Testy regresji dla RAG: jak wykrywać, że nowy indeks albo model pogorszył odpowiedzi

1. Dlaczego testy regresji są kluczowe w systemach RAG i gdzie najczęściej pojawia się degradacja

Systemy RAG (Retrieval-Augmented Generation) łączą dwa światy: wyszukiwanie (dobór fragmentów wiedzy) i generowanie (złożenie z nich odpowiedzi). To sprawia, że jakość końcowa nie zależy od jednego modelu ani jednej metryki, tylko od całego łańcucha decyzji: co zostało znalezione, w jakiej kolejności, w jakim kontekście przekazane do modelu i jak model to zinterpretował. W praktyce oznacza to, że nawet „niewielka” zmiana techniczna może wywołać nieoczywistą degradację odpowiedzi.

Testy regresji są kluczowe, bo w RAG degradacja często nie ma postaci spektakularnej awarii. System zwykle nadal zwraca płynne, poprawnie brzmiące odpowiedzi, ale pogarsza się ich trafność, kompletność albo oparcie o źródła. Bez testów regresji taki spadek jakości bywa wykrywany dopiero przez użytkowników, gdy koszty (błędne decyzje, utrata zaufania, eskalacje do supportu) są już realne.

Regresja w RAG jest też trudna do zauważenia „na oko”, ponieważ:

• Język jest z natury zmienny – odpowiedzi mogą brzmieć inaczej, mimo że są równie dobre lub gorsze.
• Błędy są selektywne – zmiana może zaszkodzić tylko części zapytań (np. długim, wieloznacznym, domenowym), a reszta pozostaje bez zmian.
• Łańcuch ma wiele punktów wrażliwych – drobna różnica w doborze kontekstu potrafi całkowicie zmienić wniosek modelu.

W przeciwieństwie do klasycznych systemów wyszukiwania, gdzie rezultat jest listą dokumentów, w RAG „wynikiem” jest odpowiedź. To przesuwa ryzyko: można mieć wyszukiwanie, które pozornie działa (zwraca jakieś dokumenty), ale generacja tworzy odpowiedź niezgodną z intencją pytania, nadinterpretowaną lub niepopartą źródłami. Z kolei model generujący może być bardzo dobry, ale jeśli kontekst jest nietrafiony, odpowiedź stanie się przekonującą halucynacją.

Najczęstsze miejsca, w których pojawia się degradacja jakości po zmianach, to:

• Spadek trafności kontekstu – system zaczyna dobierać fragmenty mniej związane z pytaniem, co skutkuje odpowiedziami „obok tematu” lub z brakującymi kluczowymi faktami.
• Utrata pokrycia – wcześniej system znajdował właściwy fragment w wiedzy, a po zmianie już go nie znajduje (np. przez zmianę segmentacji treści lub sposobu indeksowania).
• Więcej odpowiedzi nieugruntowanych w źródłach – model częściej dopowiada szczegóły, których nie ma w dostarczonym kontekście, bo kontekst jest zbyt ogólny, niekompletny lub mylący.
• Zmiana zachowania w zapytaniach granicznych – pytania wieloznaczne, z negacją, z wymaganiem warunków („jeśli… to…”) lub z ograniczeniami czasowymi częściej „rozjeżdżają się” po aktualizacji.
• Niestabilność formatowania i tonacji – odpowiedź nadal bywa merytorycznie poprawna, ale przestaje spełniać wymagania produktu (np. brak kroków, brak cytowań, zbyt długie odpowiedzi), co użytkownik odbiera jako spadek jakości.
• Pogorszenie spójności wieloturnowej – w dialogu system częściej gubi kontekst rozmowy, miesza referencje lub nie utrzymuje ustaleń z poprzednich wypowiedzi.

W efekcie testy regresji w RAG pełnią podwójną rolę: chronią jakość (żeby aktualizacja nie pogorszyła odpowiedzi) oraz chronią zaufanie (żeby system nie stawał się mniej przewidywalny). Dobrze zaprojektowane testy regresji nie muszą od razu rozstrzygać „dlaczego” coś się pogorszyło — ich celem jest możliwie wcześnie wykryć, że ryzyko jakościowe wzrosło, zanim zmiana trafi szeroko do użytkowników.

Co może się zepsuć po zmianie: indeks, embeddingi, retriever/reranker, prompt i model generujący

W systemie RAG odpowiedź jest wynikiem łańcucha: indeks → wyszukiwanie → (opcjonalnie) reranking → budowa kontekstu → generowanie. Zmiana w dowolnym ogniwie może poprawić jeden aspekt (np. trafność), a równocześnie pogorszyć inny (np. kompletność, spójność, cytowanie źródeł). Dlatego regresje często są „ciche”: system nadal działa, ale odpowiada subtelnie gorzej w części zapytań. Podczas szkoleń Cognity ten temat wraca regularnie – dlatego zdecydowaliśmy się go omówić również tutaj.

Indeks: gdy „to samo” źródło staje się innym zbiorem do wyszukiwania

Indeks to nie tylko magazyn dokumentów, ale też efekt decyzji o tym co i jak jest indeksowane. Regresje po zmianie indeksu zwykle biorą się z przesunięcia pokrycia treści lub z pogorszenia dopasowania fragmentów do zapytań.

• Inne dzielenie na fragmenty (chunking): zbyt duże fragmenty rozmywają sygnał, zbyt małe gubią kontekst i wymagają złożenia wielu źródeł.
• Zmiana czyszczenia/normalizacji: usunięte nagłówki, listy, tabele czy znaki specjalne mogą pozbawić indeks kluczowych informacji lub utrudnić dopasowanie.
• Utrata lub zmiana metadanych: filtry po dacie, wersji, języku czy typie dokumentu przestają działać, co prowadzi do mieszania nieaktualnych lub niepożądanych źródeł.
• Inna polityka aktualizacji: opóźnienia, częściowe reindeksowanie albo duplikaty skutkują niekonsekwencją („czasem odpowiada dobrze, czasem na starej wersji”).
• Zmiana typu indeksu (np. inne ustawienia wyszukiwania wektorowego/tekstowego lub hybrydowego): wpływa na to, jakie dokumenty w ogóle mają szansę trafić do kontekstu.

Embeddingi: przesunięcie przestrzeni semantycznej

Embeddingi determinują, co uznajemy za „podobne” semantycznie. Aktualizacja modelu embeddingów albo sposobu ich liczenia często nie psuje systemu wprost, ale zmienia ranking wyników w sposób trudny do zauważenia bez testów.

