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

张开发
2026/4/18 19:11:53 15 分钟阅读

分享文章

【词汇专栏】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,0001,000,000 次可接受N 10,000100,000,000 次有点慢N 100,00010,000,000,000 次爆炸N 1,000,0001,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 Sonnet200K tokens原生支持精准召回Gemini 1.5 Pro2M tokens200K → 1M → 2M演进GPT-4o128K tokens原生支持DeepSeek-V3128K tokens64K专家 动态路由Qwen2.51M tokens开源最强GLM-4128K tokens中文优化实际应用场景1. 文档分析与问答# 典型应用基于长文档的问答documentload_pdf(年度财务报告.pdf)# 500页~200K tokenspromptf 请分析以下文档回答问题。 文档内容{_document}问题 1. 公司去年的营收增长是多少 2. 主要风险因素有哪些 3. 未来战略规划是什么 # 传统模型无法处理需要先摘要# 长上下文模型直接全文分析responsemodel.generate(prompt)2. 代码库理解场景问这个函数被哪些地方调用代码库规模100万行代码方案步骤结果短上下文1. 用语义搜索找到函数定义遗漏远处的调用2. 在附近几页代码中搜索调用长上下文1. 将整个代码库加载到上下文准确找到所有调用点2. 模型直接分析调用关系图3. 准确找到所有调用点3. 多文档比较场景比较10份竞品分析报告找出差异点 传统做法 - 一份一份读逐一对比 - 容易遗忘信息碎片化 长上下文做法 - 10份报告一起读 - 直接输出对比分析 - 不会遗漏任何信息代码示例使用LangChain处理长文档fromlangchain_community.document_loadersimportPyPDFLoaderfromlangchain.text_splitterimportRecursiveCharacterTextSplitterfromlangchain_community.vectorstoresimportChromafromlangchain_openaiimportOpenAIEmbeddingsfromlangchain.chainsimportRetrievalQA# 1. 加载PDF500页loaderPyPDFLoader(annual_report.pdf)documentsloader.load()# 2. 切分文档保留重叠保证上下文连续性splitterRecursiveCharacterTextSplitter(chunk_size4000,# 4K tokenschunk_overlap500,# 500 tokens重叠length_functionlen,)chunkssplitter.split_documents(documents)# 3. 存入向量数据库embeddingsOpenAIEmbeddings()vectorstoreChroma.from_documents(chunks,embeddings)# 4. 检索增强生成RAGqa_chainRetrievalQA.from_chain_type(llmmodel,retrievervectorstore.as_retriever(search_kwargs{k:5}),)# 5. 问答resultqa_chain.invoke({query:公司去年营收增长了多少})配合Long Context APIfromanthropicimportAnthropic clientAnthropic()# Claude 3.7支持200K上下文responseclient.messages.create(modelclaude-sonnet-4-20250514,max_tokens4096,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.384128倍 解决方案 1. 只上传必要的内容 2. 使用压缩技术如LLMlingua 3. 检索增强不要全量上传挑战3KV Cache显存128K tokens的KV Cache有多大 以半精度(FP16)计算 - 32层 × 隐藏维度12896 × 2字节 × 128K × 2(KV) ≈ 200GB显存 解决方案 - PagedAttentionvLLM - ChunkKV压缩 - 量化到INT8/INT42026年最新进展Gemini 2.0 Flash长上下文2026年最新突破 ├─ 上下文窗口10M tokens1000万 ├─ 可处理4小时的视频 音频 文本 ├─ 技术动态稀疏注意力 金字塔检索 └─ 价格相比Gemini 1.5降低80%Long Context Model的新评测标准传统评测大海捞针Needle in Haystack把一个秘密藏在100K tokens中让模型找出来模型Needle in Haystack结果GPT-4o95% 准确率128KClaude 3.799% 准确率200KGemini 1.5 Pro98% 准确率1M但这只是最基础的测试新评测标准2026年多跳推理需要综合多个位置的信息关系追踪追踪实体在整个文档中的变化隐式信息信息隐藏在代码/表格/图表中常见问题Q1上下文窗口越大越好吗不是需要权衡因素短上下文长上下文成本低高延迟快慢准确性可能遗漏全面适用场景简单任务复杂分析建议能用短上下文解决就不用长上下文Q2如何选择合适的chunk size# 经验法则chunk_sizemin(模型最大上下文/4,# 不超过1/410000,# 最大1万tokens目标段落长度的2倍# 确保完整语义)# 重叠度chunk_overlapchunk_size*0.1# 10%重叠Q3长上下文会遗忘信息吗会这是著名的lost in the middle问题解决方案 1. 结构化文档 └─ 用标题分隔每个chunk保留层级信息 2. 增强检索 └─ 用向量搜索找到关键段落单独处理 3. 分层处理 └─ 先对各段摘要再整体分析总结Long Context的核心价值让AI从看摘要到读全文支持整本书、代码库、长对话分析2026年主流128K-2M tokensGemini 2.0达到10M tokens里程碑技术支撑稀疏注意力减少无效计算滑动窗口局部高效计算KV Cache避免重复计算PagedAttention显存优化使用建议能用短就不用长用检索增强不要全量上传注意成本和延迟的权衡延伸阅读相关文章说明W19 KV Cache推理加速技术W03 RAG检索增强生成W07 上下文窗口上下文窗口基础本文收录于「AI词汇专栏」相关阅读W03 RAG · W19 KV Cache

更多文章