AAR wspomagany przez AI: przekształcanie danych z ćwiczeń w wiedzę

Każde ćwiczenie generuje znacznie więcej danych, niż jakikolwiek ludzki zespół jest w stanie przejrzeć. Jedno konstruktywne ćwiczenie na poziomie batalionu może wyprodukować miliony aktualizacji stanu obiektów, tysiące zdarzeń broniowych i godziny ruchu radiowego – a momenty dydaktyczne są gdzieś pochowane w tej masie danych. Tradycyjnie ich znajdowanie było zadaniem analityków ręcznie przeglądających nagrania, ścigających się z czasem, by zmontować analizę, zanim grono szkolące się rozejdzie. AAR wspomagany przez AI zmienia ekonomikę tej pracy: automatyzuje redukcję danych, dzięki czemu ludzki obserwator-kontroler może poświęcić swój czas na interpretację i coaching zamiast na poszukiwanie zdarzeń. Ten artykuł analizuje, jak zbudowany jest taki potok — od pobierania telemetrii przez wykrywanie zdarzeń, rekonstrukcję osi czasu i metryki, aż po samą analizę — i gdzie tak naprawdę leży złożoność inżynieryjna.

Dlaczego analiza po działaniu jest problemem danych

Analiza po działaniu jest punktem, w którym ćwiczenie staje się nauką. Doktryna jest dobrze ugruntowana: przejrzyj, co miało się wydarzyć, co faktycznie się wydarzyło, dlaczego wystąpiła różnica i co zrobić inaczej. Ograniczeniem nigdy nie była doktryna — były nim dane. Im bogatsze i bardziej realistyczne ćwiczenie, tym więcej danych produkuje i tym trudniej jest zlokalizować kilka momentów, które faktycznie zdecydowały o wyniku.

Ręczna analiza nie skaluje się wraz z wiernością ćwiczenia. Analityk, który bez trudu może przejrzeć zaangażowanie na poziomie plutonu w czasie rzeczywistym, jest przytłoczony ćwiczeniem brygadowym prowadzącym dziesiątki jednoczesnych zaangażowań na rozległym obszarze. Rezultatem jest to, że duże ćwiczenia są analizowane powierzchownie: oczywiste zdarzenia są omawiane, subtelne — pominięty meldunek, decyzja, która nadeszła trzydzieści sekund za późno, pododział, który wypadł z wzajemnego wsparcia — pozostają niezbadane właśnie dlatego, że są trudne do znalezienia. AI AAR istnieje, by to odwrócić. System odczytuje wszystko, a człowiek przeglądać to, co istotne.

To ujęcie ma znaczenie dla projektowania systemu. Celem nie jest zastąpienie osądu obserwatora-kontrolera algorytmem; chodzi o usunięcie ciężaru redukcji danych, który uniemożliwia obserwatorowi-kontrolerowi sprawowanie osądu na dużą skalę. Potok generujący dopracowany zautomatyzowany raport, któremu nikt nie ufa, jest porażką. Potok, który daje zajętemu obserwatorowi uszeregowaną listę zwalidowanych zdarzeń i oś czasu do omówienia, jest sukcesem.

Fundament telemetryczny

Wszystko w potoku AI AAR zależy od przechwycenia i synchronizacji telemetrii ćwiczenia. W symulacji konstruktywnej i wirtualnej głównym źródłem jest strumień stanu obiektów przesyłany przez DIS (Distributed Interactive Simulation) lub HLA (High Level Architecture): pozycja, prędkość, orientacja, wygląd i status każdego obiektu w ćwiczeniu, aktualizowane kilka razy na sekundę. Na to nakładają się zdarzenia dyskretne — otwarcie ognia, detonacje, kolizje, emisje — oraz sygnał ludzki: sieci radiowe, czat i własne adnotacje obserwatora-kontrolera wprowadzane podczas przebiegu.

Szkolenie na żywo dostarcza tych samych logicznych strumieni z różnych czujników. Instrumentowane systemy, takie jak laserowy sprzęt zaangażowania MILES i jednostki GPS graczy, dostarczają danych o pozycji i zaangażowaniu; magistrale danych pojazdów i zestawy dla żołnierzy pieszych dodają zdarzenia broniowe i statusowe. Dane są głośniejsze i mają luki tam, gdzie instrumentacja wypada, ale potok, który je przetwarza, jest strukturalnie taki sam.

Pierwszy trudny problem inżynieryjny to synchronizacja. Zegar symulacji, zegar ścienny i zegar każdego źródła instrumentacji rzadko są zgodne, a kilkaset milisekund odchylenia wystarczy, by przypisać strzał do niewłaściwego celu lub umieścić zdarzenie w niewłaściwej fazie. Potok musi rozwiązać każdy rekord na jednej autorytatywnej osi czasu, zanim cokolwiek innego nastąpi. Drugi problem to rozwiązywanie tożsamości obiektów: ten sam pojazd może pojawić się w strumieniu symulacji, strumieniu instrumentacji i wywołaniu radiowym pod trzema różnymi identyfikatorami, a system musi rozpoznać je jako jeden obiekt w kanonicznym rejestrze. Błędy w tych dwóch fundamentach dziedziczy każda późniejsza analityka.

