# RAG 答错了？Jason Liu 说先修检索

> Instructor 作者的 Maven 课程教你用测试题量化精确率、召回率和 MRR：检索错了，提示词救不回来。

原文: https://fdetimes.net/zh/books-courses/fix-retrieval-before-prompts-jason-liu-rag/

Jason Liu 是独立 AI 顾问，也是 Instructor 库的作者。他的个人简介称，他与从种子轮到 B 轮的公司合作，涉及 RAG、上下文工程和评测。

Liu 在 2024 年的一篇博客中提出，检索应当最先修复。他在 Maven 上以 Applied LLMs 名义开设的课程 [*Systematically Improving RAG Applications*](https://maven.com/applied-llms/rag-playbook)，主题列表也沿着同一思路展开：衡量检索、构建测试数据、改进搜索。

对前线部署工程师（FDE）来说，这不是纸上谈兵。你做了一个基于客户内部文档回答问题的聊天机器人，演示很顺利。再设想两周后，真实用户开始抱怨：回答有错、不完整，或者引用了错误的文档。

这时问题不再是“怎么让它更好”，而是“它在哪里出错，先修什么”。Jason Liu 的课程教你用数字回答第二个问题。

## Jason Liu 为什么从检索入手？

在免费文章 [*The RAG Playbook*](https://jxnl.co/writing/2024/08/19/rag-flywheel/)（2024 年 8 月 19 日）中，Liu 给出了先修检索的三个理由：更容易衡量，往往是最薄弱的环节，也是后续一切的基础。

第二个理由值得 FDE 认真对待。设想一个团队不停调提示词、换模型、加指令，而包含答案的那段文本始终没有进入上下文。检索器返回的文档错了，任何提示词都救不回来。

**要点:** 检索器找不到正确的文档，提示词调得再多也无济于事。

## 这门课教什么？

据官方页面介绍，内容涵盖三个方面。第一是用精确率、召回率和平均倒数排名（MRR）评测检索，找出系统的薄弱点。

第二是构建合成数据管道，不必等待真实用户数据就能快速实验。第三是搜索架构：结合关键词搜索（BM25）、语义搜索（embedding）和元数据。

课程页面还提到，微调 embedding 可带来 20–40% 的提升。这是卖方公布的数字，未经独立验证，应谨慎看待。页面既没有标价，也没有写开课日期，做计划前请自行确认。

## 值得记住的三个观点

**一：把检索和生成分开衡量。** 假设某个问题有 3 段相关文本。检索器返回前 5 个结果，其中有 2 段正确，分别位于第 2 和第 4 位。

Recall@5 为 2/3，约 67%；Precision@5 为 2/5，即 40%。第一段正确文本排在第 2 位，所以倒数排名是 1/2，MRR 就是这个值在整个问题集上的平均。

每个数字回答的是不同的问题。召回率说明答案到底有没有进入上下文；召回率低，就该去修搜索。

精确率 40% 意味着交给模型的 5 段文本里有 3 段是噪声，既占用上下文空间，也可能把回答带偏。倒数排名 1/2 说明正确文本不在最前面：如果系统只取前一两段，排序就决定了模型能否看到答案。

只有在召回率高、正确文本排名靠前、回答仍然出错时，问题才出在生成环节。

**二：别等真实用户。** Liu 把合成数据当作早期阶段的主要工具，用来衡量精确率和召回率。在 [Parlance Labs](https://parlance-labs.com/education/rag/jason.html) 发布的一场演讲（2024 年 7 月 10 日）中，他介绍了做法：让 LLM 根据每个 chunk 生成 2 到 3 个问题，再检查检索器能否找回同一个 chunk。

对 FDE 来说，这是实实在在的优势。你通常要在最初几周拿出进展，那时还没有任何查询日志。一张基线表，加上每次改动后的结果，比任何一句“现在看起来好多了”都更能说服客户。

**三：像写单元测试一样测试检索。** Liu 希望这个流程跑得极快，这样就能不断尝试不同的 chunk 表示和索引方式。每换一种分块策略只需几秒钟就能评测完，实验就会更多，猜测就会更少。

想真正掌握这三个观点，可以做个小练习。假设有 5 个问题，每个问题恰好只有一段正确文本；对前四个问题，检索器把正确文本分别排在第 1、3、2、5 位，第五个问题则在前 5 个结果里没有找到。

Recall@5 为 4/5，即 80%。倒数排名依次是 1、1/3、1/2、1/5 和 0，加起来约 2.03，除以 5 得到 MRR 约 0.41。

两个数字要放在一起看：检索器几乎总能找到答案，但经常排得太靠后。这说明应先在搜索层改进排序，比如加入 BM25 或元数据，再去动提示词。

## Jason Liu 的 RAG 课程适合谁？

这门课适合已经至少把一个 RAG 系统交到用户手里、卡在“时对时错”阶段的工程师。

如果你还没有系统，也可以开始，因为合成数据让你不必等用户就能实验。即便如此，最好先自己做一个小型 RAG 项目，让这些指标有处落地。

至于顺序，先读 *The RAG Playbook*，再听 [TWIML AI Podcast 第 709 期](https://twimlai.com/podcast/twimlai/why-your-rag-pipeline-is-broken-and-how-to-fix-it)（2024 年 11 月 11 日）。Liu 在节目中谈到企业使用 RAG 时面临的挑战，以及为什么需要一个足够好的测试数据集。

如果这两份免费资料正好戳中你眼下的问题，Maven 课程就是下一步。

## 把这项技能变成 FDE 求职的优势

这项技能比你想象的更容易展示。简历上不要只写“搭建了 RAG 聊天机器人”，而要写明评测集有多少个问题，换了搜索策略后召回率如何变化。

FDE 岗位描述里提到 RAG 或 LLM 时，可以在面试中问对方团队如何衡量检索质量。答案会告诉你，加入的是一个有量化纪律的项目，还是一个仍凭直觉推进的项目。

这个问题也会让面试官看到，你的思路像一个真正干过这件事的人。

演示只能证明系统能跑。演示结束后客户是否继续用下去，取决于你能否衡量自己做得怎么样。

**本周动手试试:**

- 从一个 RAG 项目中取 20 段文档，让 LLM 为每段生成 2 到 3 个问题，再检查检索器能否把该段文本返回到前 5 名
- 为这组问题计算 recall@5 和 MRR，在修改提示词或模型之前记录下来作为基线
- 阅读 jxnl.co 上的 The RAG Playbook，标出一个能马上用在当前客户项目上的观点

## 信源

- [Systematically Improving RAG Applications](https://maven.com/applied-llms/rag-playbook)

- [The RAG Playbook](https://jxnl.co/writing/2024/08/19/rag-flywheel/)

- [Why Your RAG System Is Broken, and How to Fix It with Jason Liu](https://twimlai.com/podcast/twimlai/why-your-rag-pipeline-is-broken-and-how-to-fix-it)

- [Systematically improving RAG applications w/Jason Liu](https://parlance-labs.com/education/rag/jason.html)

- [Jason Liu resume](https://jxnl.co/resume/)