📚不玩虚的 RAG · 什么时候你真的需要它（什么时候纯属烧钱）

什么时候会出现这个需求？（那个确切的时刻）

这个需求出现在一个非常具体的时刻：当你的 AI 要同时处理大量信息并开始出错的时候。典型信号：你上传了 30 份 PDF，AI 却「忘掉」了其中一半；你把一本长手册贴给它，它回答时张冠李戴或者干脆瞎编；又或者你每次开新对话都得把同一份大文档再贴一遍，因为它记不住。这时候就会有人跟你说「你需要一个 RAG」。

用大白话讲 RAG（一个技术词都不用）

RAG 意思是「检索增强生成」。听着挺吓人，但道理很简单：与其每次都把你所有的文档塞给 AI（又贵，文档一多还根本塞不下），不如把文档单独存起来，当你提问时，让一个搜索器只检索出相关的小片段递给 AI，让它拿这些来回答。先搜索，再回答。

额外的一大好处：因为 AI 是基于你文档里具体的片段来回答的，它能给你标出出处（「这来自手册第 12 页」）。这正是杜绝瞎编的关键：如果内容不在你的文档里，它就不会给你编出来。

最大的好处：RAG 能省下海量 token（前提是语料库够大）

这里就是 RAG 存在的主要原因，而且分量不轻：省钱。你喂给 AI 的每一个字都要花 token，而 token 就是钱。如果你有 5.000 页文档，每次提问都把它整份贴进去，你会付出一大笔（很多时候还根本塞不下）。RAG 解决的就是这个：与其发 5.000 页，不如只发真正能回答你问题的那 3 到 4 个小片段。

为什么叫「chunks」？（RAG 的关键零件）

chunk 在英文里意思是「块」或「片段」。它是 RAG 的核心零件，所以值得搞懂。你的文档并不是整份存下来的：而是被切成一个个小片段——每个 chunk 通常是一段或几段话——每个片段还会连带一个类似「含义指纹」的东西一起存下来。

黄金法则 · 你真的需要 RAG 吗？

这里有一个几乎没有哪个「大师」会告诉你的数据，而它出自 Anthropic 自己（Claude 的创造者）。这条规则慷慨得出乎意料：

为什么这么重要？因为对大多数项目来说，500 页已经非常多了。你的品牌手册、你的模板、你业务的各种规章制度、几本书……通常都装得下。而只要装得下，搭 RAG 就是无缘无故给自己找麻烦。RAG 是给你真的超出这个体量时用的：超大的资料库、成千上万份文档、时时刻刻在变的数据。

完整的阶梯（让你看清 RAG 在哪一级）

RAG 既不是第一步也不是最后一步——它是阶梯上的一级。按顺序往上爬，别为了赶时髦跳级：

实现 RAG 的 3 种方式（按你的水平来选）

搭建 RAG 不止一种做法：有三种，从最省力到最强大。关键是选真正适合你的那一种，而不是最唬人的那种。它们如下，随后我们一个一个讲：

方式 1 · 一行代码都不写就搭好 RAG（简单路线）

如果你过了那道筛选、确实该用 RAG，那有好消息：你不需要编程，也不用搭数据库。有一些工具，你把文档拖进去就完事，一个带出处标注的智能搜索器就有了。这里有两个任何人今天都能用的：

方式 2 · 用开源仓库（掌控更多）

当你的项目变大，或者你想在自己的服务器上掌控全局时，有一些强大又免费的开源工具。对非专家最友好的两个（你的 AI 会帮你安装它们）：

