Ciclo de vida del desarrollo de machine learning

Dominio 1 · Fundamentos IA/ML

Ciclo de vida del desarrollo de machine learning

◷ 34 min

El ciclo de vida de machine learning describe el camino completo desde la idea de negocio hasta un modelo funcionando en producción. Para el examen AWS Certified AI Practitioner AIF-C01, debes entender las fases principales, qué ocurre en cada una, qué problemas pueden aparecer y cómo AWS ayuda a construir, desplegar y operar soluciones de ML de forma controlada.

Datos EDA Entrenamiento Evaluación Despliegue Monitorización MLOps

Pista de examen: cuando una pregunta hable de modelos que funcionan bien en pruebas pero mal en producción, datos que cambian con el tiempo, necesidad de repetir entrenamientos, trazabilidad o automatizar despliegues, piensa en ciclo de vida ML, monitorización y MLOps.

1. Por qué existe un ciclo de vida de ML

Un modelo de machine learning no es solo un archivo entrenado. Es el resultado de un proceso que incluye entender el problema, conseguir datos adecuados, prepararlos, entrenar, evaluar, desplegar y vigilar el comportamiento después del despliegue. En producción, el mundo cambia: los datos cambian, los usuarios cambian, el negocio cambia y el rendimiento del modelo puede degradarse.

Objetivo de negocio

Antes de entrenar nada, hay que saber qué se quiere mejorar: reducir fraude, predecir demanda, recomendar productos, clasificar tickets o detectar anomalías.

Datos adecuados

El modelo aprende patrones desde datos. Si los datos son incompletos, sesgados, antiguos o inconsistentes, el modelo probablemente tendrá problemas.

Evaluación rigurosa

Un modelo debe probarse con datos que no haya visto durante entrenamiento. Si solo se mide con datos de entrenamiento, la métrica puede engañar.

Operación continua

Después de desplegar, hay que monitorizar rendimiento, latencia, errores, coste y cambios en la distribución de datos.

2. Fase 1: definición del problema

La primera fase no es técnica, es de negocio. Hay que convertir una necesidad en un problema de ML. Esto implica definir la pregunta que el modelo debe responder, el tipo de salida esperada y cómo se medirá el éxito.

Pregunta	Qué significa	Ejemplo
¿Qué queremos predecir o decidir?	Define la variable objetivo o resultado esperado.	Probabilidad de abandono, importe de demanda, categoría de ticket.
¿La salida es categoría o número?	Ayuda a distinguir clasificación de regresión.	Fraude/no fraude frente a precio estimado.
¿Qué coste tiene equivocarse?	Permite elegir métricas y controles adecuados.	No detectar fraude puede ser más grave que generar una revisión extra.
¿Se necesita explicación o revisión humana?	Importante para decisiones de alto impacto.	Crédito, salud, selección, reclamaciones o procesos legales.

Cómo puede preguntarlo el examen

Una empresa quiere priorizar reclamaciones críticas, pero no quiere que el modelo tome la decisión final. La mejor respuesta no será automatizar todo, sino usar ML como apoyo a la priorización y mantener revisión humana en casos sensibles.

3. Fase 2: recopilación y preparación de datos

Los datos son la base del modelo. En un proyecto real, gran parte del trabajo está en localizar fuentes, revisar calidad, limpiar errores, tratar valores ausentes, eliminar duplicados, normalizar formatos y preparar variables útiles para el entrenamiento.

Tipos de datos que pueden aparecer

Datos estructurados: tablas, columnas, registros, transacciones, métricas o eventos.
Datos no estructurados: texto libre, documentos, imágenes, audio, vídeo o correos.
Datos semiestructurados: JSON, logs, mensajes o documentos con cierta estructura interna.
Etiquetas: resultado real que el modelo aprende a predecir en aprendizaje supervisado.

Problemas habituales de calidad

1Valores ausentes. Campos incompletos que pueden requerir imputación, eliminación o tratamiento específico.

2Datos inconsistentes. Fechas en formatos distintos, nombres de categorías duplicados o unidades mezcladas.

3Duplicados. Registros repetidos que pueden sesgar el entrenamiento.

4Datos no representativos. Si el conjunto no representa la realidad, el modelo puede fallar en producción.

