1. RAG 为什么要拆成两条链路

上一篇我们把 RAG 概括成了“先查资料，再回答”。这个概括没有问题，但真正开始实现时，还需要把时间关系考虑进去：资料什么时候处理，用户的问题什么时候到达？

以公司员工手册问答助手为例。员工手册不会随着每一次提问重新读取。管理员可能在晚上上传新版本，由后台任务负责解析文件、切块、生成向量并写入索引；第二天员工提问时，在线服务只需要在已经准备好的索引中查找资料。

如果每次提问都从 PDF 开始处理，系统不仅会变慢，还会反复消耗 Embedding 和生成模型的调用额度。于是，RAG 通常会被拆成两条相对独立的链路：索引链路负责把原始资料整理成可检索的数据，查询链路负责在用户提问时找出相关资料，再生成答案。

换个角度看，索引链路回答的是“知识库里应该保存什么”，查询链路回答的是“这一次问题应该取出什么”。两条链路分工明确，系统才不需要把后台处理和在线问答挤在同一个请求里。