نمط الـ Evaluator–Optimizer — واحد يبني وواحد يحكم

اتنين بدورين منفصلين. الأول بيبني. التاني ماسك ورقة معايير — مش ذوقه الشخصي — وبيحكم على الشغل بند بند: عدى / سقط.

لو بند سقط، الـ Feedback بيرجع للأول محدد: «سقطت في 2 و3، والسبب كذا». الأول يعيد وهو عارف بيصلح إيه. وكده لحد ما الشغل يعدي كل البنود — أو نوصل لسقف المحاولات، فنوقف ونبعت المخرج لمراجعة بشرية بدل ما نلف للأبد.

<!-- Field 6: Real-world analogy (Layer 2) -->

مصحح امتحانات معاه Model Answer ونموذج توزيع درجات: «تعريف صح = درجتين، مثال سليم = درجة». مش بيصحح بمزاجه — بند بند. والطالب اللي واخد 3 من 5 بيعرف بالظبط جاب إيه غلط، فمذاكرته الجاية موجهة.

قارن ده بمصحح من غير نموذج إجابة، بيقرا ويكتب «جيد جدًا» بالإحساس — ده الناقد بتاع الـ Reflection لما مايكونش معاه Rubric.

وفيه احتمال تالت أسوأ: مصحح ماسك نموذج إجابة غلط — بيدي درجات عالية بثقة لإجابات وحشة. ده بالظبط موضوع تحدي «الامتحان الغلط» — لأن أخطر حاجة في النمط ده مش غياب الحَكم... حَكم بيطمنك بالغلط.

<!-- Field 7: Simple example — one fail→retry→pass cycle -->

مثال حقيقي

المهمة: Landing copy لتطبيق إدارة مصاريف للشركات الصغيرة. الـ Evaluator ماسك 4 معايير مسماة:

> - C1: الفايدة الأساسية واضحة في أول جملة > - C2: CTA واحد بالظبط > - C3: مفيش أرقام أو ادعاءات غير موجودة في الـ Brief > - C4: الطول ≤ 80 كلمة

المحاولة 1 — الـ Generator طلّع نص فيه «وفّر 70% من وقت المحاسبة» وقفل بـ «جرب مجانًا» و«اطلب Demo»:

Evaluator report (attempt 1):
  C1: PASS — benefit stated in the first sentence
  C2: FAIL — two CTAs found: "جرب مجانًا" and "اطلب Demo"
  C3: FAIL — the 70% claim does not exist in the brief
  C4: PASS — 64 words
  verdict: REJECT → feedback sent back to generator

المحاولة 2 — الـ Generator شال الرقم، وحّد الـ CTA على «جرب مجانًا»:

Evaluator report (attempt 2):
  C1: PASS   C2: PASS   C3: PASS   C4: PASS
  verdict: ACCEPT → ship it

لاحظ حاجتين: الـ Feedback كان محدد بالبند («الرقم مش في الـ Brief») مش درجة عامة — عشان كده المحاولة التانية صلحت المطلوب بالظبط. والمعايير مسماة ومكتوبة قبل التشغيل — مش رأي اتولد لحظة الحكم.

<!-- Field 8: How it works (Layer 3) -->

1. Generate: الـ Optimizer بيطلّع مخرج — ومعاه في الـ Prompt أي Feedback من الجولة اللي فاتت. 2. Evaluate: الـ Evaluator بيفحص المخرج ضد كل معيار، وبيطلّع تقرير منظم: PASS/FAIL لكل بند + السبب. 3. قرار: كله PASS؟ المخرج يعدي. فيه FAIL والمحاولات لسه في الحد؟ الـ Feedback يرجع للخطوة 1. 4. مسار الخروج: خلصت المحاولات ولسه ساقط؟ المخرج يتعلّم للمراجعة البشرية — مش يفضل يلف.

### طيب المعايير نفسها جاية منين؟

دي أهم حتة في النمط كله — ودي سلم القوة بتاعها:

القاعدة: أتمت اللي يتأتمت بكود، وسيب للحَكم الـ LLM المعايير اللي فعلًا محتاجة فهم لغة. معيار الطول مثلًا (C4 فوق) مالوش أي مبرر يتحكم فيه LLM — سطر Python بيحسمه ببلاش.

### كلمة صريحة عن الـ LLM-as-Judge

• Self-preference حقيقي: الموديل بيميل يدي درجات أعلى للكلام اللي شبه أسلوبه — عشان كده موديل الحَكم ≠ موديل الـ Generator ممارسة أصح صحيًا.
• انحيازات موثقة: بيحب الإجابات الأطول، وحساس لترتيب العرض في المقارنات.
• المعايرة واجبة مش رفاهية: قيس حكمه على عينة صححها بشر (حتى 30 مثال بيفرقوا). لو نسبة اتفاقه مع البشر ضعيفة — عندك امتحان غلط، وكل الدرجات اللي بعده كلام فاضي.

<!-- Field 11: Technical explanation (Layer 4) -->

الحلقة كلها، بأي Provider — لاحظ فين القرارات:

MAX_ATTEMPTS = 3                              # always cap!
feedback = None

for attempt in range(MAX_ATTEMPTS):
    output = generator(task, brief, feedback)        # optimizer produces
    report = evaluator(output, criteria)             # judge: per-criterion
    if report.all_passed:                            # programmatic decision
        return output                                # quality gate passed
    feedback = report.failures                       # specific: which + why

return flag_for_human_review(output, report)         # budget exhausted

أربع حاجات خد بالك منهم:

