Który model AI najlepiej zapisuje przepisy? Test 21 modeli na polskich i angielskich przepisach

Każdy przepis zapisany w ZapiszPrzepis przechodzi przez model AI. Model wyciąga z niego składniki, ilości, kroki, temperatury i czasy, porządkuje je według reguł aplikacji, a przepis z obcej strony jeszcze tłumaczy. Zaczęło się od tłumaczenia, bo przepisy z angielskich blogów zapisywały się przetłumaczone w połowie: „1 funt” obok gramów, „mięso mielone z indyka (94% chude)”, „mały makaron (np. ditalini, alfabet)” i krok „Umieścić mięso mielone z indyka w misce”. Poprawiłem prompt i kod, a potem sprawdziłem, który model ma tę pracę wykonywać. Najpierw 11 modeli pod kątem formatu, potem 21 modeli pod kątem tego, czy zapisany przepis zgadza się z oryginałem.

W skrócie:

• Czołówka to remis. Claude Haiku 5.5, Gemini 3.5 Flash, Gemini 3.1 Flash-Lite, gpt-4.1-mini i gpt-5.4-mini mieszczą się w tych samych przedziałach ufności.
• W aplikacji zostaje gpt-5.4-mini. Na pełnym wejściu ma 0,09 błędu krytycznego na przepis, czyli mniej więcej jeden na jedenaście przepisów, i odpowiada w 4,4 sekundy.
• Droższy model nie był lepszy. Claude Sonnet 5.5 kosztował około dziesięć razy więcej niż Claude Haiku 5.5 i nie wypadł lepiej.
• Dostawca znaczy więcej niż rozmiar modelu. Ten sam gpt-oss przez OpenRouter robił od zera do ponad 12 błędów krytycznych na odpowiedź, zależnie od tego, kto go uruchomił.
• Więcej rozumowania nie pomogło gpt-5.4-mini.
• Polszczyzna modeli w chmurze nie różnicuje. W mojej ślepej ocenie wszystkie 20 odpowiedzi z różnych modeli dostało 5 na 5.
• Modele lokalne wypadają najsłabiej, zwłaszcza na angielskich przepisach. qwen3:14b pisze wtedy łamaną polszczyzną.

Jak ZapiszPrzepis wyciąga przepis

ZapiszPrzepis zapisuje przepis z linku: pobiera stronę, a model językowy zamienia jej tekst w JSON z tytułem, składnikami, krokami, czasem i kategorią. Składnik ma cztery pola: ilość, jednostkę, nazwę i miarę domową, na przykład 480 ml, a obok „2 szklanki”. Prompt ma około 40 reguł, od kategorii po formę kroków: bezokolicznik i żadnej narracji, czyli „Przełożyć do miski”, a nie „Teraz przekładamy…”.

Przepis z obcej strony ten sam prompt musi jeszcze przetłumaczyć i dopasować do polskiej kuchni. Miał na to jedno zdanie: przetłumacz na polski i zamień amerykańskie miary na metryczne (szklanka ≈ 240 ml, łyżka ≈ 15 ml). O funtach, uncjach, stopniach Fahrenheita i markach nie mówił nic.

Dlaczego nie DeepL

Pierwszy odruch to dołożyć DeepL. Tylko że tłumaczenie to jeszcze nie lokalizacja. DeepL zamieniłby „finely grated” na „drobno starte”, a glosariusz przypiąłby „ground turkey” do „mięsa mielonego z indyka”. Trzech rzeczy by jednak nie zrobił:

• nie przeliczy funtów na gramy ani °F na °C,
• nie przeniesie notatki („pokrojone”, „wyciśnięta”) z pola miary do nazwy składnika,
• nie zamieni amerykańskiej marki składnika na produkt, który kupisz w polskim sklepie.

Byłaby to też druga płatna usługa i drugi przebieg, który tłumaczy krótkie pola JSON bez kontekstu, a samotne „splash” łatwo zostaje „pluskiem”. Z sześciu zgłoszonych problemów zostałyby cztery.

Co zmieniłem

Zmiana ma trzy części.

