RAG入门：从一个痛点说起 | RAG 101: Starting from a Real Pain Point

RAG入门：从一个痛点说起

想象这样一个场景

周一早晨，某电商公司的客服主管李明接到了一个棘手的投诉。用户在凌晨两点下单了一件最新款无线耳机，但当她询问"这款耳机的降噪深度是多少"时，AI客服给出的回答竟然是"我们的耳机采用行业领先的主动降噪技术"——一个听起来专业、实际上毫无信息量的通用回复。用户追问具体参数，AI继续打太极，最后用户愤怒地表示要取消订单并投诉到315。

李明调查后发现，问题出在AI客服的“知识储备”上：这款耳机是上周刚上架的新品，而公司的AI客服助手是基于三个月前的数据训练的。面对新产品的咨询，它只能依靠"模糊但看起来很专业"的通用话术来应对——这正是大语言模型在真实业务场景中最常见的"有心无力"时刻。

这个场景并非个例。根据我们对数百家企业AI落地项目的观察，超过70%的企业AI应用失败案例，都与知识时效性和知识覆盖范围有关。要么是模型不知道最新发生的事，要么是模型不了解企业内部的规定和文档。当AI被问到超出它训练数据范围的问题时，它会怎么做？

它会编造。

这听起来像是个玩笑，但这确实是当前大语言模型面临的核心挑战之一——幻觉问题（Hallucination）。模型会用流畅的语言、合理的逻辑，把一个它完全不知道答案的问题"回答"得像是真的懂一样。这种能力让AI在闲聊时显得很聪明，但在需要准确信息的业务场景中，却是致命的缺陷。

这就是我们要讨论的核心问题：为什么大模型需要RAG？它能解决哪些问题？

---

大模型的「知识盲区」

要理解RAG的价值，首先需要理解大语言模型的知识到底是怎么来的，以及它的局限性在哪里。

训练数据的快照特性

ChatGPT、Claude、GPT-4这些通用大语言模型，本质上是基于静态数据集进行训练的。以GPT-4为例，它的知识截止日期（Knowledge Cutoff）是在一个特定的时间点之前的互联网上公开可获取的文本。这意味着：

• **2023年1月之后发生的事，模型可能完全不知道**
• **2023年1月之后发布的产品，模型无法提供准确信息**
• **任何依赖于最新数据的事实性问题，模型都可能出错**

你可能有过这样的经历：问ChatGPT某个最近上映的电影的评价，它要么说"我没有关于这部电影的信息"，要么给出一个基于预告片和早期报道的推测性回答。这种"不知道就说不知道"的态度虽然诚实，但对于需要实时信息的业务场景来说，仍然不够用。

私有知识的困境

比知识截止日期更棘手的问题是：企业内部的私有知识根本无法进入通用模型的训练数据。

让我们继续李明的故事。即使AI客服知道了那款耳机的参数（假设这些参数后来被加入了训练数据），它仍然无法回答以下问题：

• "这个订单能不能申请延迟发货？"
• "我的优惠券为什么不能用？"
• "你们公司的退货政策是什么？"

这些问题的答案不在互联网上，而在：

• 公司的内部规章制度文档
• 客服团队的SOP标准操作流程
• 历史工单中积累的解决方案
• 业务部门制定的各种特殊政策

一家连锁酒店集团的IT负责人张伟曾向我们诉苦："我们花了半年时间训练了一个看起来很专业的酒店问答AI，结果上线第一周就出了大问题——用户问'酒店最近的地铁站在哪里'，AI给出了一个五年前的地铁线路图，因为那是训练数据里能抓到的最新信息。用户到了现场才发现地铁站根本不存在的那个出口，这直接导致了客诉。"

张伟遇到的问题揭示了私有知识困境的另一个维度：即使模型"知道"某件事，它知道的可能是过时或不准确的版本。企业内部的知识是动态更新的——价格会变、政策会调、人员会换。传统的"训练一次，部署长期使用"的模式，根本无法适应这种频繁变化。

模型能力与知识边界的错配

这里有一个微妙的认知陷阱需要澄清：大语言模型展现出令人惊叹的"理解力"和"推理能力"，这让人们容易产生一种错觉——模型应该"知道"所有事。但实际上，模型的能力（Capability）和知识（Knowledge）是两个不同的维度：

