大语言模型基础：Token、Embedding、Transformer、KV Cache 与 RAG

1. 整体知识框架

理解大语言模型，可以先记住两条主线：

LLM 生成主线

文字
 ↓
Tokenizer
 ↓
Token
 ↓
Token ID
 ↓
Embedding Table
 ↓
每个 Token 一个初始高维向量
 ↓
加入位置信息
 ↓
多层 Transformer
 ↓
每个 Token 得到上下文化 Hidden State
 ↓
取当前最后位置的 Hidden State
 ↓
LM Head
 ↓
Vocabulary Logits
 ↓
选择下一个 Token
 ↓
KV Cache + Decode
 ↓
继续预测下一个 Token
 ↓
最终回答

RAG 检索主线

文档
 ↓
Chunk 切分
 ↓
Embedding Model
 ↓
每个 Chunk 一个高维语义向量
 ↓
Vector Database

用户问题
 ↓
Embedding Model
 ↓
Query Vector
 ↓
Cosine Similarity / Euclidean Distance / Dot Product
 ↓
Top-K
 ↓
找到最相关的 Chunks
 ↓
用户问题 + 检索结果
 ↓
LLM
 ↓
最终回答

---

2. Token 是什么？

大语言模型并不是直接以"汉字"或者"英文单词"为单位处理文本，而是先通过 Tokenizer（分词器） 将文本切分成一个个 Token。

Token 可以理解为：

模型处理文本的基本离散单位。

一个 Token 可能是：

• 一个汉字
• 多个汉字组成的片段
• 一个英文单词
• 一个英文单词的一部分
• 标点符号
• 空格
• 其他字符片段

例如：

原始文本：

我爱人工智能

经过 Tokenizer 后可能得到：

["我", "爱", "人工", "智能"]

也可能使用其他切分方式。

具体如何切分取决于模型使用的 Tokenizer 和 Vocabulary。

所以：

Token ≠ 汉字

Token ≠ 单词

Token 是 Tokenizer 根据自己的词表和规则切出来的文本单位。

---

3. Token 和 Token ID

Tokenizer 不仅负责切分文本，还会根据自己的 Vocabulary（词表），将每个 Token 转换成一个整数编号。

这个整数就是：

Token ID

例如假设：

"我"   → Token ID 1024
"爱猫" → Token ID 5837

那么：

"我爱猫"
   ↓
Tokenizer
   ↓
["我", "爱猫"]
   ↓
[1024, 5837]

其中：

1024
5837

就是两个 Token ID。

可以把 Vocabulary 理解成一张巨大的映射表：

Token	Token ID
"我"	1024
"你"	2048
"猫"	8921
"hello"	15339
...	...

---

4. 同一个 Token 的 Token ID 一样吗？

在同一个 Tokenizer 和 Vocabulary 中：

同一个 Token 对应固定的 Token ID。

例如：

"猫" → 8921

只要使用的是同一个 Vocabulary，那么 "猫" 对应的 ID 就不会一会儿是 8921，一会儿变成 1234。

但是：

不同模型 / 不同 Tokenizer 之间，同一个文本片段的 Token ID 不一定相同。

例如：

模型 A：

"hello" → 15339


模型 B：

"hello" → 8821

甚至两个模型的 Tokenizer 可能连切分结果都不一样。

例如：

ChatGPT

一个 Tokenizer 可能切成：

["Chat", "GPT"]

另一个可能切成：

["Chat", "G", "PT"]

因此：

Token ID 本身没有语义，它本质上只是 Token 在 Vocabulary 中的索引编号。

---

5. Token ID 如何变成高维向量？

神经网络不能直接通过：

5837

这样的编号理解语义。

所以 LLM 内部有一张很大的参数矩阵：

Embedding Table（嵌入矩阵）

Token ID 可以理解成这张表的行索引。

例如：

Token ID = 5837
       ↓
Embedding Table
       ↓
找到第 5837 行
       ↓
[0.12, -0.53, 0.87, 0.21, ...]

于是：

