Context WindowvsTokenizer

Context Window

Context Window 决定了 LLM 一次能「看到」多少内容。GPT-4 Turbo 支持 128K tokens（约 10 万字），Claude 支持 200K tokens。窗口越大，模型能处理的文档越长、对话越连贯。

Tokenizer

Tokenizer 决定了 LLM 如何「看到」文本。不同的 Tokenizer 会将同一段文字切分成不同的 token 序列，直接影响模型的效率和能力。中文在 GPT 的 Tokenizer 中效率远低于英文。

Context Window

• 从 GPT-3 的 4K 到 Claude 的 200K，增长了 50 倍
• 长上下文不等于长记忆，中间内容容易被忽略（Lost in the Middle）
• 上下文越长推理成本越高，呈二次方增长

Tokenizer

• BPE 是最主流的 Tokenizer 算法
• 同样的文本，中文消耗的 token 数通常是英文的 2-3 倍
• Tokenizer 的词表大小影响模型的多语言能力

Context Window

大语言模型在单次推理中能处理的最大 token 数量

Tokenizer

将原始文本切分为模型可处理的 token 序列的文本预处理组件

Context Window

• 长文档分析和摘要
• 多轮对话的上下文保持
• 代码库级别的理解和生成

Tokenizer

• LLM 的文本输入预处理
• 计算 API 调用的 token 消耗
• 评估不同语言的处理效率

Context Window

Context Window 是 LLM 的核心参数之一，决定了模型能同时处理的信息量。早期模型的 4K token 限制严重制约了应用场景，而 128K-200K 的长上下文使得整本书的分析、长文档问答成为可能。但长上下文带来两个挑战：计算成本随长度二次方增长（FlashAttention 等技术在缓解）、以及「Lost in the Middle」现象——模型对上下文中间部分的注意力明显弱于开头和结尾。

Tokenizer

Tokenizer 是 LLM 的输入预处理组件，将原始文本转换为模型可处理的整数序列。主流算法包括 BPE（Byte Pair Encoding）、WordPiece 和 SentencePiece。Tokenizer 的设计直接影响模型效率：GPT-4 的 Tokenizer 对中文的编码效率约为英文的 1/2-1/3，意味着处理同样长度的中文需要更多 token 和更高成本。DeepSeek 等中文模型通过扩大词表来优化中文编码效率。