Wyszukiwanie hybrydowe: BM25 vs vector (i dlaczego potrzebujesz obu)

Wyszukiwanie hybrydowe: BM25 vs vector (i dlaczego potrzebujesz obu)

Agent wsparcia wpisuje „SKU-4471" w Twoim chatbocie RAG. Dostaje cztery wyniki. Wszystkie błędne, choć brzmią pewnie. Ogólny model embeddingowy nie ma żadnego powodu, by umieszczać ten dokładny ciąg blisko niego samego w przestrzeni wektorowej. To właśnie ten jeden tryb awarii jest powodem, dla którego istnieje wyszukiwanie hybrydowe, i dlatego zespoły wciąż zadają jedno konkretne pytanie: jak właściwie połączyć BM25 i wyszukiwanie wektorowe, żeby nie niańczyć w nieskończoność pokrętła dostrajania?

Jeśli oceniasz narzędzia RAG szerzej, nasze zestawienie najlepszych narzędzi RAG obejmuje cały otaczający stack.

Najważniejsze wnioski

• BM25 znajduje dokładne dopasowania słów kluczowych (SKU, kody błędów); wyszukiwanie wektorowe znajduje tekst podobny znaczeniowo, a nie identyczne ciągi.
• Wyszukiwanie hybrydowe łączy oba podejścia, zwykle przez Reciprocal Rank Fusion (RRF), i na mieszanych obciążeniach zapytań pokonuje każde z osobna.
• W benchmarku WANDS czyste RRF osiąga 0,7068 NDCG (wobec 0,6983 dla BM25); dostrajanie podnosi wynik do 0,7497, czyli o 7,4% wyżej.
• Postgres/pgvector potrafi uruchomić wyszukiwanie hybrydowe natywnie przez ts_rank + pgvector, bez dedykowanej bazy wektorowej.

Czym jest wyszukiwanie hybrydowe? (BM25 + vector, połączone)

Wyszukiwanie hybrydowe uruchamia BM25 i wyszukiwanie wektorowe jako dwa osobne przebiegi pozyskiwania na tym samym zapytaniu, a następnie scala dwie listy rankingowe w jedno wyjście za pomocą algorytmu fuzji, najczęściej Reciprocal Rank Fusion. To nie jest trzecia metoda pozyskiwania; to warstwa orkiestracji nad dwiema istniejącymi.

To rozróżnienie ma znaczenie, bo spora część ruchu wyszukiwania wokół tego tematu myli BM25 z wyszukiwaniem wektorowym, jakby były tym samym. Nie są. BM25 to rzadka (sparse), oparta na słowach kluczowych funkcja punktacji, sięgająca korzeniami informacji naukowej lat 70. Wyszukiwanie wektorowe to gęste (dense) wyszukiwanie podobieństwa oparte na embeddingach, które stało się praktyczne na dużą skalę dopiero w ostatniej dekadzie. Wyszukiwanie hybrydowe traktuje je jako uzupełniające się wejścia, nie konkurujące techniki, i scala ich wyniki zamiast wybierać zwycięzcę z góry.

BM25 vs vector vs hybryda: szybkie porównanie

W benchmarku e-commerce WANDS samo BM25 osiągnęło 0,6983 NDCG, a samo wyszukiwanie wektorowe 0,6953 (prawie remis). Czysta fuzja RRF, bez dostrajania pod konkretny korpus, doszła do 0,7068, czyli skromne 1,2% powyżej samego BM25. Benchmark Douga Turnbella testował też wariant dostrojony, który nakłada na RRF boost z nazwy produktu, i ta wersja osiągnęła 0,7497, czyli wzrost o 7,4%. Warto być uczciwym co do tego, którą liczbę cytujesz: samo RRF daje od ręki małą, ale realną przewagę; większa figura 7,4% wymagała dodatkowego dostrajania domenowego, które większość zespołów pomija pierwszego dnia. Ani BM25, ani wyszukiwanie wektorowe nie dominuje samodzielnie; pokrywają różne tryby awarii, a ich fuzja zamyka obie luki naraz.

Mechanika BM25: jak wyszukiwanie słowami kluczowymi naprawdę punktuje trafność

