こんにちは。久々の投稿です。
データサイエンスエキスパートの皆さんにお聞きしたいのですが、表題の件、どうやって防いでますか?
というのが、AIのプロジェクトって一般的なシステム開発と違って、まだまだプロセスが未成熟ではないですか?
ぶっちゃけ、データサイエンティスト任せになっているような気もします。
一般的に(かどうかはわかりませんが、少なくとも我々の身近な範囲では)は、AIプロジェクトってざっくりいうと
・活用部門がやってみようという
・データサイエンス部門がPoCを実施する
・結果、うまくいったらシステム化する
みたいな流れですが、PoCってあくまで「検証」フェーズなので、そんな大々的にお金もリソースも投入できる、ということはあまりないと思っています。
ぶっちゃけ、データサイエンティストが1~2名くらいでせっせと分析して、それをリーダーやらマネージャが評価する、という感じではないでしょうか。
(→そもそも、それが違うって話ならすみません。)
上記仮定が正しいとするなら、以下の保証はサイエンティストに任されることになってしまいます。
・前処理/特徴量エンジニアリングのプログラムの精度
・データ加工処理のセンス
・プログラムの検証
システム開発なら「バグ発生率」とかいろいろ評価指標がありますが、データ加工ってなかなか無いですよね。。。
ということで、孤高のデータサイエンティストの皆さんはどうやって、データ加工の誤りを防ぐような術を持ってらっしゃいますか?
参考までにディスカッションさせてほしいです。
@k.sakamoto さん
言われてみると体系化しているケースはまだ少ないと私の経験から思います。その中で私がアドバイスしていることとしては
理想としてはリーケージや過学習に関しては、データサイエンティストが知り得ないホールドアウトを持っておく
です。
最近はデータサイエンティストが全てのデータを見れるというのが当たり前になっていることが少なくないと思います。こうなると結局ホールドアウトをパーティションで設定していたとしても、そこにフィットするモデルになっていて、リーケージしていたとしてもちゃんと精度が出ているように報告されて見逃されてしまいます。
リーケージが問題となることは、過去データに過学習していて未知のデータに対応するモデルとなっていないことなので、ホールドアウトが正しく秘匿されていればそこでの精度は十分には出ないはずです(確率上たまたまはありますが、そのような状況にならないようにただ取るのではなく、十分なホールドアウト量を確保することも重要になります)
特徴量エンジニアリングの不具合はソフトウェア工学と同じようにユニットテストをすることも良いかと思います。その特徴量から有効なデータ範囲や分布をぶつけて正しく変換するような判定ロジックを設けておく、正しくエラーを返すなど。
特に前処理後に想定以上に歪なヒストグラムとなるケースでは、多くの場合に変換のロジックミスや定義ミスがある場合が多いので、分布の判定なども有効かもしれません。