LLM in produzione: miti e realtà nel 2026

Perché quasi tutto quello che ti hanno raccontato sugli LLM in produzione è solo metà della storia

Ho visto team buttare via sei mesi di lavoro dando per buone due idee opposte: che un LLM funzionasse come un endpoint REST e bastasse lanciarlo, oppure che fosse così imprevedibile da non valere la pena di portarlo fuori dal laboratorio. Nessuna delle due regge il confronto con il traffico reale. Secondo la documentazione ufficiale dei principali fornitori di modelli, latenza, costo e qualità variano in modo non lineare con il contesto, la temperatura e la lunghezza della risposta, e questo infrange molte delle promesse che circolano in talk e post.

Questo articolo passa in rassegna i miti che fanno più danni quando si portano i modelli linguistici in produzione e li confronta con ciò che accade quando il sistema serve utenti reali: retry, prompt malformati, dati sensibili e picchi di carico. Non ci sono garanzie di risultato: ci sono pattern che funzionano in certi contesti e altri che falliscono clamorosamente.

Mito 1: «Il prompt perfetto elimina la necessità di ingegneria»

Il prompt conta, ma non sostituisce l’architettura. Un team con cui ho collaborato ha costruito un assistente di supporto che rispondeva con precisione nei test manuali. In produzione, lo stesso prompt ha smesso di funzionare non appena gli utenti hanno iniziato a scrivere in maiuscolo, con errori o incollando screenshot trascritti da un OCR difettoso. Il tasso di risposte utili è crollato senza che il modello fosse cambiato.

Cosa funziona davvero

• Validazione dell’input: normalizzare il testo, limitare la lunghezza e rilevare la lingua prima di chiamare il modello.
• Contratti di output: richiedere JSON con uno schema e validarlo con una libreria; se fallisce, riprovare con un prompt di correzione circoscritto.
• Fallback deterministico: per le query ad alta frequenza, un template o delle regole possono rispondere meglio e a costi inferiori rispetto al modello.

La realtà è che il prompt è un pezzo del sistema, non il sistema. I team maturi versionano i prompt come codice, li valutano con set di casi e misurano le regressioni prima del deploy.

Mito 2: «Più contesto migliora sempre la risposta»

La finestra di contesto ampia è utile, ma non è gratuita. Secondo la documentazione dei fornitori, costo e latenza crescono con i token di input, e in pratica la qualità non migliora in modo monotono: inserire dieci documenti irrilevanti diluisce il segnale e aumenta la probabilità che il modello citi informazioni tangenziali.

Esempio concreto di fallimento

In un motore di ricerca interno sulla documentazione tecnica, passare da 3 a 15 frammenti recuperati ha migliorato la copertura delle risposte corrette sulle domande ampie, ma ha peggiorato le risposte alle domande di dettaglio perché il frammento corretto finiva sepolto tra altri simili. La soluzione non è stata ampliare il contesto, ma migliorare il ranking del recupero e limitarsi ai frammenti con il punteggio più alto, con una soglia di taglio.

Limiti che conviene riconoscere

Non esiste un numero magico di frammenti. Dipende dal dominio, dalla qualità dell’indice e dal tipo di domanda. Chi afferma «usa sempre top-k=5» sta semplificando. Bisogna misurarlo con un proprio set di valutazione.

Mito 3: «Il modello è deterministico se imposto temperatura 0»

La temperatura 0 riduce la variabilità, ma non la elimina in tutti i fornitori né in tutti i modelli. Inoltre, il determinismo apparente nasconde un’altra fonte di variazione: cambiamenti silenziosi nel modello ospitato. Lo stesso identificatore può essere aggiornato e alterare le risposte, cosa che la documentazione di diversi fornitori segnala esplicitamente.

Conseguenze pratiche

• Fissare versioni specifiche quando il fornitore lo consente.
• Mantenere un set di test di regressione da eseguire dopo ogni cambio di versione.
• Registrare la versione del modello insieme a ogni risposta per poter fare audit.

Se il tuo prodotto dipende dal fatto che l’output sia identico tra esecuzioni, un LLM non è lo strumento adatto per quella parte. Lì conviene una logica deterministica.

Mito 4: «Costa poco perché il token è economico»

Il costo per token sembra basso finché non lo si moltiplica per utenti, retry e contesto. Un pattern che vedo spesso: un chatbot che include l’intera cronologia della conversazione in ogni chiamata. Con conversazioni di venti turni, il costo cresce in modo quadratico rispetto al numero di turni, non lineare.

