Jak ocenić LLM w produkcji bez „vibes”? Reguły i metryki w Pythonie

Czym jest ocena LLM „na vibes” i dlaczego zawodzi?

Ocena „na vibes” to wnioskowanie o jakości modelu z kilku doraźnych prób i subiektywnego wrażenia. Daje małe pokrycie przypadków, nie opiera się na mierzalnym benchmarku i nie pozwala uczciwie porównać dwóch wersji promptu. Zespół nie wie wtedy, czy zmiana poprawiła jakość, czy tylko styl odpowiedzi [1].

W projektach kodowych ten sam problem widać szczególnie ostro. Model może wygenerować kod, który się kompiluje, a jednocześnie korzysta z nieistniejącego argumentu funkcji albo pomija przypadek brzegowy. Bez zestawu przypadków i jawnego kryterium zaliczenia taka wada wychodzi dopiero u użytkownika. Szerszy kontekst narzędzi i modeli do pracy z kodem opisujemy w hubie AI do programowania.

Ocena „na vibes” przenosi więc koszt wykrycia błędu z etapu testów na produkcję. AWS wskazuje trzy konsekwencje: ryzyko błędnej decyzji, małe pokrycie przypadków i brak mierzalnego benchmarku. Materiał opublikowano 17 października 2025 r. [1]

Jak zdefiniować halucynację, żeby dała się zmierzyć?

NIST nazywa halucynację konfabulacją: treścią przedstawioną z pewnością, która jest fałszywa albo sprzeczna ze źródłem lub kontekstem [2]. Taka definicja jest punktem wyjścia, bo wskazuje, z czym porównujemy odpowiedź.

Bez definicji operacyjnej dwie osoby liczą jako błąd różne rzeczy i wyniki przestają być porównywalne. Definicja powinna więc obejmować cztery elementy: jednostkę oceny (zdanie, pole, cała odpowiedź), źródło prawdy, kryterium zaliczenia i sposób postępowania z przypadkami niejednoznacznymi.

Nie istnieje jeden uniwersalny wskaźnik halucynacji. Wynik zależy od zadania: ekstrakcja liczb, odpowiadanie na pytania, streszczanie i generowanie narracji wymagają innych testów. Raport Stanford AI Index 2025 podkreśla problemy z porównywalnością benchmarków oraz różnice między HHEM, FACTS i SimpleQA [3].

Jak zbudować wersjonowany golden set?

Zestaw testowy powinien zawierać rzeczywiste zapytania, przypadki brzegowe, różne typy dokumentów oraz oczekiwane odpowiedzi lub źródła. Kilka ręcznie wybranych promptów nie wystarcza, bo nie pokrywa rozkładu ruchu produkcyjnego [4].

Wersjonowanie jest równie ważne jak treść. Każda zmiana modelu, promptu i danych powinna mieć własny numer, inaczej wyników nie da się porównać w czasie. Materiał Posit o ewaluacjach w Pythonie ukazał się 5 października 2026 r. i opisuje izolowanie logiki modelu, realistyczny zbiór testowy, jawne kryteria oraz automatyzację [4].

NIST zaleca testowanie znanych wejść na kilku poziomach: testami jednostkowymi, integracyjnymi i systemowymi [5]. W praktyce oznacza to osobne przypadki dla samego modelu i osobne dla całego przepływu.

Liczebność próby jest częścią metody. Bez podania n, definicji błędu i przedziału ufności pojedyncza liczba, na przykład informacja o odsetku błędnych odpowiedzi, nie mówi nic o jakości pomiaru.

Jakie metryki dobrać do zadania?

Metryka musi odpowiadać typowi odpowiedzi. Dla liczb i pól strukturalnych sprawdza się dokładne dopasowanie lub tolerancja numeryczna. Dla tekstu otwartego potrzebna jest ocena zgodności z referencją, kompletności, trafności i cytowań [6].

Narzędzie Inspect AI rozróżnia między innymi scorery typu exact, match, F1 oraz ocenę przez model, co pozwala zestawić kilka metryk w jednym przebiegu [6].

Modele językowe są probabilistyczne, więc ten sam prompt może dać różne odpowiedzi w dwóch uruchomieniach. Test trzeba powtarzać, a wynik podawać jako rozkład, nie jako jeden przebieg [7].

Czy model jako sędzia wystarczy jako źródło prawdy?

Nie. Ocena przez drugi model jest użyteczna, ale nie jest samodzielnym ground truth. Należy kalibrować ją na ocenach ekspertów, kontrolować bias kolejności odpowiedzi i regularnie sprawdzać zgodność z ludźmi [8].

Delegowanie oceny do innego LLM bywa wygodne przy porównywaniu promptów, jednak bez kalibracji przenosi niepewność z jednego modelu na drugi [9]. Sędzia powinien mieć własny, niewielki zbiór przypadków z etykietami eksperckimi i próg zgodności, poniżej którego jego werdykt jest odrzucany.

Co raportować poza średnią?

Minimum to n, definicja błędu, wynik ogólny i wynik w podziale na segmenty, przedział ufności lub błąd standardowy, liczba odmów, koszt, opóźnienie oraz wersje modelu, promptu i danych [6].

Podział na segmenty pokazuje, gdzie model zawodzi. Wysoka średnia może ukryć słaby wynik w jednej kategorii dokumentów, a to właśnie ta kategoria zwykle trafia do produkcji najczęściej.

Liczba odmów jest osobną metryką. Model, który nie odpowiada, nie jest bezpieczny, tylko bezużyteczny w danym miejscu procesu.

