AI Vision do przetwarzania SITREP: automatyczna ekstrakcja obiektów i umieszczanie na mapie

Każde taktyczne centrum dowodzenia działa w oparciu o SITREP — meldunki sytuacyjne agregujące obserwacje od szczebla plutonu w górę, tworząc spójny obraz sytuacji na polu walki. Problem polega na tym, że znaczna część tych SITREP nadal dociera w postaci odręcznych szkiców na papierze, sfotografowanych map, opatrzonych adnotacjami wydruków satelitarnych lub zeskanowanych formularzy. Zanim którakolwiek z tych informacji trafi do cyfrowego wspólnego obrazu operacyjnego (COP), przechodzi przez operatora, który czyta dokument, identyfikuje każdy obiekt taktyczny, przepisuje referencje siatki i ręcznie nanosi jednostkę lub zagrożenie na ekran. Ten ręczny krok ponownego wprowadzania danych jest wąskim gardłem i jednym z najbardziej efektywnych celów dla AI vision w operacjach wojskowych.

Ten artykuł opisuje pełny potok techniczny automatyzacji przetwarzania SITREP za pomocą AI vision: od pobrania obrazu i wstępnego przetwarzania przez ekstrakcję obiektów, parsowanie współrzędnych, wnioskowanie symboli NATO po generowanie komunikatów CoT do umieszczania w TAK. Omówiono, gdzie potok może działać autonomicznie, gdzie wymagane jest potwierdzenie człowieka, jak integruje się z CloudTAK przez TAKpilot i co jest potrzebne do uruchomienia go na sprzęcie granicznym w środowiskach bez połączenia.

Wąskie gardło przetwarzania SITREP

Polowy SITREP docierający do batalionu operacyjnego zwykle przybiera jedną z kilku form fizycznych: odręczny szkic na arkuszu z nakładką siatki, fotografia mapy z adnotacjami sporządzonymi kredką lub markerem, zeskanowany lub sfotografowany wydrukowany formularz z polami wypełnionymi odręcznie lub — coraz częściej — zdjęcie wykonane przez żołnierza smartfonem i przesłane przez komunikator. Każdy z tych przypadków wymaga od operatora tych samych czynności: identyfikacji znaku wywoławczego jednostki raportującej, znalezienia referencji siatki dla każdego zaobserwowanego obiektu, określenia jego typu (przyjazny, wrogi, nieznany; typ pojazdu, koncentracja wojsk, przeszkoda, stanowisko ogniowe) i wprowadzenia wszystkiego do cyfrowego COP.

W spokojnych warunkach proces ten zajmuje 3–8 minut na jeden SITREP. Pod presją, w nocy lub podczas operacji o wysokim tempie, gdy w ciągu godziny może napłynąć kilkadziesiąt SITREP, staje się wąskim gardłem wprowadzającym niebezpieczne opóźnienia do obrazu taktycznego. Uwaga poznawcza operatora — która powinna być skoncentrowana na interpretacji i wsparciu decyzji — jest pochłaniana przez przepisywanie. Błędy w transkrypcji są powszechne: przestawione cyfry siatki, błędnie odczytane znaki wywoławcze, niejednoznaczna identyfikacja symboli. Cyfrowy COP pozostaje w tyle za rzeczywistą sytuacją o czas potrzebny do przetworzenia zaległości.

Modele AI vision eliminują to wąskie gardło, automatyzując krok transkrypcji. Operator przesyła lub przekazuje dokument; model ekstrahuje obiekty, rozwiązuje współrzędne, identyfikuje symbole i generuje ustrukturyzowane wyjście gotowe do umieszczenia na mapie. Rola operatora zmienia się z przepisywacza na recenzenta — potwierdzającego lub korygującego wynik modelu przed zatwierdzeniem go do COP, co zajmuje sekundy, a nie minuty.

Potok modelu vision: od pobrania do ustrukturyzowanej ekstrakcji

Potok rozpoczyna się od pobrania obrazu. Formaty wejściowe obejmują fotografie JPEG i PNG, skany PDF oraz okazjonalnie klatki wideo z urządzenia żołnierza. W przypadku wielostronicowych PDF każda strona jest rasteryzowana do obrazu o wysokiej rozdzielczości (minimum 300 DPI dla skanów formularzy; 150 DPI jest dopuszczalne dla wielkopowierzchniowych fotografii map, gdzie odpowiednie adnotacje są duże). Krok ekstrakcji metadanych rejestruje wszelkie dane EXIF — w szczególności znacznik czasu i współrzędne GPS, jeśli obraz został wykonany smartfonem — co może służyć jako estymacja oczekiwanego obszaru działań.

