Ricerca ibrida: BM25 vs vettoriale (e perché servono entrambi)

Ricerca ibrida: BM25 vs vettoriale (e perché servono entrambi)

Un operatore di supporto digita "SKU-4471" nel tuo chatbot RAG. Tornano quattro risultati, tutti sbagliati con aria di assoluta sicurezza. Un modello di embedding generico non ha alcun motivo per avvicinare quella stringa esatta a sé nello spazio vettoriale. È esattamente questo singolo punto di rottura che ha fatto nascere la ricerca ibrida, ed è il motivo per cui i team continuano a farsi la stessa domanda: come si combinano davvero BM25 e ricerca vettoriale senza passare la vita a regolare un cursore?

Se stai valutando gli strumenti RAG in senso più ampio, la nostra classifica dei migliori strumenti RAG copre l'intero stack circostante.

Punti chiave

• BM25 trova corrispondenze esatte sulle parole chiave (SKU, codici di errore); la ricerca vettoriale trova testi concettualmente simili, non stringhe identiche.
• La ricerca ibrida li combina entrambi, in genere tramite la Reciprocal Rank Fusion (RRF), e sui carichi di lavoro con query miste batte ciascuno dei due metodi presi singolarmente.
• Sul benchmark WANDS, la RRF semplice ottiene 0,7068 di NDCG (contro lo 0,6983 di BM25); con il tuning si arriva a 0,7497, un guadagno del 7,4%.
• Postgres/pgvector può eseguire la ricerca ibrida in modo nativo tramite ts_rank + pgvector, senza bisogno di un database vettoriale dedicato.

Cos'è la ricerca ibrida? (BM25 + vettoriale, combinati)

La ricerca ibrida esegue BM25 e ricerca vettoriale come due passaggi di retrieval separati sulla stessa query, poi fonde le due liste di risultati ordinati in un unico output usando un algoritmo di fusione, il più delle volte la Reciprocal Rank Fusion. Non è un terzo metodo di retrieval: è uno strato di orchestrazione sopra due metodi esistenti.

La distinzione conta, perché una buona fetta del traffico di ricerca su questo argomento tratta BM25 e ricerca vettoriale come se fossero la stessa cosa. Non lo sono. BM25 è una funzione di punteggio sparsa, basata sulle parole chiave, con radici nell'information retrieval degli anni '70. La ricerca vettoriale è una ricerca di similarità densa, basata sugli embedding, diventata praticabile su larga scala solo nell'ultimo decennio. La ricerca ibrida li tratta come input complementari, non come tecniche in competizione, e ne fonde gli output invece di scegliere un vincitore in partenza.

BM25 vs vettoriale vs ibrida: confronto rapido

Sul benchmark e-commerce WANDS, BM25 da solo ha totalizzato 0,6983 di NDCG e la ricerca vettoriale da sola 0,6953 (un sostanziale pareggio). La fusione RRF semplice, senza tuning specifico per corpus, ha raggiunto 0,7068: un modesto +1,2% rispetto a BM25. Nel suo benchmark, Doug Turnbull ha testato anche una variante ottimizzata che aggiunge un boost sul nome prodotto sopra la RRF, e quella versione è arrivata a 0,7497, con un guadagno del 7,4%. Vale la pena essere onesti su quale numero si sta citando: la RRF da sola offre un piccolo vantaggio reale già pronta all'uso; il più ampio 7,4% ha richiesto un tuning aggiuntivo specifico per il dominio che la maggior parte dei team, il primo giorno, non fa. Né BM25 né la ricerca vettoriale dominano da soli: coprono modalità di errore diverse, e fonderli chiude entrambe le lacune in un colpo solo.

Meccanica di BM25: come la ricerca per parole chiave calcola davvero la rilevanza

BM25 assegna un punteggio ai documenti in base alla frequenza dei termini, pesata rispetto alla rarità di quel termine nell'intero corpus, poi normalizzata per la lunghezza del documento. Robertson e Zaragoza hanno formalizzato il tutto nel loro paper del 2009 "The Probabilistic Relevance Framework: BM25 and Beyond". È un raffinamento del TF-IDF, non un suo sostituto.

Due parametri controllano gran parte del comportamento di BM25. k1 (in genere 1,2-2,0) governa la saturazione della frequenza: mette un tetto a quanto la ripetizione di una parola possa spingere il punteggio, così un documento che dice "fattura" 40 volte non supera automaticamente uno che la dice 4 volte in un passaggio più breve e più pertinente. b (default 0,75) controlla la normalizzazione della lunghezza: decide quanto duramente BM25 penalizza i documenti lunghi per il fatto che contengono naturalmente più occorrenze.

