Algoritmos de ML y evaluación de modelos en AWS

Un algoritmo es fácil de nombrar y difícil de justificar. El examen AIF-C01 casi nunca pregunta «qué algoritmo existe»: pregunta «el negocio necesita X, las etiquetas se parecen a Y, y AWS te da Z; justifica la pareja y defiende la métrica.» La Tarea 2.1 te pide seleccionar técnicas de ML apropiadas para casos de uso concretos (regresión, clasificación, clustering), la Tarea 2.2 te pide describir el aprendizaje supervisado, no supervisado y por refuerzo, y la Tarea 1.4 te pide describir las métricas de rendimiento del modelo (exactitud, AUC, F1) y las métricas de negocio (coste por usuario, coste de desarrollo, opinión del cliente, ROI). Esta lección convierte esas tres frases en un sistema de decisiones operable.

Al final de esta lección podrás:

• elegir entre aprendizaje supervisado, no supervisado y por refuerzo a partir de la forma de los datos solamente;
• mapear dieciséis familias de algoritmos a su caso de uso, su ruta de AWS y su hiperparámetro clave;
• declarar qué algoritmos están integrados en SageMaker, y cuál famosamente no lo está;
• calcular exactitud, precisión, exhaustividad, F1, MAE, MSE, RMSE y R² a partir de una matriz de confusión o un set de residuos sin calculadora;
• escoger el split correcto (70/30, 60/20/20, holdout 20 to 30%, k-fold 5 to 10) y defenderlo;
• diagnosticar infraajuste frente a sobreajuste y aplicar el remedio prescrito por AWS en la dirección correcta;
• atacar el desbalance de clases con las tres palancas que AWS documenta (reponderación, resampling, cambio de métrica);
• responder diez preguntas al estilo del examen escritas con la voz oficial.

---

1. Los tres paradigmas de aprendizaje y cómo los implementa AWS

1.1 Guía de selección: lee los datos, no el eslogan

El examen decide el paradigma por ti con una pista: ¿qué contiene el dataset de entrenamiento? Pares etiquetados de entrada→salida apuntan al aprendizaje supervisado; atributos sin respuestas apuntan al no supervisado; una señal de recompensa que vuelve desde un entorno apunta al aprendizaje por refuerzo.

La distinción en la que los ítems del examen más se apoyan: el aprendizaje no supervisado nunca ve un set de validación con etiquetas. La propia documentación de k-means de SageMaker dice que «no usa un dataset de validación» porque no hay nada contra lo que validar: toma un canal de test y reporta solo métricas basadas en distancia. Una pregunta que ofrece validation:f1 para un job de clustering está probando si te diste cuenta.

1.2 Cómo se ve cada paradigma como flujo de trabajo

1.3 Aprendizaje por refuerzo en SageMaker: los hechos concretos

El aprendizaje por refuerzo (RL) es el paradigma que el examen prueba por reconocimiento de nombre más que por cálculo. Las afirmaciones verificadas de AWS son:

• SageMaker AI admite RL en TensorFlow y Apache MXNet;
• admite los toolkits Intel Coach y Ray RLlib;
• la FAQ de SageMaker lista los algoritmos DQN, PPO, A3C y muchos más;
• el repositorio abierto de contenedores de RL incluye imágenes de Vowpal Wabbit (VW);
• los jobs se lanzaban con el RLEstimator.

Si una pregunta describe a un agente aprendiendo una política para maximizar la recompensa acumulada en una simulación, la respuesta es SageMaker RL con Coach o Ray RLlib: nunca k-means, nunca Autopilot, nunca PCA.

• 📚 ¿Sabías que…? El soporte de RL de SageMaker es deliberadamente estrecho: solo TensorFlow y MXNet como frameworks. Si una opción ofrece «SageMaker RL con PyTorch», es un distractor: la lista de frameworks documentados no incluye PyTorch, aunque PyTorch está totalmente soportado para aprendizaje profundo supervisado a través de los contenedores de aprendizaje profundo preconstruidos.

Comprueba tu selección de paradigma:

---

2. La matriz algoritmo → caso de uso → ruta de AWS

Esta es la tabla más examinable del Dominio 2. Léela como tres preguntas respondidas a la vez: qué familia, qué caso de negocio, dónde corre en AWS.

2.1 La matriz completa

2.2 Del tipo de tarea a la familia de algoritmos

2.3 Las listas de integrados que debes poder reproducir

