RAG：让 AI 基于你自己的数据作答，不用重新训练模型。
四步讲清机制、什么才真正决定回答的质量，以及两种「RAG 是错工具、而且会被很晚才发现」的情况。
一句话的答案。
RAG 就是模型在回答之前，先去查一个属于你的知识库。AWS 把它描述为：优化语言模型输出的一套做法，让它引用训练数据之外、可信的知识库。模型还是那个模型；变的是它下笔之前读了什么。
这个缩写出自 2020 年 Patrick Lewis 等人发表在 NeurIPS 上的一篇论文。那里的模型把两种记忆结合起来：参数化记忆，装在模型权重里；非参数化记忆，是一个当场查询的索引。今天所有的 RAG 实现，都是这个想法的变体。
对一家公司来说，直接的后果是：模型可以回答内部制度、合同、产品目录和历史记录，而这些东西一样都不用送进训练，也不用等模型的下一个版本。
四个步骤。
这是 AWS 描述的那个顺序，也是每一次提问真实发生的顺序。被最多项目忘掉的是第四步。
准备外部知识库
不在模型训练数据里的那些文档，被转换成数值表示，存进向量数据库。模型要查的就是这个库，而这个库是你的，不是模型供应商的。
检索出相关的部分
用户的问题同样变成数值表示，再和库里的内容比对。回来的是相似度计算上最接近的那些片段，不是关键词匹配的结果。
把提示词补全
检索到的片段和原始问题一起，构成发给模型的那个请求。模型对着这段上下文作答，而不是只靠训练时记住的东西作答。
更新这个库
文档和它的数值表示要自动或批量更新。少了这一步，系统会悄无声息地老去：它依然自信地回答，只不过回答的是旧版本的政策、旧版本的价格、旧版本的合同。
决定一切的那个问题：你索引的单位是什么？
在挑模型之前，先挑那个片段。如果被索引的单位是一刀切下来的一千个字符，检索回来的就是半句条款加上另一条的开头 —— 回答是错的，样子却完全是对的。
按意义切，别按长度切
一条条款、一个章节、一个商品条目、一次工单回复。这个单位必须是一个人会整段引用的东西，而不是一个固定字数。
来源要贴在片段上
文档、版本、页码和日期跟着片段一起走。没有这些，回答就没法说明自己从哪儿来，事后也没人审得了。
权限在检索这一步生效
谁能看什么，在片段送到模型之前就筛掉。拜托模型「别说出去」，是一种建立在善意之上的访问控制。
一组真实的问题
三十个业务上真的会问的问题，每个旁边写好正确答案。它把「感觉变好了」变成一个数字，而这件事几乎没人在动手前做。
RAG 什么时候管用，什么时候不管用。
这套模式对一类问题很好，对另一类很糟。提前分清楚，能省下一个季度。
- 答案确实写在公司某份文档里，但没人找得到那份文档。
- 每周都在变、等不了模型下一个版本的那些知识。
- 客服需要引用现行制度，并且把用到的那段原文摆出来。
- 初审：读一大堆东西，指出人该先看哪一件。
- 数字。余额、价格、评分和工期来自确定性且有测试的计算，模型只写数字周围的文字。
- 依赖实时状态的答案 —— 现在的库存、现在的订单位置。那是调用系统，不是检索文档。
- 没人维护的知识库。源文档过期了，RAG 只会把错误答得更快、更笃定。
- 同样输入必须永远给同样结果的决定。规则就是规则：把它写成规则。
关于 RAG 的问题。
RAG 是什么？
AWS 的定义是：RAG 是优化语言模型输出的一套做法，让它在生成回答之前，先去查一个训练数据之外、可信的知识库。这个词出自 Lewis 等人 2020 年在 NeurIPS 上发表的论文，那篇论文描述的模型把训练得到的参数化记忆，和从索引里检索出来的非参数化记忆结合在一起。
RAG 和「用我的数据训练模型」是一回事吗？
不是。训练改变的是模型的权重；RAG 不动模型，换的是它去查的那个库。AWS 把成本列为首选 RAG 的主要理由：用一家机构的专有信息去重新训练一个基础模型，算力和资金开销都很高，而 RAG 引入新数据不需要这些。
RAG 能消除幻觉吗？
能减少，不能消除。模型开始对着一段你控制的上下文作答，这砍掉了「因为不知道所以编」的那一类错误。它仍然可能误读检索回来的片段 —— 所以回答必须把来源摆出来，让人一点就能核对。
决定一套 RAG 系统好坏的是什么？
几乎总是检索这一环。对的那段没从库里回来，再好的模型也救不了这个回答。真正拨动这根指针的是：被索引的片段切多大、怎么切，什么进了库，以及什么多久更新一次 —— 这里面没有一项是选模型。
什么时候 RAG 是错的工具？
当答案是一个算出来的数，而不是一段文字的时候。余额、价格、评分和工期都该来自确定性且有测试的计算；模型写的是数字周围的文字，永远不是数字本身。另一种情况是每个人能看到的库内容不一样：那时权限必须在检索这一步就生效，而不是去拜托模型别说。
做 RAG 一定要向量数据库吗？
你需要的是某种能把对的片段捞回来的办法。向量数据库是最常见的实现，因为它比的是语义，不是字面。库不大、结构又好的时候，一个做扎实的传统检索就够用，而且运维起来更便宜。
资料来源
定义和这四个步骤来自 AWS 的页面；这个术语的出处来自那篇原始论文。两份资料都在 2026 年 8 月 9 日打开核对过。其余内容是落地实践，文中也是按实践在讲，不作为可引用的事实。