Riepilogo Tecnico: Routing di LLM Multi-Tier con Classifier-Gated per Settori Regolamentati

Problematica

L'implementazione di Large Language Models (LLM) in settori regolamentati (ad es. servizi finanziari, sanità) affronta un compromesso critico tra capacità, efficienza dei costi e conformità normativa. Le attuali architetture di serving non riescono ad affrontare simultaneamente tre vincoli specifici:

1. Residenza dei Dati e Conformità: Le normative come il GDPR, SEBI, RBI e la DPDPA indiana impongono che le informazioni identificabili (PII - Personally Identifiable Information) non attraversino i confini giurisdizionali. Le implementazioni a modello singolo non possono imporre ciò perché i dati entrano nell'endpoint del modello prima di qualsiasi decisione di routing.
2. Inefficienza del Serving a Modello Singolo: Il routing di tutte le query verso un unico modello di grandi dimensioni consuma l'intera capacità della GPU indipendentemente dalla complessità della query. Ciò crea contesa infrastrutturale e ignora la realtà per cui la maggior parte delle query nei settori regolamentati sono semplici ricerche che richiedono solo modelli piccoli.
3. Limitazioni degli Approcci di Routing Esistenti:
   • Mixture-of-Experts (MoE): Sebbene il MoE instradi i token tra gli esperti nelle fasi successive, tutti gli esperti rimangono caricati in memoria e il routing avviene dopo che i dati sono arrivati all'endpoint. Questo impedisce l'applicazione geografica della residenza dei dati.
   • Metodi di Routing Precedenti (FrugalGPT, RouteLLM, Hybrid LLM): Questi approcci si concentrano su costo o qualità ma mancano di un rilevamento integrato delle PII e del routing geografico. Non impongono la conformità per progettazione, permettendo spesso ai dati sensibili di attraversare infrastrutture cross-region prima di una decisione viene presa.

Metodologia

Il documento propone ComplianceGate, un'architettura di routing con classifier-gate che impone la conformità e ottimizza i costi al livello pre-inferenza. Il sistema opera all'interno di una rete privata e consiste in due componenti primari:

1. Encoder Classifier

Un encoder transformer bidirezionale (12 layer, 768 dimensioni nascoste, ~134M di parametri) si posiziona prima dell'inferenza del decoder.

• Addestramento: Pre-addestrato su 2 miliardi di token di testo inglese e perfezionato (fine-tuned) su 50.000 esempi specifici del dominio.
• Funzione: Valuta il testo grezzo della query per complessità (semplice, media, complessa) e sensibilità (presenza di PII rispetto a dati non sensibili).
• Output: Una distribuzione di probabilità su sei etichette (il prodotto cartesiano di 3 livelli di complessità e 2 dimensioni di sensibilità) con un punteggio di confidenza.
• Prestazioni: Il tempo di inferenza è inferiore a 10ms (specificamente 7ms negli esperimenti).

2. Logica di Routing e Fallback

Lo strato di routing interpreta l'output del classifier per prendere una decisione deterministica prima che inizi qualsiasi computazione LLM:

• Imposizione Geografica: Le query contenenti PII vengono instradate verso endpoint locali (all'interno della giurisdizione). Le query non sensibili vengono instradate verso infrastrutture cross-region.
• Selezione del Tier del Modello:
  • Query semplici $\rightarrow$ Modelli densi piccoli e veloci (es. Nova Lite, Gemma 4B).
  • Query medie $\rightarrow$ Modelli di medie dimensioni (es. Gemma 27B, Ministral 14B).
  • Query complesse $\rightarrow$ Modelli grandi e capaci (es. Qwen3-480B).
• Fallback Basato sulla Confidenza: Se la confidenza del classifier scende sotto una soglia configurabile (default 80%), il sistema decade sull'etichetta più restrittiva (complex_pii). Ciò garantisce che, in caso di incertezza, le query vengano instradate verso modelli locali a piena capacità, prevenendo strutturalmente violazioni della residenza dei dati.

3. Architettura di Deployment

Il sistema è containerizzato e distribuito tramite infrastruttura come codice (IaC). Ogni tier di modello opera su infrastrutture indipendenti senza memoria condivisa o domini di guasto, consentendo una scalabilità e aggiornamenti indipendenti senza influenzare gli altri tier.

Contributi Chiave

1. Conformità-by-Design: L'architettura rende strutturalmente impossibile la violazione della residenza dei dati rilevando le PII e instradandole verso endpoint locali prima che avvenga qualsiasi computazione LLM.
2. Ottimizzazione dei Costi Multi-Tier: A differenza del routing binario o del MoE, questo sistema supporta molteplici tier di modelli. Instrada le query semplici a modelli che costano 6–8× meno rispetto ai modelli frontier, riducendo significativamente i costi di serving in proporzione alla complessità effettiva del traffico.
3. Prestazioni e Resilienza: Evitando l'overhead del processamento di richieste semplici attraverso modelli massicci, il sistema riduce la latenza e aumenta il throughput. I tier indipendenti assicurano che i guasti in un modello non si propaghino all'intero sistema.
4. Modello di Costo Formale: Il documento deriva un modello matematico per il risparmio frazionario ($S$), dimostrando che i risparmi sono massimizzati quando le distribuzioni delle query sono sbilanciate verso richieste semplici (tipico nei servizi finanziari).

Risultati Sperimentali

Il sistema è stato valutato su 600 query utilizzando Amazon Bedrock (us-east-2) rispetto a un baseline di Qwen3-480B-A35B (MoE) utilizzando la configurazione di routing con gate.

• Accuratezza: L'encoder classifier ha raggiunto un'accuratezza del 99,2% con un richiamo (recall) quasi perfetto per le PII.
• Riduzione della Latenza:
  • Query Semplici: 2–4× più veloci (490–840ms rispetto a ~1850ms del baseline).
  • Query Medie: 1,7–3,3× più veloci (1140–2250ms rispetto a ~3750ms del baseline).
  • Query Complesse: Nessuna differenza (stesso modello utilizzato).
  • Latenza Mediana: Riduzione del 39% complessiva.
• Throughput: Il routing con gate ha raggiunto 122–200 token/secondo per le query semplici/medie, rispetto ai 50–64 token/secondo del baseline MoE.
• Prevedibilità (Varianza):
  • Il baseline MoE ha mostrato un'alta varianza della latenza (rapporto Max/Min fino a 34,5×).
  • Il routing con gate ha ridotto la varianza a 1,1–2,0×, rendendo fattibili le garanzie SLA.
• Risparmio sui Costi:
  • Risparmio del 33% con una distribuzione di query uguale (33% semplice/media/complessa).
  • Risparmio del 52% con una distribuzione sbilanciata tipica dei servizi finanziari (60% semplice, 25% media, 15% complessa).
  • Risparmio del 74% proiettato in distribuzioni altamente sbilanciate (70% semplice).

Significato e Rivendicazioni

Il documento afferma che ComplianceGate fornisce un'alternativa pronta per la produzione rispetto ai deployment a modello singolo e MoE per i settori regolamentati. La sua importanza risiede nel passaggio da un'applicazione post-hoc delle policy a un'applicazione strutturale pre-inferenza.

• Vantaggio Strutturale: A differenza del MoE, che non può imporre il routing geografico una volta che i dati sono entrati nel modello, questa architettura impone i confini giurisdizionali al livello di routing.
• Scalabilità: Permette di scalare indipendentemente i tier dei modelli, mentre il MoE richiede la scalabilità dell'intero cluster.
• Praticità: Con un overhead di routing trascurabile (<0,1% del costo totale) e un'alta accuratezza di classificazione, il sistema dimostra che un encoder addestrato può soddisfare simultaneamente rigidi mandati di conformità (residenza dei dati) e obiettivi aggressivi di efficienza dei costi senza sacrificare la qualità della risposta per le query complesse.

Gli autori concludono che il valore di questo lavoro non risiede nei modelli specifici scelti, ma nel framework di routing che consente di abbinare il modello giusto alla query giusta in base a complessità e sensibilità misurabili per query, per giurisdizione e per vincolo.