BM25 punktuje dokumenty częstością występowania terminu, ważoną względem rzadkości tego terminu w całym korpusie, a następnie normalizowaną długością dokumentu. Robertson i Zaragoza przedstawili tę formalizację w swojej pracy z 2009 roku "The Probabilistic Relevance Framework: BM25 and Beyond". To rozwinięcie TF-IDF, a nie jego zamiennik.

Dwa parametry sterują większością zachowania BM25. k1 (zwykle 1,2-2,0) kontroluje nasycenie częstości terminu: ogranicza, jak bardzo powtarzanie słowa podbija wynik, żeby dokument mówiący „faktura" 40 razy nie wygrywał automatycznie z takim, który mówi to 4 razy w ciaśniejszym, bardziej trafnym fragmencie. b (domyślnie 0,75) kontroluje normalizację długości dokumentu: decyduje, jak surowo BM25 karze długie dokumenty za to, że naturalnie zawierają więcej dopasowań.

Złe ustawienie b to częsty, realny błąd dostrajania. Krótkie dokumenty techniczne (logi błędów, tytuły produktów) chcą niższego b, bo wariancja długości jest mała; długie treści (strony dokumentacji, artykuły) zwykle chcą b bliżej wartości domyślnej. Podstawową słabością BM25 jest niedopasowanie słownictwa: jeśli użytkownik pyta „jak odzyskać pieniądze", a dokument mówi tylko „polityka zwrotów", BM25 nie znajduje wspólnych tokenów i nie zwraca nic użytecznego.

Mechanika gęstego wyszukiwania wektorowego (i gdzie się psuje)

Wyszukiwanie wektorowe odwzorowuje tekst w embeddingi o stałym wymiarze za pomocą modelu, a potem znajduje bliskie wektory przez podobieństwo cosinusowe lub iloczyn skalarny, zwykle przyspieszane indeksem przybliżonych najbliższych sąsiadów (ANN). HNSW to dominujący algorytm w Weaviate, Qdrant i Milvus: oddaje odrobinę recallu w zamian za dużą prędkość na skalę.

To właśnie naprawia problem niedopasowania słownictwa w BM25: „odzyskać pieniądze" i „polityka zwrotów" lądują blisko siebie w przestrzeni embeddingów nawet przy zerowej liczbie wspólnych tokenów, bo model wychwytuje znaczenie, a nie formę powierzchniową. Wybór właściwego modelu ma tu ogromne znaczenie. Zobacz nasz przewodnik po wyborze właściwego modelu embeddingowego i nasze zestawienie porównania embeddingów Voyage, OpenAI i Cohere, jeśli ważysz opcje.

Ale gęste pozyskiwanie ma własną ślepą plamkę, i jest ona lustrzanym odbiciem słabości BM25. Kiedy budujemy systemy RAG dla klientów, najczęściej spotykana awaria dokładnego dopasowania nie jest egzotyczna. To agent wsparcia pytający o konkretny numer zamówienia lub SKU, a indeks wektorowy z pełną pewnością zwraca coś semantycznie podobnego, ale błędnego. Ogólny model embeddingowy nie ma powodu, by umieszczać „SKU-4471" czy „ERR_CONN_RST" blisko właściwego ciągu zamiast przy powiązanym, lecz błędnym tokenie, bo takie ciągi rzadko pojawiają się w danych treningowych jako odrębne, izolowane pojęcia. BigData Boutique dokumentuje dokładnie ten wzorzec awarii na własnych przykładach SKU i kodów błędów. To dobrze ustalony, niezależnie potwierdzony fenomen wdrożeń RAG, a nie jednostkowy wybryk.

Jak połączyć BM25 i wyszukiwanie wektorowe: RRF vs fuzja ważona alfą

Istnieją dwa realne sposoby fuzji wyników BM25 i wektora, a prawie nikt piszący o wyszukiwaniu hybrydowym nie zestawia ich jasno. Reciprocal Rank Fusion (RRF), z pracy SIGIR z 2009 roku Cormacka, Clarke'a i Buettchera, operuje na rangach: score = sum(1 / (k + rank_i)) po każdej liście wyników, przy k zwykle ustawionym na 60. Ponieważ liczy się tylko pozycja, a nie surowy wynik, RRF bez problemu znosi różnice skali między nieograniczonymi wynikami BM25 a zakresem 0-1 podobieństwa cosinusowego i nie wymaga dostrajania pod korpus.

