大模型 on 你怂你mua

大语言模型原理详解：从预测下一个词到智能涌现

Sat, 02 May 2026 00:00:00 +0000

引言

大语言模型看起来很神奇：能聊天、写代码、总结文章、翻译文本、分析日志，甚至能像助手一样完成复杂任务。

但如果把外壳拆开，它最核心的目标其实非常朴素：

`1`	`根据前面的内容，预测下一个 token。`

例如给模型一句话：

今天天气很

模型要做的是预测后面最可能接什么：

`1`	`好、热、冷、差、舒服……`

当这个能力被放大到海量数据、巨大参数、强大的 Transformer 架构和精心设计的训练流程上，就出现了我们今天看到的大语言模型。

这篇文章不追求堆公式，而是用尽量直观的方式讲清楚：

模型如何“读”文字
Transformer 为什么有效
注意力机制到底在注意什么
模型是怎么训练出来的
对齐为什么能让模型更像助手
推理参数如何影响回答
大模型为什么会幻觉、受上下文限制

一句话理解 LLM

大语言模型可以理解成一个巨大的概率预测器。

它接收一串 token，输出下一个 token 的概率分布：

输入：我 喜欢 吃
输出：
  苹果：0.31
  米饭：0.18
  火锅：0.12
  代码：0.01
  ...

然后系统从这个概率分布里选一个 token，接到原文后面，再继续预测下一个。

1
2
3

我喜欢吃 → 苹果
我喜欢吃苹果 → 。
我喜欢吃苹果。 → 今天

一句话、一段代码、一篇文章，都是这样一个 token 一个 token 生成出来的。

这听起来像“文字接龙”，但关键在于：为了准确预测下一个 token，模型必须学会大量隐含能力。

它要知道：

语法结构
词义关系
世界知识
常识推理
代码模式
对话格式
上下文约束

预测下一个 token 是训练目标，理解和推理是这个目标逼出来的能力。

Token：模型眼中的文字

模型不能直接读“文字”。它看到的是 token。

Token 可以是一个字、一个词、一个词的一部分，甚至是标点或空格。

例如：

1
2

原文：ChatGPT 很强
可能被切成：["Chat", "GPT", " 很", "强"]

不同模型的分词器不一样，所以同一句话在不同模型里可能切成不同 token。

为什么不用字或词

如果按字切，英文会很碎：

`1`	`transformer → t r a n s f o r m e r`

如果按词切，又会遇到新词、拼写变体、代码变量名：

`1`	`getUserProfileById`

现代模型通常使用子词分词。它在“太碎”和“太粗”之间折中：

`1`	`unbelievable → un + believe + able`

这样既能处理常见词，也能拼出没见过的新词。

Token 影响成本和上下文

上下文窗口不是按字数算，而是按 token 算。

如果模型上下文是 128K token，意思是一次最多能看到约 128K 个 token，包括：

系统提示
用户输入
历史对话
检索文档
工具结果
模型输出

token 越多，成本越高，推理越慢，上下文管理也越重要。

Embedding：把 token 变成向量

模型不能直接对 token 字符串做计算。它会先把每个 token 映射成一个向量。

1
2
3

"苹果" → [0.12, -0.38, 0.57, ...]
"香蕉" → [0.10, -0.35, 0.61, ...]
"数据库" → [-0.44, 0.72, 0.08, ...]

这个向量叫 Embedding。

可以把它理解成 token 在语义空间里的坐标。语义接近的 token，向量距离通常也更接近。

但在大语言模型里，Embedding 只是第一步。真正强大的地方在于：这个向量会经过很多层 Transformer，不断吸收上下文信息。

例如“苹果”这个 token，在不同句子里的含义不同：

1
2

我买了一个苹果。
苹果发布了新款芯片。

初始 Embedding 可能相同，但经过上下文处理后，模型会逐渐区分它是水果还是公司。

Transformer：LLM 的主干架构

现代大语言模型的核心架构基本都来自 Transformer。

一个简化版流程：

文本
  ↓
Tokenization
  ↓
Embedding
  ↓
Transformer Block × N
  ↓
输出下一个 token 的概率

Transformer Block 可以理解成一层“信息加工器”。每一层主要做两件事：

