Руководство по поисковой дополненной генерации (RAG) Часть 2

От истоков RAG до современного использования

Многие идеи, используемые RAG, почерпнуты из предыдущих исследований по теме ответов на вопросы. Интересно, однако, что первоначальное предложение RAG в [1] было в значительной степени вдохновлено (как показал автор RAG) одной статьей [16], которая дополняет процесс предварительной подготовки языковой модели аналогичным механизмом поиска. А именно, RAG был вдохновлен “убедительным видением обученной системы, в середине которой был поисковый индекс, чтобы она могла научиться генерировать любой текстовый вывод, который вы хотели (источник)”. В этом разделе мы расскажем о происхождении RAGE и о том, как эта техника эволюционировала для использования в современных приложениях LLM.

Генерация с расширенным поиском для наукоемких задач NLP [1]

Впервые RAG был предложен в [1] — в 2021 году, когда LLM были менее изучены, а модели Seq2Seq были чрезвычайно популярны — для помощи в решении наукоемких задач или задач, которые люди не могут решить без доступа к внешнему источнику знаний. Как мы знаем, предварительно обученные языковые модели содержат много информации в пределах своих параметров, но у них заведомо плохая способность получать доступ к этой базе знаний и манипулировать ею. По этой причине производительность систем, основанных на языковых моделях, на момент предложения RAG значительно отставала от производительности специализированных методов, основанных на извлечении. Проще говоря, исследователи изо всех сил пытались найти эффективный и простой метод расширения базы знаний предварительно обученной модели.

“Средство поиска предоставляет скрытые документы, обусловленные входными данными, а модель seq2seq затем создает условия для этих скрытых документов вместе с входными данными для генерации выходных данных”. — из [1]

Как RAG может помочь? Идея RAG заключается в том, чтобы улучшить способность предварительно обученной языковой модели получать доступ к знаниям и использовать их, подключив ее к непараметрическому хранилищу памяти - обычно это набор документов или текстовых данных, по которым мы можем выполнять поиск; смотрите ниже. Используя этот подход, мы можем динамически извлекать релевантную информацию из нашего хранилища данных при генерации выходных данных с помощью модели. Этот подход не только предоставляет модели дополнительный (фактический) контекст, но и позволяет нам (т.е. людям, использующим/обучающим модель) изучить результаты поиска и получить более глубокое представление о процессе решения проблем LLM. Для сравнения, поколения предварительно обученной языковой модели - это в значительной степени черный ящик!

Предварительно обученная модель в [1] на самом деле точно настроена с использованием этой настройки RAG. Как таковая, стратегия RAG, предложенная в [1], - это не просто метод логического вывода для повышения достоверности. Скорее, это универсальный рецепт тонкой настройки, который позволяет нам подключать предварительно обученные языковые модели к внешним источникам информации.

Подробности о настройке. Формально RAG рассматривает входную последовательность x (т.е. приглашение) и использует эти входные данные для извлечения документов z (т.е. фрагментов текста), которые используются в качестве контекста при генерации целевой последовательности y. Для поиска авторы в [1] используют модель поиска плотных проходов (DPR) [2], предварительно обученный двоичный кодировщик, который использует отдельные модели BERT для кодирования запросов (т.е. кодировщик запросов) и документов (т.е. кодировщик документов); смотрите ниже. Для генерации используется предварительно обученная модель BART [3]. BART - это языковая модель кодировщика-декодера (Seq2Seq), которая предварительно обучается с использованием цели шумоподавления. И ретривер, и генератор в [1] основаны на предварительно обученных моделях, что делает точную настройку необязательной — установка RAG уже обладает способностью извлекать и использовать знания с помощью своих предварительно обученных компонентов.

Данные, используемые для Region [1], представляют собой дамп Википедии, который разбит на последовательности по 100 токенов. Размер блока, используемый для RAG, является гиперпараметром, который необходимо настраивать в зависимости от приложения. Каждый фрагмент преобразуется в векторное вложение с помощью предварительно обученного кодировщика документов DPR. Используя эти вложения, мы можем создать индекс для эффективного векторного поиска и извлекать соответствующие фрагменты при вводе последовательности текста (например, приглашения или сообщения) в качестве входных данных.

