Ewaluacja agentów AI w produkcji: od trace’ów do zestawów testów

Viacheslav Dubrov

2026-06-10 · Zaktualizowano 2026-09-06 · 24 min · Agenci AI

Tłumaczenie automatyczne Ten artykuł został automatycznie przetłumaczony z angielskiego oryginału.

Aktualizacja artykułu

Pierwotnie opublikowano 10 czerwca 2026 r. Zrecenzowano i zaktualizowano 6 września 2026 r. Aktualizacja obejmuje nowsze benchmarki agentów, zmiany w graderach oraz dowody na to, jak infrastruktura wpływa na wyniki.

Odpowiedź końcowa może stwierdzać, że zwrot został zrealizowany, podczas gdy trace pokazuje, że verify_identity nigdy się nie wykonało, issue_refund ponowiło próbę 17 razy albo agent ogłosił sukces, zanim zmieniła się baza danych. Ewaluacja wyłącznie odpowiedzi ukrywa te błędy.

Dla inżynierów obsługujących agentów korzystających z narzędzi rozwiązaniem jest przekształcenie powtarzalnych trace’ów w ograniczone przypadki regresyjne: deterministyczne kontrole wymuszają kolejność narzędzi, argumenty, pętle i niezmienniki, a skalibrowani judge’owie obsługują decyzje wymagające interpretacji. Rezultatem jest wersjonowany zestaw, który wykrywa ten sam błąd jeszcze przed kolejnym wydaniem.

Krótka analiza narzędzi znajduje się w Najlepsze narzędzia do ewaluacji agentów AI.

Dlaczego ewaluacja agentów jest inna

Tradycyjne ewaluacje LLM zwykle oceniają jedną parę wejście–wyjście: trafność, faithfulness, poprawność, bezpieczeństwo, czasem styl. Agenci dodają planowanie, wywołania narzędzi, ponawianie prób i kontrole zakończenia, a każdy krok jest kolejnym miejscem potencjalnej awarii.

Weźmy agenta obsługującego zwroty. Transkrypcja może zakończyć się pomyślnie, mimo że trace jest nieprawidłowy:

lookup_order -> issue_refund -> final_answer

Ewaluacja wyjścia przechodzi. Ewaluacja trajektorii powinna zakończyć się niepowodzeniem, ponieważ verify_identity nigdy nie wykonało się przed issue_refund. W przypadku agentów korzystających z narzędzi ewaluacje wyłącznie odpowiedzi mogą wykrywać problemy z jakością treści, ale nie potrafią potwierdzić, że agent przebył prawidłową trajektorię ani że wprowadził wymagane zmiany w systemie.

Istnieje też drugi problem: błędy się kumulują. Jeśli workflow ma 20 wymaganych kroków, każdy z nich kończy się niezależnie powodzeniem, a niezawodność każdego kroku wynosi 95%, wskaźnik sukcesu end-to-end wynosi około 36%:

Agent może więc wypadać dobrze w izolowanych testach, a mimo to kończyć się niepowodzeniem w większości pełnych uruchomień. Awaria zwykle znajduje się gdzieś pośrodku, a jej wykrycie wymaga widoczności na poziomie komponentów, nie kolejnego spojrzenia na odpowiedź.

Dwa zespoły badawcze przedstawiły to liczbowo.

tau-bench udostępnia agentowi zadania z obsługi klienta linii lotniczych i handlu detalicznego. Agent rozmawia z symulowanym użytkownikiem, wywołuje APIs i musi przestrzegać polityki domenowej. Po zakończeniu rozmowy grader sprawdza, czy baza danych osiągnęła opatrzony adnotacją stan docelowy. Prawdopodobna transkrypcja z nieprawidłowymi rekordami nadal kończy się niepowodzeniem.

Przy takim sposobie oceniania GPT-4o rozwiązał 35,2% zadań lotniczych i nieco ponad 60% zadań detalicznych. W artykule wprowadzono również pass^k: prawdopodobieństwo, że wszystkie k niezależnych prób zakończy się powodzeniem, uśrednione po zadaniach.

Łatwiejszy podział detaliczny miał pass^8 poniżej 25%. Dla losowo wybranego zadania detalicznego i ośmiu niezależnych prób prawdopodobieństwo, że wszystkie osiem uruchomień zakończy się powodzeniem, wynosiło poniżej 25%. Ewaluacja jednego uruchomienia nie mierzy tej spójności.

MAST bada, dlaczego agenci zawodzą. Autorzy stworzyli 14-elementową taksonomię na podstawie 150 ręcznie oznaczonych trace’ów, a następnie zastosowali ją do ponad 1600 trace’ów z 7 popularnych frameworków multi-agentowych. Taksonomia obejmuje nieprecyzyjne definicje ról (projekt systemu), ignorowanie przez jednego agenta informacji przekazanych przez innego (niezgodność między agentami) oraz ogłaszanie sukcesu bez sprawdzenia wyniku (brak weryfikacji). Te błędy wskazują na problemy z promptami, logiką orkiestracji i brakującymi kontrolami w harnessie. Lepszy model bazowy nie wykona kroku weryfikacji, który nigdy nie został zaimplementowany, dlatego cel ewaluacji musi obejmować także harness otaczający model.

Luka adopcyjna

Badanie LangChain State of Agent Engineering (1340 respondentów, przeprowadzone pod koniec 2025 r.) sugeruje, że wiele zespołów ma już surowe dane potrzebne do lepszych ewaluacji. Według badania 89% zespołów miało jakąś formę obserwowalności, 52,4% prowadziło ewaluacje offline, a 37,3% ewaluacje online.

Badanie podaje również, że 57,3% respondentów ma już agentów w produkcji. Na pytanie o bariery wdrożenia produkcyjnego 32% wskazało jakość, a 20% opóźnienia. To badanie dostawcy wśród jego respondentów, a nie spis wszystkich zespołów pracujących nad agentami, ale pokazuje użyteczną lukę między zbieraniem trace’ów a systematyczną ewaluacją.

