Ogni pochi mesi, un nuovo modello sale in cima alla classifica. I team si affrettano a integrarlo. I dirigenti inoltrano il comunicato stampa. E il team di engineering si ritrova a spiegare perché cambiare modello in produzione non è come aggiornare un'app sul telefono.

In GRAL, la selezione del modello è trattata come una decisione infrastrutturale — non come un ciclo di hype. Il modello che scegli influenza il tuo budget di latenza, la struttura dei costi, la postura di compliance e la capacità di iterare per anni. Sbagliare è costoso. Fare la scelta giusta richiede ignorare la maggior parte di ciò che l'industria ti dice di considerare.

I Benchmark Misurano le Cose Sbagliate

I benchmark accademici testano i modelli su task che raramente assomigliano ai carichi di lavoro enterprise. Un modello che segna 92% su un benchmark di ragionamento generale potrebbe segnare 60% sul tuo specifico task di classificazione documentale — perché i tuoi documenti hanno gergo di dominio, formattazione inconsistente e casi limite che nessun benchmark copre.

Il problema peggiore è che i benchmark misurano le performance di picco in condizioni ideali. I sistemi enterprise hanno bisogno di performance costanti in condizioni variabili. Un modello che segna 95% in media ma scende al 40% sul 5% degli input è più pericoloso di un modello che segna 85% in modo consistente. Quel 5% di fallimento colpirà le tue transazioni più complesse e di maggior valore — quelle dove l'output del modello conta di più.

GRAL valuta i modelli su dati rappresentativi della produzione prima di qualsiasi decisione di selezione. Non il dataset demo del vendor. Non un test set curato. Dati reali, con tutta la loro complessità.

I Veri Criteri di Selezione

Il framework di selezione modelli di GRAL parte dai vincoli, non dalle capacità. Prima di valutare l'accuratezza di qualsiasi modello, stabiliamo i confini entro cui deve operare:

Budget di latenza. Se il tuo sistema richiede risposte sotto i 200ms — comune nei sistemi decisionali real-time, nell'AI vocale e nell'elaborazione transazioni — quel vincolo elimina la maggior parte dei large language model immediatamente. Nessun livello di accuratezza giustifica un tempo di risposta che rende il sistema inutilizzabile. GRAL definisce i requisiti di latenza al livello P99, non alla media.

Costo per inferenza a scala. Un modello che costa €0,01 per inferenza sembra economico in un pilot. A 10 milioni di inferenze al mese, è una voce di costo di €100.000 mensili. GRAL proietta i costi a scala di produzione dal primo giorno, includendo il costo dell'infrastruttura necessaria per servire il modello — istanze GPU, memoria, rete, ridondanza.

Residenza dei dati. Nelle industrie regolamentate, i dati non possono lasciare determinate giurisdizioni. Questo esclude la maggior parte dei modelli API cloud-hosted a meno che il provider non offra deployment bloccato per regione. GRAL costruisce per deployment on-premise e edge proprio perché la residenza dei dati è non negoziabile per molti casi d'uso enterprise.

Flessibilità di fine-tuning. Un modello che non puoi fine-tunare è un modello che non puoi adattare quando il tuo business cambia. I modelli API proprietari offrono fine-tuning limitato o nullo. I modelli open-source offrono controllo totale. Questo trade-off conta più di quanto la maggior parte dei team realizzi al momento della selezione.

Rischio di vendor lock-in. Se l'intero sistema dipende dall'API di un singolo provider, sei a un cambio di prezzo o a un avviso di deprecazione dalla crisi. GRAL progetta sistemi con layer di astrazione dei modelli — la capacità di sostituire modelli senza riscrivere l'applicazione. Questa non è una preoccupazione teorica. I provider hanno deprecato API, cambiato prezzi di 10x e alterato limiti di rate con settimane di preavviso.

Open-Source vs. Proprietario

Questa non è una questione ideologica. È una decisione ingegneristica con trade-off chiari.

I modelli proprietari (via API) sono la scelta giusta quando:

  • Serve ragionamento generale allo stato dell'arte e il task non richiede fine-tuning specifico di dominio
  • Il volume di inferenze è abbastanza basso da rendere il pricing per-call più economico della propria infrastruttura
  • I dati non sono soggetti a vincoli di residenza o riservatezza che proibiscano l'elaborazione da terzi
  • Il time-to-deployment conta più dell'ottimizzazione dei costi a lungo termine

I modelli open-source (self-hosted) sono la scelta giusta quando:

  • Serve fare fine-tuning su dati proprietari — che è la maggior parte dei casi d'uso enterprise
  • Il volume di inferenze rende il pricing per-call via API insostenibile
  • I dati devono restare nella propria infrastruttura
  • Serve comportamento deterministico e controllo totale sul versioning del modello
  • Si sta costruendo un sistema che deve funzionare per anni senza dipendere dalla roadmap di un vendor

