摘要：本文是吴恩达 RAG 系列课程模块三的学习笔记，围绕 RAG（检索增强生成）从原理到落地展开。全文先讲清 RAG 解决的五个痛点与「提取 → 索引 → 检索 → 生成」四步流程，再依次拆解 Naive、Advanced、Modular 三代范式的演进逻辑，重点说明预检索与后检索策略、切分与 HyDE 的作用、混合检索为何用 RRF 融合，随后给出 RAGAs 四大指标与 TruLens 的量化评估方法，最后落到 RAG 与微调的取舍、框架与向量库选型、六大行业场景及常见误区。适合想系统掌握 RAG 工程链路、并动手跑通基线的开发者阅读。

目录

• 一、可视化导览
• 二、视频清单（8 集 · 约 2.2 小时）
• 三、RAG 解决什么 · 四步流程 · RAGFlow
• 四、第一代：Naive RAG（朴素版）
• 五、第二代：Advanced RAG（进阶版）
• 六、第三代：Modular RAG（模块化）
• 七、RAG 评估
• 八、行业落地与选型
• 九、核心概念速查表
• 十、学习打卡
• 十一、本模块常见问题与实战补充
• 十二、延伸练习
• 十三、深挖：检索链路到底在哪一步丢分
• 十四、选型与部署的实战补充
• 十五、三代范式的演进逻辑串讲
• 十六、面试常考问题速记
• 二十四、总结与参考资料

吴恩达《面向开发者的提示词工程》

吴恩达 MCP 教程（Model Context Protocol）（一）

多模态大模型教程学习笔记 — ViT · CLIP · SAM · GLIP · Stable Diffusion

一句话总结：RAG（Retrieval-Augmented Generation，2020 年论文提出）让大模型用上私有、最新、可追溯的知识，是企业落地性价比最高的方案。本模块从 RAGFlow 实操出发，系统讲清 Naive → Advanced → Modular 三代范式、预检索/后检索策略、四种模块化 flow、混合检索 RRF 融合，再用 RAGAs / TruLens 做量化评估，最后给出 RAG 与微调的取舍、框架与向量库选型及六大行业场景。

素材覆盖说明：模块三共 8 集（第 40-45、55、56 集），本地视频与字幕齐全，全部据字幕据实整理，无补全小节。

一、可视化导览

本模块的 RAG 四步流程、三代范式演进、四种模块化 flow、评估指标与落地选型已整理成一张知识图谱：模块三 · RAG 检索增强生成 · 可视化图谱

1.1 为什么 RAG 是企业落地性价比最高的方案

大模型再强，也有三个绕不开的硬伤：它的知识停在训练截止那天，公司内部的私有文档它从没见过；它会一本正经地编造，也就是幻觉；它给出的答案你无法核对出处。要解决这些问题，有两条路。一条是把私有知识塞进模型去训练，也就是微调，但训练贵、更新慢、还没法告诉用户答案从哪来。另一条就是 RAG：不动模型本身，只是在它回答之前，先去你的资料库里把相关内容捞出来，连同问题一起递给它。这样模型回答时"手里有资料"，答案有据可查，资料更新了只要重新索引、不用重训模型。这就是为什么企业做知识问答，几乎都从 RAG 起步。

理解 RAG 的关键，是建立一个朴素但重要的认知：RAG 并不让模型变得更聪明，它只是给模型"递小抄"。模型本身的能力没变，变的是它回答时能看到的上下文。所以如果小抄递错了、递漏了，模型照样会答错。这也是为什么后面要花那么多篇幅讲预检索、后检索、评估——整个 RAG 工程，本质上都是在解决"怎么把对的资料，在对的时机，以对的方式递给模型"。

1.2 离线与在线两条链路要分清

很多人学 RAG 混乱，是因为没把"离线建库"和"在线问答"两条链路分开。离线链路是你提前做的一次性工作：把各种格式的文档解析出来、清洗干净、切成小块、用 embedding 模型把每块变成向量、存进向量库。这一步做一次，之后增量更新即可。在线链路是用户每次提问时实时发生的：把用户问题也变成向量、去库里找最相似的几块、精排、拼进提示词、让模型生成。

把这两条链路分清，你定位问题时就有了方向。如果发现"库里明明有这段资料却召不回"，问题多半出在离线切分或 embedding；如果"召回的片段是对的但答案还是错"，问题多半出在在线的拼提示词或模型本身。很多人一上来就怪模型，其实是没分清问题在哪条链路上。

