Zenn
🌏

VAD（Vectorized Autonomous Driving）について調べてみた。

に公開
自動運転
e2e自動運転
ベクタ表現
マルチタスク学習
vectorized
tech

VAD: Vectorized Scene Representation for Efficient Autonomous Driving

--- 論文の「Abstract」 ---

自律走行には、信頼性の高い軌跡計画のために、周囲環境の包括的な理解が求められます。従来の手法ではラスタ化された密なシーン表現（例：エージェントの占有情報やセマンティックマップ）を用いて計画を行っており、この手法は計算負荷が大きく、インスタンスレベルの構造情報を見逃してしまいます。

本論文では、自律走行のためのエンドツーエンドの完全ベクトル化パラダイムである VAD（Vectorized Autonomous Driving） を提案します。本手法がもたらす主な利点は以下の通りです。

  1. 安全性の向上：ベクトル化されたエージェントの動きや地図要素を、明示的なインスタンスレベルの計画制約として活用することで、計画の安全性が効果的に改善されます。
  2. 高速化：計算負荷の高いラスタ表現や手作業による後処理を排除することで、従来のエンドツーエンド計画手法よりも大幅に高速化が図られています。

VAD は nuScenes データセット上で、従来最高性能の手法を大きく上回るエンドツーエンド計画性能を達成しました。基本モデルである VAD-Base は、平均衝突率を約 29.0 % 低減し、推論速度は 2.5 倍となっています。さらに、軽量タイプである VAD-Tiny は推論速度を最大 9.3 倍にまで向上させつつ、同等の計画性能を維持しています。

VAD の卓越した性能と高効率性は、自律走行システムの実世界展開において極めて重要であると考えます。研究の発展を促進するために、コードとモデルは GitHubにて公開されています。

-------------------

第1章_はじめに：本記事のゴールと対象読者

近年、自動運転技術は大きく進化しており、従来のモジュール分離型（Perception→Prediction→Planning）から、複数タスクを統合的に学習するEnd-to-End Autonomous Driving (E2E-AD) への移行が注目を集めています。
その中でVAD（Vectorized Autonomous Driving） は、入力された環境情報を「ベクタ形式」に変換し、地図情報・エージェント（他車両や歩行者）・自車の将来軌道を統合的に処理するアプローチとして提案されました（ICCV 2023）。

本記事のゴールは、

  • VADの技術的特徴と設計思想を理解する
  • なぜベクタ表現がE2E-ADにおいて有効なのかを整理する
  • 実装・評価・運用における注意点や限界を明確にする
    の3点です。

これにより、読者がVADを単なる研究論文としてではなく、再現実装や応用の出発点として理解できることを目指します。

本記事の読み方

  • 本記事は技術的詳細を含みますが、章ごとに背景 → 実装 → 評価 → 応用・課題の流れを踏むため、途中から興味のある部分だけを拾い読みしても理解できる構成としています。
  • また、随所にUniADやBEV系手法との比較ポイントを差し込み、読者がVADの位置付けを掴みやすいようにしています。

第2章_問題設定：E2E ADの分解とVADの立ち位置

2.1 従来型自動運転パイプライン

従来の自動運転システムは、多くの場合以下のようなモジュール分離型パイプラインで構築されます。

  1. Perception（認識）
    カメラやLiDAR等のセンサー入力から、車両・歩行者・信号機・道路境界などを検出する。
  2. Prediction（予測）
    認識したエージェントの将来位置・挙動を予測する。
  3. Planning（計画）
    自車の走行経路や速度プロファイルを生成する。
  4. Control（制御）
    計画に基づき、ステアリング・加減速を実行する。

この分離アーキテクチャはモジュールごとに独立最適化できる柔軟性がありますが、

  • モジュール間の誤差伝播（Error Propagation）
  • 最終目標（安全で快適な走行）と個別タスクの最適化目的の乖離
  • 開発・保守コストの増大
    といった課題が指摘されてきました。

2.2 E2E Autonomous Driving の登場

こうした課題に対して登場したのがEnd-to-End Autonomous Driving (E2E-AD) です。
これは、センサー入力から計画（あるいは制御コマンド）までを単一の学習フレームワークで統合的に学習し、誤差伝播を抑えつつ全体最適化を狙うアプローチです。

E2E-ADは近年、大きく2つの方向性に分かれています。

  • 密表現系（Raster/BEV-based）
    センサー情報を画像やBird’s-Eye-View(BEV)マップに変換し、CNN/Transformerで処理。
    • 例：BEVFormer, BEVFusion, UniAD（BEVベース＋タスク統合）
  • 疎表現系（Vector-based / Agent-centric）
    路面やエージェントをポリラインやトークンに変換し、グラフ構造やTransformerで処理。
    • 例：VectorNet, VAD

2.3 VADの立ち位置

