独自のクラウド内で再ランキングを実行する

データを外部に残せない環境で運用しているチームは、取得品質に関して繰り返し発生するジレンマに直面しています。最も役立つテクニックはコンポーネントを追加するテクニックであり、追加コンポーネントはすべて境界内でデプロイ、監視、アップグレードする必要があります。

再ランキングは最も明確なケースです。これは通常、利用可能な単一の精度向上の中で最大のものであり、追加のサービスです。

追加しているもの

再ランキング段階は、第 1 段階の検索とモデルの間にあります。候補の最終リストを取得し、事前に計算されたベクトルを比較するのではなく、クエリに対して直接判断して候補を並べ替えます。

運用上、これは独自のリソース プロファイルを持つサービスです。ベクトル検索よりも項目ごとに重く、インデックス全体ではなく小さなセットに適用されます。実行する他のものと同様に、容量、監視、アップグレード パスが必要です。

何が戻ってくるか

二つのことを同時に行うというのは珍しいことだ。

質問に答える文章が 5 番目ではなく 1 番目に来るため、より良い着地が可能になります。

凡庸なパッセージを 10 個渡す代わりに、優れたパッセージを 3 つ渡すことができるため、呼び出しごとのコンテキスト コストが低くなります。独自のコンピューティングに対して料金を支払うセルフホスト型の展開では、その削減はすべての実行に永続的に適用されます。

2 番目の利点は、追加したばかりのコンポーネントのコストを相殺するため、通常は制限された環境での決定を解決することです。

導入前にどう決めるか

何かを組み立てる前に、回収位置を測定してください。正しい文章を含む実際の質問を取り上げ、正しい文章が取得されたかどうか、およびそれがどこにランク付けされているかを記録します。

If it is usually retrieved but ranked low, reranking will help substantially and you can estimate by how much before committing.

If it is usually not retrieved at all, reranking cannot help. The problem is upstream in chunking or embedding, and adding a component will cost capacity and change nothing.

この測定には午後を要し、取得作業で最も一般的な無駄な 4 分の 1 を防ぎます。

キャパシティプランニング

再ランキングの負荷はコーパス サイズではなくクエリ量に比例するため、インデックス自体よりも予測が容易になります。重要な変数は、クエリごとに再ランク付けする候補の数です。

20 人の候補者ではなく 50 人の候補者を再ランク付けすると、コストが高くなり、ほとんどのチームが期待するほど効果がありません。多ければ多いほど良いと考えるのではなく、測定してください。

エアギャップのある環境では

同じ考慮事項が 1 つ追加されて適用されます。リランカーのモデル更新は、他のものと同様に、スケジュール上のアーティファクトとして到着します。更新を受け入れるか拒否するかが飛躍的ではなく慎重な決定となるように、最初に評価セットを構築します。

評価に当てはまるところ

ステージを追加すると、レイテンシー、精度、コストが変化し、3 つすべてが同じスコアに属します。 Oran の評価は、まさにこの理由から、動作、構造、レイテンシー、およびコストの基準をまとめてカバーしています。インタラクティブなレイテンシーの予算を破る精度の向上は、改善ではなくトレードであり、それが行われた瞬間に目に見えるものである必要があります。

次へ

再ランキングと展開のページでは、仕組みと自己ホスト型オプションについて説明します。開発者向けドキュメントでは、この決定を測定可能にする評価セットの構築について説明しています。