• Niezgodność wersji: nowe embeddingi dokumentów przy starych embeddingach zapytań (lub odwrotnie) obniżają trafność, bo odległości w przestrzeni przestają być porównywalne.
• Inny język i domena: model lepiej rozumie ogólny język, ale gorzej radzi sobie ze skrótami, kodami produktów, terminologią branżową lub nazwami własnymi.
• Inne ustawienia preprocesingu: zmiana tokenizacji, usuwania znaków, lowercasingu czy obsługi liczb może wpłynąć na zapytania „technicznym” charakterze.
• Zmiana wymiaru/normalizacji: wpływa na zachowanie wyszukiwarki (np. sposób liczenia podobieństwa), co może przetasować top-k.

Retriever: co trafia do top-k i z jaką stabilnością

Retriever odpowiada za wybór kandydatów do kontekstu. Nawet drobne zmiany w parametrach mogą zmienić wyniki dla długiego ogona zapytań. Typowe regresje to spadek kompletności, większa zmienność wyników i gorsze dopasowanie do intencji użytkownika.

• Zbyt agresywne filtrowanie: poprawia precyzję w części przypadków, ale obniża recall, bo usuwa potrzebne dokumenty (np. przez błędny filtr języka lub daty).
• Zmiana liczby pobieranych wyników: mniejsze k ogranicza pokrycie, większe k zwiększa szum i ryzyko, że generator „złapie” złą informację.
• Inne zapytanie do wyszukiwarki: modyfikacje typu query rewriting/expansion mogą pomagać na pytaniach ogólnych, a szkodzić na precyzyjnych.
• Hybryda wektor + BM25: zmiana wag lub logiki łączenia może faworyzować słowa kluczowe kosztem znaczenia (lub odwrotnie).

Reranker: poprawa precyzji kosztem pokrycia i czasu

Reranker przestawia kolejność kandydatów, zwykle celując w lepszą precyzję na szczycie listy. Regresje pojawiają się, gdy model rerankujący preferuje „ładnie brzmiące” fragmenty zamiast tych naprawdę odpowiadających na pytanie, albo gdy jest wrażliwy na format i długość tekstu.

• Zmiana modelu rerankera: może przesunąć uwagę na inne sygnały (np. styl, nagłówki), przez co kluczowe źródła spadają poza kontekst.
• Inna liczba kandydatów do rerankingu: za mało kandydatów ogranicza pole wyboru, za dużo zwiększa ryzyko błędnej selekcji i koszty.
• Budżet latencji: przy optymalizacjach czasu często obcina się reranking lub stosuje przybliżenia, co pogarsza jakość w nieoczywisty sposób.

Prompt i budowa kontekstu: „jak” podajemy źródła modelowi

Nawet przy identycznych dokumentach końcowy rezultat zależy od tego, jak kontekst jest sklejany i jak instruujemy model. Zmiany promptu potrafią wywołać regresje w tonie, strukturze, a przede wszystkim w stopniu oparcia odpowiedzi na źródłach.

• Inny format kontekstu: kolejność fragmentów, separatory, nagłówki i cytowania wpływają na to, co model uzna za ważne.
• Zbyt duża kompresja: streszczanie lub skracanie fragmentów może usuwać detale potrzebne do poprawnej odpowiedzi.
• Zmiana instrukcji: mocniejsze wymaganie zwięzłości może obciąć istotne zastrzeżenia; mocniejsze wymaganie „pewności” może zwiększyć halucynacje, jeśli model zacznie dopowiadać.
• Zmiana zasad cytowania: jeśli prompt słabiej wymusza odniesienia do źródeł, odpowiedzi mogą wyglądać dobrze, ale być mniej weryfikowalne.

Model generujący: styl, posłuszeństwo i odporność na szum

Wymiana modelu LLM (lub jego parametrów inferencji) często zmienia „osobowość” odpowiedzi: może być bardziej elokwentna, ale mniej precyzyjna; bardziej kreatywna, ale mniej ugruntowana. To źródło regresji szczególnie wtedy, gdy jakość retrievalu bywa zmienna i model musi radzić sobie z niepełnym lub częściowo sprzecznym kontekstem.

• Inna skłonność do halucynacji: niektóre modele chętniej wypełniają luki, zamiast przyznać „nie wiem”.
• Inne priorytety instrukcji: model może gorzej trzymać się zasad (np. odpowiadać bez cytatów, ignorować ograniczenia domenowe).
• Wrażliwość na długość kontekstu: model może gorzej wykorzystywać dalsze fragmenty lub gubić kluczowe informacje w długim promptcie.
• Parametry generacji: zmiany temperatury, top-p czy limitów długości wpływają na deterministyczność, kompletność i ryzyko „dopowiadania”.

Najtrudniejsze regresje to te, które nie wyglądają jak awaria: system nadal odpowiada płynnie, lecz częściej wybiera nie te źródła, gubi kluczowy szczegół albo pewnie formułuje wnioski mimo słabego kontekstu. Właśnie dlatego warto rozdzielać ocenę na poziomy (retrieval/reranking vs generacja) i śledzić, w którym miejscu łańcucha pojawia się pogorszenie.

3. Projektowanie zestawów testowych: golden set, przypadki brzegowe, wersjonowanie i reprezentatywność danych

Testy regresji w RAG są tak dobre, jak dane, na których je uruchamiasz. Dobrze zaprojektowany zestaw testowy powinien jednocześnie: (1) odzwierciedlać realne użycie (reprezentatywność), (2) mieć stabilne, kontrolowane oczekiwania (golden set), (3) celować w miejsca typowych awarii (przypadki brzegowe) oraz (4) być zarządzany jak artefakt produktu (wersjonowanie i śledzenie zmian).

Golden set: stabilny punkt odniesienia

Golden set to kuratorowany zestaw zapytań (i oczekiwań), który ma służyć jako „kotwica” do porównań między wersjami. Jego celem nie jest pokrycie całego świata, tylko dostarczenie powtarzalnego sygnału jakości dla kluczowych scenariuszy.

