LLM as a Judge とは、AI・エージェントの回答品質を自動的に評価する手法の一つで、大規模言語モデル（LLM）を「評価者」として活用し、人手による評価コストを大幅に削減しながら、一貫した基準で大量のテストケースを継続的に評価する方法です。 現在、生成AI（LLM）を自社の業務プロセスや自社プロダクトへ組み込む企業が急速に増えています。しかし、検証を進める中で多くの開発現場が直面するのが「AIの品質管理（QA）の難しさ」という壁です。 AIが出力する結果の妥当性をどう判断し、どのように安定性を担保すればよいのか。本記事では、ドットデータ社が自社製品「 dotData Insight 」などの開発プロセスで検証してきた内容をもとに、AIがAIを自動評価するアプローチ「LLM as a Judge」の基本的な仕組みや考え方について解説します。 なぜAIの品質管理は難しいのか AIプロダクトの品質管理では、従来のソフトウェアテストをそのまま適用してもうまくいきません。理由は以下の通りです。 正解が一つではない 従来のソフトウェア開発（決定的） ：1+1=2のように期待出力の仕様が明確であり、入力に対して出力が常に同じになります。このため 「一つの期待される出力（Expected）」と「実際の出力（Actual）」が完全一致するかどうか を機械的に判定することで、評価できます。 AIエンジニアリング（非決定的） ：同じ入力であっても、モデルの確率的な挙動によって出力が毎回変わり、出力が完全一致することは少ないです。正解は無数にあり、判定は「出力が妥当であるか」という評価が必要です。 仕様の曖昧さと組み合わせの爆発 「分かりやすい原因仮説を考えて出力して欲しい」といった曖昧な仕様による挙動が存在します。さらに、ユーザーとの対話プロセス（コンテキストの積み重ね）が加わることで、出力パターンは無数に広がり、組み合わせの爆発が起こります。これを人間がすべて網羅してテストすることはできません。 ハルシネーションと「80点の壁」 一見それらしく見えるもっともらしい誤情報（ハルシネーション）を出力することがあります。開発の初期段階で「なんとなく動く80点レベル」のプロトタイプを作るのは容易ですが、そこから製品・実業務レベルへ品質を引き上げ、モデルのアップデート時にも品質を維持し続けること（「80点の壁」の突破）が容易ではありません。 LLM進化への追従 近年のAIの進化の速度は非常に早く、日々、コストや性能が異なるモデルがリリースされ続けています。モデルのアップデートも頻繁に行われるため、新しいモデルごとにAIの品質を人手でチェックしていては時間とコストの面で追いつきません。 LLM as a Judgeとは何か LLM as a Judgeとは、出力を生成するAIとは別に評価専用のAIを用意し、AIの品質評価を自動化する方法です。 基本的な流れは次の通りです。 機能AIが、入力データやユーザー指示に対して出力を生成する 評価AIが、評価基準（ルーブリック）と評価データセットを参照する 評価AIが、機能AIの出力を採点し、理由やコメントを返す 開発チームが、スコア、コメント、ばらつきを見て品質を判断する 必要に応じて、プロンプト、モデル、評価基準、評価データセットを改善する この方法を使うと、人間がすべての出力を個別にレビューする代わりに、評価AIが大量のテストケースを一貫した基準で評価できます。また、モデルを変更した場合も、同じ評価基準で比較できるため、継続的なAI品質管理に活用できます。 ただし、LLM as a Judgeで重要なのは「評価AIに任せること」ではありません。人間が何を良い出力とみなすのかを定義し、その基準を評価AIが再現できるようにすることです。 LLM as a Judgeを機能させる3つの要素 LLM as a Judgeを品質管理の仕組みとして使うには、評価基準、評価データセット、評価AIの3つをセットで設計する必要があります。 要素 役割 設計時のポイント 評価基準 何を良い出力とみなすかを定義する 合否で判定する条件を実例とともに精緻に設計する 評価データセット 評価対象となる入力、期待される出力例、望ましくない出力例を用意する Good例、Bad例、グレーケースを含める 評価AI ルーブリックに基づいてAI出力を評価する 評価理由を返し、複数回評価でばらつきも確認する 評価基準だけがあっても、評価対象となるデータが不十分であれば品質は測れません。反対に、テストデータだけを増やしても、何を基準に合否やスコアを判断するかが曖昧であれば、評価結果は安定しません。 LLM as a Judgeでは、評価基準と評価データセットを整合させ、評価AIがその基準を再現できているかを確認しながら運用することが重要です。 評価基準の設計 LLM as a Judgeの精度を左右するのが、評価基準（ルーブリック）です。ルーブリックとは、出力が満たすべき品質条件を具体的に定義したものです。 ルーブリックは、ハードルールとソフトルールに分けて設計すると整理しやすくなります。 種類 役割 判定方法の例 ハードルール 出力が必ず満たすべき条件を定義する OK/NGで判定する ソフトルール 主観や曖昧性を含む品質を評価する 0〜3点などの段階スコアで評価する ハードルールは最低限の合格条件を定義する ハードルールは、出力が満たすべき絶対条件です。条件を満たしていない場合、どれほど自然な文章に見えても品質上はNGと判断します。 dotData Insightのカラムエンリッチ機能を例に考えます。カラムエンリッチ機能とは、与えられたデータに対して、四則演算により分析に役立つ新しい特徴量を自動設計・抽出する機能です。 たとえば、ローン申請データに次のような列があるとします。 年齢 性別 年収 ローン金額 支払期間（月数） この入力に対して、AIが「返済負担率」という追加カラムを提案する場合、次のような出力が考えられます。 項目 例 カラム名 返済負担率 算出方法 （ローン金額 / 支払期間（月数）） x 12 / 年収 x 100 解説 収入に対して、年間のローン支払い金額がどの程度の割合を占めるかを表す値です。 このとき、数式として計算できるだけでは十分ではありません。ビジネス的、物理的に意味が通るかを評価する必要があります。 ハードルールの例は次の通りです。 評価項目 判定基準 OK/NGの考え方 単位の整合性 計算自体は可能でも、ビジネス的・物理的に無意味な数式になっていないこと 「売上合計 / 来店者数」は来店者あたり売上として解釈できるためOK。「周波数 / 電圧」は業務指標として意味が説明できなければNG 定数の妥当性 計算式に登場する定数に直感的な解釈があり、不要な数値が混入していないこと 為替レートの近似値としての定数は説明できる場合がある。一方、理由のない +1 はNGになりやすい ハードルールでは、評価AIが迷わないように、何を満たせばOKで、何があればNGなのかを明確にします。 ソフトルールは曖昧な品質をスコア化する 一方で、AI出力の品質には、完全なOK/NGで判定しにくい観点もあります。たとえば、提案されたカラム名が「直感的に理解しやすいか」は、一定の主観を含みます。 このような品質は、段階的なスコアで評価します。 例として、次の数式に対するカラム名を評価します。 （ローン金額 / 支払期間（月数）） x 12 / 年収 x 100 スコア 評価 カラム名の例 判定基準 3点 Perfect 返済負担率 計算式の意味を正確に表し、業務担当者にも直感的に伝わる 2点 Good ローン・年収比率 概ね妥当だが、やや抽象的で説明を補う余地がある 1点 Poor 返済インデックス 計算式の意味を推測しにくい 0点 Failure 年間支払利息 計算式の説明として誤っている ソフトルールでは、単に点数を付けるだけでなく、なぜその点数になるのかを説明できる基準が必要です。評価が割れやすいケースを蓄積し、どのような場合に2点と3点を分けるのかを具体化していくことで、ルーブリックの品質が上がります。 評価データセットの作り方 評価データセットは、ルーブリックに沿って評価するための材料です。LLM as a Judgeでは、入力データだけでなく、期待される出力例や望ましくない出力例もセットで準備します。 基本構成は次の3つです。 入力データ: AIへ与える入力 Good例: 期待する出力例 Bad例: 避けたい出力例 カラムエンリッチ機能の例では、次のような評価データセットを用意できます。 項目 例 入力データ ローン申請テーブル（年齢、年収、申請額、支払期間（月数）） Good出力例 カラム名: 毎月支払額。計算式: 申請額 ÷ 支払期間（月数）。解説: ローン金額を支払期間で割ることで算出される月々の返済額。返済負担を把握するのに有用。 Bad出力例 カラム名: 一人当たり所得。計算式: 年収 ÷（子どもの数 + 1）。解説: 本人および子どもを含めた1人当たりの所得。 テストケースは、代表的なケースとエッジケースだけでは不十分です。LLM as a Judgeでは、グレーケースを含めることが重要です。 ケース 内容 目的 代表的なケース 実務で頻繁に出る標準的な入力 基本品質を確認する エッジケース 極端な入力、境界条件、例外的なパターン 想定外の破綻を見つける グレーケース 人間でも判断が分かれやすい入力や出力 評価基準の曖昧さを発見する グレーケースは、評価基準を改善するための重要な材料です。たとえば、「正確だが専門的すぎる」「分かりやすいが厳密さに欠ける」といった出力は、単純なOK/NGでは扱いにくいものです。こうしたケースを蓄積し、人間のレビュー結果と照らし合わせながらルーブリックを更新することで、評価AIの判断を安定させやすくなります。 評価の実行と結果の見方 評価AIは、ルーブリックと評価データセットを使って、機能AIの出力を採点します。評価結果では、スコアだけでなく、評価理由やコメントも確認します。 たとえば、カラムエンリッチ機能に対する評価結果は、次のような形で整理できます。 指標 Run1 Run2 Run3 平均 標準偏差 ハードルール達成率 100% 100% 100% 100% 0.0 解釈性（0〜3点） 3 2 3 2.7 0.5 説明文品質（0〜3点） 3 2 2 2.3 0.6 総合スコア（100点） 95 89 94 92.7 3.2 この結果を見るときは、平均スコアだけで判断しないことが重要です。ばらつきが大きい場合、プロンプト、ルーブリック、評価データセットのどこかに曖昧さが残っている可能性があります。 評価コメントも重要です。たとえば、次のようなコメントが返ると、改善すべき箇所が見えやすくなります。 ハードルールはすべて満たしており、数式としての妥当性に大きな問題はない カラム名は概ね適切だが、「返済負担率」と「ローン・年収比率」のどちらを高く評価するかで判定にばらつきがある 説明文に曖昧な表現があり、ルーブリックで説明文品質の基準を追加する余地がある LLM as a Judgeの評価結果は、合否を機械的に決めるためだけのものではありません。どの品質観点が安定しており、どの品質観点に改善余地があるのかを把握するための材料です。 評価は1回ではなく統計的に行う 生成AIは非決定的に動作します。同じ入力でも、プロンプト、モデル設定、文脈の違いによって出力が変わることがあります。評価AIも同様に、曖昧なケースでは評価が揺れる可能性があります。 そのため、LLM as a Judgeでは、一度だけの評価スコアで品質を判断せず、複数回実行した結果を見ます。 確認すべき観点は次の通りです。 平均スコア: 品質水準がどの程度か 標準偏差や分散: 評価や出力がどの程度安定しているか ハードルール違反の有無: 最低条件を満たしているか 評価コメントの傾向: どの観点で改善が必要か 人間レビューとの一致: 評価AIが人間の判断を再現できているか ばらつきが大きい場合、機能AIの出力が不安定なだけでなく、評価基準自体が曖昧である可能性もあります。この場合は、出力側だけでなく、ルーブリックや評価データセットを見直す必要があります。 評価AIにはより高性能なモデルを使う LLM as a Judgeでは、評価AIに機能AIよりも推論能力の高いモデルを使うことが推奨されます。理由は、評価そのものの精度が、改善サイクル全体の品質を左右するためです。 機能AIは、ユーザー向けの応答速度やコストの制約を受けます。一方、評価AIは開発・検証環境でバックグラウンド実行されることが多く、多少時間がかかっても高精度な判断を優先しやすい領域です。 評価AIに期待する役割は、単に点数を返すことではありません。次のような判断を行う必要があります。 ルーブリックの各項目に照らして、どこが満たされているか 出力のどの部分が評価に影響したか どの品質観点で改善余地があるか 人間レビューが必要なグレーケースか 評価AIの品質を確認するには、人間が評価した結果（Golden Set）との一致率や相関を定期的に見ることが有効です。評価AIが人間の判断からずれている場合は、評価プロンプト、ルーブリック、データセットのいずれかを改善します。 LLM as a Judge導入時の注意点 LLM as a Judgeは便利な仕組みですが、設計を誤ると、品質管理の精度を高めるどころか、誤った安心感につながることがあります。導入時には、次の点に注意が必要です。 注意点 内容 対応策 ルーブリックが曖昧 評価AIが判断基準を安定して再現できない OK/NG例、スコア別基準、グレーケースを追加する 評価データが偏る 実運用で出る入力を十分にカバーできない 代表ケース、エッジケース、失敗事例を継続的に追加する 評価AIを過信する 評価AI自身の誤判定を見落とす Golden Setとの一致率を確認し、人間レビューを残す スコアだけを見る 改善すべき品質観点が分からない 評価理由、コメント、ばらつきを併せて確認する 生成と評価を同じプロンプトに詰め込む 自己評価のバイアスや文脈負荷が起きやすい 機能AIと評価AIの役割を分ける 特に、機能AI自身に自己評価させるだけでは不十分な場合があります。生成と評価を同じプロンプト内で行うと、AIが自身のミスを見落としやすくなります。また、生成と評価の指示が混在することで、どちらの精度も下がる可能性があります。 LLM as a Judgeでは、機能AIと評価AIの役割を分け、評価AIにはルーブリックに沿った判断をさせることが基本です。 dotData Insightの開発における品質管理との関係 dotDataでは、dotData Insightなどの開発プロセスにおいて、生成AIを活用した機能の品質管理を検証してきました。dotData Insightは、業務部門がデータからインサイトを導くためのデータ分析プラットフォームです。業務データから隠れたパターンを抽出し、生成AIが分析結果のビジネス解釈や要因仮説の設計を支援します。 このような機能では、出力が単に文法的に自然であればよいわけではありません。業務上の意味が通っているか、データから導ける内容になっているか、利用者が次の判断に進める説明になっているかを確認する必要があります。 LLM as a Judgeの考え方は、こうしたAI機能の品質を継続的に検証するうえで有効です。評価基準を定義し、評価データセットを整備し、評価AIで出力を確認することで、AI機能の改善サイクルを回しやすくなります。 生成AIを活用したデータ分析や、自社のデータ活用・DX戦略に関心がある場合は、dotData Insightの製品情報や業界別ソリューションも参考になります。 dotData Insight 製品ページ 業界別ソリューション・導入事例 まとめ LLM as a Judgeは、生成AIの出力を評価するために、評価専用のAIを使う品質管理の方法です。AIがAIを評価する仕組みではありますが、評価の出発点は人間が定義する品質基準にあります。 AI品質管理で重要なのは、次の3つです。 評価基準（ルーブリック）: 何を良い出力とみなすかを定義する 評価データセット: Good例、Bad例、グレーケースを含むテストデータを準備する 評価AI: ルーブリックに基づいて出力を評価し、スコア、理由、ばらつきを確認する 生成AIを実ビジネスで活用するには、「AIが動くこと」だけでは不十分です。AIの出力品質を継続的に評価し、改善できることが重要です。 LLM as a Judgeは、人間を置き換える仕組みではありません。人間が定義した品質基準を、大規模かつ再現可能な形で適用し、AI開発の品質を支えるための仕組みです。 実際の開発では、評価基準をどのように改善するか、評価データをどのように収集・更新するか、評価AIと人間レビューをどう組み合わせるかも重要になります。LLM as a Judgeを導入する際は、評価を一度作って終わりにせず、プロダクトや業務の変化に合わせて継続的に見直すことが大切です。 The post AIがAIを評価するとは？LLM as a JudgeによるAI品質管理の基礎 appeared first on dotData .