记忆钩子：离线是"把书拆成卡片塞进抽屉"，在线是"根据问题去抽屉抽几张相关卡片"。切卡片和抽卡片，是两件可以分别优化的事。

二、视频清单（8 集 · 约 2.2 小时）

集	标题	时长	核心内容
40	RAG 技术原理与 RAGFlow 项目实操	19:40	RAG 四步流程、RAGFlow Docker 部署与解析
41	Naive RAG 与 langchain 实践	12:44	朴素版链路、Chroma、BGE-small-zh、chunk 参数
42	高级 RAG（一）层次索引、句子窗口、子查询、HyDE	17:10	预检索策略全家桶
43	高级 RAG（二）提示词压缩、融合、llamaindex	14:25	后检索、Rerank、LLMLingua、BM25+向量 RRF
44	模块化 RAG（一）顺序、条件、分支模式	11:37	RouterQueryEngine、并行分支
45	模块化 RAG（二）迭代、递归、FLARE、ToC	17:55	环形 flow、IR-CoT、FLARE、Self-RAG
55	RAG 评估：评估指标、RAGAs、TruLens	22:01	评估四件套、RAGAs 四指标、TruLens 面板
56	RAG 行业落地：实践心得、落地经验、业务场景	15:53	RAG vs 微调、框架/向量库选型、六大场景

三、RAG 解决什么 · 四步流程 · RAGFlow

3.1 五个痛点

大模型本身存在知识盲区、会幻觉、知识过时、答案不可追溯、私有数据不能直接喂等问题。RAG 通过"先检索、再生成"一并解决：私有知识可接入、回答有据可依、索引随时更新、能给出来源、数据不必出域。

3.2 四步流程

阶段	环节	做什么
离线	① 提取	解析 PDF/Word/表格/图片，清洗、OCR、切分
	② 索引	分块 chunk，用 embedding 模型向量化后写入向量库
在线	③ 检索	问题向量化，先相似度粗召回（如 Top100），再重排序取 Top 几条
	④ 生成	把召回内容作为上下文拼进提示词，交 LLM 生成带依据的答案

3.3 RAGFlow 实操要点

RAGFlow 是一个主打深度文档理解的开源 RAG 引擎，适合不想从零拼链路的团队。部署与使用要点：

• 基于 WSL2 + Docker Desktop 用 Docker 部署。

• 容器内配置模型地址时要填 host.docker.internal（不是 127.0.0.1）；本地用 Ollama 跑 qwen2 7B 4bit。

• 建知识库后必须手动点“解析”，系统才会真正对文档做切块、向量化、入库——只上传不解析等于没有索引。

# 1. 拉取并启动 RAGFlow（WSL2 + Docker Desktop 环境）
git clone https://github.com/infiniflow/ragflow.git
cd ragflow/docker
docker compose -f docker-compose.yml up -d
2. 查看容器状态，确认 ragflow-server 已启动
docker ps | grep ragflow
3. 浏览器访问 http://localhost:80 进入 RAGFlow 控制台
在「模型提供商」中把地址填为 host.docker.internal:11434（Ollama 默认端口）

四、第一代：Naive RAG（朴素版）

朴素版就是“索引 → 检索 → 生成”一条直线，没有任何额外优化。课程的技术栈为 Python + Ollama + Chroma + LangChain + BGE-small-zh（智源中文 embedding），其中 Chroma 原生支持 Windows、上手最简单。

# 安装依赖
pip install langchain langchain-community chromadb sentence-transformers ollama

两个关键分块参数：chunk_size（块大小）= 500、overlap（相邻块重叠）= 50。重叠是为了避免把完整语义从中间切断。朴素版的主要问题是召回质量不稳定、容易漏检或召回无关内容，这正是进阶版要解决的。

from langchain_community.document_loaders import TextLoader
from langchain_text_splitters import RecursiveCharacterTextSplitter
from langchain_community.embeddings import HuggingFaceEmbeddings
from langchain_community.vectorstores import Chroma
1. 加载文档
docs = TextLoader("your_doc.txt", encoding="utf-8").load()
2. 切分：块大小 500，重叠 50
splitter = RecursiveCharacterTextSplitter(chunk_size=500, chunk_overlap=50)
chunks = splitter.split_documents(docs)
3. 向量化并写入 Chroma
embedding = HuggingFaceEmbeddings(model_name="BAAI/bge-small-zh-v1.5")
vectorstore = Chroma.from_documents(chunks, embedding, persist_directory="./chroma_db")
4. 检索 Top3
retriever = vectorstore.as_retriever(search_kwargs={"k": 3})
results = retriever.invoke("RAG 的四步流程是什么？")
for doc in results:
print(doc.page_content)

