リブセンスの機械学習業務(2020年1月)

こんにちは、リブセンスで分析や機械学習関係の仕事をしている北原です。今回は求職者に向けたリブセンスの機械学習業務の紹介です。求職者に業務内容を理解してもらうのが目的の記事になっています。各事業部で進められている機械学習プロジェクトなどもあるのですが、本記事ではテクノロジカルマーケティング部という横断組織での機械学習専門職の業務について紹介します。

リブセンスの機械学習活用

まず、リブセンスでは機械学習がどのようなところで使われていてどのような特徴があるかについて説明します。また、リブセンスのデータ分析基盤と機械学習基盤が機械学習でどのように活用されているかについても紹介します。

リブセンスの事業と機械学習

リブセンスでは求人サイトや不動産サイトを自社サービスとして運営しています。具体的には以下の事業を運営しています。

マッハバイト：バイト求人サイト
転職ナビ：転職求人サイト
転職会議：企業口コミサイト（転職求人サイト）
転職ドラフト：競争入札式転職サイト
就活会議：就活求人サイト
IESHIL：不動産サービスサイト

機械学習の活用度合いは事業によって大きく異なるのですが、事業部独自に進めているものを除くと主にメルマガや検索、アド出稿で利用されています。

実務で機械学習を利用するケースではよくあることかもしれませんが、単純な予測問題として扱うだけでは解決できない課題が多く、精度が上がりさえすればよいというケースは少ないです。ほとんどの事業で求人情報を中心に扱っているためデータの特徴が類似している部分が多い反面、事業によってビジネスモデルやサービス設計が異なるため利用可能な情報が異なっていることも多いです。そのため、他事業部での機械学習導入ノウハウを活かせるものの、事業部ごとのサービス設計やデータ特性に合わせた問題設定が必要になります。

また、Web業界は環境変化が激しいですし、サービス単体で考えても新施策が次々と導入されるためデータ特性が大きく変わることがあるのも特徴の一つです。データ特性が大きく変わると導入済みの機械学習モデルが機能しなくなることがあるため、運用面にも配慮が必要です。

データ分析基盤

リブセンスでは2014年からデータ分析基盤を運用しており専任のデータエンジニアもいるため、データは比較的扱いやすい形に整備されています。分析しやすい形でRDBにデータが蓄積されているので、分析者によるクレンジングの手間が減っています。データ分析基盤では、アクセスログなどのサービス利用時のデータだけでなく、個人情報を除いたユーザー属性情報や求人情報なども利用できるようになっています。分析しやすい形で多様なデータが一元管理されているため、SQLが書ければ多様なデータを組み合わせた分析やモデル構築が容易で、オフラインのPoCがやりやすくなっています。

データ分析基盤は、事業部でも施策の効果測定や分析に使われており、リブセンスの「データに基づいて意思決定をする文化」を支えています。リブセンス全体にデータに基づいて意思決定する文化が根付いているため、KPIの向上、低下があればデータに基づいた原因調査が行われ、次の施策に活かされます。 SQLを使って事業部とコミュニケーションを図ることができるため、機械学習で利用するデータについて事業部に問い合わせたり議論したりするのが容易です。

機械学習基盤

2018年からは機械学習基盤も運用されています。機械学習基盤は、コンテナ化されたコンポーネントをワークフローエンジンで連携させることで機械学習の導入・管理を容易にするためのシステム基盤です。

機械学習基盤は、機械学習システムの運用で生じる問題を解決するためのものです。機械学習では目的に応じて様々な言語やライブラリ、ツールを組み合わせて使うことが多いので環境構築が大変だったり再現性が低くなることがありますが、コンテナ化されていることで個別に開発が可能でDockerコンテナで動作した機械学習処理は基盤上でそのまま動かすことができます。機械学習で必要な計算機リソースは、扱う問題やデータ、手法によって異なりますが、基盤はGCP上に構築されているため計算機リソースが不足した場合は拡張することが容易です。機械学習では、オフラインで精度の高かったモデルが運用してみるとうまくいかないことがあるため、オンラインのPoCで検証・改善を行うことも多いです。機械学習の一連の処理を行うDockerコンテナを作成すれば容易に実サービスで使えるようになっているため、機械学習基盤によってオンラインのPoCがやりやすくなっています。

機械学習プロジェクトの進め方

機械学習プロジェクト全体の流れは以下のようなものになります。

f:id:livesense-analytics:20200109150829p:plain — 機械学習プロジェクトの流れ

企画フェーズ

企画フェーズでは、問題設定、スケジュール、担当者などを決めます。

