第 17 章：EvalOps 平台对象模型与架构

17.1 平台不是把脚本搬到网页上

很多团队建设评测平台时，会先做一个页面：上传数据集、选择模型、点击运行、下载报告。这个形态比本地脚本更方便，但如果底层对象没有设计清楚，平台很快会变成“带界面的脚本集合”。

几个常见问题会很快出现：

• 同一个模型在不同团队里叫法不同，结果无法比较。
• Prompt、知识库、工具 Schema、Evaluator 版本没有绑定，评测 Run 无法复现。
• 数据集只是文件上传，没有 Case 元数据、风险标签和版本血缘。
• 规则、脚本、Judge、人工评测各自一套入口，结果无法统一汇总。
• 评测报告只能展示分数，不能回放 Trace，也不能定位 Bad Case 根因。
• 门禁规则和 CI/CD 流程脱节，平台结果不能影响发布。

EvalOps 平台的核心不是功能堆砌，而是定义清楚评测体系里的对象、关系和生命周期。对象模型稳定，平台能力才能稳定扩展。

17.2 EvalOps 在企业 AI 工程体系中的位置

EvalOps 不是孤立平台。它连接 LLMOps、AgentOps、RAG 知识库、Prompt 管理、CI/CD、线上监控和数据闭环。

图 17-2 EvalOps 平台在企业 AI 工程体系中的位置

flowchart LR
  PM["Prompt / Agent 配置"] --> EVAL["EvalOps 平台"]
  KB["知识库 / Index"] --> EVAL
  MODEL["模型服务"] --> EVAL
  TOOL["工具与业务系统"] --> EVAL
  DATA["评测数据资产"] --> EVAL
  EVAL --> GATE["发布门禁"]
  EVAL --> OBS["线上监控"]
  OBS --> DATA
  EVAL --> FIX["归因与优化闭环"]

EvalOps 平台要回答的问题是：

• 用哪个模型、Prompt、数据集、Evaluator 和环境跑了评测？
• 得到了什么分数、Trace、Bad Case 和发布建议？
• 这些结果是否可复现、可对比、可审计？
• 结果如何进入门禁、看板、归因和回流？

如果平台不能回答这些问题，它就只是评测执行工具，不是企业级质量基础设施。

17.3 核心对象模型

EvalOps 平台至少需要管理以下对象。

对象	作用
Model	被评模型或模型服务
Prompt	系统提示词、任务提示词、Judge Prompt
Agent	Agent 配置、编排策略、状态管理方式
Tool	工具 Schema、权限、版本和调用方式
Dataset	评测数据集
Case	评测执行最小单元
Evaluator	规则、脚本、Judge、人工评测配置
Task	一次评测任务定义
Run	一次实际评测运行
Metric	指标定义和计算方式
Trace	Agent 执行轨迹
Report	结果报告和发布建议
Gate	门禁规则

这些对象之间的关系决定了平台能否复现评测。

一个客服 Agent 的 Run，不能只记录“跑了退款评测集”。它必须绑定：

• Model：使用哪个模型服务和版本。
• Prompt：使用哪个客服 Prompt 和系统指令。
• Agent：使用哪个编排配置。
• Tool：使用哪个订单查询和退款工具 Schema。
• Dataset：使用哪个 Eval Set 版本。
• Case：执行了哪些具体样本。
• Evaluator：使用了哪些规则、脚本、Judge 和人工流程。
• Environment：知识库、索引、权限和沙箱配置。
• Metric：计算了哪些指标。
• Trace：每条 Agent 执行轨迹。
• Report：最终结果、风险、门禁建议。

17.4 对象关系：Run 是中心

在 EvalOps 平台中，Run 是最重要的事实对象。其他对象都通过 Run 连接起来。

flowchart TB
  RUN["Run"]
  RUN --> MODEL["Model Version"]
  RUN --> PROMPT["Prompt Version"]
  RUN --> DATASET["Dataset Version"]
  RUN --> CASE["Case List"]
  RUN --> EVAL["Evaluator Version"]
  RUN --> AGENT["Agent Config"]
  RUN --> TOOL["Tool Schema"]
  RUN --> ENV["Environment"]
  RUN --> RESULT["Metric Results"]
  RUN --> TRACE["Trace"]
  RUN --> REPORT["Report"]

如果 Run 记录完整，就可以回答：

