اختبارات الانحدار للتوجيهات في CI

في أنظمة LLM، سطرٌ واحد في التوجيه قد يغيّر سلوك النظام كله. ومع ذلك يُعدَّل عادةً بلا مراجعة ولا اختبار، ثم يُكتشف الانحدار من شكوى مستخدم بعد أسبوعين. الحلّ ليس اختراعًا جديدًا: عامِل التوجيه كما تعامل الكود.

المشكلة: النموذج غير حتميّ

الاختبارات التقليدية تقارن مخرجًا بمخرج متوقّع. هنا الصياغة تختلف بين تشغيلين، فالمقارنة الحرفية تنتج اختبارات هشّة تفشل بلا سبب حقيقي — وأسوأ ما في الاختبار الهشّ أن الفريق يتعلّم تجاهله.

الحلّ: اختبر الخصائص لا النصّ.

ثلاث طبقات، أسرعها أولًا

١) تحقّق برمجي (ثوانٍ، بلا تكلفة): المخرَج يطابق المخطط، ولا يحوي حقولًا مخترَعة، والاستشهادات تشير إلى مقاطع موجودة، وطول الجواب داخل الحدود. هذه تُشغَّل على كل دفعة.

٢) مقاييس استرجاع (سريعة، بلا نموذج): Recall@k وMRR على المجموعة الذهبية. تكشف انحدار التقطيع أو التضمين فورًا.

٣) حَكَم نموذجي (أبطأ، بتكلفة): الإخلاص وملاءمة الجواب. تُشغَّل على عيّنة ثابتة، أو على طلبات الدمج فقط لا على كل دفعة.

- name: تحقّق برمجي
  run: npm run test:contract          # كل دفعة

- name: مقاييس الاسترجاع
  run: python eval/retrieval.py --fail-under 0.82

- name: تقييم التوليد
  if: github.event_name == 'pull_request'
  run: python eval/generation.py --sample 50 --fail-under 0.80

عتبات لا أرقام مطلقة

اضبط العتبة عند «آخر رقم مقبول ناقص هامش صغير» بدل رقم طموح: الهدف كشف الانحدار لا فرض الكمال. وارفعها كلما تحسّن النظام واستقرّ — عتبة لا ترتفع أبدًا تفقد معناها.

ما الذي يستدعي التشغيل

• تعديل أي توجيه أو تعليمة نظام.
• تبديل النموذج أو ترقية إصداره.
• تغيير التقطيع أو نموذج التضمين أو معاملات الاسترجاع.
• ترقية مكتبة تمسّ السياق أو الأدوات.

الأخير هو الأخبث: ترقية صامتة تغيّر تنسيق السياق فيتغيّر السلوك بلا سطر واحد من تعديلك.

متى لا تحتاج هذه البوابة

• نموذج أوّلي لم يستقرّ شكله بعد: الاختبار سيقيس شيئًا سيتغيّر غدًا.
• مهمة تُقاس برمجيًّا كليًّا (تصنيف إلى فئات محدودة): اختبار وحدات عادي يكفي.
• حجم استخدام ضئيل لا يبرّر كلفة تقييم مستمرّ — أبقِ الطبقة الأولى وحدها.

ماذا تفعل حين تسقط البوابة

البوابة التي تُتجاوَز عند أول إزعاج لم تعد بوابة. اتّفقوا على المسار قبل أول سقوط:

1. أعد التشغيل مرّة واحدة. إن نجح، فالسبب تذبذب لا انحدار — لكن سجّل الحادثة: تكرارها يعني أن عتبتك ضيّقة أو أن مثالك هشّ.
2. إن سقط مرّتين، اقرأ أيّ الأمثلة سقطت لا كم مثالًا. سقوط ثلاثة أمثلة تخصّ نوعًا واحدًا من الأسئلة إشارة مختلفة تمامًا عن سقوط ثلاثة متفرّقة.
3. صنّف السقوط في واحد من ثلاثة: انحدار حقيقي يُصلَح، أو مثال قديم لم يعد يمثّل السلوك المطلوب فيُحدَّث بموافقة، أو عتبة خاطئة تُعاد معايرتها بقرار موثّق.
4. لا تتجاوز البوابة إلّا بموافقة معلَنة تُكتب في وصف الدمج: من وافق، ولماذا، ومتى يُراجَع القرار. التجاوز الصامت يتحوّل إلى عادة خلال أسبوعين.

وقاعدة تمنع أكثر الجدل: تحديث الأمثلة المرجعية يُراجَع كما تُراجَع الشيفرة. تغيير التوقّع ليقبل المخرَج الجديد قرار تحريري، لا تعديلًا فنيًّا يمرّ دون نظر.

الأخطاء الشائعة

1. مقارنة نصوص حرفيًّا فتصير الاختبارات هشّة.
2. تشغيل الحَكَم على كل دفعة، فترتفع الكلفة ويبطؤ الفريق.
3. عتبة صارمة تُعطّل الفريق فيُلغى الاختبار كله.
4. تجاهل تكلفة التقييم نفسها في الحساب.
5. اختبار الجودة بلا اختبار الامتناع — نصف السلوك المطلوب.

الأسئلة الشائعة

كيف أتعامل مع تفاوت النتائج بين التشغيلات؟

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

أين أحفظ التوجيهات؟

في المستودع كملفات مستقلّة بأرقام إصدار، لا مضمّنة داخل الكود ولا في قاعدة بيانات. عندها يظهر تغييرها في المراجعة، ويمكن ربط كل نتيجة تقييم بإصدار محدّد.

كم تكلّف هذه البوابة؟

الطبقتان الأوليان شبه مجانيتين. الحَكَم النموذجي على ٥٠ حالة في كل طلب دمج كلفة زهيدة مقابل انحدار يصل إلى المستخدم.

المراجع

1. Zheng, L. et al. Judging LLM-as-a-Judge with MT-Bench. arXiv:2306.05685
2. Es, S. et al. RAGAS. arXiv:2309.15217
3. NIST. AI Risk Management Framework (AI RMF 1.0). nist.gov
4. Thakur, N. et al. BEIR. arXiv:2104.08663