因此，若想确保模型对你的实际需求有所裨益，你必须将个人信息融入情境之中，如此一来，模型便能提供针对性的服务。倘若缺乏这种定制化，模型将提供适用于所有人类的常规答复，而非专门为你量身打造的解答。
此类知识需嵌入文中者，多为鲜为人知的资讯。故而，此类信息在互联网上并不多见。我猜测，随着时间的流逝，这些知识或许会逐渐消逝。或许在将来，模型能够将互联网上的所有内容都铭记于心，届时我们便无需为此忧虑。
然而，当前的情形是，一旦某事项在互联网上仅被提及寥寥数回，模型往往难以真正记住这些细节，反而可能虚构答案（出现错觉）。因此，你或许需将这些信息明确地融入语境之中。我们面临的一个挑战是，对于短语境模型而言，你所能提供的额外语境是有限的。基本上，知识来源之间会存在一种竞争关系。在上下文信息量庞大时，插入内容时可以不那么严格，同时也能够更有效地检索和涵盖相关知识点。
若你在特定情境下的使用频率更高，那么这将有助于减轻由权重内记忆所引发的所有相关问题。
RAG 暂时不会被淘汰
主持人：我们讨论了“权重内”记忆以及上下文记忆，此外，还有一种引入上下文的方法，即所谓的RAG（检索增强生成）系统。接下来，请您为我们详细介绍RAG系统。
Nikolay：RAG技术涉及一种工程手段，该手段在信息输入至LLM的语境前，增设了一个预处理环节。试想，你手中拥有一个庞大的知识库，需先将它划分为众多微小的文本片段。接着，运用一种特定的嵌入模型，将每个文本片段转化为一个实值向量。而当用户发起查询时，该查询同样会被转换为一个向量。随后，系统将执行查询向量与知识库内所有文本块向量的比对，识别出与之最为贴近的文本块，并将这些内容视为相关。紧接着，LLM 将依据这些包含相关信息的上下文进行回答的生成。这一过程正是RAG运作机制的核心所在。
主持人提到，目前某些模型所处理的上下文长度已达到百万甚至两百万个token，虽然这个数字颇为可观，但与维基百科等动辄包含数十亿token的信息库相比，还是显得较为有限。而RAG技术正是为了在这种庞大的信息海洋中，有效地检索出相关的上下文内容而设计的。
为何不将这种搜索功能直接集成到模型内部，使其能够直接应对数十亿 token 的广泛语境，自行挖掘所需信息？这难道不是一个更为简便的解决方案吗？是这一研究方向本身存在缺陷，还是说这根本就不应该是模型所承担的任务？
在我们推出1.5 Pro版本之后，社交媒体上出现了众多关于RAG是否会被淘汰的讨论。我认为，RAG并不会被淘汰。以企业知识库为例，其信息量通常可达数十亿token，远超百万级别。对于如此大规模的应用场景，RAG依然是不可或缺的。因此，我坚信在具体应用场景中，RAG 并不会迅速被市场淘汰，反而会与长上下文形成良好的协作关系。长上下文对 RAG 的益处在于，它能够让 RAG 有机会检索和纳入更多可能相关的文本片段，进而有效提升对有用信息的检索准确率。在以往，为确保信息的关联性，我们设定了极为严苛的筛选门槛，导致许多可能具有价值的信息被剔除。然而，随着长上下文的引入，我们得以放宽筛选标准，纳入更多的事实资料。在我看来，这两者之间形成了极佳的互补作用。真正制约我们的，是应用程序对延迟的严格要求。若需实现即时交流，则必须依赖较短的信息片段；然而，若能容忍较长的等待，那么采用较长的上下文将更为理想，这有助于提升信息的匹配度。
当我初涉长上下文研究领域时，对手的能效大约在12.8万（128k）或20万token之间。那时，这个项目仅是谷歌Gemini宏大计划的一个微不足道的分支。我最初的构想是，仅仅达到对手的水平显然不足够，不如确立一个更为雄心勃勃的目标。设定100万token，这样的目标无疑具有极大的挑战性。与20万token相比，这几乎实现了五倍的增长。在推出百万token级别模型之后，我们又推出了两百万token的新版本，进一步扩大了规模。这一进展比当时最前沿的技术水平高出整整一个数量级。这无疑是一个值得追求的目标，同时也极大地激发了团队进行研发的积极性。
长上下文对推理模型和 Agent 很重要
主持人提出疑问：更强的推理能力为何能够使长上下文的作用得到更充分的体现，这难道是顺理成章的结论吗？这或许是因为模型在“思考”上投入了更多时间，抑或是两者之间存在着更为复杂的内在联系？
Nikolay表示，推理与长上下文间存在更为深远的关联。若扩展上下文长度有助于优化对后续token的预测，这可从两方面来解读。首先，引入更多上下文信息，有助于提高对简短答案预测的精确度。其次，鉴于生成的标记与输入标记在形态上存在相似性，若允许模型将自身的输出信息重新输入至输入端，那么原本的输出便在某种程度上转变成了新的输入。从理论层面来看，那些拥有卓越长上下文处理能力的模型，其在推理性能上也应当表现出优异的表现。
此外，在推理过程中，上下文的长度显得尤为关键。以决策任务为例，即便在只有两个选项的情况下，只需生成一个 token，但若能先构建出完整的推理链条，往往能够获得更优的答案。这是因为，从模型架构的视角来看，在预测下一个 token 时，若需在上下文中进行多次逻辑推断，会受到“网络深度”这一因素的制约。“网络深度”与注意力层的数量相仿，它制约了模型在单次前向传播过程中逻辑推理的步数。然而，若将输出信息反馈至输入端，模型便能够超越这一局限，仿佛获得了可写入的“记忆”功能。这样一来，模型便能够应对比仅凭网络深度所能处理的更为复杂的任务。
主持人：您如何看待 Agent 的应用领域与较长文本内容之间的联系？较长的文本内容是否是打造优质 Agent 体验的核心要素？这两者之间是如何相互影响的？
Nikolay表示，这个问题确实引人入胜。他认为，Agent不仅可以作为长上下文的消费者，还可以扮演长上下文的供应者角色。为了高效运作，Agent必须记录前一个状态，包括之前执行的动作、所进行的观察等，当然也包括当前的状态。所以，为了能够保留所有先前的交流内容，我们必须提供更广阔的背景信息，这便是长上下文对智能体所提供的帮助，亦即智能体作为长上下文利用者的状态。
然而，换个角度来看，Agent 同样是长上下文的供应者。毕竟，手动整理大量的上下文信息相当繁琐。比如，若每次都需要手动上传所需的全部文档，或者上传一段视频，又或是从网络上复制粘贴相关内容，这样的过程过于复杂，几乎无人愿意这么做。大家更期待模型能够自动完成这些工作。要达到这一目标，一种途径便是借助 Agent 的功能调用。因此，当模型在某一特定时刻作出决策，例如：“现在我需要获取更多资料”，它便能自主地梳理相关背景信息。从这一角度出发，Agent 可被视为是长段背景信息的供给者。
主持人：确实，这是一个十分典型的案例。我深以为这是人类与人工智能系统交流时面临的主要障碍之一，正如你所提到的例子，过程确实相当繁琐。在处理任何与人工智能相关的事务时，最令人头疼的一点，就是必须搜寻所有可能与该模型有关的背景信息，并且亲自将这些信息输入系统。在众多场合，相关资料或许早已存于我的显示器或电脑之中，我清楚它们的具体位置，然而仍需亲自完成这些繁重的任务。因此，我热切期盼能够开发一套能够自动搜集你上下文信息的长期上下文代理系统。我认为这样的体验将极具趣味性，同时，这也将有效解决一个极为基础的问题。这一问题不仅对开发者至关重要，对于AI系统的终端用户来说同样重要。我期望模型能够自主地获取我的上下文信息，无需我亲自进行操作。
Nikolay：是的，确实是这样。
怎么用好上下文：多用上下文缓存
我们发现，开发者对长文本输出的需求极为迫切，这并不仅限于长文本输入。因此，我想请教，长文本的输入与输出能力之间存在着怎样的关联？从学术研究的视角来看，这两种能力是否实质上等同，最终会趋向于一致，还是它们在根本上是完全不同的？
Nikolay表示，就本质而言，长文本的输入与输出功能并无二致。需要明确的是，从预训练的视角来看，模型在生成大量标记方面实际上并未存在真正的障碍。比如，你输入五十万个标记，要求模型执行复制任务，它完全有能力完成，这一点我们已在实验中得到了证实。但需注意的是，这种能力在预训练完成后需要得到谨慎的引导。由于模型在后续的学习过程中会遇到一个特定的序列终结标记，若在监督微调阶段所采用的数据片段普遍较短，那么模型在序列的初期阶段就会频繁地遭遇这一终结标记。
随着时间的推移，模型将逐渐领悟到：“在 X 长度的文本范围内，你反复向我呈现这个特定的 token，因此我学会了生成它并终止输出，这原本是你传授给我的操作准则。”这实际上涉及到了模型的对齐（alignment）问题。然而，我想要强调的是，推理仅仅是长文本生成任务中的一个方面。举例来说，翻译同样属于长文本生成任务的一种。推理具备特定的结构，通过特定的符号将思维流程界定出来，模型能够识别这种结构并执行连锁推理。至于翻译任务，其输出内容往往相当冗长。这正是我们希望模型能够掌握并展示的技能。因此，这实质上是一个如何准确调整模型参数的问题。同时，我们也在积极研究如何提升模型长文本输出的能力。
主持人：开发者怎样更高效地运用长文本以及RAG技术？关于他们如何有效运用长文本，你有哪些具体的建议可以提供？
尼古拉耶夫：我的首要建议是，尽可能多地运用上下文缓存机制。我来详细阐述一下这一理念：当您首次向模型输入较长的上下文并提问时，所需处理的时间和成本都会相对较高。但若您在相同的上下文背景下再次提问，便可以借助上下文缓存，从而使后续的问答过程变得更加经济高效，速度也会显著提升。这功能目前仅对部分模型开放。因此，请充分利用这一功能，尝试对用户上传的文件进行缓存，这样做不仅能够提升处理效率，而且还能将平均输入成本减少至原来的四分之一左右。
主持人：这里我以一个例子来解释。在“与我的文档对话”或“与 PDF 对话”等常见应用中，初始的输入内容是既定的，这种情况下上下文缓存便派上了用场。要有效利用上下文缓存，每次的请求都必须确保提供的原始内容保持不变。一旦输入内容频繁变动，缓存的效果便会显著降低。
是的，您的观点完全准确。在诸如与一组既定文档对话、向一段时长较长的视频提出问题或对某个代码库执行操作等情况下，上下文缓存显得尤为关键。您所说的知识不应随意变更也是正确的。若知识确实需要更新，最理想的处理方式是在上下文的最后部分进行补充。这是因为底层实现会识别缓存中的最长公共前缀，并仅对新增内容进行处理。开发者们常常疑惑：是在上下文的前端还是后端提出问题更为妥当？对此，我的看法是：应将问题置于后端。如此一来，若意图通过缓存降低成本，这便是一个明智的选择。反之，若将问题置于起始阶段，那么每一次的请求都可能触发缓存失效，从而不得不重新从头开始处理。
主持人表示，这个提议极其实用。从开发者的视角来看，是否还有其他方面需要我们关注？
Nikolay提到，我们之前已经讨论过这一点，即与RAG的结合。在处理数十亿token的上下文时，这种结合是不可或缺的。即便上下文规模较小，在某些需要检索多个关键信息的场合，这种结合依然可能适用。
此外，还需注意一点，那就是在叙述过程中应尽量排除无关紧要的元素，以免干扰到对重要信息的查找效率。此外，还有一个值得关注的细节，那就是“权重内”记忆与上下文记忆之间的相互影响。若要借助上下文记忆来更新“权重内”的记忆内容，模型就必须同时参考这两种记忆来源，而它们之间可能存在冲突。我认为，通过精心设计提示词来明确解决这种矛盾是很有帮助的。
在提问过程中，若能附加“根据前述所提供的信息……”等类似的前置说明，如此一来，您便向模型传递了一个清晰的指示，使其更倾向于依赖上下文中的记忆，而非“权重内”的记忆，进而有助于消除这种模糊性。
主持人提出疑问：针对特定知识库，我们如何评估对长上下文进行细微调整的效果？这样的方法是否能够显著提升通用性？
Nikolay：接下来，我要向大家详细阐述一下在知识库中实施微调的具体步骤。在不少情况下，人们会接触到额外的知识资源，例如那些规模庞大的企业知识库。这些库，正如我们进行预训练时那样，也会被用作训练网络的素材。在这个过程中，我们利用语言建模损失函数来指导模型学习如何预测下一个标记。尽管这种融合信息的方法颇具成效，但它也存在着一定的局限性。
训练网络的过程并非仅仅涉及提供背景信息，它还涉及到众多环节，例如对超参数进行优化、明确何时终止训练，以及处理模型可能出现的过拟合问题。尽管这种微调技术在执行推理任务时表现出高效和低成本的优势，因为其将知识直接嵌入到模型权重中，但它的不足之处同样明显。研究表明，这种通过“硬编码”进行知识输入的方法，不仅可能使模型的幻觉问题恶化，还引发了两个接踵而至的问题：首先，隐私安全隐患随之而来，一旦敏感信息被嵌入权重，便难以彻底清除；其次，知识更新面临困境，固定的知识难以调整，一旦知识陈旧，最终还是得依赖上下文来补充新信息，从而形成了一个矛盾的局面。
大海捞针做评测已经过时了
主持人提问：模型的质量是否会因上下文规模的不同而有所变动？举例来说，当token数量从五万增至十万，再进一步增加到十二万八千时，模型质量的提升是呈现线性增长，还是在不同规模中大致维持稳定？是否存在某些特殊情况，比如在某一特定规模下，模型的性能反而会出现下降呢？
Nikolay表示，我们内部确实进行过此类评估。您提出的问题或许与之前观察到的某些现象相关，例如那普遍存在的“中间信息丢失效应”。就我们模型而言，并未明显发现上下文中间部分信息出现丢失的情况。在应对那些含有强烈干扰因素的繁杂任务时，我们确实观察到，随着背景信息的增多，模型的表现会有所减弱。这一点正是我们致力于提升的领域。
主持人提到，向模型的上下文窗口输入10万token的信息后，作为开发者或用户，我们是否可以推断模型会全面关注所有上下文内容？我了解到模型在提取单个关键信息方面表现精准，但我想问，它是否会对每一个token进行推理分析呢？
这是一个非常出色的提问。在注意力机制中，有一个本质的特性，那就是各个token之间存在着相互竞争的关系。当某个token获得了更多的关注时，其他token所获得的关注量就会相应地减少。问题在于，当上下文中存在强烈的干扰因素，例如某个干扰项与所需查找的目标信息极为相似时，这种相似性可能会吸引大量注意力，进而导致目标信息所获得的关注减少。随着上下文中token数量的增加，这种竞争愈发激烈。因此，模型的表现会受到干扰因素难度的制约以及上下文规模的影响。
主持人提问：这个注意力机制的总量是否是恒定不变的？它是否有可能得到提升？或者，它是否是一个固定的数值（例如1），然后这个数值被平均分配到每一个token上？这样一来，随着token数量的增加，每个token所获得的注意力就会相应减少，并且这种分配方式是无法进行调整的。
Nikolay：通常情况下是这样的，注意力的总量是有限的。
主持人提到，“大海捞针”测试作为一项广为人知的上下文质量评估手段，已证实了模型在浩瀚信息中准确锁定特定事实的能力。然而，除了这一方法，是否还存在其他评估标准或基准测试可供选择呢？
Nikolay：在我看来，评估构成了LLM研究的根本。特别是在规模较大的团队里，高标准的评估有助于确保团队目标的一致性，促进成员间的协作，这对于长文本的研究尤为关键。比如，在那些需要从海量文本中筛选出特定信息，如“大海捞针”般困难的任务中，若仅以Paul Graham（YC创始人）的一篇文章为依据，提出“巴塞罗那的神秘数字是多少？”这样的问题，目前，模型在解决此类问题上已表现出色。研究正聚焦于应对那些含有强烈干扰元素的场景。比如，若在上下文中填充大量“某座城市的神秘数字为y”这类键值对，任务难度将显著提升，因为干扰信息与目标信息极为相似。另外，对于大语言模型而言，同时检索多个关键信息同样构成一大挑战。因此，处理强干扰和多关键信息检索是目前的研究重点。
其次，在评估过程中，还需考虑诸多其他需权衡的要素。即便加入了强烈的干扰因素，这种犹如“大海捞针”的评估方法，在本质上仍旧是人为设定的。部分人期望评估能更加贴近实际应用场景，这种观点无疑是正确的。然而，我们必须注意到，若评估过于追求现实性，那么它可能就无法准确衡量模型在处理长上下文方面的真实能力。在庞大的代码库中咨询时，可能正确答案隐藏于某个特定文件之中，然而，执行任务却需模型执行一连串复杂的步骤。在这种特定情境下，测试的重点更多地集中在模型的编码技能上，而非其处理长上下文信息的能力。这样的测试结果可能会误导研究方向的判断，导致我们最终对错误的关键点进行了优化。
最终，我们还需关注一个重要的领域——“检索与合成评估”。从理论上讲，RAG能够解决在浩瀚信息中寻找单个关键信息的“大海捞针”问题。然而，我们更应该关注的是那些需要模型整合全面上下文信息的任务，例如文本摘要，这类任务RAG在处理时显得力不从心。尽管这些任务的方向是正确的，但实现自动化评估却面临着诸多挑战。由于诸如ROUGE（大型模型评估指标）之类的指标难以全面反映人类对质量的个人评价，因此在模型优化过程中，采用那些评判标准明确、反馈信息清晰的指标将更为合理。
主持人提出疑问：文本总结任务的效果为何不尽如人意？这或许是因为对“优秀”与“劣质”的总结带有较强的主观色彩，缺乏统一的评判标准，抑或是存在其他因素使得此类应用场景的评估变得尤为困难？
是的，这种评估具有相当的不确定性，即便是人类评估员之间的共识程度也相对较低。当然，这并不意味着我们不应开展或评估总结任务，因为它们本身具有极其重要的价值。我仅仅是想说明，就我个人而言，作为研究者，我更倾向于在具备明确信号反馈的领域进行优化工作。
千万级别上下文的瓶颈是成本
主持人提问：当上下文扩展至百万或两百万token时，将面临何种限制？是服务费用显著增加，还是现有的模型架构在更大token规模面前无法维持其有效性？为何长上下文技术的研究进展缓慢，迟迟未见新的突破？
实际上，在推出 Gemini 1.5 Pro 版本之际，我们针对千万量级的 token 进行了推理测试，并取得了令人满意的质量数据。在千万 token 的范围内检索特定关键信息这类任务，模型的表现接近完美。我们原本有计划发布这个模型，然而，执行如此大规模推理所需的成本极为高昂。我们起初并未确切知晓用户是否愿意承担高额的费用，因此选择了以较低的价格作为起始点。然而，你所提出的问题至关重要，因为进行此类测试的代价极其高昂，导致我们未能进行广泛的验证。仅是启动服务器的费用就已十分巨大，除非我们打算向众多客户开放，否则我们缺乏足够的芯片资源来支撑。
主持人提问：这种状况是否将持续？在深化上下文研究的过程中，模型性能的提升是否会遭遇障碍？我们是否需要实现研究上的重大突破，以实现上下文规模的进一步扩大，抑或是百万至两百万token已经构成了上限，而未来的拓展将不得不依赖于RAG等在模型外部进行上下文优化的策略？
Nikolay表示，我们迫切需要创新。若要达到近乎完美的千万级token上下文，仅仅扩大规模是不够的，我们还需要在技术上实现新的突破。至于RAG和长上下文这两种范式，哪种在未来会占据主导地位，我认为随着时间的推移，模型成本将会降低，届时我们将尝试将更多通过RAG检索到的信息融入模型上下文中。并且，由于模型质量也在提升，这样做的收益会越来越大。
主持人：你之前说过，强烈的干扰信息可能会导致模型注意力分散。基于这一观点，你们团队是否对预过滤技术进行了研究？在理想状态下，较长上下文窗口中的数据差异越大，效果通常会更好。一旦数据高度相似，并且问题与这些数据密切相关，模型的性能可能会受到影响。这种问题是否只能由开发者在使用阶段来处理呢？
Nikolay表示，作为研究员，他个人认为过分依赖过滤技术可能并非最佳选择。他主张应将更多资源用于增强模型的整体质量和稳定性。然而，从实际操作的角度来看，他提出一个可行的建议：应尽量减少在文本中包含与上下文无关的信息。若已知某些信息毫无价值，则不应将其纳入其中，这样做至少可以降低成本。
主持人表示，这一现象颇为有趣，实际上在一定程度上，它与大众最初对长上下文的使用目的并不一致。在网络上，我们常常看到人们将各类数据一股脑地输入模型，希望模型能够自行辨别并筛选出有价值的信息。鉴于去除无关内容的重要性，人们似乎更期待模型具备自动预过滤的能力。毕竟，长上下文的一大优势在于让用户无需花费精力去筛选输入的数据。模型能否演变成一个由多个模块构成的系统，这样的系统能够依据用户的查询自动筛选掉不相关的信息，进而使得后续的处理过程变得更加简便？
随着时间的流逝，当模型的质量得到提高且成本相应下降时，这个问题便无需再被考虑。目前阶段，若想充分挖掘长上下文的价值，从实际角度出发，尽量避免引入无关信息。我同样认同你的看法，若需投入大量时间手动筛选或精心挑选上下文，过程将异常繁琐。因此，我认为在两者之间寻求一个平衡点至关重要。上下文的价值在于它旨在简化用户的工作流程，提升其自动化程度，而非加重用户手动操作的压力。
百万级上下文质量还不完美时，更长上下文意义不大
主持人询问：在长期的发展规划中，我们的方向将如何演变？在接下来的三年里，用户将能够期待到哪些新的变化？
Nikolay表示，他将进行一些预测。首先，预计在百万或两百万token的上下文中，质量将显著提高。我们很快就能在绝大多数检索任务中实现接近完美的效果。将此视为第一步的原因在于，在百万token的上下文尚未完美之前，盲目追求更大规模并无太大意义。我坚信，若我们成功构建出接近完美的百万token语境，将激发出诸多我们目前无法预见的创新应用领域。届时，模型在处理和关联信息方面的能力将实现显著提升。事实上，模型已具备同时处理远超人类极限信息量的能力。比如，让人类在观看一小时的视频后，精确回答一个细节问题（例如：“视频中的哪一秒有人掉落了一张纸？”）对于人类来说极为不易。我坚信，这种超出人类范畴的能力将会逐渐变得广泛，而更卓越的上下文理解力将开启一系列我们未曾设想的应用场景。这标志着我们迈出的第一步，即提高内容的质量。
在第二步中，我们致力于降低长上下文处理成本。虽然这过程可能耗时较长，但最终定能达成目标。随着成本逐渐降低，处理更长的上下文将不再是难题。据我预测，千万级别的token上下文将很快成为标配，对编码等应用领域而言，这将带来颠覆性的变革。目前，百万级别的上下文仅适用于中小型代码库，而千万token则能容纳整个大型项目。届时，我们将掌握一种近乎完美地回忆起整个上下文内容的新型技术。现阶段，程序员们必须记住大量数据以实现高效作业，且需在多个文件间不断切换，他们的注意力是有限的。然而，大型语言模型将彻底消除这些困扰，它能够一次性存储所有信息，精确地重现任何片段，并能真正实现不同文件间信息的关联，从而成为一位极其高效的编码助手。不久，将涌现出超越人类智能水平的编码助手，这类助手将成为全球程序员的新工具。这一现象将在千万token上下文技术成熟后，成为发展的第二个阶段。
对于跨越一亿token的语境，难度将显著提升。我坚信这一目标终将达成，然而对其实现的速度却缺乏明确预期，并且很可能需要深度学习领域内的根本性突破来助力这一成就。
主持人提问：在促进长上下文演进的过程中，是硬件的局限性还是算法的革新构成了当前更为显著的障碍？面对这一挑战，我们这些研究者究竟应当耐心等待硬件技术的成熟，还是认为算法领域本身具有更大的突破潜力？
Nikolay：光有芯片还不够，还得有极具天赋的推理工程师。我们的推理团队在处理百万级别token的上下文方面已取得显著成绩，若没有他们，我们根本无法向客户提供服务。因此，我们需要在推理工程领域持续加大投入，我不认为这个问题会自然而然地得到解决。
