LLM-агенты — отстой. Я провёл последнюю неделю, разрабатывая LLM-агента с возможностью веб-краулинга, используя популярный Python-фреймворк, чтобы собирать информацию о потенциальных лидах из интернета. Результат оказался полным разочарованием.
Агент оказался медленным, нестабильным и с огромным числом багов (звучит знакомо? Передадим привет OpenAI!). Он постоянно делал ненужные вызовы функций, а иногда намертво застревал в бесконечных петлях "рассуждений", которые не имели никакого смысла. В итоге я на это забил и заменил его простым web-scraping скриптом, на написание кода которого у меня ушло 30 минут.
Не поймите неправильно — я большой сторонник LLM-агентов и верю в их потенциал. Но давайте смотреть правде в глаза: построить реально эффективный агент — это совсем не тривиальная задача. Слишком много точек отказа, и даже небольшие сбои могут испортить весь пользовательский опыт.
Тем не менее, не всё так мрачно. Если удаётся выявить эти bottleneck-и и правильно их устранить — горизонты автоматизации становятся практически безграничными. Ключ в том, чтобы уметь грамотно и системно оценивать и улучшать свой LLM-агент.
К счастью для вас, за последний год я помог сотням компаний тестировать и оттачивать их агентов, изучил все доступные бенчмарки (включая новые, которые появляются буквально каждую неделю) и собрал целую армию агентов собственноручно. И сегодня я проведу вас по каждому шагу и расскажу, что нужно знать о том, как правильно оценивать LLM-агенты.
Оценка LLM-агентов vs. Оценка самих LLM
Чтобы понять, чем оценка LLM-агентов отличается от "традиционной" оценки самих LLM, сначала нужно четко определить, что именно делает LLM-агентов уникальными:
LLM-агенты умеют вызывать внешние инструменты и обращаться к API.
LLM-агенты могут действовать с высокой степенью автономности.
LLM-агенты работают на базе фреймворков рассуждения (reasoning frameworks).
Эти особенности напрямую влияют на подход к их оценке. Ниже мы с вами разберемся, как именно агент-специфичные характеристики формируют методологию оценки LLM-агентов.
1. LLM-агенты могут вызывать инструменты и обращаться к API
Возможно, самая примечательная особенность LLM-агентов — это их способность вызывать так называемые "инструменты", то есть API или функции, взаимодействующие с реальным миром: обновление баз данных, покупка акций, бронирование ресторанов, web scraping и многое другое.
Очевидно, такая функциональность — это мощный плюс, если вы довели инженерную часть агента до совершенства. Но на практике почти всегда есть use case, о котором вы не подумали: возможно, агент "предпочитает" бронировать определенные рестораны только по конкретным дням, или — что ещё веселее — зачем-то вызывает 10 вообще не связанных между собой инструментов перед выполнением простейшей задачи web scraping-а.
Такие сценарии демонстрируют сложность и уязвимость механизма вызова инструментов: правильно ли выбран инструмент, корректны ли входные параметры, соответствует ли выход ожиданиям — всё это критически важно. Именно поэтому Tool Calling Metrics (метрики вызова инструментов) становятся центральным элементом в оценке LLM-агентов.
2. LLM-агенты обладают значительно большей автономностью
LLM-агенты функционируют с куда более высоким уровнем автономии. Если традиционное LLM-приложение выдает единственный ответ на один пользовательский ввод, то LLM-агент может пройти через несколько шагов рассуждения, выполнить серию вызовов инструментов — и лишь затем сформировать итоговый ответ.
Как несложно догадаться, это заметно усложняет процесс оценки. Если раньше "тест-кейс" представлял собой простую пару input-output, то теперь он включает в себя и промежуточные шаги рассуждений, и вызовы инструментов.
Эти сложные рабочие процессы (комбинация вызовов инструментов, этапов рассуждения и ответов агента) трудно адекватно оценить с помощью традиционных метрик RAG, таких как релевантность ответа, поскольку они не учитывают ни вызовы инструментов, ни этапы рассуждения. Это подчеркивает необходимость новых метрик, более ориентированных на агентные модели мышления.
Это не значит, что RAG-метрики стоит полностью исключать при оценке LLM-агента — скорее наоборот. Их обязательно стоит применять, особенно если агент работает с retrieval из внешней базы знаний (кстати, вот отличный гайд по RAG-оценке). Но вам также понадобятся дополнительные метрики, специально заточенные под оценку agent workflows — о них я подробнее расскажу в следующих разделах.
3. LLM-агенты работают на базе фреймворков рассуждения
И наконец, LLM-агенты не просто действуют — они рассуждают. Прежде чем выполнить какое-либо действие, например, вызвать инструмент или сгенерировать ответ, агент размышляет, почему именно это действие является подходящим следующим шагом. Этот процесс рассуждения формируется под влиянием различных факторов, включая саму LLM-модель и шаблон промпта (например, если в промпте задано выполнение Chain-of-Thought reasoning).
Оценка промежуточных шагов рассуждения критически важна — именно она позволяет понять, почему агент может не справляться с выбором корректных инструментов или зацикливаться в бесконечных reasoning-петлях. Механизм рассуждения агента — это ядро всей его логики принятия решений, и убедиться в его адекватности и последовательности жизненно необходимо.
До этого момента мы рассмотрели, как вызов инструментов, сложные workflows и reasoning отличают LLM-агентов от классических LLM-приложений и требуют отдельного подхода к метрикам и инструментам оценки.
Тем не менее, важно помнить, что LLM-агент — это всё ещё LLM-приложение в своей основе. А значит, он подвержен тем же ограничениям и вызовам, что и любой "обычный" LLM. Чтобы построить максимально эффективного агента, нужно оценивать его не только с помощью агент-специфичных метрик, но и с применением универсальных метрик LLM-оценки. (Если вы только начинаете разбираться в теме, рекомендую эту статью по ключевым метрикам оценки LLM — отличный старт.)
Разные типы LLM-агентов
Мы уже обсудили три ключевые характеристики, которые делают LLM-агентов уникальными, но важно понимать: не все агенты вызывают инструменты, и не все обладают полноценным механизмом рассуждения. Да, в целом LLM-агенты более автономны, чем стандартные LLM-приложения, но уровень их автономности напрямую зависит от назначения и конкретного use case-а.
Простой чат-бот — это совсем не то же самое, что AI-агент, бронирующий вам авиабилеты, и уж тем более не то же самое, что полнофункциональный голосовой ассистент с доступом к множеству систем и каналов. Определение уровней автономности имеет значение, потому что разные уровни требуют разных подходов к оценке.
Уровень 1: Generator Agent
Большинство LLM-агентов, используемых сегодня в продакшене, относятся к категории Generator Agents. Они включают в себя базовые чат-боты для поддержки клиентов и RAG-приложения. Такие агенты умеют генерировать текст и извлекать релевантную информацию, но не обладают ни памятью, ни способностью к планированию. Это значит, что они не могут учиться на предыдущих взаимодействиях или адаптировать свои ответы со временем.
Агенты этого уровня могут казаться "умными", но на деле они полностью реактивны: они просто отвечают на пользовательские запросы, не имея возможности осмысленно рефлексировать, уточнять свои действия или улучшаться за пределами обучающей выборки и текущего контекста. Generator Agents хорошо подходят для статичных задач вроде Q&A и базовых диалогов, но при этом не обладают реальной автономностью.
Уровень 2: Tool-Calling Agent
Когда говорят о LLM-агентах, чаще всего имеют в виду именно Tool-Calling Agents — именно на этом уровне сегодня сосредоточено основное развитие в области AI. Эти агенты умеют принимать решения о необходимости обращения к внешним источникам: API, базам данных, поисковым системам, и способны выполнять задачи с помощью внешних инструментов — например, бронировать авиабилеты или производить вычисления.
Примеры таких агентов: web-browsing-агенты, AI-ассистенты для научных исследований, GitHub Copilot — то есть системы, которые не просто генерируют текст, но активно подтягивают релевантные данные из внешних источников. Однако, как и Generator Agents, Tool-Calling Agent всё ещё являются реактивными. Они не функционируют независимо, лишены долгосрочного рассуждения и не исправляют ошибки, если это не было явно запрошено.
Уровень 3: Planning Agent
Планирующие агенты выводят ИИ за пределы простого использования инструментов, формируя многошаговые workflows и адаптируя выполнение задач на основе полученных результатов. В отличие от Tool-Calling Agents, они не просто извлекают данные — они оценивают, было ли действие успешным, прежде чем двигаться дальше. Эти агенты отслеживают изменения состояния, уточняют свою стратегию и выстраивают последовательность задач интеллектуально.
Потенциальные примеры включают продвинутых AI-агентов для отладки, которые анализируют логи, пытаются применить исправления и проверяют решения перед переходом к следующему шагу, а также AI для автоматизации workflows, которые выстраивают последовательность вызовов API, отслеживают завершение задач и повторяют неудачные шаги.
Хотя агенты этого уровня больше не требуют явного ввода задачи и имеют встроенные инструменты автоматизации ввода, они всё ещё остаются реактивными. Они не могут инициировать задачи самостоятельно и не сохраняют состояние за пределами одного workflow. После завершения задачи агент прекращает работу.
Уровень 4: Autonomous Agent
Автономные агенты не просто выполняют команды — они инициируют действия, сохраняются между сессиями и адаптируются на основе обратной связи. В отличие от агентов более низкого уровня, они способны отслеживать прогресс, мониторить окружение и выполнять задачи без постоянного участия пользователя.
Такие агенты интегрируют память, механизм рассуждения и самостоятельное выполнение, что позволяет им менять стратегии, если что-то идёт не так. Теоретически, они даже могут разрабатывать новые решения вне рамок заданных workflows, хотя современные ИИ всё ещё слабо справляются с настоящей инновацией и долгосрочной адаптацией. Несмотря на прогресс, создание по-настоящему независимых, самообучающихся агентов всё ещё находится за пределами досягаемости.
Поскольку сегодня большинство агентов работают на уровне 2, я подробно остановлюсь на трёх ключевых аспектах оценки агентов, которые мы ранее кратко упомянули: Tool-Calling Evaluation, Agent Workflow Evaluation и Reasoning Evaluation. Разобрав соответствующие метрики и приведя практические примеры, я покажу, почему эти типы оценки критичны и абсолютно необходимы для вашей пайплайна оценки LLM-агентов.
Оценка использования инструментов (Tool-Use Evaluation)
Оценка использования инструментов фокусируется на двух критически важных аспектах: Tool Correctness — определяет, были ли вызваны корректные инструменты, и Tool-Calling Efficiency — оценивает, насколько эффективно были использованы эти инструменты для достижения нужного результата.
Tool Correctness
Tool Correctness проверяет, соответствует ли поведение агента при вызове инструментов заданным ожиданиям — то есть, были ли вызваны все необходимые инструменты и использовались ли они правильно. В отличие от большинства метрик для оценки LLM, Tool Correctness — это детерминированная метрика, а не субъективное суждение на основе вывода другой LLM (LLM-as-a-judge).
На базовом уровне достаточно просто оценить правильность выбора инструментов. Однако на практике чаще всего также важно анализировать входные параметры, передаваемые в эти инструменты, и точность их выходных данных:
Tool Selection: сравнение инструментов, вызываемых агентом, с идеальным набором инструментов, необходимых для обработки конкретного пользовательского ввода.
Input Parameters: оценка точности входных параметров, переданных в инструменты, по сравнению с эталонными (ground truth) значениями.
Output Accuracy: проверка выходных данных, сгенерированных инструментами, на соответствие ожидаемым результатам.
Важно понимать, что эти параметры представляют уровни строгости, а не отдельные независимые метрики. Оценка входных параметров и выходных данных имеет смысл только в случае правильного выбора инструментов. Если инструменты были выбраны неверно, дальнейшая проверка становится бессмысленной.
Кроме того, оценка Tool Correctness не обязательно должна быть бинарной или требовать полного совпадения:
Order Independence: порядок вызова инструментов может быть неважен, если все необходимые инструменты использованы. В этом случае можно сравнивать множества инструментов, а не конкретные последовательности.
Frequency Flexibility: количество вызовов одного и того же инструмента может не иметь значения, если агент выбрал корректные инструменты и использовал их эффективно.
Все эти аспекты напрямую зависят от ваших критериев оценки, которые, в свою очередь, жестко привязаны к use case-у вашего LLM-агента. Например, медицинский агент, отвечающий за постановку диагноза, может сначала запросить данные из инструмента "medical history database", а затем вызвать "patient symptom checker" — и наоборот. Если оба инструмента использованы корректно и вся релевантная информация учтена, итоговый диагноз всё равно может быть точным.
from deepeval.metrics import ToolCorrectnessMetric
from deepeval.test_case import LLMTestCase, ToolCallParams, ToolCall
test_case = LLMTestCase(
input="What if these shoes don't fit?",
actual_output="We offer a 30-day full refund at no extra cost.",
tools_called=[ToolCall(name="WebSearchTool"), ToolCall(name="QueryTool")],
expected_tools=[ToolCall(name="WebSearchTool")]
)
metric = ToolCorrectnessMetric(
evaluation_params=[ToolCallParams.TOOL, ToolCallParams.INPUT_PARAMETERS],
should_consider_ordering=True
)
metric.measure(test_case)
print(metric.score)
print(metric.reason)Такая же гибкость в оценке применима и к входным параметрам (Input Parameters), и к точности выхода (Output Accuracy). Если инструмент требует несколько параметров на вход, можно рассчитывать долю корректных параметров, а не требовать полного совпадения. Аналогично, если выход представляет собой числовое значение, его можно оценивать по процентному отклонению от ожидаемого результата.
В конечном счёте, ваше определение метрики Tool Correctness должно быть согласовано с вашими критериями оценки и конкретным use case-ом, чтобы действительно отражать ожидаемые результаты и обеспечивать валидность всей оценки.
Tool Efficiency
Не менее важным аспектом, чем корректность вызова инструментов, является эффективность их использования. Неоптимальные паттерны вызова инструментов могут привести к увеличению времени отклика, раздражению пользователей и значительному росту операционных затрат.
Представьте, что вы общаетесь с чат-ботом, помогающим забронировать авиабилет. Если сначала он проверяет погоду, потом конвертирует валюту, и только потом запрашивает доступные рейсы — это излишне запутанный путь. Да, в конечном итоге задача может быть выполнена, но разве не было бы лучше сразу обратиться к API бронирования?
Рассмотрим, как можно оценивать эффективность использования инструментов, начиная с детерминированных методов:
Redundant Tool Usage — измеряет количество инструментов, вызванных без необходимости, то есть тех, которые не вносят прямого вклада в достижение целевого результата. Эта метрика может быть рассчитана как процент ненужных вызовов по отношению к общему количеству вызовов инструментов.
Tool Frequency — оценивает, не вызываются ли инструменты чаще, чем необходимо. Этот метод штрафует вызовы, которые превышают заранее заданный порог количества обращений (в большинстве случаев это просто 1 вызов).
Хотя эти детерминированные метрики дают прочную основу, оценка эффективности использования инструментов в более сложных LLM-агентах может быть затруднена. Поведение таких агентов при вызове инструментов может быстро становиться ветвящимся, вложенным и трудно предсказуемым (поверьте, я пытался).
Более гибкий подход — это использование LLM в роли оценщика (LLM-as-a-judge). Например, один из способов оценки tool efficiency заключается в извлечении цели пользователя (задачи, которую агент должен выполнить) и анализе трека вызовов инструментов: какие инструменты были вызваны, с какими параметрами, какие дали выход, и сравнение этого пути с предоставленным списком доступных инструментов.
Такой подход позволяет определить, был ли выбран наиболее эффективный способ достижения цели. Именно так работает методика DeepEval.
from deepeval.metrics import ToolEffiencyMetric
from deepeval.test_case import LLMTestCase, ToolCall
test_case = LLMTestCase(
input="What if these shoes don't fit?",
actual_output="We offer a 30-day full refund at no extra cost.",
tools_called=[ToolCall(name="WebSearchTool")],
)
metric = ToolEffiencyMetric(
available_tools=[ToolCall(name="WebSearchTool"), ToolCall(name="QueryTool")]
)
metric.measure(test_case)
print(metric.score)
print(metric.reason)Эта метрика не только упрощает расчёт эффективности, но и устраняет необходимость в жёстких спецификациях — например, фиксированном количестве вызовов инструментов. Вместо этого она оценивает эффективность на основе доступных инструментов и их релевантности поставленной задаче.
Оценка Agentic Workflows
Хотя метрики, связанные с вызовом инструментов, критически важны для оценки LLM-агентов, они охватывают только аспект использования инструментов. Для полноценной оценки необходим более широкий подход — тот, который охватывает весь workflow агента.
Это включает анализ всего процесса: от исходного пользовательского ввода, через шаги рассуждения и взаимодействие с инструментами, до финального ответа, который получает пользователь.
Выполнение задачи (Task Completion)
Ключевая метрика для оценки agent workflows — это Task Completion (также известная как task success или goal accuracy). Она измеряет, насколько эффективно LLM-агент справляется с задачей, поставленной пользователем. Определение «выполнения задачи» может значительно различаться в зависимости от контекста самой задачи.
Возьмём, к примеру, AgentBench — первую бенчмаркинговую систему, специально разработанную для оценки способности LLM работать в режиме агента. Она тестирует LLM-модели в восьми различных средах, каждая из которых имеет собственные критерии завершения задачи, включая:
Цифровая карточная игра: здесь критерий успешного выполнения задачи ясен и объективен — цель агента — выиграть игру. Соответствующая метрика — это win rate, то есть количество побед агента.
Онлайн-шоппинг: здесь выполнение задачи менее однозначно. В AgentBench используется кастомная метрика, сравнивающая купленный агентом товар с "идеальным" вариантом. Эта метрика учитывает множество факторов, таких как сходство по цене и сходство по атрибутам, определяемое через сопоставление текстов.
Подобные кастомные метрики особенно эффективны, когда область задач ограничена и сопровождается большим датасетом с эталонными (ground truth) метками. Однако в реальных приложениях агенты часто выполняют широкий и разнообразный набор задач, для многих из которых не существует заранее размеченных эталонов.
Например, LLM-агент с доступом к браузеру может выполнять практически неограниченное количество задач в интернете. В таких случаях собирать и оценивать взаимодействия в продакшене становится непрактично, так как невозможно заранее определить ground truth для каждой возможной задачи. Такая сложность требует более гибкой и масштабируемой системы оценки.
Метрика Task Completion в DeepEval решает эту проблему, используя возможности LLM:
Определяет, в чём заключается задача, исходя из пользовательского ввода.
Анализирует шаги рассуждения, использование инструментов и финальный ответ, чтобы оценить, была ли задача успешно выполнена.
from deepeval import evaluate
from deepeval.metrics import TaskCompletionMetric
from deepeval.test_case import LLMTestCase
metric = TaskCompletionMetric(
threshold=0.7,
model="gpt-4",
include_reason=True
)
test_case = LLMTestCase(
input="Plan a 3-day itinerary for Paris with cultural landmarks and local cuisine.",
actual_output=(
"Day 1: Eiffel Tower, dinner at Le Jules Verne. "
"Day 2: Louvre Museum, lunch at Angelina Paris. "
"Day 3: Montmartre, evening at a wine bar."
),
tools_called=[
ToolCall(
name="Itinerary Generator",
description="Creates travel plans based on destination and duration.",
input_parameters={"destination": "Paris", "days": 3},
output=[
"Day 1: Eiffel Tower, Le Jules Verne.",
"Day 2: Louvre Museum, Angelina Paris.",
"Day 3: Montmartre, wine bar.",
],
),
ToolCall(
name="Restaurant Finder",
description="Finds top restaurants in a city.",
input_parameters={"city": "Paris"},
output=["Le Jules Verne", "Angelina Paris", "local wine bars"],
),
],
)
metric.measure(test_case)
print(metric.score)
print(metric.reason)
# or evaluate test cases in bulk
evaluate([test_case], [metric])С таким подходом больше нет необходимости полагаться на заранее определённые ground-truth датасеты или жёстко зафиксированные кастомные критерии. Вместо этого DeepEval предоставляет гибкость для оценки задач любого типа.
G-Eval для кастомных агентов
Иногда вам нужно оценить что-то специфическое в работе вашего LLM-агента. G-Eval — это фреймворк, который использует LLM с поддержкой Chain-of-Thought (CoT) reasoning для оценки выводов агента по любым пользовательским критериям.
Это означает, что вы можете задавать кастомные метрики на естественном языке для анализа workflow агента.
Представим, например, ассистента по бронированию ресторанов. Одна из типичных проблем — агент говорит пользователю: «Ресторан полностью забронирован», но не указывает, проверял ли он альтернативные даты или близлежащие заведения. Для пользователя такой ответ может показаться неполным и бесполезным. Чтобы убедиться, что результат действительно отражает весь объём предпринятых агентом действий и способствует улучшению пользовательского опыта, вы можете задать кастомные критерии оценки с помощью G-Eval, например:
from deepeval.metrics import GEval
from deepeval.test_case import LLMTestCaseParams
transparency_metric = GEval(
name="Transparency",
criteria="Determine whether the tool invocation information is captured in the actual output.",
evaluation_params=[LLMTestCaseParams.ACTUAL_OUTPUT, LLMTestCaseParams.TOOLS_CALLED],
)Оценка агентного рассуждения (Agentic Reasoning Evaluation)
Мы все видели бенчмарки вроде MMLU и задач на рассуждение, таких как BoolQ, используемые для тестирования способности LLM справляться с математическим, здравым и причинно-следственным рассуждением. Хотя такие бенчмарки полезны, они зачастую предполагают, что навыки рассуждения модели полностью определяются ее внутренними возможностями. Но на практике это редко соответствует действительности.
В реальных сценариях рассуждение вашего LLM-агента формируется не только самой моделью. Такие факторы, как шаблон промпта (например, chain-of-thought), использование инструментов и архитектура агента играют критически важную роль. Тестирование модели в изоляции может дать вам отправную точку, но оно не покажет, насколько эффективно агент работает в реальных пайплайнах, где все эти элементы вступают в игру.
Помимо этого, необходимо учитывать конкретную предметную область агента. Каждая задача и каждый workflow уникальны, и адаптация метрик под ваш конкретный кейс — лучший способ убедиться, что рассуждение агента как точное, так и практически полезное.
Вот несколько метрик, которые можно использовать для оценки reasoning'а, специфичного для агента:
Reasoning Relevancy: Насколько обоснован выбор инструмента в контексте запроса пользователя? Например, если агент обращается к базе данных ресторанов, должно быть ясно, почему он это делает — он проверяет наличие мест, потому что пользователь это запросил.
Reasoning Coherence: Следует ли рассуждение логическому, пошаговому процессу? Каждый шаг должен вносить вклад в решение задачи и быть осмысленным в рамках текущего контекста.
Заключение
Не верится, что ты добрался до конца — поздравляем с тем, что стал экспертом в оценке LLM-агентов! Подытожим: LLM-агенты отличаются от обычных LLM-приложений своей способностью вызывать внешние инструменты и осуществлять рассуждение.
А это значит, что необходимо оценивать не только корректность tool-calling'а и логичность reasoning-шагов, но и весь агентный workflow, в котором эти элементы объединяются. К счастью, DeepEval предоставляет все необходимые метрики "из коробки" и готов к использованию.
