La realidad se nos presenta como un océano de información inabarcable, inaccesible, caótico y ruidoso. Más allá de nuestra experiencia cotidiana, esta realidad se nos revela a través de terceros que nos asedian desde múltiples frentes: artículos de prensa, telediarios, tertulias radiofónicas, comentarios en redes sociales o mensajes de WhatsApp. Y en este contexto, es habitual que los hechos se entremezclen con las opiniones, cuando estas no son directamente bulos.

Los que nos dedicamos a la ciencia de datos podemos tener la sensación de poseer una poderosa linterna que allá donde apuntemos ilumina el camino hacia la verdad. Gracias a técnicas estadísticas y computacionales podemos transformar, filtrar y resumir estos flujos de datos en información a la que podemos dar un sentido. Sin embargo, al igual que el esclavo que sostenía los laureles al César recordándole su condición mortal, traigo aquí una serie de advertencias que pueden ser de utilidad a la hora de seleccionar, utilizar y analizar los datos.

Sesgo de selección de datos

Un primer consejo para los científicos de datos es evitar apuntar la linterna en la dirección equivocada, como ocurre con el sesgo de selección. Este sesgo se produce cuando, por no abrir un melón, se descartan hipótesis o preguntas muy interesantes que o bien son técnicamente complejas o cuyas respuestas pueden no gustarnos o interesarnos. Por ejemplo, si solo publicamos los resultados de experimentos que han sido exitosos y se guardan en el cajón los fallidos, puede que se esté presentando como éxito lo que se ha producido por pura casualidad.

Otra variante más malévola de este fenómeno es el cherry picking –literalmente “recolectar cerezas” –, que consiste en presentar únicamente las evidencias que te favorecen aunque haya disponibles otras muchas que van en contra de tus argumentos.

Técnicas estadísticas incorrectas para el análisis de datos

Más sutiles son los casos en los que se hacen simplificaciones o directamente un uso incorrecto de las técnicas estadísticas para el análisis de datos, que terminan tergiversando las conclusiones de los mismos. Un ejemplo prototípico es utilizar la media en vez de la mediana para resumir datos con distribuciones que no son simétricas. En lenguaje llano, si calculamos la media aritmética de los salarios de las personas que están en un bar y de repente entra Amancio Ortega, el salario medio se dispara por una sola persona. Un efecto similar ocurre cuando se informa del salario medio de los españoles. La mediana permite corregir este efecto: ordena todos los salarios de menor a mayor y calcula el salario de aquella persona que queda en el medio.

Una técnica de manipulación estadística más sofisticada es el data dredging –literalmente “dragado de datos”–, que sería la versión perversa de la minería de datos. Tomamos un conjunto de datos y empezamos a realizar todas las combinaciones posibles de transformaciones, comparaciones estadísticas y correlaciones hasta que suena la flauta y encontramos una asociación entre dos variables que damos por genuina. Esta asociación lo más probable es que sea fruto del azar. En Spurious Correlations podéis encontrar multitud de correlaciones espurias que dan asociaciones totalmente absurdas e hilarantes. Mi favorita:  la tasa de divorcios en el estado de Maine correlaciona al 99% con el consumo de margarina per cápita entre el año 2000 y el año 2009.

Otra posibilidad es que en la asociación entre las dos variables entre en juego una tercera variable que se encuentra camuflada y que es la causa de que parezca que exista una relación que no es tal. Por ejemplo, se realiza un experimento en el que un grupo recibe una pastilla cada semana durante seis meses y se compara con un grupo que no la toma. Se detecta una reducción del riesgo de infarto de miocardio en el grupo que tomó la pastilla con la consecuente alegría del grupo investigador. Sin embargo, en estudios posteriores que intentan replicar el experimento no se obtiene dicho efecto. Una revisión minuciosa del grupo del primer experimento encuentra que la gran mayoría son deportistas habituales con una dieta equilibrada.  El riesgo de infarto se ve reducido gracias a unos hábitos saludables, no a tomarse una pastilla.

Inteligencia Artificial centrada en datos

Si nos centramos en el campo de la Inteligencia Artificial, donde el uso de datos es masivo, nos encontraremos varias dificultades. Una conocida por cualquier alumno de primero de grado es el sobreajuste (overfitting) de los modelos de aprendizaje automático o machine learning, que aprenden de ejemplos que incluyen tanto los datos de entrada como la respuesta correcta.

