RAG 设计（二）：Embedding 如何切分（Chunk）—— 一套适用于所有 AI 系统的设计方案

很多人在做 RAG 时，第一个想到的问题就是：

Chunk 应该切多大？

网上最常见的答案是：

每 500 Token 切一次。

实际上，这是一个误区。

Chunk 的本质不是按 Token 长度切，而是按"语义单元（Semantic Unit）"切。

不同类型的数据，天然具有不同的语义结构，因此 Chunk 策略应该由数据类型决定，而不是统一的 Token 数量。

本文总结一套适用于 AI 客服、AI 办公、企业知识库、AI Agent、代码助手、法律、医疗 等几乎所有 AI 系统的 Chunk 设计方案。

---

一、为什么需要 Chunk？

LLM 并不会直接搜索整个知识库。

RAG 的流程如下：

Document
    │
    ▼
Chunk（切片）
    │
    ▼
Embedding
    │
    ▼
Vector Database
    │
    ▼
Retriever
    │
    ▼
TopK Chunk
    │
    ▼
LLM

真正参与向量检索的不是 Document，而是 Chunk。

因此：

Chunk 的质量，直接决定了 Retriever 的召回率。

---

二、Chunk 的核心原则

很多人理解 Chunk：

1000 Token

↓

500 Token

↓

500 Token

实际上，这是最简单，也是效果最差的方法。

真正应该遵循的是：

一个 Chunk = 一个完整语义。

例如：

一本产品说明书：

产品说明

第一章 电池

第二章 屏幕

第三章 摄像头

第四章 保修

正确切法：

Chunk1

电池

......

-------------

Chunk2

屏幕

......

-------------

Chunk3

摄像头

......

而不是：

Chunk1

电池

......

屏幕前半部分

-------------

Chunk2

屏幕后半部分

摄像头前半部分

这样语义已经被破坏。

---

三、Chunk 的设计原则

生产环境通常遵循四个原则。

原则一：语义完整

一个 Chunk 只能表达一个主题。

例如：

退款多久到账？

退款一般1~3天到账。

就是一个 Chunk。

不要切成：

退款多久到账？

------------

退款一般

1~3天到账

---

原则二：不要跨主题

错误：

退款

......

物流

......

一个 Chunk 两个主题。

正确：

Chunk1

退款

......

Chunk2

物流

......

---

原则三：上下文完整

例如：

安装步骤

第一步

第二步

第三步

不要：

Chunk1

第一步

------------

Chunk2

第二步

应该：

Chunk

安装步骤

第一步

第二步

第三步

保持完整上下文。

---

原则四：Chunk 不宜过大

Chunk 太大会导致：

• 检索噪声增加

• Token 浪费

• 命中率下降

Chunk 太小又容易：

• 丢失上下文

• 语义不完整

因此：

语义完整 > Token 数量。

---

四、不同数据采用不同 Chunk 策略

1）FAQ（客服、知识问答）

数据特点：

Question

Answer

Chunk：

退款多久到账？

退款一般1~3天到账。

一个 FAQ = 一个 Chunk。

推荐：

100~300 Token。

---

2）Markdown 文档

例如：

# 用户管理

## 创建用户

......

## 删除用户

......

Chunk：

按照标题切。

Chunk1

创建用户

......

Chunk2

删除用户

......

不要固定长度。

---

3）PDF

PDF 通常都有目录。

例如：

第一章

第二章

第三章

建议：

按照：

一级标题

↓

二级标题

↓

正文

切。

如果正文过长，再继续拆。

推荐：

300~600 Token。

---

4）产品说明书

例如：

电池

屏幕

摄像头

尺寸

切法：

Chunk1

电池

......

Chunk2

屏幕

......

Chunk3

摄像头

每个功能一个 Chunk。

---

5）法律法规

例如：

第一章

第二章

第三章

建议：

章节切。

如果：

第一章

3000 Token

再按：

第一节

第二节

第三节

继续切。

不要切断法律条款。

---

6）代码仓库（Code RAG）

例如：

type User struct{}

func CreateUser(){}

func DeleteUser(){}

Chunk：

按照：

一个类

一个接口

一个函数

切。

不要：

一个函数切一半

推荐：

AST（抽象语法树）切分，而不是按行数切分。

---

7）SQL 文档

例如：

CREATE TABLE

INSERT

UPDATE

每条 SQL 一个 Chunk。

---

8）API 文档

例如：

POST /login

GET /user

DELETE /user

每个 API 一个 Chunk。

不要整个 OpenAPI 一起 Embedding。

---

9）会议纪要

例如：

议题一

......

议题二

......

议题三

每个议题一个 Chunk。

---

五、Chunk Size 推荐

数据类型	推荐 Chunk
FAQ	一问一答
Markdown	一级标题 / 二级标题
PDF	300~600 Token
产品说明书	一个功能模块
API 文档	一个接口
SQL	一条 SQL
法律法规	一章 / 一节
代码	一个函数 / 一个类
会议纪要	一个议题
博客	一个章节

可以看到：

没有任何一种数据是统一按 500 Token 切。

---

六、什么时候需要 Overlap？

Overlap（重叠切片）主要用于上下文连续的长文档。

例如：

Chunk1

......

最后100 Token

------------

Chunk2

前100 Token

......

这样可以减少：

上一句在 Chunk1，下一句在 Chunk2。

导致语义断裂。

建议：

类型	Overlap
FAQ	不需要
API	不需要
SQL	不需要
产品说明	50~100 Token
PDF	100 Token
法律	100~200 Token
博客	100 Token

原则：

只有连续阅读的文档才需要 Overlap。

---

七、Embedding 内容如何组织？

很多人直接：

Embedding

↓

正文

实际上建议：

标题

+

摘要

+

关键词

+

正文

例如：

标题：

退款多久到账？

关键词：

退款

到账

正文：

退款一般1~3个工作日到账。

最终 Embedding：

退款多久到账？

退款

到账

退款一般1~3个工作日到账。

这样召回效果明显优于：

退款一般1~3个工作日到账。

---

八、一套通用的 Chunk Pipeline

生产环境推荐统一采用如下 Pipeline：

Document
        │
        ▼
Document Loader
        │
        ▼
Document Parser
        │
        ▼
Document Structure Analysis
（识别标题、章节、函数、API）
        │
        ▼
Semantic Chunk
（按语义切片）
        │
        ▼
Metadata Enrichment
（补充来源、分类、版本等）
        │
        ▼
Embedding
        │
        ▼
Vector Database

其中最关键的一步不是 Embedding，而是：

Semantic Chunk（语义切片）

只有语义切得正确，Embedding 才真正有价值。

---

九、总结

Chunk 的目标不是"切得均匀"，而是"切得有意义"。

企业级 RAG 设计应遵循以下原则：

原则	说明
按语义切，不按 Token 切	一个 Chunk 表达一个完整主题
保持上下文完整	不切断步骤、函数、条款、章节
不跨主题	一个 Chunk 不混合多个知识点
根据数据类型设计 Chunk	FAQ、PDF、代码、API、法律采用不同策略
长文档适当 Overlap	保持连续语义，减少边界信息丢失
Embedding 不只是正文	建议包含标题、关键词、摘要、正文
Metadata 与 Chunk 配合	为检索提供过滤条件，提高召回准确率

一句话总结：Embedding 模型决定了"如何理解文本"，而 Chunk 策略决定了"给模型理解什么文本"。在企业级 RAG 中，Chunk 的设计往往比更换 Embedding 模型带来的收益更大，也是决定整个 AI 系统知识检索质量的关键。