AWS Machine Learning

إعادة التفكير في التحكم في الوصول لـ RAG باستخدام Amazon Quick و Amazon Bedrock

يفتح RAG للمؤسسات الرؤى المستخلصة من مصادر المعرفة مثل SharePoint وGoogle Drive وConfluence، لكن هذه المصادر تحمل أذونات معقدة. تعرّف على كيفية فرض Amazon Quick و Amazon Bedrock Knowledge Bases لضوابط الوصول على مستوى…

Two-stage ACL enforcement architecture: pre-retrieval filtering then real-time verification against authoritative sources
مصدر الصورة · AWS Machine Learning

تتبنى المؤسسات تقنية الاسترجاع المعزز بالتوليد (RAG) لفتح الرؤى المستخلصة من مصادر المعرفة الشركة مثل Microsoft SharePoint وGoogle Drive وAtlassian Confluence. ومع ذلك، تحتوي مصادر المعرفة هذه على معلومات حساسة تحكمها هياكل أذونات معقدة. وضمان أن الإجابات المولدة بالذكاء الاصطناعي تحترم تلك الأذونات يُعد أحد أصعب التحديات في الذكاء الاصطناعي للمؤسسات.

في هذه المقالة، نستكشف كيف Amazon Quick و Amazon Bedrock Knowledge Bases يحلان هذا التحدي من خلال فرض قوائم التحكم في الوصول (ACL) في الوقت الفعلي، مع التحقق من الأذونات مباشرة مع المصادر الموثوقة عند وقت الاستعلام.

المشكلة التجارية

تخيل هذا السيناريو: ينشئ مالك موقع SharePoint قاعدة معرفية لمؤسسته. ويستخدم أعضاء الفريق عبر أقسام متعددة مساعد ذكاء اصطناعي للحصول على إجابات من هذه القاعدة المعرفية. والمتطلب الحرج هو أن يحصل كل عضو في الفريق فقط على الرؤى المولدة بالذكاء الاصطناعي من المستندات المصرح له بالوصول إليها.

هذا تحدٍّ عالمي للمؤسسات. ترغب المؤسسات في إضفاء الطابع الديمقراطي على الوصول إلى الرؤى المدعومة بالذكاء الاصطناعي دون المساس بوضعها الأمني القائم. فظهور مستند واحد غير مصرح به في استجابة من الذكاء الاصطناعي قد يكشف مستندات استراتيجية سرية أو بيانات مالية لم تُصدر بعد أو معلومات موارد بشرية حساسة.

لماذا تقصر النهج الحالية

يستخدم النهج الشائع للتحكم في الوصول لـ RAG أسلوب النسخ والتصفية لفرض الأذونات على مستوى المستندات. وإليك كيف يعمل عادةً:

  1. يسحب موصل مصدر بيانات (مثل موصل SharePoint) قوائم ACL كجزء من مهمة مزامنة دورية.
  2. تُنسخ قوائم ACL من مصدر البيانات وتُخزَّن كسمات في فهرس.
  3. عند وقت الاستعلام، يربط نظام الذكاء الاصطناعي المستخدم المسجَّل الدخول بسمات ACL المخزنة ويصفّي النتائج وفقًا لذلك.

ورغم أن هذا النهج يبدو معقولًا للوهلة الأولى، إلا أنه يعاني من ثلاث نقاط ضعف جوهرية.

المشكلة 1: نظام الذكاء الاصطناعي ليس مصدر الحقيقة

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

المشكلة 2: الأذونات القديمة تخلق ثغرات أمنية

بشكل عام، تدعم موصلات البيانات عمليات المزامنة القائمة على السحب التي تعمل عند الطلب أو وفق جدول يحدده العميل. وقوائم ACL في حلول الذكاء الاصطناعي هذه هي لقطة زمنية من وقت تشغيل آخر مزامنة. وتستخدم بعض الحلول التحديثات القائمة على الأحداث، لكن هذا لا يعمل بشكل شامل. على سبيل المثال، مصدر بيانات مثل Confluence لا يُصدر حدثًا عند تغيير عضوية المجموعة. وبين عمليات المزامنة، قد يستمر مستخدم سُحبت صلاحيات وصوله في تلقي إجابات من الذكاء الاصطناعي من مستندات لم يعد ينبغي له رؤيتها.

المشكلة 3: تطور قدرات مصادر البيانات

تغيّر مصادر البيانات باستمرار أو تقدّم آليات جديدة للتحكم في الوصول إلى المحتوى. فميزة أذونات جديدة في SharePoint أو تغيير في نموذج المشاركة في Google Drive قد يخلق فجوات في منطق تخطيط ACL. وقد يؤدي ذلك إلى كشف المحتوى حتى يتم تحديث الموصل.

كيف تحل AWS هذه المشكلة: فرض ACL في الوقت الفعلي

لمواجهة هذه التحديات، نفّذنا فحوصات ACL في الوقت الفعلي كطبقة أمان إضافية فوق التصفية الموجودة لـ ACL قبل الاسترجاع لـ Amazon Quick و Amazon Bedrock Knowledge Bases. ويضمن ذلك فرض النظام لأحدث ضوابط الوصول من خلال التحقق من الأذونات مباشرة مع المصدر الموثوق عند وقت الاستعلام. ويتجنب ذلك الاعتماد على بيانات ACL قد تكون قديمة أو مُخطِّطة بشكل خاطئ.

