Cómo construir un motor de recomendación básico sin aprendizaje automático

Los sistemas de recomendación se han convertido en una parte integral e indispensable de nuestras vidas. Estos algoritmos inteligentes son fundamentales para dar forma a nuestras experiencias en línea, influyendo en el contenido que consumimos, los productos que compramos y los servicios que exploramos. Ya sea que estemos transmitiendo contenido en plataformas como Netflix , descubriendo nueva música en Spotify o comprando en línea, los sistemas de recomendación funcionan silenciosamente detrás de escena para personalizar y mejorar nuestras interacciones.

El elemento único de estos sistemas de recomendación es su capacidad para comprender y predecir nuestras preferencias en función del comportamiento histórico y los patrones de los usuarios. Al analizar nuestras elecciones pasadas, estos sistemas seleccionan sugerencias personalizadas, lo que nos ahorra tiempo y esfuerzo al mismo tiempo que nos presentan contenido/productos que se alinean con nuestros intereses. Esto mejora la satisfacción del usuario y fomenta el descubrimiento, presentándonos ofertas nuevas y relevantes que de otro modo no hubiéramos encontrado.

En un nivel alto, los desarrolladores entienden que estos algoritmos están impulsados por sistemas de aprendizaje automático y aprendizaje profundo (llamados indistintamente redes neuronales), pero ¿qué pasa si les digo que hay una manera de crear un motor de recomendación sin pasar por la molestia de implementar sus redes neuronales? ¿Modelo de aprendizaje neto o automático?

Esta pregunta es específicamente relevante en el contexto de las empresas emergentes en etapa inicial y media porque no tienen toneladas de datos estructurados para entrenar sus modelos. Y como ya sabemos, la mayoría de los modelos de aprendizaje automático no darán predicciones precisas sin los datos de entrenamiento adecuados.

Recientemente construí e implementé un motor de recomendación básico para un red social de voz primero , lo que generó un aumento del 40% en nuestras métricas clave. Al momento de escribir este blog, el sistema genera más de 30 millones de recomendaciones por mes. Aunque este sistema de recomendaciones se creó para una red social, puede aplicar la arquitectura básica a cualquier caso de uso, como recomendaciones de productos, recomendaciones de música, recomendaciones de contenido en plataformas de texto y video, o cualquier otra cosa. Permítanme comenzar describiendo el planteamiento del problema.

Planteamiento del problema desde la perspectiva de la ingeniería.

Tuve una extensa documento de requisitos del producto y documento de requisitos de ingeniería posterior porque estábamos creando el sistema de recomendación para un producto que ya utilizan miles de usuarios diariamente. Pero para que este blog sea breve y preciso, escribiré solo los requisitos de alto nivel y luego discutiré la solución de los mismos. Si está creando un sistema de recomendación para su producto (simple o basado en red neuronal) y no está en algún lugar, no dude en ponerse en contacto conmigo en Gorjeo o LinkedIn , y estaré más que feliz de responder a sus preguntas.

A un alto nivel, teníamos los siguientes requisitos desde una perspectiva de ingeniería:

1. El sistema debería poder capturar los intereses de un usuario en forma de palabras clave. El sistema también debería poder clasificar el nivel de interés que tiene un usuario con palabras clave específicas.

   
   

2. El sistema debería poder captar el interés de un usuario en otros usuarios. Debería poder clasificar el nivel de interés que tiene un usuario en el contenido creado por otro usuario.

   
   

3. El sistema debería poder generar recomendaciones de alta calidad basadas en los intereses del usuario.

   
   

4. El sistema debería poder garantizar que las recomendaciones ya vistas/rechazadas por el usuario no vuelvan a aparecer durante X días.

   
   

5. El sistema debe tener lógica para garantizar que las publicaciones de los mismos creadores no estén agrupadas en la misma página. El sistema debe hacer todo lo posible para garantizar que si un usuario consume diez publicaciones (el tamaño de nuestra página), todas sean de diferentes creadores.

   
   

6. El sistema debería ser rápido. Menos de 150 milisegundos de latencia P99.

   
   

7. Se deben cumplir todos los demás requisitos no funcionales, como alta disponibilidad, escalabilidad, seguridad, confiabilidad, mantenibilidad, etc.

   
   

