
# معمارية الذكاء الاصطناعي القابلة للتكوين مع الخدمات المصغرة لأتمتة الاستبيانات الأمنية القابلة للتوسعة

تغرق المؤسسات في موجة متزايدة من استبيانات الأمان، وتقييمات البائعين، وتدقيقات الامتثال. تكافح الأدوات التقليدية الأحادية الشكل لتواكب هذا المتطلبات، خصوصًا عندما يتعين عليها الاندماج مع أنظمة منتجات متباينة، ودعم طلبات متعددة اللغات، وتوفير سجلات تدقيق في الوقت الفعلي.  

**معمارية الخدمات المصغرة القابلة للتكوين**، المبنية حول نماذج اللغة الكبيرة (LLMs) وتوليد معزز بالاسترجاع (RAG)، توفر طريقة لتوسيع الأتمتة مع الحفاظ على المرونة والحوكمة التي تتطلبها الصناعات الخاضعة للرقابة. في هذا الدليل سنقوم بـ:

* توضيح مبادئ التصميم الأساسية التي تحافظ على النظام **آمنًا، قابلًا للتدقيق، وقابلًا للتوسيع**.  
* استعراض تنفيذ مرجعي مرسوم باستخدام Mermaid.  
* إظهار كيفية نشر كل خدمة بشكل مستقل على Kubernetes، أو على بيئات Serverless FaaS، أو على بيئات الحافة.  
* تقديم توصيات عملية حول حوكمة البيانات، والرصد، والتحسين المستمر.

> **ملخص:** قسّم منصة أتمتة الاستبيانات إلى خدمات صغيرة محددة جيدًا، وضع نماذج اللغة الكبيرة خلف طبقة استدلال غير حالية، واستخدم خطوط أنابيب قائمة على الأحداث للحفاظ على مصدر الحقيقة الواحد للأدلة والتحكم بالإصدارات.

---

## 1. لماذا نختار التركيب بدلاً من بناء جسم ضخم أحادي؟

| النهج الأحادي | الخدمات المصغرة القابلة للتكوين |
|---------------------|---------------------------|
| قاعدة شفرة واحدة، صعوبة توسيع أحمال عمل محددة (مثل استدلال LLM). | توسيع مستقل – يمكن تشغيل استدلال الذكاء الاصطناعي على عقد GPU، بينما يظل التخزين على مخازن كائنات منخفضة التكلفة. |
| الترابط القوي يجعل التحديثات محفوفة بالمخاطر؛ خطأ في واجهة المستخدم قد يُسقط النظام كله. | ترابط ضعيف عبر أحداث غير متزامنة أو واجهات HTTP يعزل الفشل. |
| تكامل محدود مع لغات برمجة متعددة – غالبًا ما يُقفل على مجموعة تقنية واحدة. | دعم متعدد اللغات – يمكن كتابة كل خدمة باللغة الأنسب لمهمتها (Go للمصادقة، Python لتنسيق LLM، Rust لأنابيب عالية السرعة). |
| تدقيق والامتثال يصبح كابوسًا لأن السجلات متشابكة. | مخزن أحداث مركزي + سجل تدقيق غير قابل للتعديل يوفر مسارًا واضحًا وقابلًا للاستعلام للمنظمين. |

