Prompt po polsku czy po angielsku? Kiedy język naprawdę zmienia jakość odpowiedzi AI

"Promptuj po angielsku, dostaniesz lepsze wyniki" - to powtarzane w kółko uproszczenie, które bywa prawdziwe i bywa szkodliwe. Prawda jest bardziej praktyczna: język promptu wpływa na jakość, ale zależy to od modelu, zadania i tego, czy odpowiedź ma trafić do polskiego odbiorcy. W tym tekście rozkładam mechanizm na czynniki pierwsze i daję Ci test, którym sprawdzisz to sam na swoich zadaniach - bez wiary na słowo.

Dlaczego język w ogóle robi różnicę

Model językowy nie "rozumie" po polsku ani po angielsku w ludzkim sensie. Działa na dwóch poziomach, które warto rozdzielić, bo dają zupełnie różne efekty.

1. Rozkład danych treningowych

Modele uczone są na ogromnych zbiorach tekstu, w których angielski dominuje. Im więcej danego typu treści w danym języku, tym pewniej model porusza się w tym obszarze. To dlatego po angielsku łatwiej dostać dobrze ustrukturyzowaną odpowiedź na wąską, techniczną niszę - po prostu model widział tego więcej. Polski jest językiem dobrze reprezentowanym jak na europejskie standardy, ale w tematach niszowych (specjalistyczny żargon, rzadkie frameworki, konkretne normy) angielski zaplecze bywa głębsze.

2. Tokenizacja

To mniej oczywisty, a bardzo praktyczny czynnik. Model nie czyta liter, tylko "tokeny" - kawałki tekstu. Tokenizery są zoptymalizowane pod angielski, więc ten sam sens po polsku rozpada się na więcej tokenów. Dla języków łacińskich (w tym polskiego) efektywność tokenizacji jest z grubsza o połowę gorsza niż dla angielskiego - czyli polski tekst zajmuje mniej więcej dwa razy więcej tokenów niż jego angielski odpowiednik (Ivan Krivyakov). Polskie ogonki (ą, ć, ż) bywają kodowane jako dwa bajty, co dodatkowo zwiększa liczbę tokenów.

Konsekwencje są dwie, obie wymierne:

• Koszt i kontekst. Ten sam dokument po polsku zje więcej tokenów niż po angielsku - droższe API i szybsze zapychanie okna kontekstu.
• "Budżet uwagi". Dłuższe sekwencje tokenów to więcej miejsca, w którym model może zgubić wątek przy bardzo długich, złożonych promptach.

To realne, mierzalne mechanizmy. Natomiast twardych, uniwersalnych benchmarków typu "po angielsku jest o X procent lepiej" nie ma sensu cytować - wynik zależy od konkretnego modelu i zadania, a liczby krążące po sieci są często wyrwane z kontekstu.

Kiedy angielski faktycznie pomaga

Z mechanizmu wynikają konkretne sytuacje, w których przełączenie promptu na angielski ma sens:

• Wąska wiedza techniczna. Dokumentacja, rzadkie biblioteki, specjalistyczne pojęcia, które po angielsku mają bogate zaplecze, a po polsku prawie nie istnieją w treningu.
• Złożone instrukcje wieloetapowe. Skomplikowane reguły, łańcuchy warunków, formaty wyjścia - tu czasem zyskujesz na precyzji, bo model "stabilniej" trzyma się angielskich instrukcji.
• Praca na długim kontekście. Jeśli wklejasz duże dokumenty i walczysz o miejsce w oknie, angielski oszczędza tokeny.
• Zadania czysto logiczne / kodowe. Tu język naturalny jest tylko opakowaniem - kod i tak jest "po angielsku".

Kiedy polski jest lepszym wyborem

Odwrotnie - są zadania, w których polski prompt wygrywa i przełączanie na angielski tylko psuje efekt:

• Treść dla polskiego odbiorcy. Jeśli wynik ma być po polsku, promptuj po polsku. Tłumaczenie "w głowie modelu" z angielskiego potrafi dawać sztuczną, kalkowaną polszczyznę.
• Niuanse językowe. Ton, rejestr, odmiana, idiomy, gra słów - to wszystko żyje w docelowym języku. Prompt po angielsku z prośbą "napisz po polsku" gubi część wyczucia.
• Kontekst lokalny. Polskie realia, urzędowy język, lokalne zwyczaje - model lepiej je "widzi", gdy pytasz w tym samym języku.
• Korekta i styl polskiego tekstu. Tu język wejścia i wyjścia powinny być spójne.

Zasada-skrót: język wiedzy (gdzie jest najwięcej danych o problemie) dobierz pod instrukcję, a język wyniku dobierz pod odbiorcę. Często to ten sam język. Czasem nie - i wtedy zaczyna się ciekawie.