AWS organiza sus algoritmos integrados en los grupos supervisado, no supervisado y por refuerzo. El set supervisado tabular es el que el examen más reutiliza:

Integrados tabulares (clasificación o regresión): AutoGluon-Tabular, CatBoost, Factorization Machines, k-NN, LightGBM, Linear Learner, TabTransformer, XGBoost.

La documentación de Linear Learner es explícita sobre lo que es: «aprende una función lineal para regresión o una función de umbral lineal para clasificación»: lo que lo convierte en la respuesta integrada siempre que una pregunta dice regresión logística o regresión lineal.

Integrados no supervisados: PCA (reducción de dimensionalidad), K-Means (clustering), Random Cut Forest (detección de anomalías), IP Insights (anomalías de dirección IP), LDA y Neural Topic Model (modelado de temas).

• 📚 ¿Sabías que…? AWS publica listas de algoritmos, nunca un recuento. Cualquier opción que empiece «SageMaker tiene exactamente N algoritmos integrados» es un número inventado: las listas cambian a medida que se añaden y se eliminan algoritmos (AutoGluon-Tabular y TabTransformer son adiciones recientes al set tabular). Aprende la pertenencia a las listas, no un total.

---

3. Las familias supervisadas: lineales, árboles, boosting y redes neuronales

3.1 Linear Learner: el caballo de batalla de regresión y clasificación

Linear Learner es la respuesta a «qué integrado hace regresión lineal o logística?» y porta tres propiedades examinables:

Esa regla de ajuste es una respuesta gratis siempre que una opción diga «ajustar contra la métrica de entrenamiento». El remedio documentado es lo opuesto: ajusta sobre la métrica de validación.

3.2 Gradient boosting: tres integrados más un envoltorio de AutoML

El gradient boosting está representado en SageMaker por tres algoritmos integrados más una opción de ensamblado por stacking:

Detalles de XGBoost que el examen reutiliza:

• el contenedor cubre XGBoost 1.0, 1.2, 1.3, 1.5, 1.7 y 3.0;
• num_round es obligatorio (más num_class para multi:softmax y multi:softprob);
• el objetivo por defecto es reg:squarederror: así que un job de XGBoost sin configurar es un job de regresión;
• el entrenamiento con GPU se habilita con tree_method=gpu_hist;
• los hiperparámetros de mayor impacto para el ajuste son alpha, min_child_weight, subsample, eta y num_round.

3.3 El menú de métricas de XGBoost: doce objetivos con direcciones

El ajuste automático de modelos necesita un objetivo y una dirección. XGBoost expone doce métricas de validación, y la dirección es parte de la respuesta:

En esta tabla viven dos trampas. Primero, las métricas de ranking (map, ndcg) son Maximizar mientras que cada métrica de error es Minimizar: seleccionar validation:rmse con dirección Maximizar ajustaría el modelo hacia el peor resultado. Segundo, merror y mlogloss son los hermanos multiclase de error y logloss; confundirlos en una opción es un patrón de distractor común.

3.4 Árboles, bosques y redes neuronales: las rutas que necesitan código

Object2Vec merece un gancho de memoria específico: usa entropía cruzada para clasificación y error cuadrático medio (MSE) para regresión: el mismo algoritmo cambia su función de loss con la tarea, que es exactamente el tipo de detalle que una opción puede voltear para fabricar una respuesta errónea.

---

4. Las familias no supervisadas: clustering, reducción, anomalías y temas

4.1 K-Means: no existe set de validación

K-Means es la forma favorita del examen de comprobar que entiendes que el aprendizaje no supervisado no tiene set de validación etiquetado. Los puntos de documentación verificados:

• «Al ser no supervisado, no usa un dataset de validación… Pero sí toma un dataset de test.»
• Métricas objetivo: test:msd (distancias cuadradas medias) y test:ssd: ambas Minimizar;
• la inferencia devuelve closest_cluster y distance_to_cluster;
• hiperparámetros: k, init_method (random o k-means++), mini_batch_size.

Observa la dirección: las métricas de distancia se minimizan, porque una distancia cuadrada más pequeña significa conglomerados más ajustados. Cada objetivo de clustering basado en distancia en SageMaker apunta en la misma dirección.

4.2 Silhouette: una métrica real que no es una métrica de SageMaker

