Ollama non è il prodotto: costruire applicazioni Open-LLM pronte per la produzione

Strumenti come Ollama hanno reso la sperimentazione locale con LLM quasi senza attriti. Installa il runtime, scarica un modello, invia un prompt e un assistente locale risponde in pochi secondi. È utile. È anche la parte più semplice del percorso.

Una demo da terminale non è un'applicazione. Un modello locale non è un prodotto. Un'applicazione Open-LLM produttiva necessita di ingestione controllata dei dati, recupero, autorizzazioni, valutazione, logging, astrazione del provider, disciplina di deployment e un flusso di lavoro utente che risolva un vero problema aziendale.

La tesi centrale è semplice: Ollama è un runtime, non il prodotto. Il prodotto vive nel livello applicativo attorno al modello. Quel livello decide quali documenti sono visibili, quali chunk vengono recuperati, quali prompt vengono utilizzati, come vengono valutate le risposte, come vengono registrati i fallimenti e se il sistema può essere affidabile nel lavoro quotidiano.

È qui che l'AI locale diventa interessante per i team che costruiscono assistenti privati, strumenti di conoscenza interna, funzionalità SaaS basate su LLM o copiloti per flussi di lavoro aziendali. Il modello può funzionare localmente, ma privacy, affidabilità e valore aziendale esistono solo se l'intero sistema è progettato correttamente.

Ollama è un runtime, non un prodotto

Ollama è eccellente per eseguire e servire modelli aperti localmente. È particolarmente indicato per esplorazione, flussi di lavoro per sviluppatori, PoC e team che vogliono testare il comportamento del modello senza impegnarsi immediatamente con un provider cloud. Espone l'interazione con modelli locali tramite API e livelli di compatibilità che facilitano la connessione con strumenti esistenti in stile OpenAI.

Ciò non significa che Ollama risolva il problema applicativo. Non sa automaticamente quali documenti aziendali un utente può leggere. Non crea isolamento dei tenant, versionamento dei documenti, audit trail, attribuzione delle fonti, dataset di valutazione o flussi di lavoro UI specifici per il business. Queste responsabilità rimangono nell'architettura applicativa.

• Ollama aiuta con: esecuzione locale del modello, sperimentazione rapida, accesso al modello tramite API, PoC offline-first e produttività degli sviluppatori.
• Ollama non risolve da solo: controllo degli accessi, qualità RAG, ciclo di vita dei documenti, confini dei tenant, valutazione, audit logging, monitoraggio, comportamento di fallback o progettazione di flussi di lavoro aziendali.
• L'errore architetturale: trattare l'inferenza locale come se fosse già un prodotto AI sicuro.

Il modello è la parte più semplice. Il livello applicativo è dove risiede il valore del prodotto.— Principio architetturale

Demo, PoC e produzione sono fasi diverse

Molte iniziative Open-LLM falliscono perché i team confondono una demo funzionante con una capacità produttiva. La differenza non è estetica. Ogni livello di maturità ha un obiettivo diverso, un profilo di rischio diverso e un requisito ingegneristico diverso.

Un PoC può essere intenzionalmente piccolo. La produzione non può essere intenzionalmente cieca. Quando utenti reali, dati privati, decisioni aziendali e aspettative di conformità entrano nel sistema, l'architettura deve diventare esplicita.

Dove si inserisce il RAG

Retrieval-Augmented Generation è il ponte più comune tra un modello linguistico e la conoscenza aziendale privata. Il modello non conosce magicamente documenti interni, contratti, ticket, specifiche di prodotto o runbook. L'applicazione deve recuperare il contesto rilevante prima di chiedere al modello di rispondere.

Un flusso RAG pratico si presenta così:

