137.000 Menschen, keine menschlichen Entscheidungen: agentische Katastrophenreaktion mit Elasticsearch

Agent Builder ist jetzt allgemein verfügbar (GA). Starten Sie mit einer Elastic Cloud-Testversion und sehen Sie sich hier die Dokumentation für Agent Builder an.

Elastic hat soeben die automatisierte Evakuierung von 137.000 Militäreinsatzkräften an sieben Standorten koordiniert – ganz ohne menschliches Eingreifen. Ein Hurrikan der Kategorie 4 trifft auf die Küste von Hampton Roads. Die Geodatenanreicherung von Elasticsearch identifiziert jede Einrichtung im betroffenen Gebiet bereits zur Indexzeit. Eine Kibana Erkennungsregel wird ausgelöst. Ein Workflow startet eine Konversation mit einem KI-Agenten. Der Agent analysiert Kapazität, Distanz und Zweigstellenkompatibilität durch logisches Denken und versendet dann 16 Evakuierungs- und Aufnahmebenachrichtigungen in einem einzigen Durchgang. Vom unverarbeiteten GDACS-Ereignis zur koordinierten Aktion, ganz automatisch.

Jedes Jahr zwingen Naturkatastrophen Notfallmanager, militärische Befehlshaber und Verantwortliche für die öffentliche Sicherheit dazu, unter hohem Zeitdruck weitreichende Entscheidungen zu treffen. Diese Entscheidungen basieren traditionell auf Telefonketten, Tabellen und institutionellem Wissen, das über Dutzende von Personen verteilt ist. Allein der Koordinationsaufwand kostet entscheidende Zeit.

Dieser Beitrag zeigt, wie Elastic ein reaktionsschnelles, agentisches Koordinationssystem für die Katastrophenreaktion antreiben kann, das eine Bedrohung erkennt, die Logistik durchdenkt und automatisch handelt. Um dies zu veranschaulichen, haben wir eine Simulation erstellt: Ein fiktiver Hurrikan der Kategorie 4, der die Küste von Hampton Roads bedroht, löst die automatische Verlegung von über 137.000 Einsatzkräften über sieben Militäreinrichtungen hinweg aus.

Hinweis: Dies ist ein rein fiktives Szenario, das zu Demonstrationszwecken erstellt wurde. Den Hurrikan ELARA-26 gibt es nicht. Die Standorte der Einrichtungen basieren auf echten, öffentlich zugänglichen geografischen Daten (dem Datensatz „Military Installations, Ranges, and Training Areas [MIRTA]“ des US-Verteidigungsministeriums [DoD]), aber alle operativen Daten wie Personalzahlen, Unterbringungskapazitäten, Ressourcen, Kontakt-E-Mails und Missionsprofile sind frei erfunden. Nichts in dieser Demo spiegelt die tatsächliche militärische Einsatzbereitschaft, Fähigkeiten oder operative Abläufe wider.

Warum eine automatisierte Katastrophenreaktion georäumliche und agentische Koordination erfordert

Wenn eine Naturkatastrophe kritische Infrastrukturen bedroht, ist die Koordinationsherausforderung unmittelbar:

• Welche Einrichtungen befinden sich in der Gefahrenzone?

• Wie viele Einsatzkräfte müssen versetzt werden?

• Wohin können sie gehen und verfügen diese Einrichtungen über Kapazitäten?

• Wer muss jetzt benachrichtigt werden?

Diese Fragen können nicht warten. Und das sollten die Antworten auch nicht.

Pipeline bereitstellen: Voraussetzungen und Einrichtung

Befolgen Sie die Anweisungen hier im Beispiel-Repo, um über Cloud Connect einen lokalen Elastic-Cluster mit Elastic Inference Service (EIS) bereitzustellen.

Wie die agentische Katastrophenreaktions-Pipeline von Elasticsearch funktioniert

Die Pipeline hat sieben Schichten, die durchgängig zusammenarbeiten:

1. Dateningestion: Katastrophenereignisse des Global Disaster Alert and Coordination System (GDACS) werden an Elasticsearch gesendet

2. Ingest-Pipeline: GeoJSON wird eingelesen und an das Elastic Common Schema (ECS) angepasst.

