Gemini 2.5 Pro 负责人最新访谈：大海捞针做测评已经过时了 | 全文

百万级别的长上下文一直是 Gemini 系列相较于其他头部大模型的领先优势之一。

尤其是最近正式推出的 Gemini 2.5 Pro 模型，在 AI Coding 的实践中，能够直接对整个项目进行遍历和读取，与其他模型相比，带来的是完全不同的体验。

更长的上下文，带来的是可能产品交互的革新和完全不一样的应用落地场景。

长上下文当前的痛点，以及未来发展方向是什么？

谷歌 DeepMind 长上下文预训练联合负责人Nikolay Savinov 给出了两点预测：一是在当前百万级 token Context 模型质量还没有达到完美之前，盲目地追求更大规模地长上下文意义不大；二是随着成本下降，千万级别的 token Context 很快会成为标准配置，对于编码等应用场景来说将是革命性的突破。

在近期谷歌的一档播客中，谷歌 DeepMind 资深研究科学家、长上下文预训练联合负责人Nikolay Savinov 与主持人 Logan Kilpatrick 对谈，分享了Gemini 2.5 长上下文技术的核心、与 RAG 之间的关系、当前的研究瓶颈、以及未来的发展方向等。

对于开发者来说，强烈推荐一读。

TLDR: 

• 在当前百万 token 上下文远还没有达到完美之前，盲目追求更大规模的长上下文意义不大。

• 理解 in-weights memory 和 in-context memory 这两者之间的区别非常重要，in-context memory 更容易修改和更新。当前的瓶颈在于，对于短上下文模型来说，提供的额外上下文有限，不同的信息源之间为获得模型「注意力」会存在竞争；

• 长上下文不会取代 RAG，两者之间是协同关系，RAG 负责从海量信息中粗筛，长上下文负责精细处理。真正的限制因素在于应用程序的延迟要求，当需要实时交互时，必须使用较短的上下文；当等待时间更长时，使用长上下文更好，因为能带来更高的召回率。

• 从理论上讲，具备强大长上下文能力的模型，也应该在推理方面表现出色。

• 有的开发者会问：我们应该把问题放在上下文的前面还是后面？答案是：应该放在后面。因为如果你想利用缓存来节省成本，这才是正确的位置。如果你把问题放在开头，那么每次请求都会导致缓存失效，需要从头开始处理。

• 不要将长上下文当成「数据垃圾桶」，不相关的信息会降低模型表现。不相关或强干扰信息会与目标信息竞争模型的「注意力」，尤其在多关键信息检索任务中，反而会降低性能。现阶段，精选上下文依然重要。

• 未来，千万级别的 token 上下文很快会成为标准配置，对于编码等应用场景将是革命性的突破。

主持人：如何理解上下文窗口？作为使用大语言模型产品的用户，或者是使用 AI 模型进行开发的人，为什么需要关注上下文窗口？

Nikolay：上下文窗口基本上就是我们输入到大型语言模型中的那些上下文 token。它可以是当前的提示（prompt），也可以是之前与用户的交互内容，还可以是用户上传的文件，比如视频或 PDF 文件。

当你向模型提供上下文时，模型实际上有两个知识来源。一个来源是「权重内记忆（in-weights memory）」或「预训练记忆」。这是大型语言模型在对一部分互联网内容进行训练时学到的知识，它不需要额外的上下文知识就能记住一些事实。所以即使没有上下文，模型中也已经存在某种记忆。

但另一种记忆是你提供给模型的这种显式的上下文内记忆（in-context memory）。理解这两者之间的区别非常重要，因为上下文内记忆比权重内记忆更容易修改和更新。

所以对于某些类型的知识来说，权重内记忆可能就足够了。比如，如果你需要记住一些简单的事实，像物体是往下掉而不是往上飞，这是一种非常基本的常识。如果这个知识来自预训练，那也没问题。但有些事实在预训练时是正确的，但在推理时就过时了。你需要以某种方式更新这些事实。而上下文为你提供了一种实现这种更新的机制。这不仅仅是关于最新的知识，还有不同类型的知识，比如私人信息。比如，网络对你个人一无所知，它也无法读懂你的心思。

所以如果你希望模型对你真正有帮助，你应该能够将你的私人信息输入到上下文中，然后模型就能实现个性化。如果没有这种个性化，模型就会给你一个它会给任何人类的通用答案，而不是为你量身定制的答案。

