10. 项目与练习

本章提供四条端到端项目路线，帮助你把教程内容转成自己的 eval 能力。

项目总要求

任选一个项目完成。每个项目都应交付：

• 一份任务定义文档。
• 至少 30 条 eval cases。
• 至少 3 个 deterministic assertions 或 state verifiers。
• 至少 1 个校准过的 binary LLM judge。
• 一份错误分析报告。
• 一份 eval run 报告。
• 一个 CI 或本地回归命令。

本章导读

前面的章节讲了许多概念，但 eval 能力不是靠读概念建立的。它更像写作、调试或产品判断：必须在一个具体系统里做过，才会真正明白哪些标准容易写、哪些样本难找、哪些 judge 看起来聪明但并不可靠，哪些失败一开始被低估，后来才发现是上线风险。

这一章的项目设计，是为了让你经历一次完整闭环。你不需要做一个很大的平台，也不需要一次覆盖所有风险；你需要的是把一个真实或半真实的 AI 功能拿到手里，从 trace 开始，写出 failure taxonomy，再把其中几类失败转成 scorer，最后用一份报告说明系统现在到底好在哪里、差在哪里、下一步应该修什么。

如果你能完成其中一个项目，你掌握的就不再是“eval 的知识点”，而是一种可以迁移的工作方式。以后无论面对 RAG、客服 agent、coding agent、游戏 NPC，还是更复杂的 RL 环境，你都知道该先看什么、该问什么、该如何把模糊质量变成可执行的改进。

项目 A：角色扮演 / NPC Agent Eval

场景

你有一个角色扮演或游戏 NPC agent，需要保持人设、记忆、剧情边界和安全性。

这个项目适合练“语义质量如何落到可评估标准”。NPC 的失败常常不是简单对错，而是慢慢偏离：说话风格变现代、忘记玩家已经完成的任务、把系统外知识带进世界观，或者在玩家诱导下泄露设定外信息。做这个项目，你会学到如何把人设、记忆和剧情边界拆成可检查的事实、状态和 judge 标准。

要评估的能力

Dataset 设计

至少包含：

• 10 条单轮人设边界 case。
• 10 条多轮记忆 case。
• 5 条安全/越界 case。
• 5 条剧情状态 case。

示例 case：

id: npc_memory_001
task: "多轮记忆一致性"
initial_state:
  player_name: "林岚"
  completed_quests: ["找回银钥匙"]
conversation:
  - user: "你还记得我刚才帮你做了什么吗？"
expected:
  must_mention: ["银钥匙"]
  must_not_claim: ["还没有完成", "第一次见"]
scorers:
  - memory_fact_assertion
  - persona_consistency_judge

Scorer 建议

• Deterministic：必须提及/不得提及的事实、禁止短语、状态字段一致。
• Judge：人设是否一致、回复是否自然、是否越界。
• State verifier：任务状态和记忆状态是否按剧情更新。

进阶

• 设计 pass^5，测试同一角色在不同采样下是否稳定。
• 加入 prompt injection：玩家要求 NPC 忘记世界观或泄露系统提示。
• 加入长轮 context rot 测试。

项目 B：Coding Agent Eval

场景

你有一个 coding agent，可以读取 repo、修改文件、运行测试、提交补丁。

这个项目适合练 verifier 和工程回归。coding agent 的好处是 outcome 相对可验证：测试是否通过、类型检查是否通过、diff 是否越界、是否破坏旧功能。它也能让你直观看到“只看最终回答”有多危险。一个 agent 可以写出很自信的修复说明，但补丁没有通过测试；也可以让目标测试通过，却做了无关重构或硬编码。

要评估的能力

Dataset 设计

至少包含：

• 10 个小 bug fix。
• 5 个测试补充任务。
• 5 个文档/类型错误任务。
• 5 个需要多文件理解的任务。
• 5 个安全边界任务。

示例 case：

id: code_bug_001
repo_snapshot: "fixtures/repo-v1"
issue: "修复用户为空时 profile page 崩溃"
expected:
  fail_to_pass:
    - "tests/test_profile.py::test_empty_user"
  pass_to_pass:
    - "tests/test_profile.py::test_existing_user"
constraints:
  must_not_modify:
    - "migrations/"
scorers:
  - pytest_fail_to_pass
  - pytest_pass_to_pass
  - no_unrelated_diff

Scorer 建议

• Verifier：运行测试、lint、typecheck。
• Diff check：限制无关文件、补丁大小。
• Trajectory check：是否运行相关测试，是否查看失败。
• Judge：PR 说明是否准确，是否过度重构。

进阶

• 加 runtime shift：不同依赖版本、低内存、网络不可用。
• 加 exploit check：测试是否可被硬编码绕过。
• 报告 cost per resolved issue。

项目 C：RAG 问答 Eval

场景

