RAG 检索增强生成：原理、流程与生产选型
RAG 四步流水线（索引/检索/重排/生成）拆解；分块策略对比表；向量数据库 2026 选型矩阵（pgvector/Qdrant/Milvus/Pinecone）；RAG vs Fine-Tuning 决策框架（70% 企业 RAG 起步）；Rerank 必要性判断表；三大生产故障点。
一、RAG 是什么，解决什么问题
大型语言模型（LLM）在生成回答时，依赖的是预训练阶段学到的参数化知识。这类知识有两个固有短板：一是时效性有限——模型发布后截止的训练数据无法覆盖后续发生的事件；二是私有领域知识缺失——企业内部文档、个人笔记、行业特定规范等内容从未参与预训练，模型没有也不会编造具体的参数化记忆。
RAG（Retrieval-Augmented Generation，检索增强生成）的核心思路是：在 生成之前，先从外部知识库中检索与当前查询相关的文档片段，将查到的内容作为上下文拼入 Prompt，让模型"看着材料回答"而非"凭记忆回答"。这一架构不改变模型参数，只在每次查询时动态注入参考资料。
典型的 RAG 适用场景：企业知识库问答、法律/医疗/金融文档检索、客服工单系统、代码库语义搜索、个人笔记助理。凡是"模型不知道但文档里有"的场景，RAG 都是首选方案。
二、四步流水线：索引 → 检索 → 重排 → 生成
生产 RAG 系统的核心是四步流水线，每步都有独立选型空间，也是最容易踩坑的三处所在。
第 1 步：索引（Index）
将原始文档（PDF、Markdown、网页、数据库记录）切分为文档块（chunk），对每个块计算 embedding 向量，存入向量数据库。这是 RAG 系统的基础设施层，决定后续所有检索质量的上限。
第 2 步：检索（Retrieve）
将用户查询向量化，在向量数据库中做相似度搜索（通常为余弦相似度或内积距离），返回最相关的 top-N 个文档块。这一步的精度直接决定回答质量——检索错了，生成再好也没用。
第 3 步：重排（Rerank，可选）
针对检索召回的 top-N 结果（通常是 10-20 条），用交叉编码器（Cross-Encoder）将查询和每个文档块联合编码，计算更精细的相关性分数，再精选出 top-K（通常 3-5 条）送给生成模型。这一阶段专为"召回多、精选少"的场景设计，可以显著提升最终答案准确度，代价是多一次模型调用、增加 50-300ms 延迟。
第 4 步：生成（Generate）
将重排后的高相关文档块拼入 Prompt 的 context 字段，由 LLM 生成最终回答。系统 Prompt 中通常要求模型"仅基于提供的上下文回答，若信息不足则说明"，以抑制模型在资料缺失时编造（幻觉）的倾向。
数据来源：OpenRouter RAG 管道文档（2026）；aws.amazon.com RAG 解释；wikipedia RAG 条目（2026 年 5 月更新）。
三、分块策略：最容易被忽视的选型
分块（chunking）是 RAG 系统中投入产出比最高的参数——不同分块策略对检索召回率的影响可达 20-40%，但多数初版系统直接用"固定 512 token + 50 重叠"了事，没有针对文档类型调优。
| 分块策略 | 适用场景 | 优点 | 缺点 |
|---|---|---|---|
| 按章节/标题切分 | 结构化文档（技术手册、API 文档） | 语义完整，每块自洽 | 块大小不均匀，超长章节需二次拆分 |
| 固定大小 + 重叠 | 非结构化长文（论文、报告） | 实现简单，块大小均匀 | 重叠区浪费空间；跨边界截断丢失上下文 |
| 按语义边界切分 | 混合文本（博客、混合格式） | 尊重自然语义边界 | 需要 NLP 预处理；边界检测不准时块质量更差 |
2026 年社区的主流实践是"固定大小 + 语义边界"混合：先用标题、段落分隔符建立粗边界，再在粗边界内按 300-500 token 切分，重叠 50-80 token。这个组合在 MTEB（Massive Text Embedding Benchmark）上召回率最优，且工程复杂度可控。
关键原则：索引和查询必须使用同一个 embedding 模型——不同维度的向量空间不可比，混用模型会导致相似度分数分布异常，检索结果随机化。
四、向量数据库选型：2026 年的格局
向量数据库是 RAG 系统的存储层，负责存储 embedding 向量并支持高维相似性搜索。2026 年主流选择分布：
| 数据库 | 定位 | 适用规模 | 特点 |
|---|---|---|---|
| pgvector（PostgreSQL 扩展） | 轻量级，嵌入已有 PG 环境 | < 1000 万向量 | 无需独立服务；索引性能 HNSW；已有运维可复用 |
| Qdrant | 高性能专用向量库 | 100 万-10 亿 | Rust 实现；过滤能力强；文档稀疏状态有序 |
| ChromaDB | 轻量原型级 | < 100 万向量 | Python 原生；嵌入式；生产不推荐（单节点） |
| Pinecone | 全托管 SaaS | 百万-百亿 | 免运维；按调用量计费；数据托管在第三方 |
| Milvus | 分布式企业级 | 10 亿+ | Go 核心；支持 GPU 加速；金融/大厂常用 |
选型决策依据
- 规模 < 10 万向量：pgvector 或 ChromaDB 起步零成本；
- 10 万-100 万：Qdrant 单节点，性能与运维平衡佳；
- 100 万-1 亿：Qdrant 集群或 Milvus 单机；
- 1 亿+：Milvus 集群；若有数据合规要求，选自建。
RAGFlow（开源企业级 RAG 系统）在 2026 年的生产案例中，4 核 8G 内存即可支撑约 50 万文档块的中等规模 RAG 流水线（含 Embedding + Rerank + 生成三部曲），硬件门槛比 2024 年显著降低。
数据来源：openrouter.ai 管道指南（2026）；RAGFlow 企业级部署文档（4 核 8G 最低配置，2026）；pgvector 官方文档（性能基准）；Zilliz Milvus 选型指南。
五、RAG vs Fine-Tuning：2026 年的选型决策
这是每个接入企业知识的团队都要面对的第一个架构决策。两条路线的本质区别是：
| 维度 | RAG | Fine-Tuning |
|---|---|---|
| 解决什么问题 | 知识更新（外部数据、私有知识） | 风格/格式/行为（领域专用表达） |
| 单次成本 | $0.01-0.05/查询 | $50-5,000+（一次性） |
| 更新频率 | 立即（向量化新文档后即时生效） | 需要重新训练（小时到天级） |
| GPU 需求 | 无（推理阶段只需 LLM 推理端点） | 需要 GPU 训练资源 |
| 知识时效 | 保持最新（文档更新即索引） | 冻结在训练数据时点 |
| 鲁棒性 | 检索错了回答就错了，需 Rerank 辅助 | 精度稳定，但知识先天缺失 |
关键判断：
- 选 RAG：需要基于动态/专有数据回答；文档变化频繁；预算有限；需要快速迭代；
- 选 Fine-Tuning：需要固定输出格式（JSON schema、固定模板）；领域专用术语精确；延迟极低（无法容忍额外检索步骤）；
- 组合使用（2026 年生产标准）：Fine-Tuned 基础模型 + RAG 动态知识注入。先微调让模型学会领域语言和格式，再用 RAG 注入实时数据。这是 Java 企业、医疗 AI、金融风控等场景的标准架构。
成本梗概：印度市场 2026 年数据，70% 企业 LLM 部署选择 RAG 起步，驱动力是 RAG 单次查询成本 $0.01-0.05 vs Fine-Tuning 单次训练 $50-5,000+；对于查询量超过 10 万次/月的场景，RAG 的 TCO（总拥有成本）比 Fine-Tuning 低一个数量级。
数据来源：growai.in RAG vs Fine-Tuning 2026 年（印度企业案例）；a16z 调研（经 LinkedIn 转述，2026 年 6 月）（70 个企业 AI 团队，68% 改变了初始架构选择）；enterprisestorageforum RAG 成本对比（2026）。
六、Rerank 的必要性：什么时候该加
Rerank 是流水线中可选但高价值的优化层。加与不加的判断标准：
| 场景 | 是否需要 Rerank | 原因 |
|---|---|---|
| 知识库 > 10,000 个文档块 | ✅ 需要 | Embedding 检索召回噪声大，Rerank 提升 top-3 精度 15-30% |
| 精度敏感（法律/医疗/财务） | ✅ 需要 | 容错率低，多一轮精排值得 200ms 延迟 |
| 召回 20 条精选 top-3 | ✅ 需要 | 候选越多噪声越大，Rerank 角色越重要 |
| 知识库 < 1,000 块 | ❌ 可跳过 | Embedding 已够准确，Rerank 增益不显著 |
| 延迟敏感（< 1 秒响应的对话） | ❌ 可跳过 | 每加一次 Rerank 调用增加 100-300ms |
| 原型/POC 阶段 | ❌ 跳过 | 先跑通 end-to-end，再按精度需求加优化层 |
当前主流 Rerank 模型（交叉编码器）：Cohere Rerank 3、BGE-Reranker-v2（MTEB 多语言可选）。开源场景下 BGE-Reranker-v2（386M 参数）在 4 核 8G 上单条 Rerank 延迟约 80-120ms，20 条 batch 约 1.5-2 秒。
数据来源：openrouter.ai RAG 管道指南（Rerank 应用边界，2026）；BGE-Reranker-v2 官方基准（386M 参数，2026）；Cohere Rerank 3 文档（2026）。
七、生产 RAG 的三处主要故障点
原型跑通后，生产环境最容易出问题的三个地方：
1. 检索质量衰减（最常见）
症状：知识库存量增长后，回答准确率逐渐下降。根因：文档块增多后，embedding 空间中语义相近的"干扰块"增多，余弦相似度分数分布扁平化，top-5 中真正相关的块占比从 80% 降到 40%。解法：加 Rerank 层；或按元数据（文档类型/时间范围）做检索前过滤，缩小搜索空间。
2. 文档更新后向量库残留
症状：文档已修改/删除，但系统仍回答旧版本内容。根因：索引时未记录文档 hash 或版本号，更新时只追加新向量而不删除旧向量。解法：每个 chunk 记录源文档 ID + 内容 hash；更新时按 ID 先删旧块再写新块；或用向量数据库的 upsert 接口（如 Qdrant 的 upsert by ID）。
3. 跨语言检索召回不足
症状：中文查询检索不到英文文档（或反之）。根因：单语言 embedding 模型（如 Ollama 的 nomic-embed、text-embedding-3）跨语言能力有限，中英语向空间不对齐。解法：用多语言 embedding 模型（BGE-M3 / mxbai-embed-large / Ollama multilingual-e5）；或对每篇文档同时生成多语言版本索引。
八、选型速查表
| 决策维度 | < 10 万查询/月 | 10 万-100 万/月 | 100 万+/月 |
|---|---|---|---|
| 向量数据库 | pgvector（已有 PG 环境） | Qdrant 单节点 | Qdrant 集群或 Milvus |
| Embedding 模型 | nomic-embed / bge-small | bge-small / mxbai-embed | bge-m3（多语言）/ mxbai-embed-large |
| Rerank | 不需要 | 可选（延时敏感场景跳过） | 必须 |
| 分块策略 | 固定 500 token + 50 重叠 | 混合（标题切分 + 固定切分） | 语义边界优先（需 NLP 预处理） |
| 硬件 | 4 核 8G（RAGFlow 起步配置） | 8 核 16G 或带 1 张消费级 GPU | 集群（多节点） |
| 成本结构 | API 费用为主（$0.01-0.05/查询） | API + 自建/托管数据库 | 主要为计算 + 存储 |
九、结论
RAG 的核心价值是"让 LLM 基于外部数据说话"——不需要重训模型、不需要 GPU 训练资源、文档更新后即时生效。2026 年的主流生产路径是：轻量 RAG（pgvector + bge-small）起步，按精度需求加 Rerank 层，按规模迁移到专用向量库（Qdrant），按语言需求换多语言 embedding 模型。
与 Fine-Tuning 的边界是清晰的：RAG 解决"模型不知道什么"，Fine-Tuning 解决"模型不会说什么风格"。2026 年的生产实践是两者组合——微调基础模型学会领域语言和格式，用 RAG 注入实时动态数据。
最容易被低估的三件事：①分块策略比向量库选择影响更大；②检索错了则生成再好也失败——Rerank 是召回质量的底线；③文档更新时向量库残留是生产 RAG 最常见的静默故障，索引时必须记录文档版本 ID。