大模型基础概念

一、Token：模型眼中的”字”

什么是 Token

人类读文字是一个字一个字读的，模型处理文字的基本单位叫 Token。

Token 不等于字，也不等于词，是模型自己学出来的一种切分方式。

以英文为例：

1 2	"Hello, world!" → ["Hello", ",", " world", "!"] 共 4 个 Token "unbelievable" → ["un", "believ", "able"] 共 3 个 Token

以中文为例：

1
2
3

"你好世界"  → ["你好", "世界"]            共 2 个 Token
"人工智能"  → ["人工", "智能"]            共 2 个 Token
"量子纠缠"  → ["量子", "纠", "缠"]        共 3 个 Token（生僻组合拆得更碎）

规律大概是这样：常见词/词组通常是 1 个 Token，生僻词、专业术语会被拆成多个，中文平均 1 个汉字约等于 0.6-0.7 个 Token，数字和标点也占 Token。

为什么要理解 Token

有两个很实际的原因。

第一是计费。所有大模型 API 按 Token 计费，输入和输出分开算：

第二是上限。每个模型每次能处理的 Token 总量有上限，超了就报错。

Token 估算经验值

内容	大约 Token 数
1 个英文单词	1-2 个 Token
1 个中文汉字	0.6-0.7 个 Token
1 页 A4 中文文字（约 800 字）	约 550 个 Token
一本 10 万字小说	约 7 万 Token
一次普通对话（来回 5 轮）	约 500-1000 Token

不想手动算的话，可以去 platform.openai.com/tokenizer 直接粘贴文字查 Token 数，挺好用的。国内的也有，但是不稳定。

二、上下文窗口：模型的”工作台”

是什么

大模型每次处理请求时，能接收的 Token 总量有上限，这个上限叫上下文窗口（Context Window）。

可以把它比作工作台：工作台大小固定，你能摆多少材料，模型就能”看到”多少内容。超出工作台的内容，模型完全不知道。

主流模型窗口大小

模型	上下文窗口	约等于
GPT-4o	128K Token	约 18 万汉字
Claude 3.5 Sonnet	200K Token	约 28 万汉字
Gemini 1.5 Pro	1M Token	约 140 万汉字
DeepSeek-V3	64K Token	约 9 万汉字
通义千问 Max	32K Token	约 4.5 万汉字

工程上会遇到的三个问题

问题一：多轮对话为什么会”失忆”？

应该有很多人发现跟 ChatGPT 聊很久之后，它开始忘记前面说过的内容。原因就是历史对话累积的 Token 超过了上下文窗口，最早的内容被截断了。

问题二：长文档处理

要让模型分析一份 10 万字的合同，但模型上下文只有 32K Token（约 4.5 万汉字），合同放不进去。这正是 RAG 要解决的问题，后面课程会讲。

问题三：成本控制

上下文越长，每次请求费用越高。生产系统需要管理上下文长度，不能无限增长。

三、消息结构：System、User、Assistant

调用大模型 API，输入不是一段文字，而是一个消息列表，每条消息有固定角色。

角色	说明	类比
system	给模型的背景设定和行为指令	员工入职培训手册
user	用户发送的消息	用户的每次输入
assistant	模型的回复	模型的每次输出

一次多轮对话的消息结构长这样：

[
  {
    "role": "system",
    "content": "你是一个专业的 Java 技术助手，回答要简洁准确，代码示例用 Java 17 语法。"
  },
  {
    "role": "user",
    "content": "什么是 Optional？"
  },
  {
    "role": "assistant",
    "content": "Optional 是 Java 8 引入的容器类，用于表示一个值可能存在也可能不存在..."
  },
  {
    "role": "user",
    "content": "给我一个实际使用的例子"
  }
]

模型收到这个列表，就能理解整个对话上下文，给出连贯的回复。

System Prompt 很重要

System Prompt 是整个 AI 应用的”灵魂”，决定了模型的身份、能做什么、不能做什么、用什么风格回答。

举一个某线上课程商店客服写得比较完整的例子：

你是xxx的智能客服助手。

职责：
- 解答用户关于课程内容的问题
- 帮助用户解决学习中遇到的技术问题
- 引导用户完成课程购买流程

限制：
- 不讨论与课程无关的话题
- 不能承诺任何价格优惠（需转接人工）
- 不确定的信息要明确告知用户

风格：简洁友好，如果举例优先用 Java 代码示例

同样的模型，有这个 System Prompt 和没有，效果天差地别。

四、Temperature：控制模型的”随机性”

模型是怎么生成文字的

模型生成每个词，实际上是在做概率分布采样。比如补全”今天天气很”这句话：

"好"   → 40% 概率
"差"   → 25% 概率
"热"   → 20% 概率
"糟糕" → 10% 概率
"棒"   →  5% 概率

模型不是每次都选概率最高的词，而是按概率”抽签”。Temperature 就是控制这个抽签过程的参数。

Temperature 的效果

Temperature = 0：每次都选概率最高的词，结果确定，每次运行一样，适合代码生成、数据提取这类要求精确的场景。

Temperature = 0.7（默认）：适当随机，有变化但总体合理，适合聊天对话、问答系统。

Temperature >= 1.5：高度随机，极具创意但可能不合逻辑，适合头脑风暴，但很少用这么高。

举个例子：

提示：写一句关于春天的话

Temperature = 0：
  "春天来了，万物复苏，百花盛开。"（每次一样）

Temperature = 0.7：
  第1次："春风轻抚大地，带来了新生的气息。"
  第2次："樱花在春雨中绽放，空气中弥漫着淡淡的花香。"

Temperature = 1.5：
  "春天是时间的叛徒，它用绿色的谎言欺骗了沉睡的种子。"
  （有创意但挺奇怪的）

开发中怎么选

应用场景	推荐 Temperature
JSON 数据提取	0
SQL 生成	0 ~ 0.2
问答系统	0.3 ~ 0.7
聊天助手	0.7
文案创作	0.8 ~ 1.0

五、其他常用参数

Top-P（核采样）

和 Temperature 类似，也是控制随机性的。Top-P = 0.9 表示只从累积概率达到 90% 的词里随机选，排除掉长尾低概率词。

实践建议：Temperature 和 Top-P 不要同时调，选一个就够了。OpenAI 官方推荐调 Temperature，固定 Top-P = 1。

Max Tokens（最大输出长度）

控制模型单次回复最多输出多少 Token。不要设太小（回复被截断），也不要不设（遇到”话痨”模型会产生大量 Token 费用）。

Stop Sequences（停止序列）

指定当模型输出包含某些特定字符串时立即停止生成，用得不多，遇到了再查。

参数速查

参数	默认值	常用设置
temperature	1.0	精确任务用 0~0.3，对话用 0.7
top_p	1.0	通常不动
max_tokens	模型上限	根据场景设合理上限

六、概念串联

一次完整的 API 调用长这样：

{
  "model": "gpt-4o",
  "messages": [
    {
      "role": "system",
      "content": "你是一个 Java 技术助手，回答简洁准确。"
    },
    {
      "role": "user",
      "content": "用一句话解释什么是 Spring Bean"
    }
  ],
  "temperature": 0.3,
  "max_tokens": 200
}