こんにちは。Sansan DSOC 研究開発部の保坂です。今年の春に新卒で Sansan に入社しました。最近、個包装の焼きあごを大量購入したのですが、おやつとしてもおつまみとしても食べれますし、カルシウムもたっぷり含まれているので在宅勤務のお供*1におすすめです。
さて、私は入社してから、実際に研究開発プロジェクトに携わってきた中で、学生時代とは異なる視点で解くべき問題の設定や機械学習システムの設計をしていく必要があると感じました。以下の記事で紹介されている新卒研修でこのようなトピックについてお話していただいたのですが、業務を通じて、改めてその内容を実感しました。
今回の記事では、整理も兼ねて、研究開発プロジェクトにおいて、新入社員という立場から私が重要だと感じたポイントについて振り返りたいと思います。
アウトプットの可視化
業務をしている中で、これがトップクラスに重要だと感じたことです。ここで、アウトプットを可視化するということは、散布図を描いたり、それに識別境界を重ねるということではありません。データの分布とそれに対するモデルの挙動を観察することは大切ですが、今回したい話とは異なります。
私が感じたことは、利用者が触れる形でアウトプットのイメージ化を行うことの大切さです。推薦アルゴリズムを開発したのであれば、実際にユーザーに推薦されるアイテムリストを作成することがこれに該当します。機械翻訳システムを構築した場合には簡単なサンプルを作ってテストできるようにすることが望ましいと考えられます。これにより、プロジェクト内の営業や開発のメンバーにモデルの価値を容易に理解してもらうことができます。
実際の業務で、学術論文のように、背景や仮定、アルゴリズムを順に追って説明したとき、知りたい情報はそこではないということがありました*2。しかし、アウトプットのイメージを共有すると、やろうとしていることをすぐに、そして正確に理解してもらえるようになり、議論が進みました。最後の一手間を加えることで、他部署との連携が一気に取りやすくなったのです。
また、仕様設計をしているときに、他メンバーと仕様の解釈に齟齬があることに気づかないまま、設計を進めそうになったことがありました。振り返ると、モデルの出力に関して簡単な例を提示して議論をしていればそのような事態は防げたと思います。細かい部分でも、例を出すことの重要性を感じました。
考えてみると、これは研究開発に限らず、部署間の連携で起こりやすい問題なのかなと思いました。議論は互いの共通の言語で進めるべきで、アウトプットのイメージは多くの人が理解しやすいものなのだと思います。
評価指標の設計
あるシステムの中に機械学習モデルを組み込むとき、モデルの出力のみを評価するだけでは不十分な場合があります。このような場合には、システムの意義を理解し、システムとしての出力を考慮した評価指標の設計が必要になってきます。
例えば、商品をユーザーに推薦するアルゴリズムを検討する際に、安価な商品を推薦しやすいアルゴリズムと、高価な商品を推薦しやすいアルゴリズムがあるとします。このとき、前者のアルゴリズムの方が多少推薦の精度が高かったとしても、企業の売上という側面からは、後者のアルゴリズムの方が優れている場合があります。
私が実際に業務でこのような評価指標を設計したときは、サービスのログを利用してシミュレーション的に評価値を算出しました。モデルの精度から逆算してサービスに関わる様々な値を算出すると、サービスにモデルを組み込んでいる実感が湧いてきます。まだやっていないのですが、今後は A/B テストもやってみたいです。
また、このような評価指標を設計することは、営業や開発のメンバーと議論をする際にも有効です。営業や開発のメンバーが気にしていることは、モデルの精度そのものではないことが多いからです。逆に言えば、営業のメンバーや開発のメンバーがそれぞれどのような数値を気にしているかということを理解しておく必要があります。
エラーの担保
どのような問題設定であっても、常に 100% の精度で予測が可能なモデルは存在しません。ここで、大学の研究では、「100% に向かいモデルの精度を高めていく」ということにフォーカスすることが多いです。対して、日々の業務で実感することは、100% との差分、つまりモデルが吐き出すエラーをどう担保するかがより重要になってくるということです。
サービス上問題のないエラーであれば、そのエラーを無視できるかもしれません。しかしながら、サービスの都合上受容しがたいエラーがある場合は、エラーをどう担保するかを考えなければなりません。例えば、確信が低い出力に対して人間のチェックを入れることで、致命的なエラーを防ぐことができると考えられます。昨今話題となっている自動運転技術も、ドライバーが周辺状況を監視する義務があり、人間により致命的なエラーを防ぐ仕組みになっているといえます。
エラーの担保について考えると、大学時代に受講していたリスクマネジメントの講義を思い出します。リスクマネジメントでは、リスクへの対策は以下の4つに分類されます。
- 受容：リスクを受け入れる
- 軽減：リスクの発生確率を抑える
- 転嫁：第三者に責任を転嫁する
- 回避：リスクの原因を除去する
これをモデルが吐き出すエラーへの対策に置き換えて考えてみます。
- 受容：エラーを受け入れ、無視する
- 軽減：エラーの発生確率を低くする、すなわちモデルを改良する
- 転嫁：モデル外のシステムに責任を転嫁する (e.g. 人間のチェック)
- 回避：モデルの採用を取りやめる
また、リスクマネジメントにおける、「リスクの影響度と頻度の組み合わせ」と「有効なリスク対策」の対応関係*3をエラーへの対策として考えてみた図を以下に示します。影響度の大きなエラーが高い確率で出るモデルは不採用にした方が良いということを考えれば、少し納得感のある図になっていると思います。
こうして整理してみると、研究開発プロジェクトにおけるエラー対策というものは、リスクマネジメント的にいえば、「軽減」と「転嫁」が組み合わさった場合が多いことが想定されます。「軽減」する場合にはモデルを改良する必要があり、技術的にある程度の限界がありそうです。「転嫁」する場合にはモデル外のシステムに責任を転嫁するため、そのシステムに負荷をかけることになります。挙げた例では、人間がチェックすることによる金銭的なコストが発生します。したがって、実際のプロジェクトでは、両者をバランス良く運用していくことが大切だと思いました。
モデル評価/改修体制の構築
モデルを開発しシステムに組み込んだら、モデルを運用するフェーズに入ります。多くのシステムでは、扱われるデータの性質が変わっていくことが想定されます。例えば、コロナウイルスの影響で、自粛する人々が増え、あるオンラインサービスを利用するユーザー層が大幅に変化することを考えます。そのような場合には、開発したモデルを使い続けるのではなく、適切なタイミングでモデルの性能を評価し、必要に応じてモデルの改修をすることが望ましいです。
モデルの評価には、最新の評価データセットの構築、評価指標の選定、改修する基準の設定が必要です。この仕組みを整えることで、モデル間の比較がしやすくなり、モデルの構築や改善に集中できるようになります。実際に業務では、モデル開発を行う前に評価の仕組みを整えることを優先しました。これにより、モデルの比較・検討もしやすくなり、結果として開発のスピードが上がったと感じました。
モデルの改修は、パラメータの調整のみに留まる場合から、アルゴリズムそのものを変更する場合まであります。いずれの場合も、その変更を評価結果の変化とともに記録しておくことが重要だと思います。実際に、ドキュメントに「解けるようになった問題」「解けなくなった問題」を改修内容とともにまとめておくとチーム内の意思疎通が図りやすくなりました。
DSOC の研究開発部は様々な研究課題にチャレンジしていますが、今まで開発してきたシステムを運用していくことは、新しいことにチャレンジすることと同じくらい大切だと思います。これからも、評価・改修が容易なシステムの設計を心がけていきたいです。
終わりに
今回の記事では、私が研究開発プロジェクトに携わった約4ヶ月間で重要だと感じたことについて書きました。実際には書いた話以外にも、開発環境の構築や開発の仕方など学ぶことが数多くありますが、今回は割愛させていただきました。振り返ってみると、アルゴリズム設計に没頭していた学生時代とはやっていることが大きく変わったなと思いました。しかし、本質は変わらず、開発技術やプロジェクト推進術を身につけていく一方で、技術調査や研究を行う時間を確保していく必要性を感じています。
次回、機会があれば、興味をもっている論文や技術について執筆したいと思います。ここまで読んでいただきありがとうございました。
buildersbox.corp-sansan.com
buildersbox.corp-sansan.com
buildersbox.corp-sansan.com
*1:在宅勤務の際はおつまみとして食べないようにしましょう。
*2:このような情報自体はとても価値があるので、積極的にドキュメントに記録しておくのが良いと思います。
*3:K. Gericke, L. Klimentew, and L. Blessing, "Measure and Failure Cost Analysis: Selecting Risk Treatment Strategies", in ICED, 2009. Measure and Failure Cost Analysis: Selecting Risk Treatment Strategies
