Completion не доказывает качество результата AI-агента

AI-агент может завершить запуск, вернуть корректный JSON и пройти автоматическую проверку. При этом у команды может не быть результата, которым можно пользоваться.

Это не парадокс, а смешение разных состояний. «Запрос завершился» говорит о работе среды. «Артефакт существует» говорит о наличии материала. «Результат принят» означает, что ответственный человек подтвердил соответствие исходной задаче. Между этими состояниями нужны отдельные проверки.

Формат не равен содержанию

Представим задачу, в которой агент должен подготовить карту источников, описание системы, список противоречий и постановку для разработки. Контракт ответа требует четыре поля. Агент возвращает их, и JSON успешно разбирается.

Но внутри полей могут оказаться пути к файлам, которые никто не создал:

• source_map: output/source_map.md;

• system_context: output/system_context.md;

• findings: output/findings.md;

• task_pack: output/task_pack.md.

Схема проверена, а документы отсутствуют. Другой запуск может вернуть заголовки и фразы вроде «материал будет добавлен позже». Текст непустой, но артефакта нет. Ещё один запуск может оборваться после подготовки части пакета из-за ограничения среды.

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

Completion gate должен стоять до оценки качества

Перед проверкой содержания я использую отдельный completion gate, то есть проверку завершённости артефакта. Его задача не в том, чтобы решить, хороший ли документ. Он должен установить, есть ли что оценивать.

Проверки идут последовательно:

1. Запрос завершился без тайм-аута и падения процесса.

2. В ответе есть содержимое.

3. Структуру можно разобрать.

4. Обязательные поля соответствуют контракту.

5. Возвращённые значения или ссылки ведут к существующим непустым артефактам.

6. Эти артефакты не являются заглушками и не состоят из пустых разделов.

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

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

Зелёный тест проверяет только свой вопрос

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

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

Поэтому цепочка должна хранить происхождение:

источник или решение → правило → пользовательский сценарий → тест или ручная проверка → доказательство реализации → пользовательская приёмка (UAT).

Если источник или решение изменились, связанные правила, сценарии и тесты становятся устаревшими. Старый зелёный результат нельзя автоматически переносить на новую версию контекста.

Независимость важнее количества агентов

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

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

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

Текстовый пересказ не заменяет исходный артефакт

Требование может прийти из скриншота, записи разговора, видео или состояния интерфейса. Транскрипция полезна для поиска, но остаётся производным представлением.

Для проверки нужны:

• исходный артефакт;

• точный указатель на фрагмент;

• производное описание;

• способ преобразования;

• известные потери.

Если требование звучит как «пользователь видит подтверждение сохранения», одного теста API недостаточно. Нужно проверить наблюдаемое состояние интерфейса. Если решение извлечено из видео, финальная проверка должна вести обратно к временному фрагменту оригинала.

Автор не должен единолично принимать результат

Агент может подготовить решение, изменить формат и объяснить, почему тест прошёл. Но он не должен одновременно быть единственным автором результата, автором критерия и органом выпуска.

Перед приёмкой человек проверяет:

• критерий появился до реализации;

• тест относится к исходному сценарию;

• ремонты и отклонения видны;

• ограничения понятны тому, кто будет использовать результат;

• остаточный риск принял именованный владелец.

Это не отказ от автоматизации. Исполнитель, детерминированные проверки и человеческая приёмка отвечают на разные вопросы.

Что хранить в отчёте

Вместо одного процента успеха полезно разделять причины:

• среда не завершила запрос;

• ответ нельзя разобрать;

• формат восстановлен внешним кодом;

• полный артефакт не прошёл критерии;

• результат отклонён человеком;

• результат принят в согласованных границах.

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

Completion gate не делает модель умнее и не оценивает качество содержания. Он не позволяет спутать отсутствие целого проверяемого артефакта с плохим результатом и формально правильный объект с завершённой работой. Сначала система должна произвести целый артефакт. Затем внешний код проверяет согласованные свойства. После этого человек решает, можно ли использовать результат.