Fuzja ważona alfą (wypukła) działa inaczej: final = alpha * dense_score + (1 - alpha) * sparse_score, operując na znormalizowanych wynikach zamiast na rangach. Potrafi lepiej odzwierciedlić wielkość pewności (trafienie wektorowe przy podobieństwie 0,95 naprawdę wygląda mocniej niż przy 0,61), ale wymaga dostrajania alpha pod każdy korpus, a to dostrajanie psuje się po cichu, gdy zmienia się rozkład wyników (nowy model embeddingowy, przeindeksowany korpus, inna mieszanka zapytań).

W praktyce wybór sprowadza się do tego, jak bardzo ufasz kalibracji swoich wyników. Przy zwykłym BM25 wobec jednego, stabilnego modelu embeddingowego ważenie alfą może wycisnąć nieco lepszy ranking, bo używa rzeczywistej różnicy wyników, nie tylko pozycji. Ale ta kalibracja dryfuje bardziej, niż ludzie myślą. Podmień wersję modelu embeddingowego, potnij dokumenty na nowo albo dodaj etap rerankingu wyżej, a rozkład wyników gęstych się przesunie. Nikt nie dostaje page'a, gdy alpha=0,6 przestaje być właściwą wartością; ranking po prostu po cichu robi się trochę gorszy i łatwo to przegapić, jeśli regularnie nie uruchamiasz ewaluacji pozyskiwania. RRF omija to całkowicie, bo nigdy nie patrzy na surowe wyniki, tylko na pozycję w rankingu, więc przeindeksowanie albo podmiana modelu nie może go zepsuć po cichu tak, jak potrafi zepsuć ważenie alfą.

RRF nie wymaga dostrajania pod korpus; ważenie alfa potrzebuje ciągłego niańczenia, gdy Twoje dane się zmieniają.

Silniki różnią się w domyślnych ustawieniach. Weaviate udostępnia zarówno RRF, jak i parametr alpha, który ustawiasz jawnie. Elasticsearch dostarcza natywne RRF przez API retriever (sprawdź dokładne bramkowanie wersją w swoim wdrożeniu; wylądowało to w linii 8.x). Qdrant wspiera RRF natywnie przez Query API. Funkcja hybrydowa Pinecone zwykle opiera się na ważonej alfą kombinacji wypukłej zamiast wystawiać RRF bezpośrednio. Jeśli nie wiesz, po co sięgnąć, zacznij od RRF. To domyślny wybór o niższych kosztach utrzymania.

RRF od zera: neutralny vendorowo przykład w Pythonie

Każda próbka kodu RRF, którą znaleźliśmy w konkurencyjnych przewodnikach, jest przywiązana do SDK jednego vendora: klienta Weaviate, klienta Qdrant, klienta Pinecone. Oto wersja bez frameworka, którą wrzucisz do dowolnego stacku, z k=60 jako standardową wartością domyślną:

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 cały algorytm. Bez SDK, bez lock-inu vendorowego, i działa niezależnie, czy Twoje dwie listy rankingowe pochodzą z Elasticsearcha i indeksu Faiss, czy z Postgresowego ts_rank i pgvector. Jeśli uruchamiasz modele sam, zamiast uderzać do API, zobacz uruchamianie modeli embeddingowych lokalnie z Ollamą.

Postgres + pgvector: wyszukiwanie hybrydowe bez dedykowanej bazy wektorowej

Nie potrzebujesz dedykowanej bazy wektorowej, żeby uruchomić wyszukiwanie hybrydowe. Według benchmarku pg_textsearch/pgvector autorstwa programisty Pedro Alonso (Postgres 17, pg_textsearch 1.3.0, pgvector 0.8.2, embeddingi nomic-embed-text, zbiór BEIR SciFact) pojedyncza instancja Postgresa z natywnym ts_rank osiągnęła zaledwie 0,07 NDCG@10, daleko za 0,69 BM25, 0,66 pgvector i 0,70 hybrydy, wszystko w jednej instancji, przy medianie około 11,5 ms dla hybrydowego RRF.

