LLM 超ロングコンテキストクエリ - 実用的なパフォーマンス評価

大規模言語モデル (LLM) のアプリケーションでは、構造化された方法でデータを提示する必要があるいくつかのシナリオがあり、その代表的な 2 つの例が情報抽出とクエリ分析です。私たちは最近、最新のドキュメントと専用のコード リポジトリによる情報抽出の重要性を強調しました。クエリ分析については、関連ドキュメントも更新しました。これらのシナリオでは、データ フィールドには文字列、ブール値、整数などが含まれる場合があります。これらの型の中で、カーディナリティの高いカテゴリ値 (つまり列挙型) を扱うのが最も困難です。

図

いわゆる「高基数グループ化値」とは、限られたオプションから選択する必要がある値を指します。値は任意に指定できませんが、事前定義されたコレクションから取得する必要があります。このようなセットでは、非常に多数の有効な値が存在することがあります。これを「高カーディナリティ値」と呼びます。このような値の処理が難しい理由は、LLM 自体がこれらの実現可能な値が何であるかを知らないためです。したがって、これらの実現可能な値に関する情報を LLM に提供する必要があります。実現可能な値が少数しかない場合を無視しても、これらの可能な値をヒントに明示的にリストすることで、この問題を解決できます。ただし、考えられる値が非常に多いため、問題は複雑になります。

可能な値の数が増えると、LLM による値の選択の難しさも増します。一方で、可能な値が多すぎると、LLM のコンテキスト ウィンドウに収まらない可能性があります。一方で、考えられるすべての値がコンテキストに適合する場合でも、それらをすべて含めると、大量のコンテキストを処理するときに処理が遅くなり、コストが増加し、LLM 推論能力が低下します。 `可能な値の数が増えると、LLM が値を選択するのが難しくなります。一方で、可能な値が多すぎると、LLM のコンテキスト ウィンドウに収まらない可能性があります。一方で、考えられるすべての値がコンテキストに適合する場合でも、それらをすべて含めると、大量のコンテキストを処理するときに処理が遅くなり、コストが増加し、LLM 推論能力が低下します。 ` (注: 元のテキストは URL エンコードされているようです。エンコードを修正し、書き直したテキストを提供しました。)

最近、クエリ分析の徹底的な研究を実施し、特にその方法に関するページを追加しました。高い基数を扱うため。このブログでは、いくつかの実験的アプローチを詳しく説明し、そのパフォーマンス ベンチマーク結果を提供します。

結果の概要は、LangSmith https://smith.langchain.com/public/8c0a4c25-426d-4582-96fc-d7def170be76/d?ref=blog.langchain.dev でご覧いただけます。次に、詳しく紹介します。

写真

データセットの概要

詳細なデータセットを確認してください。ここ https://smith.langchain.com/public/8c0a4c25-426d-4582-96fc-d7def170be76/d?ref=blog.langchain.dev。

この問題をシミュレートするために、特定の著者によるエイリアンに関する本を見つけたいというシナリオを想定します。このシナリオでは、ライター フィールドはカーディナリティの高いカテゴリ変数です。多くの値が考えられますが、それらは特定の有効なライター名である必要があります。 これをテストするために、著者名と一般的な別名を含むデータセットを作成しました。たとえば、「Harry Chase」は「Harrison Chase」のエイリアスである可能性があります。私たちは、インテリジェントなシステムがこの種のエイリアシングを処理できるようにしたいと考えています。 このデータセットでは、作家の名前と別名のリストを含むデータセットを生成しました。 10,000 個のランダムな名前は多すぎるわけではないことに注意してください。エンタープライズ レベルのシステムでは、数百万単位のカーディナリティを処理する必要がある場合があります。

このデータ セットを使用して、「エイリアンに関するハリー チェイスの本は何ですか?」という質問をしました。クエリ分析システムは、この質問を解析して、件名と著者の 2 つのフィールドを含む構造化フォーマットに変換できるはずです。この例では、予期される出力は {"topic": "aliens", "author": "Harrison Chase"} になります。システムは Harry Chase という名前の著者が存在しないことを認識すると予想されますが、ユーザーが意図したのは Harrison Chase である可能性があります。

この設定を使用すると、作成したエイリアス データセットに対してテストして、実際の名前に正しくマッピングされているかどうかを確認できます。同時に、クエリのレイテンシとコストも記録します。この種のクエリ分析システムは通常、検索に使用されるため、これら 2 つの指標は非常に懸念されます。このため、すべてのメソッドを 1 つの LLM 呼び出しのみに制限します。今後の記事で、複数の LLM 呼び出しを使用したメソッドのベンチマークを行う可能性があります。

次に、いくつかの異なる方法とそのパフォーマンスを紹介します。

写真

完全な結果は LangSmith で確認できます。これらの結果を再現するコードはここにあります。

ベースライン テスト

