mle-workflow

Flujo de Trabajo de Ingeniería de Machine Learning

Utiliza este skill para convertir el trabajo con modelos en un sistema de ML de producción con contratos de datos claros, entrenamiento repetible, compuertas de calidad medibles, artefactos desplegables y monitoreo operativo.

Cuándo Activarlo

• Al planificar o revisar una funcionalidad de ML en producción, actualización de modelos, sistema de ranking, recomendador, clasificador, flujo de embeddings o pipeline de pronósticos
• Al convertir código de notebook en un pipeline reutilizable de entrenamiento, evaluación, inferencia por lotes o inferencia en línea
• Al diseñar criterios de promoción de modelos, evaluaciones fuera de línea/en línea, seguimiento de experimentos o rutas de reversión
• Al depurar fallos causados por deriva de datos, fuga de etiquetas, características obsoletas, desajuste de artefactos o lógica inconsistente entre entrenamiento y servicio
• Al agregar monitoreo de modelos, despliegue canario, tráfico en sombra o verificaciones de calidad posteriores al despliegue

Calibración del Alcance

Utiliza únicamente los carriles que se ajusten al sistema que tienes enfrente. Este skill es útil para ranking, búsqueda, recomendaciones, clasificadores, pronósticos, embeddings, flujos de trabajo LLM, detección de anomalías y análisis por lotes, pero no debe imponer una sola arquitectura a todos ellos.

• No asumas que cada modelo tiene etiquetas supervisadas, servicio en línea, un catálogo de características, PyTorch, GPUs, revisión humana, pruebas A/B o retroalimentación en tiempo real.
• No agregues maquinaria MLOps pesada cuando un contrato de datos, una línea base, un script de evaluación y una nota de reversión harían que el cambio fuera revisable.
• Haz explícitas las suposiciones cuando el proyecto carezca de etiquetas, resultados diferidos, definiciones de segmentos, tráfico de producción o responsabilidad sobre el monitoreo.
• Trata los ejemplos como andamios intercambiables. Reemplaza las métricas, el modo de servicio, los almacenes de datos y los mecanismos de despliegue con equivalentes nativos del proyecto.

Habilidades Relacionadas

• python-patterns y python-testing para implementación en Python y cobertura pytest
• pytorch-patterns para modelos de deep learning, cargadores de datos, gestión de dispositivos y bucles de entrenamiento
• eval-harness y ai-regression-testing para compuertas de promoción y verificaciones de regresión asistidas por agente
• database-migrations, postgres-patterns y clickhouse-io para almacenamiento de datos y superficies de análisis
• deployment-patterns, docker-patterns y security-review para servicio, secretos, contenedores y endurecimiento de producción

Reutiliza la Superficie SWE

No trates MLE como algo separado de la ingeniería de software. La mayoría de los flujos de trabajo SWE de ECC se aplican directamente a los sistemas de ML, a menudo con modos de fallo más estrictos:

La instalación recomendada minimal --with capability:machine-learning mantiene la superficie principal del agente disponible junto con este skill. Para arneses limitados solo al skill o al agente, combina skill:mle-workflow con agent:mle-reviewer donde el objetivo lo admita.