1. I documenti vengono caricati o sincronizzati da fonti controllate.
2. Il testo viene estratto, pulito e suddiviso in chunk.
3. I chunk ricevono metadati come tenant, proprietario, versione del documento, URL di origine, ambito di accesso e timestamp.
4. Vengono generati embedding per ogni chunk.
5. I vettori vengono memorizzati in pgvector, Qdrant o un altro livello di recupero.
6. Al momento della query, l'applicazione verifica le autorizzazioni prima del recupero.
7. I chunk rilevanti vengono recuperati con ricerca per similarità e filtri sui metadati.
8. Il costruttore di prompt inietta il contesto selezionato nella richiesta al modello.
9. La risposta viene generata con citazioni, limiti di confidenza e fallback di nessuna risposta quando il recupero è debole.

La RAG riduce le allucinazioni, ma non le elimina. Una strategia di chunking inadeguata, metadati deboli, filtri di autorizzazione mancanti, embedding di bassa qualità o un recupero troppo ampio possono comunque produrre risposte convincenti ma errate. I sistemi RAG seri necessitano di soglie, citazioni, registri di recupero e valutazione.

Un'Architettura Pratica Locale Open-LLM

Un percorso di produzione realistico non richiede infrastrutture esotiche. Per molti team, una prima architettura solida può utilizzare un normale stack web: Nuxt per il frontend, un'API Nitro o Node, PostgreSQL come sistema di registrazione, pgvector per il recupero, Ollama come runtime locale, Prisma per l'accesso ai dati e worker in background per l'ingestione e gli embedding.

Domanda utente | v
Interfaccia utente | v
API / Backend | +--> Autenticazione +--> Controllo autorizzazioni tenant e ruolo | v
Livello di recupero | +--> Metadati PostgreSQL +--> Ricerca vettoriale pgvector o Qdrant +--> Soglia di similarità | v
Costruttore di prompt | +--> prompt di sistema +--> chunk recuperati +--> riferimenti alle fonti +--> regole di non risposta | v
Astrazione del provider LLM | +--> Ollama / modello locale +--> fallback modello cloud +--> futuro runtime self-hosted | v
Risposta con fonti | v
Log, tracce, metriche, dataset di valutazione

Questa architettura mantiene il modello sostituibile. Ollama può essere il primo runtime, ma il sistema non dovrebbe essere vincolato a un singolo motore di inferenza. Un'architettura pulita separa il flusso di lavoro dell'utente, il recupero, la costruzione del prompt, il provider del modello e l'osservabilità.

• Frontend: Nuxt o un'altra interfaccia web per flussi di lavoro utente autenticati.
• Backend/API: Nitro, Node.js o FastAPI per orchestrazione, autorizzazioni e routing del provider.
• Database: PostgreSQL per documenti, utenti, tenant, ruoli, prompt, log e metadati.
• Ricerca vettoriale: pgvector per un recupero integrato semplice o Qdrant quando la ricerca vettoriale diventa un servizio dedicato.
• Runtime del modello: Ollama per esecuzione locale, server llama.cpp per servizio leggero o vLLM per servizio GPU ad alta produttività.
• Archiviazione: filesystem locale o archiviazione oggetti compatibile con S3 per file caricati e artefatti estratti.
• Worker: ingestione in background, chunking, embedding, re-indicizzazione ed elaborazione delle versioni dei documenti.
• Osservabilità: log, metriche, tracce dei prompt, tracce di recupero, monitoraggio della latenza e risultati della valutazione.

La Checklist di Prontezza per la Produzione

La seguente checklist è la differenza tra una demo di modello locale e un'applicazione Open-LLM utilizzabile:

• Ogni documento e chunk ha un tenant_id.
• Il recupero è bloccato fino a quando non vengono verificati i permessi dell'utente e del ruolo.
• I documenti includono metadati, fonte, proprietario, versione, stato del ciclo di vita e politica di conservazione.
• La strategia di chunking è documentata e testata su documenti reali.
• La selezione del modello di embedding è esplicita e versionata.
• La configurazione dell'indice vettoriale è riproducibile.
• La soglia di similarità impedisce l'uso cieco di contesto debole.
• Le risposte includono citazioni delle fonti o riferimenti alle fonti ove possibile.
• Il fallback di non risposta viene utilizzato quando la confidenza del recupero è troppo bassa.
• I template dei prompt sono versionati e controllati nelle release.
• L'astrazione del provider LLM è costruita dall'inizio.
• L'output strutturato viene validato prima dell'uso a valle.
• Il dataset di valutazione contiene domande reali, fonti attese e risposte inaccettabili.
• I registri di recupero mostrano quali chunk sono stati utilizzati per ogni risposta.
• Vengono monitorati latenza, utilizzo dei token, carico GPU/CPU e tassi di errore.
• Le regole di privacy e conservazione coprono upload, testo estratto, chunk, embedding, prompt, risposte e log.
• I percorsi di distribuzione, backup, ripristino, rollback e incidenti sono documentati.

