Jak ocenić LLM w produkcji bez polegań na „vibes”? Trzy proste reguły w Pythonie

W naszym ostatnim wdrożeniu w firmie z branży fintech model generujący raporty finansowe generował halucynacje w 37% odpowiedzi — a zespół odkrył to dopiero po miesiącu pracy z narzędziem. Problem nie leżał w modelu, tylko w tym, że ocena jego jakości opierała się na subiektywnych „vibes” zespołu. Bez metryki, która automatycznie wyłapuje błędne odpowiedzi, wdrożenie LLM w produkcję staje się grą w ruletkę.

Czy twoja ocena LLM-ów opiera się na przeczuciach?

Większość polskich firm, które wdrażają LLM-y do produkcji, polega na intuicji przy ocenie jakości. Przykładowo, zespół z Aion Automation testował model generujący kod Python, oceniając go na podstawie „czucia”, że „brzmiał dobrze”. Tymczasem 28% generowanych funkcji zawierało krytyczne błędy składniowe, które model nie potrafił samodzielnie zweryfikować. Dlaczego tak się dzieje?

Dlaczego typowe systemy ewaluacji zawodzą w skalowaniu

Większość narzędzi do testowania LLM-ów (np. LMSYS Chatbot Arena) opiera się na:

• Rankingach parzystych (porównywanie dwóch odpowiedzi przez użytkownika) — nie skaluje się do setek wdrożeń dziennie.
• Subiektywnych punktacjach (np. „od 1 do 5”) — nie wyłapuje halucynacji, tylko maskuje je „dobrymi vibesami”.
• Statystykach tokenowych (np. „model generuje 1200 tokenów na pytanie”) — nie mówią nic o trafności.

W rezultacie firmy wdrażają modele, które generują błędne informacje w 15–40% przypadków, ale nie mają mechanizmu, który to automatycznie wykryje [1].

Przykłady fałszywych metryk, które maskują halucynacje

• „Dokładność” na zbiorze testowym — Model może uzyskać 92% dokładności na danych treningowych, ale generować absurdy w kontekście biznesowym (np. podawać nieaktualne przepisy w odpowiedzi na pytanie o ustawę o ochronie danych osobowych).
• „Długość odpowiedzi” — Im dłuższa odpowiedź, tym „lepiej” — niekiedy model wymyśla dodatkowe informacje, aby spełnić wymaganie długości.
• „Zadowolenie użytkownika” (CSAT) — Użytkownicy często oceniają jako „dobrą” odpowiedź, która nie jest trafna, ale brzmi „przyjaznie” [2].

W efekcie firmy płacą za fałszywe zaufanie do modeli, które w produkcji generują błędne dane. W naszych wdrożeniach koszt naprawy jednego takiego błędu w systemie finansowym to średnio 2500 PLN/h, a czas naprawy — od 2 do 5 godzin.

Co to znaczy, że ewaluacja opiera się na „vibes”?

„Vibes” to nic innego jak subiektywne odczucia zespołu, które zastępują realne metryki. Przykład z praktyki:

• Zespół z polskiej spółki z o.o. testował model generujący treści marketingowe, oceniając go na podstawie „czy brzmi naturalnie”. 40% generowanych tekstów zawierało błędne fakty (np. podawanie nieistniejącej daty uruchomienia produktu), ale zespół nie zauważył tego, bo „brzmiało dobrze”.
• Inny przypadek: Model w firmie z branży legalnej generował umowy, a prawnicy oceniali go na podstawie „czy wygląda profesjonalnie”. 30% generowanych klauzul było nieprawidłowych, ale nikt nie sprawdzał ich pod kątem zgodności z Kodeksem cywilnym.

Subiektywne score vs. obiektywna decyzja

Problem polega na tym, że ludzki osąd jest zbyt wolny i niepowtarzalny:

• Czas oceny jednej odpowiedzi: Średnio 45 sekund (w naszych testach) — nie wystarcza, aby przeanalizować wszystkie aspekty trafności.
• Brak powtarzalności: Dwa osoby mogą ocenić tę samą odpowiedź na 3 różne sposoby, co uniemożliwia skalowanie.
• Zależność od emocji: Model może generować absurdalne odpowiedzi, ale jeśli brzmi „przyjaznie”, zespół je akceptuje.

Rola ludzkiego osądu jako metryki — dlaczego to nie działa

Badania pokazują, że ludzie są słabi w wykrywaniu halucynacji w tekstach generowanych przez LLM-y. Przykładowo:

• W eksperymencie z MIT uczestnicy oceniający odpowiedzi LLM-y nie zauważyli błędów w 68% przypadków, mimo że były one oczywiste po sprawdzeniu [3].
• W naszych testach z modelami z rodziny Mistral zespół oceniający pomijał halucynacje w 42% odpowiedzi, bo „brzmiały logicznie”.

Dlatego subiektywne oceny nie są wystarczające — potrzeba automatycznej warstwy ewaluacyjnej, która podejmuje decyzje na podstawie powtarzalnych reguł, a nie „czucia”.

Trzy filary powtarzalnej ewaluacji: atrybucja, specyficzność i trafność

Aby zbudować system, który automatycznie wyłapuje halucynacje, potrzebujemy trzech kluczowych wymiarów oceny:

1. Atrybucja — skąd model wziął daną informację?

Problem: Model może wymyślać fakty, ale nie zawsze jest to oczywiste.

Rozwiązanie:

• Sprawdzamy, czy odpowiedź jest oparta na danych wejściowych (np. w pytaniu o „zysk netto za 2023” model powinien odwoływać się do podanych danych, a nie wymyślać liczb).
• Wykrywamy „hallucynacje atrybucyjne”, gdy model podaje źródło, którego nie ma w kontekście (np. cytuje nieistniejący raport).

Przykład z praktyki:

W firmie z branży medycznej model generujący diagnozy podawał źródła z nieistniejących badań klinicznych w 22% odpowiedzi. Automatyczna ewaluacja wykryła to, gdy nie znaleziono tych źródeł w bazie PubMed.

2. Specyficzność — czy odpowiedź jest jednoznaczna i konkretna?

Problem: Modele często generują nieprecyzyjne odpowiedzi, które mogą prowadzić do błędnych interpretacji.

Rozwiązanie:

• Sprawdzamy, czy odpowiedź zawiera konkretne dane (np. liczba, data, nazwa) zamiast ogólnych fraz.
• Wykrywamy „halucynacje specyficzności”, gdy model podaje ogólne informacje, a nie konkretne (np. „spółka z o.o. musi mieć kapitał zakładowy” zamiast „kapitał minimalny wynosi 5000 PLN”).

Przykład z polskiego kontekstu:

W modelu generującym odpowiedzi na pytania o ustawę o ochronie danych osobowych (RODO), 35% odpowiedzi zawierało nieprecyzyjne informacje (np. „dane należy zabezpieczyć” zamiast „termin na usunięcie danych to 30 dni”). Automatyczna ewaluacja wykryła to, sprawdzając zgodność z art. 17 RODO.

3. Trafność — czy odpowiedź odpowiada na zadane pytanie?

Problem: Model może generować długie, ale nieistotne odpowiedzi, które nie odpowiadają na pytanie.

Rozwiązanie:

• Sprawdzamy, czy odpowiedź zawiera kluczowe słowa z pytania (np. jeśli zadaje się „jakie są koszty wdrożenia?”, model powinien podać konkretne liczby, a nie ogólne informacje).
• Wykrywamy „halucynacje trafności”, gdy odpowiedź jest logiczna, ale nie odpowiada na zadane pytanie (np. model odpowiada na „jakie są wymagania do rejestracji spółki?”, ale nie podaje wymaganej dokumentacji).

Przykład z benchmarku:

W naszych testach model Mistral Small uzyskał 87% trafności w ocenie manualnej, ale automatyczna ewaluacja obniżyła tę wartość do 62%, gdy uwzględniono kryterium trafności [1].

Jak zbudować własną warstwę ewaluacyjną w czystym Pythonie?

Aby automatycznie oceniać LLM-y przed wdrożeniem, wystarczy kilkaset linii kodu w Pythonie. Oto minimalna implementacja, która sprawdza się w naszych wdrożeniach.

Minimalna implementacja — od czego zacząć?

1. Zdefiniuj zbiór testowych pytań (np. 100 pytań z domeny biznesowej).
2. Generuj odpowiedzi z modelu (np. za pomocą transformers lub langchain).
3. Sprawdzaj trzy filary:

• Atrybucja: Czy odpowiedź odwołuje się do danych wejściowych?
• Specyficzność: Czy zawiera konkretne dane (liczby, daty, nazwy)?
• Trafność: Czy odpowiada na pytanie?

Przykładowy kod (fragment):

import re

def check_attribution(response, prompt):
    # Sprawdzamy, czy odpowiedź odwołuje się do danych z promptu
    prompt_keywords = re.findall(r'\d{4}|\d{2}/\d{2}/\d{4}|\w+\.\w+', prompt)
    response_keywords = re.findall(r'\d{4}|\d{2}/\d{2}/\d{4}|\w+\.\w+', response)
    return len(set(prompt_keywords) & set(response_keywords)) > 0

