RAG如何把检索与生成分开协作

RAG 的架构价值，本质上来自一次有意的解耦：把"知识的获取"交给检索器，把"语言的组织"交给生成模型，两者仅通过一段结构化的证据上下文完成协作。这种分工并非工程上的权宜之计，而是对两类任务本质差异的承认——检索是判别问题，追求召回的精确；生成是表达问题，追求语义的连贯。混在一起的系统无法分别优化，拆开之后每一侧才有独立的改进空间。

检索侧：独立评估的判别模块

检索器的职责是把语料切分为粒度适当的段落，经向量化后建立索引，在查询到来时完成最近邻匹配，工程上通常取 3～5 条候选段落作为证据集合，开源方案如 FAISS、Milvus 均可承担这一层。关键在于，检索质量只由召回相关性决定，与下游模型完全无关，因此可以独立评估、独立调优：段落切分长度、索引结构、返回条数，都属于检索侧自己的参数空间。

生成侧：受约束的条件生成

生成模型接收的并非裸问题，而是"问题 + 证据 + 指令"组成的提示词。指令通常要求模型基于给定证据作答并标注来源编号，这实质上是把开放式生成转化为受约束的条件生成：模型的自由度被证据边界所限制，幻觉空间随之压缩。生成侧的核心调参点是提示词设计与证据注入方式，同样不依赖检索侧的内部实现。

两侧之间的接口只有一处，即证据上下文。正因为接口窄而清晰，知识库更新时只需重建索引，无需重训模型；回答出错时也能快速定位责任方——检索不准就查召回，证据相关但回答失真就查提示词与模型行为。排障路径的清晰，正是解耦架构在工程上的直接红利。

对实践者而言，理解这一分工的意义在于：不要用单一指标同时考核两个环节，更不要拿生成侧的错误去惩罚检索侧。先把检索调准，再让生成学会"照证据说话"，两个目标分开达成、分别验收，系统才具备可持续迭代的基础。