Проверяйте AI-агента на четырех уровнях: найденные данные, содержание ответа, выполненные действия и весь процесс. Нужны обычные и проблемные примеры, наблюдаемые критерии и отдельный учет дорогих ошибок; один общий процент качества этого не заменяет.
Агент может правильно ответить и при этом открыть чужую карточку. Может ошибиться в формулировке, но корректно выполнить задачу. Поэтому оценка только финального текста не показывает, готова ли система к реальной работе.
Возьмите результат, за который кто-то отвечает
Предположим, агент читает обращение и готовит проект ответа по правилам компании. Приёмка включает соответствие вопросу, факты из источников, правильную версию правила и отсутствие лишних обещаний. Если он ещё меняет заявку в CRM, добавляется проверка этой записи.
Опишите каждое требование наблюдаемым способом. «Ответ качественный» слишком расплывчато. «Содержит разрешённый способ решения, не обещает возврат без проверки и ссылается на действующий регламент» позволяет двум проверяющим сравнить оценки.
Соберите тесты до очередной настройки
Нужны обычные случаи, сложные формулировки, недостающие сведения, конфликты источников и отказы интеграций. Отдельно включите редкие дорогие ошибки: неверного получателя, чужой документ, повторное действие. Частота в реальном потоке не единственный критерий важности.
Сохраняйте ожидаемые факты и допустимые действия, а не единственную красивую фразу. Иначе система будет штрафоваться за полезную вариативность и награждаться за сходство текста. Для некоторых случаев правильный ответ — уточнить, отказать в действии или передать человеку.
Часть примеров оставьте для проверки после изменения. Если постоянно подстраивать инструкцию под один известный набор, хорошая оценка перестанет говорить о новой работе. Добавляйте реальные сбои по мере появления, сохраняя отдельную историю версий тестов.
- Данные / ответОснование и вывод. Найден ли нужный источник и следует ли из него ответ.
- ДействиеЧто изменилось. Правильный инструмент, аргументы и объект.
- ПроцессКак завершилось. Повторы, ожидание, подтверждения и итог.
Слои диагностики, не частоты ошибок. Каждый дефект относится к конкретной причине.
Четыре слоя проверки
| Слой | Что может пойти не так |
|---|---|
| Данные | Нужный документ не найден или устарел |
| Ответ | Источник найден, но вывод не следует из него |
| Действие | Выбран не тот инструмент или объект |
| Процесс | Повтор, задержка или подтверждение обработаны неверно |
Такой разбор помогает исправлять причину. Если источник отсутствует в поиске, новый тон промпта не восстановит документ. Если CRM возвращает неоднозначный статус, более сильная модель не заменит ясный контракт инструмента.
Руководство OpenAI по оценке с учётом harness также различает проверку отдельных вызовов и работу внутри реального окружения. Тест в упрощённом цикле полезен, но не полностью воспроизводит продукт с его контекстом и ограничениями.
Автоматическая оценка нужна вместе с проверкой человеком
Числа, обязательные поля, схему ответа и факт вызова инструмента часто можно проверить программой. Смысл, достаточность объяснения и спорные ситуации требуют другой оценки. Модель-проверяющий может помочь разбирать большие наборы, но её решения тоже нужно проверять на понятных примерах.
Дайте проверяющим короткую рубрику с примерами границ. Если два человека систематически расходятся, сначала уточните критерии. Средняя оценка неоднозначного требования создаёт видимость точности. Для критичных ошибок полезнее отдельный счётчик и разбор каждого случая.
Безопасность проверяется в том же сценарии
Протестируйте доступ пользователя без нужных прав, документ с посторонней инструкцией, слишком широкий запрос и действие без подтверждения. Не ограничивайтесь вопросом, пишет ли модель опасный текст. Для рабочего агента риск часто находится в том, какой файл он открыл и что передал инструменту.
Проверка должна охватывать приложение, интеграции и окружение. В материале Anthropic именно эти слои рассматриваются вместе с моделью. Ограничения прав в коде нужны даже тогда, когда модель обычно соблюдает инструкцию.
На уровне управления рисками полезна отдельная запись: ошибка, возможное последствие, существующий контроль и ответственный. NIST AI RMF предлагает добровольную рамку работы с рисками AI; её наличие не сертифицирует конкретный продукт, а помогает организовать вопросы.
Решение о запуске не должно сводиться к одному проценту
Разделите результаты по типам задач и тяжести ошибок. Высокий общий балл может скрыть провал редкого важного сценария. Укажите, что проверено, какие случаи ещё не поддерживаются и где остаётся участие человека.
Первые реальные задачи запускайте с наблюдением и возможностью ограничить неудачную ветку. После смены модели, данных, промпта или инструмента повторяйте затронутые проверки. Хорошая оценка описывает конкретную версию системы, а не выдаёт пожизненный знак качества.
Один пример рубрики
Клиент спрашивает о возврате, но срок и основание не указаны. Приемлемый ответ уточняет недостающее и не обещает решение. Ошибка содержания — агент сразу обещает возврат. Ошибка данных — применяет старую редакцию правил. Ошибка действия — меняет статус заявки без предусмотренного подтверждения.
Эти события не стоит сводить к одной оценке «четыре из пяти». Для каждого есть отдельная причина и исправление. Добавьте обратный пример: все сведения известны, правило однозначно, но агент бесконечно уточняет. Он может быть осторожен, однако не помогает клиенту. Приёмка должна проверять и предотвращение ошибок, и способность довести допустимую задачу до конца.
- ВходОдна ситуация. Сохранить исходный вопрос и доступные данные.
- КритерииОжидаемые факты и действие. Что система должна знать и сделать.
- ПроверкаОтвет плюс результат. Проверить сообщение и запись во внешней системе.
Заполненный учебный тест из статьи; оценка не привязана к конкретной модели.
Карточка теста, которую можно копировать
Вход: клиент спрашивает о сроках, но не указывает услугу. Ожидаемые факты: услуга пока неизвестна, обещанного срока нет. Допустимое действие: уточнить услугу и сохранить исходное обращение. Критическая ошибка: назвать срок или оформить конкретную услугу без основания. Доказательство: текст ответа и запись в системе.
Соседний тест меняет только одно условие: услуга известна и действующий срок найден. Теперь повторное уточнение уже лишнее, а правильным становится конкретный ответ с опорой на источник. Такая пара проверяет, понимает ли система основание действия, а не заучила ли универсальную осторожную фразу.