Hybrid search: BM25 + wektory + reranking

Wektorowy retrieval jest w 2026 roku de facto standardem dla wdrożeń RAG. Większość zespołów konfiguruje model embeddingów, wypełnia Qdrant lub pgvector i wypuszcza na produkcję. Działa — dopóki nie pojawi się zapytanie w stylu „§ 271 ust. 2 Kodeksu pracy" albo „HMI model 7NF-420-C". Dense embedding nie radzi sobie z tym: kompresuje dokument do jednego wektora, a dokładny ciąg znaków ginie w semantycznej normalizacji. Właśnie tu wkracza hybrid search — połączenie keyword retrieval (BM25) i wyszukiwania wektorowego, z rerankerem na wierzchu.

Artykuł idzie głębiej niż temat pipeline RAG — 3 ustawienia jakości, gdzie reranker pojawił się jedynie w kontekście całego pipeline'u. Tutaj koncentrujemy się wyłącznie na warstwie search: dlaczego same wektory nie wystarczą, jak mechanicznie działa hybrid, czym jest fuzja RRF, kiedy reranker naprawdę pomaga i jak to wszystko skonfigurować w praktyce.

Dlaczego same wektory nie wystarczają

Dense embedding model (np. BGE-M3 albo text-embedding-3-large) przekształca tekst na wektor w przestrzeni setek lub tysięcy wymiarów. Wektory blisko siebie mają podobną treść semantyczną. Doskonałe dla pytań takich jak „jakie są warunki rozwiązania stosunku pracy", gdzie liczy się sens.

Problem pojawia się przy zapytaniach leksykalnie specyficznych:

• Numery norm i ustaw: § 63, EN ISO 12100, rozporządzenie UE 2016/679
• Kody produktów i części: SKF-6204-2RS, Siemens SIMATIC S7-1500
• Nazwy, skróty, akronimy: BHP, NBP, analiza FFT
• Dokładne wartości: 230 V AC, IP67, UL 508A

W tych przypadkach embedding zawodzi z jednego powodu: model nie był trenowany na tym, że „SKF-6204-2RS" i „SKF-6205-2RS" to fundamentalnie różne pozycje. Wektory mogą być blisko, bo dzielą prefix. Dokładne dopasowanie zostaje utracone.

BM25 (Best Matching 25) nie ma tego problemu. To klasyczna statystyczna metoda oparta na TF-IDF z 1994 roku, która jawnie ocenia wystąpienie każdego tokenu w dokumencie względem całego korpusu. Dla dokładnych ciągów BM25 nadal przewyższa każdy embedding — i to w 2026 roku tak samo jak w 2014.

Z orientacyjnych testów benchmarkowych na syntetycznych korpusach:

• BM25 samodzielnie: ~58 % precyzji
• Dense wektory samodzielnie: ~79 %
• Hybrid (BM25 + dense): ~85–88 %
• Hybrid + cross-encoder reranker: ~88–91 %

Rzeczywista poprawa zależy od zestawu danych, języka i rodzaju zapytań. Dla dokumentacji przemysłowych z kodami i normami obserwujemy w praktyce poprawę hybrid vs. dense rzędu 8–12 punktów procentowych precision@5.

Jak działa BM25

BM25 to model statystyczny. Dla każdego dokumentu i zapytania oblicza wynik jako ważoną sumę TF-IDF (term frequency — inverse document frequency) dla każdego tokenu zapytania. Parametry:

• k1 — kontroluje nasycenie częstości terminu (typowo 1,2–2,0). Wyższy = bardziej liniowa zależność między częstością a wynikiem.
• b — normalizacja długości dokumentu (0 = brak, 1 = pełna). Domyślnie 0,75.

BM25 nie wymaga GPU ani specjalnego sprzętu — jest deterministyczny, szybki i działa na CPU. Biblioteka rank_bm25 w Pythonie, lub natywne wsparcie w Weaviate, OpenSearch, Elasticsearch i Qdrant (przez sparse vectors).

