はじめに
こんにちは。データシステム部・推薦基盤ブロックの上國料（@Kamiko20174481）です。私たちのチームは、ZOZOTOWNの推薦システムを開発・運用し、ユーザー一人ひとりに最適な購買体験を届けることを目指しています。
これまでは施策ごとに推薦システムをゼロベースで構築していたため、施策実施までのリードタイムが長く、推薦システムの運用負荷も高まりやすいという課題がありました。この課題を解決するために、ユーザーや商品をEmbedding（埋め込みベクトル）として表現し、それらを一元的に管理して複数の推薦施策で再利用できる仕組みの構築に取り組みました。以降では、この仕組みをEmbedding基盤と呼称します。
本記事では、この取り組みの背景となった課題とEmbedding基盤の設計方針・アーキテクチャ、導入後の知見を紹介します。同様の課題に取り組む方々の参考になれば幸いです。
目次
- はじめに
- 目次
- 推薦チームが抱える機械学習システムの課題
- Embedding基盤のアプローチ
- Embedding基盤の活用パターン
- Embedding基盤の運用から得た学び
- まとめと今後の展望
- 最後に
推薦チームが抱える機械学習システムの課題
Embedding基盤の説明を始める前に、当時チームが抱えていた推薦システム開発の課題について整理します。
施策のリードタイムが長い
MLベースの推薦システムを開発する際は、モデルの設計や実装に加え、特徴量設計や学習データの整備、モデルの保存・配信、評価指標の設計など、多くの工程が必要になります。我々のチームでは、これらの工程を施策ごとに個別に実装していたため、1つの施策をリリースするまでに数カ月単位の時間がかかることも珍しくありませんでした。
特に課題だったのは、新しい機能に推薦を導入したい場合でも、既存の仕組みをすぐに転用できず準備に多くの時間がかかっていたことです。結果として「仮説を立ててから実際にユーザー反応を確認するまで」に大きなタイムラグが生じていました。
再利用性の不足・重複発生
MLベースの推薦システムは、一度リリースして終わりではなく、継続的な保守・改善が求められます。しかし、同様の目的であっても施策ごとに独立したモデルを構築していたため、以下のような非効率が生じていました。
- 案件ごとに似たような特徴量生成クエリやコードが実装され、車輪の再発明が発生
- 複数のシステムが存在することによるメンテナンス負荷の増大
特に特徴量まわりでは、ほぼすべての案件でBigQueryのデータマートやリアルタイムデータ基盤からユーザー情報・商品情報を取得して生成するという共通パターンが存在します。しかし、各案件でそれぞれ独自にクエリを作成しているため、似たようなクエリが複数の場所に散在するケースが多く見られます。その結果、メンテナンスの行き届かないコードが増えていく構造的な問題が生じていました。
モデルについても同様で、似たようなアルゴリズムや目的を持つモデルのコードが複数存在し、再利用性の低さやモデル管理の煩雑さを招いていました。
今後も推薦システムの数が増加していくことを踏まえると、現状のままでは運用コストが増大していく懸念がありました。
Embedding基盤のアプローチ
以上の課題を踏まえ、Embedding基盤の設計・構築を進めました。
設計方針
Embedding基盤の目的は、学習済みのEmbeddingを共通資産として再利用できるようにすることです。
推薦チームでは、過去に実施したホーム画面のパーソナライズ施策でTwo-Towerモデルを導入し、ユーザーと商品のEmbeddingを生成し、推薦リストの作成に活用しています。
一方で、これらのEmbeddingは特定の施策内でのみ利用されており、他施策から容易に再利用できる仕組みは存在していませんでした。
このため、学習済みのEmbeddingを他施策にも活用できるようにすることで、施策立ち上げの効率化と一定のパーソナライズ効果の維持を実現することを目指しました。
過去のTwo-Towerモデルを活用した施策に関する記事は以下をご参照ください。
Embedding基盤のアーキテクチャ
Embedding基盤では、Two-Towerモデル訓練パイプラインとEmbedding生成パイプラインの2種類のパイプラインで構成されています。以下に全体のアーキテクチャを示します。
まず、右側のTwo-Towerモデル訓練パイプラインでは、ユーザー行動データや商品メタデータを入力として、ユーザーと商品の埋め込み空間を学習します。
Two-Towerモデルは、ユーザー側の特徴を入力とするUser Towerと、商品側の特徴を入力とするItem Towerから構成され、それぞれの出力が同一の埋め込み空間上で近いほど「ユーザーがその商品に関心を持つ可能性が高い」と判断されます。
学習済みのUser TowerとItem Towerは、Vertex AI Model Registryに登録され、後続のEmbedding生成パイプラインで参照されます。
続いて、左側のEmbedding生成パイプラインでは、Model RegistryからUser TowerとItem Towerを取得し、各ユーザー・商品のEmbeddingを生成・保存します。このパイプラインはさらに2つのパイプラインに分かれており、全件更新パイプラインと差分更新パイプラインで構成されています。
| パイプライン名 | 役割 |
|---|---|
| Embedding全件更新パイプライン | 新しいモデルの学習完了時に、すべてのユーザー・商品のEmbeddingを再生成し、BigQueryのモデルバージョン単位のパーティションに書き換える。 |
| Embedding差分更新パイプライン | ユーザー行動の変化を反映するため、直近でアクティブだったユーザーのみを対象にEmbeddingを再生成し、既存パーティションに差分マージする。 |
今回、商品Embeddingは全件更新のみとし、ユーザーEmbeddingのみ差分更新する設計としました。理由は、商品カタログの変化頻度がユーザー行動に比べて低く、コスト対効果の観点で差分更新のメリットが小さいためです。一方でユーザー行動は時間経過で変化しやすいため、差分更新で最新の嗜好を推薦結果に反映しやすくしています。これらのパイプラインはCloud Schedulerで定期実行され、日次で全件更新、時間毎で差分更新する運用としています。
Embeddingの保存先
以上の処理によって生成されたEmbeddingは、用途に応じて複数のストアに保存されます。用途は大きく分けて、オフラインサービングとオンラインサービングの2種類です。
まず、オフラインサービング用途ではBigQueryを採用しました。その理由は以下の通りです。
- スケーラビリティ: ZOZOTOWNのユーザー数・商品数は非常に多いため、大規模データを効率的に保存・クエリできるBigQueryは適している。
- 柔軟なクエリ: BigQuery Vector Searchを活用することで、Embeddingに基づく類似度検索やスコア計算をSQLベースで簡単に実装できる。
- 既存システムとの親和性: 既にZOZOTOWNのデータ分析基盤としてBigQueryを活用しており、既存のデータソースと容易に連携できる。
一方で、BigQueryにはリアルタイム性や低レイテンシの観点で制約があるため、オンラインサービング用途ではVertex AI Vector Searchを採用しました。
商品Embeddingをもとにインデックスを構築・管理することで、リアルタイムな類似商品検索やパーソナライズ検索が可能です。
Embeddingの空間整合性の担保
ここまで、Embeddingを生成・保存する仕組みを説明しました。次に、生成されたEmbeddingの空間整合性をどのように担保しているかについて説明します。
Embeddingの空間整合性とは、Embedding同士が同じ埋め込み空間上で比較可能な状態にあることを指します。今回使用しているTwo-Towerモデルを含め、一般的なEmbeddingモデルでは学習のたびにパラメータが変化するため、再学習すると埋め込み空間の基準軸が変わります。その結果、異なる学習回で生成されたEmbeddingを混在させると、距離計算の基準がずれて正しい類似度を得られなくなるという課題があります。
異なる学習回で生成されたEmbeddingの空間整合性を保つ方法として、前バージョンのEmbeddingを基準に線形変換などを行うアライメント処理も検討可能です。しかしこの手法は、過去との対応関係を継続的に維持する必要があり、ユーザー行動や商品カタログが日々変化するZOZOTOWNのような環境では、安定して整合性を保つのが難しくなる懸念があります。また計算自体は大きな負荷ではありませんが、アンカーサンプル（基準座標）の選定やアライメント後に空間が正しく対応づけられているかを確認する検証作業が必要になり、運用コストが増す可能性もあります。
今回のEmbedding基盤では、こうした懸念よりも「最新モデルのEmbeddingを素早く反映し、施策を高速に回すこと」を優先しました。そのため、アライメント処理で空間を固定するのではなく、モデルのバージョン管理で整合性を担保する設計を採用しています。
これを実現するために、Embedding基盤ではモデルの状態とバージョンを一元的に管理するためのテーブルをBigQuery上に配置しています。
これをManifestテーブルと呼び、モデルの状態遷移とバージョンなどのメタデータを管理しています。
このテーブルではTwo-TowerモデルのUser TowerとItem Towerのモデルバージョンをペアとして扱い、Embedding生成時と取得時にペアを参照することで整合性を保つ仕組みになっています。
各モデルの状態は次の4種類で、Embeddingの生成フローに応じて切り替えています。
| 状態 | 役割 |
|---|---|
| STAGING | 新しいモデルの学習が完了し、これから全件更新にてEmbedding生成に使用される。 |
| ACTIVE | 全件更新にてEmbedding生成が完了し、差分更新にてEmbeddingが更新され続けている状態。常にこの状態は1つだけ存在する。 |
| ARCHIVE | 過去にACTIVEだったモデル。分析や検証用に保持。 |
| UNUSED | 学習済みだがEmbedding生成に使われなかったモデル。 |
新しいモデルが学習を完了すると、まずSTAGING状態として登録されます。その後、STAGINGのペアを参照して全件更新パイプラインでEmbeddingを生成し、完了時にモデルの状態がACTIVEに更新されます。モデルがACTIVEに切り替わる際、それまでACTIVEだったモデルは自動的にARCHIVEに移行します。一方で、Embedding差分更新パイプラインは常に最新のACTIVEモデルペアを参照してEmbeddingの更新を継続します。
この仕組みにより、Embedding生成と利用のタイミングで常に同じモデルペアを参照することが保証されるため、異なる学習回で生成されたEmbeddingが混在することによる不整合を防止できます。また、利用側は常にACTIVEモデルを参照しておけば、モデルのバージョン変化を意識することなく安定した埋め込み空間を利用できるという利点もあります。
Embedding基盤の活用パターン
前章で紹介したように、Embeddingはオフライン用途ではBigQuery、オンライン用途ではVertex AI Vector Searchに保存しています。ここでは、それらの環境を活用し、実際の施策でどのようにEmbeddingを利用しているかを紹介します。
どちらの環境でも、ユーザーや商品のEmbeddingを用いた類似商品検索やパーソナライズ検索が可能です。ただし、施策ごとに求められる処理タイミングやレイテンシ要件が異なるため、オフライン処理とオンライン処理で環境を使い分けています。
バッチ推薦での活用
日次や時間単位でバッチ推薦する際は、BigQueryに保存されたEmbeddingを参照し、類似度計算やランキングを行います。大量の候補商品を扱う場合は、BigQuery Vector Searchを利用することで、SQLベースで効率的に類似度検索し、推薦リストを生成できます。
一方、対象商品が限定されているケースでは、Embeddingを取得して単純な類似度計算だけでも十分対応できます。
リアルタイム推薦での活用
リアルタイム応答が求められる推薦施策では、Vertex AI Vector Searchを利用します。BigQueryと同様にEmbeddingを用いた類似度検索が可能で、ミリ秒単位の低レイテンシ処理を実現できる点が強みです。Embeddingをクエリとして扱うことで、ユーザーや商品の特徴に応じて即時に推薦商品を取得できます。
Embedding基盤の運用から得た学び
Embedding基盤の導入・運用を通じて得られた知見を紹介します。
施策展開のスピード向上
特に顕著な効果は、モデル開発からA/Bテストに至るまでのリードタイム短縮です。
以前は、特徴量設計・学習データ整備・モデル配信・評価設計など多くの工程を経る必要があり、1施策あたり数ヶ月の開発期間を要することもありました。Embedding基盤の導入により、これらの工程の多くを共通化・自動化できるようになり、数週間単位で施策を試せるようになりました。現在では、要件次第で2週間ほどでモデリングが完了するケースも出てきています。
また、Embeddingや推薦モデルを共通管理することで、施策ごとに独立したモデルを構築する必要がなくなり、車輪の再発明を防止できています。
共通の埋め込み空間は便利だが、万能ではない
Embeddingを共通化したことで施策開発のスピードは大きく向上しましたが、一方で、どんな施策にも万能というわけではありません。
空間を共通にしている分、施策毎の出力結果が似通いやすく、特定の目的や文脈に合わせた個性づけが必要になる場面が多くなる懸念があります。
例えば、ある施策では新規ユーザーに対して多様な商品を推薦したい一方で、別の施策では既存ユーザーに対して嗜好に特化した商品を推薦したいとします。共通の埋め込み空間を用いる場合、同じ距離尺度で類似度を計算するため、両者の推薦結果が似通ってしまい、施策ごとの目的に最適化しづらくなる可能性があります。
現在は、共通のEmbeddingをベースにしながら、施策ごとにリランキングや後処理を追加し、最終的な推薦結果を調整するアプローチを採用しています。この方法により、共通Embeddingの利点を活かしつつ、施策ごとの個別最適化も実現しています。
まとめと今後の展望
本記事では、ZOZOTOWNの推薦システムにおけるEmbedding基盤の設計と運用について紹介しました。Embedding基盤の導入により、次のような成果が得られています。
- 施策展開のリードタイム短縮：数ヶ月かかっていた施策開発が、数週間、場合によっては2週間程度で完了するようになった
- 開発コストの削減：Embeddingや推薦モデルを共通管理することで、車輪の再発明を防止し、メンテナンス負荷を軽減
- 柔軟な推薦施策への対応：バッチ処理からリアルタイム検索まで、幅広いユースケースでの活用を実現
一方で、共通の埋め込み空間には限界もあり、施策ごとに目的や文脈が異なる中で最適化が難しいケースも見られました。
現在は、過去の記事でも紹介したカート追加最適化モデルをベースとしたEmbeddingを活用していますが、今後は異なる目的軸（たとえば閲覧最適化モデルや画像ベースのモデルなど）でのEmbedding生成も視野に入れ、多面的な表現空間の構築を検討していきたいと考えています。
最後に
Embedding基盤は、推薦システム開発のスピードと品質を両立する共通インフラとして位置づけています。今後も運用の知見を反映しながら、柔軟で拡張性の高い形へとアップデートを続けていきます。
ZOZOでは、一緒にサービスを作り上げてくれる方を募集中です。ご興味のある方は、以下のリンクからぜひご応募ください。
