الفصل 7 — تطبيق ضوابط الوصول
المقالة السابعة من الجولة الفصلية في LLM Primer III: Enhancing Enterprise AI with RAG. نماذج الأذونات المُصمَّمة لقواعد البيانات العلائقية وأنظمة الملفات لا تُلائم الاسترجاع تماماً. لم تَعُد وحدة الوصول صفاً أو ملفاً بل تضميناً — والتضمين يُمكن أن يُسرِّب الأصل عبر التشابه حتى حين تَكون الوثيقة نفسها مُقيَّدة.
لماذا يوجد هذا الفصل
أَنتج الفصل 6 نموذج التهديد. أهمُّ ضابطٍ يَستلزمه — والذي تُخطئه مُعظم أنظمة الإنتاج المبكرة — هو ضبط الوصول عند طبقة الاسترجاع، بحيث لا يَرى LLM محتوىً لا يَستطيع المستخدم رؤيته. البديل الساذج، «رَشِّح عند التوليد»، يَبني نائباً مُلتبساً: قد قرأ النموذج الوثائق المُقيَّدة بالفعل وسيُسرِّب جوهرها عبر إعادة الصياغة.
يَسلك هذا الفصل الآلياتِ الأربع التي تَتركَّب في مَكدِّس ضبط وصولٍ يَعمل — ACL على مستوى الوثيقة بوصفها الأساس، RBAC مُدمَجة مع تسميات الحساسية القائمة للمؤسسة، ReBAC للواقع المُشكَّل علاقاتياً لمعرفة المؤسسة، وانضباط التَّرشيح المُسبق مقابل اللاحق الذي يَجري تَحتها جميعاً.
7.1 ACL على مستوى الوثيقة وتَرشيح البيانات الوصفية
كل قطعةٍ تَعرف من يُسمح له برؤيتها. التنفيذ مباشرٌ في الوصف؛ وأنماط الفشل دقيقةٌ بما يَكفي ليُخطئها كل نظام إنتاجٍ مبكر مرةً على الأقل. ثلاث تفاصيل تَهم أكثر. الحُبيبية: قد يَحتوي تقريرٌ طويل ملخصاً عاماً وملحقاً سرياً، وACL مُوحَّد على مستوى الوثيقة يُنسَخ بالتساوي إلى القِطع إما يَكشف الملحق فوق الحد أو يَكتم الملخص دون الحد. النمط الذي يَتسع هو حَمل أذوناتٍ على مستوى القسم عبر تحليلٍ واعٍ بالتخطيط.
الطزاجة: الأذونات تَتغير. خبزُ ACL في القطعة وقت الفهرسة وعدم إعادة تقييمه أبداً يُعطيك نظاماً يَكذب. خَزِّن معرِّفاً ثابتاً في بيانات القطعة الوصفية وحَلَّ ACL الحية مقابل النظام المصدري وقت الاستعلام، خلف ذاكرة تَخزينٍ قصيرة العمر. الفضاء السلبي: إذا كانت الإجابة تَعيش في وثيقةٍ مُقيَّدة، فلا ينبغي للنظام أن يُهلوس ولا أن يقول بثقةٍ «لا أعرف» — ينبغي أن يقول «هناك مادةٌ عن هذا الموضوع لست مُخوَّلاً لرؤيتها». يَتطلب ذلك إما استدعاءً ثانياً غير مُرشَّح أو قاعدة بياناتٍ شعاعية تُمَيِّز «لا تَطابق» عن «طُوبق ثم رُشِّح»، ومُعظم التنفيذات تُؤجِّل.
7.2 RBAC وتسميات حساسية Microsoft Purview
تَضغط RBAC فضاء الأذونات — بدلاً من ملايين الحواف من المستخدم إلى الوثيقة، تُختزل السياسة إلى بضع مئاتٍ من الحواف من الدور إلى التصنيف، وهو قابلٌ للتدقيق والصيانة معاً. تُلائم RAG بنظافةٍ حين تَعمل المؤسسة عليها أصلاً. في بيئات Microsoft يَعني ذلك مجموعات Entra ID وتسميات حساسية Purview: عام، عمومي، سري، سري للغاية، مع تسمياتٍ فرعية اختيارية. تَتحرك التسمية مع الوثيقة؛ يَقرؤها المُحلِّل وقت الفهرسة ويَكتب معرِّف التسمية الثابت في بيانات القطعة الوصفية.
التكامل مباشر، الانجراف ليس كذلك. إذا كان المُفهرس يَعمل بوصفه حساب خدمةٍ يُمكنه فك تَشفير كل شيء، لكن نظام الاسترجاع يَفرض مُرشِّحاً قائماً على الدور فوق الفهرس، فإن وثيقةً أُعيد تَسميتها من عمومي إلى سري لن تُعاد تَسمية قِطعها المُفهرَسة بالفعل ما لم يُلاحظ المُفهرس التغيير. الأنظمة التي تَفعل هذا صحيحاً تُشغِّل مُطابقةً مستمرة مع المصدر. والأنظمة التي تَفعله خطأً تَكتشف الانجراف خلال تَدقيقٍ رسمي، والاستنتاج فادح.
7.3 ReBAC مع Zanzibar وSpiceDB
RBAC لا تَستطيع التعبير عن «أيُّ شخصٍ في المبيعات مُكلَّفٌ أيضاً بصفقة Acme Corp». يَتطلب ذلك التَّعليل على علاقةٍ بين المستخدم والمَورد، لا على دورٍ فقط. ضبط الوصول القائم على العلاقة، الذي رُسمل في ورقة Zanzibar من Google ومتوفِّر مفتوح المصدر بوصفه SpiceDB وOpenFGA، يُخزِّن رسماً بيانياً: «أليس عضوٌ في الهندسة»، «الهندسة مُشاهِدٌ لمجلد المواصفات»، «المواصفة-101 في المواصفات». تَصير فحوصات الإذن اجتيازاتٍ للرسم البياني.
نمط التكامل مع RAG نظيف. يَتلقى SpiceDB السؤال أيُّ الوثائق يَستطيع هذا المستخدم مُشاهدتها؟ ويُعيد قائمة معرِّفات وثائق؛ يُمرر نظام الاسترجاع تلك القائمة مُرشِّحَ بياناتٍ وصفية إلى البحث الشعاعي. تَسمح زوكي Zanzibar لاستدعاء الاسترجاع بأن يُصرَّ على اتساقٍ حديثٍ على الأقل بقدر وصولٍ مَمنوحٍ حديثاً — مستخدمٌ أُضيف إلى مشروعٍ في الساعة 10:00 ويَسأل في 10:01 سيَرى الوثائق الجديدة. الكلفة التشغيلية أن SpiceDB يَصير اعتمادية مسار استعلامٍ حرجة تَحتاج HA وتَخزيناً مؤقتاً قصير العمر صارماً لقوائم وثائق كل مستخدم. الأنظمة الناضجة كثيراً ما تَستخدم RBAC وReBAC معاً — RBAC للسياسة الواسعة للحساسية، ReBAC للسياسة الدقيقة للعلاقة، مَدموجتَين كتقاطع المجموعات المسموح بها.
7.4 التَّرشيح المُسبق واللاحق والانضباط الذي يَجري تَحت كليهما
التَّرشيح المُسبق يُطبِّق مَحمول التفويض قبل البحث الشعاعي — يُقيِّد الفهرس مجموعة المرشَّحين أولاً، ثم يُشغِّل التشابه على القيد. هو نظيفٌ مفهومياً وأَأمن افتراضي، لكن أداءه يَتوقف على بنية الفهرس. HNSW مع مُرشِّحٍ شديد الانتقاء يُمكن أن يَنحدر بحدةٍ بينما يَمشي اجتياز الرسم البياني عبر كثيرٍ من العُقد غير المُطابقة؛ متغيرات HNSW القابلة للترشيح في Weaviate وQdrant ومساحات الأسماء لكل مُستأجر في Pinecone وMilvus تُخفِّف لكنها لا تَلغي الكلفة.
التَّرشيح اللاحق يَعكس الترتيب. سرعةُ HNSW الكاملة، أمنٌ أضعف: تَسريب أعلى-K، تَسريب المعلومات القائم على التَّوقيت، وتَسريب الصحة حين يُرشَّح كل أعلى-K بعيداً. الإجابة الإنتاجية البراغماتية هي تَطبيق كليهما — رَشِّح مُسبقاً على المَحمول الأخشن والأسرع (مُستأجر، دور واسع)، رَشِّح لاحقاً على المَحمولات الدقيقة الغالية (قوائم SpiceDB، تسميات Purview)، واجلب زائداً أعلى-50 بدلاً من أعلى-10 بحيث يَترك المُرشِّح اللاحق مجموعةً مُرتَّبة كاملة. مَوضعان آخران يُسرِّبان: قالب الموجِّه الذي يَستشهد بعنوان وثيقةٍ سرية، وذاكرة التَّخزين المؤقت للاستجابة المُرتَّبة على سلسلة الاستعلام فقط. كلاهما لازمٌ أن يكون جزءاً من سطح التفويض.
ما يُمهِّد له الفصل 7
تُجيب ضوابط الوصول من يَستطيع رؤية ماذا. تَفترض أن هناك شيئاً يُمكن تَقييده. لا تَسأل ما إذا كانت القطعة كان ينبغي تَضمينها بالشكل الذي ضُمِّنت به — ما إذا كان ينبغي لأسماء العملاء وأرقام الضمان الاجتماعي ومسارات الشيفرة الملكية أن تَجلس في مخزن الشعاع أصلاً، مُنتظرةً التفويضَ الصحيح لإظهارها. ذلك سؤال إخفاء الهوية، وهو موضوع الفصل التالي.
التالي — الفصل 8: إخفاء الهوية في خط RAG. ما قبل التوليد مقابل ما بعد التوليد، التعتيم مقابل الاستبدال التَّوليفي مقابل الخصوصية التَّفاضلية، ومُقايضة المنفعة-الخصوصية التي يَجب أن يَتنقل بها كل خيار.
