WARG-Plattform: Technische Architektur KI-gestütztes Kriegsspiel

Die Lücke zwischen den Kriegsspielwerkzeugen, die die meisten Verteidigungsorganisationen derzeit betreiben, und den analytischen Anforderungen, denen sie gegenüberstehen, wird größer. Übungen, die für die Validierung gut verstandener Doktrin gegen einen bekannten Gegner ausreichend waren, sind für die Konzeptentwicklung in einem sich schnell wandelnden operativen Umfeld unzureichend. Was benötigt wird, ist eine Plattformarchitektur, die adaptives gegnerisches Verhalten modellieren, große Kräfteauseinandersetzungen in hoher Geschwindigkeit auflösen, statistisch aussagekräftige Ergebnisdaten über viele Durchläufe hinweg generieren und strukturierte Analysen rechtzeitig an Kommandeure und Planer zurückgeben kann, um ihr Denken vor dem nächsten Planungszyklus zu verändern. Dieser Artikel untersucht, woraus diese Architektur bestehen muss — und behandelt die Kernsubsysteme, die eine moderne KI-Kriegsspielplattform definieren: die OpFor-Verhaltensmodellierungsmaschine, die Szenario- und Kräfte-gegen-Kräfte-Simulationsschleife, die Geländedatenpipeline, die Nachgefechtsbriefing-Analysemaschine und die Integrationsschnittstellen, die sie mit bestehenden Führungs- und Kontrolltrainingsumgebungen verbinden.

Die WARG-Plattform ist die Implementierung dieser Architektur durch Corvus Intelligence, entwickelt für Planungsübungen auf Brigade- und höherer Ebene. Die hier beschriebenen technischen Entscheidungen spiegeln wider, was diese Systemkategorie tun muss, um operativ nützlich zu sein — keine Marketingaussagen, sondern Ingenieuranforderungen, die sich aus den tatsächlichen Anforderungen von Verteidigungstraining- und Analyseprogrammen ableiten. Für einen breiteren Kontext, wie KI-gestütztes Kriegsspiel mit manuell moderierten Formaten verglichen wird, siehe den Begleitartikel über KI-Kriegsspiel versus manuelles Kriegsspiel.

OpFor-KI-Verhaltensmodellierung

Die Qualität einer KI-Kriegsspielplattform wird weitgehend durch die Qualität ihres Gegnermodells bestimmt. Ein OpFor, der sich vorhersehbar verhält, sich nicht an Spielermanöver anpassen kann oder Ziele auf taktisch inkohärente Weise verfolgt, trainiert Kommandeure gegen eine Strohpuppe — und erfahrene Kommandeure werden dies innerhalb der ersten dreißig Minuten der Übung erkennen und sich mental vom Trainingsszenario abkoppeln. Den OpFor richtig zu gestalten ist kein kosmetisches Merkmal; es ist das zentrale analytische Produkt der Plattform.

Hierarchische Entscheidungsarchitektur

Ein gut konzipiertes OpFor-Verhaltensmodell arbeitet mit einer hierarchischen Entscheidungsarchitektur, die die tatsächliche Führungsstruktur widerspiegelt. Auf operativer Ebene empfängt ein PlanningModule die zugewiesenen Ziele des OpFor und den aktuellen Simulationszustand und generiert eine Reihe von Handlungsoptionen. Jede Handlungsoption wird durch ein Ergebnismodell bewertet — eine erlernte Funktion, die das aktuelle Kräfteverhältnis, die Geländeaufstellung und den Logistikzustand auf eine erwartete Ergebnisverteilung für diese Handlungsoption abbildet. Die am höchsten bewertete realisierbare Handlungsoption wird zum aktuellen operativen Plan des OpFor, der dann als Satz von Zielzuweisungen an untergeordnete taktische Agenten ausgedrückt wird.