Estos modelos, que son los más empleados en IA, tienden a sobreaprender de los datos con los que se entrenan, de hecho, cuanto más potente es el modelo, más propenso es a que le afecte el sobreajuste. Este efecto reduce la capacidad de generalizar del modelo de manera que solo funciona correctamente cuando se prueba con los mismos datos los que se ha entrenado o con datos muy parecidos.

La solución para el sobreajuste de los modelos de IA es separar del conjunto de datos de entrenamiento un conjunto de datos de validación que no se emplean para entrenar el modelo pero que permite saber si está bien calibrado. Y con esto y un bizcocho… empiezan los verdaderos problemas. Elaborar un buen conjunto de validación puede ser más difícil que la construcción del propio modelo.

Andrew Ng nos lo resume en esta charla en tres puntos:

1. El 80% del esfuerzo de un proyecto de aprendizaje automático se gasta en preparar los datos, a pesar de que el 99% de la investigación en esta área está centrada en mejorar los modelos.
2. La parte más importante en el despliegue de un proyecto en producción radica en asegurar la consistencia de los datos.
3. Asegurar esta consistencia (elegir bien las etiquetas) es más eficiente para mejorar el rendimiento de un modelo que recolectar más datos.

En sus propias palabras: «Ahora que los modelos han avanzado hasta un cierto punto, tenemos que conseguir que los datos funcionen también» (Forbes, 2021).

Representatividad de los datos

Conseguir un conjunto consistente de datos nos lleva a uno de los jinetes del apocalipsis de la ciencia de datos: la representatividad. El conjunto de validación tiene que incluir ejemplos que sean representativos de la realidad. Sonados fueron los errores del reconocimiento facial de Facebook y de Google cuando se probó con personas negras. Y no, mejorar la representatividad no significa recolectar cantidades masivas de datos, como muestra este artículo en Nature, sino asegurarse que todas las categorías están suficientemente representadas y que se incluyen muestras heterogéneas.

Como ejemplificábamos en este post sobre explicabilidad algorítmica, si tienes imágenes únicamente de lobos en la nieve, puede que la IA termine asociando el color blanco al lobo, y que etiquete a cualquier animal en la nieve como un lobo. También un extremo de nula representatividad le ocurrió a Amazon cuando implementó un sistema automático de selección que infravaloraba a las mujeres debido a que había sido entrenado con CV mayoritariamente de hombres.

Representatividad de datos en texto

El problema de la representatividad se multiplica cuando los datos que van a alimentar el sistema de inteligencia artificial es una colección de textos (corpus). Existen múltiples factores que hay que considerar porque aportan variabilidad como la naturaleza del texto (oral o escrito), su finalidad, la temática o el idioma, por lo que diseñar un corpus representativo y equilibrado es una tarea ardua. Se requiere conocer en profundidad las características del lenguaje y el dominio al que pertenecen los textos, así como tener presente cómo funcionan las técnicas de aprendizaje automático que se utilizarán para desarrollar el modelo.

Los procesos de etiquetado de textos o anotación de corpus requieren leerse cuidadosamente los documentos, señalando aquellos elementos determinantes en el resultado esperado, por ejemplo, párrafos u oraciones, palabras específicas, nombre de personas, lugares u organizaciones. Es un proceso minucioso que requiere seguir guías formales que incluyen los criterios de anotación. Estas guías se deben elaborar al principio del proyecto y son parte de la garantía que mantiene la coherencia en la anotación. La otra parte es contar con un buen equipo de anotación, ya que un mal etiquetado de los textos puede descubrirse demasiado tarde y echar al traste meses de trabajo.

Variables sensibles en los datos

El caso extremo del problema de representatividad es cuando el conjunto de datos contiene ciertas variables sensibles, como sexo, raza o religión, cuya distribución pueden condicionar las decisiones del modelo de aprendizaje automático. Hay que tener especial cuidado en esta situación para evitar usos del modelo que puedan discriminar injustamente o atentar con la dignidad humana.

