لماذا يعيد نموذج الاستدلال ردًّا فارغًا: رموز التفكير الخفية تستهلك حدّ الإخراج كله

ثلاث ليالٍ متتالية لم يُنتج خط أنابيب الملخّصات أي شيء، مع أن كل طلب كان ينتهي «بنجاح»: في الرد كان يظهر finish_reason: "length" وحقل content فارغ. السبب لم يكن الشبكة ولا حدود الحساب، بل طريقة حساب نماذج الاستدلال لميزانية الإخراج: رموز التفكير غير المرئية تُخصم من نفس max_tokens المخصّص للرد الظاهر. الحدّ الذي يكفي نموذج محادثة عاديًا تحرقه نهايةً نموذج الاستدلال على التفكير الداخلي فلا يكتب كلمة واحدة.

ما الذي تعطّل بالضبط

كان خط الأنابيب بسيطًا: جمع نتائج الوظائف الخام، ثم طلب ملخّص من 200 كلمة، ثم حفظ النص. وفي منتصف الأسبوع استُبدل نموذج المحادثة بنموذج استدلال، أملًا في تلخيص أذكى وأدق. لكن كل رد جاء بـ finish_reason: "length" وcontent فارغ. لا خطأ ولا تحذير بالقطع: الطلب مرّ رسميًا، أما الجواب فلم يكن موجودًا.

السبب هو max_tokens. سبعمئة رمز تكفي بسهولة لـ200 كلمة عند نموذج محادثة، لكن ميزانية الإكمال عند نموذج الاستدلال تشمل أيضًا رموز التفكير الداخلي: آلاف الخطوات غير المرئية تُولَّد قبل أول حرف ظاهر. الحدّ البالغ 700 رمز اشترى تقريبًا صفر تفكير وصفر جواب؛ احترق النموذج في التفكير وانقطع في منتصف الفكرة. وقد أبلغ finish_reason بصدق عن length: الحدّ تحقّق فعلًا، لكنه لم يكن الحدّ الذي قصده الكاتب.

كيف تكتشف هذا العطل

أسوأ ما في الأمر هو الصمت. لا خطأ، ورمز HTTP هو 200، ولا تُفعَّل إعادة المحاولة لأن كل شيء سليم من ناحية النقل. الإشارة الوحيدة هي اجتماع حقلين: content فارغ مع finish_reason: "length". وإذا كانت المراقبة تنظر إلى finish_reason وحده أو إلى حالة الطلب فقط، فستقرأ هذا الوضع كإكمال طبيعي.

من المفيد تذكّر أن الاسم نفسه للمعامل يعني شيئًا مختلفًا عند كل فئة من النماذج. الواجهة المتوافقة مع OpenAI تخفي هذه الفروق: max_tokens عند نموذج المحادثة هو الرد كله تقريبًا، وعند نموذج الاستدلال هو الرد مضافًا إليه سلسلة تفكير طويلة. وإذا كنت تمرّر النص نفسه عبر عدة عائلات من النماذج من نقطة واحدة، فافحص لكل عائلة ما يعنيه كل حقل في الرد.

إصلاحان بقيَا في الكود

• رُفعت ميزانية الإكمال لنماذج الاستدلال إلى نحو 4 000 رمز. صارت الملخّصات أدق، ولم ترتفع الفاتورة تقريبًا: رمز التفكير الواحد رخيص، لكن من السهل إساءة حسابه بالجملة.
• الآن يُعدّ content الفارغ مع finish_reason: "length" خطأً كاملًا لا نجاحًا صامتًا. مثل هذا الرد يذهب إلى إعادة المحاولة والسجل، لا إلى قاعدة البيانات كنتيجة جاهزة.

وهناك استنتاج ثالث أقل وضوحًا: إذا نقلت خط أنابيب من نموذج محادثة إلى نموذج استدلال، فأعد حساب حدود الإخراج لا السعر وحده. وإلا فستحصل على السيناريو نفسه: طلبات ناجحة شكليًا وسطور فارغة في قاعدة البيانات.

ماذا تقول أرقامنا

الانقطاعات الصامتة ليست نادرة في خدمات التوليد أيضًا. بحسب تجميعات قاعدة الإنتاج (ملف server/seo/benchmarkData.json، بلا نصوص أو معرّفات) خلال 30 يومًا، من 4 سبتمبر إلى 4 أكتوبر 2026، مرّ عبر المنصة 12 689 عملية توليد: 9 907 صور و2 334 فيديو و448 مقطعًا موسيقيًا. ومن 3 518 عملية توليد نهائية لنموذج gpt-image-2 خلال 90 يومًا (6 يوليو — 4 أكتوبر 2026) بلغت نسبة النجاح 92,2%، ولنموذج seedream-45 — 91,9% من 1 127 عملية. أما نموذج الفيديو kling-3.0 فبلغت نسبة نجاحه 79,7% من 374 عملية في الفترة نفسها: الفيديو أصعب بطبيعته، والقطع بسبب حدّ الإخراج ليس إلا نوعًا واحدًا من الانقطاعات «الصامتة» التي لا يظهرها مجرد حالة الطلب.

مصدر التحليل — مقال «max_tokens=700 on a reasoning model returned empty replies — hidden thinking tokens was the whole budget» في مدونة dev.to. والمزيد من الشروح العملية في مدونتنا.