El coeficiente silhouette va de −1 a 1; un valor cercano a 1 significa que los puntos están ajustados dentro de su propio conglomerado y lejos de los otros. La guía de AWS es emparejar silhouette con la inercia, y dejar claro que SageMaker no la emite: la calculas tú mismo fuera del job de entrenamiento. Una pregunta que ofrezca «seleccionar validation:silhouette como objetivo de ajuste» está probando precisamente ese límite.

4.3 PCA: tres hiperparámetros obligatorios

PCA está integrado, y su configuración es examinable porque es corta:

PCA devuelve la mean, la matriz de autovectores v y los valores singulares s: que es como luego reconstruyes o proyectas datos con los componentes que conservaste.

4.4 Detección de anomalías y modelado de temas

• 📚 ¿Sabías que…? test:msd y test:ssd no son sinónimos intercambiables: msd es la distancia cuadrada media y ssd es la distancia cuadrada suma al centroide. En un set de test de n filas, ssd = msd × n, así que ssd crece con el tamaño del dataset mientras msd no. Ambas se minimizan, y ambas son objetivos de clustering válidos, pero solo msd es comparable entre sets de test de distinto tamaño.

---

5. Cuatro rutas hacia un algoritmo

AWS documenta exactamente cuatro formas de poner un algoritmo en marcha, y el examen prueba si puedes nombrarlas en orden de esfuerzo creciente.

5.1 El flujo de decisión

5.2 BYOC: las tres reglas de contenedor innegociables

Si una pregunta te empuja a la Ruta 4, tres hechos documentados deciden la respuesta:

1. el paquete de toolkit sagemaker-training es obligatorio;
2. ENV SAGEMAKER_PROGRAM train.py es la única variable de entorno requerida: nombra el punto de entrada que SageMaker invoca;
3. /opt/ml y todos sus subdirectores están reservados por el entrenamiento de SageMaker, así que las entradas, los artefactos del modelo y la salida deben seguir ese diseño.

Dos reglas de contenedor más aparecen como distractores:

• SageMaker sobrescribe el CMD por defecto de tu imagen añadiendo el argumento train;
• las imágenes con GPU deben ser compatibles con nvidia-docker: incluye el CUDA toolkit, pero no incluyas los drivers de NVIDIA: los aporta el host.

5.3 Las ventanas de soporte de los contenedores son fechas examinables

AWS publica un calendario explícito de GA → fin de parches para sus contenedores de algoritmos. El patrón que vale la pena memorizar es el formato: aproximadamente un año de soporte de parches tras la disponibilidad general, que es la razón por la que un ítem de examen fechado en 2026 puede referenciar legítimamente a un lanzamiento de 2025 que alcanza el fin de parches en ese mismo año.

---

6. Métricas de evaluación: fórmulas, direcciones y cuándo usarlas

6.1 La hoja de fórmulas

El resumen que AWS hace de la relación entre precisión y exhaustividad vale la pena memorizarlo textual: la precisión recorta los falsos positivos, la exhaustividad recorta los falsos negativos, y la F1 es la media armónica de ambas.

6.2 Elegir una métrica a partir de la matriz de confusión

6.3 Matriz de confusión resuelta #1: datos de churn balanceados

Un modelo de churn se evalúa sobre 200 clientes: TP = 80, FP = 20, FN = 10, TN = 90.

$$\text{Accuracy} = \frac{TP+TN}{N} = \frac{80+90}{200} = \frac{170}{200} = 0.85$$ $$\text{Precision} = \frac{TP}{TP+FP} = \frac{80}{100} = 0.80$$ $$\text{Recall} = \frac{TP}{TP+FN} = \frac{80}{90} = 0.889$$ $$F1 = \frac{2TP}{2TP+FP+FN} = \frac{160}{190} = 0.842$$

Lectura: el modelo captura alrededor del 89% de los que se van, pero 20 de sus 100 alertas son incorrectas. Una exactitud de 0,85 es respetable aquí porque las clases están razonablemente balanceadas (90 positivos, 110 negativos).

6.4 Matriz de confusión resuelta #2: la trampa del 1% de fraude

Un modelo de fraude se evalúa sobre 10.000 transacciones de las cuales solo 100 son fraudulentas: TP = 85, FP = 40, FN = 15, TN = 9.860.

$$\text{Accuracy} = \frac{85+9860}{10000} = \frac{9945}{10000} = 99.45\%$$

Sin embargo, un modelo que siempre predice «no fraude» ya puntúa:

$$\frac{9900}{10000} = 99.0\%$$

Así que una exactitud de 99,45% compra 0,45 puntos porcentuales sobre una línea base inútil. Las métricas que importan:

$$\text{Precision} = \frac{85}{85+40} = \frac{85}{125} = 0.68$$ $$\text{Recall} = \frac{85}{85+15} = \frac{85}{100} = 0.85$$ $$F1 = \frac{2 \times 85}{170+40+15} = \frac{170}{225} = 0.756$$

Lectura: el 32% de las alertas de fraude son falsas alarmas, el modelo se salta 15 de cada 100 fraudes, y la exactitud titular es casi sin sentido. Este es el patrón de evaluación más repetido del material propio de AWS sobre detección de fraude.

---

7. Splits de datos, validación cruzada y pruebas A/B

7.1 Los estándares de split publicados

La razón que AWS da para retener datos es una frase que vale la pena reproducir en una respuesta de examen: evaluar sobre datos de entrenamiento «recompensa a los modelos que pueden "memorizar" los datos de entrenamiento, en lugar de generalizar a partir de ellos.»

7.2 Aritmética de splits y validación cruzada sobre 100.000 filas

7.3 Validación cruzada de Autopilot: el umbral de 50.000 instancias

Con 40.000 instancias de entrenamiento (≤ 50.000, así que se aplica el modo HPO con validación cruzada automática de k = 5):

1. el split automático 80/20 da 32.000 train / 8.000 validación;
2. cada uno de los 5 folds entrena con 4/5 × 32.000 = 25.600 instancias;
3. cada fold valida sobre 6.400 instancias;
4. las cinco puntuaciones de validación se promedian en el objetivo reportado.

Un dataset de 60.000 instancias supera el umbral de ≤ 50.000, así que la validación cruzada automática en modo HPO no se activa: mientras que el modo ensemble ejecuta validación cruzada sin importar el tamaño junto a su split automático 80/20.

7.4 Cómo encaja el bucle

Comprobación interactiva: las fórmulas que no deberías tener que buscar:

---

8. Infraajuste, sobreajuste y los controles de ajuste que los corrigen

8.1 El diagnóstico

La firma oficial de sobreajuste de AWS es corta: alta exactitud de entrenamiento más baja exactitud de prueba. La dirección del remedio importa tanto como el remedio: el sobreajuste recibe más regularización, el infraajuste recibe menos. Invertirlas es un distractor clásico.

8.2 Los controles de ajuste que previenen el sobreajuste mecánicamente

Cuatro controles documentados hacen el trabajo que un humano haría a ojo:

1. Ajusta contra una métrica de validación, no de entrenamiento. La documentación de Linear Learner lo establece como recomendación, no como preferencia.
2. Early stopping. En cada época, la métrica objetivo se compara con la mediana de medias móviles de jobs anteriores; los jobs con peor rendimiento se detienen antes: AWS dice que esto «te ayuda a evitar el sobreajuste de tu modelo». El ajuste es early_stopping_type='Auto'.
3. Hyperband también termina antes los jobs con peor rendimiento, asignando el presupuesto a configuraciones prometedoras.
4. Dirección de la regularización: aumenta el sobreajuste, reduce el infraajuste.

8.3 Ordena la secuencia de diagnóstico

• 📚 ¿Sabías que…? El early stopping en el ajuste automático de modelos de SageMaker no compara tu job con un objetivo fijo: compara el valor del objetivo de cada época con la mediana de las medias móviles de todos los jobs anteriores. Eso hace que el umbral sea adaptativo: un job inicial inusualmente fuerte sube la barra para todo lo que sigue, y un job inicial débil la baja. La lista de soporte de early stopping lleva un sello de «vigente a 13 de diciembre de 2018», así que trata cualquier afirmación sobre qué algoritmos lo soportan como histórica.

---

9. Datos desbalanceados: tres palancas y los números detrás de ellas

AWS documenta tres palancas independientes para el desbalance. Una respuesta fuerte usa al menos dos de ellas a la vez.

9.1 Las tres palancas

9.2 Aritmética de pesos de clase

Caso A: un split binario de 98% / 2%. Para que la clase minoritaria cuente tanto como la mayoritaria:

$$0.02 \times w = 0.98 \implies w = \frac{0.98}{0.02} = 49$$

Así que positive_example_weight_mult='balanced' de Linear Learner sobre un dataset 98/2 produce un peso positivo de 49.

