Google a présenté Auto-Diagnose — un système d'IA pour identifier les causes des défaillances des tests d'intégration

Google a présenté Auto-Diagnose, un système interne basé sur LLM qui analyse les journaux des tests d'intégration défaillants, extrait automatiquement les lignes clés et publie des diagnostics directement dans la revue de code. Pour les grandes équipes d'ingénierie, cela représente une tentative d'éliminer l'un des coûts cachés les plus importants du développement : les heures, et parfois les jours, consacrés à la recherche manuelle de la cause d'une défaillance dans des dizaines de fichiers journaux. Le problème de Google est tout à fait mesurable.

Dans une enquête interne auprès de 6059 développeurs, le diagnostic des défaillances des tests d'intégration a figuré dans le top 5 des plaintes les plus fréquentes concernant les outils d'ingénierie. Un suivi d'enquête auprès de 116 ingénieurs a montré que 38,4% de telles défaillances ont pris plus d'une heure à diagnostiquer, et 8,9% ont pris plus d'une journée. Pour les tests unitaires, ces chiffres ont été de 2,7% et 0% respectivement.

La raison est claire : un test d'intégration échoue presque jamais en un seul endroit évident. Dans un cas typique, il y a un driver de test séparé, un ensemble de services au sein du système en cours de test, des journaux répartis sur différents composants, une multitude d'avertissements et d'erreurs qui ne sont pas liés à la cause racine. Dans la recherche de Google, le test défaillant médian contenait 16 fichiers journaux et 2801 lignes de journaux.

Auto-Diagnose est intégré au flux de travail de développement existant. Lorsqu'un test d'intégration échoue, le système reçoit automatiquement un événement, collecte les journaux du driver de test et des composants SUT au niveau INFO et supérieur, les consolide dans un flux unique et les trie par heure. Ensuite, avec les métadonnées des composants, tout cela est envoyé à Gemini 2.

5 Flash. Le modèle fonctionne sans fine-tuning sur les journaux spéciaux de Google : le pari est fait non sur le fine-tuning, mais sur un prompt rigidement codé et l'intégration dans le processus. Dans le prompt, le modèle est forcé de suivre les étapes : trouver les sections de journaux, identifier le composant où la défaillance s'est produite, vérifier le contexte et seulement ensuite formuler une conclusion.

Le point clé est une interdiction de deviner. Si les journaux ne contiennent pas de lignes du composant exact qui n'a pas démarré ou n'est pas devenu sain, le modèle ne doit pas spéculer, mais répondre directement que les données sont insuffisantes. Après cela, la réponse est formatée en un format standard et publiée dans Critique, le système interne d'examen de code de Google, où le développeur voit immédiatement la conclusion, les étapes d'enquête et les lignes de journaux les plus pertinentes.

En chiffres, le système ne ressemble pas à un prototype de laboratoire, mais à un véritable outil interne testé. Dans la vérification manuelle sur 71 défaillances réelles de 39 équipes, Auto-Diagnose a correctement identifié la cause racine dans 64 cas, une précision de 90,14%. Après cela, Google l'a déployé sur tous les défaillances d'intégration lors des changements de code dans toute l'entreprise, à partir de mai 2025.

Au cours de cette période, le système a fonctionné sur 52.635 tests uniques, 224.782 exécutions, 91.

130 changements de code et 22.962 auteurs. Le temps médian pour publier un diagnostic dans l'examen de code était de 56 secondes, et le 90e percentile était de 346 secondes, ce qui signifie que le résultat apparaît généralement avant que l'ingénieur ne bascule complètement vers une autre tâche.

En moyenne, une exécution consomme 110.617 tokens d'entrée et génère 5.962 tokens de sortie.

Les commentaires aussi ont l'air bien : sur 517 avis de 437 développeurs, la part des marques "Non utile" était de 5,8%, en dessous du seuil interne de Google de 10% pour de tels outils, et en termes d'utilité, Auto-Diagnose s'est classé 14e sur 370 systèmes publiant des résultats dans Critique. Il y a aussi un avantage secondaire important. Sept erreurs de l'évaluation manuelle se sont avérées être non pas une défaillance du modèle lui-même, mais des problèmes avec l'infrastructure de journalisation : dans certains cas, les journaux du driver de test n'ont pas été sauvegardés après un crash, dans d'autres, les journaux du composant défaillant lui-même manquaient.

Des réponses similaires dans l'esprit de "nous avons besoin de plus de données" ont ensuite aidé à identifier environ 20 problèmes d'infrastructure supplémentaires. Par conséquent, le principal avantage d'Auto-Diagnose n'est pas seulement que Google accélère l'enquête sur les défaillances de tests. L'entreprise démontre un schéma plus pratique pour utiliser les LLMs dans le développement : ne pas demander au modèle de corriger aveuglément le code, mais l'intégrer dans un point étroit du processus, lui donner des règles strictes pour refuser la spéculation et renvoyer les résultats directement à l'endroit où l'ingénieur travaille déjà.

Pour les grandes équipes, c'est peut-être un scénario plus précieux qu'un autre "assistant de codification IA", car il réduit le temps pour comprendre la cause de la défaillance, et c'est précisément ce qui retarde le plus souvent la version.