Google a publié cette semaine un préprint décrivant Auto-Diagnose, un système basé sur LLM qui lit les logs de tests d'intégration pis dit aux ingénieurs pourquoi un test a échoué. La motivation vient d'un sondage interne chez Google : 38,4% des échecs de tests d'intégration prennent plus d'une heure à diagnostiquer, pis 8,9% prennent plus d'une journée. Les tests unitaires se triage quasi-instantanément parce que la surface d'échec, c'est une fonction ; les tests d'intégration s'étalent à travers les services, les centres de données pis les couches d'exécution, fait que l'analyse de cause-racine devient une job d'archéologie de logs. Auto-Diagnose automatise cette archéologie-là avec du prompt engineering sur un modèle frontière, pas un fine-tuné.
Le modèle, c'est Gemini 2.5 Flash à température 0,1 pis top-p 0,8, sans fine-tuning sur le corpus de tests de Google. Le pipeline ramasse les logs du driver de test pis les logs des composants à travers les centres de données, les joint chronologiquement en un seul flux, pis soumet le tout au modèle. Charge moyenne par exécution : 110 617 tokens en entrée pis 5 962 tokens en sortie. Latence p50 à 56 secondes, p90 à 346 secondes. Le prompt guide le modèle à travers des phases explicites : scanner les sections de logs, lire le contexte, localiser les échecs, résumer les erreurs, pis conclure. Le choix d'ingénierie critique, c'est une contrainte anti-hallucination dure qui force le modèle à refuser plutôt que de deviner quand la preuve manque. C'est ce comportement de refus qui garde la précision au-dessus de 90% dans un domaine où un diagnostic confidemment faux gaspille des heures d'ingénieur.
Chiffres en production depuis mai 2025 : 224 782 exécutions de tests évaluées, 52 635 tests en échec distincts diagnostiqués. Évaluation manuelle sur 71 échecs du vrai monde à travers 39 équipes : 90,14% de précision sur la cause-racine. Le feedback des développeurs : 84,3% de « please fix » des réviseurs, ratio d'utilité de 62,96% parmi les réponses des développeurs, pis rang 14 sur 370 outils Critique internes (top 3,78%) par utilité. Ce qui est notable, c'est ce qui manque : pas de fine-tuning, pas de couche RAG, pas de modèle custom. Juste Gemini 2.5 Flash avec du prompting soigné pis une règle de refus-sur-ambiguïté. Le système bénéficie aussi de la centralisation extrême des logs chez Google, fait que tu peux pas juste envoyer le même prompt sur AWS CloudWatch pis avoir les mêmes chiffres, parce que le prompt présume que les logs sont déjà joints chronologiquement à travers les services.
Si tu roules n'importe quel genre de CI multi-services, le playbook ici est replicable mais pas cheap. Le coût du modèle est négligeable (Gemini 2.5 Flash à ~116k tokens par triage, ça coûte des cennes), fait que le vrai investissement, c'est la plomberie des logs : ramasser, normaliser pis joindre à travers les services avant que le LLM voie quoi que ce soit. Le patron refus-sur-ambiguïté, c'est l'idée la plus transférable du lot. La plupart des pipelines LLM en CI sont pas réglés pour refuser pis finissent par halluciner des causes qui ont l'air plausibles, ce qui est pire que le silence parce que ça pointe les ingénieurs vers des fixes dans la mauvaise direction. Si t'es en train de brancher du triage LLM pour ta suite de tests, copie ce patron-là en premier, occupe-toi du modèle après. La deuxième leçon, c'est qu'un modèle frontière off-the-shelf avec du prompting soigné est maintenant compétitif avec les approches fine-tunées sur des tâches spécialisées, pourvu que tu façonnes l'entrée proprement. Ça monte le plafond de ce que des petites équipes peuvent livrer sans infrastructure ML.