• Co zawiera: zapytania od użytkowników (lub ich zanonimizowane/parafrazowane warianty), minimalny kontekst (np. segment użytkownika, język), oraz oczekiwania w formie: docelowych źródeł, kryteriów poprawności, dozwolonych wariantów odpowiedzi.
• Jak dobierać: priorytet dla zapytań wysokiej wartości biznesowej, najczęstszych intencji oraz tematów wrażliwych (np. polityki, regulaminy, procedury).
• Jak opisywać oczekiwania: zamiast „jednej poprawnej odpowiedzi” częściej lepiej sprawdza się opis w kategoriach: musi zawierać, nie może twierdzić, musi oprzeć się na źródłach X. Zmniejsza to kruchość testów przy drobnych zmianach językowych.

Przypadki brzegowe: testy odporności na typowe pułapki

Przypadki brzegowe są uzupełnieniem golden setu: celowo „naciągają” system w miejscach, gdzie RAG zwykle degraduje. Ich rolą jest szybkie wykrywanie klas błędów, które w średnich metrykach potrafią się ukryć.

• Niejednoznaczność i kontekst: krótkie zapytania („Jak to działa?”), zapytania wymagające doprecyzowania, zapytania zależne od wcześniejszej rozmowy.
• Konflikt w dokumentach: dwie wersje polityki/procedury, nieaktualne FAQ kontra nowa instrukcja, źródła o różnej wiarygodności.
• Długi ogon: rzadkie terminy, skróty branżowe, literówki, mieszanie języków, odmiany fleksyjne.
• Zapychanie kontekstu: zapytania, które prowokują do przytoczenia dużych fragmentów; sprawdzają, czy system zachowuje istotne informacje i nie „gubi” źródeł.
• Negacje i zakazy: „czego nie wolno”, „kiedy nie stosować”, wyjątki od reguły.
• Wymuszenie cytowań/źródeł: pytania, w których brak solidnego źródła powinien skutkować odmową lub prośbą o doprecyzowanie.

Reprezentatywność danych: żeby testy mierzyły to, co ważne

Najczęstszy błąd to budowa zestawu testowego, który jest „ładny”, ale niereprezentatywny. Reprezentatywność oznacza, że rozkład tematów, typów zapytań i warunków użycia przypomina rzeczywistość.

• Start od logów: jeśli masz historię zapytań, próbkuj ją warstwowo (np. per intencja/temat/język) zamiast wybierać ręcznie wyłącznie „najciekawsze” pytania.
• Pokrycie segmentów: różni użytkownicy pytają inaczej (rola, region, poziom wiedzy). Zadbaj o minimalne pokrycie segmentów, nawet jeśli to kilka przypadków na segment.
• Balans częste vs. krytyczne: częste pytania stabilizują metryki, a krytyczne (choć rzadkie) chronią przed kosztownymi regresjami. W praktyce warto utrzymywać oba koszyki.
• Jakość źródeł w korpusie: testy powinny uwzględniać realny stan dokumentacji (duplikaty, PDF-y, skany OCR, strony z tabelami). Inaczej regresja może ujawnić się dopiero po wdrożeniu.

Wersjonowanie: test set jako artefakt produktu

Zestawy testowe w RAG muszą być wersjonowane, bo zmienia się zarówno produkt, jak i wiedza w źródłach. Bez wersjonowania nie odróżnisz regresji systemu od zmiany „prawdy” w dokumentach.

• Co wersjonować: same zapytania, oczekiwania (np. listę akceptowalnych źródeł), oraz metadane (segment, język, kategoria ryzyka, priorytet).
• Ślad pochodzenia: dla każdego przypadku warto przechowywać: skąd pochodzi (log/zgłoszenie), kiedy dodany, dlaczego jest ważny (np. incident, krytyczna funkcja).
• Zmiany kontrolowane: dopuszczaj modyfikacje golden setu, ale zapisuj je jako zmiany semantyczne (np. „zaktualizowano oczekiwane źródło z powodu nowej wersji dokumentu”).
• Stabilność vs. aktualność: utrzymuj rdzeń stabilnych przypadków (porównywalność w czasie) oraz część rotacyjną (odświeżaną okresowo, by testy nie „zestarzały się”).

Struktura pojedynczego testu: minimalny, ale użyteczny kontrakt

Aby testy były porównywalne i łatwe do utrzymania, każdy przypadek powinien mieć zwięzły „kontrakt”. Przykładowy minimalny schemat:

• query: treść zapytania
• context: metadane (np. język, segment, kanał)
• expectations: wymagane źródła lub kryteria odpowiedzi
• tags: kategoria tematu, ryzyko, typ (golden/edge)

{
  "id": "policy_refunds_001",
  "query": "Kiedy przysługuje zwrot kosztów?",
  "context": {"lang": "pl", "segment": "customer"},
  "expectations": {
    "must_reference": ["/polityka-zwrotow"],
    "must_include": ["termin", "warunki"],
    "must_not_claim": ["zwrot zawsze" ]
  },
  "tags": ["golden", "high_value", "policy"]
}

Podział ról: golden set vs. edge set

Warto rozdzielić zestawy, bo służą innym celom i mają inne wymagania stabilności.

Dobre praktyki utrzymania zestawu

• Kuracja zamiast masy: lepiej mieć mniejszy, dobrze opisany zestaw niż ogromny, którego nikt nie rozumie i nie aktualizuje.
• Tagowanie i filtrowanie: tagi pozwalają uruchamiać testy selektywnie (np. tylko „high_risk” lub tylko dany temat) i szybciej diagnozować regresje.
• Unikanie „uczenia się na teście”: jeśli często ręcznie dopasowujesz system do przypadków testowych, rotuj część zapytań i trzymaj osobny, ukryty zestaw walidacyjny.
• Higiena danych: usuwaj duplikaty, dbaj o spójność językową i o to, by zapytania nie zawierały wprost fragmentów odpowiedzi z dokumentów.

4. Metryki i sygnały jakości: recall@k, MRR/nDCG, groundedness/faithfulness, cytowania źródeł i metryki odpowiedzi

W RAG nie ma jednej „metryki prawdy”, bo jakość powstaje na styku wyszukiwania i generowania. Dlatego testy regresji powinny śledzić sygnały z kilku warstw: (1) czy właściwe dokumenty w ogóle trafiają do kontekstu, (2) czy system potrafi je ustawić w dobrej kolejności, (3) czy odpowiedź jest ugruntowana w źródłach, oraz (4) czy odpowiedź spełnia wymagania produktu (poprawność, kompletność, format, styl). W czasie szkoleń Cognity ten temat bardzo często budzi ożywione dyskusje między uczestnikami, bo łatwo pomylić „dobre wyszukiwanie” z „dobrą odpowiedzią” i przeoczyć regresję w jednej z warstw.

