一、AI Engineer 频道的 Evals 核心内容地图

1. Domain-specific Evals：如何从业务错误开始

最重要的两场是：

• How to Construct Domain Specific LLM Evaluation Systems
• Lessons from the Trenches: Building LLM Evals That Work IRL
• The GenAI Maturity Curve or You Probably Don’t Need Fine Tuning
• How Zapier Builds AI Products and Features with the Help of Braintrust

这些视频共同强调：

不要先问“用什么指标”，而要先问“我们的系统到底会在哪些真实业务场景中失败”。

Hamel Husain 的方法尤其重要：找到真正懂业务的 Domain Expert，让其对真实输出做 Pass/Fail 判断并写 critique，再从这些人工判断中逐步构建自动化 LLM Judge。(youtube.com)

Hamel 与 Shreya 后续把这个过程总结为：

1. 找到主要领域专家；
2. 创建真实数据集；
3. 让专家做 Pass/Fail 和错误批注；
4. 先修复发现的问题；
5. 逐步构建 LLM Judge；
6. 对 Judge 做 error analysis；
7. 必要时拆成多个专门 Judge。(Hamel’s Blog)

---

2. 从 Playground 到 Production

主要视频包括：

• Mastering AI Evaluation: From Playground to Production
• Strategies for LLM Evals
• 7 Habits of Highly Effective Generative AI Evaluations
• Engineering Better Evals: Scalable LLM Evaluation Pipelines That Work
• Productionizing GenAI Models
• LLM Observability, Evaluation, Experimentation Platform

这里的核心是把 Evals 从一次性 Notebook 变成持续运行的工程系统：

开发实验
   ↓
离线 Dataset + Evaluators
   ↓
Prompt / Model / RAG / Agent 对比
   ↓
CI/CD Release Gate
   ↓
线上 Tracing 和 Monitoring
   ↓
真实失败案例回流 Dataset
   ↺

Braintrust 的 workshop 明确覆盖 offline eval、online eval、production logging、用户反馈和人工审核；可扩展 Eval pipeline 则强调把数据、实验、评分和生产 traces 连接起来。(youtube.com)

---

3. Product Evals：PM 和业务人员如何参与

主要视频包括：

• Shipping AI That Works: An Evaluation Framework for PMs
• The Importance of Evals
• 7 Habits of Highly Effective Generative AI Evaluations

这类视频强调，Evals 不是 Data Scientist 独自负责的模型评分，而是 AI 产品的 Executable Product Requirement：

• PM 定义用户成功；
• Domain Expert 定义业务正确；
• Engineer 把判断标准自动化；
• Security/Compliance 定义不可接受的行为；
• 业务 KPI 验证系统是否真的产生价值。

例如，一个客服 AI 的“答案看起来不错”没有意义。真正需要回答的是：

• 用户的问题是否解决；
• 是否引用了正确政策；
• 是否产生错误承诺；
• 是否应该转人工却没有转；
• 是否降低了处理时间；
• 是否增加了投诉或返工。

AI Engineer 的 PM Framework 演讲也明确将方法分为 human feedback、code-based checks 和 LLM-based evaluations，而不是只依赖主观 vibe check。(youtube.com)

---

4. LLM-as-a-Judge 与 Meta-Evaluation

主要视频包括：

• LLM as a Judge: Which Model Should You Use?
• Judge the Judge: Building LLM Evaluators That Actually Work
• How to Construct Domain Specific LLM Evaluation Systems

核心问题不是“LLM 能不能评分”，而是：

这个 Judge 与领域专家的判断是否足够一致？

因此，LLM Judge 本身也需要 Eval，也就是 Meta-Eval。

需要检查：

• Human–Judge agreement；
• False positive / false negative；
• 不同业务 slice 上的准确率；
• 长答案偏好；
• 位置偏差；
• 对自己生成答案的偏好；
• Judge 模型升级后是否漂移；
• Judge prompt 变化是否导致评分标准改变。

