事業会社における 機械学習システム開発・運用の課題と展望 株式会社リブセンス 田中 祥太郎

● 事業会社において、Webサービスに組み込まれ実際に収益を挙げることを 目的とした機械学習 (ML) システムについて述べる ● MLアルゴリズムそのものより、MLを利用するシステムの特徴や 開発・運用の体制、組織・プロジェクト管理に着目 ● 実際の課題の列挙とそれに対する考察・展望の共有が目的であり、 特定の課題に対する詳細な解決手法の提案は行わない ※実際の取組みは https://analytics.livesense.co.jp/ で紹介 内容について

自己紹介 田中 祥太郎 / @yubessy ● 株式会社リブセンス テクノロジカルマーケティング部 データプラットフォームグループ ● データ分析基盤・機械学習基盤の開発・運用に従事 ● 修士 (社会情報学) 経歴 2010 - 2014 京都大学工学部情報学科 2014 - 2016 京都大学大学院情報学研究科 2016 - 株式会社リブセンス

リブセンスのサービス 求人・不動産領域を中心に大小複数のサービスを運営

成功報酬型ビジネスモデルが主流 リブセンスのビジネスモデル

求人サービスの例 ● 求人票の掲載：無料 ● 応募者の採用：課金 掲載無料 = 営業努力だけでは収益を上げにくい データ活用によるマーケティング・UX向上施策に注力 → 機械学習をはじめとする最適化手法の導入 ● コンテンツと行動ログによる求人レコメンド ● CVR予測に基づく検索ランキング最適化 成功報酬型ビジネスモデルとデータ活用

例 コンテンツと行動ログによる求人レコメンド ● 求人コンテンツの類似度に基づく Contents-Based Filtering ● ユーザフィードバックに基づく Collaborative Filtering

例 CVR予測に基づく検索ランキング最適化 ● 求人のCVR (応募率・採用率) を予測し検索順位制御に利用

MLシステムの開発・運用課題 これらのシステムの開発・運用において多くの課題に直面 ● システムの負荷が高い ● 実環境での検証が困難 ● … 以前は個別に対処してきたが、限界も見えてきた → これまで直面した課題を列挙し、今後の議論の一助としたい 今回は２つの観点から整理を試みる ● システムの構造や計算の特性に関わる課題 ● 開発・運用の工程や組織体制に関わる課題

システムの構造や計算の特性に関わる課題

MLシステムの一般的特徴 ● 入出力を決定する関数 (=モデル) がデータに依存 ● ロジックがコードではなく数理モデル → ブラックボックス化の懸念 ● 学習処理はスループット志向 ↔ 予測処理はレイテンシ志向

課題 学習のリソース消費量が大きい ● スループットを出すために大量の CPU, GPU, RAM が必要 ● 学習は一時的・定期的に発生 → リソースを常に確保するのは無駄 ○ 事業会社ではハードウェア買い切りがコストに見合わないことも アイデアと展望 ● コンテナ技術等によるインフラの共通化・再利用 ● ジョブスケジューリングによるリソースシェアリング ● 従量課金型の IaaS / PaaS の利用

課題 予測のレイテンシを向上させにくい ● Web利用に耐えうるオンライン予測の実現はハードルが高い ○ 例 ユーザ特徴に基づいて動的に推薦アイテムを決定 ● 処理のボトルネックが通常のシステムと異なる ○ 通常：データベースI/O, ネットワーク ○ ML：画像・テキストなどの前処理，モデル内部の数値計算 アイデアと展望 ● 一部の処理を queue-worker などで非同期化 ● 部分的な事前計算・インデックス技術の活用

課題 処理の再現性が担保しづらい ● データの時間・環境差異やノイズの混入により再現性が失われる ○ 通常：開発環境と本番環境のDBは異なる ○ ML：開発・検証時にも本番と同等のデータが必要 ● 試験実行時のコンピューティング環境も同一が望ましい アイデアと展望 ● データウェアハウスの整備とデータソースの一元化 ● クラウドサービスのアイドリングリソース活用 ○ GCP: Preemptible Instance / AWS: Spot Instance