Wstępne przetwarzanie jest najbardziej wpływową fazą dla dokładności ekstrakcji na zdegradowanych dokumentach polowych. Potok stosuje: prostowanie przekosów za pomocą analizy profilu projekcji lub detekcji linii Hougha, korygując obroty dokumentu do ±15° powszechne w zdjęciach wykonanych z ręki; adaptywną binaryzację (algorytm Sauvola) zamiast progowania globalnego, która obsługuje nierówne oświetlenie typowe dla dokumentów fotografowanych w warunkach polowych; CLAHE do odzyskiwania śladów ołówka o niskim kontraście, które globalne wzmocnienie kontrastu by wymazało; morfologiczne usuwanie szumów za pomocą przebiegu otwierania/zamykania dostosowanego do oczekiwanej minimalnej szerokości pociągnięcia; oraz analizę układu do segmentacji dokumentu na obszary tekstowe, obszary symboli i obszary nakładki siatki przed skierowaniem każdego do odpowiedniego modułu przetwarzania. Ten krok segmentacji jest ważny: modele OCR zastosowane do obszarów symboli taktycznych dają bezsensowne wyniki, a klasyfikatory symboli zastosowane do odręcznych pól tekstowych dają błędne dopasowania.

Ekstrakcja współrzędnych: MGRS, UTM i pozycje względne

Ekstrakcja referencji siatki jest najbardziej technicznie wymagającą częścią przetwarzania SITREP, ponieważ odręczne ciągi MGRS są niejednoznaczne na wiele sposobów jednocześnie. Format to: Desygnator Strefy Siatki (liczba 1–60, po której następuje litera C–X), dwuliterowy identyfikator kwadratu 100 km i numeryczna para wschód/północ o równej długości (2, 4, 6, 8 lub 10 cyfr). Dziesięciocyfrowy ciąg MGRS określający pozycję z precyzją 1 m ma 15 znaków zmiennego formatu, pisanych odręcznie przez kogoś pod presją, w poruszającym się pojeździe, możliwie przy słabym oświetleniu.

Podejście do ekstrakcji łączy wyjście OCR ze strukturalnym walidatorem. Po tym, jak etap ekstrakcji tekstu generuje surowe sekwencje tokenów z obszarów tekstowych dokumentu, każdy token jest testowany pod kątem wzorca wyrażenia regularnego dla prawidłowego formatu MGRS. Tokeny pasujące są rejestrowane jako referencje siatki o wysokiej pewności. Tokeny częściowo pasujące, ale niezaliczające walidacji, są przekazywane do modułu rozmytej korekty: dopasowanie odległości edycji względem wstępnie obliczonej tabeli przeglądowej prawidłowych kombinacji Desygnatora Strefy Siatki i kwadratu 100 km dla teatru operacji. Referencja siatki, która nie przeszła czystego parsowania, ale pasuje do prawidłowego prefiksu MGRS w odległości Levenshteina 2, jest akceptowana z obniżoną pewnością i oznaczana do weryfikacji przez operatora.

Referencje UTM (które używają niektóre jednostki, w szczególności siły spoza NATO lub działające w oparciu o systemy starszego typu) są obsługiwane przez równoległy tor ekstrakcji. Walidator sprawdza numer strefy, literę półkuli i parę wschód/północ w notacji dziesiętnej lub stopień-minuta-sekunda.

Referencje pozycji względnych — niezwykle powszechne w odręcznych szkicach, gdzie obiekt jest umieszczony jako „400 m NE od punktu kontrolnego BRAVO" zamiast jawnych współrzędnych — wymagają rozumowania przestrzennego wykraczającego poza dopasowanie wyrażeń regularnych. Potok używa podpowiedzi chain-of-thought na VLM (lub opartego na regułach parsera dla granicznego wdrożenia bez połączenia), aby wyodrębnić punkt odniesienia, azymut (interpretowany z notacji kompasowej, kardynalnej lub miedzikardynalnej) i odległość z jednostką. Rozwiązana współrzędna WGS-84 punktu odniesienia jest następnie przesuwana o azymut i odległość, aby obliczyć pozycję pochodną. Współrzędne pochodne mają powiększoną wartość błędu kołowego (CE) — zwykle 100–500 m w zależności od precyzji opisu przesunięcia — która jest przekazywana do komunikatu CoT, aby klienci TAK renderowali odpowiedni pierścień niepewności na mapie.

