- Kryteria sukcesu zapisane przed uruchomieniem chronią przed dopasowywaniem oceny do wyniku.
- Dobre kryterium jest konkretne, mierzalne i dotyczy twojego zadania, a nie ogólnej sprawności modelu.
- Ranking mówi o modelu, własny zestaw przykładów mówi o twojej aplikacji.
Kiedy model odpowie dobrze na trzy pytania, które mu zadam, łatwo uwierzyć, że działa. Ten esej broni prostej dyscypliny: najpierw zapisz, co znaczy „dobrze”, potem uruchom. To nudna kolejność, ale chroni przed najczęstszym błędem oceny, czyli dopasowaniem kryterium do wyniku, który już widzę.
Dlaczego kolejność ma znaczenie
Jeśli oceniasz po uruchomieniu, każdy wynik da się obronić. Odpowiedź ładna, ale niepełna, wydaje się „prawie dobra”. Odpowiedź błędna w szczególe wygląda na „drobną usterkę”. Dokumentacja Anthropic o definiowaniu kryteriów sukcesu opisuje je jako cechy konkretne, mierzalne i osiągalne, dotyczące zadania, a nie ogólne hasła. Zapis przed uruchomieniem sprawia, że ocena przestaje zależeć od nastroju.
Jak wygląda dobre kryterium
Złe kryterium brzmi „odpowiedzi mają być dobre”. Dobre brzmi: „co najmniej osiemnaście z dwudziestu pytań dostaje odpowiedź zgodną z dokumentacją, a żadna nie zmyśla funkcji, której nie ma”. W pierwszym nie da się przegrać, w drugim da się wygrać i przegrać, i dlatego ma wartość. Dla zadań, w których nie ma jednej poprawnej odpowiedzi, kryterium może dotyczyć cech: długości, zawartych elementów, tonu. Dobrze jest zapisać też to, co jest niedopuszczalne, na przykład wymyślone dane lub link, który nie istnieje.
Ranking to nie twoje zadanie
Wyniki na publicznych zestawach pokazują, jak model radzi sobie z tamtymi zadaniami. Nie mówią, jak poradzi sobie z twoimi pytaniami klientów, formatem faktur czy stylem, który uważasz za swój. Dlatego zestaw dwudziestu własnych przykładów jest dla mnie ważniejszy niż pozycja w rankingu. Gdy zestaw urośnie, warto użyć narzędzia: framework Inspect z brytyjskiego AI Security Institute dostarcza gotowe klocki do zbiorów danych, agentów i oceniających. W artykule Inspect, lm-evaluation-harness czy własny skrypt porównuję te drogi, a w tekście Jak ocenić agenta, zanim mu zaufasz pokazuję najkrótszą.
Co robię, kiedy test wychodzi słabo
Najpierw sprawdzam test, bo błędy zdarzają się też w pytaniach i w oczekiwanych odpowiedziach. Potem zmieniam jedną rzecz: prompt, kontekst albo model. Uruchamiam ten sam zestaw i porównuję. Nie zmieniam kryteriów, żeby wynik wyszedł lepiej; jeśli kryterium okazało się źle sformułowane, zapisuję poprawioną wersję z datą i uruchamiam wszystko od nowa.
Dlaczego to sprawa spokoju
Moja zasada brzmi: technologia ma oddawać czas. Test napisany raz oszczędza godziny sporów o to, czy nowy model jest lepszy. Za miesiąc pojawi się następny, a ja uruchomię zestaw i będę wiedzieć w kilka minut. Bez zestawu zostają wrażenia, które są najdroższą metodą oceny.