Zespoły pozostają więc w niezręcznym stanie pośrednim: potrafią po fakcie przeanalizować nieudane uruchomienie, a mimo to dwukrotnie wdrażają ten sam błąd.

Każda zdiagnozowana awaria produkcyjna powinna pozostawić po sobie trace, etykietę, wiersz w datasecie i scorer. Powtarzalny błąd należy do zestawu regresyjnego.

Dobieraj metryki do trybu awarii

Właściwa metryka zależy od trybu awarii, a nie od frameworka. Przydatny podział obejmuje trzy poziomy:

1. Ewaluacje wyniku odpowiadają na pytanie, czy zadanie zakończyło się powodzeniem.
2. Ewaluacje trajektorii odpowiadają na pytanie, czy ścieżka była prawidłowa, efektywna i zgodna z polityką.
3. Ewaluacje komponentów odpowiadają na pytanie, które narzędzie, retriever, sub-agent lub krok decyzyjny uległ awarii.

Każdy poziom można uruchamiać offline na stałych, odtwarzalnych przypadkach przed wydaniem albo online na próbkowanych trace’ach produkcyjnych po udzieleniu odpowiedzi. Sekcja dotycząca guardrails szczegółowo omawia ten podział. Ewaluacje offline mogą wymagać goldenów: zapisanych przypadków, które łączą dane wejściowe z wynikiem, niezmiennikami narzędzi i argumentami, jakie musi wygenerować poprawne uruchomienie. Ewaluacje online powinny preferować niezmienniki, rozkłady i asynchroniczne kontrole, które pozostają poza ścieżką żądania.

Zacznij od metryk deterministycznych. Powtarzają się dla stałych danych wejściowych i kodu, a ich uruchamianie niewiele kosztuje. Ich reguły mogą jednak się zdezaktualizować po zmianie narzędzi lub polityki, dlatego wersjonuj scorer razem ze specyfikacją, którą sprawdza.

Poprawność wywołań narzędzi

Poprawność narzędzi porównuje wywołane narzędzia z narzędziami oczekiwanymi. Świadomie dobierz rygor:

• Dokładna zgodność: sekwencja musi być identyczna. Użyj jej, gdy kolejność wynika z polityki, na przykład lookup_order -> verify_identity -> issue_refund.
• Zgodność uporządkowana: wymagane narzędzia muszą wystąpić we właściwej kolejności względnej, ale dozwolone są dodatkowe, nieszkodliwe wywołania.
• Zgodność w dowolnej kolejności: wymagane narzędzia muszą wystąpić, ale ich kolejność może być różna.

Na początek wystarczy niewielki lokalny scorer:

from collections import Counter

def tool_correctness(called: list[str], expected: list[str], mode: str = "in_order") -> float:
    if mode not in {"exact", "in_order", "any_order"}:
        raise ValueError(f"unknown matching mode: {mode}")
    if mode == "exact":
        return float(called == expected)
    if not expected:
        return 1.0
    if mode == "any_order":
        matched = sum((Counter(called) & Counter(expected)).values())
        return matched / len(expected)

    rows = [[0] * (len(expected) + 1) for _ in range(len(called) + 1)]
    for i, tool in enumerate(called):
        for j, wanted in enumerate(expected):
            if tool == wanted:
                rows[i + 1][j + 1] = rows[i][j] + 1
            else:
                rows[i + 1][j + 1] = max(rows[i][j + 1], rows[i + 1][j])
    return rows[-1][-1] / len(expected)

called = ["lookup_order", "check_refund_policy", "issue_refund"]
expected = ["lookup_order", "verify_identity", "issue_refund"]

print(round(tool_correctness(called, expected, "exact"), 3))     # 0.0
print(round(tool_correctness(called, expected, "in_order"), 3))  # 0.667
assert tool_correctness(["issue_refund"], [], "exact") == 0.0
assert tool_correctness([], [], "exact") == 1.0
assert tool_correctness(["a", "b"], ["a", "a", "b"], "any_order") == 2 / 3
try:
    tool_correctness([], [], "typo")
except ValueError:
    pass
else:
    raise AssertionError("unknown modes must fail")

Wynik in_order to recall najdłuższego wspólnego podciągu: ułamek wymaganej sekwencji, który zachował się we właściwej kolejności. Zwróć uwagę, czego ta metryka nie uwzględnia. Wywołania śmieciowe nie obniżają wyniku, więc agent może uzyskać tutaj 1.0, wykonując jednocześnie dwa razy więcej wywołań, niż potrzebował. Gdy dodatkowe wywołania kosztują pieniądze lub mutują stan, śledź także precision (dopasowane wymagane wywołania podzielone przez całkowitą liczbę wywołań) i interpretuj obie wartości razem. Recall wykrywa brakujący krok, a precision wykrywa błądzenie. Ani recall równy 1.0, ani wysoka precision nie uprawniają do dodatkowych mutacji. Każde wywołanie zmieniające stan sprawdzaj pod kątem uprawnień, zasobu, argumentów i wymaganej wcześniejszej weryfikacji. Przy pustej liście oczekiwanej tylko tryb dokładny oznacza „nie wolno wykonywać żadnych wywołań”; pozostałe tryby nie mają pozytywnych wymagań.

Metryka Tool Correctness w DeepEval udostępnia te same parametry za pomocą should_consider_ordering i should_exact_match.

Poprawność argumentów

Wywołanie właściwego narzędzia z błędnymi argumentami jest często gorsze niż wywołanie niewłaściwego narzędzia, ponieważ trace wygląda wtedy normalnie.

W prostych przypadkach waliduj JSON Schema i dokładne wartości. W przypadkach semantycznych przechowuj oczekiwane argumenty i oceniaj różnice:

