Prompt Patterns — أنماط عملية

بعد درس 106: Prompting Fundamentals، نغوص في أنماط عملية تتكرّر في تطبيقات LLM الحقيقية. كل نمط يوضّح المهمة، البنية، ومثالًا عربيًا.

المبدأ العام: فصّل البيانات عن التعليمات

قبل أيّ نمط، هذا المبدأ الأهم:

❌  خلط التعليمات مع البيانات:
    "هذا مقال عن الذكاء الاصطناعي. لخّصه. لا تتجاوز 3 جمل. ابدأ ب'الذكاء
     الاصطناعي'..."

✅  فصل واضح:
    التعليمات:
      لخّص النصّ التالي بقيدَين:
        1. لا تتجاوز 3 جمل.
        2. ابدأ بـ'الذكاء الاصطناعي'.

    النصّ:
    <data>
    [النصّ الكامل هنا]
    </data>

    الملخّص:

الفوائد:

• النموذج لا يخلط بين ما هو "تعليمات" وما هو "بيانات".
• يمكنك إعادة استخدام نفس التعليمات مع بيانات مختلفة.
• أسهل في الاختبار والصيانة.
• يقلّل مخاطر prompt injection (رغم أنه ليس حلًّا كاملًا).

النمط 1: Classification — التصنيف

الاستخدام: فرز النصوص إلى فئات محدّدة.

صنّف النصّ التالي إلى إحدى الفئات:
- bug: تقرير عن خطأ تقني
- billing: مسألة مالية أو اشتراك
- account: مشكلة حساب أو تسجيل دخول
- other: أيّ شيء آخر

أمثلة:
"التطبيق يتعطّل عند الفتح" → bug
"أريد إلغاء اشتراكي" → billing
"نسيت كلمة المرور" → account

النصّ:
{user_input}

التصنيف (أعِد كلمة واحدة فقط):

ملاحظات عملية:

• حدد قائمة الفئات مسبقًا (لا تترك النموذج يخترع فئات).
• اطلب صيغة المخرج بدقة (كلمة واحدة، enum، JSON).
• وفّر أمثلة لتوضيح الحالات الحدّية.

النمط 2: Extraction — الاستخراج

الاستخدام: استخراج حقول محدّدة من نصّ حر.

استخرج من السيرة الذاتية التالية الحقول التالية:
- name (الاسم الكامل)
- email (البريد الإلكتروني)
- years_experience (عدد سنوات الخبرة، رقم صحيح)
- skills (قائمة بالمهارات التقنية)

أعِد JSON فقط، بدون أيّ نصّ إضافي:

{
  "name": "",
  "email": "",
  "years_experience": null,
  "skills": []
}

السيرة الذاتية:
"""
أحمد محمود، مطوّر Python منذ 2018.
التواصل: ahmad@example.com
خبرة في Django و FastAPI و PostgreSQL.
"""

ملاحظات:

• JSON Schema هنا فقط كـ prompt، ليس schema-constrained structured output (الفرق في درس 110).
• أَخْرِج JSON صالحًا دائمًا. تحقّق منه برمجيًا.

النمط 3: Transformation — التحويل

الاستخدام: تحويل صيغة نصّ إلى أخرى (إعادة هيكلة، ترجمة، تحويل أسلوب).

حوّل الجملة التالية من الفصحى المعقّدة إلى فصحى مبسّطة:

"يتعيّن على المستخدم أن يقوم بإدخال البيانات الشخصيّة المطلوبة بشكل دقيق في الحقول المخصّصة."

النسخة المبسّطة:

أنواع شائعة:

• ترجمة بين لغات.
• تحويل بين formal/informal.
• إعادة هيكلة JSON/XML.
• استخراج JSON من نصّ.

النمط 4: Summarization — التلخيص

الاستخدام: تقليص نصّ طويل مع الحفاظ على المضمون.

لخّص النصّ التالي في 3 جمل، موجّهة لمطوّر برمجيات مبتدئ:

النصّ:
{long_text}

الملخّص:

أنواع التلخيص:

- extractive:    اختر أهمّ الجمل حرفيًا (سهل لكن جامد).
- abstractive:   أعِد كتابة المعنى بجمل جديدة (أصعب لكن أنعم).
- brief:         1-2 جملة.
- structured:    نقاط أو JSON بمفاتيح معيّنة.

النمط 5: Rewriting — إعادة الكتابة

الاستخدام: تحسين نصّ موجود (وضوح، أسلوب، قواعد).

أعد كتابة الفقرة التالية بأسلوب واضح ومختصر، مع الحفاظ على المعنى:

الفقرة الأصلية:
{paragraph}

النسخة المحسّنة:

أمثلة على قيود معقولة:

