【Plain Language Large Model】【大语言模型底层原理全解析：从Token生成到智能体演进】流食般投喂

dj_798

500人浏览 · 2026-10-22 08:27:11

dj_798 · 2026-10-22 08:27:11 发布

大语言模型底层原理全解析：从Token生成到智能体演进

当我们熟练地调用 ChatGPT、DeepSeek 或千问的 API 时，可曾想过模型背后并非“思考”，而是在进行一场精密且疯狂的数学运算？这一系列课堂笔记，将带大家穿透黑盒，看清 LLM 从“说第一个字”到“进化为机器人”的完整旅程。

一、核心工作原理：一场“滚雪球”式的概率游戏

大语言模型（LLM） interaction 的流程可以极度简化为三段式：Prompt → LLM → Token。

用户输入的指令叫做提示词（Prompt）。比如问“什么是大语言模型”，这句话就是 Prompt。模型拿到后，并不会直接“理解”这句话，而是做一道数学题：基于当前词表，计算下一个最应该出现的词元（Token）。

1.1 Token 的本质：“词”而非“字”

这里老师特别强调了一个易错点：模型生成的最小单位是 Token（词元/代币），它通常是一个词，而非单个汉字。

例如，“我爱北京天安门”中，每个词可能对应一个或多个 Token；“西红柿炒鸡蛋”里，“西红柿”“炒”“鸡蛋”各自可能是独立的 Token。老师用“这件衣服很漂亮”与“这件衣服很帅气”举例，说明模型会根据上文计算概率，为后续拼接不同的词语。

1.2 自回归生成：像滚雪球一样循环

模型的工作方式是自回归（Auto-regressive），用老师的话说，就是 “滚雪球” 。

以“中国的首都是哪里”为例，课堂上的推演非常经典：

模型一通概率计算，发现下一个概率最高的 Token 是“北”；
但它不会停，而是把“中国的首都是哪里 + 北”作为新的输入，再次喂给自己；
模型继续算，得出下一个高概率 Token 是“京”；
再把“中国的首都是哪里 + 北京”拼回去，模型判断句子完整，于是输出句号或特殊的 EOS（End of Sentence）结束标记；
最终整段回答，是由这一个个 Token 依次拼接而成的。

老师形象地说道：这个过程如同滚雪球，上一步生成的内容会反馈回模型，成为生成下一步的语境。

1.3 Token 的选择策略：不只“选最像的”

那么模型如何从动辄 10 万+ 的词表中挑选下一个 Token？课堂上介绍了从“最老实”到“最天马行空”的几种策略：

贪婪策略（Greedy Search）：每次都选概率最高的那个。好处是结果固定、稳定；坏处是缺乏多样性，无法解释为什么同一个问题偶尔会给出不同回答。
随机策略：像掷骰子、抽扑克牌一样完全随机选。极具不确定性，现实里基本不单独使用。
温度系数（Temperature）：这是控制“贪婪”与“随机”之间平衡的旋钮。
- 低温：倾向选高概率 Token，适合数学题等逻辑性强、答案唯一的场景；
- 高温：增加低概率词被选中的机会，回答更发散，适合创意写作。
- 老师补充：很多可视化平台里的“逻辑性强”或“发散思维”选项，底层其实就是调节 Temperature，只是加了一层遮罩。
Top-K 采样：只从概率最高的前 K 个（如前 50 个）Token 里选，缩小候选范围，过滤掉极低概率的不合理词汇。
Top-P 核采样（Nucleus Sampling）：动态选择累积概率达到阈值 P（如 0.9）的最小 Token 集合。与 Top-K 固定数量不同，Top-P 固定的是“概率质量”。老师举了一个直观的例子：如果是“1+1=2”，“2”的概率可能占 99%，此时 Top-P 可能只选 1 个词；如果概率分布均匀，则可能选数千个词。

综合流程（课堂零碎知识点）：实际应用中往往是组合拳——先 Top-P 缩小范围，再 Top-K 筛选，最后结合 Temperature 做加权随机选择。在选定候选集后，还会对其概率进行重新归一化（放大至 100%），再依据温度系数抽样。这个“概率重校准”的细节，是很多初学者容易忽略的。