{
    "trace_id": "tr_2417",
    "input": "Reschedule order A-100 for June 19, 2026.",
    "expected_tools": ["lookup_order", "reschedule_delivery"],
    "expected_arguments": {
        "reschedule_delivery": {
            "order_id": "A-100",
            "date": "2026-06-19"
        }
    }
}

Metryka nazwy narzędzia nie wykryje 2026-06-17, gdy polityka wymaga 2026-06-19. Dataset musi przechowywać również argumenty.

W tym przykładzie z jednym wywołaniem każdego narzędzia parameter-match oznacza ułamek oczekiwanych trójek (tool, key, value), które agent dopasował poprawnie. Poniższe słowniki są poprawne wyłącznie wtedy, gdy każde istotne narzędzie jest wywoływane najwyżej raz. Nie twórz ich przez nadpisywanie wcześniejszych wywołań o tej samej nazwie: ukryłoby to błędny zwrot, po którym nastąpił poprawny. W przypadku powtarzających się wywołań zachowuj identyfikatory wywołań i kolejność, dopasowuj zamierzone wywołanie i osobno waliduj każdą mutację.

def argument_correctness(called_args: dict, expected_args: dict) -> float:
    total = matched = 0
    for tool, params in expected_args.items():
        for key, want in params.items():
            total += 1
            if key in called_args.get(tool, {}) and called_args[tool][key] == want:
                matched += 1
    return matched / total if total else 1.0

assert argument_correctness({}, {"reschedule_delivery": {"date": None}}) == 0.0
assert argument_correctness({"reschedule_delivery": {}},
                            {"reschedule_delivery": {"date": None}}) == 0.0
assert argument_correctness({"reschedule_delivery": {"date": None}},
                            {"reschedule_delivery": {"date": None}}) == 1.0

Równość dokładna jest właściwa dla ID, enumów i dat już znormalizowanych do jednego formatu. Nie sprawdza się dla wolnego tekstu, liczb zmiennoprzecinkowych i dat w dowolnym formacie generowanym przez model, gdzie == oznacza poprawną odpowiedź jako błędną. Oceniaj te pola zgodnie z ich charakterem: znormalizowane dopasowanie ciągu znaków, parsowanie daty, tolerancja numeryczna. Sama metryka pozostaje taka sama; zmienia się comparator dla konkretnego pola.

Efektywność, pętle i ślepe uliczki

Agent, który kończy zadanie po pięciu redundantnych wywołaniach narzędzi, nadal sygnalizuje problem z planowaniem i kosztuje więcej w uruchomieniu.

Na początek użyj niedrogich sygnałów:

• Wskaźnik redundantnych wywołań: identyczne wywołania narzędzi z identycznymi argumentami powtórzone więcej niż dwa razy.
• Anomalie kształtu trace’a: nagłe wzrosty głębokości, liczby wywołań narzędzi, liczby tokenów, opóźnienia lub kosztu.
• Zbieżność ścieżki: stopień podobieństwa uruchomienia do najkrótszej znanej poprawnej ścieżki dla danego zadania.
• Poprawność zakończenia: czy agent zatrzymał się zbyt wcześnie, kontynuował pracę po sukcesie albo ogłosił sukces bez wymaganej zmiany stanu.
• Zgodność z planem: jeśli agent zapisuje plan przed rozpoczęciem działania, sprawdź, czy trace za nim podążał. Dobry plan zignorowany oraz zły plan wykonany perfekcyjnie oznaczają niepowodzenie z przeciwnych powodów, a różnica między planem i trace’em mówi, z którym przypadkiem mamy do czynienia.

Uruchamiaj te kontrole przed judge’em, gdy tylko jest to możliwe. Detektor pętli to kilka linii działających na trace. Nie potrzebuje modelu.

Realizacja zadania i ocena wyniku

Przy ocenie wyniku pytanie brzmi: „czy użytkownik otrzymał to, o co prosił?”.

Najlepiej sprawdzają się dwa wzorce:

• Ocena realizacji zadania bez referencji: wyodrębnij cel z danych wejściowych i oceń, czy trace wraz z odpowiedzią końcową go osiągnął. Działa to online, ponieważ ruch produkcyjny rzadko ma wzorcowe odpowiedzi.
• Ocena stanu środowiska: porównaj końcowe rekordy bazy danych, pliki, zgłoszenia, rezerwacje lub inne rekordy z opatrzonym adnotacją stanem docelowym. Jest to bardziej odporne niż dopasowywanie transkrypcji, ponieważ agenci mogą znaleźć poprawne ścieżki, których nie zapisano wcześniej.

Druga opcja jest lepsza, jeśli możesz ją zbudować. Stan końcowy jest kontraktem. Transkrypcja jest tylko dowodem.

Dwa zastrzeżenia pomagają zachować rzetelność. Audyt benchmarków agentowych z 2025 r. wykazał, że tau-bench ocenia niektóre zadania wyłącznie na podstawie stanu bazy danych. W części zadań opatrzony adnotacją wynik nie wymaga żadnej zmiany stanu ani konkretnego tekstu. Agent, który nic nie robi, może wtedy uzyskać zaliczenie: 38% w podziale lotniczym i 6,0% w detalicznym, przy dowolnym k. Anthropic poinformował o uruchomieniu Opus 4.5, które „nie zdało” zadania rezerwacji w tau2-bench, będącym następcą benchmarku. Agent znalazł lukę w polityce, która w rzeczywistości prowadziła do lepszego wyniku dla użytkownika. Ocena stanu jest lepsza niż dopasowywanie transkrypcji, ale stan docelowy nadal jest adnotacją, a adnotacje mogą zawierać błędy. Audytuj przypadki, które zbyt łatwo przechodzą, a nie tylko te, które kończą się niepowodzeniem.

Wersje benchmarków i środowiska zmieniają wynik

