Python

数理最適化案件とAI/機械学習案件とのアナロジー 「やってみなければわからない」中で僕たちDSはどうするか

本記事では表題に関して、脳筋系ゆるふわVTuberこと入社2年目DSの岡部がお送りいたします。(DS=データサイエンティスト)

発端はひょんなことから以下のスライドを見つけたことでした。
読み進めていくうちに、「ああ、最適化でも機械学習でも大変なポイントは同じなんだな、、、」と悟ってしまったので、内容を簡単に紹介しつつ、僕がAI案件/機械学習案件で気をつけているポイントを書き留めようかと思います。
ほぼポエムですのでご容赦ください。

 

スライドの概要と読んでみての所感

まず上記スライドに関してですが「そうだ、最適化やろう」てなった時、いの一番に見るべきスライドだと思います。2014年に書かれたものなので若干古いことは否めませんが、経年劣化する部分以外は全く色褪せておりません。
実は僕も当初は「最適化とはこんなもので、、、」といった感じの最適化に関するレビュー記事を書こうかと思ってたんですが、このスライドを見た瞬間(これの劣化版にしかならねえな)と思い断念したという経緯があります。
内容としてはタイトル通り「超入門」であり、最適化とは何か、問題としてはどのような種類があって、解き方としてはどういうアプローチがあるのか、さらにはソルバーの種類に至るまで、最適化に関して非常に良くまとめられているスライドです。特にソルバーに関してはその有用性だけにとどまらず、有償無償や商用利用の可否の観点でも整理されており、実務家が一番気になるポイントがしっかり抑えられています。

さらに、「やってみなければわからない」という爆弾を抱えた状態でクライアントとどうコミュニケーションを取ればいいかなどソフトな面でも参考になる部分が盛りだくさんです。
この「やってみなければわからない」というのは機械学習も同じであり、思うところも多かったので以下ではスライドの内容を簡単に紹介しつつ、自分が普段案件で考えていることを整理していきます。

 

分析結果+「施策(案)」を納品することの重要性

↓スライドからの引用です。

分析のみ
・納品物:レポート
・アクション:提案はするが・・・

分析+最適化
・納品物:施策(レポートも)
・「即実行、施策まで落ちるとクライアントも本気」

上記に書いてある「レポート+施策をセットで納品する」という観点は、最適化に限らずあらゆる案件で分析官が考えねばならないことではないでしょうか。
これに関連して、以前先輩社員から「クライアントが動けない分析はクソだ」と薫陶を受けました。この言葉は、データ分析を受託でやる以上、絶対に揺らぐことのない金言として深く胸に刻みつけております。
これは何も「自分で最適な施策を考えねばならない」ということではなく、「施策も納品するという心持ち」が大事なのだと理解しています。少なくとも「データからはこう言えます」ということがボトムアップ側から提案できれば、あとはクライアントの持っているトップダウンなドメイン知識とすり合わせていくことで、いい施策立案につながるはずです。
そもそもクライアントもハナから正解を期待している訳ではなく(そりゃあるに越したことはないですが)「次どうしたら良さそうなのよ?」といった「ネクストアクション」を求めていることが大半なのではないでしょうか。

さらに過激なことを言うと、ぶっちゃけ僕自身はデータサイエンスの真髄が、PDCAで言うところのDCAのところにあると思ってるので、いくつか施策案(P)さえあれば全部A/Bテストして試してみたらいいじゃねえかと思ってすらいます笑。
実際、データサイエンス界の雄であるGoogleが「41種類の青から最適な青を決めている」逸話*は(その真偽はともかく)あまりにも有名で、これぞまさにひたすらDCAを繰り返してるわけです。(もちろんコストを考えるとそんなにDoできないケースもあり、その辺はバランス感覚が重要であることは言うまでもありませんが。)

*東洋経済_Google検索の「青色」に隠された最強の分析力

クライアントと認識をすり合わせることの重要性

以下もスライドからの引用です。

お客さんは待ってくれない

ー最適化屋さんは平気で1時間、1日単位の計算をするが、お客様はボタン押したら結果がポンっと出てくると考えている
ー想定1分、待って5分といったところ
ー数時間が許される案件もあるが、早めに認識を合わせておかないと大事故につながる

