RAG（Retrieval Augmented Generation，检索增强生成），本质是用检索的方式，把外部数据增强到 LLM 的生成能力中。说白了：LLM 记不住的东西，让它去查。
一、RAG 解决了什么问题
LLM 的知识边界在训练那一刻就固定了。让它回答私有数据（你公司的内部文档）或实时信息（今天的股价），它做不到——除非你给材料让它"看着答"。
RAG 就是做这件事的：
用户提问 → 从知识库检索相关文档 → 文档+问题一起喂给 LLM → LLM 基于材料生成回答
和 Fine-tuning 的区别：
| 修改什么 | 模型参数 | 不修改，只改输入内容 |
| 成本 | 高（训练算力） | 低（检索即可） |
| 更新频率 | 慢（重新训练） | 快（换文档即可） |
| 适合场景 | 模型学知识 | 模型查知识 |
二、RAG 完整流程
标准的 RAG 管道有 6 步：
用户输入 → 重写(Rewriting) → 检索(Retrieval) → 融合排序 → 重排序(Reranking) → LLM 生成
1. 查询重写
用户表达往往不精准（“那个啥怎么弄”），直接检索效果差。需要先重写：
- HyDE（假设性文档嵌入）：让 LLM 先生成一个假设答案，用假答案的向量去搜索，因为假答案和真答案在向量空间中更接近
- 查询扩展：把简短的查询扩展为更完整的描述
- 指代消解：多轮对话中把"他""刚才说的那个"替换成真实实体
2. 检索方式
关键字检索（BM25）：基于词频和逆文档频率计算相关性。简单高效，但只匹配字面关键词（搜"手机"找不到"iPhone"）。
语义检索（向量检索）：文档和查询都转为向量，通过余弦相似度搜索。能理解语义相关性（搜"篮球"能找到"NBA"）。
常用向量数据库：
| Chroma | 开源免费、轻量、Python 原生 | 原型开发、个人项目 |
| PostgreSQL+pgvector | 基于已有 PG 基础设施，无需额外运维 | 已有 PG 的团队 |
| Pinecone | 全托管、开箱即用、付费 | 生产环境、不想运维 |
| Milvus | 开源、支持 RRF 融合排序、高性能 | 大规模生产、自建 |
| Weaviate | 原生支持混合检索 | 需要混合检索的场景 |
选择建议：原型用 Chroma，小团队用 PG+pgvector，大规模生产用 Milvus 或托管服务。
混合检索（Hybrid Search）：关键字 + 语义检索结果融合。使用 RRF（倒数排名融合） 算法——不需要归一化不同检索的分数，直接基于排名融合。公式：RRF_score(d) = Σ 1/(k + rank_r(d))，k 通常取 60。
混合检索的关键价值：关键字检索保证精确命中（比如搜产品编号），语义检索兜底同义词和近义表达，两者互补几乎覆盖所有查询类型。
3. 重排序
检索阶段用 Bi-Encoder（双塔编码器）快速粗筛——把查询和文档分别编码为向量，计算速度快，可以从百万文档中召回 Top-100。Reranking 阶段用 Cross-Encoder（交叉编码器）精排 Top-K——把查询和文档一起输入 Transformer，通过注意力机制联合编码，精度更高但速度慢。
两步分工的价值：快筛→细排，兼顾召回率和精度。如果不做分步，直接在百万级文档上用 Cross-Encoder 做精排，延迟完全不可接受。
典型效果：Cross-Encoder Reranking 可以使 NDCG@10 提升 5-15 个百分点，延迟增加约 200ms。主流 Reranker 有 Cohere Rerank、BGE Reranker、Jina Reranker。
三、Chunking（文档分块）的工程实践
RAG 中一个经常被低估的环节是文档分块策略。分块大小直接影响检索质量：
- 分块太小：语义不完整，检索到的片段缺乏上下文
- 分块太大：包含太多无关信息，降低检索精度
常见策略：
实践中推荐：Markdown/标题结构清晰的文档按章节分块；纯文本用递归分块 + 小幅度重叠。
四、RAG 为什么"不再是必选项"
2026 年的趋势是 Agent 开发不再强调 RAG。这个结论来自三个观察：
但 RAG 会在 2B 企业场景回归 —— 企业有海量文档（百万级）、数据合规要求、权限控制需求。在这些场景下，RAG 的精确检索和权限控制不可替代。
一个重要的判断标准：当你的 Agent 需要的"知识"是操作流程时用 Skill，是事实性数据时用 RAG。
五、RAG 的四大应用场景
这四类场景的共同特征：数据量大、需要精确检索、信息频繁更新。这正是 RAG 的强项。