一个 Token ID → 一个初始高维向量。

假设：

"我爱猫"

被切成：

["我", "爱猫"]

对应：

[1024, 5837]

然后查 Embedding Table：

1024
 ↓
X1 = [0.21, -0.53, 0.87, ...]


5837
 ↓
X2 = [0.72, 0.11, -0.36, ...]

所以：

2 个 Token
 ↓
2 个 Token ID
 ↓
2 个初始高维向量

如果模型隐藏维度是 4096，那么每个 Token 会得到一个 4096 维向量。

---

6. Token Embedding 和上下文化向量不是一回事

这是非常重要的区别。

Token ID 通过 Embedding Table 得到的是：

初始 Token Embedding

例如：

"猫"
 ↓
Token ID：8921
 ↓
Embedding Table
 ↓
[0.12, -0.51, 0.83, ...]

对于同一个模型，这个初始 Embedding 是模型参数的一部分。

但是考虑：

我喜欢猫

机器猫是一部动画

他是一个夜猫子

虽然其中可能出现相同的 "猫" Token，但上下文完全不同。

所以经过 Transformer 后，这个位置对应的向量会根据上下文发生变化：

Token ID
 ↓
Embedding Table
 ↓
初始 Token Embedding
 ↓
Transformer
 ↓
结合上下文
 ↓
Contextualized Hidden State
上下文化隐藏向量

因此可以理解为：

Embedding Table 给 Token 一个初始表示；Transformer 再根据上下文不断加工这个表示。

---

7. 为什么要经过多层 Transformer？

得到初始 Token Embedding 后，模型还没有充分理解 Token 之间的关系。

例如：

小明没有去上班，因为他生病了。

模型不仅需要处理：

小明
上班
生病

还需要结合上下文理解：

"他"
 ↓
指的是
 ↓
"小明"

以及：

为什么没去上班？
 ↓
因为生病

Transformer 中的 Self-Attention 等机制允许不同位置之间进行信息交互。

因此：

初始 Token Embedding
       ↓
Transformer Layer 1
       ↓
第一层上下文表示
       ↓
Transformer Layer 2
       ↓
进一步融合和变换
       ↓
Transformer Layer 3
       ↓
...
       ↓
Transformer Layer N
       ↓
最终上下文化表示

假设有三个 Token：

Token 1
Token 2
Token 3

经过第一层：

H1¹
H2¹
H3¹

第二层：

H1²
H2²
H3²

一直到第 N 层：

H1ᴺ
H2ᴺ
H3ᴺ

可以粗略理解：

每经过一层 Transformer，每个 Token 的表示都会进一步融合上下文并进行特征变换，多层堆叠使模型能够形成越来越复杂的表示。

但不能机械地认为：

Layer 1 = 识字
Layer 2 = 语法
Layer 3 = 推理

真实模型内部并没有这样严格的人工分工。

---

8. 大语言模型如何预测下一个 Token？

假设输入：

我爱猫

为了方便说明，假设 Tokenizer 将其切成：

["我", "爱猫"]

完整过程：

文字："我爱猫"
      ↓
Tokenizer
      ↓
["我", "爱猫"]
      ↓
Token ID
[1024, 5837]
      ↓
Embedding Table
      ↓
两个初始高维向量
      ↓
加入位置信息
      ↓
Transformer Layer 1
      ↓
Transformer Layer 2
      ↓
...
      ↓
Transformer Layer N
      ↓
得到两个最终 Hidden States

H1ᴺ
H2ᴺ
      ↓
取当前最后位置 H2ᴺ
      ↓
LM Head
      ↓
整个 Vocabulary 的 Logits
      ↓
Softmax / Sampling 等
      ↓
选择下一个 Token ID
      ↓
Tokenizer Decode
      ↓
例如："很"

模型实际上会对整个 Vocabulary 中的 Token 计算分数。

例如简化成：

候选 Token	概率
"我"	1%
"你"	1%
"猫"	3%
"很"	70%
"可爱"	15%
"漂亮"	6%
<EOS>	4%

