論文 G1 完全論文提案 v1: 低高度交通クラウドブレイン用の検証可能な LLM エージェント

最初の CloudBrain-Agent カンファレンス ペーパーに向けて、リサーチの質問、提出物の位置づけ、アルゴリズム設計、データ構築、モデルの選択、ローカル展開、実験計画、評価指標、予想される結論、チャートの設計、リスク管理および実行計画を完全に計画します。

論文 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 つのレビュー リスクが発生します。

  1. LoRA、QLoRA、DPO はすでに成熟したトレーニング パラダイムです。単にドメイン データを変更するだけでは、主要な貢献を構成するには十分ではありません [3] [4] [5]。
  2. 低高度交通は安全性が重要なシステムであり、LLM が制御動作を直接出力することを審査員に納得させるのは困難です。
  3. 実際の低空交通運行データは不足しています。最初の記事で「大規模モデルのトレーニング」に焦点を当てると、データの規模、トレーニングの予算、モデルの新規性が問われます。したがって、最初の記事では、エージェント + ツール + 検証者 + シミュレーターのフィードバックに焦点を当てる必要があります。大規模なモデルは最終的なコントローラーではなく、タスクの理解、ツールのオーケストレーション、反例の修復、解釈の層です。この設定は、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_successtool_call_accuracy のみを報告することはできません。低高度の交通は安全上重要なエリアであるため、交通システムの証拠は実験の最初のバージョンから保存する必要があります。|レベル | AAAI/IJCAI 本文フォーカス | T-ITS 拡大のフォローアップに注力 | |------|---------------------|----------| |エージェントの機能 | IR の有効性、ツール呼び出しの精度、修復の成功率、幻覚率 |人間による確認、オペレーターの作業負荷、ステートフルな一貫性 | |安全性 |安全違反、NFZ違反、バッテリー違反 | LoWC/NMAC プロキシ、リスク比、天候/通信劣化 | |効率 |実行可能ファイルの決定、レイテンシー、ランタイム |遅延、余分な距離、エネルギー、スループット | |一般化 |目に見えない都市、ストレス、UNSAT/曖昧なタスク |高密度の廊下、非協力的な UAV、通信損失、実際のコンテキストの都市分割 | |システム啓発 |検証者のフィードバックが必要な場合 | LLM エージェントの決定論的ソルバー/人間のスーパーバイザーからどのシナリオを返す必要があるか |

したがって、G1 の境界条件は明確に記述する必要があります。

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 リアル コンテキスト フィールド。デプロイされたシステムとしてリアル データを書き込まないでください。

最初の一時停止されたコンテンツ:

この凍結リストの機能は、論文の境界を制御することです。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 つの記事に分けて書くことをお勧めします。

  1. CloudBrain-Agent フレームワーク 自然言語タスク、都市空域ステータス、UAV フリートステータスおよび安全制約を「LowAltitudeIR」に統合する、低高度交通クラウド脳用の型付きツール使用 LLM エージェントが提案されています。

  2. 低空交通運用のための検証ガイド付き修理 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 には、位置、電力、負荷、速度、およびミッション ステータスがあります。

自然言語命令は で表されます。目標は、実行可能な決定を生成することです。

は「LowAltitudeIR」、 はツール呼び出しシーケンス、 はスケジュール/パス/リスクの決定、 は説明です。

6.2 安全な実行可能ターゲット

の決定は、次の場合にのみ成功したとみなされます。

  1. スキーマの有効性: LowAltitudeIR 型制約を満たします。
  2. ツールの実行可能性: すべてのツール呼び出しパラメーターは正当であり、エラー以外の結果を返します。
  3. 計画の実現可能性: スケジューリングと経路計画が実行可能です。
  4. 時間的安全性: LTL/STL 仕様が検証済み。
  5. シミュレーションの堅牢性: 指定されたシナリオ シードで衝突、飛行禁止区域違反、または期限違反を引き起こしません。
  6. 人間による解釈可能性: 解釈には、存在しないエンティティ、ツール、またはルールが関与しません。

フォーマル:$$ \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) 】

