كيفية اختبار برومبت الذكاء الاصطناعي: منهج عملي متقدم من V1 إلى V2

كتابة Prompt احترافي ليست نهاية المطاف في هندسة الأوامر؛ بل هي نقطة البداية الحقيقية للاختبار والقياس. قد يمنحك البرومبت نتيجة ممتازة مع مثال واحد، ثم يتراجع أداؤه فور تغير المدخلات أو ظهور حالات غير متوقعة. لذلك، فإن السؤال الأهم ليس «هل أعطاني الذكاء الاصطناعي إجابة جيدة؟»، بل «هل يحافظ هذا البرومبت على السلوك المتوقع والدقة عبر مختلف حالات الاستخدام؟». من خلال هذا الدليل الشامل، سنأخذك في رحلة منهجية لتحويل اختبار الأوامر إلى عملية ذكية وقابلة للتكرار وفق الآتي: V1 ← تحديد معايير النجاح ← حالات الاختبار ← تحليل الأخطاء ← V2 ← إعادة الاختبار ← المقارنة.

ما هو اختبار البرومبت؟

يُعرف اختبار البرومبت بأنه عملية منهجية لتشغيل أمر ذكاء اصطناعي (Prompt) عبر مجموعة متنوعة من المدخلات تُعرف بـ (Test Dataset)، ومقارنة المخرجات الفعلية بمعايير نجاح موضوعية مسبقًا. الهدف الجوهري ليس الحصول على مخرج مذهل لمرة واحدة، بل ضمان أداء موثوق ومستقر يتعامل بكفاءة مع الحالات الطبيعية، المعقدة، والحدية على حد سواء.

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

لماذا لا تكفي نتيجة واحدة جيدة؟

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

منهج V1 → الاختبار → V2 لاختبار البرومبت

يمكنك التعامل مع هندسة الأوامر كدورة حياة تطوير برمجيات مصغرة. ابدأ بنسخة أولية (V1)، ضع معايير دقيقة للنجاح، ابنِ حزمة اختبار شاملة (Test Dataset)، نفّذ التشغيل وسجّل النتائج، ثم حلل الأخطاء الكامنة وراء الفشل لتصميم النسخة (V2) التي تعالج تلك الثغرات، وأخيرًا أعد تشغيل نفس الاختبارات لمقارنة الأداء بدقة.

V1 ← تحديد معايير النجاح ← بناء Test Dataset ← تشغيل الاختبارات ← تسجيل النتائج ← تحليل الأخطاء ← تطوير V2 ← إعادة الاختبار ← المقارنة النهائية

الخطوة 1: ابدأ بالنسخة V1

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

استخرج اسم المنتج، السعر، الفئة، وحالة التوفر من النص التالي.

هذا النموذج أولي وقابل للاستخدام، لكنه يعاني من ضبابية في المعايير؛ فهو لا يحدد طريقة التعامل مع الحقول المفقودة، أو معالجة المنتجات المتعددة، أو هيكل الإخراج المطلوب. (تعريف أساسي: حالة الاختبار (Test Case) هي سيناريو فردي يحتوي على مدخل وسلوك متوقع، بينما مجموعة الاختبار (Test Dataset) هي مجموعة منظمة وشاملة من حالات الاختبار).

الخطوة 2: حدّد شكل النتيجة الناجحة (معايير الجودة التقنية)

عند تقييم المخرجات، خصوصاً في البرومبتات المتقدمة أو عند التعامل مع المخرجات المهيكلة، يجب أن نميز بدقة بين معايير الجودة التقنية التالية:

الخطوة 3: بناء Test Dataset لاختبار البرومبت

تختلف حالات الاختبار المناسبة باختلاف طبيعة المهمة، سواء كانت استخراج بيانات، أو تلخيصاً، أو تصنيفاً، أو توليد كود. لضمان تغطية شاملة، نبدأ عادة بخمس فئات أساسية من الحالات ضمن الـ Test Dataset:

مثال عملي متماسك: استخراج معلومات المنتجات بـ JSON Schema

