【词汇专栏】Long Context：长上下文——AI的超长记忆

Long Context：长上下文——AI的超长记忆

一句话理解

Long Context（长上下文）是大模型处理超长文本的能力——从几千Token到上百万Token，让AI能"读完一本书再回答"。

传统模型：上下文窗口 = 4K / 8K / 32K tokens 长上下文模型：上下文窗口 = 128K / 1M / 10M tokens （可处理整本书、全部代码库、整年聊天记录）

为什么需要长上下文？

短上下文的局限性

长上下文解决了什么

技术原理

注意力机制的挑战

标准Transformer的注意力复杂度： Attention(Q, K, V) = softmax(QK^T / √d) × V 其中 QK^T 的计算复杂度：O(N²) N = 序列长度

解决方案：优化注意力机制

主流优化技术

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)

其中 φ 是某种变换

快了10万倍！

4. KV Cache优化（见W19）

配合KV Cache： - 稀疏注意力 + KV Cache = 推理加速 - 分块管理 + PagedAttention = 支持更长序列

2026年主流模型上下文对比

实际应用场景

1. 文档分析与问答

# 典型应用：基于长文档的问答document=load_pdf("年度财务报告.pdf")# 500页，~200K tokensprompt=f""" 请分析以下文档，回答问题。 文档内容：{_document}问题： 1. 公司去年的营收增长是多少？ 2. 主要风险因素有哪些？ 3. 未来战略规划是什么？ """# 传统模型：无法处理，需要先摘要# 长上下文模型：直接全文分析response=model.generate(prompt)

2. 代码库理解

场景：问"这个函数被哪些地方调用？"

• 代码库规模：100万行代码

3. 多文档比较

场景：比较10份竞品分析报告，找出差异点 传统做法： - 一份一份读，逐一对比 - 容易遗忘，信息碎片化 长上下文做法： - 10份报告一起读 - 直接输出对比分析 - 不会遗漏任何信息

代码示例

使用LangChain处理长文档

fromlangchain_community.document_loadersimportPyPDFLoaderfromlangchain.text_splitterimportRecursiveCharacterTextSplitterfromlangchain_community.vectorstoresimportChromafromlangchain_openaiimportOpenAIEmbeddingsfromlangchain.chainsimportRetrievalQA# 1. 加载PDF（500页）loader=PyPDFLoader("annual_report.pdf")documents=loader.load()# 2. 切分文档（保留重叠，保证上下文连续性）splitter=RecursiveCharacterTextSplitter(chunk_size=4000,# 4K tokenschunk_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

fromanthropicimportAnthropic 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：信息召回率

问题：上下文太长，模型容易"迷失"在信息海洋中

中间部分 = “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中，让模型找出来

但这只是最基础的测试！

新评测标准（2026年）：

1. 多跳推理：需要综合多个位置的信息
2. 关系追踪：追踪实体在整个文档中的变化
3. 隐式信息：信息隐藏在代码/表格/图表中

常见问题

Q1：上下文窗口越大越好吗？

不是，需要权衡：

建议：能用短上下文解决就不用长上下文

Q2：如何选择合适的chunk size？

# 经验法则chunk_size=min(模型最大上下文/4,# 不超过1/410000,# 最大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：显存优化

使用建议：

• 能用短就不用长
• 用检索增强，不要全量上传
• 注意成本和延迟的权衡

延伸阅读

本文收录于「AI词汇专栏」
相关阅读：W03 RAG · W19 KV Cache