那么模型可能选择：

"很"

作为下一个 Token。

---

9. 为什么使用最后一个位置的 Hidden State？

Decoder-only LLM 是自回归模型。

假设当前已经有：

我 爱猫

现在模型要解决的问题其实是：

我 爱猫 [???]

在因果注意力机制下，当前最后位置的 Hidden State 已经融合了它能够看到的前面上下文。

所以：

最后位置 Hidden State
       ↓
LM Head
       ↓
Vocabulary Logits
       ↓
选择下一个 Token

需要注意：

不是把最后一个 Hidden State 再重新交给整个大模型。

Transformer 本身就是大模型主体的一部分。

正确理解是：

Transformer
 ↓
最后位置 Hidden State
 ↓
LM Head
 ↓
下一个 Token

---

10. 生成一个 Token 后会发生什么？

假设：

我爱猫

模型预测：

很

那么逻辑上下一次模型面对的序列就是：

我爱猫很

然后预测：

可爱

于是：

我爱猫很可爱

再预测：

。

得到：

我爱猫很可爱。

继续预测，直到：

• 生成 <EOS> 等结束 Token
• 达到最大输出长度
• 命中停止序列
• 或触发其他停止条件

因此生成过程可以理解为：

Prompt
 ↓
预测 Token 1
 ↓
Prompt + Token 1
 ↓
预测 Token 2
 ↓
Prompt + Token 1 + Token 2
 ↓
预测 Token 3
 ↓
...

这就是：

Autoregressive Generation（自回归生成）

即：

模型根据之前已经存在和已经生成的 Token，不断预测下一个 Token。

---

11. 每生成一个 Token，都要把前面的全部重新计算吗？

从逻辑上看：

每次预测都基于全部历史上下文。

但工程实现上：

通常不会把所有历史 Token 从头完整计算一遍。

否则会产生大量重复计算。

这就引出了：

KV Cache

---

12. Prefill 和 Decode

LLM 推理通常可以分成两个重要阶段：

1. Prefill
2. Decode

---

12.1 Prefill

假设用户输入：

我爱猫

模型首先：

Prompt
 ↓
Tokenizer
 ↓
所有 Input Tokens
 ↓
Embedding
 ↓
多层 Transformer
 ↓
一次处理整个 Prompt
 ↓
建立各 Transformer Layer 的 KV Cache
 ↓
得到下一个 Token 的预测

这个阶段叫：

Prefill

特点：

主要处理用户已经提供的大量输入 Token，可以利用 GPU 做较强的并行计算。

---

12.2 Decode

假设模型预测出的第一个输出 Token 是：

很

接下来不需要把：

我爱猫

从头完整计算一遍。

而是：

新 Token："很"
       ↓
Embedding
       ↓
进入 Transformer
       ↓
读取历史 KV Cache
       ↓
计算当前新 Token
       ↓
把当前 Token 的 K/V 加入 Cache
       ↓
预测下一个 Token："可爱"

然后：

新 Token："可爱"
       ↓
读取已有 KV Cache
       ↓
继续计算
       ↓
预测："。"

这个阶段叫：

Decode

所以：

Prompt
 ↓
Prefill
 ↓
建立 KV Cache
 ↓
预测第一个输出 Token
 ↓
Decode
 ↓
Token 1
 ↓
Token 2
 ↓
Token 3
 ↓
...
 ↓
回答结束

---

13. KV Cache 是什么？

Transformer Attention 中会涉及：

Q = Query
K = Key
V = Value

历史 Token 的 K 和 V 已经计算过。

如果生成每一个新 Token 时都重新计算所有历史 Token 的 K/V，会造成大量重复计算。

因此可以把历史 Token 的 K/V 保存起来：

历史 Token
 ↓
计算 K、V
 ↓
保存
 ↓
KV Cache

生成新的 Token 时：

新 Token
 ↓
计算当前 Token
 ↓
读取历史 KV Cache
 ↓
Attention
 ↓
得到新的 Hidden State
 ↓