問題設定というのは、事業課題を機械学習を利用して解決できる具体的な問題に落とし込むことです。機械学習コンペでいうと出題する問題を作るところに対応します。ただし、コンペと違って実サービスでは特定の指標だけ上げればよいというわけではなく、サービス設計に合わせるための制約もあるのでそれらも問題設定に入れます。どのような問題設定にするかは、Webディレクターのような事業部責任者と議論しながら決めていきます。問題設定が決まってもデータを調べてみたら使い物にならなかったということもあるので、やることの方向性を決め、利用するデータの確認・検証を進めながら詳細を固めていくことが多いです。

問題設定と同時に、予測結果などを事業部サービスのどこで使うのか、事業部でどのぐらいの開発工数が必要で誰が開発するか、といったことも決めていきます。機械学習でやろうとしていることの影響範囲が大きい場合はリリース前に関係部署の了承を得る必要があるため、了承が得られそうかどういう条件ならば了承が得られやすいかなども考慮して機械学習の活用方法を具体化していきます。我々は事業部内の調整が進めやすいような活用方法や問題設定を考えますが、最終的には事業部責任者の力量に依存する部分が大きいところです。

自社サービスということもありタイトなスケジュールが組まれることはほとんどなくプロジェクト規模も小さいことが多いです。別施策と連携させる予定があるときはリリース期限が定められるときもありますが、通常は無理のないリリース目標を決めて進めていきます。プロジェクトに直接関わるのは事業部責任者を含めても２〜５人程度で、事業部責任者、事業部エンジニア、データエンジニア、データサイエンティストというのが標準的な分担です。

オフラインPoCフェーズ

オフラインPoC(Proof of Concept)フェーズでは、データ取得から予測などの出力をするところまでを実装し精度検証を行います。機械学習といったときに多くの人が思い浮かべるようなことをやるのがこのフェーズで、機械学習コンペでいうと参加者が問題を解くところに対応します。ただし、コンペのように精度をギリギリまで上げようとすることは少なくサービス設計に沿って安定的に動作するようにモデルやアルゴリズムを設計していくことが多いです。

必要なデータはデータ分析基盤に蓄積されていることが多いのでSQLを使えば簡単にデータを取得できます。しかし、データ仕様は事業部に問い合わせないとわからないことが多いので事業部担当者にデータ抽出条件を確認しながら進めます。データ抽出・加工は地味で時間のかかる工程ですが重要かつ必要不可欠で、リブセンスでも前処理に業務時間の８割がかかるというところは同じです。ロギングデータの不具合を発見することもあり、事業部に修正をお願いしたり影響範囲を確認したりといったことも必要になります。

オフラインPoCフェーズではデータ分析や試行錯誤を繰り返すため、やりたいことを迅速にコーディングしていきます。 Dockerコンテナで動かせればよいので前処理やモデル作成には好きな言語やライブラリを使えます。分析志向の強い人はR、エンジニア志向の強い人はPythonで書く傾向があります。最近では、データ量があまり多くないときにベイズ推定を利用する場合はStan、計算時間が問題になりそうなときはJuliaを使うことが多いです。

オフラインPoCで問題設定や利用データに不備が見つかることもあります。その場合は企画フェーズからやり直すこともありますし、その不備が致命的な場合はプロジェクト自体が延期あるいは中止になることもあります。例えば、事業部でKPIとして使われている指標でも機械学習の予測対象としては信頼性が低くて使えないこともありました。

オンラインPoCフェーズ

オンラインPoCフェーズでは、オフラインPoCで検証済みの機械学習処理を実サービスで動かして実際に効果があるかを検証します。

閲覧履歴などのログデータを利用して予測モデルなどを作成すると閲覧されやすさに起因するバイアスを含んだデータで学習することになるため、オフライン精度検証では高機能だったモデルが実サービスでは意図通り機能しないことがあります。また機械学習がKPI向上のために間接的に利用されている場合、精度は高いけどKPIは上がらないということもあります。そのためオフラインでの精度検証だけでは不十分で、実サービスに投入して本当に効果があるかをオンラインで検証する必要があります。

Webサービスでは比較的簡単にオンライン検証が可能ですが、リブセンスでも同様です。オフラインPoCで使ったコードをDockerで動作するようにしてデプロイすれば機械学習基盤上で運用できるようになるので、事業部の機能実装が終了すれば実サービスとしてリリースできます。オンライン検証はA/Bテストで行うのでテスト設計やそのための仕組みも実装します。

A/Bテストでは期待通りの結果になっているかを多角的に分析・検証し、次の機械学習施策に活かします。機械学習の使われ方やモデル・アルゴリズムの特性から期待通りに機械学習が機能すればどの指標に影響を与えるかわかります。そのため、主要KPIの上下だけで成否を判断するのではなく複数の指標から総合的に効果や影響を判断します。

