课 2 · 评测与迭代

本课目标

学会用一个小评测集做 before/after 对比，判断“混合检索有没有比原来更稳”。课后你会拿到一个会输出基线、进阶结果和 Bad Case 结论的评测脚本。

上一课解决的是“怎么改”。这一课解决的是另一个更重要的问题：

你怎么知道这次优化不是心理作用？

为什么不能只靠感觉

RAG 优化最容易掉进这三种坑：

1. 改了参数，试了两个问题，感觉不错，就当它变好了
2. 某个 demo 表现很好，就误以为整体都稳定
3. 用户反馈“答非所问”，但你不知道问题出在检索还是回答

所以模块 4 的验收重点不是先背术语，而是先建立一个最小闭环：

小评测集 + before/after 对比 + Bad Case 分析。

最小评测集长什么样

你只需要一小批典型问题：

interface EvalItem {
  question: string
  groundTruth: string
}

const evalDataset: EvalItem[] = [
  {
    question: 'useEffect 的依赖数组为空时会发生什么？',
    groundTruth: '依赖数组为空 [] 时，useEffect 只在组件挂载时执行一次。',
  },
  {
    question: 'Flexbox 和 Grid 怎么选？',
    groundTruth: 'Flexbox 适合一维布局，Grid 适合二维网格布局。',
  },
]

数量不用大，先保证代表性：

• 有 API 名和术语问题
• 有概念解释问题
• 有容易答错或漏检索的问题

我们到底在看什么

这节课正文只用更直白的说法：

• 搜得准不准
• 答得对不对
• 有没有瞎编
• 改完有没有变好

如果你以后继续做工程化评测，会遇到 Faithfulness、Answer Relevancy、Context Precision、Context Recall 这些术语。现在先把它们理解成上面四个问题就够了。

before / after 怎么比

模块 4 主线里，我们只比较两组：

• 基线组：混合检索
• 进阶组：混合检索 + Rerank

代码结构可以很简单：

async function runEvaluation(dataset: EvalItem[]) {
  for (const item of dataset) {
    const candidates = await hybridSearch(item.question, 5)

    const baselineDocs = candidates.slice(0, 3)
    const advancedDocs = await rerankWithLLM(item.question, candidates, 3)

    const baselineAnswer = await answerFromDocs(item.question, baselineDocs)
    const advancedAnswer = await answerFromDocs(item.question, advancedDocs)

    const baselineScores = await judge(item, baselineAnswer, baselineDocs)
    const advancedScores = await judge(item, advancedAnswer, advancedDocs)

    console.log(item.question, baselineScores, advancedScores)
  }
}

重点不是“评测框架多完整”，而是你能回答这句话：

改完以后，平均分有没有提升，最差样例有没有变好。

怎么看 Bad Case

Bad Case 比平均分更重要，因为它直接告诉你下一步该改哪儿。

一个很实用的判断方式：

现象	更像什么问题
检索结果不相关、漏掉关键文档	检索问题
检索结果基本对，但回答仍然偏题或编造	回答问题

对应动作：

• 检索问题：优先看切块、关键词信号、排序
• 回答问题：优先看提示词约束、上下文噪音、拒答逻辑

这比单纯背四个英文指标更有用。

在主线项目里怎么落

本模块能力会在基础项目 basic/project/ 中收束，当前课内 Demo 见下方运行方式。

主线代码里的 /eval 已经改成：

• 先输出基线组和进阶组的平均分对比
• 再给出一个重点 Bad Case
• 最后提示这个问题更像出在检索还是回答

这样做的目的很明确：

让你把“评测”理解成验收动作，而不是术语清单。

扩展阅读

如果你继续往工程化走，可以再补这些内容：

• RAGAS 它是一套更标准的 RAG 评测框架，适合后续自动化回归和团队协作。
• 更完整的数据集构建 比如从真实日志中抽样、人工审核 LLM 生成问答、按业务场景分层。
• A/B 测试 当策略更多时，不只比两组，而是长期跟踪多个版本。

本课产物

• ✅ 一个最小可用的评测数据集
• ✅ 基线 vs 进阶的对比脚本
• ✅ 用 Bad Case 定位问题的方法
• ✅ 对 RAGAS 的正确预期：扩展框架，不是本课门槛

试试看

cd daqi-ai-agent
pnpm exec tsx basic/examples/04-rag-advanced/02-evaluation/index.ts

1. 先看平均分对比，再看最差样例
2. 对照 basic/examples/04-rag-advanced/02-evaluation/index.ts 里的 evalDataset 和 documents，看每个问题是在验证哪类能力
3. 如果你想做进阶实验，可以临时删掉脚本里的关键文档，或放宽 answerFromDocs 的回答约束，再重新运行，观察结论会更偏向“检索问题”还是“回答问题”

面试追问

Q：为什么 RAG 优化不能只靠手测几个问题？

因为手测只能给你局部印象，不能证明整体是否变好。真实项目里要用小评测集做基线对比，再看 bad case 才知道问题到底出在哪一层。

Q：RAGAS 要不要在模块 4 里全讲完？

不用。模块 4 更重要的是先建立“怎么验收优化”的工程习惯。RAGAS 适合作为后续工程化扩展去补，而不是这一节课的记忆负担。