
# დინამიური ცნობების გრაფის განვითარება რეალურ‑დროის კითხვარი‑კონტექსტულიასახლებაზე

## შესავალი

უსაფრთხოების კითხვარები და შესაბამისობის აუდიტები გახადეს ბოჭკს ყოველ სწრაფად ზრდასრულ SaaS ორგანიზაციებში. გუნდებს ილიკია უძლოდელია საათები სწორი პოლიტიკის კლაზი დასაძიებლად, მასალა დოკუმენტთა საცავებიდან დასაკრეფებლად და იგივე პასუხის გადაწერისთვის ყოველი ახალი პროვაიდერის მოთხოვნისთვის. მიუხედავად იმისა, რომ დიდი ენის მოდელები (LLM‑ები) μπορούν გააგრძელებინათ აპირებული პასუხები, ისინი ხშირად აკლდება **რეგულაციური ნუანსანს**, რომელიც დღეში-დღეზე იცვლება — ახალი მითითებები European Data Protection Board (EDPB)‑ისგან, განახლებული [NIST CSF](https://www.nist.gov/cyberframework) (მაგ., NIST SP 800‑53) კონტროლის ნაკრები, ან ახლახანს გამოქვეყნებული [ISO 27001](https://www.iso.org/standard/27001) შეცვლა.

**Procurize** ამ საკითხს ითვლის **დინამიული ცნობების გრაფის განვითარება ძრავა (DKGEE)**‑ით. ძრავა მუდმივად იღებს რეალურ‑დროის რეგულაციურ წყადებს, უსვამს ისინი ერთობლივ მეცნიერ-გრაფზე, და მიწოდებს კონტექსტურ თანხმობას, რომელიც პირდაპირ აღმდგენი კითხვარის UI-ში არის ხელმისაწვდომი. ამის შემდეგ კი დარგდება *ერთობლივი ჭკვიანი წყარო*, რომელიც ავტომატურად იმუშავებს, აკცირებს რეაგირების დროებს დღეებიდან წუთებში, და უზრუნველყოფს, რომ every answer reflects the latest compliance posture.

ამ სტატიით ჩვენ შეგებთ:

1. განვსაზღვროთ, რატომ არის დინამიური ცნობების გრაფი დაკარგული ბადით AI‑განმწერული მასალათაა და აუდიტ‑განდამმყოფი პასუხის შორის.  
2. გავარკვიფოთ არქიტექტურა, მონაცემთა ნაკადის და DKGEE‑ის ძირითადი კომპონენტები.  
3. გავაჩეროთ, როგორ ინტეგრირდება ძრავა Procurize-ის არსებული დავალების‑მართვისა და კომენტარული ფენებთან.  
4. დავსალივოთ რეალური რიცხვი‑ბაზის მიმართულებით ROI‑ის მქონე სტატია.  
5. მივაწოდოთ პრაქტიკული რჩევები, რათა გუნდებმა დღესვე დასაწყისდეს ძრავი.

---

## 1. რატომ იჯდება სტატიკური საინფორმაციო ბაზა

| პრობლემა | სტატიკური საინფორმაციო ბაზა | დინამიული ცნობების გრაფი |
|---------|----------------------------|---------------------------|
| **რეგულაციის განახლებები** | საჭიროებს ხელოვან იმპორტს; განახლება ჩვეულებრივ აგრძელება უფლებით ანაწერის კვირებით. | ავტომატური წყარო‑იღება; განახლება წუთებში. |
| **მრავალ‑ფრემის ლინკირება** | ხელის‑ნაკრების ცხრილები სწრაფად არ აწოლება. | გრაფ‑მახასიათებლებით ურთიერთობა მუდმივად შედგება, როდესაც ახალი დაბეჭდით თუავე. |
| **კონტექსტური თანხმობის საპოვნა** | საკვანძო‑შესაძენი ძიება ასცემს ხმასარებრივ შედეგებს. | სემანტიკური გრაფ‑ტექსტი მიმგებლის ზუსტი, პროვენანს‑გადაყრილი თანხმობა. |
| **აუდიტის შესაძლებლობა** | არ არის ავტომატური ცვალება. | შემზადებულია ვერსიონისა და ხაზის ტრეკის შესაძლებლობა თითოეული კვანძი. |

სტატიკური საცავი შეიძლება შეიცავდეს პოლიტიკებს, თუმცა არ შეუძლია *იგირების* რომ ვინტავს ახალი რეგულაცია—მაგალითად GDPR‑ის ახალი არგიუმენტები—როდესაც არსებული ISO‑ის კონტროლს იცვლის. DKGEE‑ის ამოგიწოდება **რეგულაციური ეკოსისტემის მოდება როგორც გრაფი**, სადაც თითოეული კვანძი წარმოდგენილია მოხსენება, მითითება ან თანხმობის არქივი, ხოლო ბგერები საწავლთ ურთიერთობაში, როგორიცაა *“სჭირდება”*, *“გადადის”* ან *“ინტერს”*. ახალი რეგულაციის გაყოფისას, გრაფი **ინკრემენტალურად განახლება**, წარმოქმნიან ისტორიას და  ის‑ის პერიოდში გადის გავლენა არსებული პასუხებზე.

---

## 2. არქიტექტურის საერთო ხედი

ქვემოთ იყოფა მაღალი‑დროულობა Mermaid დიაგრამა, რომელიც ატარებს DKGEE პიფლაინის ვიზუალიზაციას.

```mermaid
graph TD
    A["Regulatory Feed Collectors"] --> B["Ingestion Service"]
    B --> C["Normalization & Entity Extraction"]
    C --> D["Graph Updater"]
    D --> E["Dynamic Knowledge Graph"]
    E --> F["Contextual Retrieval Engine"]
    F --> G["Procurize UI (Questionnaire Builder)"]
    G --> H["LLM Draft Generator"]
    H --> I["Human‑in‑the‑Loop Review"]
    I --> J["Final Answer Storage"]
    J --> K["Audit Trail & Versioning"]
```

### 2.1 ძირითადი კომპონენტები

1. **Regulatory Feed Collectors** – კონექტორები ოფიციალურ წყაროებზე (EU Official Journal, NIST RSS, ISO განახლებები), საერთო წყაროებზე (GitHub‑ის შესრულებული შესაბამისი წესები) და პროვაიდერის‑სპეციფიკური პოლიტიკის ცვლილებები.  
2. **Ingestion Service** – მსქელი micro‑service, შესრულებულია **Go**‑ში, ვერიფიცირებს payload‑ებს, იდენტიკაციას იღებს დუბლიკატებს, და მიწოდებს raw‑მონაცემებს Kafka‑ის ტოპიკზე.  
3. **Normalization & Entity Extraction** – იყენებს **spaCy**‑ს და **Hugging Face**‑ის ნეიმ‑ეკრანის მოდელებს, რომელიც განახლებულია სამართლებრივი ტექსტის მიხედვით, რათა გამოვიღოს კლაუზები, განსაზღვრებები და რეფერენციები.  
4. **Graph Updater** – მუშაობს **Cypher** პროვაზებთან Neo4j‑ის (5.x)‑ზე, ქმნის ან განახლებს კვანძებსა და ბგერებს, ხოლო შენარჩუნებს ვერსიონის ისტორიას.  
5. **Dynamic Knowledge Graph** – ინახავს მთლიან რეგულაციით ეპისტემოლოგიას. ყოველი კვანძის თვისებები: `id`, `source`, `text`, `effectiveDate`, `version`, `confidenceScore`.  
6. **Contextual Retrieval Engine** – RAG‑ის‑ტიპის სერვისი, რომელსაც თანხმობა კომლეკს კითხვას, აკეთებს სემანტიკური გრაფ‑ტექსტის ტრავერსიის, დილითს დადასტურდული თანხმობა, და ბრუნავს JSON‑payload‑ს.  
7. **Procurize UI Integration** – ფრონტ‑ენი იყენებს payload‑ს და განეკუთვნით შემოთავაზებებს ყოველ კითხვაზე, უნიშნავს inline‑კომენტარებს და ღილაკებს “Apply to Answer”.  
8. **LLM Draft Generator** – **GPT‑4‑Turbo** მოდელი, რომელიც იყენებს მიღებული მონაცემთა თანხმობას, რათა მწარმოებდეს პირველ‑დრიფტს პასუხს.  
9. **Human‑in‑the‑Loop Review** – მიმღები შეიძლება განისაზღვროს, შეცვალოს, ან უარყოს დრაფტები. ყველა ქმედება რეგისტრირებულია აუდიტის მიზნით.  
10. **Final Answer Storage & Audit Trail** – პასუხები ინახება იმმიუტაბილ ტრილში (მაგ., **AWS QLDB**) კრიპტოგრაფიული ჰეშით, რომელიც ბმულია გრაფ‑ს ნაკადის ტრაწეკტით, რომლის ფარგლებში მწარმოებულია.

---

## 3. მონაცემთა ნაკადი – წყაროდან პასუხამდე

1. **Feed Arrival** – გამოქვეყნებულია ახალი NIST SP 800‑53 ვერსია. Feed Collector იღებს XML‑ს, ნორმალიზაციას აკეთებს JSON‑ში, და აწის Kafka‑ს.  
2. **Extraction** – Entity Extraction სერვისი ჭდება თითოეული კონტროლა (`AC‑2`, `AU‑6`) და შესაბამისი მითითებების პუნქტები.  
3. **Graph Mutation** – Cypher `MERGE` პროვაზები ქმნის ახალ კვანძებს ან განახლებს `effectiveDate`‑ს არსებულზე. `OVERWRITES`‑ის ბგერა აერთიანებს ახალ კონტროლას ძველის მიმართ.  
4. **Snapshot Creation** – Neo4j‑ის `temporal` პლაგინით შეინახება სნეპშოტ‑ID (`graphVersion=2025.11.12.01`).  
5. **Question Prompt** – უსაფრთხოების ანალსტი იღებს კითხვაზე “როგორ მართავთ ანგარიშის მიწერასა?”.  
6. **Contextual Retrieval** – Retrieval Engine ითხოვს გრაფიდან კვანძებს, რომლებიც დაკავშირებულია `AC‑2`‑ს და კომპენიზე `SaaS`, `IAM` –‑‑‑‑ ში. აბრუნებს ორი პოლიტიკის ექსერტსა და ახლახანს გამოცოცხლებული აუდიტის მოხსენების ექსერტს.  
7. **LLM Draft** – LLM იღებს პროპორციულ მოთხოვნაზე და მიიღებული თანხმობის საფუძველზე, წარმოშობს მოკლე პასუხს, ციტირებულია თანხმობა‑ID-ებით.  
8. **Human Review** – ანალსტია ადასტურებს ციტირებებს, ჩამატებს კომენტარს შიდა პროცესის შესახებ, და დასასტურებს.  
9. **Audit Log** – სისტემამ სარიცხვიერებლებსის შეუძლია აუდიტის ჩანაწერი: გრაფ‑სნეპშოტ‑ID, თანხმობა‑კვანძი‑ID‑ები, LLM‑ის ვერსია, რეისერის მომხმარებლის ID.

ყველა ნაბიჯი შესრულდება **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) |
| Cloud | AWS (EKS სერვისებისთვის, QLDB აუდიტისთვის) |