二、认识 Token：模型的“原子”与经济账本

理解了生成机制后，课程进入了更微观的层面：Token 到底是什么？为什么模型非得用 Token 说话？

2.1 Token 的形态与分词差异

Token 是模型处理的最小基本单位，不可再分。它的形态多样：

一个完整的英文单词（如 believe）；
中文里的一个字；
单词的一部分（子词单元）；
标点符号、表情符号（老师特别提到“一个笑脸也是一个 Token”，所以模型能生成表情）。

课堂上用实际工具对比了分词差异，这些例子非常经典，值得记住：

英文 “Believe”：在 GPT-4 和 GPT-5 中都被切分为 3 个 Token，但切分位置和 Token ID 并不完全相同；
中文 “我爱大模型开发”：在 GPT-4 中是 4 个 Token（老师提到当时测试还出现了乱码），而在千问（Qwen）模型中则是 5 个 Token。

这说明：不同模型拥有独立的词表和分词策略，Token ID 对应的就是模型内部的“字典页码”。

2.2 为什么非要引入 Token 机制？

老师归纳了两大核心原因：

第一，数字化与语义保留。 大模型底层是复杂的矩阵运算，必须把文本转成向量。如果直接把整句“我爱你”映射为一个 ID，会丢失内部词汇的组合关系。拆成“我”“爱”“你”三个 Token，模型才能学会“我”和“你”之间可以放“爱”或“喜欢”，从而保留语义灵活性。

第二，避免计算量与词表爆炸。

若以单个字母为基本单位：虽然基数只有 26 个，但任意长度拼接会导致组合数量天文数字般增长，计算效率极低；
若以完整单词为基本单位：英语单词本就数十万，再加上多语言混合，词表规模会极其庞大。

Token 是介于“字/字母”与“完整单词”之间的折中方案，既控制词表规模（如 LLaMA 约 12 万、Qwen 可达 25 万），又保证计算效率，因此被称为“词元”。

2.3 输入 Token 为什么比输出 Token 便宜？

课堂后半段揭秘了一个行业现象：输出 Token 的价格通常远高于输入 Token（比如某旗舰模型输出约 6 元/百万 Token，输入仅约 3 元/百万；若缓存命中，输入甚至低至 0.025 元/百万）。

根本原因不在软件，而在 GPU 硬件计算特性：

显存带宽瓶颈：GPU 计算需要把数据从显存（VRAM）搬运到高速内存（SRAM/SM）中运算。输入阶段所有 Token 一次性并行加载，耗时极短；但输出阶段是自回归的，每生成一个 Token 都要把之前的历史上下文从显存反复搬运到 SRAM。这种频繁的“搬运-计算-等待”导致 GPU 算力闲置，且占用了昂贵的显存带宽。
KV Cache(键值缓存) 累积：为避免重复计算，模型会把已算好的 Key-Value 缓存到显存中。随着输出长度增加，KV Cache 不断累积，占用大量显存空间。每次生成新 Token 都要读取这些庞大的 KV 数据，进一步加剧资源消耗。

老师用了一个生活化比喻：输入就像把一车货一次性拉到工地；输出则是每砌一块砖，都要把之前砌好的所有砖再搬过来参考一遍，自然又慢又贵。

三、词表：LLM 的“新华字典”与 OOV 困境

如果说 Token 是原子，那 词表（Vocabulary） 就是元素周期表。老师将其本质一语道破：词表是一个映射字典，类比 Java/C++ 里的 Map，或 Python 里的 Dict。

3.1 词表的工作流

输入端：文本先被分词为 Token，再转为唯一的数字 ID（如“LM”对应 10001），因为模型只认数字；
输出端：模型输出的是一系列 ID，系统再查词表，把 ID 翻译回人类可读的 Token。

老师特别强调了一个边界：模型无法生成词表范围之外的内容。所有输出都受限于这张“字典”。

