Недавний всплеск интереса к генеративному ИИ привел к распространению ИИ-помощников, которые можно использовать для решения самых разных задач, включая самые разные — от покупки продуктов до поиска соответствующей информации . Все эти интересные приложения основаны на современных достижениях в области больших языковых моделей (LLM), которые обучаются на огромных объемах текстовой информации для накопления значительной базы знаний. Тем не менее, студенты LLM обладают заведомо плохой способностью извлекать и манипулировать знаниями, которыми они обладают, что приводит к таким проблемам, как галлюцинации (т. е. генерация неверной информации), ограничение знаний и плохое понимание специализированных областей. Есть ли способ улучшить способность LLM получать доступ к высококачественной информации и использовать ее?
«Если ИИ-помощники хотят играть более полезную роль в повседневной жизни, они должны иметь возможность не просто иметь доступ к огромному количеству информации, но, что более важно, получать доступ к правильной информации».
Ответ на поставленный выше вопрос – однозначное «да». В этом обзоре мы рассмотрим один из самых популярных методов внедрения знаний в LLM — поисковую дополненную генерацию (RAG) . Интересно, что RAG прост в реализации и очень эффективен при интеграции LLM с внешними источниками данных. Таким образом, его можно использовать для повышения достоверности LLM, дополнения знаний модели более свежей информацией или даже для построения специализированной модели на основе собственных данных без необходимости тщательной тонкой настройки. Что такое поисковая дополненная генерация?
Что такое RAG (Retrieval Augmented Generation) ?
Прежде чем углубиться в техническое содержание этого обзора, нам необходимо получить базовое представление о расширенной генерации данных (RAG), о том, как она работает и почему она полезна. LLM содержат много знаний в рамках своих предварительно обученных весов (т. е. параметрических знаний), которые можно получить, запустив модель и генерируя выходные данные. Однако эти модели также имеют тенденцию галлюцинировать или генерировать ложную информацию , что указывает на то, что параметрические знания, которыми обладает LLM, могут быть ненадежными. К счастью, у LLM есть возможность работать в контексте обучения (описанного выше), определяемого как способность использовать информацию в подсказке для получения более качественного результата. С помощью RAG мы расширяем базу знаний LLM, вставляя соответствующий контекст в подсказку и полагаясь на способности LLM к обучению в контексте для получения более качественных результатов за счет использования этого контекста.
“Процесс RAG принимает запрос и оценивает, относится ли он к темам, определенным в парной базе знаний. Если да, он выполняет поиск в своей базе знаний для извлечения информации, относящейся к вопросу пользователя. Любой релевантный контекст в базе знаний затем передается LLM вместе с исходным запросом, и выдается ответ.” - источник
Учитывая входной запрос, мы обычно отвечаем на этот запрос с помощью LLM, просто вводя запрос (возможно, как часть шаблона запроса) и генерируя ответ с помощью LLM. RAG модифицирует этот подход, объединяя LLM с базой знаний с возможностью поиска. Другими словами, мы сначала используем входной запрос для поиска релевантной информации во внешнем наборе данных. Затем мы добавляем найденную информацию в запрос модели при генерации выходных данных, позволяя LLM использовать этот контекст (с помощью своих возможностей обучения в контексте) для генерации лучшего и более фактологического ответа; смотрите ниже. Объединив LLM с непараметрическим источником данных, мы можем предоставить модели правильную, конкретную и актуальную информацию.
Очистка и измельчение.
RAG требует доступа к набору данных, содержащему правильную и полезную информацию, для пополнения базы знаний LLM, и мы должны построить конвейер, который позволит нам искать соответствующие данные в этой базе знаний. Однако внешние источники данных, которые мы используем для RAG, могут содержать данные в самых разных форматах (например, pdf, markdown и другие). Таким образом, мы должны сначала очистить данные и извлечь необработанную текстовую информацию из этих разнородных источников данных. Как только это будет сделано, мы сможем “разбить” данные на фрагменты или разбить их на наборы более коротких последовательностей, которые обычно содержат около 100-500 токенов; смотри ниже.
RAG требует доступа к набору данных, содержащему правильную и полезную информацию, для пополнения базы знаний LLM, и мы должны построить конвейер, который позволит нам искать соответствующие данные в этой базе знаний. Однако внешние источники данных, которые мы используем для RAG, могут содержать данные в самых разных форматах (например, pdf, markdown и другие). Таким образом, мы должны сначала очистить данные и извлечь необработанную текстовую информацию из этих разнородных источников данных. Как только это будет сделано, мы сможем “разбить” данные на фрагменты или разбить их на наборы более коротких последовательностей, которые обычно содержат около 100-500 токенов; смотри ниже.
Целью фрагментирования является разделение данных на единицы поиска (т. е. на фрагменты текста, которые мы можем получить в качестве результатов поиска). Весь документ может быть слишком большим, чтобы служить единицей поиска, поэтому мы должны разделить этот документ на более мелкие части. Наиболее распространенной стратегией разбиения на фрагменты является подход фиксированного размера, который разбивает более длинные тексты на более короткие последовательности, каждая из которых содержит фиксированное количество токенов. Однако это не единственный подход! Наши данные могут быть естественным образом разделены на фрагменты (например, сообщения в социальных сетях или описания продуктов в интернет-магазине) или содержать разделители, которые позволяют нам использовать стратегию фрагментирования переменного размера .
Поиск по фрагментам (chunks). Как только мы очистим наши данные и разделим их на блоки, доступные для поиска, мы должны создать поисковую систему для сопоставления входных запросов с блоками! К счастью, мы подробно рассмотрели тему поиска с использованием искусственного интеллекта в предыдущем обзоре. Все эти концепции могут быть перепрофилированы для создания поисковой системы, которая может точно сопоставлять входные запросы с текстовыми фрагментами в RAG.
Во-первых, мы хотим построить плотную поисковую систему, i) используя модель внедрения для создания соответствующего векторного представления для каждого из наших фрагментов и ii) индексируя все эти векторные представления в базе данных векторов. Затем мы можем внедрить входной запрос, используя ту же модель внедрения, и выполнить эффективный векторный поиск для получения семантически связанных фрагментов; см. выше.
Многие приложения RAG используют чисто векторный поиск для поиска релевантных фрагментов текста, но мы можем создать гораздо лучший конвейер поиска, изменив существующие подходы к поиску на основе искусственного интеллекта. А именно, мы можем дополнить плотный поиск лексическим компонентом (или поиском на основе ключевых слов), формируя гибридный алгоритм поиска. Затем мы можем добавить мелкозернистый шаг повторного ранжирования — либо с помощью кросс-кодера, либо менее дорогого компонента (например, ColBERT [10]) — для сортировки фрагментов-кандидатов на основе релевантности; описание смотрите выше.
Дополнительная обработка данных. После извлечения мы могли бы выполнить дополнительную очистку данных для каждого текстового фрагмента, чтобы сжать данные или выделить ключевую информацию. Например, некоторые практики добавляют дополнительный этап обработки после извлечения, который пропускает текстовые фрагменты через LLM для обобщения или переформатирования перед отправкой их в окончательный LLM — такой подход распространен в LangChain. Используя этот подход, мы можем передавать сжатую версию текстовой информации в приглашение LLM вместо полного документа, тем самым экономя затраты.
Всегда ли мы ищем фрагменты? В RAG мы обычно используем алгоритмы поиска для сопоставления входных запросов с релевантными текстовыми фрагментами. Однако существует несколько различных алгоритмов и инструментов, которые можно использовать для управления RAG. Например, специалисты-практики недавно изучили возможность подключения LLMS к базам данных graph, сформировав систему RAG, которая может выполнять поиск соответствующей информации с помощью запросов к базе данных graph (например, Neo4J); смотрите здесь. Аналогичным образом, исследователи обнаружили синергию между LLMS и рекомендательными системами [14], а также прямое подключение LLMS к поисковым API, таким как Google или Serper, для доступа к актуальной информации.
Генерация вывода. После того, как мы получили соответствующие текстовые фрагменты, последний шаг RAG — вставить эти фрагменты в приглашение языковой модели и сгенерировать выходные данные; см. выше. RAG включает в себя полный сквозной процесс приема входного запроса, поиска соответствующих текстовых фрагментов, объединения этого контекста с входным запросом и использования LLM для генерации выходных данных на основе объединенных входных данных. Как мы увидим, такой подход имеет множество преимуществ.
Генерируем выходные данные. Как только мы извлекли соответствующие текстовые фрагменты, заключительным шагом RAG является вставка этих фрагментов в приглашение языковой модели и генерация выходных данных; смотрите выше. RAG включает в себя полный сквозной процесс обработки входного запроса, поиска соответствующих текстовых фрагментов, объединения этого контекста с входным запросом и использования LLM для генерации выходных данных на основе комбинированных входных данных. Как мы увидим, такой подход имеет целый ряд преимуществ.
Преимущества RAG
«Системы RAG состоят из модуля поиска и генерации на основе LLM и предоставляют LLM знания из справочной текстовой базы данных, что позволяет им действовать как слой естественного языка между пользователем и текстовыми базами данных, снижая риск галлюцинаций». — из [8]
Внедрение RAG позволяет нам специализировать LLM на базе знаний по нашему выбору. По сравнению с другими методами внедрения знаний ( тонкая настройка (или продолжительное предварительное обучение) является основной альтернативой ) RAG проще в реализации и дешевле в вычислительном отношении. Как мы увидим, RAG также дает гораздо лучшие результаты по сравнению с постоянной предварительной тренировкой! Однако внедрение RAG по-прежнему требует дополнительных усилий по сравнению с простым привлечением предварительно обученного LLM, поэтому мы кратко опишем здесь основные преимущества RAG, которые делают его целесообразным.
Уменьшение галлюцинаций. Основная причина, по которой RAG так широко используется на практике, заключается в его способности уменьшать галлюцинации (т.е. генерирование ложной информации LLM). В то время как LLM, как правило, выдают неверную информацию, полагаясь на свои знания параметров, внедрение RAG может значительно снизить частоту галлюцинаций, тем самым улучшая общее качество любого приложения LLM и укрепляя доверие среди пользователей. Кроме того, RAG предоставляет нам прямые ссылки на данные, которые используются для генерации информации в выходных данных модели. Мы можем легко предоставить пользователю ссылки на эту информацию, чтобы выходные данные LLM можно было сверить с фактическими данными; смотрите ниже.
Доступ к актуальной информации. Полагаясь на параметрические знания, у программ LLM обычно есть дата окончания знаний. Если мы хотим сделать это ограничение знаний более свежим, нам придется постоянно обучать LLM новым данным, что может быть дорогостоящим. Кроме того, недавние исследования показали, что точная настройка, как правило, неэффективна для внедрения новых знаний в LLM — большая часть информации усваивается во время предварительного обучения [7, 15]. Однако с помощью RAG мы можем легко дополнить базу знаний и результатов LLM точной и актуальной информацией.
Безопасность данных. Когда мы добавляем данные в обучающий набор LLM, всегда есть вероятность, что LLM утечет эти данные в свои выходные данные. Недавно исследователи показали, что LLM склонны к атакам с извлечением данных, которые могут обнаружить содержимое набора данных предварительного обучения LLM с помощью методов подсказок. Таким образом, включение собственных данных в набор обучающих данных LLM представляет собой угрозу безопасности. Тем не менее, мы все равно можем специализировать LLM для таких данных, используя RAG, что снижает риск безопасности, поскольку фактически никогда не обучает модель на собственных данных.
«Генерация с расширенным поиском дает моделям источники, на которые они могут цитировать, например, сноски в исследовательской работе, поэтому пользователи могут проверить любые утверждения. Это укрепляет доверие». - источник
Простота реализации. Наконец, одной из главных причин использования RAG является тот простой факт, что реализация довольно проста по сравнению с такими альтернативами, как точная настройка. Основные идеи из оригинальной статьи RAG [1] можно реализовать всего в пяти строках кода , и нет необходимости обучать сам LLM. Скорее, мы можем сосредоточить наши усилия по тонкой настройке на улучшении качества более мелких специализированных моделей, которые используются для поиска в RAG, что намного дешевле/проще.
Доступ к актуальной информации. Полагаясь на параметрические знания, LLMs обычно имеют дату отсечения знаний. Если мы хотим сделать это отсечение знаний более свежим, нам пришлось бы постоянно обучать их на новых данных, что может быть дорогостоящим. Кроме того, недавние исследования показали, что тонкая настройка, как правило, неэффективна при внедрении новых знаний в LLM — большая часть информации усваивается во время предварительного обучения [7, 15]. Однако с помощью RAG мы можем легко дополнить результаты и базу знаний LLM точной и актуальной информацией.
Безопасность данных. Когда мы добавляем данные в обучающий набор LLM, всегда существует вероятность того, что LLM допустит утечку этих данных в своих выходных данных. Недавно исследователи показали, что LLM подвержены атакам на извлечение данных, которые могут обнаружить содержимое набора данных для предварительной подготовки LLM с помощью методов запроса. Таким образом, включение конфиденциальных данных в набор данных для обучения LLM представляет угрозу безопасности. Однако мы все еще можем специализировать LLM на таких данных, используя RAG, что снижает риск безопасности, поскольку фактически никогда не обучает модель на основе закрытых данных.
“Генерация с расширенным поиском предоставляет моделям источники, на которые они могут ссылаться, например, сноски в исследовательской работе, чтобы пользователи могли проверять любые утверждения. Это укрепляет доверие”.
Простота реализации. Наконец, одной из главных причин использования RAG является тот простой факт, что реализация довольно проста по сравнению с альтернативами, такими как finetuning. Основные идеи из оригинальной статьи RAG [1] могут быть реализованы всего в пяти строках кода, и нет необходимости обучать самого LLM. Скорее, мы можем сосредоточить наши усилия по тонкой настройке на улучшении качества небольших специализированных моделей, которые используются для поиска в RAG, что намного дешевле / проще.
Продолжение здесь
