الـ Reflection — الـ Agent اللي بيراجع شغله

بدل رد واحد، تلات خطوات: الموديل يكتب المسودة. بعدين — نفس الموديل أو موديل تاني بيلعب دور الناقد — يقراها ومعاه معايير محددة: إيه الغلط؟ إيه الناقص؟ وأخيرًا الموديل يعيد الكتابة بناءً على النقد ده.

أنت أصلًا بتعمل كده: قبل ما تبعت إيميل مهم، بتقراه تاني. الفرق إننا هنا بنجبر الموديل يعمل القراية التانية دي — وبقائمة فحص، مش بمزاج.

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

أنت عارف الفرق بين كود اتعمله Merge من غير مراجعة، وكود عدّى على Code Review محترم: Reviewer شايف الـ Diff، وماسك Checklist — أمان، أداء، حالات حدية.

الـ Reflection هو نفس الفكرة جوه النظام: المسودة هي الـ PR، والناقد هو الـ Reviewer، والمعايير هي الـ Checklist.

وزي الدنيا الحقيقية بالظبط: Reviewer من غير Checklist بيكتب «LGTM» ويمشي. ده هو الناقد المجامل — وهنرجعله، لأنه أشهر طريقة النمط ده بيفشل بيها.

<!-- Field 7: Simple example — before/after -->

مثال حقيقي

المهمة: «هات أعلى 5 عملاء صرفًا في آخر 90 يوم».

المسودة الأولى:

SELECT customer_id, SUM(total) AS spend
FROM orders
GROUP BY customer_id
ORDER BY spend DESC
LIMIT 5;

شكلها سليم، وهتشتغل من غير Error — وهترجّع إجابة غلط.

النقد (بمعايير):

> - C1 — الفلترة الزمنية مطابقة للطلب؟ ❌ مفيش أي شرط على آخر 90 يوم. > - C2 — الطلبات الملغية والمرتجعة مستبعدة؟ ❌ بيجمع كل الحالات، فالعميل اللي رجّع كل طلباته ممكن يطلع «أعلى صرفًا». > - C3 — مستوى التجميع مطابق للسؤال؟ ✅ تجميع على العميل، سليم.

النسخة المعدلة:

SELECT customer_id, SUM(total) AS spend
FROM orders
WHERE created_at >= CURRENT_DATE - INTERVAL '90 days'
  AND status NOT IN ('cancelled', 'refunded')
GROUP BY customer_id
ORDER BY spend DESC
LIMIT 5;

نفس الموديل. كل اللي حصل إن حد سأله: «متأكد؟ بص على الزمن والحالات». ولاحظ إن الغلطتين من النوع اللي بيعدي من الاختبار السريع — الـ Query شغالة، والأرقام شكلها منطقي، والغلط مستخبي في المعنى.

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

1. Produce: الموديل بيكتب المسودة بشكل طبيعي. 2. Critique: نداء بدور «الناقد»: خد المهمة الأصلية + المسودة + معايير محددة، وطلّع تقرير: إيه اللي سقط وليه. 3. Revise: نداء تالت: المسودة + تقرير النقد ← نسخة معدلة بتعالج النقاط المذكورة تحديدًا.

وللناقد شكلين — والاختيار بينهم قرار هندسي مش تفصيلة:

### Reflexion — لما النقد يبقى ليه ذاكرة ودليل

⚠️ خد بالك من الاسم: Reflexion بالـ x — اسم علم لنمط من ورقة بحثية، مش غلطة إملائية.

الـ Reflection العادي بينقد جوه المحاولة الواحدة وبينسى. الـ Reflexion بيضيف حاجتين:

1. إشارة خارجية موضوعية: بدل رأي الناقد لوحده — Tests بتنجح أو تفشل، Error من التنفيذ، درجة من Eval. حاجة مش بتجامل. 2. ذاكرة للفشل: بعد كل محاولة فاشلة، الموديل بيكتب خلاصة قصيرة («جربت X، فشل عشان Y — المرة الجاية هجرب Z») وبتتحقن في الـ Prompt بتاع المحاولة الجاية.

النتيجة: المحاولة الرابعة مش بتبدأ من الصفر — بتبدأ من ملف الدروس المستفادة. النمط ده بيكسّر الدنيا في المهام اللي ليها إجابة قابلة للفحص: كود لازم يعدي Unit Tests، استعلام نتيجته بتتقارن بنتيجة معروفة، مسألة ليها حل صح. ولو مفيش إشارة خارجية؟ Reflexion بيرجع Reflection عادي — بس باسم أفخم.

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

