什么是 RAG？检索增强生成的简单解释
RAG（检索增强生成）是一种让 AI 模型使用你自己的信息回答问题的方法。当有人提出问题时，你的应用会先在文档中搜索最相关的段落，然后把这些段落和问题一起交给模型。模型的回答基于这些文本，而不仅仅依赖它在训练期间碰巧学到的内容。
用 AI 构建应用时，RAG 为什么重要
大语言模型对世界的一般知识很丰富，却对你的业务一无所知：你的价格、政策、产品手册、上周的客服工单。它的训练数据也有截止时间，因此不了解最新的情况。即便如此，它仍可能给出自信、貌似合理但错误的答案。
解决这个问题大致有三种方式：
| 方法 | 作用 | 适用场景 |
|---|---|---|
| 把所有内容都放进提示词 | 每次提问都发送全部文档 | 文本量很小，比如几页 |
| RAG | 搜索文档，只发送相关部分 | 体量较大或持续变化的资料：帮助中心、手册、笔记 |
| 微调 | 用示例对模型进行额外训练 | 语气、格式以及重复性任务，而不是会变化的事实 |
现代模型可以接受很长的提示词，因此如果是一份简短的常见问题，第一种方式通常就够用。当你的文本多到不想每次都全部发送时，RAG 才有用武之地，因为你发送的每个字都会消耗费用和时间（参见大模型 API 如何收费）。
如果你正在构建“与我们的文档对话”的功能、客服助手或内部知识工具，几乎可以肯定你在构建某种形式的 RAG。
日常类比
想象一场开卷考试。如果学生必须凭记忆作答，他可能记错，或者干脆瞎猜。如果允许他先翻到正确的页面，读完再作答，他的答案就可靠得多，前提是他能找到正确的页面。
- 学生就是大语言模型。
- 教科书就是你的文档。
- 翻到正确的页面就是检索。
- 根据这些页面写出答案就是生成。
RAG 就是开卷版本。和考试一样，答案的质量很大程度上取决于是否找到了正确的页面。
RAG 的工作步骤
典型的 RAG 系统分为两个阶段。
准备文档（提前完成）：
- 收集原始资料：帮助文章、PDF、政策、产品数据。
- 分块：把长文档切分成较小的片段，通常每段几个段落，这样搜索时就可以只返回相关的部分。
- 嵌入每个片段：把它发送给嵌入模型，由其把文本转换为一个嵌入，也就是一长串能够表达语义的数字。意思相近的文本会得到相近的数字。
- 存储这些片段及其嵌入，放入一个可按相似度搜索的数据库中（通常称为向量数据库或向量索引）。
回答问题（每次都要执行）：
- 用同一个嵌入模型嵌入问题。
- 检索与问题的嵌入最接近的片段，例如前五名。
- 组装提示词：指令、检索到的片段以及问题。
- 生成：语言模型基于这些片段写出答案，理想情况下还会注明引用了哪些片段。
正是按语义搜索让这套机制行之有效：问“怎么把钱退回来”，即使两者没有一个相同的词，也能找到标题为“退款政策”的片段。
实例：健身房的帮助助手
假设一家健身房有 40 篇帮助文章，想在官网上放一个聊天助手。一位会员问：“我出差的时候能暂停会员资格吗？”
应用把问题嵌入，并检索出最接近的三个片段。其中一段写道：
Membership freeze: Members on monthly plans can freeze their
membership for up to 2 months per year. Request it at the front
desk or in the app at least 7 days before the freeze starts.
发送给模型的提示词大致如下：
You are the help assistant for Northside Gym.
Answer only from the sources below. If the answer isn't in them,
say you don't know and suggest contacting the front desk.
Mention which source you used.
[Source 1: Membership freeze] Members on monthly plans can freeze...
[Source 2: Cancelling your membership] ...
[Source 3: Guest passes] ...
Question: Can I pause my membership while I'm travelling?
模型回答：“可以。按月付费的会员每年最多可以冻结两个月的资格。请在冻结开始前至少 7 天到前台或在 App 中提出申请（来源：会员冻结）。”
这家健身房从未重新训练任何东西。当它修改冻结政策时，只需更新文章，应用重新嵌入该片段，下一次回答就会反映出新的规定。
关键术语
| 术语 | 含义 |
|---|---|
| LLM | 大语言模型，即负责写出答案的 AI。参见什么是 LLM。 |
| 嵌入（Embedding） | 表示一段文本含义的一串数字。 |
| 嵌入模型（Embedding model） | 用于生成嵌入的模型。通常与聊天模型分开，且便宜得多。 |
| 片段（Chunk） | 文档的一部分，大小适合单独检索。 |
| 向量数据库 / 向量搜索（Vector database / vector search） | 能找出嵌入相似的条目的存储方式。一些普通数据库也提供此功能，例如 Postgres 通过 pgvector 扩展实现。 |
| Top-k | 每次提问检索的片段数量。 |
| 混合搜索（Hybrid search） | 把语义搜索与普通关键词搜索结合起来，有助于匹配产品编号等精确词汇。 |
| 上下文窗口（Context window） | 模型在一次请求中能接受的文本量上限。 |
| 依据事实作答 / 引用（Grounding / citations） | 把答案与具体检索到的来源联系起来，并展示这些来源。 |
常见误解
- “RAG 会用我的数据训练模型。” 不会。模型本身没有任何改变，它只是在提问时多读了一些文本。
- “RAG 意味着不再有幻觉。” 它意味着幻觉更少。如果检索漏掉了正确的片段，或者答案根本不在你的文档中，模型仍可能瞎猜。应指示它说“我不知道”，并用你已知答案的问题进行测试。
- “我需要专门的向量数据库。” 通常不需要。对于数据量不大的情况，你已有数据库上的向量扩展，甚至普通的关键词搜索，往往就足够了。
- “片段越大越好。” 太大，会发送大量无关文本（成本更高，也更混乱）；太小，片段又会丢失使其有意义的上下文。需要根据实际情况不断调整。
- “把所有东西都上传就行。” 过时、重复或相互矛盾的文档会产生相互矛盾的答案。清理原始资料，往往是你能做的最大改进。
- “任何人都能看到任何文档。” 只有在你这样构建时才会如此。如果某些文档只对特定用户可见，搜索本身就必须按提问者的权限进行过滤，否则助手可能把一位客户的数据引述给另一位客户。
成本
RAG 功能通常有三项持续成本：嵌入你的文档（数量小，且大多只需一次）、嵌入每个问题（极少），以及语言模型调用（主要成本，并随发送的片段数量增长）。另外还有你数据库的存储费用。AI 服务商会把这些费用计入你自己的账户，因此请在服务商处设置消费上限。
可以向 AI 构建工具提出的要求
- “在构建 RAG 之前先检查：我们的内容是否少到可以直接放进提示词？”
- “把帮助文章切分成每段几个段落的片段，保留每个片段的标题和来源链接，并把嵌入存储在我们的数据库中。”
- “使用混合搜索，即语义加关键词，这样产品编号也能匹配。”
- “告诉模型只根据检索到的来源作答，不知道时要说明，并在每个答案下方展示来源。”
- “只搜索已登录用户有权查看的文档。”
- “每当文档被编辑时，自动重新嵌入。”
- “把 AI 服务商的密钥保存在服务器端的机密信息中，绝不放在浏览器里。”
- “记录每个问题、检索到的片段以及答案，方便我检查糟糕的回答。”
Mythex 中的 RAG
Mythex 不提供现成的知识库或 RAG 产品。它做的是在你的应用内部为其编写代码：你提供文档和自己的 AI 服务商密钥，密钥以项目机密的形式保存，由 Agent 构建检索与聊天部分，并使用项目的 Postgres 数据库进行存储。服务商的用量计入你的服务商账户，而不是 Mythex 积分。文档建议先从一个简单的 AI 功能开始，待其运行正常后再加入 RAG，参见构建 AI 应用，以及我们关于构建 AI 聊天机器人应用和为应用添加 AI 功能的指南。
常见问题
简单来说，什么是 RAG？
RAG（检索增强生成）是一种让 AI 模型基于你自己的信息作答的方法。在模型回复之前，你的应用会先在文档中搜索与问题最相关的段落，并把它们和问题一起放入提示词，因此答案基于这些文本，而不只依赖模型在训练时学到的内容。
RAG 会用我的数据训练 AI 吗？
不会。RAG 完全不改变模型本身。它只是在提出问题的那一刻查找相关文本，并把文本和问题一起交给模型。你更新了文档，下一次回答就能立即使用新版本。
RAG 和微调是一回事吗？
不是。微调是通过在示例上进一步训练来改变模型的行为，速度较慢，更适合调整风格或格式。RAG 则是在提问时给模型提供可以阅读的事实，更适合会变化的知识，或者必须准确引用的内容。
RAG 能消除 AI 的幻觉吗？
它能减少幻觉，但无法完全消除。如果搜索找错了段落，或者答案根本不在你的文档里，模型仍然可能猜测。设计良好的 RAG 应用会要求模型在不知道时直说，并展示所用的来源。