RAG：给大模型外挂知识库

一、一句话定义

RAG（Retrieval-Augmented Generation，检索增强生成）= 在让模型回答之前，先去知识库里"查资料"，把查到的内容塞进上下文，让模型基于这些资料回答。

简单说：先查，后答。

二、为什么需要 RAG

大模型有三个绕不过去的硬伤：

1. 知识截止：训练数据有时间限制，2024 年训练的模型不知道 2025 年发生的事。
2. 不懂私域：你公司的代码、文档、客户资料，它完全没见过。
3. 会幻觉：不知道也敢瞎编。

那为什么不直接把所有资料塞到 Prompt 里？因为：

• 上下文窗口装不下
• token 成本爆炸
• 内容越长，模型注意力越涣散

RAG 的核心思想：不是把知识"装进模型"，而是把知识"放在外面，需要时按相关度取一小段进来"。

三、RAG 的完整流程

整个 RAG 系统分两个阶段：离线建库 和 在线问答。

阶段 A：离线建库（一次性）

原始文档 → 切分（Chunking） → 向量化（Embedding） → 存入向量数据库

步骤	做什么
切分	把长文档切成小段（通常 200～800 字）
向量化	用 Embedding 模型把每段文字转成一个高维向量
入库	向量+原文 一起存进向量数据库（Pinecone、Milvus 等）

为什么要变成向量？ 因为机器没法"理解"文字，但可以算两个向量的相似度。
语义相近的文字，向量也相近——这是 RAG 能跑起来的物理基础。

阶段 B：在线问答（每次提问触发）

用户问题 → 向量化 → 在向量库里找最相似的 K 段
        → 把这 K 段拼进 Prompt → 模型生成回答

具体说：

1. 用户问：“我们公司报销的流程是什么？”

2. 把这句话也用同一个 Embedding 模型变成向量。

3. 在向量库里找出和这个向量最接近的 5 段原文（比如《报销手册》里的 3 段、《财务规章》里的 2 段）。

4. 把这 5 段拼成一个新的 Prompt：

   下面是公司内部资料，请基于这些资料回答用户问题。
   如果资料里没有，请说"不知道"。
   
   [资料 1]……
   [资料 2]……
   ……
   
   用户问题：我们公司报销的流程是什么？
   

5. 模型基于这些资料生成回答。

四、一张图看懂 RAG vs 纯 LLM

对比维度	纯 LLM	RAG
知识来源	训练时记住的	外部知识库 + 训练知识
知识更新	重新训练才能更新	改库即可，立刻生效
私域数据	完全不会	想喂什么喂什么
是否有据可查	基本没有	可以返回引用片段
幻觉风险	高	显著降低（但不为零）
成本	推理成本	推理 + 向量化 + 存储成本

五、RAG 里的几个关键决策

RAG 听起来简单，真正做好却处处是坑。下面几个点，每一个都能让效果差出一倍。

1. Chunk 切多大？

• 太小（50 字）：单段没头没尾，缺上下文。
• 太大（2000 字）：一段塞太多内容，相似度被稀释。
• 常用经验：300～500 字一段，段间留 50～100 字重叠（防止重要信息被切在边界）。

2. Embedding 模型选哪个？

不同 Embedding 模型对中文、代码、专业术语的表现差异很大。先用小数据集做评测，再选。
常见可选：text-embedding-3-large（OpenAI）、bge-large-zh、m3e、Cohere Embed。

3. 检索 Top-K 取几条？

• 太少（K=1）：错过相关资料。
• 太多（K=20）：噪声多，token 浪费。
• 常用 K=3～8，再配合"重排序"（rerank）筛精。

4. 要不要 Rerank？

向量检索很快但不够精准，业界惯用做法：

向量库召回 Top-30 → 用更强的 Reranker 模型精排 → 取 Top-5 → 喂给 LLM

Reranker 比 Embedding 慢，但准确率显著更高。

5. 怎么处理"问题里的代词"？

用户问完"什么是报销流程？“，紧接着问"那需要什么材料？”。
"那"指什么？纯向量检索抓不到。
解决：先用 LLM 把多轮对话改写成一个独立完整的问题，再去检索。
这一步叫 Query Rewriting。

6. 没查到怎么办？

宁可让模型说"我不知道"，也不要让它强答。
关键是 Prompt 里显式声明：“如果资料里没有，请回答’我不知道’。”

六、进阶：从朴素 RAG 到高级 RAG

朴素 RAG 简单粗暴：“切分 → 入库 → 检索 → 生成”。
但真实业务里很快会发现它的局限。下面是几条主流的"高级 RAG"思路：

1. Hybrid Search（混合检索）

向量检索擅长"语义相近"，关键字检索擅长"专有名词命中"。
两路一起召回，结果合并，对人名、产品 ID、错误码这类内容效果好得多。

2. Multi-hop（多跳检索）

复杂问题需要先查 A，再根据 A 的答案去查 B。
让 LLM 主动决定"还要不要再查一次"——这就走到了 Agent 的领域。

3. Graph RAG（图谱增强）

把文档之间的关系建成知识图谱，检索时不仅找相似段落，还沿着关系跳一跳，适合企业内部错综复杂的资料。

4. Agentic RAG

把 RAG 的每一步（改写、检索、判断够不够、要不要再查）都交给 Agent 自主决策。
这种模式下，RAG 不再是一个固定流程，而是一个会思考的工作流。

七、RAG 的典型应用场景

场景	为什么适合 RAG
企业内部问答	私有文档、规章制度，不能给模型训练
客服机器人	商品知识库经常更新
代码助手	项目代码本地、敏感、巨大
法律 / 医疗咨询	必须有据可查、可溯源
个人知识库	你的笔记、邮件、聊天记录

八、什么时候不该用 RAG

• 任务是计算 / 推理，不是"找资料"——RAG 没用，该用工具或思考链。
• 知识量极小（几页 PDF）——直接塞进 Prompt 反而更准。
• 需要强一致性的事实（比如实时股价）——该用 Tools 调 API。
• 需要高度结构化的查询（按字段精确过滤）——直接走 SQL，别套 RAG。

RAG 不是银弹，它解决的是"私有知识 + 模糊查询"这一类问题。

九、RAG、Tools、Agent、微调的边界

经常被混淆，简单做个对比：

方法	解决的问题	代价
Prompt	改语气、改格式、改风格	几乎为零
RAG	让模型用上私有 / 最新知识	中等（建库+检索）
Tools	让模型能查实时数据 / 执行操作	中等（开发+维护）
Agent	让模型自主完成多步任务	高（设计+调试）
Fine-tune	让模型养成新的能力 / 风格 / 领域感	高（数据+训练+迭代）

业界共识：能用 RAG 解决的，绝大多数情况都不需要微调。

十、小结

• RAG = 先查后答：把私有 / 最新的知识放在外面，按需检索进上下文。
• 流程：离线（切分 → 向量化 → 入库）+ 在线（向量化问题 → 检索 → 拼 Prompt → 生成）。
• 关键决策：Chunk 大小、Embedding 模型、Top-K、Rerank、Query Rewriting、空答兜底。
• 进阶方向：Hybrid Search、Multi-hop、Graph RAG、Agentic RAG。
• 不要迷信：RAG 是工具不是万能药，错配场景反而拖累效果。

一句话总结：模型不可能学会世界上所有知识，但可以学会"在用之前先去查一查"。