LLM长上下文

LLM发展各阶段的关键技术

  • 发展初期Chatbots

    • 实现简单聊天
    • 预训练 + 提示词工程

  • 发展中期RAG

    • 知识库降低幻觉
    • 检索内容 + 系统提示词

  • 当前阶段Agent

    • “智能体元年”
    • 工具 + 记忆 + 多轮交互

长上下文处理的目标

  • 窗口长度限制

    • 物理截断 —— 硬截断导致尾部丢弃
    • 语义碎片化 —— chunk影响指代消解
    • 多轮记忆断裂 —— 系统设定遗忘
    • 推理链断裂 —— CoT逻辑跳步 ———— 推理窗口长度扩张，让模型“一眼看完”整个世界

  • 上下文衰减

    • 中间迷失 —— 模型注意力呈U型分布
    • 抗干扰能力弱 —— 干扰信息影响加剧
    • 有效利用率低 —— 无效计算导致高昂成本 ———— 上下文信息记忆力增强，不仅要长，还要长得记得住

用长度换冗余，用冗余抗遗忘。本质上是在承认模型记忆能力有限的前提下，通过精心设计的输入结构（更长 + 更重复/更结构化）来弥补其内在缺陷，让长上下文真正“可用”而不仅是“能装”。

  • “冗余”的含义：
    • 不是无意义的重复，而是有目的的信息备份（如摘要、锚点、关键句复述）；
    • 或者是结构化组织（如章节标题、时间戳、角色标签），帮助模型定位和关联信息。

长上下文处理的技术路线

长上下文处理方法

  • 模型内策略
    • （架构/训练层面）—— 修改模型本身，使其原生支持长上下文
      • 位置编码
        • 嵌入相对位置，实现长度外推
      • 注意力机制
        • 改进标准机制，优化计算性能
  • 模型外策略
    • （系统/工程层面）—— 通过外部工作流和技巧，让模型间接处理长上下文
      • 上下文工程
        • 引入外部控制，聚焦内容管理

备注

embedding模型

这意味着词汇表中的每一个词（或子词单元，如 BPE 或 WordPiece）都会被映射为一个长度为 512 的实数向量。这个向量捕捉了该词的语义、语法甚至上下文信息（取决于模型类型）。例如：
“猫” → [0.23, -1.45, 0.67, ..., 0.89]（共512个数字）
“狗” → [0.25, -1.40, 0.65, ..., 0.87]
这些向量通常在训练过程中通过大量文本数据学习得到，使得语义相近的词在向量空间中距离较近。
  • 维度越高 → 向量能表示更丰富的语义信息
  • 512 是一个经验上“足够好”的平衡点

LLM 长上下文技术路线

位置编码

位置编码方法选型对比：

特性RoPEYaRNDCA
核心思想相对位置编码：通过旋转操作赋予每个位置独特的方向标签使模型关注相对距离。智能缩放：对RoPE的频率进行非均匀缩放（低频多缩，高頻少缩），平衡长短距离感知。分块处理：将长序列切成块，分别计算块内和块间的注意力，大幅降低计算复杂度。
技术重点相对位置编码，复数空间旋转温度调节，渐进式扩展，注意力权重修正距离感知频率调整，动态注意力偏置
外推/压缩能力基础但有限
直接外推时，相对位置差在训练范围内时有效；过长序列会导致“旋转标签”过快旋转而失效，模型难以理解远距离关系。		非常强大
通过微调可轻松将上下文窗口扩展4倍甚至更高（如从32K到128K），同时能保持短文本性能。		面向极致长度
旨在高效处理数十万至上百万token的超长文本。
适用场景* 短文本性能优秀，长文本性能下降明显
•当前主流 LLM 的标配位置编码方式		* 短文本性能基本保持，长文本性能优秀
* 主要在 Qwen 系列模型上默认适配		* 局部和全局注意力平衡良好
* 适用于超长文本

注意力机制

标准注意力机制的性能瓶颈

  • 标准 Transformer 的自注意力机制计算所有 token 对之间的相关性
    • 显存需求爆炸（KV Cache 和注意力矩阵占用数百 GB 显存（序列长度128K 或 160K））
    • 计算冗余严重（长文本中大量 token对语义无关。计算复杂度O(n²)
    • 推理延迟高（难以满足实时交互或批量处理需求）
    • 性能上限制模型能处理的上下文长度，使其难以应用于长文档、长对话场景

备注：

KV Cache（Key-Value Cache）是现代大语言模型（LLM）推理过程中用于加速自回归生成的关键优化技术。它的核心思想是：避免在每一步生成新 token 时重复计算之前所有 token 的 Key 和 Value 向量。

注意力性能瓶颈解决方案

在原有架构上“做减法” —— 稀疏注意力

  • 改变“全连接”模式，让每个token只关注序列中一部分关键token O(n²) -> O(n*k)
  • 应用典型：Longformer, DeepSeek DSA

