Baza wektorowa czy zwykłe wyszukiwanie po słowach kluczowych: kiedy co wygrywa

Każdy projekt wyszukiwania zaczyna się jako pytanie zakupowe, a kończy jako pytanie redakcyjne. Zespoły pytają, jaką technologię kupić. Uczciwa odpowiedź zależy od tego, co wpisują użytkownicy i co naprawdę jest w dokumentach. Wyszukiwanie po słowach kluczowych dopasowuje dosłowne tokeny, wyszukiwanie wektorowe dopasowuje znaczenie przez embeddingi i żadne z nich nie wygrywa na całej linii. Model językowy potrafi rozumować tylko na fragmentach, które mu podasz, więc to w retrievalu rozstrzyga się poprawność. Zły wybór daje pewne siebie odpowiedzi zbudowane na niewłaściwym dokumencie, co wygląda lepiej niż brak odpowiedzi tylko pozornie.

Gdzie słowa kluczowe nadal wygrywają

Dokładne identyfikatory to przypadek prosty. Numery katalogowe, SKU, kody błędów, numery faktur, paragrafy ustaw, nazwy chemiczne. Inżynierowie wsparcia i prawnicy znają wewnętrzne słownictwo i wpisują je precyzyjnie. Rzadkie tokeny embeddingi spłaszczają, bo model uczony na ogólnych tekstach nie ma sensownej reprezentacji dla "TX-4471-B". Operacyjnie też zostaje prosto: żadnego kroku embeddowania, żadnej wersji modelu do pilnowania, tanie przebudowanie indeksu i dopasowany termin, który każdy może wskazać palcem. Na małych zbiorach dobrze dostrojony indeks BM25 odpowiada na wszystko i nie dokłada nic do utrzymania.

Wskazówka: jeśli potrafisz przewidzieć dokładny ciąg znaków, który wpisze użytkownik, indeks słów kluczowych prawie zawsze pobije embedding.

Gdzie wyszukiwanie wektorowe zarabia na siebie

Rozjazd słownictwa to codzienny powód, dla którego sięgamy po wektory. Ktoś pisze "moja karta została odrzucona", a dokument mówi "błąd autoryzacji na etapie rozliczenia". Długie pytania w naturalnym języku często nie niosą żadnego rozstrzygającego słowa kluczowego. Zbiory wielojęzyczne wymagają, żeby pytanie w jednym języku dotarło do dokumentu napisanego w innym, a działy piszące przez wiele lat zostawiają po sobie ciąg niespójnych określeń na jedno pojęcie. Pytania o zasady czy procedury opierają się na temacie, nie na sformułowaniu. Chunking waży tu tyle samo co model. Wektor reprezentuje ten tekst, który zapisałeś razem, i nic więcej.

Tryby awarii, których nikt nie pokazuje na demie

• Wyszukiwanie wektorowe zawsze coś zwróci; najbliższy sąsiad bzdury nadal wygląda jak trafienie.
• Podobieństwo semantyczne ignoruje przeczenia, daty i wersje, więc wycofana procedura punktuje tak samo wysoko jak obowiązująca.
• Wyszukiwanie po słowach kluczowych zawodzi w drugą stronę: zwraca zero wyników, gdy słowo użytkownika jest synonimem tego z indeksu.
• Podmiana modelu embeddingów przesuwa przestrzeń i wymusza pełne przebudowanie indeksu.
• Filtry i uprawnienia działają czysto na indeksach słów kluczowych, a w bazach wektorowych wymagają jawnej obsługi metadanych.

Wskazówka: testuj obie metody na prawdziwych pytaniach wyciągniętych ze skrzynki wsparcia, nigdy na pytaniach wymyślonych przez zespół budujący system.

Retrieval hybrydowy jako ustawienie domyślne

