pgvector vs database vettoriale gestito per la ricerca semantica

Che problema risolve la ricerca semantica in un'app aziendale

La ricerca semantica aiuta le persone a trovare la risposta giusta anche quando non usano le parole “corrette”. Invece di corrispondere parole esatte, corrisponde il significato. Chi digita “reset my login” dovrebbe comunque vedere un articolo intitolato “Change your password and sign in again” perché l'intento è lo stesso.

La ricerca per parole chiave fallisce nelle app aziendali perché gli utenti reali sono incoerenti. Usano abbreviazioni, fanno errori di battitura, confondono nomi di prodotto e descrivono sintomi invece dei termini ufficiali. In FAQ, ticket di supporto, documenti di policy e guide di onboarding lo stesso problema si manifesta in molte frasi diverse. Un motore a parole chiave spesso non restituisce nulla di utile o una lunga lista che costringe a cliccare a casaccio.

Gli embeddings sono il mattone di base. La tua app trasforma ogni documento (un articolo, un ticket, una nota di prodotto) in un vettore, una lunga lista di numeri che rappresentano il significato. Quando un utente fa una domanda, anche la domanda viene trasformata in embedding e cerchi i vettori più vicini. Un “database vettoriale” è semplicemente dove conservi quei vettori e come li cerchi rapidamente.

In uno stack aziendale tipico, la ricerca semantica tocca quattro aree: il content store (knowledge base, documentazione, sistema ticket), la pipeline di embedding (import e aggiornamenti quando il contenuto cambia), l'esperienza di query (barra di ricerca, risposte suggerite, assistenza all'operatore) e le garanzie (permessi più metadati come team, cliente, piano e regione).

Per la maggior parte dei team, “abbastanza buono” batte il perfetto. L'obiettivo pratico è rilevanza alla prima risposta, tempi di risposta sotto un secondo e costi prevedibili al crescere del contenuto. Questo obiettivo conta più del dibattito sugli strumenti.

Due opzioni comuni: pgvector e database vettoriale gestito

La maggior parte dei team finisce per scegliere tra due pattern per la ricerca semantica: tenere tutto dentro PostgreSQL con pgvector, oppure aggiungere un database vettoriale gestito separato accanto al database principale. La scelta dipende meno da “quale è migliore” e più da dove vuoi che viva la complessità.

pgvector è un'estensione di PostgreSQL che aggiunge un tipo vettoriale e indici così puoi memorizzare gli embeddings in una tabella normale ed eseguire ricerche di similarità con SQL. Nella pratica, la tabella documenti può includere testo, metadati (customer_id, status, visibility) e una colonna embedding. La ricerca diventa: “calcola l'embedding della query, poi restituisci le righe i cui embedding sono più vicini”.

Un database vettoriale gestito è un servizio ospitato pensato principalmente per gli embeddings. Di solito fornisce API per inserire vettori e interrogare per similarità, oltre a funzionalità operative che altrimenti dovresti costruire tu.

Entrambe le opzioni fanno lo stesso lavoro di base: memorizzano embeddings con un ID e metadati, trovano i vicini più prossimi per una query e restituiscono i migliori match così la tua app può mostrare elementi rilevanti.

La differenza chiave è il sistema di registrazione. Anche se usi un database vettoriale gestito, quasi sempre mantieni PostgreSQL per i dati aziendali: account, permessi, fatturazione, stato dei workflow e log di audit. Il vector store diventa un livello di retrieval, non il posto dove gira tutta l'app.

Un'architettura comune è questa: mantieni il record autorevole in Postgres, memorizzi gli embeddings in Postgres (pgvector) o nel servizio vettoriale, esegui una ricerca di similarità per ottenere gli ID corrispondenti e poi recuperi le righe complete da Postgres.

Se costruisci app su una piattaforma come AppMaster, PostgreSQL è già una casa naturale per dati strutturati e permessi. La domanda diventa se la ricerca embedding debba starci dentro oppure in un servizio specializzato mentre Postgres resta la fonte di verità.

Sforzo di setup: cosa devi davvero fare

I team spesso scelgono basandosi sulle funzionalità e poi si sorprendono per il lavoro quotidiano. La vera decisione è dove vuoi che stia la complessità: dentro il tuo setup Postgres esistente o in un servizio separato.

Con pgvector, stai aggiungendo la ricerca vettoriale al database che già gestisci. Il setup è generalmente semplice, ma resta lavoro database, non solo codice applicativo.

