搞大模型应用这一年多我最深的感受是很多人把注意力全放在模型选型、Prompt调优、微调这些“显眼”环节上却忽略了最基础也最决定上限的一步——文本分块策略。项目上线后检索结果一团糟、召回质量忽高忽低排查到最后十有八九是Chunking这一步没做好。文本分块策略简单说就是把长文本切成模型能消化的“小块”再喂给模型。听起来像是复制粘贴的体力活但实际做起来有大量门道块切多大边界落在哪要不要重叠要不要对齐段落语义每换一个模型、换一个业务场景分块策略都要跟着重调。这篇文章不聊虚的我直接把今年在模拟项目X里踩过的坑、验证过的方案、修过的参数全部摊开讲希望能给正在折腾知识库、RAG或者长文档处理的你一点参考。1. 为什么分块——分块解决的核心问题1.1 文本分块的本质给大模型“一口能吃下的分量”先搞清楚分块到底解决什么问题。大模型的上下文窗口是有限的拿常见模型来说上下文在几千到几万token不等。如果我们要扔一份几十万字的公司制度汇编进去模型要么直接报错“超出最大长度”要么就是被硬截断后半段信息完全丢失。这时候如果不做切分后续的检索、摘要、问答等任务都没法正常开展。但分块不只是为了“塞得下”。更关键的原因是大模型对中间信息的遗忘倾向远比你想象的严重。我自己做过对照测试把一份两万字的合同丢给模型直接读完再问细节模型能答对的概率远低于先把合同切成若干段落、再针对性地检索相关段落后回答。这就像让人通读一整本书再回忆某页某句话远不如先定位到那一页再细读来得准确。分块本质上是在做“定位——读取——回答”三层结构的底层支撑。很多人以为分块只是工程上的体力活实际上它直接影响两个指标召回率和准确率。块太大检索时容易掺入无关内容模型答非所问块太小可能把完整的语义上下文切断模型光看一小段根本理解不了全貌。所以分块策略的设计本质是在“信息完整性”和“查询精准度”之间找平衡点。1.2 不分块的代价从上下文窗口看分块必要性有些刚入门的朋友会问现在不是有超长上下文的模型了吗几千上万token还不够用够不够用取决于任务类型。如果是单纯的文档摘要超长上下文确实能凑合但如果是做问答型知识库情况完全不同。问答系统的核心流程是“先检索后生成”检索阶段的召回质量决定了回答的天花板。而几乎所有向量检索系统在极端长文本上都会出现“语义稀释”问题——一段话里包含的信息太多向量化后各个主题的语义互相拉扯最终这个向量的方向变得模棱两可和查询的相似度计算自然不准。我举个例子你就能明白假设一本操作手册的第五章同时讲了开机步骤、参数配置、故障报警三个主题你把这整整一章做成一个向量然后问“开机时报错E401怎么办”。这个向量的语义里“开机步骤”和“故障报警”被平均拉扯算出来的相似度会同时低于单独的“开机步骤”向量和“故障报警”向量结果就是检索排名靠后回答质量大打折扣。另外还有个工程上的考量向量数据库的存储和计算成本。同一个文档切一块存一条向量和切十块存十条向量检索时的计算量、存储开销完全是两个量级。虽然现在向量库的规模扩展相对方便但分块策略做得差等于后面所有环节都在给前面“还债”。1.3 分块粒度与后续任务的关联分块不是孤立的一步它和下游任务的耦合度极高。如果你做的是语义检索/知识库问答分块的目标是让每个块承载一个“相对独立且自包含”的信息单元。用户的问题大概率只对应文档里的某一段分块越贴近语义边界检索命中率越高。如果你做的是摘要生成分块粒度可以适当放大因为摘要需要理解整体脉络过度细碎的分块反而让模型“只见树木不见森林”。如果你做的是信息抽取/情感分析分块则需要更细通常以句子甚至短语为单元因为抽取任务关注的是局部语义而不是全局脉络。我做模拟项目X的时候最常被问的一句话就是“有没有万能的分块参数”答案是没有。分块策略必须跟着任务走、跟着数据走、跟着模型走。但好在我们可以总结出一套通用的思考框架和调参流程让每一步都有据可依。这也是这篇文章想真正教会你的东西。2. 分块策略的选型与设计思路2.1 固定长度分块最朴素也最容易被低估固定长度分块是最原始、也是实现成本最低的方案设定一个token数每隔这个长度切一刀必要时让相邻块之间有重叠。# 固定长度分块示例Python伪代码/核心逻辑 def fixed_length_chunk(text, chunk_size512, overlap50): tokens tokenize(text) chunks [] start 0 while start len(tokens): end start chunk_size chunks.append(tokens[start:end]) if end len(tokens): break start end - overlap # 保留重叠区 return chunks看起来无脑但为什么我仍然建议先从它开始因为它能给你一个清晰的“基线”。我习惯的做法是新项目的数据接入后第一版先用固定长度分块跑通整个链路把检索、生成的代码流程都调通再回头优化分块。之所以这样是因为固定长度分块的变量最少——只有块大小和重叠数两个参数出了问题容易定位。而一上来就上递归分块、语义分块这些高级玩法变量太多出了问题你根本分不清是分块策略的问题还是向量化模型的问题还是检索逻辑的问题。固定长度分块最大的弱点在于“切得不管不顾”。一个语义完整的段落可能在中间被拦腰截断前后两个块各剩一半模型理解起来非常吃力。所以这种方案更适合内容结构化程度低、但单条记录本身较短的场景比如客服会话记录、日志文件、商品评价等。在这些数据里每一条天然就是信息单元固定长度分块反而够用。若想改善固定分块的短板一个立竿见影的做法是用句子边界对切割位置做对齐。先按句子切再累积token数直到接近上限遇到超出就在句号处断句。这样虽然本质上还是固定长度但块边界不会落在句子中间语义完整性已经好了很多。2.2 递归分块与结构化分块让块落在“语义自然边界”上如果数据是长文档比如技术手册、规章制度、论文固定长度分块就有点不够看了。我常用的升级方案是递归字符分块Recursive Character Text Splitter。递归分块的思路很简单用一组从大到小的分隔符去递归切分文本。先按段落分隔符比如两个换行切如果切出来的块还大于上限就再按句子分隔符切还不行就按更小的粒度继续切。这样切出来的块边界从大板块逐步收缩到句子层面尽量保证每一块内部语义相对完整。需要注意的是这里的“递归”指的不是把内容反复切而是分隔符优先级逐级下探的过程。很多人在实际使用中只配置了一组分隔符导致切分效果和固定长度分块相差无几这种是没理解递归分块的真正用意。如果数据带有明显结构比如Markdown、HTML、代码文件那就可以用结构化分块器。以Markdown文档为例可以按标题层级切分一级标题、二级标题、三级标题分别作为不同等级的切分边界。这样做的好处是每个块自带“标题上下文”后续检索时甚至可以拿标题做辅助召回。结构化分块还有一层容易被忽略的价值它给每个块赋予了“层级路径”。比如一个块的内容是“修改密码的操作步骤”它所属的标题是“账号管理-“安全设置-“修改密码”。在检索时我们可以把这个路径拼到查询里一起做相似度计算或者直接在MetaData里存一份召回后展示给用户看。这种多一层上下文信息的效果往往能让回答的准确性提升一个明显的台阶。2.3 语义分块与特殊场景是银弹还是玄学再往后走就是语义分块。它不是按固定字数切而是分析文本的语义边界在“意思变化”的地方切。目前比较常见的做法有两种一是利用嵌入模型计算相邻句子向量的相似度相似度突然变低的位置就可能是主题转折点二是借助语言模型本身让模型判断哪里是一个完整语义单元的结束。语义分块的优点很诱人切出来的块大概率是“一个完整意思”信息密度高检索匹配更精准。但代价同样明显计算开销大、处理速度慢而且效果依赖嵌入模型的敏感度。实际项目中我不会在每一版迭代中都跑语义分块通常是先用递归分块把效果做到一定程度发现问题确实集中在“块边界语义漂移”上再针对性尝试语义分块。另外还有一些特殊场景值得一提。代码文件的分块建议按函数、类定义切而不是按行数硬切法律合同可按条款编号切同时保留条款序号对话记录最好按“一轮完整问答”切避免把提问和回答拆到两个块里音视频转写文本则需要结合说话人切换点和时间戳来切。这类领域特化分块往往比任何通用算法都更有效因为它吃透的是数据的“原生气口”。3. 核心参数、实现细节与实操代码3.1 块大小、重叠、分隔符到底怎么定分块三大参数块大小chunk size、块重叠chunk overlap、分隔符集合。很多新手上来就问“块大小设多少合适”我一般反问“你的下游模型窗口多大”和“你的单条知识本身多长”。先说块大小。有一个经验范围对于通用知识库问答以512到1024个字符中文场景或200到500个token英文场景为起步区间对于长文档摘要类任务可上调到1500到2000 token对于短文本抽取类任务降到100到200 token。但这不是硬规则真正的校准方式是拿你的真实问答对去“打命中率”。判定方法很简单准备一批有代表性的问题分别用不同的块大小跑一遍检索统计能够命中正确答案所在块的比例。命中率最高的块大小就是最优值。再说块重叠。重叠的意义在于补偿边界信息丢失。举个例子一段话讲“价格包含运费但不包含保险费”如果分块恰好把“但不包含保险费”切到下一块里前面那个块就只剩下“价格包含运费”检索时如果用户问“含保险费吗”这个块会给出误导信号。设置适当重叠后两个块都能同时包含整句信息误判概率大大降低。重叠数大了信息冗余和存储成本直线上升重叠数小了补偿效果约等于零。一个可用的起步值是块大小的10%到20%。比如块大小是512字符重叠设在50到100字符。如果原始文档里句子普遍较长重叠要偏大一点保证整句完整性。分隔符的选择同样有讲究。不同语言、不同格式分隔符的有效性排序完全不同。中文文本优先考虑句号、问号、感叹号、分号再退到逗号英文同理优先句末标点。Markdown文档优先把“#、##、###”作为一级分隔符再配合换行、句号。代码优先把注释块、函数定义、空行作为边界。3.2 常见框架的落地写法从纯手写到框架封装下面给出一份可以运行的代码思路你可以按需嵌入自己的项目里。import re from typing import List def split_text_by_separators(text: str, separators: List[str]) - List[str]: 递归分隔符分块的简化实现 results [] queue [text] current_sep_index 0 while queue: segment queue.pop(0) sep separators[current_sep_index] # 先用当前分隔符尝试切分 pieces re.split(f({re.escape(sep)}), segment) # 重组保留分隔符 merged [] for i in range(0, len(pieces) - 1, 2): merged_piece pieces[i] pieces[i1] merged.append(merged_piece) if len(merged) 1: # 切不动了换更小的分隔符 if current_sep_index len(separators) - 1: current_sep_index 1 queue.append(segment) else: results.append(segment) else: queue.extend(merged) return results实际项目中我并不建议所有场景都手写分块器。成熟框架里的递归分块实现已经过了大量项目验证稳定性更好。比如知名的LangChain里的递归字符文本分割器以及LlamaIndex里的分块扩展类都支持自定义分隔符、块大小、重叠数封装度很高直接配置参数就行。但我仍然建议你至少手写一次简单版本原因只有一个只有亲手实现过你才真正理解那些参数在底层是怎么起作用的以后遇到框架版本升级、默认参数变化你才不会抓瞎。配置层面常见的做法是{ chunk_size: 800, chunk_overlap: 120, separators: [\n\n, \n, 。, , , , , , ], keep_separator: true, add_start_index: true }这个配置的含义优先按段落切段落太大按句子切最后按字符粒度切重叠区120个字符保留分隔符记录每个块在原文中的起始位置。3.3 分块质量怎么评估不是靠感觉分块策略调了半天怎么知道改好了没有靠肉眼抽查几块样本是不够的需要可量化的评估指标。我常用的有三类。第一类覆盖率。把原始文档的所有关键信息点列出来检查这些信息点是否完整出现且没有被割裂到多个块中。如果某个信息点被拦腰截断还没重叠区兜底那覆盖率就出问题了。第二类检索命中率。拿标注好答案的问答集做测试看每个问题能否在Top-K个检索结果中命中包含答案的那个块。这个指标直接反映分块和检索链路的联合效果是项目上线前最重要的验收标准之一。我自己的经验是在分块调整前后命中率变化超过5%就值得关注超过10%基本能确定问题出在分块上。第三类块间重复度。如果设了重叠不同块之间会有部分内容重合这是正常现象但重合度不宜过高。若块与块之间出现大段重复说明重叠设得过大或分隔符选择不当检索时会出现多个几乎相同的结果块白白占用窗口资源。4. 实操过程与效果对比一个完整案例4.1 模拟项目X从0到1搭建知识库分块流程模拟项目X要处理一批约30万字的中文技术文档目标场景是内部知识库问答。文档范围包括操作手册、FAQ、故障排查指南、版本更新说明。数据特点是格式混杂部分文档带Markdown标题部分文档是纯文本段落。第一版我直接用了固定长度分块块大小512字符无重叠。跑通流程后做了一轮检索质量抽测结果很不理想用户问“如何修改管理员密码”命中的块里出现的是“管理员角色权限表”因为两个文本的字符向量距离较近但内容完全不相关。这类问题就是典型的“块内主题混杂”。第二版换成递归分块分隔符设为换行、句号、分号、逗号块大小仍然是512字符重叠设为75字符。这一版本明显改善了语义漂移问题但出现了另一个典型现象因为带着重叠区每个块都会重复上一块的尾巴在检索时经常返回两个非常相似的块回答时来回引用显得很啰嗦。第三版我把分隔符优先级调整到匹配业务格式解析文档标题层级优先按Markdown标题切分块大小放宽到768字符。这样做带来的效果是整个流程精简很多——因为标题本身就是文本结构的语义边界。同时我加了start_index元数据便于回溯原文定位。4.2 三版分块策略的效果对比分块方案块平均长度检索命中率50题测试集单批处理耗时主要问题固定512无重叠51252%3秒语义边界被切断主题混杂递归512重叠7558768%6秒块间重复度高检索冗余递归标题优先76878479%8秒无明显短板个别长段落需二次切分从数据能看出来第三版在命中率上提升显著。有一个细节值得注意单批耗时从3秒涨到8秒这中间很大一部分开销来自按标题解析和更细粒度的分隔符匹配。对离线建库场景来说这点时间完全可以接受但如果你做的是实时流式分块就要在效率和效果之间权衡可能需要牺牲一部分分块精细度。单靠命中率还不够。我又做了一轮A/B测试拿100个高频问题对比第二版和第三版的实际回答质量采用“人工打分回答追溯”的方案评估。第三版在“回答能否定位到原文具体段落”上优势明显因为每个块因为嵌入了标题层级信息回答溯源时可以直接展示“引自某章某节”用户信任度高了很多。5. 常见问题与排查技巧实录5.1 高频问题速查表现象可能原因排查与解决检索结果全是无关块块过大主题混杂降低块大小切换分隔符优先级改用语义分块一个问题命中多个几乎相同的块重叠过大或分隔符失效降低重叠增加强分隔符检查分隔符是否在文本中真实存在部分知识点完全检索不到该知识点被切碎且无重叠兜底增大重叠把分块边界向句子边界对齐加语义分块回答内容张冠李戴块内包含两个主题按标题/章节优先切分提高分隔符优先级核对块内容是否主题单一存储成本激增块数过多或重叠过大增大块大小降低重叠合并短块同一问题不同批次回答不一致检索排名不稳定检查向量模型一致性检查文本切分是否随机统一随机种子5.2 踩坑实录三个容易翻车的地方第一个坑是分隔符根本不匹配。有次接手某项目配置里写了用“//”做分隔符但实际文档里用的是全角符号。结果分隔符一个都没命中递归分块退化成固定长度分块效果自然好不了。排查方法很简单运行一次分块后抽几个块看边界是否落在预期位置。如果边界落在所有奇怪的地方大概率是分隔符没匹配上。第二个坑是中文切分中的Token标点问题。中文不像英文那样天然按空格分词标点、助词、成语都会影响token化。最开始我设块大小为512字符时配的是英文模型的字符映射结果中文字符数对了但token数严重超限下游模型处理时频繁截断。后来我在分块后统一过一遍tokenizer计数把字符数和token数做成对照表才彻底解决这个问题。第三个坑是最隐蔽的重复内容导致召回失控。文档里经常有大段重复引用比如公司制度汇编里前后两章都粘贴了一大段“安全注意事项”。固定长度分块时这两个块内容高度相似检索时老是同时把两个块揪出来。优化方案是建库前先做一遍相似度去重或者在分块阶段就把重复内容标记出来检索时对这类块做降权处理。5.3 让分块策略持续可维护的落地建议分块策略不是一次定稿就万事大吉的。上线后新版本文档、新格式数据随时会打破原有假设。我现在的做法是建一套定期回归机制维护一份带标准答案的问答集每次修改分块配置后自动跑一遍全部测试问题对比命中率变化。命中率下滑超过阈值就自动告警避免出现“改完上线了才发现检索崩了”的尴尬局面。另外数据格式的变化也要纳入监控。比如之前文档一直是Markdown风格某一天运营团队开始上传纯扫描版PDF转换出来的无结构文本之前按标题切分的逻辑就全部失效了。所以我会在产品后台保留一个“文档格式分布”的看板格式结构发生变化时第一时间感知到并主动调整分块策略。更进一步的方案是把分块策略做成可配置的规则集放到一个“分块策略表”里不同数据源绑定不同的策略。技术手册走Markdown标题分块FAQ走固定短分块故障日志走时间戳分块对话记录走会话边界分块。每个策略都能独立调整参数互不干扰。这样看起来增加了配置复杂度但长期维护下来收益远大于成本。6. 我对文本分块策略的一些个人体会分块这件事在项目里的优先级经常被排得很靠后但它对系统整体质量的影响权重非常靠前。我见过不少团队花几周时间微调模型、优化Prompt检索效果却始终上不去最后换了分块策略问题迎刃而解。所以我的习惯是新项目第一周一定要把分块流程单独拎出来做一轮压力测试确认这块稳定了再铺开做上层功能。如果你现在刚接触Chunking我给你的落地路径是先用固定长度分块把整个RAG链路跑通再用递归分块拉高效果接着根据数据格式尝试结构化分块最后用测试集做好回归评估。千万不要一上来就想上最复杂的分块方案先有基线再谈优化是比较稳妥的行事方式。最后分享一个实测了多次的小技巧分块时建议保留一段“句级过渡区”不直接切在句号之前而是让块延伸到下一个句子的开头几个字。这样模型在读块的时候能隐约感知到下一块的语气启动在多轮问答中上下文连续性会明显好上不少。这个技巧在短文本问答场景里效果尤其明显你完全可以拿去直接试。 
长河君 · 2026/10/22 9:01:41 · 阅读 1.2k 大模型RAG文本分块策略：从固定长度到语义分块的实战指南
搞大模型应用这一年多我最深的感受是很多人把注意力全放在模型选型、Prompt调优、微调这些“显眼”环节上却忽略了最基础也最决定上限的一步——文本分块策略。项目上线后检索结果一团糟、召回质量忽高忽低排查到最后十有八九是Chunking这一步没做好。文本分块策略简单说就是把长文本切成模型能消化的“小块”再喂给模型。听起来像是复制粘贴的体力活但实际做起来有大量门道块切多大边界落在哪要不要重叠要不要对齐段落语义每换一个模型、换一个业务场景分块策略都要跟着重调。这篇文章不聊虚的我直接把今年在模拟项目X里踩过的坑、验证过的方案、修过的参数全部摊开讲希望能给正在折腾知识库、RAG或者长文档处理的你一点参考。1. 为什么分块——分块解决的核心问题1.1 文本分块的本质给大模型“一口能吃下的分量”先搞清楚分块到底解决什么问题。大模型的上下文窗口是有限的拿常见模型来说上下文在几千到几万token不等。如果我们要扔一份几十万字的公司制度汇编进去模型要么直接报错“超出最大长度”要么就是被硬截断后半段信息完全丢失。这时候如果不做切分后续的检索、摘要、问答等任务都没法正常开展。但分块不只是为了“塞得下”。更关键的原因是大模型对中间信息的遗忘倾向远比你想象的严重。我自己做过对照测试把一份两万字的合同丢给模型直接读完再问细节模型能答对的概率远低于先把合同切成若干段落、再针对性地检索相关段落后回答。这就像让人通读一整本书再回忆某页某句话远不如先定位到那一页再细读来得准确。分块本质上是在做“定位——读取——回答”三层结构的底层支撑。很多人以为分块只是工程上的体力活实际上它直接影响两个指标召回率和准确率。块太大检索时容易掺入无关内容模型答非所问块太小可能把完整的语义上下文切断模型光看一小段根本理解不了全貌。所以分块策略的设计本质是在“信息完整性”和“查询精准度”之间找平衡点。1.2 不分块的代价从上下文窗口看分块必要性有些刚入门的朋友会问现在不是有超长上下文的模型了吗几千上万token还不够用够不够用取决于任务类型。如果是单纯的文档摘要超长上下文确实能凑合但如果是做问答型知识库情况完全不同。问答系统的核心流程是“先检索后生成”检索阶段的召回质量决定了回答的天花板。而几乎所有向量检索系统在极端长文本上都会出现“语义稀释”问题——一段话里包含的信息太多向量化后各个主题的语义互相拉扯最终这个向量的方向变得模棱两可和查询的相似度计算自然不准。我举个例子你就能明白假设一本操作手册的第五章同时讲了开机步骤、参数配置、故障报警三个主题你把这整整一章做成一个向量然后问“开机时报错E401怎么办”。这个向量的语义里“开机步骤”和“故障报警”被平均拉扯算出来的相似度会同时低于单独的“开机步骤”向量和“故障报警”向量结果就是检索排名靠后回答质量大打折扣。另外还有个工程上的考量向量数据库的存储和计算成本。同一个文档切一块存一条向量和切十块存十条向量检索时的计算量、存储开销完全是两个量级。虽然现在向量库的规模扩展相对方便但分块策略做得差等于后面所有环节都在给前面“还债”。1.3 分块粒度与后续任务的关联分块不是孤立的一步它和下游任务的耦合度极高。如果你做的是语义检索/知识库问答分块的目标是让每个块承载一个“相对独立且自包含”的信息单元。用户的问题大概率只对应文档里的某一段分块越贴近语义边界检索命中率越高。如果你做的是摘要生成分块粒度可以适当放大因为摘要需要理解整体脉络过度细碎的分块反而让模型“只见树木不见森林”。如果你做的是信息抽取/情感分析分块则需要更细通常以句子甚至短语为单元因为抽取任务关注的是局部语义而不是全局脉络。我做模拟项目X的时候最常被问的一句话就是“有没有万能的分块参数”答案是没有。分块策略必须跟着任务走、跟着数据走、跟着模型走。但好在我们可以总结出一套通用的思考框架和调参流程让每一步都有据可依。这也是这篇文章想真正教会你的东西。2. 分块策略的选型与设计思路2.1 固定长度分块最朴素也最容易被低估固定长度分块是最原始、也是实现成本最低的方案设定一个token数每隔这个长度切一刀必要时让相邻块之间有重叠。# 固定长度分块示例Python伪代码/核心逻辑 def fixed_length_chunk(text, chunk_size512, overlap50): tokens tokenize(text) chunks [] start 0 while start len(tokens): end start chunk_size chunks.append(tokens[start:end]) if end len(tokens): break start end - overlap # 保留重叠区 return chunks看起来无脑但为什么我仍然建议先从它开始因为它能给你一个清晰的“基线”。我习惯的做法是新项目的数据接入后第一版先用固定长度分块跑通整个链路把检索、生成的代码流程都调通再回头优化分块。之所以这样是因为固定长度分块的变量最少——只有块大小和重叠数两个参数出了问题容易定位。而一上来就上递归分块、语义分块这些高级玩法变量太多出了问题你根本分不清是分块策略的问题还是向量化模型的问题还是检索逻辑的问题。固定长度分块最大的弱点在于“切得不管不顾”。一个语义完整的段落可能在中间被拦腰截断前后两个块各剩一半模型理解起来非常吃力。所以这种方案更适合内容结构化程度低、但单条记录本身较短的场景比如客服会话记录、日志文件、商品评价等。在这些数据里每一条天然就是信息单元固定长度分块反而够用。若想改善固定分块的短板一个立竿见影的做法是用句子边界对切割位置做对齐。先按句子切再累积token数直到接近上限遇到超出就在句号处断句。这样虽然本质上还是固定长度但块边界不会落在句子中间语义完整性已经好了很多。2.2 递归分块与结构化分块让块落在“语义自然边界”上如果数据是长文档比如技术手册、规章制度、论文固定长度分块就有点不够看了。我常用的升级方案是递归字符分块Recursive Character Text Splitter。递归分块的思路很简单用一组从大到小的分隔符去递归切分文本。先按段落分隔符比如两个换行切如果切出来的块还大于上限就再按句子分隔符切还不行就按更小的粒度继续切。这样切出来的块边界从大板块逐步收缩到句子层面尽量保证每一块内部语义相对完整。需要注意的是这里的“递归”指的不是把内容反复切而是分隔符优先级逐级下探的过程。很多人在实际使用中只配置了一组分隔符导致切分效果和固定长度分块相差无几这种是没理解递归分块的真正用意。如果数据带有明显结构比如Markdown、HTML、代码文件那就可以用结构化分块器。以Markdown文档为例可以按标题层级切分一级标题、二级标题、三级标题分别作为不同等级的切分边界。这样做的好处是每个块自带“标题上下文”后续检索时甚至可以拿标题做辅助召回。结构化分块还有一层容易被忽略的价值它给每个块赋予了“层级路径”。比如一个块的内容是“修改密码的操作步骤”它所属的标题是“账号管理-“安全设置-“修改密码”。在检索时我们可以把这个路径拼到查询里一起做相似度计算或者直接在MetaData里存一份召回后展示给用户看。这种多一层上下文信息的效果往往能让回答的准确性提升一个明显的台阶。2.3 语义分块与特殊场景是银弹还是玄学再往后走就是语义分块。它不是按固定字数切而是分析文本的语义边界在“意思变化”的地方切。目前比较常见的做法有两种一是利用嵌入模型计算相邻句子向量的相似度相似度突然变低的位置就可能是主题转折点二是借助语言模型本身让模型判断哪里是一个完整语义单元的结束。语义分块的优点很诱人切出来的块大概率是“一个完整意思”信息密度高检索匹配更精准。但代价同样明显计算开销大、处理速度慢而且效果依赖嵌入模型的敏感度。实际项目中我不会在每一版迭代中都跑语义分块通常是先用递归分块把效果做到一定程度发现问题确实集中在“块边界语义漂移”上再针对性尝试语义分块。另外还有一些特殊场景值得一提。代码文件的分块建议按函数、类定义切而不是按行数硬切法律合同可按条款编号切同时保留条款序号对话记录最好按“一轮完整问答”切避免把提问和回答拆到两个块里音视频转写文本则需要结合说话人切换点和时间戳来切。这类领域特化分块往往比任何通用算法都更有效因为它吃透的是数据的“原生气口”。3. 核心参数、实现细节与实操代码3.1 块大小、重叠、分隔符到底怎么定分块三大参数块大小chunk size、块重叠chunk overlap、分隔符集合。很多新手上来就问“块大小设多少合适”我一般反问“你的下游模型窗口多大”和“你的单条知识本身多长”。先说块大小。有一个经验范围对于通用知识库问答以512到1024个字符中文场景或200到500个token英文场景为起步区间对于长文档摘要类任务可上调到1500到2000 token对于短文本抽取类任务降到100到200 token。但这不是硬规则真正的校准方式是拿你的真实问答对去“打命中率”。判定方法很简单准备一批有代表性的问题分别用不同的块大小跑一遍检索统计能够命中正确答案所在块的比例。命中率最高的块大小就是最优值。再说块重叠。重叠的意义在于补偿边界信息丢失。举个例子一段话讲“价格包含运费但不包含保险费”如果分块恰好把“但不包含保险费”切到下一块里前面那个块就只剩下“价格包含运费”检索时如果用户问“含保险费吗”这个块会给出误导信号。设置适当重叠后两个块都能同时包含整句信息误判概率大大降低。重叠数大了信息冗余和存储成本直线上升重叠数小了补偿效果约等于零。一个可用的起步值是块大小的10%到20%。比如块大小是512字符重叠设在50到100字符。如果原始文档里句子普遍较长重叠要偏大一点保证整句完整性。分隔符的选择同样有讲究。不同语言、不同格式分隔符的有效性排序完全不同。中文文本优先考虑句号、问号、感叹号、分号再退到逗号英文同理优先句末标点。Markdown文档优先把“#、##、###”作为一级分隔符再配合换行、句号。代码优先把注释块、函数定义、空行作为边界。3.2 常见框架的落地写法从纯手写到框架封装下面给出一份可以运行的代码思路你可以按需嵌入自己的项目里。import re from typing import List def split_text_by_separators(text: str, separators: List[str]) - List[str]: 递归分隔符分块的简化实现 results [] queue [text] current_sep_index 0 while queue: segment queue.pop(0) sep separators[current_sep_index] # 先用当前分隔符尝试切分 pieces re.split(f({re.escape(sep)}), segment) # 重组保留分隔符 merged [] for i in range(0, len(pieces) - 1, 2): merged_piece pieces[i] pieces[i1] merged.append(merged_piece) if len(merged) 1: # 切不动了换更小的分隔符 if current_sep_index len(separators) - 1: current_sep_index 1 queue.append(segment) else: results.append(segment) else: queue.extend(merged) return results实际项目中我并不建议所有场景都手写分块器。成熟框架里的递归分块实现已经过了大量项目验证稳定性更好。比如知名的LangChain里的递归字符文本分割器以及LlamaIndex里的分块扩展类都支持自定义分隔符、块大小、重叠数封装度很高直接配置参数就行。但我仍然建议你至少手写一次简单版本原因只有一个只有亲手实现过你才真正理解那些参数在底层是怎么起作用的以后遇到框架版本升级、默认参数变化你才不会抓瞎。配置层面常见的做法是{ chunk_size: 800, chunk_overlap: 120, separators: [\n\n, \n, 。, , , , , , ], keep_separator: true, add_start_index: true }这个配置的含义优先按段落切段落太大按句子切最后按字符粒度切重叠区120个字符保留分隔符记录每个块在原文中的起始位置。3.3 分块质量怎么评估不是靠感觉分块策略调了半天怎么知道改好了没有靠肉眼抽查几块样本是不够的需要可量化的评估指标。我常用的有三类。第一类覆盖率。把原始文档的所有关键信息点列出来检查这些信息点是否完整出现且没有被割裂到多个块中。如果某个信息点被拦腰截断还没重叠区兜底那覆盖率就出问题了。第二类检索命中率。拿标注好答案的问答集做测试看每个问题能否在Top-K个检索结果中命中包含答案的那个块。这个指标直接反映分块和检索链路的联合效果是项目上线前最重要的验收标准之一。我自己的经验是在分块调整前后命中率变化超过5%就值得关注超过10%基本能确定问题出在分块上。第三类块间重复度。如果设了重叠不同块之间会有部分内容重合这是正常现象但重合度不宜过高。若块与块之间出现大段重复说明重叠设得过大或分隔符选择不当检索时会出现多个几乎相同的结果块白白占用窗口资源。4. 实操过程与效果对比一个完整案例4.1 模拟项目X从0到1搭建知识库分块流程模拟项目X要处理一批约30万字的中文技术文档目标场景是内部知识库问答。文档范围包括操作手册、FAQ、故障排查指南、版本更新说明。数据特点是格式混杂部分文档带Markdown标题部分文档是纯文本段落。第一版我直接用了固定长度分块块大小512字符无重叠。跑通流程后做了一轮检索质量抽测结果很不理想用户问“如何修改管理员密码”命中的块里出现的是“管理员角色权限表”因为两个文本的字符向量距离较近但内容完全不相关。这类问题就是典型的“块内主题混杂”。第二版换成递归分块分隔符设为换行、句号、分号、逗号块大小仍然是512字符重叠设为75字符。这一版本明显改善了语义漂移问题但出现了另一个典型现象因为带着重叠区每个块都会重复上一块的尾巴在检索时经常返回两个非常相似的块回答时来回引用显得很啰嗦。第三版我把分隔符优先级调整到匹配业务格式解析文档标题层级优先按Markdown标题切分块大小放宽到768字符。这样做带来的效果是整个流程精简很多——因为标题本身就是文本结构的语义边界。同时我加了start_index元数据便于回溯原文定位。4.2 三版分块策略的效果对比分块方案块平均长度检索命中率50题测试集单批处理耗时主要问题固定512无重叠51252%3秒语义边界被切断主题混杂递归512重叠7558768%6秒块间重复度高检索冗余递归标题优先76878479%8秒无明显短板个别长段落需二次切分从数据能看出来第三版在命中率上提升显著。有一个细节值得注意单批耗时从3秒涨到8秒这中间很大一部分开销来自按标题解析和更细粒度的分隔符匹配。对离线建库场景来说这点时间完全可以接受但如果你做的是实时流式分块就要在效率和效果之间权衡可能需要牺牲一部分分块精细度。单靠命中率还不够。我又做了一轮A/B测试拿100个高频问题对比第二版和第三版的实际回答质量采用“人工打分回答追溯”的方案评估。第三版在“回答能否定位到原文具体段落”上优势明显因为每个块因为嵌入了标题层级信息回答溯源时可以直接展示“引自某章某节”用户信任度高了很多。5. 常见问题与排查技巧实录5.1 高频问题速查表现象可能原因排查与解决检索结果全是无关块块过大主题混杂降低块大小切换分隔符优先级改用语义分块一个问题命中多个几乎相同的块重叠过大或分隔符失效降低重叠增加强分隔符检查分隔符是否在文本中真实存在部分知识点完全检索不到该知识点被切碎且无重叠兜底增大重叠把分块边界向句子边界对齐加语义分块回答内容张冠李戴块内包含两个主题按标题/章节优先切分提高分隔符优先级核对块内容是否主题单一存储成本激增块数过多或重叠过大增大块大小降低重叠合并短块同一问题不同批次回答不一致检索排名不稳定检查向量模型一致性检查文本切分是否随机统一随机种子5.2 踩坑实录三个容易翻车的地方第一个坑是分隔符根本不匹配。有次接手某项目配置里写了用“//”做分隔符但实际文档里用的是全角符号。结果分隔符一个都没命中递归分块退化成固定长度分块效果自然好不了。排查方法很简单运行一次分块后抽几个块看边界是否落在预期位置。如果边界落在所有奇怪的地方大概率是分隔符没匹配上。第二个坑是中文切分中的Token标点问题。中文不像英文那样天然按空格分词标点、助词、成语都会影响token化。最开始我设块大小为512字符时配的是英文模型的字符映射结果中文字符数对了但token数严重超限下游模型处理时频繁截断。后来我在分块后统一过一遍tokenizer计数把字符数和token数做成对照表才彻底解决这个问题。第三个坑是最隐蔽的重复内容导致召回失控。文档里经常有大段重复引用比如公司制度汇编里前后两章都粘贴了一大段“安全注意事项”。固定长度分块时这两个块内容高度相似检索时老是同时把两个块揪出来。优化方案是建库前先做一遍相似度去重或者在分块阶段就把重复内容标记出来检索时对这类块做降权处理。5.3 让分块策略持续可维护的落地建议分块策略不是一次定稿就万事大吉的。上线后新版本文档、新格式数据随时会打破原有假设。我现在的做法是建一套定期回归机制维护一份带标准答案的问答集每次修改分块配置后自动跑一遍全部测试问题对比命中率变化。命中率下滑超过阈值就自动告警避免出现“改完上线了才发现检索崩了”的尴尬局面。另外数据格式的变化也要纳入监控。比如之前文档一直是Markdown风格某一天运营团队开始上传纯扫描版PDF转换出来的无结构文本之前按标题切分的逻辑就全部失效了。所以我会在产品后台保留一个“文档格式分布”的看板格式结构发生变化时第一时间感知到并主动调整分块策略。更进一步的方案是把分块策略做成可配置的规则集放到一个“分块策略表”里不同数据源绑定不同的策略。技术手册走Markdown标题分块FAQ走固定短分块故障日志走时间戳分块对话记录走会话边界分块。每个策略都能独立调整参数互不干扰。这样看起来增加了配置复杂度但长期维护下来收益远大于成本。6. 我对文本分块策略的一些个人体会分块这件事在项目里的优先级经常被排得很靠后但它对系统整体质量的影响权重非常靠前。我见过不少团队花几周时间微调模型、优化Prompt检索效果却始终上不去最后换了分块策略问题迎刃而解。所以我的习惯是新项目第一周一定要把分块流程单独拎出来做一轮压力测试确认这块稳定了再铺开做上层功能。如果你现在刚接触Chunking我给你的落地路径是先用固定长度分块把整个RAG链路跑通再用递归分块拉高效果接着根据数据格式尝试结构化分块最后用测试集做好回归评估。千万不要一上来就想上最复杂的分块方案先有基线再谈优化是比较稳妥的行事方式。最后分享一个实测了多次的小技巧分块时建议保留一段“句级过渡区”不直接切在句号之前而是让块延伸到下一个句子的开头几个字。这样模型在读块的时候能隐约感知到下一块的语气启动在多轮问答中上下文连续性会明显好上不少。这个技巧在短文本问答场景里效果尤其明显你完全可以拿去直接试。