Оценка качества реагирования для агента Self-Service сотрудников

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

Как приступить к работе:

• Начните с запуска FlightCheck , чтобы заранее проверить работоспособность конфигурации агента, прежде чем оценивать качество ответа.
• Затем ознакомьтесь с оценками как процессом и набором навыков.
• Далее узнайте, как создать настраиваемую стратегию оценки для агента Self-Service сотрудников.
• Затем начните использовать средства оценки, наборы тестов и узнайте, как думать об измерении различных частей Self-Service сотрудников

Зачем инвестировать в оценки для вашего агента?

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

• Получите более четкое представление о том, как агент Self-Service сотрудников реагирует на определенные сценарии и обрабатывает определенные сценарии.
• Развертывание быстрее с меньшим риском за счет проверки изменений перед рабочей средой.
• Повышение точности и релевантности с помощью обоснованной и согласованной оценки качества.
• Предотвращение регрессий, вызванных запросом, моделью или изменениями конфигурации.
• Экономия времени на контроль качества вручную за счет автоматического создания и оценки набора данных.
• Увеличьте доверие сотрудников с помощью более согласованных, полных и правильных ответов.
• Поддержка управления и соответствия требованиям к аудиту, повторяемым и объективным методам оценки.

Оценки помогут вам ответить:

• Соответствует ли этот опыт потребностям сотрудников?
• Объединяются ли знания, данные и качества общения таким образом, что фактически отклоняет билеты и улучшает опыт сотрудников?
• Отражают ли ответы агента правильный уровень точности, полноты и релевантности для создания доверия и поощрения внедрения пользователей?

Чем отличаются традиционные методики контроля качества (QA) и оценки LLM

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

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

• Контроль качества проверяет, ответил ли агент
• Evals проверка, был ли ответ *полезным

Примеры

Ниже приведены некоторые примеры, демонстрирующие разницу между оценками контроля качества и LLM.

Сценарий: Сотрудник задает общий вопрос о заработной плате

Запрос пользователя: "Почему моя чистая заработная плата ниже в этом месяце?"

Традиционный пример ответа на вопросы контроля качества:

"Ваша чистая заработная плата ниже из-за вычетов. Пожалуйста, проверка ваш лист оплаты для получения дополнительных сведений".

С точки зрения традиционного контроля качества этот ответ выглядит хорошо:

• Система не сбой
• Ответ, отрисованный правильно
• Ошибки не были выданы
• Агент вернул ответ
• Ничто не нарушило жесткое правило

Проблема с ответом, как этот, заключается в том, что он не помогает предотвратить создание билетов и не повышает удовлетворенность сотрудников.

Более качественный ответ:

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

Этот ответ:

• Ответы на реальный вопрос
• Помогает сотруднику самостоятельно обслуживать
• Сокращает количество запросов в службу поддержки
• Соответствует поведению политики заработной платы

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

Запрос пользователя: "Какова моя базовая зарплата?"

Традиционный пример ответа на вопросы контроля качества:

"Вашу базовую зарплату можно найти в Workday".

Более качественный ответ:

"Ваша базовая заработная плата составляет 155 000 долларов США. Дополнительные сведения о заработной плате можно найти в Центре сотрудников".

Оценка агента — это программа

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

Роли и обязанности.

Принципы организации

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

TLDR: People ближе всего к политике проверить результаты. People ближе всего к платформе применить изменения.

Подотчетные команды

Совместная работа ролей

1. Владелец программы оценки определяет, что следует протестировать.
2. Владелец агента выполняет оценки и собирает результаты.
3. Владельцы домена просматривают сбои, относящиеся к их областям
4. Юридическая информация, конфиденциальность и безопасность: определение сценариев с высоким риском и проверка результатов теста
5. Владелец агента применяет утвержденные изменения для улучшения ответов агента
6. После внесения изменений оценки выполняются повторно

Жизненный цикл оценки — когда оценивать?

**Перед развертыванием—цель: запуск с уверенностью

• Проверка работы основных сценариев
• Ранний перехват недостающих знаний, неработающих соединителей или небезопасных ответов
• Установка базовой панели качества
• Сосредоточьтесь на следующих основных сценариях, как базовые сценарии, сценарии обязательного ответа и ответственного ИИ, различия между ролями и регионами

**Во время настройки и цели итерации: повышение качества по мере развития агента

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