Обучение с помощью RAG. Набор данных, используемый для обучения модели RAG в [1], содержит пары входных запросов и желаемых ответов. При обучении модели в [1] мы сначала внедряем входной запрос, используя кодировщик запросов DPR, и выполняем поиск ближайшего соседа в индексе документа, чтобы вернуть K наиболее похожих текстовых фрагментов. Отсюда мы можем объединить текстовый фрагмент с входным запросом и передать этот объединенный ввод в BART для генерации выходных данных; смотрите ниже.

Модель в [1] принимает только один документ в качестве входных данных при создании выходных данных с помощью BART. Таким образом, мы должны выделять верхние Kдокументы при создании текста, а это означает, что мы прогнозируем распределение по сгенерированному тексту, используя каждый отдельный документ. Другими словами, мы запускаем прямой проход BART с каждым из различных документов, используемых в качестве входных данных. Затем мы берем взвешенную сумму выходных данных модели (т. е. каждый выходной результат представляет собой распределение вероятностей по сгенерированному тексту) на основе вероятности документа, используемого в качестве входных данных. Эта вероятность документа выводится из оценки поиска (например, косинусного сходства) документа. В [1] предложены два метода маргинализации документов:

RAG-Sequence : один и тот же документ используется для прогнозирования каждого целевого токена.
RAG-Token : каждый целевой токен прогнозируется с помощью отдельного документа.

Во время вывода мы можем сгенерировать выходную последовательность, используя любой из этих подходов, используя модифицированную форму поиска луча . Для обучения модели мы просто используем цель моделирования на стандартном языке, которая максимизирует логарифмическую вероятность целевой выходной последовательности. Примечательно, что подход RAG, предложенный в [1], обучает только кодировщик запросов DPR и генератор BART, оставляя кодировщик документов фиксированным. Таким образом, мы можем избежать необходимости постоянно перестраивать индекс векторного поиска, используемый для поиска, что было бы дорого.

Как это работает? Формулировка RAG, предложенная в [1], оценивается в широком спектре наукоемких задач НЛП. В этих наборах данных формулировка RAG сравнивается с:

Экстрактивные методы : работают путем прогнозирования ответа в виде фрагмента текста из полученного документа.
Методы закрытой книги : работают путем генерации ответа на вопрос без какого-либо соответствующего механизма поиска.

Как показано в таблицах выше, RAG обеспечивает новую современную производительность в задачах ответа на вопросы открытого домена (левая таблица), превосходя как экстрактивные модели, так и модели Seq2Seq. Интересно, что RAG даже превосходит базовые версии, в которых используется средство извлечения документов в стиле перекрестного кодирования. По сравнению с экстрактивными подходами RAG является более гибким, поскольку на вопросы можно ответить, даже если они непосредственно не присутствуют ни в одном из извлеченных документов.

«RAG сочетает в себе гибкость генерации подходов с закрытой книгой (только параметрические) и производительность подходов, основанных на поиске с открытой книгой». - от 1]

В тестах на абстрактные вопросы и ответы RAG достигает практически самых современных результатов. В отличие от RAG, базовым методам предоставляется доступ к золотому отрывку, содержащему ответ на каждый вопрос, и на многие вопросы довольно сложно ответить без доступа к этой информации (т. е. необходимая информация может отсутствовать в Википедии). Несмотря на этот недостаток, RAG имеет тенденцию давать более конкретные, разнообразные и фактически обоснованные ответы.

Использование RAG в эпоху LLM

Хотя RAG изначально была предложена в [1], эта стратегия — с некоторыми незначительными отличиями — до сих пор активно используется для повышения фактологичности современных программ LLM. Структура RAG, используемая для LLM, показана на рисунке выше. Основные отличия этого подхода от подхода [1] заключаются в следующем:

Точная настройка не является обязательной и часто не используется. Вместо этого мы полагаемся на возможности LLM для контекстного обучения, чтобы использовать полученные данные.
Благодаря большим контекстным окнам, присутствующим в большинстве LLM, мы можем передать на вход модели сразу несколько документов при генерации ответа.

