RAG 这个词这两年出现的频率太高了高到很多人一上来就问用哪个向量数据库要不要上 Milvus但真正把一条链路从头搭到尾、并且能稳定跑起来的人其实没那么多。我自己前前后后搭过七八套不同规模的知识库系统从个人笔记到几十万份文档的企业级场景都趟过一遍踩的坑足够写一本小册子。这篇就把 RAG 知识库从文档入库到检索召回的完整链路拆开讲重点放在那些文档里不会写、但实际跑起来一定会遇到的问题上。如果你正在准备搭自己的第一个 RAG 知识库或者已经搭了一个但效果总是不理想——召回不准、答非所问、文档一多就崩——那这篇内容应该能帮你省下不少试错时间。我会尽量把每个环节为什么这么做讲清楚而不是只丢一堆配置让你抄。1. 先想清楚 RAG 到底在解决什么问题1.1 大模型本身的三道硬伤很多人对 RAG 的理解停留在给大模型外挂一个知识库这个说法没错但太粗糙。要真正搭好一套系统得先明白大模型到底缺什么。第一道硬伤是知识截止。任何模型都有训练数据的截止时间之后发生的事情它一概不知。你问它某个新发布的框架怎么用它要么编要么说不知道。第二道硬伤是私有知识缺失。公司内部的文档、个人的笔记、某个垂直领域的专业资料这些从来没进过训练集模型不可能知道。第三道硬伤是幻觉。就算模型知道某个知识点它也可能一本正经地胡说八道尤其是在细节参数、数字、专有名词上。这三道硬伤里前两个靠 RAG 能直接解决第三个能大幅缓解——注意是缓解不是根治这点后面会细说。RAG 的核心思路其实很朴素既然模型不知道那就在提问的时候把相关资料一起塞给它让它看着材料答题。这就像开卷考试模型是考生你的知识库就是那本可以翻的书。关键在于——你得保证翻到的是正确的那一页。1.2 一条完整链路包含哪些环节一套能用的 RAG 系统绝不是文档丢进去、问题问出来这么简单。完整链路至少包含这几个环节文档解析把 PDF、Word、Markdown、网页等各种格式统一转成纯文本文本切分把长文档切成适合检索和喂给模型的小块向量化用 Embedding 模型把文本块转成向量向量存储把向量存进数据库并建立索引查询处理把用户问题也向量化并做必要的改写检索召回从库里找出最相关的若干文本块重排序对召回结果做二次精排上下文组装把检索结果拼成 Prompt 喂给大模型生成回答模型基于上下文输出答案这九个环节里任何一个掉链子最终效果都会崩。我见过太多人只盯着用哪个向量数据库结果文档切分一塌糊涂再好的库也救不回来。1.3 什么场景适合上 RAG什么场景别硬上不是所有需求都适合 RAG。判断标准很简单你的知识是不是经常变、是不是私有的、是不是量大到塞不进 Prompt。如果知识是静态的、量很小比如就几页纸直接写进 System Prompt 就行没必要搞一套 RAG。如果知识需要精确计算、需要实时查询数据库那应该用 Function Calling 或 Agent 去调工具而不是 RAG。RAG 最擅长的场景是大量非结构化的、语义相关的、需要理解而非精确匹配的文本知识。举个反例有人想用 RAG 做订单查询问我上个月的订单到哪了。这种需求本质是结构化查询应该走 SQL硬套 RAG 只会又慢又不准。搞清楚边界比盲目上技术重要得多。2. 文档解析与切分决定成败的隐形环节2.1 解析阶段最容易被低估的坑大部分人搭 RAG 的第一步就是找向量数据库但真正决定效果上限的其实是文档解析。我踩过最惨的一次坑是一批 PDF 文档解析出来全是乱码——表格错位、公式丢失、页眉页脚混进正文。向量化之后检索出来的内容驴唇不对马嘴排查了两天才发现是解析环节的问题。不同格式的文档解析难度天差地别。纯文本和 Markdown 最好处理直接读就行。Word 相对简单用 python-docx 之类的库能拿到结构化内容。PDF 是重灾区尤其是扫描件、多栏排版、含大量表格的文档。网页则要处理导航栏、广告、评论区这些噪音。我的经验是解析阶段宁可多花时间也不要指望后面能补救。垃圾进垃圾出这句话在 RAG 里体现得淋漓尽致。2.2 不同格式文档的解析策略针对常见格式我整理了一套实际用下来比较稳的策略文档类型推荐工具关键注意点Markdown/TXT直接读取保留标题层级作为切分依据Wordpython-docx注意表格和图片图片需单独 OCR电子版 PDFPyMuPDF、pdfplumber多栏排版要按栏切分别按行扫描版 PDFOCR 工具 版面分析先做版面分析再 OCR准确率翻倍网页正文提取库去掉导航、广告、页脚Excel/CSVpandas每行转成一段自然语言描述这里重点说 PDF。电子版 PDF 用 PyMuPDF 提取文本速度快但对复杂版面支持一般pdfplumber 对表格支持更好但慢一些。我的做法是先用 PyMuPDF 快速提取检测到表格密集的页面再切到 pdfplumber 精细处理。扫描版 PDF 必须走 OCR但直接 OCR 效果往往很差因为 OCR 引擎不知道哪里是标题、哪里是正文、哪里是表格。正确做法是先做版面分析识别出文本块、表格块、图片块再分别处理。这一步做得好后面检索准确率能提升一大截。2.3 切分粒度不是越小越好也不是越大越好文本切分是 RAG 里最玄学的环节之一。切太大一个块里混了好几个主题检索时噪音大切太小语义不完整模型拿到半句话也答不出东西。常见的切分策略有这么几种固定长度切分按字符数或 token 数硬切简单粗暴但容易把一句话切断按标点切分按句号、换行切语义相对完整但块大小不均匀递归切分按段落→句子→词的优先级递归切兼顾语义和大小语义切分用模型判断语义边界效果最好但最慢最贵按结构切分利用文档本身的标题层级切最适合结构化文档我实际用下来递归切分 结构切分结合是最稳的方案。具体来说先按文档的标题层级切出大块如果某个大块还是太长再用递归切分往下切。这样既保留了文档的语义结构又控制了单块大小。块大小方面我的经验值是300 到 800 个 token具体看内容密度。技术文档信息密度高可以小一点叙述性内容可以大一点。另外一定要设置overlap重叠一般取块大小的 10% 到 20%防止关键信息正好卡在切分边界上被切断。提示切分参数没有万能值一定要拿你自己的文档做小批量测试看检索效果再调。别人说的最佳实践只能当起点。2.4 元数据被 90% 的人忽略的检索利器切分的时候很多人只存文本内容把元数据全丢了。这是个巨大的浪费。元数据包括文档标题、来源、章节、页码、创建时间等等它们在检索和生成阶段都能派上大用场。举个例子用户问最新的报销政策是什么如果你的块里带了时间元数据就能在检索时优先召回最新的文档而不是三年前的旧版本。再比如用户问某个具体章节的内容带章节元数据就能精准定位。我的做法是每个块都带上这几个字段source来源文件、title文档标题、section所属章节、chunk_index块序号、timestamp时间。存储成本几乎可以忽略但检索时的灵活性提升明显。后面讲混合检索和重排序时这些元数据会发挥关键作用。3. 向量化与向量数据库选型3.1 Embedding 模型怎么选向量化的核心是 Embedding 模型它决定了文本被映射到向量空间后的语义质量。选模型主要看三个维度语言支持、维度、性能。中文场景下我实测过几个主流方案。有些模型对中文语义理解好有些则在多语言上更均衡。维度方面常见的有 768、1024、1536 等维度越高表达能力越强但存储和计算成本也越高。性能则要看你的吞吐需求是离线批量处理还是在线实时查询。选型时有个容易被忽略的点查询和文档必须用同一个模型。我见过有人文档用一个模型向量化查询用另一个结果检索效果惨不忍睹。这个错误听起来低级但实际项目中真的有人犯。另外如果你的场景对延迟敏感可以考虑用更小的模型如果对准确率要求极高可以用大模型甚至用多个模型做集成。没有绝对的好坏只有适不适合。3.2 主流向量数据库横向对比向量数据库这两年卷得厉害Milvus、Chroma、Qdrant、Weaviate、pgvector 各有拥趸。我整理了一张对比表基于实际使用体验数据库部署难度适用规模突出优势主要短板Chroma极低小规模/原型上手快Python 原生大规模性能一般Qdrant低中小规模过滤检索强Rust 性能好生态相对小Milvus中高大规模功能全扩展性强部署运维复杂pgvector低中小规模复用现有 PG事务友好超大规模吃力Weaviate中中小规模内置模块多资源占用偏高选型的核心原则是匹配你的实际规模。个人项目、原型验证Chroma 足够了几行代码就能跑起来。中小规模生产环境Qdrant 或 pgvector 是性价比之选。真到了千万级向量、需要分布式扩展再考虑 Milvus。我特别想说的是别一上来就上 Milvus。很多人被大规模三个字唬住结果为了几万条数据搭了一套 Milvus 集群运维成本远超收益。技术选型要克制够用就好等真的撑不住了再迁移也不迟。3.3 索引类型与检索参数调优向量数据库建索引时会面临一个经典权衡检索速度 vs 召回精度。以常见的 HNSW 索引为例它有几个关键参数M每个节点的连接数越大精度越高但内存占用越大efConstruction建索引时的候选集大小越大索引质量越高但建得越慢efSearch查询时的候选集大小越大召回越高但越慢这几个参数的调优逻辑是建索引时可以慢一点、精细一点efConstruction调大查询时要平衡延迟和召回efSearch从默认值开始往上调直到召回率满足要求。我的实操建议是先用默认参数跑通然后拿一批标注好的问题-正确答案测试集逐步调efSearch观察召回率变化。通常efSearch调到 64 到 128 之间就能覆盖大部分场景。别盲目追求 100% 召回那意味着你要扫描全库延迟会爆炸。注意索引参数和你的数据分布强相关别人的最优值在你这里未必最优。一定要用自己的数据实测。4. 检索策略从能查到到查得准4.1 纯向量检索的天花板在哪很多人以为向量检索是万能的其实它有明显的短板。向量检索擅长语义相似但对精确匹配很弱。比如用户问CLSID 为 000209FF 的组件是什么向量检索可能召回一堆讲 COM 组件的文档但就是找不到那个精确的 CLSID。再比如专有名词、产品型号、错误码这些精确信息向量检索经常抓瞎。还有一个问题是关键词权重。向量检索把整句话编码成一个向量重要的关键词和无关的虚词被同等对待。用户问Milvus 和 Qdrant 的区别向量可能更关注区别这个语义而忽略了MilvusQdrant这两个关键实体。所以纯向量检索适合做初筛但要真正查得准必须引入其他手段。4.2 混合检索向量 关键词双管齐下混合检索的思路是向量检索负责语义召回关键词检索如 BM25负责精确召回两路结果融合。这样既能抓住语义相关的内容又不会漏掉精确匹配的关键词。融合两路结果常用RRFReciprocal Rank Fusion倒数排名融合。它的逻辑很简单对每个文档把它在两路结果中的排名取倒数再相加得到最终分数。排名越靠前分数越高。RRF 的好处是不需要归一化两路分数直接基于排名融合鲁棒性很好。实际配置时我一般两路各召回 20 到 50 条融合后取前 10 到 20 条进入下一步。关键词检索用 BM25 就够如果数据库原生支持全文索引比如 pgvector 配合 PG 的全文检索直接用现成的。混合检索的效果提升是立竿见影的。我做过对比测试在包含大量专有名词的技术文档场景下混合检索的召回率比纯向量检索高出 20% 到 30%。这个提升幅度值得你多写那几十行融合代码。4.3 查询改写让用户的问题更好检索用户提的问题往往不适合直接检索。有的是口语化表达有的是多轮对话里的省略句有的包含指代。直接拿这种问题去检索效果自然差。查询改写就是解决这个问题的。常见手段有几种指代消解把它这个替换成具体实体需要结合对话历史查询扩展给原问题补充同义词、相关词扩大召回查询分解把复杂问题拆成几个子问题分别检索HyDE让模型先生成一个假设性答案用答案去检索而不是用问题HyDE 这个思路挺巧妙。因为问题和答案在向量空间里的分布往往不一样用问题检索可能找不到答案但用假设的答案检索命中率会高很多。代价是多一次模型调用延迟增加。我的建议是查询改写按需启用。简单问题不需要改写多轮对话和复杂问题才值得。别为了炫技给每个查询都加一堆处理延迟上去了用户体验反而差。4.4 重排序把最相关的顶到最前面检索召回了一批结果但它们的排序未必最优。向量相似度高不代表真的相关这时候就需要重排序Rerank。重排序用的是 Cross-Encoder 模型它把问题和每个候选文档一起输入直接输出相关性分数。相比向量检索的双塔结构问题和文档分别编码Cross-Encoder 能看到问题和文档的交互精度高得多。代价是慢因为它要对每个候选都跑一次模型。所以标准流程是向量检索粗召回快召回多→ 重排序精排慢精度高。粗召回取 50 到 100 条重排序后取前 5 到 10 条喂给大模型。重排序带来的提升非常明显尤其是在候选文档质量参差不齐的时候。我实测下来加了重排序之后最终答案的准确率能提升 15% 到 25%。如果你的场景对准确率要求高重排序几乎是必选项。5. 上下文组装与生成最后一步别翻车5.1 检索结果怎么塞进 Prompt检索出一堆文本块怎么组装成 Prompt 也是有讲究的。最朴素的做法是把所有块拼起来但这样有几个问题块之间可能重复、可能矛盾、可能超出模型上下文窗口。我的组装策略是这样的先按相关性排序从高到低依次加入直到接近上下文窗口上限留出回答的空间。每个块前面加上来源标注比如【来源XX文档 第X节】这样模型引用时能说清楚出处用户也能追溯。块之间用明确的分隔符隔开避免模型把不同块的内容混在一起。如果块之间有明显矛盾可以在 Prompt 里提示模型注意甄别或者干脆只保留最相关的那几个。提示上下文不是塞得越多越好。塞太多无关内容模型反而容易被干扰还会增加成本和延迟。质量比数量重要。5.2 让模型基于材料回答而不是自由发挥RAG 最大的价值是让模型基于给定材料回答但模型天生有自由发挥的倾向。如果 Prompt 写得不好它可能无视你给的材料凭自己的记忆瞎答。所以 Prompt 里必须明确约束。我常用的模板大意是只根据下面提供的资料回答问题如果资料里没有相关信息就明确说根据现有资料无法回答不要编造。这句话看着简单但能大幅降低幻觉率。另外可以要求模型引用来源。让它回答时标注信息来自哪个块一方面方便用户核实另一方面也逼着模型真的去看材料而不是凭记忆答。还有一个技巧是先让模型复述关键信息再回答。比如让它先列出资料中与问题相关的要点再基于要点作答。这样能强迫模型真正理解材料减少跳步。5.3 多轮对话里的上下文管理单轮问答好办多轮对话就复杂了。用户第二句可能用它那个指代上一句的内容检索时如果不带上历史根本不知道在问什么。我的做法是维护一个对话历史每次检索前先用模型把当前问题改写成自包含的完整问题把指代补全再拿改写后的问题去检索。这样检索的准确率会高很多。但历史也不能无限带。带太多历史一是占上下文二是可能引入无关信息干扰。我一般只保留最近 3 到 5 轮更早的做摘要压缩。这个平衡点需要根据实际场景调。6. 那些文档里不会写的实战经验6.1 效果不好时按这个顺序排查RAG 效果差原因可能出在链路的任何一环。我总结了一套排查顺序从后往前查效率最高先看检索结果把召回的块打印出来看是不是真的相关。如果不相关问题在检索环节再看切分如果检索结果里信息是残缺的问题在切分再看解析如果切分出来的文本本身就是乱的问题在解析最后看生成如果检索结果没问题但答案还是错问题在 Prompt 或模型这个顺序的逻辑是从最接近输出的环节往前查因为后面的环节依赖前面的结果前面错了后面必然错。很多人一上来就怀疑模型不行其实十有八九是检索或切分的问题。6.2 几个提升效果的低成本技巧有些技巧不需要改架构改几行配置就能见效给块加标题前缀把文档标题和章节标题拼到每个块前面检索时能利用上标题信息问题也加前缀比如给查询加上查询意图之类的引导词有时能改善向量质量调整 top_k召回数量不是越多越好找到适合你场景的甜点值过滤低分结果设一个相似度阈值低于阈值的直接丢弃避免噪音这些技巧成本极低但组合起来效果可观。我一般会先试这些不行再动架构。6.3 评估没有评估就没有优化搭完系统不算完你得知道它到底好不好。没有评估优化就是盲人摸象。评估的核心是构建测试集准备一批问题-标准答案对跑系统看输出人工或自动打分。测试集要覆盖各种类型的问题——简单事实、复杂推理、多跳、无答案考验模型会不会瞎编。指标方面检索环节看召回率和命中率生成环节看准确率和幻觉率。有条件的话用模型做自动评估LLM-as-a-Judge效率高很多但要注意评估模型本身的偏差。我的经验是测试集不用多几十条高质量的就行但一定要有代表性。每次改动后都跑一遍看指标变化这样才能知道改动到底有没有用。6.4 成本与延迟的平衡RAG 系统跑起来是要花钱的向量化要钱、检索要钱、重排序要钱、生成更要钱。延迟也是每个环节都加一点用户等的时间就上去了。平衡的思路是分级处理简单问题走轻量链路纯向量检索 小模型复杂问题走完整链路混合检索 重排序 大模型。怎么判断简单还是复杂可以用一个轻量分类器或者根据问题长度、是否多轮等启发式规则。缓存也是省钱利器。高频问题、相同问题的检索结果都可以缓存起来。向量检索的结果缓存尤其有效因为很多用户问的其实是相似的问题。最后说一句RAG 这套东西没有银弹每个环节都要根据你的实际数据和场景去调。别人跑得通的配置搬到你这儿可能就水土不服。多测、多调、多记录慢慢就能摸出适合自己的一套参数。我到现在还在不断调整这本身就是个持续迭代的活儿。