指标缺失时会发生什么
一个 RAG 问答系统上线了。工程师说"测试都通过了"——API 响应时间 < 2 秒，格式正确，没有崩溃。
两周后用户反馈说"AI 经常答非所问"。排查后发现：检索召回率只有 40%，超过一半的用户问题找不到相关文档。
这个问题上线前就存在。没有人设计过"检索质量"这个指标，所以没人看到它。
L1/L2/L3 三层指标框架
指标按层次组织，对应不同的问题类型：
L1 — 业务结果（Business Outcome）
最终目标：AI 系统是否在创造价值？
示例：任务完成率、用户采纳率、用户满意度
L2 — 输出质量（Output Quality）
中间层：AI 的输出本身质量如何？
示例：准确性、相关性、完整性
L3 — 系统健康（System Health）
基础层：系统运行是否稳定？
示例：响应时延、Token 消耗、失败率
三层的依赖关系：
L3 不健康 → 影响 L2（超时导致输出截断）→ 影响 L1（任务失败）
L3 健康但 L2 差 → L1 仍然低（用户不采纳低质量输出）
三层都健康 → L1 才真正有价值
告警时从 L3 往上排查，比从 L1 往下倒推快得多。
四类场景的指标选择
场景 1：文档问答（RAG）
L3 系统健康：
响应时延 P90 → < 5s
Token 消耗/次 → < 3000
检索失败率 → < 1%
L2 输出质量：
Faithfulness → 回答有没有编造，基于检索内容（RAGAS）
Answer Relevancy → 回答有没有回答问题（RAGAS）
Context Precision → 检索结果里有用的占比（RAGAS）
Context Recall → 相关内容有没有都检索到（RAGAS）
L1 业务结果：
任务完成率 → 用户标记"解决了问题"的比例
采纳率 → 用户复制/引用了 AI 回答的比例
关键指标： Context Recall（检索召回率）是 RAG 系统最容易被忽略又最重要的指标。检索没找到，生成再好也没用。
场景 2：代码生成
L3：
响应时延 P90 → < 10s（代码生成比问答慢，阈值适当放宽）
超长输出率 → 避免生成远超需要的代码量
L2：
语法正确率 → 生成代码能否通过解析器（可自动化）
测试通过率 → 生成代码能否通过单元测试（可自动化）
代码可用率 → 人工评估：生成代码需要多少修改才能用
安全扫描通过率 → 生成代码是否包含已知安全漏洞（可自动化）
L1：
采纳率 → 用户接受了 AI 建议的比例
修改幅度 → 用户修改了多少（修改越少质量越高）
关键指标： 测试通过率可以完全自动化，是代码生成 L2 的核心指标。自动化程度高，适合接入 CI。
场景 3：文档摘要
L2：
Faithfulness → 摘要没有引入原文没有的内容（最重要）
覆盖率 → 原文关键要点有没有出现在摘要里
简洁性 → 摘要是否明显比原文短（否则没有价值）
阅读流畅度 → LLM-as-Judge 评估
关键指标： Faithfulness（忠实度）。摘要最大的风险是"补充"了原文没有的信息（幻觉），这比遗漏某个要点更有害。
场景 4：Agent 任务完成
L2：
工具调用准确率 → 选了正确工具、参数正确（可自动化）
步骤效率 → 完成任务用了多少步（步数越少越好）
轨迹质量 → 推理过程是否合理（LLM-as-Judge）
L1：
任务完成率 → 最终任务有没有完成（核心）
首轮解决率 → 不需要追问即完成的比例
关键指标： 任务完成率是 Agent 评测的核心 L1 指标，但需要定义清楚"完成"的标准——产出物存在 vs 产出物质量达标，是不同的要求。
常见陷阱
陷阱 1：只测 L3
✗ 错误做法：
"API 没有报错，延迟 1.2 秒，这个版本可以上线。"
问题：L3 健康不等于系统有价值。上线那个 RAG 系统的案例
就是这样——L3 完全正常，但 L2 的检索召回率只有 40%。
每次发布至少要看一次 L2 的抽样评测结果。
陷阱 2：用 BLEU/ROUGE 评测语义质量
# 看起来合理
rouge_score = rouge.compute(predictions=[output], references=[reference])
# 实际问题：
reference = "The capital of France is Paris."
output_1 = "Paris is the capital city of France." # 语义相同，ROUGE 低
output_2 = "The capital of France is Paris, the capital." # 字面重复，ROUGE 高
# ROUGE 给 output_2 更高分，但 output_2 明显更差
BLEU/ROUGE 测词汇重合度，不测语义正确性。对于生成式输出，用 LLM-as-Judge 替代。BLEU/ROUGE 只适合评测机器翻译这类有标准参考答案的任务。
陷阱 3：阈值凭感觉定
✗ 错误：
"我们定 Faithfulness > 0.8 作为质量门控。"
（为什么是 0.8？因为听起来合理。）
✓ 正确：
Step 1：先跑 100 个样本，得到当前基线（比如均值 0.73）
Step 2：看 Faithfulness < 0.6 的样本，人工判断是否可接受
Step 3：根据人工判断结果定阈值（比如 0.65）
Step 4：阈值要写清楚"低于此值的样本不可接受"的依据
阈值不是凭感觉或对齐经验值，而是从数据分布和业务可接受性倒推出来的。
企业文档问答系统的完整指标体系示例
# eval_metrics.yaml
system: document-qa
version: "1.0"
metrics:
l3_system_health:
- name: response_latency_p90
target: "< 5000ms"
collection: trace_log
alert_threshold: 8000ms
- name: token_cost_per_query
target: "< 2000 tokens"
collection: llm_callback
alert_threshold: 4000
- name: retrieval_error_rate
target: "< 1%"
collection: error_log
l2_output_quality:
- name: faithfulness
tool: ragas
target: "> 0.80"
collection: weekly_sampling (n=100)
alert_threshold: 0.70
- name: answer_relevancy
tool: ragas
target: "> 0.75"
collection: weekly_sampling
- name: context_recall
tool: ragas
target: "> 0.70"
collection: weekly_sampling
note: "最重要的检索质量指标"
- name: format_compliance
tool: rule_check
target: "100%"
collection: every_request
l1_business_outcome:
- name: task_completion_rate
target: "> 70%"
collection: user_feedback_widget
note: "用户点击'解决了我的问题'的比例"
- name: adoption_rate
target: "> 50%"
collection: behavior_tracking
note: "用户复制/引用 AI 回答的比例"
指标体系建立路线图
第一步（立即可做，不需要工具）：
□ 写下这个 AI 系统的核心业务目标（L1 是什么）
□ 列出 3-5 个最重要的 L2 输出质量维度
□ 确认 L3 的基本监控（延迟、错误率）
第二步（1 周内）：
□ 用 50 个真实用例手动评测，得到每个 L2 指标的基线数字
□ 根据基线数字，定出合理的阈值（不是凭感觉）
第三步（持续）：
□ 每次发布前跑 L2 抽样评测，与基线对比
□ 每月看一次 L1 数据（是否与 L2 变化一致）
总结
- L1/L2/L3 各有分工：L3 监控系统稳定性，L2 评测输出质量，L1 验证业务价值；三层都要有，缺任何一层都会有盲区
- 场景决定关键指标：RAG 系统最重要的是 Context Recall，代码生成最重要的是测试通过率，Agent 最重要的是任务完成率——照搬其他系统的指标不一定适合自己
- 阈值要从数据来：先跑基线，再定阈值，不要先定阈值再用数据倒推理由
欢迎访问 PrimeSkills —— 一个精心策划的 AI Agent 与技能市场，所有内容均经过真实企业级工作流验证。没有噱头，只有真正有效的东西。
更多实用知识和有趣产品，欢迎访问我的个人主页