これも、「あー、、、」って感じですね笑。
1分とか5分とか機械学習でいうと、下手すりゃデータをロードするだけで終わっちゃうくらいの時間だと思うんですが、超ハードな実務の現場ではその辺の事情がなかなか理解されないことも理解しているつもりです。
機械学習で言えば「蒸留モデルを作る」みたいな、時間短縮に頭を使うことは大前提とした上で、どう頑張っても3時間かかる計算を数分に短縮はできません。というかそんな簡単な計算であれば何も高尚なアルゴリズムやビッグデータに頼る必要もないでしょう。
ではどうするかというと、やはり3番目の「早めに認識を合わせておく」(=クライアントとの対話)これに尽きるかと思います。
例えば、

  • 数時間の計算時間が想定されるならあらかじめ(データ量を見た時点で)その旨を伝える
  • 人間が意思決定をするために回す分析なのであれば、夜間バッチとしてシステムを組んでおき、業務開始時間には分析が終わっているようにする
  • 計算時間の高速化はそれ自体が高度でヘビーなタスクであり、分析官の稼働コストと天秤にかけた時、本当にペイするのかを相談する
  • そもそも実装可能な処理なのか、データフローや業務フローを確認しておく

などといったところでしょうか。

そもそも数理最適化にせよAIや機械学習にせよ、業務に組み込む以上その目的は「売上を増やす」か「コストを削減する」の2パターンしかないわけです。必死で分析や開発に取り組んでいるうちに、これら本来の目的を忘れ、システムの導入それ自体が目的となってしまっては元も子もありません。
そのためにも、分析官は初期分析を高速で行い、できるだけ早くベンチマークとなるモデルを作ることを目指すべきではないかと思います。

あと、機械学習系の案件では特にそうですが、8割のものであれば、細かいところを一旦無視してガンガン進めていけば割とすぐにできることが多いです。あとはこの段階でデータ量とその質を見比べつつ、ブレイクスルーが起こる余地があるかどうかを見極めていけるとさらにベターでしょう。
ここで「ブレイクスルーが起こる余地」と言っているのは例えば、「このデータはスッカスカだからデータ量は多くても精度伸びねえな」とか「自然言語処理に手を出せば一山当たる可能性は高えな」とかそういった算段(皮算用)のことを言ってます。前者であれば早めに撤退を促すコミュニケーションに移行、後者であれば工数をもらい過度に期待値を上げすぎず開発していくと言った感じになるでしょう。ちなみに先ほどの「売上向上」「コスト削減」の観点から言うと、分析官の工数は完全にコストなので、早めに撤退して別タスクに集中することは立派なコスト削減だと思っています。

補足ですが、上記はある程度機械学習でやるべきことが決まっている時を想定しています。
ただ実は、実務で本当にハードルが高いのはこの「やるべきこと」を見極める部分です。どういうことかと言うと、「AIでなんかやってよ〜」といった生半可な覚悟では何もできないこと必至で、本気で取り組むならば、上記の初期分析→初期モデルのプロセスを高速に回しつつ「機械学習でしかできず、実現可能そうで、かつ効果が大きい」、つまり「やるべきこと」を見つけなければならないということです。
そしてこの見極めには、ビジネスモデルと業務フローへの理解、アルゴリズムに対する肌感、それらを実装するエンジニアリング力、とまさにデータサイエンティストに求められるスキルセットがフルコースで必要となります。こんなことを一人でできるスーパーマンがいればそりゃ理想なのですが、もちろんそんな人は希少ですし、もしいたとしてもおんぶに抱っこでは属人化すること必至なので組織として健全とは言えないでしょう。
だからこそ我々はチームを組んで仕事をするのであり、そこで重要なのが(繰り返しになりますが)対話・コミュニケーションということになります。

もっと言えば(補足が長いw)、そもそも機械学習を使わない選択肢だってあるわけです。この辺を語り出せば確実に長くなりすぎるので、またの機会に別記事で書こうかと思います笑。

最後に

長くなりましたがまとめとしては、数理最適化であれAI/機械学習であれ、あらゆる分析案件は、クラインアントとの対話が大事であるという、当たり前の結論がまず一つ。
加えて、特に数理最適化とAI/機械学習系の案件を行う際は、特有の「不確実性」を踏まえて、コストやリスクに関する想定を幅広く持ち、両手法ならではのメリットを着実に享受できる、そんなバランス感覚がデータサイエンティストには求められるのではないでしょうか。

Taizo Okabe
脳筋系データサイエンティスト。筋肉は裏切らない。筋肉。