五、第二代：Advanced RAG（进阶版）

在朴素链路的检索前与检索后各加一组优化模块，是当前工程落地的主力形态。

5.1 预检索（Pre-retrieval）

策略	作用
滑动窗口 / 句子窗口 SentenceWindow	用小颗粒检索命中、再还原到周围更大上下文，兼顾精准与完整
metadata 元数据过滤	按时间、部门、文档类型等字段先缩小检索范围
层次化 / TreeIndex / small-to-big	建立多层摘要索引，先用摘要定位再取原文细节
知识图谱	对实体关系复杂的领域用图谱补充向量检索
查询改写 / SubQuery / MultiQuery	把一个复杂问题拆成多个子问题，或生成多个同义问法分别检索
HyDE	先让模型"假设"一个可能的答案，用假设答案去检索（它比短问题更接近文档表述）
Reverse-HyDE	反过来为文档假设可能对应的问题

5.2 后检索（Post-retrieval）

• 结果去重：去掉多个高度重复的召回片段。

• Rerank 重排序（几乎必上）：用交叉编码器对粗召回结果重新精排，把真正相关的顶到前面（原理见模块四）。

• LLMLingua 提示词压缩：压缩召回上下文，可把 token 压到约 1/20，省成本、降噪声。

• 混合检索 + RRF 融合：稀疏检索 BM25（擅长关键词精确匹配）与稠密检索 embedding（擅长语义）各出一份排名，用 RRF（Reciprocal Rank Fusion，倒数排名融合）合并，无需对齐两套分数的量纲。

RRF 公式：某文档的融合分数 = Σ 1/(rank + K)，rank 是它在各榜单中的名次，K 是平滑常数（常取 60）。名次越靠前贡献越大，多榜都命中的文档排名显著上升。

def rrf_fusion(rankings, k=60):
    """rankings: 多个榜单，每个榜单是按相关性排序的文档 id 列表"""
    scores = {}
    for ranking in rankings:
        for rank, doc_id in enumerate(ranking, start=1):
            scores[doc_id] = scores.get(doc_id, 0) + 1 / (rank + k)
    return sorted(scores.items(), key=lambda x: x[1], reverse=True)
示例：BM25 榜与向量榜融合
bm25_ranking = ["doc1", "doc3", "doc2"]
vector_ranking = ["doc2", "doc1", "doc4"]
print(rrf_fusion([bm25_ranking, vector_ranking]))

5.3 切分策略为什么是召回质量的命门

在所有 RAG 优化里，切分（chunking）是最被低估、却影响最大的一环。切分做不好，后面上再贵的 Rerank 也救不回来。为什么？因为检索是按"块"为单位的：如果一个完整的知识点被从中间切成两块，查询时可能只命中其中一半，模型拿到的就是残缺信息；反过来，如果一块塞得太长太杂，相似度计算时关键信息被稀释，又会召不准。课程给的默认值是块大小五百、重叠五十，这只是起点，不是真理。

实操时的经验是：优先按语义边界切，比如按段落、按小标题，而不是死板地按字数硬切；表格、代码、列表这类结构化内容尽量整块保留，别切碎；相邻块留一点重叠，就是为了防止一句话从中间断开后两边都不完整。更高级的做法是"小颗粒检索、大颗粒返回"——索引时切得小以提高命中精度，但真正递给模型时把命中块前后更大的上下文一起带上，这正是课程里 SentenceWindow 策略的思路。

5.4 HyDE 为什么能改善召回

向量检索有个天然矛盾：用户的问题往往很短、很口语化，而文档里的句子往往是书面、完整的。两者表达方式不一样，直接拿短问题去匹配，相似度往往不高。HyDE 的巧思是：先让模型根据问题"瞎编"一个可能的答案，哪怕这个答案是错的也没关系；关键是这个编出来的答案是书面完整的句子，和真实文档的表达方式更接近，拿它去做向量检索，命中率反而更高。说白了，HyDE 是把"短问题"翻译成了"和文档同风格的查询"。理解这点，你就明白它本质是一种查询改写，而不是在提升生成质量。

5.5 为什么混合检索要 RRF，而不是直接加权重排分