まず、LLM でベースライン テストを実行しました。つまり、有効な名前情報を提供せずに、LLM にクエリ分析を実行するよう直接依頼しました。予想通り、正解した質問は 1 つもありませんでした。これは、エイリアスによる作成者へのクエリを必要とするデータセットを意図的に構築したためです。

コンテキスト入力方法

この方法では、10,000 件の正式な著者名をすべてプロンプトに入力し、LLM にクエリ分析を実行するよう依頼します。これらが正式な著者名であることを覚えておいてください。一部のモデル (GPT-3.5 など) は、コンテキスト ウィンドウの制限により、このタスクを実行できません。コンテキスト ウィンドウが長い他のモデルの場合も、正しい名前を正確に選択することが困難でした。 GPT-4 は、26% のケースでのみ正しい名前を選択しました。最も一般的なエラーは、名前を抽出しても修正しないことです。この方法は時間がかかるだけでなく、コストも高く、完了までに平均 5 秒かかり、合計 8.44 ドルかかります。

LLM 前のフィルタリング方法

次にテストした方法は、LLM に渡す前に、可能な値のリストをフィルタリングすることでした。この利点は、考えられる名前のサブセットのみを LLM に渡すため、LLM が考慮すべき名前がはるかに少なくなり、クエリ分析をより速く、より安く、より正確に完了できるようになることです。しかし、これにより、新たな潜在的な障害モードも追加されます。最初のフィルタリングが失敗した場合はどうなるでしょうか?

埋め込みベースのフィルタリング方法

最初に使用したフィルタリング方法は埋め込み方法で、クエリに最も類似した 10 個の名前が選択されました。クエリ全体と名前を比較していますが、これは理想的な比較ではないことに注意してください。

このアプローチを使用すると、GPT-3.5 はケースの 57% を正しく処理できることがわかりました。この方法は以前の方法よりもはるかに高速かつ安価で、完了までにかかる時間は平均でわずか 0.76 秒、総コストはわずか 0.002 ドルです。

NGram 類似性に基づくフィルタリング方法

使用する 2 番目のフィルタリング方法は、すべての有効な名前の 3 グラム文字シーケンスの TF-IDF ベクトル化であり、コサインを使用します。ベクトル化された有効な名前とベクトル化されたユーザー入力の間の類似性を調べて、モデル プロンプトに追加する最も関連性の高い 10 個の有効な名前を選択します。また、クエリ全体と名前を比較していますが、これは理想的な比較ではないことにも注意してください。

このアプローチを使用すると、GPT-3.5 はケースの 65% を正しく処理できることがわかりました。また、この方法は以前の方法よりもはるかに高速かつ安価で、完了までにかかる時間は平均 0.57 秒だけで、総コストはわずか 0.002 ドルです。

LLM 後の選択方法

テストした最後の方法は、LLM が予備的なクエリ分析を完了した後にエラーを修正することです。まず、プロンプトに有効な作成者名に関する情報を何も提供せずに、ユーザー入力に対してクエリ分析を実行しました。これは最初に行ったベースライン テストと同じです。次に、著者フィールドの名前を取得し、最も類似した有効な名前を見つけるという後続のステップを実行しました。

埋め込み類似度による選択方法

まず、埋め込み方式による類似性チェックを行いました。

このアプローチを使用すると、GPT-3.5 はケースの 83% を正しく処理できることがわかりました。この方法は以前の方法よりもはるかに高速かつ安価で、完了までにかかる時間は平均 0.66 秒だけで、総コストはわずか 0.001 ドルです。

NGram 類似度に基づく選択方法

最後に、類似性チェックに 3 グラム ベクトル化器を使用してみます。

このアプローチを使用すると、GPT-3.5 はケースの 74% を正しく処理できることがわかりました。また、この方法は以前の方法よりもはるかに高速かつ安価で、完了までにかかる時間は平均 0.48 秒だけで、総コストはわずか 0.001 ドルです。

#結論

高カーディナリティのカテゴリ値を処理するためのクエリ分析手法について、さまざまなベンチマーク テストを実施しました。実際の遅延制約をシミュレートするために、LLM 呼び出しを 1 回だけ行うように制限しました。埋め込み類似性に基づく選択方法は、LLM を使用した後に最もよく機能することがわかりました。

さらにテストする価値のある方法は他にもあります。特に、LLM 呼び出しの前後で最も類似したカテゴリ値を見つける方法は数多くあります。さらに、このデータセットのカテゴリ ベースは、多くのエンタープライズ システムが直面しているほど高くありません。このデータセットには約 10,000 の値がありますが、現実世界の多くのシステムでは数百万のカーディナリティを処理する必要がある場合があります。したがって、より高いカーディナリティのデータでベンチマークを行うことは非常に価値があります。

以上がLLM 超ロングコンテキストクエリ - 実用的なパフォーマンス評価の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。