AI Engineer 的相关视频专门讨论 Judge model 的选择与 evaluator calibration；Anthropic 也建议先验证 LLM grader 的可靠性，再将其规模化使用。(youtube.com)

---

5. Agent Evals

主要视频包括：

• Building and Evaluating AI Agents
• Ensure AI Agents Work: Evaluation Frameworks for Scaling Success
• Taming Rogue AI Agents with Observability-Driven Evaluation
• Ship Real Agents: Hands-On Evals for Agentic Applications
• Architecting and Testing Controllable Agents

Agent 不能只评估最后一句回答，还要评估整个 trajectory：

用户目标
   ↓
Agent 制订计划
   ↓
选择工具
   ↓
生成工具参数
   ↓
读取工具结果
   ↓
更新状态 / Memory
   ↓
决定继续、重试、停止或转人工
   ↓
最终业务结果

必须同时评估：

• Final outcome 是否成功；
• 是否选择正确工具；
• 工具参数是否正确；
• 是否重复调用；
• 是否调用了不应该调用的工具；
• 是否正确处理工具错误；
• 是否破坏外部系统状态；
• 是否在合理步数、成本和时间内完成；
• 不确定时是否停止或升级给人工。

这些视频将 Agent reliability 与 tracing、trajectory inspection、tool evaluation 和 observability 放在一起，而不是只给最终回答打分。(youtube.com)

---

6. 2026 年的新方向：Evals 成为运行时基础设施

Why Eval++ Is the Next Great Compute Primitive 代表了一个更先进的方向：Eval 不只是部署前测试，而可能成为运行时的一部分，用于选择模型、选择 Agent 路径、验证中间结果、触发重试、决定是否升级给人工。(youtube.com)

但在公司早期阶段，不建议立即建设复杂的 runtime evaluator。应先把基础的 Dataset、Rubric、Tracing 和 CI gate 做好。

---

二、公司内部 LLM Evals Framework

我建议采用下面这套十一阶段 Framework。

Business Goal
     ↓
Success Criteria & Risk
     ↓
Tracing / Logging
     ↓
Production Error Analysis
     ↓
Eval Dataset + Slices
     ↓
Human Rubric / Gold Labels
     ↓
Code + Human + LLM Evaluators
     ↓
Offline Experiments
     ↓
CI/CD Release Gate
     ↓
Production Monitoring
     ↓
New Failures → Dataset

Step 1：定义“系统做什么”，而不是“模型有多好”

先写一份 Task Contract。

例如，公司内部 Warranty Claim Assistant：

给定 warranty claim、vehicle information、repair notes 和 warranty policy，系统需要提取关键字段、判断 coverage eligibility、给出支持证据，并在信息不足时转人工审核。

然后定义三个层次的成功标准。

层次	问题	Warranty Claim 示例
Business	是否产生业务价值	降低人工审核时间、减少错误付款
Product	用户任务是否完成	Reviewer 能否根据结果完成审批
System	每个组件是否正确	提取、检索、判断、引用、工具调用

Anthropic 的建议也是先定义 specific、measurable、relevant 的 success criteria，并同时考虑质量、隐私、延迟和成本，而不是只看一个总分。(Claude Platform Docs)

---

Step 2：建立 Risk Registry

把错误按业务后果分级。

Severity	定义	示例
Critical	法律、安全、重大财务风险	错误自动批准高金额 claim
High	明显业务损失或客户伤害	引用了错误 warranty policy
Medium	需要人工返工	漏掉 repair date
Low	风格和体验问题	回答过长、格式不理想

Critical failure 不能被平均分掩盖。

一个系统可能有 97% 总体准确率，但如果剩下 3% 都是错误付款，它仍然不能上线。

---

Step 3：先做完整 Tracing

每次 LLM 请求至少记录：

trace_id
timestamp
user/task type
input
system prompt version
model and model parameters
retrieved documents
retrieval scores
tool calls and arguments
tool results
final output
latency
token usage
cost
user feedback
human correction
application version

没有 trace，就只能知道“答案错了”，却不知道是：

• Retrieval 错了；
• Prompt 错了；
• Tool 返回错了；
• Context 太长；
• Model 理解错了；
• Business rule 本身定义不清。