1
2

1. Attention：让每个 token 从其他 token 那里取信息
2. Feed Forward：对每个位置的信息做进一步加工

几十层甚至上百层叠起来后，模型就能从简单词义逐步抽象到语法、语义、推理和任务意图。

Attention：让 token 互相看见

Attention 是 Transformer 最核心的机制。

一句话理解：

Attention 让当前位置的 token 判断：我应该重点关注前文里的哪些 token。

例如：

`1`	`小明把书放进书包，因为它太重了。`

这里“它”指的更可能是“书”，不是“书包”。模型要理解这件事，就需要让“它”这个位置去关注前面的相关词。

Query、Key、Value

Attention 里常见三个词：Query、Key、Value。

可以用查资料来类比：

1
2
3

Query：我想找什么？
Key：每份资料的标签是什么？
Value：资料真正的内容是什么？

每个 token 都会生成自己的 Query、Key、Value。

然后当前位置的 Query 会和所有位置的 Key 做匹配，算出注意力分数。分数越高，说明越值得关注。最后再按这些分数加权汇总 Value。

简化成三步：

1
2
3

1. 当前 token 发出 Query：我需要什么信息？
2. 其他 token 提供 Key：我能提供什么线索？
3. 根据匹配程度汇总 Value：把有用信息拿过来。

Self-Attention

Self-Attention 的意思是：同一句话内部的 token 互相关注。

例如：

`1`	`张三告诉李四，他明天会来。`

模型需要判断“他”更可能指谁。这就需要结合上下文中的多个 token。

Self-Attention 的强大之处在于：任意两个位置之间都可以直接建立联系。不像 RNN 那样必须从左到右一步步传递信息。

Causal Mask

GPT 这类生成式模型在训练和生成时不能偷看未来。

预测第 5 个 token 时，只能看前 4 个 token，不能看第 6 个 token。

这靠 Causal Mask 实现。

1
2
3

位置 1 只能看 1
位置 2 只能看 1,2
位置 3 只能看 1,2,3

这样模型学到的才是“根据前文预测后文”，而不是提前看答案。

Multi-Head Attention：从多个角度看上下文

一个 Attention 头只能从一种角度关注上下文。

但一句话里有很多关系：

主谓关系
指代关系
时间关系
因果关系
代码里的变量引用
Markdown 里的结构层级

Multi-Head Attention 就是让模型同时用多个 Attention 头观察文本。

Head 1：关注语法
Head 2：关注指代
Head 3：关注代码变量
Head 4：关注段落结构

这些头的结果会被合并，让模型得到更丰富的上下文表示。

不需要把每个头想得太神秘。它们不一定真的严格分工成“语法头”“指代头”，但多头机制确实给了模型从不同子空间捕捉关系的能力。

Feed Forward：对信息做加工

Attention 负责“从哪里拿信息”，Feed Forward 负责“怎么加工信息”。

在每个 Transformer Block 中，Attention 汇总上下文后，会经过一个前馈网络。

可以粗略理解为：

1
2

Attention：把相关信息拿到当前 token 身边
Feed Forward：根据这些信息更新当前 token 的表示

很多研究认为，模型里的事实知识和模式记忆相当一部分保存在前馈网络参数中。

例如模型知道：

1
2
3

巴黎是法国的首都
Redis 的 zset 常用跳表
Go 的 goroutine 由调度器管理

这些知识并不是以数据库记录的形式存储，而是分散在大量参数里。

位置编码：让模型知道顺序

Attention 本身不天然知道顺序。

如果只看一堆 token 向量，模型并不知道谁在前谁在后。

所以模型需要位置编码。

1
2

我 爱 你
你 爱 我

这两句话 token 一样，但顺序不同，意思不同。

位置编码就是给每个 token 加上“我在第几个位置”的信息。

现代模型常用 RoPE 这类相对位置编码。你不必记住复杂数学，只要知道它解决的是：

`1`	`模型如何理解 token 之间的距离和顺序。`

残差连接与归一化：让深层网络稳定训练

Transformer 可以堆很多层，但层数越深，训练越难。

残差连接和归一化是两个稳定训练的关键技巧。

残差连接

