切片策略

一、为什么 RAG 要切片？

RAG 不是把整篇文档直接丢给大模型，而是先把文档切成多个小片段：

原始文档
  ↓
切片 Chunk
  ↓
向量化 Embedding
  ↓
存入向量库
  ↓
用户提问时检索相关 Chunk
  ↓
拼接上下文给大模型回答

切片质量会直接影响：

影响点	说明
检索准确率	切得太碎，语义不完整；切得太大，噪声多
上下文完整性	是否能保留完整的一段意思
向量质量	Chunk 内容越清晰，Embedding 越准确
成本	Chunk 越多，向量库越大，检索和存储成本越高
回答质量	检索不到关键内容，大模型就容易瞎答

---

二、6 种切片策略总览

你图里的文件分别是：

1-固定长度切片.py
2-句子边界切片.py
3-LLM语义切片.py
4-层次切片.py
5-滑动窗口切片.py
6-自适应切片.py

它们的区别核心在于：

到底按照什么边界来切？是按长度、句子、语义、标题层级，还是动态判断？

---

三、1. 固定长度切片

核心思想

按照固定字符数或 token 数切。

例如每 500 个字符切一段：

Chunk 1：第 1 - 500 字
Chunk 2：第 501 - 1000 字
Chunk 3：第 1001 - 1500 字

示例

原文：

RAG 是检索增强生成技术。它通常包括文档加载、文本切分、向量化、向量存储、检索、重排序和生成回答几个步骤。

如果固定每 20 个字切一次，可能变成：

Chunk 1：RAG 是检索增强生成技术。它通常
Chunk 2：包括文档加载、文本切分、向量化
Chunk 3：、向量存储、检索、重排序和生成回答几个步骤。

优点

优点	说明
简单	实现最容易
快	不需要复杂分析
稳定	每个 Chunk 大小接近
适合批处理	很容易并发处理大量文档

缺点

缺点	说明
容易切断语义	一句话可能被切成两半
上下文不完整	检索出来的片段可能缺前因后果
对表格、代码、标题不友好	结构会被破坏

适合场景

适合：

日志
纯文本
大批量非结构化文档
对语义完整性要求不高的场景

不太适合：

合同
论文
技术文档
代码文档
法律条款

---

四、2. 句子边界切片

核心思想

不粗暴按长度切，而是尽量按照句号、问号、感叹号、换行符等自然边界切。

先按句子拆分
再把多个句子组合成一个 Chunk

示例

原文：

RAG 是检索增强生成技术。它可以解决大模型知识过时的问题。RAG 通常包含检索、重排序和生成三个核心阶段。

切片后：

Chunk 1：RAG 是检索增强生成技术。它可以解决大模型知识过时的问题。

Chunk 2：RAG 通常包含检索、重排序和生成三个核心阶段。

优点

优点	说明
语义更完整	不容易把一句话切断
可读性好	Chunk 本身像自然段
比固定长度更适合问答	检索出来的信息更完整

缺点

缺点	说明
长句不好处理	有些句子特别长
对标题层级感知弱	不知道这一句属于哪个章节
对表格、代码仍然不友好	表格和代码不是普通句子

适合场景

适合：

FAQ
说明文档
制度文档
普通文章
客服知识库

例如：

用户问：退款多久到账？

句子边界切片通常效果不错，因为答案经常就是一两句话。

---

五、3. LLM 语义切片

核心思想

让 LLM 或语义模型判断：

哪些内容属于同一个语义主题，哪些地方应该切开。

它不是机械地按长度或者标点切，而是按“意思”切。

示例

原文：

RAG 包括文档加载、文本切分、向量化和检索。Redis 是一种高性能内存数据库，常用于缓存和分布式锁。向量数据库用于存储 Embedding，并支持相似度搜索。

普通切片可能会混在一起。

LLM 语义切片可能会切成：

