Ideas y buenas prácticas para evitar el sesgo algorítmico

Continuo con este post un poco la línea expositiva que inicié en el anterior, 'Seis criterios de imparcialidad algorítmica... y alguna reserva'. Se trata de conocer un poco más la temática de los sesgos en los algoritmos y, sobre todo, explorar qué se puede hacer.

Para ello, sigo los argumentos que se aportan en el libro 'Artificial Intelligence. A modern approach' de Stuart Russell y Peter Norvig, un poco sazonados con mis propias ideas pero, especialmente en este caso, es un artículo bajo en sal, con lo que quiero decir que ese sazonado es muy leve y que básicamente me limito a mostrar las ideas que los autores citados exponen en el libro. 

El sesgo algorítmico

Sólo recordar, aunque entiendo que la generalidad de los lectores de este blog lo conocen, que el sesgo algorítmico son situaciones que se producen en los algoritmos de machine learning que llevan a que de alguna forma beneficien o, sobre todo, perjudiquen a un colectivo o persona de una manera que consideramos parcial o injusta.

¿Qué se puede hacer al respecto?

Bueno, aunque personalmente, desearía, y creo posible, ir a acciones y prácticas más concretas, Russell y Norvig recogen un buen racimo de líneas de actuación.

Algunas ideas

En primer lugar nos aportan tres ideas.

La primera tiene que ver con entender y gestionar el alcance de los datos que utilizamos para el entrenamiento, algo que, aunque a bote pronto no lo parezca, tiene mucho que ver con la diversidad (en el sentido de variedad de géneros, edades, razas, culturas,...) del equipo de científicos de datos. 

Antes de pasar a los algoritmos nos ponen un ejemplo muy fácil de entender que no es del campo de la Inteligencia Artificial sino de la usabilidad de las interfaces de usuario. Nos dicen que es muy difícil valorar la usabilidad de una interfaz de usuario para daltónicos si nadie en el equipo de desarrollo o pruebas tiene ese defecto visual... porque no van a poder comprobar el impacto en ese colectivo. Es más, probablemente ni se les ocurra siquiera pensar en ese impacto, ni diseñar la interfaz para que sea válida para ese colectivo. Es por eso que la diversidad de los equipos facilita, aunque creo que no garantiza, la no marginación de minorías o ciertos colectivos.

La segunda idea que ponen sobre la mesa es trabajar con los datos para eliminar los sesgos de entrada. Así, nos proponen algún ejemplo: si estamos trabajando con un algoritmo sobre justicia, eliminar como datos de entrenamientos los casos juzgados por algún juez que se sepa por anticipado que muestra juicios sesgados contra algún colectivo. También hablan, aunque de esto yo no estoy tan seguro de su bondad, de reforzar los datos de entrenamiento correspondientes a minorías (yo diría que, más que reforzar, lo que hay es que estudiarlo y garantizar que esas minorías están suficiente y adecuadamente representadas en los datos de entrenamiento).

Y la tercera idea es idear algoritmos más resistentes a los sesgos. Nos hablan de que la idea es como tener dos algoritmos: uno que, digamos, es el principal y que, por desgracia, puede mostrar algún sesgo, pero luego tener otro algoritmo complementario que elimine el sesgo en los resultados del primero. Me gustaría conocer más el detalle de cómo funcionan ese segundo algoritmo. Lo que sí creo es que ya hay herramientas de AutoML (Auto Machine Learning) que, aunque con supervisión humana, ya alertan de eventuales sesgos.

Un cuasi-decálogo de buenas prácticas

Tras esas ideas, unas líneas más abajo los autores recogen un 'cuasi-decálogo' de buenas prácticas sin muchas explicaciones. Hablo de cuasi-decálogo, simplemente, porque son nueve recomendaciones, en lugar de diez.

Son éstas:

• Asegurarse de que los ingenieros de software hablan con científicos sociales y otros expertos del dominio para asegurar que entienden el contexto y perspectivas y diseñan algoritmos imparciales desde el mismo inicio.


• Crear un entorno en que se busque que los equipos de ingenieros de software sean diversos y reflejen la composición real de la sociedad.


• Definir a qué grupos el algoritmo tiene que dar adecuado soporte: hablantes de diferentes idiomas, grupos diferentes de edad, diferentes capacidades, etc


• Optimizar una función objetivo que incorpore la imparcialidad


• Examinar los datos de entrenamiento para detectar prejuicios o correlaciones entre atributos protegidos y otros atributos.


• Entender cómo se realiza la anotación de datos de entrenamiento por humanos (se trata del etiquetado para aprendizaje supervisado), establecer objetivos de diseño para ese etiquetado y verificar que se cumplen.


• No limitarse a métricas generales del sistema o algoritmo, sino obtener también métricas para subgrupos que pudieran ser objeto de sesgo.


• Incorporar a las pruebas de sistema, casos de prueba que reflejen la experiencia de grupos minoritarios


• Establecer un bucle de realimentación de manera que, si se producen sesgos, exista una forma de gestionarlos.

Parecen todas ellas muy buenas ideas, aunque es cierto que luego hay que operativizarlas lo cual, en algunas de las recomendaciones  parece fácil pero en otras quizá algo menos.

Conclusión

No es que haya muchas conclusiones que extraer salvo que si, el riesgo, y el problema, de los sesgos existe, pero están ya identificadas bastantes vías de actuación para, si no garantizar al cien por cien que se eliminan, sí disminuir mucho esa probabilidad de sesgo, y la magnitud del sesgo, en el caso de que se produzca.

Es esperanzador.