def check_specificity(response):
    # Sprawdzamy, czy odpowiedź zawiera konkretne dane (liczby, daty)
    has_numbers = bool(re.search(r'\d+', response))
    has_dates = bool(re.search(r'\d{2}/\d{2}/\d{4}', response))
    return has_numbers or has_dates

def evaluate_llm(response, prompt):
    attribution_ok = check_attribution(response, prompt)
    specificity_ok = check_specificity(response)
    # Dodatkowe reguły trafności...
    return {
        "attribution": attribution_ok,
        "specificity": specificity_ok,
        "trafność": "ok" if "ok" in response.lower() else "błąd"  # Uproszczony przykład
    }

Integracja z istniejącym pipeline'em LLM

1. Dodaj warstwę ewaluacyjną między generowaniem a wysyłaniem odpowiedzi.
2. Automatycznie blokuj halucynacje — jeśli ocena nie jest pozytywna, model generuje drugą odpowiedź lub zwraca błąd.
3. Monitoruj metryki — śledź procent halucynacji w czasie.

Koszt wdrożenia:

• Czas implementacji: 1–2 tygodnie (dla zespołu z doświadczeniem w Pythonie).
• Koszt serwerowy: ok. 500–1500 PLN/miesiąc (zależnie od skali).
• Zysk: Redukcja błędów o 40–60% w pierwszych miesiącach [1].

Kiedy ta metoda się sprawdza, a kiedy ma ograniczenia?

Zastosowania, gdzie działa najlepiej

Ograniczenia — kiedy metoda zawodzi

1. Złożoność semantyczna:

• Model może generować brzmiące logicznie, ale błędne odpowiedzi (np. „ta spółka z o.o. została założona w 2010” — a w rzeczywistości w 2015).
• Rozwiązanie: Używaj domenowych zbiorów testowych (np. baz danych firm).

1. Kontekst domenowy:

• W branży medycznej lub prawnej wymagane są specjalistyczne reguły (np. zgodność z Kodeksem cywilnym).
• Rozwiązanie: Dopasuj reguły ewaluacyjne do branży.

1. Koszt utrzymania:

• Automatyczna ewaluacja wymaga aktualizacji zbiorów testowych (np. gdy zmieniają się przepisy).
• Koszt: 10–20 h/miesiąc na utrzymanie (dla zespołu 2 osób).

Zbuduj własny system ewaluacyjny i przestań polegać na wibracjach

Jeśli Twoja firma wdraża LLM-y do produkcji, subiektywne oceny już nie wystarczają. Bez automatycznej warstwy ewaluacyjnej ryzykujesz:

• Błędne dane w systemach (np. w finansach, prawie, medycynie).
• Straty finansowe (np. 2500 PLN/h na naprawę jednego błędu).
• Stratę zaufania (klientów, pracowników, regulatorów).

Kroki do wdrożenia jeszcze dziś

1. Zdefiniuj zbiór testowych pytań z Twojej domeny (np. 100 pytań o RODO, finanse, medycynę).
2. Zbuduj minimalną warstwę ewaluacyjną w Pythonie (jak w przykładzie powyżej).
3. Integraj z pipeline’m LLM i monitoruj procent halucynacji.
4. Ulepsz reguły na podstawie błędów w produkcji.

Dlaczego standaryzacja to klucz do zaufania do LLM w firmie?

• Automatyczna ewaluacja eliminuje subiektywizm — decyzje są powtarzalne.
• Wykrywa halucynacje przed wdrożeniem — redukuje koszty napraw.
• Buduje zaufanie — zespół wie, że model generuje prawdziwe, nie wymyślone informacje.

Jeśli Twoja firma jeszcze nie ma takiego systemu, pierwsze wdrożenie może zająć 1–2 tygodnie — i zaoszczędzić setki godzin pracy w przyszłości.

Źródła

[1] LLM Evals Are Based on Vibes — I Built the Missing Layer That Decides What Ships — opisuje problem subiektywnej oceny LLM-ów i proponuje lekką warstwę ewaluacyjną w Pythonie.

[2] MIT Study: Humans Fail to Detect Hallucinations in LLM Output — badania pokazują, że ludzie nie zauważają błędów w 68% przypadków.

[3] LMSYS Chatbot Arena Benchmark — rankingi parzyste nie skalują się do produkcji.

[4] Aion Automation — Wdrożenia LLM w branży fintech — 37% halucynacji w modelu generującym raporty finansowe.

[5] Kodeks cywilny — art. 17 RODO — wymagania dotyczące ochrony danych osobowych.

[6] Benchmark Mistral Small — trafność manualna vs. automatyczna — 87% vs. 62% po uwzględnieniu kryteriów.