Un portfolio de machine learning que consigue entrevistas no se mide por la cantidad de modelos que entrenaste, sino por cuántas decisiones podés justificar. Los cinco proyectos que siguen cubren el rango de competencias que un equipo de datos evalúa —limpieza, modelado, evaluación, puesta en producción y comunicación— y se pueden construir con datasets públicos y herramientas gratuitas.

El error más frecuente en portfolios de machine learning es el notebook heredado de un curso: un dataset limpio, un modelo entrenado, una métrica alta y ningún contexto. Ese archivo no demuestra criterio. Lo que un reclutador técnico busca es evidencia de que sabés qué hacer cuando los datos están sucios, la métrica engaña o el modelo no sirve para el problema.

Qué evalúa realmente quien revisa tu portfolio

Antes de los proyectos, conviene entender la grilla mental de quien revisa. En general se mira, en este orden:

• Definición del problema: ¿está claro qué se predice y por qué eso importa?

• Manejo de datos reales: ¿hubo nulos, duplicados, desbalance, fugas de información? ¿cómo los resolviste?

• Elección de métrica: ¿la métrica corresponde al problema o usaste accuracy por defecto?

• Baseline: ¿comparaste contra algo simple antes de complicar?

• Comunicación: ¿alguien sin contexto entiende el resultado en dos minutos?

Un proyecto que responde bien a estos cinco puntos vale más que tres proyectos que solo muestran código. Vale la pena leer las Rules of Machine Learning que publica Google: la primera recomendación del documento es empezar por una solución simple y una infraestructura confiable antes de sofisticar el modelo, y ese criterio es exactamente lo que un revisor busca en un portfolio.

1. Predicción con datos desordenados de un dominio real

Qué construir: un modelo de predicción sobre un dataset que no venga preprocesado. Precios de alquiler, demanda de un servicio público, retrasos de transporte, consumo energético. La clave es que los datos tengan problemas reales.

Herramientas: Python, pandas, scikit-learn, matplotlib.

Qué documentar: el estado inicial de los datos con evidencia (porcentaje de nulos por columna, distribuciones raras, outliers), cada decisión de limpieza y su justificación, y el impacto de esas decisiones en el resultado final.

Por qué funciona: es el proyecto que más se parece al trabajo real. La limpieza y la exploración ocupan la mayor parte del tiempo de un equipo de datos, y casi ningún portfolio junior lo muestra.

2. Clasificación con clases desbalanceadas

Qué construir: un clasificador sobre un problema donde la clase de interés es minoritaria: detección de fraude, predicción de abandono de clientes, diagnóstico de fallas.

Herramientas: scikit-learn, imbalanced-learn, y visualización de curvas de precisión-recall.

Qué documentar: por qué accuracy no sirve acá, qué métrica elegiste (precision, recall, F1, AUC-PR) y qué costo tiene cada tipo de error en el negocio. Este último punto es el que separa un perfil técnico de un perfil que además entiende el problema.

Error a evitar: aplicar sobremuestreo antes de dividir el dataset. Es la fuga de información más común y un revisor experimentado la detecta de inmediato. La documentación de scikit-learn sobre errores frecuentes y buenas prácticas desarrolla este punto con ejemplos: cualquier transformación ajustada sobre el conjunto completo antes de la partición contamina la evaluación.

3. Un modelo servido como API

Qué construir: tomá cualquiera de tus modelos anteriores y exponelo como servicio. Un endpoint que reciba datos y devuelva una predicción.

Herramientas: FastAPI o Flask, Docker, y algún servicio de despliegue gratuito.

Qué documentar: cómo serializaste el modelo, cómo manejás entradas inválidas, cuánto tarda una predicción y cómo versionás el modelo cuando lo reentrenás.

Por qué funciona: es el proyecto que más diferencia a un candidato. La mayoría de los portfolios termina en el notebook. Mostrar que entendés qué pasa después —que un modelo tiene que correr en algún lado, recibir tráfico y fallar con gracia— señala madurez técnica. Si querés profundizar en cómo organizar todo esto para que se vea bien, sirve la guía sobre tu perfil de GitHub como portfolio de datos.

4. Procesamiento de lenguaje natural sobre texto propio

