広告クリエイティブ予測AIの MLOps 基盤

同社のAIは、広告運用の担当者やデザイナーがクリエイティブを見直すときに使うプロダクトです。研究部門が過去の配信実績で学習と評価を重ね、プロダクト企画部門と合意したうえで本番環境へ反映していました。しかし、その過程でモデル精度に関する品質管理体制が整っていませんでした。

研究者は学習のたびに評価指標を算出していましたが、gitにはコードの変更しか残らず、学習ごとの条件や結果は残りません。そのため条件と結果を別の手段で残す必要があり、新しいモデルが前より優れているかを比べるたびに大きな手間がかかっていました。モデルのバージョンも管理されておらず、稼働中のモデルがどれで、どの学習から生まれたのかが曖昧でした。何をリリースするかも、研究部門と企画部門が明確な基準がないまま決めていました。求める水準の精度に達しているかを判定できず、改善の効率も上がりませんでした。

KDOTはまず、部門の間で誰が誰に何を渡しているかを、要求の検証から本番前の確認までの流れ図に書き出し、モデル精度に関する品質管理体制が欠けている箇所を特定しました。

方針は、一般的なベストプラクティスを当てはめるのではなく、同社の部門構成と連携の実態に合わせると決めました。たとえば研究部門の研究履歴は専門性が高く、全量を渡しても企画部門の判断には使いにくいものでした。そこで、プロダクトに関係し、企画部門の運用に必要な内容だけをタグで抽出して渡す方式を選びました。

中核は、実験管理、モデルのバージョン管理、受け入れ条件によるリリース判断の3つです。実験管理とバージョン管理には、機械学習向けのツールであるMLflowを使いました。新しいモデルの学習を実行すると、条件、評価値、使ったコードのバージョンが実験ごとに残ります。研究者は評価値を前のバージョンと並べ、精度が上がったかを比べます。過去の実験の条件と結果を一覧できるので、次にどの条件を試すかも決めやすくなります。前のバージョンより精度が上がったモデルは、バージョン番号を付けて登録します。本番に出す前には、研究の履歴からタグで抽出した要点と受け入れ条件を、企画部門と研究部門が確認して合意します。合意が取れたものは、その番号を指定するだけで本番環境へデプロイできます。学習からリリースまでの各段階に、確認の関門を置いた設計です。

実装は同社のエンジニアが自ら担い、KDOTはコードレビューや定例の打ち合わせで、設計の意図どおりに仕上がるよう支えました。そのためMLOps基盤は、同社のエンジニアが自分たちで手を入れられる形で社内に残りました。完成後、同社は研究部門向けに紹介の場を設け、そこから日々の研究で使われ始めました。

導入後、研究者は日々の実験を実験管理に残し、前のバージョンと評価値を並べて精度の向上を確認するようになりました。過去の実験を踏まえて次に試す条件を決められるので、実験の計画にかかる手間も減りました。デプロイは登録したバージョンを指定して行うため手早く済み、稼働中のモデルからその元になった実験まで辿れます。研究部門と企画部門は、研究履歴の要点と受け入れ条件に照らして、何を出すかを決めるようになりました。同社は、精度を見極めながらモデルを磨く取り組みを、自分たちの手で続けられるようになりました。