模型基础04：大模型工作方式

大模型的工作方式和传统软件完全不同，它不是执行代码，而是根据上下文预测下一个 token。理解这个过程，才能更好地使用和调试大模型。

Token：大模型的基本单位

大模型处理的不是单词或字符，而是 token。理解 token 是理解模型工作方式的第一步。

什么是 Token

Token 是文本的基本单位，介于字符和单词之间：

字符：最小单位，如 ‘a’、‘中’
Token：语义单位，如 ‘apple’、‘un’、‘##able’（## 表示词尾）
单词：完整意义单位，如 ‘unable’

Token 化过程

模型在处理文本前，会先进行 token 化：

分词：将文本拆分为 token
编码：将每个 token 转换为数字 ID
嵌入：将数字 ID 转换为向量

示例：

输入："Hello, how are you?"
Token化：["Hello", ",", "how", "are", "you", "?"]
编码：[15496, 11, 1299, 389, 345, 30]

Token 数量估算

语言	1000 tokens ≈	备注
英文	750 个单词	约 1.3 tokens/单词
中文	500 个汉字	约 2 tokens/汉字
代码	500-700 行	视代码复杂度

Token 成本

API 按 token 计费，需要关注成本：

操作	计费方式	说明
输入	按输入 token 数计费	Prompt + 上下文
输出	按输出 token 数计费	生成的文本
总费用	输入费用 + 输出费用	两者都计费

上下文窗口：模型的记忆范围

上下文窗口是模型能处理的最大 token 数量，决定了模型的记忆范围。

上下文窗口的限制

不同模型的上下文窗口不同：

模型	上下文窗口	适用场景
GPT-3	2048 tokens (~1500 单词)	短对话、简单任务
GPT-3.5-turbo	4096/16384 tokens	中等长度任务
GPT-4	8192/32768 tokens	长文档理解
LLaMA-2-7B	4096/8192/32768 tokens	可配置
Claude 3 Opus	200K tokens	超长文档

上下文窗口的影响

超出窗口的处理：

截断：超出部分被丢弃（大多数 API 默认）
滑动窗口：只保留最近的内容
摘要压缩：对旧内容进行摘要

上下文长度与性能：

更长的上下文 → 更好的理解能力
更长的上下文 → 更高的成本
更长的上下文 → 更慢的响应

上下文管理策略

策略	适用场景	优缺点
完整上下文	短对话	简单，但受窗口限制
滑动窗口	长对话	保持最近信息，丢失历史
摘要压缩	长文档	保留关键信息，可能丢失细节
RAG（检索增强）	需要外部知识	扩展知识范围，增加复杂度
分层上下文	复杂任务	结构化管理，需要设计

采样参数：控制生成行为

采样参数决定了模型生成文本的风格和多样性，是控制模型输出的关键。

Temperature（温度）

控制输出的随机性：

值	效果	适用场景
0	确定性输出，每次相同	精确任务、代码生成
0.3	低随机性，稳定可靠	事实性问答
0.7	中等随机性，平衡多样与稳定	大多数场景
1.0	高随机性，创造性强	创意写作、头脑风暴
1.5+	极高随机性，可能混乱	特殊创意任务

Top-p（核采样）

控制候选 token 的范围：

值	效果	适用场景
0.1	只考虑概率最高的 10%	精确任务
0.5	考虑概率最高的 50%	平衡多样与精确
1.0	考虑所有 token	最大多样性

Top-k

控制候选 token 的数量：

值	效果	适用场景
1	只选概率最高的 token	完全确定
10	从概率最高的 10 个中选	平衡
100	从概率最高的 100 个中选	高多样性
-1	不限制	最大多样性

常见采样策略组合

场景	Temperature	Top-p	Top-k	说明
代码生成	0-0.2	0.95	-1	精确、可执行
事实问答	0.3-0.5	0.9	-1	稳定、可靠
普通对话	0.7	0.9	-1	自然、多样
创意写作	0.8-1.0	0.95	-1	创造性
角色扮演	0.9-1.2	0.95	-1	生动、有趣

指令遵循：让模型做正确的事

指令遵循是大模型理解并执行用户指令的能力，是 Prompt 工程的核心。

指令遵循的层次

