يواجه نموذج Claude الخاص بـ Anthropic تحديات تقنية في توليد الكود وموثوقية الوكلاء

واجه Anthropic مؤخرًا تحديات تقنية متعددة في نماذج Claude. إن إنشاء الكود يعاني من انخفاض في المرونة بسبب قيود إدخال العلامات المائية؛ إن آلية التفكير التكيفي في Sonnet 5 تسمح لنفس النموذج بضبط مستويات مختلفة من الموارد الحسابية، مما يُضبِّط حدود القدرات بين خطوط المنتجات؛ على الرغم من أن سياق 1M يبدو وافياً، إلا أن النموذج يستخدم فعليًا فقط حوالي 20%-30% منه خلال محادثات Agent الطويلة، ثم يواجه لاحقًا فوضى في الحالة وإغفالات؛ عند ضغط السياق، يصعب التمييز بين المعلومات التي لا تزال صالحة، وقد تُحوَّل الافتراضات المؤقتة إلى حقائق عن طريق الخطأ؛ بعد أن يُعدِّل Agent البيئة بنشاط، يبدأ النموذج في تحليل الأخطاء الجديدة التي أنشأها بدلاً من المشكلة الأصلية. تشير المقالة إلى أن موثوقية Agent الطويل تصبح أكثر اعتمادًا على وضوح الحالة، وقابلية التحقق من الإجراءات، وقدرة التراجع عن الأخطاء، بدلاً من أداء النموذج في خطوة واحدة فقط.

مؤلف المقال، المصدر:雷锋网

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

أنثروبيك كانت تملك هذا الطعم مؤخرًا.

في الأيام القليلة الماضية، جمع منشور على X بين عدة شكاوى نموذجية من这段时间 لـ Claude: بدأ إدراج علامات قابلة للقراءة آليًا في النصوص والكود، ولم تواكب التجربة العملية لـ Sonnet 5 الضجة المحيطة بترقيات النموذج، وتباع Fable 5 بسعر أعلى، لكن من الصعب ملاحظة أي تحسن واضح مقارنة بـ Opus 5؛ بالإضافة إلى ملاحظة أكثر وضوحًا، أن سياق Fable 5 لا يُستخدم إلا حوالي 20%–30%، ثم تبدأ القدرات في الانخفاض بعد ذلك.

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

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

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

01

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

ورقة بحثية: https://arxiv.org/pdf/2301.10226

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

لكن الكود يحتوي على عدد كبير من المواقع منخفضة الإنتروبيا. بعد إعلان المتغيرات، لا يمكن استخدام سوى نفس الاسم في الإشارات اللاحقة؛ حقول JSON والعلامات والقوسين تخضع لقيود هيكلية صارمة؛ يجب أن تتوافق معلمات الدالة مع الواجهة؛ في المسارات والتعبيرات المنتظمة وSQL وأوامر Shell، تغيير رمز واحد قد يغير السلوك مباشرة.

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

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

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

لا تكشف Anthropic عن كيفية تغيير علامات النص الخاصة بـ Claude للعينة، وبالتالي لا يمكن نسب تغير جودة Claude Code مباشرة إلى خوارزمية علامة مائية معينة.

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

02

التغييرات الناتجة عن التفكير التكيفي في Sonnet 5 لا تقتصر فقط على جعل النموذج يفكر لفترة أطول.

كان من السهل سابقًا فهم Sonnet و Opus و Fable كعدة نقاط قدرات ثابتة. الآن مع إضافة effort، يمكن لنفس النموذج أن يقع في فترات مختلفة من حساب وقت الاختبار، ولم يعد الموديل نفسه قادرًا على تمثيل كامل لكمية القدرات التي تم استثمارها في طلب واحد.

رابط المرجع: https://platform.claude.com/docs/en/build-with-claude/effort

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

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

رابط المرجع: https://platform.claude.com/docs/en/build-with-claude/effort

لذلك effort لا يضبط طول thinking فحسب، بل يحدد مدى نطاق البحث المسموح به في مهمة Agent. وهذا سيغير مباشرة تدرجات نموذج Anthropic.

If a regular coding task is already easy for Opus, increasing effort will likely cause Opus to quickly enter the performance plateau. Fable, even with a stronger base model, has little remaining difficulty to convert into a noticeable experience gap.

يجب على المستخدم دفع فرق السعر بين الطرازات منذ بداية الطلب. وبالتالي، فإن القيمة التي يُظهرها Fable بسهولة أكبر ليست شرح الكود العادي أو إعادة الهيكلة الصغيرة أو تصحيح الأخطاء العادي، بل هي مهام متعلقة بمكتبات كود غير مألوفة، والتخطيط متعدد المراحل، والعمل عبر أدوات متعددة، والتنفيذ الذاتي الطويل، والمهام التي تتطلب الاستعادة بعد حدوث الأخطاء.

رابط المرجع: https://www.anthropic.com/news/claude-opus-5

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

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

03

رؤية سياق 1M تجعل من السهل تفسيره كذاكرة عمل ضخمة، لذا عندما يبدأ Claude في تفويت أو تكرار أو ظهور فوضى في الحالة باستخدام 200K أو 300K token فقط، يبدو ذلك غير بديهي للغاية.

لكن نافذة السياق تقاس بالسعة، وليس بالاتساق الحالة. جلسات الوكيل الطويلة ليست مستندًا ثابتًا، بل سجل تنفيذي متزايد باستمرار.

