RAG on Renxin's Blog

RAG 是什么？从一条文档的完整旅程说起

Fri, 10 Jul 2026 00:00:00 +0000

你有没有想过一个问题——

LLM 训练时读了几万亿字的互联网数据，几乎什么都知道。但它不知道你的业务数据——你的产品手册、售后政策、内部文档、客服对话记录。这些它没读过。

怎么让它知道该知道的？

这就是 RAG 要解决的问题。这篇文章从为什么需要 RAG 开始，一直讲到它的完整架构和最容易翻车的地方。

LLM 什么都知道，但不知道你的业务

LLM 有两个先天缺陷，在实际落地中很难绕过去。

缺陷	表现	影响
知识截止	训练数据停在某个时间点	问最新政策、实时数据，它不知道
不知道私有数据	没读过你的内部文档、产品手册、客服记录	业务场景下基本不可用

怎么解决？目前有三条路可以走。

方案一：微调（Fine-tuning）

拿业务数据继续训练模型，让它把新知识学进去。

听起来最直接，但实际操作成本很高。你需要准备高质量的训练数据、处理算力资源，而且每次业务文档更新了，又得重新训一遍。更麻烦的是，微调可能会破坏模型原有的通用能力——模型学会了你的业务术语，但写邮件的能力反而变差了。

方案二：塞长上下文（Long Context）

把所有资料都塞进 Prompt 里，让模型自己翻。

实现最简单，不用动模型。现在有些模型支持 128K、1M 甚至更长的上下文，看起来够用。但实际效果没那么理想：一是 Token 成本会随着内容量线性增长；二是内容太多之后，模型很难从海量信息中找到准确的那一段——这就是著名的"大海捞针"问题。上下文再长，检索精度是会下降的。

方案三：RAG（检索增强生成）

每次提问的时候，先去知识库里检索相关内容，拼到 Prompt 里，再让 LLM 基于这些材料回答。

RAG 是目前最主流的方案。原因很实在：

成本低：不需要重新训练模型，省了算力
更新快：知识库加个文档就行，不需要重训
可追溯：LLM 是看着你给的资料回答的，能知道它引用的是哪份文档
幻觉少：基于具体材料生成，比凭空回答可靠得多

当然，RAG 也有自己的问题——它依赖检索质量。如果检索到的内容不对或者不完整，LLM 材料再好也回答不对。后面会详细讲这个。

RAG 不是搜索引擎——它和搜索引擎的区别

很多人第一次接触 RAG 的反应是：这不就是搜索引擎吗？用户搜关键词，系统返回匹配的文档——有什么新鲜的？

这个理解对了一半，错的一半恰好是 RAG 的核心。

搜索引擎（ES/BM25）怎么工作

你搜一个关键词，搜索引擎在你的文档库里找到包含这个词的所有文档，按匹配度排序返回。它做的是关键词精确匹配。

比如说你搜"2025年Q3营收"，它能找到包含这几个词的那份财报。但如果你问"去年第三季度营收怎么样？"，它可能找不到——因为文档里写的是"2025年Q3营收同比增长15.3%"，关键词对不上。

%%{init: {'theme':'neutral'}}%%
graph LR
 A["搜：去年第三季度营收怎么样？"] --> B[ES 关键词匹配]
 B --> C["找到「去年」「第三」「季度」「营收」"]
 C --> D[❌ 文档写的是「Q3营收同比增长15.3%」
关键词对不上，找不到]

这是一直以来搜索引擎的运作方式。在"搜文档、找文件"的场景下非常好用，但在"回答问题"的场景下就显得力不从心。

RAG（向量检索）怎么工作

RAG 不一样。它先把你的文档库转成一组向量（可以理解成一组数字坐标），用户提问时也把问题转成向量，然后计算问题向量和文档向量之间的距离。距离越近，说明内容越相关。

%%{init: {'theme':'neutral'}}%%
graph LR
 A["同样的问题：去年第三季度营收怎么样？"] --> B[RAG 向量检索]
 B --> C[把问题和文档都转成向量
计算语义距离]
 C --> D[✅ 匹配到「Q3营收同比增长15.3%」
语义相近，找到了]

