AI 扩展计划 / Playbooks

AI EvalOps Platform Architecture Playbook

很多团队把 eval 理解成上线前跑一张测试表。生产级 AI 系统不能这样做, 因为 LLM / RAG / Agent 的风险不是单点风险:

1,123 行AI_EVALOPS_PLATFORM_ARCHITECTURE_PLAYBOOK.md

AI EvalOps Platform Architecture Playbook

面向对象: AI PM / AI Architect / EvalOps Lead / Platform PM / Model Risk / AI Governance / 金融零售转型负责人。核心问题: 如何把 eval 从一次性测试活动升级为企业 AI 平台能力, 支撑 prompt、model、RAG、tool、agent 和 judge 的持续发布、生产监控、风险控制和审计证据。学习目标: 能设计一套可复用 EvalOps 平台架构, 能定义 release gate 和 evidence binder, 能把金融零售 AI 用例做成可评估、可上线、可监控、可复盘、可展示的作品集资产。

1. 定位: EvalOps 不是测试, 是 AI 生产控制面

很多团队把 eval 理解成上线前跑一张测试表。生产级 AI 系统不能这样做, 因为 LLM / RAG / Agent 的风险不是单点风险:

模型版本会变。
prompt 和 policy 会变。
RAG 知识库会刷新。
embedding、reranker、chunking 会影响证据。
tool schema 和权限会改变 agent 行为。
judge model 本身也会漂移。
生产流量会出现实验集没有覆盖的新型失败。

一句话:

EvalOps Platform = 用统一的数据集、评估器、实验比较、发布门禁、生产监控和证据链, 管理 AI 系统从开发到运行的质量与风险。

这份手册不讲 BA 基础, 不重复“怎么写需求”。它训练的是更高级的产品架构能力:

高级能力	具体表现	作品集资产
把 eval 产品化	设计 dataset registry、judge registry、eval runner、experiment store、release gate	EvalOps platform architecture
把质量变成决策	用 pass/fail、critical failure、confidence interval、slice regression 支撑 go / no-go	Release gate memo
把生产监控接回评估	从 production traces 发现失败, 进入 golden set, 验证修复后再发布	Continuous evaluation loop
把风险变成证据	每次模型、prompt、RAG、tool 变更都有 lineage、run、approval、exception	Evidence binder
把金融场景讲清楚	AML、KYC、支付争议、客户可见 AI 的门禁和监控不同	Financial retail case portfolio

2. Source Anchors

以下来源作为学习锚点和术语校准。正式项目必须按访问日期复核最新版本、产品状态、地区可用性、合同条款、监管要求和机构内部政策。

Anchor	Link	本手册使用方式
OpenAI Evals GitHub	https://github.com/openai/evals	学习 eval framework、benchmark registry、custom eval、model-graded eval 和本地评估组织方式。
OpenAI Evals API guide	https://developers.openai.com/api/docs/guides/evals	学习 programmatic eval、data source、testing criteria、eval run、report_url、usage 和结果分析；截至 2026-06-29, OpenAI 文档提示 Evals platform 将进入 deprecation timeline, 因此本文把它作为设计锚点而非唯一平台依赖。
MLflow LLM and Agent Evaluation	https://mlflow.org/docs/latest/genai/eval-monitor/	学习 evaluation-driven development、dataset management、human feedback、LLM-as-a-judge、systematic evaluation 和 production monitoring。
MLflow evaluation datasets	https://mlflow.org/docs/latest/genai/datasets/	学习 evaluation dataset、production trace mining、golden set、版本比较、特殊数据集和环境验证。
LangSmith Evaluation	https://docs.langchain.com/langsmith/evaluation	学习 offline / online evaluation、dataset、evaluator、experiment、production trace、feedback loop。
LangSmith Evaluation Concepts	https://docs.langchain.com/langsmith/evaluation-concepts	学习 evaluation lifecycle、offline vs online、runs / threads、human / code / LLM-as-judge / pairwise evaluator。
Google Gen AI evaluation overview	https://docs.cloud.google.com/gemini-enterprise-agent-platform/models/evaluation-overview	学习 enterprise evaluation service、adaptive rubric、static rubric、deterministic metric、custom function、model migration、prompt improvement 和 model comparison。
NIST AI RMF	https://www.nist.gov/itl/ai-risk-management-framework	用 Govern / Map / Measure / Manage 组织 AI 风险识别、评估、监控、处置和证据。

3. 与现有学习资产的连接

已有文档	本手册如何补强
`docs/AI_REQUIREMENTS_TO_EVAL_COOKBOOK.md`	从单个需求到 eval contract, 延展为平台级 dataset、runner、gate、monitoring 和 evidence。
`docs/AI_RETRIEVAL_EVAL_GRAPH_RAG_PLAYBOOK.md`	将 retrieval eval 纳入统一 EvalOps 架构, 处理 prompt / model / RAG / tool 的联合回归。
`docs/AI_MODEL_RISK_MANAGEMENT_PLAYBOOK.md`	把 MRM 的 inventory、validation、ongoing monitoring 和 effective challenge 落成可执行 eval 证据链。
`docs/AI_AUDIT_EVIDENCE_BINDER_PLAYBOOK.md`	把 EvalOps run、dataset lineage、approval、exception、production sample 和 drift report 接入审计证据包。
`docs/AI_PLATFORM_PM_PLAYBOOK.md`	把 eval harness 从平台 backlog 项升级成完整平台能力地图和产品架构。
`docs/AI_OBSERVABILITY_COST_SLO_PLAYBOOK.md`	把 AI traces、quality signal、cost、latency、incident loop 与 continuous evaluation 打通。

4. 高级框架: EvalOps Control Plane

EvalOps 平台的核心不是“跑分”, 而是建立一个 AI quality and risk control plane。

AI change
  -> component registration
  -> dataset selection
  -> evaluator selection
  -> experiment execution
  -> comparison and slice analysis
  -> release gate decision
  -> evidence binder
  -> production monitoring
  -> failure mining
  -> dataset and control update

4.1 七个控制对象

控制对象	管什么	决策问题	关键证据
Use case	业务用途、风险等级、用户、影响边界	这个 AI 能不能进入某类流程?	Use case card、risk tier、approved use
Component	model、prompt、RAG index、retriever、tool、judge、guardrail	哪个组件变了, 变更影响什么?	Component registry、version diff、owner
Dataset	offline set、golden set、red-team set、production sample、human review set	用什么样本证明质量?	Dataset card、lineage、coverage matrix
Evaluator	deterministic check、human rubric、LLM judge、pairwise、custom code	用什么评估方式支持上线决策?	Evaluator card、calibration report
Experiment	某个版本组合在某个数据集上的运行	新版本是否优于基线, 是否引入回归?	Experiment report、slice comparison
Gate	pilot、release、scale、quarterly review	是否放行、限制放行、回滚或停止?	Gate memo、approval、exception
Production signal	live trace、feedback、monitoring、incident、drift	上线后是否仍然可靠?	Monitoring dashboard、sample review、incident RCA