Przytoczone wcześniej oryginalne wyniki tau-bench wyjaśniają niezawodność w wielokrotnych próbach; nie są aktualnym rankingiem modeli. Utrzymywane repozytorium tau-bench prezentuje obecnie tau3-bench, które dodaje wyszukiwanie wiedzy i głos full-duplex. Poprawka oceniania z lipca 2026 r. w wersji 1.0.1 zmienia wyniki banking_knowledge: wyników z wcześniejszych wersji nie można porównywać dla tej domeny. Przypinaj wersje zadań i graderów tak samo jak model, a zapisane trajektorie oceniaj ponownie po korekcie adnotacji.

Wybierz benchmark, który odwzorowuje wdrażany interfejs. Testy obsługi klienta wyłącznie tekstowej nie mogą potwierdzić obsługi przerwań w agencie głosowym. Zadania z wyszukiwaniem wiedzy wymagają również korpusu, konfiguracji wyszukiwania i dowodów dostępnych w każdej turze. Wykorzystaj te kształty zadań do tworzenia lokalnych przypadków regresyjnych, zamiast importować pozycję w publicznym rankingu jako kryterium wydania.

Sandbox również jest częścią testu. Badanie infrastruktury Anthropic z lutego 2026 r. wykazało różnicę sześciu punktów procentowych w Terminal-Bench 2.0 między ścisłą i nieograniczoną konfiguracją zasobów przy tym samym modelu, harnessie i zadaniach. Większy zapas zasobów ograniczył liczbę awarii infrastruktury i umożliwił inne strategie rozwiązywania. Rejestruj gwarancje i limity CPU oraz RAM, timeouty, współbieżność, dostęp do sieci i sposób obsługi błędów infrastruktury. Raportuj te awarie osobno, nie usuwając ich po cichu z mianownika oczekiwanych zadań.

Ewaluacje komponentów

Metryki wyniku i trajektorii mówią, że uruchomienie się nie powiodło i mniej więcej gdzie. Ewaluacje komponentów oceniają pojedynczy span: czy znaleziony fragment był trafny, czy sub-agent zwrócił schemat oczekiwany przez wywołującego, czy odpowiedź narzędzia dała się sparsować. Przypisz wynik do spanu, a nie do całego uruchomienia, dzięki czemu pytanie „które narzędzie pogorszyło się w tym tygodniu” nie wymaga ponownego uruchamiania testów.

Większość problemów obejmują trzy kontrole:

• Ocena per span: uruchom metrykę odpowiednią dla typu spanu. Spany retrieval otrzymują recall i precision względem opatrzonego adnotacją fragmentu, spany sub-agentów — walidację schematu i własny wynik poprawności narzędzi, a spany narzędzi — wskaźnik błędów i opóźnienie.
• Interpretacja wyników narzędzi: podaj agentowi poprawny, ale nietypowy wynik narzędzia (pustą listę, częściowe dopasowanie, nieaktualny timestamp) i sprawdź, co zrobi dalej. Narzędzie może działać poprawnie, a agent może błędnie odczytać jego wynik; awaria ujawni się wtedy dopiero dwa kroki później.
• Atrybucja awarii: widoczna awaria zwykle następuje po rzeczywistej przyczynie. Przypisz ją najwcześniejszemu spanowi, którego wynik był już błędny, a nie krokowi, który zgłosił błąd.

W tym miejscu wraca matematyka kumulacji z początku artykułu. Jeśli 20 kroków wygląda dobrze w izolacji, całe uruchomienie nadal może kończyć się niepowodzeniem przez większość czasu. Wskaźniki powodzenia per span pokazują, który krok działa z niezawodnością 95%, a który z 70%.

Pętla trace-to-eval

Zanim zaczniesz wymyślać kolejne przypadki ewaluacyjne, wydobądź awarie produkcyjne.

Pętla wygląda następująco:

1. Zbierz wystarczające dowody z trace’a, aby odtworzyć awarię, kontrolując wrażliwe treści.
2. Oznacz, co się zepsuło.
3. Grupuj podobne awarie.
4. Zachowaj reprezentatywne goldeny, w tym warianty wymagające różnych wyników.
5. Wersjonuj dataset.
6. Uruchamiaj go w CI.
7. Kontynuuj online ocenianie próbkowanych trace’ów produkcyjnych.

Repozytorium towarzyszące trace2evals implementuje pełną pętlę dla wadliwego agenta wsparcia. Rejestruje spany OpenTelemetry GenAI, wykrywa awarie za pomocą deterministycznych reguł, deduplikuje przypadki do wersjonowanego golden datasetu i ponownie uruchamia każdy golden w CI. Domyślny backend zastępuje model deterministycznymi regułami, które odtwarzają decyzje wadliwego agenta, więc make demo odtwarza całą pętlę offline bez klucza API. Uruchom uv sync --extra live i ustaw klucz API, a te same polecenia będą sterować rzeczywistym modelem.

To pipeline edukacyjny. Wersja zrecenzowana 6 września 2026 r. nadal ma przypadki brzegowe w scorerach, kontrole autoryzacji oparte na nazwach i współdzielony stan prób. Adapter trace’ów oczekuje własnych atrybutów spanów i kształtów wiadomości. Poprawione przykłady w tym artykule nie aktualizują tego repozytorium ani nie ustanawiają produkcyjnej autoryzacji; przed poleganiem na wynikach CI zwaliduj każdą pomyślną mutację pod kątem autoryzacji związanej z zasobem i odizoluj próby.

Wyszukuj awarie za pomocą analizy błędów

Przewodnik terenowy Hamela pokazuje następujący workflow: analizuj rzeczywiste rozmowy, rób otwarte notatki, kategoryzuj awarie i buduj konkretne testy.

1. Analizuj trace’y i rób otwarte notatki na temat tego, co poszło nie tak.
2. Grupuj powtarzające się awarie w nazwane kategorie.
3. Oznaczaj trace’y zgodnie z tą taksonomią.
4. Buduj konkretne testy dla największych klastrów, dla których można podjąć działanie.

