大家好，这里是最佳拍档，我是大飞。前几天，谷歌DeepMind突然发布了Gemini 2.5 Pro Preview I/O版。根据WebDev Arena Leaderboard榜单显示，这个模型成功超越claude 3.7 sonnet，一举登顶，成为编程领域的最强模型。同时，它在@LMArena ai的Coding排名中也位列第一。
谷歌的技术实力与Gemini 2.5 Pro的优势
这个成绩一方面彰显了谷歌在人工智能领域深厚的技术能力，另一方面也在于Gemini 2.5 Pro进一步强化了模型的长上下文处理。在编码场景中，程序员们经常需要处理大量的代码文件。而Gemini 2.5 Pro正是凭借着超长的上下文能力，可以快速理解整个代码库的逻辑，显著降低认知的切换成本，同时提高整体的协作效率。
另外，在长文本写作和Agent决策链等场景中，长上下文也都起到了重要的作用，可以说已经成为了Gemini系列模型最有价值的核心能力之一。
长上下文技术的深入解读
为了让大家更加深入地了解长上下文技术，谷歌邀请了DeepMind的研究科学家，同时也是长上下文预训练项目的联合负责人之一的Nikolay Savinov尼古拉·萨维诺夫，在一档播客中分享了相关话题。
Token
萨维诺夫首先介绍了一下Token。Token是大语言模型处理信息的基本单位。对于文本来说，一个Token通常略小于一个单词，它可以是一个完整的词，比如“apple”，也可以是词的一部分，比如“appl”，甚至还可以是标点符号，像逗号、句号等等。不过在图像和音频领域，Token的定义又有所不同。
虽然我们人类习惯以字符为单位来理解文本，但是大语言模型却是采用Token来处理信息的。这背后其实是有原因的。曾经有研究者尝试让模型直接在字符级别上进行生成，希望摆脱Token，但是结果发现这种方法存在一个很大的问题，那就是生成的速度会显著变慢。因为模型通常会一次生成一个Token，如果一个Token能代表一个词，那么生成速度肯定远快于逐个生成字符。所以，尽管字符级的生成可能有一些潜在好处，但是目前Token仍然是主流方式。
另外，由于分词的存在，模型看待世界的方式与我们人类有很大差异。就拿“strawberry”这个单词来说，我们人类看到它，会很自然地将它视为一个字母序列，但是对于模型而言，“strawberry”可能是两到三个单独的Token。这时，如果要求模型计算这个词中字母“r”的数量，这个任务对模型来说就相当困难了。因为模型需要把在预训练阶段从网络上某处遇到的“r”字母Token，与代表整个“strawberry”的Token关联起来，这并不是一件容易的事。
上下文窗口
接下来，萨维诺夫介绍了一下上下文窗口。上下文窗口指的是我们输入给大型语言模型的Token序列，这些Token可以包括当前的提示词、用户之前的交互历史，甚至是用户上传的文件，比如视频或PDF等等。
而模型获取知识的来源主要有两个，一个是权重内记忆in-weight memory，也叫预训练记忆；另一个是上下文内记忆in-context memory。权重内记忆是模型在预训练阶段，通过学习大量互联网数据而获得的知识。对于一些通用而且不经常变化的事实，比如物体会下落而非上升这种，模型依靠权重内记忆就足够了，不需要额外的上下文。而上下文内记忆则是用户显式提供给模型的、存在于当前上下文中的记忆。
这两者的区别非常重要。上下文内记忆远比权重内记忆更加容易修改和更新。比如说，有些知识在预训练时是正确的，但是随着时间的推移，在推理的时候可能已经过时了，这个时候就需要通过上下文来更新这些事实。
当然，上下文的作用不仅仅是更新知识，还能给模型提供它原本不知道的信息。比如说个性化的信息，模型本身是不了解用户的私人信息的，只有用户通过上下文提供这些信息，模型才能给出个性化的回答，而不是一直用千篇一律的、普适性的回答。再比如一些罕见的事实，在互联网上出现的也很少，所以模型可能记忆不牢固，容易产生幻觉，这时候把这些事实显式地放在上下文中，就能提高回答的准确性。虽然随着模型学习能力的增强，未来这类知识或许能够被模型完全记住，但是目前这仍然是一个挑战。
上下文窗口的大小也很关键，它决定了能够提供多少额外的信息。对于短上下文模型，用户在提供不同知识来源的时候就需要权衡，因为它的上下文窗口长度有限，所以可能无法提供足够多的信息。而如果上下文窗口足够大的话，用户就不必过于挑剔输入的内容，这样就能覆盖更多相关知识，提高信息的召回率，有效缓解权重内记忆的不足。
检索增强生成RAG与长上下文的关系
提到上下文窗口，就不得不说到检索增强生成RAG，以及它与长上下文的关系。萨维诺夫解释道，RAG的工作流程是这样的：首先要对知识库进行处理，将一个大型的知识库分割成较小的文本块，然后使用专门的嵌入模型，把每个文本块转换成一个向量。当接收到用户查询的时候，同样将查询也转为嵌入向量。接着比较查询向量与知识库中各文本块向量的相似度，然后把与查询最相关的文本块提取出来，打包进大模型的上下文中。最后，大模型再基于这个构建好的上下文，进行处理并生成回复。
有人可能会问，现在模型本身的信息检索能力越来越强了，RAG会不会因此被集成到模型的内部呢？或者说RAG是不是一个错误的研究方向呢？萨维诺夫认为不是这样的，即使在Gemini 1.5 Pro发布后，RAG也并没有过时。特别是对于企业级知识库来说，它们的数据量往往达到数十亿token，这远远超过了当前模型百万级的上下文窗口。在这种情况下，RAG仍然是必不可少的。
但是往长远看，长上下文和RAG更有可能是一种协同工作的关系，而不是相互取代。长上下文对RAG的好处在于，它允许RAG系统检索并容纳更多相关的关键信息片段到模型的上下文中。以前因为上下文限制，RAG系统不得不设置一些保守的阈值来筛选文本块，但是有了长上下文之后，就可以更加“慷慨”地引入更多潜在相关的事实，从而提高有用信息的召回率，在两者之间达到良好的协同效应。
长上下文的应用场景与质量
在实际应用中，选择短上下文还是长上下文，这往往取决于应用的延迟需求。如果应用需要进行实时交互，比如在线聊天机器人，可能就不得不牺牲一些上下文长度，来保证快速的响应。但是如果应用能容忍稍微长一些的等待时间，比如一些文档分析、复杂问题解答的应用，那么使用长上下文通常能带来更高的信息召回率，从而得到更准确、更全面的回答。
除此以外，长上下文的质量一直是大家关注的重点。自从Gemini 1.5 Pro的技术报告中展示“大海捞针”测试以来，谷歌在长上下文这项技术上已经取得了显著的进步。这不光体现在，在128k上下文的基准测试中，Gemini 2.5 Pro模型的表现优于包括GPT-4.5、Claude 3.7以及DeepSeek在内的强大基线模型，而且在100万上下文的长度下，Gemini 2.5 Pro相比Gemini 1.5 Pro也展示出了显著优势。
不过，关于模型在不同上下文长度下的质量是否一致，或者是否存在波动，这里面也有一些值得探讨的地方。萨维诺夫指出，过去业界曾经观察到一种“中间信息丢失”的效应，也就是模型在处理长上下文的时候，位于中间部分的信息更容易被忽略。但是幸运的是，Gemini在1.5 Pro及后续的版本中，基本没有再观察到这种明显的“中间信息丢失”效应。不过，研究团队也发现，在处理困难任务，特别是存在强干扰项的情况下，随着上下文长度的增加，模型的表现质量也会略有下降。比如说，当模型需要从充满相似结构的键值对的长上下文中，找出特定的目标时，就会面临很大的挑战。这是因为注意力机制本身存在的一个特点，那就是Token之间的竞争。如果一个Token获得了更多注意力，其他Token获得的注意力就会相应减少。因此，如果有强干扰项，也就是与目标信息非常相似但是无关的内容，这些干扰项可能就会吸引大量的注意力，导致真正需要查找的信息，反而获得的注意力不足。而且上下文中的Token越多，这种竞争就会越激烈。
长上下文能力的评估
那么，如何评估长上下文能力呢？最初在Gemini 1.5技术报告的“大海捞针”测试中，要求模型在数百万token中找到一个特定的信息点。对于简单的干扰项，比如在保罗·格雷厄姆的文章中寻找一个特定的数字，这类测试现在基本已经能很好地解决了。当今的研究前沿是如何处理带强干扰项的“大海捞针”，这对模型来说难度更大，以及多“针”检索，也就是要求模型从长上下文中，检索多个不相关的信息点，这对模型来说也是一个不小的挑战。
萨维诺夫还提到，在评估长上下文能力的时候，还需要考虑评估的真实性与核心能力衡量的问题。对于过于追求真实场景的评估，比如基于大型代码库来回答复杂编程问题，可能会偏离衡量长上下文核心能力的目标，转而测试其他能力，比如编码能力，这样就可能给出错误的优化信号。
另外，检索型评估和综合型评估也有各自的特点。单“针”检索任务理论上可以通过RAG来解决，但是真正能体现长上下文优势的，则是那些需要整合整个上下文信息的任务，比如长文本摘要。但是RAG在处理这类任务的时候会遇到困难，而且这类综合型任务的自动评估，也存在着挑战。像摘要任务的评估指标ROUGE并不完美，主观性强，不同人类评估者之间的一致性也可能较低，这就使得基于这类指标进行模型优化时的信号不够强。萨维诺夫个人更倾向于在信号更强、不易被“钻空子”的指标上进行优化。
长上下文与推理能力的联系
那么，长上下文与推理能力之间，有着什么样的联系呢？如果增加上下文长度，能够改善模型预测下一个token的能力么？这个问题我们可以从两个方面来理解。一方面，输入更长的上下文，对短答案的预测也会得到改善；另一方面，输出的token与输入的token本质上是相似的。如果允许模型将自身输出反馈为新的输入，形成思维链，这实际上也扩展了有效的上下文。所以，从理论上来说，强大的长上下文能力应该是有助于推理的。
推理过程通常需要生成思考轨迹，而不是直接输出单token的答案。这是因为模型通过注意力层，在上下文中进行逻辑跳转的能力，受限于网络的深度。但是如果模型可以把中间思考步骤，也就是输出，作为新的输入，它就不再受到网络深度的限制，也就可以执行更为复杂的任务。这就相当于拥有了可读写的记忆。
因此，长输入能力和长输出能力其实并没有根本的不同。模型在预训练后，本身并没有生成大量token的内在限制。比如说，可以给模型输入五十万token并且要求它进行复制，模型其实是能够做到的。然而，在后训练阶段，这种长输出能力需要非常小心地处理，主要原因是存在一个特殊的序列结束符。如果监督微调SFT数据中的序列都比较短，模型就会学到在较短的上下文长度内，就生成这个结束符并且停止。这本质上是一个对齐问题。
推理只是长输出任务的一种，比如翻译也是一种长输出任务，它的整个输出都可能很长，不仅仅是思考轨迹。这就需要通过恰当的对齐来鼓励模型产生长输出。目前萨维诺夫的团队正在积极研究和改进这方面的能力。
开发者使用长上下文技术的最佳实践
对于开发者来说，萨维诺夫给出了一些在使用长上下文技术时，可以参考的最佳实践。
善用上下文缓存
首先是要善用上下文缓存。当首次向模型提供长上下文并且提问的时候，处理时间会比较长，成本也较高。但是如果基于相同的上下文，进行第二次及后续提问，就可以使用上下文缓存功能，这样既能加快响应的速度，又能够降低成本。目前部分模型已经提供了这个功能。
对于用户上传的文件，比如文档、视频、代码库等等，要尽量缓存它的上下文，这样不仅处理速度更快，输入token的平均价格也会显著降低，据说能便宜四倍左右。上下文缓存功能最适用在“与文档聊天”“与PDF聊天”或者“与我的数据聊天”这类应用场景中，因为这些场景的核心要求是原始输入的上下文保持不变。如果输入上下文在每次请求时都发生变化，那么缓存的效果就不会太好。如果上下文确实需要改变，最好是只在末尾追加内容，这样系统就会自动匹配已经缓存的前缀，仅处理新增的部分。
还有提问的位置也有讲究，应该将问题放在上下文之后。如果问题放在上下文之前，那么每次提问都会导致缓存失效，也就无法节省成本。
结合RAG
另外，萨维诺夫建议，当需要处理数十亿token的上下文时，必须要与RAG结合。即使上下文需求没那么大，但是在需要检索多个信息点的应用中，与RAG结合也是有好处的。
避免无关的上下文
还有就是要避免无关的上下文，不要用完全不相关的内容来填充上下文。这不仅会增加成本，还可能会影响多“针”检索的准确性，因为无关内容可能会成为干扰项。虽然长上下文的目的是简化用户的操作，避免耗费时间进行手动筛选，但是在当前阶段，为了获得最佳效果和成本效益，萨维诺夫还是建议避免输入明显无用的信息。不过随着模型质量的提升和成本的下降，未来用户可能就不需要再过多考虑这一点了。
谨慎选择微调
除此以外，开发者有的时候会尝试在特定的知识库，比如大型企业的文档库上对模型进行微调，从而期望提升模型的性能。但是对于长上下文任务而言，微调可能并不一定总是最佳的选择。因为微调通常都是基于有限的数据进行的，这些数据很难覆盖到长上下文所涉及的各种复杂场景和海量信息。而且，微调过程中还可能会引入新的偏差，导致模型在其他任务上的性能下降。
如果只是为了利用长上下文来更新特定知识，那么通过上下文内记忆来传递信息，往往会比微调更加灵活和高效。只有在真正需要模型深度适应特定领域的复杂任务和数据模式时，才需要谨慎的考虑微调，并且做好充分的测试和评估。
长上下文技术的发展历程与未来展望
当然，长上下文技术的发展也并非一蹴而就，背后也有着一段充满挑战与突破的历程。谷歌的团队在研发长上下文技术的时候，一开始就为自己设定了极高的目标，致力于打造出能够处理远超当时行业水平的上下文长度的模型。在 Gemini 1.5 Pro 发布之前，其实在内部测试中就已经展现出了令人振奋的成果。团队发现，模型在处理1000万上下文的时候，不仅能够准确理解其中的信息，还能基于这些信息进行有效的推理和生成。
不过，谷歌团队并没有急着推出拥有 1000 万上下文能力的模型，这是因为在实际中，运行这样的模型需要消耗大量的计算资源，导致处理速度缓慢，成本高昂。所以，他们最终选择将发布的上下文窗口长度，定在100万与200万之间，这样既可以技术领先，又勉强可控。
对于如今非常热门的Agent来说，长上下文技术的发展也与其有着紧密的关系。Agent可以被看作是能够自主感知环境、进行决策并且执行行动的实体，而长上下文能力则为Agent提供了更强大的信息处理基础，使得Agent能够理解和处理更加复杂的任务背景和环境信息。反过来，Agent的发展也对长上下文技术提出了更高的要求，促使研究人员不断地改进长上下文技术。
比如说，在与用户交互的过程中，Agent需要根据用户提供的大量上下文信息，包括历史对话记录、任务目标、背景知识等等，做出合理的决策和回应。长上下文能够让Agent能够更好地理解这些信息之间的关联，从而提供更加准确、更符合用户需求的服务。同时，Agent还可以利用长上下文技术，自动获取和整合相关信息，无需用户手动输入大量的内容。以智能办公场景为例，Agent可以自动地从企业知识库、邮件、会议记录等多个来源提取相关信息，从而为用户提供全面的决策支持。
展望未来，萨维诺夫认为长上下文技术在接下来的三年将迎来更加令人期待的发展。
质量提升
在质量方面，模型将能够更好地处理复杂的长上下文信息，减少因为干扰项等因素导致的性能下降，实现更准确、更连贯的信息处理和生成。
成本降低
在成本方面，通过算法优化和硬件升级，运行长上下文模型的成本将大幅降低，使得更多的开发者和企业能够负担得起。
上下文窗口扩展
在上下文窗口的扩展方面，萨维诺夫指出如今的百万级token只是第一步，第二步是千万级token，最后则是向亿级token的上下文迈进。虽然这个目标充满挑战，但是DeepMind的研究人员已经在探索新的技术路径，比如改进注意力机制、开发更高效的编码方式等，有望实现上下文窗口的进一步扩大。
好了，以上就是这期播客的主要内容了。总的来说，长上下文技术已经在谷歌 Gemini 系列模型中展现出了强大的实力和巨大的潜力，毫无疑问已经成为了如今大模型的关键技术领域之一。大飞我也会继续关注这项技术的发展动态，为大家做一些最新的解读。感谢收看本期视频，我们下期再见。
{# 
{# 
{# 
{# 
{#