大语言模型基础：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 理解成一张巨大的映射表：

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。

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 推理通常可以分成两个重要阶段：

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（相似度 / 距离度量）

常见方法包括：

20. Cosine Similarity（余弦相似度）

Cosine Similarity 主要关注：

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

公式：

$$\cos \theta =\frac{A\cdot B}{\Vert A\Vert \Vert B\Vert }$$

其中：

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=(a_1,a_2)$$

$$B=(b_1,b_2)$$

那么：

$$d(A,B)=\sqrt{(a_1-b_1{)}^2+(a_2-b_2{)}^2}$$

三维：

$$d(A,B)=\sqrt{(a_1-b_1{)}^2+(a_2-b_2{)}^2+(a_3-b_3{)}^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

但是欧氏距离：

$$
\\sqrt{(10-1)^2+(10-1)2}

\\sqrt{162}
\\approx 12.73
$$

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

所以可以形象地理解：

Cosine Similarity：

“你们两个朝的方向像不像？”

Euclidean Distance：

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

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

在 RAG / Vector Search 场景中：

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

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

所以 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

那么：

$$\Vert A-B{\Vert }^2=2-2\cos \theta$$

这意味着对于单位向量：

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. 核心概念速记表

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」