Para hacer un proyecto relacionado con los datos no es necesario mucho armamento. En primer lugar necesitamos datos, luego necesitamos alguna persona con conocimientos de desarrollo informático, lo que son recursos que se pueden conseguir. Hay otras cosas que no son tan fáciles de conseguir, o no son tan rápidas, que son tener un conocimiento de la materia en la que trabajamos y, sobre todo, tener un sentido crítico y escéptico. Es decir, como veremos la parte mecánica se aprende y la parte instrumental se encuentra, pero lo demás es algo que precisa oficio, comprensión y evitar la autocomplacencia. En todo caso, la idea de este post es contar un poco las etapas habituales y qué tipo de problemas pueden aparecer en la vidacuando aplicamos la ciencia de datos en las AAPP para llevarlo adelante.
Buscar el problema
Recuerdo que el mejor profesor de metodología que tuve nunca decía que toda investigación parte de la definición del problema y que eso se olvida fácil. La falta de una definción de un problema hace que, en el mejor de los casos, la investigación sea superflua (no sirve para nada) cuando no genera resultados realmente aberrantes. El problema nos debe:
- Poner sobre la mesa las piezas del tema que tratamos. Es decir qué elementos consideramos que afectan a lo que nos interesa.
- Afectar a algo que podamos arreglar o entender. Si alguno de vosotros ha tenido la suerte (o desgracia) de tenerme en clase habrá escuchado que la diferencia entre un problema y una catástrofe es la que hay entre Armageddon y Melancolía. Un problema debe tener algo de accionabilidad.
- Tener alguna idea de lo que pasa. Se que en la metodología nos dicen que no tienes nada hasta que no tienes una hipótesis. En mi experiencia esto es mentira: para llegar a la hipótesis hay que tener alguna idea previa de qué es lo que pasa. La diferencia entre alguien que investiga y que no investiga es que quien investiga hace conjeturas y quien no, se queda con la duda. Una persona que investiga con experiencia puede hacer más y mejores conjeturas más rápido.
Lo que puede ir mal en la definición del problema en las AAPP.
Normalmente los fallos en la definición de un problema en las AAPP está relacionada con dos variables. Por un lado, quien define el problema no tiene una idea muy profunda sobre el tema y tira más de voluntad que de criterio. Esta es una situación que puede venir por agenda política, por presiones externas o, simplemente por preferencias personales. Es decir, el responsable de tal dirección, servicio, concejalía (no necesariamente político), etc… entiende que el problema con una materia es de tal manera. Si ese problema le preocupa lo suficiente (que no significa que lo entienda lo suficiente) puede introducir una definición que no sea del todo exacta.
Esto no es tan grave sin el segundo: la capacidad crítica en la valoración del problema y del trabajo. Una definición del problema defectuosa no sobrevive un escrutinio en profundidad. Si un responsable público considera que, por ejemplo, que el número de suicidios está relacionado con el gasto en investigación espacial, si le damos un par de vueltas vemos que no tiene sentido. Pero, sin embargo, si esa persona esta muy casada con sus ideas (y tiene suficiente fuerza para imponerlas) esa definición llegará a ser una investigación.
No quiero decir ni que esto sea por mala intención (todos tenemos sesgos), ni que pertenezca solo a los altos responsables. El problema está en que la verticalidad de las organizaciones públicas hace que el sesgo de las personas responsables se arrastre a toda la organización. Si encima esas personas no están familiarizadas con la materia, las probabilidades de error (y de no detectar un sesgo) son más altas. Por eso muchas veces pequeños equipos o proyectos que no llaman la atención en las organizaciones públicas consiguen mejores resultados que proyectos con un alto liderazgo e implicación. hay que saber distinguir liderazgo de mandar como un chusquero.
Obtener los datos
Obtener los datos es algo complicado. Es cierto que en el sector público en España tenemos una gran cantidad de datos abiertos por AAPP. También es cierto que las AAPP tiene un montón de datos. Sin embargo, ni hay datos para todo, ni todos los datos están igual de bien. En todo caso, a veces los datos están ahí, en portales de datos o se pueden extraer de algún sitio, y otras veces hay que ir a buscarlos (por ejemplo, es lo que hacemos con la herramienta de contratos inteligentes). En todo caso, los datos disponibles (y su estado, del que hablaremos más adelante) es el primer muro con el que te topas de verdad en estos trabajos.
¿Qué puede ir mal en la obtención de datos?
Básicamente hay tres cosas estrictamente referentes a la obtención de datos en las AAPP.
- Los datos no están disponibles. Hay veces que los datos que quieres no están. Por ejemplo, llevo un tiempo con ganas de hacer un estudio de Directores Generales que no son empleados públicos de grupo A desde 1997. Conseguir escrapeando el BOE el listado de DGs no es especialmente complicado, pero no hay manera de encontrar si lo son o si no lo son (si alguien tiene una idea de cómo obtenerlo, acepto ideas)
- Los datos están disperdigados y no cubren el problema. Esto es un poco lo que nos ha pasado con todo lo del COVID y los contagios. Cada autonomía tiene sus datos y los publica a su manera, y hay cosas que no han ido incorporándose históricamente y que afectan a algunos trabajos que se podrían hacer.
- Los datos son incompletos o están desactualizados. España tiene un alto nivel de datos abiertos, pero una cosa es publicar y otra cosa es mantener. Si tienes datos sin actualizar es muy complicado tener un modelo en condiciones.
Limpieza y preparación de los datos.
La preparación de los datos es la parte posiblemente las larga, dura y pesada en un proyecto de datos. Si haces un curso y tienes ejercicios, lo más probable es que los datos estén limpios y ordenados. Incluso, si haces una encuesta y tienes algo de experiencia, tendrás unos datos fáciles de procesar y analizar. Sin embargo en la vida real tenemos datos que faltan, que no están ordenados, campos enteros de valores perdidos, integración de diferentes fuentes con datos no del todo consistentes, redundancias… Este es un trabajo técnico, pero es importante tener un ojo en él si estás haciendo parte de la investigación.
¿Qué puede ir mal?
En primer lugar que los datos requieran una integración de diferentes fuentes. Como decíamos, este es el caso de los datos del COVID en España y cómo se cuentan contagios, decesos y las actualizaciones. Esto ya obliga a tener que transformar o modificar parte de los datos para que todos digan lo mismo, al menos hasta un punto razonable. Por ejemplo, como no todas las CCAA informan al mismo ritmo de contagios, se utiliza la media diaria de los últimos 7 días para saber la evolución de casos.
Luego está el problema de los datos perdidos (no respuestas, datos que no existen, etc). Aquí es importante tener un ojo presente porque hay decisiones que tomar. A veces los datos hay que darlos por perdidos y dejarlos, y otras veces los imputamos (calculamos el valor bien sea poniendo una media o infiriéndolo de otros datos)… en todo caso, cuando lleguemos al siguiente punto, hay que tener claro todo lo que se ha hecho con los datos en su preparación porque puede afectar a nuestras decisiones.
Si volvemos al tema del COVID, cuando se fijaron criterios de cierre (qué tiempos aquellos) había gente que se quejaba de que los datos del cierre se tomaban a partir de datos «antiguos» (es decir, la media de los últimos 7 días) en lugar del día de antes. Posiblemente, tener una idea de por qué se usa esta medida y por qué el dato de un solo día no es un buen valor evitaría discusiones un poco absurdas (y muy acaloradas).
La formulación de la hipótesis.
La formulación de la hipótesis es ya cuando estamos operacionalizando el problema a partir de los datos que tenemos. Si el trabajo previo era muy técnico de datos, en este campo tenemos gente que conozca el negocioPor ejemplo, en un proyecto de grupo que tenía estábamos haciendo un modelo para estimar la recaudación de una película. Una persona del equipo cogió el campo «actores» y, aparentemente, indicaba correlación entre el número de actores y la taquilla. El problema era que el campo informaba hasta 5 y no es que indicara que la película tuviera más por tener más actores, sino que las películas sin actores informados eran más pequeñas. En mi opinión, gran parte de los problemas de los proyectos de datos vienen por una deficiente comprensión del contexto de quien lo realiza, y eso acaba generando resultados sin mucho sentido.
Formalmente se puede decir que la hipótesis se tiene que pensar antes de usar los datos. Si lo haces así, puede ser que tengas que repetir el bucle todas las veces hasta que tu hipótesis y tus datos casen. Es conveniente siempre, antes de hacer una hipótesis hacer una exploración de los datos. En ella vemos cómo funciona cada variable, cómo se distribuye, etc. Es la manera de buscar patrones para tener una idea aproximada de lo que hay.
La hipótesis nos dice qué modelo queremos usar.
Lo que puede fallar en la hipótesis
Casi siempre el problema está relacionado con un conocimiento deficiente o bien de la materia o bien de lo que informan esos datos. Esto, en principio es algo que se puede advertir si formas parte del equipo o si conoces la materia para identificar si lo que se dice tiene sentido o no, como hemos visto con la investigación aeroespacial y los suicidios.
El auténtico problema está en que un ordenador es bastante «dócil» y puede sacar conclusiones de cualquier cosa. Si Spiderman decía lo de «un gran poder conlleva una gran resposnabilidad», presentar los resultados de un proyecto de datos de AAPP (que la gente hoy en día compra casi a ciegas) tiene la responsabilidad de tener una hipótesis correcta. Por ejemplo, hace días leía este artículo sobre preferencias políticas y la cara de la gente. En principio el modelo carece de hipótesis de fondo, así que no creo que podamos hacer demasiada ciencia a partir de este trabajo.
Featurización: elegir lo que de verdad importa.
En función de la hipótesis y ya con los datos, empezamos a elegir cuáles son los datos que importan y que vamos a contemplar en el modelo. Por ejemplo, si queremos comprobar qué factores nos sirven para saber si una persona que estudia en el colegio necesita apoyo extraescorlar, podemos mirar temas como renta, nivel de estudios de los padres, trabajo, lugar de residencia, etc. A veces estos son datos directos (la renta) pero otras veces requieren algún tipo de transformación (por ejemplo, acumular el nivel educativo de los progenitores puede decirnos más que hacerlo individualmente). Es la parte más divertida del trabajo con datos (al menos para mi) y dónde está «la magia». Una buerna hipótesis hace mucho más fácil hacer una buena selección de atributos.
¿Qué puede ir mal en la selección de atributos?
En realidad a estas alturas el margen de error es proporcional a lo anterior. Si tenemos problema, datos, limpieza e hipótesis bien, esto no da margen para mucho error. En caso contrario posiblemente estemos consolidando un malentendido.
El problema más frecuente en este tipo de trabajo es la colinearidad (es decir, coger dos atributos que estén estrechamente relacionados entre sí, lo que afecta a los resultados del modelo dando una sobrerrepresentación de esas variables).
Otra cuestión añadida es la referente a temas éticos. La selección de atributos puede afectar a los sesgos o bien obviando algunos matices (renta y raza, por ejemplo) o alejándose de la causa realmente subyacente (por ejemplo, tipo de delito y tipo de condena sin tener en consideración la raza). Este tema es sensible por lo tanto por la infrarrepresentación (lo que genera sesgos) como por la sobrerrepresentación (que genera perfilados raciales). Es una cuestión que, además de afectar a la operativa (un resultado sesgado es un mal resultado), tiene que tenerse muy en cuenta en su dimensión ética.
Creación del modelo
La creación o selección del modelo es, básicamente, la selección del algoritmo que creemos que se adapta a nuestro objetivo (la resolución del problema) con los datos que tenemos. Sobre este tema hablaré en otros posts, pero vaya por delante que algo comenté aquí.
Problemas relativos a la creación del modelo
La creación o elección del modelo está muy marcado, sobre todo, por la propiedad de los algoritmos. Hay múltiples librerias de código abierto y comunitarias que pueden responder a muchos problemas. Sin embargo, también existen librerías y tecnologías propietarias. Aquí volvemos al tema de la propiedad intelectual y el coste de las licencias y el código abierto y auditable. Aunque hemos tratado el tema del software propietario, aquí hay que tener en cuenta una cosa. Igual que usar Office (o incluso un ERP) no tiene una implicación en la decisión pública, basta con tener una auditoría de seguridad del código (que no se rompe, que no desaparecen cosas, que nadie puede manipularlas sin permiso, etc.).
Sin embargo , en el tema de los algoritmos que van acarrear decisiones efectivas de una manera u otra, sean o no de pago, deben ser públicos y auditables para evitar daños mayores, más aun inadvertidos.
Entrenamiento, prueba y evaluación del modelo
Una vez que tenemos el modelo decidido toca entrenarlo, probarlo y evaluarlo.
- Entrenar el modelo consiste en dejar una serie de datos de prueba (entre el 70 y el 80%) para que aplique los coeficientes, valores y normas específicas al caso que se desarrolla.
- Probar el modelo. Con el resto de datos (entre el 20 y el 30%) se pasa el algoritmo para ver si los resultados son consistentes y significativos. Dependiendo del algoritmo y de la materia el nivel puede ir de una diferencia estadística respecto a hacer algo a mano, a tener que esperar cifras muy próximas al 100%.
- Evaluar el modelo. Aquí se compara el modelo con otros diferentes y, si procede, se combina para tener un mejor resultado.
Problemas para el entrenamiento, prueba y evaluación del modelo
Estas son cuestiones muy técnicas y muy dependientes de que los datos estén bien y de que el modelo tenga sentido con la hipótesis. En todo caso, sobre todo en modelos predictivos tenemos dos cuestiones relacionadas:
- cuál es el umbral de éxito (qué % de acierto es el que consideramos satisfactorio)
- cuándo dejamos de evaluar alternativas para optar, si procede ,por una.
Una vez más, estamos hablando de problemas más relacionados con la materia y la criticidad que con la tecnología. Por ejemplo, el algoritmo que se ha usado en Reino Unido para sustituir la selectividad (y que tuvo que retirarse) debería tener un 100% de acierto (si es que esto es posible y no estamos haciendo perfilado social) por el impacto en la vida de la gente. Ahora bien, si consideramos un algoritmo para proponer a la gente una beca podemos movernos con mayores niveles de error siempre que esto no suponga una ventaja sustancial frente a los casos que pueden dar falsos negativos o falsos positivos con un fiel reparto.
Ponerlo en marcha
Cuando ya tenemos todo listo, toca el momento de desplegar el modelo. Aquí creamos el sistema de datos para alimentar el algoritmo y ejecutarlo. Recordemos que si hemos tenido problemas para trabajar los datos, tenemos que hacer las mismas condiciones para el uso real. Es decir, eliminar campos, transformarlos y operarlos para que encajen en el modelo. A esto hay que añadirle que la alimentación de datos tiene que ser la adecuada para lo que necesitamos (por ejemplo, para decisiones a tiempo real, necesitamos datos a tiempo real). Un tema importante, además, es la magnitud de datos en las que nos movemos y su distribución. La necesidad de integrar datos de diferentes administraciones (por ejemplo) y de hacerlo en escalas importantes hace que la tecnología dependa de arquitecturas complejas de sistemas que se salen de este artículo.
¿Qué puede ir mal en la puesta en marcha?
Los problemas suelen venir de la cantidad de datos a procesar, su integración y el ritmo de procesado. Como hemos dico, en España gran parte de los datos no sólo están dispersos, sino en formatos muy heterogéneos. Incluso estando abiertos y accesibles (si lo estuvieran) hay que hacer un trabajo importante de transformación e integración para poder aplicarle un modelo.
Esto nos lleva a un segundo componente, que es alojar todo esa información de manera resiliente, segura y responsiva a la demanda, lo que nos lleva a la búsqueda, para proyectos ambiciosos, de arquitecturas grandes. Es decir, si bien hasta aquí la cosa ha sido más o menos «fácil y barata» (con un equipo humano y equipo informático bueno podemos hacer proyectos interesantes), la generalización y uso habitual a gran escala es algo que requiere una inversión en infraestructura, tecnología y personal importante.
Esto no significa que los proyectos de ciencia de datos no estén a manos de cualquier administración, sino que hacerlos de manera continua con fuentes diversas y en plazos de tiempo corto (esto es, básicamente el uso de Big Data), es algo diferente. En resumen, cualquiera puede hacer un proyecto de datos que no es lo mismo que hacer algo en big data (y muchas veces, ni se necesita).
En resumen: los desafíos de la ciencia de datos en las AAPP
Crear proyectos de datos no es algo tan difícil: requiere datos (que más o menos se tienen), tecnologías (no muy caras) y personal técnico. El único punto que requiere una inversión más «a largo plazo» es el conocimiento del sector y del servicio y en eso la Administración está más que sobrada. Evidentemente esto no es fácil ni se van a hacer proyectos como longanizas, es un proceso de aprendizaje… pero es un aprendizaje que se hace, sobre todo, sobre la marcha.