BM25 是关键词检索，它打出来的分数和向量相似度的分数，量纲完全不同——一个可能是几十，一个可能是零点几，根本没法直接相加或加权。硬加权就得反复调权重，很麻烦还不稳健。RRF 的聪明之处在于：它完全不看分数大小，只看"排名"。一篇文档在 BM25 榜里排第几、在向量榜里排第几，按名次倒数算个贡献加起来。两篇榜都靠前的文档，融合后自然排到最前。这样既不用对齐量纲，又能同时发挥关键词检索擅长精确术语、向量检索擅长语义近似的长处。这就是为什么混合检索几乎都用 RRF 融合。

一句话记：BM25 认"字"，向量认"意"，RRF 只看"名次"把两路结果和在一起。专业术语多的库，BM25 尤其不能丢。

六、第三代：Modular RAG（模块化）

把 RAG 拆成可复用模块：最初 6 类 module type，逐步细化为 14 个 module、再到更细的 operator，可按需编排。核心是四种 flow：

flow	结构	说明 / 代表
顺序	模块串行	固定链路，代表为网易 QAnything
条件	按条件路由	RouterQueryEngine 依据各节点 description 匹配，走不同检索分支
分支	并行处理	检索前并行拆子查询，或检索后多篇文档各自生成再汇总
环形	带反馈闭环	迭代 / 递归 / 自适应检索，见下方四种代表

环形 flow 的四种代表

• IR-CoT：迭代检索-思考（Retrieve then Reason），固定轮数地"检索一点、推理一点"。

• ToC（Tree of Clarifications，澄清树）：递归改写查询 / 生成澄清问题，默认用 BFS 广度优先展开。

• FLARE（Forward-Looking Active Retrieval）：边生成边检索，模型在生成中遇到低置信度内容时，就把该处掩码或主动生成一个检索问题去查资料再续写。

• Self-RAG：经过特殊微调，模型用 [Retrieval] 等四类特殊 token 自我评判"要不要检索、检索结果是否相关、生成是否有据"，把检索决策内化进模型。

七、RAG 评估

7.1 评估四件套

1. 指标：定义要衡量的维度；

2. 测试数据集：标注好的问答对（问题、参考答案、相关文档）；

3. 自动化工具：RAGAs、TruLens、LlamaIndex 评估、LangSmith、DeepEval、Phoenix；

4. 用户反馈 / AB 测试：线上真实效果回流。

7.2 RAGAs 四大指标（无需参考答案）

上下文相关性 Context Relevance	召回的上下文与问题是否切题，衡量有没有捞回噪声
上下文召回 Context Recall	回答所需的信息是否都被召回，衡量有没有漏
忠实度 Faithfulness	答案中的陈述能否被召回上下文支撑，专查幻觉（最重要之一）
答案相关性 Answer Relevance	最终回答是否真正回应了用户问题、有没有答非所问

实操提示：RAGAs 课程使用 0.1.12 版本；评测数据里的特殊字符必须先清洗，否则 JSON 序列化报错。TruLens 提供三类反馈函数，本地 Ollama 可经 LiteLLM provider 接入，用 run_dashboard 启动可视化面板，看到每条记录的检索与评分明细。

from datasets import Dataset
from ragas import evaluate
from ragas.metrics import (
    context_relevance,
    context_recall,
    faithfulness,
    answer_relevancy,
)
评测数据：问题、召回上下文、模型答案、参考答案
data = {
"question": ["RAG 的四步流程是什么？"],
"contexts": [["提取 → 索引 → 检索 → 生成"]],
"answer": ["RAG 分为提取、索引、检索、生成四步。"],
"ground_truth": ["提取、索引、检索、生成"],
}
dataset = Dataset.from_dict(data)
result = evaluate(
dataset,
metrics=[context_relevance, context_recall, faithfulness, answer_relevancy],
)
print(result)

八、行业落地与选型

8.1 RAG 还是微调

维度	倾向 RAG	倾向微调
知识更新	更新频繁、内容常变	知识稳定、不常变
目标	注入知识、可追溯、降幻觉	固化人设、语气、风格、固定能力
可解释性	强，能给来源	弱，近似黑盒
资源 / 延迟	算力成本低，但多了检索环节	训练成本高；推理延迟更低
幻觉	基本无（受上下文约束）	仍可能编造知识

8.2 框架与向量库选型

• LangChain：适合小项目快速搭；大系统容易被其高层抽象"绑架"，定制困难。

