长上下文为什么重要？

长上下文是Agent的基础设施。Agent需要记住长对话历史、处理长文档、执行多步推理——这些都依赖模型处理超长上下文的能力。从4K到1M，上下文窗口的扩展正在改变AI应用的可能性边界。

核心挑战

挑战一：注意力计算的二次复杂度

标准Transformer的自注意力计算复杂度是O(n²)：

Attention(Q, K, V) = softmax(QK^T / √d) * V

Q: [n, d], K: [n, d] → QK^T: [n, n] → O(n²)

从4K到128K，计算量增长1000倍。直接外推不可行。

挑战二：KV Cache的显存爆炸

推理时KV Cache的大小与序列长度成正比：

单层KV Cache大小 = 2 * n_heads * head_dim * seq_len * 2 bytes (FP16)

以70B模型为例(64头, 128维, 80层):
128K上下文 KV Cache ≈ 2 * 64 * 128 * 128000 * 80 * 2 = 320GB

320GB的KV Cache远超单GPU显存，必须分片或压缩。

挑战三：长程信息衰减

即使能处理长上下文，模型对中间部分的信息利用效率也在下降——这被称为"Lost in the Middle"现象：

信息利用率:
  开头部分: ████████████ (高)
  中间部分: ████ (低)
  结尾部分: █████████████ (高)

挑战四：外推问题

模型在训练时见过4K长度，推理时需要处理128K——位置编码在未见过的长度上表现不佳。

技术解决方案

位置编码优化

RoPE旋转位置编码

标准旋转位置编码在长上下文时效果下降。解决方案：

Position Interpolation（位置插值）： 将长序列的位置索引"压缩"到训练范围内：

原始位置: 0, 1, 2, ..., 128K
插值后:  0, 0.25, 0.5, ..., 1.0 (映射到0-4K范围)

YaRN（Yet another RoPE extensioN）： 更精细的分段插值，对不同频率的维度使用不同缩放策略：

  • 低频维度（长距离）：激进缩放
  • 高频维度（短距离）：保持不变
  • 中频维度：平滑过渡

NTK-aware Scaling： 基于神经正切核理论的缩放方案，在不重新训练的情况下扩展上下文。

注意力机制优化

滑动窗口注意力

每个token只关注局部窗口内的token：

窗口大小w=4096
token i 关注: [i-w, i+w] 范围内的token
复杂度: O(n*w) → 近似线性

局限性：无法直接访问远处信息。通过堆叠多层，信息可以"传递"到远处——类似CNN的感受野。

稀疏注意力

选择性地关注重要位置：

  • Big Bird：窗口注意力+全局注意力+随机注意力
  • Longformer：类似设计，部分token有全局注意力
  • Sparse Transformer：固定模式的稀疏注意力

Flash Attention

不是改变注意力计算方式，而是优化内存访问模式：

  • 将注意力矩阵分块计算
  • 减少GPU HBM与SRAM之间的数据搬运
  • 不改变数学结果，但速度提升2-4倍

Flash Attention 2/3进一步优化了GPU利用率，已成为长上下文训练的标准配置。

KV Cache优化

GQA/MQA

  • MQA（Multi-Query Attention）：所有head共享一对KV → KV Cache减少为1/n_heads
  • GQA（Grouped Query Attention）：分组共享KV → 折中方案
  • MLA（Multi-head Latent Attention）：低秩压缩KV → DeepSeek的创新

KV Cache量化

将KV Cache从FP16量化到INT8或INT4：

  • 显存减半或1/4
  • 精度损失可控
  • 需要硬件支持INT8/INT4矩阵运算

KV Cache Eviction

基于注意力分数动态删除不重要的KV对：

  • 计算每个KV对的累积注意力分数
  • 低分KV对被驱逐
  • 保留高信息密度的KV对

模型架构创新

线性注意力

将softmax注意力替换为线性近似：

标准: softmax(QK^T)V  → O(n²)
线性: φ(Q)(φ(K)^T V)  → O(n·d²)

当n » d时（长序列），线性注意力更高效。代表：Performer、Linear Transformer、RWKV。

状态空间模型

Mamba、RWKV等SSM架构：

  • 用递归状态替代注意力
  • 线性复杂度O(n)
  • 天然支持无限长上下文
  • 但在长上下文推理任务上表现仍不如Transformer

长上下文评估

评估基准

  • Needle in a Haystack：在长文档中放置一个关键事实，测试模型是否能找到
  • LongBench：中英文长文本理解多任务基准
  • InfiniteBench：超长上下文（100K+）评估
  • RULER：合成的长上下文能力评估（检索、多跳推理、聚合等）

关键发现

  1. 有效上下文≠名义上下文：模型声称128K上下文，但有效利用可能只有32K
  2. 位置偏差：开头和结尾的信息利用率高于中间
  3. 任务依赖：信息检索任务在长上下文表现好于推理任务
  4. 指令位置：关键指令放在prompt末尾效果最好

实践建议

使用长上下文的策略

  1. 分层组织：系统prompt在最前，关键信息在最后
  2. 结构化标记：用XML标签或markdown分隔不同部分
  3. 定期摘要：长对话中定期让模型总结历史
  4. 分段处理：超长文档分段处理再合并结果

成本控制

长上下文意味着更高的token成本：

  • 优先用小模型处理长上下文（摘要、检索）
  • 只在关键推理步骤用大模型的长上下文
  • 使用prefix caching减少重复计算

总结

长上下文模型正在从"能不能"走向"好不好"。128K甚至1M的上下文窗口已经实现，但有效利用这些上下文还有很长的路要走。从位置编码优化到KV Cache压缩到架构创新，每个环节都在快速进步。长上下文是Agent能力的使能技术——当模型能真正理解和利用长上下文时，Agent的"记忆容量"将迎来质变。