最后一类需要插入到上下文中的知识是一些罕见的事实。所以基本上就是在互联网上很少出现的一些知识。我怀疑这类知识随着时间的推移可能会消失。也许未来的模型能够把整个互联网的内容都牢记于心，那样我们就不需要担心这些了。

但目前的现实是，如果某件事情在整个互联网上只被提到一两次，模型实际上不太可能记住这些事实，并且它们会编造答案（产生幻觉）。所以你可能需要把这些信息显式地插入到上下文中。我们面临的一种权衡是，对于短上下文模型来说，你提供额外上下文的能力有限。基本上，知识来源之间会存在竞争。如果上下文非常大，那么你在插入内容时就可以不那么挑剔，并且可以更高程度地召回和覆盖相关知识。

如果你在上下文中有更高的覆盖率，这意味着你将缓解权重内记忆带来的所有这些问题。

主持人：我们提到了「权重内」记忆和上下文内记忆，还有第三种引入上下文的方式是 RAG（检索增强生成）系统。请你介绍下 RAG。

Nikolay：RAG 是一种工程技术，它在信息被送入 LLM 上下文之前增加了一个预处理步骤。想象一下，你有一个庞大的知识库，首先将其分割成许多小的文本块。然后，使用一个特殊的嵌入模型，将每个文本块转换成一个实值向量。当用户提出查询时，这个查询也会被嵌入为向量。接着，系统会将查询向量与知识库中所有文本块的向量进行比较，找出最接近的文本块，并认为这些是相关内容。最后，LLM 会基于这个包含了相关信息的上下文来生成回答。这就是 RAG 的基本工作原理。

主持人：现在有的的模型上下文已经能达到百万甚至两百万 token，这虽然很长，但与维基百科等动辄数十亿 token 的信息库相比仍显不足。RAG 正是用于在这种海量信息中检索相关上下文的。

为什么不直接将这种检索能力内置于模型中，让模型能够直接处理数十亿 token 的上下文，自行找到所需信息呢？这不是一个更便捷的方案吗？是这个研究方向本身存在问题，还是说这本就不该是模型的工作？

Nikolay：在我们发布 1.5 Pro 后，社交媒体上涌现了许多关于 RAG 是否会过时的讨论。我的看法是，RAG 不会过时。以企业知识库为例，信息量往往能达到数十亿 token，远超百万级别。对于这种规模的应用，RAG 依然是必需的。因此，我认为在实际应用中，RAG 不会迅速被淘汰，而是会与长上下文来协同工作。长上下文对 RAG 的好处在于，它允许 RAG 检索并容纳更多可能相关的文本片段，从而提高有用信息的召回率。如果过去为了确保相关性，设定了非常严格的筛选阈值，排除了许多潜在有用的信息，现在有了长上下文，就可以放宽标准，纳入更多事实。我认为这两者之间存在着非常好的协同效应。真正的限制因素在于应用程序的延迟要求。如果需要实时交互，就必须使用较短的上下文；但如果可以接受稍长的等待时间，那么长上下文无疑是更好的选择，因为它能带来更高的召回率。

在我刚开始从事长上下文研究时，竞争对手的水平大约在 12.8 万（128k）或 20 万 token。当时，这个项目只是谷歌 Gemini 大项目中的一小部分。我最初的想法是，仅追平竞争对手的水平远远不够，不如设定一个宏伟的目标。100 万 token，听起来是一个足够有挑战性的进步。相较于 20 万 token，这几乎是 5 倍的提升。在我们发布了百万级 token 模型后，又推出了两百万 token 的版本，再次扩大了规模，这比当时最先进的水平高出了一个数量级。这是一个很好的目标，也激发了团队的研发热情。

主持人：为什么更强的推理能力能让长上下文发挥更大的作用，这是自然而然的结果吗？是因为模型「思考」得更久，还是两者之间存在更深层次的联系？

Nikolay：我认为推理和长上下文之间存在着更深层次的联系。当增加上下文长度能改善下一个 token 的预测任务时，我们可以从两个角度理解。第一，向输入端加载更多上下文，可以提升对简短答案的预测准确性。第二，由于输出的 token 与输入的 token 在形式上是相似的，如果我们允许模型将自己的输出再反馈回输入端，那么输出在某种意义上就转化为了新的输入。从理论上讲，具备强大长上下文能力的模型，也应该在推理方面表现出色。

