Hybridsøgning: BM25 vs. vektor (og hvorfor du har brug for begge)

Hybridsøgning: BM25 vs. vektor (og hvorfor du har brug for begge)

En supportmedarbejder skriver „SKU-4471" i jeres RAG-chatbot. Fire resultater kommer tilbage. Alle sammen skråsikkert forkerte. En generel embeddingmodel har ingen grund til at placere den præcise streng tæt på sig selv i vektorrummet. Netop denne fejltype er grunden til, at hybridsøgning findes, og det er derfor, teams bliver ved med at stille det samme specifikke spørgsmål: hvordan kombinerer man egentlig BM25 og vektorsøgning uden at skulle passe på en finjusteringsknap for evigt?

Hvis du evaluerer RAG-værktøjer mere bredt, dækker vores roundup af de bedste RAG-værktøjer den omkringliggende stack.

Hovedpointer

• BM25 finder præcise nøgleordstræf (SKU'er, fejlkoder); vektorsøgning finder konceptuelt lignende tekst, ikke identiske strenge.
• Hybridsøgning kombinerer begge dele, typisk via Reciprocal Rank Fusion (RRF), og slår begge metoder alene på blandede forespørgselslaster.
• På WANDS-benchmarket scorer ren RRF 0,7068 NDCG (mod 0,6983 for BM25); finjustering løfter den til 0,7497, en forbedring på 7,4 %.
• Postgres/pgvector kan køre hybridsøgning nativt via ts_rank + pgvector, uden en dedikeret vektordatabase.

Hvad er hybridsøgning? (BM25 + vektor kombineret)

Hybridsøgning kører BM25 og vektorsøgning som to separate genfindingspass over den samme forespørgsel og merger derefter de to rangerede resultatlister til ét output med en fusionsalgoritme, oftest Reciprocal Rank Fusion. Det er ikke en tredje genfindingsmetode; det er et orkestreringslag oven på to eksisterende.

Den skelnen betyder noget, fordi en pæn del af søgetrafikken om dette emne sidestiller BM25 og vektorsøgning, som om de var det samme. Det er de ikke. BM25 er en sparse, nøgleordsbaseret scorefunktion med rødder i informationsgenfinding fra 1970'erne. Vektorsøgning er tæt, embeddingbaseret lighedssøgning, som først blev praktisk i stor skala inden for det seneste årti. Hybridsøgning behandler dem som komplementære input, ikke konkurrerende teknikker, og fusionerer deres output i stedet for at kåre en vinder på forhånd.

BM25 vs. vektor vs. hybridsøgning: hurtig sammenligning

På WANDS-e-handelsbenchmarket scorede BM25 alene 0,6983 NDCG, og vektorsøgning alene scorede 0,6953 (næsten uafgjort). Ren RRF-fusion uden korpus-specifik finjustering nåede 0,7068, en beskeden forbedring på 1,2 % over BM25 alene. Doug Turnbulls benchmark testede også en finjusteret variant, der lægger et produktnavnsboost oven på RRF, og den version nåede 0,7497, en forbedring på 7,4 %. Det er værd at være ærlig om, hvilket tal man citerer: RRF alene giver en lille, reel fordel fra start; det større tal på 7,4 % krævede ekstra domænespecifik finjustering, som de fleste teams springer over på dag ét. Hverken BM25 eller vektorsøgning dominerer alene; de dækker forskellige fejltyper, og fusionerer man dem, lukker man begge huller på én gang.

BM25-mekanik: sådan scorer nøgleordssøgning faktisk relevans

BM25 scorer dokumenter efter termfrekvens, vægtet mod hvor sjælden termen er i hele korpusset, og normaliseret for dokumentlængde. Robertson og Zaragoza lagde denne formalisering frem i deres artikel fra 2009, „The Probabilistic Relevance Framework: BM25 and Beyond". Den er en forfining af TF-IDF, ikke en erstatning.

To parametre styrer det meste af BM25's opførsel. k1 (typisk 1,2-2,0) styrer termfrekvensmætning: den sætter et loft over, hvor meget gentagelse af et ord løfter en score, så et dokument, der nævner „invoice" 40 gange, ikke automatisk rangerer over et, der nævner det 4 gange i et strammere, mere relevant afsnit. b (standard 0,75) styrer dokumentlængdenormalisering: den bestemmer, hvor hårdt BM25 straffer lange dokumenter for naturligt at indeholde flere termtræf.

At ramme forkert med b er en reel, udbredt finjusteringsfejl. Korte tekniske dokumenter (fejllogs, produkttitler) vil have et lavere b, da længdevariansen er lille; langt indhold (dokumentationssider, artikler) vil typisk have b tættere på standarden. BM25's kernemangel er mismatch i ordforrådet: hvis en bruger spørger „hvordan får jeg mine penge tilbage", og dokumentet kun nævner „refund policy", finder BM25 nul fælles tokens og returnerer intet brugbart.

Mekanikken bag tæt vektorsøgning (og hvor den fejler)

Vektorsøgning afbilder tekst i embeddinger med fast dimension via en model og finder derefter nærliggende vektorer med cosinus-lighed eller prikprodukt, typisk accelereret af et omtrentlig nærmeste-nabo-indeks. HNSW er den dominerende algoritme hos Weaviate, Qdrant og Milvus og bytter en smule recall væk for store hastighedsgevinster i skala.

Det er det, der løser BM25's mismatch-problem: „få mine penge tilbage" og „refund policy" lander tæt på hinanden i embeddingrummet, selv med nul fælles tokens, fordi modellen fanger betydning, ikke overfladeform. Her betyder modelvalget rigtig meget. Se vores guide til at vælge den rigtige embeddingmodel og vores gennemgang af sådan sammenlignede vi Voyage-, OpenAI- og Cohere-embeddinger, hvis du vejer mulighederne.

Men tæt genfinding har sin egen blinde vinkel, og den er spejlbilledet af BM25's. Når vi bygger RAG-systemer for kunder, er den fejltype med præcise træf, vi oftest støder på, ikke eksotisk. Det er en supportmedarbejder, der spørger på et bestemt ordrenummer eller en SKU, og vektorindekset, der skråsikkert returnerer noget, der minder semantisk om, men er forkert. En generel embeddingmodel har ingen grund til at placere „SKU-4471" eller „ERR_CONN_RST" tæt på sig selv i vektorrummet frem for en relateret-men-forkert token, fordi strenge som de sjældent optræder som distinkte, isolerede koncepter i træningsdata. BigData Boutique dokumenterer præcis dette fejlmønster med egne SKU- og fejlkodeeksempler. Det er et veletableret, uafhængigt bekræftet fænomen på tværs af RAG-implementeringer, ikke en engangsfejl.

Sådan kombinerer du BM25 og vektorsøgning: RRF vs. alfa-vægtet fusion

Der er to reelle måder at fusionere BM25- og vektorresultater på, og næsten ingen, der skriver om hybridsøgning, stiller dem skarpt op mod hinanden. Reciprocal Rank Fusion (RRF) fra Cormack, Clarke og Buettchers SIGIR-artikel fra 2009 opererer på rangplaceringer: score = sum(1 / (k + rank_i)) på tværs af hver resultatliste, med k typisk sat til 60. Fordi den kun bekymrer sig om placering, ikke rå score, håndterer RRF skala-mismatch mellem BM25's ubegrænsede scorer og cosinus-ligheds 0-til-1-interval uden problemer, og den kræver ingen finjustering per korpus.

Alfa-vægtet (konveks) fusion fungerer anderledes: final = alpha * dense_score + (1 - alpha) * sparse_score, der opererer på normaliserede scorer i stedet for rangplaceringer. Den kan bedre afspejle konfidensens størrelse (et vektortræf med 0,95 i lighed ser reelt stærkere ud end et med 0,61), men den kræver finjustering af alpha per korpus, og den finjustering bryder lydløst, når scorefordelingerne ændrer sig (ny embeddingmodel, reindekseret korpus, anden forespørgselsmix).

I praksis kommer valget an på, hvor meget du stoler på din scorekalibrering. Kører du standard-BM25 mod en enkelt, stabil embeddingmodel, kan alfa-vægtning klemme en lidt bedre rangering ud, fordi den bruger det faktiske scoregab, ikke kun placeringen. Men den kalibrering driver mere, end folk tror. Skifter du til en ny version af embeddingmodellen, chunker du dokumenterne om, eller tilføjer du et reranking-trin foran, flytter din tætte scorefordeling sig. Ingen bliver ringet op, fordi alpha=0,6 ikke længere er den rigtige værdi; rangeringen bliver bare stille og roligt lidt dårligere, og det er let at overse, medmindre man kører genfindingsevaluer løbende. RRF omgår det problem helt, fordi den aldrig kigger på rå scorer, kun rangplacering, så en reindeksering eller et modelskifte kan ikke ødelægge den i stilhed, som det kan med alfa-vægtning.

RRF kræver ingen finjustering per korpus; alfa-vægtning kræver konstant babysitning, efterhånden som dine data ændrer sig.

Motorerne er uenige om standarderne. Weaviate tilbyder både RRF og en alpha-parameter, man selv sætter. Elasticsearch leverer nativ RRF via sit retriever-API (tjek den præcise versionsbegrænsning i dit deployment; det landede i 8.x-serien). Qdrant understøtter RRF nativt via sit Query API. Pinecones hybridfunktion støtter sig typisk til alfa-vægtet konveks kombination frem for at eksponere RRF direkte. Er du i tvivl om, hvilken du skal gribe efter, så start med RRF. Det er den mere vedligeholdelsesfrie standard.

RRF fra bunden: et leverandørneutralt Python-eksempel

Alle RRF-kodeeksempler, vi fandt i konkurrerende guides, er låst til én leverandørs SDK: Weaviates klient, Qdrants klient, Pinecones klient. Her er en frameworkfri version, du kan smide i en hvilken som helst stack, 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 er hele algoritmen. Ingen SDK, ingen leverandørlåsning, og den virker, uanset om dine to rangerede lister kom fra Elasticsearch og et Faiss-indeks eller fra Postgres ts_rank og pgvector. Kører du selv modellerne i stedet for at kalde et API, så se kør embeddingmodeller lokalt med Ollama.

Postgres + pgvector: hybridsøgning uden en dedikeret vektordatabase

Man behøver ikke en dedikeret vektordatabase for at køre hybridsøgning. Ifølge et pg_textsearch/pgvector-benchmark af udvikleren Pedro Alonso (Postgres 17, pg_textsearch 1.3.0, pgvector 0.8.2, nomic-embed-text-embeddinger, BEIR SciFact-datasættet) scorede en enkelt Postgres-instans med nativ ts_rank blot 0,07 NDCG@10, langt bag 0,69 for BM25, 0,66 for pgvector og 0,70 for hybrid, alt sammen i én instans, hvor hybrid-RRF landede omkring 11,5 ms i median.

Det tal på 0,07 er afslørende: Postgres' indbyggede ts_rank er en cover-density-rangering, ikke ægte BM25. Vil du have reel BM25-scoring i Postgres, kræver det en udvidelse. pg_textsearch, VectorChord og ParadeDB tilføjer alle rigtig BM25-agtig rangering, som nativ ts_rank ikke leverer. Kombiner en af dem med pgvector til tæt lighed, fusioner de to rangerede lister med RRF-funktionen ovenfor, og du har hybridsøgning i en enkelt Postgres-instans uden ekstra infrastruktur, der skal drives.

Sådan nogenlunde ser den kombination ud i en enkelt forespørgsel, der kombinerer en leksikalsk rang fra en BM25-kapabel udvidelse med en vektordistance fra 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);