Nie zaczynaj od etykiet takich jak reasoning_issue lub tool_problem. Są zbyt ogólne, aby dało się je testować. Używaj etykiet takich jak missing_identity_verification, date_argument_mismatch, retried_same_tool_after_429 lub stopped_before_database_update. Tak konkretna etykieta mówi dokładnie, co powinien asertować test regresyjny.

Deduplikuj przed awansem do zestawu

Pętla wydobywania trace’ów ma pułapkę: dodawanie na zawsze każdego błędnego trace’a. Powstaje wtedy dataset duży, kosztowny i wąski. Przechodzi on dla niemal identycznych przypadków z marca, a nie wykrywa nowej postaci tego samego błędu w czerwcu.

Najpierw grupuj. Zacznij od jednego reprezentatywnego goldena na klaster, a następnie zachowaj warianty z różnymi uprawnieniami, argumentami, stanami odzyskiwania lub oczekiwanymi wynikami. Podobne sformułowanie nie oznacza, że dwa przypadki polityki są równoważne. Powiązane identyfikatory trace’ów przechowuj w metadanych z kontrolą dostępu, aby recenzent mógł później przejrzeć dowody.

Jeśli klaster awarii powraca po poprawce, przypadek regresyjny nie uogólnił się. Wróć do klastra i dodaj brakujące warianty zachowania, zamiast gromadzić niemal identyczne transkrypcje.

Wersjonuj dataset

Wersjonuj datasety tak samo jak prompty i kod. Za każdym razem, gdy zmienia się coś istotnego (model, prompt, schemat narzędzia, prompt judge’a lub zachowanie aplikacji), chcesz uruchomić tę samą wersję datasetu przed zmianą i po niej.

Kontrola CI powinna przypinać:

• wersję datasetu
• wersję aplikacji
• wersję promptu
• model judge’a
• prompt judge’a
• wersję kodu ewaluatora
• schematy narzędzi, politykę, harness i konfigurację zarządzania kontekstem
• rewizję modelu, ustawienia rozumowania i samplingu
• początkowy fixture środowiska i dozwolone efekty zewnętrzne

Jeśli którykolwiek z tych elementów się zmieni, porównanie przed/po staje się niejasne. Plik goldens-v3.json w git wystarczy na małą skalę. Natywne dla narzędzi snapshoty w Langfuse, Phoenix, Braintrust lub LangSmith pomagają, gdy dataset staje się współdzielony.

Trzymaj osobno regresje deweloperskie, przykłady do kalibracji judge’a, walidację odłożoną i próbki monitoringu. Grupuj powiązane sesje, użytkowników i zadania przed podziałem, aby niemal identyczne przypadki nie przedostały się między zbiorami. Gdy przypadek wpływa na prompt lub rubric, traktuj go jako dane deweloperskie. Zestaw wydobytych awarii testuje znane regresje; jego średnia nie szacuje wskaźnika sukcesu produkcyjnego.

Resetuj mutowalny stan dla każdej próby: pliki, rekordy bazy danych, cache i fixture’y narzędzi. Izoluj poświadczenia i efekty zewnętrzne, a budżety kandydata i baseline’u utrzymuj na równym poziomie. Raportuj liczbę zadań osobno od liczby prób, wraz ze wszystkimi rozpoczętymi próbami, timeoutami, crashami i nieskalowalnymi wynikami. Porównuj sparowane wyniki na tych samych zadaniach. Zasady te wynikają z podejścia do czystych prób i oceny wyniku opisanego w przewodniku ewaluacji Anthropic.

Uruchamiaj ewaluacje w CI

Kontrola wydania musi przerwać build, gdy metryka przekroczy uzgodniony limit. W przeciwnym razie zestaw ewaluacyjny jest tylko dashboardem.

Po przywróceniu fixture’a przypadku w izolowanej próbie test powinien ponownie uruchomić bieżącego agenta na wejściu goldena. Nie powinien jedynie odtwarzać starego, nieudanego trace’a (szkic; wersja uruchamialna znajduje się w repozytorium towarzyszącym):

@pytest.mark.parametrize("golden", GOLDENS, ids=[item["id"] for item in GOLDENS])
def test_agent_regression(golden: dict) -> None:
    answer, fresh_trace = run_agent_and_capture_trace(golden["input"])

    refired = set(flag_failures(fresh_trace)) & set(golden["failure_modes"])
    assert not refired, f"failure mode regressed: {sorted(refired)}"

    assert tool_correctness(
        called=[call["name"] for call in fresh_trace["tool_calls"]],
        expected=golden["expected_tools"],
        mode=golden.get("tool_match", "in_order"),
    ) >= golden.get("tool_threshold", 1.0)

Łatwo pomylić te dwie rzeczy. Zadaniem datasetu jest wykrycie, że kolejna wersja agenta powtarza starą awarię, a nie archiwizowanie samej awarii.

Skalibruj judge’a, zanim zaczniesz mu ufać

LLM-as-judge pomaga. Łatwo jednak oszukać samego siebie.

G-Eval ocenia trzy benchmarki meta-ewaluacyjne. Są to SummEval, zbudowany na podstawie podsumowań wiadomości CNN/DailyMail; Topical-Chat, benchmark dialogów opartych na wiedzy; oraz QAGS, który testuje spójność faktograficzną podsumowań CNN/DailyMail i XSum. Przy użyciu GPT-4 jako backbone’u G-Eval-4 osiągnął korelację Spearmana równą 0,514 z ocenami ludzi w SummEval. Funkcja scoringowa waży poziomy ocen według prawdopodobieństwa tokenów ($\text{score} = \sum_i p(s_i)\,s_i$).

