Контрольный набор для ИИ-агента: как проверить сценарий до доступа к реальной работе

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

Соберите семь типов кейсов

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

Обезличьте, но не упрощайте

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

Запускайте одинаково

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

Оценивайте по рубрике

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

Добавьте человека, который не писал сценарий

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

Решайте после серии, а не после лучшего примера

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

Ведите историю набора

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

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

Как сообщить о результате

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

Добавьте случайный контроль

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

FAQ

Сколько кейсов нужно вначале? Достаточно 10–15, если среди них есть реальные исключения. Нужно ли тестировать после обновления модели? Да, особенно перед включением внешних действий. Что делать с проваленным кейсом? Зафиксировать причину, изменить правило или доступ, затем повторить весь набор.