### 4.2 ნაბიჯ‑ნაკლული ინსტალაცია

1. **დაგეგმეთ Neo4j კლასკერი** – ჩართეთ **Temporal** და **APOC** პლაგინები. შექმენით ბაზა `regulatory`.  
2. **Kafka‑ის ტოპიკები** – `regulatory_raw`, `graph_updates`, `audit_events`.  
3. **Feed Collectors კონფიგურირება** – გამოიყენეთ EU Gazette RSS, NIST JSON feed, და GitHub Webhook‑ი კომპიუტერის‑მოქმედებული SCC წესებისთვის. საიდენტიფიკაციო მონაცემები შეინახეთ **AWS Secrets Manager**‑ში.  
4. **Ingestion Service გაშვება** – Docker‑ში Go‑service, `KAFKA_BROKERS` env variable. მონიტორინგი **Prometheus**‑ით.  
5. **Entity Extraction განთავსება** – Docker‑image Python‑ში `spaCy>=3.7` და თქვენი ლეგალური NER მოდელისით. აბონილს `regulatory_raw`, გამოაქვს ნორმალიზებული entites `graph_updates`‑ტოში.  
6. **Graph Updater** – შექმენით stream‑processor (მაგ. **Kafka Streams** Java‑ში) რომელიც აბრუნებს `graph_updates`, ქმნის Cypher‑ის მოთხოვნებს, და ახორციელებს Neo4j‑ში. თითოეული ცვლადი დაესება correlation‑ID‑ს.  
7. **RAG Retrieval Service** – FastAPI endpoint `/retrieve`. სემანტიკური სრიალება `Sentence‑Transformers`‑ით (`all-MiniLM-L6-v2`). სერვისი იყოფს ორი‑ჯოლოვანი ტრავერსია: **Question → Relevant Control → Evidence**.  
8. **Procurize UI ინტეგრაცია** – დაამატეთ React‑კომპონენტი `EvidenceSuggestionPanel`, რომელიც გამოძებნება `/retrieve` როდესაც კითხვარის ფીલდზე ფოკუსია. გამოსახეთ შედეგები CheckBox‑ებით “Insert”.  
9. **LLM Orchestration** – გამოიყენეთ OpenAI‑ის **Chat Completion** endpoint, გადმოცემული თანხმობა როგორც system messages. დავამატეთ `model` და `temperature` ლოგისათვის.  
10. **Audit Trail** – Lambda‑ფუნქცია აღინიშნება ყველა `answer_submitted`‑ის ღონისძიებას, აკრიცხვთ ჩანაწერს QLDB-ზე SHA‑256 ჰეშით, პასუხის ტექსტით, და გრაფ‑სნეპშოტ‑ID‑ით.