Nuevamente, ésta es una lista muy simplificada de planteamientos de problemas. En realidad, los documentos tenían más de 3000 palabras y también cubrían muchos casos extremos y casos extremos que pueden surgir al integrar este motor de recomendaciones en nuestros sistemas existentes. Pasemos a la solución.

Solución: funcionamiento de alto nivel del motor de recomendaciones

Discutiré las soluciones al problema una por una y luego describiré el funcionamiento general de todo el sistema.

Nuestro primer problema es captar los intereses del usuario y definir su nivel de interés con un interés específico.

Para esto, creamos algo llamado gráfico social . En pocas palabras, un gráfico social almacena las relaciones y conexiones entre diferentes entidades en una red social. Estas entidades pueden ser diferentes usuarios o una relación de usuarios con un interés específico. Los gráficos sociales son una forma poderosa de comprender y estructurar las relaciones dentro de un sistema particular. En aras de la brevedad, no explicaré el gráfico social en detalle, pero te recomendaré que lo busques en Google y aprendas más sobre él. A continuación se muestra una versión simplificada del gráfico social que creé para nuestro motor de recomendaciones.

Como puede ver en la imagen de arriba, estamos almacenando mucha información, como la cantidad de interacciones (me gusta, comentarios, acciones compartidas) y la actualidad de estas interacciones (cuándo ocurrieron por última vez) como datos de relación entre dos usuarios y entre un usuario y un interés. Incluso estamos almacenando la relación entre dos palabras clave de intereses diferentes. solía Amazonas Neptuno , una base de datos de gráficos administrada por AWS, para almacenar este gráfico social. Puede utilizar cualquier otra base de datos de gráficos, como Neo4j, JanusGraph, ArrangoDB , etc.

Estas palabras clave de interés son predominantemente sustantivos. Existe un sistema que desglosa el contenido de una publicación en estas palabras clave (sustantivos). Está impulsado por AWS. un servicio de procesamiento de lenguaje natural (NLP) que utiliza el aprendizaje automático para dividir el texto en entidades, frases clave, etc. Nuevamente, puede usar cualquier servicio de NLP administrado (varios disponibles) para lograr lo mismo. ¡No necesita aprender ni implementar sus modelos de aprendizaje automático! Si ya comprende el aprendizaje automático, puede consultar Modelos de PNL de código abierto también en Huggingface .

Nuestro segundo problema es generar recomendaciones de alta calidad basadas en el interés del usuario.

El siguiente diagrama es una representación simplificada de alto nivel de cómo funciona el sistema.

Si bien lo anterior parece fácil, suceden muchas más cosas en cada paso, y esas cosas deben pensarse cuidadosamente y luego programarse para garantizar que el sistema funcione de manera óptima.

Déjame explicarte paso a paso:

Paso 1: convertir el contenido de la publicación en incrustaciones de vectores

Para generar estas recomendaciones, primero tenemos que convertir el contenido de una publicación en algo llamado: Incrustaciones de vectores . Con el reciente repunte en la marca de los LLM, OpenAI (los creadores de ChatGPT) y Bases de datos vectoriales Las incrustaciones de vectores se están convirtiendo en un término cotidiano. No entraré en detalles sobre qué son y cómo funcionan, pero recomiendo leer más sobre ellos. Pero generar candidatos viables para un feed también debe tener en cuenta aspectos como la privacidad y moderación del contenido (eliminar palabras profanas, abusos, contenido sexual, acoso, filtrar usuarios bloqueados, etc.).

Para generar incrustaciones de vectores, puede utilizar cualquier modelo de incrustación destacado, como el modelo de incrustación OpenAI , Amazon Titan o cualquier modelo de incrustación de texto de código abierto , según su caso de uso. Elegimos Amazon Titan por su precio asequible, su rendimiento y su facilidad operativa.

Paso 2: consultar el interés del usuario

Ahora bien, aquí es donde las cosas se ponen interesantes. Le recomendamos diseñar las consultas en función de sus necesidades comerciales específicas. Por ejemplo, al consultar intereses, le damos más importancia a la antigüedad de la interacción que a la cantidad de interacciones con una palabra clave o usuario específico. También ejecutamos múltiples consultas paralelas para encontrar diferentes tipos de interés del usuario: palabra clave u otro usuario. Dado que generamos múltiples feeds para un solo usuario, también ejecutamos algunas consultas que promocionan un tema específico según la tendencia (por ejemplo, verá muchas publicaciones relacionadas con Navidad cerca de Navidad o publicaciones relacionadas con terremotos si ha ocurrido algún terremoto). No hace falta decir que este tema sólo aparecerá en los resultados de la consulta si el usuario ha expresado algún interés en él durante su viaje.

