LLM 核心概念：Token、上下文与能力边界

本文是 AI 应用系统学习系列的 L1 入门篇。前置：无。学完可以配合面试题食用：LLM Decoder-only vs BERT、AI 应用 vs 传统后端陷阱

LLM 到底是什么：一个高级的 next-token predictor

很多人第一次接触 LLM 时被"大模型""智能""涌现"这些词带偏了，以为它像人一样思考。其实 LLM 的本质就是一个 next-token predictor——给定一段文本，预测下一个最可能的 token 是什么。

从 GPT 家族开始，主流架构都转向了 Decoder-only Transformer。简单说就是：输入一段文字，模型用自注意力机制逐层加工，最后输出一个概率分布，选出概率最高的下一个 token。重复这个过程，就生成了完整回答。

数学细节不重要，但有一个认知必须建立：LLM 没有"理解"任何东西，它只是在做统计概率的序列生成。这个底层事实解释了后面所有能力边界。

Token 不是字也不是词：BPE 的直觉

Token 是 LLM 处理文本的最小单位。它既不是字符也不是单词，而是通过 BPE（Byte Pair Encoding） 算法，从训练语料里统计出来的"高频子词片段"。

举个例子：假设"reading"在语料里出现频率够高，BPE 会把它作为一个 token。但"read" + "ing" 分开出现得也挺多，那就各算一个 token。中文场景下，一个汉字大约对应 1~2 个 token，但具体取决于它在训练语料中出现的上下文。

为什么按 token 计费？ 因为模型的计算量（显存/算力）与 token 数量成正比。输入和输出都算 token，API 按 token 数收费，而不是按字符数或字数。

python

import tiktoken

enc = tiktoken.get_encoding("cl100k_base")

# 中文 vs 英文 token 对比
chinese = "人工智能正在深刻改变人类社会"
english = "Artificial intelligence is fundamentally transforming human society"

print(f"中文 '{chinese}' → {len(enc.encode(chinese))} tokens")
print(f"英文 '{english}' → {len(enc.encode(english))} tokens")

# 输出举例：
# 中文 '人工智能正在深刻改变人类社会' → 12 tokens
# 英文 'Artificial intelligence is fundamentally transforming human society' → 10 tokens

同一个意思，中文 token 数 ≈ 1.2 倍英文，但远小于汉字数×字符级的编码。理解这一点，在写 prompt 时就能估算成本。

上下文窗口：KV Cache 不是记忆

上下文窗口（context window）是 LLM 一次能"看到"的最大 token 数。GPT-4 早期是 8K，现在已经扩展到 128K 甚至 1M。但大窗口不等于大记忆。

关键区分：

上下文窗口 = 当前请求里能塞进去的信息量。对话历史、RAG 检索回来的文档、system prompt 都在这里面。
记忆 = 模型能在不同会话之间记住的东西。LLM 本身没有记忆，每次对话是独立的。记忆靠外部系统（数据库、向量存储、缓存）来维持。

还有一个容易混淆的概念：KV Cache。它是 Transformer 推理时的加速机制——把前面层的 Key-Value 计算结果缓存下来，避免重复计算。KV Cache 占的是显存，不是"记住了"什么。上下文窗口越大，KV Cache 占的显存越大，推理速度越慢。

所以： 128K 上下文窗口不是"能记住 128K 内容"，而是"你最多能塞进去 128K 输入"。模型在窗口中间位置的表现，通常不如开头和结尾（Lost in the Middle 现象）。

能力边界清单：LLM 天生不擅长什么

从"next-token predictor"这个本质出发，可以推导出一份能力边界清单：

数学计算：概率模型不擅长精确运算。3.14 和 3.15 在概率空间里差距很小，但数学上差了一个百分位。所以 LLM 算四则运算都容易出错，别说微积分了。

精确检索：问"2023 年 Q3 的营收是多少？"模型可能给出类似但不精确的数字。更适合的方式是让它写 SQL 或调用 API 去查，而不是直接回答。

