Граф знань для військової розвідки: резолюція сутностей та аналіз зв'язків

Автор: Інженерна команда Corvus Intelligence · Про команду →

24 червня 2026 12 хв читання

Військова розвідка завжди була про зв'язки: який командир контролює який підрозділ, який фінансист фінансує яку осередок, який вузол інфраструктури забезпечує який ланцюг постачання. Це задачі на графах. Дані, що дають на них відповіді — перехоплені комунікації, донесення агентів, метадані супутникових знімків, відкриті реєстраційні дані — надходять із десятка окремих систем збору, кожна з яких по-різному іменує одну й ту саму реальну сутність і зберігає зв'язки у несумісних форматах. Графи знань забезпечують структурний рівень, що об'єднує ці фрагменти в цілісну картину, придатну для запитів. У цій статті розглядається, як графові бази даних і графи знань застосовуються у робочих процесах військової розвідки: від фундаментальних недоліків реляційних підходів, через проектування онтологій відповідно до PMESII, резолюцію сутностей із різних джерел multi-INT, представлення об'єктів STIX, вибір графової бази даних для класифікованих середовищ, шаблони запитів Cypher для аналізу зв'язків і аж до інтеграції з системами C2 та OSINT-конвеєрами.

Чому реляційні бази даних непридатні для аналізу зв'язків у розвідці

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

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

Проблема розрізнення сутностей ускладнює це ще більше. Людина з'являється в перехопленні SIGINT як «Ahmed M.», у донесенні HUMINT — як «Ahmad Mansour», а у фінансовому записі — як «A. Mansouri». У реляційній схемі це три окремі рядки в трьох окремих таблицях, якщо аналітик-людина (або конвеєр дедублікації) явно не пов'язав їх. Без такого зв'язку JOIN, що починається від запису SIGINT, ніколи не перейде до фінансового запису, і мережа, яку бачить аналітик, буде систематично неповною. У реляційних базах даних немає вбудованого механізму для вираження «ці два рядки, мабуть, є однією й тією самою сутністю, з достовірністю 0,85». Ця ймовірність має знаходитися за межами схеми — в логіці застосунку, яка, як правило, є ручною і рідко послідовною.

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

Основи графів знань для військового застосування

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

Для військової розвідки фреймворк PMESII надає природний кістяк онтології. Кожен із шести вимірів — Політичний, Військовий, Економічний, Соціальний, Інфраструктурний, Інформаційний — стає родиною міток вузлів:

Вимір PMESII	Мітки вузлів	Ключові типи ребер
Політичний	Government, Official, PoliticalParty, Faction	CONTROLS, ALLIED_WITH, OPPOSES
Військовий	Unit, Commander, WeaponsSystem, Base	COMMANDS, SUBORDINATE_TO, EQUIPPED_WITH, DEPLOYS_AT
Економічний	Organization, FinancialAccount, SupplyChain, Commodity	FINANCES, TRANSACTS_WITH, SUPPLIES
Соціальний	Person, Group, Community	MEMBER_OF, COMMUNICATES_WITH, RECRUITS
Інфраструктурний	Facility, TransportLink, PowerGrid, NetworkNode	CONNECTS, DEPENDS_ON, OPERATED_BY
Інформаційний	MediaChannel, PsyopActor, NarrativeTheme	AMPLIFIES, TARGETS, DISSEMINATES

Кожен вузол містить обов'язковий набір властивостей: канонічний ідентифікатор, ім'я, мітку класифікації, посилання на джерело та мітку часу створення. Кожне ребро містить: тип, source_ref, достовірність (число від 0 до 1), valid_from (найраніший час спостереження зв'язку), valid_until (null, якщо зв'язок ще активний) та класифікацію. Ці обов'язкові властивості забезпечують аудитоспроможність графа: будь-який виведений зв'язок можна простежити до спостережень, що його підтверджують, разом із метаданими збору та показниками достовірності.

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

Резолюція сутностей із різних джерел multi-INT

Розвідувальні дані збираються з джерел, які ніколи не були розроблені для спільного ідентифікатора сутностей. Система SIGINT ідентифікує особу за номером телефону. Донесення HUMINT називає її в прозовому тексті. Аналітик IMINT позначає транспортний засіб в анотації знімку. База даних відкритих джерел реєструє організацію за її юридичною назвою іноземною мовою. Зведення всього цього в один послідовний граф вимагає резолюції сутностей: визначення для кожної пари вхідних записів, чи посилаються вони на одну й ту саму реальну сутність.