Budowanie spójnego stanu świata

Po zsynchronizowaniu telemetrii i rozwiązaniu obiektów potok rekonstruuje ciągły stan świata — substrat, o który zapytuje każdy detektor i metryka. Ślady obiektów są interpolowane między aktualizacjami, by pozycja dowolnego obiektu mogła być zapytana w dowolnym momencie. Zdarzenia broniowe są przypisywane do strzelca i celu poprzez połączenie geometrii, czasu i przynależności do siły obiektów. Każdy obiekt jest opatrzony etykietą z hierarchią pododdziału, tak by analityki mogły sumować indywidualne działania do poziomu drużyny, plutonu i kompanii. Ten stan świata jest w istocie odpytywalną rekonstrukcją całego ćwiczenia — tą samą rekonstrukcją, którą analityk buduje w swojej głowie podczas przeglądania, uczynioną jawną i maszynowo czytelną.

Automatyczne wykrywanie zdarzeń

Wykrywanie zdarzeń to miejsce, gdzie system zasługuje na swoje miejsce. Celem jest wydobycie momentów wartych omówienia i uszeregowanie ich według istotności, tak by obserwator-kontroler zaczynał od trzydziestu najwartościowszych zdarzeń, a nie od pełnego nagrania.

Wykrywanie działa najlepiej jako podejście warstwowe. Detektory regułowe obsługują dobrze zdefiniowane zdarzenia z precyzyjnymi definicjami: zaangażowanie to zdarzenie otwarcia ognia po którym następuje zmiana statusu celu; strata to ocena zniszczenia; przekroczenie linii fazowej to przecięcie przez ślad obiektu zaplanowanego środka kontroli; bratobójstwo to zaangażowanie między dwoma obiektami o tej samej przynależności do siły. Te detektory są przejrzyste i audytowalne — obserwator może dokładnie zobaczyć, dlaczego każde zdarzenie zostało uruchomione, co jest niezbędne, gdy wnioski AAR muszą być bronione przed grupą szkolącą się.

Detektory statystyczne i uczone obsługują rozmyte wzorce, które opierają się precyzyjnym regułom: utrata spójności pododdziału w miarę jak obiekty wypadają z odległości wzajemnego wsparcia, opóźnienie decyzji jako luka między zdarzeniem wyzwalającym a reakcją pododdziału, lub utracona szansa, gdy istniała korzystna geometria, ale nigdy nie była wykorzystana. Te detektory są potężniejsze i trudniejsze do wyjaśnienia, co jest dokładnie powodem, dla którego powinny proponować kandydatów na zdarzenia do ludzkiej weryfikacji zamiast stwierdzać wnioski. To samo rozdzielenie przejrzystej logiki wysokopoziomowej od nauczonego rozpoznawania wzorców niskopoziomowych, które reguluje dobre systemy szkoleniowe adaptujące się do AI, ma zastosowanie tutaj.

Punktacja i ranking istotności

Wykrycie zdarzenia nie wystarczy; potok musi zdecydować, które zdarzenia zasługują na ograniczoną uwagę obserwatora. Każde zdarzenie-kandydat jest oceniane według kilku czynników: wpływ na wynik (czy zmienił, kto wygrał zaangażowanie lub kto przeżył?), rzadkość (rutynowe zaangażowanie otrzymuje niższy wynik niż rzadkie bratobójstwo) i związek z zadeklarowanymi celami szkoleniowymi (ćwiczenie skupione na nawoływaniu ognia nadaje wyższą wagę zdarzeniom wsparcia ogniowego). Ocenione zdarzenia są uszeregowane, a analiza zaczyna się od szczytu listy. Ten ranking jest najcenniejszym operacyjnie wynikiem systemu — to on przekształca niemożliwe do opanowania nagranie w skończony, priorytetowy plan analizy.

Rekonstrukcja osi czasu i metryki wydajności

Uszeregowane zdarzenia są najbardziej przydatne umieszczone na strukturalnej osi czasu. Potok składa wykryte zdarzenia w zaplanowane fazy ćwiczenia i punkty decyzyjne, tak by analiza mogła podążać za operacją zgodnie z projektem i pytać na każdym etapie, co miało się wydarzyć w porównaniu z tym, co się wydarzyło. Oś czasu zorganizowana wokół planu — nie tylko płaski dziennik chronologiczny — pozwala dyskusji łączyć zdarzenia taktyczne z decyzjami, które je wywołały.