4.2 三类决策

EvalOps 支撑的决策应分三类, 不能混成一个平均分:

决策类型	典型问题	推荐输出
Engineering decision	哪个 prompt / model / retriever / tool schema 更好?	experiment comparison、slice diff、cost / latency trade-off
Release decision	当前版本是否能进入 pilot / production / scale?	release gate memo、critical failure list、risk acceptance
Risk decision	是否需要限制用途、人工复核、补偿控制或停用?	risk issue、control exception、management attestation

4.3 指标分层

指标必须服务于决策。一个成熟 EvalOps 平台同时保留五层指标:

指标层	示例	不能怎么用	正确用法
Component metrics	retrieval recall@k、tool call accuracy、format pass rate	单独说系统安全	定位组件瓶颈
Output quality	groundedness、completeness、policy compliance、tone	只看平均分	分风险等级和场景切片
Safety / risk	critical violation、unauthorized action、PII leakage、under-escalation	用低频率掩盖严重性	hard stop, 关键风险阈值为 0
Operational	latency、cost、timeout、fallback、human override	只优化成本	与质量和风险联合看
Business	handle time、rework、case quality、appeal rate、complaint rate	直接归因给模型	与流程、采用率、人工行为一起解释

5. Eval 生命周期: 从设计到生产反馈

5.1 生命周期总览

L0 Scope
  明确 use case、风险等级、workflow insertion point、禁止用途

L1 Eval Contract
  把可接受行为、不可接受行为、失败严重度、评估方法和门禁阈值写成 contract

L2 Dataset Build
  建立 curated set、golden set、red-team set、historical set、production sample

L3 Evaluator Build
  配置 deterministic、human、judge、pairwise、custom evaluator, 并校准一致性

L4 Experiment
  对 prompt/model/RAG/tool 组合做批量比较和切片分析

L5 Release Gate
  形成 go / limited go / no-go / rollback / exception 决策

L6 Production Evaluation
  对线上 traces 做抽样、在线评估、告警、人工复核和趋势分析

L7 Continuous Improvement
  把失败 trace 转为 dataset case, 验证修复, 更新 golden set 和证据包

5.2 每个阶段的输出

阶段	主要动作	决策输出	证据输出
Scope	确定业务边界、风险 tier、用户、流程节点	是否需要 formal EvalOps gate	Use case card、risk tier memo
Eval Contract	定义目标行为、失败模式、严重度、阈值	哪些指标是 release blocker	Requirements-to-Eval Matrix
Dataset Build	建立数据集、标注、血缘、版本	数据集是否足以支撑决策	Dataset card、coverage report
Evaluator Build	选择 evaluator、校准 judge、人审一致性	evaluator 是否可用于门禁	Evaluator card、calibration report
Experiment	批量运行、比较、切片、根因	哪个版本进入 gate	Experiment comparison report
Gate	审核结果、例外、控制、回滚	go / no-go / limited release	Gate memo、approval record
Production	抽样评估、监控漂移、反馈闭环	是否触发回滚或 remediation	Monitoring report、issue log
Improvement	新增案例、修复、复测	是否关闭问题	Regression report、evidence update

6. 评估方法组合: Offline / Online / Human / Judge

EvalOps 平台不是只选一种评估方法, 而是按风险和决策目的组合。

6.1 方法决策表

方法	适合回答的问题	强项	局限	金融零售用法
Offline eval	新版本上线前是否退化?	可重复、可比较、可进 CI/CD	依赖数据集代表性	prompt/model/RAG/tool 回归门禁
Online eval	线上真实流量是否出现新失败?	贴近生产、能发现分布变化	缺少 reference, 成本和隐私敏感	客服 AI 抽样质检、AML copilot live trace review
Human eval	专家是否认可业务判断和风险边界?	高可信、能处理复杂语义	慢、贵、一致性需要管理	AML narrative、KYC policy、投诉回复
LLM-as-judge	大规模初筛质量、安全、语气、grounding	快、可扩展、适合趋势	judge bias、judge drift、需校准	每日质量抽样和回归初筛
Deterministic eval	格式、字段、权限、工具参数是否正确?	稳定、可解释、适合 hard stop	不能判断复杂语义	PII 禁止输出、JSON schema、tool argument
Pairwise eval	A 版本是否优于 B 版本?	适合模型迁移和 prompt 对比	需要控制顺序偏差	模型升级、RAG 策略替换
Red-team eval	是否能被绕过、泄露、越权或误导?	揭示安全和滥用风险	覆盖永远不完整	prompt injection、policy bypass、excessive agency
Backtesting	新版本放到历史案例是否更好?	接近业务结果	标签延迟和流程变化会影响解释	支付争议、欺诈、AML 历史 case

6.2 评估器优先级

原则:

能用 deterministic check 的, 不先用 judge。
高风险语义判断必须有人类专家校准。
Judge 适合扩展, 不适合无校准地替代责任人。
Online eval 发现问题, offline eval 验证修复。
平均分不能覆盖 critical failure。

6.3 Evaluator Card

每个 evaluator 都应登记:

字段	说明
evaluator_id	唯一编号, 如 `JUDGE-GROUNDEDNESS-V1`
evaluator_type	deterministic / human / LLM judge / pairwise / custom function
measured_dimension	groundedness、policy compliance、tool accuracy、tone、safety
input_schema	evaluator 看到哪些输入: query、context、answer、tool trace、reference
scoring_schema	pass/fail、1-5、0-1、label、severity
calibration_set	用于校准的 human-labeled cases
agreement_metric	与专家一致率、Cohen kappa、conflict rate、false pass rate
known_bias	verbosity bias、position bias、over-refusal bias、domain blind spot
allowed_use	可用于 screening / release gate / monitoring / research
prohibited_use	不得单独决定高风险上线或客户补救
owner	评估器维护人和审批人
review_frequency	每月、每季度或重大模型变更后

7. Dataset、Version、Lineage 与 Golden Set 治理

没有数据集治理, eval 只是一组不可追溯的测试样本。

7.1 Dataset 分类

Dataset 类型	来源	用途	治理重点
Smoke set	人工构造的少量核心样本	快速检查版本是否可运行	少而稳定, 不追求覆盖
Golden set	专家确认必须通过的关键样本	release blocker	版本锁定、变更审批、严控污染
Regression set	历史失败、事故、投诉、bad feedback	防止复发	每次修复后纳入
Red-team set	越权、注入、泄露、滥用、违规诱导	安全门禁	按攻击类型和风险等级维护
Slice set	语言、地区、产品、客户类型、渠道、文档版本	检查局部退化	与业务 segment 对齐
Production sample	线上真实 traces 抽样	监控现实分布	隐私、脱敏、抽样策略、保留期限
Human review set	专家复核或标注样本	校准 judge 和 rubric	reviewer 资质、一致性、争议处理
Synthetic set	按模板或模型生成	扩展边界覆盖	必须标注 synthetic lineage, 不可替代真实 case

