Saltar al contenido principal
Todos los casos de estudio

Machine Learning · Salud · Despliegue en la nube

Plataforma de clasificación de condiciones médicas

Un clasificador Random Forest sobre datos institucionales de salud, servido por una API Flask en AWS, evaluado con honestidad como un problema de ranking top-N y no de respuesta única.

Académico · Desplegado en AWS
Rol
Ingeniero de Software — modelado, API y despliegue en la nube
Periodo
2025

Etapas cubiertas

  • Arquitectura
  • Construcción
  • Despliegue

De un vistazo

2025

Precisión top-1
29.26%
Precisión top-3
53.79%
Precisión top-10
88.76%

Modelado

  • Python
  • scikit-learn
  • Random Forest

Servicio

  • Flask
  • MySQL

Infraestructura

  • Amazon EC2
  • Amazon RDS
  • Amazon S3
  • Application Load Balancer
  • Route 53
  • AWS Certificate Manager

Resumen

Una plataforma de machine learning que sugiere categorías probables de condición relacionadas con CIE-10 a partir de registros institucionales de salud. El modelo se entrenó con datos institucionales reales con desbalance de clases considerable y se desplegó en AWS detrás de un balanceador de carga con HTTPS. Aquí se presenta como una herramienta de apoyo a la decisión por ranking, que es lo que su precisión medida realmente sostiene.

Precisión top-1
29.26%
Precisión top-3
53.79%
Precisión top-10
88.76%

Problema

Los registros institucionales de salud cargan una gran cantidad de categorías de condición, y su distribución es muy despareja: un puñado de categorías domina mientras una cola larga aparece pocas veces. Un clasificador entrenado con esos datos se verá competente en las métricas agregadas mientras es casi inútil justo en las categorías que más necesitan ayuda.

La pregunta de encuadre no era entonces '¿puede un modelo predecir la condición?' sino '¿existe una forma de predicción que de verdad sea usable por alguien que hace este trabajo?'.

Restricciones

  • Datos institucionales reales, con el manejo de privacidad y los límites de acceso que eso implica
  • Un número grande de clases objetivo respecto al número de ejemplos por clase
  • Desbalance de clases severo que ningún ajuste de modelo elimina
  • Un contexto clínico, donde una única respuesta segura de sí misma y equivocada es peor que ninguna respuesta

Rol y contribución

Ingeniero de Software — modelado, API y despliegue en la nube

  • Preparé y analicé el dataset institucional, incluida la distribución de clases
  • Entrené y evalué el clasificador Random Forest
  • Diseñé la evaluación top-N usada para juzgar si el modelo era útil
  • Construí la API de inferencia en Flask y su persistencia en MySQL
  • Aprovisioné el despliegue en AWS: cómputo, base de datos administrada, almacenamiento de objetos, balanceo, DNS y TLS

Diseño del sistema

Arquitectura

Topología de despliegue

Las peticiones del cliente llegan por HTTPS a un Application Load Balancer, con el DNS manejado por Route 53 y el certificado emitido por AWS Certificate Manager. El balanceador reenvía a una aplicación Flask que corre en Amazon EC2, la cual carga el artefacto del modelo entrenado desde Amazon S3 y lee y escribe datos estructurados en Amazon RDS con MySQL.

Modelado
  • Python
  • scikit-learn
  • Random Forest
Servicio
  • Flask
  • MySQL
Infraestructura
  • Amazon EC2
  • Amazon RDS
  • Amazon S3
  • Application Load Balancer
  • Route 53
  • AWS Certificate Manager

Leer los resultados con honestidad

La precisión top-1 es 29.26%. Por sí sola es un clasificador débil, y presentarla como otra cosa sería deshonesto.

Las cifras útiles son las de ranking: la categoría correcta está entre las tres primeras del modelo el 53.79% de las veces y entre las diez primeras el 88.76%. La distancia entre 29% y 89% es todo el hallazgo. Dice que el modelo aprendió muchísimo sobre qué categorías son plausibles para un registro dado, y comparativamente poco sobre cómo elegir entre las pocas que quedan.

Contra un espacio de etiquetas grande y muy desbalanceado, esa es la forma esperada. Una predicción única obliga al modelo a gastar su confianza en una decisión que los datos no sostienen; una lista corta ordenada corresponde con lo que realmente sabe.

Por qué top-N era el objetivo operativo correcto