“去年第三季度营收怎么样？“和"2025年Q3营收同比增长15.3%“在字面上没有共同的关键词，但在语义上是同一件事。向量检索能捕捉到这种语义上的相近。

维度	搜索引擎（ES/BM25）	RAG（向量检索）
匹配方式	关键词精确匹配	语义匹配
搜"苹果”	返回含"苹果"二字的所有文档	能区分你在问水果还是手机品牌
输出	文档列表	相关内容 + LLM 生成的自然语言回答
适合场景	搜文档、找文件	回答问题、知识问答
局限性	同义词、近义词不识别	对数字/专有名词匹配不如精确搜索

所以搜索引擎和 RAG 不是替代关系，而是互补关系。生产环境最常用的方案是混合检索：向量检索负责语义匹配，BM25 负责精确匹配，两者互补。

但语义检索有一个前提条件：内容必须被正确地理解和切分。这就引出了下一个问题。

一条文档在 RAG 系统中的完整旅程

语义匹配的效果，很大程度上取决于文档在入库时被处理成了什么样子。一条文档从上传到最终被 LLM 用来回答问题，中间经历了一整套加工管道。

RAG 系统完整管道：入库阶段 → 检索阶段（点击图片查看大图）

入库阶段：让机器能"读懂"文档

环节	做什么	为什么重要
文档解析	把 PDF、Word、HTML 等格式转成纯文本	PDF 看着是文字，实际是一堆坐标指令。解析不好，后面的所有环节都白费
文本清洗	去噪、去重、格式归一化	把乱码、多余的空格、无关的页眉页脚清掉
分块	把长文本切成语义完整的片段	不能整篇检索——太大了检索不准，太小了语境不够
向量化	用 Embedding 模型把文本片段转成向量	向量是语义匹配的基础
存入向量库	把向量和原文存入向量数据库	供后续检索使用

检索阶段：找到相关内容并让 LLM 回答

环节	做什么
问题向量化	把用户提问也转成向量
向量检索	在向量库里找距离最近的文档片段
重排序	对检索结果重新精排，提升 Top 结果的准确率
拼入 Prompt	把检索到的内容拼到 Prompt 里，加上指令让 LLM 基于材料回答

为什么检索质量是关键

整个管道里，最核心的瓶颈不是 LLM 本身，而是检索质量。

Andrew Ng 在一个分享里提过一个数据：优化 RAG 系统时，检索质量的提升对最终答案准确率的影响远大于模型本身的升级。换句话说，用更强的模型不能弥补检索结果差的问题——模型再聪明，材料给错了也答不对。

而检索质量又依赖于前面的入库环节：文档解析是否正确、分块是否合理、向量化是否准确。这是一个完整的链路，短板出在任何一环都会影响最终效果。

最容易在哪里翻车？

把各个环节按翻车概率排序，前三个是：

1. 文档解析——最大的坑

你传上去的文档是 PDF。PDF 看着是文本，但本质上是一堆坐标指令的集合——“在坐标 (x,y) 处渲染字符 A，在 (x+5,y) 处渲染字符 B”。它并不知道什么是段落、什么是表格、什么是页眉。

遇到以下几种 PDF，解析很容易翻车：

PDF 类型	难度	翻车方式
数字原生 PDF	⭐ 简单	基本没问题
扫描件 PDF（图片）	⭐⭐⭐ 中等	需要 OCR，识别率取决于清晰度
双栏/多栏排版	⭐⭐⭐⭐ 困难	阅读顺序恢复错误，左右栏混在一起
含表格 PDF	⭐⭐⭐⭐⭐ 极难	无线框表格、合并单元格、跨页表格，很容易解析错位
含公式 PDF	⭐⭐⭐⭐⭐ 极难	LaTeX 公式、化学结构式，专用模型才能处理好

2. 分块——切得不合适

解析完的文本不能整篇扔进去检索。整篇检索的问题：一篇文档可能几千字，但用户问的只是其中一小段。整篇匹配会让不相关的内容稀释相关内容的信号。

