أطلقت DeepSeek نموذج V4 Pro المتاح للعموم (GA). وتُظهر القياسات الأولية أنه يقلل من استخدام توكنات الاستدلال (reasoning tokens) بنسبة تتراوح بين 18% و62% مقارنة بنسخة المعاينة (preview build). وهذا أمر بالغ الأهمية لكل من يدفع مقابل كل توكن: فالمطالبات (prompts) نفسها أصبحت الآن أقل تكلفة بشكل ملحوظ مع الاستمرار في تقديم مخرجات مماثلة.

ما الذي استدعى إجراء هذه المقارنة

صدر إصدار GA دون منشور مدونة أو سجل تغييرات (changelog)، مما اضطر المطورين لاكتشاف الاختلافات بأنفسهم. وقد أجرت تجربة مجتمعية مهام متطابقة على كلتا النسختين ووجدت التغيير الأكبر: انخفاض حاد في عدد التوكنات التي يقضيها النموذج في "التفكير" قبل الإجابة. ففي عمليات البحث البسيطة، استخدم نموذج GA توكنات استدلال أقل بنسبة 62%؛ أما في الاستعلامات الأكثر تعقيدًا، فكان الانخفاض بنسبة 18%.

كفاءة التوكنات وتأثيرها

في سير عمل استخراج نموذجي، استهلكت نسخة المعاينة 159 توكن استدلال لاستخراج عدد قليل من الحقول من مطالبة واحدة. ومع الانتقال إلى إصدار GA مع تعطيل ميزة "التفكير" (thinking)، انخفض هذا الرقم إلى 40 توكنًا فقط. وبالنسبة للمستخدمين الذين يعتمدون على خطط الدفع حسب الاستهلاك، تتحول هذه المدخرات مباشرة إلى فواتير أقل، خاصة عند العمل على نطاق واسع.

استخراج JSON: العقبة الخفية

تتعثر كلتا النسختين عندما يكون وضع "التفكير" مفعلًا: حيث تجتازان فحص مخطط JSON (JSON schema) ولكنهما تدرجان قيمًا رقمية خاطئة. فقط إصدار GA يعيد JSON صحيحًا عندما يتم إيقاف تشغيل "التفكير". يجب على الفرق التي تحتاج إلى مخرجات مهيكلة تعطيل علامة (flag) التفكير لمهام الاستخراج، وإلا فستتلقى بيانات صحيحة من الناحية النحوية (syntactically valid) ولكنها غير صحيحة رقميًا.

التعامل مع الرفض يغير قواعد اللعبة

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

تعزيز الموثوقية

كانت هناك حلقة مفرغة خطيرة في نسخة المعاينة — ناتجة عن ميزانية "تفكير" متواضعة — قد تجعل النموذج يكرر النص نفسه حتى تمتلئ نافذة الـ 8,192 توكن. وقد عالج إصدار GA هذا الخطأ البرمجي، مما أنهى التكرار غير المنضبط الذي كان يخاطر سابقًا باستنفاد نافذة الطلب وتضخم التكاليف.

ما يجب على المستخدمين مراقبته

  • استخدم إصدار GA لتقليل عدد التوكنات. تظل الانخفاضات المقاسة ثابتة بغض النظر عن تعقيد المهمة.
  • أوقف تشغيل "التفكير" (thinking) عند استخراج أي بيانات JSON أو بيانات مهيكلة. يؤدي ذلك إلى الحصول على قيم صحيحة ويحافظ على الحد الأدنى من استخدام التوكنات.
  • لا تعتمد على الرفض المدمج. إذا طلبت المطالبة بيانات لا يمكن التحقق منها، فقد لا يزال نموذج GA يقدم إجابة، لذا تظل عملية التحقق اللاحقة (downstream validation) ضرورية.
  • راقب الفواتير في ساعات الذروة. تجعل قواعد التسعير الجديدة استهلاك التوكنات خلال فترات حركة المرور العالية يؤثر على الإنفاق الإجمالي بشكل أكثر حدة من ذي قبل.

الخلاصة

يقدم نموذج DeepSeek V4 Pro GA فوزًا واضحًا في الكفاءة — حيث يقلل توكنات الاستدلال بنسبة تصل إلى 62% — ويصلح خطأً برمجيًا حرجًا يتعلق بالتكرار. ومع ذلك، فإن فقدان استجابات الرفض الصريحة والحاجة إلى تعطيل التفكير للحصول على مخرجات JSON دقيقة يضيفان اعتبارات جديدة. يمكن للفرق التي تكيف مسارات عملها (pipelines) خفض التكاليف دون التضحية بالوظائف.

المصدر: https://dev.to/synthorai/deepseek-v4-pro-ga-vs-preview-measured-18-62-less-thinking-539l