Zwykle uruchamiamy oba i łączymy wyniki. Logi produkcyjne mieszają szukanie identyfikatorów z mglistymi pytaniami o pojęcia, więc po co udawać, że jest inaczej? Reciprocal rank fusion albo ważone wyniki łączą dwie listy rankingowe bez wciskania ich w jedną skalę, a przejście reranking po połączonych kandydatach często daje więcej jakości niż wymiana modelu embeddingów. Hybryda kosztuje więcej w utrzymaniu, więc traktuj ją jako decyzję, a nie bezrefleksyjne ustawienie domyślne.

1. Filtruj po metadanych: typ dokumentu, data, dział, poziom dostępu.
2. Pobierz wyniki dwa razy, po słowach kluczowych i wektorowo.
3. Połącz obie listy rankingowe.
4. Przepuść scalonych kandydatów przez reranking.
5. Utnij do budżetu tokenów i podaj modelowi razem ze źródłami.

Co decyduje za ciebie infrastruktura

Istniejąca infrastruktura wyszukiwania często obsługuje już oba tryby, co po cichu wyrzuca jeden komponent z architektury. Wdrożenie on-premise dokłada ograniczeń: model embeddingów działa lokalnie, a dostępność GPU wyznacza granice tego, co realne. Zarządzane bazy wektorowe w chmurze są tanie na start i trudniejsze do opuszczenia później. Rozmiar indeksu, częstotliwość aktualizacji i budżet opóźnień zawężają pole szybciej niż jakikolwiek benchmark jakości. Cokolwiek wybierzesz, musi zwracać rozpoznawalne odwołania do dokumentów, nie same wyniki punktowe, żeby odpowiedź mogła przynieść ze sobą fragment źródłowy.

Jak decydujemy w praktyce

Weź kilkaset prawdziwych pytań i posortuj je na dokładne wyszukiwanie, pojęciowe i mieszane. Najpierw zbuduj bazę odniesienia na słowach kluczowych. Jest tania i pokazuje, ile naprawdę zostało pola do poprawy. Mierz retrieval osobno od generowania, bo poprawna odpowiedź na złym fragmencie to szczęśliwy traf. Sygnały pchające w stronę wektorów: parafraza, wiele języków, niespójna terminologia, długie pytania. Sygnały pchające w stronę słów kluczowych: identyfikatory, użytkownicy eksperci, stabilne słownictwo, małe zbiory. Potem oceń to jeszcze raz, gdy asystent już działa, bo prawdziwe użycie zawsze różni się od tego, co zespół sobie wyobraził.

FAQ

Potrzebujemy dedykowanej bazy wektorowej, czy wystarczy rozszerzenie wektorowe do bazy, którą już mamy?

Dla większości zbiorów wystarczy rozszerzenie do bazy, którą zespół już utrzymuje, i jest dużo łatwiejsze w obsłudze. Dedykowane bazy zaczynają się opłacać przy dużej skali i wysokim ruchu zapytań. Zważ koszt kolejnej usługi wobec tego, co znacie.

Czy lepszy model embeddingów naprawi słaby retrieval?

Rzadko. Chunking, metadane i przejście reranking dają zwykle więcej niż sam model. Jeśli fragmenty są źle pocięte albo brakuje im dat i typów dokumentów, żaden embedding tego nie odzyska.

Czy możemy uruchomić wyszukiwanie semantyczne w całości na własnej infrastrukturze?

Tak. Lokalne modele embeddingów są praktyczne przy umiarkowanej mocy GPU, a zajętość indeksu daje się przewidzieć. Środowiska regulowane często zaczynają właśnie tutaj, dokładnie dlatego, że żaden dokument nie opuszcza firmy.

Podsumowanie

Wyszukiwanie po słowach kluczowych wygrywa precyzją i dokładnymi tokenami. Wyszukiwanie wektorowe wygrywa na parafrazie i pojęciach. Większość prawdziwych zbiorów zawiera oba rodzaje pytań i dlatego retrieval hybrydowy raz po raz okazuje się punktem dojścia. Decyzja należy do twoich dokumentów i twoich użytkowników, nie do tabeli z benchmarkiem. A niezależnie od wyboru, odpowiedź powinna przychodzić razem z fragmentem, z którego pochodzi, żeby czytelnik mógł ją sprawdzić.