当AI拥有“超长记忆”：DeepMind科学家畅谈千万级上下文的现在与未来

发表于 分类于

为对大模型上下文窗口这个技术方向感兴趣的朋友们推荐一下这期来自Google AI的播客：来自DeepMind的Nikolay Savinov与主持人Logan Kilpatrick的这期访谈干货满满，不仅探讨了将上下文窗口扩展至百万乃至千万级别的前沿进展，还深入分析了长上下文与检索增强生成（RAG）的协同关系以及未来的发展方向。

我将访谈中印象深刻的几个核心观点以及针对开发者的实用建议整理如下：

核心洞察总结

  1. 千万级（10M）上下文窗口？快了，而且会成为“标配”：Nikolay提到，在Gemini 1.5 Pro的研发过程中，技术上已经能够实现1000万token的上下文长度，只是当时推理成本过高，未能立即向公众开放。他预测，不久的将来，千万级别的上下文窗口将成为常态化、商品化的能力；
    • 这意味着什么？ AI助手能一口气读完你上传的几百页PDF文档，或者看完一部长电影，然后精准回答你的任何问题；
    • 对AI编程领域产生颠覆性影响？ 一旦千万级上下文成为标配，这几乎是为AI编码助手解锁了“上帝视角”。因为开发者将能够把大型项目的整个代码库都“喂”给AI，AI就能在全局视野下进行理解、重构和生成代码，效率和能力都将是前所未有的；
  2. 长上下文 vs. RAG：相爱相杀还是相辅相成？ 长上下文火了之后，很多人问：RAG（检索增强生成）是不是就要“凉了”？Nikolay明确表示：并不会：
    • RAG的“历史使命”未完： 首先，知识库的规模总是可能比上下文窗口更大（比如企业级的海量知识库，动辄数十亿token）。其次，延迟也是一个需要考虑的因素；
    • 强强联合，1+1 > 2： 更重要的是，RAG和长上下文其实是“天作之合”。长上下文可以帮助RAG系统一次性处理更多检索回来的信息片段，从而提升召回信息的“密度”和处理复杂需求的能力 - RAG负责从汪洋大海般的知识库中捞取“珍珠”（相关信息）；而长上下文模型凭借其一次能容纳并审视更多“珍珠”的独特优势，更擅长将它们巧妙串联、洞悉其间的复杂联系，从而给出更精准且富有洞见的答案；
  3. 长上下文 + Agents：打造更“懂你”的智能体 我们目前与AI互动的一大痛点是需要手动查找、复制粘贴并导入上下文信息，这个过程相当繁琐。Nikolay畅想，如果能构建一个“长上下文智能体系统”（long context agent system），让AI能够自动从任何地方（你的文档、邮件、浏览历史等）获取并理解你的上下文，那将极大提升AI的实用性和个性化水平 - 你就像拥有了一个能随时调取你所有相关记忆和资料的私人助理，能真正理解你的意图和需求，而无需费力解释“前情提要”；

开发者请注意：长上下文的四大“避坑”与“增效”指南

  1. 推荐多用依赖“上下文缓存”（Context Caching）
    • 工作原理与好处： 虽然首次向模型提供长上下文并提问时，确实会耗时更长、成本更高。但如果你基于相同的上下文问第二个、第三个问题，就可以利用上下文缓存机制，让后续的回答变得又快又便宜；
    • 适用场景： 文档问答、数据分析、代码库聊天等；
    • 关键要求： 你提供的原始上下文必须保持一致。如果每次请求的输入上下文都在变，缓存效果会大打折扣。不过，如果变化只发生在上下文的末尾（比如新增对话），系统通常能智能地找到匹配的缓存前缀，只处理变化部分；
    • 提问的“正确姿势”： 为了充分利用缓存带来的成本和速度优势，你应该将你的问题（prompt）放在上下文的末尾；
  2. 与RAG（检索增强生成）珠联璧合
    • 这点在前面已经强调过，即使上下文窗口再大，对于需要处理海量外部知识（数十亿token级别）或需要从多个分散信息点进行推理的场景，RAG依然是你的得力助手。长上下文让RAG检索回来的更多“珍珠”有了用武之地；
  3. 别拿无关上下文“考验”模型
    • 原因与建议： 虽然长上下文模型能处理大量信息，但用完全不相关的内容去填充上下文窗口，不仅会影响模型在多个信息点之间进行检索和推理的性能（即“多针检索”能力），也会增加不必要的成本 - 如果你明知某些信息是“噪音”，就别让它干扰模型的“注意力”了；
    • 未来展望： 当然，随着模型质量的提升和成本的下降，未来开发者可能不再需要如此精细地手动过滤不相关信息。但在现阶段，这绝对是一个值得考虑的实用建议；
  4. 巧妙运用提示（Prompting）化解“记忆冲突”
    • 背景知识： 模型拥有两种记忆：一种是通过预训练获得的“内在记忆”（in-weight memory），比如常识性知识；另一种是你通过上下文明确提供的“情境记忆”（in-context memory）。这两种记忆有时可能会发生矛盾（比如模型的旧知识与你提供的新信息相悖）；
    • 实操方法： 通过在提示中明确指示模型应该依赖哪种信息来解决这种模糊性。例如，使用类似“根据以上提供的文档…”或“基于上述信息…”这样的措辞，可以引导模型优先采信你提供的上下文信息，而不是它自己“脑补”的旧知识；

更多值得挖掘的“宝藏”观点

除了上述核心内容，访谈中还有一些有趣的细节和观点：

  • “大海捞针”的极限： 当前，在简单场景下（比如从一堆无关紧要的文本中找一句特定的话，即“单针检索”），长上下文模型已经做得相当不错了。但真正的挑战在于处理“硬性干扰项”（hard distractors，即很多看起来相似的“针”）和同时检索并理解“多根针”；
  • 长上下文与推理能力的奇妙化学反应： Nikolay认为，强大的长上下文能力对提升模型的推理能力至关重要。因为复杂的推理往往需要模型生成一个“思考链条”（thinking trace），而这个链条本身就需要较长的输出来承载，同时也需要模型能回溯和利用这个链条中的信息；
  • 长输入与长输出： 从技术角度看，长输入和长输出并非根本不同。模型在预训练后本就具备生成长序列的潜力。关键在于后续的指令微调（SFT）和对齐过程，如何引导模型在需要时生成长内容，而不是过早地输出“结束符”；
  • 未来的展望：
    • 第一步： 当前百万级上下文的“质量”将大幅提升，在检索类任务上达到近乎完美；
    • 第二步： 成本将显著下降，千万级上下文窗口成为常态；
    • 更远的未来： 随着深度学习的更多创新，我们甚至可能看到亿级（100M）上下文的出现。当然，这一切将离不开强大的推理工程团队的支持；

写在最后

如果你对长上下文这个话题感兴趣，强烈推荐去听一下这期播客的全文 - https://www.youtube.com/watch?v=NHMJ9mqKeMQ