### 4.3 საუკეთესო პრაქტიკები

- **Version Pinning** – შენახეთ ზუსტი LLM მოდელის ვერსია და გრაფ‑სნეპშოტ‑ID‑თ ყოველი პასუხისათვის.  
- **Data Retention** – შენახეთ ყველა რეგულაციური raw‑მონაცემი მინიმუმ **7 წლის** აუდიტის საჭიროებით.  
- **Security** – დაშიფრეთ Kafka ნაკადები TLS‑ით, გააქტიურეთ Neo4j‑ის როლ‑ბაზირებული კონტროლი, და შეზღუდეთ QLDB‑ის დამუშავება Lambda‑ისამდე.  
- **Performance Monitoring** – ალერგიების დაყენება Retrieval Engine‑ის latency‑ზე; მიზანია < 200 მწ კვალზე თითოეული მოთხოვნა.

---

## 5. რეალურ‑დროში გავლენა: შემთხვევის შესწავლა

**კომპანია:** SecureSoft, საშუალო SaaS პროვაიდერი, რომელიც საქმიანია ჯანმრთელობას‑ტექნოლოგიებში.

| მაკროცენტი | DKGEE‑ის წინ | DKGEE‑ის შემდეგ (3‑თვ.) |
|------------|--------------|---------------------------|
| საშუალო დრო პასუხის კითხვაზე | 2.8 საათი | 7 წუთი |
| ხელით აღწერის საზომი (საათ‑მოქმედება) | 120 საათი/თვე | 18 საათი/თვე |
| რეგულაციური უკმასული განხილვა აუდიტებში | 5 ყოველწლიურად | 0 (უხარისხება) |
| შესაბამისის გუნდის NPS | 28 | 72 |
| ROI (ზე კომპანია სამუშაო ხარჯის შესაზღვრა) | — | ~ $210 k |

