Cómo interpretar y explicar los resultados de tu modelo de machine learning

Un data scientist anuncia "nuestro modelo alcanzó un ROC AUC de 0.85" y el ejecutivo al otro lado de la mesa piensa en silencio: "¿debería estar impresionado?" No es una situación hipotética. Es el patrón más frecuente en proyectos reales donde los resultados técnicos están desconectados del lenguaje en que se toman decisiones.

El problema no es la métrica. El problema es que la métrica no está traducida. Y esa traducción no es opcional: es lo que determina si el trabajo genera impacto o si queda archivado.

Este artículo no explica cómo calcular métricas — eso ya está cubierto en el artículo de selección y evaluación de modelos. Explica qué hacer con las métricas una vez que las tienes, según a quién le estás hablando.

Tabla de contenido:

• El error más frecuente: números sin contexto
• ¿Necesitas ayuda para presentar tus resultados?
• Antes de interpretar: ¿a quién le estás explicando?
• Cómo interpretar métricas de clasificación
• Cómo interpretar métricas de regresión
• SHAP y explicabilidad local
• Cómo traducir resultados técnicos a lenguaje de impacto
• Visualizaciones que comunican vs visualizaciones que confunden
• Qué hacer cuando los resultados no son buenos
• Preguntas frecuentes

El error más frecuente: presentar números sin contexto

El error que más se repite en proyectos reales es asumir que los stakeholders saben qué hacer con las salidas del modelo. Entregar tablas de probabilidades, matrices de confusión o valores de RMSE sin contexto genera una pregunta inevitable: "¿y esto qué significa para nosotros?" En proyectos donde he cometido ese error, los usuarios terminaban tomando decisiones con el número incorrecto porque nadie les había explicado cuál era el relevante.

Un estudio de arXiv sobre explicabilidad de ML para stakeholders externos documenta que incluso expertos en distintas disciplinas — académicos, abogados, reguladores — tienen dificultades para construir un lenguaje compartido alrededor de los resultados de modelos de ML, y que esa brecha comunicacional es uno de los principales obstáculos para la adopción real de estos sistemas (Bhatt et al., 2020, arXiv 2007.05408).

La solución no es simplificar los resultados hasta el punto de perder rigor. Es estructurar la comunicación en capas: primero el impacto en lenguaje del dominio, luego las métricas que lo respaldan, y finalmente los detalles técnicos para quien los necesite.

¿Necesitas ayuda para presentar tus resultados?

Si ya tienes el modelo y las métricas pero no sabes cómo comunicarlos a tu comité, cliente o equipo, puedo revisar tu caso y ayudarte a estructurar la presentación correctamente según tu audiencia.

Quiero ayuda con mis resultados →

Antes de interpretar: ¿a quién le estás explicando?

La misma métrica necesita una traducción diferente según la audiencia. Definir esto antes de preparar la presentación ahorra reescrituras completas.

Tu asesor o comité académico

Espera rigor metodológico. Necesita ver la comparación con baselines, la varianza entre folds, la justificación de las métricas elegidas y el análisis de limitaciones del modelo. El error más frecuente con comités académicos es reportar solo el mejor resultado sin mostrar la estabilidad a través de distintas particiones. Un modelo que tiene 0.92 de F1 en promedio pero 0.68 en el peor fold tiene un problema real que el comité va a detectar.

Un stakeholder de negocio o cliente

Espera impacto medible en sus KPIs, no jerga técnica. Lo que necesita ver es la traducción del resultado a decisiones concretas: qué puede hacer el negocio con este modelo que no podía hacer antes, cuánto mejor es respecto a la situación anterior, y qué tipo de errores comete el modelo que el negocio debe tener en cuenta. En proyectos reales he aprendido que la pregunta "¿a quién actuamos con este resultado?" es más útil que cualquier tabla de métricas para alinear expectativas. Google define que la comunicación de resultados experimentales debe alinearse con las expectativas de cada stakeholder en cada fase del proyecto (Google Developers — ML Projects).

Un entrevistador técnico

Espera que puedas defender las decisiones que tomaste. No busca que el modelo sea perfecto — busca que entiendas por qué elegiste esas métricas, qué implican sus limitaciones y qué habrías hecho diferente con más tiempo o más datos. La fluidez para hablar del proyecto, más que el resultado numérico, es lo que convence en entrevistas técnicas.

Cómo interpretar métricas de clasificación según el contexto

La trampa del accuracy con clases desbalanceadas

