许多 Gemini 模型都具有大上下文窗口，可容纳 100 万个或更多词元。过去，大语言模型 (LLM) 受到一次可传递给模型的文本（或词元）数量的极大限制。Gemini 长上下文窗口发掘了许多新的应用场景和开发者模式。
您已用于文本生成或多模态输入等场景的代码可以直接用于长上下文，无需进行任何更改。
本文档简要介绍了使用上下文窗口大小为 100 万个词元或以上的模型可以实现哪些功能。本页面简要介绍了上下文窗口，并探讨了开发者应如何考虑长上下文、长上下文的各种实际应用场景，以及优化长上下文使用的方法。
如需了解特定模型的上下文窗口大小，请参阅模型页面。
什么是上下文窗口？
使用 Gemini 模型的基本方法是将信息（上下文）传递给模型，模型随后会生成回答。上下文窗口可以比作短期记忆。人们的短期记忆可以存储有限的信息量，生成模型也是如此。
您可以参阅我们的生成模型指南，详细了解模型在后台的工作原理。
开始使用长上下文
早期版本的生成式模型一次只能处理 8,000 个令牌。较新的模型进一步提高了此数字，可接受 32,000 个甚至 128,000 个词元。Gemini 是第一个能够接受 100 万个令牌的模型。
在实际中，100 万个词元相当于：
- 50,000 行代码（标准为每行 80 个字符）
- 您在过去 5 年内发送的所有短信
- 8 部平均长度的英语小说
- 200 多个平均时长播客剧集的转写内容
许多其他模型中常见的上下文窗口较为有限，因此通常需要采用一些策略，例如任意舍弃旧消息、总结内容、将 RAG 与向量数据库搭配使用，或过滤提示以节省令牌。
虽然这些技术在特定场景中仍然很有价值，但 Gemini 的宽广上下文窗口更提倡采用更直接的方法：预先提供所有相关信息。由于 Gemini 模型是专门构建的，具有强大的上下文处理能力，因此它们具有强大的上下文学习能力。例如，仅使用情境教学材料（500 页的参考语法书、一本字典和大约 400 个平行句子），Gemini 就学会了从英语翻译成 Kalamang（一种使用人数不到 200 人的巴布亚新几内亚语言），翻译质量与使用相同材料的人类学习者相当。这说明了 Gemini 的长上下文带来的范式转变，通过强大的上下文学习功能，赋予了新可能。
长上下文应用场景
虽然大多数生成模型的标准应用场景仍然是文本输入，但 Gemini 模型系列可实现多模态应用场景的新模式。这些模型可采用原生方式理解文本、视频、音频和图片。它们附带可接受多模态文件类型的 Gemini API，以方便使用。
长文本
事实证明，文本是支撑 LLM 大部分发展势头的智能层。如前所述，LLM 的很多实际限制是因为没有足够大的上下文窗口来执行某些任务。这导致了检索增强生成 (RAG) 和其他技术的快速采用，这些技术可为模型动态提供相关的上下文信息。现在，随着上下文窗口越来越大，出现了一些新技术可用于发掘新的应用场景。
基于文本的长上下文的一些新兴和标准应用场景包括：
- 总结大型文本语料库
- 之前使用较小上下文模型的总结方法需要使用滑动窗口或其他技术，以便在新词元传递给模型时保留之前部分的状态
- 问答
- 过去在上下文数量有限且模型的真实召回率较低的情况下，只有使用 RAG 才能实现这一目的
- 智能体工作流
- 文本是智能体如何保存已完成的操作和需要执行的操作的状态的基础；如果没有关于实际世界和智能体目标的足够信息，会限制智能体的可靠性
多样本上下文学习是长上下文模型发掘的最独特功能之一。研究表明，采用常见的“单样本”或“多样本”示例模式，在其中向模型提供一个或几个任务示例，然后扩展到多达数百个、数千个甚至数十万个示例，这可能形成全新的模型功能。事实证明，这种多样本方法的性能与针对特定任务进行了微调的模型类似。对于 Gemini 模型的性能尚不足以满足生产发布的应用场景，您可以尝试多样本方法。正如您稍后将在长上下文优化部分中所了解的那样，上下文缓存使这种高输入词元工作负载类型在经济上更加可行，在某些场景中甚至可降低延迟。
长视频
无法访问媒体本身长期以来一直限制着视频内容的实用性。浏览内容并非易事，转写通常无法捕获视频的细微差别，而且大多数工具无法同时处理图片、文本和音频。借助 Gemini，长上下文文本功能可转换为以持续的性能推理和回答有关多模态输入的问题的能力。
视频长上下文的一些新兴和标准应用场景包括：
- 视频问答
- 视频内存，如 Google 的 Project Astra 所示
- 视频字幕
- 视频推荐系统，通过新的多模态理解来丰富现有元数据
- 视频自定义，可查看数据以及关联视频元数据的语料库，然后移除与观看者无关的视频部分
- 视频内容审核
- 实时视频处理
处理视频时，重要的是考虑如何将视频处理为词元，这会影响结算和用量限额。如需详细了解如何使用视频文件进行提示，请参阅提示指南。
长音频
Gemini 模型是首批能够理解音频的原生多模态大语言模型。传统上，典型的开发者工作流涉及将多个特定于领域的模型（例如语音转文字模型和文本到文本模型）串联起来，以便处理音频。这会导致执行多次往返请求所需的延迟时间增加并且性能下降，这通常归因于多模型设置的分离架构。
音频上下文的一些新兴和标准应用场景包括：
- 实时转写和翻译
- 播客/视频问答
- 会议转写和总结
- 语音助理
如需详细了解如何使用音频文件进行提示，请参阅提示指南。
长上下文优化
使用长上下文和 Gemini 模型时，主要优化方法是使用上下文缓存。除了以前无法在单个请求中处理大量词元之外，另一个主要限制是费用。如果您有一个“与数据聊天”应用，用户在其中上传了 10 个 PDF 文件、一个视频和一些工作文档，那么过去您必须使用更复杂的检索增强生成 (RAG) 工具/框架来处理这些请求，并为移入上下文窗口的词元支付大量费用。现在，您可以缓存用户上传的文件，并按小时为存储这些文件付费。例如，使用 Gemini Flash 时，每个请求的输入/输出费用约为标准输入/输出费用的 1/4，因此如果用户与其数据进行足够多的聊天，便可为作为开发者的您节省大量费用。
长上下文限制
在本指南的各个部分中，我们讨论了 Gemini 模型如何在各种“大海捞针”检索评估中实现高性能。这些测试考虑了最基本的设置，您在其中只需寻找一根“针”。如果您要寻找多根“针”或特定信息，模型执行的准确率会有所不同。性能可能会因上下文而变化很大。考虑这一点很重要，因为在检索到正确信息与费用之间存在固有的权衡。您在单个查询中可获得大约 99% 的准确率，但每次发送该查询时，您都必须支付输入词元费用。因此，要检索 100 条信息，如果您需要 99% 的性能，则可能需要发送 100 个请求。这是一个很好的示例，上下文缓存在其中可显著降低与使用 Gemini 模型关联的费用，同时保持高性能。
常见问题解答
在上下文窗口中，查询的最佳放置位置在哪里？
在大多数情况下（尤其是在总上下文较长的情况下），如果您将询问 / 问题放在提示的末尾（所有其他上下文之后），模型的效果会更好。
如果向查询添加更多令牌，模型性能会下降吗？
通常，如果您不需要将令牌传递给模型，最好避免传递令牌。不过，如果您有大量包含某些信息的令牌，并且想要询问与这些信息相关的问题，该模型非常擅长提取这些信息（在许多情况下，准确率高达 99%）。
如何通过长情境查询降低费用？
如果您有一组类似的令牌 / 上下文，并且希望多次重复使用，上下文缓存可以帮助您降低与询问此类信息相关的费用。
上下文长度是否会影响模型延迟时间？
任何给定请求（无论大小）都会存在一定的延迟时间，但通常，查询越长，延迟时间（首次获取令牌的时间）就越长。