调RAG的时候很多人第一反应是去换向量模型、调召回阈值甚至给提示词加一堆指令。可真到了线上效果不稳定、检索出来的句子上下文对不上、回答里明显缺信息的时候往回查十有八九是分块Chunking这一层出了问题。分块看着简单就是把文本切成一段段再拿去向量化但这一步实际上同时决定了检索的上限、消耗的成本和生成环节能吃进多少有效上下文。它是RAG里最不像技术活却最吃经验的技术决策之一。这篇文章不打算从教科书式的原理讲起而是把自己在几个RAG项目里踩过的坑、调过的参数、换过的分块策略按一条从朴素切分到智能切割的路径整理出来。内容覆盖固定窗口分块的适用范围、按结构和语义分块的工程做法、分块大小的设定逻辑以及一套不依赖玄学感的评估方法。无论你现在是在做文档问答、私有知识库还是做代码辅助检索这篇文章里面提到的思路和参数都能直接拿去对照调参。1. 先算明白分块为什么是RAG的“命门”1.1 一条RAG链路里分块卡在哪个环节一条典型的RAG链路顺序一般是文档解析、分块、向量化、索引写入、检索召回、重排、拼接上下文、交给大模型生成。很多人把注意力放在后面的生成和提示词上但实际上真正决定系统“有没有机会答对”的是检索环节能从知识库里捞出什么。而检索捞什么又完全取决于索引里的数据长什么样。索引的数据源头是分块换句话讲分块这一步是整套系统里第一个放大失真的环节。文档解析可以乱但解析完至少原文还在分块如果切得不对信息就彻底错位了后面怎么调都是白费。分块本质上是在做一个信息粒度的取舍。粒度太大一个块可能混了多个主题向量表示会被拉成一个模糊的平均值检索的时候语义特征容易被稀释。粒度太小又容易把同一个完整观点拦腰截断导致每个块都只包含一半信息召回回来以后模型拿到的是半拉子上下文。所以分块不是简单的“长一点好还是短一点好”的问题而是要跟检索算法、向量模型、生成模型的上下文窗口这四者匹配起来看。这也是为什么全公司用同一套分块参数会出问题数据分布的差异太大了。1.2 分块质量直接影响的三件事召回、上下文、成本第一件事是召回质量。向量检索本质上是算相似度它看的是文本之间的语义重合程度。一段文本被切得越干净向量代表的主旨就越单一召回的时候跟query的匹配就越精准。反过来如果一个块里塞了三个话题它的向量可能会同时包含三个方向的特征结果任何单一query跟它匹配都是“既沾边又不尽兴”排到Top10里又不靠前导致明明里面有正确答案却取不出来。第二件事是上下文的有效性。大模型生成时一共能看到那么多token把有限的上下文预算浪费在无关内容上就会压缩真正关键信息的位置。分块尺寸过大或者召回时把很多块硬拼在一起模型要做的第一步不是作答而是在冗余里“大海捞针”。我自己实测过同一套问答同样Top4召回分块比较规整的那版回答几乎可以直接引用原文分块切得随意的那版模型像在拼拼图经常推测性补全甚至编造细节。第三件事是成本。分块数量决定了要发多少次向量化请求也决定了向量数据的存储体量和检索耗时。如果一个40页的PDF被硬分成两三千个碎片块会积攒出来的额外存储量和请求数都不可忽略。反过来如果为了省成本把块切得特别大每次召回内容变少容易落回漏召回的结构。实际项目里我不太建议只拿“省钱”这一个指标来定chunk size而是先在可接受的召回效果下再优化块数和存储。2. “无脑切”也是一种工程方案固定窗口分块的实际表现2.1 单位之争按字符、按词、还是按Token固定窗口分块就是从文档开头按固定的长度往后切切到尾部不够一整块也无所谓。但这个“固定长度”的单位选什么门道反而比想象中多。最常见的三种单位字符、词、Token。如果文档大部分是英文按词切分比较直觉如果文档主要是中文按字符切分逻辑上还挺不对齐。为什么这么说因为中文一个字符往往就是最小语义单元而英文一个单词是由多个字符组成的。按字符数切中文一个块里的意思有时能相对完整按字符数切英文很容易把一个单词或者一个词组硬生生掰开。更严谨的做法是按Token切分Token就是大模型内部真正消费的文本最小单元。一个Token可以是一个词、半个词也可以是一个中文字。对中文来说大概一个字对应一个Token对英文来说差不多四分之三个单词对应一个Token。Token感知分块的优势在于它能精确控制生成阶段实际输入给大模型的内容量不会出现“块数正好但Token爆了”的情况。很多开源框架里的默认分块器本质上就是基于Token的只是因为文本清洗方式不同它还会额外处理标点和空白带来的表面偏差。2.2 重叠窗口能捞回多少上下文固定窗口分块最被诟病的问题是语义边界完全随心所欲一个完整句子可能从中间被切开切断的位置恰好是整段信息的关键转折。为了缓解这个问题工程上引入了重叠overlap的概念也就是相邻两个块之间有一段共享的文本。我见过比较常见的做法是让重叠长度占到块长度的10%到20%。比如块长512个Tokenoverlap设64或96个Token。这样切下去虽然块边界仍然是机械的但被切断的那部分信息至少会出现在相邻的两个块里丢信息的概率会被明显拉低。overlap的原理并不复杂它等于用冗余换召回。同一个片段会以不同的上下文窗口被向量化两次甚至三次检索匹配到的概率自然更高。代价也直观索引体积增大向量化请求变多召回时容易把多个高度相似的块都顶到前排造成结果同质化。比如Top5里三块内容几乎重叠真正该出现的其他内容却排到后面去了。所以别把overlap当成越多越好要先想想自己的召回数量上限和同质化容忍度。2.3 固定切分的适用范围与边界固定窗口分块虽然“无脑”但在相当多的场景里也够用很多上线跑了好几个月的聊天机器人背后就是固定分块。它适合哪些场景表格、规则性极强的记录型文档、日志、结构规范且篇幅稳定的章节这类文本内容本身没有太强的长程语义依赖切成什么位置影响不大。还有一类情况是项目刚开始文档还没梳理完整数据量有限还没来得及做精细分块。这种时候固定窗口是性价比最高的起跑线。它的局限也很清楚遇到论述性强的长文段落内部有起承转合或者一个观点分散在多段里反复展开固定切分就很容易把讨论切碎。比如一篇技术方案先讲背景再讲约束最后讲选型这三个部分往往存在“前文定义的变量后文要引用”的关系。固定切分出来的某一块可能只包含背景另一块只包含选型结论而缺了中间的推导和约束条件。检索时query一旦问的是“为什么要这样选”召回回来的内容就缺了关键证据链。这个阶段再往下走就需要考虑按文本自身的结构来切了。3. 从“切”到“理解”按结构、语义与文档形态做智能分块3.1 结构分块段落、标题、代码块都是天然边界智能分块的第一步也是最值得优先做的是“顺着文档原本的结构切”。人类写文档的时候本身就埋好了语义边界段落是完整意思的容器标题和节号是逻辑层次的标记列表项和代码块也都有天然边界。分块器要做的不是发明边界而是敏锐地把这些边界找出来并用起来。对于Markdown和HTML类文档章节标题是最可靠的分块锚点。常见的做法是按标题层级切分每一节作为一块子标题再作为单独的小块必要时连标题一起作为块的元数据。这样做的好处有二一是内容天然连贯块内部的语义不会跨主题二是检索命中以后块自带标题可以直接告诉生成模型这段内容的出处回答的时候更容易引用到正确的章节。代码库的RAG就更典型了。按固定长度切代码几乎一定截断在函数中间或者把两个不相关的类拼在一起效果可以说是灾难。更合理的做法是先做代码结构解析把函数、类、注释块识别为基本单元再按依赖关系或就近原则聚合。这样检索代码片段时命中结果至少是一个完整的方法实现后续生成代码建议时才有上下文可推理。3.2 递归与自定义分隔符兼顾速度与语义结构分块听着理想但现实文档千奇百怪有的没有标题有的标题层级不规范有的干脆是从PDF里抽出来的大段纯文本。这种时候就需要一类更灵活的策略递归式分块。它的思路可以用一句话概括先用高阶分隔符试切如果切出来的块仍然过大再用低阶分隔符递归地切下去。这里的“高阶”指的是语义边界更强的分隔符比如段落、双换行、单换行、句子结束符如果这些都切不动最后再按Token数硬切。递归分块的工程价值在于它不用预先穷举文本的所有格式而是给出一组分隔符优先级排序让算法自己去判断哪种边界对当前文本最合适。举个例子一段Markdown文本如果按##二级标题切出的块还是太长就退一步按段落切再不行按句子切实在不行落到固定字符数兜底。这样一来绝大多数块都落到了语义相对完整的边界上只有少部分极端长段才会被硬截断。递归分块里的分隔符顺序要仔细维护不是随手写几个符号就完事。顺序错了会放大错误比如把空行放在句子结束符前面结果每个段落内部因为长度超限被句子符号切成了碎片原本的段落结构反而不见了。3.3 语义分块让嵌入模型告诉你从哪里断句递归分块虽然智能本质还是在借用文档表面的格式信号。如果一份文档没有任何格式没有换行也没有标题那再优秀的递归分块也退化成固定切分。这种时候真正的兜底方案是语义分块。语义分块的基本思路是先把文档拆成句子级别的小单元对每个句子做向量化然后计算相邻句子的相似度。如果两个相邻句子之间的相似度突然掉得很低说明话题发生了转向这里就是一个天然的分块边界。换句话说它是让嵌入模型来告诉你“这两句话聊的不是一回事”而不是靠人在规则里预设边界。这就像看电视剧情节没变的时候镜头连续情节一转场观众立刻感觉到氛围不对了。相似度骤降就是那个“转场信号”。我给一个简化版的实现骨架方便理解def semantic_chunk(sentences, embed_func, drop_threshold): chunks [] start 0 for i in range(1, len(sentences)): score cosine_similarity( embed_func(sentences[i-1]), embed_func(sentences[i]) ) if score drop_threshold: chunks.append(.join(sentences[start:i])) start i if start len(sentences): chunks.append(.join(sentences[start:])) return chunks实际落地时不会这么朴直因为相邻句子两两做嵌入的请求量太大通常会把句子先装入滑动窗口按窗口内平均相似度做判断门槛的选取也要根据数据分布调。但核心思想就是这样不依赖外部结构只依赖语言内在的语义密度变化。语义分块的坏处也很现实它比普通分块慢几十倍每一段文本的向量化成本叠加上去体量一大索引构建时间就难以接受了。所以它在文档干净、需要精细召回的小样本场景里非常亮眼但在海量日志或全量网页场景里容易贵到让人放弃。3.4 分块方法的选用对比这里把几种常用方法放在一起做一个横向对比实际选型时可以直接对照这个表决定从哪一层开始做。分块方法核心依据典型适合场景主要缺点工程成本固定窗口Token/字符计数初版业务、规则长文、日志切碎语义、边界随机极低固定窗口重叠Token计数重叠比例需快速上线、文档结构一般检索同质化、索引膨胀低递归分隔符段落/标题/句子层级Markdown、HTML、结构化文本对无格式文档退化为固定切分中结构感知代码语法树、标题元数据代码库、手册、法律文书依赖解析器和格式规范度中高语义分块嵌入相似度变化高质量长文、话题跳跃文档计算成本高、门槛敏感高父子分块粗粒度块召回细粒度块喂给模型长文档问答综合场景存储结构变复杂、多一次拼接中高最后一项父子分块值得单独说。它在实际项目里的表现经常超过其他单一方法思路是先切出较粗的父块用于向量检索定位命中后再把父块切出的子块作为生成上下文。相当于检索阶段看大纲生成阶段看细节兼顾了“找得准”和“读得全”两个目标。很多线上效果不错的RAG系统都是在普通分块外面套了这么一层父子索引。4. 参数不是玄学如何设定分块大小并量化评估4.1 分块大小的三个约束模型窗口、检索目标、存储成本决定具体切多大临场拍脑袋是最常见的翻车方式。要想切出靠谱的chunk size至少得同时想想三个约束的折中。第一是模型窗口。生成模型的上下文窗口长块就可以适当放大窗口小再追求大块就是自找麻烦。一个简单好用的经验是把分块大小控制在模型窗口的八分之一到四分之一之间。这样既保证一个块能放进上下文又能给检索召回的多块拼接留出余量。如果模型窗口是8K Token块大小设在512到1024之间比较稳妥窗口涨到128K块长可以试探到2048甚至4096但不要贪婪。第二是检索目标。你希望系统回答的那种问题通常落在一段多长的文字里如果知识库里主要是“某个参数是多少”这类事实型问答块要小尽量让一个块只包含一个事实。如果问题偏“某个方案为什么是这样设计的”那完整的设计推导段落往往是不可分割的块就得给足长度。可以从自己已有的Query日志里抽样看命中答案在原文档里大概占多长篇幅再反向定chunk size。第三是存储成本。块长减半块数近似翻倍。向量数量上去了检索耗时和存储费用也跟着涨。索引构建和实时刷新成本在中等数据量下还能忍到了千万级向量的体量差一个档次的chunk size可能让资源消耗差出一个数量级。4.2 标签用召回率、精确率、时延量化“切得好不好”没有评估体系之前调chunk size就是纯靠感觉的玄学。要打破这种感觉最直接的方式是建立一套评估基准常见指标是命中率类的召回关系和耗时。先说召回类的评价。这个指标衡量的不是“生成答案对不对”而是“正确的文档片段有没有被检索算法找出来”。具体做法是人工准备一组测试问题并在原始文档里标注每个问题对应的答案片段应该在哪个块附近。然后跑检索看这些问题里的答案片段有多少出现在TopK召回结果中。正向命中比例越高说明分块策略和向量检索的配合越好。这个指标不涉及大模型生成跑起来很快很适合做分块A/B测试的筛选器。精确率则用来控制成本TopK召回结果里有几条是真正相关的如果一堆近乎重复的块挤进TopK精确率就往下掉提升余弦相似度阈值或者调低overlap是常见对策。时延也一样重要如果分块太细导致检索和拼接路径都要多跑几轮哪怕效果提升也不划算。实际项目中我会建议至少记录三个数RecallK、精确率、单次检索P95延迟。三个数盯住分块好坏自然就分出了高下。4.3 不同文档类型的默认分块配方分享一组我在不同项目里验证过的参数配方给还没有头绪的读者当起点。使用之前先按自己的文本微调但起始点起码能帮你快速跑通基线。文档类型推荐分块策略参考块长重叠附加建议技术手册/说明文档递归分隔符优先512 Token64保留章节标题做元数据学术论文/技术方案语义分块或父子分块1024 Token128保留摘要、关键词按章节记录页码合同/法律文书结构感知按条款切条款边界0~少量每个条款带条款编号元数据代码库代码语法树分块单个函数类头0保留 import 区域做定位参考会议纪要/聊天记录固定窗口重叠768 Token128为每轮发言附加发言人元数据FAQ/知识问答库按问题分组切块问题回答整体0一个问答对一个块索引最稳定表格只是起点真正跑起来会发现文档里的“脏”数据比预期多。比如说明书里夹杂表格表格本身是按行还是按块切会直接影响表格检索效果。我的建议是表格单独走一边按“表头行记录”的方式切别跟着全文策略走。再比如代码块里的长注释、长字符串结构解析容易误判要专门做一层清洗。5. 工程现场常见的分块坑与排查手册5.1 边界切断了关键信息第一个高频坑是分块正好把一个完整的事实框架一分为二。比如“该系统的延迟低于100毫秒”这句话被切成“该系统的延迟低于”和“100毫秒”两个块。前者没有数值后者没有主语单看哪一块都答不了问题。出现这种情况优先自查两件事一是分块边界是不是完全没考虑句子完整性二是overlap是不是设得太小。递归分块能很大程度上避免这类问题因为它会优先把句子作为分隔符不会一言不合从句子中间截断。如果用了递归分块还是出现这个坑多半是原始文本里某些长句本身就不带标点或换行这时候需要给分隔符列表里加上“句末标点”这类兜底项。5.2 分块后内容“找准了”但“读不全”排查时的第二个常见现象是检索TopK返回的块内容确实是正确答案所在的区域但答案本身被切成了一段不完整过程生成模型拿它推不出结论。这种问题在长文档里尤其明显因为正确答案经常横跨2到3个块。解决办法里效率最高的是引入父子分块或者两级召回。先按大块定位“答案大概在第几章”再往大块内部切细后检索“具体是哪句话”最后把命中的小块的相邻兄弟块一起带入生成。这样既不会因为块太大导致向量语义被稀释也不会因为块太小而丢了上下文连续性。5.3 元数据丢失答案找到了出处没了分块切完了才发现元数据弄丢了是另一个比较隐蔽的坑。向量索引里存的如果只有纯文本没有标题、页码或章节信息那么检索命中后你只能把裸文本拼给模型既无法溯源回答容易变成无根之木。解决方式是在分块的时候同步保存元数据至少要把标题、章节路径、页码、原始文件ID这四个字段和块关联起来。进一步可以让分块器“继承”所属的标题链。比如一份有三级标题的文档切出来的每个块都带着“级别1标题 级别2标题 级别3标题”这样的路径。模型生成回答时能看到这句出处回答的专业度和可信度都会高一大截。5.4 评估与回归没有评估的调参都是盲猜从固定切分转向智能分块之后还会遇到一个实际问题改了一版分块器怎么知道效果真的变好了我的建议是做流水线化评估把每一版分块策略产生的索引存成快照再使用固定的一组测试Query对它们做回归对比。回归评估的流程可以这样做准备50到200个真实问题尽量覆盖高频问法、长问法和模糊问法。给每个问题标注理想答案片段对应的大致位置。对不同分块策略分别构建索引。跑同样的检索流程记录RecallK、精确率、P95延迟。选取效果最好的策略进入生成评估人工或模型评分答案的完整性和忠实度。这套流程跑起来以后调chunk size就不再是靠灵感了每次调整都有明确的分位趋势可以参考。我自己就在这个流程里吃过甜头有一版语义分块在召回率上比无脑固定分块高出十几个点但生成端因为块与块之间话题断裂答案反而更零碎。回归评估把这个问题暴露得明明白白省了我在线上反复试错的成本。最后再分享一个现在比较常用的土办法。做分块策略切换时我会先拿Top3召回结果直接打印成文本看一遍人为判断“如果我是用户光看这段能否回答我的问题”。这个步骤五分钟都不用却能把绝大多数分块严重错误提前拦下来比任何复杂指标都省事。先让输出肉眼可见地正确再去追求指标上的最优分块这件事才算真的稳了。