AI 热门概念手册

外观

检索增强生成（RAG）

本页速览 RAG 是让大模型先检索外部知识、再基于检索结果作答的架构。本文拆解离线索引与在线检索全流程，梳理变体谱系，对比微调与长上下文，并给出落地经验与血泪教训。

本页含时效性内容，数据截止于 2025-06；JD、榜单、产品功能等信息可能已变化，引用前请核对原始出处。

检索增强生成（RAG） ​

概念定义：给大模型开一本"可以翻的书" ​

**检索增强生成（Retrieval-Augmented Generation, RAG）**是一种先检索外部知识、再让大语言模型（LLM）基于检索结果生成回答的架构——把模型从"背课文"变成"开卷考试"。

想象你让一个知识渊博但信息停在去年的顾问回答公司最新政策问题：他要么瞎编、要么说"我不知道"。RAG 的做法是——先递给他一本实时更新的手册，限定他"只依据手册回答，手册里没有就直说不知道"。这就是 RAG 的全部精神。

它之所以成为 2023 年以来最流行的大模型应用范式，是因为不训练、不改参数、只靠"检索 + 拼装提示词"就能把 LLM 从"通才"变成某个领域的"可信专家"。客服机器人、企业知识库问答、AI 搜索、法律与医疗辅助都重度依赖它。截至 2025 年，几乎所有主流大模型产品都内置了某种形式的检索能力。本文先讲清它解决什么问题，再拆解架构、梳理变体、对比替代方案，最后给出落地时最容易踩的坑。概念全景与模型演进脉络可先看什么是 AI 热门概念与大语言模型（LLM）。

一、为什么需要 RAG：LLM 的三大先天缺陷 ​

大语言模型本质是一个参数化的概率分布——它把训练语料"压"进千亿参数里。这个机制带来三个无法回避的短板：

缺陷表现后果
幻觉（Hallucination）对不知道的事一本正经地编造，措辞越自信越难分辨事实性错误，企业场景不可用
知识截止（Knowledge Cutoff）训练数据有截至日期，之后的世界一无所知问最新政策、今日事件必出错
私有数据不可见训练语料不含企业内部文档、个人资料公司知识库、专属数据一问三不知

幻觉的根源在于：模型在生成时没有"查阅"能力，只能依赖参数里的记忆，而记忆本身是模糊的统计规律而非可靠事实。关于幻觉机制的深入分析见大语言模型（LLM）。

RAG 正是针对这三个缺陷的架构级解法，它的价值可归纳为三条：

  1. 可溯源（Grounding）：回答建立在检索到的具体文本之上，可以附带引用来源；用户能验证，错误能被追责。
  2. 可更新（Fresh）：知识更新 = 替换索引里的文档，不用重新训练模型。今天换文档，明天回答就变新。
  3. 可控制成本（Cheap）：不训练、不调参，只在推理时增加一次检索；相比反复微调，边际成本极低，尤其适合"知识频繁变化但模型能力够用"的场景。

一句话判断：模型"能力不够"时该考虑换模型或微调；模型"知道得不够新、不够全、不够私密"时，优先 RAG。

二、架构拆解：三段式流水线 ​

RAG 是一条清晰的流水线，分为离线索引、在线检索、生成三段。整体架构如下：

┌─────────── 离线索引（一次性构建，文档更新时重跑）───────────┐
│  原始文档 → 清洗 → 切分 chunk → Embedding 向量化 → 写入向量库  │
└──────────────────────────────────────────────────────┘
                          │（问答时复用）
┌─────────── 在线检索（每次问答执行）──────────────────┐
│  用户问题 → Query Embedding → 向量召回(recall)        │
│                        → 重排序(rerank) → 混合检索   │
└──────────────────────────────────────────────────────┘
                          │（top-k 相关片段）
┌─────────── 生成 ─────────────────────────────────┐
│  检索片段 + 用户问题 → 拼装 Prompt → LLM 生成回答（带引用）│
└──────────────────────────────────────────────────────┘

完整实现见从零搭建 RAG 应用，这里逐段拆解原理与陷阱。

1. 离线索引：先把知识"榨成汁"存起来 ​

