AI-Копілот для тактичних застосунків: як LLM-агенти керують загальною оперативною картиною

Тактичні оператори витрачають від 30 до 40 відсотків часу на управління COP на навігацію по меню. Це не конструктивна вада якогось одного застосунку — це структурний наслідок спроби відобразити весь оперативний інформаційний простір на сенсорний інтерфейс, розроблений для пальців, а не рукавиць, і для спокійних умов, а не бойового контакту. ATAK, WinTAK та їхні браузерні еквіваленти, як-от CloudTAK, є потужними інструментами. Вони також глибоко орієнтовані на меню, і кожен рівень цього дерева меню — це когнітивне навантаження, що надходить саме в той момент, коли оператор має найменший вільний ресурс уваги.

Гіпотеза за TAKpilot проста: найшвидший інтерфейс до складної системи — той, яким оператор уже вміє користуватися — мова. Якщо командир відділення може сказати «встав маркер на сітці 37U DP 12345 67890 з позивним ALPHA-3» радисту і він з'явиться на карті за десять секунд, то система, яка приймає ту саму фразу як чат-повідомлення і робить те саме за дві секунди, є суттєвим покращенням можливостей. TAKpilot — це така система: AI-копілот для CloudTAK, що перекладає природну мову в операції TAK API за допомогою виклику функцій LLM.

Проблема навігації по меню в тактичному програмному забезпеченні