预测下一个 Token

而且：

Transformer 的每一层都有对应的 K/V Cache。

因此 KV Cache 大小与很多因素有关，例如：

• 模型层数
• 上下文长度
• Batch Size
• 并发请求数量
• K/V Head 数量
• 数据精度

所以在 LLM 推理部署中：

Context Length 增大
       ↓
KV Cache 增大
       ↓
显存占用增加
       ↓
可能影响 Batch / 并发
       ↓
影响吞吐量

因此 KV Cache 是 vLLM、TensorRT-LLM 等推理框架中的重要优化对象。

---

14. 完整 LLM 推理流程

                        大语言模型 LLM

用户输入文字
     ↓
Tokenizer
     ↓
多个 Token
     ↓
多个 Token ID
     ↓
Embedding Table
     ↓
每个 Token 一个初始高维向量
     ↓
加入位置信息
     ↓
Transformer Layer 1
     ↓
Transformer Layer 2
     ↓
...
     ↓
Transformer Layer N
     ↓
每个位置得到上下文化 Hidden State
     ↓
取当前最后位置 Hidden State
     ↓
LM Head
     ↓
整个 Vocabulary 的 Logits
     ↓
Softmax / Sampling 等
     ↓
选择下一个 Token ID
     ↓
Decode 成文字
     ↓
新 Token 加入当前序列
     ↓
利用 KV Cache
     ↓
Decode 下一个 Token
     ↓
不断循环
     ↓
最终回答

---

15. RAG 是什么？

RAG 全称：

Retrieval-Augmented Generation

中文：

检索增强生成

核心思想是：

先从外部知识库中检索与用户问题相关的资料，再把这些资料作为上下文交给 LLM 回答。

例如用户问：

我们公司的年假制度是什么？

LLM 本身可能不知道公司的内部规定。

RAG 可以先：

用户问题
 ↓
知识库检索
 ↓
找到公司年假制度文档
 ↓
把相关内容交给 LLM
 ↓
LLM 根据资料回答

---

16. RAG 中的 Embedding 是什么？

这里特别容易和 LLM 内部的 Token Embedding 混淆。

LLM 内部：

Token ID
 ↓
Embedding Table
 ↓
每个 Token 一个初始向量

而 RAG 的目标通常是：

使用一个高维向量表示一句话、一个 Query 或一个 Chunk 的整体语义。

例如：

猫是一种非常常见的家庭宠物。

经过 Embedding Model：

一段文字
 ↓
Tokenizer
 ↓
多个 Token
 ↓
Embedding Model
 ↓
内部处理多个 Token
 ↓
Pooling / 特定输出方式
 ↓
整段文本的一个高维向量

例如：

[0.17, -0.81, 0.34, ..., 0.52]

这个向量可以作为整段文本的语义表示，用于检索。

---

17. RAG 为什么要进行 Chunk 切分？

假设有一份：

100 页 PDF

一般不会直接让整份 PDF 只对应一个向量。

而是先切成：

原始文档
 ↓
Chunk 1
Chunk 2
Chunk 3
Chunk 4
...

然后：

Chunk 1 → Embedding → Vector 1
Chunk 2 → Embedding → Vector 2
Chunk 3 → Embedding → Vector 3
...

再存入：

Vector Database（向量数据库）

这样用户提问时，就可以找到最相关的几个局部文本片段，而不是把整份文档全部塞给 LLM。

---

18. RAG 的完整流程

文档入库阶段

原始文档
 ↓
解析文本
 ↓
Chunk 切分
 ↓
Chunk 1
Chunk 2
Chunk 3
...
 ↓
Embedding Model
 ↓
Vector 1
Vector 2
Vector 3
...
 ↓
Vector Database

---

用户查询阶段

用户问题
 ↓
Embedding Model
 ↓
Query Vector
 ↓
和 Vector Database 中的 Chunk Vector 比较
 ↓
Similarity / Distance Search
 ↓
Top-K
 ↓
找到最相关的几个 Chunks
 ↓
