Но модель прочитала только первые 20 записей из 400. Главная опасность при работе ИИ-агентов с изолированными базами (больницы, юрфирмы, госструктуры) — не галлюцинация (выдуманный факт), а умолчание: модель просто не замечает важную информацию в длинном документе и уверенно рапортует об отсутствии проблем. Ключевые цифры из исследования (Santhiya Rajan, Multiverse Computing): При увеличении текста с 2 до 32 тыс. токенов риск пропуска факта растёт в 7 раз. Если нужный факт выражен не буквально, а по смыслу, шансы пропуска утраиваются. 68% потерь происходят ещё до обработки модели — на этапе загрузки, пагинации, обрезки текста системой. Почему модель молчит? LLM не умеют признаваться в неполноте прочтения — они всегда выдают гладкий финальный ответ, даже если внутри контекста часть данных «выпала». И это не ошибка генерации, а системный сбой: модель просто не видит дальше первых абзацев или середины длинного списка. 4 приёма, чтобы поймать пропуск (работают в обычном чате без API) Canary injection («подсадная утка») Вставьте в документ уникальный маркер (например, ПУНКТ-ОХ77) в произвольное место. Попросите модель подтвердить, что она его видела, и указать раздел. Если маркер не найден — вы точно знаете, что часть текста не обработана. Coverage accounting (отчёт о покрытии) Требуйте явного указания: «проверено X из Y записей» вместо молчаливого «аномалий не найдено». Модель честно скажет, сколько она реально просмотрела. Forced citation (принудительное цитирование) Для каждого утверждения требуйте точную цитату и номер страницы/пункта. Это привязывает вывод к конкретному месту в тексте — галлюцинацию видно сразу. Two-pass cross-check (двойной прогон) Прогоните задачу дважды и сравните результаты. Расхождения — явный сигнал ненадёжности. Пример: юрист проверяет 120-страничный договор Промпт (сокращённо): «Перед анализом подтверди, что ты видел контрольную метку “ПУНКТ-ОХ77” и укажи, где она находится. Найди все пункты про штрафы и неустойки. Для каждого приведи цитату и номер пункта. В конце укажи: сколько всего пунктов ты просмотрел из общего количества, и есть ли разделы, которые не смог прочитать полностью». Результат: модель либо находит метку (значит, прошла весь текст), либо нет — и вы сразу понимаете, что часть данных «выпала». Список штрафов с цитатами и номерами — вместо абстрактного пересказа. А отчёт о покрытии показывает, сколько реально обработано. Почему это работает? LLM отлично справляются с конкретными инструкциями: «посчитай», «процитируй», «найди маркер». Но они не умеют сигналить о своей неполноте, если их не попросить явно. Метод превращает невидимую проблему в измеримую: вместо слепой веры финальному ответу вы заставляете модель показать механику — сколько прочитано, откуда взят каждый факт, совпадает ли контрольная метка. ⚠️ Важные ограничения. Приёмы не работают, если документ передаётся через встроенный поиск (RAG) или инструменты, где модель физически не видит весь массив — проблема на уровне системы, а не промпта. Самый точный метод (анализ вероятностей токенов) доступен только при локальном запуске с доступом к логам, не в веб-чате. Технические слои (квантование, кэш, архитектура внимания) — это инфраструктура серверов, пользователь в диалоге их не контролирует. Главный вывод: не доверяйте красивым отчётам «всё чисто». Всегда требуйте от модели подтверждения полноты прочтения + ссылки на источник + двойной прогон для критических решений. Один простой маркер в тексте может спасти от пропуска важнейшего пункта договора или медицинского противопоказания. 📌 Шаблон (адаптируйте под свою задачу): «Вот документ: {текст}. Перед анализом подтверди наличие контрольной метки “{уникальный_код}” и укажи её расположение. Задача: {что ищем}. Для каждого найденного элемента дай цитату и точное место. В конце укажи, сколько частей документа реально обработано из общего числа {N}, и есть ли непрочитанные участки». arXiv:2607.22448