Hybridní vyhledávání: BM25 vs. vektor (a proč potřebujete obojí)

Hybridní vyhledávání: BM25 vs. vektor (a proč potřebujete obojí)

Operátor podpory zadá „SKU-4471" do vašeho RAG chatbota. Vrátí se čtyři výsledky. Všechny sebevědomě špatné. Univerzální embeddingový model nemá žádný důvod umístit přesně tento řetězec ve vektorovém prostoru blízko samotného sebe. Právě tento jeden způsob selhání je důvodem, proč existuje hybridní vyhledávání, a proč si týmy stále dokola kladou jednu konkrétní otázku: jak vlastně zkombinovat BM25 a vektorové vyhledávání, aniž byste museli navěky hlídat ladicí knob?

Pokud hodnotíte nástroje pro RAG v širším záběru, náš přehled nejlepších nástrojů pro RAG mapuje okolní stack.

Klíčové body

• BM25 nachází přesné shody klíčových slov (SKU, chybové kódy); vektorové vyhledávání nachází koncepčně podobný text, nikoli identické řetězce.
• Hybridní vyhledávání kombinuje obojí, nejčastěji přes Reciprocal Rank Fusion (RRF), a na směsných query workloadech poráží obě metody provozované samostatně.
• Na benchmarku WANDS dosahuje prosté RRF skóre 0,7068 NDCG (oproti 0,6983 u BM25); po vyladění stoupne na 0,7497, tedy o 7,4 % výš.
• Postgres/pgvector zvládne hybridní vyhledávání nativně přes ts_rank + pgvector, bez nutnosti dedikované vektorové databáze.

Co je hybridní vyhledávání? (BM25 + vektor v kombinaci)

Hybridní vyhledávání spustí BM25 a vektorové vyhledávání jako dva samostatné průchody retrievalu nad stejným dotazem a poté dva seřazené seznamy výsledků sloučí pomocí fúzního algoritmu do jediného výstupu, nejčastěji Reciprocal Rank Fusion. Není to třetí metoda retrievalu; je to orchestrační vrstva nad dvěma existujícími.

Toto rozlišení je důležité, protože značná část vyhledávacího provozu kolem tohoto tématu zaměňuje BM25 a vektorové vyhledávání, jako by šlo o totéž. Nejde. BM25 je řídká, na klíčových slovech založená skórovací funkce s kořeny v informačním retrievalu 70. let. Vektorové vyhledávání je husté, na embeddinzích založené hledání podobnosti, které se ve velkém měřítku stalo praktickým teprve v posledním desetiletí. Hybridní vyhledávání je bere jako komplementární vstupy, nikoli jako soupeřící techniky, a fúzuje jejich výstupy, místo aby předem vybíralo vítěze.

BM25 vs. vektor vs. hybrid: rychlé srovnání

Na e-commerce benchmarku WANDS dosáhlo samotné BM25 skóre 0,6983 NDCG a samotné vektorové vyhledávání 0,6953 (téměř vyrovnaně). Prostá RRF fúze, bez jakéhokoli ladění pro daný korpus, dosáhla 0,7068, tedy skromného zlepšení o 1,2 % oproti samotnému BM25. Benchmark Douga Turnbulla testoval také vyladěnou variantu, která na RRF navrch přidává boost na názvy produktů, a tato verze dosáhla 0,7497, tedy zlepšení o 7,4 %. Vyplatí se být upřímný v tom, které číslo citujete: samotné RRF vám z krabice dá malou, ale reálnou výhodu; větší hodnota 7,4 % vyžadovala dodatečné ladění specifické pro doménu, které většina týmů první den přeskočí. Ani BM25, ani vektorové vyhledávání samo o sobě nedominuje; pokrývají různé způsoby selhání a jejich fúzí uzavřete obě mezery naráz.

Mechanika BM25: jak klíčové hledání vlastně skóruje relevanci

BM25 skóruje dokumenty podle četnosti termínů, vážené vůči tomu, jak vzácný je daný termín v celém korpusu, a normalizované podle délky dokumentu. Robertson a Zaragoza tuto formalizaci popsali ve svém článku z roku 2009 "The Probabilistic Relevance Framework: BM25 and Beyond". Jde o zpřesnění TF-IDF, nikoli o jeho náhradu.

Dva parametry řídí většinu chování BM25. k1 (typicky 1,2-2,0) řídí saturaci četnosti termínů: omezuje, jak moc opakování slova zvedne skóre, takže dokument, který říká "invoice" čtyřicetkrát, automaticky neporazí ten, který totéž slovo použije čtyřikrát v těsnějším, relevantnějším úryvku. b (výchozí 0,75) řídí normalizaci podle délky dokumentu: rozhoduje, jak přísně BM25 trestá dlouhé dokumenty za to, že přirozeně obsahují více shod termínů.