Идя дальше, подход RAG в [1] использует чисто векторный поиск (с би-кодировщиком) для извлечения фрагментов документа. Однако нет никаких причин использовать чистый векторный поиск! Проще говоря, механизм поиска документов, используемый в RAG, — это всего лишь поисковая система . Итак, мы можем применить все, что знаем о поиске на основе искусственного интеллекта, чтобы создать лучший конвейер RAG!

«Предоставление вашему LLM доступа к базе данных, в которую он может писать и осуществлять поиск, очень полезно, но в конечном итоге лучше всего концептуализировать это как предоставление агенту доступа к поисковой системе, а не как фактическое увеличение памяти». - источник

В этом разделе мы рассмотрим более поздние исследования, которые основаны на работе в [1] и применяют эту структуру RAG к современным генерирующим (только для декодера) LLM. Как мы увидим, ДИАПАЗОН очень важен в этой области из-за появляющейся способности конечностей выполнять контекстное обучение. А именно, мы можем внедрить знания в LLM, просто включив соответствующую информацию в приглашение!

Как контекст влияет на фактические предсказания языковых моделей [4]. Предварительно обученные LLM имеют фактическую информацию, закодированную в их параметрах, но существуют ограничения на использование этой базы знаний — предварительно обученные LLM, как правило, испытывают трудности с надежным хранением и извлечением (или манипулированием) знаниями . Используя RAG, мы можем смягчить эти проблемы, вводя надежные и актуальные знания непосредственно во входные данные модели. Однако существующие подходы, включая работу в [1] , используют контролируемый подход для RAG, где модель напрямую обучается для использования этого контекста. В [4] авторы исследуют неконтролируемый подход к RAG, который использует предварительно обученный механизм поиска и генератор, обнаруживая, что польза от RAG по-прежнему велика, когда не выполняется точная настройка; см. выше.

«Поддержка коллекции веб-масштабов, состоящей из потенциально миллионов изменяющихся API, требует переосмысления нашего подхода к интеграции инструментов». — из [5]

Gorilla: большие языковые модели, связанные с массивными API [5]. Объединение языковых моделей с внешними инструментами — популярная тема в исследованиях ИИ. Однако эти методы обычно учат базовый LLM использовать небольшой фиксированный набор потенциальных инструментов (например, калькулятор или поисковую систему) для решения проблем. Напротив, авторы в [5] разрабатывают стратегию тонкой настройки на основе поиска для обучения LLM, называемого Gorilla, использованию более 1600 различных API-интерфейсов моделей глубокого обучения (например, от HuggingFace или TensorFlow Hub) для решения проблем; см. ниже.

Сначала загружается документация для всех этих различных API-интерфейсов моделей глубокого обучения. Затем используется подход самообучения [6] для создания набора данных точной настройки, в котором вопросы сочетаются с соответствующим ответом, который использует вызов одного из соответствующих API. Отсюда модель настраивается на основе этого набора данных с учетом поиска, при этом предварительно обученная система поиска информации используется для получения документации наиболее подходящих API для решения каждого вопроса. Эта документация затем передается в подсказку модели при генерации выходных данных, тем самым обучая модель использовать документацию полученных API при решении проблемы и генерации вызовов API; см. ниже.

В отличие от большинства приложений RAG, Gorilla на самом деле настроена так, чтобы лучше использовать свой механизм поиска. Интересно, что такой подход позволяет модели адаптироваться к изменениям в документации API в реальном времени во время вывода и даже позволяет модели генерировать меньше галлюцинаций за счет использования соответствующей документации.

Точная настройка или восстановление? Сравнение внедрения знаний в LLM [7]. В [7] авторы изучают концепцию внедрения знаний, которая относится к методам включения информации из внешнего набора данных в базу знаний LLM. Учитывая предварительно обученный LLM, мы можем внести в эту модель знания двумя основными способами: i) точная настройка (т. Е. Продолжающееся предварительное обучение) и ii) RAG.

