ep28 · Agent 评测 · Contextual Retrieval（进阶收官）

• 模块：M5 工程可行性
• 课节：4 节
• 配套音频：pm28-m5-播客.mp3（时长见集页）
• 配套字幕：pm28-m5-播客.srt
• 来源：xueai.miyang.cn（小山学堂 · 洛小山《学 AI 产品，从入门到精通》）

本集改编自小山学堂《学 AI 产品，从入门到精通》，音频为二次演绎配音版。音频讲主线与判断，文字稿给结构、清单和可复用的评测模板。

---

一、本集解决什么问题

没有评测的 Agent 开发，就像蒙眼开飞机。你修了用户 A 反馈的问题，却可能悄悄破坏了用户 B、C、D 依赖的功能——更糟的是你根本不知道自己破坏了什么，直到下一波投诉涌来。

对产品经理而言，评测的第一个价值不是测试，而是逼团队定义成功长什么样。当你写不出一条评测用例，往往说明你对这个任务的理解还不够清晰。写用例的过程会逼你回答最难的产品问题：用户到底想要什么结果？什么算好，什么算不好？边界情况怎么处理？很多团队是在写评测的过程中，才理清了长期模糊的产品定义。

评测的价值是复利的。最好的开始时间是三个月前，次好的是现在。

---

二、能力地图

层次	关键概念	它在回答什么	你该追问的问题
术语层	Task / Trial / Grader / Transcript / Outcome / Harness / Suite	评测体系的语言	团队对这七个词的理解是否一致
价值层	定义成功 → 回归验证 → 快速迁移	为什么值得投入	我们处在哪个阶段
裁判层	代码 / 模型 / 人工三种 Grader	谁来判断对错	三类是否都用了，Rubric 写到每一分了吗
陷阱层	噪音、作弊（Eval Awareness）、退化	评测为什么不可信	环境标准化了吗，用例还有效吗
检索层	Contextual Retrieval 三层递进	怎么让 RAG 更准	分块是否自带上下文

读法两条。第一，越往上越是「产品问题」而非「工程问题」：术语层统一语言，价值层定义成功，这两层本就该由产品主导。第二，陷阱层是长期维护项：评测不是一劳永逸的，它需要和模型一起进化。

---

三、五个概念逐个拆开

1. 七个术语与三个价值阶段

术语	含义
Task（任务）	一个测试用例：输入（给 Agent 的指令）+ 成功标准（怎样算完成）
Trial（试验）	同一 Task 的一次执行尝试。因输出有随机性，需跑多次才有统计意义
Grader（评判器）	打分逻辑：代码规则 / LLM 评审 / 人工。决定一次 Trial 通过或失败
Transcript（记录）	完整执行轨迹：每步推理、每次工具调用、每个中间结果
Outcome（结果）	环境中的最终状态——不只看它说了什么，更看它实际做了什么
Harness（脚手架）	运行评测的基础设施：创建沙箱、启动 Agent、收集结果、调用 Grader
Suite（套件）	一组相关 Task 的集合，如「文件编辑能力 Suite」含 20 个不同难度任务

三个价值阶段：

阶段	价值
早期	迫使团队定义成功长什么样，测试反而是其次
中期	回归测试（防止优化一个维度破坏另一维度）+ 变更验证（每次决策有数据支撑）
后期	新模型发布时几天内完成迁移；无评测的团队需数周甚至数月手动验证

从哪开始：先从 20 条开始。20 条精心设计的 Task 就能覆盖核心场景。有 20 条 eval 的团队，比有 0 条但「计划做 500 条」的团队领先一整个时代。

2. 三种 Grader

	代码 Grader	模型 Grader（LLM-as-Judge）	人工 Grader
方法	字符串匹配、正则、AST、单元测试、工具调用验证	将输出与 Rubric 交给评委 LLM 打分	领域专家直接评判
优点	毫秒级、成本近零、客观可复现、适合 CI/CD	能评主观质量、理解意图、灵活	质量最高、能发现盲区、有深度洞察
缺点	对合理变体过严、缺乏语义理解、无法评主观质量	有成本、可能有偏见、需精心设计 Rubric、不完全可复现	不可扩展、慢（小时~天级）、贵、评判者间有分歧
适用	有明确正确答案：编译、返回值、格式、计算	开放式：报告质量、代码风格、对话自然度、摘要质量	初期校准、模型 Grader 盲点、高风险场景（医疗/法律/金融）

核心逻辑（三层递进）：代码 Grader 保证底线（不出大错）→ 模型 Grader 提升上限（产出质量）→ 人工 Grader 校准裁判（保证公正）。三者缺一不可。

3. Rubric 要具体到每一分

模糊标准「给输出质量打 0–1 分」几乎没用。好的 Rubric：

分数	标准
0 分	完全没有回答问题，或包含严重事实错误
0.3 分	回答了问题但遗漏关键信息
0.7 分	回答完整准确，但组织混乱或有冗余
1 分	完整、准确、简洁、结构清晰