Špatně nastavené b je běžná a reálná chyba ladění. Krátké technické dokumenty (chybové logy, názvy produktů) chtějí nižší b, protože rozptyl délek je malý; dlouhé formáty (stránky dokumentace, články) obvykle chtějí b blíž výchozí hodnotě. Klíčová slabina BM25 je slovníková neshoda: pokud se uživatel zeptá "jak dostanu zpátky svoje peníze" a dokument říká jen "zásady vrácení peněz", BM25 nenajde žádný sdílený token a nevrátí nic užitečného.

Mechanika hustého vektorového vyhledávání (a kde selhává)

Vektorové vyhledávání mapuje text pomocí modelu do embeddingů s pevnou dimenzí a poté hledá blízké vektory přes kosinovou podobnost nebo skalární součin, typicky urychlené indexem přibližných nejbližších sousedů. HNSW je dominantní algoritmus napříč Weaviate, Qdrant a Milvus; vyměňuje malé množství recallu za zásadní zrychlení ve velkém měřítku.

Právě tohle řeší problém slovníkové neshody u BM25: "dostat zpátky peníze" a "zásady vrácení peněz" skončí v embeddingovém prostoru blízko sebe, i když nesdílejí jediný token, protože model zachycuje význam, nikoli povrchovou formu. Tady hodně záleží na volbě správného modelu. Podívejte se na našeho průvodce výběrem správného embeddingového modelu a na náš rozbor toho, jak jsme porovnávali embeddingy Voyage, OpenAI a Cohere, pokud zvažujete možnosti.

Hustý retrieval má ale vlastní slepé místo a je to zrcadlový obraz slabiny BM25. Když stavíme RAG systémy pro klienty, selhání přesné shody, na které narážíme nejčastěji, není nic exotického. Je to operátor podpory, který hledá konkrétní číslo objednávky nebo SKU, a vektorový index sebevědomě vrátí něco sémanticky podobného, ale špatného. Univerzální embeddingový model nemá žádný důvod umístit "SKU-4471" nebo "ERR_CONN_RST" ve vektorovém prostoru blízko samotných sebe oproti příbuznému, ale chybnému tokenu, protože řetězce tohoto typu se v trénovacích datech zřídkakdy vyskytují jako samostatné, izolované koncepty. BigData Boutique dokumentuje přesně tento vzorec selhání na vlastních příkladech SKU a chybových kódů. Jde o dobře zdokumentovaný, nezávisle potvrzený jev napříč RAG nasazeními, nikoli o jednorázový výstřelek.

Jak zkombinovat BM25 a vektorové vyhledávání: RRF vs. alfa-vážená fúze

Existují dva reálné způsoby, jak fúzovat výsledky BM25 a vektoru, a téměř nikdo, kdo o hybridním vyhledávání píše, je jasně nepostaví vedle sebe. Reciprocal Rank Fusion (RRF), z článku SIGIR 2009 od Cormacka, Clarka a Buettchera, pracuje s pořadím: score = sum(1 / (k + rank_i)) napříč jednotlivými seznamy výsledků, přičemž k se typicky nastavuje na 60. Protože se stará jen o pozici, ne o hrubé skóre, RRF si bez stížností poradí s rozdíly měřítek mezi neomezenými skóre BM25 a rozsahem 0 až 1 u kosinové podobnosti a nepotřebuje žádné ladění pro daný korpus.

Alfa-vážená (konvexní) fúze funguje jinak: final = alpha * dense_score + (1 - alpha) * sparse_score, pracuje s normalizovanými skóre místo s pořadím. Umí lépe odrážet velikost jistoty (vektorový zásah s podobností 0,95 vypadá skutečně silněji než ten s 0,61), ale vyžaduje ladění alpha pro každý korpus a toto ladění se potichu rozbije, když se posune rozložení vašich skóre (nový embeddingový model, přeindexovaný korpus, jiná směs dotazů).

