AI基础之RAG讲解

目录

1 RAG

1.1 定义

1.1.1 简介

RAG（Retrieval-Augmented Generation，检索增强生成）核心思路就一句话：让大模型在回答问题之前，先去外部知识库里检索相关资料，然后基于这些资料来生成回答。
打个比方，大模型就像一个学生参加开卷考试——与其死记硬背所有知识（预训练），不如带着参考书进场，需要的时候翻一翻。RAG 就是给大模型配的这本 "参考书"。

1.1.2 RAG 分类

RAG分类：

  • Agentic RAG（智能体化 RAG）
    传统的 Naive RAG 是 "用户问 → 检索 → 生成" 的单次流程。而 Agentic RAG 引入了 Agent 的决策能力——模型可以自主判断需不需要检索、检索什么、检索结果够不够用、要不要换个策略再搜一遍。从被动检索变成了主动决策。
  • Graph-RAG（图检索增强）
    传统 RAG 基于向量相似度检索，擅长找语义相近的内容，但不擅长处理实体之间的关联关系。Graph-RAG 结合知识图谱，能在实体和关系层面做更精准的推理。微软开源的 GraphRAG 框架在这方面做了很好的探索。
  • Context Engineering（上下文工程）
    这是 2025 年 RAG 领域最重要的认知转变——RAG 的本质不是 "检索增强生成"，而是 "上下文工程"。核心关注点从 "怎么检索到相关文档" 升级为 "怎么为模型构造最合适的上下文"，包括上下文的选取、排序、压缩、冲突处理等。

1.1.3 为什么需要 RAG

那为什么需要 RAG？ 直接让大模型回答不行吗？还真不太行，因为大模型有几个绕不开的硬伤：

大模型的硬伤 具体表现 RAG 如何解决
幻觉问题 一本正经地胡说八道，编造不存在的事实 基于检索到的真实文档生成回答，有据可依
知识截止 训练数据有截止日期，不知道最新的信息 知识库可以随时更新，突破时间限制
领域知识不足 对企业内部文档、专业知识了解有限 接入企业私有数据，补齐领域短板
无法溯源 不知道回答的依据是什么，无法验证 可以追溯引用来源，提供文档出处

大模型的痛点：

  • 幻觉（Hallucination）
    这是大模型最被诟病的问题。大模型的本质是 接龙——基于上文预测下一个最可能的 Token。它并不真正 理解 事实，只是在做概率预测。所以当它不确定的时候，它会编一个看起来很合理的答案，而不是老老实实说 "我不知道"。
    这块幻觉问题当年坑了不少人。早期很多团队直接拿 GPT-3.5 做企业客服，结果模型一本正经地给客户推荐了不存在的产品，场面一度非常尴尬。
  • 知识截止（Knowledge Cutoff）
    大模型的知识来源于训练数据，训练完就 "定格" 了。你问它 2025 年发生的新闻事件，它要么不知道，要么靠编。对于需要实时信息的场景（股价、新闻、政策更新），裸用大模型基本不可行。
  • 私有知识缺失
    大模型的训练数据是公开的互联网语料。你们公司的内部文档、产品手册、客户 FAQ，它统统没见过。你让它回答 "我们公司 XX 产品的退货政策是什么"，它只能瞎编。
  • 成本与可控性
    微调模型来注入新知识？可以，但成本高、周期长，而且每次知识更新都得重新训练。对于频繁变化的知识场景，这显然不现实。

1.2 RAG 核心流程

1.2.1 核心流程

e36a696ced012345e7be77848b85447c_6881445ebbab44adab7b89afc9e59f29

上图展示了 RAG 的完整架构，分为离线和在线两大阶段：

  • 离线阶段（知识库构建）：把各种格式的文档解析成纯文本，切成合适大小的片段（Chunk），用 Embedding 模型编码成向量，存入向量数据库。这一步是地基，文档解析质量、切分策略、Embedding 模型选型都会直接影响最终的检索效果。
  • 在线阶段（查询与生成）：用户提问后，把问题也编码成向量，在向量库里做相似度检索，找出最相关的几段文本。然后把这些文本塞进 Prompt 里，交给大模型生成最终回答。其中 Rerank（重排序）这一步很关键，用 Cross-Encoder 对初步检索结果做精排，能显著提升准确率。

1.2.2 Embedding（向量嵌入）

Embedding（向量嵌入） 就是把一段文本转换成一个浮点数数组（向量），这个数组是这段文本的 语义指纹。比如输入 "今天天气真好"，Embedding 模型会输出类似这样的结果：[0.012, -0.034, 0.567, -0.189, 0.423, ..., 0.078] ← 共 1536 个浮点数
1536 维的意思是：这个浮点数数组有 1536 个元素。每个元素是一个 float 值，比如 0.012、-0.034。这 1536 个数共同编码了这段文本的语义信息。

