Riepilogo Tecnico: FusionFactory: Fondere le capacità degli LLM con i dati di log multi-LLM

Definizione del Problema

La rapida diversificazione dei Large Language Models (LLM) ha portato a un panorama in cui diversi modelli eccellono in compiti distinti (ad esempio, generazione di codice rispetto al recupero fattuale). Di conseguenza, i professionisti impiegano sempre più spesso molteplici LLM nei flussi di lavoro, generando preziosi dati di log multi-LLM. Questi dati consistono in record di servizio strutturati contenenti coppie query-risposta allineate da più modelli, insieme a metadati come l'identità del modello, la modalità di risposta (diretta o aumentata dal ragionamento), il costo di inferenza e il feedback sulla qualità.

Nonostante la disponibilità di questi dati, i metodi esistenti per integrare più LLM affrontano tipicamente solo una singola fase della pipeline in isolamento:

1. A livello di query (Query-level): I metodi di routing selezionano il miglior modello per una specifica query, ma non fondono le capacità oltre la semplice selezione.
2. A livello di pensiero (Thought-level): Le strategie di prompting aggregano il ragionamento, ma spesso mancano di una valutazione sistematica rispetto ad altre fasi di fusione.
3. A livello di modello (Model-level): La distillazione e la fusione dei modelli trasferiscono la conoscenza in un singolo modello, ma spesso ignorano i vincoli specifici del servizio basato su API o le sfumature dei dati di log.

Esiste una lacuna critica nella comprensione di come gli stessi dati di log multi-LLM strutturati possano essere sfruttati attraverso diversi punti di intervento (routing, prompting e addestramento) per soddisfare varie esigenze dell'utente, in particolare in scenari in cui i pesi dei modelli sono inaccessibili (servizio basato su API).

Metodologia

Gli autori propongono FusionFactory, un framework sistematico per fondere le capacità degli LLM, supportato da LLMFusionBench, un benchmark su larga scala progettato per valutare le strategie di fusione attraverso tre fasi distinte.

1. Costruzione di LLMFusionBench

Per consentire il confronto tra le fasi, gli autori hanno costruito un benchmark composto da:

• Ambito: 14 compiti in 6 domini (Matematica, Codice, Ragionamento di senso comune, Conoscenza del mondo, Comprensione della lettura, Conoscenza popolare).
• Dati: Risposte da 20 LLM open-source che variano da 8B a 671B di parametri, per un totale di 103M di token.
• Struttura: A differenza dei dataset standard, ogni voce è una tupla di log strutturata $(q, t, m, s, r, c, y, j)$, che cattura la query, il compito, l'identità del modello, la modalità di risposta, la risposta generata, il costo di inferenza, la performance specifica del compito e un punteggio di un LLM-judge.
• Modalità Duali: Per ogni query, i modelli generano sia risposte dirette che risposte aumentate dal ragionamento (Chain-of-Thought) per catturare diversi pattern di ragionamento.

2. Il Framework FusionFactory

FusionFactory opera a tre livelli, corrispondenti a fasi di fusione precoce, intermedia e tardiva nella pipeline degli LLM:

A. Fusione a livello di Query (Early Fusion)

• Obiettivo: Selezionare l'LLM ottimale e la modalità di risposta per una specifica query prima della generazione.
• Meccanismo: Un router apprende una policy $f_\phi$ per mappare $(query, task)$ verso un'azione $a = (model, mode)$.
• Obiettivo: Massimizzare una funzione di ricompensa che bilancia performance ($P$), costo ($C$) e qualità dell'LLM-judge ($J$):
  $$Reward = \alpha \cdot P - \beta \cdot C + \gamma \cdot J$$
• Implementazione: Valutata utilizzando vari algoritmi di routing (KNN, SVM, MLP, BERT, GraphRouter) sotto diversi scenari di ponderazione della ricompensa (Priorità alla Performance, Bilanciata, Priorità al Costo, LLM Judge).

B. Fusione a livello di Pensiero (Mid Fusion)

• Obiettivo: Potenziare la generazione iniettando pattern di ragionamento riutilizzabili senza modificare i pesi del modello.
• Meccanismo:
  1. Estrazione dei Template: Un riassumitore LLM distilla "template di pensiero" astratti dalle risposte dei top-$k$ query storiche (classificate per performance o punteggio del judge).
  2. Recupero: Per una nuova query, vengono recuperate query storiche simili tramite somiglianza di embedding.
  3. Prompting: I corrispondenti template di pensiero vengono utilizzati come dimostrazioni few-shot per guidare il target LLM.
• Strategia: Valutata utilizzando strategie di selezione basate su Performance, LLM-Judge e Ibrida per i top-$k$ risultati.

C. Fusione a livello di Modello (Late Fusion)

