Granice pojedynczego promptu: dlaczego rozumowanie nie gwarantuje precyzji

Im więcej model „myśli” przed odpowiedzią, tym większa szansa, że odpowiedź będzie poprawna — to założenie łatwo przyjąć bezkrytycznie. Sprawdziliśmy je empirycznie na trzech zadaniach wymagających mechanicznej, weryfikowalnej precyzji. Wynik jest bardziej złożony, niż mogłoby się wydawać.

Czym jest pojedynczy prompt?

Pojedynczy prompt to najprostszy możliwy sposób korzystania z modelu językowego — dokładnie ten, który większość z nas zna z codziennych rozmów z ChatGPT: piszemy pytanie lub polecenie, model generuje jedną odpowiedź i na tym koniec. Model nie ma możliwości sprawdzenia, czy to, co właśnie napisał, jest poprawne. Nie korzysta z kalkulatora, nie uruchamia kodu ani nie konsultuje się sam ze sobą. Po prostu przewiduje kolejne słowo, potem następne, aż skończy zdanie, a rezultat trafia do nas jako gotowa odpowiedź.

To podejście świetnie sprawdza się w rozmowach, pisaniu tekstów czy podsumowań, gdzie nie ma jednej „twardej”, poprawnej odpowiedzi. Zadaliśmy sobie pytanie: co się dzieje, gdy zadanie ma dokładnie jedną poprawną odpowiedź i wymaga mechanicznej precyzji, jak wynik mnożenia lub dokładna liczba znaków w tekście? Czy samo polecenie modelowi, by „myślał dłużej” — zwiększenie reasoning_effort — gwarantuje taką precyzję?

Testy przeprowadziliśmy przez Azure OpenAI na modelu z rodziny GPT-5.6. Parametr reasoning_effort określa, ile tokenów „myślenia” model zużywa przed wygenerowaniem odpowiedzi — od none do xhigh. Aby odróżnić problemy systemowe od losowych wahań próbkowania, każdą kombinację zadania i poziomu rozumowania powtórzyliśmy czterokrotnie.

Trzy zadania, jedna wspólna cecha

Wybraliśmy trzy zadania, których wyniki są jednoznacznie poprawne albo niepoprawne:

• Mnożenie — iloczyn dwóch liczb 4-cyfrowych, dokładny wynik.
• Znaki — tekst o dokładnie określonej liczbie znaków, nie słów.
• Litery — zliczanie wystąpień wskazanej litery w losowym tekście o długości około 350 znaków.

Wyniki: skuteczność rośnie wraz z rozumowaniem, ale nie liniowo

Przy effort=none wszystkie trzy zadania kończą się niepowodzeniem w 100% prób. Zaskakujące jest to, co dzieje się dalej. W zadaniu Litery poziom high (75%) wypada gorzej niż low i medium (100%), więc więcej rozumowania nie oznacza lepszego wyniku. Wyższy poziom zwiększa prawdopodobieństwo trafnej odpowiedzi, ale jej nie gwarantuje.

Dlaczego tak się dzieje?

Przy effort=none model miał obliczyć 3471 × 6305 = 21 884 655. Zwrócił „218637?” — liczbę nie tylko błędną, ale też niekompletną strukturalnie. To pokazuje mechanizm: model generuje odpowiedź token po tokenie, w jednym kierunku, bez sprawdzania własnego wyniku. Nie ma kroku „sprawdź, czy to się zgadza”. Poziom rozumowania daje modelowi więcej „przestrzeni” na rozłożenie problemu przed odpowiedzią, ale nie zmienia podstawowej architektury: to nadal generowanie w jednym kierunku, bez pętli informacji zwrotnej.

Koszt rośnie szybciej niż pewność

Wyższy poziom rozumowania oznacza większe koszty — płacimy za tokeny „myślenia”, nie tylko za odpowiedź.

W zadaniu Znaki koszt rośnie z 0,0003 USD (none) do 0,0142 USD (xhigh) — około 40-krotnie. Skuteczność przy xhigh rzeczywiście osiąga 100%, ale przy high wynosi tylko 50%. Płacimy więcej, nie zawsze zyskując większą pewność.

Litery: średni koszt pojedynczego promptu

Poziom rozumowania	Średni koszt (USD)	Skuteczność
none	0,000249 USD	0%
low	0,003133 USD	100%
medium	0,004803 USD	100%
high	0,005837 USD	75%
xhigh	0,006423 USD	100%

Znaki: średni koszt pojedynczego promptu

Poziom rozumowania	Średni koszt (USD)	Skuteczność
none	0,000342 USD	0%
low	0,010084 USD	0%
medium	0,010458 USD	50%
high	0,014829 USD	50%
xhigh	0,014225 USD	100%

Co dalej?

Skoro problemem jest brak weryfikacji, naturalnym krokiem jest danie modelowi narzędzia, które sprawdzi wynik za niego. W kolejnym wpisie przyglądamy się temu, co daje wykonanie kodu i gdzie nadal nie wystarcza.