← Blog

Paper G1, vollständiger Paper-Vorschlag v1: Verifizierbarer LLM-Agent für das Cloud-Brain des Verkehrs in geringer Höhe

Planen Sie die Forschungsfragen, die Einreichungspositionierung, das Algorithmusdesign, die Datenkonstruktion, die Modellauswahl, die lokale Bereitstellung, den Versuchsplan, die Bewertungsindikatoren, die erwarteten Schlussfolgerungen, das Diagrammdesign, die Risikokontrolle und den Ausführungsplan vollständig für das erste CloudBrain-Agent-Konferenzpapier.

Papier G1CloudBrain-AgentGehirn der Verkehrswolke in geringer HöheLLM-AgentMCPWerkzeuggebrauchAAAIIJCAIUAVFormale Überprüfung

Papier G1 Vollständiger Papiervorschlag v1: Verifizierbarer LLM-Agent für das Cloud-Brain des Verkehrs in geringer Höhe

Kernurteil: Das erste Papier sollte nicht als „Feinabstimmung eines großen Verkehrsmodells für Tiefgebirgsverkehr“ verfasst werden, sondern als überprüfbares, reproduzierbares und einsetzbares LLM-Agent-Methodenpapier für Tiefgebirgsverkehr.
Empfohlenes Thema: CloudBrain-Agent: Tool-erweiterte und verifizierungsgesteuerte LLM-Agenten für den Verkehrsbetrieb in geringer Höhe.

1. Papierpositionierung und Einreichungsbeurteilung

1.1 Positionierung in einem Satz

In diesem Artikel wird der große Modellagent im Cloud-Gehirn des Verkehrs in geringer Höhe untersucht: Wie kann der LLM-Agent anhand einer Aufgabe in natürlicher Sprache, des städtischen Luftraums in geringer Höhe, des UAV-Flottenstatus und von Sicherheitsbeschränkungen sichere, ausführbare und interpretierbare Betriebsentscheidungen für den Verkehr in geringer Höhe durch strukturierte Zwischendarstellung, Werkzeugaufruf, formale Verifizierung und Simulationsfeedback generieren?

1.2 Empfohlene Beiträge

Bevorzugt: AAAI/IJCAI Master.
Alternativen: AAMAS, IROS/ICRA-Workshop, T-ITS-Folgeerweiterung.

Gemäß dem Zeitpunkt vom 20.05.2026 muss die spezifische Sitzung auf die nächste Runde der AAAI/IJCAI CFP abgestimmt werden; Dieser Artikel ist noch im Stil der AAAI/IJCAI-Hauptkonferenz gestaltet, da AAAI den Schwerpunkt auf KI-Methoden, Anwendungsfelder und Reproduzierbarkeit legt und der IJCAI-ECAI KI- und Robotik-Track einen klaren Fokus auf Roboteragenten, generative KI, Argumentation, strukturierte Modellierung und Handlungskonsequenzen legt [1] [2].

1.3 Warum eignet sich dieser Artikel besser als „Feinabstimmung großer Verkehrsmodelle in geringer Höhe“?

Die direkte Feinabstimmung eines LowAltitudeGPT birgt drei Überprüfungsrisiken:

  1. LoRA, QLoRA und DPO sind bereits ausgereifte Trainingsparadigmen. Die bloße Änderung von Domänendaten reicht nicht aus, um den Hauptbeitrag darzustellen [3] [4] [5].
  2. Der Verkehr in geringer Höhe ist ein sicherheitskritisches System und es ist schwierig, Prüfer davon zu überzeugen, dass LLM Kontrollmaßnahmen direkt ausgibt.
  3. Echte Daten zum Tiefflugverkehr sind rar. Wenn Sie sich im ersten Artikel auf „Großmodelltraining“ konzentrieren, werden Sie nach Datenumfang, Trainingsbudget und Modellneuheit gefragt.Daher sollte sich der erste Artikel auf Agent + Tools + Verifier + Simulator-Feedback konzentrieren. Das große Modell ist nicht der endgültige Controller, sondern eine Ebene des Aufgabenverständnisses, der Tool-Orchestrierung, der Reparatur von Gegenbeispielen und der Interpretation. Diese Einstellung ist natürlich mit Agenten-/Toolnutzungs-/Planungsarbeiten wie ReAct, ToolLLM, LLM+P [6] [7] [8] verbunden und kann auch mit der Diskussion von TrafficGPT über die Interaktion zwischen Verkehrsgrundlagenmodell und LLM mithalten [9].

1.4 22.05.2026 Kalibrierung schreiben: Schreiben Sie G1 nicht als TR-C-Geschichte, sondern bewahren Sie die Verkehrssystembeweise auf

Die erste Investition in G1 ist AAAI/IJCAI, daher muss der Hauptbeitrag die KI-Agent-Methode sein und nicht die Systemerzählung im Stil eines Transportjournals. Eine genauere Schreibweise ist:

CloudBrain-Agent ist eine KI-Agentenmethode, die in einem sicherheitskritischen Verkehrsbereich in geringer Höhe evaluiert wird.

Mit anderen Worten, die Verkehrsszene bietet echte Schwierigkeiten und Sicherheitsbeschränkungen, aber das Papier muss noch Fragen im Agentenbereich beantworten: ob der Tool-Aufruf zuverlässig ist, ob der Zustand konsistent ist, ob die Gegenbeispielreparatur effektiv ist, ob das Modell eine Illusion ist und ob die Bewertung reproduzierbar ist.

Gleichzeitig kann G1 nicht nur „task_success“ und „tool_call_accuracy“ melden. Da der Verkehr in geringer Höhe ein sicherheitskritischer Bereich ist, müssen die Verkehrssystemnachweise aus der ersten Version des Experiments erhalten bleiben:| Ebene | AAAI/IJCAI-Haupttextschwerpunkt | Schwerpunkt der weiteren T-ITS-Erweiterung | |------|-------|-------| | Agentenfunktionen | IR-Validität, Tool-Call-Genauigkeit, Reparaturerfolg, Halluzinationsrate | menschliche Bestätigung, Arbeitsbelastung des Bedieners, zustandsbehaftete Konsistenz | | Sicherheit | Sicherheitsverstoß, NFZ-Verstoß, Batterieverstoß | LoWC/NMAC-Proxy, Risikoverhältnis, Wetter-/Kommunikationsverschlechterung | | Effizienz | ausführbare Entscheidung, Latenz, Laufzeit | Verzögerung, zusätzliche Distanz, Energie, Durchsatz | | Verallgemeinerung | unsichtbare Stadt, Stress, UNSAT/mehrdeutige Aufgaben | Korridor mit hoher Dichte, nicht kooperatives UAV, Kommunikationsverlust, realer Kontext, Stadtteilung | | Systemaufklärung | Wann ist ein Prüfer-Feedback erforderlich | Welche Szenarien müssen vom deterministischen Löser/menschlichen Supervisor des LLM-Agenten zurückgegeben werden |

Daher müssen die Randbedingungen von G1 klar geschrieben werden:

1.5 23.05.2026 Zusammenstellung: Liste der Einreichungsversionen eingefroren

Die erste Version der G1-Einreichung muss drei Ansprüche einfrieren, um zu verhindern, dass sie zu einer Plattformspezifikation für niedrige Höhen wird:1. Benchmark zur domänenbasierten Toolnutzung: CloudBrain-Bench testet nicht nur das JSON-Format, sondern auch die Funktionsauswahl, Parametererdung, Zustandsabhängigkeit, Richtlinieneinhaltung und Mehrrundenkonsistenz in der Transportkette in geringer Höhe. 2. Verifizierergesteuerte Reparatur: Sicherheitsfehler, nicht ausführbare Fehler und mehrdeutige Aufgaben bei Verkehrsmissionen in geringer Höhe müssen durch LTL/STL-Verifizierer, Routenplaner und Simulator-Feedback in strukturierte Reparatursignale umgewandelt werden. 3. Lokal einsetzbare Agentenimplementierung: Das Hauptexperiment muss auf dem lokalen Open-Source-Modell reproduzierbar sein und das API-Modell dient nur als Lehrer oder Obergrenze.

Der erste Teil muss abgeschlossen sein:| Module | Freeze-Anforderungen | |------|----------| | LowAltitudeIR | Schema, Typprüfung, Fehlercodes und JSON-Beispiele korrigiert | | Werkzeuge | Mindestens 6: Luftraumabfrage, Flottenstatus, Zuordnung, Routenplaner, LTL/STL-Verifizierer, Szenariosimulator/Risikoschätzer | | CloudBrain-Bench | Entwicklung/Validierung/Test/Stress-Aufteilung, deckt SAT-, UNSAT-, mehrdeutige, ressourcenbeschränkte Stressszenarien ab | | Grundlinien | Direktes LLM, nur JSON, ReAct, LLM+P / nur Planer, Tool-Nutzung ohne Verifizierer, CloudBrain voll | | Metriken | Aufgabenerfolg, Tool-Call-Genauigkeit, ausführbare Entscheidung, Sicherheitsverletzung, Reparaturerfolg, Halluzinationsrate, Latenz/Kosten | | Ablationen | kein IR, kein Prüfer, kein Simulator, keine Reparatur, API-Lehrer vs. lokales Modell | | Datenschicht | Synthetische Stammdaten + echte OSM/FAA/OD/SUMO-Kontextfelder, keine echten Daten als bereitgestelltes System schreiben |

Der erste suspendierte Inhalt:

Die Funktion dieser eingefrorenen Liste besteht darin, die Grenzen des Papiers zu kontrollieren: G1 beweist nur, dass ein „überprüfbarer LLM-Agent im Schlüsselbereich der Verkehrssicherheit in geringer Höhe“ etabliert ist, und die nachfolgenden G2/G3/G4 werden sich jeweils mit der Feinabstimmung, der Multi-Agenten- bzw. der verkörperten Erweiterung befassen.

---## 2. Entwurf einer Zusammenfassung

Der städtische Verkehrsbetrieb in geringer Höhe erfordert eine Entscheidungsfindung in Echtzeit zwischen dynamischen Aufgaben, begrenzten Luftraumressourcen, UAV-Statusbeschränkungen und Sicherheitsregeln. Große Sprachmodelle sind in der Lage, natürliche Sprache zu verstehen und komplexe Aufgaben zu zerlegen. Wenn sie jedoch direkt für die UAV-Planung und Pfadplanung verwendet werden, führen sie zu Halluzinationen, nicht ausführbaren Plänen und Sicherheitsverstößen. In diesem Artikel wird CloudBrain-Agent vorgeschlagen, ein LLM-Agent-Framework zur Werkzeugverbesserung und Verifizierungsanleitung für Cloud Brain mit geringem Höhenverkehr. CloudBrain-Agent analysiert Aufgaben und Systemzustände in natürlicher Sprache in typisiertes „LowAltitudeIR“, ruft Luftraumabfragen, UAV-Zuweisung, Pfadplanung, LTL/STL-Verifizierung, Szenariosimulation und Risikobewertungstools auf und korrigiert Entscheidungen iterativ mithilfe von Verifizierer-Gegenbeispielen und Simulationsfeedback. Wir entwickeln CloudBrain-Bench, um Notfallverteilung, Inspektionen, Vermeidung von Flugverbotszonen, Überlastung von Korridoren, Ladeengpässe, Multi-Mode-Fallback und unbefriedigende Aufgaben abzudecken. Das Experiment vergleicht direktes LLM, reines Prompt-ReAct, Tool-Nutzung ohne Überprüfung, LLM+P, Orchestrierung im TrafficGPT-Stil und CloudBrain-Agent voll. Die Erwartung vor der Registrierung besteht darin, dass CloudBrain-Agent die reinen Eingabeaufforderungs- und reinen Tool-Baselines in Bezug auf Aufgabenerfolg, ausführbare Entscheidungsrate, Sicherheitsverletzungsrate, Halluzinationsrate und Reparaturerfolg deutlich übertrifft und gleichzeitig eine akzeptable lokale Bereitstellungslatenz beibehält.

3. Forschungsfragen und Kernhypothesen

3.1 Forschungsfragen

RQ1: Kann der LLM-Agent bei Verkehrsmissionen in geringer Höhe Entscheidungsketten des richtigen Typs und mit Werkzeugen ausführbar generieren?

RQ2: Können formale Verifizierung und Simulationsfeedback nicht ausführbare Pläne, Sicherheitsverstöße und Halluzinationen im LLM erheblich reduzieren?

RQ3: Kann die Lösung aus allgemeinem LLM + typisiertem IR + MCP/Tools + Verifizierer im Vergleich zur direkten Feinabstimmung des vertikalen Modells schneller ein reproduzierbares, einsetzbares und skalierbares Forschungssystem bilden?RQ4: Kann das lokale Open-Source-Modell die Leistung des starken Closed-Source-Modells unter den von der Lehrer-API generierten Daten und Regelrückmeldungen erreichen und das nachfolgende LowAltitudeGPT-Papier unterstützen?

3.2 Kernannahmen

H1: Die Eingabe von „LowAltitudeIR“ kann die Qualität der strukturierten Ausgabe und die Genauigkeit des Werkzeugaufrufs erheblich verbessern.
H2: Eine verifizierungsgesteuerte Reparatur kann die Entscheidungsrate für ausführbare Dateien deutlich verbessern und die Rate von Sicherheitsverstößen reduzieren.
H3: Das Feedback des Simulators ist für die Verallgemeinerung unsichtbarer gefährlicher Szenen von entscheidender Bedeutung.
H4: In der ersten Phase muss das vertikale Fundamentmodell nicht trainiert werden. Das allgemeine Modell + die Agent-Tool-Schicht + die Nachbearbeitung des Verifizierers reichen aus, um das G1-Papier fertigzustellen.
H5: Nachdem das lokale Qwen3/DeepSeek-R1-Distill-Modell über vLLM bereitgestellt wurde, kann es als reproduzierbares Hauptversuchsmodell verwendet werden; API-Modelle wie GPT-5.2 dienen als Lehrer und Leistungsobergrenzen [10] [11] [12].

4. Gestaltung von Papierbeiträgen

Es wird empfohlen, den Abschlussbeitrag der Arbeit in drei Artikeln zu verfassen, um eine Streuung zu vermeiden:

  1. CloudBrain-Agent-Framework Für das Cloud Brain für den Verkehr in geringer Höhe wird ein typisierter LLM-Agent mit Werkzeugnutzung vorgeschlagen, der Aufgaben in natürlicher Sprache, den Status des städtischen Luftraums, den Status der UAV-Flotte und Sicherheitsbeschränkungen in „LowAltitudeIR“ vereint.

  2. Überprüfungsgeführte Reparatur für den Verkehr in geringer Höhe Wandeln Sie Fehlerrückmeldungen von LTL/STL-Prüfern, Routenplanern und Simulatoren in strukturierte Gegenbeispiele um, die Aufrufe von LLM-Reparaturtools, Aufgabeneinschränkungen und Pfad-/Planungsempfehlungen vorantreiben.3. CloudBrain-Bench und Evaluierungsprotokoll Erstellen Sie einen Brain-Benchmark für den Cloud-Verkehr in geringer Höhe, der Indikatoren wie Tool-Call-Genauigkeit, ausführbare Entscheidung, Sicherheitsverletzung, Reparaturerfolg, Generalisierung, Latenz und menschliches Vertrauen abdeckt.