Chunk 1：RAG 包括文档加载、文本切分、向量化和检索。向量数据库用于存储 Embedding，并支持相似度搜索。

Chunk 2：Redis 是一种高性能内存数据库，常用于缓存和分布式锁。

因为它知道：

RAG + 向量数据库 是同一类主题
Redis 是另一个主题

优点

优点	说明
语义完整性最好	更接近人类理解
检索质量高	一个 Chunk 通常就是一个完整知识点
适合复杂文档	技术文档、论文、方案文档效果好

缺点

缺点	说明
成本高	调用 LLM 有 token 成本
速度慢	不能像固定切片那么快
稳定性受模型影响	不同模型切法可能不同
工程复杂	需要控制超时、重试、并发、缓存

适合场景

适合：

技术方案
论文
合同
产品文档
复杂知识库
高质量问答系统

如果你做的是企业级 RAG，想要回答准确，LLM 语义切片会比固定长度切片更好。

---

六、4. 层次切片

核心思想

按照文档结构切，比如：

文档
  ├── 一级标题
  │     ├── 二级标题
  │     │     ├── 段落
  │     │     └── 表格
  │     └── 二级标题
  └── 一级标题

它会保留父子关系。

示例

原文：

# 支付系统设计

## 1. 统一下单

统一下单负责创建支付订单。

## 2. 支付回调

支付回调用于接收微信或支付宝的支付结果。

## 3. 退款处理

退款处理需要校验订单状态和退款金额。

层次切片后：

{
  "title": "支付系统设计 > 统一下单",
  "content": "统一下单负责创建支付订单。"
}

{
  "title": "支付系统设计 > 支付回调",
  "content": "支付回调用于接收微信或支付宝的支付结果。"
}

{
  "title": "支付系统设计 > 退款处理",
  "content": "退款处理需要校验订单状态和退款金额。"
}

优点

优点	说明
保留文档结构	知道 Chunk 属于哪个章节
适合长文档	可以按标题、章节、段落组织
可做父子检索	先检索小 Chunk，再返回大段上下文
可追溯性强	可以告诉用户来自哪个章节

缺点

缺点	说明
依赖文档结构	如果文档标题混乱，效果下降
解析复杂	PDF、Word、Markdown 处理方式不同
实现成本较高	要维护层级 metadata

适合场景

非常适合：

技术文档
产品手册
法律合同
论文
API 文档
企业制度文档

尤其是这种结构：

第一章
第二章
2.1
2.2
三级标题

层次切片效果很好。

---

七、5. 滑动窗口切片

核心思想

每个 Chunk 之间保留一部分重叠内容。

例如：

chunk_size = 500
overlap = 100

切片方式：

Chunk 1：第 1 - 500 字
Chunk 2：第 401 - 900 字
Chunk 3：第 801 - 1300 字

为什么要重叠？

因为固定切片容易把关键信息切断。

例如：

订单超时未支付时，系统会发送延迟消息到 RabbitMQ。消费者收到消息后，需要再次查询订单状态。

如果刚好从中间切断：

Chunk 1：订单超时未支付时，系统会发送延迟消息到
Chunk 2：RabbitMQ。消费者收到消息后，需要再次查询订单状态。

检索时可能只搜到 Chunk 2，但 Chunk 2 缺少前面的原因。

滑动窗口可以避免这个问题。

优点

优点	说明
提高召回率	边界处的信息不容易丢
简单有效	在固定切片基础上增加 overlap
适合长文本	对连续文本比较友好

缺点

缺点	说明
数据冗余	重叠内容会重复存储
成本增加	Chunk 数量变多
检索结果可能重复	大模型看到重复上下文
需要去重	检索后最好做结果合并

适合场景

适合：

长篇文档
小说
技术文档
没有明显标题结构的文本

---

八、6. 自适应切片

核心思想

不是固定一种切法，而是根据文档内容动态调整。

比如：

