AI 评测系列（02）：评测指标设计——从业务目标到可量化指标

指标缺失时会发生什么

一个 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： 工具调用准确率 → 选了正确工具、参数正确（可自动化） 步骤效率 → 完成任务用了多少步（步数越少越好） 轨迹质量