Generative AI Design Patterns #5: LLM-as-Judge, Reflection, Dependency Injection i Prompt Optimization, czyli ewaluator jest specyfikacją

Rozdział 6 „Generative AI Design Patterns" opisuje cztery wzorce niezawodności: LLM-as-Judge, Reflection, Dependency Injection i Prompt Optimization. Wszystkie opierają się na ewaluatorze, więc to on decyduje, co system uzna za dobry wynik. Sprawdziłem dwa z tych wzorców na Qwen3.8-27B na stacji z RTX 5090. Jedna runda samokrytyki tym samym modelem podniosła wynik na 60 zadaniach kalendarzowych z 42 do 45. Krytyk przepuścił jednak połowę błędów, a jedną poprawną odpowiedź zepsuł. Automatyczny test, który mówił tylko „źle", podniósł wynik do 54, a poprawnych odpowiedzi z założenia nie ruszał. W Prompt Optimization obaj sędziowie wybrali prompt lepszy od bazowego, co zgadza się z autorami. Sędzia z ogólną rubryką ocenił jednak wyżej od bazowego także prompt, który ani razu nie podał numeru zgłoszenia.

To siódmy wpis serii o książce Valliappy Lakshmanana i Hannesa Hapkego. Recenzja i mapa serii są we wpisie 0, poprzedni wpis dotyczył rozszerzania zdolności modelu. Cytuję po rozdziale i numerze wzorca, bo PDF nie ma stron druku.

Teza

Rozdział 6 wygląda na zbiór czterech niezależnych technik. Łączy je jedno: w każdej z nich ktoś albo coś ocenia wynik modelu. LLM-as-Judge jest tym ewaluatorem. Reflection zamienia jego ocenę w krytykę i każe modelowi poprawić odpowiedź. Prompt Optimization wybiera według niego najlepszy prompt. Dependency Injection pozwala testować kod wokół modelu bez samego modelu.

Moja teza: we wszystkich czterech wzorcach to ewaluator określa, co znaczy „dobrze", więc system nie będzie lepszy od niego. Pomiar potwierdza to dla Reflection. Samokrytyka nie wyłapuje błędów, których model nie widzi już przy generowaniu. Ewaluator deterministyczny wyłapał je, choć mówił tylko, że odpowiedź jest zła. Przy Prompt Optimization pomiar zgadza się z autorami: optymalizacja pod sędziego-LLM dała prompt, który poprawił obiektywny wynik na zbiorze, którego wybór nie widział. Słabość ogólnego sędziego widać dopiero w ocenach pozostałych promptów, nie w zwycięzcy.

Pattern 17: LLM-as-Judge

Problem. Krok oceny pojawiał się w książce już wcześniej: przy porównywaniu dwóch treści (wzorzec 5), rerankingu fragmentów w RAG-u (wzorzec 10), ocenie ścieżek w Tree of Thoughts (wzorzec 14) i filtrowaniu przykładów w Evol-Instruct (wzorzec 16). Rozdział 6 zbiera to w osobny wzorzec. Autorzy zaczynają od trzech klasycznych sposobów oceny i ich granic. Pomiar wyniku biznesowego jest złotym standardem, ale sprzedaży nie da się przypisać jednej broszurze. Ocena ludzka jest droga, wolna i obciążona. Metryki automatyczne w rodzaju BLEU i ROUGE liczą n-gramy, a „you can't customize a BLEU score to make it more relevant to the problem of creating marketing copy to drive heavy-machinery sales" (rozdz. 6, Pattern 17).

Rozwiązanie. Model ocenia według rubryki. Autorzy opisują trzy warianty. Pierwszy to rubryka w prompcie. Drugi traktuje wyniki rubryki jako cechy klasyfikatora uczonego na prawdziwych wynikach biznesowych, który sam wygasi kryteria bez znaczenia. Trzeci to dostrojenie sędziego na ocenach ekspertów, gdy kryterium trudno opisać słowami. Najtańsza rada w całym wzorcu dotyczy kalibracji: rubryki nie pisze się hasłami, tylko opisuje, co znaczy każdy punkt skali, na przykład „1 if any information in the summary misrepresents the article / 5 if all statements in the summary are grounded in the article" (rozdz. 6, Pattern 17). Druga rada techniczna: zamiast najbardziej prawdopodobnej oceny brać średnią ocen ważoną ich prawdopodobieństwem. Obu rad użyłem w pomiarze niżej.

