什么是 RAG

大语言模型（LLM）很强，但它有一个根本性的限制：知识截止日期。GPT-4 的训练数据有截止时间，Claude 也不例外——它们无法回答训练之后发生的事，也无法获取你公司内部的私有文档。这就引出了一个问题：如何让大模型用上「它没学过的知识」？

RAG（Retrieval-Augmented Generation，检索增强生成）就是目前业界最主流的解决方案。它让大模型在回答问题之前，先从外部知识库中「查资料」，然后基于查到的内容生成回答。打个比方：大模型原本是一个「闭卷考试」的选手，RAG 给它开了「开卷」的权限。

本文属于《从 0 到 1 AI 产品出海知识库》中的「RAG 知识库与 AI Agent 入门」章节，从零开始讲清楚 RAG 的定义、原理、工作流程、应用场景、优势与局限。

RAG 的定义与核心思想

RAG 的全称是 Retrieval-Augmented Generation，中文译为「检索增强生成」。它是一种 AI 架构，通过将大语言模型与外部知识检索系统结合，让模型在生成回答时能够引用训练数据之外的信息。

RAG 的核心思想可以拆成两个词：

• Retrieval（检索）：从外部知识库中，根据用户的问题找到相关的文档或片段
• Generation（生成）：把检索到的内容作为上下文，连同用户的问题一起交给大模型，让它基于这些「参考资料」生成回答

这两个步骤组合在一起，就是 RAG。模型不再只依赖自己的参数记忆，而是能在推理时（inference time）动态获取最新、最准确的信息。

RAG 这个概念最早由 Facebook AI Research（现 Meta AI）在 2020 年的论文《Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks》中提出。当时的目标是让模型在处理知识密集型任务时，能够参考大规模的语料库，而不是完全依赖参数中存储的知识。

RAG 的工作原理

RAG 的完整工作流程可以分为四个阶段：文档处理、向量化、检索、生成。

阶段一：文档处理（Document Processing）

一切从原始数据开始。你的知识库可能是 PDF 文档、Word 文件、网页内容、数据库记录、Markdown 文件，或者任何文本格式。

这一步需要做的是：

1. 数据收集：把所有来源的文档汇总到一起
2. 文档解析：将不同格式的文档提取为纯文本
3. 文本分块（Chunking）：将长文档切分成较小的片段（chunk）。为什么要分块？因为大模型有上下文长度限制（context window），而且检索时需要精确到段落级别，而不是把整本书塞进去。常见的分块策略包括按固定字符数切分、按段落切分、按语义切分等

分块的质量直接影响后续检索的准确性。块太大，检索结果会混入无关内容；块太小，上下文不完整，模型难以理解。

阶段二：向量化（Embedding）

文本分块之后，需要把每个文本块转换成向量（Vector）——也就是一组高维数字数组。这个转换过程由 Embedding 模型完成，比如 OpenAI 的 text-embedding-3-small、Cohere 的 embed-v4、开源的 bge-large 等。

向量的意义在于：它把文本的「语义信息」编码成了数学空间中的坐标。语义相近的文本，在向量空间中的距离也相近。这样，我们就可以通过计算向量之间的距离来衡量文本的语义相似度。

所有文本块的向量会被存入向量数据库（Vector Database），常见的选择包括 Pinecone、Weaviate、Qdrant、Milvus、Chroma，以及 pgvector（PostgreSQL 的向量扩展）等。这个过程叫做建立索引（Indexing）。

阶段三：检索（Retrieval）

当用户提出问题时，RAG 系统会：

1. 用同一个 Embedding 模型将用户问题转换为向量
2. 在向量数据库中搜索与问题向量最相似的文本块（通常用余弦相似度 cosine similarity 来衡量）
3. 返回 Top-K 个最相关的文本块

除了向量检索（语义检索），实际项目中常常结合**关键词检索（BM25）做混合检索（Hybrid Search），再经过重排序（Re-ranking）**模型对结果进行二次排序，以提升检索质量。

阶段四：生成（Generation）

最后一步，RAG 系统将检索到的文本块拼接到 Prompt 中，形成一个类似这样的结构：

基于以下参考资料回答用户的问题。如果参考资料中没有相关信息，请如实说明。

参考资料：
[1] {检索到的文本块1}
[2] {检索到的文本块2}
[3] {检索到的文本块3}

用户问题：{用户的问题}