3. Geodaten-Anreicherung: Das Polygon des betroffenen Bereichs des Ereignisses wird mit indexierten Grenzen von Militäreinrichtungen abgeglichen.

4. Alerting: Eine Kibana-Erkennungsregel wird ausgelöst, wenn sich eine Katastrophe mit einer Installation überschneidet.

5. Workflow-Automatisierung: Die Warnung löst einen Kibana-Workflow aus, der eine Unterhaltung mit einem KI-Agenten startet.

6. KI-Argumentation: Der Agent analysiert die betroffenen Einrichtungen, deren Assets und die nächstgelegenen unterstützenden Einrichtungen, um die Verlagerung aller Ressourcen und des Personals zu bestimmen.

7. E-Mail-Benachrichtigungen: Der Agent versendet E-Mails an alle Empfänger für ein- und ausgehendes Personal und/oder Assets.

Sehen wir uns die einzelnen Schichten einmal an.

Schritt 1: Indexieren von militärischen Einrichtungen mit Geo-Grenzen

Die Grundlage bildet der DoD-MIRTA-Datensatz von source.coop/seerai/hifld. Dieser Datensatz stellt für jede Installation eine geo_shape vom Typ Point bereit; es werden Zentroid-Koordinaten statt vollständiger Grenzpolygone verwendet.

Jedes Installationsdokument im Index „mitra-facilities“ wird mit operativen Profildaten (alle fiktiv) angereichert – über das hinaus, was MIRTA bereitstellt:

{
  "entity_name": "Naval Station Norfolk",
  "branch_of_service": "Navy",
  "mission_function_type": "fleet_support",
  "personnel_count": 50000,
  "housing_capacity": 55000,
  "temporary_housing_capacity": 10000,
  "logistics_capabilities": ["fuel", "airlift", "sealift", "medical"],
  "available_assets": [
    { "type": "helicopters", "count": 24 },
    { "type": "transport_vehicles", "count": 150 }
  ],
  "contact_email": "norfolk.ops@navy.mil.gov.fake",
  "operational_status": "act",
  "is_joint_base": false,
  "entity_geo_location": { "type": "polygon", "coordinates": [...] }
}

Dieser umfangreiche Index ermöglicht es dem KI-Agenten, intelligente Zuweisungsentscheidungen zu treffen; nicht nur „hier sind nahegelegene Stützpunkte“, sondern „hier sind Stützpunkte mit verfügbarer Unterbringungskapazität, kompatiblen Missionstypen und der Logistik, um eingehende Ressourcen aufzunehmen.“

Schritt 2: Ingestieren und Normalisieren von GDACS-Ereignissen

GDACS veröffentlicht Echtzeit-GeoJSON für Erdbeben, tropische Wirbelstürme, Überschwemmungen, Waldbrände, Vulkane und Dürren. Wir importieren diesen Feed in einen Datenstream (logs-gdacs.events-*) mithilfe einer benutzerdefinierten Ingest-Pipeline, die das rohe GeoJSON auf ECS-Felder normalisiert.

Die GDACS Ingest-Pipeline erledigt mehrere Dinge, die es zu beachten gilt:

Geometrieextraktion: Der Zentroid wird für die Kartenanzeige als geo_point gespeichert und das Auswirkungspolygon wird als geo_shape in gdacs.affected_area gespeichert, bei dem es sich um das Feld handelt, das später für Schnittmengenabfragen verwendet wird.

Normalisierung der Schweregrade: Jede Art von Katastrophe hat eine andere Schweregradskala. Ein tropischer Wirbelsturm wird anhand der Windgeschwindigkeit in km/h gemessen; ein Erdbeben anhand der Richter-Magnitude. Die Pipeline ordnet sie alle einem normalisierten Score von 0–100 zu:

// einfacher Code-Snippet aus der Ingest-Pipeline
if (type == 'TC') {
  norm = Math.min(100.0, Math.max(0.0, (val - 40.0) / 2.6));
} else if (type == 'EQ') {
  norm = Math.min(100.0, Math.max(0.0, (val - 4.0) * 20.0));
}

Der normalisierte Schweregradwert wird dann einem severity_level-Label (low, medium, high, critical) zugeordnet, das für das Alert-Schweregrad-Mapping in der Erkennungsregel verwendet wird.