Send begge resultatsæt ind i RRF-funktionen ovenfor, og du har hybridsøgning i én Postgres-instans. Den ærlige begrænsning: det holder fint op i de lave millioner af rækker, men Postgres er ikke bygget som en dedikeret genfindingsmotor. Du står selv for indeksfinjusteringen, almindelig ts_rank_cd er stadig ikke ægte BM25 uden en udvidelse, og du får ikke den indbyggede reranking eller multi-vektor-understøttelse, som Weaviate eller Milvus leverer nativt. Er korpusset lille til mellemstort, og kører du allerede Postgres, sparer det dig for et helt ekstra stykke infrastruktur. Når du kommer op i titusindvis af millioner dokumenter, eller hvis du har brug for avanceret reranking, tjener en dedikeret motor sig hjem.

Hvis du vejer Qdrant, Chroma eller pgvector til din stack mere bredt, er det en separat beslutning fra selve fusionsmetoden. Se vores sammenligning af Qdrant, Chroma og pgvector for afvejningerne.

Hvilke vektordatabaser understøtter nativ hybridsøgning?

De fleste moderne vektordatabaser leverer i dag hybridsøgning fra start, men standardfusionsmetoden, de vælger, adskiller sig markant.

Tjek de præcise versionsbegrænsninger, før du binder dig. Hybridfunktioner er landet hurtigt i disse motorer gennem 2026, og API-formerne ændrer sig fra release til release. For en bredere købsbeslutning ud over selve fusionsmekanikken, se vores fulde roundup af de bedste vektordatabaser.

