Resumen Técnico: AdFL – Aprendizaje Federado en el Navegador para Publicidad en Línea

Declaración del Problema

El ecosistema de la publicación en línea enfrenta una tensión crítica entre la necesidad de ingresos por publicidad dirigida y las crecientes regulaciones de privacidad del usuario (p. ej., GDPR, CCPA). Las prácticas tradicionales de intercambio de datos, que envían datos de comportamiento del usuario a agencias de publicidad externas, están cada vez más restringidas, lo que obliga a los editores a depender de anuncios contextuales menos efectivos. Las soluciones existentes de Aprendizaje Federado (FL) para publicidad enfrentan obstáculos de integración significativos:

• Complejidad Arquitectónica: Algunas propuestas requieren estructuras de servidor jerárquicas que no se integran perfectamente con los servidores de anuncios existentes (como Google Ads Manager), los cuales dependen de estructuras de clave-valor en lugar de embeddings.
• Dependencias de Datos: Los enfoques de FL vertical suelen requerir la cooperación con los anunciantes y el acceso a datos de conversión externos que no están disponibles dentro del navegador.
• Limitaciones del Navegador: Los marcos de FL en el navegador existentes a menudo carecen de soporte específico para métricas publicitarias, no logran realizar la recolección de datos en tiempo real o son computacionalmente demasiado costosos para la duración limitada de la visita de un usuario.

El desafío central es permitir la publicidad dirigida que respete la privacidad del usuario manteniendo los datos brutos en el dispositivo del usuario y, al mismo tiempo, manteniendo la baja latencia y la alta eficiencia requeridas para el servicio de anuncios en tiempo real.

Metodología: Marco de Trabajo AdFL

AdFL es un marco de FL horizontal diseñado para operar enteramente dentro del navegador del usuario. Permite el entrenamiento de modelos globales utilizando datos locales del usuario sin que los datos salgan nunca del navegador.

Arquitectura del Sistema

El sistema consta de dos entidades primarias:

1. Servidor AdFL (Lado del Editor): Aloja el modelo global y coordina el proceso de aprendizaje. Gestiona el versionado del modelo y agrega las actualizaciones locales.
2. Cliente AdFL (Lado del Navegador): Un cliente basado en JavaScript que se ejecuta de forma asíncrona junto a los anuncios en línea. Se encarga de la recolección de datos, el preprocesamiento, el entrenamiento del modelo local y la inferencia.

Componentes del Cliente

El cliente AdFL se compone de cinco componentes modulares implementados mediante APIs estándar del navegador (p. ej., MutationObserver, IndexedDB, TensorFlow.js):

• Gestor de Sesión (SM): Gestiona el ciclo de vida del cliente, maneja la carga/descarga de componentes y supervisa el almacenamiento del navegador (IndexedDB).
• Recolector de Datos (DC): Captura datos contextuales (agente de usuario, SO, URL, contenido de la página) e historial de sesiones. Agrega características de sesiones actuales y pasadas para construir un patrón completo de usuario-página.
• Utilidad de Anuncio (AdU): Diseñada específicamente para capturar métricas específicas de anuncios en tiempo real a medida que estos cargan. Rastrea la visibilidad, el clic (click-through) y las métricas de atención. Activa la inferencia del modelo para ajustar el comportamiento del anuncio (p. ej., modificando las tasas de refresco) basándose en las predicciones.
• Preprocesamiento y Almacenamiento de Datos (DPS): Preprocesa los datos brutos utilizando técnicas como el escalado MinMax y la codificación por hash. Asegura una representación de características consistente entre clientes y gestiona el almacenamiento de muestras de datos procesadas.
• Utilidad de Modelo (MU): Maneja la carga, el entrenamiento y la inferencia del modelo. Gestiona los parámetros de configuración, optimiza para las restricciones del dispositivo (memoria, batería) y ejecuta el bucle de entrenamiento.

Flujo de Trabajo

1. Inicialización: Tras la carga de la página, el SM descarga los scripts de AdFL e inicializa el almacenamiento.
2. Recolección de Datos: El DC y el AdU recolectan datos contextuales y específicos de anuncios, respectivamente.
3. Preprocesamiento: El DPS procesa los datos brutos en vectores de características.
4. Inferencia: Para cada carga de anuncio, el MU realiza la inferencia para predecir métricas (p. ej., visibilidad). El AdU utiliza estas predicciones para ajustar dinámicamente los parámetros de visualización del anuncio (p. ej., extendiendo o acortando la duración del anuncio).
5. Entrenamiento: Periódicamente, el MU entrena el modelo local con los datos acumulados.
6. Agregación: Los parámetros del modelo local se cargan al servidor AdFL. El servidor los agrega utilizando FedAvg (ponderado por el tamaño del conjunto de datos) para actualizar el modelo global, el cual es redistribuido a los clientes.

