文脈ウィンドウ

コンテキストウィンドウとは、モデルが1回の推論シーケンスまたはリクエストで処理できるトークン容量です[1]。

コンテキストウィンドウとは、モデルが単一のリクエスト中に使用する作業スペースです。通常、トークンで測定され、これは小さなテキストの断片です。製品は、モデルが答えを生成する前に、ユーザーのメッセージ、システムの指示、例、取得されたセクション、会話履歴、ツールの結果、出力制約などをそのスペースに配置します。

コンテキストウィンドウはメモリと同じではありません。会話履歴は、製品がその履歴をモデルコンテキストに戻す場合にのみ、現在のリクエストに影響します。製品のメモリ、保存されたユーザーのプリファレンス、検索、およびコンテキストウィンドウは、別々のメカニズムであり、製品がそれらを1つのインターフェースで組み合わせても同じです。

文脈ウィンドウは、1回のインタラクションでモデルが使用できる内容を形作ります。ユーザーが短い契約書を貼り付けると、モデルはドキュメント全体と質問の両方を収められるかもしれません。ユーザーが長いノートのフォルダーを貼り付けると、製品は切り捨て、要約、選択されたチャンクを取得、または入力の一部を拒否する必要があるかもしれません。

これは、情報がチャットで以前に表示された場合、モデルがそれを保持していると人々が仮定するため重要です。これは誤っている可能性があります。製品には、最近のメッセージ、要約、選択された記憶、検索されたドキュメント、またはまったく過去のコンテキストが含まれていない場合があります。表示されるチャットスレッドは、モデルに送信された正確なコンテキストであるとは限りません。

これは、より大きなコンテキストウィンドウがすべての詳細を適切に使用することを保証しないことも重要です。MiddleのLost studyでは、評価された言語モデルとタスクが長文の入力コンテキストでの関連情報の位置に敏感であることが判明しました。関連情報が中央に表示される場合、パフォーマンスは通常悪化しました [2]。この結果は、研究されたシステムとタスクに帰属すべきであり、すべてのモデルが常に中央を無視するという普遍的な主張に転じてはなりません。

生成の前に、アプリケーションはリクエストを構成します。そのリクエストには、システムレベルの指示、ユーザーのメッセージ、製品によって選ばれた会話履歴、例、検索されたセクション、ツールの出力、フォーマットルールなどが含まれる場合があります。その後、モデルはその構成されたコンテキスト内のトークンを処理し、出力として新しいトークンを生成します。

入力と出力の制限は製品とモデルの実装の詳細です。一部のシステムでは、入力トークンと生成された出力が1つの合計容量を共有します。他のシステムでは、ドキュメンテーションに個別の入力と出力の制限が記載されているかもしれません。概念記事は、ある割り当てルールをすべての製品で普遍的であると提示してはなりません。

アセンブリされたコンテキストが大きすぎる場合、アプリケーションはどのようにするかを決定しなければなりません。古いメッセージを削除したり、要約したり、選択されたセクションのみを取得したり、ユーザーに入力を短縮するように求めたり、タスクを小さなリクエストに分割したりする可能性があります。それぞれの選択は、モデルが使用できる証拠に影響を与えます。

学生がAIアシスタントに3つの記事を比較するように依頼する想像をしてください。最初の記事は短く、2番目の記事は長く、3番目の記事は長時間の会話の後に貼り付けられます。製品にはユーザーの要求、いくつかのシステム指示、会話履歴の一部、および記事のテキストが含まれるかもしれません。総数が大きすぎる場合、古いトーンが削除されるか、要約が使用されるかもしれません。

良いワークフローはこれを明確にします。生徒は、「どのソースを使用しましたか？」と尋ね、答えが実際に3つの記事すべてを引用しているかを確認できます。文脈から1つの記事が欠けている場合、答えはモデルが受け取った資料だけを反映しているにもかかわらず、完全に聞こえる可能性があります。

最大の誤解は、コンテキストウィンドウがメモリを意味すると考えることです。メモリは、製品が情報を保存し、後で再び取り出せるという意味です。コンテキストウィンドウは、1回のリクエストの容量を指します。製品が別途プリファレンスや要約を保存する場合もありますが、その情報が生成に影響を与えるのは、製品がそれを現在のコンテキストに挿入した場合に限ります。

もう一つの誤解は、コンテキストウィンドウ内のすべての情報が均等に注意深く扱われ、信頼性があるということです。モデルは、特に長く複雑で、または矛盾するコンテキストでは、情報を見逃したり、希薄にしたり、誤って適用したりする可能性があります。リクエストに含まれていることは、正しく使用されていることを意味しないのです。

長いコンテキストは大規模なドキュメント、マルチステップタスク、より豊かな例に役立ちますが、リスクも生じます。ユーザーが必要な以上の機密データを貼り付ける可能性があります。取得されたセクションには古くなったまたは敵対的なテキストが含まれる可能性があります。長い入力は、誰かがどの証拠が答えを導いたのかを確認するのが難しくなる可能性があります。

NISTはジェネレーティブAIリスクを、設計、使用、モニタリング、評価を含むライフサイクルリスクとして扱っています[3]。コンテキストウィンドウの場合、チームは製品が含むもの、捨てるもの、長時間の入力をどのように扱うか、ユーザーが限界を理解しているかをテストする必要があります。

長文のコンテキストからの答えに頼る前に、尋ねてください：実際に含まれたドキュメントやメッセージはどれですか？何かが要約または省略されましたか？答えは、重要な主張を支持する正確なセクションを引用していますか？機密データが含まれている可能性がありますか？古いメッセージや検索されたドキュメントにタスクと矛盾する指示が含まれている可能性がありますか？

読み取り、比較、提供された資料からの原稿作成、タスクの一貫性を保つために、長文のコンテキストを使用してください。ポリシー、法務、医療、金融、雇用、顧客、セキュリティの決定に影響を与える場合は、遅くしてください。より大きなコンテキスト窓はモデルに多くの証拠を提供しますが、自動的な正しさを保証するものではありません。