Где пайплайны RAG действуют слепо: анализ сбоев через призму паттернов агентности

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

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

Почему одноразовый пайплайн терпит неудачу

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

Когда это предположение не сбывается, ничто в пайплайне этого не замечает:

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

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

Оценка качества извлечения и переписывание запроса

Возьмём вопрос вроде «Как LangGraph обрабатывает сохранение данных?» Предположим, что механизм извлечения возвращает пять фрагментов, и только один из них имеет отношение к вопросу. Линейная схема обработки передаёт все пять фрагментов и позволяет модели самой разобраться в них, что снижает ценность полезных данных и приводит к путанице.

В рабочем процессе с использованием агентов сначала выполняется шаг оценки. Оценщик, как правило, это небольшая вызов LLM с критериями оценки «да/нет», определяет, достаточно ли полученные документы релевантны для ответа на вопрос. Если это не так, процесс не просто снова ищет с теми же данными. Вместо этого он формирует улучшенный запрос на основе результатов первой попытки и снова выполняет поиск. Результативный цикл выглядит следующим образом:

• поиск
• оценка результатов
• переписывание запроса, если он недостаточен
• снова поиск

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

Переход на альтернативный вариант при отсутствии ответа в индексе

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

Метод корректирующего RAG решает эту проблему. После оценки найденных документов рабочий процесс рассматривает недостаточный результат как сигнал к корректировке подхода, например путем запроса в другом источнике, таком как поиск в интернете. Линейный порядок действий «поиск — генерация» превращается в следующий:

• поиск
• оценка документов
• корректировка, если оценка низкая
• генерация

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

Направление каждого вопроса к соответствующему источнику

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

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

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

Проверка ответа, а не только документов

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

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

• Является ли каждое утверждение в ответе обоснованным на найденном контексте?
• Отвечает ли ответ на то, что на самом деле спросил пользователь?
• Добавила ли модель информацию, которую не подтверждает контекст?

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

Пауза для принятия решения человеком

Некоторые решения не должны приниматься автоматически. Типичные поводы для проверки человеком включают:

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

Черновик ответа, который явно требует редактирования

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

Разделение работы между специализированными агентами

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

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

Параллельная работа независимых систем поиска

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

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

Планирование перед выполнением

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

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

• получение вопроса
• создание плана
• выполнение запланированных шагов
• оценка результатов
• ответ

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

Что на самом деле делает систему RAG агентской

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

• Действительно ли для этого вопроса необходим поиск информации?
• Была ли полученная информация действительно полезной?
• Стоит ли искать снова, используя другой запрос?
• Не будет ли другой источник более подходящим?
• Подкрепляется ли ответ доказательствами?
• Требуется ли участие человека?
• Не стоит ли передать задачу другому, специализированному агенту?
• Не принесёт ли планирование действий заранее лучшего результата?

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

Сопоставьте шаблон с типом сбоя

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

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

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

Если для ответа на вопросы требуется несколько взаимосвязанных шагов, добавьте этап планирования.

Заключение

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