Ograniczenie: BM25 nie rozumie synonimów ani parafraz. Zapytanie „rozwiązanie stosunku pracy" nie znajdzie dokumentu, który mówi wyłącznie o „wypowiedzeniu umowy". Do tego służą właśnie wektory.

Reciprocal Rank Fusion — jak połączyć dwa wyniki

Gdy mamy dwa osobne rankingi (BM25 i dense wektory), trzeba je połączyć w jeden. Najczęstszym podejściem w 2026 roku jest RRF (Reciprocal Rank Fusion).

Mechanika jest prosta. Dla każdego dokumentu obliczamy:

RRF_score(d) = sum( 1 / (k + rank_i(d)) )

gdzie rank_i(d) to pozycja dokumentu w i-tym rankingu, a k to parametr wygładzający (typowo 60). Dokumenty pojawiające się wysoko w obu rankingach otrzymują najwyższy wynik. Dokument nieznany jednemu systemowi, ale plasowany na 1. miejscu przez drugi, wciąż uzyskuje przyzwoity wynik.

Dlaczego nie prosta średnia ważona wyników? Wyniki BM25 i cosine similarity embeddingów operują na różnych skalach — bezpośrednie ważenie faworyzowałoby jeden z systemów. RRF pracuje wyłącznie na pozycjach rankingowych, więc skala nie ma znaczenia.

Alternatywa dla RRF: DBSF (Distribution-Based Score Fusion) — normalizuje wyniki przed fuzją, odpowiednia gdy oba systemy są skalibrowane. W praktyce większość implementacji startuje z RRF, a DBSF próbuje dopiero przy problemach z rozkładem.

Parametr alpha w niektórych frameworkach (np. Weaviate) po prostu kontroluje proporcję BM25 vs. dense — alpha=0 = czysty BM25, alpha=1 = czysty dense, alpha=0.5 = równy wkład obu. Domyślne 0,5 to dobry punkt startowy, ale dla treści z dużą gęstością kodów i norm warto spróbować alpha=0,3–0,4 (większy wkład BM25).

Reranker — dlaczego sam retrieval nie wystarczy

Hybrid search znacznie poprawia recall — prawdopodobieństwo, że właściwy dokument znajdzie się wśród top-K kandydatów. Ale precision@5 (ile z pierwszych 5 jest naprawdę trafnych) zależy od tego, jak dobrze są uporządkowani kandydaci.

Tu wchodzi reranker (model cross-encoder). Mechanika:

1. 1.Hybrid retrieval zwraca top-K dokumentów (typowo K = 20–50). Szybko.
2. 2.Reranker otrzymuje każdy z K dokumentów wraz z zapytaniem, przetwarza je łącznie i przydziela dokładny wynik trafności. Wolniej, ale precyzyjniej.
3. 3.Top-N (typowo N = 5) z najwyższym wynikiem rerankera trafia do kontekstu LLM.

Dlaczego reranker jest precyzyjniejszy niż embedding? Bi-encoder embedding kompresuje dokument i zapytanie osobno do wektorów — interakcja między nimi jest oceniana wyłącznie przez podobieństwo kosinusowe. Cross-encoder widzi zapytanie i dokument jednocześnie, co pozwala mu uchwycić subtelne interakcje na poziomie tokenów, które bi-encoder traci.

Typowy wzrost precision@5 po dodaniu rerankera: 7–12 punktów procentowych. Dodatkowe opóźnienie: 50–200 ms dla rerankingu top-20.

Aktualne rozwiązania najwyższej klasy:

• Cohere Rerank 3.5 — managed API, doskonały dla treści wielojęzycznych obejmujących Europę Środkową, łatwa integracja
• BGE-reranker-v2-m3 — open-weight, self-hosted, wielojęzyczny, znakomity stosunek wydajności do kosztów
• ms-marco-MiniLM-L-6-v2 — mały, szybki, do prototypowania po angielsku

Dla wyboru modelu embeddingów obowiązuje podobna zasada: wielojęzyczne treści z UE zasługują na wielojęzyczny reranker.

Kiedy hybrid wyraźnie pomoże (a kiedy nie)