| 维度 | 描述 | 例子 | |------|------|------| | 能力 | 模型"会不会做"某类任务 | 理解自然语言、进行逻辑推理、生成连贯文本 | | 知识 | 模型"知不知道"某些事实 | 2024年的GDP数据、公司内部流程、用户历史订单 |

模型可以很好地"做"客服工作——理解用户意图、生成友好的回复格式——但它不一定"知道"回答某个具体问题所需的实时信息。

这就产生了一个尴尬的局面：模型越强大，用户对它的期望就越高；当它无法回答本应能回答的问题时，落差感就越强烈。

---

RAG的核心思想：先检索，再生成

面对上述困境，研究者们提出了一个看似简单、实则精妙的解决方案——Retrieval-Augmented Generation，简称RAG。

从图书馆到AI：检索的力量

让我们先用一个生活化的类比来理解RAG的工作方式。

想象你要写一篇关于"量子计算最新进展"的论文，但你只有2015年之前的知识储备。你会怎么做？

一个方法是重新学习所有新知识，把这几年关于量子计算的新论文、新进展都塞进脑子里，然后开始写。这对应了AI领域的"模型训练/微调"方法。

但还有另一个方法：你不需要记住所有东西，而是学会如何快速找到需要的信息。你可以去图书馆、查数据库、搜学术论文，然后根据找到的资料来撰写论文。你的大脑负责理解、组织和撰写，但具体的事实性信息来自外部检索。

第二种方法就是RAG的核心思想——不要让模型独自承担"记住所有事"的重任，而是让它学会利用外部知识库来增强自己的回答。

RAG的工作流程

一个典型的RAG系统包含以下几个核心环节：

```mermaid flowchart TD A[用户 Query] --> B[检索阶段] B --> C[向量数据库查询] C --> D[返回 Top-K 相关文档] D --> E[生成阶段] E --> F[构建 Prompt] F --> G[LLM 生成回答] G --> H[返回最终答案]

style A fill:#e1f5fe style H fill:#c8e6c9 style B fill:#fff3e0 style E fill:#fff3e0 ```

第一步：检索（Retrieval）。当用户提出问题时，系统不是直接让模型回答，而是先把这个问题转换成一个"查询向量"，然后去一个预先构建好的知识库中寻找与之最相关的文档或段落。这个知识库通常被称为"向量数据库"（Vector Database），里面存储着企业准备好的各类文档——产品手册、FAQ、内部政策、技术文档等。

第二步：增强（Augmentation）。找到相关文档后，系统把这些文档作为"上下文"（Context）加入到提示词（Prompt）中，构成了一个增强版的输入。你可以理解为给模型递了一张"小抄"，让它在回答时参考这些真实、准确的信息。

第三步：生成（Generation）。带着这张"小抄"的模型，现在可以基于真实的文档内容来生成回答了。它不再是"凭记忆编造"，而是"看着资料作答"。

回到李明的案例。如果这家电商公司部署了RAG系统，AI客服的工作流程就会变成这样：

用户问："这款新耳机的降噪深度是多少？"

系统先检索产品知识库，找到最新上架的耳机产品文档，其中明确标注"主动降噪深度可达42dB"；系统把这个问题和找到的产品参数一起交给模型；模型根据真实的产品文档生成回答："这款耳机采用最新的主动降噪技术，降噪深度可达42dB，处于同价位产品的领先水平。"

整个过程不过几百毫秒，但回答的准确性和信息量却有了质的飞跃。

为什么RAG能解决"幻觉"问题

幻觉问题的根源在于：模型在生成回答时，完全依赖自身参数中存储的"压缩知识"。当这个知识与现实不符（过时或不完整）时，模型只能"合理地编造"一个看起来像答案的东西。

RAG通过引入外部知识源，改变了这个生成机制：

1. 事实性信息来自真实文档，而不是模型参数。模型不再需要"记住"所有事实，只需要"理解"问题并"引用"文档内容。 2. 知识的更新变成了文档的更新，而不是模型的重新训练。想让AI知道新产品信息？只需要把产品文档加入知识库。 3. 模型承担的是"理解-整合-表达"的工作，而不是"记忆-回忆-生成"的工作。这是一个更匹配模型能力的分工。

打个不太准确但很直观的比方：如果把模型比作一个记忆力有限的专家，RAG就像是给这个专家配了一个超级图书管理员——专家不需要记住所有细节，他只需要学会提问和引用，管理员会帮他找到需要的信息。