离线阶段把原始文档变成可检索的向量索引，三个关键步骤：

第一步：文档切分（Chunking）。 把长文档切成大小适中的"知识块"，这是决定 RAG 成败的第一因，却常被草率处理。

  • 常见策略：按固定字符数切、按段落/标题切、按语义边界切（如 sentence splitter）、按 token 上限切；
  • 核心矛盾：chunk 太小 → 上下文丢失、检索碎片化；chunk 太大 → 向量语义被稀释、混入无关信息、浪费 LLM 上下文窗口；
  • 常见陷阱：表格被从中间切断、代码块被截断、跨 chunk 的语义被破坏、专业术语被拆散。

chunking 的三条经验

  1. 先按文档结构切，再按大小切：Markdown 标题、PDF 章节是天然的语义边界；
  2. chunk 尺寸从 200~500 token 起步，用真实问题做实验，不要拍脑袋；
  3. 同一文档类型统一切法：PDF、网页、代码库各有最佳实践，混合文档要分别处理。

第二步：Embedding 向量化。 用 embedding 模型把每个 chunk 映射成稠密向量（如 1536/1024 维），语义相近的文本向量距离近。这一步是向量数据库与语义检索的地基。

python
# 伪代码：离线索引流程
from embeddings import EmbeddingModel
from vector_db import VectorStore

docs = load_documents()                    # 1. 读入文档
chunks = split_by_structure(docs, size=300) # 2. 按结构切分，目标约 300 token
vectors = [EmbeddingModel.embed(c) for c in chunks]
store = VectorStore(dimension=1024)
store.upsert(ids, vectors, metadata=chunks) # 3. 连同元数据写入向量库

第三步：记录元数据（Metadata）。 每个 chunk 必须携带来源、标题、时间戳、权限标签等元数据。它们的作用超出多数人预期：用于事后过滤（filter）、用于回答时标注引用、用于按权限裁剪检索范围。没有元数据的 RAG，等于"有知识但不知道知识从哪来、能不能用"。

2. 在线检索：从"大海"里捞出最相关的几块拼图 ​

检索质量决定回答质量的上限——检索不到正确答案，LLM 再聪明也白搭。在线检索通常叠加三层手段：

  • 向量检索（semantic search）：把用户问题 embedding 化后，在向量库中做最近邻（ANN）搜索，取 top-50。擅长处理"语义相近但字面不同"的查询；
  • 重排序（Rerank）：用 cross-encoder 模型对 top-50 逐一打分重排，取 top-5。向量检索是"初筛"，重排是"精排"，这是提升 RAG 准确率性价比最高的一步，但注意它增加一次模型推理、提升延迟；
  • 混合检索（Hybrid Search）：向量检索 + 关键词检索（如 BM25），再用 RRF（Reciprocal Rank Fusion）等算法融合排名。专有名词、型号、编号这类"字面匹配"任务，BM25 往往比向量检索更准——所以两者互补而非互斥。

一句话判断：线上环境先做"向量 + BM25 混合 + 重排"，这是准确率与成本的最佳平衡点；追求极致低延迟时可先砍重排。

3. 生成：把答案"圈定"在检索结果之内 ​

把检索到的 top-k 片段与用户问题拼装成 prompt，交给 LLM。这里的核心纪律是在提示词里显式声明"只依据材料回答"——这正是提示词工程的经典应用。一个可复用的模板：

markdown
你是企业知识库问答助手。
请严格依据下方【参考材料】回答用户问题；
若参考材料中没有答案，请直接回答"知识库中暂无相关信息"，
绝对不要编造。每个结论后用 [来源编号] 标注出处。

【参考材料】
[1] 来源: FAQ/退款流程.md —— 退款一般在 3~5 个工作日原路退回，
    大促期间可能延迟至 7 个工作日。……（此处插入检索片段）
[2] 来源: 售后政策/2025.md —— ……（插入第二个片段）

【问题】
用户申请退款后多久到账？

【回答】

为什么"只依据材料"有效？ 检索结果相当于把模型的注意力"钉"在给定文本上，大幅压缩幻觉空间；配合"不知道就说不知道"的指令，把不确定性问题显式排除。但请注意：这只是一个软约束——模型仍可能超出材料发挥，所以生产系统还要叠加引用标注、来源校验等硬手段（详见常见陷阱与反模式）。