VAD（Vectorized Autonomous Driving）は、疎表現系E2E-ADの中でも統合型マルチタスク学習を志向したモデルです。

  • ベクタ表現を用いることで、BEV画像のような高解像度格子表現よりも効率的に道路幾何やエージェント挙動を記述
  • 可変長トークンで表現するため、シーンの複雑さに応じて情報量を調整可能
  • 単一アーキテクチャで認識・地図構築・予測・計画を同時学習
  • BEV系に比べてメモリ効率が高く、レイテンシ削減の余地が大きい

2.4 なぜ「ベクタ化」が重要か

ベクタ表現は、地図や軌跡など連続幾何構造を持つ情報を、画素ベースではなく幾何単位で直接表現できます。
これにより：

  • 無駄な画素領域を処理する必要がなくなる（効率性）
  • 路線・境界・軌跡などをそのままモデル入力できる（表現力）
  • 従来のグラフ表現や経路探索アルゴリズムとの親和性が高い（拡張性）

2.5 本章まとめ

  • 従来のモジュール分離型は安定性が高いが、誤差伝播と統合最適化の難しさが課題。
  • E2E-ADは統合最適化を狙うが、密表現系と疎表現系に大別される。
  • VADは疎表現系の代表例として、可変長ベクタトークンで全タスクを統合学習する。
  • ベクタ化は効率性・表現力・拡張性の3点でメリットがある。

第3章_ベクタ表現の基礎

3.1 ベクタ表現とは

VADにおける「ベクタ表現」とは、カメラやLiDARなどから得られる生データ（画像・点群）を、道路構造やエージェントの軌跡など幾何的な要素単位に抽出・変換した表現形式を指します。
ここでの「ベクタ」は、コンピュータグラフィックスや地図データで用いられるベクトル形式（座標列やポリライン） の意味合いであり、連続した幾何形状を効率的に表すのが目的です。

3.2 主な構成要素

VADのベクタ表現は、以下の3つを中心に構成されます。

  1. ポリライン（Polyline）
    • 道路境界線・車線中心線などを複数の座標点で結んだ折れ線。
    • 例：[(x1, y1), (x2, y2), ..., (xn, yn)]
    • 道路構造の幾何情報を保持。
  2. エージェント軌跡（Agent Trajectories）
    • 他車両や歩行者など動的物体の過去軌跡。
    • 将来予測の入力としても利用。
  3. トポロジ情報（Topology）
    • 車線間の接続関係や優先度、交差点での進行可能方向などの構造情報。
    • グラフ構造として扱うことが多い。

3.3 可変長表現とパディング

ベクタ表現の大きな特徴は可変長であることです。

  • あるシーンでは車線が10本、別のシーンでは50本というように、入力サイズが変動します。
  • バッチ処理のためには、パディングとマスクを用いてテンソルサイズを揃え、計算上の不要部分を無視します。

例：

Polyline_MaxLen = 20  # 最大座標数
Line_MaxCount   = 50  # 最大ポリライン数

不足部分は(0,0)で埋め、mask[i,j]で有効/無効を管理。

3.4 ベクタ化パイプライン

  1. センサーデータ取得
    カメラ画像やLiDAR点群を入力。
  2. 幾何特徴抽出
    • 道路検出（Lane Detection）や物体検出（Object Detection）
    • BEV投影や投影変換を併用する場合もある
  3. ポリライン生成
    検出結果を座標列に変換。
  4. 属性付与
    • 例：レーンタイプ（車線/縁石/歩道）、優先度、制限速度
  5. ID付与と履歴管理
    エージェントや道路要素に一貫したIDを付与し、時系列処理可能に。

3.5 ベクタ表現の利点

  • 効率性
    不要な背景領域を処理せず、必要な幾何情報だけを扱える。
  • 表現力
    道路や軌跡など連続的な形状を損失なく記録可能。
  • 拡張性
    グラフニューラルネットワークや経路探索アルゴリズムと自然に組み合わせ可能。

3.6 ベクタ表現の課題

  • 抽出精度依存
    元の検出精度が低いと、その後の予測・計画にも影響。
  • 可変長処理の複雑さ
    高速化やハードウェア実装の際、パディング・マスク処理がボトルネックになることも。
  • センサーフュージョン設計
    カメラとLiDARなど複数ソースをどう統合するかは依然として研究途上。

3.7 本章まとめ

  • VADでは、道路やエージェントをポリライン＋属性情報＋トポロジとしてベクタ化する。
  • 可変長処理とマスク管理が実装のカギ。
  • 表現は効率的で拡張性が高い一方、抽出精度やフュージョン設計が難所。

第4章_入出力仕様（Data Schema）

4.1 なぜData Schemaが重要か

E2E-ADモデルは単に「画像を入れて軌道を出す」だけではなく、複数タスクの入出力を同時に扱う必要があります。
特にVADは、入力段階で道路・エージェント・履歴・トポロジをベクタ化し、出力段階でそれらに対応する将来情報や計画を生成します。
このため、入出力のデータ仕様を正しく定義することが、学習の安定性・実装の再現性・評価の整合性に直結します。