• 为什么这次分数和上次不同？
• 是模型变了，还是数据变了？
• Judge 是否升级过？
• 知识库索引是否一致？
• 哪些 Case 失败了？
• 失败是否集中在某个工具、场景或风险等级？

没有 Run 血缘，平台只能展示结果，不能解释结果。

17.4.1 对象契约

EvalOps 平台中的对象不是数据库表名，而是跨团队协作契约。每个对象都应说明自己由谁创建、由谁维护、被哪些流程消费，以及变更后会影响哪些下游对象。

对象	上游来源	下游消费	变更影响
Case	评测数据、线上 Bad Case、专家样本	Run、Evaluator、Report、Gate	影响分数可比性和样本覆盖
Evaluator	规则、脚本、Judge Prompt、人工流程	Run、Metric、Gate、Meta-Eval	影响评分口径和门禁稳定性
Agent Config	应用工程、Prompt、工具策略	Run、Trace、发布流程	影响工具调用、状态和执行路径
Gate	指标树、风险分级、发布策略	CI/CD、灰度、审批	影响版本能否发布
Report	Run、Metric、Trace、Bad Case	产品、研发、安全、管理层	影响发布和修复决策

对象契约能避免平台中的常见混乱：数据团队改了 Case，发布团队不知道；评测团队改了 Judge，历史分数无法比较；应用团队改了工具策略，Trace Case 没有触发回归。契约越清楚，平台越能稳定扩展。

17.4.2 对象生命周期

平台对象不能只创建，不维护。每个核心对象都应有生命周期。

对象	生命周期状态
Dataset	draft、reviewing、active、deprecated、archived
Case	drafted、approved、quarantined、retired
Evaluator	experimental、calibrated、active、deprecated
Gate	proposed、active、exempted、retired
Run	queued、running、completed、failed、cancelled、reproduced
Report	draft、reviewed、published、superseded

这些状态能解决两个常见问题。第一，评测集和 Evaluator 不能未经审核就进入门禁；第二，已失效对象不能继续影响发布。

例如，一个退款政策 Case 如果依赖已经下线的业务规则，应从 active 降级为 retired，而不是继续留在 Golden Set 中计算总分。一个 Judge Prompt 如果没有通过人工校准集，应停留在 experimental，不能用于发布门禁。

17.4.3 对象所有权

EvalOps 平台还要记录 Owner。没有 Owner 的对象会快速失效。

对象	Owner
指标	质量负责人或产品负责人
Dataset / Case	评测数据负责人
Evaluator	评测方法负责人
Agent / Tool 配置	应用工程负责人
Gate	发布质量负责人
Red Team Set	安全负责人
Report	质量运营负责人

Owner 不是名义字段。它决定谁审核变更、谁解释异常、谁推动修复和回归。

17.5 平台核心模块

17.5.1 数据管理模块

数据管理模块负责 Dataset、Case、标签、版本、审核和权限。

关键能力：

• 数据集版本管理。
• Case 元数据管理。
• Golden、Regression、Hard Case、Red Team 分层。
• 样本审核和变更记录。
• 隐藏集权限控制。
• 线上 Bad Case 回流入口。

17.5.2 任务编排模块

任务编排模块负责把评测任务拆成可执行单元。

关键能力：

• 批量运行。
• 并发控制。
• 优先级。
• 超时和重试。
• 断点续跑。
• 失败隔离。

17.5.3 执行引擎模块

执行引擎负责调用模型、Agent、工具和沙箱。

关键能力：

• 多模型接入。
• Prompt 注入和版本绑定。
• Agent 环境初始化。
• 工具调用拦截和记录。
• 沙箱运行。
• Trace 采集。

17.5.4 Evaluator 插件模块

Evaluator 插件模块让不同评估方式统一接入。

支持类型：

• 规则 Evaluator。
• 脚本 Evaluator。
• 检索指标 Evaluator。
• LLM-as-Judge。
• 人工复核。
• 终态校验器。

统一接口的价值是：不管评估器内部如何实现，平台都能统一调度、记录版本、汇总结果。

17.5.5 结果分析模块

结果分析模块负责把原始评分变成可决策信息。

关键能力：

• 指标聚合。
• 版本对比。
• 置信区间。
• 场景切片。
• 风险切片。
• Bad Case 聚类。
• Trace 回放入口。

17.5.6 门禁和报告模块

门禁和报告模块负责把评测结果转成发布建议。

