اختبار الموجّهات

لماذا يهم

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

أما للمختبِر، فاختبار الموجّهات يحوّل عبارة «يبدو الموجّه الجديد أفضل» إلى دليل: أي الحالات تحسّنت، وأيها انكسرت، وعلى أي نموذج وإصدار موجّه. كما يجعل إعادة إنتاج عيوب LLM أسهل، لأن التقرير الذي يذكر إصدار الموجّه والنموذج والمدخل يمكن إعادة تشغيله.

ما الذي يخضع للاختبار بالضبط

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

وكل تعليمة شرط اختبار (Test condition): اكتب حالة يكون اتباعها فيها مطلوباً، وأخرى يجعل فيها مستخدم عادي اتباعها صعباً. والأقسام والحدود وقواعد القرار من تصميم الاختبار ما زالت صالحة هنا.

• موجّه النظام: الدور والنطاق والقواعد والنبرة وصيغة المخرجات.
• القالب ومتغيراته، مثل {customer_name}، التي تُملأ وقت التشغيل؛ فاختبرها فارغةً وطويلةً جداً وبأنظمة كتابة أخرى.
• الأمثلة المضمَّنة (Few-shot examples)، أي مدخلات نموذجية مع إجاباتها المثالية تُكتب في الموجّه لتوضيح المطلوب: تغييرها أو إعادة ترتيبها تغيير في الموجّه.
• معرّف النموذج ومعاملاته مثل درجة الحرارة (Temperature): فالنص نفسه قد يتصرف بشكل مختلف مع إصدار آخر من النموذج أو إعدادات أخرى.

بناء مجموعة اختبار من المدخلات

مجموعة اختبار الموجّه ملفٌ تُدار إصداراته ويضم حالات اختبار، لكل منها مدخل وقيم المتغيرات والتحققات التي يجب أن تجتازها كل إجابة مقبولة. وهي من مواد الاختبار (Testware): تُراجَع وتُحفظ في المستودع ولا تتغيّر إلا عن قصد. واحتفظ بجزء محجوز (Held-out) لا يُستخدم إلا لقبول الإصدار؛ فالموجّه الذي يُضبط حتى يجتاز حالات قبوله يبدو على الورق أفضل مما هو عليه.

استمدّ الحالات من عدة مصادر. والمقتطف أدناه بصيغة YAML لسهولة القراءة، وكثيراً ما تحفظ الفرق البنية نفسها بصيغة JSON Lines.

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

# support-set v7: 3 of its 40 cases
- id: DEL-004
  input: "متى يصل طلبي رقم 5521؟"
  vars: { order_status: shipped }
  checks: [valid_json, language_is_ar, mentions_order_5521]
- id: CMP-002
  input: "मेरी केतली टूटी हुई आई है"
  checks: [valid_json, language_is_hi, handoff_is_true]
  critical: true
- id: OOS-001
  input: "Can you book me a flight to Riyadh?"
  checks: [valid_json, declines_politely, no_invented_service]

جرّبها: مدقّق JSON Lines جرّبها: مولّد بيانات اختبار متعددة اللغات جرّبها: مولّد مجموعات بيانات Unicode

إدارة إصدارات الموجّهات

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

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

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

جرّبها: مقارنة النصوص (Diff)

انحدار الموجّه: قارن بخط الأساس حالةً بحالة

انحدار الموجّه (Prompt regression) حالةٌ نجحت مع الإصدار المقبول وتفشل مع الإصدار الجديد. وتكشفه بمقارنة الإصدار المرشّح بخط الأساس (Baseline): النتائج المحفوظة لآخر إصدار مقبول على مجموعة الاختبار والنموذج والمعاملات نفسها. ولا تصبح نتائج إصدار خطَّ الأساس الجديد إلا إذا قُبل. غيّر الموجّه وحده؛ فإن تغيّر النموذج معه فلن تعرف أي التغييرين سبّب الفرق.

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

