Written with AI assistance from the source video. The video is the authority.
Log in to leave a comment
No posts yet
إن تضمين وثائق الويكي الداخلية لإطلاق مساعد ذكاء اصطناعي داخلي هو أمر يمكن إنجازه في غضون نصف يوم. لكن المشكلة الحقيقية تنفجر صباح الاثنين التالي؛ عندما يسأل مطور متدرب في نافذة دردشة الذكاء الاصطناعي: "ما هي معايير حساب حوافز التنفيذيين لهذا العام؟"، فيعرض النظام الوثيقة السرية الخاصة بقسم المالية ملخصة بعناية فائقة.
إن مهندس البتفرم الذي قضى من 3 إلى 7 سنوات في بناء قاعدة المعرفة الداخلية يدرك هذه المشكلة فوراً. فمعظم هياكل RAG تقوم بتقسيم المستندات وتحويلها إلى متجهات تضمين (Embedding)، ثم تتخلص تماماً من نظام الصلاحيات الذي تمتلكه المستندات الأصلية. والسبب في ذلك هو أن قواعد التحكم في الوصول المرتبطة بـ Okta أو Azure AD تختفي تماماً داخل قاعدة بيانات المتجهات. إذا لم يتم إغلاق فجوة الصلاحيات هذه على مستوى خط أنابيب البنية التحتية بدلاً من كود التطبيق، فإن قاعدة المعرفة الخاصة ستتحول فعلياً إلى قناة لتسريب المعلومات الداخلية.
لا يمكن حل تناقض الصلاحيات بين نظام المصادقة الداخلي ومخزن المتجهات من خلال الاستعلامات في الوقت الفعلي، بل يجب حله عبر خط أنابيب مزامنة دورية لبيانات التعريف. فالطريقة التي تقوم باستدعاء واجهة برمجة تطبيقات IdP الداخلية للسؤال عن الصلاحيات مع كل استعلام تزيد من زمن انتقال البحث بأكثر من 200 مللي ثانية وتستنفد سريعاً حد الاستدعاء في الثانية (Rate Limit) لـ IdP.
يجب استخدام Airflow أو Celery لتشغيل دفعة تقوم كل ساعة بتحديث حقل مصفوفة بيانات التعريف لسجل المتجهات بقائمة المجموعات التي تمتلك المستند. وإذا أخذنا Qdrant كمثال، فيمكن وضع حقل allowed_groups في حمولة (Payload) كل جزء (Chunk)، ويتم إدراج معرف مجموعة Okta هنا مباشرة.
json { "chunk_id": "doc_9281_chunk_04", "text": "2026년도 하반기 서버 인프라 전환 예산안...", "allowed_groups": ["group_devops_lead", "group_finance_managers"] }
عندما تتغير صلاحيات المستند، يتم اكتشاف حدث تغيير المستند الأصلي وتحديث بيانات التعريف الخاصة بقاعدة بيانات المتجهات وحدها. ونظراً لعدم الحاجة إلى إعادة حساب التضمينات بالكامل، فلا توجد تكاليف حسابية إضافية. وعندما يطرح المستخدم سؤالاً، يتم حقن مطالبة groups المستخرجة من رمز JWT قسراً كمعلمة لمرشح البحث. ومن خلال وضع حاوية جانبية لـ Open Policy Agent (OPA) أمام قاعدة بيانات المتجهات، يمكن رفض الطلب نفسه على الفور بـ HTTP 403 عندما يفتقر الاستعلام المقدم من العميل إلى مرشح مجموعة التفويض الخاصة بالمستخدم. وفقاً لتقرير تدقيق صلاحيات RAG الذي نشرته مجموعة الأبحاث الأمنية Bishop Fox في سان فرانسيسكو عام 2024، فإن 78% من حوادث اختبار اختراق نماذج اللغة الكبيرة الداخلية حدثت بسبب تفويت مرشحات بيانات التعريف. إن فرض المرشحات عند بوابة البنية التحتية يمكن أن يوفر أكثر من 8 ساعات من العمل أسبوعياً التي كانت تنفق على فحص الصلاحيات اليدوي.
إذا تم السماح لمساعد الذكاء الاصطناعي بتلخيص المستندات الداخلية أو تحديث السياق تلقائياً، فسيتسد طابور الانتظار للموافقة سريعاً. وعندما تصل طلبات مراجعة الأمان إلى صندوق البريد الإلكتروني أو تذاكر قائمة الانتظار، فإنها تستغرق في المتوسط 72 ساعة حتى تتم مراجعتها. وإذا تم ترك هذا التأخير دون علاج، فسيرى المهندسون مساعد الذكاء الاصطناعي الداخلي يجيب بمواصفات واجهات برمجية قديمة تعود لعدة أشهر.
يجب التعامل مع الموافقة على المعرفة مثل نظام مراجعة الكود الداخلي عبر طلبات السحب (PR - Pull Request) في مستودع Git. وعندما يقترح وكيل الذكاء الاصطناعي تغييراً جديداً في المعرفة، يتم إنشاء فرع (Branch) على شكل ملف Markdown لإنشاء طلب سحب (PR).
من خلال قراءة ملف CODEOWNERS في جذر المستودع، يتم تعيين فريق الهندسة المسؤول عن مسار المستند المعدل تلقائياً.
`
/docs/architecture/payment/ @team-fintech-core
/docs/infrastructure/k8s/ @team-platform-infra
/docs/security/auth/ @team-infosec
`
يتم ربط خطاف الويب (Webhook) لطلب السحب الذي أنشأه الوكيل بقناة Slack المخصصة للفريق المسؤول لعرض الاختلافات (Diff) قبل وبعد التغيير مع زر الموافقة معاً. وعندما ينقر أحد أعضاء الفريق على زر الموافقة في Slack، تعمل واجهة برمجة تطبيقات GitHub لدمج الفرع، ويعمل خط أنابيب النشر فوراً لإعادة تضمين جزء المستند ذي الصلة فقط في قاعدة بيانات المتجهات. ومن خلال مطابقة تدفق تعديل قاعدة المعرفة مع دورة التطوير المعتادة، يمكن تقليل وقت اختناق الموافقة إلى أقل من 4 ساعات.
عند جمع مستندات البنية التحتية، غالباً ما يتم جلب مفاتيح وصول AWS أو سلاسل اتصال قاعدة بيانات التدريج التي وضعها المهندسون بطريق الخطأ كأمثلة للإعدادات. وإذا تم إرسال هذه البيانات كما هي إلى نموذج التضمين، فسست تبقى بيانات الاعتماد الداخلية في سجلات التخزين المؤقت لمزود نماذج اللغة الكبيرة الخارجي (SaaS)، وسيتم استغلالها بالكامل في هجمات حقن الأوامر التي تسرق سياق البحث المعزز. وفقاً لتحليل تسرب بيانات السحابة الذي أجراه معهد الأمن السيبراني Wiz في عام 2023، تم العثور على سلاسل بيانات اعتماد صالحة في حوالي 12% من المستندات الداخلية داخل بيئة المؤسسات.
يجب بالضرورة وضع وسيط وكيل تصفية يعتمد على التعبيرات المنتظمة (Regex) عالية السرعة عند البوابة الأولى لخط أنابيب التضمين. والهيكل المستقر هو تمرير النص عبر حاوية وكيل تعتمد على لغة Rust قبل تمريره إلى مكتبة tiktoken في لغة بايثون أو سكريبت التقسيم (Chunking).
`python
import re
PATTERNS = {
"AWS_KEY": r"(?<![A-Z0-9])[A-Z0-9]{20}(?![A-Z0-9])",
"BEARER_TOKEN": r"Bearer\s+[a-zA-Z0-9_-.=]+",
"SLACK_TOKEN": r"xox[baprs]-[0-9]{10,13}-[0-9]{10,13}-[a-zA-Z0-9]{24,32}",
"GENERIC_SECRET": r'(?i)(password|secret|api_key|access_token)\s*[:=]\s*["']?([^"'\s]+)["']?'
}
def scrub_sensitive_data(text: str) -> str:
cleaned = text
for name, pattern in PATTERNS.items():
cleaned = re.sub(pattern, f"[REDACTED_{name}]", cleaned)
return cleaned
`
إذا تم ربط هذه التصفية بإحكام أمام نموذج التضمين، فعندئذٍ حتى لو كتب مهندس البنية التحتية رمز الخادم الحقيقي بطريق الخطأ في ويكي الأصل، فلن يدخل إلى قاعدة بيانات المتجهات وسياق نموذج اللغة سوى سلسلة الحروف [REDACTED_SECRET]. إن الحفاظ على حالة تمنع حتى المستخدمين الذين لديهم صلاحيات من رؤية الأسرار إلا من خلال الوصول المباشر إلى مستودع GitHub الأصلي أو Vault هو الطريقة الوحيدة لمنع تهديدات تسرب بيانات الاعتماد على مستوى البنية التحتية.
