← Blog

Proposition d'article complète de l'article G1 v1 : Agent LLM vérifiable pour le cerveau des nuages ​​​​de trafic à basse altitude

Planifiez complètement les questions de recherche, le positionnement de la soumission, la conception de l'algorithme, la construction des données, la sélection du modèle, le déploiement local, le plan expérimental, les indicateurs d'évaluation, les conclusions attendues, la conception des graphiques, le contrôle des risques et le plan d'exécution pour le premier document de conférence CloudBrain-Agent.

Papier G1Agent CloudBrainCerveau de nuage de trafic à basse altitudeAgent LLMPCMUtilisation des outilsAAAIIJCAIdroneVérification formelle

Article G1 Proposition d’article complète v1 : Agent LLM vérifiable pour le cerveau des nuages ​​de trafic à basse altitude

Jugement principal : le premier article ne doit pas être rédigé comme “le réglage fin d’un grand modèle de trafic à basse altitude”, mais doit être rédigé comme un document de méthode d’agent LLM de trafic à basse altitude vérifiable, reproductible et déployable.
Sujet recommandé : CloudBrain-Agent : agents LLM améliorés par des outils et guidés par la vérification pour l’exploitation du trafic à basse altitude.

1. Positionnement du papier et jugement de soumission

1.1 Positionnement en une phrase

Cet article étudie le grand agent modèle dans le cerveau du nuage de trafic à basse altitude : étant donné une tâche en langage naturel, l’état de l’espace aérien urbain à basse altitude, l’état de la flotte d’UAV et les contraintes de sécurité, comment l’agent LLM peut générer des décisions d’exploitation de trafic à basse altitude sûres, exécutables et interprétables grâce à une représentation intermédiaire structurée, à l’invocation d’outils, à une vérification formelle et à un retour de simulation.

1.2 Contributions recommandées

Préféré : Maître AAAI/IJCAI.
Alternatives : AAMAS, atelier IROS/ICRA, suivi de l’expansion du T-ITS.

Selon le moment du 20/05/2026, la session spécifique doit être alignée sur le prochain cycle de CFP AAAI/IJCAI ; cet article est toujours conçu dans le style de la conférence principale AAAI/IJCAI, car l’AAAI met l’accent sur les méthodes d’IA, les domaines d’application et la reproductibilité, et le parcours IJCAI-ECAI IA et robotique se concentre clairement sur les agents robots, l’IA générative, le raisonnement, la modélisation structurée et les conséquences des actions [1] [2].

1.3 Pourquoi cet article est-il plus approprié à faire en premier que « Réglage fin du grand modèle de trafic à basse altitude »

Le réglage fin direct d’un LowAltitudeGPT se heurtera à trois risques de révision :

  1. LoRA, QLoRA et DPO sont des paradigmes de formation déjà matures. Le simple fait de changer les données du domaine ne suffit pas à constituer la principale contribution [3] [4] [5].
  2. Le trafic à basse altitude est un système critique pour la sécurité, et il est difficile de convaincre les évaluateurs que le LLM génère directement des actions de contrôle.
  3. Les données réelles sur les opérations de circulation à basse altitude sont rares. Si vous vous concentrez sur la « formation sur de grands modèles » dans le premier article, vous serez interrogé sur l’échelle des données, le budget de formation et la nouveauté du modèle.Par conséquent, le premier article devrait se concentrer sur Agent + Outils + Vérificateur + Commentaires sur le simulateur. Le grand modèle n’est pas le contrôleur final, mais une couche de compréhension des tâches, d’orchestration des outils, de réparation des contre-exemples et d’interprétation. Ce paramètre est naturellement lié aux travaux d’utilisation d’agents/d’outils/de planification tels que ReAct, ToolLLM, LLM+P [6] [7] [8], et peut également rattraper la discussion de TrafficGPT sur l’interaction entre le modèle de base du trafic et LLM [9].

1.4 2026-05-22 Écriture de calibrage : n’écrivez pas G1 comme une histoire TR-C, mais conservez les preuves du système de trafic

Le premier investissement dans G1 est AAAI/IJCAI, la principale contribution doit donc être la méthode des agents IA plutôt que le récit du système de type journal de transport. Une façon plus précise de l’écrire est :

CloudBrain-Agent est une méthode d’agent IA évaluée dans un domaine de trafic à basse altitude critique pour la sécurité.

En d’autres termes, la scène du trafic présente de réelles difficultés et contraintes de sécurité, mais l’article doit encore répondre à des questions dans le domaine des agents : si l’appel de l’outil est fiable, si l’état est cohérent, si la réparation du contre-exemple est efficace, si le modèle est une illusion et si l’évaluation est reproductible.

Dans le même temps, G1 ne peut pas uniquement signaler « task_success » et « tool_call_accuracy ». Le trafic à basse altitude étant une zone critique pour la sécurité, les preuves du système de circulation doivent être préservées dès la première version de l’expérience :| Niveau | Thème principal du texte AAAI/IJCAI | Suivi de l’expansion des T-ITS | |------|---------------------|-------------------------| | Capacités des agents | Validité IR, précision des appels d’outils, réussite des réparations, taux d’hallucinations | confirmation humaine, charge de travail de l’opérateur, cohérence avec état | | Sécurité | violation de la sécurité, violation de la NFZ, violation de la batterie | Proxy LoWC/NMAC, rapport de risque, dégradation météo/communication | | Efficacité | décision exécutable, latence, runtime | délai, distance supplémentaire, énergie, débit | | Généralisation | ville invisible, stress, UNSAT/tâches ambiguës | couloir à haute densité, drone non coopératif, perte de communication, division de la ville dans un contexte réel | | Illumination du système | Quand le feedback du vérificateur est-il nécessaire | Quels scénarios doivent être renvoyés par le solveur déterministe/superviseur humain de l’agent LLM |

Les conditions aux limites de G1 doivent donc s’écrire clairement :

1.5 2026-05-23 Compilation : liste figée des versions de soumission

La première version de la soumission G1 doit geler trois revendications pour éviter de se transformer en une spécification de plate-forme à basse altitude :1. Benchmark d’utilisation des outils basés sur le domaine : CloudBrain-Bench teste non seulement le format JSON, mais teste également la sélection des fonctions, la mise à la terre des paramètres, la dépendance de l’état, la conformité aux politiques et la cohérence à plusieurs niveaux dans la chaîne de transport à basse altitude. 2. Réparation guidée par le vérificateur : les erreurs de sécurité, les erreurs inexécutables et les tâches ambiguës dans les missions de trafic à basse altitude doivent être converties en signaux de réparation structurés via le vérificateur LTL/STL, le planificateur d’itinéraire et les commentaires du simulateur. 3. Implémentation d’un agent déployable localement : L’expérience principale doit être reproductible sur le modèle open source local, et le modèle API ne sert que d’enseignant ou de limite supérieure.

La première partie doit être complétée :| Modules | Exigences de gel | |------|----------| | Faible AltitudeIR | Schéma fixe, vérificateur de type, codes d’erreur et exemples JSON | | Outils | Au moins 6 : requête d’espace aérien, état de la flotte, affectation, planificateur d’itinéraire, vérificateur LTL/STL, simulateur de scénario/estimateur de risques | | CloudBrain-Banc | dev/validation/test/stress split, couvrant les scénarios de stress SAT, UNSAT, ambigus, à ressources limitées | | Lignes de base | Direct LLM, JSON uniquement, ReAct, LLM+P / planificateur uniquement, utilisation d’outils sans vérificateur, CloudBrain complet | | Métriques | réussite de la tâche, précision des appels d’outil, décision exécutable, violation de la sécurité, réussite de la réparation, taux d’hallucinations, latence/coût | | Ablation | pas d’IR, pas de vérificateur, pas de simulateur, pas de réparation, professeur API vs modèle local | | Couche de données | données de base synthétiques + champs de contexte réel OSM/FAA/OD/SUMO, n’écrivez pas de données réelles en tant que système déployé |

Le premier contenu suspendu :

La fonction de cette liste figée est de contrôler les limites de l’article : G1 prouve seulement qu’un « agent LLM vérifiable dans le domaine clé de la sécurité du trafic à basse altitude » est établi, et les G2/G3/G4 ultérieurs traiteront respectivement du réglage fin, de l’expansion multi-agents et incarnée.

---## 2. Projet de résumé

Les opérations de trafic urbain à basse altitude nécessitent une prise de décision en temps réel entre les tâches dynamiques, les ressources limitées de l’espace aérien, les contraintes de statut des drones et les règles de sécurité. Les grands modèles de langage ont la capacité de comprendre le langage naturel et de décomposer des tâches complexes, mais s’ils sont utilisés directement pour la planification des drones et la planification de trajectoire, ils produiront des hallucinations, des plans inexécutables et des violations de la sécurité. Cet article propose CloudBrain-Agent, un cadre d’agent LLM d’amélioration et de guidage de vérification pour le cerveau des nuages ​​de trafic à basse altitude. CloudBrain-Agent analyse les tâches en langage naturel et les états du système en « LowAltitudeIR » typé, invoque une requête d’espace aérien, l’allocation d’UAV, la planification de trajectoire, la vérification LTL/STL, des outils de simulation de scénario et d’évaluation des risques, et corrige de manière itérative les décisions à l’aide de contre-exemples de vérificateurs et de commentaires de simulation. Nous construisons CloudBrain-Bench pour couvrir la distribution d’urgence, les inspections, l’évitement des zones d’exclusion aérienne, la congestion des couloirs, les goulots d’étranglement de recharge, le repli multimode et les tâches insatisfaisantes. L’expérience comparera le LLM direct, ReAct avec invite uniquement, l’utilisation d’outils sans vérification, LLM+P, l’orchestration de style TrafficGPT et CloudBrain-Agent complet. L’attente de pré-enregistrement est que CloudBrain-Agent surpasse considérablement les références d’invite uniquement et d’outils uniquement en termes de réussite des tâches, de taux de décision exécutable, de taux de violation de la sécurité, de taux d’hallucinations et de réussite des réparations, tout en maintenant une latence de déploiement local acceptable.

3. Questions de recherche et hypothèses principales

3.1 Questions de recherche

RQ1 : L’agent LLM peut-il générer de manière stable des chaînes de décision du bon type et exécutables par un outil dans les missions de trafic à basse altitude ?

RQ2 : La vérification formelle et les retours de simulation peuvent-ils réduire considérablement les plans non exécutables, les violations de sécurité et les hallucinations en LLM ?

RQ3 : Par rapport à l’ajustement direct du modèle vertical, la solution LLM générale + IR typée + MCP/outils + vérificateur peut-elle former un système de recherche reproductible, déployable et évolutif plus rapidement ?RQ4 : Le modèle open source local peut-il s’approcher des performances du modèle source fermée grâce aux commentaires sur les données et les règles générés par l’API de l’enseignant, et prendre en charge l’article LowAltitudeGPT ultérieur ?

3.2 Hypothèses fondamentales

H1 : la saisie de « LowAltitudeIR » peut améliorer considérablement la qualité de sortie structurée et la précision des appels d’outils.
H2 : La réparation guidée par vérification peut améliorer considérablement le taux de décision exécutable et réduire le taux de violation de la sécurité.
H3 : Le retour d’information du simulateur est le plus critique pour la généralisation de scènes dangereuses invisibles.
H4 : Il n’est pas nécessaire de former le modèle de fondation verticale dans un premier temps ; le modèle général + la couche d’outils d’agent + le post-traitement du vérificateur suffisent pour compléter le document G1.
H5 : Une fois le modèle local Qwen3 / DeepSeek-R1-Distill déployé via vLLM, il peut être utilisé comme modèle expérimental principal reproductible ; Les modèles d’API tels que GPT-5.2 servent d’enseignants et de limites supérieures de performances [10] [11] [12].

4. Conception de la contribution papier

Il est recommandé que la contribution finale de l’article soit rédigée en trois articles pour éviter d’être dispersée :

  1. Cadre CloudBrain-Agent Un agent LLM typé utilisant un outil est proposé pour le cerveau des nuages de trafic à basse altitude, qui unifie les tâches en langage naturel, l’état de l’espace aérien urbain, l’état de la flotte d’UAV et les contraintes de sécurité dans « LowAltitudeIR ».

  2. Réparation guidée par vérification pour le trafic à basse altitude Transformez les retours d’échec des vérificateurs LTL/STL, des planificateurs d’itinéraires et des simulateurs en contre-exemples structurés qui pilotent les appels d’outils de réparation LLM, les contraintes de tâches et les recommandations de chemin/planification.3. CloudBrain-Bench et protocole d’évaluation Créez une référence cérébrale pour les nuages de trafic à basse altitude, couvrant des indicateurs tels que la précision des appels d’outils, les décisions exécutables, les violations de sécurité, le succès des réparations, la généralisation, la latence et la confiance humaine.

Il n’est pas recommandé d’écrire la contribution sous la forme « Nous avons formé un grand modèle de trafic à basse altitude ». Un réglage fin peut être effectué comme une extension expérimentale ou comme le prochain G2.

4.1 Matrice de positionnement du papier après le deuxième cycle de recherche

Après une recherche en ligne, le meilleur point d’entrée pour G1 devrait être plus clairement l’évaluation des agents basés sur le domaine + la vérification de la sécurité, plutôt que les applications LLM générales. AgentBench prouve que les agents LLM doivent évaluer le raisonnement et la prise de décision dans un environnement interactif [34] ; BFCL explique que l’appel de fonction doit vérifier la sélection de fonction, les paramètres, les appels parallèles et la détection de pertinence [35] ; -bench met en outre l’accent sur l’interaction multi-tours, l’API, la politique de domaine et l’indice de cohérence « pass^k » [36] ; ToolSandbox souligne que la dépendance à l’état, la canonisation et l’insuffisance d’informations sont les principales difficultés des agents basés sur des outils. [37].

