はじめに
この記事は ディップ Adbent Calender 2025 の22日目の投稿になります。
こんにちは！ディップ株式会社 でエンジニアをしている澤田です。
現在はバイトルの検索・レコメンド領域に携わっており、バックエンド、機械学習、MLOpsなどの領域に取り組んでいます。
今回は Vertex AI Vector Search 2.0 がプレビューになっていたので、まとめていこうと思います。
これまでの Vector Search とはかなりコンセプトが変わっていたので、参考にしていただけると嬉しいです！
序盤は前提となる要素の説明になりますので、とにかく何が変わったのかを知りたいという方は、「2.0になって変わったこと」からご覧ください。
ベクトル検索
バイトルのようなアルバイト・パートの求人情報サイトにおいて、ユーザの条件がはっきりと定まっているケースは多くありません。そのため、曖昧な検索条件でもぴったりな求人を探せたり、閲覧傾向から求人をおすすめできたりすることがとても重要です。
技術的には、条件やキーワードが一致するかだけではなく、意味や文脈が近いものを検索できるかが重要になります。
そこで登場するのがベクトル検索です。
ベクトル検索は、埋め込み(エンベディング)モデルと呼ばれるモデルで単語、文章、画像などのデータを意味や文脈を持った数値のベクトルへ変換し、そのベクトル同士の類似度などを利用して検索を行う手法です。身の回りの様々なサービスでもこのような技術が利用されていて、RAGなどで文書や画像データを検索・参照する際にも利用されます。
Vertex AI Vector Search
Vertex AI Vector Search は Google Cloud の Vertex AI が提供するベクトル検索サービスです。先ほどの図の「2. ベクトル空間での検索」に該当します。
検索に利用する求人の構造化データとベクトルデータを一緒に保存しておき、フィルタとベクトルのハイブリッド検索を実現することができます。
2.0になって変わったこと
大きな変更点は以下の3点かなと思います。
他にもRerankerの標準装備などもありましたが、今回は下記に絞って説明いたします。
| v1.0 | v2.0 | |
|---|---|---|
| コンセプトの変更 | インデックスとエンドポイント | コレクション |
| サーバレス化 | プロビジョニング | サーバレス |
| 価格モデル | リソースベースのみ | 使用量ベースとリソースベース |
コンセプトとアーキテクチャの変更
従来の Vector Search はビルドとサービングが分かれた設計になっており、以下の手順でリソースを構築していく必要がありました。
- ベクトルデータを生成し、GCSにアップロードする
- バッチ更新 or ストリーミング更新でインデックスを構築する
- インデックス:
- ベクトルの類似度を計算するために使用される構成ファイル
- ベクトルの次元数や検索アルゴリズムなどを指定できる
- インデックス:
- インデックスエンドポイントにインデックスをデプロイする
- インデックスエンドポイント
- APIのエンドポイントとして動作し、受け取った検索クエリに対して適切なインデックスを利用し、検索を行う
- インデックスエンドポイント
Vector Search 2.0 からは、これらが「コレクション」という概念に変わります。開発者はベクトルデータとJSONデータをそのまま Vector Search に格納し、検索エンジンかつデータストアとして利用することができます。
これまでは、フィルタリングに利用する構造化データとベクトルのみを Vector Search に格納しておき、実データは別データベースを参照するという方針を取ることが多かったという印象がありました。
このコンセプトの変更によって、ホップ数が削減され、レイテンシが改善されたり、ベクトルと実データ間のデータの不整合などが発生するケースが軽減されたりすることが期待できそうです。
サーバレス化
従来の Vector Search はプロビジョニングモデルだったため、インデックスをデプロイする際に、以下のような物理的なリソース構成を決める必要がありました。
- マシンタイプ
- シャード数
- レプリカ数
- スケーリング設定
Vector Search 2.0 からは、これがサーバレス化します。開発者は前述したコレクションという論理リソースのみを管理することになります。ただし、サーバレスにはコールドスタート問題などもあるかと思いますので、その辺りは注意が必要です。
価格モデルの追加
従来の Vector Search はリクエストに対する課金ではなく、ノードを稼働させている時間に比例するリソースベースの課金体系でした。
しかし、Vector Search 2.0 では、これに使用量ベースの課金体系が追加されます。これによって、小~中規模なワークロードや開発・テスト環境では使用量ベースの課金にして、大規模かつ定常的に負荷がかかるような本番環境ではリソースベースの課金にするなどのコスト戦略が取りやすくなります。
構築・操作方法
現時点では Vector Search 2.0 をコンソール上で操作することはできませんでしたので、CLIで操作することになります。本記事では詳細な構築・操作方法は割愛いたしますので、詳しくは Google 公式ガイド を参考にしていただければと思います。
curlの例が記載されているのですが、location が us-central1 で固定化されているものが紛れ込んでいるので、試す際は注意していただけると良いと思います。
また別の機会にテストデータを用意して検証を行えればと思っていますので、その際はより詳細な手順を記載できればと思っています 
まとめ
Vertex AI Vector Search 2.0 では少々複雑だったインフラリソースの管理から解放され、アプリケーションの開発に集中できそうですし、データとベクトルを統合して保存できることで、ハイブリッド検索をより手軽に始めることができると感じました。
LLMの活用が重要視されている現代では、データの検索性能はとても重要な要素だと思いますので、そのような開発をされる方々にとって少しでも参考になれれば幸いです。