Scegliere il modello giusto per il lavoro (e per il budget)

Un modello mentale utile: prima il tipo di compito, poi il modello

In pratica, classifico i carichi di lavoro degli LLM lungo cinque assi prima ancora di guardare i nomi dei modelli:

La scelta del modello diventa molto più semplice quando smetti di chiederti “quale modello è il più intelligente?” e inizi a chiederti “quale modalità di errore sto mitigando con questa spesa?”.

Per esempio:

• Un sistema che riepiloga le richieste di reimpostazione della password ha bisogno di coerenza e costi contenuti.
• Un assistente per la migrazione del codice ha bisogno di ragionamento e uso degli strumenti.
• Uno strumento per confrontare contratti ha bisogno di un contesto lungo, ma anche di un’attenta attribuzione delle fonti.
• Un agente rivolto ai clienti ha bisogno di una latenza prevedibile più che di prestazioni di punta nei benchmark.
• Una pipeline di arricchimento batch può dare più importanza al volume elaborato per dollaro che all’eleganza della risposta.

Spesso il modello sbagliato non è sbagliato dal punto di vista tecnico. Lo è dal punto di vista economico.

Una scala pratica dei modelli

Ecco la scala che uso per la maggior parte dei sistemi in produzione.

Modelli di classe Haiku: la scelta predefinita per attività linguistiche rapide ed economiche

I modelli di classe Haiku sono eccellenti per una prima elaborazione. Li uso per attività in cui la risposta è breve, l’input è pulito e il formato dell’output è vincolato.

Impieghi adatti:

• Etichettatura dei ticket
• Riepiloghi brevi
• Classificazione del sentiment
• Normalizzazione dell’oggetto delle email
• Individuazione della FAQ corrispondente
• Estrazione semplice di JSON
• Prefiltri di moderazione a basso rischio

Esempio di prompt per un classificatore economico di primo livello:

{
  "model": "claude-haiku-4.5",
  "temperature": 0,
  "max_tokens": 120,
  "response_format": { "type": "json" },
  "messages": [
    {
      "role": "system",
      "content": "Classify the support ticket. Return only valid JSON."
    },
    {
      "role": "user",
      "content": "Subject: Refund not received\nBody: I canceled two weeks ago and still see a charge."
    }
  ]
}

Output previsto:

{
  "category": "billing",
  "urgency": "medium",
  "needs_human": true,
  "reason": "Refund dispute involving payment status"
}

Un errore comune: i team chiedono ai modelli economici di ragionare e formattare perfettamente in un unico passaggio. Se il modello a volte produce JSON non valido, non passare subito a Opus. Prima definisci meglio il compito:

• Imposta temperature: 0
• Usa uno schema JSON o una chiamata a uno strumento
• Riduci l'ampiezza delle istruzioni
• Separa la classificazione dalla spiegazione
• Valida l'output e riprova una volta

Per molti compiti in produzione, un nuovo tentativo con un modello della classe Haiku resta più economico e veloce rispetto all'uso predefinito di un modello di ragionamento di frontiera.

Modelli della classe Sonnet: il pilastro della logica di prodotto concreta

I modelli della classe Sonnet sono quelli che scelgo di solito per le funzionalità interattive dei prodotti. Sono abbastanza capaci nel ragionamento, abbastanza stabili nell'uso degli strumenti e di solito abbastanza veloci per i flussi rivolti agli utenti.

Impieghi adatti:

• Stesura di risposte per l'assistenza clienti
• Flussi di lavoro agentici con strumenti
• Spiegazione del codice e refactoring leggero
• Domande e risposte sui documenti in più passaggi
• Flussi di lavoro con copiloti per le vendite o il customer success
• Estrazione strutturata da input disordinati

In pratica, Sonnet è spesso la scelta migliore quando non vuoi dover riflettere troppo sull'instradamento. Se puoi integrare una sola fascia di modelli in una nuova funzionalità, parti da qui.

Esempio: un agente di assistenza che può esaminare un ordine, una policy e i ticket precedenti.

SYSTEM = """
You are a support resolution assistant.
Use tools before making claims about orders, refunds, or account state.
If policy is ambiguous, say what is ambiguous and escalate.
Return:
- summary
- recommended_action
- customer_reply
- escalate: true/false
"""

request = {
    "model": "claude-sonnet-4.6",
    "temperature": 0.2,
    "max_tokens": 900,
    "tools": [
        {"name": "get_order", "description": "Fetch order state"},
        {"name": "get_refund_policy", "description": "Fetch current refund rules"},
        {"name": "search_prior_tickets", "description": "Search customer history"}
    ],
    "messages": [
        {"role": "system", "content": SYSTEM},
        {"role": "user", "content": "Customer says they returned item A but were charged again."}
    ]
}

