Hybrid sökning: BM25 vs vektor (och varför du behöver båda)

Hybrid sökning: BM25 vs vektor (och varför du behöver båda)

En supportagent skriver "SKU-4471" i din RAG-chattbot. Fyra resultat kommer tillbaka. Alla självsäkert fel. En generell embeddingmodell har ingen anledning att placera exakt den strängen nära sig själv i vektorrymden. Just den felmoden är anledningen till att hybrid sökning finns, och det är därför team gång på gång ställer samma fråga: hur kombinerar man egentligen BM25 och vektorsökning utan att ägna evigheter åt att vrida på en inställningsratt?

Om du utvärderar RAG-verktyg mer brett täcker vår roundup av de bästa RAG-verktygen hela stacken runt omkring.

Det viktigaste

• BM25 hittar exakta nyckelordsmatchningar (SKU:er, felkoder); vektorsökning hittar konceptuellt liknande text, inte identiska strängar.
• Hybrid sökning kombinerar båda, oftast via Reciprocal Rank Fusion (RRF), och slår endera metoden ensam på blandade frågelaster.
• På WANDS-benchmarket når ren RRF 0,7068 NDCG (mot BM25:s 0,6983); trimning lyfter det till 0,7497, en ökning med 7,4 %.
• Postgres/pgvector kan köra hybrid sökning direkt via ts_rank + pgvector, utan någon dedikerad vektordatabas.

Vad är hybrid sökning? (BM25 + vektor, kombinerat)

Hybrid sökning kör BM25 och vektorsökning som två separata hämtningspass över samma fråga och slår sedan samman de två rangordnade resultatlistorna till en enda lista med en fusionsalgoritm, oftast Reciprocal Rank Fusion. Det är inte en tredje hämtningsmetod; det är ett orkestreringslager ovanpå två befintliga.

Den distinktionen spelar roll, eftersom en hel del söktrafik kring ämnet blandar ihop BM25 och vektorsökning som om de vore samma sak. Det är de inte. BM25 är en gles, nyckelordsbaserad poängfunktion med rötter i 1970-talets informationshämtning. Vektorsökning är tät, embeddingbaserad likhetssökning som först blev praktisk i stor skala under det senaste decenniet. Hybrid sökning behandlar dem som kompletterande ingångar, inte konkurrerande tekniker, och fusionerar deras resultat i stället för att utse en vinnare på förhand.

BM25 vs vektor vs hybrid: snabb jämförelse

På WANDS e-handelsbenchmark nådde BM25 ensamt 0,6983 NDCG och vektorsökning ensam 0,6953 (nästan oavgjort). Ren RRF-fusion, utan korpus-specifik trimning, nådde 0,7068, en blygsam ökning med 1,2 % jämfört med enbart BM25. Doug Turnbulls benchmark testade också en trimmad variant som lägger en produktnamnsboost ovanpå RRF, och den versionen nådde 0,7497, en ökning med 7,4 %. Var ärlig med vilket tal du citerar: enbart RRF ger en liten men verklig fördel direkt ur lådan; det större 7,4 %-talet krävde extra domänspecifik trimning som de flesta team hoppar över dag ett. Varken BM25 eller vektorsökning dominerar på egen hand; de täcker olika felmoder, och fusionerar man dem täpper man igen båda hålen samtidigt.

BM25-mekanik: så poängsätter nyckelordssökning relevans

BM25 poängsätter dokument efter termfrekvens, viktat mot hur sällsynt termen är i hela korpusen, och normaliserar sedan för dokumentlängd. Robertson och Zaragoza lade fram denna formalisering i sin artikel från 2009, "The Probabilistic Relevance Framework: BM25 and Beyond". Det är en förfining av TF-IDF, inte en ersättning.

Två parametrar styr det mesta av BM25:s beteende. k1 (vanligtvis 1,2-2,0) styr termfrekvensmättnad: den sätter ett tak för hur mycket upprepning av ett ord höjer poängen, så att ett dokument som säger "faktura" 40 gånger inte automatiskt slår ett som säger det 4 gånger i ett tajtare, mer relevant stycke. b (standard 0,75) styr dokumentlängdsnormalisering: den avgör hur hårt BM25 bestraffar långa dokument för att de naturligt innehåller fler termmatchningar.

