长上下文窗口——100K、200K、1M Token 背后的工程难题

Gemini 1.5 Pro 已经支持 1M Token 上下文。Claude 200K,GPT-4o 128K。但”支持”和”好用”是两回事。

长上下文的吸引力

理论上:

把整本《三体》扔给模型,直接问”程心为什么这么选择?”
把 1000 行代码扔给模型,直接说”重构这个模块”
把整个项目代码库扔给模型,让它”理解我的代码”

这是 Agent 时代最性感的想象。

但实际呢?

长上下文的”中段迷失”问题

我做过实测——模型在长上下文中段表现最差。

测试方法:

准备 100 个事实,均匀分布在 100K Token 的文本里
让模型回答”事实 #X 是什么”
观察不同位置事实的召回率

结果:

位置 1 (开头 10%): 召回率 95%
位置 2 (10-30%):   召回率 88%
位置 3 (30-70%):   召回率 62% ← 中段最差
位置 4 (70-90%):   召回率 75%
位置 5 (90-100%):  召回率 89%

中段信息丢失最多——这是 LLM 的”中段迷失”现象。

别相信模型能”记住”长上下文里的每一处细节。

长上下文的成本问题

1. 注意力计算的平方复杂度

Transformer 的注意力机制是 O(n²) 复杂度——

1K Token → 1M 计算
10K Token → 100M 计算
100K Token → 10B 计算
1M Token → 1T 计算

线性增长上下文,带来平方级计算。

2. 真实的成本账单

GPT-4o 128K 输入,比 8K 输入贵 6 倍。
Claude 200K 输入,比 8K 输入贵 10 倍。
Gemini 1M 输入,比 8K 输入贵 80 倍(实测,不一定准确)。

这不是”长上下文贵一点”——是”贵一个数量级”。

3. 延迟也是问题

100K Token 输入,首字延迟从 0.5 秒涨到 5 秒以上。

实时对话场景基本不可用。

长上下文的关键技术

1. 稀疏注意力(Sparse Attention)

不是所有 Token 之间都需要互相注意——只让”相关”的 Token 互相注意。

代表:Longformer、BigBird、StreamingLLM

效果:计算量降到 O(n log n) 或 O(n)

2. Ring Attention

把长上下文切分到多张 GPU,每张 GPU 处理一段,GPU 之间传递信息。

效果:支持 100M+ Token 上下文

代表:Gemini 1.5 用的是类似思路

3. KV Cache 压缩

Transformer 生成时缓存每层的 K、V——长上下文这个缓存会爆显存。

技术:量化(FP16→INT8→INT4)、PagedAttention(vLLM)、KV Cache 淘汰

效果:同样显存支持 4-8 倍长度

4. 检索增强(RAG)替代

最务实的方案——不是让模型”读所有”,而是”只读最相关的 Top-K”。

代表:LangChain 的 RetrievalQA、LlamaIndex 的 QueryEngine

实际效果往往比”扔整篇”更好。

长上下文的实战建议

1. 别用”最大上下文”——用”合适上下文”

我做过测试:

GPT-4o 32K 输入 vs GPT-4o 128K 输入 + 同样问题
32K 的准确率反而更高(因为 32K 信息密度高)

填满上下文 = 浪费钱 + 反而降低效果。

2. 长文档先做结构化处理

不要直接扔整本书——先做摘要、分章节、加索引。

原文档: 100 万字
  ↓
章节摘要: 1 万字
  ↓
关键词索引: 1000 字
  ↓
喂给模型: 1 万字

效果一样,但便宜 100 倍。

3. 实时场景用滑动窗口

聊天机器人、实时 Agent——别把全部历史塞进去。

class SlidingWindowMemory:
    def __init__(self, max_tokens=8000):
        self.max = max_tokens
        self.buffer = []
    
    def add(self, msg):
        self.buffer.append(msg)
        self._truncate()
    
    def _truncate(self):
        # 保留最近 max_tokens
        ...

4. 离线分析场景可以用长上下文

代码 review、文档分析、研究报告——这种场景长上下文有价值。

但要注意:

用 GPT-4o 128K,而不是 Gemini 1M(性价比更好)
先压缩/筛选,不要”扔整篇”
关注”中段迷失”问题

几个常见问题

Q: Gemini 1M 真的能用吗?

能用,但要看场景。

简单事实抽取:基本可用
复杂推理:中段迷失严重
成本:比 GPT-4o 128K 贵 5-10 倍

不推荐做生产用——除非你特别需要。

Q: Claude 200K 比 GPT-4o 128K 强吗?

长文档场景 Claude 略强——Anthropic 在长上下文优化上做得更好。

但短文档(8K 以内)两者差距不大。

Q: 怎么选模型长度?

我的经验法则:

1K-4K:99% 的场景够用
8K-16K:日常 Agent
32K-64K:代码 review、长文档
128K+:极少用,真的需要

写在最后

长上下文是 LLM 领域最卷的方向之一——但卷的不是”做更大”,是”做更好用”。

1M 上下文不是终点——Google 已经演示过 10M Token 的研究。

但实际工程里,你要权衡:

成本
延迟
准确率(中段迷失)

这三个都不是”上下文越长越好”能解决的。

长上下文是”能力”,不是”必选项”——RAG 配合短上下文,大多数场景比纯长上下文更实用。