Wnioskowanie symboliki NATO: dopasowanie odręcznych symboli do MIL-STD-2525C

Symbole taktyczne w odręcznych SITREP wahają się od starannych, zgodnych ze standardami renderings do minimalistycznych szkiców, które tylko luźno przypominają kanoniczne formy APP-6/MIL-STD-2525C. Kolorowy prostokąt z kołem na górze to prawdopodobnie jednostka piechoty. X wewnątrz prostokąta prawdopodobnie wskazuje zniszczony lub wyeliminowany obiekt. Strzałka z linią przez nią może być przeszkodą lub granicą. Potok vision musi mapować te szkice na 15-znakowe ciągi kodowania identyfikacji symboli (SIDC), kodujące przynależność, wymiar walki, status, funkcję, modyfikatory i kod kraju.

Klasyfikacja symboli używa klasyfikatora CNN wytrenowanego na syntetycznym zbiorze danych symboli APP-6/MIL-STD-2525C renderowanych w zakresie warunków degradacji: różna szerokość pociągnięć, obrót do ±30°, niekompletne renderowanie (symulujące przerywane rysowanie odręczne) i szum tła typowy dla fotografii papieru na tle mapy. Klasyfikator jest trenowany jako problem hierarchiczny: najpierw przewidywana jest przynależność (przyjazny/wrogi/neutralny/nieznany) i wymiar walki (ląd/powietrze/morze/przestrzeń/podpowierzchnia), następnie w każdej gałęzi przewidywany jest kod funkcji. Ta dekompozycja znacznie zmniejsza przestrzeń przeszukiwania klasyfikacji na każdym etapie.

Klasyfikator wyprowadza uszeregowaną listę kandydatów SIDC z prawdopodobieństwami softmax. Najlepszy kandydat powyżej konfigurowalnego progu pewności (domyślnie 0,80) jest akceptowany do automatycznego przetwarzania. Poniżej progu obiekt jest kierowany do kolejki oczekującej na potwierdzenie operatora — interfejs prezentuje wycięty obraz symbolu obok trzech najlepszych kandydatów, aby operator mógł wybrać właściwy jednym dotknięciem. Cały system jest zaprojektowany tak, aby interfejs potwierdzania był szybszy niż ręczne wprowadzanie nawet dla wszystkich obiektów jednocześnie, nie tylko dla tych powyżej progu.

Generowanie komunikatów CoT: od obiektów do umieszczania w TAK

Po wyodrębnieniu współrzędnych i przypisaniu kodów SIDC obiekty muszą zostać spakowane do dostarczenia do ekosystemu TAK. XML Cursor-on-Target (CoT) jest standardowym formatem wymiany. Każde zdarzenie CoT ma następującą obowiązkową strukturę: uid (unikalny identyfikator wyprowadzony z identyfikatora dokumentu i numeru sekwencji obiektu), type (ciąg typu CoT wyprowadzony z kodu SIDC za pomocą standardowej tabeli mapowania MIL-STD-2525C-do-CoT), trójka znaczników czasu time, start i stale, oraz element point zawierający wartości szerokości geograficznej, długości geograficznej, wysokości, błędu kołowego (CE) i błędu liniowego (LE) w WGS-84.

Dodatkowe szczegóły dotyczące obiektu — znak wywoławczy, oznaczenie jednostki, jednostka obserwująca, czas obserwacji, uwagi — są przenoszone w elemencie detail CoT. Potok ekstrahuje znak wywoławczy i oznaczenie jednostki z obszarów tekstowych SITREP za pomocą rozpoznawania nazwanych encji dostrojonego do konwencji nazewnictwa jednostek wojskowych (alfanumeryczne znaki wywoławcze, notacja hierarchii batalion-pułk-brygada). Czas obserwacji jest ekstrahowany z nagłówka dokumentu, jeśli jest obecny, lub domyślnie przyjmowany jest znacznik czasu pobrania dokumentu z zastosowaną karą pewności.

