Ewaluacja LLM (evals) — jak mierzyć jakość aplikacji AI metodą LLM-as-a-judge

Ewaluacja LLM (evals) to systematyczny pomiar jakości odpowiedzi aplikacji AI na zestawie reprezentatywnych przykładów — odpowiednik testów automatycznych, ale dla wyjść, które nie mają jednej poprawnej odpowiedzi. Najskuteczniejszą metodą w 2026 jest LLM-as-a-judge: drugi model językowy ocenia odpowiedzi Twojej aplikacji według zdefiniowanej rubryki, zgadzając się z oceną człowieka w ~85% przypadków (czyli częściej, niż dwóch ludzi zgadza się ze sobą) i kosztując 500–5000× mniej niż ocena ręczna. Jeśli nie potrafisz liczbowo odpowiedzieć na pytanie „czy nowy prompt jest lepszy od starego" — nie masz evali i zmieniasz aplikację AI na ślepo. Fundament to golden dataset zbudowany z realnych awarii produkcyjnych, a nie z przykładów wymyślonych przy biurku.

Kompletny przewodnik po ewaluacji aplikacji LLM: czym evals różnią się od testów, jak zbudować golden dataset z realnych awarii, jak działa LLM-as-a-judge i czemu zgadza się z człowiekiem w ~85%, jakie metryki mierzyć (faithfulness, hallucination, answer relevancy), jak unikać biasów sędziego, jak wpiąć evals w CI/CD oraz które narzędzie wybrać — DeepEval, Ragas, Promptfoo czy Braintrust.

Zmieniasz jedno zdanie w promptie systemowym, bo chatbot źle odpowiedział jednemu klientowi. Wdrażasz poprawkę. Tydzień później okazuje się, że ta zmiana popsuła odpowiedzi w trzech innych scenariuszach, których nikt nie sprawdził. Brzmi znajomo? To codzienność zespołów, które rozwijają aplikacje AI bez ewaluacji — każda zmiana to ruletka, bo nikt nie mierzy, co tak naprawdę się poprawiło, a co zepsuło.

Ewaluacja zamienia tę ruletkę w inżynierię. Zamiast „wydaje się lepiej" dostajesz liczbę: 87% odpowiedzi spełnia kryteria, było 81%. To różni profesjonalny zespół AI od amatorskiego — i to właśnie najczęściej odróżnia wdrożenie, które działa, od demo, które się posypało w produkcji. Ten artykuł pokazuje, jak zbudować evals od zera: golden dataset, metryki, LLM-as-a-judge, biasy sędziego, CI/CD i wybór narzędzi.

Evals a testy — czym się różnią?

To pierwsze źródło nieporozumień. W artykule o testach aplikacji AI opisałem testy w sensie inżynierii oprogramowania — czy kod działa, czy API zwraca poprawny format, czy pipeline się nie wywala. Evals to co innego: mierzą jakość odpowiedzi modelu, która z natury jest nieostra.

Kluczowa różnica: w teście klasycznym "2 + 2" zawsze daje "4". W aplikacji LLM pytanie „streść tę umowę" ma dziesiątki dobrych odpowiedzi i nieskończenie wiele złych — i nie da się tego sprawdzić prostym porównaniem stringów. Dlatego potrzebujesz oceny jakościowej, którą da się zautomatyzować i powtórzyć. To właśnie robią evals.

Oba podejścia są potrzebne i się uzupełniają: testy pilnują, że aplikacja w ogóle działa, evals pilnują, że działa dobrze. Bez testów aplikacja się wywala; bez evali cicho degraduje jakość przy każdej zmianie promptu czy modelu.

Golden dataset — fundament każdej ewaluacji

Ewaluacja jest tyle warta, ile zestaw przykładów, na którym ją uruchamiasz. Golden dataset to zbiór reprezentatywnych przypadków wejściowych (a często też oczekiwanych odpowiedzi lub kryteriów), na których mierzysz jakość przy każdej zmianie. Cztery zasady, które decydują o jego wartości:

• Buduj z realnych awarii, nie z wymyślonych przykładów — najcenniejsze przypadki to te, na których aplikacja już zawiodła w produkcji; każdy zgłoszony błąd to nowy wiersz w golden secie, dzięki czemu ta sama awaria nigdy nie wróci niezauważona
• Rozmiar 200–500 przykładów na start — wystarczająco dużo, by wynik był statystycznie sensowny, wystarczająco mało, by eval był szybki i tani; rozbudowuj go w miarę odkrywania nowych przypadków brzegowych
• Pokryj różnorodność, nie tylko liczebność — przypadki typowe, brzegowe, trudne, prowokacyjne (prompt injection), w różnych językach i rejestrach; 500 wariantów tego samego pytania jest mniej warte niż 50 naprawdę różnych
• Wersjonuj go jak kod — golden dataset trzymaj w repozytorium, recenzuj zmiany przez pull requesty; to żywy artefakt, który rośnie z aplikacją

Najczęstszy błąd początkujących: generowanie golden setu syntetycznie przez sam model. Taki zestaw mierzy, jak dobrze model zgadza się sam ze sobą, a nie jak dobrze radzi sobie z prawdziwymi, nieprzewidywalnymi zapytaniami użytkowników. Syntetyczne przykłady są ok jako uzupełnienie, ale rdzeń musi pochodzić z realnego ruchu.

LLM-as-a-judge — jak model ocenia model

Skoro odpowiedzi nie da się sprawdzić porównaniem stringów, a ocena ręczna nie skaluje się do tysięcy przykładów przy każdej zmianie — kto ma oceniać? Odpowiedź 2026: drugi model językowy jako sędzia. LLM-as-a-judge to technika, w której silny model (np. GPT-4o, Claude) dostaje odpowiedź Twojej aplikacji wraz z rubryką oceny i zwraca werdykt — wynik liczbowy, etykietę lub porównanie.

Dlaczego to działa? Bo ocenianie jest łatwiejsze niż generowanie. Modelowi dużo prościej stwierdzić „czy ta odpowiedź jest oparta na podanym kontekście", niż samemu wygenerować idealną odpowiedź. Dane potwierdzają skuteczność: sędzia LLM zgadza się z ludzkimi recenzentami w ~85% przypadków — to więcej, niż wynosi zgodność między dwoma ludźmi przy tym samym zadaniu — przy koszcie 500–5000× niższym.

Są trzy główne tryby oceny:

• Pointwise (punktowy) — sędzia ocenia jedną odpowiedź na raz według kryteriów (np. „oceń trafność w skali 1–5"); najprostszy i najczęstszy
• Pairwise (parami) — sędzia porównuje dwie odpowiedzi i wskazuje lepszą; idealny do porównania dwóch wersji promptu lub dwóch modeli, bo względna ocena jest stabilniejsza niż bezwzględna
• Reference-based (z referencją) — sędzia porównuje odpowiedź z wzorcową; stosowany, gdy golden set zawiera oczekiwane odpowiedzi

Najważniejsza zasada: rubryka sędziego to produkt, który trzeba dopracować. Im konkretniejsze kryteria, tym wyższa zgodność z człowiekiem. „Oceń jakość" daje losowe wyniki; „Oceń, czy odpowiedź (1) odpowiada na pytanie, (2) jest oparta wyłącznie na podanym kontekście, (3) nie zawiera zmyślonych faktów — zwróć Tak/Nie dla każdego punktu" daje wynik powtarzalny i sensowny.

Jakie metryki mierzyć

Metryki dobierasz do typu aplikacji. Inne mają znaczenie dla chatbota RAG, inne dla agenta z narzędziami. Najważniejsze:

Dla aplikacji RAG (większość firmowych wdrożeń) złoty standard to triada: faithfulness (czy nie zmyśla), answer relevancy (czy odpowiada na pytanie) i context precision (czy retrieval działa). Te trzy metryki rozdzielają dwa różne źródła błędów — słaby retrieval (zła warstwa wyszukiwania) od słabej generacji (model dostał dobry kontekst, ale źle go użył) — co jest kluczowe, bo każdy naprawia się inaczej. Pisałem o warstwie retrievalu w artykule o zaawansowanym RAG.

Pułapki LLM-as-a-judge — biasy sędziego

Sędzia LLM nie jest obiektywny. Ma udokumentowane, systematyczne skłonności, które zafałszują wyniki, jeśli ich nie znasz i nie przeciwdziałasz:

• Position bias — w ocenie parami sędzia faworyzuje odpowiedź na pierwszej (lub ostatniej) pozycji niezależnie od treści; przeciwdziałanie: oceniaj każdą parę w obu kolejnościach i uśredniaj
• Verbosity bias — sędzia preferuje dłuższe, rozwlekłe odpowiedzi, myląc długość z jakością; przeciwdziałanie: w rubryce jawnie nagradzaj zwięzłość i karz lanie wody
• Self-preference bias — sędzia faworyzuje odpowiedzi generowane przez ten sam model co on sam; przeciwdziałanie: używaj do oceny innego modelu niż do generacji
• Sycophancy — sędzia zgadza się z sugestiami zawartymi w prompcie („czy ta świetna odpowiedź jest dobra?"); przeciwdziałanie: pisz rubryki neutralnie, bez podpowiadania oczekiwanego werdyktu

Najważniejsze zabezpieczenie: kalibracja sędziego względem człowieka. Zanim zaufasz automatycznym wynikom, każ człowiekowi ręcznie ocenić 50–100 przykładów, uruchom na nich sędziego LLM i policz zgodność. Celuj w 85–90%. Jeśli zgodność jest niższa, dopracuj rubrykę i powtórz. Sędzia bez kalibracji to generator liczb, którym nie można ufać — a kalibrowany sędzia to wiarygodny, tani recenzent działający 24/7.

Ewaluacja w kodzie — przykład z DeepEval

Najkrótsza droga do działającego evalu to DeepEval — pisze się go jak test pytest. Poniżej ewaluacja odpowiedzi RAG na trzy metryki naraz:

from deepeval import evaluatefrom deepeval.test_case import LLMTestCasefrom deepeval.metrics import (    FaithfulnessMetric,    AnswerRelevancyMetric,    ContextualPrecisionMetric,)# Przyklad z golden datasetu: pytanie + kontekst z retrievalu + odpowiedz aplikacjitest_case = LLMTestCase(    input="Jaki jest okres wypowiedzenia w umowie?",    actual_output="Okres wypowiedzenia wynosi 3 miesiace.",    expected_output="3 miesiace",    retrieval_context=[        "Par. 8: Umowa moze byc rozwiazana z zachowaniem "        "trzymiesiecznego okresu wypowiedzenia."    ],)# Sedzia LLM ocenia kazda metryke; prog 0.7 = bramka jakoscimetrics = [    FaithfulnessMetric(threshold=0.7, model="gpt-4o"),    AnswerRelevancyMetric(threshold=0.7, model="gpt-4o"),    ContextualPrecisionMetric(threshold=0.7, model="gpt-4o"),]results = evaluate(test_cases=[test_case], metrics=metrics)Trzy rzeczy, które robią tu różnicę:- **model="gpt-4o" to sędzia, nie aplikacja** — do oceny używasz silnego, innego modelu niż ten, który generuje odpowiedzi (unikasz self-preference bias)- **threshold=0.7 to bramka jakości** — poniżej tego progu test failuje; to ten próg blokuje merge w CI, gdy zmiana pogarsza jakość- **retrieval_context oddziela retrieval od generacji** — faithfulness sprawdza, czy odpowiedź wynika z kontekstu; context precision sprawdza, czy retrieval podał właściwy fragment; rozdzielasz dwa źródła błędów

W produkcji nie uruchamiasz pojedynczego przypadku, tylko cały golden dataset (200–500 wierszy), a wynik agregujesz: „92% przeszło próg faithfulness". Ten odsetek to liczba, którą porównujesz między wersjami.

Evals w CI/CD — bramki jakości

Pełna wartość evali ujawnia się, gdy wpniesz je w pipeline jak testy. Dojrzała ewaluacja produkcyjna w 2026 to cztery etapy z automatycznymi bramkami jakości:

1. 1.Rozwój lokalny — programista iteruje nad promptem, uruchamiając DeepEval lub Promptfoo na golden secie jak testy jednostkowe; pętla zwrotna w sekundach
2. 2.PR / merge (CI) — przy każdym pull requeście automatyczny eval na pełnym golden secie; jeśli jakość spada poniżej progu, bramka blokuje merge — dokładnie jak failujący test
3. 3.Staging — eval regresji porównuje nową wersję z poprzednią; wyłapuje ciche pogorszenia na znanych przypadkach, zanim trafią do użytkowników
4. 4.Produkcja — online eval na próbce realnego ruchu; sędzia ocenia losowy procent odpowiedzi na żywo, a alert odpala się przy spadku jakości (łączy się to z monitoringiem AI z osobnego artykułu)

Wybór narzędzia zależy od potrzeby — i w praktyce dojrzałe zespoły łączą dwa z trzech open-source'owych:

• DeepEval — gdy chcesz testów jednostkowych LLM zintegrowanych z pipeline (pytest-style, 14+ metryk, custom rubryki po polsku); domyślny wybór do CI/CD
• Ragas — gdy głęboko ewaluujesz RAG; research-backed metryki retrievalu i generacji, najczęściej cytowane w pracach naukowych; często dokładany do DeepEval
• Promptfoo — gdy potrzebujesz red teamingu i walidacji bezpieczeństwa (prompt injection!) obok ewaluacji promptów; konfiguracja w YAML, bez kodu
• Braintrust — gdy chcesz jednej platformy łączącej cały cykl: dataset, scoring, monitoring produkcji i bramki CI w jednym miejscu (komercyjny SaaS)

Reguła: zacznij od DeepEval (lub Promptfoo, jeśli wolisz YAML), dołóż Ragas, gdy RAG wymaga głębszej analizy, a po platformę typu Braintrust sięgnij, gdy zespół rośnie i chcesz wszystko w jednym narzędziu.

Checklist wdrożenia ewaluacji LLM

1. 1.Zbuduj golden dataset z realnych awarii produkcyjnych — 200–500 różnorodnych przykładów, nie syntetycznych
2. 2.Wersjonuj golden set w repozytorium i recenzuj zmiany przez pull requesty
3. 3.Dobierz metryki do typu aplikacji — dla RAG triada: faithfulness, answer relevancy, context precision
4. 4.Pisz rubryki sędziego konkretnie: rozbij ocenę na jasne, sprawdzalne kryteria
5. 5.Używaj do oceny innego (silnego) modelu niż do generacji — unikasz self-preference bias
6. 6.Skalibruj sędziego: 50–100 ręcznych ocen, policz zgodność, celuj w 85–90%
7. 7.Przeciwdziałaj biasom: oceny parami w obu kolejnościach, nagradzaj zwięzłość w rubryce, neutralne prompty
8. 8.Ustaw progi (bramki jakości) na metrykach i wepnij eval w CI — niech blokuje merge przy spadku jakości
9. 9.Dodaj eval regresji w stagingu — porównuj nową wersję z poprzednią na golden secie
10. 10.Wdróż online eval na produkcji: sampluj realny ruch, alertuj przy spadku jakości
11. 11.Każdą nową awarię produkcyjną dopisuj do golden setu — niech ten sam błąd nigdy nie wróci niezauważony
12. 12.Łącz narzędzia świadomie: DeepEval/Promptfoo do pipeline, Ragas do RAG, Braintrust gdy chcesz jednej platformy

Najważniejsze wnioski

Bez ewaluacji rozwijasz aplikację AI na ślepo — każda zmiana promptu czy modelu to ruletka. Evals zamieniają „wydaje się lepiej" w liczbę i odróżniają profesjonalny zespół AI od amatorskiego. Fundament to golden dataset z realnych awarii (200–500 różnorodnych przykładów), a nie z syntetyki. Najskuteczniejsza metoda oceny to LLM-as-a-judge — ~85% zgodności z człowiekiem przy koszcie 500–5000× niższym — ale tylko po kalibracji i z przeciwdziałaniem biasom (position, verbosity, self-preference, sycophancy). Dobierz metryki do aplikacji (dla RAG: faithfulness, answer relevancy, context precision), wepnij evals w CI jako bramki jakości i dopisuj każdą awarię do golden setu. Narzędzia: DeepEval do pipeline, Ragas do RAG, Promptfoo do bezpieczeństwa, Braintrust gdy chcesz jednej platformy.

---

Pomagam firmom budować systemy ewaluacji aplikacji AI — od golden datasetu i doboru metryk, przez kalibrację LLM-as-a-judge i przeciwdziałanie biasom, po wpięcie evali w CI/CD i monitoring produkcji. Napisz do mnie — zaczynam od bezpłatnej 30-minutowej analizy Twojego przypadku.