评测

pax大约 11 分钟

评测

Agent 任务怎么测，过程指标和线上漂移。

056 · 中 · 评估一个 Agent 为什么比评估一个基础 LLM 更加困难和复杂？评估的维度有哪些不同？

来源：Hello-Agents Extra01

评估一个Agent比评估一个基础LLM更加困难和复杂，因为评估的对象从一个静态的、单轮的“文本生成器”，转变为一个动态的、多轮的、与环境交互的“决策者”。

困难和复杂性的根源：

交互性与状态空间： 基础LLM是无状态的（stateless），其评估是“输入->输出”的简单模式。而Agent是有状态的（stateful），它与环境进行多步交互，每一步的行动都会改变环境和自身的内部状态。这导致其可能的行为轨迹（trajectory）数量是天文数字，难以完全覆盖。
环境的动态性与不确定性： LLM的评估环境是确定的（相同的输入总是有相同的期望输出范围）。Agent的评估环境（如真实的网页、API）是动态变化的、不可预测的。一个今天还能用的API明天可能就失效了，一个网页的结构可能随时改变，这使得评估结果难以复现。
非确定性（Non-determinism）： 由于LLM本身的采样随机性和环境的动态性，同一个Agent在完全相同的初始任务下，两次执行的结果和路径可能完全不同。
任务的开放性： Agent处理的任务往往是开放式的、没有唯一正确答案的（例如，“帮我预订一张去新加坡的性价比最高的机票”），这使得定义一个简单的“正确/错误”指标变得不可能。

评估维度的不同：

评估维度	基础 LLM	Agent
核心评估对象	单个回答的质量 (Quality of a single response)	整个任务完成过程 (The entire task completion process)
主要维度	- 准确性 (Accuracy) - 流畅性 (Fluency) - 相关性 (Relevance) - 安全性 (Safety)	- 任务成功率 (Task Success Rate): 能否最终完成目标？ - 效率 (Efficiency): 完成任务花了多少资源？（见下文） - 鲁棒性 (Robustness): 能否处理异常和错误？ - 自主性 (Autonomy): 在没有人类干预的情况下能走多远？
新增的过程维度	(无)	- 成本 (Cost): LLM调用次数、API费用、Token消耗。 - 延迟 (Latency): 完成任务的总时间。 - 步骤数 (Number of Steps): 任务分解和执行的步数。 - 纠错能力 (Error Recovery): 从工具报错或错误状态中恢复的能力。
评估方法	静态数据集上的基准测试 (MMLU, HumanEval)	交互式环境中的基准测试 (WebArena, AgentBench)

总结来说，对LLM的评估更像是“产品质量检测”，而对Agent的评估更像是“路况复杂的真实驾驶测试”，不仅要看是否到达终点，更要看驾驶过程中的效率、安全性和应对突发状况的能力。

057 · 中 · 你了解哪些专门用于评估 Agent 能力的基准测试？这些基准通常如何构建测试环境和任务？

来源：Hello-Agents Extra01

是的，随着Agent研究的兴起，一系列专门用于评估Agent能力的基准测试被开发出来，它们的核心特点是提供可控的、可复现的交互式环境。

几个知名的Agent能力基准测试：

WebArena:

专注领域： 网页浏览与操作。
简介： 一个高度逼真的、独立的网页环境模拟器。它复刻了多个真实网站（如电商、论坛、软件开发协作工具）的功能，让Agent在其中完成真实世界的复杂任务。
任务举例： 在电商网站上找到一个满足特定要求（如价格、评分）的商品并加入购物车；在论坛上预订一个会议室。
评估方式： 基于最终网页状态的程序化判断（例如，购物车里是否有正确的商品）。

AgentBench:

专注领域： 通用Agent能力的综合评估。
简介： 一个全面的基准，包含了8个不同环境来评估Agent在不同场景下的能力。
任务举例：
- 操作系统环境： 在一个Linux终端中操作文件、执行命令。
- 数据库环境： 根据自然语言问题，对一个SQL数据库进行查询。
- 知识图谱环境： 在知识图谱中进行多跳推理。
- 游戏环境： 玩一些简单的文字冒险游戏。

GAIA (General AI Assistants):

专注领域： 模拟人类使用真实工具完成复杂任务。
简介： 一个极具挑战性的基准，其问题通常需要Agent进行多步推理，并组合使用多种工具（如网页浏览器、代码解释器、文件操作）才能解决。这些问题被设计得对人类来说很简单，但对AI来说却很困难。
任务举例： “找出引用了论文A和论文B的所有论文中，被引用次数最高的那篇的第三位作者是谁？”

这些基准通常如何构建测试环境和任务？

环境构建 -> 沙箱化与可复现性（Sandboxing & Reproducibility）：

为了安全和可复现，基准测试通常不会让Agent直接访问真实的互联网，而是创建一个受控的、隔离的环境。
方法：
- 使用 Docker 容器来封装一个包含浏览器、终端、文件系统的独立环境。
- 对于网页浏览，通常会本地托管一个网站的静态副本，或使用Web后台模拟器来响应Agent的请求。
- 对API的调用会被重定向到一个模拟（mock）的API服务器上。

任务构建 -> 目标导向（Goal-Oriented）：

任务通常以一个 高层次的目标（high-level goal） 的形式给出，而不是具体的步骤指令。
任务的设计会尽量覆盖多种需要Agent展示的能力，如信息检索、工具使用、推理规划、记忆等。
任务通常附带一个明确的、可程序化验证的成功标准。

评估构建 -> 程序化验证（Programmatic Validation）：