Con clases desbalanceadas, accuracy miente. Un modelo que predice siempre la clase mayoritaria en un dataset 80/20 obtiene 80% de accuracy y cero utilidad. En esos casos, MCC y PR AUC son más honestos porque sus denominadores incluyen directamente el rendimiento en la clase minoritaria. Al presentar resultados de un modelo de clasificación desbalanceada, siempre incluir MCC o PR AUC como métrica principal, y explicar explícitamente por qué accuracy no es suficiente.

Cómo leer una matriz de confusión para comunicar dónde falla el modelo

La matriz de confusión no es solo un número — es un mapa de los errores del modelo. Para comunicarla efectivamente a audiencias no técnicas, lo más útil no es la tabla numérica sino la traducción a consecuencias reales: ¿cuántos casos positivos el modelo no detectó? ¿Cuántas alertas falsas genera? En un proyecto de detección de violencia familiar, la diferencia entre un falso negativo y un falso positivo tenía consecuencias legales completamente distintas, y eso era lo que el comité evaluador necesitaba entender, no los números de la matriz.

Cuándo usar F1, MCC o PR AUC

• F1: cuando no hay razón clara para priorizar precision sobre recall y las clases están razonablemente balanceadas.
• MCC: cuando las clases están desbalanceadas y necesitas una métrica que no se infle por la clase mayoritaria.
• PR AUC: cuando la clase positiva es la minoritaria y el sistema necesita encontrarla con alta precision — recomendaciones, detección de anomalías, sistemas de alerta.

Cómo interpretar métricas de regresión

MAE, RMSE y el análisis de residuos

MAE da el error promedio en las mismas unidades del problema — es la métrica más fácil de comunicar a audiencias no técnicas. RMSE penaliza los errores grandes cuadráticamente, lo que lo hace más informativo cuando los errores grandes tienen consecuencias operativas graves. La elección entre los dos no es técnica: es del dominio.

El análisis de residuos es lo que MAE y RMSE no muestran: si el modelo comete errores sistemáticamente en ciertos rangos del target. Un modelo de predicción de precios de abarrotes puede tener un MAE global aceptable y al mismo tiempo predecir sistemáticamente mal en periodos de alta inflación, precisamente cuando más importa acertar. En proyectos reales, graficar el error en función del valor predicho ha revelado problemas que el número global nunca habría detectado.

SHAP y explicabilidad local: cuándo añade valor y cuándo es decorativo

SHAP (SHapley Additive exPlanations) permite explicar por qué el modelo tomó una decisión específica para una instancia concreta. En proyectos con stakeholders que necesitan entender o auditar decisiones individuales — crédito, salud, justicia — SHAP es prácticamente obligatorio. En proyectos donde solo importa el rendimiento agregado, puede ser prescindible.

El error más frecuente con SHAP no es usarlo mal técnicamente, sino mostrar el gráfico sin explicarlo. Un gráfico de importancia de features no se explica solo. Lo que comunica — que el género del pasajero explica casi la mitad de las predicciones de supervivencia en el Titanic, por ejemplo — necesita traducirse al lenguaje del dominio para que tenga sentido para la audiencia.

Cuando he presentado resultados de SHAP a comités académicos, lo que generó conversación útil no fue el gráfico en sí, sino la pregunta de si esa importancia de features tiene sentido con el conocimiento del dominio. Un modelo que da alta importancia a una variable que no debería ser relevante es una señal de data leakage o de sesgo que vale más discutir que cualquier métrica global.

Cómo traducir resultados técnicos a lenguaje de impacto

La técnica más efectiva para audiencias no técnicas es reemplazar el número abstracto por una consecuencia concreta. No "el modelo tiene precision de 0.72", sino "de cada 10 alertas que genera el modelo, 7 corresponden a casos reales". No "RMSE de 14.57 unidades", sino "el modelo se equivoca en promedio 15 bicicletas por hora de predicción, lo que en horas pico representa menos del 5% de la demanda real".

En proyectos reales, convertir las salidas del modelo en tres categorías accionables — alto, medio y bajo riesgo, ligadas a recursos disponibles — ha sido consistentemente más útil que presentar probabilidades brutas. La audiencia no necesita el número: necesita saber qué hacer con él.

Para comparar el modelo con la situación anterior, el gráfico más efectivo no es la curva ROC — es una barra simple que muestra el resultado antes y después del modelo en términos de KPIs de negocio. El lift sobre la línea base, expresado en porcentaje de mejora o en unidades monetarias si el dominio lo permite, es lo que convierte un resultado técnico en un argumento de valor.

Al explicar incertidumbre, la transparencia construye credibilidad en lugar de restarla. Admitir "este pronóstico tiene un margen de variación de ±X% en este segmento" y explicitar los supuestos del modelo demuestra rigor. Los stakeholders que trabajan con incertidumbre en sus propios dominios valoran que el modelo no pretenda una certeza que no tiene.