Sbagliare b è un errore di tuning reale e frequente. Documenti tecnici brevi (log di errore, titoli prodotto) vogliono una b più bassa, perché la varianza di lunghezza è piccola; i contenuti lunghi (pagine di documentazione, articoli) di solito vogliono una b più vicina al default. Il punto debole di fondo di BM25 è il disallineamento lessicale: se un utente chiede "come riavere i miei soldi" e il documento dice solo "politica di rimborso", BM25 non trova alcun token in comune e non restituisce nulla di utile.

Meccanica della ricerca vettoriale densa (e dove si rompe)

La ricerca vettoriale mappa il testo in embedding a dimensione fissa tramite un modello, poi trova i vettori vicini con la similarità del coseno o il prodotto scalare, in genere accelerata da un indice nearest-neighbor approssimato. HNSW è l'algoritmo dominante in Weaviate, Qdrant e Milvus: scambia una piccola quota di recall con grandi guadagni di velocità su larga scala.

Questo è ciò che risolve il problema di disallineamento lessicale di BM25: "riavere i miei soldi" e "politica di rimborso" atterrano vicini nello spazio di embedding anche con zero token in comune, perché il modello cattura il significato, non la forma di superficie. Qui la scelta del modello conta molto. Vedi la nostra guida su come scegliere il modello di embedding giusto e il nostro confronto tra gli embedding di Voyage, OpenAI e Cohere se stai valutando le opzioni.

Ma il retrieval denso ha un suo punto cieco, ed è l'immagine speculare di quello di BM25. Quando costruiamo sistemi RAG per i clienti, il fallimento sulla corrispondenza esatta che incontriamo più spesso non è niente di esotico. È un operatore di supporto che chiede un preciso numero d'ordine o SKU, e l'indice vettoriale che restituisce con sicurezza qualcosa di semanticamente simile ma sbagliato. Un modello di embedding generico non ha alcun motivo per posizionare "SKU-4471" o "ERR_CONN_RST" vicino a sé nello spazio vettoriale rispetto a un token correlato ma errato, perché stringhe del genere compaiono di rado come concetti distinti e isolati nei dati di addestramento. BigData Boutique documenta esattamente questo schema di errore con i suoi esempi di SKU e codici di errore. È un fenomeno consolidato e confermato in modo indipendente in molteplici deployment RAG, non un caso isolato.

Come combinare BM25 e ricerca vettoriale: RRF vs fusione pesata con alpha

Ci sono due modi reali per fondere i risultati di BM25 e del vettoriale, e quasi nessuno tra chi scrive di ricerca ibrida li mette a confronto con chiarezza. La Reciprocal Rank Fusion (RRF), dal paper SIGIR del 2009 di Cormack, Clarke e Buettcher, lavora sulle posizioni: score = sum(1 / (k + rank_i)) su ciascuna lista di risultati, con k in genere impostato a 60. Poiché guarda solo alla posizione e non al punteggio grezzo, la RRF gestisce senza problemi i disallineamenti di scala tra i punteggi illimitati di BM25 e l'intervallo da 0 a 1 della similarità del coseno, e non richiede tuning per corpus.

La fusione pesata con alpha (convessa) funziona diversamente: final = alpha * dense_score + (1 - alpha) * sparse_score, e opera su punteggi normalizzati invece che sulle posizioni. Può riflettere meglio l'entità della confidenza (un hit vettoriale a 0,95 di similarità sembra genuinamente più forte di uno a 0,61), ma richiede di regolare alpha per ogni corpus, e quel tuning si rompe in silenzio quando la distribuzione dei punteggi cambia (nuovo modello di embedding, corpus reindicizzato, mix di query diverso).

In pratica, la scelta dipende da quanto ti fidi della calibrazione dei tuoi punteggi. Usando BM25 standard contro un singolo modello di embedding stabile, la pesatura con alpha può strappare un ranking leggermente migliore perché usa il divario reale tra i punteggi, non solo la posizione. Ma quella calibrazione deriva più di quanto ci si aspetti. Cambi versione del modello di embedding, rifai il chunking dei documenti o aggiungi un passaggio di reranking a monte, e la distribuzione dei punteggi densi cambia. Nessuno viene svegliato di notte quando alpha=0,6 smette di essere il valore giusto; il ranking peggiora appena, in silenzio, ed è facile non accorgersene se non esegui regolarmente valutazioni sul retrieval. La RRF aggira del tutto il problema perché non guarda mai i punteggi grezzi, solo la posizione in classifica, quindi una reindicizzazione o un cambio di modello non può romperla in silenzio come può fare con la pesatura alpha.

