タイトルの通り、機械学習パイプラインのデバッグを行うツールを開発した論文「Debugging Machine Learning Pipelines」を読んだ。
International Workshop on Data Management for End-to-End Machine Learning というワークショップで発表されている。
概要
機械学習システムの失敗原因はコードのバグや入力データ、パラメータ設定など様々な原因が考えられる。特にパイプラインが複数になったりすると原因箇所の特定が非常に難しい。
そこで、ML Systemにおけるfailureの原因を推測して簡潔な説明を提供する仕組みを開発。
具体的には、前回までの実行時の情報と結果や、まだテストされていないパラメータ値を提案することで原因を突き止めやすくする。このツールによって、データ、データ型、ライブラリバージョン、パラメータ値などの側面でパイプラインをチェックできる。
実際のアルゴリズムとしては、いくつかのパイプライン実行からエラーっぽい実行結果を抽出して、未テストのパラメータ群をある時間制約の中で実行して原因を突き止める。最終的に、複数の原因が見つかったら、最小限の原因をブール式の形で提示する。
処理の説明
色々と定義が書かれているが、簡潔に言うと、以下の通り。
- MLパイプラインのプロパティを設定してCVの値が一定以上なら成功とする。
- 成功した時のパラメータ、失敗した時のパラメータからどのパラメータのときに失敗するのかの候補を最小限のブール式で提示する。
具体的には決定木のように条件文を構築して、上手くいった場合のプロパティと失敗した場合のプロパティから最小の原因となるブール式を求めている。
作成された決定木は重複部分が多く出てきて可読性が悪いため、Quine-McCluskeyのアルゴリズムというものを使って、まとめられる部分をまとめてブール式にする。
既存の研究との違いは、このML Debuggerは上手くいかないケースを探すことにある。既存研究は上手くいくプロパティの設定を探すが、著者らは最小の原因を探すためには上手くいくケースはあまり役に立たないためであると論じている。
実験結果
FineOneという原因の少なくとも一つを当てるタスクではF値1.0と他のフレームワークよりも良い結果が出ている。試行回数を制限するケースではF値は1.0よりも下がるが、依然として他のフレームワークよりも良い結果が出ている。全ての原因を見つけるFindAllというタスクでも同様の傾向が出ている。
他のフレームワークとの比較を考察すると、最小の原因群を出すのが苦手だったり、否定や不等式が扱えないなどの欠点があることが分かった。
所感
他のフレームワークはベイズ最適化のような手法を使ってパラメータを探索するものもあるというが、本手法は特にベイズ最適化などを用いることなく、失敗したところの近傍を調査するという手法で良い結果が出ているのは面白い。
データサイズが大規模になると、このようにイテレーションを回して原因を追及するということが、本質的に難しくなりそうなのでそのような場合を想定した研究を探してみたい。
著者らは今後の方向性として、何らかの実行環境に組み込んでユーザに使ってもらうことを考えているというので、近い将来このようなフレームワークを使って機械学習パイプラインをデバッグする時が来るのだろうか。
