datacubeR

6 meses usando un Corne

2023-08-01T00:00:00+00:00

Soy un fanático de la productividad. Siento que como Científico de Datos tenemos que ser sumamente eficientes, y utilizar todos los recursos posibles que nos den comodidad y rápidez. Sí, también es verdad que soy un hacker frustrado (básicamente porque siento que soy muy poco informático), pero por lo mismo, hace unos años es que estoy invirtiendo mucho tiempo en ser mejor computín. Y entre aprender mucho más de todo lo que no sé de informática, también dedico mucho tiempo a escribir rápido en el teclado. De hecho practico regularmente en plataformas como MonkeyType y estoy rondando los 80-100 wpm (palabras por minutos en inglés: words per minute). El tema es que un poco inspirado por Hola Mundo, pero por sobre todo por chris@machine y ThePrimeagen es que siento que uno tiene que trabajar primordialmente con el teclado. Esto por dos cosas:

Cambié mi mouse vertical, porque en verdad me estaba dando tendinitis por un movimiento muy antinatural que estaba haciendo al bajar. Ahora uso uno de trackball, pero igual uno pierde tiempo moviendo la mano al mouse, aunque no quiera notarlo.
Cambié mi teclado y aprendí a hacer touch typing para escribir más rápido, sin mirar el teclado y con todos los dedos. Realmente he notado una mejora muy notoria en esto y si bien es un cambio a mediano-largo plazo, el forzarme a escribir sin mirar y con la técnica correcta me ha dado muchos beneficios.
Un tercer punto y que es algo completamente nuevo, es que decidí cambiarme a Neovim. Esto porque creo que es la única manera de dejar de utilizar el mouse, y poder depender sólo del teclado. Lamentablemente este cambio ha sido el más costoso, en términos de curva de aprendizaje y de configurar el maldito editor. No creo que sea algo para todos, definitivamente no lo es. Pero me siento orgulloso de haberme atrevido y demasiado satisfecho con mi entorno de programación.

Más acerca de cómo ha sido el cambio a Neovim pronto!!

Ahí es cuando entra el Corne. No quería el Corne la verdad. Porque se está volviendo too mainstream y como que piensan que es el único teclado que hay. Yo en verdad quería el Sofle (pero sólo por ser rebelde), porque ví a este tipo decir que el Corne era demasiado difícil de aprender porque tenía muy pocas teclas (Spoiler, cuesta unas dos semanas, pero no es tan difícil como dice).

Pero cuando ví que Zone Keyboards tenía esta versión con carcasa de madera, la verdad es que no me pude resistir. Aunque yo lo pillé en oferta a un precio muchísimo menor que el que indican ahora.

Cuando compré el teclado tenía la intención trabajar un poco con VIM, pero sin VIM. Porque, como he dicho varias veces, no había encontrado una buena solución para el REPL en Python, y porque realmente no me gustaba tener que presionar la i cada vez que quiero comenzar a escribir. Hoy la historia es distinta y todas mis molestias eran sólo un tema de costumbre.

Es verdad, se pueden usar los key bindings de VIM en VSCode, pero ¿qué pasa con el resto?

Yo tenía anteriormente el GK68XS que es un buen teclado, me gustaba harto, pero con varias limitaciones que probablemente a nadie le afectan excepto a mí. Primero lo bueno:

Compacto, 65% con teclas dedicadas a los números. Lejos lo que más me ha costado acostumbrarme en el Corne.
Bluetooth.
Switches Cherry MX Rojos (de excelente calidad).
Programable.
Macros.
Tiene triple barra espaciadora que permitía usar teclas modificadores con los pulgares.

Ahora los contra:

Cherry MX Rojos. Son demasiado sensibles, probablemente los Café serían mejor, con mis switches actuales me equivocó infinitamente menos debido a que requieren más intencionalidad al tipear. Escribo menos sin querer queriendo.
Staggered. Si se fijan tiene las columnas como en pendiente negativa, lo cuál si haces touch typing, implicará una rotación de la muñeca izquierda horrible. ¡Y duele!
Flechas a la derecha, lo cual implica un retraso horrible cada vez que quieres usarlas. Además de perder la posición de home row (Tener tus dedos descansando en A, S, D, F y J, K, L, ;).
FN no modificable. Fijo y a la derecha, lo cuál no me gustaba.
Sólo una función por tecla.

No es terrible, de verdad que no. Ese teclado ahora es de mi hermano y está feliz usándolo.

¿Entonces qué tiene de distinto cualquier teclado mecánico basado en QMK (ojo, cualquiera sirve, no sólo el Corne)?

Yo creo que es la programabilidad (ni siquiera sé si eso es una palabra). Pero me refiero a que realmente se puede definir todo. Ahora, ¿es perfecto? No, no lo es. Y si uno quiere realmente el teclado perfecto hay que invertir mucho más dinero (principalmente en hardware, los pro-micro que son los controladores que tengo no tienen tanta capacidad, pero cumplen). Al menos a mí me gusta.

Lo bueno

Que es separado, lo cual permite que la espalda se relaje mucho más. Esto es verdad. Estar con los brazos hacia adentro genera tensión en los trapecios. Tener los brazos a la altura del hombro realmente ayuda.
Columnar: Las teclas están en columnas, por ejemplo, la a está inmediatamente abajo de la q y no abajo a la derecha. Ya tengo absolutamente cero dolor de muñecas, incluso usando una distribución tan nefasta como QWERTY. Y esto no me tomó tanto tiempo en acostumbrarme como decían.
Cada tecla puede tener demasiadas funcionalidades al mismo tiempo (lo cual es casi agobiante).
Tiene pantallitas leds con indicadores y buenas luces RGB de fondo (aunque yo las tengo apagadas la mayor parte del tiempo).
Las teclas de Pulgar son lo máximo. Y realmente permiten que uno no tenga que abandonar la posición de home row nunca. Además tienes 6 por lo tanto es harta funcionalidad extra.

Lo malo

Es cableado. Hay versiones inalámbricas, pero son DIY y no sé soldar.
Tiene una pequeña latencia. Probablemente imperceptible para muchos, pero yo la siento cuando estamos cerca de los 80-90 wpm (Update: Es posible que esto sea sólo una percepción mía. He probado con el terminal Kitty que es mucho más fluido y una mejor calidad de cable y ya casi no siento desfase).
Los switches Gateron café son increíbles, pero un poco toscos. Siento que hay que lubricarlos, aunque me da una lata inmensa hacerlo. Pero a pesar de so, realmente me permite escribir equivocándome muy poco.
El sonido no es tan agradable como pensé que sería. No me molesta, pero me gustaba mucho más el de mi teclado anterior. He visto algunos hacks, pero me da lata desarmar el teclado para ponerle goma eva adentro.
Algunas funcionalidades súper cool lo hacen un teclado lento. Afortunadamente yo encontré mi configuración ideal sin tener que usar cosas como los combos, o los tap dance, que realmente traban el teclado (de manera más perceptible).
Me es casi imposible teclear en un teclado Staggered nuevamente. No porque se me haya olvidado, sino porque no le achunto a las teclas. Cuando tengo que usar un teclado que no es el mío, tengo que recurrir al clásico escribir sólo con los índices y mirando, pero puede que sea yo el ñurdo.

Los combos se utilizan normalmente para hacer lo que se llama los Home Row Modifiers. Por ejemplo si presionas la a es una a, pero si la mantienes es un Alt. Era excelente la idea, pero presionar significa que el teclado literalmente tiene que esperar 200ms para detectar si es un tap o un hold y escribiendo rápido eso se nota.

Lo mismo los tap dance. Esto es cuando presionas una tecla hace algo, pero si lo presionas dos rápido hace otra cosa. Como yo uso principalmente una distribución en inglés, quería que un doble tap de la n sea una ñ. Pero nuevamente el delay para detectar si es un tap o un doble tap.

Personalización

Bueno una de las gracias es que era completamente personalizado. Y la verdad es que yo elegí desde el color de los keycaps, hasta los simbolitos:

En el Mayus, está básicamente mi logo, que cree hace ya varios años increíblemente con una librería en R que se llamaba algo como Hex, o algo así.
Ctrl y Alt son los símbolos de Mac, que encuentro harto más bonitos que simplemente colocarle el nombre.
Abajo tengo el logo de Zone Keyboards, un poco para agradecer y hacer propaganda al teclado, que está bonito. Y tengo el logo de PopOS, mi Sistema Operativo.
A la derecha tengo la patita de la Kira, mi perrita y las otras son teclas estándar.
A la derecha decidí colocar las flechas estilo VIM. Esto porque llevo mucho tiempo intentando aprendérmelas, y creo que por fín puedo decir que me acostumbré, en especial la flecha izquierda es como difícil acordarse.

Bueno, a lo que nos interesa, ¿cómo lo tengo configurado?. Esto fue realmente una lata y estuve como 3+ semanas moviéndolo todo el día, todos los días. Pero realmente siento que mi distribución está como quiero. Tengo en total 4 capas las cuales voy a describir a continuación.

Capa Principal

La capa principal la verdad es que es muy estándar. Es una distribución QWERTY con varias moficicaciones. Por un tema de orden me referiré a esta capa como referencia para que se entienda la posición de otras funcionalidades. Además me referiré a las teclas de Pulgar como LT(idx) y RT(idx) donde idx=1,2,3 siendo el 1 la tecla más interior y 3 la más exterior de cada mano (L: Izquierda, R: Derecha).

La filosofía detrás es poder tener todos mis Mods (Ctrl, Shift y Alt) en mi mano izquierda, cosa de combinar atajos con el uso del Mouse en caso de ser necesario. Además la posición debe ser lo más ergonómica posible.

La tecla ' " sirve como mi ´. Esto porque utilizo una distribución llamada US International Keyboard with dead keys. Normalmente si yo quiero el ' necesito presionar la tecla dos veces, lo cual encuentro lento, por lo que lo remapee como RAlt + ' lo que entrega directamente el ´.
No uso la tecla / ? y en vez de eso la cambio por - _, ya que el guión bajo se utiliza muchísimo más al momento de programar y quiero tenerla muy a la mano.
Una cosa que a mucho les parece extraño es que uso el espacio en RT(2) y no en RT(1). No sé, lo encuentro una posición mucho más natural y que mantiene mi mano más relajada. Se lo copié a un chico indio de Youtube que no recuerdo su nombre como para darle el crédito.
RT(3) tiene doble funcionalidad. Un tap es Enter y un hold es la tecla Super, GUI o Windows. En el caso de Pop esto permite lanzar el Launcher. Como dije, esto es una funcionalidad que da cierto Lag (debo esperar 1 segundo para activarlo), pero dado que el Hold lo utilizo en contadas ocasiones no me afecta como sí lo haría en una letra o un símbolo.
La tecla Esc la hago como un doble Tap sobre el CAPS LOCK.
Todos mis modificadores son One Shot Keys. Es decir si hago tap deja el modificador presionado hasta la siguiente tecla. Por lo tanto, si quiero hacer Copy hago Ctrl C secuencial, y no Ctrl + C (dejándo ambos presionados), lo cual es particularmente útil para escribir mayúsculas rápidas y no escribir dos mayúsculas por error. Lo bueno de estas teclas es que si por costumbre las dejo en Hold igual funciona. Tener como One Shots me permite usar acordes por ejemplo Ctrl K A es un acorde de Jupyter Notebook que me permite seleccionar todo lo que esté entre paréntesis. O Ctrl R K lo uso para reiniciar kernel y Ctrl R A para correr todo (Run All). Súper útil.
Una cosa bien chora que tengo configurado es que doble Shift es Caps Word. Esta funcionalidad permite colocar en mayúsculas y transformar - en _ hasta que presione un espacio. Lo cual permite por ejemplo crear constantes sin tener que activar y desactivar el CAPS LOCK.
Además todas mis capas OSL son One Shot Layers. Si la presiono una vez cambia a la capa indicada sólo para la siguiente tecla, si la dejo presionada quedo en esa capa hasta que suelte el OSL. Por ejemplo si quiero eliminar sólo un caracter hago OSL(0) Del y si quiero borrar tres hago OSL(0) + (Del Del Del). Ahora si quiero quedarme en esa capa hago un doble tap a OSL(0) o cualquier otra capa y me quedo ahí hasta desactivarla (con la misma tecla que la activé). Esto lo uso normalmente con la capa de navegación o la numérica cuando tengo que sólo recorrer un archivo o cuando tengo que escribir sólo operaciones aritméticas respectivamente (obviamente cuando no estoy en Neovim).

Otra ventaja de usar One Shot Layers es que me permite combinaciones muy rápidas sin equivocarme, como se garantiza que la siguiente tecla será modificado por el modificador o la capa, cualquier desincronización en mis dedos se perdona.

Quizás la funcionalidad más potente del teclado es la Leader Key. la cual se ubica donde en RT(1) de la capa 2. La Leader Key me permite generar comandos con ciertas combinaciones de teclas de hasta 5 teclas. Esta es la parte que quizás más modifico del teclado, ya que a medida que voy encontrando cosas interesantes las agrego. Para usar las combinaciones debo presionar RT(1) 2 veces y luego puedo hacer la combinación que me interesa.

t me abre/cierra el terminal de VSCode.
p me permite abrir el explorador de VSCode y navegarlo con flechas.
py me permite abrir un ipython y ejecutar inmediatemente %load_ext autoreload y %autoreload 2 para inmediatemente reconocer nuevos módulos.
pd me escribe import pandas as pd.
np me escribe import numpy as np.
plt me escribe import matplotlib.pyplot as plt.
dd Selecciona todo y copia.

Y tengo algunas combinaciones secretas con claves y cosas que me da lata recordar, pero que no compartiré acá 🤗.

Capa de Navegación (Capa 0)

Esta es la capa que utilizo para moverme. La activo con OSL(0). Está inspirada en las teclas de navegación de VIM y algunas cosillas extras. Esta es probablemente la capa que más utilizo. Incluso más que las letras (Esto porque uso Vimium para navegar en Chrome, es decir, puedo usar atajos de VIM para moverme en el navegador).

Esta capa la activo con la tecla que normalmente uno tiene el CAPS LOCK. Un tap me permite que la siguiente tecla pertenezca a esta capa, por ejemplo OSL(0) L, es equivalente a la flecha a la derecha, para salir de paréntesis, comillas, etc. (En VSCode puedo usar directamente Tab gracias a la extensión TabOut, pero en otros ambientes no puedo). Si hago doble tap bloqueo esta capa para quedarme navegando sin tener que dejar presionado OSL(0).
Donde normalmente va la y y la o tengo Home y End respectivamente. Son teclas que uso muchísimo para moverme rápido en una línea. La u y la i son el PageDown y PageUp respectivamente.
Lo que más ocupo es dejar presionado Shift más las flechas que sería equivalente al visual mode de VIM y si presiono Control y hacia los lados salto por palabras palabras, mientras que hacia arriba/abajo hago scroll. Me permite moverme sin casi necesitar el mouse. Esto lo hago sólo cuando no tengo disponible los atajos de VIM, por ejemplo, en el navegador, o en Github.
Acá la tecla - _ está mapeado a ? . Y además ' " está realmente mapeado a ' (la comilla simple).
Las teclas n y m me sirven como * y / respectivamente.
Finalmente RT(1) sirve como mi Delete.
Además en mi mano izquierda tengo controles de mis servicios multimedia: La f es para Play/Pause. La s para retroceder y la d para adelantar. Además el equivalente a la r es para subir volumen y la v para bajar volumen.
La tecla equivalente a la g la tengo mapeada a un espacio, en caso que tenga la mano derecha en el Mouse y rápidamente necesite agregar un espacio.

Capa Numérica (Capa 1)

Esta es por lejos la capa que más me ha costado usar. Acá utilizo OSL(1) como tap para colocar un sólo número, y dejo presionado en el caso de algún número de más de un caracter. Luego de mucho probar varias estrategias me quedé con una configuración en dos filas: del 1 al 5 y del 6 al 0. Al principio me costó mucho esto, pero fue la única manera de dejar de presionado LT(1) mientras usaba dedos de otra mano, que al menos a mí me alivió mucho el dolor que tenía.

La filosofía acá fue: “Si es que tengo que dejar una tecla presionada para hacer una combinación, que presione con una y genere la combinación con la otra”.

Además la tecla n me sirve como mi ñ. El botón de tildes, acá me sirve como mi comilla simple. Y acá sí utilizo la tecla al lado del . como mi ?. Si bien estas teclas están repetidas, la mayoría de las veces las uso desde esta capa.

Capa de Símbolos (Capa 2)

Esta capa está exclusivamente dedicada a todos los símbolos.

