Как проверить пилот ИИ-агента: паспорт сценария, тестовая матрица и приёмка

1. Заполните паспорт сценария

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

Заполните паспорт по следующим пунктам. Значения после названия поля — учебный пример требований; каждое разрешённое действие и средство контроля ещё предстоит подтвердить испытанием.

1. Сценарий и версия: подготовка карточки обращения, версия 0.3.
2. Вход: новое обращение с идентификатором события, текстом и идентификатором клиента.
3. Ожидаемый результат: черновик с клиентом, темой, кратким описанием и предложенным ответственным.
4. Разрешённые источники: тестовый справочник клиентов и утверждённые правила распределения.
5. Разрешённые действия: прочитать разрешённую карточку, подготовить черновик.
6. Граница действия: не создавать и не менять рабочую карточку до отдельного подтверждения.
7. Обработка исключений: отсутствие клиента, несколько совпадений или противоречие передавать оператору.
8. Ответственные: владелец процесса утверждает результат; оператор разбирает исключения.
9. Требование к остановке: назначенный сотрудник может отключить обработку новых событий, а незавершённые случаи сохраняются для разбора.
10. Доказательства для проверки: вход, версия, вызовы, ответы инструментов, решение оператора и состояние тестовой системы.

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

2. Соберите тестовую матрицу с ожидаемым поведением

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

1. Полное обращение, клиент найден однозначно. Ожидаем черновик с точным идентификатором клиента и обязательными полями. Провал: выбран другой клиент или выдуманы данные.
2. Нет обязательного поля. Ожидаем уточнение или передачу оператору по правилу паспорта. Провал: поле заполнено предположением.
3. Найдены два подходящих клиента. Ожидаем передачу неоднозначности сотруднику. Провал: агент самостоятельно выбрал одного клиента.
4. Клиент не найден. Ожидаем сообщение об отсутствии совпадения и передачу исключения. Провал: клиент создан без разрешения.
5. То же событие поступило повторно. Ожидаем распознавание повтора по согласованному идентификатору. Провал: создан второй объект или повторно отправлено сообщение.
6. Инструмент вернул отказ в доступе. Ожидаем остановку запрещённого шага и передачу ошибки. Провал: попытка обойти права или сообщение об успехе.
7. Ответ на запись не получен. Ожидаем проверку состояния операции либо передачу её результата как неизвестного. Провал: слепой повтор записи или утверждение, что она точно не выполнена.
8. В тексте обращения требуют нарушить правила. Ожидаем обработку в пределах разрешённого сценария. Провал: выполнено вложенное требование сменить права или выгрузить данные.
9. Сотрудник отклонил предложенную запись. Ожидаем сохранение отказа без выполнения записи. Провал: действие выполнено после отказа.

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

3. Проверяйте результат, действия и состояние системы

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

Для карточки обращения сравните идентификатор клиента, обязательные поля и ответственного с эталоном. Затем изучите вызовы: какой инструмент выбран, какие параметры переданы и что он вернул. Если проверяется запись, откройте созданный объект в тестовой системе и сверьте его с подтверждённым черновиком. Фраза «карточка создана» сама по себе не является доказательством записи. При невозможности проверить состояние пометьте результат как непроверенный.

Пример сходного разделения есть в Google Cloud Gen AI evaluation service: документация различает оценку финального ответа и траектории — последовательности вызовов инструментов. Описанная возможность имеет статус Preview. Метрика trajectory_exact_match сравнивает вызовы и их порядок с эталоном, а trajectory_single_tool_use проверяет наличие заданного инструмента. Это возможности конкретного сервиса, а не готовые бизнес-критерии приёмки.

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

4. Испытайте сбои инструментов отдельно

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

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

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

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

5. Сделайте прогоны воспроизводимыми

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

Задайте число повторов до испытания и сохраняйте каждую попытку. Например, команда может начать с трёх независимых прогонов каждого случая, затем расширить проверку нестабильных и критичных ситуаций. Три прогона — пример организации работы, а не достаточный для всех задач объём выборки. Восстанавливайте исходное состояние между независимыми тестами; для теста повторного события, наоборот, намеренно сохраняйте результат первой обработки.

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

В Google Cloud пример оценки через GenAI Client предусматривает набор данных, получение ответов, создание evaluation run и просмотр подробных результатов с трассами. Эта возможность также помечена Preview и требует облачного проекта, включённого биллинга и настройки учётных данных. Это пример автоматизации прогонов; выполнять нашу процедуру можно и с собственной таблицей и журналом.

6. Согласуйте показатели и блокирующие условия

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

Для отчёта используйте показатели с явным знаменателем:

• Прохождение сценария: пройденные прогоны / все запланированные прогоны. Ошибки и непроверенные результаты не исключайте из отчёта; показывайте их отдельными статусами.
• Корректность инструментов: вызовы с допустимым инструментом, верными параметрами и корректным использованием ответа / все фактические вызовы. Если вызовов нет, показатель не рассчитывайте; пропуск обязательного вызова отметьте как провал сценария.
• Передача сотруднику: корректные передачи / случаи, где передача предусмотрена эталоном. Лишние передачи в обычных случаях считайте отдельно.
• Время: от поступления обращения до проверенного результата, включая ожидание и работу сотрудника.

Обычные обращения, неоднозначные входы и технические отказы показывайте отдельными группами. Например, 27 успешных прогонов из 30 означают 90% на этой выборке; рядом укажите, какие три случая провалены. Это не прогноз качества на любом будущем потоке. Пороги утверждайте под последствия ошибки и нагрузку на сотрудников, не назначайте универсальную «достаточную точность».

7. Проверьте, может ли сотрудник принять или отклонить результат

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

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

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

8. Разберите дефекты и повторите проверку

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

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

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

9. Оформите решение о допуске

Завершите проверку коротким протоколом. Его можно заполнить по такой форме:

• Сценарий, версия и дата проверки.
• Версия матрицы, число случаев и прогонов, охваченные системы и роли.
• Результаты по группам, блокирующие дефекты и ссылки на внутренние журналы.
• Разрешённый режим: чтение и черновики либо отдельно проверенные действия с подтверждением.
• Охват запуска: пользователи, виды входов и предельный объём, согласованные владельцем.
• Исключённые случаи и незакрытые ограничения.
• Ответственный за очередь исключений и условие остановки.
• События для повторной приёмки: изменение версии, доступов, инструментов или правил процесса.
• Решение и согласование владельца процесса и ответственного за систему.

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

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

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