TL;DR
Исследователи изучали ИИ-агентов, которые работают с закрытыми базами данных — больницы, юридические фирмы, госструктуры — где нельзя слать данные во внешние API. Главный сбой в таких системах — не галлюцинация (когда модель придумывает факт), а её противоположность: умолчание — тихое исчезновение важного факта, который модель просто не увидела. Модель читает первые 20 записей из 400 и уверенно заявляет: «аномалий не найдено» — и этот ответ звучит убедительно именно потому, что он не выглядит как ошибка.
Главная находка: чем длиннее документ, тем резче растёт риск пропуска — при увеличении объёма текста с 2 до 32 тысяч токенов шансы что-то упустить увеличиваются в 7 раз. Ещё хуже, если искомый факт сформулирован не буквально — если нужно найти смысл, а не точное слово, шансы пропуска утраиваются. И большая часть таких потерь (68%) происходит вообще до того, как модель получает данные — на этапе загрузки, пагинации, обрезки текста системой.
Чтобы поймать пропуск, авторы предлагают не доверять красивому финальному ответу модели, а заставлять её явно отчитываться: сколько записей она реально обработала, привести цитату-источник для каждого факта, и заранее «подсадить» в данные контрольный маркер, который модель обязана заметить.
Схема метода
Это набор проверочных приёмов (не единый алгоритм), которые можно применять по отдельности или вместе:
ПРИЁМ 1 (canary injection): Вставь в документ уникальный "маячок" (код/фраза)
→ проверка, что модель реально прошла весь текст, а не только начало
ПРИЁМ 2 (coverage accounting): Попроси модель явно указать долю обработанных данных
→ "проверено X из Y записей" вместо тихого "аномалий не найдено"
ПРИЁМ 3 (forced citation): Требуй ссылку/цитату на источник для каждого вывода
→ привязка утверждения к конкретному месту в тексте, галлюцинацию видно сразу
ПРИЁМ 4 (two-pass cross-check): Прогони одну и ту же задачу два раза
→ сравни результаты, расхождение = сигнал ненадёжности
Все четыре приёма выполняются в обычном диалоге, без отдельных запросов к API — это формулировки внутри промпта.
Пример применения
Задача: Юрист загружает в Claude/ChatGPT 120-страничный договор поставки и просит найти все пункты про штрафы, неустойки и ответственность сторон — перед тем как подписывать.
Промпт:
Вот текст договора [вставляю документ].
Перед анализом: в тексте есть контрольная метка "ПУНКТ-QX77" —
подтверди, что ты её видел, и укажи, в каком разделе она находится.
Теперь найди все пункты про штрафы, неустойки, ответственность сторон.
Для каждого найденного пункта:
- укажи номер пункта/страницы, где он находится
- процитируй фразу целиком
В конце укажи: сколько всего пунктов в договоре ты просмотрел
(из общего количества пунктов документа), и есть ли разделы,
которые ты не смог прочитать полностью.
Результат: Модель сначала подтвердит (или не найдёт) контрольную метку — если не найдёт, вы сразу узнаете, что часть текста «выпала» из обработки. Дальше — список пунктов с цитатами и номерами (не абстрактный пересказ). В конце — честный отчёт о покрытии: «просмотрено 45 из 60 пунктов» вместо молчаливого «больше ничего не нашёл».
Почему это работает
Модели физически не умеют сказать «я не уверена, что видела весь текст» — они всегда выдают гладкий, законченный ответ, даже если внутри контекста часть данных потерялась (обрезалась, ушла в середину длинного текста, была отфильтрована системой заранее). Это и есть слабость: уверенный тон ответа никак не связан с тем, сколько данных модель реально обработала.
Сильная сторона модели — она честно отвечает, если её явно просят посчитать и процитировать. Модель хорошо считает и цитирует, когда получает точную инструкцию с чёткими требованиями к формату вывода.
Метод обходит слабость, превращая невидимую проблему в видимую: вместо того чтобы верить финальному «аномалий нет», вы заставляете модель показать механику — сколько прочитано, откуда взят каждый факт, совпадает ли контрольная метка. Пропуск, который раньше был незаметен, становится измеримым числом.
Рычаги управления: - Контрольная метка — меняйте её сложность (просто слово → редкий код) для более жёсткой проверки внимательности модели - Требование цитаты — можно убрать для скорости, но тогда теряется способ проверить, не придумала ли модель источник - Coverage accounting — особенно критичен при работе с длинными списками (базы данных, реестры, множество файлов) — везде, где легко «прочитать только начало» - Two-pass cross-check — увеличивает затраты времени вдвое, но незаменим для задач с высокой ценой ошибки (юридический due diligence, медицинские записи)
Шаблон промпта
Вот документ: {текст/файл}
Перед анализом: подтверди, что ты видел контрольную метку
"{уникальный_код}" в тексте, и укажи, где она находится.
Задача: {что нужно найти или проанализировать}
Для каждого найденного элемента укажи:
- точное место в документе (номер страницы/раздела/пункта)
- цитату из оригинала
В конце обязательно укажи:
- сколько частей документа (страниц/пунктов/записей) ты реально обработал
из общего количества {N}
- есть ли части, которые не удалось прочитать полностью
Перед вставкой в реальный документ добавьте в текст сам контрольный код — любую редкую фразу, которую легко искать (например, "МАРКЕР-KX92Q"), в произвольном месте.
🚀 Быстрый старт — вставь в чат:
Вот шаблон для проверки, не упустил ли ИИ важные факты при анализе большого документа.
Адаптируй под мою задачу: {твоя задача}.
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит, какой документ анализировать, что именно искать и какой формат отчёта нужен — потому что без этих деталей приём coverage accounting не сработает: модели нужно точно знать, что считать «единицей покрытия» (страницы? пункты? записи?).
Ограничения
⚠️ Не работает без явного текста для проверки: если документ передаётся не текстом, а через встроенный поиск по базе (RAG, инструменты), модель может не видеть весь массив данных физически — никакая формулировка промпта это не исправит, проблема на стороне системы, а не диалога.
⚠️ Доступ к «внутренностям» модели недоступен в обычном чате: самый точный приём из исследования — анализ вероятностей токенов (logit-декомпозиция), который отличает «модель пропустила отбор» от «модель не увидела факт» — работает только через локальный запуск моделей с доступом к API-логам, не в веб-интерфейсе ChatGPT/Claude.
⚠️ Технические слои (квантование, кэш, архитектура внимания) не переносятся на чат: большая часть выводов статьи касается инфраструктуры серверов, на которых крутится ИИ — это не то, что пользователь контролирует в диалоге.
Ресурсы
Santhiya Rajan (Multiverse Computing) — «Where Facts Go Missing: A Layerwise Taxonomy and Per-Layer Attribution of Information Omission in Air-Gapped LLM Agent Pipelines». Ключевые отсылки: понятие «lost in the middle» (Liu et al. 2024), устойчивость приоритетов модели при конфликте с контекстом (NQ-Swap, ConflictBank, ClashEval).