普通段落：按句子切
标题结构明显：按层次切
表格：整体保留
代码块：不要切断函数
图片：OCR + 图片描述
长段落：语义切片
短段落：合并

它是一种综合策略。

示例

一个 PDF 里面有：

标题
正文
表格
图片
代码
脚注

自适应切片可能这样处理：

内容类型	切片方式
标题章节	层次切片
普通正文	句子边界切片
长段落	语义切片
表格	整表转 Markdown/JSON
代码	按函数/类切
图片	OCR + Caption
PDF 页码	放入 metadata

优点

优点	说明
效果最好	不同内容用不同策略
工程价值高	适合真实企业知识库
可扩展性强	后续可支持 PDF、图片、表格、音视频
检索质量高	兼顾完整性和准确率

缺点

缺点	说明
实现最复杂	需要文档分类、结构识别
调试成本高	不同文件类型都要测试
规则较多	需要持续优化
依赖解析能力	PDF、表格、图片解析质量很关键

适合场景

适合企业级 RAG：

知识库问答
企业文档助手
合同问答
运维文档检索
产品手册问答
多模态知识库

---

九、6 种策略核心区别对比

策略	切片依据	语义完整性	实现难度	成本	适合场景
固定长度切片	字符数 / token 数	低	低	低	日志、普通文本
句子边界切片	标点、句子	中	低~中	低	FAQ、说明文档
LLM 语义切片	语义主题	高	高	高	论文、技术文档
层次切片	标题、章节结构	高	中~高	中	API 文档、合同、手册
滑动窗口切片	固定长度 + 重叠	中	低	中	长文本、连续文本
自适应切片	内容类型动态判断	很高	很高	中~高	企业级 RAG

---

十、怎么选择切片策略？

1. 简单文档问答

推荐：

句子边界切片 + 少量 overlap

适合：

FAQ
制度文档
普通 Word 文档

---

2. 长篇技术文档

推荐：

层次切片 + 滑动窗口

比如：

Spring Boot 文档
支付系统设计文档
接口文档
部署文档

---

3. 高质量知识库问答

推荐：

层次切片 + LLM 语义切片 + Rerank

这是效果比较好的企业级方案。

---

4. PDF、图片、表格混合文档

推荐：

自适应切片

因为 PDF 里面经常有：

正文 + 表格 + 图片 + 页眉页脚

不能用单一策略粗暴处理。

---

十一、企业级 RAG 推荐方案

如果你要真正落地，我建议不要只用一种切片。

可以这样设计：

文件上传
  ↓
文件类型识别
  ↓
文档解析
  ↓
结构识别
  ↓
自适应切片
  ├── 有标题：层次切片
  ├── 普通文本：句子边界切片
  ├── 长段落：语义切片
  ├── 表格：整表保留
  ├── 图片：OCR + Caption
  └── 代码：按类/方法切
  ↓
Chunk metadata 补充
  ↓
Embedding
  ↓
向量库存储

Chunk 结构建议这样设计：

{
  "chunkId": "chunk_001",
  "fileId": "file_1001",
  "content": "退款申请通过后，系统才允许发起退款。",
  "chunkType": "text",
  "titlePath": "支付系统设计 > 退款处理 > 退款审核",
  "pageNo": 5,
  "startOffset": 1200,
  "endOffset": 1450,
  "tokenCount": 180,
  "metadata": {
    "source": "支付系统设计.pdf",
    "tenantId": "10001",
    "permission": "private"
  }
}

---

十二、最重要的区别一句话总结 🎯

策略	一句话理解
固定长度切片	按长度硬切，简单但容易切断语义
句子边界切片	按句子切，语义比固定长度更完整
LLM 语义切片	让模型按主题切，效果好但成本高
层次切片	按标题章节切，适合结构化文档
滑动窗口切片	切片之间有重叠，防止边界信息丢失
自适应切片	根据内容类型动态选择切法，最适合企业落地