Visualizaciones que comunican vs visualizaciones que confunden

No todas las visualizaciones sirven para todas las audiencias. Hay un conjunto de gráficos que sistemáticamente generan confusión en lugar de claridad, y que vale la pena evitar independientemente de cuánto se usen en tutoriales.

Qué evitar

Los gráficos de pastel en 3D distorsionan las proporciones reales por el efecto de perspectiva. Los gráficos de líneas con ejes dobles sin escala explícita crean comparaciones engañosas. Un dashboard con más de cinco o seis series en el mismo gráfico de líneas se vuelve ilegible para cualquier audiencia. Cada vez que he simplificado un dashboard — separando gráficos o reduciendo series — la comprensión del stakeholder mejoró sin excepción.

Qué funciona

El gráfico antes/después o modelo/baseline es la visualización más impactante para comunicar valor. Una barra que muestra el costo actual y el costo estimado con el modelo, o el porcentaje de casos correctamente identificados antes y después, hace inmediatamente visible el valor agregado. Para clasificación, la matriz de confusión normalizada (en porcentajes, no en valores absolutos) es más legible y permite comparar entre clases de distinto tamaño. Para importancia de features, un gráfico de barras horizontal con las cinco o diez features más relevantes comunica más que un gráfico de árbol complejo.

Los filtros interactivos en dashboards añaden valor cuando el stakeholder necesita explorar escenarios — optimista, pesimista, por segmento — sin que esa exploración requiera intervención técnica. He visto este formato cambiar completamente la dinámica de una reunión de resultados: de una presentación unidireccional a una conversación sobre decisiones reales.

Qué hacer cuando los resultados no son buenos

Un modelo con resultados mediocres bien interpretado es más valioso que un modelo con resultados excelentes mal explicados. Esto no es un consuelo — es una observación práctica. Los stakeholders que entienden las limitaciones del modelo toman mejores decisiones con él que los stakeholders que creen que el modelo es infalible.

Cómo reportar limitaciones sin destruir la credibilidad del trabajo: enmarcarlas como hallazgos, no como fracasos. "El modelo tiene dificultades para predecir correctamente en periodos de alta volatilidad del mercado" es un hallazgo útil. "El modelo falla" no lo es. La diferencia está en que el primero incluye el contexto que explica la limitación y que permite al stakeholder saber cuándo confiar en el modelo y cuándo no.

En tesis académicas, los resultados negativos son perfectamente aceptables y a veces esperados. Un proyecto que demuestra que un método no funciona para un problema específico, y que documenta por qué, contribuye al conocimiento del campo de la misma forma que uno que reporta resultados positivos.

Preguntas frecuentes sobre interpretación de resultados de ML

¿Cómo sé si mis resultados son suficientemente buenos?

Depende del dominio, no del número. La pregunta correcta es si el modelo es mejor que la alternativa actual y si sus errores son aceptables dado el costo real de equivocarse en tu contexto. Un F1 de 0.78 puede ser excelente en un problema y completamente insuficiente en otro.

¿Tengo que usar SHAP para defender un proyecto académico?

No es obligatorio, pero es la herramienta más robusta para explicar por qué el modelo toma ciertas decisiones. Solo añade valor si puedes interpretar sus resultados y conectarlos con el conocimiento del dominio. Mostrar el gráfico sin poder explicarlo genera más preguntas de las que responde.

¿Cómo presento resultados negativos sin que parezca que el proyecto fracasó?

Enmarcándolos como hallazgos. Documenta qué aprendiste sobre el problema, por qué el modelo tiene las limitaciones que tiene, y qué condiciones serían necesarias para mejorar los resultados. En tesis académicas los resultados negativos bien documentados son valiosos.

¿Qué métricas presentar si no sé quién va a leer el informe?

La métrica más honesta para tu tipo de problema. Para clasificación desbalanceada, MCC y PR AUC. Para clasificación balanceada, accuracy y F1. Para regresión, MAE con análisis de residuos mínimo. Luego añade una traducción al lenguaje de impacto para quien no sea técnico.

Siguiente paso en el framework

Una vez que sabes cómo interpretar tus resultados, el paso siguiente es estructurarlos en un documento o defensa que otros puedan evaluar:

• Cómo escribir y defender tu proyecto o tesis de ML →

O regresa al mapa completo: Cómo documentar, interpretar y presentar tu proyecto de ML.

Si ya tienes tus métricas pero no sabes cómo presentarlas a tu comité, cliente o entrevistador, puedo ayudarte a estructurar la comunicación según tu audiencia específica.

Quiero ayuda con la interpretación de mis resultados →