Versioned Late Materialization for Ultra-Long Sequence Training in Recommendation Systems at Scale

1. Enunciato del Problema: Il Collo di Bottiglia della "Riga Grassa"

I moderni Modelli di Raccomandazione basati su Deep Learning (DLRM) seguono leggi di scalabilità in cui la qualità del modello migliora in modo monotono con sequenze di Storico delle Interazioni Utente (UIH) più lunghe (passando da $10^4$ a $10^5+$ eventi). Tuttavia, l'approccio standard del settore per gestire questi dati crea un collo di bottiglia infrastrutturale critico noto come problema della "Riga Grassa".

• Ridondanza di Pre-Materializzazione: I sistemi attuali duplicano fisicamente (pre-materializzano) l'intera sequenza UIH in ogni singolo esempio di addestramento per garantire la coerenza Online-to-Offline (O2O).
• Amplificazione K-Fold: Se un utente ha $N$ giorni di cronologia e genera $K$ richieste di ranking all'interno di una finestra di retrospettiva, gli stessi dati storici vengono archiviati $K$ volte. Ciò porta a una massiccia ridondanza di archiviazione e I/O.
• Il Muro delle Risorse: All'aumentare delle lunghezze delle sequenze, il consumo di risorse dei servizi di supporto ai dati (archiviazione, ingestione, pre-elaborazione) supera la capacità dei cluster di addestramento GPU. Ciò crea una trappola di "rendimenti decrescenti" in cui i costi infrastrutturali limitano la capacità di scalare le lunghezze delle sequenze, impedendo di fatto l'adozione di architetture di nuova generazione come HSTU e ULTRA-HSTU.
• Penalità Multi-Tenant: In dataset unitari condivisi che servono più tenant di modelli (ad esempio, modelli di retrieval vs. modelli di ranking con esigenze diverse di lunghezza delle sequenze), il paradigma della "Riga Grassa" costringe tutti i modelli a leggere la lunghezza massima delle sequenze, causando un'amplificazione I/O non necessaria per i modelli con sequenze più brevi.

2. Metodologia: Materializzazione Tardiva Versionata

Gli autori propongono un cambio di paradigma dalla pre-materializzazione pesante in termini di archiviazione a un approccio di materializzazione tardiva centrato sul calcolo. L'idea fondamentale è che l'UIH è una sequenza append-only, ordinata temporalmente e immutabile. Pertanto, lo stato esatto della cronologia di un utente in qualsiasi momento di inferenza $t$ può essere ricostruito in modo deterministico senza archiviare snapshot fisici.

A. Il Protocollo

Il sistema utilizza un protocollo biforcato per garantire la coerenza O2O e prevenire la fuoriuscita di dati futuri:

1. Snapshotting al Momento dell'Inferenza:
   • Invece di registrare l'intera UIH, il sistema registra solo metadati di versione leggeri (confini temporali start_ts, end_ts, lunghezza della sequenza e un checksum) accanto alla porzione UIH mutabile (recente).
   • Ciò disaccoppia l'amplificazione di scrittura del logging dalla lunghezza totale della sequenza (metadati $O(1)$ vs dati $O(seq\_length)$).
2. Ricostruzione al Momento dell'Addestramento:
   • Durante la pre-elaborazione dei dati di addestramento, il sistema esegue una ricostruzione "Time-Travel".
   • Recupera l'UIH mutabile recente dall'esempio di addestramento ed esegue una scansione di intervallo limitata contro un archivio UIH normalizzato e immutabile utilizzando i confini temporali registrati.
   • I due componenti vengono concatenati per ricreare lo stato esatto del momento dell'inferenza.

B. Architettura di Archiviazione

• Archiviazione Ibrida:
  • UIH Mutabile: Un archivio in tempo reale per eventi recenti (freschezza a livello di secondi), accessibile solo durante l'inferenza.
  • UIH Immutabile: Un archivio normalizzato, ottimizzato per la lettura, per la cronologia a lungo termine. Utilizza un layout a livello singolo con file pre-ordinati e ordinati cronologicamente per garantire I/O puramente sequenziale durante le scansioni di intervallo.
• Proiezione Multidimensionale: L'archivio immutabile organizza i dati per user_id, feature_group e subsequence_timestamp. Ciò consente al sistema di spingere le proiezioni a livello di archiviazione:
  • Proiezione della Lunghezza della Sequenza: I modelli più brevi scansionano solo il numero richiesto di strisce temporali.
  • Proiezione del Gruppo di Caratteristiche: I modelli leggono solo le colonne di caratteristiche pertinenti.
• Codifica Consapevole delle Caratteristiche: Utilizza una codifica colonnare (delta-encoding, bitmap, compressione dizionario) per gestire caratteristiche sparse rispetto a quelle dense, abilitando la decodifica selettiva a livello di byte.

