تفيد Anthropic بأن حملة استمرت أسبوعين في أغسطس جعلت المهام الأساسية على claude.ai وتطبيق Claude المكتبي أسرع بنحو ثلاثة أضعاف. ويقدم تقريرها الهندسي المنشور في 23 سبتمبر جوابًا أنفع من رقم العنوان وحده: إذ يبيّن الإجراءات التي تسارعت، وكيف تحقق الفريق من قياساته، والقرارات والإصدارات التي ظل المهندسون مسؤولين عنها.

التغيير الأبرز

  • ما الذي تغيّر: تفيد Anthropic بأن أوقات الانتظار انخفضت عبر 13 قياسًا لإجراءات شائعة على الويب والحاسوب المكتبي. ورقم 3.1 ضعف هو المتوسط الهندسي لهذه التحسينات، مقيسًا عند المئين الـ75 في 13 و27 أغسطس. وهذه نتيجة للشركة تخص مسارات استخدام مختارة.
  • لماذا يهم ذلك: بالنسبة لمستخدمي Claude، يتغير جزء متكرر من استخدام المنتج حين تصبح صفحة ويب جديدة جاهزة للكتابة في 550 ملّي ثانية بدلًا من 3,085. وبالنسبة إلى فرق الهندسة، توضح هذه الحالة كيف عمل مساعد ذكاء اصطناعي على معالجة مشكلات أداء مقاسة، بينما اختار البشر الأولويات وأجازوا التغييرات.
  • ما الذي ينبغي مراقبته: تقول Anthropic إن المئين الـ95 ومسارات الاستخدام الأخرى والمحادثات الطويلة جدًا ما زالت بحاجة إلى تحسين. وستبين هذه المقاييس ما إذا كانت المكاسب المُعلنة تتجاوز الإجراءات المختارة ومقارنة أغسطس.

ما الذي كسبه المستخدمون

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

في تحميل جديد لصفحة claude.ai على الويب، انخفض الزمن حتى تصبح الصفحة جاهزة للكتابة عند المئين الـ75 من 3,085 إلى 550 ملّي ثانية، أي تحسن بمقدار 5.6 أضعاف. وانخفض تشغيل تطبيق الحاسوب المكتبي باردًا من 6,310 إلى 3,328 ملّي ثانية، أي 1.9 ضعف. كما انخفض تحميل جلسة Claude Cowork سحابية على الحاسوب المكتبي من 2,566 إلى 728 ملّي ثانية، أي 3.5 أضعاف. وانخفض الجزء الواقع على جانب العميل من إرسال رسالة دردشة عبر الويب من 180 إلى 59 ملّي ثانية، أي 3.1 أضعاف. وهذه إجراءات مختلفة على منصات مختلفة؛ ورقم 3.1 ضعف الإجمالي هو المتوسط الهندسي لنسب التحسن الـ13 كلها، لا نتيجة مهمة واحدة.

تستخدم المقارنة قياسات Anthropic لمراقبة استخدام العملاء الفعليين عند المئين الـ75 في 13 أغسطس و27 أغسطس. ولا تنشر التدوينة تدقيقًا مستقلًا، أو نتيجة عند المئين الـ95 لهذه المسارات، أو تقديرًا مضبوطًا لمقدار التحسن الناتج عن مساعدة Claude. وتقدّر Anthropic أن الإجراءات الأسرع توفر عشرات الآلاف من ساعات انتظار المستخدمين يوميًا، لكنها لا تعرض الحساب وراء هذا التقدير.

دورة القياس وراء التغييرات

بدأ الفريق بنحو 20 مشروعًا اختارها المهندسون. وتقول Anthropic إنها استخدمت Claude Tag، وهو وكيل تجريبي يعمل بنموذج بحث داخلي يقارب Opus 5.5، لاكتشاف الاختناقات وبناء المعايير واقتراح تغييرات. ويقول الفريق إنه بلغ 12 هدفًا من أصل 13 أوليًا بحلول اليوم الثالث، ثم وضع أهدافًا جديدة وبحث عن مشكلات لم تكشفها أدوات المراقبة الموجودة.

بدأ أحد الأمثلة بتسجيل يُظهر تحرك صفوف الشريط الجانبي بعد تحميل الصفحة. ولم يُبرز مقياس «تغيّر التخطيط التراكمي» الموجود المشكلة. واقترح مهندس استخدام واجهة برمجة التطبيقات Layout Instability الأساسية. ثم أضاف Claude بيانات قياس تحدد منطقة الصفحة المتأثرة واختبار تكامل يؤخر تحميل بيانات الشريط الجانبي. وتفيد Anthropic بأن الاختبار فشل في كل واحدة من مرات التشغيل العشرين على الشيفرة الأصلية، ونجح في المرات العشرين كلها على الإصلاح المقترح. وبعد نشر قياس البيانات، تقول الشركة إنها رصدت حركة بعد أن أصبحت الصفحة قابلة للاستخدام في 31% من مرات التحميل على الويب. وهذا مثال موثق من حملة Anthropic؛ ولم تُعِد «بيغ تشينج» قياسه.

واستخدم الفريق أيضًا قياسات المختبر لتسريع العمل بين الإصدارات. ففي مسارين كثيفي الاستخدام في JavaScript، قارن عدد التعليمات المحدد حتميًا بالزمن المنقضي على المعايير نفسها. وتفيد Anthropic بأن خفض عدد التعليمات بنسبة 48% و31% ترافق مع انخفاض زمن الساعة الفعلي بنسبة 78% و44%. وجعل الفريق أعداد التعليمات حدودًا في التكامل المستمر، ثم خفّض الحدود مع تحسن الأداء. ويقول إنه استبعد المعايير غير الموثوقة أو التي لم تتبع زمن استجابة المستخدمين. وهذا فرق مهم: فقد ساعد عدّاد مختبري في توجيه التغييرات، بينما تحققت قراءات المستخدمين الفعليين من فائدة العمل بعد شحنه.

أين ظل البشر ممسكين بزمام الأمور

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

مرّ الإصدار بعدة فحوص. وتقول Anthropic إن كل طلب دمج خضع لمراجعة آلية وموافقة بشرية واحدة على الأقل، وإن اختبارات الوحدات سبقت التحسينات. ووُضعت التغييرات الظاهرة للمستخدم خلف مفاتيح ميزات قصيرة الأجل. ووصلت التغييرات عالية المخاطر إلى الموظفين أولًا، ثم 1% من المستخدمين، ثم الجميع. وأدخل الفريق قرابة 200 مفتاح خلال الحملة، ويقول إنه أزال أكثر من نصفها قبل نهايتها. وتفيد Anthropic بدمج أكثر من 3,000 تغيير من دون حادثة تواجه العملاء أو تراجع عن إصدار. وهذه رواية الشركة عن تلك الحملة؛ ولا تثبت النتيجة نفسها لفريق أو قاعدة شيفرة أخرى.

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

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