ACL2020のBest Paperが胸に刺さった

ふと気になってACL2020のBest Paperを調べてみたら、現状の課題にフィットしそうだったので少しメモを残す。

Beyond Accuracy: Behavioral Testing of NLP Models with CheckList
- Marco Tulio Ribeiro, Tongshuang Wu, Carlos Guestrin
- Sameer Singh Association for Computational Linguistics (ACL), 2020
- https://www.aclweb.org/anthology/2020.acl-main.442/

これは何？

機械学習によって生み出されたNLPのモデル評価としてよく行われているのはデータをtrain-validation-testの3つに分け、とあるmetrics(特にaccuracy)を測るhold-outと呼ばれる方法である。しかし、この方法は以下の理由により不十分だと筆者たちは述べている。

・trainとtestに含まれるbiasが不変なので、実世界のデータと比較するとパフォーマンスを過剰に評価してしまう
・単一のmetricsで評価を行うのでデバッグが難しい

これらを解決するためにいくつかの手法が提案されている(1章のIntroや5章のRelated Workを参照)が、特定のtaskに依存しているため包括的でない。これを解決するために今回CheckListと呼ばれる手法が提案されている。これはSoftware開発におけるテストとして使われている"behavioral testing"(aka black-box testing)の方法をNLPのモデル評価に適用したものである。この手法をNLPのコースを卒業した方かそれと同等の能力を持つ方に使ってもらったところ、2倍以上のテストケースを作成でき、約3倍のバグを発見できたと述べられている。

CheckList

ざっくりと言ってしまうとテストケースを作成するためのフレームワークという感じのものである。CheckListではNLPモデルのいくつかの特性( Capabilities)ごとにTest Typeに基づいてテストケースを作成させるようにしている。ここでいうCapabilitiesをいくつかご紹介する。

・Vocabulary+POS: 語彙や語彙の種類の影響
・Taxonomy: 同義語や反対語の影響
・Robustness: typoや関係のなさそうな語彙の影響
詳しくは3.1節を参照

これらのCapabilitiesに対してTest Typeに基づいてテストケースを設計している。Test Typeとして本文中では以下の3種類が提案されている。

・Minimum Functionality test(MFT):
　ソフトウェア開発におけるユニットテストのようなもの
　入力に対し、想定される出力がされるかを確認する
　e.g.) Sentiment Analysisにおいて入力に否定表現が存在した場合出力が
　適切に入れ替わるか　
・Invariance test(INV):
　入力に摂動を加えたときに出力が不変であることを確認する
　e.g.) NERにおいて地名と検出されるところで他の地名に変更しても
　正しく地名と検出されるか
・Directional Expectation test(DIR):
　入力を変化させたときに出力の変化が想定されるものかを確認する
　e.g.) Sentiment Analysisにおいてネガティブな入力にさらにネガティブな
　入力を加えたときに出力が変化しないか

このようにCapabilitiesとTest Typeに基づいてテストケースを作成していくのだが、テストケースを作成するためにはNLPモデルに対する入力と想定されるふるまいを定義しなければならない。これをスクラッチで作成するのはかなり手間がかかるのでCheckListではテンプレートを使うことを提案している。以下のような例である。

テストケース:
　Sentiment Analysisにおいて入力に否定表現が存在した場合出力が
　適切に入れ替わるか
テンプレート:
　"I {NEGATION} {POS_VERB} the {THING}."
プレースホルダー:
　{NEGATION} = {didn’t, can’t say I, ...}
　{POS_VERB} = {love, like, ...}
　{THING} = {food, flight, service, ...}

この場合、プレースホルダーに設定された単語集合の組み合わせ数だけ入力が作成できる。これに加え、CheckListではMasked Language Modelによるプレースホルダーに入りそうな語彙のサジェストやWordNetを使用したその拡張等によりテストケース作成を手助けする方法を提案している。詳しくは本文中のTable1~3をみてもらうとわかりやすいと思う。

ここまでCheckListの説明をしてきたが、このCheckListはPython moduleとしてPyPIに公開されており、手軽に試すことができる。

marcotcr/checklist

サジェストに使われるMasked Language ModelもMultilingualのものに対応しているので現状でも日本語で使用することは可能そうである。

終わりに

個人的には以下の2点が良いなと思っている。

・プロダクション環境で動かす上で最低限満たすべき機能を担保しやすい
　実環境で機械学習のモデルを動かす場合、最低限こういう種類のデータは正しく推論して欲しいと言った要求があると思う。仮にその要求を満たさない場合、ちょっとしたヒューリスティクスを追加したり、違う観点のモデルを追加したりする必要がある。このようにモデルを一機能としてみた場合に改善のための議論がしやすくなるのはメリットだなと感じた。
・テストケースの再利用がしやすい
　実環境におけるモデル改善で最も怖いのは今まで正しく予測できていたケースが予測できなくなることである。実装時には改善したいテストケースには着目するが、今まで正しく予測していたテストケースは軽視しがちである。この点に関して単一のmetricsを用いているとこういったデグレを検知しづらい。(デグレ以上に改善ポイントでの正解率が上がった等)これに関して機能ごとにテストケースを作成しておくと今まで実行していたテストケースに対するエラー率を都度確認することができる。
　加えて、モデルの修正によって不必要になったテストケースを削除する等のテストケースのメンテナンスもしやすくなる。私はtrain-testを別々のデータセットとして用意することがこれまであったが、モデルの定義が変更になった場合testケース全体を見直す必要がある。この点に関してCheckListの場合はCapabilitiesとTest Typeの組み合わせで作成されたテストケースごとにメンテナンスができるので高効率であると考えられる。

今後も実環境で機械学習によって作成したモデルを運用するために必要なノウハウが多く広まっていけば良いなと思う。