実際に起こった話
とある機械学習案件で、最終的に作成したモデルのアウトプットが満足いかないという報告がありました。
精度を見る限りでは特に問題はなさそうでしたが、思っているものが出力されていないということで、結局、出戻る形で一部のシステムを組み込むことになりました。
「なぜこのようなことが発生したか？」を改めて考えてみると、モデルの評価方法を細かく定義していなかったことに気づきました。 何をもってよしとするかをざっくりとしか考えられていなかったことが敗因でした。
機械学習案件の特質な点
機械学習の案件は、通常のアプリケーション開発とは少し異なり、時間をかけて開発をすれば、最終的に目標とするものが完成するという保証ができません。
どういうことを精度の視点で考えてみると、accuracy（正解率：予測した中でいくつ当てられたか）が90%になるものを納品するという約束は、過去に社内で事例がなければ、やってみないと分からないのです。
そのため、PoC（Proof of Concept：概念実証）で動くのが望ましいです。いきなり本開発に入ってしまうと、想定していたよりもトライの内容が難しく、精度が出なかった場合に納品ができないことになります。
精度向上のために再度、データに処理を加えたりすることになりますが、それでも目標値に辿り着かないことは十分に考えられます。
すると、必然的に機械学習案件に必要な要件定義が見えてきます。
何をもってよしとするか
弊社で開発しているチャットボットの場合、
「明日のスケジュールを教えて欲しい」
という入力に対し、どのような回答を返せばよしと評価するのかを事前に目標を決めて開発をしなければなりません。
この評価方法を決めずに、ふわふわな状態で開発を進めてしまうと、
「明日のスケジュールを教えて欲しい」
という入力に対しての返答をよしとする人とそうでない人が現れて、それぞれで争いが起きます。
どちらに対応するかは別の問題として、本当にそれでよいのかという決着をつける事が難しくなります。
こういった際に、あらかじめ決めておいた評価方法があるのかないのかでは全然違ってきます。
「評価方法では目標を達成しているので問題ありません」と堂々と言う事ができるのです。
ここでいう評価方法は、例えば、
- accuracyがN以上
- あるclassのprecisionやrecall、F値がN以上
- 人によるチェックで100個中、70個がよいと判断できるもの
- その他、問題特有の評価値
など様々、思いつきます。
上記のように、機械学習案件では開発の前に必ずこの評価方法を定義しないと後々大変なことになるのはお分かり頂けるかと思います。
クライアントにとっても重要
「こういった評価を行うために、このような開発をします」
また、
「このような評価をします」
ということを社内で定義して、クライアントに提示できることで、OKが頂けた場合は社内だけでなくクライアントにとってもよい状態となります。
何を基準に開発が進んでいるかが明確になるため、機械学習特有のもやっとする部分がなくなり、「今何が行われているのか」を理解しやすくなります。
さらに理想的なのは、クライアントが専門家である場合は、評価方法に対するインプットを頂いた上で評価方法の吟味を行うことです。
そうすることで、より確かな開発を進める事ができます。
まとめ
評価方法を決める際、役職ごとに意見が異なり揉めることがあるかと思いますが、社内とクライアント双方が満足いくものを開発するためには、評価方法はじっくりと内容をつめないといけません。
ここをうやむやにしたまま開発を進めると、お互い不幸なことになります。
N2i の機械学習チームでは、事前に評価方法を定めるということに重点を置いていきたいです。