C. Ottimizzazione della Pipeline di Addestramento

Per evitare che il processo di ricostruzione blocchi l'addestramento GPU (starvation della GPU), il sistema implementa:

• Pre-elaborazione Dati Disaccoppiata (DPP): Scarica l'I/O pesante e la decodifica su un cluster separato e scalabile elasticamente di worker di pre-elaborazione.
• Prefetching I/O in Pipeline: Sovrappone la lettura del prossimo batch di addestramento con la ricerca della sequenza del batch corrente per mascherare la latenza.
• Sharding con Affinità ai Dati: Garantisce che gli esempi di addestramento e i relativi dati UIH risiedano sullo stesso shard di archiviazione (tramite partizionamento hash identico), minimizzando il fanout di rete e massimizzando i tassi di hit della cache per i lavori batch.

3. Contributi Chiave

1. Formalizzazione del Problema della Riga Grassa: Analisi quantitativa che dimostra come la ridondanza dell'UIH pre-materializzata guidi l'utilizzo dell'infrastruttura dati oltre la capacità di addestramento GPU, limitando la scalabilità del modello.
2. Protocollo di Materializzazione Tardiva Versionata: Una soluzione unificata per l'addestramento sia in streaming che batch che garantisce la coerenza O2O e previene la fuoriuscita di dati futuri utilizzando metadati di versione leggeri e predicati temporali.
3. Architettura di Livello Produttivo: Un sistema che combina archiviazione immutabile ottimizzata per la lettura, pushdown di proiezioni multi-tenant e pre-elaborazione disaccoppiata per mascherare la latenza di ricostruzione, mantenendo il throughput di addestramento vincolato alla GPU.
4. Deploy su Scala: Implementazione riuscita sui DLRM di produzione di Meta, che consente una scalazione aggressiva della lunghezza delle sequenze (fino a $10^5$ eventi) riducendo al contempo l'utilizzo delle risorse infrastrutturali.

4. Risultati

Il sistema è stato valutato su tre tenant di modelli che condividono un dataset unitario e su due piattaforme di raccomandazione di produzione.

• Efficienza del Sistema:

  • Larghezza di Banda di Scrittura: Riduzione della larghezza di banda di scrittura primaria del 46,2% eliminando la ridondanza K-fold.
  • Larghezza di Banda di Lettura: Riduzione della larghezza di banda di lettura per lavoro del 47–70%. I modelli con sequenze più brevi (B e C) hanno visto ulteriori guadagni (fino al 70% di riduzione) grazie al pushdown delle proiezioni.
  • Latenza: Nonostante l'aggiunta di ricerche di sequenza, il sistema ha mantenuto una bassa latenza. Il Modello A (sequenza lunga) ha registrato un aumento della latenza di caricamento dei dati di solo 9,7%, assorbito dal ridimensionamento elastico del DPP. I modelli B e C hanno visto miglioramenti della latenza del 26–36% grazie al pushdown delle proiezioni.
  • Throughput: L'archiviazione immutabile ha fornito un throughput di lettura 3,4 volte superiore per unità di risorsa host rispetto all'archiviazione append-only di base.

• Prestazioni del Modello:

  • Svolta nella Scalabilità: Il sistema ha superato il "Muro della Riga Grassa" (dove i costi dei dati superano i costi GPU a una lunghezza di sequenza di circa 4K).
  • Miglioramenti della Qualità:
    • Piattaforma A: Ha raggiunto un ulteriore guadagno cumulativo del 1,2% di Entropia Normalizzata (NE) scalando da 4K a 64K eventi (guadagno totale >5%).
    • Piattaforma B: Ha raggiunto un guadagno del 0,65% di NE scalando da 4K a 10K eventi.
  • Impatto Online: I test A/B hanno confermato miglioramenti significativi nelle metriche di coinvolgimento (Topline, Consumo, Coinvolgimento Esplicito) quando si scalano le lunghezze delle sequenze, guadagni che erano precedentemente impossibili sotto il paradigma della Riga Grassa.

5. Significato

Questo documento stabilisce che l'infrastruttura dati è una leva di scalabilità di primo piano per i sistemi di raccomandazione, complementare ai progressi nell'architettura dei modelli. Trattando l'UIH come una sequenza immutabile e versionata piuttosto che come uno snapshot statico, gli autori hanno eliminato i muri di archiviazione e I/O che in precedenza impedivano al settore di addestrare su sequenze ultra-lunghe. Questo paradigma consente il deploy pratico di framework di raccomandazione generativa e trasduttori sequenziali trilioni di parametri, sbloccando significativi miglioramenti nella qualità del modello che erano precedentemente proibitivi in termini di costi.