关键能力：

• 硬门禁规则。
• 软门禁审批。
• 灰度建议。
• 风险摘要。
• 多角色报告。
• 审计留痕。

17.5.7 人工复核模块

企业评测平台还需要人工复核模块，尤其是高风险和低置信样本。

关键能力：

• 人工任务分发。
• 双人标注和专家仲裁。
• Rubric 展示和样例参考。
• 标注一致性统计。
• Judge 与人工差异分析。
• 人工结论回写 Evaluator 校准集。

人工复核不应脱离平台在表格里完成。否则人工结论无法进入 Run 血缘，也无法用于 Meta-Eval。

17.5.8 线上回流模块

线上回流模块负责把真实流量中的质量信号变成离线资产。

关键能力：

• Bad Case 采样。
• 脱敏和去重。
• 问题聚类。
• 风险定级。
• 归因任务创建。
• 回归集候选入库。
• 修复状态跟踪。

这部分连接第 20 章和第 21 章。没有线上回流，EvalOps 平台会停留在离线系统，无法适应真实用户分布变化。

17.5.9 最小架构与企业级架构的差异

最小可用 EvalOps 先证明闭环，企业级 EvalOps 则要证明它能被多个团队长期、稳定、可审计地使用。两者的差异不在页面数量，而在隔离、权限、运行可靠性和治理能力。

能力	最小可用 EvalOps	企业级 EvalOps
数据管理	单业务 Dataset 和 Case 版本	多业务、多租户、权限分级、脱敏和生命周期管理
执行调度	手动触发或简单批处理	队列、优先级、并发控制、超时、重试和资源配额
Evaluator 运行	规则、脚本、Judge 统一调用	插件沙箱隔离、版本审批、漂移监控和失败降级
Trace 存储	保存关键工具调用和结果	分层存储、敏感字段治理、回放索引和审计查询
权限与审计	记录主要变更人	RBAC、隐藏集访问控制、门禁变更审批、审计日志
成本治理	记录单次 Run 成本	预算、限流、成本归因、异常成本告警和降级策略
线上回流	手动导入 Bad Case	自动采样、脱敏、聚类、归因任务和回归候选流转
发布集成	输出报告供人工判断	CI/CD 门禁、风险接受、灰度策略和回滚联动

企业级架构还要明确运行时边界。Evaluator 插件不应直接访问生产数据；红队样本和 Hidden Set 需要更严格权限；工具调用应优先进入沙箱或只读模拟环境；线上回流必须先脱敏和去重，再进入人工审核或评测数据资产。

可以把企业级 EvalOps 看成四层：

1. 资产层：Dataset、Case、Rubric、Evaluator、Trace Schema、Gate。
2. 执行层：任务队列、执行引擎、沙箱、工具代理、Evaluator 插件。
3. 证据层：Run、版本血缘、Trace、评分结果、人工复核、审计日志。
4. 决策层：Report、Gate、灰度建议、风险接受、线上回流和修复任务。

这四层缺一不可。只有资产层，会变成数据仓库；只有执行层，会变成跑分脚本；只有报告层，会回到一次性评测。EvalOps 的价值在于把资产、执行、证据和决策连成长期运行的质量基础设施。

17.6 插件化 Evaluator 设计

Evaluator 插件化的关键，是统一输入和输出。

统一输入可以包括：

• Case。
• 模型输出。
• Trace。
• 工具调用记录。
• 检索证据。
• 环境终态。

统一输出可以包括：

字段	说明
evaluator_id	评估器标识
evaluator_version	评估器版本
score	分数
pass	是否通过
reason	解释
confidence	置信度
labels	错误标签
evidence	支撑证据

这样规则、脚本、Judge 和人工都能进入同一结果体系。平台后续才能统一做报告、门禁和归因。

17.6.1 插件接口的稳定性

Evaluator 插件接口要稳定，否则平台会被每个评估器实现细节拖垮。

推荐把接口分成三层：

层级	说明
输入适配	将 Case、输出、Trace 和证据转换成 Evaluator 所需格式
评估执行	运行规则、脚本、Judge 或人工流程
结果归一	输出统一的 score、pass、reason、confidence、labels、evidence

这样即使 Judge 模型、规则脚本或人工标注平台发生变化，平台主对象仍保持稳定。

17.7 权限与审计

企业级评测平台必须有权限和审计设计。

需要控制的对象包括：