オンラインPoCで期待通りの効果が確認されれば開発フェーズに移行しますが、多くの場合は意図しない結果になっている部分が見つかるので、必要に応じてさらに調査したり改善したりします。また、実サービスで動かすと事業の売上や利益にも影響するので、事業部責任者に効果やその理由について説明することも多いです。

オンラインPoCでは実サービスに投入して効果を計測するためすぐには終わらないし、改善を繰り返すたびにA/Bテストを行うので時間がかかります。また、A/Bテストで期待通りの効果が確認された後も、その効果が安定的に継続するかを確認するためそのまま運用し続けることも多いです。そのため、オンラインPoCフェーズは長期間におよぶことが多く、オンラインPoCフェーズまでと開発フェーズ以降は別プロジェクトとして進められることも多いです。

開発フェーズ

開発フェーズでは、オンラインPoCで検証済みの機械学習処理を安定運用させるための開発を行います。 PoCフェーズでは、データサイエンティストのような非エンジニアがコーディングを担当し、一時的な分析用や試行的な処理などの継続的に使われるかわからないコードを書くためコード品質は低くなりがちです。オンラインPoCを終えると継続的に利用する処理も決まるので、データエンジニアが一連の処理を書き直すことで、エンジニアによる運用保守をしやすくします。

どのような処理を行っているかによって開発内容は異なりますが、使い回しが可能なアルゴリズム部分は切り出してモジュール化し、個別課題への依存性が高い前処理などはアプリケーションモジュールとして書き直すことが多いです。 PoCで書いたコードを書き直すのは二度手間のように見えますが、仕様が確定していないPoCの段階では適切な設計は難しいしエンジニアレベルのコード品質を非エンジニアにもとめても生産性を損なうので、PoCと開発でフェーズや担当者を分けることで両者の生産性を損なわないようにしています。

運用フェーズ

運用フェーズでは、機械学習基盤で日常的に動かし安定運用します。

普段の運用監視はデータエンジニアがSREとして担当しており、トラブル発生時の一次対応を行っています。システム的なトラブルはデータエンジニアが担当し、データや機械学習処理に起因するトラブルはデータサイエンティストや開発フェーズを担当したデータエンジニアが担当します。予測結果など機械学習の出力結果のモニタリング、通知環境も整備されており明らかな異常がある場合は検知できるようになっています。またトラブル発生時には原因究明できるよう、定期バッチで作成された機械学習モデルや学習データなどはGCSに保存されています。問題設定作成時に定期バッチが失敗しても数日程度ならば大きな影響が生じないように考えられているので、夜間・休日の緊急対応は今のところありません。

機械学習システム運用の難しいところは一見問題なさそうなのに通常と異なる結果が出力されていることがあるところです。このようなケースは事業部から連絡があって気づくことが多いです。今までとは異なるタイプの大口顧客のデータが加わったり事業部施策の影響でデータ傾向が変わったりすると発生します。仕様通りの挙動のため放置することで解決した場合もあればモデルを変更することで対処したこともあります。 PoCフェーズで導入した機械学習処理が実サービスでどのような挙動をするかというところまで検証しておくことで運用時のトラブルにも対応できるようにしています。

リブセンスの機械学習専門職

データサイエンティスト

主に機械学習プロジェクトの上流工程である企画・問題設定からオンラインPoCまでを担当することを想定した職種です。我々の目的は機械学習を使うことではなくよりよいサービスを作ることなので、このサービスはどうあるべきか、機械学習を利用することでサービスをよりよくできるか、できるとしたらそのためには機械学習をどう活用すべきかということを考え、事業部と適宜コミュニケーションをとりながら業務を進めていきます。オフラインPoCで高精度なモデルやアルゴリズムを作って終わりではなく、オンラインPoCを通じて実サービスで成果をあげる仕組みを構築するところまで行います。

業務は開発よりも分析が中心になります。場合によっては高度な分析も使わないわけではないのですが大半はSQLやR、Pythonなどを使った集計です。企画フェーズでは、そもそも機械学習を導入する価値があるのかどこに導入するのかを検討するために利用状況などを分析します。問題設定を考えるときは、必要なデータが適切に収集できているかを確認したりどのデータをどのように使うかを決めるための分析をします。オフラインPoCでは精度がどうかだけでなく、サービスに投入したときにうまく機能するかという観点で分析します。オンラインPoCでもA/Bテストの結果から、適切に機械学習が機能しているか多様な観点から分析する必要があります。ただし、形式的なレポーティング業務やプレゼンのようなものはありません。プロジェクトを進めるにあたって必要なことを必要な人に伝えるために分析結果を共有したり報告したりします。

