أطلقت Google نظام Auto-Diagnose — نظام ذكاء اصطناعي للبحث عن أسباب فشل اختبارات التكامل

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

في استطلاع داخلي شارك فيه 6059 مطوراً، دخل تشخيص أعطال اختبارات التكامل قائمة أفضل 5 شكاوى متكررة حول أدوات الهندسة. أظهر استطلاع متابعة شارك فيه 116 مهندساً أن 38.4% من هذه الأعطال استغرقت أكثر من ساعة واحدة للتشخيص، و8.

9% استغرقت أكثر من يوم واحد. أما بالنسبة لاختبارات الوحدة، فكانت هذه النسب 2.7% و0% على التوالي.

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

يتم دمج Auto-Diagnose في سير العمل الحالي للتطوير. عندما يفشل اختبار التكامل، يتلقى النظام تلقائياً حدثاً، ويجمع سجلات محرك الاختبار ومكونات SUT بمستوى INFO وما فوق، ويدمجها في تدفق واحد، ويرتبها حسب الوقت. بعد ذلك، يتم إرسال كل هذا جنباً إلى جنب مع البيانات الوصفية للمكونات إلى Gemini 2.

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

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

حسب الأرقام، لا يبدو النظام كنموذج أولي من المختبر، بل كأداة داخلية قد تم اختبارها فعلياً. في التحقق اليدوي من 71 عطلاً حقيقياً من 39 فريقاً، حدد Auto-Diagnose بشكل صحيح السبب الجذري في 64 حالة، بدقة 90.14%.

بعد ذلك، طرحت جوجل النظام على جميع أعطال التكامل عند تغييرات الكود عبر الشركة بأكملها، ابتداءً من مايو 2025. خلال هذه الفترة، عمل النظام على 52635 اختبار فريد و224782 تشغيل و91130 تغيير كود و22962 مؤلف. كان متوسط الوقت لنشر التشخيص في مراجعة الكود 56 ثانية، والنسبة المئوية 90 كانت 346 ثانية، مما يعني أن النتيجة تظهر عادة قبل أن ينتقل المهندس بالكامل إلى مهمة أخرى.

في المتوسط، يستهلك التشغيل الواحد 110617 رمز إدخال وينتج 5962 رمز إخراج. التعليقات أيضاً تبدو جيدة: من 517 تقييم من 437 مطوراً، كانت نسبة علامات "غير مفيد" 5.8%، أقل من حد جوجل الداخلي البالغ 10% لمثل هذه الأدوات، وفي مجال الفائدة، احتل Auto-Diagnose المركز 14 من 370 نظام ينشر النتائج في Critique.

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

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