AI エージェント向け: ドキュメントインデックスは https://www.mongodb.com/ja-jp/docs/llms.txt で利用できます。すべてのページの markdown バージョンは、いずれかの URL パスに .md を追加することで利用できます。

自動埋め込みの仕組み

MongoDB Vector Search を構成して、クラスター内のテキストデータの vector embeddings を自動的に生成およびマネージドできます。クラスターに 1 クリックのAIセマンティック検索インデックスを作成し、Voyage AI embedding modelを使用すると、インデックスの作成、更新、ベクトルによるクエリが簡素化されます。

自動埋め込みを有効にすると、 MongoDB ベクトル検索 は、コレクション内の指定されたテキストフィールドのインデックス時に、およびクエリ内のテキスト string に対して、自動埋め込み用にインデックスされたフィールドに対して指定された embedding model を使用して埋め込みを自動的に生成します。

自動埋め込み用のMongoDB ベクトル検索インデックスを作成すると、 MongoDB は最初の同期を実行して、コレクション内のすべての既存のdocumentの埋め込みを生成します。

  1. Scans document.

    MongoDB ベクトル検索 は、インデックス付きテキストフィールドを含むコレクション内のすべてのdocumentをスキャンします。

  2. 埋め込みを生成します。

    各documentについて、 MongoDB ベクトル検索 はインデックス付きフィールドから Voyage AI embedding modelにテキストを送信し、vector embeddingsを生成します。

  3. 埋め込みを保存します。

    MongoDB ベクトル検索 は、生成された埋め込みを同じクラスター上の別の内部システムコレクション(__mdb_internal_search)に保存し、データローカリティを維持しつつ埋め込みをアプリケーションデータから分離します。

  4. インデックスの構築.

    埋め込みが生成されると、 MongoDB ベクトル検索 は生成された埋め込みを使用してインデックスを構築し、ベクトル検索を有効にします。

最初の同期中に、 MongoDB は document をバッチで処理し、特別な Flex 推論プロセシング階層を使用してスループット を最適化します。

注意

最初の同期期間は、document数、 インデックス付きフィールドのテキストの長さ、および利用可能なレート制限割り当てによって異なります。大規模なコレクションの最初の同期が完了するまでに数時間かかる場合があります。

最初の同期後、 MongoDB ベクトル検索 は、変更されるたびに埋め込みをデータと自動的に同期し続けます。

インデックス付きテキストフィールドを含む新しいドキュメントを挿入すると、 MongoDB ベクトル検索 は自動的に次のことを行います。

  1. 変更ストリームを通じて新しいdocumentを検出します。

  2. 構成されたmodelを使用してテキストフィールドの埋め込みを生成します。

  3. 埋め込みを システムコレクションに保存します。

  4. MongoDB ベクトル検索インデックスを更新して、新しい埋め込みを含めます。

documentを更新し、インデックス付きテキストフィールドが変更されると、 MongoDB ベクトル検索 は自動的に次のことを行います。

  1. 変更ストリーム を通じてフィールドの変更を検出します。

  2. 更新されたテキストの新しい埋め込みを生成します。

  3. システムコレクション内の古い埋め込みを置き換えます。

  4. MongoDB ベクトル検索インデックスを新しい埋め込みでアップデートします。

注意

MongoDB ベクトル検索、自動埋め込み用にインデックスされていないフィールドへの更新に対して埋め込み再生成がトリガーされません。

documentを削除すると、 MongoDB ベクトル検索 はシステムコレクションから対応する埋め込みを自動的に削除し、インデックスを更新します。

自動埋め込みでは、マルチテナント環境でMongoDBによってホストおよび管理される Voyage AI の embedding model を使用します。

  • ホストされたサービス: すべての埋め込みモデルはMongoDBによってホストおよび維持されます。デフォルトでは 、モデル推論プラットフォームは、任意のクラウドプロバイダーと地域のMongoDBインフラストラクチャ上で実行されます。各クラスターに対して米国またはヨーロッパへの参照を制限できます。詳細については、「 推論スコープの構成 」を参照してください。モデル インフラストラクチャを配置、設定、または管理する必要はありません。

  • APIベース アクセス: Voyage AI APIキーを使用するように構成された自己管理型配置の場合、 MongoDB は埋め込みを生成するために Voyage AI のAPIエンドポイントにテキストを送信します。埋め込みはMongoDBに返され、クラスターに保存されます。

  • マルチテナント アーキテクチャ: 埋め込みサービスは複数のユーザーで共有されます。このマルチテナント model は、次の機能を提供します。

    • 共有インフラストラクチャによるコスト効率

    • modelの自動更新と改善

    • 高可用性とスケーラビリティ

  • 自動埋め込みサービスに送信されたテキストは、埋め込みを生成するためにのみ使用され、model訓練には保存されたり使用されたりすることはありません。

  • 埋め込みはMongoDBクラスターに返され、独自のデータベース内に保存されます。

  • 自動埋め込みサービスを使用するすべての通信は、暗号化された接続を介して行われます。