Конвеєр резолюції складається з трьох етапів. Перший — нормалізація: перш ніж можна здійснити будь-яке порівняння, ідентифікатори мають бути приведені до канонічної форми. Номери телефонів нормалізуються до міжнародного формату E.164. Імена транслітеруються до спільного письма (як правило, латинського) за визначеним стандартом транслітерації (BGN/PCGN для слов'янських мов, ALA-LC для арабської) і далі нормалізуються до базової форми, що відкидає звертання та варіації порядку імені. Координати конвертуються в WGS84. Запис, де номер телефону зберігається як «0044-20-7946-0123», і інший, де номер — «+44 20 7946 0123», мають давати однаковий нормалізований ключ ще до будь-якого кроку блокування або порівняння.

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

Третій етап — оцінювання та прийняття рішення. Пари кандидатів отримують вектор схожості за кількома атрибутами: схожість імен (Jaro-Winkler або Jaccard по токенах імені), збіг ідентифікаторів (спільний телефон, IMEI, адреса), географічна близькість і часове спів-виникнення. Логістична регресія або класифікатор на основі градієнтного бустингу видає оцінку достовірності злиття. Пари, що перевищують високий поріг (як правило, 0,90), зливаються автоматично; пари в зоні невизначеності (0,65–0,90) ставляться в чергу на розгляд аналітика; пари нижче нижнього порогу лишаються окремими вузлами.

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

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

Представлення об'єктів STIX у графовому сховищі

STIX (Structured Threat Information eXpression) — стандарт обміну кіберрозвідкою, прийнятий у рамках Five Eyes. Пакет STIX складається зі STIX Domain Objects (SDOs) — сутностей: суб'єктів загроз, кампаній, індикаторів, шкідливого програмного забезпечення, вразливостей, шаблонів атак, інфраструктури — і STIX Relationship Objects (SROs), що виражають спрямовані зв'язки між ними: «Суб'єкт загрози X використовує шкідливе ПЗ Y», «Кампанія A атакує Сектор B». Це нативний граф властивостей. Кожен SDO стає вузлом; кожен SRO стає спрямованим ребром.

Відображення є прямолінійним:

// STIX SDO → Neo4j Node
MERGE (n:StixObject {stix_id: $bundle.id})
SET n.type        = $sdo.type,
    n.name        = $sdo.name,
    n.confidence  = $sdo.confidence,
    n.modified    = datetime($sdo.modified),
    n.revoked     = coalesce($sdo.revoked, false),
    n.labels      = $sdo.labels,
    n.classification = $sdo.object_marking_refs[0]

// STIX SRO → Neo4j Edge
MATCH (src:StixObject {stix_id: $sro.source_ref})
MATCH (tgt:StixObject {stix_id: $sro.target_ref})
MERGE (src)-[r:STIX_REL {stix_id: $sro.id}]->(tgt)
SET r.relationship_type = $sro.relationship_type,
    r.confidence        = $sro.confidence,
    r.valid_from        = datetime($sro.start_time),
    r.valid_until       = datetime($sro.stop_time),
    r.modified          = datetime($sro.modified),
    r.revoked           = coalesce($sro.revoked, false)

Два специфічних ускладнення STIX вимагають явної обробки. По-перше, версіонування: STIX оновлює об'єкт, перевидаючи той самий id з новою міткою часу modified. Наведений вище шаблон MERGE-on-stix_id обробляє це коректно, перезаписуючи властивості на місці. Для робочих процесів, яким потрібно відновити розвідувальну картину такою, якою вона була в конкретний момент — наприклад, під час розбору інциденту після події — необхідний шаблон часового версіонування: замість перезапису створюється нова версія вузла, і версії з'єднуються ребрами HAS_VERSION, де на кожному вузлі версії зберігається мітка часу набрання чинності.

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

STIX також визначає об'єкти Sighting, що фіксують факт спостереження SDO у конкретному контексті. Sighting відображаються у вигляді ребер, що з'єднують спостережуваний об'єкт зі спостерігачем, із властивостями sighting_count і first/last_seen. Це механізм, що пов'язує абстрактну розвідку про загрози — «ця родина шкідливого ПЗ» — із конкретним операційним спостереженням: «це шкідливе ПЗ було помічено в цій мережі в цей час».

Вибір графової бази даних для військових середовищ

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

Рушій	Ізольована мережа	Мова запитів	Нативні алгоритми GDS	Примітки
Neo4j Enterprise	Так (офлайн-ліцензія)	Cypher / openCypher	Бібліотека GDS: PageRank, Louvain, Dijkstra, WCC	Більшість аналітичних інструментів орієнтована на Cypher; сильний трекрекорд акредитації в розгортаннях Five Eyes
TigerGraph	Так (пакет on-prem)	GSQL	Вбудовані: центральність, спільноти, шляхи	Вищий пропускна здатність для пакетної аналітики; GSQL має крутішу криву навчання для аналітиків
Amazon Neptune	Ні (хмарний сервіс)	openCypher / Gremlin / SPARQL	Neptune ML для графових нейронних мереж	Підходить лише для хмарних орендованих середовищ TS/SCI; не для справжньої ізольованої мережі
JanusGraph	Так (відкритий код)	Gremlin	Через бекенд Spark/Hadoop	Повністю відкритий код; працює поверх HBase, Cassandra або RocksDB; найкраще підходить для периферійних вузлів із вбудованим сховищем

Для передових або периферійних вузлів розвідки — команда з ноутбуком і тактичною мережею — вбудовані графові сховища на базі RocksDB (JanusGraph + EmbeddedGraph) або вбудований режим Neo4j пропонують мінімальний слід. Для гарнізонних аналітичних мереж із одночасним доступом кількох аналітиків кластерне розгортання Neo4j Enterprise або розподілена архітектура TigerGraph забезпечують необхідну пропускну здатність для паралельних сесій аналізу зв'язків. Amazon Neptune підходить лише в тому випадку, якщо класифікований анклав вже розміщений у суверенній хмарній оренді на необхідному рівні класифікації.

Критичним операційним аспектом є рівень виконання контролю доступу з кількома рівнями безпеки (MLS). Сама графова база даних рідко підтримує MLS: вона зберігає дані та виконує запити без природного розуміння міток класифікації. Рівень виконання розташований у шлюзі запитів — компоненті проміжного програмного забезпечення, що переписує кожен вхідний запит Cypher, додаючи умову WHERE, яка фільтрує за авторизованим набором класифікацій запитуваного користувача. Це слід реалізовувати обережно: користувач із допуском SECRET не повинен мати можливості встановити існування ребер TOP SECRET через різницю в часі відповіді або повідомлення про помилки, навіть якщо він не може бачити вміст ребра.

Шаблони запитів для аналізу зв'язків

Аналіз зв'язків у Cypher зводиться до невеликого словника шаблонів, що компонуються в складні аналітичні запитання. Наведені приклади розраховані на Neo4j і бібліотеку GDS, але шаблони транслюються в GSQL або Gremlin з незначними змінами синтаксису.

Найкоротший шлях між двома сутностями інтересу:

// Знайти найкоротший шлях, фільтруючи за ребрами з високою достовірністю та без відкликання
MATCH (a:Entity {id: $seedA}),
      (b:Entity {id: $seedB}),
      p = shortestPath((a)-[*1..6]-(b))
WHERE ALL(r IN relationships(p)
      WHERE r.confidence >= 0.6
        AND NOT coalesce(r.revoked, false)
        AND (r.valid_until IS NULL OR r.valid_until > datetime()))
RETURN p, length(p) AS hops
ORDER BY hops ASC

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

// 3-кроке оточення, активне протягом 30-денного операційного вікна
MATCH (seed:Entity {id: $seedId})-[r*1..3]-(neighbor)
WHERE ALL(rel IN r
      WHERE rel.confidence >= 0.5
        AND rel.valid_from <= $windowEnd
        AND (rel.valid_until IS NULL OR rel.valid_until >= $windowStart))
RETURN DISTINCT neighbor, labels(neighbor) AS types
LIMIT 500

Виявлення спільнот за допомогою Louvain (запуск на проекції графа в пам'яті):

// Проектувати зважений за достовірністю підграф, запустити Louvain, записати ідентифікатори спільнот
CALL gds.graph.project(
  'intel-graph',
  ['Entity'],
  {COMMUNICATES_WITH: {properties: ['confidence']}})

CALL gds.louvain.write('intel-graph', {
  writeProperty: 'communityId',
  relationshipWeightProperty: 'confidence'
}) YIELD communityCount, modularity

// Потім вивести однодумців із тієї самої спільноти початкового вузла
MATCH (seed:Entity {id: $seedId})
MATCH (peer:Entity {communityId: seed.communityId})
WHERE peer.id <> $seedId
RETURN peer ORDER BY peer.degreeCentrality DESC LIMIT 50

Часовий аналіз зв'язків — ритм активності з плином часу:

// Підрахунок активацій ребер по календарних тижнях для аналізу часових шаблонів
MATCH (a:Entity {id: $seedId})-[r:COMMUNICATES_WITH]-()
WHERE r.valid_from >= $rangeStart AND r.valid_from <= $rangeEnd
WITH r,
     date.truncate('week', r.valid_from) AS week
RETURN week,
       count(r) AS contact_count,
       avg(r.confidence) AS avg_confidence
ORDER BY week ASC

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

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

Інтеграція графів знань із системами C2 та OSINT-конвеєрами

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

Надходження CTI-фідів (STIX/TAXII). Клієнт TAXII опитує зареєстровані кінцеві точки колекцій — платформи обміну CTI союзників, національні фіди розвідки про загрози — і обробляє вхідні пакети STIX через конвеєр SDO-до-вузла / SRO-до-ребра, описаний вище. Обробка пакетів є ідемпотентною: MERGE по stix_id гарантує, що повторно доставлений об'єкт оновлює властивості, а не створює дублікат вузла. Нові об'єкти проходять резолюцію сутностей по відношенню до наявного графа перед фіксацією; якщо новий STIX ThreatActor збігається з наявним вузлом Person, що не є STIX, через імовірнісну резолюцію ідентичності, обидва зливаються й усі ребра з обох записів тепер доступні для обходу з канонічного вузла.

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

Надходження треків SIGINT. Спостереження SIGINT — зв'язок між двома кінцевими точками в конкретний час, пристрій, що з'явився в конкретному місці — надходять у вигляді потокового фіду. Кожне спостереження створює або оновлює ребро в графі: ребро COMMUNICATES_WITH між двома вузлами особи або пристрою, або ребро OBSERVED_AT між пристроєм і місцем розташування. Поле valid_from ребра — це мітка часу спостереження; valid_until дорівнює null, якщо фід SIGINT явно не закриває спостереження. Потокове надходження великих обсягів вимагає інгестора з чергою на основі Kafka (або аналогу), що буферизує спостереження і групує їх у пакетні операції запису в граф із такою швидкістю, яку база даних може поглинути, не блокуючи інтерактивні запити.

Два кінцеві пункти споживання — робоча станція аналітика і загальна оперативна картина (COP) системи C2.

Робоча станція аналітика надає інтерфейс аналізу зв'язків, де аналітик задає початкову сутність, вибирає типи відносин і пороги достовірності та розширює обмежене оточення. Результат відображається як граф із компонуванням за принципом сил із достовірністю, закодованою як прозорість ребра, і членством у спільноті, закодованим як колір вузла. Оцінки центральності визначають розмір вузла. Аналітик ніколи не бачить весь граф — лише обмежений, відфільтрований, отриманий запитом підграф, що відповідає на конкретне питання. Хороший інтерфейс відображає шаблон Cypher на боковій панелі, щоб аналітик точно розумів, що саме було запитано, і міг уточнити запит.

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

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

Додайте розвідку про зв'язки до вашої оперативної картини

Corvus HEAD поєднує розвідку з різних джерел у граф знань, придатний для запитів — резолюція сутностей, аналіз зв'язків і мережева візуалізація, інтегрована з C2, створена для аналітиків, яким потрібні аудитоспроможні, зважені за достовірністю відповіді, а не клубки без структури.

Дізнатися про Corvus HEAD → Замовити брифінг

Цей аналіз підготований інженерами Corvus Intelligence, які розробляють критично важливі розвідувальні та інтеграційні системи для оборонних і державних організацій. Дізнатися про нашу команду →

Часті запитання

Чому вибухи JOIN у реляційних базах робить їх непридатними для аналізу зв'язків у розвідці на великій глибині?

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

Яка різниця між графом властивостей і графом знань RDF/OWL у військовому контексті?

Граф властивостей зберігає вузли та ребра з типізованими мітками та довільними властивостями «ключ-значення на обох. Він гнучкий за схемою та оптимізований для запитів обходу. Граф знань RDF моделює все як трійки суб'єкт-предикат-об'єкт; OWL додає онтологічний рівень із формальною семантикою, що підтримує виведення. Для військової розвідки графи властивостей є більш операційно практичними: вони природно обробляють властивості провенанцу та достовірності й інтегруються з інструментами Cypher, якими вже користуються аналітики. RDF/OWL кращий там, де важлива формальна інтероперабельність стандартів, наприклад при інтеграції контенту STIX на семантичному рівні або федеруванні з базами знань союзників за протоколами пов'язаних даних.

Чим розрізнення сутностей відрізняється від резолюції сутностей у розвідувальному контексті?

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

Як виглядає STIX Relationship Object у вигляді ребра графа в neo4j?

STIX SRO перетворюється на спрямоване ребро, тип якого — рядок relationship_type (наприклад, «uses», «targets»). Власний stix_id, confidence, created і modified SRO зберігаються як властивості ребра. source_ref і target_ref розрізняються за властивістю stix_id наявних вузлів. Часові поля (valid_from, valid_until) індексуються як властивості ребра, щоб запити Cypher із часовими вікнами могли фільтрувати зв'язки, активні протягом конкретного операційного вікна. Відкликані SRO встановлюють revoked: true на ребрі й виключаються з обходів фільтром WHERE NOT за замовчуванням, але зберігаються для аудиту.

Як обробляти версіоновані об'єкти STIX у графовому сховищі?

Версіонування STIX використовує той самий id з новою міткою часу modified. Застосовуються дві стратегії. Снепшот-заміна зберігає лише останню версію кожного вузла — просто, але втрачає історію. Часове версіонування вузлів створює новий вузол на кожну мітку часу modified і пов'язує версії ребрами HAS_VERSION, дозволяючи запитам подорожі в часі відновити будь-яку минулу картину розвідки. Для операційної розвідки снепшот-заміна достатня; для аналітичних процесів, яким потрібно простежити еволюцію картини загрози до прийняття рішення, необхідне часове версіонування. Обидві стратегії мають позначати відкликані об'єкти прапором revoked: true і пригнічувати їх з обходів без видалення, зберігаючи аудитний слід.

Що таке проблема супервузла в графах військової розвідки?

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

Яка графова база даних найкраще підходить для ізольованих розгортань військової розвідки?

Ізольовані розгортання вимагають графового рушія без мережевих перевірок ліцензій. Neo4j Enterprise з офлайн-ліцензією є найбільш сумісним із аналітичними інструментами вибором. TigerGraph підтримує пакетне on-prem ліцензування. JanusGraph повністю відкритий код і працює поверх вбудованого RocksDB — ідеально для периферійних розгортань. Amazon Neptune є хмарним сервісом і не придатний для справжньої ізольованої мережі. Для передових периферійних вузлів JanusGraph із RocksDB має мінімальний слід. Для гарнізонних аналітичних мереж кластеризація Neo4j Enterprise або розподілений TigerGraph забезпечують необхідну паралельність для кількох аналітиків.

Який шаблон Cypher знаходить найкоротший розвідувальний шлях між двома сутностями?

Канонічний шаблон: MATCH (a:Entity {id:$seedA}),(b:Entity {id:$seedB}), p=shortestPath((a)-[*1..6]-(b)) WHERE ALL(r IN relationships(p) WHERE r.confidence>=0.6 AND NOT r.revoked AND (r.valid_until IS NULL OR r.valid_until>datetime())) RETURN p, length(p) AS hops. Обмеження [*1..6] запобігає нескінченним обходам. Для найкоротших шляхів, зважених за достовірністю, процедура GDS Dijkstra з ваговою властивістю (1-confidence) надає перевагу ребрам із високою достовірністю, присвоюючи їм нижчу вартість.

Як виявлення спільнот допомагає аналітикам розставляти пріоритети цілей?

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

Як узгоджуються CTI-фіди і потоки SIGINT у реальному часі в живому графі знань?

CTI-фіди надходять як пакети STIX, що обробляються в пакетному режимі; SIGINT надходить як безперервний потік. Їх узгоджує двоетапний конвеєр. Пакетний етап обробляє пакети STIX: MERGE по stix_id створює або оновлює вузли, SRO стають ребрами. Потоковий етап обробляє спостереження SIGINT через інгестор на основі Kafka: кожне спостереження проходить резолюцію сутностей майже в реальному часі й створює ребро з часовими межами. Обидва етапи записують в один граф властивостей, тому запити Cypher бачать єдину картину. Часові властивості ребер графа ізолюють найновіше потокове вікно без повторного запуску пакетної історії.