RAG 检索增强生成：完整流水线拆解（不止向量入库）

现在很多 RAG 教程给人的错觉是：把文档上传、分块、存进向量库，就完事了。我一开始也这么以为，结果做出来的东西召回不准、回答失真、幻觉频发，后来才搞明白——向量入库只是整条流水线的中间一环，真正决定效果的，是它前后那些不起眼的环节。

我把完整的 RAG 流水线拆成了五段，每一段都踩过坑，展开说说。

第一段：文档预处理，最容易被忽略的一环

第一段是文档预处理，这步最容易被忽略，但权重最高。真实的业务文档里全是脏东西：页眉页脚、多余空行、广告乱码、重复段落、无效注释。你要是直接分块入库，这些噪声就跟着进去了，检索的时候它们会被当成有效内容混出来，回答质量直接打折。所以预处理必须做：格式清洗、去重降噪、结构化解析、按章节拆分，源头不干净，后面全白搭。

这一步还要注意格式适配：PDF、Word、Markdown、扫描件，每种格式的解析方式都不一样。表格数据尤其麻烦——直接当文本切分，表格的语义结构就全丢了。处理不好，表格类知识问答就是灾难。遇到表格，比较稳妥的做法是转成结构化的 markdown 表格或者 JSON 再入库，别拿原始文本硬切。

第二段：语义分块，别用固定字数硬切

第二段是语义分块。别用固定字数硬切——500 字一刀切下去，语义可能就被切断了，一个完整的观点被拆成两半，检索出来的就是残缺信息。正确的做法是按语义完整性来分：先按标题层级切，再在语义完整的位置断句，保证每个分块都是一个完整的语义单元。

分块大小也是个权衡：切得太小，语义不完整，检索容易漏；切得太大，噪声多，检索不精准。业界常用的做法是"大块检索、小块生成"——检索时用较大的块保证召回，喂给模型时用更小的子块控制噪声。这个细节很多教程都不讲，但它对效果的影响很直接。另外，分块之间可以留一点重叠（overlap），避免"观点正好被切在边界上"的尴尬。

第三段：向量化，存进去只是开始

第三段是向量化。把文本块用 Embedding 模型转成高维向量存进向量库，这一步大家都会，但别以为存进去就万事大吉了。Embedding 模型的选型、向量的维度、相似度度量方式（余弦、内积、欧氏），都会影响检索效果。向量库的选择也很多：开源的 FAISS、pgvector，托管的向量数据库服务，各有利弊——个人项目用 pgvector 甚至够用，别一上来就上重型方案。

选 embedding 模型有个原则：要跟你业务的语言和领域匹配。用中文业务就用中文 embedding 模型，用通用模型处理专业领域，效果会差不少。这是很多人容易踩的坑——一套模型打天下，结果专业术语检索效果一塌糊涂。

第四段：混合检索 + 重排，别只靠向量

第四段是混合检索。单靠向量相似度检索有个毛病——语义相近但词面不同的问题容易漏召回，精确词条匹配反而丢分。我的做法是向量检索和 BM25 关键词检索双路并跑：向量保语义，BM25 保精准词条，两边结果合并去重，再用 Rerank 重排模型对 Top-N 精筛一遍，把低相关的噪声过滤掉，只留下最该给模型看的内容。

这里要说清楚为什么不能只靠向量：向量检索擅长"语义相似"，但不擅长"精确匹配"——用户问"订单号 A123"，如果知识库里有"订单号 A123"，向量检索可能因为句子整体相似度不高而把它排到很后面。混合检索把精确匹配和语义检索互补起来，召回率和精准率才能同时兼顾。Rerank 这一步很多人省掉，但它对最终效果的影响很大——向量排序是"粗排"，Rerank 是"精排"，缺了精排，结果质量上不去。

第五段：生成约束，从机制上防幻觉

第五段是生成约束。Prompt 里强制要求模型只基于检索回来的真实语料作答，资料不足就明确拒答，不编造来源。这一步是从机制上抑制幻觉的关键——不给模型自由发挥的空间。同时还可以配"引用溯源"：让模型在回答里标注引用了哪份资料，用户能点回去核实，也方便人工检查。引用溯源还有个好处：出问题的时候能定位——是哪份资料本身有误，还是模型理解错了。

最后

说到最后，RAG 能不能用，取决于你对整条链路的管控，而不是你用了多高级的向量数据库。把预处理、分块、检索、重排、生成约束这些环节老老实实做扎实，它才从"玩具 demo"变成"能用、可信、少幻觉"的系统。

至于怎么知道每段做得好不好，我在《RAG 量化评测方案》那篇里讲过——用测试集和指标说话，别靠感觉。一句话：RAG 的成功，不在某一个环节有多炫，而在所有环节都足够扎实。