Архітектура Narrative Shield: реактивне виявлення, проактивний вплив та оцінка ефектів

Narrative Shield — це платформа підтримки прийняття рішень StratCom компанії Corvus Intelligence з посиленням ШІ: єдина консоль для операцій у когнітивному домені, що охоплює повний цикл ефектів стратегічних комунікацій. На відміну від точкових інструментів, що вирішують лише виявлення або лише генерацію контенту, Narrative Shield організований навколо трьох взаємопов'язаних операційних потоків: реактивний потік для постійного моніторингу загроз, проактивний потік для запланованих операцій впливу та потік оцінювання для після-операційної аналітики. У цій статті розглядається технічна архітектура кожного потоку та рішення щодо проектування серверної та клієнтської частин, що їх підтримують.

Платформа побудована на .NET 8 / ASP.NET Core для серверного API, React 18 з TypeScript і Vite на клієнтській стороні, та інтегрує Anthropic Claude API для всіх завдань розуміння з посиленням ШІ. Розгортання базується на Docker з REST API відповідно до OpenAPI 3, а система інтегрується з OpenTAKServer для польової доставки затверджених продуктів StratCom.

Реактивний потік: конвеєр постійного моніторингу наративів

Реактивний потік є безперервним моніторинговим хребтом Narrative Shield. Він працює як постійна фонова служба в серверній частині .NET, опитуючи налаштовані джерела сигналів із настроюваним інтервалом (за замовчуванням: 5 хвилин) і передаючи кожен отриманий сигнал через багатоетапний конвеєр обробки, перш ніж виявлені кваліфіковані події з'являться в черзі операторів.

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

Алгоритм 5-факторного оцінювання серйозності

Оцінювання серйозності є основним кількісним кроком у реактивному потоці. Кожен виявлений наратив оцінюється за п'ятьма незалежними вимірами:

Охоплення — оцінювана аудиторія, що зазнала впливу наративу на момент виявлення, визначається з кількості підписників облікових записів, крос-платформного дублювання та оціненого органічного коефіцієнта підсилення. Охоплення логарифмічно нормалізується, щоб запобігти домінуванню облікових записів з великою кількістю підписників у всіх вимірах.

Швидкість — темп поширення, виміряний як градієнт охоплення за попереднє 6-годинне вікно спостереження. Наратив, що подвоїв свою аудиторію за дві години, отримує вищий бал за швидкістю, ніж той, що досяг тієї ж абсолютної аудиторії за 48 годин. Швидкість є найнадійнішим сигналом раннього попередження про скоординовану неавтентичну поведінку.

Полярність тональності — ступінь ворожості або шкоди, спрямованої проти моніторингового суб'єкта, оцінюється Claude API за шкалою від -1,0 до +1,0, з величиною полярності, відображеною до 0–100 для внеску в серйозність. Підказка API включає контекст суб'єкта, щоб неоднозначна політична мова оцінювалася відносно конкретного моніторингового об'єкта, а не узагальнено.

Відповідність цільовій аудиторії — наскільки точно спостережуваний розподіл наративу збігається з демографічними та психографічними профілями визначених пріоритетних аудиторій моніторингового суб'єкта. Цей фактор використовує карти аудиторних сегментів, налаштовані на панелі Картографування аудиторії, та перехресно посилається на дані географічного розподілу з рівня отримання даних.

Довіра до джерела — комплексна оцінка авторитетності першоджерел та топових підсилювальних облікових записів, що береться з Реєстру джерел, підтримуваного операторами та безперервно оновлюваного за поведінковими сигналами. Облікові записи з усталеною історією скоординованої неавтентичної поведінки отримують негативні корекції довіри.

П'ять вимірних балів об'єднуються в єдиний індекс серйозності від 0 до 100 за допомогою ваг, що налаштовуються для кожної теми. За замовчуванням ваги рівні (0,2 для кожного фактора). Адміністратори теми можуть регулювати ваги через панель Конфігурація оцінювання; тема захисту особового складу, наприклад, може збільшити вагу відповідності цільовій аудиторії та довіри до джерела, тоді як тема наративу стратегічного рівня може збільшити вагу охоплення та швидкості.

Побудова графа ланцюга поширення за допомогою Cytoscape.js

Як тільки наратив перевищує поріг серйозності, реактивний потік будує граф ланцюга поширення для візуалізації того, як контент поширювався від першоджерел через мережі підсилювачів до аудиторій. Граф відображається на клієнтській стороні за допомогою Cytoscape.js, обраного за продуктивність при роботі з великими розрідженими графами та підтримку кастомних алгоритмів компонування, придатних для візуалізації спрямованих інформаційних потоків.

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

