3.2 Chunk 的切分策略

上一节解决的是“为什么文档必须切块”。这一节要继续往前走一步：既然必须切块，那到底该怎么切？

这也是很多 RAG 系统最容易掉进“参数调优陷阱”的地方。因为看起来只是在调：

• chunk size
• overlap
• splitter 类型

但本质上，你其实是在定义系统以后怎样保留语义、怎样定位答案、怎样控制上下文成本。

这一节真正想帮你建立的，是一个更稳的认识：

切块策略没有放之四海而皆准的标准答案，只有“是否匹配当前文档类型、任务目标和后续检索链路”的相对合适方案。

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

• chunk 大小不是越大越全，也不是越小越准
• overlap 不是默认越大越好，它是在“补上下文”和“制造冗余”之间做平衡
• 固定长度、语义切块、结构切块，各自解决的问题不同
• 不同数据类型的切块策略应该不同，不该强行统一

这一节会回答什么问题

• Chunk 应该切多大？为什么没有统一答案？
• Chunk overlap 有什么作用？是不是越大越好？
• 按固定长度切块、按语义切块、按结构切块分别适合什么场景？
• 长文档、FAQ、表格、代码文档的切块策略有什么不同？

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

• 当前系统更像是 chunk 太大、太小，还是边界切错
• 哪种切块方式更适合当前数据
• 后面做检索调优时，问题到底是不是应该先回到切块层处理