7.2 Dataset Card 最小字段

字段	内容
dataset_id	`AML-COPILOT-GOLDEN-2026Q2`
purpose	支撑哪个 use case、gate 和决策
source	人工构造、历史案例、生产 trace、合成、第三方
sample_count	总样本数和各 slice 数量
risk_coverage	覆盖哪些高风险失败: unsupported claim、PII leakage、under-escalation
reference_type	label、reference answer、gold doc、expected behavior、rubric
data classification	PII、confidential、restricted、public
lineage	原始系统、抽样日期、清洗逻辑、脱敏策略、标注人
version	数据集版本, 变更说明, 生效日期
owner	business SME、data owner、model risk owner
allowed use	offline release gate、judge calibration、monitoring sampling
prohibited use	不得用于训练、不得导出、不得进入低权限环境
retention	保留期限和删除机制

7.3 Golden Set 治理

Golden set 不是越大越好。它应代表“绝不能退化”的业务关键行为。

治理动作	规则
Promotion	只有专家确认、风险标注完整、参考答案或 gold evidence 明确的 case 才能进入 golden set
Demotion	业务规则废止、政策失效、样本与生产不再相关时, 从 golden set 转入 archive
Version lock	每次 release gate 固定 dataset version, 不允许边跑边改
Contamination control	不能把 golden answer 泄露进 prompt、few-shot、训练数据或开发调试样例
Slice balance	高频 case、边界 case、高风险 case、历史失败 case 都要有最低覆盖
Review cadence	高风险用例至少季度复核, 政策或产品重大变化后立即复核
Change approval	增删 high-risk golden case 需要 business SME + risk owner 双签

7.4 Lineage 追踪

每个 eval result 必须能追溯到:

use_case_id
component_versions:
  model_id
  prompt_version
  policy_config_version
  retriever_version
  embedding_model_version
  index_version
  reranker_version
  tool_schema_version
  guardrail_version
  judge_version
dataset_version
evaluator_version
run_id
environment
timestamp
approver
decision

如果这些字段缺失, 评估结果就很难支撑审计、复盘和回滚。

8. 实验比较与回归: Prompt / Model / RAG / Tool

AI 系统升级通常不是“换一个模型”这么简单。每次变更都要先判断回归范围。

8.1 变更类型与必测项

变更类型	典型例子	必测项
Prompt change	系统提示词、few-shot、拒答规则、输出格式	instruction following、policy compliance、format、tone、over-refusal
Model change	模型升级、供应商切换、路由策略调整	全量 golden set、pairwise、cost、latency、critical failure
RAG change	chunking、embedding、index refresh、retriever、reranker	recall、context precision、citation support、freshness、permission
Tool change	tool schema、API 参数、权限、idempotency	tool selection、argument accuracy、authorization、side effect
Judge change	judge model、rubric、scoring prompt	human agreement、false pass、false fail、bias check
Guardrail change	policy rule、content filter、PII redaction	blocked harmful、allowed valid、overblocking、audit log
Workflow change	handoff、HITL、fallback、agent trajectory	escalation、loop prevention、state consistency、human approval

8.2 实验比较矩阵

维度	Baseline	Candidate	Decision Lens
Overall pass rate	当前生产版本	新版本	只能作摘要, 不能单独放行
Critical failure count	必须为 0	必须为 0	任一 critical failure 触发 no-go 或 exception
High-risk slice	AML / KYC / complaints 等	同 slice 对比	高风险 slice 优先于总体平均
Regression cases	历史失败集	必须不复发	复发说明 remediation 未闭环
Human agreement	专家评分	与专家一致	决定 judge 是否可信
Cost per successful task	成本 / 通过任务	成本 / 通过任务	不能只看 token 单价
P95 latency	生产要求	新版本表现	超出 workflow SLA 可能 no-go
Coverage	数据集覆盖	新增缺口	覆盖不足应限制上线范围

8.3 回归判定

建议使用四级回归判定:

等级	判定	动作
Critical regression	出现越权动作、PII 泄露、错误客户承诺、错误高风险建议、unsupported critical claim	no-go, 修复后重跑 gate
Material regression	高风险 slice 显著下降, 或历史失败复发	limited release 或 no-go, 需要 risk owner 签署
Local regression	某些低风险 slice 下降, 有人工兜底	可 conditional go, 进入 issue backlog
No material regression	指标稳定或提升, 无 critical failure	可进入下一 gate

9. 平台架构: EvalOps Reference Architecture

9.1 架构图

flowchart TB
  U[AI Use Case / Product Team] --> I[Intake and Risk Tiering]
  I --> C[Component Registry]
  C --> PR[Prompt / Policy Registry]
  C --> MR[Model Registry]
  C --> KR[RAG / Knowledge Registry]
  C --> TR[Tool Registry]
  C --> JR[Judge / Evaluator Registry]

  I --> DS[Dataset Registry]
  DS --> ER[Eval Runner]
  PR --> ER
  MR --> ER
  KR --> ER
  TR --> ER
  JR --> ER

  ER --> XS[Experiment Store]
  XS --> CR[Comparison and Slice Analysis]
  CR --> RG[Release Gate Workflow]
  RG --> EB[Evidence Binder]
  RG --> DEP[Deployment / Model Gateway]

  DEP --> PT[Production Traces]
  PT --> OM[Online Monitoring and Sampling]
  OM --> HA[Human Review Queue]
  OM --> AD[Anomaly / Drift Detection]
  HA --> DS
  AD --> DS
  OM --> EB

9.2 核心平台组件

组件	产品职责	架构职责	风险职责
Intake and Risk Tiering	让 use case 进入统一治理入口	生成 use_case_id 和风险上下文	决定 gate 强度
Component Registry	记录模型、prompt、RAG、tool、judge 版本	提供可追溯配置快照	防止影子组件上线
Dataset Registry	管理 dataset card、版本、血缘、权限	支持 dataset search、version lock、export control	证明样本代表性和使用合规
Evaluator Registry	复用 deterministic / human / judge / pairwise evaluator	统一 evaluator schema 和运行接口	管理 judge calibration 和适用范围
Eval Runner	批量运行 app against dataset	支持并发、缓存、replay、环境隔离	保留可复现 run record
Experiment Store	存储结果、trace、score、成本、延迟	支持 baseline / candidate comparison	保留 evidence-grade audit trail
Gate Workflow	根据阈值、风险、例外生成发布决策	接入 CI/CD、approval、change management	形成正式 go / no-go 记录
Online Monitoring	抽样、在线评估、告警、反馈	接生产 trace、feedback、incident	发现生产漂移和未覆盖失败
Evidence Binder	汇总评估、审批、监控、例外、复盘	与 GRC / document repository 对接	支撑审计、监管、模型风险复核

9.3 最小数据模型

UseCase
  use_case_id
  risk_tier
  approved_use
  prohibited_use
  business_owner
  model_risk_owner

