Как уменьшить галлюцинации: от ответа к проверяемому результату

Агент сказал «готово». Что произошло?

Представим агента, который пишет: «Все проверки прошли, изменение можно выпускать». Ссылка ведёт на настоящий отчёт. Но отчёт относится к предыдущему коммиту, часть проверок не запускалась, а разрешение на выпуск вообще не выдавалось. Текст звучит убедительно. Его практический вывод не подтверждён.

В этом примере несколько разных проблем. Выдуманный результат проверки — неподтверждённое утверждение. Применение старого отчёта к новому коду — ошибка применимости. Подмена проверки разрешением — ошибка полномочий. Их полезно проверять отдельно: единая оценка «агент надёжен» скрывает место разрыва.

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

Поиск источников — первый слой

В работе Lewis et al. о Retrieval-Augmented Generation модель использует извлечённые документы вместе с параметрической памятью. На исследованных авторами задачах генерация оказалась фактичнее выбранного baseline. Это поддерживает использование внешних источников, но не обещает истинности каждого ответа любого RAG-приложения. [S1]

FActScore предлагает разбивать длинный ответ на атомарные факты и оценивать, какая их доля поддержана надёжным источником. Для наших задач отсюда полезен принцип: проверять каждое существенное утверждение отдельно. Результат старого исследования нельзя переносить на сегодняшнюю модель или наш набор репозиториев. [S2]

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

Четыре репозитория, четыре вопроса

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

Что должно сопровождать утверждение

Для первого прототипа достаточно одного небольшого реестра утверждений. Это предлагаемый формат интеграции, а не действующий API всех четырёх проектов.

Сначала система получает данные и сохраняет их версию. Затем разбивает ответ на проверяемые утверждения и сопоставляет каждое с доказательством. Перед действием повторно проверяет объект, время, условия и полномочия. После действия фиксирует результат или оставляет его UNKNOWN.

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

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

Что воспроизведено сейчас

6 сентября 2026 года мы запустили существующий пример согласований CML и четыре существующие фикстуры CGQA. Версии закреплены коммитами, входы и полный вывод сохранены. Предварительные ожидания записаны до запуска. Два последовательных вычисления дали одинаковый результат. [S7]

Итого: 6 из 6 заранее заданных классификаций совпали. Три негативных случая были обнаружены, три положительных прошли. Это проверка различающей способности правил на выбранных примерах. LLM не вызывалась, реальные инструменты и платежи не исполнялись. Поэтому «6 из 6» нельзя превращать в «галлюцинации устранены» или процент эффективности в эксплуатации.

Особенно важная граница: CML и CGQA в этом прогоне обнаруживают проблему в предоставленной трассе после её построения. Чтобы остановить будущий вызов, их результат ещё нужно корректно связать с исполнителем.

Как повторить

Из checkout RESONANCE, содержащего эту статью, получите две закреплённые версии исходников. Среда выполненного прогона: Linux, Python 3.12.13, PyYAML 6.0.3. Единственная внешняя Python-зависимость этого примера — PyYAML; установите её в своё виртуальное окружение. Сам replay работает локально.

git clone https://github.com/safal207/Causal-Memory-Layer.git ../cml-article016
git -C ../cml-article016 checkout 7a3a98c60a402d394e4d286da956823898454b8a
git clone https://github.com/safal207/ContractGraph-QA.git ../cgqa-article016
git -C ../cgqa-article016 checkout f861b934d77e64fd35f768e2a33bb4a00963bc19
python -m pip install PyYAML==6.0.3
python scripts/reproduce-article016.py --cml ../cml-article016 --cgqa ../cgqa-article016 --output article016-replay.json

Ожидаемые поля: matched_cases = 6, repeat_equal = true. SHA-256 канонического массива результатов: 7a391291204b358bc1c2323186d981e1d993d1d86ef91d7dcf509a361d6e7ff1. Полный файл также содержит версии среды, хеши Python-исходников, исходные события и нативные диагностические результаты. Это локальное авторское воспроизведение; независимая внешняя репликация не заявляется.

Как измерить именно снижение ошибок

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

Сравним три режима: модель с обычным запросом; та же модель с поиском; тот же поиск и те же найденные документы плюс реестр утверждений и явные проверки. Для двух последних режимов зафиксируем общий набор доказательств. Версию модели, настройки, запросы, доступные инструменты и лимиты сохраним; каждую задачу выполним три раза. Получится 90 прогонов на режим. Порядок режимов перемешаем, ответы оценим без указания режима.

UNKNOWN учитывается как воздержание, а не как фактическая ошибка. При нуле принятых утверждений первая доля не определена, а не равна нулю. Система, которая отказывает на всё, не выигрывает эксперимент. Нужно показать исходные количества, раздельные результаты по пяти группам и разброс между задачами; повторы одной задачи не считать независимыми задачами.

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

Первый полезный шаг

Начать можно с одного сценария: агент читает CI-артефакты закреплённого коммита и готовит отчёт. Он должен различать «проверка прошла», «проверка не запускалась» и «отчёт относится к другой версии». Результат — таблица утверждений со ссылками и один обоснованный следующий шаг. После проверки такого прототипа можно отдельно добавить допуск к инструменту и наблюдение результата.

Наш практический ориентир: каждое существенное утверждение должно иметь проверяемое основание; каждое действие — актуальные условия допуска; каждый заявленный результат — наблюдение. Возможность спокойно сказать «этого мы ещё не знаем» здесь является полезной функцией продукта.

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