L’inspiration pour G1 de ces travaux est la suivante : CloudBrain-Bench peut non seulement évaluer “si JSON est généré”, mais évalue également la mise à jour du statut de l’agent, la conformité aux règles, la dépendance aux outils, la réparation des pannes et la cohérence multi-tours dans la chaîne de transport à basse altitude.| Déjà réalisé | Travail représentatif | Limites | Différences dans G1 | |--------------|----------|------|---------------| | Benchmark des agents généraux | AgentBench, -bench, ToolSandbox [34] [36] [37] | N’inclut pas les contraintes de sécurité du trafic à basse altitude ni la chaîne d’outils des drones | Outils de domaine, politique, vérificateur pour UTM/UAV | | fonction d’appel de référence | BFCL [35] | Concentrez-vous sur l’exactitude des appels de fonction et ne vous souciez pas de l’exécutabilité physique et de la sécurité | Les appels d’outils doivent passer par le planificateur/vérificateur/simulateur | | LLM + trafic | TrafficGPT, enquête ITS LLM [9] [13] [14] | Trafic terrestre multifocale ou interaction avec un modèle de trafic | Extension à l’espace aérien à basse altitude, flotte de drones et sécurité formelle | | Spécification de tâche NL-LTL/robot | Lang2LTL, LTLCodeGen, ConformalNL2LTL [21] [22] [23] | Résoudre principalement la génération de spécifications | Intégrez la vérification des spécifications dans la boucle fermée complète de prise de décision du Cloud Brain | | Simulation UTM/UAM | NASA TCL4, CORUS-XUAM, AAM-Gym [38] [39] [40] | L’orchestration des outils d’agent LLM n’est généralement pas étudiée | Prise en charge de CloudBrain-Bench avec les concepts et scénarios UTM/UAM |

5. Cadre de travail associé

5.1 LLM pour le transport

TrafficGPT explique que LLM peut être utilisé comme entrée d’interaction et de traitement pour les modèles de base du trafic, mais souligne également que les données numériques de trafic, la simulation et l’interaction du modèle ne peuvent pas être générées uniquement par du texte brut [9]. Des revues récentes des ITS placent davantage le LLM dans les interfaces sémantiques du trafic, les aides à la décision et la compréhension des données multi-sources [13] [14]. UrbanGPT et UniST représentent l’orientation du modèle de base de l’espace-temps urbain et conviennent pour soutenir la compréhension de l’état urbain, mais ce ne sont pas des chaînes d’outils d’exploitation d’UAV à basse altitude [15] [16].### 5.2 Agents LLM et utilisation des outils

ReAct entrelace trace de raisonnement et action et constitue la base de la boucle d’agent dans cet article [6]. Toolformer et ToolLLM prouvent que LLM peut apprendre l’utilisation des API/outils, mais ils ne résolvent pas les problèmes de vérification de la sécurité routière à basse altitude et d’exécutabilité des missions [7][17]. MCP et OpenAI Agents SDK fournissent une méthode de connexion d’outils plus standard, qui permet de transformer le planificateur, le planificateur, le vérificateur et le simulateur en outils remplaçables [18] [19].

Après le deuxième cycle de recherche, les travaux connexes devraient également ajouter le système d’évaluation des agents : AgentBench est un benchmark LLM-as-agent multi-environnements [34] ; BFCL évalue spécifiquement l’appel de fonction et la détection de pertinence [35] ; -bench utilise plusieurs cycles d’interaction utilisateur-agent-outil et pass^k pour évaluer la fiabilité [36] ; ToolSandbox met l’accent sur l’état d’exécution de l’outil, les dépendances implicites et les scénarios d’informations insuffisantes [37]. Le protocole d’évaluation G1 devrait intégrer ces idées mais changer l’environnement en un cerveau nuageux de trafic à basse altitude.

5.3 Planification LLM et vérification formelle

LLM+P et PlanBench montrent que le LLM seul n’est pas fiable pour la planification et doit être combiné avec des planificateurs externes, des représentations formelles et des protocoles d’évaluation [8] [20]. Lang2LTL, LTLCodeGen et ConformalNL2LTL illustrent que la traduction du langage naturel en logique temporelle se développe, mais ils se concentrent principalement sur la génération de spécifications et une couverture incomplète de la planification, du routage, de la simulation et des boucles fermées des risques dans le cerveau des nuages ​​​​de trafic à basse altitude [21] [22] [23]. Spot et RTAMT peuvent être utilisés respectivement comme outils de vérification LTL/STL [24] [25].

5.4 Données de drone, UTM et simulationLa FAA UTM définit la gestion du trafic des drones à basse altitude comme une écologie collaborative qui prend en charge la planification des vols, les autorisations, la surveillance et la gestion des conflits [26]. Les cartes des installations UAS de la FAA fournissent une référence d’altitude qui peut être rapidement approuvée pour les opérations de la partie 107 dans l’espace aérien contrôlé et conviennent aux proxy des règles de l’espace aérien [27]. OSM/Overpass, les données NYC TLC OD, SUMO, AirSim et Flightmare peuvent conjointement prendre en charge le benchmark synthétique-réel [28] [29] [30] [31] [32].

Pour améliorer la crédibilité du trafic à basse altitude, G1 devrait en outre citer les tests en vol TCL4 Nevada de la NASA : ce test comprend des scénarios de BVLOS, de canyon urbain, de front météorologique, d’intervention d’urgence de concert et de problèmes CNS, et convient comme source pour la taxonomie des scénarios et les discussions sur la qualité des informations sur les systèmes humains [38]. Le CORUS-XUAM européen fournit un concept opérationnel U-space/UAM, des modèles de service U3/U4, une coordination ATM-U-space, un guidage de vertiport et des preuves humaines dans la boucle [39]. AAM-Gym peut être utilisé comme contrôle de simulation pour un banc d’essai avancé d’IA en mobilité aérienne, en particulier l’assurance de séparation des couloirs [40].

6. Formulation du problème

6.1 État du système

Au moment de décision discret , le cerveau du nuage de trafic à basse altitude reçoit l’état du système :

Parmi eux :-  : Une collection de drones. Chaque drone a une position, une puissance, une charge, une vitesse et un statut de mission.

Les instructions en langage naturel sont notées . Le but est de générer des décisions exécutables :

Où est LowAltitudeIR, est la séquence d’appel de l’outil, est la décision de planification/chemin/risque et est l’explication.

6.2 Cibles exécutables sécurisées

Une décision est considérée comme réussie si et seulement si :

  1. Validité du schéma : satisfait la contrainte de type LowAltitudeIR.
  2. Exécutabilité de l’outil : tous les paramètres d’appel de l’outil sont légaux et renvoient des résultats sans erreur.
  3. Faisabilité de la planification : la planification et la planification des itinéraires sont exécutables.
  4. Sécurité temporelle : spécifications LTL/STL vérifiées.
  5. Robuste de la simulation : ne déclenche pas de collisions, de violations de zones d’exclusion aérienne ou de violations de délais dans les graines de scénario spécifiées.
  6. Interprétabilité humaine : L’interprétation n’implique pas d’entités, d’outils ou de règles inexistants.

officiel:$$ \text{Succès}(\pi_t) = \mathbb{1}[ V_\text{schéma}(z_t) \land V_\text{tool}(a_{1:k}) \land V_\text{plan}(y_t) \land V_\text{logique}(y_t) \land V_\text{sim}(y_t) ]