Розгляньте типовий робочий процес розміщення маркера контакту ворога в ATAK: відкрити меню довгого натискання на карті, вибрати «Нова точка», перейти до селектора типу CoT, вибрати тип ворожого підрозділу з ієрархічного дерева MIL-STD-2525, ввести координати сітки в діалоговому вікні введення координат (перемикаючись між MGRS, десятковими градусами та DMS залежно від того, що запам'ятав оператор), додати позивний та примітки, натиснути підтвердити. Якщо пальці оператора замерзли, якщо він під вогнем, якщо він у транспортному засобі на ґрунтовій дорозі, кожне натискання несе реальну частоту помилок. Перемістіть контакт на один квадрат сітки — і вогнева місія зірветься.

Хронометражні дослідження з навчальних вправ незмінно показують, що досвідчені оператори ATAK витрачають 35–40% часу управління картою на навігацію по інтерфейсу, а не на прийняття рішень. Решта 60–65% розподіляється між читанням картини, спілкуванням по радіо та оновленням власних даних про місцезнаходження. Накладні витрати на навігацію — це не маленька помилка округлення; це більше третини когнітивного бюджету, який натомість міг би йти на ситуаційну обізнаність.

Природна мова не усуває потреби в точності — «сітка 37U DP 12345 67890» все одно вимагає від оператора знати координати — але вона повністю усуває накладні витрати на навігацію. Оператор вимовляє (або друкує) дію; система виконує її. Когнітивний шлях від «мені потрібно розмістити цей контакт» до «контакт на карті» — це один крок замість семи.

Чат-нативна архітектура: виклик функцій LLM як шар TAK API

Основна архітектура TAKpilot побудована на виклику функцій LLM — можливості сучасних великих мовних моделей не лише генерувати текст, але й обирати та параметризувати структуровані виклики функцій із визначеної бібліотеки інструментів. Кожна операція TAK API, надана CloudTAK, обгорнута у визначення інструменту: JSON-схему, що вказує назву функції, опис та типізовані параметри з обмеженнями валідації.

Репрезентативне визначення інструменту для розміщення маркера виглядає так:

{
  "name": "place_marker",
  "description": "Place a point-of-interest marker on the CloudTAK map at a specified grid coordinate.",
  "parameters": {
    "type": "object",
    "properties": {
      "mgrs": {
        "type": "string",
        "description": "MGRS grid reference, e.g. '37U DP 12345 67890'"
      },
      "callsign": {
        "type": "string",
        "description": "Callsign or label for the marker"
      },
      "cot_type": {
        "type": "string",
        "description": "MIL-STD-2525C CoT type string, e.g. 'a-h-G-U-C' for hostile ground combat"
      },
      "remarks": { "type": "string" }
    },
    "required": ["mgrs", "callsign", "cot_type"]
  }
}

Коли оператор надсилає «встав ворожий піхотний контакт на 37U DP 12345 67890, позивний CONTACT-7», модель отримує повідомлення разом із повною бібліотекою інструментів і обирає place_marker з відповідними параметрами — включно з розпізнаванням природномовного «ворожа піхота» до правильного рядка типу CoT. TAKpilot виконує виклик функції, маркер з'являється на карті, а оператор бачить згортну картку виклику інструменту в чаті з назвою функції, вхідними параметрами, часом виконання в мілісекундах та статусом HTTP-відповіді від CloudTAK.

Повна бібліотека інструментів TAKpilot охоплює основні операційні дієслова CloudTAK: розміщення та оновлення маркерів, створення та закриття місій, перелік активних треків з опціональним фільтром сектору, підписка та відписка від каналів даних, створення пакетів даних та запит статусу підрозділу. Складні багатокрокові операції — «створи місію CAS для BRAVO-7 на сітці 37U DP 98765 43210 і повідом усі підрозділи в каналі ALPHA» — обробляються моделлю, що послідовно зв'язує кілька викликів інструментів, з кожним проміжним результатом, видимим у чаті як окрема картка виклику інструменту.

Конвеєр комп'ютерного зору: від ескізу SITREP до розміщення на карті

Значна частина тактичної інформації все ще надходить у вигляді зображень: рукописні ескізи, сфотографовані на телефон, відскановані ситуаційні звіти, PDF-накладення, передані електронною поштою або месенджерами. Конвеєр комп'ютерного зору TAKpilot обробляє ці вхідні дані та перетворює їх на структуровані об'єкти карти через трьохетапний ланцюг.

Етап 1 — Витягування сутностей. Зображення (PNG, JPG або PDF, конвертований у PNG з високою роздільною здатністю) передається до моделі з підтримкою комп'ютерного зору зі структурованим запитом на витягування. Модель ідентифікує кожну релевантну для карти сутність у зображенні: координати сітки, позивні, символи типів підрозділів (з використанням розпізнавання MIL-STD-2525 або APP-6), лінії пеленгу, рубіжні лінії та вільнотекстові анотації. Результат — JSON-масив сутностей з типом, витягнутим текстом та показником достовірності.

Етап 2 — Підтвердження за ланцюгом думок. TAKpilot генерує повідомлення CoT (ланцюг думок, а не Cursor on Target), що представляє кожну витягнуту сутність оператору: «Я знайшов 4 сутності у вашому SITREP. Сутність 1: ворожий механізований піхотний взвод на 37U DP 12345 67890 (достовірність: 0,94). Сутність 2: дружній спостережний пост на 37U DP 11111 22222 (достовірність: 0,88)...» Кожна сутність відображається з запропонованим значком символіки NATO та точними координатами, які будуть використані для розміщення. Оператор переглядає список і або підтверджує всі, вибирає окремі елементи, або коригує неправильно прочитані координати перед тим, як щось потрапить на карту.

Етап 3 — Розміщення на карті. Після підтвердження оператором, TAKpilot надсилає відповідні виклики інструментів place_marker або create_mission для кожної підтвердженої сутності, пакетами та паралельно для швидкості. SITREP з десятьма сутностями, введення якого в ATAK зайняло б від чотирьох до шести хвилин, обробляється та розміщується менш ніж за тридцять секунд.

Конвеєр комп'ютерного зору коректно деградує для низькоякісних вхідних даних: якщо достовірність сутності падає нижче 0,70, TAKpilot явно позначає її як невизначену і просить оператора перевірити координати перед підтвердженням розміщення. Він не розміщує мовчки сутності з низькою достовірністю.

Шлюз підтвердження для деструктивних операцій

TAKpilot розрізняє два класи операцій: адитивні (розмістити маркер, створити місію, підписатися на канал) та деструктивні (видалити місію, видалити трек, очистити пакет даних, відписатися від усіх каналів). Адитивні операції виконуються негайно після того, як модель їх обирає — оператор може бачити результат у картці чату та скасувати його подальшим «видали маркер, який я щойно розмістив». Деструктивні операції захищені явним кроком підтвердження.

Дизайн шлюзу підтвердження спрямований на конкретний режим відмови: оператор надсилає неоднозначне повідомлення на кшталт «очисти список місій» або «видали старі контакти», і модель, правильно інтерпретуючи це, генерує пакет викликів delete_mission. Без шлюзу ці видалення виконуються і дані зникають — TAK Server не має вбудованого скасування. Зі шлюзом оператор бачить запит підтвердження: «Я збираюся видалити 7 місій. Ось задіяні записи:» з відрендерованим списком із значками символіки NATO, назвами місій, призначеними позивними та позначками часу останньої зміни. Оператор повинен ввести «підтвердити» або натиснути явну кнопку підтвердження перед тим, як виконання продовжиться.

Відображення символіки NATO MIL-STD-2525/APP-6 у запиті підтвердження є навмисним: оператори розпізнають символи своєї карти швидше, ніж розбирають текст. Підтвердження, що показує значок SFGPU (дружній наземний підрозділ) поруч з «3-й взвод, рота CHARLIE, призначений: BRAVO-7», обробляється швидше і з нижчою частотою помилок, ніж простий текстовий список. TAKpilot відображає відповідні SVG-символи вбудованими у картку підтвердження, використовуючи той самий набір символів, який CloudTAK використовує безпосередньо на карті.

Вибір моделі в різних операційних середовищах

TAKpilot підтримує кілька бекендів моделей, і активна модель налаштовується на сесію. Вибір визначається переважно вимогами до підключення та затримки, а не перевагами щодо можливостей.

Вузли HQ та тилового ешелону з доступом до Інтернету використовують Claude Sonnet через API Anthropic. Sonnet забезпечує найкращий баланс якості міркувань, точності виклику функцій та затримки для оперативного використання — він правильно розпізнає природномовні описи підрозділів до рядків типів CoT у більш ніж 97% випадків при тестуванні і обробляє багатокрокові запити на створення місій з надійним зв'язуванням викликів інструментів. Claude Opus доступний для складної обробки зображень SITREP, де максимальна точність витягування виправдовує вищу затримку та витрати на токени.

Вузли передового краю з переривчастим або відсутнім підключенням до Інтернету використовують локально розгорнуті моделі. Стек крайових моделей TAKpilot підтримує квантований Llama 3 8B (Q4_K_M, приблизно 5 ГБ ваги моделі), Qwen 2.5 7B та Mistral 7B Instruct. Вони працюють на NVIDIA Jetson AGX Orin, тактичних ноутбуках з дискретним GPU або будь-якій системі x86 з принаймні 8 ГБ VRAM. Локальна модель обробляє аналіз природної мови та генерацію викликів функцій; виклики TAK API надходять до локального екземпляру CloudTAK в тому самому сегменті LAN. Повний стек TAKpilot — CloudTAK, TAK Server та локальний інференс — може працювати без будь-яких зовнішніх мережевих залежностей.

Точність крайової моделі для генерації викликів функцій нижча, ніж у Claude Sonnet — приблизно 89% правильного вибору інструменту для простих команд, що знижується до 78% для складних багатокрокових операцій. TAKpilot компенсує це суворішим шаром валідації: якщо локальна модель генерує виклик інструменту з неправильним рядком типу CoT або посиланням на координати за межами діапазону, валідатор відхиляє його і просить модель повторити спробу перед тим, як представити дію оператору. Це виявляє більшість структурних помилок до того, як вони досягнуть шлюзу підтвердження.

Claude Haiku доступний як середній рівень — хмарний, дешевший та з меншою затримкою, ніж Sonnet, але з вищою точністю, ніж локальні моделі — для вузлів з обмеженим, але надійним підключенням до Інтернету (VSAT, тактичний супутниковий зв'язок).

Модель безпеки: ізоляція сесій та атрибуція ідентифікації

Кожна сесія TAKpilot прив'язана до токена автентифікації CloudTAK оператора, який передається до сервісу Node.js TAKpilot при ініціалізації сесії і використовується для всіх наступних викликів TAK API. LLM-агент ніколи не має прямого доступу до бази даних — він генерує виклики функцій, а шар виконання API TAKpilot використовує токен оператора для фактичних HTTP-запитів до CloudTAK. Всі операції обмежені тими самими RBAC-політиками, що застосовуються до прямого використання CloudTAK: оператор, який не може видаляти місії через інтерфейс CloudTAK, не може видаляти місії і через TAKpilot.

Атрибуція оператора зберігається наскрізь через журнал аудиту. Там, де пряма дія в CloudTAK реєструє «користувач: sgt_kovalenko — дія: create_mission», дія, опосередкована TAKpilot, реєструє «користувач: sgt_kovalenko через TAKpilot — дія: create_mission — nlp_input: "створи логістичну місію для сектору BRAVO"». Це зберігає криміналістичну цілісність оперативного журналу аудиту і дозволяє аналізу після дії розрізнити дії за допомогою ШІ від прямих дій через інтерфейс.

Завантажені файли — зображення SITREPів, ескізи, PDF-накладення — обробляються в тимчасовій директорії для кожної сесії і видаляються негайно після того, як конвеєр комп'ютерного зору повертає свій структурований результат. Вміст файлів ніколи не зберігається на диску після сесії обробки, ніколи не зберігається в контексті розмови, надісланому до LLM (до моделі включається лише структурований результат витягування), і ніколи не передається провайдеру моделі як збережений файл. Вихідне зображення бачить модель один раз, а потім зникає.

Ізоляція сесій забезпечується на рівні сервісу Node.js: кожне WebSocket-з'єднання отримує власний контекст сесії, а стан сесії — історія розмови, завантажені файли, відкладені шлюзи підтвердження — зберігається в пам'яті з ключем за ідентифікатором сесії. Немає спільного змінного стану між паралельними сесіями операторів.

Інтеграція з існуючою інфраструктурою TAK

TAKpilot розроблений для додавання можливостей без потреби в змінах інфраструктури. Він працює як сервіс Node.js поряд з існуючим розгортанням CloudTAK і взаємодіє з TAK Server через API-шар CloudTAK — ті самі HTTP-кінцеві точки, які використовує веб-клієнт CloudTAK. Немає окремого плагіна TAK Server, немає додаткового порту для відкриття на брандмауері TAK Server і немає змін у конфігурації федерації TAK Server.

Федерація TAK Server — механізм, за допомогою якого кілька екземплярів TAK Server спільно використовують свою COP через WAN — прозоро працює з TAKpilot, оскільки TAKpilot працює на рівні CloudTAK, а не на рівні TAK Server. Оператор на федеративному вузлі може використовувати TAKpilot для розміщення маркера, який через звичайну федерацію поширюється на всі підключені екземпляри TAK Server. Команда природною мовою «встав маркер на 37U DP 12345 67890» призводить до події CoT, яка проходить той самий шлях федерації, що й будь-який інший маркер, розміщений через інтерфейс CloudTAK.

Автоматизація пакетів даних доступна через бібліотеку інструментів TAKpilot: оператори можуть створювати, заповнювати та розповсюджувати пакети даних через розмовні команди. «Створи пакет даних з усіма місіями в секторі ALPHA і надішли його на канал BRAVO» запускає багатокроковий ланцюг інструментів: перелічити місії з фільтром сектору, створити пакет даних, додати елементи місій, опублікувати на каналі. Кожен крок з'являється як картка виклику інструменту в чаті з часом та статусом.

Управління підписками на канали — підписка та відписка від каналів даних CloudTAK — є одним із найбільш частих оперативних завдань, які виграють від управління природною мовою. Оператори регулярно потребують коригувати свої підписки на канали по мірі розвитку картини місії: «підпиши мене на канал DELTA та відпиши від каналу ECHO» — це двокроковий ланцюг інструментів, що замінює чотири окремі навігаційні дії в інтерфейсі CloudTAK.

Демонстраційні сценарії

Обробка SITREP. Командир взводу отримує рукописний ситуаційний звіт від спостерігача та фотографує його телефоном. Він прикріплює фото до TAKpilot і пише «обробити цей SITREP». Конвеєр комп'ютерного зору TAKpilot витягує шість сутностей: дві позиції ворожих транспортних засобів, один дружній спостережний пункт, один логістичний вузол, рубіжна лінія та межа зони незастосування вогню. Картка підтвердження відображає кожну сутність з символом NATO та запропонованими координатами. Командир взводу коригує одні неправильно прочитані координати, підтверджує решту, і всі шість елементів з'являються на карті CloudTAK протягом восьми секунд після підтвердження. Загальний час від «маю новий SITREP» до «він на карті»: менше дев'яноста секунд, включаючи час на читання та виправлення підтвердження.

Координація CAS з кількома треками. Координатор вогню керує підтримкою з повітря для трьох одночасних зіткнень. Замість перемикання між трьома відкритими вікнами місій в інтерфейсі CloudTAK, він працює через TAKpilot: «встанови статус BRAVO-7 як зайнятий», «покажи всі активні треки в секторі CHARLIE», «яка остання зафіксована позиція EAGLE-1?». Кожна команда виконується менш ніж за дві секунди і результат з'являється в чаті. Очі координатора залишаються на карті, а не на дереві меню. Коли EAGLE-1 завершує свій захід, «закрий місію CAS для EAGLE-1 і встанови статус завершено» запускає шлюз підтвердження — координатор підтверджує, і місія закривається.

Логістичний запит через чат. Заступник командира роти (XO) повинен подати запит на поповнення запасів. Він друкує: «створи логістичну місію для 3-го взводу, пріоритет ТЕРМІНОВО, запит 400 набоїв 5.56, 4 батареї BA-5590, на сітці 37U DP 55555 44444, призначити позивному LOG-1». TAKpilot створює місію з правильною категорією (логістика), пріоритетом, призначеним позивним та маркером місцезнаходження в одному ланцюгу викликів інструментів. XO бачить картку підтвердження, перевіряє деталі, і місія активна на карті та видима для LOG-1 протягом п'яти секунд. Жодного заповнення форм, жодної навігації по дереву категорій, жодного діалогу введення координат.

Пов'язане читання: TAKpilot працює поверх CloudTAK та ширшої екосистеми TAK — дивіться розробку плагінів ATAK для архітектури базової платформи. Для AI-інфраструктури, що забезпечує розгортання крайових моделей, дивіться крайовий AI у військових системах. Щодо закупівель — дивіться екосистему оборони Brave1.