Na tej osi czasu potok oblicza metryki wydajności, które ilościowo określają zachowanie grupy szkolonej. Użyteczne rodziny metryk obejmują metryki decyzyjne (czas do decyzji, opóźnienie decyzji od zdarzenia wyzwalającego do działania), skuteczność zaangażowania (współczynnik trafień, czas do pierwszego strzału, wskaźnik bratobójstwa), tempo i ruch (tempo postępu, czas w miejscu pod obserwacją, czas na oczyszczenie celu) oraz metryki komunikacji (liczba wiadomości, opóźnienie odpowiedzi, kompletność raportowania względem wymagań pododdziału). Każda z nich mapuje się na miary wydajności i efektywności ćwiczenia.

Praktyczną konsekwencją jest to, że warstwa metryk powinna być konfigurowalna per ćwiczenie, a nie stała. Ćwiczenie na żywo, wirtualne ćwiczenie stanowiska dowodzenia i konstruktywna gra wojenna brygady mierzą zupełnie różne rzeczy, a ten sam pulpit nawigacyjny dla wszystkich trzech nie służy żadnemu z nich dobrze. Potok powinien pozwolić projektantowi ćwiczenia wybrać miary, które mapują się na cele tego ćwiczenia, zdefiniować ich progi i powiązać je z odpowiednimi fazami — tak by metryki pojawiające się w analizie były dokładnie tymi, które ćwiczenie zostało zaprojektowane, by poświadczyć.

Dyscyplina oddzielająca przydatną warstwę metryk od wprowadzającej w błąd to wiązanie kontekstowe: każda liczba musi być przypisana do segmentu osi czasu i obiektów, które ją wygenerowały. Współczynnik trafień prezentowany bez zaangażowania, które podsumowuje, prowokuje klasyczną porażkę analityki szkoleniowej — optymalizowanie metryki zamiast zachowania. Gdy pododział uczy się, że system nagradza wysoki współczynnik trafień, uczy się brać tylko łatwe strzały. Metryki w AAR są dowodem do dyskusji, a nie tablicą wyników, i system powinien je tak przedstawiać. Ta sama przestroga przed traktowaniem liczb jako celów zamiast dowodów jest szczegółowo omawiana w pracy dotyczącej mierzenia efektywności szkoleniowej gier wojennych.

Prezentacja analizy

Wynikiem potoku nie jest dokument — to interaktywny, zsynchronizowany replay. Obserwator-kontroler musi móc przejść do dowolnego uszeregowanego zdarzenia, zobaczyć rekonstrukcję mapy i odpowiednie metryki obok siebie oraz odtworzyć moment z wielu perspektyw: widoku dowódcy sił własnych, widoku sił przeciwnika i widoku obiektywnej prawdy gruntu. Wierność tego replay'u decyduje o tym, czy AAR przekonuje. Osoby szkolące się akceptują wniosek, który mogą zobaczyć rozwijający się na mapie, znacznie chętniej niż liczbę na slajdzie.

Co ważne, warstwa prezentacji musi rejestrować osąd obserwatora, nie tylko wyświetlać wyniki maszyny. Obserwator akceptuje, odrzuca, adnotuje i zmienia kolejność zdarzeń-kandydatów oraz zapisuje, dlaczego każde zdarzenie miało znaczenie i co pododział powinien zrobić inaczej. Służy to dwóm celom. Po pierwsze, adnotowany, zwalidowany zestaw zdarzeń to dostarczony AAR — produkt, z którym odchodzi grupa szkoląca się. Po drugie, decyzje accept/reject obserwatora to dane z etykietami, które poprawiają detektory i punktację istotności przy następnym ćwiczeniu. Przez wiele ćwiczeń system uczy się, na jakie zdarzenia dany obserwator-kontroler zwraca uwagę, a ranking się poprawia. Głębsze omówienie podziału pracy między recenzentami a narzędziami znajdziesz w artykule o oprogramowaniu do analizy po działaniu.

Utrzymanie człowieka w roli dowódcy analizy

Powracające ryzyko projektowe w AI AAR to nadmierna automatyzacja — budowanie systemu, który dostarcza wnioski zamiast dowodów. AAR to rozmowa coachingowa i żadna ilość zautomatyzowanej analizy sama w sobie nie zmienia zachowania. Właściwą rolą potoku jest wykonanie czytania, bookkeepingu i arytmetyki, których żaden człowiek nie może wykonać na skalę ćwiczenia, a następnie cofnięcie się. Obserwator-kontroler decyduje, co zdarzenia oznaczają, dlaczego wystąpiła różnica między zamiarem a rzeczywistością i co pododział zrobi inaczej następnym razem. System zaprojektowany wokół tego podziału pracy wzmacnia obserwatora-kontrolera; system, który próbuje go zastąpić, produkuje analizy, którym nikt nie ufa i z których nikt się nie uczy.