ECS-Ausrichtung: event.kind: alert, event.category: Bedrohung, Zeitstempel auf event.start/event.end abgebildet, und eine stabile, fingerprintbasierte _id zur Deduplizierung.

Schritt 3: Georäumliche Anreicherung: Ermitteln betroffener Einrichtungen zur Indexzeit

Die geo_match-Anreicherungsrichtlinie von Elasticsearch gleicht das Katastrophenpolygon beim Indexieren mit jeder Installationsgrenze ab, ohne dass ein Join zum Abfragezeitpunkt erforderlich ist. Anstatt zum Suchzeitpunkt eine Abfrage durchzuführen, verwenden wir einen Anreicherungsprozessor in der Ingest-Pipeline, um das Auswirkungspolygon der Katastrophe beim Indexieren des Dokuments mit jeder Installationsgrenze abzugleichen.

Die Anreicherungsrichtlinie ist eine geo_match-Richtlinie:

{
  "geo_match": {
    "indices": "mitra-facilities",
    "match_field": "entity_geo_location",
    "enrich_fields": [
      "entity_name",
      "entity_type",
      "entity_station_number",
      "entity_geo_city_name",
      "entity_geo_region_name"
    ]
  }
}

Der Prozessor wird am Ende der Ingest-Pipeline ausgeführt:

{
  "enrich": {
    "policy_name": "facilities-geo",
    "field": "gdacs.affected_area",
    "target_field": "affected_facilities",
    "shape_relation": "INTERSECTS",
    "max_matches": 128
  }
}

INTERSECTS erfasst jede Anlage, deren Begrenzung das Katastrophenpolygon berührt oder überlappt, und sogar partielle Überschneidungen. Das Ergebnis ist, dass jedes GDACS-Ereignisdokument mit einem verschachtelten affected_facilities-Array gespeichert wird, das uns genau verrät, welche Anlagen sich in der betroffenen Zone befinden. Keine Join-Abfrage erforderlich.

Schritt 4: Erkennungsregel: Alerting bei Auswirkungen auf Einrichtungen

Eine Kibana-Erkennungsregel überwacht den logs-gdacs.events-* Datenstrom und wird ausgelöst, wenn ein GDACS-Ereignis mit mindestens einer betroffenen Einrichtung angereichert wurde:

Abfrage: affected_facilities: { entity_name: * }

Die Regel wird stündlich ausgeführt (deckt ein Zeitfenster von jetzt-1h bis jetzt ab) und verwendet dynamisches Schweregrad-Mapping; das gdacs.severity_level- Feld, das von der Ingest-Pipeline berechnet wird, steuert den Alert-Schweregrad automatisch.

Der Alert-Schweregrad bestimmt die Risikobewertung auch über das Feld-Mapping:

"risk_score_mapping": [
  {
    "field": "gdacs.normalized_severity",
    "operator": "equals",
    "value": ""
  }
]

Wenn die Regel ausgelöst wird, übergibt sie den vollständigen Alert-Kontext, einschließlich des angereicherten affected_facilities-Arrays mit Installationsnamen, -typen und -standorten, an einen nachgelagerten Kibana-Workflow.

Schritt 5: Workflow-Automatisierung: Verbindung von Alarm und Agent

Kibana-Workflows übernehmen die Übergabe von der Erkennung zur Reaktion. Der Workflow zur Reaktion auf Naturkatastrophen wird durch den Alarm ausgelöst:

triggers:
  - type: alert
steps:
  - name: start_convo
    type: kibana.request
    with:
      method: "POST"
      path: "/api/agent_builder/converse"
      body:
        agent_id: "mitra.response"
        input: "New Natural Disaster Alert: {{ event.alerts | json }}"

Die gesamte Alert-Payload (Katastrophentyp, Schweregrad, betroffenes Gebiet und die Liste der betroffenen Installationen) wird als anfänglicher Kontext an den KI-Agenten weitergeleitet. Ab hier übernimmt der Agent.

Schritt 6: Der KI-Agent: Von Daten zu koordinierter Aktion

Der mitra.response-Agent übernimmt die vollständige Alert-Payload und bewertet in einer einzigen agentenbasierten Schleife den Umfang, ermittelt Aufnahmeeinrichtungen, weist Personal zu und versendet Evakuierungs- und Aufnahmebenachrichtigungen – alles ohne menschliches Eingreifen.