1. Język źródła rozpoznaje kod, zanim zapyta model. Liczy polskie znaki diakrytyczne i częste słowa polskie i angielskie w tekście strony. Atrybut lang jest tylko podpowiedzią, bo wiele polskich blogów ma w szablonie lang="en-US".
2. Obce źródło dostaje dodatkowy blok reguł, doklejany do wspólnego promptu: przelicz funty, uncje, kostki masła i °F (także w krokach), przetłumacz każde słowo, pisz kroki tak jak polska książka kucharska, nazywaj produkty tak jak polskie sklepy (literki, kółka, kolanka), pomijaj amerykańskie oznaczenia chudości mięsa. Marka zostaje, gdy jest samą potrawą (domowe SpaghettiOs), i znika, gdy jest składnikiem. Osobnego promptu po angielsku nie pisałem, bo rozjechałby się ze wspólnym przy pierwszej zmianie reguł.
3. Kontrole w kodzie, bo model części reguł nie słuchał. Dwa błędy przetrwały próby na gpt-4.1-mini mimo reguł w prompcie, więc kod pilnuje ich sam. W polu miary domowej zostaje tylko polska miara („półtorej szklanki”, „płaska łyżka”, „1 saszetka”). Notatka trafia do nazwy, amerykańska waga znika, gdy są gramy, a miara, która powtarza ilość, też znika. Ta kontrola działa dla każdego źródła: z 53 miar zapisanych w bazie zmieniła 14 i każda była notatką albo amerykańską jednostką. Dla obcych źródeł kod usuwa jeszcze procent przed „chude” i zostawia szklankę albo łyżkę tylko wtedy, gdy podaje ją oryginał.

Przed i po, na trzech przepisach z howsweeteats.com, od których wszystko się zaczęło:

Dwie rzeczy nadal nie są idealne. Model napisał „Spaghettios” zamiast „SpaghettiOs”, jak w oryginale. A kontrola szklanek sprawdza cały przepis, nie każdy składnik, więc wymyślone „1/2 szklanki” przejdzie, jeśli oryginał podaje „1/2 cup” przy innym składniku.

Pierwszy test: czy model trzyma się formatu

Pierwszy test sprawdzał, czy model przestrzega reguł aplikacji: 26 przepisów (25 polskich i jeden angielski), 11 modeli (5 z OpenAI, 3 z darmowego Groqa i 3 lokalne), każdy przepis dwa razy. Wynik oceniał kod aplikacji na surowym JSON-ie, zanim zadziałają kontrole.

Liczby to sumy z 52 ekstrakcji na model. Błąd formatu jest jednego z trzech rodzajów:

gpt-5.4-mini zrobił najmniej błędów formatu, prawie nie mylił formy kroków i odpowiadał najszybciej z modeli OpenAI, więc po tym teście zastąpił w aplikacji gpt-4o-mini. Bielik wypadł najgorzej: w ponad 200 składnikach wpisywał miarę do złego pola i nie pisał kroków w bezokoliczniku.

Ten test mówił jednak tylko, czy model trzyma się formatu. Nie mówił, czy zapisany przepis jest prawdziwy: czy ilości i temperatury zgadzają się z oryginałem i czy niczego nie brakuje. Do tego potrzebny był drugi test.

Drugi test: czy zapisany przepis zgadza się z oryginałem

Przepisy i wzorzec

Zestaw to 50 przepisów zapisanych w aplikacji: 25 z polskich stron i 25 z angielskich blogów z USA, Wielkiej Brytanii, Australii i Indii. Trzy odpadły, bo zapisana strona nie zawierała przepisu (paywall albo pusta strona). Dwa kolejne odpadły tylko w wariancie z samym markdownem, bo przepis zaczynał się za pierwszymi 10 tysiącami znaków.

Dla każdego przepisu powstał wzorzec: składniki z ilościami, kroki, temperatury, czasy, porcje i zdjęcia przypisane do kroków. Przygotowały go niezależnie dwa modele: Claude Fable 5.1 (w Claude Code) i Gemini 3.5 Flash z wysokim poziomem rozumowania. Tam, gdzie się zgadzały, wzorzec był gotowy. Każdą różnicę rozstrzygałem sam, na ślepo, bez wiedzy, który model co napisał. Do tego sprawdziłem z oryginałem 31 losowo wybranych miejsc, w których się zgadzały, i wszystkie 31 były poprawne. Ustaliłem też trzy zasady: wartość z podanego zakresu jest poprawna, przepis musi zachować oba tryby piekarnika (góra-dół i termoobieg), a policzony czy oszacowany łączny czas nie jest błędem.

Jedno zastrzeżenie wprost: wzorzec przygotowały modele z tych samych rodzin co część zawodników (Claude i Gemini). To ryzyko zmniejsza moja kontrola różnic, ale go nie usuwa, a modele Claude i Gemini są akurat w czołówce.

Co liczę jako błąd

Model oceniam tylko z tego, co dostał na wejściu. Przedziały ufności to 95%, liczone metodą bootstrap po przepisach (2000 losowań). Każdy przepis szedł przez każdy model dwa razy, z tym samym promptem co w produkcji.

