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

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

المشكلة لدى Google قابلة للقياس بوضوح. ففي استطلاع داخلي شمل 6059 مطورًا، جاء تشخيص إخفاقات اختبارات التكامل ضمن أكثر خمس شكاوى تكرارًا بشأن أدوات الهندسة. وأظهر استطلاع إضافي شمل 116 مهندسًا أن 38,4% من هذه الإخفاقات يستغرق تحليلها أكثر من ساعة، وأن 8,9% منها يستغرق أكثر من يوم. أما في اختبارات الوحدة (unit tests) فبلغت هذه النسب 2,7% و0% على التوالي.

والسبب مفهوم: فاختبار التكامل لا يفشل تقريبًا أبدًا في موضع واحد واضح. ففي الحالة النموذجية هناك test driver مستقل، ومجموعة خدمات داخل النظام قيد الاختبار (system under test)، وسجلات موزعة على مكونات مختلفة، وكمٌّ كبير من التحذيرات والأخطاء التي لا علاقة لها إطلاقًا بالسبب الجذري. وفي دراسة Google، احتوى الاختبار الفاشل المتوسط على 16 ملف سجل و2801 سطر من السجلات.

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

يعمل النموذج دون تدريب إضافي على سجلات Google الخاصة؛ فالرهان هنا ليس على الضبط الدقيق (fine-tuning) بل على prompt صارم والتكامل مع سير العمل. ويُلزَم النموذج في الـ prompt باتباع خطوات محددة: العثور على أقسام السجلات، وتحديد المكون الذي وقع فيه الفشل، وفحص السياق، ثم صياغة الاستنتاج في النهاية فقط.

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

ومن حيث الأرقام، لا يبدو النظام نموذجًا مخبريًا أوليًا، بل أداة داخلية جُرِّبت فعليًا. ففي فحص يدوي شمل 71 حالة فشل حقيقية من 39 فريقًا، حدد Auto-Diagnose السبب الجذري بشكل صحيح في 64 حالة، أي بدقة 90,14%. بعد ذلك أطلقته Google على جميع إخفاقات التكامل المرتبطة بتغييرات الكود في أنحاء الشركة، اعتبارًا من مايو 2025. وخلال هذه الفترة عالج النظام 52635 اختبارًا فريدًا، و224782 عملية تشغيل، و91130 تغييرًا في الكود، وعمل مع 22962 مؤلفًا.

بلغ الوسيط الزمني لنشر التشخيص في مراجعة الكود 56 ثانية، والمئين التسعين 346 ثانية، أي أن النتيجة تظهر عادةً قبل أن ينتقل المهندس نهائيًا إلى مهمة أخرى. ويستهلك التشغيل الواحد في المتوسط 110617 رمزًا مدخلًا (token) ويولّد 5962 رمزًا مخرجًا.

أما ردود الفعل فجاءت جيدة أيضًا: ففي 517 تقييمًا من 437 مطورًا، بلغت نسبة علامات Not helpful نسبة 5,8%، وهي أقل من العتبة الداخلية لدى Google لمثل هذه الأدوات والبالغة 10%، وقد احتل Auto-Diagnose المرتبة 14 من أصل 370 نظامًا ينشر findings في Critique من حيث helpfulness.

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

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