Questo si collega direttamente con Enterprise Delivery OS: l'IA utile non è solo una decisione sul modello. È disciplina di consegna, evidenza, controlli, metriche e proprietà operativa.

Astrazione del Provider: Non Sposare un Solo Modello

I modelli locali sono preziosi per casi d'uso sensibili alla privacy, scenari offline, controllo dei costi e sperimentazione interna. I modelli cloud possono ancora essere più forti per ragionamenti difficili, codifica, accuratezza multilingue o lavoro multimodale. Un'applicazione di produzione non dovrebbe trattare nessun modello come infrastruttura permanente.

Un'astrazione del provider consente allo stesso flusso di lavoro dell'applicazione di chiamare Ollama, OpenAI, Gemini, Anthropic, Mistral, vLLM o un altro endpoint self-hosted senza riscrivere il prodotto. L'applicazione decide il provider in base al caso d'uso, alla sensibilità dei dati, alla latenza, ai costi e ai requisiti di qualità.

type LlmProvider = "ollama" | "openai" | "gemini" | "anthropic" | "vllm"; type ChatInput = { provider: LlmProvider; model: string; tenantId: string; userId: string; question: string; context: Array<{ chunkId: string; sourceTitle: string; text: string; }>;
}; async function chat(input: ChatInput) { await assertUserCanAccessContext(input.userId, input.context); const messages = buildRagMessages({ question: input.question, context: input.context, rules: [ "Rispondi solo dal contesto fornito quando possibile.", "Cita i titoli delle fonti.", "Dì quando il contesto è insufficiente." ] }); return llm.chat({ provider: input.provider, model: input.model, messages, trace: { tenantId: input.tenantId, userId: input.userId, promptVersion: "rag-v3.2" } });
}

L'idea chiave non è la sintassi TypeScript. L'idea chiave è il confine. L'applicazione possiede autorizzazioni, recupero, regole del prompt, tracciamento e valutazione. Il provider produce solo l'output del modello.

pgvector vs Qdrant

Per molte applicazioni Open-LLM, la decisione sul database vettoriale è semplice all'inizio: se PostgreSQL è già il tuo sistema di registrazione, pgvector è un ottimo punto di partenza. Mantiene metadati, autorizzazioni, registrazioni dei documenti e vettori vicini tra loro. Questo riduce la complessità operativa.

Qdrant diventa più interessante quando la ricerca vettoriale deve diventare un servizio dedicato: scala di recupero più ampia, filtraggio avanzato, indicizzazione specializzata, modelli di ricerca ibrida o scalabilità indipendente dell'infrastruttura di recupero.

Una regola pratica: inizia con pgvector quando PostgreSQL possiede già i tuoi dati aziendali e la scala di recupero è moderata. Passa a Qdrant quando la ricerca vettoriale diventa una capacità di prodotto a sé stante.

Verifica della realtà su sicurezza e privacy

L'inferenza locale non significa automaticamente AI sicura. Significa solo che l'esecuzione del modello può avvenire localmente. L'intero percorso dei dati conta ancora: file caricati, testo estratto, chunk, embedding, log, prompt, risposte, backup, accesso degli sviluppatori, strumenti di amministrazione ed esportazioni di analisi.

Anche gli embedding meritano attenzione. Non sono il documento originale, ma rappresentano comunque informazioni derivate da contenuti sensibili. Trattali come parte del percorso dati protetto, specialmente quando sono legati a metadati, record di origine, query degli utenti o identificatori del tenant.