You can't use 'macro parameter character #' in math mode ### 6.3 Ce que cet article ne fait pas - Empêcher LLM de produire directement des variables de contrôle de bas niveau. - Peut être déployé directement sans revendiquer un espace aérien réel. - Ne déguisez pas les données synthétiques en données opérationnelles réelles. - Ne formez pas le modèle de base du trafic à basse altitude à partir de zéro. --- ## 7. Méthode : CloudBrain-Agent ### 7.1 Architecture globale ```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 `LowAltitudeIR` est la clé du document. Elle est plus stricte que la sortie JSON normale et doit pouvoir connecter des outils et des validateurs. ```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" } ``` Contraintes au niveau du champ : | Champs | Types | Contraintes | |------|------|------| | `intention` | énumération | livraison / patrouille / inspection / urgence / retour / charge | | `priorité` | énumération | faible / normal / élevé / critique | | `entités` | objet | Doit faire référence à une entité qui existe dans l'état de la carte ou du drone | | `contraintes` | objet | doit pouvoir être traduit en entrée du planificateur/vérificateur | | `outil_plan` | liste | Le nom de l'outil doit provenir du registre et les paramètres doivent être conformes au schéma | | `fallback_policy` | énumération | Déclenché en cas d'inaccessibilité, de danger, de délai d'attente | ### 7.2.1 Spécifications détaillées du champ LowAltitudeIR v0.1 Dans la première version, ne concevez pas l'IR trop grand, mais assurez-vous que chaque champ peut être consommé par des outils, évalué par des indicateurs, analysé et attribué par des erreurs. Il est recommandé de diviser l'IR en 9 champs de niveau supérieur :| Champs de niveau supérieur | Obligatoire | Tapez | Descriptif | Mesures que l'échec affectera | |--------------|------|------|------|------------------| | `id_tâche` | Oui | chaîne | ID de tâche unique dans l'ensemble de données | traçabilité | | `intention` | Oui | énumération | Intention de la tâche : livraison, inspection, patrouille, urgence, retour, charge, surveillance | Champ IR F1 | | `priorité` | oui | énumération | faible, normal, élevé, critique | conformité aux politiques | | `entités` | Oui | objet | origine, destination, candidats_uavs, zones sensibles, points de transfert | taux d'hallucinations | | `contraintes` | Oui | objet | Temps, altitude, distance, batterie, zone d'exclusion aérienne, capacité, risque météo | taux d'infractions à la sécurité | | `outil_plan` | Oui | liste | Plan linéarisé pour l'appel d'outil DAG | précision d'appel d'outil | | `verification_specs` | oui | objet | Spécifications LTL/STL et règles de langage naturel interprétables | taux de décision vérifié | | `fallback_policy` | oui | énumération | ground_transfer, attendre, human_confirm, safe_refusal | précision du refus en toute sécurité | | `explication_plan` | non | objet | résultats de l'outil et contraintes qui doivent être référencées dans l'explication | score de confiance humaine | Les recommandations relatives aux champs d'entité sont spécifiques à :| Champs | Exemples | Méthodes de vérification | |------|------|----------| | `origine` | `hôpital_A` | Doit exister dans `city_state.entities` | | `destination` | `accident_site_3` | Doit exister dans la tâche ou la carte | | `candidat_uavs` | `["uav_03", "uav_07"]` | Doit exister dans `uav_state` et le statut est disponible | | `éviter_zones` | `["school_zone_2", "nfz_temp_1"]` | Doit exister dans l'espace aérien/la carte | | `handoff_points` | `["station_métro_4"]` | Requis pour le repli multimodal | Les recommandations de champs de contraintes sont spécifiques à : | Champ | Unité | Par défaut | Descriptif | |------|------|------|------| | `deadline_sec` | deuxième | nul | Vide s'il n'y a pas de date limite | | `altitude_min_m` | mètre | 30 | Altitude minimale de vol | | `altitude_max_m` | mètre | 120 | Altitude maximale, soumise au proxy de l'espace aérien | | `min_séparation_m` | mètre | 10 | Distance minimale aux obstacles/drone/zone sensible | | `rapport_de_réserve_batterie` | rapport | 0,2 | Taux de batterie restant minimum après l'arrivée | | `max_risk_level` | énumération | moyen | faible, moyen, élevé | | `corridor_capacity_required` | entier | 1 | Capacité minimale occupée par couloir | ### 7.2.2 Séquence de vérification LowAltitudeIR La vérification IR doit être hiérarchique pour faciliter l'analyse des erreurs :1. **Validité JSON** : indique s'il peut être analysé en JSON. 2. **Validité du schéma** : indique si le type de champ, l'énumération et les champs obligatoires sont corrects. 3. **Entity grounding** : indique si toutes les entités existent dans l'état actuel. 4. **Constraint grounding** : indique si les contraintes peuvent être converties en paramètres de planificateur/vérificateur. 5. **Dépendance de l'outil** : indique si l'entrée de l'outil dépend de la sortie de l'outil précédente. 6. **Compatibilité des politiques** : si la priorité, le repli et la confirmation humaine sont conformes aux règles. Chaque niveau de défaillance doit être écrit dans `error_type`, par exemple : ```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 Registre d'outils La première version de l'outil doit être transformée en fonction Python, puis intégrée à un serveur MCP. L'avantage de MCP est l'interface outils/contexte standardisée, qui permet à différents modèles et environnements d'exécution d'agent de réutiliser le même ensemble d'outils [18] [19].| Outil | Obligatoire | Entrée | Sortie | Type de panne | |------|------|------|------|--------------| | `query_city_state` | Oui | région, heure | POI, bâtiments, graphique au sol | région_inconnue | | `query_airspace` | Oui | région, altitude, heure | couloir, NFZ, plafond | espace_air_restreint | | `assign_uav` | oui | tâche, états du drone | drone sélectionné / aucun | no_available_uav | | `plan_route` | oui | début, objectif, contraintes | chemin / inaccessible | no_path | | `verify_ltl_stl` | oui | chemin, spécifications temporelles | réussite/échec/contre-exemple | spécification_violation | | `simulate_scenario` | Oui | décision, graine de scénario | succès/risque/collision | sim_failure | | `risk_assess` | oui | décision, état | score de risque, raisons | risque_élevé | | `explain_decision` | Facultatif | trace de décision | explication | explication_hallucinée | ### 7.3.1 Contrat API de l'outil Tous les outils reviennent uniformément : ```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" } } ``` En cas d'échec : ```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"] } } ``` Entrées et sorties d'outils spécifiques :| Outil | Champs de saisie clés | Champs de sortie clés | Pannes récupérables | Pannes irrécupérables | |------|--------------|--------------|------------|--------------| | `query_city_state` | `region_id`, `bbox`, `time` | `pois`, `bâtiments`, `routes`, `zones_sensibles` | `partial_map` | `région_inconnue` | | `query_airspace` | `bbox`, `altitude_range`, `time` | `couloirs`, `nfz`, `capacité`, `plafond` | `capacité_faible` | `espace aérien_restreint` | | `assign_uav` | `tâche`, `uav_states`, `objectif` | `uav_id`, `assignment_score`, `reason` | `low_battery_candidates` | `no_available_uav` | | `plan_route` | `start`, `goal`, `eviter`, `altitude_range` | `waypoints`, `length_m`, `eta_sec`, `energy_est` | `deadline_risk` | `aucun_chemin` | | `verify_ltl_stl` | `trajectoire`, `spécifications` | `réussite`, `violations`, `robustesse`, `contre-exemple` | `robustesse_négative` | `invalid_spec` | | `simulate_scenario` | `décision`, `scenario_seed`, `stress_level` | `succès`, `événements`, `min_distance`, `délai`, `risque` | `pres_miss' | `collision` | | `risk_assess` | `décision`, `météo`, `trafic`, `historique` | `risk_score`, `risk_level`, `top_reasons` | `risque_moyen` | `high_risk_no_override` |### 7.3.2 DAG de dépendance aux outils Les appels d'outils ne sont pas des séquences arbitraires et doivent satisfaire les dépendances : ```text query_city_state -> query_airspace -> assign_uav -> plan_route -> verify_ltl_stl -> simulate_scenario -> risk_assess -> explain_decision ``` Situations qui peuvent être ignorées : - `simulate_scenario` peut être désactivé dans dev-mini, mais doit être activé pour l'expérience principale. - `risk_assess` peut être fusionné dans `simulate_scenario`, mais les métriques papier sont toujours rapportées séparément. - `explain_decision` n'affecte pas la réussite de la tâche, mais affecte la confiance humaine et les hallucinations. ### 7.3.3 Version d'implémentation minimale Dans la première version, chaque outil peut être déterministe : | Outil | Algorithme minimal | Version complexe | |------|----------|--------------| | `query_city_state` | Lire des entités à partir de JSON/GeoJSON | Requête dynamique OSM/Overture | | `query_airspace` | Modèle de règle + intersection de polygones | Simulation de services UTM/U-space | | `assign_uav` | gourmand min ETA avec filtre batterie | Planificateur MILP / Lyapunov | | `plan_route` | Grille 3D A* | RRT* / MPC-lite | | `verify_ltl_stl` | Règles manuscrites + RTAMT/Spot | Moniteur logique temporel complet | | `simulate_scenario` | cinématique à temps discret | AirSim/Flightmare | | `risk_assess` | score de règle pondéré | modèle de risque appris | ### 7.4 Réparation guidée par vérification La clé de CloudBrain-Agent n'est pas de le générer une seule fois, mais de réparer la boucle fermée : ```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 ``` Les contre-exemples doivent être structurés et pas seulement « échoués ». Par exemple : ```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 Mémoire de sécurité La mémoire de sécurité enregistre trois types d'informations : 1. **Modèles dangereux connus** : Par exemple, batterie faible + vitesse du vent élevée + délai serré. 2. **Cas de réparation** : échec de l'IR, contre-exemple, réparation réussie de l'IR. 3. **Interventions humaines** : confirmation manuelle, rejet et réaffectation. Le premier article ne nécessite pas de mémoire complexe à long terme et n'a besoin que d'implémenter la récupération : étant donné la tâche en cours, récupérer des cas de défaillance similaires dans un contexte de réparation en quelques coups. ### 7.6 Pseudocode de l'algorithme Il est recommandé de mettre un algorithme simplifié dans le texte principal de l'article et la version complète en annexe. ```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 Attentes en matière de complexité et de temps d'exécution Supposons que la taille de la grille de la carte soit $G = X \times Y \times Z$, le nombre de drones candidats est $|\mathcal{U}|$ et le nombre de tours d'appel d'outils est $K$. | Module | Principale complexité | Méthodes d'optimisation | |------|------------|--------------| | Génération IR | $O(K \cdot C_\text{LLM})$ | Invite de cache, retour court, basse température | | Mission de drone | $O(|\mathcal{U}|)$ gourmand | Le pré-filtrage n'est pas disponible UAV | | 3D A* | $O(G \log G)$ | masque de couloir, grille hiérarchique, heuristique | | Surveillance STL | $O(T \cdot |\Phi|)$ | Contrôle de trajectoire vectorisé | | Simulations | $O(T \cdot N_\text{agents})$ | Semences en lots, arrêt anticipé | | Récupération | $O(\log M)$ approximatif | FAISS/Qdrant | Le premier article n’a pas besoin de rechercher des performances extrêmes en temps réel, mais il doit rendre compte de la latence de bout en bout. Objectifs suggérés :- dev-mini : tâche unique 5 à 20 secondes ; - Local 14B : tâche unique 10-40 secondes ; - Limite supérieure de l'API : 5 à 30 secondes pour une seule tâche ; - Évaluation par lots : asynchrone et simultanée, mais chaque échantillon enregistre une latence indépendante. --- ## 8. Sources de données et build CloudBrain-Bench ### 8.1 Composition des données Il est recommandé d'appeler le premier ensemble de données principal **CloudBrain-Bench**.| Couche de données | Source | Si l'expérience principale dépend de | Fonction | |--------|------|----------------|------| | Grille urbaine synthétique | Généré procéduralement | Oui | Contrôlable, reproductible, évolutif | | Contexte de la ville OSM | OSM / Passage supérieur | Oui | Dénomination des POI, routes, bâtiments, zones fonctionnelles | | Contexte des cartes d'ouverture | Lieux d'ouverture / Bâtiments / Transports | Améliorations facultatives | POI, bâtiments, topologie routière et identifiants d'entité stables de haute qualité | | Grilles d'espace aérien réelles | Polygones de la carte des installations FAA UAS + dictionnaire de données UAS | Oui | Géométrie UASFM réelle, plafond, champs espace aérien/aéroport/LAANC | | Proxy de demande OD | Taxi NYC TLC / Chicago En option | Facultatif | Générer des points chauds de demande et des tâches de pointe | | Trafic terrestre | SUMÉ | Amélioration facultative | Temps de trajet de repli au sol | | Météo aéronautique | API de données météorologiques aéronautiques de la NOAA METAR + Open-Meteo | Améliorations facultatives | Météo réelle de l'aviation, vitesse du vent, visibilité, précipitations et risques météorologiques | | Télémétrie de vol réelle d'un drone | Ensemble de données de vol de livraison de colis DJI Matrice 100 | Étalonnage en option | Consommation d'énergie/étalonnage ETA pour la position, le courant, la tension, le vent, la vitesse, la charge, l'altitude | | Contexte des tests en vol UTM | Rapports TCL4 de la NASA | Améliorations facultatives | Canyon urbain, BVLOS, front météorologique, taxonomie des scénarios d'intervention d'urgence | | Dynamique des drones | Simulateur léger auto-construit | Oui | Trajet, consommation d'énergie, collision, retard | | Visuelssimulateur | AirSim/Flightmare | Suppléments optionnels | Extensions visuelles/dynamiques ultérieures |OSM/Overpass convient à l'interrogation de caractéristiques urbaines [28] ; Overture Maps fournit des couches de lieux, de bâtiments et de transports via GeoParquet, qui peuvent compléter la topologie des POI, des bâtiments et des routes [41]. La couche d'espace aérien ne doit pas simplement être écrite comme un proxy abstrait : la page officielle FAA UAS Facility Maps fournit la saisie de données UASFM pour les fournisseurs de données. Le dictionnaire de données clarifie des champs tels que la géométrie, la latitude/longitude du centre, le « PLAFOND », la classe d'espace aérien, les identifiants d'aéroport et l'état de préparation du LAANC [27] [43]. La couche météo peut utiliser l'API NOAA Aviation Weather Data pour extraire des observations météorologiques aéronautiques telles que METAR, puis utiliser Open-Meteo pour compléter les fonctionnalités météorologiques historiques/de grille [42] [44]. La véritable couche dynamique du drone peut utiliser les données de vol de livraison de petits colis DJI Matrice 100 publiées par Scientific Data ; ces données contiennent des centaines de changements de position en vol, de consommation d'énergie, de vent, de charge, d'altitude et de vitesse, qui peuvent être utilisés pour calibrer la consommation d'énergie et l'ETA au lieu de spécifier le modèle de batterie à partir de rien [45]. NYC TLC et SUMO ne servent toujours que de proxy de demande et de repli au sol [29] [30] ; AirSim et Flightmare complètent la simulation en boucle fermée [31] [32]. ### 8.1.1 Jugement de faisabilité des données réelles La conclusion après la deuxième recherche n'est pas qu'"il n'y a pas de données réelles", mais que **les données réelles existent à différents niveaux, et il y a un manque de boucle fermée publique et complète d'opérations commerciales à basse altitude**.| Problèmes de données | 2026-05-21 Disponibilité publique | Moyens pouvant être utilisés pour G1 | Ce qui ne peut être réclamé | |----------|---------------------------|------------------|----------------| | Plan de la ville/POI/Bâtiments/Routes | Élevé | OSM/Ouverture Contexte de la ville réelle | Pas égal au véritable couloir de drones | | Grille d'altitude de l'espace aérien UAS | Élevé | Polygone UASFM de la FAA, plafond, champs d'espace aérien/LAANC | L'UASFM n'équivaut pas à une autorisation de vol | | Météorologie aéronautique | Élevé | NOAA METAR, caractéristiques du vent et de la pluie Open-Meteo | La météo à l'aéroport n'est pas égale aux champs de vent à basse altitude au niveau des blocs | | Consommation/position d'énergie réelle du vol du drone | Moyen | Télémétrie de livraison DJI M100 calibrée consommation d'énergie et ETA | Différent de 100 programmes d'opérations réels | | Scénarios de vol d'essai UTM et flux d'informations homme-machine | Moyen | Taxonomie des scénarios NASA TCL4 et exigences en matière d'informations UTM | Les rapports ne sont pas égaux aux trajectoires brutes publiques de la flotte UTM | | Journal de suivi/flux des commandes de livraison commerciale | Faible | Utiliser uniquement l'expérience opérationnelle et la motivation de la FAA pour une coopération future | Impossible de forger les pistes de commande Zipline/Wing/Flytrex | | L'identification à distance expose les trajectoires en temps réel à grande échelle | Faible | Non utilisé comme source de données principale | L'identification à distance ne peut pas être utilisée comme flotte d'ensembles de données publiques prêtes à l'emploi | La page FAA Part 135 indique que les États-Unis disposent déjà de voies d'approbation et d'entités opérationnelles approuvées pour les opérations de livraison de colis par drones, la question de recherche n'est donc pas purement hypothétique [46]. Cependant, les flux d'ordres opérationnels publics, les enregistrements de conflits dans l'espace aérien et les journaux de vols commerciaux ne sont généralement pas publiés avec la page d'approbation. L’identification à distance ne doit pas non plus être traitée comme une bibliothèque de trajectoires open source prête à l’emploi : le GAO recommandait toujours en 2024 que la FAA identifie les voies qui fournissent des données de localisation/statut des drones en réseau et en temps réel [47]. Par conséquent, l’énoncé fort de G1 devrait être :> Nous construisons une référence d'agents à basse altitude calibrée en contexte réel et en vol réel, tout en laissant les journaux opérationnels de la flotte entièrement réels à la future collaboration des opérateurs. ### 8.1.2 Stratégie de hiérarchisation des données CloudBrain-Bench recommande de le diviser en trois niveaux de confiance : | Hiérarchie | Nom | Composition des données | Rôle dans le journal | |------|------|----------|----------------| | L1 | `Contrôlé par synthèse` | Ville du programme, espace aérien du programme, tâche du programme | Contraste maître contrôlable, ablation, stabilité statistique | | L2 | `Contexte réel` | OSM/Overture + FAA UASFM + NOAA/Open-Meteo + tâches du programme | Couche prioritaire d'expérimentation principale, prouvant un véritable ancrage contextuel | | L3 | « Calibré en vol réel » | Consommation d'énergie de vol L2 + DJI M100/étalonnage des paramètres ETA | Analyse d'étalonnage et vérification de la sensibilité en vol réel | Il n’est pas recommandé d’écrire L3 comme « véritable benchmark opérationnel ». Une méthode de démontage plus stable est la suivante : - **Tâches et trace d'or** : toujours générés par un générateur déterministe, un planificateur, un vérificateur, garantissant la vraie valeur SAT/UNSAT. - **Contexte Ville/Espace Aérien/Météo** : Aussi réaliste que possible, vérifiez que l'agent s'immobilise sur des entités réelles et des champs d'espace aérien réels. - **Consommation d'énergie/Modèle ETA** : utilisez des données de vol réelles pour ajuster ou calibrer le godet afin de vérifier que les jugements de sécurité ne sont pas basés sur des paramètres de consommation d'énergie arbitraires. ### 8.1.3 Recette d'acquisition de données réelles Afin de rendre le premier article reproductible, il est recommandé d'écrire l'acquisition de données sous forme de pipeline fixe :| Étape | Entrée | Opération | Sortie | |------|------|------|------| | 1 | Boîte englobante de la ville | Utilisez Overpass pour interroger un hôpital, une école, un parc, la police, une caserne de pompiers, un bâtiment, une route | `city_osm.geojson` | | 2 | La même bbox | Utilisez les lieux/bâtiments Overture pour compléter les POI et l'empreinte du bâtiment, tout en conservant un identifiant d'entité stable | `city_overture.parquet` | | 3 | Téléchargement de données FAA UASFM / bbox | Lire le polygone UASFM, les champs « PLAFOND », aéroport/espace aérien/LAANC | `uasfm_cells.geojson` | | 4 | stations OACI les plus proches + fenêtre horaire | Interrogez NOAA METAR JSON et extrayez les jetons de vent, de visibilité, de précipitations/météo | `aviation_weather.parquet` | | 5 | Latitude, longitude et période | Interroger la météo historique/prévisionnelle Open-Meteo en tant que supplément non aéroportuaire | `météo_grid.parquet` | | 6 | Données scientifiques Fichiers DJI M100 | Analyser la position, la tension, le courant, le vent, la charge utile, l'altitude, la vitesse | `uav_flight_calibration.parquet` | | 7 | Villes et dates sélectionnées | Exemple d'OD de taxi NYC TLC / Chicago pour former une carte thermique de la demande | `od_proxy.parquet` | | 8 | Graphique routier OSM | Importer SUMO, estimer le temps de trajet de secours au sol | `ground_time_matrix.parquet` | | 9 | UTM/UASFM/CORUS/NASA TCL4 | ManuelOrganiser les modèles de règles et la taxonomie des scénarios | `airspace_rules.yaml` | | 10 | contexte réel + paramètres drone calibrés | Génération de programmes tâches drones, NFZ, corridor, recharge, risque météo | `cloudbrain_samples.jsonl` | | 11 | échantillons | planificateur/vérificateur/simulateur annote automatiquement SAT/UNSAT, trace d'or, contre-exemple | `cloudbrain_gold.jsonl` |L'expérience principale repose au minimum sur les étapes 1, 3, 9, 10 et 11 ; les étapes 4 à 8 fournissent la météo réelle, l'étalonnage de la consommation d'énergie et le repli au sol. Chaque capture doit enregistrer l'instantané du fichier d'origine, la version du champ de données et la date de téléchargement pour éviter que les modifications ultérieures des données FAA/NOAA/cartes ne provoquent une irréproductibilité. ### 8.1.4 Comment mapper des données réelles à un benchmark | Champs réels | Mapper vers CloudBrain | Utilisation | |----------|-----------|---------------| | OSM `amenity=hôpital/école/fire_station` | `origine`, `destination`, `zones_sensibles` | Mise à la terre de l'entité de commande | | Empreinte du bâtiment d'ouverture | polygones d'obstacles | planificateur/simulateur d'itinéraire | | UASFM `FORME`, `PLAFOND` | cellules de plafond d'altitude | Retour de l'outil `query_airspace` | | Champs aéroport/espace aérien UASFM | provenance de l'espace aérien | Champs d’explication et de politique | | NOAA METAR vent/visibilité/météo | risque météorologique | `risk_assess`, scénarios de stress | | Position/vitesse/altitude M100 | bacs d'étalonnage d'itinéraire/ETA | Distribution ETA | | M100 courant/tension/charge utile/vent | calibrage du modèle énergétique | contrôle de la réserve de batterie | ### 8.1.5 Tâche d'étalonnage en vol réel Utilisez les données DJI M100 pour faire uniquement ce que vous pouvez prendre en charge :1. Divisez-le en compartiments en fonction de la charge utile, de la vitesse de croisière, de l'altitude et du vent. 2. Obtenez un proxy d'énergie de vol ou de consommation d'énergie à partir de l'intégration de tension et de courant. 3. Ajustez `energy_per_meter`, `eta_multiplier` ou une recherche de quantile conservatrice. 4. Cartographiez la longueur de l'itinéraire du planificateur synthétique avec l'estimation de l'énergie et le verdict de la réserve de batterie. 5. Indiquez en annexe si la décision de sécurité change selon les modèles énergétiques calibrés et non calibrés. Il est recommandé que la première version utilise des quantiles conservateurs au lieu de réseaux complexes de consommation d'énergie en boîte noire :

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

