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 агентом, демонстрирующий вариативность таких матриц. Тест-кейсы для сбоев агента создаются по тем же принципам, что и для многоходовых диалогов: воспроизводить ошибку максимально просто.
We recommend evaluating agentic workflows in two phases:
Мы рекомендуем оценивать агентные workflow в два этапа:
1. End-to-end task success. Treat the agent as a black box and ask “did we meet the user’s goal?”. Define a precise success rule per task (exact answer, correct side-effect, etc.) and measure with human or aligned LLM judges. Take note of the first upstream failure when conducting error analysis.
1. Сквозной успех задачи. Рассматривайте агента как чёрный ящик и спрашивайте: «достигли ли мы цели пользователя?». Определите точное правило успеха для каждой задачи (точный ответ, корректный побочный эффект и т. д.) и измеряйте с помощью людей или согласованных LLM-судей. Фиксируйте первый upstream-сбой при проведении error analysis.
Once error analysis reveals which workflows fail most often, move to step-level diagnostics to understand why they’re failing.
Как только error analysis покажет, какие workflow чаще всего падают, переходите к пошаговой диагностике, чтобы понять, почему именно они падают.
2. Step-level diagnostics. Assuming that you have sufficiently instrumented your system with details of tool calls and responses, you can score individual components such as: - Tool choice: was the selected tool appropriate? - Parameter extraction: were inputs complete and well-formed? - Error handling: did the agent recover from empty results or API failures? - Context retention: did it preserve earlier constraints? - Efficiency: how many steps, seconds, and tokens were spent? - Goal checkpoints: for long workflows verify key milestones.
2. Пошаговая диагностика. Если вы достаточно инструментировали систему деталями вызовов инструментов и ответов, можно оценивать отдельные компоненты: - Выбор инструмента: был ли выбранный инструмент уместным? - Извлечение параметров: были ли входные данные полными и корректно сформированными? - Обработка ошибок: восстановился ли агент после пустых результатов или сбоев API? - Удержание контекста: сохранил ли он ранее заданные ограничения? - Эффективность: сколько шагов, секунд и токенов было потрачено? - Контрольные точки цели: для длинных workflow проверяйте ключевые вехи.
Example: “Find Berkeley homes under $1M and schedule viewings” breaks into: parameters extracted correctly, relevant listings retrieved, availability checked, and calendar invites sent. Each checkpoint can pass or fail independently, making debugging tractable.
Пример: «Найди дома в Беркли дешевле $1M и запиши на просмотры» разбивается на: параметры извлечены корректно, релевантные объявления получены, доступность проверена, приглашения в календарь отправлены. Каждая контрольная точка может проходить или падать независимо, что делает отладку посильной.
Use transition failure matrices to understand error patterns. Create a matrix where rows represent the last successful state and columns represent where the first failure occurred. This is a great way to understand where the most failures occur.
Используйте матрицы переходных сбоев, чтобы понять паттерны ошибок. Создайте матрицу, где строки — это последнее успешное состояние, а столбцы — место, где произошёл первый сбой. Это отличный способ понять, где случается больше всего сбоев.
Transition matrices transform overwhelming agent complexity into actionable insights. Instead of drowning in individual trace reviews, you can immediately see that GenSQL → ExecSQL transitions cause 12 failures while DecideTool → PlanCal causes only 2. This data-driven approach guides where to invest debugging effort. Here is another example from Bryan Bischof, that is also a text-to-SQL agent:
Матрицы переходов превращают подавляющую сложность агента в практические инсайты. Вместо того чтобы тонуть в отдельных просмотрах трейсов, вы сразу видите, что переходы GenSQL → ExecSQL вызывают 12 сбоев, тогда как DecideTool → PlanCal — всего 2. Этот data-driven подход подсказывает, куда вкладывать усилия по отладке. Вот ещё один пример от Bryan Bischof, тоже про text-to-SQL агента:
In this example, Bryan shows variation in transition matrices across experiments. How you organize your transition matrix depends on the specifics of your application. For example, Bryan’s text-to-SQL agent has an inherent sequential workflow which he exploits for further analytical insight. You can watch his full talk for more details.
В этом примере Bryan показывает вариативность матриц переходов между экспериментами. То, как организовать матрицу переходов, зависит от специфики вашего приложения. Например, text-to-SQL агент Брайана имеет внутреннюю последовательную структуру workflow, которую он использует для дополнительных аналитических выводов. Полный доклад можно посмотреть для подробностей.
Creating Test Cases for Agent Failures
Создание тест-кейсов для сбоев агента
Creating test cases for agent failures follows the same principles as our previous FAQ on debugging multi-turn conversation traces (i.e. try to reproduce the error in the simplest way possible, only use multi-turn tests when the failure actually requires conversation context, etc.).
Создание тест-кейсов для сбоев агента следует тем же принципам, что и наш предыдущий FAQ про отладку трейсов многоходовых диалогов (т. е. попытаться воспроизвести ошибку максимально простым способом, использовать многоходовые тесты только когда сбой действительно требует контекста диалога и т. д.).
This article is part of our AI Evals FAQ, a collection of common questions (and answers) about LLM evaluation. View all FAQs or return to the homepage.
Эта статья входит в наш AI Evals FAQ — сборник распространённых вопросов (и ответов) об оценке LLM. Посмотреть все FAQ или вернуться на главную.