Ecco cosa succede davvero quando esegui questo tipo di flusso di lavoro in produzione: la maggior parte degli errori non dipende dal fatto che «il modello è stupido». Sono errori di integrazione.

• Lo strumento restituisce uno stato non aggiornato.
• Il modello riceve troppo contesto irrilevante.
• Il documento della policy contiene testo contraddittorio.
• L'agente può proseguire dopo una chiamata a uno strumento fallita.
• Il prompt richiede sia un'analisi interna sia un testo pronto per il cliente, senza separarli.

Un modello della classe Sonnet offre capacità sufficienti per gestire un certo grado di disordine, ma non elimina la necessità di contratti ben definiti per gli strumenti.

Modelli della classe Opus: costosi, ma a volte meno degli errori

I modelli della classe Opus sono adatti ai compiti in cui il costo di una risposta sbagliata supera di gran lunga il costo dell'inferenza.

Scelgo Opus quando:

• L'input è ambiguo e la posta in gioco è alta
• Ci sono molti vincoli che interagiscono tra loro
• L'utente si aspetta un ragionamento approfondito
• Il compito comporta compromessi relativi a codice, policy o architettura
• Un tentativo economico fallito farebbe perdere tempo alle persone

Esempi:

• Revisione di un piano di migrazione di un database
• Analisi della cronologia di un incidente in produzione
• Generazione di un confronto complesso tra policy legali da sottoporre a revisione umana
• Debug di un malfunzionamento di un agente che coinvolge più servizi
• Valutazione della sicurezza di un'azione automatizzata

Non uso Opus per ogni compito «importante». Importanza e difficoltà sono cose diverse. Un milione di ticket per il ripristino della password sono importanti per gli utenti, ma non sono difficili presi singolarmente. Una singola migrazione con una delicata operazione di eliminazione dei dati può essere sia importante sia difficile.

Un approccio utile è «passare a un modello superiore in caso di incertezza»:

def choose_model(task):
    if task["context_tokens"] > 700_000:
        return "fable-5"

    if task["risk"] == "high" and task["requires_reasoning"]:
        return "claude-opus-4.8"

    if task["requires_tools"] or task["multi_step"]:
        return "claude-sonnet-4.6"

    return "claude-haiku-4.5"

È volutamente semplice. Il router dovrebbe essere abbastanza ordinario da permettere al tuo team di eseguirne il debug alle 2 del mattino.

Fable 5 e il contesto da 1M: usalo quando il problema è il recupero delle informazioni

I modelli con contesto lungo sono allettanti perché eliminano gran parte del lavoro di ingegnerizzazione del recupero delle informazioni. La finestra di contesto da 1M di Fable 5 cambia ciò che puoi tentare direttamente: revisione di documenti interi, sintesi di trascrizioni enormi, ispezione di repository di grandi dimensioni e analisi di policy distribuite su più file.

Ma un contesto lungo non fa miracoli.

Una finestra da 1M token aiuta quando la difficoltà è che «il fatto rilevante potrebbe trovarsi ovunque». Non garantisce che il modello ragioni perfettamente su tutti i milioni di token e non rende gratuito il contesto irrilevante. I prompt lunghi continuano a costare, aumentano la latenza e possono disperdere l'attenzione.

Uso un contesto lungo come quello di Fable quando:

• Il corpus è troppo interconnesso per una suddivisione ingenua in blocchi
• Perdere un dettaglio è peggio che pagare per un contesto aggiuntivo
• L'utente può tollerare risposte più lente
• Il compito trae beneficio dalla visione del materiale circostante nella sua forma originale

Esempio di architettura per la revisione di documenti di grandi dimensioni:

User request
  -> lightweight classifier
  -> retrieve obvious relevant sections
  -> if confidence high: Sonnet answer with citations/quotes from chunks
  -> if confidence low or query is global: Fable 5 over full document set
  -> optional Opus review for high-risk final answer

Questo approccio ibrido funziona meglio del «mettere sempre tutto nel contesto». In pratica, i modelli con contesto lungo sono particolarmente utili come soluzione di riserva quando l'affidabilità del recupero delle informazioni è bassa.

Modelli a pesi aperti: controllo, costi e capacità di elaborazione

I modelli a pesi aperti come Llama, Qwen, DeepSeek, MiniMax e Kimi non sono soltanto «alternative più economiche». Sono scelte operative.

Hanno senso quando ti servono:

• Distribuzione locale o in una VPC
• Costi prevedibili per l'elaborazione in batch ad alto volume
• Fine-tuning o distillazione
• Ottimizzazioni personalizzate dell'inferenza
• Controllo sulla residenza dei dati
• Costi marginali estremamente bassi dopo la configurazione

