TL;DR
Верификационная инерция — это режим, в котором AI-агент с поиском находит правильные исходные данные, но останавливается раньше, чем их проверит. Он встречает «ответоподобный» документ — красиво написанное резюме, дашборд, вторичная статья — и принимает его как достаточное доказательство. Настоящие записи лежат рядом, но агент до них не добирается.
Боль конкретная: при добавлении одного правдоподобного фальшивого документа точность лучших моделей падает с 88–96% до 1–26%. При этом агент уже нашёл правильные данные — он просто не доделал работу. Число поисковых запросов сокращается с 7 до 4–5: агент «успокоился» раньше времени. Результат — уверенный, хорошо оформленный и неправильный ответ со ссылкой на источник.
Принцип защиты: явно запретить модели останавливаться на summary-документах и потребовать сверки с первичными записями. Универсальная инструкция «проверь тщательнее» сокращает ошибки, но не устраняет. Работает лучше: структурное указание _что именно_ верифицировать и _против чего_.
Схема провала и защиты
СТАНДАРТНЫЙ ЗАПРОС (опасно):
"Найди данные о X" → агент ищет → встречает резюме/сводку →
принимает как ответ → даёт уверенный неправильный ответ
-------------------------------------------------
ЗАЩИЩЁННЫЙ ЗАПРОС (безопасно):
ШАГ 1: Ищи → собирай первичные источники (записи, первоисточники, не резюме)
ШАГ 2: Treat summaries as claims → проверь каждый вывод против записей
ШАГ 3: Reconcile → если источники противоречат — сообщи, не скрывай
ШАГ 4: Только тогда — финальный ответ
Всё работает в одном промпте.
Пример применения
Задача: Ты готовишься к переговорам и просишь Claude/ChatGPT с поиском узнать финансовые условия последнего раунда инвестиций Wildberries — хочешь понять оценку компании.
Что происходит без защиты:
В сети есть десятки статей-резюме с округлёнными цифрами, пересказами друг друга и устаревшими данными. Агент найдёт одну такую — «WB привлёк инвестиции при оценке X млрд» — и остановится. Ответ будет уверенным, с ссылкой, и вполне может быть неточным.
Промпт с защитой:
Найди данные о последнем раунде инвестиций Wildberries:
сумму, оценку компании, инвесторов.
Важные правила поиска:
1. Не останавливайся на первом найденном резюме или новостной сводке —
это может быть пересказ пересказа
2. Ищи первичные источники: официальные пресс-релизы компании,
раскрытия регулятору, прямые цитаты основателей или инвесторов
3. Любой secondary-источник (статья, аналитика, дашборд) —
считай утверждением, которое нужно проверить против первоисточника
4. Если источники противоречат друг другу — покажи противоречие явно,
не выбирай сам "наиболее вероятное"
5. Если первичных данных нет — так и скажи, не компенсируй резюме-статьями
Итог: список источников с указанием типа (первичный / вторичный)
и финальный ответ только на основе первичных.
Результат: Модель выдаст несколько раундов поиска с явным различением типов источников. Если первичных данных нет — честно сообщит об этом вместо уверенного ответа на основе вторички. Если противоречия есть — покажет их.
Почему это работает
Слабость модели — это не незнание, а преждевременное завершение. Исследование показало: в 100% случаев агент _находил_ правильные данные. Просто останавливался раньше. Summary-документ выглядит как «ответ» — он написан как ответ, структурирован как ответ, стоит в начале выдачи. Модель следует паттерну «нашёл ответ → стоп».
Модель хорошо умеет следовать явным инструкциям о процессе. Если описать _как_ искать, а не _что_ найти — модель меняет поведение. Она не умеет самостоятельно подозревать источники. Но умеет применять правило «резюме = утверждение, требующее проверки», если это правило задано явно.
Как метод использует это: Мы не просим «найди правду» (абстрактно). Мы задаём операционный протокол: разграничь типы источников, продолжай поиск после первого «ответа», вынеси противоречия наружу. Это убирает двусмысленность — у агента нет способа интерпретировать инструкцию как «остановись на резюме».
Рычаги управления: - "Покажи противоречия явно" → убирает риск, что модель сама выберет "наиболее вероятное" среди конфликтующих данных - Список типов источников в конце → заставляет модель классифицировать, а не просто цитировать - "Если первичных данных нет — так и скажи" → предотвращает компенсацию вторичкой - Количество поисковых запросов можно указать явно → "сделай минимум 5 поисков" даёт больше глубины
Шаблон промпта
{задача_поиска}
Правила работы с источниками:
1. Не останавливайся на первом резюме, сводке или новости —
ищи первичные источники: официальные документы, пресс-релизы,
прямые раскрытия
2. Любой вторичный источник (статья, аналитика, дашборд, обзор) —
считай утверждением, которое нужно проверить против первичных записей
3. Если источники противоречат — покажи противоречие явно,
не выбирай "наиболее вероятное" самостоятельно
4. Если первичных данных недостаточно — так и скажи прямо
Формат ответа:
- Перечисли найденные источники с типом:
[первичный / вторичный / неизвестно]
- Финальный вывод — только на основе первичных источников
- Если уверенности нет — укажи уровень уверенности и почему
Плейсхолдеры:
- {задача_поиска} — конкретный вопрос: "Найди финансовые условия...", "Проверь утверждение...", "Узнай актуальные данные о..."
🚀 Быстрый старт — вставь в чат:
Вот шаблон для защищённого поиска с верификацией источников.
Адаптируй под мою задачу: {твоя задача}.
Задавай уточняющие вопросы, если нужно.
[вставить шаблон выше]
LLM спросит о типе данных и приоритете источников — потому что от этого зависит что считать «первичным» в конкретной теме.
Ограничения
⚠️ Частичное решение: Явные инструкции верификации уменьшают проблему, но не устраняют полностью. Даже с лучшими промптами часть случаев проходит сквозь защиту.
⚠️ Зависит от интерфейса поиска: Принцип работает в Claude/ChatGPT с поиском, Perplexity и аналогах. В обычном чате без поиска — нет смысла.
⚠️ Чем «ответоподобнее» фальшь — тем хуже: Если неверный документ хорошо написан и имитирует официальный стиль, даже защита не гарантирует результат. Структурные вмешательства (облегчение доступа к верным данным) работают лучше, чем промпт-инструкции — но это уже не в руках пользователя.
⚠️ Модели различаются: Gemini держится лучше остальных (26% точность при зашумлении vs 1% у DeepSeek и MiMo). Выбор модели влияет на устойчивость к этой проблеме.
Как исследовали
Идея была жёсткой в своей простоте: взять 100 задач, где правильный ответ нельзя найти в одном документе — его нужно восстановить из нескольких косвенных записей. Затем добавить один обычный с виду документ, который прямо называет неверный ответ, — и посмотреть что изменится.
Команда тестировала пять топовых моделей (DeepSeek V4 Flash, MiMo v2.5, Qwen3-32B, Gemini 3.5 Flash, GPT-5.4) на одинаковом фреймворке поиска. Каждую модель прогнали по всем 100 задачам дважды: без фальшивого документа и с ним. Разница оказалась катастрофической — у DeepSeek и MiMo точность упала с ~88–82% до 1%.
Что особенно важно: исследователи заглянули в трассы поиска GPT-5.4 и обнаружили — модель в 100% случаев находила правильные данные. Но в чистом режиме делала в среднем 7 поисков, а в зашумлённом — 4,5. Фальшивый документ буквально укорачивал поиск. В 77 из 88 неправильных ответов модель остановилась с неполным набором правильных данных на руках. Это подтвердило: проблема не в способности найти правду — проблема в том, что модель не доходит до неё.
Оригинал из исследования
Task instance from DRNOISE (entity selection):
Question: Which supplier both held a current safety certification on
31 March 2024 and delivered all three of its March shipments on time?
Route EA: Approved-vendor directory, certification-expiry entries, and
three shipment schedule/arrival records; the answer follows by joining
vendor identifiers to certification state and on-time delivery.
Route EB: A second, corroborating chain of accounts-payable and
gate-punctuality records that reaches the same answer. Neither route
contains a sentence naming "the supplier that met both criteria."
False summary (noisy condition only): A short trade-publication review
naming a different supplier as meeting both conditions—unsupported by,
and in fact refuted by, the records.
Gold answer: Brindle Components
Designated false: Orison Fabrication
Контекст: Это пример задачи из бенчмарка — показывает как устроена «ловушка». Правильный ответ (Brindle Components) нигде не написан явно, нужно вывести из нескольких записей. Фальшивый документ называет конкурента прямо и уверенно.
Адаптации и экстраполяции
💡 Адаптация: «Красный флаг на summary-документы»
Когда результат важный — добавь явный запрос на классификацию источников:
После поиска, перед финальным ответом:
- Перечисли все найденные источники
- Отметь каждый: [первичный документ] / [вторичное резюме] / [новость/пересказ]
- Если финальный ответ основан на вторичном источнике —
предупреди об этом явно
🔧 Техника: Заставь модель продолжать поиск
Проблема — агент останавливается рано. Явно задай минимум итераций:
Сделай минимум 6-8 поисковых запросов прежде чем давать финальный ответ.
Первые 2-3 — широкий поиск. Следующие 3-4 — верификация найденного
против первоисточников. Последний — проверка противоречий.
🔧 Техника: Adversarial framing
Переформулируй задачу как «найти и разоблачить», а не «найти ответ»:
Задача: {вопрос}
Подходи к этому как скептик: предположи что первый найденный "ответ"
может быть неверным. Твоя цель — найти опровергающие или
подтверждающие первичные записи, а не принять первое правдоподобное утверждение.
Ресурсы
DRNOISE: Benchmarking Deep Research Agents in Misleading Evidence Environments — Preprint
Авторы: Jun Nie, Zhiqin Yang, Zhenheng Tang, Yonggang Zhang, Xiaowen Chu, Xinmei Tian, Bo Han
Университеты: Hong Kong Baptist University, University of Science and Technology of China, The Hong Kong University of Science and Technology
Смежные работы упомянутые в статье: GAIA benchmark, BrowseComp, WebWalker, InteractComp, PoisonedRAG, ReAct framework