Idea clave: más datos no siempre significa mejor modelo. Datos malos, sesgados o mal etiquetados pueden empeorar el resultado. En el examen, si el escenario menciona duplicados, valores incompletos o categorías incoherentes, la respuesta suele estar en preparación y limpieza de datos antes de entrenar.

4. Fase 3: análisis exploratorio de datos o EDA

EDA significa Exploratory Data Analysis. Es la fase donde se analiza el conjunto de datos para entender distribuciones, relaciones, valores raros, desbalanceo de clases y posibles problemas antes de entrenar el modelo.

Durante EDA se pueden revisar:

Distribución de variables numéricas.
Frecuencia de categorías.
Relación entre variables y etiqueta.
Valores atípicos u outliers.
Clases desbalanceadas.
Variables que podrían introducir fuga de información.

Ejemplo: un modelo de detección de fraude tiene 99% de accuracy, pero solo el 1% de operaciones son fraudulentas. El EDA ayuda a detectar que la clase positiva está muy desbalanceada y que accuracy por sí sola puede ser engañosa.

5. Fase 4: ingeniería de características

Las características o features son las variables que el modelo usa para aprender. La ingeniería de características consiste en transformar los datos originales en señales más útiles para el modelo.

Transformación	Para qué sirve	Ejemplo
Normalización o escalado	Evita que variables con magnitudes distintas dominen el modelo.	Edad, ingresos y número de compras en escalas comparables.
Codificación de categorías	Convierte texto categórico en formato usable por algoritmos.	País, segmento de cliente o tipo de producto.
Variables derivadas	Crea señales nuevas a partir de datos existentes.	Días desde la última compra, media de gasto mensual.
Extracción de texto o imagen	Convierte contenido no estructurado en información útil.	Sentimiento de reseñas o características visuales.

6. Fase 5: división de datos

Para evaluar correctamente un modelo, los datos suelen separarse en conjuntos de entrenamiento, validación y prueba.

Entrenamiento: datos usados para que el modelo aprenda patrones.
Validación: datos usados para ajustar hiperparámetros y comparar modelos durante el desarrollo.
Prueba: datos reservados para medir rendimiento final con información que el modelo no ha visto.

Error frecuente: evaluar el modelo con los mismos datos usados para entrenar. Eso puede dar métricas artificialmente buenas y ocultar problemas de generalización.

7. Fase 6: entrenamiento del modelo

Durante el entrenamiento, el algoritmo aprende patrones a partir de los datos. El resultado entrenado es el modelo. En AWS, un servicio como Amazon SageMaker AI puede ayudar a preparar, entrenar, ajustar, desplegar y monitorizar modelos de ML.

En esta fase se toman decisiones como:

Qué algoritmo o tipo de modelo usar.
Qué variables incluir.
Qué hiperparámetros probar.
Cuánto tiempo entrenar.
Cómo controlar coste y capacidad de cómputo.

Concepto	Significado	Idea de examen
Parámetros	Valores que el modelo aprende durante entrenamiento.	No los define manualmente el usuario durante el entrenamiento normal.
Hiperparámetros	Configuraciones que controlan cómo se entrena el modelo.	Pueden ajustarse para mejorar rendimiento.
Entrenamiento	Proceso donde el modelo aprende desde datos.	No es lo mismo que inferencia.
Inferencia	Uso del modelo ya entrenado para generar predicciones.	Ocurre después de entrenar y desplegar.

8. Fase 7: evaluación del modelo

La evaluación permite saber si el modelo funciona suficientemente bien para el objetivo. No existe una métrica única para todo. La métrica correcta depende del tipo de problema y del coste de equivocarse.

Tipo de problema	Métricas frecuentes	Cuándo importan
Clasificación	Accuracy, precision, recall, F1, matriz de confusión.	Fraude, churn, clasificación de tickets, diagnóstico preliminar.
Regresión	Error medio absoluto, error cuadrático, desviación frente al valor real.	Predicción de precio, demanda, tiempo de entrega o consumo.
Forecasting	Error de predicción temporal, desviación por periodo, tendencia.	Demanda, inventario, ventas, capacidad.
Modelos generativos	Relevancia, factualidad, toxicidad, seguridad, coste, latencia.	Asistentes, resúmenes, RAG y generación de contenido.

