GPT-5.5: capacità, prezzi e benchmark da valutare prima dell’adozione

GPT-5.5 è un modello frontier per lavoro professionale e coding complesso. Un rilascio di questa fascia non rende però conveniente sostituire automaticamente i modelli già in produzione: capacità, prezzo, latenza e strumenti devono migliorare un indicatore operativo verificabile.

La valutazione corretta parte dai propri task, confronta configurazioni equivalenti e introduce il nuovo modello con un pilota controllato.

Che cos’è GPT-5.5

La documentazione ufficiale OpenAI di GPT-5.5 lo descrive come un modello per lavoro professionale e coding complesso. Supporta differenti livelli di ragionamento, input testuale e immagini, strumenti, funzioni e output strutturati.

Il contesto ampio e la capacità di usare tool permettono flussi lunghi, ma aumentano la necessità di progettare il sistema: un contesto disponibile non deve essere riempito senza criterio.

Le quattro lenti di valutazione

1. Qualità

Misurare correttezza, completezza, aderenza alle istruzioni, uso delle fonti e capacità di recuperare dagli errori.

2. Costo

Includere token, tool, tentativi, cache, verifiche e revisione umana. Il prezzo per token è soltanto una componente.

3. Latenza

Valutare tempo al primo token, durata totale e percentili alti. Il comportamento medio nasconde i casi lenti che influenzano l’esperienza.

4. Strumenti

Verificare scelta del tool, argomenti, sequenza, permessi, errori e capacità di fermarsi.

Prezzo e costo totale

La documentazione ufficiale indica per GPT-5.5 prezzi distinti per token di input, input in cache e output. Prompt molto lunghi possono avere regole di prezzo specifiche.

Per stimare un flusso reale bisogna calcolare:

• token medi e percentile alto;
• ragionamento e output prodotti;
• quota di input riutilizzabile in cache;
• chiamate a strumenti;
• numero medio di iterazioni;
• fallimenti e fallback;
• tempo di revisione;
• volume mensile previsto.

Il costo per task riuscito resta più utile del costo della singola chiamata.

Come leggere i benchmark

Un benchmark misura un comportamento in condizioni definite. Prima di usare un punteggio bisogna chiedere:

• quale dataset viene usato;
• se il modello accede a strumenti;
• quale livello di ragionamento è configurato;
• quanti tentativi sono consentiti;
• chi valuta le risposte;
• quale costo e latenza accompagnano il risultato;
• quanto il test somiglia al proprio caso.

La guida sui benchmark AI approfondisce contaminazione, riproducibilità e test interni.

Costruire una eval interna

Il set dovrebbe includere 50–200 esempi per un primo confronto, secondo variabilità e rischio. Ogni esempio contiene input, contesto, output atteso o criteri e livello di gravità dell’errore.

Dimensioni utili:

• precisione fattuale;
• copertura dei requisiti;
• formato e struttura;
• citazioni e fonti;
• uso degli strumenti;
• sicurezza e privacy;
• tono e lingua;
• costo e latenza.

Le valutazioni automatiche vanno calibrate con esempi umani, soprattutto per qualità e stile.

Confrontare configurazioni equivalenti

Per evitare conclusioni errate, mantenere uguali:

• input e contesto;
• strumenti disponibili;
• limiti di token;
• numero di tentativi;
• criteri di successo;
• timeout e condizioni di rete.

Il livello di ragionamento può essere testato su più valori. Un modello migliore con un’impostazione più bassa potrebbe offrire il miglior equilibrio.

Dove GPT-5.5 può creare valore

• analisi di documenti numerosi e collegati;
• coding agentico su repository complessi;
• ricerca professionale con fonti;
• workflow con più strumenti;
• pianificazione e revisione di attività lunghe;
• problemi con ambiguità e vincoli multipli;
• produzione di deliverable strutturati;
• valutazione di alternative tecniche.

Compiti semplici e ad alto volume possono restare su modelli più efficienti. L’articolo su GPT-5.4 mini mostra come misurare il routing per costo e successo.

