ترقية النموذج تغيّر عقد التكامل، لا معرّف النموذج وحده

أصدرت Anthropic نموذج Claude Sonnet 5.5 في 28 سبتمبر، وأعلنت تحسنًا في السرعة وكفاءة إنجاز المهام. وبالنسبة للفرق التي تُنشئ طلبات Messages API بنفسها، يستحق دليل الترحيل اهتمامًا لا يقل عن ادعاءات الأداء؛ فهو يوضح تغييرات في المعلمات المقبولة وكيفية التعامل مع سجل المحادثة. أما مستخدمو Claude Managed Agents، فتقول Anthropic إن عليهم تحديث اسم النموذج فقط. ويركز التحليل التالي على تكاملات API المخصصة. [1] [2]

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

كان Sonnet 5 يقبل thinking: {"type": "disabled"}. أما Sonnet 5.5 فيرفض هذا الإعداد بخطأ 400. وأدنى إعداد للتفكير فيه هو between_tools، ويتاح مع مستويات الجهد low وmedium وhigh؛ بينما يُرفض مع xhigh وmax. هذا تغيير في عقد الطلب، لا مجرد تفضيل لضبط الأداء. وعلى الفرق التي استخدمت disabled للتحكم في زمن الاستجابة أن تختار الإعداد الجديد عن قصد وأن تعيد قياس سير العمل، بدل افتراض أن الطلب القديم سيستمر كما هو. [2]

يلغي وضع between_tools التفكير المطوّل قبل بدء الإجابة، لكن ملاحظات التقدم بين استدعاءات الأدوات قد تظل تظهر في كتل thinking. ويجب أن تعيد حلقة الأدوات هذه الكتل دون تعديل ضمن رسالة المساعد كاملة. وتحتاج إلى مراجعة البرامج التي تفترض أن أول كتلة محتوى نص، أو تعيد بناء رد المساعد من النص واستدعاءات الأدوات فقط. اقرأوا المحتوى بحسب نوع الكتلة، وأعيدوا تمرير رسالة المساعد كما أعادتها واجهة API. [2] [6]

يرفض Sonnet 5.5 قيمتي tool وany اللتين تفرضان استدعاء أداة عبر tool_choice. وتوصي Anthropic باستخدام auto مع مخططات أدوات صارمة حيث تتاح. فصرامة المخطط تقيّد شكل استدعاء الأداة إن حدث؛ لكن auto يتيح للنموذج أن يجيب من دون استدعاء أي أداة. ولا يتيح Amazon Bedrock استخدام الأدوات الصارمة لهذا النموذج، لذا يجب أن تتحقق التطبيقات هناك من مدخلات الأدوات بنفسها. [2] [4]

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

لا يمكن إعادة استخدام كتل thinking التي ينتجها Sonnet 5.5 إلا بالحساب الذي أنشأها أو بحساب مرتبط به. فإذا أعاد حساب غير مرتبط إرسال كتلة منها، تسقطها API قبل الاستدلال ومع ذلك ينجح الطلب؛ ومن دون ترويسة التشخيص المعنية يحدث الإسقاط بصمت. وقد يجعل تبديل النموذج الكتلة غير قابلة للقراءة أيضًا. لذلك لا تثبت استجابة الموجّه الناجحة أن النموذج تلقّى محتوى التفكير السابق. [3]

وهناك قاعدة مستقلة تخص ما سبق الكتلة في المحادثة: يجب ألا تتغير تعليمات النظام والأدوات والرسائل السابقة عند إعادة إرسال كتلة thinking موقّعة. ويُفرض هذا الفحص افتراضيًا على الحسابات المنشأة في 31 أغسطس 2026 أو بعده؛ أما الحسابات الأقدم فتختلف إعداداتها الافتراضية، لذا فإن اختبارًا بلا خطأ باستخدام مفتاح واحد لا يثبت سلامة جميع الحالات. حافظوا على السجل بإضافة الرسائل فقط، واختبروا أثناء الترحيل الحفظ والاستئناف، وتغيير الأدوات، واختصار السجل في العميل، وتبديل مسار التوجيه. وحيث يتاح، افحصوا input_transformations لمعرفة ما إذا كانت كتل قد أُسقطت. [3]

يدعو دليل الترحيل أيضًا إلى التعامل مع نتائج الرفض. وينبغي إدخال الرفض ضمن منطق الاستجابة والمراجعة في المنتج؛ فإعادة إرسال الطلب بلا تمييز كما لو كان فشلًا شبكيًا تخلط نتيجة مرتبطة بالسياسة بانقطاع الخدمة. وتوثّق Anthropic خيار انتقال احتياطي محدودًا على جانب الخادم لبعض فئات الرفض في Claude API، لكنه لا يجعل كل رفض قابلًا لإعادة المحاولة، ولا يَعِد بالسلوك نفسه على جميع منصات الاستضافة. [5]

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

نقترح خمسة مسارات للقبول: طلبًا قديمًا يعطّل التفكير؛ واستدعاء أداة كان يُفرض سابقًا؛ وتبادلًا متعدد الخطوات مع أداة تُعاد فيه كتل thinking؛ ومحادثة محفوظة تُستأنف باستخدام الحساب وإعداد التوجيه الفعليين؛ ورفضًا يتعامل معه المنتج. افحصوا حالة HTTP، وأنواع كتل المحتوى، وتنفيذ الأدوات والتحقق منها، وتشخيصات استمرارية المحادثة حيث تتاح، والحالة النهائية التي يراها المستخدم. وأدرجوا جلسة طويلة وتبديلًا للمسار، لأن الاختبار الأولي لتبادل واحد لا يكشف أخطاء السجل.

بعد ذلك فقط، قارنوا نسبة المهام المقبولة، والزمن المنقضي، وتكلفة كل مهمة مقبولة عند مستوى جهد محدد. وادعاءات Anthropic عن السرعة والتكلفة فرضيات مفيدة لهذه التجربة، وليست بديلًا عنها. والدرس الأوسع يتجاوز هذا الإصدار: النموذج جزء من بروتوكول يربط التطبيق والأدوات والسجل والمستخدمين. ولا تكتمل ترقيته إلا حين يواصل ذلك البروتوكول تقديم النتيجة المقصودة. [1]