三、RAG 变体谱系：从"裸奔"到"武装到牙齿" ​

RAG 不是单一方案，而是一个快速演化的谱系。按主流综述的分类（详见参考资料），可分为三代：

变体核心思想典型做法适用阶段
Naive RAG（朴素版）切分 → 检索 → 拼 prompt，开箱即用最简三段式验证想法、快速上线
Advanced RAG（进阶版）优化检索前后两端Query 改写/扩展、HyDE、重排、chunk 优化、元数据过滤生产级准确率要求
Modular RAG（模块化）检索各环节可插拔、可编排查询路由、多路召回、记忆模块、检索器融合复杂业务、多数据源
GraphRAG（图谱版）用知识图谱的结构做检索实体/关系检索、社区摘要、全局问答需要跨文档推理、总结型问题
Self-RAG（自检版）让模型自己决定"何时检索、检索什么、采不采纳"按需检索、批判式采纳、带引用输出成本敏感、检索可能伤质量的任务
Agentic RAG（智能体版）让智能体自主规划"何时查、查什么、查几次"多步检索、工具调用、自我纠错、反思复杂多跳问答、流程型任务

几个关键判断：

  • 多数团队卡在 Naive RAG 就上线，然后用更差的检索质量替"RAG 不行"背锅。先把 Advanced RAG 的四板斧（query 改写、重排、chunk 调优、元数据过滤）补齐，再谈别的；
  • GraphRAG 擅长"总结型"任务（如"我们公司各产品线的共同问题是什么"），因为它把知识组织成实体关系网络而非碎片——适合知识图谱既有资产或需要全局视角的场景，见知识图谱与知识注入；
  • Agentic RAG 适合"多跳"问题（"对比 A 和 B 的政策，再给出 C 的影响"），因为它可以检索→判断→再检索，但代价是延迟上升、行为不可完全预测，见AI 智能体（Agent）。
  • Self-RAG 的思路更"按需"：把"要不要检索"也交给模型自己判断（训练时用特殊 token 学习门控），简单问题直接答、复杂问题才检索，并对自己引用的内容做自我批判——省 token 又提精度，但需要专门的微调模型支撑，见前沿进展。

四、RAG vs 微调 vs 长上下文：三方案怎么选 ​

面对"模型不知道某件事"，业界有三种主流解法：RAG、微调、直接塞长上下文。它们不是替代关系，而是不同成本曲线下的不同选择：

维度RAG微调（Fine-tuning）长上下文
知识更新换文档即生效需重新训练/持续更新改 prompt 即可
可溯源强（可附引用）无（知识在参数里）弱（可人工核对）
幻觉风险中低（受检索质量制约）低（但会"记住"错误）中高（关键信息易被淹没）
成本存储 + 检索 + 推理训练 + 推理（成本最高）随上下文长度线性上涨
延迟低~中低中~高（长输入处理慢）
擅长事实性问答、知识库、时效信息风格/格式/领域适配、能力注入单文档深度分析、长文阅读

怎么选？给你三条决策经验：

  1. 知识在文档里 → RAG。客服、企业知识库、政策法规、产品文档，答案"现成"在资料里，RAG 是默认首选；
  2. 知识在参数里 → 微调。需要改变模型的说话风格、输出格式、领域术语，或希望"不查资料也能答对"——比如让模型学会你的 API 调用方式，见微调与 PEFT（LoRA）；
  3. 一次性的长文理解 → 长上下文。给你一篇 10 万字的报告做总结、问答，直接喂进去，不要先建索引。

组合拳更常见

真实系统往往是组合的：RAG 兜底事实、微调兜底风格、长上下文兜底单次大文档。例如客服机器人 = 微调出"客服语气" + RAG 查政策库 + 长上下文读用户上传的合同。

五、落地关键点：四件容易被低估的事 ​

RAG 在 demo 里看起来简单，生产化时四个环节最容易被低估：

