这个系列是重新梳理RAG流程与在每一个流程中的问题与解决，对于具体的技术实现不会写的很细。

上一篇把 RAG 放在了一条更完整的证据链里看：它更像一套让模型回答时能拿到外部证据的工程系统。“向量数据库 + 大模型”只是最小 demo 里的表层形态。

上一篇讲 RAG 的边界时，核心结论是：RAG 适合解决模型回答时缺少外部证据的问题。到了这一篇，问题往前推进一层。

上一篇讲的是文档进入知识库之前的处理。解析、清洗、结构化和 metadata 解决的是资料以什么质量进入系统。

上一篇讲 chunking 时，重点是文档以什么粒度进入索引。chunk 决定了知识块的边界，决定了检索系统后面能找回什么样的证据。

前面几篇已经把离线侧的基础拆开了：原始文档要经过解析、清洗、结构化和 metadata 标注，随后按合适的粒度切成 chunk，再通过 embedding 和向量索引进入可检索状态。到这里，知识库具备了被系统调用的基础。

上一篇把一次在线 RAG 请求从用户问题进入系统，到最终答案返回完整串了一遍。放在整条链路里看，检索层承担的是一个很朴素但很关键的职责：让正确证据进入候选池。

上一篇讲检索增强时，重点放在 Query Rewrite、Hybrid Search 和多路召回。它们共同解决的是证据入口问题：让正确证据尽量进入候选池。

上一篇讲 Rerank 与上下文工程时，重点放在候选证据如何进入 Prompt。检索把材料找回来，Rerank 判断证据优先级，上下文工程把证据整理成模型可以使用的形态。到了这一篇，问题继续往后推进：即使模型已经拿到了外部知识，RAG 仍然可能产生幻觉。

上一篇讲幻觉治理时，重点放在引用、拒答、证据约束和答案后校验。治理手段设计出来以后，还会遇到一个更现实的问题：怎么证明系统真的变好了。

上一篇讲 RAG 评测体系时，重点是如何证明系统变好了。评测解决的是“当前效果是否可靠”，这一篇继续往生产系统推进：知识库本身会不断变化。

前面十篇基本把普通 RAG 的工程链路拆完了。从文档处理、chunking、embedding、向量检索，到 Query Rewrite、Hybrid Search、Rerank、上下文工程、幻觉治理、评测体系，再到知识库动态更新、权限、版本和回滚，这些内容组成了一套相对完整的生产级 RAG 视角。