Как нормально тестировать AI-агента, если правильный ответ ещё ничего не доказывает
У обычного чат-бота можно проверить финальный ответ. С агентами этого уже мало: модель может выдать вполне убедительный текст, но перед этим выбрать не тот skill, вызвать неправильный tool, потерять контекст на втором сообщении или выполнить только половину задачи.
Ed Crewe описал, как они строили eval-фреймворк для агентного чат-бота вокруг Postgres AI Hybrid Manager.
Начали с простого routing eval: для каждого запроса проверяется, выбрал ли агент нужный skill или tool. Это быстро, детерминированно и удобно гонять в CI.
Следующий слой — Task Completion Rate. Здесь уже оценивается сам результат: выполнил ли агент задачу, использовал ли нужные данные, предложил ли адекватный следующий шаг. Для таких проверок используется LLM-as-a-judge и заранее заданная rubric.
Но и этого оказалось мало. Реальные задачи часто состоят из нескольких сообщений, поэтому тестировать приходится уже целые диалоги с сохранением conversation state и отдельными проверками каждого шага.
Финальный уровень — trajectory testing: смотреть не только на ответ, а на весь путь агента к нему: маршрутизацию, выбор skills, tool calls, промежуточные действия, состояние диалога и итоговый результат.
Получается уже почти классическое E2E-тестирование, только объект проверки здесь не HTTP-запрос или UI, а поведение AI-агента целиком.
В основе автор использует deepeval, поверх которого добавлены YAML goldens, CI, плагины, multi-turn evals и телеметрия через Langfuse.
https://edcrewe.blogspot.com/2026/08/from-routing-checks-to-trajectory.html
У обычного чат-бота можно проверить финальный ответ. С агентами этого уже мало: модель может выдать вполне убедительный текст, но перед этим выбрать не тот skill, вызвать неправильный tool, потерять контекст на втором сообщении или выполнить только половину задачи.
Ed Crewe описал, как они строили eval-фреймворк для агентного чат-бота вокруг Postgres AI Hybrid Manager.
Начали с простого routing eval: для каждого запроса проверяется, выбрал ли агент нужный skill или tool. Это быстро, детерминированно и удобно гонять в CI.
Следующий слой — Task Completion Rate. Здесь уже оценивается сам результат: выполнил ли агент задачу, использовал ли нужные данные, предложил ли адекватный следующий шаг. Для таких проверок используется LLM-as-a-judge и заранее заданная rubric.
Но и этого оказалось мало. Реальные задачи часто состоят из нескольких сообщений, поэтому тестировать приходится уже целые диалоги с сохранением conversation state и отдельными проверками каждого шага.
Финальный уровень — trajectory testing: смотреть не только на ответ, а на весь путь агента к нему: маршрутизацию, выбор skills, tool calls, промежуточные действия, состояние диалога и итоговый результат.
Получается уже почти классическое E2E-тестирование, только объект проверки здесь не HTTP-запрос или UI, а поведение AI-агента целиком.
В основе автор использует deepeval, поверх которого добавлены YAML goldens, CI, плагины, multi-turn evals и телеметрия через Langfuse.
https://edcrewe.blogspot.com/2026/08/from-routing-checks-to-trajectory.html