Как проверять AI-агента: результат, среда и цена неудачной попытки

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

Docker 14 октября объявил интеграцию Harbor и Sandboxes. В центре анонса изолированная среда выполнения и управляемый сетевой доступ; стабильный релиз был намечен на 23 октября. Expo 8 октября описала проверку обнаружения и применения skills. NVIDIA 14 октября разобрала верификацию инженерных артефактов Siemens. В опубликованном в тот же день кейсе OpenAI о Third Moment Research существенную роль играют анализ траекторий и решение о повторе или эскалации незавершённой задачи. Это сведения авторов, а не результаты наших испытаний.

Три разных причины одинакового провала

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

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

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

Повтор иногда дороже смены модели

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

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

Условный пример: извлечение строк из документов

Это проектный сценарий, не клиентский результат. Команда поручает агенту извлекать позиции заказа из PDF в согласованный JSON. В наборе есть читаемый документ, скан, таблица на двух страницах и документ с противоречивой суммой. Проверка сравнивает обязательные поля, типы, сумму и связь каждой позиции с исходной страницей. Для неоднозначности предусмотрен статус ручной проверки.

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

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

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