RAG与Reference，同为AI知识库却大不相同。本文用生活化类比拆解两者本质：RAG是自动搜索引擎，Reference是手动文件柜。通过退货政策案例，清晰对比工作流程与适用场景，帮你告别技术焦虑，做出明智选择。

最近，遇到一件挺”逗”的事：搭了十几个Skill，把references目录建得整整齐齐的我，突然被朋友问到”你用了RAG吗？”——当场愣住。

RAG、Reference、Obsidian……AI 圈到处都是”知识库”，但我愣是分不清它们到底有什么区别。

以前，做的大数据平台自称”知识库”，现在用的Obsidian也叫”知识库”——我特别想弄清楚它们之间到底是什么关系？

前两篇咱们聊了“Skill结构怎么搭”和“references的三种引用方式”，这一篇把搞懂这堆”名词”的过程原样分享——先把几个”知识库”对上号，然后知道在后面工作中怎么进行选择。

RAG 到底是什么？

一句话解释，RAG的本质就是四个字：先搜后答。

大模型平时回答靠训练时已存档的知识，相当于回答问题是”闭卷考试”模式；而RAG负责的就是允许它翻书——回答前先去资料库搜一遍，找到相关内容再作答，等于是把”闭卷考试”变成”开卷考试”。

它的工作流程可以压缩成是三个主要步骤，拿一份PDF举例给你看，就很好理解了：

▲ RAG 的基本工作流程：切片 · 检索 · 生成

1. 存进去—— 把一份50页的PDF切成无数”小块”（一页 3～5 块），整份PDF最后就一变成150～200张小卡片，每块编上”数字指纹”；
2. 搜出来—— 当你提问时，把问题跟所有”小块”比对，挑出最接近的几个；
3. 拼着答——AI拿这几个”小块”加你的问题，重新组织成”人话”回答给你。

比如拿一份《退货政策》PDF来进行示例：

首先，文件被存入时被切成”7天无理由退还””运费承担””特殊商品”等 200 来张小卡片；

然后，当你询问“退货运费是谁承担？”，系统比对后捞出”运费承担”那块；

最后，AI拿着它回答”7天无理由退货的情况下，运费由卖家承担……”。

所以，使用RAG技术的AI并没有读完这 50 页，只是检索到了最相关的那几块。

因此，RAG不是某个具体的软件或工具，它是一种”让AI带着参考资料回答问题”的技术方案，同时也存在它的局限性。

RAG = 先搜后答，让 AI 从”闭卷考试“变”开卷考试“。

Reference 呢？

你已经在做”手工版 RAG”了

如果RAG是让”算法”替你找资料，那Reference就是你用”人脑”干同样的事——手动分类资料、手动写检索规则。

▲ Reference 的核心：分类资料，再按规则调用

1. 分门别类—— 文件按主题拆，每个文件讲一类事，文件名就是标签；
2. AI自己找文件—— 它不算相似度，只翻你写好的”说明书”，你问哪类问题，它就按规则直达目标；
3. 照着回答—— 拿找到的内容加你的问题，生成最终回答。

还是拿《退货政策》PDF来说。看下面这个SKILL目录，已按公司惯用分类把 50 页拆成几个文件——退货流程.md、运费规则.md、特殊商品.md……

▲ 把《退货政策》按主题拆成多个文件

用户问”退货运费谁承担？”，AI翻你写好的说明书——”问运费，就读运费规则.md”。

那AI怎么知道该读哪个文件？这需要在SKILL中写好预设路径，让AI直达。截取部分引用策略，如下图：

▲ 通过用户意图，把问题路由到对应文件

AI通过用户意图直接读”运费规则.md”，再加你的问题生成回答。

就算客户反复问，只要文件不更新，答案就不变。”问退货运费就读运费规则.md”就是最典型的”明确指引”。

▲ Reference 的三种引用方式：明确指引、按规则直达

所以，Reference知识库没用向量数据库，也没有embedding，全靠”文件分类 + 索引规则”调用。

一个优秀的SKILL.md应该像个好领导：自己只管派活，专业知识放references/这个”资料柜”，用到哪份调哪份。

简单对比两者的话：RAG像”自动搜索引擎”，Reference像”你亲手做的文件柜”——每个抽屉贴好标签，要什么直接拉开。

但是，这里有个我绕了很久才想通的点：两者的分水岭，根本不是”数据量大小”——数据可来自本地文件，也可接 API 拿外部实时数据，这两件事Reference和RAG都能做到。

真正的区别只有一个：

Reference是人定规则、AI执行——每次读什么你说了算，是确定性的；RAG是AI根据提问实时判断——每次搜出什么看相似度，是概率性的。

所以像政策条款、设计规范这种”必须每次一致”的东西，我会毫不犹豫选Reference。Reference = 你手动做的 RAG，人定规则，AI 照着读。

那Reference够不够你用？先别急着学RAG，3 个问题自测：

• 知识库多大？几十个文件以内，Reference够用；
• 一人还是团队？一个人用，Reference够用；
• 要模糊搜索吗？文件分类已经很清楚，Reference够用。

四种”知识库”一张图看懂

搞懂了主线（RAG和Reference），这张表帮你顺手把另外两个也对上号——它们都叫”知识库”，但解决的是不同规模的问题。

这张表不用背，直接【保存】下来，需要时翻出来对照就行。

▲ 四种”知识库”形态对比一览

看着很复杂，本质它们干的都是“存知识 + 找知识”这一件事，只是规模和方式不同。一个生活类比：

• Reference是桌边亲手整理的文件柜；
• RAG是图书馆的自动检索系统；
• Obsidian是你家的书房；
• 大数据是国家级别的档案馆。

▲ 它们没有高下之分，只是规模和找法不同

当上一节那 3 个自检有任何一个答”否”，或者你开始有这些感觉时：

• 想不起资料放哪—— 自己都经常想不起某份资料在哪个文件里；
• 索引越写越长—— 光翻”目录”就要半天；
• 开始需要”模糊提问”—— “上次那个讲某某的内容在哪来着？”

你可能就要考虑深入RAG。但说实话，大多数人现在的阶段还用不着，但是还是要了解基本的概念才能做出明智的决策。

另外，说个容易被误会的点：在真实的企业系统里（比如智能客服），两者从来不是二选一，而是搭配用的：

场景：客户说”我要退款”

Reference 干什么?给出写死的合规骨架：必须先安抚情绪、不能承诺具体到账时间、退款理由必须录入系统

RAG 干什么?从几万份文档里捞出这个商品的具体退款政策，填进骨架里

最后

一句话让你减少技术学习焦虑：几十个文件以内，Reference 够用；等真装不下了，再考虑 RAG。

先用起来比什么都重要，遇到问题再深挖，这才是学习技术的正确姿势。

我认为真正的技术自信，不是学会更复杂的方案，而是敢于确认：我现在用的这个简单方案，就是对的。

写到这里，这个话题也连成一条线：第一篇聊结构怎么搭，第二篇聊知识库引用，这一篇聊知识库怎么选——就是我搭 Skill 最核心的三个新的，希望对你有用。