W artykule oszacowano prawdopodobieństwa tokenów GPT-4 przez 20-krotne samplowanie, ponieważ ten model nie udostępniał ich w eksperymencie. Hostowany model może nie udostępniać użytecznych logprobs, dlatego zachowaj rubric, ale nie sugeruj, że odtworzyłeś ważenie prawdopodobieństw z artykułu. Wyniki te porównują protokół z artykułu z jego baseline’ami NLG na tych benchmarkach. Uzasadniają testowanie judge’a z jawnym rubric, ale nie stanowią podstawy do zastąpienia metryk automatycznych ani benchmarku trajektorii agentów produkcyjnych.

MT-Bench pokazał, że GPT-4 zgadzał się z preferencjami ludzi mniej więcej tak często, jak ludzie zgadzają się ze sobą nawzajem. Wynik ten pomógł spopularyzować ocenianie przez LLM. Późniejsze prace ujawniły uprzedzenia związane z pozycją, długością i preferowaniem własnych odpowiedzi. Wyniki judge’a mogą również zmieniać się po zmianie promptu lub wersji modelu.

JudgeBench zbudował pary odpowiedzi, w których jedna odpowiedź jest obiektywnie błędna w zakresie weryfikowalnej wiedzy, rozumowania, matematyki i kodu. Przy prostym prompcie judge’a GPT-4o osiągnął 50,9%, czyli ledwie więcej niż rzut monetą; silniejszy prompt Arena-Hard z artykułu podniósł wynik tego samego modelu tylko do 56,6%. Zmiana modelu przy tym silniejszym prompcie ma większe znaczenie: Claude 3.5 Sonnet, najlepszy testowany judge ogólnego przeznaczenia, osiągnął 64,3%, a o3-mini przy wysokim wysiłku rozumowania — 80,9%. Pewne siebie, ale błędne odpowiedzi pozostają trudne do wykrycia przez judge’a, który nie rozumuje przed oceną.

Traktuj judge’a jak przyrząd pomiarowy: skalibruj go względem etykiet nadanych przez ludzi, zanim zacznie cokolwiek oceniać, i sprawdzaj ponownie po każdej zmianie modelu lub promptu judge’a.

Gdy judge jest niezbędny, ustrukturyzuj werdykt. Schema-Guided Reasoning (SGR) nadaje werdyktowi schemat kształtu danych wyjściowych i ich kontroli. Structured Outputs lub constrained decoding mogą wymusić kształt obiektu, wymagane pola i ograniczenia wartości dla pól takich jak evidence, passed_criteria, failed_criteria, failure_mode i score.

Umieść pola z dowodami przed wynikiem, jeśli ułatwia to inspekcję rekordu. Kolejność pól jest kwestią prezentacji, a nie gwarancją rozumowania. Werdykt poprawny względem schematu nadal może zawierać niepoparte dowody lub niewiarygodny wynik. Używaj kalibracji względem etykiet ludzi, deterministycznych walidatorów i przeglądu transkrypcji do testowania niezawodności judge’a. CI może porównywać stabilny obiekt JSON, ale sprawdza to kontrolowalność i kształt, a nie dowodzi, że etapy rubric zostały wykonane.

Ustrukturyzowany werdykt może również zmienić krzywą kosztu. Traktuj tańszy model jako kandydata, a nie automatyczny zamiennik. Uruchom go na tym samym, oznaczonym przez ludzi zbiorze kalibracyjnym. Porównaj zgodność, wskaźnik false-pass i wskaźnik false-fail z większym judge’em. Używaj go do rutynowych przypadków tylko wtedy, gdy przekroczy ustalone przez aplikację progi. Większego judge’a zachowaj dla rozbieżności, przypadków wysokiego ryzyka i przebiegów kalibracyjnych.

Domyślna lista kontrolna higieny judge’a:

1. Jeśli to możliwe, preferuj binarne pass/fail. Skale pięciopunktowe zachęcają do pozornej precyzji.
2. Przed finalizacją rubric oznacz trajektorie obejmujące rzeczywiste tryby awarii. Dobierz wielkość próby do zakresu pokrycia i niepewności, którą decyzja może tolerować, a następnie zachowaj osobne przypadki do walidacji.
3. Mierz zgodność judge’a z ludźmi za pomocą kappa Cohena, macierzy pomyłek oraz recall dla klas pozytywnej i negatywnej. Kappa mierzy zgodność po uwzględnieniu zgodności oczekiwanej losowo; wyższa wartość jest lepsza. Judge, który zawsze odpowiada „pass”, nie ma użytecznej zdolności rozróżniania, więc kappa może wynosić zero lub być niezdefiniowana. Zdecyduj, co zrobić w przypadku wartości niezdefiniowanej, zanim użyjesz tej metryki do zatwierdzania wydania.
4. Rozbijaj ogólne kryteria. „Czy agent zweryfikował tożsamość przed wywołaniem narzędzia zwrotu?” jest lepsze niż „Czy trajektoria była dobra?”.
5. Emituj werdykt przez schemat SGR zawierający dowody, niespełnione kryteria, tryb awarii i wynik.
6. Porównuj judge’ów z tej samej rodziny i z różnych rodzin względem odłożonych etykiet ludzi; sama separacja rodzin nie dowodzi niezawodności.
7. Mierz wrażliwość na kolejność par. Zachowaj randomizację lub agregację po zamianie kolejności tylko wtedy, gdy poprawia ona decyzje na odłożonych danych; kontrolowane badanie z 2026 r. wykazało, że zamiana może szkodzić w przypadkach adwersarialnych.
8. Nie przyznawaj punktów za dodatkowy tekst, chyba że dodaje poprawną, istotną i popartą treść. Dłuższa odpowiedź nie jest lepsza.
9. Przypinaj model judge’a, prompt, dataset, schemat i wersję aplikacji.
10. Ponownie kalibruj po zmianach modelu, promptu, narzędzi, polityki lub schematu.

