Jedna zła decyzja w prompcie potrafi zmienić 90% skuteczności w 28% — i na odwrót. Nie przesadzam: to konkretna liczba z badań IBM, a cały ten artykuł jest zbudowany na zweryfikowanych danych, nie na "sprawdzonych triczkach" z YouTube. Jeśli szukasz czegoś między wierszami dokumentacji Anthropic a peer-reviewed research — dobrze trafiłeś.
Chain of Thought — kiedy działa, kiedy szkodzi
CoT (Chain of Thought) to technika zmuszająca model do pokazania kroków rozumowania przed podaniem odpowiedzi. Klasyczny trigger: "Think step by step" albo numerowane kroki w przykładach few-shot. Brzmi prosto. Problem polega na tym, że większość ludzi stosuje ją wszędzie bez zastanowienia.
Badanie Wharton Generative AI Labs (2025) to najpoważniejszy benchmark na ten temat: 198 pytań GPQA Diamond na poziomie doktoratu, 25 powtórzeń na model, 8 modeli. Wyniki są niejednoznaczne w dokładnie tym kierunku, który nikomu nie pasuje do prostej narracji:
| Model | Zmiana średniej dokładności | Zmiana "perfect accuracy" |
|---|---|---|
| Gemini Flash 2.0 | +13,5% | — |
| Claude Sonnet 3.5 | +11,7% | +10,1% |
| GPT-4o-mini | +4,4% (nieistotne stat.) | — |
| GPT-4o | brak zmiany | — |
| Gemini Pro 1.5 | — | −17,2% |
| o3-mini | +2,9% | — |
| o4-mini | +3,1% | +5,6% (przy progu 51%) |
| Gemini Flash 2.5 | −3,3% | −13,1% |
Wniosek, który dokumentacja rzadko podkreśla wprost: CoT pomaga modelom nierozumującym na trudnych zadaniach. Modelom rozumującym — o3, o4-mini, Gemini 2.5 Flash — albo nie pomaga, albo aktywnie szkodzi. Dlaczego? Bo one już rozumują wewnętrznie. Dodatkowe "let's think step by step" to dla nich szum, nie sygnał.
Do tego dochodzi koszt czasowy. Modele nierozumujące z CoT pracują 35–600% dłużej (5–15 sekund więcej). Modele rozumujące — 20–80% dłużej (10–20 sekund). W skali produkcyjnej, gdzie liczymy tokeny i latencję, to nie jest detal.
Jak stosować CoT poprawnie
Przed:
"Is the sum of these odd numbers even? 15, 32, 5, 13, 82, 7, 1"
Po (z CoT):
"Think step by step. First identify which numbers are odd. Then add only the odd numbers. Determine whether the sum is even or odd."
Zasada praktyczna: jeśli używasz Claude Opus 4.6, Sonnet 4.6, GPT-4o lub Gemini Flash 2.0 — CoT warto przetestować. Jeśli używasz o3, o4-mini lub Gemini 2.5 Flash — pomiń trigger CoT i zaoszczędź czas i pieniądze. Wyjątek: dynamiczny CoT (ScienceDirect, 2025) osiąga dodatkowe 1–5% poprawy na publicznych benchmarkach przez adaptacyjne dobieranie przykładów rozumowania — ale to już automatyzacja, nie ręczny prompt.
Few-Shot — optymalna liczba przykładów
Few-shot to podawanie modelu gotowych przykładów input → output przed właściwym pytaniem. Większość poradników mówi "dodaj przykłady". Żaden nie mówi ile. A liczba ma znaczenie.
Dane z wielu źródeł (vellum.ai, promptingguide.ai, Min et al. 2022) wskazują jednoznacznie:
- k=1 (jeden przykład) już bije zero-shot na większości zbiorów danych
- Największy skok następuje między 0 a 2 przykładami
- Po 4–5 przykładach dokładność się spłaszcza, ale koszt tokenów rośnie liniowo
- Anthropic rekomenduje 3–5 przykładów jako złoty środek (dokumentacja, czerwiec 2026)
Jest jeszcze jedno zaskakujące odkrycie z badań Min et al. (2022): etykiety mogą być błędne i few-shot nadal działa lepiej niż zero-shot. Dlaczego? Bo model uczy się z formatu i rozkładu danych, nie z poprawności etykiet. Struktura sama w sobie jest sygnałem.
Anthropic zaleca owijanie przykładów w tagi XML:
<examples>
<example>
<input>Absolutnie uwielbiam, kupię ponownie.</input>
<output>pozytywny</output>
</example>
<example>
<input>Przeciętna jakość, nic specjalnego.</input>
<output>neutralny</output>
</example>
<example>
<input>Przestało działać po kilku godzinach. Tragedia.</input>
<output>negatywny</output>
</example>
</examples>
Oceń sentyment: "Ten produkt zepsuł się po jednym dniu."Krytyczne ograniczenie few-shot: przy wieloetapowej arytmetyce i rozumowaniu logicznym samo few-shot nie wystarczy, nawet przy 4–5 przykładach. Trzeba połączyć z CoT — dopiero ta kombinacja przynosi realne efekty.
XML Tags — nie tylko dla Claude'a
Anthropic twierdzi, że ustrukturyzowane prompty XML dają 20–40% bardziej spójne wyniki niż plain text. To liczba z ich własnej dokumentacji, więc traktujcie ją jako benchmark producenta, nie niezależny wynik — ale w praktyce różnica jest wyraźna.
Zalecany zestaw tagów (dokumentacja Anthropic, czerwiec 2026):
<instructions>— co model ma zrobić<context>— tło i okoliczności<input>— zmienne dane wejściowe<examples>/<example>— demonstracje<output_format>— wymagana struktura odpowiedzi<documents>/<document index="n">/<document_content>/<source>— dla wielu dokumentów<quotes>— zakotwiczanie w długich tekstach
Jedna technika warta osobnego podkreślenia: dla długich dokumentów (20k+ tokenów) umieść treść dokumentu POWYŻEJ zapytania. Zapytanie na końcu poprawia jakość odpowiedzi o do 30% w wewnętrznych testach Anthropic. Logika jest prosta — model czyta kontekst, zanim wie, czego szukać.
Przykład dla zadania wielodokumentowego:
<documents>
<document index="1">
<source>objawy.txt</source>
<document_content>{{OBJAWY}}</document_content>
</document>
<document index="2">
<source>historia.txt</source>
<document_content>{{HISTORIA}}</document_content>
</document>
</documents>
Znajdź w dokumentach cytaty powiązane z objawami. Umieść w tagach <quotes>. Następnie podaj wnioski diagnostyczne w tagach <info>.Struktura system promptu — kolejność ma znaczenie
Anthropic publikuje konkretną kolejność elementów system promptu (dokumentacja, czerwiec 2026). Większość ludzi ją ignoruje i pisze, co im przyszło do głowy:
- Rola / Persona — minimum jedno zdanie
- Kontekst / Tło
- Definicja zadania
- Instrukcje — numerowane, jeśli kolejność jest istotna
- Format wyjścia / ograniczenia
- Przykłady — w tagach
<examples>
Rola promptu to nie kosmetyka. Nawet jedno zdanie w system prompcie ("You are a senior DevOps engineer with 10 years of experience in Kubernetes.") mierzalnie zawęża aktywację wiedzy modelu, zmienia ton i redukuje odpowiedzi off-topic. Anthropic potwierdza to jako technikę pierwszej klasy, nie ciekawostkę.
Instrukcje pozytywne, nie negatywne
To jeden z tych błędów, które są jednocześnie powszechne i łatwe do naprawienia:
| Instrukcja negatywna | Instrukcja pozytywna |
|---|---|
| "Nie używaj markdown." | "Pisz w płynących akapitach prozy." |
| "Nie używaj wielokropków." | "Twoja odpowiedź będzie odczytana przez TTS — nigdy nie używaj wielokropków, bo silnik nie wie, jak je wymówić." |
| "Nie sugeruj zmian, tylko je wprowadź." | "Zmień tę funkcję, żeby poprawić jej wydajność." |
Wersja negatywna jest mniej niezawodna, bo model musi odgadnąć, co chcesz zamiast tego. Wersja z kontekstem ("bo silnik TTS nie wie, jak wymówić wielokropek") pozwala modelowi uogólnić regułę na przypadki brzegowe, których autor instrukcji nie przewidział.
Temperature i Top-P — jedno na raz
Temperature kontroluje losowość wyjścia (0.0 = w pełni deterministyczne, 2.0 = maksymalny chaos). Zasady z zweryfikowanych źródeł (promptingguide.ai):
- 0.0: A/B testy wariantów promptu, klasyfikacja, ekstrakcja, Q&A faktyczne, generowanie kodu — wszędzie, gdzie liczy się powtarzalność
- 0.3–0.7: streszczenia, pisanie biznesowe, wyjaśnienia techniczne
- 0.8–1.0: pisanie kreatywne, burza mózgów, copy marketingowe
Absolutna zasada: nigdy nie zmieniaj Temperature i Top-P jednocześnie. Tworzysz wtedy efekty interakcji, których nie da się przypisać do jednej zmiennej. Zmień jedno, przetestuj, oceń, dopiero wtedy ruszaj drugą.
Top-P: trzymaj nisko przy zadaniach faktycznych, podnoś przy różnorodnych wyjściach. Logika identyczna jak przy temperature, ale oś kontroli jest inna.
Prompt Chaining — rozbijaj, nie monolitujesz
Prompt chaining to sekwencja osobnych wywołań API, gdzie output każdego kroku staje się inputem następnego. Dane są jednoznaczne:
- Self-consistency chaining (generuj → krytykuj → popraw): dwucyfrowa poprawa dokładności na benchmarkach GSM8K i SVAMP
- Chained refinement konsekwentnie bije pojedyncze, monolityczne prompty przy streszczaniu tekstu
- GPT-3 przy właściwej dekompozycji problemu osiągał niemal perfekcyjną generalizację kompozycyjną na benchmarku SCAN
Przed (monolit):
"Podsumuj ten artykuł w punktach i dodaj call to action."
Po (chaining):
- Prompt 1: "Podsumuj kluczowe fakty z artykułu w 3–5 zdaniach."
- Prompt 2: "Przejrzyj to podsumowanie: [output kroku 1]. Wskaż brakujące punkty lub nieścisłości."
- Prompt 3: "Przepisz podsumowanie uwzględniając tę informację zwrotną: [output kroku 2]. Dodaj jedno zdanie call to action na końcu."
Koszt: każdy krok dodaje latencję (round-tripy sieciowe) i tokeny. Minimalizujesz to przez: (a) przekazywanie downstream tylko niezbędnego kontekstu, (b) równoległe uruchamianie niezależnych kroków, (c) semantic caching dla powtarzających się podzadań.
Meta Prompting — paradygmat 2026
Prompt chaining to 2024. Meta Prompting to 2026: projektujesz system promptów — routery, plannery, executory, ewaluatory — często na wielu modelach. Claude Opus 4.6 orkiestruje subagentów natywnie, bez jawnej instrukcji. To już nie jest "napisz lepszy prompt", to inżynieria systemu.
Pułapki specyficzne dla Claude 4.6+
Kilka rzeczy, które dawniej działały, teraz generują błędy lub pogorszone wyniki:
- Prefilled assistant responses (podawanie początku odpowiedzi modelu w API) — od czerwca 2026 na Claude 4.6+ zwracają HTTP 400. Migracja: instrukcja w system prompcie ("Respond directly without preamble.").
- Słowo "think" przy wyłączonym extended thinking na Claude Opus 4.5/4.6 — model reaguje nieprzewidywalnie. Używaj zamienników: "consider", "evaluate", "reason through".
- Extended thinking zastąpiony adaptive thinking: nowe API to
thinking={type:'adaptive'}+output_config={effort:'high'/'max'/'xhigh'/'medium'/'low'}. Anthropic twierdzi, że adaptive thinking "reliably drives better performance" w wewnętrznych ewaluacjach.
10 błędów, które popełnia większość — i jak je naprawić
- Vague prompts: "Napisz dobrego maila" — brak roli, odbiorcy, tonu, długości. Napraw: dodaj kto, do kogo, po co, w jakim tonie, ile słów.
- Pakowanie wielu zadań w jeden prompt: model traci fokus. Napraw: chainuj lub numeruj kroki.
- Brak kontekstu: model zgaduje i często zgaduje źle. Napraw: zawsze napisz, dlaczego to zadanie ma znaczenie.
- Rule overload: zbyt wiele ograniczeń gubi główny wątek. Napraw: jedna główna instrukcja, reszta jako szczegóły pomocnicze.
- Instrukcje negatywne: "Nie używaj markdown" jest mniej niezawodne niż "Pisz w akapitach prozy".
- Testy przy niezerowej temperaturze: A/B bez temperature=0.0 to loteria. Napraw: testuj zawsze przy 0.0.
- Jednoczesna zmiana Temperature i Top-P: nieprzewidywalne efekty interakcji. Napraw: jedna zmienna na raz.
- CoT na modelach rozumujących: o3, o4-mini, Gemini 2.5 Flash już rozumują wewnętrznie. Dodajesz 10–20 sekund latencji za zero lub ujemny efekt.
- Brak XML dla Claude'a: plain text mieszający instrukcje, kontekst i przykłady jest interpretowany niejednoznacznie.
- Prefilled responses na Claude 4.6+: HTTP 400. Przenieś logikę do system promptu.
Podsumowanie praktyczne
Jeśli miałbym wybrać pięć rzeczy do wdrożenia od dziś, to:
- Sprawdź model przed dodaniem CoT. Jeśli to o3, o4-mini lub Gemini 2.5 Flash — pomiń. Jeśli Claude Sonnet 4.6 lub Gemini Flash 2.0 — testuj, zysk może wynieść 11–13%.
- Few-shot: 3 przykłady w tagach XML. Jeden przykład już bije zero-shot. Cztery to optimum dla większości zastosowań. Pięć — tylko jeśli masz skrajne przypadki do pokrycia.
- Struktura system promptu: rola → kontekst → zadanie → instrukcje → format. Nie odwrotnie, nie losowo.
- Testuj przy temperature=0.0. Potem tune'uj w górę dla produkcji, jeśli potrzebujesz różnorodności.
- Rozbij złożone zadania na chained API calls. Monolityczny prompt na skomplikowane zadanie to antywzorzec — dane z GSM8K i SVAMP to potwierdzają.
Prompt engineering w 2026 to już nie "napisz lepiej". To decyzje inżynierskie: który model, która technika, jaki trade-off między latencją a dokładnością, jak ewaluować wyniki. Im szybciej przestaniesz myśleć o tym jak o copywritingu, a zaczniesz jak o systemie — tym szybciej zobaczysz liczby, które wyróżniają dobre wdrożenia od złych.
