extended thinking بيرجّع قيمته إمتى فعلاً

الدرس اللي فات ورّى إن Claude و GPT-4o-mini الاتنين حلّوا لغز ترتيب السباق على النموذج الأساسي في 3-4 ثواني. لو ضفت thinking mode للـprompt ده كان هيطلّع نفس الإجابة في 30+ ثانية ويكلّف فلوس أكتر. يعني thinking mode مش دايماً مكسب. السؤال إمتى يكون.

الـ4 حالات اللي thinking بيرجّع قيمته فيها

1. النموذج الأساسي بيغلط. دي الحالة الأوضح. لو تقدر تتحقق من الإجابة (عندك test set معروفة صح، أو المسألة رياضية)، والنموذج الأساسي بيغلط، الطلوع لـthinking mode غالباً بيصلّحها. benchmarks داخلية في الـlabs الكبيرة بتورّي رفع 10-30 نقطة مئوية على رياضيات مسابقات، code multi-step، ومسائل constraint-satisfaction.

2. المهمة فيها failure mode reasoning معروف. لو المهمة بتاعتك "خمّن إجابة لمسألة Fermi دي"، النماذج الأساسية بتميل تعدّي الـrigorous decomposition وتكتب رقم شكله معقول. thinking mode بيجبر الـdecomposition. نفس الحاجة لمهام "الكود ده صح؟" review اللي النموذج الأساسي يقدر يفوّت bugs دقيقة فيها.

3. الـlatency مش بتظهر للمستخدم. لو الـprompt بيشتغل في batch job في الـbackground الساعة 3 الصبح، عقوبة الـlatency 30-60 ث ما بتفرقش. ادفعها. فرق التكلفة لكل call كمان غالباً غير ذي صلة على volume قليل — research-summary digest job اللي بيشتغل مرة في اليوم تمام إنه يبقى على thinking mode لو ده بيحسّن الجودة.

4. تكلفة الإجابة الغلط طاغية على تكلفة الـcompute. لو النموذج بيعمل توصية اللي بتروح لـreviewer بشري أو لقرار فلوس حقيقية، إنك تدفع 5x للإجابة رخيص قبال التكلفة اللي ورا توصية وحشة. code review لأنظمة production، تحليل بنود contracts، financial analysis — كل دي أماكن thinking mode بيرجّع قيمته فيها.

thinking إمتى بيبقى صرف ضايع

أغلب الـprompts بتاعة الـproduction. tone rewrites ما بتتحسّنش بالتفكير؛ النموذج عارف يخلّي الإيميل أدفى. classifications ما بتتحسّنش بالتفكير؛ الإجابة موجودة أصلاً في الـembedding space. structured extractions لما الـdata موجود في الـinput ما بتستفيدش. JSON formatting ما بيستفيدش.

اختبار مفيد قبل ما تشغّل thinking: هل failure rate الحالي بتاعك بسبب إن النموذج "مش بيحاول جامد كفاية"، ولا بسبب إن النموذج ما عندوش information محتاجها؟ thinking mode بيصلّح الحالة الأولى. ما بيصلّحش التانية. لو الإجابة الصح محتاجة fresh data النموذج ما عندوش، الـthinking هيطلّع إجابة غلط أكتر تفصيل، مش صح.

سلّم عملي

لما تشكّ إن مهمة محتاجة reasoning أكتر من اللي النموذج الأساسي بيدّيه:

1. جرّب prompt-engineered chain-of-thought الأول. ضيف "think step by step" أو "show your reasoning before the answer". ببلاش، سريع، غالباً بيكفي.
2. جرّب few-shot. مثالين أو 3 شغّالين في الـprompt بيعلّموا الـpattern. كمان ببلاش، كمان سريع.
3. اطلع لـbase model أكبر. Claude Opus 4.5 بدل Sonnet 4.5. GPT-4o بدل GPT-4o-mini. Gemini 2.5 Pro بدل Flash. تكلفة per-call أعلى، بس من غير الـlatency tax بتاع thinking mode.
4. وبعدين جرّب thinking mode. بس لو (1)–(3) ما حرّكوش الإبرة. لما توصل هنا المفروض يكون عندك benchmark تقدر تقارن بيه.

الترتيب مهم. الطفر على طول لـthinking mode هي أغلى طريقة تكتشف بيها إنك كنت محتاج few-shot.

التالي: الكتابة الإبداعية — فين thinking mode بيبقى tax من غير فايدة. :::