Un setup tipico con pgvector include l'abilitazione dell'estensione, l'aggiunta di una colonna embedding, la creazione di un indice che corrisponda al tuo pattern di query (e il suo tuning successivo), decidere come aggiornare gli embeddings quando il contenuto cambia e scrivere query di similarità che applichino anche i filtri normali.

Con un database vettoriale gestito, crei un nuovo sistema accanto al database principale. Questo può significare meno SQL, ma più colla di integrazione.

Un setup tipico gestito include la creazione di un indice (dimensioni e metrica di distanza), l'inserimento di API key nei segreti, la costruzione di un job di ingest per spingere embeddings e metadati, mantenere una mappatura stabile degli ID tra record dell'app e record vettoriali e limitare l'accesso di rete così solo il backend può interrogarlo.

CI/CD e migrazioni differiscono: pgvector si integra naturalmente nelle migrazioni e nel processo di revisione esistenti. I servizi gestiti spostano i cambiamenti in impostazioni di codice più amministrative, perciò ti serve un processo chiaro per le modifiche di configurazione e per il reindexing.

La proprietà tipicamente segue la scelta. pgvector tende a ricadere sugli sviluppatori dell'app e su chi gestisce Postgres (a volte un DBA). Un servizio gestito è spesso di responsabilità di un team piattaforma, con gli sviluppatori che gestiscono ingest e logica di query. Perciò questa decisione riguarda tanto la struttura del team quanto la tecnologia.

Filtri e permessi: il dettaglio che decide

La ricerca semantica aiuta solo se rispetta ciò che un utente è autorizzato a vedere. In una vera app aziendale, ogni record ha metadati accanto all'embedding: org_id, user_id, role, status (open, closed) e visibility (public, internal, private). Se il tuo livello di ricerca non può filtrare bene quei metadati, otterrai risultati confusi o, peggio, fughe di dati.

La differenza pratica più grande è filtrare prima vs dopo la ricerca vettoriale. Filtrare dopo sembra semplice (cerca tutto, poi scarta le righe proibite), ma fallisce in due modi comuni. Primo, le migliori corrispondenze possono essere rimosse, lasciandoti con risultati peggiori. Secondo, aumenta il rischio di sicurezza se qualche parte della pipeline fa log, cache o espone risultati non filtrati.

Con pgvector, i vettori risiedono in PostgreSQL insieme ai metadati, così puoi applicare i permessi nella stessa query SQL e lasciare che Postgres li faccia rispettare.

PostgreSQL: permessi e join sono nativi

Se la tua app usa già Postgres, pgvector spesso vince in semplicità: la ricerca può essere “solo un'altra query”. Puoi fare join tra ticket, clienti e membership, e usare Row Level Security così il database stesso blocca le righe non autorizzate.

Un pattern comune è ridurre il set candidato con filtri su org e status, poi eseguire la similarità vettoriale su quello che resta, miscelando opzionalmente una corrispondenza per parole chiave per identificatori esatti.

Database vettoriale gestito: filtri variano, i permessi di solito sono responsabilità tua

La maggior parte dei database vettoriali gestiti supporta filtri sui metadati, ma il linguaggio del filtro può essere limitato e i join non esistono. Tipicamente denormalizzi i metadati in ogni record vettoriale e reimplementi i controlli di permesso nell'applicazione.

Per la ricerca ibrida nelle app aziendali, di solito vuoi che tutto questo funzioni insieme: filtri rigidi (org, role, status, visibility), corrispondenza per parole chiave (termine esatto come un numero di fattura), similarità vettoriale (significato) e regole di ranking (boost per elementi recenti o aperti).

Esempio: un portale di supporto costruito in AppMaster può tenere ticket e permessi in PostgreSQL, rendendo semplice far rispettare “l'agente vede solo la sua org” pur ottenendo corrispondenze semantiche su riepiloghi e risposte dei ticket.

Qualità di ricerca e nozioni di performance

La qualità di ricerca è la combinazione di rilevanza (i risultati sono utili?) e velocità (sembra istantaneo?). Con sia pgvector che un database vettoriale gestito, solitamente si sacrifica un po' di rilevanza per latenza più bassa usando ricerche approssimate. Questo compromesso va bene per le app aziendali, purché lo misuri con query reali.