Te 0,07 to znak rozpoznawczy: wbudowany ts_rank Postgresa to ranker gęstości pokrycia (cover-density), a nie prawdziwe BM25. Jeśli chcesz prawdziwej punktacji BM25 w Postgresie, potrzebujesz rozszerzenia. pg_textsearch, VectorChord i ParadeDB dodają porządny ranking w stylu BM25, którego natywny ts_rank nie zapewnia. Sparuj jedno z nich z pgvector do gęstego podobieństwa, scal dwie listy rankingowe powyższą funkcją RRF i masz wyszukiwanie hybrydowe w pojedynczej instancji Postgresa bez żadnej dodatkowej infrastruktury.

W przybliżeniu tak wygląda to sparowanie w jednym zapytaniu, łączącym rangę leksykalną z rozszerzenia obsługującego BM25 z odległością wektorową z 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);

Wrzuć oba zbiory wyników do powyższej funkcji RRF i masz wyszukiwanie hybrydowe w jednej instancji Postgresa. Uczciwe ograniczenie: to trzyma się dobrze do kilku milionów wierszy, ale Postgres nie został zbudowany jako dedykowany silnik pozyskiwania. Sam odpowiadasz za dostrajanie indeksów, zwykły ts_rank_cd bez rozszerzenia wciąż nie jest prawdziwym BM25 i nie dostajesz wbudowanego rerankingu ani obsługi wielu wektorów, które Weaviate czy Milvus dostarczają natywnie. Jeśli Twój korpus jest mały lub średni i już używasz Postgresa, oszczędzasz sobie całego drugiego kawałka infrastruktury. Powyżej dziesiątek milionów dokumentów albo gdy potrzebujesz zaawansowanego rerankingu, dedykowany silnik zarabia na swoje utrzymanie.

Jeśli szerzej rozważasz Qdrant, Chroma lub pgvector dla swojego stacku, to osobna decyzja niż sama metoda fuzji. Zobacz nasze porównanie Qdrant, Chroma i pgvector po trade-offy.

Które bazy wektorowe wspierają natywne wyszukiwanie hybrydowe?

Większość nowoczesnych baz wektorowych dostarcza dziś wyszukiwanie hybrydowe prosto z pudełka, ale domyślna metoda fuzji różni się znacząco.

Zweryfikuj dokładne bramkowanie wersją, zanim się zdecydujesz. Funkcje hybrydowe lądują szybko w tych silnikach przez cały 2026 rok, a kształty API zmieniają się z wydania na wydanie. Po szerszą decyzję zakupową wykraczającą poza mechanikę fuzji zajrzyj do naszego pełnego zestawienia najlepszych baz wektorowych.

Czy wyszukiwanie hybrydowe jest warte tej złożoności?

Wyszukiwanie hybrydowe jest architektonicznie słuszne, gdy Twój korpus ma zarówno wzorce dokładnego dopasowania (SKU, identyfikatory, rzadkie terminy), jak i konceptualne, parafrazowane zapytania. Jeśli Twój korpus nie ma żadnego z nich (czysto narracyjne treści, bez identyfikatorów, których ktoś szukałby dosłownym ciągiem), możesz dodać złożoność fuzji dla zysku, którego ledwie zauważysz.

Pomyśl, jak w praktyce wygląda „tylko narracja": archiwum firmowego bloga, wewnętrzna wiki inżynierska pełna runbooków pisanych prozą, strona dokumentacji, której nikt nie przeszukuje po ID produktu czy numerze zgłoszenia. W takich korpusach samo wyszukiwanie wektorowe zwykle dowozi większość wartości, a etap fuzji dokłada tylko drugi przebieg pozyskiwania i parametr, który ktoś teraz musi pilnować, dla zysku zaokrąglającego się do szumu. Porównaj to z systemem ticketów wsparcia albo katalogiem e-commerce, gdzie SKU, numery zamówień i kody modeli pojawiają się w realnych zapytaniach użytkowników bez przerwy. To jest właściwy test: wyciągnij dziesięć prawdziwych zapytań z własnych logów i policz, ile zawiera dokładny identyfikator, którego model embeddingowy oparty na parafrazie nigdy nie umiejscowi poprawnie. Zero? Odpuść hybrydę. Więcej niż jeden czy dwa? Buduj.