混合策略推荐流程：代码 Grader 打底（确定性场景）→ 模型 Grader 扩展（主观场景，Rubric 是关键）→ 人工定期校准（抽检模型 Grader 是否漂移）。

两个真实案例：

产品	评测设计
Descript（视频编辑 Agent）	三维度独立打分：不破坏（编辑后视频无损）/ 做了该做的（指令被正确执行）/ 做得好（剪辑质量专业）
Bolt AI（代码生成 Agent）	静态分析（能否编译、lint）+ 浏览器 Agent 自动打开页面验证 UI + LLM Judge 评判代码质量与可读性

共同点：都不是单一维度评分，而是拆成若干可独立观测的维度——指标变化时能立刻定位是哪一环出问题，而不是只知道总分掉了。

4. 评测的三个坑

① 基础设施噪音（可达 6 个百分点）

同一个模型、同一个任务，仅改变 CPU / 内存限制，分数差异可达 6pp，甚至出现排名逆转。

• 后果：评测里 95 分，线上可能只有 89 分；你以为模型 A 更好，其实只是它在你的沙箱配置下跑得更顺
• 基础设施配置本身就是考题的一部分
• 对策：像控制实验条件一样控制评测环境；每次报告结果时同时报告基础设施配置（CPU、内存、网络、沙箱类型）。环境变了，分数不可比

② 模型识别考试（Eval Awareness）

前沿模型在联网检索评测中能推测出自己正在跑 benchmark，识别题目模式后尝试搜索答案或利用训练数据中的类似题目。这算不上作弊，而是泛化能力在评测场景下的副作用。

• 核心问题：静态 benchmark + 联网环境 = 评测结果不再可靠
• 模型越强，识别评测的能力越高，固定题目集的区分力在衰减
• 启示：用动态生成的测试用例、限制联网、或用真实业务场景替代公开 benchmark

③ 改 Prompt 导致退化

事故	起因	结果
啰嗦修复（2026.4 事后分析）	用户反馈输出太啰嗦，修改 system prompt 减少冗余	简洁性提升，但 coding eval 掉了约 3%——变简洁的同时省略了关键注释与错误处理
Reasoning Effort 默认值变更	调整一个看似无害的配置参数	多个 eval 维度同时退化——思考深度被无意削弱，复杂任务质量下降

三条防护建议：

1. 每次变更跑完整 Suite —— 改 Prompt、换模型、调参数、改基础设施都一样；只测涉及维度远远不够
2. 评测环境标准化 —— 固定 CPU、内存、沙箱类型、网络条件
3. 动态更新评测 —— 更新用例、增加新维度、淘汰已被模型记住的旧题

补充做法：提示词变更做逐行消融——每次只改一行并测量影响，而不是一次改一大段。

更上层的教训：评测系统本身也需要被评测。 持续审视三件事——我的评测环境可靠吗？我的用例还有区分力吗？我的变更流程够严谨吗？

5. Contextual Retrieval：更好的 RAG

传统 RAG 的致命缺陷：切 Chunk 的过程本身就会丢失关键信息。

案例："The company's Q2 revenue increased by 3% over the previous quarter." —— 哪个公司？哪一年？Q1 基准是多少？增长在行业中算好还是差？全部在切块时丢失了。

核心思路：在做 Embedding 之前，先用 LLM 阅读整篇文档，为每个 Chunk 生成一段简短的上下文描述作为前缀。

	内容
BEFORE（裸 Chunk）	"公司 Q2 营收环比增长 3%" —— 谁？什么时候？无从得知
AFTER（带上下文）	"本块来自公司 2024 年报的财务表现章节。公司 Q2 营收环比增长 3%" —— 来源、时间、章节自动补齐

三层递进：

层	做法	作用
L1 · Contextual Embeddings	加前缀后再向量化	Chunk 自带语境，语义匹配更精准
L2 · Contextual BM25	关键词检索也加前缀	前缀中的公司名、年份让 BM25 命中原本漏掉的 Chunk；双路召回互补盲区
L3 · Reranking	用 Reranker 对候选重排序	更精确判断相关性，把最相关的排到前面

效果：三层叠加，检索失败率降低约 67%。假设之前每 100 次检索有 30 次找不到正确 Chunk（失败率 30%），优化后降到约 10%。

成本权衡：

• 每个 Chunk 需一次额外 LLM 调用生成前缀，大规模文档库预处理成本不可忽视
• 可用 Prompt Caching 降低（同一文档的不同 Chunk 共享文档级上下文）
• 适合高准确率场景：法律文档检索、医疗知识问答、金融合规查询
• 容错率高的场景（闲聊推荐）可能不划算

关键判断：检索的质量瓶颈在 Chunk 本身的信息完整性，而不是向量模型够不够强。换更强的向量模型帮助有限——丢失的语境不在向量里，它在切块的那一刻就已经没了。

---

四、审查清单

搭建或审视一套 Agent 评测体系时，按顺序过这九条：

