DeepSeek V4 的 Engram：改变长上下文 AI 的记忆系统
DeepSeek V4 引入了一个名为 Engram 的全新架构组件——一种条件记忆系统，旨在解决长上下文 AI 中最棘手的问题：模型在技术上接受百万 token，却无法可靠地检索其中的内容。
V4 Lite 已正式上线，完整版 V4 即将发布。本文将介绍 Engram 的实际工作原理，以及它对开发者意味着什么。
Engram 解决的问题
标准 Transformer 注意力机制在大规模场景下表现并不稳定。在 128K token 时，召回质量尚可接受；但在 100 万 token 时，一项被广泛引用的研究表明，"大海捞针"（Needle-in-a-Haystack）准确率下降至约 84%——也就是说，埋藏在百万 token 上下文中的特定信息，大约每六条就会有一条被遗漏。
这带来了一个实际问题：如果你将整个代码库或文档库传递给拥有 100 万 token 上下文窗口的模型，你无法可靠地相信模型找到了所有相关内容。长上下文窗口确实存在，但检索质量并不可靠。
DeepSeek 的答案就是 Engram。
Engram 的工作原理
DeepSeek 架构文档将 Engram 描述为一种条件记忆机制，它基于相关性信号有选择地存储和检索信息，而非单纯依赖对完整 token 序列的注意力计算。
Engram 并不对百万 token 上下文中的每个 token 进行全量注意力计算，而是识别出哪些上下文片段可能与当前查询相关，并据此路由检索过程。根据 DeepSeek 内部基准测试结果：
| 指标 | 标准注意力 | Engram（V4） |
|---|---|---|
| 大海捞针 @ 100 万 token | 84.2% | 97% |
12.8 个百分点的提升并非四舍五入的误差。在实践中，这意味着一个能够处理长文档的模型与一个可靠到足以替代昂贵的分块检索流水线的模型之间的本质差异。
对 RAG 和长文档工作流的意义
对于基于检索增强生成（RAG）构建应用的开发者而言，Engram 显著改变了原有的取舍逻辑：
Engram 之前： 长文档需要分块、嵌入和向量检索——这是一条拥有独立故障模式和维护开销的多组件流水线。
有了 Engram： 如果 DeepSeek 97% 准确率的说法能通过独立评估的验证，那么将完整文档（或中等规模的代码库）直接传入上下文将成为可行方案，无需独立的检索层。
这并不意味着 RAG 在所有场景下都会被淘汰。对于超过 100 万 token 的数据集，或对延迟敏感的应用（全量上下文加载不切实际），向量检索仍是正确的架构选择。但对于常见的文档分析、合同审查或代码库级别的代码审查任务，Engram 让全上下文方案首次具有了真正的可信度。
注意：基准测试来自内部
DeepSeek 的 97% 大海捞针结果来自内部基准测试，而非第三方评估。目前，独立机构尚未发布 V4 长上下文检索质量的测试结果。
这一点很重要。内部基准数据在历史上往往高估实际表现，尤其是在检索任务上——评估设置可能被优化以产生有利结果。
稳妥的做法是：将 97% 视为待验证的目标，而非已确认的技术规格。一旦 V4 权重发布并启动独立评估（预计发布后 48 小时内），真实的检索数据将会浮出水面。
Engram 与竞品对比
DeepSeek 并非唯一专注于长上下文检索质量的实验室。Anthropic 通过优化 Claude 架构中的注意力模式来解决这一问题；Google 的 Gemini 3.1 Pro 则采用不同的方法来保持 100 万 token 时的检索质量。
Engram 的与众不同之处在于：它在架构层面是独立的——作为单独组件存在，而非对标准注意力的优化——且其在 100 万 token 上声称的性能差距大于竞争对手已公布的数据。
如果独立基准测试证实了 97% 的数字，Engram 将代表一次有实质意义的进步。如果未能证实，它仍是一个颇具潜力的研究方向，实现细节有待进一步完善。
何时可以期待独立验证
DeepSeek V4 完整权重预计本周发布。发布后 24–48 小时内，可期待来自 LMSYS、BigCode 及更广泛开源社区的基准测试结果。
对于正在评估 V4 长上下文应用场景的开发者而言，在做出架构决策之前，这些数据才是真正值得等待的。
→ DeepSeek V4 完整开发者指南
→ DeepSeek V4 发布日期：我们已知的一切
→ AnyCap AI Agent 工作流