Gemini のロングコンテキストの使い方
以下の記事が面白かったので、簡単にまとめました。
1. Gemini のロングコンテキスト
「Gemini 1.5 Flash」には100 万トークン、「Gemini 1.5 Pro」には200万トークンのコンテキストウィンドウが付属します。歴史的にLLMは、一度にモデルに渡すことができるテキスト (またはトークン) の量によって大幅に制限されていました。ほぼ完璧な検索 (>99%) を備えた「Gemini 1.5」のロングコンテキストウィンドウにより、多くの新しいユースケースと開発者パラダイムが実現できるようになりました。
2. コンテキストウィンドウとは
「Gemini 1.5」を使用する基本的な方法は、情報 (コンテキスト) をモデルに渡し、その後モデルが応答を生成するというものです。コンテキストウィンドウは短期記憶に似ています。人の短期記憶に保存できる情報量には限りがあり、生成モデルでも同じことが言えます。
3. ロングコンテキストのはじめ方
過去数年間に作成されたほとんどの生成モデルは、一度に8000トークンしか処理できませんでした。新しいモデルでは、32000トークンまたは 128000 トークンを受け入れることで、これをさらに押し進めました。「Gemini 1.5」は100万トークンを受け入れることができる最初のモデルであり、「Gemini 1.5 Proは200万トークンを受け入れることができます。
100万トークンに格納できる情報は、次のとおりです。
・50000 行のコード (1 行あたり標準80文字)
・過去5年間に送信したすべてのテキストメッセージ
・平均的な長さの英語小説8選
・平均的な長さのポッドキャストエピソードのトランスクリプト200以上
小さなコンテキストウィンドウの制限に対処するための一般的な戦略は、次のとおりです。
・新しいテキストの入力時に、コンテキストウィンドウから古いメッセージ/テキストを削除
・コンテキストウィンドウがいっぱいに近づいたときに、以前のコンテンツを要約して置き換える
・RAGをセマンティック検索と組み合わせて使用し、データをコンテキスト ウィンドウからベクターデータベースに移動
・決定論的または生成的なフィルターを使用してプロンプトから特定のテキスト/文字を削除し、トークンを保存
これらの多くは特定のケースでは依然として必要ですが、ロングコンテキストを前提に設計されている「Gemini 1.5」はすべてのトークンをコンテキストウィンドウに配置することからはじめることができます。
たとえば、コンテキスト内で提供される指導資料 (500ページの参照文法、辞書、約400 の追加並列文) のみを使用して、「Gemini 1.5 Pro」と「Gemini 1.5 Flash」は、 英語から Kalamang (話者が200人未満で、オンラインでの存在がほとんどないパプア語) への翻訳を、同じ資料から学習した人と同等の品質で学習できました。
4. ロングコンテキストの使用例
ほとんどの生成モデルの標準的な使用例は依然としてテキスト入力ですが、「Gemini 1.5」は、マルチモーダルの新しいパラダイムを実現します。これらは、テキスト、動画、音声、画像をネイティブに理解できます。利便性のために、マルチモーダルファイルを取り込むGemini APIが付属しています。
4-1. テキスト
LLMの制限の多くは、特定のタスクを実行するのに十分な大きさのコンテキストウィンドウがなかったことに起因しています。このため、モデルに関連するコンテキスト情報を動的に提供する「RAG」やその他の手法が急速に採用されるようになりました。現在、コンテキストウィンドウはますます大きくなり、新しいユースケースを可能にする新しい手法が利用可能になっています。
テキストのロングコンテキストの使用例は、次のとおりです。
・大量のテキストの要約
以前の小規模なコンテキストモデルでの要約では、新しいトークンがモデルに渡されるときに、以前のセクションの状態を保持するためにスライディングウィンドウまたは別の手法が必要でした。
・質問応答
歴史的には、コンテキストの量が限られており、モデルの事実再現率が低いため、これはRAGでのみ可能でした。
・エージェントワークフロー
テキストは、エージェントが何をしたか、何をする必要があるかの状態を維持する方法の基礎です。世界とエージェントの目標に関する十分な情報がないことは、エージェントの信頼性の制限となります。
「Many-Shot In-Context Larning」は、ロングコンテキストモデルによって実現される最もユニークな機能の1つです。研究によると、一般的な「シングルショット」または「マルチショット」の例のパラダイム (モデルにタスクの1つまたは少数の例を提示) を採用し、それを数百、数千、数十万の例にまで拡大すると、新しいモデル機能につながる可能性があります。このメニーショットアプローチは、特定のタスクに合わせてファインチューニングされたモデルと同様に機能することも示されています。「Gemini」のパフォーマンスがまだ実稼働ロールアウトに十分でないユースケースでは、メニーショットアプローチを試すことができます。後で説明するように、「コンテキストキャッシュ」により、このような高入力トークンワークロードが経済的に実現可能になり、場合によってはレイテンシも低くなります。
4-2. 動画
動画コンテンツの有用性は、長い間、メディア自体のアクセシビリティの欠如によって制約されてきました。コンテンツをざっと読むのは難しく、トランスクリプトでは動画のニュアンスを捉えられないことが多く、ほとんどのツールは画像、テキスト、音声を一緒に処理できませんでした。「Gemini 1.5」 では、ロングコンテキストのテキスト機能が、マルチモーダル入力に関する推論と質問への回答を持続的なパフォーマンスで実行できる機能に変換されます。「Gemini 1.5 Flash」は、100万トークンの動画の干し草テスト (長いコンテキストから欲しい情報を見つけ出すテスト) で、コンテキストウィンドウ内の動画の再現率が99.8%を超え、「Gemini 1.5 Pro」はVideo-MME ベンチマークで最先端のパフォーマンスを達成しました。
動画のロングコンテキストの使用例は、次のとおりです。
・動画による質疑応答
・Project Astraで示された動画メモリ
・動画キャプション
・動画推奨システム (既存のメタデータを新たなマルチモーダル理解で強化)
・動画のカスタマイズ (データの集合と関連する動画メタデータの取得、視聴者に関係のない動画の部分の削除)
・動画コンテンツのモデレーション
・リアルタイム動画処理
動画を扱う場合、動画がトークンに処理される方法を考慮することが重要です。これは課金と使用制限に影響します。
4-3. 音声
歴史的に、一般的な開発者ワークフローでは、音声を処理するため、Audio-to-TextモデルやText-to-Textモデルなど、複数のドメイン固有のモデルを連結する必要がありました。複数のラウンドトリップ要求を実行するために必要な追加のレイテンシと、複数モデル設定の分離アーキテクチャに起因するパフォーマンスの低下が発生しました。
音声の干し草テストでは、「Gemini 1.5 Pro」はテストの100%、「Gemini 1.5 Flash」はテストの98.7%で隠れた音声を見つけることができました。1 回のリクエストで「Gemini 1.5 Flash」は最大9.5時間、「Gemini 1.5 Pro」は 最大19時間の音声を受け入れることができます。さらに、15分間の音声クリップのテストセットでは、「Gemini 1.5 Pro」は単語エラー率 (WER) が約5.5%で、追加の入力セグメンテーションや前処理の複雑さを伴わずに、特殊な音声テキスト変換モデルよりもはるかに低い値を達成しています。
音声のロングコンテキストの使用例は、次のとおりです。
・リアルタイムの文字起こしと翻訳
・ポッドキャスト/動画の質疑応答
・会議の記録と要約
・音声アシスタント
5. ロングコンテキストの最適化
ロングコンテキストと「Gemini 1.5」を使用する場合の主な最適化は、「コンテキストキャッシュ」を使用することです。以前は1回のリクエストで多数のトークンを処理できなかったことに加え、もう1つの主な制約はコストでした。ユーザーが10個のPDF、動画、およびいくつかの作業ドキュメントをアップロードしてチャットする場合、複雑なRAGを使用し、コンテキストウィンドウに移動されたトークンに多額の料金を支払う必要がありました。現在は、ユーザーがアップロードしたファイルをキャッシュし、時間単位で保存料金を支払うことができます。たとえば、「Gemini 1.5 Flash」でのリクエストあたりの入出力コストは、標準の入出力コストの約4分の1であるため、開発者にとっては大きなコスト削減になります。
6. ロングコンテキストの制限
「Gemini 1.5」がさまざまな干し草テストで高い性能を発揮することついて説明しました。これらのテストでは、探している「針」が1本しかないという最も基本的な設定を考慮しています。探している「針」が複数ある場合や特定の情報がある場合、モデルは同じ精度を発揮行できません。性能はコンテキストによって大きく異なります。正しい情報を取得することとコストの間にはトレードオフがあるため、この点を考慮することが重要です。1回のクエリで約99%を取得できますが、そのクエリを送信するたびに入力トークンのコストを支払う必要があります。したがって、100個の情報を取得する場合、99%のパフォーマンスが必要な場合は、100回のリクエストを送信する必要があります。これは、コンテキストキャッシュによって、性能を高く保ちながら、「Gemini」の使用に関連するコストを大幅に削減できる良い例です。
7. FAQ
Q. クエリにトークンを追加すると、モデルのパフォーマンスは低下しますか?
A. 一般的に、トークンをモデルに渡す必要がない場合は、トークンを渡さない方がよいでしょう。ただし、何らかの情報を含む大量のトークンがあり、その情報について質問したい場合、モデルはその情報を非常に高い精度で抽出できます (多くの場合、最大 99% の精度)。
Q. Gemini 1.5 Pro は、標準的な干し草テストでどのようなパフォーマンスを発揮しますか?
「Gemini 1.5 Pro」は、最大53万トークンまで 100% のリコール、最大100 万トークンまで99.7% を超えるリコールを実現します。
Q. ロングコンテキストクエリでコストを削減するにはどうすればよいですか?
A. 何度も再利用したい類似のトークン/コンテキストのセットがある場合、コンテキストキャッシュを使用すると、その情報に関する質問に関連するコストを削減できます。
Q. 200万トークンのコンテキストウィンドウにアクセスするにはどうすればよいでしょうか?
A. すべての開発者は、「Gemini 1.5 Pro」で200 万トークンのコンテキストウィンドウにアクセスできるようになりました。
Q. コンテキストの長さはモデルのレイテンシに影響しますか?
A. サイズに関係なく、特定のリクエストには一定のレイテンシがありますが、一般的にクエリが長くなるとレイテンシ (最初のトークンまでの時間) が長くなります。
Q. Gemini 1.5 Flash と Gemini 1.5 Pro ではロングコンテキスト機能が異なりますか?
A. はい、いくつかの数値はこのガイドのさまざまなセクションで説明されていますが、一般的に、ほとんどのロングコンテキストの使用例では、「Gemini 1.5 Pro」の方が性能が優れています。
この記事が気に入ったらサポートをしてみませんか？