---

RAG vs 微调：什么时候该用谁

在讨论RAG时，一个不可避免的话题是它与微调（Fine-tuning）的关系。这是很多刚开始接触LLM应用开发的读者最容易困惑的问题。

什么是微调

微调是在已经预训练好的大模型基础上，使用特定领域或特定任务的数据进行额外训练，让模型调整自己的参数来适应新任务。打个比方，就像是把一个已经学会说中文的通用翻译，派去专门学习医学术语，训练结束后它就成了一个医学翻译专家。

微调可以带来一些明显的好处：

• **任务特定的行为模式**：微调后的模型可以直接学会某种特定的回复风格、格式或语气，不需要在每次Prompt中反复强调。
• **更高的推理效率**：因为知识已经"固化"到模型参数中，推理时不需要额外的检索步骤，响应速度更快。
• **在特定任务上的深度优化**：如果任务非常垂直、规则非常固定，微调可以实现很高的准确率。

RAG和微调的对比

然而，微调也有明显的局限性，而RAG恰恰能在这些方面补足：

| 维度 | RAG | 微调 | |------|-----|------| | 知识更新 | 只需更新文档库，无需重新训练 | 需要重新微调，成本高、周期长 | | 知识范围 | 可以接入海量外部文档 | 受限于模型参数容量 | | 可解释性 | 答案可追溯到具体文档 | 知识"融入"参数，难以精确定位 | | 幻觉问题 | 显著降低，基于真实文档生成 | 仍可能产生幻觉，尤其在边界case | | 成本 | 主要是向量数据库和检索成本 | 训练成本高，需要GPU和时间 | | 适用场景 | 知识密集型、需要频繁更新的场景 | 任务模式固定、需要特定风格的场景 |

一个实用的决策框架

在实际项目中，如何选择？这里给出一个实用的判断逻辑：

优先考虑RAG的场景：

• 知识库量大且经常更新（如产品目录、价格变动、政策法规）
• 需要回答事实性问题，需要提供信息来源
• 希望保持答案的可审计性和可追溯性
• 团队没有充足的GPU资源进行频繁微调
• 上线初期需要快速迭代验证效果

优先考虑微调的场景：

• 任务模式非常固定，需要模型"学会"某种特定行为
• 领域非常垂直，微调数据可以覆盖绝大多数情况
• 对推理延迟有严格要求，不希望有检索环节的延迟
• 需要模型内化某种复杂的推理模式或专业技能
• 企业有充足的训练资源和MLOps能力

两者结合的场景：

在很多成熟的生产级应用中，RAG和微调是协同使用的：

• 用微调来优化模型的对话风格、指令遵循能力、输出格式
• 用RAG来提供实时、准确的事实性知识
• 微调让模型"更像专家"，RAG让模型"知识不过时"

张伟后来在复盘酒店问答项目时采用了这种思路："我们用微调让AI学会酒店行业的专业术语和对话风格，用RAG接入了实时更新的酒店设施信息和周边地理信息。效果比单纯用任何一个方法都好。"

---

一个典型的RAG Pipeline

了解了RAG的核心思想后，让我们来深入了解一个完整RAG Pipeline的技术架构。这一节会从系统组件的角度，帮助你在下一节画出完整的数据流图。

核心组件概览

一个生产级的RAG系统通常包含以下组件：

1. 文档处理层（Document Processing）

这是RAG系统的"预处理"环节，负责把原始文档转换成可检索的格式。主要步骤包括：

• **文档解析**：从PDF、Word、网页等不同格式中提取文本内容
• **文本分块（Chunking）**：把长文档切分成适合检索的小段落。分块策略很关键——太大则检索精度低，太小则丢失上下文
• **元数据提取**：为每个块添加来源文档名、章节标题、页码等元信息，便于后续追溯

2. 向量化层（Embedding）

这是RAG系统的"翻译"环节，把文本转换成模型能处理的数值向量：

• **Embedding模型**：使用专门的文本嵌入模型（如OpenAI的text-embedding-ada-002，或开源的BGE系列）把文本块转换成高维向量
• **向量存储**：把生成的向量连同原始文本一起存入向量数据库。常见的向量数据库包括Pinecone、Milvus、Weaviate、Chroma等

3. 检索层（Retrieval）

这是RAG系统在推理时的"查找"环节：