Por lo tanto, elija la lógica que se adapte a su caso de uso empresarial y al comportamiento que desea impulsar y ejecute múltiples consultas para obtener una lista lo suficientemente grande de todos los intereses del usuario.

Paso 3: realice una búsqueda de ANN según los intereses encontrados

Las bases de datos vectoriales se utilizan predominantemente para realizar un tipo particular de búsqueda llamado Búsqueda aproximada de vecino más cercano (ANA). Nuevamente, la forma en que categoriza varios intereses y si está realizando una gran búsqueda de ANN o búsquedas de diferencias paralelas debe basarse completamente en su caso de uso y requisitos comerciales. Recomiendo hacer más que búsquedas basadas en cohortes y luego ordenar los resultados (lo discutiremos más adelante en este blog) para obtener la mejor experiencia del usuario final. Lo que hace la búsqueda de ANN, en este caso, es encontrar otras publicaciones en la plataforma que sean similares (más cercanas) a los intereses del usuario.

Paso 4: almacene los resultados en una base de datos caché con orden.

Caché de base de datos porque uno de los problemas que debemos solucionar es la velocidad. Usamos conjuntos ordenados de Redis para almacenar las identificaciones únicas de las publicaciones de un usuario específico. Usamos conjuntos ordenados de Redis porque el orden de las publicaciones en el feed de un usuario es fundamental. Además, otro problema que debes resolver es que el " sistema debe tener lógica para garantizar que las publicaciones de los mismos creadores no estén agrupadas en la misma página". Para evitar la repetición de contenido del mismo creador, hemos escrito un algoritmo simple que garantiza que si la publicación de un creador específico se inserta en cualquier posición en el feed de un usuario en particular (conjunto ordenado), no insertamos otra publicación del mismo creador. para diez posiciones sucesivas (tenemos un tamaño de página de 10 mientras entregamos el feed al usuario final, por lo que lo mantuvimos estático para evitar complejidad).

Para decidir el orden de una recomendación específica del usuario, tomamos en cuenta lo siguiente:

1. La fuerza de la relación con un interés específico (u otro usuario) para este usuario : está determinada por una fórmula aritmética que toma varios puntos de datos del gráfico social. Todo esto son datos de participación, como la marca de tiempo de los últimos Me gusta creados, la cantidad de Me gusta creados, el último comentario, etc. El comportamiento de participación del usuario es el indicador de su interés en algo.

   
   

2. La popularidad de la publicación en la plataforma: para determinar esto, hemos creado un algoritmo que toma varios factores, como participación, índices de participación e impresión, cantidad de usuarios únicos que participaron, etc., para generar una puntuación de participación de esa publicación. publicar a nivel de plataforma.

   
   

En algunos feeds, damos prioridad a la popularidad; en otros, priorizamos el gráfico social. Pero sobre todo, todos ellos son una mezcla saludable de los dos.

Cómo funciona el sistema

Como puede ver en el diagrama anterior, el sistema se ha mantenido intencionalmente muy simple. A continuación se explica cómo funciona el sistema:

1. Cuando el usuario A crea una publicación, el servicio de publicación, después de guardar esa publicación, activa un evento de publicación/suscripción en una cola, que es recibido por un servicio en segundo plano destinado a la generación de candidatos. Usamos Google Pub/Sub para la funcionalidad pub/sub.

   
   

2. Este servicio en segundo plano recibe esto de forma asincrónica y realiza las funcionalidades analizadas anteriormente: comprobaciones de privacidad, comprobaciones de moderación y generación de palabras clave y luego genera las incrustaciones de vectores y las almacena en la base de datos de vectores. Estamos usando AstraDB como nuestra base de datos vectorial (discutido después).

   
   

3. Cada vez que un usuario interactúa (me gusta/comenta/comparte, etc.) después de actualizar nuestra base de datos NoSQL principal, el servicio posterior activa un evento de publicación/suscripción en el servicio del motor de recomendación.

   
   