V praxi volba závisí na tom, jak moc věříte kalibraci svých skóre. Když provozujete vanilkové BM25 proti jednomu stabilnímu embeddingovému modelu, alfa-vážení může vyždímat mírně lepší řazení, protože využívá skutečný odstup skóre, ne jen pozici. Jenže tahle kalibrace se posouvá víc, než lidé čekají. Vyměňte verzi embeddingového modelu, přechunkujte dokumenty nebo přidejte rerankingový průchod proti proudu a rozložení vašich hustých skóre se posune. Nikoho neprobudí pager, když alpha=0,6 přestane být správnou hodnotou; řazení se jen tiše o něco zhorší a snadno to unikne, pokud pravidelně nespouštíte evaly retrievalu. RRF se tomu všemu vyhýbá, protože se na hrubá skóre nikdy nedívá, jen na pozici v pořadí, takže přeindexování nebo výměna modelu ho nemůže potichu rozbít tak, jako dokáže rozbít alfa-vážení.

RRF nepotřebuje ladění pro jednotlivé korpusy; alfa-vážení vyžaduje neustálé hlídání, jakmile se vaše data mění.

Enginy se ve výchozím nastavení rozcházejí. Weaviate nabízí jak RRF, tak parametr alpha, který nastavujete explicitně. Elasticsearch dodává nativní RRF přes své retriever API (ověřte si přesné verzování ve svém nasazení; objevilo se to v řadě 8.x). Qdrant podporuje RRF nativně přes své Query API. Hybridní funkce Pinecone se typicky opírá spíše o alfa-váženou konvexní kombinaci, než aby přímo vystavovala RRF. Pokud si nejste jisti, po čem sáhnout, začněte s RRF. Je to výchozí volba s nižší údržbou.

RRF od nuly: ukázka v Pythonu bez závislosti na vendorovi

Každá ukázka kódu RRF, kterou jsme našli v konkurenčních průvodcích, je přivařená k SDK jednoho vendoru: klient Weaviate, klient Qdrant, klient Pinecone. Tady je verze bez frameworku, kterou můžete pustit v jakémkoli stacku, s k=60 jako standardní výchozí hodnotou:

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}")

To je celý algoritmus. Žádné SDK, žádný vendor lock-in, a funguje, ať vaše dva seřazené seznamy přišly z Elasticsearchu a indexu Faiss, nebo z ts_rank v Postgresu a pgvectoru. Pokud provozujete modely sami, místo abyste volali API, podívejte se na lokální běh embeddingových modelů s Ollamou.

Postgres + pgvector: hybridní vyhledávání bez dedikované vektorové databáze

K provozu hybridního vyhledávání nepotřebujete dedikovanou vektorovou databázi. Podle benchmarku pg_textsearch/pgvector od vývojáře Pedra Alonsa (Postgres 17, pg_textsearch 1.3.0, pgvector 0.8.2, embeddingy nomic-embed-text, dataset BEIR SciFact) dosáhla jediná instance Postgresu s nativním ts_rank pouhých 0,07 NDCG@10, daleko za 0,69 u BM25, 0,66 u pgvectoru a 0,70 u hybridu, vše v jediné instanci, přičemž hybridní RRF se pohybovalo kolem mediánu 11,5 ms.

Číslo 0,07 je ten prozrazující detail: vestavěný ts_rank Postgresu je ranker podle hustoty pokrytí, ne pravé BM25. Pokud chcete v Postgresu skutečné BM25 skórování, potřebujete rozšíření. pg_textsearch, VectorChord i ParadeDB přidávají řádné řazení ve stylu BM25, které nativní ts_rank neposkytuje. Spárujte jedno z nich s pgvectorem pro hustou podobnost, fúzujte dva seřazené seznamy výše uvedenou funkcí RRF a máte hybridní vyhledávání v jediné instanci Postgresu, bez další infrastruktury, kterou byste museli provozovat.

Zhruba takhle vypadá ono párování v jednom dotazu, který kombinuje lexikální pořadí z rozšíření schopného BM25 s vektorovou vzdáleností z pgvectoru:

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);

Obě množiny výsledků nasměrujte do výše uvedené funkce RRF a máte hybridní vyhledávání v jedné instanci Postgresu. Upřímná mez: tohle dobře drží do nízkých milionů řádků, ale Postgres nebyl postaven jako dedikovaný retrieval engine. Ladění indexů si zajišťujete sami, prostý ts_rank_cd stále není pravé BM25 bez rozšíření a nedostanete vestavěný reranking ani podporu více vektorů, které Weaviate nebo Milvus dodávají nativně. Pokud je váš korpus malý až střední a Postgres už provozujete, ušetříte celý druhý kus infrastruktury. Nad desítkami milionů dokumentů, nebo pokud potřebujete pokročilý reranking, se dedikovaný engine vyplatí.

Pokud pro svůj stack zvažujete Qdrant, Chromu nebo pgvector v širším záběru, je to samostatné rozhodnutí, nezávislé na metodě fúze. Tradeoffy najdete v našem srovnání Qdrantu, Chromy a pgvectoru.