Es wird nicht empfohlen, den Beitrag als „Wir haben ein großes Verkehrsmodell in geringer Höhe trainiert“ zu schreiben. Die Feinabstimmung kann als experimentelle Erweiterung oder als nächster G2 erfolgen.

4.1 Papierpositionierungsmatrix nach der zweiten Forschungsrunde

Nach Online-Recherchen sollte der beste Einstiegspunkt für G1 eindeutig domänenbasierte Agentenbewertung + Sicherheitsüberprüfung sein und nicht allgemeine LLM-Anwendungen. AgentBench beweist, dass LLM-Agenten Argumentation und Entscheidungsfindung in einer interaktiven Umgebung bewerten müssen [34]; BFCL erklärt, dass Funktionsaufrufe Funktionsauswahl, Parameter, parallele Aufrufe und Relevanzerkennung überprüfen müssen [35]; -bench betont außerdem Mehrrundeninteraktion, API, Domänenrichtlinie und Konsistenzindex „pass^k“ [36]; ToolSandbox weist darauf hin, dass Zustandsabhängigkeit, Kanonisierung und unzureichende Informationen die Hauptschwierigkeiten von Tool-basierten Agenten sind. [37].

Die Inspiration für G1 aus diesen Arbeiten ist: CloudBrain-Bench kann nicht nur bewerten, „ob JSON ausgegeben wird“, sondern bewertet auch die Statusaktualisierung, Regeleinhaltung, Werkzeugabhängigkeit, Fehlerreparatur und Mehrrundenkonsistenz des Agenten in der Transportkette in geringer Höhe.| Bereits gerichtet | Repräsentative Arbeit | Einschränkungen | Unterschiede in G1 | |----------|----------|------|-----------| | Generalagenten-Benchmark | AgentBench, -bench, ToolSandbox [34] [36] [37] | Beinhaltet keine Sicherheitsbeschränkungen für den Tiefflugverkehr und keine UAV-Werkzeugkette | Domänentools, Richtlinien, Prüfer für UTM/UAV | | Funktionsaufruf-Benchmark | BFCL [35] | Konzentrieren Sie sich auf die Korrektheit von Funktionsaufrufen und kümmern Sie sich nicht um physische Ausführbarkeit und Sicherheit | Werkzeugaufrufe müssen über den Planer/Verifizierer/Simulator | erfolgen | LLM + Verkehr | TrafficGPT, ITS LLM-Umfrage [9] [13] [14] | Multifokus-Bodenverkehr oder Verkehrsmodellinteraktion | Ausweitung auf den Luftraum in geringer Höhe, die UAV-Flotte und die formelle Sicherheit | | NL-zu-LTL/Roboter-Aufgabenspezifikation | Lang2LTL, LTLCodeGen, ConformalNL2LTL [21] [22] [23] | Lösen Sie hauptsächlich die Spezifikationsgenerierung | Integrieren Sie die Spezifikationsüberprüfung in den geschlossenen Entscheidungskreislauf des gesamten Cloud-Gehirns | | UTM/UAM-Simulation | NASA TCL4, CORUS-XUAM, AAM-Gym [38] [39] [40] | Die Orchestrierung von LLM-Agent-Tools wird normalerweise nicht untersucht | Unterstützen Sie CloudBrain-Bench mit UTM/UAM-Konzepten und -Szenarien |

5. Verwandter Arbeitsrahmen

5.1 LLM für den Transport

TrafficGPT erklärt, dass LLM als Interaktions- und Verarbeitungseingang für Verkehrsfundamentmodelle verwendet werden kann, weist aber auch darauf hin, dass numerische Verkehrsdaten, Simulationen und Modellinteraktionen nicht allein durch Klartext generiert werden können [9]. Jüngste ITS-Überprüfungen platzieren LLM weiter in den Bereichen semantische Verkehrsschnittstellen, Entscheidungshilfen und Datenverständnis aus mehreren Quellen [13] [14]. UrbanGPT und UniST repräsentieren die Richtung des städtischen Raum-Zeit-Grundlagenmodells und eignen sich zur Unterstützung des Stadtstaatsverständnisses, sind jedoch keine Werkzeugketten für den Betrieb von UAVs in geringer Höhe [15] [16].### 5.2 LLM-Agenten und Tool-Nutzung

ReAct verwebt Argumentation, Spur und Aktion und ist die Grundlage der Agentenschleife in diesem Artikel [6]. Toolformer und ToolLLM beweisen, dass LLM die Verwendung von APIs/Tools erlernen kann, lösen jedoch nicht die Probleme der Überprüfung der Verkehrssicherheit in geringer Höhe und der Ausführbarkeit von Missionen [7][17]. MCP und OpenAI Agents SDK bieten eine standardisiertere Tool-Verbindungsmethode, die dabei hilft, Scheduler, Planer, Verifizierer und Simulator zu austauschbaren Tools zu machen [18] [19].

Nach der zweiten Forschungsrunde sollte in verwandten Arbeiten auch das Agentenbewertungssystem hinzugefügt werden: AgentBench ist ein LLM-als-Agent-Benchmark für mehrere Umgebungen [34]; BFCL wertet speziell Funktionsaufrufe und Relevanzerkennung aus [35]; -bench verwendet mehrere Runden der Benutzer-Agent-Tool-Interaktion und „pass^k“, um die Zuverlässigkeit zu bewerten [36]; ToolSandbox betont den Werkzeugausführungsstatus, implizite Abhängigkeiten und unzureichende Informationsszenarien [37]. Das G1-Bewertungsprotokoll sollte diese Ideen berücksichtigen, die Umgebung jedoch in ein Cloud-Gehirn für den Verkehr in geringer Höhe verwandeln.

5.3 LLM-Planung und formale Verifizierung

LLM+P und PlanBench zeigen, dass LLM allein nicht planungssicher ist und mit externen Planern, formalen Darstellungen und Bewertungsprotokollen kombiniert werden muss [8] [20]. Lang2LTL, LTLCodeGen und ConformalNL2LTL veranschaulichen, dass sich die Übersetzung natürlicher Sprache in zeitliche Logik weiterentwickelt, sie konzentrieren sich jedoch hauptsächlich auf die Generierung von Spezifikationen und die unvollständige Abdeckung von Planung, Routing, Simulation und geschlossenen Risikoschleifen im Cloud-Gehirn des Verkehrs in geringer Höhe [21] [22] [23]. Spot und RTAMT können jeweils als LTL/STL-Verifizierungstools verwendet werden [24] [25].

5.4 UAV-, UTM- und SimulationsdatenFAA UTM definiert UAV-Verkehrsmanagement in geringer Höhe als eine kollaborative Ökologie, die Flugplanung, Autorisierung, Überwachung und Konfliktmanagement unterstützt [26]. FAA UAS Facility Maps bieten eine Höhenreferenz, die schnell für Teil 107-Operationen im kontrollierten Luftraum genehmigt werden kann und als Proxy für Luftraumregeln geeignet ist [27]. OSM/Overpass, NYC TLC OD-Daten, SUMO, AirSim und Flightmare können gemeinsam den Synthetik-zu-Real-Benchmark unterstützen [28] [29] [30] [31] [32].

Um die Glaubwürdigkeit des Verkehrs in geringer Höhe zu erhöhen, sollte G1 außerdem die NASA TCL4 Nevada-Flugtests zitieren: Dieser Test umfasst BVLOS-, Häuserschlucht-, Wetterfront-, Konzert-Notfallreaktions- und ZNS-Problemszenarien und eignet sich als Quelle für Szenariotaxonomie und Diskussionen über die Qualität von Mensch-System-Informationen [38]. Das europäische CORUS-XUAM bietet ein U-Space/UAM-Betriebskonzept, U3/U4-Servicemodelle, ATM-U-Space-Koordination, Vertiport-Führung und Human-in-the-Loop-Beweise [39]. AAM-Gym kann als Simulationssteuerung für fortgeschrittene Luftmobilitäts-KI-Testumgebungen verwendet werden, insbesondere zur Sicherung der Korridortrennung [40].

6. Problemformulierung

6.1 Systemstatus

Zum diskreten Entscheidungszeitpunkt empfängt das Gehirn der Verkehrswolke in geringer Höhe den Systemstatus:

Unter ihnen:- : Eine Sammlung von UAVs. Jedes UAV verfügt über Position, Leistung, Last, Geschwindigkeit und Missionsstatus.

Anweisungen in natürlicher Sprache werden mit bezeichnet. Ziel ist es, umsetzbare Entscheidungen zu generieren:

Dabei ist „LowAltitudeIR“, ist die Werkzeugaufrufsequenz, ist die Planungs-/Pfad-/Risikoentscheidung und ist die Erklärung.

6.2 Sichere ausführbare Ziele

Eine Entscheidung gilt genau dann als erfolgreich, wenn:

  1. Schemagültigkeit: erfüllt die Typbeschränkung „LowAltitudeIR“.
  2. Tool-Ausführbarkeit: Alle Tool-Aufrufparameter sind zulässig und geben fehlerfreie Ergebnisse zurück.
  3. Planungsdurchführbarkeit: Termin- und Wegeplanung sind durchführbar.
  4. Zeitliche Sicherheit: LTL/STL-Spezifikationen überprüft.
  5. Simulationsrobustheit: Löst in bestimmten Szenario-Seeds keine Kollisionen, Flugverbotszonenverstöße oder Fristverstöße aus.
  6. Menschliche Interpretierbarkeit: Die Interpretation umfasst keine nicht existierenden Einheiten, Werkzeuge oder Regeln.

formell:$$ \text{Erfolg}(\pi_t) = \mathbb{1}[ V_\text{Schema}(z_t) \land V_\text{tool}(a_{1:k}) \land V_\text{plan}(y_t) \land V_\text{Logik}(y_t) \land V_\text{sim}(y_t) ]