Qué construir: un proyecto de NLP sobre un corpus que hayas recolectado vos: reseñas de productos, comentarios públicos, artículos de un medio, transcripciones. Clasificación de sentimiento, agrupamiento temático o extracción de entidades.

Herramientas: spaCy, transformers de Hugging Face, o un modelo de lenguaje vía API si el enfoque es aplicado.

Qué documentar: cómo obtuviste el corpus (y con qué criterio ético), qué preprocesamiento aplicaste, y una comparación entre un enfoque clásico y uno basado en modelos preentrenados. Esa comparación demuestra que elegís herramientas, no que seguís modas.

5. Un análisis end-to-end con conclusión de negocio

Qué construir: un proyecto donde el modelo sea un medio y no el fin. Pregunta de negocio, datos, modelo, y una recomendación accionable respaldada por los resultados.

Herramientas: las que ya usaste, más una capa de visualización clara. Power BI, Tableau o incluso un informe bien escrito.

Qué documentar: la pregunta original, el hallazgo, la recomendación y —esto es clave— las limitaciones. Un proyecto que dice qué no puede concluirse con esos datos genera más confianza que uno que afirma de más.

Por qué funciona: los equipos de datos rechazan candidatos técnicamente sólidos que no logran explicar por qué su trabajo importa. Este proyecto es la prueba de que podés.

Cómo presentar los cinco proyectos

La presentación pesa tanto como el contenido. Tres reglas que aplican a todos:

1. README como portada. Problema, datos, enfoque, resultado y limitaciones en menos de 400 palabras, con una imagen del resultado arriba.

2. Notebooks limpios. Sin celdas de prueba, sin salidas de error, con narrativa entre bloques de código.

3. Reproducibilidad. Un archivo de dependencias y una instrucción de cómo correrlo. Si alguien no puede ejecutarlo, no cuenta.

Y una recomendación de volumen: tres proyectos excelentes superan a ocho medianos. El portfolio se juzga por su pieza más débil, no por la mejor.

Con qué formarte para construirlos

Cada proyecto exige un conjunto de habilidades distinto. Estos recorridos de Coderhouse cubren los distintos niveles de este camino:

• Curso de Python: punto de partida si todavía no programás con soltura. Es la base de los cinco proyectos.

• Curso de Machine Learning para la Ciencia de Datos: cubre modelado, evaluación y validación, que es el núcleo de los proyectos 1, 2 y 4.

• Carrera de Data Scientist: recorrido completo con proyecto final, ideal si querés construir el portfolio dentro de una estructura guiada.

Si venís del análisis de datos y querés sumar modelado, el artículo sobre machine learning para analistas de datos ordena qué habilidades agregar primero.

Preguntas frecuentes

¿Cuántos proyectos necesito para postular a un puesto junior?

Tres bien documentados alcanzan, siempre que cubran competencias distintas: uno de limpieza y análisis, uno de modelado con evaluación seria y uno que llegue a producción o a una conclusión de negocio. Sumar proyectos parecidos entre sí no agrega información nueva sobre lo que sabés hacer.

¿Sirven los proyectos de competencias de Kaggle?

Sirven para practicar modelado, pero solos no alcanzan: los datos vienen limpios y la métrica viene definida, que son justo las dos decisiones que un empleador quiere ver que tomás. Usalos como complemento, no como el centro del portfolio.

¿Puedo usar modelos preentrenados o tengo que entrenar desde cero?

Podés y conviene usarlos. En la práctica profesional casi nadie entrena desde cero cuando existe un modelo preentrenado adecuado. Lo que sí tenés que poder explicar es por qué elegiste ese modelo, qué ajustaste y cómo evaluaste si mejoró frente a una alternativa más simple.

¿Qué pasa si mi modelo tiene un rendimiento bajo?

No es un problema si lo explicás. Un proyecto que documenta por qué el problema es difícil, qué probaste y qué haría falta para mejorarlo demuestra criterio. Un proyecto con una métrica sospechosamente alta, en cambio, invita a buscar la fuga de datos, y suele encontrarse.

¿Conviene subir el portfolio a GitHub o armar un sitio propio?

GitHub es suficiente y es donde el revisor técnico va a mirar primero. Un sitio propio suma cuando el público incluye perfiles no técnicos, porque permite contar el caso sin código. Si hacés las dos cosas, que el sitio enlace al repositorio y viceversa.