Как мы тестируем наших агентов в разработке

4 ключевых урока, усвоенных трудным путем

Делиться

Почему так сложно тестировать агентов

Проверить, работает ли ваш ИИ-агент ожидаемым образом, непросто. Даже небольшие изменения в таких компонентах, как версии подсказок, оркестровка агента и модели, могут иметь серьёзные и неожиданные последствия.

Некоторые из главных проблем включают в себя:

Недетерминированные выходы

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

Как проверить ожидаемый результат, если неизвестно, каким он будет? Проще говоря, тестирование строго определённых результатов не работает.

Неструктурированные результаты

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

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

Стоимость и масштаб

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

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

Тестирование нашего агента

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

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

Семантическое расстояние

Мы используем детерминированные тесты, когда это уместно, поскольку они понятны, объяснимы и экономичны. Например, сравнительно легко развернуть тест, чтобы убедиться, что один из выходных данных субагента представлен в формате JSON, не превышает определённую длину или вызывается корректно.

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

Однако мы обнаружили, что слишком часто формулировки были схожими, но значение различалось.

Вместо этого мы теперь предоставляем нашему судье LLM ожидаемый результат текущей конфигурации и просим его оценить по шкале от 0 до 1 сходство нового результата.

Заземленность

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

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

Использование инструмента

Для использования инструмента у нас есть LLM-судья, который оценивает, выполнил ли агент ожидаемый результат для заранее определенного сценария, что означает:

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

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

Лучшие практики тестирования агентов

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

Мягкие неудачи

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

Оценка выставляется по шкале от 0 до 1. Оценка ниже 0,5 считается полной неудовлетворительной, выше 0,8 — удовлетворительной. Оценка от 0,5 до 0,8 считается частичной неудовлетворительной.

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

В настоящее время наш агент настроен таким образом, что если 33% тестов приводят к мягкому сбою или если в общей сложности происходит более двух мягких сбоев, то это считается жестким сбоем. Это предотвращает слияние изменений.

Переоценка незначительных сбоев

Мягкие сбои могут быть канарейкой в угольной шахте, а в некоторых случаях могут быть просто бессмысленными. Около 10% таких сбоев являются результатом галлюцинаций. В случае мягкого сбоя оценки автоматически повторяются. Если результаты тестов пройдены, мы предполагаем, что первоначальный результат был неверным.

Пояснения

Если тест провален, нужно понять, почему он провалился. Теперь мы просим каждого судью LLM не просто выставить оценку, но и объяснить её. Этот подход несовершенен, но он помогает повысить доверие к оценке и часто ускоряет отладку.

Удаление нестабильных тестов

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

Мониторинг в производстве

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

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

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

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

Источник: towardsdatascience.com