3.2 字节级回退：遇到生僻字的“兜底方案”

课堂上抛出了一个现实问题：如果遇到词表没收录的新词、生僻字甚至“火星文”怎么办？这就是 OOV（Out-of-Vocabulary）问题。

解决方案是字节级回退（Byte-level Fallback）：

系统将 0x00 到 0xFF 的所有字节值预设为独立的 Token；
遇到未知字符时，将其拆成单个字节（如一个 UTF-8 字符可能由多个字节组成），每个字节映射为已知 Token，再基于这些字节 Token 做预测。

优点：保证模型遇到任何字符都不会完全失效。
缺点：效率低。一个常规 Token 可能被拆成多个字节 Token（老师举例说“一个字符可能消耗 5 个 Token”），Token 消耗量显著增加，既拖慢速度又增加成本。

四、多人对话的真相：模型没有记忆，只有“上下文拼接”

课程进入应用层，首先打破了一个常见幻觉：大模型没有记忆力。

4.1 无状态本质：y = 2x + 1

老师用了一个极其精准的数学比喻：大模型就像函数 y = 2x + 1，它不会对输入值有任何记忆，只负责对当前输入做复杂计算。课堂实验也很直接：

先问模型“我叫小明，今年 6 岁”，再问“我叫什么”，它能答出来；
但新开一个会话，直接问“我叫什么”，模型完全不知道。

这就是所谓的“记忆”：把历史对话记录（History）与当前新问题拼接后，一并发送给模型。用户感觉模型记住了，其实只是因为它在每次提问时，都读到了完整的“剧本”。

4.2 为什么人类需要多轮对话？

既然模型没记忆，那为什么要设计多轮对话？老师总结了三个深层原因：

上下文依赖（Context Dependency）：自然语言充满代词和隐喻。比如先问“龙是什么”，再问“它的头像”，单轮对话无法解决这种指代关系。
复杂问题的澄清与拆解：人类沟通遵循“省力原则”，初始指令往往信息不全。老师举了一个非常贴近实际的例子：让 AI 做“用户管理系统”。模型不会直接上手写代码，而是会通过多轮反问来明确需求——包含哪些字段？需要新增/删除/修改/查询吗？经过多轮对齐，最终才输出完整方案。
纠错与对齐：大模型是概率模型，会犯错。比如课堂上讨论的数学问题：0.999... = 1 引发的争论。用户需要通过多轮对话指出错误、要求修正，才能对齐结果。

4.3 引入多轮后的三大挑战与解决方案

这部分是课程的“干货中的干货”，老师讲得非常细致：

挑战 1：上下文管理瓶颈
模型有上下文长度上限（如 DeepSeek 支持 1M tokens，输出限制 384k）。若对话过长，会撑爆这个“容器”。

对话摘要：让模型把长对话压缩成核心信息。老师举了代码工程的例子：先让 AI 分析整个项目目录并形成摘要，后续开发时只携带摘要，而非千万行代码。
滑动窗口：只保留最近 N 轮（如 20-30 轮），丢弃早期记录。老师提示：这个 N 可以通过运营数据统计出合理值，不是拍脑袋定的。
RAG（检索增强生成）：把海量数据（如《西游记》全文）存入向量数据库。问“牛魔王与孙悟空的关系”时，只把相关片段（如牛魔王结拜、红孩儿章节）检索出来喂给模型，避免全量投喂。

挑战 2：推理效率与成本
上下文越长，生成每个字都要重算前文，速度慢、电费高。

KV Cache：缓存已计算好的 Key-Value 值，生成新字时无需重复计算前文；
剪枝（Pruning）：直接删除对话中的冗余信息和废话，减少输入长度。

挑战 3：中间遗忘（Lost in the Middle）
老师引用了一篇经典论文：模型对上下文首尾信息记忆较好，但容易遗忘中间部分，呈 U 型记忆曲线。

