Семь архитектур RAG, выходящих за рамки наивного подхода, и ситуации, когда каждая из них подходит.

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

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

Почему существует RAG

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

Основная схема работы приведена ниже.

Когда пользователь задает вопрос, система выполняет четыре шага:

1. Поиск соответствующего материала во внешней базе знаний
2. Выбор наиболее подходящих фрагментов
3. Дополнение этих фрагментов к запросу рядом с вопросом
4. Отправка всего этого в ГЛМ, который формирует ответ на основе этого контекста

Кратко: вопрос, поиск, извлечение информации, добавление контекста, ИИ-модель, ответ. Этот подход хорошо работает с небольшими, структурированными наборами документов. Реальные данные редко ведут себя предсказуемо, и обычно проявляются пять основных слабостей:

• Фрагменты теряют контекст. Фраза о росте доходов на 3% не указывает, о какой компании и за какой квартал идет речь.
• Информация утрачивается. Таблицы, диаграммы и отсканированные страницы часто не сохраняются при поиске в текстовом формате.
• Первый поиск может оказаться неверным, а простые системы RAG не пытаются выполнить поиск заново.
• Предыдущие разговоры исчезают. При отсутствии памяти каждая сессия начинается с нуля.
• Факты остаются разрозненными. Когда информация распределена по нескольким документам, для получения осмысленного ответа может потребоваться ее связывание.

Это не просто пять случайных проблем. Они объясняют, почему существуют различные архитектуры, причем каждая из них направлена на устранение конкретной ошибки в базовой схеме обработки данных.

1. Примечания к контекстуальным фрагментам

Перед сохранением фрагмента к нему прилагается краткое примечание, объясняющее его содержание, чтобы он оставался понятным даже после выхода из исходного документа. Представьте, что вы оторвали один абзац из книги и передали его незнакомцу без указания названия или номера главы — он не сможет понять, к чему это относится. Если же сначала прикрепить примечание: «Это из главы 4, о финансовых результатах компании за второй квартал», — тогда всё становится ясно. Вот в чём суть.

Без примечания фрагмент гласит, что доходы выросли на 3% по сравнению с предыдущим кварталом, при этом не указаны ни компания, ни год. С примечанием становится ясно, что это информация из отчёта ACME Corp за второй квартал 2023 года, а далее следует та же самая фраза.

Raw chunk:        "revenue grew 3% over the previous quarter"
                   -> which company? which year? unclear

With a note attached:  "From ACME Corp's Q2 2023 filing.
                        Revenue grew 3% over the previous quarter."
                   -> now it makes sense on its own

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

2. Мультимодальный поиск

Документы часто вовсе не являются простым текстом. Преобразование страницы PDF в текст при поиске может исказить таблицы и диаграммы, поэтому альтернативой является возможность для системы просматривать страницу в виде изображения. Сравните чтение описания диаграммы кем-то с просмотром самой диаграммы. Описание может упускать детали или неправильно указывать цифры, тогда как оригинал этого не делает.

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

Old way:  PDF page -> extract text -> guess at the table layout -> search the text
          (numbers and structure can get scrambled along the way)

Multimodal way:  PDF page -> search the page as an image directly
                 (the table stays a table, the chart stays a chart)

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

3. Гибридный поиск

Один за другим выполняются два вида поиска: один понимает смысл запроса, а другой ищет точное совпадение слов, после чего результаты объединяются. Представьте себе двух библиотекарей: один понимает, что вы имеете в виду, даже если формулировка неточна; другой не учитывает контекст, но всегда найдет документ с именно тем кодом, который вы ввели. Суть гибридного поиска и заключается в использовании обоих подходов.

Возьмем запрос «error E0502 borrow checker». Поиск, основанный на понимании смысла, находит документы по связанной теме даже без точного выражения, а поиск по точным словам находит буквальную строку «E0502», после чего объединенные результаты сливают оба варианта.

Query: "error E0502 borrow checker"

Meaning-based search:   finds docs about a similar concept, even without that exact phrase
Exact-word search:      finds the literal string "E0502"
Combined:               merges both into one final list

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

4. Поиск в стиле графов и карт

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

Предположим, кто-то хочет узнать основные темы всего, что опубликовано в этом году. Ни одна отдельная статья не может на это ответить. Если бы организация была разделена на отделы, каждый из которых имел бы одностраничное резюме своей работы, то прочтение только этих страниц позволило бы быстро получить ответ. Это и есть карта. Более умная версия ведет себя как ассистент, который сначала определяет, какие отделы связаны с вопросом, а не просто читает все резюме без разбора.

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

Step 1, build the map (done once, ahead of time):

  Documents -> find how people/ideas connect -> group related ones
            -> write a short summary for each group

Step 2, answer a broad question:

  "What are the big themes here?"
  -> pick the relevant groups (a smart version does this pick automatically)
  -> read just their summaries -> combine into one answer

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

5. Агентный, итеративный поиск

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

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

Question comes in
     -> Search once -> "Is this enough to answer?"
     -> No: search again, using what was just learned
     -> No, still not enough: search again, from a different angle
     -> Yes: now answer

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

6. Поиск с участием нескольких агентов

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

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

Question comes in
  -> Planner decides what needs to be looked up
  -> Searchers go look, sometimes from different sources at the same time
  -> Checker reviews what came back for accuracy
  -> Writer puts together the final answer

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

7. Поиск на основе памяти

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

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

Выбор

Naive RAG действует незаметно. Он не падает и не выдаёт ошибок. Пользователи просто получают ответы, основанные на неверной информации, и всё кажется в порядке, пока кто-то не проверит результаты.

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