1. 从“切豆腐”到“切文本”为什么分块是RAG的命门如果你最近在折腾RAG检索增强生成想把一堆文档喂给大模型让它能精准地回答你的问题那你大概率已经踩过“分块”这个坑了。你可能试过把一篇PDF按固定字符数切成段结果模型要么找不到关键信息要么给你一堆无关的废话。这感觉就像你想做一盘麻婆豆腐却拿把大刀把整块豆腐胡乱剁碎——最后炒出来的可能是一锅豆腐渣。文本分块这个看似简单的“切豆腐”步骤恰恰是决定RAG系统成败的“命门”。它直接决定了你的向量数据库里存的是什么进而决定了检索召回的质量。分得太碎上下文信息丢失模型看不懂分得太大噪声太多模型被淹没。更头疼的是不同类型的文本——技术文档、法律合同、对话记录、学术论文——它们的“纹理”和“结构”天差地别怎么可能用同一把“刀”去切网上充斥着各种“最佳实践”告诉你用128个token或者500个字符。但作为一个从零搭建过多个RAG系统、被分块问题折磨到深夜的老兵我必须告诉你不存在放之四海而皆准的“黄金分块大小”。真正的“最佳实践”是一套根据你的数据特性和业务目标动态选择和调整分块策略的方法论。今天我们就抛开那些笼统的教条深入实战聊聊如何为你的RAG系统打造一把趁手的“文本手术刀”。2. 分块策略全景图超越简单的“按字符切”在深入具体工具之前我们必须先建立起对分块策略的立体认知。分块不仅仅是“切”更是“理解”和“组织”。根据切割的粒度和依据的逻辑我们可以将主流策略分为几个层次。2.1 基于固定大小的分块简单粗暴的起点这是最基础、也是最常用的方法。你设定一个固定的字符数或Token数如500字符或256个Token一个重叠量如50字符然后像推土机一样从头推到尾。# 一个简化的固定大小分块示例概念性代码 text 这是一段很长的文档内容... chunk_size 500 overlap 50 chunks [] for i in range(0, len(text), chunk_size - overlap): chunk text[i:i chunk_size] chunks.append(chunk) # 实际中需处理中英文混合、标点边界等问题适用场景与局限场景格式统一、结构简单的纯文本如新闻稿、某些技术博客。作为快速原型验证的起点。局限“语义截断”是致命伤。它很可能在句子中间、甚至一个词中间粗暴地切断破坏完整的语义单元。想象一下把“中华人民共和国的首都是北京”这句话从“民共和”之间切开检索时“北京”这个关键信息可能就丢失了。注意固定大小分块永远不应该作为生产环境的唯一策略。它通常需要与其他策略结合作为最后一道“保底”的切割工序。2.2 基于分隔符的分块尊重文档的天然结构文档本身就有结构标记比如段落\n\n、标题#、句号.、分号;等。基于分隔符的分块策略就是利用这些标记在自然边界处进行切割。# 使用句号、问号、感叹号作为分隔符更符合语言习惯 separators [\n\n, 。, , , , , , ] # 许多分块库如LangChain的RecursiveCharacterTextSplitter内部就是按此优先级尝试进阶技巧递归分割。 这是LangChain等库中的核心思想。它不是一个分隔符切到底而是设定一个优先级列表。例如先尝试按“\n\n”分如果分出来的块还是太大就降级用“。”分再大就用“”以此类推直到块大小满足要求。这种方法在尊重结构的同时兼顾了块大小的可控性。适用场景场景几乎所有规整的文档。特别是Markdown、HTML、代码等具有明确层级结构的文本。优势能较好地保持语义完整性因为切割点通常是人类阅读时的自然停顿点。2.3 基于语义的分块让机器理解后再切割这是更高级的策略目标是让每个“块”都是一个相对独立、完整的语义单元。它不再依赖表面的符号而是试图理解内容。句子分割这是语义分块的基础。使用NLP库如NLTK、spaCy、HanLP将文本分割成独立的句子然后再将相邻的句子组合成块。这比按逗号、空格分要精准得多尤其是处理英文的缩写如“U.S.”和中文的复杂标点。嵌入相似性分块一个非常巧妙的方法。计算相邻句子或小段文本的嵌入向量然后计算它们之间的余弦相似度。当相似度低于某个阈值时就在那里进行切割。这相当于让模型自己判断“从这里开始话题变了。”# 概念性流程 sentences split_into_sentences(text) embeddings model.encode(sentences) chunks [] current_chunk [] for i in range(1, len(sentences)): similarity cosine_similarity(embeddings[i-1], embeddings[i]) if similarity threshold: chunks.append( .join(current_chunk)) current_chunk [sentences[i]] else: current_chunk.append(sentences[i])基于模型的分块使用经过微调的序列标注模型如BERT-CRF直接预测文本中每个位置是否是“块”的边界。这种方法成本最高但对于特定领域如法律条文、医疗报告的复杂文档效果可能最好。适用场景场景对语义连贯性要求极高的场景如长篇小说、学术论文、复杂的分析报告。当你的问题需要模型理解一段完整的论证或叙事时语义分块至关重要。挑战计算开销大需要额外的模型或服务且阈值需要调优。2.4 基于内容类型的分块量体裁衣这是最高阶的策略要求你对数据有深刻理解并为不同类型的内容定制分块规则。代码应按函数、类、模块进行分块。同时将代码与其相邻的注释文档docstring保持在一起至关重要因为注释是理解代码意图的关键。Markdown/HTML应按标题层级进行分块。例如将每个二级标题下的所有内容作为一个块或者将每个列表项及其子项作为一个整体。对话记录应按对话轮次分块。将一次完整的问答对Q-A作为一个整体这对于后续检索“历史上类似的问题是如何解决的”非常有用。幻灯片应按单页幻灯片分块将标题、要点和演讲者备注结合在一起。表格永远不要拆散一个表格。应将整个表格作为一个独立的块或者按行分组如果表格非常大。可以考虑将表格转换为描述性文本如“下表展示了2023年各季度营收Q1: 100万 Q2: 120万...”再存入向量库或使用专门处理表格的模型。实战心得在实际项目中我几乎从未使用单一策略。“组合拳”才是常态。例如对于一份技术白皮书我的策略可能是先按二级标题进行基于分隔符的分块 - 对于每个大块如果仍然过长则使用递归字符分割 - 对于其中的代码片段单独用代码分割器处理并附加到所属的文本块后。这种分层处理的方式能最大程度兼顾结构、语义和可控性。3. 核心参数调优不只是大小和重叠当你选定了一个基础策略比如递归字符分割面前会出现几个关键的旋钮。怎么拧大有学问。3.1 Chunk Size大小之谜这是被问得最多的问题“我的块到底应该设多大”与嵌入模型上下文窗口匹配这是首要原则。如果你的嵌入模型如text-embedding-ada-002最大支持8191个Token那么你分块后的文本Token数必须小于这个值。通常要留出安全余量。与LLM的上下文窗口平衡检索到的块会连同问题一起送入LLM进行生成。假设你的问题是50个TokenLLM上下文窗口是4096那么你单个块的最大Token数理论上可以到4046。但实践中你会一次检索多个块如top-4所以每个块的大小需要更小。“答案通常在一个块内”原则这是一个重要的经验法则。你希望一个完整的答案所需的所有信息尽量集中在一个检索块里。如果你的答案需要综合文档中相隔很远的三个段落才能得出那么RAG的难度会急剧上升。因此对于事实性问答块可以稍大以确保信息完整对于需要总结归纳的任务块可以稍小以聚焦。从大到小实验一个实用的方法是从一个较大的尺寸开始测试如1024 Token观察检索效果。如果发现召回的内容总是包含大量无关信息噪声就逐步减小尺寸如果发现总是不完整就适当增大。3.2 Chunk Overlap重叠的艺术重叠是为了防止关键信息恰好落在块的边界而被切断。但重叠不是越大越好。作用保证边界信息的连续性特别是对于固定大小或基于分隔符的分块可以缓解语义截断问题。设置经验值通常设置为块大小的10%-20%。例如块大小为500字符重叠可以设为50-100字符。重叠过大副作用存储和计算成本翻倍重叠部分会被重复嵌入和存储增加向量数据库的容量和检索时的计算量。可能引入冗余如果重叠部分恰好是一大段无关内容反而会稀释核心信息的密度。影响检索排序如果两个高度重叠的块都被召回它们之间的相似度会异常高可能影响重排序的效果。我的常用策略对于递归分割由于它已经在自然边界处切割重叠可以设得小一些如50字符。对于固定大小分割则需要更大的重叠如10%-20%来补偿其“粗暴”的切割方式。3.3 分隔符优先级定义切割的“性格”在递归分割中分隔符列表的顺序就是切割的优先级。这个顺序定义了分块器的“性格”。[“\n\n”, “\n”, “。”, “”, “”, “ “, “”]这是“段落优先”型。它尽可能保持段落的完整只有段落太大时才退而求其次去切句子、分句。[“。”, “”, “”, “\n”, “”, “”, “ “, “”]这是“句子优先”型。它首先保证得到的是完整的句子然后将句子组合成块。如何选择看你的数据。如果文档段落结构清晰如论文、报告“段落优先”更好。如果文档是连贯的叙述体段落很长如小说、长文“句子优先”更灵活。4. 工程化实战以LangChain和LlamaIndex为例理论说再多不如一行代码。我们以两个最流行的框架为例看看如何将策略落地。4.1 LangChain Text Splitters 深度使用LangChain提供了多种分块器最常用的是RecursiveCharacterTextSplitter。from langchain.text_splitter import RecursiveCharacterTextSplitter, MarkdownHeaderTextSplitter # 1. 通用递归字符分割器 text_splitter RecursiveCharacterTextSplitter( chunk_size500, # 目标块大小字符 chunk_overlap50, # 重叠大小 length_functionlen, # 计算长度的方法可以用tiktoken计算token separators[\n\n, \n, 。, , , , ] # 分隔符优先级 ) chunks text_splitter.split_text(long_text) # 2. 专门处理Markdown的分割器基于标题 headers_to_split_on [ (#, Header 1), (##, Header 2), (###, Header 3), ] markdown_splitter MarkdownHeaderTextSplitter(headers_to_split_onheaders_to_split_on) md_chunks markdown_splitter.split_text(markdown_text) # 输出结果中每个chunk会包含元数据如所属的标题路径。 # 3. 自定义长度函数使用Token计数 import tiktoken def tiktoken_len(text): encoder tiktoken.get_encoding(cl100k_base) # 适配GPT-4/Embedding模型 return len(encoder.encode(text)) token_splitter RecursiveCharacterTextSplitter( chunk_size256, # 目标Token数 chunk_overlap25, length_functiontiktoken_len, # 使用Token计数 separators[\n\n, \n, 。, , , , ] )避坑指南长度函数陷阱默认的len函数计算的是字符数对于中英文混合文本一个汉字和一个英文字母都算1个字符但这与嵌入模型或LLM感知的Token数相差甚远。强烈建议在生产环境中使用Token计数函数如tiktoken以确保块大小精确可控。分隔符列表的结尾注意RecursiveCharacterTextSplitter的分隔符列表最后一个元素是空字符串“”。这意味着当所有分隔符都无法将文本切到目标大小时它会按单个字符切割。这是确保一定能切开的“保底”机制但可能产生无意义的单字块。如果你的文本非常特殊如连续长字符串需要留意这一点。4.2 LlamaIndex Node Parsers 的精细化控制LlamaIndex将分块后的单元称为“Node”其NodeParser提供了更精细的控制特别是与文档结构元数据的结合。from llama_index.core import SimpleDirectoryReader from llama_index.core.node_parser import SentenceSplitter, SemanticSplitterNodeParser from llama_index.embeddings.openai import OpenAIEmbedding # 1. 句子分割器基础且强大 parser SentenceSplitter( chunk_size512, # 目标字符数 chunk_overlap20, separator , # 句子连接符 paragraph_separator\n\n # 段落分隔符用于优先保持段落 ) documents SimpleDirectoryReader(./data).load_data() nodes parser.get_nodes_from_documents(documents) # 2. 语义分割器实验性但强大 embed_model OpenAIEmbedding() semantic_parser SemanticSplitterNodeParser( buffer_size1, # 用于计算相似度的滑动窗口大小 breakpoint_percentile_threshold95, # 相似度百分位阈值低于此则切割 embed_modelembed_model ) semantic_nodes semantic_parser.get_nodes_from_documents(documents)LlamaIndex的优势每个Node对象不仅包含文本还自动继承了来源文档的元数据如文件名、页码。在后续检索时这些元数据可以用于过滤非常方便。此外其SentenceSplitter对句子的识别比简单的标点分割更健壮。4.3 处理混合内容一个综合案例假设我们有一个混合文档包含Markdown格式的文本和Python代码片段。from langchain.text_splitter import RecursiveCharacterTextSplitter, Language from langchain.document_loaders import UnstructuredMarkdownLoader # 1. 加载Markdown文档 loader UnstructuredMarkdownLoader(technical_doc.md) docs loader.load() # 2. 使用支持代码分割的递归分割器 text_splitter RecursiveCharacterTextSplitter.from_language( languageLanguage.MARKDOWN, # 指定语言为Markdown内部有优化分隔符 chunk_size1000, chunk_overlap150 ) # 这个方法会对代码块进行特殊处理尽量保持其完整。 # 3. 对于复杂的自定义需求可以分步处理 final_chunks [] for doc in docs: # 假设我们通过某种方式识别出代码块例如通过标记 # 这里简化处理先按Markdown标题粗分 md_splitter MarkdownHeaderTextSplitter(headers_to_split_on[(##, section)]) md_chunks md_splitter.split_text(doc.page_content) for chunk in md_chunks: # 检查这个块里是否包含代码片段这里简化判断 if python in chunk.page_content: # 对于含代码的块采用更小的chunk_size和特定的separators code_aware_splitter RecursiveCharacterTextSplitter( separators[python, , \n\n, \n, 。], chunk_size600, chunk_overlap80 ) sub_chunks code_aware_splitter.split_text(chunk.page_content) final_chunks.extend(sub_chunks) else: # 对于纯文本块使用常规分割 regular_splitter RecursiveCharacterTextSplitter(chunk_size800, chunk_overlap100) sub_chunks regular_splitter.split_text(chunk.page_content) final_chunks.extend(sub_chunks)这个案例展示了策略组合的思想先按文档的宏观结构Markdown标题进行第一次切割再根据微观内容类型是否包含代码选择不同的切割参数进行二次处理。5. 评估与迭代如何知道你的分块是好是坏分块策略没有标准答案必须通过评估来迭代优化。评估的核心是看它是否提升了下游任务即RAG的问答效果的性能。5.1 离线评估构建你的测试集构建评估集从你的文档中人工或半自动地构建一批“问题-答案”对。确保这些问题覆盖不同的类型事实型答案在单一位置、总结型需要综合多个句子、推理型需要联系上下文。定义评估指标检索召回率对于每个问题检索到的Top-K个块中是否包含了能回答该问题的正确答案块这是分块策略最直接的衡量标准。答案精确度/相似度将检索到的块和问题一起送给LLM生成答案将生成的答案与标准答案进行比较可以使用ROUGE、BLEU或更好的用GPT-4等大模型进行评分。A/B测试用不同的分块策略如chunk_size256vs512separators列表不同处理同一份文档然后在相同的评估集上运行你的RAG流程对比上述指标。5.2 在线监控与调试上线后监控同样重要。检索结果分析定期抽样检查用户问题的检索结果。看看被召回的块是否真的相关是不是总有一些无关的块被召回来这可能意味着块太大、噪声多。Bad Case分析收集回答错误或不好的用户问题。深入分析链路是检索没找到正确块还是找到了但块内信息不完整如果是后者就是分块问题。案例用户问“XX产品的保修政策是什么”。检索到的块标题是“售后服务”内容提到了“保修期一年”但没有“政策”细节。检查发现详细的保修条款在下一个块里但因为按固定大小切割被分开了。解决方案尝试基于“标题”进行分块或者增大chunk_overlap以确保关键段落不被割裂。可视化你的块这是一个非常实用的调试技巧。将你的文档分块后把每个块的前后N个字符打印出来或者用不同颜色高亮显示在原文中。你能直观地看到切割点是否合理语义是否被破坏。5.3 一个简单的评估脚本框架import asyncio from typing import List, Tuple from your_rag_system import YourRAGSystem # 假设你的RAG系统 from your_eval_metrics import calculate_retrieval_recall, llm_evaluate_answer class ChunkingEvaluator: def __init__(self, chunking_configs: List[dict], eval_qa_pairs: List[Tuple[str, str]]): self.configs chunking_configs self.eval_set eval_qa_pairs async def evaluate_one_config(self, config: dict, qa_pair: Tuple[str, str]): 评估一种分块配置在一个QA对上的表现 question, ground_truth_answer qa_pair # 1. 用当前配置初始化分块器处理文档 # 2. 构建向量索引 # 3. 检索 retrieved_chunks rag_system.retrieve(question, top_k3) # 4. 计算检索召回率 recall calculate_retrieval_recall(retrieved_chunks, ground_truth_answer) # 5. 生成答案并评估 generated_answer rag_system.generate(question, retrieved_chunks) answer_score llm_evaluate_answer(generated_answer, ground_truth_answer) return {recall: recall, answer_score: answer_score} async def run_evaluation(self): results {} for config in self.configs: print(fEvaluating config: {config}) scores [] for qa in self.eval_set: score await self.evaluate_one_config(config, qa) scores.append(score) # 聚合分数 avg_recall sum(s[recall] for s in scores) / len(scores) avg_answer_score sum(s[answer_score] for s in scores) / len(scores) results[str(config)] {avg_recall: avg_recall, avg_answer_score: avg_answer_score} # 打印或保存比较结果 return results # 定义不同的分块策略 configs [ {chunk_size: 256, chunk_overlap: 25, separator_type: sentence}, {chunk_size: 512, chunk_overlap: 50, separator_type: paragraph}, {chunk_size: 1024, chunk_overlap: 100, separator_type: recursive}, ] evaluator ChunkingEvaluator(configs, your_qa_pairs) results asyncio.run(evaluator.run_evaluation())通过这样的评估你可以数据化地证明对于你的特定数据哪种分块配置更优。6. 高级话题与未来方向分块技术远未定型社区和学术界都在探索更智能的方法。6.1 Agentic RAG 与动态分块在智能体驱动的RAG中分块可以不是一次性、静态的。Agent可以根据当前的问题动态地决定如何“查看”文档。思路先使用较小的、颗粒度细的块进行初步检索定位到相关区域。然后Agent可以决定将相邻的多个小块“合并”成一个更大的上下文窗口再送给LLM进行深度理解和生成。这相当于“先广搜后精读”。实现这需要分块器能记录块之间的位置关系如前驱、后继并且检索系统能支持这种多粒度的操作。6.2 Graph RAG超越线性分块传统分块将文档视为一维线性序列。但文档内部的知识是结构化的有实体、有关系。Graph RAG尝试在分块时或分块后抽取实体和关系构建一个知识图谱。对分块的启示分块时可以有意地将描述同一实体或同一事件的相关段落保持在一起即使它们在原文中可能不连续。或者在分块后通过实体链接技术将散落在不同块中但指向同一实体的信息关联起来。检索阶段不仅可以进行向量相似度检索还可以进行图遍历沿着关系边找到相关知识这能极大提升复杂推理问题的回答能力。6.3 不依赖向量库的RAG分块的价值变化一些新兴方法尝试绕过向量相似度检索例如使用关键词搜索、BM25或者直接用LLM进行“语句级”的搜索。在这些范式下分块的目标可能会发生变化。关键词/BM25它们对词频敏感。过小的块可能导致关键词的统计信息不足影响排序。因此块大小可能需要适当增大。LLM直接搜索如果让LLM直接阅读原始文档或大块来定位答案那么分块的角色就从“检索单元”变成了“预处理和索引单元”其大小可能更接近原文的章节或段落。6.4 分块与重排序的协同在RAG的“多路召回-重排序”架构中分块策略直接影响着召回阶段的结果池。如果初召回的结果池质量太差因为分块不合理再强大的重排序模型也难以挽救。协同设计在设计分块时可以提前考虑重排序模型的能力。例如如果重排序模型擅长处理长文本那么召回时可以使用稍大的块如果重排序模型更擅长精细匹配那么召回时可以使用更小、更精准的块。实验闭环分块策略、召回数量、重排序模型这三者需要放在一个闭环里一起调优。固定其中两个调整第三个观察最终答案质量的变化。7. 我的实战工具箱与心法最后分享一些我在多个项目中总结出的、不会写在官方文档里的经验。心法一从业务目标反推分块策略。不要一上来就纠结技术参数。先问我的RAG系统主要回答什么类型的问题是精确查找产品参数还是总结一份报告或是回答开放性的“如何做”问题问题类型决定了所需信息的颗粒度从而决定了分块的粗细。心法二数据勘探先行。在写任何分块代码之前花时间仔细阅读你的原始文档。用眼睛看找出它的结构规律是标题分明还是段落绵长是代码注释丰富还是表格数据密集这些直观感受是最好的设计输入。心法三实现一个“分块分析器”。我习惯写一个小工具输入文档和分块参数输出两种可视化1) 每个块的大小分布直方图2) 将切割点标记在原文上的高亮文本。这能帮你快速发现哪种分法会切碎表格、打断列表。心法四建立持续评估的管道。分块不是一劳永逸的。当你的文档来源发生变化例如新增了API文档或者业务问题类型扩展时分块策略可能需要调整。将第5部分的评估流程自动化定期运行让数据告诉你策略是否依然有效。心法五拥抱复杂性但保持简洁。高级的语义分块、动态分块听起来很诱人但它们也带来了显著的复杂性和计算成本。我的原则是用最简单的策略解决80%的问题。只有当简单的基于分隔符的分块明显成为瓶颈时才考虑引入更复杂的方案。在大多数企业内部知识库场景下一个调优好的RecursiveCharacterTextSplitter或SentenceSplitter配合合适的大小和重叠已经能取得非常不错的效果。分块是RAG工程中一个充满“手艺活”色彩的环节。它没有银弹但通过系统的策略选择、严谨的参数调优和持续的评估迭代你完全可以为自己的数据打造出最合适的“文本手术刀”从而为整个RAG系统的精准和可靠打下坚实的基础。