4.2 入力仕様（Input Schema）

4.2.1 センサー入力

  • カメラ画像（Front/Side/Rear）
    • 解像度や枚数は可変だが、学習時は固定解像度にリサイズ。
  • LiDAR点群（オプション）
    • BEV投影や直接座標変換を経て特徴抽出。
  • 車両自己位置・姿勢（Ego Pose）
    • GNSS/IMUから取得、座標変換の基準として利用。

4.2.2 ベクタ化後の入力構造

入力は可変長ベクタトークンの集合として符号化されます。典型的には：

  • Map Tokens（道路要素）
    • 各ポリライン：最大点数 P_max にパディング
    • 属性：レーンタイプ、優先度、曲率、制限速度
  • Agent Tokens（動的エージェント）
    • 各エージェントの履歴軌跡：最大履歴長 H_max にパディング
    • 属性：速度、加速度、車種
  • Topology Edges
    • 車線接続情報、進行方向、交差関係

4.3 出力仕様（Output Schema）

4.3.1 認識タスク出力

  • 検出結果（Bounding Boxes / Polylines）
    • 車両・歩行者・信号など
    • 属性：信頼度スコア、クラスID

4.3.2 地図推定タスク出力

  • 更新されたMap Tokens
    • 観測結果を反映したベクタ化道路マップ
    • BEVやラスタ表現への変換は不要

4.3.3 予測タスク出力

  • エージェント将来軌跡
    • 複数モード（Multi-Modal Prediction）で出力
    • 各モードごとに確率スコアを付与（例：3モード）

4.3.4 計画タスク出力

  • Ego Vehicle Trajectory
    • 将来の自車軌道（位置・速度・加速度）
    • 安全性・快適性指標を考慮

4.4 入出力対応付け（Matching）
VADでは、入力ベクタと出力ベクタを正しく対応させるために、Hungarian MatchingやIoUベースのアサインが利用されます。
これにより、損失計算時に正解データと予測をペアリングでき、学習が安定します。

4.5 実装例（簡略）

# 入力テンソル例
map_tokens:    (B, M, P_max, F_map)  # 道路
agent_tokens:  (B, A, H_max, F_agent) # 動的エージェント
topology:      (B, M, M)              # 接続行列
mask_map:      (B, M)                  # 有効道路マスク
mask_agent:    (B, A)                  # 有効エージェントマスク

# 出力テンソル例
pred_boxes:    (B, N_pred, 4)
pred_scores:   (B, N_pred)
pred_traject:  (B, A, T_future, 2)
ego_plan:      (B, T_future, PlanDim)

4.6 本章まとめ

  • VADの入出力仕様は、マルチタスク前提で設計されており、認識・地図・予測・計画の全タスクが統合される。
  • 入力は可変長ベクタトークン＋マスク構造、出力は複数タスクの結果が並列に生成される。
  • 入出力の対応付けロジック（Matching）が学習品質を左右する。

第5章_モデルアーキテクチャ全体像

5.1 アーキテクチャの基本構成

VADは、統合型マルチタスク学習を実現するために、1つの共有バックボーンと複数のタスクヘッドで構成されています。
バックボーンが入力データから共通の高次特徴を抽出し、各タスクヘッドがその特徴をもとに特化処理（認識・地図推定・予測・計画）を行う構造です。

5.2 主な構成ブロック

  1. 入力符号化層（Input Encoder）
    • Map Encoder：道路要素ポリラインを可変長トークンとして埋め込みベクトル化
    • Agent Encoder：エージェント履歴軌跡を時間方向に符号化
    • Topology Encoder：接続関係（グラフ構造）をエッジ特徴として符号化
    • 全ての入力は (Batch, NumTokens, FeatureDim) 形式に変換され、マスクで有効部分を管理。
  2. 共有バックボーン（Shared Backbone）
    • Transformerベースのエンコーダ／デコーダ構造
    • Map・Agent・Topologyトークン間でクロスアテンションを行い、地図と動的エージェントの情報を相互に活用
    • 時系列履歴を含む場合は時空間アテンションを適用
  3. タスクヘッド（Task-specific Heads）
    • 認識ヘッド（Detection Head）
      • 車両・歩行者・信号などの検出を行い、ベクタ形式またはBounding Boxで出力
    • 地図推定ヘッド（Map Estimation Head）
      • 新たに観測された道路構造を既存の地図トークンに反映
    • 予測ヘッド（Prediction Head）
      他エージェントの将来軌跡を多モード（例：3モード）で出力、各モードに確率付与
    • 計画ヘッド（Planning Head）
      自車（Ego Vehicle）の将来軌道を生成、快適性・安全性を考慮

5.3 特徴量の流れ

  1. 入力データは符号化層でトークン化され、マスク情報とともにバックボーンへ渡される
  2. バックボーン内部でマルチモーダル統合（Map ↔ Agent ↔ Topology）が行われる
  3. 統合特徴がタスクごとのヘッドへ分岐し、マルチタスク推論が並列で実行される
  4. 出力は対応付け（Matching） を経て、正解データと照合し損失を計算する

