Estás leyendo la publicación: Hacia Mejores Sistemas de Recomendación – Hacia la IA
Publicado originalmente en Hacia la IA, la empresa líder mundial en noticias y medios de IA y tecnología. Si está creando un producto o servicio relacionado con la IA, lo invitamos a considerar convertirse en patrocinador de la IA. En Hacia la IA, ayudamos a escalar las empresas emergentes de IA y tecnología. Permítanos ayudarlo a dar rienda suelta a su tecnología a las masas.
Tablas de incrustación sin colisiones, capacitación en línea y tolerancia a fallas
Los sistemas de recomendación son la aplicación más frecuente del aprendizaje automático. Los vemos en acción en todas las plataformas de redes sociales, sitios web de transmisión, mercado en línea y casi cualquier sitio web que muestre anuncios.
A pesar de su prevalencia, hay mucho margen de mejora en la forma en que se diseñan los sistemas de recomendación. En el artículo de hoy, revisaremos un artículo reciente publicado por un equipo en Bytedance, la empresa matriz de TikTok. Sistema de recomendación en tiempo real con tabla de incrustación sin colisiones
Los autores destacan tres contribuciones principales de su trabajo:
- Tablas de incrustación sin colisión y caducadas para manejar datos categóricos.
- Una plataforma de formación en línea para garantizar que los modelos se actualicen a medida que cambien las preferencias del usuario.
- Instantáneas periódicas (copias) para que el sistema sea tolerante a fallas.
Problema 1: un espacio de funciones explosivo
En esencia, un motor de recomendaciones está entrenado para predecir si se hará clic en algo que se le muestra o no. Los motores de recomendación intentan realizar esta predicción utilizando dos tipos de datos:
- Datos sobre el usuario podrían ser características como la edad, los tiempos de inicio de sesión, compras/clics/vistas anteriores, etc.
- Datos sobre el elemento que se muestra. Por ejemplo, si estuviera en una aplicación de entrega de alimentos, las funciones que se utilizan podrían ser el tipo de cocina, los ingredientes, la calificación del restaurante, etc.
En muchos casos, las características utilizadas para entrenar un modelo pueden ser variables categóricas, es decir, valores no numéricos que se pueden categorizar, por ejemplo, fusión, hamburguesa, pizza, etc. en el caso de tipos de cocina. También se debe tener en cuenta que los usuarios/elementos en sí mismos son variables categóricas porque generalmente se representan en forma de un identificador único (ID).
En el aprendizaje profundo, un método común para manejar variables categóricas es usar incrustaciones. Donde cada categoría se asigna a un vector n-dimensional. Una capa de incrustación suele ser solo una tabla de búsqueda donde una ID única se asigna a su representación vectorial correspondiente.
Las variables categóricas plantean un problema porque pueden surgir nuevas categorías en cualquier momento. Puede haber nuevos alimentos que comiencen a aparecer en un día determinado, o una aplicación puede tener nuevos usuarios que se registren. Teóricamente, no hay límite para el número de categorías que se pueden tener para una característica determinada.
Sin embargo, no podemos tener una capa de incrustación con memoria infinita. La implicación de esto es que es posible asignar múltiples ID al mismo vector n-dimensional. Supongamos que tenemos la tarea de colocar 11 bolas en 10 cajas, sin importar lo que hagamos, al menos una de las cajas contendrá más de una bola. Este escenario es lo que llamamos una colisión. Las colisiones podrían dificultar la capacidad del modelo de aprendizaje automático para distinguir entre diferentes categorías.
Solución
Los autores resuelven este problema usando:
- hashing de cuco
- Categorías de filtrado y expulsión
hash es el concepto de tomar una entrada de cualquier tamaño y asignarla a una salida de un tamaño fijo. Una función hash ideal puede garantizar que no haya colisiones, es decir, nunca se pueden asignar dos entradas a la misma salida. Las estructuras de datos, como los diccionarios y los mapas hash, aprovechan las funciones hash.
Los autores afirman que muchos sistemas de recomendación intentan mitigar las colisiones en las tablas incrustadas eligiendo funciones hash que aseguren bajas colisiones. Argumentan que esto sigue siendo perjudicial para el modelo de aprendizaje automático.
Idealmente, si usamos una tabla de incrustación, nos gustaría usar una función hash que asegure que no se asignen dos entradas a la misma posición en la tabla de incrustación. Los autores utilizan Cuckoo HashMap para este fin.
Cuco HashMap
Como se muestra en la figura, un Cuckoo HashMap tiene dos tablas Hash T0 y T1. Cada tabla hash tiene su función hash única, T0 usa h0 y T1 usa h1. Las funciones hash deciden dónde se almacena una entrada dada en la tabla de incrustación.
En la figura anterior se muestra una ilustración del funcionamiento de Cuckoo HashMap y cómo maneja las colisiones.
- A medida que entra el elemento A, h0 (escrito como h0(A)) lo reduce a una posición en T0, pero esa ubicación ya tiene el elemento B (esto es una colisión). Lo que sucede en este escenario es que A se traslada a la ubicación y B es desalojado.
- Al ser desalojado, B se mueve a T1 calculando h1 (B), sin embargo, hay otra colisión.
- Ahora se desaloja C y se calcula h0(C), choca con D.
- se calcula h1(D). Finalmente, h1(D) corresponde a una ubicación en T1 que está vacía.
Observe cómo el algoritmo aseguró que no haya dos elementos que ocupen la misma ubicación en la tabla hash reubicando todos los elementos que tienen una colisión con el elemento entrante.
Categorías de filtrado y expulsión
Para limitar el tamaño de las capas/tablas incrustadas, los autores reconocen que ciertas categorías/identificadores ocurren muy raramente. Tener una incrustación única para tales elementos no es muy útil porque el modelo no se ajustaría bien a esa categoría debido a la poca frecuencia con la que se observa en el entrenamiento.
Otra observación astuta que señalan los autores es que ciertos ID/categorías pueden volverse inactivos después de un cierto período y tener parámetros para ellos ya no tiene ningún sentido. Esto podría ser un usuario que no inició sesión durante un año, un producto en Amazon que no se compró en los últimos 3 meses, etc.
Con base en estas observaciones, los autores filtran las categorías/identificadores según la frecuencia con la que ocurren y si están inactivos por más de un cierto período. Esto garantiza que solo las categorías/identificadores más relevantes estén presentes en las tablas de incrustación.
Problema 2: Deriva del concepto
Un modelo de aprendizaje automático se entrena con datos recopilados del pasado. Sin embargo, no hay garantía de que el pasado pueda representar con precisión el futuro. Todos hemos sido testigos de cómo las tendencias cobran protagonismo y se desvanecen con el tiempo. Nuestras preferencias también cambian con el tiempo.
En el mundo de la ciencia de datos, este fenómeno se conoce como Deriva del concepto. Donde la distribución de datos que aprende el modelo ya no es precisa y las interacciones entre las características no son las mismas. Concept Drift es la razón principal por la que los modelos de aprendizaje automático deben volver a entrenarse periódicamente para garantizar que su rendimiento no caiga en picada y que aprendan sobre los conceptos emergentes.
Solución
El entrenamiento en línea es el proceso de entrenar un modelo tan pronto como aparece un nuevo punto de datos. Por ejemplo, si ha decidido comenzar a ver un nuevo programa en Netflix, en el momento en que presiona el botón de reproducción, se crea un nuevo punto de entrenamiento con una etiqueta positiva (desde que hizo clic). El modelo ahora puede ejecutar un pase hacia adelante para calcular una pérdida y actualizar sus pesos en consecuencia.
En el documento, los autores crean un marco que puede ejecutarse por lotes (capacitación fuera de línea) junto con la capacitación en línea. Sin embargo, la preocupación aquí es que el modelo que se está entrenando (Training Worker y Training Parameter Server (PS) como se ve en la figura) y el modelo que se está utilizando activamente (servidor de parámetros de servicio (PS)) para proporcionar recomendaciones son diferentes y podrían ejecutarse en diferentes clústeres.
Esto se debe a que ejecutar un modelo en modo de entrenamiento es más lento que ejecutarlo en modo de inferencia. porque no es necesario calcular los gradientes en este último. Esto nos lleva a la pregunta de cómo se pueden sincronizar (hacer que sean iguales) los pesos de los PS de entrenamiento y de servicio.
Según nuestro entendimiento, los autores brindan las siguientes ideas clave que ofrecen una solución al problema:
- La mayoría de los parámetros de los modelos de recomendación son en gran medida escaso características, es decir, características categóricas y sus correspondientes incrustaciones.
- Solo unas pocas características dispersas tienden a actualizarse en un período de tiempo determinado. Imagine una plataforma de redes sociales como Tiktok en cualquier período de tiempo, solo una fracción de los usuarios podría iniciar sesión en la aplicación a pesar de que la cantidad total de usuarios activos diarios es de unos pocos millones.
- Los modelos que usan optimizadores basados en impulso para actualizar sus pesos tienden a tardar mucho tiempo en cambiar significativamente. Los pesos que pertenecen a la red neuronal profunda exclusivos de las incrustaciones se denominan parámetros densos.
Con base en las dos primeras observaciones, los autores desarrollan una metodología para realizar un seguimiento de qué características escasas se han actualizado durante el entrenamiento (en línea y fuera de línea). Solo los parámetros de los ID/características que se han actualizado durante el entrenamiento se envían al EP servidor para actualizar sus parámetros. Esto se indica a través de la flecha del PS de entrenamiento al PS de servicio en la imagen.
Los autores actualizan los parámetros escasos cada minuto. Esto es factible debido a la pequeña fracción de identificaciones que se actualizan durante la capacitación en línea. Por otro lado, los parámetros densos se actualizan a una frecuencia mucho menor. A pesar de las diferentes versiones de las incrustaciones y los parámetros densos en el PS de servicio, los autores destacan que no hay una caída significativa en el rendimiento.
Una combinación de capacitación en línea y por lotes con un plan inteligente para actualizar los pesos de los modelos permite que el motor de recomendaciones conozca las preferencias cambiantes de los usuarios.
Problema 3: tolerancia a fallas
Para que un sistema sea tolerante a fallas, debe poder funcionar como se desea, incluso en caso de falla. Tenga en cuenta lo raro que es que las aplicaciones de software populares dejen de funcionar por completo, esto se debe a que los ingenieros se esfuerzan por agregar la mayor resistencia posible a las fallas.
Un método común para lograr la tolerancia a fallas es mediante la creación de copias de servidores, bases de datos, etc. Recuerde que, al final del día, un servidor es solo una computadora. Puede dañarse, corromperse y funcionar mal en cualquier momento, al igual que sus propios dispositivos. Tener varias máquinas funcionando y almacenando el mismo conjunto de información y datos garantiza que tan pronto como falla una máquina, la copia puede hacerse cargo y atender cualquier solicitud dirigida a ella.
Los autores siguen el mismo enfoque para hacer que su motor de recomendaciones sea resistente a fallas. Crean copias de los pesos del modelo (denominados instantáneas). Sin embargo, hay algunas complejidades que deben ser resaltadas.
- Los modelos pueden ser extremadamente grandes y crear demasiadas copias de ellos puede ser costoso, ya que debe pagar por toda la memoria que se consume.
- Necesita encontrar el equilibrio adecuado entre crear una copia y tener pesos actualizados. Si una copia es antigua, significa que desconoce todas las formas en que han cambiado las preferencias de los usuarios desde que se creó la copia.
En sus experimentos, los autores encuentran que hacer copias diarias de su modelo funcionó bien sin ninguna caída significativa en el rendimiento del modelo a pesar de las fallas de los servidores o centros de datos que almacenan el modelo.
Conclusión
Monolith nos enseña cómo lograr incrustaciones sin colisiones y las ventajas de purgar características/identificadores no utilizados. Nos muestra cómo los modelos pueden lidiar mejor con la desviación de conceptos al aprovechar la capacitación en línea y las técnicas inteligentes de sincronización de parámetros. También nos muestra la importancia de encontrar el equilibrio correcto al crear copias de los parámetros del modelo para garantizar la tolerancia a fallas.
¡Gracias por leer este artículo, esperamos que hayas aprendido algo nuevo! Si tiene alguna pregunta o idea, compártala en la sección de comentarios a continuación.
Referencias
Paper Review Monolith: Hacia mejores sistemas de recomendación se publicó originalmente en Hacia la IA en Medium, donde las personas continúan la conversación destacando y respondiendo a esta historia.
Publicado a través de Hacia la IA
