Ricursive تطلق Ripple-65B: النموذج يحقق 80,5% على Terminal-Bench 2.1

عندما يصلح الوكيل خللًا برمجيًا، يُنفق الوقت والمال على المسار كاملًا: قراءة الملفات، وتحديد السبب، وإجراء التعديل، وتشغيل الاختبارات، وفهم الخطأ الجديد. وتطرح Ricursive نموذج Ripple-65B Preview لهذا النوع من العمل. والفائدة العملية واضحة: اختبار قدرة النموذج على التعامل مع مستودعك بزمن استجابة وتكلفة مقبولين. فهل يستطيع، مثلًا، إصلاح معالج API معطّل بمفرده وتأكيد النتيجة باختبار؟

هذا نموذج بأوزان مفتوحة يضم 65 مليار معلمة. وفي التقييم الذي نشره مطوروه، حقق 80,52% على Terminal-Bench 2.1. وسجل Reflection Beam في الجدول نفسه 80,1%. الفارق ضئيل، لذا سيكون عنوان يعلن فوزًا حاسمًا مبالغة. والأهم هو إتاحة مرشح إضافي لتشغيل وكيل برمجي. المصدر: Ricursive.

ما الذي أُطلق تحديدًا؟

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

يعلن المطورون عن نافذة سياق تصل إلى 1 048 576 توكن. وقد نُشرت الأوزان بموجب Apache 2.0، وتتوفر نسختا BF16 وNVFP4. وبالنسبة إلى فريق لديه اشتراطات تتعلق بمكان استضافة الشيفرة، يوسّع ذلك الخيارات المتاحة، إذ يمكنه النظر في نشر النموذج على بنيته التحتية الخاصة. لكن حجم السياق لا يبيّن وحده مدى موثوقية الوكيل في العثور على التبعية المطلوبة بين مئات الملفات. المصدر: بطاقة النموذج.

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

لماذا لا تنطبق نتيجة الاختبار مباشرة على مستودعك؟

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

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

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

كيف تختبر فائدته للفريق؟

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

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

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