此外，长上下文对推理至关重要。以决策任务为例，即便答案在二选一的情况下只需要生成一个 token，先生成完整的推理过程往往能得到更好的结果。因为从模型架构角度，在进行下一个 token 预测时，如果需要在上下文中进行多次逻辑推导，会受到「网络深度」的限制。「网络深度」类似于注意力层的数量，限制了模型在一次前向传播中逻辑跳跃的次数。但如果能将输出反馈回输入，模型就突破了这一限制，相当于拥有了可供写入的「记忆」，从而能够处理比单纯依赖网络深度时更复杂的任务。

主持人：你怎么看 Agent 应用场景和长上下文的关系？长上下文是实现优质 Agent 体验的关键因素吗？二者相互作用是怎样的？

Nikolay：这确实是个有趣的问题。我觉得 Agent 既能作为长上下文的使用者，也能充当长上下文的提供者。Agent 要想高效运行，就得追踪上一个状态，比如之前采取过的行动、进行过的观察等，当然还有当前的状态。因此，为了记住之前所有这些交互信息，就需要更长的上下文，这就是长上下文对 Agent 的助力，也就是 Agent 作为长上下文使用者的情形。

不过，还有另一个视角。实际上，Agent 也是长上下文的提供者。因为手动整理长上下文非常麻烦。举个例子，要是每次都得手动上传想要的所有文档，或者上传一个视频，又或者从网上复制粘贴一些内容，这实在太繁琐，没人愿意这么做，大家都希望模型能自动完成这些操作。而实现这一点的一种方式就是通过 Agent 的工具调用。所以，如果模型能在某个时刻做出判断：「嘿，现在我要获取更多信息了」，然后它就能自行整理上下文。从这个层面来讲，Agent 就是长上下文的提供者。

主持人：是的，这是个非常好的例子。我认为这实际上是人们与 AI 系统交互时的主要限制之一，就像你举的例子那样，真的很繁琐。做任何与 AI 相关的事情最糟糕的部分就是我必须去找到所有可能与模型相关的上下文，然后亲自把这些上下文输入进去。在很多情况下，这些上下文可能已经在我的屏幕上或者我的电脑里了，我知道上下文在哪里，但我却不得不做所有这些繁重的工作。所以我很期待我们应该构建一些长上下文 Agent 系统，它可以自动从各个地方获取你的上下文。我觉得那会非常有趣，而且我认为这解决了一个非常基本的问题，不仅对开发者来说是这样，从 AI 系统终端用户的角度来看也是如此。我希望模型能够自己去获取我的上下文，而不是我必须亲自去做。

Nikolay：是的，确实是这样。

主持人：我们发现开发者对长输出的需求非常强烈，而不仅仅是长输入。所以我想问，长上下文的输入能力和输出能力有多大关联？从研究角度看，这两种能力是同一回事，最终会趋于一致，还是说它们在本质上是截然不同的？

Nikolay：我认为长上下文的输入和输出能力在本质上没有不同。重要的是要理解，仅从预训练的角度看，模型在生成大量 token 方面其实没有真正的限制。例如，你输入 50 万 token，让模型执行复制任务，它是能够做到的，我们也通过实验验证了这一点。然而，这种能力在预训练之后需要被谨慎地引导。这是因为模型在后续阶段会接触到一个特殊的序列结束 token（end-of-sequence token）。如果在监督微调（SFT）阶段使用的数据都很短，模型就会频繁地在序列早期看到这个结束 token。久而久之，模型就会学到：「在 X 长度的上下文中，你总是向我展示这个 token，所以我会生成它并停止输出，这是你教给我的规则。」这其实是一个模型对齐（alignment）的问题。但我想强调的是，推理只是长输出任务的一种。例如，翻译也是一种长输出任务。推理有其独特的格式，它会将思考过程用特定的分隔符包裹起来，模型能识别出这是在让它进行链式思考。而对于翻译任务，整个输出内容都会很长。这也是我们期望模型能够具备并展现的能力。所以，这归根结底是一个如何正确校准模型的问题。我们目前也正在积极进行模型长输出方面的研究。

主持人：开发者如何更好地利用长上下文及 RAG？你对他们如何有效地利用长上下文有什么建议？

Nikolay：我的第一个建议是，尽量多地利用上下文缓存（context caching）。让我解释一下这个概念，当你首次向模型提供长上下文并提问时，处理时间会更长，成本也更高。然而，如果你在同一个上下文的基础上提出第二个问题，就可以利用上下文缓存，使后续的问答更经济、更快捷。这是我们目前为部分模型提供的功能。所以，尽量利用它，尝试缓存用户上传的文件，因为这不仅能加快处理速度，还能将平均输入成本降低到原来的约四分之一。