La RRF non richiede tuning per corpus; la pesatura con alpha richiede manutenzione continua man mano che i dati cambiano.

I motori si dividono sui default. Weaviate espone sia la RRF sia un parametro alpha che imposti esplicitamente. Elasticsearch include la RRF nativa tramite la sua API retriever (verifica l'esatto vincolo di versione nel tuo deployment: è arrivata con la linea 8.x). Qdrant supporta la RRF in modo nativo tramite la sua Query API. La funzione ibrida di Pinecone in genere si appoggia a una combinazione convessa pesata con alpha invece di esporre direttamente la RRF. Se non sai quale scegliere, parti dalla RRF: è il default che richiede meno manutenzione.

RRF da zero: un esempio Python indipendente dai vendor

Tutti gli esempi di codice RRF che abbiamo trovato nelle guide concorrenti sono legati all'SDK di un vendor: il client di Weaviate, il client di Qdrant, il client di Pinecone. Ecco una versione senza framework che puoi inserire in qualsiasi stack, con k=60 come default standard:

def reciprocal_rank_fusion(result_lists, k=60):
    """
    result_lists: list of ranked lists, each a list of document IDs
                  ordered from most to least relevant.
    k: RRF constant (60 is the standard default from Cormack et al., 2009).
    Returns: list of (doc_id, fused_score) sorted descending by score.
    """
    scores = {}
    for result_list in result_lists:
        for rank, doc_id in enumerate(result_list, start=1):
            scores[doc_id] = scores.get(doc_id, 0.0) + 1.0 / (k + rank)
    return sorted(scores.items(), key=lambda item: item[1], reverse=True)

# Example usage:
bm25_hits = ["doc_9", "doc_2", "doc_14", "doc_1"]
vector_hits = ["doc_2", "doc_1", "doc_9", "doc_30"]

fused = reciprocal_rank_fusion([bm25_hits, vector_hits])
for doc_id, score in fused:
    print(f"{doc_id}: {score:.4f}")

Questo è l'intero algoritmo. Niente SDK, nessun lock-in verso vendor, e funziona sia che le tue due liste ordinate arrivino da Elasticsearch e un indice Faiss, sia da Postgres ts_rank e pgvector. Se esegui i modelli in proprio invece di chiamare un'API, vedi eseguire i modelli di embedding in locale con Ollama.

Postgres + pgvector: ricerca ibrida senza un database vettoriale dedicato

Non serve un database vettoriale dedicato per fare ricerca ibrida. Secondo un benchmark pg_textsearch/pgvector dello sviluppatore Pedro Alonso (Postgres 17, pg_textsearch 1.3.0, pgvector 0.8.2, embedding nomic-embed-text, dataset BEIR SciFact), una singola istanza Postgres con ts_rank nativo ha totalizzato appena 0,07 di NDCG@10, molto dietro lo 0,69 di BM25, lo 0,66 di pgvector e lo 0,70 dell'ibrida, tutto in una sola istanza, con la RRF ibrida a circa 11,5 ms di mediana.

Quel valore 0,07 è il segnale rivelatore: il ts_rank integrato in Postgres è un ranker basato sulla densità delle occorrenze, non un vero BM25. Se vuoi un punteggio BM25 reale in Postgres, ti serve un'estensione. pg_textsearch, VectorChord e ParadeDB aggiungono tutte un ranking in stile BM25 vero, che il ts_rank nativo non offre. Abbina una di queste a pgvector per la similarità densa, fondi le due liste ordinate con la funzione RRF qui sopra, e hai la ricerca ibrida in una singola istanza Postgres, senza alcuna infrastruttura separata da gestire.

Ecco più o meno come appare quell'abbinamento in una singola query, combinando un ranking lessicale di un'estensione con supporto BM25 con una distanza vettoriale di pgvector:

WITH lexical AS (
  SELECT id, ts_rank_cd(body_tsv, query) AS rank
  FROM documents, plainto_tsquery('english', 'refund policy') query
  WHERE body_tsv @@ query
  ORDER BY rank DESC LIMIT 50
),
semantic AS (
  SELECT id, embedding <=> '[0.012, -0.045, ...]' AS distance
  FROM documents
  ORDER BY distance LIMIT 50
)
SELECT * FROM lexical
FULL OUTER JOIN semantic USING (id);

Dai entrambi i set di risultati in pasto alla funzione RRF qui sopra e hai la ricerca ibrida in una sola istanza Postgres. Il limite, onestamente: regge bene fino a qualche milione di righe, ma Postgres non è nato come motore di retrieval dedicato. Il tuning degli indici è a tuo carico, il semplice ts_rank_cd non è comunque un vero BM25 senza un'estensione, e non hai il reranking integrato né il supporto multi-vettoriale che Weaviate o Milvus offrono nativamente. Se il tuo corpus è piccolo o medio e usi già Postgres, così ti risparmi un'intera seconda infrastruttura. Oltre le decine di milioni di documenti, o se ti serve un reranking avanzato, un motore dedicato si ripaga da solo.

Se stai valutando Qdrant, Chroma o pgvector per il tuo stack in senso più ampio, è una decisione separata da quella sul metodo di fusione. Vedi il nostro confronto tra Qdrant, Chroma e pgvector per i compromessi.

Quali database vettoriali supportano la ricerca ibrida nativa?

La maggior parte dei database vettoriali moderni oggi include la ricerca ibrida già pronta all'uso, ma il metodo di fusione predefinito differisce in modo significativo.

Verifica l'esatto vincolo di versione prima di impegnarti. Le funzioni ibride sono arrivate rapidamente su questi motori nel corso del 2026, e la forma delle API cambia da una release all'altra. Per una decisione d'acquisto più ampia che vada oltre la meccanica di fusione, vedi la nostra classifica completa dei migliori database vettoriali.

Vale la pena la complessità della ricerca ibrida?

La ricerca ibrida è architettonicamente corretta quando il tuo corpus ha sia schemi a corrispondenza esatta (SKU, ID, termini rari) sia query concettuali e riformulate. Se il tuo corpus non ha né gli uni né le altre (contenuti puramente narrativi, nessun identificatore che qualcuno cerchi come stringa letterale), potresti aggiungere complessità di fusione per un guadagno che noterai a malapena.

Pensa a come appare in pratica un corpus "solo narrativo": l'archivio del blog aziendale, un wiki interno di engineering pieno di runbook scritti per esteso, un sito di documentazione che nessuno cerca per ID prodotto o numero di ticket. In quei corpus, la sola ricerca vettoriale di solito ti dà la maggior parte del valore, e il passaggio di fusione aggiunge solo un secondo retrieval e un parametro di cui qualcuno ora è responsabile, per un guadagno che si arrotonda a rumore. Confrontalo con un sistema di ticketing di supporto o un catalogo e-commerce, dove SKU, numeri d'ordine e codici modello compaiono di continuo nelle query degli utenti reali. Questo è il vero test: estrai dieci query reali dai tuoi log e conta quante contengono un identificatore esatto che un modello di embedding basato sulle parafrasi non posizionerebbe mai correttamente. Zero? Salta l'ibrida. Più di una o due? Costruiscila.

La ricerca ibrida non è un upgrade universale: se il tuo corpus non ha SKU, ID o ricerche di termini rari, potresti aggiungere complessità di fusione per un guadagno che non noterai mai.

Il costo è reale ma contenuto: un secondo passaggio di retrieval, un passaggio di fusione e un parametro di peso di cui qualcuno ora è responsabile. Qui evitiamo deliberatamente di citare una cifra sulla latenza, perché i numeri che circolano provengono da setup senza nome su hardware senza nome, e i tuoi saranno diversi. Misurala sul tuo corpus prima di decidere. Due thread di Hacker News catturano bene la tensione reale tra i practitioner: "Hybrid Search Is Just the Beginning: Optimizing the R in RAG" e "Better RAG Results with Reciprocal Rank Fusion and Hybrid Search". Entrambi gli thread contestano l'adozione dell'ibrida come best practice cargo cult, senza prima verificare se il tuo corpus abbia davvero gli schemi di query che dovrebbe risolvere. Prima di costruirla, vale la pena capire come misurare davvero la qualità del retrieval: i numeri di NDCG e recall@k hanno senso solo rispetto al tuo corpus, non rispetto a un dataset di benchmark.

La nostra posizione: per qualsiasi sistema RAG che gestisca query di supporto agli utenti, e-commerce o ticketing, parti dall'ibrida. Quei carichi di lavoro mescolano quasi sempre identificatori e linguaggio naturale. Saltala per i corpus solo narrativi (documenti lunghi, wiki discorsivi) finché non hai misurato un divario reale che il retrieval a metodo singolo lascia aperto.

Domande frequenti

Cos'è la ricerca ibrida nel RAG?

La ricerca ibrida esegue il retrieval BM25 (parole chiave) e quello vettoriale (semantico) come passaggi separati sulla stessa query, poi fonde le due liste ordinate con un algoritmo di fusione, di solito la Reciprocal Rank Fusion. Cattura sia le query a corrispondenza esatta sia quelle concettuali riformulate, che nessuno dei due metodi gestisce da solo.

BM25 è la stessa cosa della ricerca vettoriale?

No. BM25 è una ricerca lessicale sparsa che assegna un punteggio alla sovrapposizione e alla rarità esatte dei termini. La ricerca vettoriale è una ricerca semantica densa che usa embedding e matematica della similarità. Sono due metodi di retrieval diversi con punti di forza opposti: la ricerca ibrida li combina, non ne sostituisce nessuno dei due.

Come si combinano BM25 e ricerca vettoriale?

Esegui entrambi i metodi di retrieval in modo indipendente sulla stessa query, poi fondi le due liste di risultati ordinate, il più delle volte con la Reciprocal Rank Fusion, che somma 1 / (k + rank) su ciascuna lista. La combinazione di punteggi pesata con alpha è l'alternativa, ma richiede un tuning per corpus che la RRF non richiede.

Cos'è la Reciprocal Rank Fusion (RRF)?

La RRF è un algoritmo di fusione del paper SIGIR del 2009 di Cormack, Clarke e Buettcher che combina più liste ordinate sommando 1 / (k + rank) per ciascun documento, con k in genere impostato a 60. Lavora sulla posizione in classifica, non sui punteggi grezzi, quindi resta stabile anche con disallineamenti di scala tra metodi di retrieval diversi.

Che differenza c'è tra RRF e fusione pesata con alpha?

La RRF combina le posizioni e non richiede tuning per corpus. La fusione pesata con alpha combina punteggi normalizzati usando un parametro alpha regolabile, che può riflettere meglio l'entità della confidenza ma richiede una ricalibrazione continua ogni volta che la distribuzione dei punteggi cambia, ad esempio dopo una reindicizzazione o un cambio di modello.

Quando dovrei usare la ricerca ibrida invece della sola ricerca vettoriale?

Usa la ricerca ibrida quando le tue query mescolano identificatori esatti (SKU, numeri d'ordine, codici di errore) e domande concettuali in linguaggio naturale: supporto, e-commerce e sistemi di ticketing in genere lo fanno. Saltala per i contenuti solo narrativi senza identificatori, dove la complessità di fusione aggiunta probabilmente non mostrerà alcun guadagno misurabile.

Perché la ricerca vettoriale perde le corrispondenze esatte come SKU o codici di errore?

I modelli di embedding imparano da schemi linguistici generali, e stringhe come "SKU-4471" o "ERR_CONN_RST" compaiono di rado come concetti distinti e isolati nei dati di addestramento. Il modello non ha un motivo forte per posizionare quella stringa esatta più vicina a sé rispetto a un token semanticamente correlato ma sbagliato.

Quali database vettoriali supportano la ricerca ibrida in modo nativo?

Weaviate, Qdrant, Elasticsearch, OpenSearch, Vespa e Milvus includono tutti la ricerca ibrida nativa nel 2026, anche se i loro metodi di fusione predefiniti differiscono (RRF vs pesata con alpha vs normalizzazione). Postgres con pgvector può anch'esso eseguire la ricerca ibrida, ma serve un'estensione BM25 perché il ts_rank nativo non è un vero BM25.

Vale la pena la complessità aggiunta della ricerca ibrida?

Per i corpus che mescolano query a corrispondenza esatta e concettuali, sì. La RRF semplice batte già entrambi i metodi singoli sul benchmark WANDS (0,7068 contro lo 0,6983 di BM25), e una variante ottimizzata raggiunge un guadagno del 7,4% (0,7497). Per i corpus solo narrativi senza identificatori, il secondo passaggio di retrieval e il tuning della fusione che richiede possono pesare più di un guadagno che non noterai. Misura prima di impegnarti.

Postgres/pgvector può fare ricerca ibrida senza un database vettoriale dedicato?

Sì. Abbina pgvector per la similarità densa a una vera estensione BM25 come pg_textsearch, VectorChord o ParadeDB (il solo ts_rank nativo ha totalizzato appena 0,07 di NDCG@10 nel benchmark pg_textsearch/pgvector di Pedro Alonso, contro lo 0,70 dell'ibrida), poi fondi le due liste ordinate con la RRF, tutto dentro una singola istanza Postgres.

Entrambi i metodi di retrieval, eseguiti da soli, lasciano lacune reali: BM25 perde le parafrasi, la ricerca vettoriale perde gli identificatori esatti, e fonderli con la RRF è il modo che richiede meno manutenzione per chiuderle entrambe. Se stai valutando se costruirlo in proprio o coinvolgere un team che ha già portato in produzione retrieval RAG, la nostra guida completa per costruire un'applicazione RAG copre il passo successivo, oppure contattaci se preferisci che Techsy lo costruisca con te.