長いコンテキスト

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 行のコード（1 行あたり 80 文字として）
  • 過去 5 年間に送信したすべてのテキスト メッセージ
  • 平均的な長さの英語の小説 8 冊分
  • 平均的な長さのポッドキャスト エピソードの文字起こしが 200 件以上

モデルはより多くのコンテキストを取り込むことができますが、大規模言語モデルの使用に関する従来の考え方では、モデルに固有の制限があると想定されていました。しかし、2024 年現在、この考え方は当てはまらなくなりました。

小さなコンテキスト ウィンドウの制限に対処するための一般的な戦略としては、次のようなものがあります。

  • 新しいテキストが入力されたときに、古いメッセージ / テキストをコンテキスト ウィンドウから任意で削除する
  • コンテキスト ウィンドウがいっぱいになる前に、以前のコンテンツを要約して置き換える
  • セマンティック検索で RAG を使用して、コンテキスト ウィンドウからベクトル データベースにデータを移動する
  • 確定的フィルタまたは生成フィルタを使用して、プロンプトから特定のテキストまたは文字を削除し、トークンを保存する

これらの多くは特定のケースで引き続き行われていますが、現在は、すべてのトークンをコンテキスト ウィンドウに配置する方法が基本となっています。Gemini 1.5 モデルは長いコンテキスト ウィンドウを備えた専用モデルであるため、コンテキスト内の学習がはるかに容易です。たとえば、Gemini 1.5 Pro と Gemini 1.5 Flash は、学習教材（500 ページの文法解説、辞書、約 400 の追加並列文）のみをコンテキストで提供することで、英語からパプア語の一種であるカラマング語への翻訳を学習する能力を備えています。カラマング語は、話者が 200 人未満で、オンラインでの存在感がほとんどない言語です。人間が同じ教材から学習した場合と同等の品質を実現しています。

これは、長いコンテキストと Gemini 1.5 のコンテキスト内学習機能で何ができるか考える良い事例となります。

長いコンテキストのユースケース

ほとんどの生成モデルの標準的なユースケースは依然としてテキスト入力ですが、Gemini 1.5 モデル ファミリーでは、マルチモーダル ユースケースの新しいパラダイムが実現されます。これらのモデルは、テキスト、動画、音声、画像をネイティブに理解できます。マルチモーダル ファイル形式を受け取る Vertex AI API for Gemini も用意されています。

長いテキスト

テキストが LLM の支えるインテリジェンス レイヤであることは明らかです。前述のように、LLM の実際の制限の多くは、特定のタスクを行うのに十分なコンテキスト ウィンドウがないためでした。検索拡張生成（RAG）などの技術が急速に普及し、モデルに関連するコンテキスト情報を動的に提供できるようになりました。コンテキスト ウィンドウがさらに大きくなり（現在、Gemini 1.5 Pro では最大 200 万トークン）、新しいユースケースを実現する新しい手法が登場しています。

テキストベースの長いコンテキストの新しいユースケースと標準的なユースケースとしては、次のようなものがあります。

  • 大規模なテキスト コーパスの要約
    • 以前のコンテキスト モデルの要約オプションでは、新しいトークンがモデルに渡されるときに、以前のセクションの状態を保持するために、スライディング ウィンドウなどの手法が必要でした。
  • 質問と回答
    • これまではコンテキストの量が限られ、モデルの事実的な再現率が低いため、RAG でのみ可能でした。
  • エージェント ワークフロー
    • テキストは、エージェントがこれまでに行ったことや行うべきことを記録する方法の基盤ですが、実際の状況やエージェントの目標に関する十分な情報がないため、信頼性に限界があります。