Caso B: el propio dataset de fraude de AWS. Con 284.807 ejemplos de los cuales 492 son fraudulentos (0,173%), la variante XGBoost de AWS usa la regla de la raíz cuadrada en lugar del ratio crudo:

$$\text{scale\_pos\_weight} = \sqrt{\frac{284{,}315}{492}} = \sqrt{577.9} \approx 24$$

El ratio crudo sería 577,9; el amortiguamiento por raíz cuadrada mantiene el entrenamiento estable mientras aún le dice al modelo que el fraude importa. AWS reporta además que elevar el Kappa de Cohen por encima de 0,8 sería «generally very favorable» en ese problema.

9.3 Lo que te cuesta la ponderación: el compromiso documentado

Ponderar no es gratis. El propio ejemplo multiclase de AWS muestra ambas caras:

La lección que el examen quiere: cambiaste 13 puntos de exactitud por un modelo que de verdad reconoce la clase rara. En un problema desbalanceado, ese intercambio suele ser correcto, pero debe ser una decisión, no un efecto secundario.

9.4 El cambio de métrica, lado a lado

---

10. Evaluación por tipo de tarea: la tabla de consulta

10.1 Métricas de modelos fundacionales: lo que Clarify calcula de verdad

Dos cifras de muestreo son examinables: Clarify evalúa 100 registros por defecto para la mayoría de tareas y 300 para conocimiento factual. Y un nombre de métrica de sesgo es único de Clarify: CI (Class Imbalance).

• 📚 ¿Sabías que…? La exactitud de clasificación balanceada tiene una glosa oficial de AWS: «la suma de la exhaustividad y la tasa de verdaderos negativos dividida entre 2.» Para un problema multiclase se degrada con elegancia a la media de la exhaustividad por clase: que es exactamente la razón por la que sobrevive al desbalance de clases mientras la exactitud simple no: cada clase contribuye por igual sin importar cuántas filas posea.

---

11. Juntar los tres ejes

El examen casi siempre fuerza una elección a través de tres ejes a la vez: la familia de algoritmos, el tipo de tarea y la herramienta de AWS que implementa la pareja. Acertar dos de los tres no basta.

---

12. Ejemplos resueltos con cifras

Ejemplo resuelto 1: métricas de regresión desde cero. Valores verdaderos $y = [100, 120, 140, 160, 180]$, predicciones $\hat{y} = [110, 115, 150, 155, 190]$, así que los errores son $[10, -5, 10, -5, 10]$.

• $\text{MAE} = (10+5+10+5+10)/5 = 40/5 = \mathbf{8.0}$
• $\text{MSE} = (100+25+100+25+100)/5 = 350/5 = \mathbf{70}$
• $\text{RMSE} = \sqrt{70} \approx \mathbf{8.37}$: de vuelta a las propias unidades del objetivo
• $\bar{y} = 140$, así que $SS_{tot} = 1600+400+0+400+1600 = 4000$, y $R^2 = 1 - 350/4000 = \mathbf{0.9125}$

El patrón: el MSE castiga los dos fallos de 10 puntos cuatro veces más duro que los fallos de 5 puntos (100 frente a 25), y el RMSE deshace ese cuadrado para que la cifra pueda citarse en dólares o en días.

Ejemplo resuelto 2: aritmética de splits sobre 100.000 filas. El valor por defecto 70/30 da 70.000 / 30.000; el recomendado 60/20/20 da 60.000 / 20.000 / 20.000; el holdout del 20 to 30% de SageMaker reserva 20.000 to 30.000 filas para test; k = 10 da 90.000 train / 10.000 validación por fold a lo largo de 10 modelos cuyas métricas promedias.

Ejemplo resuelto 3: la aritmética de la validación cruzada de Autopilot. Dataset de 40.000 instancias (≤ 50.000 → k-fold automático, k = 5, en modo HPO): 80/20 da 32.000 train / 8.000 validación; cada uno de los 5 folds entrena con 4/5 × 32.000 = 25.600 y valida sobre 6.400; las cinco puntuaciones se promedian. La misma receta sobre 60.000 instancias superaría el umbral y perdería la validación cruzada automática en modo HPO.

