صعود الهندسة الوكيلية: ديون الأوامر (Prompt Debt)
تبدو كتابة الأوامر (Prompts) بلغة إنجليزية بسيطة وكأنها سحر. تكتب ما تريد، فيظهر نموذج أولي. ولكن بالنسبة للأنظمة طويلة الأمد، يصبح هذا السحر فخاً.
من المرجح أنك تراكم "ديون الأوامر" (Prompt debt).
تحدث ديون الأوامر عندما تستخدم اللغة الطبيعية للتحكم في النموذج بدلاً من استخدام الهندسة الدقيقة. وهذا يخلق ثلاث مشكلات ضخمة:
- تباطؤ عمليات التكرار. تضيف المزيد من النصوص لإصلاح خطأ واحد، لكن هذا النص يفسد شيئاً آخر. سرعان ما يصبح أمرك عبارة عن فوضى من التعليمات المتكررة.
- يفقد فريقك السيطرة. من المستحيل على الزملاء قراءة أو إدارة أمر مليء بالتحذيرات المكتوبة بأحرف كبيرة (all-caps) والحالات الاستثنائية (edge cases).
- الارتباط بنموذج واحد. الأمر الذي تم ضبطه لنموذج معين غالباً ما يفشل مع إصدار أحدث وأفضل. تظل الفرق عالقة في نماذج قديمة ومكلفة لأنها تخشى تعطل نظامها.
يحدث هذا لأنك تحارب الأوزان (weights). عندما يقاوم النموذج تعليماتك، فإنك تكررها. كل تعليمات مكررة أو مؤكدة هي بمثابة "نسيج ندبي" (scar tissue)؛ فهي توضح أين تقاوم تدريبات النموذج نيتك.
اللغة الطبيعية غير دقيقة بما يكفي للهندسة. التغييرات الطفيفة في الصياغة يمكن أن تقلب سلوك النموذج. حتى الحقائق غير المرتبطة في الأمر يمكن أن تغير طريقة استجابة النموذج.
كيف تعالج هذا؟
يجب أن تتوقف عن كتابة الأوامر يدوياً وتبدأ في تحديد السلوك باستخدام المقاييس.
- الأمر (Prompt) هو فقرة تأمل أن يتبعها النموذج.
- المقياس (Metric) هو عقد يجب على النموذج الوفاء به.
مستقبل الهندسة ينتقل من "إعطاء الأوامر" (prompting) إلى "البرمجة" (programming). تتيح لك أدوات مثل DSPy و GEPA تحديد هدف ومقياس. ثم يبحث النظام عن أفضل أمر لتحقيق ذلك الهدف.
هذا يحول إعطاء الأوامر إلى نتاج مُجمَّع (compiled artifact). إذا ظهر نموذج جديد وأرخص، فلن تصاب بالذعر. ببساطة، قم بتشغيل مقاييسك مقابل النموذج الجديد وأعد إنشاء الأمر.
تماماً كما انتقل المهندسون من لغة التجميع (assembly language) إلى المجمّعات (compilers)، يجب على مهندسي الذكاء الاصطناعي الانتقال من الضبط اليدوي للنصوص إلى تحسين المقاييس.
توقف عن استمالة النموذج بكلمات سحرية. ابدأ البناء بمواصفات قابلة للقياس.
Optional learning community: https://t.me/GyaanSetuAi