LLM Context Window 竞赛：一场没有终点的马拉松

Context window 是什么

简单说：context window 是 LLM 一次能处理的 token 数量。

你跟 LLM 对话的历史、所有背景信息、你给的文档——都在 context window 里。

context window 越大，LLM 能同时处理的"记忆"就越多。

2023 年的 context window 竞赛

数字看起来很吓人。但这些数字在实际场景里能用在哪里？

真实使用场景

场景 1：代码库分析

200k context 理论上可以把整个代码库丢给 LLM。

# 实际测试：分析一个有 50 万行代码的项目
# Claude 2 (100k) 可以分析到什么？
# - 单个文件的完整分析：✅
# - 10 个相关文件的分析：✅
# - 整个代码库：❌ (超出 100k)

# 实际上 100k tokens 大约等于 7.5 万英文单词
# 或者 2500 行代码

结论：100k 对单个模块或小型代码库够用，对大型代码库依然不够。

场景 2：长文档处理

# 典型场景：处理一本技术书籍
# 《Designing Data-Intensive Applications》
# - 英文版约 30 万词
# - 100k tokens ≈ 7.5 万词
# - 需要分 4 次处理

Claude 200k 可以一次处理完一本普通技术书的大部分章节。但实际意义有限——你需要先从书里找特定信息，不是整本丢进去。

场景 3：多文档比较

# 实际用例：比较 10 份技术文档
# 每份文档平均 1 万词
# 10 份 = 10 万词 = 约 130k tokens

# 200k context 可以一次处理
# 但输出质量取决于你怎么组织 prompt

context window 的真实限制

1. 模型不一定会"用满"整个 context

研究发现，随着 context 变长，LLM 对中间信息的注意力会下降——这叫 “lost in the middle”。

# 实验：把代码分成三段
# 开头：设置代码
# 中间：核心逻辑
# 结尾：测试代码

# 问：测试代码验证了什么功能？
# 8k context: 准确回答
# 200k context: 经常答错（忘了中间内容）

所以即使有 200k context，如果你的信息放在中间，LLM 可能还是会漏掉。

2. 成本随着 context 增长

# GPT-4 32k 的成本：
# - 8k tokens 以内：$0.03/1k tokens
# - 超过 8k：$0.06/1k tokens

# 实际对话：
# - 32k context 的平均成本 ≈ 8k context 的 3 倍

3. 延迟是另一个问题

# 32k context 的 first token 时间
# GPT-4 32k: ~30-60 秒
# Claude 100k: ~15-30 秒

# 这还是单轮对话
# 多轮对话累计 context，时间会更长

实用建议

不要被数字迷惑。

context window 是能力，但不代表你需要一直用满。

结论

2023 年的 context window 竞赛是宣传战，不是技术突破。

200k context 听起来很厉害，但：

• 大多数场景不需要这么大
• 模型对中间内容注意力会下降
• 成本和延迟是真实问题

更重要的是：怎么组织 context 让 LLM 有效利用，比单纯增加 window 大小更重要。

这才是 2024 年需要解决的问题。