Ознакомьтесь с чек-листом оценки агента

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

Tip

Скачайте редактируемый шаблон чек-листа.

Этап 1: Создание базовых тестовых наборов

Цель: создать и запустить базовый тестовый набор оценки, который оценивает основные сценарии агента.

Оценочный набор тестов — это группа тестовых примеров. Тестовый случай — это индивидуальная пара «подсказка и ответ» для оценки ответа агента на конкретный вопрос. Он включает тестовый запрос и необязательный ожидаемый ответ (утверждение), напрямую отражающий требования, заданные в инструкции агента. Тестовый случай также должен указывать критерии приема и метод тестирования для оценки качества.

Сценарий агента 1 Тестовое задание
(Пример запроса для агента)		 Ожидаемый ответ Критерии приема2
(Определите, как выглядит успешный ответ: что проходит, а что нет)
Агент должен отвечать на вопросы о политике на основе статьи базы знаний о политике. «Сколько дней больничных получает сотрудник?» «30 дней. <цитата>» Ответ должен содержать точный текст из базы знаний политики и полностью ему соответствовать. Ответ должен содержать ссылку.
Агент не должен отвечать на вопросы, выходящие за рамки статьи о политике. Прямые ответы от службы поддержки персонала. «Сколько дней больничных получает сотрудник?» «В документе политики не указаны дни больничных. Проконсультируйтесь с отделом кадров по поводу вашей политики больничных.» Ответ на запрещенный случай должен перенаправлять пользователя в службу поддержки персонала.

Tip

1Сценарий агента: Базовый тестовый набор должен включать тестовые случаи, охватывающие ключевые сценарии или сценарии использования агента. Используйте ситуацию с агентом как ориентир и сосредоточьтесь на том, что агент должен решать или избегать. Этот процесс помогает составить целевой список тестовых запросов и должен тесно координироваться с разработкой инструкций агента. Чтобы определить правильное количество тестовых случаев, начните с одного тестового запроса для каждого ключевого сценария. Начните с небольшого набора тестовых случаев, затем итерайте и уточняйте по мере получения информации и улучшения покрытия.

2Критерии принятия: Чётко определите, что считается успехом. Это определение может показаться сложным на первый взгляд, поэтому подумайте об уточнении своих критериев через итерации. Запустите тестовое задание, прочитайте ответ и оцените его качество, спросив: Отвечает ли оно на основной вопрос? Использует ли он правильную информацию? Подходит ли тон и стиль? Уважает ли он права на совместное использование? Ваши выводы из этих вопросов помогают вам определить критерии приема и, при необходимости, ожидаемый ответ.

Этап 2: Определение базового уровня и улучшение

Цель: проводить оценки и устанавливать базовые метрики для бенчмаркирования и улучшения.

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

Установите базовый уровень

  • Запустите базовый набор тестов для агента.
  • Документируйте прохождение или непрохождение для каждого тест-кейса.
  • Рассчитайте общий процент сдачи: ______%.
  • Запишите версию агента и базовую дату: ___________.

Анализ и итерация коренных причин

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

  • Проблема с тестовым случаем: вызывают ли провал подсказка, ожидаемый ответ или критерии приёма?
  • Проблема проектирования агента: указывает ли сбой на неясную инструкцию агента или недостатки в знаниях или конфигурации инструментов?

Определите первопричину и добейтесь улучшения путем доработки тест-кейса или улучшения архитектуры агента.

Tip

Балл прохождения оценки: Агенты могут давать разные ответы на один и тот же вопрос из-за своей вероятностной природы. Эта изменчивость может привести к тому, что ответы будут проходить или отклоняться в зависимости от строгих критериев приёма. Для обеспечения надёжной оценки запускайте каждый набор тестов несколько раз и рассчитывайте средний процент успешности. Стремитесь к реалистичному проценту сдачи в 80-90%, исходя из потребностей вашего бизнеса.

Этап 3: Реализация систематического расширения

Цель: создать комплексные оценочные группы по различным категориям качества агентов.

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

Категория качества Goal
Основополагающее ядро Набор тестов, которые должны быть успешно пройдены. Он оценивает ключевые показатели качества отклика при развертывании и выявляет регрессии во время эксплуатации.
Устойчивость агента Главное преимущество одного агента по сравнению с традиционным ПО — его надёжность в работе с различными сценариями использования. Это значение может включать:
  • Как агент отвечает на один и тот же вопрос, сформулированный по-разному?
  • Как агент обрабатывает богатый контекст, предоставленный в задании?
  • Как измерить наличие нескольких намерений в одном запросе?
  • Может ли агент правильно отвечать на запросы, специфичные для пользователя?
Агент должен правильно обрабатывать различные варианты этого сценария использования, и для их проверки можно использовать специальные тестовые случаи.
Архитектурный тест Оцените функциональную эффективность агента. Размеры могут включать:
  • Вызов инструмента, действие
  • Поиск знаний и поведение при цитировании
  • Логика маршрутизации
  • Интеграция передачи обращений
Граничные случаи Как агент должен обрабатывать граничные случаи с использованием механизмов защиты.
  • Условия границы
  • Запрещённые и выходящие за рамки области применения действия

Tip

Ссылка на цель категории:

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

Этап 4: Создание непрерывной операции оценки качества

Цель: Организовать непрерывный мониторинг оценки для поддержания качества агентов во время работы.

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

  • Установите регулярный график проведения оценки.
  • Рекомендуемые триггеры полного комплекса оценки:
    • Изменение модели
    • Крупное обновление настройки базы знаний
    • Новые интеграции инструментов или разъёмов
    • Инцидент на производстве

Tip

Индикатор успеха: вы успешно внедряете операционную деятельность, когда можете ответить на вопросы заинтересованных сторон конкретно, вместо того чтобы говорить: «Агент кажется нормальным».

Вы пишете: «Соответствие политикам на уровне 98%, но персонализация упала до 87%— в частности, политики, основанные на постоянной должности, не применяются. Мы выявили корень и продолжаем доработку.»

  • Last updated on