IT
Un decoder più piccolo sposta la ricerca fuori dal modello completo
Separating Thinking from Spelling for Efficient Generative Recommendation · arXiv:2610.32980
In parole semplici
I sistemi di raccomandazione usano le scelte passate di una persona per suggerire cosa potrebbe interessarle in seguito. Un modello grande, però, può passare molto tempo a cercare ripetutamente tra i codici dei possibili articoli.
Deco fa riassumere la cronologia una volta al modello grande, poi affida la ricerca a un decoder più piccolo. Su sette dataset pubblici ha eguagliato o superato il modello completo usato per il confronto nelle misure di accuratezza delle raccomandazioni.
Questo mostra che l’approccio ha funzionato in quei test, ma non stabilisce che valga in ogni contesto.
La ricerca
Quando un modello di raccomandazione ha già compresso la cronologia di un utente, il modello completo deve ancora ripetere il lavoro di ricerca tra gli articoli candidati?
Il paper misura questo costo residuo e chiede se un decoder più piccolo possa generare i candidati mantenendo la qualità delle raccomandazioni.
Deco fa riassumere una volta al backbone la cronologia di un utente, poi affida a un decoder più piccolo la generazione dei candidati per le raccomandazioni.
Deco fa leggere una volta al backbone la cronologia delle interazioni di un utente e ne ricava un concetto compatto dei possibili articoli successivi. Un decoder più piccolo usa quel concetto per generare codici candidati.
Gli autori hanno confrontato questo design con FusedGR, che usa il backbone completo durante la generazione dei candidati, su sette dataset pubblici con una suddivisione temporale globale.
Deco ha eguagliato o superato FusedGR nelle misure di accuratezza delle raccomandazioni, calcolate come medie sugli utenti di test e su tre seed di addestramento.
Nei test di serving su una GPU H100 ha servito da 3.2 a 7.3 volte più utenti al secondo sui dataset, rispettando un obiettivo di latenza al 95° percentile di 50 ms. Nel loro insieme, questi risultati mostrano che il passaggio al decoder testato ha mantenuto la qualità e aumentato la capacità di serving sotto quel vincolo.
Le evidenze coprono sette dataset pubblici con una suddivisione temporale globale. Il confronto in fase di serving è stato eseguito su una GPU H100, con beam width 100 e un obiettivo di latenza p95 di 50 ms. Il confronto separato leave-one-out è limitato a Beauty.
Cosa mostrano le prove
- Un costo di ricerca residuo
Deco, abbreviazione di decoding from concepts, è un metodo generativo per le raccomandazioni. Affronta un costo che resta anche dopo che un modello ha compresso la cronologia delle interazioni di un utente: il modello completo potrebbe continuare a elaborare ripetutamente i passaggi necessari a generare candidati.
La ricerca chiede se un decoder più piccolo possa occuparsene mantenendo la qualità delle raccomandazioni.
- Un passaggio a un decoder compatto
Il metodo fa leggere la cronologia una volta al backbone e ne ricava un concetto compatto che rappresenta i possibili articoli successivi. Un decoder più piccolo usa quel concetto e i codici già generati per produrre ID semantici candidati; un trie limita il codice successivo alle opzioni valide. Il backbone, quindi, non ripete la ricerca per ogni candidato.
- La ricerca domina in un test
Gli autori hanno prima misurato come si distribuisse il tempo di generazione. Su BPC-23, con batch size 128, la beam search rappresentava il 91% del tempo di generazione di FusedGR, anche con una cache condivisa della cronologia.
Nella configurazione misurata, questo indica perché accorciare soltanto l’input della cronologia lasciava ancora del lavoro da eliminare.
- Qualità e risultati di serving
Su sette dataset pubblici con una suddivisione temporale globale, Deco ha eguagliato o superato FusedGR nelle misure di accuratezza delle raccomandazioni riportate.
I risultati principali sono medie calcolate sugli utenti di test e su tre seed di addestramento. Nei test di serving su una GPU H100, con beam width 100, Deco ha servito da 3.2 a 7.3 volte più utenti al secondo su quei dataset, rispettando un obiettivo di latenza al 95° percentile di 50 ms.
- Un’eccezione con molte ripetizioni
Il riassunto compatto è bastato sui dataset testati Sports e BPC-23, dove le ripetizioni sono poche: dare al decoder un accesso più ricco alla cronologia ha modificato poco le misure di accuratezza e poteva aumentare la latenza.
Yambda circoscrive questo risultato. Un puntatore ai brani passati ha portato NDCG@10 di Deco da 0.079 a 0.171, in linea con l’interpretazione degli autori secondo cui per riproporre esattamente un articolo serve accedere all’identità dell’articolo.
Dettagli
- Autori del paper originale
- Danil Gusak, Anna Volodkevich, Ivan Oseledets, Evgeny Frolov
- Inviato ad arXiv
- Licenza
- CC BY 4.0