“Spedire un modello non è lanciare un razzo. È aprire una cucina: la parte difficile è il pranzo di punta, tutti i giorni.”
Il percorso della richiesta in produzione
Una funzionalità IA servita non è una chiamata al modello; è una pipeline. Una richiesta tocca una cache, passa un guardrail di input, raggiunge il modello, passa un guardrail di output e ritorna, con un percorso di fallback per quando il modello è lento o fuori servizio. Ogni stadio è infrastruttura ordinaria, e ognuno è dove controlli costo, sicurezza e affidabilità.
Costo e latenza sono parametri di progettazione
L'addestramento è capex; l'inferenza è opex: paghi per chiamata, per sempre. Su larga scala, il costo dei modelli diventa una vera voce di bilancio, e le scelte che lo controllano sono architetturali, fatte presto. Le grandi leve: la dimensione del modello (usa il modello più piccolo che passa la tua eval), la lunghezza del contesto (ogni token nel prompt costa a ogni chiamata) e la cache.
La cache è la leva di costo a più alto impatto e la più trascurata. Molte richieste sono quasi-duplicati; una cache a corrispondenza esatta o semantica può servirle gratis. Il prompt caching (riutilizzare il costo di un lungo prompt di sistema stabile tra le chiamate) riduce ulteriormente la fattura.
La latenza è una decisione di prodotto, non solo un numero. Lo streaming la nasconde: gli utenti tollerano molto meglio una risposta lenta che parte immediatamente di una rapida che arriva tutta in blocco dopo una pausa. E la latenza degli agenti si accumula: un agente di 10 passi a due secondi a passo fa venti secondi, che è un prodotto diverso da una risposta in un secondo.
Affidabilità: il modello fallirà
I provider hanno disservizi. I modelli vengono limitati in rate, vanno in timeout e a volte restituiscono spazzatura. La tua funzionalità deve degradare, non collassare. Le difese sono quelle familiari dei sistemi distribuiti: timeout, retry con backoff, un fallback (un modello più piccolo, una risposta in cache, o un onesto "riprova tra poco"), e un circuit breaker così che il brutto pomeriggio di un provider non ti porti giù con sé.
Modificare un sistema in produzione senza romperlo
I sistemi IA cambiano costantemente: i prompt vengono ritoccati, i modelli aggiornati, il retrieval regolato, i provider deprezzano versioni sotto i tuoi piedi. Ognuna di queste cose è un'occasione per regredire silenziosamente. La disciplina del cambiamento sicuro è la stessa di qualsiasi sistema di produzione, applicata a un componente probabilistico.
- Condiziona ogni modifica al set di eval: niente passaggio dell'eval, niente spedizione (capitolo 6).
- Distribuisci gradualmente: fai un rollout canary su una fetta del traffico, osserva le metriche, poi allarga.
- Fissa le versioni del modello: non lasciare mai che "latest" cambi il tuo comportamento a tua insaputa.
- Tieni un rollback: prompt e scelte di modello tornano indietro con la stessa pulizia del codice.
- Sorveglia la produzione, non solo le eval: i casi che gli utenti inviano sorprenderanno il tuo set di test.
Dove andare da qui
Ora hai la forma di un vero sistema IA: un modello sottile in un guscio spesso e deterministico, alimentato dal retrieval, potenziato dai tool, mantenuto onesto dalle eval, e gestito come qualsiasi altro servizio di produzione. Due direzioni lo approfondiscono: metterlo in sicurezza contro la nuova superficie di attacco che tutto questo apre, e le guide su prompt e RAG per pattern pratici.
Una riga per ciascuno
- Una funzionalità servita è una pipeline (cache, guardrail, modello, fallback), non una nuda chiamata al modello.
- Costo e latenza sono architetturali: dimensiona bene il modello, usa la cache in modo aggressivo, riduci il contesto, fai streaming dell'output.
- Il modello fallirà; degrada con timeout, retry, fallback e un'astrazione multi-provider.
- Modifica un sistema in produzione in sicurezza: condiziona alle eval, distribuisci gradualmente, fissa le versioni, tieni un rollback, sorveglia la produzione.