【词汇专栏】Long Context：长上下文——AI的超长记忆
·
Long Context：长上下文——AI的超长记忆
一句话理解
Long Context（长上下文） 是大模型处理超长文本的能力——从几千Token到上百万Token，让AI能"读完一本书再回答"。
传统模型：上下文窗口 = 4K / 8K / 32K tokens
长上下文模型：上下文窗口 = 128K / 1M / 10M tokens
（可处理整本书、全部代码库、整年聊天记录）
为什么需要长上下文？
短上下文的局限性
| 场景 | 问题 | 结果 |
|---|---|---|
| 聊天记录分析 | 可能有100K tokens，模型只支持8K | 只能看最近几天，断章取义 |
| 代码库问答 | 可能有100万行，模型只能读前几百行 | 问函数定义，模型一脸懵 |
| 法律合同分析 | 可能有100页，模型只能读前20页 | 遗漏关键条款，风险巨大 |
长上下文解决了什么
| 场景 | 短上下文 | 长上下文 |
|---|---|---|
| 文档问答 | 只看摘要 | 完整读完原文档 |
| 代码分析 | 只看当前文件 | 理解整个代码库 |
| 数据分析 | 只看样本 | 处理全量数据 |
| 对话记忆 | 只记最近几轮 | 记住整个对话历史 |
| 多文档比较 | 逐一分析 | 同时理解所有文档 |
技术原理
注意力机制的挑战
标准Transformer的注意力复杂度：
Attention(Q, K, V) = softmax(QK^T / √d) × V
其中 QK^T 的计算复杂度：O(N²)
N = 序列长度
| 序列长度 | 计算次数 | 体验 |
|---|---|---|
| N = 1,000 | 1,000,000 次 | 可接受 |
| N = 10,000 | 100,000,000 次 | 有点慢 |
| N = 100,000 | 10,000,000,000 次 | 爆炸！ |
| N = 1,000,000 | 1,000,000,000,000 次 | 不可能 |
解决方案：优化注意力机制
主流优化技术
1. 稀疏注意力（Sparse Attention）
核心思想：不是所有Token都需要attend to所有其他Token
┌────────────────────────────────────────────────────────┐
│ │
│ Full Attention（全连接）： │
│ [A] ───[●]───[●]───[●]───[●] │
│ [●] ───[●]───[●]───[●]───[●] │
│ [●] ───[●]───[●]───[●]───[●] │
│ [●] ───[●]───[●]───[●]───[●] │
│ [●] ───[●]───[●]───[●]───[●] │
│ │
│ Sparse Attention（稀疏）： │
│ [A] ───[●]──────────[●] │
│ [●] ───[●]──────────[●] │
│ [●] ─────────────[●]──[●] │
│ [●] ─────────────[●]──[●] │
│ [●] ───[●]──────────[●] │
│ │
│ A=锚点 ●=局部 ●=全局 │
│ │
└────────────────────────────────────────────────────────┘
只计算重要的注意力连接，忽略不相关的
2. 滑动窗口注意力（Sliding Window）
每个Token只关注最近的N个Token：
┌────────────────────────────────────────────────────────┐
│ │
│ 窗口大小 = 3： │
│ Token 1: attend [1, 2, 3, 4] │
│ Token 2: attend [1, 2, 3, 4, 5] │
│ Token 3: attend [2, 3, 4, 5, 6] │
│ ... │
│ │
│ 复杂度：O(N × W)，W=窗口大小 │
│ 比O(N²)小很多！ │
│ │
└────────────────────────────────────────────────────────┘
3. 线性注意力（Linear Attention）
将 softmax(QK^T) 近似为线性操作：
Attention ≈ φ(Q) × (φ(K)^T × V)其中 φ 是某种变换
| 方案 | 复杂度 | 100K tokens计算量 |
|---|---|---|
| 标准注意力 | O(N²) | 10,000,000,000 ops |
| 线性注意力 | O(N) | 100,000 ops |
快了10万倍！
4. KV Cache优化（见W19）
配合KV Cache：
- 稀疏注意力 + KV Cache = 推理加速
- 分块管理 + PagedAttention = 支持更长序列
2026年主流模型上下文对比
| 模型 | 上下文窗口 | 技术特点 |
|---|---|---|
| Claude 3.7 Sonnet | 200K tokens | 原生支持，精准召回 |
| Gemini 1.5 Pro | 2M tokens | 200K → 1M → 2M演进 |
| GPT-4o | 128K tokens | 原生支持 |
| DeepSeek-V3 | 128K tokens | 64K专家 + 动态路由 |
| Qwen2.5 | 1M tokens | 开源最强 |
| GLM-4 | 128K tokens | 中文优化 |
实际应用场景
1. 文档分析与问答
# 典型应用：基于长文档的问答
document = load_pdf("年度财务报告.pdf") # 500页，~200K tokens
prompt = f"""
请分析以下文档，回答问题。
文档内容：
{_document}
问题：
1. 公司去年的营收增长是多少？
2. 主要风险因素有哪些？
3. 未来战略规划是什么？
"""
# 传统模型：无法处理，需要先摘要
# 长上下文模型：直接全文分析
response = model.generate(prompt)
2. 代码库理解
场景：问"这个函数被哪些地方调用？"
- 代码库规模：100万行代码
| 方案 | 步骤 | 结果 |
|---|---|---|
| 短上下文 | 1. 用语义搜索找到函数定义 | 遗漏远处的调用 |
| 2. 在附近几页代码中搜索调用 | ||
| 长上下文 | 1. 将整个代码库加载到上下文 | 准确找到所有调用点 |
| 2. 模型直接分析调用关系图 | ||
| 3. 准确找到所有调用点 |
3. 多文档比较
场景：比较10份竞品分析报告，找出差异点
传统做法：
- 一份一份读，逐一对比
- 容易遗忘，信息碎片化
长上下文做法：
- 10份报告一起读
- 直接输出对比分析
- 不会遗漏任何信息
代码示例
使用LangChain处理长文档
from langchain_community.document_loaders import PyPDFLoader
from langchain.text_splitter import RecursiveCharacterTextSplitter
from langchain_community.vectorstores import Chroma
from langchain_openai import OpenAIEmbeddings
from langchain.chains import RetrievalQA
# 1. 加载PDF（500页）
loader = PyPDFLoader("annual_report.pdf")
documents = loader.load()
# 2. 切分文档（保留重叠，保证上下文连续性）
splitter = RecursiveCharacterTextSplitter(
chunk_size=4000, # 4K tokens
chunk_overlap=500, # 500 tokens重叠
length_function=len,
)
chunks = splitter.split_documents(documents)
# 3. 存入向量数据库
embeddings = OpenAIEmbeddings()
vectorstore = Chroma.from_documents(chunks, embeddings)
# 4. 检索增强生成（RAG）
qa_chain = RetrievalQA.from_chain_type(
llm=model,
retriever=vectorstore.as_retriever(search_kwargs={"k": 5}),
)
# 5. 问答
result = qa_chain.invoke({"query": "公司去年营收增长了多少？"})
配合Long Context API
from anthropic import Anthropic
client = Anthropic()
# Claude 3.7支持200K上下文
response = client.messages.create(
model="claude-sonnet-4-20250514",
max_tokens=4096,
messages=[
{
"role": "user",
"content": [
{
"type": "document",
"source": {"type": "pdf", "source": {"type": "upload"}},
"context": "这是一份年度财务报告，请分析其中的关键信息。"
}
]
}
]
)
长上下文的挑战与解决方案
挑战1：信息召回率
问题：上下文太长，模型容易"迷失"在信息海洋中
| 位置 | 记忆程度 | 说明 |
|---|---|---|
| 前10K tokens | 容易记住 | 位置效应 |
| 中间50K tokens | 容易遗忘 | “Lost in the middle” |
| 最后10K tokens | 容易记住 | Recency effect（近因效应） |
中间部分 = “Lost in the middle”
解决方案：
- 增强检索：先用向量搜索找到相关段落
- 分块处理：将长文档分成多段，逐一处理
- 层级总结：先摘要，再基于摘要回答
挑战2：推理成本
成本对比（GPT-4o 128K上下文）：
输入 1K tokens：$0.003
输入 128K tokens：$0.384（128倍！）
解决方案：
1. 只上传必要的内容
2. 使用压缩技术（如LLMlingua）
3. 检索增强，不要全量上传
挑战3：KV Cache显存
128K tokens的KV Cache有多大？
以半精度(FP16)计算：
- 32层 × 隐藏维度12896 × 2字节 × 128K × 2(K+V)
≈ 200GB显存！
解决方案：
- PagedAttention（vLLM）
- ChunkKV压缩
- 量化到INT8/INT4
2026年最新进展
Gemini 2.0 Flash长上下文
2026年最新突破：
├─ 上下文窗口：10M tokens（1000万！）
├─ 可处理：4小时的视频 + 音频 + 文本
├─ 技术：动态稀疏注意力 + 金字塔检索
└─ 价格：相比Gemini 1.5降低80%
Long Context Model的新评测标准
传统评测：大海捞针（Needle in Haystack）
把一个秘密藏在100K tokens中，让模型找出来
| 模型 | Needle in Haystack结果 |
|---|---|
| GPT-4o | 95%+ 准确率（128K） |
| Claude 3.7 | 99%+ 准确率（200K） |
| Gemini 1.5 Pro | 98%+ 准确率（1M） |
但这只是最基础的测试！
新评测标准（2026年）：
- 多跳推理：需要综合多个位置的信息
- 关系追踪：追踪实体在整个文档中的变化
- 隐式信息：信息隐藏在代码/表格/图表中
常见问题
Q1：上下文窗口越大越好吗？
不是，需要权衡：
| 因素 | 短上下文 | 长上下文 |
|---|---|---|
| 成本 | 低 | 高 |
| 延迟 | 快 | 慢 |
| 准确性 | 可能遗漏 | 全面 |
| 适用场景 | 简单任务 | 复杂分析 |
建议：能用短上下文解决就不用长上下文
Q2：如何选择合适的chunk size？
# 经验法则
chunk_size = min(
模型最大上下文 / 4, # 不超过1/4
10000, # 最大1万tokens
目标段落长度的2倍 # 确保完整语义
)
# 重叠度
chunk_overlap = chunk_size * 0.1 # 10%重叠
Q3：长上下文会遗忘信息吗？
会，这是著名的"lost in the middle"问题：
解决方案：
1. 结构化文档
└─ 用标题分隔，每个chunk保留层级信息
2. 增强检索
└─ 用向量搜索找到关键段落，单独处理
3. 分层处理
└─ 先对各段摘要，再整体分析
总结
Long Context的核心价值：
- 让AI从"看摘要"到"读全文"
- 支持整本书、代码库、长对话分析
- 2026年主流：128K-2M tokens
- Gemini 2.0达到10M tokens里程碑
技术支撑：
- 稀疏注意力：减少无效计算
- 滑动窗口：局部高效计算
- KV Cache：避免重复计算
- PagedAttention：显存优化
使用建议：
- 能用短就不用长
- 用检索增强，不要全量上传
- 注意成本和延迟的权衡
延伸阅读
| 相关文章 | 说明 |
|---|---|
| W19 KV Cache | 推理加速技术 |
| W03 RAG | 检索增强生成 |
| W07 上下文窗口 | 上下文窗口基础 |
本文收录于「AI词汇专栏」
相关阅读：W03 RAG · W19 KV Cache
AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念，把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起，为开发者提供从开发、训练到部署的一站式体验。
更多推荐
6
0- 0
已为社区贡献69条内容
所有评论(0)