如何量化评估 Agent 性能优化的效果
1️⃣ 考察意图
面试官想看你能否建立 Agent 性能评估体系。刁钻点在于：Agent 性能不只是"延迟降低"——需要在延迟、成本、质量三个维度同时评估，且优化一个维度可能影响另一个（如压缩 prompt 降成本但可能降质量）。答好了能展示你的数据驱动思维和多目标优化能力。
2️⃣ 标准答
1. 三维评估框架
| 维度 | 指标 | 测量方法 | 优化方向 |
|---|---|---|---|
| 延迟 | P50/P99 端到端延迟 | 分布式追踪 | 并行化、缓存、Prompt压缩 |
| 延迟 | TTFT（首字延迟） | LLM API 日志 | Prompt Caching、Prefix Caching |
| 延迟 | TPOT（单token延迟） | LLM API 日志 | Speculative Decoding、量化 |
| 成本 | 每次任务 Token 消耗 | LLM API 用量统计 | Prompt 压缩、结果缓存 |
| 成本 | 每次任务 LLM 调用次数 | Agent Trace 统计 | 减少步数、合并工具调用 |
| 成本 | 每次任务总成本 | Token × 单价 + 工具费用 | 综合优化 |
| 质量 | 任务完成率 | 人工标注 + 自动化检测 | 不降低质量前提下优化 |
| 质量 | LLM-as-Judge 评分 | GPT-4o 评估输出质量 | 监控优化对质量的影响 |
| 质量 | 用户满意度 | CSAT/NPS | 最终用户体验指标 |
2. 评估方法论
- 基准测试（Benchmark）：固定 100-500 个典型请求作为基准集
- 优化前后分别跑基准集，记录三维指标
- 对比报告：延迟变化、成本变化、质量变化 A/B 测试：
- 线上流量分流：50% 旧版本 vs 50% 新版本
- 运行 1-2 周，统计三维指标的差异
- 统计显著性检验：t-test 或 Mann-Whitney U（p < 0.05） 回归测试：
- 每次优化后跑"黄金集"（50 个核心场景）
- 检查优化是否导致质量退化
- 自动化判断：格式正确率、工具调用准确率、LLM-as-Judge 评分
3. 多目标优化的 Trade-off 分析
- 延迟 vs 质量：Prompt 压缩降延迟但可能丢信息。需要找到"质量不下降的最大压缩率"。方法：逐步增加压缩率，每步测质量，画"压缩率-质量"曲线，找拐点
- 成本 vs 质量：用小模型替代大模型降成本但质量下降。方法：对比 GPT-4o vs GPT-4o-mini 在同一任务上的质量差异，如果差异 <5% 则用小模型
- 延迟 vs 成本：并行工具调用降延迟但可能增加 LLM 调用次数（并行需要独立 LLM 调用）。方法：计算"每节省 1s 延迟增加多少成本"，判断是否值得
4. 评估报告模板
`## Agent 性能优化报告**
优化内容
- Prompt 压缩（对话历史摘要 + 工具Schema精简）
- 工具调用并行化（无依赖工具 asyncio.gather）
- Prompt Caching（system prompt KV Cache 复用）
基准测试结果（100 个典型请求）
| 指标 | 优化前 | 优化后 | 变化 |
|---|---|---|---|
| P50 延迟 | 12.5s | 6.8s | -46% ✅ |
| P99 延迟 | 28.3s | 14.2s | -50% ✅ |
| TTFT | 2.1s | 0.8s | -62% ✅ |
| Token/任务 | 18.5k | 7.2k | -61% ✅ |
| 成本/任务 | $0.046 | $0.018 | -61% ✅ |
| 任务完成率 | 87% | 85% | -2% ⚠️ |
| LLM-Judge评分 | 0.82 | 0.79 | -3.7% ⚠️ |
| 用户CSAT | 4.1/5 | 4.0/5 | -2.4% ⚠️ |
结论
延迟和成本优化显著（-46%-62%），但质量有轻微下降（-2%-3.7%）。
建议：接受质量微降换取性能提升，或调整压缩率找回质量。`
3️⃣ 答题模板（30 秒电梯版）
"Agent 性能评估三维框架：延迟（P50/P99端到端、TTFT、TPOT）、成本（Token/任务、LLM调用次数、总成本）、质量（任务完成率、LLM-Judge评分、CSAT）。方法：基准测试（100-500固定请求对比）+ A/B测试（线上分流统计显著性）+ 回归测试（黄金集质量检查）。Trade-off分析：延迟vs质量（画压缩率-质量曲线找拐点）、成本vs质量（大小模型质量差<5%则换小）、延迟vs成本（每省1s增加多少成本）。核心：优化不能只看一个维度，三维联动评估。"
4️⃣ 高频追问 & 应对
追问 1**：质量下降 3.7% 是否可接受？怎么判断？
判断标准取决于业务场景：(1) 高合规场景（医疗、法律）——质量下降 >1% 不可接受。即使延迟降 50% 也不能牺牲质量；(2) 一般场景（客服、搜索）——质量下降 <5% 可接受，但需要监控用户满意度趋势。如果 CSAT 持续下降超过 2 周，回滚优化；(3) 实验性场景（内部工具）——质量下降 <10% 可接受，优先降低成本和延迟。判断方法：设定"质量红线"（如任务完成率 >85%、CSAT >3.8），优化后任何指标低于红线则回滚。另外，质量下降的"性质"比"幅度"更重要——如果是"输出格式略有变化"可接受，如果是"安全检查被绕过"不可接受。
追问 2：基准测试的 100 个请求怎么选？和回放测试的黄金集一样吗？
可以共用但有区别：(1) 基准集——用于性能评估，选"代表性"请求（覆盖不同任务类型、不同复杂度）。关注延迟和成本指标；(2) 黄金集——用于回归测试，选"高价值"请求（核心业务场景、历史出过 bug 的场景）。关注质量指标。两者可以重叠——黄金集可以是基准集的子集（50 个核心场景同时用于性能和质量评估）。维护：基准集每季度更新（加入新出现的请求模式），黄金集每次线上 bug 后更新（加入导致 bug 的请求）。关键：两个集都需要"期望输出"标注——基准集标注"期望延迟和成本"，黄金集标注"期望输出格式和行为"。
追问 3：Agent 的多步执行使得延迟分布有长尾（少数任务 50+ 步），怎么处理？
长尾处理三层：(1) 分析长尾原因——50+ 步的任务通常是复杂任务或"陷入循环"的任务。用 Trace 分析区分"合理的复杂任务"和"循环 bug"。循环 bug 修复后长尾消失；(2) 步数上限——设硬限制（如 20 步），超过则强制停止并返回当前最佳结果。P99 延迟从 50s 降到 20s（步数上限的延迟上界）。代价：1-2% 的复杂任务被截断，但 98% 的用户体验提升；(3) 分位数报告——不只看 P50/P99，还看 P99.9 和 Max。如果 Max 是 P99 的 10 倍（如 P99=15s 但 Max=150s），说明有极端长尾。针对极端长尾设"超时熔断"（60s 强制停止）。实测：步数上限 20 + 超时 60s 将 P99.9 从 120s 降到 25s，影响 <0.5% 的任务。
5️⃣ 避坑 · 常见错误答法
- ❌ "优化就是降低延迟" → ✅ "Agent 性能是三维的——延迟、成本、质量。优化一个维度可能影响另一个。需要三维联动评估，设定质量红线。"
- ❌ "基准测试跑一次就够了" → ✅ "LLM 的概率性导致基准测试结果有波动。需要跑 3-5 次取平均值，并用 t-test 检验优化效果的统计显著性。"
- ❌ "质量下降可以后续修复" → ✅ "质量下降可能在优化上线后才显现（用户反馈滞后）。必须在上线前用回归测试+黄金集验证质量不下降。一旦上线后发现质量下降，需要快速回滚。"
6️⃣ 简历呼应
- 如果你有 Agent 性能优化项目：从"三维评估体系"切入，描述你建立的基准测试+A/B测试+回归测试 pipeline，给出优化数据（如延迟 -46%、成本 -61%、质量 -2%）
- 如果你有 A/B 测试经验：用"Web A/B 测试"迁移——分流失策、样本量计算、统计显著性检验直接适用。核心差异是 Agent 需要三维评估（延迟+成本+质量）而非单一指标
- 如果你是校招无项目：设计一个 Agent 性能评估框架，实现基准测试+回归测试，用模拟数据演示三维 trade-off 分析
- "MLPERF Inference: Benchmarking AI Systems" (MLCommons, 2024)
- "Evaluating LLM Applications: A Practical Guide" (Hamel Husain, 2024)
- "Agent Performance Optimization: A Multi-Dimensional Approach" (LangChain, 2024)
本章学习完毕 ← 返回 Agent 岗面试宝典 v3 · 精华版 | 📝 建议整理错题笔记 | 🎯 标记掌握程度