4. Este servicio de motor de recomendación actualiza la base de datos de gráficos y luego actualiza la fuente recomendada del usuario casi en tiempo real realizando la búsqueda de ANN y actualizando la base de datos de Redis. Entonces, cuanto más interactúan los usuarios, mejor se vuelve el feed. Hay controles para garantizar que las recomendaciones no estén sesgadas hacia una lista específica de palabras clave . Esas comprobaciones se realizan mientras consultamos la base de datos de Graph. Este servicio también actualiza la puntuación de participación de forma asincrónica. Las puntuaciones de participación también se vuelven a calcular en función de los usuarios que ven la publicación.

   
   

5. Dado que todos los pasos anteriores se realizan de forma asincrónica en segundo plano, estos cálculos no tienen ningún impacto en la experiencia del usuario final.

   
   

6. El feed finalmente se entrega al usuario final a través de un servicio de feed. Dado que este servicio simplemente realiza una búsqueda en redis y nuestra base de datos principal NoSQL ( DyanmoDB ), su latencia P99 es inferior a 110 milisegundos. Ambas bases de datos devuelven resultados de consultas con una latencia de milisegundos de un solo dígito, independientemente de la escala.

Herramientas y tecnologías utilizadas.

1. Algunos servicios han sido escritos en Ir al lenguaje de programación , mientras que otros han sido escritos en NodoJS (con texto mecanografiado).

   
   

2. Estamos usando AstraDB de Datastax como nuestra base de datos de vectores. Llegamos a esta decisión después de evaluar muchas otras bases de datos, como pinecone, milvus y weaviate . Además de sus excelentes capacidades de consulta e indexación de vectores y otros tipos de datos, ofrece un plan de precios sin servidor de bolsillo. Se ejecuta sobre un motor Cassandra, que utilizamos como base de datos en varias otras funciones de nuestra plataforma, y ofrece una interfaz de consulta CQL, que es muy fácil de usar para los desarrolladores. Recomiendo encarecidamente probarlo para sus casos de uso de vectores.

   
   

3. Usamos Publicación/subscripción de Google para nuestra comunicación asincrónica porque, en nuestra escala actual (pocos lakh de usuarios en total, unos pocos miles de usuarios activos diarios), es muy rentable. Lo he ejecutado a una escala de unos pocos lakh de usuarios con miles de eventos por segundo. Funciona bien y es fácil de usar y ampliar.

   
   

4. Redis - Rapidez, sencillez y potente estructura de datos. No creo que necesite discutir por qué Redis en 2024.

   
   

5. DinamoDB - Nuevamente, es altamente escalable y fácil de usar, y lo ejecutamos en modo sin servidor donde, a pesar de cientos de miles de consultas por minuto, nuestra factura total es bastante baja. También ofrece capacidades de indexación muy potentes y una latencia de milisegundos de un solo dígito en lecturas y escrituras.

Problemas a resolver en el futuro.

Como puede imaginar, esta misma configuración se puede modificar para crear un motor de recomendación básico para cualquier caso de uso. Pero, dado que la nuestra es una red social, necesitaremos algunos ajustes en el futuro para que este sistema sea más eficiente.

1. Se necesitarán algoritmos de aprendizaje automático/aprendizaje profundo a nivel de gráfico social para predecir las palabras clave y los usuarios más relevantes para el usuario. Actualmente, el conjunto de datos es demasiado pequeño para predecir algo con precisión, ya que es un producto muy nuevo. Sin embargo, a medida que los datos crezcan, necesitaremos reemplazar las consultas y fórmulas simples actuales con el resultado de algoritmos de aprendizaje automático.

   
   

2. Las relaciones entre varias palabras clave y usuarios deben ajustarse y hacerse más granulares. Están en un nivel muy alto ahora mismo. Pero tendrán que ser más profundos. Primero necesitaremos explorar las relaciones de segundo y tercer grado en nuestro gráfico para refinar las recomendaciones.

   
   

3. No estamos realizando ningún ajuste en nuestros modelos de incrustación en este momento. Tendremos que hacerlo en un futuro próximo.

Nota final

Espero que este blog te haya resultado útil. Si tiene alguna pregunta, duda o sugerencia, no dude en ponerse en contacto conmigo en Gorjeo , LinkedIn o Instagram . Comparta este artículo con sus amigos y colegas.