Kiedy nie używać. Gdy wynik da się sprawdzić deterministycznie, czyli testem, kompilatorem albo porównaniem z wzorcem. Autorzy wyliczają też skrzywienia sędziego. Pierwsze to pobłażliwość: „like professors who give every student A's and B's". Pozostałe to preferencja dla własnych odpowiedzi, dla dobrze napisanego tekstu „even if it is inaccurate", dla dłuższych odpowiedzi i dla treści na początku i na końcu. Zalecają grube skale, najlepiej pytania binarne, kilka kryteriów zamiast jednej oceny i kilku sędziów. Najbardziej zaskakuje uwaga, że prośba o uzasadnienie oceny pogarsza ocenę: „It may be that the process of self-explanation introduces deeper biases" (rozdz. 6, Pattern 17). Skrzywienia długości i pozycji zmierzyłem już we wpisie 1b, więc tu ich nie powtarzam.

Pattern 18: Reflection

Problem. W czacie poprawia się odpowiedź modelu kolejną wiadomością. Wywołania API są bezstanowe, więc aplikacja musi tę rozmowę zorganizować sama.

Rozwiązanie. Wynik idzie do ewaluatora, który zwraca krytykę, a nie ocenę. Krytyka staje się instrukcją do ponownego wygenerowania. Pętlę powtarza się do progu jakości albo robi się dokładnie jedną rundę. Autorzy zaznaczają, że wzorzec bywa nazywany self-reflection, „but there's no reason why the evaluation has to be done by an LLM at all, let alone by the same LLM that generates the content" (rozdz. 6, Pattern 18). Jedną rundę zalecają, bo trudno ustalić, co znaczy „dość dobrze". Ich własna rubryka dała tę samą ocenę 0,9 logo Pydantica i wygenerowanemu logo sushi.

Kiedy nie używać. Gdy liczy się czas odpowiedzi, jak w chatbocie albo silniku gry. Autorzy przypominają, że dostawcy mają problemy z dostępnością, więc już jedno wywołanie wymaga ponowień, a refleksja mnoży wywołania i wydłuża ogon latencji. Przy generowaniu kodu jest odwrotnie. Dodatkowa runda kosztuje mało wobec zepsutego builda, więc stosuje się wiele rund, także z kompilatorem i sandboksem jako ewaluatorem (rozdz. 6, Pattern 18). Mój pomiar dokłada drugi warunek: nie używaj samokrytyki tym samym modelem tam, gdzie błąd bierze się z tego, czego model nie umie.

Pattern 19: Dependency Injection

Problem. Aplikację GenAI trudno testować z trzech powodów. Model jest niedeterministyczny: „calls to an LLM with the exact same input can return different outputs each time". Modele szybko się zmieniają, a „the longer and more detailed your prompts, the more brittle they are". Do tego dochodzi wymóg niezależności od dostawcy, przy czym frameworki przenoszą kod, ale nie prompty (rozdz. 6, Pattern 19).

Rozwiązanie. Każdy krok łańcucha definiuje się jako funkcję o ustalonej sygnaturze. Domyślna implementacja woła model, a test podstawia atrapę ze stałym wynikiem. Do tego dochodzą asercje wewnątrz łańcucha, które w Pythonie znikają pod flagą -O. Autorzy piszą wprost, że to wzorzec znany z inżynierii oprogramowania, ale „many AI engineers who come from a science background are unaware of it". Dodają, że w chwili pisania żaden framework GenAI nie wspierał go natywnie (rozdz. 6, Pattern 19).

Szkic w Pythonie, który napisałem do tego wpisu i uruchomiłem (oba testy przechodzą):

from typing import Callable

Summarize = Callable[[str], str]   # sygnatura kroku, który woła model

def llm_summarize(text: str) -> str:
    raise RuntimeError("w produkcji: wywołanie modelu")   # domyślna implementacja

def build_notice(text: str, ticket: str, summarize: Summarize = llm_summarize) -> str:
    s = summarize(text)
    if ticket not in s:            # deterministyczny kod wokół modelu: to testujemy
        s = f"{s} (zgłoszenie {ticket})"
    assert len(s.split()) <= 45, "streszczenie za długie"   # znika pod python -O
    return s

def test_adds_missing_ticket():
    s = build_notice("...", "INC-44785", summarize=lambda t: "Przerwa 6 czerwca, 1:45–7:00.")
    assert s.endswith("(zgłoszenie INC-44785)")

