自動埋め込みでは、Atlas がマルチテナント環境の Data Plane でホストおよびマネージドする Voyage AI の embedding model を使用します。
サポートされているmodel
自動埋め込み は、次の Voyage AI embedding modelsをサポートしています。
埋め込みモデル | 説明 | 1M トークンあたりの価格 |
|---|---|---|
| 大規模でコストのかかるアプリケーションに最適化されます。 | $0.02 |
| (推奨)一般的なテキスト検索のバランスの取れたパフォーマンス。 | $0.06 |
| 複雑なセマンティック関係の最大精度。 | $0.12 |
| コード検索と技術ドキュメントに特殊化されています。 | $0.18 |
コンテキスト ウィンドウ サイズ
コンテキストウィンドウは、埋め込みまたは LLM model が 1 回のリクエストで考慮できるテキストの最大量(文字ではなくトークン単位で測定)です。各modelの最大コンテキストウィンドウサイズは次のとおりです。
埋め込みモデル | コンテキスト ウィンドウ サイズ |
|---|---|
| 32,000 tokens |
| 32,000 tokens |
| 32,000 tokens |
| 32,000 tokens |
インデックス付きテキストフィールドがコンテキストウィンドウよりも長い場合、テキストはmodelのコンテキストウィンドウサイズに自動的に切り捨てられます。クエリテキストが**model**のこのコンテキストウィンドウを超えると、$vectorSearchクエリは context-limit-exceeded エラーで失敗します。
modelのコスト
model トークンは、インデックス操作(初めての作成、挿入、更新)やクエリ操作中に消費されます。インデックス操作では、 MongoDB document内の autoEmbed 型としてインデックス付けされたフィールドのみが埋め込み生成に使用され、トークンが使用されます。クエリ操作では、提供されたクエリテキストが埋め込み生成に使用され、トークンが使用されます。各modelのトークンのコストは次のとおりです。
埋め込みモデル | Cost per 1K Tokens | 1M トークンあたりのコスト |
|---|---|---|
| $0.00012 | $0.12 |
| $0.00006 | $0.06 |
| $0.00002 | $0.02 |
| $0.00018 | $0.18 |
無料トークン
各modelに対して、Atlas には組織レベルで 20000 万の無料トークンの 1 回限りの割り当てが含まれています。組織は、組織内のすべての Atlas プロジェクトとクラスターで無料トークンを共有します。
各modelに対して、 MongoDB ベクトル検索 には 200 万の無料トークンの 1 回限りの割り当てが含まれています。無料トークンは、配置内のすべてのクラスターで共有されます。
無料トークンは更新されません。
レート制限
レート制限は、指定された期間内に自動埋め込みからリクエストできるトークンの頻度と数に対する制限です。MongoDB は、マルチテナント環境内のすべてのユーザー間での均等な使用を確保するために、埋め込み生成にレート制限を強制します。レート制限は、1 分あたりのリクエスト数(RPM)と 1 分あたりのトークン数(TPM)に基づいています。これらのレート制限はMongoDBクラスター レベルで適用され、自動埋め込みを使用してそのクラスター上のすべてのインデックス間で共有されます。より高いレート制限をリクエストには、 MongoDBアカウントチームに問い合わせるか、 MongoDBサポートにお問い合わせください。
レート制限は、クエリ、初回インデックス構築、インデックス更新操作(documentの挿入と更新)に個別に適用されるため、 トラフィック分離が提供されます。インデックス構築操作は、リアルタイムクエリトラフィックから厳密に分離されます。
初回インデックス構築のレート制限
初回インデックス構築レート制限 は、埋め込みが生成されるトークンの最大頻度と数を制限します。次回のインデックス構築(最初の同期)中に大規模なワークロードが発生した場合、自動埋め込みは標準レート制限に拘束されない別の推論メカニズムを使用します。このメカニズムは 最初のインデックス構築 を処理するためにスループットが最適化されており、次のメリットを提供します。
最初の同期の高速化: 埋め込み生成のスループットを動的にスケーリングして、大規模なバーストを処理します。
無制限のスループット: 利用可能な GPUキャパシティーまでバーストし、手動のレート制限された増加リクエストを排除します。
均等なリソース共有:インデックス構築を競合することで、同様のトークン/秒割り当てに集約され、枯渇を回避できます。
安全なRAMP: は同時実行性が低い状態で開始され、明示的な内部成功シグナルでのみ動的に増加します。
インデックスの挿入と更新のレート制限
インデックスレートは、 MongoDB ベクトル検索自動埋め込みインデックスの特定の操作中に埋め込みが生成されるトークンの最大頻度と数を制限します。これらの操作には、挿入(新しいデータがインデックスに追加されます)または更新(再埋め込みが必要な既存のデータの変更)が含まれます。
モデル | 1 分あたりのリクエスト数(RPM) | 1 分あたりのトークン数(TPM) |
|---|---|---|
| 2,000 | 3,000,000 |
| 2,000 | 8,000,000 |
| 2,000 | 16,000,000 |
| 2,000 | 3,000,000 |
クエリ操作のレート制限
クエリ レート制限は、 MongoDB ベクトル検索自動埋め込みインデックスで $vectorSearch 操作を使用するすべてのクエリの最大埋め込み生成頻度とトークン数を制御します。
モデル | 1 分あたりのリクエスト数(RPM) | 1 分あたりのトークン数(TPM) |
|---|---|---|
| 3 | 2,000 |
| 3 | 2,000 |
| 3 | 2,000 |
| 3 | 2,000 |
ベストプラクティス
レート制限内でパフォーマンスを最適化するには:
可能な場合は、データが入力されたコレクションにインデックスを作成します。初めてのインデックス構築(最初の同期)には、スループットに上限のない特別な推論メカニズムのメリットが得られます。したがって、インデックスを作成する 前に、コレクションに事前にデータを入力することをお勧めします。
バッチ更新: 一括更新を実行している場合は、オートメーション埋め込み ダッシュボードの Usage ページでインデックス更新のスループットをモニターし、レート制限に達しないようにスペースを入れます。
使用状況をモニター: 自動埋め込みダッシュボードの Usage ページで埋め込み生成を追跡し、パターンを特定し最適化します。
必要なときにアップグレードする: 一貫してレート制限に達した場合は、より高い割り当ての支払い方法を追加するか、より高いレート制限を利用するにはMongoDBアカウントチームにリクエストすることを検討してください。