Feature Storeを活用して最新のデータを学習時に取り込むことによる推薦システムの改善 | Wantedly Engineer Blog
こんにちは、ウォンテッドリーでデータサイエンティストをしている林(@python_walker)です。ウォンテッドリーでは、テクノロジーの力で人と仕事の適材適所を実現するために推薦システムの開発...
https://www.wantedly.com/companies/wantedly/post_articles/897815
Photo by Ramin Khatibi on Unsplash
ウォンテッドリーでデータサイエンティストとして働いている市村です。私たちのチームは Wantedly Visit の推薦システムの開発と運用を担っています。
機械学習をベースとした推薦システムが活用される経路は年々広がっており、プロダクトへの貢献領域も拡大し続けています。こうした成長を支えるうえで、運用コストを抑えながら素早く安定的にサービスを届けるための仕組み、すなわち MLOps の整備は欠かせません。
これまでチームとして様々な取り組みを進めてきましたが、規模の拡大に伴い新たな課題も見えてきています。この記事では、推薦システムの MLOps について「特徴量管理」「モデル学習と評価」「デプロイとサービング」「モニタリングと運用」の4つの観点から、現在の取り組みと今後の課題をお伝えします。私たちがどのように推薦システムの運用と向き合っているのかを感じ取ってもらえると嬉しいです。
はじめに
特徴量管理
モデル学習と評価
デプロイとサービング
モニタリングと運用
おわりに
推薦システムにおいて、特徴量の管理はモデルの精度と開発スピードの両方に直結する重要な要素です。
私たちのチームでは内製の特徴量ストアを実装し、複数の推薦パイプラインから共有して利用できる仕組みを構築しています。これにより、新しい推薦プロジェクトを立ち上げる際に既存の特徴量をそのまま再利用でき、開発のスピードを大きく向上させることができています。
特徴量ストアについては過去に技術ブログを書いているので、詳細はそちらをご覧ください。
一方で、特徴量ストアを内製で実装・運用していることにより、メンテナンスの負荷が増大しているのも事実です。具体的には、バックフィルの実行や差分更新といった細かな管理作業が煩雑になりつつあります。推薦パイプラインの拡大に伴い、こうした運用負荷は今後さらに増加することが見込まれるため、マネージドサービスへの移行も視野に入れて改善を進めています。
Wantedly における多くの推薦モデルは、比較的高頻度なバッチジョブとして学習が自動化されており、人手を介さずに最新のデータを反映したモデルが継続的に生成される仕組みが整えられています。
また、推薦モデルのオフライン評価を効率的に行うための評価ツールを内製しています。モデルの変更がもたらす影響を素早く定量的に確認できるため、実験サイクルの高速化に寄与しています。
評価ツールについては過去の登壇資料で詳しく紹介しています。
さらに、モデルの実験を効率的に進めるうえでは、データサイエンティストの開発環境の整備も重要なテーマです。Kubernetes 上での開発体験を向上させるための内製ツールを開発し、データサイエンティストが使い慣れた環境で快適に実験できる仕組みを整えています。
このツールの詳細については以下の記事で紹介しています。
現在は比較的軽量な機械学習モデルを中心に運用しているため、再学習のコストは大きな問題にはなっていません。ただし、一部ではすでに深層学習モデルの導入を進めており、今後さらに拡大していく方針です。深層学習モデルは学習にかかる計算コストが高いため、再学習の頻度やトリガーの設計、計算リソースの効率的な活用といった観点で、再学習パイプラインの最適化が必要になると考えています。
データサイエンティストが行った推薦ロジックの変更を、素早くオンラインで検証したり全体にリリースしたりするための仕組みは比較的整備が進んでいます。新しいモデルやロジックを試す際にもスムーズに A/B テストを実施できる状態になっており、実験から本番適用までの流れが確立されています。
デプロイのための基盤についても、過去の登壇資料で紹介しています。
一方で、現在はバッチ推論を中心としたサービング構成であり、今後はよりリアルタイムな推薦体験を実現するためにオンライン推論への移行を進めています。オンライン推論では、レイテンシやスループット、可用性といった非機能要件がバッチ推論とは大きく異なります。こうした要件に対応できるインフラの設計を整備していく必要があります。
推薦モデルの運用においては、モデルそのものの性能を測るための指標だけでなく、プロダクトのビジネス指標もチームで定期的に確認する文化があります。この両面からの監視により、モデルの変化がプロダクトに与える影響を早期に検知できるだけでなく、指標の傾向や変動から新たな改善施策が生まれることもあります。
一方で、現在の監視体制は人が能動的にダッシュボードを確認しに行く運用になっています。異常検知やアラートの仕組みを整備し、自動化できるものは自動化していくことで、問題の早期発見と対応を実現したいと考えています。
また、モデルへの入力になる特徴量のドリフト(データ分布の変化)などについては、現状では十分にモニタリングできていません。特徴量の分布が学習時と大きく乖離した場合、モデルの性能が劣化するリスクがありますが、この検知が手薄であるという課題があります。
この記事では、ウォンテッドリーの推薦システムにおける MLOps の取り組みと課題を紹介しました。
記事の中で触れたように、私たちの推薦システムは成長の過渡期にあり、MLOps の観点で取り組むべきことはまだたくさんあります。特徴量基盤の刷新、学習パイプラインの高度化、オンラインサービングへの移行、モニタリングの自動化など、これらの課題を一緒に解決してくれる仲間を探しています。
もしこの記事を読んで少しでも興味を持たれた方がいれば、ぜひ一度カジュアルにお話ししませんか?現時点で転職を考えていない方でも大歓迎です。私たちの取り組みや課題感について、より詳しくお伝えできればと思います。