Cómo documentar, interpretar y presentar tu proyecto de machine learning

En más de 50 proyectos de machine learning he visto el mismo patrón repetirse: el modelo funciona, las métricas son sólidas, y aun así el proyecto no genera impacto. No porque el modelo sea malo. Sino porque nadie fuera del equipo técnico entiende qué significa, cómo usarlo o por qué confiar en él.

Un estudio de arXiv sobre explicabilidad de ML para stakeholders externos documenta que la falta de un lenguaje compartido entre quienes construyen modelos y quienes los usan es uno de los principales obstáculos para que los sistemas de ML sean adoptados en entornos de alto impacto (Bhatt et al., 2020, arXiv 2007.05408). No es un problema de precisión. Es un problema de comunicación.

Este artículo es el mapa completo de lo que viene después de entrenar el modelo: cómo interpretar los resultados para distintas audiencias, cómo escribir y defender el proyecto, y cómo convertirlo en un activo de carrera. Cada sección de este mapa tiene su propio sub-pilar con profundidad completa.

Tabla de contenido:

• El problema que nadie resuelve: el modelo funciona pero nadie lo entiende
• ¿Tu proyecto está bloqueado en esta etapa?
• El framework completo: tres etapas después de entrenar
• El mapa del cluster: cómo navegar estas tres etapas
• Señales de que tu proyecto necesita trabajo aquí
• Proyectos de referencia en este framework
• Preguntas frecuentes

El problema que nadie resuelve: el modelo funciona pero nadie lo entiende

La mayoría de los recursos sobre machine learning terminan cuando el modelo termina. Hay tutoriales para preparar datos, seleccionar algoritmos, ajustar hiperparámetros y evaluar métricas. Pero casi ninguno responde la pregunta que aparece inmediatamente después: ¿y ahora qué hago con esto?

Google define explícitamente que los entregables de un proyecto de ML incluyen documentos de diseño, resultados experimentales e implementaciones listas para producción que otros equipos puedan entender y auditar (Google Developers — ML Projects Stakeholders). Ese último requisito es precisamente el que más se ignora.

He visto este patrón en proyectos académicos y en proyectos empresariales. El equipo técnico sabe que el modelo es bueno. Pero cuando llega el momento de explicarlo, de defenderlo o de usarlo para conseguir trabajo, aparece el bloqueo. No porque el trabajo sea malo, sino porque nunca se pensó en la audiencia.

¿Tu proyecto está bloqueado en esta etapa?

Si ya tienes un modelo entrenado pero no sabes cómo explicar sus resultados, cómo estructurar la documentación o cómo presentarlo en una entrevista o defensa, puedo revisar tu proyecto y darte un diagnóstico claro de qué falta y en qué orden resolverlo.

Sin compromiso. Sin ventas. Solo claridad sobre el siguiente paso concreto.

Quiero que revises mi proyecto →

El framework completo: tres etapas después de entrenar el modelo

La fase de documentación, interpretación y presentación no es una sola tarea. Es un sistema de tres etapas que deben trabajarse en orden, porque cada una depende de la anterior.

Etapa 1: Interpretar — ¿qué significan tus resultados realmente?

El primer problema no es técnico: es de traducción. Tienes métricas — accuracy, F1, RMSE, AUC — pero esas métricas no hablan por sí solas. Lo que importa es qué significan para quien va a tomar decisiones con el modelo. Un ROC AUC de 0.85 puede ser excelente en un contexto y completamente insuficiente en otro. La interpretación correcta depende de la audiencia, del dominio y del costo real de cada tipo de error.

→ Cómo interpretar y explicar los resultados de tu modelo de ML

Etapa 2: Escribir y defender — ¿cómo documentas y presentas el trabajo?

Una vez que entiendes lo que significan tus resultados, necesitas estructurarlos en un documento o presentación que otros puedan evaluar. Esto es diferente para una tesis académica y para un proyecto empresarial, pero hay una estructura base que funciona en ambos contextos: planteamiento del problema, decisiones sobre los datos, justificación del modelo, análisis de resultados y limitaciones honestas. La defensa oral añade una capa adicional: saber responder preguntas que no esperabas.

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

Etapa 3: Crecer profesionalmente — ¿cómo conviertes el proyecto en carrera?

