Database vettoriali, embedding e reranking: tre parti diverse del recupero

Gli embedding, i database vettoriali e i reranker sono tre parti diverse del retrieval. Un modello di embedding converte testo o altri dati in rappresentazioni numeriche; un database vettoriale o un indice vettoriale memorizza e cerca quelle rappresentazioni per recuperare elementi candidati; un reranker prende un insieme più piccolo di candidati e lo riordina usando un modello di rilevanza o un metodo di scoring più costoso. Spesso compaiono insieme nel RAG, ma nessuno di essi è la stessa cosa del RAG, e nessuno è obbligatorio in ogni sistema di retrieval.

Cosa significa davvero

I sistemi di ricerca hanno due obiettivi in competizione: trovare abbastanza materiale potenzialmente rilevante e mettere il materiale migliore vicino alla cima. Il recupero rapido di prima fase di solito ottimizza la generazione dei candidati. Un modello più forte di seconda fase può poi spendere più calcolo per distinguere i migliori candidati.

Gli embedding, gli indici vettoriali e i reranker occupano posizioni diverse in quel processo. Trattarli come un'unica funzionalità nasconde scelte di progettazione importanti su recall, precisione, latenza, archiviazione, filtraggio dei metadati e costo del modello.

La distinzione previene anche un errore comune nel RAG: presumere che memorizzare gli embedding dei documenti in un database vettoriale crei automaticamente un retrieval di alta qualità. La qualità del retrieval dipende dal modello di embedding, dal chunking, dai metadati, dalla costruzione della query, dalla configurazione dell'indice, dal numero di candidati, dal retrieval ibrido, dal reranking e dall'autorevolezza delle fonti sottostanti.

L'esempio più semplice

Supponiamo che una base di conoscenza contenga 100.000 chunk di documenti. Un utente chiede: “Come revoco un token API?”

Innanzitutto, un modello di embedding può codificare la query in un vettore. I chunk dei documenti possono già avere i propri embedding memorizzati. Una ricerca vettoriale confronta quindi il vettore della query con i vettori dei documenti indicizzati e restituisce, per esempio, 30 candidati probabili.

Quei 30 candidati possono poi essere passati a un reranker. Il reranker confronta la query più direttamente con ciascun candidato e produce un nuovo ordinamento di rilevanza. L'applicazione potrebbe mantenere i migliori cinque per il contesto del modello.

Dove si ferma l'esempio semplice

I sistemi di retrieval reali non devono necessariamente usare embedding densi. La ricerca per parole chiave come BM25 può essere il retriever di prima fase. Anche il retrieval sparso appreso, i filtri SQL, la traversata di grafi o le API applicative possono generare candidati.

Un reranker inoltre non si preoccupa che i candidati provengano da un database vettoriale. Può riordinare risultati BM25, risultati ibridi, documenti selezionati manualmente o candidati provenienti da più retriever.

Allo stesso modo, gli embedding non richiedono un database vettoriale specializzato. Piccoli dataset possono essere confrontati in memoria o con database generici ed estensioni vettoriali. I sistemi vettoriali specializzati diventano utili quando indicizzazione, ricerca approssimata del vicino più prossimo, filtraggio, scala, comportamento di aggiornamento o requisiti operativi li giustificano.

Embedding: rappresentazione, non recupero

Un embedding è una rappresentazione numerica prodotta da un modello. Per il recupero semantico, i testi con significato correlato sono destinati a occupare posizioni utili in uno spazio vettoriale in modo che una funzione di similarità o distanza possa confrontarli.

Sentence-BERT è stato un passo influente nel rendere pratica la similarità semantica a livello di frase con rappresentazioni in stile bi-encoder che possono essere calcolate indipendentemente e confrontate in modo efficiente. L'idea generale rimane centrale nel recupero denso moderno: precalcolare le rappresentazioni dei documenti, calcolare la rappresentazione della query al momento della ricerca, quindi confrontarle.

L'embedding stesso non cerca in un corpus. Sono dati prodotti da un modello di embedding. Il recupero inizia quando il sistema confronta la rappresentazione della query con i candidati memorizzati.

Il modello di embedding definisce lo spazio di rappresentazione

I vettori dei documenti e delle query devono essere compatibili con il modello e la configurazione utilizzati per crearli. Sostituire un modello di embedding può cambiare dimensionalità, comportamento di similarità, copertura linguistica e prestazioni di dominio.

Ecco perché una migrazione del modello di embedding non è semplicemente un cambio di nome API. I documenti esistenti potrebbero dover essere re-embedded e l'indice ricostruito o versionato.

Le rappresentazioni dense e sparse sono diverse

