هندسة الـ Prompt· الدرس 5 من 7
- 1تشريح الـ Prompt — من إيه بيتكوّن6 دقيقة
- 2الـ Few-Shot — علّمه بالأمثلة7 دقيقة
- 3المخرجات المنظّمة — خلّيه يرد JSON7 دقيقة
- 4سلسلة التفكير — خلّيه يفكّر خطوة خطوة8 دقيقة
- 5تحسين الـ Prompt — التعديل المتدرّج6 دقيقة
- 6الدور والشخصية — قوله يبقى مين7 دقيقة
- 7أساسيات الـ Prompt Injection — لما المدخلات تخونك8 دقيقة
تحسين الـ Prompt — التعديل المتدرّج
في سطر واحد · أول prompt نادرًا ما يكون الأخير؛ التحسين شغل متكرّر: جرّب، شوف اللي غلط، عدّل حاجة واحدة، وقارن.
الناس بتيأس من الـ prompt بعد أول محاولة فاشلة وتقول «الموديل غبي». المشكلة غالبًا في الصياغة، والحل تعديل صغير مقصود.
زي ما بتظبط استعلام SQL: بتشغّله، تشوف النتيجة، تعدّل شرط واحد، وتشغّل تاني — مش بتعيد كتابته من الأول كل مرة.
اعتبر كل نسخة من الـ prompt commit صغير: تغيير واحد واضح، عشان لو باظ تعرف ترجع.
الرد طويل؟ ضيف «في جملة واحدة». لسه رسمي أوي؟ ضيف «بلهجة ودّية». تغيّر حاجة واحدة كل مرة عشان تعرف اللي فرق فعلًا.
بتشتغلها زي أي debugging loop: ثبّت مجموعة اختبار صغيرة (٥-١٠ inputs حقيقية)، شغّل الـ prompt عليها، ودوّن الأخطاء المتكررة. عدّل حاجة واحدة بتستهدف أشهر خطأ، وشغّل تاني على نفس المجموعة وقارن. المجموعة الثابتة هي المفتاح — من غيرها بتحكم بالإحساس، ولأن ردود الموديل احتمالية، مثال واحد ممكن يضحك عليك في الاتجاهين.
🧪 جرّب بنفسك: خد الـ prompt الضعيف في التمرين المرفق، وجهّز ٥ inputs ثابتة. اعمل ٣ passes: في كل واحدة عدّل حاجة واحدة بس، وسجّل النتيجة على الخمسة قبل وبعد. في الآخر بص على السجل: أنهي تعديل جاب أكبر فرق فعلًا؟
- تغيّر ٣ حاجات مرة واحدة، فلما النتيجة تتحسن (أو تبوظ) متعرفش مين السبب.
- تحكم على التعديل من مثال واحد — النتيجة الأحسن ممكن تكون صدفة من عشوائية الموديل.
- متحتفظش بنسخ الـ prompts القديمة، فلما تعديل يبوظ حاجة كانت شغالة مبتعرفش ترجع.
أي prompt رايح production، وأي prompt نتايجه متقلبة أو بتقع على أنواع معينة من الـ inputs.
لو عدّلت الصياغة ٥-٦ مرات والنتيجة واقفة مكانها، بطّل صياغة — المشكلة غالبًا أعمق: محتاج أمثلة (few-shot)، أو سياق ناقص (RAG)، أو المهمة أكبر من الموديل نفسه.