def test_keeps_ticket_given_by_model():
    s = build_notice("...", "INC-44785", summarize=lambda t: "Przerwa INC-44785 6 czerwca.")
    assert s.count("INC-44785") == 1

Test nie sprawdza modelu, tylko deterministyczny kod wokół niego. Pilnuje, żeby numer zgłoszenia trafił do komunikatu także wtedy, gdy model go pominie. Ten przypadek nie jest wymyślony: w pomiarze Prompt Optimization niżej jeden z promptów nie podał numeru zgłoszenia w żadnym z 24 streszczeń.

Kiedy nie używać. Autorzy przyznają, że dobranie wartości atrapy bywa trudne, gdy kroki mocno na siebie wpływają. Wtedy sam wybór obiektu, który atrapa ma zwrócić, staje się problemem (rozdz. 6, Pattern 19).

Pattern 20: Prompt Optimization

Problem. Prompt dopracowany ręcznie pod jeden model trzeba dopracowywać od nowa przy każdej zmianie modelu: „If you change the foundational model … all your trials need to be repeated" (rozdz. 6, Pattern 20). Wyniesienie promptów do pliku konfiguracyjnego tego nie zmienia, bo „you'll still have to experiment manually whenever your dependencies change".

Rozwiązanie. Jeszcze jeden poziom pośredni. Zamiast promptu utrzymuje się cztery rzeczy: pipeline kroków z sygnaturami, zbiór przykładów, ewaluator (porównanie z wzorcem albo LLM-as-Judge) i optymalizator, który generuje warianty promptów i wybiera najlepszy. Autorzy pokazują to na DSPy. BestOfN generuje N wariantów przy każdym użyciu, a BootstrapFewShot dobiera przykłady few-shot raz i zapisuje gotowy pipeline. Zmianę perspektywy podsumowuje zdanie: „Your code itself doesn't have prompts" (rozdz. 6, Pattern 20). Przykład liczbowy autorów to jeden opis książki, oceniany ich własnym sędzią. Wynik wzrósł z 0,63 przy ręcznie przepisanym prompcie do 0,74 po BestOfN. To ilustracja, nie pomiar.

Kiedy nie używać. Gdy nie ma ewaluatora, któremu ufasz. Optymalizator wybiera to, co ewaluator nagradza, więc jego luki trafiają do wybranego promptu. Autorzy proponują na koniec rozdziału kolejność budowy: najpierw zapisywanie promptów i opinii ludzi, z tego zbiór do zbudowania sędziego, z sędziego skalowalna ewaluacja, a z zebranych promptów dane do dostrojenia modelu (rozdz. 6, Pattern 20). Sędzia jest tu drugim krokiem, nie pierwszym.

Sprawdziłem Reflection i Prompt Optimization na RTX 5090

Środowisko. Pomiar z 15 października 2026 na stacji z RTX 5090: vLLM v0.30.0, Qwen3.8-27B w INT4 od Red Hata, ten sam model co we wpisie o kwantyzacji. Tryb myślenia był wyłączony, temperatura 0, po jednym przebiegu. Ten sam model generował, krytykował i oceniał. Autorzy odradzają takie ustawienie z powodu skrzywienia na korzyść własnych odpowiedzi. Tu było to celowe, bo samokrytyka jest właśnie tym, co sprawdzam. Dane są syntetyczne, a odpowiedzi poprawne policzył Python.

Reflection: 60 zadań kalendarzowych

Wpis 4 skończył się na tym, że przy CoT zostają błędy arytmetyki kalendarza. Na nich sprawdziłem Reflection. Zadania były czterech rodzajów, po 15 na rodzaj: dodaj N dni roboczych, policz dni między datami, podaj dzień tygodnia, dodaj N dni kalendarzowych. Przykład: „Jaki dzień tygodnia wypada 15 lipca 2027? Podaj nazwę dnia po polsku."

Trzy warunki:

• bez refleksji: odpowiedź modelu, który i tak rozpisuje obliczenia, choć nikt go o to nie prosi;
• samokrytyka: ten sam model jako recenzent sprawdza odpowiedź krok po kroku, kończy werdyktem POPRAWNA albo BŁĘDNA, a potem autor dostaje uwagi i podaje ostateczną odpowiedź. Jedna runda, zgodnie z zaleceniem autorów;
• test deterministyczny: Python porównuje odpowiedź z wzorcem. Jeśli jest błędna, model dostaje tylko „Automatyczny test nie przeszedł: odpowiedź X jest błędna", bez poprawnego wyniku, a przy braku odpowiedzi komunikat o brakującej linii ODPOWIEDŹ. Poprawne odpowiedzi nie są ruszane.

