Sintesi Tecnica: Brick - Routing della Capacità Spaziale per il Paradigma Mixture-of-Models (MoM)

1. Definizione del Problema

Il documento affronta la sfida di instradare efficientemente le query attraverso un pool eterogeneo di Large Language Models (LLM) durante l'inferenza. La difficoltà principale risiede nel definire empiricamente la "difficoltà": la complessità di una query non è determinata da caratteristiche superficiali come il conteggio dei token o le etichette di dominio, ma dai requisiti specifici di capacità del compito rispetto ai punti di forza e di debolezza di un modello.

Le strategie di routing esistenti si affidano al routing superficiale (basato su dominio o su lunghezza/parole chiave), che non riesce a catturare la varianza intra-dominio. Ad esempio, una query breve potrebbe puntare a un problema irrisolto che richiede un modello frontier, mentre un lungo prompt di bozza potrebbe avvolgere un compito banale risolvibile da un piccolo modello open-weight. Ciò porta a due inefficienze:

1. Inefficienza dei Costi: Inviare query facili a modelli frontier costosi (es. Kimi 2.6) spreca budget, poiché modelli open-weight locali (es. Qwen 3.5-9B) sono spesso sufficienti.
2. Compromessi tra Latenza e Accuratezza: Il routing a cascata (testare i modelli dal più economico al più costoso) comporta un overhead significativo nei flussi di lavoro agentici, dove una singola richiesta dell'utente innesca molteplici chiamate LLM, compounding il costo dei tentativi "economici" respinti.

L'obiettivo è indirizzare ogni query al modello più economico che sia in grado di rispondere correttamente, bilanciando costo, latenza e accuratezza senza fare affidamento su euristiche superficiali.

2. Metodologia: Il Router Brick

Gli autori propongono Brick, un router multimodale che opera all'interno del paradigma Mixture-of-Models (MoM). A differenza della Mixture of Experts (MoE), che attiva sottoreti all'interno di un singolo modello, il MoM indirizza intere query a modelli distinti e indipendenti.

2.1 Il Paradigma MoM

Brick utilizza un pool di tre modelli eterogenei:

• Qwen3.5-9B: Un modello open-weight allo stato dell'arte (<10B parametri).
• DeepSeek-V4-Flash: Un modello open-weight allo stato dell'arte (<500B parametri).
• Kimi2.6: Un contendente open-source frontier.

Il pool copre diversi punti di prezzo (che vanno da circa $0.001 a$0.03 per chiamata) e profili di capacità, permettendo al router di sfruttare la complementarità delle capacità (ad esempio, un modello può rifiutare una query che un altro risolve).

2.2 Lo Spazio delle Capacità a Sei Dimensioni

Brick inquadra il routing come una decisione geometrica in uno spazio di capacità a sei dimensioni. Le dimensioni sono:

1. Coding (Programmazione)
2. Creative Synthesis (Sintesi Creativa)
3. Instruction Following (Seguire le Istruzioni)
4. Math Reasoning (Ragionamento Matematico)
5. Planning/Agentic (Pianificazione/Agentico)
6. World Knowledge (Conoscenza del Mondo)

La Pipeline:

1. Stima della Capacità: Un classificatore ModernBERT finemente regolato mappa la query in un vettore di probabilità $p(x)$ sulle sei dimensioni.
2. Stima della Complessità: Un classificatore separato stima un punteggio di difficoltà $\tau_q$ (miscelato da ancoraggi "facile/medio/difficile").
3. Calibrazione della Matrice delle Skill: Una matrice delle skill $S$, calibrata offline, memorizza i tassi di successo empirici ($s_{m,c}$) di ogni modello $m$ su ogni capacità $c$, derivati da un dataset etichettato.
4. Matematica del Routing Geometrico:
   • Requisito: Il vettore di requisito della query $r_{q,c}$ è derivato da $p(x)$ e dal logit di difficoltà $z_q$.
   • Capacità: Il vettore di capacità del modello $v_{m,c}$ è derivato da $p(x)$ e dal logit di skill del modello $\text{logit}(s_{m,c})$.
   • Residui: Il router calcola residui asimmetrici: sotto-capacità ($u$, modello troppo debole) e sovra-capacità ($o$, modello eccessivo).
   • Scoring: Un punteggio totale $J_m$ viene calcolato come distanza euclidea pesata dei residui più una penalità di costo:
     $$J_m = \sqrt{\sum_c (u_{m,c}^2 + \lambda o_{m,c}^2)} + \beta a_m$$
     Dove $a_m$ è il costo normalizzato, $\lambda$ penalizza la sovra-capacità e $\beta$ controlla il compromesso costo-qualità.
