RAG为什么要切片?有哪些方法?

62 阅读5分钟

在构建RAG(Retrieval-Augmented Generation)系统时,很多人一上来就关注模型选型、向量数据库或召回算法,却往往忽略了一个决定系统效果上限的基础环节——切片(Chunking)。

切片并不是简单地把文本“分段”,而是一次将原始知识转化为可被模型高效检索和理解的结构化语义单元的过程。切片方式选得好,检索更准、上下文更干净;切片设计不合理,再强的模型也很难给出稳定答案。

01

什么是切片(Chunking)?

在RAG(Retrieval-Augmented Generation,检索增强生成)体系中,切片(Chunking)是决定检索效果上限的核心步骤之一,本质上它解决的是:

💡 如何把“人类能读懂的长文档”,转化为“大模型能高效检索和理解的最小语义单元”。

02

为什么RAG一定要做切片?

1️⃣ 技术层面的刚性约束

  • Token限制:主流大模型都有上下文长度限制,长文档必须拆分
  • 计算效率:小片段向量化、检索、拼接成本更低
  • 内存与稳定性:避免一次性处理超大文本导致OOM或请求失败

2️⃣ 检索效果的决定因素

  • 相关性更高:语义更聚焦的片段,更容易被向量检索命中
  • 噪音更少:避免“相关一句话+大段无关内容”一起被召回
  • 上下文更可控:有利于后续prompt拼接和答案生成

3️⃣ 成本与系统规模控制

  • Token成本:减少无效上下文输入
  • 向量库存储成本:避免超大chunk
  • 整体吞吐能力:提升QPS与响应速度

03

常见切片方法

1️⃣ 固定长度切片(Fixed-size Chunking)

核心思路
按固定字符数 / Token数进行拆分,不关心语义边界。

实现方式

每500token一个chunk

优点

  • 实现成本最低,几乎没有额外逻辑
  • 吞吐量高,适合批量离线处理
  • chunk数量可预测,便于容量评估

缺点

  • 极易切断语义单元(定义、结论、代码逻辑)
  • 同一个概念可能分散在多个chunk
  • 对Query稍复杂的问答命中率较低

适用场景

  • 代码、日志、表结构、接口定义
  • 内容本身高度结构化
  • 对语义连续性要求不高的场景

2️⃣ 语义切片(Semantic Chunking)

核心思路
以“语义完整性”为第一原则,在语义边界处分割文本。

实现方式

  • 按句子 + 相似度聚合
  • 基于embedding相似度检测主题漂移
  • 使用LLM判断是否该分段

优点

  • 单个chunk通常能完整回答一个子问题
  • 向量检索相关性明显提升
  • 生成阶段上下文更干净

缺点

  • 切片阶段需要额外模型或embedding计算
  • 离线处理时间明显增加
  • chunk数量不可预测,容量规划更复杂

适用场景

  • 文章、报告、知识型内容
  • 高质量问答 / 知识助手
  • chunk数量不敏感但质量要求高的系统

3️⃣ 结构化切片(Structure-aware Chunking)

核心思路
严格遵循文档已有的逻辑结构进行切分。

切分依据

  • Markdown:标题、段落、列表
  • HTML:h1–h6、section、article
  • PDF:章节、页、目录层级
  • 技术文档:模块 / 接口 / 示例

优点

  • 贴近人类阅读方式
  • chunk可读性极强,方便调试
  • 容易做层级化检索(章节 → 段落)

缺点

  • 强依赖原文档结构质量
  • 扫描版PDF、格式混乱文档效果差
  • chunk大小不均,需要二次裁剪

适用场景

  • 官方文档、产品手册、技术规范
  • 有明确标题层级的内容
  • 企业内部知识库

4️⃣ 重叠切片(Overlapping Chunking)

核心思路
通过相邻chunk的内容重叠,避免关键信息刚好被切断。

典型参数

chunk_size = 500

overlap = 50 ~ 100

优点

  • 明显降低“定义在上一段、解释在下一段”的问题
  • 提高召回率,尤其对模糊Query友好
  • 对固定切片是几乎必选的增强手段

缺点

  • chunk数量上升(≈ 1.1–1.3 倍)
  • 向量库体积变大
  • 生成阶段需要去重或压缩上下文

适用场景

  • 问答系统
  • 高召回优先的知识检索
  • Query不够精确的用户场景

5️⃣ 递归切片(Recursive Chunking)

核心思路
多层级逐步拆分,直到满足目标chunk大小。

典型递归顺序

章节 → 段落 → 句子 → Token

优点

  • 能适配高度异构文档
  • chunk尺寸稳定,语义相对完整
  • 常用于通用型知识系统

缺点

  • 实现逻辑复杂
  • 调参成本高(每一层都有策略)

适用场景

  • 多来源、多格式文档
  • 企业级知识中台
  • RAG基础设施型产品

6️⃣ 混合切片(Hybrid Chunking,强烈推荐)

核心思路
不同层次、不同策略的组合使用。

常见组合方式

  • 结构化切片 → 固定长度二次裁剪
  • 固定切片 + overlap
  • 章节级索引 + 段落级向量
  • 语义切片 + 递归兜底

优点

  • 兼顾召回率与成本
  • 可针对不同Query路由不同层级
  • 易于演进和调优

04

实战中的几个关键建议

1️⃣ 控制切片粒度

  • 太小 → 语义破碎
  • 太大 → 检索不准

经验值:200–800 字,根据场景动态调整


2️⃣ 合理使用重叠

  • 重叠比例:10%–20%
  • 优先在自然语义边界(句号 / 段落)切分
  • 确保定义、结论、公式不被硬切

3️⃣ 用指标而不是感觉评估

  • 召回准确率:相关问题是否命中正确chunk
  • 答案完整性:是否需要频繁“猜上下文”
  • 性能指标:响应时间、向量数量、成本

05

总结

RAG 的效果上限,不在模型,而在切片。

切片不是简单的“分段”,而是一次工程与语义的权衡设计, 选对策略,RAG才能真正做到:检索准、生成稳。

欢迎关注「成为一名架构师」,坚持撰写有价值的IT架构、算法、教程相关文章。