論文 G1 完全な論文提案 v1: 低高度交通クラウド脳のための検証可能な LLM エージェント
核心的判断: 最初の論文は「大規模な低空交通モデルの微調整」として書かれるべきではなく、検証可能、再現可能、展開可能な低空交通 LLM エージェント手法の論文として書かれるべきです。
推奨トピック: CloudBrain-Agent: 低高度交通運用のためのツール強化および検証ガイド付き LLM エージェント。
1. 論文の位置付けと投稿の判断
1.1 一文での位置づけ
この記事では、低高度交通クラウド脳の大規模モデル エージェントについて研究します。つまり、自然言語タスク、都市の低高度空域のステータス、UAV フリートのステータスと安全制約が与えられた場合、LLM エージェントが構造化された中間表現、ツールの呼び出し、形式的な検証、およびシミュレーションのフィードバックを通じて、安全で実行可能かつ解釈可能な低高度交通運用の決定をどのように生成できるかについて研究します。
1.2 推奨される貢献
推奨: AAAI/IJCAI マスター。
代替案: AAMAS、IROS/ICRA ワークショップ、T-ITS フォローアップ拡張。
2026 年 5 月 20 日の時点によると、特定のセッションは AAAI/IJCAI CFP の次のラウンドに合わせる必要があります。この記事は依然として AAAI/IJCAI メインカンファレンスのスタイルでデザインされています。AAAI は AI の手法、応用分野、再現性を重視しており、IJCAI-ECAI の AI およびロボット工学トラックは明らかにロボット エージェント、生成 AI、推論、構造化モデリング、アクションの結果に焦点を当てているからです [1] [2]。
1.3 なぜこの記事が「低空交通大規模モデルの微調整」よりも最初に行うのに適しているのか
LowAltitudeGPT を直接微調整すると、次の 3 つのレビュー リスクが発生します。
- LoRA、QLoRA、DPO はすでに成熟したトレーニング パラダイムです。単にドメイン データを変更するだけでは、主要な貢献を構成するには十分ではありません [3] [4] [5]。
- 低高度交通は安全性が重要なシステムであり、LLM が制御動作を直接出力することを審査員に納得させるのは困難です。
- 実際の低空交通運行データは不足しています。最初の記事で「大規模モデルのトレーニング」に焦点を当てると、データの規模、トレーニングの予算、モデルの新規性が問われます。したがって、最初の記事では、エージェント + ツール + 検証者 + シミュレーターのフィードバックに焦点を当てる必要があります。大規模なモデルは最終的なコントローラーではなく、タスクの理解、ツールのオーケストレーション、反例の修復、解釈の層です。この設定は、ReAct、ToolLLM、LLM+P [6] [7] [8] などのエージェント/ツールの使用/計画作業に自然に関連しており、トラフィック基盤モデルと LLM の間の相互作用に関する TrafficGPT の議論にも追いつくことができます [9]。
1.4 2026-05-22 ライティングキャリブレーション: G1 を TR-C ストーリーとして書かず、交通システムの証拠を保管してください
G1 への最初の投資は AAAI/IJCAI であるため、主な貢献は交通ジャーナル形式のシステム ナラティブではなく、AI エージェント手法である必要があります。より正確な書き方は次のとおりです。
CloudBrain-Agent は、安全性が重要な低空交通ドメインで評価された AI エージェント メソッドです。
言い換えれば、交通現場は実際の困難と安全上の制約を提供しますが、論文は依然としてエージェント分野の質問に答える必要があります。つまり、ツールの呼び出しは信頼できるかどうか、状態は一貫しているかどうか、反例の修復は有効かどうか、モデルは幻想かどうか、評価は再現可能かどうかなどです。
同時に、G1 は task_success と tool_call_accuracy のみを報告することはできません。低高度の交通は安全上重要なエリアであるため、交通システムの証拠は実験の最初のバージョンから保存する必要があります。|レベル | AAAI/IJCAI 本文フォーカス | T-ITS 拡大のフォローアップに注力 |
|------|---------------------|----------|
|エージェントの機能 | IR の有効性、ツール呼び出しの精度、修復の成功率、幻覚率 |人間による確認、オペレーターの作業負荷、ステートフルな一貫性 |
|安全性 |安全違反、NFZ違反、バッテリー違反 | LoWC/NMAC プロキシ、リスク比、天候/通信劣化 |
|効率 |実行可能ファイルの決定、レイテンシー、ランタイム |遅延、余分な距離、エネルギー、スループット |
|一般化 |目に見えない都市、ストレス、UNSAT/曖昧なタスク |高密度の廊下、非協力的な UAV、通信損失、実際のコンテキストの都市分割 |
|システム啓発 |検証者のフィードバックが必要な場合 | LLM エージェントの決定論的ソルバー/人間のスーパーバイザーからどのシナリオを返す必要があるか |
したがって、G1 の境界条件は明確に記述する必要があります。
- 実際の展開を主張しないでください。
- エンドツーエンドの自動制御を主張しません。
- LLM は、代替のスケジューラ/プランナー/バリデータであるとは主張されていません。
- LLM エージェントがタスクの理解、オーケストレーション、修復とツール チェーンの解釈、および検証フィードバックに責任があるとのみ主張します。
- 交通システムの結論は「観察可能な運用への影響」としてのみ書かれており、政策勧告として誇張されてはいません。
1.5 2026-05-23 コンパイル: 提出バージョンの凍結リスト
G1 申請の最初のバージョンでは、低空プラットフォーム仕様にならないように、次の 3 つのクレームを凍結する必要があります。1. ドメインベースのツール使用ベンチマーク: CloudBrain-Bench は、JSON 形式をテストするだけでなく、関数の選択、パラメーターのグラウンディング、状態の依存関係、ポリシーの遵守、および低高度輸送チェーンにおけるマルチラウンドの一貫性もテストします。
2. 検証者による修理: 低空交通ミッションにおける安全エラー、実行不可能なエラー、およびあいまいなタスクは、LTL/STL 検証者、ルート プランナー、およびシミュレーターのフィードバックを通じて構造化された修復信号に変換する必要があります。
3. ローカルに展開可能なエージェントの実装: メインの実験はローカルのオープンソース モデルで再現可能である必要があり、API モデルは教師または上限としてのみ機能します。
最初の部分を完了する必要があります。|モジュール |凍結要件 |
|------|----------|
|低高度IR |スキーマ、型チェッカー、エラー コード、JSON の例を修正 |
|ツール |少なくとも 6 つ: 空域クエリ、フリート状況、割り当て、ルート プランナー、LTL/STL 検証ツール、シナリオ シミュレーター / リスク推定ツール |
|クラウドブレインベンチ |開発/検証/テスト/ストレス分割、SAT、UNSAT、曖昧、リソース制限、ストレス シナリオをカバー |
|ベースライン | Direct LLM、JSON のみ、ReAct、LLM+P / プランナーのみ、ツールを使用しない検証ツール、CloudBrain フル |
|メトリクス |タスクの成功、ツール呼び出しの精度、実行可能決定、安全違反、修復の成功、幻覚率、待ち時間/コスト |
|アブレーション | IR なし、ベリファイアなし、シミュレータなし、修復なし、API 教師とローカル モデル |
|データ層 |合成マスター データ + OSM/FAA/OD/SUMO リアル コンテキスト フィールド。デプロイされたシステムとしてリアル データを書き込まないでください。
最初の一時停止されたコンテンツ:
- 完全な MCP 製品化。
- 主な貢献としてのマルチエージェントのコラボレーション。
-LowAltitudeGPT 微調整モデルをメイン メソッドとして作成します。
- 実際の UAV の展開または飛行;
- VLA/ワールドモデル/具現化されたAGI提案。
この凍結リストの機能は、論文の境界を制御することです。G1 は、「低空交通安全の主要な領域における検証可能な LLM エージェント」が確立されていることを証明するだけであり、その後の G2/G3/G4 はそれぞれ、微調整、マルチエージェント、具体的な拡張に対処します。
---## 2. 要約草案
都市の低空での交通運用では、動的なタスク、限られた空域リソース、UAV ステータスの制約、および安全ルールの間でリアルタイムの意思決定が必要です。大規模な言語モデルには、自然言語を理解し、複雑なタスクを分解する機能がありますが、UAV のスケジューリングや経路計画に直接使用すると、幻覚、実行不可能な計画、安全違反が発生します。この記事では、低高度交通クラウド ブレイン用のツール拡張および検証ガイダンス LLM エージェント フレームワークである CloudBrain-Agent を提案します。 CloudBrain-Agent は、自然言語タスクとシステム状態を型付きの「LowAltitudeIR」に解析し、空域クエリ、UAV 割り当て、経路計画、LTL/STL 検証、シナリオ シミュレーション、リスク評価ツールを呼び出し、検証者の反例とシミュレーション フィードバックを使用して決定を繰り返し修正します。私たちは CloudBrain-Bench を構築して、緊急物流、検査、飛行禁止区域の回避、廊下の混雑、充電のボトルネック、マルチモードのフォールバック、および不十分なタスクをカバーします。実験では、直接 LLM、プロンプトのみの ReAct、検証なしのツール使用、LLM+P、TrafficGPT スタイルのオーケストレーション、および CloudBrain-Agent フルを比較します。事前登録の期待では、CloudBrain-Agent は、ローカル デプロイメントの許容可能なレイテンシーを維持しながら、タスクの成功率、実行可能決定率、安全違反率、幻覚率、および修復の成功率において、プロンプトのみおよびツールのみのベースラインを大幅に上回っていることが期待されています。
3. 研究課題と中心となる仮説
3.1 研究の質問
RQ1: LLM エージェントは、低空交通ミッションで正しいタイプのツール実行可能な意思決定チェーンを安定して生成できますか?
RQ2: 正式な検証とシミュレーションのフィードバックにより、LLM における実行不可能な計画、セキュリティ違反、幻覚を大幅に減らすことができますか?
RQ3: 垂直モデルを直接微調整する場合と比較して、一般的な LLM + 型付き IR + MCP/ツール + 検証ツールのソリューションは、再現可能、展開可能、スケーラブルな研究システムをより迅速に形成できますか?RQ4: ローカルのオープンソース モデルは、教師 API によって生成されたデータとルールのフィードバックの下でクローズド ソースの強力なモデルのパフォーマンスに近づき、その後の LowAltitudeGPT 論文をサポートできますか?
3.2 基本的な前提条件
H1: 型指定された LowAltitudeIR は、構造化出力の品質とツール呼び出しの精度を大幅に向上させることができます。
H2: 検証ガイド付き修復により、実行可能決定率が大幅に向上し、安全違反率が減少します。
H3: シミュレータのフィードバックは、目に見えない危険なシーンを一般化するために最も重要です。
H4: 最初の段階で垂直基礎モデルをトレーニングする必要はありません。 G1 ペーパーを完成するには、一般的なモデル + エージェント ツール レイヤ + ベリファイアの後処理で十分です。
H5: ローカルの Qwen3 / DeepSeek-R1-Distill モデルが vLLM を通じてデプロイされた後、再現可能なメインの実験モデルとして使用できます。 GPT-5.2 などの API モデルは教師およびパフォーマンスの上限として機能します [10] [11] [12]。
4. 論文寄稿デザイン
分散を避けるために、論文の最終的な寄稿は 3 つの記事に分けて書くことをお勧めします。
-
CloudBrain-Agent フレームワーク
自然言語タスク、都市空域ステータス、UAV フリートステータスおよび安全制約を「LowAltitudeIR」に統合する、低高度交通クラウド脳用の型付きツール使用 LLM エージェントが提案されています。
-
低空交通運用のための検証ガイド付き修理
LTL/STL 検証者、ルート プランナー、シミュレーターからの障害フィードバックを、LLM 修復ツールの呼び出し、タスクの制約、およびパス/スケジュールの推奨事項を推進する構造化された反例に変換します。3. CloudBrain-Bench と評価プロトコル
ツール呼び出しの精度、実行可能な決定、安全違反、修復の成功、一般化、遅延、人間の信頼などの指標をカバーする、低高度交通クラウド ブレイン ベンチマークを構築します。
「大規模な低高度交通モデルを訓練しました」と貢献を書くことはお勧めできません。微調整は実験的な拡張機能として、または次の G2 として実行できます。
4.1 第 2 ラウンドの調査後の論文ポジショニング マトリックス
オンライン調査の結果、G1 への最適なエントリ ポイントは、一般的な LLM アプリケーションではなく、ドメインに基づいたエージェント評価 + 安全性検証であることがより明確になります。 AgentBench は、LLM エージェントが対話型環境で推論と意思決定を評価する必要があることを証明しています [34]。 BFCL は、関数呼び出しでは関数の選択、パラメーター、並列呼び出し、および関連性の検出をチェックする必要があると説明しています [35]。 -bench は、マルチラウンド インタラクション、API、ドメイン ポリシー、一貫性インデックス pass^k をさらに強調しています [36]。 ToolSandbox は、状態の依存性、正規化、情報不足がツールベースのエージェントの主な問題点であると指摘しています。 [37]。
これらの研究から G1 のインスピレーションを得たものは次のとおりです。CloudBrain-Bench は、「JSON が出力されるかどうか」を評価するだけでなく、低高度輸送チェーンにおけるエージェントの ステータス更新、ルール準拠、ツール依存関係、障害修復、およびマルチラウンド一貫性も評価します。|すでに指示されています |代表作 |制限事項 | G1の違い |
|----------|----------|------|----------|
|一般的なエージェントのベンチマーク | AgentBench、-bench、ToolSandbox [34] [36] [37] |低空の交通安全制約と UAV ツール チェーンは含まれません。 UTM/UAV 用のドメイン ツール、ポリシー、ベリファイア |
|関数呼び出しベンチマーク | BFCL [35] |関数呼び出しの正確さに重点を置き、物理的な実行可能性やセキュリティは気にしない |ツール呼び出しはプランナー/検証者/シミュレーターを経由する必要があります。
| LLM + トラフィック | TrafficGPT、ITS LLM 調査 [9] [13] [14] |多焦点の地上交通または交通モデルの相互作用 |低空空域、UAV フリート、正式な安全性への拡張 |
| NL から LTL へ / ロボットタスク仕様 | Lang2LTL、LTLCodeGen、ConformalNL2LTL [21] [22] [23] |主に仕様生成を解決します |仕様の検証を完全なクラウド脳の意思決定の閉ループに組み込む |
| UTM/UAM シミュレーション | NASA TCL4、CORUS-XUAM、AAM-ジム [38] [39] [40] | LLM エージェント ツールのオーケストレーションは通常研究されていません。 UTM/UAM の概念とシナリオで CloudBrain-Bench をサポート |
5. 関連する作業フレームワーク
輸送用の 5.1 LLM
TrafficGPT は、LLM が交通基盤モデルの対話および処理の入り口として使用できると説明していますが、交通数値データ、シミュレーション、およびモデルの対話はプレーン テキストだけでは生成できないことも指摘しています [9]。最近の ITS レビューでは、トラフィック セマンティック インターフェイス、意思決定支援、およびマルチソース データ理解に LLM がさらに位置づけられています [13] [14]。 UrbanGPT と UniST は都市時空基盤モデルの方向性を示しており、都市状態の理解を支援するのに適していますが、低高度での UAV 運用ツールチェーンではありません [15] [16]。### 5.2 LLM エージェントとツールの使用
ReAct は推論トレースとアクションを織り交ぜており、この記事のエージェント ループの基礎となっています [6]。 Toolformer と ToolLLM は、LLM が API/ツールの使用法を学習できることを証明していますが、低空での交通安全の検証とミッションの実行可能性の問題は解決しません [7][17]。 MCP および OpenAI Agents SDK は、より標準的なツール接続方法を提供し、スケジューラ、プランナー、ベリファイア、シミュレータを置き換え可能なツールにするのに役立ちます [18] [19]。
第 2 ラウンドの調査の後、関連作業でエージェント評価システムも追加する必要があります。AgentBench は、エージェントとしてのマルチ環境 LLM ベンチマークです [34]。 BFCL は、特に関数呼び出しと関連性検出を評価します [35]。 -bench は、ユーザーとエージェントとツールの対話を複数回行い、信頼性を評価するために pass^k を使用します [36]。 ToolSandbox は、ツールの実行ステータス、暗黙的な依存関係、情報不足のシナリオを強調します [37]。 G1 評価プロトコルにはこれらのアイデアを組み込む必要がありますが、環境を低高度交通クラウド ブレインに変更する必要があります。
5.3 LLM の計画と正式な検証
LLM+P と PlanBench は、LLM だけでは計画の信頼性が低く、外部のプランナー、正式な表現、評価プロトコルと組み合わせる必要があることを示しています [8] [20]。 Lang2LTL、LTLCodeGen、および ConformalNL2LTL は、自然言語から時相論理への変換が発展していることを示していますが、主に仕様の生成と、低高度交通クラウド脳におけるスケジューリング、ルーティング、シミュレーションおよびリスク閉ループの不完全なカバーに焦点を当てています [21] [22] [23]。 Spot と RTAMT はそれぞれ LTL/STL 検証ツールとして使用できます [24] [25]。
5.4 UAV、UTM、およびシミュレーション データFAA UTM は、低高度 UAV 交通管理を、飛行計画、認可、監視、紛争管理をサポートする協調的な生態系として定義しています [26]。 FAA UAS Facility Maps は、管制空域でのパート 107 の運用を迅速に承認できる高度の基準を提供し、空域規則の代理に適しています [27]。 OSM/Overpass、NYC TLC OD データ、SUMO、AirSim、および Flightmare は共同で合成から本物へのベンチマークをサポートできます [28] [29] [30] [31] [32]。
低高度交通の信頼性を高めるために、G1 はさらに NASA TCL4 ネバダ飛行試験を引用すべきである。この試験には目視外、都市峡谷、気象前線、コンサートの緊急対応、CNS 問題のシナリオが含まれており、シナリオ分類法や人間システムの情報品質に関する議論の情報源として適している [38]。ヨーロッパの CORUS-XUAM は、U スペース/UAM 運用コンセプト、U3/U4 サービス モデル、ATM-U スペース調整、ベルティポート ガイダンス、および人間参加型証拠を提供します [39]。 AAM-Gym は、高度なエアモビリティ AI テストベッド、特に通路分離保証のシミュレーション制御として使用できます [40]。
6. 問題の定式化
6.1 システムステータス
離散決定時刻 に、低高度交通雲の脳はシステム ステータスを受け取ります。
その中には:- : UAV のコレクション。各 UAV には、位置、電力、負荷、速度、およびミッション ステータスがあります。
- : 配布、検査、緊急対応、返却、充電を含むタスクの収集。
- : 回廊、飛行禁止区域、高度、天候、収容人数などの空域ステータス。
- : OSM 道路網、POI、建物、機能エリアを含む市内地図。
- : LTL/STL、期限、距離、エネルギーを含む安全性と運用上の制約。
- : 過去の出来事、失敗事例、人間によるフィードバック、検証者のフィードバック。
自然言語命令は で表されます。目標は、実行可能な決定を生成することです。
は「LowAltitudeIR」、 はツール呼び出しシーケンス、 はスケジュール/パス/リスクの決定、 は説明です。
6.2 安全な実行可能ターゲット
の決定は、次の場合にのみ成功したとみなされます。
- スキーマの有効性: は
LowAltitudeIR 型制約を満たします。
- ツールの実行可能性: すべてのツール呼び出しパラメーターは正当であり、エラー以外の結果を返します。
- 計画の実現可能性: スケジューリングと経路計画が実行可能です。
- 時間的安全性: LTL/STL 仕様が検証済み。
- シミュレーションの堅牢性: 指定されたシナリオ シードで衝突、飛行禁止区域違反、または期限違反を引き起こしません。
- 人間による解釈可能性: 解釈には、存在しないエンティティ、ツール、またはルールが関与しません。
フォーマル:$$
\text{成功}(\pi_t) =
\mathbb{1}[
V_\text{スキーマ}(z_t)
\land V_\text{ツール}(a_{1:k})
\land V_\text{計画}(y_t)
\land V_\text{ロジック}(y_t)
\land V_\text{sim}(y_t)
】
E_\text{ルート} = L_\text{ルート} \cdot q_{0.9}(e \mid v, h, p, w)
\text{IR-EM} = \frac{1}{N}\sum_i \mathbb{1}[z_i = z_i^*]
\text{TCA} = \frac{#\text{正しいツール呼び出し}}{#\text{すべてのツール呼び出し}}
\text{TDS} = \frac{#\text{すべてのデータ依存関係を満たすツール チェーン}}{#\text{ツール チェーン}}
\text{EDR} = \frac{#\text{プランナーの実行可能決定}}{N}
\text{TSR} = \frac{#\text{完全に検証され、成功したタスクをシミュレート}}{N}
\text{SVR} = \frac{#\text{安全違反のタスク}}{N}
\text{HR} = \frac{#\text{存在しないエンティティ/ツール/ルールを含む出力}}{N}
\text{RSR} = \frac{#\text{最初の試行の失敗は K 回の反復内で修復されました}}{#\text{最初の試行の失敗}}
\text{パス}^k = \frac{#\text{すべての } k \text{ の繰り返し実行で成功したタスク}}{N}