RAG 原理入门：检索增强生成为什么有效

为什么需要 RAG

大模型有三个先天限制，RAG（Retrieval-Augmented Generation，检索增强生成）逐一回应：

1. 知识截止：训练数据有时间边界，问新发布的产品、上周的政策，模型要么不知道，要么编一个。
2. 幻觉：模型是概率生成器，“编造得像真的”是它的默认倾向。面向用户的产品里，一次 confidently 的胡说八道就能摧毁信任。
3. 私有知识缺失：你公司的产品文档、内部规章、客服工单，不在任何模型的训练集里。

RAG 的思路朴素得像考试开卷：回答之前，先把相关资料检索出来，塞进上下文，让模型“看着材料答题”。Perplexity 的每一条带引用来源的回答、ChatGPT 的联网搜索、企业知识库问答，底层都是这个范式。

RAG 的完整链路

理解链路才能定位问题。一个典型 RAG 系统分两个阶段：

离线：建索引

原始文档 → 清洗解析 → 切分成块（chunk）→ 向量化（embedding）→ 存入向量库

在线：查询应答

用户提问 → 改写查询 → 检索（向量相似度 + 关键词）→ 重排序 → 拼装上下文 → 生成带引用的回答

产品经理不需要会写每一步的代码，但必须知道：用户感知到的每一次“答错了”“没找到”，都能定位到链路上的某一环。是没检索到（召回问题）？检索到了但排在后面（排序问题）？还是材料给了但模型没用好（生成问题）？三种问题的修法完全不同。

一个关键概念：向量检索为什么能“按语义”找到资料

传统搜索按关键词匹配，搜“退款”找不到只写了“退货流程”的文档。向量检索把文本压缩成一串数字（向量），语义相近的文本在向量空间里距离更近，于是“退款”和“退货流程”能够互相命中。

这带来一个重要的产品含义：检索质量取决于语料和查询的“语义表述质量”。口语化的用户提问对上书面化的文档，命中率会打折——这是后续查询改写、分块策略要解决的问题。

RAG vs 微调 vs 长上下文

方案	适合解决	不适合解决	成本结构
RAG	知识时效、私有知识、需可溯源	改变风格、教复杂技能	检索基础设施 + 按查询付费
微调（Fine-tuning）	固定风格、格式、领域行为	更新频繁的知识	一次训练成本 + 更新成本高
长上下文	小规模文档一次性分析	全量知识库（成本与稀释效应）	token 费用随规模暴涨

经验法则：知识用 RAG，行为用微调。而且两者不互斥——很多生产系统同时使用。长上下文模型（如 128K、1M 窗口）出现后，“RAG 已死”的说法反复出现，但全量塞入上下文既有成本问题，也有“大海捞针”式的注意力稀释问题，RAG 依然是知识密集场景的主流架构。

产品决策提示：判断一个需求是否该上 RAG，看三个问题：知识是否更新频繁？是否需要给出处（合规、信任）？知识量是否超出可承受的上下文？三问皆否，纯 Prompt 可能更简单。

RAG 产品的典型形态

• 知识库问答：企业内部文档助手，是 RAG 最普遍的落地形态。
• 带引用的搜索：Perplexity 的核心体验——每个论断都能点开看来源，可信度来自可验证。
• 上下文增强：Cursor 在代码补全前检索相关代码片段，是 RAG 思想在 IDE 场景的应用。

本节要点

• RAG 回应大模型三大限制：知识截止、幻觉、私有知识缺失，本质是“开卷考试”——先检索再生成。
• RAG 分离线索引和在线应答两段链路，产品经理的核心能力是把用户投诉定位到“召回、排序、生成”具体哪一环。
• 向量检索按语义而非关键词命中，检索质量受语料与查询表述差异影响，是后续优化手段的出发点。
• 选型口诀：知识用 RAG，行为用微调，两者可叠加；长上下文不能替代大规模知识库场景。
• 需知识更新频繁、需溯源、知识量大三特征命中时，RAG 是正确架构。