Er hybridsøgning kompleksiteten værd?

Hybridsøgning er arkitektonisk korrekt, når dit korpus har både præcise-træf-mønstre (SKU'er, ID'er, sjældne termer) og konceptuelle, omskrevne forespørgsler. Har dit korpus ingen af delene (rent narrativt indhold, ingen identifikatorer nogen søger på som præcis streng), tilføjer du måske fusionskompleksitet for en gevinst, du knap nok mærker.

Tænk over, hvad „kun narrativt" faktisk ser ud: et virksomhedsblogarkiv, en intern ingeniørwiki fuld af prosatunge runbooks, et dokumentationssite ingen søger på via produkt-ID eller ticketnummer. I de korpusser får du som regel det meste af værdien fra vektorsøgning alene, og fusionstrinnet tilføjer bare et ekstra genfindingspas og en parameter, nogen nu ejer, for en gevinst, der rundes af til støj. Sammenlign det med et supportticketsystem eller et e-handelskatalog, hvor SKU'er, ordrenumre og modelkoder optræder i rigtige brugerforespørgsler konstant. Det er den reelle test: tag ti rigtige forespørgsler fra jeres egne logs og tæl, hvor mange der indeholder en præcis identifikator, en parafrasebaseret embeddingmodel aldrig ville placere korrekt. Nul: spring hybrid over. Mere end en-to: byg den.