残差连接就是让每层不要完全重写输入，而是在输入基础上做增量修改：

`1`	`输出 = 输入 + 本层加工结果`

这样信息可以更顺畅地穿过很多层，训练也更稳定。

LayerNorm

LayerNorm 用来让每层的数值分布更稳定。

可以类比成：每一层处理完后，把数据尺度整理一下，避免数值忽大忽小导致训练崩掉。

这些机制不直接决定模型“懂不懂”，但决定了模型能否被训练得足够深、足够大。

训练：从海量文本中学习规律

预训练阶段的任务很简单：

`1`	`给定前文，预测下一个 token。`

训练数据来自大量文本：

网页
书籍
代码
论文
问答
文档
论坛

模型一开始是随机参数，预测很差。每次预测错了，就根据误差微调参数。

这个过程重复数万亿 token 后，模型逐渐学会语言和世界知识的统计规律。

预训练学到什么

预训练让模型学会：

词和词如何搭配
句子如何组织
代码如何书写
常见事实
推理模式
不同领域的表达方式

但预训练模型本质上仍然是“续写器”。

你问：

`1`	`请解释什么是 Redis。`

Base Model 可能会继续补成一段网页、问答、代码注释，未必像助手一样回答你。

这就是为什么还需要指令微调和对齐。

指令微调：从续写器到助手

SFT（Supervised Fine-Tuning，监督微调）会用人工整理的指令数据继续训练模型。

数据长这样：

{
  "instruction": "解释什么是 Redis",
  "response": "Redis 是一种基于内存的键值数据库..."
}

模型通过这些样本学会：

用户提问应该回答
要遵循指令
要保持对话格式
要按要求输出结构
不要无意义续写

经过 SFT 后，模型才更像我们熟悉的聊天助手。

对齐：让模型更符合人类偏好

SFT 解决“会不会听指令”，但不完全解决“回答得好不好”。

同一个问题可以有很多回答：

1
2
3

太短：Redis 是数据库。
太长：从网络协议讲到源码实现。
刚好：解释核心概念、使用场景和特点。

对齐训练就是让模型更符合人类偏好。

常见方法包括：

RLHF：基于人类反馈的强化学习
DPO：直接偏好优化
RLAIF：用 AI 反馈辅助偏好数据

它们的共同目标是让模型更倾向于输出：

有帮助
准确
安全
不胡乱承诺
格式清晰
符合用户意图

可以把训练流程简化成：

1
2
3

预训练：学语言和知识
SFT：学会按指令回答
对齐：学会什么回答更好

推理：模型如何生成回答

训练完成后，模型参数固定。用户输入问题时，进入推理阶段。

推理流程：

用户输入
  ↓
转成 token
  ↓
模型计算下一个 token 概率
  ↓
采样或选择一个 token
  ↓
加入上下文
  ↓
继续预测

这个循环一直进行，直到模型输出结束符或达到最大长度。

Temperature

Temperature 控制随机性。

低 temperature：

`1`	`更稳定、更保守、更可复现`

高 temperature：

`1`	`更多样、更有创意、也更容易跑偏`

写代码、做问答通常用较低温度；写故事、头脑风暴可以适当提高。

Top-K

Top-K 表示只从概率最高的 K 个 token 中选择。

如果 K=5，模型只会在前 5 个候选里采样，低概率 token 会被排除。

Top-P

Top-P 也叫 nucleus sampling。

它不是固定取前 K 个，而是取累计概率达到 P 的候选集合。

例如 P=0.9，模型会从累计概率前 90% 的候选里采样。

Top-P 比 Top-K 更灵活，因为不同位置的候选分布可能差异很大。

上下文窗口：模型的工作记忆

模型不会真正“记住”当前对话之外的东西。它每次生成时，只能看到上下文窗口里的内容。

上下文包括：

系统提示
用户消息
历史对话
工具结果
RAG 检索文档
代码片段
记忆摘要

如果信息不在上下文里，模型就无法直接使用。

这也是为什么 RAG、记忆系统、上下文压缩很重要。它们本质上都在解决一个问题：

`1`	`该把什么信息放进模型当前能看到的窗口？`