Ejemplo resuelto 4: la aritmética de pesos de clase, ambas variantes. 98% negativo / 2% positivo ⇒ $0.02 \times w = 0.98 \Rightarrow w = \mathbf{49}$. La variante de fraude de AWS usa en cambio $\text{scale\_pos\_weight} = \sqrt{284{,}315/492} = \sqrt{577.9} \approx \mathbf{24}$. Ambas son legítimas; el ratio crudo es más severo, la raíz cuadrada es el amortiguamiento documentado para el sesgo extremo.

Ejemplo resuelto 5: la matriz de confusión desbalanceada completa. 10.000 transacciones, 100 fraudes, TP = 85, FP = 40, FN = 15, TN = 9.860 ⇒ exactitud 99,45%, línea base de la mayoría 99,0%, precisión 0,68, exhaustividad 0,85, F1 0,756. La decisión que sigue: reportar F1 o AUC, no la exactitud, y declarar que 40 de 125 alertas (32%) son falsas alarmas.

Ejemplo resuelto 6, balancear un set de evaluación de 600 predicciones. Un modelo produce TP = 480, FP = 60, FN = 20, TN = 40 sobre 1.000 filas. Exactitud = $880/1000 = \mathbf{0.88}$; precisión = $480/540 = \mathbf{0.889}$; exhaustividad = $480/500 = \mathbf{0.96}$; F1 = $2(0.889)(0.96)/(0.889+0.96) = 1.707/1.849 = \mathbf{0.923}$. La tasa de verdaderos negativos = $40/100 = 0.40$, así que la exactitud balanceada = $(0.96 + 0.40)/2 = \mathbf{0.68}$, muy por debajo de la exactitud de 0,88, porque la clase negativa es donde el modelo falla. Ese hueco entre 0,88 y 0,68 es exactamente lo que la exactitud balanceada existe para exponer.

---

13. Trampas, conflictos y afirmaciones no verificadas

13.1 Afirmaciones contradictorias, no verificables y no examinables

Las fuentes primarias de esta lección son: la Exam Guide de AIF-C01; las páginas de la guía de desarrollador de SageMaker algorithms, algorithms-tabular, xgboost, xgboost-tuning, linear-learner-tuning, k-means, PCA-reference, object2vec, how-it-works-model-validation, autopilot-metrics-validation, automatic-model-tuning-early-stopping, your-algorithms-training-algo-dockerfile, train-model, pre-built-containers-frameworks-deep-learning, pre-built-containers-support-policy, clarify-foundation-model-evaluate-overview y reinforcement-learning; las páginas de la guía de desarrollador de machine learning model-fit-underfitting-vs-overfitting y evaluating_models; y las entradas del blog de Machine Learning de AWS sobre detección de fraude, balanceo con Data Wrangler, Autopilot para servicios financieros y clasificación multiclase de Linear Learner.

---

Casos Reales