Hybridsøgning er ikke en universel opgradering; hvis dit korpus ingen SKU'er, ID'er eller opslag på sjældne termer har, tilføjer du måske fusionskompleksitet for en gevinst, du aldrig kommer til at mærke.

Omkostningen er reel, men begrænset: et ekstra genfindingspas, et fusionstrin og en vægtningsparameter, nogen nu ejer. Vi citerer bevidst ikke noget latenstal her, fordi de tal, der florerer, kommer fra unavngivne opsætninger på unavngivet hardware, og jeres vil være anderledes. Mål det på jeres eget korpus, før I beslutter jer. To Hacker News-tråde fanger den reelle praktikerspænding her: „Hybrid Search Is Just the Beginning: Optimizing the R in RAG" og „Better RAG Results with Reciprocal Rank Fusion and Hybrid Search". Begge tråde skubber tilbage mod at adoptere hybrid som cargo-kult-best-practice uden først at tjekke, om jeres korpus overhovedet har de forespørgselsmønstre, den er designet til at løse. Før du bygger den, er det værd at forstå, hvordan man faktisk måler genfindingskvalitet: NDCG- og recall@k-tal betyder kun noget mod jeres eget korpus, ikke mod et benchmarkdatasæt.

Vores holdning: brug hybrid som standard for ethvert RAG-system, der håndterer brugervendt support, e-handel eller ticketforespørgsler. De arbejdslaster blander næsten altid identifikatorer med naturligt sprog. Spring den over for rent narrative korpusser (langt indhold, narrative wikier), indtil du har målt et reelt gab, som enkeltmetodegenfinding lader stå åbent.

Ofte stillede spørgsmål

Hvad er hybridsøgning i RAG?

Hybridsøgning kører BM25 (nøgleord) og vektor (semantisk) genfinding som separate pass over den samme forespørgsel og merger derefter de to rangerede lister med en fusionsalgoritme, som regel Reciprocal Rank Fusion. Den fanger både præcise-træf-forespørgsler og omskrevne konceptuelle forespørgsler, som ingen af metoderne håndterer alene.

Er BM25 det samme som vektorsøgning?

Nej. BM25 er sparse, leksikalsk søgning, der scorer præcist termoverlap og sjældenhed. Vektorsøgning er tæt, semantisk søgning med embeddinger og lighedsregning. De er to forskellige genfindingsmetoder med modsatte styrker; hybridsøgning kombinerer dem i stedet for at erstatte nogen af dem.

