Stop Guessing Which Model to Use. Build THIS Instead.

O czym jest ten film

1. Cotygodniowe premiery modeli generują lawinę powtarzalnych tutoriali, które nie odpowiadają na jedno pytanie: czy ten model zmienia coś w twojej pracy.
2. Publiczne benchmarki (WebArena, olimpiady matematyczne itp.) mierzą coś zupełnie innego niż twoja codzienna robota.
3. Rozwiązanie: własny prywatny benchmark oparty na twoich realnych zadaniach i historii rozmów.
4. AI przeszukuje całą historię twoich konwersacji, wydobywa powtarzalne zadania i to na nich testuje nowy model.
5. Klucz to własna rubryka oceny — sam decydujesz, co znaczy „dobrze” (jakość, wierność instrukcjom, efektywność tokenowa, szybkość, liczba tur, a nawet „vibe”).
6. Ręczna rubryka ogranicza stronniczość, która pojawia się, gdy model ocenia sam siebie.
7. Całość działa jako komenda /benchmark: podajesz modele i poziomy wysiłku, a skill przeprowadza audyt (30–40 min) i wystawia werdykt.
8. Na żywo powstaje artefakt z tabelą i osobna strona WWW do śledzenia kolejnych prób w czasie rzeczywistym.
9. Typowe wnioski bywają rozczarowujące dla hype’u: „remis”, „nie warto przełączać workflow”, „tańszy model na niskim wysiłku daje to samo”.
10. Skill jest darmowy (link w opisie filmu) i można go dowolnie dostosować do modeli i własnych metryk.

Redakcyjne tłumaczenie

Znajomy scenariusz

Powiedzcie mi, czy to brzmi znajomo. Po raz trzeci w tym tygodniu wychodzi nowy model. Naturalnie wchodzicie na YouTube, zamykacie oczy, otwieracie je — i nagle macie przed sobą sto świeżych tutoriali. Wszystkie zbudowane dokładnie tak samo: „Model X jest absolutnie szalony i zmienia wszystko”. Dajecie się skusić, klikacie. A w środku oglądacie, jak ktoś buduje stronę, której nigdy nie użyjecie, grę 3D, w którą nigdy nie zagracie, i jakąś aplikację, której w ogóle nie było na waszej liście zadań.

Czasem zobaczycie nawet, jak ktoś po raz pierwszy razem z wami przewija i czyta benchmarki nowego modelu — tak, jakby te liczby realnie coś znaczyły dla większości waszej codziennej pracy. Musi być lepszy sposób, prawda? Jest.

Cel filmu

Moim celem jest pokazać wam, jak uruchomić własne benchmarki dla pracy, którą naprawdę wykonujecie. Dzięki temu, gdy pojawi się nowy model, nie musicie oglądać żadnego tutoriala. Wystarczy, że odpalicie prostą komendę — którą dam wam pod koniec filmu — i szybko dowiecie się, czy ten model faktycznie coś dla was zmienia, czy powinniście odstawić go na bok i skupić się na tym, co naprawdę się liczy.

Jeśli macie już dość powtarzalnych filmów, które oglądacie co tydzień, i chcecie czegoś, co realnie robi różnicę — zaczynajmy.

Dlaczego cudze benchmarki nie pasują do twojej pracy

Za każdym razem, gdy wychodzi model, dostajecie serię benchmarków. Problem w tym, że — w przeciwieństwie do tego, co one testują, jak WebArena czy olimpiada matematyczna — wasza faktyczna praca to maile do klientów, briefy, audyty repozytoriów, logi zdrowotne, listy leadów, prezentacje w PowerpoIncie i inne rzeczy zupełnie namacalne.

(Informacja dodatkowa: WebArena to akademicki benchmark oceniający agentów AI wykonujących zadania w symulowanych stronach internetowych; podobne testy mierzą wąskie, wystandaryzowane umiejętności, a nie codzienną pracę biurową.)

Zamiast więc liczyć na to, że ktoś inny akurat omówi ten jeden przypadek użycia, który dotyczy właśnie was, możecie kazać czemuś w rodzaju Claude’a albo Codeksa przejrzeć całą waszą dotychczasową historię rozmów, wyłuskać powtarzalne zadania, sprawdzić, jak wykonywały je wcześniejsze modele, i uruchomić dokładnie te same zadania i projekty na nowym modelu.

Twoja historia rozmów to surowiec

Czy chodzi o przepisanie zimnego maila i przetestowanie go na różnych poziomach wysiłku, czy o napisanie posta zapowiadającego premierę — w moim przypadku mam w systemie ponad tysiąc rozmów. To prawie 2 GB płynnego złota, informacji, które mogę podać AI, żeby samo się oceniło względem rubryki i sprawdziło, jak wypada na tle najnowszego modelu.

