Scegliere un modello non è guardare la classifica del momento. È valutarlo sul tuo caso d'uso reale, con i tuoi dati, i tuoi vincoli di privacy e il tuo budget. Ecco il metodo che usiamo quando progettiamo un sistema.
I criteri che contano davvero
I benchmark pubblici danno un'idea, ma non predicono le prestazioni sul tuo task specifico. La scelta è multi-dimensionale.
- Qualità sul TUO task (misurata, non dichiarata)
- Costo per token e volumi previsti
- Latenza accettabile per l'esperienza utente
- Privacy: dove possono andare i dati
- Context window e supporto a tool calling / output strutturato
- Affidabilità del vendor e rischio di lock-in
Valutare con un eval, non a sensazione
Il modo serio per scegliere è costruire un piccolo dataset di casi reali e misurare i modelli candidati con metriche definite. Una giornata di eval evita mesi su un modello sbagliato.
1. raccogli 30–50 casi reali con output atteso2. definisci metriche (accuratezza, formato, costo, latenza)3. esegui gli stessi casi su 2–3 modelli candidati4. confronta i numeri, non le impressioni
Non serve il modello più potente
Spesso un modello medio con buona architettura (RAG, prompt, validazione) batte il modello più grande usato male. E un sistema può usare modelli diversi per task diversi: piccolo ed economico per il volume, potente per i casi difficili.
In sintesi
- Valuta sul tuo caso reale con un eval, non sui benchmark pubblici.
- La scelta è multi-criterio: qualità, costo, latenza, privacy, lock-in.
- Il modello più potente non è sempre quello giusto: conta l'architettura.
- Un sistema può orchestrare più modelli, uno per tipo di task.
FAQ tecniche
Quanto spesso va rivalutata la scelta?
I modelli evolvono in fretta. Conviene ripetere l'eval ogni pochi mesi o quando esce una versione rilevante, mantenendo il dataset di test come metro stabile.
Posso cambiare modello facilmente?
Solo se l'architettura è disaccoppiata dal provider. Un layer di astrazione (o un AI gateway) e prompt versionati per modello rendono la migrazione gestibile.