第 26 章：成熟度模型、团队能力与路线图
本页导航
26.1 方法齐全不等于组织能力成熟
客服 Agent 团队已经有评测脚本、数据集、Judge、看板和若干报告。但问题仍然反复出现：
- 数据集没人维护。
- 门禁被紧急发布绕过。
- Judge Prompt 改了却没有版本记录。
- Bad Case 归因后没人负责修复。
- 线上指标异常后没有固定响应流程。
这说明评测体系不只是技术问题，也是一种组织能力。
本章把全书方法收束为三件事：
- 用成熟度模型判断团队位置。
- 明确团队角色和能力矩阵。
- 给出 90 天落地路线图。
26.2 五级成熟度模型
企业 AI 评测体系可以分为五级。
| 等级 | 名称 | 典型表现 |
|---|---|---|
| M1 | 脚本级 | 个人脚本、临时样本、手工报告 |
| M2 | 工具级 | 有固定工具和部分自动化 |
| M3 | 平台级 | 有数据、执行、报告和版本管理 |
| M4 | 组织级 | 接入门禁、线上回流和跨团队治理 |
| M5 | 跨域复用级 | 在多个业务域复用经验证的方法、平台能力和治理机制 |
M 表示组织成熟度（Maturity），用于区别第 14 章的 L1—L5 沙箱保真度、第 20 章的 R0—R4 样本复用就绪度和第 21 章的 E0—E4 归因证据成熟度。本模型是本书用于组织诊断的工作框架，不是行业认证标准。
成熟度取决于评测能否持续影响质量决策，工具数量不能说明这一点。
26.2.1 成熟度要按证据判断
团队经常高估自己的成熟度。判断成熟度时，应看是否有可检查证据，而不是看是否使用了某个工具。
证据应覆盖数据治理、指标有效性、Run 可复现性、发布门禁、Bad Case 闭环、线上回流和非 P0 豁免审计。完整诊断问题统一放在 26.15.1，避免在模型定义和交付物中维护两张相同问卷。如果这些证据不存在，即使平台界面完整、报告漂亮，也仍然不能称为成熟体系。
等级判断采用“能力下限”而不是平均分：团队只能认定为已持续满足当前级别及以前级别的关键证据；某一项工具能力特别突出，不能抵消数据、门禁或闭环缺失。若证据只在单个项目短期成立，应记录为局部能力，不直接上升为组织等级。
M1 也不是默认起点。如果团队还没有稳定 Case、基本版本记录和可复查结果，应标记为“尚未建立 M1 证据”，而不是为了完成评级强行归入 M1。
26.3 M1：脚本级
M1 团队通常有少量样本和脚本。
典型表现：
- 用表格保存样本。
- 用脚本批量调用模型。
- 人工看部分输出。
- 报告靠手工整理。
- 样本和结果难追溯。
M1 先建立基本标准，不要求建设复杂平台：
- 固定 Case Schema。
- 记录版本。
- 建立最小 Golden Set。
- 明确高风险样本。
26.4 M2：工具级
M2 团队开始有工具化能力。
典型表现：
- 有评测工具或内部小平台。
- 能自动跑部分数据集。
- 有简单 Judge 或规则评估。
- 能生成报告。
- 但门禁、线上回流和归因仍弱。
M2 升级重点：
- 建立 Regression Set。
- 引入版本血缘。
- 做 Bad Case 分类。
- 让评测结果进入发布评审。
26.5 M3：平台级
M3 团队有 EvalOps 平台雏形。
典型表现：
- 管理 Model、Prompt、Dataset、Evaluator、Run、Report。
- 支持批量执行和对比。
- 记录 Trace 和成本。
- 有可复现运行记录。
M3 的瓶颈通常转向治理，继续增加工具未必有效。
升级重点：
- 接入 CI/CD 和发布门禁。
- 建立 Owner 机制。
- 将线上 Bad Case 回流。
- 建立评测体系质量回检。
26.6 M4：组织级
M4 团队已经把评测纳入组织流程。
典型表现：
- 评测结果能阻断发布。
- 非 P0 门禁豁免有审批、期限、补偿措施和留痕；P0 不得通过豁免放行。
- Bad Case 有归因、修复、回归和防复发。
- 线上看板支持多角色决策。
- 安全红队和合规证据链持续运行。
M4 的重点是持续运营：防止数据老化、指标失真、门禁失权和团队标准分裂。
26.7 M5：跨域复用级
M5 团队不仅支撑单个应用，还能在多个业务域复用经过验证的方法与治理能力。
典型表现：
- 评测标准可迁移到多个业务线。
- 有成熟的红队和安全研究能力。
- 有高质量垂类 Rubric 和专家网络。
- 能沉淀平台能力和最佳实践。
- 能用评测结果反哺数据生产和模型迭代。
M5 不是所有团队的短期目标。团队应先稳定满足 M3—M4 的生产证据，再根据跨业务复用需求决定是否建设 M5 能力。
26.8 组织治理：Owner 机制
评测资产需要明确 Owner。
| 对象 | Owner 职责 |
|---|---|
| 指标树 | 保证指标与业务目标一致 |
| 数据集 | 维护样本质量、版本、污染和老化 |
| Evaluator | 维护评估器准确性和漂移 |
| 门禁 | 维护阈值、非 P0 豁免和发布规则，守住 P0 红线 |
| 线上看板 | 维护指标口径和告警 |
| Bad Case | 推动归因、修复和回归 |
| 安全红队 | 维护风险样本和证据链 |
没有 Owner 的资产会迅速失效。
26.9 变更管理
评测体系自身也需要变更管理。
需要管理的变更包括：
- 评测集新增、删除和重分层。
- Rubric 修改。
- Judge Prompt 修改。
- 门禁阈值修改。
- 知识库、工具和 Agent 策略变更。
- 紧急发布和非 P0 门禁豁免。
每次变更都要记录原因、影响范围、审批人和回归结果。
评测体系如果没有变更治理，分数会失去可比性，门禁也会失去权威。
26.10 团队角色
成熟评测团队通常包含多类角色。
| 角色 | 核心职责 |
|---|---|
| 评测方法负责人 | 指标、Rubric、实验设计 |
| 评测平台工程师 | EvalOps 平台、执行引擎、数据血缘 |
| 数据 / 标注负责人 | 样本采集、标注、质检和污染控制 |
| Agent 评测工程师 | Tool、Trace、沙箱和执行评测 |
| 红队安全评测 | 攻击样本、安全门禁、合规证据链 |
| 评测产品 / 运营 | 看板、报告、流程和跨团队协作 |
| 领域专家 | 业务标准、Rubric 仲裁、高风险样本 |
一个人可以承担多个角色，但职责不能缺失。
26.11 能力矩阵
专业 AI 评测人才需要复合能力。
| 能力 | 说明 |
|---|---|
| 方法论 | 能从业务目标拆指标、样本和 Rubric |
| 工程化 | 能构建自动化执行、版本血缘和平台能力 |
| Agent 技术 | 理解 RAG、Tool、Memory、Workflow、Trace |
| 统计实验 | 理解样本量、置信区间、版本对比和显著性 |
| 数据治理 | 维护数据质量、污染、老化和隔离 |
| 安全红队 | 设计攻击样本和安全门禁 |
| 业务抽象 | 把行业规则转成评测资产 |
| 组织推动 | 让评测进入发布、灰度和优化流程 |
评测负责人最关键的能力，是把技术证据转化为组织决策。
26.12 个人成长路径
AI 评测从业者可以按四个阶段成长。
| 阶段 | 重点 |
|---|---|
| 执行评测 | 跑样本、看结果、整理报告 |
| 设计评测 | 设计指标、Rubric、Case 和 Evaluator |
| 建设体系 | 建平台、门禁、线上回流和归因闭环 |
| 影响组织 | 制定标准、推动发布治理和质量文化 |
从跑 Benchmark 到建设质量基础设施，是能力跃迁的关键。
26.13 90 天企业级评测体系启动路线图
一个团队可以把 90 天作为启动最小闭环的示例节奏，而不是固定工期。实际周期取决于系统风险、数据基础、团队规模、合规要求和平台现状；高风险业务宁可延长验证，也不应为了满足日期压缩门禁。
第 1-30 天：建立最小评测资产
- 选择一个高价值场景，例如客服退款。
- 梳理业务目标和风险场景。
- 围绕这个核心场景建立约 50—100 条初始 Eval Case；若基础较好再扩展到相邻场景。数量是规划示例，风险覆盖和标注质量优先于凑足规模。
- 定义指标树和 Rubric。
- 建立 Golden Set 和高风险小集。
- 记录模型、Prompt、知识库和工具版本。
第 31-60 天：自动化和回归
- 建立自动化执行脚本或轻量平台。
- 接入规则、脚本、Judge 和人工复核。
- 建立 Regression Set。
- 记录 Run、Report、Trace 和成本。
- 对关键变更触发评测。
- 输出发布前质量报告。
第 61-90 天：门禁和线上闭环
- 接入 CI/CD 或发布审批。
- 将明确的 P0 红线、P1 审批规则和灰度观察指标接入发布流程。
- 建立线上质量看板。
- 采集线上 Bad Case。
- 建立归因、修复、回归流程。
- 明确指标、数据、Evaluator 和门禁 Owner。
90 天目标是让一个业务场景形成可运行闭环，不必先做完整平台。
26.13.1 90 天路线图的常见失败与风险控制
90 天启动路线图最常见的失败，是目标过大。团队一开始想同时覆盖所有业务线、所有模型、所有风险，结果样本质量不稳、平台尚未成型、门禁也无法落地。
更稳妥的做法是明确三条约束：
- 只选择一个高价值场景作为主战场。
- 只把明确的 P0 红线和少量 P1 风险接入硬门禁，其他风险按审批或观察规则处置。
- 只建设足够支撑闭环的轻量平台能力。
| 风险 | 表现 | 应对 |
|---|---|---|
| 范围过大 | 多业务线同时铺开，样本质量下降 | 固定一个场景，形成样板后复制 |
| 平台先行 | 工具开发很多，评测标准不足 | 先定义 Case、Rubric、门禁，再平台化 |
| 门禁过重 | 大量指标阻断发布，研发绕开流程 | 只把红线指标设为硬门禁 |
| 人评过载 | 高低风险样本都进入人工 | 规则和 Judge 分流，人工聚焦争议和高风险 |
| 线上断流 | Bad Case 没有进入回归 | 指定 Owner 和回流周期 |
路线图描述组织能力建设节奏。每 30 天都应形成可验证资产，不能只完成会议和文档。
26.14 客服 Agent 三个月升级案例
以下是与 90 天路线图配套的假设案例，不代表真实项目周期或成果。客服 Agent 团队可以按以下节奏推进：
| 时间 | 目标 | 产物 |
|---|---|---|
| 第 1 月 | 建立退款场景评测基础 | 指标树、Golden Set、风险清单 |
| 第 2 月 | 接入自动回归 | Eval Case、Judge、Run Report、Trace |
| 第 3 月 | 接入发布和线上闭环 | 门禁、看板、Bad Case 归因、Regression Set |
三个月后，团队至少应做到：
- Prompt 修改自动触发核心回归。
- 知识库更新触发 RAG Case。
- 退款工具变更触发 Tool / Trace Case。
- P0 安全失败阻断发布。
- 线上高价值 Bad Case 能进入归因和回归。
这时团队形成了比一次性脚本更稳定的闭环起点，但具体属于 M2、M3 还是更高等级，仍需按 26.15.1 的组织证据逐项判断。
26.15 交付物一：AI 评测体系成熟度模型
26.2—26.7 解释每一级的表现与跃迁障碍，本表只保留诊断后的汇总卡，不重复展开各级正文。
| 等级 | 核心能力 | 升级重点 |
|---|---|---|
| M1 脚本级 | 能跑样本 | Schema、版本、Golden |
| M2 工具级 | 能自动评测 | Regression、血缘、归因 |
| M3 平台级 | 能复现和对比 | 门禁、Owner、线上回流 |
| M4 组织级 | 能影响发布和治理 | 持续运营、安全合规、质量回检 |
| M5 跨域复用级 | 能跨业务复用经验证方法 | 标准化、跨业务复用、专家网络 |
成熟度评估应按证据判断，而不是按团队自评。
26.15.1 成熟度诊断问题
团队应按下表收集证据，而不是凭“多数问题答是”估算等级。
| 等级 | 需要满足的诊断条件 | 最低可检查证据 |
|---|---|---|
| M1 | 核心 Case 有稳定标识、期望行为和 Owner | Case 清单、审核记录、变更历史 |
| M1 | 每次执行保留输入、输出和基本模型 / Prompt 版本 | 可复查的运行记录 |
| M2 | 核心场景能重复自动执行，并区分 Golden 与 Regression | 自动任务配置、连续运行记录 |
| M2 | 数据集和 Evaluator 有版本、负责人和更新流程 | Dataset / Evaluator 版本及评审记录 |
| M2 | 失败样本能进入问题池并形成回归候选 | Bad Case 流转记录 |
| M3 | Run 能绑定模型、Prompt、Dataset、Case、Evaluator、工具和环境版本 | 完整 Run 血缘与可复现检查 |
| M3 | 平台保存逐 Case Result、Evaluation Result、Trace 和聚合报告 | 对象记录及关联查询 |
| M3 | 数据、Evaluator 和 Gate 有审核及生命周期 | 状态变更和权限审计记录 |
| M4 | 预先批准的 Gate 能实际阻断或约束发布 | CI/CD 记录、Gate Result、发布决定 |
| M4 | 线上 Bad Case 能完成脱敏、归因、修复、回归和防复发 | 至少一条闭环证据链 |
| M4 | Evaluator 回检、安全红队和非 P0 例外治理持续运行 | 周期记录、审批、期限和补偿措施；P0 无豁免 |
| M5 | 多个业务域复用同一对象契约和治理机制 | 跨域资产目录、差异说明和复用评审 |
| M5 | 共享平台能力在不同业务域有独立效果证据 | 各域运行、门禁和线上校准记录 |
| M5 | 跨域标准由稳定专家网络和治理机制持续维护 | 标准变更、专家仲裁和复审记录 |
判定步骤如下：
- 每项条件只能标记为“满足、部分满足、不满足、证据不足”；证据不足不能按满足计算。
- 从 M1 开始逐级检查。当前级别及以前级别的所有必选条件均满足，才能认定该等级。
- 任一必选条件部分满足或不满足，最终等级停在其前一级，并把该项列为升级缺口。
- 只在单个项目或一次发布中出现的证据记为局部能力；组织等级还要证明机制在约定观察周期内持续运行。
- 若 M1 条件也未满足，结论写“尚未建立 M1 证据”，不得用平均分包装成熟度。
26.16 交付物二：评测团队角色与能力矩阵
下表的高、中、低用于团队配置讨论，不是个人能力认证或招聘硬标准。为避免只凭印象打分，先使用统一行为锚点：
| 等级 | 行为锚点 | 可检查证据 |
|---|---|---|
| 高 | 能独立设计标准、处理高风险边界、评审他人方案，并对结果负责 | 主导的方案、评审记录、事故或门禁决策 |
| 中 | 能独立完成常规任务、解释主要取舍，遇到高风险或证据不足时正确升级 | 独立交付物、复盘记录、升级记录 |
| 低 | 理解基本概念，能在明确规范和复核下完成局部任务 | 受指导完成的样本、脚本、分析或运营记录 |
角色矩阵描述的是团队需要覆盖到什么程度，不表示每个人都要同时达到全部要求。具体招聘和培养标准还应结合职责、业务风险与组织分工展开。
| 角色 | 方法论 | 工程化 | Agent 技术 | 统计实验 | 业务抽象 | 组织推动 |
|---|---|---|---|---|---|---|
| 评测负责人 | 高 | 中 | 中 | 高 | 高 | 高 |
| 平台工程师 | 中 | 高 | 中 | 中 | 中 | 中 |
| Agent 评测工程师 | 高 | 高 | 高 | 中 | 中 | 中 |
| 数据负责人 | 中 | 中 | 中 | 中 | 高 | 中 |
| 红队安全 | 高 | 中 | 高 | 中 | 高 | 高 |
| 评测产品 / 运营 | 中 | 中 | 中 | 中 | 高 | 高 |
| 领域专家 | 中 | 低 | 低 | 中 | 高 | 中 |
团队不一定一次配齐所有专职人员，但各项能力需要有人覆盖。
26.17 交付物三：90 天企业级评测体系启动路线图
26.13 讲阶段动作，26.14 展示客服案例，本表是管理层验收卡。三处分别承担方法、案例和汇总，不应作为三份独立计划维护。
| 阶段 | 关键任务 | 验收标准 |
|---|---|---|
| 1-30 天 | 场景、指标、样本、Rubric | 能对一个核心场景给出可信离线报告 |
| 31-60 天 | 自动执行、版本血缘、回归 | 能稳定比较候选版本 |
| 61-90 天 | 门禁、线上监控、Bad Case 闭环 | 能影响发布并处理线上问题 |
路线图应从一个业务场景开始，而不是一开始覆盖所有应用。
26.18 全书收束：评测体系的完成定义
企业级 AI 评测体系是否完成，要看能否稳定回答六个问题，不能用样本数量或跑分次数代替：
- 这个 AI 系统要为业务创造什么价值？
- 哪些失败会造成不可接受的损失？
- 当前版本在哪些场景可靠，在哪些场景不可靠？
- 候选版本能否发布、灰度、阻断或回滚？
- 失败发生后，能否定位根因并完成修复验证？
- 线上新问题能否回流为长期质量资产？
如果一个团队能持续回答这六个问题，就已经从“跑评测”进入“管理 AI 质量”。这也是本书所有章节的共同指向。
26.19 方法依据与评级边界
M1—M5 是本书为评测体系建设设计的诊断框架，不是认证标准，也不与外部框架的等级直接换算。它主要参考两类治理思想：
- NIST AI Risk Management Framework将组织责任、情境映射、风险测量和风险处置连接起来，支持本章用持续证据而非工具数量判断能力。
- ISO/IEC 42001:2023要求组织建立并持续改进 AI 管理体系，覆盖角色、能力、运行、绩效评价和纠正措施，为 M4—M5 的组织治理证据提供参照。
达到本书某一级别，不等于符合 NIST AI RMF、通过 ISO/IEC 42001 认证或满足任何监管要求。组织若需要对外声明，应使用对应框架的正式评估、审计或认证流程。
26.20 本章小结
企业级 AI 评测最终沉淀为组织能力，工具只是承载手段。
成熟评测体系要有数据、指标、Evaluator、平台、门禁、线上回流、归因、修复和治理机制，也要有明确 Owner 和跨团队协作流程。
本书从传统测试失效开始，沿着业务目标、风险场景、分层对象、数据、Evaluator、Trace、平台、门禁、监控、归因、优化、安全、垂类和组织化一路展开。最终目标只有一个：让企业能够用可验证、可复现、可行动的方式管理 LLM 与 Agent 系统质量。