Агентный поиск и достаточный контекст: когда RAG не знает достаточно

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

Классический подход предусматривает один проход по данным:

User question → embed query → retrieve top-k chunks → send to LLM → generate answer

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

Преждевременные ответы

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

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

Что означает достаточный контекст

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

От метода top-k к поиску доказательств

Стандартный RAG рассматривает поиск как единый шаг: сначала находят данные, затем отвечают. Агентный поисок рассматривает его как рабочий процесс:

Retrieve once → answer

Plan → retrieve → inspect → judge evidence → retrieve again → answer

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

Почему агенты повышают ставки

Чат-бот отвечает на вопрос. Агент принимает решения: выбирает инструменты, вызывает API, обновляет записи, создаёт заявки, рекомендует действия, запрашивает одобрение или выполняет множество шагов. Неполный контекст затем распространяется дальше:

Incomplete retrieval → wrong diagnosis → wrong tool call → wrong business action

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

Куда движется технология агентного поиска

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

Поиск между корпусами данных

Корпоративные знания не хранятся в одной упорядоченной базе данных векторов. Они распределены по Google Drive, Confluence, Notion, Slack, Jira, GitHub, хранилищам данных, тикетам поддержки, панелям управления, внутренним API, документации к продуктам и PDF-руководствам. Хорошая система должна определять, где искать в первую очередь. Механизм поиска может классифицировать запрос как касающийся правил, поведения продукта, индивидуальных потребностей клиента, инцидента, финансовых показателей или технических зависимостей, и направлять его соответственно. Поиск во всем объеме данных требует значительных усилий, а поиск в неверном месте ещё хуже.

Инструменты поиска

Один из полезных подходов представляет поиск как набор контролируемых инструментов вместо фиксированного результата:

search(query)
find(term, document)
open(document_id)
summarize(document_id_or_section)

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

Проход по графу знаний

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

Customer → Workspace → Feature Flag → Service → Incident → Release Note

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

Оценка достаточности доказательств

После поиска система должна определить, достаточны ли имеющиеся доказательства. Отвечает ли она напрямую на вопрос? Не отсутствуют ли сущности, даты или источники? Совпадают ли источники? Обладает ли источник реальным авторитетом? Можно ли цитировать ответ? Если доказательства слабы, система продолжает поиск:

Evidence score: weak
Reason: found general export docs, but no customer-specific workspace state
Next action: query account configuration source

Цикл предотвращает преждевременные ответы и облегчает отладку, поскольку вы можете увидеть, почему агент снова выполнил поиск.

Графы контекста и память агента

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

User asked about Acme export failure → agent searched export docs →
found migration-related incident → checked Acme workspace state →
concluded permission-path mismatch

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

Мультимодальный RAG с учетом структуры документов

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

Лимиты ресурсов инструментов и контекста

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

Tool definitions + retrieved evidence + conversation history + room for the answer
= one finite context window

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

Архитектура в производстве

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

User Question
   ↓
Intent + Risk Classifier
   ↓
Retrieval Planner
   ↓
Source Router
   ├── Enterprise Search
   ├── Vector Search
   ├── Keyword Search
   ├── Knowledge Graph
   ├── Structured Data
   ├── Document Parser
   └── Agent Memory
   ↓
Evidence Inspector
   ↓
Sufficiency Gate
   ├── If insufficient → refine query / follow graph / open document
   └── If sufficient → generate answer
   ↓
Answer with Evidence Trace

Практический совет проще: не позволяйте RAG отвечать, пока у него нет достаточно доказательств.

Случай Acme: от начала до конца

При вопросе о причине неудачной экспортации после миграции рабочего пространства стандартный RAG загружает руководство по устранению неполадок при экспорте и часто задаваемые вопросы по миграции, отвечая, что экспорт, скорее всего, не удался из-за отсутствия прав. Агентная система проводит расследование:

1. Поиск в документации поддержки информации о неудачах при экспорте.
2. Поиск в записях об обновлениях изменений, связанных с миграцией рабочего пространства.
3. Открытие настройок аккаунта клиента.
4. Проверка состояния флагов функций.
5. Поиск в истории инцидентов.
6. Прослеживание графа зависимостей от сервиса экспорта до сервиса управления правами.
7. Определение того, достаточно ли теперь доказательств.
8. Написание ответа с указанием источников.

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

Что создавать в первую очередь

Если у вас уже есть система RAG, не нужно перестраивать всё заново. Выполните следующие шаги в порядке:

1. Добавьте проверку достаточности. Перед генерацией ответа уточните, достаточно ли полученных доказательств для конкретного вопроса; если нет, либо проведите ещё одну поиск, либо задайте пользователю уточняющий вопрос.
2. Добавить механизм маршрутизации источников. Поиск в каждом источнике при каждом запросе — пустая трата усилий. Сначала необходимо классифицировать запрос: вопросы, связанные с политиками, направляются в документы с политиками, проблемы клиентов — в заявки вместе с информацией о состоянии аккаунта, технические сбои — в документы, журналы и граф сервисов, а вопросы, касающиеся метрик, — в семантический слой.
3. Добавить инструменты поиска, такие как search, open, find, summarize, follow_entity_relation и query_structured_record, чтобы процесс поиска стал итеративным.
4. Добавить алгоритмы прослеживания в графе, при которых ответы зависят от принадлежности элементов, их взаимозависимостей, цепочек связей, причинно-следственных связей, иерархии, многократных связей или исключений из политик.
5. Сохранять структуру документа. Для PDF, отчетов, слайдов, таблиц и диаграмм использовать парсинг, учитывающий структуру документа, и хранить её, а не просто разбивать содержимое на фрагменты.
6. Сохраняйте запись доказательств, в которой указаны источники, которые были просмотрены, документы, открытые, факты, принятые, выявленные пробелы, а также причина, по которой система решила, что информации достаточно. Именно такая запись способствует формированию доверия к агентному подходу RAG.

Чего не стоит переусердствовать с разработкой

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

Изменения

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

Vector DB → top-k chunks → LLM

и ещё что-то в этом роде:

Planner → source routing → retrieval tools → graph traversal → evidence scoring → answer

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

plan the search → route to the right sources → inspect evidence →
follow relationships → check sufficiency → retrieve again if needed →
answer only when grounded

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