Antes de hablar de foundation models o IA generativa, el examen AIF-C01 espera que domines los conceptos base de Machine Learning: cómo aprende un modelo, qué fases tiene un proyecto de ML y por qué un modelo puede fallar aunque "funcione" en pruebas.
Contenido
Machine Learning no es una técnica única — es una familia de enfoques que difieren en cómo el modelo recibe información durante el entrenamiento. El examen espera que reconozcas cuál se aplica a un escenario dado.
Supervisado
El modelo aprende de datos etiquetados: cada ejemplo de entrenamiento tiene un input y el output correcto conocido. El modelo ajusta sus parámetros para minimizar el error entre su predicción y la etiqueta real.
No supervisado
El modelo recibe datos sin etiquetas y busca estructura o patrones ocultos por su cuenta: agrupaciones, relaciones o reducción de dimensionalidad.
Por refuerzo
Un agente aprende por prueba y error, interactuando con un entorno. Recibe recompensas o penalizaciones según sus acciones y ajusta su estrategia (política) para maximizar la recompensa acumulada.
Trampa frecuente del examen
Si el escenario menciona "datos históricos con la respuesta correcta ya conocida" → supervisado. Si menciona "agrupar sin saber de antemano las categorías" → no supervisado. Si menciona "recompensas", "políticas" o "un agente que actúa en un entorno" → por refuerzo.
Un modelo de ML no nace entrenado. Es un proceso iterativo con seis fases bien diferenciadas — y el examen puede preguntar en qué fase ocurre una actividad específica (por ejemplo, "detectar drift" es monitoreo, no evaluación).
Recolección de datos
Reunir datos relevantes, suficientes y representativos del problema real. La calidad de esta fase limita el techo de todo el proyecto.
Preparación de datos
Limpieza (valores nulos, duplicados), transformación (normalización, encoding) y etiquetado si el enfoque es supervisado.
Entrenamiento
El algoritmo ajusta sus parámetros internos iterativamente para minimizar el error sobre el conjunto de entrenamiento.
Evaluación
Medir el desempeño con datos que el modelo NUNCA vio durante el entrenamiento, usando métricas como accuracy, precision, recall o F1.
Despliegue
Publicar el modelo como un endpoint de inferencia accesible por aplicaciones, integrado en un flujo de producción.
Monitoreo
Vigilar el desempeño en producción para detectar degradación o "drift": cuando los datos del mundo real cambian respecto a los de entrenamiento.
Es un ciclo, no una línea recta
El monitoreo en producción frecuentemente revela que el modelo necesita reentrenarse con datos nuevos — lo que reinicia el ciclo desde la recolección de datos. Este proceso continuo se conoce como MLOps.
Deja que SageMaker Autopilot entrene y compare varios modelos automáticamente, y despliega el mejor.
+1 más...
Datos etiquetados (labeled)
Cada registro incluye la respuesta correcta junto al input. Ejemplo: una imagen junto con la etiqueta "gato". Son necesarios para aprendizaje supervisado, pero son caros y lentos de producir — a menudo requieren anotación humana.
En AWS, SageMaker Ground Truth combina anotación humana con asistencia de ML para reducir el costo de etiquetado.
Datos no etiquetados (unlabeled)
Solo el input, sin respuesta conocida. Son mucho más abundantes y baratos de conseguir (texto de internet, logs, imágenes sin categorizar) y son la base del aprendizaje no supervisado y del pre-entrenamiento de foundation models.
La mayoría de los foundation models de IA generativa se pre-entrenan sobre volúmenes masivos de datos no etiquetados.
Crea un labeling job y etiqueta manualmente mensajes de soporte sin categorizar usando SageMaker Ground Truth.
+1 más...
Además de etiquetados/no etiquetados, el examen espera que reconozcas otras formas comunes de clasificar los datos que alimentan un modelo de IA, según su estructura y su relación con el tiempo.
Datos estructurados
Organizados en un esquema fijo y predecible: filas y columnas, como una tabla de base de datos o un archivo CSV. Fáciles de consultar y procesar con ML clásico.
Datos no estructurados
Sin esquema predefinido: texto libre, imágenes, audio, vídeo. Representan la mayoría de los datos generados hoy y son el terreno natural de deep learning y los foundation models.
Datos tabulares
Caso particular (y muy común) de datos estructurados: cada fila es una observación y cada columna una feature. Es el formato típico de entrada para SageMaker Autopilot y modelos de scoring/predicción tradicionales.
Series de tiempo (time-series)
Observaciones ordenadas cronológicamente donde el orden temporal importa: precios de acciones, lecturas de sensores IoT, tráfico web. Requieren técnicas que capturen tendencia y estacionalidad (ej. RNN, o servicios especializados como Amazon Forecast).
Para evaluar honestamente un modelo, sus datos se dividen en tres conjuntos independientes. Usar el mismo conjunto para entrenar y evaluar produce una falsa sensación de precisión.
| Conjunto | Para qué se usa | Proporción típica |
|---|---|---|
| Training set | El modelo aprende sus parámetros ajustándose a estos datos directamente | ~60-80% |
| Validation set | Ajustar hiperparámetros y comparar configuraciones del modelo sin tocar el test set | ~10-20% |
| Test set | Evaluación final, una sola vez, con datos que el modelo nunca vio ni influyeron en ninguna decisión | ~10-20% |
Por qué importa el test set separado
Si evalúas con datos que el modelo ya vio (directa o indirectamente, ajustando hiperparámetros contra ellos), obtienes una métrica optimista que no predice el desempeño real en producción. El test set debe tocarse una sola vez, al final.
El objetivo de entrenar un modelo no es que memorice los datos, sino que generalice: que funcione bien con datos nuevos que nunca vio. Dos formas de fallar en esto, en direcciones opuestas.
Overfitting (sobreajuste)
El modelo es demasiado complejo para la cantidad de datos disponibles y termina memorizando el training set, incluyendo su ruido, en vez de aprender patrones generales.
Síntoma: accuracy muy alta en training, pero baja en validation/test.
Ejemplo: un modelo de detección de fraude que alcanza 99.9% de accuracy en entrenamiento pero falla constantemente con transacciones nuevas — memorizó casos específicos, no el patrón de fraude.
Underfitting (subajuste)
El modelo es demasiado simple para capturar los patrones reales de los datos. Ni siquiera logra un buen desempeño en el propio conjunto de entrenamiento.
Síntoma: accuracy baja tanto en training como en validation/test.
Ejemplo: intentar predecir el precio de una vivienda usando solo una línea recta cuando la relación real entre variables es claramente no lineal.
Mitigaciones comunes:
Una vez entrenado, un modelo se usa para generar predicciones sobre datos nuevos — eso es "inferencia". Cómo y cuándo se ejecuta depende de los requisitos del caso de uso: latencia tolerable, volumen de peticiones y su patrón en el tiempo.
Batch (por lotes)
Se procesa un gran volumen de datos de una sola vez, de forma programada, sin necesitar respuesta inmediata. Ejemplo: generar recomendaciones de productos para todos los clientes cada noche.
Real-time (tiempo real)
El modelo responde en milisegundos a cada petición individual a través de un endpoint siempre activo. Ejemplo: aprobar o rechazar una transacción con tarjeta en el momento de la compra.
Asynchronous (asíncrona)
La petición se encola y se procesa cuando hay capacidad disponible, sin bloquear al cliente que la generó. Ideal para inputs grandes (documentos extensos, vídeos) donde procesar puede tardar segundos o minutos y no se requiere respuesta instantánea.
Serverless
La infraestructura de inferencia escala automáticamente a cero cuando no hay tráfico y se aprovisiona bajo demanda. Reduce costos para cargas de trabajo intermitentes o impredecibles, a cambio de posible latencia extra en el primer request ("cold start").
En SageMaker
SageMaker ofrece endpoints dedicados para inferencia en tiempo real, Batch Transform para inferencia por lotes, colas de inferencia asíncrona para payloads grandes, y Serverless Inference para cargas intermitentes sin gestionar capacidad fija.
"Accuracy" (exactitud) es la métrica más intuitiva, pero puede ser profundamente engañosa cuando las clases están desbalanceadas. El examen espera que sepas cuándo mirar más allá de accuracy.
Accuracy (exactitud)
Porcentaje total de predicciones correctas sobre el total de predicciones. Simple, pero engañosa con clases desbalanceadas.
Precision (precisión)
De todo lo que el modelo marcó como positivo, ¿qué porcentaje era realmente positivo? Importa cuando el costo de un falso positivo es alto.
Recall (sensibilidad)
De todos los casos realmente positivos, ¿qué porcentaje detectó el modelo? Importa cuando el costo de un falso negativo es alto.
F1 score
Media armónica entre precision y recall. Útil como métrica resumen única cuando necesitas balancear ambas y las clases están desbalanceadas.
Por qué accuracy sola engaña — ejemplo de detección de fraude
Imagina un dataset de transacciones donde solo el 1% son fraudulentas. Un modelo "perezoso" que predice SIEMPRE "no es fraude" obtiene 99% de accuracy — y sin embargo es completamente inútil, porque nunca detecta ni un solo fraude real (recall = 0%). Aquí precision y recall (y F1) revelan el problema que accuracy esconde.
Un modelo técnicamente excelente puede seguir siendo un mal proyecto si no genera valor de negocio. El examen también evalúa que reconozcas métricas fuera del propio modelo, usadas para justificar (o cuestionar) una inversión en ML/IA.
Costo por usuario
Cuánto cuesta operar el modelo (cómputo, almacenamiento, API) dividido entre usuarios activos — clave para decidir si el modelo escala de forma sostenible.
Costos de desarrollo
Inversión en datos, talento, entrenamiento y experimentación necesaria para llegar a un modelo utilizable en producción.
Feedback de clientes
Satisfacción, quejas o tasas de adopción reales de la funcionalidad impulsada por IA — el modelo puede tener buenas métricas técnicas y aun así no gustarle al usuario.
ROI (Return on Investment)
Relación entre el valor generado (ahorro de costos, ingresos adicionales) y la inversión total del proyecto — la métrica que finalmente decide si el proyecto continúa.
Métricas del modelo (accuracy, F1...) y métricas de negocio (ROI, costo por usuario...) responden preguntas distintas: las primeras dicen si el modelo predice bien; las segundas dicen si vale la pena tenerlo en producción.
¿Entendiste este tema?
Pon a prueba lo que acabas de aprender
Un equipo de ciencia de datos entrena un modelo que logra 98% de accuracy en el conjunto de entrenamiento, pero solo 61% en el conjunto de test. ¿Qué problema describe mejor esta situación?
Inicia sesión para llevar tu progreso.