4.1. Metryki retrievalu: recall@k

recall@k odpowiada na proste pytanie: „Czy wśród top-k zwróconych fragmentów jest coś, co faktycznie zawiera informację potrzebną do odpowiedzi?”. To metryka zasięgu retrievera — ignoruje kolejność i skupia się na tym, czy „trafiliśmy w ogóle”.

• Kiedy używać: przy ocenie zmian w indeksie, embeddingach i retrieverze.
• Co wykrywa: nagłe „zgubienie” kluczowych źródeł (np. po przebudowie indeksu) lub spadek dopasowania semantycznego.
• Ograniczenia: wysoki recall@k nie gwarantuje dobrej odpowiedzi, jeśli trafne źródło jest bardzo nisko w rankingu albo kontekst jest „zaśmiecony”.

4.2. Metryki rankingu: MRR i nDCG

Gdy kontekst ma limit tokenów, znaczenie ma nie tylko czy trafny fragment jest w top-k, ale jak wysoko. Do tego służą metryki rankingowe.

• MRR (Mean Reciprocal Rank): nagradza sytuację, w której pierwszy trafny wynik pojawia się wysoko (im wyżej, tym lepiej). Dobra, gdy liczy się szybkie dotarcie do jednego właściwego źródła.
• nDCG: uwzględnia wiele poziomów trafności (np. „idealny”, „wystarczający”, „słaby”) i bierze pod uwagę pozycję w rankingu. Jest użyteczna, gdy istnieje kilka przydatnych fragmentów i każdy wnosi inną wartość.

W praktyce: recall@k mówi, czy system „dowiózł” potrzebne źródła, a MRR/nDCG czy dowiózł je na czas i w dobrej kolejności.

4.3. Groundedness/faithfulness: czy odpowiedź trzyma się kontekstu

W RAG ryzyko regresji często objawia się tym, że model zaczyna dopowiadać lub mieszać fakty, mimo że kontekst jest poprawny. Dlatego warto mierzyć ugruntowanie odpowiedzi w dostarczonych źródłach.

• Groundedness: na ile twierdzenia w odpowiedzi mają pokrycie w dostarczonych dokumentach.
• Faithfulness: na ile odpowiedź jest wierna kontekstowi (bez „halucynacji”, przekształceń sensu, błędnych uogólnień).

To metryki „między-warstwowe”: potrafią wskazać degradację, której nie widać w recall@k/MRR (np. ten sam kontekst, ale model generujący zaczyna wprowadzać błędy). Często są liczone poprzez automatyczną weryfikację twierdzeń (np. ekstrakcję zdań/claimów i sprawdzanie, czy da się je uzasadnić cytatem z kontekstu) albo ocenę LLM-as-judge z jasno opisanymi kryteriami.

4.4. Cytowania źródeł: pokrycie, precyzja i spójność odwołań

Jeśli system ma zwracać odpowiedź z odnośnikami do dokumentów, jakość cytowań staje się osobnym sygnałem. Regresja może polegać nie na samej treści, lecz na tym, że cytaty znikają, wskazują złe miejsca albo nie odpowiadają konkretnym twierdzeniom.

• Coverage (pokrycie cytowaniami): jaki odsetek kluczowych twierdzeń ma przypisane źródło.
• Precision cytowań: czy cytowany fragment rzeczywiście uzasadnia zdanie, do którego jest przypięty.
• Spójność: czy odwołania są stabilne (np. ten sam typ pytania nie zaczyna wskazywać losowych dokumentów) i czy nie ma „martwych” linków po zmianie indeksu.

To szczególnie przydatne w systemach, gdzie odpowiedź ma pełnić rolę „asystenta z przypisami” i gdzie łatwo o regresję po zmianach w chunkingu, mapowaniu identyfikatorów dokumentów albo promptach formatujących wynik.

4.5. Metryki odpowiedzi: jakość końcowa z perspektywy użytkownika

Nawet idealny retrieval nie gwarantuje, że odpowiedź będzie użyteczna. Dlatego warto mierzyć cechy odpowiedzi jako produktu końcowego. Zwykle są to metryki oparte o ocenę regułową, porównanie do wzorca (gdy istnieje) lub ocenę automatyczną wg rubryki.

• Correctness (poprawność): czy odpowiedź jest merytorycznie poprawna.
• Completeness (kompletność): czy obejmuje wszystkie wymagane elementy (np. kroki procedury, warunki, wyjątki).
• Relevance (trafność): czy odpowiada na pytanie bez dygresji i „przepisywania” kontekstu.
• Format compliance: czy spełnia wymagania formatu (np. JSON, lista punktów, język, długość, zakaz pewnych treści).
• Helpfulness/clarity (użyteczność i jasność): czy jest zrozumiała i prowadzi do rozwiązania problemu.

4.6. Szybka mapa: które metryki do czego

Najlepsze pokrycie regresji daje zestaw metryk komplementarnych: retrieval (recall@k), ranking (MRR/nDCG), ugruntowanie (groundedness/faithfulness) oraz miary jakości odpowiedzi i cytowań. W testach regresji ważne jest, by te sygnały rozdzielały „problem z danymi i wyszukiwaniem” od „problemu z generowaniem”, bo naprawa zwykle leży w innej warstwie.

# Pseudokod: szkic liczenia recall@k z etykietami relewantnych dokumentów
# inputs: results[q] = lista doc_id w kolejności; gold[q] = zbiór relewantnych doc_id

recall_at_k = mean([
  1 if len(set(results[q][:k]) & gold[q]) > 0 else 0
  for q in queries
])

5. Progi i tolerancje regresji: budżety błędu, przedziały ufności, testy statystyczne i analiza segmentowa

W systemach RAG rzadko da się utrzymać identyczną jakość po zmianie indeksu lub modelu. Dlatego zamiast oczekiwać „braku zmian”, ustala się progi regresji (kiedy wdrożenie blokujemy) oraz tolerancje (kiedy dopuszczamy niewielkie wahania). Kluczowe jest, by progi były mierzalne, powtarzalne i rozdzielały: (1) wahania losowe, (2) zmianę istotną dla użytkownika.

Budżety błędu: ile pogorszenia jest akceptowalne

Budżet błędu to „limit pogorszenia”, jaki akceptujesz na określonych metrykach lub segmentach. Najczęściej definiuje się go jako:

