Что такое оценки ИИ-агентов и почему они важны?

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

Откуда вы знаете, что ваш ИИ-агент действительно дает пользователям правильные ответы? Вероятно, потому что он произвел на всех впечатление на презентации. Допустим, ваш помощник техподдержки ответил на каждый вопрос, который ваша команда задала ему перед запуском. Затем приходят реальные клиенты с расплывчатыми вопросами, устаревшими данными учетных записей и системами, у которых истекает время ожидания на середине запроса. Помощник продолжает отвечать так же уверенно, и примерно один ответ из 10 оказывается неверным. Уверенно неверным — а это худший вид ошибки.

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

Что такое оценки ИИ-агентов?

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

Оценка может проверять не только то, что агент говорит в итоге. Она также может проверять, как агент к этому пришел:

• Какие документы он искал
• Какие инструменты он использовал, например API поиска или систему бронирования
• Какую информацию он отправлял в каждый инструмент
• Была ли задача действительно выполнена

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

Почему традиционных тестов недостаточно?

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

Традиционные тесты следует использовать для проверки предсказуемых вещей, таких как парсеры, схемы, разрешения, вычисления и ответы API. У них есть конкретные ожидаемые результаты.

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

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

Если вы оцениваете только первый ответ, вы можете вообще упустить этот сбой. Несмотря на то, что помощник звучит так, будто справляется лучше, он пропускает важный шаг в рабочем процессе. Традиционный тест может это пропустить.

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

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

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

Что включает в себя рабочий процесс оценки?

Рабочий процесс оценки использует пять связанных частей, чтобы показать, какие сценарии улучшило изменение и почему.

Когда оценки связаны с трассировками, падение качества ответов может помочь вам выяснить, какой именно шаг к нему привел. Стандарты OpenTelemetry generative AI унифицируют процесс записи таких трассировок и оценок.

Чтобы сделать это наглядным, вот небольшая строка датасета для агента поддержки аккаунтов:

Запустите ту же строку для Промпта A и Промпта B. Оцените оба результата, а затем изучите трассировки, когда оценки расходятся. Записывайте версии промпта, модели, оценщика и датасета вместе с экспериментом, иначе позже никто не сможет воспроизвести победный результат. «В прошлый вторник оценка была выше» — это не доказательство.

Отслеживать все эти версии вручную быстро надоедает. Progress Agent Engineering встраивает такое ведение учета в свои датасеты и эксперименты, поэтому каждый эксперимент указывает версию датасета, на которой он запускался.

Полезный совет: используйте детерминированные проверки для фактов, которые может проверить машина, а качественные оценки и проверку человеком оставьте для вопросов смысла и риска.

Что такое LLM в роли судьи (LLM-as-a-Judge)?

LLM-as-a-Judge использует модель-оценщика для применения письменной рубрики к результату и возврата оценки с обоснованием. Рубрика может охватывать релевантность, безопасность или обоснованность — то есть поддерживается ли ответ исходным материалом.

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

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

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

В Agent Engineering шаблон оценщика содержит инструкции судьи, критерии оценки и модель, и каждая оценка возвращается с объяснением.

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

Как оценки справляются с RAG и агентами, использующими инструменты?

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

Когда ответ службы поддержки упускает важную деталь политики, Retrieval-Augmented Generation Assessment (RAGAs) evaluation framework оценивает качество извлечения и качество ответа раздельно. Трассировка может предоставить информацию, которая поможет вам выяснить, пропустило ли извлечение нужную политику, затенел ли промпт нужный фрагмент или модель его не использовала.

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

Как начать с малого и продолжить улучшение после запуска?

Начните с малого: выберите один критически важный рабочий процесс и соберите от 20 до 50 примеров из требований, граничных случаев и известных сбоев. Определите несколько критериев успешности. Используйте точные проверки везде, где это возможно, и добавляйте LLM-судью только там, где необходимо оценить смысл.

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

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

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

Задачи оценки в Agent Engineering могут оценивать уже собранные трассировки или новые по мере их поступления.

Пропускайте каждый полезный сбой из продакшена через тот же цикл улучшений:

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

Каждый сохраненный сбой делает следующий релиз менее уязвимым к тем же ошибкам.

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

Ознакомьтесь с тарифными планами Progress Agent Engineering для трассировки, оценок с помощью LLM в роли судьи, наборов данных и экспериментов.

Начать работу