Una herramienta que propone una categoría y se equivoca siete de cada diez veces será ignorada después de una semana. Una herramienta que reduce cientos de categorías a diez, y acierta unas nueve de cada diez veces en que la respuesta está en esa lista, elimina la mayor parte de la búsqueda y deja el juicio donde corresponde.

Ese reencuadre cambió lo que el sistema tenía que ser. No es un clasificador automatizado; es un generador de listas cortas cuyo trabajo es ser confiablemente incluyente en vez de ocasionalmente exacto.

Limitaciones y riesgo clínico

Este es un proyecto académico. No ha sido validado clínicamente, no es un dispositivo médico, y no debe usarse para hacer o sustentar un diagnóstico.

Dos limitaciones importan más. El desbalance de clases significa que las categorías raras — muchas veces aquellas donde la asistencia sería más valiosa — son las que el modelo ha visto menos y predice peor; la precisión agregada esconde esto por completo. Y una lista corta crea su propio riesgo: una lista de aspecto plausible puede anclar a quien la lee hacia su contenido y alejarlo de una respuesta correcta que no está ahí.

  • No validado clínicamente; no es un dispositivo médico
  • Las categorías raras son las más débiles y quedan ocultas por las métricas agregadas
  • Una lista corta puede anclar el juicio hacia las opciones que contiene
  • Entrenado con datos de una sola institución, sin evidencia de transferencia a otra

Decisiones clave y trade-offs

Decisión

Evaluar como tarea de ranking top-N en vez de clasificación de etiqueta única

Contexto
Una precisión top-1 de 29.26% contra un espacio de etiquetas grande y desbalanceado se lee como un modelo fallido bajo el encuadre por defecto.
Alternativas consideradas
  • Reportar solo la precisión top-1 y tratar el proyecto como fallido
  • Reducir el problema fusionando categorías hasta que el top-1 se vea aceptable
Enfoque elegido
Reportar top-1, top-3 y top-10 juntos y diseñar el producto alrededor de la salida ordenada.
Razón
La distancia de 29% a 89% muestra que el modelo es informativo incluso cuando no puede comprometerse con una respuesta. Fusionar categorías habría mejorado la métrica descartando justo las distinciones para las que la herramienta existe.
Trade-off
El sistema no se puede automatizar: siempre requiere que una persona elija de la lista corta. Ese es el trade-off correcto en un contexto clínico.
Resultado
La categoría correcta aparece entre las diez primeras el 88.76% de las veces.

Decisión

Analizar el desbalance de clases como un resultado de primera clase

Contexto
La distribución de categorías del dataset es muy despareja.
Alternativa considerada
  • Remuestrear o reponderar hasta que las métricas agregadas mejoren, y reportar solo el número mejorado
Enfoque elegido
Reportar la distribución junto a las cifras de precisión.
Razón
La precisión agregada sobre datos desbalanceados mide sobre todo las clases mayoritarias. Sin la distribución, el número titular invita a sobreestimar el modelo justo donde más importa.
Trade-off
Un resultado titular menos halagador, y más explicación requerida a cada lector.

Resultado

  • Medido: top-1 29.26%, top-3 53.79%, top-10 88.76%
  • Desplegado y accesible por HTTPS en AWS detrás de un Application Load Balancer
  • Reencuadrado de clasificador de respuesta única a herramienta de lista corta que corresponde con lo que los datos sostienen

Aprendizajes

  • La métrica de evaluación es una decisión de producto. Elegir top-N sobre top-1 cambió para qué servía el sistema, no solo cómo puntuaba.
  • La precisión agregada sobre datos desbalanceados es casi carente de significado sin la distribución al lado.
  • El despliegue sacó a la luz problemas que el entrenamiento nunca mostró: la carga del artefacto del modelo, el arranque en frío y el manejo de certificados no son preocupaciones de modelado pero deciden si alguien puede usar el modelo.
  • En un contexto clínico, un sistema que se niega a estar seguro es más confiable que uno que se equivoca con seguridad.

Próximas mejoras

  • Métricas por clase, sobre todo recall en las categorías raras que las cifras agregadas ocultan
  • Probabilidades calibradas para que la lista corta pueda expresar qué tan segura está, no solo qué ordena
  • Comparación contra líneas base de gradient boosting y modelos lineales para establecer si Random Forest es la familia correcta aquí
  • Validación con datos de una segunda institución antes de cualquier afirmación de generalidad