A un livello alto, si tarano tre cose: il modello di embedding (come appare il “significato”), le impostazioni dell'indice (quanto cerca l'engine) e lo strato di ranking (come ordinare i risultati una volta aggiunti filtri, recency o popolarità).

In PostgreSQL con pgvector, in genere scegli un indice come IVFFlat o HNSW. IVFFlat è più veloce e leggero da costruire, ma devi tarare quante “liste” usa e generalmente vuoi abbastanza dati prima che dia il meglio. HNSW spesso dà migliore recall a bassa latenza, ma può usare più memoria e impiega più tempo a costruirsi. I sistemi gestiti espongono scelte simili, con nomi e default diversi.

Alcune tattiche contano più di quanto ci si aspetti: cache per query popolari, batch dove possibile (per esempio prefetch della pagina successiva) e considerare un flusso in due fasi in cui fai prima una ricerca vettoriale veloce e poi riordini i top 20–100 con segnali di business come recency o tier del cliente. Attenzione anche ai salti di rete: se la ricerca vive in un servizio separato, ogni query è un round trip in più.

Per misurare la qualità, inizia piccolo e concreto. Raccogli 20–50 domande reali degli utenti, definisci cosa significa una “buona” risposta e monitora hit rate top3 e top10, latenza mediana e p95, percentuale di query senza buon risultato e quanto cala la qualità quando si applicano permessi e filtri.

Qui la scelta smette di essere teorica. L'opzione migliore è quella che raggiunge il tuo target di rilevanza a una latenza accettabile, con il tuning che il tuo team può mantenere.

Preoccupazioni di scala e operazioni continue

Molti team iniziano con pgvector perché tiene tutto in un posto: dati dell'app e embeddings. Per molte app aziendali, un singolo nodo PostgreSQL basta, soprattutto se hai decine o qualche centinaio di migliaia di vettori e la ricerca non è il driver principale del traffico.

I limiti di solito emergono quando la ricerca semantica diventa un'azione core (su molte pagine, su ogni ticket, in chat) o quando memorizzi milioni di vettori e hai bisogno di tempi di risposta stretti nelle ore di picco.

Segnali comuni che un singolo Postgres è sotto sforzo includono aumento della latenza p95 durante attività normali di scrittura, dover scegliere tra indici veloci e velocità di scrittura accettabile, task di manutenzione che diventano “programmiamoli di notte” e la necessità di scalare la ricerca diversamente dal resto del database.

Con pgvector, scalare spesso significa aggiungere repliche di lettura per il carico di query, partizionare tabelle, ottimizzare indici e pianificare ricostruzioni di indice e crescita dello storage. È fattibile, ma diventa lavoro continuativo. Devi anche decidere se tenere gli embeddings nella stessa tabella dei dati business o separarli per ridurre il bloat e il contention sui lock.

I database vettoriali gestiti spostano gran parte di questo al fornitore. Spesso offrono scalabilità indipendente di compute e storage, sharding integrato e alta disponibilità più semplice. Il compromesso è gestire due sistemi (Postgres più vector store) e mantenere sincronizzati metadati e permessi.