لنفترض أننا نطلب مخرجات مهيكلة تطابق المخطط البرمجي (JSON Schema) التالي: json { "type": "object", "properties": { "products": { "type": "array", "items": { "type": "object", "properties": { "name": { "type": "string" }, "price": { "type": ["string", "null"] }, "category": { "type": ["string", "null"] }, "availability": { "type": ["string", "null"] } }, "required": ["name", "price", "category", "availability"], "additionalProperties": false } } }, "required": ["products"], "additionalProperties": false } (ملاحظة هامة: تم اختيار نوع string لحقل السعر والبيانات النصية بدلاً من number، لكي يتحمل النموذج رموز العملات مثل $699، أو النطاقات السعرية، أو القيم النصية المرنة عند اللزوم، بينما استخدام null عند غياب القيمة هو الخيار الأنظف دلالياً في Structured Outputs). سنطبق الآن حالات الاختبار الخمسة لتقييم النسخة V1:

الخطوة 4: تسجيل النتائج وتصنيف الأخطاء

بعد تشغيل V1، نسجل النتائج ونحدد أنواع الأخطاء بدقة. الجدول التالي يوضح مثالاً توضيحياً لنتائج V1 والخطأ المرصود في كل حالة:

الخطوة 5: تطوير النسخة V2 وعلاج الأسباب الجذرية

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

استخرج اسم المنتج، السعر، الفئة، وحالة التوفر من النص المقدم حصرياً بصيغة JSON تطابق الـ Schema المحددة بدقة.

القواعد الصارمة:
- استخدم فقط المعلومات المذكورة صراحة في الإدخال (Source-groundedness).
- إذا كانت أي قيمة مفقودة أو غير مؤكدة، ضع القيمة null تماماً ولا تخمن شيئاً.
- في حال وجود عدة منتجات، أنشئ عنصراً مستقلاً لكل منتج داخل مصفوفة products.
- لا تضف أي حقول أو مفاتيح خارج الـ Schema المحددة نهائياً (additionalProperties: false).
- لا تعتبر المنتج متاحاً إلا إذا نص المدخل على ذلك صراحة.

الخطوة 6: إعادة الاختبار، قياس التحسن، واختبار الانحدار

لتقييم تحسن الأداء بشكل كمي، نستخدم مقاييس رياضية واضحة: - **Pass Rate** = (عدد الحالات الناجحة ÷ إجمالي حالات الاختبار) × 100 - **Schema Compliance Rate** = (المخرجات المطابقة للـ Schema ÷ إجمالي المخرجات) × 100 (ملاحظة هامة: النتائج الرقمية التالية هي محاكاة تعليمية وتوضيحية لشرح منهجية القياس ضمن هذا الـ Test Dataset فقط، وليست تقييماً معيارياً لنموذج تجاري محدد): $$\text{Pass Rate} = \frac{\text{Passed Test Cases}}{\text{Total Test Cases}} \times 100$$

**كيف تجعل عملية الاختبار قابلة للتكرار (Reproducible)؟** 1. ثبّت إصدار النموذج وإعدادات التوليد (مثل التحكم بدرجة الحرارة قدر الإمكان مع إدراك أن النتائج لا تكون حتمية بنسبة 100%). 2. استخدم نفس الـ Test Dataset دائماً عند المقارنة بين الإصدارات. 3. وثّق نسخة البرومبت بدقة. 4. **اختبار الانحدار (Regression Testing):** قد يؤدي تعديل البرومبت لإصلاح حالة معينة (مثل T2) إلى إفساد حالة أخرى كانت تعمل بنجاح مسبقاً (مثل T1). لتجنب هذا التخصيص الزائد أو الـ (Prompt Overfitting)، احرص دائماً على إعادة تشغيل الـ Test Dataset بالكامل بعد كل تعديل جوهري.

الخلاصة: نحو أتمتة تقييم الـ LLM

البرومبت الجيد ليس الذي ينجح في حالة واحدة، بل الذي يمكنك قياس سلوكه، اكتشاف نقاط ضعفه، تحسينه، ثم إعادة اختباره بثقة. ومع نمو تطبيقاتك وزيادة حجم حالات الاختبار، ستنتقل تدريجياً من الاختبار اليدوي إلى بناء **Evaluation Dataset** وأتمتة عملية التقييم بالكامل ضمن خط الأنابيب (CI/CD Pipeline) الخاص بك.