摘要：大模型有两个致命弱点：知识截止日期（不知道最新信息）和幻觉（编造答案）。RAG（检索增强生成）是目前解决这些问题最有效的方案——它让模型在回答问题时先检索相关文档，再基于文档内容作答。2026 年，90% 以上的 LLM 应用都采用了 RAG 架构。这篇文章从原理到进阶，一次性讲透。

---

一、为什么需要 RAG？

大模型的两大硬伤

2026 年的大模型已经非常强大，但它们有两个与生俱来的局限：

硬伤 1：知识是"冷冻"的

模型训练完成后，它的知识就定格在训练数据的截止日期。GPT-4 不知道昨天发生的新闻，Claude 不知道你公司的内部文档——除非你告诉它。

硬伤 2：模型会"编造"

当模型不知道答案时，它不会说"我不知道"，而是会自信地编造一个听起来合理的答案。这就是幻觉（Hallucination）问题。

三种解决方案对比

方案	思路	优点	缺点
重新训练	把新数据混入训练集，重新训练模型	知识内化，最彻底	成本极高（百万级），不可能频繁做
微调（Fine-tuning）	用新数据对模型做增量训练	比重新训练便宜	仍需要大量数据和算力，且可能"灾难性遗忘"
RAG（检索增强生成）	不改变模型，在提问时检索相关文档注入上下文	零训练成本，实时更新，可解释性强	依赖检索质量

RAG 的核心优势：不需要重新训练模型，不需要大量算力，只需要把你的文档塞进一个向量数据库，模型就能"实时学习"最新信息。

---

二、RAG 的工作原理：开卷考试的比喻

如果你把大模型想象成一个学生，那么：

• 传统问答（闭卷考试）：学生凭记忆作答。如果学过而且记住了，答得好；如果没学过，就瞎编。
• RAG（开卷考试）：给学生一份参考资料，让他边查边答。不需要记住所有内容，但需要会查、会用。

具体流程

用户提问："公司去年的营收是多少？"
        │
        ▼
┌─────────────────────────────┐
│  步骤 1：检索                │
│  把问题转换成"向量"           │
│  在知识库中搜索最相关的文档    │
│  → 找到"2025年度财报.pdf"    │
└─────────────────────────────┘
        │
        ▼
┌─────────────────────────────┐
│  步骤 2：增强                │
│  把检索到的文档 + 原始问题    │
│  组合成一个完整的提示词       │
│  → "基于以下财报内容回答...  │
│     2025年营收为3.2亿元..."  │
└─────────────────────────────┘
        │
        ▼
┌─────────────────────────────┐
│  步骤 3：生成                │
│  大模型基于增强后的提示      │
│  生成最终答案               │
│  → "公司去年营收3.2亿元..." │
└─────────────────────────────┘
        │
        ▼
      输出答案（附带引用来源）

---

三、基础 RAG 的核心组件

一个基础 RAG 系统由三个关键组件构成：

组件 1：向量化（Embedding）

计算机不理解"文字"，只理解"数字"。向量化就是把文档转换成数字数组（向量）的过程。

"公司去年营收3.2亿元"  →  [0.231, -0.145, 0.678, ..., 0.032]  ← 768维向量

关键是：语义相似的文本，它们的向量在空间中的距离也近。

• "营收"和"收入"的向量距离很近
• "营收"和"天气"的向量距离很远

组件 2：向量数据库

把所有文档向量化后，存储到一个专门的数据库中——这就是向量数据库。

常见的向量数据库：

数据库	特点	适用场景
FAISS（Facebook）	内存型，速度极快	小规模（百万级以下），单机
Chroma	轻量级，Python 原生	学习和原型验证
Milvus	分布式，支持百亿级	生产环境，大规模
Qdrant	Rust 实现，高性能	生产环境
Pgvector	PostgreSQL 插件	已有 PostgreSQL 的场景

组件 3：检索 + 生成

检索：用户提问时，先把问题转换成向量，然后在向量数据库中搜索最相似的 Top-K 个文档。

生成：把检索到的文档 + 原始问题组装成提示词，交给大模型生成最终答案。

提示词模板：

"请基于以下参考资料回答问题。
如果参考资料中没有相关信息，请明确说'不知道'。

参考资料：
[文档1] 公司2025年年度财报：营收3.2亿元...
[文档2] 公司2025年利润表：净利润0.8亿元...

问题：公司去年的营收是多少？

答案："

这里有一个关键设计：明确告诉模型"不知道就说不知道"——这是减少幻觉的重要手段。

---

四、从基础到进阶：RAG 的常见问题与优化

基础 RAG 能解决 80% 的需求，但剩下的 20% 需要进阶技术。

问题 1：检索不准确

症状：检索到的文档和问题不相关，导致答案错误。

解决方案：混合检索（Hybrid Search）

纯向量检索擅长理解"语义"，但不擅长处理"精确关键词"。比如搜"2025年第3季度"这样的精确时间——向量可能匹配到"2024年第3季度"，因为语义相似。

混合检索 = 向量检索 + 关键词检索（BM25）

用户搜："2025年Q3营收"

向量检索结果：
  1. "2025年各季度营收分析"（语义相关）  得分 0.85
  2. "2024年Q3营收报告"（语义相近）      得分 0.82 ← 其实是错的

BM25关键词检索结果：
  1. "2025年Q3营收简报"（精确匹配）      得分 9.5
  2. "2025年Q2营收简报"                 得分 7.2