Auf taktischer Ebene pflegt jeder Einheitenagent ein lokales Lagebild, das aus dem Sensormodell der Simulation abgeleitet wird — er sieht, was seine Sensoren angesichts des Geländes und des elektronischen Kriegszustands sehen können, nicht den vollständigen Simulationszustand. Der Einheitenagent trifft Bewegungs-, Gefechts- und Positionierungsentscheidungen mithilfe einer Kombination aus seinem zugewiesenen Ziel, seinem lokalen Bild und einer trainierten Verhaltenspolicy. Die Policy wurde gegen ein Korpus historischer und doktrinärer Daten trainiert, was bedeutet, dass sie taktisch erkennbares Verhalten erzeugt: Flankenangriffe, wenn verfügbar, Abstandsgefecht, wenn im Vorteil, Unterdrückung vor Bewegung in bebautem Gelände. Das Ergebnis ist ein Gegner, der auf erkennbare Weise kämpft und dabei auf Spieleraktionen reagiert, die die lokale Lage verändern.

Verhaltensgenauigkeit und Doktrincodierung

Die Codierung spezifischer gegnerischer Doktrin in das OpFor-Modell erfordert mehr als die Auswahl einer generischen „Angreifer"-Verhaltensvoreinstellung. Verschiedene gegnerische Kräftestrukturen und Doktrinen erzeugen charakteristische taktische Signaturen — charakteristische Annäherungsgeometrien, Feuerunterstützungseinsatzmuster, Ausnutzungstempo und Logistikdisziplin. Diese Signaturen werden durch eine Kombination aus Parameterkonfiguration (Engagementreichweiten-Präferenzen, Rückzugsschwellen, Reserveeinsatz-Auslöser) und Trainingsdaten, die doktrinspezifische Beispiele enthalten, codiert. Das Ergebnis ist ein OpFor, der nicht nur kompetent kämpft, sondern auf eine Weise kämpft, die für das Trainingspublikum als spezifischer Gegnertyp erkennbar ist.

Szenario-Engine-Architektur

Die Szenario-Engine ist das Substrat, auf dem alle anderen Plattformkomponenten operieren. Sie pflegt den autoritativen Simulationszustand — Einheitenpositionen, Stärkepegel, Logistikbestände, elektronischer Kriegszustand, Wetter — und verwaltet die Simulationsuhr, die Ereigniswarteschlange und die Adjudikationspipeline.

Simulationsschleife und Adjudikationspipeline

Eine Kräfte-gegen-Kräfte-Simulationsschleife auf Brigadeebene verarbeitet eine große Anzahl gleichzeitiger Interaktionen pro Simulationstakt. Die Adjudikationspipeline muss auflösen: Sensorerfassungsereignisse (welche Einheiten können welche anderen Einheiten angesichts von Gelände, Wetter und elektronischem Kriegszustand beobachten), Gefechtsereignisse (welche Einheiten sind in Reichweite und haben Sichtlinie, welche erwarteten Wirkungen gibt es angesichts Waffentyp, Zieltyp und Schutzgrad), Bewegungsereignisse (welche Einheiten bewegen sich auf welchen Routen mit welchen Geschwindigkeiten angesichts von Gelände und Logistikzustand) und Logistikereignisse (welche Einheiten verbrauchen welche Ressourcen und welche Nachschubkonvois bewegen sich auf welchen Routen). Jede dieser Ereigniskategorien hat ihr eigenes Auflösungsmodell. Die Pipeline verarbeitet Ereignisse in einer definierten Prioritätsreihenfolge — Erkennung vor Gefecht, Gefecht vor Bewegung — um Kausalitätsfehler im Simulationszustand zu vermeiden.

Die Simulationsuhrenarchitektur ist für den Trainingsrealismus wichtig. Eine rein rundenbasierte Uhr erzwingt eine künstliche Synchronisierung von Ereignissen, die in der Realität asynchron auftreten. Eine zeitkontinuierliche Simulation mit variablen Takten — die Uhr auf das nächste geplante Ereignis vorziehend — ist realistischer, erfordert aber eine sorgfältige Verwaltung der Ereignisreihenfolge, um Race Conditions zu verhindern. Die Wahl der Uhrenarchitektur beeinflusst sowohl die rechnerische Handhabbarkeit der Simulation bei großen Kräftegrößen als auch den Realismus der Trainingserfahrung auf Einheitenebene.

Skalierbarkeit von der Zug- bis zur operativen Ebene