ComponentVersion
  component_id
  component_type
  version
  owner
  environment
  effective_date
  change_reason

DatasetVersion
  dataset_id
  version
  source
  lineage
  data_classification
  sample_count
  coverage_tags

EvaluatorVersion
  evaluator_id
  version
  type
  rubric
  calibration_set
  agreement_result

EvalRun
  run_id
  use_case_id
  component_snapshot
  dataset_version
  evaluator_versions
  environment
  scores
  failures
  cost
  latency
  trace_links

GateDecision
  gate_id
  run_ids
  decision
  release_scope
  blockers
  exceptions
  approvers
  rollback_plan

9.4 Build vs Buy 判断

维度	买平台更合适	自建更合适
Time to value	需要 1-2 个季度内统一评估流程	已有成熟 ML platform / observability / GRC
Data sensitivity	可接受 vendor 平台处理脱敏数据	高敏数据不能离开内网或特定区域
Custom workflow	标准实验比较和在线监控为主	复杂金融审批、模型风险、证据保留要求强
Integration	使用现成 LangSmith / MLflow / cloud eval 能快速接入	需要深度连接核心系统、case management、GRC
Audit	标准报告够用	需要 evidence-grade lineage、retention、legal hold
Talent	平台工程能力有限	有 AI platform、data governance、risk engineering 团队

实战建议:

先用成熟工具验证 workflow, 不要一开始自研所有 UI。
对高敏金融场景, 自建控制面或私有化部署通常更可控。
即使买平台, use case registry、risk tier、release gate 和 evidence binder 也要由企业自己定义。

10. Release Gates: 从 Pilot 到 Scale

10.1 Gate 总览

Gate	目标	放行条件	阻断条件
G0 Eval Readiness	use case 是否有可评估边界	risk tier、approved use、eval contract、owner 明确	业务边界不清, 没有 owner, 不知道什么叫失败
G1 Dataset Readiness	数据集是否能支撑评估	golden / regression / red-team / slice coverage 达标	high-risk slice 缺失, lineage 不清, PII 未处理
G2 Evaluator Readiness	evaluator 是否可信	judge 与专家校准达标, deterministic checks 可复现	judge false pass 高, rubric 含糊, 人审不一致
G3 Pilot Gate	是否能小范围试点	critical failure 为 0, 高风险输出有 HITL	未定义回滚, 未定义人工升级, 关键指标不达标
G4 Production Release	是否能生产发布	release scope、monitoring、incident、evidence 完整	high-risk regression, 生产日志不可复盘
G5 Scale Gate	是否能扩大用户或自动化程度	生产质量稳定, adoption 和风险指标可解释	judge drift、投诉上升、人工 override 异常
G6 Quarterly Review	是否继续、刷新、限制或退役	指标趋势、模型/知识更新、问题关闭	长期无人维护, 知识过期, 证据缺口

10.2 Gate Decision

Decision	含义	适用条件
Go	按批准范围发布	无 blocker, 监控和回滚就绪
Limited go	限定用户、流量、地区、功能、工具权限	局部指标可接受, 风险可由补偿控制覆盖
Conditional go	带期限和整改项发布	非 critical issue, 明确 owner 和到期日
No-go	不发布	critical failure、证据不足、owner 不清、风险不可接受
Rollback	回退上一版本	生产问题超过阈值或 gate 条件失效
Exception	风险接受	必须记录理由、范围、期限、补偿控制、审批人

10.3 Release Gate Memo 模板

# AI Release Gate Memo

## 1. Release Scope
- Use case:
- Version snapshot:
- Release population:
- Workflow insertion point:
- Approved use:
- Prohibited use:

## 2. Risk Tier and Control Posture
- Risk tier:
- Customer impact:
- Human oversight:
- Tool permissions:
- Data classification:

## 3. Eval Evidence
- Dataset versions:
- Evaluator versions:
- Baseline version:
- Candidate version:
- Critical failures:
- High-risk slice results:
- Regression set results:
- Red-team results:
- Cost / latency:

## 4. Decision
- Decision:
- Conditions:
- Exceptions:
- Approvers:
- Expiry date for exceptions:

## 5. Production Plan
- Monitoring signals:
- Sampling rate:
- Alert thresholds:
- Human review queue:
- Rollback trigger:
- Evidence location:

11. Production Evaluation、Calibration 与 Judge Drift

11.1 生产监控不是传统 APM

AI production monitoring 不能只看 uptime、latency、cost。必须监控模型行为、证据质量、用户反馈和风险信号。

信号	监控问题	触发动作
Quality score trend	LLM judge 或人审分数是否下降	抽样加密, 分析版本和流量变化
Critical failure	是否出现越权、泄露、错误承诺、错误高风险建议	立即升级, 冻结版本或限流
Human override	用户或复核人是否频繁改写 AI 输出	分析不信任、错误、流程不适配
User feedback	bad answer、not useful、unsafe、wrong citation	进入 triage 和 dataset backlog
Retrieval drift	gold-like live queries 的 context quality 是否下降	检查知识库、index、权限、metadata
Policy drift	政策更新后旧口径是否仍被引用	触发 RAG index refresh 和回归测试
Judge drift	judge 与人审一致性是否下降	重校准 judge 或更换 evaluator
Cost drift	单成功任务成本是否上升	分析模型路由、cache、prompt length、retrieval
Latency drift	P95 是否影响工作流	调整模型、并发、缓存、fallback

11.2 Online Evaluation 设计

设计项	建议
Sampling	按风险分层抽样: 高风险 100% 或高比例, 低风险按统计抽样
Privacy	production trace 进入 eval 前脱敏、最小化、按权限隔离
Reference-free scoring	线上通常没有 ground truth, 可评估 safety、format、grounding、citation、policy
Human review	对高风险和低置信样本进入专家队列
Feedback mining	用户负反馈、人工大幅改写、事故样本进入 regression set
Alerting	对 critical failure 用即时告警, 对趋势用周报或阈值告警
Evidence	每次抽样、评分、人审、处置都保留 trace link 和 decision log

11.3 Judge Calibration

LLM-as-judge 必须被管理为一个风险组件。

校准项	做法
Human agreement	用专家标注集比较 judge 结果, 记录一致率和争议
False pass	关注 judge 把坏输出判好的比例, 高风险场景尤其重要
False fail	关注 judge 过度拦截造成业务不可用
Bias test	检查 verbosity bias、position bias、format bias、language bias
Stability	同一输入多次评分是否稳定
Version compare	judge model 或 judge prompt 变更必须跑 calibration set
Periodic review	至少季度复核, 重大生产事件后立即复核

11.4 Judge Drift 信号

Drift 信号	含义	动作
Human disagreement 上升	judge 与专家判断偏离	暂停 judge 用于 gate, 重校准
Score distribution 突变	judge 或流量分布可能变化	检查 judge version、prompt、model route
False pass after incident	judge 没拦住真实事故	将事故样本加入 calibration set
Over-refusal trend	judge 过度惩罚合理回答	调整 rubric, 增加正例
Slice-specific drift	某语言、地区、产品线评分异常	增加 slice calibration