You can't use 'macro parameter character #' in math mode ### 6.3 Was dieser Artikel nicht tut - Verhindern Sie, dass LLM direkt Steuervariablen auf niedriger Ebene ausgibt. - Kann direkt eingesetzt werden, ohne echten Luftraum zu beanspruchen. - Verschleiern Sie synthetische Daten nicht als echte Betriebsdaten. - Trainieren Sie das Fundamentmodell für den Tiefflugverkehr nicht von Grund auf. --- ## 7. Methode: CloudBrain-Agent ### 7.1 Gesamtarchitektur ```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“ ist der Schlüssel zum Papier. Es ist strenger als die normale JSON-Ausgabe und muss in der Lage sein, Tools und Validatoren zu verbinden. ```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" } ``` Einschränkungen auf Feldebene: | Felder | Typen | Einschränkungen | |------|------|------| | „Absicht“ | Aufzählung | Lieferung / Patrouille / Inspektion / Notfall / Rückgabe / Gebühr | | „Priorität“ | Aufzählung | niedrig / normal / hoch / kritisch | | „Entitäten“ | Objekt | Muss sich auf eine Entität beziehen, die im Karten- oder UAV-Status vorhanden ist | | „Einschränkungen“ | Objekt | muss in Planer-/Prüfereingaben übersetzt werden können | | `tool_plan` | Liste | Der Toolname muss aus der Registrierung stammen und die Parameter müssen dem Schema | entsprechen | `fallback_policy` | Aufzählung | Wird ausgelöst, wenn nicht erreichbar, unsicher, Zeitüberschreitung | ### 7.2.1 LowAltitudeIR v0.1 detaillierte Feldspezifikationen Entwerfen Sie in der ersten Version die IR nicht zu groß, sondern stellen Sie sicher, dass jedes Feld von Tools genutzt, von Indikatoren ausgewertet und anhand von Fehlern analysiert und zugeordnet werden kann. Es wird empfohlen, die IR in 9 Felder der obersten Ebene aufzuteilen:| Felder der obersten Ebene | Erforderlich | Geben Sie | ein Beschreibung | Metriken, auf die sich ein Fehler auswirkt | |----------|------|------|------|----| | `task_id` | Ja | Zeichenfolge | Eindeutige Aufgaben-ID im Datensatz | Rückverfolgbarkeit | | „Absicht“ | Ja | Aufzählung | Aufgabenzweck: Lieferung, Inspektion, Patrouille, Notfall, Rückgabe, Ladung, Überwachung | IR-Feld F1 | | „Priorität“ | ja | Aufzählung | niedrig, normal, hoch, kritisch | Richtlinieneinhaltung | | „Entitäten“ | Ja | Objekt | Herkunft, Ziel, Candidate_uavs, sensitive_zones, handoff_points | Halluzinationsrate | | „Einschränkungen“ | Ja | Objekt | Zeit, Höhe, Distanz, Akku, Flugverbotszone, Kapazität, Wetterrisiko | Rate von Sicherheitsverstößen | | `tool_plan` | Ja | Liste | Linearisierter Plan für Tool-Call-DAG | Tool-Call-Genauigkeit | | `verification_specs` | ja | Objekt | LTL/STL-Spezifikationen und interpretierbare natürliche Sprachregeln | verifizierte Entscheidungsrate | | `fallback_policy` | ja | Aufzählung | Ground_transfer, Wait, Human_Confirm, Safe_Refusal | sichere Ablehnungsgenauigkeit | | `explanation_plan` | nein | Objekt | Werkzeugergebnisse und Einschränkungen, auf die in der Erklärung Bezug genommen werden muss | menschlicher Vertrauenswert | Empfehlungen zu Entitätsfeldern gelten speziell für:| Felder | Beispiele | Prüfmethoden | |------|------|----------| | „Herkunft“ | `hospital_A` | Muss in „city_state.entities“ | vorhanden sein | „Ziel“ | `accident_site_3` | Muss in der Aufgabe oder Karte | vorhanden sein | `candidate_uavs` | `["uav_03", "uav_07"]` | Muss in „uav_state“ vorhanden sein und der Status ist verfügbar | | `avoid_zones` | `["school_zone_2", "nfz_temp_1"]` | Muss im Luftraum/in der Karte | vorhanden sein | `handoff_points` | `["metro_station_4"]` | Erforderlich für multimodalen Fallback | Empfehlungen für Einschränkungsfelder gelten speziell für: | Feld | Einheit | Standard | Beschreibung | |------|------|------|------| | `deadline_sec` | zweite | null | Leer, wenn es keine Frist gibt | | `altitude_min_m` | Meter | 30 | Mindestflughöhe | | `altitude_max_m` | Meter | 120 | Maximale Höhe, abhängig vom Luftraum-Proxy | | `min_separation_m` | Meter | 10 | Mindestabstand zu Hindernissen/UAV/sensibler Zone | | `battery_reserve_ratio` | Verhältnis | 0,2 | Minimal verbleibender Batteriestand nach Ankunft | | `max_risk_level` | Aufzählung | mittel | niedrig, mittel, hoch | | `corridor_capacity_required` | int | 1 | Vom Korridor belegte Mindestkapazität | ### 7.2.2 LowAltitudeIR-Verifizierungssequenz Die IR-Überprüfung sollte hierarchisch erfolgen, um die Fehleranalyse zu erleichtern:1. **JSON-Gültigkeit**: Ob es in JSON geparst werden kann. 2. **Schemagültigkeit**: Ob der Feldtyp, die Aufzählung und die erforderlichen Felder korrekt sind. 3. **Entitätserdung**: Ob alle Entitäten im aktuellen Zustand vorhanden sind. 4. **Constraint Grounding**: Ob Einschränkungen in Planer-/Prüferparameter umgewandelt werden können. 5. **Werkzeugabhängigkeit**: Ob die Werkzeugeingabe von der vorherigen Werkzeugausgabe abhängt. 6. **Richtlinienkompatibilität**: Ob Priorität, Fallback und menschliche Bestätigung den Regeln entsprechen. Jede Fehlerebene muss in „error_type“ geschrieben werden, zum Beispiel: ```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 Tool-Registrierung Die erste Version des Tools sollte in eine Python-Funktion umgewandelt und dann in einen MCP-Server gepackt werden. Der Vorteil von MCP ist die standardisierte Tools-/Kontextschnittstelle, die es verschiedenen Modellen und Agentenlaufzeiten ermöglicht, denselben Satz an Tools wiederzuverwenden [18] [19].| Werkzeug | Erforderlich | Eingabe | Ausgabe | Fehlertyp | |------|------|------|------|----------| | `query_city_state` | Ja | Region, Zeit | POI, Gebäude, Bodendiagramm | unbekannte_region | | `query_airspace` | Ja | Region, Höhe, Zeit | Flur, NFZ, Decke | eingeschränkter_Luftraum | | `assign_uav` | ja | Aufgabe, UAV-Zustände | ausgewähltes UAV / keines | no_available_uav | | `plan_route` | ja | Start, Ziel, Einschränkungen | Pfad / nicht erreichbar | no_path | | `verify_ltl_stl` | ja | Pfad, zeitliche Angaben | bestanden/nicht bestanden/Gegenbeispiel | spec_violation | | `simulate_scenario` | Ja | Entscheidung, Szenario-Seed | Erfolg/Risiko/Kollision | sim_failure | | `risk_assess` | ja | Entscheidung, Zustand | Risikobewertung, Gründe | hohes_risiko | | `explain_decision` | Optional | Entscheidungsspur | Erklärung | halluzinierte_Erklärung | ### 7.3.1 Tool-API-Vertrag Alle Werkzeuge kehren einheitlich zurück: ```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" } } ``` Bei Misserfolg: ```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"] } } ``` Spezifische Werkzeugeingabe und -ausgabe:| Werkzeug | Wichtige Eingabefelder | Wichtige Ausgabefelder | Behebbare Fehler | Nicht behebbare Fehler | |------|--------------|--------------|------------|--------------| | `query_city_state` | „region_id“, „bbox“, „time“ | `pois`, `buildings`, `roads`, `sensitive_zones` | `partial_map` | `unknown_region` | | `query_airspace` | `bbox`, `altitude_range`, `time` | „Korridore“, „nfz“, „Kapazität“, „Decke“ | `capacity_low` | `restricted_airspace` | | `assign_uav` | „task“, „uav_states“, „objective“ | „uav_id“, „assignment_score“, „reason“ | `low_battery_candidates` | `no_available_uav` | | `plan_route` | `start`, `goal`, `avoid`, `altitude_range` | `waypoints`, `length_m`, `eta_sec`, `energy_est` | `deadline_risk` | `no_path` | | `verify_ltl_stl` | „Flugbahn“, „Spezifikationen“ | „bestanden“, „Verstöße“, „Robustheit“, „Gegenbeispiel“ | `negative_robustness` | `invalid_spec` | | `simulate_scenario` | „Entscheidung“, „szenario_seed“, „stress_level“ | „Erfolg“, „Ereignisse“, „Mindestentfernung“, „Verzögerung“, „Risiko“ | `near_miss` | „Kollision“ | | `risk_assess` | „Entscheidung“, „Wetter“, „Verkehr“, „Geschichte“ | „risk_score“, „risk_level“, „top_reasons“ | „mittleres_risiko“ | `high_risk_no_override` |### 7.3.2 Tool-Abhängigkeits-DAG Toolaufrufe sind keine willkürlichen Sequenzen und sollten Abhängigkeiten erfüllen: ```text query_city_state -> query_airspace -> assign_uav -> plan_route -> verify_ltl_stl -> simulate_scenario -> risk_assess -> explain_decision ``` Situationen, die übersprungen werden dürfen: - „simulate_scenario“ kann in dev-mini ausgeschaltet werden, muss aber für das Hauptexperiment eingeschaltet werden. - „risk_assess“ kann mit „simulate_scenario“ zusammengeführt werden, Papiermetriken werden jedoch weiterhin separat gemeldet. - „explain_decision“ hat keinen Einfluss auf den Aufgabenerfolg, sondern auf das menschliche Vertrauen und die Halluzination. ### 7.3.3 Mindestimplementierungsversion In der ersten Version kann jedes Werkzeug deterministisch sein: | Werkzeug | Minimaler Algorithmus | Komplexe Version | |------|----------|----------| | `query_city_state` | Entitäten aus JSON/GeoJSON lesen | Dynamische OSM/Overture-Abfrage | | `query_airspace` | Regelvorlage + Polygonschnittpunkt | Simulation von UTM/U-Space-Diensten | | `assign_uav` | gierige min ETA mit Batteriefilter | MILP / Lyapunov-Planer | | `plan_route` | 3D A*-Raster | RRT* / MPC-lite | | `verify_ltl_stl` | Handschriftliche Regeln + RTAMT/Spot | Vollständiger zeitlicher Logikmonitor | | `simulate_scenario` | Zeitdiskrete Kinematik | AirSim/Flightmare | | `risk_assess` | gewichteter Regelwert | erlerntes Risikomodell | ### 7.4 Verifizierungsgeführte Reparatur Der Schlüssel zum CloudBrain-Agent besteht nicht darin, ihn einmal zu generieren, sondern darin, den geschlossenen Regelkreis zu reparieren: ```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 ``` Gegenbeispiel-Feedback muss strukturiert sein und darf nicht nur „fehlgeschlagen“ sein. Zum Beispiel: ```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 Sicherheitsspeicher Der Sicherheitsspeicher zeichnet drei Arten von Informationen auf: 1. **Bekannte unsichere Muster**: Zum Beispiel schwacher Akku + hohe Windgeschwindigkeit + knappe Frist. 2. **Reparaturfälle**: fehlgeschlagene IR, Gegenbeispiel, erfolgreiche Reparatur-IR. 3. **Menschliche Eingriffe**: manuelle Bestätigung, Ablehnung und Neuzuweisung. Der erste Artikel erfordert kein komplexes Langzeitgedächtnis und muss lediglich den Abruf implementieren: Rufen Sie bei gegebener aktueller Aufgabe ähnliche Fehlerfälle als Reparaturkontext mit wenigen Schüssen ab. ### 7.6 Algorithmus-Pseudocode Es wird empfohlen, einen vereinfachten Algorithmus in den Haupttext der Arbeit und die vollständige Version in den Anhang einzufügen. ```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 Komplexität und Laufzeiterwartungen Angenommen, die Kartengittergröße beträgt $G = | Modul | Hauptkomplexität | Optimierungsmethoden | |------|------------|----------| | IR-Erzeugung | $O(K \cdot C_\text{LLM})$ | Cache-Eingabeaufforderung, kurzes Feedback, niedrige Temperatur | | UAV-Aufgabe | $O(|\mathcal{U}|)$ gierig | Vorfilterung ist nicht verfügbar UAV | | 3D A* | $O(G \log G)$ | Korridormaske, hierarchisches Raster, Heuristik | | STL-Überwachung | $O(T \cdot |\Phi|)$ | Vektorisierte Flugbahnprüfung | | Simulation | $O(T \cdot N_\text{agenten})$ | Chargensaat, Frühstopp | | Abruf | $O(\log M)$ ungefähr | FAISS/Qdrant | Im ersten Artikel muss keine extreme Echtzeitleistung angestrebt werden, es muss jedoch eine End-to-End-Latenz gemeldet werden. Vorgeschlagene Ziele:- dev-mini: Einzelaufgabe 5-20 Sekunden; - Lokal 14B: Einzelaufgabe 10-40 Sekunden; - API-Obergrenze: 5–30 Sekunden für eine einzelne Aufgabe; - Batch-Auswertung: asynchron und gleichzeitig, aber jede Stichprobe zeichnet eine unabhängige Latenz auf. --- ## 8. Datenquellen und CloudBrain-Bench-Build ### 8.1 Datenzusammensetzung Es wird empfohlen, den ersten Hauptdatensatz **CloudBrain-Bench** zu nennen.| Datenschicht | Quelle | Ob das Hauptexperiment davon abhängt | Funktion | |--------|------|----------------|------| | Synthetisches Stadtnetz | Prozedural generiert | Ja | Kontrollierbar, reproduzierbar, skalierbar | | OSM-Stadtkontext | OSM / Überführung | Ja | POI, Straße, Gebäude, Funktionsbereichsbenennung | | Overture Maps-Kontext | Ouvertüre Orte / Gebäude / Transport | Optionale Erweiterungen | Hochwertige POIs, Gebäude, Straßentopologie und stabile Entitäts-IDs | | Reale Luftraumgitter | FAA UAS Facility Map-Polygone + UAS-Datenwörterbuch | Ja | Echte UASFM-Geometrie, Decke, Luftraum/Flughafen/LAANC-Felder | | OD-Demand-Proxy | NYC TLC / Chicago Taxi optional | Optional | Generieren Sie Bedarfs-Hotspots und Spitzenaufgaben | | Bodenverkehr | SUMO | Optionale Erweiterung | Boden-Fallback-Reisezeit | | Flugwetter | NOAA Aviation Weather Data API METAR + Open-Meteo | Optionale Erweiterungen | Echtes Flugwetter, Windgeschwindigkeit, Sicht, Niederschlag und Wetterrisiko | | Echte UAV-Flugtelemetrie | DJI Matrice 100 Paketzustellungsflugdatensatz | Optionale Kalibrierung | Energieverbrauch/ETA-Kalibrierung für Position, Strom, Spannung, Wind, Geschwindigkeit, Last, Höhe | | UTM-Flugtestkontext | NASA TCL4-Berichte | Optionale Erweiterungen | Stadtschlucht, BVLOS, Wetterfront, Taxonomie von Notfallszenarien | | UAV-Dynamik | Selbstgebauter Leichtbau-Simulator | Ja | Weg, Energieverbrauch, Kollision, Verzögerung | | VisualsSimulator | AirSim/Flightmare | Optionale Ergänzungen | Nachfolgende visuelle/dynamische Erweiterungen |OSM/Overpass eignet sich zur Abfrage städtischer Merkmale [28]; Overture Maps stellt Orte, Gebäude und Transportebenen über GeoParquet bereit, die POI, Gebäude- und Straßentopologie ergänzen können [41]. Die Luftraumschicht sollte nicht nur als abstrakter Proxy geschrieben werden: Die offizielle Seite der FAA UAS Facility Maps bietet Datenanbietern die UASFM-Dateneingabe. Das Datenwörterbuch klärt Felder wie Geometrie, mittlere Breiten-/Längengrade, „CEILING“, Luftraumklasse, Flughafenkennungen und LAANC-Bereitschaft [27] [43]. Die Wetterschicht kann die NOAA Aviation Weather Data API verwenden, um Flugwetterbeobachtungen wie METAR abzurufen, und dann Open-Meteo verwenden, um historische/Gitterwetterfunktionen zu ergänzen [42] [44]. Die reale UAV-Dynamikschicht kann die von Scientific Data veröffentlichten DJI Matrice 100-Flugdaten für die Lieferung kleiner Pakete verwenden; Diese Daten enthalten Hunderte von Flugpositions-, Energieverbrauchs-, Wind-, Last-, Höhen- und Geschwindigkeitsänderungen, die zur Kalibrierung des Energieverbrauchs und der voraussichtlichen Ankunftszeit verwendet werden können, anstatt das Batteriemodell aus dem Nichts anzugeben [45]. NYC TLC und SUMO dienen immer noch nur als Nachfrage- und Boden-Fallback-Proxys [29] [30]; AirSim und Flightmare ergänzen die Closed-Loop-Simulation [31] [32]. ### 8.1.1 Beurteilung der Realdaten-Machbarkeit Die Schlussfolgerung nach der zweiten Suche ist nicht, dass „es keine echten Daten gibt“, sondern dass **echte Daten auf verschiedenen Ebenen existieren und es an einem öffentlichen und vollständigen geschlossenen Kreislauf für den kommerziellen Betrieb in geringer Höhe mangelt**.| Datenprobleme | 21.05.2026 Öffentliche Verfügbarkeit | Möglichkeiten, die für G1 | verwendet werden können Was nicht behauptet werden kann | |----------|------------|------------------|----------------| | Stadtplan/POI/Gebäude/Straßen | Hoch | OSM/Ouvertüre Real City Context | Nicht gleichbedeutend mit einem echten Drohnenkorridor | | UAS-Luftraum-Höhenraster | Hoch | FAA UASFM-Polygon, Decke, Luftraum/LAANC-Felder | UASFM ist nicht gleichbedeutend mit Fluggenehmigung | | Flugmeteorologie | Hoch | NOAA METAR, Open-Meteo Wind- und Regeneigenschaften | Flughafenwetter ist nicht gleichbedeutend mit windfeldern in geringer Höhe auf Blockebene | | Tatsächlicher Flugenergieverbrauch/Position des UAV | Mittel | DJI M100-Liefertelemetrie kalibrierter Energieverbrauch und voraussichtliche Ankunftszeit | Ungleich 100 reale Betriebspläne | | UTM-Testflugszenarien und Mensch-Maschine-Informationsfluss | Mittel | NASA TCL4-Szenariotaxonomie und UTM-Informationsanforderungen | Die Berichterstattung entspricht nicht den öffentlichen Rohdaten der UTM-Flotte | | Kommerzieller Lieferauftragsfluss/Trackprotokoll | Niedrig | Nutzen Sie nur den operativen Hintergrund und die Motivation der FAA für die zukünftige Zusammenarbeit | Zipline-/Wing-/Flytrex-Bestellspuren können nicht gefälscht werden | | Remote ID macht Echtzeit-Trajektorien im großen Maßstab sichtbar | Niedrig | Wird nicht als primäre Datenquelle verwendet | Remote ID kann nicht als vorgefertigte öffentliche Datensatzflotte verwendet werden | Auf der FAA-Seite Teil 135 heißt es, dass die Vereinigten Staaten bereits über Genehmigungsrouten und zugelassene Betriebseinheiten für den Paketzustellungsdrohnenbetrieb verfügen, sodass die Forschungsfrage nicht rein hypothetisch ist [46]. Allerdings werden öffentliche Betriebsordnungsabläufe, Luftraumkonfliktaufzeichnungen und kommerzielle Flugprotokolle normalerweise nicht mit der Genehmigungsseite veröffentlicht. Remote ID sollte auch nicht als handelsübliche Open-Source-Flugbahnbibliothek behandelt werden: Das GAO empfahl der FAA im Jahr 2024 immer noch, Pfade zu identifizieren, die vernetzte Echtzeit-Standort-/Statusdaten von Drohnen liefern [47]. Daher sollte die starke Aussage von G1 lauten:> Wir erstellen einen realkontext- und realflugkalibrierten Agenten-Benchmark für niedrige Flughöhen und überlassen die vollständig realen Betriebsprotokolle der Flotte der künftigen Zusammenarbeit mit dem Betreiber. ### 8.1.2 Daten-Tiering-Strategie CloudBrain-Bench empfiehlt die Unterteilung in drei Vertrauensstufen: | Hierarchie | Name | Datenzusammensetzung | Rolle in der Zeitung | |------|------|----------|----------------| | L1 | „Synthetisch gesteuert“ | Programmstadt, Programmluftraum, Programmaufgabe | Kontrollierbarer Masterkontrast, Ablation, statistische Stabilität | | L2 | „Realer Kontext“ | OSM/Overture + FAA UASFM + NOAA/Open-Meteo + Programmaufgaben | Hauptprioritätsschicht des Experiments, die eine echte Kontexterdung beweist | | L3 | „Real-Flight-Calibrated“ | L2 + DJI M100 Flugenergieverbrauch/ETA-Parameterkalibrierung | Kalibrierungsanalyse und Überprüfung der tatsächlichen Flugempfindlichkeit | Es wird nicht empfohlen, L3 als „echten operativen Benchmark“ zu bezeichnen. Eine stabilere Demontagemethode ist: - **Aufgaben und Goldspur**: werden weiterhin durch einen deterministischen Generator, Planer und Verifizierer generiert, um den wahren SAT/UNSAT-Wert sicherzustellen. - **Stadt-/Luftraum-/Wetterkontext**: Überprüfen Sie so realistisch wie möglich, dass der Agent auf realen Objekten und realen Luftraumfeldern landet. - **Energieverbrauchs-/ETA-Modell**: Verwenden Sie reale Flugdaten zur Anpassung oder Eimerkalibrierung, um zu überprüfen, dass Sicherheitsbeurteilungen nicht auf willkürlichen Energieverbrauchsparametern basieren. ### 8.1.3 Rezept zur Erfassung realer Daten Um die erste Arbeit reproduzierbar zu machen, empfiehlt es sich, die Datenerfassung als feste Pipeline zu schreiben:| Schritt | Eingabe | Betrieb | Ausgabe | |------|------|------|------| | 1 | Stadtbegrenzungsrahmen | Verwenden Sie Overpass, um Krankenhaus, Schule, Park, Polizei, Feuerwehr, Gebäude, Straße | abzufragen `city_osm.geojson` | | 2 | Die gleiche bbox | Verwenden Sie Overture Places/Buildings, um POI und Gebäudegrundfläche zu ergänzen und eine stabile Entitäts-ID beizubehalten | `city_overture.parquet` | | 3 | FAA UASFM-Daten herunterladen / bbox | UASFM-Polygon, „CEILING“, Flughafen-/Luftraum-/LAANC-Felder lesen | `uasfm_cells.geojson` | | 4 | nächstgelegene ICAO-Stationen + Zeitfenster | Fragen Sie NOAA METAR JSON ab und extrahieren Sie Wind-, Sicht-, Niederschlags-/Wetter-Tokens | `aviation_weather.parquet` | | 5 | Breiten- und Längengrad und Zeitraum | Abfrage historischer/vorhersagender Open-Meteo-Wetterdaten als Nicht-Flughafen-Ergänzung | `weather_grid.parquet` | | 6 | Wissenschaftliche Daten DJI M100-Dateien | Analysieren Sie Position, Spannung, Strom, Wind, Nutzlast, Höhe, Geschwindigkeit | `uav_flight_kalibration.parquet` | | 7 | Ausgewählte Städte und Termine | Beispiel NYC TLC / Chicago Taxi OD zur Erstellung einer Nachfrage-Heatmap | `od_proxy.parquet` | | 8 | OSM-Straßendiagramm | SUMO importieren, Boden-Fallback-Reisezeit schätzen | `ground_time_matrix.parquet` | | 9 | UTM/UASFM/CORUS/NASA TCL4 | HandbuchRegelvorlagen und Szenariotaxonomie organisieren | `airspace_rules.yaml` | | 10 | echter Kontext + kalibrierte UAV-Parameter | Programmerstellung UAV-Aufgaben, NFZ, Korridor, Aufladen, Wetterrisiko | `cloudbrain_samples.jsonl` | | 11 | Proben | Planer/Verifizierer/Simulator kommentiert automatisch SAT/UNSAT, Goldspur, Gegenbeispiel | `cloudbrain_gold.jsonl` |Das Hauptexperiment basiert minimal auf den Schritten 1, 3, 9, 10 und 11; Die Schritte 4–8 bieten reales Wetter, Kalibrierung des Energieverbrauchs und Boden-Fallback. Bei jeder Erfassung müssen der ursprüngliche Datei-Snapshot, die Datenfeldversion und das Download-Datum gespeichert werden, um zu verhindern, dass spätere Änderungen an FAA-/NOAA-/Kartendaten zu Nichtreproduzierbarkeit führen. ### 8.1.4 So ordnen Sie reale Daten einem Benchmark zu | Reale Felder | Zu CloudBrain zuordnen | Verwendung | |----------|-----------|----------| | OSM `amenity=hospital/school/fire_station` | `origin`, `destination`, `sensitive_zones` | Befehlsentitätsverbot | | Grundriss des Overture-Gebäudes | Hindernispolygone | Routenplaner/Simulator | | UASFM „FORM“, „DECKE“ | Höhenkappenzellen | Rückgabe des Tools „query_airspace“ | | UASFM-Flughafen-/Luftraumfelder | Herkunft des Luftraums | Erläuterung und Richtlinienfelder | | NOAA METAR Wind/Sicht/Wetter | Wetterrisiko | `risk_assess`, Stressszenarien | | M100 Position/Geschwindigkeit/Höhe | Routen-/ETA-Kalibrierungsbehälter | ETA-Verteilung | | M100 Strom/Spannung/Nutzlast/Wind | Kalibrierung des Energiemodells | Batteriereserveprüfung | ### 8.1.5 Echte Flugkalibrierungsaufgabe Verwenden Sie die DJI M100-Daten nur für das, was Sie unterstützen können:1. Je nach Nutzlast, Reisegeschwindigkeit, Höhe und Wind in Eimer aufteilen. 2. Erhalten Sie einen Flugenergie- oder Energieverbrauchs-Proxy aus der Spannungs- und Stromintegration. 3. Passen Sie „energy_per_meter“, „eta_multiplier“ oder eine konservative Quantilsuche an. 4. Ordnen Sie die Routenlänge des synthetischen Planers der Energieschätzung und dem Urteil zur Batteriereserve zu. 5. Geben Sie im Anhang an, ob sich die Sicherheitsentscheidung unter kalibrierten und unkalibrierten Energiemodellen ändert. Es wird empfohlen, in der ersten Version konservative Quantile anstelle komplexer Black-Box-Energieverbrauchsnetzwerke zu verwenden:

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 Dabei steht $e$ für den Energieverbrauch pro Distanzeinheit, $v$ für die Geschwindigkeit, $h$ für die Höhe, $p$ für die Last und $w$ für die Windbedingungen. Auf diese Weise können reale Flugdaten in die Sicherheitsüberprüfung integriert werden, ohne dass G1 zu einem Energieverbrauchs-Modellpapier wird. ### 8.1.6 Echtdaten-Split-Design | Geteilt | Datenschicht | Funktion | |-------|--------|------| | `test_synthetic_controllered` | L1 | Hauptablation, kontrollierbare Schwierigkeit | | `test_real_context_city_a` | L2 | Realer Stadt-/Luftraum-/Wetterkontext | | `test_real_context_city_b` | L2 | unsichtbare Stadtverallgemeinerung | | `test_real_weather_stress` | L2 | METAR/Open-Meteo-Wetterrisiko | | `test_energy_kalibriert` | L3 | Batterie-/ETA-Sicherheit nach echter Flugkalibrierung |Die Haupttabelle der Arbeit kann sowohl L1 als auch L2 gegeben werden; L3 wird als Kalibrierungsanalysetabelle oder Anhang empfohlen. Wenn der L2-Effekt stabil ist, kann die Zusammenfassung als „Real-Context-Benchmark“ geschrieben werden. Wenn L3 auch stabil ist, schreiben Sie erneut „Echtflugkalibrierte Auswertung“. ### 8.1.7 Codeskizze für die reale Datenerfassung Mischen Sie UASFM- und METAR-Loader nicht in Agent-Tools. Bereiten Sie zuerst Offline-Daten vor: ```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) ``` Echter Flugkalibrierungslader: ```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 Stadt- und Szenenparameter Es wird empfohlen, dass in der ersten Version vier Arten der Stadtgestaltung festgelegt werden: | Stadttyp | Rastergröße | POI-Eigenschaften | Risiko geringer Höhe | Verwendung | |----------|----------|----------|----------|------| | `grid_city` | 50 x 50 x 6 | Regelmäßiges Straßennetz, einheitlicher POI | Niedrig | Gesundheitscheck | | `downtown_city` | 80 x 80 x 8 | Hohe Bebauungsdichte, intensive Krankenhäuser/Schulen | Hoch | Hauptexperiment | | `suburban_city` | 100 x 100 x 5 | POI spärlich, große Entfernung | mittel | Batterie/Frist | | `mixed_city` | 120 x 120 x 10 | Gemischte Gewerbegebiete, Wohngebiete, Verkehrsknotenpunkte | Hoch | unsichtbare Verallgemeinerung | Räumlicher Maßstab:| Parameter | Standard | Reichweite | |------|------|------| | Zellgröße | 10m | 5-20 m | | Höhenschichten | 6 | 3-12 | | maximale Höhe | 120 m | 60-150 m | | Korridorbreite | 20 m | 10-40 m | | Flugverbotszonen | 3-12 pro Karte | 0-20 | | sensible Zonen | 5-30 pro Karte | 0-50 | | Ladepads | 3-10 pro Karte | 1-20 | | UAV-Anzahl | 10 / 30 / 50 | 5-100 | Aufgabenparameter: | Parameter | Standard | Beschreibung | |------|------|------| | Terminknappheit | mittel | locker / mittel / eng / unmöglich | | Prioritätsverteilung | 60/25/10/5 | normal/hoch/kritisch/niedrig einstellbar | | Batterieverteilung | Beta-ähnlich | Erstellen Sie Edge-Cases mit niedrigem Batteriestand | | Wetterrisiko | keine/niedrig/mittel/hoch | Stress-Split-Medium zu erhöhen | | Nachfrage platzte | 1x / 2x / 4x | Testkorridor und Planer | ### 8.1.9 Regelvorlage Die erste Version verfügt nur über 8 Arten von Regeln, die zum Schreiben einer Arbeit ausreichen und reproduziert werden können:| Regel-ID | Natürliche Sprache | LTL/STL/Programmprüfung | |---------|----------|------------------| | R1 | Nichtbetreten der vorübergehenden Flugverbotszone | `G not_in_nfz` | | R2 | Halten Sie stets den Mindestsicherheitsabstand | ein STL-Robustheit: `dist_to_obstacle > d_min` | | R3 | Die Höhe bleibt im erlaubten Bereich | `G height_min <= z <= height_max` | | R4 | Kommen Sie vor Ablauf der Frist an | `F[0, Deadline] at_goal` | | R5 | Batterie nach Rückgabe/Ankunft reservieren | Programmprüfung | | R6 | Korridorkapazität überschreitet den Grenzwert nicht | Kapazitätsmonitor | | R7 | Kritische Aufgaben haben Priorität, können aber nicht außer Kraft gesetzt werden. Sicherheit | Richtlinienprüfung | | R8 | Wird ausgelöst, wenn nicht genügend Informationen vorhanden sind oder die Sicherheitsverweigerung des UNSAT/eine menschliche Bestätigung vorliegt | Ablehnungsprüfung | ### 8.1.10 Datenqualitätskontrolle CloudBrain-Bench muss „LLM-generierte Spam-Tags“ vermeiden. Es wird empfohlen, dass jede Probe vier Arten von Qualitätsfeldern aufzeichnet: | Feld | Beschreibung | |------|------| | `generation_seed` | Zufällige Samen für Wiederholungsexperimente | | `source_provenance` | OSM/Ouvertüre/Regelvorlage/Programmgenerierungsquelle | | `label_verifier` | Von welchem ​​Prüfgerät stammt das SAT/UNSAT-Label | | `human_review_status` | ungeprüft / sampled_pass / sampled_fail / korrigiert | Stichprobeninspektionsstrategie: - Überprüfen Sie nach dem Zufallsprinzip mindestens 30 Elemente für jeden Szenariotyp. - Überprüfen Sie nach dem Zufallsprinzip mindestens 20 Elemente für jeden Fehlermodus. - Erhöhung der Abtastrate von Stress- und UNSAT-Proben auf 15–20 %; - Nur natürliche Sprache und Erklärungen werden manuell geändert, und Planer-/Prüfer-Tags werden nicht manuell geändert, um die Einführung subjektiver Tags zu vermeiden.### 8.2 Beispielformat Jede Probe enthält: ```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 Szenentyp | Szene | Anteil | Schwierigkeit | |------|------|------| | Normale Lieferung | 15 % | Normale Termin- und Wegeplanung | | Notfalllieferung | 15 % | Priorität, Frist, Risikokompromiss | | Patrouille / Inspektion | 10 % | Zeitliche Einschränkungen mehrerer Wegpunkte | | Vermeidung von Flugverbotszonen | 15 % | LTL/STL-Sicherheitseinschränkungen | | Überlastung des Korridors | 10 % | Luftraumkapazität und Latenz | | Ladeengpass | 10 % | Leistungseinschränkungen und Fallback | | Wetter-/Windrisiko | 10 % | Risikobewertung und Ablehnung | | Multimodaler Fallback | 10 % | UAV-Bodentransfer | | UNSAT / mehrdeutige Aufgaben | 5 % | Sichere Ablehnungen und Klarstellungen | ### 8.4 Datenskala Machbarer Maßstab der ersten Version: | Geteilt | Anzahl der Proben | Zweck | |-------|--------|------| | Dev-mini | 200 | Schnelle Debugging-Pipeline | | Zugartig | 3000 | wenige Schüsse, RAG, Reparaturspeicher, nicht für Haupttraining verwendet | | Validierung | 1000 | Eingabeaufforderung/Modellauswahl | | Test-gesehene-Stadt | 1000 | Haupttest | | Test-unsichtbare-Stadt | 1000 | Verallgemeinerung | | Teststress | 1000 | Stresstest am gefährlichen Ort | Insgesamt gibt es etwa 7200 Beispiele, was ausreicht, um das erste Benchmark-/Methodenpapier zu unterstützen. Nachfolgende G2-Feinabstimmung wird auf 50.000 bis 100.000 Werkzeugspuren erweitert. ### 8.5 Gold-Label-GenerierungGold sollte nicht ausschließlich durch LLM generiert werden. Empfohlener Prozess: 1. Generieren Sie prozedural Städte, Missionen, UAV-Status und Regeln. 2. Die Regelvorlage generiert Gold „LowAltitudeIR“. 3. Rufen Sie deterministische Tools auf, um die Gold-Tool-Spur zu erhalten. 4. Planer/Prüfer/Simulator bestimmt SAT/UNSAT. 5. Der LLM-Lehrer ist nur für die Umschreibung in natürlicher Sprache und einen kleinen Teil des Erklärungstextes verantwortlich. 6. Probenahme von 5–10 % für die manuelle Inspektion, wobei der Schwerpunkt auf Hochrisiko- und UNSAT-Proben liegt. ### 8.6 Datendateiorganisation Es wird empfohlen, dass das endgültige Open-Source- oder interne Reproduktionsexperiment die folgende Struktur verwendet: ```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 Statistiken müssen gemeldet werden Papiertabelle 2 berichtet mindestens: | Statistische Elemente | Muss melden | |--------|----------| | Gesamtzahl der Proben | gesamt / pro Split | | Szenariotypverteilung | 9 Kategorien Szenariotyp | | SAT/UNSAT-Verhältnis | insgesamt + pro Szenario | | Anzahl der Städte | gesehen / unsichtbar | | Datenebene | Anzahl und Anteil der L1/L2/L3-Proben | | Echte Kontextfeldabdeckung | OSM/Overture/UASFM/NOAA/Open-Meteo Snapshot-Berichterstattung | | UAV-Nummernverteilung | min / median / max | | Anzahl der Einschränkungen | Durchschnittliche Anzahl von Einschränkungen pro Aufgabe | | Werkzeugaufruflänge | Durchschnittliche Länge der Goldspur | | Fehlertypverteilung | no_path/nfz/battery/deadline/ambiguity | | Manuelles Abtastverhältnis | bestanden / korrigiert | --- ## 9. Modellauswahl und Bereitstellungsplan ### 9.1 Im ersten Artikel wird nicht empfohlen, zunächst ein großes vertikales Modell zu trainieren Die Hauptlinie von G1 ist die Agentenmethode und der geschlossene Verifizierungskreislauf. Das vertikale Modelltraining wird im nachfolgenden G2 platziert. G1 kann ein leichtes SFT-Vorexperiment enthalten, es sollte jedoch nicht entscheidend für den Erfolg oder Misserfolg der Arbeit sein. ### 9.2 Empfohlene Modellmatrix| Rolle | Modell | Verwendung | Erforderlich | |------|------|------|----------| | Lehrer / Obergrenze | GPT-5.2 oder gleichwertige API | Daten generieren, Baseline stärken, Fehleranalyse | Ja | | Lokales Hauptmodell | Qwen3-14B / Qwen3-32B | Hauptexperiment reproduzierbares Mittel | Ja | | Lokales Argumentationsmodell | DeepSeek-R1-Distill-Qwen-14B/32B | Reparatur, Gegenbeispiel-Argumentation | Ja | | Modell mit geringer Latenz | Qwen3-8B | Ablation mit geringer Latenz | Optional | | Einbetten | Qwen3-Einbettung / BGE-M3 | RAG- und Sicherheitsspeicherabruf | Ja | GPT-5.2 gilt offiziell als geeignet für Codierungs- und Agentenaufgaben und kann als starker Lehrer und als Obergrenze für geschlossene Quellen verwendet werden [10]. Der technische Bericht von Qwen3 legt den Schwerpunkt auf Argumentation, Befehlsfolge, Agenten- und Mehrsprachigkeitsfähigkeiten und eignet sich als lokales Open-Source-Hauptmodell [11]. DeepSeek-R1 bietet auf Qwen/Llama destillierte 14B/32B-Argumentationsmodelle, die für die Reparatur von Gegenbeispielen geeignet sind [12]. ### 9.3 Lokal oder API Empfohlene **Hybridarchitektur**: | Bühne | API | Lokal | |------|-----|------| | Woche 1-2 | Schnelle Verifizierungsaufforderung, Schema, Tool-Design | Synchrone Bereitstellung Qwen3-14B | | Woche 3-5 | Lehrer generiert Paraphrasen und schwierige Beispiele | Hauptlauf dev/validation | | Woche 6-8 | Obergrenze der Grundlinie | festlegen Hauptexperiment und reproduzierbare Ergebnisse | | Vor der Einreichung | Kleinere Fehleranalyse | Alle Kernexperimente sind lokal reproduzierbar |In der Haupttabelle des Papiers wird die Verwendung des lokalen Modells als Hauptmodell und des API-Modells als Obergrenze empfohlen. Dies hat nicht nur eine starke Wirkung, sondern vermeidet auch die Frage der Rezensenten, ob es reproduziert werden kann. ### 9.4 Schnelle Verarbeitungsimplementierung Bereitstellungsempfehlungen: ```text vLLM server -> OpenAI-compatible endpoint -> Agent runtime -> Tool registry / MCP servers -> verifier / simulator ``` vLLM bietet einen OpenAI-kompatiblen Server, der es lokalen Qwen/DeepSeek- und API-Modellen ermöglicht, eine Aufrufschnittstelle gemeinsam zu nutzen [33]. ### 9.5 Eingabeaufforderungs- und Inferenzkonfiguration Um die Reproduzierbarkeit sicherzustellen, müssen alle Modelle über feste Inferenzparameter verfügen: | Zweck | Temperatur | top_p | maximale Token | Reparatur K | Beschreibung | |------|-------------|-------|------------|----------|------| | Direktes LLM | 0,2 | 0,9 | 2048 | 0 | Direkte Ausgabeentscheidung | | Nur JSON | 0,0 | 1,0 | 2048 | 0 | Strukturierte Ausgabe zur Reduzierung der Zufälligkeit | | ReAct | 0,2 | 0,9 | 4096 | 0 | Argumentation/Handlung zulassen | | CloudBrain keine Reparatur | 0,0 | 1,0 | 4096 | 0 | Einzelne IR + Werkzeuge | | CloudBrain voll | 0,0 zuerst, 0,2 reparieren | 1,0 | 4096 | 3 | Das Reparaturrad lässt sich leicht lösen | Es wird empfohlen, die Eingabeaufforderung in vier Abschnitte zu unterteilen: 1. **Systemrolle**: Sie sind der Gehirnagent der Low-Altitude-Traffic-Cloud und geben keine direkten Kontrollmengen aus. 2. **IR-Schema**: Geben Sie das JSON-Schema und die Enumeration „LowAltitudeIR“ an. 3. **Tool-Registrierung**: Listet verfügbare Tools, Ein- und Ausgaben sowie Fehlertypen auf. 4. **Aktuelle Aufgabe/Status**: Aktuelle Aufgabe in natürlicher Sprache, UAV-Status, Karte, Luftraumregeln und historisches Feedback. Das Ausgabeformat muss festgelegt werden: ```json { "low_altitude_ir": {}, "rationale_summary": "one paragraph only", "uncertainty": { "needs_human_confirmation": false, "missing_information": [] } } ```Lassen Sie die Modellausgaben nicht als vollständige Gedankenkette zurück; Papiere und Systeme speichern nur kurze Begründungszusammenfassungen, Werkzeugverläufe und Prüfer-Feedback. ### 9.6 API und lokale Kostenerfassung Speichern Sie jedes Experiment: | Feld | Beschreibung | |------|------| | `Modellname` | API- oder lokaler Modellname | | `endpoint_type` | api/local_vllm | | `prompt_tokens` | Geben Sie das Token | ein | `completion_tokens` | Ausgabetoken | | `wall_time_sec` | End-to-End-Zeit | | `llm_time_sec` | LLM-Anrufzeit | | `tool_time_sec` | Werkzeugausführungszeit | | `repair_rounds` | Anzahl der Reparaturrunden | | `estimated_cost_usd` | Geschätzte API-Kosten, lokal können mit 0 oder GPU-Stunde | gefüllt werden Dies unterstützt die Einsatzanalyse von Tabelle 5. --- ## 10. Grundlinien ### 10.1 Hauptgrundlinie| Grundlinie | Beschreibung | Zu beantwortende Fragen | |----------|------|--------------| | Direktes LLM | Das Modell gibt den Entscheidungstext | direkt aus Wie unzuverlässig ist LLM Naked Running | | Nur JSON-LLM | Erfordert nur die Ausgabe von JSON IR, kein Tool zur Ausführung | Ist die eingegebene Ausgabe ausreichend | | ReAct-Eingabeaufforderung | Aufruf des Tools im ReAct-Stil, kein Schema/Verifizierer | Ist die Argumentations-Aktions-Schleife ausreichend? | Nur Werkzeuggebrauch | Es erfolgt ein Tool-Aufruf, aber keine Verifizierungsreparatur | Reicht das Tool aus | | Funktionsaufruf im BFCL-Stil | Bewertet nur, ob der Funktionsname und die Parameter korrekt sind, und führt keine physische Überprüfung durch | Ob der Erfolg des Funktionsaufrufs dem Erfolg des Cloud-Gehirns entspricht | | Politikagent im Tau-Bank-Stil | Verfügt über Tools und Richtlinienregeln, aber keinen UAV-Planer/Überprüfer | Ist die Befolgung der Domänenrichtlinie ausreichend | | Statusbehafteter Tool-Agent im ToolSandbox-Stil | Zustandsbehaftete Toolausführung und Umgang mit Informationsdefiziten | Der Beitrag der Stateful-Tool-Ausführung zu Aufgaben in geringer Höhe | | LLM+P-Stil | LLM wird in ein Planungsproblem umgewandelt und der Planer löst es | Wie viel kann der externe Planer lösen | | TrafficGPT-Stil | LLM nennt Fahrzeuge, keine UAVs formale Sicherheit | Basislinie für die Traffic-LLM-Orchestrierung | | CloudBrain-Agent ohne Simulator | Simulationsstresstests entfernen | Simulator-Feedback-Beitrag | | CloudBrain-Agent ohne Reparatur | Bei Fehler stoppen | Reparaturschleifenbeitrag | | CloudBrain-Agent voll | Vollständige Methode | Hauptmethode dieses Artikels | ### 10.2 Modellgrundlinie| Modell | Einstellungen | |-------|------| | GPT-5.2 | API-Obergrenze | | Qwen3-14B | lokales Haupt | | Qwen3-32B | lokal stärker | | DeepSeek-R1-Distill-Qwen-14B | lokale Reparaturbegründung | | Qwen3-8B | kleines Lokal | ### 10.3 Details zur Basisimplementierung Um zu vermeiden, dass Baselines von Prüfern als unfair angesehen werden, müssen für jede Baseline eindeutig Berechtigungen eingegeben werden: | Grundlinie | Sichtbare natürliche Sprache | Sichtbarer Status | Abrufbare Werkzeuge | Sichtbares Prüfer-Feedback | Reparierbar | |----------|--------------|----------|------------|------------------------|--------| | Direktes LLM | Ja | Zusammenfassungsstatus | Nein | Nein | Nein | | Nur JSON | Ja | Vollständiger Status | Nein | Nein | Nein | | ReAct | Ja | Vollständiger Status | Ja | Werkzeugfehler ohne Gegenbeispiel | Nein | | Nur Werkzeuggebrauch | Ja | Vollständiger Status | Ja | Werkzeugfehler | Nein | | LLM+P-Stil | Ja | Vollständiger Status | Planer | Planerergebnis | Nein | | CloudBrain ohne Prüfer | ja | Vollständiger Status | ja | nein | nein | | CloudBrain ohne Simulator | ja | Vollständiger Status | ja | Nur Prüfer | ja | | CloudBrain voll | ja | Vollständiger Status | ja | Verifizierer + Simulator | ja | Fairnessprinzip:- Alle Methoden verwenden dasselbe Basismodell; - Verwenden Sie für alle Methoden die gleiche Testaufteilung. - Alle Methoden haben das gleiche maximale Token-Budget; – Die maximale Anzahl an Toolaufrufen für ReAct und CloudBrain ist gleich; – Nur CloudBrain Full verwendet strukturierte Gegenbeispiele, da dies der Beitrag dieses Artikels ist. --- ## 11. Experimentelles Design ### 11.1 Experiment 1: Hauptergebnisse Frage: Ist CloudBrain-Agent vollständig besser als direktes LLM, ReAct, nur Tool-Nutzung und LLM+P? Daten: Test-gesehene-Stadt, Test-unsichtbare-Stadt, Test-Stress. Indikatoren: -Aufgabenerfolgsquote -Ausführbare Entscheidungsrate - Rate von Sicherheitsverstößen -Genauigkeit beim Werkzeugaufruf - Halluzinationsrate - Reparaturerfolgsquote -Latenz ### 11.2 Experiment 2: Ablationsexperiment | Ablation | Entfernung von Inhalten | Erwartete Auswirkungen | |----------|----------|----------| | kein typisiertes IR | Kostenloser Text-Tool-Aufruf | Tool-Call-Genauigkeit verringert | | kein Prüfer | Keine LTL/STL-Prüfungen | Sicherheitsverstöße nehmen zu | | kein Simulator | Kein Szenenstresstest | Stress-Pass-Abnahme | | keine Reparatur | Keine Iteration nach Verifizierungsfehler | ausführbare Ratensenkung | | keine Erinnerung | Historische Fehlerfälle nicht abrufen | Reparaturerfolg verringert | | kein RAG | Regeln/Zuordnungskontext nicht abrufen | Halluzinationsanstieg | ### 11.3 Experiment 3: Gegenbeispiel-Reparaturanalyse Reparaturpfad nach Ausfall des statistischen Verifizierers/Simulators:- Erfolgsquote der ersten Reparatur - Erfolgsquote der 2. Reparatur - Erfolgsquote der 3. Reparatur - Neue Verletzungsrate nach Reparatur - Die häufigsten Fehlertypen: NFZ, Frist, Batterie, Korridor, Entitätshalluzination ### 11.4 Experiment 4: Modell- und Bereitstellungsanalyse Vergleichen Sie die API mit nativen Modellen: | Modell | Indikatoren | |------|------| | GPT-5.2 | Deckeleffekte, Kosten, Verzögerungen | | Qwen3-14B | Lokal reproduzierbare Hauptergebnisse | | Qwen3-32B | Lokal starkes Modell | | DeepSeek-R1-Distill-Qwen-14B | Spezialfähigkeit reparieren | | Qwen3-8B | Kompromiss bei geringer Latenz | ### 11.5 Experiment 5: Verallgemeinerung Generalisierungsdimension: - Ungesehener Stadtgrundriss - unsichtbare POI-Namen - Unsichtbare Form einer Flugverbotszone -ungesehene Werkzeugkombination -ungesehenes Notfallszenario -höhere UAV-Dichte -höherer Nachfrageschock ### 11.6 Experiment 6: Sichere Ablehnung der Mensch-Maschine-Kollaboration Testen Sie, ob das Modell die Ausführung verweigern oder eine menschliche Bestätigung anfordern kann, wenn UNSAT oder unzureichende Informationen verfügbar sind. Beispiel: - Frist unmöglich - Alle UAV-Batterien unzureichend - Ziel innerhalb NFZ - Fehlendes Ziel - Konflikt zwischen Priorität und Sicherheitsregel ### 11.7 Experiment 7: Agentenzuverlässigkeit und Mehrrundenkonsistenz Unter Bezugnahme auf die „Pass^k“-Idee von $\tau$-bench führen Sie dieselbe Aufgabe $k$ wiederholt aus, um zu bewerten, ob der Agent die Aufgabe stabil abschließen kann [36]. Bei Verkehrsmissionen in geringer Höhe sind ein Erfolg, aber mehrere zufällige Misserfolge nicht sicher genug. Daher wird empfohlen, Folgendes zu melden:| Indikator | Bedeutung | |------|------| | `pass@1` | Einzellauf-Erfolgsquote | | `pass^3` | Erfolgsquote für die gleiche Aufgabe dreimal hintereinander | | `pass^5` | Der Anteil der gleichen Aufgabe, die fünfmal hintereinander erfolgreich war | | Richtlinieneinhaltung | Ob Luftraum-/Sicherheits-/manuelle Bestätigungsregeln eingehalten werden sollen | | Zustandskonsistenz | Ob der interne Zustand mit der Werkzeugrückkehr nach mehreren Runden von Werkzeugaufrufen übereinstimmt | | Umgang mit unzureichenden Informationen | Ob bei unzureichenden Informationen geklärt/zurückgewiesen werden soll, statt halluzinatorische Vervollständigung | Dieser Teil macht G1 nicht nur zu einer „Verkehrsanwendung“, sondern zu einem übertragbaren Beitrag zur allgemeinen Agentenzuverlässigkeit. ### 11.8 Experiment 8: Schichtung der Aufgabenschwierigkeit Um zu vermeiden, dass die Hauptergebnisse durch einfache Stichproben verdeckt werden, ist die Berichterstattung nach Schwierigkeitsgrad geschichtet: | Schwierigkeit | Definition | Probeneigenschaften | |------|------|----------| | Einfach | Einzelaufgabe, kein NFZ, lockere Frist | Normale Lieferung | | Mittel | 1-2 Sicherheitsbeschränkungen, normale Leistung | NFZ oder Batterie-Einzelfaktor | | Hart | Mehrere Einschränkungen, knappe Fristen, Überlastung der Korridore | Notfall + NFZ + Aufladen | | Extrem | Hohes Risiko oder nahe an UNSAT | Spannungsspaltung | | UNSAT | Keine realisierbare Sicherheitslösung | sichere Ablehnung / menschliche Bestätigung | In der Haupttabelle wird der Gesamtwert aufgeführt, im Anhang werden die einzelnen Schwierigkeitsgrade aufgeführt. Der Nutzen von CloudBrain dürfte bei Hard/Extreme/UNSAT am größten sein. ### 11.9 Experiment 9: Falsche Zuordnung Jede fehlgeschlagene Probe wird automatisch der ersten Fehlerstufe zugeordnet:| Bühne | Fehlertyp | |------|----------| | IR | ungültiges JSON, Schema fehlt, falsche Enumeration | | Erdung | nicht existierende Entität, falsche Zone, falsches UAV | | Werkzeug | falsches Tool, falsche Reihenfolge, ungültige Argumente | | Planung | kein Pfad, falsches UAV, Batterie nicht machbar | | Verifizierung | NFZ, Höhe, Entfernung, Frist, Kapazität | | Simulation | Kollision, Beinaheunfall, Wetterrisiko, Verzögerung | | Politik | unsichere Überschreibung, fehlende menschliche Bestätigung, falsche Ablehnung | | Erklärung | halluzinierter Grund, nicht unterstützte Behauptung | Es wird empfohlen, gestapelte Balken für das Fehleranalysediagramm zu verwenden: Verteilung der Fehlerstadien verschiedener Basislinien. Dies kann klar erklären, was CloudBrain behoben hat. --- ## 12. Definition von Bewertungsindikatoren ### 12.1 Strukturierte Output-Indikatoren **IR-genaue Übereinstimmung**:

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

