#お品書き
ご覧くださりありがとうございます。
企業でデータ分析や機械学習関係の何でも屋をしている者です。
本記事は実務的な機械学習プロジェクトに関わる中で経験した 苦い思い出 貴重な体験をお話させていただきます。
機械学習やAI,データサイエンスという言葉が未だ独り歩きしているように感じます。
- 依頼者の「きかいがくしゅう」に対する勘違いで発生した問題
- 大幅な手戻り
- 長時間かけて作った使われることのない検証・モデル
- 消える案件
当然だろって思うような話でも人の知識は広く狭く、また玉石混交です。
今回は色々な体験・聞いた「しくじり談」を晒し共有します。
#前菜：管理系の失敗編
##管理1. 「機械学習できる」ってだけで業者や人を選ばない
- 機械学習って言っても分野が幅広い
- 仕事を外注する・共同研究相手を選ぶ・メンバを採用する 時には「何をしてほしいか」事前によく議論すべき
- 時系列データサイエンティストが深層学習使って画像の分類ゴリゴリできるかっていうと違うよね
業務中でデータサイエンスが活躍できる場が極一部であるように、データサイエンティストの得意分野も尖っている事を認識しておく
##管理2. 分析過程は証拠レベルで分かりやすく残しておこう
- 機械学習って分析段階、試作モデルは個人分析になりがち
- あの分析どうなった？とか一年前の分析結果を聞かれる
- 掘り出しやすいようにプロジェクトごとにデータ・スクリプト・資料のフォルダ分け
- パッケージのバージョンの記録
- 生データ・加工データ・抽出データの条件(SQL文・抽出日・ソースDB)残す
- リーダブルコードである(分かる変数名、コーディング規則、再帰的な代入、コメントアウト、繰り返す処理は関数に)
- コードが何しているか説明できるように(コメントアウトでデモコードと実行結果を入れておく等)
誰も見ないから。じゃなく、一年後の自分が滅茶苦茶苦労するので自分のために
##管理3. 案件には根本から入ろう
- とりあえず投げられたデータをひたすら分析するのはよくない
- コンペみたいに綺麗に投げてくれることは稀
- 分析し始めてモデル作っている時に
- 追加で変数が増える
- 予測対象が変わる
- 評価指標が変わる
- などなどコーディング以前の問題が出てくる
- 課題設定の時点から入るとおかしな部分や不足データに気づきやすい
振り出しに戻って心が折れないためにも、分析者であると同時に課題設定者になろう
#副菜：認識不足の失敗編
##認識1. 初めにデータがあった。は注意
- 初めに、データがあった。データは課題とともにあった。ならまだOK
- 「データがあるから"何か"出来るだろう」は失敗する
- "何か"と言う人が指すものは"手書きpdfの記録書"や"属人的なメールboxの中のCSV"だったりする
- データの前処理以前に集めることに労力が必要
- 整合性も確認しなければならない
- マイニングするにしても方向性がわからない
- データのドメイン知識が強くないと課題発見は難しく分析・エンジニアと遠いこともしばしば
課題整理、ロジックツリーを書いて「何のデータが必要か」から「データはどこに、どんな形式で在るか」を考えよう
##認識2. データの品質について考えよう
- データがあっても正しいデータなのかを自分でも担保する
- 作図したものが意思決定に使われる事を想像して
- joinミス
- 計算ミス
- 変数の理解
- を今一度確認する
分析結果や精度でなく、意思決定に使う時のリスクに責任を持つ覚悟が必要
##認識3. データの背景について考えよう
- 実はサーバーテストの都合でダミー入れてました
- 各店舗から注文が入る日を予測したいのに、営業さんによっては貯めてまとめて入れたりする
- 手打ちだから信用ならない
- ある年から導入したから、それ以前のデータは適当に入れている
- 寿命分析したいけど、記録に残ってない修理とか実はある
業務(ドメイン)とデータの関係を知り、対象範囲のドメイン知識とデータに一番詳しくなる
##認識4. 機械学習・分析だけでいいってもんじゃない
- 機械学習・分析は相手が結果を理解しにくい
- 理論的な理解が難しい
- 現状の業務を多少変更する必要があり導入に拒否感を感じられる
- 現状と導入後の改善のシミュレーション結果を作ったり
- システム化まで構想したり
- アプリ強い人にデモ作ってもらったり(自分で作ったり)
- 現行システムと喧嘩しない仕組みを考える
- モジュール化してモデル取り換えられるよう設計する
作ったモデルや結果が自分の子供だと思って独り立ちまで面倒を見る
##認識5. 結果を乗せりゃいいってもんじゃない
- 結果報告にはコードを取り除いてわかりやすく説明
- わかる人の範囲ではSQLや分析環境を付ける
- 図を書いて張って終わりでなく、解釈までが分析の仕事
中学生にわかる説明を心がける、あとはスライド術
#主菜：技術的な失敗編
##技術1. データを集めりゃいいってもんじゃない
- 画像認識を行っている時に精度が上がらなかった
- データがあれば精度が上がる、と言われて画像をたくさん集めた(撮影した)
- 結果はモデルが単純すぎるのが問題で元のデータ数でも十分に効果は出た
- モデルのバイアス・バリアンスを確認しよう
- 最低限、交差検証の知識をつけよう
- データを集めてモデルを作った
- 現場ではうまく精度が出なかった
- 見に行くと日光の当たる環境で別のカメラを使って撮影していた
モデルの問題・画像の問題・使われ方の問題 問題になりそうな箇所をアセスメントしよう
##技術2. 検定で有意ならいいってもんじゃない
- 複数種類の新素材を使った製品開発しました
- 従来品よりα=0.05で耐久性の差が有意でした
- 実は有意になるまで実験を繰り返しました
- 100変数の重回帰の結果、影響のある変数は1から5列目でした
- この5変数を使えば目的変数が説明でき、予測できます
Ｐ値ハッキングダメ絶対
5%誤るってことは、100変数あったら関係ないもの5つとってくるよね
多重比較の検定は有意で無いものを取ってくるので騙さない騙されないための検定、αの補正や階層モデルを勉強しておこう
##技術3. とにかく試せばいいってもんじゃない
- モデルを作ってるけど精度が上がらない
- 画像のトリミングが甘かったかもしれない
- 教師ラベル付けが間違っていた
- パラメータが最適でないのかも
- 全部修正してもう一度走らせてみよ
修正するのは一か所づつ、不安点は網羅的に羅列して一つづつ潰す。本当に改善すべき部分が見える
##技術4. 精度がよければいいってもんじゃない
- モデル作ってみました
- 学習回数を増やしたら精度が上がりました
- 精度は80%でした
- 目標精度に達してます
訓練の精度を見てませんよね
検証・テストを正しく割り振ってますか
時系列をランダムに割り振ってませんか、バックテストも試しましたか
##技術5. 評価指標だけ目指せばいいってもんじゃない(複数)
- R2乗値が良いので成功です
- 実は列数多すぎ
- 実は過学習
- 正答率が良いので成功です
- クラスに偏りがあってすべてを片方のクラスに予測する適当モデルでも精度99.9%になる
- 医療の診断システムなので何が原因の間違いか知りたい
- 正常も多少異常と判断していいから異常を絶対見逃したくないモデルだった
- MAEが低いので成功です
- 実は難しいことしないで平均値・移動平均で見たほうが当たってる
- 時系列なら波を捉えているかが大切なのに予測値のはずれ具合だけで判断してしまっている
- そもそも値のスケールが大きい予測はMAEも大きく、スケールの小さい予測はMAEも小さくなる
- 評価指標は良いけど実運用できないモデルだった(もっと先を予測したいのに一つ先の予測精度だけ上げていた)
評価指標と課題が事前にあっているか調べておく
#水菓子：おわりに
失敗談など上げたらきりがないのですが、
こうして失敗を覚えて次に活かせると失敗にも価値が出てきて良いものですね
皆様の失敗談と改善談も聞いてみたくなりました。
(コメントあると嬉しい)