C’è un certo tipo di riunione che avviene in ogni team che costruisce sopra i frontier LLM. Qualcuno condivide l’ultima classifica dei benchmark. Qualcun altro fa notare che le posizioni si sono rimescolate rispetto al mese scorso. Una terza persona segnala che il modello che il team sta usando è sceso di due posizioni su qualche metrica di cui nessuno aveva sentito parlare tre settimane fa. A fine riunione, nessuno è sicuro se migrare, e la conversazione viene rimessa in agenda per il prossimo trimestre.
Il problema di quella riunione non sono le persone. È che i benchmark misurano compiti sintetici, e il tuo prodotto non è un compito sintetico. La classifica ti dice come un modello si comporta su MMLU, su SWE-bench Verified, su GPQA Diamond — test progettati dai ricercatori per essere misurabili tra modelli. Nessuno di quei test assomiglia ai prompt che la tua applicazione invia davvero in produzione. Nessuno cattura come un modello gestisce il tipo specifico di input disordinato e plasmato dal dominio che i tuoi utenti generano.
Questo articolo illustra esattamente l’esercizio che i benchmark non possono fare. Tre prompt concreti, pensati per essere inviati a GPT-5.5, Claude Sonnet 4.6 e Gemini 3.1 Pro attraverso lo stesso endpoint compatibile con OpenAI, con le stesse impostazioni di temperatura e senza prompt aggiuntivi. I prompt coprono tre categorie che toccano la maggior parte dei carichi di lavoro in produzione: estrazione strutturata da un documento disordinato, un compito di pianificazione a forte componente di ragionamento e generazione di codice sotto vincoli. Le osservazioni di seguito sono i pattern comportamentali che i team che eseguono questo tipo di confronto riportano con coerenza — i pattern che vedresti tu stesso se eseguissi questi prompt nella tua configurazione.
Sulle classifiche, questi tre modelli sono separati da 0,8 punti percentuali su SWE-bench Verified. In pratica, si comportano in modo molto diverso. La scelta tra loro non riguarda chi ottiene il punteggio più alto nei benchmark — riguarda quale pattern comportamentale si adatta al tuo carico di lavoro.
Cosa misurano i benchmark e cosa si perdono
I benchmark esistono perché devono. I provider di modelli hanno bisogno di test standardizzati per fare affermazioni sulle capacità, i ricercatori ne hanno bisogno per pubblicare confronti, e il resto di noi ne ha bisogno per avere un punto di partenza oggettivo nella valutazione dei modelli. Sono utili. Sono anche incompleti in modi che contano per l’uso in produzione.
Vale la pena esplicitare tre limiti specifici, perché ciascuno emerge negli esempi di prompt qui sotto.
- I benchmark misurano capacità isolate, non pattern comportamentali. SWE-bench Verified ti dice se un modello può risolvere un certo tipo di issue su GitHub. Non ti dice se il modello tende a sovra-progettare problemi semplici, se fa domande di chiarimento quando il prompt è ambiguo, o se produce un output che corrisponde alla struttura richiesta al primo tentativo. Queste sono le cose che osserverai ogni giorno in produzione.
- I benchmark vengono “tuned”. Quando un rilascio di modello mette in evidenza il suo punteggio su un particolare benchmark, è un segnale che il modello è stato almeno in parte ottimizzato per quel benchmark. Le prestazioni nel mondo reale e quelle sui benchmark possono divergere — talvolta in modo sostanziale — quando un modello esce dalle condizioni per cui il benchmark è stato progettato.
- I benchmark aggregano. Una differenza di 0,8 punti percentuali nel punteggio di SWE-bench Verified può nascondere il fatto che il Modello A sia molto migliore in una specifica categoria di compiti e peggiore in un’altra, mentre il Modello B sia uniforme su tutta la linea. L’aggregazione comprime informazioni di cui hai bisogno per prendere una decisione.
L’esercizio qui sotto è progettato per far emergere proprio il tipo di informazioni che i benchmark aggregano via. Il punto non è dichiarare un vincitore — è mostrarti le domande che dovresti porti quando esegui lo stesso esercizio sui tuoi prompt.
La configurazione
Tre prompt, scelti perché mappano categorie che toccano la maggior parte dei carichi di lavoro in produzione. La configurazione: ogni prompt inviato a tutti e tre i modelli con parametri identici (temperatura 0,3, nessuna override del system prompt, formato di risposta predefinito), accesso tramite un unico endpoint compatibile con OpenAI così che il confronto resti coerente — niente peculiarità di SDK specifici del provider, nessuna mappatura di parametri diversa, nessun rischio che un modello riceva un trattamento speciale per come è costruita la richiesta.
I prompt sono riportati di seguito, come blocchi di codice che puoi copiare ed eseguire. Le descrizioni comportamentali che seguono ciascuno sono i pattern che i team riferiscono costantemente quando eseguono questo tipo di confronto — pattern documentati in più studi indipendenti nel 2026, e il tipo di cosa che dovresti aspettarti di vedere tu stesso quando esegui questi prompt nella tua configurazione. Eseguirli tu stesso è il punto; l’articolo esiste per darti il framework e i prompt di partenza per farlo.
from openai import OpenAI
import os
client = OpenAI(
api_key=os.environ["COMET_API_KEY"], # or replace with your API key
base_url="https://api.cometapi.com/v1", # one endpoint, multiple models
)
MODELS = [
"gpt-5.5",
"claude-sonnet-4-6",
"gemini-3.1-pro",
]
def run_comparison(prompt: str, temperature: float = 0.3) -> dict[str, str]:
"""
Send the same prompt to all three models and return their responses.
"""
responses = {}
for model in MODELS:
result = client.chat.completions.create(
model=model,
messages=[
{
"role": "user",
"content": prompt,
}
],
temperature=temperature,
)
responses[model] = result.choices[0].message.content
return responses
# Example usage
if __name__ == "__main__":
prompt = "Summarise the key risks in this contract."
outputs = run_comparison(prompt)
for model, response in outputs.items():
print(f"\n--- {model} ---")
print(response)
Prompt 1: Estrazione strutturata da un documento disordinato
Questo è il pane quotidiano di metà delle funzionalità LLM rilasciate nel 2026. Prendere un input non strutturato — un’email, un ticket di supporto, un verbale di riunione, un modulo scannerizzato — ed estrarre campi specifici in un oggetto strutturato. Il prompt qui sotto chiede a ciascun modello di estrarre sette campi da un’email di assistenza clienti deliberatamente disordinata che contiene informazioni parziali, segnali in conflitto e un campo che non è presente nel testo di partenza.
Il prompt
You are processing customer support emails. Extract the followingseven fields from the email below into a JSON object with exactlythese keys: - customer_name (string)- order_id (string)- issue_type (one of: "shipping", "product_quality", "billing", "returns", "other")- urgency (one of: "low", "medium", "high")- requested_action (string)- affected_product (string)- escalation_history (any prior contact about this issue, if mentioned)
Email:---Hi there, I'm writing about order #FT-2289334 from last Tuesday. The Cascadehiking boots I received are NOT the size 11 I ordered — they'reclearly size 10 (I can see the label inside). I have a guided trekbooked in 5 days and I genuinely don't know what to do. I've beena customer for years and this is the first time something likethis has happened. Can you sort this out urgently? I'd prefer a same-day exchange ifat all possible. I'm in Manchester. Margaret W.--- Return only the JSON object. No commentary, no markdown code fences.
Cosa osservare
Tre cose. Primo, se il modello aderisce allo schema JSON richiesto senza invenzioni. Secondo, come gestisce il campo che non esiste nella sorgente (escalation_history — il cliente non menziona alcun contatto precedente su questo problema): ammette l’assenza o inventa in modo plausibile? Terzo, se il modello produce commento aggiuntivo al di fuori del JSON, richiedendo un parsing a valle per rimuovere il “wrapper”. Vale la pena osservare anche il campo urgency: “5 giorni” non è immediato ma il cliente è chiaramente in ansia, il che lascia margine di interpretazione.
Cosa riportano con coerenza i team che lo eseguono
GPT-5.5. Tipicamente produce JSON pulito al primo tentativo. Il rispetto dello schema è elevato; ogni campo richiesto è presente e il formato è analizzabile senza pre-elaborazione. Per i campi mancanti, GPT-5.5 tende a restituire un null esplicito. Di solito non racchiude il JSON in code fence markdown né include spiegazioni in prosa, il che rende banale il parsing a valle. Su scelte interpretative ambigue come la valutazione dell’urgenza qui, GPT-5.5 tende a essere più prudente degli altri due — dove Claude e Gemini potrebbero classificare il ticket come “high” sulla base del tono emotivo del cliente, GPT-5.5 spesso si ancora alla finestra concreta di 5 giorni e indica “medium”.
Claude Sonnet 4.6. Produce anch’esso JSON pulito, ed è in genere il più preciso dei tre nel seguire lo schema richiesto. Dove GPT-5.5 lascia un campo mancante come null, Claude spesso aggiunge campi non richiesti per segnalare problemi di qualità dei dati — una chiave “notes” o “data_quality_notes” non richiesta ma contenente informazioni realmente utili. Questo campo extra è utile per i revisori umani ma causa errori se il parser a valle è rigoroso rispetto allo schema. È un pattern ricorrente con Claude: alta qualità, ma talvolta più scrupoloso di quanto chiesto dal prompt, richiedendo istruzioni esplicite per contenere.
Gemini 3.1 Pro. Tipicamente produce l’output più essenziale dei tre. Ogni campo richiesto, nessun campo extra, nessuna prosa circostante. L’aderenza allo schema è esattamente quella richiesta. Una particolarità utile da conoscere: per i campi mancanti, Gemini tende a restituire una stringa vuota anziché null. I parser JSON rigorosi che distinguono tra i due rileveranno la differenza; quelli permissivi no. Il comportamento è abbastanza coerente tra le esecuzioni da sembrare una preferenza del modello più che un artefatto.
Cosa ti dice questo
Tutti e tre i modelli sanno fare estrazione strutturata. Le differenze stanno nel margine comportamentale attorno allo schema richiesto. Se il tuo sistema a valle è rigoroso sullo schema e considera i campi extra come errori, Gemini 3.1 Pro e GPT-5.5 sono scelte più sicure. Se vuoi che il modello evidenzi problemi di qualità dei dati senza che gli venga chiesto, Claude Sonnet 4.6 è più utile. Nulla di tutto questo emerge in un benchmark.
Prompt 2: Un compito di pianificazione a elevato ragionamento
Questo prompt chiede ai modelli di pianificare un’indagine multi-step: una domanda di ricerca con tre vincoli impliciti che un modello attento dovrebbe identificare prima di sequenziare il lavoro. Il tipo di compito che un’applicazione agentica delega a un LLM come fase di pianificazione prima di invocare strumenti.
Il prompt
I'm trying to answer this research question for my team: "Is our customer churn rate higher among users who haven't usedfeature X in the last 30 days?" Produce a plan for how to investigate this. The plan should:- Identify the steps required- Sequence them with dependencies- Be actionable for a data analyst on my team Return the plan in clear, structured form.
I vincoli impliciti da osservare: la domanda non definisce che cosa significhi “churn” (chiusura account? nessun login? nessun acquisto?), non specifica come controllare le variabili confondenti (gli utenti a basso coinvolgimento abbandonano per molte ragioni non legate alla feature X) e non stabilisce un gruppo di confronto di base. Un planner attento dovrebbe far emergere tutti e tre prima di proporre i passaggi.
Cosa osservare
Se il modello ragiona davvero sul problema o produce una sequenza di passaggi verosimile che però non regge all’esame. Se identifica i vincoli impliciti senza che gli siano stati esplicitati. E se le dipendenze tra passaggi sono corrette — un piano che sembra valido ma ha il passo tre dipendente da un risultato che produrrebbe il passo cinque è inutile in pratica.
Cosa riportano con coerenza i team che lo eseguono
GPT-5.5. Tipicamente produce il piano più utilizzabile operativamente. Il ragionamento tende a essere visibile — GPT-5.5 elenca le sue assunzioni sui vincoli impliciti (definizione di churn, gruppo di controllo, variabili confondenti) prima di delineare i passaggi, il che rende facile individuare dove la sua interpretazione differisce da quella intenduta. Le dipendenze tra i passaggi sono identificate ed etichettate in modo affidabile. L’output spesso include una sezione che segnala quali passaggi possono essere parallelizzati, cosa non richiesta ma che aggiunge valore reale. È il tipo di compito in cui emergono l’uso degli strumenti e l’addestramento “agentico” di GPT-5.5 — il comportamento di pianificazione è plasmato dall’assunzione che seguirà un’esecuzione a valle.
Claude Sonnet 4.6. Tipicamente produce il piano più “pensato”, in senso letterale — il piano di Claude spesso include considerazioni che gli altri due modelli non sollevano. Su una domanda come questa, Claude probabilmente segnalerà la questione metodologica di correlazione vs causalità, noterà che “non aver usato la feature X” potrebbe essere un sintomo di churn più che una causa, e identificherà esplicitamente vincoli non esplicitati ma che un analista attento dovrebbe cogliere. Il rovescio della medaglia: il piano può essere più lungo del necessario e alcuni passaggi talvolta sovra-progettati rispetto alla domanda reale. Il pattern è coerente con il comportamento di Claude altrove — cura a livello esperto, a volte più di quanto richieda il compito.
Gemini 3.1 Pro. Tipicamente produce il piano più chiaramente strutturato, con il grafo delle dipendenze più netto. La qualità del ragionamento è alta — Gemini identifica in modo affidabile i vincoli impliciti, scompone il problema in una sequenza difendibile e produce istruzioni passo-passo effettivamente eseguibili. Lo svantaggio: il piano può risultare un po’ meccanico. Fa il lavoro ma tende a non far emergere le sottigliezze metodologiche che solleva Claude, né gli insight di parallelizzazione che include GPT-5.5. Questo rispecchia il pattern più ampio di Gemini — forte sul ragionamento, più “scolastico” sulle scelte discrezionali circostanti.
Cosa ti dice questo
La qualità del ragionamento su questo compito è elevata in tutti e tre i modelli. Le differenze stanno nel comportamento circostante — ciò che il modello aggiunge oltre alla richiesta letterale. GPT-5.5 aggiunge pragmatismo operativo (parallelizzazione, suggerimenti di esecuzione). Claude aggiunge cura a livello esperto (metodologia, edge case, finezze statistiche). Gemini aggiunge chiarezza ed economia. Nessuna di queste è una scelta sbagliata. Quale si adatta alla tua applicazione dipende da cosa vuoi che il modello faccia una volta terminato il compito richiesto.
Prompt 3: Generazione di codice con vincoli specifici
Questo prompt chiede ai modelli di implementare una funzione piccola ma non banale: una funzione Python che prende una lista di eventi con timestamp e restituisce il gap più lungo tra eventi consecutivi, gestendo quattro casi limite. I vincoli sono espliciti; l’intento è testare la generazione di codice sotto vincoli piuttosto che il soffitto di capacità — ogni modello può scrivere questa funzione. Ciò che varia è come gestiscono i vincoli.
Il prompt
Write a Python function that takes a list of timestamped events andreturns the longest gap (in seconds) between consecutive events. Requirements:- Function signature: longest_gap(events: list[datetime]) -> float- Handle these edge cases: 1. Empty list (return 0.0 or raise — your choice, but be consistent) 2. Single event 3. Duplicate timestamps 4. Unsorted input- Use only the standard library- Include type hints- Return just the function. No tests or usage examples.
Cosa osservare
Se il modello affronta tutti e quattro i casi limite o ne tralascia alcuni in silenzio. Se le annotazioni di tipo sono accurate o di facciata. Se l’implementazione sceglie un algoritmo difendibile (ordinare poi scansionare) o qualcosa di esotico. E se il modello rispetta il vincolo “niente test, niente esempi d’uso” alla fine del prompt — è il tipo di istruzione tardiva che i modelli con forte aderenza alle istruzioni onorano e quelli più deboli violano silenziosamente.
Cosa riportano con coerenza i team che lo eseguono
GPT-5.5. Tipicamente produce il codice più accuratamente ingegnerizzato. Tutti e quattro i casi limite gestiti con rami espliciti, annotazioni di tipo precise (spesso includendo Optional o Union per i valori di ritorno nei casi limite) e una docstring con chiamate di esempio. L’implementazione sceglie di solito l’algoritmo ovvio — ordinare, scansionare, tracciare il gap massimo — ed è corretta. Da sapere: GPT-5.5 include spesso test unitari o esempi d’uso anche quando il prompt chiede esplicitamente solo la funzione. Questo è il trade-off con modelli pragmatici operativamente — aggiungono ciò che pensano ti servirà, anche quando chiedi di non farlo.
Claude Sonnet 4.6. Tipicamente produce il codice più leggibile. La funzione è concisa, i casi limite gestiti con un pulito pattern di guard clause all’inizio, annotazioni di tipo accurate e minimali. Claude spesso aggiunge un commento ponderato che spiega una scelta discrezionale lasciata aperta dal prompt — ad esempio, sui timestamp duplicati, trattandoli come gap di lunghezza zero e spiegandone il perché, una scelta difendibile che il prompt non specificava. Claude tende a rispettare il vincolo “niente test” più affidabilmente di GPT-5.5. La funzione in sé è la più manutenibile delle tre. Coerente con la reputazione di Claude per la qualità del codice: pulito, idiomatico, da esperto.
Gemini 3.1 Pro. Tipicamente produce il codice più essenziale dei tre. La funzione è corretta, i casi limite gestiti, l’implementazione è la più breve. Docstring solitamente di una riga. Annotazioni di tipo presenti e accurate. La soluzione di Gemini raramente include test o commenti estesi e non sovra-progetta — esattamente ciò che il prompt chiedeva. Per uno sviluppatore che vuole una funzione funzionante e intende aggiungere i test separatamente, è la via più diretta. Per chi vuole che il modello faccia anche il lavoro circostante, gli altri due aggiungono di più (che tu lo chieda o meno).
Cosa ti dice questo
Tutti e tre i modelli sanno scrivere la funzione. La differenza comportamentale è in quanto lavoro circostante ciascun modello fa oltre alla richiesta letterale — e in quanto bene ciascuno rispetta istruzioni esplicite del tipo “non aggiungere X”. GPT-5.5 tende alla completezza, anche quando la completezza era stata esplicitamente limitata nel prompt. Claude tende alla cura artigianale (codice leggibile, commenti ponderati sulle scelte). Gemini tende all’economia (fare esattamente ciò che è stato chiesto, niente di più). Per workflow agentici in cui l’output del modello entra direttamente in una codebase di produzione, il comportamento desiderato dipende da cosa si aspetta il processo di revisione a valle — e da quanto rigidamente hai bisogno che le istruzioni negative vengano seguite.
I pattern che emergono
Attraverso i tre prompt di cui sopra, emergono tre pattern comportamentali coerenti dagli studi comparativi e dai report degli sviluppatori pubblicati nel 2026. Non sono affermazioni di capacità — ogni modello gestisce ogni compito a un livello elevato. Sono tendenze, il tipo di cosa che vedi solo quando i team osservano lo stesso modello su dozzine di prompt. Esegui i prompt sopra nella tua configurazione e vedrai gli stessi pattern; l’articolo esiste per darti il framework per riconoscere ciò che stai osservando mentre lo fai.
| Model | Tendenza comportamentale | Si adatta meglio quando… |
|---|---|---|
| GPT-5.5 | Pragmatico dal punto di vista operativo. Aggiunge suggerimenti di esecuzione, codice difensivo e output favorevole all’automazione a valle. Forte su compiti plasmati da uso di strumenti e approcci agentici. | La tua applicazione incatena l’output del modello in un’esecuzione successiva — agenti, workflow o pipeline in cui il passo successivo è automatizzato. |
| Claude Sonnet 4.6 | Cura a livello esperto. Fa emergere considerazioni oltre la richiesta letterale, solleva temi etici e metodologici, produce codice altamente leggibile. | La tua applicazione prevede una revisione umana dell’output del modello — generazione di contenuti, code review, analisi in cui la “cura del mestiere” conta. |
| Gemini 3.1 Pro | Economico e diretto. Fa esattamente ciò che è stato chiesto, niente di più. Aderenza allo schema più pulita e minor output in token a parità di lavoro. | La tua applicazione ha requisiti di output rigorosi, la prevedibilità dei costi è prioritaria, o vuoi che il modello sia uno strumento preciso più che un collaboratore riflessivo. |
Un’importante avvertenza. Questi pattern sono tendenze, non regole. Ciascun modello può essere guidato verso uno qualsiasi di questi comportamenti con un prompt appropriato — un system prompt sufficientemente dettagliato farà aggiungere test a Gemini, o limiterà Claude all’output minimo indispensabile, o farà sì che GPT-5.5 eviti i test unitari. Il punto è cosa fa ciascun modello per impostazione predefinita, prima che tu inizi a guidarlo. Il comportamento predefinito è ciò con cui convivi in produzione a meno che tu non spinga attivamente in direzione opposta via prompt.
Come testare sul tuo carico di lavoro
L’esercizio sopra è replicabile su qualsiasi carico di lavoro, e dovrebbe esserlo. I punteggi dei benchmark sono utili come primo filtro, ma i pattern comportamentali che contano per la tua applicazione specifica sono visibili solo quando osservi i modelli gestire i tuoi prompt specifici.
Una guida pratica per eseguire l’esercizio sul tuo traffico:
- Scegli tre categorie di prompt rappresentative. Non tre prompt a caso — tre categorie che coprono il tuo carico. La maggior parte dei sistemi in produzione può essere scomposta in poche tipologie di prompt (estrazione, classificazione, generazione, ragionamento, codice, sintesi). Scegli le categorie che contano per la maggior parte del tuo traffico.
- Cura 20–30 esempi per categoria. Idealmente dal traffico reale. Anonimizza dove necessario. Il punto è che i prompt dovrebbero assomigliare a ciò che la tua applicazione vede davvero, non a domande da benchmark. Venti esempi per categoria bastano per vedere i pattern; trenta bastano per esserne sicuri.
- Eseguili attraverso un unico endpoint, tutti i modelli. Un endpoint aggregatore compatibile con OpenAI rende tutto molto più rapido rispetto a usare l’SDK di ciascun modello. Il codice all’inizio di questo articolo è l’intera configurazione. La stessa temperatura, gli stessi parametri, lo stesso prompt — le differenze nell’output sono le differenze tra modelli.
- Valuta qualitativamente prima di quantitativamente. Dai un’occhiata agli output. I pattern comportamentali sono di solito evidenti entro la prima dozzina di prompt. Una volta che hai un’ipotesi su come ciascun modello si comporta sul tuo carico, allora puoi costruire una griglia di valutazione — ma l’ipotesi nasce dall’osservazione, non da un template di grading preconfezionato.
- Fai attenzione a ciò che il modello aggiunge. La domanda da benchmark è se il modello dà la risposta giusta. La domanda comportamentale è cos’altro fa. Aggiunge test? Spiega il ragionamento? Solleva preoccupazioni? Produce campi extra che non hai richiesto? È qui che vivono le differenze tra modelli.
- Scegli il modello che si adatta al tuo pattern a valle. Se il tuo processo a valle è automatizzato, vuoi un modello il cui comportamento predefinito produca output puliti e analizzabili. Se il tuo processo a valle è una revisione umana, vuoi un modello il cui comportamento predefinito aggiunga il tipo di giudizio circostante che un revisore umano vorrebbe vedere. La risposta giusta dipende da ciò che viene dopo il modello.
Conclusione
La scelta tra GPT-5.5, Claude Sonnet 4.6 e Gemini 3.1 Pro non riguarda quale modello sia “migliore”. Riguarda quale modello si adatta alla forma del tuo carico di lavoro — e quella forma è qualcosa che i benchmark non possono vedere. L’esercizio sopra è replicabile in un pomeriggio se hai i prompt curati; il valore di farlo è che smetti di indovinare e inizi a osservare.
Per i team che eseguono l’esercizio in autonomia: l’impostazione più semplice è un singolo endpoint compatibile con OpenAI che espone tutti e tre i modelli dietro una sola credenziale. CometAPI è una via: punti il tuo SDK OpenAI esistente a una base URL diversa e il parametro del modello diventa la variabile.
I benchmark ti dicono cosa un modello può fare. I pattern comportamentali ti dicono cosa un modello farà, per impostazione predefinita, sui tuoi prompt. La prima risposta è pubblicata. La seconda devi osservarla tu. Venti prompt per categoria, un pomeriggio, e avrai una risposta che nessuna classifica produrrà mai.
Pronto a integrare con affidabilità? Vai su CometAPI e sulla documentazione API per un accesso senza attriti a Claude Fable 5 insieme ad altri modelli all’avanguardia, fatturazione unificata e affidabilità di livello enterprise. Iscriviti oggi e inizia con crediti generosi per i nuovi utenti — il tuo prossimo progetto rivoluzionario ti aspetta.