上下文窗口变大不代表问题完全解决。信息越多，噪声也越多。真正关键的是上下文质量。

参数量、数据和算力

大模型能力提升通常来自三件事：

1
2
3

更多参数
更多高质量数据
更多训练算力

参数可以理解成模型内部可调的“旋钮”。参数越多，模型能表达的模式越复杂。

但参数不是越大越无脑好。

模型效果还取决于：

数据质量
训练 token 数
模型架构
对齐质量
推理成本
部署约束

一个训练得好的小模型，在特定任务上可能比一个泛用大模型更划算。

涌现能力：规模带来的质变

当模型规模、数据量和训练计算达到一定程度后，会出现一些小模型不明显的能力：

多步推理
代码生成
工具调用
少样本学习
指令泛化
跨语言迁移

这类现象常被称为涌现能力。

但“涌现”不等于魔法。它更像是大量统计规律、表示能力和训练目标叠加后，在某些任务上表现出突然变强的现象。

理解这一点很重要：大模型很强，但它不是全知系统。

为什么会幻觉

幻觉是大模型最典型的问题之一。

原因很简单：模型的目标是生成“概率上合理的下一个 token”，不是从数据库里查真相。

当它不知道答案时，也可能生成一个看起来像答案的回答。

幻觉常见于：

问题超出训练知识
需要最新信息
上下文缺少证据
用户要求编造式任务
检索结果不相关
模型被错误前提诱导

降低幻觉的方法：

RAG 引入外部证据
工具调用查询真实系统
要求引用来源
不确定时允许回答不知道
对高风险场景做人工审核

幻觉不能完全消除，只能通过工程手段降低。

为什么数学和逻辑会出错

LLM 不是传统符号推理引擎。

它可以学到很多推理模式，但本质上仍然在生成 token。

所以它可能：

算术中间步骤出错
忘记约束条件
被题目措辞误导
在长推理链中偏离目标
给出看似合理但错误的解释

解决方法通常不是“让模型更努力想”，而是结合工具：

计算器
代码执行器
定理证明器
SQL 查询
测试用例

模型负责理解问题和组织流程，工具负责精确计算和验证。

LLM 与 Agent 的关系

LLM 是大脑，但 Agent 是系统。

一个 Agent 通常包含：

LLM 推理
工具调用
记忆系统
任务规划
权限控制
错误恢复
评估与日志

LLM 本身只负责生成下一步内容或动作意图。Agent 工程负责把它放进可执行、可观察、可控制的系统里。

这就是为什么同一个模型，在不同产品里的表现差异很大。真正决定可用性的，不只有模型，还有上下文、工具、流程和评估。

小结

大语言模型的核心可以压缩成一句话：

`1`	`在大量文本上训练一个 Transformer，让它根据上下文预测下一个 token。`

但这句话背后包含一整套机制：

Tokenization：把文字切成模型能处理的单位
Embedding：把 token 变成向量
Attention：让 token 从上下文中取信息
Feed Forward：加工和存储模式
Position Encoding：让模型知道顺序
Pre-training：学习语言和世界规律
SFT：学会听指令
Alignment：学会更符合人类偏好
Decoding：一个 token 一个 token 生成答案
Context：决定模型当前能看到什么

理解 LLM，不需要一开始就陷进公式。先抓住主线：

`1`	`它如何读文本 → 如何理解上下文 → 如何训练 → 如何生成 → 为什么会出错`

这条线理清了，再去看 Transformer 细节、RAG、Agent、Tool Calling、模型部署，就会顺很多。

RAG架构详解：从大模型局限到检索增强生成

Sun, 05 Apr 2026 00:00:00 +0000

大模型的四大局限性

以 GPT-4、Claude 为代表的大语言模型（LLM）能力惊艳，但在实际落地中存在几个"先天不足"：

1. 知识截止日期

大模型的训练数据有明确的时间窗口。比如 GPT-4 的训练数据截止到 2023 年 12 月，在此之后发生的事情一概不知。你问它"2024 年奥运会金牌榜"，它只能编造或拒绝回答。

2. 幻觉问题

大模型本质是概率模型，它不"知道"答案，而是预测最可能的下一个 token。当训练数据中没有足够的相关信息时，模型会"自信地编造"——这就是幻觉（Hallucination）。在法律、医疗等场景下，幻觉可能造成严重后果。