Att sätta b fel är ett vanligt, verkligt trimmisstag. Korta tekniska dokument (felloggar, produkttitlar) vill ha ett lägre b eftersom längdvariationen är liten; långt innehåll (dokumentationssidor, artiklar) vill oftast ha b närmare standardvärdet. BM25:s kärnsvaghet är ordförrådsmismatch: om en användare frågar "hur får jag tillbaka mina pengar" och dokumentet bara säger "återbetalningspolicy" hittar BM25 noll gemensamma tokens och returnerar inget användbart.

Mekanik för tät vektorsökning (och var den brister)

Vektorsökning avbildar text i embeddingar med fast dimension med hjälp av en modell och hittar sedan närliggande vektorer via cosinuslikhet eller skalärprodukt, vanligtvis accelererat av ett approximativt närmaste-granne-index. HNSW är den dominerande algoritmen hos Weaviate, Qdrant och Milvus, och byter bort en liten del av recall mot stora hastighetsvinster i skala.

Det är det här som löser BM25:s ordförrådsproblem: "få tillbaka mina pengar" och "återbetalningspolicy" hamnar nära varandra i embeddingrymden trots noll gemensamma tokens, eftersom modellen fångar betydelse, inte ytform. Att välja rätt modell spelar stor roll här. Se vår guide om att välja rätt embeddingmodell och vår genomgång av hur vi jämförde Voyage-, OpenAI- och Cohere-embeddingar om du väger alternativ.

Men tät hämtning har sin egen blinda fläck, och den är spegelbilden av BM25:s. När vi bygger RAG-system åt kunder är den exakt-matchning-felmod vi oftast stöter på inte exotisk. Det är en supportagent som frågar efter ett specifikt ordernummer eller en SKU, och vektorindexet som självsäkert returnerar något semantiskt liknande men fel. En generell embeddingmodell har ingen anledning att placera "SKU-4471" eller "ERR_CONN_RST" nära sig själv i vektorrymden jämfört med en besläktad men felaktig token, eftersom strängar som de sällan dyker upp som distinkta, isolerade koncept i träningsdata. BigData Boutique dokumenterar exakt detta felmönster med egna SKU- och felkodsexempel. Det är ett väletablerat, oberoende styrkt fenomen i RAG-drift, inte en engångsgrej.

Så kombinerar du BM25 och vektorsökning: RRF vs alfaviktad fusion

Det finns två verkliga sätt att fusionera BM25- och vektorresultat, och nästan ingen som skriver om hybrid sökning ställer dem tydligt mot varandra. Reciprocal Rank Fusion (RRF), från Cormack, Clarke och Buettchers SIGIR-artikel 2009, arbetar med rang: score = sum(1 / (k + rank_i)) över varje resultatlista, med k vanligtvis satt till 60. Eftersom den bara bryr sig om position, inte rå poäng, hanterar RRF skalningsskillnader mellan BM25:s obegränsade poäng och cosinuslikhetens 0-till-1-intervall utan klagomål, och den behöver ingen korpus-specifik trimning.

Alfaviktad (konvex) fusion fungerar annorlunda: final = alpha * dense_score + (1 - alpha) * sparse_score, och arbetar med normaliserade poäng i stället för rang. Den kan spegla konfidensens storlek bättre (en vektorträff på 0,95 likhet ser genuint starkare ut än en på 0,61), men den kräver att man trimmar alfa per korpus, och den trimningen brister tyst när poängfördelningen förskjuts (ny embeddingmodell, omindexerad korpus, annan frågeblandning).