但切得太细也不行。比如只切一两句话——检索时可能命中了，但上下文缺失，LLM 看了也不知道前因后果。

这就是分块的核心矛盾：检索精度 vs 上下文完整性。切小了检索精准但语境不足，切大了语境完整但检索不精准。

实际生产中有好几种分块策略来解决这个矛盾——按固定大小切、按语义边界切、按文档结构切、父子分块等等。每种策略各有优缺点，选型取决于你的文档类型和场景。

3. 检索——精确匹配 vs 语义匹配的盲区

即使解析和分块都做好了，检索环节仍然可能翻车。典型场景：

找不到相关内容：你的文档里确实有答案，但向量检索没把它排到前面
找到太多噪音：检索返回了大量不太相关的内容，稀释了有效信号
数字/专有名词匹配弱：向量检索对"Q3-2025营收同比增长率15.3%“这种精确表达不如关键词搜索

这也是为什么生产环境通常用混合检索——语义 + 关键词组合，取长补短。

回头看看

把整篇文章的问题串起来：

LLM 不知道你的业务数据
 → 三种方案对比，RAG 最实用（成本低、更新快、可追溯）
 → RAG 不是搜索引擎，是语义匹配
 → 但语义匹配的前提是内容被正确加工
 → 入库阶段：解析 → 清洗 → 分块 → 向量化 → 存储
 → 检索阶段：检索 → 重排序 → 拼入 Prompt → 生成
 → 最容易翻车的地方：解析、分块、检索

RAG 看起来简单——“查资料再回答”——但做了才发现，每一步都有坑。理解了这个全貌，后续不管是选型还是排查问题，都知道问题可能出在哪一环。

参考资料

Andrew Ng, Building RAG Agents with LLMs, DeepLearning.AI, 2025 — 检索质量对 RAG 效果影响的分享
Lewis et al., Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, arXiv:2005.11401, 2020 — RAG 论文原文

向量化原理——为什么向量能算语义相似度

Fri, 10 Jul 2026 00:00:00 +0000

你有没有想过一个问题——

RAG 的核心是「语义匹配」：你说「去年第三季度营收怎么样」，它能找到文档里写的「Q3 营收同比增长 15.3%」。字面不一样，但意思一样。

这到底是怎么做到的？一段文字怎么变成一个「向量」？为什么两个向量离得近就代表意思相近？

这篇文章从最基础的概念讲起，不涉及复杂的数学公式。

人能判断语义相似度，机器也能

先想一个简单的问题：人和人之间怎么判断两句话意思差不多？

「今天天气真好」和「今天阳光明媚」——你一看就知道它们说的是一回事。

背后的过程很复杂（你用了多年的语言经验、对词汇的理解、对语境的把握），但直觉上很简单：你在大脑里给这两句话各自建立了一个「语义位置」，发现它们靠得很近。

机器做同样的事，只是用的方法不一样——它用向量来表示语义位置。

向量是什么？一组数字而已

向量听起来很高深，其实就是一组数字。

[0.52, -0.13, 0.87, -0.42, 0.11, ...]

你可以把向量想象成语义空间中的一个坐标点。

比如我们想象一个二维的语义空间，每一段话都对应一个坐标点：

「今天天气真好」→ 坐标 (0.9, 0.3)
「今天阳光明媚」→ 坐标 (0.8, 0.4)
「苹果很好吃」 → 坐标 (0.1, 0.2)

在语义空间里，「今天天气真好」和「今天阳光明媚」靠得近（意思相近），和「苹果很好吃」离得远（不相关）。

二维语义空间示意：意思相近的文本在空间中靠得近

当然，现实中的语义向量不是两维，而是几百甚至几千维——但原理一样。两个向量在空间中的距离越近，代表它们的意思越相近。

语义从哪来：Embedding 模型怎么训练的

刚才的水果例子是我手动编的维度（甜度、大小）。但在真实场景中，不可能有人来给每个词标注「甜度 = 0.9」这种数据。

那向量的数值从哪来？答案是 Embedding 模型自己学出来的。

