Appearance
4.2 索引构建的基本思路
这一节要讨论的，不是“怎么调用某个向量库 API 建索引”，而是更基础也更容易被忽略的问题：
- 为什么索引阶段一定排在清洗和切块之后
- 为什么很多召回问题其实在索引阶段就已经决定了上限
- 为什么索引阶段做错了，后面很难靠 Prompt 补回来
很多初学者会把索引理解成一个很机械的动作：
- 文本切好块
- 跑一下 embedding
- 写进向量数据库
这个流程当然存在，但如果你只把它看成“写入动作”，就会低估索引阶段真正承担的作用。
索引阶段真正做的是：把已经整理好的知识对象，组织成一种后面可被稳定检索、过滤、排序、更新和治理的结构。
所以它既不是简单存储，也不是纯模型问题，而是连接“数据准备”和“检索执行”的中间层。
学这一节时，最值得先建立的判断
- 清洗和切块决定的是“进入索引的对象质量”，索引决定的是“这些对象以后怎么被找回来”
- 索引质量不只是 embedding 质量，而是对象粒度、字段设计、边界信息和写入方式的综合结果
- 很多召回问题看起来发生在查询阶段，根因其实早在索引阶段就埋下了
- Prompt 可以改善表达和约束输出，但不能凭空修复错误召回、脏数据和边界混乱
这一节最想帮你建立的系统视角
如果把 RAG 看成一条链路，那么：
- 清洗阶段决定“数据干不干净”
- 切块阶段决定“知识对象长什么样”
- 索引阶段决定“这些对象以后怎么被组织和找回”
- 检索阶段才是在这个基础上执行查询
也就是说，索引不是后面检索的一部分小实现细节，而是前后两端真正接起来的关键层。
这一节会回答什么问题
读完这一节后，你最好能更稳地判断：
- 什么时候一个数据问题还没准备好进入索引
- 为什么同一批数据，索引组织方式不同会带来完全不同的召回表现
- 哪些问题应该回到索引阶段重做，而不是继续在 Prompt 上硬修