5.4 マルチタスク学習のポイント

  • タスク間の情報共有
    • Map情報が予測精度を上げ、予測結果が計画の安全性向上に寄与
  • 損失関数の重み付け
    • Detection / Map / Prediction / Planning の損失比率はタスク難易度や重要度で調整
  • End-to-End最適化
    • 全タスクを一括学習することで、誤差伝播を抑え全体最適を実現

5.5 本章まとめ

  • VADは、入力符号化層 → 共有バックボーン → タスクヘッド という3層構造
  • トークンベースでMap・Agent・Topologyを統合的に処理
  • マルチタスク学習により、認識・地図・予測・計画を一度の推論で同時に出力可能
  • 損失設計やタスク間のバランス調整が性能のカギ

第6章_学習戦略と損失設計

6.1 学習の全体方針

VADはマルチタスク統合学習を採用しており、1つのバックボーンで認識・地図推定・予測・計画を同時に学習します。
このため、学習戦略は次の3つのポイントを押さえる必要があります。

  1. タスク間のバランス
    • 損失の重み付け調整で、特定タスクに偏らない学習を実現
  2. 対応付け（Matching）の安定化
    • 出力と正解をペアリングするアルゴリズムの精度と速度
  3. 学習スケジュール
    • 学習率やデータカリキュラムをタスク進行度に合わせて設計

6.2 損失関数の設計

6.2.1 認識タスク（Detection Loss）

  • 分類損失：クロスエントロピーまたはフォーカルロス（クラス不均衡対策）
  • 位置損失：L1損失やIoU Loss（GIoU/DIoU）でBounding Boxやポリライン座標の精度を評価
  • 損失例：
L_{\mathrm{det}} = \lambda_{\mathrm{cls}} L_{\mathrm{cls}} + \lambda_{\mathrm{loc}} L_{\mathrm{loc}}

6.2.2 地図推定タスク（Map Loss）

  • ポリライン予測に対する座標回帰損失（Smooth L1 Loss）
  • 道路属性の分類損失（交差点/車線タイプなど）
  • 例：Polylineの形状＋属性ラベルを両方最適化

6.2.3 予測タスク（Prediction Loss）

  • ADE/FDE（Average/Final Displacement Error）：将来軌跡と正解の距離誤差
  • モード選択損失：最も近い将来軌跡モードを選び、そのモードの誤差で学習
  • 確率回帰損失：各モードの確率分布を正解に近づける（Negative Log-Likelihood）

6.2.4 計画タスク（Planning Loss）

  • Ego軌道に対する位置・速度・加速度の回帰損失
  • 安全性を加味したペナルティ（例：衝突予測がある場合は罰則）

6.3 対応付け（Matching）戦略

VADでは、入力ベクタ（Map Token, Agent Token）と出力予測を正解データと対応付ける必要があります。

  • Hungarian Matching
    • 総合コスト（位置誤差＋クラス誤差）を最小化するペアリング
    • 運算量は O(n³) だが、トークン数が適切なら実用的
  • IoUベースMatching
    • Bounding BoxやPolylineのIoUが最大のものを対応付け
    • 計算が軽いが、形状が複雑な場合はHungarianの方が安定

6.4 学習スケジュールとテクニック

  1. ウォームアップ＋コサイン減衰
    • 初期は小さい学習率で安定させ、後半は徐々に減少
  2. タスク重みの動的調整
    • 損失の大きさや勾配ノルムに応じて重みを変化（GradNormなど）
  3. データカリキュラム
    • 簡単なシーン（低密度、車両少なめ）から始め、徐々に複雑なシーンへ
  4. マルチGPU同期BatchNorm
    • バッチサイズが小さい場合でも統計量を安定化

6.5 実務上の注意点

  • 損失が不安定になる場合は、Matching部分のコスト設計を見直す
  • 計画タスクの損失を大きくしすぎると、検出や予測が犠牲になる可能性
  • マルチタスクでの勾配干渉を抑えるため、タスクごとに勾配スケーリングを適用する手法も有効

6.6 本章まとめ

  • VADの学習は、マルチタスク損失のバランス調整とMatchingの安定化が重要
  • 認識・地図・予測・計画それぞれに適した損失設計が必要
  • 学習スケジュール、タスク重み調整、データカリキュラムで性能を底上げできる

第7章_推論パイプラインとリアルタイム性

7.1 推論パイプラインの全体像

