Poza Top-K: progi istotności, wyszukiwanie hybrydowe i ponowna klasyfikacja w RAG

Generowanie wzbogacone o wyszukiwanie jest zazwyczaj przedstawiane jako trójetapowy proces: znajdowanie dokumentów związanych z pytaniem, przekazanie ich modelowi językowemu i pozwolenie mu na napisanie odpowiedzi. Schemat jest prosty, ale uczynienie go niezawodnym to inna sprawa. Przepływ danych łączący bezpośrednio wyszukiwanie oparte na embeddingach z modelem językowym dużych modeli będzie udzielać pewnych odpowiedzi na podstawie słabego kontekstu, pomijać dokładne identyfikatory i udawać, że ma odpowiedź, gdy baza wiedzy nic nie zawiera. W tym miejscu pęknie ten naiwny projekt, a konkretne etapy – od dzielenia tekstu na fragmenty z uwzględnieniem struktury po mierzalną ocenę – przekształcą go w architekturę wyszukiwania, której można zaufać.

Naiwny przepływ danych i jego ukryte założenia

Baza, na której opierają się większość tutoriali, wygląda w ten sposób: dzieli dokumenty na fragmenty, wstawia je do modelu, przechowuje wektory, a podczas wyszukiwania wstawia pytanie, pobiera top_k najbliższych fragmentów i wkleja je do promptu. Działa to w demonstracji, ale zakłada bez słowa komentarza, że każdy fragment jest znaczącą jednostką oraz że „najbliższe” oznacza „istotne”.

Dzielenie według struktury dokumentu

Rozważmy podręcznik dla pracowników. Słaba metoda dzieli go na dowolne kawałki po 1000 znaków, co skutkuje rozcięciem polityki w połowie oraz przyklejeniem końca jednego tematu do początku innego. Silniejsza metoda kieruje się własnym podziałem dokumentu, tworząc fragmenty takie jak Praca zdalna, Bezpieczeństwo, Urlop i Wydatki.

Część samodzielna dostarcza modelowi embeddingowemu wystarczającego kontekstu, aby zrozumieć, o czym faktycznie jest tekst i jak ze sobą powiązane są jego stwierdzenia. W rezultacie wektory są czystsze, a wyszukiwanie semantyczne zwraca bardziej istotne wyniki.

Top-K zwraca najbliższe wyniki, a nie te istotne

Lepsze podziały tekstu prowadzą prosto do kolejnego błędnego założenia. Ustawienie top_k = 5 jest często interpretowane jako „daj mi pięć istotnych wyników”. W rzeczywistości oznacza to pięć najbliższych wyników, niezależnie od tego, czy któreś z nich są dobre. Typowa rozkład wartości dla pytania dotyczącego pracy zdalnej może wyglądać następująco:

Remote Work       0.62
Paid Time Off     0.36
Security          0.30
Expenses          0.28
Other Policy      0.24

Pierwszy wynik to prawdopodobnie to, czego potrzebuje użytkownik. Pozostałe cztery to słabe dopasowania, które znalazły się na liście tylko dlatego, że coś musiało wypełnić te miejsca. Przekazanie wszystkich pięciu do modelu miesza informacje użyteczne z tekstem ewentualnie przydatnym, słabo powiązanym i nieistotnym. Model musi teraz samodzielnie oddzielić sygnał od szumu, co zwiększa koszt tokenów i sprawia, że odpowiedź jest mniej przewidywalna.

Pytania bez możliwości odpowiedzi wymagają specjalnego podejścia

Bardzo ważnym przypadkiem jest pytanie, na które baza wiedzy po prostu nie może odpowiedzieć, np. „Jaka jest kwota wolna od opłat w ubezpieczeniu zdrowotnym firmy?”, gdy w podręczniku o tym w ogóle nie ma mowy. Metoda Top-K nadal zwróci pięć fragmentów, a prosty proces przetwarzania potraktuje najbliższy z nich jako dowód i spróbuje odgadnąć odpowiedź.

Prawidłowe zachowanie w środowisku przedsiębiorstwa polega na stwierdzeniu, że dostępne dokumenty nie zawierają wystarczających informacji. Dobrze zaprojektowany system powinien być w stanie zwrócić coś w rodzaju:

No sufficiently relevant context was found.

Dodanie filtru relewności pomiędzy wyszukiwaniem a modelem

Zarządzanie zarówno słabymi dopasowaniami, jak i pytaniami bez odpowiedzi wymaga dodatkowego etapu. Prosty przepływ jest następujący:

Vector Search
   ↓
Top-K
   ↓
LLM

Ulepszony przepływ traktuje Top-K jako listę kandydatów i wstawia filtr przed modelem:

Vector Search
   ↓
Top-K candidates
   ↓
Relevance Filter
   ↓
LLM

Najprostszym filtrem jest próg podobieństwa. Kandydaci na tym poziomie lub powyżej go przechodzą dalej:

score >= threshold
    → keep

a wszystko poniżej tego poziomu jest odrzucane:

score < threshold
    → discard

Jeśli nic nie przejdzie, system zwraca odpowiedź „brak istotnego kontekstu” zamiast wywoływać model z szumem.

Wybór progu na podstawie pomiarów

Progi powinny wynikać z danych. Jedno małe doświadczenie na zbiorze danych dotyczącym podręcznika przedsiębiorstwa porównało stopień odzyskiwania informacji w przypadku zapytań na które istnieją odpowiedzi („znanych”) z wskaźnikiem odrzucania zapytań bez odpowiedzi („nieznanych”) dla kilku różnych wartości:

| Threshold | Known-query recall | Unknown-query rejection |
| --------: | -----------------: | ----------------------: |
|      0.20 |               100% |                      0% |
|      0.25 |               100% |                      0% |
|      0.30 |               100% |                     50% |
|      0.35 |               100% |                     50% |
|      0.40 |               100% |                     50% |
|  **0.45** |           **100%** |                **100%** |
|      0.50 |               100% |                    100% |
|      0.55 |               100% |                    100% |

W tym zestawie danych 0,45 było pierwszą granicą, która zachowywała wszystkie znane zapytania, odrzucając jednocześnie wszystkie nieznane, co czyniło ją najlepszym rozwiązaniem wśród sprawdzonych wartości. Ta liczba nie jest przenośna – wyniki podobieństwa zależą od modelu embeddingowego, korpusu, sformułowania zapytań oraz konfiguracji systemu wyszukiwania; różne modele dają bardzo odmienne wyniki. Stopa odrzuceń zmieniająca się co 50% wskazuje również na bardzo małą liczbę nieznanych zapytań, dlatego w rzeczywistym zastosowaniu potrzebny jest większy zbiór oznaczonych przykładów, zanim można zaufać tej granicy. To, co może być przeniesione, to sama metoda: mierzenie zachowania systemu wyszukiwania w przypadku znanych i nieznanych zapytań oraz wybór granicy na podstawie uzyskanych dowodów, a nie intuicji.

Wyszukiwanie i ranking to różne zadania

Załóżmy, że proces wyszukiwania zwraca 20 kandydatów. Wykonał swoją pracę: znalazł 20 fragmentów tekstu, które prawdopodobnie są ze sobą powiązane. Pozostaje drugie pytanie: które z tych pięciu stanowią najlepszy kontekst dla tego konkretnego pytania? To właśnie jest zadaniem rerankingu.

Proces wyszukiwania jest optymalizowany pod kątem odzyskiwania jak największej liczby wyników z dużej kolekcji, redukując na przykład 10 000 fragmentów do zrozumiałej liczby kandydatów:

10,000 chunks
      ↓
retrieval
      ↓
50 candidates

Następnie reranking dokonuje ponownej oceny tego małego zestawu, zwykle przy użyciu modelu, który czyta pytanie wraz z każdym kandydatem i zachowuje te najsilniejsze:

50 candidates
      ↓
reranker
      ↓
5 strongest candidates

Proces teraz wygląda w ten sposób:

Question
   ↓
Embedding
   ↓
Vector / Hybrid Search
   ↓
Candidate Set
   ↓
Reranking
   ↓
Best Context
   ↓
LLM

Wyszukiwanie semantyczne pomija dokładne terminy

Embeddingi doskonale radzą sobie z znaczeniem, ale dane korporacyjne są pełne tokenów, których wartość leży w ich dokładnej pisowni:

INC-48271
ERR_CONNECTION_RESET
POL-104
AWS us-east-1
customer_12345

Model embedding może zrozumieć, że zapytanie dotyczy błędu połączenia, oceniając fragment zawierający dokładny kod ERR_CONNECTION_RESET jako mniej ważny niż ogólny akapit na temat sieci.

Hybrydowe wyszukiwanie łączy oba sygnały

Standardowym rozwiązaniem jest hybrydowe wyszukiwanie, które łączy w sobie wyszukiwanie semantyczne i leksykalne:

Semantic Search
+
Keyword / Lexical Search

Oba typy wyszukiwania są uruchamiane dla tego samego pytania, a ich wyniki łączą się w jeden zbiór kandydatów, często przy użyciu metody fuzji łączącej obie rankingi:

Question
                    │
          ┌─────────┴─────────┐
          ↓                   ↓
   Semantic Search      Keyword Search
          │                   │
          └─────────┬─────────┘
                    ↓
              Candidate Set

System zapewnia podobieństwo semantyczne dla zapytań sformułowanych inaczej oraz dokładne dopasowanie terminów dla identyfikatorów.

Pipeline skierowany do produkcji

Gdy wszystkie etapy są już wdrożone, pełny proces wygląda następująco:

Documents
    ↓
Semantic Chunking
    ↓
Embeddings
    ↓
