Car-GPT: 大規模言語モデルはついに自動運転車を実現させるか？

1928年、ロンドンは肺炎、結核、髄膜炎などの細菌性疾患に襲われ、深刻な健康危機の真っ只中にあった。無菌状態の研究室に閉じこもった科学者や医師たちは、複雑な問題を解決するために従来の医学的アプローチを用い、試行錯誤の果てしない循環に陥っていた。 そんな中、1928年9月、ある偶然の出来事が世界の流れを変えた。アレクサンダー・フレミングというスコットランド人医師が、ペトリ皿（理科の授業で使った透明な円形の容器）の蓋を閉め忘れ、それがカビに汚染されてしまったのである。フレミングはそこで奇妙なことに気づいた。湿気の近くにあった細菌はすべて死んでおり、他の細菌は生き残っていたのだ。 「あの湿気は何でできているんだ？」とフレミングは考えた。こうして彼は、カビの主成分であるペニシリンが強力な細菌殺傷剤であることを発見した。これが画期的なペニシリンの発見につながり、今日私たちが使う抗生物質へと発展していった。医師たちが既存のよく研究された手法に頼っていた世界において、ペニシリンは予期せぬ答えだった。 自動運転車も同様の出来事をたどっているのかもしれない。2010年代、自動運転車の大半は「モジュラー」アプローチと呼ばれる手法で構築されていた。ソフトウェアの「自律」部分は、知覚（世界を見るタスク）、位置推定（世界の中で自分自身を正確に位置づけるタスク）、計画（車が辿る軌道を作成し、車の「頭脳」を実装するタスク）など、いくつかのモジュールに分割されていた。そして最終的に、これらすべてが最後のモジュールである「制御」に送られ、「右に20°ハンドルを切る」などのコマンドを生成する。これがよく知られたアプローチだった。 しかし10年後、企業は別の分野を非常に真剣に捉え始めた。エンドツーエンド学習である。核となる考え方は、すべてのモジュールを、ステアリングと加速度を予測する単一のニューラルネットワークに置き換えることだが、ご想像の通り、これはブラックボックス問題を引き起こす。 これらのアプローチは知られているが、まだ自動運転の問題を解決していない。そこで私たちはこう考えずにはいられない。「現在世界に革命を起こしているLLM（大規模言語モデル）が、自動運転に対する予期せぬ答えになるのではないか？」 本記事では、まずLLMとは何かを簡単に説明し、その後、LLMが自動運転にどのように貢献できるのかについて掘り下げていく。 前置き: LLMとは？ この記事を読む前に、一つ知っておいてほしいことがある。私は全くLLMの専門家ではない。つまり、LLMを学ぶ苦労をよく知っている。私は「LLM 学習」とググって、具体的な内容が何も書かれていない電子書籍のダウンロードを促すスポンサー記事を3つ見て、それから20個の究極のロードマップやGitHubリポジトリを見て、その最初のステップ（全54ステップ中）が2時間もの長い動画を見ることだと知る（そして54番目のステップが何かは誰も知らない。あまりにも長すぎるからだ）という経験がどんなものか理解している。 だから、私があなたに同じ苦痛を味わわせる代わりに、LLMが何かを3つのキーアイデアに分解して説明しよう。 言語の処理 ChatGPTでは、あなたがテキストを入力すると、テキストが返ってくる、そうだよね？実際に起こっていることは、あなたのテキストがまずトークンに変換されることだ。 しかしトークンとは何か？あなたはそう尋ねるかもしれない。トークンは単語、文字、あるいは私たちが望むどんなものでも対応できる。考えてみてほしい——もしあなたがニューラルネットワークに文を送るつもりなら、実際の単語を送るつもりはなかっただろう？ ニューラルネットワークへの入力は常に数値なので、テキストを数値に変換する必要がある。これがトークン化だ。 モデル（ChatGPT、LLAMAなど）によって、トークンが意味するものは異なる。単語、サブワード、あるいは文字さえも意味しうる。英語の語彙を取って、それらを単語として定義することもできるし、単語の一部（サブワード）を取り、さらに複雑な入力を扱うこともできる。例えば、単語「a」はトークン1、単語「abracadabra」はトークン121といった具合だ。 さて、文を一連の数値に変換する方法がわかったので、その数列をニューラルネットワークに送ることができる！大まかに言うと、次のような構造になる。 周りを見回すと、エンコーダー-デコーダーアーキテクチャに基づくモデルもあれば、純粋にエンコーダーベースのモデル、GPTのように純粋にデコーダーベースのモデルもあることがわかるだろう。 いずれにせよ、それらはすべてコアとなるTransformerブロックを共有している。マルチヘッドアテンション、レイヤー正規化、加算と連結、ブロック、クロスアテンションなどだ。 これは単に、出力を得るための一連のアテンションブロックに過ぎない。では、この単語予測はどのように機能するのだろうか？ 出力 / 次単語予測 エンコーダーは特徴を学習し、文脈を理解する… ではデコーダーは何をするのか？物体検出の場合、デコーダーはバウンディングボックスを予測する。セグメンテーションの場合、デコーダーはセグメンテーションマスクを予測する。ここではどうか？ 私たちの場合、デコーダーは一連の単語を生成しようとしている。このタスクを「次単語予測」と呼ぶ。 もちろん、デコーダーも同様に数値やトークンを予測することでこれを行う。これにより、私たちの完全なモデルは以下のように特徴づけられる。 さて、このイントロの上に学ぶべき多くの「概念」がある。Transformerとアテンションに関連するすべてのこと、さらに数ショット学習、事前学習、ファインチューニングなどだ。 なるほど… しかし、これが自動運転車と何の関係があるのだろう？そろそろステージ2に移る時が来たようだ。 自動運転車のためのChat-GPT 実は、あなたはすでに難しい部分を通過した。あとは単に「これを自動運転にどう適応させるか？」ということだ。考えてみてほしい。私たちにはいくつかの修正を加える必要がある。 私たちの入力は、画像、センサーデータ（LiDAR点群、RADAR点群など）、あるいはアルゴリズムデータ（車線、物体など）のいずれかになる。Vision TransformerやVideo Vision Transformerが行うように、これらすべては「トークン化可能」だ。 私たちのTransformerモデルは、トークン上で動作するだけで入力の種類に依存しないため、ほとんど同じままである。 出力は、私たちが行いたい一連のタスクに基づく。画像で何が起こっているかを説明することもできれば、車線変更のような直接的な運転タスクにもなりうる。 では、結論から始めよう。 LLMが解決できる自動運転車のタスクとは？ 自動運転には多くのタスクが関わるが、すべてがGPT化できるわけではない。2023年に最も活発な研究領域は以下の通りだった。 知覚: 入力画像に基づき、環境、物体の数などを記述する。 計画: 画像、鳥瞰図、または知覚の出力に基づき、何をすべきか（走行継続、譲歩など）を記述する。 生成: 「拡散」を用いて、トレーニングデータ、代替シナリオなどを生成する。 質問応答: チャットインターフェースを作成し、LLMにシナリオに基づいて質問に答えさせる。 知覚におけるLLM 知覚では、入力は一連の画像であり、出力は通常、物体の集合、車線などである。LLMの場合、3つのコアタスクがある。検出、予測、追跡だ。Chat-GPTに画像を送り、何が起こっているかを説明するよう求める例を以下に示す。 HiLM-DやMTD-GPTなどの他のモデルも同様のことができ、動画に対応する研究もある。PromptTrackのようなモデルは、4D知覚モデルと同様に、一意のID（前方のこの車はID #3）を割り当てる能力も持つ。 このモデルでは、マルチビュー画像がエンコーダー-デコーダーネットワークに送られ、バウンディングボックスやアテンションマップなどの物体のアノテーションを予測するように訓練される。これらのマップは、「右折している車両を見つけて」のようなプロンプトと組み合わされる。次のブロックは、ハンガリアンアルゴリズムのような二部グラフマッチングアルゴリズムを使用して、3Dバウンディングボックスの位置を特定し、IDを割り当てる。 これはクールだが、これまでのところLLMの「最高の」応用とは言えない。 意思決定、ナビゲーション、計画におけるLLM もしChat-GPTが画像内の物体を見つけられるなら、それらの物体をどう扱うべきか教えられるはずではないか？そう、これが計画のタスク、つまり現在の知覚に基づいてAからBへの経路を定義することだ。このタスクのために開発された数多くのモデルがある中で、私の目を引いたのはTalk2BEVだった。 モデル間の主な違いは、

Car-GPT: 大規模言語モデルはついに自動運転車を実現させるか？

背景や根拠まで確認しますか？

関連記事

調べる

選ぶ

サイト

背景や根拠まで確認しますか？

関連記事

ニュースの次に確認する

調べる

選ぶ

サイト