主持人：我来举个例子。在「与我的文档聊天」或「与 PDF 聊天」这类常见应用中，原始输入上下文是固定的，这是上下文缓存发挥作用的场景。使用上下文缓存的前提是，每次请求提供的原始上下文必须保持一致。如果输入上下文每次都在变化，缓存效果就会大打折扣。

Nikolay：是的，你说的完全正确。对于与一组固定文档聊天、针对某个长视频提问或对一个代码库进行操作等场景，上下文缓存都非常重要。你提到知识不应改变这一点也是对的。如果知识确实需要更新，最好是在上下文的末尾进行追加，因为底层实现会匹配缓存中的最长公共前缀，然后只处理新增的部分。有的开发者会问：我们应该把问题放在上下文的前面还是后面？答案是：应该放在后面。因为如果你想利用缓存来节省成本，这才是正确的位置。如果你把问题放在开头，那么每次请求都会导致缓存失效，需要从头开始处理。

主持人：这个建议非常实用。除了上下文缓存，从开发者角度看，还有其他需要注意的地方吗？

Nikolay：有一点我们之前提到过，与 RAG 的结合。如果你需要处理数十亿 token 的上下文，那么结合 RAG 是必然选择。即使上下文规模小得多，在一些需要检索多个关键信息的场景中，结合 RAG 可能仍然是有效的。另一点是，避免在上下文中包含不相关的内容，因为它会影响多关键信息的检索效果。还有一个有趣的细节，是「权重内」记忆和上下文内记忆的相互作用。如果你想利用上下文内记忆来更新「权重内」的知识，那么模型必然会同时依赖这两种知识来源，它们之间可能会产生矛盾。我认为，通过精心设计提示词来明确解决这种矛盾是很有帮助的。例如，你可以在提问时加上「基于以上提供的信息……」这样的前缀。当你这样说时，你就给了模型一个明确的信号，让它优先依赖上下文内记忆，而非「权重内」记忆，从而为模型消除了这种模糊性。

主持人：如何看待在特定知识库上进行长上下文微调，这种方法能否带来更好的通用结果？

Nikolay：我先来详细解释一下在知识库上进行微调是如何操作的。有时人们会获取额外的知识，比如一个庞大的企业知识库，像我们进行预训练一样，会在这个语料库上训练网络，通过语言建模损失函数让模型学习预测下一个 token。这种整合信息的方式虽然有效，但也存在局限。首先，因为是在训练一个网络，而不是简单地提供上下文，所以需要处理各种问题，比如调整超参数、确定停止训练的时机、以及应对模型过拟合等情况。尽管这种微调技术在推理时速度快、成本低，因为它将知识直接编码进了模型权重，但其弊端也十分突出。有研究指出，这种「硬编码」式的知识注入方式，不仅可能加剧模型的幻觉问题，还带来了两个后续的难题：一是隐私风险，敏感信息一旦嵌入权重便难以剥离；二是更新困境，固化的知识难以修改，一旦过时，最终还是需要通过上下文来提供新信息，这便形成了一个悖论。

主持人：模型质量会随着上下文规模而变化吗？例如，token 数从 5 万增加到 10 万，再到 12.8 万，模型质量的提升是线性的，还是在不同规模下基本保持一致？是否会存在异常情况，比如在特定规模下性能下降？

Nikolay：我们内部确实做过这类评估。你的问题可能与过去观察到的一些现象有关，比如一个非常常见的「中间信息丢失效应」（lost in the middle effect）。就我们的模型而言，我们没有明显观察到这种上下文中间部分信息丢失的情况。但我们确实发现，在处理包含强干扰因素的复杂任务时，随着上下文规模的增加，模型质量会出现轻微下降。这也是我们希望改进的方向。

主持人：当我向模型的上下文窗口输入 10 万 token 的信息时，作为开发者或用户，我是否可以假设模型会关注所有上下文内容？我知道模型能准确提取单个关键信息，但会对所有 token 进行推理吗？

Nikolay：这是一个很好的问题。注意力机制存在一个固有的特点，即 token 之间存在竞争关系。如果一个 token 获得了更多的注意力，那么其他 token 获得的注意力就会相应减少。问题在于，如果上下文中存在强干扰因素，比如某个干扰项与您要查找的目标信息非常相似，它就可能吸引大量的注意力，从而导致目标信息获得的注意力减少。上下文中的 token 越多，这种竞争就越激烈。所以，模型的表现取决于干扰因素的难度和上下文的规模。