Superficie SWE	Uso en MLE
product-capability / architecture-decision-records	Convertir el trabajo con modelos en contratos de producto explícitos y registrar decisiones irreversibles sobre datos, modelos y despliegue
repo-scan / codebase-onboarding / code-tour	Encontrar rutas existentes de entrenamiento, características, servicio, evaluación y monitoreo antes de introducir un stack de ML paralelo
plan / feature-dev	Definir cambios en modelos como capacidades del producto con fases de datos, evaluación, servicio y reversión
tdd-workflow / python-testing	Probar transformaciones de características, lógica de división, cálculos de métricas, carga de artefactos y esquemas de inferencia antes de la implementación
code-reviewer / mle-reviewer	Revisar calidad del código más riesgos específicos de ML: fuga, reproducibilidad, promoción y monitoreo
build-fix / pr-test-analyzer	Diagnosticar CI roto, evals inestables, fixtures faltantes y fallos de modelo o dependencia específicos del entorno
quality-gate / test-coverage	Exigir evidencia automatizada para transformaciones, métricas, contratos de inferencia, compuertas de promoción y comportamiento de reversión
eval-harness / verification-loop	Convertir métricas fuera de línea, verificaciones de segmentos, presupuestos de latencia y simulacros de reversión en compuertas repetibles
ai-regression-testing	Preservar cada bug de producción como regresión: característica faltante, etiqueta obsoleta, artefacto defectuoso, deriva de esquema o desajuste en el servicio
api-design / backend-patterns	Diseñar APIs de predicción, trabajos por lotes, endpoints de reentrenamiento idempotentes y envoltorios de respuesta
database-migrations / postgres-patterns / clickhouse-io	Versionar etiquetas, instantáneas de características, registros de predicción, métricas de experimentos y análisis de deriva
deployment-patterns / docker-patterns	Empaquetar imágenes reproducibles de entrenamiento y servicio con verificaciones de estado, límites de recursos y reversión
canary-watch / dashboard-builder	Hacer visible la salud del despliegue con paneles de versión de modelo, segmentos, deriva, latencia, coste y etiquetas diferidas
security-review / security-scan	Verificar artefactos de modelo, notebooks, prompts, datasets y registros en busca de secretos, PII, deserialización insegura y riesgo en la cadena de suministro
e2e-testing / browser-qa / accessibility	Probar flujos de producto críticos que consumen predicciones, incluyendo explicabilidad y estados de interfaz de usuario alternativos
benchmark / performance-optimizer	Medir rendimiento, latencia p95, memoria, utilización de GPU y coste por predicción o reentrenamiento
cost-aware-llm-pipeline / token-budget-advisor	Enrutar cargas de trabajo LLM/embedding por calidad, latencia y presupuesto en lugar de recurrir al modelo más grande por defecto
documentation-lookup / search-first	Verificar el comportamiento actual de la biblioteca para servicio de modelos, catálogos de características, bases de datos vectoriales y herramientas de evaluación antes de codificar
git-workflow / github-ops / opensource-pipeline	Empaquetar cambios MLE para revisión con alcance claro, artefactos generados excluidos y evidencia de prueba reproducible
strategic-compact / dmux-workflows	Dividir trabajo de ML largo en pistas paralelas: contrato de datos, arnés de evaluación, ruta de servicio, monitoreo y documentación

Diez Simulaciones de Tareas MLE

Utiliza estas simulaciones como verificaciones de cobertura al planificar o revisar trabajo MLE. Un flujo de trabajo MLE sólido debería reducir cada tarea a contratos explícitos, superficies SWE reutilizables, evidencia automatizada y un artefacto revisable.