Dem Agenten stehen zwei Tools zur Verfügung:

• mitra.nearest_facility fragt den Index „mitra-facilities“ mithilfe einer geo_shape-Abfrage ab, sortiert nach der Entfernung von einer angegebenen Koordinate, und gibt bis zu 50 aktive Installationen in der Nähe mit verfügbarer Kapazität zurück.

• mitra.send_email iteriert über ein JSON-Array von Einrichtungsobjekten und versendet formatierte Evakuierungs- oder Aufnahmebenachrichtigungen.

Der Anweisungssatz des Agenten definiert einen klaren Workflow:

1. Bewerten der Situation. Parsen Sie den Alert, identifizieren Sie betroffene Einrichtungen und bestimmen Sie das Ausmaß der Katastrophe.

2. Inventarisieren, was verschoben werden muss. Mitarbeiterzahlen, kritische Assets, Unterbringungsanforderungen pro Einrichtung.

3. Zieleinrichtungen ermitteln. Rufen Sie mitra.nearest_facility für jede betroffene Installation auf, wobei Einrichtungen herausgefiltert werden, die sich noch in der Gefahrenzone befinden.

4. Zuteilungsentscheidungen treffen. Wägen Sie Single- versus Multi-Facility-Lösungen, Zweigstellenkompatibilität, Unterbringungskapazität und Asset-Support ab.

5. Koordinierungs-E-Mails senden. Evakuierungsanordnungen an Ausgangseinrichtungen und Aufnahmebenachrichtigungen an Aufnahmeeinrichtungen übermitteln.

6. Einen zusammenfassenden Bericht erstellen. Erstellt eine kurze Zusammenfassung aller betroffenen Einrichtungen, des gesamten Personals, der verschobenen Assets, der Zieleinrichtungen und etwaiger Bedenken zur Überprüfung im Chat.

Die Zuweisungslogik des Agenten folgt realen Einschränkungen: Unterbringungskapazitäten nicht überschreiten, wenn möglich Versetzungen innerhalb desselben Zweigs bevorzugen, gemeinsame Stützpunkte bei zweigübergreifendem Überlauf nutzen und die Entfernung priorisieren, um die Transitzeit zu minimieren.

Das Tool für die nächstgelegene Einrichtung

Die zugrunde liegende Workflow-Abfrage verwendet geo_shape mit einem circle-Filter und einer _geo_distance-Sortierung:

"query": {
  "bool": {
    "filter": [
      {
        "geo_shape": {
          "entity_geo_location": {
            "shape": {
              "type": "circle",
              "coordinates": [{{ inputs.lon }}, {{ inputs.lat }}],
              "radius": "5000km"
            },
            "relation": "intersects"
          }
        }
      },
      { "term": { "operational_status.keyword": "act" } }
    ]
  }
},
"sort": [
  {
    "_geo_distance": {
      "entity_geo_point": { "lat": {{ inputs.lat }}, "lon": {{ inputs.lon }} },
      "order": "asc",
      "unit": "km"
    }
  }
],
"script_fields": {
  "available_capacity": {
    "script": {
      "source": "Math.max(0, doc['housing_capacity'].value - doc['personnel_count'].value)"
    }
  }
}

Die verfügbare Kapazität wird zum Abfragezeitpunkt über ein Skriptfeld berechnet, das die Unterbringungskapazität abzüglich des aktuellen Personalbestands ermittelt. Der Agent verwendet dies, um Personal auf Zielorte zu verteilen, ohne Grenzen zu überschreiten.

Hurrikan ELARA-26: agentische Koordination von 137.000 Einsatzkräften, von Anfang bis Ende

Hurrikan ELARA-26 ist ein Sturm der Kategorie 4 (maximale Windgeschwindigkeit von 213 km/h), der laut Vorhersage im Gebiet Hampton Roads in Virginia auf Land treffen wird. Wenn das GDACS-Ereignis aufgenommen wird, schneidet das Polygon des betroffenen Gebiets sieben wichtige Militäreinrichtungen in der Region. Die Erkennungsregel wird ausgelöst. Der Workflow startet eine Agentenkonversation.