(Informacja dodatkowa: autor mówi o lokalnych plikach z historią konwersacji z asystentami AI, do których narzędzie ma dostęp na jego komputerze.)

Działa to tak: AI skanuje cały system w poszukiwaniu wszystkich rozmów, które prowadziliście. Potem w tych rozmowach szuka rdzenia — jakie są kluczowe inicjatywy i zadania, które faktycznie wykonujecie na co dzień. Bo to właśnie one warte są testowania na nowych modelach. To one powiedzą wam: tak, warto dopłacić — albo: wiesz co, ten model na niskim wysiłku da ci dokładnie to samo, co tamten na wysokim.

Rubryka, którą tworzysz sam

Kazanie AI, żeby samo się oceniało, prowadzi do sporej stronniczości. Dlatego tworzycie własną rubrykę — sami decydujecie, czym ma być wasz benchmark. Może opierać się na „vibe”, na konkretnych zadaniach, na copywritingu — na czymkolwiek chcecie.

Główna idea jest taka: kiedy raz stworzycie własną rubrykę osobistych benchmarków, może ona obejmować zarówno wydajność na konkretnych zadaniach, jak i „vibe check” — na przykład rozwlekłość modelu. Jak bardzo model ocenia? Jak bardzo jest „pyskaty”? To wy ustalacie, które metryki się dla was liczą.

A kiedy odpalicie taki skill, będziecie mogli porównać Opusa 4.8 z Opusem 5, z Fable 5, z dowolnym nowym modelem — czy to Claude Code, Codex, czy Kimi — i wciąż rozwijać ten skill według potrzeb.

(Informacja dodatkowa: „poziom wysiłku” — effort level — to ustawienie części modeli rozumujących, określające, jak długo model „myśli” przed odpowiedzią; wyższy wysiłek zwykle oznacza lepszą jakość, ale wyższy koszt i dłuższy czas.)

Jak wygląda uruchomienie

Jak pokażę za moment przy tych wszystkich otwartych kartach, wystarczy zrobić coś tak prostego, jak wpisanie /benchmark i podanie polecenia. Na przykład: „porównaj Opusa 4.8 z Opusem 5 na wysiłku średnim i niskim”. Narzędzie przeprowadzi audyt przez 30–40 minut, przetestuje wszystko, zestawi z waszą rubryką, stworzy raport i poda ostateczny werdykt.

Pokażę wam trzy próby, ale najpierw sam mechanizm. Otwieracie nowy terminal, logujecie się w świeżej sesji — i znów, możecie to zrobić z dowolnym modelem językowym — i wpisujecie /benchmark. Powiedziałbym na przykład: „Porównaj Opusa 4.8 na niskim wysiłku z Opusem 5 na niskim wysiłku pod kątem copywritingu, w oparciu o to, co — jak wiesz — jest dla mnie ważne w pisaniu tekstów”.

Wysyłamy polecenie. Narzędzie zaczyna kompilować, a po kilku minutach pojawia się nowy, żywy artefakt. Ma on tabelę pokazującą wszystkie elementy, które będą testowane przez najbliższe 30–40 minut, i raportuje w czasie rzeczywistym, gdy je kończy. Kiedy jest gotowe, potwierdza z wami, czy to dokładnie to zadanie, które chcecie przetestować. Jeśli tak, klikacie „uruchom jak jest”. Mogę powiedzieć: trzy próby, kliknąć „wyślij”. Wtedy uruchamia się nowa strona, która pozwala śledzić wszystkie próby — otwiera mi się w przeglądarce Chrome. Widać, że pracuje nad pierwszym wierszem, czyli pierwszym testem; oba modele są w toku i oba działają w trybie niskiego wysiłku, więc wiecie, że jedzie na właściwym poziomie.

Trzy przykładowe próby

Zamiast każać wam czekać czterdzieści minut, przejdę przez ukończone przebiegi i pokażę prompty, które wysłałem.

• Pierwsza próba: /benchmark Opus 5 kontra Fable 5 na zadaniu triażu maili menedżerskich — czyli w praktyce test copywritingu mailowego.
• Druga próba: Opus na niskim i wysokim wysiłku oraz Fable na niskim i wysokim wysiłku na konkretnym zadaniu.
• Trzecia próba: to samo, ale Opus 5 na niskim wysiłku kontra Opus 5 na wysokim wysiłku, trzy próby, zadanie postawione ogólnie — więc wybór zadań zostawiłem narzędziu.

Jak czytać raport

Oto przykład ukończonego raportu. Mówi dokładnie to, czego szukacie: zadanie zostało przetestowane, ale wynik był remisowy. Znaczy to, że nie opłaca się przestawiać całego workflow na dany model — poza kwestią kosztu — skoro na swoich poziomach wysiłku idą łeb w łeb.