ID	Tarea MLE común	Ruta ECC simplificada	Salida requerida	Carriles de pipeline cubiertos
MLE-01	Enmarcar una capacidad ambigua de predicción, ranking, recomendador, clasificador, embedding o pronóstico	product-capability, plan, architecture-decision-records, mle-workflow	Iteration Compact nombrando quién se preocupa, propietario de la decisión, métrica de éxito, errores inaceptables, suposiciones, restricciones y primer experimento	contrato de producto, pérdida del interesado, riesgo, despliegue
MLE-02	Definir objetivos de métricas, etiquetas, fuentes de datos y el presupuesto de errores	repo-scan, database-reviewer, database-migrations, postgres-patterns, clickhouse-io	Contrato de datos y métricas con granularidad de entidad, momento de la etiqueta, confianza de la etiqueta, momento de las características, uniones point-in-time, política de división e instantánea del dataset	contrato de datos, diseño de métricas, fuga, reproducibilidad
MLE-03	Construir un modelo de línea base y una ruta de puntuación antes de agregar complejidad	tdd-workflow, python-testing, python-patterns, code-reviewer	Puntuador de línea base con matriz de confusión, notas de calibración, estimación de latencia/coste, debilidades conocidas y pruebas de forma y determinismo de la puntuación	línea base, puntuación, pruebas, paridad de servicio
MLE-04	Generar características a partir de hipótesis sobre lo que separa los resultados	python-patterns, pytorch-patterns, docker-patterns, deployment-patterns	Plan de características y módulo de transformación que cubra fuente de la señal, valores faltantes, valores atípicos, correlaciones, verificaciones de fuga y equivalencia entrenamiento/servicio	pipeline de características, fuga, entrenamiento, artefactos
MLE-05	Ajustar umbrales, configuraciones y complejidad del modelo bajo compensaciones	eval-harness, ai-regression-testing, quality-gate, test-coverage	Informe de umbral/configuración comparando precisión, recall, F1, AUC, calibración, segmentos de grupos, latencia, coste, complejidad y clases de error aceptables	evaluación, umbral, promoción, regresión
MLE-06	Ejecutar análisis de errores y convertir errores en el siguiente experimento	eval-harness, ai-regression-testing, mle-reviewer, silent-failure-hunter	Informe de agrupación de errores para falsos positivos, falsos negativos, etiquetas ambiguas, características obsoletas, señales faltantes y trazas de bugs con lecciones aprendidas	análisis de errores, traza de bugs, iteración, regresión
MLE-07	Empaquetar un artefacto de modelo para inferencia por lotes o en línea	api-design, backend-patterns, security-review, security-scan	Paquete de artefactos versionado con preprocesamiento, configuración, restricciones de dependencias, validación de esquema, carga segura y registros seguros de PII	artefacto, seguridad, contrato de inferencia
MLE-08	Implementar servicio en línea o puntuación por lotes con captura de retroalimentación	api-design, backend-patterns, e2e-testing, browser-qa, accessibility	Endpoint de predicción o trabajo por lotes con envoltorio de respuesta, tiempo de espera, procesamiento por lotes, respaldo, versión del modelo, confianza, registro de retroalimentación y pruebas del flujo de producto	servicio, inferencia por lotes, respaldo, flujo de trabajo del usuario
MLE-09	Desplegar un modelo con tráfico en sombra, canario, prueba A/B o reversión	canary-watch, dashboard-builder, verification-loop, performance-optimizer	Plan de despliegue nombrando división de tráfico, paneles, latencia p95, coste, barreras de calidad, artefacto de reversión y disparador de reversión	despliegue, canario, reversión
MLE-10	Operar, depurar y actualizar un modelo de producción después del lanzamiento	silent-failure-hunter, dashboard-builder, mle-reviewer, doc-updater, github-ops	Registro de observación y plan de actualización con verificaciones de deriva, salud de etiquetas diferidas, propietarios de alertas, actualizaciones de runbook, criterios de reentrenamiento y evidencia de PR	monitoreo, respuesta a incidentes, reentrenamiento

Iteration Compact

Antes de tocar el código del modelo, comprime el trabajo en un artefacto revisable. Debe ser lo suficientemente corto para caber en la descripción de un PR y lo suficientemente preciso para que otro ingeniero pueda cuestionar las compensaciones.

Objetivo:
Quién se preocupa:
Propietario de la decisión:
Acción del usuario o sistema modificada por el modelo:
Métrica de éxito:
Métricas de barrera:
Presupuesto de errores:
Errores inaceptables:
Errores aceptables:
Suposiciones:
Restricciones:
Etiquetas e instantánea de datos:
Línea base:
Señales candidatas:
Plan de umbral o configuración:
Segmentos de evaluación:
Riesgos conocidos:
Próximo experimento:
Reversión o respaldo:

Este compact es el equivalente MLE de una nota de diseño SWE sólida. Mantiene al equipo de optimizar una métrica que nadie confía, agregar características que no abordan el modo de error real, o implementar complejidad sin una reversión.

