一、💡 一句话理解
核心结论
大模型用“模型参数”学习能力，用“Token”读写文字，在“上下文窗口”允许的范围内，根据前文预测下一个 Token。
这四个概念是调用大模型的基础，可以先用一句话记忆：
LLM 是模型本身
Token 是模型处理文字的单位
上下文窗口是模型一次能看到的内容上限
模型参数是模型训练后获得的内部能力二、🧭 理论：LLM 是什么
2.1 LLM 的含义
LLM 是 Large Language Model 的缩写，中文叫“大语言模型”。
它是一种经过大量文本训练的人工智能模型，擅长理解和生成文字，也可以处理代码、表格、结构化数据等内容。
从最简单的角度看，LLM 做的事情是：
根据已经出现的内容，预测接下来最可能出现的内容。
例如输入：
今天天气很好，我想去模型可能生成“公园”“散步”或“旅行”等内容。它不是一次性把整段答案从数据库中取出来，而是不断预测下一个 Token，最终组成完整回答。
2.2 LLM 不等于搜索引擎
搜索引擎主要是查找网页或数据库中的信息；LLM 主要是根据训练时学到的规律生成内容。
因此，LLM 能够写出通顺的答案，但不代表答案一定正确。它可能会把不确定的内容说得很肯定，这种问题通常称为“幻觉”。
三、⚙️ 理论：它是怎么工作的
3.1 分词器：文字如何进入模型
官方教程里，Tokenizer 不只是“把句子切开”，而是一套把原始文字准备成模型输入的流程。模型只能处理数字，所以文字需要经过分词、编号和必要的格式处理，最后才能送进模型。
完整流程可以先记成：
原始文字
→ 规范化
→ 预分词
→ 子词算法切分
→ 得到 Token 文字片段
→ 转换成 input IDs
→ 添加必要的特殊 Token 和掩码
→ 送进模型对于 AI 应用开发，先理解前 5 步就够了；特殊 Token 和掩码属于后续深入内容。
3.1.1 规范化和预分词
规范化是对原始文字做必要的预处理，例如统一某些字符形式、处理空格或大小写。预分词则是先按照空格、标点等规则做初步切分。
不同 Tokenizer 的处理规则可能不同，所以不能凭肉眼准确判断一句话有多少 Token。调用模型时，应使用与模型配套的 Tokenizer。
3.1.2 子词切分和词表匹配
很多现代模型使用子词（subword）思路：常见的完整片段尽量保留，少见的词拆成几个较常见的片段。常见算法包括 BPE、WordPiece、Unigram 等。
假设分词器的词表中有这些文字片段：
Java、 中、 的、 Hash、 Map、 HashMap、 是、 什么、 ？为了便于理解，假设它给每个片段分配了编号：
Java → 101
中 → 205
的 → 306
Hash → 412
Map → 513
HashMap → 8301
是 → 614
什么 → 715
？ → 816输入问题：
Java 中的 HashMap 是什么？如果词表中包含完整的 HashMap，可能切成：
[Java] [中] [的] [HashMap] [是] [什么] [？]再转换成模型使用的数字编号：
[101] [205] [306] [8301] [614] [715] [816]如果词表中没有完整的 HashMap，但有 Hash 和 Map，则可能切成：
[Java] [中] [的] [Hash] [Map] [是] [什么] [？]这说明同样的文字，在不同模型中可能对应不同数量的 Token。很多分词器会通过类似 BPE 的方法生成和使用词表：先把文字拆得比较细，再把语料中经常一起出现的相邻片段合并。
3.1.3 Token 文字片段转换成 input IDs
分词器得到 Token 文字片段后，会根据词表把它们转换成整数编号，也就是 input_ids。模型接收的是这些编号，而不是原始字符串。
[Java] [中] [的] [HashMap]
→ [101] [205] [306] [8301]模型内部还会把这些编号转换成向量，再交给后续网络计算。向量转换的细节暂时不需要深入。
3.1.4 特殊 Token 和其他输入信息
某些模型还会在输入中加入表示开始、结束、分隔或填充的特殊 Token，并可能生成 attention_mask 等辅助信息。它们用于告诉模型哪些位置是真实内容、哪些位置需要忽略。
分词器在这一步只负责切片和编号，并不会判断“这是 Java 概念”或“用户想要概念解释”。
官方资料把这类过程称为 encoding；反过来，把编号还原为文字称为 decoding。
3.2 Token：模型处理文字的单位
Token 是模型内部处理文字时使用的“文字碎片”。一个 Token 可能是：
- 一个汉字；
- 一个词；
- 一个英文单词或单词的一部分；
- 一个数字或标点符号。
人看到的是：
我喜欢学习人工智能经过分词器处理后，这句话会被拆成若干 Token，再转换成模型能够计算的数字，之后才能进行分析和生成。
Token 不完全等于字数，也不完全等于单词数量。具体怎么拆分，取决于模型使用的分词规则。
3.3 上下文窗口：模型一次能看到多少内容
上下文窗口可以理解为模型一次对话时的“阅读桌面”。放在桌面上的内容，模型当前可以参考；超出桌面容量的内容，就可能无法继续参考。
一次请求的上下文通常包括：
系统提示词
+ 用户当前问题
+ 历史聊天记录
+ 参考文档或检索结果
+ 预留的模型回答空间上下文窗口通常用 Token 数量表示，例如 8K、32K、128K。这里的 K 表示千，具体含义以对应模型的官方说明为准。
上下文窗口越大，模型一次能处理的对话和资料通常越多，但不代表模型拥有永久记忆。
3.4 模型参数：训练后留下的内部数值
模型参数是模型训练过程中不断调整出来的大量内部数值。它们共同记录了模型从训练数据中学到的语言规律、知识模式和表达能力。
可以把模型参数粗略理解成模型“大脑中形成的能力结构”，但它不是一张可以直接打开查看的知识表。
常见的 7B、13B、70B，表示模型大约拥有多少个参数：
| 名称 | 大致含义 |
|---|---|
| 7B | 约 70 亿个参数 |
| 13B | 约 130 亿个参数 |
| 70B | 约 700 亿个参数 |
参数更多通常意味着模型容量更大，但参数数量不是判断模型效果的唯一标准。训练数据、训练方法、模型结构和实际任务都会影响最终效果。
3.5 模型训练如何形成规律
模型参数不是人工一条条写进去的规则，而是在训练过程中不断调整出来的内部数值。
可以把训练过程理解成“不断做完形填空”。例如训练材料中有一句话：
HashMap 用来保存键值对模型先看到：
HashMap 用来保存然后预测下一个 Token。假设模型预测成了“数据”，但正确答案是“键值对”，训练系统就会计算预测结果和正确答案之间的差异，再调整模型参数。
这个过程会使用大量文本重复进行：
大量文本
→ 拆成 Token
→ 预测下一个 Token
→ 和正确答案比较
→ 计算错误程度
→ 调整模型参数
→ 重复训练经过大量训练后，模型会逐渐形成各种关联，例如：
HashMap → Java 集合
HashMap → key-value
HashMap → 根据 key 查找 value它还会学习语言表达、代码结构、概念之间的关系，以及根据指令组织答案的方式。
这些规律不是一条条清晰写出来的规则，而是分散在模型参数中的能力结构。因此，模型有时能够生成合理答案，但也可能因为规律不准确而产生幻觉。
3.5.1 预训练：学习通用能力
预训练阶段会使用大量文本、代码等数据，让模型学习：
- 语言表达方式；
- 常见知识和概念关系；
- 代码结构和编程模式；
- 根据前文预测后文的能力。
3.5.2 指令微调：学会按照要求回答
预训练后的模型虽然有语言能力，但不一定擅长按照用户要求完成任务。因此还会使用大量“问题—答案”示例进行指令微调，例如：
问题：什么是 HashMap？
答案：HashMap 是 Java 中用来保存键值对的集合类。这样模型会逐渐学会理解指令、控制回答格式和使用合适的表达方式。
3.5.3 偏好与安全训练：让回答更有帮助
训练过程中还可能加入人工偏好和安全规则，让模型更倾向于：
- 回答有帮助的内容；
- 避免危险或不合适的内容；
- 说明不确定性；
- 按照用户要求组织答案。
不同模型的具体训练流程可能不同，但“预训练、指令训练、偏好与安全调整”是理解模型能力来源的常用框架。
3.5.4 AI 应用开发需要了解多深
你现在需要理解模型训练的基本原理，但暂时不需要自己训练大模型，也不需要马上深入复杂数学。
当前阶段重点掌握：
- 模型通过预测下一个 Token 生成内容；
- 模型参数是训练过程中调整出来的内部数值；
- 训练数据会影响模型的知识和能力；
- 模型可能产生幻觉，不能当作绝对可靠的数据库；
- 最新业务知识通常需要通过 RAG 提供给模型；
- Prompt 可以影响回答方式，但不能凭空创造模型没有的能力。
Transformer 的矩阵计算、反向传播公式、GPU 并行训练和自己训练 7B/70B 模型，暂时属于模型算法方向的深入内容，不是 AI 应用开发入门阶段的必修内容。
3.6 从文字到回答的整体关系
用户输入文字
→ 拆分成 Token
→ 模型利用参数进行计算
→ 结合上下文窗口中的内容
→ 预测下一个 Token
→ 重复生成
→ 组成完整回答3.7 一个问题是如何被模型处理的
以这个问题为例：
Java 中的 HashMap 是什么？为了方便理解，可以把模型的处理过程拆成下面 5 步。实际模型内部不是 5 个完全独立的程序，而是由神经网络综合完成这些事情。
3.7.1 从 Token 进入模型
在 3.1 中，分词器已经把原始文字切成 Token，并把 Token 转换成数字编号。现在模型接收到的不是“Java 中的 HashMap 是什么？”这句话，而是类似下面的一组编号：
[101] [205] [306] [8301] [614] [715] [816]这些编号会和系统提示词、历史对话、参考资料等上下文一起交给模型，之后模型才开始分析问题并生成回答。
3.7.2 识别问题中的关键信息
模型会根据 Token 之间的关系，判断问题的大致结构：
主题：HashMap
领域：Java 编程
问题类型：概念解释其中：
Java表示编程语言；HashMap表示 Java 中的一个集合类；- “是什么”表示用户想了解定义和基本概念。
这里的“识别”不是打开数据库查找，而是模型根据训练中学到的规律，分析文字之间的关系。
3.7.3 使用模型参数中学到的规律
模型参数是模型训练后留下的大量内部数值，里面包含模型从大量文本中学到的语言规律、知识模式和编程规律。
模型可能在训练材料中见过类似内容：
HashMap 是基于哈希表实现的 Map
HashMap 用来保存键值对
HashMap 的数据形式是 key-value因此，当模型看到 Java 和 HashMap 时，就能联想到应该解释：
- HashMap 的定义；
- key 和 value；
- 键值对的保存方式；
- 基本使用场景。
这些知识不是以一篇完整文章的形式整齐存放在模型里，而是分散在大量参数形成的能力结构中。
3.7.4 结合上下文判断回答方式
上下文是模型当前能够参考的全部内容，可能包括：
系统提示词：要求用简单语言回答
用户背景：Java 初学者
当前问题：Java 中的 HashMap 是什么？
之前对话：用户正在学习大模型和 Java模型结合这些内容后，会判断用户需要的是“概念解释”，而不是复杂源码或源码级原理。
如果用户改问：
HashMap 是怎么解决哈希冲突的？模型就会判断用户需要更深入的原理解释。
所以这一步主要是在确定：应该回答什么内容，以及使用什么难度和表达方式回答。
3.7.5 一个 Token 接一个 Token 地生成答案
模型确定回答方向后，不是一次性把完整答案全部取出来，而是根据已有内容，逐步预测下一个 Token。
例如，模型可能按下面的方式生成：
HashMap
→ HashMap 是
→ HashMap 是 Java
→ HashMap 是 Java 中
→ HashMap 是 Java 中用来保存
→ HashMap 是 Java 中用来保存键值对的集合类。每生成一个 Token，模型就把它接到已有内容后面，再根据新的完整内容预测下一个 Token，直到回答结束。
聊天界面之所以会一边生成、一边显示，是因为模型还在继续生成后面的 Token。这里的“Token”不一定是完整的词，可能只是一个汉字、标点符号或英文单词的一部分。
四、🚀 实践：可以拿来干什么
理解这些概念后，可以解决很多实际问题：
- 估算一次调用大模型的大致成本；
- 判断聊天记录为什么会被模型“遗忘”；
- 判断一篇长文档能否一次交给模型处理；
- 设计 RAG 知识库时决定如何切分文档；
- 选择本地模型时比较模型规模和机器资源；
- 设计 Agent 时控制历史消息、工具结果和最大上下文长度。
在 Java 后端调用大模型时，通常还会遇到这些工程问题：
输入太长 → 超过上下文窗口
输出太长 → 消耗更多 Token
请求太多 → 成本和并发压力增加
历史消息太多 → 需要压缩、摘要或裁剪相关的 Agent 学习主线见：0-学习路线。
五、🔍 最小例子
5.1 一次问答发生了什么
用户输入：
Java 中的 HashMap 是什么？模型会先把问题拆成 Token 和数字编号，再结合上下文与模型参数判断用户想了解 HashMap 的基本概念，最后逐步生成类似下面的回答：
HashMap 是 Java 中用来保存键值对的集合类。完整的 5 步原理见“3.7 一个问题是如何被模型处理的”。这里的重点是：理论章节解释每一步为什么发生，最小例子只展示一次完整问答如何串起来。
5.2 为什么需要关注 Token 数量
假设一次请求包含：
系统提示词：100 Token
历史聊天：1,000 Token
用户问题：100 Token
预留回答：500 Token这次请求大约需要容纳 1,700 个 Token。如果模型的上下文窗口小于这个数量，请求就可能失败、截断，或需要先删除一部分历史内容。
这里的数字只是帮助理解的示例，不代表所有模型的实际分词结果。
六、⚠️ 边界与常见误区
- Token 不是固定的字数。同样长度的中文、英文和代码，Token 数量可能不同。
- 上下文窗口不是永久记忆。没有被重新传入当前请求的历史内容，模型通常无法继续参考。
- 参数越多不一定越聪明。模型效果还取决于训练数据、训练方法、模型结构和任务类型。
- LLM 生成的是概率较高的内容，不是天然可靠的事实查询工具。
- 上下文窗口通常同时受到输入和输出影响，不能把全部窗口容量都当作输入容量。
- “模型参数”和“调用参数”不是一回事。
temperature、max_tokens等是调用时的配置项，不是模型训练后形成的内部参数。 - 对长文档进行问答时，通常不应把所有内容全部塞进上下文，而是先检索相关片段，再交给模型处理。
七、📌 总结
- 快速回顾：LLM 是大语言模型，负责理解和生成内容。
- 快速回顾：Tokenizer 负责把原始文字处理成 Token 和
input_ids。 - 快速回顾：Token 是模型实际处理的文字单位，也影响上下文容量和调用成本。
- 快速回顾：上下文窗口是模型一次请求能够参考的内容上限，不等于永久记忆。
- 快速回顾：模型参数是训练后形成的大量内部数值，决定模型能力的一部分。
- 记忆句：模型靠参数学习，文字拆成 Token，窗口限制可见内容，模型再逐步生成答案。
八、📚 官方资料
- OpenAI 官方 Tokenizer 工具：查看文字如何被切成 Token，并估算 Token 数量。
- Hugging Face 官方课程：Tokenizers：了解词级、字符级和子词分词，以及 Token 到
input_ids的转换。 - Hugging Face 官方课程：构建 Tokenizer 的完整流程：了解规范化、预分词、分词模型和后处理等步骤。
- OpenAI 官方模型文档：查阅具体模型的上下文窗口、最大输出等规格；这些规格会随模型变化，不应把示例数字当成所有模型的固定值。