Hvordan kombinerer man BM25 og vektorsøgning?

Kør begge genfindingsmetoder uafhængigt på den samme forespørgsel, og fusioner derefter de to rangerede resultatlister, oftest med Reciprocal Rank Fusion, der summerer 1 / (k + rank) på tværs af hver liste. Alfa-vægtet scorekombination er alternativet, men den kræver finjustering per korpus, som RRF ikke gør.

Hvad er Reciprocal Rank Fusion (RRF)?

RRF er en fusionsalgoritme fra Cormack, Clarke og Buettchers SIGIR-artikel fra 2009, der kombinerer flere rangerede lister ved at summere 1 / (k + rank) for hvert dokument, med k typisk sat til 60. Den arbejder på rangplacering, ikke rå scorer, så den forbliver stabil på tværs af skala-mismatch mellem genfindingsmetoder.

Hvad er forskellen på RRF og alfa-vægtet fusion?

RRF kombinerer rangplaceringer og kræver ingen finjustering per korpus. Alfa-vægtet fusion kombinerer normaliserede scorer med en justerbar alpha-parameter, som bedre kan afspejle konfidensens størrelse, men kræver løbende omfinjustering, hver gang scorefordelingerne ændrer sig, f.eks. efter en reindeksering eller et modelskifte.

Hvornår skal jeg bruge hybridsøgning i stedet for kun vektorsøgning?

Brug hybridsøgning, når dine forespørgsler blander præcise identifikatorer (SKU'er, ordrenumre, fejlkoder) med konceptuelle spørgsmål på naturligt sprog; det gør support, e-handel og ticketsystemer typisk. Spring den over for rent narrativt indhold uden identifikatorer, hvor den ekstra fusionskompleksitet sandsynligvis ikke giver en målbar gevinst.

Hvorfor misser vektorsøgning præcise træf som SKU'er eller fejlkoder?

Embeddingmodeller lærer af generelle sprogmønstre, og strenge som „SKU-4471" eller „ERR_CONN_RST" optræder sjældent som distinkte, isolerede koncepter i træningsdata. Modellen har ingen stærk grund til at placere den præcise streng tættere på sig selv end på en semantisk relateret, men forkert token.

Hvilke vektordatabaser understøtter hybridsøgning nativt?

Weaviate, Qdrant, Elasticsearch, OpenSearch, Vespa og Milvus leverer alle nativ hybridsøgning i 2026, dog med forskellige standardfusionsmetoder (RRF vs. alfa-vægtet vs. normalisering). Postgres med pgvector kan også køre hybridsøgning, men kræver en BM25-udvidelse, da nativ ts_rank ikke er ægte BM25.

Er hybridsøgning den ekstra kompleksitet værd?

For korpusser, der blander præcise træf og konceptuelle forespørgsler: ja. Ren RRF slår allerede begge enkeltmetoder på WANDS-benchmarket (0,7068 mod 0,6983 for BM25), og en finjusteret variant når en forbedring på 7,4 % (0,7497). For rent narrative korpusser uden identifikatorer kan det ekstra genfindingspas og finjusteringen, det kræver, godt opveje en gevinst, du aldrig kommer til at mærke. Mål efter, før du binder dig.

Kan Postgres/pgvector køre hybridsøgning uden en dedikeret vektordatabase?

Ja. Kombiner pgvector til tæt lighed med en ægte BM25-udvidelse som pg_textsearch, VectorChord eller ParadeDB (nativ ts_rank alene scorede blot 0,07 NDCG@10 i Pedro Alonsos pg_textsearch/pgvector-benchmark mod 0,70 for hybrid), og fusioner derefter de to rangerede lister med RRF, alt sammen i én Postgres-instans.

Begge genfindingsmetoder efterlader reelle huller, når de kører alene: BM25 misser parafraser, vektorsøgning misser præcise identifikatorer, og fusionerer man dem med RRF, er det den mere vedligeholdelsesfrie vej til at lukke begge. Overvejer du, om du skal bygge det selv eller hente et team ind, der har leveret RAG-genfinding før, dækker vores fulde guide til at bygge en RAG-applikation næste skridt, eller tag fat i os, hvis du hellere vil have Techsy til at bygge det sammen med dig.