Un proyecto bien documentado y presentado es también un activo de carrera. Los reclutadores no evalúan el código: evalúan si el candidato puede hablar del proyecto, explicar las decisiones que tomó y conectar los resultados con el problema de negocio. Transformar un notebook o una tesis en un README que cuenta una historia, en una presentación de entrevista o en un post de LinkedIn que demuestra autoridad son habilidades distintas, con su propia técnica.

→ Cómo usar tu proyecto de ML para crecer profesionalmente

Señales de que tu proyecto necesita trabajo en estas tres áreas

Estas son las situaciones concretas que indican que el proyecto técnico está terminado pero la comunicación no:

• Tu asesor o comité pide "que expliques mejor los resultados" sin decirte exactamente cómo hacerlo.
• Presentas el proyecto y la primera pregunta del público es "¿y eso para qué sirve en la práctica?"
• Tu README en GitHub tiene código funcional pero no tiene contexto del problema que resuelve.
• Sabes que el modelo funciona pero no podrías defenderlo fluidamente en una entrevista técnica de 20 minutos.
• Terminaste la tesis y no sabes cómo ponerla en tu CV de forma que le importe a un reclutador.
• Entregaste el informe y el cliente o stakeholder preguntó "¿qué hacemos con este número?" — la señal más clara de que los resultados no estaban traducidos.

Cada una de estas señales corresponde a una etapa específica del framework. La primera y la sexta apuntan a interpretación. La segunda y la cuarta, a escritura y defensa. La tercera y la quinta, a crecimiento profesional.

Proyectos de referencia en este framework

Los tres problemas de comunicación que describe este framework aparecen en proyectos reales con características muy distintas. Algunos ejemplos de mi portafolio donde estos tres bloqueos fueron centrales:

• Proyecto #36 — Árbitros de laboratorios: el modelo de clasificación funcionaba correctamente, pero los resultados tenían que presentarse ante un comité con nulo conocimiento técnico. El reto no fue el modelo: fue traducir la matriz de confusión a decisiones operativas concretas que el comité pudiera aprobar.
• Proyecto #41 — Violencia familiar: los resultados positivos del modelo tenían implicaciones legales y éticas. Documentar las limitaciones correctamente, en lenguaje que un comité jurídico pudiera evaluar, fue más complejo que construir el modelo mismo.
• Proyecto #52 — Innovación: el proyecto académico terminó bien evaluado, pero convertirlo en algo presentable para empleadores requirió reescribir completamente cómo se describía el problema, las decisiones y el impacto.

Preguntas frecuentes sobre documentación y presentación de proyectos de ML

¿Para qué sirve documentar un proyecto de ML si ya está funcionando?

Un modelo que funciona pero que nadie entiende no genera impacto. Documentar sirve para que otros equipos puedan auditarlo, para que stakeholders no técnicos tomen decisiones con él, para defenderlo en una tesis o entrevista, y para convertirlo en un activo de carrera. Google define que los entregables de un proyecto de ML incluyen documentación que otros equipos puedan entender, no solo el modelo ejecutándose.

¿Qué diferencia hay entre interpretar resultados y reportarlos?

Reportar es presentar los números. Interpretar es explicar qué significan esos números para quien toma decisiones. Un data scientist puede reportar "ROC AUC de 0.85" sin que eso le diga nada útil a un stakeholder. Interpretar implica traducir esa métrica al lenguaje del dominio: qué decisiones habilita, qué errores comete el modelo y qué consecuencias tienen esos errores en el contexto real.

¿Cómo se defiende un proyecto de ML ante un comité no técnico?

Evitando la jerga y conectando cada resultado con una decisión o acción concreta. La audiencia no técnica no necesita entender el algoritmo, necesita entender por qué el resultado importa para sus objetivos. Esto significa hablar de impacto — qué problema resuelve, cuánto mejor es que la alternativa anterior, y qué limitaciones existen que el comité debe conocer para tomar decisiones informadas.

¿Necesito GitHub para conseguir trabajo en data science?

Para roles técnicos en ML, sí es prácticamente necesario. Pero lo que importa no es el volumen de repositorios sino la calidad de cómo están documentados. Un proyecto con un README que explica claramente el problema, las decisiones y los resultados comunica más sobre las capacidades del candidato que veinte notebooks vacíos de contexto.