Cerebro de Decisión

Utiliza este bucle cuando la tarea sea ambigua, de alto impacto o centrada en métricas:

1. Comienza desde la decisión, no desde el modelo. Nombra la acción que cambia el comportamiento posterior.
2. Nombra quién se preocupa y por qué. Diferentes interesados pagan diferentes costes por falsos positivos, falsos negativos, latencia, gasto computacional, opacidad u oportunidades perdidas.
3. Convierte la ambigüedad en hipótesis. Pregunta qué señal separaría los resultados, qué evidencia la refutaría y qué línea base simple debería ser difícil de superar.
4. Investiga el arte previo o un problema conocido cercano antes de inventar un sistema a medida.
5. Puntúa las opciones con (probabilidad, confianza) x (coste, gravedad, importancia, impacto).
6. Considera el comportamiento adversarial, los incentivos, la divulgación selectiva, el cambio de distribución y los bucles de retroalimentación.
7. Prefiere el cambio más simple que reduzca el error más importante. La simplicidad no es pereza; es una forma de minimizar errores garrafales preservando la velocidad de iteración.
8. Captura la decisión, la evidencia, el contraargumento y el siguiente paso reversible.

Economía de Métricas y Errores

Elige métricas basadas en costes de fallo, no por costumbre:

• Utiliza una matriz de confusión al principio para que el equipo pueda discutir falsos positivos y falsos negativos concretos en lugar de precisión abstracta.
• Favorece la precisión cuando domina el coste de una decisión positiva incorrecta.
• Favorece el recall cuando domina el coste de una decisión positiva omitida.
• Usa F1 solo cuando la compensación precisión/recall esté genuinamente equilibrada y sea explicable.
• Usa AUC o métricas de ranking cuando la calidad del ordenamiento importe más que un solo umbral.
• Realiza un seguimiento de la latencia, el rendimiento, la memoria y el coste como métricas de primera clase porque determinan la complejidad factible del modelo.
• Compara contra una línea base y el modelo de producción actual antes de celebrar una mejora fuera de línea.
• Trata las señales de retroalimentación del mundo real como etiquetas diferidas con sesgo, retraso y brechas de cobertura; no las trates como verdad absoluta sin análisis.

Cada elección de métrica debe indicar qué error hace más barato, qué error hace más probable y quién absorbe ese coste.

Hipótesis de Datos y Características

Las características deben provenir de una teoría de separación:

• Texto, campos categóricos, historiales numéricos, relaciones de grafo, actualidad, frecuencia y agregados son familias de señales candidatas, no características automáticas.
• Para cada familia de características, indica por qué debería separar los resultados y cómo podría filtrar información futura.
• Para etiquetas ruidosas, considera adjudicación, confianza de etiqueta, objetivos suaves o ponderación por confianza.
• Para desequilibrio de clases, compara pérdida ponderada, remuestreo, movimiento de umbral y reglas de decisión calibradas.
• Para valores faltantes, decide si la ausencia es informativa, imputable o una razón para abstenerse.
• Para valores atípicos, decide si recortar, agrupar, investigar o preservarlos como señal rara pero importante.
• Para características correlacionadas, verifica si son redundantes, inestables o proxies de un estado futuro no disponible.

No agregues complejidad al modelo hasta que el análisis de errores muestre que la línea base está fallando por una razón que una señal o capacidad adicional pueda plausiblemente solucionar.

Bucle de Análisis de Errores

Después de cada línea base, ejecución de entrenamiento, cambio de umbral o cambio de configuración:

1. Divide los errores en falsos positivos, falsos negativos, abstenciones, casos de baja confianza y fallos del sistema.
2. Agrupa los errores por rasgos compartidos: idioma, tipo de entidad, fuente, momento, geografía, dispositivo, dispersión, actualidad, frescura de características, fuente de etiqueta o versión del modelo.
3. Separa los errores del modelo de los bugs de datos.