VADにおける推論パイプラインは、学習済みモデルを用いてセンサー入力から最終的な走行計画を生成する一連の処理フローです。
大きく以下のステップに分けられます。

  1. センサーデータ取得
    • カメラ、LiDAR、IMU/GNSSなどからデータを同期取得
    • タイムスタンプ整合と外部校正（Extrinsic Calibration）を確認
  2. 前処理（Pre-processing）
    • 画像リサイズ、正規化
    • LiDAR点群のフィルタリング（ROI Crop、ノイズ除去）
  3. ベクタ化（Vectorization）
    • 道路境界や車線中心線のポリライン抽出
    • エージェントの履歴軌跡生成
  4. トークン化（Tokenization）
    • 可変長データをパディング＋マスク化し、バッチ形式に整形
  5. 共有バックボーン推論
    • TransformerエンコーダでMap/Agent/Topologyトークン間の相互情報を統合
  6. タスクヘッド推論
    • 認識（Detection Head）
    • 地図推定（Map Head）
    • 将来予測（Prediction Head）
    • 計画生成（Planning Head）
  7. ポストプロセス
    • Matching（Hungarian等）による出力の整理
    • フィルタリング（信頼度閾値、物理制約の適用）
  8. 制御インタフェースへの送信
    • 計画軌道を車両制御モジュールへ送出

7.2 レイテンシ要件と計算制約

自動運転のリアルタイム性は、安全性と快適性に直結します。
VADのような統合モデルの場合、1推論サイクルの目安は 50〜100ms以内 が望ましい（10〜20Hz動作）です。

  • 応答遅延が長い場合のリスク
    • 障害物回避が間に合わない
    • 急ハンドル・急制動による乗り心地悪化
  • 高スループット化の難所
    • 可変長トークン処理（パディング・マスク）がGPU効率を下げる
    • Multi-Head推論でヘッド間のパラレル化が不十分

7.3 リアルタイム最適化のアプローチ

7.3.1 モデル軽量化

  • トークン数削減
    • 距離が遠いポリライン・エージェントを事前に間引き
  • バックボーン圧縮
    • レイヤー数削減、ディメンション削減
  • 量子化（INT8/FP16）
    • 推論精度とのトレードオフを評価

7.3.2 パイプライン並列化

  • センサーデータ取得と前処理を別スレッド化
  • CPUとGPUで前処理と推論を非同期化
  • マルチGPUによるバッチ推論（複数フレーム先読み）

7.3.3 キャッシュとインクリメンタル更新

  • 直前フレームの特徴量を再利用
  • 静的要素（地図）をキャッシュして毎フレーム再計算しない

7.4 実装上のベストプラクティス

  • タイムスタンプ管理の厳密化
    • センサー間同期ズレは、予測や計画の精度低下を招く
  • プロファイリングの定期実施
    • 推論時間の内訳（前処理 / バックボーン / 各ヘッド / ポストプロセス）を分解
  • 異常検知とフォールバック
    • 推論が期限内に終わらない場合は簡易な安全軌道へ切替

7.5 本章まとめ

  • VADの推論パイプラインは、入力→ベクタ化→トークン化→共有バックボーン→タスクヘッド→ポストプロセスの流れ
  • リアルタイム性を確保するには、モデル軽量化と並列化、キャッシュ活用が重要
  • 50〜100ms以内の処理時間を目指し、プロファイリングでボトルネックを特定・改善する

第8章_評価設計

8.1 なぜ評価設計が重要か

VADは認識・地図推定・予測・計画の複数タスクを同時に実行するため、評価設計が不十分だと以下の問題が起きます。

  • 一部タスクは改善しても、他タスクが劣化していることに気づかない
  • オープンループ（オフライン）では高精度でも、クローズドループ（実走）では性能が出ない
  • 指標間のトレードオフを無視した過学習

8.2 評価の二つの軸

8.2.1 オープンループ評価（Offline Evaluation）

  • 学習やテストデータを用い、推論結果と正解ラベルを直接比較
  • メリット：再現性が高く、細かい指標で比較可能
  • デメリット：実際の走行制御や環境変化の影響を反映できない

8.2.2 クローズドループ評価（Closed-loop Evaluation）

  • 実際に推論結果を制御コマンドに変換し、シミュレーションや実車で走行
  • メリット：制御・センサー遅延・累積誤差を含めた総合評価が可能
  • デメリット：再現性が低く、評価コストが高い

8.3 タスク別の主な評価指標

8.3.1 認識（Detection）

  • mAP（mean Average Precision）：全クラス平均の検出精度
  • Recall / Precision：検出漏れ・誤検出のバランス
  • IoU（Intersection over Union）：予測と正解の重なり度

8.3.2 地図推定（Map Estimation）

  • Topology Accuracy：車線接続の正確さ
  • Polyline IoU / Chamfer Distance：道路形状の一致度
  • 属性分類精度（交差点フラグ、車線種別など）

8.3.3 予測（Prediction）

  • minADE / minFDE
    • ADE（Average Displacement Error）：予測軌跡と正解の平均距離
    • FDE（Final Displacement Error）：最終時刻での誤差
  • MR（Miss Rate）：一定距離以上外れた割合
  • 多モード精度：モード確率の正しさ（NLLなど）

8.3.4 計画（Planning）

  • Driving Score：安全性＋快適性＋効率性を統合した指標
  • 衝突率 / オフルート率：衝突・逸脱の発生割合
  • 操作滑らかさ：ステアリング角や加減速度の変化率