Die Skalierung einer Kriegsspielplattform von der Zugebene auf die operative Ebene ist eine Architekturherausforderung, die nicht durch einfaches Ausführen der gleichen Modelle in einem gröberen Maßstab gelöst werden kann. Auf Zugebene ist individuelle Fahrzeuggenauigkeit angemessen und rechnerisch handhabbar: Jede Plattform hat ihr eigenes Sensormodell, Waffensystem und ihren eigenen Bewegungszustand. Auf Brigade- und höherer Ebene führt die Verfolgung einzelner Plattformen zu einem Simulationszustand, der zu groß ist, um ihn ohne spezialisierte Hardware in Echtzeit zu aktualisieren. Die Lösung ist eine konfigurierbare Auflösungshierarchie: Nutzer wählen die Gliederungsebene der Übung, und die Plattform aggregiert Einheitenzustände entsprechend und verwendet aggregierte Kampfmodelle, die kalibriert sind, um Ergebnisse zu liefern, die mit den Einzelplattformmodellen bei feinerer Auflösung konsistent sind. Die gleichen Szenariodatenstrukturen und OpFor-Verhaltensmodellparameter sollten über alle Auflösungsebenen hinweg funktionieren — eine Plattform, die für jede Gliederungsebene separate Szenariodatensätze erfordert, verursacht für Übungsdesignteams einen nicht tragbaren Datenverwaltungsaufwand.

Karten- und Geländedatenpipeline

Das Geländesubsystem ist die Grundlage, von der alle Bewegungs-, Erkennungs- und Gefechtsberechnungen abhängen. Auf Brigadeebene ist der minimalste nützliche Input ein digitales Geländemodell im Maßstab 1:50.000 oder feiner. Aus diesem Input leitet die Geländepipeline die Produkte ab, die die Adjudikationsmaschine verbraucht: Hang- und Befahrbarkeitmasken nach Fahrzeugklasse (Ketten, Räder, abgesessen), Vegetationsdichteebenen, die Beobachtungsreichweite und Feuer beeinflussen, Stadtgebietsbezeichnungen, die Nahkampfmechaniken beeinflussen, und ein Straßen- und Brückennetzgraph, der vom Logistikroutingmodul verwendet wird.

Datenaufnahme und -normalisierung

Eine praktische Geländepipeline muss Daten aus mehreren Quellen aufnehmen und auf eine gemeinsame interne Darstellung normalisieren können. Geoinformationsdaten für operative Gebiete liegen in mehreren Formaten und Projektionen vor — GeoTIFF für Raster-Höhendaten, Shapefile oder GeoJSON für Vektormerkmate, DTED für verteidigungsstandard-Höhenprodukte. Das Aufnahmemodul der Pipeline normalisiert all diese auf das interne Kachelformat der Plattform, das für die räumlichen Abfragemuster optimiert ist, die die Adjudikationsmaschine erzeugt: Reichweite-und-Peilung-Abfragen für Sichtlinienberechnungen, Bereichsabfragen für Einheitendichteberechnungen und Pfadabfragen für Bewegungsrouting. Die Normalisierung umfasst die Koordinatenprojektion auf ein konsistentes System und Auflösungs-Resampling, wenn die Quelldaten eine andere Auflösung haben als das Kachelformat der Plattform.

Reales versus synthetisches Gelände

KI-Kriegsspielplattformen können entweder auf realen Geoinformationsdaten oder auf verfahrenstechnisch generiertem synthetischem Gelände betrieben werden. Reales Gelände bietet den höchsten Trainingsnutzen für Übungen, die an ein bestimmtes operatives Einsatzgebiet gebunden sind, und ermöglicht einen direkten Vergleich der Kriegsspielergebnisse mit realen Planungsprodukten. Synthetisches Gelände ist für Konzepttests und für Übungen geeignet, bei denen die spezifische Geografie weniger wichtig ist als die operative Problemstruktur. Die Plattformarchitektur muss beides unterstützen, wobei die Geländepipeline entweder reale Daten-Importe oder synthetische Geländegenerierungsparameter als Input für die gleiche nachgelagerte Adjudikationsmaschine akzeptieren kann.

AAR-Analysemaschine