• 隐藏评测集。
• 高风险 Red Team 样本。
• 线上脱敏数据。
• 人工标注结果。
• Judge Prompt。
• 发布门禁配置。
• 审批和豁免记录。

审计需要记录：

• 谁创建或修改了数据集。
• 谁修改了 Evaluator。
• 谁批准了门禁豁免。
• 哪次 Run 支撑了发布。
• 哪些 Bad Case 已修复并回归。

评测平台不仅是技术系统，也是质量治理系统。

17.8 平台演进路径

EvalOps 平台不需要一步到位。可以按四个阶段演进。

阶段	形态	重点
单脚本	本地脚本和表格	快速验证评测方法
工具集	数据、评估器、报告脚本分离	提升复用性
团队平台	多人共享数据、任务、结果	支持稳定回归
组织级基础设施	接入 CI/CD、门禁、线上回流、审计	支撑发布治理

过早建设大平台容易失败。正确路径是先把对象模型和闭环跑通，再逐步平台化。

17.8.1 最小可用 EvalOps 闭环

最小可用 EvalOps 平台不需要一次覆盖全部功能，但必须跑通质量闭环。

一个可接受的最小闭环包括：

1. 能管理一个核心业务场景的数据集和 Case。
2. 能记录模型、Prompt、工具、知识库和 Evaluator 版本。
3. 能稳定执行规则、脚本、Judge 和必要人工复核。
4. 能输出 Run、Report、Bad Case 和门禁结论。
5. 能把线上高价值 Bad Case 回流为候选 Regression Case。

如果一个平台有复杂看板，却无法复现 Run；有多模型接入，却没有 Case 版本；有报告页面，却不能影响发布，它仍然不是合格的 EvalOps 起点。

客服 Agent 的最小闭环可以只从退款场景开始：管理退款 Eval Set，执行退款 RAG / Tool / Trace Case，输出发布门禁报告，接入会员部分退款线上 Bad Case 回流。这个闭环稳定后，再扩展到物流、发票、投诉等场景。

17.8.2 平台建设优先级

平台建设应优先支持最小质量闭环，而不是一次性覆盖所有功能。

优先级可以这样排序：

优先级	能力	原因
P0	Dataset、Case、Run、Evaluator、Report	没有这些对象，评测不可复现
P1	Trace、版本血缘、门禁	支撑 Agent 评测和发布决策
P2	人工复核、线上回流、Bad Case 归因	支撑长期闭环
P3	高级分析、跨业务看板、自动归因推荐	提升效率，但不是起点

客服 Agent 的平台化起点可以很小：先管理退款场景的 Case、Run、Evaluator 和 Report；再接入退款工具 Trace 和发布门禁；最后接入线上 Bad Case 回流。

17.9 交付物一：EvalOps 平台对象模型图

对象	必备字段	关键关系
Model	model_id、version、provider、config	Run
Prompt	prompt_id、version、content_hash	Agent、Run
Dataset	dataset_id、version、split	Case、Run
Case	case_id、risk_level、scenario	Dataset、Run
Evaluator	evaluator_id、version、type	Run、Metric
Agent	agent_id、config_version	Tool、Prompt、Run
Tool	tool_id、schema_version、permission	Agent、Trace
Run	run_id、timestamp、config_snapshot	所有对象
Trace	trace_id、case_id、run_id	Run、Report
Report	report_id、run_id、decision	Gate

17.10 交付物二：评测平台模块架构图

数据管理
  Dataset / Case / 标签 / 版本 / 权限

任务编排
  Task / Queue / 并发 / 重试 / 断点续跑

执行引擎
  Model / Prompt / Agent / Tool / Sandbox / Trace

Evaluator 插件
  Rule / Script / Judge / Human / State Check

结果分析
  Metric / 对比 / 切片 / Bad Case / 置信度

门禁报告
  Gate / 灰度 / 审批 / 看板 / 审计

17.11 本章小结

EvalOps 平台的本质不是把评测脚本搬到网页上，而是把评测对象、执行过程、评估器、结果、门禁和审计组织成可复现、可扩展、可治理的系统。

平台建设最重要的起点是对象模型。对象模型清楚，评测结果才能解释；Run 血缘完整，版本对比才能可信；Evaluator 插件统一，评测能力才能持续扩展。

下一章，我们将深入平台最核心的能力——自动化执行、版本血缘记录和可复现运行。