flujo-de-trabajo-mle

Flujo de Trabajo de Ingeniería de Machine Learning

Use 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 Activar

• Planificar o revisar una característica de ML de producción, actualización de modelo, sistema de ranking, recomendador, clasificador, flujo de trabajo de embeddings o pipeline de pronósticos
• Convertir código de notebook en un pipeline reutilizable de entrenamiento, evaluación, inferencia por lotes o inferencia en línea
• Diseñar criterios de promoción de modelos, evaluaciones fuera de línea/en línea, seguimiento de experimentos o rutas de reversión
• Depurar fallos causados por deriva de datos, fuga de etiquetas, características obsoletas, desajuste de artefactos o lógica inconsistente de entrenamiento y servicio
• Agregar monitoreo de modelos, despliegue canario, tráfico sombra o controles de calidad posteriores al despliegue

Calibración del Alcance

Use solo los carriles que se ajusten al sistema que tiene delante. 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 forzar una arquitectura única para todos ellos.

• No asuma que cada modelo tiene etiquetas supervisadas, servicio en línea, un almacén de características, PyTorch, GPUs, revisión humana, pruebas A/B o retroalimentación en tiempo real.
• No agregue maquinaria pesada de MLOps 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.
• Haga explícitos los supuestos cuando el proyecto carezca de etiquetas, resultados retrasados, definiciones de segmentos, tráfico de producción o propiedad del monitoreo.
• Trate los ejemplos como andamios intercambiables. Reemplace las métricas, el modo de servicio, los almacenes de datos y los mecanismos de despliegue con equivalentes nativos del proyecto.

Skills Relacionados

• python-patterns y python-testing para implementación en Python y cobertura de pytest
• pytorch-patterns para modelos de aprendizaje profundo, cargadores de datos, manejo de dispositivos y bucles de entrenamiento
• eval-harness y ai-regression-testing para compuertas de promoción y controles de regresión asistidos por agente
• database-migrations, postgres-patterns y clickhouse-io para almacenamiento de datos y superficies analíticas
• deployment-patterns, docker-patterns y security-review para servicio, secretos, contenedores y endurecimiento de producción

Reutilice la Superficie SWE

No trate a 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 del agente central disponible junto con este skill. Para arneses solo de skill o limitados por agente, combine skill:mle-workflow con agent:mle-reviewer donde el destino lo admita.

Superficie SWE	Uso en MLE
product-capability / architecture-decision-records	Convierta el trabajo con modelos en contratos de producto explícitos y registre decisiones irreversibles sobre datos, modelos y despliegue
repo-scan / codebase-onboarding / code-tour	Encuentre rutas existentes de entrenamiento, características, servicio, evaluación y monitoreo antes de introducir una pila ML paralela
plan / feature-dev	Defina los cambios de modelo como capacidades de producto con fases de datos, evaluación, servicio y reversión
tdd-workflow / python-testing	Pruebe 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	Revise la calidad del código más los riesgos específicos de ML: fuga, reproducibilidad, promoción y monitoreo
build-fix / pr-test-analyzer	Diagnostique CI roto, evaluaciones inestables, fixtures faltantes y fallos de modelo o dependencia específicos del entorno
quality-gate / test-coverage	Exija evidencia automatizada para transformaciones, métricas, contratos de inferencia, compuertas de promoción y comportamiento de reversión
eval-harness / verification-loop	Convierta métricas fuera de línea, controles de segmentos, presupuestos de latencia y ejercicios de reversión en compuertas repetibles
ai-regression-testing	Preserve cada error de producción como una regresión: característica faltante, etiqueta obsoleta, artefacto incorrecto, deriva de esquema o desajuste de servicio
api-design / backend-patterns	Diseñe APIs de predicción, trabajos por lotes, endpoints de reentrenamiento idempotentes y envoltorios de respuesta
database-migrations / postgres-patterns / clickhouse-io	Versionamiento de etiquetas, instantáneas de características, registros de predicción, métricas de experimentos y análisis de deriva
deployment-patterns / docker-patterns	Empaquete imágenes de entrenamiento y servicio reproducibles con controles de salud, límites de recursos y reversión
canary-watch / dashboard-builder	Haga visible la salud del despliegue con paneles de versión de modelo, segmentos, deriva, latencia, costo y etiquetas retrasadas
security-review / security-scan	Verifique artefactos de modelo, notebooks, prompts, conjuntos de datos y registros en busca de secretos, PII, deserialización insegura y riesgo en la cadena de suministro
e2e-testing / browser-qa / accessibility	Pruebe flujos de producto críticos que consuman predicciones, incluyendo explicabilidad y estados de UI de respaldo
benchmark / performance-optimizer	Mida rendimiento, latencia p95, memoria, utilización de GPU y costo por predicción o reentrenamiento
cost-aware-llm-pipeline / token-budget-advisor	Enrute cargas de trabajo de LLM/embedding por calidad, latencia y presupuesto en lugar de usar el modelo más grande por defecto
documentation-lookup / search-first	Verifique el comportamiento actual de la biblioteca para servicio de modelos, almacenes de características, bases de datos vectoriales y herramientas de evaluación antes de programar
git-workflow / github-ops / opensource-pipeline	Empaquete cambios de MLE para revisión con alcance claro, artefactos generados excluidos y evidencia de prueba reproducible
strategic-compact / dmux-workflows	Divida el trabajo largo de ML en pistas paralelas: contrato de datos, arnés de evaluación, ruta de servicio, monitoreo y documentación

