第 3 章 Chunk、Metadata 与索引前设计

本章目标：理解切块和元数据为什么决定检索上限，并建立“检索用块”和“生成用块”分离设计的基本认知。

如果说第 2 章解决的是“哪些数据值得进知识库、进来之前该怎么清理和治理”，那这一章要解决的就是：

这些数据进入索引前，系统到底应该按什么粒度理解它们，又该为这些粒度补上哪些结构信息。

很多 RAG 系统后面检索不稳、召回太粗、回答像碎片、版本和权限边界老出问题，往前追根因，最后很容易追到这里：

chunk 切得不对
metadata 设计不完整
检索粒度和生成粒度强行绑在一起

也就是说，这一章讨论的不是“怎么把文档切开”这么简单，而是在讲：

系统以后准备按什么知识单位去理解内容
这些知识单位需要补哪些身份和边界信息
检索阶段和生成阶段到底应不应该使用同一种上下文粒度

建议阅读顺序

主题模块

学完这一章后，你应该建立的判断

文档切块不是导入前的机械步骤，而是在定义系统以后按什么粒度理解知识
chunk 大小没有统一答案，关键看问题粒度、文档结构和后续链路
metadata 不是附加字段，而是检索、过滤、排序、引用和治理真正依赖的边界信息
“检索最适合的块”和“生成最适合的块”不一定是同一种块

如果这些判断没有建立，后面即使开始做 embedding、索引、混合检索和重排，也很容易在最前面的粒度定义上反复返工。

阅读这一章时，建议一直带着 4 个问题

当前系统到底是在按什么知识粒度做相关性判断？
这个粒度如果不对，后面的召回和回答通常都会一起偏。
一个 chunk 除了文本本身，还需要哪些 metadata 才算真正可用？
如果这层没补齐，很多边界能力后面都做不稳。
当前问题更像是 chunk 太大、太小，还是边界切错？
这是很多检索问题最值得先判断的地方。
检索阶段和生成阶段，是不是已经该拆成两种不同的上下文设计？
这往往决定系统后面还能不能继续往上优化。

关联章节

这一章会直接影响第 5 章 Embedding、BM25 与混合检索的检索效果。
也和第 10 章 RAG 调优方法论中的大量优化问题直接相关。