5. Decisione: Viene selezionato il modello con il valore minimo di $J_m$.

2.3 La Manopola di Preferenza ($r$)

Brick introduce una manopola di preferenza continua $r \in [-1, 1]$ che permette agli operatori di scivolare tra un profilo "massima qualità" e uno "massimo risparmio". Questa manopola modula i quattro scalari di routing ($\mu, b, \beta, \lambda$) tramite una legge di potenza calibrata, trasformando il compromesso costo-qualità in un parametro di deploy piuttosto che in una modifica al codice.

3. Contributi Chiave

1. Formulazione MoM: Il documento inquadra il routing di interi modelli attraverso pool eterogenei come il paradigma MoM, dimostrando che recupera il 24% dell'headroom ottenibile tra il miglior singolo modello e un oracle teorico a tre modelli.
2. Rifiuto del Routing Superficiale: Dimostra empiricamente che il routing basato sul dominio e quello basato su lunghezza/parole chiave falliscono nel catturare la difficoltà intra-dominio, performando peggio anche di una semplice baseline "sempre-Kimi".
3. Router Brick: Un router MoM calibrato con una rappresentazione esplicita del vettore di capacità e una manopola di preferenza accessibile all'utente.
4. Efficienza Agentica: Il documento sostiene che il routing a singolo step (come Brick) è strutturalmente superiore al routing a cascata per i carichi di lavoro agentici, poiché evita di accumulare il costo dei rami della cascata respinti ad ogni step di una traiettoria dell'agente.

4. Risultati Sperimentali

Valutato su Dataset A (5.504 query attraverso sei dimensioni di capacità):

• Accuratezza vs. Costo:

  • Profilo Max-Quality ($r=+1$): Brick raggiunge il 76,98% di accuratezza, superando il miglior singolo modello (Kimi 2.6 al 75,02%) e tutti i router esterni (RouteLLM, FrugalGPT, Cascade Routing). Lo fa con un costo inferiore del 28% ($0,022 vs $0,031 per chiamata).
  • Profilo Neutro ($r=0$): Raggiunge il 74,11% di accuratezza con un costo 4,71× inferiore rispetto a sempre-Kimi, con una perdita di accuratezza di soli 0,91 punti percentuali. Supera il Cascade Routing di +0,71 pp a parità di costo.
  • Profilo Low ($r=-0,5$): Raggiunge il 71,62% di accuratezza, superando FrugalGPT (69,42%) di +2,20 pp a parità di costo.
  • Profilo Min-Cost ($r=-1$): Pareggia il modello più economico (Qwen) con il 63,17% di accuratezza, ma con un costo 22,15× inferiore rispetto a sempre-Kimi.

• Latenza:

  • La latenza mediana end-to-end per Brick (profilo max) scende da 51,2s (sempre-Kimi) a 22,8s. Questo perché Brick indirizza circa il 31% delle query al modello più veloce DeepSeek-V4-Flash anche nell'impostazione di massima qualità.

• Limite Oracle:

  • Il tetto teorico (Three-Model Oracle) è 83,25%. Brick cattura una parte significativa del gap tra il miglior singolo modello e questo oracle, sebbene rimanga un 6,27 pp non ancora estratto dal router attuale.

5. Significato e Rivendicazioni

Il documento afferma che Brick dimostra la validità del paradigma MoM come pattern di deployment di prima classe. La sua importanza risiede in:

• Validazione Empirica: Dimostrare che il routing basato su uno spazio di capacità calibrato supera il routing euristico e i baselines a singolo modello.
• Flessibilità Operativa: Fornire una manopola continua per gli operatori per regolare il compromesso costo-qualità senza retraining o modifiche al codice.
• Scalabilità Agentica: Stabilire che il routing puro è l'unico design che scala efficientemente verso i carichi di lavoro agentici, evitando i costi lineari e le penalità di latenza inerenti al routing a cascata.
• Complementarità: Evidenziare come i pool di modelli offrano set di errori complementari (es. gestione dei "rifiuti onesti" vs. allucinazioni), che un router consapevole delle capacità può sfruttare per migliorare l'affidabilità complessiva del sistema.

Gli autori rimangono modesti, riconoscendo che il gap residuo rispetto all'oracle (6,27 pp) rappresenta informazioni che il router attuale non estrae ancora, e che il lavoro futuro dovrebbe concentrarsi sul smoothing bayesiano per pool sparsi e sulla stima della complessità condizionata al dominio.