すべての人をティータイムで帰れるようにする
久保隆宏氏（以下、久保）：では、発表させていただきます。ちなみにこの中で花粉症の方ってどれくらいいますか？
（会場挙手）
かなり多いですね。講演終了までにくしゃみをしなかったらぜひ拍手をいただきたいなと思います。
（会場笑）
では始めていきたいと思います。システムの中で機械学習を組み込むことが一般的にできるようになってきているということなんですけれども。
機械学習の部分というのは、我々アプリケーション開発者が今まで触ってきた機能と違う挙動をするところになります。
それを扱うには、これまでとは違う依存性の管理であったりとか、設計上の構造というものが生まれてくるんじゃないか、という話をします。最後に機械学習エンジニアは今後何をしていくべきなのかみたいな話もちょっとしていきます。
自己紹介です。TIS株式会社の戦略技術センターにいます、久保でございます。
私はもともと研究開発をずっとやっていたわけじゃなくて、むしろ化学系メーカーのコンサルタントとしてのキャリアのほうがずっと長いです。
お客様のそばにいてシステムの管理などをやってたんですけど、普通にシステムを入れるだけで行える業務改善って、けっこう限界があるなというのを現場でひしひしと感じまして。
やっぱり新しい技術がないと単純に効率化以上のことはできないなと思って、数年前に戦略技術センターに行って、という感じです。
今所属しているチームのミッションとして、すべての人がティータイムに帰れるようにすることを掲げ、研究開発を行っています。
研究活動のコンセプトとしては単純に「こういうふうにしてくださいね」と言ってもなかなかそうはしてくれないですよね？
実際に使ってみてもらって「これ便利だね」というふうになると、意外とすっと変わったりする。実際に動かせるプロダクトを作って、それを使って体験してもらうところを中心に活動しています。
現在の取り組み 自然言語の観点要約など
今注力して取り組んでいるのは、観点を指定した自然言語処理というものです。
ここにちょっと例があるんですけれども。「ペンギンのサイズは小さくて、手触りは冷たい」と言うときに、サイズが小さくて手触りが冷たいというふうに、観点単位にまとめるというふうな処理をやろうとしています。これを行うことで観点が指示できるので、適当に文章を突っ込んだらテキストが出てきたんだけど、そのテキストからは重要な情報が落ちていた、ということがなくせるということ。
あとここに表が載ってるんですけれども。観点ごとの表がまとまるので、単純に文章というかたちで要約するのではなくて図や表にして要約をするということができるようになる。ということで、この技術に今取り組んでいます。
ただ観点を学習するためのデータってすごく少ない。そこをうまくやるということで、自然言語処理の転移学習というところが今の僕の研究テーマになっています。我々の研究開発の活動もかなりオープンで、GitHubに掲載しています。総計のスターが728、これは日本でもわりと屈指の数かなという感じです。
我々が作ったプロダクトですね。ちょっと愚痴も入るんですけれども、我々のような大きな会社って、たくさんデータがあり「さあ、もう分析するしかねぇ」「モデル作るしかねぇ」っていう状態からだったりするんです。
大きい会社と言ってもお客さんのデータなので勝手に持ち出したりできないんですね。なのでデータのアノテーションは自分たちで取って、あとはアノテーションとして作ったデータのモデルの評価をちゃんと行うためのスクリプトを作るとかですね。けっこう地道なところから開発をしています。
ここには来月データセットを小規模ながら公開するんですけど、そういうようなデータセットとかですね。あとは機械学習モデルの性能を測ったりとか。当然動かせるものも載っているので、よろしければチェックしてみてください。
あとは『arXivTimes』という機械学習系の論文を読んで一言でまとめて共有するというような活動もやっています。これは月一で原稿もやっていて、現在も……ってか今日も投稿してから来ました。
機械学習を組み込むうえでの1つの問題
というわけでここからは本題です。まずは機械学習を使用する機会が多くなってるよね、という話をしていきます。
機械学習の技術の画期的なところは、研究ですごくインパクトが大きかったというだけじゃなくて、そのインパクトを起こした研究が手元ですぐに動かせるようになっているところです。そこがかなり大きく革新的なところだなと思います。
最近の研究は、研究がされた瞬間にそもそもGitHubで公開されるものも本当に多いですし、Kaggleの勝者の実行したスクリプトのKernelが公開されてたりする。ということで、すぐに動かせるコードが手に入るので、システムへの組み込みが容易になってきています。
実際にもう使った事例とかもけっこう出てきていています。
上の例はビクトリア州で盗難車両を発見したいということで約1億円かけてシステム作ったんですけど、それなんか週末にエンジニアがやったら57行（のコード）でできたとか。そういう例です。
あとはよく名刺を写真で撮って管理するサービスがあると思うんですけど、それを自前で作っちゃってですね。もうそういうことがわりと簡単にできるみたいになってきています。機械学習の判断の仕方は普通のプログラムと違うというところが組み込むうえでの1つの問題になってきます。
これは猫の写真なんですけど、猫を機械学習モデルに入れる。そうすると「90パーセント猫です」と、そういうような判断をしてくれる。
普通のプログラムの中だと「何パーセントの確率でこっちに処理する」みたいなことができないので。「猫なのか、猫じゃないのかはっきりしてくれ」という話になるわけですよ（笑）。
この確率的な判断というのと、どっちかはっきりしろというギャップを埋めないといけないというのが機械学習を組み込むうえでの注意点ということになります。
閾値決定は現実に即して
その方法としては2つあるんですけど、1つは「90パーセント以上いってたらいいだろう」みたいなかたちで閾値をもって判断するということが1つあります。
あともう1つよく使われるのは、「確率が最大のものだったらいいでしょ」という話ですね。こちらのほうがよく利用されるので機械学習の判断が確率的ということをけっこう忘れがちになります。
ただ後ろに続く処理が重要になるほど、最大のものに寄せるというわりと便利な処理というのはけっこう危険をはらむことになると思います。
例えばツイートが危険だったらツイッターアカウントを停止するという処理があるとすると。この場合「死ねー」みたいなことをつぶやいていると、機械学習モデルを入れて「つぶやきの確率が危険か危険じゃないか。危険のほうが大きかったら即停止する」と、そういうようなことをやる。
この場合だと最大のものを選びましょうとなると0.5を超えた瞬間にツイッターアカウントが停止されてしまうという話になると。これは当然困るわけですね。なので、一定の責任がある処理を行うときは、適切な閾値の設定が欠かせなくなってきます。
この閾値の設定って、機械学習モデルにおける精度の評価だけで決まるわけじゃなくて。ビジネス上の要件というものもけっこう大きく関わっています。
例えば、判断をミスするとユーザーが会社に乗り込んでくるとかそういうこともあったりすることです。そういう場合は、閾値はなるべく高めに設定しないといけないです。90パーセント以上じゃないと後ろの処理はやらない。そういうふうにしないと、会社を壊されちゃったりすると。
あとは、ちょっとでも可能性があったら捕捉したいという場合もあるんですね。こうやって「今日も1日がんばるぞい！」と気軽に言っちゃってるユーザーを全員捕捉して著作権法で訴えたいという場合は、ちょっとでもあったらなるべく、まあノイズがあるかもしれないけど把握したいという話になるんです。この場合は閾値は低めに設定しないといけないというかたちになると。
理論上良いと決めることはできるんですね。決める方法はいろいろあるんですけど。ただそれがビジネス上良いかと言うと、必ずしもそうではないという感じです。
機械学習の副作用
これ（スライドを指して）右下のほうに電話会社の契約のデータで閾値の設定によってどれくらいパフォーマンスが変わるかということを検証したページがあります。
機械学習を組み込んだシステムのパフォーマンスというのは機械学習モデルの精度だけではなくて、扱う側がその判断をどう解釈するかというところにも依存します。
つまり、「機械学習モデルの力を引き出すコードはこれだ！ 機械学習モデルの判断を0.81394を超えたらツイッターアカウントを停止する。これがユーザーにとっても我々にとってもベストかな」という話になっていくわけですね。
これはちょっといくらなんでもっていう話で、閾値は固定値でコードの中に書かなくても一応自動で調整する方法があります。
ただ、ここで言わんとしていることは、機械学習自体のモデルの精度だけではなくて、機械学習を利用する側の設定というのもビジネス上のパフォーマンスにおいて非常に影響があるという話です。
そういう話になってくると、機械学習モデルを更新しようとなったら、機械学習モデルだけを更新するのではなくて、機械学習モデルを扱う側も更新しないといけません。
さっきの例だと、ユーザーアカウントの停止を判断するための閾値というものを更新してあげないと連携が取れなくなっちゃいます。ということは、連鎖範囲というのを確認しないとつつがない運用はできないということになります。これは1対1の場合ですが、1対1の場合だけじゃないという話もこれからしていきます。それが機械学習の副作用です。
モデルの利用を通じた依存関係
機械学習モデルの連鎖範囲を把握するには2つの依存関係を明らかにする必要があります。1つはモデルの利用を通じた依存関係で、もう1つはデータを通じた依存関係です。この2つについて今から説明していきます。
まずモデルの利用を通じた依存関係です。「ユーザーの解約を予測したい」ということで、ユーザーの解約を予測するモデルを立てました。
これが続きしばらく時間が経って、「解約が予測できるということは逆に考えたら解約しなさそうなユーザーも予測できるよね」ということで、解約をしなさそうな人には「サービスの追加機能を使ってみませんか?」みたいな提案をすることにも使えました。
そのあと「解約を予測できるんだったら解約理由まで予測できないか」ということで、解約の理由を予測するモデルをベースに理由をさらに予測できるモデルを作ると。そういうふうに、当初1個だけの目的に使われていたモデルがだんだんといろんな用途で使われていくことになってくると、更新対象がどんどん増えてきてしまうということです。
作成したモデルが当初とは違う処理で使われていて、さらには作成したモデルをベースにデータがまだ少ない領域に流用するということもある。こういうモデルの利用というのも把握しておかないと、さっき言ったように、あそこのモデルは更新したけど利用先のモデルは更新してなくて判断がおかしくなったりということが生まれてしまうと。それがモデルを利用した依存関係性です。
データを通じた依存関係
続いて、データを通じた依存関係です。最初にサービスを立てた当初、使ってもらわないといけないので営業メール先を予測するときのモデルを作りました。当然、このときはなかなかユーザーがサービスを利用してくれない、というような情報がデータの中にもある状態です。
テレビCMを打ったりして、どんどんユーザーが契約してくれたので、この次のタイミングで解約防止メールモデルを作った。この解約防止メールモデルはテレビCMでどんどんユーザーが流入してきているときに作られたので、あまり解約防止しなくても継続してくれるというデータをもとに作られている。
そういうことはずっとうまくはなかなか続かないので、競合サービスがリリースされると当然解約が増えていく。解約理由の判断をより細かく予測するというときは、当然解約が増えている状況でモデルが作られる。
というふうになってくると、モデルが作成された時期によってデータの傾向というのが異なってくるわけです。データの傾向が異なれば当然機械学習モデルの判断も変わってくる。つまり同じデータソースの出自のモデルであっても判断傾向が異なるモデルというのがいつの間にか混在してしまうという可能性がある。
今回のケースだと、1番最初に作ったモデルはユーザーがあまり来ないことが前提なので、わりと悲観的な判断をする。その次に作られたモデルはテレビCMを打ったあとに作られたので、ユーザーがあまり解約しないんです。イケイケドンドン、「大丈夫大丈夫、防止しなくても！」みたいなイメージ。
同じデータが出自なのに下している判断がけっこう割れてるという自体が起こってしまう。
これは人間組織に置き換えるとけっこうわかりやすいです。
判断を行うということを1つの業務と考えると、機械学習モデルの作成というのはその判断を行うある部署を作るのとよく似ているんですね。その部署が判断のもとにするのが学習データというわけです。時間が経つにつれいろんな部署がどんどんできるわけですけど、機械学習モデルの世界で言うと、部署間で情報の共有というのは決して行われないですよね。
機械学習モデルというのは再学習を行わない限り判断基準が変わることはないので、まさにタコ壺化した部署がいろいろあるような状況というのが生まれてしまうということになってくる。システムの中で判断傾向がバラバラにならないためには、同じデータソースから生まれたモデルについて、新しいモデルができたら併せて更新しておかないといけません。
さっきのデータだと3つのモデルが時代によって使われていると思うんですけど、必要に応じて3モデルの同期をとらないといけないという話になってきます。この同期をとらないといけない事態が発生するというのが、データを通じた依存関係の話になります。