Отриманий граф виконує дві операційні функції. Для реактивного потоку він допомагає операторам ідентифікувати топологію мережі виявленої кампанії — чи контент походив від невеликого скоординованого кластера або виник органічно, та які вузли підсилення є структурно критичними для ланцюга поширення. Для потоку оцінювання та ж структура графа стає основою для вимірювання того, чи дійсно протинаративні дії порушили поширення, шляхом порівняння метрик топології графа до та після дії.

Генерація Курсу дій через Claude API

Для виявлень, що перевищують поріг сповіщення, реактивний потік автоматично генерує три структуровані Курси дій (КД) за допомогою Claude API. Кожен КД є структурованим об'єктом, що містить: рекомендований тип дії (публікація протинаративу, виклик атрибуції джерела, повідомлення про зловживання платформою, залучення ключових лідерів, мовчання/очікування), короткий обґрунтування з явним ланцюгом міркувань, прогнозовану контрреакцію з боку противника, оцінку ризику ескалації та оцінку ризику атрибуції там, де це застосовно.

Генерація трьох КД замість однієї рекомендації є навмисним рішенням щодо дизайну: воно зберігає свободу дій оператора, представляючи простір рішень, а не звужуючи його до єдиної рекомендації ШІ. Сліди міркувань відображаються в операторському інтерфейсі поруч з кожним КД, а не приховані за результатом. Оператори можуть розгорнути слід, щоб побачити ланцюг думок Claude API перед прийняттям або відхиленням курсу дій.

Проактивний потік: картографування аудиторних сегментів та генерація кампаній

Якщо реактивний потік реагує на виявлені загрози, проактивний потік ініціюється оператором: за наявності визначеної комунікаційної мети він генерує структурований план кампанії з кількома варіантами та прогнозованими когнітивними ефектами. Проактивний потік підходить для запланованих інформаційних заходів — підтримки публічного релізу, попереднього розміщення протинаративів перед очікуваною операцією противника або координації союзницьких повідомлень між кількома урядовими каналами.

Проактивний потік починається з картографування аудиторних сегментів. Оператори визначають цільові сегменти за допомогою геопросторового інтерфейсу Leaflet / OpenStreetMap — малюючи географічні межі на карті, обираючи застосовні демографічні та психографічні профілі з бібліотеки сегментів і позначаючи атрибути мовного та культурного контексту. Визначення сегмента визначає як генерацію кампанії, так і подальші кроки адаптації контенту.

Генерація варіантів кампанії виконується Claude API за структурованим шаблоном підказки, що включає комунікаційну мету, визначений аудиторний сегмент, поточне наративне середовище (витягнуте з активних виявлень реактивного потоку для відповідних тем спостереження) та будь-які зазначені оператором обмеження (обмеження контенту, затверджені теми повідомлень, заборонені твердження). API генерує три варіанти кампанії, кожен з окремим основним формулюванням, набором допоміжних тез та прогнозованими когнітивними ефектами, деталізованими за підсегментами аудиторії.

Модель прогнозованих когнітивних ефектів спирається на профілі аудиторних сегментів для оцінки того, як різні формулювання, ймовірно, сприйматимуться різними підпопуляціями — не як точна прогностична модель, а як структурований результат міркувань, який оператори можуть оцінювати та досліджувати. Прогнози чітко позначені як оцінки, згенеровані ШІ, а не емпіричні прогнози.

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

Потік оцінювання: кореляція залученості та після-операційна аналітика

Потік оцінювання замикає цикл ефектів, вимірюючи, чи дійсно дії StratCom досягли своїх запланованих когнітивних ефектів. Це компонент, що найчастіше відсутній в інструментах інформаційних операцій — платформи, що генерують контент, рідко надають строгі механізми для вимірювання того, чого цей контент досяг.

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

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

Дизайн серверного API на .NET 8

Серверна частина організована як Web API ASP.NET Core з модульною сервісною архітектурою. Три операційні потоки реалізовані як незалежні фонові служби, зареєстровані у генеричному хості .NET, що спільно використовують загальний рівень доступу до даних, але працюють на окремих чергах і сховищах стану. Це розділення означає, що затримка або збій в генерації кампанії проактивного потоку не блокує конвеєр виявлення реактивного потоку.

REST API відповідає OpenAPI 3 та документований через Swashbuckle. Кожна кінцева точка є типізованою наскрізно — моделі запитів і відповідей є спільними між серверною частиною та клієнтською частиною на React через згенерований TypeScript клієнт, що усуває клас інтеграційних помилок, спричинених дрейфом схем між сервером API та споживачем. API автентифікований через токени JWT bearer з контролем доступу на основі ролей, що застосовується на рівні контролера.