Das Nachgefechtsbriefing ist der Ort, wo der Trainingsnutzen des Kriegsspiels realisiert wird. Eine Plattform, die ein reichhaltiges Simulationsereignisprotokoll generiert, aber keine strukturierten analytischen Werkzeuge zur Verarbeitung dieses Protokolls bereitstellt, zwingt Moderatoren dazu, Stunden damit zu verbringen, Chronologien aus Rohdaten zu rekonstruieren — Zeit, die für Diskussionen mit dem Trainingspublikum genutzt werden sollte. Die AAREngine ist das Subsystem, das das rohe Ereignisprotokoll in strukturierte Analyseprodukte umwandelt.

Entscheidungspunkt-Erkennung und -Kommentierung

Das wertvollste AAR-Ausgabeprodukt ist eine Zeitachse der Entscheidungspunkte — Momente, in denen die Wahl eines Kommandeurs die nachfolgende Entwicklung des Gefechts maßgeblich verändert hat. Die Erkennung dieser Entscheidungspunkte erfordert, dass die AAR-Engine mehr als Ereignisse chronologisch wiedergibt. Sie muss Divergenzpunkte identifizieren: Momente, in denen die Bandbreite möglicher zukünftiger Ergebnisse groß war und eine Entscheidung sie einengte. Dies wird berechnet, indem die tatsächliche Simulationstrajektorie mit einer Reihe kontrafaktischer Trajektorien verglichen wird, die durch Wiederholung des Szenarios ab diesem Punkt mit unterschiedlichen Entscheidungsinputs generiert wurden. Entscheidungspunkte, bei denen die kontrafaktischen Trajektorien wesentlich von der tatsächlichen Trajektorie abweichen, sind die Momente, die im Debriefing die meiste Aufmerksamkeit des Moderators verdienen.

Die Kommentierung dieser Entscheidungspunkte — die Generierung natürlichsprachiger Beschreibungen dessen, was entschieden wurde, welche Alternativen bestanden und was die Ergebnismodelle für jede Alternative vorhersagten — ist eine Funktion, bei der die Fähigkeiten von Sprachmodellen echten analytischen Mehrwert bieten. Die Kommentierung ersetzt nicht das Urteil des Moderators; sie reduziert den Vorbereitungsaufwand und gibt dem Moderator einen strukturierten Ausgangspunkt für die Debriefingdiskussion, anstatt eines leeren Ereignisprotokolls.

Statistische Analyse über mehrere Durchläufe

Die volle analytische Kraft einer KI-Kriegsspielplattform ist nur verfügbar, wenn das Szenario mehrfach unter variierenden Bedingungen durchgespielt wird. Das statistische Modul der AAR-Engine verarbeitet den Ergebnissatz aus mehreren Durchläufen und generiert: Ergebniswahrscheinlichkeitsverteilungen (welcher Anteil der Durchläufe in jedem definierten Ergebniszustand endete), Sensitivitätsanalysen (welche Ausgangsbedingungen oder Entscheidungsvariablen Ergebnisse am stärksten vorhergesagt haben), Kräfte-Austausch-Verhältnisse in Abhängigkeit von Entscheidungsinputs und Logistikverbrauchskurven, die die Bedingungen identifizieren, unter denen die Versorgung zum entscheidenden Engpass wurde. Diese Analyse ist nur auf diesem statistischen Konfidezniveau verfügbar, wenn die Plattform ohne menschliche Beteiligung Hunderte von Szenarioiterationen durchführen kann — die rechnerische Investition in die KI-OpFor-Modellierung zahlt sich hier aus, da sie diese Analysefähigkeit ermöglicht, die ein manuelles Kriegsspielformat strukturell nicht bieten kann. Siehe auch den Artikel über Kriegsspiel in der militärischen Doktrinentwicklung für die analytischen Anforderungen, die diese Fähigkeit antreiben.

Integration mit C2-Trainingsumgebungen

Eine Kriegsspielplattform, die isoliert von den C2-Werkzeugen betrieben wird, die Kommandeure und Stäbe tatsächlich in Operationen einsetzen, erzeugt Training, das nicht auf die Praxis übertragbar ist. Die Simulation erzeugt Ergebnisse, aber das Trainingspublikum interagiert mit ihr über eine Schnittstelle, die keinerlei Ähnlichkeit damit hat, wie sie in einer realen Operation befehligen würden. Die Integration mit C2-Trainingsumgebungen ändert dies: Kommandeure erteilen Befehle über vertraute Schnittstellen, empfangen Meldungen in vertrauten Formaten und erleben das Tempo und die kognitive Belastung realer Führungsabläufe — während die Kriegsspielplattform die zugrundeliegende Simulation verwaltet.

