Opus 4.7 من Anthropic يستهلك رموزًا أكثر: تضخم خفي مع بقاء الأسعار على حالها

يحوّل المُرمِّز في Opus 4.7 من Anthropic النص نفسه إلى عدد رموز أكبر مما كان عليه في Opus 4.6. ورسميًا لم تتغير الأسعار ولا حدود السياق، لكن تكاليف API ترتفع عمليًا، وهو ما يمكن وصفه بـ«التضخم الخفي». واختبر مطورون من Kodik أنواعًا مختلفة من النصوص عبر API، وتبيّن لهم في أي الحالات يكون ارتفاع عدد الرموز أكبر ما يمكن، وفي أيها يكاد لا يُلحظ.

معالج بواسطة الذكاء الاصطناعي من Habr AI؛ بتحرير Hamidun News
Opus 4.7 من Anthropic يستهلك رموزًا أكثر: تضخم خفي مع بقاء الأسعار على حالها
المصدر: Habr AI. كولاج: Hamidun News.
استمع للمقال
بطاقة الحقائق والأرقام
المعيارالتفاصيل
المصدر الأصليHabr AI ↗
رئيس التحرير
حقيقة رئيسية #1الأكواد — ارتفاع ملموس، خصوصًا في اللغات التي تكثر فيها الرموز الخاصة: العوامل والأقواس والمسافات البادئة
حقيقة رئيسية #2السلاسل التقنية (JSON وXML وYAML وSQL) — تتفاوت التغيرات بحسب البنية؛ وقد تكون الزيادة أكبر في البنى المتداخلة
حقيقة رئيسية #3موجّهات النظام — تتأثر كما تتأثر طلبات المستخدمين؛ وهذا حسّاس بوجه خاص للمنتجات التي تعتمد تعليمات system طويلة

أصدرت Anthropic نموذج Claude Opus 4.7، وأظهرت الاختبارات الأولى عبر API نتيجة غير متوقعة: قد يشغل النص نفسه في النموذج الجديد عددًا أكبر بكثير من الرموز مقارنةً بـ Opus 4.6. ومع بقاء الأسعار دون تغيير رسميًا، يعني ذلك ارتفاعًا غير ملحوظ لكنه حقيقي في التكاليف.

جوهر المشكلة

المُرمِّز (tokenizer) هو المكوّن الذي يقسّم النص إلى أجزاء قبل تمريره إلى النموذج. وعدد هذه الأجزاء هو ما يحدد تكلفة الطلب وحجم نافذة السياق التي يشغلها. وحين تغيّر Anthropic المُرمِّز بين إصدار وآخر، يصبح «وزن» الموجّه (prompt) نفسه مختلفًا. وفي حالة Opus 4.7 ازداد هذا الوزن. فإذا كان طلبك المعتاد يشغل سابقًا 1 000 رمز، فقد يشغل الآن ما بين 1 300 و1 500. وأسعار المليون رمز لم تتغير، لكنك عمليًا تستهلك رموزًا أكثر لإنجاز العمل نفسه.

«النتيجة تضخم خفي: الأسعار والحدود المعلنة هي نفسها، لكن النفقات قد ترتفع عمليًا» — من دراسة فريق

Kodik.

اختبرت شركة Kodik، التي تطوّر محرر أكواد يدعم نماذج ذكاء اصطناعي متعددة، سلوك المُرمِّز بنفسها عبر API. ولم تنشر Anthropic بيانات مقارنة رسمية، ولذلك أجرى المطورون الاختبارات بأنفسهم وشاركوا استنتاجاتهم.

أي أنواع المحتوى أكثر تأثرًا

لا يتساوى ارتفاع عدد الرموز بين أنواع النصوص المختلفة. وبحسب البيانات المتاحة، تبدو الصورة على النحو التالي:

  • الأكواد — ارتفاع ملموس، خصوصًا في اللغات التي تكثر فيها الرموز الخاصة: العوامل والأقواس والمسافات البادئة
  • السلاسل التقنية (JSON وXML وYAML وSQL) — تتفاوت التغيرات بحسب البنية؛ وقد تكون الزيادة أكبر في البنى المتداخلة
  • موجّهات النظام — تتأثر كما تتأثر طلبات المستخدمين؛ وهذا حسّاس بوجه خاص للمنتجات التي تعتمد تعليمات system طويلة
  • النص العادي — ارتفاع معتدل، وهو أقل وضوحًا في الطلبات القصيرة
  • المحتوى المختلط (نص + كود + JSON) — سلوكه غير متوقع، ويُستحسن اختباره في السيناريو المحدد

ومن المهم مراعاة حجم الاستخدام: فإذا ارتفع طول الموجّه بنسبة 20%، وكنت ترسل مليون طلب يوميًا، فسيتغير الحساب الفعلي تغيرًا كبيرًا جدًا.

لماذا تُعدّ هذه مشكلة منهجية

حالة Opus 4.7 ليست استثناءً. فقد يتغير المُرمِّز في أي نموذج لدى أي مزوّد، وفي كثير من الأحيان لا يرد ذلك صراحةً في ملاحظات الإصدار (release notes). وبالنسبة للفرق التي تبني منتجاتها فوق API، يخلق هذا عدة مخاطر.

مفاجآت الميزانية. قد تُتجاوز فجأةً الحدود المحسوبة استنادًا إلى بيانات تاريخية بعد تغيير النموذج، حتى لو لم تتغير الطلبات نفسها.