Wyszukiwanie hybrydowe nie jest uniwersalnym ulepszeniem: jeśli Twój korpus nie ma SKU, identyfikatorów ani wyszukiwań rzadkich terminów, możesz dokładać złożoność fuzji dla zysku, którego nigdy nie zauważysz.

Koszt jest realny, ale ograniczony: drugi przebieg pozyskiwania, krok fuzji i parametr ważenia, który ktoś teraz musi pilnować. Celowo nie cytujemy tu liczby opóźnień, bo krążące po sieci pochodzą z nienazwanych konfiguracji na nienazwanym sprzęcie, a Twoje będą inne. Zmierz to na własnym korpusie, zanim zdecydujesz. Dwa wątki na Hacker News dobrze oddają napięcie praktyków: "Hybrid Search Is Just the Beginning: Optimizing the R in RAG" i "Better RAG Results with Reciprocal Rank Fusion and Hybrid Search". Oba wątki sprzeciwiają się przyjmowaniu hybrydy jako cargo-cultowej najlepszej praktyki bez wcześniejszego sprawdzenia, czy Twój korpus w ogóle ma wzorce zapytań, które ma ona rozwiązywać. Zanim ją zbudujesz, warto zrozumieć, jak naprawdę mierzyć jakość pozyskiwania: liczby NDCG i recall@k znaczą cokolwiek tylko wobec własnego korpusu, a nie zbioru benchmarkowego.

Nasze zdanie: domyślnie wybieraj hybrydę dla każdego systemu RAG obsługującego zapytania wsparcia, e-commerce lub ticketowe kierowane przez użytkowników. Te obciążenia prawie zawsze mieszają identyfikatory z językiem naturalnym. Pomiń ją dla korpusów czysto narracyjnych (długie dokumenty, wiki narracyjne), dopóki nie zmierzysz realnej luki, którą pozostawia pozyskiwanie jedną metodą.

O autorze

Mert Batur jest współzałożycielem Techsy.io, gdzie zespół dostarcza agentów AI, systemy automatyzacji i pipeline'y głosowe/SDR dla klientów B2B. Pisze o stacku narzędzi LLM, którego zespół Techsy faktycznie używa na produkcji. Połącz się na LinkedIn.

Często zadawane pytania

Czym jest wyszukiwanie hybrydowe w RAG?

Wyszukiwanie hybrydowe uruchamia pozyskiwanie BM25 (słowa kluczowe) i wektorowe (semantyczne) jako osobne przebiegi na tym samym zapytaniu, a następnie scala dwie listy rankingowe algorytmem fuzji, zwykle Reciprocal Rank Fusion. Łapie zarówno zapytania dokładnego dopasowania, jak i parafrazowane, konceptualne, których żadna z metod nie obsłuży sama.

Czy BM25 to to samo co wyszukiwanie wektorowe?

Nie. BM25 to rzadkie wyszukiwanie leksykalne, które punktuje dokładne pokrycie terminów i ich rzadkość. Wyszukiwanie wektorowe to gęste wyszukiwanie semantyczne używające embeddingów i matematyki podobieństwa. To dwie różne metody pozyskiwania o przeciwnych mocnych stronach; wyszukiwanie hybrydowe łączy je, a nie zastępuje którąkolwiek.

Jak połączyć BM25 i wyszukiwanie wektorowe?

Uruchom obie metody pozyskiwania niezależnie na tym samym zapytaniu, a potem scal dwie listy rankingowe, najczęściej przez Reciprocal Rank Fusion, które sumuje 1 / (k + rank) po każdej liście. Alternatywą jest ważona alfą kombinacja wyników, ale wymaga dostrajania pod korpus, którego RRF nie potrzebuje.

Czym jest Reciprocal Rank Fusion (RRF)?

