Krytyczne miary jakości RAG: recall@k, MRR, nDCG i „answer groundedness” na jednym dashboardzie

1. Wprowadzenie: dlaczego metryki RAG są inne niż w klasycznym IR i QA

RAG (Retrieval-Augmented Generation) łączy dwa światy: wyszukiwanie (dobór dokumentów lub fragmentów) oraz generowanie (złożenie odpowiedzi przez model językowy). To powoduje, że ocena jakości nie może opierać się wyłącznie na metrykach znanych z klasycznego Information Retrieval (IR) ani wyłącznie na metrykach znanych z klasycznego Question Answering (QA). W RAG łatwo uzyskać dobre wyniki w jednym komponencie i jednocześnie porażkę w drugim — a użytkownik odczuwa końcową jakość jako rezultat obu.

W klasycznym IR celem jest zwykle dostarczenie rankingu wyników, który użytkownik sam eksploruje. Jakość mierzy się więc tym, czy i jak wysoko pojawiają się trafne dokumenty. W klasycznym QA (zwłaszcza ekstrakcyjnym) ocenia się głównie zgodność odpowiedzi z prawdą referencyjną. RAG zmienia założenia: model ma udzielić finalnej odpowiedzi, ale powinien to zrobić na podstawie dostarczonych źródeł. Pojawia się więc dodatkowy wymiar jakości: nie tylko „czy odpowiedź brzmi dobrze”, lecz także „czy jest ugruntowana w kontekście” i „czy kontekst był wystarczający”.

Dlatego metryki w RAG muszą odpowiadać na kilka odrębnych pytań diagnostycznych:

• Czy retrieval dostarczył właściwe materiały? Nawet świetny generator nie „wymyśli” poprawnej, zgodnej z polityką organizacji odpowiedzi, jeśli w kontekście brakuje kluczowego fragmentu albo pojawiły się źródła mylące.
• Czy ranking jest użyteczny dla generacji? W RAG liczy się szczególnie to, co trafia do okna kontekstowego. Trafny dokument na dalekiej pozycji może być praktycznie bezwartościowy, jeśli nie zmieści się w promptcie lub zostanie ucięty.
• Czy model wykorzystał dowody, które dostał? Możliwa jest sytuacja, w której źródła są poprawne, ale odpowiedź jest nieprecyzyjna, niekompletna albo zawiera halucynacje, bo model pominął istotne zdania.
• Czy odpowiedź jest bezpieczna i zgodna z wymaganiami produktu? W systemach produkcyjnych jakość to nie tylko poprawność merytoryczna, ale też cytowalność, spójność, format, styl, ograniczenia prawne i polityki treści.

RAG wprowadza też istotne różnice operacyjne, które wpływają na interpretację metryk. Po pierwsze, „relewancja” jest często zależna od pytania i sposobu generacji: ten sam dokument może być wystarczający do krótkiej odpowiedzi, a niewystarczający do odpowiedzi wymagającej uzasadnienia i szczegółów. Po drugie, koszt błędu jest asymetryczny: brak kluczowego dowodu w top-k może być krytyczny, podczas gdy dodanie jednego średnio trafnego fragmentu może jedynie wprowadzić szum. Po trzecie, dane referencyjne bywają niepełne: w wielu domenach trudno stworzyć „jedyną poprawną listę” dokumentów, które powinny zostać zretrievowane.

W praktyce oznacza to, że sensowna ocena RAG powinna łączyć metryki retrieval (czyli jakość doboru i rankingu kontekstu) z metrykami generacji (czyli jakość finalnej odpowiedzi), a dodatkowo uwzględniać wskaźniki mówiące, na ile odpowiedź jest oparta na źródłach. Dopiero taki zestaw pozwala odróżnić typowe tryby awarii: „retrieval nie znalazł”, „ranking schował dowód”, „kontekst jest dobry, ale model nie korzysta”, „model odpowiada płynnie, lecz niezgodnie ze źródłami”.

W dalszej części artykułu skupimy się na kluczowych metrykach, które pomagają uchwycić te różnice: miarach pokrycia i pozycji trafnych wyników w top-k, miarach jakości rankingu oraz ocenie ugruntowania odpowiedzi w dostarczonych fragmentach — tak, aby można je było spójnie śledzić na jednym dashboardzie.

2. Recall@k: definicja, sposób liczenia, interpretacja i typowe pułapki

Recall@k to podstawowa miara jakości etapu retrieval w systemach RAG. Odpowiada na pytanie: czy wśród pierwszych k zwróconych fragmentów (chunków/dokumentów) znalazło się cokolwiek, co faktycznie pozwala poprawnie odpowiedzieć na pytanie? W praktyce to jedna z najczęściej używanych metryk, bo jest prosta i bezpośrednio wiąże się z ryzykiem „nie mam materiału, więc halucynuję”. Podczas szkoleń Cognity ten temat wraca regularnie – dlatego zdecydowaliśmy się go omówić również tutaj.

Definicja

Najczęściej spotkasz wariant „hit rate”, czyli recall rozumiany binarnie na zapytanie:

• Recall@k = 1, jeśli w top-k wyników jest przynajmniej jeden element oznaczony jako relewantny (gold).
• Recall@k = 0, jeśli w top-k nie ma żadnego relewantnego elementu.

Następnie uśrednia się wynik po zbiorze zapytań. W ujęciu klasycznym recall bywa definiowany jako „odsetek wszystkich relewantnych elementów, które zostały odnalezione”, ale w RAG często ważniejsza jest wersja „czy znalazłem przynajmniej jeden wystarczający dowód”, bo generator zwykle nie potrzebuje wszystkich relewantnych fragmentów.

Sposób liczenia (praktycznie, krok po kroku)

• Ustal zbiór zapytań i dla każdego zapytania przygotuj złoty zestaw (gold) fragmentów/dokumentów uznanych za relewantne lub wystarczające do odpowiedzi.
• Dla każdego zapytania pobierz z retrievera ranking wyników i weź pierwsze k.
• Sprawdź, czy w top-k występuje przynajmniej jeden element z gold (albo element uznany za dopasowany do gold według przyjętej reguły dopasowania).
• Policz średnią z wartości 0/1 po wszystkich zapytaniach (to daje recall@k dla całego testu).

Kluczowe jest to, co uznasz za „ten sam” dokument/fragment: czasem porównuje się identyfikatory dokumentów, czasem identyfikatory chunków, a czasem stosuje się dopasowanie po źródle lub podobieństwie treści. Ta decyzja potrafi zmienić wynik równie mocno jak sam model retrievalu.

Interpretacja: co mówi recall@k w RAG

• Wysoki recall@k oznacza, że system zwykle dostarcza generatorowi materiał, na którym da się oprzeć odpowiedź. To warunek konieczny dobrej jakości RAG, ale nie gwarantuje dobrej odpowiedzi.
• Niski recall@k to jasny sygnał, że problem jest „u źródła”: zbyt słaby retriever, zły podział na chunki, brakujące dane w indeksie, nietrafione zapytania (query formulation) albo złe dopasowanie semantyczne.
• Wpływ k: recall@1 bywa surowy (czy pierwszy wynik jest trafiony), recall@5/10 mierzy „czy w rozsądnym oknie kontekstu dostarczam dowód”. W RAG dobór k powinien odzwierciedlać realne ograniczenia kontekstu i strategię kompozycji promptu.

