如何评价Agent解决问题的质量

P1 · agent_architecture

🏷 标签：agent, evaluation, metrics, quality, llm-as-judge

1️⃣ 考察意图

面试官想考察你对 Agent 评估体系的系统性理解，而非简单罗列指标。核心在于区分“结果指标”与“过程指标”，并理解它们之间的 trade-off。刁钻点在于：Agent 的“质量”不是单一分数，而是多维度权衡，且评估本身可能引入偏差（如 LLM-as-Judge 的自我偏好）。答好了能展示你从工程落地到评估框架设计的硬实力，包括如何设计自动化评估 pipeline、如何平衡成本与准确性。

2️⃣ 标准答

评估 Agent 质量需从 结果、过程、效率、鲁棒性 四个维度切入，并辅以自动化与人工结合的评估策略。

结果维度：任务完成度

核心指标：任务成功率（Success Rate, SR）和完成度（Task Completion Score, TCS）。例如，客服 Agent 解决用户问题后，SR 定义为“用户确认问题解决”的比例。
评估方法：用 LLM-as-Judge（如 GPT-4）对 Agent 最终输出打分，或构建规则检查（如是否包含订单号、退款金额等关键字段）。坑：LLM 可能偏好冗长回答，需用 prompt 约束（如“只关注事实正确性，忽略格式”）。
工程取舍：SR 高不一定好——如果 Agent 只处理简单任务而拒绝复杂请求，SR 会虚高。需结合任务难度分层统计。

过程维度：步骤合理性

核心指标：工具调用正确率（Tool Call Accuracy, TCA）、中间结果一致性（如多步推理中，前一步输出是否被后一步正确引用）。
评估方法：对 Agent 的每一步进行 trace 分析。例如，用 ReAct 框架时，检查“思考-行动-观察”循环是否逻辑自洽。实际落地坑：Agent 可能“幻觉”工具参数（如调用天气 API 时传入错误城市名），需用 schema 校验（如 JSON Schema 验证参数类型）。
为什么这么做：结果正确但过程错误（如通过暴力尝试而非推理）会导致不可复现，对生产环境是灾难。

效率维度：成本与速度

核心指标：平均步骤数（Avg Steps）、Token 消耗总量、API 调用延迟（P95）。
工程取舍：减少步骤数可能牺牲准确性。例如，用单步大模型直接生成答案（步骤少但可能幻觉），与多步检索+推理（步骤多但准确）之间需权衡。解法：设置步骤数上限（如 10 步），超时则降级为人工。
具体数字：一个典型客服 Agent 的 Token 消耗约 2000-5000/任务，若超过 10000 需优化 prompt 或减少冗余调用。

鲁棒性维度：异常处理

核心指标：错误恢复率（Error Recovery Rate, ERR）、对模糊输入的容忍度（如“帮我查一下”无具体实体时是否主动追问）。
评估方法：构造 adversarial 测试集（如缺失参数、多义指令、API 超时）。坑：Agent 可能陷入死循环（如反复调用同一工具失败），需用循环检测（如 3 次相同错误后终止）。
用户满意度：用 5 点 Likert 量表收集主观反馈，但需注意“用户满意”可能受 Agent 语气影响（如礼貌但错误 vs 正确但生硬）。

自动化评估框架

推荐工具：LangSmith 或 Weights & Biases 的 Agent 评估模块。构建 pipeline：输入测试集 → Agent 执行 → 记录 trace → LLM-as-Judge 打分 + 规则检查 → 输出报告。
实际落地：在 50 个任务上测试客服 Agent，发现 SR 为 85%，但 TCA 仅 70%（工具调用错误多）。优化后，通过增加参数校验和重试机制，TCA 提升至 90%，SR 升至 92%。

3️⃣ 答题模板（30 秒电梯版）