Panel jest kolejnym kandydatem do przetestowania. PoLL raportował lepszą zgodność z ocenami ludzi, mniejsze uprzedzenie wewnątrzmodelowe i niższy koszt niż baseline oparty na pojedynczym GPT-4 w sześciu datasetach. Wyniki te dotyczą użytych modeli, zadań i historycznych cen. Nie dowodzą, że panel będzie bezpieczniejszy w Twoim zadaniu. Porównaj jego false-pass, false-fail, koszt i obciążenie związane z rozbieżnościami z jednym skalibrowanym judge’em na odłożonych etykietach.

Nie ma uniwersalnego progu kappa, który czyni judge’a odpowiednim do CI. Raportuj macierz pomyłek, liczebności etykiet, false-pass wśród ludzkich błędów oraz false-fail wśród ludzkich sukcesów, wraz z niepewnością. Limity wydań dobieraj do konsekwencji tych błędów. Używaj kolejek do przeglądu, gdy dowody są zbyt słabe do automatycznej akceptacji, i zachowaj autoryzację człowieka dla działań o istotnych konsekwencjach, jeśli workflow jej wymaga.

Guardrails blokują inline, a ewaluacje online obserwują później

Ludzie mylą te mechanizmy, ponieważ oba generują wyniki. Różnica dotyczy miejsca działania: inline w ścieżce żądania, przed wydaniem albo po odpowiedzi.

Guardrails działają inline. Są szybkie i widoczne dla użytkownika. Guardrail może zablokować wywołanie narzędzia, zredagować PII, odrzucić prompt injection albo wymusić ponowienie próby, zanim odpowiedź opuści system. False positive jest błędem produkcyjnym. False negative jest cichszy i gorszy, ponieważ ścieżka żądania go nie zgłasza. Kontrole schematu, zakresu i polityki są deterministyczne. Wykrywanie injection i PII opiera się na classifierach, dlatego traktuj przeoczenia jako oczekiwane i uruchom asynchroniczną ewaluację monitorującą to, co przepuszczają.

Ewaluacje offline uruchamia się przed wydaniem. Są powtarzalne. Sprawdzają prompty, modele, narzędzia, retrievery i polityki na stałym datasecie.

Ewaluacje online uruchamia się po odpowiedzi, zwykle na próbkowanym ruchu. Mogą korzystać z wolniejszych judge’ów LLM, ponieważ nie znajdują się na ścieżce opóźnienia. Ich zadaniem jest wykrywanie driftu, znajdowanie nowych klastrów awarii i zasilanie kolejnego datasetu offline.

Niewłaściwe umiejscowienie szkodzi w obu kierunkach:

• Judge w ścieżce żądania zwiększa opóźnienie i wprowadza nowe źródło niestabilności.
• Guardrail ograniczony do asynchronicznego scoringu pozwala, aby naruszenia polityki dotarły do użytkowników.

W przypadku testów bezpieczeństwa rozróżniaj wykrycie ataku, próbę wykonania działania zabronionego oraz faktyczne powodzenie szkodliwego efektu. Raportuj liczbę udanych szkodliwych efektów na próbę ataku, wraz z modelem zagrożeń i budżetem prób, a także sukcesy prawidłowych zadań i false blocks na próbę benign, jako osobne wartości. Sam wynik detektora nie może potwierdzić, że dane pozostały prywatne ani że zapis został zablokowany. Używaj izolowanych celów; raport incydentu ewaluacji cyberbezpieczeństwa Anthropic pokazuje, dlaczego efekty ewaluacji wymagają odizolowania.

W systemach o dużym wolumenie oceniaj małą próbkę silniejszym judge’em, a większą próbkę tańszymi classifierami. Alarmuj na podstawie klastrów i przedziałów ufności, a nie pojedynczego zaszumionego oszacowania punktowego.

Wybór narzędzi

Żadne pojedyncze narzędzie nie obsługuje całej pętli. Osobno porównuj store trace’ów/datasetów i runner CI/ewaluacji; jeden produkt może obejmować oba obszary, ale nie musisz kupować obu od jednego dostawcy.

To zestawienie autora sprawdzone 6 września 2026 r. Każdy link prowadzi do aktualnej dokumentacji wykorzystanej dla danego twierdzenia o możliwościach. Nadal obowiązują plany, licencje, klucze API, dostęp do providerów i wymagania infrastrukturalne.

Uwagi dotyczące kompromisów opisują źródła kosztów, a nie ich wysokość. Strony cenników się zmieniają, a dostawcy liczą różne elementy: trace’y, obserwacje, spany, wyniki, użytkowników, retencję lub przetworzone dane. Przed podjęciem decyzji sprawdź aktualny cennik.

Rekomendacje zależnie od ograniczeń:

• Wybierz Phoenix, gdy self-hosting, prywatność i tracing zgodny z OTel są wymaganiami twardymi, a zespół może obsługiwać wdrożenie.
• Wybierz Langfuse, gdy potrzebujesz również wersjonowania datasetów i eksperymentów oraz możesz obsługiwać jego warstwę storage albo kupić wymagane dodatki.
• Wybierz DeepEval, gdy podstawowym kontraktem jest pass/fail w CI opartym na Pythonie/pytest.
• Wybierz Inspect AI, gdy głównym zadaniem jest ewaluacja bezpieczeństwa lub agentów frontier w konfigurowalnych sandboxach.
• Wybierz LangSmith, gdy integracja z LangChain/LangGraph pasuje do Twojego workflow; korzystaj z Cloud albo uwzględnij wymóg Enterprise dla hostingu platformy BYOC lub self-hosted.
• Wybierz Braintrust, gdy zarządzany feedback do pull requestów i porównywanie eksperymentów uzasadniają usługę opartą na kluczu API.
• Wybierz Promptfoo, gdy główną powierzchnią regresji są kontrole promptów lub red-teamingu, a store trace’ów jest poza zakresem.

Wybór narzędzia jest drugorzędny. Jeśli awarie produkcyjne nie stają się przypadkami testowymi, w większości płacisz za przechowywanie trace’ów.

Praktyczna lista kontrolna wdrożenia

Zbuduj pipeline dowodowy, zanim rozbudujesz stos metryk. Zacznij od ustalenia, skąd będą pochodzić przykłady.

