Агентский поиск и проблема доверия
Агентский поиск — следующий шаг эволюции систем дополненной генерации (RAG). Агент принимает запрос, сам решает, что искать и как проверять, но без встроенного механизма контроля фактов он склонен к галлюцинациям.
Исследователи выделяют два направления развития агентного ИИ: символическое (классические правила) и нейросетевое (генеративные модели). Будущее за нейро-символическими архитектурами, объединяющими формальную логику и гибкость больших языковых моделей (LLM).
Проблема контроля достоверности фактов стоит остро: модель может демонстрировать низкую степень неопределённости (perplexity), выдавая при этом фактически ложные утверждения. Без верификатора агентский поиск остаётся «чёрным ящиком», ответы которого нельзя принимать на веру.
Верификатор — специальный компонент пайплайна, который выделяет утверждения, находит подтверждающие источники и возвращает оценку достоверности. Именно он превращает агентский поиск из генератора правдоподобного текста в инструмент, пригодный для промышленной эксплуатации.
Архитектура пайплайна агентского поиска
Классический пайплайн агентского поиска состоит из этапов:
Поиск → Извлечение → Проверка → Синтез.
Поисковый запрос уточняется и направляется в базу знаний. Модуль извлечения достаёт релевантные фрагменты, часто с помощью гибридного поиска. Затем вступает верификатор: он оценивает обоснованность и фактическую достоверность полученных фрагментов, отсеивает противоречия. Только после этого модуль синтеза формирует итоговый ответ. Такое разделение позволяет локализовать проверку и не пропускать ошибки в финальный вывод.
Связь с RAG прямая: поисковая часть поставляет контекст, а верификатор работает как фильтр, отсекающий недостоверные фрагменты. Он не заменяет модуль извлечения, а дополняет его. В архитектуре также прослеживается общий тренд — переход от жёстко оркестрированных циклов логических рассуждений к децентрализованным агентным шаблонам, где проверка становится отдельным сервисом, доступным через стандартизованный протокол модельного контекста (MCP, Model Context Protocol).
Верификатор: как работает
1. Извлечение утверждений
Первый шаг — декомпозиция исходного текста на атомарные утверждения. Например, предложение «GPT-4 запустили в марте 2023, и он превзошёл GPT-3.5 по тесту MMLU» распадается на три факта:
- GPT-4 запущен в марте 2023.
- GPT-4 превзошёл GPT-3.5.
- Сравнение проводилось по тесту MMLU.
Такое извлечение утверждений позволяет проверять каждое по отдельности, а не оценивать всё высказывание целиком.
2. Сопоставление источников
Для каждого атомарного утверждения верификатор ищет подтверждающие или опровергающие доказательства.
Типичный пайплайн включает:
Атомарная декомпозиция → Поиск знаний → Оценка достоверности → Агрегация.
На этапе поиска знаний могут использоваться как классические индексы, так и графовые базы знаний. Важно не просто найти документ, а сопоставить его содержимое с конкретным фактом, избегая поверхностных совпадений.
3. Оценка доказательств
Найденным источникам присваивается уровень доверия. Оценка может быть уровневая: первичные источники (официальные документы, рецензируемые статьи) получают высший балл, вторичные — средний, а посты из социальных сетей — низший. Такой подход снижает риск опоры на недостоверные или устаревшие данные.
4. Вердикт
Финальная агрегация сводит оценки доказательств к трёхстороннему решению (подтверждает/опровергает/нейтрально) или к метрикам, аналогичным точности и полноте. В некоторых реализациях верификатор выдаёт не просто «правда/ложь», а детализированный отчёт с указанием, какие именно части ответа не подтверждены.
Типы проверок
-
Фактологическая проверка
Проверяется соответствие утверждения найденным доказательствам. Основные методы: стратегии промптинга — цепочка рассуждений (chain-of-thought, CoT) и самосогласованность (self-consistency), а также дообучение модели на доменных наборах данных. Подход на основе цепочки рассуждений заставляет LLM мыслить пошагово, а метод самосогласованности генерирует несколько вариантов ответа и выбирает наиболее согласованный. Тонкая настройка на корпусе фактчекинга повышает точность для узких предметных областей.
-
Проверка источника
Оценивается не только авторитетность источника, но и его свежесть. Устаревший документ может содержать верные на момент публикации данные, но они уже неактуальны. Отдельная проблема — атаки внедрения: злоумышленник может подмешать в корпус вредоносное содержимое, которое модуль извлечения подхватит как «доказательство». Верификатор должен распознавать такие попытки, сравнивая стиль и метаданные источника с ожидаемым профилем.
-
Логическая непротиворечивость
Сложные утверждения требуют многошаговых рассуждений. Здесь набирает популярность подход GraphCheck: графовая нейронная сеть работает поверх графа знаний и выполняет фактчекинг за один проход, без последовательных вызовов LLM. Эксперименты показывают прирост точности до 7,1% по сравнению с базовым уровнем, при этом результаты сопоставимы с моделями DeepSeek-V3 и OpenAI-o1, но с меньшим числом параметров. Такой подход особенно эффективен для проверки цепочек фактов, где каждый следующий шаг зависит от предыдущего.
Инструменты и фреймворки
OpenFactCheck (CUSTCHECKER) — открытый пайплайн фактчекинга, реализующий полный цикл от извлечения утверждений до вердикта. Легко интегрируется в существующие RAG-системы.
LangChain Evaluation Toolkit предоставляет метрики обоснованности (groundedness), ссылочной достоверности (attribution) и полноты использования контекста (chunk utilization) — они позволяют численно оценить, насколько ответ опирается на предоставленный контекст и корректно ссылается на источники.
SelfCheckGPT — инструмент обнаружения галлюцинаций, основанный на анализе согласованности множества вариантов ответа. Если ответы на один и тот же промпт различаются, это сигнал о возможной недостоверности.
GraphCheck — проверщик на базе графов знаний, сопоставимый по качеству с большими LLM, но потребляющий меньше вычислительных ресурсов.
Deepchecks и Confident AI — дополнительные инструменты мониторинга качества и стабильности ответов. Они встраиваются в конвейеры непрерывной интеграции и доставки (CI/CD) и отслеживают смещение распределения данных.
Ограничения и границы применимости
Парадокс «модель как проверяющий»: та же модель, что генерирует текст, проверяет его достоверность. Это создаёт риск циклической самопроверки, когда ошибки галлюцинации воспроизводятся и на этапе верификации.
Качество поиска остаётся узким местом. Если модуль извлечения не находит релевантных документов, даже самый точный верификатор не сможет подтвердить или опровергнуть утверждение. Проблема обостряется в мультиязычных средах и при работе с узкопрофильными наборами данных.
Свежесть данных — ещё один вызов. Информация устаревает, и верификатор должен учитывать временной разрыв, иначе он будет отвергать верные, но недавно появившиеся факты.
Атаки внедрения подрывают доверие к контексту. Если злоумышленник поместит в базу фальшивый документ, верификатор может принять его за истину, если не обучен распознавать подделку.
Выводы и лучшие практики внедрения
Практика показывает: одного подхода недостаточно. Эффективная стратегия объединяет поиск, RAG, цепные рассуждения (CoT), контроль человеком (human-in-the-loop) и обучение с подкреплением на основе обратной связи (RLHF). Стандартизация взаимодействия через MCP позволяет сделать верификатор повторно используемым сервисом, а не жёстко зашитым этапом.
Для старта рекомендуется развернуть OpenFactCheck или GraphCheck — они дают опорную реализацию с открытым кодом. Затем внедрить метрики обоснованности и ссылочной достоверности из LangChain Evaluation Toolkit, чтобы оценить текущий уровень галлюцинаций. Верификатор нельзя рассматривать как разовую доработку: это наблюдаемый компонент пайплайна, требующий мониторинга и регулярного дообучения.
Предыдущая статья