• "احتفظ بنفس طول النصّ ± 20%."
• "استخدم جملًا لا تتجاوز 20 كلمة."
• "تجنّب الكلمات العامّية، استخدم الفصحى."

النمط 6: Constrained Generation — التوليد المقيد

الاستخدام: توليد نصّ بشروط صارمة (طول، صيغة، مفردات).

اكتب سيرة ذاتية لوظيفة "مطوّر Backend" بالشروط التالية:
- الطول: 150-200 كلمة بالضبط.
- الأقسام: ملخّص (جملة واحدة)، مهارات تقنية (قائمة نقطية)، خبرة (فقرة واحدة).
- تجنّب: ذكر العمر، الجنس، الحالة الاجتماعية.
- الأسلوب: رسمي ومهني.

السيرة:

القيد الأساسي: لا تعتمد على النموذج لاحترام كل القيود العددية بدقة. للمهام الحرجة، تحقّق برمجيًا بعد المخرج.

النمط 7: Rubric-Based Evaluation — تقييم قائم على Rubric

الاستخدام: تقييم مخرج (نصّ، كود، إجابة) وفق معايير محدّدة.

قيّم الإجابة التالية وفق المعايير:
- accuracy: هل المعلومة صحيحة؟ (1-5)
- clarity: هل الشرح واضح؟ (1-5)
- completeness: هل يغطّي كل جوانب السؤال؟ (1-5)

لكل معيار أعطِ:
- الدرجة (1-5)
- مبرر قصير (جملة واحدة)

السؤال:
{question}

الإجابة:
{answer}

التقييم (JSON):
{
  "accuracy": {"score": 0, "reason": ""},
  "clarity": {"score": 0, "reason": ""},
  "completeness": {"score": 0, "reason": ""}
}

نصيحة: استخدم نماذج أقوى (مثل نموذج أكبر) لتقييم مخرجات نماذج أصغر — أسلوب شائع يُسمّى LLM-as-judge.

النمط 8: Few-shot مع مخرج منظّم

الاستخدام: تصنيف أو استخراج مع أمثلة توضّح الحالات الحدّية.

صنّف تذكرة الدعم.

أمثلة:
"نسيت كلمة المرور" → account (إجراء ذاتي)
"التطبيق يرمي خطأ 500" → bug (يحتاج فحص)
"أريد استرداد المبلغ" → billing (يحتاج مراجعة بشرية)

التذكرة:
{user_input}

التصنيف (كلمة واحدة):
الخطورة (low/medium/high):
الإجراء المقترح:

لا تطلب سلسلة التفكير الخاصة

قاعدة عملية: اطلب النتيجة النهائية، لا سلسلة الاستدلال الداخلية.

❌  "اشرح خطوة بخطوة كيف حللت المسألة، ثم أعطني الإجابة"
    → النموذج يكتب سلسلة استدلال. قد تكون طويلة، متحيّزة، أو تحتوي معلومات
       لا تريد كشفها.

✅  "احسب الإجابة في ذهنك، ثم أعِد رقمًا واحدًا فقط"
    → النموذج يولّد نتيجة مختصرة. أنت تتحقّق منها برمجيًا.

لماذا هذا مهم؟

• الأمان: سلسلة الاستدلال قد تكشف معلومات حسّاسة (مثلاً قاعدة prompt).
• التحكّم: المستخدمون قد يستخدمون المنطق ضدّك أو يعدّلونه.
• الكلفة: استدلال مطوّل = tokens أكثر = تكلفة أعلى.

ما تريده من المستخدم: النتيجة الموثوقة. سلسلة الاستدلال تبقى داخلية في النموذج.

أخطاء شائعة في الأنماط

• "النمط يصلح لكل شيء": لا. التصنيف ≠ الاستخراج ≠ التحويل. كل نمط له بنية ومحدّدات.
• "Few-shot يحلّ كل غموض": أحيانًا يضيف غموضًا إن كانت الأمثلة متحيّزة.
• "LLM-as-judge موضوعي": ليس بالضرورة. الحكم نفسه تحكّمه prompt والموديل المستخدم. قس الاتفاق بين الحكّام.
• "Constrained generation = مخرج مضمون": لا. النموذج قد ينتهك القيود. تحقق برمجيًا.

الخطوات التالية

• استخدام LLM API من Python — تطبّق هذه الأنماط عمليًا مع API.
• Structured Outputs & JSON Schema — حين تريد ضمان بنية المخرج على مستوى الـ API لا الـ prompt فقط.

ملاحظة النطاق: هذا الدرس حدّه أنماط prompt يدوية. الـ structured output مع schema-constrained generation يغطّى في درس 110. الوكلاء و RAG في الموجات التالية.