Q: How do I evaluate agentic workflows? – Hamel’s Blog - Hamel Husain
Хэмел Хусейн рекомендует оценивать агентные workflow в два этапа. Сначала — сквозной успех задачи: агент рассматривается как чёрный ящик, для каждой задачи задаётся точное правило успеха, а оценку проводят люди или согласованные LLM-судьи с фиксацией первой upstream-ошибки при error analysis. Затем — пошаговая диагностика инструментированной системы по компонентам: выбор инструмента, извлечение параметров, обработка ошибок, удержание контекста, эффективность и контрольные точки целей. Для понимания паттернов сбоев предлагается матрица переходов между состояниями: строки — последнее успешное состояние, столбцы — место первого сбоя, что помогает увидеть, например, что переход GenSQL → ExecSQL даёт 12 ошибок против 2 у DecideTool → PlanCal. Приводится пример Брайана Бишофа с text-to-SQL агентом, демонстрирующий вариативность таких матриц. Тест-кейсы для сбоев агента создаются по тем же принципам, что и для многоходовых диалогов: воспроизводить ошибку максимально просто.
Мы рекомендуем оценивать агентные workflow в два этапа:
1. Сквозной успех задачи. Рассматривайте агента как чёрный ящик и спрашивайте: «достигли ли мы цели пользователя?». Определите точное правило успеха для каждой задачи (точный ответ, корректный побочный эффект и т. д.) и измеряйте с помощью людей или согласованных LLM-судей. Фиксируйте первый upstream-сбой при проведении error analysis.
Как только error analysis покажет, какие workflow чаще всего падают, переходите к пошаговой диагностике, чтобы понять, почему именно они падают.
2. Пошаговая диагностика. Если вы достаточно инструментировали систему деталями вызовов инструментов и ответов, можно оценивать отдельные компоненты: - Выбор инструмента: был ли выбранный инструмент уместным? - Извлечение параметров: были ли входные данные полными и корректно сформированными? - Обработка ошибок: восстановился ли агент после пустых результатов или сбоев API? - Удержание контекста: сохранил ли он ранее заданные ограничения? - Эффективность: сколько шагов, секунд и токенов было потрачено? - Контрольные точки цели: для длинных workflow проверяйте ключевые вехи.
Пример: «Найди дома в Беркли дешевле $1M и запиши на просмотры» разбивается на: параметры извлечены корректно, релевантные объявления получены, доступность проверена, приглашения в календарь отправлены. Каждая контрольная точка может проходить или падать независимо, что делает отладку посильной.
Используйте матрицы переходных сбоев, чтобы понять паттерны ошибок. Создайте матрицу, где строки — это последнее успешное состояние, а столбцы — место, где произошёл первый сбой. Это отличный способ понять, где случается больше всего сбоев.
Матрицы переходов превращают подавляющую сложность агента в практические инсайты. Вместо того чтобы тонуть в отдельных просмотрах трейсов, вы сразу видите, что переходы GenSQL → ExecSQL вызывают 12 сбоев, тогда как DecideTool → PlanCal — всего 2. Этот data-driven подход подсказывает, куда вкладывать усилия по отладке. Вот ещё один пример от Bryan Bischof, тоже про text-to-SQL агента:
В этом примере Bryan показывает вариативность матриц переходов между экспериментами. То, как организовать матрицу переходов, зависит от специфики вашего приложения. Например, text-to-SQL агент Брайана имеет внутреннюю последовательную структуру workflow, которую он использует для дополнительных аналитических выводов. Полный доклад можно посмотреть для подробностей.
Создание тест-кейсов для сбоев агента
Создание тест-кейсов для сбоев агента следует тем же принципам, что и наш предыдущий FAQ про отладку трейсов многоходовых диалогов (т. е. попытаться воспроизвести ошибку максимально простым способом, использовать многоходовые тесты только когда сбой действительно требует контекста диалога и т. д.).
Эта статья входит в наш AI Evals FAQ — сборник распространённых вопросов (и ответов) об оценке LLM. Посмотреть все FAQ или вернуться на главную.