长上下文模型
852 字约 3 分钟
domain/aiai/llm
2026-07-24
1. 核心结论
- 长上下文模型能够处理数万到数百万 token 的输入，支持整本书、长视频、大代码库的理解
- 上下文窗口扩展面临计算复杂度 O(n^2) 和内存占用的挑战
- 模型在长上下文中的注意力会分散，"大海捞针"能力随位置变化
- RoPE 插值、ALiBi、Ring Attention 等技术是扩展上下文的关键
- 长上下文不等于好理解，需要配合检索和摘要策略
2. 基础概念
上下文窗口（Context Window）：模型一次能处理的最大 token 数量。
Needle In A Haystack（NIAH）：测试模型在长文本中定位关键信息的能力。
RoPE（Rotary Positional Embedding）：旋转位置编码，支持长度外推。
ALiBi（Attention with Linear Biases）：通过注意力偏置实现长度外推。
KV Cache：缓存注意力计算中的 K、V 矩阵，加速自回归生成。
Ring Attention：分布式注意力计算，突破单设备内存限制。
3. 工作原理
长上下文扩展技术：
- 位置编码改进：
- RoPE 插值：缩放位置编码频率
- NTK-aware：调整频率维度
- YaRN：动态缩放因子
- 注意力优化：
- Flash Attention：减少内存访问
- Sparse Attention：只计算部分注意力
- Sliding Window：局部注意力窗口
- 分布式计算：
- Ring Attention：跨设备分片计算
- Sequence Parallelism：序列并行
- 训练策略：
- 渐进式长度扩展
- 长文本数据混合
主流模型上下文能力：
- Claude 3.5 Sonnet：200K tokens
- GPT-4 Turbo：128K tokens
- Gemini 1.5 Pro：1M-2M tokens
- Llama 3.1：128K tokens
- Qwen 2.5：128K tokens
长上下文挑战：
- 注意力分散：模型难以关注到所有信息
- 位置偏差：倾向于关注开头和结尾的内容
- 成本增加：计算和内存消耗随长度增长
- 质量下降：超长上下文中幻觉率增加
4. 实战场景
- 长文档分析：合同审查、论文阅读、报告摘要
- 代码库理解：整个项目的代码分析和重构
- 会议记录：长时间会议的内容提取和总结
- 法律文件：多份法律文档的交叉引用分析
- 视频理解：长视频的字幕分析和内容摘要
- 批量处理：单次请求处理多个任务
5. 常见误区
- 认为长上下文能替代 RAG：检索仍然必要，长上下文成本高
- 忽视位置偏差：关键信息放在中间可能被忽略
- 不验证理解质量：长上下文不等于准确理解
- 盲目追求大窗口：大多数场景不需要超长上下文
- 忽视 token 成本：长上下文 API 调用成本显著增加
6. 进阶方向
- 无限上下文架构
- 层次化注意力机制
- 上下文压缩与摘要
- 长上下文评估基准
- 高效 KV Cache 管理
- 上下文窗口动态调整
7. 推荐资料
- Anthropic Long Context - https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/long-context-tips
- Google Gemini Long Context - https://ai.google.dev/gemini-api/docs/context-window
- Ring Attention Paper - https://arxiv.org/abs/2310.01889
- Flash Attention - https://github.com/Dao-AILab/flash-attention
- NIAH Test - https://github.com/gkamradt/LLMTest_NeedleInAHaystack