夜雨聆风
AI 概念日志 · 第 006 讲|RAG:让 LLM 先翻书再答
episode:006
title:AI 概念日志 · 第 006 讲
#RAG
>让 AI 不再瞎编的关键技术.
每隔几个月，AI 圈就会冒出一波「RAG 已死」的论调。理由听起来很有道理：长上下文窗口都到 100 万 token 了，把整本书塞进去问就行，何必折腾向量检索。
但同一时段的另一组数据是：2025 年企业 RAG 部署增长 280%；LinkedIn 用 RAG + 知识图谱把客服解决时间砍了 28.6%；Perplexity 靠 RAG 做到 4500 万月活、4.5 亿美元年化收入、估值 200 亿。
「RAG 已死」和「RAG 在创历史新高」同时为真——这本身就是个值得搞清楚的反常识。
前 5 讲讲 AI 怎么动手（Agent 四部曲）。这一讲讲 AI 怎么知道。
##一句话理解
RAG 是在 LLM 回答问题前，先从外部资料里找出几段相关内容，连同问题一起塞进 prompt 的一种方法。
如果只能记一句话：让 LLM 不要凭记忆回答，先翻书再答。
##它解决了什么问题
LLM 的三个原生缺陷，一个 RAG 全解
– Before RAG
LLM 单干有三个跨不过去的坎：知识有截止日期（训练完就冻结）、不知道你的私有数据（公司 Wiki / 客户合同它没见过）、容易瞎编（即使在它知识范围内）。
这三件事，靠把模型训练得更大解决不了。前两件本质上做不到，第三件只能缓解。
+ After RAG
RAG 用同一个机制同时解决三件：用户提问 → 系统先去外部知识库里搜相关段落 → 把段落 + 问题一起塞给 LLM → LLM 基于这些段落生成回答，并标注来源。
知识库实时更新解决知识截止；知识库放你公司内部文档解决私有数据；LLM 看着原文回答 + 给引用解决瞎编。一个机制三个收益。
RAG 是 2020 年 Patrick Lewis 等人在 NeurIPS 论文里提出的（Facebook AI Research，现 Meta AI）。Lewis 后来在 NVIDIA 采访里公开「为这个不雅缩写道歉」——他说当年起名时没想到会火成这样，现在他在 Cohere 领衔 RAG 团队。
##怎么工作的
两个阶段，五个步骤
RAG 分两段：离线建索引（一次性做好），在线查询（每次提问做）。
// STAGE 01 · 离线 · INDEXING
▸切块 + 向量化 + 入库
把所有文档（PDF / 网页 / Wiki / 工单）切成小段（chunking），用 embedding 模型转成向量，存进向量数据库（Pinecone / Weaviate / Qdrant 等）。这一步是离线的，做一次就行。
// STAGE 02 · 在线 · QUERYING
▸检索 → 增强 → 生成
用户问题来了，三步：
1. RETRIEVE 问题向量化 → 在库里找最相似的 K 段 2. AUGMENT 把 K 段拼到 prompt 里:「以下是相关资料: ...」 3. GENERATE LLM 基于这些资料生成回答 + 引用来源
关键观察：RAG 真正难的不是向量搜索
大众以为「RAG = 向量搜索」，错。向量搜索只是五步里的一步。RAG 真正难的是切块（切得不对，相关段落根本搜不出来）和重排（reranking）（搜出来还得二次排序，否则 LLM 拿到的是噪声）。
还有 2023 年 Stanford 的「Lost in the Middle」论文：LLM 在长上下文中呈 U 型性能曲线——开头和结尾的信息记得住，中间的容易丢。GPT-4 / Claude / Gemini 都躲不过。所以 RAG 的真价值是：不是给 LLM 更多资料，而是把对的资料放在对的位置。
##真实产品案例
从经典 RAG 到 Agentic RAG · 三个跨光谱案例
CASE_01.md · 经典 RAG / C 端
Perplexity · 把 RAG 做成独立搜索产品
Perplexity 是 RAG 最成功的 C 端案例：你问问题，它实时搜网页 → 检索相关段落 → LLM 回答 + 标引用。2026 年 3 月数据：4500 万月活、10 亿月查询量、4.5 亿美元年化收入、估值 200 亿。后端用 Vespa.ai 把向量、关键词、排序统一在一个栈里。
// 用户感知：把 RAG 做到极致，本身就能挑战 Google 搜索
CASE_02.md · GraphRAG / B 端
LinkedIn 客服 · 把工单变成知识图谱
LinkedIn 客服团队发现，传统 RAG 把 Jira 工单当纯文本切块时，相同问题的描述和解决方案常被切散。他们的做法：把工单转成知识图谱（保留 issue 内部结构 + issue 之间的关系），再做检索。SIGIR 2024 论文公开数据：检索准确率 MRR 提升 77.6%，客服中位解决时间下降 28.6%，已生产部署 6 个月。
// 用户感知：当数据有强关系结构，GraphRAG 拿向量 RAG 拿不到的精度
CASE_03.md · Agentic RAG / 2026 前沿
Agentic RAG · 把 RAG 接进 ReAct 循环
2026 年企业 RAG 的主流形态。框架：LangGraph / Claude Agent SDK / LlamaIndex AgentQueryEngine。模式：Agent 规划 → 多轮检索 → 反思 → 再检索 → 答。Morgan Stanley 跑内部金融研究 Agent，PwC 用在税务合规，ServiceNow 嵌进 IT 工作流。市场预测：3.8 亿（2024）→ 1650 亿（2034）。
// 用户感知：用 EP_004 的 ReAct 决策算法去驱动 RAG，知识层 + 决策层合流
##你会在哪里遇到它
六个现实锚点
[01] Perplexity / Felo / You.com — C 端答案引擎，本质都是经典 RAG 包装。
[02] Notion AI Q&A、GitHub Copilot Chat — 在你的工作区/代码库里做 RAG。
[03] ChatGPT Enterprise / Claude for Enterprise — 连企业知识库做 RAG。
[04] Pinecone / Weaviate / Qdrant / Vespa — 向量数据库，RAG 的存储层。
[05] arXiv 2005.11401 — Lewis et al. 2020 RAG 原始论文（NeurIPS）。
[06] arXiv 2307.03172 — Lost in the Middle，解释为什么长上下文也救不了 RAG 该解决的问题。
##一个反常识观察
「RAG 已死」是错的，但「经典 RAG 已死」是对的。
每次有新模型发 100 万 token 上下文窗口，就会有一波「RAG 不再需要」的舆论。但这个论调有两个事实硬伤。
第一，长上下文 ≠ 长理解。Lost in the Middle 已经证明：把 90 万 token 资料一股脑塞进 prompt，LLM 倾向于只用开头和结尾的内容，中间会丢。U 型曲线在 GPT-4 / Claude / Gemini 上都重复出现。第二，成本扛不住——把整本书塞进 prompt，每次提问都跑 100 万 token 推理，按 API 计费可能是 RAG 方案的 50-100 倍。
但反过来说，2023 年那种「向量搜索 + 拼 prompt」的经典 RAG 流水线，确实正在被取代——不是被长上下文，是被两个新形态:
经典 RAG (2020-2023) 单轮: 检索 → 生成 GraphRAG (2024-) 知识图谱 + 向量混合，擅长多跳推理 Agentic RAG (2025-2026) ReAct 循环 + 多轮检索，Agent 自己决定查什么
所以这一讲最值得记住的话：RAG 不是给 LLM 找资料，是替 LLM 限制资料范围。瓶颈从来不是 LLM 不够大，是怎么把对的资料放在对的位置。
// FURTHER_READING
如果你已经懂本讲，下一讲推荐：
→第 007 讲｜Embedding（向量嵌入）：为什么向量搜索能找到「语义相似」，RAG 检索的底层
→第 008 讲｜向量数据库：Pinecone / Weaviate / Qdrant 各自的定位与差异
→第 009 讲｜Reranking（重排序）：为什么搜出来还要再排一次，RAG 提质的关键一步
▸ 下一讲预告：第 007 讲｜Embedding（为什么向量搜索能找到「语义相似」）
// AI 概念日志 · 永续栏目
每讲一个概念，看懂 AI 行业
@AI 产品日志