BM25, embeddings i rerankery: wybór etapów wyszukiwania

Tłumaczenie automatyczne

Ten artykuł został automatycznie przetłumaczony z angielskiego oryginału.

BM25 szereguje tekst według dopasowania terminów zapytania. Embeddings znajdują kandydatów o podobnym znaczeniu. Reranker ponownie ocenia znalezionych kandydatów, aby poprawić ich kolejność. Dla inżynierów budujących systemy wyszukiwania lub RAG te etapy rozwiązują różne problemy i należy je testować osobno.

Zacznij od BM25 i egzekwuj uprawnienia dostępu do dokumentów. Dodaj embeddings, gdy brakuje trafnych fragmentów, ponieważ zapytanie używa innych słów. Dodaj reranker, gdy właściwe fragmenty zostają znalezione, ale pojawiają się zbyt nisko na liście. Zachowaj każdy etap tylko wtedy, gdy poprawia wyniki na oznaczonych danych w ramach budżetu czasu i kosztu.

Na przykład zapytanie o ERR-42 wymaga poprawnej obsługi identyfikatorów. Pytanie o błąd po wybudzeniu może wymagać dopasowania semantycznego, jeśli instrukcja mówi o „błędzie wznowienia”. Reranking pomaga dopiero wtedy, gdy potrzebny fragment trafi do zbioru kandydatów.

Co robi każdy etap

EtapMetodaZadanie
FiltrowanieFiltry strukturalneEgzekwowanie ograniczeń dotyczących tenanta, uprawnień, produktu, języka, czasu i dostępności.
Wyszukiwanie leksykalneBM25Dopasowywanie terminów; zachowanie ID i kodów błędów za pomocą odpowiednich pól lub analizatorów.
Wyszukiwanie gęsteEmbeddingsSynonimy, parafrazy, nieprecyzyjna intencja i recall semantyczny.
FuzjaReciprocal Rank Fusion lub ważone połączenie modułów wyszukiwaniaŁączenie kandydatów z wyszukiwania rzadkiego i gęstego bez zakładania, że ich oceny są porównywalne.
RerankingCross-encoderOdczytanie zapytania wraz z każdym kandydatem w celu oceny krótkiej listy.
Końcowa precyzjaReranker oparty na LLM lub model odpowiedziRozstrzyganie niuansów trafności dopiero wtedy, gdy lista jest krótka.
EwaluacjaRecall@k, nDCG, MRR, etykiety kliknięć, etykiety nadane przez ludziSprawdzenie, czy każdy dodany etap poprawia wynik bazowy.

Punkty wyjścia dla różnych zastosowań

ProduktPodejście do przetestowaniaDlaczego
Wyszukiwanie w dokumentacjiBM25 plus embeddings plus cross-encoderWażne są zarówno dokładne nazwy API, jak i pytania semantyczne.
Wyszukiwanie dla RAGBazowe BM25; porównanie wyszukiwania hybrydowego i rerankinguOcena pokrycia dowodów, uzasadnienia odpowiedzi i opóźnienia.
Wyszukiwanie produktówFiltry leksykalne plus wyszukiwanie hybrydowe plus cechy biznesoweWażne są dostępność, cena, popularność i dokładne facety.
Wyszukiwanie dla wsparciaWyszukiwanie hybrydowe plus aktualność i metadane zgłoszeńWażne są zarówno podobne sformułowania, jak i aktualne zasady.
Wewnętrzna baza wiedzyBazowe BM25, następnie wyszukiwanie gęste na podstawie logów zapytańZacznij od mierzalnych wyników, zanim dodasz koszty modeli.
Wyszukiwanie prawne lub dotyczące zgodnościBazowe wyszukiwanie leksykalne plus ścisłe filtry, następnie ostrożne rozszerzanie semantyczneZarówno wyniki fałszywie dodatnie, jak i fałszywie ujemne są kosztowne.

Dlaczego BM25 nadal należy do systemu

Embeddings znajdują tekst o podobnym znaczeniu, ale nie zastępują niezawodnie dokładnego dopasowania. Kody błędów, nazwy funkcji, SKU produktów, sformułowania prawne i nazwiska często wyrażają intencję poprzez dokładną pisownię. BM25 jest użytecznym punktem odniesienia, ponieważ premiuje dopasowane terminy. Analiza tekstu może zmieniać te terminy: standardowy analizator Elasticsearch dzieli tekst i zamienia litery na małe. Zachowuj identyfikatory wrażliwe na interpunkcję, takie jak ERR-42, za pomocą odpowiedniego analizatora lub pola przechowującego dokładną wartość. Ranking BM25 nie gwarantuje dokładnej równości ciągów znaków.

Wyszukiwanie gęste może dodawać trafne wyniki, gdy użytkownicy nie znają słownictwa dokumentu. Testuj je równolegle z BM25. Jeśli oba moduły wyszukiwania znajdują użyteczne, uzupełniające się wyniki, RRF może połączyć ich uszeregowane listy. Wykorzystuje pozycje wyników zamiast porównywać surowe oceny leksykalne i oceny embeddings.

Kiedy dodać reranker

Dodaj cross-encoder, gdy trafne dokumenty trafiają do zbioru kandydatów, ale zajmują zbyt niskie pozycje. Cross-encoder odczytuje zapytanie wraz z każdym dokumentem kandydującym. Wymaga to przejścia przez model dla każdej pary, dlatego stosuj go do krótkiej listy. Wybierz liczbę kandydatów na podstawie zmierzonego recall i opóźnienia; pierwszych 50 to użyteczny eksperyment, a nie uniwersalny próg.

Przetestuj reranker oparty na LLM, gdy cross-encoder pomija różnice potrzebne w Twojej aplikacji, na przykład to, która wersja zasad obowiązuje. Dodaje obliczenia modelu, których koszt zależy od liczby kandydatów i długości danych wejściowych. Porównaj jakość, opóźnienie i koszt na tej samej krótkiej liście, zanim go zachowasz.

Recall@k mierzy, jaka część oznaczonego trafnego materiału pojawia się w pierwszych k wynikach. MRR premiuje wysoką pozycję pierwszego trafnego wyniku; nDCG mierzy kolejność, gdy etykiety mają różne poziomy trafności. Precision@1 sprawdza, czy pierwszy wynik jest trafny.

Sekwencja ewaluacji

  1. Oznacz rzeczywiste zapytania obejmujące istotne intencje, języki, uprawnienia i koszty błędów. Zacznij od małego zbioru i rozszerzaj go, aż podgrupy i niepewność będą wystarczające do podjęcia decyzji.
  2. Zmierz samo BM25.
  3. Przetestuj wyszukiwanie gęste, gdy BM25 pomija trafne fragmenty.
  4. Jeśli oba zbiory wyników się uzupełniają, przetestuj fuzję za pomocą nDCG i Recall@k.
  5. Przetestuj reranking z użyciem modelu cross-encoder, gdy trafni kandydaci zajmują zbyt niskie pozycje; zmierz Precision@1 i nDCG.
  6. Dodaj reranking przez LLM tylko wtedy, gdy poprawia jakość po uwzględnieniu kosztu i opóźnienia.
  7. Monitoruj metryki produkcyjne: odsetek zapytań bez wyników, odsetek przeformułowań, współczynnik kliknięć, korekty odpowiedzi, opóźnienie p95 i koszt.

Dalsza lektura

Źródła