独立课程
在这里学习完整课程并检验你的理解。
RAG Formation 的 16 节课程内容已完成。本页包含完整课程内容、本地参考资料和可直接在浏览器中完成的即时练习。
本课的具体收获
学完本课后，看到一个聊天机器人的答案，你就能判断问题究竟出在检索还是生成，而这个区分决定了下一步该修哪里。
观看讲解视频
1 · 用一句话理解 RAG
检索增强生成（RAG）的工作方式是：用户一提问，系统就从公司知识库中找出相关证据，放进模型的上下文，然后要求模型只依据眼前的内容回答。
这和把公司的 SOP 永久教给模型完全不同——模型每次只会看到为当前请求交给它的证据。因此，模型还没写下第一个字，聊天机器人就可能已经失败：它可能取错文档、取错文本块，或者什么有用的内容都没找到。
在受监管、需要审计的环境里，“听起来合理”不算质量。只有得到正确证据支持并且标明来源的答案，才算合格。
主要阅读：OpenAI《优化 LLM 准确性》指南——现在先阅读其中关于 RAG 的部分。
2 · 你的实际系统
你的 demo 演示程序是我们的安全沙盒：里面有 25 份 Meridian Labs 虚构文档和 65 道问题，其中 6 道问题系统应该明确拒答。
问题
“重大不符合项的行动计划关闭期限是多少？”
1. 检索 → Qdrant 语义文本块 + Qdrant 摘要 + Meilisearch 关键词命中 + LightRAG 上下文
2. 组装 → qa_service.py 合并并截断证据
3. 生成 → 完成模型根据组装后的上下文写出答案
4. 引用 → 从实际展示给模型的上下文条目中提取来源
5. 评估 → demo/eval.py 分别评估检索、答案正确性、引用、拒答、幻觉和延迟
这种分层正是本课程的基础——演示报告不只是一个百分比，它会准确告诉你系统薄弱在哪个环节。
3 · 改代码前先诊断
| 观察结果 | 可能层级 | 首先检查 |
|---|---|---|
预期文档未出现在 /api/v1/search | 检索 | 索引、分块、查询形式、阈值、排序 |
| 预期文档已检索到，但没有被引用 | 上下文/引用组装 | 上下文截断和来源提取 |
| 文档已被引用，但答案遗漏了必需事实 | 生成 | 提示词、上下文组织、模型行为 |
| 不可回答的问题得到自信的答案 | 有据性/安全 | 拒答指令、证据阈值、评估集 |
| 答案正确，但响应很慢 | 运维 | 后端延迟、图谱调用、上下文大小、并发 |
4 · 练习：问题出在检索还是生成？
场景 A：答案说是“24 小时”——但 /api/v1/search 的结果里根本没有 PR-QA-MRD-009。首先失败的是哪一层？
场景 B：PR-QA-MRD-009 明明出现在搜索结果里，但答案说“60 天”，证据明确写的是“45 天”。哪里出错了？
场景 C：一个没有真实答案的问题得到了一段详细、自信的回复，而且没有来源。哪个指标应该发现它？
5 · 原型成功标准
在开始下一次实验之前，用自己的话写下这五个目标：
- 哪些问题类别必须首先做好？
- 第一个 MVP 需要达到什么准确率门槛？
- 最低可接受的来源命中率是多少？
- 什么样的幻觉率是不可接受的？
- 真实员工能够接受的响应时间是多少？
不要直接复制历史报告 demo-fixed 中的数字，把它们当成自己的目标。那些数字只是讨论用的基线，并不能证明当前系统已经可以上线生产。
企业场景连接
你的用户可能是 QA 团队、监管人员、供应商和审计员——他们不在乎答案听起来多么流畅，只在乎它是否能与正确的 SOP、政策或问卷核对上。因此，我们的第一条工程习惯是：
答案出错时，先检查检索到的证据，再去动提示词。
下一步行动
坚持使用脱敏演示环境，运行下面的离线检查：
cd demo
python eval.py verify
python test_scoring.py然后打开现有报告 demo-fixed.md，找出两个失败案例：一个是检索成功但答案仍然不完整或错误，另一个是来源根本没有被检索到。
如果还有任何术语、指标或失败案例没弄清楚，尽管继续问我。 下一课，我们会沿着真实代码和评估工具，完整追踪一个问题。