Recall@k jest więc świetny do monitorowania, czy retrieval „dowozi” i do porównywania wersji indeksu, embeddingów, filtrów czy re-rankingu. Słabiej nadaje się do oceny, czy ranking jest dobrze ułożony oraz czy odpowiedź faktycznie jest wierna źródłom.

Typowe pułapki i błędy interpretacyjne

• Niejasna definicja „relewancji”. W RAG relewancja bywa „wystarczalnością dowodową”, a nie ogólną zgodnością tematyczną. Jeśli etykietujesz zbyt szeroko (tematycznie), recall@k będzie zawyżony i nie przełoży się na jakość odpowiedzi.
• Mylenie poziomu dokumentu i chunku. Możesz mieć wysoki recall na poziomie dokumentu, ale niski na poziomie chunku (bo trafiasz dokument, lecz nie ten fragment). Dla generatora liczy się często właśnie fragment, który zawiera konkretny fakt.
• Gold jako „jeden prawidłowy fragment”. Jeśli w danych jest tylko jeden wskazany chunk, metryka karze alternatywne, równie dobre dowody. Wtedy recall@k spada mimo sensownie działającego retrievalu.
• Wrażliwość na duplikaty i overlap chunków. Przy nakładających się chunkach top-k może zawierać kilka bardzo podobnych fragmentów, co sztucznie poprawia szanse „trafienia” (hit), ale realnie nie zwiększa pokrycia informacji.
• Brak rozróżnienia między „znalezione” a „użyte”. Recall@k mówi tylko, że dowód był wśród wyników. Generator mógł go nie dostać (np. obcięcie kontekstu), albo dostać i zignorować. Dlatego recall@k jest metryką retrieval, nie metryką odpowiedzi.
• Uśrednianie ukrywa ogony. Średnia recall@k potrafi wyglądać dobrze, gdy system radzi sobie z większością pytań, ale kompletnie przegrywa w określonych klasach (np. pytania wieloetapowe, liczby, daty, wyjątki). Bez segmentacji łatwo przeoczyć te luki.
• Zbyt duże k „na papierze”. Podnoszenie k prawie zawsze podnosi recall, ale może być nierealistyczne kosztowo (więcej tokenów, wolniej) i wprowadzać szum do promptu. Wtedy recall@k rośnie, a jakość odpowiedzi wcale nie.
• Niedopasowanie do przepływu produkcyjnego. Jeśli w produkcji stosujesz filtry (np. po dacie, uprawnieniach, typie źródła) lub re-ranking, a w ewaluacji nie, recall@k będzie mylący — mierzysz inny system niż działa na użytkowniku.
• Efekt „łatwych pytań”. Jeśli zestaw testowy zawiera dużo pytań, gdzie wystarczy ogólny fragment, recall@k będzie zawyżony względem realnych scenariuszy wymagających precyzyjnego dowodu.

W dobrze prowadzonym pomiarze recall@k jest traktowany jako minimalny barometr dostępności dowodów: jeśli spada, najpierw naprawiasz retrieval (dane, indeks, embeddingi, strategię zapytania). Jeśli jest wysoki, a odpowiedzi nadal zawodzą, problem zwykle leży gdzie indziej niż samo „znalezienie” materiału.

3. MRR: kiedy ma sens, jak liczyć, ograniczenia i warianty (np. MRR@k)

MRR (Mean Reciprocal Rank) mierzy, jak wysoko w rankingu pojawia się pierwszy trafiony (relewantny) wynik dla każdego zapytania. W praktyce odpowiada na pytanie: „Czy użytkownik/LLM szybko natrafia na pierwszy fragment, który wystarczy, by ruszyć dalej?”. W RAG MRR jest szczególnie przydatne wtedy, gdy pipeline jest wrażliwy na to, czy w top wynikach znajdzie się choć jeden „dobry” kontekst (np. ponieważ generator zwykle i tak używa tylko kilku pierwszych chunków, albo reranker ma ograniczony budżet).

Kiedy MRR ma sens w RAG

• Jednoznaczne pytania, gdzie istnieje pojedynczy „kluczowy” fragment (lub mała liczba zamiennych fragmentów), który umożliwia poprawną odpowiedź.
• Pipeline z mocnym biasem na top rank: gdy do LLM trafia np. top-1/top-3, albo gdy koszt kontekstu jest wysoki i system agresywnie tnie listę wyników.
• Ocena rankingowania/rerankingu: MRR dobrze wychwytuje poprawę „przesuwania” właściwego dokumentu do góry.

MRR jest mniej informatywne w scenariuszach, w których poprawna odpowiedź wymaga złożenia informacji z wielu źródeł (multi-hop) lub gdy istotna jest jakość całego top-k, a nie tylko pierwszego trafienia.

Definicja i sposób liczenia

Dla pojedynczego zapytania q znajdujemy pozycję r(q) pierwszego relewantnego wyniku w rankingu (1 = na pierwszym miejscu). Następnie liczymy RR(q) = 1 / r(q). Średnia po wszystkich zapytaniach daje MRR.

Wzór:

MRR = (1/|Q|) * Σ_q∈Q (1 / r(q)), gdzie r(q) to ranga pierwszego wyniku spełniającego kryterium relewancji.

Jak interpretować wynik

• MRR jest w przedziale [0, 1]. Wynik 1.0 oznacza, że dla każdego zapytania pierwszy wynik był relewantny.
• MRR mocno premiuje trafienia bardzo wysoko: przejście z rangi 10 na 2 daje duży skok (0,1 → 0,5), a poprawa z 50 na 40 jest prawie niewidoczna.
• MRR jest wrażliwe na „pudła”: jeśli nie ma żadnego relewantnego wyniku, wkład dla zapytania to zwykle 0.

Ograniczenia i typowe błędy użycia

• Ignoruje wszystko po pierwszym trafieniu – jeśli top-1 jest relewantny, MRR nie odróżni sytuacji, gdzie kolejne wyniki są świetne vs. kompletnie złe. W RAG może to maskować problemy, gdy LLM potrzebuje więcej niż jednego fragmentu.
• Wymaga binarnej decyzji „relewantny/nierelewantny” (albo przynajmniej progu), co bywa niejednoznaczne przy chunkach: fragment może być częściowo pomocny, ale nie wystarczający.
• Nie rozróżnia jakości między relewantnymi wynikami: pierwszy „jako-tako” trafiony chunk i pierwszy „idealny” chunk są liczone tak samo, jeśli oba spełniają kryterium relewancji.
• Wieloodpowiedziowość i duplikaty: jeśli kolekcja zawiera bliskie duplikaty lub wiele zamiennych źródeł, MRR może wyglądać świetnie, mimo że system nie radzi sobie z trudniejszymi przypadkami (metryka staje się „za łatwa”).
• Nie mówi nic o pokryciu: można mieć wysokie MRR na podzbiorze zapytań, a jednocześnie często nie zwracać żadnego trafienia w top-k (dlatego zwykle ogląda się ją obok metryk „czy w ogóle znalazł”).

