Тестирование ИИ-агентов перед запуском: сценарии, метрики и контроль рисков

Что именно нужно тестировать?

Агент — это не только модель. Проверяют инструкции, контекст, поиск по базе знаний, планирование, вызовы инструментов, права, внешние интеграции, память, интерфейс подтверждения и журнал. Ошибка может возникнуть в любом слое.

С чего начать модель рисков?

Перечислите активы, пользователей, внешние системы и недопустимые последствия. Для каждого действия определите обратимость, цену ошибки, требуемое подтверждение и владельца. NIST AI RMF предлагает рассматривать управление рисками как постоянный процесс, а OWASP выделяет угрозы вроде внедрения инструкций, небезопасной обработки вывода и чрезмерной автономности.

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

Как собрать набор сценариев?

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

1. Типовые задачи. Частые запросы с подтверждённым результатом.
2. Исключения. Отсутствующие поля, неоднозначность, дубль.
3. Конфликты. Расхождение запроса пользователя с политикой.
4. Атаки. Инъекции в сообщении, файле и найденном контенте.
5. Сбои. Тайм-аут, недоступный API, неожиданный ответ.
6. Критичные действия. Проверка шлюза подтверждения и отмены.

Для агента по базе знаний отдельно проверяют цитирование и поведение при отсутствии ответа. Архитектура такого решения описана в статье об ИИ-ассистенте по базе знаний.

Какие метрики использовать?

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

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

Как проверять действия и права?

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

Интеграционные повторы должны быть идемпотентными: повтор после тайм-аута не создаёт второй заказ или письмо. Основы надёжного контракта разобраны в статье «Интеграция по API».

Как провести проверку безопасности?

Тестируют прямые и косвенные инъекции, подмену инструкций в документе, извлечение системного контекста, доступ к данным другой роли и небезопасную передачу ответа в SQL, HTML или команду. Недоверенный текст остаётся данными и не получает приоритет над политикой.

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

Что проверять при сбоях?

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

Какие этапы пройти до продакшена?

1. 01

   Изолированный стенд

   Инструменты-имитаторы и синтетические данные.

2. 02

   Контрольный набор

   Автоматические правила и экспертная разметка.

3. 03

   Теневой режим

   Агент предлагает действия, но не выполняет их.

4. 04

   Ограниченный пилот

   Одна роль, процесс и подтверждаемые операции.

5. 05

   Поэтапный допуск

   Права расширяются только после разбора ошибок.

Какие условия включить в приёмку?

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

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

Что контролировать после запуска?

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

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

Частые вопросы