You can't use 'macro parameter character #' in math mode ### 6.3 この記事で行われないこと - LLM が低レベルの制御変数を直接出力しないようにします。 - 実際の空域を主張せずに直接展開できます。 - 合成データを実際の運用データとして偽装しないでください。 - 低空交通基礎モデルを最初からトレーニングしないでください。 --- ## 7. メソッド: CloudBrain-Agent ### 7.1 全体的なアーキテクチャ ```text User instruction + System state -> Context builder / RAG -> LLM planner -> LowAltitudeIR -> Tool router -> Scheduler / Route planner / Verifier / Simulator / Risk assessor -> Counterexample & robustness feedback -> Repair agent -> Final verified decision + explanation ``` ### 7.2 低高度赤外線 「LowAltitudeIR」がこの論文の鍵となります。これは通常の JSON 出力よりも厳密であり、ツールとバリデーターを接続できる必要があります。 ```json { "task_id": "task_00042", "intent": "emergency_delivery", "priority": "high", "entities": { "origin": "hospital_A", "destination": "accident_site_3", "candidate_uavs": ["uav_03", "uav_07"] }, "constraints": { "deadline_sec": 600, "avoid_zones": ["school_zone_2", "nfz_temp_1"], "altitude_min_m": 30, "altitude_max_m": 120, "min_separation_m": 10, "battery_reserve_ratio": 0.2 }, "tool_plan": [ {"tool": "query_airspace", "args": {"region": "downtown"}}, {"tool": "assign_uav", "args": {"objective": "min_delay_safe"}}, {"tool": "plan_route", "args": {"planner": "astar_3d"}}, {"tool": "verify_ltl_stl", "args": {"logic": ["avoid_nfz", "meet_deadline"]}}, {"tool": "simulate_scenario", "args": {"stress_level": "medium"}} ], "fallback_policy": "ground_transfer_or_human_confirm" } ``` フィールドレベルの制約: |フィールド |種類 |制約 | |------|------|------| | `意図` |列挙型 |配送 / 巡回 / 点検 / 緊急 / 返却 / 充電 | | `優先度` |列挙型 |低 / 通常 / 高 / クリティカル | |エンティティ |オブジェクト |マップまたは UAV 状態に存在するエンティティを参照する必要があります。 | `制約` |オブジェクト |プランナー/検証者の入力に変換できなければなりません | | `ツールプラン` |リスト |ツール名はレジストリから取得する必要があり、パラメーターはスキーマに準拠している必要があります。 | `フォールバックポリシー` |列挙型 |到達不能、安全でない、タイムアウトの場合にトリガーされます。 ### 7.2.1 LowAltitudeIR v0.1 の詳細なフィールド仕様 最初のバージョンでは、IR を大きすぎないように設計しますが、各フィールドがツールで使用でき、インジケーターで評価でき、分析してエラーの原因を特定できるようにします。 IR を 9 つの最上位フィールドに分割することをお勧めします。|トップレベルのフィールド |必須 |タイプ |説明 |障害が影響するメトリクス | |----------|------|------|------|------| | `タスクID` |はい |文字列 |データセット内の一意のタスク ID |トレーサビリティ | | `意図` |はい |列挙型 |タスクの目的: 配送、検査、パトロール、緊急、帰還、充電、監視 | IR フィールド F1 | | `優先度` |はい |列挙型 |低、通常、高、重大 |ポリシーの遵守 | |エンティティ |はい |オブジェクト |出発地、目的地、候補 UAV、機密ゾーン、ハンドオフポイント |幻覚率 | | `制約` |はい |オブジェクト |時間、高度、距離、バッテリー、飛行禁止区域、容量、気象リスク |安全違反率 | | `ツールプラン` |はい |リスト |ツール呼び出し DAG の線形化計画 |ツール呼び出しの精度 | | `検証仕様` |はい |オブジェクト | LTL/STL 仕様と解釈可能な自然言語ルール |検証済み決定率 | | `フォールバックポリシー` |はい |列挙型 |地上転送、待機、人間確認、安全拒否 |安全な拒否精度 | | `説明_計画` |いいえ |オブジェクト |説明で参照する必要があるツールの結果と制約 |人間の信頼スコア | エンティティ フィールドの推奨事項は以下に固有です。|フィールド |例 |確認方法 | |------|------|----------| | `起源` | `病院_A` | `city_state.entities` に存在する必要があります。 | `目的地` | `事故現場_3` |タスクまたはマップに存在する必要があります | | `candidate_uavs` | `["uav_03", "uav_07"]` | `uav_state` に存在し、ステータスが利用可能である必要があります。 | `回避ゾーン` | `["school_zone_2", "nfz_temp_1"]` |空域/マップに存在する必要があります | | `ハンドオフポイント` | `["メトロ駅_4"]` |マルチモーダル フォールバックに必要 | 制約フィールドの推奨事項は以下に固有です。 |フィールド |単位 |デフォルト |説明 | |------|------|------|------| | `デッドライン_秒` | 2番目 |ヌル |期限がない場合は空 | | `高度_分_m` |メーター | 30 |最低飛行高度 | | `高度_最大_m` |メーター | 120 |最大高度、空域プロキシの影響を受ける | | `min_separation_m` |メーター | 10 |障害物/UAV/感知ゾーンまでの最小距離 | | `バッテリー予備率` |比率 | 0.2 |到着後の最低バッテリー残量率 | | `最大リスクレベル` |列挙型 |中 |低、中、高 | | `corridor_capacity_required` |整数 | 1 |廊下が占める最小収容人数 | ### 7.2.2 LowAltitudeIR 検証シーケンス エラー分析を容易にするために、IR 検証は階層化する必要があります。1. **JSON validity**: JSON に解析できるかどうか。 2. **スキーマの有効性**: フィールド タイプ、列挙型、および必須フィールドが正しいかどうか。 3. **エンティティのグラウンディング**: すべてのエンティティが現在の状態で存在するかどうか。 4. **制約のグラウンディング**: 制約をプランナー/検証者のパラメーターに変換できるかどうか。 5. **ツールの依存関係**: ツールの入力が前のツールの出力に依存するかどうか。 6. **ポリシーの互換性**: 優先順位、フォールバック、人間による確認がルールに準拠しているかどうか。 障害の各レベルは、次のように `error_type` に書き込む必要があります。 ```json { "valid": false, "stage": "entity_grounding", "error_type": "nonexistent_destination", "field": "entities.destination", "value": "hospital_X", "allowed_entities": ["hospital_A", "hospital_B", "accident_site_3"] } ``` ### 7.3 ツールレジストリ ツールの最初のバージョンは Python 関数にしてから、MCP サーバーにパッケージ化する必要があります。 MCP の利点は、標準化されたツール/コンテキスト インターフェイスであり、これにより、異なるモデルとエージェント ランタイムが同じツール セットを再利用できるようになります [18] [19]。|ツール |必須 |入力 |出力 |障害の種類 | |------|------|------|------|----------| | `クエリ_都市_州` |はい |地域、時間 | POI、建物、地上グラフ |不明な地域 | | `クエリ空域` |はい |地域、高度、時間 |廊下、NFZ、天井 |制限空域 | | `assign_uav` |はい |タスク、UAV の状態 |選択された UAV / なし | no_available_uav | | `計画ルート` |はい |スタート、ゴール、制約 |パス / 到達不能 |パスなし | | `verify_ltl_stl` |はい |パス、時間的仕様 |合格/不合格/反例 |仕様違反 | | `シミュレーションシナリオ` |はい |意思決定、シナリオシード |成功/リスク/衝突 | sim_失敗 | | `リスク評価` |はい |決定、状態 |リスクスコア、理由 |高リスク | | `説明_決定` |オプション |決定トレース |説明 |幻覚説明 | ### 7.3.1 ツール API コントラクト すべてのツールは一律に次の値を返します。 ```json { "ok": true, "tool": "plan_route", "request_id": "tool_00042_03", "result": {}, "warnings": [], "error": null, "provenance": { "input_hash": "sha256:...", "data_sources": ["city_osm", "airspace_rules"], "timestamp": "2026-05-20T12:00:00Z" } } ``` 失敗時: ```json { "ok": false, "tool": "plan_route", "request_id": "tool_00042_03", "result": null, "warnings": [], "error": { "type": "no_path", "message": "No feasible path avoiding nfz_temp_1 within altitude range.", "recoverable": true, "suggested_actions": ["relax_deadline", "choose_ground_transfer", "human_confirm"] }, "provenance": { "input_hash": "sha256:...", "data_sources": ["city_grid", "airspace_rules"] } } ``` 特定のツールの入力と出力:|ツール |キー入力フィールド |主要な出力フィールド |回復可能な障害 |回復不可能な障害 | |-----|--------------|--------------|---------------|--------------| | `クエリ_都市_州` | `region_id`、`bbox`、`time` | `ポア`、`建物`、`道路`、`センシティブゾーン` | `部分マップ` | `不明な領域` | | `クエリ空域` | `bbox`、`高度範囲`、`時間` | `廊下`、`nfz`、`定員`、`天井` | `容量_低` | `制限空域` | | `assign_uav` | `タスク`、`uav_states`、`目的` | `uav_id`、`assignment_score`、`reason` | `low_battery_candidates` | `no_available_uav` | | `計画ルート` | `スタート`、`ゴール`、`回避`、`高度範囲` | `waypoints`、`length_m`、`eta_sec`、`energy_est` | `デッドライン_リスク` | `no_path` | | `verify_ltl_stl` | `軌跡`、`スペック` | `合格`、`違反`、`堅牢性`、`反例` | `ネガティブロバストネス` | `無効な仕様` | | `シミュレーションシナリオ` | `決定`、`シナリオシード`、`ストレスレベル` | `成功`、`イベント`、`最小距離`、`遅延`、`リスク` | 「ニアミス」s` | 「衝突」 | | `リスク評価` | 「決定」、「天気」、「交通」、「歴史」 | `risk_score`、`risk_level`、`top_reasons` | `中リスク` | `高リスク_オーバーライドなし` |### 7.3.2 ツール依存関係 DAG ツール呼び出しは任意のシーケンスではなく、依存関係を満たす必要があります。 ```text query_city_state -> query_airspace -> assign_uav -> plan_route -> verify_ltl_stl -> simulate_scenario -> risk_assess -> explain_decision ``` スキップできる状況: - `simulate_scenario` は dev-mini ではオフにできますが、メインの実験ではオンにする必要があります。 - 「risk_assess」は「simulate_scenario」にマージできますが、紙の指標は依然として個別にレポートされます。 - `explain_decision` はタスクの成功には影響しませんが、人間の信頼と幻覚には影響します。 ### 7.3.3 最小実装バージョン 最初のバージョンでは、すべてのツールが決定論的になる可能性があります。 |ツール |最小限のアルゴリズム |複雑なバージョン | |------|----------|----------| | `クエリ_都市_州` | JSON/GeoJSON からエンティティを読み取る | OSM/Overture 動的クエリ | | `クエリ空域` |ルール テンプレート + ポリゴン交差 | UTM/U-spaceサービスシミュレーション | | `assign_uav` |バッテリーフィルターを使用した貪欲な最小ETA | MILP / リャプノフ スケジューラー | | `計画ルート` | 3D A* グリッド | RRT* / MPC-lite | | `verify_ltl_stl` |手書きルール + RTAMT/スポット |完全な時相論理モニター | | `シミュレーションシナリオ` |離散時間運動学 |エアシム/フライトメア | | `リスク評価` |加重ルールスコア |学習されたリスク モデル | ### 7.4 検証ガイド付き修復 CloudBrain-Agent の鍵は、一度生成するのではなく、閉ループを修正することです。 ```text for i in 1..K: z_i = LLM(q, S, feedback_{i-1}) if not schema_valid(z_i): feedback_i = schema_error(z_i) continue trace_i = execute_tools(z_i) verdict_i = verify_and_simulate(trace_i) if verdict_i.pass: return decision_i feedback_i = compress_counterexample(verdict_i) return safe_refusal_or_human_confirm ``` 反例のフィードバックは、単に「失敗」するだけではなく、構造化する必要があります。たとえば: ```json { "failure_type": "stl_robustness_negative", "violated_constraint": "always distance_to_school_zone > 30m", "counterexample_time_sec": 142, "offending_segment": ["p17", "p18", "p19"], "suggested_repair": "increase detour radius or choose corridor_C" } ```### 7.5 安全メモリ セーフティメモリには次の 3 種類の情報が記録されます。 1. **既知の危険なパターン**: たとえば、バッテリー残量低下 + 高風速 + 厳しい締め切り。 2. **修復ケース**: 失敗した IR、反例、成功した修復 IR。 3. **人間の介入**: 手動による確認、拒否、および再割り当て。 最初の記事では、複雑な長期記憶は必要なく、取得を実装するだけで済みます。つまり、現在のタスクが与えられた場合、同様の失敗ケースを少数ショット修復コンテキストとして取得します。 ### 7.6 アルゴリズムの擬似コード 簡略化したアルゴリズムを論文の本文に掲載し、完全版を付録に掲載することをお勧めします。 ```text Algorithm 1: CloudBrain-Agent Input: q: natural-language instruction S: low-altitude traffic state T: typed tool registry R: rule and memory retriever K: maximum repair iterations 1: C <- BuildContext(q, S, R) 2: feedback <- null 3: for k = 0 ... K do 4: z <- LLM_Generate_IR(q, C, feedback) 5: schema_report <- ValidateIR(z, S, T) 6: if schema_report fails then 7: feedback <- Compress(schema_report) 8: continue 9: trace <- ExecuteToolPlan(z.tool_plan, T) 10: if trace has unrecoverable tool error then 11: return SafeRefusal(trace.error) 12: verdict <- VerifyAndSimulate(z, trace) 13: if verdict.pass then 14: explanation <- ExplainDecision(z, trace, verdict) 15: return VerifiedDecision(z, trace, verdict, explanation) 16: feedback <- CompressCounterexample(verdict) 17: return HumanConfirmOrSafeRefusal(feedback) ``` ### 7.7 複雑さと実行時間の予想 マップ グリッド サイズが $G = X \times Y \times Z$、候補 UAV の数が $|\mathcal{U}|$、ツール呼び出しラウンド数が $K$ であるとします。 |モジュール |主な複雑さ |最適化手法 | |------|-----------|----------| | IR生成 | $O(K \cdot C_\text{LLM})$ |キャッシュ プロンプト、短いフィードバック、低温 | | UAV の割り当て | $O(|\mathcal{U}|)$ 貪欲 |事前フィルタリングは利用できません。 | 3D A* | $O(G \log G)$ |コリドーマスク、階層グリッド、ヒューリスティック | | STLモニタリング | $O(T \cdot |\ファイ|)$ |ベクトル化された軌道チェック | |シミュレーション | $O(T \cdot N_\text{エージェント})$ |バッチシード、早期停止 | |検索 | $O(\log M)$ の概算 | FAISS/Qdrant | 最初の記事では、極端なリアルタイム パフォーマンスを追求する必要はありませんが、エンドツーエンドの遅延を報告する必要があります。推奨される目標:- dev-mini: 単一タスク 5 ~ 20 秒。 - ローカル 14B: シングルタスク 10 ~ 40 秒。 - API の上限: 1 つのタスクに対して 5 ~ 30 秒。 - バッチ評価: 非同期および同時実行ですが、各サンプルは独立したレイテンシーを記録します。 --- ## 8. データソースとCloudBrain-Benchビルド ### 8.1 データ構成 最初のメイン データ セットは **CloudBrain-Bench** という名前にすることをお勧めします。|データ層 |出典 |主な実験が依存するかどうか |機能 | |------|------|-----|------| |合成都市グリッド |手続き的に生成 |はい |制御可能、再現可能、スケーラブル | | OSM 都市のコンテキスト | OSM / オーバーパス |はい | POI、道路、建物、機能エリアの命名 | |オーバーチュアマップのコンテキスト |序曲 場所・建物・交通 |オプションの機能拡張 |高品質の POI、建物、道路トポロジ、安定したエンティティ ID | |実際の空域グリッド | FAA UAS 施設地図ポリゴン + UAS データ辞書 |はい |実際の UASFM ジオメトリ、天井、空域/空港/LAANC フィールド | | OD デマンド プロキシ | NYC TLC / シカゴタクシー オプション |オプション |需要ホットスポットとピークタスクを生成 | |地上交通 |相撲 |オプションの機能拡張 |地上フォールバック移動時間 | |航空天気 | NOAA 航空気象データ API METAR + Open-Meteo |オプションの機能拡張 |実際の航空天気、風速、視程、降水量、気象リスク | |実際の UAV 飛行テレメトリー | DJI Matrice 100 荷物配送飛行データセット |オプションの校正 |位置、電流、電圧、風、速度、荷重、高度のエネルギー消費量/ETA 校正 | | UTM フライトテストのコンテキスト | NASA TCL4 レポート |オプションの機能拡張 |都市峡谷、目視外、気象前線、緊急対応シナリオの分類 | | UAV ダイナミクス |自作軽量シミュレーター |はい |経路、エネルギー消費、衝突、遅延 | |ビジュアルシミュレータ |エアシム/フライトメア |オプションのサプリメント |その後の視覚的/動的拡張 |OSM/Overpass は都市の特徴をクエリするのに適しています [28]。 Overture Maps は、GeoParquet を通じて場所、建物、交通レイヤーを提供し、POI、建物、道路トポロジを補完できます [41]。空域レイヤーは、単に抽象的なプロキシとして記述すべきではありません。FAA UAS Facility Maps 公式ページでは、データ プロバイダー向けの UASFM データ エントリが提供されています。データ辞書は、形状、中心緯度/経度、「CEILING」、空域クラス、空港識別子、LAANC の準備状況などのフィールドを明確にします [27] [43]。気象レイヤーは、NOAA 航空気象データ API を使用して METAR などの航空気象観測を取得し、Open-Meteo を使用して履歴/グリッド気象機能を補完できます [42] [44]。実際の UAV ダイナミクス レイヤーでは、Scientific Data によってリリースされた DJI Matrice 100 小型荷物配送の飛行データを使用できます。このデータには何百もの飛行中の位置、エネルギー使用、風、荷重、高度、速度の変化が含まれており、何もないところからバッテリーのモデルを指定する代わりに、エネルギー消費とETAを校正するために使用できます[45]。 NYC TLC と SUMO は依然として需要と地上フォールバック プロキシとしてのみ機能します [29] [30]。 AirSim と Flightmare は閉ループ シミュレーションを補足します [31] [32]。 ### 8.1.1 実データの実現可能性判断 2 回目の検索後の結論は、「実際のデータは存在しない」ということではなく、**実際のデータはさまざまなレベルに存在し、公開された完全な低高度商業運用閉ループが欠如している**ということです。|データの問題 | 2026-05-21 一般公開 | G1で使える方法 |請求できないもの | |----------|--------------------------|---------------------|----------------| |市内地図/POI/建物/道路 |高 | OSM/序曲 リアルシティコンテキスト |実際のドローン回廊とは異なります | | UAS 空域高度グリッド |高 | FAA UASFM ポリゴン、天井、空域/LAANC フィールド | UASFM は飛行許可と同等ではありません | |航空気象学 |高 | NOAA METAR、Open-Meteo の風雨特性 |空港の天気はブロックレベルの低空の風力発電所と同等ではありません。 | UAV の実際の飛行エネルギー消費/位置 |中 | DJI M100 配信テレメトリーでエネルギー消費量と ETA を校正 |実際の運用スケジュール 100 に等しくない | | UTM テスト飛行シナリオと人間と機械の情報フロー |中 | NASA TCL4 シナリオ分類と UTM 情報の要件 |レポートは、公開されている未加工の UTM フリートの軌跡と同等ではありません。 |商用配送の注文フロー・実績ログ |低い | FAA の運用上の背景と将来の協力に対する動機のみを使用する | Zipline/Wing/Flytrex の注文トラックを偽造できません。 |リモート ID はリアルタイムの軌跡を大規模に公開します |低い |プライマリ データ ソースとして使用されない |リモート ID は既製のパブリック データセット フリートとして使用できません。 FAA Part 135のページには、米国はすでに荷物配達用ドローン運用の承認ルートと承認された運営主体を持っているため、研究上の疑問は純粋に仮説ではないと述べられている[46]。ただし、公共の運用命令フロー、空域紛争記録、商業飛行ログは通常、承認ページでは公開されません。リモート ID も、既製のオープンソース軌道ライブラリとして扱われるべきではありません。GAO は 2024 年にも、FAA がリアルタイムのネットワーク化されたドローンの位置/ステータス データを提供する経路を特定することを推奨しました [47]。したがって、G1 の強い声明は次のようになります。> 私たちは、実際のコンテキストと実際の飛行で調整された低高度エージェントのベンチマークを構築しますが、完全に実際の運用フリートのログは将来のオペレーターのコラボレーションに委ねられます。 ### 8.1.2 データ階層化戦略 CloudBrain-Bench は、信頼度を 3 つのレベルに分類することを推奨しています。 |階層 |名前 |データ構成 |論文における役割 | |------|------|----------|-----| | L1 | `合成制御` |プログラム都市、プログラム空域、プログラムタスク |制御可能なマスターコントラスト、アブレーション、統計的安定性 | | L2 | `リアルコンテキスト` | OSM/Overture + FAA UASFM + NOAA/Open-Meteo + プログラムタスク |主要な実験優先層、実際のコンテキスト基盤を証明 | | L3 | `リアルフライトキャリブレーション済み` | L2 + DJI M100 飛行エネルギー消費/ETA パラメーターの校正 |キャリブレーション解析と実際の飛行感度検証 | L3 を「実際の運用ベンチマーク」として記述することはお勧めできません。より安定した逆アセンブル方法は次のとおりです。 - **タスクとゴールド トレース**: 決定論的なジェネレーター、プランナー、検証者によって生成され、SAT/UNSAT の真の値が保証されます。 - **都市/空域/気象コンテキスト**: 可能な限り現実的に、エージェントが実際のエンティティおよび実際の空域フィールドに接地していることを確認します。 - **エネルギー消費/ETAモデル**: 実際の飛行データを使用してフィッティングまたはバケットキャリブレーションを行い、安全性の判断が任意のエネルギー消費パラメータに基づいていないことを検証します。 ### 8.1.3 実データ取得レシピ 最初の論文を再現可能にするために、データ取得を固定パイプラインとして記述することをお勧めします。|ステップ |入力 |操作 |出力 | |------|------|------|------| | 1 |都市境界ボックス | Overpass を使用して、病院、学校、公園、警察、消防署、建物、道路をクエリする | `city_osm.geojson` | | 2 |同じボックス | Overture の場所/建物を使用して POI と建物のフットプリントを補完し、安定したエンティティ ID を保持します。 `city_overture.寄木細工` | | 3 | FAA UASFM データダウンロード / bbox | UASFM ポリゴン、「CEILING」、空港/空域/LAANC フィールドを読み取る | `uasfm_cells.geojson` | | 4 |最寄りのICAO駅 + 時間枠 | NOAA METAR JSON をクエリして、風、視程、降水量/気象トークンを抽出します。 `aviation_weather.parquet` | | 5 |緯度と経度と期間 |空港以外の補足として Open-Meteo の履歴/予報天気をクエリする | `weather_grid.parquet` | | 6 |科学データ DJI M100 ファイル |位置、電圧、電流、風、積載量、高度、速度を解析 | `uav_flight_calibration.parquet` | | 7 |選択した都市と日付 |需要ヒートマップを形成するためのサンプル NYC TLC / シカゴ タクシー OD | `od_proxy.parquet` | | 8 | OSMロードグラフ | SUMO をインポートし、地上フォールバック移動時間を推定する | `ground_time_matrix.parquet` | | 9 | UTM/UASFM/CORUS/NASA TCL4 |マニュアルルール テンプレートとシナリオ分類を整理する | `airspace_rules.yaml` | | 10 |実際のコンテキスト + 調整された UAV パラメータ |プログラム生成 UAV タスク、NFZ、廊下、充電、気象リスク | `cloudbrain_samples.jsonl` | | 11 |サンプル |プランナー/検証者/シミュレーターは、SAT/UNSAT、ゴールド トレース、反例に自動的に注釈を付けます。 `cloudbrain_gold.jsonl` |メインの実験は、ステップ 1、3、9、10、および 11 に最小限依存します。ステップ 4 ~ 8 では、実際の天気、エネルギー消費量の校正、および地上フォールバックを提供します。各キャプチャでは、FAA/NOAA/地図データのその後の変更により再現性が失われるのを防ぐために、元のファイルのスナップショット、データ フィールドのバージョン、およびダウンロードの日付を保存する必要があります。 ### 8.1.4 実際のデータをベンチマークにマッピングする方法 |実フィールド | CloudBrainへの地図 |使い方 | |----------|-----------|----------| | OSM `アメニティ=病院/学校/消防署` | `出発地`、`目的地`、`センシティブゾーン` |コマンドエンティティの接地 | |オーバーチュアの建物の設置面積 |障害物ポリゴン |ルートプランナー/シミュレーター | | UASFM `形状`、`天井` |高度キャップセル | `query_airspace` ツール return | | UASFM 空港/空域分野 |空域の由来 |説明とポリシーのフィールド | | NOAA METAR 風/視程/天気 |気象リスク | 「risk_assess」、ストレスシナリオ | | M100 位置/速度/高度 |ルート/ETA キャリブレーション ビン |到着予定時刻の分布 | | M100 電流/電圧/ペイロード/風 |エネルギーモデルの校正 |バッテリー残量チェック | ### 8.1.5 実際の飛行校正タスク DJI M100 データを使用して、サポートできることのみを実行します。1. 積載量、巡航速度、高度、風に応じてバケツに分割します。 2. 電圧と電流の統合から飛行エネルギーまたはエネルギー消費プロキシを取得します。 3. `energy_per_meter`、`eta_multiplier`、または保守的な分位ルックアップを適合させます。 4. 総合プランナーのルート長をエネルギー推定値とバッテリー予備量の判断にマッピングします。 5. 校正済みエネルギーモデルと未校正エネルギーモデルの下で安全性の決定が変わるかどうかを付録で報告します。 最初のバージョンでは、複雑なブラック ボックスのエネルギー消費ネットワークの代わりに保守的な分位数を使用することをお勧めします。

