Dlaczego Enterprise RAG potrzebuje hybrydowego wyszukiwania, a nie tylko wektorów

Największym błędem rozumieniem w RAG dla przedsiębiorstw jest przekonanie, że lepsze embeddingi automatycznie zapewniają lepsze odpowiedzi. Jakość odpowiedzi zależy znacznie bardziej od tego, co zostanie odzyskane, niż od tego, jaki model czatowy jest używany.

Wprowadzenie

Retrieval-Augmented Generation umożliwia asystentom czerpanie informacji z zewnętrznej wiedzy przed wydaniem odpowiedzi. Większość demonstracji stawia szukanie wektorowe w centrum:

Documents
    │
Chunking
    │
Embedding Model
    │
Vector Database
    │
Top-K Retrieval
    │
Large Language Model

Zaimportuj dokumenty, przechowaj wektory i odzyskaj najbliższe sąsiady dla każdego zapytania. Taki model sprawdza się w demonstracjach, ale często zawodzi w warunkach produkcyjnych – szczególnie w przedsiębiorstwach pełnych identyfikatorów. Samo szukanie wektorowe rzadko wystarcza. Szukanie hybrydowe stało się standardową strategią odzyskiwania informacji w zaawansowanych systemach RAG.

Dlaczego szukanie wektorowe stało się popularne

Motory słów kluczowych dopasowują tokeny. Zapytanie „Jak można sformatować hasło?” znajdzie dokumenty zawierające słowa reset/hasło/konto. Zapytanie „Nie mogę uzyskać dostępu do konta” może całkowicie pominąć dokumenty dotyczące haseł pomimo identycznej intencji. Embeddingi mapują znaczenie do przestrzeni wektorowej, więc parafrazy nadal powodują błędy dopasowania. Dla FAQ i dokumentów narracyjnych jest to przełom.

Gdzie czyste wektory zawodzą

Korpora firmy przedsiębiorstwowych są przepełnione numerami faktur, identyfikatorami pracowników, kodami błędów, SKU, identyfikatorami umów, numerami polis oraz łańcuchami wersji. Te łańcuchy są ważne dla użytkowników, ale stanowią trudność dla modeli o dużej gęstości informacji.

W przypadku takiego zapisu:

Invoice Number : INV-93842
Status         : Paid
Customer       : ABC Corporation

Zapytanie „Jaki jest status faktury INV-93842?” często zwraca przewodniki dotyczące rozliczeń zamiast samej faktury, ponieważ embeddingi kładą nacisk na pojęcia „faktura/rozliczenie” bardziej niż na dokładny identyfikator.

Kolejne sposoby awarii

Po wyszukiwaniu błędów w bazie danych:

ORA-12514

może zwracać ogólne przewodniki dotyczące łączności zamiast strony ORA-12514.

Zapytania dotyczące produktów, takie jak:

RTX-9000 Switch

może pokazywać przeglądy sieci zamiast instrukcji obsługi RTX-9000.

Pytania o wersje, dotyczące:

Version 4.3.12

często przynoszą ogólne notatki o wydaniu, a nie konkretnie te dotyczące wersji 4.3.12.

Zapytania w sektorze opieki zdrowotnej, dotyczące:

Patient ID: P-482731

może wyświetlać dokumenty procedur rejestracji zamiast danych pacjenta.

Gdy liczą się dokładne identyfikatory, sama podobieństwo semantyczne traci wiarygodność.

Dlaczego embeddingi mają tu trudności

Modele uczą się powiązań typu lekarz↔praktyk medyczny oraz samochód↔automobil. Wyrażenia takie jak:

INV-93842

lub

RTX-9000

zawierają niewiele treści semantycznej. Zmiana:

INV-93842

na

INV-93843

Zmienia się podmiot gospodarczy, podczas gdy wektory pozostają niemal identyczne. Jest to cecha charakterystyczna gęstego wyszukiwania, a nie błąd konkretnego dostawcy.

Rozdzielenie wyszukiwania w przedsiębiorstwach