传统测试难以处理 LLM 的非确定性、模型升级和局部改进造成的回归；完整 trace 是构建 Eval dataset 和定位失败的基础。(Braintrust)

---

Step 4：建立 Seed Dataset

不要一开始生成一万个 synthetic examples。

先收集大约 50–200 个高质量真实案例，覆盖：

• 高频普通案例；
• 已知失败案例；
• 边界案例；
• 高风险案例；
• 信息缺失案例；
• 相互矛盾案例；
• 不应该回答的案例；
• 安全和 prompt-injection 案例。

Warranty Claim 可以建立这些 slices：

valid_standard_claim
out_of_warranty
missing_purchase_date
conflicting_vehicle_information
policy_exception
high_value_claim
duplicate_claim
unsupported_repair
ambiguous_policy
prompt_injection_in_attachment
pii_exposure
human_escalation_required

每个 Eval case 应至少包含：

{
  "case_id": "WC-00125",
  "source": "production_anonymized",
  "input": {},
  "expected_behavior": {},
  "gold_answer": null,
  "slice_tags": [
    "policy_exception",
    "high_value_claim"
  ],
  "severity": "critical",
  "rubric_version": "v1.2",
  "reviewer": "warranty_sme",
  "notes": "Must escalate rather than auto-approve"
}

---

Step 5：由 Domain Expert 建立 Rubric

不要让 AI Engineer 自己猜测“业务正确”是什么。

请 Warranty SME 对案例回答：

1. 这个结果 Pass 还是 Fail？
2. 为什么？
3. 错误属于什么类别？
4. 正确行为是什么？
5. 这个错误有多严重？

最好先使用二元判断：

PASS
FAIL
NOT_APPLICABLE
UNCERTAIN

而不是一开始使用模糊的 1–5 分。

例如：

Criterion: Coverage Decision Correctness

PASS:
The coverage decision matches the warranty policy,
vehicle dates, repair type and applicable exclusions.

FAIL:
The decision contradicts any applicable warranty rule,
ignores an exclusion, or makes a decision when required
information is missing.

UNCERTAIN:
The policy itself is ambiguous and requires a warranty
specialist.

Hamel 的方法尤其强调 Pass/Fail 加 critique，因为 critique 后续可以直接用于修复系统和训练 Judge。(Hamel’s Blog)

---

Step 6：建设分层 Evaluators

不要试图用一个“overall quality judge”解决所有问题。

Layer 0：Deterministic Checks

优先使用代码。

JSON schema valid
required fields present
date format valid
claim amount within range
citation IDs exist
tool name allowed
tool arguments valid
PII pattern detection

代码评分通常最快、最稳定、最便宜；复杂语义判断才交给人工或 LLM。(Claude Platform Docs)

Layer 1：Task Accuracy

field extraction correctness
claim classification correctness
coverage decision correctness
calculation correctness

Layer 2：Grounding

answer supported by retrieved documents
citation points to correct policy section
no unsupported factual claims

Layer 3：Policy and Safety

does not expose PII
does not follow prompt injection
does not approve without required evidence
escalates high-risk uncertainty

Layer 4：Process / Agent Trajectory

correct tool selected
correct arguments supplied
correct number of calls
proper retry behavior
no unauthorized side effects

Layer 5：Operational Metrics

latency
token usage
cost
failure rate
timeout rate

Layer 6：Business Outcome

manual overturn rate
review time saved
claim leakage
false approval rate
false rejection rate
human escalation rate
user adoption

---

Step 7：构建并校准 LLM Judge

Judge Prompt 应输出结构化结果：

{
  "label": "FAIL",
  "failure_category": "unsupported_coverage_decision",
  "severity": "critical",
  "evidence": [
    "Policy section 4.2 excludes this repair type"
  ],
  "critique": "The assistant approved the claim despite an explicit exclusion.",
  "confidence": 0.94
}

校准过程：