用户问题 + 检索到的 Chunks
 ↓
LLM
 ↓
最终回答

通常 Query 和文档 Chunk 应使用同一套或相互兼容的 Embedding Model，使它们处于可比较的向量空间。

---

19. RAG 怎么知道两个文本语义相似？

假设：

用户问题：
家养猫有什么特点？

Embedding：

用户问题
 ↓
Embedding Model
 ↓
Query Vector

知识库中有：

Chunk A：
猫是一种常见的家庭宠物。

Chunk B：
飞机依靠机翼产生升力。

Chunk C：
数据库可以用于保存结构化数据。

它们也分别有：

Vector A
Vector B
Vector C

现在需要解决：

Query Vector 到底和哪个 Chunk Vector 最相似？

这就需要使用向量之间的：

Similarity / Distance Metric（相似度 / 距离度量）

常见方法包括：

1. Cosine Similarity
2. Euclidean Distance
3. Dot Product

---

20. Cosine Similarity（余弦相似度）

Cosine Similarity 主要关注：

两个向量的方向是否相似。

公式：

cos⁡θ=A⋅B∥A∥∥B∥ \cos\theta = \frac{A \cdot B} {\|A\|\|B\|} cosθ=∥A∥∥B∥A⋅B

其中：

A、B = 两个向量
θ    = 两个向量之间的夹角

如果：

θ = 0°
cosθ = 1

表示完全同方向。

如果：

θ = 90°
cosθ = 0

表示正交。

如果：

θ = 180°
cosθ = -1

表示完全反方向。

在很多 Embedding 场景下：

Cosine Similarity 越高，通常表示两个文本的语义越接近。

例如：

用户：
家养猫有什么特点？

Chunk：
猫是一种常见的家庭宠物。

假设：

Cosine Similarity = 0.91

说明两个向量方向非常接近，因此这个 Chunk 很可能与用户问题相关。

---

21. Euclidean Distance（欧氏距离）

Euclidean Distance 又叫：

L2 Distance

它衡量的是：

两个向量对应的点在高维空间中的实际距离。

二维情况下：

A=(a1,a2) A=(a_1,a_2) A=(a1,a2)

B=(b1,b2) B=(b_1,b_2) B=(b1,b2)

那么：

d(A,B)=(a1−b1)2+(a2−b2)2 d(A,B)= \sqrt{ (a_1-b_1)^2+ (a_2-b_2)^2 } d(A,B)=(a1−b1)2+(a2−b2)2

三维：

d(A,B)=(a1−b1)2+(a2−b2)2+(a3−b3)2 d(A,B)= \sqrt{ (a_1-b_1)^2+ (a_2-b_2)^2+ (a_3-b_3)^2 } d(A,B)=(a1−b1)2+(a2−b2)2+(a3−b3)2

如果是 1024 维向量，道理完全相同，只不过计算 1024 个维度。

---

22. 欧氏距离在 RAG 中是干什么的？

如果一个 Embedding Model 学到的向量空间具有这样的性质：

语义越相似
 ↓
向量在空间中的位置越接近

那么就可以使用欧氏距离进行语义检索。

例如：

Query Vector = A

Chunk 1 Vector = B
Chunk 2 Vector = C

计算：

Distance(A, B) = 0.3

Distance(A, C) = 8.7

那么：

A 和 B 距离很近
→ Chunk 1 更可能和用户问题语义相关

A 和 C 距离很远
→ Chunk 2 相关性可能较低

因此：

Euclidean Distance 也可以用于 RAG / Vector Search 中寻找语义接近的文本。

判断方式：

距离越小
→ 向量越接近
→ 通常语义越相似

距离越大
→ 向量越远
→ 通常语义差异越大

---

23. Cosine Similarity 和 Euclidean Distance 的区别

假设：

A = (1,1)

B = (10,10)

两个向量指向完全相同的方向。

所以：

Cosine Similarity = 1

但是欧氏距离：

