如果你搭过一套RAG系统一定经历过这种状态文档喂进去了、向量存好了、大模型也换成最强的那档了可问出来的答案依然离谱要么答非所问要么漏掉关键细节要么直接把毫无关系的一段话拼进回答里。很多人第一反应是换Embedding模型、换向量库、调Prompt折腾到半夜才发现问题可能出在最不起眼的环节——分块。分块就是把长文档切成一个个小块再向量化的过程英文叫Chunking。它决定了大模型在检索阶段能看到什么、在生成阶段能引用什么。说实话在我看过的绝大多数RAG翻车案例里模型无罪Embedding也无罪真正的锅都在分块策略上。这篇文章我会把一个知识库项目里踩过的坑、试过的方案、定下来的参数从头到尾整理一遍。适合刚接触RAG的小白也适合已经搭好检索链路但效果不理想的人。你不用把每个库的API背下来重点是理解分块的底层逻辑然后带着这些思路去调自己的系统。1. 分块在RAG里的真实地位为什么它才是决定质量的关键1.1 一条RAG流水线里谁才是最脆弱的环节一个常规的RAG系统链路大概是这样的文档加载 → 分块 → Embedding向量化 → 存入向量库 → 用户提问时把问题向量化 → 检索相似块 → 把块拼进上下文 → 大模型生成回答。很多人把注意力放在Embedding模型和向量库选型上这两块当然有影响但它们是“标准化”的。Embedding模型的任务是把语义映射到向量空间向量库的任务是快速找近邻这两个环节只要选型正常上下限不会差太多。真正个性化的、高自由度的、最容易出偏差的步骤是分块。为什么说分块最脆弱因为它直接决定了检索单元的纯度。你切出来的每一块都会成为向量库里的一个独立条目。用户问问题时系统不是在全文里搜索而是在这些预先切好的块里搜索。如果切块切得烂后面的Embedding再强、向量库再快也只能在烂食材里挑菜。我在一个内部文档问答项目里做过一次实验同一份产品手册用默认的固定字符长度切块和按章节结构切块在同样的向量模型和检索参数下准确率差了将近百分之二十五。没有改模型没有改Prompt只改了分块方式效果差距巨大。1.2 先搞懂检索的基本原理向量相似度挽回不了错误的切块想彻底理解分块为什么重要得先弄清楚向量检索到底在做什么。文本向量化之后每段文字变成一串几百维的数字。语义相近的文本向量在空间里靠得近。当你提问时系统把你的问题也向量化然后在库里找最邻近的几个向量也就是语义上最接近的几个块。这里有个关键点向量表示的是“整体语义”不是“部分语义”。假设有一个块长三千字里面讲了五个不同的话题那么它的向量是五个话题混合后的平均状态。用户问第一个话题时这个块只能“沾边”不能精准命中。反过来如果把一篇完整的介绍拆成十几个碎片每个碎片只有一两句话那向量可能学到的只有表面字词特征丢失了上下文逻辑。分块的目标很朴素让每一块内部只讲一个完整的话题同时让每一块独立存在时依然能说清自己在讲什么。这个目标比大多数人想象的难得多因为文本的语义边界不像代码行那样有明确符号。1.3 分块同时伤害检索和生成两个阶段分块的影响是双重的一次操作在两个阶段产生连锁反应。检索阶段块太大向量被稀释相关段落会被淹没在不相关的内容里检索回来的块“相关度”打折扣块太小检索倒是精准了但没有足够的上下文支撑可能只捞回一句孤零零的话失去了前因后果。生成阶段大模型拿到检索回来的块作为参考信息。如果块太大大模型需要在大量无关信息里定位答案容易被带偏还会占用上下文窗口。如果块太小大模型缺少推理所需的背景只能靠自身参数里的知识硬编回答自然不靠谱。我打过一个比方RAG的检索结果就像做菜时准备的配菜。你切肉丝切得太碎下锅一炒就不见踪影口感全无切得太粗咬不动不说还抢占其他食材的空间。分块也是在“切配”只不过切的是文字。想清楚这个类比后面讲参数和策略时很多选择就顺势能理解了。2. 分块到底是什么三种切法的边界逻辑2.1 为什么不把整篇文档直接丢进去直接拿整篇文档去做向量化然后检索时把整篇文档都拉回来行不行理论上可行但实际会出现三个问题。第一个是上下文窗口问题。大模型的上下文窗口有限长篇文档可能装满甚至超出窗口导致没有空间放问题和指令。第二个是检索精度问题。你问“某功能在什么版本开始支持”全文向量会把大量无关段落也算进相似度里噪声太多。第三个是引用问题。回答时你要告诉用户“这个说法来自第几节”但整篇文档无法定位到具体段落回答的出处就变得含糊。我自己试过直接把整本操作手册做成一个向量结果检索返回的永远是一大坨完全相同的向量回答质量跟让模型不带资料硬答区别不大。这不是Embedding模型的问题是对“检索单元”的设计有问题。RAG的本质是让你在以“最小可用语义单位”为基础的粒度上进行检索和引用。整篇文档是最大粒度单字符是最小粒度分块就是在这中间找到一个平衡点。2.2 固定大小分块与结构感知分块分块大体可以分成两派固定大小分块和结构感知分块。固定大小分块就是按字符数或Token数均等切割。这个方案实现最简单但语义中断的风险最高。你永远不知道一刀切下去会不会把一句话从中间劈开或者把一个主题的论述从断言处切成两截。很多库提供了重叠参数来缓解这个问题但重叠解决的是“上下文衔接”解决不了“语义断裂”。结构感知分块是按文档本身的边界来切。比如按Markdown标题、HTML标签、PDF的段落、代码的函数定义来切。这种分块的哲学是作者写文档时已经帮你划好了语义边界你只需要尊重这个边界。这两种不是非此即彼的。一个实际的项目里我通常的做法是先按结构切再对超大块按固定大小二次拆分最后给每个块保留结构信息作为元数据。纯用固定分块适用于那些没有明显结构的文本纯用结构分块则要求文档本身质量够高。2.3 小块更精准、大块更完整的取舍分块粒度的两难是所有RAG实践者的共同课题。小块的优势是检索精度高。用户问一个很具体的问题时小块能快速命中而且向量里的语义更集中干扰少。小块的劣势是上下文不足。很多问题需要结合前后文才能回答一块一两百字的片段往往只剩结论没有推导背景大模型把它当成唯一依据就会断章取义。大块的优势是上下文完整。逻辑链条、引言、结论都在同一个块里生成回答时大模型看到的是全貌。大块的劣势是检索时噪声大、向量语义被稀释。更重要的是如果一个大块混了好几个主题无论问哪个主题它都能“擦边”返回但提供的都是差不多的信息量多轮问答体验很差。实际调优时没有标准答案。我的习惯是先按问题类型反推如果用户的提问都是“某个参数是多少”这种事实型问题块可以小一些如果提问是“对比A和B方案后应该选哪个”这种分析型问题块必须大到能包含双方的完整论述。搞清楚你的应用场景里用户到底怎么问问题比死记任何一组推荐参数都重要。3. 分块参数实战块大小、重叠长度与代码演示3.1 块大小怎么定块大小也就是每个块包含多少Token或字符是分块最核心的参数。先给一个初学视角的参考基线中文场景下我常从300到800个字符之间起步。为什么是这个区间因为一般中文一句话是二三十个字一个段落三五句话300到800字大致能覆盖一个完整的论述单元。英文场景下这个数值要换成Token数来看大约100到300个Token具体看模型的上下文窗口和你使用的Embedding模型的最大输入长度。在刚才提到的那个产品手册项目里我最初的块大小是512个字符后来压到256效果好了不少。原因是我们的问题多数是“某功能入口在哪”“报错代码含义是什么”这类事实型问题256个字符已经足够包含一段完整的说明又能在检索时避免无关内容混进来。块大小不是拍脑袋定的有两个硬约束先要确认。一个是Embedding模型的输入上限比如很多开源Embedding模型单次输入不超过512个Token块超过上限会被截断等于切了块又白切。另一个是面向最终回答的大模型上下文窗口窗口小的模型不能喂太多个块否则放不下问题和指令。先卡这两个约束再谈效果调优。3.2 重叠长度怎么定重叠overlap解决的是分块时“一句话被劈在两块里”的尴尬。当你从第300个字切一刀如果第290到第310个字是连续的一句话这句话就断了。前半个意思在前一块后半个意思在后一块。检索时如果命中的是前一块模型只看到半句话。重叠的做法很简单下一块不从第300个字开始而从第250或第270个字开始让两块的边界区间共享部分内容。重叠长度通常设为块大小的10%到20%。比如块大小500字重叠50到100字。过高的重叠会制造大量冗余块导致向量库里同一句话出现好几份检索时返回的多个块高度重复白白浪费上下文窗口。过低的重叠又起不到衔接作用。我踩过的一个坑是把重叠设到块大小的四分之一结果库里冗余度很高用户问一个问题检索回来的五个块里有三个在讲同一件事回答翻来覆去就那几句话。后来把重叠压到15%冗余少了召回还提升了因为每个块都覆盖了更多独立信息量。3.3 标准分块流程代码演示我用一个简单的Python示例演示固定大小分块加重叠的实现。先写一个最基础的分块函数。def fixed_size_chunk(text, chunk_size500, overlap50): if chunk_size overlap: raise ValueError(chunk_size must be greater than overlap) chunks [] start 0 while start len(text): end start chunk_size chunks.append(text[start:end]) if end len(text): break start end - overlap return chunks这个函数逻辑非常简单从头开始取500个字符下一块的起点往前回退50个字符。实现原理搞清楚了再去看各种框架里的高级分块器核心逻辑都是一回事只不过加了分隔符优先级、语义边界检测等功能。实际项目中我更常用的是LangChain的RecursiveCharacterTextSplitter它支持按分隔符列表递归切分会优先在段落边界、换行符、句号等位置切尽量避免在句中下刀。from langchain_text_splitters import RecursiveCharacterTextSplitter splitter RecursiveCharacterTextSplitter( chunk_size500, chunk_overlap50, separators[\n\n, \n, 。, , , , , , ], ) chunks splitter.split_text(document_text)这个分隔符列表值得注意它按优先级排列优先按段落切段落太长再按句子切句子太长再按逗号和空格切实在没有分隔符才按字符硬切。这样切出来的块语义完整性比我手写的固定函数高很多。如果你用的是中文文档我建议把句末标点加进separators列表。默认配置里往往只处理英文标点不加的话中文文本会很吃亏很容易从一句话的中间劈开。这是我早期最常忽视的一个细节。3.4 用元数据补足分块丢失的上下文很多人切完块之后直接向量化入库忽略了一个很重要的信息元数据。分块会把原先的上下文割裂开但你可以把上下文作为元数据挂在每个块上。比如这个块来自哪个文档、属于哪个章节、原文的路径是什么、创建时间是什么。检索时不一定把这些元数据塞给大模型但可以用它来做过滤比如用户只查2024年之后的文档或者只查某个章节元数据能把搜索范围大大缩小。更进阶的用法是给块附加“来源标题”或“父块摘要”。比如固定大小切出来的块丢失了章节归属你可以提取当前块最近的Markdown标题存成一个叫section的字段。这样检索返回时大模型能看到“这句话来自‘参数配置’这一节”生成答案时就有了边界感不会张冠李戴。我在项目中验证过这个做法加了章节元数据之后回答中胡编乱造的情况少了很多。因为大模型知道这段话的确切出处引用格式也规范多了。4. 进阶玩法按结构切、按语义切、按层级切4.1 结构化文档别用固定大小切按标题层级走如果文档有清晰的结构比如Markdown、HTML或Word里的标题层级还用固定大小切分就是暴殄天物。按标题层级切分就是把每个标题下的内容作为一个候选块。如果标题下内容太长再递归往下层标题切。这样切出来的块天然具备一个完整主题。产品文档和技术博客是最适合这种切法的作者本人已经把信息组织得很清晰我们只是顺着他的组织思路搬运。LangChain里有个MarkdownHeaderTextSplitter可以做这件事原理就是扫描各级标题按你指定的标题层级组合成块。我习惯把二级标题作为默认分割点因为一级标题往往大而全切出来的块还是太大二级标题下一般是一个能独立成立的论点。用这种切法要注意一点不要只看标题字面量还要考虑标题下的内容量。有些文档在二级标题下只有两句话有些三级标题下却有好几屏内容这时就要设置一个最大长度上限对超长块再次拆分。4.2 语义分块把意思接近的内容凑在一起固定大小分块是物理切割结构分块是逻辑切割语义分块则是按“意思”聚拢内容。语义分块的核心思路先把文档按句子拆开然后用Embedding模型计算相邻句子的相似度如果相似度超过某个阈值就把它们归到同一个块如果发现语义突然转折就在这里切块。这个做法适合没有明显结构的长文比如论文、访谈、问答记录它的边界是“话题是否连续”而不是“字符数量是否相等”。实际使用中你可以直接基于相似度聚类的思路做把所有句子向量化计算相邻句子间的余弦相似度设定一个相似度阈值低于阈值就切开。阈值越高切出的块越多、越小阈值越低块越大、越完整。这种方案的代价是计算量和处理时间都上升句子需要额外跑一次Embedding。不过在知识库质量要求高的场景下语义分块带来的检索精度提升是值得的。我自己的实测感受是语义分块比固定大小分块更接近人工手动切分的质量尤其在话题转折频繁的文本上效果非常明显。4.3 父子分块既想要精准检索又想要足够上下文父子分块是我特别想推荐给小白尝试的方案因为它从设计上就解决了“小块精准和大块完整”的矛盾。它的思路分两层。父块是较大的语义单元比如一个完整的章节或一段较长的文字子块是从父块里切出来的更小的片段。构建索引时把子块放进向量库用于检索检索命中子块后不把子块直接拿给大模型看而是顺着父子关系找回它的父块再把父块作为上下文给大模型。这样检索发生在小粒度上精准度高生成发生在完整粒度上上下文充足。用检索到的子块定位答案在哪用对应的父块提供答案的前因后果。在LangChain里这个能力叫做ParentDocumentRetriever。我建议把父块大小控制在1000到2000字子块控制在200到400字。父块不能太大否则上下文窗口受不了子块也不能太小否则连问题本身都装不下。4.4 多路检索让多个分块策略同时干活既然每种分块策略都有短板那能不能同时跑多套分块方案让它们互补可以这就是多路召回。做法是对同一份文档同时用大块、小块、结构化分块等多套策略生成多个向量集合。检索时分别从每套集合里各取几个候选合并去重后再决定最终交给大模型的顺序。这种方案在高质量问答系统里很常见代价是需要维护多个索引存储成本和检索耗时都会上升。但对中小型知识库来说这个代价完全可接受。我对一个几千页文档的知识库做过多路召回实验召回质量明显优于单策略尤其在混合着短问答和长论述的文档集上。多路召回的关键是合并规则要设计好不能简单按相似度拼凑。我给过一个经验值大块召回的结果排在前面保证上下文完整小块召回的结果排在其后作为细节补充结构分块的命中结果可以用来生成引用来源。最终顺序结合窗口大小再截断。5. 常见问题与排查实录5.1 三次印象最深刻的分块事故这里记录我在实际项目里遇到的三次分块事故希望能帮你提前避坑。第一次事故是“切碎了代码块”。一份技术文档里有一整段YAML配置示例按中文句号分块时配置里的注释和标点被误判成句子边界导致一段完整的配置被切成三截索引进去了检索回来的配置永远不完整用户照着用必然报错。后来处理方式是对代码块单独做保护遇到缩进或代码框标记时就跳过常规分块逻辑。第二次事故是“重叠冗余引发的回答刷屏”。前面讲过重叠比例设置太高导致向量库里同一句话出现多份。当时用户问一个问题五个检索结果里三个是同一段话的不同切片大模型就来回引用这句话完全忽略真正重要的其他内容。把重叠从25%降到10%之后这个问题立刻缓解。第三次事故是“表格被拦腰切断”。PDF里的表格按字符分块时很容易在行中间切开检索到的块只剩半张表列名都丢了模型自然没办法做数值对比。后来对表格单独处理先把表格转成文本形式并且保证每行记录不跨块表格类文档的问答准确率才上来。5.2 分块方案怎么评估分块方案好不好不能靠感觉。我通常会构建一个小规模的评测集用三类指标来客观打分。第一类是召回命中率。准备一批问题和它对应的标准答案所在段落检索后看正确答案对应的块是否出现在前几个结果里。第二类是答案相关性。让大模型根据检索结果生成回答人工或通过评分模型判断内容与问题和参考文档的相关程度。第三类是检索结果去重率。如果返回的多个块内容大量重复说明分块冗余太重不管准确率多高这个方案都不适合。还有一个偏工程向的指标重复内容占比。随机抽样库里的块做两两相似度计算如果大量块的相似度超过某个阈值说明重叠或分块策略产生了太多重复信息。小规模人工评测就可以发现问题不用一上来就搭复杂的评测系统。我每次调分块参数都是先准备三五十个真实问题跑一轮看结果再根据失败案例反推参数。这个过程很土但确实最有效。5.3 一套实用的排查顺序如果你的RAG问答效果不好先别急着怪模型按下面的顺序排查一遍多数问题都能定位。先看检索结果本身。把用户的问题和检索返回的块直接打印出来人工看一眼返回的内容是否和问题相关。如果返回的块本身就是答非所问问题一定出在分块或Embedding阶段。再看检索命中的块是否包含正确答案但答案埋在很长的上下文里找不到这是块太大。如果正确答案刚好被切在两块的边界上每一块都只有半截信息这是分块边界设计有问题。最后再看提示词和模型生成阶段。按这个顺序走下来大部分RAG翻车案例都能归结到分块上。尤其是检索阶段我花了几个月的时间才完全建立起“先看检索结果再谈生成质量”的反思习惯。刚开始做RAG时一出问题就调提示词和模型参数折腾很久才发现全都是检索回来的块质量太差导致的。如果你在做RAG时只记住一条经验我想说分块的粒度要跟着你的问题来。事实型问题切小块分析型问题切大块结构化文档按结构切混合场景就上多路召回。你不需要一开始就找到最完美的方案先搭一套能跑通的分块攒一批真实问题再逐步调整。分块这件事最大的好处是它的试错成本很低改一次只是重新跑一遍索引但带来的收益是实打实可感知的。把这个环节打磨好大模型的能力才能真正释放出来。