RAG 入门

⚠️ 源单薄性声明 本条目素材正反两边都单薄——正方没有独立学术 / 工业界深度论文，反方主要是 Obsidian-AI 橙书 + Boris 访谈共 2 份。已讲清楚:RAG 是什么 / 为什么火 / 反 RAG 阵营的具体反对理由 / AIBuilder 自身的立场矛盾还没听到:大规模生产环境 RAG 的真实 benchmark、向量数据库的具体对比、“什么场景 RAG 确实最优”的硬案例本条目最诚实的读法:这是一个正在进行的架构辩论，不是定论。

一句话

RAG = Retrieval-Augmented Generation。让 AI 在回答前，先从一个”外部知识库”里检索相关片段，再把片段+你的问题一起喂给 LLM 生成答案。

它解决了啥

没 RAG 之前:你要让 AI 知道你公司的文档、产品手册、内部规范——只能把全部内容塞进 prompt。token 消耗爆炸，超过上下文窗口就完蛋。

有 RAG 之后:知识库预处理成向量存起来；你问问题时只检索最相关的 3-5 段，拼进 prompt。常量级 token 消耗。

典型架构（AIBuilder 本项目就是这么做的）:

用户问问题
  ↓
Query 向量化
  ↓
向量数据库（chromadb / pinecone / anythingllm）检索 top-k 相似段
  ↓
Top-k 段 + 用户问题 → LLM
  ↓
答案

它在 AIBuilder 本项目的角色

来源:本 repo CLAUDE.md + 蓝图 Blueprint v1.7。

后端:AnythingLLM（容器化）承载向量库 + RAG 检索
LLM:MiniMax（国产）
数据源:wiki/*.md 批量上传（sync/bulk-upload.sh）
前端:chat widget 嵌入在 Quartz wiki 页面右下角

好朋友问一个 AI 相关问题 → RAG 从 wiki 里查相关条目 → MiniMax 生成答案 → 答案里带 wiki 引用。Obj 2”后来者受益于先来者”就是靠这个机制跑通。

但是——有个强反对声音

来源:Obsidian-AI 橙书 + Boris pragmatic-interview。

Obsidian-AI 橙书的核心立场

花叔 Obsidian-AI 橙皮书（huasheng-github-orange-books/11-obsidian-ai/）明确提出:

“Markdown 是 AI Agent 的原生接口；LLM 应该是编译器而非检索器（Karpathy 40 万字验证）；一个 CLAUDE.md + 每目录一个 index.md 就做到 80%，不需要复杂 MCP 或 RAG。”

翻译:绝大多数”要 RAG 的场景”其实不用 RAG 就能做好——让 LLM 直接读 md 目录结构，比向量检索更准。

Boris 的反 RAG 经验

boris-cherny/pragmatic-interview.md 里明确提到:Anthropic 内部做 Claude Code 时，试过向量库 / 递归索引，都被 Claude 用 glob+grep 打败。

理由（Boris 原话精神，非逐字引述）:

stale index 是硬伤——代码一直在变，索引永远跟不上
权限复杂性——向量库绕过了文件系统权限，容易泄密
Claude 自己会找——它用 glob 和 grep 比你手工建的索引更准

AIBuilder 自身的立场矛盾

AIBuilder 用 AnythingLLM RAG，但两份权威素材（Obsidian-AI + Boris）都在反 RAG。

这是本项目架构上的真实张力——我们不假装这不存在。陈彬在蓝图 v1.7 里记录的 Plan B 链包含了”如果 RAG 效果不佳，考虑退回 Markdown-first 方案”。

什么时候 RAG 确实有意义

（这是我的推断，不是素材给的结论——请当一家之言）

知识库规模大（wiki 上百条 + 长文档）——直接塞 context 会爆
用户是”问问题”场景而非”改代码”场景——问答 ≠ 开发
知识更新慢（每周一次而非每分钟一次）——stale index 问题不严重
用户不会 grep（非程序员社群）——glob+grep 不是所有人都会用

AIBuilder 好朋友场景三条都符合，所以当前立场是”先跑 RAG，看 3 天反馈再决定是否切换”。

什么时候 RAG 可能不是最优

（同上，推断）

对象是代码 / 结构化文件——glob+grep 更快更准（Boris 的场景）
用户自己会组织知识（像陈彬在 PK 里）——CLAUDE.md + 目录 index 够用（Obsidian-AI 的场景）
需要精确引用而非模糊相似——向量检索是”语义相似”，不保证精确

多观点并存（这是架构级分歧，本 wiki 不给单一推荐）

关于 RAG 该不该用，目前 wiki 里至少有两条对立声音并存，读者按自己场景判断：

观点 A：RAG 被过度推销了（见 Obsidian-AI 的反 RAG 观点）

Obsidian-AI / Karpathy / Boris：很多”要 RAG 的场景”其实用 Markdown-first + glob/grep 更好
典型不适合 RAG 的场景：代码库、个人小规模知识库、会频繁更新的结构化文档
核心理由：stale index、权限复杂、LLM 自己会找

观点 B：社群问答场景 RAG 仍有价值（本条目立场）

大规模长尾 wiki、多用户问答、非程序员用户入口——RAG 简化了”查询权限 + 召回+ 拼 prompt”
典型适合 RAG 的场景：AIBuilder 这种第三方好朋友通过 chat widget 访问
未被完全验证的假设：RAG 在 40 万字以下规模真的比 Markdown-first 好吗？——需要实测

AIBuilder 当前的选择：用 RAG（AnythingLLM），不是因为它”对”，是因为好朋友场景的入口形态（浏览器 + widget）决定了后端必须有检索层——他们无法像陈彬那样”自己在 Claude Code 里直接读目录”。

这不是定论，是待验证的选择。Plan B 链（蓝图 v1.7）包含”如果 RAG 效果不佳，考虑 Markdown-first 替代方案”。

needs_sources（明确待补）

大规模生产 RAG 的 benchmark（正面数据）
Obsidian-AI 具体案例（纯 md 方案的真实效果）
RAG vs grep 的同任务实测
向量数据库选型对比（chromadb / pinecone / AnythingLLM / Qdrant）

AIBuilder · AI 搭建系统社群知识库

探索