Polszczyznę oceniłem też sam: 20 odpowiedzi z różnych modeli, na ślepo. Wszystkie dostały 5 na 5, więc płynność języka nie odróżnia tych modeli, a sędzia AI nie miałby czego się ode mnie nauczyć. Dlatego go nie użyłem.

Dwa warianty wejścia

W produkcji model dostaje tekst strony w markdownie i jej HTML, każde do 20 tysięcy znaków. Darmowy Groq tego nie przyjmie: limit to 8000 tokenów na minutę i to jest zarazem największe zapytanie, jakie można wysłać, a pełne zapytanie ma 10–13 tysięcy tokenów. Dlatego test ma dwa warianty: pełny (markdown i HTML, jak w produkcji) i sam markdown (pierwsze 10 tysięcy znaków). Wariant z samym markdownem przeszły wszystkie modele, więc w nim porównanie jest pełne.

Modele

• 5 z OpenAI, bezpośrednio: gpt-4o-mini, gpt-4.1-mini, gpt-5-mini, gpt-5-nano i gpt-5.4-mini, ten ostatni także z wyższym poziomem rozumowania (low);
• 10 przez OpenRouter: Claude Haiku 5.5 i Sonnet 5.5, Gemini 3.5 Flash i 3.1 Flash-Lite, Gemma 4 31B, GLM 5.3, Qwen 3.7 Plus, DeepSeek v4 Flash, Mistral Medium 3.1 i Llama 4 Maverick;
• 3 na darmowym Groqu: gpt-oss-120b, gpt-oss-20b i qwen3.8-27b. Oba gpt-oss puściłem też przez OpenRouter, żeby porównać dostawców;
• 3 lokalne, przez Ollamę: Bielik 11B v2.3 i v3.0 (kwantyzacja Q4_K_M) oraz qwen3:14b.

Wyniki

Dwa wyjątki od pełnego zestawu. Darmowy Groq odrzuca każde zapytanie dłuższe niż 8000 tokenów, a sześć angielskich przepisów nie mieści się w tym limicie nawet z samym markdownem (przy gpt-oss-20b trzy). Wiersze Groqa oznaczam znakiem †: są liczone bez tych najdłuższych przepisów, o czym trzeba pamiętać przy każdym porównaniu. Modelom lokalnym ograniczyłem odpowiedź do 4096 tokenów, bo qwen3:14b na jednym przepisie zapętlił się na ponad 17 tysięcy tokenów (zwykły przepis to około 1300). Ucięta odpowiedź liczy się jako zepsuty JSON. Kolumna „Przepisy PL/EN” mówi, ile przepisów każdy model dostał.

Kolor słupka mówi, jak wywołałem model, a nie kto go zrobił: przez API OpenAI, przez OpenRouter, na darmowym Groqu albo lokalnie przez Ollamę. Dlatego gpt-oss, model OpenAI, ma kolor Groqa albo OpenRoutera.

Poprawność, sam markdown

Krytyczne, poważne i drobne to średnia liczba błędów na przepis; w nawiasie 95-procentowy przedział ufności. Krytyczne PL i EN liczą osobno przepisy z polskich i angielskich stron. Polszczyzna to błędy LanguageTool na 1000 słów. † darmowy Groq odrzucił najdłuższe angielskie przepisy, więc te wiersze są liczone bez nich.

Koszt i niezawodność, sam markdown

Mediana to czas jednej ekstrakcji; gwiazdka oznacza czas przez OpenRouter zmierzony osobno na 6 przepisach. Koszt to kwota za przepis z rozliczenia OpenRoutera; OpenAI i Groq nie podawały jej w odpowiedzi, a modele lokalne nic nie kosztują, więc tam kreska. Odrzucone to zapytania, których darmowy Groq nie przyjął (limit 8000 tokenów). Zepsuty JSON to odpowiedzi, których nie dało się odczytać, w tym ucięte limitem 4096 tokenów u modeli lokalnych. Przepisy PL/EN mówią, ile przepisów model dostał.

Poprawność, pełne wejście

Krytyczne, poważne i drobne to średnia liczba błędów na przepis; w nawiasie 95-procentowy przedział ufności. Krytyczne PL i EN liczą osobno przepisy z polskich i angielskich stron. Polszczyzna to błędy LanguageTool na 1000 słów. † darmowy Groq odrzucił najdłuższe angielskie przepisy, więc te wiersze są liczone bez nich.

Koszt i niezawodność, pełne wejście