• LlamaIndex：专为数据/检索而生，集成度相对低但更灵活，进阶 RAG 算子丰富。

• 研发能力弱：直接用 RAGFlow / QAnything 二次开发，少造轮子。

• 向量库：已在用 ES 就用 ES dense_vector + HNSW；已在用 PostgreSQL 就上 pgvector；ClickHouse 适配 OLAP；轻量入门用 Chroma / Milvus（详见模块四）。

8.3 调优要点与六大场景

调优清单：embedding 可针对领域微调 ｜ 调 chunk 大小与重叠 ｜ 清洗表格、做好 OCR（可参考清华 GOT）｜ 中文优先用大厂开源 embedding ｜ Rerank 必上、甚至微调 ｜ 召回置信度 > 0.6 才采用 ｜ 实体关系复杂用 GraphRAG。

六大落地场景：智能客服 ｜ 生产 SOP 工艺问答 ｜ 金融知识图谱 ｜ 法律检索 ｜ 医疗辅助问答 ｜ 企业知识资料沉淀与审批流程优化。课程总结：企业做大模型应用，最后往往只剩三件事——提示词工程、微调、RAG。

8.4 怎么向非技术同事解释 RAG 和微调的区别

这是个面试和落地都常被问到的问题。一个好懂的比方：RAG 像是开卷考试——学生（模型）进考场时可以带着资料，遇到不会的题就翻书找答案，资料更新了换本新书就行，但他答得好不好取决于书翻得快不快、翻得准不准。微调像是把知识点反复灌输给学生，让他背下来——之后考试不用带书，答得快，但书里的内容一旦更新，就得让他重新背一遍，而且他具体从哪本书哪页背出来的，你也说不清。

用这个比方就能回答业务方的问题：你的知识是不是经常变？变，就用 RAG；你的需求是"回答特定知识"还是"表现出特定风格"？要风格（比如固定的客服语气、某种写作范式），微调；要知识可追溯，RAG。绝大多数企业知识问答，先用 RAG 就够了；只有当 RAG 怎么调都无法满足某种风格化、能力固化的需求时，才考虑叠加微调。两者不是对立，而是常常组合使用。

8.5 六大场景背后的共性

课程列了智能客服、生产工艺、金融图谱、法律检索、医疗问答、企业知识沉淀六个场景。它们表面不同，背后的共性是一样的：都有大量私有、专业、需要准确引用的文档，都不能容忍模型胡编，都希望答案能追溯到出处。区别只在于文档形态和精度要求——法律、医疗对准确性和引用要求最高，往往要上 GraphRAG 和更严格的引用校验；客服类对响应速度和覆盖面要求高，往往要做查询路由和多知识库分流。理解了这个共性，你面对一个新场景时，就知道该往哪几个方向调：文档越专业，越要重视切分和 Rerank；引用要求越高，越要把忠实度指标盯紧。

8.6 为什么说"先跑基线再迭代"是铁律

新手做 RAG 最容易犯的错，是一上来就堆各种高级技巧：又加 HyDE、又上 Rerank、又做混合检索，结果效果到底好不好、是哪一步起了作用，完全说不清。正确做法是反过来：先跑一个最朴素的 Naive RAG，用 RAGAs 打个分当基线；然后一次只加一个优化，每加一次重新打分，看指标是升是降。这样你才能知道，在你的具体数据上，到底是 Rerank 起了作用，还是查询改写更管用，还是切分才是最大瓶颈。没有基线的调优都是碰运气。

铁律：没有评测就没有优化。先攒二三十个标准问题，建一个能反复打分的评测集，后面每一次改动都用数据说话，而不是凭感觉。

九、核心概念速查表

概念	一句话理解
RAG 四步	提取 → 索引 → 检索 → 生成
chunk / overlap	分块大小 / 相邻块重叠（示例 500 / 50）
三代范式	Naive 直线 → Advanced 加前后处理 → Modular 模块编排
HyDE	先假设答案再用它去检索
混合检索	BM25（关键词）+ embedding（语义），RRF 融合排名
RRF	分数 = Σ 1/(rank + K)，无需对齐分数量纲
四种 flow	顺序 / 条件（路由）/ 分支（并行）/ 环形（反馈）
FLARE / Self-RAG	边生成边主动检索 / 用特殊 token 自我评判
RAGAs 四指标	上下文相关性、上下文召回、忠实度、答案相关性

十、学习打卡