Gli embedding densi di solito contengono molte dimensioni non nulle e sono comunemente usati per la similarità semantica. Le rappresentazioni sparse contengono molti zeri e possono preservare una struttura più forte simile a token o termini.

Entrambi possono supportare il recupero semantico, e i sistemi di ricerca moderni possono combinare segnali densi, sparsi e lessicali. La "ricerca vettoriale" quindi non significa sempre una pipeline di similarità coseno densa.

Le funzioni di similarità fanno parte del contratto di rappresentazione

Similarità coseno, prodotto scalare e distanza euclidea non significano la stessa cosa. La metrica corretta dipende da come il modello di embedding è stato addestrato e normalizzato.

La documentazione attuale di Qdrant, ad esempio, richiede una metrica di distanza come parte della configurazione vettoriale e documenta scelte in stile coseno, prodotto scalare ed euclideo. La regola architetturale importante è trattare la metrica come parte del contratto di embedding/indice piuttosto che sceglierne una arbitrariamente.

Database vettoriali e indici: recupero dei candidati

Un database vettoriale o un sistema di ricerca con capacità vettoriale organizza le rappresentazioni vettoriali in modo che l'applicazione possa recuperare efficientemente i candidati vicini. I sistemi pratici di solito associano i vettori a ID e metadati di payload come fonte, lingua, tenant, tipo di documento, timestamp o ambito di accesso.

Qdrant, ad esempio, organizza i dati in collezioni di punti dove un punto contiene un vettore e metadati di payload opzionali. La sua documentazione descrive la ricerca di similarità basata su HNSW e il filtraggio dei metadati come capacità separate del livello di recupero.

Questa distinzione è importante: l'indice vettoriale risponde a un problema di nearest-neighbor, mentre i filtri sul payload impongono vincoli strutturali come tenant, classe di documento o lingua.

La ricerca approssimata del nearest-neighbor scambia esattezza con efficienza

Confrontare un vettore di query con ogni vettore può essere pratico per piccole collezioni ma costoso su larga scala. Gli indici approssimati di nearest-neighbor come HNSW riducono il costo di ricerca navigando una struttura di indice invece di scansionare esaustivamente ogni vettore.

La ricerca approssimata introduce un compromesso tra recall e latenza. Una ricerca più veloce può mancare candidati che la ricerca esatta restituirebbe. I parametri dell'indice influenzano quindi la qualità del recupero, non solo le prestazioni dell'infrastruttura.

Qdrant espone sia parametri relativi a HNSW sia un'opzione di ricerca esatta, illustrando che l'archiviazione vettoriale e la politica di recupero approssimato sono decisioni separate.

Il filtraggio dei metadati appartiene prima o durante il recupero dei candidati

Se l'utente può accedere solo al tenant A, recuperare chunk semanticamente simili dal tenant B e tentare di rimuoverli in seguito è il confine di sicurezza sbagliato. I filtri di autorizzazione e di eleggibilità rigida dovrebbero vincolare lo spazio dei candidati prima che tali candidati possano influenzare l'elaborazione a valle.

Lo stesso principio si applica a locale, stato del documento, classe di origine, data, versione del prodotto e altri vincoli deterministici. La similarità dovrebbe classificare i candidati eleggibili; non dovrebbe prevalere sull'eleggibilità.

Un database vettoriale è opzionale

Per un piccolo corpus, il confronto brute-force del coseno può essere semplice e sufficiente. Anche un database relazionale con supporto vettoriale può essere adeguato. Un database vettoriale dedicato diventa prezioso quando il suo indicizzazione, filtraggio, archiviazione distribuita, comportamento di aggiornamento o caratteristiche operative risolvono un requisito reale.

Scegliere un database vettoriale perché "RAG ne ha bisogno" inverte il processo architetturale. Inizia dai requisiti di recupero e dalla scala, poi seleziona la tecnologia di archiviazione/indice.

Reranking: raffinamento della rilevanza di secondo stadio

Un reranker riceve una query e un insieme più piccolo di candidati già recuperati, poi assegna punteggi di rilevanza più forti o un nuovo ordinamento. Normalmente è più costoso dal punto di vista computazionale rispetto al recupero di primo stadio, motivo per cui viene applicato dopo la generazione dei candidati anziché all'intero corpus.

L'attuale guida di Elastic descrive il reranking semantico come una tecnica di stadio finale su un piccolo insieme top-k e osserva che può raffinare il recupero lessicale, semantico o ibrido. Cohere documenta la stessa architettura: ricerca lessicale o semantica di primo stadio seguita da uno stadio di reranking.

Un'implementazione comune utilizza un modello simile a un cross-encoder che esamina insieme la query e ciascun candidato. Questa interazione più ricca può distinguere la rilevanza con maggiore precisione rispetto alla similarità di embedding indipendente, ma è molto più costosa su scala di corpus.

