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