• 能完整说出 RAG 解决的五个痛点与四步流程

• 能用 Docker 部署 RAGFlow，建好知识库并记得点"解析"

• 能用 Chroma + LangChain + BGE 跑通一个 Naive RAG，并会调 chunk_size/overlap

• 能说清至少 4 种预检索策略与 3 种后检索策略

• 理解 HyDE 与混合检索 RRF 的原理，能写出 RRF 公式

• 能区分 Modular RAG 的四种 flow，并举出环形 flow 的代表

• 能用自己的话说清 FLARE 与 Self-RAG 的区别

• 能列出 RAG 评估四件套与 RAGAs 四指标及其含义

• 能从知识更新、可解释性、成本、延迟、幻觉五个维度判断 RAG vs 微调

• 能结合业务给出框架与向量库的选型建议和调优清单

学习建议：本模块概念多、算子多，不必死记每个策略的实现细节，先建立"三代演进 + 前后检索 + 四 flow + 评估"的骨架，再在自己的数据集上动手：先跑 Naive 拿基线，用 RAGAs 打分，再逐个加 Rerank、查询改写、混合检索，观察指标变化——这是理解进阶 RAG 最快的方式。

十一、本模块常见问题与实战补充

11.1 RAGAs 四个指标分别暴露什么问题

学会用 RAGAs 打分还不够，要会读分数。如果上下文召回低，说明该捞的资料没捞到——问题在检索环节，要改切分、换 embedding、加混合检索。如果上下文相关性低，说明捞回来一堆不相关的——问题在检索太宽或阈值太松，要加 Rerank、收紧阈值。如果忠实度低，说明召回的资料是对的，但模型没有照着资料答、自己瞎编了——问题在提示词约束和模型，要在提示词里强调"只依据给定资料回答"。如果答案相关性低，说明答非所问——问题在查询理解，要做查询改写或澄清。你看，四个指标正好对应链路的四个不同环节，哪个指标差，就去哪一环找原因。这就是量化评估的价值：它把"效果不好"这个模糊感受，变成了四个可定位的具体问题。

11.2 FLARE 和 Self-RAG 到底解决什么

传统 RAG 是"先一次性把资料捞够，再一口气生成"。但有些长答案，你一开始根本不知道后面会需要查什么。FLARE 的思路是边写边查：模型写一段，写到自己都没把握、预测到下一句可能需要资料时，就主动停下来，把那个疑点变成一个查询去检索，拿到资料再接着写。Self-RAG 更进一步，它是经过专门微调的模型，天生就懂得用特殊标记自我判断"这里需不需要检索、刚才召回的资料到底相不相关、我这段回答有没有依据"。两者都代表了 RAG 的演进方向——从"检索一次用到底"走向"按需、动态、自适应地检索"。

11.3 实战中的常见误区

误区一：以为上了 RAG 就不会幻觉——错，召回错了照样错。误区二：召回条数越多越好——错，塞太多无关内容反而稀释、误导模型。误区三：盲目追求最复杂的 flow——错，多数业务一个调好的 Advanced RAG 就够了。误区四：忽略文档解析质量——错，PDF 里的表格、图片如果 OCR 得稀烂，后面再怎么调都白搭。误区五：不做评估就凭感觉调——错，这是最常见也最致命的。

十二、延伸练习

练习一：用你自己的一份 PDF 文档，先跑 Naive RAG，记下 RAGAs 基线分。练习二：加上 Rerank，重新打分对比。练习三：把纯向量检索换成 BM25 加向量的混合检索加 RRF，再打分。练习四：故意把同一份文档用两种切分策略建库，观察召回差异。这四个练习做下来，你对三代范式和前后处理策略的理解，会远超只看视频。

• 我能说清离线建库与在线问答两条链路各自做什么

• 我能用开卷考试的比方向别人解释 RAG 与微调的区别

• 我能根据 RAGAs 四个指标的高低，定位到底该优化哪一环

• 我亲手跑过 Naive 基线，并至少做过一次加优化前后的对比打分

本模块小结：RAG 的核心不是某个花哨技巧，而是一条"把对的资料递给模型"的工程链路。三代范式是这条链路不断加控制的过程，评估是让你知道自己有没有变好的标尺。下一站模块四，钻进检索底座，看 embedding、重排和向量库是怎么决定召回上限的。

十三、深挖：检索链路到底在哪一步丢分

