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 は 今では Gemini 1.5 では 100 万トークンを受け入れ、現在では 200 万トークンを使用 Pro。
実際には、100 万個のトークンは次のようになります。
- 50,000 行のコード（1 行あたり 80 文字として）
- 過去 5 年間に送信したすべてのテキスト メッセージ
- 平均的な英語の小説 8 冊
- 平均的な長さのポッドキャスト エピソードの文字起こしが 200 件以上
モデルはより多くのコンテキストを取り込むことができますが、大規模言語モデルの使用に関する従来の考え方では、モデルに固有の制限があると想定されていました。しかし、2024 年現在、この考え方は当てはまらなくなりました。
小さなコンテキスト ウィンドウの制限に対処するための一般的な戦略としては、次のようなものがあります。
- 新しいテキストが入力されたときに、古いメッセージ / テキストをコンテキスト ウィンドウから任意で削除する
- コンテキスト ウィンドウがいっぱいになる前に、以前のコンテンツを要約して置き換える
- セマンティック検索で RAG を使用して、コンテキスト ウィンドウからベクトル データベースにデータを移動する
- 確定的フィルタまたは生成フィルタを使用して、プロンプトから特定のテキストまたは文字を削除し、トークンを保存する
これらの多くは特定のケースで引き続き行われていますが、現在は、すべてのトークンをコンテキスト ウィンドウに配置する方法が基本となっています。Gemini 1.5 モデルは長いコンテキスト ウィンドウを備えた専用モデルであるため、コンテキスト内の学習がはるかに容易です。たとえば、説明的な内容のみを含む場合は、 （500 ページの参照文法、辞書、約 400 のその他の並列教材） Gemini 1.5 Pro および Gemini 1.5 Flash は、 Google 搭載の自動車では 英語からカラマン（話者 200 人未満、パプア語）に翻訳しました。 オンライン プレゼンスがほとんどなく、 同じ材料から抽出できます
これは、長いコンテキストと Gemini 1.5 のコンテキスト内学習機能で何ができるか考える良い事例となります。
長いコンテキストのユースケース
ほとんどの生成モデルの標準的なユースケースは依然としてテキスト入力ですが、Gemini 1.5 モデル ファミリーでは、マルチモーダル ユースケースの新しいパラダイムが実現されます。これらのモデルは、テキスト、動画、音声、画像をネイティブに理解できます。内容は次のとおりです。 マルチモーダル ファイルを受け取るGemini API が タイプ 便利です。
長いテキスト
テキストが LLM の支えるインテリジェンス レイヤであることは明らかです。前述のように、LLM の実際の制限の多くは、特定のタスクを行うのに十分なコンテキスト ウィンドウがないためでした。検索拡張生成（RAG）などの技術が急速に普及し、モデルに関連するコンテキスト情報を動的に提供できるようになりました。現在では、コンテキスト ウィンドウの 最大 200 万件）、新しい手法が利用可能に 新しいユースケースの可能性が広がります
テキストベースの長いコンテキストの新しいユースケースと標準的なユースケースとしては、次のようなものがあります。
- 大規模なテキスト コーパスの要約
- 以前のコンテキスト モデルの要約オプションでは、新しいトークンがモデルに渡されるときに、以前のセクションの状態を保持するために、スライディング ウィンドウなどの手法が必要でした。
- 質問と回答
- これまではコンテキストの量が限られ、モデルの事実的な再現率が低いため、RAG でのみ可能でした。
- エージェント ワークフロー
- テキストは、エージェントがこれまでに行ったことや行うべきことを記録する方法の基盤ですが、実際の状況やエージェントの目標に関する十分な情報がないため、信頼性に限界があります。
多ショット コンテキスト内学習は、長いコンテキスト モデルによって実現される最もユニークな機能の一つです。研究によると、一般的な「シングルショット」または「マルチショット」のパラダイム（モデルにタスクの 1 つまたは数個の例を提示し、それを数百、数千、数十万の例にスケールアップする）を採用すると、新しいモデル機能につながる可能性があります。このマルチショット アプローチは、特定のタスク用にファインチューニングされたモデルと同様のパフォーマンスを発揮することも示されています。Gemini モデルのパフォーマンスが本番環境へのロールアウトにまだ不十分なユースケースでは、マルチショット アプローチを試すことができます。後述の長いコンテキストの最適化のセクションで説明するように、コンテキスト キャッシュを使用すると、この種の入力トークン ワークロードがはるかに経済的に実現可能になり、場合によってはレイテンシがさらに短くなります。
長い動画
動画コンテンツの有用性は、長い間、メディア自体のアクセス性の欠如によって制限されていました。コンテンツの概要をつかむのは難しく、文字起こしでは動画のニュアンスが伝わらないことが多かったためです。また、ほとんどのツールは、画像、テキスト、音声を同時に処理できません。Gemini 1.5 では、長いコンテキストのテキスト機能を、マルチモーダル入力に関する質問を推論して回答する能力に置き換え、パフォーマンスを維持しています。Gemini 1.5 Flash（動画内の針でテストした場合） 100 万トークンの haystack の問題、動画の再現率 99.8% 超 コンテキスト ウィンドウがあり、Android 1.5 Pro は Video-MME ベンチマーク。
動画の長いコンテキストの新しいユースケースと標準のユースケースとしては、次のようなものがあります。
- 動画に関する質問と回答
- ビデオメモリ（Google の Project Astra）
- 動画字幕作成
- 動画レコメンデーション システム: 新しいマルチモーダル理解によって既存のメタデータを拡充
- データと関連する動画のメタデータの集合を調べ、視聴者に関連しない動画の部分を削除するように動画をカスタマイズ
- 動画コンテンツの管理
- リアルタイムのビデオ処理
動画を制作するときは、動画の品質について 処理されるため、影響します。 料金や使用量の上限を設定できます。動画ファイルを使用したプロンプトについて詳しくは、 プロンプト ガイドをご覧ください。
長い音声
Gemini 1.5 モデルは、音声を理解できる最初のネイティブ マルチモーダル大規模言語モデルです。これまで、音声を処理するためには、音声入力モデルやテキスト文字変換モデルなど、複数のドメイン固有のモデルを連結するという典型的なデベロッパー ワークフローがありました。これにより、複数のラウンドトリップ リクエストの実行に必要なレイテンシが増加し、複数モデルのセットアップで接続されていないアーキテクチャに起因するパフォーマンスの低下が発生しました。
標準的なオーディオ スタックの評価では、Gemini 1.5 Pro は Gemini 1.5 Flash は 100% のテストで隠れた音声を検出でき、 企業の 98.7% テストをご覧ください。 Gemini 1.5 Flash は、 request と Gemini 1.5 Pro は、200 万トークンを使用して最大 19 時間の音声を受信できます。 表示されます。さらに、15 分間の音声クリップのテストセットでは、Gemini 1.5 Pro が アーカイブのワードエラー率（WER）は約 5.5% で、特殊なケースよりもはるかに低い 追加の入力セグメンテーションの複雑さを伴わない音声文字変換 行います。
音声コンテキストの新しい標準的なユースケースとしては、次のようなものがあります。
- リアルタイムの音声文字変換と翻訳
- ポッドキャスト / 動画に関する質問と回答
- 会議の文字起こしと要約
- 音声アシスタント
音声ファイルによるプロンプトの詳細については、プロンプト ガイドをご覧ください。
長いコンテキストの最適化
長いコンテキストと Gemini 1.5 を使用する場合の主な最適化 コンテキストに基づいて キャッシュ保存について説明します。これまでは、1 つのリクエストで大量のトークンを処理することができず、コストも大きな制約となっていました。ユーザーが 10 個の PDF、動画、業務用のファイルをアップロードするチャットアプリを使用している場合、従来は、これらのリクエストを処理するために、より複雑な検索拡張生成（RAG）ツール / フレームワークを使用し、コンテキスト ウィンドウに移動されたトークンに対して多額の料金が発生していました。現在では、ユーザーがアップロードしたファイルをキャッシュに保存し、保存料金を時間単位で支払うことができるようになりました。1 対 1 の入出力の Gemini のリクエスト 1.5 たとえば、Flash は標準の入出力コストの約 4 分の 1 であるため、 ユーザーがデータとチャットするときには 費用の大幅な節約になります 開発者です。
長いコンテキストの制限
このガイドのさまざまなセクションで、Gemini 1.5 モデルがさまざまな「干し草の山から針を探す」検索に対して高いパフォーマンスを達成する方法について説明しました。これらのテストでは、検出対象が 1 つの針である最も基本的な設定を検討しています。複数の「針」や特定の情報が含まれている場合は、モデルの精度が変わります。パフォーマンスはコンテキストによって大きく異なる場合があります。適切な情報を取得することとコストの間には、本質的なトレードオフがあるため、この点は考慮する必要があります。1 回のクエリで約 99% の精度を得ることができますが、そのクエリを送信するたびに入力トークンの費用を支払う必要があります。100 個の情報を取り出すときに 99% のパフォーマンスが必要であれば、100 個のリクエストを送信する必要があります。これは、コンテキスト キャッシュによって、パフォーマンスを維持しながら Gemini モデルの使用に関連する費用を大幅に削減できる例です。
よくある質問
クエリにトークンを追加すると、モデルのパフォーマンスが低下しますか？
一般に、モデルにトークンを渡す必要がない場合は、 渡さないようにします。ただし、大量のトークンと大量のトークンが その情報について質問したい場合は、 情報を抽出する能力（多くのユースケースでは最大 99% の精度）が ケース）。
Gemini 1.5 Pro は、標準的な「干し草の山から針を見つける」テストでどのように動作しますか？
Gemini 1.5 Pro は、最大 53 万トークンで 100% の再現率を達成、最大 53 万トークンの再現率で 100 万 トークン。
コンテキストが長いクエリの費用を抑えるには？
同様のトークン / コンテキストのセットがあり、それらを多数再利用したい場合 コンテキスト キャッシュを使用すると、 関連する情報について質問できます。
200 万トークンのコンテキスト ウィンドウにアクセスするにはどうすればよいですか？
すべてのデベロッパーが Gemini で 200 万トークンのコンテキスト ウィンドウにアクセスできるようになりました 1.5 Pro。
コンテキストの長さはモデルのレイテンシに影響しますか？
リクエストには一定のレイテンシが存在しますが、 ただし、一般的にクエリが長いほどレイテンシが高くなります（最初に あります。
長いコンテキストの機能は、Gemini 1.5 Flash と Gemini 1.5 Pro で異なりますか？
はい。このガイドの別のセクションで説明されている数字もありますが、 一般的に、長いコンテキストのユースケースでは、Gemini 1.5 Pro のほうがパフォーマンスが高くなります。