
# Կազմակերպելի AI Micro‑սերվիսների ճարտարեմություն չափչելիության համար անվտանգ հարցաշարների ավտոմատիզացիա

Շահունչներ բազում են օգտատերերով աճող անվտանգության հարցաշարների, վաճառողների գնահատումների և համաձայնության հաշվետվությունների ծավալների տակ։ Պարամետր տեսական գործիքները չի կարող թեկնածինին, հատկապես, երբ պետք է դրանք ինտեգրել տարբեր արտադրանքի ekosystem-ներով, աջակցել բազմալեզս հարցումներ և տրամադրել իրական‑ժամի մատեռնարքսադելիության հետբերիք։  

**Կազմակերպելի միկրո‑սերվիսների ճարտարեմություն**, որը կառուցված է մեծ լեզվի մոդելների (LLM) և վերականգնված‑արտարժան գեենս (RAG) շուրջ, միշտ է մակարդակագրում ավտոմատիզացիայի չափաչափը՝ պահպանելով այն ճկունությունն ու ղեկավարությունը, որոնք պահանջվում են ռեգուլյացված ոլորտներում։ Այս ուղեցույցում մենք կկատարենք.

* Անհատականացնենք հիմնական դիզայնի սկզբունքները, որոնք պահում են համակարգը **անհատապ, մատեռնարքսադելի և ընդարտածելի**:  
* Գնալով Referencing diagram-ով Mermaid‑ում։  
* Ցուցադրել, թե ինչպես յուրաքանչյուր ծառայությունը կարող է լինել առանձին՝ Kubernetes‑ում, serverless FaaS‑ում կամ edge runtime‑ում։  
* Տրամադրել կոնկրետ լավագույն փորձի առաջարկներ տվյալի կառավարում, observe‑ability, որըսի հետ շարունակելու բոլոր թողումներ։

> **TL;DR:** Բաժանել հարցաշարների ավտոմատիզացիայի հարթակը փոքր, հստակ սահմանված ծառայություններով, թող LLM‑ները ցածր‑պակաս inference շերտի հետ, իսկ իրադարձություն‑ադված կանալները պահպանեն միակ ճշգրիտ աղբյուրին՝ ապագիրների և տարբերակների վերահսկումի համար։

---

## 1. Ինչու պետք է կազմենք՝ ոչ լինել Հնդիկ Մոնոլիտ

| Մոնոլիտային մոտեցում | Կազմավորված Micro‑սերվիսներ |
|---------------------|----------------------------|
| Միակ կոդի բազա, դժվարցած մեծացում հատուկ բեռնաթափումները (օրինակ՝ LLM inference) | Ավազանված մեծացում – AI inference‑ը կարող է աշխատել GPU նոդերում, իսկ պահպալիքը կարող է մնալ արժեքներից արդյունավետ օբյեկտների պահարանականում |
| Խիստ կապակցվածություն, թարմացումները ռիսկավոր են; UI‑ում սխալը կարող է ամբողջ համակարգը կոտրել | Լրիվ կապակցվածություն՝ ասինքրոնիկ իրադարձություններ կամ HTTP API‑ները անջատում են ձախողումները |
| Սահմանված լեզվի‑անհատապ ինտեգրում – հաճախ միակ փաքակ | Պոլիգլոտ աջակցում – յուրաքանչյուր ծառայությունը կարող է գրել այն լեզվում, որը լավագույնն է այդ գործի համար (Go – հեղինակություն, Python – LLM‑ների կարգավորում, Rust – բարձր անցանկալի հոսքեր) |
| Ապահովում և համաձայնություն դառնում են խուժան, քանի որ լոգերը համակցված են | Կենտրոնացված իրադարձության պահարանը + անխմբվող մատեռնարքսադելի լոգը հստակ, հարմարվելի որոնման համար նախատեսված վերակազմակերպիչների համար |