很多同学做完朴素版检索，觉得效果不好，却说不清到底是哪一步出了问题。这里把整条在线链路再拆开，逐段讲清楚每个环节可能丢掉什么分，方便你对照自己的项目排查。第一步是把用户的问题变成向量。这一步的问题往往出在问题本身太模糊，用户只说了半句，系统却当成完整问题去检索，自然捞不到东西。这时候该做的不是换模型，而是在检索前加一步澄清，或者把用户的口语化问题改写成更接近文档语言的完整问法。这就是前面讲的查询改写要解决的事。

第二步是拿问题向量去库里做相似度粗召回。这一步的典型问题是只召回了语义相近、其实无关的段落，或者反过来，明明库里有答案却因为表达方式不同没召到。前者说明召回太松，需要收紧阈值或者加精排；后者说明只靠语义检索不够，要补上关键词检索那一路，也就是混合检索。你要养成一个习惯：遇到召不回的问题，先把那个问题手工到库里搜一下关键词，看看资料到底是用什么词表达的——如果资料用的是专业术语而用户问的是大白话，那就是表达鸿沟，该上混合检索或者查询改写。

第三步是精排。粗召回一般取一百条，这里面噪声很多，精排就是用一个更懂语义匹配的模型，把这一百条重新排一遍，只留下最靠前的三四条。为什么需要这一步？因为粗召回用的是 embedding，它追求快，把查询和文档分别独立编码再算相似度，这种方式精度有限；而精排用的是交叉编码，它把问题和候选段落拼在一起同时送进模型，让模型充分理解两者关系，判断更准，只是慢，所以只能对少量候选做。这就是为什么精排几乎必上。

第四步是把精排后的几条拼进提示词交给模型。这一步最容易被忽略的是：你拼进去的顺序、给模型的指令，都会影响答案。把最相关的放在前面，明确告诉模型"只能根据下面给的资料回答，资料里没有就说不知道"，能显著压低幻觉。反过来，如果一次塞进去十条、互相矛盾的资料，模型反而被搞糊涂。所以不是塞得越多越好，而是精、少、准。

十四、选型与部署的实战补充

关于框架，新手常纠结到底用哪个。课程的判断很实在：小项目、想快速出东西，用最成熟的编排框架，生态全、坑都被踩过；但当你的系统越做越大，会发现那些高层封装反而成了束缚，你想定制一个特殊算子都被框架挡着。这时候要么换更灵活的框架，要么干脆自己控制链路。一句话：入门靠框架提效，深入靠自己掌控。关于向量库，课程给的原则非常实用——别为了上向量库而专门引入一个新组件。你的团队已经在用什么数据库，就在它上面加向量能力，这样运维成本最低。轻量入门阶段用最简单的本地库跑通流程即可，等数据量和并发上来了，再换分布式向量库。

关于中文场景，有一条特别重要：中文一定要优先用专门为中文训练的向量模型。拿只在英文上训练的模型去算中文，效果会打折，因为中英文的语义分布差别很大。课程实操里用的就是开源中文向量模型，这不是随便选的。同理，做中文问答时，切分也要考虑中文的特点，中文没有空格分词，按字数硬切和按语义切差别很大。

落地心法：文档解析决定上限，切分决定召回，精排决定精度，提示词决定发挥。这四件事按顺序抓，比一上来堆高级技巧有效得多。

• 我能按离线、在线两条链路复盘自己的检索项目

• 我理解了为什么交叉编码精排又慢又准，只能对少量候选做

• 我知道中文场景为什么要选中文向量模型

• 我明白了为什么已有什么数据库就优先在它上面加向量能力

十五、三代范式的演进逻辑串讲

学完三代范式，最该建立的是一条演进主线，而不是把它们当成三个孤立名词。第一代朴素版，就是一根直线：把文档切块入库，用户来了就查、查完就生成。它简单，但很快就暴露问题：切分是一刀切的，召回是一次性的，没有任何纠偏机制，于是召回不好就一路错到底。于是有了第二代进阶版，思路是在这根直线的前后各加东西。检索前加一组策略，目的是让问题更像样、让候选更聚焦，比如查询改写、句子窗口、元数据过滤；检索后再加一组策略，目的是把捞回来的一堆结果去粗取精，比如去重、精排、压缩、多路融合。到这一步，链路已经相当能用了，是当前生产环境的主流。