8.4 総合評価の設計

VADはタスク間でトレードオフがあるため、総合スコアを定義すると評価が分かりやすくなります。

  • 例：
Score_{\mathrm{total}} = w_{1} \cdot \mathrm{mAP} + w_{2} \cdot \left( 1 - \mathrm{minADE} \right) + w_{3} \cdot \mathrm{DrivingScore}
  • 重み w_{1}, w_{2}, w_{3} はタスク重要度に応じて設定

8.5 実務上の評価ポイント

  • 分布外シナリオ（OOD）評価
    • 悪天候、夜間、工事区間など学習データにない条件での耐性確認
  • シナリオ別評価
    • 交差点右折、追い越し、緊急停止など特定場面での性能
  • 長期安定性
    クローズドループでの連続走行距離やエラー累積挙動

8.6 本章まとめ

  • 評価はオープンループ＋クローズドループ両方の視点で行う必要がある
  • タスクごとに最適な指標を使い、総合スコアで全体性能を管理
  • 実運用を意識したシナリオ別・分布外評価が欠かせない

第9章_アブレーションの観点

9.1 なぜアブレーションが必要か

VADのような統合型モデルは多数の構成要素（バックボーン、ベクタ表現、損失設計など）から成り立っています。
単に精度を比較するだけでは「どの要素が効果をもたらしたのか」が不明確になり、改良の方向性を誤るリスクがあります。
アブレーション（要素除去／変更）実験は、その効果を切り分けて分析する手段です。

9.2 アブレーション設計の基本方針

  • 1回の比較では1要素だけを変更
    他条件は固定し、影響を純粋に測定
  • 評価指標は多角的に取得
    mAPやADE/FDEだけでなく、推論時間やメモリ使用量も記録
  • 統計的有意性の確認
    小さな差異は複数シードで検証して信頼性を確保

9.3 主なアブレーションの観点

9.3.1 ベクタ表現の解像度・密度

  • ポリラインの最大点数 P_{\text{max}} を変化
  • エージェント履歴長 H_{\text{max}} を短縮／延長
  • 結果：効率性と精度のトレードオフ分析

9.3.2 バックボーン構造

  • Transformer層数やヘッド数の削減／増加
  • クロスアテンション有無の比較
  • 結果：タスク間情報共有の寄与度を評価

9.3.3 入力モダリティ

  • カメラのみ vs LiDARのみ vs 融合
  • センサ数削減時の精度低下と推論速度向上のバランス

9.3.4 損失設計と重み付け

  • タスク損失の比率 w_{\mathrm{det}},\ w_{\mathrm{map}},\ w_{\mathrm{pred}},\ w_{\mathrm{plan}} を変更
  • 認識・予測・計画のどれを優先したときに全体スコアが最適化されるかを分析

9.3.5 Matching手法

  • Hungarian Matching vs IoU-based Matching
  • 高速化と精度の差異

9.3.6 計算効率化手法

  • トークン間引き（遠距離ポリライン除去）の有無
  • 量子化（FP16/INT8）によるレイテンシ短縮と精度変化

9.4 実験結果の可視化

  • スパイダーチャートで各構成の性能プロファイルを表示（精度・速度・メモリ・安全性など）
  • ヒートマップでパラメータ設定と評価指標の関係を可視化
  • シナリオ別棒グラフで特定シーン（交差点・高速走行・混雑時）における性能比較

9.5 実務での活用例

  • 新モデル導入時に「精度は上がったが推論時間が20%増加」という結果が出た場合、アブレーションで原因要素を特定
  • 顧客や関係者への説明資料に、構成ごとの貢献度を定量的に示すことで意思決定を支援

9.6 本章まとめ

  • アブレーションはモデル改良の指針を明確にするために必須
  • ベクタ表現、バックボーン、入力モダリティ、損失設計、Matching、効率化手法など多角的に検証する
  • 実験結果はグラフや表で可視化し、性能・効率・安全性のバランスを見極める

第10章_実装ノート（エンジニアリング視点）

10.1 本章の目的

VAD（Vectorized Autonomous Driving）モデルは論文仕様をそのままコード化すれば動きますが、
実際の開発環境や制約（リアルタイム性、メモリ、再現性）を考慮すると多くの追加工夫が必要になります。
本章では、研究コードを実務コードに落とし込む際のポイントをまとめます。

10.2 データ前処理の工夫

10.2.1 ベクタ化の高速化

  • 複数センサの生データ（カメラ/LiDAR）をベクタ形式に変換する処理はCPU負荷が高い
  • 並列処理（マルチスレッド / GPU）でバッチ処理化
  • Polyline抽出時の点間距離しきい値を動的調整して冗長点を削減

10.2.2 トークン化の再現性確保

  • PyTorchのDataLoaderにworker_init_fnで乱数種を固定
  • 同一シードでもGPUの非決定性演算（例: cuDNN）を抑える設定を有効化

