Ewaluacja LLM zbudowana na śladach z twojego systemu

W raporcie State of Agent Engineering firmy LangChain, opublikowanym w 2026 roku i opartym na odpowiedziach ponad 1300 specjalistów pracujących z agentami, 89% miało wdrożoną jakąś formę obserwowalności, ale 29,5% nie prowadziło żadnych ewaluacji, a jakość była najczęściej wskazywaną przeszkodą przed wdrożeniem produkcyjnym. Trace pokazuje, co wydarzyło się w jednej rozmowie. Ewaluacja pokazuje, jak często dany błąd występuje we wszystkich rozmowach i czy zmiana przesunęła tę liczbę.

Ogólne wskaźniki, takie jak pomocność czy ocena od jednego do dziesięciu, rzadko pomagają. Rosną i spadają, a nikt nie wie, co naprawić. Zaczynamy od błędów, które twój system faktycznie popełnia.

W pierwszym tygodniu wybieramy co najmniej 100 śladów lub zamkniętych spraw i czytamy je z kimś, kto zna tę pracę, na przykład z kierowniczką wsparcia albo likwidatorem szkód. Do każdej sprawy krótko notujemy, co pierwsze poszło nie tak. Czytamy dalej, aż nowe ślady przestaną pokazywać nowe rodzaje błędów.

Potem grupujemy notatki w krótką listę typów błędów i liczymy je. To liczby decydują o pracy. Część błędów naprawiamy od razu w prompcie albo w ustawieniach wyszukiwania, część dostaje sprawdzenie w kodzie, a sędziego LLM dostają tylko te, które wymagają oceny.

Zestaw testów powstaje z twoich śladów i zamkniętych spraw, oznaczonych według intencji, trudności i języka, i jest wersjonowany obok promptów, żeby każdy wynik dało się odtworzyć. Jeśli produkt nie ma jeszcze użytkowników, generujemy przypadki według określonych wymiarów, zamiast po prostu prosić model o pytania testowe, a twoi eksperci dopisują przypadki, o których wiedzą, że są trudne.

W systemach RAG oznaczamy, który fragment powinien odpowiadać na każde pytanie, żeby wyszukiwanie i odpowiedź oceniać osobno. U agentów najpierw sprawdzamy wynik, a ślad służy do znalezienia miejsca, w którym przebieg poszedł w złą stronę.

• Przypadki z prawdziwego ruchu, oznaczone i wersjonowane w twoim repozytorium
• Rzadkie, ale kosztowne przypadki zostają w zestawie, nawet jeśli to mały odsetek ruchu
• Pytania w każdym języku, w którym piszą twoi użytkownicy
• Przypadki dla każdego typu błędu z analizy błędów

Najpierw piszemy sprawdzenia w kodzie: poprawny JSON, wymagane pola, zapytanie SQL, które się wykonuje, kwota zwrotu zgodna z zasadami. Kosztują prawie nic i za każdym razem dają ten sam wynik. Tam, gdzie błąd wymaga oceny, na przykład gdy odpowiedź przekręca zapis umowy, budujemy sędziego, który dla tego jednego błędu zwraca zaliczone albo niezaliczone.

Każdego sędziego testujemy na przypadkach, których wcześniej nie widział, porównując go z ocenami twojego eksperta. Podajemy, ile prawdziwych błędów wyłapuje i ile dobrych odpowiedzi niesłusznie odrzuca, żebyś wiedział, na ile ufać jego liczbom. Gdy zmienia się model sędziego, jego prompt albo kryteria oceny, testujemy go ponownie.

Mały zestaw, głównie sprawdzenia w kodzie, uruchamia się w CI przy każdej zmianie promptów, modeli, narzędzi lub ustawień wyszukiwania. Każdy typ błędu ma własny próg, więc poprawa w jednym miejscu nie ukryje pogorszenia w innym. Na produkcji sędziowie działają na próbce prawdziwego ruchu, z alertami dla każdego typu błędu.

Raport bazowy zestawia w jednej tabeli jakość, koszt udanego zadania i opóźnienie, z przedziałami ufności. Przy 100 przypadkach 80% i 83% zwykle mieszczą się w granicach szumu i tak to opisujemy, zamiast ogłaszać sukces.

Pomiar bazowy obejmuje jeden produkt AI lub jeden proces, na przykład asystenta wsparcia, wewnętrzne narzędzie RAG albo agenta procesowego, w maksymalnie dwóch językach. Potrzebuje po twojej stronie eksperta dziedzinowego na kilka godzin tygodniowo i dostępu do śladów lub zamkniętych spraw. Przed startem uzgadniamy, jak postępujemy z tymi danymi, w tym pseudonimizację danych osobowych.

Jeśli już prowadzisz ewaluacje, dwutygodniowy audyt sprawdza, czy można im ufać: jak znaleziono typy błędów, czy sędziów porównano z ocenami ludzi i czy wskaźniki pasują do decyzji, które na ich podstawie podejmujesz.

• Typy błędów z liczbą wystąpień
• Wersjonowany zestaw testów w twoim repozytorium
• Sprawdzenia w kodzie, prompty sędziów i raport, na ile każdy sędzia zgadza się z twoim ekspertem
• Konfiguracja bramki w CI i próbkowania na produkcji
• Raport bazowy z jakością, kosztem i opóźnieniem oraz uszeregowana lista poprawek

Pracujemy z platformą, której już używasz, na przykład Langfuse, LangSmith albo Braintrust, albo bez żadnej. Zestawy testów i sędziowie zostają w prostych formatach w twoim repozytorium. Narzędzia do ewaluacji w ciągu ostatnich dwóch lat często zmieniały właściciela, a OpenAI 31 października 2026 przełączyło swoją hostowaną platformę Evals w tryb tylko do odczytu i wyłączy ją 30 listopada 2026, dlatego twoje ewaluacje nie powinny zależeć od żadnego z nich.

Zgodnie z AI Act obowiązki testowania według określonych wskaźników, deklarowania dokładności i monitorowania po wdrożeniu spoczywają na dostawcach systemów wysokiego ryzyka. Według harmonogramu przyjętego w 2026 roku obowiązują od 2 grudnia 2027 dla zastosowań wysokiego ryzyka wymienionych w załączniku III i od 2 sierpnia 2028 dla AI w produktach objętych załącznikiem I. W przypadku większości chatbotów, wewnętrznych asystentów i narzędzi RAG rozporządzenie nie przewiduje takiego obowiązku. Ewaluacje to w każdym przypadku dobra inżynieria i mogą dostarczyć dużą część dowodów z testów, których dostawca będzie potrzebował, jeśli zastosowanie stanie się systemem wysokiego ryzyka. Nie oceniamy zgodności i nie udzielamy porad prawnych.