E_\text{ルート} = L_\text{ルート} \cdot q_{0.9}(e \mid v, h, p, w)

You can't use 'macro parameter character #' in math mode ここで、$e$ は単位距離あたりのエネルギー消費量、$v$ は速度、$h$ は高さ、$p$ は荷重、$w$ は風の状態を表します。このようにして、G1 をエネルギー消費モデリングペーパーに変えることなく、実際の飛行データを安全性チェックに統合することができます。 ### 8.1.6 実データ分割設計 |分割 |データ層 |機能 | |------|--------|------| | `test_synthetic_controlled` | L1 |メインアブレーション、制御可能な難易度 | | `test_real_context_city_a` | L2 |実際の都市/空域/気象コンテキスト | | `test_real_context_city_b` | L2 |目に見えない都市の一般化 | | `テスト_リアル_ウェザー_ストレス` | L2 | METAR/Open-Meteo 気象リスク | | `test_energy_calibrated` | L3 |実際の飛行校正後のバッテリー/ETA の安全性 |論文のメインテーブルは L1 と L2 の両方に与えることができます。 L3 は校正分析表または付録として推奨されます。 L2 効果が安定している場合、サマリーは「リアル コンテキスト ベンチマーク」として記述できます。 L3 も安定している場合は、再度「実飛行校正評価」を書き込みます。 ### 8.1.7 実際のデータ取得のコードスケッチ エージェント ツールで UASFM と METAR ローダーを混在させないでください。まずオフライン データを準備します。 ```python def load_uasfm_cells(path: Path, bbox: BoundingBox) -> gpd.GeoDataFrame: cells = gpd.read_file(path) cells = cells.to_crs("EPSG:4326") clipped = cells[cells.geometry.intersects(bbox.to_polygon())].copy() keep = ["CEILING", "UNIT", "GLOBAL_ID", "APT1_ICAO", "AIRSPACE_1", "geometry"] return clipped[keep] def fetch_metar_snapshot(station_ids: list[str], hours: int) -> pd.DataFrame: response = requests.get( "https://aviationweather.gov/api/data/metar", params={"ids": ",".join(station_ids), "format": "json", "hours": hours}, timeout=30, ) response.raise_for_status() rows = response.json() return normalize_metar_rows(rows) ``` 実際の飛行校正ローダー: ```python def build_energy_calibration(flights: Iterable[FlightLog]) -> EnergyCalibrationTable: rows = [] for flight in flights: energy_j = integrate_power(flight.voltage_v, flight.current_a, flight.time_sec) path_length_m = trajectory_length(flight.position_xyz) rows.append( { "payload_g": flight.payload_g, "cruise_speed_mps": flight.programmed_speed_mps, "altitude_m": flight.programmed_altitude_m, "wind_bin": wind_bin(flight.wind_speed_mps), "energy_per_meter_j": energy_j / max(path_length_m, 1.0), } ) return EnergyCalibrationTable.from_rows(rows, quantile=0.9) ``` ### 8.1.8 都市とシーンのパラメータ 最初のバージョンでは、次の 4 種類の都市レイアウトを修正することをお勧めします。 |都市タイプ |グリッドサイズ | POIの特徴 |低地のリスク |使い方 | |----------|----------|----------|----------|------| | `グリッドシティ` | 50×50×6 |通常の道路網、均一な POI |低い |健全性チェック | | `ダウンタウンシティ` | 80×80×8 |建物密度が高く、病院/学校が集中している |高 |主な実験 | | `郊外都市` | 100×100×5 | POI がまばら、長距離 |中 |バッテリー/期限 | | `混合都市` | 120×120×10 |複合商業地、住宅地、交通結節点 |高 |目に見えない一般化 | 空間スケール:|パラメータ |デフォルト |範囲 | |------|------|------| |セルサイズ | 10メートル | 5~20メートル | |高度レイヤー | 6 | 3-12 | |最大高度 | 120メートル | 60~150メートル | |廊下の幅 | 20メートル | 10~40メートル | |飛行禁止区域 |マップごとに 3 ~ 12 | 0-20 | |デリケートゾーン |マップごとに 5 ~ 30 | 0-50 | |充電パッド |マップごとに 3 ~ 10 | 1-20 | | UAV 数 | 10 / 30 / 50 | 5-100 | タスクパラメータ: |パラメータ |デフォルト |説明 | |------|------|------| |締め切りが厳しい |中 |緩い / 中程度 / きつい / 不可能 | |優先配分 | 60/25/10/5 |ノーマル/ハイ/クリティカル/ロー調整可能 | |バッテリーの分布 |ベータ版のような |バッテリー低下のエッジケースを作成する | |気象リスク |なし/低/中/高 |増加するストレス分割媒体 | |デマンドバースト | 1x / 2x / 4x |テストコリドーとスケジューラ | ### 8.1.9 ルールテンプレート 最初のバージョンには 8 種類のルールしかなく、論文を書くのに十分な量であり、再現することができます。|ルール ID |自然言語 | LTL/STL/プログラムチェック | |----------|----------|---------------------| | R1 |一時的な飛行禁止区域に入らない | `G not_in_nfz` | | R2 |常に最小限の安全距離を維持してください。 STL の堅牢性: `dist_to_obstacle > d_min` | | R3 |高度は許容範囲内のままです | `G 最小高度 <= z <= 最大高度` | | R4 |締め切り前に到着 | `F[0, 期限] at_goal` | | R5 |返品/到着後のバッテリーの予備 |プログラムチェック | | R6 |廊下の収容人数は制限を超えません |容量モニター | | R7 |重要なタスクが優先されますが、安全性を上書きすることはできません。ポリシーチェック | | R8 |情報が不十分であるか、UNSAT の安全な拒否/人間による確認が行われた場合にトリガーされます。拒否チェック | ### 8.1.10 データ品質管理 CloudBrain-Bench は、「LLM で生成されたスパム タグ」を回避する必要があります。各サンプルに 4 種類の品質フィールドを記録することをお勧めします。 |フィールド |説明 | |------|------| | `世代シード` |実験を再現するためのランダム シード | | `ソース_来歴` | OSM/オーバーチュア/ルールテンプレート/プログラム生成ソース | | `ラベル検証者` | SAT/UNSAT ラベルはどのチェッカーからのものですか | | `ヒューマンレビューステータス` |未チェック / サンプル合格 / サンプル失敗 / 修正済み | 抜き取り検査戦略: - シナリオ タイプごとに少なくとも 30 個の項目をランダムにチェックします。 - 各故障モードについて少なくとも 20 項目をランダムにチェックします。 - ストレスおよび UNSAT サンプルのサンプリング率を 15% ~ 20% に増加します。 - 自然言語と説明のみが手動で変更され、プランナー/検証者タグは主観的なタグの導入を避けるために手動で変更されません。### 8.2 サンプル形式 各サンプルには次のものが含まれます。 ```json { "sample_id": "cb_000001", "data_tier": "real_context", "city_seed": 12, "scenario_type": "emergency_delivery_with_nfz", "instruction": "请优先派一架无人机把急救包送到 accident_site_3,避开学校和临时禁飞区,10 分钟内到达。", "source_provenance": { "map_sources": ["osm", "overture"], "airspace_sources": ["faa_uasfm"], "weather_sources": ["noaa_metar", "open_meteo"], "task_source": "deterministic_generator" }, "real_context": { "city_id": "pittsburgh_bbox_01", "uasfm_snapshot": "faa_uasfm_2026_05", "weather_snapshot": "metar_kpit_2026_05_20T12Z" }, "energy_calibration_version": "dji_m100_q90_v0", "state": { "uavs": "...", "airspace": "...", "map": "...", "tasks": "..." }, "gold_ir": "...", "gold_tool_trace": "...", "gold_decision": "...", "logic_specs": ["G not_in_nfz", "F[0,600] arrive_destination"], "label": "SAT", "failure_modes": [] } ``` ### 8.3 シーンの種類 |シーン |割合 |難易度 | |------|------|------| |通常配送 | 15% |通常のスケジューリングと経路計画 | |緊急配送 | 15% |優先順位、期限、リスクのトレードオフ | |巡回・点検 | 10% |複数のウェイポイントの時間的制約 | |飛行禁止区域の回避 | 15% | LTL/STL の安全制約 | |廊下の混雑 | 10% |空域容量と待ち時間 | |充電のボトルネック | 10% |電力制約とフォールバック | |天候/風のリスク | 10% |リスク評価と拒否 | |マルチモーダルフォールバック | 10% | UAV から地上への移動 | | UNSAT / 曖昧なタスク | 5% |安全な拒否と説明 | ### 8.4 データスケール 最初のバージョンの実現可能なスケール: |分割 |サンプル数 |目的 | |------|--------|------| |開発ミニ | 200 |クイック デバッグ パイプライン | |電車っぽい | 3000 |少数ショット、RAG、修復メモリ、メインのトレーニングには使用されません | |検証 | 1000 |プロンプト/モデルの選択 | |試しに見た都市 | 1000 |メインテスト | |テスト-まだ見ぬ都市 | 1000 |一般化 | |テストストレス | 1000 |危険現場ストレステスト | 合計で約 7,200 のサンプルがあり、最初のベンチマーク/メソッド ペーパーをサポートするには十分です。後続の G2 微調整は、50k ~ 100k のツール トレースに拡張されます。 ### 8.5 ゴールドラベルの生成ゴールドはすべて LLM によって生成されるべきではありません。推奨されるプロセス: 1. 都市、ミッション、UAV のステータス、およびルールを手順に従って生成します。 2. ルール テンプレートはゴールドの「LowAltitudeIR」を生成します。 3. 決定論的ツールを呼び出して、ゴールド ツール トレースを取得します。 4. プランナー/検証者/シミュレーターが SAT/UNSAT を決定します。 5. LLM 教師は、自然言語の言い換えと少量の説明テキストのみを担当します。 6. 高リスクサンプルと UNSAT サンプルに焦点を当て、手動検査のために 5% ~ 10% をサンプリングします。 ### 8.6 データファイルの構成 最終的なオープンソースまたは内部再現実験では、次の構造を使用することをお勧めします。 ```text data/cloudbrain_bench/ README.md schemas/ low_altitude_ir.schema.json tool_result.schema.json sample.schema.json raw/ osm/ overture/ uasfm/ aviation_weather/ weather/ uav_flight_calibration/ od_proxy/ processed/ city_states/ airspace_rules/ uasfm_cells/ weather_risk_tables/ energy_calibration_tables/ uav_states/ splits/ dev_mini.jsonl train_like.jsonl validation.jsonl test_seen_city.jsonl test_unseen_city.jsonl test_stress.jsonl test_real_context_city_a.jsonl test_real_context_city_b.jsonl test_real_weather_stress.jsonl test_energy_calibrated.jsonl test_unsat.jsonl gold/ gold_ir.jsonl gold_tool_traces.jsonl gold_verdicts.jsonl metadata/ split_stats.csv scenario_taxonomy.yaml data_sources.yaml ``` ### 8.7 統計は報告する必要があります 論文の表 2 には少なくとも次のことが報告されています。 |統計項目 |報告する必要があります | |----------|----------| |サンプルの総数 |合計 / 分割ごと | |シナリオ種類分布 | 9 カテゴリ シナリオ タイプ | | SAT/UNSAT 比 |全体 + シナリオごと | |都市の数 |見える/見えない | |データレベル | L1/L2/L3 サンプル数と割合 | |真のコンテキストフィールドのカバレッジ | OSM/Overture/UASFM/NOAA/Open-Meteo スナップショットの範囲 | | UAV 番号分布 |最小値 / 中央値 / 最大値 | |制約の数 |タスクごとの平均制約数 | |ツール呼び出しの長さ |ゴールドトレースの平均長 | |故障タイプの分布 | no_path/nfz/battery/期限/曖昧さ | |手動サンプリング率 |合格 / 修正済み | --- ## 9. モデルの選択と導入計画 ### 9.1 最初の記事では、最初に大規模な垂直モデルをトレーニングすることは推奨していません G1 の主なラインは、エージェント方式と検証クローズド ループです。垂直モデルのトレーニングは後続の G2 に配置されます。 G1 には軽量の SFT 事前実験を含めることができますが、それは論文の成否にとって重要ではありません。 ### 9.2 推奨モデルマトリックス|役割 |モデル |使い方 |必須 | |------|------|------|----------| |先生 / 上限 | GPT-5.2 または同等の API |データの生成、ベースラインの強化、エラー分析 |はい | |ローカルメインモデル |クウェン3-14B / クウェン3-32B |主な実験の再現可能なエージェント |はい | |ローカル推論モデル | DeepSeek-R1-蒸留-Qwen-14B/32B |修復、反例の推論 |はい | |低遅延モデル |クウェン3-8B |低遅延アブレーション |オプション | |埋め込み | Qwen3-エンベディング / BGE-M3 | RAG とセーフティメモリの検索 |はい | GPT-5.2 は、コーディングおよびエージェント タスクに適していると公式に位置づけられており、強力な教師およびクローズド ソースの上限として使用できます [10]。 Qwen3 技術レポートは、推論、指示に従って、エージェントおよび多言語機能を強調しており、ローカルのオープンソースのメイン モデルとして適しています [11]。 DeepSeek-R1 は、反例修復に適した Qwen/Llama に抽出された 14B/32B 推論モデルを提供します [12]。 ### 9.3 ローカルまたは API 推奨される **ハイブリッド アーキテクチャ**: |ステージ | API |ローカル | |------|-----|------| |第 1 ~ 2 週目 |クイック検証プロンプト、スキーマ、ツール設計 |同期展開 Qwen3-14B | |第 3 ~ 5 週目 |教師は言い換えや難しいサンプルを作成します |メイン実行開発/検証 | |第 6 ~ 8 週 |上限ベースラインを実行する |主な実験と再現可能な結果 | |提出前 |軽微なエラーの分析 |すべてのコア実験はローカルで再現可能です。この論文の主要な表では、ローカル モデルをメイン モデルとして使用し、API モデルを上限として使用することを推奨しています。これは強力な効果があるだけでなく、レビュアーが再現できるかどうか疑問を抱くのを避けることにもなります。 ### 9.4 高速処理の実装 導入に関する推奨事項: ```text vLLM server -> OpenAI-compatible endpoint -> Agent runtime -> Tool registry / MCP servers -> verifier / simulator ``` vLLM は、ローカルの Qwen/DeepSeek と API モデルが呼び出しインターフェイスを共有できるようにする OpenAI 互換サーバーを提供します [33]。 ### 9.5 プロンプトと推論の構成 再現性を確保するには、すべてのモデルに固定の推論パラメーターが必要です。 |目的 |温度 |トップページ |最大トークン |修理K |説明 | |------|---------------|----------|---------------|----------|------| |ダイレクトLLM | 0.2 | 0.9 | 2048年 | 0 |直接出力決定 | | JSON のみ | 0.0 | 1.0 | 2048年 | 0 |ランダム性を低減するための構造化された出力 | |反応する | 0.2 | 0.9 | 4096 | 0 |推論/アクションを許可する | | CloudBrain 修理不可 | 0.0 | 1.0 | 4096 | 0 |単一の IR + ツール | |クラウドブレインがいっぱい |最初は 0.0、修理は 0.2 | 1.0 | 4096 | 3 |修理ホイールはわずかに緩むことができます | プロンプトを 4 つのセクションに分割することをお勧めします。 1. **システムの役割**: あなたは低高度交通雲の頭脳エージェントであり、制御量を直接出力しません。 2. **IR スキーマ**: `LowAltitudeIR` JSON スキーマと列挙型を指定します。 3. **ツール レジストリ**: 利用可能なツール、入力と出力、および失敗のタイプをリストします。 4. **現在のタスク/状態**: 現在の自然言語タスク、UAV ステータス、地図、空域ルール、および履歴フィードバック。 出力形式は固定する必要があります。 ```json { "low_altitude_ir": {}, "rationale_summary": "one paragraph only", "uncertainty": { "needs_human_confirmation": false, "missing_information": [] } } ```モデルの出力を完全な思考連鎖のままにしないでください。論文やシステムでは、短い根拠の要約、ツールの軌跡、検証者のフィードバックのみが保存されます。 ### 9.6 API とローカルコストの記録 各実験を保存します。 |フィールド |説明 | |------|------| | `モデル名` | API またはローカル モデル名 | | `エンドポイントタイプ` | api/ローカル_vllm | | `プロンプト_トークン` |トークンを入力 | | `completion_tokens` |出力トークン | | `壁時間_秒` |エンドツーエンド時間 | | `llm_time_sec` | LLM 通話時間 | | `ツール時間_秒` |ツールの実行時間 | | `修理ラウンド` |修理ラウンド数 | | `推定コスト_米ドル` | API の推定コスト、ローカルには 0 または GPU 時間で埋めることができます。 これは、表 5 の展開分析をサポートします。 --- ## 10. ベースライン ### 10.1 メインベースライン|ベースライン |説明 |答えるべき質問 | |----------|------|--------------| |ダイレクトLLM |モデルは決定テキストを直接出力します。 LLM の裸の実行はどれほど信頼性が低いのか | | JSON のみの LLM | JSON IR の出力のみが必要で、実行ツールは不要 |入力された出力は十分ですか | | ReAct プロンプト | ReAct スタイルのツール呼び出し、スキーマ/ベリファイアなし |推論とアクションのループは十分ですか | |ツール使用のみ |ツール呼び出しはありますが、検証修復はありません |ツールは十分ですか | | BFCL スタイルの関数呼び出し |関数名とパラメータが正しいかどうかのみを評価し、物理的な検証は実行しません。関数呼び出しの成功がクラウド脳の成功と等しいかどうか | |タウベンチ スタイルのポリシー エージェント |ツールとポリシー ルールはありますが、UAV プランナー/検証者はありません。ドメイン ポリシーに従って十分ですか | | ToolSandbox スタイルのステートフル ツール エージェント |ステートフル ツールの実行と情報不足の処理 |ステートフル ツール実行の低高度タスクへの貢献 | | LLM+P スタイル | LLM は計画問題に変換され、プランナーがそれを解決します。外部プランナーはどこまで解決できるのか | | TrafficGPT スタイル | LLM は車両を呼び出すが、UAV は正式な安全性を持たない |トラフィック LLM オーケストレーション ベースライン | | CloudBrain-Agent (シミュレータなし) |シミュレーション ストレス テストを削除 |シミュレータのフィードバックへの貢献 | | CloudBrain-Agent 修理なし |失敗時に停止 |修復ループの貢献 | | CloudBrain-Agent フル |完全な方法 |この記事の主な方法 | ### 10.2 モデルのベースライン|モデル |設定 | |------|------| | GPT-5.2 | API の上限 | |クウェン3-14B |ローカルメイン | |クウェン3-32B |地元の強い | | DeepSeek-R1-蒸留-Qwen-14B |ローカル修復の推論 | |クウェン3-8B |小さな地元 | ### 10.3 ベースライン実装の詳細 ベースラインがレビュー担当者によって不公平であるとみなされるのを避けるために、各ベースラインには明確に権限を入力する必要があります。 |ベースライン |目に見える自然言語 |表示ステータス |呼び出し可能なツール |検証者のフィードバックを可視化 |修理可能 | |----------|--------------|----------|---------------|------------------------|----------| |ダイレクトLLM |はい |概要ステータス |いいえ |いいえ |いいえ | | JSON のみ |はい |フルステータス |いいえ |いいえ |いいえ | |反応する |はい |完了ステータス |はい |反例のないツールエラー |いいえ | |ツール使用のみ |はい |フルステータス |はい |ツールエラー |いいえ | | LLM+P スタイル |はい |完了ステータス |プランナー |プランナー結果 |いいえ | | CloudBrain 検証機能なし |はい |完全なステータス |はい |いいえ |いいえ | |シミュレーターなしの CloudBrain |はい |完全なステータス |はい |検証者のみ |はい | |クラウドブレインがいっぱい |はい |完全なステータス |はい |検証者 + シミュレーター |はい | 公平性の原則:- すべてのメソッドは同じ基本モデルを使用します。 - すべてのメソッドに同じテスト分割を使用します。 - すべてのメソッドの最大トークン バジェットは同じです。 - ReAct と CloudBrain のツール呼び出しの最大数は同じです。 - これはこの記事の寄稿であるため、CloudBrain のみが構造化反例を完全に使用しています。 --- ## 11. 実験計画 ### 11.1 実験 1: 主な結果 質問: CloudBrain-Agent 完全版は、直接 LLM、ReAct、ツール使用のみ、および LLM+P よりも優れていますか? データ: テストされた都市、テストされた未見の都市、テストされたストレス。 指標: -タスクの成功率 ・実行可能決定率 - 安全違反率 -ツール呼び出しの精度 - 幻覚率 - 修理成功率 -レイテンシー ### 11.2 実験 2: アブレーション実験 |アブレーション |コンテンツの削除 |予想される影響 | |----------|----------|----------| |型指定された IR はありません |無料のテキストツール呼び出し |ツール呼び出しの精度が低下 | |検証者なし | LTL/STL チェックなし |安全違反が増加 | |シミュレーターなし |ノーシーンストレステスト |ストレスパスの減少 | |修理なし |検証失敗後は反復なし |実行可能レートの減少 | |記憶がない |過去の失敗事例を取得しない |修復の成功率が低下しました。 |ラグなし |ルール/マップ コンテキストを取得しない |幻覚の増加 | ### 11.3 実験 3: 反例修復解析 統計検証器/シミュレータ障害後の修復パス:- 初回修理成功率 - 2回目の修理成功率 - 3回目の修理成功率 - 修理後の新規違反率 - 最も一般的な障害の種類: NFZ、デッドライン、バッテリー、廊下、エンティティの幻覚 ### 11.4 実験 4: モデルと展開の分析 API をネイティブ モデルと比較します。 |モデル |指標 | |------|------| | GPT-5.2 |キャップ効果、コスト、遅延 | |クウェン3-14B |ローカルで再現可能な主な結果 | |クウェン3-32B |ローカル強力モデル | | DeepSeek-R1-蒸留-Qwen-14B |特殊能力を修復する | |クウェン3-8B |低遅延のトレードオフ | ### 11.5 実験 5: 一般化 一般化の次元: - 目に見えない都市のレイアウト - 見たことのないPOI名 - 目に見えない飛行禁止区域の形状 - 見たことのないツールの組み合わせ - 目に見えない緊急事態 -より高いUAV密度 -需要の高まりによるショック ### 11.6 実験 6: 人間とマシンのコラボレーションの安全な拒否 UNSAT または不十分な情報が利用可能な場合に、モデルが実行を拒否できるか、人間の確認を要求できるかどうかをテストします。 例: - 締め切り不可 - すべての UAV バッテリーが不足しています - NFZ内の目的地 - 目的地がありません - 優先順位と安全ルールの間の矛盾 ### 11.7 実験 7: エージェントの信頼性とマルチラウンドの一貫性 $\tau$-bench の `pass^k` アイデアを参照して、同じタスクを $k$ 回繰り返し実行して、エージェントが安定してタスクを完了できるかどうかを評価します [36]。低空での交通ミッションでは、1 回成功してもランダムに複数回失敗するだけでは十分安全ではないため、次のことを報告することをお勧めします。|インジケーター |意味 | |------|------| | `パス@1` |単一実行の成功率 | | `パス^3` |同じタスクを連続 3 回成功した割合 | | `パス^5` |同じタスクが 5 回連続して成功する割合 | |ポリシーの遵守 |空域・保安・マニュアル確認ルール遵守の有無 | |状態の一貫性 |内部状態が、複数ラウンドのツール呼び出し後のツールの戻り値と一致しているかどうか。 |情報不足への対応 |幻覚補完ではなく、情報が不十分な場合に明確化/拒否するか | この部分により、G1 は単なる「トラフィック アプリケーション」ではなく、一般的なエージェントの信頼性への譲渡可能な貢献になります。 ### 11.8 実験 8: タスクの難易度の階層化 主要な結果が単純なサンプルによって曖昧になることを避けるために、レポートは難易度によって階層化されています。 |難易度 |定義 |サンプルの特性 | |------|------|----------| |簡単 |単一タスク、NFZ なし、期限は緩い |通常配送 | |中 | 1-2 の安全制約、通常の電力 | NFZ またはバッテリーの単一要因 | |ハード |複数の制約、厳しい締め切り、廊下の混雑 |緊急 + NFZ + 充電 | |エクストリーム |高リスクまたは UNSAT に近い |ストレス分割 | | UNSAT |実現可能な安全ソリューションがない |安全な拒否 / 人間の確認 | メインの表では全体的なレポートが表示され、付録では難易度ごとのレポートが表示されます。 CloudBrain の利点は、ハード/エクストリーム/UNSAT で最大になると予想されます。 ### 11.9 実験 9: 誤った分布 失敗した各サンプルは、最初の失敗段階に自動的に分類されます。|ステージ |エラーの種類 | |------|----------| | IR |無効な JSON、スキーマが欠落、間違った列挙型 | |接地 |存在しないエンティティ、間違ったゾーン、間違った UAV | |ツール |間違ったツール、間違った順序、無効な引数 | |企画 |道がありません、間違った UAV、バッテリーがありません | |検証 | NFZ、高度、距離、期限、容量 | |シミュレーション |衝突、ニアミス、天候リスク、遅延 | |ポリシー |安全でないオーバーライド、人間による確認の欠落、間違った拒否 | |説明 |幻覚の理由、裏付けのない主張 | エラー分析図 (さまざまなベースラインの故障段階の分布) には積み上げ棒を使用することをお勧めします。これにより、CloudBrain が修正した内容が明確に説明できます。 --- ## 12. 評価指標の定義 ### 12.1 構造化された出力インジケーター **IR 完全一致**:

\text{IR-EM} = \frac{1}{N}\sum_i \mathbb{1}[z_i = z_i^*]

You can't use 'macro parameter character #' in math mode **IR フィールド F1**: インテント、エンティティ、制約、ツール プランなどのフィールドの精度、再現率、F1 をそれぞれ計算します。 ### 12.2 ツール呼び出しインジケーター **ツール呼び出し精度**:

\text{TCA} = \frac{#\text{正しいツール呼び出し}}{#\text{すべてのツール呼び出し}}

\text{TDS} = \frac{#\text{すべてのデータ依存関係を満たすツール チェーン}}{#\text{ツール チェーン}}

You can't use 'macro parameter character #' in math mode これは、エージェントが下流のツールに依存するのではなく、最初に空域/都市のステータスをクエリし、次に計画を立てて検証するかどうかを測定します。 ### 12.3 実行可能性の指標 **実行可能決定率**:

\text{EDR} = \frac{#\text{プランナーの実行可能決定}}{N}

\text{TSR} = \frac{#\text{完全に検証され、成功したタスクをシミュレート}}{N}

You can't use 'macro parameter character #' in math mode ### 12.4 セキュリティ指標 **安全違反率**:

\text{SVR} = \frac{#\text{安全違反のタスク}}{N}

You can't use 'macro parameter character #' in math mode 違反の種類には次のものがあります。 - 飛行禁止区域への侵入; - 高度違反。 - 最小分離違反。 - バッテリーリザーブ違反。 - 期限違反。 - 安全でないフォールバック。 - 幻覚の許可。 低空輸送の拡張版では、さらなる安全指標を輸送することが推奨されています。|指標 |定義 |目的 | |------|------|------| | LoWC プロキシ |いつでも明確な分離率以下。分離喪失のリスクの測定 | | NMAC プロキシ |近空中衝突のしきい値を下回った回数 |重度のニア・ミッド・リスクの尺度 | |リスク比率 |ルールベースの安全なベースラインに対するリスク イベントの割合 |さまざまなシナリオを比較できるようにする | |安全拒否の精度 |本当に安全に実行できない拒否/手動確認要求の割合 |エージェントが過度に保守的になるのを防ぐ | AAAI/IJCAI の本文では、SVR と違反タイプの内訳のみを報告できます。 T-ITS 拡張機能は、LoWC/NMAC プロキシとリスク比を報告する必要があります。 ### 12.5 幻覚インジケーター **幻覚率**:

\text{HR} = \frac{#\text{存在しないエンティティ/ツール/ルールを含む出力}}{N}

You can't use 'macro parameter character #' in math mode ### 12.6 修復インジケーター **修理成功率**:

\text{RSR} = \frac{#\text{最初の試行の失敗は K 回の反復内で修復されました}}{#\text{最初の試行の失敗}}

\text{パス}^k = \frac{#\text{すべての } k \text{ の繰り返し実行で成功したタスク}}{N}

You can't use 'macro parameter character #' in math mode このメトリクスは、安全性が重要なエージェントには「pass@1」よりも適しています。これは、低高度の交通雲の頭脳は、時々成功するよりも安定したルールへの準拠を必要とするためです[36]。 ### 12.7 統計的検定 実験ごとに少なくとも 3 つのランダム シード。主な結果レポート:- 平均±標準誤差。 -ペアのブートストラップ 95% 信頼区間。 - マクネマー テストまたはブートストラップ テストは、成功/失敗の指標を比較します。 - 待ち時間の中央値、p90、p95 をレポートします。 ### 12.8 メイン結果テーブルのテンプレート 用紙 表 3 は、次の形式で直接入力できます。 |方法 |モデル | TSR ↑ | EDR ↑ | SVR ↓ | HR ↓ | TCA ↑ | RSR ↑ |パス^3 ↑ | p95 レイテンシ ↓ | |----------|----------|----------|------|----------|------|----------|----------|----------|------| |ダイレクトLLM |クウェン3-14B | - | - | - | - |該当なし |該当なし | - | - | | JSON のみ |クウェン3-14B | - | - | - | - |該当なし |該当なし | - | - | |反応する |クウェン3-14B | - | - | - | - | - |該当なし | - | - | |ツール使用のみ |クウェン3-14B | - | - | - | - | - |該当なし | - | - | | LLM+P |クウェン3-14B | - | - | - | - | - |該当なし | - | - | | CloudBrain 修理なし |クウェン3-14B | - | - | - | - | - |該当なし | - | - | |クラウドブレインがいっぱい |クウェン3-14B | - | - | - | - | - | - | - | - | ### 12.9 アブレーションテーブルテンプレート|バリアント | TSR ↑ | EDR ↑ | SVR ↓ | TCA ↑ | RSR ↑ |主な説明 | |----------|----------|----------|----------|----------|----------|----------| |フル | - | - | - | - | - |完全なメソッド | |型指定された IR はありません | - | - | - | - | - |構造化インターフェイスをテストする | |検証者なし | - | - | - | - | - |正式な検証をテストする | |シミュレーターなし | - | - | - | - | - |圧力測定フィードバック | |修理なし | - | - | - | - |該当なし |テスト反例の修復 | |記憶がない | - | - | - | - | - |テスト失敗事例の検索 | |ラグなし | - | - | - | - | - |テストルール/マップコンテキスト | ### 12.10 最小成功しきい値 論文執筆に入る前に、少なくとも次の基準を満たすことをお勧めします。 |指標 |最小しきい値 |理由 | |------|----------|------| | CloudBrain フル TSR | ReAct | よりも 10 パーセント以上高いメソッドマスター収入 | | SVR | Direct LLM より 30% 以上低い |セキュリティ上の重要な価値 | | TCA | 85%以上 |信頼性の高いツール呼び出し | | RSR | 40%以上 |反例修復が有効 | |パス^3 |ツールのみの使用よりも大幅に高い |マルチラウンドの安定性 | | p95 レイテンシ |ローカル 14B 60 秒未満 |展開可能な物語 | --- ## 13. 予想される実験結果 以下は事前登録の予想であり、実験結果ではありません。1. CloudBrain-Agent フルは、タスクの成功率、実行可能決定率、安全性違反率において、直接 LLM、ReAct、およびツールのみの使用よりも優れていると予想されます。 2. `LowAltitudeIR` と入力すると、主にツール呼び出しの精度、IR フィールド F1、幻覚率が改善されることが期待されます。 3. 検証者のフィードバックは、主に実行可能決定率と修復成功率を向上させることが期待されます。 4. ストレス シナリオ、特に廊下の混雑、風のリスク、NFZ のエッジ ケースでは、シミュレーターのフィードバックが最も重要であることが予想されます。 5. ローカル Qwen3-14B/32B は再現可能なマスター モデルとして機能すると予想されますが、GPT-5.2 はまだ上限にあります。 6. DeepSeek-R1-Distill-Qwen は、反例修復において通常の命令モデルよりも優れたパフォーマンスを発揮すると予想されます。 --- ## 14. チャート計画| ID |タイプ |コンテンツ |優先順位 | |----|------|------|----------| |図1 |アーキテクチャ図 | CloudBrain-Agent の指示から検証された決定までの閉ループ |高 | |図2 |データ生成フローチャート | OSM/FAA/OD/SUMO/シミュレータからCloudBrain-Benchへ |高 | |図3 |主な結果のヒストグラム | TSR、EDR、SVR、HRの比較 |高 | |図4 |修復曲線 |修復反復 1 ~ 3 の成功率の向上 |高 | |図5 |一般化ヒート マップ |見える/見えない都市、ストレス、UNSAT に関するパフォーマンス |中 | |図6 |エージェントの一貫性曲線 | `pass@1`、`pass^3`、`pass^5` および状態の一貫性 |中 | |表 1 |関連作品の比較 | LLM トラフィック、ツールの使用、計画、正式な検証、この記事 |高 | |表 2 |データセット統計 |シナリオ タイプ、SAT/UNSAT、都市、タスクの数 |高 | |表 3 |ベースラインの主な結果 |すべての指標の比較 |高 | |表 4 |アブレーション |コンポーネントの取り外し後のパフォーマンスの変化 |高 | |表 5 |モデルの展開 | API とローカルの効果、レイテンシ、コスト |中 | |表6 |データソースの再現性 |各タイプのデータの URL、ライセンス、主な実験がそれに依存するかどうか、フォールバック |中 | --- ##15. 紙の構造計画 AAAI/IJCAI の 7 ~ 8 ページの本文を圧縮したもの: ### 要約 150~200単語。低空の交通安全の鍵、LLM の信頼性の低さ、CloudBrain-Agent、ベンチマーク、および主要な結果を強調します。 ### 1 はじめに 内容:- 低高度の交通雲の背景。 - LLM による直接意思決定のリスク。 - ツールの呼び出しと検証の閉ループの必要性。 - この記事の 3 つの寄稿。 - 図1 ヒーローの図。 ### 2 関連作品 3 つの段落: 1. 輸送および時空間インテリジェンスのための LLM。 2. LLM エージェント、ツールの使用、および計画。 3. 正式な検証と UAV/UTM シミュレーション。 ### 3 問題の設定 状態、タスク、「LowAltitudeIR」、ツール、成功条件、セキュリティ制約を定義します。 ### 4 方法 CloudBrain-Agent の紹介: - コンテキストビルダー; - LowAltitudeIR パーサー; - ツールルーター; - 検証者/シミュレーター; - ループを修復します。 - 安全メモリ。 ### 5 クラウドブレインベンチ データ ソース、生成プロセス、シナリオ タイプ、分割、ゴールド ラベル、再現性について紹介します。 ### 6 実験 主な結果、アブレーション、修復解析、一般化、モデル展開。 ### 7 結論 貢献を要約し、制限について正直に書きます。合成ベンチマーク、実際の空域展開は検証されておらず、人間による関与が依然として必要です。 --- ## 16. 導入ルート ### 16.1 最低限実行可能なシステム これらは最初の 1 か月間のみ実行してください。 ```text cloudbrain/ ir/schema.py tools/city.py tools/airspace.py tools/scheduler.py tools/planner.py tools/verifier.py tools/simulator.py agent/runner.py data/generator.py eval/metrics.py ``` ### 16.2 推奨されるテクノロジースタック|モジュール |テクノロジー | |------|------| |エージェントランタイム | Python + Pydantic + LiteLLM/OpenAI クライアント | |ローカルモデル | vLLM OpenAI互換サーバー | |ツールプロトコル |最初に Python 関数、2 番目に MCP ラッパー | | IR検証 | Pydantic JSON スキーマ | |プランナー | 3D A* が最初、RRT* はオプション | |検証者 | LTL 用スポット、STL 用 RTAMT | |シミュレーター |軽量グリッド/コリドーシミュレータ | |ラグ | Qdrant/FAISS + Qwen3-Embedding/BGE-M3 | |ストレージ | JSONL + 寄木細工 + DuckDB | |評価 |パンダ + scipy + ブートストラップ | ### 16.2.1 コードモジュールインターフェース 各モジュールが最小限のインターフェイスを公開することをお勧めします。 ```python class LowAltitudeIR(BaseModel): task_id: str intent: Literal["delivery", "inspection", "patrol", "emergency", "return", "charge", "monitoring"] priority: Literal["low", "normal", "high", "critical"] entities: dict constraints: dict tool_plan: list[dict] verification_specs: dict fallback_policy: str class ToolResult(BaseModel): ok: bool tool: str request_id: str result: dict | None warnings: list[str] error: dict | None provenance: dict ``` ランナーの主な機能: ```python def run_agent(sample: dict, model: str, config: AgentConfig) -> AgentTrace: ... ``` 評価の主な機能: ```python def evaluate_trace(sample: dict, trace: AgentTrace) -> dict: return { "task_success": ..., "executable_decision": ..., "safety_violation": ..., "tool_call_accuracy": ..., "hallucination": ..., "repair_success": ..., "latency_sec": ..., } ``` ### 16.2.2 実験的なコマンド設計 今後の実装後に次のコマンドを使用して問題を再現できるようにすることをお勧めします。 ```bash python -m cloudbrain.data.generate --config configs/data/dev_mini.yaml python -m cloudbrain.eval.run --split dev_mini --method direct_llm --model qwen3-14b python -m cloudbrain.eval.run --split dev_mini --method react --model qwen3-14b python -m cloudbrain.eval.run --split dev_mini --method cloudbrain_full --model qwen3-14b python -m cloudbrain.eval.aggregate --runs runs/dev_mini --out results/dev_mini.csv python -m cloudbrain.figures.make_all --results results/main.csv --out figures/ ``` ### 16.2.3 設定ファイルのテンプレート ```yaml experiment: name: cloudbrain_main_qwen3_14b seed: 42 split: test_seen_city max_repair_rounds: 3 model: provider: local_vllm name: qwen3-14b temperature: 0.0 top_p: 1.0 max_tokens: 4096 tools: enable_city: true enable_airspace: true enable_scheduler: true enable_planner: true enable_verifier: true enable_simulator: true enable_risk: true evaluation: bootstrap_samples: 1000 report_pass_k: [1, 3, 5] latency_percentiles: [50, 90, 95] ``` ### 16.3 10週間の実行計画|週 |目標 |成果物 | |----|------|--------| | 1 |フリーズ問題の定式化と IR スキーマ | `LowAltitudeIR v0.1` | | 2 |都市/空域/UAV/タスクジェネレーターを実装 | 200 の開発サンプル | | 3 |プランナー/検証者/シミュレーターの実装 |決定的なゴールドラベル | | 4 |エージェント ランナーと Direct/ReAct ベースラインを実装する | dev-mini の結果 | | 5 | CloudBrain-Bench を 3000 以上に拡張 |検証分割 | | 6 |ローカル Qwen3-14B および GPT-5.2 上限を実行します。主要ベースラインテーブル草案 | | 7 |修復ループ、メモリ、アブレーションの実装 |アブレーション結果 | | 8 |見えないところで走る/ストレス/UNSAT |一般化図 | | 9 |統計的テスト、エラー分析、グラフ |カメラ対応フィギュアのドラフト | | 10 | AAAI/IJCAI の最初の草稿を書く |フルペーパードラフト | ### 16.4 毎週の合格基準|週 |実行する必要があるコマンド |合格基準 | |----|----------------|----------| | 1 |スキーマ検証スクリプト | 20 件の手書き IR はすべて正しく検証されました | | 2 |データジェネレーター | 200 個のサンプルが生成され、分割統計は空のフィールドなし | | 3 |ツール単体テスト |プランナー/検証者/シミュレーター少なくとも 30 個の単体テスト | | 4 | dev-mini ベースライン | direct/ReAct/CloudBrain 修復は実行されません | | 5 |検証分割 | 3000 以上のサンプル、ゴールド ラベルの生成が完了 | | 6 |モデルマトリックス | Qwen3-14B と GPT 上限の結果が得られました | | 7 |アブレーション | IR なし / ベリファイアなし / 修復なし / シミュレータ実行可能ファイルなし | | 8 |ストレス/UNSAT |ストレスと安全な拒否の指標を計算できます | | 9 |数字 | 6 つの図と 6 つの表が自動的に生成されたドラフト | | 10 |紙のドラフト |本文は完全で、付録にはスキーマとデータの説明が含まれています。 ### 16.5 推奨コード ディレクトリ v1 コード ベースの最初のバージョンは、最初から大規模なプラットフォームにするのではなく、小さく明確に保ち、最初に論文の実験に使用することをお勧めします。 ```text cloudbrain-agent/ pyproject.toml README.md configs/ data/ dev_mini.yaml main_bench.yaml experiments/ direct_llm.yaml react.yaml cloudbrain_full.yaml ablation_no_verifier.yaml models/ local_qwen3_14b.yaml api_gpt52.yaml data/ cloudbrain_bench/ schemas/ splits/ gold/ metadata/ src/ cloudbrain/ __init__.py ir/ schema.py validators.py errors.py state/ city_state.py airspace_state.py uav_state.py task_state.py tools/ base.py registry.py city.py airspace.py scheduler.py planner.py verifier.py simulator.py risk.py agent/ prompts.py llm_client.py runner.py repair.py memory.py traces.py data/ generator.py osm_loader.py overture_loader.py weather_loader.py split.py quality.py eval/ run.py metrics.py aggregate.py bootstrap.py error_analysis.py figures/ main_results.py ablations.py repair_curve.py utils/ io.py geometry.py hashing.py timing.py tests/ test_ir_schema.py test_tool_registry.py test_planner.py test_verifier.py test_metrics.py ``` ### 16.6 Pydantic スキーマ コードの詳細 `LowAltitudeIR` は強力な型制約を使用し、LLM 出力後およびツール実行前にエラーをブロックするように試行する必要があります。 ```python from __future__ import annotations from enum import Enum from typing import Literal from pydantic import BaseModel, Field, field_validator, model_validator class Intent(str, Enum): delivery = "delivery" inspection = "inspection" patrol = "patrol" emergency = "emergency" return_home = "return" charge = "charge" monitoring = "monitoring" class Priority(str, Enum): low = "low" normal = "normal" high = "high" critical = "critical" class EntityRefs(BaseModel): origin: str | None = None destination: str | None = None candidate_uavs: list[str] = Field(default_factory=list) avoid_zones: list[str] = Field(default_factory=list) sensitive_zones: list[str] = Field(default_factory=list) handoff_points: list[str] = Field(default_factory=list) class OperationConstraints(BaseModel): deadline_sec: int | None = Field(default=None, ge=1) altitude_min_m: float = Field(default=30.0, ge=0) altitude_max_m: float = Field(default=120.0, ge=0) min_separation_m: float = Field(default=10.0, ge=0) battery_reserve_ratio: float = Field(default=0.2, ge=0, le=1) max_risk_level: Literal["low", "medium", "high"] = "medium" corridor_capacity_required: int = Field(default=1, ge=1) @model_validator(mode="after") def check_altitude_range(self) -> "OperationConstraints": if self.altitude_min_m >= self.altitude_max_m: raise ValueError("altitude_min_m must be lower than altitude_max_m") return self class ToolCallSpec(BaseModel): tool: str args: dict = Field(default_factory=dict) depends_on: list[str] = Field(default_factory=list) class VerificationSpecs(BaseModel): ltl: list[str] = Field(default_factory=list) stl: list[str] = Field(default_factory=list) program_rules: list[str] = Field(default_factory=list) class LowAltitudeIR(BaseModel): task_id: str intent: Intent priority: Priority entities: EntityRefs constraints: OperationConstraints tool_plan: list[ToolCallSpec] verification_specs: VerificationSpecs fallback_policy: Literal[ "ground_transfer", "wait", "human_confirm", "safe_refusal", "ground_transfer_or_human_confirm", ] explanation_plan: dict = Field(default_factory=dict) @field_validator("tool_plan") @classmethod def check_nonempty_tool_plan(cls, value: list[ToolCallSpec]) -> list[ToolCallSpec]: if not value: raise ValueError("tool_plan must contain at least one tool call") return value ``` エンティティのグラウンディングは、現在のマップと UAV の状態に依存するため、Pydantic で記述する必要はなく、個別に行う必要があります。 ```python def validate_entity_grounding(ir: LowAltitudeIR, state: SystemState) -> ValidationReport: errors: list[ValidationErrorItem] = [] known_entities = state.known_entity_ids() known_uavs = state.known_uav_ids() for field_name in ["origin", "destination"]: value = getattr(ir.entities, field_name) if value is not None and value not in known_entities: errors.append( ValidationErrorItem( stage="entity_grounding", field=f"entities.{field_name}", value=value, error_type="unknown_entity", ) ) for uav_id in ir.entities.candidate_uavs: if uav_id not in known_uavs: errors.append( ValidationErrorItem( stage="entity_grounding", field="entities.candidate_uavs", value=uav_id, error_type="unknown_uav", ) ) return ValidationReport(valid=not errors, errors=errors) ``` ### 16.7 ToolRegistry コードの詳細すべてのツールは同じインターフェイスを実装しているため、決定的 / 学習済み / 外部 MCP バージョンを簡単に置き換えることができます。 ```python from abc import ABC, abstractmethod from dataclasses import dataclass from time import perf_counter from typing import Any class ToolErrorType(str, Enum): unknown_region = "unknown_region" restricted_airspace = "restricted_airspace" no_available_uav = "no_available_uav" no_path = "no_path" spec_violation = "spec_violation" sim_failure = "sim_failure" high_risk = "high_risk" invalid_arguments = "invalid_arguments" class ToolError(BaseModel): type: ToolErrorType | str message: str recoverable: bool = True suggested_actions: list[str] = Field(default_factory=list) class ToolResult(BaseModel): ok: bool tool: str request_id: str result: dict[str, Any] | None = None warnings: list[str] = Field(default_factory=list) error: ToolError | None = None provenance: dict[str, Any] = Field(default_factory=dict) latency_sec: float = 0.0 class BaseTool(ABC): name: str @abstractmethod def run(self, args: dict[str, Any], context: ToolContext) -> ToolResult: ... class ToolRegistry: def __init__(self) -> None: self._tools: dict[str, BaseTool] = {} def register(self, tool: BaseTool) -> None: if tool.name in self._tools: raise ValueError(f"duplicate tool: {tool.name}") self._tools[tool.name] = tool def execute(self, call: ToolCallSpec, context: ToolContext) -> ToolResult: start = perf_counter() if call.tool not in self._tools: return ToolResult( ok=False, tool=call.tool, request_id=context.next_request_id(call.tool), error=ToolError( type="unknown_tool", message=f"Tool {call.tool} is not registered.", recoverable=True, suggested_actions=["choose a registered tool"], ), ) result = self._tools[call.tool].run(call.args, context) result.latency_sec = perf_counter() - start return result ``` ### 16.8 プランナーとシミュレーターの最小限のコード設計 3D A* の最初のバージョンでは、グリッド、NFZ マスク、高度範囲、バッテリー/長さの推定のみをサポートする必要があります。 ```python def plan_route_astar( grid: Grid3D, start: GridNode, goal: GridNode, avoid_mask: set[GridNode], altitude_min_layer: int, altitude_max_layer: int, ) -> RoutePlan: open_set = PriorityQueue() open_set.put((0.0, start)) came_from: dict[GridNode, GridNode] = {} g_score = {start: 0.0} while not open_set.empty(): _, current = open_set.get() if current == goal: return reconstruct_route(came_from, current) for nxt in grid.neighbors_26(current): if nxt in avoid_mask: continue if not altitude_min_layer <= nxt.z <= altitude_max_layer: continue tentative = g_score[current] + grid.edge_cost(current, nxt) if tentative < g_score.get(nxt, float("inf")): came_from[nxt] = current g_score[nxt] = tentative priority = tentative + euclidean_distance(nxt, goal) open_set.put((priority, nxt)) return RoutePlan(ok=False, failure_type="no_path") ``` 軽量シミュレーターは離散時間で進めることができます。 ```python def simulate_route( route: RoutePlan, scenario: ScenarioState, dt_sec: float = 1.0, ) -> SimulationResult: events: list[SimEvent] = [] min_distance = float("inf") elapsed = 0.0 for segment in route.segments: for pose in interpolate_segment(segment, dt_sec): elapsed += dt_sec distance = scenario.min_distance_to_obstacles(pose) min_distance = min(min_distance, distance) if scenario.inside_no_fly_zone(pose): events.append(SimEvent(time=elapsed, type="nfz_intrusion", pose=pose)) if distance < scenario.min_separation_m: events.append(SimEvent(time=elapsed, type="separation_violation", pose=pose)) if scenario.weather_risk_at(pose, elapsed) == "high": events.append(SimEvent(time=elapsed, type="weather_risk", pose=pose)) return SimulationResult( success=not any(e.is_terminal for e in events), events=events, min_distance_m=min_distance, elapsed_sec=elapsed, ) ``` ### 16.9 検証ツールの最小限のコード設計 最初のバージョンでは、LTL/STL を 2 つの層に分割できます。共通ルールはプログラム チェッカーによって保証されて安定性が確保され、複雑な式は Spot/RTAMT に渡されます。 ```python def verify_common_rules( trajectory: Trajectory, specs: VerificationSpecs, scenario: ScenarioState, ) -> VerificationResult: violations: list[Violation] = [] if "G not_in_nfz" in specs.ltl: for t, pose in trajectory.iter_poses(): if scenario.inside_no_fly_zone(pose): violations.append( Violation( rule="G not_in_nfz", time_sec=t, failure_type="nfz_intrusion", recoverable=True, ) ) for stl_spec in specs.stl: if stl_spec.startswith("distance_to_obstacle"): robustness = min( scenario.distance_to_nearest_obstacle(pose) - scenario.min_separation_m for _, pose in trajectory.iter_poses() ) if robustness < 0: violations.append( Violation( rule=stl_spec, time_sec=trajectory.time_of_min_distance(scenario), failure_type="negative_robustness", robustness=robustness, recoverable=True, ) ) return VerificationResult(pass_=not violations, violations=violations) ``` 反例の圧縮は短くする必要があり、トラック全体をプロンプトに戻さないでください。 ```python def compress_counterexample(verdict: VerificationResult) -> dict: first = next(iter(verdict.violations)) return { "failure_type": first.failure_type, "violated_rule": first.rule, "time_sec": first.time_sec, "robustness": first.robustness, "suggested_repair": suggest_repair(first), } ``` ### 16.10 エージェント ランナー コードの詳細 `run_agent` は、再現可能な実験とエラー分析を容易にするために、トレースを完全に保存する必要があります。 ```python def run_agent(sample: Sample, model: ChatModel, tools: ToolRegistry, cfg: AgentConfig) -> AgentTrace: trace = AgentTrace(sample_id=sample.sample_id, method=cfg.method, model=model.name) context = build_context(sample, cfg) feedback: dict | None = None for repair_round in range(cfg.max_repair_rounds + 1): llm_output = model.generate( messages=build_messages(sample.instruction, context, feedback), temperature=cfg.temperature_for_round(repair_round), max_tokens=cfg.max_tokens, ) trace.add_llm_call(llm_output, repair_round=repair_round) parse_report = parse_low_altitude_ir(llm_output.text) if not parse_report.ok: feedback = {"stage": "parse", "errors": parse_report.errors} trace.add_validation_failure(feedback) continue ir = parse_report.ir validation = validate_ir_all(ir, sample.state, tools) if not validation.valid: feedback = {"stage": "validation", "errors": validation.to_prompt_feedback()} trace.add_validation_failure(feedback) continue tool_trace = execute_tool_plan(ir, tools, sample.state) trace.add_tool_trace(tool_trace) if tool_trace.has_unrecoverable_error: trace.final_status = "safe_refusal" trace.final_reason = tool_trace.first_unrecoverable_error.type return trace verdict = verify_and_simulate(ir, tool_trace, sample.state) trace.add_verdict(verdict) if verdict.pass_: trace.final_status = "success" trace.final_decision = build_final_decision(ir, tool_trace, verdict) return trace feedback = compress_counterexample(verdict) trace.final_status = "human_confirm_or_safe_refusal" trace.final_reason = "max_repair_rounds_exceeded" return trace ``` トレース JSONL 各行を保存することをお勧めします。 ```json { "sample_id": "cb_000001", "method": "cloudbrain_full", "model": "qwen3-14b", "final_status": "success", "repair_rounds": 1, "llm_calls": [], "tool_calls": [], "validation_errors": [], "verifier_verdicts": [], "latency": { "total_sec": 18.4, "llm_sec": 13.2, "tool_sec": 4.1 } } ``` ### 16.11 評価コードの詳細 手動による主観的な判断を避けるために、メトリクスはトレースとゴールドから自動的に計算される必要があります。 ```python def compute_tool_call_accuracy(gold: list[ToolCallSpec], pred: list[ToolCallRecord]) -> float: if not gold: return 1.0 if not pred else 0.0 matched = 0 for gold_call, pred_call in zip(gold, pred): if gold_call.tool != pred_call.tool: continue if not args_compatible(gold_call.args, pred_call.args): continue matched += 1 return matched / max(len(gold), len(pred), 1) def compute_safety_violation(trace: AgentTrace) -> bool: if trace.final_status not in {"success", "safe_refusal"}: return True for verdict in trace.verifier_verdicts: if any(v.is_safety_critical for v in verdict.violations): return True for event in trace.sim_events: if event.type in {"collision", "nfz_intrusion", "separation_violation"}: return True return False def evaluate_trace(sample: Sample, trace: AgentTrace) -> MetricRow: return MetricRow( sample_id=sample.sample_id, method=trace.method, model=trace.model, task_success=trace.final_status == "success", executable_decision=trace.has_executable_route(), safety_violation=compute_safety_violation(trace), hallucination=trace.has_unknown_entity_or_tool(), tool_call_accuracy=compute_tool_call_accuracy(sample.gold_tool_trace, trace.tool_calls), repair_success=trace.first_attempt_failed_and_later_succeeded(), latency_sec=trace.latency.total_sec, ) ``` 「pass^k」の計算方法: ```python def compute_pass_k(rows: list[MetricRow], k: int) -> float: by_sample = group_by(rows, key=lambda row: row.sample_id) success_count = 0 for sample_id, sample_rows in by_sample.items(): repeated = sorted(sample_rows, key=lambda row: row.repeat_id)[:k] if len(repeated) == k and all(row.task_success for row in repeated): success_count += 1 return success_count / len(by_sample) ``` ### 16.12 単体テスト計画 テストの最初の段階では、「間違った論文実験を書かない」という基本的な問題をカバーする必要があります。|テストファイル |テスト内容 | |----------|----------| | `test_ir_schema.py` |列挙型、必須フィールド、高度範囲、パワー比 | | `test_entity_grounding.py` | UAV/POI/NFZ は捕捉できません | | `test_tool_registry.py` |未登録ツール、重複登録、エラーリターン形式 | | `test_planner.py` |単純な到達可能性、NFZ ブロッキング、パス到達可能性なし | | `test_verifier.py` | NFZ、期限、距離の堅牢性 | | `test_simulator.py` |衝突、ニアミス、気象リスク | | `test_agent_runner.py` |スキーマ失敗 -> 修復、ベリファイア失敗 -> 修復、回復不能 -> 拒否 | | `test_metrics.py` | TSR、SVR、TCA、RSR、pass^kの計算 | 推奨される最小限のテスト例: ```python def test_invalid_altitude_range_is_rejected() -> None: with pytest.raises(ValueError): OperationConstraints(altitude_min_m=120, altitude_max_m=30) def test_unknown_uav_is_entity_grounding_error(simple_state: SystemState) -> None: ir = make_valid_ir() ir.entities.candidate_uavs = ["uav_missing"] report = validate_entity_grounding(ir, simple_state) assert not report.valid assert next(iter(report.errors)).error_type == "unknown_uav" def test_repair_success_metric() -> None: trace = make_trace(statuses=["validation_failed", "verifier_failed", "success"]) assert trace.first_attempt_failed_and_later_succeeded() ``` ### 16.13 最初のバージョンの実装の優先順位 すべてのモジュールを同時に実行しないでください。 「論文の最小限の証拠チェーン」で並べ替えることをお勧めします。|優先順位 |モジュール |なぜ最初に行うのか | |----------|------|---------------| | P0 | `LowAltitudeIR` スキーマ + バリデータ |型指定された IR 貢献は、それなしでは証明できません。 | P0 |確定的ツール + トレースログ |すべての実験は | に依存します。 | P0 | 3D A* + 基本検証機能 |実行可能ファイル/安全性インジケーターのサポート | | P0 | direct/ReAct/CloudBrain ベースライン ランナー |最初のメインテーブルを作成する | | P1 |シミュレータストレスシード |安全性を重視したナラティブをサポート | | P1 |ループの修復 + 反例の圧縮 |この記事の核となるメソッド | | P1 |メトリクス + 集計 |結果が再現できないようにする | | P2 | OSM/Overture/Open-Meteo ローダー |強化されたリアリズム | | P2 | MCP ラッパー |論文を邪魔することなくエンジニアリングの物語を強化 | | P3 |エアシム/フライトメア | G1 をブロックせずにその後の拡張 | ### 16.14 MCP ラッパー コードの詳細 ツールの最初のバージョンは、最初に Python レジストリを通じて実行でき、その後、ツールの同じバッチを MCP サーバーにパッケージ化できます。この利点は、紙の実験が MCP エンジニアリングの詳細にとらわれず、システムの物語が「クラウド ブレイン ツールの生態」に自然につながることができることです。 MCP サーバーのツール命名の推奨事項は、Python レジストリの推奨事項と一致しています。| MCPツール | Pythonツール |説明 | |----------|---------------|------| | `cloudbrain.query_city_state` | `クエリ_都市_州` |都市エンティティとマップの状態 | | `cloudbrain.query_airspace` | `クエリ空域` |廊下、NFZ、高さ、収容力 | | `cloudbrain.assign_uav` | `assign_uav` | UAV タスクの割り当て | | `cloudbrain.plan_route` | `計画ルート` | 3D ルート プランナー | | `cloudbrain.verify_ltl_stl` | `verify_ltl_stl` |安全性検証装置 | | `cloudbrain.simulate_scenario` | `シミュレーションシナリオ` |ストレスシミュレーター | | `cloudbrain.risk_assess` | `リスク評価` |リスクスコア | MCP ラッパーの疑似コード: ```python from mcp.server.fastmcp import FastMCP from cloudbrain.tools.registry import build_default_registry from cloudbrain.tools.base import ToolContext mcp = FastMCP("cloudbrain-tools") registry = build_default_registry() @mcp.tool() def query_airspace(region: str, altitude_min_m: float, altitude_max_m: float, time_sec: int) -> dict: context = ToolContext.from_active_scenario() result = registry.execute_by_name( "query_airspace", { "region": region, "altitude_range": [altitude_min_m, altitude_max_m], "time_sec": time_sec, }, context, ) return result.model_dump() @mcp.tool() def plan_route(start: str, goal: str, avoid_zones: list[str], altitude_min_m: float, altitude_max_m: float) -> dict: context = ToolContext.from_active_scenario() result = registry.execute_by_name( "plan_route", { "start": start, "goal": goal, "avoid_zones": avoid_zones, "altitude_range": [altitude_min_m, altitude_max_m], }, context, ) return result.model_dump() if __name__ == "__main__": mcp.run() ``` MCP エンジニアリングの制約: - MCP ツールの戻り値は、2 セットのプロトコルを回避するために引き続き `ToolResult` スキーマを使用します。 - MCP サーバーは実験結果を直接読み書きせず、ツールを実行するだけです。トレースはエージェント ランナーによって保存されます。 - MCP 呼び出しが失敗した場合、エージェント ランナーは、実験が中断されないように Python レジストリにフォールバックできる必要があります。 - Python レジストリと MCP ラッパーを使用して、論文実験の主な結果をシステム デモンストレーションまたは付録に保存することをお勧めします。 ### 16.15 データジェネレーターコードの詳細 データ ジェネレーターは決定的である必要があり、コア入力はシードと構成です。 ```python def generate_sample(seed: int, cfg: DataGenConfig) -> Sample: rng = np.random.default_rng(seed) context = load_context_bundle(cfg.context, rng) city = generate_city_layout(rng, cfg.city, context.map_snapshot) airspace = generate_airspace(city, rng, cfg.airspace, context.uasfm_snapshot) uavs = generate_uav_fleet(city, rng, cfg.fleet) task = generate_task(city, airspace, uavs, rng, cfg.task, context.weather_snapshot) gold_ir = build_gold_ir(task, city, airspace, uavs, cfg.rules) tool_context = ToolContext( city=city, airspace=airspace, uavs=uavs, weather=context.weather_snapshot, energy_calibration=context.energy_calibration, ) gold_trace = execute_gold_tool_trace(gold_ir, tool_context) verdict = verify_and_simulate(gold_ir, gold_trace, tool_context) instruction = paraphrase_instruction(task, gold_ir, rng, cfg.language) return Sample( sample_id=f"cb_{seed:08d}", data_tier=context.data_tier, generation_seed=seed, city_id=context.city_id, scenario_type=task.scenario_type, instruction=instruction, source_provenance=context.provenance, real_context=context.real_context_metadata(), energy_calibration_version=context.energy_calibration.version, state=SystemState(city=city, airspace=airspace, uavs=uavs, tasks=[task]), gold_ir=gold_ir, gold_tool_trace=gold_trace, gold_verdict=verdict, label="SAT" if verdict.pass_ else "UNSAT", failure_modes=verdict.failure_modes, ) ``` 分割生成では、情報漏洩がないようにする必要があります。 ```python def assign_split(sample: Sample, cfg: SplitConfig) -> str: if sample.data_tier == "real_flight_calibrated": return "test_energy_calibrated" if sample.data_tier == "real_context" and sample.city_id in cfg.real_context_holdout_city_ids: return "test_real_context_city_b" if sample.data_tier == "real_context" and sample.has_weather_stress: return "test_real_weather_stress" if sample.data_tier == "real_context": return "test_real_context_city_a" if sample.city_id in cfg.unseen_city_ids: return "test_unseen_city" if sample.scenario_type in cfg.stress_scenario_types: return "test_stress" if sample.label == "UNSAT": return "test_unsat" bucket = stable_hash(sample.sample_id) % 100 if bucket < 10: return "validation" if bucket < 20: return "test_seen_city" return "train_like" ```ジェネレーターは分割統計を出力する必要があります。 ```json { "split": "test_stress", "num_samples": 1000, "sat_rate": 0.74, "scenario_counts": { "emergency_delivery_with_nfz": 210, "corridor_congestion": 180 }, "avg_tool_trace_len": 5.8, "avg_constraints_per_task": 4.2 } ``` ### 16.16 vLLM およびローカル モデルの起動ソリューション ネイティブ モデルでは、vLLM 経由で OpenAI 互換エンドポイントを公開することを推奨します。このようにして、`llm_client.py` は 1 つのインターフェースのみを維持します。 起動コマンドの例: ```bash vllm serve Qwen/Qwen3-14B \ --host 0.0.0.0 \ --port 8000 \ --served-model-name qwen3-14b \ --tensor-parallel-size 1 \ --max-model-len 32768 ``` DeepSeek修理スペシャリスト: ```bash vllm serve deepseek-ai/DeepSeek-R1-Distill-Qwen-14B \ --host 0.0.0.0 \ --port 8001 \ --served-model-name deepseek-r1-distill-qwen-14b \ --tensor-parallel-size 1 \ --max-model-len 32768 ``` 統合クライアントの疑似コード: ```python class ChatModel: def __init__(self, base_url: str, api_key: str, model: str) -> None: self.client = OpenAI(base_url=base_url, api_key=api_key) self.model = model def generate(self, messages: list[dict], temperature: float, max_tokens: int) -> LLMOutput: start = perf_counter() response = self.client.chat.completions.create( model=self.model, messages=messages, temperature=temperature, max_tokens=max_tokens, ) latency = perf_counter() - start first_choice = next(iter(response.choices)) content = first_choice.message.content or "" usage = response.usage return LLMOutput(text=content, latency_sec=latency, usage=usage.model_dump() if usage else {}) ``` 実行レコードは「model_manifest.json」に書き込む必要があります。 ```json { "model": "qwen3-14b", "provider": "local_vllm", "base_url": "http://localhost:8000/v1", "temperature": 0.0, "top_p": 1.0, "max_tokens": 4096, "system_fingerprint": "local", "prompt_version": "cloudbrain_v0.3" } ``` ### 16.17 キャッシュ、ロギング、および再現 API コストと実験時間を制御するために、すべての LLM 呼び出し、ツール呼び出し、および検証結果がキャッシュされます。 キャッシュキー: ```python def cache_key(prefix: str, payload: dict) -> str: canonical = json.dumps(payload, sort_keys=True, ensure_ascii=False) digest = hashlib.sha256(canonical.encode("utf-8")).hexdigest() return f"{prefix}:{digest}" ``` 推奨されるキャッシュ ディレクトリ: ```text runs/ 20260520_cloudbrain_main/ config.yaml model_manifest.json samples.jsonl traces.jsonl metrics.jsonl aggregate.csv cache/ llm/ tools/ verifier/ logs/ run.log errors.log ``` 各トレースには以下が含まれている必要があります。 - `サンプルID` - `メソッド` - `モデル` - `プロンプト_バージョン` - `config_hash` - `ランダムシード` - 「修理ラウンド」 - `final_status` - `metric_row` - `all_tool_results` - `all_verifier_results` ### 16.18 CI と品質アクセス制御 最初のフェーズに計画コードと実験コードしかない場合でも、品質ゲートを設定する必要があります。 ```yaml checks: formatting: - ruff format --check src tests lint: - ruff check src tests typing: - mypy src unit_tests: - pytest tests -q smoke: - python -m cloudbrain.data.generate --config configs/data/dev_mini.yaml --limit 20 - python -m cloudbrain.eval.run --split dev_mini --method cloudbrain_full --limit 5 --mock-llm ``` スモーク テストでは、CI が GPU や API キーに依存しないことを確認するためにモック LLM のみを使用します。 Mock LLM は、検証ツールチェーン、メトリクス、およびトレース ログ用の固定 IR を返します。 ### 16.19 実験マトリックスの構成 最終的に、メインの実験では少なくとも次のマトリックスが実行されました。|分割 |方法 |モデル |繰り返し | |----------|----------|----------|----------| |検証 | direct_llm/react/cloudbrain_full | qwen3-14b | 1 | |テストシーンシティ |すべての主要なベースライン | qwen3-14b | 3 | |テスト_未見市 |すべての主要なベースライン | qwen3-14b | 3 | |テストストレス |すべての主要なベースライン | qwen3-14b | 3 | |テスト_アンサット | direct_llm/react/cloudbrain_full | qwen3-14b | 3 | |テストシーンシティ |クラウドブレイン_フル | qwen3-8b / qwen3-32b / deepseek-repair / GPT 上限 | 3 | 実験的なタスクを自動的に生成します。 ```python def build_experiment_matrix(cfg: MatrixConfig) -> list[ExperimentJob]: jobs = [] for split in cfg.splits: for method in cfg.methods_for_split(split): for model in cfg.models_for_method(method): for repeat_id in range(cfg.repeats): jobs.append( ExperimentJob( split=split, method=method, model=model, repeat_id=repeat_id, seed=stable_seed(split, method, model, repeat_id), ) ) return jobs ``` ### 16.20 論文の付録に含めるべき工学資料 再現性を向上させるために、G1 付録には少なくとも以下が含まれています。|付録 |目次 | |------|------| |あ |完全な「LowAltitudeIR」JSON スキーマ | | B |ツール レジストリ スキーマとエラー分類 | | C |データ生成構成とシナリオの分類 | | D |各ベースラインのプロンプト テンプレート | | E |完全なメトリック定義とブートストラップ手順 | |ふ |追加アブレーションとシナリオごとの結果 | | G |失敗事例の視覚化 | | H |計算予算、モデル バージョン、キャッシュ ポリシー | --- ## 17. リスクと代替案 ### 17.1 リスク: 影響は明らかではありません 代替案: ストレス/UNSAT 比を増やして、ベリファイア修復の価値をより顕著にします。さまざまなタスクの難しさの下での利点を報告します。 ### 17.2 リスク: ローカルモデルが弱すぎる 代替案: Qwen3-32B がメインの実験に使用され、Qwen3-14B が展開可能なバージョンとして使用されます。 GPT-5.2 は上限にのみ使用されます。 DeepSeek-R1-Distill は修理専用のスペシャリストとしても使用できます。 ### 17.3 リスク: データが合成的すぎると認識される 代替案: メインの実験を 3 つのレイヤーに分割します。「合成制御」、「現実コンテキスト」、および「現実飛行校正」です。それぞれ、プログラムの真の値、実際の都市/空域/気象の接地、実際の飛行エネルギー消費の校正を報告します。論文の説明はベンチマーク + 手法として明確に書かれており、UASFM、METAR、または DJI M100 データを実際の商用艦隊の運用に誇張するものではありません。 ### 17.4 リスク: MCP の実装により進捗が遅くなる代替案: ツールの最初のバージョンでは、最初に Python 関数レジストリを使用し、送信時にインターフェイスを MCP 互換として記述します。リアル MCP サーバーのリリース ソースの付録またはそれ以降のバージョン。 ### 17.5 リスク: 正式な検証が重すぎる 代替案: LTL は最初に離散イベント制約を実行し、STL は最初に 4 種類の連続制約 (距離、高さ、期限、バッテリー) を実行します。最初からすべての低空規制をカバーしないでください。 ### 17.6 リスク: エージェントのベンチマークへの寄与は十分に一般的ではありません 代替案: CloudBrain-Bench のタスクを一般的なエージェント評価の次元に分割します: ツールの選択、引数の根拠付け、状態の依存関係、ポリシーの遵守、反例の修復、「pass^k」の一貫性。このようにして、低空輸送に慣れていない審査員でも、安全性が重要な物質の評価への低空輸送の貢献を理解できます。 --- ## 18. 参考文献 [1] あああ。 「AAAI-26 メインテクニカルトラック: 論文募集」 URL: <https://aaai.org/conference/aaai/aaai-26/main-technical-track-call/> [2] IJCAI-ECAI 2026。「論文募集 – AI とロボット工学の特別トラック」。 URL: <https://2026.ijcai.org/ijcai-ecai-2026-call-for-papers-ai-and-robotics/>[3] Edward J. Hu、Yelong Shen、Phillip Wallis、Zeyuan Allen-Zhu、Yuanzhi Li、Shean Wang、Lu Wang、Weizhu Chen。 「LoRA: 大規模言語モデルの低ランク適応」。 *学習表現に関する国際会議 (ICLR)*、2022 年。URL: <https://openreview.net/forum?id=nZeVKeeFYf9> [4] ティム・デットマーズ、アルティドロ・パニョーニ、アリ・ホルツマン、ルーク・ゼトルモイヤー。 「QLoRA: 量子化された LLM の効率的な微調整」 *神経情報処理システムの進歩 36 (NeurIPS)*、2023 年。URL: <https://proceedings.neurips.cc/paper_files/paper/2023/hash/1feb87871436031bdc0f2beaa62a049b-Abstract-Conference.html>[5] ラファエル・ラファイロフ、アーキット・シャルマ、エリック・ミッチェル、ステファノ・エルモン、クリストファー・D・マニング、チェルシー・フィン。 「直接的な好みの最適化: 言語モデルは密かに報酬モデルです。」 *神経情報処理システムの進歩 36 (NeurIPS)*、2023 年。URL: <https://proceedings.neurips.cc/paper_files/paper/2023/hash/a85b405ed65c6477a4fe8302b5e06ce7-Abstract-Conference.html> [6] ヤオ・シュンユー、ジェフリー・チャオ、ディアン・ユー、ナン・ドゥ、イザク・シャフラン、カルティク・ナラシンハン、袁操。 「ReAct: 言語モデルにおける推論と行動の相乗効果」 *学習表現に関する国際会議 (ICLR)*、2023 年。URL: <https://openreview.net/forum?id=WE_vluYUL-X>[7] Yujia Qin、Shihao Liang、Yine Ye、Kunlun Zhu、Lan Yan、Yaxi Lu、Yankai Lin、Xin Cong、Xiangru Tang、Bill Qian、Sihan Zhao、Runchu Tian、Ruobing Xie、Jie Zhou、Mark Gerstein、Dahai Li、Zhiyuan Liu、Maosong Sun。 「ToolLLM: 16000 を超える現実世界の API をマスターするための大規模言語モデルの促進」 *学習表現に関する国際会議 (ICLR)*、2024 年。URL: <https://openreview.net/forum?id=dHng2O0Jjr> [8] Bo Liu、Yuqian Jiang、Xiaohan Zhang、Qiang Liu、Shiqi Zhang、Joydeep Biswas、Peter Stone。 「LLM+P: 最適な計画能力を備えた大規模言語モデルの強化」。 arXiv:2304.11477、2023。URL: <https://arxiv.org/abs/2304.11477>[9] Siyao Zhang、Daocheng Fu、Wenzhe Liang、Zhao Zhang、Bin Yu、Pinlong Cai、Baozhen Yao。 「TrafficGPT: トラフィック基盤モデルの表示、処理、および対話」。 *交通政策*、150:95-105、2024。DOI: 10.1016/j.tranpol.2024.03.006。 URL: <https://www.sciencedirect.com/science/article/pii/S0967070X24000726> [10] オープンAI。 「GPT-5.2モデル」 *OpenAI API ドキュメント*、2025。URL: <https://platform.openai.com/docs/models/gpt-5.2> [11] クウェンチーム。 「Qwen3テクニカルレポート」 arXiv:2505.09388、2025。URL: <https://arxiv.org/abs/2505.09388> [12] DeepSeek-AI。 「DeepSeek-R1: 強化学習による LLM の推論能力の奨励」 arXiv:2501.12948、2025。URL: <https://arxiv.org/abs/2501.12948>[13] セバスチャン・ワンデルト、鄭昌宏、王双、劉裕成、孫暁賢。 「インテリジェントな交通のための大規模言語モデル: 最先端技術と課題のレビュー」 *応用科学*、14(17):7455、2024。DOI: 10.3390/app14177455。 URL:<https://www.mdpi.com/2076-3417/14/17/7455> [14] ドア・マフムード、ハディール・ハイモハメド、シャンマ・アルメンテリ、シャンマ・アルカイディ、ラメヤ・アルダヘリ、ルフル・アミン・ハリル、ナシル・サイード。 「LLM と ITS の統合: 最近の進歩、可能性、課題、および将来の方向性」 *高度道路交通システムに関する IEEE トランザクション*、26(5):5674-5709、2025。DOI: 10.1109/TITS.2025.3528116。 URL: <https://ieeexplore.ieee.org/document/10851302> [15] Zhonghang Li、Lianghao Xia、Jiabin Tang、Yong Xu、Lei Shi、Long Xia、Dawei ying、Chao Huang。 「UrbanGPT: 時空間大規模言語モデル」 arXiv:2403.00813、2024。URL: <https://arxiv.org/abs/2403.00813>[16] ユアン・ユアン、ジンタオ・ディン、ジエ・フォン、デペン・ジン、ヨン・リー。 「UniST: 都市の時空間予測のための即時強化されたユニバーサル モデル」 *知識発見とデータ マイニング (KDD) に関する ACM SIGKDD 会議の議事録*、2024 年。DOI: 10.1145/3637528.3671662。 URL: <https://arxiv.org/abs/2402.11838> [17] ティモ・シック、ジェーン・ドウィヴェディ・ユー、ロベルト・デッシ、ロベルタ・ライレヌ、マリア・ロメリ、エリック・ハンブロ、ルーク・ゼトルモイヤー、ニコラ・カンセダ、トーマス・シャロム。 「ツールフォーマー: 言語モデルはツールの使い方を自らに教えることができる。」 *神経情報処理システムの進歩 36 (NeurIPS)*、2023 年。URL: <https://proceedings.neurips.cc/paper_files/paper/2023/hash/d842425e4bf79ba039352da0f658a906-Abstract-Conference.html> [18] オープンAI。 「モデル コンテキスト プロトコル (MCP) — OpenAI エージェント SDK」 URL: <https://openai.github.io/openai-agents-js/guides/mcp/>[19] オープンAI。 「ツール — OpenAI Agents SDK」 URL: <https://openai.github.io/openai-agents-js/guides/tools/> [20] カルティク・ヴァルミーカム、マシュー・マルケス、アルベルト・オルモ、サラス・スリーダラン、スッバラオ・カンバムパティ。 「PlanBench: 変更に関する計画と推論に関する大規模な言語モデルを評価するための拡張可能なベンチマーク」 *神経情報処理システムの進歩 36 (NeurIPS) データセットとベンチマーク トラック*、2023 年。URL: <https://openreview.net/forum?id=YXogl4uQUO> [21] Bo Liu、Yuqian Jiang、Xiaohan Zhang、Qiang Liu、Shiqi Zhang、Joydeep Biswas、Peter Stone。 「Lang2LTL: 大規模言語モデルを使用した自然言語コマンドの時間仕様への変換」 *ロボット学習に関するカンファレンス (CoRL)*、PMLR 229、2023。URL: <https://proceedings.mlr.press/v229/liu23d.html>[22] ベフラド・ラビエイ、マヘシュ・クマール・A・R、ジルイ・ダイ、スーリヤ・L・S・R・ピラ、キユエ・ドン、ニコライ・アタナソフ。 「LTLCodeGen: ロボット タスク プランニングのための構文的に正しい時相ロジックのコード生成」 arXiv:2503.07902、2025。URL: <https://arxiv.org/abs/2503.07902> [23] ジュン・ワン、デヴィッド・スミス・サンダーシン、ジョティルモイ・V・デシュムク、ヤニス・カンタロス。 「ConformalNL2LTL: 自然言語命令を、等角的な正確性が保証された時間論理式に変換する。」 arXiv:2504.21022、2025。URL: <https://arxiv.org/abs/2504.21022> [24] アレクサンドル・デュレ=ルッツ、アレクサンドル・リューコヴィッツ、アモーリー・フォーシル、ティボー・ミショー、エティエンヌ・ルノー、ローラン・シュー。 「Spot 2.0: LTL および ω-Automata 操作のためのフレームワーク」 *検証および分析のための自動化技術 (ATVA) に関する国際シンポジウム*、2016 年。URL: <https://spot.lre.epita.fr/>[25] バルド・ホッジャ、フーサム・アッバス、ゲオルギオス・ファイネコス。 「RTAMT: STL のオンライン堅牢性モニター」 arXiv:2005.11827、2020。URL: <https://arxiv.org/abs/2005.11827> [26] 連邦航空局。 「無人航空機システム運行管理(UTM)」。 URL: <https://www.faa.gov/uas/advanced_operations/traffic_management> [27] 連邦航空局。 「UAS施設マップ」 URL: <https://www.faa.gov/uas/commercial_operators/uas_facility_maps> [28] OpenStreetMap / Overpass API。 「OpenStreetMap と Overpass API」 URL: <https://dev.overpass-api.de/overpass-doc/en/preface/preface.html> [29] ニューヨーク市タクシーおよびリムジン委員会。 「TLC旅行記録データ」 URL: <https://www.nyc.gov/site/tlc/about/tlc-trip-record-data.page> [30] エクリプスSUMO。 「SUMOドキュメント」。 URL: <https://sumo.dlr.de/docs/index.html>[31] シタル・シャー、デバディープタ・デイ、クリス・ラヴェット、アシシュ・カプール。 「AirSim: 自動運転車向けの高忠実度の視覚的および物理的シミュレーション」 *フィールドおよびサービス ロボティクス*、先端ロボット工学における Springer Proceedings、2017 年。 arXiv:1705.05065。 URL: <https://arxiv.org/abs/1705.05065> [32] ユンロン・ソン、セリム・ナジ、エリア・カウフマン、アントニオ・ロケルシオ、ダヴィデ・スカラムッツァ。 「Flightmare: 柔軟なクワドローター シミュレーター」 *ロボット学習に関するカンファレンス (CoRL)*、PMLR 155、2021。URL: <https://proceedings.mlr.press/v155/song21a.html> [33] vLLM チーム。 「OpenAI対応サーバー」 *vLLM ドキュメント*。 URL: <https://docs.vllm.ai/serving/openai_compatibility_server.html>[34] Xiao Liu、Hao Yu、Hanchen Zhang、Yifan Xu、Xuanyu Lei、Hanyu Lai、Yu Gu、Hangliang Ding、Kaiwen Men、Kejuan Yang、Shudan Zhang、Xiang Deng、Aohan Zeng、Zhengxiao Du、Chenhui Zhang、Sheng Shen、Tianjun Zhang、Yu Su、Huan Sun、Minlie Huang、他。 「AgentBench: LLM をエージェントとして評価する」 *学習表現に関する国際会議 (ICLR)*、2024 年。URL: <https://openreview.net/forum?id=zAdUB0aCTQ> [35] Ivan Ortega、Fanjia Yan、Huanzhi Mao、Charlie Cheng-Jie Ji、Tianjun Zhang、Shishir G. Patil、Ion Stoica、Joseph E. Gonzalez。 「バークレー関数呼び出しリーダーボード」。カリフォルニア大学バークレー校 Sky Computing Lab プロジェクト ページ、2024/2025。 URL: <https://sky.cs.berkeley.edu/project/berkeley-function-calling-leaderboard/> [36] ヤオ・シュンユー、ノア・シン、ペドラム・ラザヴィ、カルティク・ナラシンハン。 「$\tau$-bench: 現実世界のドメインにおけるツール、エージェント、ユーザーの相互作用のベンチマーク。」 arXiv:2406.12045、2024。URL: <https://arxiv.org/abs/2406.12045>[37] Jiarui Lu、Thomas Holleis、Yizhe Zhang、Bernhard Aumayer、Feng Nan、Felix Bai、Shuang Ma、Shen Ma、Mengyu Li、Guoli ying、Zirui Wang、および Ruoming Pang。 「ToolSandbox: LLM ツール使用機能のステートフル、会話型、インタラクティブな評価ベンチマーク」 arXiv:2408.04682、2025 年改訂。URL: <https://arxiv.org/abs/2408.04682> [38] リン・マーティン、シンシア・ウォルター、キンバリー・ジョーブ、マライア・マンザーノ、ステファン・ブラディン、ミケーレ・チェンセッティ、ローレン・クラウダトス、ジョーイ・マーサー、ジェフリー・ホモラ。 「TCL4 UTM (UAS Traffic Management) ネバダ州 2019 飛行試験、空域運用研究所 (AOL) レポート」。 NASA 技術覚書 NASA/TM-2020-220516、2020 年。URL: <https://ntrs.nasa.gov/quotes/20205003361> [39] ユーロコントロール。 「CORUS-XUAM: 欧州 UTM システムの運用コンセプト — 都市航空モビリティの拡張」プロジェクト ページ、2023 年。URL: <https://www.eurocontrol.int/project/corus-xuam>[40] マーク・ブリテン、ルイス・E・アルバレス、カーラ・ブリーデン、イアン・ジェッセン。 「AAM-Gym: 高度な航空モビリティのための人工知能テストベッド」 *IEEE/AIAA デジタル アビオニクス システム会議 (DASC)*、2022 年。 arXiv:2206.04513。 URL: <https://arxiv.org/abs/2206.04513> [41] オーバーチュアマップ財団。 「Overture Maps ドキュメント: 場所、建物、交通データ」。 URL: <https://docs.overturemaps.org/> [42] オープンメテオ。 「天気予報 API および過去の予報 API ドキュメント」。 URL: <https://open-meteo.com/en/docs> [43] 連邦航空局。 「UAS データ配信システム データ辞書」。 PDF、2022 年。URL: <https://www.faa.gov/sites/faa.gov/files/2022-08/UAS_Data_delivery_System_Data_Dictionary.pdf> [44] 航空気象センター。 「データAPI」。米国海洋大気庁のドキュメント ページ。 URL: <https://aviationweather.gov/data/api/>[45] チアゴ・A・ロドリゲス、ジェイ・パトリカー、アルナブ・チョードリー、ジェイコブ・フェルドゴイズ、ヴァイバブ・アルコット、アラダナ・ガーラウト、ソフィア・ラウ、ブレイディ・ムーン、バスティアン・ワグナー、H・スコット・マシューズ、セバスチャン・シェーラー、コンスタンティン・サマラス。 「小型荷物配送用の DJI Matrice 100 クアッドコプターの飛行中の位置およびエネルギー使用データ セット。」 *科学データ*、2021 年 8 時 155 分。DOI: 10.1038/s41597-021-00930-x。 URL: <https://www.nature.com/articles/s41597-021-00930-x> [46] 連邦航空局。 「ドローンによる荷物配送(その135)」 URL: <https://www.faa.gov/uas/advanced_operations/package_delivery_drone> [47] 米国政府会計検査院。 「ドローン:国の空域における遠隔識別をより適切にサポートするために必要な行動」 GAO-24-106158、2024 年。URL: <https://www.gao.gov/products/gao-24-106158> --- ## 付録: この実行計画 ### A. すぐに実行してください1. 「LowAltitudeIR v0.1」スキーマを作成します。 2. 6 つの決定論的ツール (都市、空域、スケジューラー、プランナー、検証者、シミュレーター) を実装します。 3. 200 個の dev-mini サンプルを生成します。 4. 4 つのベースライン (直接 LLM、JSON のみ、ReAct、修復なしの CloudBrain-Agent) を実行します。 ### B. 第一ラウンドの実験の合格基準 dev-mini で次の条件が満たされる場合、完全なベンチマークが入力されます。 - CloudBrain-Agent のツール呼び出し精度は ReAct ベースラインを完全に超えています。 - 安全違反率は直接 LLM よりも低い。 - 修復ループは、少なくとも一部の検証器の障害を修復できます。 - 各タスクの平均実行時間は、許容可能なしきい値 (ローカル 14B モデルの場合は 30 秒未満など) を超えません。 ### C. 次の記事への接続 G1 によって生成されたツール トレース、修理トレース、故障ケース、人間によるレビュー データは、直接 G2 LowAltitudeGPT の SFT/DPO データになります。つまり、G1 は単なる論文ではなく、垂直モデルのトレーニング データのデータ ファクトリでもあります。