В [4] мы видим, что RAG намного превосходит тонкую настройку в отношении внедрения новых источников информации в ответы LLM; см. ниже. Интересно, что сочетание точной настройки с RAG не всегда превосходит эффективность RAG в отдельности, что демонстрирует влияние RAG на достоверность LLM и качество ответов.

RAGAS: Автоматизированная оценка поисковой дополненной генерации [8].

RAG — эффективный инструмент для приложений LLM. Однако этот подход сложно оценить, поскольку существует множество параметров «производительности», которые характеризуют эффективный конвейер RAG:

Возможность идентифицировать соответствующие документы.
Правильное использование данных в документах посредством контекстного обучения.
Генерация высококачественного заземленного выхода.

RAG — это не просто поисковая система, а скорее многоэтапный процесс поиска полезной информации и использования этой информации для повышения качества результатов с помощью LLM. В [8] авторы предлагают подход, называемый «Оценка расширенной генерации с поиском» (RAGAS), для оценки этих сложных конвейеров RAG без каких-либо наборов данных, аннотированных человеком, или справочных ответов. В частности, для оценки используются три класса метрик:

Верность : ответ основан на данном контексте.
Актуальность ответа : ответ касается заданного вопроса.
Релевантность контекста : полученный контекст сфокусирован и содержит как можно меньше нерелевантной информации.

Вместе эти метрики, как утверждают авторы в [8] , целостно характеризуют производительность любого конвейера RAG. Кроме того, мы можем автоматически оценивать каждую из этих метрик, предлагая мощные базовые модели, такие как ChatGPT или GPT-4. Например, в [8] достоверность оценивается путем предложения LLM извлечь набор фактических утверждений из сгенерированного ответа, а затем снова предложить LLM определить, можно ли вывести каждое из этих утверждений из предоставленного контекста; см. ниже. Релевантность ответа и контекста оцениваются аналогичным образом (возможно, с некоторыми дополнительными уловками, основанными на внедрении сходства).

Примечательно, что набор инструментов RAGAS — это не просто документ. Эти инструменты, которые сейчас довольно популярны среди специалистов LLM, были реализованы и открыто опубликованы в Интернете . Документация инструментов RAGAS представлена по ссылке здесь .

Практические советы по применению RAG

Хотя на тему RAG опубликовано множество статей, этот метод наиболее популярен среди практиков. В результате многие из лучших выводов о том, как успешно использовать RAG, скрыты в сообщениях в блогах, дискуссионных форумах и других неакадемических публикациях. В этом разделе мы изложим некоторые знания из этой предметной области, изложив наиболее важные практические уроки, которые следует учитывать при создании приложения RAG.

RAG – это поисковая система!

Применяя RAG в практических приложениях, мы должны понимать, что конвейер поиска, используемый для RAG, — это всего лишь поисковая система ! А именно, те же методы поиска и ранжирования, которые годами использовались поисковыми системами, могут быть применены RAG для поиска более релевантных текстовых фрагментов. Из этого осознания можно извлечь несколько практических советов по улучшению RAG.

Не используйте просто векторный поиск. Многие системы RAG используют исключительно плотный поиск для поиска соответствующих текстовых фрагментов. Такой подход довольно прост, поскольку мы можем просто: i) создать встраивание для приглашения ввода и ii) выполнить поиск связанных фрагментов в нашей базе данных векторов. Однако семантический поиск имеет тенденцию давать ложноположительные результаты и может давать зашумленные результаты. Чтобы решить эту проблему, мы должны выполнить гибридный поиск, используя комбинацию векторного и лексического поиска — как в обычной поисковой системе (на базе искусственного интеллекта) ! Подход к векторному поиску не меняется, но мы можем выполнить параллельный лексический поиск:

Извлечение ключевых слов из приглашения ввода.
Выполнение лексического поиска по этим ключевым словам.
Получение взвешенной комбинации результатов лексического/векторного поиска.