Warianty: MRR@k i inne praktyczne modyfikacje

W systemach RAG rzadko interesuje nas pełna lista wyników — liczy się to, co realnie trafia do kolejnego kroku. Stąd popularny wariant:

• MRR@k: jeśli pierwszy relewantny wynik jest na pozycji ≤ k, RR = 1/r; jeśli nie ma go w top-k, RR = 0. Ten wariant „przywiązuje” metrykę do budżetu kontekstu (np. k = 5, 10, 20).

W praktyce spotyka się też:

• MRR z wieloma relewantnymi etykietami: nadal liczy się tylko pierwszy trafiony, ale relewantnych wyników może być kilka (ważne, by definicja relewancji była spójna).
• MRR na poziomie dokumentu vs. chunka: przy chunkingu można uznać trafienie dowolnego chunka z właściwego dokumentu za „hit” (to często stabilizuje metrykę, ale może ukrywać problemy z lokalizacją właściwego fragmentu).

Krótki przykład obliczenia

Załóżmy 3 zapytania, a pierwsze relewantne wyniki są odpowiednio na pozycjach: 1, 3 oraz brak w top-10.

• RR = 1/1 = 1.0
• RR = 1/3 ≈ 0.333
• RR = 0 (brak trafienia)

MRR = (1 + 0.333 + 0) / 3 ≈ 0.444.

Minimalny kod (pomocniczo)

def mrr_at_k(ranks, k=None):
    # ranks: lista pozycji (1..n) pierwszego relewantnego wyniku lub None gdy brak
    rr = []
    for r in ranks:
        if r is None:
            rr.append(0.0)
        elif k is not None and r > k:
            rr.append(0.0)
        else:
            rr.append(1.0 / r)
    return sum(rr) / len(rr) if rr else 0.0

# przykład
print(mrr_at_k([1, 3, None]))      # 0.444...
print(mrr_at_k([1, 3, None], 10))  # 0.444...

Co raportować obok MRR, żeby metryka była użyteczna

• MRR@k dla kilku k (np. 1/3/5/10), żeby widzieć, czy problemem jest sam top-1 czy ogólna jakość rankingu.
• Odsetek zapytań z brakiem trafienia w top-k, bo MRR potrafi „wyglądać ok” przy nierównym rozkładzie łatwych i trudnych pytań.
• Rozbicie po typach zapytań (np. faktograficzne vs. wieloetapowe), bo MRR jest naturalnie uprzywilejowane dla pytań, gdzie wystarcza pojedynczy fragment.

4. nDCG: ocena jakości rankingu (gain, discount), przykładowe obliczenie i problemy z etykietami relewancji

W RAG sama obecność „jakiegoś” trafnego dokumentu w top-k często nie wystarcza. Liczy się też kolejność wyników: dokument, który naprawdę wspiera odpowiedź, powinien znaleźć się jak najwyżej, bo modele generatywne w praktyce mają ograniczony budżet kontekstu i/lub czytają wyniki z silnym priorytetem pierwszych pozycji. Do oceny jakości rankingu najczęściej używa się nDCG (normalized Discounted Cumulative Gain).

Czym jest DCG: „gain” i „discount”

nDCG opiera się na dwóch intuicjach:

• Gain (zysk): im bardziej trafny element, tym większy wkład do wyniku. Trafność może być stopniowana (np. 0–3), co jest szczególnie przydatne w RAG, gdzie dokumenty bywają: idealnie wspierające, częściowo wspierające, luźno powiązane albo nietrafne.
• Discount (dyskont): trafne elementy są tym mniej wartościowe, im niżej w rankingu się pojawiają. Najczęściej dyskont rośnie logarytmicznie, bo różnica między pozycją 1 i 2 jest większa niż między 21 i 22.

Typowa postać:

DCG@k = Σ_{i=1..k} (gain_i / log2(i + 1))

gdzie gain_i wynika z etykiety relewancji elementu na pozycji i. Często stosuje się też wersję z wykładniczym gainem:

DCG@k = Σ_{i=1..k} ((2^{rel_i} - 1) / log2(i + 1))

Wersja wykładnicza silniej premiuje „najlepsze” dokumenty i bywa użyteczna, gdy różnica między rel=3 a rel=2 ma dla zadania duże znaczenie (np. dokument wprost zawierający dowód vs. ogólny opis).

Po co normalizacja (nDCG)

Surowe DCG zależy od tego, ile w ogóle jest trafnych dokumentów dla danego zapytania i jak są „mocne” etykiety. Żeby wyniki były porównywalne między zapytaniami, liczy się nDCG jako stosunek do najlepszego możliwego rankingu:

nDCG@k = DCG@k / IDCG@k

IDCG@k (Ideal DCG) to DCG@k policzone dla rankingu idealnego, czyli takiego, w którym dokumenty są posortowane malejąco po relewancji. Dzięki temu nDCG@k zwykle mieści się w przedziale 0–1, co ułatwia interpretację i śledzenie trendów.

Przykładowe obliczenie nDCG@5 (prosty wariant)

Załóżmy, że dla zapytania mamy ocenę relewancji wyników (skala 0–3) na pozycjach 1–5: [3, 2, 0, 1, 2]. Użyjmy liniowego gainu: gain = rel.

DCG@5 ≈ 3.000 + 1.262 + 0 + 0.431 + 0.774 = 5.467.

Aby policzyć IDCG@5, sortujemy relewancje malejąco: [3, 2, 2, 1, 0].

IDCG@5 ≈ 3.000 + 1.262 + 1.000 + 0.431 + 0 = 5.693.

Zatem:

nDCG@5 ≈ 5.467 / 5.693 = 0.960

Interpretacja: ranking jest blisko ideału, ale nie perfekcyjny (w tym przykładzie „2” na pozycji 5 mogłoby znaleźć się wyżej, a „0” z pozycji 3 nie powinno wypychać lepszych wyników).

Jak interpretować nDCG w kontekście RAG

• Czułość na kolejność: nDCG mocno premiuje umieszczenie najlepszych źródeł na górze. To pasuje do RAG, gdzie pierwsze fragmenty mają największą szansę wejść do kontekstu i realnie wpłynąć na odpowiedź.
• Obsługa relewancji stopniowanej: zamiast binarnego „trafny/nietrafny”, możesz rozróżniać dokumenty podpierające odpowiedź vs. tylko tematycznie zbliżone. To ważne, bo w RAG „tematycznie podobny” bywa bezużyteczny dla ugruntowania odpowiedzi.
• Porównywalność między zapytaniami: dzięki normalizacji, zapytania z różną liczbą trafnych dokumentów nie dominują średniej.

Problemy z etykietami relewancji (najczęstsze pułapki)

Doświadczenie Cognity pokazuje, że rozwiązanie tego problemu przynosi szybkie i zauważalne efekty w codziennej pracy: nDCG zaczyna wtedy lepiej korelować z realną jakością odpowiedzi, a nie tylko z „podobieństwem tematycznym”.