I praktiken handlar valet om hur mycket du litar på din poängkalibrering. Kör man vanlig BM25 mot en enda stabil embeddingmodell kan alfaviktning pressa ut en något bättre rangordning eftersom den använder det faktiska poängavståndet, inte bara positionen. Men den kalibreringen driver iväg mer än man tror. Byt till en ny version av embeddingmodellen, chunka om dokumenten eller lägg till ett reranking-pass uppströms, så förskjuts din täta poängfördelning. Ingen blir uppringd när alpha=0.6 slutar vara rätt värde; rangordningen blir bara tyst lite sämre, och det är lätt att missa om man inte kör hämtningsevalueringar regelbundet. RRF kringgår detta helt eftersom den aldrig tittar på råa poäng, bara rangposition, så en omindexering eller ett modellbyte kan inte bryta den tyst på det sätt alfaviktning kan.

RRF behöver ingen trimning per korpus; alfaviktning behöver ständig passning när datan förändras.

Motorerna skiljer sig åt i standardval. Weaviate erbjuder både RRF och en alpha-parameter du sätter explicit. Elasticsearch skeppar inbyggd RRF via sitt retriever-API (kontrollera exakt versionsavgränsning i din distribution; detta landade i 8.x-serien). Qdrant stöder RRF direkt via sitt Query API. Pinecones hybridfunktion lutar sig vanligtvis mot alfaviktad konvex kombination i stället för att erbjuda RRF direkt. Är du osäker på vilken du ska ta, börja med RRF. Det är det underhållssnålaste standardvalet.

RRF från grunden: ett leverantörsoberoende Python-exempel

Varje RRF-kodexempel vi hittade i konkurrerande guider är låst till en leverantörs SDK: Weaviates klient, Qdrants klient, Pinecones klient. Här är en ramverksfri version du kan släppa in i vilken stack som helst, med k=60 som 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}")

Det är hela algoritmen. Ingen SDK, ingen leverantörsinlåsning, och den fungerar oavsett om dina två rangordnade listor kom från Elasticsearch och ett Faiss-index, eller från Postgres ts_rank och pgvector. Kör du modeller själv i stället för att anropa ett API, se köra embeddingmodeller lokalt med Ollama.

Postgres + pgvector: hybrid sökning utan en dedikerad vektordatabas

Du behöver ingen dedikerad vektordatabas för att köra hybrid sökning. Enligt ett pg_textsearch/pgvector-benchmark av utvecklaren Pedro Alonso (Postgres 17, pg_textsearch 1.3.0, pgvector 0.8.2, nomic-embed-text-embeddingar, BEIR SciFact-datasetet) nådde en enda Postgres-instans med inbyggd ts_rank bara 0,07 NDCG@10, långt efter BM25:s 0,69, pgvectors 0,66 och hybridens 0,70, allt i en instans, där hybrid-RRF landade runt 11,5 ms median.

Just 0,07-talet avslöjar saken: Postgres inbyggda ts_rank är en täthetsbaserad rankare, inte riktig BM25. Vill du ha riktig BM25-poängsättning i Postgres behöver du ett tillägg. pg_textsearch, VectorChord och ParadeDB tillför alla riktig BM25-liknande rangordning som inbyggd ts_rank inte erbjuder. Para ett av dem med pgvector för tät likhet, fusionera de två rangordnade listorna med RRF-funktionen ovan, så har du hybrid sökning i en enda Postgres-instans utan extra infrastruktur att driva.

Så här ser ungefär den parningen ut i en enda fråga, där ett lexikalt rang från ett BM25-kapabelt tillägg kombineras med ett vektoravstånd från 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);

Mata in båda resultatmängderna i RRF-funktionen ovan så har du hybrid sökning i en Postgres-instans. Den ärliga begränsningen: det håller bra en bit in i miljoner rader, men Postgres är inte byggt som en dedikerad hämtningsmotor. Du äger din egen indextrimning, vanlig ts_rank_cd är fortfarande inte riktig BM25 utan ett tillägg, och du får inte den inbyggda rerankingen eller multivektor-stödet som Weaviate eller Milvus skeppar direkt. Är din korpus liten till medelstor och du redan kör Postgres sparar detta en hel andra infrastrukturbit. Förbi tiotals miljoner dokument, eller om du behöver avancerad reranking, tjänar en dedikerad motor sitt pris.

Väger du Qdrant, Chroma eller pgvector för din stack mer brett är det ett separat beslut från själva fusionsmetoden. Se vår jämförelse av Qdrant, Chroma och pgvector för avvägningarna.