训练方法的核心思路很简单：出现在相似语境中的词，应该有相似的向量。

一个经典的例子：

「国王」和「女王」经常出现在类似的句子里（「__ 统治着国家」「__ 戴着一顶王冠」）。所以它们的向量应该离得近。

「国王」和「苹果」很少出现在同一个语境里。所以它们的向量应该离得远。

训练时，模型会读海量的文本，对每个词做一个调整：如果两个词经常出现在相似的上下文里，就把它们的向量拉近一点；如果很少同时出现，就把它们推远一点。

经过无数次这样的调整，模型最终学会了一个语义空间——意思相近的词，在空间里靠得近；意思不相关的词，离得远。

这一步就是 Embedding 模型做的事。你给它输入一段文本，它返回一组向量。

%%{init: {'theme':'neutral'}}%%
graph LR
 A["输入文本
去年第三季度赚了多少"] --> B[Embedding 模型]
 B --> C["输出向量
[0.23, -0.56, 0.91, ...]"]

 style A fill:#dbeafe,stroke:#3b82f6,color:#1e3a5f
 style B fill:#d1fae5,stroke:#10b981,color:#064e3b
 style C fill:#fce7f3,stroke:#ec4899,color:#831843

如何判断两个向量离得近

有了向量之后，怎么计算两段文字的相似度？

最常用的方法叫余弦相似度（Cosine Similarity）。你不需要记住公式，只要理解它的直觉：

两个向量在空间中有一个夹角。夹角越小，说明方向越一致，内容越相似。

完全相同的文本 → 夹角 0°，相似度 = 1
完全不相关的文本 → 夹角 90°，相似度 ≈ 0
意思相反的文本 → 夹角 180°，相似度 = -1

%%{init: {'theme':'neutral'}}%%
graph LR
 A["文本A: 今天天气真好"] --> C[Embedding 模型]
 B["文本B: 今天阳光明媚"] --> C
 C --> D["向量A: [0.8, 0.5, ...]
向量B: [0.7, 0.6, ...]"]
 D --> E["余弦相似度 = 0.92
✅ 意思相近"]

 style A fill:#dbeafe,stroke:#3b82f6,color:#1e3a5f
 style B fill:#dbeafe,stroke:#3b82f6,color:#1e3a5f
 style C fill:#d1fae5,stroke:#10b981,color:#064e3b
 style D fill:#fce7f3,stroke:#ec4899,color:#831843
 style E fill:#d1fae5,stroke:#10b981,color:#064e3b

回到 RAG：向量检索就是这样工作的

RAG 的检索过程，就是把上面的逻辑倒过来：

入库时：把每篇文档的每个片段都通过 Embedding 模型转成向量，存进向量数据库
查询时：把用户的问题也转成向量
匹配时：计算问题向量和所有文档向量的余弦相似度，找出最接近的那几个片段

用户问题：去年第三季度我们赚了多少钱？
 │
 ▼ Embedding 模型
 │
[0.23, -0.56, 0.91, ...]
 │
 ▼ 跟库里所有文档向量算相似度
 │
文档中匹配到的内容：Q3营收同比增长15.3%（相似度 0.87）
 去年全年营收1.2亿元（相似度 0.45）
 公司成立于2018年（相似度 0.12）
 │
 ▼ 取 Top-K，拼入 Prompt
 │
LLM 基于这些内容生成回答

向量检索不只是「找到包含关键词的文档」，而是「找到意思最相近的内容」。这也解释了为什么在 RAG 中，分块和向量化的质量决定了检索的天花板——如果文档切得不好、向量化得不准确，后面用多好的 LLM 也弥补不了。

参考资料

Mikolov et al., Efficient Estimation of Word Representations in Vector Space, arXiv:1301.3781, 2013 — Word2Vec，向量化技术的奠基论文
Reimers & Gurevych, Sentence-BERT: Sentence Embeddings using Siamese BERT-Networks, EMNLP 2019 — 现代 Embedding 模型的基础架构
Datawhale, hello-agents, 第八章记忆与检索, https://github.com/datawhalechina/hello-agents — 从认知科学到向量检索的实践教程