• دورين = نداءين مختلفين بـ Prompts منفصلة تمامًا — وياريت موديلين مختلفين (الـ Self-preference فوق).
• تقرير الحَكم Structured Output — عشان all_passed قرار كود، مش Parsing لإنشاء.
• الـ Feedback بيدخل الـ Generator بالنص: المعيار اللي سقط + السبب. درجة «6/10» من غير تفاصيل بتخلي المحاولة الجاية تخمين جديد مش تصليح.
• `flag_for_human_review` مسار مصمم مش Exception: المخرج اللي فشل 3 مرات هو بالظبط المخرج اللي محتاج عين بشرية — ومعاه تقرير جاهز بيقول ليه.

⚠️ خد بالك — قواعد التوقف تلاتة، مش واحدة: سقف محاولات (2–3 كفاية في الأغلب)، وعتبة نجاح واضحة (أنهي معايير Must-pass)، وسقف تكلفة للمهمة الواحدة. ولو لقيت المخرج بيحوم حوالين العتبة جولة ورا جولة — 78 من 80 المطلوبة، كل مرة — متزودش المحاولات: راجع المعايير نفسها، غالبًا فيه بندين بيشدوا في اتجاهين متعاكسين.

<!-- Field 21: Cost considerations -->

تمرين (30 دقيقة): خد مهمة توليد متكررة من شغلك الفعلي — وصف منتج، رد Support، رسالة Commit. (1) اكتب 4 معايير، منهم واحد على الأقل بيتفحص بكود (طول، Regex، Schema). (2) ابني الحلقة: Generator ← Evaluator بتقرير JSON ← Loop بسقف 3 محاولات. (3) شغّلها على 10 مدخلات وسجّل رقمين: نسبة النجاح من أول محاولة، ومتوسط المحاولات.

الرقم الأول بيقولك جودة الـ Prompt الأساسي عندك — لو 9 من 10 بيعدوا من أول مرة، ممكن أصلًا متكونش محتاج الـ Loop. ولو 3 من 10... الـ Evaluator لسه بيوفر عليك، بس الـ Generator محتاج شغل.

<!-- Field 28: Knowledge check (scenario-based per F5) -->

<!-- Field 19: Trade-offs — the crucial contrast with Reflection -->

💸 التكلفة

> 💸 أرقام قابلة للتغير *(Volatile fragment — أسعار نموذجية للتوضيح؛ راجع أسعار مزوّدك الحالية)*: $3/مليون Input Token و $15/مليون Output Token.

سيناريو: توليد وصف منتج بالمعايير الأربعة:

على 1,000 منتج: ~$19 — مقابل مراجعة بشرية بـ 5 دقايق للوصف = ~83 ساعة عمل. وده قبل ما نحسب الثبات: الحَكم الآلي مش بيتعب آخر اليوم ولا بيعدّي حاجة عشان مستعجل.

ورقم واحد يستاهل تراقبه على الـ Dashboard: متوسط المحاولات لكل مخرج. لو بدأ يزحف من 1.6 لـ 2.8، فيه حاجة اتغيرت — الـ Brief، الموديل، أو المعايير — والفاتورة بتقولك قبل الجودة ما تقول.

<!-- Field 14: Common mistakes -->

• Batch Generation بجودة موحدة: أوصاف منتجات، ردود Support، ملخصات — أي حاجة بتتعمل بالمئات.
• حد أدنى جودة قابل للتعريف: تقدر تكتب «لازم يعدي C1 لـ C4» في بنود واضحة.
• مخرجات قابلة للفحص بكود: كود بيتاخد عليه Tests، بيانات بتتاخد عليها Schema Validation — النمط في أقوى حالاته هنا.
• Pipeline شغال من غير بشر في الـ Loop بس محتاج Quality bar حقيقي قبل ما المخرج يمشي.

<!-- Field 17: When NOT to use it (Layer 7b) -->

• مهمة One-off: هتكتب الحاجة مرة واحدة؟ راجعها بعينك — بناء Evaluator لمخرج واحد هو Over-engineering من كتاب المدرسة.
• الجودة ذوقية بحتة: «النكتة أحلى؟» «الـ Copy أشيك؟» — لو أنت شخصيًا مش قادر تكتب المعيار، الحَكم مش هيخترعه لك. هيديك درجات شكلها علمي لحكم مزاجي.
• المعيار الحقيقي هو رأي العميل: مفيش Evaluator بديل عن العميل — خد Feedback حقيقي بدل ما تحاكيه.
• قرارات حساسة (قانوني، طبي، مالي): النمط يرشّح ويصفّي — لكن القرار الأخير لازم يفضل بشري. الـ Evaluator هنا فلتر أولي، مش جهة اعتماد.

💡 نصيحة: اختبار سريع قبل ما تبني: اكتب المعايير الأربعة على ورقة. لو كتبتهم في 5 دقايق وكلهم قابلين للفحص — النمط مناسب. لو قعدت نص ساعة وطالع كلام زي «يكون النص جذابًا» — مشكلتك مش في النمط، مشكلتك إنك لسه معرفش «كويس» يعني إيه. وده اكتشاف مهم في حد ذاته.

<!-- Field 23: Related concepts -->

الفرق عن الـ Reflection — بجدول

والحقيقة الكاملة: الخط بينهم مش سور — ده منحدر. لما تدي ناقد الـ Reflection معايير رسمية، وتخلي القرار برمجي، وتحط سقف ومسار خروج... أنت عمليًا بنيت Evaluator–Optimizer. كل ما المعايير بقت أصرح والقرار أوتوماتيكي أكتر، كل ما اتحركت من «مراجعة» لـ «بوابة جودة».

<!-- Field 16: When to use it (Layer 7a) -->