アプリケーション側でのEmbeddingモデル変更を「設定のみ」で完結させる設計とA/Bテスト基盤
noteでサーバサイドエンジニアをしている露木です。突然ですが皆様、ベクトル検索は活用されているでしょうか?
※ この記事はnote株式会社 Advent Calendar 2025の9日目の記事です。
生成AIの発展により、これまで以上にベクトル検索が注目されるようになりました。ベクトル検索エンジンひとつとってもVespaのような老舗からQdrantやWeaviateといった新勢力も登場し、まさに群雄割拠といったところです。直近ではOpenSearch ServiceがGPUを使ったベクトル検索最適化を発表しました。
ベクトル検索エンジンの発展も早いですが、Embeddingモデルの発展も日進月歩です。TitanのようにAPI経由・従量課金で利用可能なモデルからEmbeddingGemmaのようなローカルで動作可能なモデルまで多様な選択肢があり、ユースケースによって様々なEmbeddingモデルが選択可能です。
このような技術環境においては、その時々の最適解に応じてローコストでEmbeddingモデルならびにベクトル検索エンジンを切り替えられる設計が大事になります。技術の進歩速度とは関係なく、一般論として機能実装のバックエンドを切り替え容易にすることは大事ではありますが、今回はEmbeddingモデル(と理論上はベクトル検索エンジン)を容易に切り替えるための設計について紹介したいと思います。
昨年にBuilders Flashで公開した内容ではTitan Text Embeddingsを利用していましたが、現在は別のモデルを利用しています。今回紹介する設計を活用することで、note.com側は管理画面での設定のみでA/Bテストを開始することができました。
利用側設計の概要
ベクトル検索側について、大まかな設計は以下のようになっています。
note.com と、推薦システムは別のシステムとして独立に運用されています。推薦システムを開発するチームでインフラ運用を賄う必要はありますが、そのぶんアーキテクチャや技術選定の自由度が高まるとともに、開発のリードタイムが大幅に短縮されております。やっててよかった趣味AWS運用。
note.com 内でのベクトル検索を用いた推薦機能は、推薦システム内に構築した推薦APIをコールします。この際、利用するモデルをパラメータに付与します。
推薦APIの側では、モデルのパラメータに応じて利用するベクトルDBを選択できます。今回はどちらもQdrantを利用していたため、モデルに応じてCollectionを変更することで対応が完了しました。
リードタイムを短くするための工夫
概要を見ると普通の設計ですが、リードタイムを短縮するためには既に採用されているソリューションを含めて様々な工夫をしています。
まず、A/Bテストのグループ割り付けですが、以前よりnoteではGrowthBookを用いたA/Bテストの効率化を行なっています。GrowthBookを使うことで、設定画面でグループ設定が完結しました。
グループに応じたAPI呼び出しについては、昨年開催したイベント「10年超えRails開発の振り返りと未来 - 持続可能な開発の具体策」にて紹介したMediaKit(noteの記事詳細ページ等のデータ取得を担うBFF)で実現できています。詳細については下記資料をご参照ください。
MediaKitを使うことで、多くのことが管理画面の設定だけで完結します。推薦機能の開発者として実際にMediaKit内部の機能開発も行い、以下の対応をA/Bテストの前に実施していました。
推薦APIをMediaKitのQueryから呼べるように実装(将来的なモデル切り替えも考慮)
モデルパラメータとA/Bテストのグループを出力に含める
出力結果をログ基盤に送信する
以上の3点を予め用意していたことで、推薦システム側で新しいベクトルDBとパラメータに応じた検索ロジックを用意するだけでnote側は管理画面での設定だけでA/Bテストの実行・検証ができるようになりました。
A/Bテストの結果、新規に採用したEmbeddingモデルのほうが性能的に優れていたため、Titan Text Embeddingsの利用は取りやめました。
Embedding生成側の設計
ベクトル検索を利用するにはEmbedding生成が必要になります。生成側については、大まかな設計は以下のようになっています。
記事投稿を契機にEmbedding生成APIを実行するようになっていますが、その際にAPI側がモデルパラメータによって利用するModel Servingを切り替えるようになっています。
noteではDatabricksを活用しており、Embedding生成のためにMosaic AI Model Servingを活用しています。ローカルで動作するモデルの場合はDatabricksのモデルとして登録すればインフラの用意をすることなくデプロイができますし、BedrockのEmbeddingモデルを利用することも(設定画面を見る限りは)可能です。バックエンドを問わず、統一的にLLMを利用するための基盤としてDatabricksを利用することで、Embedding生成にまつわる煩雑さを減らしつつ、容易にモデルを切り替えられるようにしています。
現状ではオープンなLLMを利用しておりますが、今後再び商用モデルに戻る際であっても大きな設計は崩さずに変更が可能になる見込みです。(この構成にしてからは切り替えが発生していないので、あくまで見込みです)
まとめ
推薦システムの精度向上にはモデルの性能も大事ですが、A/Bテストを通してすばやくフィードバックループを回すことも重要です。
今回の設計により、note側は管理画面での設定だけで検証が可能になりました。Embedding生成についてもDatabricksを活用することで、モデル側の実装に集中することが可能になりました。これにより、エンジニアがコードを書いてデプロイを待つというリードタイムが短くなり、思いついた施策を即座に試せる「実験の高速道路」が敷かれたことになります。
実際にTitan Text Embeddingsから新モデルへの移行判断もスムーズに行えました。今後も新しいモデルや手法が登場するたびに、この仕組みを活用して軽やかに検証を行い、クリエイターの皆様により良い推薦体験を届けていきたいと思います。
▼noteエンジニアアドベントカレンダーはこちら
▼さらにnoteの技術記事が読みたい方はこちら
