指标缺失时会发生什么

使用者痛点：上线后才发现程序“答非所问”，导致使用者流失。不过，

一个 RAG 问答程序上线了。工程师说 “测试都通过了”——API 响应时间 <1 秒，格式正确，没有崩溃。

两周后使用者反馈说 “AI 经常答非所问”。从排查后发现来看，检索召回率只有 30%。超过一半的使用者问题找不到相关文档。

这个问题上线前就存在。没有人设计过 “检索质量” 这个指标，所以没人看到它。

L1/L2/L3 三层指标框架

指标按层次组织。对应不同的问题类型：

L1 — 业务结果
最终目标的观点是，AI 程序是否在产生价值？说到示例，任务完成率、使用者采纳率、使用者满意度
L2 — 输出质量
说到中间层。AI 的输出本身质量如何？说到示例，准确性、相关性、完整性
L3 — 程序健康
说到基础层。程序运行是否稳定，至于示例，响应时延、Token 消耗、失败率

三层的依赖关系：

L3 不健康 → 影响 L2 → 影响 L1
L3 健康但 L2 差 → L1 仍然低
三层都健康 → L1 才真正有价值

告警时从 L3 往上排查。比从 L1 往下倒推快得多。其实，

四类场景的指标选择

至于场景。文档问答

L3 程序健康：
响应时延 P90 → <5s
    Token 消耗/次         → <500 tokens
    检索失败率           → <1%
L2 输出质量：
    Faithfulness          → 回答有没有编造，基于检索内容
    Answer Relevancy      → 回答有没有回答问题
    Context Precision     → 检索结果里有用的占比
    Context Recall        → 相关内容有没有都检索到
L1 业务结果：
    任务完成率           → 用户标记“解决了问题”的比例
    采纳率               → 用户复制/引用了 AI 回答的比例

关键指标： Context Recall是 RAG 程序最容易被忽略却最关键的指标。检索没找到，生成再好也没用。

至于场景，代码生成

L3 程序健康：
响应时延 P90 → <10s
    超长输出率           → 避免生成远超需要的代码量
L2 输出质量：
    语法正确率           → 生成代码能否通过解析器
    测试代码能否
    代码可用率           → 人工评估：生成代码需要多少修改才能用
    安全扫描通过率       → 是否包含已知安全漏洞
L1 业务结果：
    采纳率               → 用户接受 AI 建议的比例
    修改幅度             ← 用户修改了多少行代码

关键指标： 测试 L2 的主要指标。自动化程度高，适合接入 CI。

再看场景，文档摘要

L2 输出质量：
Faithfulness → 摘要没有引入原文没有的内容
覆盖率 → 原文关键要点是否出现在摘要里
简洁性 → 摘要是否明显比原文短
阅读流畅度 → LLM-as-Judge 整体评估

关键指标： Faithfulness。摘要最大的风险是“补充”了原文没有的信息，这比遗漏某个要点更有害。

从场景来看，Agent 任务完成

L2 输出质量：
工具调用准确率 → 正确选择工具、参数正确
步骤效率 → 完成任务用了多少步
轨迹质量 ← 推理过程是否合理
L1 业务结果：
任务完成率 ← 最终任务是否完成
首轮解决率 ← 不需要追问即完成的比例

关键指标： 任务完成率是 Agent 评测的主要 L1 指标。但需要明确“完成”的标准——产出物存在 vs.产出物质量达标，是不同要求。

常见陷阱

再看陷阱，只测 L3

✗ 错误做法：
"API 没有报错。延迟 <0.5 秒，这个版本可以上线。"
问题：L3 健康不等于系统有价值。
上线那个 RAG 系统的案例就是这样——L3 完全正常，但 L2 的检索召回率只有30%。

建议： 每次发布至少要看一次 L2 的抽样评测结果。

说到陷阱，用 BLEU/ROUGE 测评语义质量

# 看起来合理
rouge_score = rouge.compute
# 实际问题：
reference = "The capital of France is Paris."
output_1 = "Paris is capital city of France." # 语义相同。ROUGE低
output_2 = "The capital of France is Paris,capital." # 字面重复，ROUGE高
# ROUGE 给 output_2 更高分，但 output_2 明显更差

BLEU/ROUGE 测词汇重合度，不测语义正确性。对于生成式输出，用 L​LM‑as‑Judge 替代。BLEU/ROUGE只适合机器翻译等有标准参考答案的任务。说起来，

说到陷阱。阈值凭感觉定

✗ 错误：
"我们定 Faithfulness> 0.9 为质量门控。"
✓ 正确步骤：
说到Step1。随机抽取 N 个样本，计算当前基线均值。不过，Step2的观点是，查看 Faithfulness<0.9 的样本，人工判断是否可接受。
   Step3: 设定阈值，例如0.85。
   Step4: 在文档中写明“低于此值不可接受”的依据。

阈值不是凭感觉或经验。而是从数据分布和业务可接受性倒推出来的。

公司文档问答程序的完整指标程序示例

# 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: "<=500 tokens"
      collection: llm_callback
      alert_threshold: null
    - name: retrieval_error_rate
      target: "<=1%"
      collection: error_log
  l2_output_quality:
    - name: faithfulness
      tool: ragas
      target: ">0.9"
collection: weekly_sampling
alert_threshold: null
- name: answer_relevancy
从tool来看，ragas
target的观点是，">0.85"
collection: weekly_sampling
alert_threshold: null
- name: context_recall
tool这方面，ragas
说到target，">0.8"
collection: weekly_sampling
note这方面，"最关键的检索质量指标"
alert_threshold: null
- name: format_compliance
说到tool，rule_check
target的观点是，"100%"
collection: every_request
l1_business_outcome:
- name: task_completion_rate
target的观点是。">80%"
collection: user_feedback_widget
至于note，"使用者点击‘解决了我的问题’的比例"
- name: adoption_rate
说到target，">60%"
.collection : behavior_tracking
.note : "使用者复制/引用 AI 回答的比例"

指标程序建立路线图

第一步先 ：
□ 写下 AI 程序的主要业务目标
□ 列出 ≤5 个最关键的 L2 输出质量维度
□ 确认已有的 L3 基本监控
接下来 ：
□ 用 ≤10 个真实用例手动评测，得到每个 L2 指标的基线数字
□ 根据基线数字制定合理阈值 —— 不是凭感觉
：
□ 每次发布前跑 L2 抽样评测，与基线对比
□ 每月审视一次 L1 数据，看业务变化是否与 L2 同步
□ 根据实际反馈微调阈值和抽样频次

1. L1/L L/L C 各有分工：L ³ 监控程序稳定性，L ² 评测输出质量，L ¹ 验证业务价值；三层缺一都会形成盲区，
2. 场景决定关键指标：L ² 中的 Context Recall 对 RAG 最关键；代码生成则以 Test Pass Rate 为主要；Agent 场景聚焦 Task Completion Rate——照搬别人的指标往往不适合自己。
3. 阈值要来源于数据：

欢迎访问 PrimeSkills —— 一个精心策划的 AI Agent 与技能行业市场，所有内容均。没有噱头，只有真正有效的东西。

更多实用知识和有趣产品，请访问我的个人主页。