• globalny limit (np. średnia metryka nie może spaść poniżej X),
• limit dla krytycznych przypadków (np. dla pytań wymagających cytowania nie wolno tracić więcej niż Y),
• limit dla ogona rozkładu (np. liczba „złych” odpowiedzi nie może wzrosnąć o więcej niż Z%).

W RAG warto rozdzielić budżety na co najmniej dwie kategorie: retrieval (czy właściwe fragmenty w ogóle trafiły do kontekstu) oraz generation (czy odpowiedź jest wierna źródłom i kompletna). To pozwala uniknąć sytuacji, w której jedna metryka „przykrywa” regresję w innej.

Przedziały ufności: odróżnij regresję od szumu

Nawet przy stałym zestawie testowym wyniki mogą się wahać (np. przez losowość generacji lub drobne zmiany rankingu). Zamiast porównywać „średnia vs średnia”, warto oceniać przedział ufności dla różnicy między wersjami. Praktyczna zasada:

• Jeśli przedział ufności różnicy w całości leży poniżej zera (dla metryki „im wyżej tym lepiej”) i przekracza ustalony budżet — to regresja.
• Jeśli obejmuje zero — wynik jest niejednoznaczny i może wymagać większej próby lub stabilizacji pomiaru.

W RAG szczególnie ważne jest to przy metrykach odpowiedzi liczonych przez model oceniający (LLM-as-judge), gdzie dochodzi dodatkowy wariant oceny.

Testy statystyczne: kiedy „zmiana” jest istotna

Test statystyczny pomaga odpowiedzieć, czy obserwowana różnica to przypadek. W praktyce, bez wchodzenia w detale implementacyjne, warto rozróżnić:

• Testy na danych sparowanych — gdy porównujesz te same pytania w dwóch wersjach systemu (to standard w regresji RAG).
• Testy nieparametryczne — gdy rozkład metryki jest „dziwny” (częste dla metryk per-query, np. 0/1 albo skokowych).
• Bootstrap — gdy chcesz uzyskać stabilne oszacowanie niepewności bez założeń o rozkładzie.

Najczęstszy błąd to traktowanie „p-wartości” jako jedynego kryterium. W regresji jakości liczy się istotność praktyczna: nawet statystycznie istotna różnica może być zbyt mała, by miała znaczenie dla użytkownika, i odwrotnie — duża degradacja na małej próbce może nie przejść testu, ale nadal powinna blokować release.

Analiza segmentowa: globalnie lepiej, lokalnie gorzej

Średnia globalna potrafi maskować problemy. RAG jest szczególnie podatny na regresje „wyspowe”: nowy indeks poprawia popularne zapytania, ale psuje długie ogony lub specyficzne typy dokumentów. Dlatego progi warto definiować także per segment.

Typowe segmenty, które ujawniają regresje:

• Typ intencji: definicje vs procedury krok-po-kroku vs porównania.
• Złożoność zapytania: krótkie vs wieloetapowe, z warunkami.
• Świeżość źródeł: nowe dokumenty vs archiwalne.
• Język i styl: zapytania formalne vs potoczne.
• Wymóg cytowań: pytania, gdzie brak źródeł jest krytyczny.
• Długość kontekstu: przypadki, gdzie retriever zwraca dużo szumu.

Praktyka: utrzymuj osobne progi dla segmentów „krytycznych” (np. compliance, instrukcje operacyjne), a dla pozostałych dopuszczaj większą tolerancję. Segmenty powinny być stabilne w czasie (żeby porównania między wersjami miały sens).

Jak spisać progi w sposób operacyjny

Najprościej opisać progi jako zestaw reguł typu „must/should”. Poniżej minimalistyczny schemat (do dopasowania do własnych metryk):

• MUST: brak przekroczenia budżetu na metrykach krytycznych (globalnie i w segmentach krytycznych).
• SHOULD: brak istotnej statystycznie degradacji na metrykach pomocniczych; jeśli jest, wymagane uzasadnienie.
• INVESTIGATE: wynik niejednoznaczny (przedział ufności obejmuje 0) — nie blokuje automatycznie, ale wymusza analizę.

// Pseudokonfiguracja progów (przykład formy, nie narzędzie)
thresholds:
  must:
    - metric: groundedness
      delta_min: -0.01
      segments: ["all", "citations_required"]
    - metric: recall_at_10
      delta_min: -0.02
      segments: ["all"]
  should:
    - metric: answer_completeness
      delta_min: -0.01
      segments: ["all"]
  investigate:
    - condition: "ci_overlaps_zero"
      action: "manual_review"

Taki zapis ułatwia rozmowę w zespole: co jest „blokujące”, co jest „do akceptacji”, a co „wymaga zrozumienia”, zanim zmiana trafi dalej.

6. Automatyzacja w CI/CD: pipeline testowy, testy offline/online, monitoring po wdrożeniu i alerting

W systemach RAG „jakość odpowiedzi” zależy od kilku współdziałających komponentów (indeks, retrieval, generowanie), a zmiana w jednym miejscu często daje efekt uboczny w innym. Dlatego testy regresji powinny być zautomatyzowane i wykonywane zawsze przy zmianie artefaktów RAG (np. nowy indeks, nowy model, zmiana promptu), zamiast być ręcznym krokiem przed releasem. Celem CI/CD nie jest tu wyłącznie wykrycie błędu, ale też szybka odpowiedź na pytanie: co się pogorszyło, gdzie i dla jakiego typu zapytań.

Pipeline testowy: co automatyzować i gdzie wpiąć

Minimalny pipeline dla RAG powinien rozdzielać testy na warstwy, aby szybciej lokalizować źródło regresji i nie blokować rozwoju zbyt kosztownymi przebiegami.

• Smoke/contract tests (szybkie): uruchamiane przy każdym PR — poprawność schematów danych, dostępność indeksu, kompatybilność wersji embeddingów, limity czasu, podstawowe przypadki „czy w ogóle działa”.
• Testy offline jakości (średnio-kosztowne): uruchamiane na głównej gałęzi lub przed mergem przy zmianach wpływających na retrieval/generację — porównanie metryk na ustalonym zestawie zapytań oraz raport różnic.
• Testy wydajności i stabilności: latencja p50/p95, obciążenie, koszt tokenów, limity pamięci, błędy sieciowe — ważne, bo przeciążenia i time-outy wprost psują jakość (np. ucinanie kontekstu).
• Gating release: decyzja „blokuj/nie blokuj” oparta o progi regresji oraz sygnały ryzyka (np. spadki w krytycznych kategoriach pytań).

