Uber Eats Reduce Feature Staleness de 24 Horas a Segundos Con Ranking Listwise

Uber Eats reemplazó su ranker DeepCVR pointwise con un modelo generativo listwise que califica un conjunto completo de candidatos en un forward pass único. También redujo feature staleness de 24 horas a segundos. Staff ML Engineer Yicheng Chen y colegas detalló los cambios en el blog de ingeniería de Uber.

La arquitectura anterior calificaba un comerciante por llamada de inferencia. El nuevo modelo Generative Recommender ingiere un array de tiendas candidatas y produce scores clasificados para todas en un pass único. Esto reduce el compute por tienda a aproximadamente 1/T del original, donde T es el número de tiendas objetivo. En tamaños típicos de candidate set, esa es una reducción de un orden de magnitud en la carga de inferencia del ranker.

El modelo es un híbrido dual-path. Un path DCNv2 maneja features escasas de alta dimensionalidad y estadísticas densas de comerciante. Un segundo path ejecuta un transformer-based sequence encoder sobre un registro cronológico de acciones del usuario usando multi-head self-attention. Los dos paths se fusionan antes de la calificación final, con la tienda objetivo anexada a la secuencia del usuario para que el transformer modele la relación entre comportamiento pasado y el candidato específico.

La capa de feature en tiempo real se ejecuta en una plataforma interna llamada Next Personalization Platform. FeatureExtractors — funciones Java puras — se invocan por un servicio de Feature Store en línea. Los mismos FeatureExtractors se reproducen offline vía Apache Spark para generar datos de entrenamiento, imponiendo online-offline parity. La actualización de features mejoró de retraso en batch de 24 horas a unos pocos segundos.

Los usuarios cold-start vieron las ganancias más grandes. Los vectores de feature anteriores eran escasos u obsoletos; la actualización subsecond significa que un clic único en la sesión actual remodela la clasificación antes de la carga de página. El equipo ejecuta monitoreo continuo vía sampled feature logging para detectar drift antes de degradar la calidad del modelo.

Uber no divulgó latencias p50/p99 para el transformer encoder en serving, tamaño de la flota GPU, números de A/B test lift (órdenes por usuario, click-through rate, GMV), o comparación de costo-por-inferencia entre modelos viejos y nuevos. El argumento de eficiencia listwise es matemáticamente sólido pero números de producción empíricos lo validarían en otras escalas.

Agregar un transformer sequence encoder al serving hot path introduce latencia variable vinculada a sequence length. La complejidad de attention escala cuadráticamente con sequence length a menos que esté masked o truncated. Uber no describe el sequence length cap, estrategia de masking, o manejo de usuarios con historiales muy largos sin explotar presupuestos de latencia.

El patrón más portable aquí: el modelo de parity del FeatureExtractor — una función Java llamada idénticamente en Feature Store en línea y replay Apache Spark offline. Si tu equipo mantiene lógica de feature separada para entrenamiento y serving, ese es donde fuga la calidad del modelo.