Datenaustausch und API-Architektur

Die C2-Integration wird durch die Simulationsadapterschicht der Plattform erreicht — eine Reihe von Schnittstellen, die zwischen dem internen Simulationszustand der Plattform und den Nachrichtenformaten übersetzen, die C2-Trainingssysteme verbrauchen und senden. Standardmäßige Datenaustauschformate in Verteidigungstrainingsumgebungen umfassen Lagemeldungsformate für Positions- und Statusaktualisierungen sowie strukturierte Befehlsaustauschprotokolle für Führungsanweisungen. Der Simulationsadapter veröffentlicht Lageaktualisierungen auf einem Nachrichtenbus, wenn sich der Simulationszustand ändert, und ermöglicht es verbundenen C2-Systemen, simulierte Einheitenpositionen genau so anzuzeigen, wie sie reale Lagedaten anzeigen würden. Der Adapter abonniert auch Befehlsnachrichten von C2-Systemen, übersetzt sie in Simulationsbefehle und leitet sie an die entsprechenden Einheitenagenten in den OpFor- oder Freundliche-Kräfte-Modellen weiter.

Übungssteuerung und Föderation

Bei größeren Übungsmaßstäben muss eine einzelne Kriegsspielplattforminstanz möglicherweise mit anderen Simulationssystemen föderieren — separate Plattformen, die verschiedene Domänen (Luft, See, Cyber) oder verschiedene geografische Sektoren des gleichen operativen Gebiets bearbeiten. Die Föderation erfordert eine Vereinbarung über eine gemeinsame synthetische Umgebungsdefinition: Koordinatensystem, Zeitreferenz und Entitätsidentifikationsschema. Das Übungssteuerungssubsystem verwaltet diese Föderation, handhabt die Zeitsynchronisierung zwischen föderalen Systemen und löst Konflikte auf, bei denen mehrere Systeme Zuständigkeit über dieselbe Entität oder dasselbe geografische Gebiet haben.

Plattformauswahlkriterien für die Beschaffung

Für Beschaffungsbeauftragte und Trainingsleiter, die KI-Kriegsspielplattformen bewerten, lassen sich die obigen technischen Architekturfragens direkt in Beschaffungskriterien übersetzen. Erstens: Erzeugt das OpFor-Modell der Plattform taktisch kohärentes gegnerisches Verhalten, oder erzeugt es offensichtliche Muster, die erfahrene Kommandeure ablehnen werden? Dies kann beurteilt werden, indem die Plattform einige Stunden lang mit erfahrenen Operatoren gefahren wird und beobachtet wird, ob der OpFor Überraschungen erzeugt. Zweitens: Erzeugt die AAR-Engine analytische Produkte in einer Form, die die Vorbereitungszeit des Moderators reduziert, oder erfordert sie eine umfangreiche manuelle Analyse von Rohdaten? Drittens: Akzeptiert die Geländepipeline reale Geoinformationsdaten für die spezifischen operativen Gebiete, die das Programm üben muss? Viertens: Skaliert die Plattform auf die Gliederungsebene, die das Programm erfordert, unter Verwendung der gleichen Datenstrukturen und Szenarioverwaltungswerkzeuge über alle Maßstabsebenen? Fünftens: Verwendet die C2-Integrationsarchitektur standardisierte Datenformate, oder erfordert sie individuelle Integrationsarbeit, die das Programm an einen einzigen Plattformanbieter bindet?

Eine Plattform, die alle fünf Kriterien erfüllt — adaptiver OpFor, strukturiertes AAR, reale Geländeaufnahme, gliederungsübergreifende Skalierbarkeit und standardsbasierte C2-Integration — ist eine Plattform, die ein ernsthaftes Verteidigungstraining- und Analyseprogramm unterstützen kann, anstatt diese Fähigkeiten in einer vom Anbieter kontrollierten Umgebung zu demonstrieren. Der Unterschied ist in den Übungsergebnissen beobachtbar: Der erste Typ erzeugt Erkenntnisse, die Planung und Doktrin verändern; der zweite erzeugt beeindruckende Demonstrationen, die dies nicht tun.