d(A,B)=(10−1)2+(10−1)2=162≈12.73 d(A,B)=\sqrt{(10-1)^2+(10-1)^2}=\sqrt{162}\approx12.73 d(A,B)=(10−1)2+(10−1)2 =162 ≈12.73

说明它们在空间中的实际位置相隔较远。

所以可以形象地理解：

Cosine Similarity：

"你们两个朝的方向像不像？"


Euclidean Distance：

"你们两个站的位置离得近不近？"

---

24. 两者都是为了语义检索吗？

在 RAG / Vector Search 场景中：

是的，两者都可以用于寻找语义相似的文本。

但是它们衡量相似性的方式不同。

方法	衡量什么	越相似时
Cosine Similarity	向量方向是否接近	值越大
Euclidean Distance	向量空间位置是否接近	距离越小
Dot Product	向量方向和长度的综合关系	通常值越大

所以 RAG 可以是：

Query Vector
 ↓
和所有 Chunk Vector 比较
 ↓
┌──────────────────────────────┐
│ Cosine Similarity            │
│ 或 Euclidean Distance        │
│ 或 Dot Product               │
└──────────────────────────────┘
 ↓
排序
 ↓
Top-K
 ↓
最相关 Chunks

具体选择哪一种，需要根据：

• Embedding Model 的训练方式
• 模型官方推荐
• Vector Database 配置

来决定。

---

25. Cosine 和 Euclidean 有什么关系？

如果两个向量都进行了 L2 Normalization（归一化）：

||A|| = 1
||B|| = 1

那么：

∥A−B∥2=2−2cos⁡θ \|A-B\|^2 = 2 - 2\cos\theta ∥A−B∥2=2−2cosθ

这意味着对于单位向量：

Cosine Similarity 越大
        ⇕
Euclidean Distance 越小

因此在向量已经归一化的情况下，两种方法得到的排序可能完全一致或非常接近。

---

26. 三种"向量"不要混淆

这是整个知识体系中非常重要的一点。

26.1 Token Embedding

Token ID
 ↓
Embedding Table
 ↓
一个初始高维向量

主要作用：

把离散 Token ID 转换成神经网络可以计算的连续向量。

---

26.2 Transformer Hidden State

Token Embedding
 ↓
多层 Transformer
 ↓
结合上下文
 ↓
Contextualized Hidden State

主要作用：

表示 Token 在当前上下文中的信息。

同一个 Token 在不同句子中的 Hidden State 可以不同。

---

26.3 RAG Text Embedding

一句话 / Query / Chunk
 ↓
Embedding Model
 ↓
一个高维向量

主要作用：

表示整段文本的语义，用于语义搜索、向量检索等。

---

27. Token 为什么也是 AI 的计费单位？

大模型的计算量与 Token 数量高度相关，因此很多 LLM API 按 Token 计费。

主要分成：

Input Tokens

发送给模型处理的内容，例如：

System Prompt
用户 Prompt
历史对话
RAG 检索结果
工具调用结果
...

都可能计入 Input Tokens。

Output Tokens

模型生成出来的 Token：

Token 1
Token 2
Token 3
...

属于 Output Tokens。

因此：

Total Tokens
=
Input Tokens
+
Output Tokens

例如：

Input Tokens  = 1000
Output Tokens = 500

Total Tokens  = 1500

---

28. Input 和 Output 通常分开计价

虽然：

Total Tokens
=
Input Tokens + Output Tokens

但是很多 API 并不是：

1500 × 一个统一价格

而是：

Input Tokens × Input Price
+
Output Tokens × Output Price
=
最终费用

例如假设：

Input：
$2 / 1M Tokens

Output：
$8 / 1M Tokens

如果：

Input  = 1M Tokens
Output = 1M Tokens

那么：

输入费用 = $2

输出费用 = $8

总费用 = $10

实际 API 还可能存在：

Cached Input Tokens

等其他计费类别。

---

29. 为什么 Output Token 往往更贵？

输入阶段主要是：

大量 Input Tokens
 ↓
Prefill
 ↓
GPU 可以高度并行处理

