論点バカになれば、天才達に勝てる。
なぜ凡人・ド文系の僕らが、天才・理系集団に勝つことが
できたのかシリーズ②
SAS Analytics Hackathon 2019、大会当日の様子*1 SAS Japanの小林さんから、ハッカソンの課題(=モーターの故障予兆の検知)を説明して頂いた。
論点バカな僕たちは、実を言うと、大会の序盤で、もう優勝を確信していた。
では、始めてください。二日間楽しんでいきましょう!
SASの小林さんから号令が鳴らされ、大会がスタートした。
ハッカソンのテーマは、「モーターの故障予兆をリアルタイムに検知する仕組みを開発せよ」というもので、開発期間は、2日間 (= 計15時間) の超短期戦だった。
たぶん、(僕らを含めた) 多くのチームが、その開発期間の短さに、焦っていたと思う。なぜなら、この「故障予兆の予測」は、普通、3週間くらい、じっくりと時間をかけて、開発を進めたいテーマだからだ。
ただ、確かに「焦心・焦燥感」は全チーム共通して持っていた。けれど、出だしの行動 (+会話) は、僕らとその他のチームでは、かなり対照的だった。 まず、僕ら以外のチームの、出だし(会話・行動)は、下記のような感じだった。
他チームの会話
時間がないから急がないと。
まず、FFTしないとね。(生データだと)ノイズがたくさん含まれているはずだから。その後は、正常時の周波数の振幅(平均)から現在の運転の振幅を引いて、それを特徴量として加えて…(省略)
(その後)すぐに、作業 (=開発) スタート👩💻👩💻👩💻
異常スコアによって運転モードが違うはずだから、とりあえず、階層ベイズ*2でモデリングしてみるわ。モーターの運転挙動は○○○になっているはずだから、XXXで定式化して…(省略)
(その後)すぐに、作業 (=開発) スタート👩💻👩💻👩💻
というような会話をしているチームがほとんど、であった。つまり、
「まず、FFTしないとね」という作業 (=タスク)
「とりあえず、階層ベイズでモデリング」という打ち手
で、行動(=分析・開発)をスタートしていた。
一方、僕らは、こういった作業ドリブン・打ち手ドリブンな会話に、聞き耳を立てながら、
勝ったわ、絶対優勝できる。
と、静かに確信し、コッソリと下記のように、行動を開始していた。
僕らチームの会話
(センサーの挙動のプロット見ながら) そもそも、正常な期間でもさぁ、周期性もなければ同期もしてない期間あるよね。
こういう、「正常なんだけど、不安定な期間」に対して、どう対処しようか?
このモーターの運転ロジックってさ、仮にフィードバック制御だとしたら、オーバーシュートだったり、ハンチングが発生する場合あるよね。これって、波形的には、異常な挙動に見えるけど、故障を示唆するものではないよね。
こういった期間の時系列、どう加工しようか?
キーは「データの加工」だよね。その観点で、各自、サブ論点考えようか!軽くデータを見つつ、各自でしばらく(1-2時間くらい)考えて、最後に、みんなで最終化しよう。
(その後)各自、ワードやホワイトボードで、ひたすらサブ論点を考える。
つまり、僕らは、
どの問い (=サブ論点) に答えれば、予測精度が圧倒的に高い、高性能なモデルを開発できるか?
を、何よりも、まず先に考えた。
開発環境を開かず*3、ひたすら、ひとりひとり、ワードと向き合いながら。
途中、僕らのチームのメンターをしてくださったSASのリュウさんから、「大丈夫ですか? 何かわからないことや、困ったことがあったら、いつでもサポートしますので、気軽に頼ってくださいね。」と、大変ありがたい、声がけを頂いた。
たぶん、コンペ開始からしばらく経っても、僕らはずっと、コーディング=開発をせず、ひたすらワードとホワイトボードに向き合いながら、「論点、論点、あー論点」と、唱えていたから、心配してくださったのだと思う。
それくらい、僕らの出だしは、他のチームと比べて、異質だった。 そして、コンペ開始から2時間後、僕らは、サブ論点を最終化し、解くべき問いを定めた。
予測精度を上げるためには?*4
− 何がわかれば解けるのか?を示す、2+2のサブ論点
1. そもそも、データの“産みどころ”であるこのモーターは、どのような挙動・波形で運転しているのか?
頂いたデータの期間中に、運転データの生成メカニズム (=確率分布) が、大きく変化するようなイベントは、どこかで発生したか?
クリック/タップでポップアップ表示
センサーデータに周期性がなく、複数センサーで制御が同期してないなどの「正常だが、不安定な時系列」は、どこかで存在しているか?
クリック/タップでポップアップ表示
2. 異常スコア (=異常度合い) が低い時と高い時、それぞれで、モーターの運転挙動には、どんな特徴があるのか?
そもそも、普通でない (=アブノーマルな) 波形は、モーターのような精密機器には付き物で、その波形の全てが異常状態を示唆するものではないが、SASさんはどのような波形を ”異常” と定義しているのか?
クリック/タップでポップアップ表示
モーターの故障予兆には関係のない「良性な異常」は、運転データから確認できるか? また、それはどのような波形か?
クリック/タップでポップアップ表示
これらの問いを作る際、僕らには、強く意識していたことがある。
それは、
“一点豪華” 万歳!!
という、心がけ、精神である。
つまり、(2日間で) 天才達に勝てるような圧倒的に高品質なモデルを開発するために、どの問いを深掘りすれば (=何を捨てれば)、いいのか? という、MECE (=漏れなくダブりなく) なんてクソ喰らえ!という心意気で臨んだ、ということだ。
クリック/タップでポップアップ表示
この「行動=サブ論点を立てる」と「精神 = ’一点豪華’ 万歳!」を、何よりもまず初めに行ったおかげで、やるべきことがはっきり見え*5、「凡人・ド文系な僕達が、天才!理系集団に勝つ」という下克上が達成できたわけなのだ。
論点の立て方=お作法は「フェルミ推定の技術」から学ぶことができる
*1. SAS Japanさんの公式YouTubeチャンネル上で、オープンに公開している動画から、引用させていただいた。大会当日の様子がわかるハイライト動画: https://www.youtube.com/watch?v=Znzdw3UwSMk&list=LL
*2. 正確にいうと、そのチームは「階層ベイズ」という言葉を明示的に使っていたわけではない。モーターの運転挙動や故障発生因果メカニズムを仮定して、定式化しようとしていた。いずれにせよ、初期の段階でこのレベルのモデリングをやろうとするには【モーターの運転に精通】×【確率モデリングに関する圧倒的経験(技術力)】がないとできない。ホントに、すごすぎて、ド文系の僕は、ただただ尊敬するしかない。
*3. 正確に言うと、サブ論点を具体的に考えるため、データの集計や可視化のコーディングはした。ただ、それは、どれも20秒で終わるようなものなので、開発環境を開いていないと表現しても、大袈裟ではないと思う。
*4. コンフィデンシャリティを遵守するため、固有名詞を避け、若干、単純化/一般化した。実際は、3+6の論点を立て、より具体的に、リアルに考えていた。
*5. サブ論点が出揃ったら、その問いに答えるためのタスク=分析を、それぞれ分担して行った。例えば、動的時間伸縮法(DTW)による異常波形のクラスタリングなどだ。(分析の内容自体の共有は、別の機会に移したい)