**Կազմավորված** մոդելը ընդունում է *«կատարեք այն, ինչ է պետք, և փոխարինեք այն, ինչ չի պետք»* փիլիսոփայությունը։ Այն համատեղվում է անվտանգության հարցաշարների փոփոխական բնույթի հետ, որտեղ նոր վերահսկման շրջանակներ (օրինակ՝ [ISO 27001 Rev 2](https://www.iso.org/standard/27001)) կանաչվում են և թիմերը պետք է արագին համապատասխանեն։

---

## 2. Կենտրոնական ճարտարեմական սյունակները

1. **Stateless API Gateway** – UI‑ի, SaaS‑կոնեկտորների և արտաքին գործիքների մուտքադրվելը։ Արդյունքավորվում է նույնացում, հարցի ստուգում և վերջավորում։  
2. **Domain‑Specific Micro‑services** – յուրաքանչյուրը պարունակ է սահմանափակ համատեքստ՝  
   * **Questionnaire Service** – պահում է հարցաշարների մետատվյալները, տարբերակները ևամասերի հանձնարարությունները։  
   * **Evidence Service** – կառավարում է փաստաթղթեր (պոլիսներ, սքրինշոտներ, մատեռնարքսադելի լոգներ) անխմբված օբյեկտների պահարանում։  
   * **AI Orchestration Service** – կազմում է բերմաններ, աշխատում RAG պծպակները և վերադարձնում պատասխանի շրջանցումներ։  
   * **Change‑Detection Service** – դիտում է ապացույցների թարմացումները, և առաջադրում վերագումարները ազդված պատասխանների համար։  
   * **Notification Service** – ուղարկում է Slack, Teams կամ էլ‑փոստի միջոցները շահագրգիռ կողմերին։  
3. **Event Bus (Kafka / Pulsar)** – երաշխավորում է առնվազն մեկ անգամի ապա‑պաշտպանումը դոմեինների իրադարձությունների (օրինակ՝ `EvidenceUploaded`, `AnswerDrafted`) համար։  
4. **Observability Stack** – OpenTelemetry‑ի ստրեյզները շուրջ ծառայությունների, Prometheus‑ի մեթրիկները և Loki‑ի լոգերը։  
5. **Policy‑as‑Code Engine** – հայտարարագրական կանոնները (Rego կամ OPA‑ով) գնահատում են `final`‑պատասխանի նախքան։  

Բոլոր ծառայությունները կապակցվում են **gRPC** (նշանակված ցածր-արտակ) կամ **REST** (արտաքին ինտեգրացիա) միջոցով։ Դիզայնը խթանում է *հասարակ շղթա, խելացի վերջնակետեր*‑ը՝ բիզնեսի տրամաբանականը գտնվում է նրա տեղում, իսկ շղթան ընդմիջում է միայն հաղորդագրությունները։

---

## 3. Տեղեկատվական հոսք – Հարցից մինչև մատեռնարքսադելի պատասխան

Ավելի որնձին Mermaid‑ում պատկերացնենք մի ստանդարտ հարցման կյանքը։

```mermaid
flowchart TD
    subgraph UI["Օգտագործողի ինտերֆեյս"]
        UI1["«Վեբ UI»"] -->|«Ներկայացնել հարցաշար»| AG["«API Գոդար»"]
    end

    AG -->|«Նույնացում & Վավէտացում»| QMS["«Հարցաշարների Սերվիս»"]
    QMS -->|«Ստանալ շաբլոն»| AIOS["«AI Կոորդինացիայզ Սերվիս»"]
    AIOS -->|«Վերականգնել համապատասխան ապացույցներ»| ES["«Ապացույցի Սերվիս»"]
    ES -->|«Ապացույցի օբյեկտներ»| AIOS
    AIOS -->|«Ստեղծել նախագծված պատասխանը»| RAG["«RAG Փողոց»"]
    RAG -->|«LLM ելք»| AIOS
    AIOS -->|«Պահպանել նախագծվածը»| QMS
    QMS -->|«Ներկայացնել AnswerDrafted»| EB["«Իրադարձությունների Բուս»"]
    EB -->|«Ձևավորել»| CDS["«Փոփոխությունների Դիտարար Սերվիս»"]
    CDS -->|«Կրկին գործարկել, եթե ապացույցը փոփոխված է»| AIOS
    CDS -->|«Ներկայացնել AnswerUpdated»| EB
    EB -->|«Ծանոթացնել»| NS["«Ծանուցման Սերվիս»"]
    NS -->|«Ուղարկել Slack/Email‑ին»| UI

    style UI fill:#f9f,stroke:#333,stroke-width:2px
    style AG fill:#bbf,stroke:#333,stroke-width:1px
    style QMS fill:#bfb,stroke:#333,stroke-width:1px
    style AIOS fill:#ffb,stroke:#333,stroke-width:1px
    style ES fill:#fbb,stroke:#333,stroke-width:1px
    style RAG fill:#fdd,stroke:#333,stroke-width:1px
    style CDS fill:#ddf,stroke:#333,stroke-width:1px
    style NS fill:#cfc,stroke:#333,stroke-width:1px
```

**Հոսքի կարևոր դրականները**.

1. **Օգտատերը ներկայացրում է** նոր հարցաշար կամ ընտրում առկա։  
2. **API Գոդար** արտավում JWT‑ն, ստուգում գրանցումները և ուղարկում հարցաշարների սերվիսին։  
3. **Հարցաշարների սերվիսը** վերցնում է շաբլոն և հրապարակում իրրվող իրադարձություն AI Կոորդինացիայզ Սերվիսին։  
4. **AI Կոորդինացիայզ** կատարում է *վերականգնված քայլը*՝ հարցում հարցում հարցում հարցում հարցում, որոնելով `Evidence Service`‑ից համապատասխան ապաբերված աղբյուրները (սարք/բանալի կամ վեկտոր մտավորականություն։)  
5. Հայտնված համատեքստերը, ինչպես նաև բերմանը, ընդինելով **RAG պեցին** (օրինակ՝ `openAI/gpt‑4o‑preview`).  
6. Նախնական պատասխանը պահվում է հետ `Questionnaire Service`‑ում որպես *«սպասում վերանայում»*։  
7. **Փոփոխության Դիտարարը** հետևում է ապացույցի նոր բեռների՝, եթե քաղաքականությունը թարմացվում է, այն վերակատարում է RAG‑ը ազդված պատասխանների համար։  
8. Վերջնական պատվիրակները ստում են կամ խմբագրում, որոնում հետո **Policy‑as‑Code Engine**‑ը հավաստիացնում, որ պատասխանը բավարարում է բոլոր կանոնների սահմանման, այն վերադարձնել անխմբվող մատեռնարքսադելի գրանցում։  

---

## 4. Ներդրման մանրամասները

### 4.1. API Գոդար (Envoy + OIDC)

* **Routing** – `POST /questionnaires/:id/answers` → `questionnaire-service`.  
* **Կայունություն** – պարտադրում է `questionnaire:write`‐սկոպները։  
* **Բեռնային պակասություն** – 100 պահանջ մի րոպե մեկ տենանտի համար, մինչ LLM‑ների ծախսերը ապահովելու համար։

### 4.2. Հարցաշարների Սերվիս (Go)

```go
type Questionnaire struct {
    ID          string            `json:"id"`
    Version     int               `json:"version"`
    Controls    []Control        `json:"controls"`
    Drafts      map[string]Answer `json:"drafts"` // key = control ID
    AssignedTo  map[string]string `json:"assigned_to"` // userID
}
```

* Օգտագործում է **PostgreSQL**՝ հարաբերական տվյալների համար, **EventStoreDB**՝ դոմեինների իրադարձությունների համար։  
* Տպագրություններ `GetTemplate`, `SaveDraft`, `FinalizeAnswer`‑ը gRPC‑ով։

### 4.3. Ապացույցի Սերվիս (Python + FastAPI)

* Պահպանում է ֆայլերը **MinIO** կամ **AWS S3**‑ի վրա, զրկելով բաժանման քաղցկեղի գաղտնիքով։  
* Արդյունքվում է **Qdrant**‑ում (վեկտորային շտեմարան)՝ համեմատական որոնման համար։  
* Սպասարկում է `POST /search` վերջակետը, որը ընդունում է հարցարածը և վերադարձնում է լավագույն `k` փաստաթղթի ID‑ները։

### 4.4. AI Կոորդինացիայզ Սերվիս (Python)

```python
def generate_answer(question: str, evidence_ids: List[str]) -> str:
    evidence = fetch_evidence(evidence_ids)
    context = "\n".join(evidence)
    prompt = f"""You are a compliance specialist.
    Using the following evidence, answer the question concisely:\n{context}\n\nQuestion: {question}"""
    response = client.chat.completions.create(
        model="gpt-4o-mini",
        messages=[{"role":"system","content":prompt}]
    )
    return response.choices[0].message.content
```

* **RAG** – Վեկտորային որոնումը համադրվում է *system prompt*‑ի հետ, որը պարտադրում է մոդելին մատուցել ապացույցի ID‑ները։  
* **Cache** – Պահպանում է գեներացված պատասխանները 24 ժամվա Համար՝ գործուն LLM‑ին կանչի խուսափելու համար։

### 4.5. Փոփոխության Դիտարար Սերվիս (Rust)

* Բաժանորդագրվում է `EvidenceUploaded`‑ի իրադարձություն։  
* Հաշվարկում է **hash**‑ը նոր փաստաթղթի և կատարում է **diff**‑ը ապացույցների հետ, որոնք կապված են յուրաքանչյուր վերահսկման հետ։  
* Եթե տարբերությունը գերազանցում է կարգադրված հատակը, այն հրապարակում է `AnswerRequiresRegen`‑ը։

### 4.6. Ծանուցման Սերվիս (Node.js)

* Լսում է `AnswerDrafted`, `AnswerFinalized`, `AnswerRequiresRegen`։  
* Ֆորմատավորում է Slack Block‑ները, Teams Adaptive Card‑ները կամ էլ‑փոստի ձևանմուշները։  
* Աջակցում է **deduplication** – ծանուցում է միայն մեկ անգամ փոփոխության համար յուրաքանչյուր հարցաշարի համար։

---

## 5. Անվտանգություն & Կառավարման

| Խնդիր | Հարգանք |
|-------|----------|
| **Տվյալների ցածրություն** – LLM‑ի բերմանները կարող են պարունակել գաղտնի քաղաքականություն | **On‑prem LLM inference** (օրինակ՝ Llama 3.2)՝ VPC‑ի մեջ։ Պաշտպանում ենք PII‑ը՝ մեկնումը առաջանումը՝ արտաքին API‑ների հետ։ |
| **Ապացույցի չպետք հասանելիություն** | Պաշտպանում ենք մանրակրկիտ ACL‑ները՝ OPA‑ի կանոններով `Evidence Service`‑ում։ |
| **Մոդելի պտտում** – Պատասխանը անկուն է դառնում | Կազմակերպում ենք **պարբերական գնահատում**՝ պահանջների շղթա և վերադարձրակալ՝ prompt‑ների թարմացում։ |
| **Մատեռնարքսադելիություն** | Ամեն դաշտի փոփոխությունը գրանցված է անխմբվող իրադարձության լոգում, սંગ્રված `WORM S3`‑ում։ |
| **GDPR / CCPA** | Ընդունակ `right‑to‑be‑forgotten` – ջնջում ենք օգտատիրոջ‑հատուկ ապացույցները վեկտորային շտեմարանից և օբյեկտների պահարանից։ |
| **ISO 27001** | Դիմորդները՝ ապացույցների պահում, գաղտնագրում, հասանելիության քաղաքականությունները համեմատվում են ISO 27001-ի պահանջներին։ |
| **HIPAA / SOC 2** | Ընդլայնում ենք OPA կանոնները՝ ապահովված պահումների համար պահանջված վերահսկումներ։ |

---

## 6. Մատչելիության ռազմավարություններ

1. **Horizontal Pod Autoscaling (HPA)** – Մակարդակավորեք AI Orchestration պոդերը՝ GPU‑ի օգտագործման (`nvidia.com/gpu`) հիման վրա։  
2. **Burst‑able Queues** – Kafka‑ի բաժինները բաժանված են թրածիկի տենանտների համար։  
3. **Cold‑Start Reduction** – Պահպանում մի տաքափող կոնտեներների պուլ՝ LLM inference‑ի համար (օրինակ՝ **KEDA**‑ի կստորական ցուցիչ)։  
4. **Cost Controls** – Նպատակակազմի վրա սահմանում ենք **token‑based budgeting**‑ը, որ ալիքները կամ ավելորդ օգտագործումը ավտոմատ տարբերակով գեներացվի։

---

## 7. Observe‑ability & Դիտարկում

* **Distributed Tracing** – OpenTelemetry‑ի ստրեյզները սկսվում են UI‑ից → API Գոդար → AI Կոորդինացիայզ → RAG → Evidence Service։  
* **Metrics** – `answer_draft_latency_seconds`, `evidence_upload_bytes`, `llm_token_usage`։  
* **Log Aggregation** – Կառուցված JSON‑լոգերը `request_id`‑ով, որը ղեկավարվում է ծառայությունների միջից։  
* **Feedback Loop** – Պատասխանի վերջնականացմանը հանգեցնում է **review_score**‑ի հավաքագրություն։ Այս տվյալներն օգտագործվում են **reinforcement learning** մոդելին, որը կարգավորում է prompt‑ների ջերմաստիճանը կամ այլ աղբյուրների ընտրությունը։

---

## 8. Քայլ քայլովերը՝ Փոխանցման Ճարտարություն

| Ցանկ | Նպատակ | Գործողություններ |
|------|----------|-------------------|
| **0 – Անհատականացում** | Նկարագրել ընթացիկ հարցաշարների ընթացքը | Հատկորոշել տվյալների աղբյուրները, սահմանել վերահսկման թակսոնոմիան |
| **1 – Հիմնադրամների կառուցում** | Կառուցել API Գոդար, նույնացումը, հիմնային ծառայությունները | Կոնտեներիզացնել `questionnaire-service` և `evidence-service` |
| **2 – AI-ի ներգուծում** | Գործարկել RAG‑ի պղպջակ մի թեստային հարցաշարով | Օգտագործել sandbox LLM, ձեռքով ստուգելով Draft‑ները |
| **3 – Իրադարձություն‑ադված ավտոմատիզացիա** | Երկրակետի հետ կապված `Change‑Detection Service` | Միացնել ինքնակառավարման վերագումարները ապացույցների թարմացումից հետո |
| **4 – Կառավարության խիստացում** | Յարձակում OPA կանոններ, անխմբվող մատեռնարքսադելի լոգեր | Փոխանցել LLM‑ին on‑prem, կիրառել արտադրական պլատֆորմ |
| **5 – Սանդղակ և օպտիմիզացում** | GPU պոդի ինքնակառավարություն, ծախսի վերահսկում | Ներկայացնել Observe‑ability գործիքակազմ, սահմանել SLO‑ներ |

Փասպաստ՝ կազմված ճարտարեմությանը՝ թիմերը խուսափում են «սարք‑համաք» ռիսկից և ցուցադրում է վաղ ROI‑ին (սովորաբար **30‑50 %** նվազեցում հարցաշարների հաշվարկման ընթացքում)։

---

## 9. Ապագա‑համար պլանավորում

* **Federated Learning** – Այլ‑տենանտների համար լարաբար պատրաստում `adapter`‑ները, առանց դպրոցի տվյալների տեղափոխման, մեխանիզմը բարելավելու համար պատասխանների ոչ ցանկալի կառուցվածք։  
* **Zero‑Trust Service Mesh** – **Istio** կամ **Linkerd**՝ փոխաշնակող TLS‑ով, ապահովեցնելուինternal‑սանձնակցված շղթաները։  
* **Semantic Governance** – Ընդլայնված Policy‑as‑Code՝ գնահատում ոչ միայն պատասխանի բովանդակությունը, այլև **սեմանտիկական համապատասխանությունը**   ապացույցների և վերահսկման լեզվին։  
* **Generative Traceability** – Պահպանում ենք իդեալական LLM-ի ջերմաստիճան, top‑p և system prompt‑ը յուրաքանչյուր պատասխանի հետ, ֆորենսիկ հետազոտության համար։

---

## 10. Եզրի

Կազմված միկրո‑սերվիսների ճարտարեմությունը փոխում է անվտանգության հարցաշարների ավտոմատիզացիան «ձեռնարկված ձեռքի աշխատանքից» դեպի **սանդղակ, մատեռնարքսադելի և շարունակաբար բարելավվող շարժիչ**։ Դոմինները բաժանելով, օգտագործելով LLM‑ները Stateless RAG շերտի միջոցով և կապածների հետ՝ իրադարձություն‑ադված գծով, կազմակերպությունները կարող են.

* Պատասխանելու վաճառողների գնահատումները րոպեների մեջ, ոչ թե օրերում։  
* Պահպանել ապացույցները ինքնակառավարած, մատեռնարքսադելի դեպքի հետ։  
* Համապատասխանել ռեգուլյատորներին՝ մատնանշելով միակ չխախտված, անխմբվող մատեռնարքսադելի հետբերիք։

Սկսեք փոքր, կրկնակի արդիականացեք արագ, և թողեք միկրո‑սերվիսների փիլիսոփայությունը ձեր համաձայնության գործընթացները դարձնի **հատուկ ֆունկցիա**, ոչ խնդիր։

---

## Տե՛ւ նաև

- [OPA Policy‑as‑Code for Micro‑services](https://www.openpolicyagent.org/docs/latest/policy-language/) (OPA‑ի քաղաքականության‑որպես‑կոդի առարկան միկրո‑սերվիսների համար)