3. 私有知识缺失

企业内部的业务文档、代码库、设计规范等私有数据，从未出现在公开训练语料中。通用大模型对此一无所知，无法直接用于企业内部场景。

4. 上下文窗口限制

即使将私有文档塞进 prompt，大模型的上下文窗口也是有限的。GPT-4 Turbo 支持 128K token，看似很大，但当你面对几千页的企业文档时，仍然杯水车薪。而且长上下文的推理成本、延迟都会线性增长。

这四大痛点催生了一个关键范式：RAG（Retrieval-Augmented Generation，检索增强生成）。

什么是 RAG

RAG 的核心思想很简单：先检索，再生成。

在用户提出问题后，系统先去外部知识库中检索相关文档片段，然后将检索到的内容连同用户问题一起喂给大模型，让模型基于这些"参考资料"来生成答案。

`1`	`用户提问 → 检索相关文档 → 将文档+问题拼接成 prompt → LLM 生成答案`

这就像考试时允许翻书——大模型不再需要记住所有知识，只需要理解问题并从参考资料中提炼答案即可。

RAG 论文"Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks"由 Facebook AI Research（现 Meta AI）于 2020 年提出，论文将 RAG 定义为"将预训练的参数化记忆（大模型）与非参数化记忆（外部知识库）相结合的通用框架"。

RAG 架构详解

一个完整的 RAG 系统通常包含三个核心阶段：

第一阶段：索引（Indexing）

将原始文档处理成可供高效检索的形式。

`1`	`原始文档 → 文本提取 → 分块（Chunking） → 向量化（Embedding） → 存入向量数据库`

文档加载：支持 PDF、Word、网页、Markdown、数据库等多种数据源。

文本分块（Chunking）：将长文档切分成适当大小的文本片段。分块策略直接影响检索效果：

策略	做法	适用场景
固定大小	按 token 数一刀切	通用场景
语义分割	按段落/章节自然边界	结构化文档
滑动窗口	重叠切分，保留上下文	对上下文敏感的场景
层级分块	父子文档层级索引	需要多粒度检索

分块大小是核心权衡：太小会丢失上下文，太大会引入噪声。通常 512~1024 token 是一个经验范围。

向量化（Embedding）：用嵌入模型将文本片段转成高维向量。语义相近的文本，向量距离也相近。

常用嵌入模型：

模型	维度	特点
OpenAI text-embedding-3-large	3072	通用性强，付费
BGE-M3 (BAAI)	1024	多语言，开源
Cohere Embed v3	1024	企业级，付费
jina-embeddings-v3	1024	长文本支持

向量数据库：存储和检索向量化后的文档。主流选择：

Chroma：轻量开源，适合原型开发
Milvus：高性能分布式，适合生产环境
Pinecone：全托管云服务，零运维
Weaviate：自带向量化和混合搜索
Elasticsearch：传统搜索引擎 + 向量检索

第二阶段：检索（Retrieval）

当用户提问时，将问题向量化并在知识库中检索最相关的 k 个文档片段。

检索流程：

`1`	`用户问题 → 向量化（Query Embedding） → 向量相似度搜索 → Top-K 文档片段`

相似度算法：

余弦相似度：最常用，计算向量夹角
欧氏距离：适合低维向量
内积：适合归一化向量

检索策略优化：

基础的向量检索在实际应用中常常不够，需要多种增强手段：

混合检索（Hybrid Search）：向量检索 + 关键词检索（BM25）结合，兼顾语义和精确匹配
重排序（Re-ranking）：初检后用小模型对结果二次排序，提升 Top-K 精准度
查询改写（Query Rewriting）：用 LLM 将用户问题重写为更利于检索的形式
多轮检索（Multi-hop）：复杂问题拆分多步，逐步检索和推理

第三阶段：生成（Generation）

将检索到的文档片段与用户问题组装成 prompt，交由 LLM 生成最终答案。

一个典型的 RAG prompt 模板：

基于以下参考资料回答问题。如果参考资料中没有相关信息，请如实说明。

参考资料：
{检索到的文档内容}

