spinner

¿Cómo aplicar aprendizaje federado y no morir en el intento? Aplicación en fraude de tarjetas de crédito

El aprendizaje federado (FL) es un nuevo paradigma de IA que permite entrenar modelos de manera segura con datos sensibles, antes inaccesibles. En este post veremos cómo implementar con éxito FL en la detección de fraude de tarjetas de crédito y qué ventajas nos podría aportar respecto al Machine Learning tradicional.

El Aprendizaje Federado (FL) es una nueva forma de hacer Machine Learning que nos permite entrenar modelos con datos protegidos. El objetivo final no es otro que el poder aprender de un conjunto de datos más amplio sin necesidad de acceder, extraer y centralizar bases de datos, exponiendo su seguridad y privacidad.

Sin embargo, esta tecnología aunque prometedora, puede acabar siendo un fracaso en su implementación [1], si no se tienen en cuenta una serie de aspectos básicos. En este post vamos a ver cómo implementar aprendizaje federado para el caso de uso de fraude en tarjetas de crédito. Veremos cómo aplicarlo mediante 7 sencillos pasos, en los que contaremos aquellos aspectos que hay que tener en cuenta para implementar con éxito un proyecto de FL.

Figura 1. Metodología de aplicación – Aprendizaje Federado

01: Definición del contexto de aplicación

Con el objetivo de poder evaluar las ventajas que ofrece FL en un entorno empresarial. Desde BBVA Next Technologies diseñamos un experimento para facilitar la explotación de datos de movimientos de tarjetas de crédito de varias filiales de BBVA. Estos datos, aunque de gran utilidad para diferentes áreas del banco, suelen ser custodiados en silos a los que sólo unos pocos privilegiados tienen acceso.

Concretamente, vimos que se podría utilizar FL para poder entrenar modelos predictivos de fraude utilizando los datos de estos silos, sin necesidad de pedir acceso. De esta manera se entrena un modelo con un conjunto de datos más amplio utilizando los datos compartidos, de manera privada y segura por varios departamentos o filiales del mismo. 

En nuestro experimento, esta compartición de datos se hace a través de varias cuentas de GCP. Teniendo como objetivo principal entrenar un modelo de ML que haga uso de distintos silos de datos en su entrenamiento y cuya ejecución se orquestre a través de una cuenta externa en AWS, sin acceso directo a los mismos.

Definición de roles

Esto nos deja con dos roles básicos: el científico de datos que trabaja en un entorno en AWS y es el encargado de explotar los datos (de forma remota), definir el modelo y asegurar su privacidad y el propietario de datos de cada silo o banco encargado de implementar y asegurar la seguridad y gobernanza de los datos almacenados en GCP.

Figura 2. Entrenamiento de un modelo FL. El modelo se envía para ser entrenado en el silo de datos. De esta manera, los datos no salen del silo, no se expone la privacidad ni la seguridad de los mismos.

Gobernanza del dato

En este escenario, los requisitos mínimos de seguridad y gobernanza se definen cómo un acuerdo global y se implementan de manera local por cada silo o banco en cada cuenta.

Figura 3. Escenario de compartición de datos y explotación de los mismos.

Por otro lado, se hace necesario asegurar unos mínimos requisitos de calidad, así como establecer un modelo de datos común1 que nos permita operar con el conjunto de datos o particiones de forma similar. Esto es importante para poder facilitar la definción y entrenamiento del modelo global, común a todos los silos. En nuestro caso concreto, este conjunto de operaciones básicas se han definido de manera global de la siguiente manera:

Figura 4. Pipeline de pre-procesamiento común – operaciones mínimas a tener en cuenta.

Posteriormente, este pipeline de pre-procesamiento es implementado y orquestado por el científico de datos utilizando como base las cabeceras de los datasets compartidos. En este caso, se utiliza Spark y un cluster de Google Dataproc cuyo acceso a datos se gestiona de manera local por cada silo mediante una cuenta de servicio de GCP.