Jak wpiąć ewaluację w pipeline w Pythonie?

Warstwa ewaluacyjna powinna być zwykłym modułem, który przyjmuje odpowiedź, kontekst i oczekiwanie, a zwraca werdykt oraz powód. Taki moduł da się testować bez wywoływania modelu.

from dataclasses import dataclass

@dataclass
class Verdict:
    passed: bool
    score: float
    reason: str

def check_fields(answer: str, expected: dict[str, float], tolerance: float = 0.01) -> Verdict:
    missing = [key for key in expected if key not in answer]
    if missing:
        return Verdict(False, 0.0, 'brak pol: ' + ', '.join(missing))
    return Verdict(True, 1.0, 'wszystkie pola obecne')

def check_citations(answer: str, sources: list[str]) -> Verdict:
    used = [source for source in sources if source in answer]
    if not used:
        return Verdict(False, 0.0, 'brak odwolania do zrodel')
    return Verdict(True, len(used) / len(sources), 'zrodla uzyte')

def evaluate(answer: str, expected: dict[str, float], sources: list[str]) -> list[Verdict]:
    return [check_fields(answer, expected), check_citations(answer, sources)]

Jeśli model zwraca dane strukturalne, osobna warstwa powinna walidować je schematem i naprawiać typowe błędy formatowania, na przykład bloki kodu wokół JSON-a. Opis takiego podejścia w Pythonie z użyciem JSON Schema i Pydantic obejmuje obsługę fence, argumentów narzędzi oraz powtórzeń naprawczych [10].

Warto zacząć od małego zestawu i rozwijać go z każdym wykrytym błędem. Biblioteki do przetwarzania danych w takich pipeline'ach zestawiamy w osobnym artykule o bibliotekach Python do pipeline'ów danych.

Jak prowadzić pętlę regresji w produkcji?

Produkcja wymaga próbkowania odpowiedzi, eskalacji istotnych finansowo przypadków do człowieka i dodawania wykrytych błędów do zbioru testowego. Ewaluację uruchamia się przy każdej zmianie modelu, promptu lub danych [11].

OpenAI opisuje podstawowy cykl: zdefiniowanie zadania, uruchomienie na danych testowych, analiza wyników i iteracja. Platforma Evals OpenAI przechodzi w tryb tylko do odczytu 31 października 2026 r., a wyłączenie zaplanowano na 30 listopada 2026 r. [11]

Ewaluacja powinna obejmować cały system, nie tylko model. Błędy powstają w retrievalu, parsowaniu, promptcie, narzędziach, obliczeniach i post-processingu. NIST zaleca monitorowanie w rzeczywistym środowisku oraz regularne testy adversarialne [2].

Zespół, który wdraża agenta kodującego, powinien też kontrolować, co agent widzi i czym się posługuje. Wątek o wstrzykiwaniu poświadczeń w runtime pokazuje, że granica systemu wykracza poza sam model.

Najczęstsze pytania

Ile przypadków powinien mieć golden set?

Nie ma jednej liczby. Zestaw musi pokrywać rzeczywiste zapytania, przypadki brzegowe i różne typy dokumentów, więc zaczyna się od kilkudziesięciu przypadków i rośnie wraz z błędami znajdowanymi w produkcji. Ważniejsze od rozmiaru jest wersjonowanie i to, żeby każdy przypadek miał jednoznaczne oczekiwanie [4][5].

Czy wystarczy jeden model jako sędzia?

Nie bez kalibracji. Ocena przez model bywa przydatna, ale nie jest samodzielnym źródłem prawdy. Potrzebny jest zbiór przypadków z etykietami ekspertów, kontrola biasu kolejności i próg zgodności, poniżej którego werdykt sędziego jest odrzucany [8][9].

Jak często uruchamiać ewaluację?

Przy każdej zmianie modelu, promptu i danych testowych, a w produkcji dodatkowo cyklicznie na próbce rzeczywistych odpowiedzi. Sam harmonogram bez wersjonowania niewiele daje, bo nie wiadomo, co dokładnie porównujemy [11].

Czy ewaluacja zastępuje testy jednostkowe?

Nie. Testy jednostkowe sprawdzają kod wokół modelu: parsowanie, walidację schematu, obsługę błędów. Ewaluacja mierzy jakość odpowiedzi. NIST zaleca oba poziomy równolegle, razem z testami integracyjnymi i systemowymi [5].

Co robić z odpowiedziami, których nie da się ocenić automatycznie?

Eskalować do człowieka i oznaczyć jako osobną kategorię w raporcie, zamiast wliczać je do średniej lub pomijać. Liczba takich przypadków sama jest metryką i pokazuje, gdzie potrzebna jest lepsza definicja błędu lub lepszy zbiór testowy [6].

Źródła

1. Beyond vibes: How to properly select the right LLM for the right task (AWS, 2025)
2. NIST Trustworthy and Responsible AI NIST AI 600-1 (NIST, 2024)
3. Artificial Intelligence Index Report 2025, Chapter 3: Responsible AI (Stanford HAI, 2025)
4. Vibes are not a Metric: A Guide to LLM Evals in Python (Posit, 2026)
5. NIST AI 600-1 Generative AI Profile (NIST)
6. Scorers (Inspect AI)
7. Jak podejść do testowania LLM-ów? (Testerzy.pl)
8. Custom Scorers (Inspect AI)
9. Porównaj możliwości LLM z podsumowaniem (web.dev)
10. Walidacja strukturyzowanych danych wyjściowych LLM w Pythonie (Glukhov.org)
11. Working with evals (OpenAI)