而输出阶段：

Token 1
 ↓
Token 2
 ↓
Token 3
 ↓
Token 4
 ↓
...

因为：

必须先得到 Token N
       ↓
才能确定下一轮输入
       ↓
再预测 Token N+1

因此 Decode 具有明显的自回归串行特征。

所以很多模型：

Output Token 的 API 单价会高于 Input Token。

---

30. 多轮聊天为什么越来越消耗 Token？

假设第一轮：

用户输入：1000 Tokens
AI 输出：1000 Tokens

第二轮用户只新输入：

100 Tokens

但是模型为了理解上下文，系统可能还需要把之前相关对话一起作为输入：

之前用户：1000
之前 AI：1000
本轮用户：100
----------------
Input ≈ 2100 Tokens

如果模型再回答：

Output = 1000 Tokens

那么这一轮可能产生：

Input  ≈ 2100
Output ≈ 1000

Total ≈ 3100 Tokens

而不是：

100 + 1000 = 1100

因此：

对话越长、Prompt 越大、RAG 检索内容越多、Agent 工具结果越多，Token 消耗通常越大。

实际系统还可能使用：

Prompt Caching / Cached Input

降低重复上下文的成本。

---

31. "买了 100 万 Token"是什么意思？

需要看具体平台的定义。

标准模型 API 一般会明确区分：

Input Tokens
Output Tokens
Cached Input Tokens
...

但是某些第三方平台所谓：

购买 1000 万 Token

可能实际上是平台自己的：

Credits
积分
Token 额度

例如可能规定：

普通模型 ×1
高级模型 ×10

Input ×1
Output ×4

因此：

第三方平台所说的"1000 万 Token"，不一定代表可以真实输入 + 输出 1000 万个模型 Token。

必须查看具体平台的计费规则。

---

32. LLM 与 RAG 的关系

可以把两者放到一起理解。

                       用户问题
                          │
              ┌───────────┴───────────┐
              │                       │
              ↓                       ↓
            RAG                      LLM
              │                       │
       Embedding Model           Tokenizer
              │                       │
        Query Vector               Token ID
              │                       │
       Vector Database        Token Embedding
              │                       │
       Similarity Search       Transformer
              │                       │
           Top-K             Hidden States
              │                       │
       相关知识 Chunks                 │
              │                       │
              └──────→ Prompt ────────┘
                          ↓
                         LLM
                          ↓
                       LM Head
                          ↓
                    下一个 Token
                          ↓
                       KV Cache
                          ↓
                        Decode
                          ↓
                     不断循环生成
                          ↓
                       最终回答

需要注意：

RAG 负责"找资料"，LLM 负责"理解上下文并生成答案"。

---

33. 核心概念速记表

概念	核心含义
Tokenizer	将文本切分并编码为 Token ID
Token	模型处理文本的基本离散单位
Token ID	Token 在 Vocabulary 中对应的整数编号
Vocabulary	Token 与 Token ID 的映射词表
Embedding	将离散信息转换成连续高维向量
Embedding Table	根据 Token ID 查找初始 Token 向量的参数矩阵
Token Embedding	一个 Token 的初始高维表示
Transformer	通过 Attention 等机制融合上下文并进行多层特征变换
Hidden State	Token 经过 Transformer 后得到的上下文化表示
LM Head	将 Hidden State 映射到 Vocabulary 的 Logits
Logits	模型对 Vocabulary 中各 Token 给出的原始分数
Autoregressive	根据已有 Token 不断预测下一个 Token
Prefill	一次处理 Prompt，并建立后续生成需要的状态
Decode	生成阶段逐 Token 预测
KV Cache	缓存历史 Token 各 Transformer 层的 K/V
Text Embedding	用一个高维向量表示 Query / Chunk 等整段文本
Vector Database	存储和检索高维向量
Cosine Similarity	比较两个向量方向是否接近
Euclidean Distance	比较两个向量在空间中的实际距离
Dot Product	通过点积衡量向量关系，可用于向量检索
Top-K	取相关性最高的 K 个检索结果
RAG	先检索外部知识，再让 LLM 基于知识生成答案
Input Tokens	输入给模型处理的 Token
Output Tokens	模型生成的 Token
Total Tokens	Input Tokens + Output Tokens