Mediana to czas jednej ekstrakcji; gwiazdka oznacza czas przez OpenRouter zmierzony osobno na 6 przepisach. Koszt to kwota za przepis z rozliczenia OpenRoutera; OpenAI i Groq nie podawały jej w odpowiedzi, a modele lokalne nic nie kosztują, więc tam kreska. Odrzucone to zapytania, których darmowy Groq nie przyjął (limit 8000 tokenów). Zepsuty JSON to odpowiedzi, których nie dało się odczytać, w tym ucięte limitem 4096 tokenów u modeli lokalnych. Przepisy PL/EN mówią, ile przepisów model dostał.

Jakie to błędy

Błędy krytyczne według rodzaju, zliczone ze wszystkich odpowiedzi w wariancie z samym markdownem:

Co z tego wynika

Czołówka to remis

Najmniej błędów krytycznych na samym markdownie mają Claude Haiku 5.5 (0,01), Gemini 3.5 Flash (0,02), Gemini 3.1 Flash-Lite (0,03) i gpt-4.1-mini (0,04). Ich przedziały ufności nakładają się jednak z gpt-5.4-mini (0,08), więc przy 50 przepisach nie da się uczciwie powiedzieć, który z nich jest najlepszy. Różnica, którą da się zmierzyć, dzieli czołówkę od reszty: modele lokalne, gpt-5-nano, gpt-oss przez OpenRouter i Llama 4 Maverick robią wielokrotnie więcej błędów krytycznych.

W aplikacji zostaje gpt-5.4-mini

W ustawieniu takim jak w aplikacji, z HTML strony, gpt-5.4-mini ma 0,09 błędu krytycznego na przepis, najmniej błędów poważnych (0,41) i drobnych (0,56) spośród modeli w tym wariancie oraz medianę 4,4 sekundy. Zmiana na model z czołówki nie dałaby mierzalnej poprawy, a gpt-5.4-mini wygrał też pierwszy test, ten z formatem.

Droższy model nie był lepszy

Claude Sonnet 5.5 kosztował przez OpenRouter 0,0215 USD za przepis i miał 0,06 błędu krytycznego na przepis. Claude Haiku 5.5 za 0,0022 USD miał 0,01, a Gemini 3.1 Flash-Lite za 0,0065 USD miał 0,03. Przy tysiącu przepisów to około 21,50 USD wobec 2,20 USD, bez lepszego wyniku za wyższą cenę.

Ten sam model, inny dostawca, inny wynik

To największe zaskoczenie testu. OpenRouter rozdzielał zapytania do gpt-oss między ponad dziesięć firm, które uruchamiają ten model u siebie, przy tych samych ustawieniach zapytania. Wynik zależał od tej firmy bardziej niż od rozmiaru modelu:

To tłumaczy, dlaczego gpt-oss-120b wywołany bezpośrednio na Groqu nie zrobił żadnego błędu krytycznego na polskich przepisach, a przez OpenRouter miał ich 0,80 na przepis. Jeśli używasz OpenRoutera do zadania, w którym liczy się dokładność, wskaż w zapytaniu dostawców, których sprawdziłeś. Inaczej trafisz na losowego.

Więcej rozumowania nie pomogło

gpt-5.4-mini na poziomie rozumowania low miał 0,24 błędu krytycznego na przepis, a na najniższym (none) 0,08. Przedziały na skraju się nakładają, więc nie twierdzę, że rozumowanie szkodzi, ale na pewno nie pomogło: model generował więcej tokenów, odpowiadał wolniej (7,2 zamiast 4,6 sekundy) i częściej gubił składniki.

HTML nie zmniejsza liczby błędów krytycznych

Modele OpenAI miały na samym markdownie mniej więcej tyle samo błędów krytycznych co z HTML, przy około połowie wejścia: gpt-5.4-mini 0,08 wobec 0,09, gpt-4o-mini 0,20 wobec 0,19. HTML zostaje jednak w aplikacji, bo z niego biorą się zdjęcia kroków.

Polszczyzna: ślepa ocena nie widzi różnicy

W ślepej ocenie wszystkie odpowiedzi dostały ode mnie 5 na 5. LanguageTool znajduje między modelami różnice: na pełnym wejściu od 0,9 błędu na 1000 słów u Bielika 11B v2.3 i 1,1 u gpt-4o-mini do 6,8 u gpt-5-nano. Przy jego trafności to sygnał kolejności, nie ocena.

Wyjątkiem jest qwen3:14b z wynikiem 18,5 błędu na 1000 słów. Na angielskich przepisach pisze łamaną polszczyzną, a jego błędy zostały sprawdzone ręcznie i są prawdziwe: „pudr”, „vanilię”, „nacisknij”, „wyciąnij”, „mikrowarce”, „auberginy” zamiast bakłażanów.

