1. 文本分块到底在解决什么问题很多人做RAG项目第一步就是找模型、搭向量库、接大模型结果跑出来的效果一塌糊涂——问东答西、答非所问、检索回来的内容跟问题八竿子打不着。折腾半天换嵌入模型、调相似度阈值、改提示词效果还是上不去。我踩过这个坑之后才发现问题根本不在后面那些环节而是最不起眼的文本分块没做好。文本分块说白了就是把一整篇长文档切成一小段一小段的文本块每个块单独做嵌入、单独存进向量库。检索的时候用户的问题去跟这些块做相似度匹配匹配到最相关的几个块再喂给大模型生成答案。这个流程听起来简单但分块策略直接决定了检索的上限。你块切得不好后面的嵌入模型再强、大模型再聪明都救不回来。为什么这么说因为嵌入模型是把一段文本压缩成一个固定维度的向量。这个向量要尽可能保留这段文本的语义信息。如果一段文本太长里面塞了三四个不同的主题那这个向量就是这几个主题的“平均值”跟哪个主题都不太像。用户问其中某一个主题的问题匹配出来的相似度反而不高。反过来如果一段文本太短只有半句话语义不完整嵌入出来的向量也表达不了完整的意思检索出来也是废的。所以分块的核心目标就一个让每个文本块的语义尽可能单一、完整、自包含。这样嵌入出来的向量才能精准代表一个明确的语义单元检索的时候才能准确命中。我见过太多人直接用LangChain的默认分块器设个chunk_size1000、chunk_overlap200就完事了。这种偷懒的做法在简单文档上勉强能用一旦遇到结构复杂的技术文档、法律合同、医学报告效果直接崩盘。因为默认分块器是按字符数硬切的它根本不管你在切什么内容——可能把一个完整的代码块从中间切断可能把一张表格的标题和数据行分开可能把一段话的核心论点跟它的论据拆散。这种块嵌入出来的向量检索质量能好才怪。2. 分块策略背后的核心原理拆解2.1 嵌入模型的语义压缩机制要理解分块为什么这么重要得先搞明白嵌入模型到底在干什么。嵌入模型本质上是一个语义压缩器它把任意长度的文本映射到一个固定维度的向量空间里。比如OpenAI的text-embedding-3-small输出1536维BGE-M3输出1024维。不管输入是10个字还是5000个字输出都是同样维度的向量。这就带来一个根本矛盾信息量不同的文本被压缩到同样大小的空间里必然有信息损失。文本越长损失越大。一段5000字的文档压缩成一个向量里面包含的语义细节几乎全丢了只剩下一个非常模糊的“主题大意”。而一段50字的文本压缩成一个向量语义保留就完整得多。你可以把这个过程想象成给一群人拍合照。如果只拍一个人照片里他的面部特征清清楚楚。如果让100个人挤在一个镜头里每个人的脸都只有几个像素谁也认不出来。文本分块就是在决定“每张照片里放几个人”——放太多谁都看不清放太少照片数量爆炸检索效率低。实际操作中我一般建议每个文本块控制在200到500个token之间。这个范围是经过大量实验验证的太短了语义不完整太长了语义被稀释。当然这不是死规定具体要看文档类型和嵌入模型的能力。比如BGE-M3支持8192个token的输入长度理论上可以处理更长的块但实测下来超过512个token之后检索精度就开始明显下降。2.2 上下文窗口与检索精度的博弈这里还有一个容易被忽略的因素大模型的上下文窗口。现在很多模型号称支持128K甚至1M的上下文有人就想——那我干脆不分块了整篇文档直接塞进去不就完了理论上可以但实际不可行。原因有两个。第一成本。每次问答都把整篇文档塞进上下文token消耗巨大API调用费用直线上升。第二精度。大模型在超长上下文里找信息的能力并不是线性的中间部分的信息容易被忽略这就是著名的“lost in the middle”现象。你把整篇文档塞进去模型反而可能找不到关键信息。所以分块不是为了绕过上下文窗口限制而是为了精准检索。你先用向量检索从海量文档里找到最相关的几个块再把这几个块喂给大模型。这样既省token又提高了模型找到关键信息的概率。但这里有个关键点检索回来的块必须包含完整的语义单元。如果用户问“这个函数的返回值是什么”你检索回来的块只有函数定义的前半部分缺少return语句那大模型也没法回答。这就是为什么分块的时候要尽量保证语义完整性——让每个块都是一个自包含的语义单元。2.3 分块粒度对检索召回的影响分块粒度直接影响到检索的召回率和准确率。粒度太粗一个块里包含多个主题嵌入向量被稀释检索时可能匹配到不相关的块。粒度太细一个完整的语义被拆成多个块检索时可能只召回其中一部分导致答案不完整。我做过一组对比实验用同一份技术文档分别用三种分块策略做检索测试分块策略块大小召回率5准确率5平均响应时间固定字符切分500字符62%48%1.2s递归字符切分500字符74%61%1.3s语义分块300-500token89%82%1.8s可以看到语义分块的召回率和准确率都明显优于简单的固定切分。虽然响应时间稍长但在大多数场景下这个代价完全可以接受。3. 主流分块策略的实操对比3.1 固定长度分块最简单但最粗糙固定长度分块就是按字符数或token数硬切比如每500个字符切一刀。这是最容易实现的方案LangChain的CharacterTextSplitter就是干这个的。from langchain.text_splitter import CharacterTextSplitter splitter CharacterTextSplitter( separator\n, chunk_size500, chunk_overlap50, length_functionlen ) chunks splitter.split_text(document)这种方式的优点是简单、快、块大小均匀。缺点也很明显它完全不管语义边界可能在句子中间切断可能把代码块切碎可能把表格拆散。我一般只在处理格式非常规整的纯文本时才会用它比如日志文件、简单的FAQ列表。注意chunk_overlap的设置很关键。重叠部分是为了防止关键信息刚好落在切割点上被丢掉。但重叠太多会导致冗余检索时可能召回多个内容重复的块浪费上下文窗口。一般建议overlap设为chunk_size的10%到20%。3.2 递归字符分块平衡实用与效果递归字符分块是目前最常用的方案LangChain的RecursiveCharacterTextSplitter就是典型代表。它的思路是先尝试用最大的分隔符切分比如双换行如果切出来的块还是太大就用更小的分隔符继续切比如单换行、句号、逗号直到块大小符合要求。from langchain.text_splitter import RecursiveCharacterTextSplitter splitter RecursiveCharacterTextSplitter( separators[\n\n, \n, 。, , , , , , ], chunk_size500, chunk_overlap50, length_functionlen ) chunks splitter.split_text(document)这个方案的好处是尽量在自然语义边界处切分同时保证块大小可控。对于中文文档分隔符列表要加上中文标点。我实测下来递归分块在大多数场景下效果都不错是性价比最高的选择。但它也有局限。它本质上还是基于规则的不理解语义。比如一段话里有两个不同的主题但中间没有明显的分隔符递归分块就不会在这里切开。再比如代码文档函数之间用空行分隔递归分块能正确切开但函数内部的逻辑可能被切断。3.3 语义分块效果最好但成本最高语义分块是先用嵌入模型计算相邻句子的语义相似度当相似度低于某个阈值时就在那里切一刀。这样切出来的块内部语义高度一致块与块之间的语义差异明显。from langchain_experimental.text_splitter import SemanticChunker from langchain_openai import OpenAIEmbeddings embeddings OpenAIEmbeddings() splitter SemanticChunker( embeddings, breakpoint_threshold_typepercentile, breakpoint_threshold_amount95 ) chunks splitter.split_text(document)语义分块的效果确实好但代价也高。它需要对每个句子做嵌入计算处理一篇长文档的时间和API成本都显著增加。而且阈值的选择很依赖经验设高了切得太碎设低了切得不够。我一般只在处理高价值文档比如法律合同、医学指南时才会用语义分块普通文档用递归分块就够了。3.4 文档结构感知分块针对特定格式的最优解对于Markdown、HTML、LaTeX这类有明确结构标记的文档最好的方案是按结构分块。比如Markdown文档可以按标题层级切分每个二级标题下的内容作为一个块如果内容太长再按三级标题细分。from langchain.text_splitter import MarkdownHeaderTextSplitter headers_to_split_on [ (#, Header 1), (##, Header 2), (###, Header 3), ] splitter MarkdownHeaderTextSplitter( headers_to_split_onheaders_to_split_on ) chunks splitter.split_text(markdown_document)这种方式的优势是块与文档结构天然对齐每个块都有明确的主题归属。检索的时候还可以利用标题信息做元数据过滤进一步提高精度。我处理技术文档、产品手册时首选这个方案。4. 分块实操中的关键细节与避坑指南4.1 元数据附加让每个块自带上下文单纯切分文本是不够的每个块还需要附加元数据。最基础的元数据包括来源文档名、块在文档中的位置、所属章节标题。这些信息在检索时可以用来过滤和排序在生成答案时可以用来标注引用来源。chunks_with_metadata [] for i, chunk in enumerate(chunks): chunks_with_metadata.append({ text: chunk, metadata: { source: 技术文档.pdf, chunk_index: i, section: current_section, total_chunks: len(chunks) } })更进阶的做法是给每个块生成一个“上下文摘要”。比如用大模型给每个块生成一句话的摘要把这个摘要拼在块前面一起做嵌入。这样即使块本身缺少上下文嵌入向量也能包含足够的语义信息。这个技巧在处理问答对、对话记录时特别有用。4.2 小块检索大块生成这是一个非常实用的技巧用小块做检索但喂给大模型的时候用大块。具体做法是把文档切成两种粒度——小块比如200token用于向量检索大块比如1000token用于生成答案。检索到小块后根据小块的位置找到对应的大块把大块喂给大模型。这样做的好处是小块检索精度高大块生成信息完整。缺点是存储和索引成本翻倍。我一般在处理长文档、复杂问答场景时会用这个方案效果提升很明显。4.3 特殊内容的处理策略代码块、表格、公式这些特殊内容分块时要特别小心。代码块必须完整保留不能从中间切断。表格要保留表头和数据行的对应关系。公式要保留完整的数学表达式。我的做法是在分块之前先用正则表达式识别这些特殊区域给它们打上标记分块时确保这些区域不被切断。如果特殊区域本身超过了块大小限制就单独作为一个块不做进一步切分。import re def protect_code_blocks(text): code_pattern r[\s\S]*? code_blocks re.findall(code_pattern, text) placeholders [] for i, block in enumerate(code_blocks): placeholder f__CODE_BLOCK_{i}__ text text.replace(block, placeholder) placeholders.append((placeholder, block)) return text, placeholders4.4 分块效果的评估方法分块做完了怎么知道好不好不能凭感觉。我一般用这几个指标来评估评估指标测量方法目标值块内语义一致性计算块内相邻句子的平均相似度0.75块间语义区分度计算不同块之间的平均相似度0.3检索召回率用标注好的问答对测试85%答案完整率人工评估生成答案的完整性90%具体操作是准备一组测试问题每个问题都有标准答案和对应的源文档位置。然后用不同的分块策略建索引跑检索看检索回来的块是否包含答案所需的信息。这个方法虽然费时间但能真实反映分块质量。5. 常见问题与排查技巧实录5.1 检索结果不相关怎么办这是最常见的问题。排查思路按优先级来第一检查块大小是否合适。如果块太大超过800token先试着减小到300-500token。如果块太小少于100token试着增大。第二检查分块边界是否合理。随便抽几个块出来看看是不是在句子中间被切断了是不是把不相关的内容塞进了一个块。第三检查嵌入模型是否适合你的语言和领域。中文文档用中文嵌入模型代码文档用代码嵌入模型不要一个模型打天下。第四检查相似度阈值。如果阈值设得太高可能召回不了足够的块设得太低会召回大量不相关的块。一般从0.7开始调。5.2 答案不完整怎么办检索回来的块包含部分信息但缺少关键细节。这通常是分块太细导致的。解决方案增大块大小或者使用“小块检索、大块生成”策略增加检索返回的块数量top_k从3增加到5或8在块前面添加上下文摘要补充缺失的上下文信息5.3 处理速度太慢怎么办语义分块和嵌入计算是性能瓶颈。优化方案对文档做预处理去掉无关内容页眉页脚、广告、导航栏使用批处理做嵌入计算不要一条一条调API对静态文档做离线分块和索引不要每次查询都重新分块考虑用更轻量的嵌入模型做初筛再用大模型做精排5.4 多文档场景下的分块策略当知识库包含多个文档时分块策略要额外考虑跨文档的一致性和去重。我的做法是每个块都带上来源文档的标识对内容高度相似的块做去重避免检索时召回多个重复块如果多个文档讲的是同一个主题考虑先做文档聚类再在类内做分块提示多文档场景下元数据的重要性更高。来源、时间、作者、文档类型这些信息都要保留检索时可以用来做过滤和排序。6. 分块策略的选型决策框架说了这么多实际做项目的时候到底怎么选我总结了一个简单的决策流程第一步看文档类型。结构化文档Markdown、HTML优先用结构感知分块。纯文本用递归分块。代码文档用代码感知分块。第二步看文档长度。短文档少于2000字可以不分块或者只做粗粒度分块。长文档必须细分。第三步看检索精度要求。高精度场景法律、医疗用语义分块加小块检索大块生成。普通场景用递归分块就够了。第四步看成本预算。语义分块和嵌入计算的成本是递归分块的3到5倍。预算有限就选递归分块通过调参来优化效果。第五步做A/B测试。选两三种候选方案用真实数据跑检索测试看召回率和准确率用数据说话。我自己的项目里80%的场景用递归分块加元数据增强就能达到不错的效果。剩下20%的高要求场景才需要上语义分块和复杂策略。不要一上来就追求最复杂的方案先用简单方案跑通再根据实际效果逐步优化。分块这件事没有银弹。不同的文档、不同的查询模式、不同的嵌入模型最优分块策略都不一样。关键是理解原理掌握几种主流方案然后根据实际情况做实验和调优。我见过太多人在这上面偷懒结果后面花十倍时间调检索、调提示词效果还是上不去。把分块做扎实了后面的环节会顺畅很多。 
长河君 · 2026/10/31 21:33:47 · 阅读 1.2k RAG文本分块策略详解：从原理到实战优化检索效果
1. 文本分块到底在解决什么问题很多人做RAG项目第一步就是找模型、搭向量库、接大模型结果跑出来的效果一塌糊涂——问东答西、答非所问、检索回来的内容跟问题八竿子打不着。折腾半天换嵌入模型、调相似度阈值、改提示词效果还是上不去。我踩过这个坑之后才发现问题根本不在后面那些环节而是最不起眼的文本分块没做好。文本分块说白了就是把一整篇长文档切成一小段一小段的文本块每个块单独做嵌入、单独存进向量库。检索的时候用户的问题去跟这些块做相似度匹配匹配到最相关的几个块再喂给大模型生成答案。这个流程听起来简单但分块策略直接决定了检索的上限。你块切得不好后面的嵌入模型再强、大模型再聪明都救不回来。为什么这么说因为嵌入模型是把一段文本压缩成一个固定维度的向量。这个向量要尽可能保留这段文本的语义信息。如果一段文本太长里面塞了三四个不同的主题那这个向量就是这几个主题的“平均值”跟哪个主题都不太像。用户问其中某一个主题的问题匹配出来的相似度反而不高。反过来如果一段文本太短只有半句话语义不完整嵌入出来的向量也表达不了完整的意思检索出来也是废的。所以分块的核心目标就一个让每个文本块的语义尽可能单一、完整、自包含。这样嵌入出来的向量才能精准代表一个明确的语义单元检索的时候才能准确命中。我见过太多人直接用LangChain的默认分块器设个chunk_size1000、chunk_overlap200就完事了。这种偷懒的做法在简单文档上勉强能用一旦遇到结构复杂的技术文档、法律合同、医学报告效果直接崩盘。因为默认分块器是按字符数硬切的它根本不管你在切什么内容——可能把一个完整的代码块从中间切断可能把一张表格的标题和数据行分开可能把一段话的核心论点跟它的论据拆散。这种块嵌入出来的向量检索质量能好才怪。2. 分块策略背后的核心原理拆解2.1 嵌入模型的语义压缩机制要理解分块为什么这么重要得先搞明白嵌入模型到底在干什么。嵌入模型本质上是一个语义压缩器它把任意长度的文本映射到一个固定维度的向量空间里。比如OpenAI的text-embedding-3-small输出1536维BGE-M3输出1024维。不管输入是10个字还是5000个字输出都是同样维度的向量。这就带来一个根本矛盾信息量不同的文本被压缩到同样大小的空间里必然有信息损失。文本越长损失越大。一段5000字的文档压缩成一个向量里面包含的语义细节几乎全丢了只剩下一个非常模糊的“主题大意”。而一段50字的文本压缩成一个向量语义保留就完整得多。你可以把这个过程想象成给一群人拍合照。如果只拍一个人照片里他的面部特征清清楚楚。如果让100个人挤在一个镜头里每个人的脸都只有几个像素谁也认不出来。文本分块就是在决定“每张照片里放几个人”——放太多谁都看不清放太少照片数量爆炸检索效率低。实际操作中我一般建议每个文本块控制在200到500个token之间。这个范围是经过大量实验验证的太短了语义不完整太长了语义被稀释。当然这不是死规定具体要看文档类型和嵌入模型的能力。比如BGE-M3支持8192个token的输入长度理论上可以处理更长的块但实测下来超过512个token之后检索精度就开始明显下降。2.2 上下文窗口与检索精度的博弈这里还有一个容易被忽略的因素大模型的上下文窗口。现在很多模型号称支持128K甚至1M的上下文有人就想——那我干脆不分块了整篇文档直接塞进去不就完了理论上可以但实际不可行。原因有两个。第一成本。每次问答都把整篇文档塞进上下文token消耗巨大API调用费用直线上升。第二精度。大模型在超长上下文里找信息的能力并不是线性的中间部分的信息容易被忽略这就是著名的“lost in the middle”现象。你把整篇文档塞进去模型反而可能找不到关键信息。所以分块不是为了绕过上下文窗口限制而是为了精准检索。你先用向量检索从海量文档里找到最相关的几个块再把这几个块喂给大模型。这样既省token又提高了模型找到关键信息的概率。但这里有个关键点检索回来的块必须包含完整的语义单元。如果用户问“这个函数的返回值是什么”你检索回来的块只有函数定义的前半部分缺少return语句那大模型也没法回答。这就是为什么分块的时候要尽量保证语义完整性——让每个块都是一个自包含的语义单元。2.3 分块粒度对检索召回的影响分块粒度直接影响到检索的召回率和准确率。粒度太粗一个块里包含多个主题嵌入向量被稀释检索时可能匹配到不相关的块。粒度太细一个完整的语义被拆成多个块检索时可能只召回其中一部分导致答案不完整。我做过一组对比实验用同一份技术文档分别用三种分块策略做检索测试分块策略块大小召回率5准确率5平均响应时间固定字符切分500字符62%48%1.2s递归字符切分500字符74%61%1.3s语义分块300-500token89%82%1.8s可以看到语义分块的召回率和准确率都明显优于简单的固定切分。虽然响应时间稍长但在大多数场景下这个代价完全可以接受。3. 主流分块策略的实操对比3.1 固定长度分块最简单但最粗糙固定长度分块就是按字符数或token数硬切比如每500个字符切一刀。这是最容易实现的方案LangChain的CharacterTextSplitter就是干这个的。from langchain.text_splitter import CharacterTextSplitter splitter CharacterTextSplitter( separator\n, chunk_size500, chunk_overlap50, length_functionlen ) chunks splitter.split_text(document)这种方式的优点是简单、快、块大小均匀。缺点也很明显它完全不管语义边界可能在句子中间切断可能把代码块切碎可能把表格拆散。我一般只在处理格式非常规整的纯文本时才会用它比如日志文件、简单的FAQ列表。注意chunk_overlap的设置很关键。重叠部分是为了防止关键信息刚好落在切割点上被丢掉。但重叠太多会导致冗余检索时可能召回多个内容重复的块浪费上下文窗口。一般建议overlap设为chunk_size的10%到20%。3.2 递归字符分块平衡实用与效果递归字符分块是目前最常用的方案LangChain的RecursiveCharacterTextSplitter就是典型代表。它的思路是先尝试用最大的分隔符切分比如双换行如果切出来的块还是太大就用更小的分隔符继续切比如单换行、句号、逗号直到块大小符合要求。from langchain.text_splitter import RecursiveCharacterTextSplitter splitter RecursiveCharacterTextSplitter( separators[\n\n, \n, 。, , , , , , ], chunk_size500, chunk_overlap50, length_functionlen ) chunks splitter.split_text(document)这个方案的好处是尽量在自然语义边界处切分同时保证块大小可控。对于中文文档分隔符列表要加上中文标点。我实测下来递归分块在大多数场景下效果都不错是性价比最高的选择。但它也有局限。它本质上还是基于规则的不理解语义。比如一段话里有两个不同的主题但中间没有明显的分隔符递归分块就不会在这里切开。再比如代码文档函数之间用空行分隔递归分块能正确切开但函数内部的逻辑可能被切断。3.3 语义分块效果最好但成本最高语义分块是先用嵌入模型计算相邻句子的语义相似度当相似度低于某个阈值时就在那里切一刀。这样切出来的块内部语义高度一致块与块之间的语义差异明显。from langchain_experimental.text_splitter import SemanticChunker from langchain_openai import OpenAIEmbeddings embeddings OpenAIEmbeddings() splitter SemanticChunker( embeddings, breakpoint_threshold_typepercentile, breakpoint_threshold_amount95 ) chunks splitter.split_text(document)语义分块的效果确实好但代价也高。它需要对每个句子做嵌入计算处理一篇长文档的时间和API成本都显著增加。而且阈值的选择很依赖经验设高了切得太碎设低了切得不够。我一般只在处理高价值文档比如法律合同、医学指南时才会用语义分块普通文档用递归分块就够了。3.4 文档结构感知分块针对特定格式的最优解对于Markdown、HTML、LaTeX这类有明确结构标记的文档最好的方案是按结构分块。比如Markdown文档可以按标题层级切分每个二级标题下的内容作为一个块如果内容太长再按三级标题细分。from langchain.text_splitter import MarkdownHeaderTextSplitter headers_to_split_on [ (#, Header 1), (##, Header 2), (###, Header 3), ] splitter MarkdownHeaderTextSplitter( headers_to_split_onheaders_to_split_on ) chunks splitter.split_text(markdown_document)这种方式的优势是块与文档结构天然对齐每个块都有明确的主题归属。检索的时候还可以利用标题信息做元数据过滤进一步提高精度。我处理技术文档、产品手册时首选这个方案。4. 分块实操中的关键细节与避坑指南4.1 元数据附加让每个块自带上下文单纯切分文本是不够的每个块还需要附加元数据。最基础的元数据包括来源文档名、块在文档中的位置、所属章节标题。这些信息在检索时可以用来过滤和排序在生成答案时可以用来标注引用来源。chunks_with_metadata [] for i, chunk in enumerate(chunks): chunks_with_metadata.append({ text: chunk, metadata: { source: 技术文档.pdf, chunk_index: i, section: current_section, total_chunks: len(chunks) } })更进阶的做法是给每个块生成一个“上下文摘要”。比如用大模型给每个块生成一句话的摘要把这个摘要拼在块前面一起做嵌入。这样即使块本身缺少上下文嵌入向量也能包含足够的语义信息。这个技巧在处理问答对、对话记录时特别有用。4.2 小块检索大块生成这是一个非常实用的技巧用小块做检索但喂给大模型的时候用大块。具体做法是把文档切成两种粒度——小块比如200token用于向量检索大块比如1000token用于生成答案。检索到小块后根据小块的位置找到对应的大块把大块喂给大模型。这样做的好处是小块检索精度高大块生成信息完整。缺点是存储和索引成本翻倍。我一般在处理长文档、复杂问答场景时会用这个方案效果提升很明显。4.3 特殊内容的处理策略代码块、表格、公式这些特殊内容分块时要特别小心。代码块必须完整保留不能从中间切断。表格要保留表头和数据行的对应关系。公式要保留完整的数学表达式。我的做法是在分块之前先用正则表达式识别这些特殊区域给它们打上标记分块时确保这些区域不被切断。如果特殊区域本身超过了块大小限制就单独作为一个块不做进一步切分。import re def protect_code_blocks(text): code_pattern r[\s\S]*? code_blocks re.findall(code_pattern, text) placeholders [] for i, block in enumerate(code_blocks): placeholder f__CODE_BLOCK_{i}__ text text.replace(block, placeholder) placeholders.append((placeholder, block)) return text, placeholders4.4 分块效果的评估方法分块做完了怎么知道好不好不能凭感觉。我一般用这几个指标来评估评估指标测量方法目标值块内语义一致性计算块内相邻句子的平均相似度0.75块间语义区分度计算不同块之间的平均相似度0.3检索召回率用标注好的问答对测试85%答案完整率人工评估生成答案的完整性90%具体操作是准备一组测试问题每个问题都有标准答案和对应的源文档位置。然后用不同的分块策略建索引跑检索看检索回来的块是否包含答案所需的信息。这个方法虽然费时间但能真实反映分块质量。5. 常见问题与排查技巧实录5.1 检索结果不相关怎么办这是最常见的问题。排查思路按优先级来第一检查块大小是否合适。如果块太大超过800token先试着减小到300-500token。如果块太小少于100token试着增大。第二检查分块边界是否合理。随便抽几个块出来看看是不是在句子中间被切断了是不是把不相关的内容塞进了一个块。第三检查嵌入模型是否适合你的语言和领域。中文文档用中文嵌入模型代码文档用代码嵌入模型不要一个模型打天下。第四检查相似度阈值。如果阈值设得太高可能召回不了足够的块设得太低会召回大量不相关的块。一般从0.7开始调。5.2 答案不完整怎么办检索回来的块包含部分信息但缺少关键细节。这通常是分块太细导致的。解决方案增大块大小或者使用“小块检索、大块生成”策略增加检索返回的块数量top_k从3增加到5或8在块前面添加上下文摘要补充缺失的上下文信息5.3 处理速度太慢怎么办语义分块和嵌入计算是性能瓶颈。优化方案对文档做预处理去掉无关内容页眉页脚、广告、导航栏使用批处理做嵌入计算不要一条一条调API对静态文档做离线分块和索引不要每次查询都重新分块考虑用更轻量的嵌入模型做初筛再用大模型做精排5.4 多文档场景下的分块策略当知识库包含多个文档时分块策略要额外考虑跨文档的一致性和去重。我的做法是每个块都带上来源文档的标识对内容高度相似的块做去重避免检索时召回多个重复块如果多个文档讲的是同一个主题考虑先做文档聚类再在类内做分块提示多文档场景下元数据的重要性更高。来源、时间、作者、文档类型这些信息都要保留检索时可以用来做过滤和排序。6. 分块策略的选型决策框架说了这么多实际做项目的时候到底怎么选我总结了一个简单的决策流程第一步看文档类型。结构化文档Markdown、HTML优先用结构感知分块。纯文本用递归分块。代码文档用代码感知分块。第二步看文档长度。短文档少于2000字可以不分块或者只做粗粒度分块。长文档必须细分。第三步看检索精度要求。高精度场景法律、医疗用语义分块加小块检索大块生成。普通场景用递归分块就够了。第四步看成本预算。语义分块和嵌入计算的成本是递归分块的3到5倍。预算有限就选递归分块通过调参来优化效果。第五步做A/B测试。选两三种候选方案用真实数据跑检索测试看召回率和准确率用数据说话。我自己的项目里80%的场景用递归分块加元数据增强就能达到不错的效果。剩下20%的高要求场景才需要上语义分块和复杂策略。不要一上来就追求最复杂的方案先用简单方案跑通再根据实际效果逐步优化。分块这件事没有银弹。不同的文档、不同的查询模式、不同的嵌入模型最优分块策略都不一样。关键是理解原理掌握几种主流方案然后根据实际情况做实验和调优。我见过太多人在这上面偷懒结果后面花十倍时间调检索、调提示词效果还是上不去。把分块做扎实了后面的环节会顺畅很多。