LLM agent太烂了。我过去一周用了一个流行的 Python 框架构建了一个网络爬虫LLMagent，想从互联网上抓取一些潜在客户的信息。结果完全让人失望。
那个agent运行缓慢、表现不稳定且问题百出（听起来耳熟吗？@OpenAI 的同行们）。它不断进行不必要的函数调用，偶尔还会陷入毫无意义的无限推理循环中。最终，我放弃了它，转而用 30 分钟编写了一个简单的网页抓取脚本。
别误会—我是LLM agent的坚定支持者，完全相信它们的潜力。但现实是：构建一个高效的agent绝非易事。无数环节可能出错，即便是微小的瓶颈也可能决定用户体验的成败。
话虽如此，并非全是悲观失望。如果你能识别这些瓶颈并实施正确的改进措施，自动化的可能性将是无限的。关键在于懂得如何正确且有效地评测和改进你的LLM智能体。
对你来说幸运的是，过去一年里，我帮助了数百家公司测试和完善他们的智能体，深入研究了能找到的每一个LLM智能体基准（包括不断涌现的新基准），并亲自组建了一支智能体大军。今天，我将带你全面了解关于LLM智能体评测的一切。
LLM智能体评测与LLM评测对比
要理解LLMagent评测与“传统”LLM评测有何不同，首先明确这些LLM agent的独特之处至关重要。
- LLM agent能够调用工具和 API
- LLM agent可以具有高度自主性
- LLM agent由推理框架驱动
这些agent特有的属性如何影响我们对LLMagent的评测方式
1. LLM agent可以调用工具和 API
LLMagent最显著的特性或许在于它们能够调用和激活“工具”，比如能与现实世界交互的 API 或函数——更新数据库、购买股票、预订餐厅，甚至进行网页抓取。
显而易见，如果你已经精通agent工程，这将是极好的。然而，很可能存在你尚未了解的用例：或许你的agent更倾向于在特定日子预订某些餐厅，又或者偶尔在执行简单的网页抓取任务前会调用 10 个完全不相关的其他工具。
工具调用的这些复杂性及潜在错误——无论是调用正确的工具、使用正确的工具输入参数，还是生成正确的工具输出——使得工具调用指标成为评测LLM智能体的关键要素。
2. LLM 智能体的自主性显著增强
LLM 智能体以更高的自主性运作。传统的LLM应用通常针对单一用户输入生成单一响应，而LLM智能体可能进行多步推理、调用多个工具，之后才作出回应。
正如你所想象的那样，这一转变略微复杂化了评测流程。虽然单个“测试用例”过去可能简单到仅是一对输入输出，但现在它还包含了中间推理步骤和调用的工具。
这些复杂的工作流程（包括工具调用、推理步骤和agent响应的集合）难以通过传统的 RAG 指标如答案相关性来准确衡量，因为这些指标未考虑工具调用和推理步骤，因此需要更适合此类agent式思维过程的新评测标准。
这并不是说你不应该使用 RAG 指标来评测你的LLM智能体——实际上恰恰相反。你绝对会想要使用它们，特别是当你的智能体从知识库中检索信息时（事实上，这里有一份关于 RAG 评测的绝佳指南）。但你还需要一些专门为评测智能体工作流程量身定制的额外指标，我将在下面的章节中进一步深入探讨。
3. LLM 智能体由推理框架驱动
最后，LLMagent不仅行动——它们还会推理。在执行任何操作（如调用工具或构建响应）之前，agent会深思熟虑为何该操作是合适的下一步。这一推理过程受多种因素影响，包括LLM模型和提示模板（即指定其执行 CoT 推理）。
评测这些中间推理步骤至关重要，因为它能揭示为何你的agent可能难以持续选择正确的工具或陷入无限循环。agent的推理引擎支撑着其所有决策过程，因此确保其逻辑合理极其重要。
迄今为止，我们已经探讨了工具调用、工作流和推理如何区分LLMagent，这要求我们拥有专门的评测工具和指标集。
然而，重要的是要记住，LLM agent本质上仍是一个LLM应用程序。因此，它与任何“普通”LLM应用程序一样，面临着相同的挑战和限制。为了构建最佳版本的LLM agent，除了agent特定的指标外，还需使用通用LLM指标对其进行评测。
不同类型的LLM agent
我们已经讨论了使LLM agent与众不同的三个关键特性，但并非所有agent都会调用工具，也并非所有agent都能进行推理。诚然，LLM agent通常比标准的LLM应用程序更具自主性，但其自主程度取决于它们的设计目的和具体应用场景。
一个简单的聊天机器人不同于能为你预订航班的人工智能agent，后者又与能行走、交谈的个人助理相去甚远。明确这些自主级别很重要，因为不同级别需要不同的评测方法。
级别 1：生成型agent
目前生产环境中的大多数LLM agent都是生成型agent。这包括基础的客户支持聊天机器人和基于 RAG 的应用。虽然它们能够生成文本并检索相关信息，但缺乏记忆和规划能力，意味着它们无法从过去的互动中学习，也无法随时间调整其响应。
这一级别的agent可能显得智能，但它们完全是反应式的——仅能根据用户查询做出回应，无法进行反思、优化或超越其训练数据或给定上下文进行改进。它们适用于静态问答和基础对话任务，但缺乏真正的自主性。
级别 2：工具调用agent
当人们谈论LLM Agents 时，通常指的是工具调用agent——这是当前大多数 AI 开发的重点所在。这类agent能决定何时从 API、数据库或搜索引擎检索信息，并能利用外部工具执行任务，比如预订航班或进行计算。
例子包括网页浏览agent、AI 研究助手和 GitHub Copilot——这些 AI 系统不仅能生成文本，还能主动获取相关数据。然而，与生成型agent一样，工具调用agent仍是被动响应的。它们无法独立运作，缺乏长期推理能力，除非明确提示，否则不会纠正错误。
级别 3 ：规划型智能体
规划型智能体通过构建多步骤工作流并根据执行结果调整策略，将 AI 的应用提升至超越简单工具使用的层面。与工具调用型智能体不同，它们不仅获取数据——还会在推进前评测行动是否成功。这类智能体能感知状态变化、优化方法，并智能地编排任务顺序。
潜在示例包括分析日志、尝试修复并在继续之前验证解决方案的高级 AI 调试agent，以及排序 API 调用、监控任务完成情况并重试失败步骤的工作流自动化 AI。
尽管此级别的agent不再需要明确的任务输入，并内置了输入自动化工具，但它们仍是被动响应的。它们无法自主启动任务，且不会在单一工作流之外持续存在。一旦任务完成，agent即停止运行。
级别 4 ：自主agent
自主agent不仅能执行命令——它们还能主动发起行动，跨会话持续运行，并根据反馈进行自我调整。与低级agent不同，它们能够追踪进度、监控环境，并在无需用户持续输入的情况下执行任务。
这些智能体集成了记忆、推理与自主执行能力，使其能在策略失效时进行调整。理论上，它们甚至能开发出超越预设流程的新解决方案，但当前人工智能仍难以实现真正的创新和长期适应性。尽管进展不断，完全独立且能自我完善的智能体仍遥不可及。
鉴于现今大多数智能体运行于第二层级，我将深入探讨先前简要提及的智能体评测三大核心要素：工具调用评测、智能体工作流评测及推理评测。通过分析相关指标并分享实际案例，我将阐明为何这些评测至关重要，且对你的LLM智能体评测流程绝对不可或缺。
工具使用评测
评测工具使用聚焦于两个关键方面：工具正确性，即判断是否调用了正确的工具；以及工具调用效率，即评测是否以最高效的方式使用工具来达成预期结果。
工具正确性
工具正确性通过验证是否所有必需的工具都被正确调用来评测agent的工具调用行为是否符合预期。与大多数LLM评测指标不同，工具正确性指标是一个确定性度量，而非LLM判断。
在最基础的层面上，仅评测工具选择本身已足够。但更多时候，你还需要考量传入这些工具的输入参数及它们生成结果的输出准确性：
- 工具选择：将智能体调用的工具与针对特定用户输入所需理想工具集进行比较。
- 输入参数：评测传入工具的输入参数相对于基准真值参考的准确性。
- 输出准确性：将工具生成的输出与预期基准真值进行验证。
值得注意的是，这些参数代表严格程度而非独立指标，因为评测输入参数和输出准确性依赖于正确工具的调用。若使用了错误的工具，这些参数的评测便失去意义。
此外，工具正确性评分不必是二元的或要求完全匹配：
- 顺序无关性：只要所有必要工具都被使用，工具调用的顺序可能无关紧要。在此类情况下，评测可侧重于比较工具集而非精确序列。
- 频率灵活性：相较于确保正确选择和有效使用工具，每个工具被调用的次数可能不那么重要。
这些考虑因素都取决于你的评测标准，这与你的LLM agent的使用场景密切相关。例如，一个负责诊断患者的医疗 AI agent可能在从“病史数据库”工具检索数据后查询“患者症状检查器”工具，而不是相反顺序。只要两个工具都正确使用且所有相关信息都考虑在内，诊断结果仍可能是准确的。
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)
同样的评分灵活性也适用于输入参数和输出准确性。如果一个工具需要多个输入参数，你可以计算正确参数的百分比，而非要求完全匹配。类似地，如果输出是数值，你可以测量其与预期结果的百分比偏差。
最终，你对工具正确性指标的定义应与评测标准和使用场景保持一致，以确保其有效反映期望的成果。
工具效率
与工具正确性同等重要的是工具效率。低效的工具调用模式会延长响应时间，令用户沮丧，并大幅增加运营成本。
想想看：假设一个聊天机器人帮你预订航班。如果它先查看天气，再转换货币，最后才搜索航班，那岂不是走了不必要的弯路？当然，最终它可能完成任务，但如果直接调用航班 API，效率岂不是高得多？
让我们从确定性方法开始，探讨如何评测工具效率：
- 冗余工具使用衡量了多少工具被不必要地调用——这些调用并未直接促成预期结果的达成。其计算方式为不必要工具调用次数占总工具调用次数的百分比。
- 工具频率评测工具是否被调用得过于频繁。此方法会对完成任务所需调用次数超过预设阈值（通常仅为 1 次）的工具进行惩罚。
虽然这些确定性指标提供了坚实的基础，但在评测更复杂的LLM agent工具效率时可能会遇到挑战。这类agent中的工具调用行为可能迅速变得分支化、嵌套且错综复杂（相信我，我试过）。
一种更灵活的方法是使用LLM作为评判标准。例如，计算工具效率的一种方式提取用户目标（agent需要完成的任务），并根据调用的工具（如名称、描述、输入参数、输出）和提供的可用工具列表评测工具调用轨迹，以确定该轨迹是否为最高效的方法（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)
该指标不仅简化了效率计算，还避免了诸如固定工具调用次数等硬性规范要求，而是根据可用工具及其与当前任务的相关性来评测效率。
评测agent工作流程
虽然工具调用指标对于评测LLM agent至关重要，但它们仅聚焦于使用情况。然而，有效的评测需要更广阔的视角——即审视agent的整个工作流程。
这包括评测整个过程：从用户的初始输入开始，经过推理步骤和工具交互，直至向用户提供的最终响应。
任务完成率
评测agent工作流的一个关键指标是任务完成率（也称为任务成功率或目标准确率）。该指标衡量LLM agent完成用户给定任务的有效性。“任务完成”的定义可能因任务上下文而有显著差异。
考虑 AgentBench，这是首个旨在评测LLMs作为agent能力的基准测试工具。它在八个不同的环境中测试LLMs，每个环境都有独特的任务完成标准，包括：
- 数字卡牌游戏中，任务完成标准明确且客观——智能体的目标是赢得比赛。对应指标为胜率，即智能体获胜的场次。
- 网络购物场景下，任务完成度的衡量更为复杂。AgentBench 采用定制化指标，通过对比智能体购买的商品与理想商品进行评测。该指标综合考虑价格相似度及通过文本匹配确定的属性相似度等多重因素。
当任务范围有限且伴随大量带有真实标签的数据集时，此类定制化指标极为有效。然而，在实际应用中，智能体常需执行多样化的任务集——其中许多可能缺乏预定义的真实数据集。
例如，一个配备有网页浏览器等工具的LLM agent能够执行几乎无限的基于网络的任务。在这种情况下，收集和评测生产环境中的交互变得不切实际，因为无法为每一个可能的任务定义真实参考标准。这种复杂性需要一个更加灵活和可扩展的评测框架。
DeepEval 的任务完成度指标通过利用LLMs来解决这些挑战，具体包括：
- 根据用户的输入确定任务。
- 分析推理步骤、工具使用情况及最终响应，以评测任务是否成功完成。
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])
采用这种方法，你不再需要依赖预定义的真实数据集或严格的定制标准。相反，DeepEval 为你提供了灵活评测各类任务的能力。
G-Eval 自定义agent评测
有时，你会想评测你的LLM agent的某些具体方面。G-Eval 是一个框架，它利用LLMs结合思维链（CoT）推理，基于任何自定义标准来评测输出。
这意味着你可以用自然语言定义自定义指标来评测agent的工作流程。
考虑一个餐厅预订助手。常见的问题可能是，助手告诉用户“餐厅已订满”，但遗漏了重要背景信息，比如是否检查了其他可选日期或附近餐厅。对用户而言，这样的回答可能显得不完整或帮助不大。为确保输出能全面反映助手的努力并提升用户体验，你可以用 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],
)
agent推理评测
我们都见过用 MMLU 等基准测试和 BoolQ 类推理任务来检验LLM处理数学、常识及因果推理的能力。虽然这些基准测试有其价值，但它们常假设模型的推理能力完全取决于其内在性能。然而实践中，这很少是全部真相。
在现实场景中，你的LLM智能体的推理能力远不止由模型本身决定。提示模板（如思维链推理）、工具使用以及智能体架构等因素都起着关键作用。单独测试模型或许能提供一个起点，但无法全面反映这些因素交织时智能体在实际工作流中的表现。
除此之外，你还需要考虑agent的具体领域。每项任务和工作流程都各不相同，针对你的独特用例定制评测是确保agent推理既准确又有用的最佳方式。
以下是可用于评测特定智能体推理能力的几项指标：
- 推理相关性：每次工具调用的理由是否明确关联用户需求？例如，若智能体查询餐厅数据库，其行为动机应清晰可辨——因用户要求而进行可用性检查。
- 推理连贯性：推理过程是否符合逻辑且逐步推进？每个步骤都应在任务背景下提供价值并言之成理。
结论
真不敢相信你一路坚持到了这里！恭喜你成为LLM智能体评测专家。总结来说，LLM智能体区别于常规LLM应用的核心在于其调用工具与执行推理的能力。
这意味着我们需要评测工具调用、推理步骤以及整合这些能力的完整agent工作流。幸运的是，DeepEval 已内置并提供这些开箱即用的评估指标。