**После развертывания— цель: поддерживать качество с течением времени

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

**Масштабирование и оптимизация— цель: доказать ценность и руководство по инвестициям

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

Основные этапы цикла тестирования

1. Начните с измерения того, что важнее всего.

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

2. Выполните тест, чтобы установить базовый план.

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

3. Синтез результатов, так как не все сбои равны.

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

4. Решите, что на самом деле необходимо изменить.

Большинство изменений делятся на три категории:

• **A. Агенту необходимо изменить— Результаты могут отображать пробелы в знаниях, разделы, которые не активируются (или чрезмерно активируются), или отсутствуют сведения о контексте пользователя, такие как роль и регион. Эти проблемы обычно требуют обновления источников знаний, инструкций агента или проектирования разделов.
• **B. Ожидаемый ответ должен измениться. Ожидаемый ответ может быть слишком строгим, может не усилить правильное поведение или создать ложные сбои из-за незначительных различий в формулировках.
• **C. Критерии теста необходимо изменить. Проблема может быть связана с типом теста, превышением пороговых значений, которые не соответствуют приемлемому качеству, или критериями, которые измеряют неправильную вещь.

5. Выполните итерацию нескольких циклов улучшения.

Loop: Выполнить —> Проверка —> настройка —> повторный запуск. Агент улучшается, тесты получаются более точными, а команда формирует общее представление о том, что хорошо выглядит.

6. Тест стабилизируется.

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

7. Используйте стабилизированный тест для регрессии.

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

Рекомендации по обработке стратегии оценки

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

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

Организационная структура и модель владения

В большинстве организаций есть несколько поддоменов, которые владеют разными разделами, например:

• Отдел кадров: пособия, компенсация, мобильность, отпуск, адаптация, отношения с сотрудниками
• ИТ: доступ к удостоверениям &, конечная точка или устройство, программное обеспечение, сеть, операции поддержки

Влияние на стратегию.

• Создание отдельных тестовых наборов по домену (например, "Преимущества", "Выйти", "ИТ-доступ", "Устройства" и т. д.).
• Назначьте владельцев конкретного домена для просмотра результатов теста.
• Используйте тег или отдельный CSV-файл. файлы, чтобы результаты теста можно было направлять в нужные команды.
• Некоторым командам требуются юридические, кадровые операции, ИТ-безопасность или знак соответствия требованиям.

Сложность системы и интеграция

Отдел кадров и ИТ имеют несколько интегрированных систем (Workday, ServiceNow, инструменты для заработной платы, поездок, идентификации, управления устройствами). Качество ответа часто зависит от точных вызовов соединителя и правильной маршрутизации системы.

Влияние на стратегию.

• Создание определенных системных тестовых наборов (например, запросы профиля Workday)
• Определите ожидаемые ответы, включающие правильные триггеры и параметры средства.
• Выполнять регрессионные тесты при каждом изменении конфигурации или разрешений системы.

Различия в политике между регионами и ролями

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

Влияние на стратегию.

• Включите запросы золотого региона (например, "Я имею право на отпуск по уходу за ребенком в Германии?").
• Используйте переменные контекста пользователя (роль, регион) при тестировании, чтобы обеспечить правильную адаптацию ответов.
• Рассмотрите возможность оценки "сценариев только для США" и т. д. в качестве отдельных тестовых наборов.

Различия в разрешениях и рабочих процессах на основе ролей

Руководители, сотрудники, подрядчики и новые сотрудники часто имеют разные шаги и права, которые также могут отличаться в зависимости от региона.

Влияние на стратегию.

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

Управление, соответствие требованиям и устойчивость к рискам

Более регулируемые отрасли, такие как здравоохранение, финансовые услуги, правительство, фарма и т. д., могут иметь более строгие пороговые значения для реагирования агента.

Влияние на стратегию.

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

Жизненный цикл содержимого и частота изменений

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

Влияние на стратегию.

• Создайте план eval на основе циклов изменения политики.
• Повторно запускайте тестовые наборы после каждого обновления знаний или корректировки сезонной политики.
• Запускайте и оценивайте тесты, которые являются "чувствительными к политике", чтобы они были более тщательно отслеживаются.

Дальнейшие действия

• Узнайте, как создать настраиваемую стратегию оценки
• Пропустить вперед: начать выполнение тестов