Cosa si può fare

• Riassumere la cronologia più vecchia e conservare solo gli ultimi turni rilevanti.
• Fare cache delle risposte per le domande ripetute, se il dominio lo consente.
• Instradare le query semplici verso modelli piccoli e riservare quelli grandi ai casi complessi.
• Imporre limiti di spesa per utente o per sessione.

Non esiste una formula universale di risparmio. Qualsiasi cifra condivisa senza contesto di traffico e lunghezza del contesto è aneddotica. Quello che è coerente: senza osservabilità dei token di input e output, il costo sfugge di mano.

Mito 5: «Se funziona nella demo, è pronto per la produzione»

La demo mostra il percorso felice. La produzione è il percorso infelice: input vuoti, tentativi di prompt injection, utenti che chiedono cose fuori ambito, cadute del fornitore e timeout. Secondo studi di settore sull’affidabilità dei servizi, i guasti delle dipendenze esterne sono una causa comune di incidenti, e un LLM è una dipendenza esterna in più.

Checklist minima prima di esporlo agli utenti

1. Timeout e retry con backoff esponenziale, con limite di tentativi.
2. Circuit breaker per non martellare il fornitore quando fallisce.
3. Messaggi di degradazione chiari quando il modello non è disponibile.
4. Filtri di input e output per dati personali e contenuti dannosi.
5. Registrazione delle tracce con prompt, risposta, latenza e costo, con retention definita.

Niente di tutto questo è glamour, ma è ciò che separa un prototipo da un servizio che regge un lunedì mattina.

Mito 6: «La valutazione si risolve con buone metriche automatiche»

Le metriche automatiche come BLEU o ROUGE hanno una correlazione debole con l’utilità percepita nelle attività aperte. Per un sistema di estrazione dati con schema fisso, una metrica di accuratezza funziona. Per un assistente conversazionale, no.

Cosa funziona in pratica

• Un set di valutazione piccolo ma rappresentativo, revisionato da persone del dominio.
• Valutazione tra pari o rubriche per le attività soggettive.
• Campionamento periodico delle risposte reali per rilevare derive.

Riconosco un limite: costruire e mantenere quel set richiede tempo e non scala bene come uno script automatico. Ma senza di esso, qualsiasi affermazione sulla qualità del sistema è un’opinione.

Mito 7: «La privacy si risolve con un avviso legale»

Inviare dati degli utenti a un fornitore esterno ha implicazioni che un avviso non risolve. Bisogna sapere cosa si invia, quanto viene trattenuto e in quale giurisdizione viene elaborato. Alcuni team scoprono tardi di aver incluso email e numeri di telefono nei prompt perché il modulo di origine li raccoglieva senza filtri.

Misure concrete

• Pseudonimizzare gli identificatori prima di costruire il prompt.
• Definire quali campi non escono mai dal sistema.
• Rivedere le condizioni di retention del fornitore e, se necessario, usare deployment che non memorizzano dati.

Questo non è un parere legale, e conviene consultarsi con chi di dovere. Ma tecnicamente, filtrare prima di inviare costa meno che rimediare dopo.

Mito 8: «Un LLM sostituisce il team di supporto o quello dei contenuti»

Può ridurre il carico nelle attività ripetitive, ma introduce un costo di supervisione. Un modello che risponde con sicurezza su temi che non padroneggia genera più lavoro di quanto ne risparmi. Nei progetti di assistenza clienti, la revisione umana delle risposte a bassa confidenza resta necessaria per evitare errori costosi.

La realtà è più noiosa: l’LLM è uno strumento dentro un flusso, con umani nei punti di rischio. I casi in cui funziona senza supervisione sono quelli con schema chiuso e basse conseguenze in caso di errore, come classificare ticket o riassumere testi interni.

Cosa conviene davvero dare per scontato prima di iniziare

• Avrai bisogno di osservabilità dal primo giorno, non dopo.
• Il costo reale si capisce quando c’è traffico, non in laboratorio.
• La qualità si misura con dati propri, non con benchmark pubblici.
• Ci saranno cambiamenti nel fornitore che influenzeranno il tuo prodotto senza che tu tocchi nulla.
• Alcune attività non dovrebbero essere risolte con un LLM: calcoli esatti, conformità normativa rigorosa o decisioni con conseguenze irreversibili.

Implementare LLM in produzione è meno magia e più disciplina ingegneristica: versionamento, valutazione, limiti e degradazione controllata. I miti vendono scorciatoie; la realtà chiede di misurare prima di promettere.