Precision, recall y F1 en lenguaje sencillo

Precision: de todo lo que el modelo marcó como positivo, cuánto era realmente positivo. Importa cuando los falsos positivos son costosos.
Recall: de todos los positivos reales, cuántos detectó el modelo. Importa cuando no quieres dejar escapar casos importantes.
F1: combina precision y recall cuando necesitas equilibrio entre ambos.

Pregunta típica

Si el escenario dice que una aplicación médica no debe dejar escapar casos urgentes, la métrica prioritaria suele ser recall/sensibilidad, aunque aumenten revisiones innecesarias.

9. Overfitting, underfitting y generalización

Un buen modelo debe funcionar con datos nuevos, no solo con datos de entrenamiento.

Problema	Qué ocurre	Señal típica
Overfitting	El modelo memoriza demasiado el entrenamiento y generaliza mal.	Muy buen resultado en entrenamiento, mal resultado en prueba o producción.
Underfitting	El modelo es demasiado simple o no aprende patrones relevantes.	Mal resultado tanto en entrenamiento como en prueba.
Buena generalización	El modelo mantiene rendimiento razonable con datos no vistos.	Resultados consistentes entre validación, prueba y producción.

10. Fuga de información o data leakage

La fuga de información ocurre cuando el modelo usa datos que no estarían disponibles en el momento real de predicción. Esto provoca métricas artificialmente buenas, pero el modelo falla en producción.

Ejemplo: un modelo para predecir cancelación de clientes usa una variable calculada después de que el cliente ya haya cancelado. Durante pruebas parece excelente, pero en producción esa variable no existiría a tiempo.

Para evitarlo, hay que revisar cuidadosamente qué variables están disponibles antes del evento que se quiere predecir y separar correctamente los datos por tiempo cuando el caso lo requiere.

11. Fase 8: despliegue e inferencia

Desplegar un modelo significa ponerlo disponible para recibir datos nuevos y devolver predicciones. La inferencia puede ser en tiempo real o por lotes.

Tipo de inferencia	Cuándo encaja	Ejemplo
Tiempo real	Cuando la aplicación necesita una respuesta inmediata o casi inmediata.	Detección de fraude en una operación online.
Batch o por lotes	Cuando se procesan muchos registros de una vez y no hace falta respuesta instantánea.	Predicción nocturna de demanda para todas las tiendas.
Asíncrona	Cuando la tarea puede tardar y se procesa en segundo plano.	Análisis de documentos largos o contenido multimedia.

12. Fase 9: monitorización

Un modelo desplegado necesita vigilancia. La monitorización no solo mide si el endpoint está disponible; también revisa si las predicciones siguen siendo fiables y si los datos de entrada han cambiado.

✓Rendimiento del modelo. ¿Mantiene accuracy, precision, recall u otras métricas relevantes?

✓Calidad de datos. ¿Han cambiado formatos, valores, distribuciones o fuentes?

✓Latencia y disponibilidad. ¿Responde en el tiempo esperado?

✓Coste. ¿El uso en producción se mantiene dentro de lo previsto?

13. Drift: cuando el mundo cambia

El drift aparece cuando los datos reales cambian respecto a los datos usados para entrenar el modelo o cuando cambia la relación entre variables y resultado. Un modelo que era bueno puede degradarse con el tiempo.

Tipo de drift	Descripción	Ejemplo
Data drift	Cambia la distribución de los datos de entrada.	Nuevos hábitos de compra tras una campaña o cambio de mercado.
Concept drift	Cambia la relación entre datos de entrada y resultado.	Patrones de fraude nuevos que no existían cuando se entrenó el modelo.
Model drift	Degradación general del rendimiento del modelo en producción.	El modelo falla más con el paso de los meses.

Cómo reconocerlo en el examen

Si el enunciado dice que el modelo funcionaba bien durante meses, pero empieza a fallar tras cambios de comportamiento de clientes, mercado o datos, la respuesta suele estar relacionada con drift, monitorización y reentrenamiento.

14. Reentrenamiento y mejora continua

Cuando el rendimiento cae, puede ser necesario reentrenar el modelo con datos más recientes, ajustar variables, revisar etiquetas, cambiar el algoritmo o incluso replantear el caso de uso.