رابط المرجع: https://platform.claude.com/docs/en/build-with-claude/context-windows

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

المسألة التي ظهرت هنا لا تتعلق فقط باسترجاع المعلومات. يجب على النموذج ليس فقط العثور على المعلومات ذات الصلة بالمهمة الحالية، بل أيضًا تقييم ما إذا كانت هذه المعلومات لا تزال سارية الآن.

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

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

رابط المرجع: https://platform.claude.com/docs/en/build-with-claude/context-windows

لذلك، لا تتناسب تعقيد السياق الطويل بشكل بسيط مع نسبة استخدام الرموز. قد يكون المستند الثابت الذي يحتوي على 250K رمز أسهل في المعالجة بكثير من سجل العميل الذي يحتوي على 250K رمز، لأن الأخير يحتوي على كمية كبيرة من الكائنات المعدلة، والأحكام المرحلية، ونتائج الأدوات، والحالات التي أصبحت غير صالحة.

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

لذلك، فإن القيود الحقيقية لسياق 1M ليست فقط كم المعلومات التي يمكن وضعها، بل ما إذا كان النموذج لا يزال قادرًا على استعادة الإصدار الحالي بثبات مع ظهور المزيد من الإصدارات التاريخية لنفس الكائن.

04

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

عند تلخيص مقال، فإن حذف مثال واحد لا يؤثر إلا على اكتمال المعلومات؛ لكن عند ضغط مسار الوكيل، فإن إغفال شرط محدود لا يزال ساريًا قد يغير مسار التنفيذ بالكامل.

رابط المرجع: https://platform.claude.com/cookbook/tool-use-context-engineering-context-engineering-tools

لأن التجميع يجب أن يعالج ليس "ما الذي مهم"، بل "ما الذي لا يزال ساريًا الآن". قد تحتوي سجلات التاريخ على مهام مكتملة، وأحكام تم إلغاؤها لاحقًا، وقيود واجهات لا تزال سارية، ونتائج اختبار منتهية، وحلول مؤقتة. يحتاج المُجمّع إلى إعادة تنظيم هذه الحالات الزمنية لتشكيل تمثيل يمكن استخدامه في الجولة التالية.

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

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

إنها لا تضيف فقط معلومات يمكن للنموذج رؤيتها، بل تنقل بعض الحالات التي تحتاج إلى الاستمرار على المدى الطويل من السجلات النصية إلى أنظمة خارجية. يحدد Git إصدار الكود الحالي، وتقدم الاختبارات نتائج قابلة للتحقق، وتسجل ملفات المهام الحالة الإنجاز، وتميّز الحالة المُهيكلة بين الاستنتاجات الحالية والمحاولات السابقة.

يمكن للسياق الاحتفاظ بتاريخ غني، لكنه لا يمكنه تحمل مسؤولية إدارة الحالة الكاملة على المدى الطويل.

رابط المرجع: https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents

05

لا تزال الأسئلة السابقة يمكن فهمها على أنها كيفية معالجة النموذج للمدخلات. يخطو الوكيل خطوة إضافية إلى الأمام، لأنه يقوم بتعديل البيئة بشكل نشط.

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

وبالتالي لم تعد الأخطاء مجرد أخطاء تقييم، بل تصبح تغييرات في البيئة. افترض أن كلاود قام بتصنيف خطأ ما على أنه مشكلة في التخزين المؤقت، فغيّر منطق التخزين المؤقت وآلية إعادة المحاولة وعدد من نقاط الاستدعاء. ثم ظهرت مجموعة جديدة من الاستثناءات أثناء الاختبار.

هذه الاستثناءات حقيقية، لكنها ليست ناتجة بشكل طبيعي عن الخطأ الأصلي، بل نتجت عن التعديلات التي أُجريت في الجولة السابقة. وهذا سيجعل الوكيل يدخل نمط فشل خاص: حيث يبدأ النموذج في تحليل توزيع البيانات الذي أنشأه هو نفسه.

رابط المرجع: https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents

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

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

يمكن لـ Git diff أن يخبر النموذج بما هي التغييرات التي حدثت للتو، ويمكن للاختبارات التحقق مما إذا كان سلوك معين قد تضرر، ويمكن لـ checkpoint و rollback تقييد انتشار الأخطاء، بينما يمكن للمقيّم المستقل تقديم مراجعة إضافية خارج تفسير النموذج نفسه.

دور هذه المكونات هو في جوهره تعزيز قدرة العامل على تصحيح الأخطاء بشكل حلقي.

رابط المرجع: https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents

06

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

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

من الصعب التمييز بين هذين السلوكين عند النظر إلى النقطة النهائية فقط. إذا استمرت مهام الوكيل في التمديد، فستصبح المؤشرات الأكثر معنى هي: كم من الحالة الأساسية تم الاحتفاظ بها بعد التجميع، وما إذا كان يمكن تحديد الخطوات التي أدخلت الخطأ بعد حدوث تعديل خاطئ، وما إذا كانت حالة المهمة الداخلية لا تزال متسقة مع البيئة الحقيقية مع زيادة استدعاء الأدوات، وما هي التكلفة المطلوبة للعودة إلى المسار الصحيح بعد الانحراف.

هذه المؤشرات لا تقاس بذكاء استجابة واحدة، بل بقدرة المسار على البقاء تحت السيطرة.

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

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

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