يتيح مهندس الأوامر التلقائي (Automatic Prompt Engineer - APE) للنموذج اللغوي كتابة واختبار واختيار أفضل أمر لمهمة معينة، محولاً ما كان يُعتبر فناً قائماً على التجربة والخطأ إلى عملية بحث متكررة قائمة على البيانات.
لماذا أصبحت كتابة الأوامر تمثل عنق زجاجة
لطالما كانت هندسة الأوامر (Prompt engineering) — أي صياغة الكلمات الدقيقة التي تخبر النموذج بما يجب فعله — مزيجاً من الحدس والحظ. يقوم الممارسون بتعديل كلمة هنا، وتبديل عبارة هناك، ثم تشغيل النموذج، والتوقف عندما "تبدو" المخرجات صحيحة. هذا النهج يستغرق وقتاً طويلاً، ويعتمد على خيال المهندس، ويحد من الأداء. وفي مرحلة الإنتاج، يعني هذا دورات تطوير أطول، ونتائج غير مستقرة، وتكاليف خفية لا تظهر إلا بعد الإطلاق.
سير عمل APE المكون من ثلاث خطوات
يتعامل APE مع إنشاء الأوامر كمسألة بحث. يقوم المستخدم بتزويد النظام بمجموعة صغيرة من أمثلة المدخلات والمخرجات، ثم يقوم النظام بتشغيل ثلاث مراحل مؤتمتة:
- الاقتراح (Propose) – يقوم النموذج بفحص الأمثلة ويخرج مجموعة من التعليمات المرشحة، مثل "أرجع العكس" أو "اكتب الضد".
- التقييم (Score) – يقوم النظام بتشغيل كل مرشح على مجموعة منفصلة من الأمثلة غير المرئية ويحسب عدد الإجابات التي تطابق المخرجات المتوقعة، مما يعطي رقماً خاماً للدقة. لا يتدخل أي حكم بشري في هذه الخطوة.
- الاختيار (Select) – تصبح التعليمات ذات الدقة الأعلى هي الأمر النهائي.
يمكن تكرار هذه الحلقة؛ حيث يصبح الأمر الفائز هو "البذرة" الجديدة، ويقترح النموذج تنويعات عليه. وفي عمليات التشغيل المسجلة، تم تحسين تعليمات عامة سجلت دقة 83% إلى نسخة حققت 100% في مجموعة الاختبار.
ما الذي يجعل هذا النهج أقوى من التدخل البشري
- التغطية (Coverage) – يمكن للنماذج اللغوية الكبيرة (LLM) إنتاج عشرات البدائل للصياغة في ثوانٍ معدودة، وهو ما يفوق بكثير ما يمكن لشخص واحد اختباره.
- الموضوعية (Objectivity) – يعتمد الاختيار على الدقة القابلة للقياس، وليس على مدى رقي الصياغة. فقد تخسر تعليمات مكتوبة بأسلوب أكاديمي رصين أمام نسخة موجزة وغريبة النبرة يفهمها النموذج بشكل أفضل.
ولأن مقياس التقييم يأتي من المستخدم — وعادة ما يكون فحصاً للمطابقة التامة أو اختبار وحدة (unit test) — يمكن ضبط النظام ليتناسب مع أي متطلبات لاحقة، بدءاً من توليد الكود وصولاً إلى تحليل المشاعر.
ثمن الأتمتة
المقايضة هنا هي قوة الحوسبة. فتقييم كل مرشح يتطلب العديد من استدعاءات النموذج، مما يعني أن مرحلة التطوير تستهلك قدراً ملحوظاً من استخدام الـ API. لكن APE يتعامل مع هذه التكلفة كاستثمار لمرة واحدة: فبمجرد تحديد الأمر الأمثل، يمكنك إعادة استخدامه للأبد دون تكلفة إضافية.
هناك أيضاً شرطان مسبقان يحدان من اعتماد هذه التقنية:
- أمثلة مصنفة (Labeled examples) – يحتاج النظام إلى مجموعة ممثلة من المدخلات والمخرجات الصحيحة.
- دالة التقييم (Scoring function) – يجب على المستخدمين تحديد معنى كلمة "صحيح" لمهمتهم، سواء كان ذلك مطابقة تامة للنص، أو هامش سماح رقمي، أو أداة تحقق مخصصة.
أين يمكن أن تتعثر الفكرة
إذا كانت مجموعة الأمثلة الأولية صغيرة جداً أو غير ممثلة للواقع، فقد يعاني الأمر المختار من "الفرط في التخصيص" (overfit) ويفشل عند الاستخدام في العالم الحقيقي.
ما الذي يجب مراقبته لاحقاً
توفر الأداة بديلاً: قم بتزويدها ببضعة أمثلة، واترك النموذج يكرر المحاولات، وستحصل على أمر يصنفه النظام كأعلى نتيجة من بين محاولاته. يتوفر العرض التجريبي (demo) عبر الرابط الموجود في الإعلان الأصلي، كما يتجمع مجتمع تعليمي على Telegram.
الخلاصة: تستبدل أتمتة هندسة الأوامر التخمين بالأداء القابل للقياس، لكنها تتطلب بيانات مسبقة، وقوة حوسبة، وتحديداً واضحاً لمعايير النجاح.