埋め込みサービスはマルチテナントです。したがって、 MongoDB はすべてのカスタマー間で均等に使用できるようにするためにレート制限を強制します。レート制限とそれが自動埋め込み操作にどのように影響するかについて詳しくは、「 レート制限 」を参照してください。

自動埋め込みを使用してベクトル検索クエリーを実行すると、 MongoDB はクエリ テキストの埋め込み生成を自動的に処理します。

  1. クエリ テキストの送信:query ステージの $vectorSearchフィールドに、事前に生成されたベクトルではなく、テキスト string を入力します。

  2. 埋め込み生成: MongoDB はクエリテキストを自動埋め込みサービスに送信し、インデックスで指定された同じmodel(または model オプションでオーバーライドする場合は互換性のあるmodel)を使用して埋め込みを生成します。

  3. ベクトル検索: 生成されたクエリ埋め込みは、構成された類似性関数(cosine、dotProduct、またはユークリッド)を使用してインデックス作成された埋め込みを検索するために使用されます。

  4. 返された結果: MongoDB は、クエリに類似する順に順位付けされた document を返します。

自動埋め込みを使用する各クエリは、埋め込みを生成するためにAPI呼び出しが必要であるため、自動埋め込みレート制限にカウントされます。クエリスループットとコストの管理の詳細については、レート制限を参照してください。

  • 大規模なコレクションでは、レート制限に達すると、最初の同期が完了するまでにかなりの時間がかかる可能性があります。

  • MongoDB は失敗した埋め込みリクエストを自動的に再試行し、指数バックオフを実装します。

  • 検索モニタリングを使用して同期の進行状況をモニターできます。

  • documentの更新は、レート制限の対象として、発生に応じて処理されます。

  • 更新がレート制限を超える場合、キャパシティーが利用可能になったときにキューに入れられ、処理されます。

  • アプリケーションは正常に機能し続けます。埋め込み生成のみが遅延する可能性があります。

  • クエリ レート制限は、実行可能な同時検索の数に影響します。

  • クエリ レート制限を超えると、クエリはレート制限を超えたことを示すエラーを返します。

  • 頻繁に使用するクエリ結果をキャッシュする か、スループットを向上させるために 有料階層にアップグレードする ことを検討してください。

自動埋め込みでは、vector embeddings を保存するために別の予約データベースが使用されます。インデックスの生成された埋め込みコレクションを見つけ、生成された埋め込みコレクションから埋め込みを検索できます。

埋め込みストレージ

MongoDB は生成された埋め込みを非同期に保存し、内部的な 生成された埋め込みコレクションに永続化します。この生成された埋め込みコレクションは、同じクラスター上の __mdb_internal_search という名前の専用内部データベースに存在します。クラスター内のすべての自動埋め込みインデックスには、このデータベース内に対応する生成された埋め込みコレクションが 1 つだけ あります 。詳細については、生成された埋め込みコレクション を参照してください。

警告

__mdb_internal_searchデータベースは、 MongoDBによって作成およびマネージドされる予約済みの内部名前空間です。このデータベースまたはそのコレクションは操作 しない でください。この 予約された名前空間を変更すると、インデックスが失敗し、検索結果が一貫性を失う可能性があります。

生成された埋め込みコレクションの構造

生成された埋め込みコレクションには、 ソース コレクションdocumentごとに 1 つのdocumentが含まれます。生成された各埋め込みコレクションdocumentには、ソースと同じ _id、ソースのフィルター フィールドのコピー、および各自動埋め込みフィールドの生成された埋め込みベクトルが含まれます。

次のフィールドが表示されます。

フィールド
タイプ
説明

_id

ObjectId

ソース document と同じ _id 。

<filter-field>

Any

ソースdocumentからフィルターフィールドのコピー。

_autoEmbed

オブジェクト

各 自動埋め込みフィールドの埋め込みベクトルが含まれます。

_autoEmbed.
<fieldPath>

float、または量子化されたベクトルの配列

自動埋め込みフィールドの生成された埋め込みベクトルが含まれます。

警告

__mdb_internal_searchデータベースは、 MongoDBによって作成およびマネージドされる予約済みの内部名前空間です。このデータベースまたはそのコレクションは操作 しない でください。この 予約された名前空間を変更すると、インデックスが失敗し、検索結果が一貫性を失う可能性があります。

生成された埋め込みのコレクションのストレージ サイズを確認することで、生成された埋め込みによるディスクとインデックス スペースの消費を理解できます。これは、キャパシティーの計画、予期せぬ拡大のデバッグ、インデックスの削除または再定義後のクリーンアップの検証に役立ちます。

重要

ストレージサイズを確認する前に、生成された埋め込みコレクションの名前を見つけます。詳細については、「生成された埋め込みコレクションの検索」を参照してください。

次のセクションでは、自動埋め込みに関する一般的な問題をトラブルシューティングするためのガイダンスを提供します。

