# Chunking 切片的四种策略：从小块到大块到语义分块

之前已经讲过按照固定chunk大小切块，和按照段落分明切块。现在补齐另外两种模式。

## 目录

- [一、为什么切片方式决定 RAG 天花板](#一为什么切片方式决定-rag-天花板)
- [二、四种基础切片策略](#二四种基础切片策略)
- [三、语义分块与结构感知分块](#三语义分块与结构感知分块)
- [四、切片参数怎么定](#四切片参数怎么定)
- [五、可运行的切片实现](#五可运行的切片实现)
- [六、四个工程陷阱](#六四个工程陷阱)
- [七、要点小结](#七要点小结)
- [八、常见问答](#八常见问答)
- [九、3 道模拟面试题](#九-3-道模拟面试题)
- [十、10 条速记清单](#十-10-条速记清单)
- [十一、延伸阅读](#十一延伸阅读)

## 一、为什么切片方式决定 RAG 天花板

**一句话结论：切片决定了"喂给模型的上下文单位"——切太大召回噪声多，切太小语义断裂，RAG 效果上限在切片这步就定了一半。**

RAG 检索的最小单位是 chunk。如果 chunk 太大（一整篇文档），检索命中后塞给模型的上下文里 90% 是无关内容，既浪费 token 又稀释答案；如果太小（一句话），一个完整知识点被切碎，检索到的片段丢了一半关键信息，模型答不全。


![切片两难](https://developer.qcloudimg.com/http-save/yehe-1293908/fabe4084309570c1816097fe29aa3aee.png)

大厂招聘岗位里面比如腾讯「RAG 数据切片策略」、阿里云「知识库预处理」岗位明确把 Chunking 列为知识库工程核心环节。

#### ✅ 本节要点小结

- 切片决定"喂给模型的上下文单位"，定 RAG 效果上限。
- 大块噪声多、小块语义断，目标是"一个 chunk ≈ 一个知识单元"。
- 大厂知识库岗把 Chunking 列为核心环节。

## 二、四种基础切片策略

**一句话结论：从"无脑按字数切"到"按结构切"到"按语义切"，粒度越聪明效果越好，成本也越高。**

| 策略   | 做法                   | 优点      | 缺点     | 适用        |
| ---- | -------------------- | ------- | ------ | --------- |
| **固定长度** | 每 N 字一刀切             | 简单      | 切断语义   | 粗筛/兜底     |
| **按分隔符** | 按段落/换行切              | 保段落完整   | 块大小不均  | 通用文档      |
| **结构感知** | 按标题/Markdown/HTML 结构 | 保章节边界   | 依赖格式规范 | 技术文档/API  |
| **递归切分** | 先段落→句→词逐级切到目标大小      | 兼顾大小与边界 | 实现略复杂  | **生产最常用** |

**递归切分（RecursiveCharacterTextSplitter）是事实标准**：优先在段落边界切，不行再在句子边界，最后才在词边界，尽量保住语义完整。

#### ✅ 本节要点小结

- 四策略：**固定长度 / 按分隔符 / 结构感知 / 递归切分**。
- 递归切分是生产事实标准（优先段落→句→词边界）。
- 结构感知适合格式规范的文档。

## 三、语义分块与结构感知分块

**一句话结论：语义分块用 Embedding 找"话题边界"切，比字数更聪明，但成本更高；结构感知按标题层级切，性价比高。**

| 策略   | 原理                  | 成本        | 效果       |
| ---- | ------------------- | --------- | -------- |
| 语义分块 | 逐句编码，相似度骤降处为边界      | 高（每句一次编码） | 最优但贵     |
| 结构感知 | 按 `##`/`###` 标题层级聚合 | 低         | 好（文档规范时） |
| 父子分块 | 小块检索、大块喂模型          | 中         | **生产推荐** |

**父子分块（Parent-Child）是生产最佳实践**：检索时用小块（精准命中），喂给模型时用其父大块（完整上下文）。兼顾"查得准"和"答得全"。

```
检索阶段: 命中 child chunk "退款时效: 7个工作日"  → 精准
喂模型时: 替换为 parent chunk 整节（含条件/例外）→ 完整
```

#### ✅ 本节要点小结

- 语义分块按话题边界切，最聪明但每句编码成本高。
- 父子分块：小块检索 + 大块喂模型，生产推荐。
- 结构感知按标题层级，格式规范时性价比最高。

## 四、切片参数怎么定

**一句话结论：chunk_size 和 overlap 没有银弹，按"知识单元平均长度"反推，再评测调优。**

| 参数         | 典型值            | 影响               |
| ---------- | -------------- | ---------------- |
| chunk_size | 300–800 字（中文）  | 太小断语义，太大噪声多      |
| overlap    | 10–20% of size | 防边界信息丢失，但太大会重复计费 |
| 最小块        | 丢弃 < 50 字碎片    | 防噪声 chunk        |

**调参方法论**：① 统计知识库里"一个完整知识点"的平均长度；② chunk_size 取该值的 1–1.5 倍；③ 用 3.7 的评估体系测召回率，迭代调整。不要拍脑袋设 512 就完事。

#### ✅ 本节要点小结

- chunk_size 按"知识单元平均长度"反推（中文 300-800 字）。
- overlap 10-20% 防边界丢失，太大重复计费。
- 用 3.7 评估迭代，不拍脑袋。

## 五、可运行的切片实现

**一句话结论：递归切分 + 父子分块，30 行覆盖生产 80% 场景。**

```python
import re

def recursive_split(text: str, size=500, overlap=80) -> list:
    # 优先段落，再句子，再词
    seps = ["\n\n", "\n", "。", "，", " "]
    chunks, start = [], 0
    buf = text
    for sep in seps:
        if len(buf) <= size: break
        parts = re.split(f"({re.escape(sep)})", buf)
        buf, cur = "", ""
        for p in parts:
            if len(cur) + len(p) > size and cur:
                chunks.append(cur.strip()); cur = ""
            cur += p
        buf = "".join(chunks) or cur
    if buf: chunks.append(buf.strip())
    return chunks

# 父子分块：小块检索，父块喂模型
docs = ["## 退款政策\n退款时效为7个工作日。VIP用户可加急至24小时。运费不退。", ...]
parents = docs
children = [c for d in docs for c in recursive_split(d, size=200, overlap=40)]
# 检索命中 child 后，回查其 parent 喂给模型
```

#### ✅ 本节要点小结

- 递归切分：段落→句→词逐级降维，保语义。
- 父子分块：child 检索、parent 喂模型。
- 30 行覆盖生产 80% 切片需求。

## 六、四个工程陷阱

**一句话结论：切片最常死于"一刀切固定长度""overlap 过大""忽略表格/代码块""不保留元数据"。**

| 陷阱         | 现象        | 对策               |
| ---------- | --------- | ---------------- |
| 固定长度无脑切    | 句子拦腰斩，语义断 | 递归切分保边界          |
| overlap 过大 | 重复内容多，多计费 | 10-20% 足够        |
| 表格/代码被切烂   | 结构化信息丢失   | 结构感知，表格整体保留      |
| 丢元数据       | 召回不知来源    | 每块带 source/标题/页码 |

**最隐蔽的是"表格被切烂"**：固定长度切分把一张 10 行表格从中间切断，检索到的半张表模型无法理解。技术文档/API 文档必须结构感知，把表格、代码块作为不可切的最小单元。

#### ✅ 本节要点小结

- 固定长度切断语义，递归切分保边界。
- overlap 10-20% 足够，过大重复计费。
- 表格/代码块须整体保留，每块带元数据。

## 七、要点小结

| # | 要点              | 对应 JD 维度 | 腾讯命中           | 字节命中  |
| - | --------------- | -------- | -------------- | ----- |
| 1 | 切片定 RAG 天花板     | RAG/知识库  | 12.5% (17/136) | 22.7% |
| 2 | 递归切分是生产标准       | RAG/知识库  | 12.5%          | 22.7% |
| 3 | 父子分块：小块检索+大块喂模型 | RAG/知识库  | 12.5%          | 22.7% |
| 4 | 语义分块最聪明但贵       | RAG/知识库  | 12.5%          | 22.7% |
| 5 | 参数按知识单元长度反推     | RAG/知识库  | 12.5%          | 22.7% |
| 6 | 表格/代码块不可切，带元数据  | RAG/知识库  | 12.5%          | 22.7% |

## 八、常见问答

**Q1：chunk_size 设多大？**  
中文建议 300–800 字。先统计知识库"一个完整知识点"的平均长度，取 1–1.5 倍。技术文档偏长（800+），FAQ 偏短（200-300）。

**Q2：overlap 有什么用？为什么不能太大？**  
overlap 让边界处的信息不被切断（如一个知识点跨两个 chunk 边界）。但过大会导致重复内容进索引、检索重复、多计费。10-20% 足够。

**Q3：语义分块值得上吗？**  
内容长且话题切换频繁（如长报告）时值得，召回质量明显好。但每句一次 Embedding 成本高，短文档/格式规范的文档用结构感知更划算。

**Q4：父子分块怎么实现？**  
检索用 child（小块）算相似度，命中后回查其 parent（大块）喂模型。多数向量库支持 metadata 关联或独立存 parent 表。

**Q5：表格怎么切？**  
表格作为不可切最小单元整体保留（结构感知）。跨页长表格按行逻辑分组，不要从中间切断行。

**Q6：多语言文档怎么切？**  
按语言分流后用对应分隔符规则。中文按"。"切、英文按". "切，混切会断句。

**Q7：切片后还要存什么元数据？**  
source（文件名）、标题、章节路径、页码、chunk 序号、所属 parent id。没有元数据，召回后无法溯源和展示引用。

**Q8：知识更新时切片怎么处理？**  
文档改了要重新切片+重新编码+更新向量库，且同步更新 parent 关联。只改原文不重切 = 检索到旧 chunk。

## 九、常见面试题

**题 1：怎么给技术文档知识库设计切片方案？**

- 答题结构：① 结构感知按 Markdown 标题层级；② 表格/代码块整体保留；③ 父子分块（child 检索 + parent 喂模型）；④ 每块带元数据。
- 追问防线：长表格怎么处理？→ 按行逻辑分组，不从中间切断，作为不可切单元。

**题 2：为什么生产推荐父子分块？**

- 答题结构：小块精准命中、大块完整上下文，兼顾查准和答全。
- 追问防线：检索用 child 喂模型用 parent，怎么关联？→ metadata parent_id 或独立 parent 表回查。

**题 3：切片参数怎么定才不会拍脑袋？**

- 答题结构：统计知识单元平均长度→反推 size；overlap 10-20%；用 3.7 评估召回率迭代。
- 追问防线：调参指标看什么？→ 3.7 的召回率/答案命中率，不只看相似度分数。

## 十、10 条速记清单

1. **切片定 RAG 天花板**，一个 chunk ≈ 一个知识单元。
2. **递归切分**是生产事实标准（段落→句→词）。
3. **父子分块**最佳实践：小块检索 + 大块喂模型。
4. 语义分块最聪明但**每句编码成本高**。
5. chunk_size **中文 300-800 字**，按知识单元长度反推。
6. overlap **10-20%**，过大重复计费。
7. **表格/代码块不可切**，整体保留。
8. 每块必带**元数据**（source/标题/页码/parent_id）。
9. 调参靠 **3.7 评估召回率**迭代，不拍脑袋。
10. 知识更新 = **重切 + 重编码 + 更新向量库**。

## 十一、延伸阅读

| 类型   | 标题                                    | 来源                   | 获取日期       |
| ---- | ------------------------------------- | -------------------- | ---------- |
| 论文   | "Chunking Strategies for RAG"（切片对比实证） | arXiv                | 2026-10-09 |
| 官方文档 | LangChain: Text Splitters             | python.langchain.com | 2026-10-09 |
| 官方文档 | LlamaIndex: Node Parsers              | docs.llamaindex.ai   | 2026-10-09 |
| 实践   | "Parent-Child Chunking" 模式            | pinecone.io/learn    | 2026-10-09 |
| 一手案例 | 本工作区《Agent开发工程师岗位调研报告》RAG JD 词频       | 本地                   | 2026-10-09 |


**「切片是 RAG 里最不起眼却最致命的一步——它决定了模型每次'睁眼'看到的，是一个完整的知识，还是一堆被腰斩的碎片。」**


之前已经讲过按照固定chunk大小切块，和按照段落分明切块。现在补齐另外两种模式。

Chunking 切片的四种策略：从小块到大块到语义分块

高级工程师

人工智能

算法

架构设计

RAG切片策略决定检索上限：本文详解四种切分方式，递归切分与父子分块是生产最佳实践。中文chunk_size建议300-800字，overlap取10-20%，表格代码需整体保留。从参数调优到工程避坑，助你掌握知识库核心环节。

代码解释

LlamaIndex

LangChain

Markdown

Agent

2026上云采购 | AI焕新·智启新局

lexiang

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

Chunking 切片的四种策略：从小块到大块到语义分块-腾讯云开发者社区-腾讯云

Chunking 切片的四种策略：从小块到大块到语义分块

Chunking 切片的四种策略：从小块到大块到语义分块

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