• Obiettivo: Consolidare le capacità complementari in un singolo modello base tramite supervised fine-tuning (SFT).
• Meccanismo: Le risposte di alta qualità dai log multi-LLM (selezionate per performance o punteggio del judge) fungono da dati di addestramento per un modello base.
• Strategia: Confronta la Top-$K$ SFT (utilizzando le risposte multi-LLM selezionate) contro la Top-$K$ Label-only SFT (utilizzando solo le verità fondamentali/ground truths) per isolare il beneficio della conoscenza multi-LLM.

Risultati Chiave

Gli esperimenti sono stati condotti sull'intero set di test di LLMFusionBench, confrontando i tre livelli di fusione rispetto al miglior LLM individuale e ai baseline zero-shot.

1. La Fusione a Livello di Pensiero Ottiene le Migliori Performance:

   • La fusione a livello di pensiero (specificamente la strategia Ibrida con modelli a scala completa) ha raggiunto la performance media più alta (0.615), superando il miglior LLM individuale (0.600) e altri baseline di fusione come LLM-Blender (0.603) e FuseLLM-adapted (0.557).
   • I guadagni sono stati più pronunciati nei compiti intensivi di ragionamento (Matematica e Codice), dove il recupero di diverse tracce di ragionamento ha fornito un valore significativo.
   • I guadagni di performance sono stati robusti anche controllando il recupero di quasi-duplicati, suggerendo che il beneficio derivi da pattern di ragionamento riutilizzabili piuttosto che dalla semplice sovrapposizione di dati.

2. La Fusione a Livello di Query Offre la Migliore Efficienza dei Costi:

   • La fusione a livello di query (tramite GraphRouter) ha fornito un rapporto favorevole tra performance e costo.
   • In uno scenario di routing consapevole dei costi, ha raggiunto una performance paragonabile al miglior singolo LLM, ma con un costo di inferenza circa 10 volte inferiore (0.0184 vs 0.1850 in unità normalizzate).
   • Ciò conferma la sua utilità per il servizio basato su API dove minimizzare l'uso dei token è critico.

3. La Fusione a Livello di Modello Mostra una Limitata Generalizzazione:

   • La fusione a livello di modello (SFT) ha prodotto guadagni modesti e, in alcuni domini (Codice e Conoscenza del Mondo), ha performato peggio dei baseline zero-shot.
   • Gli autori attribuiscono ciò all'overfitting sugli stili di risposta specifici dei dati loggati e alla difficoltà di astrarre comportamenti di task eterogenei in un singolo set di parametri.
   • Significativamente, la multi-LLM SFT ha superato la Label-only SFT, confermando che i log multi-LLM contengono una conoscenza preziosa oltre le verità fondamentali, ma il processo di consolidamento introduce sfide di generalizzazione.

4. Variazioni Specifiche per Dominio:

   • La fusione ha fornito miglioramenti marginali nei domini di Conoscenza del Mondo e Matematica, che si affidano fortemente alla precisione fattuale rigorosa e alla coerenza logica, suggerendo che queste aree siano meno adatte agli attuali euristici di fusione.
   • I compiti pesanti di ragionamento (Matematica, Codice) hanno beneficiato maggiormente della fusione a livello di pensiero, mentre i compiti basati sulla conoscenza hanno mostrato risultati misti.

Significato e Rivendicazioni

Il paper afferma che FusionFactory e LLMFusionBench forniscono una prospettiva unificata e consapevole delle fasi sulla fusione degli LLM che era precedentemente mancante.

• Oltre la Compatibilità API: Mentre il lavoro precedente si concentrava sul routing basato solo su API, questo lavoro dimostra che gli stessi dati di log multi-LLM strutturati possono essere valutati sistematicamente attraverso le fasi di routing, prompting e addestramento.
• Framework Decisionale: La "matrice delle fasi di fusione" rivela che non esiste una singola strategia di fusione ottimale; la scelta dipende dai vincoli di implementazione (es. costo vs accuratezza) e dai requisiti del compito (es. ragionamento vs richiamo).
  • Usare il Livello di Query per scenari sensibili ai costi e ad alto throughput.
  • Usare il Livello di Pensiero per massimizzare le capacità di ragionamento senza il riaddestramento del modello.
  • Usare il Livello di Modello solo quando è richiesto strettamente un singolo modello distribuibile e l'addestramento offline è fattibile, riconoscendo i suoi limiti di generalizzazione.
• Fondamenta Pratiche: Il lavoro valida i dati di log multi-LLM come una fonte di supervisione pratica e scalabile per fondere le diverse capacità degli LLM, offrendo un blueprint per futuri sistemi che devono operare in ambienti di servizio eterogenei e reali.

Gli autori concludono che, sebbene la fusione a livello di pensiero offra attualmente i guadagni di performance più forti, il confronto sistematico reso dal loro framework è essenziale per comprendere i compromessi tra flessibilità, costo e generalizzazione nei sistemi multi-LLM.