De esta manera se ejecutan de manera segura los pipelines de pre-procesamiento de cada dataset como un conjunto de operaciones previamente acordadas por ambas partes y aceptadas por los propietarios de datos.

Nota 1: En el caso de que no sea posible establecer un modelo de datos común, deberíamos optar por una solución del tipo aprendizaje vertical.

02: Selección del framework de FL

Una vez definidos el ámbito de aplicación y los requisitos mínimos de seguridad, estandarización y calidad del dato, es necesario seleccionar un framework que se ajuste a estas necesidades. Concretamente para el caso de uso cross-silo, que es el que nos aplica, hemos priorizado los siguientes frameworks por su nivel de madurez:

Figura 5. Frameworks destacados y sus características más relevantes

En el contexto de esta PoC se ha seleccionado PySyft como framework FL y Duet para la distribución y entrenamiento de modelos. Una de las ventajas que nos proporciona este framework es que permite gestionar la seguridad del dato a nivel de operación. Además de habilitar un entorno de colaboración a través de notebooks, mediante la definición de los dos roles básicos mencionados anteriormente: data scientist y data owner.

Figura 6. En PySyft el propietario de datos (data owner) tiene control sobre las operaciones que se van a ejecutar en su entorno.

03: Caracterización de los datos distribuidos en silos

Otro aspecto importante a tener en cuenta es cómo se distribuyen los datos en cada silo. Uno de los retos en FL es hacer que el modelo final, resultado de la agregación de las copias de los modelos locales entrenados con distintos datos, converja hacia una solución óptima.

Figura 7. Divergencia en la dirección de entrenamiento del modelo debido a la presencia de datos heterogéneos [2].

Esto va a depender de dos factores que es necesario analizar en detalle: la heterogeneidad de los datos y el número de iteraciones de entrenamiento local (sin agregaciones parciales).

Heterogeneidad de los datos

En nuestro caso de uso, nos encontramos en un tipo de aprendizaje federado horizontal. Esto es así porque los datos de cada silo comparten las mismas características o columnas pero diferente número de filas o clientes.

Figura 8. Escenario de particionamiento horizontal de datos. Las particiones comparten columnas pero tienen filas diferentes.

Este tipo de particionamiento puede afectar a la distribución de los datos y hacer que cada modelo entrenado sobre cada partición converja hacia una dirección diferente. Por ello, es necesario caracterizar los datos y detectar diferencias en la distribución de los mismos. Para esto una buena herramienta suelen ser los test o análisis anova.

Figura 9. Ejemplo de análisis comparativo de las distribuciones de datos entre nodos. Inter-variabilidad estadística. Se observa desbalanceamiento en  la etiqueta fraude y en el tipo de operaciones por código de riesgo, así como diferencias en la distribución del importe por operación.

Si hay una diferencia estadísticamente significativa entre nodos entonces es posible que sea necesario aplicar algún tipo de estrategia diferente en su entrenamiento.

04: Estrategias de aprendizaje federado

Existen varias maneras de resolver este problema [2]. Una de las técnicas más utilizadas en ciencia de datos es realizar clustering generando grupos homogéneos para luego entrenar modelos diferentes en cada grupo. Sin embargo, aunque esta técnica podría ser válida, al tener el conjunto de datos repartido entre varios silos habría que crear clusters de sistemas con la complejidad que esto conlleva.

Debido a esto, en FL se suele entrenar un modelo por cada silo de datos, realizando posteriormente agregaciones a nivel de parámetro. En la siguiente figura, tenéis la implementación en PySyft del algoritmo más comúnmente utilizado, conocido como FedAvg.

Figura 10.  Implementación del algoritmo FedAvg en PySyft. En FedAvg se ejecutan n rondas de entrenamiento en local para posteriormente hacer agregación de los parámetros entrenados. El número de iteraciones o agregaciones parciales a realizar es un hiper-parámetro que debe ser seleccionado apropiadamente.