评估的核心是自动判断任务是否成功。
方法： 在Agent完成任务后，一个 评估脚本（evaluator script） 会自动检查环境的 最终状态（final state） 是否满足成功条件。
举例：
- 检查磁盘上是否创建了内容正确的文件。
- 检查购物车的最终状态是否包含了正确的商品和数量。
- 检查Agent提交的最终答案字符串是否与标准答案匹配。

058 · 中 · 在评估一个 Agent 的任务完成情况时，除了最终结果的正确性，还有哪些过程指标是值得关注的？（例如：效率、成本、鲁棒性）

来源：Hello-Agents Extra01

在评估Agent时，只看最终结果的正确性（Task Success）是远远不够的。一个优秀的Agent不仅要能“做对事”，还要“聪明地、高效地、可靠地做事”。因此，关注过程指标至关重要，它们能更全面地反映Agent的智能水平。

值得关注的关键过程指标包括：

1. 效率 (Efficiency):

定义： 衡量Agent完成任务所消耗的资源。效率是决定Agent在现实世界中是否可用的关键因素。
具体指标：
成本 (Cost):
- Token消耗量： Agent在所有思考和生成步骤中消耗的总Token数。
- API调用费用： 如果使用了付费的LLM或工具API，完成一次任务的总花费。
延迟 (Latency):
- 总耗时 (Wall-clock Time): 从任务开始到结束所经过的真实时间。
- 计算时间 (CPU/GPU Time): Agent自身运行所占用的计算时间。
步骤数 (Number of Steps / Turns): Agent执行“思考-行动”循环的总次数。通常，能用更少步骤完成任务的Agent被认为规划能力更强。

2. 鲁棒性 (Robustness):

定义： 衡量Agent在面对非理想、非预期情况时的表现。
具体指标：
错误处理能力 (Error Handling Capability): 当工具返回错误、网页加载失败或遇到预期外的环境状态时，Agent能否识别问题并采取纠正措施（例如，尝试不同的工具、修正输入参数、重新规划）。
抗干扰能力 (Disturbance Resistance): 在环境中加入一些噪声或误导性信息，评估Agent的成功率下降了多少。

3. 自主性与对齐 (Autonomy & Alignment):

定义： 衡量Agent在多大程度上能够独立完成任务，以及其行为是否符合人类的意图。
具体指标：
需要人类干预的次数 (Number of Human Interventions): 在一个需要人类协助的系统中，一个更自主的Agent需要人类帮助的次数更少。
行为可解释性 (Interpretability): Agent的“思考”过程是否清晰、合乎逻辑，是否能让人类理解其决策依据。
计划遵循度 (Plan Adherence): 如果Agent预先生成了一个计划，它在多大程度上遵循了自己的计划。

通过综合评估这些过程指标，我们不仅能知道Agent“是否能行”，还能深入了解它“行不行得好”，并找到针对性的优化方向。

059 · 难 · 如何持续监控和评估一个已经部署上线的 LLM 应用或 Agent 服务的表现，以应对可能出现的性能衰退或行为漂移？

来源：Hello-Agents Extra01

对已部署上线的LLM应用或Agent服务进行持续监控和评估，是一个主动的、循环的过程，旨在应对模型漂移（Model Drift）和数据漂移（Data Drift），确保服务质量的稳定。

数据漂移指生产环境中的输入数据分布发生了变化（例如，用户开始问一些新型的问题），而模型漂移指模型的预测能力因数据漂移而下降。

一个完整的监控评估体系应包含以下几个层面：

1. 采集与日志（Collection and Logging）：

全面日志： 记录每一次请求的完整交互数据，包括用户输入、模型生成的中间步骤（如Agent的思考链）、最终输出、调用的工具、延迟、Token消耗等。
用户反馈： 在产品界面中嵌入明确的用户反馈机制，如“顶/踩”按钮、打分、一键报告问题等。这是最直接的性能信号。

2. 自动化监控（Automated Monitoring）：

监控代理指标（Proxy Metrics）： 监控那些与性能高度相关的、可自动计算的指标。这些指标的异常波动通常是问题的早期预警。
输入指标： 问题长度、主题分布、提问语言等。
输出指标： 回答长度、代码块比例、JSON格式错误率、拒绝回答率等。
过程指标（针对Agent）： 平均执行步数、工具调用频率、工具调用失败率。
自动化质量评估：
定期抽样： 从生产流量中随机抽取一小部分样本。
LLM-as-a-Judge： 使用一个强大的“裁判LLM”，根据一套固定的评估准则（如是否有害、是否跑题），对抽样样本进行自动打分。
对比黄金集： 将抽样样本与一个内部维护的、高质量的“黄金评估集”进行对比，看模型在这些关键问题上的表现是否稳定。

3. 人工审核与分析（Human Review and Analysis）：

定期人工审计： 定期组织运营或评估团队，对生产环境中的随机样本、用户反馈的坏案例、以及自动化监控发现的异常案例进行深入的人工分析。
根本原因分析（Root Cause Analysis）： 对于发现的问题，需要深入分析是哪个环节出了问题？是LLM本身能力退化？是Agent的规划逻辑有误？还是某个工具API发生了变更？

4. 反馈闭环与模型迭代（Feedback Loop and Model Iteration）：

持续的数据管理： 将从生产环境中发现的有价值的案例（特别是失败案例和用户不喜欢的案例）清洗、标注后，持续地加入到评估集和微调数据集中。
定期再训练/微调： 根据积累的新数据，定期对模型进行微调（Fine-tuning）或重新训练（Re-training），以适应新的数据分布和用户需求。
A/B测试： 在上线新版本的模型或Agent逻辑时，使用A/B测试框架，小流量验证新版本的性能是否优于旧版本，确保每次迭代都是正向的。

通过建立这样一个“采集 -> 监控 -> 分析 -> 迭代”的闭环，我们可以主动地管理和维护线上服务的质量，而不是被动地等待用户投诉。