多ショット コンテキスト内学習は、長いコンテキスト モデルによって実現される最もユニークな機能の一つです。研究によると、一般的な「シングルショット」または「マルチショット」のパラダイム（モデルにタスクの 1 つまたは数個の例を提示し、それを数百、数千、数十万の例にスケールアップする）を採用すると、新しいモデル機能につながる可能性があります。このマルチショット アプローチは、特定のタスク用にファインチューニングされたモデルと同様のパフォーマンスを発揮することも示されています。Gemini モデルのパフォーマンスが本番環境へのロールアウトにまだ不十分なユースケースでは、マルチショット アプローチを試すことができます。後述の長いコンテキストの最適化のセクションで説明するように、コンテキスト キャッシュを使用すると、この種の入力トークン ワークロードがはるかに経済的に実現可能になり、場合によってはレイテンシがさらに短くなります。

長い動画

動画コンテンツの有用性は、長い間、メディア自体のアクセス性の欠如によって制限されていました。コンテンツの概要をつかむのは難しく、文字起こしでは動画のニュアンスが伝わらないことが多かったためです。また、ほとんどのツールは、画像、テキスト、音声を同時に処理できません。Gemini 1.5 では、長いコンテキストのテキスト機能を、マルチモーダル入力に関する質問を推論して回答する能力に置き換え、パフォーマンスを維持しています。Gemini 1.5 Flash は、100 万トークンを使用して、動画の「干し草の山の中の針」の問題でテストしたところ、コンテキスト ウィンドウでの動画の再現率が 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 は、1 回のリクエストで最大 9.5 時間の音声を受け入れることができます。Gemini 1.5 Pro は、200 万トークンのコンテキスト ウィンドウを使用して、最大 19 時間の音声を受け入れることができます。さらに、15 分間の音声クリップのテストセットでは、Gemini 1.5 Pro の単語誤り率（WER）は約 5.5% でした。追加の入力セグメンテーションや前処理の複雑さがなく、専門的な音声入力モデルよりもはるかに低くなっています。

音声コンテキストの新しい標準的なユースケースとしては、次のようなものがあります。

  • リアルタイムの音声文字変換と翻訳
  • ポッドキャスト / 動画に関する質問と回答
  • 会議の文字起こしと要約
  • 音声アシスタント

音声ファイルによるプロンプトの詳細については、プロンプト ガイドをご覧ください。

長いコンテキストの最適化

長いコンテキストと Gemini 1.5 モデルを使用する場合の主な最適化は、コンテキスト キャッシュを使用することです。これまでは、1 つのリクエストで大量のトークンを処理することができず、コストも大きな制約となっていました。ユーザーが 10 個の PDF、動画、業務用のファイルをアップロードするチャットアプリを使用している場合、従来は、これらのリクエストを処理するために、より複雑な検索拡張生成（RAG）ツール / フレームワークを使用し、コンテキスト ウィンドウに移動されたトークンに対して多額の料金が発生していました。現在では、ユーザーがアップロードしたファイルをキャッシュに保存し、保存料金を時間単位で支払うことができるようになりました。リクエストあたりの入出力コストは標準の入出力コストよりも低いため、ユーザーがデータとチャットすることは、デベロッパーにとっても大きなコスト削減になります。

長いコンテキストの制限

このガイドのさまざまなセクションで、Gemini 1.5 モデルがさまざまな「干し草の山から針を探す」検索に対して高いパフォーマンスを達成する方法について説明しました。これらのテストでは、検出対象が 1 つの針である最も基本的な設定を検討しています。複数の「針」や特定の情報が含まれている場合は、モデルの精度が変わります。パフォーマンスはコンテキストによって大きく異なる場合があります。適切な情報を取得することとコストの間には、本質的なトレードオフがあるため、この点は考慮する必要があります。1 回のクエリで約 99% の精度を得ることができますが、そのクエリを送信するたびに入力トークンの費用を支払う必要があります。100 個の情報を取り出すときに 99% のパフォーマンスが必要であれば、100 個のリクエストを送信する必要があります。これは、コンテキスト キャッシュによって、パフォーマンスを維持しながら Gemini モデルの使用に関連する費用を大幅に削減できる例です。

次のステップ