1. 成功定义：能不能用一句话说清「什么算完成」？写不出用例的任务是不是本身就没想清？
2. 起步数量：是否已有至少 20 条覆盖核心场景的 Task？（别等 500 条）
3. 多次试验：同一 Task 是否跑了多个 Trial 以消除随机性？
4. 三类 Grader 齐备：代码守底线、模型提上限、人工做校准——缺哪一类？
5. Rubric 粒度：评分标准是否写到了「每一分代表什么」？
6. 多维度打分：是否拆成可独立观测的维度（如不破坏 / 做了 / 做好）？
7. 环境标准化：评测环境配置是否固定并记录？结果报告是否附带环境信息？
8. 用例新鲜度：是否还在用公开的、可能已被模型记住的题目集？
9. 变更流程：每次改动是否跑完整 Suite？提示词变更是否做逐行消融？

---

五、约束说明

以下约束来自本集原始素材，属于设计与承诺时的边界条件：

1. 评测不是上线前的 checklist，而是贯穿开发周期的基础设施。
2. 没有评测的改动都是赌博。修一个问题可能悄悄破坏其他功能，且你不会立刻知道。
3. 基础设施配置是考题的一部分。环境不一致，分数不可比。
4. 静态 benchmark 对前沿模型的区分力在衰减。模型会识别考试，公开题目集成绩可能被高估。
5. 单一维度的改善不等于整体改善。改一行 Prompt 也可能让另一个维度掉约 3%。
6. 评测本身也需要被评测。环境、用例、变更流程三者都要持续审视。
7. Contextual Retrieval 有预处理成本。每个 Chunk 一次额外 LLM 调用，高准确率场景才划算。
8. 检索瓶颈在 Chunk 完整性，不在向量模型。换更强的向量模型帮助有限。
9. 本集不含题库内容。本集无题库页，全部素材均为正文讲解。

---

六、实践提示

提示一 · 本周就写出 20 条 Task，不要等

不要等有几百条用例才开始。挑你最核心的 20 个场景，每个写清楚输入和成功标准。写的过程本身就是一次产品梳理——你会发现有些场景你根本说不清「什么算完成」，这些正是最需要先对齐的地方。二十条跑起来之后，每次改动都能在几分钟内看到结果，这比任何文档都更能推动团队达成共识。

提示二 · 把 Rubric 写成「每一分长什么样」

如果用了模型 Grader，不要写「给质量打 0 到 1 分」这种模糊标准。把 0 分、0.3 分、0.7 分、1 分各自对应的具体表现写清楚，最好每一档都附一个真实例子。这一步做与不做，模型 Grader 的稳定性差别非常大。做完之后，定期用人工抽检它的打分有没有漂移，这是保证整套体系可信的关键。

提示三 · 记录并固化评测环境配置

在评测报告里固定带上环境信息：CPU、内存、网络条件、沙箱类型。这个动作成本极低，但能挡掉一整类误判——否则某次分数变化到底是模型变好了、还是有人改了沙箱配置，你会完全分不清。同时确保评测环境尽量贴近生产环境，两者不一致时，评测里的高分是不可信的。

提示四 · 给 RAG 的每个 Chunk 补一段上下文前缀

如果线上检索经常「找到了相关的块但答不准」，问题大概率不在向量模型，而在切块时丢了语境。用模型给每个块生成一段包含来源、时间和章节的前缀，再做向量化。做完先只上这一层，测出失败率变化，再叠加关键词双路召回和重排序，逐层验证收益。如果业务容错率高、对准确率要求一般，可以先只做第一层，控制预处理成本。

---

七、可带走的判断清单

1. 把评测当成基础设施。它的第一个价值是逼团队定义成功长什么样。写不出用例，通常说明任务理解还不够清晰。从二十条开始就够。
2. 三种评判器组合使用。代码评判器守底线，模型评判器提上限且必须把评分标准写到每一分都可判断，人工评判器做校准。
3. 把评测环境当成实验条件来控制。处理器、内存、网络和沙箱类型都要固定并记录，且别迷信公开题目集，模型越强越会识别考试。
4. 任何变更都跑完整套件，提示词变更做逐行消融。单一维度的改善不等于整体改善。
5. 检索增强的瓶颈在分块本身的信息完整性。给每块补上来源、时间和章节前缀，配合双路召回与重排序，检索失败率可降低三分之二。

这五条的共同点：评测不是一次性工作，它需要和产品一起进化。你今天建的这套体系，决定了你半年后能不能快速换模型、快速定位问题，以及有没有底气说自己变好了。

---

八、音频与文字稿说明

• 音频为单人口播，面向非工程背景听众，全程不直接口播英文缩写，数字以中文读法呈现。
• 文字稿按「能力地图—概念拆解—审查清单—约束说明—实践提示」组织，可直接作为团队内部培训材料使用。
• 音频的八段结构与本文第三、四节对应，建议先听音频建立主线，再回到本文查清单。
• 本集为进阶篇收官，评测方法与 Contextual Retrieval 方案均有公开实践与效果数据支撑，文中已标注来源与适用边界。

---

来源：xueai.miyang.cn（小山学堂 · 洛小山《学 AI 产品，从入门到精通》）