إعادة كتابة Campfire بالـ agents في Rust وElixir وGo تكشف أن المقارنة كانت بين مواصفات مختلفة
المغزى: حين لا يحدد الطلب الموجَّه إلى الـ agent قرارات التصميم، يتخذها الموديل بصمت، فتصبح مقارنة اللغات مقارنة بين قرارات لم يرها أحد.
وسم
المغزى: حين لا يحدد الطلب الموجَّه إلى الـ agent قرارات التصميم، يتخذها الموديل بصمت، فتصبح مقارنة اللغات مقارنة بين قرارات لم يرها أحد.
المغزى: إعادة تشغيل التجربة حتى تظهر نتيجة جيدة، وضبط الأرقام حتى يرتفع الرقم، يبدوان في تقرير الـ agent مثل التقدم تمامًا، والسؤال الأول أمام أي تحسن معلن هو هل هو فكرة أم انتقاء.
المغزى: الفارق الكبير في أداء Python لم يعد في رقم النسخة بل في اختيار المفسّر، فالترقية وحدها تعطي تحسنًا طفيفًا، أما إزالة الـ GIL فتغيّر النتيجة في العمل المتوازي.
المغزى: القياس الذي يستغرق أقل من 10 ميلي ثانية يقيس أدوات القياس أكثر مما يقيس الكود، والـ benchmark أداة لبناء الحدس لا آلة دقة.
المغزى: مختبر أمريكي يطلق أول نموذج مفتوح له فيعرّف نفسه بالكفاءة لا بالصدارة، ويسمّي المتقدمين عليه وكلهم صينيون. والرخصة، لا جدول الأرقام، هي ما يحدد إن كان البناء فوقه ممكنًا.
المغزى: إطفاء الـ reasoning لتوفير الـ tokens يطفئ معه قدرة الموديل على أي عملية تحتاج خطوات، والموديل لا يخبر المستخدم أنه خمّن الجواب.
الإحساس بتراجع جودة نموذج لا يثبت شيئًا، لكن عدّاد الـ tokens قد يفعل. فخفض مستوى التفكير يغيّر الاستهلاك بأكثر مما يغيّر الدقة.
الفارق بين الطريقة الأبسط والنموذج الأكبر قد يكون بضع نقاط وقد يكون صفرًا، ولا يظهر إلا بالقياس على بيانات المنتج نفسه، قبل الالتزام بتكلفة API على كل طلب.
التقييمات التي أُجريت على النموذجين في أيامهما الأولى قاست خللًا في خطوة قبل النموذج لا النموذج نفسه، والانطباع الذي تكوّن حينها قد يبقى بعد زوال سببه.
من يستخرج بيانات بنموذج لغوي دون تعليمة صريحة للحقول الغائبة قد يحصل على حقل مختلق من كل ثلاثة حقول ناقصة، بشكل سليم لا يلفت النظر. وخدمة مدفوعة واحدة كانت أسوأ من معظم النماذج.
نسبة الثقة قد تؤدي وظيفة نفسية أكثر منها هندسية، إذ تمنح شعورًا بالتحكم في المخاطرة دون قياسها، ويظهر ذلك بعد الإطلاق حين يُسأل عن مصدر الحد الفاصل.
فئة النموذج السريع والرخيص والأقل ذكاء صار فيها مرشح جدي، فأصبح اختيار النموذج قرار منتج يتعلق بما ينتظره المستخدم، لا قرارًا تقنيًا فقط.
حين يكون النموذج أرخص بفارق كبير وأضعف بفارق قابل للقياس، يصبح الاختيار بين النماذج قرارًا بحسب شكل المهمة لا بحسب ترتيب الجداول.
حين يكون الوقت جزءًا من المهمة، يصبح التفكير الإضافي تكلفة لا ميزة، ويصبح فشل التنسيق بين الـ agents أخطر من ضعف النموذج نفسه.
في تشغيل النماذج محليًا، القرار الحاسم ليس اختيار النموذج بل اختيار نسخته المضغوطة، وهو الطريق الوحيد المتاح لمن لا يملك وسيلة دفع دولية.
الرقم نفسه كان صحيحًا في المرتين، والإعداد هو الذي روى قصتين متعاكستين. أول سؤال أمام أي اختبار أداء ليس من فاز، بل كيف قيس.
جزء من فاتورة الـ coding agents لا يذهب إلى العمل بل إلى السياق الذي ترسله الأداة في أول نداء، ويُدفع تلقائيًا عند قبول الأداة الافتراضية دون مقارنة.
جدول النتائج النهائي يخبر بالنتيجة، أما اللوحة الحية فتكشف التكلفة: التشغيلات التي توقفت، والبيانات التي حُذفت، والساعات التي ضاعت في خطأ لم يُكتشف.
المسائل الرياضية هي أفضل حالة ممكنة للنماذج لأن مواصفاتها دقيقة، بينما معظم العمل البرمجي اليومي بلا مواصفة مكتوبة، وكتابتها أغلى من البناء نفسه.
تصميم التجربة يحدد الرقم قبل أن تبدأ، وقراءة المنهجية قبل النتيجة هي الفرق بين رأي مبني على قياس ورأي مبني على ظروف لا يعمل بها أحد.
أكبر خسائر الـ agent في مهمة طويلة جاءت من ضعف المتابعة لا من نقص الذكاء، والاختبار الذي يقيس ردًا واحدًا لا يكشف ما يحدث لـ agent يعمل أسبوعين.
الفجوة بين أرقام إعلانات النماذج وأدائها على مستودعات الفرق الحقيقية قد لا تعود إلى صياغة الطلب، بل إلى أن الاختبارات الشهيرة مبنية على كود رآه النموذج أثناء تدريبه.
نسب التوفير التي تعلنها الأدوات محسوبة على الجزء الذي تعمل عليه وحده، لا على الفاتورة كاملة، والفرق بين الرقمين قد يقلب النتيجة.
نسبة توفير بلا سعر أساس معلن لا تدخل في أي حساب، ونموذج بلا API مستقل ولا أوزان مفتوحة هو اشتراك في منتج أكثر منه نموذجًا يُبنى عليه.
الخلاف حول ضرر الضغط على النماذج يحسمه عدد الـ bits: عند 4 bits لا فرق يُذكر ويكفي كارت واحد، وعند 1 bit ينهار النموذج.
الاختبار المنشور يتسرّب مع الوقت إلى بيانات التدريب، فتقيس الدرجة أن النموذج رأى السؤال لا أنه يعرف حله، والمرتبة الأولى في الترتيب العام لا تعني الأفضل في كل مهمة.
سعر الـ token المتطابق لا يعني فاتورة متطابقة. فالنموذج الأدق يستهلك ضعف الـ tokens، والمقارنة الصحيحة تكون على بيئة اختبار واحدة لا بين جدولين.
حين يتجاوز الجميع 95% في اختبار واحد، يصبح الرقم دليلًا على الانتماء إلى المجموعة لا على التفوق، ويصعب معه التمييز بين نموذج أرخص قريب فعلًا ونموذج لا يرى الاختبار الفرق بينهما.
القرار الحقيقي ليس أي نموذج أقوى، بل هل تستفيد المهمة من تفكير إضافي. وإعداد الـ effort الافتراضي، الذي لا يراجعه أحد، قد يحدد الفاتورة أكثر من اسم النموذج.
التحسن هنا جاء من التدريب اللاحق وحده دون تغيير المعمارية، ومع رخصة MIT يصبح نموذج قادر على العمل البرمجي متاحًا للتشغيل الذاتي دون ربطه بحساب أو قرار خارجي.