一、为什么切分是 RAG 的地基RAG 不能把整本书丢给大模型(上下文窗口 成本 检索精度都顶不住)。关键是因为切分过大→噪音多、匹配差;切分过小→代词/上下文丢失、易幻觉。语义完整性 × 检索精度的平衡点就是切分策略的核心目标。Amir Teymoori 与 Chroma 2025 研究都把这一步列为RAG 成败的第一变量。二、8 种主流切分策略(按复杂度递增)1. 固定大小切分 (Fixed-size)最朴素——按字符数 / Token 数切,带 overlap。deffixed_size_chunk(text,chunk_size512,overlap50):chunks,start[],0whilestartlen(text):chunks.append(text[start:startchunk_size])startchunk_size-overlapreturnchunks问题:不懂结构,容易把句子/列表/代码块从中间切断。适用:高度统一的文本(短消息、社交帖子)。2. 递归字符切分 (Recursive Character)——LangChain 默认,生产环境 80% 的选择按分隔符列表从大粒度到小粒度依次尝试,满足大小就停。默认 separators:[\n\n, \n, , ]也就是:段落 → 行 → 词 → 字符。这样能最大程度保留语义单元。fromlangchain_text_splittersimportRecursiveCharacterTextSplitter splitterRecursiveCharacterTextSplitter(chunk_size512,chunk_overlap50,length_functionlen,separators[\n\n,\n,. ,? ,! , ,])chunkssplitter.split_text(your_text)结论来源:LangChain 官方实现;Chroma 2025 研究指出「400 token 10–20% overlap」配合text-embedding-3-large可达88–89% recall。3. 文档结构切分 (Document-based)按格式专属结构切:MarkdownHeaderTextSplitter按#/##/###标题切,保留层级 metadataMarkdownTextSplitter按 Markdown 自身语义切(分隔符含代码块围栏 )通常两者串联用:先用MarkdownHeaderTextSplitter沿标题分大块,再把每个大块喂给RecursiveCharacterTextSplitter控大小——既保结构又保长度。4. 句子切分 (SentenceSplitter)按句号/问号/感叹号断句,适合对句子语义完整性要求高的场景(FAQ、对话)。5. 语义切分 (Semantic Chunking)——质量天花板按句间相似度找主题切换点:fromlangchain_experimental.text_splitterimportSemanticChunkerfromlangchain_openaiimportOpenAIEmbeddings splitterSemanticChunker(OpenAIEmbeddings(),breakpoint_threshold_typepercentile,breakpoint_threshold_amount50)用句向量之间的余弦相似度,相似度骤降处即切点Chroma 研究:LLM 语义切分可达91.9% recall(所有策略最高)代价:每句都要 embedding,成本线性增加6. LLM 驱动切分 (LLM-based)让 LLM 自己读完整文,决定在哪里切最合理。质量高但贵且慢,适合一次性处理关键文档。7. Agentic 切分 (Agentic)让 Agent 按文档类型动态选策略(Markdown 一种、代码一种、对话一种)。Amir Teymoori 预测:2025 下半年 Agentic Chunking 会进入主流生产级 RAG。8. Late Chunking / 层次 / 父子切分Late Chunking:先 embed 整篇文档,再在 embedding 序列上切——保留跨块上下文(尤其代词消解)父子切分:父块 1024-2048 token 给 LLM 推理,子块 256-512 token 做检索命中——适合既要全局又要局部的法律/技术文档三、关键参数怎么定(选型决策的核心)参数经验值来源依据chunk_size默认 400–512 tokenChroma 2025 研究短文 FAQ / 客服200–400 token行业基准长文 / 论文 / 技术文档512–800 token行业基准代码仓库300–500 token(保住一个函数)LangChainfrom_languagechunk_overlap10–20%(标准)Chroma / Databricks结构化文档(手册/论文)5–10% 也行Databricks非结构化(对话/网页)15–20% 更稳Databrickslength_function优先用tiktoken防止字符数 ≠ token 数关键原则:chunk_overlap 必须是和 chunk_size 同单位(都是 token 或都是 char),否则行为会对不上。四、RecursiveCharacterTextSplitter的三种合并场景针对递归切分器遇到 chunk 不足 512 时的三种行为(LangChain 实现细节):场景触发条件行为A(最常见)不足 512 的碎片后面还有内容,且叠加后 ≤ 512持续合并,直到接近 512 才截断B(文件末尾)不足 512 的碎片是最后一片,即使加上缓冲区也不够剩余部分直接作为最后一个 Chunk 输出,不强制补白(chunk_size是上限,不是目标值)C(单碎片超长)某个\n\n段本身就 512(如 1000 字)放弃该分隔符,降级到\n(行)→ 句号 → 空格 →逐字强制切到 ≤ 512举例(场景 A):碎片1(200 字) 碎片2(200 字) 400 字(≤ 512),继续合并碎片3(200 字)→ 600 字( 512)。此时碎片1 碎片2 合成一个 Chunk(400 字),碎片3 作为新 Chunk 的开头。中文场景建议把句号、逗号加进 fallback 链:separators[\n\n,\n, ,。,,]确保长段落不会被硬砍在英文逗号或空格上。五、Markdown 文档的标准两阶段流水线fromlangchain_text_splittersimportMarkdownHeaderTextSplitter,RecursiveCharacterTextSplitter# 阶段 1:按标题分层(保留 H1/H2/H3/H4 作为 metadata)_MD_HEADER_SPLITTERMarkdownHeaderTextSplitter(headers_to_split_on[(#,H1),(##,H2),(###,H3),(####,H4),],strip_headersFalse,)# 阶段 2:把每个大块再按长度切(中英文混合分隔符)_CHAR_SPLITTERRecursiveCharacterTextSplitter(chunk_size512,chunk_overlap100,separators[\n\n,\n, ,。,,],)defload_document(file_path:str)-list:统一文档加载入口,扩展时可在此加格式分发rawopen(file_path,encodingutf-8).read()md_docs_MD_HEADER_SPLITTER.split_text(raw)return_CHAR_SPLITTER.split_documents(md_docs)关键点:阶段 1 的输出带 metadata(比如{H1:第二章,H2:2.1 概述}),检索时命中后可在 prompt 里把这些层级带回去——显著提升答案的上下文还原度。六、选型决策树(实战速查)内容是什么? ├── 高度统一(短消息) → 固定大小 ├── 结构化 Markdown / HTML → 文档结构(标题) 递归字符(两阶段) ├── 代码 → RecursiveCharacterTextSplitter.from_language() ├── 叙事/技术长文 → 语义切分 / Late Chunking ├── 高价值低数量 → LLM 驱动 └── 内容异构(混合仓库) → Agentic / Hybrid chunk_size 选多少? ├── 默认起手 → 512 token 10% overlap ├── 短问答 → 200–400 token └── 论文/手册 → 512–800 token,overlap 5–10% 要不要做父子切分? ├── 只要检索快 → 单层 └── 还要给 LLM 长上下文推理 → 父子(父 2048 / 子 256–512)七、常见陷阱(Chroma / Databricks / Amir Teymoori)切太小:代词丢失 → 幻觉。切太大:噪音多 占 token 多 → 慢 贵。零 overlap:跨块查询的关键词会正好落在边界外,漏召回。无视结构:在表格/列表/代码中间切断。一套参数打天下:FAQ 适用 ≠ 论文适用。不评测就上线:切分是唯一必须用真实查询评估的环节——A/B 不同策略跑 recalln 再说。length_function len:中文 / emoji / 多字节字符,字符数 ≠ token 数,容易超出 embedding 模型 512 上下文。生产建议换 tiktoken。八、一句话总结起手配置:RecursiveCharacterTextSplitter(chunk_size512, chunk_overlap10–20%, separators[\n\n,\n,。,, ,], length_functiontiktoken_len)。Markdown 文档先走MarkdownHeaderTextSplitter留层级 metadata,再走递归切分控长度。chunk_size是上限不是目标,不足的部分不会硬补。语义切分能冲到 91.9% recall,但贵——先做评测,再决定是否升级。
RAG 文档切分(Chunking)策略与实现细节 —— 全网技术汇总
一、为什么切分是 RAG 的地基RAG 不能把整本书丢给大模型(上下文窗口 成本 检索精度都顶不住)。关键是因为切分过大→噪音多、匹配差;切分过小→代词/上下文丢失、易幻觉。语义完整性 × 检索精度的平衡点就是切分策略的核心目标。Amir Teymoori 与 Chroma 2025 研究都把这一步列为RAG 成败的第一变量。二、8 种主流切分策略(按复杂度递增)1. 固定大小切分 (Fixed-size)最朴素——按字符数 / Token 数切,带 overlap。deffixed_size_chunk(text,chunk_size512,overlap50):chunks,start[],0whilestartlen(text):chunks.append(text[start:startchunk_size])startchunk_size-overlapreturnchunks问题:不懂结构,容易把句子/列表/代码块从中间切断。适用:高度统一的文本(短消息、社交帖子)。2. 递归字符切分 (Recursive Character)——LangChain 默认,生产环境 80% 的选择按分隔符列表从大粒度到小粒度依次尝试,满足大小就停。默认 separators:[\n\n, \n, , ]也就是:段落 → 行 → 词 → 字符。这样能最大程度保留语义单元。fromlangchain_text_splittersimportRecursiveCharacterTextSplitter splitterRecursiveCharacterTextSplitter(chunk_size512,chunk_overlap50,length_functionlen,separators[\n\n,\n,. ,? ,! , ,])chunkssplitter.split_text(your_text)结论来源:LangChain 官方实现;Chroma 2025 研究指出「400 token 10–20% overlap」配合text-embedding-3-large可达88–89% recall。3. 文档结构切分 (Document-based)按格式专属结构切:MarkdownHeaderTextSplitter按#/##/###标题切,保留层级 metadataMarkdownTextSplitter按 Markdown 自身语义切(分隔符含代码块围栏 )通常两者串联用:先用MarkdownHeaderTextSplitter沿标题分大块,再把每个大块喂给RecursiveCharacterTextSplitter控大小——既保结构又保长度。4. 句子切分 (SentenceSplitter)按句号/问号/感叹号断句,适合对句子语义完整性要求高的场景(FAQ、对话)。5. 语义切分 (Semantic Chunking)——质量天花板按句间相似度找主题切换点:fromlangchain_experimental.text_splitterimportSemanticChunkerfromlangchain_openaiimportOpenAIEmbeddings splitterSemanticChunker(OpenAIEmbeddings(),breakpoint_threshold_typepercentile,breakpoint_threshold_amount50)用句向量之间的余弦相似度,相似度骤降处即切点Chroma 研究:LLM 语义切分可达91.9% recall(所有策略最高)代价:每句都要 embedding,成本线性增加6. LLM 驱动切分 (LLM-based)让 LLM 自己读完整文,决定在哪里切最合理。质量高但贵且慢,适合一次性处理关键文档。7. Agentic 切分 (Agentic)让 Agent 按文档类型动态选策略(Markdown 一种、代码一种、对话一种)。Amir Teymoori 预测:2025 下半年 Agentic Chunking 会进入主流生产级 RAG。8. Late Chunking / 层次 / 父子切分Late Chunking:先 embed 整篇文档,再在 embedding 序列上切——保留跨块上下文(尤其代词消解)父子切分:父块 1024-2048 token 给 LLM 推理,子块 256-512 token 做检索命中——适合既要全局又要局部的法律/技术文档三、关键参数怎么定(选型决策的核心)参数经验值来源依据chunk_size默认 400–512 tokenChroma 2025 研究短文 FAQ / 客服200–400 token行业基准长文 / 论文 / 技术文档512–800 token行业基准代码仓库300–500 token(保住一个函数)LangChainfrom_languagechunk_overlap10–20%(标准)Chroma / Databricks结构化文档(手册/论文)5–10% 也行Databricks非结构化(对话/网页)15–20% 更稳Databrickslength_function优先用tiktoken防止字符数 ≠ token 数关键原则:chunk_overlap 必须是和 chunk_size 同单位(都是 token 或都是 char),否则行为会对不上。四、RecursiveCharacterTextSplitter的三种合并场景针对递归切分器遇到 chunk 不足 512 时的三种行为(LangChain 实现细节):场景触发条件行为A(最常见)不足 512 的碎片后面还有内容,且叠加后 ≤ 512持续合并,直到接近 512 才截断B(文件末尾)不足 512 的碎片是最后一片,即使加上缓冲区也不够剩余部分直接作为最后一个 Chunk 输出,不强制补白(chunk_size是上限,不是目标值)C(单碎片超长)某个\n\n段本身就 512(如 1000 字)放弃该分隔符,降级到\n(行)→ 句号 → 空格 →逐字强制切到 ≤ 512举例(场景 A):碎片1(200 字) 碎片2(200 字) 400 字(≤ 512),继续合并碎片3(200 字)→ 600 字( 512)。此时碎片1 碎片2 合成一个 Chunk(400 字),碎片3 作为新 Chunk 的开头。中文场景建议把句号、逗号加进 fallback 链:separators[\n\n,\n, ,。,,]确保长段落不会被硬砍在英文逗号或空格上。五、Markdown 文档的标准两阶段流水线fromlangchain_text_splittersimportMarkdownHeaderTextSplitter,RecursiveCharacterTextSplitter# 阶段 1:按标题分层(保留 H1/H2/H3/H4 作为 metadata)_MD_HEADER_SPLITTERMarkdownHeaderTextSplitter(headers_to_split_on[(#,H1),(##,H2),(###,H3),(####,H4),],strip_headersFalse,)# 阶段 2:把每个大块再按长度切(中英文混合分隔符)_CHAR_SPLITTERRecursiveCharacterTextSplitter(chunk_size512,chunk_overlap100,separators[\n\n,\n, ,。,,],)defload_document(file_path:str)-list:统一文档加载入口,扩展时可在此加格式分发rawopen(file_path,encodingutf-8).read()md_docs_MD_HEADER_SPLITTER.split_text(raw)return_CHAR_SPLITTER.split_documents(md_docs)关键点:阶段 1 的输出带 metadata(比如{H1:第二章,H2:2.1 概述}),检索时命中后可在 prompt 里把这些层级带回去——显著提升答案的上下文还原度。六、选型决策树(实战速查)内容是什么? ├── 高度统一(短消息) → 固定大小 ├── 结构化 Markdown / HTML → 文档结构(标题) 递归字符(两阶段) ├── 代码 → RecursiveCharacterTextSplitter.from_language() ├── 叙事/技术长文 → 语义切分 / Late Chunking ├── 高价值低数量 → LLM 驱动 └── 内容异构(混合仓库) → Agentic / Hybrid chunk_size 选多少? ├── 默认起手 → 512 token 10% overlap ├── 短问答 → 200–400 token └── 论文/手册 → 512–800 token,overlap 5–10% 要不要做父子切分? ├── 只要检索快 → 单层 └── 还要给 LLM 长上下文推理 → 父子(父 2048 / 子 256–512)七、常见陷阱(Chroma / Databricks / Amir Teymoori)切太小:代词丢失 → 幻觉。切太大:噪音多 占 token 多 → 慢 贵。零 overlap:跨块查询的关键词会正好落在边界外,漏召回。无视结构:在表格/列表/代码中间切断。一套参数打天下:FAQ 适用 ≠ 论文适用。不评测就上线:切分是唯一必须用真实查询评估的环节——A/B 不同策略跑 recalln 再说。length_function len:中文 / emoji / 多字节字符,字符数 ≠ token 数,容易超出 embedding 模型 512 上下文。生产建议换 tiktoken。八、一句话总结起手配置:RecursiveCharacterTextSplitter(chunk_size512, chunk_overlap10–20%, separators[\n\n,\n,。,, ,], length_functiontiktoken_len)。Markdown 文档先走MarkdownHeaderTextSplitter留层级 metadata,再走递归切分控长度。chunk_size是上限不是目标,不足的部分不会硬补。语义切分能冲到 91.9% recall,但贵——先做评测,再决定是否升级。