1. 准备 Domain Expert 已标注的数据；
2. 隐藏人工标签；
3. 让 Judge 独立评分；
4. 计算 Human–Judge agreement；
5. 查看 confusion matrix；
6. 对 Judge 的 false positive 和 false negative 做 error analysis；
7. 修改 rubric 或 Judge prompt；
8. 重新测试；
9. 达到可接受一致性后才扩大使用。

高风险案例建议双重检查：

LLM Judge
    ↓
低置信度或 Critical
    ↓
Human Review Queue

Judge 的版本、模型、prompt 和 threshold 也必须被版本管理。

---

Step 8：建立标准 Experiment Protocol

每一次 Prompt、Model、RAG 或 Agent 变更都要运行同一套实验。

Baseline configuration
vs.
Candidate configuration

同时比较：

维度	示例
Quality	Coverage correctness
Safety	Critical error count
Grounding	Citation support
Reliability	多次运行一致性
Cost	每个 claim 的平均成本
Latency	p50 / p95
Slices	每种 claim 类型的表现

对于有随机性的任务，单个案例可以重复运行 3–5 次，以检查稳定性，而不是只运行一次。

必须看 slice-level results：

Overall accuracy: 94%
Standard claims: 98%
Policy exceptions: 71%
High-value claims: 76%

仅看总体 94% 会隐藏最危险的问题。

---

Step 9：把 Evals 接入 CI/CD

每个 Pull Request 或 Release Candidate 自动运行：

Unit Eval Suite
Regression Eval Suite
Critical Safety Suite
RAG Eval Suite
Agent Tool-Use Suite
Cost and Latency Benchmark

示例 Release Gate，以下阈值仅作为示意：

Critical auto-approval errors = 0
JSON schema validity = 100%
Coverage decision agreement >= 95%
Citation support >= 98%
No important slice regresses by more than 2 percentage points
p95 latency <= 8 seconds
Average cost <= approved budget

Release Gate 不应只使用总平均分：

release = (
    critical_errors == 0
    and overall_score >= minimum_score
    and all_critical_slices_pass
    and latency_p95 <= latency_limit
    and average_cost <= cost_limit
)

OpenAI 官方也把 Eval 流程概括为描述任务、运行测试输入、分析结果并迭代，类似 behavior-driven development。(OpenAI Developers)

---

Step 10：建立 Online Evals

离线 Dataset 永远不能完全代表生产流量。

线上需要：

100% deterministic safety checks
100% schema and tool validation
100% latency / error / cost monitoring
5–20% semantic quality sampling
100% explicit negative feedback review
100% critical action audit

生产 traces 可以通过以下方式抽样：

• 随机抽样；
• 低置信度；
• 用户点踩；
• 高金额业务；
• 多次 tool retry；
• 异常高 token usage；
• 新用户 intent；
• Judge disagreement；
• 新模型发布后的 canary traffic。

Online Eval 发现的新失败案例，要回流到 Regression Dataset：

Production failure
     ↓
Human review
     ↓
Failure taxonomy
     ↓
Add regression case
     ↓
Fix system
     ↓
CI prevents recurrence

---

Step 11：建立组织和治理机制

推荐职责划分

角色	主要责任
Product Manager	业务目标、用户成功和上线标准
Domain Expert	Rubric、Gold Labels、关键错误定义
AI Engineer	Eval runner、Judge、Prompt/RAG/Agent 实验
Data Engineer	Dataset pipeline、数据质量、匿名化
Platform/MLOps	Tracing、CI/CD、Dashboard、权限
Security/Legal	Safety、隐私、合规、红队测试
Business Owner	风险接受和最终上线审批

推荐节奏

Every PR:
运行 regression evals

Every week:
Review 新失败案例和 Judge disagreement

Every month:
刷新 production dataset 和 slices

Every quarter:
Red-team、policy review、threshold review

Every model upgrade:
完整 baseline comparison 和 canary release

三、Warranty Claim 项目的完整 Eval Scorecard