RRF to algorytm fuzji z pracy SIGIR Cormacka, Clarke'a i Buettchera z 2009 roku, który łączy wiele list rankingowych, sumując 1 / (k + rank) dla każdego dokumentu, przy k zwykle ustawionym na 60. Działa na pozycji w rankingu, nie na surowych wynikach, więc pozostaje stabilny mimo różnic skali między metodami pozyskiwania.

Jaka jest różnica między RRF a fuzją ważoną alfą?

RRF łączy rangi i nie wymaga dostrajania pod korpus. Fuzja ważona alfą łączy znormalizowane wyniki za pomocą konfigurowalnego parametru alpha, co potrafi lepiej odzwierciedlić wielkość pewności, ale wymaga ciągłego przestrajania przy każdej zmianie rozkładu wyników, na przykład po przeindeksowaniu lub zmianie modelu.

Kiedy użyć wyszukiwania hybrydowego zamiast samego wektorowego?

Użyj wyszukiwania hybrydowego, gdy Twoje zapytania mieszają dokładne identyfikatory (SKU, numery zamówień, kody błędów) z konceptualnymi pytaniami w języku naturalnym; wsparcie, e-commerce i systemy ticketowe zwykle tak robią. Pomiń je dla treści czysto narracyjnych bez identyfikatorów, gdzie dodatkowa złożoność fuzji prawdopodobnie nie pokaże mierzalnego zysku.

Dlaczego wyszukiwanie wektorowe przegapia dokładne dopasowania jak SKU czy kody błędów?

Modele embeddingowe uczą się z ogólnych wzorców językowych, a ciągi takie jak „SKU-4471" czy „ERR_CONN_RST" rzadko pojawiają się w danych treningowych jako odrębne, izolowane pojęcia. Model nie ma silnego powodu, by umieszczać ten dokładny ciąg bliżej siebie niż semantycznie powiązany, lecz błędny token.

Które bazy wektorowe wspierają wyszukiwanie hybrydowe natywnie?

Weaviate, Qdrant, Elasticsearch, OpenSearch, Vespa i Milvus dostarczają natywne wyszukiwanie hybrydowe w 2026 roku, choć różnią się domyślną metodą fuzji (RRF vs ważona alfa vs normalizacja). Postgres z pgvector też potrafi uruchomić wyszukiwanie hybrydowe, ale potrzebuje rozszerzenia BM25, bo natywny ts_rank nie jest prawdziwym BM25.

Czy wyszukiwanie hybrydowe jest warte dodatkowej złożoności?

Dla korpusów mieszających zapytania dokładnego dopasowania i konceptualne, tak. Czyste RRF już pokonuje każdą pojedynczą metodę w benchmarku WANDS (0,7068 wobec 0,6983 BM25), a wariant dostrojony osiąga wzrost o 7,4% (0,7497). Dla korpusów czysto narracyjnych bez identyfikatorów drugi przebieg pozyskiwania i dostrajanie fuzji mogą przeważyć nad zyskiem, którego nie zauważysz. Mierz, zanim się zdecydujesz.

Czy Postgres/pgvector potrafi wyszukiwanie hybrydowe bez dedykowanej bazy wektorowej?

Tak. Sparuj pgvector do gęstego podobieństwa z prawdziwym rozszerzeniem BM25, takim jak pg_textsearch, VectorChord lub ParadeDB (sam natywny ts_rank osiągnął zaledwie 0,07 NDCG@10 w benchmarku pg_textsearch/pgvector Pedro Alonso, wobec 0,70 dla hybrydy), a następnie scal dwie listy rankingowe przez RRF, wszystko wewnątrz jednej instancji Postgresa.

Obie metody pozyskiwania zostawiają realne luki, gdy działają same: BM25 przegapia parafrazy, wyszukiwanie wektorowe przegapia dokładne identyfikatory, a ich fuzja przez RRF to tańszy w utrzymaniu sposób na zamknięcie obu. Jeśli rozważasz, czy zbudować to sam, czy sprowadzić zespół, który już dostarczał pozyskiwanie RAG, nasz pełny przewodnik po budowie aplikacji RAG opisuje następny krok, albo odezwij się, jeśli wolisz, żeby Techsy zbudowało to z Tobą.