山火事避難AIの蒸留は制約を学習に混ぜる話だった
目次
カリフォルニアで山火事（wildfire）が広がると、数千〜数万人が一斉に避難する。
道路は火で塞がり、大気質が急変して通れない区間が出る。避難所もすぐ埋まる。
Rikin PatelのCross-Modal Knowledge Distillation for wildfire evacuation logistics networks under real-time policy constraints（2026年5月10日公開）は、この避難ルート最適化に蒸留を使う。
教師モデルは衛星画像、避難命令テキスト、交通センサー、大気質データ、避難所容量をまとめて処理し、その判断を小さな生徒モデルへ移す。
面白いのはモデル圧縮ではなく、「通行止め」「AQI（大気質指数）300超は通行禁止」のような動的制約を蒸留の損失関数に直接入れている設計だった。
制約を後ろからかぶせない
原典の実装例では、教師モデルが画像、テキスト、数値データをまとめて処理する。
生徒モデルは軽量化のため、画像を直接見ず、テキストと数値データ、さらにpolicy constraintの埋め込みを受け取る。
そのうえで、通常のKL divergenceによる蒸留損失に、禁止された行動を選んだときのペナルティを足している。
たとえば「AQIが300を超える地域を通る避難ルートは禁止」という制約が来たら、そのルート選択の確率を下げる方向へ学習する。
これは「モデルが出した候補をルールエンジンで弾く」とは少し違う。
ルールエンジン後処理なら、モデルは最後まで危険ルートを高く見積もり続け、最後に別部品が止める。
制約込みの蒸留では、生徒モデルの判断分布そのものが、動的ルールを織り込む方向に寄る。
以前、LLM推論を高速化するCDLMとAttention Matching KV圧縮で見た蒸留は、遅い教師モデルから速い生徒モデルへ推論軌跡を移す話だった。
今回の原典も軽量化は目的に含むが、圧縮だけで読むと薄い。
「制約を含む判断の癖」を小さいモデルに移そうとしている点が違う。
画像を見ない生徒がどこまで耐えるか
原典では、教師モデルは衛星画像を見ているが、生徒モデルは画像を直接入力しない。
エッジデバイスや避難車両上では画像処理の計算資源が足りない、という前提だ。
ここで怖いのは、画像由来の情報が「教師のsoft label」に圧縮されるところだ。
煙で衛星画像が読みにくい、交通センサーが欠落する、SNS報告が遅れる。
災害時のモダリティは、きれいに揃ってくれない。
Sentence Transformers v5.4でテキスト・画像・音声・動画の統合Embeddingが可能にでは、異なるモダリティを同じ検索・rerank APIで扱えるようになった話を書いた。
あれは検索用途なので、候補を落としても人間やrerankerで戻せる余地がある。
避難ルート判断では、落とした情報がそのまま行動に刺さる。
画像を見ない生徒モデルを現場に置くなら、画像情報を本当に捨てていい場面と、教師に再問い合わせすべき場面を分ける必要がある。
原典のコード例はその境界までは踏み込んでいない。
confidenceやデータ鮮度を出し、低いときは人間の判断へ戻す設計がないと、軽量化がそのまま見落としになる。
リアルタイムは23msだけでは決まらない
原典では、Raspberry Pi 4とCoral USB acceleratorで生徒モデルを動かし、1予測23ms、教師モデルはGPU上で1.2秒という数字が出てくる。
この差は分かりやすい。避難判断の現場で1秒単位の遅れが積み重なるなら、軽い生徒モデルを置きたい。
ただ、避難物流ネットワークで詰まるのは推論時間だけではない。
センサーの更新間隔、衛星画像の取得周期、道路閉鎖情報の伝達遅延、避難所容量の反映遅れが全部混ざる。
モデルが23msで返しても、入力が5分古ければ判断は古い。
3日でモバイルアプリを作った。難しかったのは接続の維持だったでは、AIチャットのストリーミングがスマホのバックグラウンド移行で切れる話を書いた。
災害対応はもっと厳しい。
回線が切れる、基地局が混む、車両側の端末が古い、現地のオペレーターが画面を見続けられない。
リアルタイム制約下のAIは、モデル単体のレイテンシより、入力・通信・状態保存のほうが壊れやすい。
ウェブ界隈の低レイテンシ・リアルタイム同期通信で扱ったWebSocketやWebRTCの話とも接続するが、避難システムでは「低遅延で届く」だけでは足りない。
届かなかった情報、古い情報、矛盾した情報をどう扱うかが本体になる。
数字は面白いが検証単位が見えない
原典には、Californiaの2017-2021年の山火事データで、生徒モデルが教師の92%の精度を出し、急な政策変更では教師を上回ったという記述がある。
また、2020 August Complex Fireの例として、静的データで訓練された教師が大気汚染ポリシーに反するルートを薦め、生徒モデルが迂回できたと書かれている。
この話は面白いが、記事上では評価単位が足りない。
route optimization taskの正解ラベルをどう作ったのか。
「政策変更への追従」は、実際の避難結果なのか、シミュレーション内の制約充足なのか。
道路容量、避難者数、渋滞、煙、避難所の受け入れ条件をどこまで入れたのか。
そのあたりが見えない。
信頼度スコアで文書抽出の人手確認を絞るでは、confidenceはaccuracyではないと書いた。
避難AIでも似た問題がある。
ルート選択のスコアが高くても、それは「データが正しい」「制約が最新」「現場で実行できる」まで保証しない。
特に災害対応では、モデル出力の確信度より、どの入力が何分前で、どの制約に引っかかり、どの部分を人間が上書きしたかを残すほうが効く。
蒸留を安全側の部品として読む
蒸留という言葉は、最近だとモデル盗用やベンチマーク汚染の文脈でも出てくる。
Claudeの大規模不正蒸留とSWE-benchの崩壊が同時に来たでは、API出力を大量収集して他社モデルを再現する話を扱った。
今回の原典はその逆で、危機対応のために大きな教師の判断を小さい現場モデルへ移す、正当な用途の蒸留として読める。
ただし、正当な用途でも「教師の判断を移したから安全」にはならない。
教師が古い制約を見ていたら、生徒もそれを学ぶ。
教師が特定地域の道路網に偏っていたら、生徒もその偏りを受ける。
生徒が画像を見ないなら、見えないモダリティの異常を検出しにくい。
この原典から拾えるのは、災害対応AIの完成形ではなく、動的制約をモデルの外側に置きっぱなしにしない設計メモだと思う。
通行止め、大気汚染、避難命令、避難所容量のようなルールが分単位で変わるなら、推論後のフィルタだけでは遅い。
それを学習時の損失や推論時の入力に入れるところまでは筋がいい。
その先は、データ鮮度、失敗時のフォールバック、人間の上書き履歴、現場で実行できなかった判断の記録がないと、実運用には持っていけない。