Routing anziché sostituzione totale

Un’architettura a più modelli può usare:

• modello piccolo per classificazione ed estrazione;
• modello intermedio per attività standard;
• GPT-5.5 per casi complessi o fallimenti;
• revisione umana per decisioni ad alto impatto.

Il router deve basarsi su segnali verificabili: categoria, rischio, strumenti, fallimento dello schema o superamento della soglia.

Piano pilota in tre fasi

Fase 1: offline

Eseguire eval su casi storici senza influenzare utenti o sistemi. Confrontare qualità, costo e latenza.

Fase 2: shadow

Il nuovo modello elabora richieste reali in parallelo, ma la risposta non viene usata. Questo misura distribuzione e carico.

Fase 3: traffico limitato

Assegnare una piccola quota di utenti o task, con monitoraggio, approvazione e possibilità di rollback.

Ogni fase deve avere criteri di avanzamento e di stop.

Prompt e context engineering

Un nuovo modello non richiede necessariamente prompt più lunghi. Conviene eliminare istruzioni nate per limiti precedenti, chiarire criteri e separare dati da comandi.

Il context engineering organizza memoria, documenti e strumenti in base alla fase del lavoro. Il contesto deve essere pertinente, aggiornato e tracciabile.

Strumenti e autonomia

GPT-5.5 può interagire con strumenti, ma la disponibilità tecnica non implica autorizzazione illimitata. Per ogni tool definire:

• azioni consentite;
• dati accessibili;
• limiti di frequenza e spesa;
• operazioni che richiedono conferma;
• validazione di input e output;
• log e responsabile;
• rollback o compensazione.

Un errore di testo è diverso da un’azione eseguita su un sistema esterno.

Sicurezza e test avversari

Ripetere test su prompt injection, dati sensibili, contenuti non affidabili, escalation dei permessi e uso improprio degli strumenti.

La guida sulla prompt injection spiega perché documenti e pagine devono essere trattati come dati potenzialmente ostili.

Monitoraggio dopo il rilascio

• tasso di task accettati;
• errori per categoria e gravità;
• latenza media e percentile alto;
• token, strumenti e costo;
• fallback e interventi umani;
• rifiuti e blocchi inattesi;
• drift dopo aggiornamenti;
• feedback degli utenti;
• incidenti e quasi-incidenti.

Alias e snapshot devono essere registrati per capire quale versione ha prodotto un risultato.

Quando non migrare

È ragionevole mantenere il sistema attuale se:

• la qualità è già sufficiente;
• il nuovo modello non migliora KPI importanti;
• costo o latenza superano i benefici;
• strumenti necessari non sono compatibili;
• il team non può completare test e monitoraggio;
• la migrazione crea rischio senza un caso d’uso.

Non migrare subito non significa ignorare il rilascio. Significa programmare una valutazione proporzionata.

Errori frequenti

• Decidere da un benchmark generale;
• confrontare livelli di ragionamento diversi;
• ignorare strumenti e tentativi;
• migrare tutto in un’unica volta;
• copiare prompt senza revisione;
• non preparare rollback;
• usare il massimo contesto senza necessità;
• misurare soltanto qualità o soltanto costo.

Domande frequenti

GPT-5.5 è sempre migliore di un modello piccolo?

Può essere più capace, ma il modello migliore dipende da task, volume, latenza, costo e rischio.

Quale livello di ragionamento usare?

Partire da un livello proporzionato e confrontare almeno una configurazione più bassa e una più alta sulle eval reali.

Serve migrare tutti i workflow?

No. Routing e selezione per caso d’uso possono offrire un equilibrio migliore.

Come decidere se il pilota è riuscito?

Con soglie definite prima su qualità, costo, latenza, sicurezza e lavoro umano richiesto.

Adottare solo quando migliora il sistema

GPT-5.5 amplia le possibilità per lavoro professionale e coding complesso, ma il rilascio non è una prova di valore per ogni applicazione. Eval rappresentative, costo per task riuscito, pilota graduale e rollback permettono di adottarlo quando migliora davvero un processo.