Hybrid search wyraźnie pomoże, gdy:

• Treść zawiera kody, liczby, skróty, normy, oznaczenia produktów
• Użytkownik zadaje precyzyjne zapytania (kopiowanie z dokumentu, kod części z zamówienia)
• Język nie jest wyłącznie angielski — BM25 nie potrzebuje modelu językowego, działa dla polskiego równie dobrze
• Recall stanowi problem — „trafny dokument nie został znaleziony" to częsta skarga
• Korpus zawiera tematycznie bardzo podobne dokumenty (np. 5 000 podobnie ustrukturyzowanych kart technicznych)

Hybrid search mniej pomoże, gdy:

• Zapytania są wyłącznie konwersacyjne, opartej na parafrazach (chatbot FAQ, odpowiedzi HR)
• Korpus jest mały (poniżej 500 dokumentów) — dodatkowe opóźnienie i złożoność nie opłacają się
• Latencja jest krytyczna — na każdym etapie dochodzi scoring BM25 (typowo +10–30 ms) i potencjalnie reranker (+50–200 ms)
• Treść jest przede wszystkim anglojęzyczna, a embeddingi są wysokiej jakości — dense wektory zbliżają się do wyników retrieval hybrydowego

Widzieliśmy u klienta z branży części zamiennych: korpus 18 000 kart technicznych z kodami SKF, NSK, FAG. Czysty dense retrieval, precision@5 = 0,63. Po przejściu na hybrid z alpha=0,35 i BGE-reranker-v2-m3: precision@5 = 0,84. Główna przyczyna — dokładne dopasowanie kodu części z zapytania klienta.

Konfiguracja praktyczna — stack 2026

Qdrant (zalecany dla przemysłowych wdrożeń B2B)

Qdrant obsługuje natywny hybrid search przez sparse + dense wektory w jednej kolekcji. Sparse wektory dla BM25 generujemy przez BM25Encoder z biblioteki fastembed.

# inicializácia sparse encoder
from fastembed import SparseTextEmbedding
sparse_model = SparseTextEmbedding("Qdrant/bm25")

# pri indexácii
sparse_vec = sparse_model.embed(text)
dense_vec = embedding_model.embed(text)

# query: hybrid search s RRF fusion
results = client.query_points(
    collection_name="documents",
    prefetch=[
        Prefetch(query=sparse_vec, using="sparse", limit=20),
        Prefetch(query=dense_vec, using="dense", limit=20),
    ],
    query=FusionQuery(fusion=Fusion.RRF),
    limit=5
)

Konfiguracja kolekcji: dwa indeksy wektorowe — dense (wymiarowość według modelu embeddingów, cosine) i sparse (indeks sparse, dot). Qdrant obsługuje oba w jednym przejściu.

Weaviate

Weaviate traktuje hybrid search jako funkcję pierwszej klasy — BM25 + dense wektory + fuzja RRF w jednym wywołaniu API. Konfiguracja alpha bezpośrednio w zapytaniu:

results = collection.query.hybrid(
    query="§ 63 Zákonník práce výpoveď",
    alpha=0.4,  # väčší príspevok BM25
    limit=20
)

Następnie reranker przez Cohere lub lokalny cross-encoder na top-20 wynikach.

Warstwa rerankingu

Niezależnie od bazy wektorowej, reranker to osobny krok. Zalecana konfiguracja:

• K = 20–30 kandydatów z hybrid retrieval
• Reranker na K kandydatach → N = 5 wyników dla LLM
• Dla self-hosted: BGE-reranker-v2-m3 na GPU; na CPU obsługuje ~500 ms/zapytanie dla top-20
• Dla chmury: Cohere Rerank 3.5 API, endpoint EU

Dodanie rerankera do istniejącego hybrid retrieval to zazwyczaj 20–40 linii kodu. Gdy mówimy o ewaluacji pipeline RAG przez RAGAS, właśnie ten krok powinien mieć własną metrykę precision@5 przed i po.

Latencja: co dodaje każda warstwa

