Nel precedente articolo abbiamo costruito una piattaforma AI completamente on-premises, eseguendo un Large Language Model locale su Kubernetes tramite Ollama.
Questa configurazione rappresenta un primo passo fondamentale: ci consente di interrogare un modello linguistico senza dipendere da servizi cloud esterni, mantenendo il pieno controllo dei dati.
Tuttavia, un limite importante rimane.
Il modello, per quanto potente, non conosce il contesto specifico della nostra organizzazione: documentazione interna, procedure, knowledge base, ticket o dati proprietari.
Il problema: LLM senza contesto
Un LLM locale:
- non è aggiornato con dati aziendali
- non può accedere a documenti interni
- risponde solo in base al training generico
Questo lo rende poco utile in scenari reali enterprise.
La soluzione: Retrieval Augmented Generation (RAG)
Per superare questo limite entra in gioco il paradigma di Retrieval Augmented Generation (RAG).
RAG combina due elementi:
- Retrieval → recupero di informazioni rilevanti da una base dati
- Generation → generazione della risposta usando il modello LLM
In pratica:
Per rendere possibile il retrieval, i documenti devono essere trasformati in vettori tramite embeddings.
Qui entra in gioco un componente chiave:
➡️ Vector Database
Nel nostro laboratorio utilizzeremo Qdrant , un database ottimizzato per:
- ricerca semantica
- gestione embeddings
- alta performance su workload AI
Evoluzione dell’architettura
Con l’introduzione del RAG, lo stack evolve:
Ora il modello non risponde più “a memoria”, ma: risponde usando i tuoi dati
Perché il RAG è fondamentale
I motivi principali sono:
- AI contestualizzata per i dati aziendali
- maggiore accuratezza delle risposte
- riduzione delle allucinazioni
- nessuna necessità di retraining del modello
- pieno controllo dei dati (on-prem)
Nel prossimo articolo vedremo nel dettaglio:
- deployment di Qdrant su Kubernetes
- gestione degli embeddings
- caricamento della knowledge base
- integrazione con OpenWebUI e Ollama