实时知识：训练数据有截止日期，训练完成后知识就冻结了。模型不知道今天发生了什么，除非你通过 RAG 或搜索工具给它喂最新信息。

长程规划：生成第 100 步时，模型已经"忘了"第 1 步说过的细节。每一步的 token 生成只依赖之前窗口内的上下文，没有全局规划能力。这就是为什么复杂的多步任务需要 Chain-of-Thought 或 ReAct 等外部策略来分解。

事实一致性：模型会编造——不是"有意的"，而是概率上最合理的下一个 token 组合起来恰好是假的。这叫 hallucination，归因于模型的目标是"语义通顺"而不是"事实正确"。

温度 / top_p / 最大长度参数直觉

这几个参数控制 LLM 的"随机性"。

Temperature（温度）：控制 softmax 输出的概率分布有多"陡"。温度低（0.1）→ 模型几乎每次都选概率最高的 token，输出稳定但重复。温度高（1.5）→ 概率分布变平，低概率 token 也有机会被选到，输出更有创意但可能跑题。

Top-p（核采样）：取累计概率达到 p 的最小 token 集合，只在这个集合里采样。Top-p=0.9 意味着只考虑概率最高的 90% 的 token。温度和 top-p 通常二选一调，不用同时改。

max_tokens：限制单次生成的最大 token 数。不是"思考多少"，而是"最多写多少"。有这个限制是因为模型理论上能无限生成，需要截断。

实际经验值：

代码生成 / 事实性回答：temperature=0.1，top_p=0.1
翻译 / 摘要：temperature=0.3，top_p=0.5
头脑风暴 / 创意写作：temperature=0.8，top_p=0.9

python

from openai import OpenAI

client = OpenAI(api_key="sk-your-key", base_url="https://api.openai.com/v1")

response = client.chat.completions.create(
    model="gpt-4o",
    messages=[
        {"role": "system", "content": "你是一个 Java 开发助手，回答问题简洁直接。"},
        {"role": "user", "content": "什么是 ThreadLocal？"}
    ],
    temperature=0.1,
    max_tokens=500
)

print(response.choices[0].message.content)

这是最基础的 API 调用。注意 temperature=0.1 确保回答稳定，max_tokens=500 防止吐出过多废话。

常见误区与小结

误区：模型参数越大，上下文窗口越大。 参数量和上下文窗口是独立的架构设计，参数量大不一定窗口大，取决于 attention 机制和算力优化。
误区：temperature 越高，模型越聪明。 高 temperature 只增加随机性，不提升准确性。对于事实性任务，低 temperature 永远更好。
误区：Token 是汉字或英文单词。 Token 是统计片段，不是语言学单位。同样一段中文，不同 tokenizer 的分法不同，token 数也不同。
误区：上下文窗口大，就不用 RAG 了。 窗口大不等于效果好，长上下文中模型容易丢失中间信息，RAG 仍然是更可靠的方案。
误区：LLM 回答错误是因为"理解错了"。 它没有"理解"这个过程，只是概率生成的序列刚好不合预期。调试思路应该是"这组 token 为什么会出现在这里"而不是"它为什么这么想"。

小结： 理解 LLM 的 next-token prediction 本质，能帮你解释它的所有行为——为什么收费按 token 算、为什么大窗口也有 Lost in the Middle、为什么数学不好。下一篇进入 L2 核心，讲 Prompt Engineering 的工程化方法。

参考

参考：OpenAI Tokenizer 文档 (https://platform.openai.com/tokenizer)、Tiktoken 源码 (https://github.com/openai/tiktoken)、Minimax "Lost in the Middle" 现象分析

LLM 核心概念：Token、上下文与能力边界 ​

LLM 到底是什么：一个高级的 next-token predictor ​

Token 不是字也不是词：BPE 的直觉 ​

上下文窗口：KV Cache 不是记忆 ​

能力边界清单：LLM 天生不擅长什么 ​

温度 / top_p / 最大长度参数直觉 ​

常见误区与小结 ​

参考 ​