Ukończony pakiet XML CoT — jedno zdarzenie na każdy wyodrębniony obiekt — jest dostarczany do serwera TAK przez TCP (dla niezawodnej dostawy) lub multicast UDP (dla rozgłaszania do wszystkich klientów w sieci taktycznej). Klienci TAK — ATAK na Androidzie, WinTAK na laptopach Windows, iTAK na iOS, CloudTAK w przeglądarce — natychmiast renderują każdy obiekt w określonych współrzędnych, używając odpowiedniego symbolu MIL-STD-2525C. Wynikiem jest SITREP, który 15–30 sekund temu był fotografią, pojawiający się jako zestaw poprawnie opisanych ikon na wspólnej mapie każdego operatora.

Implementacja TAKpilot: potok vision zintegrowany z CloudTAK

TAKpilot (corvusintell.com/takpilot) to platforma operacyjna TAK firmy Corvus Intelligence, zawierająca zintegrowany potok przetwarzania SITREP vision połączony z CloudTAK. Przepływ pracy jest zaprojektowany wokół kroku potwierdzenia operatora jako podstawowego punktu interakcji człowiek-maszyna, zamiast traktowania modelu vision jako czarnej skrzynki zapisującej bezpośrednio do COP.

Operator otrzymuje fotografię SITREP — przez operatora radiowego, przekazanie przez komunikator lub bezpośrednie przesłanie — i przesyła ją do interfejsu TAKpilot. Plik jest transmitowany do backendu przetwarzania TAKpilot, który uruchamia pełny potok vision: wstępne przetwarzanie, analiza układu, OCR, ekstrakcja i walidacja współrzędnych, klasyfikacja symboli, ekstrakcja znaków wywoławczych i jednostek oraz generowanie CoT. Czas przetwarzania typowej fotografii SITREP wynosi 8–20 sekund, w zależności od złożoności dokumentu i tego, czy potok działa w trybie chmury (VLM API) czy trybie granicznym (skwantyzowany lokalny model).

Wynik jest prezentowany operatorowi jako karta potwierdzenia: ustrukturyzowana tabela zawierająca każdy wykryty obiekt z wyodrębnioną referencją siatki, typem symbolu (renderowanym jako ikona MIL-STD-2525C), znakiem wywoławczym, czasem obserwacji i wskaźnikiem pewności (zielony/żółty/czerwony) dla każdego pola. Obiekty z dowolnym polem poniżej progu są wyróżnione i wymagają indywidualnego potwierdzenia; obiekty powyżej progu są wstępnie zatwierdzone, ale nadal mogą być korygowane. Operator może edytować dowolne pole bezpośrednio — korygując błąd OCR lub zmieniając przypisanie symbolu — przed zatwierdzeniem. Zatwierdzenie karty wyzwala TAKpilot do przesłania pakietu CoT do podłączonego serwera CloudTAK.

Projekt karty potwierdzenia odzwierciedla operacyjną rzeczywistość, że zerowe pominięcia są ważniejsze niż zerowe opóźnienie: pominięty obiekt na mapie taktycznej jest bardziej niebezpieczny niż 10-sekundowe opóźnienie potwierdzenia. Interfejs jest zoptymalizowany do użytku mobilnego (tablet), aby operatorzy pracujący przy terminalu polowym mogli ukończyć potwierdzenie przy minimalnej liczbie naciśnięć klawiszy.

Dokładność i ocena pewności

Ocena pewności działa na dwóch poziomach: pewność na poziomie pola (indywidualna referencja siatki, klasyfikacja symbolu, ekstrakcja znaku wywoławczego) i pewność na poziomie obiektu (iloczyn wszystkich pewności pól, używany do decyzji o kierowaniu między automatycznym umieszczaniem a potwierdzeniem).

Pewność referencji siatki jest obliczana na podstawie trzech czynników: ocen pewności na poziomie znaków OCR wyprowadzonych przez model tekstowy, odległości edycji od najbliższego prawidłowego ciągu MGRS (zero dla czystego parsowania, wyższe dla rozmytej korekty) i sprawdzenia wiarygodności przestrzennej względem ograniczającego prostokąta teatru operacji. Referencja siatki, która czysto parsuje, dokładnie pasuje do prawidłowego ciągu MGRS i mieści się w oczekiwanym obszarze operacji, uzyskuje powyżej 0,92 i kwalifikuje się do automatycznego umieszczenia. Ta, która wymagała rozmytej korekty lub mieści się blisko granicy teatru, uzyskuje 0,65–0,85 i wymaga potwierdzenia.