Které vektorové databáze podporují nativní hybridní vyhledávání?

Většina moderních vektorových databází dnes hybridní vyhledávání dodává přímo z krabice, ale výchozí metoda fúze se smysluplně liší.

Než se zavážete, ověřte si přesné verzování. Hybridní funkce napříč těmito enginy v průběhu 2026 rychle přibývají a podoba API se mezi vydáními mění. Pro širší nákupní rozhodnutí, které jde za mechaniku fúze, se podívejte na náš kompletní přehled nejlepších vektorových databází.

Stojí hybridní vyhledávání za tu složitost?

Hybridní vyhledávání je architektonicky správné, když má váš korpus jak vzorce přesné shody (SKU, ID, vzácné termíny), tak koncepční, parafrázované dotazy. Pokud nemá ani jedno (čistě narativní obsah, žádné identifikátory, podle kterých by někdo hledal doslovným řetězcem), možná přidáváte složitost fúze kvůli zlepšení, které sotva zaznamenáte.

Zamyslete se, jak "pouze narativní" vlastně vypadá: archiv firemního blogu, interní inženýrská wiki plná upovídaných runbooků, dokumentační web, kde nikdo nehledá podle ID produktu ani čísla tiketu. V takových korpusech vám obvykle většinu hodnoty doručí samotné vektorové vyhledávání a fúzní krok jen přidává druhý průchod retrievalu a parametr, který teď někdo vlastní, kvůli zlepšení, které se zaokrouhlí na šum. Porovnejte to se systémem podpory nebo e-shopovým katalogem, kde se SKU, čísla objednávek a kódy modelů objevují v reálných uživatelských dotazech neustále. Tohle je ten skutečný test: vytáhněte ze svých logů deset reálných dotazů a spočítejte, kolik jich obsahuje přesný identifikátor, který by parafrázový embeddingový model nikdy neumístil správně. Nula, hybrid přeskočte. Víc než jeden dva, postavte ho.

Hybridní vyhledávání není univerzální upgrade; pokud váš korpus nemá SKU, ID ani hledání vzácných termínů, možná přidáváte složitost fúze kvůli zlepšení, které nikdy nezaznamenáte.

Náklady jsou reálné, ale ohraničené: druhý průchod retrievalu, fúzní krok a vážicí parametr, který teď někdo vlastní. Záměrně tu necitujeme žádnou latenci, protože čísla, která kolují, pocházejí z nepojmenovaných sestav na nepojmenovaném hardwaru a ta vaše se budou lišit. Změřte si to na vlastním korpusu, než se rozhodnete. Dvě vlákna na Hacker News zachycují skutečné napětí mezi praktiky: "Hybrid Search Is Just the Beginning: Optimizing the R in RAG" a "Better RAG Results with Reciprocal Rank Fusion and Hybrid Search". Obě vlákna tlačí proti přebírání hybridu jako cargo-cult best practice bez předchozího ověření, zda váš korpus vůbec obsahuje query vzorce, které má řešit. Než ho postavíte, vyplatí se pochopit, jak skutečně měřit kvalitu retrievalu: čísla NDCG a recall@k něco znamenají jen proti vlastnímu korpusu, ne proti benchmarkovému datasetu.

Náš pohled: pro jakýkoli RAG systém, který obsluhuje uživatelskou podporu, e-shop nebo tiketovací dotazy, volte hybrid jako výchozí. Tyto workloady téměř vždy míchají identifikátory s přirozeným jazykem. Přeskočte ho u čistě narativních korpusů (dlouhé dokumenty, narativní wiki), dokud nezměříte reálnou mezeru, kterou jednosměrný retrieval nechává otevřenou.

O autorovi

Mert Batur je spoluzakladatel Techsy.io, kde tým dodává AI agenty, automatizační systémy a hlasové/SDR pipeline pro B2B klienty. Píše o stacku nástrojů pro LLM, který tým Techsy skutečně používá v produkci. Spojte se na LinkedInu.

Často kladené otázky

Co je hybridní vyhledávání v RAG?

Hybridní vyhledávání spouští retrieval BM25 (klíčová slova) a vektorový (sémantický) jako samostatné průchody nad stejným dotazem a poté dva seřazené seznamy slučuje fúzním algoritmem, obvykle Reciprocal Rank Fusion. Zachytí dotazy s přesnou shodou i parafrázované koncepční, což žádná z metod samostatně nezvládne.

Je BM25 totéž co vektorové vyhledávání?