Журнал рішень — незмінний запис кожного виведення, згенерованого ШІ, дії оператора, схвалення та поширення — реалізований як таблиця лише для додавання. Операції запису до журналу рішень використовують оптимістичну конкурентність для запобігання дублювання записів при конкурентних записах, а читання розбиті на сторінки та індексовані за темою спостереження, оператором та міткою часу для ефективного після-операційного отримання даних.

Клієнтська частина на React 18 з TypeScript

Клієнтська частина є односторінковим застосунком на React 18, побудованим з Vite і TypeScript, стилізованим за допомогою Tailwind CSS. Управління станом використовує React Query для серверного стану (черги виявлень, дані оцінювання, варіанти кампаній) та контекст React для стану інтерфейсу (вибрана тема спостереження, активна панель). Архітектура уникає глобального клієнтського сховища для серверних даних — поведінка інвалідації кешу та фонового оновлення React Query краще підходить для природи реактивного потоку з інтенсивним опитуванням, ніж ручне сховище Zustand або Redux.

Відображення графів Cytoscape.js ізольовано в окремому компоненті з кастомною обгорткою React, що керує ініціалізацією графа, оновленнями даних та перерахунком компонування поза циклом рендерингу React — Cytoscape.js безпосередньо мутує елемент canvas, і узгодження цього з віртуальним DOM React вимагає ретельного управління межами. Перерахунок компонування виконується із затримкою і поза основним потоком там, де підтримка браузера це дозволяє.

Геопросторовий компонент Leaflet дотримується того ж патерну: ініціалізується одноразово, оновлюється безпосередньо через refs та обгорнутий у компонент React, що надає декларативний інтерфейс для встановлення відображуваних меж сегментів та накладання теплових карт розподілу наративів.

Інтеграція з OpenTAKServer для польової доставки

Затверджені продукти StratCom доставляються польовим підрозділам через інтеграцію з OpenTAKServer. Коли оператор затверджує дію поширення, серверна частина надсилає місійний пакет CoT (Cursor on Target) до налаштованого екземпляра OpenTAKServer через його REST API. Польові підрозділи, що використовують TAK-сумісні застосунки, отримують пакет на своїх пристроях без потреби в окремому каналі зв'язку або ручній ретрансляції від команди StratCom.

Інтеграція налаштовується на панелі адміністрування Narrative Shield: оператори вказують кінцеву точку OpenTAKServer, облікові дані автентифікації та групи TAK, що мають отримувати пакети для кожної теми спостереження. Вміст пакета відформатований як структурований текст, придатний для польового відображення — не сирі розвідувальні звіти, а затверджені оператором тези та оперативне зведення у форматі, відповідному для тактичної аудиторії.

Для більш широкого обговорення того, як оборонне програмне забезпечення обробляє обмеження архітектури місійно-критичних систем, включаючи відмовостійкість та роботу в деградованому режимі, дивіться наш огляд архітектури. Стаття про аспекти CI/CD конвеєра для оборонного програмного забезпечення охоплює дисципліну збірки та розгортання, що лежить в основі процесу випуску Narrative Shield.

Як налаштувати нову тему спостереження за наративами в Narrative Shield

Наступні кроки описують повну конфігурацію нової теми спостереження — від початкового визначення таксономії до після-операційного огляду після першого оперативного періоду.

Крок 1: Визначте тему спостереження та таксономію ключових слів. Перейдіть до Адміністрування > Теми спостереження та створіть нову тему. Введіть описову мітку та побудуйте таксономію ключових слів, що охоплює основні терміни, пов'язані фрази та відомі гештеги противника. Таксономія підтримує булеві оператори та зіставлення з символами підстановки. Починайте широко та звужуйте на основі перших 48 годин оцінених результатів.

Крок 2: Налаштуйте ваги оцінювання серйозності для цієї теми. Відкрийте панель Конфігурація оцінювання теми. Відрегулюйте повзунки ваги п'яти факторів відповідно до оперативних пріоритетів. Зміни ваг набирають чинності при наступних циклах оцінювання і не перераховують ретроспективно попередні виявлення.

Крок 3: Встановіть поріг серйозності для сповіщення оператора. У панелі Сповіщення встановіть поріг індексу серйозності, перевищення якого призводить до негайного сповіщення оператора. Поріг за замовчуванням 65/100 підходить для більшості тем. Налаштуйте канал сповіщень та призначення чергового офіцера для цієї теми спостереження.

Крок 4: Заповніть граф поширення відомими вихідними обліковими записами. Додайте відомі облікові записи противника, мережі підсилювачів та кластери координації до Реєстру джерел теми. Ці вузли-насіння ініціалізують граф поширення Cytoscape.js при появі нового виявлення. Реєстр приймає прямі ідентифікатори облікових записів і може імпортуватися пакетом через CSV.