インデックスIDに一致する埋め込みコレクションは生成されませんでした
インデックスがまだ Building または Pending 状態にある可能性があります。生成された埋め込みコレクションは、最初の書き込み時にレイジーに作成されます。$listSearchIndexes を使用してステータスを確認します。
ソースのdocumentが欠落している _id
指定されたdocumentがまだ生成されていないこと、またはdocumentがインデックスのフィルター式によってフィルタリングされたことの埋め込み。
複数のコレクションがインデックスIDに一致する
自動埋め込みフィールドの構成が更新されました。新しい生成埋め込みコレクションが作成されましたが、古いコレクションはクリーンアップされるまで一時的に存在する場合があります。
インデックスの編集または削除後にディスク使用量が多くなる
インデックス構築プロセスはリソースを多く使用する可能性があり、バックグラウンドのクリーンアップ プロセスがスペースを再利用できるようになるまでに時間がかかる場合があります。ディスク使用量を経時的にモニタリングすることで、スペースが解放される速度を理解するのに役立ちます。
(自己管理型配置のみ)生成された埋め込みコレクション名の形式が変更されました

30年2026月のリリースから、MongoDB ベクトル検索では生成された埋め込み コレクションの命名形式が変更されました。自動埋め込みのプライベート プレビュー バージョンを実行している自己管理型 Community または Enterprise Advanced 配置をアップグレードすると、MongoDB ベクトル検索では既存の自動埋め込み インデックスごとに新しい形式の新しい生成埋め込み コレクションが作成されます。新しいコレクションを作成すると、インデックスの埋め込みが再生成されます。前の生成埋め込み コレクションは孤立しており、自動的にクリーンアップされません。ストレージを再利用するには、孤立したコレクションを手動で削除します。詳細については、孤立した生成埋め込み コレクションを削除するを参照してください。

30 年 2026 月のリリース以降、生成された埋め込みコレクション名は次の形式になります。

<index_id>-<index_definition_hash>-<mv_format_version>-<index_definition_version>

名前には次のコンポーネントが含まれます。

  • <index_id> 自動埋め込みインデックスの ID です。

  • <index_definition_hash> インデックス定義の 16 進数エンコードのハッシュです。

  • <mv_format_version> は、生成された埋め込みコレクション形式のバージョンです。

  • <index_definition_version> インデックス定義のバージョンです。

安定状態では、生成された埋め込みコレクションのみがインデックス ID を持つ指定されます。コレクションを見つけるには、ハッシュまたはバージョン コンポーネントを識別する必要はありません。インデックス ID プレフィックスでインデックスのコレクションを見つけることができます。

(自己管理型配置のみ)生成された孤立型埋め込みコレクションを検索して削除する

自動埋め込みのプライベートプレビューバージョンを実行している自己管理型 Community または Enterprise Advanced 配置を 6 月 30日 2026日のリリースにアップグレードすると、MongoDB ベクトル検索は既存の自動埋め込みインデックスごとに新しい命名形式で新しい生成型埋め込みコレクションを作成します。前の生成型埋め込みコレクションは孤立しており、自動的にクリーンアップされません。ストレージを回収するには、孤立したコレクションを手動で検索して削除します。

コレクションの名前でオーファンのコレクションを識別できます。現在生成された埋め込みコレクション名には、インデックス定義のハッシュとバージョン コンポーネントが <index_id>-<index_definition_hash>-<mv_format_version>-<index_definition_version> の形式で含まれます。プライベート プレビュー バージョンの孤立したコレクションには、インデックス ID のみが名前として付けられます。

警告

__mdb_internal_searchデータベースは、 MongoDBによって作成およびマネージドされる予約済みの内部名前空間です。このデータベースまたはそのコレクションは操作 しない でください。この 予約された名前空間を変更すると、インデックスが失敗し、検索結果が一貫性を失う可能性があります。

1
2

次のプレースホルダーを置き換えた後、次のクエリを実行する。

  • <database_name> - 自動埋め込みインデックスを含むデータベースの名前。

  • <collection_name> - 自動埋め込みインデックスを含むコレクションの名前。

  • <index_name> - 自動埋め込みインデックスの名前。

例: 自動埋め込みインデックスのIDを取得する

use <database_name>db.<collection_name>.aggregate( [ { $listSearchIndexes: { name: "<index_name>" } } ] )
3

<index_id> を、前のステップのコマンドによって返された自動埋め込みインデックスのIDに置き換えてから、次のクエリを実行する。

例: インデックスのコレクションをリストする

use __mdb_internal_searchdb.getCollectionNames().filter(n => n.startsWith("<index_id>"))

インデックスIDのみで名前が付けられたコレクションは、Private Previewバージョンのオーファンコレクションです。ハッシュとバージョンコンポーネントも含まれるコレクションは、現在生成されている埋め込みコレクションです。

4

<orphaned_collection_name>を前の手順で作成した孤立コレクションの名前に置き換えてから、次のクエリを実行する。

例: 孤立したコレクションを削除する

use __mdb_internal_searchdb.getCollection("<orphaned_collection_name>").drop()
このページを評価