You can't use 'macro parameter character #' in math mode Où $e$ représente la consommation d'énergie par unité de distance, $v$ représente la vitesse, $h$ représente la hauteur, $p$ représente la charge et $w$ représente les conditions du vent. De cette manière, des données de vol réelles peuvent être intégrées dans le contrôle de sécurité sans transformer G1 en un document de modélisation de la consommation d'énergie. ### 8.1.6 Conception de répartition des données réelles | Divisé | Couche de données | Fonction | |-------|--------|------| | `test_synthétique_contrôlé` | L1 | Ablation principale, difficulté contrôlable | | `test_real_context_city_a` | L2 | Contexte réel ville/espace aérien/météo | | `test_real_context_city_b` | L2 | généralisation invisible de la ville | | `test_real_weather_stress` | L2 | METAR/Open-Meteo Risque météorologique | | `test_energy_calibrated` | L3 | sécurité batterie/ETA après calibrage en vol réel |Le tableau principal de l'article peut être attribué à la fois à L1 et à L2 ; L3 est recommandé comme tableau ou annexe d’analyse d’étalonnage. Si l'effet L2 est stable, le résumé peut être rédigé sous forme de « benchmark en contexte réel ». Si L3 est également stable, écrivez à nouveau « évaluation calibrée en vol réel ». ### 8.1.7 Esquisse du code d'acquisition de données réelles Ne mélangez pas le chargeur UASFM et METAR dans les outils d'agent. Préparez d'abord les données hors ligne : ```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) ``` Chargeur d'étalonnage de vol réel : ```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 Paramètres de ville et de scène Il est recommandé que la première version fixe 4 types d'aménagement urbain : | Type de ville | Taille de la grille | Caractéristiques des POI | Risque de basse altitude | Utilisation | |----------|----------|----------|---------------|------| | `grid_city` | 50x50x6 | Réseau routier régulier, POI uniforme | Faible | contrôle de santé mentale | | `centre-ville_ville` | 80x80x8 | Haute densité de construction, hôpitaux/écoles intensifs | Élevé | Expérience principale | | `ville_banlieue` | 100 x 100 x 5 | POI clairsemés, longue distance | moyen | batterie/date limite | | `ville_mixte` | 120 x 120 x 10 | Zones commerciales mixtes, zones résidentielles, pôles de transport | Élevé | généralisation invisible | Échelle spatiale :| Paramètres | Par défaut | Gamme | |------|------|------| | taille des cellules | 10 mètres | 5-20 m | | couches d'altitude | 6 | 3-12 | | altitude maximale | 120 m | 60-150 m | | largeur du couloir | 20 mètres | 10-40 m | | zones d'exclusion aérienne | 3-12 par carte | 0-20 | | zones sensibles | 5-30 par carte | 0-50 | | chargeurs | 3-10 par carte | 1-20 | | Nombre de drones | 10/30/50 | 5-100 | Paramètres de la tâche : | Paramètres | Par défaut | Descriptif | |------|------|------| | serrage des délais | moyen | ample / moyen / serré / impossible | | distribution prioritaire | 25/60/10/5 | normal/élevé/critique/faible réglable | | distribution de batteries | de type bêta | Créer des cas extrêmes à batterie faible | | risque météorologique | aucun/faible/moyen/élevé | stress split moyen pour augmenter | | explosion de la demande | 1x/2x/4x | couloir de test et planificateur | ### 8.1.9 Modèle de règle La première version ne comporte que 8 types de règles, ce qui est suffisant pour rédiger un article et peut être reproduit :| ID de règle | Langue naturelle | Vérification LTL/STL/Programme | |---------|----------|------------------| | R1 | Ne pas entrer dans la zone d'exclusion aérienne temporaire | `G not_in_nfz` | | R2 | Maintenez toujours la distance de sécurité minimale | Robustesse STL : `dist_to_obstacle > d_min` | | R3 | L'altitude reste dans la plage autorisée | `G altitude_min <= z <= altitude_max` | | R4 | Arriver avant la date limite | `F[0, date limite] at_goal` | | R5 | Réserver la batterie après le retour/arrivée | vérification du programme | | R6 | la capacité du corridor ne dépasse pas la limite | moniteur de capacité | | R7 | les tâches critiques sont prioritaires mais ne peuvent être annulées sécurité | vérification de la politique | | R8 | Déclenché en cas d'informations insuffisantes ou de refus de sécurité UNSAT/confirmation humaine | chèque de refus | ### 8.1.10 Contrôle de la qualité des données CloudBrain-Bench doit éviter les « balises de spam générées par LLM ». Il est recommandé que chaque échantillon enregistre quatre types de champs de qualité : | Champ | Descriptif | |------|------| | `génération_seed` | Graines aléatoires pour reproduire des expériences | | `source_provenance` | OSM/Ouverture/Modèle de règles/Source de génération de programme | | `label_verifier` | De quel vérificateur provient l'étiquette SAT/UNSAT | | `human_review_status` | non vérifié / sampled_pass / sampled_fail / corrigé | Stratégie d'inspection par échantillonnage : - Cochez au hasard au moins 30 éléments pour chaque type de scénario ; - Vérifiez au hasard au moins 20 éléments pour chaque mode de défaillance ; - Augmenter le taux d'échantillonnage des échantillons de stress et UNSAT à 15 %-20 % ; - Seul le langage naturel et les explications sont modifiés manuellement, et les balises du planificateur/vérificateur ne sont pas modifiées manuellement pour éviter l'introduction de balises subjectives.### 8.2 Format d'échantillon Chaque échantillon comprend : ```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 Type de scène | Scène | Proportion | Difficulté | |------|------|------| | Livraison normale | 15% | Horaires normaux et planification des trajets | | Livraison d'urgence | 15% | priorité, délai, compromis entre risques | | Patrouille / inspection | 10% | Contraintes temporelles de points de cheminement multiples | | Évitement des zones d'exclusion aérienne | 15% | Contraintes de sécurité LTL/STL | | Encombrement des couloirs | 10% | Capacité de l'espace aérien et latence | | Goulot d'étranglement de charge | 10% | Contraintes de puissance et repli | | Risque météo/vent | 10% | Évaluation des risques et rejet | | Repli multimodal | 10% | Transfert drone-sol | | UNSAT / tâches ambiguës | 5% | Rejets et clarifications en toute sécurité | ### 8.4 Échelle des données Echelle réalisable de la première version : | Divisé | Nombre d'échantillons | Objectif | |-------|--------|------| | Dév-mini | 200 | Pipeline de débogage rapide | | En forme de train | 3000 | quelques tirs, RAG, mémoire de réparation, non utilisé pour l'entraînement principal | | Validation | 1000 | sélection d'invite/modèle | | Test-vu-ville | 1000 | Essai principal | | Ville-invisible-test | 1000 | Généralisation | | Test-stress | 1000 | Test de stress sur une scène dangereuse | Il y a environ 7 200 échantillons au total, ce qui est suffisant pour étayer le premier document de référence/méthode. Les réglages ultérieurs du G2 seront étendus à 50 000 à 100 000 traces d'outils. ### 8.5 Génération d'étiquettes Goldl’or ne devrait pas être entièrement généré par LLM. Processus recommandé : 1. Générez de manière procédurale des villes, des missions, le statut et les règles du drone. 2. Le modèle de règle génère de l'or `LowAltitudeIR`. 3. Appelez des outils déterministes pour obtenir la trace de l'outil Gold. 4. Le planificateur/vérificateur/simulateur détermine SAT/UNSAT. 5. L'enseignant de LLM n'est responsable que de la paraphrase en langage naturel et d'une petite quantité de texte explicatif. 6. Échantillonnage de 5 à 10 % pour une inspection manuelle, en se concentrant sur les échantillons à haut risque et UNSAT. ### 8.6 Organisation des fichiers de données Il est recommandé que l'expérience finale open source ou de reproduction interne utilise la structure suivante : ```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 Les statistiques doivent être déclarées Le tableau papier 2 rapporte au moins : | Éléments statistiques | Doit signaler | |--------|----------| | Nombre total d'échantillons | total / par fractionnement | | Répartition des types de scénarios | Type de scénario 9 catégories | | Rapport SAT/UNSAT | global + par scénario | | Nombre de villes | vu / invisible | | Niveau de données | Nombre et proportion d'échantillons L1/L2/L3 | | Couverture du champ contextuel réel | Couverture des instantanés OSM/Overture/UASFM/NOAA/Open-Meteo | | Répartition des numéros de drones | min / médiane / max | | Nombre de contraintes | Nombre moyen de contraintes par tâche | | longueur d'appel de l'outil | longueur moyenne des traces d'or | | Répartition des types de défaillance | no_path/nfz/battery/deadline/ambiguity | | Taux d'échantillonnage manuel | réussite / corrigé | --- ## 9. Sélection du modèle et plan de déploiement ### 9.1 Le premier article ne recommande pas de former d'abord un grand modèle vertical L'axe principal de G1 est la méthode agent et la vérification en boucle fermée. La formation du modèle vertical est placée dans le G2 ultérieur. G1 peut contenir une pré-expérience SFT légère, mais elle ne devrait pas être essentielle au succès ou à l'échec de l'article. ### 9.2 Matrice de modèle recommandée| Rôle | Modèle | Utilisation | Obligatoire | |------|------|------|--------------| | Enseignant / limite supérieure | GPT-5.2 ou API équivalente | Générer des données, renforcer la base de référence, analyser les erreurs | Oui | | Modèle principal local | Qwen3-14B / Qwen3-32B | Agent reproductible de l'expérience principale | Oui | | Modèle de raisonnement local | DeepSeek-R1-Distill-Qwen-14B/32B | réparation, raisonnement contre-exemple | Oui | | Modèle à petite latence | Qwen3-8B | Ablation à faible latence | Facultatif | | Intégration | Qwen3-Intégration / BGE-M3 | RAG et récupération de mémoire de sécurité | Oui | GPT-5.2 est officiellement positionné comme adapté aux tâches de codage et d'agent, et peut être utilisé comme un enseignant puissant et une limite supérieure de source fermée [10]. Le rapport technique Qwen3 met l'accent sur le raisonnement, le suivi des instructions, les capacités d'agent et multilingues, et convient comme modèle principal open source local [11]. DeepSeek-R1 fournit des modèles de raisonnement 14B/32B distillés en Qwen/Llama, qui conviennent à la réparation de contre-exemples [12]. ### 9.3 Local ou API **Architecture hybride** recommandée : | Scène | API | Locale | |------|-----|------| | Semaine 1-2 | Invite de vérification rapide, schéma, conception d'outils | Déploiement synchrone Qwen3-14B | | Semaine 3-5 | enseignant génère des paraphrases et des échantillons difficiles | développement/validation de l'exécution principale | | Semaine 6-8 | Faire la ligne de base de la limite supérieure | Expérience principale et résultats reproductibles | | Avant la soumission | Analyse des erreurs mineures | Toutes les expériences de base sont reproductibles localement |Le tableau principal de l'article recommande d'utiliser le modèle local comme modèle principal et le modèle API comme limite supérieure. Cela a non seulement un effet important, mais évite également aux critiques de se demander si cela peut être reproduit. ### 9.4 Mise en œuvre rapide du traitement Recommandations de déploiement : ```text vLLM server -> OpenAI-compatible endpoint -> Agent runtime -> Tool registry / MCP servers -> verifier / simulator ``` vLLM fournit un serveur compatible OpenAI, qui permet aux modèles Qwen/DeepSeek et API locaux de partager une interface d'appel [33]. ### 9.5 Configuration des invites et des inférences Pour garantir la reproductibilité, tous les modèles doivent avoir des paramètres d'inférence fixes : | objectif | température | top_p | jetons maximum | réparation K | descriptif | |------|-------------|-------|------------|----------|------| | LLM direct | 0,2 | 0,9 | 2048 | 0 | Décision de sortie directe | | JSON uniquement | 0,0 | 1.0 | 2048 | 0 | Sortie structurée pour réduire le caractère aléatoire | | Réagir | 0,2 | 0,9 | 4096 | 0 | Autoriser le raisonnement/l'action | | CloudBrain pas de réparation | 0,0 | 1.0 | 4096 | 0 | IR unique + outils | | CloudBrain plein | 0,0 d'abord, 0,2 réparation | 1.0 | 4096 | 3 | La roue de réparation peut être légèrement desserrée | Il est recommandé de diviser l'invite en quatre sections : 1. **Rôle système** : Vous êtes l'agent cérébral du nuage de trafic à basse altitude et ne produisez pas directement les quantités de contrôle. 2. **Schéma IR** : donnez le schéma et l'énumération JSON `LowAltitudeIR`. 3. **Registre d'outils** : répertorie les outils disponibles, les entrées et sorties, ainsi que les types de pannes. 4. **Tâche/état actuel** : tâche actuelle en langage naturel, statut du drone, carte, règles de l'espace aérien et commentaires historiques. Le format de sortie doit être fixe : ```json { "low_altitude_ir": {}, "rationale_summary": "one paragraph only", "uncertainty": { "needs_human_confirmation": false, "missing_information": [] } } ```Ne laissez pas les résultats du modèle suivre une chaîne de réflexion complète ; les documents et les systèmes n'enregistrent que de courts résumés de justification, les trajectoires des outils et les commentaires des vérificateurs. ### 9.6 API et enregistrement des coûts locaux Enregistrez chaque expérience : | Champ | Descriptif | |------|------| | `nom_modèle` | Nom de l'API ou du modèle local | | `endpoint_type` | api/local_vllm | | `prompt_tokens` | Entrez le jeton | | `complétion_tokens` | Jetons de sortie | | `wall_time_sec` | Temps de bout en bout | | `llm_time_sec` | Heure d'appel LLM | | `tool_time_sec` | Temps d'exécution de l'outil | | `repair_rounds` | Nombre de tournées de réparation | | `estimated_cost_usd` | Coût estimé de l'API, le local peut être rempli avec 0 ou GPU-heure | Cela conforte l’analyse de déploiement du tableau 5. --- ## 10. Lignes de base ### 10.1, référence principale| Référence | Descriptif | Questions auxquelles répondre | |--------------|------|--------------| | LLM direct | Le modèle génère directement le texte de décision | À quel point LLM nu est-il peu fiable | | LLM JSON uniquement | Nécessite uniquement la sortie de JSON IR, aucun outil pour l'exécution | La sortie tapée est-elle suffisante | | Invite ReAct | Invocation de l'outil de style ReAct, pas de schéma/vérificateur | La boucle raisonnement-action est-elle suffisante | | Utilisation d'outils uniquement | Il y a un appel d'outil, mais aucune réparation de vérification | L'outil est-il suffisant | | Appel de fonction de style BFCL | Évalue uniquement si le nom de la fonction et les paramètres sont corrects et n'effectue pas de vérification physique | Le succès de l'appel de fonction est-il égal au succès du cerveau cloud | | Agent politique de type banc Tau | Dispose d'outils et de règles politiques, mais pas de planificateur/vérificateur d'UAV | La politique de domaine est-elle suffisante | | Agent d'outil avec état de style ToolSandbox | Exécution d'outils avec état et gestion des déficiences d'informations | La contribution de l'exécution d'outils avec état aux tâches à basse altitude | | Style LLM+P | Le LLM se transforme en problème de planification et le planificateur le résout | Dans quelle mesure le planificateur externe peut-il résoudre | | Style TrafficGPT | LLM appelle les véhicules, pas de sécurité formelle des drones | Base de référence pour l'orchestration LLM du trafic | | CloudBrain-Agent sans simulateur | Supprimer les tests de résistance par simulation | contribution aux retours d'expérience du simulateur | | CloudBrain-Agent sans réparation | Arrêt en cas d'échec | contribution à la boucle de réparation | | CloudBrain-Agent complet | Méthode complète | Méthode principale de cet article | ### 10.2 Référence du modèle| Modèle | Paramètres | |-------|------| | GPT-5.2 | Limite supérieure de l'API | | Qwen3-14B | principale locale | | Qwen3-32B | local plus fort | | DeepSeek-R1-Distill-Qwen-14B | raisonnement de réparation locale | | Qwen3-8B | petit local | ### 10.3 Détails de mise en œuvre de base Afin d'éviter que les références ne soient considérées comme injustes par les évaluateurs, chaque référence doit clairement saisir les autorisations : | Référence | Langage naturel visible | Statut visible | Outils appelables | Commentaires visibles du vérificateur | Réparable | |--------------|--------------|---------|------------|------------------------|--------| | LLM direct | Oui | Statut récapitulatif | Non | Non | Non | | JSON uniquement | Oui | Statut complet | Non | Non | Non | | Réagir | Oui | Statut complet | Oui | Erreur d'outil sans contre-exemple | Non | | Utilisation d'outils uniquement | Oui | Statut complet | Oui | Erreur d'outil | Non | | Style LLM+P | Oui | Statut complet | planificateur | résultat du planificateur | Non | | CloudBrain sans vérificateur | oui | statut complet | oui | non | non | | CloudBrain sans simulateur | oui | statut complet | oui | vérificateur uniquement | oui | | CloudBrain plein | oui | statut complet | oui | vérificateur + simulateur | oui | Principe d'équité :- Toutes les méthodes utilisent le même modèle de base ; - Utiliser la même répartition de tests pour toutes les méthodes ; - Toutes les méthodes ont le même budget de jetons maximum ; - Le nombre maximum d'appels d'outils pour ReAct et CloudBrain est le même ; - Seul CloudBrain full utilise un contre-exemple structuré puisque c'est la contribution de cet article. --- ## 11. Conception expérimentale ### 11.1 Expérience 1 : Principaux résultats Question : CloudBrain-Agent full est-il meilleur que LLM direct, ReAct, utilisation d'outils uniquement et LLM+P ? Données : Test-vu-ville, Test-invisible-ville, Test-stress. Indicateurs : -Taux de réussite des tâches -Taux de décision exécutable - Taux de violation de la sécurité -Précision de l'appel d'outil - Taux d'hallucinations - Taux de réussite des réparations -Latence ### 11.2 Expérience 2 : Expérience d'ablation | Ablation | Suppression de contenu | Impact attendu | |----------|----------|---------------| | pas d'IR tapé | Appel à l'outil de texte gratuit | la précision de l'appel d'outil a diminué | | pas de vérificateur | Pas de contrôles LTL/STL | violation de la sécurité en hausse | | pas de simulateur | Pas de test de stress sur scène | diminution du passage du stress | | pas de réparation | Aucune itération après l'échec de la vérification | diminution du taux exécutable | | pas de mémoire | Ne pas récupérer les cas d'échec historiques | le succès des réparations a diminué | | pas de chiffon | Ne pas récupérer les règles/le contexte de la carte | montée des hallucinations | ### 11.3 Expérience 3 : analyse de réparation par contre-exemple Chemin de réparation après une défaillance du vérificateur/simulateur statistique :- Taux de réussite de la première réparation - 2ème taux de réussite des réparations - 3ème taux de réussite des réparations - Nouveau taux de violation après réparation - Les types de pannes les plus courants : NFZ, date limite, batterie, couloir, hallucination d'entité ### 11.4 Expérience 4 : Analyse du modèle et du déploiement Comparez l'API aux modèles natifs : | Modèle | Indicateurs | |------|------| | GPT-5.2 | Effets plafond, coûts, retards | | Qwen3-14B | Principaux résultats reproductibles localement | | Qwen3-32B | Modèle local fort | | DeepSeek-R1-Distill-Qwen-14B | réparer la capacité spéciale | | Qwen3-8B | Compromis de faible latence | ### 11.5 Expérience 5 : Généralisation Dimension de généralisation : - disposition de la ville invisible - noms de POI invisibles - forme invisible de la zone d'exclusion aérienne -combinaison d'outils invisible -scénario d'urgence invisible -une densité de drones plus élevée -choc de demande plus élevé ### 11.6 Expérience 6 : Rejet sûr de la collaboration homme-machine Testez si le modèle peut refuser l'exécution ou demander une confirmation humaine lorsque UNSAT ou des informations insuffisantes sont disponibles. Exemple : - délai impossible - batterie de tous les drones insuffisante - destination à l'intérieur de la NFZ - destination manquante - conflit entre priorité et règle de sécurité ### 11.7 Expérience 7 : Fiabilité des agents et cohérence multi-tours En vous référant à l'idée `pass^k` de $\tau$-bench, exécutez la même tâche $k$ à plusieurs reprises pour évaluer si l'agent peut terminer la tâche de manière stable [36]. Dans les missions de trafic à basse altitude, un succès mais plusieurs échecs aléatoires ne sont pas suffisamment sûrs, il est donc recommandé de signaler :| Indicateur | Signification | |------|------| | `passe@1` | Taux de réussite d'une seule exécution | | `passer^3` | Proportion de réussite pour la même tâche 3 fois de suite | | `passer^5` | La proportion de la même tâche réussie 5 fois consécutives | | conformité aux politiques | Faut-il se conformer aux règles relatives à l'espace aérien/à la sécurité/à la confirmation manuelle | | cohérence de l'état | Si l'état interne est cohérent avec le retour de l'outil après plusieurs séries d'appels d'outil | | Traitement des informations insuffisantes | Faut-il clarifier/rejeter lorsque les informations sont insuffisantes, plutôt qu'un achèvement hallucinatoire | Cette partie fera de G1 non seulement une « application de trafic », mais une contribution transférable à la fiabilité des agents généraux. ### 11.8 Expérience 8 : Stratification de la difficulté des tâches Pour éviter que les principaux résultats ne soient obscurcis par des échantillons simples, les rapports sont stratifiés par difficulté : | Difficulté | Définition | Caractéristiques des échantillons | |------|------|----------| | Facile | Tâche unique, pas de NFZ, délai lâche | Livraison normale | | Moyen | 1-2 contraintes de sécurité, puissance normale | NFZ ou batterie monofacteur | | Difficile | Contraintes multiples, délais serrés, congestion des corridors | urgence + NFZ + recharge | | Extrême | Risque élevé ou proche de l'UNSAT | répartition du stress | | INSAT | Aucune solution de sécurité réalisable | refus sécuritaire / confirmation humaine | Le tableau principal présente l'ensemble et l'annexe les rapports par difficulté. Les avantages de CloudBrain devraient être plus importants en Hard/Extreme/UNSAT. ### 11.9 Expérience 9 : attribution erronée Chaque échantillon échoué est automatiquement attribué à la première étape d'échec :| Scène | Type d'erreur | |------|----------| | IR | JSON invalide, schéma manquant, énumération incorrecte | | Mise à la terre | entité inexistante, mauvaise zone, mauvais drone | | Outil | mauvais outil, mauvais ordre, arguments invalides | | Planification | pas de chemin, mauvais drone, batterie irréalisable | | Vérification | NFZ, altitude, distance, délai, capacité | | Simulations | collision, quasi-accident, risque météorologique, retard | | Politique | dérogation dangereuse, confirmation humaine manquante, refus erroné | | Explication | raison hallucinée, affirmation non étayée | Il est recommandé d'utiliser des barres empilées pour le diagramme d'analyse des erreurs : répartition des étapes de défaillance des différentes lignes de base. Cela peut clairement expliquer ce que CloudBrain a corrigé. --- ## 12. Définition des indicateurs d'évaluation ### 12.1 Indicateurs de réalisation structurés **Correspondance exacte 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 **Champ IR F1** : calculez respectivement la précision, le rappel et F1 pour les champs tels que l'intention, les entités, les contraintes et le plan d'outil. ### 12.2 Indicateur d'appel d'outil **Précision de l'appel d'outil**：