**წარმატების ძირითადი მიზეზები**

1. **ეოდიტის რეგულაციის კონტექსტი** – როდესაც NIST იზრდება SC‑7‑ზე, გრაფი პირდაპირ UI‑ში ცნობას აჩვენა, რაც გუნდს ხელსაწყოსგან იწვროს დამახასიათებელია.  
2. **ტანის დამადასტურება** – ყოველი პასუხი აჩვენა უკითვალი ბმული შესაბამისი კლაუზის და ვერსიის ლინკს, რაც აუდიტორთა მოთხოვნის წინაპრებს ფართოდ.  
3. **განწყობა რედანდანტურობა** – ცნობების გრაფი გასდგომ შერჩეულ დონეზე აუნიშის დუბლირებული მასალები ყველა პროდუქტზე, რაც 30 % დანაწესრიგებული ღირებულება შეამცირა.

SecureSoft აერთიანებულია გაფართოების სტრატეგიისთვის **პრივატის შემოწმება (PIA)**-ის, და ინტეგრირებულია CI/CD‑პაიპლაინში, რომ ყოველ გამოცემის კომისიის შემოწმება იყოს ავტომატური.

---

## 6. ხშირად დასრიცხვი კითხვები

**კ1: მუშაობს თუ არა ძრავა არ‑ინგლისურ რეგულაციებზე?**  
დიახ. Extraction Pipeline‑ში შედის მრავალენოვანი მოდელები; შეგიძლიათ დაამატოთ სპეციალურ სასარგებლო წყაროებს (მაგ. იაპონიის APPI, ბრაზილიის LGPD) და გრაფი შენახავს ენის‑ტელოთისზე თითოეულ კვანძზე.

