1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

自動運転ワークショップで、相関を因果と読み違えていたことに発表6時間前に気づいた

1
Posted at

tl;dr

  • ティアフォーの学生向け Autoware ワークショップに5日間参加しました。専門は音声で、自動運転は初めてです
  • テーマは「カメラ画像だけで、コース上の物体の種類に応じて挙動を変える」E2E モデルでした
  • 3日目、物体に近いほどアクセルが緩むというきれいな単調減少のグラフが出たので、反応していると解釈しました
  • 4日目の朝、物体を置かない条件を足したら同じグラフが出ました。物体を固定座標に置いていたので、「物体までの距離」と「コース上の位置」が同じ変数になっていました
  • ただし測り直したら、物体ありと無しの差分には反応が残っていました。結論は合っていて、根拠だけが間違っていたという話です
  • MLOps 的に評価基盤を作り込んでいたおかげで測り直せましたが、交絡そのものを教えてくれたのは仕組みではなくドメイン知識でした

技術的な中身は書けないので、この「根拠だけ間違っていた」話だけ書きます。

やっていたこと

自動運転には大きく2つのアプローチがあります。認識・計画・制御をモジュールに分けて組む従来型と、カメラ画像を入れてハンドルとアクセルを直接出力するニューラルネットを1つ置く End-to-End(E2E)型です。私がやったのは後者でした。

テーマは「見た目で挙動を変える」ことです。同じコースでも、置いてあるのがコーンか段ボールか人かで取るべき挙動は違います。人なら止まるべきですが、コーンなら徐行で抜ければいい。それをカメラ画像だけから判断させたい、というものでした。

シミュレータ上で、学習させては走らせるのを4日間繰り返しました。

MLOps 好きとして、最初に評価基盤を作った

私は普段 MLOps や LLMOps まわりが好きで、モデルそのものより「どう回すか」「どう測るか」を考えている時間のほうが長いタイプです。今回選んだのも MLOps・AI 系のコースでした。

なので初日と2日目は、モデルを触る前に回す仕組みのほうを作っていました。データ収集から学習、変換、デプロイ、走行、結果の集計までを1コマンドで通るようにして、条件を変えたら同じ手順で再実行できる状態にしました。地味ですが、4日しかない中ではこれが効きました。試行を何度も回せましたし、最終日に測り直せたのもこの基盤があったからです。

あとで書きますが、この仕組みは私を救ってくれた一方で、肝心の間違いは教えてくれませんでした

3日目:距離が近いほどアクセルが緩む、というグラフ

3日目に、物体までの距離ごとにモデルの出力を集計してみました。すると距離が近づくほどアクセルが緩む、きれいな単調減少のグラフが出ました。

物体に近いほど緩めている。モデルは物体を見て反応している。

そう解釈して、発表スライドにもそう書きました。

4日目の朝:物体を置かない条件を足したら、同じグラフが出た

最終日の朝、念のため確認実験を組みました。やったのは同じ場所に物体を置かない条件を追加しただけで、準備に5分もかかっていません。

走らせて集計したら、物体が無くてもまったく同じ勾配が出ました。

理由はあとから考えれば単純でした。物体はコースの決まった座標に置いています。そしてコースは閉じたループです。つまり「物体までの距離」と「コース上のどこを走っているか」は同じ変数でした。

私が測っていたのは物体への反応ではなく、コースの形だったわけです。カーブの手前で緩む、それだけのことを物体への反応だと読んでいました。

発表の6時間前でした。

結論は合っていて、根拠だけが間違っていた

最初は結論ごと否定されたと思ったのですが、測り直したら少し違いました。

物体ありと物体なしの出力を引き算すると、物体があるときにだけ出る差がちゃんと残っていました。モデルは確かに物体を見ていたわけです。反応が出るのが衝突の直前で、実用にはまるで足りないだけでした。

つまり「モデルは物体に反応している」という結論自体は合っていて、間違っていたのはそれを信じた根拠のほうでした。

これが今回いちばん怖いと思ったところです。結論が間違っていれば、いずれどこかで破綻して気づけます。でも結論がたまたま正しいと、間違った根拠は検出されずに生き残ります。あのまま発表していたら、「距離に応じて減速するモデルができた」と信じたまま帰っていたはずです。

相関と因果を分けたのは、統計でも仕組みでもなくドメイン知識だった

LLM に分析させていると、相関しか出ていないものを因果があるように書いてくることがよくあります。読んでいて「それは言い過ぎでは」と引っかかる、あれです。

今回わかったのは、自分も同じことをやっていたということでした。しかも厄介なのは、統計を正しく扱っていても防げなかった点です。集計方法にも計算にも間違いはありません。グラフも本物でした。

あの交絡に気づくのに必要だったのは、

  • 物体を固定座標に置いていること
  • コースが閉じたループであること
  • だから距離と位置が一対一に対応すること

という、対象についての知識のほうでした。ドメインを知らないと、そもそも「何と何が交絡しうるか」の候補が挙がりません。

そしてここが自分にとって痛かったのですが、私が作り込んだ評価基盤も、これは教えてくれませんでした。パイプラインは指定された条件を正しく回して、正しく集計して、正しいグラフを出します。条件の設計が間違っていることは検出できません。MLOps でよく言われる「評価を自動化しろ」は正しいのですが、自動化できるのは決めた指標を測ることまでで、その指標が何を測っているかは人が保証するしかない、というのを身をもって理解しました。

LLM が相関と因果を混ぜるのも、統計の能力というより対象を知らないせいで交絡の候補を思いつけない面が大きいのだろうと思います。だとするとそれを潰せるのは分野を知っている人間の側で、今回それは私のはずでした。ドメイン知識は分析するための知識というより、自分の分析を疑うための知識なのだな、というのが今回の実感です。

おわりに

発表は結局「できませんでした」という内容になって、スライドは全部書き直しました。それで困ったことは特になく、むしろ5日間で一番の収穫がこれでした。

専門が違っても問題ありませんでした。むしろ当たりがつかないぶん、ひとつずつ測って確かめるしかなくて、その訓練になりました。対照条件を置くのは5分で済むのに、それを3日間やらなかったせいで間違った根拠を1日持ち歩いていた、というのは覚えて帰ります。

メンターの方には5日間よく議論に付き合っていただきました。運営の皆さま、メンターの方、ありがとうございました。

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?