底层架构革新 —— 线性复杂度架构

  • 采用状态空间模型（SSM）模型结构替代 Transformer O(n²) -> O(n) (随着输入序列变长，SSM的效率比 Transformer 更高)
  • 应用典型：Mamba, RWKV, RetNet

注意力方法选型对比

方案核心机制计算复杂度优势适用场景
稀疏注意力在注意力矩阵中引入稀疏模式（局部+全局）O(n*k)* 兼容Transformer生态
* 微调成本低		需要较好兼容性、长文档理解
线性复杂度架构状态空间模型等全新机制O(n)* 极致推理速度
* 长序列扩展潜力大		超高吞吐、实时生成、极长序列
混合架构注意力层与线性层混合O(n)~O(n²)* 平衡性能与效率
* 实用性强		兼顾性能与资源约束的通用任务

在关键位置保留注意力机制的强大表现力，同时在其余部分利用线性层的效率优势，实现性能与效率的平衡

上下文工程

总体目标：策略性地将正确的信息，在正确的时机，以正确的格式填入模型有限的上下文窗口

关键策略

上下文选择

  • 避免提供所有的可用上下文
  • 在有限的上下文窗口内实现信息密度的最大化
  • 常见方法：RAG、结构化输出

上下文压缩

  • 对消息历史进行摘要或压缩，避免超出上下文窗口的容量
  • 常见方法：LLM生成摘要、长期记忆转移、MinHash去重

上下文排序

  • 若重解决中间信息丢失问题
  • 将关键指令置于开头，将最新或最相关的数据放在末尾

上下文隔离

  • 将复杂问题拆分给多个专用智能体处理
  • 每个智能体专注维护自身的上下文窗口，避免干扰，提升系统运行性能

上下文压缩

通过 token 级或外部记忆插件模块压缩上下文信息

  • token级学习

    • 保持上下文窗口大小恒定，训练模型从上下文中提取关键信息
    • 关键技术：强化学习
    • 典型实现：MEM1、MemAgent、SWE Agent

  • 外部记忆模块

    • 使用外部模型或插件进行上下文的摘要生成
    • 关键技术：提示词工程
    • 典型实现：Claude Code、Gemini CLI、Cursor

外部记忆模块实现上下文压缩

以 Claude Code 实现为例：

核心机制：多层次记忆存储

上下文管理：由短期、中期和长期记忆协同工作的三层式（3-Tier）架构

短期记忆层

  • 存储最近的、未经处理的对话消息 实时访问

  • 利用简单消息队列实现，保证 O(1) 访问效率 自动Token统计

  • 核心机制：反向遍历（从最新到最旧的顺序回溯历史消息）

    ↓ 92%阈值触发

中期记忆层

  • 调用专门的压缩 LLM，提炼上下文摘要 智能压缩

  • 8段式结构化摘要组织 上下文连续

    ↓ 持久化存储

长期记忆层

  • 存储经过中期记忆提炼后具有长期价值的信息， 跨会话恢复 比如用户偏好、项目配置、通用解决方案等 用户定制
  • 以 .md 文件存储，支持向量检索 项目持续记忆

token级学习实现上下文压缩

特性维度MEM1MemAgentClaude CodeGemini CLI
开发组织MIT & 新加坡国立大学字节跳动 Seed 团队 & 清华大学SIA-LabAnthropicGoogle
核心思想使智能体学会如何记忆长文本分段处理，在固定大小的记忆库中迭代提取关键信息，最终仅基于最终记忆回答问题极限压榨上下文，追求单窗口内的极致性能用压缩换掉换取压缩质量和系统稳定
压缩触发机制持续自主压缩覆盖式压缩92% 阈值触发（渐进压缩）70% 阈值触发（保守压缩）支持用户主动触发压缩
压缩存储形式动态内部状态高度抽象和精简的历史信息固定上下文窗口内的文本token序列结构化摘要（八段式）结构化摘要（段式）
技术实现端到端强化学习（RL）奖励驱动模型学会记忆多轮对话强化学习最轻答案奖励+中间步骤专用压缩模型（J7）+ 规则管理精选历史提取 + 规则管理（五段式摘要）
上下文窗口内存储近似恒定（O(1)），不随交互轮次增加而增长近似恒定（O(1)），理论上可线性增长但有文本限制线性增长（O(N)），直至触发压缩线性增长（O(N)），直至触发压缩
优点- 对长篇任务序列的处理效率高；内存占用低；泛化能力强- 卓越的长篇外推性；结构计算复杂度低；泛化能力强- 摘要高度结构化；单个上下文窗口内能力强大；引入文件恢复- 开源免费；与开发环境集成度高；压缩对于用户体验的影响较小（无感知压缩、连续性好、透明反馈）
缺点- 训练复杂；存在关键信息丢失的风险- 推理延迟较高；训练复杂度高；中间信息丢失风险- 未开源，依赖定制工程；依赖压缩模型能力- 频繁压缩可能影响对话连贯性；未引入文件历史恢复和压缩K线，可能导致失真或信息偏差；依赖压缩模型能力
最近更新:
Contributors: klc407073648