LLM-as-a-Judge w praktyce
Od pytania „czy model odpowiada dobrze" do pipeline'u, w którym dwa agenty piszą kod, sędzia z innego modelu wybiera, a ja liczę, ile decyzji po drodze nie podjął nikt.
Seria o jednym pytaniu: czy można pozwolić modelowi decydować. Zaczyna się od tego, jak w ogóle mierzyć odpowiedzi LLM-a, potem daje sędziemu władzę nad kodem dwóch agentów, a od trzeciej części każdy wpis jest eksperymentem z liczbami: przewidywania zapisane przed startem, rejestr przebiegów, wynik, także wtedy, gdy przewidywanie padło.
Czytać po kolei. Każda część zakłada poprzednią, a pipeline, na którym to wszystko chodzi, rośnie z wpisu na wpis.
Jak sprawdzić, czy LLM odpowiada dobrze?
Wyobraź sobie, że masz ocenić pracownika, który jednego dnia pisze wiersz, drugiego rozwiązuje równanie, a trzeciego tłumaczy z japońskiego. Jedną skalą? Powodzenia.
Sędzia, który podejmuje decyzje
Tam zbudowaliśmy sędziego. Tu dajemy mu władzę — i patrzymy, co może pójść nie tak.
Przyłapałem własny pipeline AI na ściąganiu. A potem zmierzyłem, czego LLM-as-a-Judge nie widzi
Osiem przebiegów, dwóch agentów, sędzia z podwójnym przejściem i człowiek na końcu. Wszystkie testy zielone. Po drodze: worker kopiujący rozwiązania z sąsiednich zadań, trzy sprzeczne interpretacje jednego zdania specu i licznik decyzji, których nie podjął nikt.
Napisałem zadanie porządnie. Sędzia cztery razy ogłosił remis
Te same agenty, ten sam sędzia, zmienia się tylko opis zadania. Osiem rozwiązań, wszystkie poprawne, sędzia nie ma czego rozstrzygać. A potem znajduję zamówienie, na którym różnią się o sto złotych.
