الفصل 8 — إخفاء الهوية في خط RAG
المقالة الثامنة من الجولة الفصلية في LLM Primer III: Enhancing Enterprise AI with RAG. هل تُخفى هوية البيانات قبل أن يَراها النموذج، أم قبل أن يَرى المستخدمُ المَخرَج؟ الإجابة تُغير كل شيءٍ في الخط، والنظام التنظيمي يَختار الإجابة لك عادةً.
لماذا يوجد هذا الفصل
أَجاب الفصل 7 من يَستطيع رؤية ماذا. افترض أن هناك شيئاً يُمكن تَقييده. لكن الفصل 6 أَظهر أيضاً أن التضمين ليس دالَّة أحادية — مخزنُ الشعاع نسخةٌ ضبابية من المصدر، وضوابط الوصول هي الطبقة الخارجية فقط. إذا كانت المكتبة تَحتوي أرقام ضمانٍ اجتماعي، مدخلات سجلٍّ طبي، أسماء عملاء، أو مسارات شيفرة ملكية، فالسؤال لم يَعُد فقط من يَجوز له استرجاعها. هو ما إذا كان ينبغي تَضمينها بذلك الشكل أصلاً.
ذلك سؤال إخفاء الهوية، وهو قرارٌ أمني هندسي ثقيلٌ في نشر RAG. الخيار موقعي قبل أن يكون خوارزمياً: عند أيِّ مرحلةٍ يُحوَّل المحتوى الحساس؟
8.1 ما قبل التوليد مقابل ما بعد التوليد
إخفاء الهوية ما قبل التوليد يُحوِّل البيانات قبل تَضمينها وتَخزينها. لا يَحوي مخزن الشعاع القيم الحساسة الأصلية أبداً؛ حتى اختراقٌ كامل على طبقة النموذج لا يَستخرج ما لم يَكن موجوداً قط. هي البنية المُكلَّفة لكثيرٍ من RAG الطبي تحت HIPAA وعدةٍ من التطبيقات القانونية المُلتزمة بـ GDPR. الكلفة جودة الاسترجاع: يقول الاستعلام «Acme Corp» لكن المكتبة قالت «[ORG_47]» قبل التضمين، وتَنخفض التشابه الكثيف على أكثر الرموز إخباراً.
إخفاء الهوية ما بعد التوليد يَعمل على مَخرَج النموذج. تُحفَظ جودة الاسترجاع؛ ضمانة الخصوصية أضعف لأن البيانات الحساسة في الفهرس. هو ملائمٌ حين يكون نموذج التهديد تَسريباً يُواجه المستخدم لا تَسريباً يُواجه البنية التحتية. وتَنتهي مُعظم أنظمة الإنتاج باستخدام هجين — مُعرِّفات مباشرة وفئاتٌ تنظيمية عالية الوزن تُعالَج ما قبل التوليد، وحساسياتٌ تشغيلية أَخفض وزناً تُعتَّم عند المَخرَج بحسب ملف تَفويض المستخدم. انضباطان تنفيذيان يَهمان: شغِّل إخفاء الهوية قبل التقطيع (وإلا يُدمِّر المُقطِّع السياقَ الذي يَحتاجه الكاشف)، واحتفظ بخزينة فك ترميز جدولَ تَخطيطٍ منفصلاً مُتحكَّماً بالوصول بحيث يَستطيع طبيبٌ بالدور الصحيح أن يرى معرِّف المريض الذي عَتَّمه الفهرس.
8.2 التعتيم، الاستبدال التَّوليفي، الخصوصية التَّفاضلية
تَنقسم التقنيات إلى ثلاث عائلاتٍ على مقبضٍ واحد. تَعتيم PII يَكشف الكيانات (Microsoft Presidio هو التطبيق المفتوح المصدر الأوسع نَشراً) ويَستبدلها بعناصر نائبة. المشكلات الصعبة هي الاستدعاء — كاشفٌ يُفوِّت عشرة بالمئة من الأسماء يُنتج وثائق مُعتَّمة يَستطيع مُهاجمٌ تَحديد موقعها عبر تشابه التضمين — والتعتيم الزائد، الذي يُقلِّص المفردات ويُؤذي الاسترجاع. الانضباط قياسٌ مُزدوج: استدعاء على مجموعة موسومة ومعيار جودة استرجاعٍ خارج الخط.
الاستبدال التَّوليفي يَستبدل قيمةً مزيفة معقولة بدلاً من عنصر نائب، فيَصير «John Smith» «Alex Romano» بدلاً من [NAME]. يَبقى التضمين موزَّعاً حسناً ويَقرأ طبيعياً للنموذج. التَّخطيط حتمي — تَجزئةٌ مُفتاحية من الكيان الحقيقي إلى المزيف — فيَحصل الكيان الحقيقي نفسه على المزيف نفسه عبر المكتبة، ويَقطن المفتاح في الخزينة. الاستبدال التَّوليفي لا يزال يُسرِّب ضد خصمٍ بمعلوماتٍ مساعدة، لكنه تَحسينٌ ذو معنىً عن التعتيم حين تَهم جودة الاسترجاع.
الخصوصية التَّفاضلية هي العائلة التي تُقدِّم ضمانةً رياضية فعلية — آليةٌ هي ε-DP إذا تَغير توزيع المَخرَج بمعاملٍ أقصاه exp(ε) حين يُضاف سجلٌّ أو يُحذف. DP-Prompt يُشوِّش القِطع المُختارة للموجِّه؛ DP-MLM يُشوِّش تَمرير تضمين النموذج اللغوي المُعتَّم؛ 1-Diffractor يَجمع DP مع إعادة صياغةٍ تَحفظ الدلالة. DP ميزانية، لا مُفتاح — كل استعلامٍ يَصرف منها، والانضباط التشغيلي محاسبة ميزانيةٍ بالأساس. تَتركَّب العائلات الثلاث، والنشرة الصحيحة عادةً تُكدِّسها.
8.3 مُقايضة المنفعة-الخصوصية
الرموز الأَولى بإخفاء الهوية هي الرموز التي يُؤذي إخفاء هويتها الاسترجاعَ أكثر. التَّضارب مؤسف لكنه غير قابلٍ للتفاوض. التَّخفيفات جزئية: الاستبدال التَّوليفي يَحفظ إشارةً أكثر من العناصر النائبة؛ والعناصر النائبة المُوسَّمة بالنوع ([PERSON named Alex] بدل [PERSON]) تَحفظ أكثر، بكلفة تَعتيمٍ أضعف. مكتبات إخفاء الهوية كثيراً ما تُريد قِطعاً أكبر بقليلٍ من غير المُخفاة، لأن خسارة العَتم تُستهلَك على محتوىً ناجٍ أكثر.
الصياغة الصادقة أن المُقايضة ليست مقبضاً وحيد المحور بل سطح ثنائي البُعد — أرضية تنظيمية تَحتها يكون النظام غير قانوني، أرضية منفعةٍ تَحتها يَهجره المستخدمون، ومنطقة عمل بينهما. أحياناً الفجوة واسعة وكثيرٌ من التَّصاميم تَعمل. وأحياناً الفجوة فارغة: الأرضية التنظيمية فوق أرضية المنفعة، وأَنفع شيءٍ تَستطيع مرحلة التصميم فعلَه أن تُدرك ذلك قبل غَرق الجهد في نظامٍ لا يُمكن بناؤه.
8.4 التكامل المؤسسي واختيار تصميم
يَكشف Zilliz Cloud إخفاء الهوية تَحويل خطٍّ بين المُحلِّل والمُضمِّن، مع خطافاتٍ عند أربع نقاط فحص (استيعاب، استرجاع، فك ترميز، مَخرَج). PII Masker يَأخذ الشكل المعاكس — كتلةُ بناءٍ مُركَّزة يُرتِّبها الفرق في خطوطها الخاصة. النشرات الناضجة كثيراً ما تَبني خدمة إخفاء هويةٍ مركزية بأربع عمليات: أَخفِ هوية وثيقةٍ مُحلَّلة، ابحث عن فك ترميزٍ تحت سياق تَفويض، افحص سلسلة مَخرَجٍ بحثاً عن محتوىً حساس مُتبَق، وأَبلغ عن ميزانية الخصوصية المُستهلَكة.
قرار التصميم يَبدأ من التنظيم، لا الخوارزمية. يُخرَّط HIPAA Safe Harbor بنظافةٍ على تَعتيم PII مع قائمة فئاتٍ ثابتة من ثماني عشرة. يُحقَّق PCI DSS بالترميز — استبدالٌ تَوليفي مع خزينة. يَدفع مبدأ تَقليل بيانات GDPR نحو ما قبل التوليد للفئات الأكثر حساسية. الخصوصية التَّفاضلية لا يَكلِّفها أيُّ تنظيمٍ كبير، لكنها الإجابة الصحيحة حين يَشمل نموذج التهديد خصماً مُتطوراً ببياناتٍ مساعدة وتَحوي المكتبة سجلاتٍ سيكون يُمكن الإبلاغ عنها تنظيمياً لو أُعيد التعريف.
ما يُمهِّد له الفصل 8
الفصلان 7 و8 معاً يُكملان الجزء الرابع. تُجيب ضوابط الوصول من يَستطيع رؤية ماذا؛ ويُجيب إخفاء الهوية ما يوجد لرؤيته أصلاً. كلاهما قراراتُ بنيةٍ تَحتية على بقية الخط احترامها، وكلاهما يَعتمد على خياراتٍ اتُّخذت في وقت التحليل والتقطيع لا يُمكن عكسها رخيصاً لاحقاً. مع تَصميم النظام وتَأمينه، السؤال التالي هو ما إذا كان يَعمل — ويَتطلب ذلك طريقةً لقياسه.
التالي — الفصل 9: ثلاثية تقييم RAG. ملاءمة السياق، الإسناد، وملاءمة الإجابة — ثلاث إشاراتٍ مستقلة تُخبر المُشغِّل معاً ما إذا كان النظام يَفشل في الاسترجاع، في التوليد، أو في الصلة بينهما.