Kolejny przykład: przetestowaliśmy jedno konkretne zadanie i raport mówi wprost — nie wygląda na to, by warto było przesiadać się z Fable na niskim wysiłku na Opusa na niskim czy średnim.

Gdy przewinę w dół, zobaczycie moją osobistą rubrykę. Dla jasności:

1. Jakość — jakość samej odpowiedzi. Może być punktowana w skali do 10, z własnym opisem, co znaczy dla was jakość.
2. Wierność instrukcjom — jak bardzo prawdopodobne jest, że model wykona dokładnie te polecenia, które mu daję.
3. Efektywność tokenowa.
4. Szybkość.
5. Liczba tur — im więcej tur bierze model, im więcej narzędzi wywołuje, tym bardziej puchnie kontekst i tym więcej tokenów zużywacie.

Wracając do widoku, przy każdym zadaniu narzędzie mówi mi, jaki procent całego mojego obciążenia stanowi to zadanie, jaki prompt przetestowano i jakie były wyniki. Co było „przed” i „po”, ile tur, ile słów, ile sprawdzeń i tak dalej. Potrafi przejść przez plik JSONL zawierający wszystkie metadane danego przebiegu i powiedzieć dokładnie, co się wydarzyło, żebyście mogli podjąć ostateczną decyzję.

(Informacja dodatkowa: JSONL to format pliku, w którym każda linia jest osobnym zapisem JSON; tu przechowuje logi i metadane poszczególnych przebiegów testowych.)

Werdykty w praktyce

Kilka innych przykładów. Jeden mówi: „Opus 5 mówi jak człowiek i działa szybciej, ale przeoczył ten konkretny brief”. Następny — pomijając kwestię ceny — „Claude Opus na wysokim wysiłku, Fable na niskim po cichu wygrywa”. Przewijając, zobaczycie wszystkie benchmarki dla każdego poziomu wysiłku, łączny czas i raporty „post mortem”. Bo waszym celem jest jasność.

Zamiast tracić czas na ciągłe poczucie zagubienia w nagłówkach, w których ludzie kłócą się, że jeden model zniszczył drugi albo zabił jakąś nową branżę, to wy jesteście sędzią i osobą za kierownicą.

Podsumowanie

I tyle. Wystarczy, że złapiecie skill, który zrobiłem dla was całkowicie za darmo — drugi link w opisie — i dostosujecie go do wybranych modeli. Możecie zmienić rubrykę, cokolwiek trzeba, żeby uzyskać szukaną jasność. A jeśli szukacie środowiska wolnego od hype’u, ze stałym strumieniem ekskluzywnych materiałów, w tym naszego żywego kursu Claude Code i Codex — sprawdźcie pierwszy link i dołączcie do mojej społeczności wczesnych użytkowników. Reszcie: jeśli to było pomocne i odświeżające na tle powtarzalnych tutoriali, będę wdzięczny za łapkę i komentarz. Do zobaczenia w kolejnym.

10 najważniejszych takeaways — z kontekstem zastosowania

1.Nie ufaj cudzym benchmarkom przy wyborze modelu

Na czym polega: Publiczne benchmarki mierzą wąskie, akademickie umiejętności (agenci webowi, matematyka, kodowanie), które rzadko pokrywają się z tym, co robisz na co dzień: maile, briefy, teksty, audyty.

Jak stosować: Traktuj nagłówki „model X bije model Y” jako informację orientacyjną, nie decyzyjną. Decyzję o zmianie modelu podejmuj dopiero po teście na własnych zadaniach.

Na co uważać: Wysoki wynik w rankingu nie oznacza lepszej roboty w twoim przypadku — a często kusi do niepotrzebnej, kosztownej migracji.

2.Zbuduj własny benchmark z historii swoich rozmów

Na czym polega: Twoja dotychczasowa historia konwersacji z AI to gotowy zbiór realnych zadań. Można ją przeskanować, wyłuskać powtarzalne czynności i użyć ich jako testów.

Jak stosować: Wskaż narzędziu (Claude, Codex itp.) folder z historią rozmów i poproś o wydobycie najczęstszych typów zadań wraz z ich udziałem w całości pracy.

Na co uważać: Historia rozmów bywa wrażliwa (dane klientów, dane osobowe). Rób to lokalnie i pilnuj, gdzie trafiają te dane, zanim podasz je jakiemukolwiek modelowi.

3.Testuj na swoich prawdziwych zadaniach, nie na demo

Na czym polega: Zamiast oglądać, jak ktoś buduje stronę czy grę, których nie potrzebujesz, uruchamiasz nowy model dokładnie na tych zadaniach, które faktycznie wykonujesz.

