Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Финальный ответ ИИ-агента нужно проверять отдельно от результата его работы: выполненная задача ещё не означает, что человек поймёт отчёт. Хотя препринт не рецензирован и числа получили сами авторы, непригодными оказались 54% проверенных ответов. Явные требования к финальному сообщению или отдельное переписывание снижают риск без перестройки самого агента.
Как отделили пригодность ответа от успеха задачи
Работа вводит отдельное свойство — пригодность ответа для заказчика. Ответ считается пригодным, если его можно понять по переписке и файлам, которые видел заказчик, если он написан на нужном языке и прямо отвечает на последний запрос.
Это не то же самое, что успешное выполнение задачи. Агент может правильно изменить код, провести расчёты или собрать источники, а затем сослаться на внутреннее имя эксперимента, номер документа из своей памяти или результат, который остался только в выводе инструмента. Отчёт будет верным, но человеку придётся запрашивать расшифровку или изучать рабочие записи агента.
Для проверки использовали модель-читателя Gemini 3 Flash. Она видит только доступный заказчику контекст, выделяет фрагменты, которые требуют пояснений, формулирует по ним вопросы и ищет в ответе дословные основания для ответа. Если объяснения нет, модель отмечает информационный разрыв.
Отдельная модель-проверяющий получает уже весь журнал работы: вызовы инструментов, их результаты, заметки и память проекта. Она ищет фактические ошибки и пропущенные результаты. Такое разделение не позволяет принять понятный, но искажённый пересказ за качественный ответ.
Вердикты модели-читателя сопоставили с человеческой разметкой. Её согласие с мнением большинства оказалось на уровне отдельного разметчика, поэтому такой тест можно использовать как автоматическую метрику наряду с успешностью задачи и точностью отчёта.
Внутренние обозначения делают верный отчёт бесполезным
Проверка охватила восемь моделей из семи семейств, включая закрытые и модели с открытыми весами. Они работали в многоэтапных исследовательских и бизнес-сценариях на английском и китайском языках. Проекты были синтетическими и проходили по заданному сценарию, а заказчик знал предметную область, но не видел внутреннюю работу агента.
Непригодными признали 54% ответов, а у лучшей модели доля сбоев всё равно составила 30%. В группе сообщений, написанных после самой длинной работы с инструментами, показатель доходил до 70%. Проблема проявилась во всех проверенных семействах и не зависела от того, доступны ли веса модели.
Главная причина — словарь, который агент создаёт во время работы и затем ошибочно считает общим. В одном ответе появились ссылки R07 и R09, а также параметр reader_size: 70B. Для агента они были понятны из прочитанных статей и запусков, но заказчик этих обозначений раньше не видел.
Другие ответы перечисляли внесённые изменения, но не сообщали запрошенный итог, либо переключались на другой язык. Чем больше инструментов, файлов и сжатий контекста участвует в задаче, тем больше внутренних имён может просочиться в финальное сообщение.
Что менять в архитектуре агента
Первый шаг не требует нового контура или дополнительного вызова модели. Перед финальным ответом агенту явно указывают: ответить на последний запрос, расшифровать внутренние названия, заменить ссылки на скрытые материалы их содержанием и использовать язык заказчика.
На точках, где сравнивали способы подготовки сообщения, такие требования снизили долю непригодных ответов с 52% до 43%. Простое напоминание о том, что заказчик не видел рабочий процесс, измеримого эффекта не дало. Отдельный этап написания с теми же требованиями тоже не улучшил результат по сравнению с инструкцией в текущем контексте.
Если основной запрос агента изменить нельзя, готовое сообщение можно передать второй модели вместе с запросом и журналом работы. Переписывание снизило долю сбоев до 36%; слепое сравнение людьми подтвердило результат. Одновременно стало меньше фактических ошибок и пропусков, то есть более понятная формулировка не потребовала жертвовать точностью.
Для продуктовой команды это означает, что проверка завершённой задачи не должна заканчиваться состоянием среды или успешным вызовом API. В набор регрессионных тестов стоит добавить представление заказчика: модель-оценщик должна видеть только его сообщения, переданные им файлы и предыдущие ответы агента. При найденном разрыве система может повторить генерацию или отправить сообщение на переписывание.
Такой контроль в первую очередь меняет планы команд, которые строят агентов с инструментами, рабочими файлами, памятью и сжатием длинного контекста. Для коротких ответов без скрытой истории работа даёт меньше оснований менять архитектуру. Проверка нескольких вариантов исследована только на одной модели с открытыми весами, поэтому этот способ ещё нельзя переносить на все стеки как общий результат.
В работе не указана денежная стоимость дополнительного вызова, поэтому переписывание нужно считать по цене и задержке выбранной модели. Добавленная инструкция обходится без такого вызова и выглядит базовой мерой, после которой уже можно оценивать пользу отдельного редактора.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