De todas las maneras, hay que resaltar que también puede ser el uso que se haga del sistema y no el hecho de que haya sido entrenado con datos sensibles lo que puede derivar en problemas éticos y legales. Por ejemplo, un sistema de IA que incluye el sexo para determinar la probabilidad de desarrollar una determinada enfermedad parece que no contraviene ningún principio ético, más bien al contrario, de no incluirlo sería penalizar injustamente al sistema.

Más allá de esta puntualización, hay que asegurarse de que no existen sesgos en los datos, y eliminarlos si fuera necesario es una tarea compleja. No es tan sencillo como eliminar de una tabla las variables que se hayan determinado como sensibles, ya que otras columnas pueden estar correlacionadas y el problema del sesgo en los resultados persiste.

Cuando los datos son documentos, hay que extremar las precauciones, especialmente en el caso del sexo, ya que algunos idiomas pueden contener marcadores de género que facilitan la identificación del sexo de una persona sin referirse explícitamente a ella (por ejemplo, en “Mi vecina le dijo a su cuñado que la doctora que lo atendió fue más amable que el enfermero”). Dada la sofisticación de los sistemas de Procesamiento de Lenguaje Natural (PLN) podemos detectar sesgos que van más allá de la capa morfosintáctica del idioma. Por ejemplo, en un reciente estudio de Science Advances se determinó que hay una asociación más fuerte entre el concepto “persona” y “hombre” que entre “persona” y “mujer”.

Data leakage

Otro jinete del apocalipsis es el data leakage, literalmente “fuga de datos”. Este consiste en incorporar en el entrenamiento del modelo información que realmente quieres predecir o de la que no vas a disponer cuando uses el modelo en tiempo real. Un ejemplo del primer caso podría ser el siguiente: una fábrica quiere predecir el número de quesos que va a producir y, para ello, incorpora un indicador de los litros de leche que se consumen. Durante el entrenamiento, el rendimiento del modelo es muy elevado, ya que la cantidad de leche que emplea la fábrica predice con elevada precisión la producción de queso. En cambio, cuando se pone en producción, falla estrepitosamente. En este caso, es la demanda de queso la que determina el nivel de leche y no al revés. Es decir, la fábrica compra más o menos leche dependiendo de cuanta demanda tiene de queso.

Al entrenar el modelo con datos históricos, este se aprovecha de que existe una correlación fuerte entre ambas variables, ya que cuando aumenta una, aumenta la otra, y cuando disminuye una, la otra también disminuye. Sin embargo, cuando ejecutamos el modelo con datos del presente, la correlación se convierte en una relación causal. Esta relación impone que es la demanda de queso la que influye en la cantidad de leche y no al revés.

Otro caso similar es el de un modelo que prediga el tiempo de duración de un proyecto software. Una de las variables predictoras es el cambio en el número de desarrolladores. En las pruebas con los datos de entrenamiento se observa que esta variable predice muy bien, ya que cuando se incrementa el equipo se detectan descensos en la duración. Sin embargo, se prueba el modelo en un proyecto en curso y las predicciones son bastante malas, ya que son los retrasos en el proyecto los que producen el incremento del equipo y no al contrario.

Por otro lado, también se puede producir esta fuga de datos cuando al poner el modelo en producción no se dispone de variables con las que se contaba en el conjunto de entrenamiento. Por ejemplo, pongamos el caso de que se realiza un sistema que predice el coste de una avería y una de variables que se incorpora es si un perito intervino en la valoración. Cuando se lleva a producción el rendimiento del sistema baja porque las predicciones se realizan siempre antes que se determine si es preciso enviar un perito para realizar la valoración.

En definitiva, hay que ser precavido cuando trabajamos con datos o recibimos resultados basados en estos. Si estás en el lado de los que tratan los datos, ojo avizor, ya que hemos repasado múltiples maneras de resbalar. Como consejo a tener siempre en mente, cuida en extremo los datos sobre los que realizas tus modelos: «si entra basura, sale basura».

Si te encuentras en el lado de quien consume los resultados, es necesario siempre un punto de escepticismo: «si torturan los datos lo suficiente, estos confesarán lo que ellos quieran». A ambos lados, la manera más efectiva para garantizar la robustez de los resultados es validar los modelos con datos que nunca antes haya visto y replicar hasta la saciedad los experimentos.