Informacje semantyczne (zasady działania, proces składania roszczeń, reset hasła) – wektory radzą sobie doskonale. Informacje dokładne (identyfikatory, kody, SKU, wersje) – słowa kluczowe/BM25 radzą sobie najlepiej.

Użycie tylko jednej strategii oznacza doskonałość w jednym obszarze i trudności w drugim. Wyszukiwanie hybrydowe ma na celu pokrycie obu tych aspektów.

Wejdźmy w świat wyszukiwania hybrydowego

Zamiast BM25 lub wektorów, uruchommy oba i połączmy je:

User Query
                         │
        ┌────────────────┴────────────────┐
        │                                 │
        ▼                                 ▼
 Keyword Search (BM25)           Vector Search
        │                                 │
        └──────────────┬──────────────────┘
                       ▼
              Merge & Score Fusion
                       ▼
                 Cross-Encoder Re-ranker
                       ▼
                Top Relevant Context
                       ▼
                 Large Language Model

Wyszukiwanie słowami kluczowymi chroni identyfikatory oraz rzadkie tokeny. Wyszukiwanie wektorowe obejmuje synonimy oraz różne sformułowania. Funkcja ponownego rankingu (lub fuzja rankingu wzajemnego) uporządkowuje połączone kandydaty dla zapytania użytkownika.

Dlaczego wygrywa rozwiązanie hybrydowe

Dla zapytania „Dlaczego faktura INV-93842 wciąż czeka na zatwierdzenie?” system hybrydowy może dopasować dokładny identyfikator za pomocą słów kluczowych, pobrać powiązane dokumenty procesowe za pomocą wektorów oraz przeprowadzić ponowne rankowanie, tak aby rekord faktury znajdował się na czele, podczas gdy dokumenty procesowe pozostały dostępne. Każda z tych technik robi to, w czym jest najlepsza.

Ostateczne uwagi

Bazy danych wektorowych pozostają podstawą. Nie stanowią one pełnej zamiennicy klasycznych systemów wyszukiwania informacji. Wiedza przedsiębiorstwa składa się z tekstów, kodów i rekordów. Systemy hybrydowe uwzględniają tę mieszankę.

Lepszy model do rozmów nie może naprawić słabego zestawu kandydatów. Lepiej zainwestować w systemy wyszukiwania, które wielokrotnie pokazują właściwe fragmenty, zamiast wydawać budżet na bardziej zaawansowane generatory lub efektowniejsze prompty — w systemach RAG jakość odpowiedzi zależy przede wszystkim od jakości wyszukiwania.

Z punktu widzenia funkcjonalnego należy rejestrować, który węzeł przyczynił się do każdego wyniku wyszukiwania (słowo kluczowe vs treść zwięzła), dostosowywać wagi fuzji na zbiorze do oceny zawierającym zarówno pytania parafrazujące, jak i zapytania o wyszukiwanie identyfikatorów, oraz unikać deklarowania „RAG gotowe” po demonstracji obejmującej jedynie łagodne pytania semantyczne. Zapytania identyfikatorów to właśnie te testy przyjęcia, w których przedsiębiorstwa rzeczywiście ponoszą porażki w warunkach produkcyjnych.

Budowa hybrydy bez nadmiernych wysiłków

Należy zacząć od użycia BM25 (lub równoważnego wyszukiwania leksykalnego) obok istniejącego indeksu wektorowego — wiele baz danych wektorowych już oferuje hybrydowe interfejsy API. Należy utrzymać zgodność identyfikatorów fragmentów, aby fuzja była prosta. Najpierw należy zastosować metodę fuzji rankingu wzajemnego, zanim rozpocznie się trening ponownego sortera typu cross-encoder; RRF jest tani i często „dostatecznie dobry”, by udowodnić, że luka w funkcjonowaniu wyszukiwania identyfikatorów się zmniejsza.

