3.1 为什么文档必须切块

这一节讨论的是 RAG 里一个非常基础、但影响后面几乎所有设计的问题：为什么文档通常不能直接整篇进入检索和生成，而要先拆成更小的片段。

很多人第一次做 RAG，会把注意力先放在 embedding、向量库和模型上。但真正开始搭系统以后，很快就会发现：如果 chunk 设计不对，后面检索、重排、上下文构造、引用展示都会一起受影响。

这一节真正想帮你建立的，是一个很关键的认识：

切块不是“为了方便存储做一下拆分”，而是在定义系统以后到底按什么粒度理解、检索和组织知识。

如果这个粒度定义错了，后面很多问题就不是“小调一下参数”能补回来的。

学这一节时，最值得先建立的判断

在继续往后看之前，最好先把这几个判断立住：

Chunk 不是随便切出来的一段文本，而是系统真正拿来做检索和回答组织的知识单元
文档太大时，系统很难稳定定位真正相关的局部内容
文档切得太碎时，系统又容易失去上下文和完整语义
“切不切块”通常不是问题，真正的问题是“按什么边界切、为谁而切”

这一节会回答什么问题

读完这一节后，你最好能更稳地判断：

一个 RAG 系统里的“知识粒度”到底应该落在哪一层
文档整篇入索引为什么会在检索和生成阶段一起出问题
后面设计 chunk 策略时，应该优先避免哪些常见误判