大模型基于这些参考资料生成最终回答。由于回答有了「依据」，模型产生幻觉（hallucination）的概率会显著降低。

RAG 完整工作流程图

RAG 的应用场景

RAG 已经成为企业落地 AI 应用最主流的技术方案之一。以下是最常见的应用场景：

RAG vs 微调：两种增强 LLM 的路径

让大模型用上领域知识，除了 RAG，还有一种常见方案：微调（Fine-tuning）。两者在原理、成本、适用场景上有显著差异。

什么是微调

微调是在已有的预训练模型基础上，用特定领域的数据继续训练（additional training），让模型「学会」新的知识或行为。微调改变的是模型的参数权重——训练完成后，这些知识就被「固化」到模型中了。

核心差异对比

如何选择？

简单来说：

• 知识频繁变化（产品文档、新闻资讯、政策法规）→ 选 RAG
• 需要模型学习特定风格或格式（比如始终用 JSON 输出、用特定语气回复）→ 选微调
• 需要追溯回答来源（合规场景、客户服务）→ 选 RAG
• 领域知识稳定且封闭（医学教科书、法律条文的基础理解）→ 可以考虑微调
• 两者结合：微调让模型理解领域语言和输出格式，RAG 提供最新的知识——这是很多企业的实际做法

RAG 的优势

1. 知识实时可更新 只需更新向量数据库中的文档，不需要重新训练模型。新产品发布、政策变更、FAQ 更新，都能即时反映在 AI 回答中。

2. 降低幻觉风险 模型的回答基于检索到的具体文档片段，而非凭空生成。你可以要求模型只基于参考资料回答，不确定时如实说明，从而显著减少「一本正经胡说八道」的情况。

3. 可追溯来源 RAG 可以在回答中附带引用来源（「根据文档 [1]…」「参考 XX 手册第 3 章…」），用户能够验证信息的准确性。这在合规要求高的行业（金融、医疗、法律）尤其重要。

4. 实施门槛相对较低 不需要 GPU 训练集群，不需要机器学习工程师从头训练模型。用现成的 Embedding API + 向量数据库 + LLM API，一个后端开发者就能搭建起基础的 RAG 系统。

5. 保护数据隐私 企业的私有数据不需要用来训练模型（可能泄露到模型参数中），而是存储在独立的知识库中，只在推理时按需检索。

6. 成本可控 相比微调需要反复消耗 GPU 算力，RAG 的主要成本在于向量数据库和 API 调用。对于中小规模的知识库，月成本可以控制在几十到几百美元。

RAG 的局限

1. 检索质量决定上限 RAG 的效果高度依赖检索的准确性。如果检索回来的内容不相关，模型即使再强也生成不了好答案——「垃圾进，垃圾出」的原则在 RAG 中同样适用。

2. 上下文长度限制 虽然现代模型的上下文窗口越来越大（GPT-4 Turbo 128K，Claude 3.5 200K），但把大量检索结果塞进 Prompt 仍然有上限。如何在有限的窗口内放最有价值的信息，是一个需要持续优化的问题。

3. 延迟增加 相比直接调用 LLM，RAG 多了检索步骤。向量检索、重排序、拼接 Prompt 都会增加响应时间。在对延迟敏感的场景（实时聊天）中需要重点优化。

4. 分块策略需要反复调优 文本分块的大小、重叠度、切分方式都会影响最终效果，而这些往往需要根据具体业务数据反复实验。没有「万能」的分块策略。

5. 语义鸿沟 用户的问题和文档的表述方式可能差异很大。比如用户问「怎么退款」，但文档中写的是「退货退款流程」，Embedding 模型可能无法准确匹配。这需要靠查询改写（query rewriting）、混合检索等手段来缓解。

6. 维护成本不可忽视 知识库需要持续更新和维护。过期的文档、重复的内容、格式不一致的文件，都会降低检索质量。RAG 不是一个「搭完就不管」的系统。

优势与局限对比表

实际案例

案例一：跨境电商智能客服

某跨境电商公司有大量的退换货政策、物流说明、产品使用手册，过去客服团队每天处理上千条重复性咨询。

他们搭建了一套 RAG 系统：

• 将所有产品文档、退换货政策、FAQ 整理成结构化文本
• 按段落分块后用 OpenAI Embedding 模型向量化，存入 Pinecone
• 用户提问时，系统检索最相关的 3-5 个文本块，连同问题交给 GPT-4 生成回答
• 回答中附带来源引用，方便用户核实