\text{TCA} = \frac{#\text{corriger les appels d’outils}}{#\text{tous les appels d’outils}}

éèééééèééééà

\text{TDS} = \frac{#\text{chaînes d’outils satisfaisant toutes les dépendances de données}}{#\text{chaînes d’outils}}

You can't use 'macro parameter character #' in math mode Il mesure si l'agent interroge d'abord le statut de l'espace aérien/de la ville, puis planifie et vérifie, plutôt que de s'appuyer sur des outils en aval. ### 12.3 Indicateurs d'exécutabilité **Taux de décision exécutable**：

\text{EDR} = \frac{#\text{décisions exécutables du planificateur}}{N}

éâ：

\text{TSR} = \frac{#\text{tâches réussies entièrement vérifiées et simulées}}{N}

You can't use 'macro parameter character #' in math mode ### 12.4 Indicateurs de sécurité **Taux de violation des règles de sécurité**：

\text{SVR} = \frac{#\text{tâches violées par la sécurité}}{N}

You can't use 'macro parameter character #' in math mode Les types de violations comprennent : - intrusion dans une zone d'exclusion aérienne ; - violation de l'altitude ; - violation de la séparation minimale ; - violation de la réserve de batterie ; - non-respect du délai ; - repli dangereux ; - permission hallucinée. La version étendue du transport à basse altitude recommande des indicateurs de sécurité de transport supplémentaires :| Indicateurs | Définition | Objectif | |------|------|------| | Proxy LoWC | Le rapport en dessous d'une séparation bien claire à tout moment | Mesurer le risque de perte d'espacement | | Mandataire NMAC | Nombre de fois en dessous du seuil de quasi-collision en vol | Mesure du risque grave proche du milieu | | Rapport de risque | La proportion d'événements à risque par rapport à la référence de sécurité basée sur des règles | Rendre différents scénarios comparables | | Précision du refus sûr | La proportion de rejets/demandes de confirmation manuelle qui sont vraiment dangereux à exécuter | Empêcher l'agent d'être trop conservateur | Le texte principal de l'AAAI/IJCAI ne peut signaler que la répartition du SVR et du type de violation ; l’extension T-ITS doit indiquer le proxy LoWC/NMAC et le ratio de risque. ### 12.5 Indicateur d'hallucinations **Taux d'hallucinations**：

\text{HR} = \frac{#\text{sorties contenant une entité/un outil/une règle inexistante}}{N}

You can't use 'macro parameter character #' in math mode ### 12.6 Indicateurs de réparation **Taux de réussite des réparations**：

\text{RSR} = \frac{#\text{échec des premières tentatives réparées en K itérations}}{#\text{échec des premières tentatives}}

ééèé

\text{pass}^k = \frac{#\text{tâches réussies dans toutes } k \text{ exécutions répétées}}{N}

You can't use 'macro parameter character #' in math mode Cette métrique est plus adaptée aux agents critiques pour la sécurité que « pass@1 », car les cerveaux des nuages ​​de trafic à basse altitude exigent une conformité stable aux règles plutôt qu'un succès occasionnel [36]. ### 12.7 Tests statistiques Au moins 3 graines aléatoires par expérience. Rapport sur les principaux résultats :- moyenne ± erreur standard ; -intervalle de confiance bootstrap apparié à 95 % ; - Le test McNemar ou test bootstrap compare les indicateurs de réussite/échec ; - Rapport médian, p90, p95 pour la latence. ### 12.8 Modèle de tableau de résultats principal Le tableau papier 3 peut être rempli directement dans ce format : | Méthode | Modèle | TSR ↑ | EDR ↑ | RVS ↓ | RH ↓ | TCA ↑ | RSR ↑ | passer ^3 ↑ | p95 Latence ↓ | |--------|-------|-------|-------|-------|------|-------|-------|--------------|---------------| | LLM direct | Qwen3-14B | - | - | - | - | N/A | N/A | - | - | | JSON uniquement | Qwen3-14B | - | - | - | - | N/A | N/A | - | - | | Réagir | Qwen3-14B | - | - | - | - | - | N/A | - | - | | Utilisation d'outils uniquement | Qwen3-14B | - | - | - | - | - | N/A | - | - | | LLM+P | Qwen3-14B | - | - | - | - | - | N/A | - | - | | CloudBrain sans réparation | Qwen3-14B | - | - | - | - | - | N/A | - | - | | CloudBrain plein | Qwen3-14B | - | - | - | - | - | - | - | - | ### 12.9 Modèle de table d'ablation| Variante | TSR ↑ | EDR ↑ | RVS ↓ | TCA ↑ | RSR ↑ | Explication principale | |--------|-------|-------|-------|-------|-------|--------------| | Complet | - | - | - | - | - | Méthode complète | | pas d'IR tapé | - | - | - | - | - | Interface structurée de test | | pas de vérificateur | - | - | - | - | - | Test de vérification formelle | | pas de simulateur | - | - | - | - | - | Retour d'information sur la mesure de pression | | pas de réparation | - | - | - | - | N/A | Test de réparation de contre-exemple | | pas de mémoire | - | - | - | - | - | Récupération des cas d'échec de test | | pas de chiffon | - | - | - | - | - | Règles de test/contexte de la carte | ### 12.10 Seuil minimum de réussite Avant de se lancer dans la rédaction d’une thèse, il est recommandé de respecter au minimum ces seuils : | Indicateurs | Seuil minimal | Raisons | |------|----------|------| | CloudBrain TSR complet | Plus de 10 points de pourcentage de plus que ReAct | Revenu principal de la méthode | | SVR | Plus de 30 % inférieur à Direct LLM | Valeur critique de sécurité | | TCA | Plus de 85% | Appels d'outils fiables | | RSR | Plus de 40% | La réparation par contre-exemple est efficace | | passer^3 | Significativement plus élevé que l'utilisation d'outils uniquement | Stabilité multi-tours | | latence p95 | local 14B moins de 60 secondes | récit déployable | --- ## 13. Conclusions expérimentales attendues Les éléments suivants sont des attentes préalables à l'inscription et non des résultats expérimentaux :1. CloudBrain-Agent full devrait être meilleur que l'utilisation directe de LLM, ReAct et d'outils uniquement en termes de réussite des tâches, de taux de décision exécutable et de taux de violation de la sécurité. 2. On s'attend à ce que la saisie de « LowAltitudeIR » améliore principalement la précision des appels d'outils, le champ IR F1 et le taux d'hallucinations. 3. Les commentaires du vérificateur devraient principalement améliorer le taux de décision des exécutables et le taux de réussite des réparations. 4. On s’attend à ce que le retour d’information du simulateur soit le plus critique dans les scénarios de crise, en particulier la congestion des corridors, le risque de vent et les cas limites de NFZ. 5. Le Qwen3-14B/32B local devrait servir de modèle principal reproductible, mais GPT-5.2 est toujours dans la limite supérieure. 6. DeepSeek-R1-Distill-Qwen devrait surpasser le modèle d'instruction ordinaire en matière de réparation par contre-exemple. --- ## 14. Plan graphique| ID | Tapez | Contenu | Priorité | |----|------|------|--------| | Figure 1 | Schéma d'architecture | Boucle fermée de CloudBrain-Agent, de l'instruction à la décision vérifiée | Élevé | | Figure 2 | Organigramme de génération de données | OSM/FAA/OD/SUMO/simulateur vers CloudBrain-Bench | Élevé | | Figure 3 | Histogramme des principaux résultats | Comparaison TSR, EDR, SVR, HR | Élevé | | Figure 4 | Courbe de réparation | Taux de réussite amélioré des itérations de réparation 1-3 | Élevé | | Figure 5 | Carte thermique de généralisation | Performance sur la ville vue/invisible, le stress, UNSAT | Moyen | | Figure 6 | Courbe de consistance des agents | `pass@1`, `pass^3`, `pass^5` et cohérence d'état | Moyen | | Tableau 1 | Comparaison des travaux connexes | Trafic LLM, utilisation des outils, planification, vérification formelle, cet article | Élevé | | Tableau 2 | Statistiques des ensembles de données | Type de scénario, SAT/UNSAT, ville, nombre de tâches | Élevé | | Tableau 3 | Principaux résultats de référence | Comparaison de tous les indicateurs | Élevé | | Tableau 4 | Ablation | Modifications des performances après la suppression du composant | Élevé | | Tableau 5 | Déploiement du modèle | Effet, latence, coût de l'API vs local | Moyen | | Tableau 6 | Reproductibilité de la source de données | URL de chaque type de données, licence, si l'expérience principale en dépend, solution de secours | Moyen | --- ## 15. Planification de la structure papier Compressé par le texte principal des pages 7-8 de AAAI/IJCAI : ### Résumé 150-200 mots. Mettez en évidence la clé de la sécurité du trafic à basse altitude, le manque de fiabilité du LLM, CloudBrain-Agent, l'analyse comparative et les principaux résultats. ### 1 Introduction Contenu :- Fond nuageux de trafic à basse altitude ; - Risques de prise de décision directe par LLM ; - La nécessité d'un appel d'outil et d'une vérification en boucle fermée ; - Trois contributions de cet article ; - Fig. 1 figurine de héros. ### 2 Travaux connexes Trois paragraphes : 1. LLM pour les transports et l'intelligence spatio-temporelle ; 2. Agents LLM, utilisation des outils et planification ; 3. Vérification formelle et simulation UAV/UTM. ### 3 Configuration du problème Définir les états, les tâches, les « LowAltitudeIR », les outils, les conditions de réussite et les contraintes de sécurité. ### 4 Méthodes Présentation de CloudBrain-Agent : - constructeur de contexte ; - Analyseur LowAltitudeIR ; - toupie à outils ; - vérificateur/simulateur ; - boucle de réparation ; -mémoire de sécurité. ### 5 CloudBrain-Bench Présente les sources de données, les processus de génération, les types de scénarios, les divisions, les étiquettes dorées et la reproductibilité. ### 6 Expériences Principaux résultats, ablation, analyse des réparations, généralisation, déploiement du modèle. ### 7Conclusion Résumez les contributions et écrivez honnêtement sur les limites : la référence synthétique, le déploiement réel de l'espace aérien n'a pas été vérifié et l'intervention humaine est toujours nécessaire. --- ## 16. Voie de mise en œuvre ### 16.1 Système minimum viable Ne faites ceci que le premier mois : ```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 Pile technologique recommandée| Modules | Technologie | |------|------| | Exécution de l'agent | Client Python + Pydantic + LiteLLM/OpenAI | | Modèle local | Serveur compatible vLLM OpenAI | | Protocole de l'outil | Les fonctions Python en premier, le wrapper MCP en second | | Validation IR | Schéma JSON Pydantique | | Planificateur | 3D A* en premier, RRT* en option | | Vérificateur | Spot pour LTL, RTAMT pour STL | | Simulateur | simulateur de grille/couloir léger | | CHIFFON | Qdrant/FAISS + Qwen3-Embedding/BGE-M3 | | Stockage | JSONL + Parquet + DuckDB | | Évaluation | pandas + scipy + bootstrap | ### 16.2.1 Interface du module de codes Il est recommandé que chaque module expose l'interface minimale : ```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 ``` Fonction principale du coureur : ```python def run_agent(sample: dict, model: str, config: AgentConfig) -> AgentTrace: ... ``` Fonction principale d'évaluation : ```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 Conception de commandes expérimentales Il est recommandé d'utiliser ces commandes pour reproduire le problème après une future implémentation : ```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 Modèle de fichier de configuration ```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 Plan d'exécution sur 10 semaines| Semaine | Objectifs | Livrables | |----|------|--------| | 1 | Geler la formulation du problème et le schéma IR | `LowAltitudeIR v0.1` | | 2 | Implémenter un générateur de ville/espace aérien/UAV/tâche | 200 échantillons de développement | | 3 | Planificateur/vérificateur/simulateur d'implémentation | étiquettes en or déterministes | | 4 | Implémenter Agent Runner et lignes de base Direct/ReAct | résultats dev-mini | | 5 | Extension de CloudBrain-Bench à plus de 3000 | répartition de validation | | 6 | Exécutez la limite supérieure locale Qwen3-14B et GPT-5.2 | projet de tableau de référence principal | | 7 | Implémenter une boucle de réparation, une mémoire, une ablation | résultats d'ablation | | 8 | courir sans être vu/stress/UNSAT | chiffres de généralisation | | 9 | Tests statistiques, analyse d'erreurs, graphiques | projet de chiffres prêts à photographier | | 10 | Rédaction de la première version de l'AAAI/IJCAI | projet de papier complet | ### 16.4 Critères d'acceptation hebdomadaires| Semaine | Commandes à exécuter | Critères d'acceptation | |----|----------------|----------| | 1 | script de validation de schéma | 20 IR manuscrits tous vérifiés correctement | | 2 | générateur de données | 200 échantillons générés, statistiques fractionnées, pas de champs vides | | 3 | tests unitaires d'outils | planificateur/vérificateur/simulateur au moins 30 tests unitaires | | 4 | référence de développement-mini | direct/ReAct/CloudBrain aucune réparation n'est effectuée | | 5 | répartition de validation | Plus de 3 000 échantillons, génération d'étiquettes dorées terminée | | 6 | matrice de modèle | Qwen3-14B et la limite supérieure GPT ont des résultats | | 7 | ablation | pas d'IR/pas de vérificateur/pas de réparation/pas d'exécutable de simulateur | | 8 | stress/UNSAT | des indicateurs de stress et de refus sécuritaire peuvent être calculés | | 9 | chiffres | 6 figures et 6 tableaux brouillon générés automatiquement | | 10 | brouillon de papier | Le texte principal est complet et les annexes incluent la description du schéma et des données | ### 16.5 Répertoire de codes recommandé v1 Il est recommandé que la première version de la base de code reste petite et claire, et serve d'abord aux expériences de thèse, plutôt que d'en faire une grande plate-forme au début. ```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 Détails du code du schéma Pydantic `LowAltitudeIR` doit utiliser des contraintes de type fortes et essayer de bloquer les erreurs après la sortie LLM et avant l'exécution de l'outil. ```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 ``` La mise à la terre des entités ne doit pas être écrite en Pydantic mais effectuée séparément car elle repose sur la carte actuelle et l'état du drone. ```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 Détails du code ToolRegistryTous les outils implémentent la même interface, ce qui facilite le remplacement de la version MCP déterministe/appris/externe. ```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 Conception minimale du code du planificateur et du simulateur La première version de 3D A* doit uniquement prendre en charge la grille, le masque NFZ, la plage d'altitude et l'estimation de la batterie/longueur. ```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") ``` Le simulateur léger peut être avancé en temps discret : ```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 Conception minimale du code du vérificateur La première version peut diviser LTL/STL en deux couches : les règles communes sont assurées par le vérificateur de programme pour garantir la stabilité, et les expressions complexes sont transmises à 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) ``` La compression du contre-exemple doit être courte, ne remettez pas la piste entière dans l'invite : ```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 Détails du code d'exécution de l'agent `run_agent` doit enregistrer complètement la trace pour faciliter les expériences reproductibles et l'analyse des erreurs. ```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 ``` Trace JSONL Il est recommandé de sauvegarder chaque ligne : ```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 Détails du code d'évaluation La métrique doit être automatiquement calculée à partir de la trace et de l’or pour éviter un jugement subjectif manuel. ```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, ) ``` Méthode de calcul `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 Plan de tests unitaires La première étape des tests devrait couvrir les questions fondamentales de « ne pas rédiger de mauvaises expériences sur papier » :| Fichiers de tests | Contenu des tests | |----------|----------| | `test_ir_schema.py` | enum, champs obligatoires, plage d'altitude, rapport de puissance | | `test_entity_grounding.py` | Aucun UAV/POI/NFZ ne peut être capturé | | `test_tool_registry.py` | Outil non enregistré, enregistrement en double, format de retour d'erreur | | `test_planner.py` | Accessibilité simple, blocage NFZ, pas d'accessibilité du chemin | | `test_verifier.py` | NFZ, délai, robustesse à distance | | `test_simulator.py` | collision, quasi-accident, risque météo | | `test_agent_runner.py` | échec du schéma -> réparation, échec du vérificateur -> réparation, irrécupérable -> refus | | `test_metrics.py` | TSR, SVR, TCA, RSR, calcul pass^k | Exemple de test minimum recommandé : ```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 Priorité de mise en œuvre de la première version Ne faites pas tous les modules en même temps. Il est recommandé de trier par « chaîne de preuves minimale du document » :| Priorité | Module | Pourquoi le faire en premier | |--------|------|------------| | P0 | Schéma `LowAltitudeIR` + validateurs | Les contributions IR dactylographiées ne peuvent être prouvées sans cela | | P0 | outils déterministes + journalisation des traces | toutes les expériences reposent sur | | P0 | 3D A* + vérificateur de base | Prise en charge des indicateurs exécutables/de sécurité | | P0 | coureur de base direct/ReAct/CloudBrain | Former la première table principale | | P1 | graines de stress simulateur | Soutenir le récit critique pour la sécurité | | P1 | boucle de réparation + compression du contre-exemple | Méthode principale de cet article | | P1 | métriques + agrégation | Empêcher la reproduction des résultats | | P2 | Chargeurs OSM/Overture/Open-Meteo | Réalisme amélioré | | P2 | Emballage MCP | Améliorez le récit de l'ingénierie sans bloquer le papier | | P3 | AirSim/Flightmare | Expansion ultérieure, sans bloquer G1 | ### 16.14 Détails du code du wrapper MCP La première version des outils peut d'abord être exécutée via le registre Python, puis le même lot d'outils peut être regroupé dans un serveur MCP. L'avantage de ceci est que les expériences sur papier ne sont pas coincées dans les détails de l'ingénierie MCP, mais que le récit du système peut naturellement se connecter à « l'écologie des outils cloud brain ». Les recommandations de dénomination des outils pour le serveur MCP sont cohérentes avec celles du registre Python :| Outil MCP | Outil Python | Descriptif | |--------------|-------------|------| | `cloudbrain.query_city_state` | `query_city_state` | Entité de la ville et état sur la carte | | `cloudbrain.query_airspace` | `query_airspace` | couloir, NFZ, hauteur, capacité | | `cloudbrain.assign_uav` | `assign_uav` | Affectation des tâches du drone | | `cloudbrain.plan_route` | `plan_route` | Planificateur d'itinéraire 3D | | `cloudbrain.verify_ltl_stl` | `verify_ltl_stl` | vérificateur de sécurité | | `cloudbrain.simulate_scenario` | `simulate_scenario` | simulateur de stress | | `cloudbrain.risk_assess` | `risk_assess` | notation des risques | Pseudo-code du wrapper 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() ``` Contraintes d'ingénierie MCP : - La valeur de retour de l'outil MCP utilise toujours le schéma `ToolResult` pour éviter deux ensembles de protocoles. - Le serveur MCP ne lit et n'écrit pas directement les résultats expérimentaux, mais exécute uniquement les outils ; les traces sont enregistrées par l'agent runner. - Si l'appel MCP échoue, l'agent d'exécution doit pouvoir recourir au registre Python pour garantir que l'expérience n'est pas interrompue. - Il est recommandé d'utiliser le registre Python et le wrapper MCP pour stocker les principaux résultats des expériences de thèse dans la démonstration du système ou en annexe. ### 16.15 Détails du code du générateur de données Le générateur de données doit être déterministe et les entrées principales sont les semences et la configuration. ```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, ) ``` La génération fractionnée doit garantir l’absence de fuite d’informations : ```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" ```Le générateur doit générer des statistiques fractionnées : ```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 et solution de démarrage de modèle local Le modèle natif recommande d'exposer le point de terminaison compatible OpenAI via vLLM. De cette façon, `llm_client.py` ne conserve qu'une seule interface. Exemple de commande de démarrage : ```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 ``` Spécialiste de la réparation 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 ``` Pseudocode client unifié : ```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 {}) ``` Les enregistrements en cours d'exécution doivent être écrits dans `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 Mise en cache, journalisation et reproduction Afin de contrôler le coût de l'API et la durée des expériences, tous les appels LLM, les appels d'outils et les résultats du vérificateur sont mis en cache. Clé de cache : ```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}" ``` Répertoire de cache recommandé : ```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 ``` Chaque trace doit contenir : - `exemple_id` - 'méthode' - `modèle` - `prompt_version` - `config_hash` - `random_seed` - `repair_rounds` - `statut_final` - `metric_row` - `all_tool_results` - `all_verifier_results` ### 16.18 CI et contrôle d'accès qualité Même s'il n'y a que du code de planification et d'expérimentation dans la première phase, des contrôles de qualité doivent être mis en place : ```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 ``` Le test de fumée utilise uniquement un LLM simulé pour garantir que CI ne dépend pas du GPU ou de la clé API. Mock LLM renvoie un IR fixe pour la chaîne d'outils de validation, les métriques et la journalisation des traces. ### 16.19 Configuration de la matrice d'expérimentation En fin de compte, l'expérience principale a utilisé au moins cette matrice :| Divisé | Méthode | Modèle | Répéter | |-------|--------|-------|--------| | validation | direct_llm/react/cloudbrain_full | qwen3-14b | 1 | | test_seen_city | toutes les principales lignes de base | qwen3-14b | 3 | | test_invisible_city | toutes les principales lignes de base | qwen3-14b | 3 | | test_stress | toutes les principales lignes de base | qwen3-14b | 3 | | test_unsat | direct_llm/react/cloudbrain_full | qwen3-14b | 3 | | test_seen_city | cloudbrain_full | qwen3-8b / qwen3-32b / deepseek-repair / limite supérieure GPT | 3 | Générez automatiquement des tâches expérimentales : ```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 Documents d'ingénierie qui doivent être inclus dans l'annexe du document Pour améliorer la reproductibilité, l'annexe G1 contient au moins :| Annexe | Contenu | |------|------| | Un | Schéma JSON complet `LowAltitudeIR` | | B | Schéma du registre d'outils et taxonomie des erreurs | | C | Configuration de génération de données et taxonomie des scénarios | | D | Modèles d'invite pour chaque référence | | E | Définitions complètes des métriques et procédure d'amorçage | | F | Ablation supplémentaire et résultats par scénario | | G | Visualisations de cas d'échec | | H | Budget de calcul, versions de modèle, politique de cache | --- ## 17. Risques et alternatives ### 17.1 Risque : L'effet n'est pas évident Alternative : Augmenter le rapport contrainte/UNSAT pour rendre plus visible la valeur de la réparation du vérificateur ; et signaler les avantages sous différentes difficultés de tâche. ### 17.2 Risque : Le modèle local est trop faible Alternative : Qwen3-32B est utilisé pour l'expérience principale et Qwen3-14B est utilisé comme version déployable ; GPT-5.2 n'est utilisé que pour la limite supérieure. DeepSeek-R1-Distill peut également être utilisé comme spécialiste de la réparation uniquement. ### 17.3 Risque : Données perçues comme trop synthétiques Alternative : divisez l'expérience principale en trois couches : « Synthetic-Controlled », « Real-Context » et « Real-Flight-Calibrated », qui rapportent respectivement les valeurs réelles du programme, l'échouement réel de la ville/de l'espace aérien/de la météo et l'étalonnage réel de la consommation d'énergie du vol. La description du document est clairement rédigée comme une méthode de référence + et n'exagère pas les données UASFM, METAR ou DJI M100 dans les opérations réelles de la flotte commerciale. ### 17.4 Risque : la mise en œuvre du MCP ralentit les progrèsAlternative : la première version de l'outil utilise d'abord le registre de fonctions Python et décrit l'interface comme compatible MCP lors de la soumission. Annexe source de la version du serveur MCP réel ou version ultérieure. ### 17.5 Risque : La vérification formelle est trop lourde Alternative : LTL exécute d'abord des contraintes d'événements discrets, et STL exécute d'abord quatre types de contraintes continues : distance, hauteur, délai et batterie. Ne couvrez pas initialement toutes les réglementations à basse altitude. ### 17.6 Risque : La contribution du benchmark de l'agent n'est pas assez générale Alternative : divisez les tâches de CloudBrain-Bench en dimensions générales d'évaluation de l'agent : sélection des outils, fondement des arguments, dépendance de l'état, conformité aux politiques, réparation des contre-exemples, cohérence « pass ^ k ». De cette façon, même les évaluateurs peu familiers avec le transport à basse altitude peuvent comprendre sa contribution à l’évaluation des agents critiques pour la sécurité. --- ## 18. Références [1] AAAI. « Piste technique principale AAAI-26 : appel à communications. » URL : <https://aaai.org/conference/aaai/aaai-26/main-technical-track-call/> [2] IJCAI-ECAI 2026. « Appel à communications – Volet spécial IA et robotique ». 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 et Weizhu Chen. "LoRA : Adaptation de bas rang de grands modèles de langage." *Conférence internationale sur les représentations de l'apprentissage (ICLR)*, 2022. URL : <https://openreview.net/forum?id=nZeVKeeFYf9> [4] Tim Dettmers, Artidoro Pagnoni, Ari Holtzman et Luke Zettlemoyer. « QLoRA : réglage fin efficace des LLM quantifiés. » *Avances in Neural Information Processing Systems 36 (NeurIPS)*, 2023. URL : <https://proceedings.neurips.cc/paper_files/paper/2023/hash/1feb87871436031bdc0f2beaa62a049b-Abstract-Conference.html>[5] Rafael Rafailov, Archit Sharma, Eric Mitchell, Stefano Ermon, Christopher D. Manning et Chelsea Finn. "Optimisation directe des préférences : votre modèle linguistique est secrètement un modèle de récompense." *Avances in Neural Information Processing Systems 36 (NeurIPS)*, 2023. URL : <https://proceedings.neurips.cc/paper_files/paper/2023/hash/a85b405ed65c6477a4fe8302b5e06ce7-Abstract-Conference.html> [6] Shunyu Yao, Jeffrey Zhao, Dian Yu, Nan Du, Izhak Shafran, Karthik Narasimhan et Yuan Cao. "ReAct : mettre en synergie le raisonnement et l'action dans les modèles linguistiques." *Conférence internationale sur les représentations de l'apprentissage (ICLR)*, 2023. URL : <https://openreview.net/forum?id=WE_vluYUL-X>[7] Yujia Qin, Shihao Liang, Yining 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 et Maosong Sun. "ToolLLM : Faciliter les grands modèles de langage pour maîtriser plus de 16 000 API du monde réel." *Conférence internationale sur les représentations de l'apprentissage (ICLR)*, 2024. URL : <https://openreview.net/forum?id=dHng2O0Jjr> [8] Bo Liu, Yuqian Jiang, Xiaohan Zhang, Qiang Liu, Shiqi Zhang, Joydeep Biswas et Peter Stone. "LLM+P : Renforcer les grands modèles de langage avec une maîtrise optimale de la planification." arXiv :2304.11477, 2023. URL : <https://arxiv.org/abs/2304.11477>[9] Siyao Zhang, Daocheng Fu, Wenzhe Liang, Zhao Zhang, Bin Yu, Pinlong Cai et Baozhen Yao. « TrafficGPT : affichage, traitement et interaction avec les modèles de base de trafic. » *Politique des transports*, 150 :95-105, 2024. DOI : 10.1016/j.tranpol.2024.03.006. URL : <https://www.sciencedirect.com/science/article/pii/S0967070X24000726> [10] OpenAI. «Modèle GPT-5.2». *Documentation de l'API OpenAI*, 2025. URL : <https://platform.openai.com/docs/models/gpt-5.2> [11] Équipe Qwen. «Rapport technique Qwen3.» arXiv :2505.09388, 2025. URL : <https://arxiv.org/abs/2505.09388> [12] DeepSeek-AI. "DeepSeek-R1 : Inciter la capacité de raisonnement dans les LLM via l'apprentissage par renforcement." arXiv :2501.12948, 2025. URL : <https://arxiv.org/abs/2501.12948>[13] Sebastian Wandelt, Changhong Zheng, Shuang Wang, Yucheng Liu et Xiaoqian Sun. « Grands modèles linguistiques pour le transport intelligent : un examen de l'état de l'art et des défis. » *Sciences appliquées*, 14(17):7455, 2024. DOI : 10.3390/app14177455. URL : <https://www.mdpi.com/2076-3417/14/17/7455> [14] Doaa Mahmud, Hadeel Hajmohamed, Shamma Almentheri, Shamma Alqaydi, Lameya Aldhaheri, Ruhul Amin Khalil et Nasir Saeed. "Intégrer les LLM avec les ITS : avancées récentes, potentiels, défis et orientations futures." *Transactions IEEE sur les systèmes de transport intelligents*, 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 Yin et Chao Huang. "UrbanGPT : grands modèles de langage spatio-temporels." arXiv :2403.00813, 2024. URL : <https://arxiv.org/abs/2403.00813>[16] Yuan Yuan, Jingtao Ding, Jie Feng, Depeng Jin et Yong Li. « UniST : un modèle universel optimisé pour la prévision spatio-temporelle urbaine. » *Actes de la conférence ACM SIGKDD sur la découverte des connaissances et l'exploration de données (KDD)*, 2024. DOI : 10.1145/3637528.3671662. URL : <https://arxiv.org/abs/2402.11838> [17] Timo Schick, Jane Dwivedi-Yu, Roberto Dessì, Roberta Raileanu, Maria Lomeli, Eric Hambro, Luke Zettlemoyer, Nicola Cancedda et Thomas Scialom. "Toolformer : les modèles de langage peuvent apprendre eux-mêmes à utiliser des outils." *Avances in Neural Information Processing Systems 36 (NeurIPS)*, 2023. URL : <https://proceedings.neurips.cc/paper_files/paper/2023/hash/d842425e4bf79ba039352da0f658a906-Abstract-Conference.html> [18] OpenAI. « Protocole de contexte de modèle (MCP) – SDK des agents OpenAI. » URL : <https://openai.github.io/openai-agents-js/guides/mcp/>[19] OpenAI. « Outils – SDK OpenAI Agents. » URL : <https://openai.github.io/openai-agents-js/guides/tools/> [20] Karthik Valmeekam, Matthew Marquez, Alberto Olmo, Sarath Sreedharan et Subbarao Kambhampati. « PlanBench : un référentiel extensible pour évaluer de grands modèles de langage sur la planification et le raisonnement sur le changement. » *Avances in Neural Information Processing Systems 36 (NeurIPS) Datasets and Benchmarks Track*, 2023. URL : <https://openreview.net/forum?id=YXogl4uQUO> [21] Bo Liu, Yuqian Jiang, Xiaohan Zhang, Qiang Liu, Shiqi Zhang, Joydeep Biswas et Peter Stone. "Lang2LTL : traduction des commandes en langage naturel en spécifications temporelles avec de grands modèles de langage." *Conférence sur l'apprentissage des robots (CoRL)*, PMLR 229, 2023. URL : <https://proceedings.mlr.press/v229/liu23d.html>[22] Behrad Rabiei, Mahesh Kumar AR, Zhirui Dai, Surya LSR Pilla, Qiyue Dong et Nikolay Atanasov. « LTLCodeGen : génération de code de logique temporelle syntaxiquement correcte pour la planification des tâches du robot. » arXiv :2503.07902, 2025. URL : <https://arxiv.org/abs/2503.07902> [23] Jun Wang, David Smith Sundarsingh, Jyotirmoy V. Deshmukh et Yiannis Kantaros. "ConformalNL2LTL : traduction d'instructions en langage naturel en formules logiques temporelles avec des garanties d'exactitude conforme." arXiv :2504.21022, 2025. URL : <https://arxiv.org/abs/2504.21022> [24] Alexandre Duret-Lutz, Alexandre Lewkowicz, Amaury Fauchille, Thibault Michaud, Etienne Renault et Laurent Xu. « Spot 2.0 : un cadre pour la manipulation de LTL et d'automates ω. » *Symposium international sur les technologies automatisées de vérification et d'analyse (ATVA)*, 2016. URL : <https://spot.lre.epita.fr/>[25] Bardh Hoxha, Houssam Abbas et Georgios Fainekos. "RTAMT : moniteurs de robustesse en ligne de STL." arXiv :2005.11827, 2020. URL : <https://arxiv.org/abs/2005.11827> [26] Administration fédérale de l'aviation. «Gestion du trafic des systèmes d'avions sans pilote (UTM).» URL : <https://www.faa.gov/uas/advanced_operations/traffic_management> [27] Administration fédérale de l'aviation. «Cartes des installations UAS». URL : <https://www.faa.gov/uas/commercial_operators/uas_facility_maps> [28] API OpenStreetMap/Overpass. "OpenStreetMap et l'API Overpass." URL : <https://dev.overpass-api.de/overpass-doc/en/preface/preface.html> [29] Commission des taxis et des limousines de la ville de New York. « Données d'enregistrement de voyage TLC. » URL : <https://www.nyc.gov/site/tlc/about/tlc-trip-record-data.page> [30] Éclipse SUMO. "Documentation SUMO." URL : <https://sumo.dlr.de/docs/index.html>[31] Shital Shah, Debadeepta Dey, Chris Lovett et Ashish Kapoor. "AirSim : simulation visuelle et physique haute fidélité pour les véhicules autonomes." *Robotique de terrain et de service*, Springer Proceedings in Advanced Robotics, 2017 ; arXiv : 1705.05065. URL : <https://arxiv.org/abs/1705.05065> [32] Yunlong Song, Selim Naji, Elia Kaufmann, Antonio Loquercio et Davide Scaramuzza. « Flightmare : un simulateur de quadrirotor flexible. » *Conférence sur l'apprentissage des robots (CoRL)*, PMLR 155, 2021. URL : <https://proceedings.mlr.press/v155/song21a.html> [33] Équipe vLLM. « Serveur compatible OpenAI. » *Documentation vLLM*. URL : <https://docs.vllm.ai/serving/openai_compatible_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 et autres. "AgentBench : évaluation des LLM en tant qu'agents." *Conférence internationale sur les représentations de l'apprentissage (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 et Joseph E. Gonzalez. «Classement des appels fonctionnels de Berkeley». Page du projet UC Berkeley Sky Computing Lab, 2024/2025. URL : <https://sky.cs.berkeley.edu/project/berkeley-function-calling-leaderboard/> [36] Shunyu Yao, Noah Shinn, Pedram Razavi et Karthik Narasimhan. "$\tau$-bench : une référence pour l'interaction outil-agent-utilisateur dans les domaines du monde réel." 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 Yin, Zirui Wang et Ruoming Pang. "ToolSandbox : un référentiel d'évaluation avec état, conversationnel et interactif pour les capacités d'utilisation des outils LLM." arXiv :2408.04682, révisé en 2025. URL : <https://arxiv.org/abs/2408.04682> [38] Lynne Martin, Cynthia Wolter, Kimberly Jobe, Mariah Manzano, Stefan Bladin, Michele Cencetti, Lauren Claudatos, Joey Mercer et Jeffrey Homola. « Tests en vol TCL4 UTM (UAS Traffic Management) Nevada 2019, rapport du Laboratoire des opérations de l'espace aérien (AOL). » Mémorandum technique de la NASA NASA/TM-2020-220516, 2020. URL : <https://ntrs.nasa.gov/citations/20205003361> [39] EUROCONTROL. « CORUS-XUAM : Concept d'opérations pour les systèmes UTM européens — Extension pour la mobilité aérienne urbaine. » Page du projet, 2023. URL : <https://www.eurocontrol.int/project/corus-xuam>[40] Marc Brittain, Luis E. Alvarez, Kara Breeden et Ian Jessen. «AAM-Gym : banc d'essai d'intelligence artificielle pour une mobilité aérienne avancée." *Conférence IEEE/AIAA sur les systèmes avioniques numériques (DASC)*, 2022 ; arXiv :2206.04513. URL : <https://arxiv.org/abs/2206.04513> [41] Fondation Overture Maps. "Documentation Overture Maps : lieux, bâtiments et données de transport." URL : <https://docs.overturemaps.org/> [42] Ouvrir-Météo. « Documentation de l'API de prévisions météorologiques et de l'API de prévisions historiques. » URL : <https://open-meteo.com/fr/docs> [43] Administration fédérale de l'aviation. « Dictionnaire de données du système de livraison de données UAS. » PDF, 2022. URL : <https://www.faa.gov/sites/faa.gov/files/2022-08/UAS_Data_Delivery_System_Data_Dictionary.pdf> [44] Centre de météorologie aéronautique. «API de données». Administration nationale océanique et atmosphérique, page de documentation. URL : <https://aviationweather.gov/data/api/>[45] Thiago A. Rodrigues, Jay Patrikar, Arnav Choudhry, Jacob Feldgoise, Vaibhav Arcot, Aradhana Gahlaut, Sophia Lau, Brady Moon, Bastian Wagner, H. Scott Matthews, Sebastian Scherer et Constantine Samaras. "Ensemble de données de position et de consommation d'énergie en vol d'un quadricoptère DJI Matrice 100 pour la livraison de petits colis." *Données scientifiques*, 8:155, 2021. DOI : 10.1038/s41597-021-00930-x. URL : <https://www.nature.com/articles/s41597-021-00930-x> [46] Administration fédérale de l'aviation. «Livraison de colis par drone (partie 135).» URL : <https://www.faa.gov/uas/advanced_operations/package_delivery_drone> [47] Bureau de responsabilité du gouvernement des États-Unis. « Drones : actions nécessaires pour mieux soutenir l'identification à distance dans l'espace aérien national. » GAO-24-106158, 2024. URL : <https://www.gao.gov/products/gao-24-106158> --- ## Annexe : Ce plan d'exécution ### A. Faites-le immédiatement1. Créez le schéma `LowAltitudeIR v0.1`. 2. Implémenter 6 outils déterministes : ville, espace aérien, planificateur, planificateur, vérificateur et simulateur. 3. Générez 200 mini-échantillons de développement. 4. Exécutez quatre lignes de base : LLM direct, JSON uniquement, ReAct et CloudBrain-Agent sans réparation. ### B. Critères de réussite pour la première série d'expériences Si les conditions suivantes sont remplies sur dev-mini, le benchmark complet sera saisi : - La précision des appels d'outils de CloudBrain-Agent dépasse complètement la référence ReAct ; - le taux de violation de la sécurité est inférieur à celui du LLM direct ; - La boucle de réparation peut réparer au moins certaines défaillances du vérificateur ; - Le temps d'exécution moyen de chaque tâche ne dépasse pas un seuil acceptable, par exemple moins de 30 secondes pour un modèle 14B local. ### C. Connexion à l'article suivant Les traces d'outils, les traces de réparation, les cas de panne et les données d'examen humain générées par G1 deviendront directement les données SFT/DPO de G2 LowAltitudeGPT. En d'autres termes, G1 n'est pas seulement un article, mais aussi une usine de données pour les données de formation de modèles verticaux.