Методология тестирования AI-агентов: от роутинга до траекторий

Как тестировать 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е пайпы с агентами 👇👇👇