Bielik i modele lokalne

Modele lokalne wypadają najsłabiej, a po dołożeniu angielskich przepisów jeszcze słabiej. Na samym markdownie Bielik 11B v2.3 ma 0,62 błędu krytycznego na przepis, v3.0 0,64, a qwen3:14b 1,00. Na pełnym wejściu odpowiednio 0,82, 1,68 i 1,17, więc tam nowszy Bielik wypada gorzej niż 2.3.

Polskie przepisy idą im znacznie lepiej niż angielskie. Bielik 11B v2.3 ma na polskich 0,24 błędu krytycznego na przepis, a na angielskich 1,02 (sam markdown). qwen3:14b na polskich prawie się nie myli (0,02), a na angielskich ma 2,13. Bielik najczęściej gubi składniki i myli temperatury, a do tego nie trzyma formatu aplikacji: v2.3 ma 37,9 drobnych błędów na przepis. Polszczyznę ma przy tym poprawną, z najmniejszą liczbą błędów na pełnym wejściu (0,9 na 1000 słów), co zgadza się z pierwszym testem: zna polski, ale nie trzyma formatu.

Lokalnie przepis trwa niecałą minutę na Bieliku i półtorej minuty na qwen3:14b na samym markdownie, a z HTML dłużej. qwen3:14b z kontekstem 24 tysięcy tokenów nie mieści się w 12 GB pamięci karty, więc część modelu liczy procesor z pamięci RAM. Stąd jego czasy; na komputerze z większą kartą byłby szybszy.

Inne obserwacje

• DeepSeek v4 Flash w 19 odpowiedziach nie oddał poprawnego JSON-a, generował średnio ponad 12 tysięcy tokenów na odpowiedź i potrzebował ponad dwóch minut.
• Mistral Medium 3.1 i Llama 4 Maverick najczęściej gubią składniki: odpowiednio 20 i 30 razy.
• gpt-5-nano, najtańszy model OpenAI, ma na samym markdownie najwięcej błędów krytycznych spośród modeli w chmurze, głównie przez brakujące składniki (51).

Czego ten test nie mówi

• Wzorzec przygotowały modele. Sprawdziłem każdą ich różnicę i próbkę zgodności, ale gdyby oba modele tak samo źle odczytały ten sam fragment poza próbką, nie zauważyłbym tego. Fable i Gemini należą do tych samych rodzin co część zawodników.
• Darmowy Groq odrzucił najdłuższe angielskie przepisy (limit 8000 tokenów na zapytanie), więc jego wiersze (†) ich nie obejmują i nie są w pełni porównywalne z resztą.
• Modele lokalne miały odpowiedź ograniczoną do 4096 tokenów. Ucięta odpowiedź liczy się jako zepsuty JSON (qwen3:14b: 2 na pełnym wejściu, 5 na samym markdownie).
• 50 przepisów i dwa przebiegi wystarczą, żeby oddzielić czołówkę od końca tabeli, ale nie żeby ustawić kolejność w czołówce.
• Polszczyznę ocenił jeden człowiek na 20 odpowiedziach, a LanguageTool trafia w prawdziwy błąd w około 57% przypadków.
• Czasy przez OpenRouter (gwiazdka) zmierzyłem osobno na 6 przepisach i zależą od dostawcy i pory dnia.
• Koszt podaję tam, gdzie rozliczył go OpenRouter. Ceny są z 25 i 26 października 2026.
• Promptu pod Bielika ani pod inne modele nie pisałem. Wszystkie dostały prompt, który powstawał przy modelach OpenAI.

Podsumowanie

• Kilka modeli zapisuje przepisy niemal bez błędów krytycznych, a różnice między nimi mieszczą się w niepewności pomiaru. Wybór w tej grupie to kwestia ceny, szybkości i tego, z czyjego API już korzystasz.
• W ZapiszPrzepis zostaje gpt-5.4-mini: około jednego błędu krytycznego na jedenaście przepisów i odpowiedź w 4,4 sekundy.
• Droższy model ani wyższy poziom rozumowania nie poprawiły wyniku.
• Na OpenRouterze sprawdzaj dostawcę, nie tylko model.
• Lokalne modele, w tym Bielik, są darmowe w pieniądzach, ale wolne i z tym promptem robią więcej błędów.

A Ty jak wybierasz model do swojej aplikacji: na benchmarkach, na własnych danych, czy po prostu bierzesz ten, który już znasz? Chętnie się dowiem, co sprawdza się u Ciebie.