Twoje ewaluacje też są niestabilne: Przestań ufać wskaźnikowi zaliczeń, którego nie potrafisz odtworzyć

Większość ludzi wie, że agenci AI są niedeterministyczni. Wysyłasz ten sam prompt, ale otrzymujesz różne wyniki.

Zaakceptowaliśmy to. Zaczęliśmy używać modeli LLM jako sędziów do oceniania tych agentów.

Ale popełniliśmy ogromny błąd. Założyliśmy, że nasi sędziowie są deterministyczni. Nie są.

Twój zestaw ewaluacyjny to losowy system oceniający inny losowy system. Jeśli nie mierzysz, jak bardzo Twój sędzia się waha, nie masz bramki jakościowej. Masz rzut monetą.

Widziałem to na przykładzie agenta wsparcia. Dashboard pozostawał zielony przez tygodnie. Potem liczba skarg klientów gwałtownie wzrosła. Przeprowadziłem tę samą ewaluację na 200 starych odpowiedziach. 14 z nich zmieniło swój werdykt. Agent się nie zmienił. To sędzia zmienił zdanie.

Niestabilna bramka jest gorsza niż jej brak. Daje Ci fałszywe poczucie pewności.

Istnieją trzy powody, dla których Twoje ewaluacje zawodzą:

  • Model sędziego: Każdy sędzia LLM wykazuje zmienność. Nawet przy temperaturze 0 dostawcy nie gwarantują tego samego wyniku. Cicha aktualizacja modelu może z dnia na dzień zniszczyć Twój baseline.
  • Środowisko (harness): Jeśli kontekst lub wyjścia narzędzi zmieniają się między uruchomieniami, sędzia widzi inne pytanie. Dane wejściowe uległy dryfowi.
  • Kryteria (rubric): Niejasne zasady typu „czy to jest dobre?” tworzą zmienność. Ścisłe, konkretne zasady ją redukują.

Musisz traktować niestabilne ewaluacje tak samo jak niestabilne testy oprogramowania. Nie wdrażaj ich. Kwarantannuj je. Mierz wskaźnik niestabilności (flake rate).

Przestań raportować pojedynczy wskaźnik zaliczeń. Zacznij raportować zgodność.

Uruchamiaj każde wywołanie sędziego wielokrotnie. Jeśli sędzia nie potrafi dojść do porozumienia z samym sobą, werdykt nie jest sygnałem. Jest UNSTABLE.

Wynik UNSTABLE powinien być traktowany jako pełnoprawny rezultat w Twoim potoku CI/CD. Powinien głośno sygnalizować błąd.

Aby naprawić niestabilną ewaluację, potrzebujesz dwóch rzeczy:

  1. Warstwy punktacji (scoring layer): Oblicza ona stabilność i zamienia wyniki na PASS, FAIL lub UNSTABLE.
  2. Warstwy śledzenia (tracing layer): Musisz widzieć surowe bajty, dokładny prompt i wyjścia narzędzi dla każdego uruchomienia.

Bez śladów (traces) będziesz myśleć, że model jest po prostu losowy. Obniżysz temperaturę i uznasz, że naprawiłeś problem. Nie naprawiłeś go. Po prostu sprawiłeś, że błąd stał się cichszy.

Przestrzegaj tych zasad, aby budować prawdziwą jakość:

  • Raportuj zgodność, a nie tylko średnie.
  • Spraw, aby UNSTABLE było stanem błędu w Twoim potoku.
  • Przypnij (pin) konkretne wersje modeli sędziów.
  • Czytaj ślady (traces), gdy sprawdzenie zakończy się niepowodzeniem.

Zielony dashboard, którego nie potrafisz odtworzyć, nie jest sygnałem. To historia, którą opowiadasz samemu sobie.

Source: https://dev.to/saurav_bhattacharya/your-evals-are-flaky-too-stop-trusting-a-pass-rate-you-cant-reproduce-6pk

Optional learning community: https://t.me/GyaanSetuAi