كيف يمكن لخمسة مستندات أن تكسر نظام RAG وتحوّل قاعدة المعرفة إلى قناة هجوم

كثيراً ما يُنظر إلى أنظمة RAG على أنها وسيلة لتقليل الهلوسة ودفع نماذج LLM إلى الاعتماد على مستندات الشركة. لكن إذا عُدّت قاعدة المعرفة موثوقة بحكم الافتراض، فقد تصبح هي بالذات القناة الأنسب لـ prompt injection والاستبدال الصامت للإجابات.

أين تكمن نقطة الضعف

المشكلة ليست في أن النموذج «يقرأ المستندات بشكل سيئ»، بل في أنه لا يميّز بين الوقائع والتعليمات كما يفعل الإنسان. فإذا دخلت إلى المخزن بضعة ملفات أُعدّت خصيصاً، يستطيع مستوى البحث في RAG أن يرفعها إلى السياق بشكل متكرر عند الاستعلامات ذات الصلة. بعد ذلك يرى LLM هذه المقتطفات جزءاً من بيئة العمل ويبدأ باتباع التعليمات الخفية: تجاهل system prompt، أو تغيير الأولويات، أو إدراج استنتاجات كاذبة، أو دفع الحوار في الاتجاه الذي يريده المهاجم.

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

لماذا تكفي خمسة مستندات

الخطر الرئيسي أن أمان RAG كثيراً ما يُبالَغ في تقديره بسبب الـ embeddings. يبدو وكأن البحث المتجهي يحوّل النصوص الأصلية إلى تجريد رياضي آمن، لكن الأمر ليس كذلك. فالـ embeddings تساعد على العثور على مقاطع متشابهة، لا على تحييد معناها. وإذا كُتبت خمسة مستندات بحيث تتطابق مع استعلامات المستخدمين الشائعة وتحتوي على تعليمات خبيثة في المواضع المناسبة، فسيُدرجها النظام في السياق مراراً وتكراراً. ولا يحتاج الهجوم إلى سيطرة كاملة على قاعدة المعرفة: فأحياناً تكفي بضع ملاحظات أو صفحات FAQ أو لوائح داخلية دخلت الفهرس دون فحص.

ويتضاعف الأثر بسبب آلية retrieval نفسها. فالنظام نادراً ما يمرّر المستند كاملاً إلى النموذج، بل يقطّعه عادةً إلى chunks ويختار بضع نتائج متصدّرة. وهذا يعني أن المهاجم ليس مضطراً إلى كتابة نص خبيث طويل: يكفيه زرع مقتطفات قصيرة لكنها «لاصقة» دلالياً، تظهر في نتائج top-k. وبذلك لا يحصل LLM على مرجع محايد، بل على مجموعة منتقاة من الإيحاءات المؤثرة، وقد لا يلاحظ مشغّل النظام لفترة طويلة أن الإجابات تنحرف نحو الاتجاه الذي تفرضه هذه المقتطفات.

ما الذي يجب حمايته

لا يمكن في بيئة الإنتاج حماية RAG بمرشّح واحد عند المدخل. المطلوب منظومة متعددة المستويات تفحص المستندات والـ chunks المستخرجة والإجابة النهائية للنموذج معاً. وإلا فقد ينقّي الفريق استعلام المستخدم لكنه يمرّر الـ injection نفسه الموجود في قاعدة المعرفة.

وثمة مشكلة مستقلة هي الهجمات «الصامتة»: لا ينهار النظام ولا يُصدر خطأً صريحاً، بل يبدأ ببساطة بنصح المستخدم بإجراءات خاطئة بثقة، أو يبدّل الأولويات، أو يكشف ما لم يكن ينبغي له كشفه.

• فحص المستندات قبل الفهرسة بحثاً عن تعليمات مخفية وأنماط مشبوهة
• عزل البيانات بحسب المصدر والدور ومستوى الثقة
• سياسات retrieval: حدود لهيمنة مصدر واحد وضبط لتنوّع المصادر
• ترشيح السياق قبل تمريره إلى LLM، مع guardrail مستقل للإجابة
• السجلات واختبارات red-team وإعادة تقييم الكوربوس بانتظام بعد كل تحديث

تُخفي سيناريوهات العرض التجريبي هذه المشكلة عادةً، لأن الكوربوس فيها صغير والمصادر معروفة سلفاً والاستعلامات متوقعة. أما في النظام الفعلي فالوضع مختلف: تُحمَّل المستندات على دفعات، وتُحدَّث دون مراجعة يدوية، وتأتي من أقسام مختلفة، وكثيراً ما تخلط بين الوقائع والنصائح والقوالب والتعليمات التشغيلية. وفي مثل هذه البيئة ينبغي تصميم RAG لا بوصفه «بحثاً + LLM»، بل بوصفه pipeline حسّاساً أمنياً، بمناطق ثقة واضحة وتدقيق للتغييرات وقواعد مستقلة لكل نوع من المحتوى.

ماذا يعني هذا

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