12. Evidence Binder: EvalOps 证据链

EvalOps 的成果必须能被 model risk、internal audit、compliance 和业务负责人复核。

12.1 Evidence Binder Index

证据类别	内容	责任方
E01 Use Case Evidence	use case card、risk tier、approved / prohibited use、workflow	AI PM、业务 owner
E02 Component Evidence	model、prompt、RAG、tool、judge、guardrail 版本快照	Platform owner、architect
E03 Dataset Evidence	dataset card、lineage、coverage、golden set approval	EvalOps、data owner、SME
E04 Evaluator Evidence	evaluator card、rubric、judge calibration、人审一致性	EvalOps、model risk
E05 Experiment Evidence	run id、baseline/candidate、scores、failures、trace samples	ML / platform team
E06 Gate Evidence	release memo、go/no-go、例外、审批、回滚计划	Release owner、risk owner
E07 Production Evidence	online eval、monitoring、sampling、feedback、alerts	Ops、EvalOps
E08 Incident Evidence	incident、RCA、impact analysis、remediation、retest	Incident manager、risk
E09 Change Evidence	change request、diff、approval、deployment、rollback	Change manager
E10 Portfolio Evidence	case study、architecture diagram、metric dashboard、decision story	AI PM / Architect

12.2 Evidence Quality 标准

每份证据必须回答:

证明哪个控制?
适用于哪个 use case、版本、环境和时间窗?
数据从哪里来, 是否可追溯?
谁生成、谁审核、谁批准?
是否能复现同一 eval run?
是否记录失败和例外, 而不只记录通过项?
是否能支持监管、审计或模型风险的追问?

12.3 证据保留与访问

设计点	要求
Retention	高风险 AI 证据按机构记录保留政策管理, 与客户影响和监管要求对齐
Access control	PII、case detail、prompt、tool trace、judge result 分级授权
Immutability	gate 决策后的 run report 和 dataset version 不可静默改写
Hash / snapshot	对关键 dataset、prompt、policy、index manifest 保留 hash 或快照
Legal hold	事故、投诉、监管问询相关证据可进入 legal hold
Export	支持按 use case、release、incident、quarterly review 导出 evidence pack

13. Ownership Model

EvalOps 平台跨产品、工程、风险、数据、运营。职责不清会让 eval 变成形式主义。

13.1 RACI

活动	AI PM	Architect	EvalOps	Data Owner	Business SME	Model Risk	Compliance	Ops
Use case scope	A	C	C	C	R	C	C	C
Risk tier	C	C	C	C	R	A	C	C
Eval contract	A	C	R	C	R	C	C	C
Dataset curation	C	C	R	A	R	C	C	I
Golden set approval	C	I	R	C	A	A	C	I
Evaluator design	C	C	R	I	C	A	C	I
Judge calibration	I	C	R	I	R	A	C	I
Experiment execution	C	R	R	I	C	C	I	I
Release gate	A	R	R	C	R	A	C	C
Production monitoring	C	C	R	C	C	C	I	A
Incident response	C	C	C	C	R	A	C	R
Evidence binder	A	C	R	C	C	A	C	C

R = Responsible, A = Accountable, C = Consulted, I = Informed.

13.2 团队拓扑

团队	主要职责
AI Platform	提供 model gateway、prompt registry、RAG services、tool gateway、trace infrastructure
EvalOps	运营 dataset、evaluator、runner、experiment comparison、gate evidence
Product / Use Case Team	定义业务目标、workflow、release scope、adoption、portfolio story
Business SME	标注、复核、定义严重失败、批准 golden set
Model Risk / Validation	独立挑战 eval 方法、阈值、代表性、监控和证据
Compliance / Legal	审核客户影响、监管边界、披露、保留和例外
Operations	生产监控、人审队列、事故响应、用户反馈闭环

14. 金融零售案例

14.1 AML Copilot

场景: 帮 AML 分析师汇总交易线索、客户资料、历史 case、red flag checklist, 草拟 investigation narrative。不得自动决定是否提交 SAR。

维度	EvalOps 设计
风险	高风险, 涉及 BSA/AML、客户资料、可疑活动判断
Offline eval	历史匿名 case、red flag coverage、evidence completeness、unsupported claim
RAG eval	是否召回正确交易、KYC、历史 alert、政策段落
Tool eval	case lookup、transaction query、entity graph query 参数正确性
Human eval	AML SME 对 narrative 的准确性、完整性、可审查性评分
Judge eval	初筛 groundedness、missing evidence、policy tone
Release gate	critical unsupported suspicion claim = 0; 不允许自动 SAR decision
Monitoring	每周抽检高风险 case, 跟踪 analyst override、case reopen、quality review
Evidence	case sample hash、eval report、SME review、release memo、incident log

关键失败:

编造交易事实。
把相似客户或相似商户混入当前 case。
把 red flag 当成确定违法结论。
未指出缺失证据。
绕过人工审查给出 SAR filing recommendation。

14.2 KYC Policy Assistant

场景: 员工询问客户开户、尽调、受益所有人、制裁筛查、文件要求。系统基于批准政策回答并引用来源。

维度	EvalOps 设计
风险	中到高, 取决于是否影响客户 onboarding 或账户限制
Golden set	高频政策、边界客户类型、地区差异、旧版政策干扰、无答案拒答
RAG gate	citation accuracy、current effective policy、permission correctness
Prompt gate	必须区分“政策要求”“操作建议”“需要升级合规”
Human review	KYC SME 校准高风险问答
Online eval	线上问题中 policy conflict、no-answer、low-confidence 抽样
Release gate	引用过期政策 = critical; 错误文件要求 = high
Evidence	policy index manifest、gold docs、citation support report

关键失败:

引用过期政策。
对地区或客户类型适用范围判断错误。
用 FAQ 替代正式政策。
对无覆盖问题编造答案。
向无权限角色显示敏感政策细节。

14.3 Payment Dispute Agent

场景: 支持支付争议处理, 读取交易、商户、规则、客户沟通记录, 推荐下一步和草拟回复。高风险动作需要人工批准。

维度	EvalOps 设计
风险	高, 可能影响客户资金、时限、合规通知和商户关系
Offline eval	历史争议案例 backtesting、规则适用、时限判断、证据缺口
Tool eval	dispute status update、refund recommendation、letter generation 的权限和参数
Deterministic check	日期、金额、case id、regulatory deadline、JSON schema
Human eval	争议专家审查 recommended next action
Release gate	未授权退款动作 = critical; 错误监管时限 = critical
Monitoring	action override、SLA breach、customer complaint、appeal outcome
Evidence	tool trace、human approval、case outcome、regression report

关键失败:

错误计算时限。
建议未授权退款或拒付。
将客户 A 的证据用于客户 B。
草拟误导性客户信。
没有升级复杂争议或异常金额。

14.4 Customer-Facing AI