Выполняя гибридный поиск, мы делаем наш конвейер RAG более надежным и уменьшаем частоту появления нерелевантных фрагментов в контексте модели. Кроме того, использование поиска по ключевым словам позволяет нам выполнять хитрые трюки, например продвигать документы с важными ключевыми словами, исключать документы с минус-словами или даже дополнять документы синтетически сгенерированными данными для лучшего соответствия!

Оптимизация конвейера RAG. Чтобы улучшить нашу поисковую систему, нам необходимо собирать метрики, которые позволят нам оценивать ее результаты так же, как и любую обычную поисковую систему. Один из способов сделать это — показать конечным пользователям текстовые фрагменты, используемые для определенных поколений, аналогично цитате, чтобы пользователь мог использовать информацию, полученную RAG, для проверки фактической правильности выходных данных модели. В рамках этой системы мы могли бы затем предлагать пользователю предоставить двоичную обратную связь (т. е. «палец вверх» или «палец вниз») относительно того, действительно ли информация актуальна; см. ниже. Используя эту обратную связь, мы можем оценивать результаты нашей поисковой системы, используя традиционные метрики поиска (например, DGC или nDCG ), тестировать изменения в системе с помощью AB-тестов и итеративно улучшать наши результаты.

Оценки RAG должны выходить за рамки простой проверки результатов поиска. Даже если мы получим идеальный набор контекста для включения в приглашение модели, сгенерированный вывод все равно может быть неверным. Чтобы оценить генерирующий компонент RAG, сообщество ИИ в значительной степени полагается на автоматизированные метрики, такие как RAGAS [8] или LLM as a Judge [9], которые выполняют оценки, запрашивая LLM, такие как GPT-4; более подробную информацию см. здесь . Эти методы, по-видимому, обеспечивают надежную обратную связь о качестве создаваемого результата. Однако для успешного применения RAG на практике важно оценить все части комплексной системы RAG, включая как извлечение, так и генерацию , чтобы мы могли надежно оценить улучшения, внесенные в каждый компонент.

Улучшение с течением времени. После того как мы построим правильный конвейер поиска и сможем оценить комплексную систему RAG, последним шагом применения RAG будет выполнение итеративных улучшений с использованием комбинации лучших моделей и данных. Существует множество улучшений, которые можно изучить, включая (но не ограничиваясь):

Добавление ранжирования в конвейер поиска с использованием перекрестного кодировщика или гибридной модели, которая выполняет как поиск, так и ранжирование (например, ColBERT [10]).
Точная настройка модели внедрения для плотного поиска по релевантным данным, собранным человеком (т. е. парам входных подсказок с релевантными/нерелевантными отрывками).
Точная настройка генератора LLM на примерах высококачественных результатов, чтобы он научился лучше следовать инструкциям и использовать полезный контекст.
Использование LLM для дополнения приглашения ввода или текстовых фрагментов дополнительными синтетическими данными для улучшения поиска.

Для каждого из этих изменений мы можем измерить их влияние на исторические данные в автономном режиме. Однако, чтобы по-настоящему понять, оказывают ли они положительное влияние на систему RAG, нам следует полагаться на онлайн-тесты AB, которые сравнивают показатели новой и улучшенной системы с предыдущей системой в ходе испытаний в реальном времени на людях.

Оптимизация контекстного окна

Успешное применение RAG — это не просто вопрос получения правильного контекста: огромную роль играет оперативное проектирование . Как только мы получим соответствующие данные, мы должны создать подсказку, которая: i) включает этот контекст и ii) форматирует его таким образом, чтобы получить обоснованный вывод от LLM. В этом разделе мы рассмотрим несколько стратегий создания эффективных подсказок с помощью RAG, чтобы лучше понять, как правильно включать контекст в подсказку модели.

RAG требует большего контекстного окна. Во время предварительного обучения LLM видит входные последовательности определенной длины. Этот выбор длины последовательности во время предварительного обучения становится длиной контекста модели. В последнее время мы наблюдаем тенденцию в исследованиях ИИ к созданию LLM с большей длиной контекста. См., например, MPT-StoryWriter-65K, Claude-2.1 или GPT-4-Turbo , которые имеют длину контекста 65 КБ, 200 КБ и 128 КБ соответственно. Для справки: «Великий Гэтсби» (то есть целая книга!) содержит всего около 70 тысяч токенов . Хотя не все LLM имеют большое контекстное окно, RAG требует модели с большим контекстным окном, чтобы мы могли включить достаточное количество текстовых фрагментов в приглашение модели.