但进阶版还是一条直线，它不会根据问题类型自动切换打法，也不会在发现资料不够时主动再查一轮。于是有了第三代模块化版，核心思想是把整条链路拆成一个个可复用的零件，像搭积木一样编排。遇到简单问题就走最短链路，遇到复杂问题就拆成子问题并行查，发现查出来的不够就再回去查一轮。这就是四种流程结构的来历：顺序是最朴素的串行；条件是加了个路由，按问题类型走不同分支；分支是把一个大问题拆开并行去查、再汇总；环形是带了反馈，查一轮不够就再查、边生成边查。理解了这条演进主线，你就不会被一堆名词淹没——它们都是为了解决前一代的某个具体局限而出现的。

十六、面试常考问题速记

第一问，朴素版检索为什么效果不稳定？答：因为一刀切的切分会破坏语义，一次性粗召回没有精排容易带进噪声，而且没有任何根据反馈再检索的机制，错了就一路错到底。第二问，混合检索为什么要做融合？答：关键词检索擅长精确术语匹配，向量检索擅长语义近似，二者互补；但它们的分数量纲不同没法直接加权，所以用只看排名的融合方法合并两路结果。第三问，怎么判断该用检索增强还是微调？答：看知识是否常更新、是否要求可追溯、是要注入知识还是要固化风格；知识常变、要出处，用检索增强；知识稳定、要风格固化，才微调，两者常组合。第四问，怎么评估一个检索增强系统好不好？答：用四个维度分别看召回全不全、召回准不准、答案忠不忠于资料、回答有没有答非所问，再配上人工抽查和线上反馈。

二十四、总结与参考资料

回顾整个模块，RAG 的价值可以浓缩成一句话：不动模型，只把对的资料在对的时机递给它。三代范式（Naive → Advanced → Modular）是这条链路不断加控制的过程，预检索与后检索是控制的具体手段，RAGAs 四指标是判断有没有变好的标尺，而 RAG 与微调的取舍、框架与向量库的选型，则决定了这套方案能不能真正落到业务里。

如果你只想带走三件事，那就是：先跑基线再迭代、切分与精排决定召回上限、没有评测就没有优化。把这三条落实到自己的项目里，比记住任何一个具体算子都更有价值。

24.1 官方文档与项目地址

• RAG 原始论文：Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks（Lewis et al., 2020），NeurIPS，是理解 RAG 设计动机的起点。

• RAGFlow：github.com/infiniflow/ragflow，官方文档见 ragflow.io/docs，主打深度文档理解，Docker 部署与知识库解析流程以官方文档为准。

• LangChain：python.langchain.com/docs，检索器、文本切分器与向量库集成的用法都在这里。

• LlamaIndex：docs.llamaindex.ai，进阶 RAG 算子（SentenceWindow、RouterQueryEngine、SubQuestion 等）的官方实现。

• Chroma：docs.trychroma.com，轻量本地向量库，适合入门跑通链路。

• RAGAs：docs.ragas.io，四大指标的官方定义与评测脚本示例。

• TruLens：trulens.org，反馈函数与可视化面板的使用说明。

• BGE 中文向量模型：BAAI/bge-small-zh-v1.5，智源开源中文 embedding，中文场景优先选用。

• Ollama：ollama.com，本地跑 qwen2 等开源模型的便捷方式。

24.2 推荐阅读资料

• RAG 综述：Retrieval-Augmented Generation for Large Language Models: A Survey（Gao et al.），系统梳理 Naive / Advanced / Modular 三代范式，与本模块的章节结构高度对应。

• HyDE：Precise Zero-Shot Dense Retrieval without Relevance Labels，理解"先假设答案再检索"的原始思路。

• FLARE：Active Retrieval Augmented Generation，边生成边检索的代表工作。

• Self-RAG：Learning to Retrieve, Generate, and Critique through Self-Reflection，用特殊 token 把检索决策内化进模型。

• RRF：Reciprocal Rank Fusion 原始论文，理解为什么混合检索只看名次、不看分数。

• LLMLingua：提示词压缩方向，适合关注上下文成本与噪声控制的读者。

• GraphRAG：微软开源项目，实体关系复杂领域的补充方案。

24.3 下一步怎么走

建议按这个顺序推进：先用 RAGFlow 或 Chroma + LangChain 跑通一个最小可用版本，攒二三十个标准问题建立评测集；再用 RAGAs 打出基线分；然后一次只加一个优化（Rerank、查询改写、混合检索），每加一次重新打分。等这条链路走顺了，再进入模块四，把 embedding、重排模型和向量库这三块底座彻底吃透。