Sono particolarmente adatti a compiti circoscritti e ripetitivi. Per esempio, una variante di Qwen o Llama servita tramite vLLM può gestire classificazione, estrazione e arricchimento interno con un'elevata capacità di elaborazione, se controlli la lunghezza del prompt e il formato dell'output.

Esempio di configurazione per l'erogazione locale:

vllm serve Qwen/Qwen3-14B \
  --host 0.0.0.0 \
  --port 8000 \
  --tensor-parallel-size 2 \
  --max-model-len 32768 \
  --gpu-memory-utilization 0.90

Poi chiamalo tramite un client compatibile con OpenAI:

from openai import OpenAI

client = OpenAI(
    base_url="http://localhost:8000/v1",
    api_key="local"
)

result = client.chat.completions.create(
    model="Qwen/Qwen3-14B",
    temperature=0,
    messages=[
        {"role": "system", "content": "Return valid JSON only."},
        {"role": "user", "content": "Classify: user cannot access invoice PDF"}
    ]
)

Il compromesso è assumersi la responsabilità tecnica. Con i modelli di frontiera ospitati, qualcun altro gestisce la capacità, le patch, le scelte di quantizzazione e il lavoro sulle prestazioni a livello di kernel. Con i modelli aperti, questo diventa il tuo compito.

I modelli a pesi aperti sono un'ottima scelta quando il carico di lavoro è stabile. Sono meno adatti quando il prodotto cambia ogni settimana e la qualità del prompt conta più del costo puro di erogazione.

Instradamento ai modelli economici con passaggio a modelli superiori

Un buon router non è una classifica. È un sistema di controllo del rischio.

Ecco un approccio adatto alla produzione:

1. Prova il modello più economico che dovrebbe essere in grado di svolgere il compito.
2. Valida l'output con controlli automatici.
3. Chiedi al modello un'autoverifica calibrata solo su criteri osservabili.
4. Passa a un modello superiore se la validazione fallisce, il livello di confidenza è basso o il rischio è alto.
5. Registra il percorso di instradamento e l'esito per ottimizzazioni successive.

Esempio di router:

def run_with_escalation(task, input_text):
    first_model = pick_first_model(task)

    response = call_model(
        model=first_model,
        input=input_text,
        schema=task["schema"],
        temperature=0
    )

    validation = validate(response, task["schema"])

    if not validation.ok:
        return call_model(
            model="claude-sonnet-4.6",
            input=input_text,
            schema=task["schema"],
            temperature=0
        )

    if task["risk"] == "high" and response.get("needs_review"):
        return call_model(
            model="claude-opus-4.8",
            input=input_text,
            schema=task["schema"],
            temperature=0
        )

    return response

L'aspetto importante è che il passaggio a un modello superiore si basi su segnali misurabili, non su impressioni.

Segnali utili per passare a un modello superiore:

• JSON non valido
• Campi obbligatori mancanti
• Risposta contraddittoria
• Chiamata a uno strumento fallita
• Le evidenze recuperate sono deboli
• L'utente richiede un'azione irreversibile
• L'input supera la lunghezza normale
• Il modello segnala esplicitamente un'incertezza
• Il classificatore rileva contenuti legali, medici, di sicurezza o finanziari

Evita di usare soltanto la «confidenza del modello» come punteggio numerico. La confidenza di un LLM non è una probabilità calibrata. Resta comunque utile quando è limitata a verifiche specifiche: «L'input conteneva informazioni sufficienti per rispondere?» è meglio di «Quanto sei sicuro?»

Latenza, prezzo ed esperienza utente

Il modello più veloce non offre sempre la migliore UX. La migliore UX è quella che porta l'utente a un risultato corretto con un'attesa tollerabile.

Per i sistemi interattivi, ragiono in termini di budget di latenza:

Non nascondere un ragionamento lento dietro un indicatore di caricamento senza fornire riscontri. Se un'attività con Opus o Fable richiede 90 secondi, presentala esplicitamente come un'attività di analisi:

Analyzing 184 files...
✓ Indexed repository structure
✓ Found 12 migration scripts
✓ Checking rollback safety

Questo cambia la percezione dell'utente perché il sistema sta svolgendo un lavoro visibile.

Inoltre, usa lo streaming ogni volta che è possibile. Lo streaming non riduce il tempo totale di completamento, ma migliora notevolmente la latenza percepita nei flussi di lavoro di chat e stesura di testi.

Scelte concrete per ciascuna attività

Ecco le scelte concrete che farei oggi.

Smistamento dei ticket di assistenza

Usa prima Haiku.

• Input: breve testo del ticket
• Output: categoria, urgenza, coda di assegnazione
• Passa a Sonnet per contestazioni sulla fatturazione, clienti arrabbiati e ambiguità nelle policy
• Revisione umana per i rimborsi superiori alla soglia