层次	描述	示例
字面理解	直接执行指令	”写一段介绍 AI 的文字”
隐含意图	理解潜在需求	”帮我看看这段代码有什么问题”
多步推理	需要拆解任务	”分析这个业务需求并给出技术方案”
工具使用	需要调用外部工具	”查一下明天的天气”

提高指令遵循的方法

明确任务定义：

角色：你是一名资深软件架构师
目标：分析以下业务需求，给出技术方案
输入：业务需求文档
输出：技术方案文档（包含架构图、技术选型、风险评估）
约束：使用 Java 技术栈，考虑高并发场景

提供示例：

示例输入：用户登录需求
示例输出：技术方案...

设定验收标准：

验收标准：
1. 方案包含至少 3 种技术选型对比
2. 风险评估包含至少 5 个风险点
3. 架构图使用 Mermaid 格式

指令遵循的挑战

挑战	原因	解决方案
指令模糊	用户描述不清晰	追问澄清，定义模板
目标漂移	模型偏离任务目标	明确约束，定期提醒
步骤遗漏	复杂任务遗漏步骤	提供步骤清单
格式错误	输出格式不符合要求	提供格式示例

预训练与微调：模型的学习过程

大模型的能力来自预训练和微调两个阶段。

预训练

预训练是模型学习通用知识的过程：

数据收集：收集大规模文本数据（书籍、网页、代码等）
目标设定：预测下一个 token（自监督学习）
训练过程：反复迭代，调整模型参数
结果：模型学会语言理解、知识储备和推理能力

预训练的特点：

数据量大（万亿级 token）
训练时间长（数周甚至数月）
成本高（百万甚至千万美元）
能力通用（但不一定精准）

微调

微调是让模型适应特定任务的过程：

数据准备：收集特定任务的标注数据
目标设定：根据任务类型设定目标（分类、生成等）
训练过程：在预训练模型基础上继续训练
结果：模型在特定任务上表现更好

微调的方式：

方式	数据需求	效果	适用场景
全量微调	大量标注数据	效果最好	有充足数据
LoRA	少量标注数据	效果较好	数据有限
指令微调	指令-响应对	提升指令遵循	通用任务
RLHF	人类反馈数据	对齐人类偏好	用户体验

推理时微调（In-Context Learning）

不需要训练，通过在上下文中提供示例来指导模型：

Few-shot Learning：

示例1：输入→输出
示例2：输入→输出
当前输入：...

Zero-shot Learning：

直接给出指令，不需要示例

Chain-of-Thought：

让模型一步步推理，展示中间过程

模型能力的边界

理解模型的能力边界，才能正确使用模型。

模型能做什么

能力	描述	示例
语言理解	理解文本含义	阅读理解、情感分析
文本生成	生成自然语言	写文章、对话
知识问答	回答事实性问题	”地球有多大”
推理能力	逻辑推理	数学题、推理题
代码生成	编写代码	实现功能、修复 bug
多模态	处理图像、语音	看图说话、语音转文字

模型不能做什么

限制	原因	示例
实时信息	训练数据截止到某个时间	”今天的新闻”
精确计算	数学计算可能出错	”12345 × 6789”
因果推理	可能混淆相关性和因果性	”吸烟导致肺癌”
隐私保护	可能泄露训练数据中的隐私信息	”某人的邮箱”
长期记忆	上下文窗口有限	”记住昨天的对话”
价值判断	没有价值观，可能产生偏见	”什么是好的”

模型错误的类型

错误类型	描述	示例
幻觉	编造事实	”地球是平的”
遗漏	遗漏重要信息	回答不完整
错误推理	逻辑错误	”2+2=5”
偏见	产生歧视性内容	”女性不适合编程”
前后矛盾	同一回答中自相矛盾	先说 A 再说非 A

项目判断清单

需要精确输出（代码、公式）→ 降低 Temperature（0-0.2）
需要创意输出（写作、方案）→ 提高 Temperature（0.8-1.0）
文本超出上下文窗口 → 分块处理或用 RAG
模型输出不稳定 → 调整采样参数或提供示例
需要特定领域知识 → 微调或提供上下文
需要实时信息 → 结合搜索或 API
需要精确计算 → 调用计算器 API