Offline vs online: różnice, zastosowania i kiedy które wybrać

Testy offline wykrywają regresje szybciej i taniej, ale nie obejmują wszystkich efektów rzeczywistego ruchu (dystrybucja zapytań, zachowania użytkowników, czasem też różnice infrastrukturalne). Testy online są bliżej prawdy produkcyjnej, ale wymagają ostrożności i obserwowalności.

Jak zorganizować automatyczne porównania: baseline, artefakty i powtarzalność

W CI/CD kluczowa jest możliwość porównania „przed vs po” na tych samych wejściach. W praktyce oznacza to:

• Trzymanie baseline (np. poprzednia wersja indeksu/modelu) i odtwarzalny „runner” testów, który potrafi uruchomić oba warianty w identycznej konfiguracji.
• Wersjonowanie artefaktów (indeksy, konfiguracje retrievera, prompty) oraz jednoznaczne metadane w raporcie: commit, wersja modelu, timestamp, region.
• Powtarzalność: tam gdzie to możliwe, stałe ziarna losowości i kontrola parametrów, aby odróżnić fluktuacje od realnej regresji.

Raport z pipeline powinien być zrozumiały dla zespołu: nie tylko „fail/pass”, ale też krótka lista największych spadków oraz grupy zapytań, których dotyczy problem (np. po domenie, języku, długości pytania).

Monitoring po wdrożeniu: co obserwować, aby szybko wykryć degradację

Po wdrożeniu regresje często ujawniają się jako zjawiska operacyjne (np. time-outy, ograniczenia kontekstu, błędy dostępu do indeksu), które finalnie materializują się w gorszych odpowiedziach. Monitoring powinien łączyć sygnały jakości z telemetrią systemową.

• Sygnały jakościowe: oceny użytkowników (jeśli są), współczynniki ponownych zapytań/„rephrase”, eskalacje do człowieka, ręczne flagi „niepoprawne/bez źródeł”.
• Sygnały retrieval: odsetek odpowiedzi bez kontekstu, liczba znalezionych dokumentów, częstość „pustych” wyników, odsetek fallbacków.
• Sygnały generacji: długość odpowiedzi, ucięcia przez limity, błędy narzędzi, częstotliwość odmów, odsetek odpowiedzi bez cytowań (jeśli wymagane).
• Sygnały operacyjne: latencja p95/p99, error rate (4xx/5xx), time-outy, saturacja zasobów, kolejki, retry.

Dobrą praktyką jest monitorowanie osobno dla krytycznych segmentów ruchu (np. zapytania w danym języku, kluczowe produkty/obszary), bo degradacja często dotyczy tylko części przypadków.

Alerting: jak ustawić powiadomienia, żeby nie generować szumu

Alerty w RAG powinny być warstwowe: inne dla awarii (twarde błędy), inne dla spadków jakości (miękkie sygnały). Aby uniknąć „alert fatigue”, warto:

• Ustawić progi i okna czasowe (np. pogorszenie utrzymujące się przez N minut, a nie pojedynczy pik).
• Rozdzielić alerty na krytyczne (np. brak dostępu do indeksu, masowe time-outy) i obserwacyjne (np. stopniowy wzrost rephrase rate).
• Łączyć sygnały: alert jakościowy powinien być silniejszy, gdy równolegle pogarsza się retrieval lub latencja.
• Dołączać do alertu kontekst diagnostyczny: wersja wdrożenia, region, odsetek ruchu, najbardziej dotknięte segmenty.

Przykładowy szkic w CI: uruchomienie testów offline i publikacja raportu

# Pseudokod: krok w pipeline
# 1) Uruchom testy dla baseline i candidate
run_eval --rag-config baseline.yaml  --suite regression.json --out baseline.json
run_eval --rag-config candidate.yaml  --suite regression.json --out candidate.json

# 2) Porównaj i wygeneruj raport
compare_eval --base baseline.json --cand candidate.json --out report.html --fail-on-regression

# 3) Opublikuj artefakty (raport + logi) jako wynik joba
publish_artifact report.html

Kod jest drugorzędny — istotne jest, by pipeline zawsze produkował porównywalne wyniki i zostawiał ślad audytowy, który pozwala szybko zrozumieć, dlaczego zmiana została zablokowana albo dopuszczona.

7. Przykładowy proces release dla RAG: eksperymenty, canary, rollout oraz zasady „stop-the-line” i procedura rollbacku

W systemach RAG wdrożenie nowego indeksu lub modelu to nie tylko „wrzucenie wersji na produkcję”. Zmiana często dotyka wielu elementów naraz (retrieval, generowanie, cytowania), a degradacja bywa cicha: odpowiedzi nadal brzmią poprawnie, ale są mniej trafne, gorzej ugruntowane w źródłach albo mniej kompletne. Dlatego proces release powinien zakładać etapowanie ryzyka, jasne kryteria zatrzymania oraz szybki, przewidywalny rollback.

Etap 1: eksperymenty i walidacja przedprodukcyjna

Najpierw warto potraktować zmianę jako eksperyment z hipotezą: „nowy indeks zwiększy trafność w zapytaniach X” albo „nowy model poprawi zwięzłość bez utraty zgodności ze źródłami”. Na tym etapie celem nie jest jeszcze pełna automatyzacja, tylko szybkie wyłapanie oczywistych regresji oraz doprecyzowanie, jakiego rodzaju poprawy oczekujemy.

• Porównanie wersji A/B offline na stałym zestawie pytań i dokumentów: nowa wersja powinna być oceniona nie tylko „ogólnie”, ale też w najważniejszych scenariuszach biznesowych.
• Ocena segmentowa: osobno dla typów zapytań (np. krótkie vs. złożone), domen (obszary wiedzy) i poziomów trudności. W RAG regresja często ukrywa się w konkretnym segmencie.
• „Red team” przypadków ryzykownych: zapytania, gdzie łatwo o halucynację lub błędne uogólnienie, oraz takie, które wymagają poprawnych cytowań źródeł.

Efektem powinien być werdykt „przechodzi/nie przechodzi” oraz lista znanych ograniczeń. Jeśli wynik jest niejednoznaczny, to sygnał, że brakuje kryteriów jakości albo że zmiana jest zbyt szeroka i wymaga rozbicia na mniejsze kroki.