Category	Evaluator	Metric
Extraction	Code / labeled data	Field accuracy/F1
Classification	Exact match	Claim type accuracy
Coverage	SME-calibrated Judge	Pass/fail agreement
Calculation	Code	Dollar amount accuracy
Retrieval	Labeled relevance	Relevant policy recall
Grounding	LLM Judge	Supported claim rate
Citation	Code + Judge	Correct citation rate
Safety	Rules + adversarial set	Critical violation count
Uncertainty	Human/Judge	Correct escalation rate
Tool use	Trace evaluator	Tool/argument correctness
Reliability	Repeated runs	Consistency
Operations	Telemetry	Cost and p95 latency
Business	Production data	Overturn rate and cycle time

最终不要生成一个简单的：

Overall Eval Score = 87

更合理的是生成 Quality Profile：

Coverage correctness       96%
Citation support           98%
Correct human escalation   91%
High-value claims          88%
Policy exceptions          82%
Critical safety failures   0
Average cost               $0.08
p95 latency                6.4 sec

这能让团队知道下一步究竟应该改 Prompt、RAG、business rules、tools，还是模型。

四、90 天落地路线

第 1–30 天：Minimum Viable Eval System

完成：

• Task Contract；
• Success Criteria；
• Tracing；
• 第一版 Failure Taxonomy；
• 100 个真实案例；
• Domain Expert Rubric；
• JSON/schema/code checks；
• 人工 baseline evaluation。

产出物：

eval_dataset_v1
rubric_v1
failure_taxonomy_v1
baseline_report

第 31–60 天：自动化和 CI

完成：

• LLM Judge；
• Human–Judge calibration；
• Prompt/model experiment runner；
• Regression suite；
• CI release gate；
• Slice dashboard；
• Cost/latency comparison。

第 61–90 天：生产闭环

完成：

• Online trace sampling；
• Feedback ingestion；
• Human review queue；
• Canary/A-B testing；
• Agent trajectory eval；
• Security red-team dataset；
• Monthly Eval Review Meeting；
• Governance 和 ownership 文档。

五、最常见的失败方式

1. 从工具开始，而不是从业务失败开始。
2. 直接使用通用 hallucination、relevance 指标，却没有定义自己的业务正确性。
3. 完全依赖 synthetic data，没有真实生产样本。
4. 让 LLM Judge 评分，却从未和 Domain Expert 对齐。
5. 只评估最终回答，不评估 retrieval、tools 和 agent trajectory。
6. 只看平均分，不看高风险 slices。
7. Prompt、Dataset、Rubric、Judge 和 Model 没有版本管理。
8. 把 monitoring 当成 eval，或者只做离线 eval 而没有生产回流。
9. 系统已经针对固定测试集过度优化，却没有持续加入新失败案例。
10. 把 Evals 当成上线前的一次 QA，而不是整个 AI SDLC 的核心循环。

六、工具选择原则

Framework 应保持 vendor-neutral：

Tracing layer
Dataset layer
Annotation layer
Evaluator layer
Experiment runner
CI/CD gate
Production monitoring
Review dashboard

可以购买统一平台，也可以使用 Python、pytest、数据库和内部 Dashboard 自建。关键是 Dataset、Rubric 和 Evaluator 必须能够导出和版本管理，避免被某个平台锁死。

尤其不建议现在把整个内部 Framework 绑定在旧的 OpenAI Evals Platform 上：OpenAI 当前文档显示，该平台计划在 2026 年 10 月 31 日变为只读，并于 2026 年 11 月 30 日关闭，官方建议新用户考虑 Datasets 等新流程。(OpenAI Developers)

---

最终可以把整个公司级 Framework 浓缩成一句话：

用真实业务失败定义测试数据，由领域专家定义正确性，用代码和经过校准的 LLM Judges 自动评分，把结果接入 CI/CD 和生产 tracing，并持续将新的线上失败回流为 regression tests。

下一步最实用的是把你们当前一个具体项目，例如 Warranty Claim Assistant、内部 RAG Chatbot 或 Extraction Workflow，套入这套结构，形成第一版 Dataset Schema、Failure Taxonomy、Rubric、Judge Prompt 和 Release Gate。