三种范式是什么
RAG 综述把系统演进归纳为三种范式：Naive RAG 让检索结果直接拼进提示词，Advanced RAG 在检索前后加入优化环节，Modular RAG 把各环节拆成可插拔模块并引入路由、记忆与工具。它们不是软件版本号，而是复杂度递增的设计思路，用来对照自己的系统在哪一档、下一步该补什么。
基本信息
| 来源 | Gao et al., RAG for LLMs: A Survey（arXiv:2312.10997） |
|---|
| 划分依据 | 检索前后是否存在优化环节、组件是否可替换 |
|---|
| 典型阶段 | 原型期用 Naive，成长期进 Advanced，平台化走向 Modular |
|---|
| 判断方法 | 看短板出在数据侧、检索侧还是编排侧 |
|---|
范式对比
| 范式 | 结构 | 典型改进 |
|---|
| Naive RAG | 检索 → 拼接 → 生成 | 只有基础向量召回，常见问题：召回差、内容重复、格式混乱 |
| Advanced RAG | 检索前 + 检索后优化 | 查询改写、混合检索、重排、上下文压缩 |
| Modular RAG | 模块化编排 | 检索、记忆、路由、预测等模块组合，可引入工具与多跳检索 |
各范式的典型短板
- Naive：只按相似度取 top-k，专有名词问题命中差，切片重叠导致上下文重复
- Naive：没有拒答策略，检索为空时模型照样编出一段答案
- Advanced：加了多个环节却没建评测基线，无法证明改动是否真的有效
- Advanced：检索前后都优化，但解析与切分问题被放过，仍在上限很低的地基上改进
- Modular：模块多、链路长，一次请求的成本与延迟难以预测，需要编排层做超时与降级
组件归属
| 组件 | 属于哪一段 | 解决什么问题 |
|---|
| 查询改写 / Multi-Query | 检索前 | 问题表述与文档不一致 |
| 混合检索 | 召回层 | 语义近似与精确匹配各有盲区 |
| 重排 | 检索后 | 候选排序不反映真实相关性 |
| 上下文压缩 | 检索后 | 上下文超预算、噪声过多 |
| 路由与多跳 | 编排层 | 不同问题需要不同知识源或多次检索 |
先用 Naive 流程跑通端到端并建立评测基线，再按测出的短板逐项引入 Advanced 组件；没有基线时新增组件只是增加不确定性。