Etap 2: canary na ruchu produkcyjnym

Canary polega na wypuszczeniu nowej wersji do małego odsetka ruchu (lub wybranej grupy użytkowników) przy zachowaniu starej wersji jako punktu odniesienia. To krytyczne w RAG, bo jakość może zależeć od „prawdziwego” rozkładu zapytań, aktualnych dokumentów i zachowań użytkowników.

• Kontrolowane kierowanie ruchu: stała alokacja użytkownika do wersji (aby uniknąć mieszania doświadczeń i uprościć interpretację sygnałów).
• Ścisły monitoring nie tylko błędów technicznych, ale też symptomów jakościowych, takich jak spadek użycia cytowanych źródeł, częstsze odpowiedzi „nie wiem” albo wzrost eskalacji do wsparcia.
• Bezpieczniki funkcjonalne: ograniczenie wpływu zmian poprzez limity (np. maksymalna liczba tokenów, czas odpowiedzi, fallback do poprzedniej wersji przy anomaliach).

Ważna różnica względem klasycznego canary dla API: w RAG nawet drobny spadek jakości może nie powodować błędów w logach, ale realnie szkodzić użytkownikom. Dlatego canary powinien mieć zdefiniowane „twarde” warunki stopu oparte o obserwowalne sygnały jakości i ryzyka.

Etap 3: rollout stopniowy

Jeśli canary jest stabilny, wdrożenie przechodzi w rollout etapowy: zwiększanie udziału nowej wersji (np. 10% → 25% → 50% → 100%) z pauzami na ocenę. Celem jest ograniczenie promienia rażenia i danie czasu na wychwycenie degradacji, która ujawnia się dopiero po większej skali (np. przy większej różnorodności zapytań albo obciążeniu).

• Stopniowe zwiększanie udziału z wyraźnymi checkpointami: po każdym kroku weryfikacja jakości i stabilności.
• Kontrola kosztów: nowe modele lub rerankery mogą zwiększać koszty; rollout powinien uwzględniać budżet i limity.
• Spójność wersji komponentów: w RAG mieszanie wersji (np. nowy retriever ze starym promptem) bywa źródłem nieprzewidywalnych zachowań; rollout powinien jasno definiować, co jest „pakietem” wersji.

Zasada „stop-the-line”: kiedy zatrzymać wdrożenie

„Stop-the-line” oznacza, że każdy członek zespołu ma prawo i obowiązek zatrzymać rollout, gdy widzi sygnał ryzyka. W RAG szczególnie ważne jest zdefiniowanie kryteriów natychmiastowego stopu, bo degradacja może dotyczyć rzetelności informacji.

• Ryzyko merytoryczne: wzrost niezgodności ze źródłami, częstsze odpowiedzi bez oparcia w dokumentach, błędne cytowania.
• Ryzyko bezpieczeństwa i zgodności: pojawienie się treści niepożądanych, wycieki wrażliwych informacji lub omijanie polityk.
• Ryzyko operacyjne: skok latencji, błędy integracji, niestabilność przy obciążeniu lub gwałtowny wzrost kosztów.
• Ryzyko produktu: spadek kluczowych sygnałów użytkowych (np. wzrost porzuceń, spadek satysfakcji, wzrost eskalacji) w krytycznych segmentach.

Kluczowe jest, aby „stop-the-line” nie był uznaniowy: powinien mieć proste reguły decyzyjne, właściciela decyzji eskalacyjnej oraz kanał komunikacji, który zatrzymuje wdrożenie bez zwłoki.

Rollback: szybki powrót do znanej dobrej wersji

Rollback w RAG powinien być traktowany jako normalna część procesu, a nie porażka. Najważniejsze są czas reakcji i deterministyczność: zespół musi wiedzieć, do czego wraca i co dokładnie się zmienia.

• Rollback wersji end-to-end: powrót całego „pakietu” (indeks, retriever/reranker, prompt, model) do poprzednio zatwierdzonej konfiguracji, aby uniknąć półśrodków.
• Rollback selektywny: w niektórych sytuacjach sensowne jest cofnięcie tylko jednego elementu (np. indeksu) przy zachowaniu reszty, o ile zespół ma pewność, że zależności są zrozumiałe.
• Powrót do stabilnego indeksu: jeśli nowy indeks jest problemem, ważna jest możliwość szybkiego przełączenia na poprzednią wersję bez długiej reindeksacji.
• Procedura po rollbacku: zebranie artefaktów (logi, przykłady degradacji, segmenty dotknięte problemem) i zapis wniosków tak, aby kolejna próba była krótsza i bezpieczniejsza.

Dobrze zaprojektowany release dla RAG minimalizuje ryzyko poprzez etapowanie (eksperymenty → canary → rollout), a jednocześnie zakłada, że regresje mogą się zdarzyć. Zasady „stop-the-line” i szybki rollback sprawiają, że nawet jeśli nowa wersja pogorszy odpowiedzi, wpływ na użytkowników jest ograniczony, a zespół może wrócić do stabilnego stanu bez chaosu.

8. Przykładowy dashboard: kluczowe wykresy, alerty i workflow reagowania na incydenty

Dashboard dla testów regresji w RAG ma jedno zadanie: jak najszybciej pokazać, że jakość odpowiedzi spadła oraz gdzie i dlaczego to się stało. W praktyce łączy perspektywę wyszukiwania (retrieval), generowania (LLM) i warstwy danych (indeks/źródła), aby dało się odróżnić incydent produktowy od naturalnej zmienności ruchu czy zmian w treściach.

Warto zaprojektować dashboard w logice trzech poziomów: sygnały objawów (co się psuje), sygnały diagnostyczne (w której warstwie) oraz sygnały operacyjne (czy problem się pogłębia i kogo dotyczy).

Kluczowe wykresy: „objawy” widoczne dla użytkownika

• Trend jakości odpowiedzi w czasie (na poziomie całego systemu i na segmentach): odsetek odpowiedzi ocenionych jako pomocne/niepomocne, udział odpowiedzi z odmową, liczba eskalacji do człowieka lub ponowień zapytania. To najszybciej wskazuje, czy regresja jest realna z perspektywy użytkowników.
• Stabilność stylu i zgodności: skoki w długości odpowiedzi, nagły wzrost „nie wiem” albo przeciwnie: wzrost odpowiedzi pewnych siebie bez oparcia w źródłach. Przydatne, gdy zmiana w prompt/modelu psuje zachowanie mimo podobnego retrievalu.
• Udział odpowiedzi z cytowaniami (jeśli produkt wspiera źródła): spadek pokrycia cytowaniami często sygnalizuje problem w łańcuchu RAG (np. brak kontekstu, błędna selekcja dokumentów, zbyt agresywne skracanie kontekstu).

