Ayer estuve de birras con dos de los científicos de datos que más respeto y, como suele ser habitual, nos lo pasamos bien y echamos un buen rato de conversación.
El caso es que uno de ellos comentaba algo que debería ser obvio para todos los que estamos en este mundillo y es que “los modelos por sí solos no dan pasta”.
Lo ejemplifico con un sencillo ejemplo. Supongamos que nos encargan como científicos de datos hacer uno de esos modelos de “churn” o de riesgo o cualquier otra cosa, y que nosotros de forma diligente, hacemos un modelo chachi piruli.
En un post anterior ya vimos como entrenar un modelo de h2o y cómo sería la lógica para hacer predicciones en un entorno que tenga Spark pero no h2o.
Un lector del blog comentó que porque no usar directamente H20 con sparkling water y leer directamente los datos a partir de un sparkdataframe y predecir también usando sparkling water. Aquí varios motivos.
Por mi escasa experiencia con sparkling water existe un cuello de botella al pasar de sparkdataframe a h2oframe.
Para todo áquel que quiera saber de que va esto de la Inferencia Bayesiana con INLA le recomiendo que le eche un vistazo a este libro de Virgilio Gómez Rubio. Bayesian Inference with INLA and R-INLA
Cómo dice un amigo mío, si no tenemos en cuenta la estructura se palma pasta, y la estadística bayesiana va de esto, de considerar la estructura. El libro da ejemplos de cómo usar INLA para modelos lineales, lineales generalizados, modelos mixtos, modelos multinivel, modelos espaciales, modelos temporales, análisis de supervivencia, modelos GAM o modelos con mezcla de distribuciones.
Voy a comentar por encima lo que se viene llamando “codificación por impacto”, la idea es codificar una variable categórica predictora usando la información del “target”, evidentemente este tipo de codificación sólo sirve cuando tenemos un modelo en mente y dicen que es útil si tenemos variables categóricas con alta cardinalidad.
La idea es muy sencilla, para cada nivel de la variable categórica le asignamos su media de target, por ejemplo, (o la media(u otra medida) menos la media general)
Hablábamos el otro día mi amigo Carlos y yo sobre los modelos mixtos y el uso de lme4, Stan o INLA. Total, que el problema es que queríamos un atajo que permitiera tener una estimación de los efectos aleatorios en un tiempo menor que lo que queda hasta el fin del universo.
Pues nada, investigando vi que existía una librería en Julia llamada MixedModels y que es del autor de lme4 así que me puse a probar a ver si es verdad el lema de Julia, “tan rápido como C, tan fácil como Python”.
Voy a hacer una serie de entradas sobre codificación de variables categóricas, mi idea es pasar desde la codificación parcial (OneHot Encoders para los modernos), hasta utilizar embeddings. Vamos al lío.
Tradicionalmente, si tenemos una variable categórica con 5 niveles se codifica en tantas variables cero uno como niveles menos uno, puesto que uno de los niveles se toma como referencia y se codifica con todo 0’s en las varaibles indicadoras.
Tengo la suerte de haber trabajado con algunos de los mejores arquitectos big data que hay en España y de considerarlos mis amigos. Para mí, este es el perfil clave en el éxito o fracaso de cualquier proyecto de Big Data y por desgracia es el perfil más complicado de encontrar.
Un buen arquitecto big data es justo el pegamento que une los mundos del ingeniero de datos y el de los mal llamados data scientist.
La verdad es que no sé como traducir el término “lookup table”, en fin, vamos al grano.
Supongamos que tengo un factor con 3 niveles o un vector de caracteres con 3 letras únicas y 20 valores.
set.seed(43) vector_largo <- sample(c("a","b","c"), size = 20, replace = TRUE) vector_largo ## [1] "b" "c" "a" "c" "a" "b" "c" "b" "a" "c" "b" "a" "b" "a" "b" "c" "a" ## [18] "a" "a" "a" Y que en otro sitio tengo un vector “con nombres” dónde tengo el valor que asigno a “a”, “b” y “c”
Supongo que ya ni los más viejos del lugar recuerdan el tiempo en que había protestas contra la incorporación de tractores y cosechadoras al mundo rural. Total, ¿para qué? la funcionalidad ya estaba cubierta con los jornaleros. El caso es que al final el “progreso” se fue imponiendo, haciendo desaparecer muchos puestos de trabajo y creando otros nuevos, sinceramente creo que en términos netos hemos salido ganando.
En esto de la ciencia de datos también tenemos nuestra tecnología y además, cambian a la velocidad del rayo, que si R, python, spark, h2o, apache flink, cosas como datarobot o driverless, sin olvidar a los aún hoy vivos SAS, MATLAB, SPSS, stata y alguno más que habrá por ahí.
Un amigo mío suele comentar que si no tienes en cuenta la estructura, palmas pasta. Así que hoy estoy leyendo capítulos sueltos de Doing Bayesian Data Analysis.
El libro está bastante bien y me encanta la foto de portada, lo único que está más enfocado a usar JAGS y de Stan no cuenta mucho, pero para eso ya está la completa documentación de Stan.
Sigo con la lectura, buen domingo.