Vector / Hybrid Retrieval
    ↓
Relevance Filtering
    ↓
Reranking
    ↓
LLM
    ↓
Answer + Sources
    ↓
Evaluation + Observability

Model nie znajduje się już bezpośrednio za bazą danych wektorowych. Pomiędzy użytkownikiem a LLM znajduje się teraz prawdziwa architektura wyszukiwania. Aby lepiej zrozumieć etap rankingu oraz w jakich sytuacjach opóźnienie ma sens, przeczytaj nasz artykuł na temat tego, dlaczego reranking musi uzasadnić swoje opóźnienie.

Baza odniesienia, którą warto najpierw stworzyć

Dobrym sposobem na poznanie tych kompromisów jest stopniowe budowanie rozwiązania. Mała baza odniesienia może łączyć Python, FastAPI, embeddingi OpenAI i modele LLM oraz Pinecone jako magazyn wektorowy, wraz z:

• dzielonymi na fragmenty treściami uwzględniającymi nagłówki oraz metadanymi tych fragmentów
• wyszukiwaniem semantycznym z konfigurowalnym parametrem top_k
• filtrowaniem według podobieństwa
• atrybucją źródła
• oceną efektywności wyszukiwania

Jego przebieg jest następujący:

Question
   ↓
Embedding
   ↓
Pinecone Retrieval
   ↓
Top-K Candidates
   ↓
Similarity Threshold
   ↓
Relevant Context
   ↓
LLM
   ↓
Answer + Sources

Naturalnym następnym krokiem jest dodanie hybrydowego sposobu wyszukiwania i ponownego rankowania, a następnie porównanie ich z tą bazą referencyjną przy użyciu tego samego zestawu oceny, dzięki czemu każda poprawa może być zmierzona, a nie tylko założona.

Mierzenie niezawodności systemu

„Czy chatbot działa?” to nie jest użyteczne pytanie. Podziel je na wymiary, które można zmierzyć:

• Jakość wyszukiwania: czy w ogóle uzyskano prawidłowe informacje?
• Jakość rankowania: czy najbardziej przydatny kontekst znalazł się blisko góry listy?
• Opartość na faktach: czy odpowiedź jest poparta uzyskanym kontekstem?
• Dokładność cytowania: czy przytoczone źródła potwierdzają przedstawione twierdzenia?
• Rozwiązywanie nieznanych zapytań: czy system rozpoznaje, gdy odpowiedzi nie ma w bazie wiedzy?

Czas oczekiwania: jak długo trwa łącznie pobieranie danych i generowanie odpowiedzi?

Koszt: ile kosztuje każde zapytanie?

Cel zmienia się z „czy aplikacja potrafi odpowiadać na pytania?” na „czy możemy ocenić, czy architektura pobierania danych jest niezawodna?”

Główne wnioski

• RAG to coś więcej niż tylko umożliwienie modelowi LLM dostępu do dokumentów; kluczowe są decyzje dotyczące tego, co pobrać, w co zaufać, co przekazać i kiedy odmówić.
• top_k gwarantuje ilość wyników, a nie ich trafność, dlatego należy filtrować kandydatów za pomocą progu dostosowanego do własnych danych.
• Połączone metody wyszukiwania pozwalają na identyfikację dokładnych identyfikatorów, które są zamazane przez embeddingi, a ponowna sortowanie przekształca szeroki zbiór kandydatów w precyzyjny kontekst.
• Jakość odpowiedzi jest w dużej mierze określana jeszcze przed tym, jak model zobaczy jakikolwiek kontekst: lepszy kontekst prowadzi do lepszych odpowiedzi i bardziej niezawodnych systemów.
• Traktuj produkcję RAG jako problem architektoniczny z mierzalnymi etapami, a nie jako pojedynczą integrację LLM.

Literatura pokrewna

• Hybrid RAG Retrieval with pgvector, BM25 and a Cross-Encoder Reranker — Dowiedz się, dlaczego czyste wyszukiwanie wektorowe pomija numery części i kody błędów, oraz jak połączyć pgvector, BM25 i mechanizm ponownego rankowania w LangChain dla precyzyjnego wyszukiwania RAG.
• Right-Sizing LLMs: Routing, Retrieval and Evaluation Over Raw Model Size — Dowiedz się, jak wybierać między małymi a dużymi modelami językowymi w zależności od obciążenia, mierzyć koszt za udaną zadanie oraz jak najpierw wykorzystać routowanie, RAG, buforowanie i weryfikację.
• Projektowanie pipeline RAG opartego na danych praktycznych: chunking, filtrowanie i streaming — Przewodnik po podstawach pipeline RAG opartego na danych praktycznych: chunking uwzględniający strukturę, dzielenie bezpieczne pod kątem tokenów, trójetapowe filtrowanie wyników wyszukiwania, ponowne łączenie elementów, projektowanie promptów oraz streaming.