Distribuire un modello linguistico in produzione non significa scaricare uno ZIP ed eseguire un comando. Ho visto team sprecare mesi su una proof of concept che funzionava sul portatile di un ingegnere e che il primo lunedì è caduta con venti utenti concorrenti. Questa guida descrive il processo reale di configurazione, con le decisioni che contano e i punti in cui quasi tutti inciampano.
Prima di toccare qualsiasi cosa: definisci il caso d’uso e il criterio di successo
La configurazione tecnica dipende dal lavoro che il modello dovrà svolgere. Non è la stessa cosa un assistente interno che risponde sulla documentazione aziendale (recupero aumentato sui PDF) e un classificatore di ticket di supporto (un compito circoscritto in cui un modello piccolo ben ottimizzato batte uno grande con prompt generico).
Scrivi una frase concreta prima di scegliere il fornitore: «il commerciale scrive una domanda sui prezzi e riceve una risposta con il link alla sezione del catalogo in meno di tre secondi». Se non puoi misurarlo, non puoi configurare nulla con criterio.
Un errore comune: team che iniziano chiedendo «un ChatGPT interno» senza delimitare dominio né fonti. Il risultato è una chat che allucina sulla politica delle ferie perché nessuno le ha dato accesso al documento corretto. Delimita le fonti prima del modello.
Decisione 1: API gestita, modello aperto autoospitato o ibrido
Tre percorsi reali, con costi e attriti diversi:
- API di un fornitore cloud: metti in funzione in ore. Il costo è variabile per token e la latenza dipende dalla rete. Adatto a quasi tutto, tranne quando ci sono dati che non possono uscire dal perimetro.
- Modello aperto nella tua infrastruttura: controllo totale del dato, costo fisso di GPU. Richiede saper gestire l’inferenza: quantizzazione, memoria video, code di richieste. Un modello da 7-8 miliardi di parametri in quantizzazione a 4 bit gira su una GPU da 24 GB; uno da 70B ne richiede diverse oppure quantizzazioni aggressive che degradano la qualità.
- Ibrido: modello piccolo locale per classificare e instradare, modello grande via API solo per le richieste complesse. Riduce costi ed esposizione dei dati.
Secondo la documentazione ufficiale dei principali framework di inferenza (vLLM, TGI, Ollama), le prestazioni in produzione dipendono più dal batching e dalla gestione della cache KV che dal modello scelto. Un server mal configurato con un modello eccellente offre un’esperienza peggiore di uno ben ottimizzato con un modello medio.
Il fattore che nessuno mette a budget: la GPU
Se opti per l’autoospitazione, calcola la memoria prima di comprare. Regola pratica: parametri in miliardi × byte per parametro secondo la quantizzazione (≈0,5 byte a 4 bit, ≈1 byte a 8 bit, ≈2 byte a 16 bit) più lo spazio per il contesto. Un 7B in FP16 occupa circa 14 GB solo di pesi; con contesto lungo rimani senza VRAM prima di quanto pensi.
Decisione 2: come gli fornisci la conoscenza dell’azienda
Qui sta l’80% del lavoro reale. Due approcci:
Recupero aumentato (RAG)
Frammenti i documenti, generi gli embedding, li salvi in un indice vettoriale e a ogni richiesta recuperi i frammenti rilevanti da iniettare nel prompt. Passaggi di configurazione:
- Ingestione con controllo di versione. Ogni documento porta metadati: fonte, data, reparto, permessi. Senza permessi nei metadati, uno stagista può leggere i verbali del consiglio.
- Frammentazione consapevole. Frammenti da 300-800 token con sovrapposizione. Frammentare per caratteri rompe tabelle ed elenchi; frammenta per struttura (intestazioni, paragrafi).
- Embedding e reindicizzazione. Scegli un modello di embedding multilingue se ci sono documenti in più lingue. Pianifica la reindicizzazione quando cambia il corpus; un indice obsoleto risponde con dati di due anni fa senza avvisare.
- Recupero ibrido. Combina ricerca semantica e ricerca lessicale (BM25). I codici prodotto e i nomi propri falliscono nella ricerca puramente vettoriale.
- Reranking e soglia. Un reranker scarta i frammenti irrilevanti. Definisci una soglia: se la similarità è bassa, l’assistente deve dire «non lo so» invece di inventare.
Fine-tuning
Utile per stile, formato di output e compiti ripetitivi con molti esempi etichettati. Non è lo strumento per iniettare conoscenza mutevole: un modello ottimizzato con il catalogo di gennaio continuerà a rispondere con quello di gennaio. Per dati che cambiano, RAG.
Configurazione del prompt di sistema e delle salvaguardie
Il prompt di sistema è configurazione, non scrittura creativa. Definisci: ruolo, tono, limiti, formato di output e cosa fare in caso di dubbio. Sii esplicito con il formato se devi fare il parsing della risposta (JSON con schema fisso, per esempio) e valida l’output con un parser prima di mostrarlo all’utente.
Salvaguardie minime che devi configurare:
- Filtro di input e output per i dati personali secondo la politica interna.
- Limite di lunghezza del contesto e dei token di output (evita costi fuori controllo).
- Registro delle conversazioni con conservazione definita e accesso sottoposto ad audit.
- Rate limiting per utente e per IP.
- Pulsante «segnala risposta errata» che alimenti una coda di revisione.
Un dettaglio che scopri in produzione: gli utenti incollano conversazioni complete di altre chat nel prompt. Senza limite di lunghezza, il costo per sessione si moltiplica e il modello si distrae con contesto irrilevante.
Integrazione con i sistemi dell’azienda
L’assistente raramente vive isolato. Configurazione tipica:
- Livello di orchestrazione (backend proprio o framework di agenti) che riceve la richiesta, decide se consultare l’indice, chiamare uno strumento o rispondere direttamente.
- Connettori verso sistemi interni via API con credenziali di servizio in sola lettura e permessi minimi. Non dare mai al modello credenziali di scrittura sull’ERP nella prima versione.
- Autenticazione ed ereditarietà dei permessi. L’assistente deve rispondere solo con ciò che l’utente può vedere. Questo si implementa nel livello di recupero, non nel prompt: chiedere al modello di «non rivelare dati riservati» non è un controllo di accesso.
- Osservabilità. Tracce per richiesta: token di input e output, latenza, frammenti recuperati, costo stimato. Senza questo non puoi ottimizzare né giustificare la spesa.
Testa con dati reali prima di aprire la porta
Prepara un insieme di valutazione con domande reali degli utenti e risposte attese. Misura: precisione della risposta, tasso di «non lo so» corretti, latenza al percentile 95 e costo medio per richiesta. Secondo studi del settore, una parte significativa dei fallimenti negli assistenti aziendali proviene dal recupero, non dalla generazione: il modello risponde bene a un frammento sbagliato.
Testa anche i casi limite: domande ambigue, richieste fuori dominio, tentativi di manipolazione del prompt. E controlla il comportamento con documenti scansionati male digitalizzati: l’OCR sporco genera risposte con cifre corrotte.
Distribuzione graduale e manutenzione
Inizia con un gruppo pilota di dieci o venti persone di un solo reparto. Raccogli feedback per due settimane, ottimizza il prompt e il corpus, e solo allora amplia. Abbi un piano di rollback: poter disattivare l’assistente senza rompere il flusso di lavoro del team.
Manutenzione continua indispensabile: reindicizzare quando cambiano i documenti, rivedere i costi settimanali, monitorare la latenza e aggiornare il modello quando esce una versione migliore solo dopo aver superato la valutazione. Cambiare modello senza valutare è il modo più rapido per degradare un sistema che funzionava.
Cosa questo approccio non risolve
Un LLM configurato così non sostituisce un sistema di regole in processi dove l’esattezza è obbligatoria (calcolo delle buste paga, conformità normativa con cifre). Non è nemmeno affidabile per ragionamenti matematici complessi senza strumenti esterni. E non elimina la necessità di revisione umana nelle comunicazioni esterne sensibili.
La configurazione passo passo che funziona è quella che parte circoscritta, misura e amplia solo ciò che dimostra valore. Il resto è spesa in token.