
# Динамічне збагачення графу знань для контекстуалізації опитувальників у реальному часі

## Вступ

Опитувальники безпеки та аудити комплаєнсу стали вузьким місцем у швидко зростаючих SaaS‑компаніях. Команди витрачають безліч годин на пошук потрібного пункту політики, збір доказів із сховищ документів та переписування однієї і тієї ж відповіді для кожного нового запиту від постачальника. Хоча великі мовні моделі (LLM) можуть генерувати чернетки відповідей, вони часто пропускають **регуляторні нюанси**, які змінюються щодня — нові рекомендації Європейської ради з захисту даних (EDPB), оновлений набір контролів [NIST CSF](https://www.nist.gov/cyberframework) (наприклад, NIST SP 800‑53) або щойно опубліковану поправку до [ISO 27001](https://www.iso.org/standard/27001).

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

У цій статті ми розглянемо:

1. Чому динамічний граф знань — це відсутнє зв’язкове звено між чернетками, створеними ШІ, і готовими до аудиту відповідями.  
2. Архітектуру, потік даних та основні компоненти DKGEE.  
3. Як інтегрувати движок у існуючі шари управління завданнями та коментарями Procurize.  
4. Реальний кейс‑стаді з вимірюваним ROI.  
5. Практичні рекомендації для команд, які хочуть впровадити движок вже сьогодні.

---

## 1. Чому статична база знань не справляється

| Проблема | Статична база знань | Динамічний граф знань |
|----------|---------------------|------------------------|
| **Оновлення регуляторних актів** | Потрібен ручний імпорт; затримка оновлень — тижні. | Автоматичне споживання потоків; оновлення за хвилини. |
| **Крос‑фреймворк маппінг** | Ручні таблиці маппінгу швидко втрачають актуальність. | Графові зв’язки залишаються консистентними при появі нових вузлів. |
| **Отримання контекстуальних доказів** | Пошук за ключовими словами повертає шум. | Семантичне обходження графу дає точні докази з відстежуваною провенансією. |
| **Аудиторська прозорість** | Немає автоматичного журналу змін. | Вбудована версіонування та лінійність для кожного вузла. |

Статичне сховище може зберігати політики, але воно не може *зрозуміти*, як новий регламент — наприклад, стаття GDPR — змінює інтерпретацію існуючого контролю ISO. DKGEE вирішує це, **моделюючи регуляторну екосистему у вигляді графу**, де кожен вузол представляє пункт, рекомендацію або артефакт доказу, а ребра кодують взаємовідносини типу *«вимагає»*, *«переписує»* або *«відображає»*. Коли надходить новий регламент, граф **інкрементально збагачується**, зберігаючи історію і роблячи вплив на існуючі відповіді миттєво видимим.

---

## 2. Огляд архітектури

Нижче — діаграма Mermaid, що візуалізує конвеєр DKGEE.

```mermaid
graph TD
    A["Збирачі регуляторних потоків"] --> B["Служба інжестії"]
    B --> C["Нормалізація та видобування сутностей"]
    C --> D["Оновлювач графу"]
    D --> E["Динамічний граф знань"]
    E --> F["Служба контекстуального отримання"]
    F --> G["UI Procurize (будівельник анкет)"]
    G --> H["Генератор чернетки LLM"]
    H --> I["Human‑in‑the‑Loop перевірка"]
    I --> J["Зберігання фінальної відповіді"]
    J --> K["Аудиторський журнал та версіонування"]
```

### 2.1 Основні компоненти

1. **Збирачі регуляторних потоків** – коннектори до офіційних джерел (Офіційний вісник ЄС, RSS NIST, оновлення ISO), спільнотних потоків (правила в GitHub) та змін політик постачальників.  
2. **Служба інжестії** – легковаговий мікросервіс на **Go**, який валідовує payload, виявляє дублікати та надсилає сирі дані в Kafka‑топік.  
3. **Нормалізація та видобування сутностей** – використовує **spaCy** і моделі **Hugging Face**, налаштовані на юридичний текст, щоб витягти пункти, визначення та посилання.  
4. **Оновлювач графу** – виконує **Cypher**‑запити проти **Neo4j**, створюючи або оновлюючи вузли та ребра, зберігаючи історію версій.  
5. **Динамічний граф знань** – зберігає всю регуляторну екосистему. Кожен вузол має властивості: `id`, `source`, `text`, `effectiveDate`, `version`, `confidenceScore`.  
6. **Служба контекстуального отримання** – сервіс типу **RAG**, що отримує запит до анкети, виконує **семантичне обходження графу**, ранжує кандидати‑докази і повертає JSON‑payload.  
7. **Інтеграція UI Procurize** – фронтенд споживає payload і відображає пропозиції безпосередньо під кожним запитанням, з інлайн‑коментарями та кнопкою «Застосувати до відповіді».  
8. **Генератор чернетки LLM** – модель **GPT‑4‑Turbo**, яка використовує отримані докази як підґрунтя для створення першої чернетки відповіді.  
9. **Human‑in‑the‑Loop перевірка** – рецензенти можуть приймати, редагувати або відхиляти чернетки. Усі дії журналюються для аудиту.  
10. **Зберігання фінальної відповіді та аудит** – відповіді зберігаються в незмінному реєстрі (наприклад, **AWS QLDB**) з криптографічним хешем, що вказує на точний знімок графу, використаний під час генерації.

---

## 3. Поток даних – від потоку до відповіді

1. **Надходження потоку** – опубліковано нову версію NIST SP 800‑53. Збирач потоку завантажує XML, нормалізує його у JSON і надсилає в Kafka.  
2. **Видобування** – сервіс видобування тегує кожен контроль (`AC‑2`, `AU‑6`) та пов’язані пояснювальні абзаци.  
3. **Мутація графу** – Cypher‑команди `MERGE` додають нові вузли або оновлюють `effectiveDate` існуючих. Ребро `OVERWRITES` пов’язує нову версію зі старою.  
4. **Створення знімка** – плагін **temporal** Neo4j фіксує знімок з ID (`graphVersion=2025.11.12.01`).  
5. **Запит у питанні** – аналітик відкриває анкету з питанням “Як ви керуєте створенням облікових записів?”  
6. **Контекстуальне отримання** – сервіс запитує граф за вузлами, пов’язаними з `AC‑2`, та відфільтровує за доменом компанії (`SaaS`, `IAM`). Повертає два витяги політики та один витяг звіту аудиту.  
7. **Чернетка LLM** – LLM отримує підказку та отримані докази, генерує стислу відповідь з посиланнями на ID доказів.  
8. **Рецензія** – аналітик перевіряє посилання, додає коментар про недавнє внутрішнє оновлення процесу і схвалює.  
9. **Аудиторський журнал** – система фіксує ID знімка графу, ID вузлів‑доказів, версію LLM та ідентифікатор користувача‑рецензента.  

У середньому всі кроки виконуються **за менш ніж 30 секунд** для типового пункту анкети.

---

## 4. Практичний посібник з впровадження

### 4.1 Передумови

| Компонент | Рекомендована версія |
|-----------|----------------------|
| Neo4j | 5.x (Enterprise) |
| Kafka | 3.3.x |
| Go | 1.22 |
| Python | 3.11 (spaCy та RAG) |
| LLM API | OpenAI GPT‑4‑Turbo (або Azure OpenAI) |
| Хмара | AWS (EKS для сервісів, QLDB для аудиту) |

### 4.2 Кроки налаштування

1. **Розгорнути кластер Neo4j** – увімкнути плагіни **Temporal** і **APOC**. Створити базу `regulatory`.  
2. **Створити Kafka‑топіки** – `regulatory_raw`, `graph_updates`, `audit_events`.  
3. **Налаштувати збирачі потоків** – підключити офіційний RSS Євросвідомства, JSON‑потік NIST та webhook GitHub для спільних правил SCC. Зберігати креденшіали в **AWS Secrets Manager**.  
4. **Запустити службу інжестії** – Docker‑образ Go‑сервісу, задати змінну `KAFKA_BROKERS`. Моніторити через **Prometheus**.  
5. **Розгорнути видобування сутностей** – Docker‑образ Python з `spaCy>=3.7` і кастомною юридичною NER‑моделлю. Підписатися на `regulatory_raw` і надсилати нормалізовані сутності в `graph_updates`.  
6. **Оновлювач графу** – написати stream‑процесор (наприклад, **Kafka Streams** на Java), який споживає `graph_updates`, формує Cypher‑запити та виконує їх проти Neo4j. Додати correlation‑ID до кожної мутації.  
7. **Служба RAG‑отримання** – експортувати FastAPI‑endpoint `/retrieve`. Використовувати семантичну схожість через **Sentence‑Transformers** (`all-MiniLM-L6-v2`). Служба виконує двоходове обходження графу: **Питання → Відповідний контроль → Докази**.  
8. **Інтеграція з UI Procurize** – додати React‑компонент `EvidenceSuggestionPanel`, який викликає `/retrieve` при фокусуванні поля питання. Показувати результати з чекбоксами «Вставити».  
9. **Оркестрація LLM** – використати OpenAI Chat Completion, передаючи отримані докази як system‑messages. Фіксувати `model` і `temperature` для повторюваності.  
10. **Аудиторський журнал** – Lambda‑функція, яка улавлює події `answer_submitted`, записує запис у QLDB з SHA‑256 хешем тексту відповіді та посиланням на знімок графу (`graphVersion`).  

### 4.3 Кращі практики

- **Фіксація версій** – завжди зберігайте точну версію LLM та ID знімка графу разом із відповіддю.  
- **Зберігання даних** – зберігайте сирі регуляторні потоки щонайменше **7 років** для аудиту.  
- **Безпека** – шифруйте Kafka‑потоки TLS, ввімкніть RBAC у Neo4j, обмежте права запису у QLDB лише Lambda‑функції.  
- **Моніторинг продуктивності** – налаштуйте алерти на затримку служби отримання; ціль — < 200 мс на запит.  

---

## 5. Реальний кейс‑стаді: вплив на бізнес

**Компанія:** SecureSoft, середня SaaS‑компанія, що працює в галузі здоров’я.

| Показник | До DKGEE | Після DKGEE (за 3 місяці) |
|----------|----------|---------------------------|
| Середній час відповіді на пункт анкети | 2,8 години | 7 хвилин |
| Час на ручний пошук доказів (люд‑годин) | 120 год/міс | 18 год/міс |
| Кількість регуляторних невідповідностей під час аудиту | 5 за рік | 0 (невідповідностей не виявлено) |
| NPS команди комплаєнсу | 28 | 72 |
| ROI (на основі економії вартості праці) | — | ~ 210 тис. $ |

**Ключові фактори успіху**

1. **Миттєвий регуляторний контекст** – коли NIST оновив SC‑7, граф одразу показував сповіщення в UI, змушуючи команду переглянути пов’язані відповіді.  
2. **Провенансія доказів** – кожна відповідь відображала клікабельне посилання на точний пункт та його версію, що задовольняло вимоги аудиторів.  
3. **Усунення дублювання** – граф усунув дублювання доказів між різними продуктами, скоротивши витрати на сховище на **30 %**.  

SecureSoft планує розширити движок на **оцінки впливу конфіденційності (PIA)** та інтегрувати його у **CI/CD‑конвеєр** для автоматичної перевірки відповідності політик при кожному релізі.

---

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

**Q1: Чи працює движок з регуляціями, написаними не англійською?**  
Так. Конвеєр видобування сутностей включає багатомовні моделі; ви можете додати збирачі для японської APPI, бразильського LGPD тощо, а граф зберігає теги мови для кожного вузла.

**Q2: Як система справляється з протилежними регуляціями?**  
Створюються ребра `CONFLICTS_WITH`, коли два вузли мають однакову сферу впливу, але різні вимоги. Служба отримання ранжує докази за `confidenceScore`, беручи до уваги ієрархію регуляцій (наприклад, GDPR переважає національне законодавство).

**Q3: Чи прив’язаний я підв’язок до конкретного постачальника?**  
Ні. Усі ядра побудовані на відкритих технологіях (Neo4j, Kafka, FastAPI). Єдиним стороннім сервісом є API LLM, який можна замінити будь‑яким моделлю, сумісною з OpenAI‑подібним інтерфейсом.

**Q4: Яка політика зберігання даних графу?**  
Рекомендуємо **time‑travel** підхід: зберігати кожну версію вузла назавжди (як незмінні знімки), а старі знімки архівувати у “cold storage” після 3 років, залишаючи лише актуальний перегляд для щоденних запитів.

---

## 7. Перші кроки вже сьогодні

1. **Пілотний запуск інжестії** – виберіть один регуляторний джерело (наприклад, [ISO 27001](https://www.iso.org/standard/27001)) і потокуйте його у тестовий Neo4j‑кластери.  
2. **Запустіть приклад отримання** – використайте наданий скрипт `sample_retrieve.py` для запиту «Політика зберігання даних для клієнтів ЄС». Перевірте, чи повернено відповідні вузли‑докази.  
3. **Інтеграція у пісочничу анкету** – розгорніть UI‑компонент у staging‑оточенні Procurize. Дайте кільком аналітикам протестувати робочий процес «Застосувати доказ до відповіді».  
4. **Вимірювання** – зафіксуйте базові метрики (час на відповідь, кількість ручних пошуків) та порівняйте їх через два тижні використання.

Якщо потрібен практичний воркшоп, звертайтеся до команди Professional Services Procurize для **30‑денного пакету прискореного розгортання**.

---

## 8. Майбутні напрямки

- **Федеративні графи знань** – дозволити кільком організаціям ділитися анонімізованими маппінгами регуляцій, зберігаючи суверенітет даних.  
- **Аудит з нульовим розкриттям** – надати аудиторам можливість перевіряти відповідність без розкриття самих доказів.  
- **Прогнозування регуляцій** – поєднати граф із час‑рядковими моделями, щоб передбачати майбутні зміни законодавства та проактивно пропонувати оновлення політик.  

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

---

## <span class='highlight-content'>Дивіться</span> також

- [Dynamic Knowledge Graph Enrichment for Real‑Time Questionnaire Contextualization (Video Overview)](https://www.youtube.com/watch?v=example)