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