核心逻辑：语义相近的文本，它们的向量在高维空间中距离也相近。 所以可以通过计算两个向量的距离（余弦相似度）来判断两段文本在语义上有多相似——这就是 RAG 中向量检索的底层原理。

1.2.3 为什么要1536维

1536 维——为什么是这个数字？
说实话，1536 这个数字本身没有特别的含义，它不是什么 "最优解"，而是 OpenAI 在设计 text-embedding-ada-002 模型时选定的一个参数。后来 text-embedding-3-small 延续了这个维度。
但它背后的逻辑是有道理的：

维度 语义表达能力 存储成本 计算成本 适用场景
128~256 维 一般 低 低 简单分类、大规模初筛
768 维 较好 中 中 BERT 系列、轻量级 RAG
1024 维 好 中 中 BGE-M3，多语言 RAG
1536 维 很好 较高 较高 主流 RAG 系统
3072 维 极好 高 高 高
8192+ 维 极强 很高 很高 研究探索，极少生产使用

简单来说：维度越高，能编码的语义信息越丰富，但存储和计算成本也越高。 1536 维是当前 RAG 系统中性价比最好的选择之一。
举个直觉上的例子：假设用 3 维向量表示一个人 [身高, 体重, 年龄]，只能编码很有限的信息。但如果用 100 维 [身高, 体重, 年龄, 收入, 学历, 兴趣1, 兴趣2, ...]，就能更精确地区分不同的人。Embedding 的维度也是这个道理——1536 个维度就是 1536 个 "语义特征轴"，足以精细地刻画文本的语义。
1536 维的向量，每个 float 占 4 字节，一条就是 6KB。百万级文档就是 6GB 的纯向量数据。选择维度要在效果和成本之间找平衡点

1.2.4 语义相似度怎么算

有了向量之后，怎么判断两段文本是否语义相近？
靠计算向量之间的距离，最常用的是余弦相似度。
image

上图展示了余弦相似度的计算逻辑：文本 A "怎么退货" 和文本 B "退换货政策" 的余弦相似度是 0.96，说明语义非常接近。虽然字面差异很大，但 Embedding 模型理解了它们的语义是相同的文本 A 和文本 C "北京天气预报" 的余弦相似度只有 0.12，说明语义不相关，不会被错误地检索到
除了余弦相似度（关注向量方向（角度），不受向量长度影响），还有欧氏距离（L2，关注绝对位置差异，受向量长度影响）和内积（IP）等度量方式。文本语义检索场景一般用余弦相似度，因为它关注方向而不是绝对大小，对文本长度不敏感。

1.3 RAG vs 微调 vs 长上下文

很多人一听到 "给大模型补充知识"，就只知道 RAG。但面试官可能追问：除了 RAG，还有别的方式吗？这时候得知道怎么对比选型。

维度 RAG 微调（Fine-tuning） 长上下文（Long Context）
核心作用 注入外部知识 改变模型行为风格 扩大单次输入窗口
知识更新 随时更新知识库 需重新训练 更新输入内容即可
成本 低 中高（算力 + 数据） 按 Token 计费，量大时成本高
幻觉控制 较好，有检索约束 一般 取决于上下文中的信息量
适用场景 知识密集型问答、企业知识库 特定格式输出、风格定制 全文分析、长文档摘要
响应延迟 多了检索环节，略高 无额外开销 输入越长延迟越高
典型代表 LangChain + Chroma LoRA / QLoRA GPT-4o（128K）、Gemini（1M+）

说句实话，这三者不是互斥的。实际项目中经常组合使用——比如先微调模型让它熟悉你业务的回答风格，再用 RAG 注入实时知识，长上下文则用于需要通篇理解的场景。

1.4 RAG 相关问题

RAG 的检索效果不好怎么优化？

优化 Chunk 策略（语义切分替代固定长度切分）、加 Rerank 重排序、使用 Hybrid Search（稠密向量 + 稀疏关键词检索融合）、Query 改写（把用户的口语化问题改写成更适合检索的 Query）、升级 Embedding 模型。

RAG 和微调什么时候用哪个？能不能一起用？

知识用 RAG，能力用微调。知识频繁变化的场景选 RAG，需要改变模型行为风格的场景选微调。两者完全可以组合使用。

现在大模型上下文窗口越来越大了（比如 Gemini 支持 100 万 Token），还需要 RAG 吗？

RAG 仍有独特优势：成本低（不用把所有文档都塞进去）、延迟低（检索几段比塞入整本文档快）、可溯源（知道答案来自哪段文档）。而且不是所有场景都需要通篇理解，很多时候只需要精准的几段话就够了。

posted @ 2026-06-06 16:48  上善若泪  阅读(19)  评论(0)    收藏  举报