You can't use 'macro parameter character #' in math mode **IR-Feld F1**: Berechnen Sie Präzision, Rückruf bzw. F1 für Felder wie Absicht, Entitäten, Einschränkungen und Werkzeugplan. ### 12.2 Werkzeugaufrufanzeige **Tool-Call-Genauigkeit**:

\text{TCA} = \frac{#\text{richtige Werkzeugaufrufe}}{#\text{alle Werkzeugaufrufe}}

äüää

\text{TDS} = \frac{#\text{Werkzeugketten, die alle Datenabhängigkeiten erfüllen}}{#\text{Werkzeugketten}}

You can't use 'macro parameter character #' in math mode Es misst, ob der Agent zuerst den Luftraum-/Stadtstatus abfragt, dann plant und überprüft, anstatt sich auf nachgelagerte Tools zu verlassen. ### 12.3 Ausführbarkeitsindikatoren **Ausführbare Entscheidungsrate**:

\text{EDR} = \frac{#\text{ausführbare Entscheidungen des Planers}}{N}

\text{TSR} = \frac{#\text{vollständig verifizierte und simulierte erfolgreiche Aufgaben}}{N}

You can't use 'macro parameter character #' in math mode ### 12.4 Sicherheitsindikatoren **Rate von Sicherheitsverstößen**:

\text{SVR} = \frac{#\text{Aufgaben mit Sicherheitsverstößen}}{N}

You can't use 'macro parameter character #' in math mode Zu den Verstoßarten gehören: - Eindringen in die Flugverbotszone; - Höhenverstoß; - Mindestabstandsverletzung; - Verletzung der Batteriereserve; - Fristverletzung; - unsicherer Fallback; - halluzinierte Erlaubnis. Die erweiterte Version des Tieftransports empfiehlt weitere Transportsicherheitsindikatoren:| Indikatoren | Definition | Zweck | |------|------|------| | LoWC-Proxy | Das Verhältnis unterhalb der jederzeit klaren Trennung | Messung des Risikos eines Trennungsverlusts | | NMAC-Proxy | Anzahl der Unterschreitungen der Nahkollisionsschwelle in der Luft | Maß für schweres, nahezu mittleres Risiko | | Risikoverhältnis | Der Anteil der Risikoereignisse im Verhältnis zur regelbasierten sicheren Basislinie | Verschiedene Szenarien vergleichbar machen | | Präzision bei der sicheren Ablehnung | Der Anteil der Ablehnungen/Anfragen zur manuellen Bestätigung, deren Ausführung wirklich unsicher ist | Verhindern, dass der Agent übermäßig konservativ ist | Im AAAI/IJCAI-Haupttext können nur SVR- und Verstoßtyp-Aufschlüsselungen gemeldet werden. Die T-ITS-Erweiterung sollte den LoWC/NMAC-Proxy und das Risikoverhältnis melden. ### 12.5 Halluzinationsindikator **Halluzinationsrate**:

\text{HR} = \frac{#\text{Ausgaben, die nicht vorhandene Entitäten/Werkzeuge/Regeln enthalten}}{N}

You can't use 'macro parameter character #' in math mode ### 12.6 Blinker reparieren **Reparaturerfolgsquote**:

\text{RSR} = \frac{#\text{fehlgeschlagene erste Versuche innerhalb von K Iterationen repariert}}{#\text{fehlgeschlagene erste Versuche}}

ü

\text{pass}^k = \frac{#\text{Aufgaben in allen erfolgreich } k \text{ wiederholte Durchläufe}}{N}

You can't use 'macro parameter character #' in math mode Diese Metrik eignet sich besser für sicherheitskritische Agenten als „pass@1“, da Verkehrswolkenhirne in geringer Höhe eine stabile Einhaltung der Regeln und keinen gelegentlichen Erfolg erfordern [36]. ### 12.7 Statistische Tests Mindestens 3 zufällige Samen pro Experiment. Hauptergebnisbericht:- Mittelwert ± Standardfehler; -gepaartes Bootstrap-Konfidenzintervall von 95 %; - McNemar-Test oder Bootstrap-Test vergleicht Erfolgs-/Misserfolgsindikatoren; - Median, S. 90, S. 95 für Latenz melden. ### 12.8 Hauptergebnistabellenvorlage Papiertabelle 3 kann direkt in diesem Format ausgefüllt werden: | Methode | Modell | TSR ↑ | EDR ↑ | SVR ↓ | HR ↓ | TCA ↑ | RSR ↑ | pass^3 ↑ | p95 Latenz ↓ | |--------|-------|-------|-------|-------|------|-------|-------|----------|---------------| | Direktes LLM | Qwen3-14B | - | - | - | - | N/A | N/A | - | - | | Nur JSON | Qwen3-14B | - | - | - | - | N/A | N/A | - | - | | ReAct | Qwen3-14B | - | - | - | - | - | N/A | - | - | | Nur Werkzeuggebrauch | Qwen3-14B | - | - | - | - | - | N/A | - | - | | LLM+P | Qwen3-14B | - | - | - | - | - | N/A | - | - | | CloudBrain ohne Reparatur | Qwen3-14B | - | - | - | - | - | N/A | - | - | | CloudBrain voll | Qwen3-14B | - | - | - | - | - | - | - | - | ### 12.9 Ablationstabellenvorlage| Variante | TSR ↑ | EDR ↑ | SVR ↓ | TCA ↑ | RSR ↑ | Haupterklärung | |---------|-------|-------|-------|-------|-------|----------| | Voll | - | - | - | - | - | Vollständige Methode | | kein typisiertes IR | - | - | - | - | - | Strukturierte Schnittstelle testen | | kein Prüfer | - | - | - | - | - | Testen Sie die formale Verifizierung | | kein Simulator | - | - | - | - | - | Rückmeldung der Druckmessung | | keine Reparatur | - | - | - | - | N/A | Gegenbeispiel-Reparatur testen | | keine Erinnerung | - | - | - | - | - | Testfehlerfall-Abruf | | kein RAG | - | - | - | - | - | Testregeln/Kartenkontext | ### 12.10 Mindesterfolgsschwelle Bevor Sie mit dem Verfassen einer Abschlussarbeit beginnen, wird empfohlen, mindestens diese Schwellenwerte zu erreichen: | Indikatoren | Mindestschwelle | Gründe | |------|----------|------| | CloudBrain vollständiger TSR | Mehr als 10 Prozentpunkte höher als ReAct | Methode Mastereinkommen | | SVR | Mehr als 30 % günstiger als Direct LLM | Sicherheitskritischer Wert | | TCA | Über 85 % | Zuverlässige Werkzeugaufrufe | | RSR | Mehr als 40 % | Gegenbeispiel-Reparatur ist wirksam | | pass^3 | Deutlich höher als bei reiner Werkzeugnutzung | Mehrrundenstabilität | | p95-Latenz | lokal 14B weniger als 60 Sekunden | einsetzbare Erzählung | --- ## 13. Erwartete experimentelle Schlussfolgerungen Bei den folgenden Angaben handelt es sich um Erwartungen vor der Registrierung, nicht um experimentelle Ergebnisse:1. Von CloudBrain-Agent Full wird erwartet, dass es hinsichtlich des Aufgabenerfolgs, der ausführbaren Entscheidungsrate und der Sicherheitsverletzungsrate besser ist als direktes LLM, ReAct und nur die Tool-Nutzung. 2. Es wird erwartet, dass die Eingabe von „LowAltitudeIR“ hauptsächlich die Genauigkeit des Werkzeugaufrufs, das IR-Feld F1 und die Halluzinationsrate verbessert. 3. Es wird erwartet, dass das Feedback des Verifizierers vor allem die Entscheidungsrate der ausführbaren Datei und die Erfolgsrate der Reparatur verbessert. 4. Es wird erwartet, dass das Simulator-Feedback in Stressszenarien, insbesondere bei Korridorüberlastung, Windrisiko und NFZ-Randfällen, am kritischsten ist. 5. Es wird erwartet, dass das lokale Qwen3-14B/32B als reproduzierbares Mastermodell dient, aber GPT-5.2 ist immer noch die Obergrenze. 6. Es wird erwartet, dass DeepSeek-R1-Distill-Qwen das gewöhnliche Instruct-Modell bei der Reparatur von Gegenbeispielen übertrifft. --- ## 14. Kartenplan| ID | Geben Sie | ein Inhalt | Priorität | |----|------|------|--------| | Abb. 1 | Architekturdiagramm | Der geschlossene Kreislauf des CloudBrain-Agenten von der Anweisung bis zur verifizierten Entscheidung | Hoch | | Abb. 2 | Flussdiagramm zur Datengenerierung | OSM/FAA/OD/SUMO/Simulator zu CloudBrain-Bench | Hoch | | Abb. 3 | Hauptergebnis-Histogramm | TSR, EDR, SVR, HR-Vergleich | Hoch | | Abb. 4 | Reparaturkurve | Verbesserte Erfolgsrate der Reparaturiteration 1-3 | Hoch | | Abb. 5 | Generalisierungs-Heatmap | Performance zu gesehener/unsichtbarer Stadt, Stress, UNSAT | Mittel | | Abb. 6 | Agentenkonsistenzkurve | „pass@1“, „pass^3“, „pass^5“ und Zustandskonsistenz | Mittel | | Tabelle 1 | Vergleich verwandter Arbeiten | LLM-Verkehr, Tool-Nutzung, Planung, formale Verifizierung, dieser Artikel | Hoch | | Tabelle 2 | Datensatzstatistik | Szenariotyp, SAT/UNSAT, Stadt, Anzahl der Aufgaben | Hoch | | Tabelle 3 | Hauptergebnisse der Baseline | Vergleich aller Indikatoren | Hoch | | Tabelle 4 | Ablation | Leistungsänderungen nach Komponentenentfernung | Hoch | | Tabelle 5 | Modellbereitstellung | Wirkung, Latenz, Kosten der API vs. lokal | Mittel | | Tabelle 6 | Reproduzierbarkeit der Datenquelle | URL jedes Datentyps, Lizenz, ob das Hauptexperiment davon abhängt, Fallback | Mittel | --- ## 15. Papierstrukturplanung Komprimiert durch den Haupttext der Seiten 7-8 von AAAI/IJCAI: ### Zusammenfassung 150-200 Wörter. Heben Sie den Schlüssel zur Verkehrssicherheit in geringer Höhe, zur LLM-Unzuverlässigkeit, zum CloudBrain-Agent, zum Benchmark und zu den Kernergebnissen hervor. ### 1 Einführung Inhalt:- Hintergrund einer Verkehrswolke in geringer Höhe; - Risiken der direkten Entscheidungsfindung durch LLM; - Die Notwendigkeit eines Werkzeugaufrufs und einer geschlossenen Verifizierungsschleife; - Drei Beiträge zu diesem Artikel; - Abb. 1 Heldenfigur. ### 2 Verwandte Arbeiten Drei Absätze: 1. LLM für Transport und räumlich-zeitliche Intelligenz; 2. LLM-Agenten, Werkzeugnutzung und Planung; 3. Formale Verifizierung und UAV/UTM-Simulation. ### 3 Problemeinrichtung Definieren Sie Zustände, Aufgaben, „LowAltitudeIR“, Tools, Erfolgsbedingungen und Sicherheitsbeschränkungen. ### 4 Methoden Einführung von CloudBrain-Agent: - Kontextersteller; - LowAltitudeIR-Parser; - Werkzeugfräser; - Verifizierer/Simulator; - Reparaturschleife; -Sicherheitsspeicher. ### 5 CloudBrain-Bench Stellt Datenquellen, Generierungsprozesse, Szenariotypen, Aufteilungen, Goldlabels und Reproduzierbarkeit vor. ### 6 Experimente Hauptergebnisse, Ablation, Reparaturanalyse, Generalisierung, Modellbereitstellung. ### 7 Fazit Fassen Sie die Beiträge zusammen und schreiben Sie ehrlich über die Einschränkungen: synthetischer Benchmark, realer Luftraumeinsatz wurde nicht verifiziert und Human-in-the-Loop ist weiterhin erforderlich. --- ## 16. Implementierungsroute ### 16.1 Minimal lebensfähiges System Tun Sie dies nur im ersten Monat: ```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 Empfohlener Technologie-Stack| Module | Technologie | |------|------| | Agentenlaufzeit | Python + Pydantic + LiteLLM/OpenAI-Client | | Lokales Modell | vLLM OpenAI-kompatibler Server | | Werkzeugprotokoll | Python-Funktionen zuerst, MCP-Wrapper zweitens | | IR-Validierung | Pydantic JSON-Schema | | Planer | 3D A* zuerst, RRT* optional | | Prüfer | Spot für LTL, RTAMT für STL | | Simulator | leichter Gitter-/Korridorsimulator | | RAG | Qdrant/FAISS + Qwen3-Embedding/BGE-M3 | | Lagerung | JSONL + Parkett + DuckDB | | Auswertung | Pandas + Scipy + Bootstrap | ### 16.2.1 Codemodulschnittstelle Es wird empfohlen, dass jedes Modul die Mindestschnittstelle offenlegt: ```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 ``` Hauptfunktion des Läufers: ```python def run_agent(sample: dict, model: str, config: AgentConfig) -> AgentTrace: ... ``` Hauptfunktion der Auswertung: ```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 Experimenteller Befehlsentwurf Es wird empfohlen, diese Befehle zu verwenden, um das Problem nach einer zukünftigen Implementierung zu reproduzieren: ```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 Konfigurationsdateivorlage ```yaml experiment: name: cloudbrain_main_qwen3_14b seed: 42 split: test_seen_city max_repair_rounds: 3 model: provider: local_vllm name: qwen3-14b temperature: 0.0 top_p: 1.0 max_tokens: 4096 tools: enable_city: true enable_airspace: true enable_scheduler: true enable_planner: true enable_verifier: true enable_simulator: true enable_risk: true evaluation: bootstrap_samples: 1000 report_pass_k: [1, 3, 5] latency_percentiles: [50, 90, 95] ``` ### 16.3 10-wöchiger Ausführungsplan| Woche | Ziele | Leistungen | |----|------|--------| | 1 | Problemformulierung und IR-Schema einfrieren | `LowAltitudeIR v0.1` | | 2 | Stadt-/Luftraum-/UAV-/Aufgabengenerator implementieren | 200 Entwicklungsbeispiele | | 3 | Planer/Prüfer/Simulator implementieren | deterministische Goldetiketten | | 4 | Implementieren Sie Agent Runner und Direct/ReAct-Baselines | dev-mini-Ergebnisse | | 5 | Erweiterung von CloudBrain-Bench auf 3000+ | Validierungsaufteilung | | 6 | Führen Sie die lokale Obergrenze von Qwen3-14B und GPT-5.2 aus | Hauptgrundlinientabellenentwurf | | 7 | Implementieren Sie Reparaturschleife, Speicher, Ablation | Ablationsergebnisse | | 8 | ungesehen laufen/Stress/UNSAT | Verallgemeinerungszahlen | | 9 | Statistische Tests, Fehleranalyse, Grafiken | Entwurf für fotorealistische Figuren | | 10 | Schreiben des ersten Entwurfs von AAAI/IJCAI | Vollständiger Papierentwurf | ### 16.4 Wöchentliche Akzeptanzkriterien| Woche | Befehle, die ausgeführt werden müssen | Akzeptanzkriterien | |----|----------------|----------| | 1 | Schemavalidierungsskript | 20 handgeschriebene IRs, alle korrekt verifiziert | | 2 | Datengenerator | 200 Proben generiert, geteilte Statistiken, keine leeren Felder | | 3 | Tool-Unit-Tests | Planer/Verifizierer/Simulator mindestens 30 Unit-Tests | | 4 | dev-mini-Basislinie | direkt/ReAct/CloudBrain kein Reparaturdurchlauf | | 5 | Validierungsaufteilung | Über 3000 Proben, Erstellung des Gold-Labels abgeschlossen | | 6 | Modellmatrix | Qwen3-14B und GPT-Obergrenze haben Ergebnisse | | 7 | Ablation | kein IR/kein Verifizierer/keine Reparatur/keine ausführbare Simulatordatei | | 8 | Stress/UNSAT | Stress- und sichere Verweigerungsindikatoren können berechnet werden | | 9 | Figuren | 6 Abbildungen und 6 Tabellen automatisch generierter Entwurf | | 10 | Papierentwurf | Der Haupttext ist vollständig und die Anhänge enthalten Schema und Datenbeschreibung | ### 16.5 Empfohlenes Codeverzeichnis v1 Es wird empfohlen, die erste Version der Codebasis klein und übersichtlich zu halten und zunächst für Thesexperimente zu dienen, anstatt sie zu Beginn zu einer großen Plattform zu machen. ```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 Details zum Pydantic-Schemacode „LowAltitudeIR“ sollte starke Typbeschränkungen verwenden und versuchen, Fehler nach der LLM-Ausgabe und vor der Ausführung des Tools zu blockieren. ```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 ``` Die Entitätserdung sollte nicht in Pydantic geschrieben, sondern separat erfolgen, da sie auf der aktuellen Karte und dem UAV-Status basiert. ```python def validate_entity_grounding(ir: LowAltitudeIR, state: SystemState) -> ValidationReport: errors: list[ValidationErrorItem] = [] known_entities = state.known_entity_ids() known_uavs = state.known_uav_ids() for field_name in ["origin", "destination"]: value = getattr(ir.entities, field_name) if value is not None and value not in known_entities: errors.append( ValidationErrorItem( stage="entity_grounding", field=f"entities.{field_name}", value=value, error_type="unknown_entity", ) ) for uav_id in ir.entities.candidate_uavs: if uav_id not in known_uavs: errors.append( ValidationErrorItem( stage="entity_grounding", field="entities.candidate_uavs", value=uav_id, error_type="unknown_uav", ) ) return ValidationReport(valid=not errors, errors=errors) ``` ### 16.7 ToolRegistry-CodedetailsAlle Tools implementieren die gleiche Schnittstelle, wodurch es einfach ist, die deterministische/erlernte/externe MCP-Version zu ersetzen. ```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 Planer und Simulator mit minimalem Codedesign Die erste Version von 3D A* muss lediglich Raster, NFZ-Maske, Höhenbereich und Batterie-/Längenschätzung unterstützen. ```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") ``` Der Leichtbau-Simulator kann in diskreter Zeit weiterentwickelt werden: ```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 Verifier minimales Codedesign Die erste Version kann LTL/STL in zwei Schichten unterteilen: Gemeinsame Regeln werden durch den Programmprüfer sichergestellt, um die Stabilität zu gewährleisten, und komplexe Ausdrücke werden an Spot/RTAMT übergeben. ```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) ``` Die Komprimierung des Gegenbeispiels sollte kurz sein. Setzen Sie nicht den gesamten Titel zurück in den Eingabeaufforderungsbereich: ```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 Details zum Agent-Runner-Code „run_agent“ muss den Trace vollständig speichern, um reproduzierbare Experimente und Fehleranalysen zu ermöglichen. ```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 ``` Es wird empfohlen, jede Zeile von JSONL zu speichern: ```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 Details zum Evaluierungscode Die Metrik sollte automatisch aus Spuren und Gold berechnet werden, um eine manuelle subjektive Beurteilung zu vermeiden. ```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, ) ``` Berechnungsmethode „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 Unit-Testplan Die erste Testphase sollte die grundlegenden Fragen abdecken, „keine falschen Papierexperimente zu schreiben“:| Testdateien | Inhalt testen | |----------|----------| | `test_ir_schema.py` | Enumeration, erforderliche Felder, Höhenbereich, Leistungsverhältnis | | `test_entity_grounding.py` | Kein UAV/POI/NFZ kann gefangen werden | | `test_tool_registry.py` | Nicht registriertes Tool, doppelte Registrierung, Fehlerrückgabeformat | | `test_planner.py` | Einfache Erreichbarkeit, NFZ-Blockierung, keine Pfaderreichbarkeit | | `test_verifier.py` | NFZ, Frist, Distanzrobustheit | | `test_simulator.py` | Kollision, Beinaheunfall, Wetterrisiko | | `test_agent_runner.py` | Schemafehler -> Reparatur, Verifiziererfehler -> Reparatur, nicht behebbar -> Ablehnung | | `test_metrics.py` | TSR, SVR, TCA, RSR, pass^k-Berechnung | Empfohlenes Mindesttestbeispiel: ```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 Implementierungspriorität der ersten Version Machen Sie nicht alle Module gleichzeitig. Es wird empfohlen, nach „Mindestbeweiskette des Papiers“ zu sortieren:| Priorität | Modul | Warum es zuerst tun | |--------|------|------------| | P0 | „LowAltitudeIR“-Schema + Validatoren | Ohne sie können getippte IR-Beiträge nicht nachgewiesen werden | | P0 | deterministische Tools + Trace-Protokollierung | Alle Experimente basieren auf | | P0 | 3D A* + Basisprüfer | Unterstützen Sie ausführbare Dateien/Sicherheitsindikatoren | | P0 | Direct/ReAct/CloudBrain-Baseline-Runner | Bilden Sie die erste Haupttabelle | | P1 | Simulator Stresssamen | Unterstützen Sie sicherheitskritische Narrative | | P1 | Reparaturschleife + Gegenbeispielkomprimierung | Kernmethode dieses Artikels | | P1 | Metriken + Aggregation | Verhindern Sie, dass Ergebnisse reproduzierbar sind | | P2 | OSM/Overture/Open-Meteo-Lader | Verbesserter Realismus | | P2 | MCP-Wrapper | Verbessern Sie die technische Erzählung, ohne das Papier zu blockieren | | P3 | AirSim/Flightmare | Nachträgliche Erweiterung, ohne G1 | zu blockieren ### 16.14 Details zum MCP-Wrapper-Code Die erste Version der Tools kann zunächst über die Python-Registrierung ausgeführt werden, und dann kann derselbe Satz an Tools auf einen MCP-Server gepackt werden. Dies hat den Vorteil, dass die Papierexperimente nicht in den Details der MCP-Technik hängen bleiben, sondern die Systemerzählung auf natürliche Weise mit der „Cloud-Brain-Tool-Ökologie“ verbunden werden kann. Die Empfehlungen zur Werkzeugbenennung für den MCP-Server stimmen mit denen der Python-Registrierung überein:| MCP-Tool | Python-Tool | Beschreibung | |----------|-------------|------| | `cloudbrain.query_city_state` | `query_city_state` | Stadtentität und Kartenstaat | | `cloudbrain.query_airspace` | `query_airspace` | Korridor, NFZ, Höhe, Kapazität | | `cloudbrain.assign_uav` | `assign_uav` | UAV-Aufgabenzuweisung | | `cloudbrain.plan_route` | `plan_route` | 3D-Routenplaner | | `cloudbrain.verify_ltl_stl` | `verify_ltl_stl` | Sicherheitsprüfer | | `cloudbrain.simulate_scenario` | `simulate_scenario` | Stresssimulator | | `cloudbrain.risk_assess` | `risk_assess` | Risikobewertung | MCP-Wrapper-Pseudocode: ```python from mcp.server.fastmcp import FastMCP from cloudbrain.tools.registry import build_default_registry from cloudbrain.tools.base import ToolContext mcp = FastMCP("cloudbrain-tools") registry = build_default_registry() @mcp.tool() def query_airspace(region: str, altitude_min_m: float, altitude_max_m: float, time_sec: int) -> dict: context = ToolContext.from_active_scenario() result = registry.execute_by_name( "query_airspace", { "region": region, "altitude_range": [altitude_min_m, altitude_max_m], "time_sec": time_sec, }, context, ) return result.model_dump() @mcp.tool() def plan_route(start: str, goal: str, avoid_zones: list[str], altitude_min_m: float, altitude_max_m: float) -> dict: context = ToolContext.from_active_scenario() result = registry.execute_by_name( "plan_route", { "start": start, "goal": goal, "avoid_zones": avoid_zones, "altitude_range": [altitude_min_m, altitude_max_m], }, context, ) return result.model_dump() if __name__ == "__main__": mcp.run() ``` MCP-technische Einschränkungen: – Der Rückgabewert des MCP-Tools verwendet weiterhin das Schema „ToolResult“, um zwei Protokollsätze zu vermeiden. - Der MCP-Server liest und schreibt die experimentellen Ergebnisse nicht direkt, sondern führt nur Tools aus; Spuren werden vom Agent Runner gespeichert. – Wenn der MCP-Aufruf fehlschlägt, muss der Agent-Runner in der Lage sein, auf die Python-Registrierung zurückzugreifen, um sicherzustellen, dass das Experiment nicht unterbrochen wird. - Es wird empfohlen, die Python-Registrierung und den MCP-Wrapper zu verwenden, um die Hauptergebnisse der Thesenexperimente in der Systemdemonstration oder im Anhang zu speichern. ### 16.15 Details zum Datengenerator-Code Der Datengenerator muss deterministisch sein und die Kerneingaben sind Seed und Config. ```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, ) ``` Die geteilte Generierung muss sicherstellen, dass keine Informationen verloren gehen: ```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" ```Der Generator muss geteilte Statistiken ausgeben: ```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 und lokale Modellstartlösung Das native Modell empfiehlt, den OpenAI-kompatiblen Endpunkt über vLLM verfügbar zu machen. Auf diese Weise verwaltet „llm_client.py“ nur eine Schnittstelle. Beispiel für einen Startbefehl: ```bash vllm serve Qwen/Qwen3-14B \ --host 0.0.0.0 \ --port 8000 \ --served-model-name qwen3-14b \ --tensor-parallel-size 1 \ --max-model-len 32768 ``` DeepSeek-Reparaturspezialist: ```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 ``` Einheitlicher Client-Pseudocode: ```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 {}) ``` Laufende Datensätze müssen in „model_manifest.json“ geschrieben werden: ```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 Caching, Protokollierung und Reproduktion Um die API-Kosten und die Experimentierzeit zu kontrollieren, werden alle LLM-Aufrufe, Tool-Aufrufe und Prüfergebnisse zwischengespeichert. Cache-Schlüssel: ```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}" ``` Empfohlenes Cache-Verzeichnis: ```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 ``` Jeder Trace muss Folgendes enthalten: - `sample_id` - „Methode“. - „Modell“. - „prompt_version“. - `config_hash` - „random_seed“. - `repair_rounds` - `final_status` - `metric_row` - `all_tool_results` - `all_verifier_results` ### 16.18 CI und Qualitätszugriffskontrolle Auch wenn es in der ersten Phase nur Planung und experimentellen Code gibt, müssen Quality Gates eingerichtet werden: ```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 ``` Der Smoke-Test verwendet nur Schein-LLM, um sicherzustellen, dass CI nicht von der GPU oder dem API-Schlüssel abhängt. Mock LLM gibt eine feste IR für die Validierungs-Toolchain, Metriken und Trace-Protokollierung zurück. ### 16.19 Konfiguration der Experimentmatrix Am Ende lief das Hauptexperiment mindestens mit dieser Matrix:| Geteilt | Methode | Modell | Wiederholen | |-------|--------|-------|--------| | Validierung | direct_llm/react/cloudbrain_full | qwen3-14b | 1 | | test_seen_city | alle Hauptgrundlinien | qwen3-14b | 3 | | test_unseen_city | alle Hauptgrundlinien | qwen3-14b | 3 | | test_stress | alle Hauptgrundlinien | qwen3-14b | 3 | | test_unsat | direct_llm/react/cloudbrain_full | qwen3-14b | 3 | | test_seen_city | cloudbrain_full | qwen3-8b / qwen3-32b / deepseek-repair / GPT-Obergrenze | 3 | Experimentelle Aufgaben automatisch generieren: ```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 Technische Materialien, die im Anhang der Arbeit enthalten sein sollten Zur Verbesserung der Reproduzierbarkeit enthält der G1-Anhang mindestens:| Anhang | Inhalt | |------|------| | A | Vollständiges „LowAltitudeIR“-JSON-Schema | | B | Tool-Registrierungsschema und Fehlertaxonomie | | C | Datengenerierungskonfiguration und Szenariotaxonomie | | D | Eingabeaufforderungsvorlagen für jede Baseline | | E | Vollständige Metrikdefinitionen und Bootstrap-Verfahren | | F | Zusätzliche Ablations- und Szenario-Ergebnisse | | G | Visualisierungen von Fehlerfällen | | H | Rechenbudget, Modellversionen, Cache-Richtlinie | --- ## 17. Risiken und Alternativen ### 17.1 Risiko: Die Auswirkung ist nicht offensichtlich Alternative: Erhöhen Sie das Stress/UNSAT-Verhältnis, um den Wert der Prüferreparatur hervorzuheben. und berichten Sie über die Vorteile bei verschiedenen Aufgabenschwierigkeiten. ### 17.2 Risiko: Lokales Modell ist zu schwach Alternative: Qwen3-32B wird für das Hauptexperiment verwendet und Qwen3-14B wird als einsetzbare Version verwendet; GPT-5.2 wird nur für die Obergrenze verwendet. DeepSeek-R1-Distill kann auch als reiner Reparaturspezialist eingesetzt werden. ### 17.3 Risiko: Daten werden als zu synthetisch wahrgenommen Alternative: Teilen Sie das Hauptexperiment in drei Ebenen auf: „Synthetic-Controlled“, „Real-Context“ und „Real-Flight-Calibrated“, die jeweils echte Programmwerte, reale Stadt-/Luftraum-/Wetter-Grounding-Werte und eine echte Flugenergieverbrauchskalibrierung melden. Die Papierbeschreibung ist eindeutig als Benchmark + Methode verfasst und überträgt UASFM-, METAR- oder DJI M100-Daten nicht übertrieben auf den tatsächlichen kommerziellen Flottenbetrieb. ### 17.4 Risiko: MCP-Implementierung verlangsamt den FortschrittAlternative: Die erste Version des Tools verwendet zunächst die Python-Funktionsregistrierung und beschreibt die Schnittstelle beim Senden als MCP-kompatibel. Echter MCP-Server-Release-Quellenanhang oder Folgeversion. ### 17.5 Risiko: Die formale Verifizierung ist zu aufwändig Alternative: LTL führt zunächst diskrete Ereignisbeschränkungen durch, und STL führt zunächst vier Arten kontinuierlicher Beschränkungen durch: Entfernung, Höhe, Frist und Batterie. Decken Sie zunächst nicht alle Vorschriften für niedrige Höhenlagen ab. ### 17.6 Risiko: Der Beitrag zum Agenten-Benchmark ist nicht allgemein genug Alternative: Teilen Sie die Aufgaben von CloudBrain-Bench in allgemeine Agentenbewertungsdimensionen auf: Werkzeugauswahl, Argumenterdung, Zustandsabhängigkeit, Richtlinieneinhaltung, Gegenbeispielreparatur, „pass^k“-Konsistenz. Auf diese Weise können auch Gutachter, die mit dem Transport in geringer Höhe nicht vertraut sind, seinen Beitrag zur Bewertung sicherheitskritischer Arbeitsstoffe verstehen. --- ## 18. Referenzen [1] AAAI. „AAAI-26 Main Technical Track: Call for Papers.“ URL: <https://aaai.org/conference/aaai/aaai-26/main-technical-track-call/> [2] IJCAI-ECAI 2026. „Call for Papers – AI and Robotics Special Track.“ 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 und Weizhu Chen. „LoRA: Low-Rank-Anpassung großer Sprachmodelle.“ *International Conference on Learning Representations (ICLR)*, 2022. URL: <https://openreview.net/forum?id=nZeVKeeFYf9> [4] Tim Dettmers, Artidoro Pagnoni, Ari Holtzman und Luke Zettlemoyer. „QLoRA: Effiziente Feinabstimmung quantisierter LLMs.“ *Advances 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 und Chelsea Finn. „Direkte Präferenzoptimierung: Ihr Sprachmodell ist insgeheim ein Belohnungsmodell.“ *Advances 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 und Yuan Cao. „ReAct: Synergie zwischen Denken und Handeln in Sprachmodellen.“ *International Conference on Learning Representations (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 und Maosong Sun. „ToolLLM: Erleichtert die Beherrschung großer Sprachmodelle von über 16.000 realen APIs.“ *International Conference on Learning Representations (ICLR)*, 2024. URL: <https://openreview.net/forum?id=dHng2O0Jjr> [8] Bo Liu, Yuqian Jiang, Xiaohan Zhang, Qiang Liu, Shiqi Zhang, Joydeep Biswas und Peter Stone. „LLM+P: Große Sprachmodelle mit optimaler Planungskompetenz stärken.“ arXiv:2304.11477, 2023. URL: <https://arxiv.org/abs/2304.11477>[9] Siyao Zhang, Daocheng Fu, Wenzhe Liang, Zhao Zhang, Bin Yu, Pinlong Cai und Baozhen Yao. „TrafficGPT: Anzeigen, Verarbeiten und Interagieren mit Traffic Foundation-Modellen.“ *Transport Policy*, 150:95-105, 2024. DOI: 10.1016/j.tranpol.2024.03.006. URL: <https://www.sciencedirect.com/science/article/pii/S0967070X24000726> [10] OpenAI. „GPT-5.2-Modell.“ *OpenAI API-Dokumentation*, 2025. URL: <https://platform.openai.com/docs/models/gpt-5.2> [11] Qwen-Team. „Technischer Bericht von Qwen3.“ arXiv:2505.09388, 2025. URL: <https://arxiv.org/abs/2505.09388> [12] DeepSeek-KI. „DeepSeek-R1: Anreize für die Denkfähigkeit in LLMs durch Reinforcement Learning schaffen.“ arXiv:2501.12948, 2025. URL: <https://arxiv.org/abs/2501.12948>[13] Sebastian Wandelt, Changhong Zheng, Shuang Wang, Yucheng Liu und Xiaoqian Sun. „Große Sprachmodelle für intelligenten Transport: Ein Überblick über den Stand der Technik und Herausforderungen.“ *Applied Sciences*, 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 und Nasir Saeed. „Integration von LLMs mit ITS: Aktuelle Fortschritte, Potenziale, Herausforderungen und zukünftige Richtungen.“ *IEEE Transactions on Intelligent Transportation Systems*, 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 und Chao Huang. „UrbanGPT: Räumlich-zeitliche große Sprachmodelle.“ arXiv:2403.00813, 2024. URL: <https://arxiv.org/abs/2403.00813>[16] Yuan Yuan, Jingtao Ding, Jie Feng, Depeng Jin und Yong Li. „UniST: Ein Prompt-gestütztes Universalmodell für urbane räumlich-zeitliche Vorhersagen.“ *Proceedings of the ACM SIGKDD Conference on Knowledge Discovery and Data Mining (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 und Thomas Scialom. „Toolformer: Sprachmodelle können sich selbst den Umgang mit Werkzeugen beibringen.“ *Advances in Neural Information Processing Systems 36 (NeurIPS)*, 2023. URL: <https://proceedings.neurips.cc/paper_files/paper/2023/hash/d842425e4bf79ba039352da0f658a906-Abstract-Conference.html> [18] OpenAI. „Model Context Protocol (MCP) – OpenAI Agents SDK.“ URL: <https://openai.github.io/openai-agents-js/guides/mcp/>[19] OpenAI. „Tools – OpenAI Agents SDK.“ URL: <https://openai.github.io/openai-agents-js/guides/tools/> [20] Karthik Valmeekam, Matthew Marquez, Alberto Olmo, Sarath Sreedharan und Subbarao Kambhampati. „PlanBench: Ein erweiterbarer Benchmark zur Bewertung großer Sprachmodelle zur Planung und Begründung von Veränderungen.“ *Advances 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 und Peter Stone. „Lang2LTL: Übersetzen natürlicher Sprachbefehle in zeitliche Spezifikationen mit großen Sprachmodellen.“ *Conference on Robot Learning (CoRL)*, PMLR 229, 2023. URL: <https://proceedings.mlr.press/v229/liu23d.html>[22] Behrad Rabiei, Mahesh Kumar A. R., Zhirui Dai, Surya L. S. R. Pilla, Qiyue Dong und Nikolay Atanasov. „LTLCodeGen: Codegenerierung syntaktisch korrekter zeitlicher Logik für die Roboteraufgabenplanung.“ arXiv:2503.07902, 2025. URL: <https://arxiv.org/abs/2503.07902> [23] Jun Wang, David Smith Sundarsingh, Jyotirmoy V. Deshmukh und Yiannis Kantaros. „ConformalNL2LTL: Übersetzen von Anweisungen in natürlicher Sprache in temporale Logikformeln mit konformen Korrektheitsgarantien.“ arXiv:2504.21022, 2025. URL: <https://arxiv.org/abs/2504.21022> [24] Alexandre Duret-Lutz, Alexandre Lewkowicz, Amaury Fauchille, Thibault Michaud, Etienne Renault und Laurent Xu. „Spot 2.0: Ein Framework für die Manipulation von LTL und ω-Automaten.“ *International Symposium on Automated Technology for Verification and Analysis (ATVA)*, 2016. URL: <https://spot.lre.epita.fr/>[25] Bardh Hoxha, Houssam Abbas und Georgios Fainekos. „RTAMT: Online-Robustheitsmonitore von STL.“ arXiv:2005.11827, 2020. URL: <https://arxiv.org/abs/2005.11827> [26] Federal Aviation Administration. „Unmanned Aircraft System Traffic Management (UTM).“ URL: <https://www.faa.gov/uas/advanced_operations/traffic_management> [27] Federal Aviation Administration. „Karten der UAS-Einrichtung.“ URL: <https://www.faa.gov/uas/commercial_operators/uas_facility_maps> [28] OpenStreetMap/Overpass-API. „OpenStreetMap und die Overpass-API.“ URL: <https://dev.overpass-api.de/overpass-doc/en/preface/preface.html> [29] New York City Taxi and Limousine Commission. „TLC-Reiseaufzeichnungsdaten.“ URL: <https://www.nyc.gov/site/tlc/about/tlc-trip-record-data.page> [30] Eclipse SUMO. „SUMO-Dokumentation.“ URL: <https://sumo.dlr.de/docs/index.html>[31] Shital Shah, Debadeepta Dey, Chris Lovett und Ashish Kapoor. „AirSim: Hochpräzise visuelle und physikalische Simulation für autonome Fahrzeuge.“ *Field and Service Robotics*, 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 und Davide Scaramuzza. „Flightmare: Ein flexibler Quadrocopter-Simulator.“ *Conference on Robot Learning (CoRL)*, PMLR 155, 2021. URL: <https://proceedings.mlr.press/v155/song21a.html> [33] vLLM-Team. „OpenAI-kompatibler Server.“ *vLLM-Dokumentation*. URL: <https://docs.vllm.ai/serving/openai_kompatible_server.html>[34] Xiao Liu, Hao Yu, Hanchen Zhang, Yifan Xu, „AgentBench: Bewertung von LLMs als Agenten.“ *International Conference on Learning Representations (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 und Joseph E. Gonzalez. „Berkeley Function-Calling Leaderboard.“ Projektseite des 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 und Karthik Narasimhan. „$\tau$-bench: Ein Benchmark für die Tool-Agent-Benutzer-Interaktion in realen Domänen.“ 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 und Ruoming Pang. „ToolSandbox: Ein zustandsbehafteter, konversationsorientierter, interaktiver Bewertungsbenchmark für LLM-Tool-Nutzungsfähigkeiten.“ arXiv:2408.04682, überarbeitet 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 und Jeffrey Homola. „TCL4 UTM (UAS Traffic Management) Nevada 2019 Flugtests, Bericht des Airspace Operations Laboratory (AOL).“ Technisches Memorandum der NASA NASA/TM-2020-220516, 2020. URL: <https://ntrs.nasa.gov/citations/20205003361> [39] EUROCONTROL. „CORUS-XUAM: Betriebskonzept für europäische UTM-Systeme – Erweiterung für urbane Luftmobilität.“ Projektseite, 2023. URL: <https://www.eurocontrol.int/project/corus-xuam>[40] Marc Brittain, Luis E. Alvarez, Kara Breeden und Ian Jessen. „AAM-Gym: Testumgebung für künstliche Intelligenz für fortschrittliche Flugmobilität.“ *IEEE/AIAA Digital Avionics Systems Conference (DASC)*, 2022; arXiv:2206.04513. URL: <https://arxiv.org/abs/2206.04513> [41] Overture Maps Foundation. „Overture Maps-Dokumentation: Orte, Gebäude und Transportdaten.“ URL: <https://docs.overturemaps.org/> [42] Open-Meteo. „Wetterprognose-API und historische Prognose-API-Dokumentation.“ URL: <https://open-meteo.com/en/docs> [43] Federal Aviation Administration. „UAS Data Delivery System Datenwörterbuch.“ PDF, 2022. URL: <https://www.faa.gov/sites/faa.gov/files/2022-08/UAS_Data_Delivery_System_Data_Dictionary.pdf> [44] Flugwetterzentrum. „Daten-API.“ National Oceanic and Atmospheric Administration, Dokumentationsseite. 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 und Constantine Samaras. „Positions- und Energieverbrauchsdatensatz während des Fluges eines DJI Matrice 100-Quadrocopters für die Zustellung kleiner Pakete.“ *Scientific Data*, 8:155, 2021. DOI: 10.1038/s41597-021-00930-x. URL: <https://www.nature.com/articles/s41597-021-00930-x> [46] Federal Aviation Administration. „Paketzustellung per Drohne (Teil 135).“ URL: <https://www.faa.gov/uas/advanced_operations/package_delivery_drone> [47] U.S. Government Accountability Office. „Drohnen: Es sind Maßnahmen erforderlich, um die Fernidentifizierung im nationalen Luftraum besser zu unterstützen.“ GAO-24-106158, 2024. URL: <https://www.gao.gov/products/gao-24-106158> --- ## Anhang: Dieser Ausführungsplan ### A. Tun Sie es sofort1. Erstellen Sie das Schema „LowAltitudeIR v0.1“. 2. Implementieren Sie 6 deterministische Tools: Stadt, Luftraum, Scheduler, Planer, Prüfer und Simulator. 3. Generieren Sie 200 Dev-Mini-Beispiele. 4. Führen Sie vier Baselines aus: direktes LLM, nur JSON, ReAct und CloudBrain-Agent ohne Reparatur. ### B. Bestehenskriterien für die erste Versuchsrunde Wenn auf dev-mini folgende Bedingungen erfüllt sind, wird der komplette Benchmark eingetragen: – Die Tool-Aufrufgenauigkeit von CloudBrain-Agent Full übertrifft die ReAct-Basislinie; - Die Rate von Sicherheitsverstößen ist niedriger als bei direktem LLM. - Die Reparaturschleife kann zumindest einige Prüffehler beheben. – Die durchschnittliche Laufzeit jeder Aufgabe überschreitet nicht einen akzeptablen Schwellenwert, z. B. weniger als 30 Sekunden für ein lokales 14B-Modell. ### C. Verbindung zum nächsten Artikel Die von G1 generierten Werkzeugspuren, Reparaturspuren, Fehlerfälle und menschlichen Überprüfungsdaten werden direkt zu den SFT/DPO-Daten von G2 LowAltitudeGPT. Mit anderen Worten, G1 ist nicht nur ein Papier, sondern auch eine Datenfabrik für vertikale Modelltrainingsdaten.