En esta fase, la caracterización de los datos nos puede ayudar a determinar el número de agregaciones parciales necesarias o el número de iteraciones de entrenamiento local. Cuanto mayor sea la diferencia en la distribución estadística de los datos, mayor será el riesgo de que exista cierta divergencia si el número de iteraciones de entrenamiento local aumenta.

05: Evaluación y entrenamiento del modelo

Finalmente es necesario evaluar si el modelo entrenado cumple con los resultados mínimos esperados por cada participante. Esto significa que el modelo debería funcionar mejor que el modelo entrenado con los datos de un sólo silo. ¿Cúal sería si no la ventaja que obtienen los participantes al compartir sus datos sino es obtener al menos un modelo mejorado?.

Por otro lado también es interesante comparar este modelo con el que se habría obtenido si hubiéramos centralizado todos los datasets, es decir, sin utilizar FL.

Figura 11. Comparación de resultados – Modelo final obtenido (Federated Global Model) vs. Modelo entrenado con datos de un silo (Federated Local Model) vs. Modelo con datos centralizados (Centralized Model).

En la figura 11. observamos que utilizando el algoritmo FedAvg obtenemos resultados muy similares a los que habríamos obtenido centralizando estos datos2. Por otro lado, observamos que obtenemos resultados muy superiores a los obtenidos con los datos de un sólo silo.

Nota 2: Para obtener estos resultados ha sido necesario hacer agregaciones parciales cada 100 epochs, el resto de hiper-parámetros se han mantenido comunes entre los distintos modelos o experimentos. Para más información se adjunta en referencias un documento con el detalle del experimento.

06: Implementación de mecanismos de privacidad

Por último es importante evaluar si el modelo o el proceso de construcción del mismo podría exponer la privacidad del dato. Concretamente en nuestro caso se ha optado por anonimizar y cifrar los datos en GCP. Esto es importante puesto que en nuestro caso concreto además de regulaciones como GDPR, también nos aplican otras más específicas como PCI.

Sin embargo, también es necesario proteger al modelo frente ataques de fuga de datos [3]. Para esto se podrían utilizar las herramientas que proporciona PySyft de computación homomórfica (entrenamiento del modelo sobre datos cifrados) o técnicas de privacidad diferencial.

Conclusiones

En este post hemos visto que se puede aplicar aprendizaje federado para mejorar un modelo de fraude en tarjetas de crédito. Este modelo obtiene mejores resultados ya que se entrena con más datos, compartidos por varios bancos, evitando la centralización o duplicación de los mismos.

Por último hemos visto una metodología que podría ayudar a aplicar estas técnicas en un proyecto real.  Si quieres saber más al respecto por favor, ponte en contacto con nosotros en hablemos.es@bbvanexttechnologies.com.

Referencias

Referencia principal: Documento completo de la PoC Fraude tarjetas de crédito

[1] Kairouz, P. et al. Advances and open problems in federated learning. (Google, 2019). [Online]. Available: https://www.nowpublishers.com/article/Details/MAL-083

[2] Hangyu Zhua , Jinjin Xub , Shiqing Liua and Yaochu Jin. Federated Learning on Non-IID Data: A Survey. Jun 2021. [Online]. Available: https://arxiv.org/pdf/2106.06843.pdf

[3] NguyenTruong, KaiSun, .et al. Privacy preservation in federated learning: An insightful survey from the GDPR perspective. Nov 2021 [Online]. Available: https://www.sciencedirect.com/science/article/pii/S0167404821002261

Disclaimer

Este post no pretende servir como una guía de referencia de aplicación de FL. Los aprendizajes obtenidos aquí se han extraído de una PoC realizada en una entorno controlado y no en un entorno productivo dentro del BBVA.

 

Las opiniones vertidas por el autor son enteramente suyas y no siempre representan la opinión de BBVA Next Technologies.

¿Quieres saber que más cosas hacemos en BBVA Next Technologies?