场景: 面向客户的智能客服或金融产品助手, 回答账户、费用、产品、争议、投诉等问题。不得提供未经批准的财务建议或承诺。

维度	EvalOps 设计
风险	高, 因为客户可见、可被截图、可触发投诉和监管关注
Offline eval	高频问题、敏感问题、投诉语气、无答案、越权承诺、提示注入
Safety eval	PII leakage、jailbreak、policy bypass、financial advice boundary
Tone eval	清晰、克制、可执行, 不做无法兑现承诺
Online eval	实时抽样、bad feedback、handoff failure、sentiment spike
Human review	投诉、费用、争议、账户限制类问题进入人审或强制转人工
Release gate	错误客户承诺 = critical; 泄露敏感信息 = critical
Evidence	customer impact assessment、disclosure、monitoring dashboard、complaint linkage

关键失败:

承诺免除费用或保证争议成功。
生成不准确的账户状态。
对投诉使用不当语气。
无法识别需要人工介入的客户困境。
被 prompt injection 引导泄露内部政策。

15. 模板与 Artifact 示例

以下 artifact 用 AML Copilot 作为完整示例。真实项目可替换 use case、风险等级、数据集和阈值, 但不应删除 owner、lineage、gate、monitoring 和 evidence 字段。

15.1 Eval Contract 示例

# Eval Contract: AML Copilot Narrative Drafting

## Use Case
- use_case_id: AML-COPILOT-001
- workflow point: AML analyst reviews alert evidence and drafts investigation narrative
- user role: Tier 2 AML analyst
- risk tier: High
- customer impact: Indirect customer impact through suspicious activity investigation quality

## Expected AI Behavior
- must do: summarize evidence, cite transaction and KYC sources, identify missing information, separate facts from analyst judgment
- must not do: decide SAR filing, invent suspicious behavior, merge unrelated customer entities, expose unnecessary PII
- must escalate when: evidence is incomplete, entity match confidence is low, sanctions or law enforcement terms appear
- allowed tools: case_lookup, transaction_summary, kyc_profile_read, policy_retrieval
- prohibited tools: submit_sar, close_case, customer_notification

## Failure Modes
| Failure | Severity | Example | Detection method | Release impact |
|---|---|---|---|---|
| Unsupported critical claim | Critical | States "structuring is confirmed" without cited transaction pattern | judge + SME | no-go |
| Wrong citation | High | Cites KYC profile when the claim depends on transaction velocity | citation check + SME | no-go for high-risk slice |
| Bad tone | Medium | Uses accusatory language instead of investigation-neutral wording | judge + human sample | conditional |

## Evaluation Design
- dataset versions: AML-GOLDEN-2026Q2 v1.0, AML-REGRESSION-2026Q2 v1.1, AML-REDTEAM-2026Q2 v1.0
- evaluator versions: RULE-PII-v2, JUDGE-GROUNDEDNESS-v1.3, HUMAN-AML-RUBRIC-v1.0
- human review plan: 2 AML SMEs review all critical and 30% high-risk slice outputs
- judge calibration: monthly calibration against 80 human-labeled cases, false pass threshold below 3%
- deterministic checks: required citation IDs, no SAR decision phrase, no prohibited tool action

## Gate Thresholds
- critical failure: 0 tolerated
- high-risk slice: groundedness pass rate at least 97%, citation accuracy at least 95%
- regression set: 100% pass on prior incident cases
- red-team: 0 PII leakage and 0 prompt-injection-follow failures
- cost / latency: P95 under 9 seconds and cost per analyst-approved draft under approved budget

## Monitoring
- online sampling: 100% critical alerts, 25% high-risk alerts, 5% routine alerts
- alert thresholds: any critical failure, or high-risk slice score drops by 5 percentage points week over week
- human review queue: low-confidence summaries and all entity ambiguity cases
- incident trigger: unsupported suspicious activity conclusion enters case record

15.2 Golden Set Card 示例

# Golden Set Card: AML Copilot

## Identity
- dataset_id: AML-COPILOT-GOLDEN-2026Q2
- version: v1.0
- owner: AML Analytics Lead
- approved by: AML Operations SME + Model Risk VP
- effective date: 2026-06-29

## Purpose
- use cases: AML-COPILOT-001 narrative drafting and evidence summarization
- release gates: pilot, production release, quarterly review
- risk areas: unsupported claim, wrong entity merge, missing evidence, policy overreach, PII leakage

## Composition
| Slice | Count | Risk tier | Source | Reviewer |
|---|---:|---|---|---|
| Common cases | 60 | Medium | anonymized closed AML alerts | AML SME |
| Edge cases | 40 | High | entity ambiguity and incomplete KYC scenarios | AML SME + Data Steward |
| Historical failures | 30 | High | prior QA defects and reopened cases | AML Quality Lead |
| Red-team | 30 | High | prompt injection, PII minimization, prohibited SAR decision prompts | Security + Model Risk |

## Lineage and Controls
- source systems: AML case management, transaction monitoring warehouse, KYC profile store
- sampling method: stratified by alert type, risk score band, entity type, and QA outcome
- anonymization: customer identifiers tokenized, free-text notes redacted before evaluator access
- data classification: restricted internal, no export to unmanaged environments
- retention: aligned to AML evidence retention policy and model risk validation records
- contamination controls: reference labels excluded from prompts, few-shot examples, and training data

## Change History
| Version | Change | Reason | Approver |
|---|---|---|---|
| v1.0 | Initial approved set | Release gate baseline | SME + Model Risk |

15.3 Judge Calibration Report 示例

# Judge Calibration Report: AML Groundedness Judge

## Evaluator
- evaluator_id: JUDGE-AML-GROUNDEDNESS-v1.3
- judge model: approved enterprise judge model route
- judge prompt version: aml-groundedness-judge-prompt v1.3
- rubric version: aml-groundedness-rubric v1.0
- allowed use: offline screening, production sample triage, release gate supporting evidence

## Calibration Dataset
- dataset_id: AML-JUDGE-CALIBRATION-2026Q2
- sample count: 80
- high-risk slice count: 45
- human reviewer roles: AML SME, AML Quality Lead, Model Risk validator

## Results
| Metric | Result | Threshold | Decision |
|---|---:|---:|---|
| Human agreement | 91% | 88% | pass |
| False pass rate | 2.1% | 3.0% | pass |
| False fail rate | 6.4% | 8.0% | pass |
| Position bias check | 1.5 pp delta | 3.0 pp max | pass |
| Verbosity bias check | 2.4 pp delta | 4.0 pp max | pass |

## Decision
- approved for: release gate support and online triage
- prohibited for: sole approval of AML production release or SAR-related conclusion
- required compensating controls: SME review for all critical or disputed samples
- next review: 2026-09-30 or immediately after judge model route changes

15.4 Production Eval Runbook 示例

# Production Eval Runbook: AML Copilot

