perturber: خدمة تضم 68 تشويشًا نصيًا لاختبار متانة نماذج LLM

تبالغ تقييمات النماذج اللغوية على المعايير النظيفة (benchmarks) في تقدير متانتها. فالطلبات الحقيقية تصل مشوَّهة، وحتى التعديلات التي لا تغيّر المعنى تزحزح إجابات النموذج بانتظام. ويقترح مؤلفو الورقة البحثية arXiv:2610.12667 أداة للتحقق المنهجي من هذا الأثر. perturber خدمة بلا حالة (stateless)، وهي في الوقت نفسه مكتبة Python. تطبق الأداة في كل استدعاء تشويشًا واحدًا فقط يحافظ على المعنى، من كتالوجها الخاص الذي يضم 68 تشويشًا في 11 عائلة.

المشكلة: التشويشات مرتبطة بمنظومة برمجية تابعة لطرف آخر

تتطلب الدراسة المنهجية للمتانة ثلاثة أمور. أولها أن تُطبَّق التشويشات واحدًا تلو الآخر. وثانيها أن تكون النتيجة قابلة للتكرار. وثالثها أن يخرج النص نفسه على أي جهاز وفي أي بيئة. وبحسب المؤلفين، فإن الأدوات القائمة تكون عادةً مدمجة في منظومة قياس أداء (benchmarking) بعينها، ولا تُقدَّم كطبقة تحويلات مستقلة. ولأخذ تشويش واحد من هذه الأدوات، يضطر المرء إلى جلب الإطار (framework) بأكمله معه. ويصعب كذلك مقارنة نتائج فرق مختلفة، إذ لا يُعرف ما إذا كان التحويل قد عمل لديها بالطريقة نفسها.

يُخرج perturber هذه الطبقة إلى الخارج. فهو لا يعرف شيئًا عن النماذج ولا عن المقاييس ولا عن مجموعات البيانات. يتلقى نصًا واسم التشويش، ويعيد النص بعد تعديله.

استدعاء واحد، وحدة بناء واحدة

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

أبرز مواصفات الأداة:

• 68 تشويشًا من تطوير المؤلفين أنفسهم (first-party)، دون اعتماد خارجي على كتالوجات الآخرين؛
• 11 عائلة من التشويشات؛
• تشويش واحد فقط في كل استدعاء، مع إجراء الجمع بين التشويشات في جانب العميل؛
• صيغة التوزيع: خدمة stateless ومكتبة Python بمخرجات متطابقة؛
• العرض التوضيحي: بيئة تجريبية (sandbox) حيّة، وكتالوج يتيح الاستكشاف الذاتي (introspection) لاختيار ما يناسب معيارًا معينًا، وتقييم قابل للتكرار بأمر واحد.

يؤكد المؤلفون أنهم يختبرون الأداة نفسها لا نموذج أي جهة. ويقيسون الصحة وقابلية التكرار وتكلفة التشغيل. ويُقاس الحفاظ على المعنى لكل تشويش على حدة. ولا يسلّم المؤلفون بهذه الخاصية دون اختبار: فكل من جرّب إعادة الصياغة يعلم أن التعديل «المكافئ» قد يغيّر المهمة أحيانًا دون أن يلحظ أحد. ومن هنا نخلص إلى نتيجة عملية: التشويش الذي لا يجتاز هذا الاختبار يفسد الاستنتاج المتعلق بمتانة النموذج.

كيف يُستخدم ذلك عمليًا

يفيد الكتالوج القابل للاستكشاف الذاتي في اختيار التشويشات المناسبة لمعيار محدد. فبإمكان الفريق الذي يقيّم نموذجه أن يختار منه العائلات الملائمة لمجاله، وأن يشغّل كل واحدة منها بمعزل عن الأخرى. وتصبح المقارنة بين «المدخل النظيف والمدخل المشوَّه» أكثر نقاءً حين يُعرف أي تغيير بالتحديد أزاح الإجابة. وهذا مفيد أيضًا في اختبارات الانحدار (regression tests). فما دام الناتج حتميًا ولا يتأثر بالبيئة، يمكن إعادة توليد المجموعات المشوَّهة على CI دون الحاجة إلى حفظها كمخرجات (artifacts).

وثمة قيود أيضًا. فالملخص (annotation) لا يتضمن نتائج عن متانة أي نماذج، والأداة نفسها لا تعد بذلك. إنها لبنة بناء وليست ترتيبًا للنماذج. وستُختبر قيمتها بمدى استعداد الفرق لدمجها في خطوط عملها (pipelines)، وبمدى صدق قياسات الحفاظ على المعنى على بيانات حقيقية، بما في ذلك خارج اللغة الإنجليزية. أما من يبنون منصات التقييم، فالأفق واضح بالنسبة إليهم: طبقة تشويش مستقلة تتصرف بالطريقة نفسها في كل مكان تزيل على الأقل مصدرًا واحدًا من مصادر عدم اليقين في النتائج.