你有一个基于内部文档、知识库、合同、政策或代码文档的 RAG 问答系统，需要评估它是否能检索到正确证据，并基于证据回答。

这个项目适合练“把管道拆开评估”。RAG 的失败经常被误称为“幻觉”，但根因可能完全不同：检索没有拿到相关上下文，拿到了上下文但回答没有使用，回答忠实于上下文却没回应用户限定条件，或者上下文本身不足以回答问题。完成这个项目后，你应该能把“RAG 答错了”拆成可修复的检索、生成、引用和拒答问题。

要评估的能力

Dataset 设计

至少包含：

• 10 条常见明确问题。
• 5 条上下文不足、必须拒答或追问的问题。
• 5 条相似政策容易混淆的问题。
• 5 条需要多个文档合成的问题。
• 5 条对抗或诱导编造的问题。

示例 case：

id: rag_policy_001
question: "上海出差酒店超预算时还能报销吗？"
retrieval_fixture:
  corpus_version: "policy-docs-2026-06"
expected:
  must_retrieve:
    - "travel-policy-hotel-limit"
  must_answer:
    - "需要业务说明"
    - "需要审批"
  must_not_claim:
    - "可以直接提交"
scorers:
  - context_relevance_c_given_q
  - faithfulness_a_given_c
  - answer_relevance_a_given_q
  - citation_support_check

Scorer 建议

• Deterministic：引用 ID 是否存在、答案是否包含必须字段、是否拒答不可回答问题。
• Retriever metrics：recall@k、context relevance、重复 chunk 比例。
• Judge：faithfulness、answer relevance、support coverage。
• Human review：高风险政策、法律、财务、医疗类答案。

进阶

• 按文档版本做 time-window eval，测试政策更新后是否仍然正确。
• 加入 query rewrite，对比重写前后的 C|Q 与 A|C。
• 对同一问题生成 paraphrases，测试检索稳定性和 answer consistency。

项目 D：AI 原生产品上线 Eval

场景

你有一个面向用户的 AI 功能，例如客服、销售助手、RAG 问答、文档助手或工作流 agent。

这个项目最接近真实产品工作。它要求你从 trace 出发，而不是从指标出发；从用户目标和业务风险出发，而不是从模型能力榜单出发。你会经历完整闭环：抽样、错误分析、failure taxonomy、scorer 设计、judge 校准、上线 gate 和线上回流。完成它之后，你应该能把“这个 AI 功能感觉还可以”改写成“它在哪些场景达标，哪些场景不能上线，下一轮应该修什么”。

要评估的能力

10 天实施路线

示例 failure taxonomy

上线 gate 示例

必须满足：
- high-risk regression cases: 100% pass
- state verifier pass rate >= 95%
- groundedness judge TPR >= 0.90, TNR >= 0.90
- p95 latency <= 8s
- cost per successful task <= target
- 人工审计最近 50 条线上样本无 P0/P1 失败

通用练习题

概念题

1. 为什么 eval 不是 benchmark 的同义词？
2. 为什么 agent eval 要记录 trace？
3. output 与 outcome 的差别是什么？
4. 为什么 pass@k 不适合作为客服 agent 的唯一可靠性指标？
5. 为什么 judge agreement 高不代表 judge 可靠？

设计题

1. 为一个 RAG 问答系统设计 5 个 failure modes。
2. 为一个退款 agent 写 3 个 state checks。
3. 为一个多轮 agent 写一个 pass^3 eval 计划。
4. 设计一个 synthetic eval data generation pipeline，并说明如何验证样本真的触发目标场景。
5. 设计一个 benchmark contamination screen。

审计题

1. 找一个你正在使用的 LLM judge，写出它最可能的 3 个偏差。
2. 找一个自动 grader，设计一个可能 exploit 它的策略。
3. 找一个公开 leaderboard，分析它是否有 predictive validity 证据。
4. 找一个 regression set，检查是否被平均分掩盖了高风险 case。
5. 找一个 agent runtime，列出训练/评测/生产环境差异。

项目评分 Rubric

作品集表达模板

完成项目后，可以把能力表达写成：

我为一个 [产品/agent] 设计并实现了端到端 eval 系统：
- 从 [N] 条真实 trace 做错误分析，聚类出 [K] 类失败模式；
- 构建了 [N] 条 golden/regression cases；
- 实现了 [X] 个 deterministic/state verifiers 和 [Y] 个 binary LLM judges；
- 用 [N] 条人工标签校准 judge，例如 TPR=0.91, TNR=0.94；
- 将高风险 regression eval 接入 CI，并建立线上抽样复盘流程；
- 通过 eval 指导修复后，[关键指标] 从 [基线值] 提升到 [新值]。

这个表达比“熟悉 LLM eval”更有说服力，因为它有数据、方法、指标和工程闭环。