Generative AI Design Patterns #3: HyDE, reranking, Trustworthy Generation i Deep Search, czyli podobieństwo to nie trafność
Rozdział 4 „Generative AI Design Patterns" dokłada do RAG-a cztery wzorce: przepisywanie zapytania (w tym HyDE), przetwarzanie pobranych fragmentów z rerankingiem, sygnalizowanie wiarygodności odpowiedzi i iteracyjne wyszukiwanie. Sprawdziłem wszystkie cztery na fikcyjnej polskiej instrukcji serwisowej i lokalnych modelach. Najmocniej potwierdziło się zastrzeżenie, które autorzy sami stawiają przy HyDE: w domenie, której model nie zna, hipotetyczna odpowiedź jest zmyślona, a wyszukiwanie po niej trafiło właściwy fragment w 10 przypadkach na 20 zamiast w 17. Reranking poprawił kolejność, ale lepszy okazał się wolny sędzia-LLM niż wyspecjalizowany reranker. Pętla Deep Search z promptem z książki w trzech pytaniach na pięć kończyła pracę po pierwszym kroku z odpowiedzią niepełną, bo jej ewaluator uznawał „brakuje informacji" za odpowiedź kompletną.
To piąty wpis serii o książce Valliappy Lakshmanana i Hannesa Hapkego. Recenzja i mapa serii są we wpisie 0, poprzedni wpis dotyczył fundamentów RAG. Cytuję po rozdziale i numerze wzorca, bo PDF nie ma stron druku.
Teza
Rozdział 3 budował RAG, w którym wszystko psuje się przed modelem. Rozdział 4 próbuje to naprawić i robi to w dużej części samym modelem: model przepisuje zapytanie, model ocenia trafność fragmentu, model decyduje, czego jeszcze brakuje. Każda z tych napraw wnosi do potoku dokładnie te słabości, przed którymi RAG miał chronić.
Moja teza ma trzy części. Podobieństwo nie jest trafnością, a reranker widzi różnicę, której embedding nie widzi, ale płaci się za to w czasie zapytania. HyDE i rozwinięcie zapytania korzystają z wiedzy modelu, więc tam, gdzie RAG jest najbardziej potrzebny, czyli w domenie modelowi obcej, dopasowują fragmenty do halucynacji. Sygnał „nie wiem" trzeba wyprodukować poza modelem generującym, a pętla wyszukiwania jest dokładnie tak dobra jak jej ewaluator.
Pattern 9: Index-Aware Retrieval
Problem. Założenie „pytanie jest podobne do odpowiedzi" zawodzi w czterech sytuacjach: pytania nie ma w bazie, baza mówi innym językiem niż użytkownik, odpowiedź jest drobnym szczegółem w chunku, którego jeden wektor nie reprezentuje, albo wymaga złożenia kilku chunków (rozdz. 4, Pattern 9).
Rozwiązanie. Cztery komponenty. HyDE (hypothetical document embedding): model pisze hipotetyczną odpowiedź bez dostępu do bazy, a wyszukuje się fragmenty podobne do niej, a nie do pytania. Query expansion: model rozwija zapytanie o terminologię bazy. Hybrid search: ważona suma BM25 i wektorów, w LlamaIndex przez parametr alpha (0,0 to czyste BM25, 1,0 czysty wektor). GraphRAG: dokumenty w bazie grafowej, z której po znalezieniu częściowej odpowiedzi dociąga się powiązane węzły (rozdz. 4, Pattern 9).
Najważniejsze zdanie wzorca autorzy umieścili w ograniczeniach. Hipotetyczna odpowiedź i rozwinięcie zapytania powstają z wiedzy, którą model już ma. Gdy RAG działa w domenie, której model nie zna, mogą zawierać „hallucinated, obsolete, or irrelevant data", a wtedy „one of the key benefits of RAG—that answers are grounded in the text—could be lost". Halucynacje dotyczą domeny, której model nie zna. Jako przykład danych nieistotnych autorzy podają pytanie „What patterns is Alexander best known for?", na które model napisze o wzorcach architektonicznych Christophera Alexandra, a nie o falandze Aleksandra Wielkiego (rozdz. 4, Pattern 9). Nie znalazłem w książce drugiego miejsca, w którym wzorzec wprost odbiera właściwość, dla której sięgnęło się po całą technikę.
Pattern 10: Node Postprocessing
Problem. Autorzy otwierają go nagłówkiem „Similarity is not relevance". Przy RAG-u na podręczniku geologii pytanie o geologię Wielkiego Kanionu zwróciło na pierwszej pozycji spis treści, bo był pełen terminów geologicznych. Drugi fragment opisywał płaskowyż, na którym leży kanion, więc odpowiedź mówiła o stopniach szerokich na „a score or more miles", czyli ponad 20 mil, choć kanion ma średnio 10. Zwiększenie top_k z 2 do 4 dało tę samą błędną odpowiedź (rozdz. 4, Pattern 10). Do tego dochodzą zbędna treść wewnątrz trafnego chunka, dwuznaczne encje (dwa Wielkie Kaniony) i treści nieaktualne.
Rozwiązanie. Krok między wyszukiwaniem a generacją. Jego rdzeniem jest reranking: model dostaje parę zapytanie–fragment i zwraca ocenę od 0 do 1. Uzasadnienie autorów jest strukturalne: „an embedding model has to compress all the information in the chunk into a single embedding vector", a reranker ogląda fragment w całości. Autorzy wskazują wyspecjalizowane modele, na przykład bge-reranker-v2-m3, którego użyłem w pomiarach (rozdz. 4, Pattern 10).
Na tym samym kroku autorzy wieszają kontekstową kompresję fragmentów, filtr nieaktualnych wersji po metadanych, dezambiguację i personalizację. Rachunek złożoności jest wart zapamiętania: wykrycie sprzeczności wymaga porównania par, czyli N * (N-1) wywołań, co autorzy uznają za „cost prohibitive", a dezambiguacja tylko N – 1, bo wystarczy porównać kolejne fragmenty z pierwszym (rozdz. 4, Pattern 10). Dlatego sprzeczności rozstrzyga się metadanymi, a nie czytaniem, co we wpisie 2 potwierdziło się po stronie czytania: model z całym dokumentem pomylił łańcuch biuletynów, a samo wycięcie starszych też nie pomogło.
Pattern 11: Trustworthy Generation
Problem. Autorzy piszą wprost: „There is, currently, no way to completely avoid these issues". Chodzi o awarie wyszukiwania, niewiarygodny kontekst, błędy rozumowania i halucynacje. Celem nie jest więc usunięcie błędu, tylko oszacowanie wiarygodności i przekazanie jej użytkownikowi, który decyduje, czy działać (rozdz. 4, Pattern 11).
Rozwiązanie. Najciekawszy element to out-of-domain detection, czyli odmowa zbudowana poza modelem generującym. Trzy sygnały: odległość embeddingu zapytania od fragmentów (autorzy obiecują „a steep drop in similarity scores", z progiem zależnym od domeny), klasyfikacja zero-shot małym modelem i wymóg terminologii domenowej. Zalecenie to ważona suma sygnałów (rozdz. 4, Pattern 11).
Dalej trzy poziomy cytowania: z metadanych pobranych fragmentów (prosty, ale cytuje za dużo), przez klasyfikator twierdzeń wymagających źródła i przez atrybucję na poziomie tokenów, o której autorzy piszą: „No production-ready open source implementation has yet emerged". Gdy klasyfikator uzna, że zdanie wymaga źródła, a źródła nie ma, w odpowiedzi ląduje [Citation needed]. Do tego dwie pętle korekcyjne: CRAG ocenia jakość pobranych fragmentów przed generacją, a self-RAG krytykuje własny wynik (rozdz. 4, Pattern 11).
Ograniczenia autorzy wyliczają bez upiększania: zbyt ostre zabezpieczenia wycinają wartościową treść, weryfikacja przez człowieka „only scale[s] so far", a rosnąca baza „can also produce more false positives over time as conflicting information is added to them" (rozdz. 4, Pattern 11).
Pattern 12: Deep Search
Problem. Okno kontekstu, niejednoznaczność, nieświeżość, płytkie rozumowanie i zapytania wieloskokowe, w których wynik pierwszego wyszukiwania jest dopiero podstawą do sformułowania drugiego (rozdz. 4, Pattern 12).
Rozwiązanie. Pętla: wyszukaj, pomyśl, czego brakuje, wyszukaj ponownie, aż odpowiedź będzie dość dobra albo skończy się budżet. Rada autorów jest nieoczywista: nie zaczynać od dekompozycji złożonego pytania, tylko od odpowiedzi na prostsze i iteracyjnie zasypywać luki. Krok szukania luk to zwykły prompt: „Determine whether there is a logical or information gap … If there is a gap, provide a list of up to 3 search queries to fill in the gap". Autorzy podkreślają, że jakość odpowiedzi jest „directly tied to how well you can evaluate the iterations", i zalecają gotowy framework (Ragas) zamiast własnej metryki (rozdz. 4, Pattern 12).
Główną wadę nazywają jednym zdaniem: „the overall system is very slow". Łagodzi się ją zrównolegleniem podzapytań i wcześniejszym przerywaniem pętli (rozdz. 4, Pattern 12).
Sprawdziłem to po polsku na lokalnych modelach
Środowisko jak w poprzednich wpisach: ThinkPad L16 Gen 2, sam CPU, llama.cpp b6153 z pakietu Fedory. Embeddingi: bge-m3 (Q8_0, pooling CLS). Reranker: bge-reranker-v2-m3 (Q8_0). Generacja i sędzia: Qwen3-Coder-30B-A3B-Instruct (UD-Q3_K_XL), temperatura 0. Wszystkie liczby z tej sekcji pochodzą z moich uruchomień z 5 października 2026.
Korpus jest nowy i znów fikcyjny: 34 chunki instrukcji serwisowej pompy ciepła „Aeron HP-9" po polsku. Fikcyjność jest tu warunkiem testu, bo model nie może znać znaczenia kodu E-204 ani numeru części ZB-3381 z pretreningu. Sześć chunków to celowe dystraktory w duchu spisu treści z książki: spis treści, wstęp, słowniczek, historia zmian dokumentu, tekst marketingowy i zapowiedź FAQ. Pełno w nich słów z pytań, a odpowiedzi nie ma w żadnym. Do tego 20 pytań z oznaczonym właściwym chunkiem, w dwóch grupach: 12 o rzeczach specyficznych dla produktu (kody błędów, parametry, numery części) i 8 o rzeczach, które model może znać ogólnie (odszranianie, krzywa grzewcza, ciśnienie w instalacji).
Jedna uwaga techniczna dla posiadaczy AMD z iGPU. Build llama.cpp z ROCm przy -ngl 0 wciąż korzystał z karty, a generator zwracał ciągi w rodzaju G(rb hers是一名几OT. Dopiero --device none dało poprawne wyniki. Wszystkie liczby poniżej pochodzą z drugiego uruchomienia, poza czasami rerankingu (osobny pomiar, opisany niżej).
1. Reranking: sędzia-LLM wygrywa, reranker bge nie zawsze pomaga
Bge-m3 zwracał 10 kandydatów, które potem porządkowały dwa rerankery. Trafienie oznacza właściwy chunk na pierwszej pozycji (@1) albo w pierwszej trójce (@3):
| Metoda | specyficzne @1 | ogólne @1 | razem @1 / @3 | dystraktor na 1. miejscu | czas na pytanie |
|---|---|---|---|---|---|
| bge-m3 (samo podobieństwo) | 9 / 12 | 8 / 8 | 17 / 20 · 20 / 20 | 2 | 0,2 s |
| bge-reranker-v2-m3 | 10 / 12 | 8 / 8 | 18 / 20 · 19 / 20 | 1 | 8 s |
| sędzia-LLM, prompt z książki | 12 / 12 | 8 / 8 | 20 / 20 · 20 / 20 | 0 | 106–125 s (3 pytania) |
Podobieństwo zawiodło dokładnie tak jak w przykładzie z Wielkim Kanionem, tylko w miniaturze. Na pytanie o usterkę F17 bge-m3 dał na pierwsze miejsce historię zmian dokumentu („poprawiono opis kodów błędów E-204 i F17"), a na pytanie o ostrzeżenie W-07 zapowiedź FAQ, która wymienia W-07 z nazwy. Oba dystraktory zawierają kod z pytania, a żaden nie mówi, co ten kod znaczy.
Najbardziej pouczające było pytanie „Jak wyciszyć jednostkę zewnętrzną w nocy?". Bge-m3 dał na pierwsze miejsce chunk o hałasie: „38 dB(A) w trybie nocnym". Jest on bardzo podobny do pytania i całkowicie bezużyteczny. Właściwy chunk opisuje parametr P.34, który ogranicza wentylator nocą i obniża hałas o 4 dB(A), a bge-m3 umieścił go na trzecim miejscu. Wyspecjalizowany reranker zepchnął go na piąte. Sędzia-LLM dał mu 0,8, a chunkowi o decybelach 0,5. To jedyne pytanie, w którym reranker bge pogorszył wynik bge-m3, i zarazem jedyne, które w mojej ocenie wymagało wnioskowania („wyciszyć" → „ograniczyć prędkość wentylatora"), a nie dopasowania słów.
Sędzia-LLM ma jednak dwie wady. Pierwsza to koszt: dziesięć wywołań na pytanie, czyli na tym laptopie około dwóch minut, wobec ośmiu sekund dla rerankera bge i 0,2 s dla samego embeddingu. Czasy zmierzyłem osobno, przy bezczynnym systemie, na 20 pytaniach dla embeddingu i rerankera oraz na trzech dla sędziego. Druga to skala ocen. Sędzia użył w sumie dziewięciu wartości (0, 0,2, 0,25, 0,3, 0,5, 0,75, 0,8, 0,95 i 1), więc pozycje od drugiej w dół często remisowały. Dystraktorów w pierwszej trójce po rerankingu było więcej niż przed nim (12 wobec 10 na 60 pozycji), bo oba rerankery wypychały właściwy chunk na górę, a puste miejsca zapełniały fragmentami ogólnymi.
2. HyDE w obcej domenie: halucynacja jako zapytanie
Ten sam zbiór 20 pytań. Model pisał dwu-, trzyzdaniowy fragment instrukcji Aeron HP-9 odpowiadający na pytanie, bez dostępu do bazy. Szukałem po pytaniu, po samym hipotetycznym fragmencie i po złączeniu obu:
| Zapytanie do bge-m3 | specyficzne @1 / @3 | ogólne @1 / @3 | razem @1 |
|---|---|---|---|
| samo pytanie | 9 / 12 · 12 / 12 | 8 / 8 · 8 / 8 | 17 / 20 |
| hipotetyczna odpowiedź (HyDE) | 4 / 12 · 10 / 12 | 6 / 8 · 7 / 8 | 10 / 20 |
| pytanie + hipotetyczna odpowiedź | 6 / 12 · 10 / 12 | 7 / 8 · 7 / 8 | 13 / 20 |
Treść hipotetycznych odpowiedzi tłumaczy wynik. Model stwierdził, że E-204 to „awaria w pracy czujnika ciśnienia" (w instrukcji: za niski przepływ), W-07 to „problem z przepływem czynnika pracy w obwodzie wentylatora" (w instrukcji: grzałka pracuje ponad 6 godzin na dobę), a P.51 to „minimalna wartość ciśnienia w obiegu chłodzenia" (w instrukcji: opóźnienie startu sprężarki). Czujnik przepływu dostał numer katalogowy „1234-5678", sprężarka 5 lat gwarancji zamiast 7, a częstsze odszranianie przy mokrej pogodzie zostało wyjaśnione „zwiększonym napięciem elektrycznym na zewnątrz".
Nawet w grupie ogólnej, gdzie model mógł coś wiedzieć, HyDE stracił dwa trafienia. Najciekawsze jest to, dokąd prowadziły zmyślone odpowiedzi. W 7 z 20 przypadków pierwsze miejsce po HyDE zajmował dystraktor: cztery razy wstęp, trzy razy tekst marketingowy. Przy wyszukiwaniu po samym pytaniu zdarzyło się to dwa razy. Hipotetyczna odpowiedź jest napisana ogólnym językiem instrukcji, więc najbardziej podobny jest do niej chunk napisany tym samym językiem i niezawierający niczego konkretnego. Przypadek halucynacji z ograniczeń wzorca wystąpił w czystej postaci: pytanie o W-07 po HyDE spadło z drugiego miejsca na szóste.
Ten wynik nie przekreśla HyDE jako techniki. Autorzy pokazują jego zysk na Anabasis, czyli tekście, który model zna z pretreningu. Pokazuje natomiast, że wzorzec trzeba testować na tej domenie, w której ma działać, a w dokumentacji własnego produktu będzie zwykle gorzej niż w przykładach z książki.
3. Pytania spoza domeny: „stromy spadek" nie zawsze jest stromy
Dwadzieścia pytań z domeny i 15 spoza niej: siedem dalekich (sernik, mundial, dojazd do szpitala, pralka) i osiem bliskich, czyli o pompach ciepła, ale bez odpowiedzi w instrukcji (cena z montażem, dotacja Czyste Powietrze, pompa gruntowa a powietrzna). Dwa sygnały, czyli najwyższy cosinus bge-m3 i najwyższy wynik rerankera po sigmoidzie:
| Grupa | cosinus min–max | reranker min–max |
|---|---|---|
| z domeny (20) | 0,520–0,813 | 0,066–1,000 |
| blisko domeny (8) | 0,400–0,593 | 0,000–0,025 |
| daleko od domeny (7) | 0,310–0,563 | 0,000–0,001 |
Przedziały cosinusa nachodzą na siebie. Najlepszy możliwy próg (ok. 0,565) klasyfikował poprawnie 31 z 35 pytań. Pytanie „Pralka nie odwirowuje, co robić?" miało cosinus 0,563 i było bardziej „w domenie" niż pytania o F17 (0,520), E-204 (0,559) i P.51 (0,551). Krótkie pytanie o kod błędu jest po prostu mało podobne do czegokolwiek, a pytanie o awarię pralki brzmi jak instrukcja serwisowa.
Wynik rerankera rozdzielił wszystkie 35 pytań, ale z małym marginesem: najwyższa wartość spoza domeny wyniosła 0,025, najniższa z domeny 0,066 (pytanie o F17). Próg wybierałem na tych samych 35 pytaniach, więc w produkcji trzeba go ustalić na osobnym zbiorze i śledzić, tak jak radzą autorzy. Kiedy w tym korpusie pojawi się chunk o pralce, rozdział zniknie.
4. Deep Search: pętla kończy się na ewaluatorze
Pięć pytań dwuskokowych. Pierwszy chunk mówi, którą część wymienić, a dopiero tabela części podaje jej numer, np. E-204 → czujnik przepływu FS-2 → ZB-3381. Trzy tryby: jednorazowo top-3, jednorazowo top-6 i pętla Deep Search: odpowiedź z top-3, sprawdzenie luki promptem z książki, do trzech podzapytań po dwa chunki i najwyżej trzy iteracje albo do momentu, gdy podzapytania nie przyniosą nowych fragmentów. Odpowiedzi oceniłem ręcznie, bo samo wystąpienie numeru w tekście mylnie wyglądało na sukces:
| Pytanie (część → numer) | top-3 | top-6 | Deep Search, prompt z książki | Deep Search, ewaluator poprawiony |
|---|---|---|---|---|
E-204 wraca → FS-2 → ZB-3381 | brak numeru | FS-2 bez numeru | brak, „NO GAP" po 1. iteracji | brak, „NO GAP" po 1. iteracji |
odszranianie 20 min → TP-1 → ZB-3318 | brak numeru | brak numeru | brak, „NO GAP" po 1. iteracji | numer podany, ale odpowiedź „brakuje informacji" |
rura spustowa zimą → kabel → EL-5633 | numer z zastrzeżeniem | numer z zastrzeżeniem | numer z zastrzeżeniem, „NO GAP" | ✓ po 3 iteracjach |
F12 wraca → naczynie wzbiorcze → HY-1185 | brak numeru | brak numeru | numer z zastrzeżeniem po 3 iteracjach | brak, „NO GAP" po 1. iteracji |
W-07 → bezpiecznik STB → EL-5502 | ✓ | ✓ | ✓ | ✓ |
| łączny czas 5 pytań | 358 s | 413 s | 779 s | 1064 s |
| najdłuższe pytanie | 86 s | 103 s | 517 s (6 wywołań) | 431 s (6 wywołań) |
„Numer z zastrzeżeniem" oznacza odpowiedź w rodzaju: „brakuje informacji o numerze katalogowym kabla… Potrzebny numer katalogowy: EL-5633, ale nie został wprost podany jako rozwiązanie". Model miał oba fragmenty i nie złożył ich w odpowiedź.
Pętla z promptem z książki nie poprawiła żadnej odpowiedzi do czystego ✓. W czterech pytaniach z pięciu zatrzymała się po pierwszej iteracji, w tym w trzech z odpowiedzią niepełną, bo krok szukania luki odpowiedział „NO GAP" na odpowiedź, która sama zaczynała się od „Brakuje informacji o numerze katalogowym czujnika przepływu FS-2". Odpowiedź uczciwie mówiąca „nie wiem" jest dla ewaluatora odpowiedzią kompletną i logicznie spójną. W jedynym pytaniu, w którym pętla ruszyła (F12), podzapytania odpłynęły od tematu: „kabel grzewczy przewodu spustowego", „części hydrauliczne do naprawy błędu F12 w urządzeniu gazowym". Po 517 sekundach i sześciu wywołaniach odpowiedź zawierała właściwy numer, ale wciąż jako „brakuje".
Potem zmieniłem tylko prompt ewaluatora. Napisałem go po polsku i wprost: odpowiedź, która mówi, że czegoś brakuje, albo podaje wartość z zastrzeżeniem, ma lukę. To dało jedną czystą poprawną odpowiedź (rura spustowa, po trzech iteracjach i 431 s) i jedno dociągnięcie właściwej tabeli części (odszranianie). Mimo tej instrukcji ewaluator w dwóch pytaniach znów odpowiedział „NO GAP" na odpowiedź zaczynającą się od „Brakuje informacji". Przy pytaniu o F12 wersja z książki lukę wykryła, a poprawiona nie, przy temperaturze 0 i tej samej pierwszej odpowiedzi. Ewaluator jest tu takim samym modelem językowym jak generator i ma te same słabości.
Autorzy piszą, że jakość Deep Search zależy od tego, jak dobrze ocenia się iteracje. Mój pomiar mówi to samo w ostrzejszej formie: bez ewaluatora sprawdzonego osobno na odpowiedziach typu „nie wiem" pętla jest kosztowną formą jednorazowego retrievalu. Najprostsza poprawa w tym korpusie nie wymagała zresztą modelu. Prostszą kandydatką jest reguła „jeśli odpowiedź zawiera brakuje, szukaj dalej", choć przy F12 samo dalsze szukanie nie wystarczyło: model miał w końcu właściwą tabelę części i nadal pisał „brakuje". Tej reguły nie sprawdzałem.
Zastrzeżenia do całej sekcji. Korpus i pytania napisałem sam, więc wiedziałem, które przypadki są trudne, a dystraktory wstawiłem celowo. Próby liczone są w dziesiątkach. Biorę pod uwagę jeden model generujący, jeden embedder, jeden reranker i jeden język. Odpowiedzi oceniałem sam. Czasy pochodzą z laptopa bez GPU i opisują proporcje, a nie wartości bezwzględne. To pokazuje mechanizmy, a nie odsetki, których należy się spodziewać w innym korpusie.
To samo w innych książkach
Dominik Polzer w RAG with Python Cookbook opisuje ryzyko HyDE tak samo jak Lakshmanan i Hapke: „The main risk is generating plausible but incorrect hypothetical documents… This happens more with specialized domains where the model lacks knowledge" (s. 187). Jego przykłady pokazują drugie ryzyko, które występuje także w domenie znanej: przepisanie zapytania zmienia jego sens. Pytanie o zalety dostaje wariant o wadach (s. 189), a „make more money" zamienia się w „profit" (s. 208). Pętla Deep Search z mojego pomiaru zrobiła to samo: dopisała do pytania o pompę ciepła „urządzenie gazowe".
U Polzera jest też pułapka, która dotyczy ewaluacji z Pattern 12. Zaleca, żeby system RAG oceniać tylko na pytaniach, na które baza zna odpowiedź (s. 286), a w metryce trafności odpowiedzi odpowiedź wymijająca typu „I don't know" dostaje wynik „set to 0" (s. 321). Ewaluator zbudowany w ten sposób nagradza system, który nigdy nie odmawia, czyli działa wbrew out-of-domain detection z Pattern 11. To mój wniosek z zestawienia obu książek, nie teza Polzera.
François Chollet w Deep Learning with Python pisze o architekturach głębokiego uczenia, że z typowego złożonego układu można usunąć kilka modułów „with no loss of performance", i jako lekarstwo zaleca ablację, czyli systematyczne usuwanie części systemu, żeby zobaczyć, skąd naprawdę bierze się wynik (s. 251). Nie pisze o RAG-u, ale zasada przenosi się wprost. W moim pomiarze z trzech dokładanych warstw jedna obniżyła wynik (HyDE), a jedna w wersji z książki nie dała żadnej czystej poprawnej odpowiedzi (pętla Deep Search). Każdą warstwę trzeba zmierzyć osobno, zanim trafi do potoku.
Kiedy nie używać — zestawienie
| Wzorzec | Nie używaj, gdy | Zamiast tego |
|---|---|---|
| HyDE, query expansion | domena jest modelowi obca (własny produkt, wewnętrzne kody) | zapytanie bez zmian, hybryda z BM25, słownik synonimów domenowych |
| HyDE, query expansion | przepisanie może zmienić intencję pytania | oryginalne pytanie w prompcie generacji, warianty tylko do wyszukiwania |
| Reranking LLM | liczy się latencja zapytania | wyspecjalizowany reranker albo tylko top-k z embeddingu |
| Wyspecjalizowany reranker | pytania wymagają wnioskowania, a nie dopasowania słów (w moim pomiarze: 1 przypadek) | sędzia-LLM na krótkiej liście kandydatów |
| Próg cosinusa jako out-of-domain | krótkie pytania z identyfikatorami i pytania z sąsiedniej domeny | wynik rerankera, klasyfikator, próg strojony na osobnym zbiorze |
| Deep Search | ewaluator luki nie był sprawdzony na odpowiedziach z „brakuje" | ewaluator przetestowany osobno, potem pętla |
| Deep Search | liczy się czas odpowiedzi | jednorazowy retrieval + reranking |
Ocena trwałości
Moja ocena, nie autorów. Node Postprocessing jest najtrwalszy z czterech, bo opiera się na stałej obserwacji: jeden wektor nie odróżni fragmentu podobnego od fragmentu użytecznego. Datowane jest tylko to, który model rerankuje i ile to kosztuje. Trustworthy Generation jest trwały w części out-of-domain i [Citation needed], bo oba mechanizmy wytwarzają sygnał „nie wiem" poza modelem generującym. Atrybucja tokenowa jest datowana, zgodnie z tym, co piszą sami autorzy. Index-Aware Retrieval jest mieszany: hybryda i GraphRAG są trwałe, a HyDE i rozwinięcie zapytania zależą od tego, czy model zna domenę, czyli są tym lepsze, im mniej RAG jest potrzebny. Deep Search jest trwały jako architektura i wolny z definicji. Mój pomiar dopisuje, że jego jakość ogranicza najsłabsze ogniwo, czyli ewaluator luki.
Starszy krewny: wyszukiwanie dwuetapowe
Reranking jest starszy od LLM-ów. Klasyczne wyszukiwarki od dawna działają dwuetapowo: tani etap pobiera setki kandydatów, a drogi model rankingowy porządkuje kilkadziesiąt pierwszych. Ta sama dziedzina zna pytania bez wyników („brak wyników dla zapytania") i rozwijanie zapytań synonimami. Nowe w rozdziale 4 jest to, że etap rankingowy, rozwijanie zapytania i decyzja „szukaj dalej" przeszły na model językowy. Jest elastyczniejszy, ale też wolniejszy, i potrafi zmyślać.
Dalej w serii
Następny wpis (4) dotyczy rozdziału 5, czyli rozszerzania zdolności modelu: Chain of Thought, Tree of Thoughts, Adapter Tuning i Evol-Instruct. Zajmę się w nim pytaniem, który rodzaj braku naprawia które narzędzie, i tym, czego fine-tuning nie dodaje. Mapa całej serii jest we wpisie 0.