10.3 モデル実装のポイント

10.3.1 Transformer最適化

  • Mixed Precision Training (FP16/BF16) でVRAM削減
  • 大規模バッチ時はGradient Accumulationでメモリ圧迫回避
  • Key-Valueキャッシュ活用で推論レイテンシ短縮

10.3.2 マルチタスク出力の制御

  • 各タスクの出力ヘッドはnn.ModuleDictで一括管理
  • 損失関数の重み w_{\mathrm{det}},\ w_{\mathrm{map}},\ w_{\mathrm{pred}},\ w_{\mathrm{plan}} を外部設定ファイル（YAML/JSON）で切替可能にする

10.4 推論パイプライン最適化

10.4.1 バッチサイズ調整

  • オンライン推論ではバッチサイズ=1が原則だが、シミュレーション検証時はまとめ処理で効率化
  • 動的バッチ化（Dynamic Batching）でGPU稼働率向上

10.4.2 モデル軽量化

  • TensorRTでの最適化（Layer Fusion, FP16/INT8量子化）
  • 不要なタスクヘッドをコンパイル時に無効化してレイテンシ削減

10.5 ロギングとデバッグ

10.5.1 可視化

  • 中間特徴（ベクタトークンのAttention Map）を可視化して不具合箇所を特定
  • Scenario-based Visualization（交差点・追い越し・右折など）でタスクごとの挙動分析

10.5.2 ログ管理

  • 実験IDとGit Commit Hashを必ず紐付け
  • HydraやMLflowを使ってパラメータ・モデル・結果の完全追跡を実現

10.6 実務での注意点

  • リアルタイム推論ではメモリ確保・GCが遅延原因になるため事前確保が必須
  • 学習用コードと推論用コードは責務分離し、パフォーマンスを優先した軽量版を用意
  • 論文の理想設定（高解像度・長履歴）と実務制約（ハードウェア限界）を明確に区別して設計

10.7 まとめ

  • 実装段階では計算効率・再現性・デバッグ容易性を重視する
  • 論文のパフォーマンスを再現するだけでなく、実運用環境に適合させるための軽量化・最適化が必要
  • ベクタ化～トークン化～推論～出力の各段階でボトルネックを測定し、継続的に改善を行う

第11章_UniAD/BEV系/VectorNet系との比較

11.1 本章の目的

VADは「ベクタ表現 × トランスフォーマー」による統一的パイプラインを採用していますが、その立ち位置を理解するためには、他の主要アプローチと比較することが有効です。
本章では、UniAD（Unified Autonomous Driving）、BEV変換系、VectorNet系との違いを整理します。

11.2 UniADとの比較

観点 UniAD VAD
表現形式 BEVグリッド（ピクセル単位の空間マップ） ベクタ（PolylineやObject Token）
タスク統合度 知覚・予測・計画を完全統合 知覚・予測・計画を統合（ベクタベース）
特徴 BEV表現により幾何一貫性が高いが、解像度依存の計算コスト増 ベクタ化により軽量化、対象の意味構造を直接表現
弱み 高解像度BEVの計算負荷 トポロジ情報抽出の精度依存

まとめ：
VADはUniADの統合思想を引き継ぎつつ、BEV→ベクタ変換により計算効率と軽量性を確保。

11.3 BEV系手法との比較（BEVFormer, BEVDetなど）

観点 BEV系 VAD
表現空間 Bird’s Eye View（固定グリッド） ベクタ（動的トークン）
スケーラビリティ 高解像度で急速にメモリ消費増 ベクタ数に比例、軽量
幾何表現 空間均一だが冗長領域あり 必要部分のみをポリライン/点で表現
適合タスク 知覚中心（検出・マップ構築） 知覚＋予測＋計画の統合が容易

まとめ：
BEV系は視覚的に直感的で強力だが、VADは同等の情報をより圧縮表現で扱える。

11.4 VectorNet系との比較

観点 VectorNet VAD
目的 車両軌跡予測（予測専用） 統合型：検出・地図構築・予測・計画
入力 マップポリライン＋周辺エージェント軌跡 センサデータをベクタ化＋同様のポリライン構造
アーキテクチャ 階層型Graph＋Transformer トークン化＋Transformer（統合出力）
スコープ 単一タスク寄り マルチタスク統合

まとめ：
VADはVectorNetの「ベクタ＋トランスフォーマー」発想をE2E AD全体に拡張した形。

11.5 比較から見えるVADのポジション

  • UniAD寄りの統合設計思想
  • BEV系の代替として、より軽量なベクタ表現を採用
  • VectorNetの発展形として、予測だけでなく検出や計画までカバー
  • 強み：軽量・モジュール間の情報損失が少ない
  • 弱み：ベクタ化モジュールの品質に全性能が依存

11.6 まとめ

