Per molte aziende l'obiettivo è semplice: l'utilità di ChatGPT, ma che risponda dalla conoscenza interna e senza inviare dati riservati a terzi. Oggi è del tutto fattibile con modelli open-weight — ed è diventato il percorso predefinito per i settori regolati. Ecco l'architettura completa, le decisioni che contano e i modi in cui questi progetti affondano.
I quattro blocchi
- Modello — un LLM open-weight (Llama, Mistral, Qwen, Gemma…) dimensionato su hardware e task.
- Motore di serving — Ollama per prototipo o piccolo team; vLLM/TGI per concorrenza in produzione. Entrambi espongono una API compatibile con OpenAI.
- Livello RAG — ingestione, chunking, embeddings e un DB vettoriale, così l'assistente risponde dalla tua conoscenza e cita le fonti.
- UI di chat + controllo accessi — un front-end di chat aperto (Open WebUI, LibreChat) collegato a SSO e permessi per team.
Scegliere il modello (e il modello di embedding)
La verità controintuitiva degli assistenti grounded: con un buon RAG, la qualità del retrieval sposta la qualità delle risposte più della dimensione del modello. Un moderno 8–14B che cita il paragrafo giusto batte un 70B che tira a indovinare da uno sbagliato. Logica di selezione pratica:
- 8–14B (Q5/Q8 su una scheda 24GB) — il punto di partenza giusto per Q&A sui documenti, riassunti, ricerca interna. Veloce, economico, reattivo sotto concorrenza.
- 30–70B (48–80GB) — ripaga il costo per ragionamento multi-step, qualità di redazione, codice e output multilingue sfumato. Fai l'upgrade quando la valutazione mostra che il modello piccolo è il collo di bottiglia — non prima.
- Verifica della lingua: se i tuoi utenti lavorano in italiano, testa i modelli candidati in italiano — la qualità dell'instruction-following varia tra le lingue molto più di quanto i benchmark inglesi suggeriscano. Le famiglie Qwen e Gemma sono spesso forti in multilingua; verifica sui tuoi prompt.
- Verifica della licenza: "open-weight" ≠ fai-quello-che-vuoi. La maggior parte delle licenze (Llama, Gemma) consente l'uso aziendale interno, ma alcune restringono i campi d'uso o richiedono attribuzione. Falla leggere davvero a qualcuno prima che il pilot diventi infrastruttura.
- La scelta dimenticata — il modello di embedding: il retrieval vive o muore su di esso. Scegli un embedder multilingue forte se i documenti mescolano lingue, tienilo versionato (cambiarlo significa re-indicizzare tutto), e preferiscine uno che puoi self-hostare — un assistente "privato" che chiama una API cloud di embedding sta facendo uscire il contenuto dei documenti.
La pipeline RAG, onestamente
Flusso di riferimento: documenti → parsing → chunking → embeddings → DB vettoriale; alla query: domanda → recupero dei top chunk (filtrati sui permessi dell'utente) → costruzione prompt → LLM locale → risposta con citazioni. Ogni fase ha un modo di fallire che ti troverà:
- Il parsing è la palude. La conoscenza aziendale vive in PDF con tabelle, contratti scansionati, PowerPoint e formati di export dei wiki. Un'estrazione di testo cattiva avvelena tutto a valle — metti a budget tempo vero qui, usa OCR dove serve, e controlla a campione cosa il parser ha davvero prodotto.
- Chunking: dividi per struttura (titoli, paragrafi), non per conteggi fissi di caratteri; mantieni i chunk autosufficienti (una riga di tabella senza intestazione è rumore); allega metadati (fonte, data, reparto) per il filtraggio.
- Qualità del retrieval: la similarità vettoriale pura manca i termini esatti (codici prodotto, numeri di articolo) — la ricerca ibrida (vettoriale + keyword/BM25) più un reranker è la correzione standard e spesso il singolo salto di qualità più grande dell'intero sistema.
- Le citazioni non sono negoziabili. Gli utenti perdonano una risposta sbagliata con una fonte verificabile; abbandonano un'allucinazione sicura di sé. Grounding + citazioni visibili è la tua politica anti-allucinazioni.
- Freschezza: i documenti cambiano. Pianifica la re-indicizzazione, gestisci le cancellazioni (un documento revocato deve uscire dall'indice, non solo dalla UI), e logga le versioni dell'indice per l'audit.
- DB vettoriale: Chroma o pgvector per iniziare (pgvector è ideale se hai già Postgres); Qdrant/Weaviate/Milvus quando crescono scala e richieste di filtraggio. Questa scelta è raramente il collo di bottiglia — non sovraingegnerizzarla.
Il fallimento enterprise n°1: la fuga di permessi
Nel momento in cui indicizzi il drive condiviso, indicizzi anche la cartella delle valutazioni salariali che qualcuno ci ha messo per sbaglio. Il RAG poi la cita allegramente a chiunque faccia la domanda giusta. Il retrieval ACL-aware — filtrare i chunk candidati sui permessi dell'utente richiedente al momento della query — è un blocco al lancio, non una voce di roadmap. Regole pratiche: rispecchia i permessi dei sistemi sorgente nei metadati dei chunk all'ingestione; filtra al retrieval (non nel prompt — non ci si può fidare che il modello taccia ciò che ha visto); ri-sincronizza i permessi a cadenza; e parti da una allowlist di set di documenti puliti e scelti deliberatamente invece di "indicizza tutto e restringi poi" — il poi non arriva mai.
Sicurezza: il modello delle minacce in breve
- Prompt injection indiretta: un'istruzione malevola nascosta dentro un documento ("ignora le istruzioni precedenti e…") viene recuperata ed eseguita. Mitiga: tratta il testo recuperato come dati (separazione chiara nel prompt), rimuovi contenuti attivi all'ingestione, e non dare mai all'assistente strumenti che agiscono (inviare email, chiamare API) su contenuto recuperato senza conferma umana.
- Logging vs privacy: vuoi log completi delle query per audit e qualità — ma i log di un assistente interno contengono per natura PII e segreti. Cifrali, restringi l'accesso, imposta la retention e dichiaralo nell'informativa privacy interna (il GDPR vale anche verso i tuoi dipendenti).
- Supply chain del modello: scarica i pesi dalla fonte ufficiale, verifica i checksum e blocca le versioni. Un file modello è un artefatto come ogni altra dipendenza.
- Isolamento: la macchina di serving non ha bisogno di internet a runtime — è il vantaggio dell'on-prem; applicalo davvero con regole di egress.
Hardware per dimensione del team
| Utenti | Setup | Modello | Motore |
|---|---|---|---|
| Pilot / ≤10 | 1× 24GB (3090 usata) | 8–14B Q5/Q8 | Ollama + Open WebUI |
| ~10–50 | 1× 48GB (classe A6000) | 14–34B AWQ | vLLM (continuous batching) |
| ~50–200 | 1–2× 80GB o 2× 48GB | 34–70B AWQ/FP8 | vLLM + load balancer |
| 200+ | Pool GPU, k8s, autoscaling | 70B+ / MoE + routing su modelli piccoli | Flotta vLLM |
La concorrenza guida il sizing più dell'organico: 200 dipendenti raramente significano 200 query simultanee. Misura la concorrenza reale del pilot prima di comprare la scheda grossa — e ricorda che la KV-cache scala per sessione concorrente (vedi la guida VRAM).
Costi vs comprare semplicemente abbonamenti
Qui l'inquadramento onesto batte l'entusiasmo. Il SaaS AI per postazione a piccola scala è difficile da battere sul prezzo: sotto circa 30–50 utenti, uno stack self-hosted (hardware + le ore-ingegnere che sono il suo costo reale) di solito costa di più per utente. Il caso self-hosted si vince su altri assi: controllo dei dati (niente esce; auditor e DPO dormono), uso illimitato (niente ansia per postazione o per token, quindi l'uso cresce davvero), personalizzazione (il tuo RAG, i tuoi modelli, i tuoi flussi), e — a scala maggiore — costo puro, dove un rig fisso sostituisce centinaia di abbonamenti. Fai i conti col metodo TCO della nostra guida ai costi e presenta entrambi gli scenari; i deployment più solidi sono scelti a occhi aperti, non venduti sull'hype.
Cosa non farà (gestisci le aspettative subito)
- Conosce i tuoi documenti, non le notizie di ieri — i modelli open-weight hanno un cutoff di conoscenza, e il tuo assistente è deliberatamente offline.
- Ogni tanto sbaglierà comunque — grounding + citazioni lo gestiscono; non lo eliminano. Vietagli per policy le decisioni vincolanti (HR, legale, pricing).
- Non è esente da manutenzione: aggiornamenti dei modelli, refresh degli indici, sync dei permessi e valutazione della qualità sono un lavoro ricorrente — un budget realistico è una frazione di un ingegnere, in modo permanente.
Un rollout pragmatico
- Pilot (settimane 1–4): una GPU, un modello 8–14B, Ollama + Open WebUI, RAG su un set di documenti pulito e ben permissionato. Un team amico.
- Valuta onestamente: costruisci un test set di ~50 domande reali con risposte note; misura il tasso di risposte fondate e l'accuratezza delle citazioni prima e dopo ogni modifica. Questo piccolo harness guiderà ogni decisione futura (modello più grande? retrieval migliore?).
- Produzione: sposta il serving su vLLM, aggiungi SSO, retrieval ACL-aware, logging con retention e un host con egress bloccato.
- Scala deliberatamente: espandi i set di documenti uno alla volta (prima i permessi), cresci modello/GPU quando l'eval dice che il modello è il collo di bottiglia, aggiungi il routing su modelli piccoli quando cresce il carico.