Vilka vektordatabaser stöder inbyggd hybrid sökning?

De flesta moderna vektordatabaser skeppar nu hybrid sökning direkt, men fusionsmetoden de väljer som standard skiljer sig åt i praktiken.

Verifiera exakt versionsavgränsning innan du bestämmer dig. Hybridfunktioner har landat snabbt i motorerna under 2026, och API-formerna skiftar mellan versioner. För ett bredare köpbeslut utöver fusionsmekaniken, se vår fullständiga roundup av de bästa vektordatabaserna.

Är hybrid sökning värt komplexiteten?

Hybrid sökning är arkitektoniskt korrekt när din korpus har både exakt-matchningsmönster (SKU:er, ID:n, sällsynta termer) och konceptuella, parafraserade frågor. Har din korpus ingetdera (rent berättande innehåll, inga identifierare någon söker på som literal sträng) lägger du kanske till fusionskomplexitet för en vinst du knappt märker.

Tänk efter hur "bara berättande" faktiskt ser ut: ett företagsbloggsarkiv, en intern teknikwiki full av prosatunga runbooks, en dokumentationssajt ingen söker på med produkt-ID eller ärendenummer. I de korpusarna räcker vektorsökning ensam oftast för det mesta av värdet, och fusionssteget lägger bara till ett andra hämtningspass och en parameter någon nu äger, för en vinst som avrundas till brus. Jämför det med ett ärendehanteringssystem eller en e-handelskatalog, där SKU:er, ordernummer och modellkoder dyker upp i riktiga användarfrågor hela tiden. Det är det verkliga testet: dra tio riktiga frågor ur dina egna loggar och räkna hur många som innehåller en exakt identifierare som en parafrasbaserad embeddingmodell aldrig skulle placera rätt. Noll, hoppa över hybrid. Mer än en eller två, bygg det.

Hybrid sökning är ingen universell uppgradering; har din korpus inga SKU:er, ID:n eller sällsynta termuppslagningar lägger du kanske till fusionskomplexitet för en vinst du aldrig märker.

Kostnaden är verklig men begränsad: ett andra hämtningspass, ett fusionssteg och en viktningsparameter någon nu äger. Vi citerar medvetet ingen latenssiffra här, eftersom talen som cirkulerar kommer från namnlösa setup:er på namnlös hårdvara, och dina kommer att skilja sig. Mät på din egen korpus innan du bestämmer dig. Två Hacker News-trådar fångar den verkliga utövarspänningen här: "Hybrid Search Is Just the Beginning: Optimizing the R in RAG" och "Better RAG Results with Reciprocal Rank Fusion and Hybrid Search". Båda trådarna ifrågasätter att man tar till sig hybrid som en cargo-cult-bästa-praxis utan att först kontrollera om korpusen ens har de frågemönster metoden är avsedd att lösa. Innan du bygger det är det värt att förstå hur man faktiskt mäter hämtningskvalitet: NDCG- och recall@k-tal betyder bara något mot din egen korpus, inte mot ett benchmark-dataset.

Vår slutsats: välj hybrid som standard för alla RAG-system som hanterar kundsupport, e-handel eller ärendefrågor. De lasterna blandar nästan alltid identifierare med naturligt språk. Hoppa över det för rent berättande korpusar (långformsdokument, berättande wikier) tills du har mätt ett verkligt gap som enmetodshämtning lämnar öppet.

Vanliga frågor

Vad är hybrid sökning i RAG?

Hybrid sökning kör BM25 (nyckelord) och vektor (semantisk) hämtning som separata pass över samma fråga och slår sedan samman de två rangordnade listorna med en fusionsalgoritm, oftast Reciprocal Rank Fusion. Den fångar både exakt-matchningsfrågor och parafraserade konceptuella frågor, vilket ingen av metoderna klarar ensam.

Är BM25 samma sak som vektorsökning?

Nej. BM25 är gles lexikal sökning som poängsätter exakt termöverlapp och sällsynthet. Vektorsökning är tät semantisk sökning med embeddingar och likhetsmatematik. De är två olika hämtningsmetoder med motsatta styrkor; hybrid sökning kombinerar i stället för att ersätta någon av dem.

