Dziesięć problemów w wyszukiwaniu w systemach RAG w warunkach produkcyjnych i sposób naprawy każdego z nich.
Od wielkości fragmentów i nakładania się danych do wyszukiwania hybrydowego, RRF, ponownego rankowania, wyboru embeddingów oraz ocen CI: dziesięć błędów w wyszukiwaniu powodujących błędne odpowiedzi RAG i sposoby ich naprawy.
Bot do obsługi klienta kiedyś w pięknym stylu wyjaśnił błędną politykę zwrotów pieniędzy. System odnalazł akapit, w którym słowo „zwrot” występowało cztery razy. Treść była tematycznie powiązana i opisywała już nieprodukowaną linię produktów. Sztuczna inteligencja zrobiła to, co jej kazano, czyli odpowiedziała z pewnością siebie na podstawie dostarczonego kontekstu. Nikt nie poinformował jej, że kontekst jest błędny.
Taki jest obraz większości awarii typu RAG, które kończą się sesją debugowania. Zespół spędza dwa tygodnie na wymienianiu modelu, przepisywaniu instrukcji systemowych oraz dodawaniu napisu „odpowiadać tylko na podstawie kontekstu” pogrubionym tekstem, a wskaźnik halucynacji prawie się nie zmienia. Problemem nigdy nie była generacja treści. Model rozumował poprawnie na podstawie dowodów, które już przy dostarczeniu były błędne.
Te konkretne błędy pogarszają jakość wyszukiwania w produkcji systemów RAG. Zazwyczaj pojawiają się w określonej kolejności: najpierw błędy w dzieleniu tekstu na fragmenty, ponieważ występują na wczesnym etapie, potem kwestie związane z projektowaniem mechanizmu wyszukiwania, następnie wybór metod ponownego sortowania i tworzenia wektorów reprezentacji, a na końcu luka w pomiarach, która sprawia, że wszystkie te problemy pozostają nierozpoznane. Każdy z poniższych rozdziałów wyjaśnia, dlaczego występuje dany błąd, jakie są jego konsekwencje i co należy zmienić, a tam, gdzie badania są sprzeczne, sprzeczność jest otwarcie przedstawiona.
Dlaczego to właśnie wyszukiwanie jest problemem w systemach RAG
Opisy praktyków dotyczące systemów RAG w roku 2026 wskazują na ten sam problem: większość błędnych odpowiedzi wynika z procesu wyodrębniania informacji. Wracają niewłaściwe dokumenty, albo pomijane są te właściwe, albo znajdują się zbyt nisko w rankingu, by można je było wykorzystać. Powszechnie przyjmowana wartość wynosi około 70% lub więcej. Ta liczba zmienia się w zależności od raportu i dziedziny, więc stanowi jedynie przybliżony wskaźnik, ale niezależne źródła zgadzają się co do ogólnego kierunku. Gdy system RAG popełnia błąd, najbardziej prawdopodobnym wyjaśnieniem jest to, że model LLM nigdy nie otrzymał odpowiednich dowodów, dlatego pierwszym krokiem jest sprawdzenie tego, co zwrócił mechanizm wyodrębniania informacji, zanim edytuje się prompt.
Dziesięć błędów można podzielić na cztery grupy zgodnie z poszczególnymi etapami procesu. Numery od 1 do 4 dotyczą uszkodzenia danych wprowadzanych do magazynu wektorowego. Numery od 5 do 7 odnoszą się do architektury wyodrębniania informacji. Numery 8 i 9 dotyczą etapu rankingu i tworzenia wektorów. Błąd numer 10 polega na tym, że nic z tego nie jest mierzony.
Terminy użyte poniżej
- Chunking oznacza dzielenie dokumentów źródłowych na fragmenty przed indeksowaniem. Modele embeddingowe oraz okna kontekstowe działają lepiej na krótkich, skoncentrowanych jednostkach niż na całych plikach.
- Dense retrieval (szukanie wektorowe) umieszcza zapytania i fragmenty w jednym przestrzeni embeddingowej i zwraca najbliższe sąsiednie elementy. Jest skuteczny przy parafrazowaniu, ale słaby w przypadku dosłownych ciągów znaków.
- Sparse retrieval, takie jak BM25, sortuje fragmenty według wspólnych słów z zapytania, przydając większą wagę rzadkim słowom. Kodы, nazwy i żargon dobrze się dopasowują, natomiast synonimy – nie.
- Hybrid search uruchamia oba mechanizmy wyszukiwania równocześnie i łączy dwa listy uporządkowane, najczęściej przy użyciu Reciprocal Rank Fusion (RRF). RRF wykorzystuje pozycje w rankingu zamiast surowych wyników, co rozwiązuje problem nierównoważności wartości BM25 i podobieństwa kosinowego.
- Reranking ponownie ocenia krótką listę kandydatów, zazwyczaj od 20 do 100 pozycji, przy użyciu kodera krzyżowego, który analizuje zapytanie i tekst wspólnie, zamiast traktować je oddzielnie. W rezultacie powstaje znacznie precyzyjniejszy porządek przed przekazaniem ostatecznej listy top-k do modelu LLM.
Cztery błędy w dzieleniu na fragmenty
1. Używanie podziału o stałej wielkości jako standardu i nigdy nie testowania innych metod
Tutoriale najpierw pokazują dzielenie każdego dokumentu na okna po 500 tokenów, niezależnie od treści. Proces ten trwa pięć minut, działa wystarczająco dobrze do demonstracji, więc zespoły wdrażają go bez dalszych modyfikacji.
Badania w tej kwestii dają różne wyniki, a przyznanie się do tego jest bardziej przydatne niż udawanie konsensusu. Kilka porównań z 2026 roku faworyzuje stałe lub rekurencyjne dzielenie tokenów zamiast semantycznego dzielenia na fragmenty. W jednym dużym teście wielu strategii zwyciężyło rekurencyjne dzielenie na 512 tokenów, częściowo dlatego, że semantyczne dzielenie dawało średnio fragmenty składające się z zaledwie 43 tokenów, zbyt małe, by przenosić kontekst. Inne badania w tym obszarze wskazują na przeciwny efekt: ocena systemu wspierającego decyzje kliniczne przeprowadzona przez recenzentów wykazała 87% dokładności w przypadku adaptacyjnego dzielenia zgodnego z tematem w porównaniu do 50% w przypadku stałej bazy (p = 0,001). Trzecie porównanie wykazało, że dobrze dostrojona stała wielkość może dorównać lub przewyższyć semantyczne dzielenie na rzeczywistych zbiorach danych, co jest zgodne ze stałymi fragmentami o długości 100 słów użytymi w oryginalnym artykule o RAG.
Żadna strategia nie jest skuteczna we wszystkich przypadkach. Wszystkie źródła zgadzają się co do tego, że błędem jest wybór podziału o stałej wielkości. Chodzi raczej o wybór dowolnej strategii bez sprawdzenia alternatywy na rzeczywistym korpusie danych.
Prawidłową reakcją jest mierzenie zamiast teoretyzowania. Należy zebrać od 20 do 50 reprezentatywnych par pytań i odpowiedzi, indeksować ten sam korpus przy użyciu dwóch lub trzech strategii i porównać wskaźniki recall@5 oraz precyzji kontekstowej. Treści o wbudowanej strukturze, takie jak dokumentacja API, dokumenty prawnicze i raporty finansowe, zazwyczaj radzą sobie lepiej, gdy są najpierw podzielone zgodnie z tą strukturą, ponieważ te jednostki są już spójne:
from langchain_text_splitters import RecursiveCharacterTextSplitter
# Recursive splitting respects structure first, falls back to
# character boundaries only when a section is still too large.
splitter = RecursiveCharacterTextSplitter(
chunk_size=512, # tokens, not characters, if you swap in a token-aware splitter
chunk_overlap=75, # ~15% overlap, a reasonable starting point
separators=["\n## ", "\n### ", "\n\n", "\n", ". ", " "],
)
chunks = splitter.split_text(document_text)
2. Jeden rozmiar fragmentu dla każdego typu dokumentu
Rozmiar jest wybierany raz, na wstępie, według ogólnej zasady, a następnie stosowany do mieszanej kolekcji. Odnośniki API, długie dokumenty polityki oraz transkrypcje rozmów otrzymują ten sam rozmiar.
Zbyt duże fragmenty osłabiają sygnał istotności. Fragment zawierający 2000 tokenów i dotyczący pięciu tematów daje wektor, który jest niewyraźną średnią wszystkich pięciu tematów i nie pasuje dobrze do żadnego z nich. Zbyt małe fragmenty pozbawiają czytelnika potrzebnego kontekstu, podobnie jak podpis funkcji bez informacji o parametrach lub klauzula bez sekcji, którą modyfikuje.
Rozmiar powinien odpowiadać gęstości treści. Dokumentacja techniczna zazwyczaj zawiera od 256 do 512 tokenów, co pozwala skupić się na pojedynczych koncepcjach. Teksty narracyjne lub regulacyjne wymagają zwykle od 1 024 do 2 048 tokenów, aby uwzględnić otaczający kontekst. Są to punkty wyjścia do weryfikacji, ponieważ optymalna liczba zależy od modelu embeddingu oraz od sposobu formułowania pytań przez użytkowników.
3. Zaniedbywanie nakładania się fragmentów
Nakładanie się fragmentów jest ustawiane raz i potem ignorowane lub pomijane, ponieważ rzekomo marnuje przestrzeń przechowywania. Bez niego zdanie przekraczające granicę fragmentu jest dzielone na dwa. Jeden fragment kończy się wprowadzeniem, a następny zaczyna się od wniosku, przy czym żaden z nich nie może być odczytany jako całościowa myśl. To powszechny i w pełni unikniony powód skarg, że odpowiedź gdzieś tam jest, ale model nie może jej znaleźć.
Rozmiar nakładania się wynoszący 10 do 20% wielkości fragmentu jest rozsądnym standardem: 50 do 100 tokenów dla fragmentu składającego się z 500 tokenów, co jest niewielkim kosztem w porównaniu z awariami, których można uniknąć. Więcej nie zawsze oznacza lepsze rezultaty. Zbyt duży stopień nakładania się przede wszystkim zwiększa zużycie pamięci i powoduje dodatkowy „szum”, a przynajmniej jedna systematyczna analiza z 2026 roku wykorzystująca metodę SPLADE nie wykazała żadnych mierzalnych korzyści z takiego rozwiązania w tym ustawieniu. To właściwy zestaw parametrów powinien decydować o tym, a nie standardowy wartość domyślna.
4. Ignorowanie własnej struktury dokumentu
Traktowanie każdego pliku jako pojedynczej całości jest prostsze, niezależnie od tego, czy chodzi o odnośnik API w formacie Markdown, umowę z numerowanymi klauzulami, czy o raport finansowy bogaty w tabele, jednak dzielenie dokumentu bez uwzględnienia jego struktury często powoduje, że nagłówek zostaje oddzielony od odpowiadającej mu sekcji lub tabela od akapitu, który ją opisuje. Najczęściej dotyka to opisu funkcji oddzielonego od listy jej parametrów, przez co pytanie dotyczące danej funkcji przynosi tylko część odpowiedzi.
Rozwiązaniem jest najpierw podział według struktury – według nagłówków, sekcji, list i tabel – a podział oparty na rozmiarze należy stosować tylko w tych sekcjach, które pozostają zbyt duże. Z tego powodu do połowy 2026 roku większość procesów dzielenia danych na fragmenty w produkcji ma charakter hybrydowy: najpierw struktura, dalszy podział semantyczny w długich, niestруктуrowanych fragmentach, rozmiar stały jako ostateczność, przy czym żaden jeden metod nie jest narzucany na złożony zbiór danych.
Trzy błędy w architekturze wyszukiwania
5. Wprowadzanie samych wyszukiwań wektorowych
Środowiska startowe domyślnie wykorzystują wyszukiwanie wektorowe. Jest to jedna wywołanie API, a w demonstracjach, gdzie zapytania testowe to konwersacyjne parafrazy, wygląda to doskonale – dokładnie to, w czym najlepiej radzą sobie gęste embeddingi.
Rzeczywisty ruch różni się od ruchu demonstracyjnego. Użytkownicy wpisują kody produktów, łańcuchy błędów, nazwy flag, numery ticketów oraz nazwy własne, które są krótkimi, dosłownymi tokenami. Modele o dużej gęstości, szkolone do grupowania znaczeń, mają tendencję do łączenia ich z powiązanymi, lecz błędnymi elementami. Testy porównawcze wielokrotnie pokazują tę różnicę: dostosowana konfiguracja hybrydowa przewyższyła każdą z metod używanej pojedynczo w teście rankingu e-commerce, a testy przeprowadzone przez praktyków wykazały, że metoda oparta wyłącznie na wektorach daje gorsze wyniki w kategorii recall@10 w porównaniu z prawidłowo połączoną konfiguracją hybrydową, głównie z powodu pominięcia dokładnych identyfikatorów. Wartości te różnią się w zależności od korpusów, ale tendencja ta utrzymuje się we wszystkich przeprowadzonych testach. Zawsze, gdy zapytania łączą styl konwersacyjny z dokładnym dopasowaniem – co zdarza się niemal zawsze – zwycięża rozwiązanie hybrydowe.
Zmiana polega na dodaniu indeksu BM25 lub SPLADE obok indeksu wektorowego. Weaviate, Elasticsearch, OpenSearch, Qdrant i Milvus obsługują obecnie natywne zapytania hybrydowe, a zarówno LangChain, jak i LlamaIndex dostarczają mechanizmy odzyskiwania danych typu fusion retriever, które je integrują:
from langchain.retrievers import EnsembleRetriever
from langchain_community.retrievers import BM25Retriever
bm25_retriever = BM25Retriever.from_texts(chunk_texts)
bm25_retriever.k = 20
vector_retriever = vectorstore.as_retriever(search_kwargs={"k": 20})
# weights are a starting point for RRF-style blending; tune against your eval set
hybrid_retriever = EnsembleRetriever(
retrievers=[bm25_retriever, vector_retriever],
weights=[0.4, 0.6],
)
results = hybrid_retriever.invoke(user_query)
6. Łączenie za pomocą średniej ważonej, a nie RRF
Po dodaniu BM25 intuicyjnym krokiem jest znormalizowanie obu list ocen do zakresu od 0 do 1 i połączenie ich za pomocą wag. Wydaje się to rozsądne w arkuszu kalkulacyjnym. Jednak oceny BM25 oraz podobieństwa kosinowe pochodzą z nieograniczonych, różnie ukształtowanych rozkładów, a normalizacja min-max jest krucha. Jeden dokument odbiegający od normy, który powtarza termin z zapytania dziesiątki razy, może po normalizacji sprowadzić wszystkie pozostałe oceny BM25 do zera, co zaburza połączoną listę rankingową w sposób trudny do zauważenia bez specjalnego sprawdzania.
Fuzja wzajemnych rankingu unika tego problemu poprzez wykorzystanie pozycji rankingu każdego dokumentu na każdej liście oraz całkowite zignorowanie ocen. Dlatego właśnie RRF, a nie średnia ważona, jest standardem w praktycznie każdej produkcyjnej implementacji hybrydowej wspominanej w opracowaniach inżynieryjnych z 2026 roku. Standardowa formuła przypisuje każdemu dokumencie sumę wartości 1 / (k + rank) dla wszystkich list, na których się pojawia, przy czym k=60 jest powszechnie stosowaną wartością domyślną, która łagodzi wpływ nadmiernie wysokich lub niskich rankingu.
7. Jeden k na każdym etapie
Top-k to zazwyczaj jedna globalna stała, która jest ponownie wykorzystywana podczas pierwszego etapu wyszukiwania, przy fuzji oraz przy końcowym promptzie. Gdy pierwszy etap pobiera tylko tyle fragmentów, ile może pomieścić prompt, zdolność przywoływania informacji już się zmniejsza, zanim reranker zdąży cokolwiek naprawić – fragment, który w wyszukiwaniu wektorowym znalazł się na 14. miejscu, nigdy do niego nie trafia. Odwrotnym błędem jest podanie setek kandydatów do rerankera bez późniejszego przycinania, co kosztuje czas i pieniądze oraz wypełnia prompt słabymi danymi. Uwaga modelu LLM pogarsza się pod takim obciążeniem (efekt „zagubienia pośrodku”), co powoduje, że korzyści z rerankingu są po cichu anulowane.
Rozważmy zamiast tego k jako lejek. Na pierwszym etapie wybierzmy szeroki zbiór – około 20 do 100 kandydatów – aby system ponownego rankowania miał możliwość poprawienia wczesnych błędów w kolejności, a następnie ograniczmy się do małej grupy końcowej, liczącej około 3 do 8 elementów, przeznaczonych do promptu. Dostosujmy wartość k dla każdego etapu osobno na podstawie zestawu oceniającego, ponieważ jedna wartość nie może służyć obu celom.
Dwa błędy w rankowaniu i embeddingach
8. Pomijanie ponownego rankowania
Ponowne rankowanie wymaga dodatkowego wywołania sieci lub kroku inferencji, co powoduje opóźnienia, a w przypadku usług hostowanych – dodatkowe koszty. Pod presją terminów jest to pierwsza rzecz, którą eliminuje się, a kolejność z pierwszego etapu traktowana jest jako ostateczna.
Poszukiwanie wektorowe pierwszego etapu opiera się na bi-kodownikach, które kompresują tekst w jeden stały wektor jeszcze przed wystąpieniem jakiegokolwiek zapytania. To właśnie sprawia, że są szybkie w dużych skali, ale ogranicza ich dokładność, ponieważ ginie szczegółowa interakcja pomiędzy danym zapytaniem a danym tekstem. Kodowniki krzyżowe przywracają tę interakcję, czytając oba elementy jednocześnie. Niezależne raporty z 2026 roku opisują ponowne sortowanie za pomocą kodowników krzyżowych jako najlepsze rozwiązanie do dodania do procesu poszukiwania o przyzwoitej skuteczności pierwszego etapu – typowe są wzrosty dokładności lub NDCG o kilka punktów, a wyniki na poziomie dwudziestu punktów osiągane są nawet na trudnych pod względem leksykalnym zbiorkach danych, przy dodatkowym opóźnieniu poniżej 200 ms przy rozsądnych rozmiarach zbiorów. Jeden z klientów korporacyjnych przypisał ponownemu sortowaniu wzrost dokładności o 23 punkty w ramach realizowanego projektu, co przewyższa efekty jakichkolwiek zmian w metodach embeddingu czy rozmiarze fragmentów tekstu. Gdy już zadziała poszukiwanie hybrydowe, to jest następna rzecz, którą warto wypróbować.
Zmiana polega na dodaniu etapu ponownego rankowania pomiędzy fuzją a końcowym promptem. Dla samodzielnego hostowania bez opłaty za każdą próbę, bge-reranker-v2-m3 to popularny otwarty cross-encoder o dobrej obsłudze wielu języków. API Rerank firmy Cohere stanowi standardową alternatywę typu zarządzaną, gdy nie chce się korzystać z infrastruktury GPU. Oba rozwiązania integrują się z LangChain i LlamaIndex:
from FlagEmbedding import FlagReranker
reranker = FlagReranker("BAAI/bge-reranker-v2-m3", use_fp16=True)
def rerank(query: str, candidates: list[str], top_k: int = 5) -> list[str]:
pairs = [[query, c] for c in candidates]
scores = reranker.compute_score(pairs, normalize=True)
ranked = sorted(zip(candidates, scores), key=lambda x: x[1], reverse=True)
return [text for text, _ in ranked[:top_k]]
final_context = rerank(user_query, fused_candidates, top_k=5)
9. Ogólny model embeddingu w specjalistycznym korpusie
Model embeddingu dostępny w ramach frameworku jest często stosowany bezpośrednio w korpusach prawniczych, medycznych lub finansowych, uzasadnione to kilkoma ręcznymi sprawdzeniami. Modele uniwersalne uczą się na szerokim materiale z Internetu i encyklopediach, dlatego mniej wyraźnie odróżniają specjalistyczną terminologię od innych elementów tekstu niż modele treningowane na materiałach specyficznych dla danej dziedziny. Ten brak precyzji najbardziej szkodzi w sytuacjach o najwyższych konsekwencjach. W dziedzinach regulowanych błąd pozornie niewielki, np. fragment opisujący standardową procedurę zamiast konkretnej wyjątkowej sytuacji, o którą ktoś pytał, skutkuje odpowiedzią, która wydaje się prawdopodobna, ale jest błędna, co jest gorsze niż oczywisty niepowodzenie.
Zanim przystąpisz do zapisania zmian, uruchom co najmniej jeden embeder dostosowany lub dopracowany do konkretnego domeny w porównaniu z domyślnym modelem na zbiorze referencyjnym. Gdy dopracowanie embedera nie jest możliwe, cross-encoder reranker, wyszkolony na małej grupie oznaczonych zapytań z danej domeny, często szybciej i taniej zamienia większość problemów, ponieważ naprawia błędy pierwszego etapu bez konieczności ponownego włączania całego korpusu.
Błąd, który ukrywa inne
10. Wymieranie wynagrodzenia w zależności od wyświetleń
Infrastruktura oceny wydaje się zbędnym obciążeniem obok pracy nad funkcjami, a sprawdzenie kilku wyników wydaje się wystarczające, jeśli demo wygląda dobrze. Zdecydowanie powoduje to największe koszty w dalszej fazie, ponieważ ukrywa pozostałe dziewięć problemów. Halucynacje oparte na technicznie uzasadnionym kontekście, błędny porządek dokumentów oraz fragmenty przecięte dokładnie w niewłaściwym miejscu nie mogą zostać skutecznie wykryte poprzez tylko przeczytanie wyników, a zanim użytkownicy je zgłoszą, są już w użyciu.
Rozwiązaniem jest złota kolekcja składająca się z 50 do 200 reprezentatywnych par pytań i odpowiedzi, obejmująca przypadki krawędziowe takie jak niejednoznaczne sformułowania, pytania wieloetapowe wymagające dwóch dokumentów oraz wrogie przeredagowania. Ocenia się ją za pomocą standardowej skali podzielonej na dwie części. System wyszukiwania oceniany jest pod kątem precyzji i przywoływania kontekstu, natomiast generator – pod kątem wierności oraz stopnia trafności odpowiedzi. W tym obszarze dominują dwa frameworki, które zespoły często łączą. Ragas to standardowe narzędzie do analizy metryk, a jego syntetyczny generator może stworzyć złotą kolekcję na podstawie korpusu, aby osoba mogła ją dalej udoskonalić. DeepEval, zbudowany na pytest, to standardowy sposób na przekształcenie oceny w rzeczywistą bramkę w procesie CI. Powszechnym podziałem jest wykorzystanie Ragas do eksploracji i generowania danych, a DeepEval do weryfikacji każdego pull requesta:
from deepeval import assert_test
from deepeval.metrics import FaithfulnessMetric, ContextualPrecisionMetric
from deepeval.test_case import LLMTestCase
def test_refund_policy_query():
test_case = LLMTestCase(
input="What is the refund window for the Pro plan?",
actual_output=rag_pipeline.run("What is the refund window for the Pro plan?"),
retrieval_context=rag_pipeline.last_retrieved_chunks,
expected_output="Pro plan purchases can be refunded within 14 days of purchase.",
)
faithfulness = FaithfulnessMetric(threshold=0.8)
precision = ContextualPrecisionMetric(threshold=0.7)
assert_test(test_case, [faithfulness, precision])
Umieść taki zestaw w CI, aby mała modyfikacja dotycząca dzielenia na fragmenty, zamiana embedów lub aktualizacja bazy wiedzy, która pogarsza funkcjonalność wyszukiwania, powodowała przerwanie procesu budowania, zanim zepsuje dzień klienta.
Jak błędy różnią się w zależności od ustawień
- Wewnętrzne wyszukiwanie w przedsiębiorstwie i systemy Q&A do dokumentów, najczęstsza konfiguracja, w dużej mierze opiera się na hybrydowym wyszukiwaniu. Pracownicy wpisują numery zgłoszeń, kody polityk oraz SKU razem z pytaniami w języku potocznym, a wyszukiwanie oparte wyłącznie na treści tekstowej pomija część dosłowną zapytania.
- Boty obsługi klienta najbardziej korzystają z ponownego rankowania odpowiedzi. Błędna, choć płynna odpowiedź może doprowadzić do powstania zgłoszenia lub utraty konta, zamiast do obojętności kolegi z zespołu.
- Przemysły regulowane (finanse, opieka zdrowotna, prawo) wymagają embeddingów dostosowanych do konkretnych dziedzin lub narzędzi do ponownego rankowania oraz ścisłej oceny, ponieważ nieprecyzyjne wyszukiwanie może prowadzić do problemów z zgodnością z przepisami i ryzyka prawnych.
- Produkty konsumenckie o dużym ruchu muszą funkcjonować przy najściślejszych ograniczeniach czasu reakcji podczas fuzji danych i ponownego rankowania. Celem jest osiągnięcie jak najwyższej dokładności przy jednoczesnym zachowaniu budżetu czasowego poniżej 200 ms, co faworyzuje małe modele cross-encoder lub samodzielnie hostowane narzędzia GPU do rankowania zamiast największych modeli.
- Asystenci do programowania i platformy narzędzi dla programistów to nowszy, szybko rozwijający się obszar, w którym rozbieranie treści na fragmenty z uwzględnieniem ich struktury ma większe znaczenie niż w tekście prozatorskim. Kod i referencje API mają wysoką stopień strukturyzacji, a nieostrożne dzielenie ich niszczy właśnie tę strukturę, która umożliwia ich wyszukiwanie.
Wybór kolejnego kroku
W fazie przedpremierowej, lub gdy nadal sprawdza się, czy RAG w ogóle jest wykonalny, odpowiednim punktem wyjścia jest wyszukiwanie oparte wyłącznie na wektorach: jest najszybsze do wdrożenia i pozwala odpowiedzieć na pytania dotyczące architektury w ciągu jednego dnia. Gdy pojawią się rzeczywiste zapytania użytkowników, należy przeanalizować logi w poszukiwaniu wzorców dokładnego dopasowania, takich jak kody produktów, identyfikatory biletów i wartości konfiguracyjne. Jeśli jakiekolwiek się pojawią, należy najpierw dodać BM25 w połączeniu z RRF, ponieważ źródła jednogłośnie wskazują, że jest to największe ulepszenie pod względem szybkości wyszukiwania, i to z dużą przewagą. Następnie przystępuje się do ponownego rankowania, gdy funkcjonuje wyszukiwanie hybrydowe, a celem jest precyzja, a nie tylko ogólna liczba odnalezionych wyników. Jest to rozwiązanie niedrogie w stosunku do efektów, które przynosi, i nie wymaga ponownego budowania indeksu. SPLADE lub embeddingi dostosowane do konkretnego domeny powinny zostać wdrożone dopiero przez zespoły posiadające rozwinięty proces oceny, które już wykazały, że połączenie wyszukiwania hybrydowego z ponownym rankowaniem pozostawia luki, ponieważ wymagają one większego wysiłku i konserwacji, a ich uzasadnienie bez podstawowych wskaźników jest trudne.
Liczba pracowników i budżet decydują o odpowiedzi. Przy dwóch inżynierach zarządzana API do ponownego rankowania (Cohere jest zwykle najlepszym wyborem) jest lepsza niż używanie własnego cross-encodera: przy umiarkowanym ruchu opłaty są niskie w porównaniu z godzinami pracy serwerów GPU. Tam, gdzie już istnieje personel do zarządzania procesami MLOps oraz GPU, albo gdy ruch jest na tyle duży, że opłaty za każdą prośbę stają się istotnym elementem kosztów, sensowniejsze jest hostowanie otwartego modelu takiego jak bge-reranker-v2-m3.
Ile nadal kosztuje dobry pipeline
RAG nie jest idealnym rozwiązaniem. Jego główną zaletą jest powiązanie z rzeczywistymi źródłami: odpowiedzi mogą cytować pobrane materiały zamiast polegać wyłącznie na tym, co model zapamiętał, a baza wiedzy może być aktualizowana bez konieczności ponownego szkolenia. Dodatkowe elementy jednak stanowią rzeczywisty obciążenie operacyjne. Trzeba utrzymywać w zgodności dwa indeksy, mechanizm ponownego rankowania w celu wykrywania odchyleń, proces oceny, aby zachować jego jakość na najwyższym poziomie, oraz schemat dzielenia tekstu na fragmenty, który wymaga ponownej weryfikacji w przypadku zmiany składu dokumentów.
RAG również nie eliminuje halucynacji. Redukuje on fikcje wynikające z braku wiedzy, ale nie wpływa na sytuacje, gdy model błędnie interpretuje lub stosuje kontekst, który został mu prawidłowo podany. Istnieją metryki wiarygodności, ponieważ „powiązanie z rzeczywistym kontekstem” i „poprawność” to różne właściwości, a zaawansowany proces pomiarowy obejmuje obie z nich.
Gotowość do produkcji
- Ocena w CI. Uruchamiaj procesy Ragas i DeepEval przy każdej zmianie promptu, mechanizmu wyszukiwania lub bazy wiedzy, zamiast sprawdzać je tylko raz podczas uruchomienia.
- Synchronizacja indeksów. Aktualizuj indeksy BM25 i wektorowe jednocześnie lub według tego samego harmonogramu. Gdy stary, rzadki indeks jest używany razem z nowymi embeddingami, wyniki wyszukiwania mogą ulec zmianom w sposób trudny do zauważenia.
- Obserwowalność. Rejestruj fragmenty danych pobrane dla każdego zapytania, a nie tylko ostateczną odpowiedź. Dzięki temu można bez domysłów ustalić, czy zła odpowiedź wynika z problemów w procesie wyszukiwania, czy z generowania treści.
- Udostępnienia. Unikaj przechowywania kluczy API do ponownego sortowania i generowania embeddingów w repozytorium oraz rotuj je za pomocą standardowego menedżera sekretów.
Krótkie podsumowanie
Zobacz, co zwrócił retriever, zanim zmieniono prompt lub model. Dziewięć z dziesięciu błędów (słabe dzielenie na fragmenty, brak wyszukiwania hybrydowego, naiwna fuzja, błędna wielkość zbiorów kandydatów, pominięcie ponownego sortowania, nie sprawdzony model embeddingów) to problemy związane z procesem wydobywania informacji, na które istnieją rozwiązania. Dziesiąty błąd, brak oceny, jest powodem, dla którego pozostałe dziewięć tak często pozostaje niezauważone.
Żadna z tych poprawek nie wymaga zespołu badawczego. Dodanie BM25 obok istniejącego magazynu wektorowego, zastąpienie metody łączenia wyników RRF lub pominięcie kroku ponownego sortowania pomiędzy fuzją a generowaniem to działania bardziej przypominające pracę inżynierską niż całkowitą przebudowę, a wszystkie one cieszą się spójnym wsparciem w niezależnych źródłach, nawet jeśli liczby się różnią. Praktyczny początek: pobierz dwutygodniowy zbiór rzeczywistych zapytań użytkowników, policz, ile z nich zawiera dokładne identyfikatory, które w wyszukiwaniu wektorowym zostałyby zatarte, i stwórz zbiór „złoty” składający się z 50 zapytań na podstawie już dostępnych nieudanych prób. To mniej, niż się wydaje, i pokazuje, które z dziesięciu błędów jest najdroższe w rozliczeniach.
Literatura pokrewna
- Diagnozowanie ukrytych błędów RAG: pobieranie danych, dzielenie na fragmenty, filtry i oceny — Odpowiedzi generowane przez RAG mogą brzmieć poprawnie, a mimo to być błędne. Przewodnik skierowany do programistów Python, który pomaga w śledzeniu procesów pobierania danych, dzielenia ich na fragmenty, stosowania filtrów metadanych, ocen wyników, hybrydowego wyszukiwania oraz uzasadniania odpowiedzi.
- Hybrydowy RAG do tekstów prawniczych: dzielenie na fragmenty, BM25, BGE i ponowna klasyfikacja — Proces przetwarzania danych prawniczych w oparciu o Konstytucję Indii: dzielenie tekstu na fragmenty hierarchiczne, pobieranie informacji za pomocą BM25 i BGE, łączenie wyników klasyfikacji, ponowna klasyfikacja przy użyciu cross-encodera oraz rozszerzanie zapytań, sprawdzone na testach benchmarkowych.