上线后，客服工单量下降了约 40%，平均响应时间从 2 小时缩短到 30 秒。更重要的是，回答的一致性提高了——不再出现不同客服给出不同答案的情况。

案例二：SaaS 产品技术文档助手

一家 B2B SaaS 公司有数百页的 API 文档、集成指南和最佳实践。开发者和客户经常需要在文档中翻找特定信息。

他们构建了一个文档助手：

• 将所有文档（Markdown 格式）按章节分块
• 使用混合检索（向量检索 + BM25 关键词检索）提升匹配准确率
• 加入 Re-ranking 模型对检索结果二次排序
• 将结果交给 LLM 生成回答，并在回答中附上文档链接

这个助手集成到了产品的帮助中心，开发者可以直接用自然语言提问：「如何用 Python SDK 创建 webhook？」。系统从文档中检索到对应的 API 说明和代码示例，生成带有代码片段和文档链接的回答。

RAG 的进阶方向

基础 RAG 已经能满足很多场景的需求，但业界在实践中也发现了不少可以优化的环节。以下是一些主流的进阶方向：

这些进阶技术不互斥，实际项目中往往会组合使用。

构建 RAG 系统的检查清单

如果你准备搭建一个 RAG 系统，以下清单可以帮你检查关键环节是否到位：

• 明确数据来源：所有需要纳入知识库的文档是否已收集齐全？
• 文档质量检查：过期、重复、格式混乱的文档是否已清理？
• 分块策略确定：是否根据文档特点选择了合适的分块方式（按段落、按语义、按固定长度）？
• 分块大小调优：chunk 大小是否在 200-1000 token 之间做了实验对比？
• Embedding 模型选择：是否根据语言（中文/英文/多语言）和数据量选择合适的 Embedding 模型？
• 向量数据库选型：是否根据数据规模、查询并发、运维成本选择了合适的向量数据库？
• 检索策略设计：是否考虑了混合检索（向量 + 关键词）以提升召回率？
• Re-ranking 环节：是否加入了重排序步骤以提升检索精度？
• Prompt 工程：系统 Prompt 是否明确要求模型基于参考资料回答，并在不确定时如实说明？
• 来源引用：回答中是否附带了来源文档的引用或链接？
• 延迟优化：端到端的响应延迟是否满足业务需求？是否需要做缓存或异步优化？
• 评估指标：是否建立了检索准确率（recall@k、MRR）和回答质量的评估体系？
• 持续维护机制：是否有文档更新、过期清理、质量监控的流程？

总结

RAG 让大语言模型从「闭卷考试」变成了「开卷考试」。它不需要重新训练模型，就能让 AI 用上最新的、私有的、特定领域的知识。它的核心流程很清晰：文档处理 → 向量化 → 检索 → 生成。它的优势在于知识可更新、来源可追溯、实施门槛相对较低；局限在于检索质量决定上限、延迟会增加、需要持续维护。

对于 AI 产品出海来说，RAG 几乎是搭建知识库类应用的必备技术。理解了 RAG，你就掌握了让大模型「接入外部世界」的关键能力。

参考资料

1. Lewis, P., et al. "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks." NeurIPS 2020. https://arxiv.org/abs/2005.11401
2. AWS. "什么是 RAG？— 检索增强生成 AI 详解." https://aws.amazon.com/cn/what-is/retrieval-augmented-generation/
3. Red Hat. "什么是检索增强生成？" https://www.redhat.com/zh-cn/topics/ai/what-is-retrieval-augmented-generation
4. IBM. "RAG vs. Fine-tuning." https://www.ibm.com/think/topics/rag-vs-fine-tuning
5. Cloudflare. "什么是 AI 中的检索增强生成（RAG）？" https://www.cloudflare.com/zh-cn/learning/ai/retrieval-augmented-generation-rag/
6. Elastic. "什么是检索增强生成（RAG）？RAG 全面指南." https://www.elastic.co/cn/what-is/retrieval-augmented-generation
7. Squirro. "RAG in 2026: Bridging Knowledge and Generative AI." https://squirro.com/squirro-blog/state-of-rag-genai
8. Google Cloud. "什么是检索增强生成（RAG）？" https://cloud.google.com/use-cases/retrieval-augmented-generation?hl=zh-CN