⚠️ 源单薄性声明
本条目素材正反两边都单薄。已经能讲清：RAG 是什么、为什么火、反 RAG 阵营在反什么、AIBuilder 当前为什么仍然先用它。还讲不清：大规模生产环境 benchmark、向量数据库选型、哪些场景它确定最优。
最诚实的读法是：这是一个正在进行的架构辩论，不是定论。
一句话定义
RAG 是 Retrieval-Augmented Generation 的缩写，意思是 AI 回答前先从你的资料库里检索相关片段，再基于这些片段生成答案。
人话版：它不是“先记住你的材料”，而是“需要时临时去查，再拿查到的内容回答”。
为什么重要 / 什么场景会听到
没有 RAG 时，如果你想让 AI 知道公司的 wiki、产品手册、内部规范，往往只能整坨塞进 prompt；token 爆掉或上下文不够大时，这条路就不稳了。
RAG 会在这些场景被提到：
- 私有知识不能靠模型预训练记住
- 文档量已经大到不能直接整包塞进上下文
- 用户入口是“问答”，不是“让 AI 自己到目录里找”
- 像 AIBuilder 这种浏览器 widget 问答场景，需要一层检索后端
技术机制
它最核心的链路分三步：
- 索引阶段：把文档切片、向量化，放进向量库。
- 检索阶段：把用户 query 向量化，按相似度取 top-k 片段。
- 生成阶段：把这些片段和问题一起塞给 LLM 生成答案。
典型结构：
用户问问题
↓
Query 向量化
↓
向量数据库检索 top-k 相似段
↓
Top-k 段 + 用户问题 → LLM
↓
答案最小可跑通例子
最小可跑通的心智模型很简单：上传一批 markdown 或 PDF，让系统基于这些材料回答问题。
现有条目里提到的例子：
- AnythingLLM
- NotebookLM
- Obsidian Copilot
AIBuilder 当前的具体形态是：
- 后端：AnythingLLM
- 数据源：
wiki/*.md - 前端：Quartz 页面里的 chat widget
好朋友提问时，系统先从 wiki 检索相关条目，再交给 LLM 生成答案。
常见误解 / 陷阱
- 误解一：RAG 等于“真记住”了。不是，每次都是临时检索。
- 误解二：材料越多越好。不是，噪音越大，召回质量可能越差。
- 误解三：RAG 是唯一方案。不是，现有素材里就有强烈的反 RAG 立场。
- 误解四：embedding 一次建完就行。不是，文档更新后索引会陈旧。
- 反例：把 10GB 未清洗的材料直接扔进去，召回会被噪音稀释，答得可能还不如直接瞎猜。
什么时候它有意义，什么时候可能不是最优
当前素材支持的“相对更适合”场景：
- 知识库规模较大，直接塞上下文会爆
- 用户是问答场景，而不是改代码场景
- 知识更新没有快到每分钟都变
- 使用者不是会自己
glob + grep的程序员
当前素材支持的“可能不是最优”场景：
- 对象是代码库或结构化文件
- 用户本来就能直接读目录、组织 markdown
- 任务需要精确引用而不是语义相似
这里必须保留现有条目里的反对声音：
- Obsidian-AI 橙书主张，很多场景里 Markdown-first 就够，不需要复杂 RAG。
- Boris 的经验是，向量库和递归索引在代码场景里被
glob + grep打败过。
AIBuilder 当前立场
AIBuilder 自己就在这条张力里：项目当前用 AnythingLLM 做 RAG，但现有两份关键素材都在提醒“RAG 不一定是最优”。
当前选择不是因为它已经被证明最好，而是因为：
- 入口形态是浏览器 widget
- 用户是第三方好朋友，不是在 Claude Code 里自己翻目录
- 先把基于 wiki 的问答跑通，比先追求最纯粹的 Markdown-first 更直接
同时，现有条目也明确保留了 Plan B：如果 RAG 效果不佳，可以退回 Markdown-first 方案。
与其他术语的关系
[[上下文]]：RAG 是解决“上下文窗口装不下所有资料”的方案之一。[[MCP]]：两者都让 AI 接到项目外信息，但一个偏知识检索，一个偏工具协议。[[CLAUDE.md]]：CLAUDE.md是直接塞进上下文的长期规则，RAG 是按需检索的知识补充。[[Harness]]：在这个 wiki 语境里，RAG 可以看作 harness 的知识接入层实现之一。
延伸阅读 / 官方链接
🎬 3 个场景（读者最可能用到的情境）
场景 1 · 公司内部 wiki 问答
HR 有一个 200 页员工手册 + 几十份制度文档。上传到 AnythingLLM / NotebookLM，员工问”我育儿假怎么算”，AI 检索相关条款段再回答。比人肉翻手册快得多。
场景 2 · 研报库按主题检索
散户订阅了几个研报库，积累了几千份 PDF。全量塞进 context 不可能，用 RAG 建索引：问”最近锂电产业链有哪些一致预期”，AI 检索相关研报段落综合回答，带出处。
场景 3 · 法律条款精确查找
律师有几十部法律 + 过千判例。用 RAG 按语义检索”最接近当前案情的 3 条先例”，再由 AI 综合要点。注意：精确引用仍要人工核对原文，RAG 只做初筛。
⚖️ 和最像的邻居比
| 术语 | 本质区别 | 适用边界 |
|---|---|---|
| RAG | 检索后把片段喂给 LLM 生成 | 知识量 > context 容量、问答形态 |
| 长上下文（1M 窗口） | 整坨塞进 prompt | 资料能一次塞下、要精确引用 |
| fine-tune | 把知识训练进权重 | 风格/语气/高频结构化模式 |
| grep + Read（Karpathy 式） | 让 AI 自己到文件树里翻 | 使用者是程序员、材料是结构化代码/md |
🚫 反例（不该这么用）
反例 1 · RAG 万能论
“不管什么场景先建个 RAG”。结果代码项目用 RAG，被 glob + grep 打败；小知识库用 RAG，还不如直接全贴；更新频繁的资料用 RAG，索引永远过期。正确做法：先问”资料量真的超过 context 容量吗？使用者能不能直接读？“
反例 2 · 盲目建 RAG 不评估召回
把 10GB 未清洗材料直接扔进向量库，top-k 返回一堆弱相关片段，AI 答得比瞎猜还差。也不测召回率、不看 reranker、不做 chunking 调优。正确做法：先用 20-50 条标准问题测召回，没有 70%+ 就回去优化切片和检索策略。
❓ 常见误解
- 误解 1：“RAG 能取代长上下文” → 实际：两者各有适用面——资料精确引用 / 要全文通观的任务，长上下文更稳；资料量远超窗口 / 纯问答场景，RAG 更省。
- 误解 2：“embedding 一次建完就行” → 实际：文档一变索引就陈旧，增量更新 + 周期重建是必修课。
- 误解 3：“RAG = 真记住了” → 实际：每次都是临时检索 + 临时生成，AI 并没有”学会”你的知识，只是在回答时”查了一下”。
🧬 历史坐标（最早谁提 · 本质 · 分型 · git）
最早谁提
2020-05-22 Patrick Lewis 等在 Facebook AI Research（与 UCL、NYU 合作）提交 “Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks”（arxiv:2005.11401），首次把”先检索再生成”作为一个可端到端微调的范式命名为 RAG。ChatGPT 2022 后，它从学术方法演化为工业界标配。
本质（一句话 · 20 字内）
AI 回答前先查外部资料再生成。
分型 / 演化（2-4 行主线）
- Naive RAG（切片 + 向量 + top-k）→ Dense retrieval（DPR）→ Hybrid search（向量 + 关键字 BM25）
- Advanced RAG：reranker / query rewriting / multi-hop / HyDE
- Agentic RAG 2024+：agent 自己决定检不检索、检什么
- 反 RAG 分叉：Karpathy LLM Wiki / Boris “glob+grep 就够” / 长上下文派 — 主张”AI 直接读 md”，不要向量库
代表 git / 文档
- RAG 原论文 · Lewis et al. 2020 · 范式起点
- LlamaIndex · Jerry Liu · 面向 RAG 的文档框架
- LangChain · Harrison Chase · retriever / vectorstore 抽象的事实标准
- RAGFlow · InfiniFlow · 深度文档理解的开源 RAG 引擎