Mi tecla h corresponde a = y mi tecla j corresponde a el símbolo +. Son los únicos en mi mano derecha, porque no tenía más espacio y por alguna razón me acomoda presionar RT(1) y estas teclas.
En la parte izquierda, la fila superior son todos los símbolos asociados a números hasta el 5, excepto el @ que cambie por ". Estuve un tiempo obligado a usar un teclado en español y me gustó mucho la posición de las comillas ahí, por lo que las dejé. El resto normalmente lo tengo en otro lugar.
El Home Row izquierdo es la apertura de paréntesis (, [ &, { y \ respectivamente. Esto porque { se utiliza como desplazamiento en VIM y me acomodó mucho tenerlo directamente bajo mi índice.
En la fila inferior están sus opuestos: ], ] |, } y @.
En las teclas LT(2) y LT(1) están los símbolos de ` y ~ respectivamente.

Más simbología que eso creo que no tengo ni necesito.

Capa de Configuración

Solía tener una capa de configuración, que si ven algún tutorial todos suelen ponerla en una capa presionando LT(1) y RT(1). Yo la verdad, encontré que no me aportaba y rara vez la ocupaba. Por lo tanto, decidí dejar de agregarla, lo cual genera un teclado con menos memoria ocupada y más rapidito.
Además, como se puede ver, no tengo teclas de función. No las ocupo. Y en verdad no las he echado de menos. Eventualmente si las necesito las iré agregando.

Debo decir que en verdad llegar a esta configuración me costó bastante y está inspirada en miles de configuraciones que ví. Si bien existen configuraciones numéricas que todavía me trabo, me siento súper cómodo como está. Lo mismo con los símbolos, es algo que ya tengo sumamente integrado y que hago rápido en forma de acorde. Por ejemplo RT(1) A permite abrir paréntesis rápidamente y no es necesario que deje nada presionado

Espero que mi configuración les pueda servir de inspiración para la suya (si es que tienen) o que les anime a probar algo parecido. Lo bueno es que no hay nadie mejor que yo para escribir en mi teclado. Lo malo, nadie más puede usarlo. Pero bueno, no es mi intención que alguien más lo use.

Nos vemos a la otra.

Alfonso

Mis Extensiones para Trabajar en VSCode

2023-03-22T00:00:00+00:00

Trabajando como Científico de Datos, o de cualquier programador en general, pasas gran parte de tu día en frente de algún editor de código o un IDE. Si bien yo realmente creo que no está totalmente definido cuál es el mejor ambiente para trabajar, a mí me gusta la versatilidad que ofrece VSCode. .

En el mundo de los datos uno trabaja en varios frentes: Desde exploración o diseño de prototipos en Notebooks, hasta diseño de pipelines automatizados utilizando Scripts, y desplegando sistemas en Cloud o tecnologías asociadas como Docker. En general uno tiene que manejar muchas tecnologías en distintos entornos. Y a pesar de que me gustan las tecnologías especialistas, tener un entorno multifacético como VSCode me gusta mucho, en especial porque es un todo en uno: Python Scripts, Jupyter Notebooks, terminal además de permitir conectarme a entornos remotos como contendores de Docker o mi servidor utilizando SSH. Todo en un sólo lugar.

La intención de este artículo no es juzgar qué es mejor y donde trabajar. Yo tengo mi opinión y me gusta trabajar en VSCode. Básicamente quiero compartir y documentar para mi yo del futuro cuál es mi configuración elegida.

Lo bueno de VScode es que es completamente personalizable, pero me pasa que siempre que veo videos/artículos que abordan las mejores extensiones están enfocadas en un público más de desarrollo Web, o en otros lenguajes de programación más que en Python en el contexto de Ciencia de Datos. La idea de este artículo es mostrar extensiones conocidas y otras bien under que me han permitido aumentar la productividad (uno de mis sueños que es no depender tanto del mouse, ni tampoco de Vim/NeoVim que no me terminan de convencer) o sencillamente que tu ambiente de trabajo se vea más bonito.

Como editor de Texto en verdad creo que Vim/NeoVim es lo mejor que hay por velocidad, atajos, funcionalidades, y otras capacidades como IDE. Donde no me termina de convencer es como un entorno de ejecución en tiempo real de Python (tipo REPL). A diferencia del desarrollo de software uno necesita ir ejecutando trozos de código en memoria rápidamente y la verdad es que no he encontrado algo que me termine de gustar en VIM. El Jupyter Notebook es lo mejor (o menos malo) que he encontrado, pero tiene muchos otros problemas. Para mí la mejor solución la tenía Atom con Hydrogen, pero sabrán que Microsoft decidió darlo de baja y eliminarlo (igual tenía algunas pifias de performance, se volvía muy lento con archivos con muchas líneas de código, pero la idea de tener un Script con el output inmediatemente al lado es para mí lo mejor que hay. VSCode ofrece el Python Interactive Window pero no anda ni cerca de lo útil que era Hydrogen, de hecho funciona muy mal). Me encantaría que algo así saliera en VSCode pero al parecer es medio imposible por la forma en la que VSCode funciona.

Python

Obvio, esta es probablemente la primera extensión a instalar para poder ejecutar código en Python. No mucho que decir, permite ejecutar Python en VSCode, permite la interactive Window, que es para ejecutar código en vivo tipo REPL pero en Python Script, además de habilitar los Jupyter Notebooks (antes eran extensiones separadas pero ahora viven todo bajo la extensión de Python). Actualmente esta extensión igual instala extensiones amigas como Jupyter Cell Tags, Jupyter Keymap, etc. Pero son extensiones que trabajan behind the scenes.

La extensión además permite refactoring (aunque no funciona mucho), e incorpora Pylance como Language Server para dar sugerencias de código, y isort como una herramienta para ordenar imports. Además tiene incorporación con formatters (yo uso Black) y linter (la verdad es que odio los linters por la cantidad de suciedad que agrega a mi pantalla, pero normalmente trabajo con flake8 pero ahora estoy probando Ruff).

Una de las cosas que más me gusta es que por fín integraron la posibilidad de modificar Tags para poder usar librerías súper interesantes como Papermill.

Entiendo que aún existe gente que usa R, y la verdad es que si bien VSCode tiene una extensión para trabajar con R, creo que RStudio funciona mucho mejor. Si les interesa hablar de la pelea R vs Python, lo dejamos para otra ocasión.

Extensiones de estética

Probablemente muchos pueden pensar que no son necesarias pero de verdad hacen que nuestro ambiente de trabajo sea más ameno. Al menos el hightlighting creo que ayuda mucho a leer mejor el código y poner atención a distintas partes del código. El resto me hace más feliz!! Pero igual ayuda.

One Dark Pro

No mucho que decir acá más que es mi tema favorito (que de hecho proviene de Atom). Para mí es bien importante que el código sea muy multicolor, y que permita diferenciar cada parte del código. He probado muchos temas y este por lejos es el mejor, tiene colores predefinidos para:

Palabras Claves
Funciones
Clases
Métodos
Atributos
Strings
Números
Booleanos
Signos

Una imagen de cómo se ve código Python con casi todo lo que mencioné se puede ver acá:

Material Icon

Esta es una extensión muy sencilla que coloca íconos a las carpetas y los íconos de manera muy bonito para reconocerlos mejor. Utiliza el nombre o la extensión para asignar íconos que facilitan encontrar archivos y diferencias carpetas importantes de otras no tan importantes.

Una cosa que me gusta bastante de VSCode es que marca qué archivos no están siendo trackeados por Git, cuáles son nuevos, cuáles son partes de .gitignore, etc. Si bien no es ninguna extensión adicional lo que permite esto, Material Icon si agrega esos colores dorado, verde, o gris para denotar distintos estados de un archivo en Git.

indent-rainbow

Es una extensión muy pequeñita que permite marcar la indentación con colores para asegurarse que estén alineados. Si está incorrectamente alineado aparecerá en rojo, sino irán marcando por colores los distintos niveles.

Better Comments

Esta extensión permite destacar ciertos comentarios. En general lo he encontrado bien útil para poder tener mensajes a los que tengo que estar atento en el futuro o para que mis compañeros vean mis mensajes. Básicamente, tiene varios tipos de mensajes que se destacarán dependiendo del símbolo con el que partan:

Si bien se sugieren esos comentarios, la verdad es que uno puede usar el color para lo que uno quiera.

Rainbow CSV

Esta es otra pequeña extensión muy livianita, que permite colorear un CSV para poder tener una mejor lectura del archivo raw. Es la extensión más común, y si bien hay otras extensiones que permiten ver los CSV cómo Spreadsheets, a mí me gusta esta, porque de nuevo, me gusta el editor bien multicolor.

Autocompletado

Son extensiones que ayudan a autocompletar código o escribir código de manera más rápida y oprimiendo menos teclas.

Github Copilot

La verdad es que cada vez lo ocupo menos. Si bien es un gusto que me complete mucho código, rara vez me da la respuesta absolutamente correcta, lo que significa que tengo que terminar editando la sugerencia. Lo mejor que tiene es sugerir variables de manera correcta o librerías que necesito importar, pero normalmente editar para mí es más lento que escribir todo. Una de las razones por las que he dejado de usarlo es porque hago clases donde la mayor parte del tiempo hago código en vivo, y no es ninguna gracia que te sugieran largas líneas de código.

Sirve, vale la pena (yo lo tengo gratis por ser estudiante), pero no es la gran maravilla. Podría vivir sin él y prefiero algo como Intellicode que permita autocompletar más rápido y entender mejor lo que estoy haciendo.

Intellicode

Esta extensión ha terminado siendo mucho más útil. Intellicode es bien interesante, ya que permite mejorar las capacidades de Pylance para dar mejores sugerencias. No sé si habrán dado cuenta de que muchas veces las sugerencias son bien malas. Uno siempre importa csv y al colocar pd.read_ se sugiere .read_clipboard() porque alfabéticamente va primero. Al habilitar Intellicode, el motor de sugerencias va aprendiendo para entregar mejores sugerencias de acuerdo a tu código y a tus prácticas de escritura. Verás que mejores sugerencias se ven con una estrella:

Solía haber una extensión llamada Kite que era muy similar y que la verdad funcionaba sumamente bien hasta que comenzar a cobrar por todas las cosas buenas que tenían. Lamentablemente quebró y encontré esta que ha suplido bastante bien mis necesidades.

Path Intellisense

Esta extensión permite el autocompletado de los paths/rutas reconociendo que archivos están disponibles a medida que uno construye la ruta. Sumamente útil, en especial para los que tenemos mala memoria recordando donde guardamos nuestra info. Creo que lo único que no me gusta es que exige para disparar las sugerencias (al menos inicialmente) el partir el path con ./. A parte de eso, muy buena extensión.

Python Type Hint

Como el nombre lo dice, sugiere autocompletado para cuando quieres utilizar Type Hints.

Superpoderes

Extensiones que permiten que haga cosas de manera más rápido o eficiente normalmente utilizando sólo el teclado.

Autodocstring

Es otra pequeña extensión que entrega el template de un Docstring. Para los que no sepan, un Docstring es una documentación propia de una función en Python. Lo bueno de esto es que no sólo entrega una pauta de referencia de cómo rellenarla sino que además VSCode la renderiza de manera muy bonita cuando se hace hover sobre la función con el mouse.

Es importante recalcar que VSCode soporta muchos formatos de docstring, pero yo ocupo estilo Numpy, el cuál se puede configurar en Settings > AutoDocstring:Docstring Format.

La extensión automáticamente identificará los parámetros de entrada y si es que existe un return y mostrará placeholders para reemplazar el tipo de dato y una descripción de cada elemento.

Quick and Simple Text Selection

Probablemente la mejor extensión para los que nos gusta usar el teclado y sumamente desconocida (pueden ver el número de descargas). Tiene atajos de teclados que permiten seleccionar todo lo que se encuentre entre cualquier tipo de paréntesis o comillas. Además tiene otra funcionalidad que permite cambiar el tipo de comillas inmediatamente.

En mi caso lo tengo configurado como acorde, es decir, presionados como secuencia, no al mismo tiempo, esto gracias a mi Corne:

Ctrl k ; seleccionará todo lo que está dentro de cualquier tipo de comillas.
Ctrl k a seleccionará entre paréntesis, Ctrl k s entre corchetes y Ctrl k d entre llaves. La elección de esto tiene que ver con cómo hago los distintos de paréntesis en mi teclado.
Ctrl k : irá rotando entre “”, ‘’ y ``. Súper útil.

Advanced New File

Es una extensión que sólo permite crear un archivo nuevo. La gran gracia es que puedo especificar su ruta completa y creará carpetas intermedias que se requieran para su creación en el caso que no existan. Me gusta principalmente porque permite agregar un atajo de teclado para hacerlo más rápido.

TabOut

Probablemente la extensión más simple pero más útil del mundo. Una de las ventajas que tiene VSCode es el auto-cerrado de paréntesis y comillas, que es genial para que nunca olvides cerrarlos. El problema que trae eso es que luego tienes que usar la flecha a la derecha ➡️ para salir del paréntesis o cierre de comillas. Esto es particularmente un problema porque la flecha a la derecha suele estar lejos en los teclados convencionales y eso significa perder la posición de home row si haces touch typing (que es una demora innecesaria). Esta extensión tiene el único objetivo de usar la tecla Tab para salir de un cierre de paréntesis o comillas. Demasiado simple, pero no les puedo explicar lo productivo que es.

Python postfix completion

Todavía no me termino de acostumbrar a esta extensión, pero tiene varias cosas muy interesantes. Por ejemplo: Si tengo un objeto en Python llamado item y hago item.len se transforma automáticamente en len(item). Esto siempre pasa, no te das cuenta que es una lista y no tiene .shape y tienes que devolverte a hacer el len(). Tiene varios atajos más para return, for loops, if statements, y funciones de conversión como int().

Python Indent

Por alguna razón VSCode al presionar Enter dentro de alguna estructura de datos o alguna sintaxis que requiera indentación, no mantiene la indentación. Esta extensión asegura que si se mantenga. Simple! Por ejemplo si escribo un else: y presiono Enter automáticamente la siguiente línea está indentada.

Misceláneo

Todas las extensiones que no supe como clasificar.

Git Graph

Otra extensión muy pequeñita. Muchos recomiendan el uso de Git Lens (pero realmente no entiendo para qué sirve). Esto lo único que hace, pero lo hace muy bien, es mostrar de manera mucho más bonito un git log.

La extensión muestra todas las ramas, como interactúan entre ellas y cada uno de los commits. Simple y bonito!!

Markdown All in One

Como el sitio lo llevo principalmente en Markdown, uso esta extensión para habilitar atajos como Ctrl + B para Negrita o Ctrl + I para Cursiva, además de funcionalidades para trabajar mejor en Markdown como previsualizar o evitar el autocompletado innecesario.

Remote SSH

La mejor extensión que existe para conectarte de manera remota a un servidor. La verdad es que por ahora ser cliente Movistar me dio un pequeño problema porque no tenía autorización al puerto 22 que es el puerto por defecto para usar SSH, pero aparte de eso, requiere cero configuración y me permite conectarme de manera remota a mi servidor JARVIS.

Project Manager

Creo que todavía no le termino de sacar el beneficio a esta extensión, pero básicamente, en vez de tener que abrir cada carpeta de proyecto, o navegar por el terminal dependiendo de donde quieres trabajar te coloca una pestaña en la que tienes todos tus proyectos. Por lo que basta con abrir VSCode donde sea y ahí tienes todo. No me termino de acostumbrar porque tengo la costumbre de entrar siempre por terminal. Pero es una excelente extensión.

DVC

Esta es una extensión para poder generar experimentos en DVC, muy similar a lo que sería Tensorboard. Probablemente muy útil (no la he usado mucho aún), pero requiere de un tutorial por sí sola.

La verdad es que tengo más extensiones instaladas, pero que en verdad no les he encontrado el uso. Una de ellas es Bookmarks, nunca la he usado. Hay otras que me parecen bien interesantes como Docker o Dev Containers, pero me gusta mucho el uso del terminal, por lo que casi siempre termino interactuando mediante él.

Otra cosa que para mí es sumamente importante es el terminal. Si bien no es una extensión adicional, sí utilizo mucho el terminal integrado para no tener que abrir ventanas adicionales.

Mi terminal utiliza Oh my ZSH con Powerlevek10k. Esto me permite tener mucha información en la línea del terminal como:

La ruta actual en la que estoy parado.
La rama de Git además archivos en stage, si commits esperando push o incluso un stash. Además me indica estados como rebase y el estado del rebase en caso de conflictos.
El ambiente de Python en el que estoy actualmente.
Hora.
Me indica si el estado del comando fue exitoso o no.

Y tiene autocompletado, syntax highlightning entre otros. Vale mucho la pena.

Ahora, para que todo esto valga la pena tiene que ir de la mano con la configuración de VSCode, y por sobre todo los atajos de teclados. Yo diría que utilizo la mayoría de atajos por defecto, pero tengo algunos customizados que hacen mi vida más sencilla (en combinación con la disposición de algunas teclas en mi teclado como Ctrl).

Pero lo dejamos para la otra,

Espero que les haya gustado y les sirva para armar un ambiente más ameno y cambiarse a VSCode.

Alfonso

¿Dónde Aprender Ciencia de Datos?

2023-02-20T00:00:00+00:00

¿Por qué siquiera molestarse en volver a la Universidad si hay tantos cursos por ahí que me permiten aprender lo mismo o más sin tener que pasar por el estrés de la Universidad? Eso es lo que debería haber pensado antes de entrar a la UAI. Acabo de terminar mi ~~primer~~ segundo semestre en el MSDS de la Universidad Adolfo Ibañez, pero ¿Vale la pena el costo? ¿Vale la pena volver a la Universidad para aprender de Ciencia de Datos?

Actualizado 2023

Bueno yo soy de las personas que cree que existen muchos recursos para aprender Ciencia de Datos. Y está lleno, algunos de los que yo he utilizado:

A diferencia de lo que algunas personas muy reputadas en Linkedin puedan pensar yo sí creo que es importante programar de manera excelente. Ya que lo que menos uno puede hacer como Científico de Datos es darse el lujo de desperdiciar recursos por no tener la habilidad suficiente para llevar a cabo una buena implementación.

Google + Stackoverflow (no necesariamente para aprender Ciencia de Datos pero para poder implementar algo)
Datacamp
Youtube
Stanford Artificial Intelligence Professional Program
Coursera
Udemy
Contribuyendo en Open Source

En este artículo, me gustaría contarles cuál ha sido mi experiencia con estos cursos, cuáles tengo ahí esperando a tener tiempo libre y si vale la pena hacer lo que estoy haciendo: ElMSDS.

Google + Stackoverflow

Creo que esto es algo transversal para cualquier programador. Siempre que existan dudas de cómo implementar algo lo mejor es Googlear. De hecho, me pasó de que cuando tuve la oportunidad de estar a cargo de un equipo de Data Science para mí es mejor que alguien no sepa, pero sepa Googlear a que “se las sepa todas”. Rara vez uno conocerá todo lo que necesita para una implementación o para solucionar un error de código. Creo que hoy en día aprender a Googlear y a elegir cuál de todas las respuestas de Stackoverflow es la más apropiada, es un skill que hay que desarrollar. Con una googleada y 2 o 3 links y ya mi problema debería estar solucionado (a menos que sea un problema muy raro y hay que incluso meterse en el Github del autor de la librería).

Mi recomendación: Es bueno saber googlear, usar palabras claves, comandos de búsqueda específica de Google y ser capaz de rápidamente discernir qué respueta de Stackoverflow es la más apropiada. A eso le sumaría conocer las documentaciones de sus librerías, cuáles son confiables y cuáles no tanto. Ej: Pandas, Scikit-Learn, Pytorch son librerías con excelente documentación y que es muy fácil encontrar algo. Por otro lado, Tensorflow (no me maten), Pytorch Lightning, Statsmodels, son como documentaciones enredadas, difíciles de seguir. No sé si han entrado a la Documentación de SQLAlchemy o Pytest, esas son imposibles. Entonces, si la documentación es buena ir directo ahí, sino, Stackoverflow al rescate.

Hay otro tipo de documentación que está haciendo bien popular Tiangolo en librerías como SQLModel, Typer o FastAPI que es como un arma de doble filo. Es como en modo historia/tutorial que para aprender la librería está espectacular, pero cuando quieres buscar una funcionalidad específica nunca sabes donde buscar. Pero bueno estamos hablando de otra cosa.

Datacamp

Creo que he tomado suficientes cursos como para hablar con propiedad: tengo 37 Cursos en Python más el Track de Machine Learning Scientist y ML Fundamentals además de 18 en R. No les voy a mentir, no es un curso que sea increíblemente difícil y en el que vayan a volverse expertos, pero quita el miedo, y les ayuda a soltar la mano para codear rápido. Yo aprendí Python en Datacamp, venía de sólo saber R, y aprendí Pandas, Scikit-Learn y Python Base a un nivel bastante decente. Eso junto con empezar a implementar cosas fue lo que más confianza me dió en Python.

Ahora, hay cursos muy buenos como los de Pandas y Scikit-Learn (no todos, pero la mayoría), pero encontré particularmente malos los de Matplotlib y Seaborn, más que ayudarme a entender la librería me ayudaron a confundirme más. Además, tomé por ahí un curso de GIT y de UNIX que fueron bastante buenos para perder el miedo a estas tecnologías.

Mi Recomendación: Creo que este tipo de cursos sólo vale la pena para gente que no conoce una tecnología y quieres perderle el miedo. Si bien yo pagué dos veces la suscripción anual a Datacamp, no creo que lo volvería a hacer. Si te quieres iniciar en R o Python (creo que ahora también tiene SQL y Tableau) vale completamente la pena. Si tú intención es especializarte, entonces te vas a aburrir.

Youtube

Para mí es casi mi fuente primaria de sabiduría. Obviamente hay de todo y hay que saber filtrar. No tengo las respuestas de todo y probablemente va a depender mucho de cuáles son tus intereses para aprender. Yo puedo compartir los youtubers que más sigo para algunos de mis temas:

Probabilidad y Estadística y Teoría en General: Statsquest, por lejos lo mejor. A algunos les pueden molestar sus canciones, pero vale la pena aguantárselas porque el contenido es muy bueno. Y uno que encontré para algebra lineal que es espectacular 3Blue1Brown recomendado por mi amigo Álex Álvarez.
Python Misceláneo: Python Engineer, Sentdex(aunque no me gusta mucho en aspectos más teóricos, es medio chamuyento).
Deep Learning en Español: Sensio, lo mejor que hay en español.
Machine Learning y Deep Learning: Abishek Thakur, súper buen contenido del primer Cuádruple Kaggle GrandMaster.
Otros canales buenos:
- ArjanCodes es un canal misceláneo de muchas cosas pero todas en Python. He aprendido muy buenas prácticas de diseño de software viendo este canal. Y el tipo explica muy bien.
- HuggingFace es una joyita bien escondida.
- AI Epiphany, es un canal mucho más avanzado de Aleksa Gordic, un cabro que hoy está trabajando en DeepMind. Creo que tanto su canal como su Github tiene mucha info de lo último en Deep Learning.
- Aladdin Persson, es un canal súper denso igual, casi siempre son implementaciones de Papers.
Cursos de Deep Learning: Canales de Stanford principalmente.
- CS229 2018 y 2019
- CS224N
- CS224U
- CS224W
- Uva Deep Learning
- Transformers United (no lo he visto aún)
- HuggingFace Course: Acá tienen varias opciones. Yo estoy en este momento tomando el de NLP, pero no me había percatado del beneficio de este curso en partícular porque se explica demasiado bien el por qué funcionan los transformers.
- etc.

Mi Recomendación: Suelo utilizar Youtube para contenido más denso, que no siempre entiendo de un paper o un libro, por lo que prefiero que alguien me lo explique. Para dudas de programación, normalmente googleo.

Artificial Intelligence Professional Program

Este es el programa que estoy a punto de terminar en la Universidad de Stanford. Básicamente te entregan un pool de cursos y tú debes tomar 3. Yo tomé XCS229 que es el curso de Machine Learning de Andrew Ng, XCS224W que es el curso de Jure Leskovec de Redes Neuronales de Grafos y XCS224N que es el de Chris Manning de NLP y Transformers.

Estos son por lejos los mejores cursos que he tomado. He aprendido muchísimo tanto teóricamente, como en implementaciones prácticas. Son cursos basados en los cursos dictados en postgrado en Stanford, con las mismas tareas que se dan en el Campus. Son cursos densos, teóricamente muy profundos, y las tareas son muy difíciles, normalmente tienen parte teórica para probar la matemática detrás e implementaciones en Python (ML implementa en Numpy desde cero y en DL con Pytorch).

Mi Recomendación: Este tipo de cursos se toman sólo si te gusta sufrir. Me tomó cerca de 2 años tomar los 3 cursos, toman un trimestre cada uno, y además son muy caros: ~~US$1595~~ US$1700 y ojo que si no estudias te los puedes echar. Hay alta tasa de deserción y no se devuelve el dinero. Lo que sí, quedas certificado por la Universidad de Stanford y recibes Certificados y un registro de la Universidad.

Coursera y Udemy

Este es el cementerio de cursos más grandes que tengo, en especial de Udemy. En Udemy, hay harto curso malo, y que luego de un par de videos te das cuenta que no vas a aprender nada nuevo. Yo tomé unos de Pytorch que me gustaron y unos de una librería llamada Feature Engine, aunque aún me queda uno esperando de MLOps dado por la misma autora. En Coursera, dado que son más caros, tengo muchos ahí que tomé completos, pero sin las tareas. Los mejores cursos a tomar en Coursera son definitivamente cualquiera de Deep Learning AI y uno que se llama How to Win a Kaggle Competition, que hoy es muy dificil de encontrar porque es dada por una Universidad Rusa y debido a la guerra no está disponible para nuevos estudiantes. How to Win a Kaggle Competition tiene todos los trucos habidos y por haber de ML clásico: EDA, Preprocesamiento, Tuning de Hiperparámetros, un detalle de todos los modelos más comunes, Data Leakage, Cross Validation, Ensambles.

Mi recomendación: En Coursera, tomar los de Deep Learning AI. Son muchísimos, pero valen la pena aunque sean en Tensorflow (El de GANs es en Pytorch). Y no sé, en mi opinión son cursos difíciles y caros, entonces si hay algo que realmente quieres aprender dale, porque son en general de muy buen nivel. Respecto a Udemy, no sé, tomarlos bajo tu propio riesgo, es muy alta la chance de salir decepcionado.

Contribuyendo en Open Source (Nuevo)

Esto es algo nuevo para mí. Y tengo que agradecer a Sole Galli por animarme a hacerlo. Ella es la mantenedora de Feature Engine y me animo a solucionar un bug que encontré en la librería el año pasado. Fue genial porque es super presente en las revisiones y en las sugerencias de donde hacer las correcciones. Sigo contribuyendo regularmente a la librería y creo que el mayor aprendizaje es en buenas prácticas de programación y uso de Git.

¿Y el MSDS?

Bueno el Master of Science in Data Science (MSDS, igual es como malo el nombre), es un Magister Académico, es decir, está enfocado en quedarse idealmente investigando y/o eventualmente tomar el Doctorado en Data Science. ¿Por qué lo tomé? No voy a mentir, por el cartón. Yo soy solo egresado de Ingeniería Civil (y tengo mi licenciatura en Ciencias de la Ingeniería), pero es algo que siempre me sacan en cara. Aún así, Jooycar confió en mí y me dio la oportunidad de ser Head de Data Science y creo no haberles fallado. Pero en general el cartón pesa. Ahora, yo tuve que entrevistar varios tipos con Magister y no les encontré nada especial. Es más, incluso algunos sabían menos que un Data Scientist con un par de años de experiencia.

La siguiente pregunta es: ¿Por qué en la UAI? Bueno, ví varias opciones, y Magister en Data Science propiamente tal sólo encontré la UAI y la Universidad de Chile. Y la UAI me becó, por eso en la UAI. No creo que haya una gran diferencia entre ambas universidades. La otra opción que tenía era tomar un Msc. en Informática y armar mi malla con ramos en Ciencia de Datos. Pero la UAI me becó y aquí estamos.

La decisión fue tomada en conciencia de que probablemente no aprendería nada nuevo. Esto, luego de ver un video de Mark Tennenholtz (Kaggle Master) que está haciendo su Master en Georgia Tech y dijo estar aprendiendo incluso menos cosas de las que ha aprendido en Kaggle. Bajo eso, dije bueno: No pierdo nada en intentar estando becado y ~~me he sorprendido para bien, he aprendido más de lo que esperaba,~~ me encantó. La verdad es que terminé aprendiendo demasiado de cosas que jamás pensé que fueran tan útiles. Acá dejo un detalle de todos los ramos que tomé, sin pelos en la lengua.

Primer Semestre

Análisis Geoespacial (Prof. Moreno Bevilacqua): Creo que fue el ramo que más me gustó del primer semestre. Es básicamente estadística avanzada enfocado en Campos Aleatorios. No sé si alguna vez utilice esto, pero la cantidad de estadística multivariada que aprendí es impagable. Este tipo de análisis permite ajustar modelos en el espacio y espacio-tiempo para luego generar predicciones (Kriging). El ramo lamentablemente se hace en R, pero utilizamos la librería que creó el profe además de implementaciones hechas de manera manual. Súper buena mezcla entre teoría dura y código.
Current Trends in Data Genomics (Prof. Álvaro Cortés): Este es quizás el ramo más interesante. A mí no me mató principalmente porque no me gusta la Biología, pero básicamente nos enseñaron lo último en análisis genético tanto de ADN como de ARN. Además lo interesante es que el profe nos hizo clases desde Bélgica (KU Leuven) y nos dió acceso a un Supercomputador (HPC Cluster), lo cuál fue una tremenda experiencia (trabajamos con Clusters con hasta 384 Nodos). Es sumamente interesante saber cómo se pueden detectar mutaciones, cánceres, variantes genéticas, etc. Es una clase de harta teoría, nos hicieron leer varios papers, pero quizás lo mejor fue que justo en la mitad del curso se liberó el artículo indicando que finalmente se pudo secuenciar el Genoma Humano completo, lo cual fue entretenido, porque gracias al curso pudimos entender el alcance de este trabajo. Finalmente (y eso que el curso no me mató), el trabajo final consistió (en mi caso) en investigar acerca de un Modelo de Red Neuronal de Grafos para el proceso de novo assembly, para poder generar Genomas de especies en las que no se tiene referencia. Realmente fue un joya tener un curso así aunque es difícil que alguna vez lo llegue a aplicar.
Percepción Remota (Prof. Javier Lopatín): Otro ramo que me gustó, y el tema en el que estoy haciendo mi tesis. Al principio el nombre no parecía muy atractivo, pero terminó siendo súper interesante. Principalmente la percepción remota se encarga de utilizar imágenes que pueden ser satélitales, de drones, de aviones y un largo etc. para poder detectar cosas. Esto lo encontré súper interesante, porque el ramo es en Python, es sumamente aplicado, y además pudimos utilizar librerías de manipulación de imágenes para calcular muchas cosas: pendientes, sombras, altitud. Aprendimos librerías súper cool como rasterio, xarray, geopandas y es un tema súper interesante (por eso mi tema de investigación), entre otras cosas, por el cambio climático. El ramo enseña todo lo teórico en cuánto a qué información se puede extraer de imágenes hiperespectrales (o sea tienen más canales que el RGB) y métodos de Machine Learning en Clasificación, Regresión y Series de Tiempo (aunque es sólo una pincelada). SPOILER: Estoy trabajando en el uso de Deep Learning para Anomalías en Series de Tiempo de Imágenes, súper choro.
Tópicos en Data Management y Data Analytics (Nombre fancy para Bases de Datos) (Prof. Miguel Romero): Este pensé que sería el ramo más aburrido de la vida pero terminó siendo súper interesante. Aprendimos SQL (y sí, aprendí cosas nuevas de SQL que no sabía, como consultas recurrentes, índices, y uno que otro truquito de queries), aprendí Mongo (yo igual había usado mongo, pero siento que el curso enseña varias cosas bastante avanzadas que no sabía) y lo que más me gustó fue Neo4j. Neo4j es una base de datos de Grafos, que realmente cambió mi manera de ver la organización de la data. Sirve tanto para data estructurada como no estructurada y es poderoso y rápido, y además permite aplicar proyecciones y algoritmos como PageRank. Definitivamente voy a estar subiendo un tutorial de Mongo y Neo4j. Si bien no esperaba mucho de este curso, que de paso es obligatorio, terminé aprendiendo muchísimo.
Técnicas Estocásticas y Estadísticas en Data Science (nombre fancy para estadística básica) (Prof. Leopoldo Bertossi): Quizás el ramo más decepcionante, y no creo que sea por la materia sino por el Profe. Realmente la pasamos mal en este ramo, es estadística básica, y realmente aprendí conceptos muchos más robustos en estadística, variable aleatoria discreta sobre todo, redes de Bayes, algo de Markov, y un poquito de teoría de Información, pero no volvería a tomar este ramo con el mismo profe. Explica bien, pero nunca entendimos lo que preguntaba en las evaluaciones, y lo pasamos mal, era bien pesote. Lo voy a dejar ahí. Lamentablemente es un ramo obligatorio y que no vale la pena, ya que aprendí mucha más estadística en Análisis Geoespacial.

Segundo Semestre

Durante el segundo semestre tomé los siguientes ramos:

Álgebra Lineal y Optimización para Data Science (Prof. Miguel Romero): Este fue el curso cortacabezas, bien denso teoricamente pero probablemente el mejor curso que he tomado de teoría asociada a Data Science. El curso es una joya, especialmente porque está dividido en dos partes: Algebra Lineal, creo que en el Algebra Lineal de pregrado rara vez se aborda el entendimiento de Operaciones Matriciales como Transformaciones Lineales que llevan de una dimensión a otra (que es la base del funcionamiento de las redes neuronales). El curso no sólo cubre en detalle toda la parte matricial incluyendo interpretabilidad de operaciones, calculo diferencial y optimización de funciones matriciales, pero también toca en detalles algoritmos basados en operaciones tipo Valores Propios como son PageRank, PCA y SVD. Y una segunda parte de Optimización que cubre desde Optimización Convexa hasta Optimización No Convexa, incluyendo algoritmos como SGD, Momentum, Nesterov, Adagrad, Adadelta, RMSProp y Adam. El curso es muy bueno pero difícil. Las pruebas son de corte más teórica, incluyendo algunas demostraciones no tan complejas, pero que hay que pensarlas igual, y las tareas son más de código implementando todo en Numpy. Muy buen curso.
Métodos de Aprendizaje de Máquina en Data Science (Prof. Raimundo Sanchez): Este fue un ramo obligatorio (y el que pasé con la peor nota 😂) y la verdad no me gustó mucho. Siento que no es un curso en el que se enseñe modelamiento (para ser justos hubo otra sección donde se entró en más detalle) pero no se entró en el detalle que esperaba (como sí se hizo en Algebra Lineal). El profe muy simpático, pero hubo tres cosas que me molestaron particularmente: Una que el curso se hizo en R y tidymodels (luego de usar Scikit-Learn se nota que R es realmente malo para Machine Learning. La documentación es pésima, los errores son muy confusos y no hay mucha ayuda en StackOverflow, además de que la librería es muy lenta. De hecho fue tanto así que para la última tarea se permitió el uso de Python porque la última entrega requería del uso de un dataset de 1M de registros y tidymodels sencillamente no daba a basto. Segundo, realmente como un curso de post-grado era absolutamente necesario entrar en los detalles más mínimos y descomponer las ecuaciones detrás de cada modelo. Humildemente creo que la documentación de Scikit-Learn es más profunda que la clase. Finalmente, me pareció que las pruebas eran muy de opinión, muy subjetivas, casi apreciativas, y no creo que sea la mejor forma de evaluar este tipo de curso. En general, no me gustó mucho el curso, pero bueno, no me fue tan bien y puede sonar a picado 😇.
Seminario de Tesis (Prof. Tamara Fernández): Este curso fue un desperdicio. Pero espero se entienda bien. No porque el curso fuera malo, sino que porque desaprovechamos una profesora de talla mundial en un curso Online. Creo que ella intentó hacer lo mejor que pudo enfocándose en cosas que son sumamente útiles para la investigación: Aprender a buscar papers, crear documentos académicos, utilizar Latex, y algunas herramientas de mucha utilidad para alguien que quiere investigar. Lamentablemente en mi opinión perdimos demasiado tiempo en comandos básicos de Latex, que son googleables, y no tuvimos la oportunidad de aprovechar a la profe. Digo esto porque la actividad final del ramo fue diseñar un póster del trabajo de tesis, que a mí en particular me sirvió mucho para poder ordenar mis ideas y encaminar sumamente bien mi tesis (que va avanzando bastante bien), pero también tuvimos la oportunidad al finalizar la sesión de quedarnos conversando con ella y aprender muchísimo sobre su experiencia estudiando en Oxford, su trabajo con su supervisor Yee Whye Teh, Research Scientist en DeepMind, y obviamente aprendiendo a sobrevivir un doctorado. Realmente hubiera sido genial poder tener muchas más conversaciones con ella.

En mi opinión este es uno de los fuertes de la UAI. Viniendo de Universidades como la USM donde al menos en mi tiempo costaba muchísimo que un profesor te diera bola. Tener conversaciones donde los profes no te hagan sentir como “idiota”, y en verdad te animen y aconsejen sobre tu futuro es algo invaluable.

Neural Networks (Prof. Daniel Furtado): No me gustó en general el ramo. No aprendí nada nuevo porque en mi opinión el curso estaba muy desactualizado, aunque siendo súper sincero a muchos les sirvió bastante. Los puntos bajos para mí es que tocamos cosas como la historia de la IA o arquitecturas que ya nadie usa y que no existe forma de implementarlas de lo añejas que están y lo que todo queríamos que era algo como Transformers, RF o Stable Diffusion eran temas que el profe ni siquiera conocía. Ahora las tareas fueron bien entretenidas, pero dependía mucho de el esfuerzo que uno quisiera poner. Debido a que yo quería sacarle el máximo provecho al curso implementé en Pytorch un MLP, un RBF-NN, una ResNet, una EfficientNet. Pero una tarea que era implementar una GAN se eliminó (y menos mal, porque teníamos muy poco tiempo para todo eso). No recomendaría el curso, y no me gustó. Probablemente la gran decepción del semestre.
Grafos en Ciencia de Datos (Prof. Miguel Romero): Otro curso excelente, que es una de las grandes joyas del programa. El profe es un crack, y este es el tema que más domina. El curso es interesante no sólo porque toca temas relacionados a Grafos, pero también porque introduce mucho background de Informática que uno como Data Scientist debería tener: Escritura de Algoritmos, Complejidad Algorítmica (Notación Big O, Notación NP, etc.), estructura de datos, y por supuesto su aplicación en Grafos. Cosas muy útiles como Breadth First Search, Depth First Search, fueron explicados en detalles e implementados por nosotros en código además de algoritmos para caminos mínimos, minimum spanning trees, clustering, comunidades, cliques, coloreo, homomorfismos, etc. Además pudimos tener una visión general de cómo se implementan algoritmos de Machine Learning en Grafos, como PageRank, PageRank con Teleportación, DeepWalk, Node2vec, Node Embeddings, y entender el detalle la diferencia con las Redes Neuronales de Grafos. En particular agradezco mucho el uso de Pytorch Geometric y el poder entender muy en detalle el funcionamiento interno. Creo que este es el curso en el que más cosas nuevas (y útiles) aprendí.

Muchas personas se quejaron porque el profe Romero es un poco bajo perfil. Lo consideran fome y aburrido para sus clases, pero yo lo siento como en el mismo tono de Andrew Ng, que parece que tiene sueño, su tono es medio plano, pero dejando eso de lado y enfocando en su contenido son demasiado buenos. Sus slides son demasiado ordenadas y el orden en el que va pasando el contenido hace que realmente uno disfrute mucho sus ramos. Para mi gusto (y esto es muy personal) fue el mejor profesor del programa.

Modelos Lineales (Prof. Moreno Bevilacqua): Este fue un ramo que me gustó mucho también. Fue un ramo bien teórico y el Profesor Bevilacqua se caracteriza por ser un profesor de mucha pizarra y de mucha demostración. Siempre es bueno tener en cuenta técnicas de demostración, los supuestos al momento de generar modelos lineales, y técnicas de optimización como el Maximum Likelihood Estimation (MLE). El ramo si bien es en R, se usa muy poca librería, porque el profe le gusta implementar todo desde cero, que es un approach que me gusta, porque desmenuzar el código me ayuda a entender de mejor manera cómo funciona el algoritmo por detrás. Una de las cosas que más agradecí es entender en detalle el problema de la multicolinealidad (acá influyó bastante entender el problema de cuadrados mínimos desde el Algebra Lineal) y al menos el Profesor Bevilacqua, piensa que variables multicolineales o con un grado de multicolinealidad no es de gran gravedad, lo cual fue algo que me sorprendió bastante. Otro de los mitos que rompió fue el tema de la significancia de las variables. He estado en varios cursos, en los que se enseña como método de selección de variables el deshechar las variables no significativas por p-value, algo que siempre me llamó la atención porque nunca he visto un algoritmo que mejores su performance predictiva por eliminar variables no significativas.

Bueno, ¿vale la pena? Depende.

En mi caso, estaba buscando aplicaciones en Ciencias de Datos que no sean típicos modelos de fuga, de propensión y que el único objetivo que tienen es que empresas ganen más plata. Por otro lado, como mi rollo es el Deep Learning, he tenido la oportunidad de aprender varias cosas fuera de lo común, acabo de implementar un algoritmo de Anomaly Detection llamado DeepAnT y voy a estar implementando varios más, algunos que no tengo idea cómo. Si te gusta implementar cosas raras, que tienen un valor, pero no necesariamente en lo económico para una empresa (en mi caso queremos encontrar anomalías en el uso de terrenos como bosques ~~, humedales y turberas~~ con imágenes satelitales), entonces vale completamente la pena. Si quieres sólo estar más preparado para hacer la pega de siempre (lo cual no es malo), quizás es mejor un programa Profesional.

Sólo a modo de ejemplo, el Magister Profesional de la UAI (puede ser cualquier otro, nada en particular con este), probablemente te enseñará elementos más aplicados, con menos teoría. Perfeccionarte en R y Python, cómo hacer buenas visualizaciones, uno que otro modelo por ahí, y un largo etc.

En el MSDS, no teníamos tiempo de aprender a programar, el que sabía bien, y sino, doble pega (aunque se ofrece un bootcamp de nivelación en caso de necesitarlo). En mi caso, me ayudó mucho tener experiencia en Python y R, hizo que los ramos se me hicieran menos pesados. Pero aún así en especial en las últimas 3 semanas fue caótico, mucho que estudiar, muchas tareas, presentaciones, informes, posters, y entregas teóricas (todo en Latex, aunque no es obligación) y código. Lo pasé mal, así que hay que tener ojo también con cuanta carga quieres tener. Yo partí tomando el Master y mi pega (que siendo bien organizado es posible, al menos en mi opinión), luego me echaron, pero el segundo semestre tuve proyectos freelance, competencia, clases, bootcamps y sobreviví.

Espero que para los que están buscando algún programa les sirva. Traté de ser lo más imparcial posible. Y si me preguntan si recomendaría el MSDS yo diría que sí, me gustó. Aprendí cosas que no están en Youtube, o que cuesta mucho encontrar, y que rara vez tendrás la oportunidad de verlas en empresas tradicionales. Me gustó tanto que decidí seguir adelante y comienzo mi PhD en Ciencias de Datos en Marzo, aunque todavía estoy en el proceso de cerrar mi tesis de Magister que tiene fecha para Mayo.

Nos vemos y espero que sea de utilidad.

Alfonso

¿Hagamos un Proyecto desde cero? Parte 3

2022-10-10T00:00:00+00:00

Esta es la tercera patita de cómo hacer un proyecto desde cero. Puedes ver la parte 1 acá y la parte 2 acá. La idea es que, como ya implementamos un modelo baseline y un clipping, ahora podamos ir implementando elementos que permitan poder mejorar el puntaje obtenido. .

Si es que hiciste la tarea, habrás notado que algo raro pasa. En la vida real nosotros no podemos ver nuestro Test Set, eso irá ocurriendo a medida de que el Motor vaya funcionando. Por lo tanto, nosotros deberíamos confiar que nuestro esquema de validación es suficientemente robusto para decirnos que el modelo va a generalizar como corresponde en Test-Time. Pero acá no ocurre.

Los resultados que debieron haber obtenido muestran que el mejor puntaje de Validación se obtiene con Clipping de 150 pero no es el que generaliza mejor en Test. En test nuestro modelo actúa mejor con Clipping de 120. Lo que acaba de pasar es algo muy dificil de detectar (no sabría como hacerlo en tiempo real), nuestro modelo no está generalizando de manera apropiada. Y esto puede ser por varias razones:

Nuestro esquema de Validación no es confiable.
Tenemos algún error en nuestro código.
No estamos capturando apropiadamente el error.

Detectar este tipo de Problemas es quizás de las Skills más complicadas de desarrollar, y para los que dicen que la Modelación Competitiva (Kaggle principalmente) no sirve, déjenme decirles que esto es precisamente la skill principal a desarrollar en competencias. Poder descubrir a ciegas si el modelo está generalizando de manera apropiada o no.

Me gustaría pensar que este problema se da por lo siguiente:

Nuestro modelo tiene predicciones bajo cero para RUL reales muy pequeños. Lo cual no refleja la realidad. Debemos pensar que el objetivo final del modelo es poder predecir de manera anticipada que nuestro motor fallará. Por lo tanto, no nos interesan valores negativos diciéndonos que la falla ya ocurrió. Para corregir realizaremos un Post-Procesamiento. Es decir, evitaremos que nuestro modelo prediga RUL menores a uno, de esa manera cuando hayan predicciones con 1 indicará que el motor está pronto a fallar. Quiero pensar que esto solucionará nuestro problema 😕.

Adicionalmente, intetaremos otro approach. Debido a la naturaleza temporal del problema generaremos variables que nos permitan modelar el problema en el tiempo. Para ello generaremos lags, variables con un desfase en el tiempo. Para ello trataremos de descubrir cuál es el mejor set de lags, dejando en este caso un RUL_CLIP fijo de 125.

Vamos a implementar esos cambios.

Archivo de Configuración params.yaml

base:
  random_seed: 42

import:
  train_name: train_FD001.txt
  test_name: test_FD001.txt
  rul_name: RUL_FD001.txt

featurize:
  index_names: [unit_nr, time_cycles]
  setting_names: [setting_1, setting_2, setting_3]
  sensor_names: [s_1, s_2, s_3, s_4, s_5, s_6, s_7, s_8, s_9, s_10, s_11, s_12, s_13,
    s_14, s_15, s_16, s_17, s_18, s_19, s_20, s_21]
  to_keep: [s_2, s_3, s_4, s_6, s_7, s_8, s_9, s_11, s_12, s_13, s_14, s_15, s_17,
    s_20, s_21]
  lags:
  - 1
  - 2
  - 3
  - 4
  - 5
  - 10
  - 20
  - 30
train:
  model_name: model.joblib
  n_split: 5
  rul_clip: 125
  pred_clip: 1
  standardize: true

En este nuevo archivo de configuración tenemos lo siguiente:

En la etapa featurize mantenemos el parámetro to_keep, que nos perrmitirá determinar con qué sensores queremos quedarnos.
Además agregamos los posibles lags que nos gustaría calcular. (La razón en utilizar - como separador es que cuando probamos listas como hiperparámetros DVC al sobreescribir el óptimo lo deja en ese formato).
En la etapa agregamos dos parámetros nuevos: standardize que permitirá activar o no el StandardScaler, que es buena práctica para modelos lineales y que no veníamos realizando. Además fijamos el rul_clip a 125 y el pred_clip a 1.

Featurize

En esta etapa utilizaremos ahora la función create_features() cambiará de la siguiente forma:

def create_features(df_train, df_test, params):
    
    to_keep = params['to_keep']
    lag_features = []
    for lag in params['lags']:
        
        cols = [col + f'_lag_{lag}' for col in to_keep]
        lag_features.extend(cols)
        df_train[cols] = df_train.groupby('unit_nr')[to_keep].shift(lag)
        df_test[cols] = df_test.groupby('unit_nr')[to_keep].shift(lag)
    
    df_train.dropna(inplace = True)
    df_test.dropna(inplace = True)
    
    # selecting last instance to predict
    df_test = df_test.groupby('unit_nr').last()

    return df_train[to_keep + lag_features], df_test[to_keep + lag_features], df_train.rul

Esta función aceptará un set de train y test y creará los lags sólo para los sensores que vamos a dejar (los que entregan info de acuerdo a to_keep). Luego debido a la naturaleza del lag, quedarán observaciones con nulos, los cual simplemente los eliminaremos. También eliminaremos etiquetas, por lo que devolveremos el Train set y el Test set con las nuevas variables y las etiquetas de entrenamiento que sobrevivan a la eliminación de nulos.

La definición de features se ve mucho más sencilla ahora:

df_train = add_rul(df_train)
train_features, test_features, train_labels = create_features(df_train, 
                                                df_test, 
                                                params = params)

Notar que los set ingresados a create_features() son el train luego de crear el RUL y el test sin agrupar.

Train

Cuando entrenamos nuestro modelo ahora tendremos los siguientes cambios:

if params['standardize']:
    model = Pipeline([('scaler', StandardScaler()),
                    ('model', LinearRegression())])
else:
    model = LinearRegression()

#======================================================
# Validation Metrics
#======================================================
folds = KFold(n_splits=params['n_split'], 
                shuffle=True, 
                random_state=Config.RANDOM_SEED)

mae = np.zeros(params['n_split'])
rmse = np.zeros(params['n_split'])
r2 = np.zeros(params['n_split'])

for fold_, (train_idx, val_idx) in enumerate(folds.split(X = train_features, y = train_labels)):
    log.info(f'Training Fold: {fold_}')
    
    X_train, X_val = train_features.iloc[train_idx], train_features.iloc[val_idx]
    y_train, y_val = train_labels.iloc[train_idx], train_labels.iloc[val_idx]
    
    # Training Clipping
    model.fit(X_train, y_train.clip(upper = params['rul_clip']))
    
    # Adding Prediction Clipping (Numpy)
    val_preds = model.predict(X_val).clip(min = params['pred_clip'])
    val_mae = mean_absolute_error(y_val, val_preds)
    val_rmse = mean_squared_error(y_val, val_preds, squared=False)
    val_r2 = r2_score(y_val, val_preds)
    
    mae[fold_] = val_mae
    rmse[fold_] = val_rmse
    r2[fold_] = val_r2
    log.info(f'Validation MAE for Fold {fold_}: {val_mae}')
    log.info(f'Validation RMSE for Fold {fold_}: {val_rmse}')
    log.info(f'Validation R2 for Fold {fold_}: {val_r2}')

Agregaremos la opción de un Pipeline de Estandarización y además al momento de Predecir aplicaremos Clipping mínimo (para evitar los RUL negativos).

El resultado de la predicción es un Numpy Array y el clipping en Numpy utiliza min, max en vez de lower, upper. Fue un dolor de cabeza inicialmente, porque no entendía por qué me arrojaba error.

Evaluate

En el caso de nuestro Evaluate, también debemos aplicar clipping.

model = joblib.load(Config.MODELS_PATH / 'model.joblib')
# Adding Prediction Clipping (Numpy)
y_pred = model.predict(X_test).clip(min = params['pred_clip'])

Proceso de Experimentación

DVC es sumamente inteligente, y podemos utilizarlo para hacer nuestra búsqueda de Hiperparámetros. DVC automáticamente detecta qué etapas se deben reejecutar y cuáles se pueden reutilizar dependiendo de nuestras dependencias definidas en dvc.yaml (ejecutando dvc_config.sh).

Para definir nuestra búsqueda de Hiperparámetros utilizarmos exp_config.sh para probar con distintos lags.

dvc exp run -S featurize.lags=[1,2,3,4,5]
dvc exp run -S featurize.lags=[1,2,3,4,5,6,7,8,9]
dvc exp run -S featurize.lags=[1,2,3,4,5,10,20,30]
dvc exp run -S featurize.lags=[1,2,3,4,5,10,20]
dvc exp run -S featurize.lags=[1,3,6,9,12,15]

Estudiaremos el efecto de los distintos niveles de Lag:

Ahora les toca poder ejecutar todo este proceso en Colab. ¿Mejoramos nuestros resultados? ¿Fue posible solucionar el problema de Generalización? ¿Y si quiero probar otro modelo? Cambia el tipo de Modelo a un Random Forest o a un XGBoost y cuéntame cómo te dan los resultados.

Habiendo entendido esta parte la verdad es que podrías utilizar cualquier modelo de Machine Learning Shallow (los clásicos, RF, XGB, LGBM, Catboost, incluso un Multilayer Perceptron) y no habrían grandes cambios. Variables extras pueden ir en featurize y el resto del Pipeline sigue igual.

Por eso es tan importante la parte de programación en Ciencia de Datos. Mucho del gran esfuerzo se hace al principio en el cual tenemos que dedicar mucho tiempo a un Pipeline robusto que nos permita experimentar de manera rápida y sencilla.

Consejo/Opinión muy personal:

Utiliza Jupyter Notebooks cuanto quieras para explorar, visualizar, incluso cómo instrucciones de Reproducibilidad como estoy utilizandolo yo ahora.
Vamos de a poco dejando de usar los Jupyter Notebooks. Lamentablemente este tipo de estructura para el core del código te fuerza a hacer códigos eternos y poco modulares. Uno se olvida de utilizar abstreaer en Clases o Funciones y copia y pega a veces incluso ejecutando en órdenes diferentes.
Utiliza alguna herramienta de Automatización de Pipelines, yo uso DVC, pero está MAKE (que estoy empezando a revisar y posiblemente se vuelva un tutorial luego), Airflow (también viene luego), y un largo etc.

¿Y habrá parte 4?

Alfonso

¿Hagamos un Proyecto desde cero? Parte 2

2022-09-05T00:00:00+00:00

En este artículo estaremos continuando el proyecto que comenzamos la semana pasada. Si es que te perdiste el inicio del proyecto puedes revisar la primera parte acá. La idea es que este proyecto sea interactivo y puedas ir siguiendo las distintas etapas, pero por sobre todo reproduciendo el código y analizándolo.

Si seguiste la parte uno sabrás que implementamos un modelo baseline muy sencillo. Si entrenaste el modelo y visto sus resultados notarás que el modelo que hicimos no anda muy bien, y sería bueno probar nuevas estrategias para mejorar su performance. Mucho del trabajo duro de programación ya lo hicimos en la parte 1 por lo que ahora nos enfocaremos en las mejoras.

De acuerdo a nuestro Análisis Exploratorio vimos que existen sensores que no están aportando información. Por lo tanto, una primera cosa a probar sería eliminar de nuestras features aquellos sensores que no aportan información. Por otro lado, debido a que estamos utilizando una regresión lineal, podríamos crear interaciones entre variables para ver qué tal le va.

Finalmente si analizamos nuestro True vs Fitted Curve de la parte pasada podemos ver lo siguiente:

A partir de esto podemos concluimos lo siguiente:

Parece ser que a medida que el RUL aumenta nuestros errores se hacen más grandes. Eso normalmente es esperable ya que que no hay evidencia para decir que el motor fallará cuando falta demasiado tiempo para su falla. Debido a la naturaleza del problema a nosotros nos interesa entender cuando queda poco tiempo para la falla y enfocarnos ahí. Una técnica utilizada para resolver este problea es usar un clipping. Es decir, yo permito un RUL máximo, todo lo que supere ese RUL máximo lo acoto a dicho nivel.

Implementemos esos cambios y tratemos de buscar el valor de RUL más apropiado.

Archivo de Configuración params.yaml

base:
  random_seed: 42

import:
  train_name: train_FD001.txt
  test_name: test_FD001.txt
  rul_name: RUL_FD001.txt

featurize:
  index_names: [unit_nr, time_cycles]
  setting_names: [setting_1, setting_2, setting_3]
  sensor_names: [s_1, s_2, s_3, s_4, s_5, s_6, s_7, s_8, s_9, s_10, s_11, s_12, s_13,
    s_14, s_15, s_16, s_17, s_18, s_19, s_20, s_21]
  to_keep: [s_2, s_3, s_4, s_6, s_7, s_8, s_9, s_11, s_12, s_13, s_14, s_15, s_17,
    s_20, s_21]
train:
  model_name: model.joblib
  n_split: 5
  rul_clip: 50

En este nuevo archivo de configuración tenemos lo siguiente:

En la etapa featurize agregamos el parámetro to_keep, que nos perrmitirá determinar con qué sensores queremos quedarnos. Es decir, no consideramos los que no aportan información. La razón por la que hacemos eso es porque sensor_names tiene otra función que es darle el nombre a las variables a importar.
En la etapa train usaremos un clip de 50 inicialmente. Pero la idea es que implementemos una búsqueda de algún valor más óptimo.

Featurize

En esta etapa utilizaremos ahora la función create_features() que nos permitirá crear las interacciones con Scikit-Learn.

def create_features(df_train, df_test, params = None):
    pf = PolynomialFeatures(interaction_only=True)
    
    df_train = pd.DataFrame(pf.fit_transform(df_train), columns = pf.get_feature_names_out())
    df_test = pd.DataFrame(pf.fit_transform(df_test), columns = pf.get_feature_names_out())
    
    return df_train, df_test

Esta función aceptará un set de train y test y creará las interacciones correspondientes entre ellas.

Normalmente suelo usar la librería Feature Engine para hacer las transformaciones. Resulta que Feature Engine tenía un bug con el uso de PolynomialFeatures. Gracias a Soledad Galli (autora de Feature Engine) que me animó a solucionar el bug que reporté. Mi Pull Request ya es parte de la rama main de la librería y en el próximo release habrá código contribuido por mí, lo que me pone muy contento.

Finalmente en la etapa de definición de features se verá así:

to_keep = params['to_keep']
df_train = add_rul(df_train)
train_features = df_train[to_keep]
test_features = df_test.groupby('unit_nr').last()[to_keep]

train_features, test_features = create_features(train_features, test_features)

Notar que los set ingresados a create_features() son el train luego de crear el RUL y el test, luego de ser agrupado para obtener el último ciclo. La razón de esto se explicó en la la parte 1.

Train

Cuando entrenamos nuestro modelo ahora lo haremos con el RUL clippeado. Por lo tanto, el KFold CV cambia de la siguiente forma:

for fold_, (train_idx, val_idx) in enumerate(folds.split(X = train_features, y = train_labels)):
    log.info(f'Training Fold: {fold_}')
    
    X_train, X_val = train_features.iloc[train_idx], train_features.iloc[val_idx]
    y_train, y_val = train_labels.iloc[train_idx], train_labels.iloc[val_idx]
    
    model.fit(X_train, y_train.clip(upper = params['rul_clip']))
    val_preds = model.predict(X_val)
    val_mae = mean_absolute_error(y_val, val_preds)
    val_rmse = mean_squared_error(y_val, val_preds, squared=False)
    val_r2 = r2_score(y_val, val_preds)
    
    mae[fold_] = val_mae
    rmse[fold_] = val_rmse
    r2[fold_] = val_r2
    log.info(f'Validation MAE for Fold {fold_}: {val_mae}')
    log.info(f'Validation RMSE for Fold {fold_}: {val_rmse}')
    log.info(f'Validation R2 for Fold {fold_}: {val_r2}')

Notar que al momento del fit, ahora y_train irá con el clip indicado en mis parámetros.

Evaluate

En el caso de nuestro Evaluate, no tendremos ningún cambio, ya que realizaremos el mismo proceso.

Proceso de Experimentación

Para definir nuestra búsqueda de Hiperparámetros utilizarmos exp_config.sh:

dvc exp run -S train.rul_clip=150
dvc exp run -S train.rul_clip=130
dvc exp run -S train.rul_clip=125
dvc exp run -S train.rul_clip=120
dvc exp run -S train.rul_clip=90
dvc exp run -S train.rul_clip=70
dvc exp run -S train.rul_clip=50
dvc exp run -S train.rul_clip=30
dvc exp run -S train.rul_clip=10

Si quieres entender el efecto de probar distintos valores de clipping te invito a seguir el experimento en el siguiente Colab:

Ahora les toca poder ejecutar todo este proceso en Colab. ¿Con cuántas features se entrenó el modelo?¿Sirvió de algo lo que implementamos? ¿Cuál es el mejor valor de Clipping? ¿Ves algún problema con las predicciones?

Esto fue todo por esta semana, espero que vayan siguiendo y los espero para revisar los resultados en la parte 3.

Nos vemos,

Alfonso

¿Hagamos un Proyecto desde cero? Parte 1

2022-08-30T00:00:00+00:00

Hace tiempo que me interesaba poder mostrar cómo realizar un proyecto desde cero (Al menos simular cómo hacerlo). Para ello me gustaría mostrar alguna de los problemas que me ha tocado resolver. Hoy día vamos a tratar de predecir el RUL. El RUL o Remaining Useful Life es un problema típico en Mecánica en el que se quiere al menos intentar predecir cuánto falta para que una maquinaria falle. Este es un problema sumamente difícil, porque para poder construir el modelo necesitamos construir data, y necesitamos hacer que maquinas fallen lo cual es caro. Si no tenemos maquinas que fallan, este modelo no funciona, porque necesitamos entender qué pasa justo el tiempo antes que la maquina falle. Lamentablemente, empresas hoy en día quieren que se haga magia adivinando cuando sus maquinas fallan, y peor aún, existen consultoras que prometen resolver este problema sin siquiera tener datos al respecto. Esto porque nadie está dispuesto a que sus maquinas fallen en favor de la ciencia.

Hoy día vamos a ver varios métodos tratando de ver cómo resolver este problema y por qué funciona. Para ello utilizaremos el dataset benchmark stándard que se utiliza para probar metodologías: El NASA CMAPPS. Este dataset contiene funcionamiento simulado de motores de aviones, que representan la realidad bastante bien.

Intetaremos por nuestra parte tratar de simular cómo se resuelve un proyecto de Data Science en la realidad, sólo que un poco más acotado.

No quiero que se aburran con tanto código.

Análisis Exploratorio (EDA)

Normalmente para realizar el análisis exploratorio utilizo un Notebook para poder ir mirando mis datos y dejar comentarios en el mismo lugar. El código completo del EDA está en el siguiente Colab.

Datos de Entrenamiento

En este caso particular, la data se encuentra en formato txt separado por espacios, y no tiene bien definidos los nombres. Por lo que se ingresarán todos de la siguiente forma:

index_names = ['unit_nr', 'time_cycles']
setting_names = ['setting_1', 'setting_2', 'setting_3']
sensor_names = ['s_{}'.format(i) for i in range(1,22)] 
col_names = index_names + setting_names + sensor_names


df_train = pd.read_csv('../assets/CMAPSSData/train_FD001.txt', sep = '\s+', header = None, names = col_names)
df_train

	unit_nr	time_cycles	setting_1	setting_2	setting_3	s_1	s_2	s_3	s_4	s_5	...	s_12	s_13	s_14	s_15	s_16	s_17	s_18	s_19	s_20	s_21
0	1	1	-0.0007	-0.0004	100.0	518.67	641.82	1589.70	1400.60	14.62	...	521.66	2388.02	8138.62	8.4195	0.03	392	2388	100.0	39.06	23.4190
1	1	2	0.0019	-0.0003	100.0	518.67	642.15	1591.82	1403.14	14.62	...	522.28	2388.07	8131.49	8.4318	0.03	392	2388	100.0	39.00	23.4236
2	1	3	-0.0043	0.0003	100.0	518.67	642.35	1587.99	1404.20	14.62	...	522.42	2388.03	8133.23	8.4178	0.03	390	2388	100.0	38.95	23.3442
3	1	4	0.0007	0.0000	100.0	518.67	642.35	1582.79	1401.87	14.62	...	522.86	2388.08	8133.83	8.3682	0.03	392	2388	100.0	38.88	23.3739
4	1	5	-0.0019	-0.0002	100.0	518.67	642.37	1582.85	1406.22	14.62	...	522.19	2388.04	8133.80	8.4294	0.03	393	2388	100.0	38.90	23.4044
...	...	...	...	...	...	...	...	...	...	...	...	...	...	...	...	...	...	...	...
20626	100	196	-0.0004	-0.0003	100.0	518.67	643.49	1597.98	1428.63	14.62	...	519.49	2388.26	8137.60	8.4956	0.03	397	2388	100.0	38.49	22.9735
20627	100	197	-0.0016	-0.0005	100.0	518.67	643.54	1604.50	1433.58	14.62	...	519.68	2388.22	8136.50	8.5139	0.03	395	2388	100.0	38.30	23.1594
20628	100	198	0.0004	0.0000	100.0	518.67	643.42	1602.46	1428.18	14.62	...	520.01	2388.24	8141.05	8.5646	0.03	398	2388	100.0	38.44	22.9333
20629	100	199	-0.0011	0.0003	100.0	518.67	643.23	1605.26	1426.53	14.62	...	519.67	2388.23	8139.29	8.5389	0.03	395	2388	100.0	38.29	23.0640
20630	100	200	-0.0032	-0.0005	100.0	518.67	643.85	1600.38	1432.14	14.62	...	519.30	2388.26	8137.33	8.5036	0.03	396	2388	100.0	38.37	23.0522

20631 rows × 26 columns

Como se puede ver el dataset tiene 26 columnas, las cuales corresponden a lo siguiente:

unit_nr: Es el identificador del Motor. Hay 100 motores diferentes, desde su instalación hasta su falla.
time_cycles: Es la unidad de tiempo. Cada Cycle es una medición hasta que muere en el último time_cycle.
setting_1 y setting_2 corresponden a mediciones que fijan configuración del motor.
s_1 a s_21 son mediciones hechas a distintos sensores del motor para detectar la posible falla.

Acá se pueden ver algunos de los elementos que son medidos en el motor (Pero para mí es chino).

Este dataset no contiene un vector objetivo (algo que ocurre la mayor cantidad del tiempo en la realidad). Por lo tanto vamos a contar la cantidad de ciclos que quedan hasta la falla (RUL). Sabiendo que el último ciclo de cada motor tiene un RUL cero. Creamos el RUL con la siguiente función.

def add_rul(df):
    max_cycles = df.groupby('unit_nr',as_index=False).time_cycles.max().rename(columns = {'time_cycles':'max_cycles'})
    df = (df.merge(max_cycles, on = 'unit_nr', how = 'left')
                        .assign(rul = lambda x: x.max_cycles - x.time_cycles)
                        .drop(columns = 'max_cycles'))
    return df

Al chequear la distribución del Máximo RUL por motor se tiene lo siguiente:

Número de Ciclos de Vida Promedio 205.31
STD Ciclos de Vida 46.34

Luego una buena idea es chequear si los sensores utilizados en el proceso son capaces de detectar algo cuando efectivamente el motor va a fallar. Acá algunos ejemplos:

Podemos ver que el sensor 2 tiene un aumento de su valor cuando un motor se acerca al fin de la vida útil.
El sensor 6 por otro lado es dificil de interpretar pero pareciera tener un fuerte peak antes de morir.
El sensor 14 tiene un comportamiento más disperso, algunos motores decrecen mientras que otros se incrementan, incluso algunos se mantienen.
El sensor 19 tiene una fuerte baja en el último cuarto de su vida útil.

Si chequean el notebook verán que algunos sensores como el 1, 5, 10, 16, 18 y 19 no aportan información.

Datos de Validación

En este caso, la data de validación viene en dos archivos: El primero, un Test set muy similar al de entrenamiento con 100 motores y sus variables predictoras. Y un segundo archivo el cual contiene el valor real del RUL para el último ciclo de vida en el Test set. Cabe destacar que ha diferencia del train set, el test set contiene un número de ciclos que no necesariamente representa la vida completa del motor. Y ahí radica la tarea, generar una buena estimación del RUL para la última medición a los sensores. El formato de estos datos es similar al de entrenamiento y se puede importar así:

df_test = pd.read_csv('../assets/CMAPSSData/test_FD001.txt', sep = '\s+', header = None, names = col_names)
rul = pd.read_csv('../assets/CMAPSSData/RUL_FD001.txt', sep = '\s+', header = None, names = ['RUL'])

Por lo tanto, en el caso que queramos predecir utilizando el test set en modelos Shallow de Machine Learning (no Deep Learning) predeciremos en este set:

df_test.groupby('unit_nr', as_index=False).last()

	unit_nr	time_cycles	setting_1	setting_2	setting_3	s_1	s_2	s_3	s_4	s_5	...	s_12	s_13	s_14	s_15	s_16	s_17	s_18	s_19	s_20	s_21
0	1	31	-0.0006	0.0004	100.0	518.67	642.58	1581.22	1398.91	14.62	...	521.79	2388.06	8130.11	8.4024	0.03	393	2388	100.0	38.81	23.3552
1	2	49	0.0018	-0.0001	100.0	518.67	642.55	1586.59	1410.83	14.62	...	521.74	2388.09	8126.90	8.4505	0.03	391	2388	100.0	38.81	23.2618
2	3	126	-0.0016	0.0004	100.0	518.67	642.88	1589.75	1418.89	14.62	...	520.83	2388.14	8131.46	8.4119	0.03	395	2388	100.0	38.93	23.2740
3	4	106	0.0012	0.0004	100.0	518.67	642.78	1594.53	1406.88	14.62	...	521.88	2388.11	8133.64	8.4634	0.03	395	2388	100.0	38.58	23.2581
4	5	98	-0.0013	-0.0004	100.0	518.67	642.27	1589.94	1419.36	14.62	...	521.00	2388.15	8125.74	8.4362	0.03	394	2388	100.0	38.75	23.4117
...	...	...	...	...	...	...	...	...	...	...	...	...	...	...	...	...	...	...	...	...	...
95	96	97	-0.0006	0.0003	100.0	518.67	642.30	1590.88	1397.94	14.62	...	522.30	2388.01	8148.24	8.4110	0.03	391	2388	100.0	38.96	23.4606
96	97	134	0.0013	-0.0001	100.0	518.67	642.59	1582.96	1410.92	14.62	...	521.58	2388.06	8155.48	8.4500	0.03	395	2388	100.0	38.61	23.2953
97	98	121	0.0017	0.0001	100.0	518.67	642.68	1599.51	1415.47	14.62	...	521.53	2388.09	8146.39	8.4235	0.03	394	2388	100.0	38.76	23.3608
98	99	97	0.0047	-0.0000	100.0	518.67	642.00	1585.03	1397.98	14.62	...	521.82	2388.02	8150.38	8.4003	0.03	391	2388	100.0	38.95	23.3595
99	100	198	0.0013	0.0003	100.0	518.67	642.95	1601.62	1424.99	14.62	...	521.07	2388.05	8214.64	8.4903	0.03	396	2388	100.0	38.70	23.1855

100 rows × 26 columns

Lo cuál nos regresa 100 registros, el último para cada motor.

Modelamiento

Todo el proceso de modelamiento será utilizando las tecnologías que me gustan, es decir, DVC, Scikit-Learn y Pytorch Lightning cuando corresponda. Además el código será en formato Script. Voy a entrar en detalle de ciertas partes del código. Para todo lo demás incluiré al final un Colab con los pasos para analizar los resultados finales. También disponibilizaré los Scripts utilizados para que puedan analizarlos.

El Colab añadido tiene sólo comandos que capaces de reproducir el código. Mayoritariamente serán comandos de DVC. Cada uno de estos comandos irán llamando a los distintos Python Scripts según correspondan. Si realmente te interesa empezar a embarrarte las manos con códigos deberás investigar dichos Scripts.

Modelo Baseline: La querida Regresión Lineal

Lo primero a definir es la configuración que utilizaremos:

from pathlib import Path

import yaml

with open('params.yaml') as f:
    params = yaml.safe_load(f)

class Config:
    RANDOM_SEED = params['base']['random_seed']
    ASSETS_PATH = Path('assets')
    DATA_PATH = ASSETS_PATH / 'CMAPSSData'
    TRAIN_FILE =  DATA_PATH/ params['import']['train_name']
    TEST_FILE = DATA_PATH / params['import']['test_name']
    RUL_FILE = DATA_PATH / params['import']['rul_name']
    FEATURES_PATH = ASSETS_PATH / 'features'
    MODELS_PATH = ASSETS_PATH / 'models'
    METRICS_PATH = ASSETS_PATH / 'train_metrics.json'
    VAL_METRICS_PATH = ASSETS_PATH / 'val_metrics.json'
    TEST_METRICS_PATH = ASSETS_PATH / 'test_metrics.json'

Con esto definimos parámetros de reproducibilidad, nuestros Paths de Input de Datos, y carpetas intermedias para almacenar features, modelos y métricas. Todos los parámetros utilizados acá son definidos en mi params.yaml el cual pueden ver en Colab.

1era Etapa: Featurize

import pandas as pd
from config import Config
import yaml
from utils import add_rul

with open('params.yaml') as f:
    params = yaml.safe_load(f)['featurize']

#======================================================
# importing files
#======================================================

Config.FEATURES_PATH.mkdir(parents=True, exist_ok=True)

col_names = params['index_names'] + params['setting_names'] + params['sensor_names']

df_train = pd.read_csv(Config.TRAIN_FILE, sep = '\s+', header = None, names = col_names)
df_test = pd.read_csv(Config.TEST_FILE, sep = '\s+', header = None, names = col_names)
rul_test = pd.read_csv(Config.RUL_FILE, sep = '\s+', header = None, names = ['rul'])


#======================================================
# defining features
#======================================================

df_train = add_rul(df_train)
train_features = df_train[params['sensor_names']]
train_labels = df_train.rul

test_features = df_test.groupby('unit_nr').last()[params['sensor_names']]
test_labels = rul_test

#======================================================
# Export Files
#======================================================

train_features.to_csv(Config.FEATURES_PATH / 'train_features.csv', index = None)
train_labels.to_csv(Config.FEATURES_PATH / 'train_labels.csv', index = None)

test_features.to_csv(Config.FEATURES_PATH / 'test_features.csv', index = None)
test_labels.to_csv(Config.FEATURES_PATH / 'test_labels.csv', index = None)

La etapa featurize básicamente crea la carpeta features, la cual guardará las features que eventualmente se creen.
Importa train, test y rul y realiza lo siguiente:
- Define variables a utilizar de acuerdo al parámetro sensor_names. O sea se están utilizando sólo variables del Sensor 1 al 21, sin importar si éste aporta o no información.
- Agrega el RUL para el set de entrenamiento.
- Calcula las features de test (como se mostró en el Notebook).
- Guarda por separados train y test features además de train y test labels.

2da Etapa: Train

from config import Config
import pandas as pd

import joblib
from sklearn.linear_model import LinearRegression
from sklearn.model_selection import KFold
from sklearn.metrics import mean_squared_error, mean_absolute_error, r2_score
import numpy as np
import json
import yaml
import logging

log = logging.getLogger("Training")
Config.MODELS_PATH.mkdir(parents=True, exist_ok=True)

with open('params.yaml') as f:
    params = yaml.safe_load(f)['train']

train_features = pd.read_csv(Config.FEATURES_PATH / 'train_features.csv')
train_labels = pd.read_csv(Config.FEATURES_PATH / 'train_labels.csv')
print(train_features.shape)
print(train_labels.shape)

model = LinearRegression()

#======================================================
# Validation Metrics
#======================================================
folds = KFold(n_splits=params['n_split'], 
                shuffle=True, 
                random_state=Config.RANDOM_SEED)

mae = np.zeros(5)
rmse = np.zeros(5)
r2 = np.zeros(5)

for fold_, (train_idx, val_idx) in enumerate(folds.split(X = train_features, y = train_labels)):
    log.info(f'Training Fold: {fold_}')
    
    X_train, X_val = train_features.iloc[train_idx], train_features.iloc[val_idx]
    y_train, y_val = train_labels.iloc[train_idx], train_labels.iloc[val_idx]
    
    model.fit(X_train, y_train)
    val_preds = model.predict(X_val)
    val_mae = mean_absolute_error(y_val, val_preds)
    val_rmse = mean_squared_error(y_val, val_preds, squared=False)
    val_r2 = r2_score(y_val, val_preds)
    
    mae[fold_] = val_mae
    rmse[fold_] = val_rmse
    r2[fold_] = val_r2
    log.info(f'Validation MAE for Fold {fold_}: {val_mae}')
    log.info(f'Validation RMSE for Fold {fold_}: {val_rmse}')
    log.info(f'Validation R2 for Fold {fold_}: {val_r2}')

val_metrics = dict(validation = dict(val_mae = mae.mean(), 
                                    val_rmse = rmse.mean(), 
                                    val_r2 = r2.mean())
                    )

log.info('Saving Validation Metrics')
with open(Config.VAL_METRICS_PATH, 'w') as outfile:
    json.dump(val_metrics, outfile)

#======================================================
# Retrain Model
#======================================================
log.info('Model Retraining')
model.fit(train_features, train_labels)
joblib.dump(model, Config.MODELS_PATH / params['model_name'])

Esta segunda etapa realiza lo siguiente:

Crear el directorio de Modelos.
Cargar features y Labels de Entrenamiento.
Instanciar el Modelo, en este caso una Regresión Lineal.
Instanciar un proceso de KFold.

Es importante que hay formas muchas más sencillas de hacer un KFold. Entre ellas está utilizar cross_val_score(), cross_validate(), o el mismo GridSearchCV. Estoy acostumbrándome más a esta forma ya que si bien es más verbosa es muchísimo más flexible para formas de modelación más raras.

Entrenar el Modelo en esquema de Validación y calcular R², RMSE y MAE de Validación.
Se reentrena el modelo en toda la data y se guarda el modelo como .joblib.

3era Etapa: Evaluate

import json
import joblib
from sklearn.metrics import mean_absolute_error, mean_squared_error, r2_score
import pandas as pd
from utils import plot_oof, plot_importance
from config import Config

Config.IMAGE_PATH.mkdir(parents=True, exist_ok=True)

X_test = pd.read_csv(Config.FEATURES_PATH / 'test_features.csv')
y_test = pd.read_csv(Config.FEATURES_PATH / 'test_labels.csv')

model = joblib.load(Config.MODELS_PATH / 'model.joblib')
y_pred = model.predict(X_test)

#======================================================
# Metrics
#======================================================

test_metrics = dict(test = dict(test_mae = mean_absolute_error(y_test, y_pred),
                                test_rmse = mean_squared_error(y_test, y_pred, squared=False),
                                test_r2 = r2_score(y_test, y_pred))
                    )

with open(Config.TEST_METRICS_PATH, 'w') as outfile:
    json.dump(test_metrics, outfile)
    
#======================================================
# Other Evaluation Curves
#======================================================

plot_oof(y_test, y_pred, s = 10, path = Config.IMAGE_PATH / 'F_vs_t.png')
plot_importance(model, X_test.columns, path = Config.IMAGE_PATH / 'Feature_Importance.png')

Esta etapa final es más cortita, por lo que sólo realizaremos lo siguiente:

Se crea la carpeta de Imágenes para guardar las Curvas de Interés.
Se carga la data de test.
Se carga el modelo entrenado.
Se calculan las mismas métricas pero ahora para validación.
Se calculan una curva OOF para chequear qué partes son las que más falla el modelo.

Si quieres correr todo este proceso puedes usar este Google Colab.

Siguientes Pasos

Está claro que este no puede ser nuestro modelo final.

No hemos limpiado variables que no aportan.
No hemos creado variables nuevas.
No hemos probado otros approaches.
No hemos probado otros modelos.

En la parte 2 iremos agregando algunas de estas mejoras.

Entonces, la idea ahora es desafiarlos. ¿Qué tal nos dio el modelo? ¿Es bueno o es malo? ¿Se puede determinar algún grado de sobreajuste? Ojalá puedas ir comentando lo que pudiste revisar y vamos a ir dejando desafio mayores en cada parte.

Si les gustó la modalidad, y aprendieron algo nuevo, por fa denme una estrellita en el Repo.

Hasta la otra!!

Alfonso

Implementando DeepAnt

2022-08-08T00:00:00+00:00

Bueno, como les comenté en los post anteriores, mi tema de investigación está siendo el uso de Anomalías en Series de Tiempo utilizando Deep Learning. Por lo que comencé por implementar mi primer Paper y publicándolo en Papers with Code por lo que les agradecería encarecidamente que si aprendieron algo nuevo me dieran una estrellita en el Github para que gane popularidad.

Además, creo que gran parte del valor de un tutorial es que puedan reproducirlo, por lo que de ahora en adelante podrán reproducirlo sin casi nada de configuración en Google Colab. Sólo clickeen en Open in Colab e instalen las dependencias. Perdón que el Notebook esté en Inglés pero lo estoy usando como parte de la publicación en Papers with Code. Prometo que otros estarán en español.

El código completo lo encontrarán en el Notebook, por lo que sólo incluiré el código más interesante a explicar.

DeepAnt

Bueno DeepAnt es un algoritmo de Detección de Anomalías en series de tiempo. Su principal usi es detectar comportamiento anormal de una medición en el tiempo de manera no supervisada, es decir, no tenemos etiquetas para validar qué partes de las series de tiempo son anómalas o no. Esto es particularmente importante debido a que las anomalías son raras, no tenemos cómo saber a priori cómo son y cómo se ven. Algunas de las principales aplicaciones de la Detección de Anomalías son Detección de Fraude, comportamientos inusuales, etc.

En este caso lo que haremos es reproducir el algoritmo en uno de los dataset de prueba utilizados en el paper. Este dataset chequea el tiempo de demora en tráfico en Minnesota, y la tarea es detectar cuáles de esos tiempos son son correctos.

Para ello DeepAnt propone una arquitectura utilizando Redes Convolucionales de 1 dimensión para análisis de secuencias. Lo más común para resolver este tipo de problemas es utilizar redes recurrentes pero en este caso, las redes convolucionales funcionan bastante bien.

Obviamente lo común es pensar que las Redes Convolucionales se utilizan sólo en Imágenes, pero una Red Convolucional de 1D es como una imagen pero sin alto, solo con ancho.

Investigando y adentrándome más en el tema se definen 3 tipos de algoritmos para la detección de Anomalías: Forecast Based, Reconstruction Based y mixtos. DeepAnt es ForecastBased, lo que quiere decir que va a intentar predecir uno más a puntos con la hipótesis que valores anómalos serán más dificiles de predecir. Luego las predicciones pasarán por una métrica de error, este caso Norma L2, Los puntos con más error serán considerados anomalías.

Si quieres conocer cómo funciona uno Reconstruction Based, puedes ir acá.

La métrica L2 se define como:

\[L2 = ||y_{pred}-y||_2 = \sqrt{(y_{pred}-y)^2}\]

Data

Al revisar nuestra data nos encontramos con esto:

df = pd.read_csv('data/TravelTime_451.csv', index_col = 'timestamp', parse_dates=['timestamp'])
df.plot(figsize = (15, 6), title = 'Travel Time', legend = False);

Se puede ver claramente que la data tiene unos peaks que podrían ser eventualmente inusuales.

Para el entrenamiento del modelo el Paper propone crear minisecuencias, supongamos que tenemos una series de Tiempo TS de 5 Puntos:

\[TS = \{x_1, x_2, x_3, x_4, x_5\}\]

Por ejemplo, las secuencias $S_i$ de largo 2 serían así:

\[S_i = \{x_{i-2}, x_{i-1}\} \rightarrow x_i\]

Es decir, el punto $x_i$ se trataría de predecir con los dos puntos inmediatamente anteriores.

Esto podemos implementarlo en Pytorch de la siguiente manera:

class TrafficDataset(Dataset):
    def __init__(self, df, seq_len):
        self.df = df
        self.seq_len = seq_len
        self.sequence, self.labels, self.timestamp = self.create_sequence(df, seq_len)

    def create_sequence(self, df, seq_len):
        sc = MinMaxScaler()
        index = df.index.to_numpy()
        ts = sc.fit_transform(df.value.to_numpy().reshape(-1, 1))
        
        sequence = []
        label = []
        timestamp = []
        for i in range(len(ts) - seq_len):
            sequence.append(ts[i:i+seq_len])
            label.append(ts[i+seq_len])
            timestamp.append(index[i+seq_len])
            
            
        return np.array(sequence), np.array(label), np.array(timestamp)
    
    def __len__(self):
        return len(self.df) - self.seq_len
    
    def __getitem__(self, idx):
        return (torch.tensor(self.sequence[idx], dtype = torch.float).permute(1, 0), 
                torch.tensor(self.labels[idx], dtype = torch.float))

El método create_sequence() creará la secuencia escalada en el rango [0.1]. Hacer este preprocesamiento genera más estabilidad en el entrenamiento. Además se crea la etiqueta a utilizar dependiendo del SEQ_LEN dado. Además guardaremos el timestamp asociado a la etiqueta para poder identificar dónde ocurren las anomalías. El resto corresponde a la estructura de Pytorch Dataset para incluirlo posteriormente en los DataLoaders.

Luego, viene el DataModule. Este permitirá indicar el proceso de entrenamiento:

class DataModule(pl.LightningDataModule):
    def __init__(self, df, seq_len):
        super().__init__()
        self.df = df
        self.seq_len = seq_len
    def setup(self, stage=None):
        self.dataset = TrafficDataset(self.df, self.seq_len)
        
    def train_dataloader(self):
        return DataLoader(self.dataset, batch_size = 32, num_workers = 10, pin_memory = True, shuffle = True)
    
    def predict_dataloader(self):
        return DataLoader(self.dataset, batch_size = 1, num_workers = 10, pin_memory = True, shuffle = False)

En este caso sólo tenemos dos DataLoaders idénticos excepto por el batch size: 32 para entrenar con shuffle, y 1 para predecir. Sólo por un tema de organizar las predicciones de manera más fácil (y sin shuffle).

Luego la Arquitectura de DeepAnt:

class DeepAnt(nn.Module):
    def __init__(self, seq_len, p_w):
        super().__init__()
        
        self.convblock1 = nn.Sequential(
            nn.Conv1d(in_channels=1, out_channels=32, kernel_size=3, padding='valid'),
            nn.ReLU(inplace=True),
            nn.MaxPool1d(kernel_size=2)
        )
        
        self.convblock2 = nn.Sequential(
            nn.Conv1d(in_channels=32, out_channels=32, kernel_size=3, padding='valid'),
            nn.ReLU(inplace=True),
            nn.MaxPool1d(kernel_size=2)
        )
        
        self.flatten = nn.Flatten()
        
        self.denseblock = nn.Sequential(
            nn.Linear(32, 40),
            #nn.Linear(96, 40), # for SEQL_LEN = 20
            nn.ReLU(inplace=True),
            nn.Dropout(p=0.25),
        )
        self.out = nn.Linear(40, p_w)
        
    def forward(self, x):
        x = self.convblock1(x)
        x = self.convblock2(x)
        x = self.flatten(x)
        x = self.denseblock(x)
        x = self.out(x)
        return x

Como se puede ver se compone de 3 Bloques + la salida:

2 Bloques Convolucionales de 32 Filtros con una Capa Convolucional 1D Relu y MaxPool1D. El Kernel Convolucional es 3x3, mientras que el Pooling es 2x2.
Una capa flatten para conectar con la Capa Densa.
Una capa Hidden de 40 Neuronas más Relu y Dropout de 25%.
Finalmente la capa de Predicción con salida p_w. El paper indica que de predecir anomalías puntuales se usa p_w = 1, que es el caso implementado. En caso de predecir secuencias se puede usar p_w, con el correspondiente ajuste a la creación de secuencias.

Finalmente el LightningModule:

class AnomalyDetector(pl.LightningModule):
    def __init__(self, model):
        super().__init__()
        self.model = model
        self.criterion = nn.L1Loss()
    def forward(self, x):
        return self.model(x)
    
    def training_step(self, batch, batch_idx):
        x, y = batch
        y_pred = self(x)
        loss = self.criterion(y_pred, y)
        self.log('train_loss', loss, prog_bar=True, logger = True)
        return loss
    def predict_step(self, batch, batch_idx):
        x, y = batch
        y_pred = self(x)
        return y_pred, torch.linalg.norm(y_pred-y)
    
    def configure_optimizers(self):
        return torch.optim.Adam(self.parameters(), lr = 1e-5)

De acuerdo al Paper se entrena el modelo con MAE Loss (L1Loss en Pytorch) durante 30 epochs. Para la predicción, no nos interesa la predicción propiamente tal, sino que la Norma L2 (torch.linalg.norm(y_pred-y)), aunque también retorno la predicción en caso de necesitarla.

Análisis de los Resultados

Al momento de inferencia se grafica la distribución de Errores por Norma L2 y el error para cada punto predicho. Por inspección visual se decide que todos los puntos con error mayor a 0.5 se consideran anomalías:

Anomalies Detected: 
2015-07-29 06:49:00    0.759585
2015-07-31 10:29:00    0.504894
2015-07-31 10:39:00    0.533254
2015-07-31 10:59:00    0.509283
2015-07-31 11:09:00    0.731919
2015-07-31 11:29:00    0.665691
2015-07-31 11:39:00    0.734755
2015-07-31 11:59:00    0.815328
2015-07-31 12:09:00    0.890414
2015-07-31 12:29:00    0.904424
2015-07-31 12:33:00    0.965008
2015-08-07 06:09:00    0.947923
2015-08-11 12:07:00    0.524375
dtype: float32

Luego si marcamos los puntos encontrados en la serie de tiempo original obtenemos lo siguiente:

Bueno, no tenemos información sobre etiquetas existentes como para poder medir la performance del modelo. Esto debido a la naturaleza no supervisada del modelo. Lo que sí se indica en distintos blog post de este dataset es que existe una anomalía confirmada el día 2015-08-11 12:07:00. La cuál es difícil de detectar porque no es la más prominente de las existentes.

En este caso DeepAnt es capaz de encontrarla de manera exitosa junto con otras más.

Conclusiones

Es posible ver que DeepAnt funciona bastante bien. Es una arquitectura relativamente sencilla de realizar y su tiempo de entrenamiento e inferencia son bien bajos lo cual lo hace un modelo que puede ser de fácil implementación en producción.
Ventajas: El uso de Redes Convolucionales 1D, ya que son mucho más fáciles de entrenar que una RNN, LSTM o GRU. Su procedimiento es estándar y fácilmente explicable.
Desventajas: Debido a la naturaleza secuencial, no es posible detectar anomalías en los primeros SEQ_LEN puntos, ya que no hay data previa para el Forecast necesario.

Bueno, espero que este tipo de modelos sean útiles tanto para eventualmente implementarlos como para aprender del funcionamiento del Deep Learning en Detección de Anomalías.

Y ahora a jugar con el modelo, no hay excusa. El código está para llegar y ejecutar en Colab!!!

Alfonso

¿Qué debo aprender para ser Data Scientist?

2022-08-01T00:00:00+00:00

La ciencia de datos es una de las disciplinas más de moda hoy en día. Y cómo que por alguna razón todos quieren ser parte de ello. Sin duda en el mediano/largo plazo probablemente todas las disciplinas tendrán una componente de datos y la verdad es que vale la pena aprender a lidiar con ellos.

Hoy en día la decisión es simple, trabajar con R o con Python, pero el tema es que Python tiene 150.000+ librerías y R tiene otras tantas, por lo que a veces es abrumante pensar, tengo que aprender todo? Ojo, eso sin contar otro tipo de tecnologías de Visualización, ETL y un largo etc. Por donde empiezo, tengo un montón de opciones y no me gustaría perder el tiempo en cosas que no valen la pena.

Además, en plataformas como Linkedin siempre hay gente en cuyo título dice Data Science | Machine Learning | Analytics Expert y un largo etc. y que probablemente en su vida ha programado y comparten publicaciones como esta:

TL;DR

TOP 10 LIBRERÍAS DE PYTHON

Esta es una lista que encontré por ahí:

Pandas.
NLTK.
Plotly.
Scikit-learn.
Category-encoders (era tremenda librería pero está sin mantenimiento actualmente)
Imbalance Learning. (Esta no es ni siquiera una librería en Python, se llama Imbalanced-Learn)
XGBoost.
Keras / Tensorflow.
Theano. (Nadie usa esto ya)
Beautiful Soup.

Colocan una foto llena de logos, y un listado con nombres casi aleatorios:

A veces te indican qué librerías sí o sí tienes que saber, y nunca las has escuchado:

A veces tienen hasta errores burdos:

Y uno se pregunta ¿Con qué parto?. Y la verdad es que si bien son librerías que pueden ser útiles, hay que ver si realmente son aplicables al trabajo que haces y si vale el esfuerzo de aprenderlo.

Un Alto antes de Continuar

La ciencia de datos es una disciplina enorme. Y hay que darla paso a paso, o no vamos a lograr nada y vamos a vivir estresados de tantas cosas que no sabemos usar y que tenemos que aprender. No digo que mi caso sea el perfecto, para nada, pero yo partí así:

Business Analyst (Una especie de Data Analyst, pero enfocado en dar valor al negocio 🤭 ja ja): En mis primeros 2 años, lo que más hacía era responder preguntas con datos. El resultado, una query en SQL, la mayor parte del tiempo con una tabla exportada en Excel. Aprendí mucho SQL porque las Bases de Datos que usábamos eran gigantes y muy complejas. Responder una pregunta de negocio podía tomar 6 o 7 subqueries, con muchos joins en cada una de ellas. Luego tuve la oportunidad de crear algoritmos sencillos para aplicar lógicas de negocios, a esto le llamábamos Calculation Engines (Motores de cálculo). Y es básicamente aplicar lógicas de negocio complejas en los datos para chequear qué clientes cumplían o no regulaciones bancarias. Luego muté nuevamente a algo más BI, y me tocaba hacer dashboards en Tableau todo el día, todos los días. La data que el dashboard necesita no se ordena sola, por lo que aparte de hacer gráficos que digan algo, había que hacer mucho SQL de fondo. No fue hasta como mi tercer año de Analista que comencé a hacer una Regresión o un SVM loco por ahí. Todo esto en R.
Data Scientist: Luego de como 4 años logre un puesto de Data Scientist. Ya llevaba como 1 año haciendo modelos a escondidas, porque no era mi rol. Y acá me cambié a Python definitivamente. Tuve que aprender mucho pandas, Scikit-Learn (y los 3 grandes XGBoost, LightGBM y CatBoost) y modelar mucho. Pero con muchos errores teóricos de fondo, y ahí decidí que era importante entender el transfondo teórico. En ese tiempo leía mucho blog y veía mucho video (aún lo hago, pero ahí partí). Quizás desde el 2021 que ya me metí de lleno en el Deep Learning y acá estamos.

Todo tiene que ser progresivo. El Deep Learning es sólo una extensión del Machine Learning, en vez de hacer feature selection/engineering, acá hay que hacer “Architecture Engineering”, tratando de encontrar la arquitectura más apropiada a un problema. Por otra parte el Machine Learning es una extensión del Análisis. En vez de que tenga que analizar la data manualmente, el modelo aprende los insights por mí y a escala, pero hay que entregar data estructurada. Y el Análisis es sólo una extensión de la Manipulación de Datos. Sólo se puede entender la data una vez que la tengo ordenadita. Entonces, hay que partir de a poco, y no saltarse pasos.

Tabla de Contenidos

La idea
Manipulación de Datos
Bases de Datos
Visualizaciones
- Otras herramientas BI
Machine Learning
Deep Learning
Misceláneo
Librerías estándar que deberías usar/conocer

La idea

Trabajando como Data Scientist creo que he usado 100+ librerías y otras tecnologías, por lo que quiero hablar de cada una de ellas y dar mi opinión si vale la pena aprenderla o no. Quiero decir que en verdad llevo más tiempo usando R (cerca de 5 años) que Python (3 años), por lo que voy a tratar de dar mi opinión de ambos.

La idea nace porque siempre me pongo a rabiar cuando gente experta publica algo copiado de plataformas como Coding Dojo, Datacamp, etc. con información incompleta y recomendando librerías que nunca han usado (y hoy yo también voy a hacer eso 🤭😅). Entonces decidí que quiero hacer un compendio de las tecnologías más famosas que hay relacionadas a la ciencia de datos.

El compendio incluirá lo siguiente:

Todas las librerías/tecnologías que he utilizado previamente.
Sólo en ocasiones excepcionales listaré librerías que no he utilizado cuando ocurra algunos de los siguientes casos:
- Están en mi lista de estar próximo a usarla y si bien no tengo proyectos con ellas ya me he adentrado en su documentación.
- Son demasiado famosas para dejarlas fuera.

Principalmente mencionaré librerías de Python, porque es el estado del arte en Ciencia de Datos y algunas librerías de mi tiempo usando R.

Además me dí la lata de recorrer los 5000 paquetes más descargados en PyPI para recomendar librerías de Python, por lo que en el caso de que corresponda indicaré el Ranking y el número de descargas al 01-07-2022. Debo advertir que puedo estar un poco desactualizado en R porque dejé de usarlo definitivamente desde fines del 2019. Además cuando corresponda voy a mencionar otras tecnologías fuera de R o Python que quizás vale la pena conocer cuando se trabaja en ciertas áreas de la Ciencia de Datos.

Librerías de Python incluirán Ranking en PyPI (Rk) y número de descargas (ND).
Librerías de R irán acompañadas de un indicador (R).
Otras Técnologías que no son librerías ni de R ni de Python llevarán una (O) de Otras.

Voy además dividirlas en Prioridades:

1: Definitivamente debes aprenderlas y empezar a utilizarlas ya. En el caso de R debes aprenderla ya, pero sólo si usas R.
2: Dependiendo del caso (si trabajas con tecnologías anexas) podría ser una buena opción.
0: No pierdas tu tiempo en aprenderlas. No porque sea mala, sino que la vas a necesitar de manera muy esporádica, por lo que hay que saber qué puede hacer, para qué sirve y puede que en algún momento de la vida una que otra función sea útil.

Finalmente, dividiré todas las recomendaciones en las siguientes categorías:

Manipulación de Datos,
Bases de Datos,
Machine Learning,
Deep Learning,
Misceláneo.
Librerías Estándar

Esta lista no es exhaustiva y si alguien quiere contribuir ayudando a reclasificar esto estoy abierto a sugerencias y colaboraciones.

Disclaimer: Todas las librerías que mencionaré son excelente en lo que hacen. Si recomiendo no aprenderlas no es porque sean malas (a menos que lo diga), es sólo que muy rara vez necesitarás utilizarlas debido a que son demasiado específicas y no vale la pena enfocarse en ellas. Basta con leer la documentación un rato antes de utilizarla y saber que existe.

Finalmente el objetivo final de este compendio es que los nuevos Data Scientists (y también los más experimentados) puedan tener una opinión de qué librerías existen y cuáles sí o sí deberían dominar.

Manipulación de Datos

SQL ((O), Pr: 1): Si bien esta no es una librería de Python/R, esto es por lejos lo primero que todo Data Scientist debe saber. No es necesario ser un ultra experto en este tema pero sí al menos debes dominar los siguientes aspectos:
SELECT/FROM
JOINS: Entender las principales diferencias entre LEFT, RIGHT, INNER, SELF JOINS.
WHERE, GROUP BY, HAVING.
ORDER BY
MIN,MAX, AVG, etc.
CREATE (volatile, temporary) TABLE, INSERT INTO, WITH (Esto es bien difuso ya que depende del motor).
Entender al menos los motores más populares que son por lejos MySQL y Postgresql.

Es muy triste ver gente que se hace llamar Data Scientist y no sabe hacer una query. Sin datos, no hay Científico de Datos, por lo que sí o sí dale a esto primero que cualquier otra cosa!!

Pandas (Rk: 31, ND: 86M+, Pr: 1): Esta es por lejos la librería más utilizada en Ciencia de Datos y para mi gusto la más completa. No está en el primer lugar porque realmente creo que es más importante saber SQL primero ya que es mucho más simple. Básicamente Pandas es un SQL con Esteroides, muchísimo más poderosa y que bajo ningún motivo puede ser reemplazada por SQL. Pero tiene tantos comandos que al principio uno podría no saber cómo empezar. Su API es tan buena que existen muchos mirrors, como Dask, koalas, o cuDF, que siguen la misma convención sólo que el backend hace algo distinto (Básicamente aprendiendo pandas se pueden aprender varias librerías a la vez). Mi recomendación es aprender cómo reproducir todo lo aprendido en SQL y luego aprender funciones para resolver problemas específicos. ¿Cómo aprender? Lo mejor es a través del User Guide en su propia documentación.
Numpy (Rk: 15, ND: 110M+, Pr: 0): Numpy es una librería de computación científica, esto quiere decir, computar/calcular implementaciones matemáticas/estadísticas desde test de hipótesis, Transformadas de Fourier, y un largo etc. Normalmente se recomienda aprender antes o junto a Pandas, pero realmente creo que (prepárense) no vale la pena aprenderla inicialmente. Hace unos años era necesario aprender numpy para complementar pandas, ya que habían muchas cosas que no estaban disponibles en pandas pero sí en Numpy, pero si es que no vas a hacer implementaciones directamente de Algebra Lineal, no va a ser necesario usarla. Obviamente cuando uno es avanzado se dará cuenta que es bueno entender conceptos de Numpy como la vectorización. Mi recomendación es aprender sólo funciones que no están en pandas a medida que las vayas necesitando.

A varios les puede llamar la atención que tiene más descargas que Pandas, pero la explicación es sencilla. Muchas librerías tiene como dependencia Numpy, Scikit-Learn, Matplotlib, pandas, y un largo etc, que hace obligatorio siempre tenerla instalada.

Scipy (Rk: 65, ND: 42M+, Pr: 0): Este es un pedacito de Numpy aún más específico. Definitivamente no vale la pena aprenderlo, y sólo se necesitarán funciones muy específicas. En mi caso sólo la he usado para utilizar matrices sparse cuando queremos disminuir el tamaño de matrices con demasiados ceros y cuando enseñé probabilidad, porque tiene todas las distribuciones de probabilidad (incluso si son muy raras) con sus respectivas funciones para muestreos, pmf, pdf y cdf.
dplyr ((R), Pr: 1): Diría que es la versión en R de pandas, pero es un poco más limitado. No porque no tenga las capacidades para hacer lo que pandas hace sino porque el ecosistema de R está disperso en más paquetes. Para emular pandas en R se tiene que usar casi todo el tidyverse: dplyr, tidyr, lubridate y hms (para fechas), forecats (para variables categóricas), purrr (para loops eficientes), readr + vroom para io, stringr y stringi para lidiar con strings. Creo que el uso del pipe (%>%) hace que el código en R sea más expresivo que en pandas y realmente vale la pena aprender este ecosistema si trabajas en R ya que es mucho más amigable que la sintaxis de R puro.
Dask (Rk: 390, ND: 5.6M+, Pr: 0): Corresponde al motor que provee paralelismo para Pandas. La librería es excelente pero bajo ningún motivo vale la pena invertir tiempo acá, porque básicamente es la misma interfaz de pandas. Basta con hacer import dask.dataframe as dd y anteponer dd en vez de pd y listo. No he tenido que usar nunca esta librería pero es demasiado famosa para no mencionarla.
data.table (R principalmente pero creo que también está en Python, Pr: 0): Este es un tema polémico porque hace mucho tiempo había una discusión entre el creador de esta librería y la gente de RStudio. Básicamente data.table es la librería más rápida para manejo de datos en R pero su sintaxis no es muy amigable. Afortunadamente Hadley Wickham creo dtplyr que permite usar data.table como el backend de dplyr, por lo que diría que si bien esta librería es extremadamente poderosa no vale la pena aprenderla si sabes dplyr.
cudf (Rk: NA, ND: NA, Pr: 0): cuDF es una librería que es parte de RAPIDS, un set de paquetes en Python desarrollado por NVIDIA que permiten ejecutar todo en GPU. Este es el mirror de Pandas, básicamente la misma sintaxis que pandas pero que en el backend se ejecuta en GPU. No vale la pena apenderla, ya que es igual a pandas.
cupy (Rk: NA, ND: NA, Pr: 0): Es el Mirror en este caso de Numpy. Si sabes numpy entonces sabes cupy, no debería estar dentro de tus prioridades como Data Scientist. Pero en el caso de querer lanzar tus procesos a la GPU es excelente.

Estas librerías no deberían ser la mejor opción para trabajar con grandes volumentes de datos. Esto porque normalmente la GPU tiene menos RAM, a menos que tengas varias GPU o una RTX3090. La mayoría del tiempo utilizar pandas va a ser más que suficiente.

pyspark (Rk: 127, ND: 23.9M+, Pr: 0): Este es la librería por excelencia para trabajar con Big Data. pyspark es el cliente de Python para el Spark de Scala. Lo bueno de esta librería es que te da la opción de usar una API muy similar al Spark en Scala o incluso una que utiliza comandos tipo SQL. Esta va a ser la mejor opción para cuando tengas que trabajar con Big Data y computación distribuida en un Cluster, pero NO VALE LA PENA APRENDERLO. Principalmente porque la interfaz de SQL te servirá la mayor cantidad del tiempo para llevar a cabo ETLs y en caso de procesamiento más rebuscado koalas es un mirror de pandas para ejecutar Spark.
findspark (Rk: 729, ND: 2.4M+, Pr: 0): Tan enredada es la instalación de Spark que se creó una librería para tener el path de instalación y poder levantar un Cluster local. Sólo sirve para eso.
koalas (Rk: 1047, ND: 1.4M+, Pr: 0): Si tienes que usar Spark yo creo que es mejor koalas, que tiene la sintaxis de pandas que uno ya sabe. No es necesario aprender nada nuevo.
sparklyr ((R), Pr: 2): La única vez que tuve que trabajar con data en Spark fue en Python y usé koalas. Pero vale la pena mencionar esta librería porque básicamente permite ejecutar Spark usando sintaxis de dplyr. Si es que llegaras a necesitar Spark, mi recomendación sería hazlo en otro lenguaje (principalmente por los problemas de memory leakage de R) pero si necesitas hacerlo en R, esta es la mejor opción.
NetworkX (Rk: 147, ND: 20M+, Pr: 2): Es una librería de manipulación de datos, pero en forma de grafos. No la he usado más que para calcular métricas de centralidad (closeness, betweeness, degree, etc). Pero es probable que comience a utilizarla más.
Microsoft Excel ((O), Pr: 1): Excel nunca debería ser una opción para trabajar con Datos, pero sí o sí tienes que saber usarlo porque lamentablemente los archivos .xlsx son todavía un formato extremadamente popular. NUNCA deberías utilizar Excel si no es sólo para entregar resultados. Si tú eres de los que aún dice que hay cosas que son más sencillas en Excel que en Pandas o SQL, es que no sabes utilizar bien esas tecnologías aún.

Bases de Datos

sqlalchemy (Rk: 49, ND: 49M+, Pr: 1): Esta es por lejos una de las mejores librerías que se han creado en Python. Básicamente permite utilizar cualquier Base de Dato SQL con una interfaz común. Debo decir que si bien esta es una librería extremadamente poderosa y que vale completamente la pena aprender, la documentación está pensada para gente bien “computín” y no es tan amigable. Mi recomendación para aprenderla es mediante videos tutoriales. Ahora en Ciencia de Datos la vas a ocupar sí o sí si eres Data Engineer para poder modelar Bases de Datos o hacer consultas. Como Data Scientist normalmente sólo la usarás como forma de conexión con Pandas mediante create_engine y .to_sql() para extraer datos.
sqlmodel (Rk: 4085, ND: 90K, Pr: 2): Esta es una librería creada hace muy poco por el gran Sebastián Ramírez (Tiangolo). No he utilizado esta librería pero sí sé que está construida sobre sqlalchemy. sqlmodel es a sqlalchemy lo que FastAPI es a Flask. Por lo tanto, es muy posible que en el tiempo esta librería venga a reemplazar a SQLAlchemy principalmente porque Tiangolo dedica mucho tiempo a la buena documentación y casos de usos, cosa que SQLAlchemy no tiene tan bien hecho en mi opinión.
DBI ((R), Pr: 1): DBI viene a ser una interfaz común para poder consultar datos. Creo que podría considerarse el símil de sqlalchemy, pero no sé si tiene tantas funcionalidades. Al menos esta siempre fue mi opción para conectarme a DBs en R, pero nunca me tocó modelar una base de datos como sí tuve que hacerlo en Python. DBI tiene conexión con casi todos los motores de SQL o usando conexión odbc.
PyMongo (Rk: 185, ND: 16.8M+, Pr: 2): Esta es la interfaz para utilizar MongoDB desde Python. MongoDB es probblemente la base de datos no relacional más famosa. Sólo vale la pena si es que te toca trabajar con MongoDB pero lo bueno es que su uso es sumamente intuitivo. Utiliza la misma sintaxis que MongoDB pero en vez de usar el formato BSON (que es como un tipo de JSON), lo hace en los diccionarios de Python. Y por cierto, hacer queries en MongoDB es básicamente SQL con otra sintaxis y permitiendo data no estructurada como output, por lo que aprenderla es bastante sencillo.
elasticsearch-dsl (Rk: 732, ND: 2.4M+, Pr: 2): Este no es la librería más popular para conectarse a ElasticSearch, que es un motor de base de datos basado en documentos que es extremadamente rápida. La sintaxis en ElasticSearch es horrible, y yo reconozco que no tengo idea como extraer datos usando ElasticSearch puro. El tema es que elasticsearch-dsl es tan intuitivo que pude generar procesos de ETL en ElasticSearch utilizando esta librería, ya que su API es como estilo dplyr (aunque es una librería de Python), lo que le permite ser muy expresiva y fácil de crear, leer y entender. Si alguna vez tienes que trabajar con ElasticSearch, usa esta librería ya que es muchísimo más sencilla.
psycopg2 (Rk: 194 y 99, ND: 31M + 15M, Pr: 0): El Ranking de esta librería es un poco extraño, la razón es porque si utilizas Windows descargas psycopg2, pero si tienes Mac o Linux descargas psycopg2-binary, por lo que en estricto rigor esta librería es la suma de ambos. Este es el cliente de Postgresql en Python, un motor de base de datos extremadamente popular y poderoso. Es una interfaz muy parecida a DBI en R. Es un cliente lowlevel y bien rápido para poder interactuar con DBs Postgres. Yo la he utilizado como motor tanto para DBs Postgres Puras o para Datawarehouse como Redshift que están basadas en Postgres. Además se puede conectar con sqlalchemy, por lo que diría que no es necesario aprender mucho su sintaxis porque saber sqlalchemy ya hace la pega.
pyodbc (Rk: 161, ND: 19M, Pr: 0): Es una librería que nos permite hacer conexiones ODBC. Esta librería la usé únicamente en Windows para conectarme con Teradata que es un motor de Base de Datos que suele ser utilizado en entornos de alta seguridad como Bancos o Retail (mi recomendación: no usen Teradata, funciona bien, es rápido y todo pero su documentación al no ser código abierto es pésima, por lo que cosas fáciles se pueden hacer pero encontrar cómo hacer algo fuera de la común es casi imposible. Se los dice alguien que lo usó por 5 años). Normalmente se utiliza una línea para conectarse y es compatible con sqlalchemy, por lo que no es necesario aprender mucho.
Neo4J ((O), Pr: 2): Debo decir que este tipo de bases de Grafo cambió demasiado mi manera de ver el almacenamiento de datos. Creo, luego de pelear con hartos motores de datos no estructurado que, este es la manera más sencilla de interactuar con datos NoSQL. Entre sus grandes pro está el hecho de que su sintaxis es muy fácil de aprender (parecida a SQL, pero no igual), es rápido, y no requiere joins.
rasterio (Rk: 1454, ND: 749K+, Pr: 0): Esta es una librería para trabajar con rasters. Rasters son las típicas imágenes donde cada píxel está representado como un valor en una matriz/tensor. En el caso de rasterio, tiene más utility functions para trabajar con imágenes satélitales pero en general se utiliza como complemento a otras librerías. Normalmente se utiliza una que otra función.
Xarray (Rk: 1454, ND: 749K+, Pr: 0): No sé si saben pero antiguamente pandas (que deriva de PAnel DAta ), tenía data panel, que es son varias realizaciones en el tiempo de un DataFrame, o sea un Pandas de 3 dimensiones. Bueno eso hace un tiempo se quitó de pandas y si querías más de 3 dimensiones necesitabas Numpy. Bueno Xarray permite la data panel, 3 Dimensiones, pero con nombre del nombres de array. Es una extensión que permite por ejemplo trabajar mejor con Imágenes Multiespectrales (ya que queda capa tiene un significado: RGB, Infrarrojo Cercano, Infrarrojo Lejano, etc.) y normalmente se combinan para poder crear índices y falsos colores para destacar ciertos aspectos de la imágen. Es una librería súper específica, por lo que sólo será útil cuando necesites trabajar con este tipo de datos.
Geopandas (Rk: 733, ND: 2.4M+, Pr: 2): Esta es una extensión de Pandas, que incluye dos cosas interesantes a mi gusto, el incorportar shapes: Puntos, Polígonos, etc. Y el hecho de tener joins espaciales. De esta manera puedes combinar datasets si es que comparten mismo espacio, por ejemplo: Tienes puntos (coordenadas) de casas en un csv y tienes polígonos de regiones en otro csv. Al hacer join espacial, unirá los registros de casas que están dentro del polígono región igual que un join. El tema es que hay varios tipos de join espaciales: dentro, que colinden, que se intersecten, etc. Excelente librería, y no muy dificil de aprender.
Scikit-Image (Rk: 325, ND: 8.6M+, Pr: 0): Esta es una librería de manipulación de Imágenes, muy parecida a OpenCV. Yo la usé una sola vez para intentar reconstruir una foto que rompí por error. Bien intuitiva tiene muchas built-in functions para manipular imágenes.
Spacy (Rk: 475, ND: 5.1M+, Pr: 0): Esta es una tremenda librería para lidiar con texto libre. Tiene modelos pre-entrenados muy buenos en muchos idiomas para llegar y utilizar. Yo la usé una sóla vez porque en Cenco teníamos info sucia de muchas empresas (y querían sacar promociones en la tarjeta, o algo así): “Hipermercados Lider”, “Supermercado Lider”, “Falabella” , “Tiendas Falabella”. Entonces hicimos un Name Entity Recognition para encontrar nombres de potenciales Comercios donde compraba la gente para poder ofrecer descuentos al sacar la tarjeta Cencosud. Por ejemplo, ellos tenían descuentos en Cine, y nadie y usaba la tarjeta para ir al cine. Pero sí la usaban para Uber, entonces querían cambiar la estrategia a ofrecer no sé 10 lucas en Uber o algo así. Aprendí lo que necesitaba en una tarde porque su documentación es excelente.
DBeaver ((O), Pr: 2): Esta es un cliente de bases Open Source gratis (aunque también tiene una versión pagada). Básicamente es un software que puedes descargar que te permite conectarte a cualquier Base de Datos SQL y muchos otros. Entre los motores disponibles están: Postgresql, MySQL, Hive, ElasticSearch, Redshift, Snowflake y Neo4J entre otros. Además, en la versión paga te permite conectarte a MongoDB. Es rápido, tiene posibilidad de tener los modelos ER de cada Esquema además de varios atajos de teclado. Muy buena opción para conectarse con distintos motores.

Visualizaciones

Esta es probablemente mi parte más débil principalmente porque es un área que no me gusta. Aún así he usado varias librerías, las cuales voy a mencionar ahora.

Seaborn (Rk: 310, ND: 9M+, Pr: 1): Probablemente no esperaban que esta fuera mi primera opción. La razón por la que la menciono en primer lugar es porque es una librería con funcionalidades restringidas pero que hace la pega muy bien. Tiene la mayoría de gráficos prehechos y permite sin mucho código hacer gráficos muy bonitos y muy expresivos. Mi recomendación es sólo aprender sns.catplot() que permite graficar gráficos de variables categóricas o combinación categórica numérica (conteos, barplots, boxplot y amigos, etc.), sns.relplot() que permite generar gráficos para variables sólo númericas (scatter, lineplots) y sns.displot() que grafica básicamente histogramas. Estas 3 funciones tienen interfaz comunes con built-in facet y varias manera de agrupación (columnas, filas, colores, estilos, etc.). Una de las cosas que más me entusiasma es que Seaborn comenzó a desarrollar una interfaz muy similar a ggplot2 de R lo cual la haría extremadamente flexible y fácil de usar. Definitivamente vale la pena aprenderla.
Matplotlib (Rk: 110, ND: 26.9M+, Pr: 1): Yo creo que el ranking es un poco mentiroso, principalmente porque matplolib es dependencia de casi todas las librerías de gráficos, por lo que siempre la vas a necesitar. Lamentablemente hay que aprenderla. Y digo lamentable, porque a pesar de ser muy poderosa, considero que la documentación es como engorrosa y tiene una sintaxis muy verbosa. Además seaborn está construida sobre matplotlib, por lo que en casos de querer cambiar elementos del layout en seaborn se debe hacer mediante comandos matplotlib. Mi recomendación es aprenderla con ejemplos y algún cursito corto en Datacamp, porque es realmente difícil de aprender (no por su sintaxis sino que porque tiene muchas maneras distintas de hacer lo mismo y que a veces aplican y otras veces no). Igual me he dado cuenta que la termino usando más que Seaborn.
ggplot2 ((R), Pr: 1): Para muchos es la mejor librería de visualizaciones que existe. Y quizás tienen razón. ggplot2 es un remake de ggplot (que fue un fracaso) y que está basado en el grammar of graphics que es un concepto en el cual las partes del gráfico se construye en capas (la figura; ejes; elementos como puntos, líneas, boxplots; cálculos como regresiones lineales, promedios, intervalos de confianza; etc.) Además como que por defecto la paleta de colores y los ejes son bien bonitos. Yo considero que no es tan fácil de aprenderla pero es la mejor sintaxis para graficar. Existen algunas librerías/addins en RStudio como esquisse que permiten crear ggplots (te entrega el código incluso) con una interfaz tipo Tableau. Muy recomendada si trabajas en R y/o en Python. Además tiene un enorme ecosistema de librerías complementarias para poder graficar casi cualquier cosa.
plotnine (Rk: 2473, ND: 232K+, Pr: 0): Es la versión en Python de ggplot2. Creo que es un tremendo esfuerzo y casi todas las funcionalidades están implementadas pero no funciona tan bien como ggplot2 (su ranking lo indica). El problema es que ggplot2 tiene muchos paquetes que lo complementan. Uno de los más poderosos es patchwork que es una interfaz para crear gráficos sobre gráficos de manera muy sencilla. Este es precisamente uno de las grandes problemáticas de plotnine, si se quieren crear layouts un poco más complejos comenzamos nuevamente a depender de matplotlib lo que evita una sintaxis única. Gracias a ver visto un EDA por Martin Henze utilizando ggplot comencé a usar esta librería pensando que podría lograr los mismos resultados, pero lamentablemente ggplot es muy superior.

En mi opinión el 90% del tiempo utilizar gráficos estáticos será más que suficiente tanto para compartirlos en un PPT o para hacer EDAs. En caso de crear alguna aplicación interactiva entonces gráficos dinámicos e interactivos como los que hacen las siguientes librerías son una buena opción.

plotly (Rk: 359, ND: 7.5M+, Pr: 0): Plotly es una librería basada en D3, que a su vez es una librería de Javascript que se hizo muy popular gracias a su capacidad de desarrollar gráficos interactivos muy bonitos. Hoy tiene APIs en casi todos los lenguajes más populares. Para mí gusto es una librería que sólo vale la pena aprender si es que estás completamente dedicado a las visualizaciones. Si bien es una librería poderosa es muy verbosa. Afortundamente paquetes como plotly-express han aparecido para abstraer la verbosidad y crear versiones de gráficos comúnmente usados en pocas líneas.
plotly-express (Rk: 2936, ND: 181K+, Pr: 2): Es la versión menos verbosa de plotly, si bien es un pelín menos poderosa debido a que es más simple, la mayor parte del tiempo será maś que suficiente. No entiendo por qué no es tan popular aún.
altair (Rk: 360, ND: 7.4M+, Pr: 0): Es otra librería muy parecida a Seaborn en términos de sintaxis pero con la interactividad de plotly. Yo la utilicé sólo una vez creando una app en Streamlit. La razón: no quería usar plotly (en ese tiempo no conocía plotly express) y quedaban los gráficos más bonitos que en matplotlib y seaborn que eran estáticos. No vale la pena aprenderla y rara vez la verán por ahí.
bokeh (Rk: 674, ND: 1.8M+, Pr: 0): Es otra librería proveniente de Javascript que puede ser usadas desde R o Python. La verdad es que no la he usado, pero pueden ser alternativas para plotly ya que también son interactivas basadas en HTML pero con una sintaxis más simple. Nuevamente las recomiendo sólo en caso de dedicarse el BI o al Data Storytelling donde vale la pena invertir en visualizaciones llamativas.

Otras herramientas BI

Tableau ((O), Pr: 2): En el caso de trabajar en Business Intelligence donde el foco es más mostrar herramientas interactivas que puedan manipular la data con algunos clicks, aparecen herramientas que no están basadas en código. Tableau es una muy buena alternativa. Es rápido, fácil de crear Dashboard con gráficos que sirven como filtros y pueden interactuar entre ellos. El problema, es que su costo es prohibitivo, su licencia es extremadamente cara y hoy existen otras herramientas más baratas que hacen lo mismo.
PowerBI ((O), Pr: 2): Es el Tableau de Microsoft. Es una buena alternativa con costos de licencias bastante más bajo. Sigue la misma idea de Tableau de usar cajitas tipo Pivot Tables para crear gráficos. Igual de eficiente que Tableau pero mucho más barato.
Qliksense ((O), Pr: 2): No recuerdo quien creó esto, pero es otra versión. Funciona exactamente igual que los otros dos. Tienen las mismas funcionalidades. Ninguna ventaja ni desventaja con los otros.

¿Cuál elegir? Da lo mismo, es lo que tu empresa esté dispuesta a pagar.

Shiny ((R), Pr: 1): Podríamos decir que es la versión en R de estos productos. La diferencia es que es gratis, y es basado completamente en código. Permite crear todo tipo de Dashboards interactivos mezclando cualquier otra librería de R (aunque también se podría agregar Python mediante reticulate) tanto para manipular datos como para visualizar. Es extremadamente poderosa y flexible y hay varias empresas que crean sus portales utilizando Shiny. El problema es que no es tan fácil de hostear. En mi tiempo sólo RStudio ofrecía servicios para hostear ShinyApps (algunos gratis y otros de pago). Lo bueno es que se comenzó a crear todo un ecosistema en torno a Shiny, el cual tiene temas (basados en Bootstrap, material y otros frameworks de HTML, CSS y Javascript). Además, hay una librería llamada golem, que permite modularizar grandes aplicaciones e incluso se permiten ingresar elementos nativos en HTML, CSS o Javascript. Vale completamente la pena aprenderlo si es que te dedicas al BI en R y tienes tiempo de crear todo desde cero. Va a ser más flexible que Tableau, PowerBI o Qliksense, pero hay que crear todo.
streamlit (Rk: 1361, ND: 853K+, Pr: 1): Similar a Shiny pero en Python. En mi opinión es mucho más sencillo de utilizar, pero mucho más simplista. Tiene lo justo y necesario para hacer funcionar una excelente aplicación demo. Lo bueno es que Streamlit fue comprado por HuggingFace por lo que se ha estado llevando sus funcionalidades para que sea el front-end de modelos de Machine Learning. Una ventaja de streamlit es que es fácilmente hosteable en cualquier servidor con Python (que son casi todos), en Heroku, en un servicio provisto por la misma gente de Streamlit o en Huggingface Spaces, siendo estos últimos totalmente gratis. En el caso de querer hacer una demo, se puede crear algo de gran calidad y complejidad en no más de una hora. Su sintaxis es muy sencilla y se puede aprender en unas horas.
Dash (Rk: 1380, ND: 830K+, Pr: 0): Este es casi idéntico a Shiny (pero también en Python). Yo lo usé sólo una vez en un proyecto, y no nos gustó porque era muy complicado de setear. Básicamente crear el CSS que dejara los distintos divs en orden fue un martirio por lo que siempre nos quedaba la aplicación descuadrada. No vale la pena, ya que streamlit simplificó esto infinitamente.
Gradio (Rk: 3187, ND: 148K+, Pr: 2): Es una interfaz aún más simple que Streamlit, pero con muchas menos funcionalidades. Esta librería sí que se creó con el sólo propósito de ser un IO para modelos de Machine Learning. A diferencia de Streamlit que puedes crear Dashboards, sitios webs, agregar gadgets, Gradio sólo le interesa crear gadgets de input/output para un modelo a modo de demo. Yo lo probé rápidamente y lo encontré muy fácil. Decidí aprenderlo luego de ver una demo de un Pipeline de Transformers por Omar Sanseviero, donde construyó un front-end con modelos de Generación de Texto y Machine Translation en 10 mins. Puedes ver su presentación acá. Vale mencionar que también fue adquirido por HuggingFace por lo que puedes hostearlo facilmente en servidores Python, Heroku o Spaces. La gran ventaja de Gradio es que permite hostear de manera gratuita desde cualquier computador por dos días. Una vez se acabe puedes volver a levantar el servicio, el cual permite el frontend y una API en FastAPI creada automáticamente.
Django (Rk: 357, ND: 7.5M+, Pr: 0): No lo he usado. Pero es por lejos la librería más poderosa de desarrollo Web. Acá ya no hablamos sólo de una interfaz de Dashboards sino que un software completo. Es tanto así que existen Ingenieros de Software especializados sólamente en el Ecosistema Django. Por nada del mundo como Data Scientist debieras tener que llegar a usar una librería tan poderosa como esta. Pero si te interesa crear una aplicación a nivel profesional con procesos de datos o Modelos de Machine Learning por abajo, esta podría ser una opción. Algunas aplicaciones creadas en Django son Instagram, Spotify, Youtube, Dropbox, entre otras.
Flask (Rk: 88, ND: 35.9M+, Pr: 0): Tampoco lo he usado, pero tengo entendido que es un Django pequeñito, que además tiene otras funcionalidades como crear APIs. Es aún extremadamente popular en entornos de desarrollo web, pero en mi opinión está poco a poco cayendo en desuso, principalmente debido a que FastAPI está ganando mucho protagonismo en cuánto a APIs se refiere y es una opción mucho más sencilla de aprender.

Machine Learning

Esta es por lejos mi sección favorita, por lo que puede que me extienda un poco más de que el resto.

Scikit-Learn (Rk: 94, ND: 32.6M+, Pr: 1): Es la librería por excelencia para crear modelos de Machine Learning. La sintaxis de su API está tan bien diseñada que una manera de reconocer que otras librerías de Machine Learning son confiables es si es que siguen su API. Básicamente scikit-learn es super reconocida por sus modelos como Clase y su estandar fit-transform-predict, además de casi 15 años de vida. Si quieres hacer modelos de Machine Learning sí o sí tienes que partir por acá por varias razones: (1) Su documentación es excelente, incluso puedes aprender la teoría detras de cada modelo leyendo su User Guide (toda persona que se dedique al ML debería leer la documentación completa de Sklearn una vez al año 🤪). Además contiene sólo modelos ML que están en el estado del arte. De hecho para que un modelo se implemente en Scikit Learn tiene que cumplir requisitos muy estrictos. Andreas Mueller, mantenedor de Scikit-Learn tiene un curso disponible de manera gratuita acá. Este es por lejos una de las mejores inversiones que uno hará como Data Scientist, ya que aprendiendo a utilizar esta librería podrás utilizar millones de otras basadas en la misma API. Acáun ejemplo de modelamiento en Scikit-Learn.
tidymodels (R, Pr: 2): Yo solía ser un fan de esta compilación de librerías. Creo que Max Kuhn es un tremendo desarrollador y lo respeto profundamente, pero creo que parsnip trató de llevar el modelamiento en R a un estado incluso más flexible que scikit-learn pero no les funcionó. Lamentablemente el Machine Learning en R está disgregado en muchas librerías todas con APIs diferentes, por lo que este esfuerzo de unificar todo es increíble. Lamentablemente el memory leakage que sufre R y el tremendo trabajo de los mantenedores de scikit-learn hacen que un esfuerzo como este nunca logre la popularidad que tiene Python en este rubro. Tidymodels está basado en 3 paquetes principalmente: recipes, para el preprocesamiento, que a mi gusto tiene una API muy similar a los Pipelines de Scikit, parsnip, que es la unificación de todos los modelos de ML implementados en R y yardstick que contiene todas las métricas de evaluación. Si te dedicas a hacer modelos pequeñitos de prueba, sin mucho intensidad de cómputo es una opción, en cualquier otro caso vale más cambiarse a scikit-learn.
caret (R, Pr: 2): Este es el predecesor de tidymodels. A pesar de ser una librería que se le quitó mantenimiento hace un tiempo sigue disfruntando de mucha popularidad ya que tiene más de 200 modelos implementados. El propósito de Caret es el mismo de tidymodels sólo que su API no era compatible con el tidyverse por lo que decidieron seguir el esfuerzo de tidymodels. Este proyecto contaba con todo integrado, preprocesamiento, entrenamiento, postprocesamiento, esquemas de validación, métricas de evaluación, incluso ensambles. Por alguna razón lamentablemente decidieron cortarlo.
pycaret (Rk: 1940, ND: 432K+, Pr: 2): Este es un proyecto en Python que nace de la base de Caret y que se ha hecho extremadamente popular. En mi opinión sólo vale la pena aprenderlo si es que no te gusta codear. Las ventajas es que permite hacer mucho en pocas líneas de código y es compatible con muchas librerías externas como XGBoost, LightGBM, etc. Además cuando uno no es experto en tareas menos habituales como Anomaly Detection o Series de Tiempo permite seguir el mismo esquema de código. Lo que me gusta del creador de esta librería es que él deja muy en claro que su objetivo que es que los Citizen Data Scientist pueden tener modelos de alta calidad a la mano. Creo que están haciendo un tremendo trabajo y he visto muchos Notebooks en Kaggle que lo usan y obtienen muy buenos resultados.
Feature Engine (Rk: 3096, ND: 99K+, Pr: 1): Para mí esta es una librería de primerísima calidad. Tiene muy buen mantenimiento y tiene muchísimos mejores preprocesamiento que Scikit-Learn y además implementados en DataFrames. Contiene muchos de los excelentes encoders que tenía Category Encoders y además un Wrapper que permite convertir los preprocesadores de Scikit para que devuelvan pandas DataFrames en vez de Numpy Arrays. Espero que gane más popularidad, yo al menos la uso mucho.
category-encoders (Rk: 814, ND: 2M+, Pr: 0): Esta solía ser mi librería de encoders por defecto, pero dejó de mantenerse porque los mantenedores se cansaron. En su momento fue muy buena y todavía tiene mucha popularidad. Particularmente encontré un par de issues que reporté pero se demoraron casi un año en corregirlo. Una pena.
statsmodels (Rk: 294, ND: 9.6M+, Pr: 2): Si trabajas en Estadística en Python esta es la librería. Yo no soy muy fan de los modelos estadísticos, pero igualmente creo que es una librería interesante, porque también contiene muchas herramientas para trabajar con series de tiempo. En caso de necesitar mucho poder estadístico, creo que R es mucho más potente acá.
XGBoost (Rk: 320, ND: 8.8M+, Pr: 1): Uno de los problemas que Scikit-Learn solía tener es que no tenía una buena implementación de algoritmos de Gradient Boosting (hoy tiene una buena implementación de HistGradientBoosting similar a LightGBM) y XGBoost quizás es la implementación más famosa que hay. Desde el 2014 viene dominando por lejos el modelamiento en data tabular y definitivamente es un algoritmo que hay que dominar. Si bien es cierto su performance es superior, llegar a esa performance es difícil de lograr, ya que hay que hacer un buen afinamiento de Hiperpárámetros. Definitivamente un algoritmo que hay que aprender.
LightGBM (Rk: 393, ND: 6.5M+, Pr: 1): Me llama la atención que tenga menos descargas. Porque LightGBM para mí supera a XGBoost, por poco pero lo supera. En general para todas las competencias en la que he estado y modelos en producción que he dejado siempre obtengo mejor performance con LightGBM. Esta es una implementación liberada por Microsoft en 2016, y en mi opinión es bastante más rápido que XGBoost y menos complicado de afinar Hiperparámetros. El problema es la instalación, las docs de instalación son malitas, y la versión con GPU es bien enredada de instalar. Definitivamente, hay que tenerlo en el arsenal.
CatBoost (Rk: 747, ND: 2.3M+, Pr: 1): Otro Gradient Boosting que está muy de moda. En mi opinión es el algoritmo más fácil de afinar. Casi no hay que mover los Hiperparámetros para obtener muy buenos resultados. Es fácil de instalar, pero en velocidad es similar a XGBoost. Creo que el único problema que le he visto es que cuando guardas el modelo es muy pesado. Por ejemplo, una vez entrené los 3 Boosting (típico en Kaggle) y no sé, XGBoost y LightGBM pesaban del orden de megas mientras que CatBoost pesaba 11 GB, no sé si habré hecho algo mal, pero encontré que era muy pesado. El otro contra (no tan contra), es que siempre queda fuera de los frameworks, y la API es un poquito diferente a Scikit. (XGBoost y LightGBM tienen versiones con API de Scikit). Definitivamente hay que aprenderlo.

Lo bueno de los 3 grandes Boosting es que todos tienen Early Stopping y permiten el uso de un set de Validación mietras se entrena, igual que los algoritmos de Deep Learning.

DeepChecks (Rk: NA, ND: NA, Pr: 2): Yo no lo he usado aún en mis pegas, pero he hecho pruebas y revisado a fondo la documentación y creo que es una excelente librería para estudios previos de la data (chequear potenciales drifts y el potencial poder de generalización de un modelo) y para monitoreo. Permite realizar distintas validaciones para entre tu set de entrenamiento y tu data real, o test set para chequear que el modelo funciones bien en el tiempo.
Mapie (Rk: NA, ND: NA, Pr: 2): Excelente librería para aplicar Conformal Prediction, es decir, se pueden generar predicciones con intervalos de confianza en Regresión y Clasificación probabilística para modelos de clasificación. Lo bueno es que es solo un wrapper y es Scikit-Learn compatible. Tuve la oportunidad de estudiar la documentación a fondo y es realmente la manera de generar modelos robustos en especial cuando hay mucha incertidumbre.
mlxtend (Rk: 1024, ND: 1.4M+, Pr: 2): Tremenda librería creada por Sebastian Raschka, profesor de Wisconsin Madison y parte de Lightning AI. Es un complemento a Scikit-Learn y tiene varios elementos que permiten extender las capacidad de Scikit. En particular rescato las herramientas para ensambles tipo Stacking. Muy necesaria si quieres competir, y si quieres un modelo ensamblado.
pyGAM (Rk: 2237, ND: 325K+, Pr: 0): Es una librería que hace modelos GAM (Generalized Additive Models). Estos modelos son famosos por ser la mejor mezcla entre buena predicción y buena explicabilidad. Quizás el modelo GAM más conocido es prophet de Meta. En general esta librería no me gustó, y si es que realmente quieres meterte en este tipo de modelos mejor utilizar mgcv en R que es años luz más maduro. No creo que valga la pena aprenderlo.
CuML (Rk: NA, ND: NA, Pr: 0): Esta es una librería que está aún en desarrollo por parte de NVIDIA, pero es la parte de ML de cuDF y cuPY. Es un mirror de Scikit-Learn, pero que corre en GPU. En especial algoritmos como Random Forest y SVM pueden verse muy beneficiados. No creo que valga la pena aprenderlo, porque es lo mismo que Scikit-Learn.
Imbalanced-Learn (Rk: 650, ND: 3M+, Pr: 0): Es la librería por excelencia para desbalance de clases. Lo bueno es que incluye técnicas de undersampling, oversampling, SMOTE y algoritmos propios que funcionan con desbalance como RUSBoost y BalancedRandomForest. Debo confesar que casi nunca obtengo mejores modelos utilizando estas estrategias, y no me ha tocado usarlo aún, pero normalmente utilizando el parámetro sample_weigths de cualquier modelo de Scikit-learn podría funcionar mejor.
Shap (Rk: 530, ND: 4.1M+, Pr: 1): Es hoy quizás la librería más poderosa para dar explicabilidad. Existen varios spin-offs enfocados en problemas específicos pero creo que es algo que todos deberíamos dominar porque al negocio siempre le interesa entender por qué un modelo predice lo que predice.
ELI5 (Rk: 1022, ND: 1.4M+, Pr: 2): Otra opción para la explicabilidad de modelos. No lo he usado pero solía ser la librería por defecto antes que apareciera el boom de los shap values.
Implicit (Rk: 2761, ND: 207K+, Pr: 2): Librería de Factorization Machines para modelos de recomendación Implicita. Esta la usé una vez para una prueba de Concepto en Cencosud. Fácil de usar, buenos tutoriales, me gustó. No tengo más que decir, porque fue “el uso” que le dí.
Surprise (Scikit-Surprise) (Rk: 2860, ND: 195K+, Pr: 2): No alcancé a usarla, porque en la misma Prueba de Concepto anterior me dí cuenta que teníamos un recomendador implícito y Surprise es para modelos explícitos. Para tenerlo en cuenta.
LightFM (Rk: 1920, ND: 441K+, Pr: 2): Esta fue la librería que terminé utilizando, debido a su rápidez. Recuerdo que en ese momento no pude sacarle todo el potencial porque funciona mejor en entornos Unix y obvio, nos obligaban a usar Windows. También para tenerla en cuenta.
H2O (Rk: 1954, ND: 428K+, Pr: 2, (R)): Es una librería que está tanto en Python como en R que por detrás corre una JVM. Es la librería en CPU más rápida que he visto. Yo sólo la ví en curso en R con Erin Ledell. Es buena para hacer cosas rápido. Además posee AutoML y Stacking, para los que les guste algo rápido con poquito código.
Prophet (Rk: 1367, ND: 848K+, Pr: 2): Hace poco hubo un escándolo porque la empresa Zillow hizo un uso indiscriminado de Prophet entrenando modelos sin entender y eso le significó un impacto muy negativo (pueden leer más al respeco acá). Pero si se le da un uso correcto, creo que es una tremenda librería. Es fácil de usar y tienen muchas ventajas. Konrad Banachewicz está haciendo un curso de series de tiempo en el canal de Abishek Thakur y habló sobre este modelo, y la verdad lo encontré muy interesante. Úselo con precaución y bajo su propio riesgo.
Neuralprophet (Rk: 4635, ND: 68K+, Pr: 2): Spin-off de Prophet pero utilizando algoritmos de Redes Neuronales. Mismo cuidado que con prophet.
Sktime (Rk: 2739, ND: 211K+, Pr: 2): Es una extensión de Scikit-Learn para modelos aplicados a Series de Tiempo. Tiene algoritmos propios para clasificación (de series de tiempos, o sea clasificar un secuencia), regresión, forecast (no es lo mismo que regresión), anomaly detection y tiene varios CV propios de series de tiempo. Yo no la usé propiamente tal, pero aprendí mucho leyendo su documentación, en especial para entender la diferencia entre forecast y regresión. Además posee un transformer que permite convertir modelos de forecasting en Regresión. Muy buena librería si trabajas con series de tiempo.
Skforecast (Rk: NA, ND: NA, Pr: 2): Muy similar a sktime pero creada por Joaquin Amat, un data scientist español. Creo que siempre el trabajo en español tiene que ser destacado.
TSFresh (Rk: 1888, ND: 456K+, Pr: 2): Yo utilicé esta librería como herramienta de feature extraction para series de tiempo. Posee una función extract_features que permite crear muchísimas features para series de tiempo. Muy buena librería.
Lifetimes (Rk: 1473, ND: 731K+, Pr: 2): Librería especializada en Survival Models. Los modelos de sobrevivencia son modelos que buscan estimar el tiempo a un evento. Lo utilicé en la competencia de Mercado Libre, pero no me dió muy bueno así que seguí por otro lado. Es bueno tenerlo como alternativa para tipos de modelación no tan comunes.
Boruta-Shap (Rk: NA, ND: NA, Pr: 0): Es una librería muy pequeñita que permite utilizar el algoritmo Boruta más Shap Values para Feature Selection. Por defecto utiliza un Random Forest para escoger las variables más importantes, pero yo lo utilicé con XGBoost y LightGBM en GPU y funciona bastante bien.
LOFO (Rk: NA, ND: NA, Pr: 0): Es otra librería de Feature Selection. En este caso la ventaja que ofrece sobre Boruta Shap es que se realiza una selección utilizando un modelo específico pero en un esquema de Cross Validation. Esta la utilicé en una competencia que tenía muchas variables anónimas, y funcionó bastante bien.
Optuna (Rk: 613, ND: 3.2M+, Pr: 1): Es probablemente la mejor librería de optimización que hay hoy. Originalmente permite resolución de algoritmos de Optimización (min, max, minmax). Pero su gran fortaleza es que permite la implementación de algoritmos Bayesianos de búsqueda compatibles con modelos de Machine Learning y Deep Learning (agregando Pruning, que permite terminar la búsqueda en espacios poco prometedores). Es obligación aprender a utilizarla, 100-200 iteraciones de Optuna es equivalente a una búsqueda gigantesca en GridSearch o RandomSearch.
Scikit-Optimize (Rk: 613, ND: 3.2M+, Pr: 0): No lo he usado, pero es competidor directo de Optuna. No sé mucho más pero creo que era necesario mencionarlo.
Hyperopt (Rk: 809, ND: 3.2M+, Pr: 0): Idem al anterior.
Scikit-plot (Rk: 1756, ND: 520K+, Pr: 0): Es en estricto rigor una librería de visualizaciones, pero sólo tiene visualizaciones asociadas a Machine Learning. Es muy sencillo de usar y con un comando permite graficar matrices de confusión, curvas ROC, curvas Precision-Recall, Curvas de Aprendizaje, Silhouette, Curvas de Calibración, etc. Yo comencé utilizandola porque antes los Plot de Scikit-Learn quedaban muy feos. Esto está muy mejorado actualmente y recomendaría utilizar este tipo de librerías sólo para curvas muy específicas.
Yellowbrick (Rk: 1659, ND: 578K+, Pr: 0): Para mí, hace y tiene exactamente lo mismo que Scikit-Plot. No recuerdo por qué comencé a usar Scikit-Plot por sobre esta.

Deep Learning

Pytorch (Rk: NA, ND: NA, Pr: 1): Es el framework de Deep Learning de Meta. Quizás esto es sorpresivo. Pero la razón por la que Pytorch no está en el Ranking es porque se recomienda su instalación via Conda. Para mí (y esto es muy sesgado), es la mejor librería de Deep Learning. Y la razón es porque te permite entender el funcionamiento de una red neuronal de mejor manera que con otros frameworks. El contra de Pytorch es que necesitas mucho código para entrenar principalmente, pero permite entender muy bien cuando hay que setear los gradientes a cero, en qué parte se evalúa la loss function, cuando haces backpropagation y actualizas los pesos. Además como te fuerza a utilizar clases permite mejorar tu programación orientada a objetos y su gran fuerte es la documentación, muy buena en términos de uso, pero también de teoría. Otro aspecto espectacular de Pytorch es que permite el desarrollo de spin-offs que mencionaré más tarde. ¿Es Pytorch perfecto? la verdad es que no. Como dije antes, es muy verboso y entrenar en Aceleradores es engorroso. Hay que estar consciente en todo momento de si tu tensor vive en CPU o GPU, hay que moverlo manualmente. No, es un cacho. Aún así, creo que es necesario hacer al menos un par de modelos en Pytorch Nativo, acá un ejemplo. Si quieres iniciarte en Pytorch, lo mejor es partir por el 60 minutes Blitz.
Pytorch-Lightning (Rk: 692, ND: 2.7M+, Pr: 1): Pero afortunadamente existe Pytorch Lightning que soluciona todos los inconvenientes de Pytorch Nativo. Permite organizar mucho del excesivo código de Pytorch y tiene una API que permite escalar a GPUs, TPUs, IPUs y HPUs sin casi ningún cambio. Además permite la portabilidad del código, haciendo que un mismo módulo sea muy fácil de reutilizar casi sin latencia. Creo que definitivamente Lightning es la razón por la que me enamoré de Pytorch. Dentro de los mejores lugares para entender bien el funcionamiento de Pytorch Lightning está este el level up y una serie de tutoriales de la Universidad de Amsterdam y otros más.
Tensorflow (Rk: 181, ND: 17.2M+, Pr: 0): Es el primer framework de Deep Learning liberado por Google en el 2015. Esto no es sesgo. No conozco a nadie que haga sus modelos utilizando Tensorflow. Inicialmente el hecho de tener ejecución estática, hacía que fuera muy difícil programar en él, además de que se sentía como programar en otro lenguaje distinto de Python. La versión dos permite ejecución dinámica, para debuggear en tiempo real, pero siento que ya quedó muy por detrás de Pytorch. Ahora, ¿por qué tiene tantas descargas? Porque se necesita el backend para programar en Keras que sí es la manera en que todo el mundo usa Tensorflow.
Keras (Rk: 292, ND: 17.2M+, Pr: 1): Para los que no les gusta complicarse con Pytorch pero igualmente quieren utilizar Redes Neuronales, Keras es la solución. Es por lejos la API más famosa, y más sencilla de aprender. Es un poco más lento que Tensorflow puro pero se encuentran muchos tutoriales de cómo implementar modelos sencillos. Yo comencé a aprender redes neuronales en Keras pero me fui desalentando porque no me gustó la documentación, la encontré muy engorrosa, y además porque empecé a confundirme. Hay como 3 formas distintas de implementar modelos, hoy algunas muy parecidos a Pytorch utilizando clases. No hay mejor o peor entre Keras o Pytorch, pero Pytorch está ganando mucha popularidad, mientras Tensorflow la pierde. Acá tengo un pequeño ejemplo de cómo utilizar Keras.
Jax (Rk: 1546, ND: 662K+, Pr: 0): No la he usado, y no está en mi agenda aprenderlo, pero puede que gane mucha popularidad. Corresponde a otro framework desarrollado por Google y fue adoptado por DeepMind, por lo que quizás debido al tremendo desarrollo que ellos hacen comience a hacerse famoso.
Pytorch-Geometric (Rk: 4190, ND: 86K+, Pr: 2): Es una extensión de Pytorch para trabajar con Redes de Grafos (Geometric Deep Learning). Yo lo encontré difícil de aprender, pero no por el framework sino que las redes de Grafos son más enredadas. Para tenerlo en cuenta. Tiene muy buena documentación, por lo que pueden comenzar el aprendizaje por ahí.
Pytorch-Forecasting (Rk: 4346, ND: 78K+, Pr: 2): Es un spin-off de Pytorch para Forecast utilizando Redes Neuronales. Lo interesantees que tiene varios algoritmos famosos implementados como N-Beats, DeepAR y Temporal Fusion Transformer. Además tiene Dataloaders que están diseñados para tipos de predicción propios de series de tiempo. Yo no la utilicé pero sí estudié bastante sus docs para ver si podía utilizarla.
Pycox (Rk: NA, ND: NA, Pr: 2): Spin-Off de Pytorch para el uso de Modelos Survival en Deep Learning. Tampoco alcancé a utilizarla, pero también para tenerla en el arsenal si usamos este tipo de modelos.
torchvision (Rk: 518, ND: 4.3M+, Pr: 0): Es una librería auxiliar a Pytorch para Visión que provee de datasets, Data Augmentation y algunos modelos preentrenados. Particularmente creo que hoy no vale la pena. Existen otras librerías más potentes que esta y se demora mucho en incluir cosas nuevas. No vale la pena a mi gusto.
Albumentations (Rk: 2391, ND: 283K+, Pr: 1): Es por lejos la mejor librería de Data Augmentation en Imágenes. No sólo es rápida sino que permite augmentation de Imágenes y Masks. No es muy dificil de aprender y es compatible tanto con Pytorch como con Tensorflow/Keras. Muy buena librería.
Kornia (Rk: 1918, ND: 441K+, Pr: 2): Si bien Albumentations funciona sumamente rápido, funciona en CPU. Kornia es un Albumentation en GPU, lo cual permitiría, es especial en multiple GPU, tener una que se dedique al preprocesamiento. No la he usado, pero está ganando mucha popularidad.
OpenCV (Rk: 466, ND: 5.2M+, Pr: 0): Si bien es una librería agnóstica de Visión, posee algunos modelitos internos que funcionan súper bien de manera rápida para tareas de detección de objetos, segmentación, etc. con los que fácil y rápidamente puedes impresionar. Yo la uso principalmente junto con Albumentations y es espectacular.
Timm (Rk: 837, ND: 1.9M+, Pr: 0): Si te dedicas a la Visión Computacional tienes que conocer esta librería, debe tener un par de comandos y su principal función es descargar modelos pre-entrenados. Principalmente sus modelos son compatibles con Pytorch pero creo que ya se pueden utilizar en Tensorflow/Keras también. Lo mejor de esta librería es que en quizás un par de semanas de salido una arquitectura estado del arte (SOTA Model) ya va a estar disponible acá. Puedes encontrar desde MobileNet o ResNets, hasta ViT, ConvNext, EfficientNets, y un largo etc. Otra buena noticia es que Timm se asoció con HuggingFace por lo que muy probablemente será aún más rápido ver avances en arquitecturas ultra modernas.
Transformers (Rk: 403, ND: 6.3M+, Pr: 1): Es quizás por lejos la librería que más rápido ha crecido en el último tiempo y es mantenida por HuggingFace. Inicialmente estaba enfocada en proveer modelos preentrenados y tokenizers de modelos de NLP. Hoy tiene modelos, de Visión, Audio, y dicen que vienen de Grafos. Yo no la he usado mucho, porque no estoy muy metido en el área de NLP, pero hay que conocerla. Con un par de líneas puedes hacer un tremendo transformer estado del arte. Aprovecho de destacar el trabajo que hace la Universidad de Chile que tiene un Bert preentrenado en español disponible para uso libre, el Beto.
torchinfo (torch-summary) (Rk: 4030, ND: 93K+, Pr: 0): Es una librería pequeñita que con una función summary permite ver un detalle de la red neuronal: capas, parámetros, tamaño, peso, idéntico a como lo permite Keras. Es una función literalmente.
torchmetrics (Rk: 705, ND: 2.6M+, Pr: 0): Es una excelente librería con métricas de evaluación para Deep Learning. ¿Por qué no usar las típicas de Scikit-Learn? Primero, esta tiene muchas más métricas específicas para NLP, Object Detection y un largo etc. Además estas métricas se pueden ejecutar en GPU o Clusters, dependiendo de la paralelización o distribución, lo cuál las hacen mucho más rápidas.

Misceláneo

VSCode ((O), Pr: 1): Para mí, el mejor IDE para programar hoy en día, aunque es agnóstico, puedes programar casi lo que quieras acá. Principalmente porque es liviano, evita muchas complejidades para trabajar en ambientes aislados (conda o venv). Lo bueno es que es totalmente personalizable, tiene extensiones para todo. De hecho este blog es escrito en Markdown utilizando distintas extensiones que me facilitan la escritura. Otro aspecto para los más computines es que puede utilizar keycodes populares como Vim, Emacs o Sublime para usar sólo el teclado. En particular VSCode tiene muy buen soporte para Python permitiendo el uso de Notebooks, Scripts o una Consola Interactiva. Además es posible utilizar terminal (aunque increíblemente no funciona tan bien en Windows, por eso Linux for the “Win”), tiene soporte de GIT, debugger y un largo etc. Vale la pena, toma un tiempo aprenderlo pero no se van a arrepentir.
RStudio ((O), (R) Pr: 1): Hay que decir que este es por lejos el IDE más optimizado para R. Permite instalar librerías directo de CRAN, tiene visualizador de Datasets, un sector de Plots, Documentación incluida, Explorador de Archivos y Terminal. Además tiene integración con GIT y librerías como blogdown (para hacer tu sitio web en R, mi antiguo sitio fue hecho ahí), bookdown (mi tesis de pregrado la escribí ahí), etc.
Spyder ((O), (R) Pr: 2): Este es como una réplica de Rstudio pero para Python. Inicialmente cuando me moví de Python comencé a utilizarlo, y es bien completo, permite Scripts, tiene extensiones para Notebooks, tiene explorador de variables. A mí particularmente me molestaban dos cosas, que se demora en iniciar, y que nunca pude encontrar una paleta de colores para el highlighting. Es una buena opción para programar en un ambiente que está diseñado para ciencia de datos.
Pycharm ((O), (R) Pr: 0): También lo utilicé con licencia completa y debo decir que si bien es un IDE enfocado exclusivamente en Python me cargó. Siento que no está pensado para Ciencia de Datos. Es muy pesado, se demora mucho en partir, su configuración inicial es terrible y al menos a mí siempre se me quedó pegado. Jetbrains (los creadores de esto) creo que se dieron cuenta que no era lo mejor y crearon un IDE enfocado en Ciecia de datos (DataSpell), pero la verdad no lo he probado. Es tan completo que llega ser abrumante, y nunca pude aprender todo lo que podía eventualmente servirme. Para mí, no vale mucho la pena.
Atom ((O), (R) Pr: 0): Para mí era lejos el mejor IDE para programar, creado por Github. Tiene extensiones, muy buenos atajos de teclado, era rápido, liviano y tenía una extensión llamada Hydrogen que permitía tener los resultados de tu código directamente en el Script de manera muy intuititva y cómoda. ¿Por qué dejé de usarlo? Siento que dejaron de darle tanto soporte luego que Github fue adquirido por Microsoft y favorecieron más VSCode. Además luego de usarlo por un rato, comandos simples como df.shape tomaba 40-50 segundos, lo cual era inaceptable. Créanme que volvería mil veces a utilizarlo si viera que hay soporte y mantenimiento continuo. Una lástima.
GIT/Github ((O), Pr: 1): Me cuesta creer que aún existen muchos “Data Algo” que no usan GIT. Esto debería ser obligación y requisito siempre. Afortunadamente me tocó trabajar en un equipo con muy buenas prácticas de desarrollo donde entendí la importancia de llevar control de versiones siempre. GIT no es difícil, pero es importante entender conceptos de Commits, push, trabajo en ramas. Adicionalmente llevarlo con Github (u otras variantes como GitLab o BitBucket) y entender conceptos como Pull Request, levantar Issues, Revisiones de códigos, approvals, etc. Si no usas GIT/Github, no te sientas mal. Hay empresas gigantes que no lo usan, pero aprenderlo y fomentar su uso te lleva fácilmente a un nivel más alto de calidad. Si quieres aprenderlo tengo una serie de tutoriales que parten acá.
Docker ((O), Pr: 1): Hoy por hoy es imprescindible mover a producción todo en Docker. No soy para nada experto en el tema pero puedo crear un contenedor, conectarlo con el mundo real y eventualmente hostearlo en alguna parte. Es por lejos la mejor manera de asegurar reproducibilidad en cualquier ambiente (Unix, Max o incluso Windows con WSL2). Hay que aprenderlo sí o sí.
Bash ((O), Pr: 1): Creo que es sumamente importante conocer un poquito de Bash, en especial para automatizar procesos. Bash es el lenguaje de tu computador y te permite interactuar con él. Algunas cosas interesantes que puedes hacer: Agendar trabajos periódicos de manera automática, mandar correos cuando termine un proceso largo, apagar el computador luego de entrenar un modelo por la noche. No es dificil de aprender, y la mayoría de las veces vas a googlear en Stackoverflow para salir del paso.
Wandb (Rk: 791, ND: 2.1M+, Pr: 2): Este es un logger, que si bien permite llevar registro de modelos de ML y DL, funciona mejor en Deep Learning. Fácil de usar, muy linda interfaz y permite llevar registro de Arquitectura, Hiperparámetros, Curvas de Aprendizaje, ejemplos de Inferencia, almacenar tablas y gráficas, etc. Además contiene un sistema de Búsqueda de Hiperparámetros distribuido usando Hyperband, es decir, se puede entrenar el mismo modelo en distintas máquinas sin interferir entre ellos y sin repetir búsqueda, Weights & Biases lleva el control.
MLFlow (Rk: 260, ND: 11.1M+, Pr: 2): La verdad es que MLFlow es igual o mejor que Weights & Biases, pero a mí no me gustó. Encuentro que su documentación es engorrosa y su API no es tan intuitiva. Hace lo mismo además de poder llevar proyectos y un Model Registry para llevar control de versiones del entrenamiento de tu modelo. Si les interesa aprenderlo, tengo un tutorial acá.
FastAPI (Rk: 377, ND: 6.8M+, Pr: 1): Es quizás una de las librerías más rápidas en Python y es muy fácil de usar. Primero, está hecha por un Colombiano (Tiangolo), es de excelentísima cálidad, muy buena documentación, muchas funcionalidades, y requiere de poquito código, ¿qué más se puede pedir?. Definitivamente si quieres distribuir lo que sea, data, un modelo de ML, FastAPI es la mejor opción. Es tanto la popularidad que varias librerías utilizan esta librería under the hood.
Airflow (Rk: 375, ND: 6.8M+, Pr: 1): Yo creo que a menos que seas Analista de Datos, es una herramienta que hay que aprender. Airflow es un orquestador creado por Airbnb, que permite ejecutar y agendar Scripts para ser ejecutados de manera local o remota. Lo bueno de Airflow es que servicios como AWS, o Astronomer permiten ejecutarlos en entornos autoescalables en Kubernetes, lo cual quita una capa de complejidad, en especial a los que no sabemos cómo demonios funciona Kubernetes (un orquestador de contenedores). Airflow se hizo famoso como un orquestador de ETLs, que es compatible con casi todo. Yo lo he usado con: AWS, Spark, AWS Glue, ElasticSearch, MongoDB, SQLAlchemy, Redshift, Postgres. Es tan potente que incluso permite entrenar modelos de ML localmente o en entornos como Amazon SageMaker (aunque no es la opción óptima para ML), de hecho Airbnb creó BigHead para eso, que no ha sido liberado al público. Creo que su único contra es que un poco verboso, y tiene harto código boilerplate. Pero su funcionamiento es impecable.
Metaflow (Rk: NA, ND: NA, Pr: 2): Otro orquestador, pero creado por Netflix, pero que está enfocado en llevar modelos de ML a producción. Las ventajas, mucho menos boilerplate que Airflow, no tienes los típicos problemas de Xcoms en Airflow, puede ejecutarse local o en AWS mediante AWS Batch, EC2 y Step Functions. Permite automatizar todo el proceso de entrenamiento creando de ser necesarios ambientes anacondas independientes para cumplir con requerimientos de versiones específicas. No alcancé a utilizarlo, pero me tocó leerme toda la documentación para impulsar su uso.
Kedro (Rk: 2066, ND: 378K+, Pr: 0): Otro orquestador, pero desarrollado por QuantumBlack. Es bien poderoso, en el sentido que permite crear Pipelines de carga de datos, y de entrenamiento de modelos, pero no logré encontrar tantas opciones de escalabilidad. Si bien permite por ejemplo conexión con Sagemaker en AWS, no tiene las opciones más avanzadas de escalamiento vertical y horizontal que tiene Airflow y Metaflow. Además lo encontré en su momento un poco verboso, y sus Docs tenían errores, que hizo que me costará mucho entenderlo.
DVC (Rk: 1700, ND: 551K+, Pr: 1): Para mí es el orquestador más liviano, con menos Boilerplate y más sencillo de utilizar, pero tiene una cierta inclinación al entrenamiento de modelos. DVC es más que un orquestador, permite llevar registro de versiones de tu data, los cuales normalmente no es posible llevar en GIT; organizar Pipelines, llevar registro de Hiperparámetros, guardar métricas de performance, etc. Me gustó mucho más que Airflow, pero para una orquestación local, aunque podría escalar. Puedes aprender de él en este tutorial.
Great-Expectations (Rk: 429, ND: 5.9M+, Pr: 1): Es un validador de datos. No les puedo explicar lo necesario que es empezar a incluir elementos como estos en nuestros Pipelines de datos. Todas las empresas tienen datos, pero pocas empresas con calidad suficiente para llegar y utilizar. Great Expectations es como una librería de Tests asociados a si los datos cumplen: rangos, tipos, cantidad, distribución y un largo etc. En caso de no cumplir levanta la alerta dando en detalle qué registros no cumplen con el estándar solicitado. Además es compatible con Airflow, por lo que uno puede usar como Gate de Ejecución si tu data cumple o no los requerimientos de modo de no cargar datos sucios en tus fuentes principales de almacenamiento. Muy buena librería.
Pytest (Rk: 72, ND: 39.4M+, Pr: 1): Librería de Unit Test, algo que los Data Scientist rara vez hacemos. Es muy buena librería, fácil de usar, aunque es media rara la Documentación, pero nada que un buen tutorial de Youtube no pueda enseñar. Todos los pipelines de datos, deberían considerar Unit Tests.
Hydra (Rk: 1507, ND: 698K+, Pr: 1): Para mí el mejor CLI para modelos de Machine Learning, nacida en el equipo de Research de Facebook, ahora Meta. No sólo permite crear comandos personalizados para ejecutar Scripts desde el terminal sino que también permite crear configuraciones muy complejas tanto para modelos de ML como para Pipelines en general. Para los que siguen el Blog saben que es de mis favoritas, y pueden ver ejemplos acá. Muy buena librería, aunque no es tan famosa aún.
CML (Rk: NA, ND: NA, Pr: 0): Es una librería para automatizar procesos con Github Actions. Si les interesa ver en acción pueden chequear acá. No vale la pena aprenderla, son sólo un par de comandos y ya.
BentoML (Rk: NA, ND: NA, Pr: 0): Esta es una librería que permite automatizar el Deployment de Modelos de Machine Learning. No la he usado pero he leído mucho su documentación, porque en estricto rigor permite crear de manera muy sencilla un Docker con tu modelo que esté listo para entregar al equipo de desarrollo. También crea una API Rest automáticamente. Definitivamente voy a estar metiéndome más en el tema.
MLEM (Rk: NA, ND: NA, Pr: 0): Esta es una librería que me ofrecí a probarla en Beta. Hace lo mismo que Bento, pero permite rápidamente deploy en Cloud (AWS, Azure y GCP y Heroku), para cualquier tipo de modelo, y crea el Docker automáticamente. Cuando la ví me pareció demasiado mágica y está recién partiendo. Lo bueno es que incluye un curso que se puede tomar de manera gratuita acá.
Typer (Rk: 349, ND: 7.8M+, Pr: 2): Creada también por Tiangolo, es un CLI mucho más poderoso que Hydra pero con un enfoque general. Su API es muy parecida a FastAPI, muy sencilla y potente. Yo la probé antes de conocer Hydra, pero igual creo que vale mucho la pena.
BeautifulSoup4 (Rk: 63, ND: 42M+, Pr: 2): Es una herramienta de Scrapping para poder tomar data de páginas web. Súper potente, ya que tiene mucho del trabajo que uno normal necesita hacer automatizado. Su documentación es buena y es fácil de aprender. Si quieres saber cómo usarla tengo un tutorial acá.
Boto3 (Rk: 1, ND: 392M+, Pr: 0): Es impresionante la cantidad de descargas de Boto3. Lamentablemente sólo será útil si utilizas AWS. Yo la he usado principalmente para interactuar con S3. Además si instalas s3fs y fsspec es posible utilizar pd.read_* y .to_* de pandas utilizando un URI de S3 directamente, por ejemplo: pd.read_csv('S3://bucket/folder/file.ext').
Joblib (Rk: 126, ND: 24M+, Pr: 0): Yo lo uso principalmente para serializar modelos entrenados de Scikit-Learn y similares de acuerdo a esto.
Pickle (Rk: NA, ND: NA, Pr: 0): Dejé de usarlo, porque Scikit-Learn favorece guardarlo en formato joblib.
Faker (Rk: 454, ND: 5.4M+, Pr: 0): Yo sólo lo utilicé para una prueba de técnica para un candidato. Quería poner la misma data que utilizabamos pero sin entregar información confidencial. Faker permite emular info de manera muy real, creando de todo. En ese momento, cree: Nombres, Apellidos, Direcciones, Teléfonos, Patentes de Auto, Empresas, y un largo etc. Es sumamente bueno cuando se quiere generar un producto en el cual la data no está lista. Súper útil, pero no lo vas a usar siempre.
pyyaml (Rk: 11, ND: 142M+, Pr: 0): No vale la pena aprender más que una función para importar un yaml, esto permitirá manipular tu yaml file como diccionario de Python. De esta manera toda tu configuración vive en un archivo yaml, y no ensucia tus Scripts.
pdbpp (Rk: 2999, ND: 173K+, Pr: 2): Es un debugger en terminal. Personalmente no me gusta el debugger de VSCode, por eso uso este. Tiene atajos de teclado y es bastante rápido. Lo recomiendo, aunque no es necesario que lo sepan utilizar.
holidays (Rk: 526, ND: 4.2M+, Pr: 0): Es una librería pequeñita pero muy poderosa (se ve en su ND). Tiene todos los feriados, de todos los países de todos los años. Sólo indicas país, periodo y ya. Yo la utilice para crear features en un Tabular Playground de Kaggle. Muy útil en series de tiempo, pero tiene un método y ya.
Python-Box (Rk: 1038, ND: 1.4M+, Pr: 0): Es súper útil, solo envuelves un diccionario con Box() y puedes llamar tu diccionario como dict.key en vez de dict['key']. Ahorras varios caractéres.
beepr ((R), Pr: 0): Esta es una librería inútil, pero que me encantaba. Podías agregar sonidos cuando tu código fallaba o terminaba correctamente (típico sonido de Mario al pasar el nível), lo cual sacó más de una carcajada en el equipo.
chime (Rk: NA, ND: NA, Pr: 0): Sería como el equivalente en Python de Beepr. Hay otra librería más que ocupé que no recuerdo el nombre pero no funcionó tan bien.
Rich (Rk: 290, ND: 9.8M+ Pr: 2): Esta es una librería muy poderosa para agregar color a tu terminal. Tiene muchas funcionalidades, barras de progreso, outputs de colores, quizás la mejor es que es posible que los errores en Python se rendericen más bonitos, para por lo menos frustrarse menor cuando algo falla. Creo que igual vale la pena invertir en una mejor experiencia de usuario cuando crees productos CLI, por lo que vale la pena aprenderla en ese caso.
tqdm (Rk: 77, ND: 38M+ Pr: 0): Tiene dos funciones interesantes, tqdm para envolver un For Loop y tener barra de progreso. Y otra para llamada progress_apply que permite barra para el apply de pandas. No te demoras nada en dominarla.

Librerías estándar que deberías usar/conocer

Logging (Rk: NA, ND: NA Pr: 1): Si vas a automatizar algo en Python, sea cual sea su uso, debes loggear todo. Logging permite generar archivos .log que permitirán analizar a posteriori si un Script terminó con éxito o no. Súper útil, fácil de aprender, tiene sólo un par de comandos para indicar éxito, info, warning, errores. Puedes combinar con chime y con Rich para tener un producto multicolor y sonoro. Hace más agradable la pega.
requests (Rk: 5, ND: 194M+ Pr: 0): Sirve para conectarse a una API o en combinación con BeautifulSoup para obtener el HTML de un sitio WEB. Yo la he utilizado sólo para eso y no cuesta nada aprender a utilizarla, aunque quizás si debas entender el output que normalmente es un string con HTML o string con arreglos de diccionarios anidados si proviene de una API.
glob (Rk: NA, ND: NA Pr: 0): Permite revisar directorios utilizando sólo el comando glob y un path con expresiones regulares simples. Súper útil, por ejemplo, cuando tienes que importar muchos archivos en un sólo pandas DataFrame.
json (Rk: NA, ND: NA Pr: 0): Yo lo he usado para convertir el output de requests en diccionarios y para guardar outputs como json. Sólo eso!
pathlib (Rk: NA, ND: NA Pr: 2): Esta es una librería bien interesante para poder automatizar la creación de directorios y llevar tus Path de manera más sencilla. Puedes manipular Path combinandolos, creando Paths más sencillos y crear o eliminar carpetas dentro de ellos. Es fácil de utilizar y tengo ejemplos de ello en mis tutoriales de DVC.
getpass (Rk: NA, ND: NA Pr: 0): Esta librería tiene una función llamada getpass, que funciona como un Text Input pero con los caractéres ocultos. Útil para ingresar data que no quieres que se vea, pero no la encripta ojo.

Uff

Y con esto terminamos. Debo decir que este es al artículo que más trabajo me ha dado. Y demoré cerca de dos meses en escribirlo. Voy a tratar de ir llenando esto con el tiempo a medida que vaya probando más cosas. Algunas de las tecnologías que se me quedaron en el tintero porque no cumplen los requisitos exigidos arriba:

Varios servicios AWS
- Sagemaker
- AWS Lambda
- API Gateway
- Step Functions
PRegex
Dagshub
poetry. Por alguna razón me da terror instalarla, aunque he leído bastante de ella.
fancyimpute
NGBoost
SKLego
tabnet
UMAP
Segmentation Models
NannyML
DGL
BioPython
Ecosistema Pytorch :

Espero que esto sea de utilidad para tenerlo como referencia a la hora de enfrentar distintos problemas en Ciencia de Datos.

Nos vemos,

Alfonso

¿Cómo funciona un Sistema Recomendador?

2022-04-25T00:00:00+00:00

Los sistemas de Recomendación están en todas partes. Abrimos Netflix, Amazon, Spotify, sin ir más lejos el mismo Mercado Libre, y todos siempre tienen algo que ofrecernos. Los sistemas de recomendación son otro tipo de modelos de modelos de Machine Learning, y son el eje principal en las grandes de Silicon Valley. Pero, conversando con Gustavo Prudencio de Cornershop, ambos estuvimos de acuerdo en que no son para nada Modelos Populares. Es más, particularmente en Chile, creo que es de los modelos más raros de ver. Probablemente Cornershop sea de los pioneros en esto (aunque no me quiso dar detalles de qué tienen actualmente implementado 😆).

En fin, no soy experto en modelos de recomendación. Pero por ahí en el 2019 me tocó armar un piloto en Cencosud Scotiabank utilizando filtrado colaborativo con librerías como implicit, surprise y lightfm pero nunca llegué a entenderlo a profundidad. Este fin de semana decidí aprender en más profundidad de esto e implementar un modelo de Recomendación en Pytorch (así como si tuviera tiempo de sobra, el cual no tengo).

Modelo de Recomendación

Entender el problema de recomendación es muy sencillo, hay dos tipos de recomendadores, los que usan rating explícito y rating implícito.

Rating Explícito: Es cuando un usuario de manera explícita califica un producto: Notas, estrellas, lo que sea. El tema con este tipo de data es que es rara porque normalmente no es obligatorio calificar un producto.
Rating Implícito: Es cuando la calificación del producto se da de manera implícita. Normalmente se puede dar como: compra o no compra un producto, ve o no ve un video, escucha o no una canción, etc.

El objetivo del modelo de Recomendación determinar qué producto sería bueno mostrarle al usuario. Para ello existen distintos approaches. El más común hoy el día es el filtrado colaborativo. Es una técnica que consiste en que se recomendarán productos que usuarios parecidos a ti hayan visto. Por lo tanto, no influye solo lo que tú has visto, sino que también lo que gente con gustos similares a los tuyos han visto.

Mi interés es poder implementar un modelo de Deep Learning que tenga esto en cosideración, por lo tanto, decidí utilizar el siguiente paper implementando un Neural Collaborative Filtering:

Este modelo está basado en Embeddings, que es una especie de Encoding en el cual se representa un espacio de alta dimensionalidad en un espacio de menor dimensionalidad en el cual la distancia de las representaciones pueden tener una cierta interpretación. Esto es particularmente importante porque normalmente los sistemas recomendadores están implementados cuando hay muchos usuarios y muchos productos.

Para el caso que quiero mostrar voy a utilizar un dataset llamado MovieLens 25M, el cual se puede descargar de acá. La razón por la que escogí este dataset es porque contiene una lista de usuarios y películas calificadas por usuarios hasta el 2019, que incluye muchas películas actuales (aunque pre-pandemia). El problema del dataset es que contiene 25 millones de ratings, 62423 películas y 162541 usuarios.

No voy a utilizar el dataset completo porque no quiero ensuciar las recomendaciones con películas antiguas, pero de igual manera quiero como desafío personal trabajar con una gran cantidad de datos. Es en este tipo de problemas cuando realmente es necesario tener buenas skills de programación para poder lidiar con alta cantidad de datos.

Esto no es Big Data, es harta data pero para que se vea el poder del Stack de Data Science no vamos a usar nada extraño, sólo Pandas, Scipy y Numpy.

Entonces para poder entender qué hace el modelo encontré el siguiente ejemplo: Supongamos que Bob no es muy fan de las peliculas de Romance, pero sí de ls películas de Acción, mientras que Joe, le gustan ambas. Podemos dependiendo del id de usuario y de las id de las películas vistas transformarlo en lo siguiente:

Luego su representación en el plano bidimensional Action x Romance nos permite identificar qué tan parecidos o distintos son Bob y Joe. Esto permitirá al modelo aprender las relaciones que existen entre usuarios al momento de poder recomendar.

Teniendo estas ideas básicas del funcionamiento de un recomendador vamos a la implementación:

Entendiendo los datos

Películas

import pandas as pd
import numpy as np

movies = pd.read_csv('ml-25m/movies.csv')
print(movies.shape)

(62423, 3)

Index(['movieId', 'title', 'genres'], dtype='object')

El set de películas contiene sólo el Id de Película, el título y los géneros asociados a cada película. La verdad es que el formato no es mi favorito, por lo que decidí limpiar un poco la data para por ejemplo poder obtener el año de cada película. Además como dijimos anteriormente, no queremos recomendar películas viejas por lo que decidí mantener sólo las películas de 2010 en adelante.

year = 2010
movies['year'] = movies.title.str.extract(r'\((\d{4})\)').astype("float")
movie_id_removed = movies.query('year < @year').movieId.tolist()
movies = movies.query('year >= @year')
movies

	movieId	title	genres	year
14156	73268	Daybreakers (2010)	Action\|Drama\|Horror\|Thriller	2010.0
14161	73319	Leap Year (2010)	Comedy\|Romance	2010.0
14162	73321	Book of Eli, The (2010)	Action\|Adventure\|Drama	2010.0
14222	73744	If You Love (Jos rakastat) (2010)	Drama\|Musical\|Romance	2010.0
14256	73929	Legion (2010)	Action\|Fantasy\|Horror\|Thriller	2010.0
...	...	...	...	...
62412	209143	The Painting (2019)	Animation\|Documentary	2019.0
62413	209145	Liberté (2019)	Drama	2019.0
62415	209151	Mao Zedong 1949 (2019)	(no genres listed)	2019.0
62418	209157	We (2018)	Drama	2018.0
62420	209163	Bad Poems (2018)	Comedy\|Drama	2018.0

20489 rows × 4 columns

Esto nos dejó con 20489 películas pero que no deja de ser un número considerable.

Además es importante guardar los id de las películas removidas que fueron 41524. Estas tienen que retirarse también de los reviews de los usuarios.

len(movie_id_removed)

Finalmente, creé un mapping entre el movieId y el nombre de la película. Esto será de gran utilidad al final del procedimiento, para poder identificar los movieId recomendado para ver si es que hacen sentido.

movies_mapping = movies[['movieId','title']].set_index('movieId').to_dict()['title']

Calificaciones

Por otro lado, tenemos el dataset de Ratings, el cual contiene los 25 millones de datos. Estos contienen los distintos usuarios con las películas vistas y sus reviews. Además incluye un timestamp para poder por ejemplo, tener información de cuando vió la película, en caso de que el orden también tenga relevancia para la recomendación.

ratings = pd.read_csv('ml-25m/ratings.csv', parse_dates=['timestamp'])
print(ratings.columns)
print(ratings.shape)
ratings.userId.nunique()

Index(['userId', 'movieId', 'rating', 'timestamp'], dtype='object')
(25000095, 4)

162541

Entonces, dentro del procesamiento de los datos tenemos que primero eliminar todas las películas anteriores a 2010 (por eso guardamos los movieId de las películas). Además modificaremos el rating a 1. Esto convertirá nuestro problema en un recomendador implícito. Es decir, el 1 significará que el usuario interactuó con la película, es decir, la vio. Esto es importante para el algoritmo de recomendación ya que entonces tendremos que modelar nuestro problema como un problema de clasificación.

ratings = ratings.query('movieId not in @movie_id_removed')
ratings['rating'] = 1
ratings['timestamp'] = pd.to_datetime(ratings['timestamp'], unit='s')
ratings

	userId	movieId	rating	timestamp
712	3	73268	1	2015-08-13 14:11:38
713	3	73321	1	2015-08-13 13:52:05
715	3	74458	1	2017-04-21 14:39:18
716	3	74789	1	2019-08-18 00:59:42
717	3	76077	1	2017-01-18 16:15:09
...	...	...	...	...
24999773	162538	111617	1	2015-08-05 14:15:09
24999774	162538	112138	1	2015-08-05 14:14:35
24999775	162538	112556	1	2015-08-05 14:25:33
24999776	162538	116797	1	2015-08-05 13:25:21
24999777	162538	126548	1	2015-08-05 14:24:57

2711937 rows × 4 columns

Este es quizás uno de los proyectos que más he disfrutado haciendo, y la razón principal es porque el Proceso de un Motor de Recomendación es bastante más complejo que sólo entrenar el modelo. La data tiene que ser manipulada de muchas maneras distintas (incluyendo sus complejidades por el tamaño, así que veamos cómo me las ingenié)

Label Encoder

Debido a los recortes que hicimos en la data, nuetros Id, tanto de Usuarios como de películas no tienen porque ser consecutivos. Esto nos pueden traer algún problema para el algoritmo ya que el id va a representar una distancia en nuestro espacio de embeddings y no queremos que esto se vea alterado. Para ello entonces utilizaremos el LabelEncoder para crear un mapeo entre los ids reales y un id correlativo.

Esto es básicamente lo mismo que hicimos con el mapeo de películas, pero eventualmente al momento de produccionalizar esto tendremos que tener acceso rápido a nuestros mapeos, por lo que el LabelEncoder permite una fácil serialización de ellos, ya que las clases quedarán como listas.

from sklearn.preprocessing import LabelEncoder

user_encoder = LabelEncoder()
movie_encoder = LabelEncoder()
ratings['userId'] = user_encoder.fit_transform(ratings.userId)
ratings['movieId'] = movie_encoder.fit_transform(ratings.movieId)

Primer Tropezón

Dado que este es un recomendador implícito, va a ser modelado como un problema de clasificación binaria. Por lo que tenemos muchas películas que el usuario ha visto, pero no tenemos las que no ha visto. Para que el modelo pueda aprender bien leí que una buena idea es poder entregar casos negativos, es decir, películas que no ha visto. Y un buen ratio era 4:1, es decir 4 películas no vistas por cada película vista.

Mi primer approach fue este:

def create_negative_movies(df, userid = 'userId', movieid = 'movieId',neg_examples = 4):
    unique_movies = set(df[movieid])
    
    movies = []
    uids = df[userid].unique()
    for u in uids:
        movies.extend(np.random.choice(list(unique_movies - set(df[movieid][df[userid] == u])), size = neg_examples))
        
    return uids, movies

Intenté una implementación, que de partida estaba mala, pero que demoró 20 minutos en ejecutarse. Básicamente el código hace lo siguiente:

Para cada usuario en la lista de usuarios.
Calculo la diferencia entre todos los ids de películas y las que ha visto un usuario.
A partir de las películas no vistas saco un random de 4 ejemplos.

Este approach está incorrecto porque generé sólo 4 ejemplos por usuario, unos 400K registros extras y demoró demasiado debido a los muchos usuarios, y debido a que filtrar un dataset tan grande tantas veces lo hace muy lento.

La solución

Si han estudiado el mecanismo de atención de los transformers, notarán que básicamente se basan en un one-hot encoder para utilizarla como una matriz de filtrado (si quieren estudiar esto en detalle pueden leerlo acá). Con esto podríamos crear una matriz cuyas filas sean los ids de los usuarios y las columnas los ids de las películas. Esto se conoce como una user-item matrix y basta con hacerla así:

user_item_matrix = ratings.pivot(index = 'userId', columns = 'movieId', values = 'rating').fillna(0)

El problema es que esta matriz es gigantesca y me dio el clásico error Unable to allocate 1010. MiB for an array with shape....

Entonces, aquí es donde hay que ponerse creativo. Básicamente la user-item matrix es una matriz rala (escasa, esparsa, llena de ceros, no sé cuál es la terminología correcta, sparse matrix en inglés…). Y scipy tiene matrices especiales para eso. csr_matrix sólo almacena los índices de los valores distintos de cero. Este tipo de matriz es extremadamente eficiente para sumas y productos matriciales, los cuales no vamos a usar, pero sí queremos beneficiarnos de la eficiencia.

from scipy.sparse import csr_matrix
np.random.seed(42)
def create_matrix(data, user_col, item_col, rating_col):

    data[[user_col, item_col]] = data[[user_col, item_col]].astype('category')
    
    rows = data[user_col].cat.codes
    cols = data[item_col].cat.codes
    rating = data[rating_col]
    user_item_matrix = csr_matrix((rating, (rows, cols)))
    return user_item_matrix

user_item_matrix = create_matrix(ratings, 'userId', 'movieId', 'rating')

Encontré una implementación que básicamente toma los índices de usuarios y películas y en la cordenada (userId, movieId) rellena el 1 o cero si es que dicho usuario vio o no la película. Crear esto toma exactamente nada:

Antes eso sí de generar las clases negativas decidí generar el split de la data. Esto con el fin de poder evaluar el comportamiento del modelo:

La verdad es que en mi proceso real hice el split antes, pero luego me di cuenta que era mejor crear la user-item matrix primero. Esto porque si creaba este procedimiento después tendría que crear dos user-item matrix, una para el train_set y otra para el test_set. El gran problema de esto, es que los índices en test son películas que no están en train, por lo que iba a tener problemas para identificar el id correcto ya que el test_set iba a tener dimensiones distintas y el id 0 de test no iba a corresponder a la película con id cero, si no a la primera película del test_set que podría ser una película arbitraria. Esto me forzaría a hacer otro mapeo, el cual no quise hacer. Todo ese problema me lo evité haciendo el split después.

Train-Test Split

Para poder generar el split sin generar leakage se recomendaba utilizar el siguiente procedimiento:

ratings['test'] = ratings.groupby(['userId'])['timestamp'].rank(method='first', ascending=False)

train_ratings = ratings.query('test != 1').drop(columns = ['test', 'timestamp'])
test_ratings = ratings.query('test == 1').drop(columns = ['test', 'timestamp'])

Básicamente estamos aprendiendo de todas las películas excepto la última que cada usuario vió. La última película estará en el test_set, por lo que esperamos que nuestro recomendador efectivamente pueda recomendar la última película que vió.

Generación de Películas no vistas

Ahora generé otra implementación utilizando la user-item matrix. Debido a la fea sintáxis de numpy, el resultado dejaba muchas funciones anidadas, por lo que decidí escribirlo estilo Pytorch:

def create_negative_df(user_ids, user_item, neg_examples = 4, test = False):
    
    movies_id = np.arange(user_item.shape[1])
    negative_movies = []
    examples = []
    for i in range(len(user_ids)):

        interacted = user_item[i].nonzero()[1]
        x = ~np.isin(movies_id, interacted)
        x = np.argwhere(x).squeeze(1)
        
        if test:
            size = neg_examples
        else:
            size = len(interacted)*neg_examples
        
        x = np.random.choice(x, size = size)
        negative_movies.extend(x)
        examples.append(size)
        
    negative_movies_df = pd.DataFrame(dict(userId = np.repeat(user_ids, examples),
                        movieId = negative_movies,
                        rating = np.zeros(len(negative_movies)))
                        )
    return negative_movies_df

Esta función:

Toma los ids de películas y para cada id de usuario detecta las películas con que interactuó.
Genera un mask de películas no vistas, es decir, donde la user-item matrix no es uno.
Calcula qué indices son las películas no vistas.
Saca una muestra de toda las películas no vistas igual a neg_examples en el caso de test y de neg_examples por el número de películas vistas en otro caso.
Finalmente combina todo eso en un DataFrame (con una lógica bien enredada que no sé muy bien como explicar así que pueden deducirlo del código).

Esta función la implementé solito (sin StackOverflow).

Esta función entonces sacará 4 ejemplos no vistos por cada película vista por un usuario en train. En el caso de test es un poco distinto, dado que cada usuario tiene sólo una película vista, sacaremos 99 casos no vistos (aleatorios). Luego la predicción del modelo será las 10 recomendaciones de los 100 casos, donde una de ellas ha sido vista por el usuario. Esperamos que en las 10 recomendaciones se encuentre la película que efectivamente vio.

Como pueden ver esta implementación es muy rápida y eficiente y los resultados son 10 millones de registros para el train y 6 para el test.

Finalmente se combinan los casos vistos y no vistos obteniendo 12 millones para el train set y 6 millones para el test set.

full_training_df = train_ratings.append(train_negative_movies_df)
full_test_df = test_ratings.append(test_negative_movies_df)

full_training_df.shape, full_test_df.shape

((12797849, 3), (6078000, 3))

Neural Collaborative Filtering

Como siempre el modelo lo crearemos utilizando Pytorch Lightning. Justo actualicé Pytorch Lightning a la versión 1.6.1 el cuál trajo varios cambios en la API por lo que aprovecharé de mencionar dichos cambios:

import torch
import torch.nn as nn
import pytorch_lightning as pl
from pytorch_lightning.callbacks import ModelCheckpoint

pl.seed_everything(42, workers=True)

Global seed set to 42

Primero que todo fijamos la semilla para la reproducibilidad. Además, encontré que utilizando workers=True se garantiza la reproducibilidad en los DataLoaders, que a veces no eran tan fáciles de reproducir debido a la carga de la data en GPU.

from torch.utils.data import Dataset, DataLoader

class MovieData(Dataset):
    def __init__(self, users, movies, ratings):
        self.users = users
        self.movies = movies
        self.ratings = ratings
        
    def __len__(self):
        return len(self.ratings)
        
    def __getitem__(self, idx):
    
        users = self.users.iloc[idx]
        movies = self.movies.iloc[idx]
        ratings = self.ratings.iloc[idx]

        return dict(
            users = torch.tensor(users, dtype=torch.long),
            movies = torch.tensor(movies, dtype=torch.long),
            ratings = torch.tensor(ratings, dtype=torch.float)
        )

Creamos nuestro Pytorch Dataset, que básicamente tomará los usuarios, películas y ratings y los transformará en tensores.

class MovieDataModule(pl.LightningDataModule):
    def __init__(self, train_df, test_df, batch_size = 512):
        super().__init__()
        
        self.train_df = train_df 
        self.test_df = test_df 
        self.batch_size = batch_size
        
    def setup(self, stage=None):
        
        self.train_data = MovieData(self.train_df.userId, self.train_df.movieId, self.train_df.rating)
        self.test_data = MovieData(self.test_df.userId, self.test_df.movieId, self.test_df.rating)
    
    def train_dataloader(self):
        return DataLoader(self.train_data, batch_size=self.batch_size, shuffle=True, pin_memory=True, num_workers = 10)
    
    def test_dataloader(self):
        return DataLoader(self.test_data, batch_size=self.batch_size, shuffle=False, pin_memory=True, num_workers = 10)

En este caso el LightningDataModule tomará los set de train y test los transformará en tensores y los cargará en GPU con los DataLoader. Si se fijan el batch_size lo dejé en 512 porque es mucha data y batch size pequeños demoraban demasiado. El tema de usar batch_size alto es que hizo explotar mis DataLoaders muchas veces, y la razón de eso es porque tenía mi num_workers en 12 (que son todos mis core en mi laptop). Luego de mucho batallar, encontré que era mejor decisión bajar esto y dejar algunos libres. Hay que recordar que la función del DataLoader es cargar la data al modelo y en este caso hacer el traspaso a la GPU, pero este proceso se realiza en CPU, por lo que es bueno dejar unos cores para que el compu pueda sobrevivir el proceso de entrenamiento.

class NCF(nn.Module):
    def __init__(self, dim_users, dim_movies, n_out = 1):
        super().__init__()
        
        self.user_embedding = nn.Embedding(dim_users, 8)
        self.movie_embedding = nn.Embedding(dim_movies, 8)
        
        self.encoder = nn.Sequential(
                            nn.Linear(16,64),
                            nn.ReLU(inplace=True),
                            nn.Linear(64,32),
                            nn.ReLU(inplace=True),
                            nn.Linear(32,n_out)
                        )
        
    def forward(self, users, movies):
        user_emb = self.user_embedding(users)
        movie_emb = self.movie_embedding(movies)
        
        x = torch.cat((user_emb, movie_emb), dim = 1)
        x = self.encoder(x)
        return x

El modelo de Neural Collaborative Filtering es una red neuronal que toma como entrada los usuarios y películas y devuelve un rating. En este caso el modelo es una red neuronal que parte con un embedding tanto para users como movies de 8 dimensiones, que se concatenan para entrar en un encoder compuesto por una capa de 64 dimensiones, una capa de 32 dimensiones y una capa de 1 dimension (el rating). (Pueden creer que el parrafo anterior lo escribió Github Copilot, es espectacular). Como es un modelo de clasificación, este debería terminar con una sigmoide, pero se recomienda no hacerlo y utilizar una Loss Function de BCEWithLogitsLoss, que es una Binary CrossEntropy más la sigmoide que provee mejor estabilidad numérica.

class RecSys(pl.LightningModule):
    def __init__(self, model):
        super().__init__()
        self.model = model
        self.criterion = nn.BCEWithLogitsLoss()
        
    def forward(self,users, movies):
        x = self.model(users, movies)
        return x
        
    def training_step(self, batch, batch_idx):
        users, movies, ratings = batch['users'], batch['movies'], batch['ratings']
        preds = self(users, movies)
        # print('preds:',  preds.shape)
        # print('ratings: ', ratings.shape)
        loss = self.criterion(preds, ratings.view(-1,1))
        self.log('train_loss', loss,  prog_bar = True, logger = True)
        return {'loss': loss}
    
    def configure_optimizers(self):
        return torch.optim.Adam(self.model.parameters(), lr = 1e-3)

El LightningModule no tiene nada especial. Sólo mencionar que en este caso nuestra red neuronal recibe de cada batch los usuarios por un lado y las películas por otro. Esto es importante porque usuarios y películas tienen embeddings diferentes por lo que deben entrar al modelo por separado ya que los embeddings del modelo no van en serie sino en paralelo.

Finalmente para el entrenamiento instanciamos el modelo:

model = NCF(dim_users, dim_movies)
dm = MovieDataModule(full_training_df, full_test_df, batch_size=512)
recommender = RecSys(model)

Definimos el Callback:

mc = ModelCheckpoint(
    dirpath = 'checkpoints',
    #filename = 'best-checkpoint',
    save_last = True,
    save_top_k = 1,
    verbose = True,
    monitor = 'train_loss', 
    mode = 'min'
    )

mc.CHECKPOINT_NAME_LAST = 'best-checkpoint-latest'

Un detalle acá es que aprendí que cambiando la variable CHECKPOINT_NAME_LAST se puede tener el mejor checkpoint con un nombre fijo. De esta manera podemos automatizar el rescate del mejor estado del modelo ya que siempre tendrá el mismo nombre y no un -v1, -v2, -v3, etc.

Definimos el Trainer:

trainer = pl.Trainer(max_epochs=5,
                    accelerator="gpu",
                    devices=1, 
                    callbacks=[mc], 
                    progress_bar_refresh_rate=30, 
                    # fast_dev_run=True,
                    #overfit_batches=1
                    )
trainer.fit(recommender, dm)

Acá es importante destacar que hay cambios, ahora para ejecutar en gpu no utilizamos gpus=1 sino que definimos el accelerator que puede ser gpu, tpu, ipu, etc. Y definimos el devices que es el número de GPUs que queremos utilizar. Pueden ver comentado dos comandos que uso para debuggear que la red funcione correctamente antes de dejarla harto rato corriendo:

fast_dev_run=True ejecuta una epoch de prueba para chequear por ejemplo que las dimensiones de los tensores funcionen bien.
overfit_batches=1 sobreajusta una batch por cada epoch. Si el overfit funciona es que el modelo efectivamente tiene la posibilidad de aprender. Con esto se puede chequear que el modelo no diverge.

Normalmente ejecuto esto antes de dejar la red corriendo y luego de una larga epoch de entrenamiento darme cuenta que falló.

GPU available: True, used: True
TPU available: False, using: 0 TPU cores
IPU available: False, using: 0 IPUs
HPU available: False, using: 0 HPUs

LOCAL_RANK: 0 - CUDA_VISIBLE_DEVICES: [0]

  | Name      | Type              | Params
------------------------------------------------
0 | model     | NCF               | 653 K 
1 | criterion | BCEWithLogitsLoss | 0     
------------------------------------------------
653 K     Trainable params
0         Non-trainable params
653 K     Total params
2.612     Total estimated model params size (MB)



Training: 0it [00:00, ?it/s]


Epoch 0, global step 24996: 'train_loss' reached 0.08028 (best 0.08028), saving model to '/home/alfonso/Documents/kaggle/recom/checkpoints/epoch=0-step=24996.ckpt' as top 1
Epoch 1, global step 49992: 'train_loss' was not in top 1
Epoch 2, global step 74988: 'train_loss' reached 0.07823 (best 0.07823), saving model to '/home/alfonso/Documents/kaggle/recom/checkpoints/epoch=2-step=74988.ckpt' as top 1
Epoch 3, global step 99984: 'train_loss' reached 0.06737 (best 0.06737), saving model to '/home/alfonso/Documents/kaggle/recom/checkpoints/epoch=3-step=99984.ckpt' as top 1
Epoch 4, global step 124980: 'train_loss' reached 0.06487 (best 0.06487), saving model to '/home/alfonso/Documents/kaggle/recom/checkpoints/epoch=4-step=124980.ckpt' as top 1

Evaluación del Modelo

Otro cambio, esta vez en Pytorch 1.11, es la introducción de un decorador de inferencia. Hacer esto es equivalente al with torch.no_grad(). Básicamente vaciaremos nuestro dataloader al modelo, aplicaremos la sigmoide que no colocamos en nuestro modelo e increiblemente descargando las predicciones a la CPU funcionó más rápido que la GPU (esto porque evita el overhead de subir los datos a la GPU para poder predecir).

@torch.inference_mode()
def predict(model, dm):
    model.eval()
    preds = []
    for item in dm.test_dataloader():
        
        pred = torch.sigmoid(model(item['users'], item['movies']))
        preds.extend(pred.cpu().detach().numpy())
        
    return preds

Luego convertimos todo en un Numpy Array para poder incluirlo en nuestro full_test_df.

predictions= np.array(predict(recommender, dm))
print(predictions.shape)
full_test_df['preds'] = predictions
full_test_df

(6078000, 1)

	userId	movieId	rating	preds
734	0	230	1.0	0.987030
1066	1	929	1.0	0.749257
2855	2	465	1.0	0.911151
2889	3	2505	1.0	0.973490
3015	4	9907	1.0	0.959640
...	...	...	...	...
6017215	60779	2442	0.0	0.006992
6017216	60779	10800	0.0	0.003167
6017217	60779	17767	0.0	0.000137
6017218	60779	7073	0.0	0.000070
6017219	60779	2124	0.0	0.000730

6078000 rows × 4 columns

Para evaluar el modelo utilizaremos la métrica HitRatio@10. Esto quiere decir que si dentro de las 10 mejores predicciones por usuario, el usuario tiene la película vista entonces eso es un éxito.

recomendations = full_test_df.sort_values(by = ['userId','preds'], ascending=[True, False]).groupby('userId').head(10)

En uno de los artículos que ví como referencia encontré la siguiente implementación:

# User-item pairs for testing
test_user_item_set = set(zip(test_ratings['userId'], test_ratings['movieId']))

# Dict of all items that are interacted with by each user
user_interacted_items = ratings.groupby('userId')['movieId'].apply(list).to_dict()

hits = []
for (u,i) in test_user_item_set:
    interacted_items = user_interacted_items[u]
    not_interacted_items = set(all_movieIds) - set(interacted_items)
    selected_not_interacted = list(np.random.choice(list(not_interacted_items), 99))
    test_items = selected_not_interacted + [i]
    
    predicted_labels = np.squeeze(model(torch.tensor([u]*100), 
                                        torch.tensor(test_items)).detach().numpy())
    
    top10_items = [test_items[i] for i in np.argsort(predicted_labels)[::-1][0:10].tolist()]
    
    if i in top10_items:
        hits.append(1)
    else:
        hits.append(0)
        
print("The Hit Ratio @ 10 is {:.2f}".format(np.average(hits)))

Sólo al verla me dio dolor de estomago, porque no la entiendo. Una manera mucho más sencilla es esta:

Sabemos que sólo hay un 1 en cada usuario, por lo tanto recomendations.rating.sum() nos dirá cuantas películas efectivamente vistas por nuestro usuario están en las 10 mejores recomendaciones. Si eso lo dividimos por el número de usuarios entonces tenemos el HitRatio@10

recomendations.rating.sum()/recomendations.userId.nunique()

0.9457880881869036

¿Cómo Utilizamos el Modelo?

Bueno para poder operacionalizar el modelo entonces tenemos que llevar a nuestros Ids originales:

def back_to_normal(df, user_encoder, movie_encoder, movies_mapping):
    
    idx_movies = df.movieId.tolist()
    idx_users = df.userId.tolist()
    return pd.DataFrame(dict(userId = user_encoder.classes_[idx_users],
                    movieId = pd.Series(movie_encoder.classes_[idx_movies]).map(movies_mapping),
                    rating = df.rating.tolist()))

vistos= back_to_normal(train_ratings, user_encoder, movie_encoder, movies_mapping)
visto.shape

(2651157, 3)

recomendar = back_to_normal(recomendations, user_encoder, movie_encoder, movies_mapping)
recomendar.shape

(607800, 3)

visto corresponderá a las películas ya vistas por nuestro usuario, y recomendar a las 10 mejores recomendaciones. Ojo que agregamos el movies_mapping del principio para poder tener el nombre de la película y no sólo el Id.

Revisemos entonces algunas recomendaciones:

Al revisar los resultados me dí cuenta que sé muy poco de películas (a excepción de las películas de Marvel) pido perdón de antemano si mi análisis es un poco pobre, pero no soy muy cinéfilo XD.

Por ejemplo, el usuario 4 parece que le gustan las películas de acción y ciencia ficción. Correctamente predijimos John Carter, que es la película que vio y además dado que ha visto varias películas del MCU se le recomienda ver Thor 2 (que es muy mala película, pero bueno, nada que hacer).

user = 4
print(visto.query('userId == @user')['movieId'])
recomendar.query('userId == @user')

                              Shutter Island (2010)
  Percy Jackson & the Olympians: The Lightning T...
                    How to Train Your Dragon (2010)
                         Clash of the Titans (2010)
                                  Iron Man 2 (2010)
                             ...                        
           Spider-Man: Into the Spider-Verse (2018)
           John Wick: Chapter 3 – Parabellum (2019)
                  Pokémon: Detective Pikachu (2019)
                             Ford v. Ferrari (2019)
       Fast & Furious Presents: Hobbs & Shaw (2019)
Name: movieId, Length: 115, dtype: object

	userId	movieId	rating
10	4	Thor: The Dark World (2013)	0.0
11	4	Margin Call (2011)	0.0
12	4	Kubo and the Two Strings (2016)	0.0
13	4	John Carter (2012)	1.0
14	4	Autómata (Automata) (2014)	0.0
15	4	You Were Never Really Here (2017)	0.0
16	4	Aloha (2015)	0.0
17	4	Thanks for Sharing (2012)	0.0
18	4	Eva (2011)	0.0
19	4	Magic Mike XXL (2015)	0.0

El usuario 6225 parece que le gustan las películas de Romance, Miedo y Suspenso, y se recomienda correctamente Midnight in Paris que no tengo idea de qué trata pero podemos ver otras recomendaciones como Saw (Miedo), Friends with Benefits o Aladdin que serán medio Romance/Fantasía supongo.

user = 6265
print(visto.query('userId == @user')['movieId'])
recomendar.query('userId == @user')

100326    Cabin in the Woods, The (2012)
100327                Snowpiercer (2013)
100328                  Gone Girl (2014)
100329         The Imitation Game (2014)
Name: movieId, dtype: object

	userId	movieId	rating
22630	6265	Midnight in Paris (2011)	1.0
22631	6265	Friends with Benefits (2011)	0.0
22632	6265	Saw VII 3D - The Final Chapter (2010)	0.0
22633	6265	Searching (2018)	0.0
22634	6265	Aladdin (2019)	0.0
22635	6265	The Dark Tower (2017)	0.0
22636	6265	The BFG (2016)	0.0
22637	6265	ARQ (2016)	0.0
22638	6265	A Wrinkle in Time (2018)	0.0
22639	6265	Magic of Belle Isle, The (2012)	0.0

El usuario 63 es como mi esposa, le gustan las películas livianitas, de monitos o para reirse, Tangled, Inside Out o Pitch Perfect sólo pueden recomendar algo como The Twilight Saga: Eclipse.

user = 63
print(visto.query('userId == @user')['movieId'])
recomendar.query('userId == @user')

                            Easy A (2010)
                           Tangled (2010)
                       Bridesmaids (2011)
                   Horrible Bosses (2011)
              Crazy, Stupid, Love. (2011)
                    21 Jump Street (2012)
                     Pitch Perfect (2012)
  Perks of Being a Wallflower, The (2012)
                 Great Gatsby, The (2013)
                    Now You See Me (2013)
                 We're the Millers (2013)
                        About Time (2013)
          Wolf of Wall Street, The (2013)
                         Gone Girl (2014)
                        Inside Out (2015)
                              Room (2015)
                             Moana (2016)
                              Coco (2017)
Name: movieId, dtype: object

	userId	movieId	rating
200	63	Spotlight (2015)	0.0
201	63	Twilight Saga: Eclipse, The (2010)	1.0
202	63	Sorcerer's Apprentice, The (2010)	0.0
203	63	Melancholia (2011)	0.0
204	63	Oz the Great and Powerful (2013)	0.0
205	63	Venom (2018)	0.0
206	63	Selma (2014)	0.0
207	63	Burlesque (2010)	0.0
208	63	Silent Hill: Revelation 3D (2012)	0.0
209	63	Double, The (2011)	0.0

El usuario 162532 es de los míos, harta película de Acción, del MCU y como de Niños (Despicable Me) y se recomienda Guardians of the Galaxy (muy buena película) y Spy Kids que es de Acción e Infantil que también es rebuena.

user = 162532
print(visto.query('userId == @user')['movieId'])
recomendar.query('userId == @user')

2650878                      How to Train Your Dragon (2010)
2650879                                      Kick-Ass (2010)
2650880                    Exit Through the Gift Shop (2010)
2650881                                    Iron Man 2 (2010)
2650882                                 Despicable Me (2010)
2650883                                     Inception (2010)
2650884                   Scott Pilgrim vs. the World (2010)
2650885                           Social Network, The (2010)
2650886                                        Easy A (2010)
2650887    Harry Potter and the Deathly Hallows: Part 1 (...
2650888                            King's Speech, The (2010)
2650889                                   Source Code (2011)
2650890                                          Thor (2011)
2650891                            X-Men: First Class (2011)
2650892    Harry Potter and the Deathly Hallows: Part 2 (...
2650893            Captain America: The First Avenger (2011)
2650894                                 Avengers, The (2012)
2650895                                          Hugo (2011)
2650896                              The Hunger Games (2012)
2650897                        Dark Knight Rises, The (2012)
2650898            Sherlock Holmes: A Game of Shadows (2011)
2650899                                  Intouchables (2011)
2650900                                        Looper (2012)
2650901                                          Argo (2012)
2650902                       Silver Linings Playbook (2012)
2650903            Hobbit: An Unexpected Journey, The (2012)
2650904                                    Iron Man 3 (2013)
Name: movieId, dtype: object

	userId	movieId	rating
607750	162532	Guardians of the Galaxy (2014)	1.0
607751	162532	Only the Brave (2017)	0.0
607752	162532	Immigrant, The (2013)	0.0
607753	162532	Diary of a Wimpy Kid: Rodrick Rules (2011)	0.0
607754	162532	Spy Kids: All the Time in the World in 4D (2011)	0.0
607755	162532	The Belko Experiment (2017)	0.0
607756	162532	All the Way (2016)	0.0
607757	162532	Come Together (2016)	0.0
607758	162532	Batman: Gotham by Gaslight (2018)	0.0
607759	162532	Kizumonogatari Part 1: Tekketsu (2016)	0.0

Conclusiones

Creo que el Modelo funciona sumamente bien. Cabe destacar que estamos haciendo el trabajo bien dificil porque en estricto rigor nosotros deberíamos predecir el Rating de todas las películas del catálogo y entregar las 10 mejores, y estamos haciendo un random de 99 películas que puede que no tengan nada que ver con el usuario y aún así el modelo es capaz de ordenar las predicciones de buena manera.

Es interesante que gran parte del modelo de Recomendación tiene que ver con el manejo de la data y cómo vamos a operacionalizarlo. No es llegar y hacer un predict sino que es necesario pensar en una estrategia para poder mostrar esto.

Una de las ventajas de este tipo de modelo es que podemos tener todas las predicciones hechas por ejemplo en la noche y luego operacionalizarlas en nuestro front-end. Esto es beneficioso también en el sentido que una inferencia en tiempo real para semejante cantidad de datos es difícil.

Una desventaja de este tipo de modelos es que sólo pueden entregar recomendaciones a los usuarios que ya han visto películas y que ya se encuentran en la user-item matrix. Esto es lo que se conoce como el cold-start problem. No sé muy bien como se soluciona pero en la forma en la que se planteó esta solución no es posible decir me gusta A, B, C, entonces, ¿qué me recomiendas? Deben existir otro tipo de modelos que sí pueden lidiar con esto, pero que no manejo.

Eso es todo por esta semana, espero les haya gustado y gracias Gustavo, aprendí harto de Sistemas Recomendadores (aunque me sacó canas verdes) durante este fin de semana.

Hasta la otra,

Alfonso

Github para Data Science Pt. 3

2022-04-11T00:00:00+00:00

Siguiendo un poco con la racha de tutoriales dedicado al uso de Github, hoy quiero hablar de un tercer punto que creo que es importante que es la automatización al momento de productivizar. Yo soy Data Scientist, pero me gustaría mucho en el futuro cercano trabajar como Machine Learning Engineer y creo que una de las cosas más importantes de aprender en el desarrollo de software es CI/CD.

CI/CD

Corresponde a la sigla para Continuous Integration / Continuous Delivery y en el desarrollo de software se usa para automatizar tareas que siempre deben de ejecutarse para asegurar que el producto a productivizar es infalible, ojalá libre de errores y que pasa todos los test de calidad que el mismo proyecto se ha impuesto. Normalmente el Proceso de CI/CD incluirá procesos de Unit Testing, Deploy, Dockerización y un largo etc.

Cuando pensamos en el desarrollo de Machine Learning es un poco distinto. Hoy no quiero hablar de cómo hacer el deploy y el proceso de MLOps que uno debería seguir, sino más bien de cómo poder automatizar el proceso de Experimentación y que pueda ser revisado de manera más amena.

Pongo el siguiente caso (porque lo he vivido):

Tengo un proyecto.
Tengo un Product Owner, que normalmente no entiende nada de código (esto me parece que no debiera ser así y deberían empezar a interiorizarse más en el tema. Siempre se habla de que el DS tiene que entender del negocio para poder explicar a los stakeholders, pero el negocio nunca hace un esfuerzo por entender lo técnico, en fin, pelea para otro día).
El Product Owner quiere entender si tenemos alguna mejora, es decir, si el modelo está mejorando o no.
Cita a una Reunión en la que hay mostrarle el Jupyter Notebook y llegamos a las métricas finales.
Finalmente el interés del PO es: ¿Mejoramos el Accuracy/Recall/Valor para el negocio/etc. o no?

Y la reunión termina con un ¿y probaste X, probaste Y o probaste Z? ¿Mejora o no? Y uno rápidamente tiene que ponerse a corregir el notebook en vivo o citar a otra reunión para volver a tener la misma conversación y mostrar los nuevos resultados.

Bueno, creo que todo este proceso tedioso podría hacerse de manera asíncrona, sin perder tiempo en reuniones y tener la discusión en un Pull Request (que creo que es algo que un PO debería poder saber qué es, cómo hacerlo y cómo interactuar con él).

iterative.ai desarrolló una herramienta llamada CML una herramienta para Continuous Machine Learning.

Si bien creo que es una herramienta bastante básica y en pleno desarrollo, creo que aporta con varios elementos que nos permiten solucionar el problema que expongo anteriormente. Es fácil de usar y cumple su objetivo que es lo más importante de todo que es generar reportes, en medio del Pull Request para mostrar en simple los avances del código del modelo.

CML funciona con Github Actions. Github Actions es la herramienta que Github provee para hacer CI/CD. Github Actions básicamente crea una maquina virtual (VM) de manera automatizada donde se ejecutarán los comandos que uno le indique. Estos comandos pueden ejecutarse cada vez que se hace un commit, push, PR, etc. Dentro de esa VM nosotros ejecutaremos CML, el cual nos permitirá crear dicho reporte con lo que nosotros indiquemos.

Creo que CML se puede utilizar para bastantes cosas más, pero aún estoy aprendiendo y haciendo pruebas de en qué flujos podría ser una alternativa.

CML es compatible también con Gitlab CI, y tiene una imagen Docker prefabricada, por lo que en caso de tener Circle CI, Travis CI, Jenkins o cualquier otra alternativa de CI/CD también debería ser posible utilizarlo.

Github Actions

Bueno Github Actions está disponible en cualquier repositorio de Github. Basicamente una Action es un Script que permite crear un ambiente virtual en el que podemos tener cosas pre-instaladas, o podemos cargar una imagen Docker. Todo usuario de Github tiene gratis varios minutos al mes de Github Actions, luego de esa cuota se empieza a cobrar para tener acceso a minutos adicionales. Si les interesa pueden ver los precios acá.

Acabo de volverme Github Pro y eso aumenta la cuota de minutos mensuales de 2000 a 3000, que creo que para un usuario normal es suficiente. En el caso de empresas es recomendable que tenga un plan.

Entonces para utilizar Github Actions basta con que tu repo contenga una carpeta llamada .github/workflows. Dentro de esta carpeta crearemos un archivo yaml, el cual puede tener cualquier nombre.

Para mostrar esto con ejemplos concretos utilizaremos el Repo utilizado en el tutorial de DVC. Además para seguir un correcto uso de GIT crearé una Rama llamada CML:

$ git checkout -b CML

Dentro de esta rama crearé el siguiente archivo ´cml.yaml´:

name: train-my-model
on: [push]
jobs:
  train-model:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - uses: iterative/setup-cml@v1
      - uses: actions/setup-python@v2
        with:
          python-version: '3.x'
      - name: Train model
        env:
          repo_token: $
        run: |
          pip3 install -r requirements.txt
          dvc repro
          # Create CML report
          echo "## Metrics" >> report.md
          dvc metrics show --show-md >> report.md
          cml publish conf_mat.png --md >> report.md
          cml send-comment report.md

Este archivo puede verse muy complejo de entender, pero paso a explicar parte por parte en detalle:

name: No es nada más que el nombre que yo le doy a mi proceso, no afecta a mi proceso de CI/CD.
on: Esto indica cuando se va a ejecutar la Action. En este caso esto se va a ejecutar siempre y cuando haga un push. Pero existen distintas opciones que se pueden ver acá. Github actions es tán flexible que se pueden ejecutar en distintos eventos, en ramas específicas, etc.
Luego jobs especificará qué hará el proceso:
- runs-on: Indica en qué ambiente correrá. En este caso se indica una maquina virtual con ubuntu-latest. Lo más común es usar ubuntu ya que es lo más barato y fácil, otras opciones incluyen Windows y MacOs que son más caras. En mi opinión Ubuntu es suficiente a menos que tengas dependencia de OS, por ejemplo, si estás desarrollando un app para Mac y tiene que probarse en dicho OS.
- steps: Indica qué se va a instalar en la VM. Hay que entender la VM es una maquina creada de cero, no tiene nada.
- uses: Son las Actions predefinidas que se van a cargar, esto normalmente sirven como preparación del ambiente:
  - actions/checkout@v2: Esto lo que hace es cargar toda la Info del commit para que esté disponible en la maquina. Si no hacemos esto, nuestros scripts no pueden ser vistos por la VM.
  - iterative/setup-cml@v1: Esta instala CML, y está indicado en la Documentación de CML como una línea obligatoria.
  - actions/setup-python@v2: Instala Python. Tengo dudas si este paso es realmente necesario porque en la Doc dice que la Action de CML ya tiene Python incluido, pero igual en su ejemplo usan este paso.
- name: Este otro name ahora indica el nombre de una etapa. Uno eventualmente puede dividir su Action en varias etapas.
- env: Declara variables de entorno.
  - repo_token: $ Esta es una variable de entorno propia del Repo de Github. La razón de agregarla es que para que CML pueda comentar dentro del PR que vamos a generar.
- run: Finalmente este comando permite ejecutar cualquier tipo de comando válido en la VM.

Modificaciones en esta Rama

Aparte de que nuestra rama agrega cml.yaml para configurar Github Actions, hicimos las siguientes modificaciones:

Creamos un archivo requirements.txt para definir las dependencias de nuestro proyecto. Esto es importante ya que, como dijimos anteriormente, nuestra VM de Github Actions no tiene nada instalado.

gdown
pandas
dvc
scikit-learn
matplotlib

Modificamos nuestro script src/04-evaluate_model.py de la siguiente forma:

import json

import joblib
import pandas as pd
from sklearn.metrics import accuracy_score, recall_score, ConfusionMatrixDisplay
import matplotlib.pyplot as plt

from config import Config

X_test = pd.read_csv(Config.FEATURES_PATH / 'test_features.csv')
y_test = pd.read_csv(Config.FEATURES_PATH / 'test_labels.csv')

model = joblib.load(Config.MODELS_PATH / 'model.joblib')
y_pred = model.predict(X_test)

output = dict( test_accuracy = accuracy_score(y_test, y_pred),
    test_recall = recall_score(y_test, y_pred, average='macro'))

with open(Config.METRICS_PATH, 'w') as outfile:
    json.dump(output, outfile)

ConfusionMatrixDisplay.from_predictions(y_test, y_pred)
plt.title("Confusion Matrix for NBA Positions.")
plt.xlabel("Posiciones Predichas")
plt.ylabel("Posiciones Reales")
plt.savefig('conf_mat.png')

Básicamente sólo importamos matplotlib y agregamos una Matriz de Confusión la cual guardamos como conf_mat.png. Ojo, Scikit-Learn cambió su API gráfica de curvas desde la versión 1.0. Personalmente me gustó mucho la nueva API, ya que permite crear curvas from_prediction, from_model y como clase. Para entender más como funciona la nueva interfaz pueden ir acá.

Entonces teniendo estos cambios nuestro run, que quizas es la única parte que nos corresponde modificar al momento de setear Github Actions, queda así:

Instalamos las dependencias de nuestro proyecto con pip install -r requirements.txt.
Luego hacemos dvc repro para ejecutar nuestro experimento.
Luego tenemos los siguientes comandos:
- echo “## Metrics” » report.md: Esto escribe Metrics como Título dos y lo guarda en un archivo llamado report.md
- dvc metrics show –show-md » report.md: Esto toma las métricas de nuestro modelo las convierte en formato markdown y le hace un append al mismo archivo report.md.
- cml publish conf_mat.png –md » report.md: cml publish corresponde a uno de los comandos de CML, tomará en este caso el archivo .png y lo inserta en el archivo report.md. Publish se utiliza sólo con imágenes.
- cml send-comment report.md tomará nuestro archivo y lo publica como un comentario en nuestro Pull Request.

Al hacer los cambios mandamos todo a Github:

$ git add .
$ git commit -m 'Adding CI/CD'
$ git push --set-upstream origin CML

Al ejecutar esto, creamos el Pull Request. Si ahora vamos a Github en la pestaña Actions veremos algo así:

En este caso el workflow posee el Mensaje del Commit, la Rama y un color que puede ser Rojo si falla, Amarillo cuando se está ejecutando y verde cuando se ejecutó sin problemas.

Al clickear en el Workflow encuentran esto:

En este caso vemos, el nombre de la etapa Train Model se transforma en train-model y nos dice que el proceso fue exitoso y duró 1m 45s. Esto es importante porque acá Github va llevando registro de nuestra cuota mensual. Si clickeamos nuevamente en train-model vemos lo siguiente:

Acá podemos ver un desglose de todo. Podemos notar que nuestro proceso de entrenamiento es el que más tiempo toma con 1m 6s debido a la instalación de las librerías más la ejecución de nuestro Pipeline. Luego lo que más demora es la instalación de CML con 25s. Ante la duda de si utilizar o no la Action con Python es indistinto ya que tomó 0 segundos.

Finalmente si volvemos al Pull Request veremos el resultado:

Podemos ver las métricas obtenidas en nuestro tutorial anterior. Y además tenemos una Matriz de Confusión, la cual podría ser útil para nuestro PO para poder evaluar si el nuevo modelo cumple con sus expectativas o no. Obviamente, esto es un ejemplo, y dependiendo del proyecto podremos definir cuales son las gráficas y métricas de interés para medir si nuestro proyecto está avanzando o no. En el caso de que este modelo cumpla con las expectativas podemos hacer el merge con Master para pasarlo como nuestro modelo actual.

Como justo terminó la temporada regular de la NBA podríamos desviarnos un poquito a analizar los resultados del modelo. No tiene que ver con el tutorial pero es importante entender para qué serviría colocar una gráfica así en el Pull Request.

Dijimos que la intención del modelo es poder entender de acuerdo a las estadísticas del jugador, cuál podría ser una posición adecuada. Si miramos nuestras métricas, son pésimas, pero ¿quiere decir que nuestro modelo es realmente inservible?

Si analizamos la Matriz de Confusión que está hecha para el Test Set, podemos notar que nuestro modelo tiene grandes problemas para diferenciar, por ejemplo, un Centro (C) de un Power Forward (PF). Y tiene razón, hoy en día el Centro (C) es una pieza fundamental en el ataque no sólo como el reboteador del equipo y quien hace las pantallas, sino como anotador y pasador (algunos hasta anotando triples). En mi opinión, Anthony Davis (PF), Giannis Antetokounmpo (PF), Nikola Jokic (C) y Joel Embid (C) son el mismo monstruo. Tipos gigantes y atléticos (Jokic un poco menos) pero extremadamente completos, que sólo juegan en esas posiciones por su altura y poder, pero podrían jugar en cualquier posición. Se entiende que en la NBA actual el modelo tenga problemas diferenciando dichas posiciones.

Por otro lado, se ve una tremenda confusión entre los PF, SG y PG. Y en mi opinión la NBA actual ya no sigue para nada dichas posiciones. Los Point Guards (PG) solían ser tipos pequeñitos muy hábiles que destacaban por su habilidad para pasar (recordar John Stockton, Tony Parker, Steve Nash, Jason Kidd). Hoy son el show de cada partido: Steph Curry, Ja Morant, Chris Paul, Kyrie Irving. Si bien algunos siguen el esterotipo, podrían perfectamente jugar de SG o SF por su habilidad anotadora si tuvieran mayor corpulencia. Por el otro lado, los SG eran los anotadores con buen dominio de balón y los SF eran Anotdores, robustos que no tenían tanta habilidad en el dribble pero hoy: Lebron James (SF), Kevin Durant (SF), Kawhi Leonard (SF), James Harden (SG), Donovan Mitchell (SG) o Devin Booker (SG), son jugadores prácticamente intercambiables. Son tan completos que la única razón por la que no juegan de PF o C es su altura o robustez, pero en muchas ocasiones durante partidos se les ve ejerciendo el rol de armador (PG).

Con esto no quiero defender al modelo, efectivamente sus métricas están mal, pero analizando una simple Matriz de Confusión más un poquito de Conocimiento del Juego se pueden obtener muy buenos insights para mejorar el modelo (y obtener valor). Por ejemplo, incluir altura y peso para definir de mejor manera las posiciones dentro de la cancha, ya que diría que hoy ya no es un tema de habilidad, sino más bien de corpulencia.

Setear un Action la primera vez no es fácil, de hecho pueden ir a mi tab de Actions para ver todas los workflows fallidos que tuve antes de encontrar la combinación correcta. Lo bueno es que una vez que la configuración está correctamente hecha no hay que preocuparse más

¿Cómo Combinar CML con la Interfaz de Experimentación?

Uno de los flujos que consideré que podía ser bueno utilizar CML es para experimentar. Lamentablemente me encontré con un muro. Mi idea era utilizar el Workflow para ejecutar todas los experimentos y generar un reporte de todo lo obtenido con el fin de que todo se hiciera en la maquina virtual y no en mi maquina, cosa que yo pudiera seguir trabajando.

Github Actions permite utilizar self-hosted servers, es decir podríamos correr estos procesos en un servidor propio o incluso en máquinas Cloud (esto queda para una futura iteración)

Lamentablemente, CML no está pensado para experimentar y luego de muchas pruebas fallidas intentando correr experimentos me di cuenta de que no se podía. Aún así llegué al siguiente flujo el cual se puede ver en mi rama rama-experimental. la Documentación de DVC y CML no estaba preparada para esto. Intentando muchas pruebas no encontré solución, por lo que decidí abrir un issue en el repo de DVC que pueden ver acá.

La verdad es que tenía pensado sacar este tutorial la semana anterior, pero al encontrarme con esto decidí que no era buena idea. De hecho en un momento hasta pensé que no valía la pena aprender CML. Pero gracias a la ayuda de los mantenedores logramos sacar el tutorial adelante.

Por lo tanto, para poder generar una interfaz remota de experimentación crearemos una nueva rama:

$ git checkout -b rama-experimental

En esta rama considero los mismos cambios de la Rama CML pero agrego los siguientes:

Cree el archivo exp_file.sh en el cual setié experimentos:

dvc exp run --queue -S train.C=5
dvc exp run --queue -S train.C=30
dvc exp run --queue -S train.C=60
dvc exp run --queue -S train.C=120

dvc exp run --run-all

Como se puede ver, generé 4 experimentos en el cual pruebo los valores C=5,30,60,120. El flag --queue permite generar una cola de experimentos los cuales se correrán con dvc exp run --run-all lo cual puede ser súper útil para dejar ejecutando e irse a descansar.

Luego para poder hacer correr la interfaz de experimentación en Github Actions tuve que modificar el cml.yaml de la siguiente manera:

name: experiments
on: [push]
jobs:
  train-model:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
        with: 
          fetch-depth: 0
      - uses: fregante/setup-git-user@v1
      - uses: iterative/setup-cml@v1
      - uses: iterative/setup-dvc@v1
      - uses: actions/setup-python@v2
        with:
          python-version: '3.x'
      - name: Experiment
        env:
          repo_token: $
        run: |
          pip3 install -r requirements.txt
          bash exp_file.sh

          echo "## Resultados del Experimento" >> report.md
          dvc exp show --only-changed --drop 'assets|src' --no-pager --md >> report.md

          cml send-comment report.md

De acuerdo a los comentarios en el issue, dvc exp run requiere la historia de GIT completa y no sólo un shallow-clone. Por defecto actions/checkout@v3 hace un checkout sólo del commit actual, lo que no es suficiente. Agregando el fetch-depth: 0 tenemos la historia completa que permite a DVC funcionar correctamente.

Durante esta semana salió actions/checkout@v3 que tiene unas mejoras de performance respecto actions/checkout@v2. Yo probé todos los workflows probando ambas y cualquiera que quieras utilizar funciona bien siempre y cuando se agregue el fetch_depth: 0.

Al intentar esto, me dí cuenta de que DVC necesita conectarse con tu cuenta de GIT. Y lamentablemente dentro de la maquina virtual DVC no tiene tus credenciales de GIT. Para solucionar esto, encontré otra action que lo hace, con lo que basta agregar la línea uses: fregante/setup-git-user@v1 y asunto solucionado.

Finalmente indagando dentro de la documentación de DVC encontré que desarrollaron un Action para instalar DVC de manera más rápida que el pip install. Aplicamos dicho paso utilizando la línea uses: iterative/setup-dvc@v1.

Aún así tuve que dejar DVC como dependencia ya que pip install dvc instala el paquete yaml, el cual es dependencia para usar parámetros. Lo dejé mencionado en el issue y espero pronto se solucione eso.

Subiendo los cambios a Github y siguiendo el mismo procedimiento anterior obtuve lo siguiente en mi Pull Request:

Creo que este puede ser un buen flujo para poder dejar documentado cuales fueron los avances que he ido teniendo junto con visualizaciones y métricas que me interesan para poder medir el impacto del modelo. En el caso de que algún set de hiperparámetros me guste los dejo fijos en el siguiente commit y ejecuto dvc repro para generar el primer reporte que mostramos en el tutorial.

Investigando para solucionar el flujo de experimentación me encontré que Github Actions es una herramienta muy poderosa. Hay muchas ideas que encontré para poder dejar un flujo automatizado completamente en la interfaz de Github por lo que a medida que vaya implementando más cosas las iré compartiendo. CML por su parte nos ayudará a generar el reporte y agregar nuestras imágenes de manera sencilla como comentario.

Como siempre, pueden ir a mi Github y en especial a este Repo. En este caso dejé todas las ramas y los Pull Requests para que puedan seguir todo el flujo que seguí al construir este tutorial. También decidí no eliminar todos los intentos fallidos de Actions por lo que pueden ir revisando lo que les interese.

Espero que este tutorial les haya gustado y nos vemos a la próxima.

Alfonso