• **Query向量化**：把用户的问题同样转换成向量
• **相似度搜索**：在向量数据库中找出与问题向量最相似的Top-K个文档块
• **重排序（Reranking）**：可选的优化步骤，使用更精准的模型对初步检索结果进行二次排序

4. 生成层（Generation）

这是RAG系统的"回答"环节：

• **Prompt构建**：把用户问题、检索到的文档块、系统指令组合成完整的Prompt
• **LLM推理**：调用大语言模型生成最终回答
• **后处理**：对回答进行必要的格式处理、敏感词过滤等

数据流详解

现在让我们把视角切换到一次完整的用户请求流程上：

```mermaid flowchart LR subgraph 预处理阶段["预处理阶段（离线）"] A1[原始文档] --> A2[文档解析] A2 --> A3[文本分块] A3 --> A4[向量化] A4 --> A5[(向量数据库)] end

subgraph 推理阶段["推理阶段（在线）"] B1[用户问题] --> B2[Query向量化] B2 --> B3[向量检索] A5 --> B3 B3 --> B4[相关文档] B4 --> B5[Prompt构建] B5 --> B6[LLM生成] B6 --> B7[最终回答] end ```

离线预处理阶段：企业将产品手册、FAQ、政策文档等原始材料准备好，经过解析、分块、向量化后存入向量数据库。这个阶段一次性完成（或定期更新），不影响线上响应速度。

在线推理阶段：用户发起请求时，系统实时完成Query向量化→向量检索→Prompt构建→LLM生成→返回回答的全流程。整个过程通常在几百毫秒到几秒内完成。

关键技术考量

在设计RAG系统时，有几个关键技术点需要特别注意：

分块策略（Chunking Strategy）：这不是一个"设个固定长度"就能解决的问题。不同的文档类型、不同的使用场景，需要不同的分块策略：

• 对于问答场景，通常200-500token的块比较合适
• 对于需要保持完整上下文的长文档，可以使用Overlap的分块方式，让相邻块之间有重叠
• 对于结构化文档（表格、列表），可能需要特殊处理，避免把一个完整的表格拆得七零八落

检索质量优化：向量检索虽然强大，但并非万能。一些常见的优化手段包括：

• **混合检索**：结合关键词检索（如BM25）和向量检索的结果
• **元数据过滤**：在检索时加入时间、类别等条件过滤
• **query改写**：在检索前先对用户问题进行改写或扩展，提高检索召回率

上下文窗口管理：当检索到多个文档块时，如何把它们都塞进Prompt的上下文窗口是一个挑战。上下文窗口是有限的（即使是GPT-4-128k也有上限），而知识库可能很大。一个常见策略是只保留Top-K最相关的块，并按相关性排序。

---

从痛点到方案：完整的案例拆解

现在，让我们用一个完整的案例来串联本章的所有知识点。假设你是李明，你们公司决定用RAG来解决AI客服的知识时效问题。

步骤一：梳理知识资产

首先，你需要盘点公司现有的知识资源：

• **产品信息**：产品规格参数、价格、库存状态（实时）
• **政策文档**：退换货政策、优惠券使用规则、会员权益
• **运营公告**：促销活动说明、系统维护通知
• **客服知识库**：历史工单中的常见问题解决方案

在这个案例中，最紧急的是产品信息——尤其是新品上架后的参数更新。你决定先用RAG接入产品数据库。

步骤二：设计RAG架构

基于产品信息的特点，你设计了如下方案：

```mermaid flowchart TD subgraph 数据源["数据源"] P1[产品数据库] P2[ERP系统] P3[商品详情页] end

subgraph 预处理["预处理层"] T1[定时同步任务] T2[文档分块] T3[向量生成] end

subgraph 存储["向量数据库"] V1[(产品向量库)] end

subgraph 服务["服务层"] R1[检索服务] G1[生成服务] end

subgraph 对外["API接口"] A1[AI客服前端] end

P1 --> T1 P2 --> T1 P3 --> T1 T1 --> T2 T2 --> T3 T3 --> V1 A1 --> R1 R1 --> V1 R1 --> G1 G1 --> A1 ```

定时同步任务：每30分钟从ERP系统同步一次产品数据，确保新品上架后半小时内即可被检索到。

分块策略：以产品SKU为单位进行分块，每个产品块包含：产品名称、品牌