Se hai letto qualcosa su RAG, ricerca AI o suggerimenti, probabilmente ti sei imbattuto nel termine database vettoriale. Ecco la versione semplice. Un database vettoriale memorizza i dati come vettori - liste di numeri che catturano il significato - e trova gli elementi per similarità, non per corrispondenza esatta. È proprio questa idea a far sembrare che la ricerca AI moderna ti capisca.
Cos'è davvero un database vettoriale
I database normali sono ottimi per le domande esatte: trova l'utente con questo ID, o ogni ordine della scorsa settimana. Faticano con « trovami cose che significano la stessa cosa ». Un database vettoriale è costruito esattamente per questo.
Funziona sugli embedding - le impronte numeriche che un modello AI assegna a testo, immagini o audio. Gli elementi con significato simile ottengono vettori che stanno vicini tra loro. Il database memorizza quei vettori e, quando cerchi, restituisce quelli più vicini alla tua query.
Come funziona la ricerca per similarità
Il flusso ha tre passaggi:
- Embed. Un modello di embedding trasforma ogni documento, immagine o frase in un vettore.
- Indicizza. Il database memorizza quei vettori in un indice speciale (come HNSW o IVF) così può cercare velocemente in insiemi enormi.
- Query. Anche la tua ricerca viene trasformata in embedding. Il database restituisce i vettori più vicini per distanza.
Così una ricerca per « come reimpostare la mia password » può far emergere un articolo intitolato « recuperare un accesso dimenticato ». Le parole sono diverse, ma il significato - e i vettori - sono vicini.
Database vettoriale vs database normale
Risolvono problemi diversi, e la maggior parte delle app reali usa entrambi. Un database relazionale contiene i tuoi record strutturati e risponde a query esatte. Un database vettoriale risponde a « cosa è più simile a questo? » Tieni le righe dei clienti in uno e il significato ricercabile nell'altro. Strumenti come pgvector ti permettono perfino di aggiungere la ricerca vettoriale a un normale database PostgreSQL, così entrambi vivono in un solo posto.
Perché conta per l'AI
Un database vettoriale è il motore di recupero dietro a gran parte dell'AI. Alimenta la ricerca semantica, i suggerimenti di prodotti e contenuti e - soprattutto - la fase di recupero in RAG, dove un assistente recupera testo pertinente prima di rispondere. Senza una ricerca per similarità veloce sugli embedding, nessuna di queste funzioni sarebbe pratica su larga scala.
Come la ricerca resta veloce: il vicino più prossimo approssimato
Confrontare il vettore della tua query con ognuno dei vettori memorizzati - una ricerca del vicino più prossimo esatta - è preciso ma lento non appena hai milioni di elementi. Per questo i database vettoriali si appoggiano ad algoritmi di vicino più prossimo approssimato (ANN). L'ANN scambia un pizzico di precisione con un enorme guadagno di velocità: invece di controllare ogni vettore, percorre una struttura di indice intelligente che gli dà quasi le corrispondenze più vicine, in fretta.
Due famiglie di indici fanno gran parte del lavoro:
- HNSW (Hierarchical Navigable Small World) costruisce un grafo a livelli che si attraversa rapidamente a salti. È l'impostazione predefinita più comune: buon recall, bassa latenza, più memoria.
- IVF (Inverted File) raggruppa i vettori in contenitori e cerca solo in quelli più vicini. Scala su insiemi molto grandi e usa meno memoria, spesso abbinato alla compressione (PQ) per ridurre la dimensione dei vettori.
La manopola che regoli è il recall contro la latenza: chiedi un recall più alto (più dei veri vicini più prossimi) e la ricerca lavora di più. La distanza si misura con una metrica - di solito similarità del coseno (l'angolo tra i vettori), prodotto scalare o distanza euclidea (L2) - e il modello di embedding che usi di norma impone quale sia quella corretta.
Database vettoriali comuni - e quale scegliere
Non esiste un'unica opzione « migliore »; la scelta giusta dipende dalla scala, dal fatto che tu voglia un servizio gestito o l'auto-hosting, e dal fatto che ti servano i vettori accanto a dati relazionali esistenti. Le opzioni più diffuse nel 2026:
| Database | Modello | Buona scelta quando… |
|---|---|---|
| pgvector | Estensione di PostgreSQL | Usi già Postgres e vuoi i vettori accanto ai tuoi dati normali: un solo database, nessun servizio in più. |
| Chroma | Open source, integrabile | Prototipazione o una piccola app; veloce da avviare in locale. |
| Qdrant | Open source, auto-hosting o gestito | Vuoi un filtraggio ricco per metadati e buone prestazioni mantenendo il controllo sull'hosting. |
| Weaviate | Open source, auto-hosting o gestito | Vuoi moduli integrati (ricerca ibrida, vettorizzazione) e un approccio basato sullo schema. |
| Milvus | Open source, pensato per la scala | Collezioni molto grandi (centinaia di milioni e oltre) e carichi ad alto throughput. |
| Pinecone | Completamente gestito (proprietario) | Vuoi un servizio serverless senza pensieri e preferisci non gestire l'infrastruttura. |
Una regola pratica: parti da pgvector se usi già PostgreSQL, oppure Chroma per un prototipo rapido; passa a Qdrant, Weaviate o Milvus quando ti servono scala, filtraggio o controllo sull'auto-hosting; scegli Pinecone quando vuoi un servizio gestito senza operatività. La maggior parte dei team usa anche la ricerca ibrida - combinando la similarità vettoriale con la ricerca per parole chiave classica - per avere il meglio di entrambe.
In sintesi
Un database vettoriale memorizza il significato come vettori e trova gli elementi per similarità invece che per corrispondenza esatta. Non sostituisce il tuo database normale: gli sta accanto e risponde alle domande a cui una ricerca per parole chiave non potrebbe mai rispondere. Se stai costruendo qualcosa con ricerca semantica o RAG, il database vettoriale è il pezzo che fa il lavoro pesante.
Guide correlate: Cos'è l'Ingegneria dei Prompt? Ottenere Risposte Migliori dall'IA (2026).