Rodzaj zadania	Bez refleksji	Samokrytyka	Test deterministyczny
dni robocze	9/15	11/15	13/15
różnica dni	14/15	15/15	15/15
dzień tygodnia	4/15	4/15	11/15
dodawanie dni	15/15	15/15	15/15
razem	42/60	45/60	54/60

Samokrytyka naprawiła 4 z 18 błędnych odpowiedzi i zepsuła 1 z 42 poprawnych. Ciekawsze jest to, czego krytyk nie zobaczył. Z 18 błędnych odpowiedzi uznał za błędne 9, a 9 przepuścił jako poprawne. 8 z tych 9 to dzień tygodnia, czyli dokładnie ten rodzaj zadania, na którym model myli się najczęściej. Moje wyjaśnienie: krytyk ma tę samą lukę co autor odpowiedzi, bo jest tym samym modelem. Wariantu z krytykiem z innego modelu nie mierzyłem.

Zepsucie wyglądało tak. W zadaniu „11 lutego 2027 plus 9 dni roboczych" odpowiedź 24 lutego była poprawna, a 11 lutego 2027 to czwartek. Krytyk napisał „11 lutego 2027 to Sobota, a nie czwartek, jak twierdzi odpowiedź", wydał werdykt BŁĘDNA i podał 23 lutego. Autor przyjął uwagę, przeliczył i odpowiedział 23 lutego. Krytyk w drugą stronę przy 8 lutego 2027 sprawdził „niezależnie", że 1 stycznia 2027 to poniedziałek (był piątek), i potwierdził błędny czwartek (był poniedziałek).

Test deterministyczny naprawił 12 z 18 błędów i nie zepsuł nic, bo z założenia nie rusza odpowiedzi, które przeszły. Przy dniu tygodnia trzeba jednak uczciwie zaznaczyć, że sama informacja „źle" wyklucza jedną z siedmiu odpowiedzi. Mimo to wynik 11/15 przy 4/15 bez refleksji to więcej, niż dałoby zgadywanie spośród sześciu pozostałych dni.

Koszt w tokenach. Odpowiedzi bez refleksji to 96 648 tokenów wyjścia. Samokrytyka dołożyła 159 937 tokenów wyjścia i 343 428 tokenów wejścia, bo krytyk czyta całą odpowiedź, a autor całą krytykę. Test dołożył 65 025 tokenów wyjścia i 52 961 wejścia w 18 wywołaniach. Za mniej niż połowę tokenów wyjścia dał trzy razy więcej naprawionych odpowiedzi.

Pierwszy przebieg był źle ustawiony. Najpierw dałem limit 2048 tokenów na odpowiedź. 13 z 60 odpowiedzi bez refleksji nie zmieściło się w nim i nie miało wyniku, 10 z nich przy dniu tygodnia. Mediana dla tego rodzaju zadania w drugim przebiegu wyniosła 3 579 tokenów, bo model liczy dni od 1 stycznia i gubi się po drodze. Wyniki z tabeli pochodzą z drugiego przebiegu z limitem 8192. Także w nim jedna odpowiedź (dzień tygodnia) została ucięta. Liczę ją jako błędną. Pierwszy dał 37, 40 i 40 na 60, ale mierzył głównie mój limit. Próbowałem też krytyka z włączonym trybem myślenia. Na pierwszym zadaniu nie skończył myślenia w limicie 8192 tokenów, więc zrezygnowałem z tego wariantu na współdzielonej stacji.

Prompt Optimization: SMS z komunikatu o przerwie

Zadanie: streścić komunikat o przerwie w działaniu fikcyjnej usługi jako SMS w maksymalnie 20 słowach. Każdy komunikat ma pięć kluczowych danych: datę, godzinę rozpoczęcia i zakończenia, numer zgłoszenia i liczbę oddziałów. Do tego zawiera akapity grzecznościowe i dane-pułapki, czyli numer i datę poprzednich prac. Najpierw ustawiłem limit 40 słów, ale wtedy prompt bazowy na próbie (tej próby nie zachowałem) podawał wszystkie pięć danych i nie było czego optymalizować.