I costi sorprendono i team più delle performance. I principali driver sono lo storage (vettori più indici crescono in fretta), il volume di query di picco (spesso ciò che definisce la fattura), la frequenza di aggiornamento (re-embedding e upsert) e il movimento di dati (chiamate extra quando l'app ha bisogno di filtri pesanti).

Se stai scegliendo tra pgvector e un servizio gestito, scegli quale dolore preferisci: tuning profondo di Postgres e pianificazione della capacità, o pagare di più per una scalabilità più semplice gestendo una dipendenza in più.

Sicurezza, compliance e affidabilità: domande da porsi

I dettagli di sicurezza spesso decidono prima dei benchmark di velocità. Chiedi presto dove risiederanno i dati, chi può vederli e cosa succede durante un outage.

Inizia con residenza dei dati e accesso. Gli embeddings possono comunque rivelare significato, e molti team memorizzano anche snippet grezzi per evidenziazioni. Sii chiaro su quale sistema terrà il testo grezzo (ticket, note, documenti) e quale conterrà solo embeddings. Decidi anche chi dentro l'azienda può interrogare direttamente lo store e se serve separazione netta tra produzione e accesso analitico.

Controlli da confermare prima di costruire

Fai queste domande per entrambe le opzioni:

• Come sono cifrati i dati a riposo e in transito, e puoi gestire le tue chiavi?
• Qual è il piano di backup, quanto spesso si testano i restore e quale obiettivo di recovery ti serve?
• Hai log di audit per letture e scritture, e puoi allertare su volumi di query insoliti?
• Come applichi l'isolamento multi-tenant: database separati, schemi separati o regole a livello di riga?
• Qual è la policy di retention per contenuti eliminati, inclusi embeddings e cache?

La separazione multi-tenant è quella che manda più persone in difficoltà. Se un cliente non deve mai influenzare un altro, ti serve un tenant scoping forte in ogni query. Con PostgreSQL questo si può far rispettare con Row Level Security e pattern di query attenti. Con un database vettoriale gestito spesso ti appoggi a namespace o collection più la logica applicativa.

Affidabilità e modalità di errore

Pianifica i downtime della ricerca. Se il vector store è giù, cosa vedranno gli utenti? Una fallback sicura è usare la ricerca per parole chiave o mostrare solo elementi recenti, invece di rompere la pagina.

Esempio: in un portale di supporto costruito con AppMaster, potresti tenere i ticket in PostgreSQL e trattare la ricerca semantica come una funzionalità opzionale. Se gli embeddings non sono disponibili, il portale può comunque mostrare liste di ticket e permettere ricerche esatte mentre recuperi il servizio vettoriale.

Passo dopo passo: come scegliere con un pilot a basso rischio

Il modo più sicuro per decidere è eseguire un piccolo pilot che assomigli alla tua app reale, non a un notebook demo.

Inizia scrivendo cosa stai cercando e cosa deve essere filtrato. “Cercare la nostra doc” è vago. “Cercare articoli di help, risposte dei ticket e manuali PDF, ma mostrare solo gli elementi che l'utente è autorizzato a vedere” è un requisito reale. Permessi, tenant ID, lingua, area prodotto e filtri su “solo contenuti pubblicati” spesso decidono il vincitore.

Poi scegli un modello di embedding e un piano di refresh. Decidi cosa viene embedded (documento intero, chunk o entrambi) e quanto spesso si aggiorna (ad ogni modifica, nightly o alla pubblicazione). Se il contenuto cambia spesso, misura quanto è doloroso il re-embedding, non solo quanto sono veloci le query.

Poi costruisci una API di ricerca snella nel backend. Mantienila noiosa: un endpoint che prende una query più campi filtro, restituisce i migliori risultati e registra cosa è successo. Se costruisci con AppMaster, puoi implementare l'ingest e il flusso di aggiornamento come servizio backend più un Business Process che chiama il provider di embedding, scrive vettori e metadati e applica le regole di accesso.

Esegui un pilot di due settimane con utenti e compiti reali. Usa una manciata di domande comuni che gli utenti fanno realmente, traccia “tasso di risposta trovata” e tempo alla prima risposta utile, rivedi settimanalmente i risultati errati, monitora volume di re-embedding e carico di query e testa modalità di errore come metadati mancanti o vettori obsoleti.

Alla fine decidi basandoti sulle prove. Mantieni pgvector se soddisfa qualità e filtri con lavoro operativo accettabile. Passa a un gestito se dominano esigenze di scalabilità e affidabilità. Oppure usa un setup ibrido (PostgreSQL per metadati e permessi, vector store per retrieval) se si adatta al tuo stack.

Errori comuni in cui incappano i team

La maggior parte degli errori emerge dopo che la prima demo funziona. Un proof of concept veloce può apparire ottimo, poi crollare quando aggiungi utenti reali, dati reali e regole reali.

I problemi che spesso causano rifacimenti sono:

• Assumere che i vettori gestiscano i controlli di accesso. La ricerca di similarità non sa chi può vedere cosa. Se la tua app ha ruoli, team, tenant o note private, servono ancora filtri di permesso rigorosi e test per evitare fughe.
• Fidarsi di demo che “sembrano buone”. Poche query selezionate non sono una valutazione. Senza un piccolo set etichettato di domande e risultati attesi, le regressioni sono difficili da cogliere quando cambi chunking, embedding o indici.
• Embedding dell'intero documento come singolo vettore. Pagine grandi, ticket e PDF solitamente richiedono chunking. Senza chunk, i risultati diventano vaghi. Senza versioning, non sai quale embedding corrisponde a quale revisione.
• Ignorare aggiornamenti e cancellazioni. Le app reali modificano e rimuovono contenuti. Se non ricalcoli gli embedding all'update e non pulisci alla cancellazione, servirai corrispondenze obsolete che puntano a testi mancanti o superati.
• Ottimizzare la performance prima di definire l'UX. I team passano giorni su impostazioni di indice saltando basi come filtri metadati, buoni snippet e un fallback per parole chiave quando la query è molto specifica.

Un semplice test “day-2” cattura questi problemi presto: aggiungi una nuova regola di permesso, aggiorna 20 elementi, cancellane 5 e poi fai di nuovo le stesse 10 domande di valutazione. Se costruisci su una piattaforma come AppMaster, pianifica questi controlli assieme alla logica di business e al modello di database, non come un ripensamento.

Scenario esempio: ricerca semantica in un portale di supporto

Una SaaS di medie dimensioni gestisce un portale di supporto con due tipi principali di contenuto: ticket dei clienti e articoli della help center. Vogliono una barra di ricerca che capisca il senso, così digitando “can’t log in after changing phone” appare l'articolo giusto e ticket simili del passato.

I non negoziabili sono pratici: ogni cliente deve vedere solo i propri ticket, gli agenti devono poter filtrare per status (open, pending, solved) e i risultati devono sembrare istantanei perché i suggerimenti appaiono mentre l'utente digita.

Opzione A: pgvector nello stesso PostgreSQL

Se il portale già memorizza ticket e articoli in PostgreSQL (comune se costruisci su uno stack che include Postgres, come AppMaster), aggiungere pgvector può essere una prima mossa pulita. Mantieni embeddings, metadati e permessi in un posto, quindi “solo i ticket per customer_123” è semplicemente una clausola WHERE.

Questo funziona bene quando il dataset è modesto (decine o centinaia di migliaia di elementi), il team sa gestire tuning di indici e piani di query e vuoi meno parti in movimento con controllo di accesso più semplice.

Il compromesso è che la ricerca vettoriale può competere con il carico transazionale. Con l'aumentare dell'uso potresti aver bisogno di capacità extra, indici accurati o addirittura un'istanza Postgres separata per proteggere scritture di ticket e SLA.

Opzione B: database vettoriale gestito per embeddings, PostgreSQL per i metadati

Con un database vettoriale gestito di solito memorizzi embeddings e un ID lì, poi tieni la “verità” (status ticket, customer_id, permessi) in PostgreSQL. In pratica i team o filtrano prima in Postgres e poi cercano gli ID eleggibili, oppure cercano prima e ricontrollano i permessi prima di mostrare i risultati.

Questa opzione vince spesso quando la crescita è incerta o il team non vuole dedicare tempo a curare le performance. Ma il flusso dei permessi richiede cura reale, altrimenti rischi fughe tra clienti.

Una chiamata pratica è partire con pgvector se ti servono filtri stretti e operazioni semplici ora, e pianificare un database vettoriale gestito se prevedi crescita rapida, volume di query elevato o non puoi permetterti che la ricerca rallenti il database principale.

Checklist rapida e prossimi passi

Se sei bloccato, smetti di discutere funzioni e scrivi cosa l'app deve fare al giorno uno. I requisiti reali spesso emergono durante un piccolo pilot con utenti e dati reali.

Queste domande di solito decidono prima dei benchmark:

• Quali filtri sono non negoziabili (tenant, ruolo, regione, status, intervallo temporale)?
• Quanto crescerà l'indice in 6–12 mesi (elementi ed embeddings)?
• Quale latenza sembra istantanea per i tuoi utenti, anche nei picchi?
• Chi possiede il budget e la responsabilità on-call?
• Dove deve vivere la fonte di verità: tabelle PostgreSQL o un indice esterno?

Pianifica anche il cambiamento. Gli embeddings non sono “set and forget”. Il testo cambia, i modelli cambiano e la rilevanza deriva finché qualcuno non si lamenta. Decidi in anticipo come gestirai gli aggiornamenti, come rileverai il drift e cosa monitorerai (latenza query, tasso di errori, recall su un piccolo set di test e ricerche “no results”).

Se vuoi muoverti in fretta sull'app completa intorno alla ricerca, AppMaster (appmaster.io) può essere una soluzione pratica: ti offre modellazione dati PostgreSQL, logica backend e UI web o mobile in un unico workflow no-code, e puoi aggiungere la ricerca semantica come iterazione una volta che l'app core e i permessi sono a posto.