事業部とのやりとりでは数値をベースに行われます。数値で成果を測定し数値で問題点を洗い出し数値で議論します。リブセンスのWebディレクターのほとんどはSQLが使えるので、Slack上でSQLとCVRなどの集計結果を示して「この施策うまく動いています」とか「ロギングがおかしくないですか」といった会話がされます。データ分析基盤はRedshiftを利用して構築されているのでほとんどはRedshiftですが事業部のシステムはMariaDBなので、PostgreSQL系、MySQL系のいずれのSQLも使います。

スキルでいうと、SQLやデータ分析を実務レベルで使いこなせ、機械学習の上流工程を担えるぐらいの機械学習の知識は必須です。知りたいことをデータを使って明らかにすることができれば必ずしも高度な分析手法を知っている必要はありません。中途半端な理解しかできていない高度な分析手法を知っているよりも、実務で使いこなせる分析技術がどれぐらいあるかのほうが重要です。使いこなせるというのはライブラリの使い方を知っているだけでなく、データや課題に応じた適切な使い所を判断できる、データや現象、課題に合わせたモデリングやアルゴリズムの拡張といった応用的な使い方ができることを意味します。リブセンスの課題は多様なので、自然言語処理やレコメンドなどの特定の技術だけに詳しい人より統計学や最適化の基礎がしっかりしている人のほうが向いているのではと思います。基礎ができていれば必要な技術は後から学べます。それでも現在抱えている課題や利用技術をふまえると、実務で使いこなせるレベルの因果推論やベイズ統計モデリングの技術があると即戦力として活躍しやすいです。リブセンスの機械学習プロジェクトは小規模なものが多いのですがプロジェクトマネジメントの経験があると業務を進めやすいでしょうし、Webマーケティングについて詳しければマーケティングの知見を活かした分析や機械学習活用ができるので活躍しやすいです。

使っている分析・機械学習技術の一部については過去の技術ブログ記事で公開しています。以下で扱っている技術は、オフラインPoCで精度検証しただけでなく、実際にサービスで使われているあるいは使われていたものです。必ずしもこれらの技術に詳しい必要はないですが、これらを理解し議論できる程度の基礎知識や技術力は必要になります。

リブセンスのデータサイエンティストの魅力は、データ活用に関する自分のアイディアを実サービスで活かしやすい環境にあります。データ活用に理解のあるディレクター陣がいて、データを分析しやすい形で一元管理しているデータ分析基盤、オンラインPoCを容易にする機械学習基盤があります。事業部責任者が納得し施策に必要なデータがあり運用上問題がないのであれば、機械学習施策を実サービスに導入することができます。アイディアもあるし技術もあるのに提案活動とオフラインPoCばかりでアイディアや技術を活かしきれていない人にとっては魅力的な仕事だと思います。データサイエンティストといっても強みはそれぞれ異なるので、自分の強みを活かすことができるところも利点です。 Webマーケティングに強みがあるならばマーケティング施策をやれるし、モデリングやアルゴリズムに強みがあるのであれば使いたいモデルやアルゴリズムを使えます。プログラミングが得意である必要はないですが、やりたいことを自分でコーディングできるのであれば活躍範囲が広がります。

一方で、大変な部分も当然あります。データ分析基盤があるので生データ整備の必要はないものの前処理に手間がかかるところは変わりません。どこのDBにどのような条件でデータが格納されているかを事業部に確認しながら進めていくので時間もかかります。ロギングにバグがあり分析し直さなければならないこともあります。そのようなバグは外れ値だけを調べればみつかるといった簡単なものだけとは限りません。データとサービス特性の関係から「このサービスでこういうデータになるのはおかしい」といち早く気づいたり、「こういうデータになるのはサービスがこうなっているからではないか」と仮説を立てて調べていく必要があります。

また、実サービスで使っているからこその苦労もあります。例えば、データの傾向が変化し安定稼働しているはずの機械学習システムが機能しなくなることがあります。 Webサービスだと事業環境が変わることも多いし事業部施策が影響することもあるので、原因を調べ対策を示す必要があります。さらに、何らかのトラブルや業績不振があると機械学習が原因でない場合でも原因ではないことをデータに基づいて説明することをもとめられます。機械学習手法をいろいろと試すと偶然うまくいく技術が見つかることもありますが、どういうときになぜうまくいくのかを把握した上で利用しないと運用後に苦労します。機械学習プロジェクトというと交差検証で高精度なモデルやアルゴリズムを作ることだと考えている人も多いかもしれませんが、それだけだと通用しないことも多いです。