El reentrenamiento debe hacerse de forma controlada:

Guardar versiones de datos, código, configuración y modelos.
Comparar el nuevo modelo con el anterior.
Validar que mejora métricas relevantes sin introducir nuevos riesgos.
Desplegar gradualmente si el impacto es alto.
Conservar trazabilidad para auditoría y rollback.

15. MLOps: llevar ML a producción de forma repetible

MLOps aplica principios de automatización, control de versiones, CI/CD, monitorización y gobernanza al ciclo de vida de ML. Su objetivo es evitar procesos manuales frágiles y permitir que los modelos se desarrollen y operen de forma repetible.

Necesidad	Qué aporta MLOps	Idea de examen
Repetibilidad	Pipelines para preparar datos, entrenar, evaluar y desplegar.	Evita entrenamientos manuales difíciles de reproducir.
Trazabilidad	Versionado de datasets, artefactos, modelos y métricas.	Permite saber qué modelo está en producción y con qué datos fue entrenado.
Gobernanza	Controles, aprobaciones, auditoría y gestión de riesgo.	Importante en sectores regulados o decisiones sensibles.
Monitorización continua	Detección de drift, errores, latencia y degradación.	Un modelo no se abandona después de desplegarlo.

16. Servicios AWS que pueden aparecer asociados

En este dominio debes reconocer los servicios a nivel conceptual. No necesitas conocer todos los parámetros, pero sí qué servicio encaja con cada necesidad.

Servicio AWS	Uso principal	Cómo recordarlo para AIF-C01
Amazon SageMaker AI	Crear, entrenar, desplegar y monitorizar modelos de ML.	Servicio principal para el ciclo de vida ML en AWS.
SageMaker Pipelines	Automatizar flujos de ML como preparación, entrenamiento y evaluación.	Piensa en MLOps y repetibilidad.
SageMaker Model Monitor	Monitorizar modelos desplegados y detectar cambios o degradación.	Piensa en producción, drift y vigilancia.
Amazon Bedrock	Crear aplicaciones con modelos fundacionales gestionados.	Más relacionado con GenAI y modelos fundacionales que con ML clásico.
Amazon CloudWatch	Métricas, logs y alarmas operativas.	Monitorización de infraestructura y aplicaciones.

17. Cómo razonar preguntas del examen

Cuando veas una pregunta sobre ciclo de vida ML, intenta identificar en qué fase está el problema:

1Problemas de datos. Si hay duplicados, valores incompletos o categorías inconsistentes, piensa en preparación y calidad de datos.

2Métricas engañosas. Si el rendimiento parece demasiado bueno, revisa data leakage o evaluación con datos incorrectos.

3Mal rendimiento con datos nuevos. Piensa en overfitting, generalización o datos no representativos.

4Degradación con el tiempo. Piensa en drift, monitorización y reentrenamiento.

5Necesidad de repetir el proceso. Piensa en MLOps, pipelines, versionado y automatización.

18. Errores frecuentes

Entrenar antes de limpiar datos. Más cómputo no compensa datos de mala calidad.
Usar accuracy para todo. En datos desbalanceados puede ser una métrica muy engañosa.
Confundir entrenamiento con inferencia. Entrenar crea el modelo; inferencia usa el modelo para predecir.
Ignorar drift. Un modelo bueno hoy puede degradarse mañana si cambian los datos.
No versionar modelos ni datos. Sin trazabilidad no hay operación seria ni auditoría.
Automatizar una decisión sensible sin revisión. En casos de alto impacto puede requerirse supervisión humana.

Resumen final

El ciclo de vida de ML empieza con un problema de negocio y termina con un sistema monitorizado en producción. Entre medias hay datos, EDA, preparación, entrenamiento, evaluación, despliegue, inferencia, monitorización y mejora continua. La idea esencial para AIF-C01 es que el modelo no es el único elemento importante: los datos, las métricas, el despliegue, la vigilancia y la gobernanza son igual de críticos.

Recuerda esta secuencia para el examen: definir problema → preparar datos → explorar datos → entrenar → evaluar → desplegar → monitorizar → reentrenar si hace falta. Si el escenario habla de procesos repetibles, trazabilidad o producción, añade MLOps a tu razonamiento.

← Anterior Dominio 2 →