Samo uzyskanie odpowiedzi od modelu AI nie oznacza jeszcze, że system działa poprawnie. W przypadku klasycznego oprogramowania możemy często jednoznacznie sprawdzić, czy funkcja zwróciła oczekiwany wynik. W systemach AI odpowiedź może być płynna, logiczna i przekonująca, a mimo to zawierać błędy.
Dlatego wraz z rozwojem AI pojawia się nowy problem inżynierski: jak systematycznie mierzyć jakość systemu, którego odpowiedzi nie zawsze są identyczne?
To właśnie obszar AI evaluation, czyli ewaluacji systemów sztucznej inteligencji.
I jest znacznie szerszy niż sprawdzenie, czy chatbot „odpowiada dobrze”.
Test klasycznego software'u i test AI to nie to samo
Wyobraźmy sobie prostą funkcję w aplikacji.
Użytkownik wpisuje: 2 + 2
System powinien zwrócić: 4
Jeżeli zwróci 5, mamy jednoznaczny błąd.
Możemy przygotować test: expect(calculate("2 + 2")).toBe(4)
i za każdym razem otrzymamy jasny wynik: test przechodzi albo nie przechodzi.
W systemach AI sytuacja wygląda inaczej.
Użytkownik może zapytać: „Napisz krótką odpowiedź dla klienta, który pyta o termin realizacji zamówienia.”
System może wygenerować kilka różnych odpowiedzi. Wszystkie mogą być językowo poprawne. Wszystkie mogą brzmieć profesjonalnie. Jedna może jednak zawierać nieprawdziwy termin, druga może być zbyt długa, trzecia może pominąć ważną informację, a czwarta może być idealna.
Nie wystarczy więc sprawdzić, czy odpowiedź jest technicznie wygenerowana.
Trzeba sprawdzić, czy spełnia określone kryteria jakości.
Pierwszy problem: dobra odpowiedź nie zawsze jest prawdziwa
To jedna z najbardziej charakterystycznych cech generatywnej AI.
Model może wygenerować odpowiedź, która brzmi bardzo przekonująco, ale nie ma pokrycia w danych źródłowych.
W przypadku systemu korzystającego z RAG problem jest jeszcze ciekawszy. System może otrzymać pytanie, wyszukać kilka fragmentów dokumentacji i następnie wygenerować odpowiedź.
Wtedy trzeba sprawdzić przynajmniej trzy rzeczy:
- Czy znaleziono właściwe informacje? Czy mechanizm wyszukiwania pobrał fragmenty rzeczywiście związane z pytaniem?
- Czy odpowiedź wykorzystuje znalezione informacje? Czy model nie dopisał czegoś, czego w źródłach nie było?
- Czy odpowiedź rzeczywiście odpowiada na pytanie? Można bowiem mieć poprawnie działający retrieval, ale kiepską odpowiedź końcową.
Właśnie dlatego ewaluacja RAG rozdziela między innymi takie aspekty jak trafność pobranego kontekstu, kompletność wyszukiwania, poprawność odpowiedzi i jej zgodność ze źródłami.
To ważna zmiana w myśleniu o testowaniu.
Nie testujemy już tylko: pytanie → odpowiedź
ale cały łańcuch: pytanie → wyszukiwanie → kontekst → model → odpowiedź
Można mieć dobry model i zły system AI
To kolejna rzecz, o której łatwo zapomnieć.
Firma może wybrać bardzo dobry model językowy, a mimo tego stworzyć słaby produkt AI.
Dlaczego? Bo jakość końcowego systemu zależy nie tylko od modelu.
Liczą się również:
- jakość danych,
- sposób przygotowania kontekstu,
- prompt,
- sposób wyszukiwania informacji,
- parametry modelu,
- narzędzia udostępnione AI,
- logika aplikacji,
- pamięć,
- sposób obsługi błędów,
- zabezpieczenia,
- sposób oceny odpowiedzi.
To oznacza, że pytanie: „Który model jest najlepszy?”
często jest mniej użyteczne niż: „Który model najlepiej sprawdza się w naszym konkretnym przypadku użycia?”
Model, który świetnie radzi sobie z generowaniem treści marketingowych, nie musi być najlepszym rozwiązaniem do klasyfikacji dokumentów, analizy danych czy obsługi procesów biznesowych.
Dlatego porównywanie modeli powinno odbywać się na rzeczywistych zadaniach, które system ma wykonywać.
Najpierw trzeba stworzyć własny zestaw testów
Nie da się sensownie oceniać systemu AI, jeśli nie wiemy, czego od niego oczekujemy.
Dlatego jednym z najważniejszych elementów ewaluacji jest przygotowanie datasetu testowego, czyli zestawu rzeczywistych lub reprezentatywnych przypadków.
Przykładowo firma buduje AI dla działu obsługi klienta.
Zamiast ręcznie sprawdzać jedną odpowiedź po każdej zmianie promptu, można przygotować kilkaset przypadków:
- proste pytania,
- pytania niejednoznaczne,
- pytania zawierające błędne założenia,
- pytania wymagające wyszukania dokumentu,
- pytania dotyczące wyjątków,
- pytania dotyczące reklamacji,
- pytania wymagające odmowy,
- pytania zawierające dane, których AI nie powinno ujawnić.
Każda zmiana systemu może być następnie uruchomiona na tym samym zestawie.
I właśnie tutaj AI zaczyna przypominać klasyczny software.
Nie testujemy już pojedynczej odpowiedzi. Testujemy zachowanie systemu na całym zestawie przypadków.
Prompt też można testować
Prompt często traktowany jest jak tekst, który ktoś napisał raz i zostawił na produkcji.
W rzeczywistości może być elementem logiki aplikacji.
Zmiana jednego zdania może spowodować:
- poprawę odpowiedzi w jednym scenariuszu,
- pogorszenie odpowiedzi w innym,
- większą skłonność do odmawiania,
- większą liczbę halucynacji,
- dłuższe odpowiedzi,
- wyższy koszt,
- większe zużycie tokenów.
Dlatego prompt powinien być traktowany podobnie jak kod.
Jeżeli zmieniamy prompt, warto wiedzieć:
- co się poprawiło?
- co się pogorszyło?
- czy pojawiła się regresja?
To właśnie dlatego coraz większe znaczenie ma automatyczna ewaluacja, a nie ręczne ocenianie kilku przykładowych odpowiedzi.
AI może przejść test i nadal być złym produktem
Załóżmy, że przygotowaliśmy 100 przypadków testowych.
System odpowiedział poprawnie na 95. Wynik wygląda świetnie. Ale co, jeśli pięć błędnych odpowiedzi dotyczy sytuacji krytycznych?
Jeżeli chatbot odpowiada na pytania o godziny otwarcia, pięć błędów może być problemem.
Jeżeli AI pomaga pracownikowi analizować dokumenty finansowe, medyczne albo prawne, znaczenie tych błędów może być zupełnie inne.
Dlatego sama średnia nie wystarczy.
Potrzebujemy również ważenia przypadków.
Możemy uznać, że:
- zwykłe pytanie ma wagę 1,
- istotny błąd ma wagę 5,
- błąd bezpieczeństwa ma wagę 10,
- ujawnienie poufnej informacji ma wagę 100.
Wtedy system nie dostaje „95 procent”. Dostajemy znacznie bardziej użyteczny obraz ryzyka.
Nie wszystko da się zmierzyć jedną liczbą
To jeden z najważniejszych problemów ewaluacji AI.
Możemy mieć kilka metryk:
- Accuracy - czy odpowiedź jest poprawna?
- Relevance - czy odpowiada na pytanie?
- Faithfulness / groundedness - czy opiera się na dostarczonych źródłach?
- Context precision - czy wyszukiwane fragmenty są trafne?
- Context recall - czy system znalazł potrzebne informacje?
- Safety - czy nie wykonuje niepożądanych działań?
- Latency - jak długo użytkownik czeka?
- Cost - ile kosztuje wykonanie zadania?
RAG może więc mieć bardzo dobrą jakość odpowiedzi, ale jednocześnie pobierać ogromną ilość kontekstu i generować nieakceptowalny koszt.
Inny system może być bardzo tani i szybki, ale popełniać zbyt wiele błędów.
Nie istnieje więc jedna uniwersalna liczba określająca, czy AI jest „dobre”. Jakość trzeba definiować w kontekście konkretnego zastosowania.
A co z ocenianiem AI przez inne AI?
Tutaj pojawia się kolejny ciekawy mechanizm.
Jednym ze sposobów automatyzacji ewaluacji jest wykorzystanie modelu jako sędziego, czyli LLM-as-a-judge.
Przykładowo:
Model A generuje odpowiedź.
Model B otrzymuje pytanie, odpowiedź i określone kryteria.
Następnie ocenia:
- poprawność,
- zgodność z instrukcją,
- kompletność,
- styl,
- bezpieczeństwo.
Współczesne narzędzia ewaluacyjne pozwalają również łączyć takie ocenianie z klasycznymi porównaniami tekstu, własnymi skryptami czy graderami opartymi na konkretnych regułach.
To ogromnie zwiększa skalę testowania. Ale nie oznacza, że człowiek przestaje być potrzebny. Model oceniający również może się mylić. Dlatego w systemach o większym znaczeniu biznesowym warto łączyć automatyczne ewaluacje z okresową oceną ekspercką.
Największy problem: regresja
Wyobraźmy sobie system, który działa bardzo dobrze. Zespół zmienia model na nowszy. Nowa wersja jest szybsza i tańsza. Wydaje się więc, że wszystko idzie w dobrym kierunku.
Po wdrożeniu okazuje się jednak, że:
- odpowiedzi są mniej precyzyjne,
- model częściej odmawia odpowiedzi,
- gorzej korzysta z dokumentacji,
- inaczej interpretuje instrukcje,
- w niektórych scenariuszach zaczyna podawać niepoprawne informacje.
To właśnie AI regression.
W klasycznym software znamy regresję od lat. W AI również musimy ją wykrywać, ale problem jest trudniejszy, ponieważ zachowanie systemu może zmienić się bez klasycznego „błędu”. Dlatego każda większa zmiana powinna być porównywana z poprzednią wersją.
Model.
Prompt.
Embedding.
Retriever.
Dokumentacja.
Logika agenta.
Parametry.
Każdy z tych elementów może wpłynąć na wynik.
Agenta nie wystarczy ocenić po jego końcowej odpowiedzi
Jeszcze trudniej robi się w przypadku agentów AI.
Klasyczny chatbot może wykonać jedno zadanie: pytanie → odpowiedź.
Agent może działać zupełnie inaczej: cel → plan → narzędzie → wynik → kolejny krok → decyzja → działanie → odpowiedź.
Jeżeli agent nie osiągnął celu, chcemy wiedzieć nie tylko, że przegrał.
Chcemy wiedzieć: gdzie popełnił błąd?
- Czy źle zrozumiał zadanie?
- Czy wybrał niewłaściwe narzędzie?
- Czy przekazał zły parametr?
- Czy pobrał niewłaściwe dane?
- Czy podjął złą decyzję po otrzymaniu wyniku?
- Czy wykonał zbyt wiele kroków?
- Czy zatrzymał się zbyt wcześnie?
W badaniach nad ewaluacją agentów coraz częściej analizuje się właśnie nie tylko wynik końcowy, ale również przebieg działania, użycie narzędzi, planowanie, pamięć, niezawodność i bezpieczeństwo.
To oznacza, że przyszłość testowania AI będzie w dużej mierze związana z analizą trace'ów, czyli pełnego przebiegu działania systemu.
AI potrzebuje czegoś podobnego do CI/CD
Jeżeli AI jest częścią produktu, nie można testować go tylko przed pierwszym wdrożeniem.
System będzie się zmieniał.
Zmieni się model.
Zmieni się prompt.
Zmieni się baza wiedzy.
Zmieni się sposób wyszukiwania.
Zmieni się konfiguracja.
Dlatego ewaluacja powinna wejść do procesu developmentu.
Schemat może wyglądać następująco: zmiana → testy → ewaluacja → porównanie z poprzednią wersją → decyzja o wdrożeniu
Jeżeli nowa wersja poprawia jakość w jednym obszarze, ale przekracza ustalony próg błędów w innym, deployment może zostać zatrzymany.
To bardzo podobna filozofia do klasycznego CI/CD, ale kryteria są inne.
W przypadku aplikacji AI możemy sprawdzać jednocześnie jakość odpowiedzi, poprawność, bezpieczeństwo, koszt i opóźnienie. Pojawiają się już rozwiązania badawcze, które łączą ewaluację z observability i bramkami jakości w procesie wdrażania systemów LLM/RAG.
Czy można więc testować AI tak samo jak klasyczny software?
Tak, ale tylko częściowo.
Klasyczne podejście nadal jest potrzebne.
Testujemy:
- API,
- integracje,
- uprawnienia,
- walidację danych,
- błędy,
- timeouty,
- bezpieczeństwo,
- wydajność,
- logikę aplikacji.
Ale na tym nie możemy skończyć.
Dochodzi druga warstwa: ewaluacja zachowania AI.
- Czy odpowiedź jest poprawna?
- Czy jest zgodna ze źródłami?
- Czy model trzyma się instrukcji?
- Czy system zachowuje się poprawnie w nieoczekiwanych sytuacjach?
- Czy agent wybiera właściwe narzędzia?
- Czy nowa wersja nie pogorszyła jakości?
- Czy koszt działania pozostaje akceptowalny?
- Czy użytkownik faktycznie otrzymuje wartość?
To już nie jest klasyczny unit test.
Najlepszy test AI to nie zawsze test laboratoryjny
Jest jeszcze jeden bardzo ważny element.
System może świetnie wypadać na przygotowanym zbiorze testowym, a mimo tego mieć problemy w prawdziwym świecie. Dlatego warto obserwować również rzeczywiste interakcje. Nie po to, żeby każdy użytkownik był testerem. Chodzi o to, żeby system można było stale doskonalić na podstawie rzeczywistych przypadków:
- gdzie użytkownicy poprawiają AI,
- gdzie proszą o ponowienie odpowiedzi,
- gdzie przerywają rozmowę,
- gdzie eskalują sprawę do człowieka,
- gdzie agent nie osiąga celu,
- gdzie pojawiają się nietypowe pytania.
W ten sposób powstaje ciągła pętla ewaluacji: użytkownik → działanie AI → wynik → analiza → nowy przypadek testowy → kolejna wersja systemu
To zupełnie inny model rozwoju niż jednorazowe „wdrożyliśmy AI i działa”.
AI nie powinno być oceniane pytaniem „czy działa?”
To zbyt mało.
Lepsze pytania brzmią:
- Jak często działa poprawnie?
- W jakich sytuacjach się myli?
- Jak poważne są te błędy?
- Czy nowa wersja jest lepsza od poprzedniej?
- Czy system jest wystarczająco bezpieczny?
- Czy odpowiedzi są oparte na właściwych danych?
- Ile kosztuje osiągnięcie konkretnego rezultatu?
Dopiero taki zestaw pytań pozwala mówić o dojrzałym systemie AI.
Najważniejsza zmiana w myśleniu
Przez lata w software development obowiązywała prosta zasada: kod powinien działać.
W systemach AI trzeba ją rozszerzyć: system powinien działać dobrze, przewidywalnie i mierzalnie.
To ogromna różnica. Bo AI nie jest funkcją, która zawsze zwraca ten sam wynik. Jest systemem probabilistycznym, którego zachowanie zależy od modelu, danych, kontekstu, instrukcji i całej architektury wokół niego.
Dlatego profesjonalne wdrożenie AI nie kończy się w momencie, kiedy model zaczyna odpowiadać.
Wtedy dopiero zaczyna się pytanie: skąd wiemy, że możemy mu zaufać?
I właśnie na to pytanie powinna odpowiadać dobrze zaprojektowana ewaluacja.
W przyszłości testowanie systemów AI prawdopodobnie stanie się równie naturalnym elementem procesu developmentu jak testy jednostkowe, integracyjne czy monitoring. Nie dlatego, że AI jest „niebezpieczne z definicji”. Po prostu dlatego, że system, którego wynik nie zawsze jest deterministyczny, wymaga innego sposobu mierzenia jakości.
A im bardziej AI przechodzi od generowania tekstu do obsługi rzeczywistych procesów, korzystania z danych, RAG i wykonywania działań przez agentów, tym ważniejsze staje się nie tylko pytanie „czy AI potrafi to zrobić?”, ale również: „czy potrafimy udowodnić, że robi to wystarczająco dobrze?”