La maggior parte dei sistemi GRAL usa modelli open-source come base, con modelli proprietari come fallback o per subtask specifici dove la qualità di ragionamento generale conta più della specificità di dominio.

Il Problema del Model Zoo

Le aziende che adottano l'AI senza una strategia chiara sui modelli finiscono con uno zoo di modelli: un modello diverso per ogni caso d'uso, ciascuno che richiede la propria infrastruttura, monitoraggio e manutenzione. Un team usa GPT-4 via API. Un altro ha fatto fine-tuning su una variante Llama. Un terzo sta eseguendo un modello BERT custom del 2023. Nessuno sa dirti il costo totale dell'inferenza AI nell'organizzazione.

GRAL evita questo standardizzando su un piccolo numero di famiglie di modelli che coprono le esigenze dell'organizzazione. Un'architettura GRAL tipica usa due o tre livelli:

  • Un modello leggero per task ad alto volume e bassa complessità — classificazione, routing, estrazione. Veloce, economico, gira ovunque.
  • Un modello di medio livello per task che richiedono comprensione di dominio — riassunti, analisi, ragionamento strutturato. Fine-tunato su dati di dominio.
  • Un modello grande (spesso API proprietaria) riservato a task complessi e basso volume dove la qualità giustifica il costo — generazione sfumata, ragionamento multi-step, input ambigui.

Ogni task mappa su un livello. I nuovi casi d'uso si inseriscono nell'architettura esistente piuttosto che generare nuova infrastruttura.

Costo Totale di Possesso su 3-5 Anni

Il costo iniziale del deployment di un modello è una frazione del costo totale di esercizio. Il framework TCO di GRAL tiene conto di:

Costi infrastrutturali. Istanze GPU, storage, rete, ridondanza. Scalano con il volume di inferenze e la dimensione del modello. Un modello che richiede 80GB di VRAM costa fondamentalmente di più da servire di uno che sta in 16GB — anche se entrambi producono output di qualità simile per il tuo task.

Costi di manutenzione. Monitoraggio del modello, pipeline di retraining, etichettatura dati, test di regressione delle performance. GRAL budgetta il 20-30% del costo iniziale di deployment annualmente per la manutenzione — e quella stima si è dimostrata conservativa.

Costi opportunità. Tempo ingegneristico speso a mantenere un modello che avrebbe dovuto essere sostituito. I team che hanno scelto il modello sbagliato all'inizio spesso spendono più tempo a lavorare attorno ai suoi limiti di quanto ne avrebbero speso migrando a una scelta migliore.

Costi di migrazione. Se serve cambiare modello, il costo dipende interamente da quanto l'applicazione è accoppiata al modello specifico. I sistemi progettati con astrazione del modello possono cambiare in giorni. I sistemi costruiti direttamente sull'API di un modello possono richiedere mesi.

Il Framework Decisionale

Il processo di selezione modelli di GRAL segue una sequenza specifica:

Passo 1: Definire i vincoli. Latenza, tetto di costo, residenza dati, requisiti di compliance. Questi sono filtri non negoziabili. Qualsiasi modello che fallisce un vincolo viene eliminato, indipendentemente dalla sua accuratezza.

Passo 2: Valutare su dati di produzione. Non benchmark. Non dataset demo. Dati reali dal sistema target, inclusi casi limite e modalità di fallimento. GRAL esegue valutazioni in cieco — il team che valuta gli output non sa quale modello ha prodotto quale output.

Passo 3: Testare le caratteristiche operative. Come si comporta il modello sotto carico? Cosa succede quando gli input sono malformati? Come cambia la latenza al P99 con l'aumento del throughput? GRAL testa l'envelope operativo, non solo quello dell'accuratezza.

Passo 4: Modellare il costo a scala. Proiettare i volumi di inferenza per 12 mesi. Calcolare i costi infrastrutturali. Includere monitoraggio, manutenzione e retraining.

Passo 5: Valutare la strategia di uscita. Se questo modello deve essere sostituito tra 18 mesi, come appare la migrazione? GRAL progetta per la sostituibilità fin dall'inizio.

Questo processo richiede più tempo che scegliere il modello in cima a una classifica. Produce sistemi che funzionano ancora — e hanno ancora senso economico — anni dopo.

Cosa Significa nella Pratica

Il framework di selezione modelli di GRAL produce spesso risultati controintuitivi. Il modello migliore sulla carta è raramente il modello migliore per il sistema. Un modello più piccolo, più veloce, più economico che soddisfa tutti i vincoli e può essere fine-tunato su dati di dominio supererà un modello più grande e costoso che non è stato progettato per il tuo carico di lavoro specifico.

La disciplina è resistere all'attrazione della capacità in favore della compatibilità. L'AI enterprise non riguarda avere il modello più potente. Riguarda avere il modello giusto — che funziona in modo affidabile, a costi accettabili, entro i vincoli, per anni.

È un pitch meno eccitante di "usiamo l'ultimo modello frontier." È anche l'approccio che mantiene i sistemi in produzione invece che nel purgatorio dei pilot.