根本解决：把上下文长度从 1M 扩展到 10M——但这训练成本极高（动辄数百万美金），周期长。
外挂状态存储（终极方案）：引入外部数据库（如 PG、MySQL）。老师举了旅游计划的例子：当家庭出游计划发生变更（爸爸要看老虎，儿子要看斑马），AI 助手检测到状态变化后，不把希望寄托在模型回忆上，而是将最新计划写入数据库。后续查询时，直接从数据库读取最新状态注入 Prompt，彻底规避遗忘问题。

五、提示词工程：给模型设定“人设”与“边界”

课程接下来剖析了提示词的分类与系统提示词（System Prompt）的核心作用。

5.1 用户提示词 vs 系统提示词

User Prompt：用户直接说的话，如“北京的天气怎么样”；
System Prompt：预先设定且置于最前端的顶层指令，由开发者设定，对用户不可见，且贯穿整个对话始终。

5.2 系统提示词的四大作用

1. 定义角色和行为边界
可以把“全科博士”塑造成特定专家。

老师演示了引导式教学人设：设定模型为“一步步引导小朋友且不直接给出答案的老师”。面对 2x + 3 = 7，模型不会直接报答案，而是像教小朋友一样提问：“观察天平，右边是什么？我们第一步先做什么？”
边界划定：设定为“数学老师”并规定“不回答其他科目问题”。当用户要求写一篇春天的作文时，模型幽默拒绝：“抱歉，你走错教室了。”

2. 稳定模型行为
模型基于概率生成，本质上带有“摇色子”般的随机性，回复风格可能波动。通过系统提示词限定“回复非常专业”或“语气温柔”，可以约束输出保持一致。

3. 安全与合规
充当安全护栏，拒绝制作炸弹、涉黄涉政等请求。同时防御提示词攻击（如用户试图套取系统提示词本身）。

4. 弥补知识短板和提供上下文
模型训练数据有截止日期。老师展示了 Claude（SOP 公司）公开的系统提示词案例：其中明确写入了当前美国总统及其就职时间等实时政治信息，以弥补模型训练数据的滞后。此外还包含模型名称、官网、儿童安全策略、恶意代码处理原则等。

5.3 开发框架的抽象

在实际开发框架（如 LangChain）中，这些概念被抽象为 Message：

System Message（系统提示）
User Message（用户输入）
AI Message（模型回复，注意回复本身不属于 Prompt，所以统称 Message）
Tool Message（工具调用及返回）

六、聊天模板：格式化的“安全蓝图”

当用户输入变得复杂、模型版本快速迭代时，直接把 JSON 发给模型会很危险——如果用户输入里带了引号，极易导致模型把用户内容和系统指令搞混。这就是 聊天模板（Chat Template） 存在的意义。

6.1 核心机制：用特殊 Token 划定边界

聊天模板本质上是一种格式蓝图。它把 JSON 转换成带特殊标记的字符串，例如用 <|start|> 表示系统指令开始，<|end|> 表示结束。模型只需识别这些特定标记，就能清晰区分“哪里是系统指令、哪里是用户输入”，避免冲突。

6.2 模型间的格式鸿沟

不同模型家族的模板差异巨大，甚至同一系列不同版本（如 Qwen 2.5 与 2.7）都有细微差别。硬编码 Python 字符串拼接来适配，维护成本极高。

6.3 为什么推荐 Jinja2？

课堂上力荐 Jinja2 作为模板引擎，三大优势：

解耦通用性：模型格式微调时，只需改模板文件，无需改动核心业务代码；
动态逻辑控制：支持 if-else 判断，可根据是否有系统指令、是否有工具调用，灵活生成不同结构；
安全防护（防注入）：Jinja2 的自动转义（Escape）能力，能处理用户输入中的复杂特殊字符，防止恶意构造字符串破坏解析逻辑。

6.4 实际应用路径

云端调用（如 LangChain + 阿里云 Qwen）：JSON 到模板的转换在服务端黑盒完成，开发者无感知；
本地复现/调试：建议使用 Hugging Face Transformers 库的 apply_chat_template 方法，输入 JSON 消息列表，观察渲染后的完整字符串，验证 Start/End Token 格式。