主持人：注意力机制的总量是固定的吗，能否增加？还是一个固定值（比如 1），被分散到所有 token 上，导致 token 越多，每个 token 分得的注意力就越少，且无法改变？

Nikolay：通常情况下是这样的，注意力的总量是有限的。

主持人：「大海捞针」测试是长上下文的质量评估中我们熟知的一种方法，它验证了模型在海量信息中定位具体事实的能力。除此之外，还有没有其他标准的评估方法或基准测试？

Nikolay：我认为评估是 LLM 研究的基石。尤其在大型团队中，高质量的评估能让整个团队目标一致、协同发力，这在长上下文研究中同样重要。首先，像「大海捞针」这类从大量文本中检索单个关键信息的任务，如果只是基于 Paul Graham（YC 创始人） 的某一篇文章提问「巴塞罗那的神奇数字是多少？」，现在的模型已经能很好地解决。当前研究的前沿在于处理包含强干扰因素的场景。例如，用成千上万个「某个城市的神奇数字是 y」这样的键值对填满上下文，任务难度会急剧增加，因为干扰信息与目标信息高度相似。此外，同时检索多个关键信息对大语言模型来说也是一个挑战。因此，处理强干扰和多关键信息检索是目前的研究重点。

其次，评估时还有其他需要权衡的因素。即便是加入了强干扰因素，「大海捞针」式评估在某种程度上仍是人为设计的。有人希望评估能更贴近现实应用，这个想法是正确的。但需要注意的是，一旦评估过于「现实」，它可能就无法有效衡量模型真正的长上下文处理能力。例如，在一个超大型代码库中提问，答案可能只存在于某个文件中，但任务本身却要求模型完成一系列复杂操作。这种情况下，测试的更多是模型的编码能力而非长上下文能力，这会误导研究方向，让我们最终优化了错误的重点。

最后，还有一个值得关注的方向是「检索与合成评估」。理论上，检索单个关键信息的「大海捞针」任务，用 RAG 就能解决。但我们真正应该关注的是那些需要模型整合整个上下文信息才能完成的任务，比如文本总结，RAG 在处理这类任务时就显得力不从心。但这类任务的方向虽然正确，但自动化评估充满挑战。因为像 ROUGE（大模型评估指标） 这类指标难以完全捕捉人类对质量的主观判断。所以，在优化模型时，更明智的做法是依据那些评判标准明确、反馈信号清晰的指标。

主持人：为什么文本总结任务的指标效果不佳？是因为对「好」与「坏」的总结更具主观性，缺乏标准答案，还是有其他原因导致这类应用场景难以评估？

Nikolay：是的，这类评估存在很大的不确定性，即便是人类评估员之间的一致性也相对较低。当然，这并不是说我们不应该研究或衡量总结任务，它们本身非常重要。我只是想表达，作为一名研究员，我个人更倾向于在有明确信号反馈的方向上进行优化。

主持人：如果继续将上下文扩展到百万甚至两百万 token 以上，存在哪些限制？是服务成本过高，还是支撑当前规模的模型架构在更大 token 规模下会失效？长上下文技术的前沿为什么迟迟还没有新的突破？

Nikolay：实际上，在发布 Gemini 1.5 Pro 时，我们曾在千万级别的 token 规模上进行过一些推理测试，并获得了不错的质量数据。对于在千万 token 上下文中检索单个关键信息这类任务，模型表现近乎完美。我们本来是可以发布这个模型的，但运行这种规模推理的成本非常高昂。我们当时并不确定用户是否愿意为此支付高昂的费用，所以先从一个在价格上更合理的规模起步。但你提的问题很关键，因为运行这类测试的成本非常高，所以我们没能进行大规模的验证。仅仅是启动一次服务器的成本就相当可观，除非我们准备好向大量客户开放，否则我们没有足够的芯片资源来支持。

主持人：这种现状会持续下去吗？推进长上下文研究时，模型能力的增长是否会遇到瓶颈？我们需要重大的研究突破才能进一步扩大上下文规模，还是说百万到两百万 token 已经是上限，未来的扩展只能依赖 RAG 这类在模型外部优化上下文管理的方案？