Pewność klasyfikacji symbolu to prawdopodobieństwo softmax najlepszego kandydata SIDC. W kontrolowanych ocenach na zestawie testowym zebranych w terenie fotografii SITREP klasyfikator osiąga dokładność top-1 87% na poziomie kodu funkcji przy pewności powyżej 0,80, spadając do 61% poniżej tego progu. Dlatego próg 0,80 dla automatycznej akceptacji jest ważny: oddziela niezawodnie poprawny obszar od niejednoznacznego.

Niejednoznaczne symbole — te, dla których trzy najlepsze kandydaty są ściśle skupione (rozrzut softmax mniejszy niż 0,15) — są zawsze kierowane do potwierdzenia przez człowieka niezależnie od oceny najlepszego kandydata. Ścisłe skupienie wskazuje na autentyczną niejednoznaczność symbolu (odręczny symbol jest zgodny z wieloma znaczeniami taktycznymi), a nie na niską jakość wejścia, i prawidłowe rozwiązanie wymaga wiedzy operatora o kontekście taktycznym, której model nie posiada.

Wdrożenie graniczne: Jetson, węzły tylko z CPU i działanie bez połączenia

Przetwarzanie SITREP połączone z chmurą (kierowanie dokumentów do punktu końcowego VLM API) osiąga najwyższą dokładność ekstrakcji, ale wprowadza opóźnienie i zależność sieciową niedopuszczalną na taktycznej granicy. Potok vision TAKpilot jest zaprojektowany do pełnego działania w izolacji na sprzęcie granicznym.

NVIDIA Jetson AGX Orin jest głównym celem dla pełnoprawnego wdrożenia granicznego. Dzięki 64 GB ujednoliconej pamięci węzeł może uruchamiać skwantyzowany model vision-language o 7 miliardach parametrów (LLaVA-1.6 lub odpowiednik przy INT4 przez llama.cpp) do ogólnej ekstrakcji obiektów razem ze zoptymalizowanym przez TensorRT klasyfikatorem symboli. Pojedynczy obraz SITREP przetwarza się w 8–15 sekund. Jetson jednocześnie służy jako węzeł CloudTAK — TAKpilot i CloudTAK działają jako współlokalizowane usługi na tym samym urządzeniu, z dostarczaniem CoT przez loopback, a nie przez skok sieciowy. Ta architektura kolokacji jest ważna dla zaawansowanych sztabów, gdzie serwer TAK i system przetwarzania SITREP są na tym samym wzmocnionym węźle obliczeniowym.

Węzły tylko z CPU — tam, gdzie sprzęt GPU jest niedostępny lub moc jest ograniczona poniżej poziomu Jetsona — używają potoku dwóch modeli: PaddleOCR z modelami detekcji i rozpoznawania PPOCR-v4 do ekstrakcji tekstu (działa ~1 sekundę na stronę na nowoczesnym rdzeniu ARM64) i lekkiego klasyfikatora symboli MobileNetV3 przy kwantyzacji INT8 do rozpoznawania symboli. Krok VLM jest pomijany; parsowanie pozycji względnych wraca do opartego na regułach parsera przesunięć. Ten potok przetwarza SITREP w 3–6 sekund na nowoczesnym procesorze laptopa lub 8–20 sekund na jednomodułowym procesorze ARM (klasy Raspberry Pi 5), z nieco niższą dokładnością ekstrakcji na złożonych dokumentach, ale nadal operacyjnie użyteczną wydajnością dla najczęstszych formatów SITREP.

Aktualizacje modeli w terenie podążają za tym samym mechanizmem aktualizacji podpisanych pakietów opisanym dla innych wdrożeń edge AI: pakiet aktualizacji jest kryptograficznie podpisany, dostarczany przez kanał zarządzania TAKpilot i stosowany z automatycznym wycofaniem, jeśli metryki dokładności po aktualizacji spadną poniżej punktu odniesienia. Dostrajanie specyficzne dla teatru — adaptacja klasyfikatora symboli do konkretnych konwencji odręcznego rysowania jednostek w obszarze operacji — może być wysyłane do zaawansowanych węzłów jako delta modelu w ciągu 24 godzin od otrzymania oznakowanej partii próbek.

Przejście między trybem granicznym a chmurą jest przezroczyste dla operatora. Gdy łączność sieciowa jest dostępna, TAKpilot kieruje do potoku chmury dla wyższej dokładności. Gdy łączność spada — wykrywana przez 5-sekundowy limit czasu sprawdzania kondycji API — automatycznie wraca do lokalnego modelu bez interwencji operatora. Interfejs karty potwierdzenia jest identyczny w obu trybach; zmienia się tylko czas przetwarzania.