一、为什么切分是 RAG 的"地基"

RAG 不能把整本书丢给大模型(上下文窗口 + 成本 + 检索精度都顶不住)。关键是因为：切分过大→噪音多、匹配差;切分过小→代词/上下文丢失、易幻觉。"语义完整性 × 检索精度"的平衡点就是切分策略的核心目标。

Amir Teymoori 与 Chroma 2025 研究都把这一步列为"RAG 成败的第一变量"。

---

二、8 种主流切分策略(按复杂度递增)

1. 固定大小切分 (Fixed-size)

最朴素——按字符数 / Token 数切,带 overlap。

def fixed_size_chunk(text, chunk_size=512, overlap=50):
chunks, start = [], 0
while start < len(text):
chunks.append(text[start:start+chunk_size])
start += chunk_size - overlap
return chunks

问题:不懂结构,容易把句子/列表/代码块从中间切断。适用:高度统一的文本(短消息、社交帖子)。

2. 递归字符切分 (Recursive Character)——LangChain 默认,生产环境 80% 的选择

按分隔符列表从大粒度到小粒度依次尝试,满足大小就停。默认 separators:

[”\n\n”, ”\n”, ” ”, ””]

也就是:段落 → 行 → 词 → 字符。这样能最大程度保留语义单元。

from langchain_text_splitters import RecursiveCharacterTextSplitter
splitter = RecursiveCharacterTextSplitter(
chunk_size=512, chunk_overlap=50,
length_function=len,
separators=[”\n\n”, ”\n”, ”. ”, ”? ”, ”! ”, ” ”, ””]
)
chunks = splitter.split_text(your_text)

结论来源:LangChain 官方实现;Chroma 2025 研究指出「400 token + 10–20% overlap」配合 text-embedding-3-large 可达88–89% recall。

3. 文档结构切分 (Document-based)

按格式专属结构切:

• MarkdownHeaderTextSplitter

  按 #/##/### 标题切,保留层级 metadata