Максимизация разнообразия. Как только мы убедились, что выбрали LLM с достаточно большой длиной контекста, следующим шагом в применении RAG будет определение того, как выбрать лучший контекст для включения в приглашение. Хотя текстовые фрагменты, которые необходимо включить, выбираются нашим конвейером поиска, мы можем оптимизировать нашу стратегию подсказок, добавив специализированный компонент выбора , который частично выбирает результаты поиска. Выбор не меняет процесс поиска RAG . Скорее, выделение добавляется в конец конвейера поиска — после того, как соответствующие фрагменты текста уже идентифицированы и ранжированы — чтобы определить, как документы лучше всего выбирать и упорядочивать в результирующем приглашении.

Одним из популярных подходов к выбору является ранжирование разнообразия, которое можно использовать для максимизации разнообразия текстовых фрагментов, включенных в подсказку модели, путем выполнения следующих шагов:

Используйте конвейер поиска для создания большого набора документов, которые можно включить в приглашение модели.
Выберите документ, который наиболее похож на входные данные (или запрос), что определяется путем внедрения косинусного сходства.
Для каждого оставшегося документа выберите документ, который меньше всего похож на уже выбранные документы.

Примечательно, что эта стратегия оптимизируется исключительно с учетом разнообразия выбранного контекста, поэтому важно, чтобы мы применяли эту стратегию выбора после того, как набор соответствующих документов был идентифицирован конвейером поиска. В противном случае специалист по ранжированию разнообразия выберет разнообразные, но нерелевантные фрагменты текста для включения в контекст.

Оптимизация макета контекста. Несмотря на увеличение длины контекста, недавние исследования показывают, что LLM с трудом захватывает информацию в середине большого контекстного окна [11]. Информация в начале и конце контекстного окна фиксируется наиболее точно, в результате чего некоторые данные «теряются посередине». Чтобы решить эту проблему, мы можем принять стратегию выбора, которая более внимательно относится к тому, где в подсказке размещается контекст. В частности, мы можем взять соответствующие текстовые фрагменты из нашего конвейера поиска и итеративно разместить наиболее релевантные фрагменты в начале и конце контекстного окна; см. ниже. Такой подход позволяет избежать вставки текстовых фрагментов в порядке их релевантности, а вместо этого предпочитает размещать наиболее релевантные фрагменты в начале и конце подсказки.

Очистка и форматирование данных

В большинстве приложений RAG наша модель будет получать текстовую информацию из множества различных источников. Например, помощник, созданный для обсуждения деталей кодовой базы с программистом, может извлекать информацию из самого кода, страниц документации, сообщений в блогах, веток обсуждений пользователей и многого другого. В этом случае данные, используемые для RAG, имеют множество различных форматов, которые могут привести к появлению артефактов (например, логотипов, значков, специальных символов и блоков кода) в тексте, которые могут сбить с толку LLM при создании выходных данных. Чтобы приложение функционировало правильно, мы должны извлечь, очистить и отформатировать текст из каждого из этих разнородных источников. Проще говоря, предварительная обработка данных для RAG — это гораздо больше, чем просто разделение текстовых данных на фрагменты !

Влияние на производительность. Если текст из каждого источника знаний не будет извлечен должным образом, производительность нашего RAG-приложения заметно ухудшится! С другой стороны, стандартизированная очистка и форматирование данных заметно улучшит производительность. Как показано в этом сообщении блога , инвестиции в правильную предварительную обработку данных для RAG имеют несколько преимуществ (см. выше):

Повышение правильности ответов, сгенерированных LLM, на 20%.
Сокращение количества токенов, переданных в модель, составило 64%.
Заметное улучшение общего поведения LLM.

