Tag: Retrieval

Pubblicato il

Deployment di Qdrant su Kubernetes

Dopo aver installato un LLM locale con Ollama su Kubernetes, il passo successivo per costruire un sistema AI realmente utile è permettere al modello di consultare una knowledge base personalizzata.

Questo approccio prende il nome di RAG – Retrieval Augmented Generation: il modello non si limita alle conoscenze con cui è stato addestrato, ma recupera informazioni da un database vettoriale contenente documenti indicizzati tramite embeddings.

Nel laboratorio Kubernetes utilizzato in questo articolo la pipeline è composta da:

  • Ollama → esecuzione del modello LLM
  • Qdrant → database vettoriale per gli embeddings
  • Open WebUI → interfaccia grafica e gestione della knowledge base
  • Embedding model → trasformazione dei documenti in vettori

Architettura semplificata:

User
│
▼
Open WebUI
│
|– Query → Ollama (LLM)
│
└── Search → Qdrant (vector DB)
│
▼
Knowledge Base
Deploy Qdrant su k8s

Per il deployment di Qdrant è possibile utilizzare il chart Helm ufficiale.

Repository Helm: https://qdrant.github.io/qdrant-helm

Aggiungiamo il repository:

  • helm repo add qdrant https://qdrant.github.io/qdrant-helm
  • helm repo update

Installazione nel namespace dedicato all’AI:

helm install qdrant qdrant/qdrant \
–namespace ai \
–create-namespace

Dopo pochi secondi verifichiamo lo stato dei pod:

  • kubectl get pods -n ai  — Output atteso: qdrant-0 1/1 Running

Il servizio Kubernetes esposto sarà:

kubectl get svc -n ai

Esempio:

qdrant ClusterIP 10.43.x.x 6333/TCP

La porta 6333 espone l’API REST di Qdrant.

Verifica rapida:

kubectl exec -n ai qdrant-0 — wget -qO- http://localhost:6333/healthz

Risposta attesa: healthz check passed

Pubblicato il

LLM & RAG: L’importanza del dato

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:

  1. Retrieval → recupero di informazioni rilevanti da una base dati
  2. Generation → generazione della risposta usando il modello LLM

In pratica:

Domanda utente
↓
Ricerca nei dati aziendali (vector DB)
↓
Contesto rilevante
↓
LLM (Ollama)
↓
Risposta arricchita e contestualizzata
Il ruolo del Vector Database

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:

Utente
↓
OpenWebUI
↓
Ollama (LLM)
↓
Qdrant (Vector DB)
↓
Knowledge Base

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:

  1. deployment di Qdrant su Kubernetes
  2. gestione degli embeddings
  3. caricamento della knowledge base
  4. integrazione con OpenWebUI e Ollama