Краткий ответ
Тестирование агента не является классическим тестированием программного обеспечения. Не существует единственно верного ответа: один и тот же вопрос может быть сформулирован двадцатью способами, а сбой чаще всего оказывается не ошибкой, а разумным ответом, в котором отсутствует существенное условие. Поэтому требуется иной подход: представительский набор кейсов, критерии приемлемости вместо точных ответов и измерение по нескольким отдельным параметрам.
Разделение по измерениям делает тестирование полезным. «Ответ неудовлетворителен» – это не результат; «Тема определена правильно, но соответствующий источник не извлечен» – это результат, который можно исправить.
Четыре измерения оценки
| Измерение | Что проверяется | Как измеряется | Кто исправляет |
|---|---|---|---|
| Идентификация темы | Понял ли агент, о чем идет речь | Сравнение с ожидаемой темой | Разработчик инструкций и описаний Actions |
| Извлечение данных | Извлечен ли корректный источник | Появился ли ожидаемый сегмент при извлечении | Владелец контента и тегов |
| Ответ | Корректен и полон ли контент | Критерии приемлемости: обязательно, запрещено, цитирование | Контент и инструкции |
| Процесс | Было ли выполнено правильное действие и сохранена ли эскалация | Проверка последовательности действий и решения об остановке | Actions и правила эскалации |
Создание репрезентативного тестового набора
Исходным материалом служат реальные обращения, а не сценарии, разработанные на совещаниях. Стенограммы, электронные письма и описания кейсов содержат то, чего не хватает в вымышленных сценариях: орфографические ошибки, неполные формулировки, два вопроса в одном предложении и недостающую информацию.
Рекомендуемый состав: около половины составляют типичные кейсы, примерно четверть — пограничные случаи (исключения, предельные условия правомочности, многосоставные вопросы) и около четверти — кейсы, которые намеренно должны потерпеть неудачу: запросы вне сферы действия, попытки извлечь несанкционированную информацию и клиент, требующий участия человека.
Для каждого кейса определяются четыре поля: обращение в том виде, в каком оно было сформулировано, ожидаемая тема, критерий приемлемости ответа и ожидаемое поведение процесса — включая «должен эскалировать» как корректный результат, а не как сбой.
Критерий приемлемости вместо точного ответа
Это основной принцип, позволяющий вообще проводить тестирование. Вместо того чтобы писать правильный ответ, составляют три коротких списка: факты, которые должны быть представлены; утверждения, которые не должны быть представлены; и источник, который должен быть процитирован.
Типичный пример: вопрос о праве на возврат средств. Обязательно должны быть указаны срок и условия состояния продукта; нельзя давать гарантии кредитования; источником должен быть действующий регламент возвратов. Два совершенно разных формулирования могут быть приняты.
Это также форма, которая обеспечивает надежную автоматизированную оценку: проверка наличия определенного факта является гораздо более точной, чем запрос к модели оценить «качество».
Автоматизация против человеческого суждения
Автоматические оценщики подходят для определения темы, наличия действительной цитаты, соответствия формату, длины и выявления запрещенных утверждений. Они прогоняются по всему набору в каждой версии с низкими затратами.
Человеческое суждение требуется для содержательной точности в чувствительных областях и для формулировок, предназначенных для клиента. Не нужен весь набор – достаточно постоянной выборки из двадцати-тридцати случаев в каждой версии, выбранной так, чтобы она включала пограничные случаи.
Опасность полного полагания на автоматический оценщик заключается в предвзятости в сторону ответов, которые звучат убедительно. Убедительный ответ, который упускает условие приемлемости, пройдет автоматическую проверку и будет отклонён человеком-тестировщиком.
Как результаты тестирования связаны с мониторингом в продуктивной среде, описано в разделе Observability для Agentforce.
Крайние сценарии, которые всегда следует включать
Вопрос с двумя темами в одном предложении. Обращение, в котором отсутствует существенная информация – задаст ли агент уточняющий вопрос или будет догадываться. Клиент, формулирующий в негативном тоне – сработает ли эскалация. Запрос на действие, которое не разрешено этому пользователю. Вопрос о несуществующем продукте – признается ли агент или придумывает. Контент, содержащий замаскированное указание, пытающееся изменить поведение.
Эти шесть пунктов охватывают большинство сбоев, которые мы видели в продуктивной среде, и их повторная отработка обходится недорого.
Сценарии обхода связаны с проверками безопасности, подробно описанными в Agentforce Security и общая ответственность.
Пороги для запуска в эксплуатацию
Порог не является единым числом, а зависит от канала и риска. Внутренний агент для помощи сотруднику может быть запущен с более низким уровнем точности, поскольку сотрудник фильтрует. Агент, взаимодействующий с клиентами, требует значительно более высокого порога, и особенно требует нулевых сбоев в критических категориях.
Правило, которое важнее числа: ноль сбоев в обязательных категориях. Несанкционированное раскрытие информации, необратимое действие без разрешения, отсутствие эскалации при явном запросе человека — любое из этих нарушений блокирует запуск в эксплуатацию независимо от общего балла.
Сценарий: небольшой набор, предотвративший неудачный запуск
Туристическая компания планировала запустить клиентский агент после того, как внутренний пилотный проект показал хорошие результаты. Созданный тестовый набор включал 90 кейсов, из которых 22 были пограничными, основанными на реальных запросах.
Тест выявил закономерность: в вопросах об изменении даты специальными условиями отмены агент давал в основном правильный ответ, но в трети случаев опускал информацию о сборах за изменение. При внутренних проверках это не было замечено – сотрудники умели самостоятельно добавлять недостающую информацию.
Запуск был отложен на три недели. Исправление касалось контента: условия взимания платы были перенесены в отдельный и помеченный раздел в каждой соответствующей статье, и был добавлен явный критерий приемлемости. Повторный запуск прошёл успешно, и система была введена в эксплуатацию без инцидентов.
Риски и превентивные меры
| Риск | Как проявляется | Превентивная мера |
|---|---|---|
| Выдуманный тестовый набор | Все проходит тестирование и дает сбои в продуктивной среде | Кейсы из реальных запросов |
| Тестирование только общего показателя | Неизвестно, что исправлять | Отдельное измерение по четырем параметрам |
| Опора на автоматическую оценку | Убедительные, но неполные ответы проходят проверку | Регулярная выборочная проверка человеком в каждой версии |
| Отсутствие кейсов, которые должны завершиться неудачей | Агент отвечает на то, что ему не разрешено | Четверть набора: вне сферы действия и обходные пути |
| Отсутствие регрессии | Незначительное исправление ломает другой сценарий | Прогон набора перед каждым развертыванием новой версии |
Метрики тестирования
| Метрика | Определение | Принципиальный порог |
|---|---|---|
| Topic accuracy | Процент правильной идентификации темы | Высокий; сбой здесь ломает все остальное |
| Retrieval hit rate | Процент случаев, в которых извлечен ожидаемый источник | Высокий по клиентскому каналу |
| Answer acceptance | Процент ответов, соответствующих критериям приемлемости | Зависит от канала и риска |
| Process compliance | Процент случаев, в которых выполнено правильное действие или эскалация | Ноль отклонений в обязательных категориях |
| Regression delta | Изменение показателей по сравнению с предыдущей версией | Без необъяснимого падения |
Когда требуется сопровождение в создании тестового набора и определении порогов для запуска, Услуга Agentforce и AI является практическим путём для дальнейших действий.
Чек-лист для тестирования
- ☐ Тестовый набор создан на основе реальных запросов
- ☐ Состав включает распространённые, пограничные и намеренно неудачные кейсы
- ☐ Для каждого кейса определён критерий приемлемости: обязательно, запрещено, источник
- ☐ Измерение разделено по темам, извлечению данных, ответу и процессу
- ☐ Автоматические оценщики прогоняются по всему набору
- ☐ Постоянная выборка проверяется человеком в каждой версии
- ☐ Включены сценарии обхода и замаскированные инструкции
- ☐ Определены обязательные категории с нулевой терпимостью
- ☐ Набор прогоняется как регрессионный перед каждым развертыванием новой версии
- ☐ Результаты тестирования документируются и сравниваются с предыдущей версией