النقطة الهندسية الوحيدة اللي بتفرق بين Reflection شغال و Reflection ديكور: الناقد لازم ياخد Rubric صريح. شكل الـ Critic Prompt الصح:

You are a strict code reviewer. Evaluate the SQL below against
these criteria — for each one, output PASS or FAIL + one line why:

1. Time filter matches the request exactly
2. Cancelled and refunded orders are excluded
3. Aggregation level matches the question
4. Only existing columns are used (schema attached)

Then list the required fixes, most severe first.
Do NOT rewrite the query yourself.

ليه السطر الأخير؟ لأن من غيره الناقد «بيهرب» من النقد للتأليف — يكتب لك نسخة جديدة على مزاجه بدل تقرير تقدر تبني عليه. فصل الأدوار بيخلي كل نداء متخصص وقابل للفحص.

وحاجتين عمليتين كمان:

• خلّي تقرير الناقد Structured Output (JSON فيه PASS/FAIL لكل معيار) — عشان كودك يقدر يوقف الـ Loop برمجيًا لما كله يعدي، بدل ما تعمل Parsing لكلام إنشائي.
• سقف الجولات في الكود مش في النية: MAX_ROUNDS = 2 من أول يوم. الأسباب في قسم التكلفة.

💡 نصيحة: الـ Rubric اللي كتبته للناقد ده هو نفسه بذرة الـ Evaluation بتاعك: نفس المعايير دي هي اللي هتتحول لـ Golden Set و LLM-as-Judge في دومين AI Evaluation. فلسفة BuildAI واحدة في الاتنين: من غير معايير، أنت مش بتقيّم — أنت بتخمّن. الفرق بس إن الناقد شغال جوه الـ Loop، والـ Eval بيحكم من بره.

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

تمرين (20 دقيقة): خد مهمة تلخيص حقيقية — صفحة من Docs مشروعك مثلًا. (1) خد المسودة الأولى من الموديل واحفظها. (2) اكتب Rubric من 4 معايير: دقة المعلومات، تغطية النقاط الأساسية، صفر معلومات مخترعة، طول ≤ 150 كلمة. (3) شغّل جولة Critique ← Revise بالـ Rubric ده. (4) اعرض النسختين على زميل من غير ما تقوله أنهي أنهي — وخليه يختار.

لو المعدلة كسبت: مبروك، بقيت تعرف تشتري جودة بـ 3×. ولو ماكسبتش؟ اتعلمت درس أغلى: المراجعة مش مجانية ومش دايمًا مستاهلة — وقياسك ده نفسه كان Evaluation صغير.

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

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

💸 التكلفة

جولة المراجعة الواحدة = تلات نداءات بدل واحد. خلينا نحسبها على تلخيص تقرير:

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

على 5,000 ملخص في الشهر: ~$185 بدل ~$60. جولة تانية؟ زوّد ~$0.025 لكل ملخص كمان — وهنا الخبر المهم: أغلب التحسن بييجي من الجولة الأولى. التانية بتضيف أقل، والتالتة غالبًا بتنقل الجودة يمين وشمال مش لفوق. خدها قاعدة عملية — مش قانون فيزيا — بس اكسرها بقياس، مش بأمل.

القرار في الآخر بسيط: الجودة الزيادة تستاهل 3×؟ تقرير رايح لعميل — أيوه. رد Chat سريع — غالبًا لأ.

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

• مخرجات بتتسلم لحد: تقارير، إيميلات مهمة، كود هيتراجع — أي حاجة «أول انطباع» فيها بيفرق.
• مهام قابلة للفحص وفيها Tests أو Evals: روح على Reflexion مباشرة — إشارة خارجية + ذاكرة فشل.
• جودة أول محاولة مش كفاية وتغيير الموديل مش مطروح: المراجعة أرخص من موديل أغلى في حالات كتير — احسبها.
• Agents طويلة المدى: ذاكرة الفشل بتمنع تكرار نفس الغلطة جوه نفس المهمة.

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

• ردود سريعة الجودة المقبولة فيها كفاية: شات عام، اقتراحات، مسودات داخلية — 3× تكلفة على فايدة هامشية.
• الـ Latency حساس: تلات نداءات متسلسلة ≈ تلات أضعاف الانتظار. في مسار تفاعلي ساخن، ده محسوس ومؤلم.
• المشكلة شكلية مش جوهرية: مخرج ناقص Format معين؟ Structured Output + Validation بيحلوها بنداء واحد.
• المعايير كلها قابلة للأتمتة وقرار النجاح Pass/Fail: ساعتها أنت مش محتاج «مراجعة» — أنت محتاج بوابة جودة. ده المفهوم الجاي: Evaluator–Optimizer.

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