Тестирование ИИ-агентов: как принимать обновления

Что считать успешной работой ИИ-агента?

В программе Datadog Summit на 23 сентября 2026 года есть практикум с вопросом, который я предложил бы задавать на каждой приёмке: как понять, что замена модели или промпта действительно улучшила приложение? Организаторы связывают тестирование ИИ-агентов до выпуска с наблюдением за качеством после запуска. На странице практикум называется Evaluate and Optimize AI Agent Performance.

Моя позиция: если помощник меняет состояние бизнес-системы, принимать его по переписке нельзя. Промпт – инструкция модели. Но для заказчика правка этой инструкции меняет поведение продукта, а значит, требует проверяемого результата.

Возьмём условный сценарий для проектирования теста: сотрудник просит перенести доставку. Красивое сообщение о новой дате ничего не доказывает. Я проверял бы дату в заказе, сохранность остальных полей, результат уведомления и отсутствие повторного изменения при повторном запросе. Если правила запрещают перенос, успешный исход – объяснение отказа без изменения заказа.

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

В препринте READY or Not, опубликованном 2 сентября 2026 года, авторы предлагают оценивать готовность к внедрению через сочетание надёжности, затрат и человеческого контроля. Для приёмки это полезный ориентир: умение выполнить задачу ещё не объясняет, при каких условиях систему можно использовать.

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

Почему ручной проверки перестаёт хватать?

У Anthropic есть показательный опыт. Claude Code сначала развивали, быстро собирая отзывы сотрудников и внешних пользователей. Позже добавили автоматизированные оценки: от краткости ответов и редактирования файлов до склонности чрезмерно усложнять решения. В разборе Anthropic описан тупик работы по жалобам: команда воспроизводит сбой, исправляет его, но без системных проверок не знает, не сломала ли что-то рядом.

Для меня здесь управленческий вопрос: кто доказывает, что исправление завершено? Сообщение разработчика «теперь на этом запросе работает» закрывает только исходный пример. Заказчику же нужно основание принять изменение целиком.

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

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

Как собрать проверочные сценарии из требований и ошибок?

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

В CRT есть компетенции системной аналитики и QA – обеспечения качества. В такой задаче я подключал бы их вместе ещё до разработки: аналитик помогает договориться о правилах процесса, QA переводит их в проверки. Если к демонстрации стороны всё ещё по-разному понимают слово «готово», тестирование подключили поздно.

Для карточки сценария я рекомендую такую структуру:

Больше всего внимания я уделил бы запретам и неоднозначностям. Для условного переноса доставки добавил бы случаи, когда нужная дата недоступна, заказ уже передан перевозчику, пользователь назвал несколько заказов или сервис сохранения не ответил. Это предлагаемые проверки (проект CRT я здесь не описываю).

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

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

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

Кто проверяет результат: тест, модель или специалист?

Я распределял бы проверки по тому, чем можно доказать результат. Наличие записи в CRM подтверждается чтением записи. Просить другую нейросеть оценить, «похоже ли, что заказ обновлён», здесь незачем.

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

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

У нас в портфолио есть дизайн-поддержка и тестирование раздела Альфа-Инвестиций. Этот проект подтверждает компетенцию CRT в тестировании; внедрение агента в нём не описано. Для ИИ-решения я добавил бы QA отдельную задачу: подтвердить фактический исход операции и независимо от него оценить сообщение пользователю.

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

Как принимать обновления модели и промпта?

Условия выпуска я предлагаю согласовать до первого сравнения. Когда критерии выбирают уже после просмотра результатов, слишком легко найти удобное объяснение любому исходу.

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

Процедуру сравнения я выстроил бы так:

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

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

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

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

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