Jak wybrać LLM do produkcji: ślepa, międzydostawcza ocena

Najnowszy, najbardziej rozdmuchany model wygrał tę jedną metrykę, którą zacząłem mierzyć — i wylądował na samym końcu we wszystkim, co naprawdę się liczyło. To zdanie jest jedynym powodem, dla którego to spisuję.

Prowadzę zautomatyzowany pipeline, który zamienia jednolinijkowy pomysł („dwie rysunkowe rybki kłócą się z zazdrości") w gotowy pionowy film. W jego sercu siedzi jedno wywołanie LLM, które nazywam scenarzystą: z fabuły i obsady generuje ustrukturyzowaną listę ujęć dla każdej sceny — opis pierwszej klatki, ruch kamery, wypowiadane dialogi, emocjonalne akcenty oraz listę obiektów, które mają pozostać ukryte aż do celowego odsłonięcia.

To jedno wywołanie ma dwie cechy, dla których warto się nad nim głowić:

• To sufit jakości. Każdy późniejszy etap — obraz, wideo, głos — renderuje tylko to, co zdecydował scenarzysta. Płaskiego dialogu czy mglistego opisu nie da się uratować na dalszych etapach.
• Uruchamia się przy każdym projekcie. Więc jego cena za wywołanie mnoży się przez całe obciążenie.

Zestaw to razem, a pytanie przestaje brzmieć „który model jest najlepszy" i staje się „który model daje najwięcej jakości za dolara" — oraz czy tani wysłużony model nie zostawia na stole jakości, za którą warto zapłacić.

Co to wywołało

Dwie pretensje do wysłużonego modelu, taniego GPT-5.4-mini. Po pierwsze, wyciek pierwszej klatki: w komediowym odsłonięciu przez odjazd kamery — dwie rybki się kłócą, a potem kamera oddala się, by pokazać, że są w maleńkim akwarium, w domu, pod wodą, a obok przelatuje jastrząb — model wpisał odsłonięcie wprost w klatkę otwierającą. Puenta zepsuta, pierwsze ujęcie zaśmiecone. Po drugie, chude dialogi: funkcjonalne, ale płaskie, często odzywała się tylko jedna postać.

Bug w obrazku: GPT-5.4-mini wpisał całe oddalenie-rewelację wprost w pierwszą klatkę — dom, pokój, jastrząb i maleńkie akwarium widoczne naraz. Puenta zepsuta, zanim scena się zaczęła.

Mogłem podmienić model na czuja. Zamiast tego przeprowadziłem ocenę, bo koszt tego wywołania mnoży się przez każdy film, jaki kiedykolwiek zrobię.

Metoda (to jest ta część do wielokrotnego użytku)

Uczciwy input. Nie napisałem syntetycznego promptu testowego. Odtworzyłem dokładnie te wiadomości, które pipeline wysyła w produkcji: systemowy prompt na ~12 000 tokenów niosący fabułę, postacie i wszystkie reguły autorskie, plus malutki prompt użytkownika („wygeneruj listę ujęć dla 1 sceny") i ścisły kontrakt wyjścia w JSON. Każdy model dostał bajt w bajt identyczną treść; per dostawca dostosowałem jedynie mechanizm ustrukturyzowanego wyjścia.

Cztery modele wzdłuż osi kosztu: tani wysłużony model (GPT-5.4-mini), najnowszy pełny GPT (GPT-5.5), Claude z najwyższej półki (Opus 4.8) i Claude ze średniej półki (Sonnet 4.6).

Dwa narzędzia. Deterministyczny skaner wycieków, który mechanicznie sprawdza pola t=0 pod kątem ukrytych słów, niezadeklarowanych rzeczowników-„intruzów" oraz sformułowań zdradzających odsłonięcie (wynik: 10 minus kary). Oraz ślepy, międzydostawczy panel sędziowski: dwóch sędziów od różnych dostawców (jeden Opus, jeden GPT-5.5) oceniało cztery wyjścia zanonimizowane — przemianowane na A/B/C/D, żaden sędzia nie wiedział, który model napisał które wyjście ani które było jego własnym — w sześciu wymiarach: dialog, opis, ruch, emocje, dyscyplina pierwszej klatki i spójność.

Dwóch sędziów od różnych dostawców chroni przed gustem pojedynczego modelu; anonimizacja wejść powstrzymuje sędziego od schlebiania własnej pracy.

Co się wydarzyło

Runda 1, wąski test wycieku. Na świeżej próbce wszystkie cztery modele dostały 10/10 — czysto — wobec 0/10 prawdziwej klatki produkcyjnej. Ten sam wysłużony model, który przeciekał w produkcji, tutaj wyprodukował czystą klatkę, z tego samego promptu.

To pierwsza lekcja i łatwo ją przeoczyć: bug był stochastyczny, nie był wadą modelu. Przy normalnej temperaturze próbkowania awaria jest probabilistyczna. Pojedynczy przebieg nie potrafi rozdzielić modeli na tej osi — i żadna podmiana modelu nie gwarantuje czystej klatki.

Runda 2, pełna ślepa ocena. Ponieważ wąski test się wysycił, oceniłem całe wyjście. Sumy panelu na 60:

• Claude Opus 4.8 — 49.5
• Claude Sonnet 4.6 — 49.0
• GPT-5.4-mini (wysłużony) — 40.5
• GPT-5.5 — 34.0

Obaj sędziowie niezależnie postawili dwa modele Claude na szczycie, a GPT-5.5 na końcu. Szczegół, który kazał mi w to uwierzyć: sędzia GPT-5.5 ustawił modele swojego własnego dostawcy na ostatnim miejscu. Żadnej stronniczości na rzecz swoich — jeśli już, to wręcz przeciwnie.

To, co je różnicowało, było konkretne. Dwa najlepsze napisały prawdziwą wymianę zdań w obie strony — jedna rybka oskarża, druga odpowiada („Przecież tylko jadłam…", wiążąc wymówkę z robakiem w pyszczku) — plus animowalną komedię fizyczną („trzaska płetwą w twarz, robak wylatuje"). Oba modele GPT dały jednostronne oskarżenie i zostawiły drugą postać bezczynnie.

I puenta całego badania: GPT-5.5, najnowszy flagowiec, wygrał wąską metrykę wycieku, ale ogólnie wylądował na końcu. Utrzymał pierwszą klatkę w czystości — po czym przeniósł odsłonięcie do innego pola, którego skaner nie sprawdzał. Przeszedł proxy i mimo to zepsuł gag.

Czysta pierwsza klatka na Sonnet 4.6: tylko dwie postacie. Robak w pyszczku błazenka to wymówka, którą rozgrywa dialog — detal fabuły, a nie wyciek rewelacji.

Optymalizacja pod pojedynczą metrykę może aktywnie wyselekcjonować gorszy produkt. Jedyne, co to wyłapało, to spojrzenie na całe wyjście, ślepo.

Decyzja jakość kontra koszt

To jest sekcja, dla której to badanie istnieje. Zmierzone na żywym wywołaniu, jedna scena na Sonnet 4.6 zużyła ~12k tokenów wejścia + ~1.3k tokenów wyjścia — wejście zdominowane przez stały systemowy prompt, wyjście rosnące z liczbą scen. Jako orientacyjne proporcje na projekt dla filmu z 6 scenami (przed wycenianiem sprawdź ponownie aktualne ceny dostawców — to proporcje są tą trwałą częścią):

• GPT-5.4-mini — ~1× (najtańszy), jakość 40.5
• Sonnet 4.6 — ~15× wysłużonego modelu, jakość 49.0
• Opus 4.8 — ~5× Sonneta, jakość 49.5
• GPT-5.5 — ta sama półka co Sonnet, jakość 34.0

Czytaj to na trzy sposoby:

• Najtańsze nie znaczy darmowe. Wysłużony model jest ~15× tańszy, ale o 8.5 punktu jakości niżej — a skoro scenarzysta jest sufitem, ta różnica wychodzi w każdym filmie. Oszczędność zostaje spłacona gorszym wyjściem.
• Najdroższe nie jest tu warte zachodu. Opus jest nominalnie #1, ale jego przewaga 0.5 punktu nad Sonnetem mieści się w szumie dwuosobowego panelu, przy ~5× koszcie za token — na wywołaniu, które uruchamia się przy każdym projekcie.
• Najnowszy flagowiec jest zdominowany. GPT-5.5 jest i gorszy, i nie tańszy. Nie ma punktu pracy, w którym byłby właściwym wyborem. „Najnowszy i najbardziej rozdmuchany" to nie to samo co „najlepszy do roboty".

Więc wdrożyłem Sonnet 4.6 — kolano krzywej: z grubsza jakość Opusa, wyraźnie powyżej obu GPT, za jakąś jedną piątą ceny Opusa. Dwie korekty trzymają rachunek w ryzach: pomocnicze, niekreatywne wywołania (walidator, normalizator dialogów) zostają na tanim modelu, bo niczego nie tworzą; a model scenarzysty to pojedyncza stała konfiguracyjna, więc awans do Opusa albo cofnięcie z powrotem to zmiana jednej linijki.

A ten bug, od którego wszystko się zaczęło? Upgrade modelu obniża szanse na wyciek pierwszej klatki, ale nie wyeliminuje rzutu kostką. Solidna naprawa jest deterministyczna: złóż klatkę otwierającą ze sztywno ograniczonych slotów (postacie, ich poza i emocja, tylko otoczenie tła) i wytnij w kodzie jakiekolwiek odsłonięcie czy obiekt-intruza, niezależnie od modelu. Płacenie za większy model, by kupić niezawodność, którą deterministycznie masz za darmo, to po prostu odwrócona pułapka taniego modelu.

Co chciałbym, żebyś stąd wziął, a nie brał na wiarę

Uczciwe ograniczenia: ten ranking opiera się na jednej generacji na model i dwóch sędziach. Różnica Opus/Sonnet to szum — traktuj je jako remis. Sędziowie też są graczami (anonimizacja i międzydostawcza zgodność redukują samopreferencję, ale jej nie wymazują). To jeden scenariusz, jeden gatunek. Mocniejsze badanie przepuszcza N≥10–20 próbek na model i raportuje rozkłady, nie pojedyncze wyniki. Nic z tego nie wywraca kierunkowego rezultatu, ale wyznacza granice tego, jak mocno możesz go stwierdzić.

Części, które przenoszą się dalej, niezależnie od tego, który dostawca wygra w twoim przypadku:

1. Testuj na swoim prawdziwym promptcie, nie na syntetycznym. Uczciwość zależy od identycznego, produkcyjnie prawdziwego wejścia.
2. Mierz holistycznie i ślepo. Pojedyncza metryka proxy prędzej czy później wybierze gorszy produkt; zanonimizowane, międzydostawcze sędziowanie to wyłapuje.
3. Wyceniaj prawdziwymi tokenami i porównuj jakość-za-dolara, nie szczytową jakość — zwłaszcza dla wywołania mnożonego przez całe twoje obciążenie.
4. Oddziel bugi stochastyczne od jakości modelu. Jeśli defekt pojawia się i znika między przebiegami tego samego modelu, jest probabilistyczny — napraw go w kodzie, nie wykupuj się z niego większym modelem.

---

Jestem Dzmitry Harupa, fractional CTO, który buduje i wdraża systemy AI własnymi rękami i spisuje to, czego uczy mnie ta robota — jak to, że dałem moim agentom AI trwałą pamięć między sesjami. Jeśli prowadzisz takie oceny albo chcesz podważyć sposób, w jaki przeprowadziłem tę — napisz do mnie — najostrzejsze zarzuty są najbardziej przydatne.