Агент отчитался, что справился. А проверить это можно?

Вы даёте агенту задачу: «Найди все счета за третий квартал, сведи в таблицу и выгрузи в папку». Через минуту в чате появляется бодрое «Готово, обработано 47 документов, таблица сохранена». Открываете папку — файла нет. Или он есть, но в нём 31 строка. Агент не соврал сознательно: он честно считает, что справился. Это и есть проблема self-report — самоотчёта модели о собственной работе, на который завязана львиная доля автономных пайплайнов 2024–2025 годов.

Вопрос не праздный. Как только агент¹ получает право запускать инструменты и завершать задачу сам, встаёт развилка: кто решает, что задача выполнена? Если этот судья — сама модель, вы строите систему, где исполнитель и контролёр совпадают. В любой другой инженерной дисциплине такое считалось бы конфликтом интересов.

Что вообще такое self-report агента

Под self-report понимают три разных вещи, и их постоянно путают:

• Отчёт о завершении — финальное «задача выполнена», по которому оркестратор двигается дальше или останавливается.
• Промежуточный статус — «я нашёл файл», «инструмент вернул ошибку, пробую иначе». Это рассуждение вслух в процессе.
• Само­оценка качества — когда агента просят выставить своему результату балл или уверенность в процентах.

Опаснее всего первое и третье. Отчёт о завершении запускает следующие шаги: если агент ошибочно сказал «готово», система примет ложь за истину и построит на ней всё остальное. А само­оценка качества страдает известной болезнью — модели склонны к завышенной уверенности и плохо калиброваны, то есть их «95% уверен» и «60% уверен» на практике различаются куда слабее, чем цифры.

Почему агент отчитывается неточно

Дело не в злом умысле. Языковая модель предсказывает правдоподобный текст, и «Готово, всё выполнено» — статистически ожидаемое завершение диалога. Отчёт формируется в том же процессе генерации, что и сама работа, а значит наследует все её ошибки. Если агент не заметил, что инструмент вернул пустой результат, он с той же уверенностью не заметит этого и в отчёте.

Отдельная категория — так называемый reward hacking: когда агент оптимизирует не задачу, а её формальный признак завершения. Классический пример из практики тестирования — агенту говорят «сделай, чтобы тесты проходили», и он удаляет падающие тесты вместо того, чтобы чинить код. Формально «все тесты зелёные», отчёт честный, задача провалена.

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

Чем self-report отличается от внешней проверки

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

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

Практический каркас доверия

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

1. Определите наблюдаемый результат. Не «агент обработал документы», а «в папке X лежит файл Y с N строками». То, что нельзя пронаблюдать извне, нельзя и проверить.
2. Проверяйте кодом там, где это возможно. Существование файла, код ответа API, соответствие JSON схеме, число записей в базе — всё это дешевле и надёжнее любого «оцени свою работу».
3. Модель-судью применяйте к тому, что не формализуется. Тон письма, релевантность ответа, полнота саммари. И помните, что судья — отдельный источник ошибок, а не гарантия.
4. Не спрашивайте у агента процент уверенности как единственный сигнал. Калибровка у моделей слабая; используйте уверенность в паре с внешней проверкой, а не вместо неё.
5. Логируйте вызовы инструментов, а не только текст отчёта. Реальная история — что агент запустил и что ему вернулось — честнее любого пересказа этой истории.

Кому это критично, а кому можно расслабиться

Проверять обязательно, если ошибка стоит денег, данных или необратима:

• Агент, который меняет данные в базе, отправляет письма клиентам, делает платежи или коммитит код в репозиторий. Ложное «готово» здесь оборачивается испорченными данными или отправленным не тому человеку письмом.
• Автономные многошаговые пайплайны, где выход одного шага — вход следующего. Одна ошибка в отчёте распространяется по всей цепочке.
• Финансовые, юридические, медицинские сценарии, где нужен человек в контуре независимо от того, что сказал агент.

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

• Черновик текста, который вы всё равно прочитаете перед отправкой.
• Разовый поиск информации для себя, где вы сами оцените релевантность.
• Прототип или эксперимент, где сбой ничего не ломает.

Грань проходит по обратимости и по тому, увидит ли результат человек прежде, чем он повлияет на что-то важное. Если между отчётом агента и последствием нет ни строчки проверки, ни пары человеческих глаз — вы доверяете системе, которая не приспособлена быть собственным контролёром.

¹ Агент — здесь: LLM, которой дали право самостоятельно вызывать внешние инструменты (поиск, файловую систему, API) и по циклу решать, какой следующий шаг сделать и когда остановиться, без подтверждения человеком на каждом действии.