第 11 章 价值评估与评测体系：如何算清 AI 的账
“AI 到底给我们带来了什么？”
这是企业管理者最终必然会问的问题。而在 AI 稳定性这件事上，大多数团队没有一个令人信服的答案——他们有感受，有案例，有截图，但没有数字。
这不只是汇报的问题。更深层的原因是：没有评测，就没有改进的方向。 你不知道哪个场景在退化，不知道某次提示词修改是进步还是退步，不知道投入的人力和成本是否值得。
本章分两部分：上半部分讲如何算清成本与 ROI（让你能回答“值不值得”）；下半部分讲如何建立评测体系（让你能回答“好不好”和“有没有在变好”）。
第一部分：算清 AI 的账
一、成本的全貌：不只是订阅费
企业在计算 AI 成本时，最常犯的错误是只算“工具订阅费”。但 AI 工作流的 总拥有成本（TCO，Total Cost of Ownership） 至少应覆盖以下持续成本与按规则分摊的一次性成本：
| 成本类型 | 具体内容 | 容易被忽视的原因 |
|---|---|---|
| 直接工具成本 | API Token 费用、SaaS 订阅费、模型调用费 | 账单上看得见，相对容易统计 |
| 人工验证成本 | 每次输出后人工检查、修改、审核所花的时间 | 没有单独计时，被算进“正常工作时间” |
| 错误修复成本 | AI 输出错误导致的返工、客户投诉处理、危机公关 | 偶发性，容易被当作“例外”处理 |
| 维护成本 | Prompt 更新、知识库维护、人员培训、版本管理 | 分散在多人时间中，难以汇总 |
| 上下文与工具运营成本 | 检索/索引、上下文包、工具/MCP/连接器维护、记忆/状态、日志、评测和变更回归 | 常被隐藏在平台、工程、知识 Owner 和审核人的零散工作中 |
| 实施、共享与退出成本 | 集成、数据准备、迁移、一次性安全/合规审查、共享平台分摊、培训/变革、恢复演练与退役准备 | 常被错误归入其他项目，或只在上线前一次性记录 |
核算公式：
月度 AI 工作流总成本 = 直接工具成本 + 人工验证/接管成本 + 错误处理成本 + 维护成本 + 上下文/检索/工具/记忆与控制运营成本 + 一次性与共享成本的可追溯分摊 + 退出/恢复准备成本注意： 不要跳过“人工验证成本”和“上下文/工具运营成本”。前者包括人工核验、审批、接管和回退；后者包括让 Agent 取得正确上下文、维护连接器、限制工具返回、处理记忆失效、留存日志和运行回归的投入。具体占比必须依据本组织的任务量、风险和运行记录核算，不能仅用模型账单代表总成本。
二、价值的量化：三种可测量的维度
AI 工作流带来的价值，可以从三个维度量化：
维度 1：时间节省
最直接的价值，也最容易测量。
测量方法：
- 在引入 AI 前，按任务类型、复杂度、人员经验、时间窗口和异常情形记录端到端基线（T_before）。对低风险、同质的探索性试点，可先从少量代表性样本起步；这不是用于财务结论的固定充分样本量。
- 引入 AI 后，在相同或可比条件下记录端到端时间（T_after），包括准备上下文、等待、AI/工具运行、人工验证、修改、审批、接管、返工和必要的回退。
- 容量释放估计 = (T_before - T_after) × 可比期间的实际完成量。若要主张因果改善或做财务决策，应结合分阶段试点、对照组、A/B、前后趋势或其他能处理季节性、任务结构和采用率变化的设计。
常见错误： 只计算 AI 生成时间，忘记计算人工验证时间；或把不同难度、不同人员和不同业务负荷下的平均值直接相减。真实企业现场研究确实使用每小时解决问题数、每周 Pull Request、审查时间、构建成功和错误率等端到端流程数据，但研究也会报告采用率、任务差异和统计局限。1 2
维度 2：质量提升
通常比时间节省更难量化，但对于很多场景（如客服回复质量、文档准确率）更重要。
测量方法（选一种）：
- 对比 AI 辅助前后，客户满意度评分的变化
- 对比人工审核发现错误的频率（错误率下降多少）
- 对比内部评审通过率（第一次提交通过的比例）
维度 3：容量释放
AI 可能让同样的人员在相同时间内处理更多工作，或释放部分容量用于服务、改进或其他任务；这不自动等于可以减少一个岗位、预算或外包合同。
测量方法：
- 记录引入 AI 前后，同一团队处理的任务总量
- 或记录完成同等任务量，所需的人力变化
三、ROI 计算框架
月度投资回报率（Monthly ROI）：
已实现财务 ROI = (已实现财务收益 - 可归属月度总成本) / 可归属月度总成本 × 100%
已实现财务收益 = 已验证的现金支出减少 + 已验证的增量贡献利润 + 经批准口径估算的已避免损失
容量价值代理 = 节省的端到端小时数 × 组织确认的容量价值系数“节省小时数 × 平均时薪”可以作为容量价值代理，但不自动等于已实现财务收益。只有当释放时间确实转化为减少加班、外包、招聘、闲置、现金支出，或带来可验证的处理量、收入、服务水平或风险损失变化时，才可按事先约定的归因规则纳入已实现财务 ROI。未货币化的容量、质量、体验、学习和风险控制应单列呈现，不应为了得出一个ROI百分比而强行折算。
向管理层汇报的简洁版本：
“本季度，我们在[场景 A]和[场景 B]上运行 AI 工作流。可归属全成本为 X 元；在可比范围内，端到端处理时间变化为 Y，质量/风险指标为 Z。已验证财务收益为 W 元，容量价值代理为 V 元，两者未合并计算。下一阶段是否扩大，取决于预先约定的质量、控制和业务结果闸门。”
这个表述的关键不是把所有收益压缩成单一数字，而是让成本、已实现收益、容量代理、质量和证据边界可以被复核。Klarna 等企业公开案例同时报告处理量、时长、客户体验、容量等价和预计财务影响，说明多维测量在实践中被使用；但其中数值属于当事方披露，不能外推为其他企业的目标或财务结论。3
第二部分：建立评测体系
四、核心指标体系：基础结果与 Agent 运行信号
以下五个指标来自附录 B，构成所有用例的基础结果视图。涉及检索、工具、记忆或 Agent 时，还应增加上下文、工具和接管信号；这些不是跨团队统一 KPI，而是帮助团队识别“最终文本看起来正常、运行控制却已失效”的早期迹象。
| 指标 | 定义 | 目标或触发条件如何设定 | 为什么重要 |
|---|---|---|---|
| 一次通过率 | 输出一次性通过验证清单的次数 / 总执行次数 | 依据基线、错误后果、审核能力和阶段门设定；高影响场景不应仅因平均值达标而放宽控制 | 衡量稳定性的核心指标 |
| 实际采用率 | 被直接或小改后使用的输出数 / 总输出数 | 结合任务覆盖、人工替代方式、用户选择和质量反馈设定；需区分“被接受”与“被迫使用” | 衡量实际业务价值（通过了检查但没人用 = 质量标准脱离业务） |
| 平均总耗时 | 从提交任务到获得可用输出的完整时间 | 与可比人工基线、服务等级、任务难度和审核负担比较，不设跨场景统一比例 | 衡量效率提升 |
| 失败类型分布 | 各类失败原因（幻觉/格式/遗漏/过期知识）的占比 | — | 指导改进方向 |
| 知识更新及时率 | 按时完成知识库更新的次数 / 应更新次数 | 由用例风险、变化速度和 Owner 能力确定 | 衡量知识维护质量 |
| 来源可定位与异常拦截（涉及上下文/Agent 时） | 来源、版本、范围可定位，以及过期、冲突、越权或信息不足被正确停止/转人工的情况 | 由风险边界和 Golden Set 确定 | 衡量上下文是否可解释、可复核、可安全停止 |
| 工具/记忆运行信号（涉及工具/记忆时） | 工具参数/返回异常、无效调用、记忆纠错与失效、接管和恢复情况 | 由运行合约和控制卡确定 | 衡量行动面和状态面是否仍受控 |
五、评分量表（Rubric）：让“好”变得可以测量
一次通过率需要一个前提：明确定义什么样的输出算“通过”。
验证清单给出的是“是/否”判断（格式是否正确、有没有事实错误）。但很多输出的质量是连续的，需要用评分量表（Rubric）来处理。
设计一个 Rubric 的四步法：
第 1 步：确定评测维度
根据任务类型选 3~5 个维度。例如客服回复场景：
- 准确性（信息是否正确）
- 完整性（是否覆盖了所有要点）
- 适当性（语气是否符合品牌调性）
- 简洁性（是否简洁，没有废话）
第 2 步：为每个维度定义评分等级
可从 3 级评分（合格/良好/优秀）开始，也可按任务使用二元、四级或其他可解释等级；等级数不是质量保证。
以“准确性”为例：
- 1 分（不合格）：包含明显的事实错误，或使用了过期信息
- 2 分（合格）：信息基本正确，但有一处模糊表述
- 3 分（优秀）：所有信息准确，表述清晰无歧义
第 3 步：计算综合得分与通过阈值
例如 4 个维度各 3 分，总分 12 分，可以先用 9 分作为教学演示。正式通过阈值应由错误代价、关键维度的最低分、监管/合同要求、人工接管能力和历史样本分布共同确定；不能把 75% 作为通用质量门槛。
第 4 步：定期校验评分一致性
让两个或以上评审人分别对同一批样本评分，检查**评审者间一致性（Inter-rater Agreement）**与分歧类型。可按评分尺度和样本量选择原始一致率、Cohen's kappa、加权 kappa、Krippendorff's alpha 或组内相关系数（ICC）。不存在通用的 70% 通过线；若关键维度分歧会改变发布、对外沟通或高影响决定，应先澄清 Rubric、培训评审人并复测。
六、从人工检查到半自动化评测
纯人工评测在低频场景可行，但当任务量增大时，你需要把部分评测自动化。
可以自动化的评测项
| 检查类型 | 自动化方法 |
|---|---|
| 格式检查 | 用正则表达式检查输出是否符合预定格式（如 JSON 结构、必须包含的字段） |
| 禁止词检查 | 检查输出中是否包含禁止使用的词语或表述 |
| 长度检查 | 检查输出是否在规定的字数范围内 |
| 结构完整性 | 检查必须出现的章节标题、关键词是否存在 |
LLM-as-Judge：用 AI 评测 AI
对于“合理但难以用规则判断”的质量维度（如语气、逻辑连贯性），可以用另一个 LLM 作为评审。
LLM-as-Judge 的标准提示词结构：
你是一个专业评审员。请根据以下评分标准，对以下输出进行评分。
【任务描述】
[说明这个 AI 工作流的任务是什么]
【评分标准】
[粘贴你的 Rubric，含各维度定义和评分等级]
【待评测的输出】
[粘贴 AI 的输出内容]
请对每个维度给出分数（1/2/3）和一句理由，最后给出综合判断（通过/不通过）。LLM-as-Judge 的注意事项：
- LLM 评审本身也有误差，置信度不等于正确性。应按风险分层抽取人工复核样本，并比较一致性、假通过、假拒绝、漂移和高风险样本覆盖；20%只能作为某些探索性试点的起点，不是通用充分比例
- 不适合用于高风险决策的评测（如判断法律合规性）
- 建议定期用人工重新校验 LLM 的评审标准是否在漂移
七、评测数据的记录与使用
评测的价值，不在于当下的数字，而在于趋势。
最简单的评测记录表（按运行节奏填写）：
| 日期 | 场景/版本 | 执行范围 | 质量与采用结论 | 主要失败/风险信号 | 上下文/工具/记忆变化与异常 | 本期改进动作与证据 |
|---|---|---|---|---|---|---|
三个用评测数据做的最重要的决策：
- 停止或限量：出现不可接受错误、无法解释的质量退化、来源/权限异常、接管失效或证据不足时，考虑暂停扩大、转人工或回退。
- 升级：只有当业务价值、质量、人工审核负担、来源/工具控制、接管和运行证据均满足用例闸门时，才考虑扩大范围或提高自主性。
- 改进：当失败或运行信号呈现重复模式时，针对任务定义、上下文、知识、工具、记忆、验证或培训进行专项改进，并在变更后回归。
八、从单用例数据到组合决策
当只有一个用例时，计算该用例的 TCO、质量和采用率即可。当多个 Skill、工作流或 Agent 同时运行时，管理层还需要回答：哪些用例值得继续投资源，哪些只是局部便利，哪些因为共享知识、共享平台或共享维护人而带来了组合风险。
1. 不要把所有“节省时间”直接相加为财务收益
不同用例的节省时间可能来自同一批员工，也可能只是把工作从一个环节转移到另一个环节。组合汇报时，应区分以下三类信息：一是各用例的流程效率证据，即端到端耗时、返工和处理量变化；二是可被验证的业务结果证据，如客户满意度、积压下降、收入周期、成本避免或风险损失减少；三是尚未货币化的能力建设投入，如知识整理、培训、平台与维护。
因此，组合层面的 ROI 不应简单把每个用例的“节省工时×时薪”累加。只有当时间释放确实转化为可观察的处理量、成本减少、收入改善或风险避免时，才应谨慎作为财务价值汇报；其余可先作为流程和产能证据记录。
2. 组合评审应做四类决定
| 决定 | 应看什么证据 | 典型动作 |
|---|---|---|
| 加大投入 | 业务价值已验证；质量、采用和维护稳定；可复用资产明确 | 扩大问题类型、使用者或相邻团队；补充支持能力 |
| 继续改进 | 业务问题真实但质量、知识、成本或采纳仍有可修复缺口 | 限制范围，安排明确 Owner 与改进期限 |
| 暂停或降级 | 风险、维护负担或质量问题大于当前收益 | 回退人工流程或降为辅助使用，保留证据与复盘 |
| 退役 | 价值消失、被更优方案替代、维护不可承受或风险不可接受 | 停止权限与运行，归档资产，按政策处置数据与日志 |
用例组合台账、阶段闸门和月度评审模板见附录 A 第 18、20、21 节；第 8 章和第 12 章分别说明扩展节奏与组合治理机制。
3. 把评测结果接入发布与运行决策
一次通过率、Rubric 或单次回归结果本身不是终点。企业需要把“为什么做、怎样运行、如何测试、能否发布、发布后是否健康”连成一条可追溯的控制链：用例立项卡定义业务假设与停止条件；工作流合约定义运行边界；上下文包、记忆合约和工具控制卡定义信息面、状态面与行动面；Golden Set 定义应测哪些真实、边界和失败情形；回归报告比较新旧版本；发布登记限制范围并设观察期；用例健康卡持续判断扩大、维持、改进、暂停或退役。
| 资产 | 它回答的问题 | 使用时点 |
|---|---|---|
| 用例立项卡 | 这个业务问题是否值得做，成功或停止意味着什么 | 设计前与阶段变更前 |
| 工作流合约 | 流程怎样运行，谁在何处验证、接管和回退 | 多人试点或正式运行前 |
| 上下文包、记忆合约与工具控制卡 | 此刻允许依据什么、可保存什么、可查询或执行什么，以及如何限制和回退 | 设计、试点、连接器接入或高影响变更前 |
| Golden Set | 什么样的正常、边界、失败和异常行为必须被验证 | 试点、变更和事件复盘前 |
| 回归报告 | 新版本相对稳定版本是否退化，是否可发布 | 变更、修复或阶段提升前 |
| 发布登记 | 允许谁在何范围使用，何时停止和如何回退 | 每次受控上线或范围扩大时 |
| 用例健康卡 | 当前业务价值、质量、成本、风险和维护是否仍支持继续运行 | 与用例运行频率、风险和变更节奏相称的运行会与组合评审 |
附录 A 第 25、26、29、30、31、32、48–51 节分别提供这些资产。它们不要求每个低风险内部试点都做成复杂项目：范围越小、风险越低，记录越轻；但涉及对外沟通、写入、权限扩大、敏感数据或高影响决策时，证据和审批也必须随之加强。
九、本章行动清单
本月建立基础：
- [ ] 计算你当前最主要 AI 场景的 总拥有成本（包含验证时间成本）
- [ ] 为该场景设计一个 3~5 维度的评分量表（Rubric）
- [ ] 从真实或脱敏历史任务中建立一个最小 Golden Set，至少覆盖正常、边界与历史失败样本
- [ ] 按用例运行频率、变更节奏和风险等级填写评测记录，直至覆盖足以支持阶段决策的正常、边界、失败和变更样本
- [ ] 为下一次 Prompt、上下文包、知识、记忆、模型、工具或连接器变更预先指定回归报告、发布登记和回退版本
建立向管理层汇报的能力：
- [ ] 用本章的 ROI 公式，计算你运行时间最长的那个 AI 场景的季度 ROI
- [ ] 准备一份不超过一页的 AI 价值汇报模板，包含：成本、价值、质量指标、下一步改进计划
当重复频率、人工评测负担或变更速度已使人工全量检查不可持续时：
- [ ] 为格式、禁止词、结构完整性等确定性要求建立自动化检查，并验证其漏报与误报
- [ ] 评估是否可以引入 LLM-as-Judge，并按风险分层设计人工校验、漂移监测和停止条件
本章小结
算清 AI 的账，需要同时看两个维度：成本的全貌（不只是订阅费）和价值的量化（不只是感受）。
评测体系的建立，不需要一步到位。从按运行节奏填写一张简单的评测记录表开始，然后逐步引入 Rubric、自动化检查和 LLM-as-Judge。
最重要的一点：评测数据是用来做决策的，不是用来证明 AI 的价值给领导看的。 如果数据告诉你一个场景在退化，你就需要根据数据做出停止或改进的决策，而不是选择性地只汇报好看的数字。