Diez Simulaciones de Tareas MLE

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

ID	Tarea común de MLE	Ruta ECC optimizada	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	Compacto de Iteración: nombre a quién le importa, propietario de la decisión, métrica de éxito, errores inaceptables, supuestos, 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étrica con granularidad de entidad, momento de la etiqueta, confianza de la etiqueta, momento de la característica, uniones puntuales, política de división e instantánea del conjunto de datos	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/costo, 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 señal, valores faltantes, valores atípicos, correlaciones, controles 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 grupo, latencia, costo, complejidad y clases de error aceptables	evaluación, umbral, promoción, regresión
MLE-06	Ejecutar análisis de errores y convertir los 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 rastros de errores con lecciones aprendidas	análisis de errores, rastreo de errores, 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 dependencia, validación de esquema, carga segura y registros sin 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, agrupación, respaldo, versión de modelo, confianza, registro de retroalimentación y pruebas de flujo de producto	servicio, inferencia por lotes, respaldo, flujo de trabajo de usuario
MLE-09	Implementar un modelo con tráfico 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, costo, barreras de calidad, artefacto de reversión y desencadenante 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	Libro de registro de observaciones y plan de actualización con controles de deriva, salud de etiquetas retrasadas, propietarios de alertas, actualizaciones de runbook, criterios de reentrenamiento y evidencia de PR	monitoreo, respuesta a incidentes, reentrenamiento

Compacto de Iteración

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

Objetivo:
A quién le importa:
Propietario de la decisión:
Acción del usuario o sistema que cambia el modelo:
Métrica de éxito:
Métricas de barrera:
Presupuesto de errores:
Errores inaceptables:
Errores aceptables:
Supuestos:
Restricciones:
Instantánea de etiquetas y 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 compacto es el equivalente MLE de una nota de diseño SWE sólida. Mantiene al equipo alejado de optimizar una métrica en la 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

Use este bucle siempre que la tarea sea ambigua, de alto impacto o intensiva en métricas:

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

Economía de Métricas y Errores

Elija métricas basándose en los costos de fallo, no por hábito:

• Use 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.
• Favorezca la precisión cuando el costo de una decisión positiva incorrecta domine.
• Favorezca el recall cuando el costo de un positivo perdido domine.
• Use F1 solo cuando la compensación precisión/recall esté genuinamente equilibrada y sea explicable.
• Use AUC o métricas de ranking cuando la calidad del orden importe más que un solo umbral.
• Rastree latencia, rendimiento, memoria y costo como métricas de primera clase porque moldean la complejidad factible del modelo.
• Compare contra una línea base y el modelo de producción actual antes de celebrar una ganancia fuera de línea.
• Trate las señales de retroalimentación del mundo real como etiquetas retrasadas con sesgo, retraso y brechas de cobertura; no las trate como verdad absoluta sin análisis.

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

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ñal candidatas, no características automáticas.
• Para cada familia de características, indique por qué debería separar los resultados y cómo podría filtrar información futura.
• Para etiquetas ruidosas, considere arbitraje, confianza de la etiqueta, objetivos suaves o ponderación de confianza.
• Para desequilibrio de clases, compare pérdida ponderada, remuestreo, movimiento de umbral y reglas de decisión calibradas.
• Para valores faltantes, decida si la ausencia es informativa, imputable o una razón para abstenerse.
• Para valores atípicos, decida si recortar, agrupar, investigar o preservarlos como señal rara pero importante.
• Para características correlacionadas, verifique si son redundantes, inestables o proxies de un estado futuro no disponible.

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

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. Divida los errores en falsos positivos, falsos negativos, abstenciones, casos de baja confianza y fallos del sistema.
2. Agrupe los errores por características compartidas: idioma, tipo de entidad, fuente, tiempo, geografía, dispositivo, escasez, actualidad, frescura de la característica, fuente de la etiqueta o versión del modelo.
3. Separe los errores del modelo de los errores de datos...