Generowanie wspomagane wyszukiwaniem — RAG — to koń roboczy większości użytecznej firmowej AI: asystent, który odpowiada z Twoich dokumentów, a nie z danych treningowych. Na demie wygląda banalnie. W produkcji to właśnie tam większość projektów po cichu grzęźnie. Luka prawie nigdy nie leży w modelu językowym. Leży w wyszukiwaniu, dzieleniu na fragmenty, ewaluacji i uczciwości co do tego, czego system nie wie.
Pułapka dema
Pierwszy prototyp RAG jest zwodniczo prosty: osadź kilka dokumentów, wrzuć je do bazy wektorowej, pobierz najlepsze dopasowania i pozwól modelowi odpowiedzieć. Działa pięknie na dziesięciu pytaniach, które sprawdziłeś. Potem spotyka realnych użytkowników, realne dokumenty i realne przypadki brzegowe, a dokładność spada z urwiska. Powód jest taki, że demo optymalizuje pod ścieżkę idealną, podczas gdy produkcja to niemal wyłącznie przypadki brzegowe.
Zespoły, które odnoszą sukces, traktują wyszukiwanie jako pełnoprawny problem inżynierski, nie jako nakładkę na API. Mierzą je, celowo je łamią i projektują z myślą o pytaniach, które nie mają dobrej odpowiedzi w korpusie.
Dzielenie na fragmenty to decyzja projektowa, nie domyślna
Sposób, w jaki dzielisz dokumenty na pobieralne kawałki, po cichu wyznacza sufit całego systemu. Zbyt duże fragmenty rozcieńczają istotne zdanie w szumie; zbyt małe tracą kontekst, który nadawał im sens. Dzielenie o stałym rozmiarze jest wygodne i zwykle błędne. Lepsze wyniki płyną z poszanowania własnej struktury dokumentu — sekcji, nagłówków, klauzul — aby każdy fragment był spójną jednostką znaczenia.
Nie ma uniwersalnego rozmiaru fragmentu. Umowa prawna, instrukcja produktu i zapis czatu wymagają różnego traktowania. Warto tu prawdziwego eksperymentowania, bo wszystko w dole strumienia dziedziczy jakość tego kroku.
Jakość wyszukiwania jest mierzalna — więc ją mierz
Największą różnicą między demem a niezawodnym systemem jest to, że ten drugi ma zbiór ewaluacyjny. Zbierz stałą listę realnych pytań ze znanymi dobrymi odpowiedziami i znanymi istotnymi fragmentami źródłowymi. Wtedy możesz zadawać konkretne pytania: czy właściwy fragment pojawia się w najlepszych wynikach? Jak często system nie pobiera niczego użytecznego? Bez tego każda zmiana to zgadywanie, a każda poprawa to kwestia opinii.
Traktujemy ten zbiór ewaluacyjny jak zestaw regresji. Każda zmiana w dzieleniu, osadzeniach czy promptach jest oceniana wobec niego przed wdrożeniem, więc jakość nigdy po cichu nie spada — klasyczny błąd, w którym „drobna poprawa” cicho psuje klasę pytań, których nikt nie przetestował ponownie.
Ugruntowanie i cytaty są nienegocjowalne
Produkcyjny asystent musi odpowiadać wyłącznie z pobranej treści i cytować, skąd wzięło się każde twierdzenie. Robi to dwie rzeczy: pozwala użytkownikom zweryfikować odpowiedzi i sprawia, że halucynacje są oczywiste, a nie ukryte. Jeśli model nie potrafi ugruntować odpowiedzi w pobranych fragmentach, właściwym zachowaniem jest powiedzieć to — nie wypełniać luki pewnym zgadywaniem.
Projektowanie pod „nie wiem” to właśnie to, co buduje zaufanie. Użytkownicy dużo chętniej wybaczają systemowi, który przyznaje się do niepewności, niż takiemu, który jest pewny i błędny, a w środowiskach regulowanych lub o wysokiej stawce pewna, błędna odpowiedź to realne ryzyko.
Wyszukiwanie hybrydowe jako rozsądny domyślny wybór
Gdy czyste wyszukiwanie wektorowe zawodzi, warto sięgnąć po wyszukiwanie hybrydowe — łączące podobieństwo semantyczne z tradycyjnym dopasowaniem słów kluczowych. Wektory świetnie radzą sobie ze znaczeniem, ale mogą przeoczyć dokładne terminy, kody produktów czy nazwy, które wyszukiwanie po słowach kluczowych obsługuje trywialnie. Uruchomienie obu i połączenie wyników daje najlepsze z obu światów.
Wzorzec kryjący się za pułapkami
Zauważ, że większość tych porażek nie dotyczy w ogóle matematyki wektorowej. Dotyczą otaczającej inżynierii: przygotowania danych, doboru modelu do domeny, struktury obok podobieństwa, pomiaru i utrzymania. To powracająca lekcja systemów wyszukiwania — model rzadko jest wąskim gardłem, a trwała jakość bierze się z traktowania całego potoku jako pełnoprawnego problemu inżynierskiego, nie nakładki na wyszukiwanie podobieństwa.