Encuentra la causa raíz de los fallos de CI de ML en minutos con Gemini 3.5 Flash
Depurar una canalización de entrenamiento de ML rota es un trabajo lento y tedioso. Obtienes logs de dos ejecuciones distintas de CI, los comparas con los valores dorados, revisas el historial de commits para encontrar la regresión y luego redactas un informe explicando qué salió mal y por qué, todo mientras tu equipo espera. Este caso de uso automatiza toda esa investigación.
Al combinar la habilidad ml-failure-audit con el modelo Gemini 3.5 Flash de Google y la Gemini Agent API como motor de razonamiento remoto, la fuerza de trabajo multiagente de Eigent puede auditar un fallo de CI de extremo a extremo: obteniendo logs, extrayendo valores de referencia, rastreando evidencia, delegando el análisis pesado y produciendo entregables estructurados, todo desde un único prompt.
Selecciona Gemini 3.5 Flash como tu modelo
Ve a Settings → Agents → Model y selecciona Gemini 3.5 Flash de la lista de modelos en la nube. Si prefieres usar tus propias credenciales de API, aporta tu propia clave de Gemini introduciéndola en Settings → API Keys → Gemini.
Gemini 3.5 Flash está optimizado para una inferencia rápida y rentable en tareas de contexto largo, exactamente lo que exige el análisis de logs de CI.
Habilita la Gemini Agent API como subagente remoto
Ve a Settings → Agents → Remote Agents y activa Gemini Agent API. Esto registra el Gemini Agent como un subagente invocable dentro de la fuerza de trabajo de Eigent.
Una vez habilitado, tu Developer Agent puede delegar tareas de razonamiento computacionalmente intensivas, como el análisis de causa raíz a través de cientos de líneas de log, directamente al Gemini Agent, en lugar de procesarlo todo en una sola llamada al modelo. Esto te da una configuración de dos niveles: los agentes locales de Eigent se encargan de la orquestación y el uso de herramientas, mientras que el Gemini Agent se encarga del razonamiento profundo.
Sube la habilidad ml-failure-audit
Ve a Settings → Agents → Skills y sube el paquete de la habilidad ml-failure-audit. También puedes explorar Skill Hub: ml-failure-audit para ver los detalles de la habilidad y los pasos de instalación. La habilidad define cómo debe abordar Eigent las auditorías de fallos de CI: qué artefactos recopilar, qué comparaciones ejecutar, qué evidencia reunir y cómo estructurar el informe final.
Una vez cargada, cualquier agente de la fuerza de trabajo puede invocar esta habilidad al gestionar tareas de auditoría de ML.
Envía tu tarea a Eigent
Con todo configurado, escribe tu prompt de tarea en el chat de Eigent:
Sigue la habilidad {{ml-failure-audit}} y usa un subagente remoto para completar subtareas complejas.
Por favor, audita este fallo de CI de métricas doradas de preentrenamiento MIMO VLM de Megatron-LM. Te estoy dando un checkout local de NVIDIA/Megatron-LM en el commit <your-commit-sha> y los artefactos de CI que adjunté (por ejemplo, logs de ejecuciones aprobadas y fallidas). La carga de trabajo fallida es una comprobación de convergencia frozen start de 8 GPUs usando sequence packing, tamaño de batch global 32, longitud total de secuencia empaquetada 3200, packing buffer 4 y 100 iteraciones de entrenamiento.
Decide si el fallo es una regresión real de convergencia/corrección del modelo o un problema de política de métricas/gating. Usa el código de comparación de valores dorados del repositorio y los logs de CI como evidencia. No vuelvas a ejecutar el entrenamiento en GPU.
Produce answer.json en la raíz del repo con source_refs, extracted_facts, calculations, final_answer y validation. Produce también un answer.md conciso.
Incluye la URL del repositorio, tu checkout del commit objetivo y adjunta los artefactos de CI que quieras comparar. Eigent comienza inmediatamente a planificar la investigación.
Instala la habilidad ml-failure-audit antes de ejecutar este prompt.
Aporta tus propias entradas: reemplaza <your-commit-sha> por el commit que quieres auditar, haz checkout de esa revisión en tu espacio de trabajo y adjunta tus propios artefactos de CI (por ejemplo, logs de ejecuciones aprobadas frente a fallidas, capturas de stderr o salida exportada de trabajos de CI). Puedes adaptar el ejemplo de Megatron-LM a cualquier repo y fallo que estés investigando.
El agente Coordinator planifica y asigna la tarea
El Coordinator Agent de Eigent lee el prompt y lo descompone en un plan de auditoría estructurado. Identifica las fases clave (obtención de logs, extracción de datos, rastreo de evidencia y generación de informes) y asigna la investigación completa a un Developer Agent.
El Coordinator no se limita a delegar a ciegas: transmite la referencia de la habilidad, el contexto del repo y los artefactos de logs de CI para que el Developer Agent empiece con todo lo que necesita.
El Developer Agent carga la habilidad y obtiene los logs
La primera acción del Developer Agent es cargar la habilidad ml-failure-audit, leyendo sus instrucciones para comprender la metodología de auditoría.
Luego ejecuta 4 comandos en paralelo para obtener los datos de logs de CI, extrayendo simultáneamente los dos logs de fallo y cualquier metadato relevante. La ejecución paralela de herramientas significa que la fase de recopilación de datos se completa en una fracción del tiempo que tardaría secuencialmente.
Extrae los valores dorados y rastrea el commit de corrección
Con los logs en mano, el Developer Agent ejecuta un script de Python para extraer los valores de referencia dorados: las métricas de entrenamiento esperadas, las curvas de pérdida o los números de benchmark que una ejecución de CI aprobada debería producir. Luego los compara con los valores registrados en los logs fallidos para identificar exactamente dónde y en qué medida divergieron las cosas.
Después, el Developer Agent busca en el historial de commits de Megatron-LM para encontrar el commit de corrección, el cambio de código específico más probablemente responsable de la regresión. Este commit sirve como evidencia concreta en el informe de auditoría, proporcionando a los revisores un enlace directo entre el fallo observado y el cambio de código subyacente.
Delegar el razonamiento profundo al Gemini Agent
Una vez reunida la evidencia bruta (diferencias de logs, comparaciones de valores dorados y el commit rastreado), el Developer Agent llama al Gemini Agent para realizar el paso de razonamiento pesado.
El Gemini Agent analiza todo el contexto: qué cambió en el código, cómo ese cambio afectó al comportamiento del entrenamiento y cuál es la causa raíz más probable. Minutos después, devuelve un informe de auditoría completo y estructurado que cubre el diagnóstico del fallo, los factores contribuyentes y la corrección recomendada.
El Developer Agent escribe los informes finales de auditoría
El Developer Agent toma el análisis del Gemini Agent y escribe dos entregables en el espacio de trabajo:
-
answer.json: un registro de auditoría legible por máquina con campos estructurados para el tipo de fallo, la causa raíz, las métricas afectadas, el commit de evidencia y la resolución recomendada. Útil para pipelines automatizados, sistemas de tickets o paneles de CI. -
answer.md: un resumen de auditoría conciso y legible por personas que cubre qué falló, por qué falló, la evidencia y qué hacer después. Listo para pegar en un comentario de PR, un hilo de Slack o un informe de incidente.
Ambos archivos se escriben directamente en la carpeta del espacio de trabajo y están disponibles de inmediato.
Por qué importa este flujo de trabajo
Los fallos de CI de ML son notoriamente difíciles de depurar porque la señal está enterrada en una salida de logs densa y la causa raíz a menudo está en varios commits anteriores al síntoma. Este flujo de trabajo lo aborda con tres capacidades que trabajan en conjunto:
- Recuperación paralela de logs elimina el cuello de botella secuencial de extraer artefactos uno por uno.
- Extracción de valores dorados basada en Python aplica una comparación numérica precisa en lugar de depender de coincidencias de patrones o inspección manual.
- Gemini Agent como subagente de razonamiento descarga el paso de inferencia más complejo a un modelo optimizado para ello, manteniendo ligera la orquestación y profundo el análisis.
El resultado es una auditoría de causa raíz que a un ingeniero le tomaría 30–60 minutos de trabajo concentrado, entregada en unos pocos minutos, con un rastro estructurado de artefactos.
Qué probar después
Una vez completada tu primera auditoría, amplía el flujo de trabajo con prompts de seguimiento como:
Ejecuta la misma auditoría contra los tres fallos de CI más recientes y compara las causas raíz.
Después de encontrar el commit de corrección, abre un issue de GitHub con el informe de auditoría prellenado.
Programa un disparador nocturno para auditar cualquier nuevo fallo de CI y publicar answer.md en Slack.
Sustituye por otro modelo: prueba Gemini 3.5 Pro para un análisis más profundo o Gemini Flash Lite para una respuesta más rápida.
Consejos para mejores resultados
- Adjunta explícitamente tus artefactos de CI. La habilidad ml-failure-audit funciona mejor cuando proporcionas el checkout del commit junto con los logs o exportaciones que quieres comparar (por ejemplo, una ejecución aprobada y una fallida).
- Incluye la URL del repo. El Developer Agent la usa para buscar en el historial de commits el commit de corrección. Un enlace directo al repositorio ahorra un paso de búsqueda.
- Especifica tus archivos de salida. Pedir tanto
answer.jsoncomoanswer.mdle indica al Developer Agent que produzca ambos formatos, útil si necesitas salida legible por máquina para un pipeline de CI y salida legible por personas para tu equipo. - Usa el Gemini Agent para tareas que requieran mucho razonamiento. El patrón de subagente remoto funciona mejor cuando los agentes locales manejan la recopilación de datos y el Gemini Agent maneja la síntesis. Evita llamarlo para búsquedas simples que el uso local de herramientas pueda resolver más rápido.