我想用下面这两个仓库之一，基于我的文档搭一个开源 RAG：
- RAGFlow (https://github.com/infiniflow/ragflow) —— 可视化 RAG，如果我想要一套完整的方案就用它。
- AnythingLLM (https://github.com/Mintplex-Labs/anything-llm) —— 桌面应用，本地且私密。

用简单的语言一步一步引导我，假设我不会编程：
1. 根据我的情况帮我选哪个更合适：[描述你的文档、是否想让一切本地/私密，以及你的操作系统]。
2. 告诉我怎么安装它（连同它的依赖要求，比如 Docker），能你来做的地方就你来做。
3. 帮我上传文档、建立知识库。
4. 把它配置成只用我文档里有的内容作答，并且始终标注出处。
5. 给我 3 个测试问题，确认它确实在正确读取我的文档。

如果某一步得我亲手做，就用确切的操作说明告诉我。

方式 3 · 一个超级应用的 RAG（我们自己那套就是这么跑的）

第三种方式是最硬核的：当你在打造一个超级应用时——一个信息量巨大、用户众多的平台——任何开箱即用的工具都够不着。这时你就要量身打造你自己的 RAG 引擎。这是工程师级别（由你或你的团队指挥代码智能体来做），但我们把它掀开给你看，不玩虚的，让你看看它能走多远：这就是我们在自家应用里用的那套 RAG 引擎是怎么跑的。

当你要动手搭一个量身定制的 RAG 时，把它复制下来贴给你的代码智能体（Claude Code、Cursor）。它内置了那些对我们管用的决策，好让它一开始就站在坚实的地基上，而不是临场瞎凑：

你要帮我为一个大规模应用打造一个量身定制的 RAG。先别急着写代码。先跟我一起做规划，因为最贵的错误就是没定好架构就写代码。

第 1 步 —— 面试我（一次问一个问题，用简单的语言）：
- RAG 要索引什么信息、有多少？（文档类型、大致体量）
- 你预期有多少用户、每天多少次查询？
- 数据经常变吗？我需要删除／更新 chunk 吗？
- 是多租户（多个客户数据分隔）吗？有敏感数据吗？
- 我现在已经用了什么技术栈（数据库、语言、托管在哪）？

第 2 步 —— 提出架构，用这些经过实战检验的决策作为起点（并告诉我在我的情况下是否该改动、为什么）：
- 向量库：PostgreSQL + pgvector 加 HNSW 索引（如果我已经用 Postgres/Supabase，就复用它）。
- Embeddings：一个便宜或免费的模型（比如 Gemini），存好你选定的维度。
- 切块：约 200 token 的片段加一点重叠，并存好元数据（出处、日期、章节）。
- 混合搜索：结合向量 + 精确文本，再加一层 re-ranking 把最相关的往上提。
- 隔离：如果是多租户，每次查询都要始终按客户 id 过滤。

第 3 步 —— 给我一份分阶段的计划（先建什么、什么留到以后），其中要有一个能端到端跑通的最小阶段，然后再谈优化。

第 4 步 —— 列出生产环境 RAG 里最常见的 5 个错误，以及从第一天起如何规避（比如没按租户过滤、切块切得不好、没处理更新、盲信而不标出处、不衡量回答质量）。

等我们批准了计划，再从那时起才开始一步一步搭第 1 阶段，每完成一个能跑通的阶段就把进度存进 GitHub。

提示词 1 · 诊断 —— 我到底需不需要 RAG？

在搭任何东西之前，让你的 AI 先告诉你，你其实处在哪一级台阶。把它复制下来贴给 ChatGPT、Claude 或你的智能体：

我想搞清楚我是真的需要 RAG，还是在给自己找麻烦。请一个一个地问我这些问题，等我回答，最后告诉我我在哪一级台阶、为什么：

1. 我大概有多少份文档、每份多大？（总页数的粗略估算）
2. 那些信息是经常在变，还是稳定的？
3. 我需要它给每个回答标出处吗？
4. 这是只给我自己用，还是给一个很多人会用的应用？
5. 我今天用的是什么 AI 工具？

你给建议的规则：
- 如果我所有的材料能装进约 500 页（约 200.000 token），就告诉我我不需要 RAG：让我把全部贴进上下文里，更简单也更精准。
- 如果明显超过这个量，或者变化很大，或者是给很多用户用的，就推荐我用 RAG，并告诉我零代码路线（NotebookLM / Custom GPT）够不够，还是我需要开源方案。
- 别推着我搞过度工程。给我推荐能解决我情况的**最简单**那级台阶，并说明理由。

提示词 2 · 搭一个零代码、防瞎编的迷你 RAG

如果诊断结果是「对，用零代码 RAG」，这个提示词会引导你搭好它，尤其是验证它确实在读你的文档、没在瞎编：

我要搭一个零代码 RAG 来查询我的文档。用简单的语言一步一步引导我，假设我不会编程。

1. 根据我的情况在 NotebookLM（免费）和 ChatGPT 的 Custom GPT 之间给我推荐一个：我有[描述你的文档：多少份、什么类型、我会用来查什么]。
2. 告诉我创建空间、上传文档的确切步骤（连点击操作）。
3. 帮我拟好我要给它的指令，让它只用我文档里有的内容作答、标注出处，并在内容不在文档里时明确说「文档里没有」，而不是瞎编。
4. 给我 3 个测试问题，确认它确实在读我的文档（而不是靠泛泛的记忆作答）。
5. 告诉我怎么察觉它在瞎编，以及一旦发生该调整什么。

做得简单点。如果有些事只能我在网页上做，就用确切的点击操作告诉我。

典型错误（免得你踩坑）

下一级台阶 · 从一个零件到完整的大脑

RAG 是一个强大的零件，但它只是其中之一：它在你的文档里搜索。当你打造一个真正的应用时，那个应用还需要记住每一个用户，有时还要理解万物如何互相连接。这三样东西合在一起——RAG + 记忆 + 图谱——就构成了所谓的 brain，也就是你应用自己的大脑。那是下一篇资源，它会把你看到的一切汇聚起来。