O czym jest ten film
- Autor od miesięcy porównuje otwarte modele (Kimi, GLM, DeepSeek, Qwen) z komercyjnymi — każda premiera zaczyna się od obiecujących benchmarków, a kończy rozczarowaniem w praktyce.
- Kluczowy podział przebiega nie między „prostym a trudnym”, lecz między krótkim a długim: w krótkich zadaniach, nawet wymagających pogłębionego rozumowania, modele otwarte dorównują czołowym modelom komercyjnym — za ułamek ceny.
- W długich, wielogodzinnych procesach agentowych modele otwarte się sypią: gubią reguły, łamią wytyczne, utykają w nieskończonych iteracjach.
- Benchmarki to potwierdzają: w krótkich testach typu Terminal Bench 4.0 Kimi K3.1 Pro bywa lepsze od GPT-6 Astra i Claude’a Opus 5.5, ale w testach długohoryzontowych (Terminal Bench Science, Frontier Code 2.0) różnica jest przepaścista.
- Nawet najlepsze modele komercyjne nie rozwiązały problemu długich zadań — dlatego niezależnie od wyboru modelu potrzebna jest dopracowana inżynieria procesu.
- Autor przeprowadził kontrolowany eksperyment: trzy niezależne egzemplarze jego „fabryki oprogramowania AI” budowały tę samą grę Northstar — sterowane kolejno przez Claude’a, GPT i Kimi.
- Wyniki: Claude ukończył 12/12 zgłoszeń w ok. 14 godzin za 255 dolarów; GPT — 11/12 w dwukrotnie dłuższym czasie za 635; Kimi — zaledwie 5/12 w 44 godziny za 180.
- Paradoks kosztu: tańszy model okazał się najdroższy w przeliczeniu na ukończone zadanie (ok. 36 USD wobec 21 USD u Claude’a), bo wymagał najwięcej poprawek i najczęściej wołał człowieka o pomoc.
- Ślepa recenzja kodu wykonana przez osobnego agenta: Claude 8/10, GPT 7/10, Kimi 6/10.
- Wniosek praktyczny: nie rezygnuj z modeli otwartych — zmiksuj je. Silny model planuje i przegląda, tańszy pisze kod; jakość bez zmian, koszt złożonych zadań spada ponad dwukrotnie.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Długość zadania decyduje o wyborze modelu
Na czym polega: Modele otwarte i komercyjne osiągają praktycznie identyczne wyniki w krótkich zadaniach, nawet skomplikowanych i wymagających rozumowania. Różnica pojawia się dopiero, gdy proces rozciąga się na wiele godzin i dziesiątki kroków.
Jak stosować: Zanim wybierzesz model, sklasyfikuj zadania z backlogu na „krótkie, domknięte” i „długie, wieloetapowe”. Do pierwszej grupy śmiało wstawiaj tanie modele otwarte — w automatyzacjach i pojedynczych edycjach wygrywają ceną.
Na co uważać: Nie ekstrapoluj dobrego wyniku z krótkiego zadania na cały workflow — to najczęstszy błąd przy wdrażaniu tańszych modeli.
2.Nie ufaj benchmarkom mierzącym krótkie zadania
Na czym polega: Wynik z Terminal Bench 4.0 sugeruje, że Kimi K3.1 Pro prześciga GPT-6 Astra i Claude’a Opus 5.5. Testy ukierunkowane na długi horyzont (Terminal Bench Science, Frontier Code 2.0) pokazują coś odwrotnego — i to one lepiej przewidują pracę w realnym procesie.
Jak stosować: Przy doborze modelu do własnego workflow patrz w pierwszej kolejności na benchmarki długohoryzontalne, a najlepiej zrób własny krótki pilotaż na swoim kodzie i regułach.
Na co uważać: Producenci modeli pokazują głównie te testy, na których wypadają dobrze — pełna lista benchmarków często opowiada inną historię.
3.Porównuj koszt ukończonego zadania, nie cenę tokena
Na czym polega: Kimi kosztowało łącznie 180 dolarów wobec 255 u Claude’a, ale skończyło ledwie 5 z 12 zadań. W przeliczeniu na ukończone zgłoszenie wyszło najdrożej: ok. 36 USD wobec 21 USD u Claude’a. Tani token, drogie poprawki.
Jak stosować: Po każdym pilotażu policz: całkowity koszt podzielony przez liczbę faktycznie ukończonych i scalonych zadań. To jedyna uczciwa miara do porównań.
Na co uważać: Niska cena API bywa pułapką — jeśli model musi wielokrotnie iterować, rachunek finalny potrafi przerosić droższy model.
4.Otwartym modelom wyznaczaj wąski zakres
Na czym polega: Kimi radziło sobie dobrze z pojedynczymi edycjami, dopóki zadania były bardzo drobnoziarniste. Gdy zakres rósł, model przestawał stosować się do reguł — nawet najbardziej podstawowych, zapisanych wprost w pliku konfiguracji.
Jak stosować: Rozbijaj pracę na małe, samodzielne jednostki z kompletnym kontekstem w dokumencie planu. Im węższe zadanie, tym większa szansa, że słabszy model go nie zepsuje.
Na co uważać: Rozszerzanie zakresu „bo przecież idzie dobrze” to moment, w którym model otwarty zaczyna gubić wytyczne — najlepiej to monitorować w przeglądach.
5.Krytyczne pliki zabezpieczaj technicznie, nie tylko regułami
Na czym polega: Mimo wyraźnej reguły „nie ruszaj dokumentu PRD, jest tylko do odczytu”, model otwarty wielokrotnie próbował go edytować — i utykał, bo proces przeglądu blokował scalenie.
Jak stosować: To, czego nie wolno zmieniać, chroń na poziomie narzędzi: atrybuty tylko do odczytu, uprawnienia, automatyczne przeglądy, bramy scalania. Reguła pisana to za mało.
Na co uważać: Nawet zablokowana operacja kosztuje tokeny — każdy nieudany, próbny zapis to spalone pieniądze i czas.
6.Proces i reguły są konieczne nawet przy najlepszych modelach
Na czym polega: W badaniach nad zadaniami długohoryzontowymi nawet czołowe modele osiągają okolicę 40% skuteczności. Dopracowany proces — planowanie, przegląd, testowanie — podnosi wynik każdemu, ale modelom komercyjnym pomaga wyraźnie bardziej niż otwartym.
Jak stosować: Inwestuj w strukturę workflow niezależnie od tego, jakim modelem sterujesz: pętla „plan → implementacja → przegląd → test → scalenie” to podstawa trafności.
Na co uważać: Nie licz, że świetny proces wyrówna słabszy model w długich zadaniach — redukuje chaos, ale wady modelu zostają.
7.Planowanie i przegląd — dla silnego modelu, pisanie — dla tańszego
Na czym polega: W teście porównawczym grupa „Opus robił wszystko” i grupa „Opus planował i przeglądał, Kimi implementowało” dały równorzędne wyniki — ale przy złożonych zadaniach wariant wyłącznie na Opusie kosztował ponad dwukrotnie więcej.
Jak stosować: W dużym workflow rozdziel role: potężny model ładuje cały kontekst i zamienia złożony problem w konkretny plan; tańszy, ale zdolny model wykonuje plan punkt po punkcie.
Na co uważać: Cała jakość zależy od jakości planu. Lichy dokument planu przenosi problem z etapu projektowania na etap kosztownych poprawek.
8.Mierz autonomię liczbą interwencji człowieka
Na czym polega: W fabryce autora działa warstwa „menedżera”, który eskaluje decyzje w sytuacjach niepewności. Claude zgłaszał potrzebę pomocy sporadycznie, GPT mniej więcej raz na zadanie, a Kimi po kilka razy przy każdym — co przy dłuższej pracy zamienia się w realne obciążenie człowieka.
Jak stosować: Wbuduj w workflow punkt eskalacji i loguj, jak często model wymaga ingerencji. To jedna z najlepszych miar przydatności modelu w produkcji.
Na co uważać: Zbyt wysoki próg eskalacji („menedżer sam wszystko załatwi”) maskuje koszty — tylko że tym razem płatne Twoim czasem, nie tokenami.
9.Ślepa recenzja kodu jako obiektywny miernik porównań
Na czym polega: Porównując trzy wersje tej samej gry, autor zlecił ocenę całości kodu osobnemu agentowi, który nie wiedział, który model co napisał. Wynik: Claude 8/10, GPT 7/10, Kimi 6/10 — ranking spójny z resztą danych.
Jak stosować: Jeśli porównujesz modele lub dostawców, oceniaj efekty „na ślepo” — osobnym agentem oceniającym albo osobą bez wiedzy o pochodzeniu kodu. Ucinasz stronniczość.
Na co uważać: Ocena sędziego też pochodzi od modelu i bywa surowa albo łaskawa — traktuj ją jako punkt odniesienia, nie wyrocznię.
10.Buduj niezależność od jednego dostawcy
Na czym polega: Subskrypcje typu Codex czy Claude Code nie mają gwarancji wieczności, limity z miesiąca na miesiąc się zaostrzają, a ceny API przy intensywnej pracy bywają finansowo nierealne. Miks modeli to też polisa na tę niepewność.
Jak stosować: Zaprojektuj workflow tak, by można było podmieniać modele między etapami (planowanie / implementacja / przegląd) bez przebudowy całości, i regularnie testuj nowe modele otwarte na swoich zadaniach.
Na co uważać: Nie przestawiaj całej fabryki na słabszy model wyłącznie dla oszczędności — niezawodność procesu jest warta więcej niż niższy rachunek za tokeny.
Redakcyjne tłumaczenie
Premiera otwartego modelu i to samo rozczarowanie
Za każdym razem, gdy premierę ma nowy model o otwartych wagach — kolejny Kimi, GLM czy DeepSeek — łapię się na entuzjazmie. Publikowane wyniki wyglądają znakomicie: twórcy deklarują, że nowość dorównuje najsilniejszym zamkniętym modelom w kodowaniu wspomaganym AI, a czasem je przewyższa. I przez jeden dzień naprawdę wierzę, że doczekaliśmy: modele otwarte zrównały się z modelami frontier (Informacja dodatkowa: modele frontier to czołowe, najmocniejsze modele wiodących firm, ustawiające „granicę” możliwości; open-weight — modele udostępniane z wagami, które można uruchamiać na własnej infrastrukturze). Że nie musimy już wszystkiego kupować od wielkich graczy, takich jak Anthropic czy OpenAI. A potem siadam do testów. I za każdym razem wychodzi z tego rozczarowanie.
W czym dokładnie te modele mnie zawodzą — to sprawa o wiele bardziej zniuansowana. Bo szczerze: są imponujące i w wielu zastosowaniach faktycznie równają się najlepszym modelom komercyjnym, za ułamek ceny. Wystarczy spojrzeć na Terminal Bench 4.0: Kimi K3.1 Pro wypada tam odrobinę lepiej niż GPT-6 Astra i Claude Opus 5.5. Musiałem więc zadać sobie pytanie: o co chodzi? Dlaczego Kimi, Qwen, GLM i pozostali publikują modele z wynikami rzekomo przebijającymi czołówkę, a gdy próbuję z nimi zbudować coś realnego, wszystko się rozpada?
Właśnie temu poświęcam ten materiał: dlaczego nie mogę oprzeć całego swojego kodowania na modelach otwartych, jakie testy przeprowadziłem, żeby to udowodnić, i — co najważniejsze — co z tym zrobić. Bo szczerze kibicuję otwartym modelom i wierzę, że to przyszłość. Chcę włączać je do swojej pracy na tyle, na ile się da, nawet jeśli na razie nie oddajemy im całych procesów.
Niech nie będzie wątpliwości: lubię swoje subskrypcje Codex i Claude Code i korzystam z nich codziennie. Ale nie ma gwarancji, że będą trwać wiecznie — wszyscy widzimy, że limity zacieśniają się z miesiąca na miesiąc — i nie chcę od nich zależeć. A gdybym kiedyś musiał płacić za Opus 5.5 albo GPT-6 Astra według cennika API, przy dziennej liczbie tokenów, które zużywam, byłoby to finansowo nierealne.
Krótkie zadania: tu otwarte modele wygrywają bez dyskusji
Największy podział, jaki zaobserwowałem w tym roku, wygląda tak: modele komercyjne i otwarte dają równorzędne wyniki w zadaniach krótkich — nawet jeżeli są skomplikowane i wymagają pogłębionego rozumowania. Dawałem obu grupom mnóstwo różnorodnych poleceń, rezultaty oceniał osobny agent oraz ja sam, i w praktyce nie było między nimi różnicy. A ponieważ model otwarty jest znacznie tańszy, w tej kategorii — a zatem i w większości automatyzacji biznesowych oraz zastosowań agentowych — wygrywa.
Krążą ostatnio opracowania i głosy ekspertów, według których modele otwarte przejmą około 90 procent kroków korporacyjnych procesów agentowych; zwykle mowa o perspektywie dwóch–pięciu lat, bo masowej adopcji jeszcze nie ma, ale tempo jest zawrotne. Widzę to na własne oczy we współpracy z firmami: od pół roku przedsiębiorstwa wyjątkowo pilnują wydatków na tokeny, a gdy obrabiają dane wrażliwe, chcą uruchamiać modele lokalnie. Z grubsza dziewięć na dziesięć kroków w procesie agentowym to rutyna, z którą modele otwarte radzą sobie równie dobrze — za mniej więcej czwartą część ceny nawet najtańszego modelu zamkniętego, takiego jak Haiku 5.5. Jeśli agent ma być jednym z ogniw większej automatyzacji, nie ma sensu wpychać tam GPT-6 Astra ani Opus 5.5: większość rzeczy załatwi model z niższej półki, wielokrotnie tańszy.
I zresztą — mówiąc „z niższej półki”, muszę się sam poprawić. Bo przy krótkich zadaniach modele otwarte po prostu nie są słabsze.
Długie procesy: tu wszystko się rozsypuje
Problem zaczyna się tam, gdzie w agentowym kodowaniu liczy się to najbardziej: przy zadaniach rozciągniętych w czasie. Gdy próbuję oprzeć na otwartym modelu większy proces — na przykład moją „fabrykę oprogramowania AI” — zawodzi mnie za każdym razem.
Wyjaśnijmy, o co chodzi. Mój obraz fabryki to w dużej uproszczeniu cała moja praca z AI w kodzie. Nie otwieram po prostu Claude Code czy Kimi Code i nie wysyłam zlecenia. Mam zestaw „umiejętności” i reguł, które prowadzą mnie i agenta przez cały cykl: wspólne planowanie, implementację według planu, a potem przegląd i przetestowanie — moje oraz drugiego agenta — żeby przed scaleniem zmian mieć pełne przekonanie o jakości. Tak pracuję przy każdej poprawce błędu i każdej nowej funkcji. W takim układzie jest jednak mnóstwo okazji do dryfu — to naturalna cecha każdego rozbudowanego kodu i wieloetapowego procesu. I właśnie na tym modelei otwarte się wywracają.
Dotyczy to nawet Kimi K3.1 Pro, do którego ciągle wracam, bo to rzeczywiście najświeższe i najmocniejsze wydanie wśród modeli otwartych. Gdybym miał to ująć w jednym słowie: uwaga. Przy długich procesach otwarty model nie potrafi utrzymać uwagi na wszystkich regułach i na całym kontekście, które powinien respektować. Gdy pracuję z Opusem 5.5 — z moimi regułami, złożoną bazą kodu, koniecznością rozumienia, gdzie coś zintegrować i co sprawdzić — model rozumie i mnie, i kod, nawet gdy działa godzinami. Z Kimi bywa odwrotnie: pojedyncze edycje wychodzą dobrze, dopóki trzymam bardzo drobny zakres. Wystarczy poszerzyć zadanie, a model zaczyna gubić reguły — nawet najbardziej podstawowe, zapisane wprost w moich regułach globalnych, na przykład: nie ruszaj dokumentu wymagań produktowych (PRD), jest tylko do odczytu. W testach z ostatnich tygodni Kimi podejmowało próby edycji tego pliku wielokrotnie, po czym utykało, bo mam ostre kryteria dopuszczania zmian do scalenia. Poprzeczkę stawiam wysoko i Kimi, bez iterowania w kółko, po prostu nie sięga do niej. Co gorsza, przez masę tokenów zużywanych na prostowanie drobnych błędów wychodzi ostatecznie drożej niż Claude.
Benchmarki mówią to samo — wystarczy spojrzeć na właściwe
To samo widać na pełnej liście testów, a nie tylko na tych, które producent modelu chce pokazać. W części benchmarków — takich jak Terminal Bench 4.0 — Kimi K3.1 Pro i inne modele otwarte rzeczywiście są na poziomie czołówki albo lepsze. Więc nie jest tak, że wyniki wymyślono. Ale w testach ukierunkowanych na zadania długoterminowe, jak Terminal Bench Science czy Frontier Code 2.0, różnica jest ogromna — i to lepiej odpowiada mojemu doświadczeniu: przy dłuższych zadaniach otwartym modelom daleko do Gemini 4 Carbon czy Claude’a Opus 5.5. Szkoda tylko, że to Terminal Bench 4.0 nie opisuje mojej codziennej pracy.
Nie chcę przy tym wywoływać wrażenia, że modele komercyjne mają problem długich zadań z głowy. Wciąż się z nim zmagają — widzę to i w cudzych badaniach, i we własnych. Po prostu zmagają się dużo mniej: w jednym z badań GPT-5.6 Soul uzyskał 41,6 procent, a Kimi K3 — 22,1 procent. To przepaść. Nadal potrzebujemy inżynierii procesu (ang. harness engineering), czyli dopracowanego szkieletu reguł, narzędzi i punktów kontrolnych, w którym pracuje agent — bez niego nawet najlepsze modele nie osiągną użytecznej trafności w dużych procesach kodowania. Ale — i to jest ciekawe — nawet bardzo dobrze ułożony proces nie pomaga modelom otwartym w podobnym stopniu co komercyjnym.
Fragment sponsorski: TripleTen
Sponsorem odcinka jest TripleTen, firma tworząca programy dla inżynierów seniorów, którzy chcą naprawdę dobrze budować systemy AI. Sztuczna inteligencja była w tym roku w USA główną powoływaną przyczyną zwolnień, ale zapotrzebowanie na inżynierów nie zniknęło — przesunęło się, i to na stanowiska seniorskie. Narzędzie AI można poznać w weekend, ale zdobycie praktyki w utrzymywaniu systemów AI na produkcji we własnym zakresie jest bardzo trudne — i do tego służy TripleTen. Dwa programy, AI System Engineering i AI Machine Learning, są skierowane do inżynierów z kilkuletnim doświadczeniem produkcyjnym, więc to nie oferta dla początkujących. W ramach kursu buduje się pięć projektów, które składają się w jeden spójny system — na przykład pipeline wyszukiwania z ewaluacją oraz agent wsparcia podpięty do Jiry przez MCP — a potem broni się ich przed prawdziwym inżynierem, co bardzo mi się podoba. Projekty ekspertów są publicznie dostępne na GitHubie, a instruktorzy mają jawne profile — choćby Muhammad Sheriff, który pracował w AMD, Microsoftie i Amazonie. Jeśli masz za sobą kilka lat inżynierii i chcesz wejść głębiej w systemy AI, linki do obu programów znajdziesz w opisie.
Test kontrolny: ta sama gra w trzech fabrykach
Wszystko, o czym dotąd mówiłem, opiera się na badaniach i na doświadczeniach z całego roku porównywania modeli zamkniętych i otwartych. Chciałem jednak przejść od wrażeń do liczb. Przygotowałem więc ściśle kontrolowany test: zbudowałem w mojej fabryce oprogramowania dokładnie tę samą aplikację trzykrotnie — z Claude’em, z GPT-6 i z Kimi K3.1 Pro, przy czym każdy model dostał własny, niezależny egzemplarz fabryki. Zadaniem była gra wideo. Wybrałem grę, bo sama w sobie jest dla mnie frajdą, dobrze się pokazuje na wizji, a przy tym stanowi sensownie złożony problem — nie byle jaka aplikacja webowa — więc porządnie wypycha modele do granic.
Gra nazywa się Northstar. Pełną wersję buduje mi teraz na poważnie moja główna fabryka; tu chodziło o edycję uproszczoną, powstałą w dwunastu pełnych obiegach procesu. Przygotowałem dwanaście zgłoszeń (ticketów) — dwanaście rund pełnej pętli: planowanie, implementacja, przegląd, test, scalenie.
Wersja od Claude’a powstawała z Opusem 5.5 przy planowaniu i przeglądach oraz Sonnetem 5.5 jako koniem roboczym. I jest po prostu dobra: solidna fizyka, w pełni działająca pętla rozgrywki. Animacje walki wychodzą co najwyżej komicznie, a bohater wygląda jak ciężki szkic, ale całość gra.
Wersja od GPT: planowanie i przegląd na GPT-6 Astra, implementacja na GPT-6.1 Soul. Panel interfejsu wygląda brzydko, ale gdy wejść w rajd, robi się dobrze. Każda fabryka startowała z identycznego zestawu grafik, stąd wizualne podobieństwo wszystkich wersji. GPT wybrał mocno oddaloną kamerę; zostały też drobiazgi do domknięcia — porozrzucane hitboxy, ślady debugowania — więc nie wygląda tak dobrze jak u Claude’a. Mniej więcej przyzwoicie. Do obecnego stanu doszedł jedenastoma zgłoszeniami. Moim celem zresztą wcale nie było polerowanie gry, tylko przepchnięcie dużej liczby zgłoszeń przez bardziej złożoną bazę kodu, żeby zobaczyć, jak dobrze model dobudowuje funkcje i testuje własną robotę.
Wreszcie wersja od Kimi — z kamerą oddaloną jak u Claude’a. Gdy zaczynam rajd, interfejs wygląda wręcz najczyściej z całej trójki, naprawdę mi się podoba. Problem w tym, że Kimi zbudowało najmniej: utknęło w poprawianiu drobiazgów i iterowaniu nad pojedynczymi zgłoszeniami. Przykład: między rajdami ma działać sklep, w którym ulepszasz postać. W wersjach Claude’a i OpenAI jest — Kimi nigdy do niego nie doszło.
Tak, wiem: jeden przykład, jedna aplikacja. Potrzebowałem jednak czegoś namacalnego, co odda to, co widzę po dziesiątkach aplikacji budowanych na modelach komercyjnych i otwartych. Samych zgłoszeń nie jest wiele, ale wydałem na te testy dziesiątki milionów tokenów — specjalnie pozwalałem modelom iterować i główkować, żeby zdobyć prawdziwe dane. I wszystko wskazuje to samo, co widziałem przez cały rok.
Twarde liczby: czas, koszt, interwencje, ocena kodu
Claude ukończył dwanaście z dwunastu zgłoszeń w około czternaście godzin; pełny obrót fabryki zajmował mu średnio godzinę, co przy rozmiarze każdego zadania jest bardzo dobrym tempem. Przechodził całą ścieżkę: planowanie, budowa, przegląd, test, scalenie.
GPT potrzebował dwa razy więcej czasu i nawet nie skończył — jedenaście na dwanaście. Już między modelami komercyjnymi różnica jest więc spora; między innymi dlatego większością moich procesów steruje dziś Opus 5.5. Sam przebieg wyglądał jednak stabilnie: nic go mocno nie blokowało, a efekt końcowy był dobry.
A Kimi? Pięć zgłoszeń na dwanaście — w czterdzieści cztery godziny. Kilka razy utykało na długie godziny. Właśnie dlatego nie zdążyło ze sklepem i pozostałymi funkcjami. Frustrujące było to, że wciąż podejmował próby robienia rzeczy, których reguły zabraniają; przegląd to wyłapywał i wracało iterowanie. Po prostu nie potrafił zastosować się do wszystkiego, co fabryka narzuca.
Mogłbym oczywiście poluzować fabrykę — propuścić drobne błędy, żeby Kimi wyglądał lepiej na tle konkurencji. Ale nie zamierzam. Dopracowanie procesu przeglądu zajęło mi mnóstwo czasu i nie będę obniżać poprzeczki pod słabsze modele, żeby więcej przechodziło. Gdy przełączam się między modelami komercyjnymi, każdy z nich od razu „łapie” moją fabrykę, kod i reguły. Przy otwartych wygląda to na wadę fundamentalną: w długich zadaniach nie są w stanie żonglować wszystkim, na co powinny zwracać uwagę.
Teraz liczby, które mnie najbardziej fascynują. Całkowity koszt zbudowania aplikacji — pełne dwanaście zgłoszeń — u Claude’a: 255 dolarów. W praktyce oczywiście płacę subskrypcją, ale wycena API to jedyne, co da się uczciwie porównać. GPT: 635 dolarów — pracował dwa razy dłużej, ale wyszedł ponad dwa razy drożej. Ciekawe. Kimi: 180 dolarów, co wcale nie jest tanio, bo przecież nie ukończyło pracy. I tu sedno: niska cena modelu nie oznacza niskiego kosztu zadania. Jeśli model musi więcej iterować i częściej się mylić, finalnie może wyjść drożej niż model droższy — dokładnie to widuję w otwartych modelach w swoich procesach. W przeliczeniu na ukończone zgłoszenie: Claude 21 dolarów, GPT 63, Kimi prawie 36.
Do tego interwencje człowieka. Moja fabryka ma warstwę „menedżera” nad całym procesem: pilnuje przebiegu i alarmuje, gdy pojawia się niepewność wymagająca mojej decyzji — albo sam podejmuje wybór za mnie. Z Claude’em wszystko toczy się gładko. OpenAI zgłaszał się mniej więcej raz na zgłoszenie. Kimi potrzebował pomocy po kilka razy przy każdym — na dłuższą metę byłoby to męczące. Claude jest po prostu znacznie bardziej samodzielny i ma większą pewność we własne implementacje, którą — co ważne — wydaje się zasługiwać. Nikt nie chce modelu pewnego siebie bez powodu, sypiącego błędami; Claude jest solidny i sam to wie.
Ostatnia miara: osobny agent wykonał ślepą recenzję całej bazy kodu — bez wiedzy, który model co napisał. Claude: 8 na 10. GPT: 7 na 10. Kimi: 6 na 10. Sześć na dziesięć to w porządku — Kimi w końcu doprowadziło kod do przyzwoitego stanu. Po prostu droga do tego stanu była bolesna.
Rozwiązanie: miks modeli zamiast wyboru „albo–albo”
Wiemy już, dlaczego nie możemy oddać długich procesów kodowania tańszemu modelowi otwartemu. Nawet z dużą liczbą iteracji wyjdzie drożej niż praca z Claude’em, a niezawodność będzie niższa. Co zatem robić — przynajmniej na dziś?
Mój cel docelowy to oparcie wszystkiego na modelach otwartych i mocno wierzę, że kiedyś tam dojdziemy — że nie będziemy skazani na modele frontier w żadnym ogniwie, jeśli nie zechcemy. Po prostu jeszcze nas tam nie ma. To jednak nie znaczy, że dziś trzeba z otwartych modelów całkiem zrezygnować.
Od dłuższego czasu eksperymentuję z mieszaniem modeli i dostawców: dobieram model do zadania według kosztu i jakości. Na przykład Opus do planowania i przeglądów w większym procesie, Kimi jako koń roboczy. Takie połączenia sprawdzają się u mnie znakomicie. Wkrótce pokażę, jak taki układ skonfigurować krok po kroku — jest też film na kanale, w którym wchodzę w te liczby znacznie głębiej — ale z grubsza: da się miksować modele bez ofiary na jakości kodu, a oszczędności czasu i pieniędzy są realne.
Test wyglądał tak. Grupa kontrolna: kilka procesów agentowych prowadzonych wyłącznie przez Opusa — planowanie, implementacja, przegląd, wszystko. Grupa druga: Opus planował i przeglądał, a implementację wykonywało Kimi — czyli dokładnie tam, gdzie u mnie płynie najwięcej tokenów. Wyniki w obu grupach okazały się praktycznie identyczne, zarówno przy prostych, jak i złożonych zgłoszeniach. To najlepsza możliwa wiadomość. Przy prostych zadaniach różnice w koszcie były niewielkie, ale przy złożonych praca wyłącznie na Opusie kosztowała ponad dwukrotnie więcej — przy tym samym efekcie końcowym.
Sedno całego rozwiązania: potężniejszy model dostaje zadanie tam, gdzie trzeba załadować cały kontekst i przestrzegać wszystkich reguł — czyli na etapie planowania. Gdy złożony problem zostaje zamknięty w dokumencie planu, słabszy, choć wciąż bardzo zdolny model realizuje go znakomicie. Dlatego modele open-weight z powodzeniem można używać już dziś — tylko nie do wszystkiego w obrębie dużych procesów.
Moja główna rekomendacja jest więc następująca: jeśli chcesz oszczędzać tokeny i przyspieszyć pracę, eksperymentuj z otwartymi modelami i używaj ich jako konia roboczego, który pisze kod — a tę pracę „obłóż” planowaniem i przeglądem na modelu frontier. Dokładny sposób konfiguracji opiszę w kolejnych materiałach. Napiszcie w komentarzach, co Was bardziej ciekawi: więcej danych czy praktyczna instrukcja budowy takich systemów?
Mam nadzieję, że ten materiał był wartościowy — od zdefiniowania problemu z otwartymi modelami, przez twarde dane, aż po rozwiązanie. Jeśli tak, a czekacie na więcej o inżynierii agentowej i modelach open-weight, like i subskrypcja dużo dla mnie znaczą. Do zobaczenia w następnym odcinku.