Kluczowe wykresy: „diagnostyka” warstwy retrieval i indeksu

• Pokrycie trafnych dokumentów w top-k (lub proxy pokrycia): czy system nadal znajduje te same typy materiałów co wcześniej. Spadki zwykle sugerują regresję w embeddingach, indeksie lub parametrach retrievera.
• Rozkład podobieństw i marginesów pomiędzy najlepszymi wynikami: gdy top-1 przestaje wyraźnie wygrywać nad resztą, reranking i generowanie dostają gorszy sygnał. To bywa sygnałem „rozmycia” embeddingów albo zmiany dystrybucji danych.
• „Empty/low-context rate”: odsetek zapytań, dla których zwrócono zbyt mało kontekstu lub kontekst o zbyt niskiej jakości (np. krótkie, powtarzalne fragmenty). To szybki wskaźnik awarii indeksu, filtrów, uprawnień lub pipeline’u ekstrakcji.
• Freshness i kompletność indeksu: wskaźniki opóźnienia aktualizacji oraz liczby dokumentów/fragmentów w indeksie. Skoki w dół często oznaczają problem w zasilaniu danymi, a nie w samym modelu.

Kluczowe wykresy: „diagnostyka” generowania i ugruntowania

• Groundedness/faithfulness proxy: trend odsetka odpowiedzi, które nie znajdują oparcia w dostarczonym kontekście (np. na podstawie automatycznych heurystyk lub ocen). Jeżeli retrieval jest stabilny, a ten wskaźnik rośnie, winny bywa prompt lub model.
• Coverage kontekstu w odpowiedzi: czy odpowiedź wykorzystuje kluczowe informacje z dostarczonych fragmentów. Spadek sugeruje zbyt agresywny prompt, zmianę temperatury/parametrów lub problem z formatem kontekstu.
• Rate błędów bezpieczeństwa i zgodności: wzrost odpowiedzi niezgodnych z politykami (np. ujawnienia danych wrażliwych, niepożądane instrukcje) może pojawić się po zmianie modelu lub promptu i wymaga osobnych progów alarmowych.

Segmentacja: jak szybko zawęzić „gdzie boli”

Najbardziej użyteczny dashboard pozwala przełączać się pomiędzy segmentami bez przebudowy analiz. Minimalny zestaw segmentów to: typ zapytania (faktograficzne vs proceduralne), domena tematyczna, język, źródło danych (kolekcja/namespace), poziom uprawnień, kanał (web/API), oraz wersja konfiguracji (indeks, embedding, retriever, prompt, model). Dzięki temu widać, czy regresja dotyczy całego systemu, czy tylko wąskiej części danych lub ruchu.

Alerty: co alarmować i jak ograniczać fałszywe alarmy

• Alerty na spadek jakości użytkowej: gdy metryki satysfakcji/eskalacji przekraczają ustalony próg lub wykazują nagły trend w dół. To alerty priorytetowe, bo wskazują realny wpływ na użytkownika.
• Alerty na degradację retrieval: wzrost zapytań bez sensownego kontekstu, spadek pokrycia trafnych dokumentów lub zmiany w rozkładach podobieństw. Cenne jako wczesne ostrzeganie przed spadkiem jakości odpowiedzi.
• Alerty na ugruntowanie i cytowania: nagły wzrost odpowiedzi bez oparcia w źródłach albo spadek cytowań. Pomaga wychwycić regresje promptu/modelu nawet wtedy, gdy retrieval wygląda „normalnie”.
• Alerty operacyjne: błędy pipeline’u indeksowania, wzrost latencji, time-outy, limity kontekstu. Często to one są prawdziwą przyczyną pozornych „regresji jakości”.

Dobre alerty są krótkie, jednoznaczne i mówią: co się pogorszyło, od kiedy, w jakim segmencie i jaka była ostatnia zmiana (wersja indeksu/modelu/promptu). To skraca czas od wykrycia do decyzji.

Workflow reagowania na incydenty: od sygnału do naprawy

• Triaging: potwierdzenie, czy sygnał jest rzeczywisty (czy dotyczy użytkowników, czy tylko testów), oraz ocena zasięgu (globalnie czy segmentowo).
• Lokalizacja przyczyny: szybkie rozdzielenie na problem z danymi/indeksem, retrieval/rerankingiem, czy generowaniem. W praktyce pomaga porównanie „objawów” z warstwami diagnostycznymi: jeśli retrieval spada, zaczyna się od indeksu; jeśli retrieval stabilny, a rośnie brak ugruntowania, podejrzenie pada na prompt/model.
• Decyzja operacyjna: czy zatrzymać wdrożenie, przełączyć ruch na poprzednią wersję, czy zastosować obejście (np. mniejsze top-k, inne filtry, ograniczenie do wybranej kolekcji).
• Weryfikacja naprawy: po zmianie należy obserwować, czy metryki wracają do normy w tych samych segmentach, w których wystąpił problem, oraz czy nie pojawiają się efekty uboczne (np. poprawa groundedness kosztem odmów).
• Post-incident: zapisanie, które wskaźniki zadziałały, a które zawiodły (np. brak alertu na konkretny segment), i doprecyzowanie dashboardu/alertów, by skracać czas reakcji następnym razem.

Najważniejsza zasada projektowa: dashboard ma służyć podejmowaniu decyzji, nie tylko obserwacji. Jeśli po alarmie nie da się w ciągu kilku minut odpowiedzieć na pytania „czy to wpływa na użytkowników?” i „w której warstwie jest problem?”, to znaczy, że brakuje kluczowych wykresów, segmentów albo powiązania metryk z wersjami zmian.

Jeśli chcesz poznać więcej takich przykładów, zapraszamy na szkolenia Cognity, gdzie rozwijamy ten temat w praktyce.

Jak projektować ankiety, żeby dało się je analizować: skale, bias i struktura pytań 06 kwietnia 2026

Analiza kohortowa bez narzędzi BI: jak zbudować ją w R i zwizualizować sensownie 04 kwietnia 2026