问题：
{用户问题}

回答：

关键点：

明确指示"无法回答时如实说明"，降低幻觉
引用来源，让答案可追溯
控制 prompt 长度，避免超出模型上下文窗口

RAG 的进阶架构

基础 RAG 能解决简单问答，但面对复杂场景时力不从心。业内发展出几种进阶架构：

Modular RAG

将 RAG 的索引、检索、生成三阶段进一步拆分为可替换的模块。不同场景使用不同的检索器、生成器组合，灵活度高。

Graph RAG

用知识图谱替代向量库作为外部知识。适合实体关系复杂、需要多跳推理的场景。微软开源的 GraphRAG 是该方向的代表实现。

Agentic RAG

将 RAG 与 AI Agent 结合。Agent 自主决定何时检索、检索什么、是否需要重新检索、是否需要拆分子问题。Agentic RAG 是 RAG 从"被动回答"到"主动推理"的进化方向。

Self-RAG

让 LLM 在生成过程中自我评估是否需要检索，以及检索结果是否相关。通过特殊的"反思 token"训练模型具备检索判断能力。

RAG 的应用场景

1. 企业知识库问答

最典型的 RAG 落地场景。将企业内部的规章制度、技术文档、产品手册、会议纪要等导入知识库，员工用自然语言提问即可获得答案。

优势：

新员工入职可快速上手
打破部门信息壁垒
降低老员工答疑成本

2. 智能客服

将产品文档、FAQ、历史工单导入 RAG 系统，替代传统的关键词匹配客服。能理解用户复杂问题，给出针对性解答。

3. 代码助手

对代码库建立索引，开发者直接用自然语言询问：“这个项目的鉴权逻辑在哪？““如何添加一个新的 API 接口？”

与直接依赖 LLM 训练数据中的代码知识不同，RAG 让 AI 真正"理解"当前项目的代码。这个思路也是当下 AI 编程工具（如 Claude Code、Cursor、Copilot 的 codebase 检索）的核心能力。

4. 法律/医疗辅助

导入法规条文和判例，辅助律师快速查找相关法律依据。导入医学文献和临床指南，辅助医生获取循证建议。这两个领域对准确性要求极高，必须有来源引用来降低幻觉风险。

5. 学术研究

研究人员将论文 PDF 导入知识库，用 RAG 快速梳理文献、发现跨领域关联、生成文献综述初稿。

6. 多模态 RAG

不仅检索文本，还能检索图片、表格、音视频。比如上传一张设备故障的照片，系统检索维修手册中的相关章节并给出修理建议。

RAG 的挑战

RAG 并非银弹，实际落地面临不少挑战：

挑战	说明
文档解析	PDF 表格、扫描件、复杂排版的解析效果参差不齐
分块策略	一刀切容易割裂语义，自动化语义分块不够成熟
检索质量	高维向量空间的"语义漂移"导致检索结果不相关
生成质量	检索到不相关文档可能误导 LLM
评估困难	缺乏统一的 RAG 系统评估标准
延迟	嵌入+检索+LLM 生成，端到端延迟可能难以接受
数据更新	知识库如何增量更新，无需全量重建索引

RAG 技术栈一览

┌─────────────────────────────┐
│        LLM 框架             │
│  LangChain / LlamaIndex     │
├─────────────────────────────┤
│        向量数据库            │
│  Milvus / Pinecone / Chroma │
├─────────────────────────────┤
│        嵌入模型              │
│  OpenAI / BGE / Cohere      │
├─────────────────────────────┤
│        文档处理              │
│  Unstructured / PyPDF       │
├─────────────────────────────┤
│        编排部署              │
│  FastAPI / Ray / Docker     │
└─────────────────────────────┘

小结

RAG 解决了大模型在落地中的三个核心矛盾：

知识的时效性与静态训练的矛盾——RAG 随时更新知识库
知识的广度与私有化需求的矛盾——RAG 接入企业私有数据
知识的准确性与概率输出的矛盾——RAG 用参考资料约束幻觉

随着 Agentic RAG、Graph RAG 等进阶架构的成熟，RAG 正在从"带检索的问答系统"进化为"具备推理能力的企业知识中枢”。