Innerhalb einer einzelnen agentischen Schleife führt der Agent Folgendes aus:

• Sieben Einrichtungen in der Einschlagszone wurden identifiziert, mit insgesamt 137.372 Einsatzkräften.

• mitra.nearest_facility wurde angerufen, um Empfangseinrichtungen außerhalb des Sturmpfads zu finden.

• Einsatzkräfte wurden basierend auf der verfügbaren Unterbringungskapazität und Entfernung auf neun Aufnahmeeinrichtungen verteilt.

• Evakuierungsanordnungen wurden für alle sieben betroffenen Anlagen erstellt und versandt.

• Aufnahmebenachrichtigungen wurden erstellt und an alle neun empfangenden Einrichtungen versandt.

• Eine vollständige Koordinationszusammenfassung wurde erstellt, ähnlich wie unten:

Evakuierte Einrichtungen:

Aufnahmeeinrichtungen:

Zu den verlegten Einsatzmitteln gehören Transportfahrzeuge, Hubschrauber, Patrouillenboote, medizinische Einheiten, Pionierfahrzeuge, Generatoren, Wassertankanhänger, Notunterkunfts-Sets und Kommunikationssysteme.

Automatisierte E-Mail-Benachrichtigungen

Sobald der Agent seinen Zuweisungsplan fertiggestellt hatte, rief er mitra.send_email auf und versandte in einem einzigen Durchlauf 16 E-Mails, nämlich Evakuierungsanordnungen an alle sieben betroffenen Einrichtungen und Aufnahmebenachrichtigungen an alle neun aufnehmenden Einrichtungen. Jede Nachricht enthielt die Zieleinrichtung, die Anzahl der eintreffenden Personen, die zu verlegenden Assets und einen Ansprechpartner für die Koordination. Was andernfalls Stunden an Telefonketten erfordert hätte, wurde automatisch erledigt, sobald der Agent seine Überlegungen abgeschlossen hatte.

Erweiterung der agentischen Katastrophenreaktion mit RAG und Richtlinienverankerung

Diese Demo basiert rein auf strukturierten Daten wie Kapazitätszahlen, Entfernungen und Betriebsstatus. Die Funktionen von Elastic für semantische Suche und Retrieval-Augmented Generation (RAG) können den Agenten durch zwei Ergänzungen deutlich intelligenter machen:

Abruf historischer Reaktionen: Indexieren Sie frühere After-Action-Berichte, Vorfallszusammenfassungen der Federal Emergency Management Agency (FEMA) und Einträge zur Katastrophenreaktion als Vektoreinbettungen. Wenn ein neues Ereignis ausgelöst wird, kann der Agent semantisch abrufen, wie ähnliche Ereignisse gehandhabt wurden, und so Zuteilungsentscheidungen mit institutionellem Wissen statt reiner Kapazitätsberechnung fundieren.

Verankerung in Richtlinien und Doktrin: Indexieren Sie DoD-Richtlinien für das Notfallmanagement, Pläne zur Aufrechterhaltung des Betriebs der Einrichtung und Anweisungen des Kommandeurs. Der Agent kann die tatsächlichen Richtlinien abrufen und zitieren, die eine Reaktion regeln, und so sicherstellen, dass jede Entscheidung in der Doktrin und nicht in Schlussfolgerungen verankert ist.

Beide folgen demselben Elastic-nativen Ansatz:; Eine Inferenz-Pipeline generiert Einbettungen beim Indexieren, und dem Agenten wird ein Tool für die semantische Suche bereitgestellt. Die Koordinierungs-Pipeline bleibt unverändert. Der Agent wird einfach intelligenter.

Warum Elasticsearch die richtige Plattform für die agentische Reaktion im öffentlichen Sektor ist

Das ist kein Chatbot. Es ist kein Dashboard. Es ist ein responsives agentisches Workflow-System – eines, das eine Bedrohung erkannt, ein komplexes Logistikproblem durchdacht und die Versetzung von 137.000 Menschen ohne menschliche Beteiligung koordiniert hat. Ein solches Ergebnis ist nur möglich, weil jede Funktion, auf die es angewiesen ist, auf einer einzigen, einheitlichen Plattform liegt.