---

34. 一句话理解 Token

Token 是 Tokenizer 对文本切分后得到的基本处理单位；每个 Token 在 Vocabulary 中对应一个 Token ID。

---

35. 一句话理解 Embedding

Embedding 就是把离散的 Token、文本等信息转换成神经网络可以计算和比较的高维连续向量。

---

36. 一句话理解 Transformer

Transformer 通过多层 Attention 和神经网络计算，让每个 Token 的初始向量不断融合上下文信息，最终形成上下文化的 Hidden State。

---

37. 一句话理解 LLM 生成

LLM 将文字转换成 Token ID 和向量，经过多层 Transformer 得到 Hidden State，再利用最后位置的 Hidden State 预测下一个 Token，并通过 KV Cache 高效地逐 Token 循环生成，直到回答结束。

---

38. 一句话理解 RAG

RAG 将文档 Chunk 和用户问题通过 Embedding Model 转换成语义向量，再使用 Cosine Similarity、Euclidean Distance、Dot Product 等方法检索最相关的 Chunk，最后把检索到的知识交给 LLM 生成答案。

---

39. 一句话区分 Cosine 和 Euclidean

Cosine Similarity 看两个向量"朝的方向像不像"；Euclidean Distance 看两个向量"在空间中的位置离得近不近"。二者都可以用于 RAG 的语义向量检索。

---

40. 最终知识链路

LLM

文字
 ↓
Tokenizer
 ↓
Token
 ↓
Token ID
 ↓
Embedding Table
 ↓
Token Embedding
 ↓
多层 Transformer
 ↓
Contextualized Hidden States
 ↓
最后位置 Hidden State
 ↓
LM Head
 ↓
Vocabulary Logits
 ↓
选择下一个 Token
 ↓
KV Cache
 ↓
Decode
 ↓
继续预测
 ↓
最终回答

RAG

文档
 ↓
Chunk
 ↓
Embedding Model
 ↓
Text Embedding
 ↓
Vector Database
        ↑
        │
用户问题
 ↓
Embedding Model
 ↓
Query Embedding
 ↓
Cosine Similarity
或 Euclidean Distance
或 Dot Product
 ↓
Top-K Chunks
 ↓
用户问题 + 检索结果
 ↓
LLM
 ↓
最终答案

---

41. 最终总结

整个大语言模型和 RAG 的基础逻辑可以浓缩成：

                    AI 处理文字的核心

                         文字
                          ↓
                       Token
                          ↓
                      Token ID
                          ↓
                       向量化
                          ↓
              ┌───────────┴───────────┐
              ↓                       ↓
             LLM                     RAG
              ↓                       ↓
      Transformer 计算          Embedding Model
              ↓                       ↓
       理解上下文关系             语义向量
              ↓                       ↓
      预测下一个 Token           Vector Search
              ↓                       ↓
        不断循环生成              找相关知识
              │                       │
              └──────────┬────────────┘
                         ↓
                      最终回答

最重要的是理解这几个转换：

文字
→ Token
→ Token ID
→ 高维向量

在 LLM 中：

高维向量
→ Transformer
→ 上下文化 Hidden State
→ LM Head
→ 下一个 Token
→ 循环生成

在 RAG 中：

文本
→ Embedding Model
→ 整段文本的语义向量
→ Vector Database
→ 相似度 / 距离检索
→ Top-K
→ LLM

因此可以把两者概括为：

LLM 的核心任务是根据上下文不断预测下一个 Token；RAG 的核心任务是在 LLM 生成之前，通过向量语义检索给模型找到更相关、更可靠的外部知识。

---

💬 如果本文对你有帮助，欢迎点赞 + 收藏 + 分享

📌 更多 AI 工程实践内容，欢迎关注「YoanAILab」