Dify学习笔记 03 · RAG检索增强生成：三代范式、评估与落地（第40-45、55-56集）

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

一、可视化导览
[二、视频清单（8 集 · 约 2.2 小时）](#二、视频清单（8 集 · 约 2.2 小时）)
[三、RAG 解决什么 · 四步流程 · RAGFlow](#三、RAG 解决什么 · 四步流程 · RAGFlow)
[四、第一代：Naive RAG（朴素版）](#四、第一代：Naive RAG（朴素版）)
[五、第二代：Advanced RAG（进阶版）](#五、第二代：Advanced RAG（进阶版）)
[六、第三代：Modular RAG（模块化）](#六、第三代：Modular RAG（模块化）)
[七、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。
建知识库后必须手动点"解析"，系统才会真正对文档做切块、向量化、入库------只上传不解析等于没有索引。

bash 复制代码

# 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、上手最简单。

bash 复制代码

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

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

python 复制代码

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）。名次越靠前贡献越大，多榜都命中的文档排名显著上升。

python 复制代码

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 评估四件套

**指标：**定义要衡量的维度；
**测试数据集：**标注好的问答对（问题、参考答案、相关文档）；
**自动化工具：**RAGAs、TruLens、LlamaIndex 评估、LangSmith、DeepEval、Phoenix；
**用户反馈 / AB 测试：**线上真实效果回流。

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

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

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

python 复制代码

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、重排模型和向量库这三块底座彻底吃透。

Dify学习笔记 03 · RAG检索增强生成：三代范式、评估与落地（第40-45、55-56集）

目录

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

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

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

一、可视化导览

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

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

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

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

3.1 五个痛点

3.2 四步流程

3.3 RAGFlow 实操要点

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

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

5.1 预检索（Pre-retrieval）

5.2 后检索（Post-retrieval）

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

5.4 HyDE 为什么能改善召回

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

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

环形 flow 的四种代表

七、RAG 评估

7.1 评估四件套

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

八、行业落地与选型

8.1 RAG 还是微调

8.2 框架与向量库选型

8.3 调优要点与六大场景

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

8.5 六大场景背后的共性

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

九、核心概念速查表

十、学习打卡

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

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

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

11.3 实战中的常见误区

十二、延伸练习

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

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

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

十六、面试常考问题速记

二十四、总结与参考资料

24.1 官方文档与项目地址

24.2 推荐阅读资料

24.3 下一步怎么走