Cada regla de las secciones 1 a 13 tiene su versión de cliente. Los cuatro casos de abajo provienen del digest de casos de estudio del curso (fuentes restringidas a aws.amazon.com/solutions/case-studies/* y aws.amazon.com/blogs/machine-learning/*), y cada uno se eligió porque es una historia de selección de algoritmo o de evaluación y no una anécdota de marketing: alguien eligió una ruta de la sección 5, eligió una métrica de la sección 6, y después midió el resultado sobre datos en los que el modelo no había sido entrenado.

Caso de estudio 1, Chronomics: el umbral es una decisión, no un detalle

Después de cuatro meses de modelado interno de visión por computadora que nunca alcanzó su objetivo, Chronomics trasladó la misma tarea de leer pruebas de COVID a Amazon Rekognition Custom Labels (AutoML) y se entregó en 3 to 4 semanas con 96,5% de exactitud y 97,9% de F1, puntuado con DetectCustomLabels. La parte examinable es lo que pasó después: elevar el umbral de confianza compró precisión y pagó por ella con cobertura.

Fuente: AWS Machine Learning Blog, blogs/machine-learning/chronomics-detects-covid-19-test-results-with-amazon-rekognition-custom-labels (13 dic 2022).

La lección refleja la sección 6: una sola cifra de exactitud nunca te dice cuánto cuesta un cambio de umbral. Chronomics no reentrenó entre las dos filas: solo cambió qué predicciones estaba dispuesto a firmar, que es la razón por la que «qué pasa con las filas descartadas?» debe responderse antes del despliegue.

Caso de estudio 2, Sun Finance: evalúa cada intento, y nunca dejes que un modelo haga dos trabajos

Sun Finance automatizó la extracción de documentos KYC en nueve países. La escalera de intentos documentada es la narrativa de evaluación más limpia del digest:

Fuente: AWS Machine Learning Blog, blogs/machine-learning/sun-finance-automates-id-extraction-and-fraud-detection-with-generative-ai-on-aws (30 abr 2026); evaluado sobre 585 imágenes.

Aquí viven dos hábitos de examen. Primero, el intento 1 se midió y se rechazó: el equipo no entregó por sensaciones, entregó sobre un set de evaluación retenido. Segundo, el OCR y el razonamiento son trabajos separados: el servicio de extracción preconstruido (Ruta 1) hizo la lectura, el modelo fundacional solo estructuró lo que ya estaba leído, y las reglas de validación cazaron el resto.

Caso de estudio 3, HAYAT HOLDING: el ajuste automático reemplaza al barrido manual

HAYAT HOLDING transmite 194 sensores por OPC-UA hacia un SiteWise Edge Gateway de AWS IoT Greengrass, y después entrena en SageMaker Model Training con SageMaker Automatic Model Tuning, despliega con SageMaker Model Deployment y ejecuta los modelos en el dispositivo a través de SageMaker Edge Manager. El resultado documentado son $300.000 al año ahorrados más mayor calidad de los paneles.

Fuente: AWS Machine Learning Blog, blogs/machine-learning/hayat-holding-uses-amazon-sagemaker-to-increase-product-quality-and-optimize-manufacturing-output-saving-300000-annually (2023).

Esta es la 8.2 corriendo sin supervisión: en lugar de un humano barriendo hiperparámetros a ojo, el tuner busca en el espacio de configuración contra una métrica de validación y detiene antes los jobs débiles. Cuando una pregunta pide cómo un equipo escala el ajuste a muchos modelos o entradas, la respuesta documentada es Automatic Model Tuning: no una hoja de cálculo más grande.

Caso de estudio 4, Adobe: el chunking y los embeddings también son hiperparámetros

Adobe mejoró la búsqueda de documentación para desarrolladores con Amazon Bedrock Knowledge Bases, probando cuatro estrategias de chunking (400 tokens con 20% de solapamiento, 1.000 tokens, jerárquica, semántica) emparejadas con Amazon Titan Text Embeddings V2 hacia OpenSearch Service, recuperadas a través de la Retrieve API. El resultado sobre el propio set de pruebas de Adobe fue +20% de precisión de recuperación, y la estrategia más simple, chunks de 400 tokens con 20% de solapamiento, fue también la más precisa.

Fuente: AWS Machine Learning Blog, blogs/machine-learning/adobe-enhances-developer-productivity-using-amazon-bedrock-knowledge-bases (11 jun 2025).

La disciplina de evaluación es idéntica a la sección 7: los candidatos se compararon sobre un set de prueba fijo y retenido, no sobre las consultas con las que se construyeron. La calidad de la recuperación es un problema de selección de modelo: el tamaño del chunk, el solapamiento y la elección del embedding son los hiperparámetros, y la métrica decide.

• 📚 ¿Sabías que…? AWS publica exactamente una tasa de resultados de proyectos: el 65% de los proyectos del Generative AI Innovation Center llegó a producción en 2025, de más de 1.000 implementaciones, con algunos entregándose en tan solo 45 días. El método detrás es el Five V's framework, Value → Visualize → Validate → Verify → Venture, que parte de métricas de línea base (exactitud y resultado de negocio) antes de entrenar un solo modelo. Fuente: AWS Machine Learning Blog, blogs/machine-learning/beyond-pilots-a-proven-framework-for-scaling-ai-to-production (2025). El corolario que a los examinadores les gusta: el 35% no llegó a producción, así que la evaluación es una fase, no una ceremonia.

• 📚 ¿Sabías que…? La ruta humana para el 5% descartado de Chronomics ya tiene nombre de producto: Amazon Augmented AI (A2I), disponible desde 2020 con más de 60 flujos de trabajo, existe porque «los clientes todavía dicen que hay casos de uso críticos en los que se requiere el juicio humano.» A2I es la forma en que un pipeline de visión o de documentos con umbral alto convierte las abstenciones en resultados revisados en lugar de filas descartadas: el mismo principio de diseño que la ruta de excepción humana de Anthem para las reclamaciones que Textract no automatizó.

---

14. Preguntas de Práctica (Practice Questions)