## Sampling
- risk-based sampling: 100% critical alerts, 25% high-risk alerts, 5% routine alerts
- excluded data: unredacted customer identifiers, privileged investigation notes, legal hold material without approval
- privacy controls: tokenization before eval queue, reviewer access by AML role, trace retention under evidence policy

## Daily Checks
- critical failures: unsupported SAR conclusion, wrong entity merge, PII leakage, prohibited tool action
- quality score trend: groundedness, citation accuracy, missing-evidence detection
- latency and cost: P95 generation latency and cost per analyst-approved draft
- feedback spike: bad-answer rate, analyst major rewrite rate, quality escalation count

## Weekly Review
- human review sample: 30 high-risk traces and all critical alerts
- new failure themes: stale KYC profile, entity ambiguity, unsupported typology inference
- dataset promotion candidates: confirmed failure traces with clear expected behavior
- open issues: unresolved high severity findings and conditional release obligations

## Incident Trigger
- immediate rollback: any AI-generated unsupported suspicious activity conclusion saved to case record
- limited disablement: citation accuracy below threshold for two consecutive business days
- increased HITL: entity match confidence below threshold or policy conflict detected
- risk notification: Model Risk and AML Operations notified within incident SLA

## Evidence
- dashboard: AML EvalOps production quality dashboard
- trace store: evidence-grade trace repository with run_id and component snapshot
- evidence binder: AML-COPILOT-001 release and monitoring binder
- issue tracker: AI risk issue log linked to remediation eval runs

15.5 Portfolio Case Study 示例

# EvalOps Portfolio Case Study: AML Copilot

## Business Context
- workflow: AML alert investigation and narrative drafting
- users: Tier 2 AML analysts and quality reviewers
- baseline pain: evidence gathering and narrative drafting consume significant analyst time and create QA rework
- AI role: summarize approved evidence, cite sources, identify missing information, draft neutral narrative

## Architecture
- component map: model gateway, prompt registry, AML RAG index, case lookup tool, groundedness judge, release gate workflow
- data flow: case data and transaction summaries are retrieved, redacted, assembled into context, scored, reviewed, and logged
- model / prompt / RAG / tool versions: component snapshot recorded per eval run and production trace
- monitoring design: online sampling, SME review queue, quality dashboard, judge drift calibration

## Eval Design
- eval contract: critical unsupported claim and prohibited SAR decision are hard blockers
- datasets: smoke, golden, regression, red-team, production sample
- evaluators: deterministic checks, groundedness judge, citation checker, AML SME rubric
- release gates: dataset readiness, evaluator readiness, pilot, production release, scale review
- production monitoring: risk-based sampling and feedback-to-regression loop

## Decision Story
- baseline: manual evidence review with inconsistent narrative quality and limited structured feedback
- candidate: RAG-backed narrative drafter with citations and missing-evidence detection
- trade-offs: higher latency accepted for high-risk cases to improve citation quality and audit traceability
- no-go or limited-go decisions: broad release blocked until entity ambiguity slice met threshold
- final release scope: limited pilot to trained Tier 2 analysts with mandatory human approval

## Evidence
- eval report: baseline vs candidate report with high-risk slice analysis
- gate memo: limited-go memo with conditions, owners, and rollback triggers
- monitoring screenshot: dashboard showing groundedness, citation accuracy, override rate, latency, cost
- incident or improvement loop: entity ambiguity failures promoted to regression set and retested

## Outcome
- quality: citation accuracy and missing-evidence detection tracked as primary quality measures
- risk: no automated SAR decision, no prohibited tool action, all critical findings routed to SME
- business metric: analyst drafting time and QA rework used as value measures
- lessons learned: eval quality improved most when production failures were rapidly converted into regression cases

16. 30-Day Lab: 从 0 到 1 搭一套 EvalOps 平台作品

目标: 选择一个金融零售 AI 用例, 在 30 天内产出可展示的 EvalOps architecture、eval contract、dataset card、experiment report、release gate memo、monitoring plan 和 interview story。

Day	任务	产出
1	选择用例: AML copilot、KYC assistant、payment dispute agent 或 customer-facing AI	Use case one-pager
2	画 AS-IS / TO-BE workflow, 标出 AI 插入点和人审点	Workflow map
3	定义 approved use / prohibited use / risk tier	Risk scope memo
4	写 Eval Contract v1	Eval contract
5	拆 failure modes: unsupported claim、wrong citation、tool misuse、under-escalation	Failure taxonomy
6	设计 dataset taxonomy: smoke、golden、regression、red-team、production sample	Dataset plan
7	写 Dataset Card 和样本 schema	Dataset card
8	构造 20 条 smoke cases, 覆盖核心流程	Smoke set
9	构造 30 条 high-risk golden cases	Golden set v1
10	构造 20 条 red-team / adversarial cases	Red-team set
11	设计 deterministic checks: format、PII、tool args、deadline、citation presence	Rule evaluator spec
12	设计 LLM judge rubric, 明确输入和评分	Judge evaluator card
13	设计 human review rubric 和 reviewer workflow	Human eval guide
14	制作 judge calibration set 和一致性记录模板	Calibration plan
15	设计 baseline / candidate 实验: prompt A/B 或 model comparison	Experiment plan
16	跑第一轮离线评估或模拟结果	Eval run report
17	做 slice analysis: 产品、语言、风险等级、失败类型	Slice report
18	写 regression decision: 哪些 blocker 必须修	Regression memo
19	设计 RAG lineage: source、version、index、chunk、permission	RAG lineage map
20	设计 tool eval: selection、argument、authorization、idempotency	Tool eval spec
21	写 Release Gate Memo v1	Gate memo
22	设计 production sampling 和在线评估	Production eval plan
23	设计 monitoring dashboard 指标	Dashboard wireframe
24	设计 judge drift 和 calibration cadence	Judge drift runbook
25	设计 evidence binder index	Evidence binder map
26	写 ownership RACI 和 operating model	RACI
27	做 architecture diagram 和 component map	EvalOps architecture
28	写 build vs buy ADR	Architecture decision record
29	整理 portfolio case study	Portfolio artifact
30	准备 5 个面试答案和 3 分钟讲述	Interview pack

17. 面试答案准备

Q1: 你如何解释 EvalOps 平台的价值?

30 秒版本: EvalOps 不是上线前测试, 而是 AI 系统的质量和风险控制面。它把 dataset、evaluator、experiment、release gate、production monitoring 和 evidence binder 连起来, 让每次 prompt、model、RAG、tool、judge 变更都能被比较、放行、监控和审计。

2 分钟版本: 我会从三个层次解释。第一, 工程层, EvalOps 让团队能对 prompt、model、RAG、tool 做可重复回归, 不靠主观体验判断质量。第二, 产品层, 它把“能不能上线”变成基于 critical failure、slice regression、成本、延迟和用户影响的决策。第三, 风险层, 它形成证据链: 数据集版本、评估器版本、运行结果、审批、例外、生产监控都可追溯。金融零售场景里, 这特别重要, 因为 AML、KYC、支付争议和客户可见 AI 都会触达监管、客户权益和审计。

