Как тестировать AI агентов: от роутинга до траекторий и ответов. 🤖
Помню, как читал лекции по RAG и говорил, что агентные эвалы схожи, но более сложные из-за недетрменированности флоу.
Теперь вышел достойный обзор, как можно это делать удобно. Ниже представлен разбор статьи инженера Postgres AI Hybrid Manager.
🔥 Проблема.
В RAG у вас ~четыре измерения: данные, кандидатогенератор, реранкер и ответ LLM. Но с агентами интереснее.
Тестировать AI-агента как обычный REST API (статус-коды и JSON-схемы) - бесполезно. LLM недетерминированы: они могут правильно решить задачу, но пойти другим путём, или наоборот – красиво ответить (увернуться, сглюкать), но пропустить главное.
Автор статьи прошёл путь от простых проверок к сложной системе и щедро поделился граблями. Вот этапы этого пути 👇
Этап 1: Роутинг - самая дешёвая и быстрая проверка. Убеждаемся, что запрос пользователя попал в нужный скилл или инструмент. По сути это аналог классификации интентов.
Метод оценки: Детерминированное сравнение строк (ожидаемый инструмент = фактический).
+ Ловит критичные баги на старте.
- Правильный роутинг НЕ гарантирует правильный ответ.
Этап 2: Полнота задачи (TCR - Task Completion Rate)
Здесь вводится как инструмент – LLM as J.
Вы пишете рубрику - метрики на на естественном языке, а другой LLM ставит оценку (например, от 0 до 1) за финальный ответ. Порог прохождения теста обычно ставят 0.7–0.85.
Этап 3: Многошаговые диалоги
Жизнь - это диалог, а не один запрос. Тесты учатся поддерживать сессию, склеивать историю и оценивать не только итог, но и корректность уточняющих вопросов.
Этап 4: Траектории - здесь проверяется не только «что сказал агент», но и «как он шёл».
Порядок вызовов инструментов, переданные параметры, изменения состояния системы. Это позволяет поймать ситуацию, когда финальный ответ хорош, но внутри агент «сходил» за данными в обход логики или нарушил политики безопасности.
Оба пункта 3 и 4 проводятся также, как ранее для оценки ассистентов - диалог идёт с накоплением по фразно, трейсы тоже, таким образом каждый квант действия проходит оценку на релевантность и полноту. См SSA. Берете эту логику и кладёте в рубрики для судьи. Далее оцениваете именно не число траекторий, шагов, фраз, а контекстуальную релевантность и итоговые ответы.
⚙️ Стек автора:
- deepeval для написания метрик и запуска LLM-судей.
- Langfuse для наблюдаемости.
Каждый тест - это трейс. Если тест упал, вы сразу видите в Langfuse, что пошло не так: промпт, выбор инструмента или ответ судьи.
📊 БОЛЬ - ЭТО ДАННЫЕ
Автор подчёркивает, что тестировать без корзин оценки или как я говорю "на глазок"- преступление против человечества качества. Агент покажет 90% прохождения, но в бою провалится. Это будет точечная оценка, а не стат значимая выборка.
Решение:
Использовать тестовое окружение в БД (тк тут ребята из Postgres и задача SQL агент) и проводить мутационное тестирование – намеренно удалять индексы, дублировать поля и ломать данные, чтобы проверить, как агент справляется с «грязным» окружением.
Особое внимание уделено тестированию под разный масштаб моделей.
Система поддерживает модели разного размера (S, M, L, XL) для офлайн/и onprem AI.
Умный вывод об оценке:
Маленькая модель не должна видеть все инструменты (ей не хватит контекста). Поэтому фреймворк должен быть «Tier-Aware», когда один запрос для модели S должен тестироваться по одним ожиданиям (отказ или простой ответ), а для модели XL по другим (сложная аналитика).
Эта статья мастрид для всех, кто строит Production AI. Сохраните, чтобы не потерять.
И делитесь в комментариях тем, как вы измеряет е2е пайпы с агентами 👇👇👇
Помню, как читал лекции по RAG и говорил, что агентные эвалы схожи, но более сложные из-за недетрменированности флоу.
Теперь вышел достойный обзор, как можно это делать удобно. Ниже представлен разбор статьи инженера Postgres AI Hybrid Manager.
🔥 Проблема.
В RAG у вас ~четыре измерения: данные, кандидатогенератор, реранкер и ответ LLM. Но с агентами интереснее.
Тестировать AI-агента как обычный REST API (статус-коды и JSON-схемы) - бесполезно. LLM недетерминированы: они могут правильно решить задачу, но пойти другим путём, или наоборот – красиво ответить (увернуться, сглюкать), но пропустить главное.
Автор статьи прошёл путь от простых проверок к сложной системе и щедро поделился граблями. Вот этапы этого пути 👇
Этап 1: Роутинг - самая дешёвая и быстрая проверка. Убеждаемся, что запрос пользователя попал в нужный скилл или инструмент. По сути это аналог классификации интентов.
Метод оценки: Детерминированное сравнение строк (ожидаемый инструмент = фактический).
+ Ловит критичные баги на старте.
- Правильный роутинг НЕ гарантирует правильный ответ.
Этап 2: Полнота задачи (TCR - Task Completion Rate)
Здесь вводится как инструмент – LLM as J.
Вы пишете рубрику - метрики на на естественном языке, а другой LLM ставит оценку (например, от 0 до 1) за финальный ответ. Порог прохождения теста обычно ставят 0.7–0.85.
Этап 3: Многошаговые диалоги
Жизнь - это диалог, а не один запрос. Тесты учатся поддерживать сессию, склеивать историю и оценивать не только итог, но и корректность уточняющих вопросов.
Этап 4: Траектории - здесь проверяется не только «что сказал агент», но и «как он шёл».
Порядок вызовов инструментов, переданные параметры, изменения состояния системы. Это позволяет поймать ситуацию, когда финальный ответ хорош, но внутри агент «сходил» за данными в обход логики или нарушил политики безопасности.
Оба пункта 3 и 4 проводятся также, как ранее для оценки ассистентов - диалог идёт с накоплением по фразно, трейсы тоже, таким образом каждый квант действия проходит оценку на релевантность и полноту. См SSA. Берете эту логику и кладёте в рубрики для судьи. Далее оцениваете именно не число траекторий, шагов, фраз, а контекстуальную релевантность и итоговые ответы.
⚙️ Стек автора:
- deepeval для написания метрик и запуска LLM-судей.
- Langfuse для наблюдаемости.
Каждый тест - это трейс. Если тест упал, вы сразу видите в Langfuse, что пошло не так: промпт, выбор инструмента или ответ судьи.
📊 БОЛЬ - ЭТО ДАННЫЕ
Автор подчёркивает, что тестировать без корзин оценки или как я говорю "на глазок"- преступление против человечества качества. Агент покажет 90% прохождения, но в бою провалится. Это будет точечная оценка, а не стат значимая выборка.
Решение:
Использовать тестовое окружение в БД (тк тут ребята из Postgres и задача SQL агент) и проводить мутационное тестирование – намеренно удалять индексы, дублировать поля и ломать данные, чтобы проверить, как агент справляется с «грязным» окружением.
Особое внимание уделено тестированию под разный масштаб моделей.
Система поддерживает модели разного размера (S, M, L, XL) для офлайн/и onprem AI.
Умный вывод об оценке:
Маленькая модель не должна видеть все инструменты (ей не хватит контекста). Поэтому фреймворк должен быть «Tier-Aware», когда один запрос для модели S должен тестироваться по одним ожиданиям (отказ или простой ответ), а для модели XL по другим (сложная аналитика).
Эта статья мастрид для всех, кто строит Production AI. Сохраните, чтобы не потерять.
И делитесь в комментариях тем, как вы измеряет е2е пайпы с агентами 👇👇👇