• Niejasna definicja „relewancji”: w RAG warto rozdzielić co najmniej dwa pojęcia: topical relevance (czy dokument jest o tym) oraz supportiveness (czy dokument dostarcza dowodu/fragmentu, który można zacytować lub parafrazować w odpowiedzi). Etykiety mieszające te znaczenia prowadzą do nDCG, które „wygląda dobrze”, ale nie koreluje z jakością odpowiedzi.
• Skala ocen i jej kalibracja: różnica między 2 a 3 w skali 0–3 musi być operacyjnie opisana (np. „3 = zawiera bezpośredni fragment z odpowiedzią”, „2 = zawiera przesłanki”, itd.). Bez tego różni anotatorzy wprowadzają losowy szum, który maskuje regresje.
• Niepełne zbiory ocen (missing judgments): jeśli oceniasz tylko część wyników (np. top-10), dokumenty nieocenione bywają traktowane jak 0. To może karać systemy, które „odkrywają” nowe, nieocenione źródła. W praktyce wymaga to ostrożności w doborze procesu anotacji i interpretacji spadków.
• Duplikaty i fragmentacja źródeł: ten sam sens może pojawić się w wielu podobnych chunkach. Jeśli wszystkie dostaną wysoką relewancję, nDCG może premiować „zalanie” rankingu wariantami tego samego dowodu zamiast różnorodnego pokrycia. Warto mieć zasady etykietowania, które uwzględniają redundancję.
• Granularność: dokument vs. chunk: etykietowanie na poziomie całego dokumentu bywa zbyt grube (bo trafny jest tylko jeden akapit), a na poziomie chunków bywa niestabilne (bo drobne zmiany segmentacji zmieniają etykiety). To wpływa na porównywalność nDCG między wersjami pipeline’u.
• Zależność od intencji pytania: dla jednych zapytań wystarczy źródło ogólne, dla innych potrzebny jest precyzyjny przepis/parametr. Jeśli etykiety nie uwzględniają typu pytania, nDCG może faworyzować jeden styl retrievalu kosztem drugiego.

Minimalny kod do policzenia nDCG@k (pomocniczo)

import math

def dcg(rels, k=None):
    if k is None:
        k = len(rels)
    s = 0.0
    for i, rel in enumerate(rels[:k], start=1):
        s += rel / math.log2(i + 1)
    return s

def ndcg(rels, k=None):
    if k is None:
        k = len(rels)
    ideal = sorted(rels, reverse=True)
    denom = dcg(ideal, k)
    return 0.0 if denom == 0 else dcg(rels, k) / denom

W praktyce kluczowe jest nie tyle samo liczenie, co konsekwentne zdefiniowanie rel (co oznacza 0/1/2/3) oraz kontrola jakości etykiet, bo to one determinują, czy nDCG faktycznie mierzy „jakość rankingu źródeł pod odpowiedź”, czy tylko „podobieństwo tematyczne”.

5. Answer groundedness: co mierzy, jak ją oceniać (LLM-as-judge vs reguły), ryzyka i walidacja

Answer groundedness (ugruntowanie odpowiedzi) mierzy, w jakim stopniu treść wygenerowanej odpowiedzi jest poparta dostarczonym kontekstem (np. fragmentami z retrievera) oraz czy nie zawiera informacji, których w tym kontekście nie ma. To metryka specyficzna dla RAG, bo w klasycznym QA często ocenia się „czy odpowiedź jest poprawna”, a w RAG równie ważne jest „czy jest poprawna na podstawie dostarczonych źródeł”.

W praktyce groundedness odpowiada na pytania:

• Czy każdy kluczowy fakt w odpowiedzi da się wskazać w źródłach (cytaty/fragmenty)?
• Czy model nie dopowiada detali (liczb, nazw, warunków), których nie ma w kontekście?
• Czy odpowiedź nie „przeskakuje” z kontekstu na wiedzę ogólną modelu?

Warto odróżnić groundedness od metryk retrievalowych (np. recall@k): retrieval może dostarczyć dobre źródła, a generacja i tak może „odjechać” (halucynacja, nadinterpretacja, łączenie wątków). I odwrotnie: odpowiedź może być w dużej części prawdziwa, ale nieugruntowana w aktualnie dostarczonych dokumentach, co w zastosowaniach audytowalnych jest problemem.

Co dokładnie jest „ugruntowane”? Granularność oceny

Groundedness można rozumieć na różnych poziomach, a wybór poziomu wpływa na wynik i koszt oceny:

• Poziom odpowiedzi (globalny) – jedna ocena dla całej odpowiedzi: „w jakim stopniu jest poparta kontekstem?”. Szybkie, ale mniej diagnostyczne.
• Poziom zdań/claimów – rozbijasz odpowiedź na twierdzenia i oceniasz każde z nich. Lepsze do debugowania (widać, które fragmenty są nieugruntowane), ale wymaga dodatkowego kroku ekstrakcji claimów.
• Poziom cytowań – wymagasz wskazania fragmentów źródła dla każdego claimu. Najbardziej audytowalne, ale wymaga standardu cytowania i stabilnego mapowania na źródła.

W większości projektów RAG groundedness staje się metryką bezpieczeństwa (czy model nie wymyśla), a nie tylko „metryką jakości językowej”. Dlatego często stosuje się też progi (np. „nie wypuszczaj odpowiedzi, jeśli groundedness < X” lub „wymuś odmowę, jeśli brak dowodów”).

Jak oceniać groundedness: LLM-as-judge vs podejścia regułowe

Najczęściej spotkasz dwie klasy metod: oceny przez model (LLM-as-judge) oraz heurystyki/reguły oparte o dopasowanie tekstu lub strukturę cytowań. Wybór zależy od wymagań audytu, kosztu i odporności na „grywalność” metryki.

LLM-as-judge: praktyczny schemat oceny

Typowy, lekki schemat (bez wchodzenia w pełny design systemu ocen) wygląda tak:

• Wejście: pytanie, odpowiedź modelu, kontekst (top-k fragmentów), opcjonalnie: instrukcja systemowa i format cytowań.
• Krok 1: ekstrakcja claimów (np. 3–10 krótkich twierdzeń) albo ocena zdań wprost.
• Krok 2: dla każdego claimu sędzia wskazuje: Supported / Not supported / Contradicted oraz (opcjonalnie) fragmenty kontekstu, które wspierają claim.
• Krok 3: agregacja do jednego wyniku (np. odsetek claimów „Supported”, z karą za „Contradicted”).

Ważne: groundedness to nie „czy odpowiedź brzmi sensownie”, tylko „czy da się ją obronić na podstawie kontekstu”. Dlatego w promptach sędziego warto wyraźnie zakazać korzystania z wiedzy zewnętrznej i premiować wskazywanie dowodów w kontekście.

System: Oceń ugruntowanie odpowiedzi wyłącznie na podstawie podanego KONTEKSTU.
Nie używaj wiedzy zewnętrznej.

