AI 项目上线后怎么评估：从 Demo 指标到业务指标的度量体系（2026 指南）

先说结论：Demo 指标和业务指标之间，隔着一整套评估体系

我们接手的 AI 项目里，最常见的死法不是”做不出来”，而是**“上线了，却说不清它到底有没有用”**。

Demo 演示时准确率 98%、客户惊叹、合同签字——三个月后客户问”它给业务带来了什么”，答不上来，项目就变成”感觉还行但说不清价值”。AI 项目的评估必须分三层，缺一层都会翻车：

层级	回答的问题	代表指标
① 离线技术质量	模型本身行不行	评测集（Eval Set）、Precision/Recall/F1、RAGAS
② 线上效果	系统跑得稳不稳	任务成功率、回退率、人工介入率、Token 成本
③ 业务价值	投的钱值不值	转化率、客诉率、节省工时、ROI

本文按这三层展开：每层看什么指标、评测集怎么建、三层怎么闭环，以及我们见过的六个高频坑。

---

1. 为什么”感觉效果还行”不成立

先看三组我们真实见过的反差，都是”Demo 数据很好、业务毫无变化”的典型：

• 准确率 98%，客诉没降。智能客服上线，离线测试准确率 98%，但客户投诉率纹丝不动——因为剩余 2% 的错误全部集中在高价值场景（退款、改期），而 98% 的”正确”里有一大半是”答了等于没答”的废话。平均值骗人，要看分布。
• 检索分很高，回答不可用。RAG 项目，检索召回率 92%，但回答仍然幻觉频出——检索准不等于生成准，两段要分开评，问题出在生成段的 Faithfulness。
• 省了 50% 工时，成本吃掉利润。文档处理流水线，人工工时省了一半，但 Token 成本 + 人工兜底成本（介入率 40%）算下来，单笔单处理成本比原来还高。

这三组反差的共同点：只测了第一层（甚至只测了一个数字），第二、三层没有闭环。评估体系的建设，从上线第一天就要开始——不是”验证通过”就结束，而是持续运行的基础设施。

---

2. 第一层：离线技术质量指标

这一层回答”模型本身行不行”，核心是评测集（Eval Set / Golden Dataset）。

评测集怎么建

最快的路径不是让专家凭空写用例，而是从真实日志回流：

1. 种子集：人工标注 50-100 条覆盖主要场景的用例（含标准答案），先让评测能跑起来
2. 分层抽样：按场景、难度、用户类型分层取样，别只挑简单的——评测集偏简单，指标就会虚高
3. 双人标注：每条标准答案由两人独立标注，不一致的讨论定标，避免单人主观偏差
4. 持续回流：每周从线上日志补充 10-20 条真实失败用例，防回归

分任务类型选指标

任务类型	指标	说明
分类/抽取	Precision、Recall、F1	别只看准确率（Accuracy），类别不平衡时它毫无意义
生成/RAG	RAGAS 四件套	Context Precision、Context Recall、Faithfulness、Answer Relevancy
检索质量	Hit Rate、MRR	检索引擎标准指标，Top-K 命中率与排序质量
通用问答	LLM-as-a-Judge	用强模型按 rubric 打分，注意用不同模型做裁判避免同源偏好

RAG 项目尤其要拆两段评：检索段看 Context Precision（检索出来的有多少是相关的）和 Context Recall（该召回的有没有召回）；生成段看 Faithfulness（回答是否忠于检索上下文，防幻觉）和 Answer Relevancy（回答是否切题）。四个指标组合定位问题在哪一层——只给一个总准确率，等于没给。

这层的方法论和 RAG 知识库的评测闭环 是同一条链路，评测集建一次，RAG、Agent、客服系统都能复用。

---

3. 第二层：线上效果指标

离线评测再漂亮，上线后也会被真实输入教育。这一层盯五个指标：

指标	含义	健康线参考
任务成功率	端到端完成且结果达标的比例	业务定义，建议 ≥ 85%
回退率	一次失败的 ReAct/流程重试占比	高说明工具设计或流程拆解有问题
人工介入率	需要人确认或修正的步骤占比	太高没省到人，太低风险失控
端到端延迟	从请求到结果的时间	按业务场景定（客服 < 5s，批处理放宽）
Token 成本/任务	平均每任务消耗	预算红线，和收益对比才有意义

另外两个容易被忽略但极其重要的动作：

• 失败模式聚类：每周把失败案例聚类（工具调用错？检索不到？指令理解偏？回答幻觉？），按根因排优先级修——而不是零散打补丁。这是我们排查线上 AI 问题最有效的动作。
• 评估四指标从第一天记起：成功率、回退率、介入率、成本，从灰度上线第一天就记录，形成基线。没有基线，“后面变差了”无从判断（Agent 编排项目的上线评估就是同一套，见姊妹篇）。

线上效果的观测基建，见AI 应用的可观测性设计——没有日志、追踪和指标采集，这一层就是空转。

---

