Vector Database

Un database vettoriale archivia gli embedding, i vettori numerici che i modelli producono per testo, immagini, audio o video, insieme a un ID e ai metadati di ogni elemento, e risponde in millisecondi alla domanda «quali vettori archiviati sono più vicini a questo?» su milioni o miliardi di elementi. Integra un indice di ricerca vettoriale con le funzionalità di un database: inserimenti, aggiornamenti ed eliminazioni, filtraggio per metadati, persistenza, controllo degli accessi e replica tra macchine. I database vettoriali forniscono la fase di recupero per la generazione aumentata dal recupero (RAG), la ricerca semantica e i sistemi di raccomandazione.

Come funziona un database vettoriale#

Nel percorso di scrittura, un modello di embedding, esterno al database o integrato al suo interno, converte ogni elemento in un vettore e il database archivia quel vettore con un ID e un insieme di metadati, come il file sorgente, la data, la telecamera o il cliente. Confrontare una query con ogni vettore archiviato è preciso ma lento su larga scala, quindi il database crea un indice dei vicini più prossimi approssimati (ANN). HNSW collega ogni vettore ai vicini prossimi in un grafo a livelli che la ricerca percorre in modo greedy; gli indici a file invertito (IVF) raggruppano i vettori con il clustering k-means e analizzano soltanto i cluster più vicini alla query; i metodi di quantizzazione vettoriale, come la quantizzazione del prodotto, comprimono ogni vettore in pochi byte. Nel percorso di lettura, la query viene trasformata in embedding con lo stesso modello e confrontata usando una metrica come la similarità coseno, il prodotto scalare o la distanza euclidea; il database restituisce gli ID, i punteggi e i payload dei primi k risultati, che molti sistemi uniscono ai risultati per parole chiave nella ricerca ibrida.

Questo esempio usa Chroma, un database vettoriale open source che viene eseguito in memoria all'interno di un processo Python:

import chromadb

# Client in memoria; chromadb.PersistentClient(path="db") conserva i dati su disco
client = chromadb.Client()
collection = client.create_collection("inspection_notes")

# Chroma crea l'embedding di ogni documento con il suo modello di embedding predefinito e indicizza i vettori
collection.add(
    ids=["n1", "n2", "n3"],
    documents=[
        "Hairline crack found near the weld on bracket B7",
        "Paint scratch on the left door panel",
        "Porosity in the weld seam of the frame rail",
    ],
    metadatas=[{"line": "A"}, {"line": "B"}, {"line": "B"}],
)

# Ricerca dei vicini più prossimi limitata a una linea di produzione
results = collection.query(query_texts=["welding defects"], n_results=1, where={"line": "B"})
print(results["ids"][0], results["documents"][0])

La query restituisce la nota n3, relativa alla porosità della saldatura sulla linea B. Il filtro sui metadati esclude dalla ricerca la nota sulla crepa della linea A, anche se il suo testo è altrettanto simile a «difetti di saldatura».

Database vettoriali e sistemi correlati#

• Librerie di ricerca vettoriale come FAISS: indici in-process, inclusi HNSW, IVF e quantizzazione del prodotto, senza server, archiviazione di metadati o replica. Diversi database vettoriali si basano su queste librerie.
• Database vettoriali progettati appositamente: Pinecone come servizio gestito e Milvus, Qdrant, Weaviate e Chroma come progetti open source, progettati fin dall'inizio per gli embedding.
• Estensioni vettoriali come pgvector: aggiungono colonne vettoriali con indici HNSW e IVFFlat a PostgreSQL, così gli embedding risiedono accanto ai dati relazionali. Elasticsearch, OpenSearch, MongoDB Atlas e Redis offrono campi vettoriali simili accanto alla ricerca per parole chiave.
• Feature store: forniscono le feature di input del modello tramite la chiave dell'entità per l'addestramento e l'inferenza. Cercano i record tramite ID, non in base alla similarità.
• Data lake: contengono file grezzi come immagini e log, a cui un database vettoriale fa riferimento tramite ID o percorso.

Applicazioni nel mondo reale#

• Memoria per gli agenti AI: le pipeline RAG e gli agenti archiviano porzioni di documenti e conversazioni passate affinché un modello linguistico di grandi dimensioni possa recuperarle quando necessario.
• Ricerca visiva nel retail: le funzionalità «Acquista prodotti simili» creano l'embedding di ogni foto di prodotto e restituiscono gli articoli più vicini a quello che il cliente sta visualizzando.
• Rilevamento delle anomalie: un nuovo campione i cui vicini più prossimi archiviati sono tutti molto distanti viene segnalato come anomalo, per esempio una transazione o una lettura di un sensore.

Per produrre i vettori, le raccolte di immagini hanno bisogno di un modello di visione. Ultralytics YOLO26 ne fornisce uno tramite model.embed(), che esegue il modello su ogni immagine e restituisce un vettore di caratteristiche aggregato dal penultimo livello, pronto per essere archiviato insieme al percorso dell'immagine e ai metadati di acquisizione per rilevare quasi duplicati o cercare immagini simili, come nella funzione Trova immagini simili di Ultralytics Platform.

Dimensionamento e ottimizzazione#

Le impostazioni dell'indice bilanciano recupero e latenza di inferenza: l'ampiezza di ricerca di HNSW (ef_search) e il numero di cluster esaminati da IVF (nprobe) trovano entrambi più vicini effettivi a costo di query più lente, quindi i team li ottimizzano confrontandoli con la ricerca esatta su query campione. La memoria determina il costo dell'hardware. Un milione di embedding float32 a 768 dimensioni occupa 3,07 GB (1.000.000 x 768 x 4 byte) prima di qualsiasi sovraccarico dell'indice; la quantizzazione scalare int8 dei vettori riduce lo spazio a 768 MB, mentre gli embedding Matryoshka possono essere troncati a un numero minore di dimensioni per ridurlo ulteriormente.