Jak stosować: Wybierz 3–5 reprezentatywnych zadań (np. zimny mail, triaż skrzynki, post zapowiadający premierę) i uczyń je stałym zestawem testowym dla każdego nowego modelu.

Na co uważać: Zbyt ogólne zadania dadzą mętne wnioski. Im konkretniejsze zadanie i kryterium sukcesu, tym ostrzejszy werdykt.

4.Stwórz własną rubrykę oceny

Na czym polega: Sam definiujesz, co znaczy „dobrze”: jakość, wierność instrukcjom, efektywność tokenowa, szybkość, liczba tur, a nawet cechy stylu („vibe”, rozwlekłość, ton).

Jak stosować: Zapisz rubrykę na sztywno przed testem — np. jakość w skali do 10 z opisem, co ją stanowi. Trzymaj się jej przy każdym kolejnym modelu, żeby wyniki były porównywalne.

Na co uważać: Rubryka bez opisu („jakość 1–10”, ale bez definicji) prowadzi do niespójnych ocen. Metryki muszą być na tyle jasne, by dwa przebiegi dało się porównać.

5.Ogranicz stronniczość samooceny modelu

Na czym polega: Gdy model ocenia sam siebie, wyniki są tendencyjne. Ręcznie ułożona rubryka i jasne kryteria zmniejszają ten efekt.

Jak stosować: Nie pytaj modelu „który jest lepszy?”. Zmuś go do wypełnienia twojej rubryki konkretnymi liczbami i dowodami (fragmenty odpowiedzi, liczba tur, słów).

Na co uważać: Model-sędzia i tak może faworyzować dłuższe lub „ładniej brzmiące” odpowiedzi. Warto weryfikować werdykt na kilku przykładach ręcznie.

6.Porównuj poziomy wysiłku, nie tylko modele

Na czym polega: Często tańszy model na niskim wysiłku dorównuje droższemu na wysokim. To poziom wysiłku, a nie sama nazwa modelu, bywa realną dźwignią kosztu i jakości.

Jak stosować: W jednym teście zestawiaj krzyżowo modele i poziomy (np. Fable/low vs Opus/low vs Opus/high) na tym samym zadaniu.

Na co uważać: Niski wysiłek bywa świetny do prostych zadań, ale zawodzi przy złożonych. Nie generalizuj wyniku z jednego typu zadania na wszystkie.

7.Werdykt „remis” to też cenna decyzja

Na czym polega: Jeśli nowy model idzie łeb w łeb ze starym, wniosek brzmi: nie migruj. Oszczędzasz czas i ryzyko przebudowy workflow.

Jak stosować: Traktuj „brak różnicy” jako pełnoprawny wynik, który uwalnia cię od presji ciągłego przesiadania się między modelami.

Na co uważać: Przy remisie decydującym kryterium staje się koszt i szybkość — uwzględnij je, zanim zostaniesz przy droższej opcji z przyzwyczajenia.

8.Uwzględnij liczbę tur i zużycie tokenów

Na czym polega: Im więcej tur i wywołań narzędzi robi model, tym bardziej puchnie kontekst i rośnie koszt — nawet przy tej samej jakości odpowiedzi.

Jak stosować: Dodaj do rubryki twarde metryki: liczba tur, liczba słów, zużyte tokeny, czas. Wyciągaj je z logów przebiegu (np. plików JSONL).

Na co uważać: Ładna odpowiedź osiągnięta w wielu turach może być droższa w skali. Patrz na koszt całkowitego przebiegu, nie na pojedynczą odpowiedź.

9.Zamień proces w powtarzalną komendę /benchmark

Na czym polega: Cały audyt można zamknąć w jednym skillu wywoływanym komendą typu /benchmark, który sam przeprowadza testy (30–40 min) i generuje raport z werdyktem.

Jak stosować: Zbuduj lub pobierz gotowy skill, sparametryzuj go modelami i poziomami wysiłku, a przy każdej premierze po prostu go odpalaj zamiast oglądać tutoriale.

Na co uważać: Autor rozdaje skill za darmo w opisie filmu, ale konkretnej implementacji w nagraniu nie pokazuje. Zanim mu zaufasz, przejrzyj, co skanuje i dokąd wysyła twoje dane.

10.Odzyskaj rolę sędziego zamiast gonić za hype’em

Na czym polega: Celem całego podejścia jest jasność — samodzielna, oparta na danych decyzja zamiast ulegania nagłówkom „ten model zabił tamten”.

Jak stosować: Ustal własny, stały rytuał oceny nowych modeli. Każdą premierę przepuszczaj przez ten sam zestaw zadań i rubrykę, i decyduj na podstawie wyników.

Na co uważać: Nie przesadź w drugą stronę — testowanie każdego modelu przez 40 minut też kosztuje czas. Rób to wybiórczo, gdy premiera realnie dotyczy twoich zadań.