課題 コード実行を伴うテストや検証が大変 ● 構造上、単体テストによる検証がしづらい ○ Webサーバ：実行時間の短い関数を独立・並行実行 ○ MLジョブ：実行時間の長い関数を依存・直列実行 ● テストケースの整備にMLの専門知識が必要 ○ データのサイズや分布が異なると挙動が変わる ○ アルゴリズムに対する数理的な理解が要求される ● 一度のテスト実行に多大な時間とリソースが必要 アイデアと展望 ● ソフトウェアの静的解析手法の応用 ○ 出力の値域や計算量を実行前にある程度知りたい ○ アルゴリズム実装の正しさの検証ができないか？ ● 現状は動的型言語 (Python, R, ...) が主流なので難しさも

開発・運用の工程や組織体制に関わる課題

Webサービス運営事業の一般的特徴 サービスのローンチ後に継続的なモニタリングと改善を行う ● システムの運用と並行して開発とリリースが繰り返される ● 拡張性・スケーラビリティを強く意識する必要がある ※ ● ウォータフォールモデルよりアジャイル的手法が好まれやすい ※もちろん安定性・堅牢性を軽視してはならない 業態 Webサービス運営 システムインテグレーション 提供するもの サービス ソリューション 売上の発生 利用 納品・保守 顧客単価 比較的小 比較的大 顧客数 比較的多 比較的少

課題 実環境下でのオンライン評価が必要 ● オフライン評価では精度指標は算出できてもビジネス効果は不明 ● 実環境ではフィードバックループにより学習データ自体が変化 ○ 例 レコメンドによる一部商品へのコンバージョンの偏り ● → オフライン評価の結果が常に有用とは限らない アイデアと展望 ● 実環境でのオンライン評価の仕組みの整備 ○ スプリットテストによる統制実験 ○ 段階的ロールアウトによる変化傾向の把握

課題 ソフトウェア品質が低くなりやすい ● PoCでも実環境検証が必要 ↔ PoCではコードや設計に気を使えない ○ MLの専門性 ≠ ソフトウェアエンジニアリングの専門性 ● → 品質の低いソフトウェアの実環境投入による運用負荷 ○ アプリケーション・インフラエンジニアが対応に追われる ● → クリティカルな機能でのML利用が進みにくい ○ 例 検索ランキングの動的制御, A/Bテストのパターン配信 アイデアと展望 ● フェイルオーバーの仕組みの整備 ○ MLが要求を満たせない → ヒューリスティクスでリカバリ ● SLI / SLO / SLA の導入によるサービスレベルの明確化 ○ 客観的指標があれば問題をトリアージしやすい

課題 モデル精度とビジネス収益の関係が不透明 ● 精度がX%向上するとどの程度のビジネス収益につながるか？ ● みかけの精度向上の裏に重要な機会損失が潜むことも ○ 例 検索の適合率が向上するも一部の高収益商品の順位が低下 アイデアと展望 ● 実際のユースケースに即した評価指標の選定 ○ 適合率 vs 再現率 ○ ペアワイズ評価 vs リストワイズ評価 ● 精度指標とビジネス指標の統合的なモニタリング

課題 プロジェクト・組織管理の方法論が未整備 ● 異なるバックグラウンドのメンバーからなる混成チーム ○ 高度な専門性が必要 ⇔ 属人化しやすい ● 適当なプロジェクト管理の方法論が存在しない ○ CRISP-DM※ はシステム開発・運用の観点が薄い アイデアと展望 ● 組織・事業に応じた体制づくりはどこも模索中 ● → まずは事例共有から ※https://en.wikipedia.org/wiki/Cross-industry_standard_process_for_data_mining

まとめ 事業会社でのMLシステムの開発・運用における課題を列挙・整理 ● システムの構造や計算の特徴に関わる課題 ○ 学習のリソース消費が大きい ○ 予測のレイテンシを向上させにくい ○ 処理の再現性が担保しづらい ○ コード実行を伴うテストや検証が大変 ● 開発・運用の工程や組織体制に関わる課題 ○ 実環境下でのオンライン評価が必要 ○ ソフトウェア品質が低くなりやすい ○ モデル精度とビジネス収益の関係が不透明 ○ プロジェクト・組織管理の方法論が未整備 今後の議論の一助になれば