Крок 5: Визначте сегмент цільової аудиторії для цієї теми. Відкрийте панель Картографування аудиторії, намалюйте географічну межу на карті Leaflet, виберіть застосовні демографічні та психографічні профілі та прив'яжіть сегмент до теми спостереження. Це визначення сегмента використовується як реактивним потоком (оцінка відповідності цільовій аудиторії), так і проактивним потоком (генерація варіантів кампанії).

Крок 6: Активуйте тему та перевірте за допомогою тестового виявлення. Встановіть статус теми як Активна. Скористайтеся інструментом Тестове впорскування для надсилання синтетичного сигналу, що відповідає вашій таксономії ключових слів, переконайтеся, що граф поширення ініціалізується правильно та що спрацьовує сповіщення, якщо синтетичний індекс серйозності перевищує налаштований поріг.

Крок 7: Перегляньте після-операційну аналітику після першого оперативного періоду. Після 24–72 годин реальної роботи відкрийте панель Оцінювання для цієї теми. Перегляньте діаграми кореляції залученості, перевірте показники хибно-позитивних результатів і відповідно відрегулюйте таксономію або пороги. Експортуйте після-операційний звіт та поверніть висновки до конфігурації теми спостереження для підвищення точності майбутнього оцінювання.

Поширені запитання

+У чому різниця між реактивним та проактивним потоками Narrative Shield?

Реактивний потік — це постійний моніторинг: він отримує сигнали, оцінює виявлені наративи за 5-факторною моделлю серйозності, будує графи ланцюга поширення та генерує структуровані Курси дій для розгляду оператором-людиною. Проактивний потік ініціюється оператором: за наявності комунікаційної мети він геопросторово картографує цільові аудиторні сегменти, генерує кілька варіантів кампаній з прогнозованими когнітивними ефектами та створює адаптований до аудиторії чорновий контент — ще до того, як будь-яка загроза матеріалізується.

+Як працює алгоритм 5-факторного оцінювання серйозності?

Кожен виявлений наратив оцінюється за п'ятьма незалежними вимірами: охоплення (оцінювана аудиторія, що зазнала впливу), швидкість (темп поширення по платформах і в часі), полярність тональності (ступінь ворожості або шкоди для моніторингового суб'єкта), відповідність цільовій аудиторії (наскільки наратив збігається з відомими цільовими популяціями противника) та довіра до джерела (авторитетність першоджерел і підсилювачів). П'ять вимірних балів зважуються та об'єднуються в єдиний індекс серйозності від 0 до 100. Ваги налаштовуються для кожної теми спостереження відповідно до оперативних пріоритетів.

+Чи замінює Narrative Shield офіцерів StratCom?

Ні. Narrative Shield розроблено з урахуванням людського нагляду на кожній точці прийняття рішень. Платформа генерує Курси дій та чорновий контент, але жоден результат не поширюється без схвалення оператора. Кожен результат, згенерований ШІ, супроводжується видимим слідом міркувань, щоб оператори могли оцінити базову логіку, а не лише висновок. Мітки часу рішень та записи схвалень записуються до незмінного журналу аудиту.

+Як працює інтеграція з OpenTAKServer?

Narrative Shield надає webhook-кінцеву точку, яка надсилає затверджені продукти StratCom — зведення ситуацій, тези протинаративів та оновлення вказівок — до екземпляра OpenTAKServer у вигляді місійних пакетів CoT (Cursor on Target). Польові підрозділи отримують ці продукти на своїх пристроях TAK без потреби в окремому каналі зв'язку або ручній ретрансляції. Інтеграція використовує стандартний REST API OpenTAKServer та налаштовується через панель адміністрування Narrative Shield.

+Якій системі відповідності дотримується Narrative Shield щодо використання ШІ?

Narrative Shield розроблено відповідно до принципів ШІ NATO: людський контроль на кожній точці прийняття рішень, прозорість міркувань (усі результати Claude API включають видимі сліди ланцюга думок), надійність через детерміновані конвеєри оцінювання, що не змінюють результат для однакового вхідного сигналу, безпека через журналювання аудиту всіх дій і схвалень та підзвітність через повний провенанс рішень від отримання сигналу до затвердженого поширення.

Додаткове читання: Фундаментальні архітектурні концепції, що лежать в основі серверної частини Narrative Shield, розглядаються в статті Архітектура місійно-критичного програмного забезпечення для оборони. Проектування та розгортання конвеєра для цього класу платформ розглядається в статті Побудова захищеного CI/CD конвеєра для оборонного програмного забезпечення. Для контексту щодо ширших міркувань щодо вибору постачальника при закупівлі платформ StratCom або когнітивного захисту дивіться Як обрати постачальника програмного забезпечення для оборони.