Il recupero con bi-encoder e il reranking con cross-encoder risolvono problemi di costo diversi

Un reranker non può recuperare ciò che il recupero ha mancato

Se il documento rilevante è assente dall'insieme dei candidati, il reranking non ha nulla da promuovere. Questo è il motivo centrale per valutare separatamente il recupero e il reranking.

Una pipeline può avere un'eccellente precisione del reranker e fallire comunque perché il richiamo della prima fase è scarso. Aumentare la qualità del reranker non riparerà la copertura mancante delle fonti, un chunking errato, filtri restrittivi o un retriever di candidati debole.

Il recupero ibrido è una scelta progettuale separata

Il recupero semantico denso è forte quando query e documento usano parole diverse ma esprimono un significato correlato. Il recupero lessicale è forte quando contano termini esatti, identificatori, nomi, codici o frasi rare.

Il recupero ibrido combina più segnali candidati, spesso BM25 lessicale e similarità vettoriale, poi unisce le classifiche usando un metodo come la Reciprocal Rank Fusion o una combinazione ponderata dei punteggi.

Il reranking può quindi operare sull'insieme fuso dei candidati. Il recupero ibrido e il reranking sono pertanto fasi complementari ma distinte.

BM25 non è obsoleto perché esistono gli embedding

La ricerca per parole chiave può superare il recupero denso per identificatori esatti, numeri di versione, messaggi di errore, codici prodotto e vocabolario specializzato. SQLite FTS5, ad esempio, include una funzione di ranking BM25 per la ricerca full-text.

Un'architettura di recupero solida può usare il recupero lessicale come unica prima fase, il recupero vettoriale come unica prima fase, o combinare entrambi a seconda del corpus e della distribuzione delle query.

Il chunking cambia ciò che embedding e reranker possono vedere

Se un documento viene suddiviso male, nessun componente di recupero successivo può ricostruire completamente l'unità semantica mancante. Un chunk che separa una condizione dalla sua eccezione può generare embedding fuorvianti e può anche essere riordinato in modo errato perché il testo candidato è incompleto.

Dimensione dei chunk, sovrapposizione, confini strutturali e metadati influenzano quindi sia il richiamo dei candidati sia il giudizio del reranker. La valutazione del recupero dovrebbe testare l'intera pipeline dall'ingestione al ranking, non solo il modello di embedding.

Non confrontare i punteggi di recupero come se fossero probabilità universali

Similarità coseno, punteggi BM25, punteggi di vettori sparsi, ranghi RRF e punteggi del reranker hanno significati diversi. Un punteggio di 0,82 di un modello di embedding non è automaticamente confrontabile con 0,82 di un altro modello o con un punteggio di un reranker.

Le soglie dovrebbero essere calibrate per il modello, il corpus e il compito effettivi. Le attuali linee guida di Elastic osservano anche che i punteggi di similarità degli embedding possono dipendere dalla query, il che rende rischiosi i tagli universali.

Valutare separatamente le fasi di recupero

Questa separazione è operativamente importante. Se Recall@50 è scarso, il reranker non è il primo componente da correggere. Se Recall@50 è forte ma il miglior passaggio rimane al rango 38, il reranking o la fusione del ranking diventa un obiettivo plausibile.

Quale livello ha effettivamente fallito?

Rilevanza e Fonte di Verità sono diverse

Un reranker può far sembrare estremamente rilevante un documento obsoleto. Un indice vettoriale può recuperare un riassunto secondario che è semanticamente più vicino della fonte primaria. La qualità del retrieval quindi non può sostituire le regole di autorità.

Dove l'autorità della fonte è importante, i filtri sui metadati, le classi di fonte, le regole di versione e la provenienza dovrebbero vincolare il retrieval prima che il risultato diventi contesto del modello.

Evidenza dell'implementazione originale

Source of Truth Research Engine: il retrieval lessicale e semantico sono separati

Il Source of Truth Research Engine contiene un percorso di retrieval lessicale locale che utilizza SQLite FTS5/BM25 e un percorso separato opzionale di retrieval semantico che utilizza embedding generati localmente.

La sua implementazione di ricerca semantica calcola un vettore di query e lo confronta con i vettori dei chunk memorizzati utilizzando la similarità coseno. Il progetto tratta deliberatamente la similarità semantica come un segnale di scoperta piuttosto che come prova: un candidato deve comunque essere ricondotto a una fonte concreta e a un locator prima di supportare un'affermazione.

Questa è un'evidenza di implementazione utile per R01 perché lo stesso corpus può supportare il ranking lessicale e la similarità vettoriale senza confondere nessuno dei due meccanismi con l'autorità probatoria.