1. Najpierw zbierz historyczne uruchomienia. Jeśli agent już istnieje, pobierz trace’y, zgłoszenia do supportu, raporty błędów, sesje z oceną thumbs-down, transkrypcje ręcznego QA i notatki z dogfoodingu, zanim zmienisz implementację. Jeśli agenta jeszcze nie ma, loguj każde uruchomienie prototypu i testu ręcznego od pierwszego dnia.

2. Oprzyrządkuj kształt trace’a. Przechwytuj wiadomości, wywołania narzędzi, argumenty, wyniki narzędzi, błędy, liczbę tokenów, opóźnienie, koszt, feedback użytkownika, wersję aplikacji, wersję promptu, wersję modelu, wersję schematu narzędzi i końcowy stan środowiska. Używaj konwencji OpenTelemetry GenAI lub spanów w stylu OpenInference, jeśli zależy Ci na przenośności, i przypnij wersję konwencji oraz adaptera. Przechwytuj treść selektywnie: redaguj sekrety i dane osobowe, ogranicz dostęp i ustal retencję przed awansem trace’ów do datasetów. Użyj Langfuse, LangSmith, Phoenix lub Braintrust, jeśli od razu potrzebujesz interfejsu trace’ów i workflow datasetów.

3. Przekształć rzeczywiste awarie w przypadki startowe. Przeczytaj trace’y przed ich podsumowaniem przez model. Dla każdej użytecznej awarii przechowuj dane wejściowe, identyfikator źródłowego trace’a, oczekiwany stan, oczekiwane niezmienniki narzędzi, tryb awarii, ważność i notatkę recenzenta. Langfuse może łączyć elementy datasetu z trace’ami produkcyjnymi; LangSmith może tworzyć datasety ze śledzonych uruchomień. Zachowaj link źródłowy, aby przypadek pozostał audytowalny.

4. Jeśli nie masz historii, wygeneruj przypadki cold-start. Poproś LLM o przygotowanie zadań na podstawie wymagań produktu, polityk, schematów narzędzi, automatów stanów i makr supportu. Uwzględnij ścieżki poprawne oraz awarie, takie jak błędne uprawnienia, brak kontroli tożsamości, nieaktualne wyniki narzędzi, niejednoznaczne daty, ponowienia po limitach rate limit oraz sprzeczne wyniki narzędzi.

5. Nie ufaj przypadkom syntetycznym bez przeglądu człowieka. Przykłady syntetyczne są użyteczne dla pokrycia, ale nie stanowią prawdy. Oznacz je za pomocą source: synthetic i wymagaj zatwierdzenia oczekiwanego wyniku przez recenzenta. Jeśli to możliwe, uruchom ścieżkę referencyjną, o której wiesz, że jest poprawna, i niezależnie zwaliduj wygenerowane oczekiwania; użycie innej rodziny modeli nie zastępuje tej kontroli.

6. Zbuduj mały, zbalansowany dataset. Uwzględnij sukcesy, awarie, odmowy, przypadki graniczne, przypadki wieloturowe, przypadki wrażliwe z perspektywy polityki oraz poprawne ścieżki alternatywne. Nie twórz goldena jako „dokładnej starej transkrypcji”. Przechowuj to, co przechowuje golden powyżej, a także tryb awarii, który umieścił przypadek w zestawie.

7. Najpierw dodaj kontrole deterministyczne. Wymagana kolejność narzędzi tam, gdzie jest narzucona polityką, wymagane argumenty, walidacja schematu, różnice stanu końcowego, limity pętli, limity tokenów i opóźnienia oraz niezmienniki specyficzne dla zadania powinny działać przed każdym judge’em.

8. Dodaj jednego judge’a o kształcie SGR. Używaj go wyłącznie do części wymagającej interpretacji. Skalibruj go względem etykiet ludzi i przetestuj wybrany rubric na nietkniętych przypadkach walidacyjnych. Jeśli nie potrafi rozdzielić dobrych i złych przykładów na zbiorze kalibracyjnym, popraw rubric przed podłączeniem go do CI.

9. Połącz pętlę. Uruchamiaj mały zestaw offline w CI, większy zestaw przed wydaniem, oceniaj online próbkowany ruch produkcyjny i przenoś powtarzające się klastry awarii online z powrotem do datasetu offline.

Pierwszy zestaw ewaluacyjny będzie pomijał pewne przypadki. Uruchom go mimo to, a następnie dodawaj powtarzające się awarie jako przypadki. Zestaw uruchamiany codziennie dostarcza dowodów potrzebnych do jego ulepszania.

Referencje

• repozytorium demonstracyjne trace2evals
• LangChain — State of Agent Engineering
• Anthropic — Demystifying Evals for AI Agents
• Hamel Husain — A Field Guide to Rapidly Improving AI Products
• Konwencje semantyczne OpenTelemetry dla systemów generative AI
• DeepEval Tool Correctness
• DeepEval Task Completion
• DeepEval unit testing in CI/CD
• Inspect running evals
• OpenAI Structured model outputs
• Schema-Guided Reasoning: vLLM, xgrammar, and Pydantic
• Phoenix self-hosting
• Langfuse datasets and versioning
• Langfuse experiments in CI/CD
• LangSmith platform setup
• LangSmith — Create and manage datasets programmatically
• Braintrust — Create experiments
• Phoenix LLM evals
• Promptfoo GitHub Action integration
• tau-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains
• Why Do Multi-Agent LLM Systems Fail?
• Establishing Best Practices for Building Rigorous Agentic Benchmarks
• G-Eval: NLG Evaluation using GPT-4 with Better Human Alignment
• Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena
• Replacing Judges with Juries: Evaluating LLM Generations with a Panel of Diverse Models
• JudgeBench: A Benchmark for Evaluating LLM-based Judges
• Self-Preference Bias in LLM-as-a-Judge