/ Documentar proyectos ML / Escribir y defender
Cómo escribir y defender tu proyecto o tesis de machine learning
La estructura que los comités académicos y los equipos técnicos esperan — y que nadie te enseña explícitamente.
La sección de planteamiento del problema es la que más veces se reescribe en proyectos reales. No porque sea la más difícil técnicamente, sino porque al inicio del proyecto el problema no está claro — y esa falta de claridad persiste hasta que alguien lo lee desde fuera y pregunta "¿pero qué estás resolviendo exactamente?"
Un proyecto de ML tiene componentes que no existen en la ingeniería de software clásica ni en la ciencia tradicional. Tiene decisiones de datos que determinan qué puede y qué no puede aprender el modelo. Tiene justificaciones de métricas que dependen del dominio, no de la técnica. Tiene análisis de limitaciones que no son opcionales sino parte del resultado. Ninguna plantilla genérica de tesis captura todo esto.
Este artículo da la estructura que funciona para proyectos aplicados de ML, tanto en contextos académicos como empresariales. Y da también la guía para la defensa oral, porque la escritura y la defensa son dos habilidades distintas que requieren preparación diferente.
Tabla de contenido:
Por qué escribir un proyecto de ML es diferente a escribir software o ciencia tradicional
Un proyecto de ML es híbrido: tiene rigor empírico (como la ciencia), produce artefactos ejecutables (como la ingeniería de software), y sus resultados dependen de datos que cambian (a diferencia de ambas). Esa naturaleza híbrida significa que ninguna de las estructuras estándar se aplica directamente.
En ingeniería de software, el producto es el código y la documentación describe cómo funciona. En ML, el código es solo el vehículo — el producto es el modelo y las decisiones que lo produjeron. En ciencia experimental clásica, hay una hipótesis falsable y un experimento diseñado para probarla. En ML aplicado, el objetivo es resolver un problema práctico, y las decisiones de modelado se justifican por su efecto en ese objetivo, no por un marco teórico previo.
Esto implica que la documentación de un proyecto de ML debe responder preguntas que ni la tesis de ingeniería ni el paper científico están diseñados para responder: ¿por qué este dataset y no otro? ¿Por qué este modelo y no los alternativos? ¿Qué consecuencias tiene cada tipo de error en el contexto real? ¿Qué no puede hacer este modelo que podría esperarse que hiciera?
¿Estás atascado en la escritura de tu proyecto o tesis?
Si tienes el modelo listo pero no sabes cómo estructurar el documento, o si ya tienes un borrador pero no estás seguro de si cumple con lo que el comité espera, puedo revisarlo y darte retroalimentación específica sobre qué fortalecer.
Termina ya tu proyecto
Ya tomaste cursos… pero no sabes cómo aplicarlo
El 92% de los profesionales de datos desbloquea sus proyectos al ver ejemplos completos resueltos.
Sin registro · Acceso inmediato
La estructura recomendada para un proyecto aplicado de ML
Sección 1: Planteamiento del problema y objetivo
Esta sección responde tres preguntas: cuál es el problema real, por qué ML es la herramienta correcta para este problema específico, y qué decisión o acción habilitan los resultados. El error más frecuente es empezar por el modelo — "usé Random Forest para predecir X" — en lugar del problema: "el negocio necesita identificar qué clientes tienen alta probabilidad de abandono antes de que ocurra, para intervenir con recursos limitados".
La sección de planteamiento es la que más se reescribe porque al inicio del proyecto el problema generalmente no está completamente claro. En proyectos con stakeholders reales, es habitual que la primera versión de esta sección cambie sustancialmente después de las primeras reuniones de alineación. Documentar esa evolución — cómo se redefinió el problema al entender mejor los datos — es también parte del trabajo.
Sección 2: Datos — origen, preprocesamiento y decisiones tomadas
Esta es la sección más subestimada y la que más daño puede hacer si está mal. Lo que debe documentarse: fuente de los datos y sus limitaciones, proceso de limpieza con las decisiones no obvias justificadas, qué features se construyeron y por qué, y cómo se hizo el split entre entrenamiento, validación y test.
El error que destruye la credibilidad más rápido es no documentar el proceso de split o mencionar validación cruzada sin justificarla. Si el comité pregunta "¿cómo garantizas que no hay data leakage?" y la respuesta es vaga, el trabajo pierde credibilidad independientemente de qué tan buenas sean las métricas.
Un detalle que marca diferencia: documentar las versiones exactas de las librerías usadas. Un modelo entrenado con scikit-learn 1.2 puede no reproducirse en un entorno con scikit-learn 1.4. Ese es el tipo de error que aparece meses después del deployment y que nadie puede rastrear si no está documentado.
Sección 3: Metodología — el modelo seleccionado y por qué
No basta con decir "usé Random Forest". Hay que justificar por qué Random Forest sobre las alternativas razonables para este problema. Eso implica nombrar al menos dos o tres alternativas consideradas y explicar brevemente por qué se descartaron: mayor complejidad sin mejora justificada, requisito de interpretabilidad que el modelo no cumple, o simplemente que el baseline más simple funcionó bien.
Esta justificación no necesita ser exhaustiva — no es una revisión de literatura. Necesita mostrar que la elección fue reflexiva, no arbitraria. Un comité académico que pregunta "¿por qué no usaste una red neuronal?" espera poder escuchar una razón, no un silencio.
Sección 4: Resultados y análisis
Esta sección tiene dos partes que con frecuencia se confunden: el reporte de métricas y el análisis de qué significan. El reporte sin análisis es una tabla. El análisis sin reporte es especulación. Los dos juntos son el resultado.
Lo que es obligatorio: comparación con un baseline, métricas con varianza (no solo el promedio de cross-validation), y al menos un análisis de los errores del modelo — no solo cuántos acierta sino dónde falla y qué implica eso para el uso real.
Lo que con frecuencia se omite y que añade valor real: el análisis de subgrupos. Un modelo puede tener excelente F1 global y ser sistemáticamente peor en el segmento más crítico del problema. Eso no aparece en el número global — solo aparece cuando lo buscas explícitamente.
Sección 5: Limitaciones y trabajo futuro
Las limitaciones bien documentadas fortalecen el trabajo, no lo debilitan. Un proyecto que admite honestamente que "el modelo tiene dificultades con datos de periodos de alta volatilidad porque no tuvo ejemplos de ese escenario en el entrenamiento" demuestra comprensión del problema. Un proyecto que presenta el modelo como si no tuviera limitaciones levanta sospechas.
Los tres tipos de limitaciones que deben aparecer siempre: de datos (qué sesgos o gaps existen en el dataset), de modelo (qué tipos de error comete sistemáticamente y por qué), y de generalización (en qué contextos o poblaciones el modelo podría no funcionar igual). El trabajo futuro debe fluir directamente de estas limitaciones, no ser una lista genérica de mejoras posibles.
Cómo preparar la defensa oral
Qué preguntan los comités académicos
Los comités académicos tienen preguntas recurrentes que conviene preparar con anticipación. La más frecuente: "¿y si hubieras tenido más datos?" No hay una respuesta única — la respuesta correcta depende de por qué el proyecto tiene los datos que tiene y qué limitación específica mejoraría con más datos. Pero quien no la ha pensado antes de entrar a la sala suele dar una respuesta vaga que daña la evaluación.
Otras preguntas que aparecen consistentemente: por qué se eligió esa métrica y no otra, cómo garantizas que no hay data leakage, qué pasaría si el modelo se usa en un contexto ligeramente diferente al del entrenamiento, y si los resultados son estadísticamente significativos o podrían ser ruido. Tener respuestas preparadas para estas cuatro no garantiza una defensa perfecta, pero cubre la mayoría de los vectores de ataque de un comité promedio.
Cómo responder cuando no sabes la respuesta: decirlo directamente y proponer cómo lo averiguarías. "No lo sé con certeza, pero lo evaluaría haciendo X" demuestra madurez metodológica. Intentar improvisar una respuesta técnica incorrecta en una defensa oral es el error más costoso que se puede cometer.
Qué preguntan los equipos técnicos en empresa
La diferencia clave con la defensa académica es el foco: los equipos técnicos en empresa evalúan utilidad operativa, no rigor metodológico. Las preguntas más frecuentes en entrevistas técnicas sobre proyectos propios: qué problema de negocio resuelve el modelo, qué pasaría si los datos de entrada llegaran en un formato diferente al esperado, y cómo sabría el equipo de operaciones que el modelo está fallando.
Estas tres preguntas no son técnicas en el sentido algorítmico — son preguntas de sistema. Quien las puede responder con fluidez demuestra que piensa el proyecto como un producto completo, no como un ejercicio de notebook.
Plantilla de estructura para proyecto o tesis de ML aplicado
La estructura que cubre todos los requisitos descritos en este artículo, adaptable a proyectos académicos y empresariales:
- 1. Planteamiento: problema real · por qué ML · qué decisión habilita el resultado
- 2. Datos: fuente · proceso de limpieza · decisiones de features · split documentado · versiones de librerías
- 3. Metodología: modelo elegido · alternativas descartadas y por qué · proceso de entrenamiento
- 4. Resultados: comparación con baseline · métricas con varianza · análisis de errores · análisis de subgrupos si aplica
- 5. Limitaciones: de datos · de modelo · de generalización · trabajo futuro derivado de limitaciones reales
Si necesitas la plantilla en formato editable para tu proyecto o tesis específico, puedo enviártela directamente: contacto.
Preguntas frecuentes sobre escritura y defensa de proyectos de ML
¿Cuántas páginas debe tener una tesis de ML de maestría?
No hay un estándar universal. Un proyecto aplicado bien estructurado puede ser sólido en 60-80 páginas. Lo que importa no es la extensión sino que cada sección justifique su presencia. Una tesis larga con secciones vacías de contenido es peor que una corta con cada sección trabajada.
¿Necesito incluir el código completo en la tesis?
No. El código completo va en un repositorio de GitHub enlazado desde la tesis. En el documento escrito se incluyen fragmentos solo cuando ilustran una decisión técnica específica. Lo que sí debe estar en la tesis: versiones de librerías y suficiente detalle para que el experimento sea reproducible.
¿Puedo defender un proyecto con resultados mediocres?
Sí. Lo que se evalúa es que el proceso metodológico sea riguroso y que el autor entienda por qué obtuvo los resultados que obtuvo. Un proyecto con resultados mediocres bien analizados suele evaluarse mejor que uno con buenos resultados sin capacidad de defenderlos.
¿Qué diferencia hay entre un proyecto de tesis y un proyecto de portafolio?
La audiencia y el propósito. Una tesis evalúa rigor metodológico. Un proyecto de portafolio comunica capacidad de resolver problemas reales ante reclutadores. El mismo trabajo puede adaptarse a ambos formatos, pero requiere reescritura significativa de cómo se presenta el problema y los resultados.
Siguiente paso en el framework
Una vez que el proyecto está escrito y defendido, el paso siguiente es convertirlo en un activo de carrera:
O regresa al paso anterior: Cómo interpretar y explicar los resultados de tu modelo de ML.
Si tienes un proyecto terminado o en progreso y necesitas ayuda para estructurarlo, revisarlo antes de la defensa, o adaptarlo para una entrevista técnica, puedo trabajarlo contigo directamente.
Termina ya tu proyecto
Ya tomaste cursos… pero no sabes cómo aplicarlo
El 92% de los profesionales de datos desbloquea sus proyectos al ver ejemplos completos resueltos.
Sin registro · Acceso inmediato