**კ2: როგორ ავისა-რიცხვოთ წინააღმდეგ ვეღარ რეგულაციები?**  
ბგერი `CONFLICTS_WITH` დაშვებისას ავტომატურად შემოთავაზებულია, როდესაც ორი კვანძი იკავდება დამუშავებული ერთდრიული ადგილები, მაგრამ ინდივიდუალური მოთხოვნები. Retrieval Engine ითვლის `confidenceScore`‑ის მიხედვით, რომელიც გულისხმობს რეგულაციის იერარქიის შორის (მაგ. GDPR > ეროვნული კანონმდებლობა).

**კ3: არის თუ არა სისტემა‑გაგეგნოუთი?**  
ყველა ძირითადი კომპონენტი Open‑Source‑ზეა (Neo4j, Kafka, FastAPI). მხოლოდ LLM‑ის გამოყენება არის მესამე‑პარტიის სერვისი, თუმცა შეგიძლიათ შეცვალოთ ნებისმიერი მოდელით, რომელიც აკმაყოფილებს OpenAI‑ის თავსებადი endpoint‑ის სპეციფიკაციას.

**კ4: რა მონაცემთა შენახვის პრინციპალი გაქვთ?**  
რეკომენდირებულია **time‑travel** შეხედულება: ყველა კვანძი ვერსია შენახეთ უსასრულოდ (immutably), ხოლო ძველი snapshots(გრაფის-ჟურნალი) გადაიტანეთ ცივი შენახვის (cold‑storage) შემდეგ 3 წლამდე, დაჭირდდით დღიურ კითხვებზე მხოლოდ უკანასკნელი აქტიური ხედით.

---

## 7. დღესვე დაწყება

1. **პაილოტი ღურნი‑ღრმა** – აირჩეთ ერთი რეგულარული წყარო (მაგ. [ISO 27001](https://www.iso.org/standard/27001)) და გადაიტანეთ‑ტესტ Neo4j‑ში.  
2. **მაგალითი Retrieval** – გამიყენეთ `sample_retrieve.py`‑ის სკრიპტი, რაც ითხოვს “Data retention policy for EU customers”. შეამოწმეთ შემდეგი returned evidence nodes.  
3. **ინტეგრაცია Sandbox‑კითხარით** – განახლებისთვის UI‑კომპონენტის დარეგისტრირება Staging‑omgevingში Procurize‑ის. დაუმატეთ რამდენიმე ანალიტიკას “Apply evidence” workflow‑ს.  
4. **სიმპტომები** – ფიქსირეთ საბაზისო მაკროცენტები (დრო თითოეულ პასუხზე, მეტი ხელით ძიება) და შედარეთ ორი კვირის მოხმარების შემდეგ.

თუ გჭირდებათ პრაქტიკული სამუშაოს შედეგად, დაუკავშირდით Procurize‑ის Professional Services‑ის გუნდს **30‑დღიანი აჩქარებული განლაგების** პაკეტი.

---

## 8. მომავალის მიმართულებები

- **Federated Knowledge Graphs** – მრავალკომპანიის ჩაწერა ანონიმიზებული რეგულარული ნაცვალება, მონაცემთა ცივილიზაციისა მიუხედავად.  
- **Zero‑Knowledge Proof Auditing** – აუდიტორებს შეუძლიათ დასტური, რომ პასუხი შეესაბამება რეგულირებას, გაუგებრობით არჩეულით.  
- **Predictive Regulation Forecasting** – გრაფის ინტეგრაცია დროის‑განაკვეთის მოდელებთან, რათა საჭირო იყოს რეგულარული მოთხოვნების მომავალის პროგნოზირება, და proactively პროპორციული პოლიტიკებისთვის შეთავაზებები.  

დინამიური ცნობების გრაფი არის **ცოცხალი შესაბამისობის ძრავა**, რომელიც იზრდება რეგულაციასთან, და კვდება AI‑დამუშავებული ავტომატიზაციასთან მრავალჯერ.

---

## <span class='highlight-content'>ნახეთ</span> ასევე

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