Hur kombinerar man BM25 och vektorsökning?

Kör båda hämtningsmetoderna oberoende på samma fråga och fusionera sedan de två rangordnade resultatlistorna, oftast med Reciprocal Rank Fusion, som summerar 1 / (k + rank) över varje lista. Alfaviktad poängkombination är alternativet, men den kräver korpus-specifik trimning som RRF inte gör.

Vad är Reciprocal Rank Fusion (RRF)?

RRF är en fusionsalgoritm från Cormack, Clarke och Buettchers SIGIR-artikel 2009 som kombinerar flera rangordnade listor genom att summera 1 / (k + rank) för varje dokument, med k vanligtvis satt till 60. Den arbetar med rangposition, inte råa poäng, och förblir därför stabil över skalningsskillnader mellan hämtningsmetoder.

Vad är skillnaden mellan RRF och alfaviktad fusion?

RRF kombinerar rang och behöver ingen korpus-specifik trimning. Alfaviktad fusion kombinerar normaliserade poäng med en justerbar alfa-parameter, vilket kan spegla konfidensens storlek bättre men kräver löpande omtrimning när poängfördelningen förskjuts, exempelvis efter en omindexering eller ett modellbyte.

När bör jag använda hybrid sökning i stället för enbart vektorsökning?

Använd hybrid sökning när dina frågor blandar exakta identifierare (SKU:er, ordernummer, felkoder) med konceptuella frågor på naturligt språk; support, e-handel och ärendehantering gör det oftast. Hoppa över det för rent berättande innehåll utan identifierare, där den extra fusionskomplexiteten troligen inte ger en mätbar vinst.

Varför missar vektorsökning exakta matchningar som SKU:er eller felkoder?

Embeddingmodeller lär sig från allmänna språkmönster, och strängar som "SKU-4471" eller "ERR_CONN_RST" dyker sällan upp som distinkta, isolerade koncept i träningsdata. Modellen har ingen stark anledning att placera exakt den strängen närmare sig själv än en semantiskt besläktad men felaktig token.

Vilka vektordatabaser stöder hybrid sökning direkt?

Weaviate, Qdrant, Elasticsearch, OpenSearch, Vespa och Milvus skeppar alla inbyggd hybrid sökning från och med 2026, men deras standardfusionsmetoder skiljer sig åt (RRF vs alfaviktad vs normalisering). Postgres med pgvector kan också köra hybrid sökning, men behöver ett BM25-tillägg eftersom inbyggd ts_rank inte är riktig BM25.

Är hybrid sökning värt den ökade komplexiteten?

För korpusar som blandar exakta matchningar och konceptuella frågor, ja. Ren RRF slår redan endera ensam metod på WANDS-benchmarket (0,7068 mot BM25:s 0,6983), och en trimmad variant når en ökning med 7,4 % (0,7497). För rent berättande korpusar utan identifierare kan det andra hämtningspasset och fusionstrimningen det kräver väga tyngre än en vinst du inte märker. Mät innan du bestämmer dig.

Kan Postgres/pgvector köra hybrid sökning utan en dedikerad vektordatabas?

Ja. Para pgvector för tät likhet med ett riktigt BM25-tillägg som pg_textsearch, VectorChord eller ParadeDB (enbart inbyggd ts_rank nådde bara 0,07 NDCG@10 i Pedro Alonsos pg_textsearch/pgvector-benchmark, mot 0,70 för hybrid) och fusionera sedan de två rangordnade listorna med RRF, allt i en enda Postgres-instans.

Båda hämtningsmetoderna lämnar verkliga luckor när de körs ensamma: BM25 missar parafraser, vektorsökning missar exakta identifierare, och att fusionera dem med RRF är det underhållssnålaste sättet att täppa igen båda. Om du väger att bygga detta själv eller ta in ett team som har levererat RAG-hämtning tidigare, täcker vår fullständiga guide om att bygga en RAG-applikation nästa steg, eller hör av dig om du hellre vill att Techsy bygger det med dig.