Como Auditar una Elección Presidencial — Edición Colombia— Prueba de Concepto
Este artículo es completamente apolítico, no tiene intención o inclinación por alguno de los candidatos presidenciales, se trata mayormente de un ejercicio para el desarrollo de una prueba de concepto que permita realizar el conteo de votos e identificar posibles anomalías, auditando así el mecanismo utilizado en las votaciones para presidente que tuvieron lugar el 29 de mayo de 2022 en Colombia. El tiempo total de dedicación en la construcción del sistema fue de aproximadamente 60 horas.
English version: https://bit.ly/3QbuUDX
El 29 de mayo de 2022, tuvieron lugar las elecciones para presidente de Colombia; mas allá del resultado, en la mayoría sino la totalidad de las redes sociales, se generaron oleadas de seguidores de uno y otro candidato denunciando fraudes en el conteo de los votos, aduciendo que los formatos utilizados, también llamados E14 contienen correcciones que añaden votos a un candidato u otro.
E-14…
Lo curioso de las ya mencionadas “denuncias” es que, si bien existen representantes de todos los frentes políticos, la mayoría de estas denuncias, al menos desde mi concepto, provienen de los seguidores del candidato que quedo en primera posición con más del 40% del total de los votos.
La problemática asociada a estas denuncias radica en que realizar una auditoría general desde una perspectiva totalmente externa, es un proceso extenuante y manual, no pretendo entrar en detalles del proceso de conteo de votos colombiano, el cual puede ser consultado en este link, pero el punto a tener en cuenta es que uno de los elementos más importantes es el formulario E-14; el cual es un formulario que contiene toda la información de los candidatos y su respectivo partido político, así como los votos obtenidos por cada uno; una de las tres copias de este formulario es publicado en la página de la Registraduría Nacional, entidad encargada de agregar los resultados y publicar la cantidad de votos oficiales de las elecciones.
¿Y mis votos?
Si ingresamos a la página de la Registraduría Nacional es posible consultar cualquiera de los formularios E-14 correspondientes a las 103 mil mesas de votación instaladas en el país (https://divulgacione14presidencia.registraduria.gov.co); sin embargo, al ser un portal estilo Single Page Application (SPA) y usar reCAPTCHA, no es posible automatizar el proceso de descarga de los formularios E14 al menos a partir de herramientas tradicionales.
A un nivel lógico, los pasos que requeriríamos para realizar el conteo de los votos presentes en los E14 e identificar posibles anomalías en estos incluiría los siguientes pasos:
- Descargar los formatos E-14 (103.364) a través de la navegación del portal
- Convertir el archivo PDF a una imagen (PNG en lo posible)
- Extraer los campos que contienen los votos por cada uno de los candidatos
- Identificar el número, asterisco o la ausencia de un carácter en los campos
- Identificar si existe algún tipo de inconsistencia
- Almacenar la información, correlacionarla y presentarla para ser auditada (si se requiere)
Ultron… There are no Strings on Me…
Teniendo en cuenta las múltiples restricciones que pueden existir para cada uno de los pasos; es posible con ciertas tecnologías conseguir un resultado que se acerque a nuestros objetivos de contar los votos y al mismo tiempo auditar los formularios E-14; para esto fue creado como prueba de concepto Ultron, un sistema con una arquitectura capaz de sobrepasar las restricciones identificadas. La arquitectura de alto nivel del sistema es la siguiente:
Fuentes: Página oficial de la Registraduría Nacional estilo SPA, protegida por reCAPTCHA, donde se realiza la publicación de los formularios E-14; es importante tener en cuenta que este portal es relativamente lento (Asumo por la alta demanda), la carga de elementos e información toma varios segundos, lo cual es el equivalente de años para un computador.
Extracción: Si bien existen soluciones para sobrepasar sistemas como reCAPTCHA y consultar paginas SPA; en este caso optaremos por “Puppeteer”, el cual es una librería que permite manipular Chrome/Chromium. Para sobrepasar los problemas asociadas a reCAPTCHA la idea es controlar una instancia de Google Chrome de un equipo de usuario (Mi equipo), Puppeteer detecta cuando reCAPTCHA actúa y espera unos segundos para que el usuario resuelva el captcha; dado que es un navegador con una sesión de usuario normal, el proceso de resolver el captcha no es muy frecuente (Mas o menos dos o tres veces por cada 500 formularios descargados); en total se descargaron 1.016 formularios E-14 (Aproximadamente el 1% de las mesas totales del país) en un periodo de aproximadamente 30 minutos, todos del departamento de Antioquia (Por facilidad) y de diversos Municipios y Zonas.
Transformación: En este componente desarrollamos tres acciones; extraer los campos que contienen los votos por cada uno de los candidatos, Identificar el número, asterisco o la ausencia de un carácter en los campos e Identificar si existe algún tipo de inconsistencia; esto se desarrolla inicialmente con tres microservicios y una base de datos:
- p2i (PDF to Image): Microservicio cuyo único propósito es el de convertir archivos de formato pdf a png, a través de este podemos reducir la resolución, esto con el objetivo de que todo el proceso sea más eficiente.
- icutter (Image Cutter): Microservicio que permite a partir de un archivo png de entrada, realizar uno o múltiples recortes de la imagen, retornado estos cortes en formato png. Solamente se recortaron los votos de los candidatos Gustavo Petro, Rodolfo Hernández y Federico Gutiérrez.
- mldigits (Machine Learning Digits): Microservicio que expone un Modelo de Machine Learning entrenado utilizando el juego de datos MNIST-784 para reconocimiento de números; a través de técnicas de expansión (mover la imagen unos pixeles a la izquierda, derecha, arriba y abajo) y expansión (Girar la imagen unos pixeles a la izquierda o derecha) y aparte, utilizando los microservicios para extraer 6 mil muestras de asteriscos y casillas libres; el algoritmo KNN-Classifier de Scikit fue entrenado con un total de 565 mil muestras de números y asteriscos. La salida de este es un vector de números, con la probabilidad que corresponda a una u otra opción la imagen de entrada.
- Base de Datos: La base de datos es ElasticSearch, dado que facilita el proceso de analítica bajo la misma interfaz; el almacenamiento de la información extraída se realiza formato json, la información extraída es la siguiente:
- Candidato: nombre del candidato
- Números en la Primera, Segunda y Tercera Casilla: números identificados por mldigits en cada una de las respectivas casillas del formulario E-14.
- Probabilidades de los Numero: Probabilidades generados por mldigits por cada uno de los números analizados. El numero 10 fue utilizado como etiqueta para referirse al asterisco/tachón/celda vacía en los formularios E-14.
- Votos: Cantidad de votos de acuerdo con los números identificados en las casillas.
- Imagenes: Nombre de las imágenes obtenidas de cada una de las casillas correspondientes a los votos; estas imágenes son enviadas por el sistema un bucket S3 para que puedan ser visualizadas a través del nombre dentro de la interfaz de analítica.
- Votos — Confianza: Nivel de confianza en cada uno de los tres números identificados.
- General — Confianza: Promedio del nivel de confianza de los tres números identificados.
Analítica: A partir de la base de datos se utiliza la interfaz gráfica de ElasticSearch (Kibana) para la generación de tableros de control, agregación de resultados y analítica sobre la información identificada.
Todos estos sistemas se implementan sobre plataformas que corren sobre un clúster de 4 nodos de Kubernetes y un servidor con Docker; siendo orquestados por Node-Red, quien se encarga de realizar las llamadas a los microservicios y él envió y almacenamiento de la información en ElasticSearch.
Debido a practicidad, economía del articulo y sobre todo que no es propósito, no pretendo entrar en detalles técnicos respecto a cada uno de los componentes, probablemente a futuro escriba artículos sobre IA/ML, Microservicios, Kubernetes, etc.
Resultados
El proceso a partir de la descarga y procesamiento de un total de 1016 formularios, tomo aproximadamente 50 minutos; aunque paralelizándolo un tanto más podría reducirse significativamente este tiempo (Estimo a 25–30 minutos).
Al totalizar los datos y comparar contra una muestra de 100 mesas (el 10% del 1% del total de mesas del país); se encontró que el rendimiento del algoritmo de ML estaba dentro del 95% de precisión en cuanto al reconocimiento de los números; y debido a que los errores se presentan de forma más común en el 2do y 3er digito, los resultados del total de votos de las mesas tenían un desfase de un 2% con respecto al valor real.
Una de las grandes ventajas del proceso es que al utilizar un modelo de ML para el reconocimiento de la cantidad de votos, tenemos no solo el número, si no un vector con las probabilidades; esto es, el nivel de “confianza” del modelo en que ese número es 1, 2, asterisco, etc; esto en sí mismo es una medida que dice más del modelo de ML que de los datos del formulario… sin embargo, una diferencia de más de un par de puntos porcentuales en el nivel de confianza entre un candidato y otro, si nos dice que a pesar que ambos resultados están escritos supuestamente con la misma caligrafía, unos son más fácilmente reconocibles que otros, dándonos pistas de anomalías. De igual forma un nivel de confianza bajo o muy bajo (Podríamos tomar 75% por ejemplo) también nos indica posibles problemas; principalmente de tres tipos:
- Errores en el formato de los datos: Estos errores están principalmente asociados a la desalineación de la imagen del formato, números borrosos, manchones de tinta, etc.
- Errores del algoritmo ML: Debido a factores como al dataset utilizado y la caligrafía del jurado que llena los formularios; algunos números pueden resultar ambiguos, bien sea porque se encuentran demasiado inclinados, la escritura dificulta discernir los números, por ejemplo, un 4 de un 9 y otros factores.
- Errores en el formulario: Problemas relacionados a información presente, estos pueden ser tachones, enmendaduras, números mal escritos, ambiguos, complementados o sobrepuestos.
Una de las características más útiles y totalmente independiente de la precisión del algoritmo de ML, es la posibilidad de realizar auditoria de los resultados de forma rapida y sin tener que ingresar formulario por formulario; esto al generar una vista unificada que solamente muestra el candidato y las imágenes, y, en caso de tener alguna duda, es posible consultar que formulario especifico, de que departamento, municipio, zona, puesto y mesa presenta la inconformidad; como un ejemplo de esto es posible auditar más 100 formularios en poco menos de un par de minutos.
Conclusiones
- Desde mi punto de vista y si bien hace parte del proceso político, y me atrevería a decir que hasta de nuestra cultura Colombiana el reclamar y quejarse muy muy fuerte por cosas que simplemente “no me benefician”, ese es precisamente el único fundamento de la mayoría de quejas que salen en redes sociales.
- La realidad es que dentro del proceso del desarrollo de esta prueba de concepto de auditoría de los E-14, no se encontraron una cantidad significativa de tachones o enmendaduras que añadan (o quiten) votos a los candidatos, sobre todo, no las suficientes como para que se manipule significativamente el resultado del proceso electoral en los municipios analizados. En total se encontraron anomalías en 21 mesas (2.06%) del total analizado, todas con la firma de al menos 4 jurados y la mayoría con comentarios aclarando el error. ¿Estos errores beneficiaban de forma mayoritaria a algún candidato? ¡Si!; sin embargo, y debido a que no es significativo el cambio y con el fin de mantener el tono apolítico del artículo, no mencionare cual.
- Existen bastantes mejoras que se pueden implementar dentro del proyecto, particularmente en la extracción de datos desde el formato E-14, identificando mucho mejor donde se encuentran los números, notas y total de votos, por ejemplo; y por supuesto también el entrenamiento del modelo de ML y el algoritmo (XGBoost, RandomForest, etc), inclusive cambiándolo por un modelo de aprendizaje profundo, lo cual reduciría su tamaño y mejoraría la precisión.
- “Ultron” es una Prueba de Concepto, la muestra es pequeña y no es posible extrapolar lo aquí identificado al total de mesas del país; eso sería como tomar un vaso de agua de un lago y al no encontrar un solo pez, concluir que en el lago completo no hay peces. El propósito de este articulo NO ES posicionarse a favor de un candidato, ni siquiera de defender a la Registraduría; es mostrar estrategias para la auditoria del proceso y como se puede hacer más eficiente y con la menor cantidad de sesgos.
