Si alguna vez ha mirado miles de líneas de registros de pruebas de integración preguntándose cuál de los dieciséis archivos de registro contiene realmente su error, no está solo, y Google ahora tiene datos para demostrarlo.
Un equipo de investigadores de Google presentó Auto-Diagnose, una herramienta basada en LLM que lee automáticamente los registros de fallas de una prueba de integración fallida, encuentra la causa raíz y publica un diagnóstico conciso directamente en la revisión del código donde apareció la falla. En una evaluación manual de 71 fallas del mundo real que abarcaban 39 equipos distintos, la herramienta identificó correctamente la causa raíz el 90,14 % de las veces. Se ha ejecutado en 52.635 pruebas fallidas distintas en 224.782 ejecuciones en 91.130 cambios de código escritos por 22.962 desarrolladores distintos, con una tasa de “No útil” de sólo el 5,8% de los comentarios recibidos.
El problema: las pruebas de integración son un impuesto de depuración
Las pruebas de integración verifican que varios componentes de un sistema distribuido realmente se comuniquen entre sí correctamente. Los objetivos de Auto-Diagnose de las pruebas son pruebas herméticas de integración funcional: pruebas en las que un controlador de prueba muestra todo un sistema bajo prueba (SUT), generalmente un gráfico de servidores en comunicación, dentro de un entorno aislado y lo ejercita contra la lógica empresarial. Una encuesta separada de Google a 239 encuestados encontró que el 78% de las pruebas de integración en Google son funcionales, que es lo que motivó el alcance.
El diagnóstico de fallas en las pruebas de integración apareció como una de las cinco quejas principales en EngSat, una encuesta de Google realizada a 6.059 desarrolladores. Una encuesta de seguimiento realizada a 116 desarrolladores encontró que el 38,4 % de los fallos de las pruebas de integración tardan más de una hora en diagnosticarse y el 8,9 % tarda más de un día, frente al 2,7 % y el 0 % de las pruebas unitarias.
La causa fundamental es estructural. Los registros del controlador de prueba generalmente solo muestran un síntoma genérico (un tiempo de espera, una afirmación). El error real se encuentra en algún lugar dentro de uno de los registros del componente SUT, a menudo enterrado bajo advertencias recuperables y líneas de nivel de ERROR que en realidad no son la causa.
Cómo funciona el diagnóstico automático
Cuando falla una prueba de integración, un evento de publicación/suscripción activa el diagnóstico automático. El sistema recopila todos los registros del controlador de prueba y de los componentes SUT en el nivel INFO y superiores (en centros de datos, procesos y subprocesos) y luego los une y los clasifica por marca de tiempo en un único flujo de registros. Esa secuencia se coloca en una plantilla de aviso junto con los metadatos del componente.
El modelo es Gemini 2.5 Flash, llamado con temperatura = 0,1 (para salidas casi deterministas y depurables) y topp = 0,8. Gemini no ajustó los datos de las pruebas de integración de Google; esto es pura ingeniería rápida en un modelo de propósito general.
El mensaje en sí es la parte más instructiva de esta investigación. Guía el modelo a través de un protocolo explícito paso a paso: escanea las secciones del registro, lee el contexto del componente, localiza la falla, resume los errores y solo entonces intenta llegar a una conclusión. Fundamentalmente, incluye restricciones negativas estrictas, por ejemplo: si los registros no contienen líneas del componente que falló, no saque ninguna conclusión.
La respuesta del modelo se procesa posteriormente en un hallazgo de rebajas con las secciones ==Conclusión==, ==Pasos de la investigación== y ==Líneas de registro más relevantes==, luego se publica como un comentario en Critique, el sistema interno de revisión de código de Google. Cada línea de registro citada se representa como un enlace en el que se puede hacer clic.
Números de producción
El diagnóstico automático tiene un promedio de 110 617 tokens de entrada y 5962 tokens de salida por ejecución, y publica hallazgos con una latencia p50 de 56 segundos y p90 de 346 segundos, lo suficientemente rápido como para que los desarrolladores vean el diagnóstico antes de cambiar de contexto.
La crítica expone tres botones de comentarios sobre un hallazgo: Corrija (usado por los revisores), Útil y No útil (ambos usados por los autores). De un total de 517 informes de comentarios de 437 desarrolladores distintos, 436 (84,3%) fueron “Por favor, arregle” de 370 revisores: con diferencia, la interacción dominante y una señal de que los revisores están pidiendo activamente a los autores que actúen según los diagnósticos. Entre los comentarios del lado del desarrollador, la proporción de utilidad (H / (H + N)) es del 62,96%, y la tasa de “No útil” (N / (PF + H + N)) es del 5,8%, muy por debajo del umbral del 10% de Google para mantener una herramienta activa. Entre 370 herramientas que publican hallazgos en Critique, Auto-Diagnose ocupa el puesto 14 en utilidad, lo que lo sitúa en el 3,78 % superior.
La evaluación manual también reveló un efecto secundario útil. De los siete casos en los que falló el diagnóstico automático, cuatro se debieron a que los registros del controlador de prueba no se guardaron correctamente en el momento del accidente, y tres se debieron a que los registros del componente SUT no se guardaron cuando el componente falló; ambos errores reales de infraestructura, reportados a los equipos pertinentes. En producción, alrededor de 20 diagnósticos de “se necesita más información” también han ayudado a sacar a la luz problemas de infraestructura.
Conclusiones clave
El diagnóstico automático alcanzó una precisión de causa raíz del 90,14% en una evaluación manual de 71 fallas en pruebas de integración del mundo real que abarcaban 39 equipos de Google, abordando un problema que 6.059 desarrolladores clasificaron entre sus cinco principales quejas en la encuesta de EngSat. El sistema se ejecuta en Gemini 2.5 Flash sin ajustes, solo ingeniería rápida. Un activador de publicación/sub recopila registros en centros de datos y procesos, los une mediante marca de tiempo y los envía al modelo a una temperatura de 0,1 y 0,8 como máximo. El mensaje está diseñado para rechazar en lugar de adivinar. Las duras restricciones negativas obligan al modelo a responder con “se necesita más información” cuando falta evidencia: una compensación deliberada que evita causas fundamentales alucinadas e incluso ayudó a sacar a la luz errores reales de infraestructura en el proceso de registro de Google. En producción desde mayo de 2025, Auto-Diagnose se ha ejecutado en 52,635 pruebas fallidas distintas en 224,782 ejecuciones en 91,130 cambios de código de 22,962 desarrolladores, publicando hallazgos en un p50 de 56 segundos, lo suficientemente rápido como para que los ingenieros vean el diagnóstico antes de cambiar de contexto.
Consulte el documento de preimpresión aquí. Además, no dude en seguirnos en Twitter y no olvide unirse a nuestro SubReddit de más de 130.000 ML y suscribirse a nuestro boletín. ¡Esperar! estas en telegrama? Ahora también puedes unirte a nosotros en Telegram.
¿Necesita asociarse con nosotros para promocionar su repositorio de GitHub O su página principal de Hugging O su lanzamiento de producto O seminario web, etc.? Conéctate con nosotros