ARTICLE · 988495
一文讲透 RAG:从文档分块到检索生成的完整链路
点击上方蓝字关注我们
假设你是一家公司的技术负责人，老板丢给你一句话：把公司那三千份产品文档做成一个 AI 问答机器人，让销售随时能问。
你的第一反应可能是：这有什么难的？把文档丢给大模型不就行了？
然后你会收到教训。文档一多，模型记不住，答非所问；就算记住，也只会"背"，不会"找"；你问它"上个月版本更新了什么"，它开始一本正经地编。
这时候就该 RAG 出场了。
RAG 的全称是 Retrieval-Augmented Generation，检索增强生成。名字很绕，但本质上它是一条知识加工流水线：让大模型在回答之前，先去你的文档堆里"翻资料"，翻到相关内容再开口。
这篇文章，我带你沿着这条流水线从头走到尾。五个工位：文档解析 → 分块 → 向量化 → 检索 → 生成。每到一个工位，我讲讲它干什么、容易在哪里翻车、有什么实操技巧。走完这一趟，你就能自己搭一条能用的 RAG 链路了。
工位一：文档解析——先把"纸"变成"字"
流水线的第一站，是把你的三千份文档喂进系统。但这里有个很多人忽略的问题：文档不是文字。
PDF 可能是扫描件，里面是一张张图片；Word 里有表格、有页眉页脚；PPT 里的字在文本框里；Excel 里的数据躺在单元格里。你直接把 PDF 丢给模型，它看到的是"乱码"或者"一堆图片"。
所以第一步是把各种格式转成干净的纯文本，这个过程叫文档解析（Parsing）。工具上，简单场景用 pypdf、pdfplumber 这类库就够；复杂场景（扫描件、表格密集的文档）得上 OCR 和版面分析，比如 PaddleOCR 或者商用解析服务。
这里的坑：解析质量直接决定后面所有环节的上限。一个常见的悲剧是——表格被解析成一行行粘连的文字，关键词全乱；页眉页脚混进正文，检索时匹配到一堆"某某公司内部资料"。
实操建议：解析完做一次抽检，肉眼扫 20 页，看看表格、公式、多栏排版有没有坏。宁可解析慢一点，也别把脏数据喂给下游。
工位二：分块——把文档切成一口能吃下的量
解析完，你拿到的是动辄几十页的纯文本。问题来了：模型处理文本有长度上限（上下文窗口），你不能把整个文档一次性塞进去，也没必要——回答"这款产品支持哪些接口"只需要文档里的几段话。
所以要把长文本切成一个个小块（Chunk），检索的时候按块召回。这就是分块（Splitting）。
分块看着简单，切不好直接翻车。两种常见的切法：
固定长度切：比如每 500 个字符一刀切。简单粗暴，但经常把一句话、一个表格、一段逻辑从中间劈开。检索时命中半句话，模型靠猜补全，答案自然不靠谱。
语义切：按段落、标题层级、语义边界来切。效果更好，但实现复杂一些，需要用到一些判断逻辑（比如检测标题、按 Markdown 结构切）。
这里的坑：分块大小要跟你的场景匹配。块太小，上下文信息不足，模型"看不见全局"；块太大，检索召回一堆不相关的内容，还浪费 token。
两种切法的差异，看这张图最直观：
实操建议：块大小可以先从 300-500 字试起，配合 50-100 字的重叠（Overlap）——让相邻块之间保留一点公共部分，防止关键句恰好被切在边界上。多跑几轮测试，看哪个参数下回答最稳。
这里还有一个很多人忽略的细节：分块不是"切完就完了"，而是要和下游的向量化、检索一起调。比如，如果你用的是 200 字的小块，那么检索时一次给模型的"资料条数"就要相应多一些（比如 8-10 块），才能保证上下文完整；如果你用 800 字的大块，可能 3-4 块就够了。块大小和召回数量是一对要一起调的参数，单独调任何一个都容易失衡。
工位三：向量化——把文字翻译成"坐标"
分好块之后，下一步是让这些文本块变得"可被搜索"。但搜什么？怎么搜？
直接做关键词匹配？"汽车"和"车辆"是两个词，关键词搜不到，语义上却是同一个意思。所以我们需要把文字转成一种能表达"语义相似度"的形式。
这就是向量化（Embedding）：用一个嵌入模型，把每段文本转换成一串数字（比如几百维的向量）。意思相近的文本，向量在空间里就挨得近。这是整个 RAG 里最核心的一个跃迁——文字从"字符串"变成了"坐标"。
向量化之后，把每个文本块和它的向量一起存进一个专门的数据库，也就是我们常说的向量数据库。这一步通常叫"建索引"。
这里的坑：嵌入模型选错了，效果天差地别。中文场景硬用英文模型，语义理解一塌糊涂；通用模型面对专业术语（医疗、法律、代码），相似度计算会跑偏。
实操建议：优先选对中文支持好的嵌入模型（如 bge、m3e 等开源模型或对应的 API）。另外，向量化之后一定要做一次抽样验证——拿几个真实问题去检索，看看召回的块到底相不相关。很多团队在这步偷懒，最后上线才发现"检索到的全是无关内容"。
顺带说说嵌入模型的选型细节，这是新手最容易忽略的地方：
维度不是越高越好。嵌入模型输出的向量维度有 128 维、768 维、1024 维、1536 维不等。维度高，表达能力理论上更强，但存储和计算成本也更高。对绝大多数文档问答场景，768 维左右已经够用，不必盲目追求高维。
中文和英文要分开选。有些模型英文表现很好，中文却一般；也有专门优化中文的模型。如果你的语料中英混杂，优先选多语言模型（如 bge-m3），它会比单一语言模型稳定。
嵌入模型和生成模型是两回事。生成模型（ChatGPT 这类）用来"答"，嵌入模型用来"找"。很多人只关注生成模型强不强，却随便挑了个嵌入模型，结果检索召回质量上不去，怎么调都没用。记住：RAG 里嵌入模型的质量，决定检索的天花板。
最后给一个判断嵌入模型好坏的最笨也最有效的办法：选两三个候选模型，各自对同一批测试问题做检索，肉眼对比召回结果。哪个召回的块"看起来最对"，就用哪个。不要只看论文里的 benchmark 分数。
工位四：检索——从知识库里"捞"出相关片段
链路走到这里，终于到了关键时刻。
用户问了一个问题，比如"这款扫地机的尘盒怎么拆？"。系统把这个问题的向量也算出来，然后去向量库里找"离它最近的 N 个文本块"。这 N 个块，就是模型回答时能参考的"资料"。
这一步就是检索（Retrieval）。
但这里有个残酷的现实：单靠向量相似度检索，效果经常不理想。原因在于，向量检索擅长找"语义像"的，但用户问法跟文档写法经常对不上。比如文档里写的是"尘盒拆卸步骤"，用户问的是"怎么清理垃圾"——语义相似度算出来可能并不高。
所以实践中，检索环节往往要加料：
混合检索（Hybrid Search）：向量检索 + 关键词检索（BM25）同时跑，再把结果合并。向量抓语义，关键词抓字面，互补。
重排序（Rerank）：第一次召回 20 个块，再用一个专门的排序模型精排，挑出最相关的 3-5 个。这一步能显著提升精度，但会多花一点时间和成本。
元数据过滤：文档带了分类、时间、部门等标签的话，可以先用标签过滤（比如"只搜产品手册"），缩小检索范围。
这里的坑：只做向量检索、不做任何优化，是最常见的"能用但不好用"的状态。召回质量差，后面模型再聪明也白搭——RAG 的效果上限，基本由检索决定，不由生成决定。
从"只能向量"到"混合检索 + Rerank"，是三个阶段逐步加料的过程：
实操建议：先上"向量 + 关键词"混合检索，再视效果加 Rerank。成本不高，收益明显。
再补充一个容易踩的细节：检索数量不是越多越好。有人觉得"多召回几块给模型参考总没错"，结果一次塞 20 块进上下文，模型反而被大量不相关内容干扰，答出来的东西又长又偏。我的经验是：先召回 20 个候选，Rerank 后只把最相关的 3-5 块交给模型。给得少而精，比给得多而杂效果更好，token 成本还更低。
工位五：生成——让模型"看着资料"回答
资料捞出来了，最后一步是把它交给大模型，让它基于这些资料组织答案。
这一步的关键是提示词怎么写。你要明确告诉模型三件事：
下面这些资料是参考依据；
只能基于资料回答，资料里没有的，明确说"不知道"，不许编；
回答要引用资料出处，方便用户查证。
一个简单的提示词模板长这样：
你是公司的产品助手。请基于下面的资料回答用户的问题。
资料：
[检索到的文本块1]
[检索到的文本块2]
...
用户问题：{问题}
要求：只依据资料回答；资料中没有的信息，回答"资料中未提及"；
回答末尾注明引用的资料编号。
这里的坑：很多人走到这步才发现，前面工位没做好，生成环节再怎么调提示词都救不回来。另外，"不许编"这句一定要写进提示词——大模型天生有"编造倾向"，不约束它，它会一本正经地把你没给它的信息也"推理"出来，这就是所谓的幻觉。
实操建议：生成环节加一个"引用溯源"，让模型在回答里标出依据来自哪份资料。一方面用户能查证，另一方面你也能在后台统计"哪些问题检索不到资料"——这数据反过来帮你优化前面几个工位。
关于 RAG 的四个常见误区
聊完链路，再顺手拆几个网上流传很广的误区，免得你被带偏。
误区一：RAG 只是"给模型塞资料"。
有人觉得 RAG 就是把文档塞进提示词里。这么想会把工程做浅——RAG 的难点不在"塞"，而在"塞哪些、怎么找到最相关的"。检索质量决定了答案质量，这才是 RAG 真正花功夫的地方。
误区二：向量数据库 = RAG。
RAG 是架构，向量数据库只是其中一个可选组件。简单场景用内存里的列表做相似度计算也能跑；反过来，向量数据库本身也可以用在小样本分类、推荐系统等非 RAG 场景。别把两者划等号。
误区三：RAG 上线了就完事。
恰恰相反，RAG 是需要持续维护的系统。文档更新了要重新解析分块，用户问题变了要调整检索策略，回答错了要把失败案例加进评测集。上线只是开始，不是结束。
误区四：有了 RAG 就不需要微调，或者反之。
这两者不是替代关系。RAG 解决"模型不知道的事实"，微调解决"模型不会的能力"。很多生产级系统是两者都用：用 RAG 提供最新知识，用微调让模型学会特定输出风格。具体怎么选，下一篇讲微调时细聊。
链路跑通之后：你还需要做什么
五个工位走完，一条能用的 RAG 链路就通了。但"能用"和"好用"之间，还有三件事要做：
第一，建评测集。 准备 50-100 个真实问题，每个问题配上"期望答案要点"，每次改动链路就跑一遍，看回答质量有没有退化。没有评测集的 RAG 项目，优化全靠感觉，迟早踩坑。
第二，迭代检索策略。 上面说的混合检索、Rerank、元数据过滤，都不是一次配好就完事的。根据评测结果，哪个环节拖后腿就调哪个。
第三，别忘了更新机制。 文档是会变的。产品发了新版、政策有了调整，你得有"重新解析、重新分块、重新向量化"的流程。很多 RAG 项目死就死在——上线那天是最好的状态，之后知识越用越旧。
一个真实案例：一周把 RAG 调到"能上线"
说个我自己的实战案例，帮你建立直觉。
接到一个任务：把公司三千份产品文档做成 AI 问答。第一版上线后，用户反馈"答非所问"。我以为是模型的问题，换了 GPT-4，结果还是一样。
后来拆解才发现，是前面三个工位没做好：
问题一：解析脏。三分之一的 PDF 是扫描件，被 OCR 识别成了乱码，表格全乱了。换成商用解析服务后，问题解决。
问题二：分块太粗。我一开始按 1000 字一刀切，结果用户问"接口在哪里"，模型拿到的是包含接口说明、警告、常见问题的一整页，模型答得对但答得偏。改成 400 字 + 60 字重叠，按段落切分后，问题大幅缓解。
问题三：纯向量检索召回差。用户问"怎么充电"，文档里写的是"充电方法"，字面不匹配但语义很像，纯向量能命中。但用户问"便宜的有哪些"，文档里写的是"价格不高于 1999"，纯向量就抓不到了。加了 BM25 混合检索后，覆盖率从 65% 提到 92%。
这一周踩过的坑，今天写进文章里，希望你跳过。
一张图回顾整条链路
你的文档从左边进，经过解析、分块、向量化变成"可检索的知识"，用户问题从下面进，经过检索捞到相关资料，最后模型看着资料生成答案，从右边出。
这条链路看起来简单，但每个工位都藏着自己的坑。
我把最容易翻车的三个点再敲一遍黑板：
解析不干净，后面全白干；
分块切错，答案断章取义；
只做向量检索不做优化，召回质量上不去，生成再好也白搭。
记住一句话：RAG 做得好不好，七分在检索，三分在生成。
对 AI 深度学习感兴趣的，可以持续关注这个系列。
更多精彩内容
扫码关注我们