• Non indicizzare i documenti prima che le regole di accesso siano note.
• Non recuperare chunk senza filtri per tenant e ruolo.
• Non registrare prompt e risposte completi senza regole di conservazione.
• Non inviare contesto sensibile a un modello cloud a meno che la policy non lo consenta.
• Non dare per scontato che locale sia uguale a conforme al GDPR; la conformità dipende dalla progettazione completa del trattamento.
• Non permettere che le copie di valutazione e debug diventino dataset ombra incontrollati.

È qui che l'architettura SaaS multi-istanza conta. Se tenant, ruoli, proprietà dei dati e confini operativi sono deboli, aggiungere un LLM locale può amplificare il rischio invece di ridurlo.

La valutazione non è opzionale

Un'applicazione Open-LLM in produzione necessita di un ciclo di valutazione. Senza di esso, i team hanno solo aneddoti. Alcune buone risposte dimostrative non provano che il recupero funzioni, che il prompt sia stabile o che il modello si comporti in modo sicuro nell'uso reale.

Un dataset di valutazione minimo dovrebbe includere domande reali degli utenti, documenti di origine attesi, risposte inaccettabili, casi senza risposta e test di regressione per fallimenti precedenti. Ogni modifica a chunking, embedding, prompt, provider del modello o soglia di recupero dovrebbe essere testata rispetto a quel dataset.

• Valutazione del recupero: Il sistema ha recuperato i chunk di origine corretti?
• Valutazione della risposta: La risposta è rimasta ancorata al contesto recuperato?
• Valutazione della sicurezza: Il sistema ha evitato divulgazioni vietate o dati non autorizzati?
• Valutazione operativa: Latenza, tasso di fallimento e costo sono rimasti entro limiti accettabili?
• Valutazione di regressione: Un aggiornamento del modello o del prompt ha rotto un comportamento precedentemente corretto?

Il RAG riduce le allucinazioni, ma non elimina la necessità di valutazione. La valutazione è il ciclo di controllo che trasforma un prototipo intelligente in un prodotto in miglioramento.

Disciplina di distribuzione: il modello è un evento di rilascio

Cambiare un modello non è una modifica di configurazione innocua. Può cambiare lo stile delle risposte, il comportamento di ragionamento, la qualità della lingua, la latenza, l'uso dei token, la disciplina delle citazioni e le modalità di fallimento. In produzione, gli aggiornamenti del modello dovrebbero essere gestiti come eventi di rilascio.

Ciò significa versionare prompt, modelli di embedding, impostazioni di recupero, identificatori del modello, route del provider e risultati di valutazione. Significa anche avere una logica di rollback. Se un nuovo modello causa risposte peggiori ancorate al recupero o rompe l'output strutturato, il sistema necessita di un percorso controllato per tornare alla configurazione nota e funzionante.

Questo si inserisce nella stessa logica operativa di Delivery & Change e architettura di piattaforma pronta per l'AI: una consegna stabile richiede controlli ripetibili, non interventi manuali eroici.

Conclusione: la produzione inizia dove finisce la demo

Ollama può iniziare il viaggio. Rende accessibile l'esecuzione locale del modello e abbassa la barriera alla sperimentazione. Questo è prezioso. Ma l'applicazione di produzione inizia dove finisce la demo.

Il modello è solo un componente sostituibile. Il vero prodotto è il sistema controllato che lo circonda: acquisizione, permessi, recupero, prompt, instradamento dei provider, valutazione, log, monitoraggio, distribuzione, backup e flusso di lavoro dell'utente. È qui che la privacy diventa reale, la qualità diventa misurabile e il valore aziendale diventa ripetibile.

Un'applicazione Open-LLM seria si costruisce attraverso la disciplina ingegneristica, non eseguendo un modello locale una sola volta. Ollama può iniziare il viaggio, ma l'applicazione di produzione inizia dove finisce la demo.

Tema:

Ollama, Open LLM, RAG, pgvector, Qdrant, Local AI, LLMOps, astrazione dei provider, architettura AI aziendale