RAG 里的 chunking（分块）策略

你怎么把文本切成一块块（chunk），往往比 embedding 模型本身更能决定 RAG 的效果。

为什么 chunk 大小很重要

在 RAG 搜索开始之前，文本必须先被切成一个个较小的片段（chunk，也叫“分块”）。chunk 太大，重要内容会被淹没在大量无关信息里；chunk 太小，又会丢失上下文——一句话单独拿出来，往往没什么意义。

常见的策略

固定大小：死板地按字符数或 token 数切分。实现简单，但常常会切在句子或段落中间。
基于结构：沿着文档天然的边界切分——段落、标题、章节。这种方式更尊重文档本身的结构，通常是更好的默认选择。
语义分块（semantic chunking）：在主题明显发生变化的地方划出边界，靠比较相邻句子的相似度来判断。计算成本更高，但切出来的内容更连贯。

重叠（overlap）

Chunk 之间通常会保留一小段和前一个、后一个 chunk 共有的内容。这样可以避免一条重要信息刚好卡在 chunk 的边界上，被拆成两半，一半落在前一个 chunk，一半落在下一个 chunk 里。

Contextual Retrieval（上下文检索）

Anthropic 描述了一种补充技术：在给每个 chunk 做 embedding 之前，先由模型生成一句简短的上下文说明，加在 chunk 前面，比如点明它属于哪份文档、哪个章节。这解决了一个 chunk 被孤立看待时会丢失上下文的问题。

示例

对 chunk 做 embedding 之前使用的上下文 prompt（大意遵循 Anthropic 的 Contextual Retrieval 方法）：“这是我们要放进整份文档里定位的 chunk：[CHUNK]。请给出一段简短的上下文，用来说明这个 chunk 在整份文档里的位置，以便在搜索时更容易被找到。只需回答这段简短的上下文。”

🛠️ 练习——自己动手试试

在你自己的一份短文档上，对比两种 chunking 策略。

找一份有好几页的文档（比如一篇长教程或一篇博客文章）。
先按固定字符数/token 数（比如 300 个 token）切一遍，再沿着标题/段落切一遍。
写出 3 个你已经知道答案的测试问题，分别检查这两种方式下，正确的 chunk 是否都排在检索结果的前几名。
记录下哪种策略更常把正确的 chunk 排在前面，以及原因是什么。

✅ 自查清单

☐ 你有没有用同样的 3 个测试问题，检验了两种 chunking 方式？
☐ 你知道哪种策略更常把正确的 chunk 排在前面吗？
☐ 你能用一句话说清楚，为什么这种策略表现更好吗？

小测验

根据 Anthropic 自己的测试，Contextual Retrieval（上下文 embedding + BM25）相比纯标准 embedding 搜索，把 Top-20 chunk 未命中率降低了多少？