自動modelの埋め込み

コンテキスト ウィンドウ サイズ

コンテキストウィンドウは、埋め込みまたは LLM model が 1 回のリクエストで考慮できるテキストの最大量（文字ではなくトークン単位で測定）です。各modelの最大コンテキストウィンドウサイズは次のとおりです。

インデックス付きテキストフィールドがコンテキストウィンドウよりも長い場合、テキストはmodelのコンテキストウィンドウサイズに自動的に切り捨てられます。クエリテキストが**model**のこのコンテキストウィンドウを超えると、$vectorSearchクエリは context-limit-exceeded エラーで失敗します。

modelのコスト

model トークンは、インデックス操作（初めての作成、挿入、更新）やクエリ操作中に消費されます。インデックス操作では、 MongoDB document内の autoEmbed 型としてインデックス付けされたフィールドのみが埋め込み生成に使用され、トークンが使用されます。クエリ操作では、提供されたクエリテキストが埋め込み生成に使用され、トークンが使用されます。各modelのトークンのコストは次のとおりです。

無料トークン

無料トークンはリフレッシュされません。例えば、新しいモデルがリリースされると、レガシーモデルの無料トークンはリセットされません。レガシー モデルの残りの無料トークンを引き続き使用できます。

初回インデックス構築のレート制限

初回インデックス構築レート制限 は、埋め込みが生成されるトークンの最大頻度と数を制限します。次回のインデックス構築（最初の同期）中に大規模なワークロードが発生した場合、自動埋め込みは標準レート制限に拘束されない別の推論メカニズムを使用します。このメカニズムは 最初のインデックス構築 を処理するためにスループットが最適化されており、次のメリットを提供します。

• 最初の同期の高速化: 埋め込み生成のスループットを動的にスケーリングして、大規模なバーストを処理します。

• 無制限のスループット: 利用可能な GPUキャパシティーまでバーストし、手動のレート制限された増加リクエストを排除します。

• 均等なリソース共有:インデックス構築を競合することで、同様のトークン/秒割り当てに集約され、枯渇を回避できます。

• 安全なRAMP: は同時実行性が低い状態で開始され、明示的な内部成功シグナルでのみ動的に増加します。

インデックスの挿入と更新のレート制限

インデックスレートは、 MongoDB ベクトル検索自動埋め込みインデックスの特定の操作中に埋め込みが生成されるトークンの最大頻度と数を制限します。これらの操作には、挿入（新しいデータがインデックスに追加されます）または更新（再埋め込みが必要な既存のデータの変更）が含まれます。

クエリ操作のレート制限

クエリ レート制限は、 MongoDB ベクトル検索自動埋め込みインデックスで $vectorSearch 操作を使用するすべてのクエリの最大埋め込み生成頻度とトークン数を制御します。