, el sistema de recomendación multimodal no es trivial, especialmente cuando necesita escalar, adaptarse casi en tiempo real y ejecutarse de manera confiable en la nube.
En esta publicación, analizo mi experiencia en el diseño e implementación de un sistema de este tipo de extremo a extremo, que abarca la preparación de datos, la capacitación de modelos y el servicio de los modelos en producción.
Exploraremos todo el proceso, incluida la recuperación, el filtrado, la puntuación y la clasificación, junto con la infraestructura y las decisiones importantes que hacen que todo funcione. Esto incluye tiendas de funciones, filtros Bloom, Kubeflow, adaptación de preferencias casi en tiempo real y una importante ganancia de latencia gracias al almacenamiento en caché de funciones en memoria.
Es una lectura larga, pero si está creando o ampliando sistemas de recomendación, aquí encontrará patrones prácticos que puede aplicar directamente a sus propios proyectos.
Las secciones principales de esta publicación.
Alguna información sobre el sistema Por qué se eligió el diseño actual Componentes del sistema Fuente de datos Canal de capacitación e implementación completo Canal de ajuste continuo Procesamiento de solicitudes a través de los 14 modelos en el servidor de inferencia NVIDIA Triton Mejora de la latencia de búsqueda de características de elementos con almacenamiento en caché en memoria Escalado automático del servidor de inferencia Triton en EKS Validación de recomendaciones contextuales, filtrado de filtro Bloom y actualizaciones de recomendaciones casi en tiempo real (con demostración) Limitaciones y recursos de conclusión del trabajo futuro
Alguna información sobre el sistema.
El sistema de recomendación consta de cuatro etapas principales: un modelo de dos torres genera candidatos, un filtro Bloom oculta temporalmente los elementos con los que el usuario interactuó recientemente, un clasificador DLRM califica los elementos restantes utilizando características de usuario, elemento y contexto, y una etapa final de reclasificación ordena y muestra de estos puntajes para producir las recomendaciones finales. Los modelos utilizan funciones colaborativas tabulares e incrustaciones de imágenes CLIP precalculadas e incrustaciones de texto Sentence-BERT.
En el modelo de recuperación, estas incorporaciones previamente entrenadas se introducen en la torre candidata junto con las características de los elementos aprendidos, proporcionando a la torre candidata señales semánticas basadas en contenido y señales colaborativas. El producto escalar entre la salida de la torre de consultas y la salida de la torre candidata se utiliza luego como puntuación de relevancia aprendida en este espacio de incrustación compartido.
En el clasificador DLRM, las incrustaciones de texto e imágenes previamente entrenadas participan en la capa de interacción del producto escalar. Estas interacciones por pares luego se pasan al MLP superior, lo que permite que las señales basadas en contenido de las incrustaciones previamente entrenadas complementen las señales colaborativas y contextuales utilizadas para la predicción de clics.
Por qué se eligió el diseño actual
El caso de uso objetivo es una plataforma de comercio electrónico que necesita recomendar productos relevantes tan pronto como los usuarios acceden a la página de inicio. La plataforma atiende tanto a usuarios registrados como a visitantes anónimos, y el comportamiento del usuario puede variar sustancialmente según el contexto de la solicitud, como el tipo de dispositivo, la hora del día o el día de la semana. Eso significa que el servicio de recomendación debe proporcionar recomendaciones razonables de arranque en frío para nuevos usuarios y debe adaptar las recomendaciones al contexto de la solicitud actual.
La solución también necesita escalar. A medida que se incorporen más minoristas, el catálogo de productos podría crecer hasta alcanzar millones de artículos. En ese momento, no resulta práctico calificar el catálogo completo en cada solicitud. Un diseño de varias etapas resuelve este problema mediante el uso de una etapa de recuperación liviana para buscar candidatos rápidamente y una etapa de clasificación más pesada para calificar a esos candidatos.
Además, los modelos de recomendación deben mantenerse actualizados con nuevas interacciones; sin embargo, no es práctico reconstruir la pila de recuperación completa todos los días. Por este motivo, se definen dos canalizaciones de Kubeflow. El primer canal configura los flujos de trabajo de preprocesamiento, entrena los modelos desde cero, crea el índice ANN e implementa el servidor y los modelos Triton. El segundo canal gestiona el ajuste diario que actualiza principalmente la torre de consultas y el clasificador; los modelos se actualizan con nuevas señales de interacción pero las incrustaciones de elementos no se regeneran.
Componentes del sistema
Todos los componentes del sistema trabajan juntos para garantizar que se logre el objetivo general de brindar recomendaciones relevantes de manera rápida y a una escala razonable.
Kubeflow Pipelines gestiona tanto el flujo de trabajo de capacitación completo como el flujo de trabajo de ajuste diario en el sistema basado en Kubernetes. La pila NVIDIA Merlin maneja la ingeniería de funciones, el preprocesamiento, la recuperación de entrenamiento y los modelos de clasificación acelerados por GPU. El servidor Triton Inference aloja el gráfico de publicación de varias etapas como un modelo de conjunto único. FAISS sirve como índice de vecino más cercano aproximado para la recuperación de candidatos. Feast gestiona las funciones del usuario y del elemento durante la capacitación y el servicio. ElastiCache para Valkey (Redis) respalda la tienda de funciones en línea, administra el filtro Bloom de cada usuario para permitir el filtrado de elementos ya vistos de la lista de recomendaciones de un usuario y almacena información de popularidad de elementos global y basada en categorías según el recuento de interacciones. Amazon Athena (con S3 y Glue) respalda la tienda de funciones fuera de línea. Amazon Elastic Kubernetes Service (EKS) ejecuta flujos de trabajo de aprendizaje automático en contenedores y escala la computación para satisfacer las demandas cambiantes de las cargas de trabajo.
fuente de datos
Los datos de capacitación provienen de una versión modificada del generador de interacción de la tienda de demostración minorista de AWS. El grupo de usuarios se amplió a 300.000, mientras que el catálogo de productos se mantuvo en 2.465 artículos, con las imágenes y descripciones asociadas. El conjunto de datos contiene 13 millones de interacciones a lo largo de 14 días, almacenadas como parquets divididos diariamente (día_00.parquet — día_13.parquet).
Canal completo de capacitación e implementación
El primer canal de Kubeflow maneja la copia de datos inicial, el preprocesamiento de datos, el entrenamiento de modelos, la indexación FAISS y la implementación del servidor de inferencia Triton.
copia de datos
La canalización comienza copiando todas las entradas necesarias para las tareas posteriores desde el depósito de S3 a un volumen persistente montado en una ruta local. Estos incluyen datos de interacción, tablas de características, imágenes de productos, modelos CLIP y Sentence-BERT previamente entrenados.
Preprocesamiento
El paso de preprocesamiento fusiona datos de interacción con tablas de características del usuario y del artículo, luego define y ajusta tres flujos de trabajo NVTabular, uno para las características del usuario [salte al CÓDIGO], uno para las características del artículo [salte al CÓDIGO] y otro para las características del contexto [salte al CÓDIGO]. También compila los subgrafos en un flujo de trabajo completo. La división de los flujos de trabajo facilitó la creación de modelos Triton separados para transformaciones de características que se pueden actualizar de forma independiente.
Otro paso de preprocesamiento simula condiciones de arranque en frío (consulte el fragmento de código a continuación) durante el entrenamiento. En el 5 % de las filas de entrenamiento, las características de ID de usuario, género y categoría superior se reemplazan con valores centinela, seguidos de un enmascaramiento aleatorio separado del 5 % del tipo de dispositivo. La transformación con los flujos de trabajo NVTabular asigna los centinelas al índice fuera de vocabulario (OOV).
#MASK algunos usuarios y características de contexto en los datos del tren con 5% de probabilidad ANONYMOUS_USER = -1 OOV_GENDER = -1 OOV_TOP_CATEGORY = -1 OOV_DEVICE = -1 masked_train_dir = os.path.join(input_path, "masked_train") os.makedirs(masked_train_dir, exist_ok=True) para i en rango(train_days): día = cudf.read_parquet(os.path.join(input_path, f"train_day_{i:02d}.parquet")) n=len(day) user_mask = cupy.random.random(n) < 0.05 day.loc[user_mask, "user_id"] = ANONYMOUS_USER day.loc[user_mask, "gender"] = OOV_GENDER day.loc[user_mask, "top_category"] = OOV_TOP_CATEGORY device_mask = cupy.random.random(n) < 0.05 day.loc[device_mask, "device_type"] = OOV_DEVICE day.to_parquet(os.path.join(masked_train_dir, f"train_day_{i:02d}.parquet"), index=False) del día gc.collect() masked_train_paths = [os.path.join(masked_train_dir, f"train_day_{i:02d}.parquet") for i in range(train_days)] masked_train_ds = Conjunto de datos(masked_train_paths) full_workflow.transform(masked_train_ds).to_parquet(os.path.join(output_path, "train")) full_workflow.transform(valid_raw).to_parquet(os.path.join(output_path, "valid"))
Para obtener las características de los artículos multimodales, las imágenes del producto se codifican utilizando OpenAI CLIP y las descripciones de los productos se codifican utilizando Sentence-BERT. Ambas incrustaciones se reducen a vectores de 64 dimensiones a través de PCA y se almacenan como tablas de búsqueda codificadas por los ID de elementos transformados de NVTabular. La edad media calculada por el flujo de trabajo del usuario se guarda para su posterior inyección en la configuración del modelo fiesta_usuario_lookup. Otro paso prepara los artefactos de funciones en línea y fuera de línea. Este paso agrega marcas de tiempo a las características del usuario y del artículo, escribe las características resultantes en la tienda fuera de línea y las materializa en la tienda en línea para su publicación. Al mismo tiempo, la información de popularidad global y específica de la categoría se calcula a partir de los datos de interacción y se escribe en la base de datos Valkey (db=3).
Entrenando el modelo de recuperación
El modelo de dos torres [saltar a CÓDIGO] se entrena únicamente en las características del usuario y del artículo, con negativos en lotes y una pérdida de contraste. La torre de consultas ingiere las características del lado del usuario, mientras que la torre candidata consume las características del elemento junto con la imagen precalculada y las incrustaciones de texto. Consulte las Figuras 5 y 6 para obtener información sobre el preprocesamiento NVTabular y los pasos de procesamiento del bloque de entrada para cada torre.
La capacitación utiliza los primeros 9 días de datos de interacción; la evaluación utiliza los días 10 a 12. Después del entrenamiento, el codificador candidato se ejecuta en todo el catálogo de artículos para calcular las incorporaciones de artículos. Para esto, un operador LookupEmbeddings personalizado (basado en BaseOperator de Merlin) maneja la búsqueda de incrustación multimodal al cargar características de elementos en lotes con el cargador de datos de Merlin. Estas incorporaciones de elementos se utilizan para construir el índice FAISS para una recuperación aproximada del vecino más cercano. El codificador de consultas se guarda por separado para la inferencia en línea.
Entrenando el modelo de clasificación
El clasificador DLRM [saltar a CÓDIGO] se entrena con los mismos datos de interacción pero con un conjunto de funciones ampliado. El conjunto de características incluye características de elementos, características de usuario, características de contexto de tiempo de solicitud (como el tipo de dispositivo y características cíclicas de hora del día y día de la semana). El objetivo de aprendizaje es una etiqueta de clic binario. Estas características del contexto representan factores situacionales que pueden moldear la elección de un cliente. Por ejemplo, un usuario puede interactuar más con ciertos elementos cuando navega en su teléfono que en una computadora de escritorio, o mostrar diferentes preferencias según la hora del día o el día de la semana.
Preparación e implementación del modelo.
Una vez que ambos modelos están entrenados, el canal ensambla los artefactos de servicio que necesita Triton. Estos incluyen la torre de consultas guardadas, el clasificador DLRM, los modelos de transformación NVTabular, el índice FAISS y las tablas de búsqueda para las incorporaciones de elementos multimodales. El repositorio de modelos Triton está estructurado con anticipación, por lo que cada implementación solo necesita copiar los artefactos del modelo en su directorio versionado e inyectar valores de tiempo de ejecución como la edad promedio del usuario (para el inicio en frío predeterminado), el topK de recuperación, el topK de clasificación y el modo de diversidad en los archivos de configuración del modelo.
Un gráfico de timón implementa Triton Inference Server en EKS, inicia el servidor en modo explícito y luego carga todos los modelos (consulte el script de inicio).
#Triton iniciando script set -e MODELS_DIR=${1:-"/model/triton_model_repository"} echo "Iniciando Triton Inference Server" echo "Directorio de modelos: $MODELS_DIR" tritonserver –model-repository="$MODELS_DIR" –model-control-mode=explicit –load-model=nvt_user_transform –load-model=nvt_item_transform –load-model=nvt_context_transform –load-model=multimodal_embedding_lookup –load-model=query_tower –load-model=faiss_retrieval –load-model=dlrm_ranking –load-model=item_id_decoder –load-model=feast_user_lookup –load-model=feast_item_lookup –load-model=filter_seen_items –load-model=softmax_sampling –load-model=context_preprocessor –load-model=unroll_features –load-model=ensemble_model
Tubería de ajuste continuo
Este canal de Kubeflow maneja actualizaciones diarias del modelo. La canalización se basa en algunos de los artefactos generados por la canalización de capacitación completa; por lo tanto, sus componentes montan el mismo volumen persistente que contiene los artefactos guardados.
Copiar datos incrementales
Al comienzo de esta ejecución, la canalización copia los datos de interacción más recientes de Amazon S3 junto con un conjunto de reproducción más pequeño de interacciones más antiguas. La parte de repetición le da al trabajo de ajuste un contexto de comportamiento más amplio y evita que los modelos se ajusten excesivamente solo al patrón más nuevo.
Datos de preprocesamiento
Este paso fusiona las características históricas del usuario y del elemento con los nuevos datos de interacción y luego transforma los datos utilizando los flujos de trabajo NVTabular adaptados del trabajo de capacitación completo reciente.
Modelos afinados
Este paso actualiza la torre de consultas y el clasificador. Inicializa el modelo de dos torres desde el punto de control anterior, pero con el codificador candidato congelado, de modo que solo se pueden entrenar los parámetros de la torre de consulta. Esto permite que el modelo se adapte al comportamiento reciente del usuario y al mismo tiempo conserva las incrustaciones del lado del elemento utilizadas por el índice ANN existente. Puede encontrar un resumen del modelo de dos torres que muestra las capas congeladas aquí.
La canalización también inicializa el clasificador DLRM desde el punto de control anterior, pero entrena todos los parámetros utilizando una tasa de aprendizaje menor y durante menos épocas.
Una vez que se completa la capacitación, guarda la torre de consultas optimizada y el clasificador DLRM en carpetas de nuevas versiones en el repositorio de modelos Triton existente.
Promocionar modelos perfeccionados
Este paso llama a Triton para cargar los nuevos modelos. Triton atiende solicitudes en vuelo sobre las versiones de modelos existentes mientras carga los nuevos modelos en segundo plano. Luego cambia en caliente a las últimas versiones del modelo una vez que están listas.
Procesamiento de solicitudes a través de los 14 modelos en el servidor NVIDIA Triton Inference
El repositorio de modelos contiene 14 modelos en dos backends. Backends de Python para búsquedas de funciones, transformaciones de funciones y filtrado; Backends de TensorFlow para la torre de consultas y el clasificador DLRM. Una configuración de conjunto conecta todos estos modelos en un gráfico acíclico dirigido (DAG) que ejecuta el servidor NVIDIA Triton Inference.
Cómo se preparan el contexto y las características del usuario
Cada solicitud llega con una identificación de usuario y un tipo de dispositivo opcional y una marca de tiempo de solicitud. Si falta algún contexto, el context_preprocessor imputa los valores predeterminados. Por ejemplo, la hora actual del servidor se imputa por una marca de tiempo faltante y un centinela OOV se imputa por un tipo de dispositivo faltante. El flujo de trabajo de contexto transforma los datos de contexto en un índice de dispositivo categorizado y cuatro características temporales (seno/coseno de hora, seno/coseno de día de la semana).
En la ruta del usuario, fiesta_usuario_lookup recupera las funciones del usuario de la tienda de funciones en línea (respaldada por ElastiCache para Valkey), luego nvt_user_transform transforma las funciones utilizando el flujo de trabajo del usuario antes de pasarlas a la torre de consulta (query_tower). La torre de consulta produce las incrustaciones de usuario que faiss_retrieval utiliza para realizar búsquedas de similitud y devuelve los ID de elementos topK.
Manejo del arranque en frío del usuario
Cuando no se encuentra una ID de usuario en la tienda de funciones en línea, fiesta_usuario_lookup utiliza los valores predeterminados, es decir, ID_usuario = -1, edad = la media de entrenamiento, género = -1 y categoría_top=-1. nvt_user_transform asigna estos centinelas user_id, género y top_category a sus índices OOV y la edad media al valor normalizado y al grupo de edad categorizado. Luego, query_tower genera la incorporación del usuario a partir de las funciones transformadas. Aunque faiss_retrieval devuelve los mismos candidatos con sesgo de popularidad para usuarios desconocidos, el clasificador DLRM aún puede personalizar el pedido de los candidatos utilizando el contexto disponible.
Filtrado de elementos vistos con un filtro Bloom
Los ID de los elementos candidatos se comparan con un filtro Bloom en ElastiCache para Valkey. Este paso puede eliminar un número significativo de candidatos, por lo que es importante realizar una búsqueda excesiva en la etapa de recuperación, ya que garantiza que el clasificador reciba suficientes candidatos para producir una lista de recomendaciones significativa.
Los ID de artículos filtrados ingresan a la canalización de características del artículo donde fiesta_item_lookup recupera las características del artículo de la tienda de características en línea, nvt_item_transform transforma estas características utilizando el flujo de trabajo del usuario y multimodal_embedding_lookup devuelve las incrustaciones de CLIP (imagen) y Sentencia BERT (texto) previamente entrenadas para los artículos.
Clasificación y ordenamiento
El modelo unroll_features muestra las características de usuario y contexto para que coincidan con el tamaño del candidato de recuperación. Luego, el clasificador DLRM (dlrm_ranking) puntúa a los candidatos. En softmax_sampling, si DIVERSITY_MODE está deshabilitado, el modelo devuelve los candidatos topK por puntuación descendente; si está habilitado, el modelo utiliza un muestreo ponderado basado en puntajes sin reemplazo para seleccionar un topK diverso y al mismo tiempo favorecer los elementos con puntajes más altos. Finalmente, item_id_decoder asigna los ID de los candidatos ordenados (índices NVTabular) a los ID de los elementos originales, y Triton devuelve los ID de los elementos seleccionados junto con sus puntuaciones correspondientes.
Mejora de la latencia de búsqueda de características de elementos con almacenamiento en caché en memoria
La creación de perfiles de servidor con Triton Performance Analyzer con un tamaño de recuperación de 300 reveló que fiesta_item_lookup consume 195 ms, lo que representó aproximadamente el 52 % de la latencia total de la solicitud con concurrencia = 1. Bajo carga, el tiempo de cola aumentó de 36 ms (con simultaneidad = 1) a 988 ms (con simultaneidad = 4). Esto limitó el rendimiento a 2,9 inferencias por segundo, independientemente de cuántas solicitudes simultáneas se emitieran.
El cuello de botella fue que fiesta_item_lookup buscaba funciones para 300 candidatos de la tienda en línea de Feast en cada solicitud. Para aliviar esto, las llamadas de Feast para las características de los elementos se reemplazaron con un caché de matriz NumPy en proceso. Esencialmente, en la inicialización de Fest_item_lookup, todas las características de los elementos se obtienen una vez de Feast y se almacenan como matrices NumPy indexadas por ID de elemento, por lo que cada solicitud lee características de la memoria en lugar de realizar llamadas de red a la tienda de características en línea. Esta optimización resultó en una mejora de aproximadamente el 99,7 % en la latencia de fiesta_item_lookup y una mejora del 54 % en la latencia de un extremo a otro (con concurrencia = 1). Además, el rendimiento (con simultaneidad = 4) mejoró en un 310 %. La única desventaja es que las funciones almacenadas en caché solo se actualizan al reiniciar Triton; sin embargo, para un catálogo con atributos de elementos bastante estáticos, esto no es problemático.
Después de este cambio, los tres modelos de transformación NVTabular nvt_user_transform (72 ms), nvt_item_transform (41 ms) y nvt_context_transform (39 ms) representaron aproximadamente el 88 % de la latencia restante. Otras optimizaciones del modelo se aplazan para una versión futura de este proyecto.
Escalado automático del servidor de inferencia Triton en EKS
En este proyecto, el servidor de inferencia Triton se escala automáticamente a través del escalador automático de pod horizontal (HPA) de Kubernetes en función de una métrica personalizada: el tiempo promedio (en milisegundos) que cada solicitud pasó esperando en la cola durante los últimos 30 segundos. Cuando esta latencia excede el objetivo, HPA amplía la implementación de Triton aumentando el número de réplicas de pods deseado. Si el nuevo pod Triton no se puede programar porque ningún nodo GPU tiene capacidad para un nuevo pod, Karpenter aprovisiona un nuevo nodo GPU y lo agrega al clúster. Una vez que el nodo está disponible, el programador de Kubernetes coloca el pod Triton en él. Una vez que el nuevo pod esté listo, el balanceador de carga puede comenzar a enrutar el tráfico hacia él.
Validación de recomendaciones contextuales, filtrado de filtros Bloom y actualizaciones de recomendaciones casi en tiempo real.
Para validar el sistema, el modo de diversidad se desactivó durante la implementación para aislar su efecto de los de los tipos de contexto, el filtrado del filtro Bloom y el cambio de preferencias en las recomendaciones.
Validar recomendaciones contextuales
Para validar las recomendaciones contextuales, experimenté con varios tipos de solicitudes, incluidas solicitudes con solo una identificación de usuario y solicitudes que combinaban una identificación de usuario con características contextuales como el tipo de dispositivo y la marca de tiempo. Estas pruebas demostraron que las recomendaciones para usuarios desconocidos varían según el contexto. Un usuario de arranque en frío puede recibir listas de elementos clasificados diferentes según el tipo de dispositivo y el tiempo de solicitud. Para los usuarios existentes, el efecto del contexto fue menos pronunciado. La clasificación general se mantuvo en gran medida estable en todos los contextos, aunque las puntuaciones de los resultados variaron.
[insertar]https://www.youtube.com/watch?v=8cGvn7Y50lg[/embed]
Validando el filtrado de elementos vistos del filtro Bloom
Para validar la exclusión de elementos vistos por parte del filtro Bloom, se hizo clic en varios elementos del carrusel Recomendado para usted. Esos elementos fueron excluidos de recomendaciones posteriores mediante el filtro Bloom. Para evitar cambiar la preferencia inferida del usuario y confundir la prueba del filtro Bloom, haga clic en elementos de diferentes categorías.
En el video que muestra el filtrado del filtro Bloom, observamos que los elementos en los que se hizo clic, como Decadent Chocolate Dream Cake y Vintage Explorer's Canvas Backpack, están excluidos de las siguientes recomendaciones del usuario 12345678.
[incrustar]https://www.youtube.com/watch?v=D7wFdhFsVU0[/embed]
Validación de actualizaciones de recomendaciones casi en tiempo real
Para validar las actualizaciones de recomendaciones casi en tiempo real para los usuarios existentes, la prueba comienza obteniendo primero recomendaciones para un usuario para establecer su preferencia actual. A continuación, se hace clic en varios elementos de la misma categoría, por ejemplo, elementos que pertenecen únicamente a Accesorios, Muebles o Comestibles, y luego se espera unos cinco segundos para que las actualizaciones surtan efecto. Las interacciones repetidas con elementos de la misma categoría pueden cambiar la preferencia inferida del usuario si esa categoría difiere de la top_category actual del usuario. La característica top_category representa la categoría dominante entre los elementos con los que ha interactuado un usuario en las últimas 24 horas y se vuelve a calcular después de cada interacción. En la siguiente solicitud, el modelo puede clasificar más arriba los elementos de esa categoría de interés recientemente expresada y mostrarlos entre las principales recomendaciones.
En el video que muestra los cambios en vivo en las recomendaciones, notamos que las principales recomendaciones del Usuario 1003 cambian de Accesorios a Decoración del hogar (y muebles) debido a interacciones repetidas con elementos de la categoría Muebles.
[insertar]https://www.youtube.com/watch?v=rwUwrISzDEQ[/embed]
Sin embargo, tenga en cuenta que la característica top_category es una aproximación burda del interés a corto plazo que se utiliza para demostrar la capacidad del sistema para adaptarse al comportamiento del usuario en tiempo real. Para un modelado de intereses más rico a corto plazo, la próxima iteración de este proyecto reemplazaría la torre de consulta estática con un codificador transformador basado en sesiones.
Limitaciones y trabajo futuro
En la arquitectura actual, el contexto del lado de la solicitud, como el tipo de dispositivo y las características derivadas de la marca de tiempo, solo lo utiliza el clasificador. Esta fue una opción de implementación para mantener la recuperación simple, ya que agregar contexto en el momento de la recuperación requeriría calcular características adicionales durante la generación de candidatos. Sin embargo, si el contexto de la solicitud influye en qué elementos deben recuperarse, los candidatos relevantes pueden filtrarse antes de que el clasificador los vea.
Una dirección futura es agregar características de contexto del lado de la solicitud a la torre de consultas, de modo que tanto la recuperación como la clasificación tengan en cuenta el contexto. Otra dirección es reemplazar la torre de consultas actual con un codificador de sesión, que capturaría más fielmente el comportamiento del usuario a corto plazo que la aproximación actual de características de comportamiento (es decir, top_category).
Conclusión
Esta publicación analizó un sistema de recomendación multimodal de varias etapas para un caso de uso de comercio electrónico, implementado en Amazon EKS. El sistema combina la recuperación de candidatos de Two-Tower, una clasificación DLRM contextual y una clasificación de diversidad basada en puntuaciones. El sistema utiliza características tabulares de usuarios y artículos, incrustaciones multimodales basadas en imágenes de productos y descripciones de texto, e información de contexto.
El arranque en frío se aborda mediante el enmascaramiento de funciones durante el entrenamiento, lo que obliga a los modelos a depender de una incrustación de OOV aprendida y de señales de contexto cuando el usuario es nuevo o desconocido. Esto significa que los usuarios nuevos y anónimos reciben recomendaciones que se adaptan a su tipo de dispositivo y al momento de su solicitud, en lugar de una lista alternativa estática. Los filtros Bloom evitan que los elementos ya vistos vuelvan a aparecer en sesiones repetidas, y el almacenamiento en memoria caché de las características de los elementos ayudó a resolver el cuello de botella de latencia en la etapa de búsqueda de características de los elementos. Además, la adaptación en tiempo real del sistema a las señales de comportamiento cambiantes se demuestra a través de la función top_category.
En el lado de MLOps, dos canalizaciones de Kubeflow gestionan el ciclo de vida del sistema. Un canal para capacitación e implementación completa, y el otro para el ajuste diario de la torre de consultas y el clasificador sin reconstruir el índice de incorporación de elementos. Karpenter y Kubernetes HPA manejan el escalado informático en respuesta a la carga de solicitudes.
El sistema muestra sistemas de recomendación de estilo de producción en los que una etapa de recuperación optimizada para velocidad y recuperación se combina con una etapa de clasificación optimizada para precisión y una capa de infraestructura diseñada para mantener los modelos actualizados sin un reentrenamiento completo en cada ciclo. Encuentre el código completo en este repositorio: MustaphaU/multistage-recommender-system-on-kubernetes
¡Espero que hayas disfrutado leyendo esto! Espero sus preguntas.
Recursos
Mustapha Unubi Momoh, sistema de recomendación multimodal multietapa en Kubernetes, repositorio de GitHub. Disponible: https://github.com/MustaphaU/multistage-recommender-system-on-kubernetes Even Oldridge y Karl Byleen‑Higley, “Recommender Systems, Not Just Recommender Models”, NVIDIA Merlin (mediano), abril de 2022. Disponible: https://medium.com/nvidia-merlin/recommender-systems-not-just-recommender-models-485c161c755e Radek Osmulski, “Exploring Production-Ready Recommender Systems with Merlin”, NVIDIA Merlin (medio), julio de 2022. Disponible: https://medium.com/nvidia-merlin/exploring-production-ready-recommender-systems-with-merlin-66bba65d18f2 Jacopo Tagliabue, Hugo Bowne‑Anderson, Ronay Ak, Gabriel de Souza Moreira y Sara Rabhi, “NVIDIA Merlin Meets the MLOps Ecosystem: Building a Production-Ready RecSys Pipeline on Cloud”, NVIDIA Merlin (medio), Febrero de 2023. Disponible: https://medium.com/nvidia-merlin/nvidia-merlin-meets-the-mlops-ecosystem-building-a-production-ready-recsys-pipeline-on-cloud-1a16c156166b. Benedikt Schifferer, “Solución del problema del arranque en frío mediante redes neuronales de dos torres para los sistemas de recomendación de correo electrónico de NVIDIA”, NVIDIA Merlin (mediano), enero de 2023. Disponible: https://medium.com/nvidia-merlin/solving-the-cold-start-problem-using-two-tower-neural-networks-for-nvidias-e-mail-recommender-2d5b30a071a4. Ziyou “Eugene” Yan, “Diseño de sistemas para recomendaciones y búsqueda”, eugeneyan.com, junio de 2021. Disponible: https://eugeneyan.com/writing/system-design-for-discovery/. Haoran Yuan y Alejandro A. Hernandez, “Problema de arranque en frío del usuario en sistemas de recomendación: una revisión sistemática”, IEEE Access, vol. 136958–136977, 2023. Disponible: https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=10339320 Justin Wortz y Justin Totten, “Scaling Deep Retrieval with TensorFlow Recommenders and Vertex AI Matching Engine”, Blog de Google Cloud, 19 de abril de 2023. Disponible: https://cloud.google.com/blog/products/ai-machine-learning/scaling-deep-retrieval-tensorflow-two-towers-architecture Sam Partee, Tyler Hutcherson y Nathan Stephens, “Offline to Online: Feature Storage for Real-time Recommendation Systems with NVIDIA Merlin”, Blog técnico de NVIDIA, 1 de marzo de 2023. Disponible: https://developer.nvidia.com/blog/offline-to-online-feature-storage-for-real-time-recommendation-systems-with-nvidia-merlin/