Questo è un classico flusso di lavoro che parte dall'opzione più economica.

Agente di assistenza rivolto ai clienti

Usa Sonnet.

• Richiede l'uso di strumenti
• Richiede il controllo del tono
• Richiede la gestione delle policy
• Richiede un passaggio fluido a un livello di assistenza superiore

Usa Haiku solo per la preelaborazione. Usa Opus per una revisione di supervisione nei casi ad alto rischio.

Assistente per la revisione del codice

Usa Sonnet per la normale revisione delle PR. Usa Opus per modifiche delicate dal punto di vista architetturale, concorrenza, sicurezza, migrazioni dei dati e verifiche di correttezza su aspetti sottili.

Un errore comune è fornire per impostazione predefinita l'intero repository. Parti dal diff, dal grafo delle dipendenze e dai file vicini. Passa a Fable o a un altro modello con contesto lungo solo quando la modifica coinvolge molte aree.

Confronto di contratti o policy lunghi

Usa il recupero delle informazioni insieme a Sonnet per domande circoscritte. Usa Fable 5 quando la domanda è globale, ad esempio «trova tutte le contraddizioni tra questi documenti».

Se l'output influisce su una decisione concreta in ambito legale o di conformità, usa il modello per preparare l'analisi, non per prendere la decisione.

Arricchimento dei dati su larga scala

Usa un modello con pesi aperti se il volume è elevato e l'attività è stabile.

Esempio:

• Normalizzare i nomi delle aziende
• Estrarre tag di settore
• Classificare i lead in entrata
• Generare brevi riepiloghi interni

Esegui batch notturni, valida dei campioni e passa i casi limite a un modello ospitato.

Assistente di ricerca su archivi di grandi dimensioni

Usa Gemini 3, GPT-5.5, Opus o Fable in base alla lunghezza del contesto e alle esigenze di ragionamento. Non partirei dall'opzione più economica per questo caso, a meno che la richiesta non sia chiaramente semplice. Gli errori nella ricerca spesso passano inosservati: il modello fornisce una risposta plausibile ma non individua il documento chiave.

Pianificare il budget senza ingannare sé stessi

Il modo più facile per spendere troppo è ottimizzare il costo per chiamata ignorando i tentativi ripetuti, le correzioni umane e i flussi di lavoro non riusciti.

Monitora queste metriche per tipo di attività e modello:

• Token di input
• Token di output
• Latenza p50/p95
• Tasso di errori di validazione
• Tasso di passaggio a un livello superiore
• Tasso di interventi correttivi umani
• Tasso di tentativi ripetuti dagli utenti
• Costo per attività completata con successo, non costo per chiamata

Quest'ultima metrica conta. Un modello economico che richiede tre nuovi tentativi e rende comunque necessaria una revisione manuale può risultare più costoso di Sonnet. Una chiamata a Opus che evita una migrazione errata può essere la decisione più economica della settimana.

Se usi un gateway multimodello, ad esempio l'accesso API di AI Prime Tech alle famiglie Claude, GPT e Gemini, il vantaggio principale non è soltanto la possibilità di scegliere tra fornitori. È rendere più semplici l'instradamento e la misurazione tra classi di modelli. Ma la parte difficile resta la progettazione delle tue attività.

Indicazioni pratiche

• Parti dalla natura dell'attività: trasformazione, estrazione, ragionamento, sintesi su contesto lungo o arricchimento in batch.
• Usa modelli di classe Haiku per attività economiche, rapide e vincolate, con validazione meccanica.
• Usa modelli di classe Sonnet come scelta predefinita per le funzionalità del prodotto che richiedono ragionamento, strumenti o qualità adeguata all'interazione con gli utenti.
• Usa modelli di classe Opus quando gli errori sono costosi, l'ambiguità è elevata o il ragionamento approfondito è importante.
• Usa un contesto lungo sul modello di Fable 5 quando il problema principale è l'incertezza nel recupero delle informazioni, non come strategia predefinita per riversare tutto nel prompt.
• Usa modelli con pesi aperti quando la stabilità del carico di lavoro, la privacy, la capacità di elaborazione o il controllo del deployment giustificano la gestione diretta dell'inferenza.
• Crea un instradamento che parta dall'opzione più economica, con segnali espliciti per passare a un livello superiore: output non valido, evidenze deboli, strumenti che falliscono, azioni ad alto rischio e incertezza.
• Misura il costo per attività completata con successo, non il costo per token o per chiamata.
• Mantieni i router abbastanza semplici da consentire il debug sotto pressione.
• Tratta la scelta del modello come una leva di controllo ingegneristica, non come una decisione sul fornitore da prendere una volta sola.