Privacidad y Seguridad

• Localidad de los Datos: Los datos brutos del usuario nunca salen del navegador.
• Modelo de Amenaza: Asume un servidor "honesto pero curioso" que sigue el protocolo pero puede intentar inferir el comportamiento del usuario a partir de las actualizaciones del modelo.
• Mitigación: El marco soporta Privacidad Diferencial (DP) para añadir ruido a las actualizaciones del modelo local, protegiendo contra ataques de inferencia basados en gradientes.

Contribuciones Clave

1. Marco AdFL: Un sistema de FL de extremo a extremo, novedoso y diseñado específicamente para el entorno del navegador, que permite la recolección, el preprocesamiento y el entrenamiento de modelos locales de forma fluida para anuncios en línea sin requerir la instalación de software en el cliente.
2. Modelo de Predicción de Visibilidad de Anuncios: Un modelo de prueba de concepto construido sobre AdFL que predice la visibilidad de los anuncios. Utiliza una arquitectura de red neuronal ligera capaz de manejar características de entrada dinámicas y de ejecutarse eficientemente en dispositivos con recursos limitados.
3. Prototipo de Implementación: Un prototipo plenamente funcional que demuestra la recolección de datos de anuncios en tiempo real y el entrenamiento efectivo de FL utilizando APIs estándar del navegador (TensorFlow.js, IndexedDB) y cookies de primera parte, evitando la necesidad de cookies de terceros.

Resultados Experimentales

Los autores evaluaron AdFL utilizando dos conjuntos de datos no superpuestos (periodos de 10 y 30 días) de un sitio web de un editor con aproximadamente 40,000 visitantes diarios.

Rendimiento y Latencia

• Latencia: El sistema opera con baja latencia, adecuada para el servicio de anuncios en tiempo real.
  • Inferencia: < 3ms en escritorio, < 7ms en móviles.
  • Preprocesamiento: ~40ms en escritorio, ~50ms en móviles.
  • Entrenamiento: ~378ms por ronda en escritorio, ~469ms en móviles.
• Sobrecarga de Memoria: El sistema consume aproximadamente 50MB de memoria de JavaScript inicialmente, aumentando a ~230MB (escritorio) y ~198MB (móvil) tras el entrenamiento y la inferencia, lo cual es factible para dispositivos modernos.

Precisión del Modelo

• Predicción de Visibilidad: El modelo de FL alcanzó un Área Bajo la Curva (AUC) de hasta el 92.59% en el conjunto de datos de 30 días.
• FL vs. Aprendizaje Centralizado (CL): El rendimiento del modelo FL fue comparable al de un modelo centralizado, con descensos solo modestos (p. ej., 87.36% AUC para FL frente a 89.19% para CL en un entorno de 50 usuarios).
• Privacidad Diferencial: La aplicación de DP (con un ruido $\epsilon$ que oscila entre 0.1 y 1.0) resultó en reducciones de rendimiento solo modestas en comparación con la variante sin DP, demostando que las salvaguardas de privacidad pueden implementarse con compensaciones aceptables.

Importancia de las Características

Mediante el análisis SHAP, el estudio identificó que las características específicas del anuncio (p. ej., dimensiones del anuncio, ubicación) y las métricas personalizadas fueron los contribuyentes más significativos para el rendimiento del modelo, validando la importancia de las capacidades de recolección de datos específicas del cliente AdFL.

Significado y Reivindicaciones

El artículo posiciona a AdFL como una solución práctica para el dilema "privacidad vs. ingresos" en la publicidad en línea. Su importancia radica en:

• Viabilidad: Demostrar que los complejos procesos de FL pueden ejecutarse eficientemente dentro de las restricciones de un navegador web sin requerir la instalación de software por parte del usuario.
• Preservación de la Privacidad: Ofrecer un mecanismo para que los editores utilicen los datos de los usuarios para la publicidad dirigida manteniendo los datos brutos locales y cumpliendo con las regulaciones de privacidad.
• Optimización de Ingresos: Mostrar que los modelos que preservan la privacidad pueden alcanzar una alta precisión (hasta un 92.59% de AUC), permitiendo potencialmente a los editores mantener niveles de ingresos cercanos a los de los sistemas centralizados que no preservan la privacidad.

Los autores concluyen que AdFL representa un paso prometedor hacia el equilibrio entre la privacidad del usuario y los ingresos del editor, proporcionando una alternativa viable a las prácticas actuales de intercambio de datos y a los métodos de evasión de bloqueo de anuncios.