Gemini 4 Argon: من يراجع مخرجات من مليون توكن؟

أعلنت Google عن Gemini 4 Argon في 30 سبتمبر، بحد للمخرجات يبلغ مليون توكن، بعدما كان 64K. ولا يحدد الإعلان هنا ما إذا كانت توكنات التفكير تُحتسب ضمن هذا الحد. إنه سقف معلن، وليس دليلًا على تقديم مليون توكن من العمل النهائي المفيد. [1]

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

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

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

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

تعرض صفحة نموذج Google نتيجة 77.9% في DeepSWE v1.1 و55.0% في FrontierSWE v2. وهما تقييمان مختلفان للبرمجة. ولا يمكن اعتبارهما معدلًا عامًا لإكمال العمل في مستودعكم. ويميز الجدول أيضًا بين نطاقات سياق GraphWalks، وهي تتعلق بالمدخلات، لا بطول المخرجات. [2]

تستخدم المنهجية 650 مسألة من GraphWalks بسياق يصل إلى 128K، و200 مسألة بسياق يتراوح بين 256K ومليون. تستخدم نتائج Argon عمومًا أعلى إعداد للتفكير وpass@1، مع استثناءات: يعرض OSWorld نتيجة جزئية لتقييم غير متصل، مع اختيار الأفضل من ثلاثة تشغيلات. وتأتي بعض نتائج المقارنة من مزودين آخرين أو لوحات ترتيب. [3]

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

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

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

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

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

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

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

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

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

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

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

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

التحول المحتمل هو من مراجعة إجابة إلى قبول مجموعة كاملة من العمل. توسع زيادة القدرة نطاق ما يستطيع النموذج محاولة إنجازه. وسيعتمد التبني المهني على قدرة الفرق على رؤية ما قدّمه بالفعل والتحقق منه واستعادته عند الحاجة.