Ne. BM25 je řídké lexikální hledání, které skóruje přesný překryv a vzácnost termínů. Vektorové vyhledávání je husté sémantické hledání využívající embeddingy a matematiku podobnosti. Jsou to dvě různé metody retrievalu s opačnými silnými stránkami; hybridní vyhledávání je kombinuje, nikoli nahrazuje.

Jak zkombinujete BM25 a vektorové vyhledávání?

Spusťte obě metody retrievalu nezávisle na stejném dotazu a poté fúzujte dva seřazené seznamy výsledků, nejčastěji pomocí Reciprocal Rank Fusion, která sčítá 1 / (k + rank) napříč jednotlivými seznamy. Alternativou je alfa-vážená kombinace skóre, ale ta na rozdíl od RRF vyžaduje ladění pro každý korpus.

Co je Reciprocal Rank Fusion (RRF)?

RRF je fúzní algoritmus z článku SIGIR 2009 od Cormacka, Clarka a Buettchera, který kombinuje více seřazených seznamů sčítáním 1 / (k + rank) pro každý dokument, přičemž k se typicky nastavuje na 60. Pracuje s pozicí v pořadí, ne s hrubými skóre, takže zůstává stabilní i při rozdílech měřítek mezi metodami retrievalu.

Jaký je rozdíl mezi RRF a alfa-váženou fúzí?

RRF kombinuje pořadí a nepotřebuje ladění pro jednotlivé korpusy. Alfa-vážená fúze kombinuje normalizovaná skóre pomocí laditelného parametru alpha, což umí lépe odrážet velikost jistoty, ale vyžaduje průběžné přeladění pokaždé, když se posune rozložení skóre, například po přeindexování nebo výměně modelu.

Kdy použít hybridní vyhledávání místo samotného vektorového?

Hybridní vyhledávání použijte, když vaše dotazy míchají přesné identifikátory (SKU, čísla objednávek, chybové kódy) s koncepčními otázkami v přirozeném jazyce; systémy podpory, e-shopy a tiketovací systémy to typicky dělají. Přeskočte ho u čistě narativního obsahu bez identifikátorů, kde přidaná složitost fúze pravděpodobně nepřinese měřitelné zlepšení.

Proč vektorové vyhledávání mine přesné shody jako SKU nebo chybové kódy?

Embeddingové modely se učí z obecných jazykových vzorců a řetězce jako "SKU-4471" nebo "ERR_CONN_RST" se v trénovacích datech zřídkakdy vyskytují jako samostatné, izolované koncepty. Model nemá žádný silný důvod umístit tento přesný řetězec blíž k sobě než k sémanticky příbuznému, ale chybnému tokenu.

Které vektorové databáze podporují hybridní vyhledávání nativně?

Weaviate, Qdrant, Elasticsearch, OpenSearch, Vespa i Milvus dodávají k roku 2026 nativní hybridní vyhledávání, i když jejich výchozí metody fúze se liší (RRF vs. alfa-vážená vs. normalizace). Postgres s pgvectorem také zvládne hybridní vyhledávání, ale potřebuje rozšíření pro BM25, protože nativní ts_rank není pravé BM25.

Stojí hybridní vyhledávání za přidanou složitost?

U korpusů, které míchají dotazy s přesnou shodou a koncepční dotazy, ano. Prosté RRF na benchmarku WANDS poráží obě jednotlivé metody (0,7068 proti 0,6983 u BM25) a vyladěná varianta dosahuje zlepšení o 7,4 % (0,7497). U čistě narativních korpusů bez identifikátorů může druhý průchod retrievalu a ladění fúze, které vyžaduje, převážit zlepšení, které nezaznamenáte. Před závazkem si to změřte.

Zvládne Postgres/pgvector hybridní vyhledávání bez dedikované vektorové databáze?

Ano. Spárujte pgvector pro hustou podobnost s pravým rozšířením BM25, jako je pg_textsearch, VectorChord nebo ParadeDB (samotný nativní ts_rank dosáhl v benchmarku pg_textsearch/pgvector od Pedra Alonsa jen 0,07 NDCG@10, oproti 0,70 u hybridu), a poté fúzujte dva seřazené seznamy pomocí RRF, vše uvnitř jediné instance Postgresu.

Obě metody retrievalu nechávají při samostatném provozu reálné mezery: BM25 mine parafráze, vektorové vyhledávání mine přesné identifikátory a jejich fúze pomocí RRF je způsob s nižší údržbou, jak uzavřít obě. Pokud zvažujete, jestli tohle postavit sami, nebo přizvat tým, který už RAG retrieval dodával, náš kompletní průvodce stavbou RAG aplikace pokrývá další krok, nebo se ozvěte, pokud byste to raději postavili s Techsy.