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