JourneyFormer de Airbnb Cómo los Modelos de Secuencia Transformer Están Cambiando la Búsqueda Personalizada

¡Adiós Features Manuales, Hola Jornadas Aprendidas!

Por años, el ranking de búsqueda de Airbnb dependió de estadísticas agregadas y hechas a mano, como el total de reservas pasadas o el precio promedio de los listados. Esto funcionó, pero llegó a un límite: con cientos de features, el modelo se volvió difícil de escalar y limitado en expresividad. El problema es que la jornada de un huésped es una secuencia rica de eventos: vistas, reservas, reseñas y cancelaciones a lo largo de años. Capturar esa narrativa con features estáticas es como intentar entender un libro solo por su portada.

En este artículo, vamos a explorar el JourneyFormer, el modelo de secuencia basado en Transformer que codifica la jornada completa del huésped. Este cambio es un hito en sistemas de recomendación, pasando de la ingeniería de features al aprendizaje de representaciones. Y ojo, estos cambios en la plataforma web también nos afectan a los devs — checa nuestro post sobre las actualizaciones de la web platform en junio 2026.

La Arquitectura: Separando la Intención a Corto Plazo de la Memoria a Largo Plazo

La decisión más importante fue dividir la secuencia de eventos del huésped en dos partes para resolver problemas de costo computacional y señales dispersas.

El Diseño de las Dos Secuencias

• Secuencia a Largo Plazo: Captura eventos infrecuentes pero informativos de los últimos siete años (reservas, reseñas, cancelaciones). Limitada a 80 eventos, da profundidad y contexto.
• Secuencia a Corto Plazo: Captura vistas de listados de los últimos 21 días, representando la intención inmediata de búsqueda. Limitada a 200 eventos, se enfoca en lo reciente.

Ambas secuencias comparten una tabla de embeddings unificada para IDs de alta cardinalidad, como los de listados y anfitriones, permitiendo representaciones ricas y compartidas.

Eficiencia: 4x Más Throughput en Entrenamiento

El equipo implementó tres estrategias para hacer el entrenamiento viable con cientos de millones de ejemplos:

1. Batching de Búsquedas: En lugar de correr el encoder para cada búsqueda, el modelo corre una vez sobre la secuencia completa. Con la máscara causal, los embeddings intermedios se enrutan a las búsquedas correspondientes, permitiendo que varias búsquedas compartan un solo forward pass.
2. Bucketing por Longitud: Las secuencias se agrupan por tamaño para minimizar el desperdicio de padding en los batches.
3. Cálculo Disperso: Las búsquedas con padding se eliminan del modelo de ranking.

# Ejemplo simplificado del concepto de batching de búsquedas

def agrupa_encodings_busquedas(secuencia_eventos, timestamps_busquedas):
    """
    Procesa la secuencia completa una vez y enruta embeddings
    intermedios a las búsquedas correspondientes.
    """
    # Placeholder para el forward pass del encoder Transformer
    todos_embeddings = transformer_encoder(secuencia_eventos)

    embeddings_busquedas = {}
    for timestamp in timestamps_busquedas:
        # El embedding en timestamp-1 captura todos los eventos hasta ese punto
        embeddings_busquedas[timestamp] = todos_embeddings[timestamp - 1]

    return embeddings_busquedas

Sirviendo: Desacoplando la Inferencia para Baja Latencia

Para mantener la latencia baja al momento de la búsqueda, el sistema separa la inferencia en dos etapas:

• Job Diario en Batch: El encoder de secuencia procesa el historial de eventos diariamente y guarda los embeddings resultantes.
• Recuperación en Tiempo Real: Al momento de la búsqueda, el modelo de ranking recupera el embedding guardado y lo combina con la query en vivo para puntuar los listados candidatos.

Resultados, Limitaciones y el Camino a Seguir

Los resultados son impresionantes. Los tests A/B mostraron ganancias estadísticamente significativas: +0.55% en huéspedes que no cancelaron y +0.90% en vistas combinando ambas secuencias. El setwise ranker final añadió +0.28% en reservas no canceladas. En total, el sistema completo logró +3.78% de mejora offline en NDCG — una ganancia enorme en un sistema refinado por más de una década.

Limitaciones y Puntos de Atención

A pesar del poder, este enfoque tiene limitaciones:

• Costo Computacional: Entrenar un Transformer a esta escala requiere una inversión significativa en infraestructura.
• Problema del Cold Start: El modelo depende de eventos históricos, siendo menos efectivo para huéspedes nuevos con poco historial.
• Recencia de Datos: La inferencia en batch diario puede no reflejar cambios en la intención del huésped dentro de un mismo día.

Próximos Pasos para Aprender

Para profundizar en este dominio, explora:

1. Setwise Ranking: Aprende cómo difiere del pointwise al considerar un conjunto de candidatos juntos.
2. Modelado de Secuencias: Estudia la arquitectura Transformer y sus aplicaciones más allá de NLP.
3. Aprendizaje de Embeddings: Mira cómo las tablas de embeddings unificadas manejan features de alta cardinalidad.

Conclusión: Una Nueva Era en la Búsqueda Personalizada

JourneyFormer representa un cambio fundamental en cómo Airbnb entiende a sus huéspedes. Al aprender directamente de la jornada completa, el modelo captura preferencias que antes eran inaccesibles. El éxito tanto en la búsqueda como en los emails promocionales valida el poder y la generalidad de este enfoque. El mensaje es claro: el futuro de los sistemas de recomendación no está en más features, sino en mejores representaciones de las jornadas de los usuarios. Para más consejos de front-end, mira nuestro guía sobre estilización de pseudo-elementos de resaltado.

Fuente: Airbnb Engineering Blog