Q2: Offline eval 和 online eval 如何分工?

30 秒版本: Offline eval 用于上线前比较和回归, online eval 用于上线后发现真实流量中的新失败。Online 发现的问题要回流到 offline dataset, 修复后再通过 gate。

2 分钟版本: Offline eval 面向 dataset, 可以有 reference answer、gold docs、expected behavior, 适合做模型迁移、prompt 改动、RAG 策略和 tool schema 的回归。Online eval 面向 production traces, 通常没有标准答案, 更适合监控 safety、grounding、format、feedback、异常趋势和真实分布变化。成熟做法是闭环: 线上 bad feedback、人工 override、事故样本进入 regression set 或 golden set, 然后用 offline eval 验证修复, 通过 release gate 后再上线。

Q3: 你如何治理 golden set?

30 秒版本: Golden set 是必须稳定通过的关键样本, 不是随手堆积的测试集。它需要 owner、版本、血缘、覆盖矩阵、审批、污染控制和定期复核。

2 分钟版本: 我会把 golden set 当成受控数据产品。进入 golden set 的样本必须有明确来源、风险标签、expected behavior、参考证据或专家标注。新增和删除 high-risk case 要有业务 SME 和风险 owner 审批。每次 release gate 锁定 dataset version, 避免边测试边改答案。还要防止 contamination, 也就是 golden answer 被放进 prompt、few-shot 或训练数据。政策失效、业务规则改变或样本不再代表生产时, 不能静默删除, 要归档并记录原因。

Q4: LLM-as-judge 可以用于 release gate 吗?

30 秒版本: 可以, 但不能无校准地单独决定高风险上线。Judge 必须有 evaluator card、rubric、human agreement、false pass / false fail、bias check 和 drift monitoring。

2 分钟版本: 我会把 judge 当成一个模型风险组件。它适合大规模初筛 groundedness、policy compliance、tone、safety, 但在 AML、KYC、支付和客户承诺这类场景, 最终 gate 需要 deterministic check 和专家复核共同支撑。特别要关注 false pass, 因为 judge 把坏输出判好会直接放大风险。每次 judge model 或 judge prompt 变化都要跑 calibration set, 上线后还要用人审抽样监控 judge drift。

Q5: 如何评估 RAG 系统不是只看答案准确?

30 秒版本: RAG 要分层评估: source readiness、retrieval recall、context precision、answer faithfulness、citation support、permission correctness 和 freshness。

2 分钟版本: 答案准确只是最后结果, 无法定位失败。金融政策类 RAG 必须先确认知识源是 approved source, 有 owner、版本、生效日期和权限。检索层看 gold chunk 是否被召回, context 层看最终放进 prompt 的资料是否相关、有效、权限正确。生成层看关键断言是否由 context 支撑, 引用是否真的支持结论。高风险场景里, “引用过期政策”或“无权 chunk 进入 context”应是 critical failure, 不是普通扣分项。

Q6: 模型升级时你会如何设计 release gate?

30 秒版本: 先冻结 baseline 和 candidate 的组件快照, 用同一 dataset 和 evaluator 比较整体、high-risk slice、regression set、red-team、成本和延迟。critical failure 为 0 是硬门槛。

2 分钟版本: 模型升级要避免只看总体 pass rate。我会先确定变更范围, 锁定 model、prompt、RAG index、tool schema、judge 版本。然后用 golden set、regression set、red-team set 和业务 slice 跑候选版本, 与生产 baseline 做比较。上线决策看 critical failure、high-risk slice regression、历史失败是否复发、human agreement、成本和 latency。即使总体提升, 只要客户可见承诺、PII 泄露、错误工具动作或 unsupported critical claim 出现, 就 no-go 或 limited release。

Q7: EvalOps 如何服务 Model Risk?

30 秒版本: EvalOps 为 Model Risk 提供可追溯的 validation 和 ongoing monitoring 证据: use case、组件版本、数据集、评估器、实验结果、门禁、例外、生产趋势和事故复测。

2 分钟版本: 传统模型风险关注开发、验证、上线、监控、变更和治理。GenAI 里风险对象扩展到 prompt、RAG、tool、judge 和 workflow。EvalOps 正好把这些对象登记和版本化, 每次变更都能形成 evaluation evidence。Model Risk 可以独立挑战数据集代表性、阈值合理性、judge 校准、生产监控覆盖和例外审批。这样 eval 不只是工程质量工具, 也成为模型风险管理和审计证据的一部分。

Q8: 客户可见 AI 的 EvalOps 和员工 copilot 有什么不同?

30 秒版本: 客户可见 AI 的风险更高, 因为输出会直接影响客户理解、投诉、承诺和监管观感。它需要更强的 safety、tone、disclosure、handoff、监控和 evidence。

2 分钟版本: 员工 copilot 通常有专业用户和内部流程兜底, 客户可见 AI 则直接面对非专业用户。评估时要增加错误客户承诺、误导性表述、投诉语气、敏感信息泄露、金融建议边界、人工转接失败等维度。Release gate 也更严格: 错误承诺、PII 泄露和越权建议应该是 critical failure。生产中要连接投诉、负反馈、人工转接、会话中断和质检结果, 形成持续监控。

18. 作品集表达

一个高级 EvalOps 作品集不应只展示 demo UI, 而要展示决策和证据。

Artifact	展示什么能力
EvalOps reference architecture	能设计平台控制面, 不只做单点工具
Eval contract	能把 AI 行为、失败、风险和门禁写清楚
Dataset card / golden set card	能治理评估数据和血缘
Evaluator card / judge calibration	能管理 LLM-as-judge 风险
Experiment comparison report	能做 prompt/model/RAG/tool 的决策比较
Release gate memo	能把评估结果转成 go / no-go / limited go
Production eval runbook	能设计上线后的监控、抽样、告警和回流
Evidence binder index	能支持审计、模型风险和监管问询
Financial retail case study	能结合 AML、KYC、支付、客服讲清楚业务风险

面试讲述结构:

1. 我选择了一个高风险金融零售 AI 用例。
2. 我没有从模型开始, 而是从 workflow、风险边界和失败代价开始。
3. 我把需求转成 eval contract, 把样本做成 golden/regression/red-team sets。
4. 我设计了 deterministic、人审和 LLM judge 的组合, 并校准 judge。
5. 我用 release gate 决定能否 pilot / release / scale。
6. 我把 production traces 回流到 dataset, 形成持续评估。
7. 我把每次运行、审批、例外和监控组织成 evidence binder。

19. 总结

EvalOps 平台的成熟度可以用一句话检验:

当一个 AI 系统的 model、prompt、RAG、tool 或 judge 发生变化时, 团队能否在同一天说清楚变更影响、跑出可复现评估、定位高风险回归、形成发布决策、上线后持续监控, 并在审计或事故中拿出完整证据链?

如果答案是肯定的, EvalOps 就不再是测试工具, 而是企业 AI 规模化的核心平台能力。