【ITニュース解説】Semantic Search on Easy Mode

セマンティック検索は、入力されたキーワードだけでなく、その背後にある「意図」や「意味」を理解して関連性の高い情報を探し出す技術だ。従来の検索システムは、キーワードがデータに直接含まれているかを主な基準としていたため、「ゴーストコメディでビル・マーレイが出ている映画」と検索しても、単に「ゴースト」や「コメディ」という単語が含まれる映画はヒットするかもしれないが、「ビル・マーレイ」という俳優の情報が検索対象のテキストに含まれていない場合、最適な結果（例えば『ゴーストバスターズ』）は得られにくいという課題があった。このようなキーワードマッチング型の検索では、ユーザーの複雑な要求に応えきれないことが多かった。

近年、大規模言語モデル（LLM）や埋め込みモデル（Embedding Model）といった新しい技術が登場し、情報検索の世界に大きな変革をもたらしている。これらのモデルは、単語や文章を数値の並び（ベクトル）に変換する能力を持ち、意味的に近い単語や文章であれば、そのベクトルも近い位置に配置されるように学習されている。この技術を活用することで、キーワードが直接一致しなくても、意味的に関連性の高い情報を検索することが可能になる。これがセマンティック検索の核心部分である。

MongoDB Atlas Vector Searchは、こうした新しい検索技術をデータベースの機能として提供している。当初は、データにベクトル埋め込みを保存し、HNSW（Hierarchical Navigable Small World）という効率的なアルゴリズムを使って類似するベクトルを検索する機能を提供していた。これは多くの開発者の注目を集めたが、その後の経験から、開発者がよりスムーズに、よりコスト効率よくセマンティック検索を構築できるようにするための改善点が明らかになった。

MongoDBはこれに応え、ベクトルの保存効率を高めるbinData表現、大規模なデータに対応するための量子化技術、検索処理を分離してパフォーマンスとコストを最適化する専用検索ノード、そして検索結果の関連性を細かく調整するためのハイブリッド検索演算子など、様々な機能を矢継ぎ早に追加してきた。そして、今回紹介される「イージーモード」を実現する鍵となるのが、「ビューサポート」と「自動埋め込み（auto-embedding）」という二つの新機能だ。これらの機能は、開発者が手間をかけずにセマンティック検索アプリケーションを構築できるようにすることを目的としている。

セマンティック検索を始める際、開発者は「どの部分のデータをベクトルに変換すべきか？」という問いに直面する。一見すると「データ全体」と答えたくなるが、それは常に最適とは限らない。例えば、映画のデータセットを考えてみよう。映画のドキュメントには、あらすじ（plot）、出演者（cast）、タイトル（title）、監督（directors）、公開年（year）といった様々な情報が含まれている。

もし、単純にあらすじだけをベクトルに変換して検索するように設定した場合、「ビル・マーレイ主演のゴーストコメディ」というクエリに対しては、あらすじに「幽霊」や「コメディ」という単語が含まれる映画はヒットするかもしれないが、「ビル・マーレイ」という情報があらすじに含まれていなければ、『ゴーストバスターズ』のような最も関連性の高い結果は上位に来ない。同様に、「1900年代のグレート・トレイン・ロバリー」というクエリでは、あらすじだけではタイトルや公開年といった情報が考慮されず、ユーザーの期待する映画が見つからないという問題が発生する。これは、埋め込みベクトルが、ベクトル化された元のテキストの情報しか持っていないためだ。

この課題を解決するためには、検索対象となるテキストに、より多くの関連する情報を含める必要がある。つまり、あらすじだけでなく、タイトル、出演者、監督、公開年といったメタデータも一緒にベクトル化することが望ましい。しかし、単純にこれらの情報を文字通り結合するだけでは、埋め込みモデルがそれぞれの情報の意味を正しく理解しにくくなることがある。

そこで有効なのが、情報を構造化して結合する方法だ。例えば、「映画タイトル: グレート・トレイン・ロバリー\n\n出演者: A.C. Abadie, ...\n\n公開年: 1903\n\nあらすじ: ...」のように、それぞれの情報に「映画タイトル:」や「出演者:」といった見出しを付けて結合する。このようにすることで、埋め込みモデルは「1900年代」というクエリが「公開年」と関連している、といったように、各情報の意味的な役割をより正確に捉え、より適切なベクトル表現を生成できるようになる。