Stwórz zbiór do oceny składający się z dwóch grup pytań: pytań wymagających parafrazowania (semantycznych) oraz pytań z identyfikatorami (dokładnych). Oceniaj oddanie informacji@k osobno. Wykorzystuj rozwiązanie hybrydowe tylko wtedy, gdy obie grupy poprawią się lub przynajmniej jedna poprawi się bez pogorszenia wyników drugiej. Zwracaj uwagę na opóźnienia: działanie dwóch systemów wyszukiwania równolegle zazwyczaj jest w porządku, natomiast sekwencyjne ponowne sortowanie ogromnych zbiorów kandydatów nie jest.

Strategia dzielenia tekstu na fragmenty nadal ma znaczenie. Identyfikatory ukryte w dużych fragmentach osłabiają zarówno wyniki BM25, jak i wyniki oparte na intensywności danych. Wolno preferować granice fragmentów, które zachowują nienaruszone nagłówki faktur, tytuły kodów błędów oraz linie z identyfikatorami SKU. Filtry metadanych (linia produktu, lokalizacja, typ dokumentu) dodatkowo zmniejszają liczbę błędnych wyników przed fuzją.

Na koniec należy poinformować zaangażowanych w produkt osoby: „Wbudowaliśmy wszystko” nie jest strategią wyszukiwania. Rozwiązanie hybrydowe to strategia odpowiadająca temu, w jaki sposób przedsiębiorstwa faktycznie zadają pytania — połową w języku naturalnym, a połową za pomocą identyfikatorów wpisywanych z ekranu.

Lista kontrolna wdrażania

1. Zbierz zapytania dotyczące inventarza z logów produkcyjnych; oznacz, które wymagają dokładnego dopasowania, a które parafrazy.
2. Zainstaluj wyszukiwanie leksykalne w tym samym korpusie i z tą samą strukturą identyfikatorów co indeks wektorowy.
3. Zintegruj je z RRF; rejestruj źródła informacji dla każdego wyniku.
4. Pomierz wskaźnik recall@k dla obu grup; dostosuj wagi.
5. Dopiero wtedy rozważ użycie uczonego narzędzia do ponownego sortowania, jeśli pozwala na to budżet opóźnień.
6. Zachowaj pola identyfikatorów w metadanych dla opcjonalnych filtrów sztywnych, gdy interfejs już zna numer faktury lub SKU.

Zespoły, które od razu przechodzą do „większych modeli embeddingów”, często ponownie napotykają te same problemy z identyfikatorami przy użyciu lepszych wektorów. Wyszukiwanie hybrydowe to nudne rozwiązanie, które odpowiada sposobowi formułowania zapytań.

Literatura pokrewna

• RAG wyjaśnione: Dostęp LLM do wiedzy zewnętrznej — Przewodnik po RAG przeznaczony dla początkujących: dzielenie na fragmenty, embeddingi, wyszukiwanie wektorowe, hybrydowe odzyskiwanie informacji oraz sytuacje, gdy RAG nadal tworzy halucynacje – z jasnymi diagramami architektury.
• RAG, RAG bez wektorów i GraphRAG w porównaniu — Klasyczny RAG oparty na wektorach, odzyskiwanie informacji bez wektorów leksykalnych oraz GraphRAG: dzielenie na fragmenty, embeddingi, BM25, grafy wieloetapowe oraz sytuacje, gdy każde z tych podejść jest najskuteczniejsze.
• GraphRAG z dostosowaniem do ontologii: Gdy wektory wymagają stypowanych relacji — Jak ankiety identyfikatorów, kontrakty ontologiczne, fuzja rankingu oraz mechanizmy cytowania lub odrzucenia naprawiają błędy RAG w przypadku CVE, wieloetapowej własności oraz niewypowiedzianych faktów grafowych.

Hybrydowe wyszukiwanie dla Enterprise RAG: Gęsta forma sama w sobie nie wystarcza — Dokładne identyfikatory i rzadkie kody psują embeddingi; BM25 w połączeniu z równoległą fuzją gęstych danych obejmuje rzeczywisty zestaw zapytań.