The Pulse
Meta separa i rilasci delle feature pubblicitarie: una richiesta può richiedere oltre 20.000 feature
Il sistema F3 Lightning di Meta consente di rilasciare indipendentemente le feature di machine learning per la pubblicità, mantenendo l’esecuzione condivisa. L’azienda afferma che feature di estrazione comparabili arrivano in produzione cir
AI.info Team · Scritto con l’IA · verificato ·
Meta ha pubblicato il resoconto il 3 novembre 2026, descrivendo F3 Lightning come un livello infrastrutturale per il suo Facebook Feature Framework, o F3. Il framework fornisce le feature di machine learning utilizzate dai modelli di ranking degli annunci; una singola richiesta può richiedere più di 20.000 feature. Meta afferma che il nuovo sistema consente di compilare, validare, distribuire e annullare la distribuzione di ogni feature in modo indipendente.
Una feature difettosa poteva ritardare l’intero rilascio
In origine F3 combinava i grafi delle feature di un servizio in un unico grafo di esecuzione. Quando più feature richiedevano la stessa operazione, come filtrare gli eventi in una finestra di sette giorni, il grafo unificato poteva eseguire quel lavoro una sola volta e condividerne il risultato. Lo stesso grafo unificato definiva però anche il rilascio, quindi una feature non valida poteva impedire la distribuzione delle altre.
Secondo Meta, questo vincolo è diventato più rilevante quando F3 è passato da poche centinaia di feature a oltre 20.000. Le feature già utilizzate dai modelli in produzione richiedono ulteriori test legati ai modelli prima del rilascio e l’azienda afferma che questi test vengono eseguiti in una fase successiva perché sono onerosi dal punto di vista computazionale. Con il precedente approccio ai rilasci in blocco, tutte le feature del grafo dovevano attendere quei controlli.
F3 Lightning separa la distribuzione dall’esecuzione
F3 Lightning assegna a ogni feature una propria configurazione e un proprio percorso di rilascio. Una configurazione difettosa può essere trattenuta senza bloccare una feature non correlata, mentre la coda di rilascio può assegnare priorità alle modifiche in base a ciò che sbloccano. Meta afferma che una nuova feature non ancora utilizzata da un modello può essere sottoposta alla validazione standard, mentre una modifica a una feature letta da un modello in produzione è soggetta a test aggiuntivi.
Inizialmente i rilasci indipendenti avevano un costo: i primi prototipi utilizzavano molta più CPU perché il grafo di ogni feature ripeteva letture, filtri e aggregazioni che F3 aveva condiviso. Il sistema di Meta ripristina l’esecuzione condivisa all’avvio del servizio, anziché ricostruire un unico artefatto di rilascio unificato. Compila le feature separatamente, quindi combina il lavoro che hanno in comune in un piano di esecuzione condiviso.
Quattro ottimizzazioni ripristinano il lavoro condiviso
In primo luogo, F3 Lightning ricava identificatori stabili dall’operazione, dai parametri e dagli input di un calcolo, consentendo alle feature compilate separatamente di riconoscere il lavoro identico. All’avvio, il sistema usa questi identificatori per costruire un unico piano di esecuzione, eliminare i calcoli duplicati e disporre il lavoro rimanente secondo l’ordine delle dipendenze. Appiattisce poi il piano in una lista per eseguire un passaggio in avanti a ogni richiesta.
Il piano condiviso non significa che ogni errore blocchi tutte le feature: Meta afferma che l’esecutore contrassegna il lavoro a valle come non pronto quando un calcolo fallisce o un input non è disponibile, mentre i rami indipendenti proseguono. Il sistema colloca inoltre i risultati ottenuti al momento della richiesta in un unico buffer di memoria condiviso, anziché in contenitori separati per ciascuna feature. La maggior parte dei risultati sotto forma di liste e mappe viene memorizzata una sola volta e utilizzata tramite riferimenti da chi ne fa uso; i valori scalari vengono copiati.
Infine, durante l’avvio F3 Lightning assegna a ogni calcolo univoco uno slot identificato da un numero intero consecutivo e riscrive i riferimenti nella configurazione per utilizzare quegli slot. Ciò consente al percorso di elaborazione della richiesta di leggere i risultati tramite l’indice diretto di un array, anziché risolvere gli identificatori attraverso hashing e tabelle di consultazione. Meta afferma che l’insieme di queste modifiche ha ridotto di circa 3,6 volte i tempi necessari per portare in produzione feature di estrazione comparabili rispetto a F3 tradizionale, senza aumentare il costo di calcolo dell’infrastruttura.