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 与语义搜索搭配使用，将数据移出上下文窗口，以及 导入矢量数据库中，
- 使用确定性过滤器或生成过滤器移除特定文本 / 提示中的字符，用于保存令牌
虽然其中许多在某些情况下仍然具有相关性，但默认显示 start 现在只是将所有词元放入上下文窗口中。因为 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 万人）的新技术陆续推出， 从而发掘新的应用场景
基于文本的长上下文的一些新兴和标准用例包括：
- 总结大型文本语料库
<ph type="x-smartling-placeholder">
- </ph>
- 之前采用较小上下文模型的汇总选项将需要 使用滑动窗口或其他方法来保持前面各部分的状态 将新词元传递给模型，
- 问答
<ph type="x-smartling-placeholder">
- </ph>
- 过去，由于 RAG 的 上下文和模型的事实回想度较低
- 代理工作流
<ph type="x-smartling-placeholder">
- </ph>
- 文本是代理保持其所做状态的基础 以及需要采取的行动没有足够的关于这个世界的信息 而代理的目标是限制其可靠性
多样本情境学习是 由长上下文模型解锁的大多数独特功能。研究表明 “单一镜头”的想法或“多样本”其中的 该模型会为某个任务提供一个或多个示例， 成百上千甚至数十万个样本都可能导致 新的模型功能。事实证明，这种多样本方法 这类似于针对特定任务微调的模型。应用场景 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、1 个视频和一些工作文档 来运用更复杂的检索增强生成 (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 在大多数较长的上下文用例中的性能都更高。