Die Geodatenunterstützung von Elasticsearch (geo_point, geo_shape, Anreicherungsrichtlinien und entfernungsbasierte Sortierung) übernimmt das räumliche Denken, das Schnittpunkterkennung und die Standortsuche im großen Maßstab möglich macht. Semantische Suche und Vektor-Einbettungen verankern Agenten in der Realität und stellen sicher, dass KI-Schlussfolgerungen auf den tatsächlichen Inhalten Ihrer Daten basieren und nicht auf halluzinierten Annahmen. Die Erkennungs-Engine, Workflows, der Agent Builder und die Agent Builder-Tools von Kibana verbinden all dies zu einer Pipeline, die vom Rohereignis bis zur koordinierten Aktion reicht – ganz ohne externen Glue-Code.

Keine andere Plattform bringt dies so zusammen wie Elastic. Die Kombination aus Echtzeit-Indexieren, georäumlicher Präzision, semantischem Abrufen und agentischer Orchestrierung in einem einzigen Stack mit integrierter Sicherheit und Beobachtbarkeit auf Enterprise-Niveau unterscheidet Elastic von Tools, die eine dieser Aufgaben zwar gut bewältigen, bei denen Sie den Rest jedoch selbst zusammenfügen müssen.

Agentische georäumliche Reaktion für Notfallmanagement, Feuerwehr, Strafverfolgung und öffentliche Gesundheit

Dieselbe Architektur gilt überall dort, wo Menschen, Einrichtungen und Echtzeitereignisse aufeinandertreffen. Die spezifischen Daten ändern sich. Die Pipeline nicht.

Katastrophenschutz: FEMA und die Katastrophenschutzbehörden der Bundesstaaten können Standorte von Notunterkünften, Bereitstellungsräume und gefährdete Bevölkerungsgruppen mit eingehenden Unwetter-Polygonen des National Weather Service (NWS) abgleichen und so die automatisierte Vorabpositionierung von Ressourcen auslösen, bevor ein Sturm das Festland erreicht.

Feuerwehr und Rettungsdienste: Feuerwehren können die Standorte von Einheiten und Reaktionszonen mit Waldbrandgrenzen oder Gebäudebrand-Clustern überlagern und Anforderungen für überörtliche Hilfe automatisch an die nächstgelegenen verfügbaren Einheiten mit der passenden Ausrüstung weiterleiten.

Strafverfolgung: Behörden können Standorte aktiver Vorfälle mit Schulzonen, kritischer Infrastruktur und den Positionen von Einsatzkräften korrelieren und so ohne Warten auf eine manuelle Triage standortbezogene Lockdown-Benachrichtigungen oder die Entsendung von Ressourcen auslösen.

Sicherheit an öffentlichen Schulen: Schulbezirke können Bedrohungsfeeds in Echtzeit im Hinblick auf Campusgrenzen überwachen. Wenn eine Bedrohung die Grenzen eines Schulgeländes überschreitet, kann ein Agent sofort die Schulleitung benachrichtigen, die Lockdown-Kommunikation einleiten und die Reaktion der Strafverfolgungsbehörden koordinieren – noch bevor ein Disponent zum Telefon greift.

Öffentliches Gesundheitswesen: Gesundheitsbehörden können Daten zur Krankheitsüberwachung oder Umweltgefahrenzonen mit Klinikstandorten, Ebenen zur Bevölkerungsdichte und Beständen in Versorgungsdepots abgleichen, um Ressourcen dorthin zu leiten, wo sie am dringendsten benötigt werden.

Die Daten sind in jedem Szenario unterschiedlich. Das zugrunde liegende Muster aus Ingest, Datenanreicherung zur Indexzeit, Erkennung von Schnittmengen, Auslösen einer agentischen Reaktion und Handeln ist immer dasselbe. Elastic bietet Organisationen im öffentlichen Sektor die Platform, es einmal zu entwickeln und überall anzupassen.

Die Entscheidung über die Veröffentlichung der in diesem Blogeintrag beschriebenen Leistungsmerkmale und Features sowie deren Zeitpunkt liegt allein bei Elastic. Es ist möglich, dass noch nicht verfügbare Leistungsmerkmale oder Features nicht rechtzeitig oder überhaupt nicht veröffentlicht werden.