第 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-1 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 平台至少需要管理以下对象。
本节给出概念对象全集；17.9 交付物是平台落库时的权威最小数据字典。概念对象可以在实现中拆表或合表，但不能丢失对应责任与血缘。
| 对象 | 作用 |
|---|---|
| Model | 被评模型或模型服务 |
| Prompt | 系统提示词、任务提示词、Judge Prompt |
| Agent | Agent 配置、编排策略、状态管理方式 |
| Tool | 工具 Schema、权限、版本和调用方式 |
| Environment | 知识库、索引、沙箱、权限和外部依赖快照 |
| Dataset | 评测数据集 |
| Case | 评测执行最小单元 |
| Evaluator | 规则、脚本、Judge、人工评测配置 |
| Task | 一次评测任务定义 |
| Run | 一次实际评测运行 |
| Case Result | 某次 Run 中一条 Case 的执行事实、输出和 artifact 引用 |
| Evaluation Result | 某个 Evaluator 对一条 Case Result 的独立判断 |
| Metric | 指标定义和计算方式 |
| Trace | Agent 执行轨迹 |
| Report | 结果报告和发布建议 |
| Gate | 版本化的门禁策略和规则 |
| Gate Result | 某次 Run 按某个 Gate 版本计算出的门禁证据 |
这些对象之间的关系决定了平台能否复现评测。
一个客服 Agent 的 Run 不能停在“跑了退款评测集”这条摘要上，还要绑定：
- Model：使用哪个模型服务和版本。
- Prompt：使用哪个客服 Prompt 和系统指令。
- Agent：使用哪个编排配置。
- Tool：使用哪个订单查询和退款工具 Schema。
- Dataset：使用哪个 Eval Set 版本。
- Case：执行了哪些具体样本。
- Case Result：每条 Case 实际产生了什么输出、Trace、错误和执行状态。
- Evaluator：使用了哪些规则、脚本、Judge 和人工流程。
- Evaluation Result：每个 Evaluator 对哪条 Case Result 给出了什么判断和证据。
- Environment：知识库、索引、权限和沙箱配置。
- Metric：计算了哪些指标。
- Trace：每条 Agent 执行轨迹。
- Gate：使用哪个版本化门禁策略。
- Gate Result：该 Run 按 Gate 版本计算出的不可变门禁证据。
- Report：汇总结果、风险、Gate Result 和发布建议；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 --> CASE_RESULT["Case Results"]
CASE --> CASE_RESULT
RUN --> EVAL["Evaluator Version"]
RUN --> AGENT["Agent Config"]
RUN --> TOOL["Tool Schema"]
RUN --> ENV["Environment"]
CASE_RESULT --> TRACE["Trace"]
CASE_RESULT --> EVAL_RESULT["Evaluation Results"]
EVAL --> EVAL_RESULT
EVAL_RESULT --> METRIC["Metric Values"]
GATE["Gate Policy"] --> GATE_RESULT["Gate Result"]
RUN --> GATE_RESULT
METRIC --> GATE_RESULT
RUN --> REPORT["Report"]
GATE_RESULT --> REPORT["Report"]
如果 Run 记录完整，就可以回答：
- 为什么这次分数和上次不同？
- 是模型变了，还是数据变了？
- Judge 是否升级过？
- 知识库索引是否一致？
- 哪些 Case 失败了？
- 失败是否集中在某个工具、场景或风险等级？
没有 Run 血缘，平台只能展示结果，不能解释结果。
17.4.1 对象契约
EvalOps 平台对象承担跨团队协作契约的职责，不能被理解为一组数据库表名。每个对象都应说明自己由谁创建、由谁维护、被哪些流程消费，以及变更后会影响哪些下游对象。
| 对象 | 上游来源 | 下游消费 | 变更影响 |
|---|---|---|---|
| Case | 评测数据、线上 Bad Case、专家样本 | Run、Case Result、Evaluator | 影响输入、期望和样本覆盖 |
| Case Result | Run、Case、执行引擎 | Evaluation Result、Trace、Report | 记录一次执行事实，不得被后续重跑覆盖 |
| Evaluator | 规则、脚本、Judge Prompt、人工流程 | Run、Metric、Gate、Meta-Eval | 影响评分口径和门禁稳定性 |
| Evaluation Result | Case Result、Evaluator、评判证据 | Metric、Report、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 | draft、active、deprecated、retired |
| Gate Result | pending、passed、blocked、approval_required、error |
| Run | created、queued、running、completed、failed、cancelled |
| Report | draft、reviewed、published、superseded |
这些状态能解决两个常见问题。第一，评测集和 Evaluator 不能未经审核就进入门禁；第二，已失效对象不能继续影响发布。
例如，一个退款政策 Case 如果依赖已经下线的业务规则，应从 approved 变为 retired，而不是继续留在 Golden Set 中计算总分。一个 Judge Prompt 如果没有通过人工校准集，应停留在 experimental，不能用于发布门禁。门禁豁免属于单次发布决策，不是 Gate 策略本身的生命周期状态。
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 看成四层：
- 资产层：Dataset、Case、Rubric、Evaluator、Trace Schema、Gate。
- 执行层：任务队列、执行引擎、沙箱、工具代理、Evaluator 插件。
- 证据层：Run、Case Result、Evaluation Result、版本血缘、Trace、人工复核和审计日志。
- 决策层：Report、Gate Result、发布决定、灰度建议、风险接受、线上回流和修复任务。
17.5.1—17.5.8 是按产品模块划分职责，四层架构则按数据流划分运行边界：数据管理主要属于资产层；任务编排、执行引擎和 Evaluator 插件属于执行层；结果分析和人工复核横跨证据层；门禁报告与线上回流主要属于决策层。模块可以跨层消费对象，两种视图不要求一一对应。
这四层缺一不可。只有资产层，会变成数据仓库；只有执行层，会变成跑分脚本；只有报告层，会回到一次性评测。EvalOps 的价值在于把资产、执行、证据和决策连成长期运行的质量基础设施。
17.6 插件化 Evaluator 设计
Evaluator 插件化的关键，是统一输入和输出。
Evaluator 的统一输入应以 Case Result 为中心，并引用：
- Case。
- Case Result 中的模型或 Agent 输出。
- Trace。
- 工具调用记录。
- 检索证据。
- 环境终态。
统一输出形成一条 Evaluation Result：
| 字段 | 说明 |
|---|---|
| evaluation_result_id | 评判结果唯一标识 |
| case_result_id | 被评的执行结果 |
| evaluator_id | 评估器标识 |
| evaluator_version | 评估器版本 |
| metric_values | 该 Evaluator 产生的指标值 |
| outcome | passed / failed / needs_human_review / error |
| reason | 解释 |
| confidence | 置信度 |
| labels | 错误标签 |
| evidence | 支撑证据 |
| review_required | 是否进入人工复核 |
这样规则、脚本、Judge 和人工都能进入同一结果体系。平台后续才能统一做报告、门禁和归因。
其中 confidence 需要带来源和语义。Judge 自报置信度只能作为复核分流信号，不能直接解释为校准概率；规则或统计 Evaluator 若输出置信区间，也应使用独立字段表达区间方法和覆盖口径。
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 平台可以暂时缺少部分功能，但要跑通质量闭环。
一个可接受的最小闭环包括：
- 能管理一个核心业务场景的数据集和 Case。
- 能记录模型、Prompt、工具、知识库和 Evaluator 版本。
- 能稳定执行规则、脚本、Judge 和必要人工复核。
- 能输出 Run、Report、Bad Case、Gate Result 和发布建议，并把最终发布决定留给责任流程。
- 能把线上高价值 Bad Case 回流为候选 Regression Case。
如果一个平台有复杂看板，却无法复现 Run；有多模型接入，却没有 Case 版本；有报告页面，却不能影响发布，它仍然不是合格的 EvalOps 起点。
客服 Agent 的最小闭环可以只从退款场景开始：管理退款 Eval Set，执行退款 RAG / Tool / Trace Case，输出发布门禁报告，接入会员部分退款线上 Bad Case 回流。这个闭环稳定后，再扩展到物流、发票、投诉等场景。
17.8.2 平台建设优先级
平台建设应优先支持最小质量闭环，而不是一次性覆盖所有功能。
优先级可以这样排序：
| 优先级 | 能力 | 原因 |
|---|---|---|
| 基础闭环 | Dataset、Case、Run、Evaluator、Report | 先形成可执行、可复查的评测事实 |
| 发布接入 | Trace、版本血缘、Gate 与 Gate Result | 支撑 Agent 评测和发布决策 |
| 持续改进 | 人工复核、线上回流、Bad Case 归因 | 支撑长期闭环 |
| 规模治理 | 高级分析、跨业务看板、自动归因推荐 | 提升效率，但不是起点 |
该优先级表是 17.8.1 最小闭环的实施排序：先保证 Case、Run、Evaluator 和 Report 可运行，再补 Trace 与门禁，最后扩展人工复核、线上回流和高级分析，不再单独定义另一套最小闭环。
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、case_version、risk_level、scenario | Dataset、Run、Case Result |
| Evaluator | evaluator_id、version、type | Run、Metric |
| Agent | agent_id、config_version | Tool、Prompt、Run |
| Tool | tool_id、schema_version、permission | Agent、Trace |
| Environment | environment_id、version、permissions、dependency_snapshot | Run、Tool、Trace |
| Run | run_id、timestamp、config_snapshot、case_results_uri | 所有对象 |
| Case Result | case_result_id、run_id、case_id、case_version、execution_status、quality_status、output、artifact_refs | Evaluation Result、Trace、Report |
| Evaluation Result | evaluation_result_id、case_result_id、evaluator_id、evaluator_version、metric_values、outcome、evidence | Metric、Gate Result、Report |
| Trace | trace_id、case_result_id、run_id | Case Result、Report |
| Gate | gate_id、version、metric_rules、action | Metric、Gate Result、CI/CD |
| Gate Result | gate_result_id、gate_id、gate_version、run_id、outcome、evidence | Report、发布决策 |
| Report | report_id、run_id、gate_result_ids、recommendation | 产品、研发、安全、管理层 |
| Task | task_id、scope、trigger | Run |
| Metric | metric_id、definition、version | Evaluator、Report、Gate |
17.10 交付物二：评测平台模块架构图
flowchart TB
DATA["数据管理<br/>Dataset / Case / 标签 / 版本 / 权限"]
TASK["任务编排<br/>Task / Queue / 并发 / 重试 / 断点续跑"]
ENGINE["执行引擎<br/>Model / Prompt / Agent / Tool / Sandbox / Trace"]
EVAL["Evaluator 插件<br/>Rule / Script / Judge / Human / State Check"]
RESULT["结果分析<br/>Case Result / Evaluation Result / Metric / 对比 / Bad Case"]
GATE["门禁报告<br/>Gate / 灰度 / 审批 / 看板 / 审计"]
DATA --> TASK
TASK --> ENGINE
ENGINE --> EVAL
EVAL --> RESULT
RESULT --> GATE
RESULT --> DATA
17.11 方法依据与适用边界
本章对象模型是面向企业评测闭环的参考设计，不是对某个开源平台或行业标准的复刻。它借鉴了两类已有工程基础：
- MLflow Tracking围绕 Run 记录参数、指标、时间和 artifact，为本章的 Run 血缘与结果存储提供了实验追踪参照。
- OpenTelemetry Generative AI Semantic Conventions持续定义模型调用、Agent、工具、事件和指标的可观测语义，为 Trace 和跨系统关联提供了参照；相关约定仍在演进，落地时要记录采用版本，不能把实验性字段当作永久契约。
本书在这些基础上增加 Case、Case Result、Evaluation Result、Gate Result 和发布决定，用来表达业务评测与发布治理，不意味着上述项目采用了完全相同的对象。团队可以映射到现有平台，但应保留各对象的责任边界和关联键。
17.12 本章小结
EvalOps 平台把评测对象、执行过程、评估器、结果、门禁和审计组织成可复现、可扩展、可治理的系统。仅把评测脚本搬到网页上，还没有解决这些问题。
平台建设最重要的起点是对象模型。对象模型清楚，评测结果才能解释；Run 血缘完整，版本对比才能可信；Evaluator 插件统一，评测能力才能持续扩展。
下一章，我们将深入平台最核心的能力——自动化执行、版本血缘记录和可复现运行。