• MarkdownTextSplitter

  按 Markdown 自身语义切(分隔符含代码块围栏 ` ````)

通常两者串联用:先用 MarkdownHeaderTextSplitter 沿标题分大块,再把每个大块喂给 RecursiveCharacterTextSplitter 控大小——既保结构又保长度。

4. 句子切分 (SentenceSplitter)

按句号/问号/感叹号断句,适合对句子语义完整性要求高的场景(FAQ、对话)。

5. 语义切分 (Semantic Chunking)——质量天花板

按"句间相似度"找主题切换点:

from langchain_experimental.text_splitter import SemanticChunker
from langchain_openai import OpenAIEmbeddings
splitter = SemanticChunker(
OpenAIEmbeddings(),
breakpoint_threshold_type=”percentile”,
breakpoint_threshold_amount=50
)

• 用句向量之间的余弦相似度,相似度骤降处即切点
• 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 token	Chroma 2025 研究
短文 FAQ / 客服	200–400 token	行业基准
长文 / 论文 / 技术文档	512–800 token	行业基准
代码仓库	300–500 token(保住一个函数)	LangChain from_language
chunk_overlap	10–20%(标准)	Chroma / Databricks
结构化文档(手册/论文)	5–10% 也行	Databricks
非结构化(对话/网页)	15–20% 更稳	Databricks
length_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 文档的标准两阶段流水线

from langchain_text_splitters import MarkdownHeaderTextSplitter, RecursiveCharacterTextSplitter
# 阶段 1:按标题分层(保留 H1/H2/H3/H4 作为 metadata)
_MD_HEADER_SPLITTER = MarkdownHeaderTextSplitter(
headers_to_split_on=[
(”#”, ”H1”), (”##”, ”H2”),
(”###”, ”H3”), (”####”, ”H4”),
],
strip_headers=False,
)
# 阶段 2:把每个大块再按长度切(中英文混合分隔符)
_CHAR_SPLITTER = RecursiveCharacterTextSplitter(
chunk_size=512, chunk_overlap=100,
separators=[”\n\n”, ”\n”, ” ”, ”。”, ”，”, ””],
)
def load_document(file_path: str) -> list:
”””统一文档加载入口,扩展时可在此加格式分发”””
raw = open(file_path, encoding=”utf-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)

1. 切太小:代词丢失 → 幻觉。
2. 切太大:噪音多 + 占 token 多 → 慢 + 贵。
3. 零 overlap:跨块查询的关键词会正好落在边界外,漏召回。
4. 无视结构:在表格/列表/代码中间切断。
5. 一套参数打天下:FAQ 适用 ≠ 论文适用。
6. 不评测就上线:切分是唯一必须用真实查询评估的环节——A/B 不同策略跑 recall@n 再说。
7. length_function = len:中文 / emoji / 多字节字符,字符数 ≠ token 数,容易超出 embedding 模型 512 上下文。生产建议换 tiktoken。

---

结语：抓住大模型时代的职业机遇

AI大模型的发展不是“替代人类”，而是“重塑职业价值”——它淘汰的是重复性、低附加值的工作，却催生了更多需要“技术+业务”交叉能力的高端岗位。对于求职者而言，想要在这波浪潮中立足，不仅需要掌握Python、TensorFlow/PyTorch等技术工具，更要深入理解目标行业的业务逻辑（如金融的风险控制、医疗的临床需求），成为“懂技术、懂业务”的复合型人才。

无论是技术研发岗（如算法工程师、研究员），还是业务落地岗（如产品经理、应用工程师），大模型都为不同背景的职场人提供了广阔的发展空间。只要保持学习热情，紧跟技术趋势，就能在AI大模型时代找到属于自己的职业新蓝海。

最近两年大模型发展很迅速，在理论研究方面得到很大的拓展，基础模型的能力也取得重大突破，大模型现在正在积极探索落地的方向，如果与各行各业结合起来是未来落地的一个重大研究方向

大模型应用工程师年包50w+属于中等水平，如果想要入门大模型，那现在正是最佳时机

2025年Agent的元年，2026年将会百花齐放，相应的应用将覆盖文本，视频，语音，图像等全模态

如果你对AI大模型入门感兴趣，那么你需要的话可以点击这里大模型重磅福利：入门进阶全套104G学习资源包免费分享！

扫描下方csdn官方合作二维码获取哦！

给大家推荐一个大模型应用学习路线

这个学习路线的具体内容如下：

第一节：提示词工程

提示词是用于与AI模型沟通交流的，这一部分主要介绍基本概念和相应的实践，高级的提示词工程来实现模型最佳效果，以现实案例为基础进行案例讲解，在企业中除了微调之外，最喜欢的就是用提示词工程技术来实现模型性能的提升

第二节：检索增强生成（RAG）

可能大家经常会看见RAG这个名词，这个就是将向量数据库与大模型结合的技术，通过外部知识来增强改进提升大模型的回答结果，这一部分主要介绍RAG架构与组件，从零开始搭建RAG系统，生成部署RAG，性能优化等

第三节：微调

预训练之后的模型想要在具体任务上进行适配，那就需要通过微调来提升模型的性能，能满足定制化的需求，这一部分主要介绍微调的基础，模型适配技术，最佳实践的案例，以及资源优化等内容

第四节：模型部署

想要把预训练或者微调之后的模型应用于生产实践，那就需要部署，模型部署分为云端部署和本地部署，部署的过程中需要考虑硬件支持，服务器性能，以及对性能进行优化，使用过程中的监控维护等

第五节：人工智能系统和项目

这一部分主要介绍自主人工智能系统，包括代理框架，决策框架，多智能体系统，以及实际应用，然后通过实践项目应用前面学习到的知识，包括端到端的实现，行业相关情景等

学完上面的大模型应用技术，就可以去做一些开源的项目，大模型领域现在非常注重项目的落地，后续可以学习一些Agent框架等内容

上面的资料做了一些整理，有需要的同学可以下方添加二维码获取（仅供学习使用）