混合：加权合并两种结果 → 精确匹配 + 语义理解

问题 2：检索结果太多，质量不一

症状：搜到 50 篇相关文档，但只有 3 篇真正有用。

解决方案：重排序（Reranking）

先粗筛（向量检索取 Top-50），再用更精细的模型精排（Reranker 取 Top-5）。

第一步：向量检索（快，但不够精确）
    知识库（100万文档） → 粗筛 → Top-50

第二步：Cross-Encoder 重排序（慢，但非常精确）
    Top-50 逐对与问题计算相关性 → 精排 → Top-5

第三步：用 Top-5 文档生成答案

Cross-Encoder 比向量检索更精确，因为它同时"看到"问题和文档的内容，而不是只比较向量距离。

问题 3：用户提问的措辞和文档不一致

症状：用户问"去年的利润怎么样"，但文档中用的是"净利润率"。

解决方案：查询改写（Query Rewriting）

先用 LLM 把用户的问题改写成更适合检索的形式：

用户原问："去年的利润怎么样？"

改写后：
  1. "2025年净利润数据"
  2. "2025年利润率变化"
  3. "2025年盈利能力分析"

→ 用 3 个改写后的问题分别检索，合并结果

---

五、RAG 的变体与演进

5.1 Agentic RAG（2025-2026 年主流）

基础 RAG 只有"检索→生成"一步。Agentic RAG 让模型可以多次检索、逐步推理：

用户问："对比我们和竞争对手的产品"

Agent RAG：
  1. 检索自家产品文档 → 提取关键特性
  2. 检索竞争对手文档 → 提取关键特性
  3. 调用搜索工具 → 查最新市场评论
  4. 综合所有信息 → 生成对比分析报告

这里的"Agent"意味着模型可以自主决定什么时候检索、检索什么、检索几次。

5.2 多模态 RAG

不仅检索文本，还能检索图像、表格、视频：

用户问："去年哪个季度的增长最快？"

多模态 RAG：
  1. 检索文本描述 → "Q3增长15%"
  2. 检索图表 → 季度增长趋势图
  3. 检索表格 → 各季度具体数据

答案 = 文字解释 + 趋势图 + 数据表

5.3 Graph RAG（图谱增强检索）

微软提出的进阶方案：在检索时利用知识图谱的结构化关系，而不只是向量相似度。

传统 RAG：    查"苹果" → 搜到"苹果公司"和"苹果水果"
Graph RAG：   查"苹果" → 通过图谱关系知道用户问的是科技领域
             → 只返回"苹果公司"相关内容

---

六、一个完整的 RAG 系统架构

用户提问
    │
    ▼
┌──────────────┐    ┌──────────────────────┐
│  查询处理     │───→│  查询改写（可选）     │
│  意图识别     │    │  生成多个检索版本     │
└──────────────┘    └──────────┬───────────┘
                              │
                              ▼
                    ┌──────────────────────┐
                    │      检索引擎         │
                    │  ┌─────┐  ┌───────┐  │
                    │  │向量 │  │ BM25  │  │
                    │  │检索 │  │关键词 │  │
                    │  └──┬──┘  └───┬───┘  │
                    │     └────┬────┘      │
                    │      混合合并         │
                    └──────────┬───────────┘
                              │
                              ▼
                    ┌──────────────────────┐
                    │   重排序 (Reranker)   │
                    │   Cross-Encoder 精排  │
                    └──────────┬───────────┘
                              │
                              ▼
                    ┌──────────────────────┐
                    │       LLM 生成        │
                    │   基于检索文档作答     │
                    └──────────┬───────────┘
                              │
                              ▼
                   答案 + 来源引用

---

七、实践建议：从零搭建 RAG

第一步：从小开始

不要一开始就追求大规模。用 Python + Chroma（向量数据库）+ 一个小型 LLM（如 Qwen3-0.6B），几百行代码就能搭建一个可用的 RAG 系统。

第二步：先评估检索质量

RAG 系统的瓶颈通常是检索，而不是生成。先用一个简单的测试集评估：

测试问题集 → 检索 → 人工判断检索结果是否相关 → 调整检索策略

检索质量达标后，再去优化生成质量。

第三步：逐步加入进阶技术

基础 RAG（向量检索） → 加入 BM25 混合 → 加入重排序 → 加入查询改写 → Agentic RAG

不需要一步到位，在每一步评估效果，只在带来显著提升时才加入。

工具推荐

阶段	推荐工具	说明
学习原型	Chroma + LangChain + 本地模型	快速验证，免费
生产环境	Milvus/Qdrant + LlamaIndex	大规模、高并发
托管服务	Pinecone + 云端 LLM API	无需运维

---

八、总结

RAG 不是一项"可选"的技术——在 2026 年，它是 LLM 应用开发的标配。

你需要记住的关键点	一句话
为什么用 RAG	解决知识截止和幻觉问题，零训练成本
核心流程	检索 → 增强 → 生成（开卷考试）
关键组件	向量化 + 向量数据库 + LLM
进阶方向	混合检索 → 重排序 → 查询改写 → Agentic RAG
最大陷阱	检索质量是瓶颈，先优化检索再优化生成

如果你正在开发一个基于 LLM 的应用，问自己一个问题："我的模型是闭卷考试还是开卷考试？"

如果是闭卷，试试 RAG——这可能是最简单的提升准确率的方法。