VADは、

  • UniADの「統合パイプライン」
  • BEV系の「空間的俯瞰」
  • VectorNetの「ベクタ＋Transformer」
    これらの長所を組み合わせた位置づけにある。
    特に軽量化・リアルタイム性・タスク統合性のバランスが取れているため、実運用向きのアプローチとして注目される。

第12章_実務適用と限界

12.1 本章の目的

これまでの章でVADの技術構造や比較分析を行ってきました。
本章では、研究レベルの成果を実務に適用する際の課題、そして現時点での限界を明確化します。

12.2 実務適用のシナリオ

12.2.1 想定適用領域

  • ADASレベル3～4向け：高速道路自動運転、限定エリアでのロボタクシー
  • HDマップ補完システム：地図更新頻度の低い地域での動的地図生成
  • シミュレーション検証：車両挙動予測精度の評価やプランニング戦略の検証

12.2.2 利点

  • モジュール間のデータ変換ロスが少なく、統一的に最適化可能
  • ベクタ表現による軽量化 → エッジデバイス適用可能性が高い
  • マルチタスク同時学習で開発効率が向上

12.3 実務での追加要件

  1. リアルタイム性確保
    • 推論レイテンシを50ms以下に抑える必要あり
    • モデル軽量化（量子化・TensorRT最適化）が必須
  2. 再現性と検証性
    • 自動運転安全認証のため、同一入力に対し完全一致する出力が必要
    • 乱数シードや非決定性演算の排除が必須
  3. ロバスト性
    • センサ異常・欠落・天候変化に耐える設計（データ拡張・マルチモーダル冗長化）
  4. インターフェースの安定性
    • 実車制御ECUや安全モジュールとの通信仕様を固定

12.4 限界と課題

12.4.1 学習データ依存性

  • ベクタ化の精度が低下すると、全タスクの精度が同時に劣化
  • 学習データの多様性確保が必須（天候、地形、交通量）

12.4.2 長距離・長時間予測の難しさ

  • 現行VADは短～中距離予測に最適化されており、長期予測では累積誤差が増加
  • 長期計画は依然としてルールベースや他モジュール併用が現実的

12.4.3 実装複雑性

  • トークン数制御・メモリ管理・マルチタスク損失設計など、多くの実装パラメータが存在
  • チーム間での実装標準化が必要

12.4.4 規制・認証面

  • E2Eモデルは「ブラックボックス」性が高く、説明責任（Explainability）が課題
  • 安全規格（ISO 26262, SOTIF）適合のための補助的な検証モジュールが必要

12.5 今後の展望

  • ハイブリッド構成：E2E VADとルールベース制御の組み合わせによる安全性向上
  • オンライン学習：実運用から得られるデータでの継続改善
  • 軽量モデル探索：モバイル向けTransformerやSparse Attentionの導入
  • 説明可能AI（XAI）統合：Attention可視化や因果分析で安全認証をサポート

12.6 まとめ

VADは実務適用において大きな可能性を持つ一方、学習データ依存性・説明性・リアルタイム制約など、越えるべき課題も多い。
特に自動運転という安全クリティカル領域では、単体運用よりも既存モジュールとのハイブリッド活用が現実解となるだろう。
今後は、性能と安全性を両立するための設計パターン確立が鍵となる。

第13章_まとめ（3つのTakeaways）

13.1 本記事のゴールの再確認

本記事では、VAD（Vectorized Autonomous Driving） の技術構造を深掘りし、既存のUniADやBEV系、VectorNet系との比較を通してその立ち位置を明らかにしました。
E2E ADにおけるベクタ表現の強みと実務適用時の課題も整理し、研究から実運用への橋渡しを意識した構成としました。

13.2 3つのTakeaways

①ベクタ表現は軽量かつ情報効率の高い統合手法

  • 従来のBEVグリッド表現に比べ、必要領域だけを抽出するため計算負荷が低い
  • トークン単位での情報伝達により、知覚・予測・計画の統合が容易
  • モジュール間変換による情報損失を抑制

②VADはUniADとVectorNetの長所を兼ね備えた発展形

  • UniADの「統合パイプライン設計思想」を引き継ぎつつ、VectorNetの「ベクタ＋Transformer」発想を全タスクへ拡張
  • BEV系の幾何的俯瞰能力を、軽量ベクタ表現で実現

③実務適用にはリアルタイム性・安全性・説明性が鍵

  • エッジデバイス適用にはモデル最適化（量子化、TensorRT変換）が必須
  • ISO 26262 / SOTIF 適合に向けた検証・説明性の確保が課題
  • 実運用ではルールベース制御や冗長構成とのハイブリッド運用が現実解

13.3 最後に

VADは、E2E自動運転の中で 「軽量性と統合性のバランス」 に優れた注目アプローチです。
今後、センサの高精度化や計算リソースの進化とともに、このアーキテクチャがさらに洗練され、
より多様な運用シナリオで採用される可能性があります。
この記事が、研究者・エンジニア・プロダクトマネージャーの皆さんが次の一手を考える一助になれば幸いです。

Discussion