Strategia hybrydowa - najlepsze z obu

Nie musisz wybierać binarnie. Najmocniejszy układ to: instrukcje i ramy po angielsku, materiał i wynik po polsku. Model dostaje precyzyjne polecenie w "swoim mocniejszym" języku, a operuje na polskiej treści i oddaje polski rezultat.

You are an expert Polish editor. Work strictly in Polish for the OUTPUT.

TASK: Rewrite the text below to be clear, concrete, and natural in Polish.
RULES:
- Keep the original meaning. Do not invent facts.
- Use plain, direct Polish. No corporate buzzwords.
- Preserve all numbers and names exactly.
- Return only the rewritten text, no comments.

TEKST DO PRZEPISANIA:
"""
[tu wklejasz polski tekst]
"""

Odwrotny układ też bywa przydatny - kiedy chcesz wyciągnąć wiedzę z angielskiego zaplecza, ale dostać ją po polsku:

Odpowiedz wyłącznie po polsku, naturalnym, konkretnym językiem.

Najpierw przemyśl problem w oparciu o całą dostępną wiedzę
(także anglojęzyczną), a następnie napisz odpowiedź po polsku.

PYTANIE: [twoje pytanie]

Wymagania:
- Bez kalk z angielskiego, bez "korpomowy".
- Jeśli czegoś nie jesteś pewien, napisz to wprost.
- Konkret zamiast ogólników.

Przetestuj to sam - 15-minutowy protokół

Zamiast wierzyć poradom (także tej), sprawdź na swoich zadaniach. Wynik bywa różny dla różnych modeli, więc jedyny wiarygodny benchmark to Twój własny.

1. Wybierz 3-5 realnych zadań, które faktycznie robisz (np. streszczenie, mail, fragment kodu, korekta, analiza).
2. Przygotuj dwie wersje promptu - identyczne co do treści, różniące się tylko językiem instrukcji. Trzymaj wszystko inne stałe.
3. Uruchom każdą wersję 2-3 razy (modele są losowe - jeden strzał niczego nie dowodzi).
4. Oceniaj na ślepo. Wklej wyniki do arkusza bez etykiet "PL/EN" i oceń je później, nie wiedząc, który jest który. To zabija efekt potwierdzenia.
5. Notuj według stałych kryteriów (tabela niżej).

Po kilku zadaniach zobaczysz wzorzec: prawdopodobnie część zadań wyjdzie lepiej po polsku, część po angielsku, a część bez różnicy. I o to chodzi - dostaniesz regułę dopasowaną do siebie, a nie ogólnik z internetu.

Pułapki, które psują takie testy

• Jeden strzał. Modele są niedeterministyczne. Pojedynczy wynik to anegdota, nie dowód.
• Zmiana dwóch rzeczy naraz. Jeśli przy okazji zmiany języka poprawiasz też treść promptu, nie wiesz, co zadziałało. Izoluj jedną zmienną.
• Efekt potwierdzenia. Jeśli z góry "wiesz", że angielski jest lepszy, ocenisz go łagodniej. Stąd ocena na ślepo.
• Mylenie języka wejścia z wyjściem. To dwie osobne decyzje. Możesz pytać po angielsku, a kazać odpowiadać po polsku - i odwrotnie.
• Generalizowanie między modelami. Wynik z jednego modelu nie przenosi się 1:1 na inny. Przy zmianie modelu warto powtórzyć szybki test.
• Ignorowanie kosztu. Nawet jeśli polski daje równie dobrą jakość, przy masowych zadaniach na długim kontekście różnica tokenów potrafi realnie podbić rachunek.

Praktyczne wnioski

• Nie ma uniwersalnej odpowiedzi. "Zawsze po angielsku" to mit; "zawsze po polsku" - też.
• Wynik dla polskiego odbiorcy promptuj po polsku - naturalność języka wygrywa.
• Wąską wiedzę techniczną i złożone instrukcje warto dać po angielsku - więcej danych, stabilniejsze trzymanie reguł.
• Hybryda (instrukcja EN + treść/wynik PL) to często optimum.
• Pamiętaj o tokenach - polski jest droższy i szybciej zapycha kontekst, co ma znaczenie przy skali.
• Decyduj danymi, nie wiarą. 15-minutowy test na ślepo da Ci więcej niż dziesięć poradników.

Najlepsi użytkownicy AI nie kłócą się o język w teorii - oni go testują pod konkretne zadanie i mają na to swój mały protokół. Teraz masz go i Ty.

Źródła

• LLM tokens and foreign languages - Ivan Krivyakov
• LLM Tokenization Explained: English vs Other Languages - PromptCost.org
• Tokenization efficiency of foundational LLMs for Ukrainian - Frontiers in AI

Tekst powstał z pomocą AI i został zredagowany przez człowieka.