تجاوز نافذة السياق. النظام الذي كان يتسع سابقًا ضمن 128k رمز قد يبدأ بعد التحديث في اقتطاع السياق أو إرجاع خطأ.

اختبارات A/B غير عادلة. عند مقارنة جودة إصدارين من النموذج على البيانات نفسها، يعني اختلاف المُرمِّز أن النموذجين يتلقيان مدخلًا مختلفًا من الناحية التقنية، وهذا يؤثر في تفسير النتائج.

تراجع خفي في خطوط RAG. إذا كنت تجمّع المقاطع (chunks) وفق حد معين من الرموز، فقد يخلّ تغيير المُرمِّز بمنطق التقسيم دون أي خطأ واحد في السجلات.

ماذا يعني ذلك

على المطورين الذين يستخدمون Opus بالفعل في بيئة الإنتاج (production) أو يخططون للانتقال إلى 4.7 أن يمرّروا موجّهاتهم الفعلية عبر tokenizer API لكلا الإصدارين قبل التحويل. سيستغرق ذلك بضع ساعات، لكنه يتيح تقدير الزيادة في التكاليف بصدق، وتعديل الميزانية أو البنية المعمارية وفقًا لذلك.

تُعدّ حالة Opus 4.7 تذكيرًا جيدًا: عند ترقية النموذج، لا تتحقق من جودة الإجابات فحسب، بل تحقق أيضًا من كفاءة الترميز.

القصة

أسئلة وأجوبة حول الخبر

ما أبرز التفاصيل حول جوهر المشكلة؟

المُرمِّز (tokenizer) هو المكوّن الذي يقسّم النص إلى أجزاء قبل تمريره إلى النموذج. وعدد هذه الأجزاء هو ما يحدد تكلفة الطلب وحجم نافذة السياق التي يشغلها. وحين تغيّر Anthropic المُرمِّز بين إصدار وآخر، يصبح «وزن» الموجّه (prompt) نفسه مختلفًا. وفي حالة Opus 4.7 ازداد هذا الوزن. فإذا كان طلبك المعتاد يشغل سابقًا 1 000 رمز، فقد يشغل الآن ما بين 1 300 و1 500. وأسعار المليون رمز لم تتغير، لكنك عمليًا تستهلك رموزًا أكثر لإنجاز العمل نفسه. «النتيجة تضخم خفي: الأسعار والحدود المعلنة هي نفسها، لكن النفقات قد ترتفع عمليًا» — من دراسة فريق Kodik. اختبرت شركة Kodik، التي تطوّر محرر أكو

ما أبرز التفاصيل حول أي أنواع المحتوى أكثر تأثرًا؟

لا يتساوى ارتفاع عدد الرموز بين أنواع النصوص المختلفة. وبحسب البيانات المتاحة، تبدو الصورة على النحو التالي: الأكواد — ارتفاع ملموس، خصوصًا في اللغات التي تكثر فيها الرموز الخاصة: العوامل والأقواس والمسافات البادئة السلاسل التقنية (JSON وXML وYAML وSQL) — تتفاوت التغيرات بحسب البنية؛ وقد تكون الزيادة أكبر في البنى المتداخلة موجّهات النظام — تتأثر كما تتأثر طلبات المستخدمين؛ وهذا حسّاس بوجه خاص للمنتجات التي تعتمد تعليمات system طويلة النص العادي — ارتفاع معتدل، وهو أقل وضوحًا في الطلبات القصيرة المحتوى المختلط (نص + كود + JSON) — سلوكه غير متوقع، ويُستحسن اختباره في السينار

ما أبرز التفاصيل حول لماذا تُعدّ هذه مشكلة منهجية؟

حالة Opus 4.7 ليست استثناءً. فقد يتغير المُرمِّز في أي نموذج لدى أي مزوّد، وفي كثير من الأحيان لا يرد ذلك صراحةً في ملاحظات الإصدار (release notes). وبالنسبة للفرق التي تبني منتجاتها فوق API، يخلق هذا عدة مخاطر. مفاجآت الميزانية. قد تُتجاوز فجأةً الحدود المحسوبة استنادًا إلى بيانات تاريخية بعد تغيير النموذج، حتى لو لم تتغير الطلبات نفسها. تجاوز نافذة السياق. النظام الذي كان يتسع سابقًا ضمن 128k رمز قد يبدأ بعد التحديث في اقتطاع السياق أو إرجاع خطأ. اختبارات A/B غير عادلة. عند مقارنة جودة إصدارين من النموذج على البيانات نفسها، يعني اختلاف المُرمِّز أن النموذجين يتلقيان مدخلً

ZK
جمال حميدون — مدير المنتجات في Alpina Digital ومدير منتج AlpinaGPT. يبني منتجات الذكاء الاصطناعي منذ 2019. بدأ Hamidun News كمشروع شخصي ثم أصبح مُجمِّعًا إنتاجيًا بأكثر من 6000 قارئ.
✦ Private AI Builders Community · Vibe Club

Ship AI Faster with Founders, Engineers & Weekly Architecture Reviews

Inside Vibe Club (hamidun.com/club) — weekly live masterminds with Zhemal Khamidun, Tech Radar, full LMS access, and 370+ production Claude Code skills.

Join Vibe Club →Explore Hamidun Academy
ما رأيك؟
جارٍ تحميل التعليقات…