AI-агенты возвращают пустышки в красивом JSON: 6 ступеней валидации спасают от фальшивого «успеха»

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

Три состояния, которые нельзя смешивать

Ключевая идея разбора: между «запрос завершился» и «результатом можно пользоваться» лежат минимум три отдельных проверки. Вот что происходит, когда их сваливают в одну:

• «Запрос завершился» означает только то, что среда исполнения не упала. Агент не завис, процесс не прервался по тайм-ауту. Это говорит о здоровье инфраструктуры, не о качестве ответа.
• «Артефакт существует» означает, что в ответе есть структура и данные. JSON (формат обмена данными между программами) разобрался, обязательные поля на месте. Но внутри полей могут оказаться ссылки на файлы, которых никто не создал, или заглушки вроде «материал будет добавлен позже».
• «Результат принят» означает, что ответственный человек подтвердил соответствие исходной задаче. Только здесь появляется содержательная оценка.

Если все три сбоя записывать как одинаковый провал, отчёт не подскажет, что именно чинить: сломалась среда, формат, полнота результата или сама постановка задачи.

Что такое completion gate и зачем он нужен до оценки качества?

Completion gate (проверка завершённости артефакта, «ворота готовности») ставится перед любой содержательной оценкой. Его задача не решить, хороший ли документ, а установить, есть ли вообще что оценивать.

Проверки идут последовательно, каждая следующая запускается только после прохождения предыдущей:

1. Запрос завершился без тайм-аута и падения процесса.
2. В ответе есть содержимое.
3. Структуру можно разобрать.
4. Обязательные поля соответствуют контракту (заранее согласованной схеме ответа).
5. Ссылки и значения ведут к существующим непустым артефактам.
6. Эти артефакты не являются заглушками и не состоят из пустых разделов.

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

Такое разделение не позволяет техническому обрыву маскироваться под слабое понимание задачи, а правильной форме приниматься за готовый результат.

Почему «зелёный тест» врёт и что с этим делать?

Автоматическая проверка (чекер) полезна, но её границы должны быть видны. Вот реальные ловушки:

• Чекер подтверждает наличие четырёх заголовков и пропускает пустой текст под ними.
• Чекер требует точное слово и отклоняет равнозначную формулировку.
• Тесты написаны по устаревшей постановке. Агент выбрал старую версию требований, а тесты аккуратно проверили именно её.

Решение: хранить цепочку происхождения каждого правила и теста. Цепочка выглядит так: источник или решение, затем правило, затем пользовательский сценарий, затем тест или ручная проверка, затем доказательство реализации, затем пользовательская приёмка (UAT, то есть приёмочное тестирование конечным пользователем).

Если источник изменился, все связанные тесты становятся устаревшими. Старый «зелёный» результат нельзя автоматически переносить на новую версию контекста. Факт, который легко упустить, когда ИИ-агенты работают с быстро меняющейся документацией.

Несколько ИИ-агентов не равно независимая проверка

Несколько ИИ-агентов, которые пересказывают один и тот же набор сведений, не создают независимую проверку. Они могут просто быстрее прийти к общему заблуждению, галлюцинации (когда ИИ уверенно выдумывает то, чего не было).

Автор предлагает вести журнал покрытия свидетельств: какие факты уже представлены, какие повторяются, какие источники расходятся и какого свидетельства не хватает. Обсуждение заканчивается не после фиксированного числа реплик, а когда обязательные факты покрыты, а нерешённые конфликты вынесены владельцу решения.

При конфликте источников система должна сохранить обе версии, показать область расхождения и остановиться там, где нужно полномочие человека.

Что хранить в отчёте вместо одного процента успеха?

Вместо единственной метрики «процент успешных запусков» разбор предлагает фиксировать причину каждого исхода:

• Среда не завершила запрос.
• Ответ нельзя разобрать.
• Формат восстановлен внешним кодом.
• Полный артефакт не прошёл критерии.
• Результат отклонён человеком.
• Результат принят в согласованных границах.

Тогда команда видит, где находится следующее действие: в инфраструктуре, контракте, модели, проверке или постановке задачи.

Как попробовать на своих задачах?

1. Возьмите любую цепочку, где ИИ-агент выдаёт структурированный ответ (отчёт, документ, набор данных). Добавьте отдельный шаг проверки завершённости ДО содержательной оценки по шести ступеням выше.
2. Разделите лог результатов: не «успех/провал», а шесть категорий из раздела «Что хранить в отчёте». Посмотрите, какая категория сбоев доминирует.
3. Для каждого автоматического теста зафиксируйте, на какую версию требований он опирается. Если требования менялись, пометьте тест как устаревший и обновите до ручной перепроверки.
4. Перед финальной приёмкой убедитесь, что критерий появился до реализации, тест относится к исходному сценарию, а ограничения понятны тому, кто будет использовать результат.

Сравнение с инструментами, доступными в России

Подход из разбора не привязан к конкретному провайдеру и применим к любым ИИ-агентам, включая построенные на YandexGPT или GigaChat (крупнейшие закрытые модели, доступные в РФ). Если вы строите агентные цепочки на отечественных API, completion gate встраивается точно так же: между вызовом модели и содержательной проверкой. Специфика лишь в том, что у российских моделей пока меньше сторонних инструментов автоматической валидации, и тем важнее выстроить собственную многоступенчатую проверку.

Что делать с этим прямо сейчас, по ролям

ML-инженеру и разработчику. Внедрите completion gate как отдельный модуль между исполнением агента и оценкой качества. Шесть ступеней из разбора, готовый чеклист, который можно превратить в код за день.

Автору Дзена, который использует ИИ-агентов для контента. Не доверяйте статусу «задача выполнена». Проверяйте: файлы реально созданы, текст не заглушка, источники существуют. Если агент написал «материал будет добавлен позже», это не черновик, это пустышка.

Предпринимателю и менеджеру. Требуйте от команды раздельный отчёт по категориям сбоев, а не один процент. Иначе вы не узнаете, где проблема: в модели, которую надо менять, или в инфраструктуре, которую надо чинить.

Частые вопросы

Completion gate замедлит работу агента?

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

Нужен ли completion gate, если я использую одного агента для простых задач?

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

Как это соотносится с eval-фреймворками вроде тех, что есть у OpenAI?

Eval-фреймворки (инструменты оценки качества ответов модели) проверяют содержание: точность, полноту, соответствие эталону. Completion gate работает раньше: он отвечает на вопрос «есть ли вообще что оценивать». Эти уровни дополняют друг друга. Без gate eval-фреймворк может поставить низкую оценку артефакту, которого физически не существует, и вы будете чинить промпт вместо инфраструктуры.

Разделение «агент ответил» и «задача решена» звучит очевидно, пока не посмотришь в собственные логи и не обнаружишь, что половина «провалов» модели на самом деле провалы инфраструктуры, а половина «успехов» содержит красиво отформатированное ничего.