• أُصلحت: فشلت مع خط الأساس وتنجح الآن؛ وهذا هو التحسين المقصود.
• انحدرت: نجحت سابقاً وتفشل الآن. الانحدار في حالة حرجة يمنع التغيير، وأي انحدار آخر يحتاج إلى فحص وقبول صريح من الفريق.
• ما زالت تفشل: فشلت مع الإصدارين؛ مشكلة معروفة لم يسببها هذا التغيير.
• ناجحة دون تغيير: نجحت مع الإصدارين. ومع ذلك اقرأ عيّنة منها جنباً إلى جنب، فقد تنحرف النبرة أو المحتوى بينما تنجح التحققات.

جرّبها: مقارنة JSON جرّبها: مدقّق JSON Schema

مثال تطبيقي: إجابة أقصر كسرت حالتين

الإصدار v3 من موجّه مساعد الدعم هو خط الأساس. وجد العملاء إجاباته طويلة، فأضاف v4: «اجعل كل إجابة أقل من ⁦60⁩ كلمة». يُشغَّل الإصداران على support-set v7 (⁦40⁩ حالة) على النموذج نفسه بإصدار مثبَّت، بخمسة تشغيلات لكل حالة؛ وتنجح الحالة إذا اجتازت كل تحققاتها في ⁦4⁩ تشغيلات على الأقل، والحالات الحرجة في الخمسة كلها.

يرتفع عدد الحالات الناجحة من ⁦34⁩ إلى ⁦37⁩، وهذا يبدو تحسّناً. لكن حالةً بحالة: أُصلحت خمس حالات إسهاب، غير أن RET-012 صارت تُسقط شرط الإرجاع خلال ثلاثين يوماً، والحالة الحرجة CMP-002 لم تعد تحوّل شكوى المنتج التالف إلى موظف بشري في تشغيلين من خمسة؛ وتُظهر مقارنة نصّي إجابتي RET-012 الجملة الناقصة. والانحدار في الحالة الحرجة يمنع v4. فيكتب الفريق v5: «اجعل كل إجابة أقل من ⁦60⁩ كلمة، لكن اذكر شروط السياسة دائماً ولا تتخطَّ التحويل إلى موظف أبداً»، ثم يعيد تشغيل المجموعة كاملةً.

Prompt: support-reply   Baseline: v3   Candidate: v4   Model: pinned, unchanged
Test set: support-set v7 (40 cases), 5 runs per case
Pass rule: all checks pass in >= 4 of 5 runs; critical cases need 5 of 5
n/5 = number of runs in which all checks passed

Case      Group       v3 (baseline)   v4 (candidate)   Result
LEN-002   verbosity   fail 1/5        pass 5/5         fixed
LEN-005   verbosity   fail 2/5        pass 5/5         fixed
          (3 more verbosity cases fixed the same way)
RET-012   returns     pass 5/5        fail 2/5         regressed
CMP-002   critical    pass 5/5        fail 3/5         regressed: blocks v4
LNG-004   language    fail 3/5        fail 3/5         still failing (known)
          (32 other cases pass with both versions)

Passing cases         34 / 40         37 / 40

جرّبها: مقارنة النصوص (Diff)

أسئلة شائعة

المراجع

• Define success criteria and build evaluationsAnthropicإرشادات مزوّد نماذج لكتابة معايير نجاح قابلة للقياس ومجموعات تقييم تُصحَّح بالكود أو بالمطابقة التامة أو بنموذج.
• Working with evalsOpenAIإرشادات مزوّد نماذج لاختبار مخرجات النموذج مقابل معايير ومجموعات بيانات محددة، وإعادة تشغيل التقييمات مع تغيّر الموجّهات والنماذج.
• ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023المنهج التأسيسي لاختبار البرمجيات: مستويات الاختبار وأنواعه وتقنيات تصميم الاختبارات وإدارة الاختبار والأدوات.