4. 第三层：业务价值指标与 ROI

这一层回答”投的钱值不值”，也是甲方老板真正关心的。核心是把技术指标翻译成钱。

最小 ROI 公式

年净收益 =（节省人工成本 + 新增/改善的业务收益）-（API/推理成本 + 开发成本摊销 + 人工兜底成本）

拆开看四块：

成本/收益项	怎么算	常见坑
节省人工成本	处理量 × 单位人工成本 × 替代率	替代率按真实介入率算，别按 100%
业务收益	转化率提升、客诉率下降、响应时长缩短折算	需要有对照期数据（改造前 vs 改造后）
API/推理成本	单次成本 × 月调用量 × 12	用全年量，别用 Demo 期数据
人工兜底成本	介入率 × 单次人工处理成本	最容易被漏掉的一块

Unit Economics 是判断 AI 有没有用的唯一硬标准

单次 AI 处理总成本（Token + 兜底人工 + 分摊开发）必须低于单次人工处理成本，这个 AI 才值得做。我们见过太多”省了人但没省钱”的项目——介入率 40% 的客服系统，兜底人工成本直接吃掉全部收益。

ROI 的另一半是对照：改造前和改造后的业务数据要能对上。没有对照期数据，ROI 就是拍脑袋。这就是为什么评估要从上线第一天开始记——等客户问的时候，历史数据已经没了。

---

5. 三层怎么闭环：评估是持续运行的基础设施

三层不是三个独立清单，而是一条闭环流水线：

离线评测（评测集回归）→ 灰度/上线 → 线上指标采集 → 失败案例回流评测集 → 下一轮改版

• 改版前：先跑评测集回归，防回归用例不过不许上线
• 上线时：灰度 + A/B 对比，Champion-Challenger 机制——新版本指标没赢过线上版本就不切换
• 运行中：每周失败聚类 + 评测集回流，形成”越用越准”的飞轮

这个闭环和 PoC 设计方法 是一脉相承的：PoC 阶段验证最危险的假设，上线后评估体系验证假设是否真的成立。

---

6. 六个高频坑

1. 评测集泄漏。测试用例被模型训练数据覆盖，指标虚高——评测集要定期换新题，防泄漏。
2. 只看平均值。98% 准确率掩盖了高价值场景的 100% 失败。看分布、看长尾、按场景分层看。
3. A/B 测试周期太短。AI 系统的效果有冷启动期（检索索引、用户习惯都在变），至少跑 2-4 周再下结论。
4. 线上失败不回流。评测集是死的，没有每周回流就没有防回归能力，改版全靠赌。
5. 指标冲突。成本降了质量也降了——ROI 要同时看两边，单项指标优化是自欺欺人。
6. 没有基线。上线第一天不记指标，三个月后”变差了”无从判断。基线比完美更重要的。

---

最后：评估体系就是 AI 项目的验收标准

“AI 效果评估”不是一个验收节点，而是项目从第一天起的运行方式。Demo 靠惊艳，生产靠度量——离线评测集、线上指标、业务 ROI 三层缺一不可，且要持续闭环运行。

这正是我们团队在 AI 交付里和客户聊得最多的地方：我们交付 RAG 知识库、Agent 编排、AI 客服类项目时，会把评测集、线上指标和 ROI 框架作为交付物的一部分写进验收标准——项目验收的不是”功能跑通”，而是”三层指标达标”。

如果你正在评估 AI 项目怎么验收、上线后怎么度量效果，欢迎带着场景来聊。我们做 AI 工程补位与决策层服务：RAG 知识库、Agent 编排、私有化推理部署，以及技术路线评估与效果度量体系设计——不做什么都能做的承诺，只做我们擅长的领域。

延伸阅读：

• AI 项目劝退指南：这 6 种情况，先别急着上 AI — 立项前先判断”该不该做”：6 种劝退情况 + 3 问自测清单
• 企业 AI 落地 ROI 测算与立项 — 立项前的账怎么算：ROI 公式、五项成本、三类项目测算模板
• AI Agent 工作流编排实战 — 上线评估四指标（成功率/回退率/成本/介入率）的姊妹篇
• AI 客服落地实战：为什么你的智能客服总是翻车 — 三层指标在客服场景的具体落地：任务成功率、介入率、单次处理成本
• 企业私有知识库 RAG 落地实战 — 评测闭环与检索质量方法论
• AI 应用的可观测性设计 — 线上指标采集与追踪的基建
• 可行性验证（PoC）设计方法 — 上线前先验证最危险的假设
• LLM 应用评测实战 — 本文讲业务层三层指标，那篇讲工程层评测体系，两者配合才是完整闭环
• LLM 成本管理实战 — “单次处理成本”指标的完整算法：Cost per Task 与任务链路记账
• AI 项目做完后，为什么甲方和乙方都觉得亏了？ — 从验收标准到期望管理的深层原因
• AI 工程按月补位 — RAG、Agent 编排、私有化推理部署的外部工程能力