Me gustaría compartir una variación práctica del enfoque de integración de dos torres (TTE) de Uber para casos en los que tanto los datos relacionados con el usuario como los recursos informáticos son limitados. El problema surgió de un widget de descubrimiento de alto tráfico en la pantalla de inicio de una aplicación de entrega de alimentos. Este widget muestra selecciones seleccionadas como italiano, hamburguesas, sushi o saludable. Las selecciones se crean a partir de etiquetas: cada restaurante puede tener varias etiquetas y cada mosaico es esencialmente una porción del catálogo definida por etiquetas (con la adición de algo de selección manual). En otras palabras, el conjunto de candidatos ya se conoce, por lo que el verdadero problema no es su recuperación sino su clasificación.
En ese momento, este widget tenía un rendimiento significativamente inferior en comparación con otros widgets en una pantalla de descubrimiento (principal). La selección final se clasificó según la popularidad general sin tener en cuenta ninguna señal personalizada. Lo que descubrimos es que los usuarios son reacios a desplazarse y si no encuentran algo interesante dentro de las primeras 10 a 12 posiciones, generalmente no realizan conversiones. Por otro lado, la oferta puede ser a veces enorme, en algunos casos hasta 1.500 restaurantes. Además de eso, se podría seleccionar un solo restaurante para diferentes selecciones, lo que significa que, por ejemplo, McDonald’s se puede seleccionar tanto para hamburguesas como para helados, pero está claro que su popularidad solo es válida para la primera selección, pero la clasificación de popularidad general lo colocaría en la cima en ambas selecciones.
La configuración del producto hace que el problema sea aún menos amigable con las soluciones estáticas, como la clasificación por popularidad general. Estas colecciones son dinámicas y cambian con frecuencia debido a campañas estacionales, necesidades operativas o nuevas iniciativas comerciales. Por eso, entrenar un modelo dedicado para cada selección individual no es realista. Un recomendador útil debe generalizarse a nuevas colecciones basadas en etiquetas desde el primer día.
Antes de pasar a una solución de estilo de dos torres, probamos enfoques más simples, como una clasificación de popularidad localizada a nivel de ciudad-distrito y bandidos con múltiples brazos. En nuestro caso, ninguno de los dos produjo un aumento mensurable respecto de la popularidad general. Como parte de nuestra iniciativa de investigación, intentamos ajustar el TTE de Uber a nuestro caso.
Resumen de las incrustaciones de dos torres
Un modelo de dos torres aprende dos codificadores en paralelo: uno para el lado del usuario y otro para el lado del restaurante. Cada torre produce un vector en un espacio latente compartido y la relevancia se estima a partir de una puntuación de similitud, normalmente un producto escalar. La ventaja operativa es el desacoplamiento: las incrustaciones de restaurantes se pueden precalcular fuera de línea, mientras que la incrustación del usuario se genera en línea en el momento de la solicitud. Esto hace que el enfoque sea atractivo para sistemas que necesitan puntuación rápida y representaciones reutilizables.
El artículo de Uber se centró principalmente en la recuperación, pero también señaló que la misma arquitectura puede servir como capa de clasificación final cuando la generación de candidatos ya se maneja en otro lugar y la latencia debe permanecer baja. Esa segunda formulación estaba mucho más cerca de nuestro caso de uso.
Nuestro enfoque
Mantuvimos la estructura de dos torres pero simplificamos las partes que requieren más recursos. En el lado del restaurante, no ajustamos un modelo de lenguaje dentro del recomendador. En cambio, reutilizamos un modelo TinyBERT que ya había sido ajustado para la búsqueda en la aplicación y lo tratamos como un codificador semántico congelado. Su incrustación de texto se combinó con características explícitas del restaurante, como precio, calificaciones y señales de desempeño recientes, además de una pequeña incrustación de identificación de restaurante entrenable, y luego se proyectó en el vector final del restaurante. Esto nos brindó cobertura semántica sin pagar el costo total de la capacitación en modelos de lenguaje de un extremo a otro. Para un POC o MVP, un pequeño transformador de oraciones congeladas también sería un punto de partida razonable.
Evitamos aprender a incorporar una ID de usuario dedicada y, en su lugar, representamos a cada usuario sobre la marcha a través de sus interacciones anteriores. El vector de usuario se construyó a partir de incrustaciones promedio de restaurantes en los que el cliente había pedido (la publicación de Uber también menciona esta fuente, pero los autores no especifican cómo se usó), junto con las características de usuario y sesión. También utilizamos las visualizaciones sin pedidos como señal negativa débil. Eso importaba cuando el historial de pedidos era escaso o irrelevante para la selección actual. Si bien el modelo no podía inferir claramente qué le gustaba al usuario, aun así ayudaba saber qué restaurantes ya habían sido explorados y rechazados.
La elección de modelado más importante fue filtrar ese historial por la etiqueta de la selección actual. Promediar todo el historial de pedidos generó demasiado ruido. Si un cliente pidiera principalmente hamburguesas y luego abriera una selección de helados, un promedio global podría llevar el modelo hacia hamburgueserías que vendieran postres en lugar de hacia los candidatos más fuertes a helados. Al filtrar las interacciones pasadas con etiquetas coincidentes antes de promediar, hicimos que la representación del usuario fuera contextual en lugar de global. En la práctica, ésta era la diferencia entre modelar el gusto a largo plazo y modelar la intención actual.
Finalmente, entrenamos el modelo a nivel de sesión y utilizamos el aprendizaje multitarea. Un mismo restaurante podría ser positivo en una sesión y negativo en otra, dependiendo de la intención actual del usuario. El jefe de clasificación predijo el clic, el agregado a la cesta y el pedido de manera conjunta, con una simple restricción de embudo: P(pedido) ≤ P(agregar a la cesta) ≤ P(clic). Esto hizo que el modelo fuera menos estático y mejoró la calidad de la clasificación en comparación con la optimización de un único objetivo de forma aislada.
La validación fuera de línea también fue más estricta que una división aleatoria: la evaluación utilizó datos fuera de tiempo y usuarios que no fueron vistos durante el entrenamiento, lo que hizo que la configuración se acercara más al comportamiento de producción.
Resultados
Según las pruebas A/B, el sistema final mostró un aumento estadísticamente significativo en la tasa de conversión. Igual de importante es que no estaba vinculado a un solo widget. Debido a que el modelo puntúa un par usuario-restaurante en lugar de una lista fija, se generalizó naturalmente a nuevas selecciones sin cambios arquitectónicos, ya que las etiquetas son parte de los metadatos del restaurante y se pueden recuperar sin selecciones en mente.
Esa transferibilidad hizo que el modelo fuera útil más allá de la superficie de clasificación original. Posteriormente lo reutilizamos en Anuncios, donde su resultado orientado al CTR se aplicó a restaurantes promocionados individuales con resultados positivos. Por lo tanto, la misma configuración de aprendizaje de representación funcionó tanto para la clasificación de selección como para otros problemas de ubicación similares a recomendaciones dentro de la aplicación.
Investigaciones adicionales
El siguiente paso más obvio es la multimodalidad. Se pueden agregar imágenes de restaurantes, íconos y potencialmente elementos visuales del menú como ramas adicionales a la torre del restaurante. Esto es importante porque el comportamiento de los clics está fuertemente influenciado por la presentación. Una pizzería dentro de una selección de pizzas puede tener un rendimiento inferior si su imagen principal no muestra pizza, mientras que un restaurante económico puede parecer premium simplemente por su imagen de héroe. El texto y las características tabulares no capturan bien esa brecha.
Conclusiones clave:
Los modelos de dos torres pueden funcionar incluso con datos limitados. No necesita una infraestructura a escala de Uber si la recuperación de candidatos ya está resuelta y el modelo se centra únicamente en la etapa de clasificación. Reutilice incorporaciones previamente entrenadas en lugar de entrenar desde cero. Un modelo de lenguaje ligero congelado (por ejemplo, TinyBERT o un pequeño transformador de oraciones) puede proporcionar señales semánticas fuertes sin necesidad de realizar costosos ajustes. Promediar las incorporaciones de restaurantes pedidos previamente funciona sorprendentemente bien cuando el historial del usuario es escaso. El filtrado contextual reduce el ruido y ayuda al modelo a capturar la intención actual del usuario, no sólo el gusto a largo plazo. Las señales negativas ayudan en entornos dispersos. Los restaurantes que los usuarios vieron pero no realizaron pedidos brindan información útil cuando las señales positivas son limitadas. El aprendizaje multitarea estabiliza la clasificación. Predecir clics, agregar a la cesta y realizar pedidos junto con restricciones de embudo produce puntuaciones más consistentes. Diseño para reutilización. Un modelo que puntúa pares de usuario-restaurante en lugar de listas específicas se puede reutilizar en superficies de productos como selecciones, clasificación de búsqueda o anuncios.