RAG 的完整工作流程与文档切分数据怎么进系统切多大才合理作者利威尔xu | CSDN 专栏《RAG 保姆级实战从原理到落地》前言在本专栏第二篇《降低模型幻觉汇总》里咱聊了降幻觉的几种手段重点区分了 RAG 和微调的适用场景。结论是知识频繁更新用 RAG行为风格需要定制用微调RAG 是优先选项。这篇咱把 RAG 的落地细节拆开来讲。一个完整的 RAG 系统到底分几步每一步在干嘛为什么文档切分是坑最多的一步切太大切太小分别有什么后果咱还是老规矩先讲为什么再讲是什么最后讲怎么用。不一上来就塞代码先让你搞懂背后的逻辑。一、RAG 完整工作流程六步鸟瞰说 RAG你脑子里可能已经有一个模糊的印象——把文档扔进去问问题答案出来。但具体分几步每步干嘛很多人在面试时讲不清楚。一个完整的 RAG 流程分六步加载、切分、向量化、存储、检索、生成。为了让你们记住这六步咱用图书馆的比喻来串一遍——加载就是把书搬进图书馆。原始文档各式各样有 PDF、有网页、有 Word你得先把它们统一成能处理的格式这步叫加载。说白了就是把书搬到图书馆的书架上。切分是把厚书拆成索引卡片。一本 300 页的书直接塞进去检索的时候没法精准拿内容得先拆。拆成什么粒度、多大的块这就是文档切分。向量化是给每张卡片编上坐标。把文字变成一串数字向量语义相似的文字在向量空间里距离近。这步叫向量化。存储是把卡片放进书架。向量和原始文本对应起来存好等着被检索。检索是按坐标找卡片。用户问一个问题把问题也转成向量在向量空间里找最相似的文档块。生成是看着卡片写答案。把检索到的文档块和问题一起交给大模型让它基于真实资料生成回答。六步就是这样串起来的。每一步都可以单独优化——加载可以换解析器切分策略可以调向量模型可以换存储可以换向量库检索可以加重排序生成可以调 Prompt。但不管怎么调这六步的框架不会变。面试官可能追问RAG 六步里哪一步最关键答都很关键但如果非要说最容易被低估的是切分。好比图书馆的书架设计——书搬进去了、坐标编好了但如果卡片大小不对检索效果也好不了。切分决定了召回的精度上限后面几步都是在切分划定的范围内优化。二、为什么要切分六步讲完了咱重点聊聊第二步——切分这是本篇最核心的内容。你可能会问为什么要切不切行不行讲真还真不一定行。咱从两个角度把这个道理讲透。先说检索的精度问题。文档太大了一个向量代表的信息太多语义就被稀释了。打个比方你把一整本《经济学原理》转成一个向量用户问什么是 GDP系统检索到的就是这本 500 页的书。500 页的内容塞给模型模型得从里面自己找答案火眼金睛也挑花眼。但如果你把这本书切成 1000 张卡片每张卡片讲一个独立概念什么是 GDP这张卡片可能只有两段话。检索出来的就是这张精准的卡片模型拿着直接答不用在一本书里大海捞针。说白了切分就是把厚书拆成索引卡片——你想让模型找什么就让卡片里有什么。再说上下文的容量问题。大模型的上下文窗口是有限的不是无限塞的。你把一整本书塞进去token 早早就用完了真正有用的信息反而放不下。现在的模型动不动 128K、200K 的上下文听着挺大但你想想一份详尽的产品手册可能有 50 万字一本技术文档全集可能有上百万字。上下文再大也塞不下整座图书馆。所以必须挑最相关的片段。切分就是在为这一步做准备——你先拆好检索的时候只拿最相关的几个块进去。面试官可能追问文档切分有没有标准答案答没有标准答案。切多大合适取决于你的文档特点、业务场景、模型上下文窗口。不是越大越好也不是越小越好后面会展开讲。切分策略需要结合实际情况来定没有一劳永逸的配方。三、切太大有什么问题好咱先说切太大有什么坑。你把文档切得很大比如每块 5000 字、8000 字听起来一次性塞进去的信息很多但问题也跟着来了。最直接的问题是语义稀释。一块 5000 字的文档可能讲了三个不同的主题。转成向量的时候这三个主题的语义全混在一起变成一个四不像的向量。你问它关于 A 主题的问题它检索出来的块里 A 的语义被 B 和 C 稀释了相似度分数看着不低实际上答非所问。接着是噪声增加。检索回来的内容里大部分是无关的。一块 5000 字里边可能只有 200 字跟你问的问题真正相关剩下 4800 字全是噪声。模型看到这么多无关内容容易被带跑生成的答案里掺进去一些似是而非的东西。还有 token 浪费。上下文窗口是稀缺资源。你把一大块无关内容塞进去真正有用的信息反而放不下了。好比你去超市买东西推车里塞了一堆用不上的东西真正要买的东西反而装不下。用切菜来比喻一块太大的肉炒的时候外面焦了里面还生火候进不去。你得把肉切成合适的大小每块都能均匀受热。做菜的人都知道肉切多大块、丝切多细是有讲究的不是越大越豪气。面试官可能追问切太大导致的语义稀释具体怎么理解答一个向量本应代表一个主题切太大后多个主题混在一起向量表示不精准。你问什么是 GDP模型检索出来的块里 GDP 的语义被通货膨胀、财政政策稀释了相似度分数看着不低实际上答非所问。这就是语义稀释——向量不纯粹了检索出来的东西看着相关、细看不对。四、切太小有什么问题说完切太大咱再说切太小。你把文档切得很碎比如每块 50 字、100 字看起来精准了但问题比切太大还隐蔽。最明显的问题是上下文碎片化。一个完整的逻辑被拆成好几块每块单独看都不完整。你拿到一段话的开头看不到结尾拿到结尾看不到开头。模型读到的就是半截子信息没法理解完整的意思。举个例子。用户问请详细解释一下你们公司的退款政策结果检索出来的三块分别是退款政策第一条、“退款政策第三条”、“退款政策第五条”。第一条和第三条之间还有第二条单独看每一块都读得通放在一起却漏掉了关键的时间限制条款。模型答出来的退款政策是不完整的。再一个是语义断裂。模型拿到半句话没法理解答案不完整甚至答偏。你问怎么申请退货检索出来的是请填写退——后面被切走了模型只能猜你要填什么。还有个问题是检索召回碎片。同一个问题的答案分散在多块里检索只能命中其中一块。比如退货流程答案分散在退货条件、“退货步骤”、“退货地址三块里你检索怎么退货”可能只命中退货条件模型只能告诉你能退但不知道怎么退。用拼图来比喻你把拼图拆得太碎每一片单独看都不知道是什么。拿到一块红色你说这可能是天空其实是国旗的一角。拼起来才完整但检索只能拿碎片碎片的信息是残缺的。面试官可能追问切太小和切太大哪个更麻烦答两害相权切太小更难救。切太大是检索不准模型还能从大块里自己找相关部分信息虽然散但还在。切太小是上下文不完整模型拿到的信息本身就是残缺的补都补不回来。你拿到半句话模型只能猜后半句猜错比漏答更麻烦。所以切太小比切太大更难救切分的时候宁可稍大一点也别切太碎。五、切分的本质是平衡把刚才说的收拢一下——切太大检索不准、噪声大、token 浪费。切太小上下文碎片化、语义断裂、召回不完整。切分的本质是在检索精度和上下文完整性之间找平衡。你可能会问那到底切多大合适说白了没有标准答案。取决于三件事你的文档有多长、你的文档结构是什么样的、你的业务场景需要多细粒度的回答。一份简短 FAQ每条 FAQ 可能就一两句话切成 50 字太碎了切成 200 字刚好。一份长篇技术文档章节之间逻辑严密切太小会破坏结构可能 500 字、800 字一块更合适。一份法律合同条款之间有关联也有独立切的时候要照顾句子完整性不能硬切。这就是为什么切分是坑最多的一步——它不像加载有标准工具不像向量化有成熟模型切分策略需要你自己摸索、评估、调优。没有银弹只有实践。为什么放这段代码让你们看看切分函数的基本形态理解输入输出是什么。// 文档切分函数输入原始文档输出切片列表funcsplitDocument(docstring,chunkSizeint,overlapint)[]string{chunks:[]string{}start:0forstartlen(doc){end:startchunkSizeifendlen(doc){endlen(doc)}chunksappend(chunks,doc[start:end])startstartchunkSize-overlap// 滑动窗口}returnchunks}这段代码在干嘛这是个固定长度切分的示例按chunkSize切块相邻块之间有overlap个字符的重叠。输入一整段文本输出一组切片。实际生产中要按段落、按语义切这段只是展示基本思路。为了代码清晰这里省略了常规的错误处理和相关逻辑实际生产代码中务必加if err ! nil判断。六、常见切分策略说完切分的本质咱聊聊常见的切分策略。最省事的是按固定长度切。最简单按字符数或者 token 数一刀切。比如每 500 个字符切一块。这种方法简单粗暴好实现但缺点也很明显——可能在句子中间硬切语义被破坏。适用场景文档结构不复杂、对语义完整性要求不高的简单文本比如日志、聊天记录。更讲究一点的是按段落切。以段落为边界切一个段落一块。段落本身就是语义相对完整的单元在段落边界切不会破坏语义完整性。适用场景结构化文档比如文章、报告、新闻稿。段落本身就是自然边界。质量最高的是按语义切。用模型判断哪里该切——语义相近的内容放一块语义变化了就开始新的一块。这种切分质量最高但成本也最高需要额外调用模型来判断语义边界。适用场景对精度要求极高的场景比如法律文书、医疗报告语义完整性直接影响回答质量。不管用哪种策略都可以加上重叠窗口。不管用哪种切分策略相邻两块之间留一段重叠。重叠的部分防止关键信息刚好被切在边界上两边都拿不到完整信息。举个例子。你问请解释第三段的退货政策结果第三段被切在两块里一块的结尾是退货需在下一块的开头是30天内申请。单独看哪一块都读不通但两块重叠的区域里有完整的退货需在30天内申请。有了重叠窗口这个问题就解决了。重叠窗口为什么需要因为切分边界是人为划的不一定跟语义边界重合。重叠就像保险丝防止关键信息被一刀切坏。面试官可能追问重叠窗口大小怎么定答一般取切块大小的 10% 到 20%。比如每块 500 字重叠 50 到 100 字。太大浪费存储和计算太小可能兜不住边界问题。没有绝对标准可以先按 15% 来然后根据实际效果调。为什么放这段代码展示切太大和切太小两种切分结果长什么样。// 切分结果对比切太大 vs 切太小orig:退货政策需在30天内申请退货商品需未拆封退货流程第一步联系客服第二步填写表单// 切太大整句塞进一块噪声多chunksBig:[]string{退货政策需在30天内申请退货商品需未拆封退货流程第一步联系客服第二步填写表单,}// 一块包含所有内容检索退货流程时把政策条件也带进来了// 切太小硬切成三截语义断裂chunksSmall:[]string{退货政策需在30天内申请退货商品需未拆封退货流程第一步,联系客服退货流程第一步联系客服第二步填写表单,第二步填写表单,}// 第一步联系客服被拆到三块里单独看哪块都不完整这段代码在干嘛对比两种切分策略的结果。切太大chunksBig把所有信息塞进一块检索时噪声多切太小chunksSmall在任意位置硬切语义被破坏。实际切分要找平衡点不是越大越好也不是越小越好。为了代码清晰这里省略了常规的错误处理和相关逻辑实际生产代码中务必加if err ! nil判断。值得一提的是目前比较新的做法是可以让agent智能切割感兴趣的同学可以自己了解一下具体做法本篇文章不详细讲解。七、落地常见坑先提一嘴趁这块地盘先给你们打几剂预防针后面第六篇会专门展开。最常见的坑是切分长度拍脑袋定。上来就设 500 字、1000 字不看文档结构、不看业务场景、不做评估调参全靠玄学。还有个坑是不考虑文档结构。PDF 有标题层级Word 有段落标记直接按字符数硬切全拆没了。结构信息是语义的天然边界扔掉可惜。第三个坑是不用重叠窗口。以为切分边界刚好就是语义边界结果检索的时候发现关键信息被切成两半哪块都拿不完整。最后一个坑是切完不评估检索效果。切分策略调了但不知道怎么评估改完是变好了还是变差了。后面第六篇会讲怎么建评估集、怎么量化检索质量。 本章面试要点RAG 完整流程分哪六步加载把原始文档转成可处理格式、切分把长文档拆成小块、向量化把文字转成数字向量、存储向量和文本对应存好、检索用向量相似度找相关文档块、生成把检索结果和问题交给模型生成回答。六步框架不会变每步都可以单独优化。文档为什么要切分本质原因是什么两个原因检索精度文档太大语义被稀释检索不准和上下文容量大模型上下文有限不能无限塞。切分的本质是在检索精度和上下文完整性之间找平衡。切太大检索不准切太小上下文碎片化没有标准答案取决于文档特点和业务场景。切太大会导致什么问题三个后果语义稀释一块代表太多主题向量不精准、噪声增加检索回来的内容大部分无关模型容易被干扰、token 浪费上下文窗口被无关内容占满有用信息放不下。比喻一块太大的肉炒的时候外面焦了里面还生火候进不去。切太小会导致什么问题三个后果上下文碎片化完整逻辑被拆成好几块单独看都不完整、语义断裂模型拿到半句话没法理解答案不完整甚至答偏、检索召回碎片同一问题的答案分散在多块检索只能命中其中一块。比喻拼图拆太碎每一片单独看不知道是什么。常见切分策略有哪些重叠窗口为什么需要四种策略按固定长度切简单但破坏语义、按段落切尊重自然边界、按语义切质量最高但成本高、带重叠窗口切防止边界信息丢失。重叠窗口是保险丝因为切分边界不一定跟语义边界重合有了重叠关键信息被切在边界上也能兜住。下篇预告第四篇《向量与向量数据库文字怎么变成可计算的数字》咱会深入讲 RAG 的第三步和第四步——向量化是什么、向量数据库怎么选、向量检索的原理是什么。为什么语义相似就能被检索到欧氏距离和余弦相似度有什么区别向量数据库里存的是什么如果这篇文章帮你搞懂了 RAG 流程和文档切分欢迎点赞、收藏、关注利威尔xu咱们下篇见。你们项目中文档切分用的什么策略踩过什么坑评论区聊聊。