Google publicó esta semana un preprint describiendo Auto-Diagnose, un sistema basado en LLM que lee logs de tests de integración y le dice a los ingenieros por qué falló un test. La motivación viene de una encuesta interna de Google: 38,4% de los fallos de tests de integración tardan más de una hora en diagnosticarse, y 8,9% tardan más de un día. Los tests unitarios se trían casi instantáneamente porque la superficie de fallo es una sola función; los tests de integración se despliegan a través de servicios, data centers y capas de runtime, así que el análisis de causa-raíz se vuelve un trabajo de arqueología de logs. Auto-Diagnose automatiza esa arqueología con ingeniería de prompts sobre un modelo frontera, no uno fine-tuneado.
El modelo es Gemini 2.5 Flash a temperatura 0,1 y top-p 0,8, sin fine-tuning sobre el corpus de tests de Google. El pipeline recolecta los logs del driver de test y los logs de componentes a través de data centers, los une cronológicamente en un solo flujo, y somete todo al modelo. Carga promedio por ejecución: 110.617 tokens de entrada y 5.962 tokens de salida. Latencia p50 de 56 segundos, p90 de 346 segundos. El prompt guía al modelo por fases explícitas: escanear secciones de logs, leer contexto, localizar fallos, resumir errores y concluir. La decisión crítica de ingeniería es una restricción anti-alucinación dura que obliga al modelo a rehusarse en lugar de adivinar cuando la evidencia es insuficiente. Ese comportamiento de rechazo es lo que mantiene la precisión por encima del 90% en un dominio donde un diagnóstico confiadamente incorrecto desperdicia horas de ingeniero.
Cifras en producción desde mayo de 2025: 224.782 ejecuciones de test evaluadas, 52.635 tests fallidos distintos diagnosticados. Evaluación manual sobre 71 fallos del mundo real a través de 39 equipos: 90,14% de precisión en causa-raíz. Feedback de desarrolladores: 84,3% de "please fix" de revisores, ratio de utilidad del 62,96% entre respuestas de desarrolladores, y rango 14 entre 370 herramientas Critique internas (top 3,78%) por utilidad. Lo notable es lo que no está: sin fine-tuning, sin capa RAG, sin modelo custom. Solo Gemini 2.5 Flash con prompting cuidadoso y una regla de rechazo-ante-ambigüedad. El sistema también se beneficia de la centralización extrema de logs de Google, así que no se puede simplemente enviar el mismo prompt en AWS CloudWatch y obtener las mismas cifras, porque el prompt asume que los logs ya están unidos cronológicamente a través de servicios.
Si corres cualquier tipo de CI multi-servicio, el playbook aquí es replicable pero no barato. El costo del modelo es insignificante (Gemini 2.5 Flash a ~116k tokens por triaje cuesta centavos), así que la inversión real es la plomería de logs: recolectar, normalizar y unir a través de servicios antes de que el LLM vea nada. El patrón rechazo-ante-ambigüedad es la idea más transferible. La mayoría de pipelines LLM en CI no están afinados para rechazar y terminan alucinando causas que parecen plausibles, lo cual es peor que el silencio porque dirige a los ingenieros hacia arreglos equivocados. Si estás cableando triaje LLM para tu suite de tests, copia ese patrón primero, preocúpate del modelo después. La segunda lección es que un modelo frontera off-the-shelf con prompting cuidadoso es ahora competitivo con enfoques fine-tuneados en tareas especializadas, siempre y cuando moldees la entrada con cuidado. Eso sube el techo de lo que equipos pequeños pueden entregar sin infraestructura de ML.