نظرة عامة على المعمارية

يوضح المخطط التالي نهجنا الهجين الذي يوفر أداء البحث الدلالي وقدرات الأمان في الوقت الفعلي معًا.

Two-stage ACL enforcement architecture: pre-retrieval filtering then real-time verification against authoritative sources

الشكل 1: معمارية فرض ACL في الوقت الفعلي لـ Amazon Quick و Amazon Bedrock Knowledge Bases، التي تجمع بين التصفية قبل الاسترجاع (المرحلة 1) والتحقق في الوقت الفعلي من المصادر الموثوقة (المرحلة 2)

كيف تعمل: مثال على Google Drive

عندما يقدّم المستخدم استعلامًا إلى وكيل Amazon Quick يستخدم قاعدة معرفية من Google Drive، يفرض النظام ضوابط الوصول على مرحلتين:

المرحلة 1: التصفية قبل الاسترجاع

يُجري Amazon Quick بحثًا دلاليًا على الفهرس المتجهي للعثور على مقاطع المستندات الأكثر صلة. يطبّق النظام قوائم التحكم في الوصول المخزّنة بالفعل في الفهرس. وينتج عن ذلك مجموعة أولية من المستندات المرشحة. هذه المرحلة ضرورية لأن إجراء استدعاءات API في الوقت الفعلي لكل مستند في الفهرس سيكون مكلفًا للغاية على نطاق واسع.

المرحلة 2: التحقق في الوقت الفعلي

يتحقق Amazon Quick من المستندات المرشحة في الوقت الفعلي عن طريق استدعاء واجهات Google Drive APIs. يستخدم بيانات اعتماد حساب الخدمة التي قدّمها المسؤول لتوليد رموز وصول خاصة بكل مستخدم من خلال الانتحال (impersonation). يحتفظ Google Drive بالمصدر الموثوق لقوائم التحكم في الوصول المرتبطة بكل مستند. ويُستبعد المستندات التي لا يُصرّح للمستخدم بالوصول إليها من مجموعة النتائج المستردة. وتُمرَّر فقط مقاطع المستندات الموثّق بها والمصرّح بها إلى النموذج اللغوي الكبير (LLM) كسياق. ويستخدم النموذج هذه المعرفة لتوليد استجابة.

يوازن هذا النهج المكون من مرحلتين بين الأداء والأمان. فهو يستخدم قوائم التحكم في الوصول (ACL) المخزنة مؤقتًا لتحقيق الكفاءة، بينما يضمن الصحة من خلال الفحوصات في الوقت الفعلي. بالإضافة إلى فرض قوائم ACL، توفر Amazon Bedrock ضوابط للذكاء الاصطناعي المسؤول. وتشمل هذه الضوابط Amazon Bedrock Guardrails لتصفية المحتوى، وفحوصات الارتكاز لتقليل الهلوسة، وسياسات أمان قابلة للتهيئة لمساعدة المؤسسات على نشر تطبيقات الذكاء الاصطناعي التوليدي بمسؤولية.

لماذا يهم هذا مؤسستك

يحقق هذا النهج ثلاث فوائد رئيسية:

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

ماذا يقول العملاء عن هذا

«عندما شرعنا في تقييم حلول الذكاء الاصطناعي لمؤسستنا، كانت فرق الأمان والامتثال لدينا واضحة بشأن أولويتها القصوى: ضمان أن الزملاء لن يروا أبدًا سوى المعلومات المصرح لهم بالوصول إليها. إنه مطلب أساسي، لكنه مطلب تعاني العديد من المنصات في معالجته بطريقة ذات معنى. وقد أجاب نهج Amazon Quick تجاه التحكم في الوصول في الوقت الفعلي على هذا السؤال بشكل قاطع، وأظهر مستوى من الصرامة برز خلال تقييمنا بأكمله. فقد منح مجلس المراجعة الداخلي لدينا الثقة للمضي قدمًا، وأرسى أساسًا قويًا لطريقة تفكيرنا في حوكمة الذكاء الاصطناعي مستقبلًا.»

— جماhl ويغينز، أخصائي أول – ابتكار M365، مونديليز إنترناشونال

لقد نشرت مونديليز إنترناشونال Amazon Quick لموظفيها البالغ عددهم أكثر من 35,000 موظف عبر أربع مناطق.

الخاتمة

تحدثنا في هذا المقال عن كيفية تنفيذ Amazon Quick وAmazon Bedrock Knowledge Bases لفرض قوائم ACL في الوقت الفعلي لحل تحدٍّ أمني بالغ الأهمية للمؤسسات. فبنية ACL ثنائية الطبقات تتحقق من الأذونات مباشرة مع المصادر الموثوقة وقت الاستعلام. وهذا يضمن أن الإجابات المولدة من الذكاء الاصطناعي تتضمن فقط المحتوى المصرح للمستخدم بالوصول إليه.

للبدء، قم بزيارة Amazon Quick و Amazon Bedrock Knowledge Bases.


نبذة عن المؤلفين

المصدر الأصلي

AWS Machine Learning

ملاحظات المحتوى

النشر الأصلي والحقوق تعود إلى المصدر.

ترجمة آلية · يُرجى الرجوع إلى الأصل