跳到主要内容

RAG：检索增强生成到底增强了什么

RAG 这题最容易被答浅。很多人只会说“先查资料，再让大模型回答”。这句话方向没错，但不够面试化。更完整的表达应该是：RAG（Retrieval-Augmented Generation，检索增强生成）是一种把外部知识检索结果动态注入模型上下文，再由模型基于这些资料生成答案的方案。

0. 面试速答（30 秒版 TL;DR）​

  • RAG 不是训练模型，而是给模型在回答前临时补资料。
  • 它解决的核心问题是：模型参数里的知识不够新、不够全、不够贴业务。
  • 标准链路通常是：
    • 文档切块
    • 向量化
    • 建索引
    • 检索召回
    • 重排
    • 把片段放进 Prompt
    • 生成答案
  • RAG 的关键不只是“查到资料”，而是查到对的资料，并且让模型正确使用这些资料。
  • 一句话：RAG 增强的不是模型参数，而是模型推理时可用的上下文。

1. 为什么需要 RAG？​

只靠大模型参数，会遇到几个典型问题：

  • 知识过时
  • 企业内部知识不在预训练语料里
  • 某些领域答案必须基于原文，不能凭模型“感觉”
  • 需要引用来源，方便追溯

所以你可以把 RAG 理解成：

  • 给模型外挂一个“临时可查资料区”

它的本质不是让模型更聪明，而是让答案更有依据。

2. 一条标准 RAG 流程​

这条链路里最值得记住的是两层：

  • 离线侧：文档如何被处理和建索引
  • 在线侧：问题如何被检索并注入生成

3. RAG 的关键步骤，不是每一步都同等重要​

3.1 切块（Chunking）​

切块是很多系统效果不稳定的根源。

切得太大：

  • 噪音多
  • 上下文浪费
  • 检索不准

切得太小：

  • 语义被切碎
  • 模型拿不到完整因果关系

所以切块本质上是在平衡两件事：

  • 可检索性
  • 语义完整性

3.2 检索（Retrieval）​

检索目标不是“查很多”，而是：

  • 优先把真正相关的片段找出来

常见检索方式有：

  • 向量检索
  • 关键词检索
  • 混合检索

实际工程里，一个非常重要的经验是：

  • 召回率和精确率要一起看

只追求召回多，可能把大量噪音也带进 Prompt。

3.3 重排（Rerank）​

为什么很多 RAG 要加重排？

因为第一轮检索往往负责“尽量别漏”，但不一定最会排序。

重排做的事情是：

  • 对候选片段再次判断相关性
  • 把更像答案依据的片段排到前面

一句话理解：

  • 检索负责找候选，重排负责把最该看的顶上来。

3.4 生成（Generation）​

资料找到了，不代表答案一定好。

生成阶段仍然可能出问题：

  • 模型忽略检索片段
  • 模型过度总结，丢细节
  • 模型把多个片段拼错
  • 模型夹带参数知识里的幻觉

所以一个好的 RAG Prompt 往往会明确要求：

  • 仅基于给定资料回答
  • 资料不足时明确说不知道
  • 尽量给出处或引用片段

4. RAG 和微调（Fine-tuning）有什么区别？​

这题很高频。

可以直接这样答：

维度RAG微调
改的是什么运行时上下文模型参数
更新知识成本低高
适合场景知识问答、企业文档、强时效内容风格迁移、格式学习、特定任务行为调整
是否容易带来源引用相对容易不直接提供

面试里一句话总结：

  • RAG 更像“开卷考试”，微调更像“改学生脑子里的习惯”。

5. 一个最小可落地示例​

type Chunk = {
  text: string;
  score: number;
};

async function answerWithRag(question: string): Promise<string> {
  const recalled: Chunk[] = await retrieve(question);
  const ranked = recalled.sort((a, b) => b.score - a.score).slice(0, 4);

  const context = ranked.map((item) => item.text).join("\n\n");

  return callModel({
    system: "你只能基于提供的资料回答；资料不足就明确说明。",
    user: `问题: ${question}\n\n资料:\n${context}`,
  });
}

这段代码虽然很简化，但能说明 RAG 的核心动作：

  • 先取资料
  • 再拼上下文
  • 最后再生成

6. 前端 / Agent 系统里，RAG 常见用法​

典型场景包括：

  • 产品文档问答
  • 内部知识库助手
  • API 文档 Copilot
  • 工单、FAQ、操作手册统一检索
  • 对聊天机器人增加“基于事实回答”的能力

如果是前端产品，RAG 很常见的真实落点是：

  • 带引用的搜索问答
  • 文档助手
  • 面向客服或运营的知识增强型聊天

7. 为什么做了 RAG，还是会幻觉？​

这是最容易被追问的一题。

原因通常不止一个：

  • 没召回到真正相关的内容
  • 召回内容太多，噪音盖过重点
  • Chunk 切得不好，证据链断裂
  • Prompt 没明确约束“只基于资料回答”
  • 模型把参数知识和检索内容混合了

所以要记住：

  • RAG 不是幻觉消除器，它只是把“回答有依据”的概率显著提高。

8. 评估 RAG，不能只看最终答案像不像​

成熟一点的评估至少会拆成三层：

  • 检索是否召回了对的片段
  • 重排是否把关键片段排前面
  • 生成是否忠于资料

否则你很容易出现：

  • 最终答案错了，却不知道错在检索还是生成

这是很多团队做 RAG 的常见盲区。

9. 面试高频追问​

9.1 RAG 的核心瓶颈通常在哪？​

标准答法：

通常不在模型本身，而在检索质量，包括文档清洗、切块策略、召回策略、重排质量和 Prompt 约束。很多 RAG 系统效果差，不是因为模型不够强，而是因为前面的资料准备和检索链路做得不够好。

9.2 RAG 一定要向量数据库吗？​

标准答法：

不一定。向量检索很常见，但不是唯一方案。关键词检索、倒排索引、混合检索都可以构成 RAG。关键不在“是不是向量库”，而在“能不能把相关资料稳定找出来”。

9.3 RAG 和搜索引擎有什么区别？​

标准答法：

搜索引擎核心是返回候选结果列表，RAG 则是在检索结果基础上进一步把内容喂给模型，由模型做综合生成。也就是说，RAG 往往是“检索 + 生成”的组合系统。

10. 常见误区​

  • 误区一：把 RAG 等同于向量数据库。 向量库只是实现手段之一。
  • 误区二：以为接上文档就一定更准。 如果检索噪音很大，效果可能更差。
  • 误区三：只看最终回答，不拆检索指标。 这样很难定位问题根因。
  • 误区四：以为 RAG 可以完全代替微调。 两者解决的问题并不相同。

11. 速记要点​

  • RAG = 检索增强生成
  • 增强的是 运行时上下文
  • 标准流程：切块 -> 向量化 -> 检索 -> 重排 -> 生成
  • 难点主要在 切块、召回、重排、约束生成
  • 和微调的区别是：RAG 改上下文，微调改参数