Kontrola obiektywna została zapisana w kodzie przed uruchomieniem. Liczy, jaka część pięciu danych jest w SMS-ie, a SMS dłuższy niż 20 słów dostaje 0. Liczyłem też dane-pułapki. Żaden SMS ich nie podał i żaden nie przekroczył limitu.

Dwóch sędziów, oba jako ten sam model z oceną 1–5 liczoną jako średnia ważona prawdopodobieństwem ocen:

• JA, rubryka ogólna: „Kryteria: jasność, zwięzłość, ton, przydatność";
• JB, rubryka z opisem każdego punktu, zgodnie z radą autorów: 5 to wszystkie kluczowe dane, zgodne z komunikatem, najwyżej 20 słów; 4 to brak jednej danej i tak dalej.

Optymalizator w uproszczonej formie BestOfN. Model z temperaturą 0,7 zaproponował 8 wariantów instrukcji bazowej „Streść poniższy komunikat dla klientów jako SMS w maksymalnie 20 słowach". Każdy z 9 promptów wygenerował SMS-y dla 12 komunikatów treningowych. Najlepszy prompt wybierałem osobno według JA, według JB i według kontroli. Na koniec sprawdziłem wybrane prompty na 12 innych komunikatach, których wybór nie widział.

Prompt	Wybrał go	Kontrola, zbiór testowy	JA, test	JB, test
bazowy	—	0,80	3,83	3,03
nr 2 („Ton: profesjonalny, spokojny. Zawijaj tylko kluczowe fakty")	JA	0,98	4,34	4,19
nr 1 („Skup się na: co się dzieje, od kiedy, do kiedy")	JB i kontrola	0,98	3,92	4,69

Tu pomiar zgadza się z autorami. Optymalizacja działała z obydwoma sędziami. Prompt wybrany według ogólnej rubryki poprawił kontrolę na zbiorze testowym z 0,80 do 0,98, tak samo jak prompt wybrany według rubryki szczegółowej. Prompt bazowy podał numer zgłoszenia tylko w 13, a liczbę oddziałów w 12 z 24 SMS-ów. Moja teza robocza zakładała, że optymalizacja pod ogólnego sędziego może nie poprawić wyniku. W tym pomiarze się nie potwierdziła.

Różnica między sędziami jest w rankingu wszystkich dziewięciu promptów. Korelacja rangowa Spearmana z kontrolą na zbiorze treningowym wyniosła 0,98 dla JB i 0,52 dla JA. Najwyraźniej widać to na prompcie nr 3, który kazał pisać w formacie „[Status] | [Wpływ] | [Czas]". Ten prompt nie podał numeru zgłoszenia w żadnym z 24 SMS-ów. JA dał mu na zbiorze treningowym 4,06, więcej niż promptowi bazowemu (3,61) i niż zwycięzcy według kontroli (3,88). Kontrola wyniosła u niego 0,80, czyli tyle co prompt bazowy. Na jednym komunikacie testowym SMS z promptu nr 3 bez numeru zgłoszenia dostał od JA 3,81, a kompletny SMS z promptu nr 1, zwycięzcy według kontroli, 3,54. We wszystkich 216 SMS-ach JA odróżniał kompletne od niekompletnych średnio o pół punktu (4,08 wobec 3,59), a JB o dwa punkty (4,61 wobec 2,62).

Wniosek jest węższy, niż zakładałem. Ogólny sędzia wybrał dobry prompt, ale wśród promptów z wysoką oceną miał też taki, który systematycznie gubił jedną z pięciu danych. Przy innym zestawie kandydatów mógł wygrać właśnie on. Rubryka z opisem punktów, którą autorzy zalecają, zamieniła sędziego w niemal wierną kopię kontroli. To nie jest przypadek. Wpisałem do niej te same pięć danych, które liczyła kontrola, czyli zapisałem specyfikację wprost.

Czego ten pomiar nie mówi

60 zadań i 2 razy 12 komunikatów, po jednym przebiegu, to mało. Różnice o 2–3 zadania mogą być szumem, różnice 42 → 54 i 0,80 → 0,98 są wyraźne. Wszystkie role pełnił jeden lokalny model z wyłączonym myśleniem. Krytyk z innego, mocniejszego modelu mógłby wyłapać więcej. Nie sprawdzałem DSPy, tylko własną uproszczoną pętlę wyboru najlepszego promptu. Jak w poprzednim wpisie, zadania i komunikaty są od dziś opublikowane, więc przestają się nadawać do kolejnego testu.

To samo w innych książkach

François Chollet w Deep Learning with Python opisuje ten sam mechanizm przy hiperparametrach. Dobieranie konfiguracji według wyniku na zbiorze walidacyjnym „is a form of learning" (s. 133), więc model „performs artificially well on the validation data, because that's what you optimized it for" (s. 134). Automatyczne tunery „will quickly overfit to the validation data" (s. 418). Chollet pisze o hiperparametrach, nie o promptach, więc przeniesienie jest moje. Pasuje jednak do pętli z Prompt Optimization: zbiór, na którym wybierasz prompt, przestaje być niezależnym pomiarem. Dlatego w pomiarze wyżej wybór szedł na zbiorze treningowym, a wynik podaję ze zbioru testowego.

Harry Percival w Test-Driven Development with Python pokazuje koszt atrap, na których opiera się Dependency Injection. Lakshmanan i Hapke o nim nie piszą. Percival pisze o mockach: wiążą test ze sposobem wywołania, więc „you shouldn't use them unless you have a good reason" (s. 494). Lepszym rozwiązaniem jest architektura, która ogranicza ilość kodu stykającego się z granicami systemu (s. 632). Percival przytacza też kontrargument Davida Heinemeiera Hanssona o „test-induced design damage" (s. 632–634). Dlatego test w szkicu wyżej sprawdza wynik, czyli czy numer zgłoszenia jest w komunikacie, a nie to, jak wywołano model.

Dominik Polzer w RAG with Python Cookbook przyznaje, że ocena sędzią-LLM jest „similar to an author reviewing their own work" (s. 287). To samo pokazał krytyk w moim pomiarze.

Kiedy nie używać — zestawienie

Wzorzec	Nie używaj, gdy	Zamiast tego
LLM-as-Judge	wynik da się sprawdzić testem albo wzorcem	test deterministyczny
LLM-as-Judge	rubryka jest hasłowa („jasność, ton")	rubryka z opisem każdego punktu
LLM-as-Judge	sędzią jest ten sam model co generator	inny model albo kilku sędziów
Reflection	liczy się czas odpowiedzi	jedno wywołanie z dobrym promptem
Reflection	krytykiem jest ten sam model, a błąd wynika z braku umiejętności	ewaluator zewnętrzny: test, kompilator, narzędzie
Dependency Injection	kroki tak na siebie wpływają, że nie wiadomo, co ma zwrócić atrapa	testy integracyjne na granicach
Prompt Optimization	nie masz ewaluatora, któremu ufasz	najpierw zbieranie opinii ludzi i sędzia
Prompt Optimization	wynik podajesz ze zbioru, na którym wybierałeś	osobny zbiór testowy

Ocena trwałości

Moja ocena, nie autorów. LLM-as-Judge jest trwały, a jego skrzywienia są stałe i dają się zmierzyć, więc da się je obejść rubryką i grubą skalą. Reflection jest trwały jako schemat, ale samokrytyka jednym modelem jest najsłabszą jego wersją. Trwała jest wersja z zewnętrznym ewaluatorem, którą autorzy opisują przy generowaniu kodu. Dependency Injection jest trwały, bo to stary wzorzec, a niedeterminizm modeli nie zniknie. Prompt Optimization jest trwały jako zasada: utrzymujesz przykłady i ewaluator, a prompt z nich odtwarzasz. Konkretne frameworki są datowane.

Starszy krewny

Dependency Injection to wzorzec znany od dawna w inżynierii oprogramowania, o czym autorzy piszą wprost. Reflection z testem deterministycznym to zwykła pętla „kompiluj, popraw, kompiluj", w której model zastępuje programistę. Prompt Optimization to dobór hiperparametrów na zbiorze walidacyjnym z tymi samymi pułapkami, które opisuje Chollet. Moim zdaniem LLM-as-Judge ma krewnego w ocenie esejów według klucza. Pomiar wyżej pokazał to samo co szkolny klucz: im dokładniej opisany jest każdy punkt, tym mniej ocena zależy od tego, kto ją wystawia.

Dalej w serii

Następny wpis (6) dotyczy rozdziału 7, czyli agentów i narzędzi: Tool Calling, Code Execution i Multiagent Collaboration. Mapa całej serii jest we wpisie 0.