Vector database spiegate

Dietro quasi ogni funzionalità di "AI-powered search" e RAG si trova sempre lo stesso motore silenzioso: la similarity search sui vettori. Se sta costruendo qualcosa che trova contenuti rilevanti per significato anziché per corrispondenza esatta di parole chiave, è fondamentale capire i vettori e, soprattutto, quando un database dedicato è necessario e quando non lo è.

Dal testo ai vettori

Un embedding è una lista di numeri, un vettore, che cattura il significato di un testo (o di un'immagine, o di un file audio). Un modello di embedding trasforma "annulla il mio abbonamento" e "come smetto di essere addebitato" in vettori che si trovano vicini tra loro, anche se condividono quasi nessuna parola.

Questa prossimità è tutto. Il significato diventa geometria: i concetti simili si trovano vicini nello spazio ad alta dimensionalità, e "trova contenuti correlati" diventa "trova i vettori più vicini."

Come funziona la similarity search

Una volta archiviati i contenuti come vettori, il recupero è semplice in linea di principio:

1. Trasformare la query dell'utente in un vettore tramite embedding.
2. Trovare i vettori archiviati più vicini ad esso, tipicamente tramite cosine similarity.
3. Restituire i contenuti a cui appartengono quei vettori più vicini.

La sfida consiste nell'eseguire il secondo passaggio velocemente quando si hanno milioni di vettori. Confrontare ogni vettore uno per uno è troppo lento, quindi gli indici vettoriali utilizzano algoritmi di approximate nearest neighbor (ANN) che sacrificano una minima quantità di precisione in cambio di una velocità enormemente superiore.

Ha davvero bisogno di un vector database?

Questa è la domanda che conta, e la risposta onesta è: di solito no, almeno all'inizio.

Se utilizza già PostgreSQL, e con Supabase è così, l'estensione pgvector aggiunge colonne vettoriali e indicizzazione ANN direttamente all'interno del database esistente. Questo significa:

• Un unico sistema da gestire, di cui fare il backup e da proteggere, non due.
• Join tra i propri vettori e i dati relazionali ordinari in una singola query: filtrare per tenant, data o categoria insieme alla similarity.
• Nessun servizio aggiuntivo da sincronizzare, da pagare o da mantenere coerente.

Per la maggior parte dei prodotti fino a milioni di vettori, pgvector non è un compromesso: è la risposta pragmatica e corretta.

Quando un vector database dedicato è giustificato

Si passi a un vector store specializzato solo quando si raggiungono limiti reali:

• Scala molto elevata: decine o centinaia di milioni di vettori, dove l'indicizzazione e lo sharding costruiti ad hoc fanno la differenza.
• Throughput di query elevato che entrerebbe in competizione con il carico di lavoro transazionale.
• Funzionalità di retrieval avanzate come hybrid search sofisticata o filtering che un motore dedicato gestisce meglio.

Anche in quel caso, mantenga i metadati su cui si basa l'applicazione in Postgres; lasci al vector store solo ciò che sa fare in modo esclusivo.

Ottenere la qualità del retrieval giusta

Il database è raramente la parte difficile: la qualità del retrieval lo è. Alcuni fattori la influenzano più della scelta del motore:

• Adattare il modello di embedding al proprio dominio e utilizzare lo stesso modello per l'indicizzazione e le query.
• Combinare vector search e keyword search (hybrid) in modo che termini esatti come i nomi dei prodotti vengano comunque trovati.
• Filtrare prima o insieme alla similarity affinché i risultati rispettino tenant e permessi.
• Re-rank dei candidati migliori per portare il contesto più rilevante in prima posizione.

Inizi con semplicità usando pgvector, misuri la qualità del retrieval su query reali e scali l'infrastruttura solo quando i dati lo richiedono. Se sta costruendo AI search o RAG e vuole farlo in modo rapido e preciso senza over-engineering dello stack, ci contatti.