“这个问题我从结果、过程、效率、鲁棒性四个层面回答。结果层面看任务完成度，用 LLM-as-Judge 打分；过程层面看步骤合理性，用 trace 分析工具调用正确率；效率层面关注步骤数和 Token 消耗，需权衡准确性与成本；鲁棒性层面用 adversarial 测试集检测异常恢复能力。总结一句：Agent 质量评估是多维度权衡，必须结合自动指标和人工反馈，避免单一指标误导。”

4️⃣ 高频追问 & 应对

追问 1：LLM-as-Judge 评估 Agent 时，如何避免自我偏好偏差？

应对策略：使用多模型投票（如 GPT-4 + Claude 3 分别打分，取平均）或引入“评估 prompt 模板”约束（如“只评估事实正确性，忽略语气”）。更鲁棒的方法是用对比评估（pairwise comparison），让 LLM 比较 Agent 输出与 ground truth，而非直接打分。实际落地中，我曾在客服场景用 GPT-4 评估，发现它偏好长回答，后改为只检查关键字段（如订单号、退款金额），偏差从 15% 降至 3%。

追问 2：如果 Agent 在复杂任务上 SR 低，但简单任务 SR 高，如何设计综合指标？

应对策略：引入任务难度加权。例如，将任务按步骤数或工具调用次数分为简单（1-3 步）、中等（4-6 步）、复杂（7+ 步），分别计算 SR，再用加权平均（如简单 0.2、中等 0.3、复杂 0.5）。更精细的做法是用 AUC（Area Under Curve）衡量 Agent 在不同难度下的表现曲线。实际坑：难度划分需人工标注，成本高，可先用 LLM 自动分类（如“此任务需要 3 个工具调用，属于中等”）。

追问 3：Agent 评估中，如何量化“用户满意度”？

应对策略：用隐式指标替代显式评分。例如，用户是否在 Agent 回答后立即结束对话（表示满意），或是否重复提问（表示不满）。更直接的方法是用 NPS（Net Promoter Score）抽样调查，但需注意样本偏差（只有极端用户会反馈）。工程取舍：隐式指标噪声大（用户可能因网络中断离开），需结合显式反馈（如“这个回答对你有帮助吗？”按钮）交叉验证。

5️⃣ 避坑 · 常见错误答法

❌ 只提“任务完成率”作为唯一指标 → ✅ 必须结合过程指标（如工具调用正确率），因为 SR 高可能掩盖过程错误（如 Agent 通过暴力尝试成功，但不可复现）。
❌ 认为 LLM-as-Judge 完全可靠，不验证其偏差 → ✅ 需用 ground truth 校准（如人工标注 10% 的测试集，对比 LLM 评分一致性），否则评估本身可能误导优化方向。
❌ 忽略效率指标，只关注准确性 → ✅ 生产环境中，Token 消耗和延迟直接影响成本，需设置预算上限（如每个任务 Token 不超过 5000），否则 Agent 可能因过度推理而不可用。

6️⃣ 简历呼应

如果你有 RAG 项目：从“检索质量影响 Agent 结果”切入，展示你如何用评估框架（如 RAGAS）分析检索召回率与 Agent 最终答案的相关性，并优化 chunking 策略（如 256 token 分块 vs 512 token）。
如果你只做过传统 NLP：用“分类任务评估”类比，如将 Agent 步骤视为多标签分类（每个工具调用是一个标签），用 F1-score 评估步骤正确性，并迁移你的混淆矩阵分析经验。
如果你是校招无项目：聚焦论文复现，如用 ReAct 论文中的评估方法（人工标注 100 个任务，计算 SR 和步骤数），并指出其局限性（未考虑效率），展示你对评估体系的理解深度。

7️⃣ 延伸阅读

《ReAct: Synergizing Reasoning and Acting in Language Models》（论文，提出 Agent 框架与评估方法）
《Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena》（博客，讨论 LLM 评估偏差）
LangSmith Agent Evaluation Guide（工具文档，自动化评估 pipeline 实现）
《Tool Learning with Foundation Models》（论文，工具调用正确率评估）
《The Cost of Intelligence: Token Economics in LLM Agents》（博客，效率指标与成本权衡）

—— 本场面试完 ——