نموذج **القابلية للتركيب** يتبنى فلسفة "*تبني ما تحتاج، واستبدل ما لا تحتاجه*". وهو يتماشى مع الطبيعة الديناميكية لاستبيانات الأمان، حيث تظهر أطر تحكم جديدة (مثل [ISO 27001 الإصدار 2](https://www.iso.org/standard/27001)) بانتظام ويتعين على الفرق التكيّف بسرعة.

---

## 2. الركائز المعمارية الأساسية

1. **بوابة API غير حالة** – نقطة الدخول للواجهة، موصلات SaaS، والأدوات الخارجية. تتعامل مع المصادقة، والتحقق من الطلبات، والحد من السرعة.  
2. **خدمات مصغرة متخصصة** – كل واحدة تغلف سياقًا محدودًا:
   * **خدمة الاستبيان** – تخزن بيانات الاستبيان، الإصدار، وتخصيص المهام.  
   * **خدمة الأدلة** – تدير القطع (سياسات، لقطات شاشة، سجلات تدقيق) في مخزن كائنات غير قابل للتغيير.  
   * **خدمة تنسيق الذكاء الاصطناعي** – تُصاغ المطالب، تشغّل خطوط RAG، وتُعيد مسودات الإجابات.  
   * **خدمة كشف التغييرات** – تراقب تحديثات الأدلة، وتُطلق إعادة تقييم للإجابات المتأثرة.  
   * **خدمة الإشعارات** – تدفع أحداث إلى Slack أو Teams أو البريد الإلكتروني لأصحاب المصلحة.  
3. **ناقل الأحداث (Kafka / Pulsar)** – يضمن توصيل الرسائل مرة واحدة على الأقل للحدثات النطاقية (مثل `EvidenceUploaded`، `AnswerDrafted`).  
4. **كومة الرصد** – تتبع OpenTelemetry عبر الخدمات، مقاييس Prometheus، وسجلات Loki.  
5. **محرك السياسات ككود** – يقيّم قواعد الامتثال (مكتوبة بـ Rego أو OPA) قبل وضع أي إجابة كـ "نهائية".  

جميع الخدمات تتواصل عبر **gRPC** (لل latency المنخفض) أو **REST** (للتكاملات الخارجية). التصميم يشجع *أنابيب غبية، نقاط نهاية ذكية* — حيث تتواجد منطق الأعمال حيث يخصه الأمر، بينما يبقى الناقل مجرد ناقل رسائل.

---

## 3. تدفق البيانات – من السؤال إلى الإجابة القابلة للتدقيق

فيما يلي مخطط Mermaid يوضح دورة حياة طلب نموذجية.

```mermaid
flowchart TD
    subgraph UI["واجهة المستخدم"]
        UI1["\"واجهة ويب\""] -->|\"إرسال الاستبيان\"| AG["\"بوابة API\""]
    end

    AG -->|\"المصادقة والتحقق\"| QMS["\"خدمة الاستبيان\""]
    QMS -->|\"جلب القالب\"| AIOS["\"خدمة تنسيق الذكاء الاصطناعي\""]
    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/البريد\"| 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. **تستخرج خدمة الاستبيان** قالب الاستبيان وتُرسل حدثًا إلى خدمة تنسيق الذكاء الاصطناعي.  
4. **تُجري خدمة تنسيق الذكاء الاصطناعي** خطوة الاسترجاع — تستعلم خدمة الأدلة عن كل القطع المتعلقة بالتحكم الحالي (باستخدام تشابه المتجه أو مطابقة الكلمات).  
5. تُغذِّي السياقات المسترجعة، مع قالب المطالبة، خط أنابيب **RAG** (مثل `openAI/gpt‑4o‑preview`).  
6. تُخزن مسودة الإجابة في خدمة الاستبيان، وتُعلَّم *“قيد المراجعة”.*  
7. **تراقب خدمة كشف التغييرات** عمليات رفع الأدلة الجديدة. إذا تم تعديل سياسة ما، تُعيد تشغيل خط أنابيب RAG للإجابات المتأثرة.  
8. بعد قبول المراجعين، **يقوم محرك السياسات ككود** بالتحقق من أن الإجابة تلبي جميع القواعد قبل تثبيتها في سجل تدقيق غير قابل للتعديل.  

---

## 4. تفاصيل التنفيذ

### 4.1. بوابة API (Envoy + OIDC)

* **التوجيه** – `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"` // المفتاح = معرف التحكم
    AssignedTo  map[string]string `json:"assigned_to"` // معرف المستخدم
}
```

* يستخدم **PostgreSQL** للبيانات العلائقية، و**EventStoreDB** لأحداث المجال.  
* يوفّر أساليب gRPC `GetTemplate`، `SaveDraft`، `FinalizeAnswer`.

### 4.3. خدمة الأدلة (Python + FastAPI)

* تخزن الملفات في **MinIO** أو **AWS S3** مع تشفير على مستوى الدلو.  
* تفهرس المحتوى في **Qdrant** (قاعدة بيانات المتجهات) للبحث بالتشابه.  
* تُقدِّم نقطة النهاية `POST /search` التي تستقبل استعلامًا وتعيد أفضل k معرفات للقطع.

### 4.4. خدمة تنسيق الذكاء الاصطناعي (Python)

```python
def generate_answer(question: str, evidence_ids: List[str]) -> str:
    evidence = fetch_evidence(evidence_ids)
    context = "\n".join(evidence)
    prompt = f"""أنت أخصائي امتثال.
باستخدام الأدلة التالية، أجب على السؤال بإيجاز:\n{context}\n\nالسؤال: {question}"""
    response = client.chat.completions.create(
        model="gpt-4o-mini",
        messages=[{"role":"system","content":prompt}]
    )
    return response.choices[0].message.content
```

* **RAG** – دمج البحث المتجه مع موجه نظام يطلب من النموذج الاستشهاد بمعرفات الأدلة.  
* **التخزين المؤقت** – حفظ الردود المولدة لمدة 24 ساعة لتقليل عدد طلبات LLM.

### 4.5. خدمة كشف التغييرات (Rust)

* تشترك في أحداث `EvidenceUploaded`.  
* تحسب **هاش** للقطعة الجديدة وتُجري **فرق** مقارنةً بالأدلة المرتبطة بكل تحكم.  
* إذا تجاوز الفرق عتبة قابلة للتكوين، تُصدر `AnswerRequiresRegen`.

### 4.6. خدمة الإشعارات (Node.js)

* تستمع إلى `AnswerDrafted`، `AnswerFinalized`، `AnswerRequiresRegen`.  
* تُنسّق كتل Slack، بطاقات Teams المتكيفة، أو قوالب بريد إلكتروني.  
* تدعم **إلغاء التكرار** – تُرسل إشعارًا واحدًا فقط للتغيير لكل استبيان.

---

## 5. الأمان والحوكمة

| القلق | التدابير |
|-------|----------|
| **تسرب البيانات** – قد يحتوي موجه LLM نصًا حساسًا. | استخدم **استدلال LLM داخل بيئة خاصة** (مثلاً Llama 3.2) داخل VPC. اخفِ البيانات الشخصية قبل إرسالها إلى واجهات برمجة تطبيقات خارجية. |
| **وصول غير مصرح به إلى الأدلة** | فرض سياسات ACL دقيقة باستخدام OPA في خدمة الأدلة. |
| **انجراف النموذج** – تتدهور جودة الإجابات مع الوقت. | جدولة **تقييم دوري** ضد مجموعة اختبار معيارية وإعادة تدريب القوالب. |
| **قابلية التدقيق** | كل تحول حالة يُسجَّل في سجل أحداث غير قابل للتعديل مخزن على **WORM S3**. |
| **الامتثال ل GDPR/CCPA** | تنفيذ سير عمل **الحق في النسيان** الذي يحذف الأدلة الخاصة بالمستخدم من قاعدة المتجهات ومخزن الكائنات ([GDPR](https://gdpr.eu/)). |
| **الامتثال لـ ISO 27001** | التحقق من أن سياسات الاحتفاظ، والتشفير، وضوابط الوصول تتماشى مع معيار ISO 27001. |
| **HIPAA / SOC 2** | توسيع قواعد OPA لتفرض الضمانات المطلوبة لهذه الأطر. |

---

## 6. استراتيجيات التوسع

1. **توسيع الأفقي للبودات (HPA)** – توسيع بودات تنسيق الذكاء الاصطناعي بناءً على استهلاك GPU (`nvidia.com/gpu`).  
2. **قوائم الانتظار القابلة للانفجار** – استخدم تقسيم Kafka لعزل المستأجرين عاليي الحركة.  
3. **تقليل بدء بارد** – حافظ على مجموعة من الحاويات الدافئة لخادم استدلال LLM (مثلاً باستخدام **KEDA** مع مقيِّس مخصص).  
4. **ضوابط التكلفة** – تطبيق **ميزانية رمزية** لكل مستأجر؛ حدّ أو فرض رسوم تلقائيًا عند تجاوز الاستخدام.

---

## 7. الرصد والتحسين المستمر

* **التتبع الموزع** – OpenTelemetry يمتد من طلب الواجهة → بوابة API → تنسيق الذكاء الاصطناعي → RAG → خدمة الأدلة.  
* **المقاييس** – `answer_draft_latency_seconds`، `evidence_upload_bytes`، `llm_token_usage`.  
* **تجميع السجلات** – سجلات JSON منسقة مع `request_id` تُنقل عبر جميع الخدمات.  
* **دورة التغذية الراجعة** – بعد اعتماد الإجابة، التقط تعليقات المراجع (`review_score`). استخدمها لتدريب نموذج **تعزيز التعلم** يضبط درجة الحرارة أو يختار مصادر أدلة بديلة.

---

## 8. مسار الهجرة خطوة بخطوة للفرق الحالية

| المرحلة | الهدف | الأنشطة |
|--------|-------|----------|
| **0 – الاكتشاف** | رسم خريطة سير عمل الاستبيان الحالي. | حصر مصادر البيانات، تعريف تصنيف الضوابط. |
| **1 – بناء الأساسات** | نشر بوابة API، المصادقة، والخدمات الأساسية. | حاوية `questionnaire-service` و `evidence-service`. |
| **2 – إدخال الذكاء الاصطناعي** | تشغيل RAG على استبيان تجريبي. | استخدام LLM تجريبي، التحقق يدويًا من المسودات. |
| **3 – أتمتة الحدث** | ربط خط كشف التغييرات. | تمكين إعادة توليد تلقائي عند تحديث الأدلة. |
| **4 – صقل الحوكمة** | إضافة سياسات OPA، سجلات تدقيق غير قابلة للتعديل. | الانتقال إلى LLM داخل المؤسسة. |
| **5 – توسيع وتحسين** | توسيع البودات على GPU، تطبيق ضوابط التكلفة. | نشر مجموعة الرصد، تحديد مقاييس الخدمة (SLO). |

من خلال اعتماد معمارية الخدمات المصغرة القابلة للتكوين بشكل تدريجي، تتجنب الفرق مخاطر "القفزة الكبيرة" وتستفيد مبكرًا من العائد على الاستثمار (غالبًا ما يُحقق **خفضًا بنسبة 30‑50 ٪** في زمن الاستجابة للاستبيانات).

---

## 9. تجهيز المستقبل للمنصّة

* **التعلم المتماسك** – تدريب محولات خفيفة على بيانات كل مستأجر دون نقل الأدلة خارج الموقع، مما يعزز ملاءمة الإجابات مع احترام سيادة البيانات.  
* **شبكة خدمات صفرية الثقة** – استخدم **Istio** أو **Linkerd** مع TLS المتبادل لتأمين حركة المرور بين الخدمات.  
* **حوكمة دلالية** – مدّ محرك السياسات ليتحقق ليس فقط من محتوى الإجابة بل من **التشابه الدلالي** بين الأدلة ولغة التحكم.  
* **قابلية تتبع التوليد** – خزن درجة الحرارة، قيمة top‑p، وموجه النظام لكل إجابة لتفتيش الجنائية.

---

## 10. الخلاصة

تحوّل معمارية الخدمات المصغرة القابلة للتكوين أتمتة استبيانات الأمان من **مهمة يدوية مرهقة** إلى **محرك قابل للتوسيع، قابل للتدقيق، ويتحسن باستمرار**. من خلال فكّ المسؤوليات، الاستفادة من نماذج اللغة الكبيرة عبر طبقة RAG غير حالية، وربط كل ذلك بظهرية أحداث، يمكن للمؤسسات:

* الرد على تقييمات البائعين في دقائق بدلاً من أيام.  
* إبقاء أدلة الامتثال محدثة دائمًا بفضل كشف التغييرات الآلي.  
* تزويد المنظمين بسجل تدقيق واضح وغير قابل للتعديل.  

ابدأ صغيرًا، كرّر بسرعة، ودع فلسفة الخدمات المصغرة ترشدك نحو مستقبل يصبح فيه الامتثال **ميزة** وليس عائقًا.  

---

## راجع أيضًا

- [OPA Policy-as-Code للخدمات المصغرة](https://www.openpolicyagent.org/docs/latest/policy-language/)