1. 分块为什么成了RAG项目的胜负手前两年做RAG项目我一直以为检索效果不好是Embedding模型的锅换了个更强的向量模型结果提升微乎其微。后来认真排查才发现真正卡住我的是文本分块方案。分块Chunking在RAG链路里排在第一个却是最容易被人忽略的环节。文档进来之后先切成一个个独立的小块再做Embedding入库。检索时用户的问题也向量化然后去向量库里找相似块最后把这些相似块拼起来丢给大模型生成答案。你会发现如果这一刀切得不对后面无论Embedding多强、Rerank多准、大模型多聪明都是白搭——检索回来的内容本身就不对生成结果怎么可能对。一个很典型的例子你把一篇制度文件按固定200个字切块正好把一个完整条款从中间截断下半句存到了下一个块里。用户问“这个费用能报销吗”检索命中的块只包含上半句“报销标准如下无”那大模型就只能一本正经地告诉你“不能报销”。这种问题换什么模型都救不回来。这篇文章我是写给正在做RAG实战的人看的。不管你是用LangChain、LlamaIndex这类框架还是自己手写RAG管道又或者正在搞知识库问答、企业文档助手、政务制度问答分块方案的选型和调优都是你绕不开的环节。我会把目前实践中真正常用的七种分块技术方案逐一拆开来讲讲清楚它们的原理、适用场景、参数怎么调、坑在哪里最后再给一份组合使用的实战建议。这七种方案没有绝对的优劣之分它们各自适合不同的文档类型、检索粒度和算力预算。看完之后你应该能对着自己的业务场景直接做出选择而不是再到处翻文档查“到底用哪种”。2. 七种分块技术方案全景对比先把七种方案亮出来后面再逐一展开。为了方便记忆我把它们分成两大类一类是“规则驱动型”靠字符数、分隔符、文档结构来切另一类是“语义驱动型”靠Embedding相似度甚至大模型理解来切。规则驱动型方案包括固定长度分块、递归字符分块、文档结构感知分块、句子级滑动窗口分块。语义驱动型方案包括父子分块、语义分块、上下文增强分块也有人叫Agentic分块。在实际项目中我见过很多团队把其中两到三种混着用形成多路召回效果往往比单一方案好不少。先看全景对比表这样对整体有个概念方案核心切分依据典型场景计算成本检索粒度典型配置固定长度分块字符数/token数日志、对话流、纯文本极低粗chunk_size512, overlap50递归字符分块分隔符优先级通用知识库、新闻、说明文档低中按段落优先再按句子文档结构感知标题/章节/标签制度文件、产品手册、HTML/Markdown中中细按H1/H2/H3切保留标题句子级滑动窗口句子边界窗口FAQ、短问答、句子语义较强的文本低极细window3~5句父子分块子块检索、父块输出需要完整上下文的知识问答中细检索粗输出子块256字符父块整节语义分块Embedding相似度断点长文、讲义、逻辑段落明显的文本较高动态候选句相似度突降断点上下文增强分块LLM生成上下文摘要检索精度要求高的私有知识库高自定义每个块附加来源、主题、关联上下文这里我要先说一句大实话别指望选一个方案就一劳永逸。我做过一个政务知识库项目制度类文档适合结构感知分块而通知公告类文档又更适合递归字符分块最后我是在同一套系统里对不同数据源使用了不同的分块方案才把检索命中率拉到可用水平。这也是为什么我把“多路召回和混合分块”单独留了一章来讲的原因。3. 规则驱动型分块基础方案到结构感知方案3.1 固定长度分块最朴素也最容易踩坑固定长度分块就是按固定的字符数或token数硬切比如每512个字符切一块。这是最直观的方案很多刚接触RAG的人第一版代码都是这么写的。实现逻辑很简单def fixed_size_chunk(text, chunk_size512, overlap50): chunks [] start 0 while start len(text): end start chunk_size chunks.append(text[start:end]) start end - overlap return chunks注意这里有两个关键参数chunk_size控制每块长度overlap控制相邻块之间的重叠字数。overlap的作用是避免一句话正好被截在边界上通过让相邻块共享一部分文本把语义断点的影响降到最低。我见过有人设置overlap0结果检索效果明显变差——因为被截断的关键信息永远找不到完整上下文。固定长度分块的优点就一个字快。不管什么文档进来处理时间基本可以预估Embedding调用成本也稳定。缺点是切出来的块几乎必然存在语义割裂一个完整段落可能被劈成两半一个列表项可能缺了后半截。这个方案真正适合的场景是那种没有明显结构、内容密度均匀的文本。比如聊天记录、日志文件、法律条文这种短句多且相对独立的文本切成固定长度反而不容易破坏什么关键语义。至于长篇的论述型文档、制度文件、技术手册我强烈不建议直接用固定长度哪怕加了overlap也只是把问题从“边界截断”变成“边界截断的概率降低”并不能根治。3.2 递归字符分块日常项目的主力方案如果你去翻LangChain的默认文本分块器大概率会遇到RecursiveCharacterTextSplitter这就是递归字符分块。它比固定长度聪明的地方在于不是硬按长度切而是按照一组分隔符的优先级来切。它的执行逻辑是这样的先按段落分隔符比如两个换行尝试切分如果切出来的块还是太大再按句子分隔符句号、问号、感叹号切要是还大就再按逗号、分号、空格等切。整个过程可以理解成“先礼后兵”——尽量保留语义完整的段落和句子实在不行才退到字符级。separators [\n\n, \n, 。, , , , , , ] def recursive_split(text, max_len): if len(text) max_len: return [text] for sep in separators: parts text.split(sep) if len(parts) 1: result [] buffer for part in parts: if len(buffer) len(part) max_len: buffer part sep else: result.extend(recursive_split(buffer, max_len)) buffer part sep if buffer: result.extend(recursive_split(buffer, max_len)) return result return [text[:max_len]]上面的实现只是示意生产环境建议直接用成熟框架的方法别重复造轮子。为什么说它是主力方案因为绝大多数知识库文档都是“段落句子短语”的结构递归字符分块能最大程度地保证切出来的块落在自然语义边界上同时实现成本又很低不需要额外的大模型调用也不需要复杂的依赖。我在通用知识库项目里第一版基本都是先用它跑通全链路拿到基线指标再说。参数上主要关注chunk_size和overlap。chunk_size设多大跟你的Embedding模型和最终生成模型都有关系。以常见的文本Embedding模型为例512到1024个字符都是相对安全的区间如果文档本身段落很长可以把上限稍微放宽一点但别超过1500字符——太长的块会让向量表示的语义变模糊检索精度反而下降。3.3 文档结构感知分块政务、制度、产品手册的最优解这个方案的核心思路是既然源文档本来就有标题、章节、列表这些结构那就顺着结构来切。比起靠分隔符猜语义边界直接读取Markdown的标题层级、HTML的标签、PDF的目录结构切出来的块天然和文档的逻辑单元对齐。我做过一个政务知识库项目里面全是政策文件、制度汇编、办事指南。这种文档的特点是有非常清晰的层级——章、节、条、款、项。如果拿递归字符分块去切遇到一条很长的条款一样会被拦腰截断但如果识别出“第X条”这个结构边界把它当作一个切分点那么每个块就是一个完整条款检索命中率会质变。在实际实现里常见的做法是这样Markdown/HTML文档按H1、H2、H3标签逐级嵌套切分同时把标题文本保留到每个子块前面作为前缀。PDF文档先用文档解析工具抽取目录大纲和标题位置再根据标题位置确定每个章节的范围。Word/PDF制度文件把“第X条”“X”“一、二、三”等结构化关键词当作切分点。这里有一个非常容易被忽略的细节切完块之后一定要把块的“结构上下文”保留下来而不是只存正文。什么意思比如一个块的内容是“第四十二条规定……”你最好把“第三章 财务管理”这个标题也拼到块头部再一起Embedding。这样用户问“报销流程”的时候向量检索才能感知到“这个块属于财务章节”匹配精度会明显提升。结构感知分块的缺点是处理成本高一些因为要先解析文档结构不同格式的文档要分别写解析逻辑。而且很多历史扫描PDF根本没有结构信息这时候就只能退而求其次用递归字符分块。但对制度、手册、标准、规范这类结构化程度很高的文档这个方案值得投入。3.4 句子级滑动窗口分块检索片段的最小化尝试句子级分块的思想是把每个句子当成独立的小块进行Embedding检索的时候找出最相关的那一两个句子再把它周围的上下文句子补上一起送给大模型。这种“切小块检索、补窗口输出”的模式特别适合处理短问答场景。比如FAQ类知识库用户问“离职了公积金怎么提取”答案其实就一两句话你如果返回一个512字符的大块里面可能有一半内容是不相关的但如果按句子切检索回来的就是精准的那一句再带上前后两三句作为缓冲效果会好很多。我举一个常用实现思路先用NLP工具或者简单规则把文本拆成句子然后以当前句为中心向前向后各取N个句子合并成一个检索单元。这里的N就是窗口大小一般取2到3比较合理。窗口越大上下文越完整但噪声也可能越多窗口太小语义可能缺胳膊少腿。原始文本A句。B句。C句。D句。E句。F句。 窗口大小2 索引1 - A句。B句。C句。 索引2 - B句。C句。D句。 索引3 - C句。D句。E句。这种方案在LangChain里也有对应的Splitter核心参数是window_size和step。需要提醒的是句子的划分质量直接决定效果。中文还好一些句号、问号、感叹号基本能覆盖绝大多数情况英文要注意缩写点、小数点和引用格式否则会把一句话切成好几截。句子级分块不适合那种一个知识点需要跨多个段落展开的复杂文档。用户问的是需要综合多处论据才能回答的问题时单句窗口往往信息量不够。这时候我建议你往后看父子分块它才是为这类场景设计的。4. 语义驱动型分块让模型参与理解规则驱动型方案无论怎么切本质上是靠“表面的符号特征”来猜语义边界。那么有没有一种方式直接让模型判断“哪些句子放在一起是语义上完整的”这就是语义驱动型分块做的事。它们通常需要更多的计算资源但换来的往往是更符合人类阅读习惯的检索单元。4.1 父子分块兼顾检索精度和上下文完整性父子分块在业界的普及度越来越高它的核心思路是建两套索引层级。子块是细粒度的短块负责和用户的查询做精确匹配父块是粗粒度的长块负责在大模型生成时提供完整上下文。打个比方这就像查字典。你通过词条索引子块快速定位到某个词在第几页但真正阅读的时候你看的是整个词条的完整解释父块。这样既避免了短查询在大文本块里“淹没”又避免了只给一句话导致生成时缺上下文。具体实现流程是这样的先把文档按较大粒度切成长段这些是父块通常是1000到2000字符对应一个章节或一个完整主题。再在父块内部按较小粒度切出子块通常是200到500字符。Embedding只对子块做。检索时用子块去匹配用户查询命中子块后把所属的父块整体返回给大模型。子块负责“定位准”父块负责“上下文全”。这个方案尤其适合那些“答案需要覆盖多个子观点才能说清楚”的知识问答场景比如规章制度里的处罚条款、审计流程的多步骤说明。我在一个企业知识库项目里是这么配的子块用固定长度切256字符加30字符重叠父块按段落或章节切最多1000字符。为什么子块不用递归字符切因为子块本身很细递归切分反而容易把相对完整的短句合并得比较随机固定长度加上适度重叠在这个粒度下表现很稳定。要提醒的是父子分块会让索引结构变复杂检索的时候需要维护“子块ID到父块ID”的映射关系同时因为返回的是父块可能会超出大模型的上下文窗口所以一般还要配合截断策略或者只取父块中与子块位置相邻的一小段文本。4.2 语义分块用向量相似度找断点语义分块英文叫Semantic Chunking思路是让Embedding模型自己判断句子的语义转折。先把文本切成一串候选句子然后逐句做向量化计算相邻句子向量的余弦相似度。当相似度出现明显下降时说明语义发生了转折这里就是一个合适的分块断点。听起来很巧妙但实现起来有几个细节要处理。候选句怎么切、相似度差多少算“明显下降”、最小块长度怎么限制这些都是需要试出来的。我梳理了一个基本的实现流程1. 将文本按句子切分为候选句列表 S [s1, s2, ..., sn] 2. 对每个句子做Embedding得到向量列表 V [v1, v2, ..., vn] 3. 计算相邻句子的余弦相似度 sim(v1,v2), sim(v2,v3), ... 4. 计算相似度的均值 mu 和标准差 sigma 5. 当相邻相似度 mu - k*sigmak通常取1~2时判定该处为断点 6. 把所有断点拼起来得到语义分块结果为什么用“均值减k倍标准差”而不是固定阈值因为不同文档的全局相似度分布差异很大。制度文件前后句子高度相关classical的句子可能频繁转折。固定阈值很难一套通吃用统计量来标定“相对于这篇文档的突变程度”会更稳妥。语义分块的优点很明显它不依赖显式结构对没有标题、排版混乱的长文本也有不错的处理效果。比如论文全文转过来的纯文本、课程讲稿、访谈记录这些文档用递归字符分块切出来的块经常出现“前面还在讲概念后面突然跳到案例”的问题语义分块能大大缓解。缺点也很实在计算成本高。每句话都要过一遍Embedding长文档的向量化调用量会比普通方案高一个数量级而且断点判定对超参数比较敏感需要有一套带标注的测试集来调。我的建议是如果你的文档规模不大几千篇以内、文本质量偏高值得用语义分块如果是千万级大规模语料成本往往hold不住还是退回结构感知方案更划算。4.3 上下文增强分块让大模型给每个块写“自我介绍”这个方案是最近在RAG实战社群和Agentic RAG语境里频繁被提到的一种做法。我最早是在Anthropic提出的一篇关于Contextual Retrieval的技术内容里看到完整思路的核心思想很简单单独一个文本块在向量化的时候缺少全局上下文导致检索时语义匹配不上那么在向量化之前先让LLM给每个块写一段包含来源、主题、相关背景的上下文描述把这段描述和原块拼在一起再做Embedding。比如一个制度文件中有个块写的是“全年不得超过十万元”。这句话单独看非常模糊什么不得超过十万元如果Embedding只看到这句话用户问“年度预算上限”很可能匹配不到。但如果你让LLM生成一段上下文说明“本块选自XX公司财务报销管理制度第三章关于年度差旅费用预算的规定前文规定了报销审批流程此处明确部门年度差旅费用预算总额上限为十万元”拼接之后做Embedding检索命中率会有非常显著的提升。这个方案的实现逻辑更像Agentic——每个块的处理不再是单纯的字符串切割而是一次独立的“大模型理解改写”调用。所以有人把它归到Agentic RAG的范畴。具体流程是1. 先用任意规则方案切出基础块 2. 对每个块构造提示词请根据整个文档上下文为以下文本生成一段30~50字的说明 包括来源章节、主题、关联背景等 3. LLM返回上下文描述 4. 将“上下文描述 原始块”拼接作为最终Embedding的输入 5. 入库时同时保存描述、原始块、所在文档ID我实际测试下来这个方案对检索精度的提升是最直接的尤其适合那种单个块看起来“字面意思不完整”的场景。但它也是最烧钱的每个块都要调用一次LLM小规模文档还好到了几十万块的规模成本和时间需要认真评估。还有一种折中做法值得推荐只让LLM为“检索命中率低”的部分——比如较短的块、字面歧义大的块——做上下文增强普通的段落直接跳过。这样能把成本控制在一个比较现实的范围。5. 分块参数调优与多路召回实践5.1 关键参数怎么定chunk_size、overlap、断点阈值很多人在分块上栽跟头不是因为不知道有哪些方案而是不知道参数该怎么调。这里我给出一个比较务实的调参次序你可以直接照着试。先定chunk_size。chunk_size不是越大越好也不是越小越好。它跟三个因素强相关Embedding模型的最大输入长度、大模型的上下文窗口、文档内容本身的粒度。经验做法是先看Embedding模型支持多少token。比如输入上限是512 token的模型你在中文场景下大约对应700到1000个汉字那么chunk_size取500到600个汉字会比较稳留出富余量给后续可能拼接的上下文描述。再调overlap。overlap的典型值在chunk_size的10%到20%之间。512字符的块overlap取50到80比较常见。overlap太大会导致相邻块大量重复检索时同一个段落被多次返回浪费上下文空间太小则起不到防止截断的作用。最后是语义分块的断点阈值。前面提过用mu - k*sigma的方法k的取值需要在你的验证集上调。我的建议是先取1.5作为基线如果切出来的块数量太多、平均长度太短就往大调比如2.0如果块的语义内部依然有明显跳跃就往小调。这里要强调一个很容易被忽视的原则调参的依据永远是“你的验证集”不是直觉。建一套至少一两百条业务问题的评测集人工标注好标准答案和参考文档段落然后用不同的参数组合跑检索对比召回率、命中位置、生成答案的准确率用数据说话。5.2 多路召回同一份文档用不同分块方案并行多路召回在搜索领域是老生常谈但在RAG里结合分块来做效果常常出人意料。核心做法是对同一份文档同时用两到三种分块方案建多套索引查询时分别检索然后把多路结果合并、去重、重排。为什么这么做有效因为不同分块方案的“信息视野”不一样。固定长度分块虽然容易切断句子但它的块边界稳定检索时不容易漏掉长段落中的局部内容结构感知分块对章节把握准但在细节匹配上可能不够细。多路召回本质上是用多个视角去看同一份文档降低单一分块方案的系统性偏差。常见的组合我试过这几组组合适用场景效果说明递归字符分块 句子级窗口通用文档、FAQ兼顾段落级语义和句子级精确定位结构感知分块 父子分块制度文件、手册章节上下文完整条款细粒度可命中固定长度分块 语义分块长文、论文、讲义全局检索不遗漏语义边界更准确多路结果合并的时候一个简单有效的策略是RRFReciprocal Rank Fusion它不依赖分数绝对值而是把每条结果在各自路内的排名取倒数再求和排名越靠前贡献越大。这个方式对“各路分数尺度不一致”的问题非常鲁棒实现也就十几行代码。# RRF简易实现 def rrf_fusion(result_lists, k60): scores {} for results in result_lists: for rank, doc_id in enumerate(results): scores[doc_id] scores.get(doc_id, 0) 1 / (k rank 1) return sorted(scores.items(), keylambda x: x[1], reverseTrue)这里要注意多路召回会带来检索延迟和存储成本上升。每增加一路索引就需要多一遍Embedding调用和检索查询。不建议一开始就上三路以上先两路并联观察收益如果召回率提升不明显说明瓶颈不在分块可能要去看看Embedding模型或Rerank层面的问题。5.3 一个企业知识库的混合分块实际配置拿我之前做过的一个企业制度知识库来举例。这套系统里的文档类型大致有三类规章制度、操作手册、公告通知。一开始我统一用递归字符分块结果是制度类文档的条款经常被切断操作手册里的步骤列表被拆得七零八落公告通知反而还行。后来我按文档类型做了分路处理规章制度走结构感知分块。先用正则识别“第X条”“第X章”以条为基本块保留章节标题作为块前缀。子块控制在400字符。操作手册走父子分块。父块是每个操作步骤的大节子块是单个步骤或步骤中的说明文字。子块200到300字符。公告通知走递归字符分块chunk_size600overlap60。这样改完评测集上的Top-5命中率从54%提到了79%效果非常直观。所以你看实际项目里的分块方案不是一道单选题而是一套需要根据数据源定制的策略组合。5.4 与Rerank的配合分块决定了Rerank的天花板最后补一句关于Rerank的话。很多项目上了Rerank之后发现效果提升不大原因往往就是分块太粗Top-20里压根没有正确答案Rerank再怎么排也排不出来。Rerank的作用是把“基本相关的候选”排到前面而不是凭空变出相关片段。所以分块方案的目标应该调整为“提供高质量、高覆盖率的候选集”在此基础上Rerank才能最大化发挥价值。实操中的先后顺序应该是先用分块方案提高Top-20的召回率再靠Rerank提高Top-5的准确率。如果直接上来堆Rerank花钱多收益却有限。这也是为什么我在项目里一直强调分块多花点时间后面整个链路都会轻松很多。6. 常见问题与排查技巧实录写项目复盘的时候我把这两年遇到的典型问题整理成了一份速查表分享出来希望能帮你少走弯路。6.1 检索召回的内容前言不搭后语现象用户问了一个具体问题召回的块文本里明明包含了关键词但句子不完整语义残缺。原因大概率是固定长度分块把句子截断了或者chunk_size太小块内容不够表达一个完整语义。排查步骤先打开召回结果里那几个块肉眼检查是不是存在半句话。是的话换成递归字符分块并把chunk_size适当调大。确认overlap是否在合理区间如果没有重叠加上10%到20%的重叠。6.2 召回结果太短大模型无法组织完整答案现象召回的内容是一个孤零零的句子信息量不够支撑回答。原因句子级分块或子块切得过于细缺少上下文。排查步骤看当前是不是句子级窗口分块窗口大小是否只有1或2。加大窗口到3到5句。换成父子分块子块负责定位父块负责提供完整段落。如果用的是父子分块检查返回逻辑是否正确返回了父块。我见过有人把子块直接送去生成了导致上下文缺失。6.3 长文档的中间段落永远搜不到现象文档开头和结尾的块经常被命中中间部分几乎从不出现。原因很多Embedding模型对处于长文档中部的内容在向量空间中区分度不高容易被两端的强语义片段压制也有可能是分块时中间部分的标题或上下文信息丢失。排查步骤给中间块补充结构前缀把所属章节标题拼到块头再做Embedding。检查是否用了整体文档Embedding再切块的做法这会让所有块共享全局向量中间信息被稀释改成逐块独立Embedding。适当缩小chunk_size让中间部分的局部语义更聚焦。6.4 Embedding调用量暴涨成本失控现象换了语义分块或上下文增强分块之后账单飙升。原因逐句向量化和逐块LLM调用都属于高成本方案如果没有做成本规划很容易失控。排查步骤确认是否所有文档都适合用高成本方案。很多短文本用递归字符分块就够了不需要逐句Embedding。上下文增强分块可以只对“字面歧义大”的块启用。先用普通方案跑一遍筛出检索命中率低的块再对这部分做二次处理。可以考虑用批量调用、缓存相同或相似块结果来降低成本。6.5 分块参数怎么调才靠谱回归测试是底线最后一个心得也是我踩坑最重的一条分块方案和参数的改动一定要用回归测试来验收不要凭感觉。很多RAG项目改了一轮分块参数看起来问答效果好了但换个测试集又打回原形就是因为没有建立稳定评测集。你可以这样建一个最小的评测流程准备100到200条有代表性的业务问题每条标注好对应的参考文档ID和标准答案。跑一遍“分块 - 检索 - Rerank - 生成”全链路记录Top-5命中率和最终答案正确率。修改分块方案或参数后重跑同一套评测对比指标变化。注意不要只记录“答案对不对”还要记录“正确答案是否出现在召回候选中”。如果命中了但生成不好问题大多在提示词或大模型如果压根没召回那才真正需要回去改分块。我个人在项目中的经验是建立这套评测流程后分块方案的迭代就从一个“靠玄学”的过程变成了一个纯工程过程后续不管是换Embedding模型、调chunk_size还是加多路召回都有了明确的判断依据。最后再分享一个小技巧动手写代码之前把一个项目的文档类型清单和典型查询问题列出来对着这两个列表去选分块方案比任何技术文章的推荐都靠谱。毕竟分块砍下去的那一刀最终还是为了解决你业务里的具体问题。
RAG分块方案全解析：七种文本切分技术与实战调优指南
1. 分块为什么成了RAG项目的胜负手前两年做RAG项目我一直以为检索效果不好是Embedding模型的锅换了个更强的向量模型结果提升微乎其微。后来认真排查才发现真正卡住我的是文本分块方案。分块Chunking在RAG链路里排在第一个却是最容易被人忽略的环节。文档进来之后先切成一个个独立的小块再做Embedding入库。检索时用户的问题也向量化然后去向量库里找相似块最后把这些相似块拼起来丢给大模型生成答案。你会发现如果这一刀切得不对后面无论Embedding多强、Rerank多准、大模型多聪明都是白搭——检索回来的内容本身就不对生成结果怎么可能对。一个很典型的例子你把一篇制度文件按固定200个字切块正好把一个完整条款从中间截断下半句存到了下一个块里。用户问“这个费用能报销吗”检索命中的块只包含上半句“报销标准如下无”那大模型就只能一本正经地告诉你“不能报销”。这种问题换什么模型都救不回来。这篇文章我是写给正在做RAG实战的人看的。不管你是用LangChain、LlamaIndex这类框架还是自己手写RAG管道又或者正在搞知识库问答、企业文档助手、政务制度问答分块方案的选型和调优都是你绕不开的环节。我会把目前实践中真正常用的七种分块技术方案逐一拆开来讲讲清楚它们的原理、适用场景、参数怎么调、坑在哪里最后再给一份组合使用的实战建议。这七种方案没有绝对的优劣之分它们各自适合不同的文档类型、检索粒度和算力预算。看完之后你应该能对着自己的业务场景直接做出选择而不是再到处翻文档查“到底用哪种”。2. 七种分块技术方案全景对比先把七种方案亮出来后面再逐一展开。为了方便记忆我把它们分成两大类一类是“规则驱动型”靠字符数、分隔符、文档结构来切另一类是“语义驱动型”靠Embedding相似度甚至大模型理解来切。规则驱动型方案包括固定长度分块、递归字符分块、文档结构感知分块、句子级滑动窗口分块。语义驱动型方案包括父子分块、语义分块、上下文增强分块也有人叫Agentic分块。在实际项目中我见过很多团队把其中两到三种混着用形成多路召回效果往往比单一方案好不少。先看全景对比表这样对整体有个概念方案核心切分依据典型场景计算成本检索粒度典型配置固定长度分块字符数/token数日志、对话流、纯文本极低粗chunk_size512, overlap50递归字符分块分隔符优先级通用知识库、新闻、说明文档低中按段落优先再按句子文档结构感知标题/章节/标签制度文件、产品手册、HTML/Markdown中中细按H1/H2/H3切保留标题句子级滑动窗口句子边界窗口FAQ、短问答、句子语义较强的文本低极细window3~5句父子分块子块检索、父块输出需要完整上下文的知识问答中细检索粗输出子块256字符父块整节语义分块Embedding相似度断点长文、讲义、逻辑段落明显的文本较高动态候选句相似度突降断点上下文增强分块LLM生成上下文摘要检索精度要求高的私有知识库高自定义每个块附加来源、主题、关联上下文这里我要先说一句大实话别指望选一个方案就一劳永逸。我做过一个政务知识库项目制度类文档适合结构感知分块而通知公告类文档又更适合递归字符分块最后我是在同一套系统里对不同数据源使用了不同的分块方案才把检索命中率拉到可用水平。这也是为什么我把“多路召回和混合分块”单独留了一章来讲的原因。3. 规则驱动型分块基础方案到结构感知方案3.1 固定长度分块最朴素也最容易踩坑固定长度分块就是按固定的字符数或token数硬切比如每512个字符切一块。这是最直观的方案很多刚接触RAG的人第一版代码都是这么写的。实现逻辑很简单def fixed_size_chunk(text, chunk_size512, overlap50): chunks [] start 0 while start len(text): end start chunk_size chunks.append(text[start:end]) start end - overlap return chunks注意这里有两个关键参数chunk_size控制每块长度overlap控制相邻块之间的重叠字数。overlap的作用是避免一句话正好被截在边界上通过让相邻块共享一部分文本把语义断点的影响降到最低。我见过有人设置overlap0结果检索效果明显变差——因为被截断的关键信息永远找不到完整上下文。固定长度分块的优点就一个字快。不管什么文档进来处理时间基本可以预估Embedding调用成本也稳定。缺点是切出来的块几乎必然存在语义割裂一个完整段落可能被劈成两半一个列表项可能缺了后半截。这个方案真正适合的场景是那种没有明显结构、内容密度均匀的文本。比如聊天记录、日志文件、法律条文这种短句多且相对独立的文本切成固定长度反而不容易破坏什么关键语义。至于长篇的论述型文档、制度文件、技术手册我强烈不建议直接用固定长度哪怕加了overlap也只是把问题从“边界截断”变成“边界截断的概率降低”并不能根治。3.2 递归字符分块日常项目的主力方案如果你去翻LangChain的默认文本分块器大概率会遇到RecursiveCharacterTextSplitter这就是递归字符分块。它比固定长度聪明的地方在于不是硬按长度切而是按照一组分隔符的优先级来切。它的执行逻辑是这样的先按段落分隔符比如两个换行尝试切分如果切出来的块还是太大再按句子分隔符句号、问号、感叹号切要是还大就再按逗号、分号、空格等切。整个过程可以理解成“先礼后兵”——尽量保留语义完整的段落和句子实在不行才退到字符级。separators [\n\n, \n, 。, , , , , , ] def recursive_split(text, max_len): if len(text) max_len: return [text] for sep in separators: parts text.split(sep) if len(parts) 1: result [] buffer for part in parts: if len(buffer) len(part) max_len: buffer part sep else: result.extend(recursive_split(buffer, max_len)) buffer part sep if buffer: result.extend(recursive_split(buffer, max_len)) return result return [text[:max_len]]上面的实现只是示意生产环境建议直接用成熟框架的方法别重复造轮子。为什么说它是主力方案因为绝大多数知识库文档都是“段落句子短语”的结构递归字符分块能最大程度地保证切出来的块落在自然语义边界上同时实现成本又很低不需要额外的大模型调用也不需要复杂的依赖。我在通用知识库项目里第一版基本都是先用它跑通全链路拿到基线指标再说。参数上主要关注chunk_size和overlap。chunk_size设多大跟你的Embedding模型和最终生成模型都有关系。以常见的文本Embedding模型为例512到1024个字符都是相对安全的区间如果文档本身段落很长可以把上限稍微放宽一点但别超过1500字符——太长的块会让向量表示的语义变模糊检索精度反而下降。3.3 文档结构感知分块政务、制度、产品手册的最优解这个方案的核心思路是既然源文档本来就有标题、章节、列表这些结构那就顺着结构来切。比起靠分隔符猜语义边界直接读取Markdown的标题层级、HTML的标签、PDF的目录结构切出来的块天然和文档的逻辑单元对齐。我做过一个政务知识库项目里面全是政策文件、制度汇编、办事指南。这种文档的特点是有非常清晰的层级——章、节、条、款、项。如果拿递归字符分块去切遇到一条很长的条款一样会被拦腰截断但如果识别出“第X条”这个结构边界把它当作一个切分点那么每个块就是一个完整条款检索命中率会质变。在实际实现里常见的做法是这样Markdown/HTML文档按H1、H2、H3标签逐级嵌套切分同时把标题文本保留到每个子块前面作为前缀。PDF文档先用文档解析工具抽取目录大纲和标题位置再根据标题位置确定每个章节的范围。Word/PDF制度文件把“第X条”“X”“一、二、三”等结构化关键词当作切分点。这里有一个非常容易被忽略的细节切完块之后一定要把块的“结构上下文”保留下来而不是只存正文。什么意思比如一个块的内容是“第四十二条规定……”你最好把“第三章 财务管理”这个标题也拼到块头部再一起Embedding。这样用户问“报销流程”的时候向量检索才能感知到“这个块属于财务章节”匹配精度会明显提升。结构感知分块的缺点是处理成本高一些因为要先解析文档结构不同格式的文档要分别写解析逻辑。而且很多历史扫描PDF根本没有结构信息这时候就只能退而求其次用递归字符分块。但对制度、手册、标准、规范这类结构化程度很高的文档这个方案值得投入。3.4 句子级滑动窗口分块检索片段的最小化尝试句子级分块的思想是把每个句子当成独立的小块进行Embedding检索的时候找出最相关的那一两个句子再把它周围的上下文句子补上一起送给大模型。这种“切小块检索、补窗口输出”的模式特别适合处理短问答场景。比如FAQ类知识库用户问“离职了公积金怎么提取”答案其实就一两句话你如果返回一个512字符的大块里面可能有一半内容是不相关的但如果按句子切检索回来的就是精准的那一句再带上前后两三句作为缓冲效果会好很多。我举一个常用实现思路先用NLP工具或者简单规则把文本拆成句子然后以当前句为中心向前向后各取N个句子合并成一个检索单元。这里的N就是窗口大小一般取2到3比较合理。窗口越大上下文越完整但噪声也可能越多窗口太小语义可能缺胳膊少腿。原始文本A句。B句。C句。D句。E句。F句。 窗口大小2 索引1 - A句。B句。C句。 索引2 - B句。C句。D句。 索引3 - C句。D句。E句。这种方案在LangChain里也有对应的Splitter核心参数是window_size和step。需要提醒的是句子的划分质量直接决定效果。中文还好一些句号、问号、感叹号基本能覆盖绝大多数情况英文要注意缩写点、小数点和引用格式否则会把一句话切成好几截。句子级分块不适合那种一个知识点需要跨多个段落展开的复杂文档。用户问的是需要综合多处论据才能回答的问题时单句窗口往往信息量不够。这时候我建议你往后看父子分块它才是为这类场景设计的。4. 语义驱动型分块让模型参与理解规则驱动型方案无论怎么切本质上是靠“表面的符号特征”来猜语义边界。那么有没有一种方式直接让模型判断“哪些句子放在一起是语义上完整的”这就是语义驱动型分块做的事。它们通常需要更多的计算资源但换来的往往是更符合人类阅读习惯的检索单元。4.1 父子分块兼顾检索精度和上下文完整性父子分块在业界的普及度越来越高它的核心思路是建两套索引层级。子块是细粒度的短块负责和用户的查询做精确匹配父块是粗粒度的长块负责在大模型生成时提供完整上下文。打个比方这就像查字典。你通过词条索引子块快速定位到某个词在第几页但真正阅读的时候你看的是整个词条的完整解释父块。这样既避免了短查询在大文本块里“淹没”又避免了只给一句话导致生成时缺上下文。具体实现流程是这样的先把文档按较大粒度切成长段这些是父块通常是1000到2000字符对应一个章节或一个完整主题。再在父块内部按较小粒度切出子块通常是200到500字符。Embedding只对子块做。检索时用子块去匹配用户查询命中子块后把所属的父块整体返回给大模型。子块负责“定位准”父块负责“上下文全”。这个方案尤其适合那些“答案需要覆盖多个子观点才能说清楚”的知识问答场景比如规章制度里的处罚条款、审计流程的多步骤说明。我在一个企业知识库项目里是这么配的子块用固定长度切256字符加30字符重叠父块按段落或章节切最多1000字符。为什么子块不用递归字符切因为子块本身很细递归切分反而容易把相对完整的短句合并得比较随机固定长度加上适度重叠在这个粒度下表现很稳定。要提醒的是父子分块会让索引结构变复杂检索的时候需要维护“子块ID到父块ID”的映射关系同时因为返回的是父块可能会超出大模型的上下文窗口所以一般还要配合截断策略或者只取父块中与子块位置相邻的一小段文本。4.2 语义分块用向量相似度找断点语义分块英文叫Semantic Chunking思路是让Embedding模型自己判断句子的语义转折。先把文本切成一串候选句子然后逐句做向量化计算相邻句子向量的余弦相似度。当相似度出现明显下降时说明语义发生了转折这里就是一个合适的分块断点。听起来很巧妙但实现起来有几个细节要处理。候选句怎么切、相似度差多少算“明显下降”、最小块长度怎么限制这些都是需要试出来的。我梳理了一个基本的实现流程1. 将文本按句子切分为候选句列表 S [s1, s2, ..., sn] 2. 对每个句子做Embedding得到向量列表 V [v1, v2, ..., vn] 3. 计算相邻句子的余弦相似度 sim(v1,v2), sim(v2,v3), ... 4. 计算相似度的均值 mu 和标准差 sigma 5. 当相邻相似度 mu - k*sigmak通常取1~2时判定该处为断点 6. 把所有断点拼起来得到语义分块结果为什么用“均值减k倍标准差”而不是固定阈值因为不同文档的全局相似度分布差异很大。制度文件前后句子高度相关classical的句子可能频繁转折。固定阈值很难一套通吃用统计量来标定“相对于这篇文档的突变程度”会更稳妥。语义分块的优点很明显它不依赖显式结构对没有标题、排版混乱的长文本也有不错的处理效果。比如论文全文转过来的纯文本、课程讲稿、访谈记录这些文档用递归字符分块切出来的块经常出现“前面还在讲概念后面突然跳到案例”的问题语义分块能大大缓解。缺点也很实在计算成本高。每句话都要过一遍Embedding长文档的向量化调用量会比普通方案高一个数量级而且断点判定对超参数比较敏感需要有一套带标注的测试集来调。我的建议是如果你的文档规模不大几千篇以内、文本质量偏高值得用语义分块如果是千万级大规模语料成本往往hold不住还是退回结构感知方案更划算。4.3 上下文增强分块让大模型给每个块写“自我介绍”这个方案是最近在RAG实战社群和Agentic RAG语境里频繁被提到的一种做法。我最早是在Anthropic提出的一篇关于Contextual Retrieval的技术内容里看到完整思路的核心思想很简单单独一个文本块在向量化的时候缺少全局上下文导致检索时语义匹配不上那么在向量化之前先让LLM给每个块写一段包含来源、主题、相关背景的上下文描述把这段描述和原块拼在一起再做Embedding。比如一个制度文件中有个块写的是“全年不得超过十万元”。这句话单独看非常模糊什么不得超过十万元如果Embedding只看到这句话用户问“年度预算上限”很可能匹配不到。但如果你让LLM生成一段上下文说明“本块选自XX公司财务报销管理制度第三章关于年度差旅费用预算的规定前文规定了报销审批流程此处明确部门年度差旅费用预算总额上限为十万元”拼接之后做Embedding检索命中率会有非常显著的提升。这个方案的实现逻辑更像Agentic——每个块的处理不再是单纯的字符串切割而是一次独立的“大模型理解改写”调用。所以有人把它归到Agentic RAG的范畴。具体流程是1. 先用任意规则方案切出基础块 2. 对每个块构造提示词请根据整个文档上下文为以下文本生成一段30~50字的说明 包括来源章节、主题、关联背景等 3. LLM返回上下文描述 4. 将“上下文描述 原始块”拼接作为最终Embedding的输入 5. 入库时同时保存描述、原始块、所在文档ID我实际测试下来这个方案对检索精度的提升是最直接的尤其适合那种单个块看起来“字面意思不完整”的场景。但它也是最烧钱的每个块都要调用一次LLM小规模文档还好到了几十万块的规模成本和时间需要认真评估。还有一种折中做法值得推荐只让LLM为“检索命中率低”的部分——比如较短的块、字面歧义大的块——做上下文增强普通的段落直接跳过。这样能把成本控制在一个比较现实的范围。5. 分块参数调优与多路召回实践5.1 关键参数怎么定chunk_size、overlap、断点阈值很多人在分块上栽跟头不是因为不知道有哪些方案而是不知道参数该怎么调。这里我给出一个比较务实的调参次序你可以直接照着试。先定chunk_size。chunk_size不是越大越好也不是越小越好。它跟三个因素强相关Embedding模型的最大输入长度、大模型的上下文窗口、文档内容本身的粒度。经验做法是先看Embedding模型支持多少token。比如输入上限是512 token的模型你在中文场景下大约对应700到1000个汉字那么chunk_size取500到600个汉字会比较稳留出富余量给后续可能拼接的上下文描述。再调overlap。overlap的典型值在chunk_size的10%到20%之间。512字符的块overlap取50到80比较常见。overlap太大会导致相邻块大量重复检索时同一个段落被多次返回浪费上下文空间太小则起不到防止截断的作用。最后是语义分块的断点阈值。前面提过用mu - k*sigma的方法k的取值需要在你的验证集上调。我的建议是先取1.5作为基线如果切出来的块数量太多、平均长度太短就往大调比如2.0如果块的语义内部依然有明显跳跃就往小调。这里要强调一个很容易被忽视的原则调参的依据永远是“你的验证集”不是直觉。建一套至少一两百条业务问题的评测集人工标注好标准答案和参考文档段落然后用不同的参数组合跑检索对比召回率、命中位置、生成答案的准确率用数据说话。5.2 多路召回同一份文档用不同分块方案并行多路召回在搜索领域是老生常谈但在RAG里结合分块来做效果常常出人意料。核心做法是对同一份文档同时用两到三种分块方案建多套索引查询时分别检索然后把多路结果合并、去重、重排。为什么这么做有效因为不同分块方案的“信息视野”不一样。固定长度分块虽然容易切断句子但它的块边界稳定检索时不容易漏掉长段落中的局部内容结构感知分块对章节把握准但在细节匹配上可能不够细。多路召回本质上是用多个视角去看同一份文档降低单一分块方案的系统性偏差。常见的组合我试过这几组组合适用场景效果说明递归字符分块 句子级窗口通用文档、FAQ兼顾段落级语义和句子级精确定位结构感知分块 父子分块制度文件、手册章节上下文完整条款细粒度可命中固定长度分块 语义分块长文、论文、讲义全局检索不遗漏语义边界更准确多路结果合并的时候一个简单有效的策略是RRFReciprocal Rank Fusion它不依赖分数绝对值而是把每条结果在各自路内的排名取倒数再求和排名越靠前贡献越大。这个方式对“各路分数尺度不一致”的问题非常鲁棒实现也就十几行代码。# RRF简易实现 def rrf_fusion(result_lists, k60): scores {} for results in result_lists: for rank, doc_id in enumerate(results): scores[doc_id] scores.get(doc_id, 0) 1 / (k rank 1) return sorted(scores.items(), keylambda x: x[1], reverseTrue)这里要注意多路召回会带来检索延迟和存储成本上升。每增加一路索引就需要多一遍Embedding调用和检索查询。不建议一开始就上三路以上先两路并联观察收益如果召回率提升不明显说明瓶颈不在分块可能要去看看Embedding模型或Rerank层面的问题。5.3 一个企业知识库的混合分块实际配置拿我之前做过的一个企业制度知识库来举例。这套系统里的文档类型大致有三类规章制度、操作手册、公告通知。一开始我统一用递归字符分块结果是制度类文档的条款经常被切断操作手册里的步骤列表被拆得七零八落公告通知反而还行。后来我按文档类型做了分路处理规章制度走结构感知分块。先用正则识别“第X条”“第X章”以条为基本块保留章节标题作为块前缀。子块控制在400字符。操作手册走父子分块。父块是每个操作步骤的大节子块是单个步骤或步骤中的说明文字。子块200到300字符。公告通知走递归字符分块chunk_size600overlap60。这样改完评测集上的Top-5命中率从54%提到了79%效果非常直观。所以你看实际项目里的分块方案不是一道单选题而是一套需要根据数据源定制的策略组合。5.4 与Rerank的配合分块决定了Rerank的天花板最后补一句关于Rerank的话。很多项目上了Rerank之后发现效果提升不大原因往往就是分块太粗Top-20里压根没有正确答案Rerank再怎么排也排不出来。Rerank的作用是把“基本相关的候选”排到前面而不是凭空变出相关片段。所以分块方案的目标应该调整为“提供高质量、高覆盖率的候选集”在此基础上Rerank才能最大化发挥价值。实操中的先后顺序应该是先用分块方案提高Top-20的召回率再靠Rerank提高Top-5的准确率。如果直接上来堆Rerank花钱多收益却有限。这也是为什么我在项目里一直强调分块多花点时间后面整个链路都会轻松很多。6. 常见问题与排查技巧实录写项目复盘的时候我把这两年遇到的典型问题整理成了一份速查表分享出来希望能帮你少走弯路。6.1 检索召回的内容前言不搭后语现象用户问了一个具体问题召回的块文本里明明包含了关键词但句子不完整语义残缺。原因大概率是固定长度分块把句子截断了或者chunk_size太小块内容不够表达一个完整语义。排查步骤先打开召回结果里那几个块肉眼检查是不是存在半句话。是的话换成递归字符分块并把chunk_size适当调大。确认overlap是否在合理区间如果没有重叠加上10%到20%的重叠。6.2 召回结果太短大模型无法组织完整答案现象召回的内容是一个孤零零的句子信息量不够支撑回答。原因句子级分块或子块切得过于细缺少上下文。排查步骤看当前是不是句子级窗口分块窗口大小是否只有1或2。加大窗口到3到5句。换成父子分块子块负责定位父块负责提供完整段落。如果用的是父子分块检查返回逻辑是否正确返回了父块。我见过有人把子块直接送去生成了导致上下文缺失。6.3 长文档的中间段落永远搜不到现象文档开头和结尾的块经常被命中中间部分几乎从不出现。原因很多Embedding模型对处于长文档中部的内容在向量空间中区分度不高容易被两端的强语义片段压制也有可能是分块时中间部分的标题或上下文信息丢失。排查步骤给中间块补充结构前缀把所属章节标题拼到块头再做Embedding。检查是否用了整体文档Embedding再切块的做法这会让所有块共享全局向量中间信息被稀释改成逐块独立Embedding。适当缩小chunk_size让中间部分的局部语义更聚焦。6.4 Embedding调用量暴涨成本失控现象换了语义分块或上下文增强分块之后账单飙升。原因逐句向量化和逐块LLM调用都属于高成本方案如果没有做成本规划很容易失控。排查步骤确认是否所有文档都适合用高成本方案。很多短文本用递归字符分块就够了不需要逐句Embedding。上下文增强分块可以只对“字面歧义大”的块启用。先用普通方案跑一遍筛出检索命中率低的块再对这部分做二次处理。可以考虑用批量调用、缓存相同或相似块结果来降低成本。6.5 分块参数怎么调才靠谱回归测试是底线最后一个心得也是我踩坑最重的一条分块方案和参数的改动一定要用回归测试来验收不要凭感觉。很多RAG项目改了一轮分块参数看起来问答效果好了但换个测试集又打回原形就是因为没有建立稳定评测集。你可以这样建一个最小的评测流程准备100到200条有代表性的业务问题每条标注好对应的参考文档ID和标准答案。跑一遍“分块 - 检索 - Rerank - 生成”全链路记录Top-5命中率和最终答案正确率。修改分块方案或参数后重跑同一套评测对比指标变化。注意不要只记录“答案对不对”还要记录“正确答案是否出现在召回候选中”。如果命中了但生成不好问题大多在提示词或大模型如果压根没召回那才真正需要回去改分块。我个人在项目中的经验是建立这套评测流程后分块方案的迭代就从一个“靠玄学”的过程变成了一个纯工程过程后续不管是换Embedding模型、调chunk_size还是加多路召回都有了明确的判断依据。最后再分享一个小技巧动手写代码之前把一个项目的文档类型清单和典型查询问题列出来对着这两个列表去选分块方案比任何技术文章的推荐都靠谱。毕竟分块砍下去的那一刀最终还是为了解决你业务里的具体问题。
