003｜RAG 到底在做什么：从向量检索到 Agent 知识库
RAG 不是让 LLM 变聪明，而是给 LLM 一个可控的资料来源。
核心结论：RAG 不是让 LLM 变聪明，而是给 LLM 一个可控的资料来源。模型能力再强，也需要企业私有知识、最新信息和可溯源的答案。RAG 是 Agent 可调用的知识库工具，不是系统的全部。
一、RAG 是什么
RAG = Retrieval-Augmented Generation，检索增强生成。
一句话：先检索资料，再生成答案。
没有 RAG
用户问题 → LLM 直接回答
有 RAG
用户问题 → 从知识库找相关资料 → 把资料 + 问题一起给 LLM → LLM 回答
二、为什么要用 RAG
| LLM 的问题 | RAG 的解决 |
|---|---|
| 不知道最新信息 | 检索最新资料 |
| 编造答案 | 基于检索到的资料回答 |
| 领域知识不足 | 检索领域文档 |
| 上下文太长 | 只检索相关内容 |
| 答案不可溯源 | 可标注来源 |
三、一个报销助手的例子
原始文档
第三章 差旅报销
3.1 飞机票
- 经济舱可以全额报销
- 商务舱需要提前审批，报销比例 80%
- 头等舱不报销
3.2 住宿费
- 一线城市每晚不超过 500 元
- 二线城市每晚不超过 300 元
切成片段
片段1：飞机票报销规则：经济舱全额报销，商务舱需提前审批且报销80%，头等舱不报销。
片段2：住宿费标准：一线城市每晚不超过500元，二线城市每晚不超过300元，超出部分自理。
片段3：商务舱报销：需要提前审批，报销比例80%，未审批不报销。
用户提问
商务舱能报销吗？
检索匹配
RAG 找到最相关的片段：
- 片段1
- 片段3
给 LLM 的输入
你是一位报销规则助手。请根据以下资料回答问题。
相关资料：
[片段1] 飞机票报销规则：经济舱全额报销，商务舱需提前审批且报销80%，头等舱不报销。
[片段3] 商务舱报销：需要提前审批，报销比例80%，未审批不报销。
用户问题：商务舱能报销吗？
最终答案
商务舱可以报销，但有两个条件：需要提前审批；报销比例是 80%，不是全额。如果没有提前审批，商务舱不能报销。
四、RAG 是怎么存储的
不是简单 key-value，而是存四样东西：
| 字段 | 是什么 | 例子 |
|---|---|---|
| id | 片段编号 | "doc1" |
| document | 原始文本 | "经济舱全额报销..." |
| embedding | 向量 | [0.12, -0.33, 0.85, ...] |
| metadata | 额外信息 | {source: "报销手册", page: 3} |
存入流程：
原始文档 → 切分成片段 → 用 Embedding 模型转成向量 → 存入向量数据库
检索流程：
用户问题 → 用 Embedding 模型转成向量 → 在向量数据库里找最相似的向量 → 返回对应文本
五、向量匹配到底是什么
不是关键词匹配
RAG 不是查"商务舱"三个字。它比较的是语义向量距离。
例子
库里有两个片段：
| id | 文本 | 向量（简化成2个数字） |
|---|---|---|
| doc1 | 经济舱全额报销 | [1, 0] |
| doc2 | 商务舱报销80% | [0.9, 0.1] |
| doc3 | 餐饮补贴150元 | [0, 1] |
用户问题"商务舱能报销吗？"转成向量：[0.85, 0.05]
计算距离：
- 到 doc1：很近
- 到 doc2：非常近
- 到 doc3：很远
所以返回 doc1 和 doc2。
六、RAG 可以存什么内容
| 类型 | 例子 | 用途 |
|---|---|---|
| 数据库表结构 | orders 表字段说明 | 帮 LLM 写 SQL |
| 指标定义 | DAU 怎么算 | 避免理解错指标 |
| 业务文档 | 优惠券规则 | 回答业务问题 |
| 历史案例 | 历史问题 + 正确 SQL | 提供参考 |
| 代码文档 | API 怎么用 | 回答开发问题 |
| 错误排查记录 | 某报错怎么处理 | 技术支持 |
七、RAG 在 Agent 里的位置
用户问题
↓
[RAG 检索]
├→ 相关表结构
├→ 指标定义
├→ 历史 SQL 案例
└→ 业务文档
↓
[数据查询 Agent]（基于 RAG 结果生成 SQL）
↓
[归因分析 Agent]
↓
[风控 Agent]
↓
输出
八、RAG 在 Agent 里的调用时机
| 时机 | 例子 |
|---|---|
| 用户问题进来时 | 先检索相关知识，再交给 Agent |
| Agent 执行前 | 数据查询 Agent 需要 schema 时检索 |
| 生成 SQL 前 | 检索相关表和历史 SQL |
| 归因分析前 | 检索业务指标定义 |
常见做法：
def answer(question):
context = retriever.retrieve(question, top_k=5)
prompt = f"基于以下资料回答问题：
{context}
问题：{question}"
return llm.generate(prompt)
九、片段切分多少合适
| 太小 | 太大 |
|---|---|
| 语义断裂 | 无关信息多 |
| 匹配数量多但质量差 | 干扰 LLM |
| 上下文丢失 | 超出上下文长度 |
常见大小：
- 一般文档：200-500 字
- 代码/Schema：按函数或表切
- 问答对：一问一答
最终靠实验确定。 准备测试集，用不同大小跑一遍，看哪个效果好。
十、RAG 的效果评估
| 指标 | 含义 | 怎么测 |
|---|---|---|
| 检索准确率 | 检索出来的片段是否相关 | 人工标注 top 5 |
| 召回率 | 正确答案的片段有没有被检索到 | 看是否在 top 10 |
| 回答正确率 | 最终答案对不对 | 人工打分 |
| 幻觉率 | 有没有编造 | 对比原文 |
| 响应延迟 | 检索耗时 | 日志统计 |
迭代方向：
- 切分策略
- Embedding 模型
- top_k 数量
- 相似度阈值
- 重排序
- 混合检索（向量 + 关键词）
- 元数据过滤
十一、模型能力越来越强，RAG 会消失吗
不会消失，但形态会变。
模型强了，确实可以替代一些简单 RAG
比如通用常识、简单推理，直接问 LLM 就行。
但 RAG 仍然必要
| 原因 | 解释 |
|---|---|
| 模型没有私有数据 | 公司手册、数据库 schema |
| 模型会过时 | 业务规则经常变 |
| 模型会幻觉 | 没有资料支撑容易胡说 |
| 需要可溯源 | 企业答案必须说明来源 |
| 成本控制 | 检索少量资料比全塞更便宜 |
| 权限控制 | 不同人看到不同资料 |
最新趋势
| 趋势 | 说明 |
|---|---|
| 长上下文 + RAG 结合 | 不再二选一，而是互补 |
| Agentic RAG | RAG 成为 Agent 的工具之一 |
| 多模态 RAG | 检索图片、PDF、表格 |
| GraphRAG | 向量检索 + 知识图谱 |
| RAG 评估工具化 | RAGAS、LangSmith 等 |
十二、一句话总结
RAG 是给 LLM 配一个"资料库"。用户提问时，先找相关片段，再让 LLM 基于这些片段回答。模型再强，也需要可控、可更新、可溯源的知识来源。
下一步可以读
- 004｜LangGraph 入门：多 Agent 工作流框架（已更新）
- 005｜主流多 Agent 框架对比：LangGraph / CrewAI / AutoGen / LlamaIndex（已更新）
- 006｜Agent 项目工程化：代码组织、测试、部署（待更新）