1. はじめに 今年、AWS（Amazon Web Services）がAgentic Football Cupを発表しました。これまでにもDeepLens、DeepRacerやAI Leagueなど技術の可能性を体感できるサービスを出してきているAWSらしいサービスとなります。 AWS Summitでブースが出ていたので、担当者の方にいろいろと話を伺ってきましたので、紹介いたします。ただし、本サービスはワークショップは各地域で提供されているようですが、一般公開はされていないため、サービスを体感できるまでにはもう少し待つ必要がありそうです。 なお、本サービスはマルチエージェントで協調

はじめに こんにちは。データシステム部・MA推薦ブロックの住安（ @kosuke_sumiyasu ）です。 私たちのチームは、ZOZOTOWNのメール・LINE・プッシュ通知といったマーケティングオートメーション（MA）の推薦システムを開発・運用しています。目指しているのは、ユーザーひとりひとりに最適な配信を届けることです。 ZOZOTOWNで本番運用されている推薦モデルは、価格・ブランド・カテゴリ・カラーといった テーブル特徴量 のみを学習に用いていました。そのため、商品画像が持つ視覚情報（シルエット・質感・カラー・柄）を活用できていませんでした。「オーバーサイズシルエット」や「光沢感」「チェック柄」といった、人が画像から読み取れる「見た目の好み」を推薦に反映できていなかったのです。 下図は、四角い縁のメガネを好むユーザーを例に、画像から「見た目」を捉えることで目指した推薦の姿を示したものです。従来のモデルではカテゴリは「メガネ」で合っていても、丸縁やサングラスといった「見た目」の異なる商品が混ざってしまいます。一方、画像から「見た目」を捉えられれば、ユーザーが好みそうな四角い縁のメガネを中心に推薦できます。 そこで私たちは、 商品画像から視覚的特徴を捉えた画像特徴量を生成する仕組み を構築し、既存の推薦モデルに特徴量として組み込むことで、「見た目の好み」を捉えるマルチモーダル推薦システムを実現しました。実際に、この推薦モデルをあるメール配信施策に適用しました。A/Bテストの結果、メール経由サイト流入率（CTR）・メール経由購入率（CVR）・経由売上（メール経由で発生した売上）のすべてで有意な改善が得られました。しかもこの画像特徴量は特定の施策にとどまらず、全社のどの推薦・検索モデルからでも利用できる共通の基盤として提供しています。 本記事では、この取り組みの背景にある課題、画像特徴量を生成・提供する仕組み、そして推薦モデルへの特徴量の組み込みで工夫した点を中心に紹介します。マルチモーダルな特徴量を推薦に活かしたい方の参考になれば幸いです。 目次 はじめに 目次 背景・課題 前提となる推薦システム 課題1: 推薦モデルが「見た目」を捉えられていない 課題2: 画像Embeddingを全社で利用できる基盤がない アプローチの全体像 画像Embeddingを安定供給する仕組みの構築 差分更新によるコスト削減 モデル・バージョンを管理し、VIEWで全社へ提供する 推薦モデルのマルチモーダル化によるパーソナライズ精度向上 モデルの選定 事前学習済みモデルを使用した理由 Item Towerへの組み込み Gated Multimodal Unit（GMU）で画像の寄与度を動的に制御する 特徴量単位の Dropout（Feature/Modality Dropout）で特定特徴量への依存を抑える 定量評価（オフライン） 効果 「見た目の好み」の反映による主要指標の改善 全社共通の画像Embedding基盤の整備 まとめ 今後の展望 最後に 背景・課題 前提となる推薦システム ZOZOTOWNのMAにおけるパーソナライズされたアイテム推薦の一部では、 Two-Towerモデル を使用しています。これは、ユーザーを表現するUser Towerと商品を表現するItem Towerの2つのニューラルネットワークからなります。学習済みの各Towerを使うことで、ユーザーと商品の特徴量をそれぞれEmbeddingに変換できます。このEmbeddingは、特徴を捉えた数値ベクトルで、意味の近いものほどベクトルも近くなる性質を持ちます。両Towerの出力を同じ潜在空間上にマッピングするように学習することで、ユーザーとアイテムの近さをコサイン類似度で測れるようになります。推薦時は、任意のユーザーのEmbeddingと各商品のEmbeddingの類似度を計算し、類似度が高い商品から順に推薦します。 ZOZOでは、このEmbeddingを Embedding基盤 として一元管理し、どの部署からでも利用できるようにしています。私たちの 汎用推薦システム も、この基盤を使用して配信する商品を選定しています。 課題1: 推薦モデルが「見た目」を捉えられていない このItem Towerの特徴量は、価格・ブランド・カテゴリ・カラーなどの テーブル特徴量 のみでした。そのため、 ユーザーの視覚的な嗜好を推薦に反映できない という課題が残っていました。同じカテゴリ・ブランドの商品でも、ユーザーが好むシルエットや柄、質感はさまざまです。しかし従来の推薦モデルは見た目の情報を持たないため、「興味のあるカテゴリやブランドは合っているけれど、見た目の趣味は違う」という結果になりがちでした。例えば筆者は、結婚式用に無地のパステルカラーのネクタイを探していたのですが、柄物ばかりが推薦されてしまい、改善の余地を感じていました。 課題2: 画像Embeddingを全社で利用できる基盤がない 商品画像が持つ視覚情報を推薦に活かすには、それを数値ベクトルに変換した 画像Embedding として扱うのが有効です。しかし当時は、商品画像すべてを画像Embedding化する仕組みも、それを全社で共有する基盤も存在していませんでした。そのため、各チームが検索や推薦で画像特徴量を使いたくても、それぞれが独自に実装する必要があり、開発工数の増加や品質のばらつきが生じます。そこで本プロジェクトでは、 画像Embeddingを常に使える状態で組織に提供し続ける基盤 を構築し、それを推薦モデルに組み込むことで「見た目の好み」を捉えられるようにすることを目指しました。 アプローチの全体像 課題を解決するために、大きく2つに取り組みました。 画像Embeddingを安定供給する仕組みの構築 ：商品画像から視覚的特徴を表す画像Embeddingを日次バッチで生成し、BigQueryのVIEWで提供する。どの推薦・検索モデルからでも、常に最新の画像特徴量を利用できる 推薦モデルのマルチモーダル化によるパーソナライズ精度向上 ：その画像Embeddingを推薦モデルのアイテム特徴量として組み込み、「見た目の好み」を捉えてパーソナライズ精度を高める マルチモーダル推薦は、次の3つのパイプラインで実現しています。 パイプライン 役割 generate-image-embedding 商品画像から画像Embeddingを生成し、BigQueryへ保存する train-product-recommendation 画像Embeddingを特徴量に加えてTwo-Towerモデルを学習する generate-product-embedding 学習済みモデルでユーザー・商品のEmbeddingを生成する このうち、train-product-recommendationとgenerate-product-embeddingは、もともと運用している既存のパイプラインです。今回はそこに、画像Embeddingを生成するgenerate-image-embeddingを新たに追加しました。あわせて、train-product-recommendationのモデルアーキテクチャと入力特徴量を変更しています。 これらのパイプラインで生成したユーザー・商品のEmbeddingを使って、施策ごとに配信商品を選定します。 以降では、本記事の中心である「画像Embeddingを安定供給する仕組みの構築」と「推薦モデルのマルチモーダル化によるパーソナライズ精度向上」を詳しく紹介します。 画像Embeddingを安定供給する仕組みの構築 画像Embeddingの生成パイプラインは、 Agent Platform Pipelines（旧Vertex AI Pipelines） 上に実装し、日次バッチで実行しています。全体像は次のとおりです。 処理は大きく4ステップで構成されます。 Embedding化の対象とするアイテム集合を取得する 商品画像を取得し、Cloud Storage（以下GCS）へ保存する 事前学習済みの画像モデルで画像Embeddingを生成する 生成したEmbeddingをBigQueryへ保存し、VIEWとして提供する 画像Embeddingの生成（ステップ3）には、 Hugging Face で公開されている事前学習済みモデル（ SigLIP 2 ）をGPU上で利用しています。画像の保存先にはGCS、Embeddingの保存先にはBigQueryを使っています。なお、SigLIP 2を採用した理由は、のちほど「モデルの選定」で説明します。 この中で工夫した「差分更新によるコスト削減」と「全社への提供」を順に紹介します。 差分更新によるコスト削減 ZOZOTOWNで扱う商品画像は、サイト上でアクティブな商品に限っても数千万枚の規模にのぼります。これらをすべてEmbedding化すると計算コストが大きいため、各商品（商品×カラー）につき代表の1枚に絞ってEmbedding化しています。それでも対象は数百万枚あり、さらに新着商品を考えると、毎日およそ数十万枚を新たにEmbedding化する必要があります。 これらを毎日すべて計算し直すと、GCSからマシンへ画像を転送するオペレーション料金や、推論時間の増加に伴うマシン料金がかさみ、個々は小さくても積み重なると無視できないコストになります。そこで、すべての画像を毎日計算し直す 全件更新 ではなく、未処理分のみを計算する 差分更新 を採用しています。具体的には、次の2つのステップで「まだ処理していないものだけ」を対象にします。 画像の保存（ステップ2） ：すでにGCSへダウンロード済みの画像は除外し、未取得の商品画像のみを保存する Embedding生成（ステップ3） ：すでに計算済みのEmbeddingは除外し、未計算の商品画像のみを対象とする これにより、新着商品だけを処理すればよくなり、ダウンロードコストと計算コストを抑えられます。また、GCSはAgent Platform Pipelinesの実行リージョンと同じRegionalバケットを使うことで、リージョン間レプリケーション費用やエグレス料金も抑えています。 モデル・バージョンを管理し、VIEWで全社へ提供する 画像Embeddingを全社の共通資産として提供するうえで重要になるのが、 モデルとバージョンの管理 です。精度改善のためにモデルを差し替えたり、複数のモデル・バージョンをA/Bテストで並行させたりすることがあります。そのたびに、利用者が「いまどのモデル名・バージョンが最新で有効か」を追いかけてクエリを書き換えるのは負担が大きく、更新への追従漏れも起こる可能性があります。そこで、利用者がそれらを意識しなくても、常に最新の有効なEmbeddingを取得できる仕組みを用意しました。 具体的には、次の3つのテーブル・VIEWでモデルとバージョンを管理しています。 テーブル / VIEW 種別 役割 product_image_embedding_raw テーブル 生成したEmbeddingを、商品ID・モデル名・モデルバージョン・生成日とあわせて追記する。過去分も残すため、複数のモデル・バージョンが共存する model_manifest テーブル 提供対象とするモデル・バージョンにアクティブフラグを立てる product_image_embedding VIEW model_manifestのアクティブなバージョンに絞り、商品ID × モデル名ごとに最新のEmbeddingを返す product_image_embedding_rawテーブルを直接参照する場合は、利用者がクエリのたびにモデル名やバージョンをWHERE句で指定する必要があります。これをVIEWにまとめることで、利用者はproduct_image_embeddingのVIEWを参照するだけで、常にアクティブなモデル・バージョンの最新Embeddingを取得できます。一方でproduct_image_embedding_rawテーブルにはバージョンごとの履歴が残ります。そのため、モデルのA/BテストではTreatment用のVIEWを用意することで、特定バージョンを指定した検証にも対応できます。 この仕組みによって、追跡性と再現性を確保しつつ、A/Bテストにも対応できます。当初の施策にとどまらず、検索や他の推薦面でも安心して利用できる全社共通の資産として提供できるようになりました。 推薦モデルのマルチモーダル化によるパーソナライズ精度向上 画像特徴量を活かしてパーソナライズ精度を高めるために工夫した点を紹介します。工夫したポイントは2つあります。1つ目が「画像Embedding生成モデルの選定」、2つ目が「生成した画像Embeddingを推薦モデルに組み込む方法」です。特に後者が重要で、画像特徴量は単純に足すだけでは効果が薄く、シンプルな2つの工夫を加えることでモデルの精度を大きく改善できました。 モデルの選定 画像Embeddingの生成には、事前学習済みの SigLIP 2 を採用しています。SigLIP 2は、 CLIP から派生したモデルです。CLIP系のモデルは、画像を扱うImage Encoderと、説明テキストを扱うText Encoderの2つから構成されます。学習時は、対応する画像と説明テキストのペアは近づけ、対応しないペアは遠ざけます。こうした対比的な学習をcontrastive学習と呼び、これにより画像と言語が同じ空間で結びつきます。なお、CLIPがsoftmaxベースの損失を用いるのに対し、採用したSigLIP系はこれをsigmoid損失に置き換えている点が特徴です。 画像が言語の意味と対応づけて学習されるため、得られる画像Embeddingは「柄」「シルエット」「質感」といった視覚的特徴を捉えやすいと考えられます。 CLIP系のモデルの中でSigLIP 2を選んだのは、論文記載のとおり、ゼロショットの分類・検索タスクのベンチマークで良い結果が示されているためです。 事前学習済みモデルを使用した理由 ZOZOの商品画像でファインチューニングする選択肢もありましたが、今回は事前学習済みモデルをそのまま使う方針としました。理由は次の3点です。 テキスト側の教師データがない ：CLIP系の追加学習に必要な、画像とペアになる説明テキストを大規模に用意できていない まず有効性を検証したい ：画像特徴量が推薦に効くかは未検証のため、まずは低コストに効果を確かめたい 基盤モデルの進化が速い ：将来、高性能なモデルへ載せ替える余地を残したい Item Towerへの組み込み 画像Embeddingは、まずItem Towerの入力としてそのまま使えるように整えます。下図のように、画像EmbeddingをItem Towerの入力特徴量の1つ（image_embedding）として追加します。User Tower側は変更せず、Item Tower側にのみ画像特徴量を加えています。 使用した画像Embeddingは768次元です。これを価格やカラーといった他のテーブル特徴量とそのまま結合すると、画像だけで次元の大部分を占めてしまい、他の特徴量の影響が埋もれてしまいます。そこで、画像Embeddingを2層の多層パーセプトロン（768 → 256 → 128）で128次元に圧縮してから、他の特徴量と結合します。これにより、画像とテーブル特徴量の次元のバランスを取りつつ、画像から推薦に効く表現を学習できるようにしています。 ただし、この「圧縮してそのまま結合する」方法だけでは、期待したほどの精度改善が得られませんでした。そこで、さらなる精度改善に向けて次の2つの機構を導入しています。 Gated Multimodal Unit（GMU）で画像の寄与度を動的に制御する 次元を揃えて結合するだけでは、画像をどれだけ重視するかが全商品で一律になってしまいます。しかし本来、画像をどれだけ重視すべきかは商品によって異なります。例えば、Tシャツは柄が選択の決め手になるため画像を重視したい一方、靴下はカラーやブランドといったテーブル特徴量で十分なことが多いです。そこで、画像特徴量の寄与度だけをアイテムごとに動的に調整できるよう、 GMU を参考にしたゲート機構を導入しました。 論文の2モダリティ版GMUは2つのモダリティをゲート値で線形補間するため、片方を強調するともう片方が抑制されるトレードオフを持ちます。これに対して本実装は、 他の特徴量はそのままで、画像特徴量にのみsigmoidゲートを掛ける一方向型のゲート を採用しました。これは、2モダリティ版GMUからもう片方を抑制する項を取り除いた独自の変種で、アイテムごとに画像特徴量の重みづけだけを調整できます。これにより、カテゴリやブランドなどのアイテム情報から、その商品で画像特徴量をどれだけ重視するかを動的に決められます。 一方向型にした理由は、既存のテーブル特徴量（カテゴリ・価格など）は複数のA/Bテストで有効性が実証されており、その表現力をそのまま維持した状態で、画像特徴量を追加したかったためです。 特徴量単位の Dropout（Feature/Modality Dropout）で特定特徴量への依存を抑える もう1つの工夫が、学習のたび、入力の一部をランダムにマスクすることで、特定の特徴量への過度な依存を防ぐDropoutです。よく使われるDropoutは個々のニューロン単位でマスクしますが、今回は特徴量単位でマスクする Feature Dropout を行います。なかでも画像Embeddingは、モダリティ全体を1単位としてマスクし、これを特に Modality Dropout と呼びます。実際には、テーブル特徴量（価格・ブランド・カテゴリ・カラーなど）は各フィールドを、画像Embeddingはモダリティをまるごと1つの塊として、それぞれ独立かつランダムにマスクします。 なぜこれが効くのかを、カラーと画像Embeddingを例に説明します。カラーからもユーザーが好む大まかな色味は学習できますが、画像Embeddingを使えば、より詳細なカラーやシルエット、柄まで捉えられる可能性があります。しかし画像Embeddingは複雑で扱いが難しいため、モデルは学習しやすいカラーにばかり頼り、画像Embeddingを十分に活用しないことがあります。そこでカラーをマスクすると、モデルは画像Embeddingからも学ばざるを得なくなり、画像Embeddingの特徴が使われない状態を防げます。逆に、画像Embeddingに偏りすぎる場合も画像Embeddingをマスクすれば、カラーなどのテーブル特徴量から学べます。こうして、どちらか一方に偏らず、画像Embeddingも含めた幅広い手がかりをバランスよく使う、堅牢なモデルになります。 定量評価（オフライン） これらの工夫により、画像特徴量なしのベースラインと比べて、オフラインのRecall@100は段階的に改善しました。 構成 Recall@100（ベースライン比） ベースライン（画像特徴量なし） — ＋ 画像特徴量あり（単純結合のみ） +1.06% ＋ 画像特徴量あり（Feature/Modality Dropout） +11.3% ＋ 画像特徴量あり（Feature/Modality Dropout ＋ GMU） +12.0% 効果 「見た目の好み」の反映による主要指標の改善 構築したマルチモーダル推薦システムを、1配信あたり約700万人を対象とするメール配信施策のアイテム推薦ロジックに適用し、A/Bテストで効果を検証しました。Control（画像Embeddingなし）とTreatment（画像Embeddingあり）を比較し、CTR・CVRはz検定、経由売上はt検定を用いて有意水準5％で評価しました。 その結果、 CTR・CVR・経由売上のすべてで統計的に有意な改善 が確認され、TreatmentがControlを上回りました。以下はTreatmentのControlに対する相対改善率です。 指標 相対改善率 有意差 CTR（メール経由流入数 / 配信数） 約 9.9% あり（勝ち） CVR（メール経由購入数 / 配信数） 約 14.3% あり（勝ち） 経由売上（メール経由の受注金額 / 配信数） 約 10.3% あり（勝ち） ユーザーの「見た目の好み」を捉えた推薦が、実際の流入・購入・売上の改善に結びつくことを確認できました。この結果を受けて本番リリースを決定し、現在は本番環境で稼働しています。 全社共通の画像Embedding基盤の整備 共通基盤の構築により、画像Embeddingを使いたいチームは、生成パイプラインを自前で用意する必要がなく、VIEWを参照するだけで常に最新のEmbeddingを利用できます。これにより、検索や他の推薦面を担当するチームも、開発工数をかけずに効果検証を始められます。さらに、基盤側でモデルを改善すれば、利用側は追加対応なしでその精度向上を受けられます。モデルの差し替えやバージョン管理を基盤の内側に閉じ込めたことで、利用者は中身を意識せずに使い続けることができます。 まとめ 本記事では、商品画像の視覚情報を推薦に活かすマルチモーダル推薦システムの構築を紹介しました。事前学習済みモデルを活用し、少ない工数で画像特徴量を追加して、その有効性まで確かめられました。さらに、生成した画像特徴量を全社で利用できる資産として提供できたことも、大きな成果だと考えています。これにより、画像特徴量を試したい部署は、自分たちで実装しなくてもすぐに効果検証を始められます。そして「画像」という新しい特徴量の軸を手に入れたことで、ここを足がかりに推薦をさらに良くしていけるはずです。 今後の展望 画像Embeddingのさらなる活用と推薦の精度向上に向けて、次のような展開を考えています。 画像Embeddingの活用箇所の拡大 ：整備した共通基盤を活かし、検索・他推薦面へも展開する 画像ベースの候補生成への活用 ：閲覧・購入した商品と視覚的に似た商品を、推薦候補とする モデルの高度化 ：事前学習済みモデルから、ZOZOのデータでファインチューニングしたモデルへ置き換え、ファッションに特化した表現の獲得を目指す 画像の前処理の工夫 ：商品領域をバウンディングボックスで検出してクロップ（切り出し）し、周辺の背景ノイズを除いて視覚的特徴をより正確に捉える 最後に ZOZOでは、一緒にサービスを作り上げてくれる方を募集中です。ご興味のある方は、以下のリンクからぜひご応募ください。 corp.zozo.com