Nikolay：我们确实需要更多的创新。要实现近乎完美的千万级 token 上下文，单纯扩大规模是不够的，还需要技术上的新突破。至于 RAG 和长上下文哪种范式未来会更占主导，我认为随着时间推移，模型成本会下降，我们会尝试将更多通过 RAG 检索到的信息整合到模型上下文中。并且，由于模型质量也在提升，这样做的收益会越来越大。

主持人：你此前提到强干扰信息会分散模型注意力。从这个角度看，团队是否研究过预过滤机制？理想情况下，长上下文窗口内的数据差异越大越好。如果数据高度相似，且问题与这些数据都相关，性能反而可能下降。这个问题是否只能由开发者在应用层面解决？

Nikolay：作为一名研究员，我认为依赖过滤技巧可能并不是一个正确的方向。我们应该将更多精力投入到提升模型的质量和稳健性上。不过，从实践角度出发，一个可行的建议是：尽量避免在上下文中包含完全不相关的内容。如果明知道某些信息毫无用处，就没必要放进来，至少会增加成本。

主持人：这很有趣，某种程度上，这与人们使用长上下文的初衷相悖。网络上常见的用法是，将各种数据一股脑地丢给模型，期望它能自行筛选出有用信息。考虑到剔除无关内容的重要性，人们似乎期待模型能自带预过滤功能。毕竟，长上下文的一大卖点就是让用户无需费心筛选输入数据。那么，模型是否有可能发展成一个多模块系统，能根据用户查询自动过滤无关数据，从而简化后续处理？

Nikolay：随着时间的推移，当模型质量提升、成本降低后，就不需要为这个问题所考虑了。在现阶段，如果希望充分利用长上下文，那么从现实角度出发，最好不要引入不相关的内容。当然我也同意你的观点，如果花费大量时间手动过滤或精心挑选上下文，会非常繁琐。我认为需要在这两者之间找到一个平衡点。上下文的意义在于简化用户的工作流程，使其更加自动化，而不是增加手动操作的负担。

主持人：长上下文的长期发展方向是什么？未来三年，用户可以期待什么？

Nikolay：我来做一些预测。首先，当前百万或两百万 token 上下文的质量将大幅提升，很快我们就能在几乎所有检索任务上达到近乎完美的效果。之所以说这是第一步，是因为在当前百万 token 上下文远还没有达到完美之前，盲目追求更大规模的意义不大。我相信，一旦我们实现了近乎完美的百万 token 上下文，将会开启一些我们今天难以想象的应用场景，模型处理和关联信息的能力将得到质的飞跃。实际上，模型已经能够同时处理远超人类极限的信息量。例如，让人类在观看一小时视频后，精确回答某个细节问题（比如「视频的第几秒有人掉落了一张纸」），这是非常困难的。我认为，这种超越人类的能力会变得更加普遍，而更强的长上下文能力将解锁更多我们未曾预想过的应用。这是第一步：提升质量。

第二步，是长上下文的成本降低。这可能需要更长的时间，但一定会实现。随着成本的下降，更长的上下文也将成为可能。我认为，千万级别的 token 上下文很快会成为标准配置，对于编码等应用场景将是革命性的突破。目前百万级别的上下文仅能容纳中小型代码库，而千万 token 可以将大型项目完整地置于其中。到那时，我们将拥有能够实现对整个上下文近乎完美召回的创新技术。目前，人类程序员需要记住大量信息才能高效工作，并且不得不在不同文件间频繁切换，注意力总是有限的。而 LLM 将彻底解决这些问题，它能一次性记住所有信息，精确重现任何部分，还能真正关联不同文件之间的信息，成为极其高效的编码助手。很快就会出现超越人类能力的编码 AI 助手，将成为世界上每个程序员的新标配。这是千万 token 上下文实现时会发生的第二步。

至于达到一亿 token 上下文，那将更具挑战性。我认为最终能够实现，但不确定速度有多快，而且可能需要更多深度学习领域的根本性创新才能达成这一目标。

主持人：在推动长上下文发展的过程中，硬件的限制和算法的创新，哪个是当前更大的瓶颈？我们作为研究者，是应该等待硬件成熟，还是说算法本身就有更大的突破空间？

Nikolay：仅有芯片是不够的，还需要非常有才华的推理工程师。我们的推理团队在处理百万级 token 上下文方面取得了优异的成就，没有他们，我们根本无法向客户提供这项服务。所以，这需要在推理工程方面持续投入，我不认为这个问题会自行解决。