«Мы написали быстрый рабочий процесс, в котором использовалась LLM в качестве судьи, и итеративно разработали код очистки для удаления посторонних токенов форматирования из файлов и веб-страниц Markdown». — из [12]

Конвейер очистки данных. Детали любого конвейера очистки данных для RAG будут во многом зависеть от нашего приложения и данных. Чтобы создать функционирующий конвейер данных, мы должны: i) наблюдать за большими объемами данных в нашей базе знаний, ii) визуально проверять наличие нежелательных артефактов и iii) устранять обнаруженные проблемы, добавляя изменения в конвейер очистки данных. Хотя этот подход не является ярким или крутым, любой специалист по искусственному интеллекту и машинному обучению знает, что 90% времени на создание приложения будет потрачено на наблюдение и работу с данными.

Если мы не заинтересованы в проверке данных вручную и хотим более удобного подхода, мы можем автоматизировать процесс создания функционального конвейера предварительной обработки данных, используя LLM-as-a-Judge [9] для итеративного построения кода для очистки и правильного форматирование данных. Недавно было показано, что такой подход сохраняет полезную информацию, устраняет ошибки форматирования и резко уменьшает средний размер документов [12]. См . здесь полученный сценарий предварительной обработки данных и ниже пример переформатированного документа после очистки.

Дополнительные практические ресурсы по RAG

Как упоминалось ранее, некоторые из лучших ресурсов для изучения RAG не публикуются в научных журналах или на конференциях. Существует множество сообщений в блогах и практических статей, которые помогли мне понять, как лучше использовать RAG. Некоторые из наиболее примечательных ресурсов описаны ниже.

Что такое поисковая дополненная генерация? [ связь ]
Создание приложений LLM для производства на основе RAG [ ссылка ]
Лучшие практики оценки заявок на получение степени LLM для RAG [ ссылка ]
Создание диалогового поиска с помощью RAG в Vespa [ ссылка ]
Точная настройка RAG с помощью Ray и HuggingFace [ ссылка ]

Заключительные мысли

На этом этапе мы должны иметь полное представление о RAG, его внутренней работе и о том, как лучше всего подойти к созданию высокопроизводительного приложения LLM с использованием RAG. И концепция, и реализация RAG просты, что в сочетании с впечатляющими характеристиками делает эту технику такой популярной среди практиков. Однако успешное применение RAG на практике предполагает нечто большее, чем просто создание минимального функционирующего конвейера с предварительно обученными компонентами. А именно, мы должны усовершенствовать наш подход RAG путем:

Создание высокопроизводительного гибридного алгоритма поиска (возможно, с компонентом повторного ранжирования), который сможет точно идентифицировать соответствующие текстовые фрагменты.
Построение функционального конвейера предварительной обработки данных, который правильно форматирует данные и удаляет вредные артефакты перед использованием данных для RAG.
Поиск правильной стратегии подсказок, которая позволит LLM надежно включать полезный контекст при создании результатов.
Введение детальных оценок как для конвейера поиска (т. е. с использованием традиционных метрик поиска), так и для компонента генерации (с использованием RAGAS или LLM в качестве судьи [8, 9]).
Сбор данных с течением времени, которые можно использовать для улучшения способности конвейера RAG обнаруживать соответствующий контекст и генерировать полезные выходные данные.

Идя дальше, создание надежного пакета оценки позволяет нам улучшить каждый из перечисленных выше компонентов путем количественного тестирования (с помощью автономных показателей или AB-теста) итеративных улучшений нашего конвейера RAG, таких как модифицированный алгоритм поиска или точно настроенный компонент системы. . Таким образом, наш подход к RAG должен со временем развиваться (и совершенствоваться!) по мере того, как мы тестируем и открываем новые идеи. (c) Cameron R. Wolfe, Ph.D.

Разработка чатботов на основе RAG LLM открывает новые горизонты для общения и бизнеса. Если после прочтения статьи у вас возникли идеи или вопросы о том, как ИИ может обогатить ваш проект, не стесняйтесь делиться ими. Мы всегда рады обсуждению новых концепций и поможем вам найти наилучший путь к реализации ваших инновационных идей.