摘要：想象一下，你有一份 200 页的技术报告 ，现在要问大模型一个问题：“第二季度的销售增长是多少？”
文档 Chunk（分块）到底咋回事？他是RAG 准确率背后的秘密武器，我们今天来聊聊
想象一下，你有一份 200 页的技术报告 ，现在要问大模型一个问题：“第二季度的销售增长是多少？”
你当然希望模型聪明地只去看第 2 季度那一页，而不是通篇翻 200 页。
可问题是，大模型并不能“一次性吃下整本书” **。 （也许未来可以）**
于是我们想了个办法：
把文档拆成一块一块的小片段（chunk），
给每块生成 embedding 向量，
存进向量数据库，
提问时再从这些块里“捞出”最相关的几块，拼成上下文交给模型。
这，就是 RAG 的核心套路：
召回（Retrieve） → 生成（Generate）
而“怎么切块”，直接决定了：
模型能不能找对地方； 回答是否准确； 是否会答非所问。一句话总结：
Chunking 就是把一大段文本切成许多语义合理的小块，让模型更好地理解和召回。
每个 chunk 通常包含：
一小段文字；一个 embedding 向量；一些元信息（来源、页码、章节等）。像这样：
{ "doc_id": "report_2024_01", "chunk_id": "report_2024_01_3", "text": "第二季度销售额同比增长了12%。", "metadata": { "page": 12, "section": "Q2 Performance" }} 1️⃣ 固定长度切割法（Fixed-size Sliding Window）最朴素的办法——就像切寿司 ：
每刀切 500 个 token，相邻块之间重叠一点（比如 100 个 token），这样上下文还能衔接得上。
常见场景：
LangChain 默认就是这个方案。
适合普通网页、聊天记录、代码注释等。
举例：
“我爱北京天安门，天安门上太阳升”
被切成
块1：我爱北京天安门，天安门上
块2：天安门上太阳升
模型：嗯……我大概明白了，但不太确定
顾名思义，先分句，再拼接。
比如用 NLP 工具（spaCy、HanLP）识别出句子边界，每凑够 400~500 token 组成一个 chunk。
这样不会在句中“半截腰斩”。
优点：
语义更完整；embedding 向量更“干净”；模型理解更连贯。缺点：
分句器不靠谱的话，容易乱切；不太适合有表格或列表的内容。举例：
“第二季度收入增长12%。成本下降5%。利润率提升显著。”
→ 一个 chunk 含 3 句，模型理解： “哦，这是一个连续的业务描述。”
这个方法更“聪明”一点：
它不是随便切，而是“顺着文档的章节结构”来。
比如你有一个 Markdown：
# 第一章 市场概况## !(https://mmbiz.qpic.cn/mmbiz_png/NeVo2wFHxWB3DVJxtsK6czGC2KEkHrBr4x94z9I3aZFpl7jynxEDDjueibLQRxyBVpd4Bycxic97LjrRicSm6cIfA/640?wx_fmt=png&from=appmsg&tp=webp&wxfrom=5&wx_lazy=1) 1.1 全球趋势内容A...## !(https://mmbiz.qpic.cn/mmbiz_png/NeVo2wFHxWB3DVJxtsK6czGC2KEkHrBr4x94z9I3aZFpl7jynxEDDjueibLQRxyBVpd4Bycxic97LjrRicSm6cIfA/640?wx_fmt=png&from=appmsg&tp=webp&wxfrom=5&wx_lazy=1) 1.2 中国市场内容B...分块结果是：
Chunk 1：第一章 → 全球趋势Chunk 2：第一章 → 中国市场优点：
结构清晰，上下文自然；检索时可以保留层级（比如：“第几章第几节”）。缺点：
实现略复杂，要能解析结构；不适合“无格式”的纯文本。适用：报告、说明书、产品文档。
4️⃣ 语义相似度分块（Semantic Similarity Chunking）这就更“AI 味儿”了 。
核心思想：让 embedding 自己决定哪里该切！
实现原理：
先按句子生成 embedding；计算相邻句子的相似度；相似就合并，不相似就分开。ifcosine(sent_emb[i], sent_emb[i+1]) >threshold: mergeelse: split优点：
语义自然连续；模型召回准确率更高；不会因为机械切割打断逻辑。缺点：
算法复杂，embedding 成本高；调参（相似度阈值）麻烦。适用：科研论文、法律、医疗类文档。
⚙️ 5️⃣ Tokenizer 感知切割（Tokenizer-aware Chunking）这是“工程师风格”的切法。
不是按字符数，而是按 模型实际的 token 长度切，比如 tiktoken。
这样可以确保每个 chunk 不会超出 embedding 模型的最大限制。
优点：
精准控制；不会“爆 token”。缺点：
语义可能被截断；需要配合其他策略（如 overlap）。“单一切法不够看？那就全都要！”
例如：
先按标题结构分层；每层再按句子分割；最后再 tokenizer-aware 限制 token 长度；加点 overlap，保证衔接。 文档类型 推荐策略⚙️ Chunk Size Overlap 说明普通网页 / 日志Fixed + Overlap300–50050–100通用快速方案技术报告 / 论文Hierarchical + Sentence500–800100保留章节结构医疗 / 法律类Semantic Similarity400–70050逻辑连续性更好代码文档按函数 / 类分块--AST 分块效果更佳多语言文本Tokenizer-aware + Sentence400–60080防止 token 边界错乱LLM 自行判断语义边界；（现在也可以，但是要花费token）不再需要固定 chunk_size；分块与召回一体化（End-to-End Retrieval）。也许在不远的将来，你只需要告诉模型一句话：
“帮我切好这份文档。”
然后它会智能地说：
“切好了，语义连贯度 98%，召回覆盖率 93%，您请查收 。”
项目核心点分块目的让模型理解、召回更精准核心挑战切割边界、语义连续、控制 token主流方法固定长度 / 语义分句 / 结构化 / 相似度 / 混合最佳实践结构化 + 语义分句 + overlap一句话总结分块分得好，RAG 跑得稳！如果你现在理解了 chunk 是啥，那恭喜你：你已经比 80% 的 RAG 实践者更清楚这块的门道了。
下次再有人问你：“为什么我的 RAG 总答不准？”
你就可以微微一笑说：
“兄弟，你这块切得不太对。”
文章参考：https://blog.dailydoseofds.com/p/5-chunking-strategies-for-rag
来源：正正杂说
