En el episodio de hoy hablamos de las mejores prácticas para científicos de datos que te ayudarán a evitar errores comunes y a optimizar tu flujo de trabajo 👩💻
Como científicos de datos, todos hemos estado en ese momento en el que un modelo parece listo para cambiar el mundo...
...y de repente un error en los datos nos devuelva a la realidad.
La ciencia de datos es, en esencia, una aventura de prueba y error, con un toque de drama (y a veces, caos).
Hoy, vamos a repasar algunas reglas que, aunque no te convertirán automáticamente en un ninja de los datos, sí te ayudarán a ser más eficiente, ordenado y, sobre todo, a evitar sorpresas indeseadas.
Uno de los primeros espacios que un científico de datos usa para sus experimentos es un notebook o cuaderno en el navegador, y en ciencia de datos, el favorito es Jupyter Notebook.
Si quieres profundizar en su funcionamiento y utilidad, te recomiendo escuchar el episodio 67, donde hablamos de estos cuadernos y cómo se convierten en aliados para realizar pruebas y desarrollar modelos.
El primer consejo para sobrevivir en el mundo de los datos es bastante simple:
Mantén todo en orden.
Este pequeño hábito hará la vida mucho más fácil, especialmente si estás trabajando en equipo o si algún día necesitas revisar tu trabajo.
¿Cómo lograrlo?
Una buena práctica es utilizar plantillas para organizar los proyectos de datos.
Una opción interesante es la plantilla Cookiecutter de DrivenData Labs.
├── LICENSE <- Licencia de código abierto, si se ha elegido una
├── Makefile <- Makefile con comandos útiles como `make data` o `make train`
├── README.md <- README de nivel superior para desarrolladores que usen este proyecto.
├── data
│ ├── external <- Datos provenientes de fuentes de terceros.
│ ├── interim <- Datos intermedios que han sido transformados.
│ ├── processed <- Conjuntos de datos finales y canónicos para modelado.
│ └── raw <- Volcado de datos original e inmutable.
│
├── docs <- Proyecto mkdocs por defecto; ver www.mkdocs.org para detalles
│
├── models <- Modelos entrenados y serializados, predicciones o resúmenes de modelos
│
├── notebooks <- Notebooks de Jupyter. Convención de nombres: un número (para orden),
│ las iniciales del creador y una breve descripción con `-`, e.j.
│ `1.0-jqp-exploracion-datos-inicial`.
│
├── pyproject.toml <- Archivo de configuración del proyecto con metadatos del paquete para
│ {{ cookiecutter.module_name }} y configuración para herramientas como black
│
├── references <- Diccionarios de datos, manuales y otros materiales explicativos.
│
├── reports <- Análisis generados como HTML, PDF, LaTeX, etc.
│ └── figures <- Gráficos y figuras generados para ser utilizados en reportes
│
├── requirements.txt <- Archivo de requerimientos para reproducir el entorno de análisis, por ej.
│ generado con `pip freeze > requirements.txt`
│
├── setup.cfg <- Archivo de configuración para flake8
│
└── {{ cookiecutter.module_name }} <- Código fuente para usar en este proyecto.
│
├── __init__.py <- Convierte {{ cookiecutter.module_name }} en un módulo de Python
│
├── config.py <- Almacena variables útiles y configuraciones
│
├── dataset.py <- Scripts para descargar o generar datos
│
├── features.py <- Código para crear características para modelado
│
├── modeling
│ ├── __init__.py
│ ├── predict.py <- Código para ejecutar inferencia de modelos entrenados
│ └── train.py <- Código para entrenar modelos
│
└── plots.py <- Código para crear visualizaciones
Esta estructura permite separar tus datos crudos, los que no has tocado, de los datos procesados, que son los que has transformado.
También te permite organizar los notebooks, el código y demás elementos del proyecto en carpetas separadas.
Al estilo Marie Kondo, un proyecto ordenado es un proyecto más claro y fácil de compartir.
La ciencia de datos implica transformar los datos muchas veces.
Desde limpiar, procesar, hasta generar datasets que sean útiles para entrenar modelos de Machine Learning, el proceso es complejo y propenso a errores.
Mantener los datos originales inmutables es fundamental.
Los datos en crudo no se tocan; cualquier transformación se realiza sobre copias, y siempre debes saber cómo y dónde se han transformado los datos.
En términos técnicos, esto es mantener el linaje de los datos.
Es como trazar un mapa que te dice de dónde vienen los datos, qué cambios han sufrido y cómo han llegado a su forma actual.
Esto te permitirá volver atrás en caso de error, evitando el riesgo de trabajar con datos corruptos o duplicados, que pueden llevar a conclusiones erróneas, como en la historia de la empresa de energía que te cuento en el episodio de hoy, en la que el mal manejo de los datos les llevó a creer que tenían una mina de crudo más grande de lo que realmente era.
¡Drama asegurado!
Para más detalles sobre buenas prácticas en el análisis de datos, también te recomiendo escuchar el episodio 70, donde exploramos métodos y consejos que pueden marcar la diferencia.
Si nadie te ha dicho esto antes, déjame ser la primera:
Aprender Git es esencial para cualquier científico de datos.
En ciencia de datos, estamos constantemente probando cosas, haciendo cambios en el código, en los notebooks, en los scripts de preprocesamiento… y sin control de versiones, es fácil perderse o, peor aún, estropear algo que ya funcionaba.
Git no solo te permite mantener un historial de cambios y retroceder si algo sale mal, sino que también facilita la colaboración en proyectos.
Puedes trabajar en tu propia rama, mientras que otros colaboradores trabajan en la suya, y luego fusionar todo de manera organizada.
Sin embargo, hay un matiz: en ciencia de datos, Git se debe usar principalmente para el código o para datasets que no cambian mucho y son relativamente pequeños.
Para el versionado de grandes volúmenes de datos, existen herramientas específicas como DVC (Data Version Control).
Además, si ya has avanzado en MLOps (si no sabes lo que es, escucha este episodio del podcast o puedes echarle un vistazo a este resumen del pedazo de libro de Chip Huyen), puedes automatizar el proceso de integración continua: los cambios en el código se prueban automáticamente, y si algo falla, se detecta al instante.
Espero que te guste el episodio.
Si es así, no olvides dejar un «Me gusta» y algún comentario al episodio en Ivoox o una valoración de 5 estrellas del podcast en Apple podcasts, en Spotify, en Youtube o donde quiera que escuches el podcast.
Recuerda que si tienes cualquier duda o pregunta puedes contactar conmigo a través del formulario de contacto o podemos seguir la conversación en Twitter.
Muchas gracias por estar ahí y te espero en el próximo episodio de Un Podcast Ninja sobre Big Data.