Zadanie:
1) Wypisz kluczowe twierdzenia (claims) z ODPOWIEDZI.
2) Dla każdego claimu zwróć etykietę: SUPPORTED / NOT_SUPPORTED / CONTRADICTED.
3) Jeśli SUPPORTED, wskaż cytowany fragment kontekstu (krótki cytat).
4) Zwróć score groundedness = (#SUPPORTED) / (#claims).

Wejście:
PYTANIE: ...
KONTEKST: ...
ODPOWIEDŹ: ...

Podejścia regułowe: co da się zmierzyć „bez sędziego”

Reguły zwykle nie „rozumieją” odpowiedzi tak jak model, ale mogą wymuszać zachowania sprzyjające groundedness:

• Wymóg cytowań: odpowiedź musi zawierać odnośniki do fragmentów (np. identyfikatory chunków). Brak cytatu obniża wynik lub blokuje publikację.
• Pokrycie cytowaniami: jaki procent zdań/claimów ma przypisane źródło.
• Spójność z cytatem: proste podobieństwo semantyczne między zdaniem a cytowanym fragmentem; ewentualnie klasyfikacja entailment (NLI) jako dodatkowa warstwa.
• Detektory ryzyka: liczby, daty, „twarde fakty” bez źródeł (np. występują w odpowiedzi, ale nie w kontekście) jako sygnał nieugruntowania.

Reguły dobrze działają jako guardrails, ale często wymagają normalizacji odpowiedzi (format, cytowania) i są wrażliwe na styl pisania.

Typowe ryzyka i „fałszywe dobre wyniki”

• Parafraza vs dosłowność: metody oparte o overlap mogą zaniżać groundedness przy poprawnej parafrazie; z kolei LLM-sędzia może zawyżać, jeśli „domyśla się” pokrycia.
• Cherry-picking kontekstu: odpowiedź cytuje fragment, który jest tematycznie bliski, ale nie wspiera konkretnego twierdzenia (pozorne ugruntowanie).
• Konflikt źródeł: w kontekście są sprzeczne fragmenty; model wybiera jeden bez sygnalizacji niepewności. Groundedness może wyjść wysokie, a ryzyko merytoryczne pozostaje.
• Nadmierna ogólność: model unika konkretnych faktów („zależy”, „zwykle”) — groundedness rośnie, ale użyteczność spada. Dlatego groundedness warto interpretować razem z metrykami trafności/kompletności.
• Grywalność: jeśli metryka premiuje cytaty, model może „zalewać” odpowiedź cytowaniami bez realnego powiązania. Jeśli premiuje podobieństwo, może kopiować kontekst zamiast odpowiadać.
• Wrażliwość na skład kontekstu: zmiana chunkingu, kolejności fragmentów, lub obecność nieistotnych dokumentów może zmieniać ocenę sędziego.

Walidacja groundedness: jak upewnić się, że metryka mierzy to, co trzeba

Żeby groundedness była użyteczna operacyjnie, trzeba ją skalibrować i sprawdzić, czy koreluje z realnymi błędami, które chcesz łapać.

• Zestaw referencyjny: przygotuj próbkę odpowiedzi z ręczną oceną (przynajmniej binarną: ugruntowana/nieugruntowana) i porównaj z automatycznym score.
• Testy negatywne: wstrzyknij kontrolowane halucynacje (np. podmiana liczby, dopisanie nieistniejącej polityki, błędna data) i sprawdź, czy metryka to wykrywa.
• Powtarzalność: dla LLM-as-judge sprawdź stabilność wyników (ten sam przykład oceniony wielokrotnie). Jeśli rozrzut jest duży, wynik trudniej użyć do trendów i alertów.
• Ocena per segment: osobno dla typów pytań (faktyczne vs proceduralne), długości kontekstu, domeny dokumentów. Groundedness często „psuje się” tylko w wybranych segmentach.
• Progi i koszty błędu: ustaw progi nie „na oko”, tylko pod ryzyko biznesowe (co gorsze: przepuścić nieugruntowaną odpowiedź czy zbyt często odmawiać?).

Dobrze zaprojektowana metryka groundedness nie zastępuje innych miar, ale pełni rolę bezpiecznika: wykrywa sytuacje, w których generacja przestaje być wierna dostarczonym źródłom — nawet wtedy, gdy retrieval wygląda „dobrze” na papierze.

6. Jak zbudować jeden dashboard RAG: metryki retrieval + generacji, segmentacja, trendy i korelacje

Dashboard RAG ma sens tylko wtedy, gdy łączy dwie perspektywy, które w praktyce często „rozjeżdżają się” diagnostycznie: retrieval (czy system dostarczył właściwe źródła) oraz generację (czy odpowiedź jest poprawna i oparta na źródłach). W klasycznym IR wystarcza zwykle ranking dokumentów; w RAG nawet idealny ranking nie gwarantuje dobrej odpowiedzi (np. z powodu złej syntezy), a dobra odpowiedź może powstać mimo niedoskonałego retrievalu (np. dzięki „szczęściu” w top-k).

6.1. Zasada projektowa: jedna oś czasu, dwa „lejki” jakości

Najczytelniejszy układ to dwa równoległe lejki, spięte wspólnymi wymiarami segmentacji (kolekcja, typ zapytania, język, wersja indeksu, wersja promptu/modelu):

• Retrieval funnel: metryki rankingu i pokrycia (np. recall@k, MRR, nDCG) + sygnały operacyjne (latencja, liczba trafionych źródeł, długość kontekstu).
• Generation funnel: metryki jakości odpowiedzi (np. „answer groundedness”, zgodność ze źródłami, kompletność) + sygnały ryzyka (odsetek odpowiedzi bez cytowań, sprzeczności, odmowy/„I don’t know”).

Klucz: oba lejki muszą być raportowane dla tych samych prób (ten sam zestaw zapytań i warunki), aby korelacje były interpretowalne.

6.2. Minimalny zestaw paneli (MVP), który realnie pomaga diagnozować

6.3. Segmentacja: bez niej dashboard jest „średnią, która nic nie mówi”

W RAG średnie globalne są mylące, bo system zwykle ma kilka trybów pracy: krótkie pytania faktograficzne, długie pytania proceduralne, zapytania wieloetapowe, zapytania wielojęzyczne. W dashboardzie warto mieć stałe filtry (i domyślne widoki per segment):

• Typ zapytania: fakt/definicja vs procedura vs porównanie vs „multi-hop”.
• Trudność: łatwe (jedno źródło) vs trudne (wiele źródeł, rozproszone fakty).
• Język: osobne widoki, bo tokenizacja, embeddingi i indeks często zachowują się inaczej.
• Domena/kolekcja: np. polityki, dokumentacja techniczna, regulaminy—różne rozkłady długości i stylu.
• „Freshness”: zapytania o treści nowe vs archiwalne (wrażliwe na aktualizacje indeksu).
• Tryb odpowiedzi: z cytowaniami vs bez, krótka vs długa odpowiedź (wpływa na groundedness i koszt).

Praktyczna wskazówka: segmenty powinny być stabilne w czasie (ta sama definicja etykiet), inaczej trendy stają się nieporównywalne.

6.4. Trendy i wykrywanie regresji: metryki + „guardraile”

Dashboard RAG powinien działać jak monitoring jakości: pokazywać trend i alarmy, a nie tylko tabelę wyników z jednego testu. Typowe elementy:

• Wykresy czasowe dla kluczowych metryk (retrieval i generacja) z oznaczeniem wdrożeń (release markers).
• Progi akceptacji (guardrails): np. groundedness nie może spaść poniżej ustalonego poziomu, nawet jeśli recall@k rośnie.
• Rozkłady i percentyle, nie tylko średnia: regresja często objawia się „ogonem” (wzrostem liczby bardzo złych przypadków).
• Kontrola próbki: stały „golden set” + rotująca próbka z produkcji (aby wykrywać drift).

6.5. Korelacje: jak połączyć retrieval i generację bez błędnych wniosków

Największa wartość dashboardu RAG to odpowiedź na pytanie: czy poprawa retrievalu przekłada się na lepszą odpowiedź? Do tego potrzebujesz widoków, które łączą metryki na poziomie pojedynczego zapytania:

• Scatter plot: recall@k (lub nDCG) vs groundedness; szybko widać „kwadranty” porażek.
• Tabela kwadrantów diagnostycznych: wysoki retrieval/niska groundedness (problem generacji), niski retrieval/wysoka groundedness (podejrzenie „zgadywania”), niski/niski (problem end-to-end), wysoki/wysoki (idealnie).
• Analiza per segment: korelacje globalne mogą maskować fakt, że dla jednego typu pytań retrieval jest wąskim gardłem, a dla innego prompt.

Ważne: korelacja nie oznacza przyczynowości. Dlatego dashboard powinien wspierać drill-down do przykładów (konkretne zapytanie, top-k źródła, odpowiedź, cytaty), żeby potwierdzić hipotezę jakościową.

6.6. Drill-down: od metryki do przypadku

Każdy widok agregatów powinien mieć możliwość przejścia do danych na poziomie pojedynczego zapytania. Minimalny „rekord” do debugowania:

• zapytanie + ewentualne parametry (filtry, język, tryb odpowiedzi),
• top-k źródeł (ID, tytuł/ścieżka),
• fragmenty kontekstu faktycznie podane do modelu (po przycięciu),
• odpowiedź modelu,
• oceny: retrieval (np. etykiety relewancji) i generacja (np. groundedness),
• metryki kosztowe i czasy.

6.7. Szkielet danych pod dashboard (praktyczne minimum)

Żeby dashboard był spójny, warto ustandaryzować schemat logów dla jednego „runu” RAG. Poniżej minimalny przykład pól, które umożliwiają metryki, segmentację, trendy i drill-down:

{
  "timestamp": "2026-03-26T12:34:56Z",
  "query_id": "...",
  "query_text": "...",
  "segment": {
    "query_type": "fact|procedure|multi-hop|...",
    "language": "pl",
    "collection": "...",
    "difficulty": "easy|hard"
  },
  "version": {
    "index": "vX",
    "embedder": "...",
    "reranker": "...",
    "prompt": "vY",
    "generator_model": "..."
  },
  "retrieval": {
    "k": 10,
    "candidates": [
      {"doc_id": "...", "rank": 1, "score": 0.87},
      {"doc_id": "...", "rank": 2, "score": 0.83}
    ],
    "latency_ms": 120
  },
  "context": {
    "tokens_in": 2800,
    "snippets": [{"doc_id": "...", "text": "..."}]
  },
  "generation": {
    "answer": "...",
    "tokens_out": 220,
    "latency_ms": 900
  },
  "labels_and_scores": {
    "retrieval_labels": {"relevant_doc_ids": ["..."]},
    "groundedness": 0.78
  }
}

Taki schemat ułatwia: (1) liczenie metryk offline, (2) porównania wersji, (3) budowę wykresów trendu, (4) drill-down do przypadków, (5) korelacje retrieval↔generacja bez zgadywania, czy dane są porównywalne.

7. Struktura raportu RAG: przykładowy szablon, checklisty diagnostyczne i interpretacja wyników

Dobry raport RAG nie jest „zbiorem wykresów”, tylko narzędziem decyzyjnym: ma szybko odpowiedzieć, czy problem leży w retrieval, w generacji, w danych, czy w samych testach. Ponieważ RAG łączy wyszukiwanie z generowaniem, raport powinien konsekwentnie rozdzielać te warstwy, a jednocześnie pokazywać ich zależności (np. sytuacje, gdy retrieval wygląda dobrze, ale odpowiedzi nadal są nieuziemione w źródłach).

Proponowany szablon raportu (sekcje, które warto mieć zawsze)

• Cel i kontekst użycia: do czego system służy, jaki typ zapytań obsługuje (fakty, procedury, porównania), jaki jest akceptowalny kompromis między pokryciem a precyzją oraz jakie są wymagania dot. cytowań/źródeł.
• Zakres ewaluacji i definicje: wersje komponentów (indeks, embeddingi, retriever, reranker, LLM, prompt), okno czasowe danych, zasady annotacji relewancji, definicja „poprawnej odpowiedzi” oraz co oznacza „źródło” (fragment, dokument, URL, rekord).
• Opis zbioru testowego: liczebność, miks tematów, poziom trudności, rozkład typów pytań, udział pytań bez odpowiedzi w korpusie, ryzyko przecieku danych (np. pytania z dokumentacji, która była w treningu modelu).
• Wyniki retrieval (mierniki rankingu i pokrycia): metryki oparte o trafienie relewantnych fragmentów w top-k oraz jakość rankingu; dodatkowo sygnały operacyjne (np. odsetek pustych wyników, duplikaty, długości chunków). Celem jest odpowiedź: „czy właściwe źródła w ogóle trafiają do kontekstu?”.
• Wyniki generacji: miary związane z poprawnością, zgodnością ze źródłami i formatem (np. czy model cytuje, czy odpowiada na pytanie, czy nie wymyśla). Celem jest odpowiedź: „czy model umie wykorzystać dostarczone źródła i nie ucieka poza nie?”.
• Łańcuch przyczynowo-skutkowy: zestawienie metryk retrieval i generacji w jednym miejscu, tak aby było widać, kiedy degradacja wynika z wyszukiwania, a kiedy z generacji lub instrukcji.
• Analiza segmentów: wyniki rozbite na kategorie, które mają sens produktowo (temat, język, długość pytania, typ intentu, świeżość dokumentów, obecność tabel/plików PDF, użytkownicy wewnętrzni vs zewnętrzni). Segmenty często ujawniają regresje, których nie widać w średniej.
• Trend i regresje: porównanie do poprzedniego wydania (baseline), zaznaczenie zmian w danych i konfiguracji oraz identyfikacja metryk, które „poruszają się razem” (lub przestały się poruszać razem).
• Przegląd błędów (qualitative): kilkanaście reprezentatywnych przykładów z krótką diagnozą „co poszło nie tak” (retrieval/generacja/dane/etykiety) oraz potencjalnym działaniem naprawczym.
• Rekomendacje i decyzje: jasno zapisane wnioski, priorytety, ryzyka oraz kryteria „go/no-go” dla wdrożenia.

Checklisty diagnostyczne (szybkie „triage” problemów)

Poniższe listy pomagają szybko zaklasyfikować źródło problemu bez wchodzenia w szczegóły implementacyjne.

A. Gdy wyniki retrieval spadają

• Czy zmienił się korpus (nowe dokumenty, usunięcia, duplikaty, spadek jakości OCR/PDF)?
• Czy zmieniła się segmentacja (chunking), a przez to „rozmyła się” relewancja fragmentów?
• Czy pojawiły się zapytania poza domeną lub pytania „bez odpowiedzi w danych” i czy są oznaczone jako takie?
• Czy obserwujesz wzrost pustych wyników albo powtarzających się fragmentów w top-k?
• Czy spadek dotyczy wszystkich segmentów, czy tylko wybranych (np. świeże treści, długi ogon tematów)?

B. Gdy retrieval wygląda dobrze, ale jakość odpowiedzi jest słaba

• Czy model odpowiada w oparciu o kontekst, czy „dopowiada” spoza źródeł?
• Czy kontekst jest zbyt długi/zaszumiony i model nie potrafi wybrać właściwych fragmentów?
• Czy wymagany format odpowiedzi jest jasny (np. cytowania, kroki, ograniczenie do źródeł)?
• Czy odpowiedzi psują się głównie na pytaniach wieloetapowych lub wymagających syntezy?
• Czy błędy dotyczą zgodności z politykami (np. odmowa, wrażliwe treści), a nie merytoryki?

C. Gdy metryki „nie zgadzają się” z obserwacją użytkowników

• Czy zbiór testowy odzwierciedla realny ruch (tematy, język, długość, intencje)?
• Czy etykiety relewancji i kryteria oceny są spójne między annotatorami i stabilne w czasie?
• Czy raport pokazuje rozkłady i segmenty, czy tylko średnie (średnia często maskuje problemy)?
• Czy użytkownicy oceniają „użyteczność” (czas, forma, pewność), a metryki mierzą tylko „trafność”?
• Czy widoczny jest wpływ zmian w UI (np. ekspozycja źródeł) na percepcję jakości?

D. Gdy system jest „zbyt pewny siebie”

• Czy raport rozróżnia błędy: brak odpowiedzi w danych vs halucynacja przy dostępnych źródłach?
• Czy istnieje mechanizm rozpoznawania niepewności (np. odmowa, prośba o doprecyzowanie)?
• Czy odpowiedzi mają ślad dowodowy (cytowania) i czy użytkownik może go zweryfikować?

Jak interpretować wyniki: proste wzorce i co z nich wynika

• Niskie metryki retrieval + niska jakość odpowiedzi: najczęściej problem „u podstaw” (dane, indeks, zapytania, segmentacja). Priorytetem jest przywrócenie pokrycia właściwymi źródłami, zanim dostraja się generację.
• Wysokie metryki retrieval + niska zgodność odpowiedzi ze źródłami: problem po stronie generacji/instrukcji lub „szumu” w kontekście. W raporcie warto wtedy pokazać, czy model konsekwentnie cytuje właściwe fragmenty i czy nie miesza dokumentów.
• Wysokie metryki retrieval + poprawne, ale nieużyteczne odpowiedzi: zwykle kłopot z formatem, zbyt ogólnym stylem, brakiem syntezy albo niedopasowaniem do potrzeb użytkownika. To sygnał, że sama trafność źródeł nie wystarcza jako KPI.
• Metryki stabilne, ale rośnie liczba skarg: możliwy drift w realnych zapytaniach, zmiana oczekiwań użytkowników lub luka w zbiorze testowym. Raport powinien wymusić aktualizację testów i segmentów, zanim uzna się to za „subiektywne”.
• Poprawa retrieval bez poprawy odpowiedzi: potencjalnie osiągnięto „sufit” na retrieval i dalsze zyski wymagają pracy nad generacją albo nad sposobem podawania kontekstu (selekcja, kompresja, priorytetyzacja).

Minimalny zestaw artefaktów, które raport powinien zostawić po sobie

• Jasne kryteria akceptacji: które metryki muszą rosnąć, które nie mogą spaść i jakie są progi bezpieczeństwa.
• Lista top problemów z przypisaniem do warstwy (retrieval/generacja/dane/ocena) oraz właścicielem działania.
• Zestaw „kanonicznych” przykładów (good/bad/edge cases), które będą używane do ręcznej weryfikacji w kolejnych iteracjach.
• Notatka o ograniczeniach ewaluacji: czego nie mierzymy, gdzie są luki w danych testowych i jakie są największe ryzyka błędnej interpretacji.

8. Rekomendowane progi alarmowe i playbook reakcji: alerty, priorytety, eksperymenty naprawcze

Same wartości metryk niewiele znaczą bez progów alarmowych i ustalonej reakcji operacyjnej. W RAG błędy powstają w łańcuchu (retrieval → selekcja kontekstu → generacja), więc alertowanie powinno rozróżniać: spadek zdolności odnajdywania dowodów, spadek jakości rankingu oraz utrzymanie poprawnej odpowiedzi mimo poprawnego retrievalu. Progi niżej traktuj jako punkt startowy; docelowo stabilizuje się je na bazie własnej historii wyników, sezonowości i segmentów zapytań.

Progi alarmowe: jak je ustawiać, żeby nie hałasowały

• Nie ustawiaj progów absolutnych „z internetu” jako jedynych. Najlepiej działają progi oparte o odchylenie od własnej bazy: alarm, gdy metryka spada poniżej ustalonego percentyla lub o określoną liczbę odchyleń standardowych względem 7–28 dni.
• Oddziel progi dla segmentów. Inne oczekiwania będą dla zapytań na „świeże” dane, innych języków, długich pytań, zapytań z numerami/ID, czy pytań wymagających cytowania źródeł.
• Ustal minimalny wolumen. Alerty z małej próbki są mylące. Jeżeli dzienne N jest małe, agreguj tygodniowo albo używaj progów opartych o ufność/wiarygodność.
• Alarmuj na metryki i na ich rozjazdy. W RAG ważne są anomalia typu: retrieval wygląda dobrze, a groundedness spada — to zwykle oznacza problem po stronie generacji lub formatu kontekstu.

Rekomendowane „starter progi” (do kalibracji)

• Recall@k (retrieval coverage): ostrzeżenie przy spadku o 3–5 p.p. względem mediany z ostatnich 14 dni; krytyczny alarm przy spadku o 8–10 p.p. lub gwałtownym trendzie spadkowym utrzymującym się kilka okien pomiarowych.
• MRR / MRR@k (pierwszy trafny wynik): ostrzeżenie przy spadku o 5–10% względem baseline; krytyczny alarm przy spadku o 15–20%. MRR jest wrażliwe na „przetasowania” top1/top3, więc dobrze sprawdza się jako wczesny sygnał problemów z rankingiem.
• nDCG@k (jakość rankingu z wagami): ostrzeżenie przy spadku o 3–7% względem baseline; krytyczny alarm przy spadku o 10–15%. Jeśli masz wielopoziomowe etykiety relewancji, nDCG często wykrywa degradacje wcześniej niż recall.
• Answer groundedness (uziemienie odpowiedzi w kontekście): ostrzeżenie przy spadku o 5–10% względem baseline; krytyczny alarm przy spadku o 15% lub przy nagłym wzroście odpowiedzi „bez cytowalnego wsparcia” w kontekście. Warto też ustawić próg na odsetek przypadków „brak dowodu” oraz na częstość sprzeczności z kontekstem.
• Alert na rozjazd metryk: krytyczny, gdy recall/nDCG są stabilne, a groundedness istotnie spada (typowo problem generacji, promptu, formatu kontekstu, limitów tokenów, instrukcji bezpieczeństwa); oraz gdy groundedness stabilne, a recall spada (typowo problem indeksu, chunkingu, filtrów lub query rewrite).

P1/P2/P3: priorytety incydentów i co sprawdzać najpierw

• P1 (krytyczny): gwałtowny spadek metryk w wielu segmentach lub jednoczesny spadek recall/nDCG i groundedness; skok w odpowiedziach „halucynacyjnych” lub brakujących źródeł; istotny wpływ na kluczowe ścieżki biznesowe. Reakcja: natychmiastowe ograniczenie ryzyka (np. zaostrzenie odpowiedzi „nie wiem”, wymuszenie cytowań, obniżenie kreatywności), szybka diagnostyka retrieval i generacji równolegle.
• P2 (ważny): degradacja w konkretnym segmencie (np. jedna kolekcja dokumentów, jeden język, jeden typ zapytania) albo stopniowy trend spadkowy. Reakcja: analiza zmian w danych, indeksie i konfiguracji; eksperyment naprawczy w trybie A/B lub shadow.
• P3 (monitoring): drobne wahania w granicach typowej zmienności; pojedyncze segmenty o małym wolumenie. Reakcja: obserwacja, doprecyzowanie segmentacji, korekta progów lub jakości etykiet.

Playbook reakcji: szybka diagnoza „gdzie pękło”

Najskuteczniejszy playbook zaczyna od rozróżnienia dwóch sytuacji: brak dowodu (retrieval/ranking) vs złe użycie dowodu (generacja/groundedness). Każda z nich ma inne działania naprawcze.

• Jeśli spada recall@k (a MRR/nDCG też często spadają):
  • Sprawdź zmiany w źródłach: nowe dokumenty, usunięcia, duplikaty, błędy parsowania, nagłe skrócenie treści.
  • Zweryfikuj indeks i pipeline: opóźnienia w indeksacji, błędy w embedowaniu, zmiana modelu embedów, wersji tokenizera, parametrów ANN.
  • Skontroluj chunking: zbyt małe/duże fragmenty, utrata nagłówków, brak metadanych, zła normalizacja.
  • Przejrzyj filtry: zawężenia po metadanych, uprawnienia, język, „freshness”, które mogą usuwać trafne źródła.
• Jeśli recall@k jest stabilny, ale spada MRR/nDCG:
  • Sprawdź ranking: zmiany w rerankerze, wagach cech, normalizacji score’ów, progu odcięcia.
  • Oceń dystrybucję wyników: czy rośnie liczba „prawie remisów” w topk (model ma trudność z rozróżnieniem)?
  • Zweryfikuj query rewrite/rozszerzanie zapytań: czy nie dodaje szumu lub nie zmienia intencji.
• Jeśli retrieval jest stabilny, a spada answer groundedness:
  • Sprawdź budowę kontekstu: czy kontekst nie jest ucinany (limity tokenów), czy kolejność fragmentów jest sensowna, czy nie zniknęły nagłówki/źródła.
  • Zweryfikuj prompt/instrukcje: czy nie zachęcają do dopowiadania, czy wymuszają cytowanie i ograniczają „wiedzę ogólną” poza kontekstem.
  • Sprawdź parametry generacji: wyższa losowość zwykle obniża groundedness; zmiany modelu mogą zwiększać skłonność do konfabulacji.
  • Oceń „odmowę odpowiedzi”: czasem groundedness spada, bo system odpowiada mimo braku dowodów zamiast powiedzieć „nie wiem”.
• Jeśli groundedness rośnie, ale metryki retrieval spadają:
  • To może oznaczać nadmierną ostrożność (częstsze „brak informacji”), co poprawia uziemienie kosztem użyteczności. Sprawdź balans: odsetek odpowiedzi niekompletnych, satysfakcję użytkownika, czas do rozwiązania.

Eksperymenty naprawcze: szybkie „dźwignie” poprawy

• Retrieval: ponowna indeksacja krytycznych kolekcji; korekta chunkingu; dodanie pól do embedowania (np. tytuł + sekcja); odszumianie duplikatów; dostrojenie filtrów; wprowadzenie hybrydy (słowa kluczowe + wektory) jeśli zapytania są „identyfikatorowe”.
• Ranking: włączenie lub strojenie rerankera; zwiększenie k; zmiana strategii łączenia score’ów; osobne rankery per typ zapytania; ograniczenie agresywnego query expansion.
• Kontekst: poprawa selekcji fragmentów (mniej, ale bardziej trafnie); lepsze układanie kolejności; dodanie jawnych cytowań/źródeł; usunięcie fragmentów „prawniczych” lub boilerplate’u, które wypychają istotną treść.
• Generacja i uziemienie: twardsze instrukcje „odpowiadaj tylko na podstawie kontekstu”; format odpowiedzi z cytatami; reguły blokujące twierdzenia bez pokrycia; obniżenie losowości; fallback do ekstrakcyjnej odpowiedzi w segmentach wysokiego ryzyka.
• Ewaluacja: doprecyzowanie etykiet relewancji; walidacja judge’a; rozdzielenie zbiorów testowych na „łatwe” i „trudne”; testy regresji na stałym zestawie kontrolnym.

Alerty, które warto mieć od razu

• Trend degradacji: 3 kolejne okna pomiarowe poniżej baseline dla recall@k lub nDCG.
• Skok halucynacji: wzrost odsetka odpowiedzi nieuziemionych powyżej progu krytycznego (albo powyżej górnego percentyla historii).
• Rozjazd retrieval–generacja: stabilny recall@k przy spadku groundedness (lub odwrotnie) jako osobny typ incydentu.
• Segment krytyczny: osobne alerty dla zapytań o wysokim ryzyku (np. prawne/medyczne/finansowe) nawet przy małym wolumenie, ale z ostrożniejszą interpretacją.

Dobrze ustawione progi i playbook skracają czas od wykrycia do naprawy: zamiast „metryki spadły”, dostajesz sygnał jaki komponent najpewniej zawiódł i jakie eksperymenty mają największą szansę szybko podnieść jakość bez wprowadzania nowych regresji.

W Cognity łączymy teorię z praktyką – dlatego ten temat rozwijamy także w formie ćwiczeń na szkoleniach.

Narzędzia do dokumentacji technicznej – FrameMaker vs nowoczesne platformy docs 12 kwietnia 2026

Analiza tekstu z ankiet w R: sentiment, tematy i wizualizacje, które działają w raporcie 10 kwietnia 2026