Aaasaasa AI Client: Qdrant è un componente infrastrutturale vettoriale

Aaasaasa AI Client include Qdrant/infrastruttura vettoriale come risorsa locale separata. L'architettura Electron espone i servizi Qdrant dal lato affidabile del processo principale invece di trattare la ricerca vettoriale come parte del modello stesso.

Il repository contiene un adattatore client Qdrant, la configurazione del servizio Qdrant e l'infrastruttura Qdrant basata su Docker. Questo dimostra la separazione architetturale tra esecuzione del provider/modello AI e archiviazione/ricerca vettoriale.

L'esistenza del supporto Qdrant non dovrebbe essere sopravvalutata come una pipeline RAG di produzione completa. L'evidenza qui è più ristretta: l'infrastruttura vettoriale è implementata come un proprio confine di componente.

Quando hai bisogno di ciascun componente?

Una sequenza pratica di progettazione del recupero

Idee sbagliate comuni

Casi limite e limitazioni

Alcune applicazioni non necessitano di ricerca semantica. Una ricerca esatta nel database o SQL strutturato può essere più corretta, più veloce e più facile da verificare rispetto al recupero tramite embedding.

Alcuni corpus sono così piccoli che una scansione vettoriale completa è accettabile. L'indicizzazione approssimata aggiunge complessità senza benefici significativi.

Alcune query richiedono un recall elevato prima di qualsiasi ottimizzazione della precisione. Scoperta legale, ricerca e revisione di conformità possono preferire un recupero ampio dei candidati seguito da filtraggio trasparente e revisione umana.

Il recupero multilingue e specifico del dominio può comportarsi molto diversamente tra modelli di embedding. Le affermazioni di benchmark da dataset pubblici non dovrebbero essere considerate prova per un corpus privato.

La latenza del reranking cresce con il numero e la lunghezza dei candidati. La dimensione dei candidati dovrebbe quindi essere ottimizzata come variabile di accuratezza/costo/latenza invece di essere copiata da un tutorial.

Cosa cambierebbe questa risposta?

I confini dei componenti non cambierebbero se un fornitore impacchettasse generazione di embedding, indicizzazione vettoriale e reranking dietro un'unica API. Il prodotto può nascondere le fasi, ma esse restano concettualmente responsabilità diverse con modalità di fallimento diverse.

Futuri modelli di embedding o recupero potrebbero ridurre la necessità di reranking separato in alcuni carichi di lavoro, mentre metodi più forti di late-interaction o sparse appresi possono sfumare le tradizionali categorie dense/lessicali. L'architettura dovrebbe comunque chiedersi quale fase produce rappresentazioni, quale fase genera candidati e quale fase raffina il ranking.

Il design migliore cambia anche con dimensione del corpus, mix di query, lingua, terminologia di dominio, frequenza di aggiornamento, autorevolezza della fonte, budget di latenza e risultati di valutazione.

Conoscenza canonica correlata

R01 presuppone che il concetto di base di RAG sia già compreso. RAG è il pattern più ampio in cui informazioni esterne recuperate vengono fornite a un modello; embedding, ricerca vettoriale e reranking sono componenti di recupero opzionali all'interno di quel pattern.

Quando il retrieval fallisce, diagnostica separatamente copertura delle fonti, retrieval, ranking, assemblaggio del contesto e generazione, invece di trattare l'intero sistema come un unico "fallimento del RAG".

L'architettura Source-of-Truth è il livello di autorità attorno al retrieval: decide quale fonte può stabilire un'affermazione, mentre gli embedding e il ranking decidono solo quali candidati appaiono rilevanti.

Domande frequenti

Glossario

Conclusione

Il modello di retrieval pulito è semplice: gli embedding rappresentano il significato, la ricerca vettoriale recupera i candidati e i reranker affinano l'ordinamento dei candidati.

Una volta che questi confini sono espliciti, le decisioni architetturali diventano più facili da diagnosticare. I candidati mancanti indicano copertura delle fonti, chunking, embedding, filtri o retrieval di primo stadio. Un ordinamento scarso indica ranking, fusione o reranking. Le risposte finali errate possono poi essere investigate separatamente ai livelli di contesto e generazione.

Il risultato più importante non è scegliere il componente di retrieval più alla moda. È costruire una pipeline di retrieval le cui fasi, confini di autorità, metriche e modalità di fallimento possano essere misurati in modo indipendente.

Fonti primarie ed evidenze di implementazione

I riferimenti esterni di seguito documentano i meccanismi di rappresentazione, ricerca vettoriale e reranking usati in questo articolo. Le sezioni specifiche del progetto sono evidenze di implementazione originali e sono intenzionalmente più limitate rispetto ad affermazioni sulla completa maturità del RAG in produzione.