1. 检索质量评估（检索不评，等于盲人摸象）。 别只盯着"回答好不好"，先量化"检索准不准"。

  • 指标：召回率（正确答案是否在 top-k 里）、命中率（Hit Rate）、MRR（排序质量）；
  • 端到端：用 RAGAS 一类的评估框架测 answer faithfulness（回答是否忠于材料）、answer relevancy（是否切题）、context precision/recall（上下文质量），见LLM 评估与基准；
  • 做法：先攒 50~200 个真实问答对做评测集，迭代检索参数时看指标变化，不要用感觉调参。

2. chunk 大小调优（唯一靠谱的方法是实验）。 固定其他环节，只改 chunk size 跑一组评测，看命中率曲线。常见现象：chunk 从 100 涨到 500，命中率先升后降——太小丢上下文，太大稀释语义，存在一个"甜点区间"。

3. 向量库选型（按规模与运维能力选）。 从"嵌入式轻量库"到"分布式重库"是一个梯度：

选型典型代表适用规模特点
嵌入式Chroma、FAISS、SQLite-vec万级 chunk零运维，快速起步
开源服务器Milvus、Qdrant、Weaviate百万级可扩展，需运维
云托管Pinecone、云厂商向量库任意规模免运维，按量付费
基于 PostgreSQLpgvector十万级与业务库同栈，事务一致

选型细节与语义检索原理见向量数据库与语义检索。别在起步阶段纠结选型，先用嵌入式库跑通，规模上来再迁移。

4. 成本与延迟（账要算在前面）。 RAG 的隐性成本常被忽略：Embedding 生成与存储费用、rerank 的额外推理开销、向量库的 QPS 压力、索引随文档增长的维护成本。优化方向：结果缓存（相同问题命中缓存）、检索器分级（先用便宜的召回，再对 top-k 精排）、量化压缩向量，以及更通用的推理优化手段，见推理优化与量化。

六、真实产品案例：RAG 已经无处不在 ​

RAG 不是实验室玩具，头部产品早已把它作为核心能力：

  • Perplexity：AI 搜索引擎的标杆。用户提问 → 实时抓取网页 → 检索 → 生成带引用答案，回答底部附来源列表，用户可逐条核对。它把"可溯源"做成了产品体验的核心卖点，详细拆解见Perplexity 与 AI 搜索；
  • Notion AI（企业版）：让用户"Ask AI"直接问答工作区里的文档、会议记录、数据库，所有回答可跳转回原始页面——典型的企业知识库 RAG；
  • Microsoft Copilot（Bing 模式）：联网检索 + 生成，浏览器场景的 RAG 落地；
  • 各类客服/法律/医疗助手：检索对应政策条款、法规条文后作答，并附条文编号。

这些产品证明了一个共性：好的 RAG 产品 = 60% 检索质量 + 30% 交互设计 + 10% 生成。想把 Perplexity 搬回家，可以对照从零搭建 RAG 应用实操一遍。

七、局限与常见误区 ​

RAG 是工程解而不是银弹，它有自己的边界：

局限一：检索失败，则生成失败。 RAG 的回答上限被检索质量锁死——召回不到正确答案时，LLM 可能强行编一个"看起来合理"的答案。检索是 RAG 的阿喀琉斯之踵，这也是"大海捞针"类测试（把关键信息埋在一份超长文档里）频频翻车的原因：不是模型不行，是检索器捞不到那根针。

局限二：评估难。 生成式答案没有唯一标准，"回答好不好"本身依赖人工主观判断；检索质量、生成质量、提示词效果三者的锅常常纠缠不清。评测体系搭建见LLM 评估与基准与搭建一套 LLM 评估。

局限三：上下文窗口是有限资源。 检索片段过多会挤占窗口、稀释注意力；过少又可能漏掉关键证据，需要精打细算。

三个高频误区

  1. "RAG = 拼 prompt"：只做拼接不优化检索，效果必然差；检索优化才是主力战场；
  2. "chunk 越小越好"：小 chunk 提高定位精度，却丢了上下文，答案常"对但残"；
  3. "有了 RAG 就不用微调"：RAG 管"知识"，微调管"能力与风格"，两者解决不同问题。

更系统的翻车案例与规避方法见常见陷阱与反模式。

延伸阅读 ​

参考资料 ​