想象一位 AI 工程师正在为公司构建一个简单的内部支持聊天机器人。她用 GPT-5.1 这个现成的大语言模型（LLM），花了一个下午就做出了原型。早期效果看起来很惊艳：模型对话流畅，能总结长文档，甚至还能起草代码。但一旦他们问到需要基于公司自身系统的问题——比如“明年一月之后退款政策会是什么？”或者“本周哪些客户账户被标记为需要跟进？”——答案就开始崩坏。模型会自信地返回一段听起来合理、但和公司真实数据毫无关系的文本。有时它会编造已经过时的政策。有时它会给出完全荒唐的内容。核心问题并不在于模型不会表达，而在于它“看不见”。
这正是即便最先进的 LLM 也存在的根本限制。它们是在海量语料上训练出来的——包括书籍、文章、代码仓库和公开网页内容——这赋予了它们广泛、通用的语言理解能力，也让它们能够完成许多并未被显式训练过的任务。但无论训练数据集有多大，它都不可能包含某家公司的私有文档、内部知识库，或者某个小众库上周刚刚发布的更新。因此，只要任务需要训练窗口之外的信息，LLM 就可能给出措辞漂亮但事实错误的答案。这类错误通常表现为幻觉：生成的内容流畅、自信，却完全没有任何真实数据支撑。
扩大训练集规模并不是一个可行解。世界上的信息——公开的、私有的、结构化的、非结构化的、稳定的，以及持续变化的——不可能被一次性捕获、清洗并整合进某一次训练过程中。任何模型在训练结束的那一刻，都注定是不完整的，并且已经略微过时。
这就是检索增强生成出现的原因。RAG 并不是期待一个静态模型“知道”一切，而是让它能够动态拉取自己原本缺失的相关事实。在前面那位 AI 工程师的聊天机器人中，加入 RAG 后，模型就可以在用户提问的那一刻，获取准确的 wiki 页面、政策文档或支持工单历史。随后，LLM 再利用自己的生成能力，基于这些被检索出来的材料综合生成最终答案。这样得到的系统更加准确、更加可靠，也更不容易产生幻觉——因为它终于拥有了回答问题所需的信息。
本书关注的正是这种转变：从只依赖预训练知识的 LLM，走向能够通过检索，对私有的、领域特定的、持续更新的数据进行推理的系统。RAG 不只是一个技术增强项；它是让生成式 AI 在真实应用中真正有用的关键。
RAG 是如何工作的？
如图 1-1 所示，一次 RAG 查询包含两个步骤：R（retrieval，检索）和 G（generation，生成）。当用户向 RAG 系统发起查询时，“R”步骤会首先启动，检索出与查询最相关的信息。随后进入“G”步骤，也就是让大语言模型分析被检索出来的信息和用户查询，并基于检索到的事实，为该查询生成一个合适的回答。
图 1-1 展示了基础 RAG 架构：先检索数据，再使用语言模型生成回答。
图 1-1 基础 RAG 架构
这里有一个简单例子。假设我们正在构建一个 RAG 聊天机器人，用来回答医学问题。这个聊天机器人基于一个私有数据源，这个数据源包含医学书籍和期刊论文。
现在，考虑如下查询：“糖尿病有哪些有效治疗方法？”
在这个例子中，RAG 查询流程如下：
R（检索）步骤： 系统搜索私有数据并检索相关文档。在这个例子里，它会找到专门讨论糖尿病治疗的段落。
G（生成）步骤： 随后，LLM 接收原始查询和被检索到的事实。它只使用这些被检索出来的信息来综合生成答案。
“retrieval-augmented generation”中的“augmented”一词，意味着被检索出来的信息会被加入到 LLM 的提示词中用于生成；从这个意义上说，它用额外事实增强了模型的内部知识。
下面是一个非常基础的 RAG 提示词结构：
You are an assistant for question-answering tasks. Use the following pieces of
retrieved context to answer the question. If you don't know the answer, just say
that you don't know.
<question>
{question}
</question>
<context>
{context}
</context>
Answer:
这里，变量 question 会被替换为实际的问题字符串，而 context 是一组事实列表，其中每个事实都是一个字符串。因此，我们是在让 LLM 执行一个问答任务：查看被检索出来的事实（context），并使用 context 中提供的信息和事实来回答用户查询。
从很多角度看，纯 LLM 使用方式和 RAG 的区别，类似于闭卷考试和开卷考试的区别。
在闭卷考试中，学生只能依靠自己的记忆和理解。教材、笔记或其他参考资料都不允许使用。类似地，纯 LLM 使用方式意味着你得到的所有信息，都只基于 LLM 训练期间所包含的数据集。这类知识存储在 LLM 的参数中，也称为权重。LLM 本质上是一个人工神经网络，其行为由权重的数值决定，因此这类知识也被称为参数化知识。
相比之下，在开卷考试中，学生可以在考试期间查阅教材、笔记或其他被允许的材料。这种设置使他们在需要时能够回到详细信息中查证，而这正是 RAG 的工作方式——检索步骤会实时向 LLM 提供额外信息。
有了这些基础认识之后，我们现在可以更深入一层，理解 RAG 需要哪些组件，以及摄取流程和查询流程是如何工作的。
RAG 技术栈的蓝图
让我们更详细地看一下 RAG 是如何工作的，尤其是 RAG 技术栈中的各种组件。图 1-2 描绘了 RAG 的两条主要流程：摄取流程和查询流程。
图 1-2 展示了 RAG 技术栈的摄取流程和查询流程，包括数据抽取与索引过程，以及查询如何经过嵌入、向量存储、混合搜索、重排序、生成式 LLM 和幻觉检测等环节。
图 1-2 RAG 技术栈
摄取流程负责执行必要功能，将数据从源头中抽取出来，例如数据库、S3 上的一组 PDF 文件、Notion 中的文本等，并将其索引进 RAG 技术栈。
查询流程则负责对用户查询进行完整处理——它检索正确的事实，并使用 LLM 进行生成，最终形成返回给终端用户的响应。下面我们更详细地看一下这两条流程。
摄取流程
在数据摄取期间，RAG 系统首先会把输入数据，也就是后续用于回答用户查询的数据，转换成多种适合查询匹配的格式。这些格式包括但不限于向量嵌入，向量嵌入用于表示文本的语义含义。随后，这些向量嵌入会被存储在一种特殊数据库中，称为向量数据库，或 vector DB。与每个向量一起存储的，还有实际文本，因为查询时处理仍然需要这些文本。将数据转换为向量的步骤通常被称为索引或嵌入。
生产级摄取流水线可能相当复杂——我们将在第 2、3 和 8 章中介绍其中涉及的一些挑战，例如文档预处理、切分、嵌入、数据校验、多模态输入处理，以及增量更新。
注意
在 RAG 领域，index、dataset 或 corpus 这几个词在某种程度上会被交替使用，用来指代被摄取进 RAG 的数据。如果要更精确一些，dataset（或 document set）只是你一开始拥有的原始源文件集合；corpus 是经过整理、清洗和组织后的内容主体；而 index 则是从 corpus 构建出来的高性能数据结构，经过优化以支持快速搜索和检索。
查询流程
查询流程执行两个操作：检索和生成。
检索从把用户查询转换成嵌入向量开始，然后向量数据库会在查询嵌入和向量数据库中所有可能匹配的文本（也就是事实）之间执行相似度搜索。
使用嵌入来查找信息被称为语义搜索。通过在嵌入向量空间中应用相似度搜索——这个空间是人类无法直接理解的——我们可以在语义层面，将查询中的意图与相关文本文件匹配起来。正如我们将在本书后面看到的，尤其是在第 2 章和第 3 章中，语义搜索只是检索的一种基础形式，在生产部署中，它通常不足以支撑高质量的 RAG 响应。另一种基础检索形式是词法搜索，它根据文本在书写形式上的相似性来匹配文本。实际中，经常会使用混合搜索，也就是把语义搜索和词法搜索结合起来，或者使用重排序等高级技术。理想情况下，被检索出来的文本片段应当包含与回答用户查询高度相关的事实。
一旦我们得到相关事实，生成步骤就会继续：RAG 查询流程会构造一个专用提示词模板，就像我们在“RAG 是如何工作的？”中看到的那样，用来指导 LLM 如何基于检索结果中的信息生成对用户查询的回答。
重要的是，优秀的 RAG 流水线通常会要求 LLM 生成引用或引文，这样响应中不仅包含答案文本本身，还会指向该回答所依据的知识来源。
尽管我们已经到了可以生成响应的阶段，甚至可能带有引用，但事情还没有结束！
在 LLM 返回响应之后，一个典型的 RAG 查询流程还会应用护栏，确保响应达到预期质量标准。其中最重要的是幻觉检测——也就是验证 LLM 确实使用了提供给它的事实，并生成了与这些事实一致的响应。换句话说，我们要检查 LLM 没有编造内容。其他类型的护栏还包括检测偏见、有毒或有害回答，或者其他不允许的内容，后续我们将在第 3 章中看到。
这就是 RAG 摄取流程和查询流程在高层次上的工作方式。
在实践中，当你从第一个概念验证走向一个任务关键型 RAG 应用的生产部署时，事情会变得更加复杂，你需要思考如何处理额外挑战：
如何不仅使用向量搜索，还使用混合搜索、重排序或其他更高级的检索技术来优化响应质量？
如何把表格、图片、流程图和其他多模态数据中的信息纳入 RAG 流水线，同时保持高准确率？
如何衡量 RAG 流水线的质量——包括检索、生成、幻觉和引用——不仅在首次部署时衡量，还要在后续升级和改进 RAG 流水线的过程中持续衡量？
如何扩展 RAG，让它使用知识图谱，或将其集成到 agentic workflow 中？这些内容将在“Agentic RAG”和“RAG with Knowledge Graphs”两个小节，以及第 9 章中讨论。
重要的是，在生产规模下，设计和实现一条 RAG 流水线，需要一套强健的 DevOps 最佳实践。在 LLM 的新时代，这也常被称为 MLOps 或 LLMOps，用来确保低延迟、高可用和强安全性。这包括以下内容：
RAG 的持续集成和持续交付（CI/CD）
自动化数据刷新
实现事件驱动的抽取、转换、加载（ETL）流程。每当源数据更新时，该流程会自动触发文档摄取更新，包括切分、嵌入，以及索引进 RAG 知识库。
自动化评估
将自动化 RAG 评估集成到 CI/CD 流水线中。这可以防止部署会降低响应质量的新模型、新提示词或数据变更。
提示词和模型控制
将提示词视为像代码一样需要版本控制的工件，并对所有组件进行版本管理，例如嵌入模型、切分逻辑和 LLM，以确保可复现性，并支持安全回滚。
可观测性和监控
使用可观测性工具追踪单个请求在 RAG 流水线中的流动过程，以便调试“糟糕”的响应。
追踪每个组件的具体性能和成本：摄取、检索、使用 LLM 生成，例如 token 使用量，以及每次查询的整体成本。
性能与可扩展性
数据库优化
对 RAG 技术栈中包含的任何数据库实施高效索引策略、分片或缓存，包括向量数据库、如果包含的话还包括图数据库，以及在实现混合搜索时使用的词典。
优化推理
为嵌入、重排序和 LLM 生成使用专用的、可自动扩缩容的推理端点，例如使用 vLLM，本书第 4 章“软件或硬件加速”一节会讨论，或者使用预置吞吐量。
安全与治理
以数据为中心的访问控制
在数据层面应用细粒度、基于角色的访问控制（RBAC），确保 RAG 流水线只检索并呈现特定用户有权限查看的文档。
静态和传输中的加密
使用强加密标准，对所有数据存储以及任何 API 通信进行加密。
提示词和输出净化
实施严格的输入校验，以缓解提示词注入攻击；同时对输出进行过滤，在敏感数据到达用户之前扫描并遮蔽 PII 或其他敏感数据。
随着本书章节推进，我们会逐一处理这些挑战，并提供应对策略。
示例：使用 LangChain 构建 RAG
下面展示一个快速示例，说明如何用 LangChain 构建一个简单的 RAG 流水线。该流水线基于刘易斯·卡罗尔的《爱丽丝梦游仙境》（Alice’s Adventures in Wonderland），此版本由 VolumeOne Publishing 出版。
我们从摄取开始，步骤如下：
下载 PDF 文件并解析为文本。
将整本书的完整文本切分成块。
计算向量嵌入，并将生成的向量和文本块存储到向量数据库 LanceDB 中。
from langchain_community.document_loaders import PyPDFLoader
from langchain_text_splitters import RecursiveCharacterTextSplitter
from langchain_openai import OpenAIEmbeddings, ChatOpenAI
from langchain_community.vectorstores import LanceDB
from langchain_core.prompts import ChatPromptTemplate
from langchain_core.output_parsers import StrOutputParser
from langchain_core.runnables import RunnablePassthrough
pdf_url = "https://www.adobe.com/be_en/active-use/pdf/Alice_in_Wonderland.pdf"
loader = PyPDFLoader(pdf_url)
pages = loader.load()
text_splitter = RecursiveCharacterTextSplitter(
chunk_size=1000,
chunk_overlap=200,
length_function=len,
)
chunks = text_splitter.split_documents(pages)
embeddings = OpenAIEmbeddings(model="text-embedding-3-small")
vectorstore = LanceDB.from_documents(chunks, embeddings)
现在，我们使用 LangChain 创建 RAG 流水线。首先，我们定义一个 llm 对象，在这个例子中使用 GPT-4o mini；然后定义一个 retriever，用来从 LanceDB 向量存储中检索最相关的前三个结果，也就是文本块。随后，RAG “chain”由三个步骤组成：
把文本块收集为“context”，然后使用 format_docs() 函数格式化这些文本块。
将文本块和问题整合进提示词。
调用 llm。
格式化输出：
llm = ChatOpenAI(model="gpt-4o-mini", temperature=0)
retriever = vectorstore.as_retriever(search_kwargs={"k": 3})
def format_docs(docs):
return "\n\n".join(doc.page_content for doc in docs)
prompt = ChatPromptTemplate.from_template(
"""Answer the question based only on the following context:
{context}
Question: {question}"""
)
rag_chain = (
{"context": retriever | format_docs, "question": RunnablePassthrough()}
| prompt
| llm
| StrOutputParser()
)
好了，现在我们试一个查询：
Query = "Describe the Mad Hatter's tea party."
answer = rag_chain.invoke(q)
print(answer)
我们得到的输出是：
The Mad Hatter's tea party is a chaotic and nonsensical gathering set under a
tree, where the March Hare, the Hatter, and a Dormouse are present. The table is
large but crowded, with the three characters sitting closely together at one
corner. The Dormouse is asleep, and the other two use it as a cushion while they
converse over its head. The atmosphere is filled with absurdity, as the March
Hare offers Alice wine that isn't actually there, leading to a confrontation
about manners. The Hatter makes a personal remark about Alice's hair, which she
finds rude, and the conversation is marked by a lack of civility and logic.
Alice, feeling frustrated and insulted, eventually leaves the tea party,
declaring it the stupidest she has ever attended. The scene is characterized by
whimsical elements, such as the peculiar house of the March Hare, which has
chimneys shaped like ears and a fur thatched roof. Overall, the tea party
embodies the surreal and illogical nature of Wonderland.
疯帽子的茶会是一场混乱而荒诞的聚会，发生在一棵树下，三月兔、帽匠和一只睡鼠都在场。桌子很大，却显得拥挤，这三个角色紧挨着坐在桌子一角。睡鼠睡着了，另外两人把它当作垫子，同时隔着它的头交谈。整个氛围充满荒诞感，比如三月兔向爱丽丝提供其实并不存在的酒，由此引发了一场关于礼貌的冲突。帽匠对爱丽丝的头发发表了个人评价，这让她觉得很无礼，而整段对话都缺乏礼貌和逻辑。爱丽丝感到沮丧又受辱，最终离开了茶会，并宣称这是她参加过的最愚蠢的茶会。这个场景充满奇幻元素，比如三月兔那座奇特的房子，烟囱形状像耳朵，屋顶则像用毛皮铺成。总体来说，这场茶会体现了仙境超现实、非逻辑的本质。
这是 RAG 最基础的形式——用一个简单示例上手其实相当容易。本书后续内容将持续扩展这个示例，从而更好地理解如何把 RAG 从简单的概念验证推进到生产环境。
在进入第 2 章的 RAG 技术组件之前，我们先牢牢建立一个问题：为什么 RAG 重要，以及它和其他方法相比有什么不同。本章剩余部分将讨论这些内容——RAG 的优势、使用场景，以及什么时候选择 RAG 是合理的。
RAG 与其他方法的对比
当你刚进入 LLM 和 RAG 的世界时，会看到不少方法在功能上至少看起来和 RAG 很相似，但它们往往有明显缺点，或者过于简单，无法支撑真实世界中生产规模的使用场景。
下面，我们更详细地讨论其中一些替代方法。
RAG 与“和 PDF 聊天”
你可能会发现，RAG 看起来类似于“和 PDF 聊天”——这类应用会基于一组文档回答用户查询。
虽然完全可以用 RAG 来实现一个“和 PDF 聊天”的应用，但大多数“和 PDF 聊天”应用采用的是如下简单方法，尽管这种方法不可扩展：它们把 PDF 文件的全文放进 LLM 提示词中，后面再接上问题。对于较小的 PDF 文件，这种方法是可行的，因为现代 LLM 现在已经支持 256K 甚至 1M token 的上下文长度。事实上，你甚至可能把几十个或几百个 PDF 文件塞进这么大的上下文窗口中。然而，这显然无法扩展到企业应用场景，因为企业中通常有数十万份可用文档，即便上下文窗口非常大也不够。
还有一些其他限制值得考虑。
第一是成本：运行 LLM 很昂贵。把所有文档都喂给 LLM，也意味着你会把与查询无关的信息一并喂给 LLM，这是一种浪费。相比之下，RAG 会有选择地把相关信息提供给 LLM，因此更便宜、更快速，并且可以扩展到任意规模。
第二是延迟：即使某些 LLM 能处理很长的序列长度，也可能需要一段时间来处理，从而导致高延迟和令人沮丧的用户体验。
第三是文档选择：想象一个企业应用，我们只是想得到一个问题的答案，而这个答案需要基于 Google Drive、Notion、SharePoint，以及 S3 上一组 PDF 文件中的文档。使用“和 PDF 聊天”时，仍然必须有人识别哪些文档是相关的，然后像前面提到的那样把这些文档喂给 LLM。于是我们又回到了检索问题上，它开始看起来和 RAG 几乎一模一样。
RAG 与微调
使用私有数据利用 LLM 的开发者，通常会考虑使用微调，让模型适应自己的特定领域。这个过程包括拿一个通用的预训练 LLM，在私有数据上“继续”训练它。这种额外训练通常运行几个 epoch，会调整模型的内部参数，使它的知识、术语和响应风格专门适配新数据。
那么，微调面临哪些挑战？
专业能力缺口
首先也是最重要的一点，微调是一项困难任务。它需要仔细准备数据，也需要深厚的深度学习专业能力，以避免一些问题，例如过拟合、LLM 通用能力退化、无意中把新数据中的偏见引入模型，或者增加 AI 安全风险。
注意
大多数现代 LLM 在最初的大规模“预训练”之后，还会经历继续训练，包括监督微调（SFT）和基于人类反馈的强化学习（RLHF）等技术。前沿实验室的研究人员会尝试在所有这些任务之间平衡模型能力。这里所说的微调，可能会逆转或干扰这些后训练机制；如果不格外谨慎，它可能导致模型在多个维度上出现退化。
即便你的团队拥有所需水平的深度学习专业能力，你的数据也可能不够大，或者不够干净，无法支撑有效微调。
微调成本
除了专业能力缺口之外，微调往往也相当昂贵，主要体现在 GPU 成本上。你还必须问自己：我需要多频繁地微调？如果你的数据集是静态的，那问题不大——微调一次就可以了。但在大多数真实企业场景中，数据通常会频繁更新——你会每天微调一次吗？每周一次吗？这不太可能是一个具有成本效益的方案。
访问控制与权限
RAG 方法另一个经常被忽视、但非常重要的优势，是访问控制。想象你有一个数据集，其中包含多个部门的文档：工程、人力资源、财务和法务。如果你试图使用微调，那么实际上你会把所有这些数据都整合进模型权重里。
现在，如果公司某位员工提出一个问题，而微调后的 LLM 基于本应只对 CEO 或 HR 部门开放的机密信息作出了回答，会发生什么？在微调中，信息变成了一个单一的“团块”，你无法把 CEO 可见的文档和全体员工都可见的文档区分开来。
我们喜欢把这称为博格效应：“我们是博格。抵抗是徒劳的。”就像《星际迷航》中的博格会把个体、文化和技术同化或整合进集体一样，微调会把所有训练过的知识整合进模型权重中，使得数据分段和访问控制难以维持。这可能导致敏感数据在部门之间被意外暴露，也是大多数企业关心的安全问题。
当然，你可能会考虑针对每个用户群体或部门可访问的数据，分别微调不同的 LLM。但这会导致多个 LLM 都需要被微调，并且每个模型都需要单独托管。这不仅资源密集，还需要查询路由机制来确保每种情况下访问的是目标模型。总体来说，这种方法不可扩展，而且很快会增加成本和复杂度。
相比之下，使用 RAG 时，你可以轻松地在检索步骤中实现访问控制：只需在数据存储中添加基于权限的元数据字段，并在查询时使用过滤条件即可。详见“RAG 的关键优势”。
注意
没有什么会阻止你在 RAG 技术栈中使用经过微调的 LLM。如果你有大量内部数据，认为对其进行微调会带来显著收益，并且你的团队具备在这些数据上正确微调 LLM 的专业能力，同时也有能力托管它，让它在你的 RAG 流水线中使用——那么，你完全可以在 RAG 的生成步骤中使用这个微调后的 LLM，而不是标准 LLM。
总结来说，“和 PDF 聊天”和微调在某些场景下都是有效方法，但在企业级部署方面存在明显限制。现在，与其继续比较其他方法，不如强调 RAG 的关键优势，以及它为什么非常适合任务关键型、大规模企业应用。
RAG 的关键优势
既然你已经理解了 RAG 与其他潜在方法的比较，下面我们更详细地讨论 RAG 本身的主要优势。
RAG 具备可扩展性和效率
RAG 是一种高效方法，可以让生成式 AI 应用基于私有数据集进行事实锚定，并且能够轻松扩展到数十万、数百万，甚至更多文档。
让这一点成为可能的，是 RAG 核心中的检索引擎。搜索本身是一个困难问题，几十年来一直有大量研究，因此有很多方法可以被用于 RAG。而且我们知道，搜索，也就是 RAG，提供了一条随文档数量扩展的路径——这是单独 LLM 无法做到的，因为 LLM 的自注意力机制由于使用了如今著名的 self-attention，其复杂度会随着序列长度呈二次方增长。
不过需要注意，虽然检索算法本身可以高效扩展，现代索引通常甚至可以实现次线性扩展，但生产环境中整个系统的真实可扩展性，往往取决于工程瓶颈，包括数据库并发或网络延迟。
RAG 有助于减少幻觉
幻觉描述的是这样一种情况：LLM 生成的内容既没有被自身的世界知识支持，也没有被提供给提示词的信息支持。
由于设计方式不同，相比以闭卷方式直接询问 LLM，RAG 有助于减少幻觉。原因是：我们会向 LLM 提供一组从源数据集中检索出来、与用户查询相关的事实；如果系统构建得当，它会使用这些事实来给出一个好的回答。
当相关事实不可用时，大多数 RAG 应用都会被指示直接回答“我不知道”。相比之下，LLM 几乎总会基于自己的训练集给出某种回答；如果它没有相关信息，在很多情况下，它会编造内容。
RAG 支持可解释性
RAG 使用被检索出来的信息来回答用户查询，因此一种常见实践是：如果需要，就在 RAG 流水线生成的每个句子末尾加入引用，例如“[3,5]”。这些引用让用户能够验证主张，从而提升用户信任；同时也让用户能够更好地区分幻觉和坏数据。幻觉指模型编造了内容，而坏数据则是指被检索出的文档本身包含错误信息。
RAG 应用中的 LLM 还可以通过合适的提示词进一步被要求解释它是如何处理检索信息、并通过推理得出答案的。当 LLM 仅使用参数化知识，也就是从训练集中提取出的知识来回答问题时，这种高可解释性是无法匹敌的，因为几乎不可能从神经网络权重中重构出来源。
近乎即时地添加和移除知识
RAG 中，LLM 生成响应的质量取决于被检索数据的质量和相关性，而这些检索数据会被喂给 LLM。由于这些被检索数据存储在 LLM 外部的系统中，因此可以通过传统 ETL 方法轻松更新。这意味着，LLM 可访问的知识可以被定期轻松更新。
LLM 不会记住给过它的知识。它只需要在查询时检索到正确事实。
将这一点与使用前沿模型或微调模型对比：如果想要整合新数据，或者移除、更新已有数据，就需要重新训练——这在实践中几乎不可能做到。虽然我们也注意到，关于机器遗忘的学术研究未来可能有助于解决这一挑战。
访问控制与安全
使用 RAG 时，你可以通过在摄取期间向文档添加权限信息，例如作为元数据，来实现访问控制。这样，查询流程就可以根据权限包含或排除特定文档。
正确支持访问控制，往往是企业级 RAG 应用中的关键要求。它可以防止用户无权查看的数据泄漏到 RAG 响应中。
RAG 提供了对企业应用非常有吸引力的能力，尤其适合那些需要严格访问控制和强安全性的组织；更重要的是，它适合那些重视响应质量和减少幻觉的组织。
下面，我们来看一些具体的企业 RAG 使用场景。
RAG 使用场景
RAG 能够在利用 LLM 能力的同时，用私有数据对其进行增强。因此，它几乎适用于企业内部会使用 LLM 的任何场景，因为大多数企业应用都需要访问自己的私有数据。
这并不是说 ChatGPT、Claude 或 Gemini 作为员工独立使用的工具没有价值——它们当然有价值。它们可以有效提升个人生产力：用于编码、市场营销，或其他需要通用世界知识的任务，以及许多其他用途。
但只要某个应用需要 LLM 访问内部数据，RAG 通常就是最佳选择。
下面我们回顾一些常见的企业级 RAG 使用场景。
虚拟助手和 AI 聊天机器人
虚拟助手和聊天机器人可以作为客户交互的第一线。它们既可以作为外部工具，直接与客户交互；也可以作为内部工具，支持客服人员工作。
这里有一个简化例子。在航空公司中，客服人员可以使用虚拟助手帮助完成日常任务，例如在电话中与客户交谈时，回答他们可能遇到的常见问题。另一个聊天机器人则可以被部署到外部，直接为航空公司的客户提供服务，回答他们的各种问题。
在这个使用场景中，通常会让 RAG 应用指向相关内部知识库，例如过去的客户支持日志、航空公司 FAQ 或网站信息，以及围绕公司政策的其他内部文档。
以这种方式部署虚拟助手，通常会对客服指标产生积极影响，帮助显著缩短响应时间，减少支持工单总量，并提高首次联系解决率。该技术确保每次交互都基于最新、最完整的数据，从而提升整体客户体验。
聊天机器人和虚拟助手能够服务的应用数量非常庞大。只要你有一个合适的数据集，能够封装你希望助手基于其作答的知识，就可以简单地将 RAG 应用指向该数据集，并部署一个虚拟助手。
作为这个常见使用场景的另一个例子，我们来看教育。大学和学校可以部署聊天机器人，帮助回答学生问题。让每个学生在任何时间都能接触到老师或导师，几乎是不可能的。但通过用 RAG 构建的 AI 助手，我们可以为每个学生提供一位随时随地、覆盖任何科目的老师。只需把 RAG 系统连接到老师授权或创建的课程材料，例如教材或笔记，助手就能够在这些资源范围内回答学生问题。
图 1-3 展示了一个由 RAG 驱动的智能辅导和自适应学习平台。首先，课程材料被送入摄取服务器，这个服务器会处理这些材料，并将它们存储进向量数据库。随后，agent 可以通过聊天与学生互动，既可以作为导师，也可以作为考官。在导师模式下，学生提出问题，agent 给出回答。对于学生提出的每一个问题，agent 都会调动它的 LLM 并查询向量数据库，以生成答案。在考官模式下，它会主动为学生生成问题，并为学生的回答评分。它甚至可以基于需要改进的领域生成新问题，以强化学生对所选知识的理解。
图 1-3 展示了一个 RAG 驱动的智能辅导和自适应学习平台，展示了从课程材料到摄取、与学生互动，以及导师和考官角色之间的流程。
图 1-3 RAG 驱动的智能辅导和自适应学习平台
企业知识管理和内部搜索
在企业环境中，员工经常面临一个挑战：如何在庞大且多样的数据源中找到正确的信息。尤其是企业数据通常存储在多个系统中，例如 Google Drive 文件、Notion、Salesforce、HubSpot、Jira、Confluence 等。
RAG 通过结合检索和 LLM，使企业搜索现代化。检索是传统企业搜索系统中常见的能力，而 LLM 则增加了生成、信息处理和推理能力。通过将所有相关企业数据源摄取进 RAG 应用，当员工提交查询时——无论是关于政策细节、历史会议文档，还是技术规范——系统都会提取最相关内容，然后生成清晰的响应。
这个过程替代了传统方式：用户通常需要查看搜索结果前 10 条，逐一阅读这些文档，然后在脑海中尝试形成一个连贯且准确的答案。这个传统过程往往耗时很长。
使用这种方法的公司会获得多方面收益。员工节省了原本要花在大量文档筛选上的时间，也避免遗漏关键信息。这种效率提升会提高整体生产力，并让团队把精力集中在更高价值的任务上，而不是行政式搜索上。
通过持续保持数据源刷新和更新，基于 RAG 的知识管理系统可以跟上组织内部快速变化的节奏。
自动化内容创作和文档摘要
企业中的内容创作非常常见，包括生成内部报告、撰写营销文章或博客文章等任务。这类任务通常需要细致研究和事实核查。
RAG 提供了一个强有力的方案，可以自动化创作过程。当被要求生成内容时，RAG 系统会从多个来源检索最新的相关数据，并使用这些数据产出结构良好的草稿或摘要，必要时再由人类审核。这可以显著减少人工研究所需的时间和精力，并且通常会产出更准确的内容。
这种积极影响也延伸到品牌声誉层面。凭借准确且及时生成的内容，公司可以在所有渠道上保持一致且权威的声音。这种响应速度和可靠性，相比那些耗时更长、还要与其他优先事项竞争资源，并且可能产出不够准确成果的传统流程，可以成为一个重要竞争优势。
生成有吸引力且有效的个性化广告
广告需要有吸引力，也需要有效。传统上，同一个广告会投放给所有目标受众，而不会考虑用户正在网上做什么，或者正在谈论什么。使用 RAG，我们可以生成更及时、更加个性化的信息广告，让广告因人而异，并可能更加有效。
图 1-4 描绘了一个由 RAG 驱动的系统，它可以基于用户上下文即时生成有说服力的广告，例如用户曾经或正在聊什么、看什么、浏览什么。举例来说，如果用户正在聊跑步，那么与跑步或运动相关的产品会从预先摄取的向量数据库中被拉取出来，然后系统会同时利用产品信息和用户上下文，例如用户之前的购买记录，生成个性化广告。
图 1-4 展示了一个 RAG 驱动系统生成个性化广告的过程：它将用户上下文与产品信息整合在一起。
图 1-4 RAG 驱动的即时个性化广告生成流水线
RAG 驱动广告生成的优势很清楚：我们可以在生产推荐中使用 RAG 强大的语义搜索能力，不仅展示产品，还可以为这些产品创建与我们掌握的用户信息相匹配的广告。这确保每条广告都强调对单个用户最相关的卖点。
举个例子，假设我们想为 Acme Shoes 做广告，这款鞋同时强调安全性和卫生性。对于一位最近聊过脚臭、现在又在聊足球的用户，广告可以从气味痛点切入，比如：“热爱足球，但讨厌脚臭？Acme 鞋经过专门设计，可以抑制造成异味的微生物。”而对于另一位正在谈论安全的用户，广告可以写成：“你不必为了保持身材而牺牲安全。Acme 鞋配有反光条，为你提供保护。”
问答系统
问答系统旨在通过使用 RAG，从多样化数据集中综合信息，为用户查询提供精确答案。
不同于支持多轮对话的聊天机器人或虚拟助手，这里的产品形态是单个问题和单个答案。
问答的一个常见使用场景，是帮助回复招标请求（RFP）或信息请求（RFI）。在竞争激烈的销售环境中，回应客户询问和提案请求时的速度与准确性至关重要。当销售团队需要准备一份定制化提案时，RAG 系统会从内部数据库中拉取相关历史数据、产品规格、价格细节和客户互动记录，然后构造出连贯、定制化的响应。
积极影响非常清楚，收益也相当可观。销售团队可以用手工流程所需时间的一小部分，产出高质量提案，从而提高响应速度和竞争力。这种自动化最大限度降低了人为错误风险，并确保每份提案都基于最新、最准确的数据，而不是从上一份提案中复制粘贴，因为那里的数据可能已经过时。最终，这会带来更高的中标率和更强的客户关系。
医疗和健康应用
在医疗健康领域，及时且准确的信息可能关乎生死。
当临床医生需要快速查看治疗指南或患者病史时，RAG 应用可以检索相关病例研究、研究论文，以及患者病历和所有医生笔记，并生成一份简洁的、基于证据的响应。
这个响应甚至可以针对每位医生的专科进行定制。例如，如果你是心血管外科医生，或者是皮肤科专家，摘要可能会有所不同——因为对每个专科而言，相关信息是不一样的。
通过提供准确且上下文化的医学摘要，并将历史病历与最新医学信息结合起来，我们可以帮助医生更有效地治疗患者，降低遗漏关键信息的可能性，例如过敏信息，并整体上为患者提供更好的治疗。
对于医疗服务提供方以及保险公司来说，收益非常明显。作出知情决策所需的时间被缩短，因此患者结局也会改善。RAG 系统还能通过提供经过综合、易于消化的信息，而不是令人不堪重负的原始数据，帮助减轻临床医生的认知负担。
当然，患者也会从更精准、更个性化的护理中受益。由于可以更快访问关键洞察，并降低信息过时或错误的风险，医疗从业者能够提供既及时又有效的治疗。
重要的是，将这类强大应用部署到生产环境，必须建立在两个不可协商的原则之上：严格遵守《健康保险可携性与责任法案》（HIPAA）以保护患者隐私；以及建立稳健的“人在回路”（HITL）框架，确保在 AI 输出影响生命关键决策之前，始终由合格临床医生进行验证。
法律和合规研究
许多受监管行业，例如医疗和金融服务行业，都需要遵守各种法律法规。理解每项法律要求和监管规定的全部复杂性，以及它如何适用于你的业务，往往非常复杂，并且需要法律研究。在这种场景中，精确性和可靠性至关重要，因为错误可能导致严重的财务损失或声誉损害。
基于 RAG 的系统可以通过快速检索相关判例法、法律条文和内部合规文档，帮助法律和监管专业人员。这种方法极大改善了传统法律研究方式，后者通常依赖人工搜索法律文本和数据库，以及内部数据源。
对法律专业人员而言，收益非常巨大。通过自动化研究流程中的重要部分，RAG 能够缩短法律意见、合规报告和案件准备的交付时间。这种效率不仅降低了人工成本，也最大限度减少了遗漏关键信息的风险。
在前面几节中，我们介绍了 RAG 的基础知识，以及它的主要使用场景。后续在本书中，我们还会介绍更高级形式的 RAG。下一节将预览其中一些高级技术。
高级 RAG
RAG 最早由 Facebook/Meta 在 2020 年发表于第 34 届神经信息处理系统大会（NeurIPS）的一篇论文中提出。当时，RAG 是一个简单概念，仅限于纯文本数据，并且使用微调而不是上下文学习。不过，这一基础性构想非常关键，为这项技术未来的发展铺平了道路。
从那以后，RAG 已经发展成更加高级、更强大的形式。本书后续章节将介绍 RAG 中更高级的技术，例如 agentic RAG（第 7 章）、多模态 RAG（第 8 章），以及知识图谱（第 9 章）。这里，我们先对其中一些技术做一个快速概览。
Agentic RAG
Agentic RAG 是 RAG 的一种演进形式：它不再是一次性检索相关信息并生成响应的过程，而是把自主 AI agent 纳入流水线。这些 agent 增加了如下能力：
迭代式和多步骤检索
不再只获取一次上下文，agent 可以在初始数据不足时重新检索并细化信息。
动态工具集成
Agentic RAG 可以利用多个外部工具，例如网页搜索或 API 调用，访问各种知识来源，而不是只依赖预先摄取的知识。在最简单的形式中，agentic RAG 会把 RAG 中的检索变成模型可以调用一次或多次的工具，使 agent 能够重新表述用户查询，或者支持多轮对话，在这种对话中，前面交互中的信息可以被利用起来，从而改善响应。
高级推理和适应性
Agent 可以拆解复杂查询、规划检索策略、验证信息，甚至协调多个专门化子 agent 来处理多部分任务。
Agentic RAG 通过动态编排多个检索和推理步骤，为处理复杂、多面向查询提供了更大的灵活性和稳健性。我们将在第 7 章中更详细地讨论 agentic RAG。
多模态 RAG
最初，RAG 只用于文本信息。后来，RAG 被扩展到覆盖其他模态，例如表格、图表和图形。通常有两种方法可以把这些其他模态纳入进来。
第一种方法是把所有信息模态都转换成文本，例如把图片转换成图像说明，然后只在文本领域运行已经被充分理解的 RAG 流水线。
另一种方法是利用多模态嵌入模型和语言模型，例如视觉语言模型（VLM），或多模态大语言模型（MLLM）。在这种方法中，非文本领域的信息会保留在原始模态中。随后，这些信息会在查询时提供给 VLM，并与文本数据一起用于生成响应。
最近，一种更端到端的方法正在兴起：对整个页面进行嵌入，并把页面发送进 MLLM 来生成响应。我们将在第 8 章中进一步解释。
结合知识图谱的 RAG
到目前为止，我们讨论过的 RAG 示例都直接使用数字化文本。这种传统方法在复杂数据集之间“串点成线”时可能会遇到困难。为了解决这一限制，一种高级策略是利用知识图谱（KG）。这种方法已经被图数据库厂商广泛推广。
与其只依赖扁平文本嵌入，集成知识图谱的方法会先处理非结构化文档，抽取关键实体及其关系。随后，这些连接会被用来构建知识图谱。这种结构化表示使系统能够支持多跳推理，也就是连接不同信息片段，通常跨越多个文档，从而得出单一来源中并不明显的结论，并在回答复杂查询时提供更深层的上下文感知能力。
另一种由 Microsoft 推广、涉及知识图谱的方法被称为 GraphRAG。它被提出用于解决手工构建知识图谱的复杂性。GraphRAG 会先处理非结构化文档，抽取实体和关系，并构建一个捕捉数据内在连接的知识图谱。我们将在第 9 章中看到这一点。
总结
本章介绍了 RAG。RAG 是一种常见且有效的方法，用于克服大语言模型的内在限制。虽然 LLM 擅长基于其训练过的大量数据生成响应、编写代码和回答问题，但当面对训练集之外的私有信息、最新信息或小众信息时，它们就会出现不足。
RAG 通过把实时数据检索整合进生成过程来解决这个问题，确保响应基于相关的外部信息。
我们介绍了 RAG 系统架构，概述了摄取流程和查询流程，以及每条流程中的不同步骤。
随后，我们回顾了 RAG 的替代方案，例如微调，并讨论了每种方法的优缺点。最后，我们讨论了 RAG 的优势、企业中 RAG 的主要使用场景，以及一些高级技术。后续本书会更详细地讨论这些高级技术。
构建一个 RAG 应用需要学习大量内容——从向量数据库这类新型系统组件，到嵌入模型、LLM 等模型。接下来的内容将深入拆解这些组件，帮助你更好地理解每个组件在实践中如何工作，以及要把它们扩展到企业级使用场景需要什么条件。在整本书中，我们不仅会介绍理论概念，也会强调概念理解和生产部署之间的差距，覆盖运维挑战、成本优化、监控策略，以及经过验证的架构模式。
注 1：如果你刚接触 LLM 世界，可以深入阅读 Jay Alammar 和 Maarten Grootendorst 的《Hands-On Large Language Models》（O’Reilly）。