しかし、このような構造化されたテキストを毎回手動で生成し、外部の埋め込みサービスに送信してベクトルを取得し、データベースに保存するという作業は、開発者にとって大きな負担となる。また、元のデータが更新された場合に、この一連のプロセスを自動で実行することも課題だ。

ここで、MongoDB Atlas Vector Searchの「ビューサポート」と「自動埋め込み」が真価を発揮する。

まず「ビューサポート」とは、既存のコレクション（データ群）から、特定の条件に基づいてデータを抽出したり、形を変えたりして、まるで新しいコレクションであるかのように見せる仮想的な機能だ。このビューを使えば、先ほど説明したように、あらすじ、タイトル、出演者、公開年といった複数の情報を結合し、構造化された一つのテキストフィールド（例えばembedding_sourceという名前）を生成できる。この処理はデータベース内部で行われるため、元のコレクションのスキーマ（データの構造）を汚すことなく、検索のためだけに最適化されたテキストを用意できる。しかも、元のデータが更新されれば、ビューを通じて生成されるテキストも自動的に最新の状態に保たれる。

次に「自動埋め込み」は、このビューで生成されたembedding_sourceフィールドのようなテキストフィールドを、MongoDB Atlasが自動的に埋め込みモデル（例えばVoyage AIのような高性能なモデル）を使ってベクトルに変換し、検索インデックスを作成してくれる機能だ。開発者は外部の埋め込みAPIを呼び出したり、異なるシステムを連携させたりする手間が一切不要になる。クエリ（検索要求）が来た際も、同様に自動でクエリテキストがベクトル化され、生成されたインデックスに対して類似性検索が実行される。

具体的な手順は以下のようになる。

1. メタデータフィールドとあらすじを結合するビューを定義する: MongoDBの集計パイプラインという機能を使って、ビューを定義する。このパイプラインでは、$addFieldsという演算子を使って、既存のフィールドを加工したり、新しいフィールドを追加したりする。例えば、plotやratedフィールドがnullの場合にデフォルト値を設定するといった処理を行う。 次に、再度$addFieldsを使って、embedding_sourceという新しいフィールドを追加する。このフィールドの値は、$concatという演算子を使って、複数の情報を結合して生成する。映画タイトル、出演者、監督、公開年、評価、あらすじといった各情報を、それぞれ「Movie Title:」「Cast:」のようなプレフィックスを付け、\n\n（改行）で区切りながら連結していく。出演者や監督のように複数の値を持つ配列フィールドは$reduceを使って結合し、公開年のような数値フィールドは$toStringで文字列に変換する。この際、空の配列やnull値に対する処理も組み込むことで、データの欠損があっても適切にテキストが生成されるようにする。

2. ビューに対して自動埋め込みベクトルインデックスを作成する: ビューが定義できたら、MongoDB Atlasの管理画面やJSON設定を使って、このビューのembedding_sourceフィールドに対してベクトルインデックスを作成する。設定は非常にシンプルで、使用する埋め込みモデル（例: voyage-3-large）と、ベクトル化したいフィールドのパス（embedding_source）、そしてそれがテキストタイプであることを指定するだけだ。

これらの設定が完了すると、以前の課題だった「ビル・マーレイ主演のゴーストコメディ」や「1900年代のグレート・トレイン・ロバリー」といったクエリに対しても、期待通りの正確な検索結果が得られるようになる。embedding_sourceフィールドにタイトル、キャスト、年といったすべての関連情報が構造化されて含まれているため、埋め込みモデルがユーザーの意図を正確に捉え、意味的に最も近い映画を特定できるのだ。

もちろん、他の技術、例えば各フィールドごとに別々のベクトルを生成して検索したり、検索クエリからメタデータを抽出してフィルターとして利用したりする方法でも同様の結果は得られる。しかし、それらの方法はインデックス作成時のコストが増えたり、クエリ実行時の複雑さが増したり、複数のシステムを連携させる手間がかかったりする。

MongoDB Atlas Vector Searchの「ビューサポート」と「自動埋め込み」を活用する「イージーモード」は、これらの課題を解消し、開発者が最も手軽に、かつ効率的にセマンティック検索機能を実装できる手段を提供する。データベース内でデータの整形からベクトル化、インデックス作成までが完結し、元のデータが更新されれば自動的に検索インデックスも最新の状態に保たれる。これにより、開発者は煩雑なインフラ管理や外部サービス連携に時間を費やすことなく、ユーザーにとって価値のある検索体験の構築に集中できるのだ。