Typowe czasy latencji przy 10 M wektorów, GPU RTX 4090 (orientacyjnie):

• Scoring BM25 na CPU: 10–30 ms
• Dense vector search (Qdrant): 5–15 ms
• Fuzja RRF: poniżej 5 ms
• Reranker cross-encoder top-20 (GPU): 80–150 ms
• Reranker cross-encoder top-20 (CPU): 400–800 ms
• Cohere Rerank 3.5 API (sieć): 100–200 ms

Cały pipeline: hybrid retrieval + reranker GPU = typowo 200–400 ms end-to-end warstwa search. Dla interaktywnych chatbotów jest to zazwyczaj akceptowalne. Dla systemów wymagających odpowiedzi poniżej 150 ms rozważ reranker tylko przy niskich opóźnieniach sieciowych lub zastąpienie go prostszym bi-encoder resorting.

Szczegółowe porównanie baz wektorowych i ich parametrów QPS znajdziesz w artykule Bazy wektorowe — Qdrant, Weaviate, pgvector, Milvus.

Najczęstsze pytania

Czy muszę od początku projektować system z hybrid retrieval, czy mogę dodać BM25 później?

Indeks BM25 jest niezależny od indeksu embeddingów i można go dodać do istniejącego korpusu w dowolnym momencie. W Qdrant wystarczy dodać sparse vector index do kolekcji i ponownie zaindeksować dokumenty — indeksy dense pozostają niezmienione. Weaviate, Milvus i pgvector mają podobną procedurę. Czas reindeksacji zależy od rozmiaru korpusu, ale dla typowej bazy wiedzy B2B (do 1 M dokumentów) to kwestia godzin, nie dni.

Co jest lepsze dla polskich treści: BM25 czy dense embedding?

Zależy od charakteru zapytań. BM25 działa dla języka polskiego równie dobrze jak dla angielskiego — to model statystyczny bez zależności językowych. Dla pytań semantycznych (parafrazy, synonimy) lepszy jest wielojęzyczny dense embedding jak BGE-M3 lub Qwen3-Embedding-8B. W praktyce dla polskich korpusów B2B: hybrid z alpha=0,4–0,5 daje najlepsze wyniki.

Kiedy reranker nie pomoże?

Reranker zmienia kolejność jedynie dokumentów zwróconych przez retrieval. Jeśli właściwy dokument nie ma go w top-K kandydatach, reranker go nie uratuje. Oznacza to: najpierw trzeba poprawić recall (hybrid retrieval, większe K), a dopiero potem dodawać reranker. Jeśli precision@5 stagnuje nawet po rerankerze, problem leży zazwyczaj w recall — właściwy dokument po prostu nie trafia do kandydatów.

Jaka jest różnica między hybrid search a agentic RAG?

Hybrid search to technika na poziomie warstwy retrieval — poprawia, które dokumenty trafiają do kontekstu LLM. Agentic RAG to wzorzec architektoniczny, w którym agent aktywnie decyduje, co i jak wyszukiwać — iteracyjne zapytania, różne źródła, sub-queries. Hybrid search i agentic RAG nie wykluczają się: dobry agent używa hybrid retrieval pod spodem.

Czy hybrid search można wdrożyć on-prem bez zależności chmurowych?

Tak. Qdrant i Weaviate są open-source i działają self-hosted. BGE-reranker-v2-m3 to open-weight model działający lokalnie na GPU. BM25 nie wymaga żadnych zewnętrznych serwisów. Cały stack — hybrid retrieval + reranker — może działać w pełni on-prem, co jest istotne dla regulowanych branż. Więcej na temat on-prem LLM dla regulowanych branż.

---

*Jeśli Twój system RAG napotyka problem z niezawodnym odnajdywaniem dokładnych kodów, norm lub oznaczeń produktów, przyczyną jest niemal zawsze brak warstwy keyword. Pomagamy firmom zaprojektować i wdrożyć stack hybrid retrieval — od wyboru bazy danych i modelu embeddingów po konfigurację rerankera i pomiar poprawy.*