# Jak działa AI

> Interaktywny przewodnik dla inżynierów: jak działają modele językowe pod spodem i co jest ważne w budowaniu systemów agentowych. Z pytaniami sprawdzającymi.

https://howaiworks.dev/pl/


---

## Tokeny

*Jak model czyta i przewiduje*

*Ostatnia zmiana: 28 września 2026*

Model nie widzi liter ani słów, tylko ciąg liczb. Każda liczba to numer tokena, czyli kawałka tekstu ze stałego słownika. W tokenach liczy się cenę, limit kontekstu i prędkość, a sposób cięcia tłumaczy kilka typowych błędów modeli.

**Po ludzku:** Model czyta jak ktoś, kto zna sylaby i całe popularne słowa, ale nigdy nie widział pojedynczych liter. Znane słowa łyka w całości, rzadkie składa z kawałków.

*Interaktywny widżet na stronie: Wybierz tokenizer i przykład albo wpisz własny tekst. Zobacz, gdzie wypadają granice tokenów i ile znaków przypada na jeden token.*

### Jak powstaje słownik tokenów

- Słownik buduje algorytm BPE (byte-pair encoding). Startuje od 256 możliwych bajtów i na dużym korpusie w kółko scala najczęstszą sąsiednią parę w nowy token, aż dojdzie do zadanego rozmiaru. Częste słowa stają się jednym tokenem, rzadkie składają się z kawałków.
- Przed BPE wyrażenie regularne dzieli tekst na słowa, liczby i interpunkcję, więc scalanie nie przekracza tych granic. Spacja przykleja się do następnego słowa. W tokenizerze GPT-4o „strawberry” poprzedzone spacją to jeden token, a bez spacji, np. na początku tekstu, trzy: st|raw|berry (wpisz samo słowo w widżet).
- BPE działa na bajtach UTF-8, więc każdy tekst da się zakodować i nie ma tokena „nieznane słowo”. Rzadkie połączenia rozpadają się na bajty: w GPT-4o słowo „Źdźbło” ze spacją przed nim to sześć tokenów, a spacja z „Ź” dzieli się na dwa kawałki, z których żaden nie jest całym znakiem. Tokenizery oparte na SentencePiece osiągają to samo przez byte fallback.
- Rozmiar słownika to decyzja projektowa: GPT-4 ma ok. 100 tys. tokenów, GPT-4o ok. 200 tys., Llama 3 128 tys. (100 tys. z tokenizera OpenAI plus 28 tys. dla języków innych niż angielski), Gemma 3 262 tys. Większy słownik daje krótsze sekwencje, ale większą tabelę embeddingów i warstwę wyjściową.
- Słownik ma też tokeny specjalne: koniec tekstu, znaczniki ról, wywołanie narzędzia. To osobne numery, których w dobrze zbudowanym API nie da się wpisać zwykłym tekstem. Rozmowa to jeden ciąg tokenów z takimi znacznikami (zobacz „Jak model widzi czat”).

### Skutki widoczne w odpowiedziach

- Litery: w pytaniu „Ile r jest w strawberry?” model widzi słowo „strawberry” jako jeden numer zamiast dziesięciu liter, a pisownię musi pamiętać z treningu. Liczenie liter, rymy, odwracanie słów i anagramy są przez to zawodne. Modele rozumujące radzą sobie lepiej, bo najpierw wypisują słowo litera po literze i każda litera staje się osobnym tokenem.
- Liczby: GPT-4 i GPT-4o tną cyfry na grupy po trzy od lewej (1234567 to 123|456|7), Gemma 3 po jednej cyfrze. Przy grupach pozycje dziesiętne w dwóch liczbach się nie pokrywają, więc arytmetyka „w pamięci” jest zawodna. Do liczenia daje się narzędzie albo interpreter kodu.
- Prompt zakończony spacją psuje granicę tokena. W danych treningowych spacja prawie zawsze należy do następnego słowa, więc model dostaje rzadki układ i odpowiada gorzej. Nie kończ spacją promptu w trybie uzupełniania (completion) ani początku odpowiedzi podanego z góry (prefill). Dotyczy to głównie self-hostingu: w API czatu odpowiedź zaczyna się w nowej turze, a obecne modele Claude w ogóle odrzucają prefill (stan na wrzesień 2026).

### Koszt i limity

- W tokenach liczy się cenę, context window, `max_tokens`, limity zapytań na minutę i prędkość generowania. Polski tekst zużywa ich więcej: na całym tekście tego przewodnika polska wersja ma ok. 1,4 raza więcej tokenów niż angielska w tokenizerze GPT-4o (3,2 wobec 4,5 znaku na token) i ok. 1,6 raza więcej w Llama 3 (liczby pokazuje widżet). Ta sama treść jest więc droższa, szybciej zapełnia okno i dłużej się generuje.
- Tokenizer należy do modelu. Ten sam tekst to inna liczba tokenów u różnych dostawców, a czasem między wersjami jednego modelu: według Anthropic nowy tokenizer Claude Opus 4.7 (kwiecień 2026) zamienia ten sam tekst nawet na ok. 35% więcej tokenów niż Opus 4.6, przy tej samej cenie za token. Cen za milion tokenów nie porównuj wprost. Policz tokeny na własnych danych tokenizerem modelu albo endpointem dostawcy, np. `count_tokens` w API Claude.

### Sprawdź się

**Pytanie:** Jak działa tokenizacja BPE i jak wpływa na koszt i zachowanie modelu?

**Krótka odpowiedź:** Tokenizer tnie tekst na kawałki ze stałego słownika i zamienia je na liczby. BPE buduje słownik od 256 bajtów, scalając najczęstsze sąsiednie pary, aż dojdzie do zadanego rozmiaru, zwykle 100–260 tys. Dzięki bajtom każdy tekst da się zakodować. Częste słowa są jednym tokenem, rzadkie i nieangielskie rozpadają się na kawałki, więc polski tekst zajmuje ok. 1,3–1,6 raza więcej tokenów niż angielski, zależnie od tokenizera. Model zwykle nie widzi pojedynczych liter, a w wielu tokenizerach także cyfr, stąd błędy przy liczeniu liter i arytmetyce. Większy słownik skraca sekwencje, ale powiększa tabelę embeddingów i warstwę wyjściową.

### Pytania pogłębiające

- **Czemu nie tokenizować po znakach albo po całych słowach?** Znaki dają kilka razy dłuższe sekwencje, a koszt attention i KV cache’u rośnie z długością. Słowa dają gigantyczny słownik, a literówka, nowe słowo czy nazwa własna nie mają numeru. BPE na bajtach łączy krótkie sekwencje z pełnym pokryciem.
- **Co zmienia większy słownik?** Krótsze sekwencje, więc tańszy kontekst i szybsze generowanie, zwłaszcza w językach innych niż angielski. Kosztem jest większa tabela embeddingów i warstwa wyjściowa (w Llama 3 70B po ok. 1 mld parametrów) oraz rzadkie tokeny, dla których w treningu było mało przykładów.
- **Czy da się podmienić tokenizer w gotowym modelu?** Praktycznie nie. Tabela embeddingów i warstwa wyjściowa są przypisane do konkretnych numerów, więc nowy słownik wymaga co najmniej dotrenowania tych warstw, a zwykle dalszego pretrainingu. Dodanie kilku tokenów specjalnych przy fine-tuningu jest możliwe, ale ich embeddingi trzeba wytrenować (zobacz „Fine-tuning i LoRA”).
- **Jak oszacujesz koszt nowej funkcji przed wdrożeniem?** Na próbce prawdziwych danych: wejście i definicje narzędzi tokenizerem danego modelu albo endpointem dostawcy do liczenia tokenów, a wyjście z pola usage kilku prawdziwych wywołań. Modele rozumujące liczą tokeny myślenia jako wyjście, nawet gdy ich nie widać, a żaden tokenizer nie policzy ich z góry (zobacz „Modele rozumujące”). Powtarzany prefiks licz po cenie cache’u (zobacz „Prompt caching”), całość razy liczba wywołań. Cen za milion tokenów u różnych dostawców nie porównuje się wprost, bo ten sam tekst to u nich różna liczba tokenów.

### Źródła

- [Sennrich i in.: Neural Machine Translation of Rare Words with Subword Units (BPE, ACL 2016)](https://arxiv.org/abs/1508.07909)
- [Anthropic: Introducing Claude Opus 4.7 (nowy tokenizer, kwiecień 2026)](https://www.anthropic.com/news/claude-opus-4-7)
- [Andrej Karpathy: Let’s build the GPT Tokenizer](https://www.youtube.com/watch?v=zduSFxRajkE)
- [Tiktokenizer: prawdziwe tokenizery w przeglądarce](https://tiktokenizer.vercel.app/)

---

## Wektory i macierze

*Jak model czyta i przewiduje*

*Ostatnia zmiana: 28 września 2026*

Każdy token staje się wektorem liczb, który przechodzi przez kilkadziesiąt warstw. Warstwa to głównie mnożenie tego wektora przez duże, stałe macierze wag, dlatego koszt modelu liczy się w parametrach, bajtach i operacjach.

**Po ludzku:** Wyobraź sobie stół mikserski z miliardami suwaków. Trening ustawił suwaki raz, potem nikt ich nie rusza. Każde słowo przechodzi przez ten sam stół i wychodzi trochę zmienione.

*Interaktywny widżet na stronie: Kliknij liczbę w nowym wektorze i zobacz, z jakich mnożeń powstała.*

### Droga tokena przez model

- Embedding to zwykły lookup, a nie mnożenie: numer tokena wybiera wiersz tabeli. W Llama 3 70B tabela ma 128 256 × 8192 liczb, ponad 1 mld parametrów.
- Warstwa ma dwa kroki. Attention miesza informacje między tokenami (zobacz „Attention”). MLP przetwarza każdy token osobno: rozszerza wektor z 8192 do 28 672 liczb, przepuszcza przez nieliniowość (w Llamie SwiGLU) i zwęża z powrotem. Bez nieliniowości kolejne mnożenia dałoby się złożyć w jedną macierz. W Llama 3 70B MLP to ponad 80% parametrów warstwy.
- Każdy krok dodaje swój wynik do wektora, zamiast go zastępować: `x = x + Attn(Norm(x))`, potem `x = x + MLP(Norm(x))`. Ten wektor to residual stream, wspólna szyna, z której warstwy czytają i do której dopisują. Dodawanie daje gradientowi prostą drogę przez dziesiątki warstw, a normalizacja (w Llamie RMSNorm) trzyma skalę liczb w ryzach.
- Na końcu wektor ostatniego tokena mnoży się przez macierz 8192 × rozmiar słownika. Wychodzi jeden logit na każdy token ze słownika, a softmax zamienia logity w prawdopodobieństwa (zobacz „Następny token”).

*Interaktywny widżet na stronie: Kliknij pojęcie i zobacz jego najbliższych sąsiadów w przestrzeni wektorowej.*

### Gdzie model przechowuje wiedzę

- W środku nie ma bazy faktów ani instrukcji warunkowych, tylko liczby w macierzach. Badania wskazują, że warstwy MLP działają jak pamięć klucz–wartość (Geva i in., 2021): wzorzec na wejściu „zapala” kierunek, który dopisuje do wektora skojarzoną informację.
- Fakt nie leży w jednym miejscu. Badania nad interpretowalnością pokazują, że model upycha więcej cech, niż ma wymiarów, nakładając je na siebie, więc pojedyncza liczba rzadko znaczy jedną rzecz. Dlatego nie da się przejrzeć wiedzy modelu ani niezawodnie poprawić jednego faktu. Nową albo zmienną wiedzę podaje się w kontekście (zobacz „RAG”).

### Ile pamięci i obliczeń potrzebuje model

- Pamięć na wagi to parametry × bajty na parametr: model 70B w BF16 zajmuje ok. 140 GB, w 4 bitach niecałe 40 GB (zobacz „Kwantyzacja”).
- Obliczenia: ok. 2 operacje (mnożenie i dodawanie) na parametr na token przy inferencji i ok. 6 przy treningu, bo dochodzi przebieg wstecz. Model 70B to ok. 140 GFLOP na token plus attention, którego koszt rośnie z długością kontekstu i w Llama 3 70B dogania koszt wag przy prompcie o długości ok. 100 tys. tokenów (zobacz „Attention”). W MoE liczą się tylko aktywne parametry (zobacz „Mixture of Experts”).
- Mnożenie macierzy to tysiące niezależnych iloczynów skalarnych, więc idealnie pasuje do GPU. Przy generowaniu jednego tokena karta i tak czeka głównie na odczyt wag z pamięci (zobacz „Czemu GPU się nudzi”).

### Sprawdź się

**Pytanie:** Co dzieje się z tokenem w środku modelu i ile kosztuje jeden token?

**Krótka odpowiedź:** Numer tokena wybiera wektor z tabeli embeddingów. Wektor przechodzi przez kilkadziesiąt bloków: w każdym attention miesza informacje z wcześniejszymi tokenami, a MLP przetwarza token osobno. Wynik każdego kroku dodaje się do wektora (residual stream), z normalizacją przed krokiem. Na końcu mnożenie przez macierz słownika daje logity, a softmax rozkład następnego tokena. Przy krótkim kontekście prawie cały koszt to mnożenie przez stałe macierze wag: ok. 2 operacje na parametr na token, więc model 70B to ok. 140 GFLOP na token, a jego wagi w BF16 zajmują ok. 140 GB. Attention dokłada koszt, który rośnie z długością kontekstu i w Llama 3 70B dogania koszt wag przy prompcie o długości ok. 100 tys. tokenów.

### Pytania pogłębiające

- **Ile obliczeń i pamięci kosztuje jeden token?** Około 2 operacji na aktywny parametr przy inferencji i 6 przy treningu, plus attention, którego koszt rośnie z długością kontekstu. Pamięć to wagi (parametry × bajty) plus KV cache, który rośnie z długością kontekstu (zobacz „Pętla generowania i KV cache”).
- **Gdzie fizycznie jest wiedza modelu?** W wagach, w dużej mierze w warstwach MLP, które działają jak pamięć skojarzeniowa. Attention przenosi informacje między pozycjami. Fakty są rozproszone i nałożone na siebie, dlatego nową wiedzę taniej podać w kontekście niż wpisywać w wagi (zobacz „RAG” i „Fine-tuning i LoRA”).
- **Po co połączenia rezydualne i normalizacja?** Dodawanie wyniku do wejścia daje gradientowi prostą drogę przez dziesiątki warstw, a każda warstwa uczy się tylko poprawki. Normalizacja przed każdym krokiem (dziś zwykle RMSNorm) trzyma skalę aktywacji w ryzach. Bez tego głębokie modele trenują się niestabilnie.
- **Czym embedding tokena różni się od embeddingu do wyszukiwania?** Embedding tokena to wiersz tabeli, bez kontekstu. Model embeddingowy przepuszcza cały fragment przez transformer i zwraca jeden wektor na tekst. Jest trenowany tak, żeby teksty o podobnym znaczeniu leżały blisko siebie (zobacz „Embeddingi i wyszukiwanie wektorowe”).

### Źródła

- [Geva i in.: Transformer Feed-Forward Layers Are Key-Value Memories (2021)](https://arxiv.org/abs/2012.14913)
- [Anthropic: Toy Models of Superposition (2022)](https://transformer-circuits.pub/2022/toy_model/index.html)
- [Transformer Explainer: prawdziwy GPT-2 w przeglądarce](https://poloclub.github.io/transformer-explainer/)
- [3Blue1Brown: sieci neuronowe i transformery](https://www.3blue1brown.com/topics/neural-networks)
- [LLM Visualization w 3D (bbycroft)](https://bbycroft.net/llm)

---

## Attention

*Jak model czyta i przewiduje*

*Ostatnia zmiana: 28 września 2026*

Attention to jedyne miejsce w transformerze, w którym tokeny wymieniają informacje: każdy token patrzy na wszystkie wcześniejsze i bierze od nich ważoną mieszankę treści. Od tego mechanizmu zależy koszt długiego kontekstu.

**Po ludzku:** Czytając „był głodny”, cofasz wzrok do słowa „Kot”, żeby wiedzieć, o kim mowa. Attention to takie cofanie wzroku, tylko robione przy każdym słowie i do wszystkich poprzednich naraz.

*Interaktywny widżet na stronie: Kliknij token i zobacz, na które wcześniejsze tokeny patrzy. Wagi w jednym wierszu zawsze sumują się do 100%.*

### Mechanizm: Q, K, V

- Każdy token rzutuje swój wektor na trzy: zapytanie Q (czego szukam), klucz K (po czym można mnie znaleźć) i wartość V (co przekażę). Wagi to `softmax(Q·Kᵀ/√d)`: iloczyn skalarny mierzy dopasowanie, dzielenie przez pierwiastek z wymiaru głowy chroni softmax przed nasyceniem, a softmax daje wagi sumujące się do 1. Wynik to ważona suma V. W przykładzie „był” daje dalekiemu słowu „Kot” prawie tyle uwagi co sąsiedniemu „bo”: waga zależy od dopasowania Q do K, nie od odległości.
- Maska przyczynowa: token widzi tylko siebie i tokeny wcześniejsze. Dzięki temu trening uczy przewidywania na wszystkich pozycjach tekstu naraz, a przy generowaniu K i V starych tokenów się nie zmieniają, więc można je trzymać w KV cache’u (zobacz „Pętla generowania i KV cache”).
- Wiele głów: w Llama 3 70B wektor 8192 liczb jest rzutowany na 64 głowy zapytań po 128 wymiarów (i 8 głów kluczy i wartości). Każda głowa widzi cały wektor przez własną projekcję i szuka niezależnie od pozostałych, a macierz wyjściowa skleja wyniki. Nieliczne głowy da się nazwać, np. kopiującą wzorzec, który już wystąpił w tekście; większości nie.
- Sama operacja attention ignoruje kolejność: bez maski przyczynowej i bez informacji o pozycji „2 − 1” i „1 − 2” wyglądałyby tak samo. Już sama maska pozwala modelowi odtworzyć pozycje (token może policzyć, ilu ma poprzedników), a Llama 4 ma część warstw w ogóle bez kodowania pozycji. Większość modeli i tak dodaje RoPE, które obraca pary współrzędnych Q i K o kąt proporcjonalny do pozycji, więc iloczyn Q·K zależy od odległości między tokenami. Kontekst wydłuża się po treningu zwykle przez przeskalowanie RoPE i krótkie dotrenowanie na długich tekstach.

*Interaktywny widżet na stronie: Wydłużaj kontekst i porównaj trzy liczby: pary rosną kwadratowo, KV cache liniowo, a attention przejmuje większość obliczeń dopiero przy bardzo długim prompcie.*

### Ile kosztuje attention

- Prefill liczy n²/2 par w każdej głowie każdej warstwy. Reszta warstwy, czyli projekcje i MLP, rośnie jednak liniowo i przy krótkim kontekście dominuje: w Llama 3.1 70B attention dogania ją dopiero przy ok. 100 tys. tokenów. Dziesięć razy dłuższy prompt kosztuje więc od 10 do 100 razy więcej obliczeń, zależnie od długości.
- Przy generowaniu nowy token porównuje jedno Q ze wszystkimi K w cache’u, więc obliczenia na token rosną liniowo. Boli pamięć: KV cache rośnie liniowo z długością (43 GB na 128 tys. tokenów w Llama 3.1 70B) i to on ogranicza, ile rozmów zmieści się na karcie.
- FlashAttention liczy dokładnie ten sam wynik, ale kafelkami w szybkiej pamięci SRAM, bez zapisywania macierzy n × n do pamięci karty. Pamięć staje się liniowa, a obliczenia kilka razy szybsze, choć liczba operacji nie spada (w treningu wręcz rośnie, bo przebieg wstecz liczy attention ponownie).
- KV cache można zmniejszyć w samej architekturze: GQA daje jedną parę K, V na grupę głów zapytań (Llama 3 70B: 8 zamiast 64), MLA z DeepSeek zapisuje jeden skompresowany wektor, a okno przesuwne ogranicza część warstw do najnowszych tokenów (Gemma 3: 1024, gpt-oss: 128).

### Granice długiego kontekstu

- Softmax zawsze rozdziela 100% uwagi, więc głowa nie może „na nic nie patrzeć”. Modele uczą się zrzucać nadmiar na pierwsze tokeny (attention sinks, Xiao i in., 2023), w widżecie wyżej – na token startu. Dlatego obcięcie początku kontekstu, np. w prostym oknie przesuwnym, psuje model, nawet gdy początek nie niósł ważnej treści.
- Zmieszczenie tekstu w oknie nie znaczy, że model go dobrze wykorzysta. Informację ze środka długiego kontekstu modele wykorzystują gorzej niż z początku i końca (Liu i in., „Lost in the Middle”, 2023). Co wkładać do kontekstu i gdzie, omawia „Context engineering i pamięć”.

### Sprawdź się

**Pytanie:** Jak działa attention i czemu długi kontekst jest drogi?

**Krótka odpowiedź:** Każdy token rzutuje swój wektor na zapytanie, klucz i wartość. Wagi to softmax z iloczynów Q·K podzielonych przez √d, a wynik to ważona suma wartości. Maska przyczynowa zasłania przyszłość, a wiele głów robi to równolegle. W prefillu liczba par rośnie z kwadratem długości, ale w modelu 70B attention zaczyna dominować w obliczeniach dopiero przy ok. 100 tys. tokenów. Przy generowaniu bardziej boli pamięć: KV cache rośnie liniowo, ok. 0,33 MB na token w Llama 3 70B (BF16), i ogranicza batch. Pomagają FlashAttention, GQA lub MLA i okno przesuwne.

### Pytania pogłębiające

- **Czemu dzielimy przez √d?** Iloczyn skalarny wektorów o losowych składowych ma wariancję rosnącą z wymiarem. Bez skalowania logity są duże, softmax staje się prawie zero-jedynkowy, a gradienty zanikają.
- **Czym różnią się MHA, MQA i GQA?** Liczbą głów kluczy i wartości. MHA ma ich tyle co zapytań, MQA jedną wspólną, GQA po jednej na grupę (Llama 3 70B: 8 na 64 głowy zapytań, czyli 8 razy mniejszy KV cache). MLA z DeepSeek zapisuje zamiast K i V jeden skompresowany wektor. Mniej KV to większe batche i dłuższy kontekst. MQA i GQA płacą za to niewielką stratą jakości, a według DeepSeek MLA dorównuje pełnemu MHA, a nawet je przewyższa.
- **Co robi FlashAttention?** Liczy dokładnie to samo attention, ale kafelkami mieszczącymi się w szybkiej pamięci karty, bez zapisywania całej macierzy n × n. Wynik ten sam, pamięć liniowa zamiast kwadratowej i mniej transferów, więc szybciej. Liczby operacji nie zmniejsza.
- **Jak modele obsługują milion tokenów?** Łączą pełne attention z tańszymi wariantami albo je nimi zastępują: oknem przesuwnym, attention rzadkim (sparse attention), w którym każdy token patrzy tylko na top-k wcześniejszych tokenów wybranych przez mały, szybki moduł oceniający (DeepSeek V4 łączy je z kompresją KV cache’u i obsługuje milion tokenów), attention liniowym albo warstwami typu Mamba ze stałym stanem. Do tego GQA lub MLA i przeskalowane RoPE. Zmieszczenie miliona tokenów to nie to samo co dobre ich wykorzystanie, więc jakość na długim kontekście mierz na własnym zadaniu.

### Źródła

- [Vaswani i in.: Attention Is All You Need (2017)](https://arxiv.org/abs/1706.03762)
- [Su i in.: RoFormer, czyli RoPE (2021)](https://arxiv.org/abs/2104.09864)
- [Dao i in.: FlashAttention (2022)](https://arxiv.org/abs/2205.14135)
- [DeepSeek: premiera V4, sparse attention i kontekst 1M (2026)](https://api-docs.deepseek.com/news/news260424/)
- [Transformer Explainer: interaktywny GPT-2 w przeglądarce (Georgia Tech)](https://poloclub.github.io/transformer-explainer/)

---

## Następny token

*Jak model czyta i przewiduje*

*Ostatnia zmiana: 28 września 2026*

Model nie zwraca tekstu, tylko wynik (logit) dla każdego tokena ze słownika. Osobny kod, sampler, zamienia wyniki w prawdopodobieństwa i losuje jeden token. Tak powstaje każdy token odpowiedzi, jeden po drugim.

**Po ludzku:** Klawiatura w telefonie podpowiada trzy słowa. Model robi to samo dla stu tysięcy kawałków słów naraz, a potem rzuca kostką obciążoną tymi szansami. Temperatura decyduje, jak mocno obciążona jest kostka.

*Interaktywny widżet na stronie: Zmieniaj temperaturę i top-p, a potem losuj. Porównaj pytanie, na które model zna odpowiedź, takie, na które odpowiada pewnie i błędnie, i takie, przy którym zgaduje.*

### Od logitów do tokena

- Softmax z temperaturą: `p = exp(logit / T) / Σ exp(logit / T)`. T poniżej 1 wyostrza rozkład, powyżej 1 go spłaszcza, T → 0 to zawsze najlepszy token (greedy), a bardzo wysokie T zbliża rozkład do jednostajnego. Temperatura nie zmienia kolejności tokenów, tylko odstępy między nimi.
- Obcinanie ogona: top-k zostawia k najlepszych tokenów, top-p (nucleus) najmniejszy zbiór pokrywający np. 90% prawdopodobieństwa, min-p odrzuca tokeny słabsze niż ułamek najlepszego. Top-p i min-p dopasowują się do pewności modelu: gdy model jest pewny, zostaje jeden kandydat, gdy niepewny – kilkadziesiąt. W Hugging Face i vLLM temperatura działa przed obcinaniem, więc wpływa na to, co zostanie.
- Wylosowany token trafia na koniec tekstu i nie da się go cofnąć. Kolejne tokeny muszą do niego pasować, więc jeden pechowy token z ogona potrafi pociągnąć za sobą całe zmyślone zdanie.
- Sampler może też zerować tokeny niezgodne ze schematem JSON. Tak działa structured output (zobacz „Wymuszanie formatu”).

### Pułapki

- Greedy nie znaczy najlepiej. Wybieranie zawsze najbardziej prawdopodobnego tokena prowadzi do powtórzeń i pętli (Holtzman i in., 2019). DeepSeek zaleca dla R1 temperaturę 0,5–0,7 właśnie przeciw niekończącym się powtórzeniom. Kary za powtórzenia (repetition, frequency, presence penalty) obniżają logity już użytych tokenów: ograniczają pętle, ale karzą też uzasadnione powtórzenia, np. nazwy zmiennych w kodzie czy klucze JSON.
- Temperatura 0 nie daje pełnej powtarzalności. Obliczenia na GPU dają minimalnie inne liczby zależnie od tego, ile requestów trafiło do batcha, a przy prawie równych logitach to zmienia wybrany token i całą resztę odpowiedzi. Parametr `seed`, tam gdzie API go ma, nie gwarantuje determinizmu. Przy self-hostingu determinizm dają kernele niezależne od batcha, kosztem prędkości (vLLM: `VLLM_BATCH_INVARIANT=1`).
- Rozkład nie mierzy prawdy. Płaski rozkład bywa sygnałem niewiedzy, ale też kilku równie dobrych sformułowań. Model bywa pewny błędnej odpowiedzi, a sampler zawsze coś wybierze i zdanie zabrzmi równie pewnie. Niższa temperatura nie leczy zmyśleń, tylko czyni je powtarzalnymi (zobacz „Halucynacje”).

### Co ustawiasz w praktyce

- W modelach bez rozumowania: ekstrakcja, klasyfikacja i kod przy niskiej temperaturze, 0–0,3; pisanie i szukanie pomysłów przy 0,7–1. Zmieniaj temperaturę albo top-p, nie oba naraz, i sprawdzaj efekt na zestawie ewaluacyjnym, a nie na jednej próbce.
- `logprobs` w API pokazują ten rozkład, zwykle sprzed temperatury i top-p (domyślnie w vLLM). Przydają się do progu pewności w klasyfikacji: każesz modelowi odpowiedzieć jednym tokenem etykiety i czytasz prawdopodobieństwo każdej etykiety. API Claude ich nie zwraca, a OpenAI tylko przy wyłączonym rozumowaniu.
- Kilka próbek przy T > 0 i głosowanie większością (self-consistency) podnosi trafność w zadaniach z jedną poprawną odpowiedzią, a niezgodność próbek jest sygnałem niepewności. Kosztuje tyle razy więcej tokenów, ile próbek.
- Przy modelach rozumujących sampler bywa zablokowany (stan na wrzesień 2026). Claude Opus od wersji 4.7 i Claude Sonnet 5 odrzucają błędem 400 wartości `temperature`, `top_p` i `top_k` inne niż domyślne, a OpenAI przy włączonym rozumowaniu nie przyjmuje `temperature`, `top_p` ani `logprobs`. Sterujesz wtedy poziomem rozumowania i promptem. Tam, gdzie model rozumujący je przyjmuje, zostaw wartości zalecane przez dostawcę: Google zdecydowanie zaleca temperaturę 1,0 dla wszystkich modeli Gemini 3 i ostrzega, że niższa może wpędzić model w pętle. Niska temperatura to narzędzie dla modeli bez rozumowania.

### Sprawdź się

**Pytanie:** Jak model wybiera następny token i jak dobierasz temperaturę i top-p?

**Krótka odpowiedź:** Model zwraca logity dla całego słownika. Softmax z temperaturą, exp(logit/T), zamienia je w rozkład: T poniżej 1 wyostrza, powyżej 1 spłaszcza, a T = 0 to zawsze najlepszy token. Top-p zostawia najmniejszy zbiór tokenów pokrywający np. 90% prawdopodobieństwa i odcina ogon, z którego biorą się dziwne tokeny. W modelach bez rozumowania ekstrakcja i kod dostają niską temperaturę, teksty twórcze wyższą; zmieniaj jeden parametr naraz i sprawdzaj na ewaluacjach. T = 0 nie daje pełnej powtarzalności, a modele rozumujące często blokują sampler albo, jak Gemini 3, działają najlepiej przy domyślnym 1,0.

### Pytania pogłębiające

- **Czemu temperatura 0 nie daje pełnej powtarzalności?** Wynik zależy od tego, z kim request trafił do batcha: inny rozmiar batcha to inna kolejność działań zmiennoprzecinkowych i minimalnie inne logity. Przy dwóch tokenach o prawie równych logitach to wystarczy, żeby wybrać inny, a dalej rozjeżdża się cała odpowiedź.
- **Top-k, top-p, min-p: jaka różnica?** Top-k zostawia stałą liczbę kandydatów bez względu na pewność modelu. Top-p zostawia tylu, żeby pokryć zadany procent prawdopodobieństwa, więc dopasowuje się do rozkładu. Min-p odcina tokeny słabsze niż ułamek najlepszego, np. 0,1 × jego prawdopodobieństwo. Autorzy min-p piszą, że lepiej znosi wysoką temperaturę, ale ponowna analiza z 2025 r. uznała, że ich dowody tego nie potwierdzają.
- **Czy niższa temperatura zmniejsza halucynacje?** Tylko te, które biorą się z wylosowania tokena z ogona. Jeśli model „wierzy” w błędny fakt, T = 0 wybierze go za każdym razem (zobacz „Halucynacje”).
- **Jak użyć logprobs do klasyfikacji?** Każ modelowi odpowiedzieć jednym tokenem etykiety i odczytaj prawdopodobieństwo każdej etykiety. Dostajesz rozkład zamiast jednej odpowiedzi i ustawiasz próg, poniżej którego sprawa idzie do człowieka. Próg kalibruj na własnych danych, bo po post-trainingu pewność modelu bywa zawyżona.

### Źródła

- [Holtzman i in.: The Curious Case of Neural Text Degeneration (top-p, 2019)](https://arxiv.org/abs/1904.09751)
- [Hugging Face: How to generate text](https://huggingface.co/blog/how-to-generate)
- [Thinking Machines: Defeating Nondeterminism in LLM Inference](https://thinkingmachines.ai/blog/defeating-nondeterminism-in-llm-inference/)
- [Dokumentacja Claude: migracja na Opus 5.5 (m.in. parametry samplowania)](https://platform.claude.com/docs/en/models/opus-5-5/migration-guide)
- [Gemini API: przewodnik po Gemini 3 (temperatura)](https://ai.google.dev/gemini-api/docs/gemini-3)

---

## Trening

*Skąd model wie to, co wie*

*Ostatnia zmiana: 28 września 2026*

Model powstaje w trzech etapach. Pretraining daje język i wiedzę przez przewidywanie następnego tokena, SFT uczy roli asystenta, a RL szlifuje zachowanie i rozumowanie. Po treningu wagi są zamrożone, więc wszystko, czego model nie wie, trzeba mu dać w kontekście.

**Po ludzku:** Najpierw lata czytania wszystkiego jak leci. Potem kurs zawodowy na przykładowych rozmowach, po którym kursant wie, jak zachowuje się asystent. Na końcu praktyka z oceną: próbuje sam, a egzaminator nagradza dobre wyniki, więc uczy się tego, za co są punkty.

*Interaktywny widżet na stronie: Kliknij etap i porównaj, co model robi z tym samym promptem.*

### Pretraining

- Zadanie: przewidzieć następny token w ogromnym zbiorze tekstu i kodu (Llama 3: ok. 15 bln tokenów). Strata to cross-entropy, czyli −log prawdopodobieństwa, które model dał poprawnemu tokenowi. Backpropagation liczy gradient, a optymalizator, zwykle AdamW, przesuwa każdą wagę odrobinę w stronę mniejszego błędu. Każda pozycja w tekście to osobny przykład, więc jeden dokument daje naraz tysiące przykładów.
- Liczba operacji to ok. 6 × parametry × tokeny. Chinchilla (2022) wyliczyła, że przy stałym budżecie optimum to ok. 20 tokenów na parametr. Dziś trenuje się dużo dłużej (Qwen3, 2025: 36 bln tokenów dla każdego rozmiaru, ok. 60 tys. na parametr w modelu 0,6B; Llama 3 8B: prawie 2000 na parametr), bo mniejszy, dłużej trenowany model jest tańszy w inferencji przez cały okres użytkowania.
- Przed treningiem dane się filtruje: w Llama 3 usunięto duplikaty na poziomie URL-i, dokumentów (MinHash) i linii, odsiano śmieci heurystykami i wybrano tekst wysokiej jakości klasyfikatorami. Publiczne benchmarki leżą w tym samym internecie i przeciekają do korpusu. Na GSM1k, nowych zadaniach w stylu GSM8K, część modeli wypadła gorzej nawet o 8 punktów procentowych, więc wynik publicznego benchmarku może zawyżać to, co zobaczysz na własnym zadaniu (temat „Ewaluacje”).
- Pod koniec model trenuje się na coraz dłuższych sekwencjach, żeby wydłużyć kontekst, i na małej porcji najlepszych danych, np. kodu i matematyki, przy malejącym learning rate (annealing). Ten etap nazywa się też mid-training.
- Wynik, czyli model bazowy, jest wyuczony dokańczać dokumenty, a nie odpowiadać. Na „Jak upiec chleb?” może dopisać kolejne pytania z forum. W danych do pretrainingu jest dziś sporo par pytanie–odpowiedź i syntetycznych instrukcji, więc współczesne modele bazowe często i tak odpowiadają, ale zawodnie i bez roli asystenta.

### Post-training: SFT i RL

- SFT to trening z tą samą stratą, ale na rozmowach zapisanych w szablonie czatu (zobacz „Jak model widzi czat”), a stratę liczy się tylko na tokenach odpowiedzi asystenta. Setki tysięcy do milionów przykładów pisanych przez ludzi i generowanych przez silniejsze modele uczą formatu, roli i wywoływania narzędzi.
- RLHF: ludzie porównują pary odpowiedzi, na tych porównaniach trenuje się model nagrody, a model językowy optymalizuje się pod jego ocenę (klasycznie algorytmem PPO) z karą KL za odejście od modelu po SFT. W InstructGPT (2022) model o 1,3 mld parametrów po takim treningu wygrywał w ocenach ludzi z 175-miliardowym GPT-3. DPO uczy wprost z par lepsza/gorsza, bez osobnego modelu nagrody. Dziś porównania często robi model-sędzia według spisanych zasad (RLAIF, Constitutional AI); w Tülu 3 odpowiedzi oceniał GPT-4o.
- RLVR: nagrodę przyznaje program, np. testy albo porównanie z poprawnym wynikiem. Model generuje wiele prób, a lepsze są wzmacniane. GRPO porównuje próby na ten sam prompt między sobą, bez osobnego krytyka. Tak powstały modele rozumujące: długi tok myślenia się opłaca, bo zwiększa szansę na nagrodę (zobacz „Modele rozumujące”).
- RL w środowiskach: to samo dla agentów. W wieloturowych zadaniach z narzędziami (terminal, repozytorium z testami, symulowane API) nagradza się stan końcowy; Kimi K2 (2025) miał wspólny etap RL w prawdziwych i syntetycznych środowiskach. SFT uczy formatu wywołań narzędzi, a tu model ćwiczy długie, wieloetapowe przebiegi.
- Destylacja: mniejszy model uczy się na odpowiedziach albo rozkładach prawdopodobieństwa większego, dlatego małe modele są lepsze, niż wynikałoby z ich rozmiaru (zobacz „Destylacja”).

### Co z tego wynika w praktyce

- Po treningu wagi są zamrożone. Model nie uczy się z rozmowy, a „pamięć” w aplikacjach to notatki doklejane do kontekstu (zobacz „Context engineering i pamięć”). O świecie po dacie odcięcia wie tylko to, co dostanie w kontekście.
- RL optymalizuje nagrodę, nie intencję (reward hacking). Model nagradzany za przechodzące testy potrafi je obejść zamiast naprawić kod, a nagradzany ocenami ludzi uczy się im przytakiwać (sycophancy). W RLHF kara KL i różnorodne nagrody to ograniczają, ale nie eliminują. W RLVR dla rozumowania karę KL często się pomija (DAPO, 2025), bo przy długim toku myślenia model musi daleko odejść od punktu startu, więc tam przed reward hackingiem chroni głównie jakość weryfikatora.
- Własny trening zaczynasz od gotowego modelu. Fine-tuning dobrze uczy stylu, formatu i wąskich zadań, słabo nowej wiedzy. Wiedza, która się zmienia albo musi mieć źródło, idzie do kontekstu (zobacz „Fine-tuning i LoRA” i „RAG”).

### Sprawdź się

**Pytanie:** Jak powstaje LLM: czym różnią się pretraining, SFT, RLHF i RLVR?

**Krótka odpowiedź:** Pretraining uczy przewidywać następny token na bilionach tokenów tekstu ze stratą cross-entropy. Stąd język i wiedza, ale model bazowy tylko dokańcza dokumenty. SFT na rozmowach w szablonie czatu uczy roli asystenta i formatu wywołań narzędzi. RLHF optymalizuje pod model nagrody wyuczony z porównań ludzi albo modelu-sędziego, z karą KL za odejście od modelu po SFT. RLVR optymalizuje pod nagrodę z automatycznego sprawdzenia, np. testów: tak powstają modele rozumujące, a w wieloturowych środowiskach z narzędziami także modele do agentów. Ryzykiem RL jest reward hacking. Po treningu wagi są zamrożone, więc bieżącą wiedzę trzeba podać w kontekście.

### Pytania pogłębiające

- **RLHF a RLVR?** RLHF bierze nagrodę z modelu wyuczonego na preferencjach ludzi albo modelu-sędziego: sprawdza się, gdy liczą się styl i pomocność, ale model nagrody da się oszukać. RLVR bierze nagrodę z automatycznego sprawdzenia, np. testów albo wyniku zadania: trudniej ją oszukać i łatwo skalować, ale tylko tam, gdzie wynik da się sprawdzić programem.
- **PPO, DPO, GRPO?** PPO to klasyczne RL z modelem nagrody i osobnym krytykiem, który szacuje wartość stanu. DPO uczy wprost z par „lepsza/gorsza odpowiedź”, bez modelu nagrody i bez generowania w pętli. GRPO (DeepSeek) generuje kilka odpowiedzi na ten sam prompt i porównuje je między sobą, więc nie potrzebuje krytyka.
- **Po co kara KL w RL?** Trzyma model blisko modelu po SFT. Bez niej optymalizacja szybko znajduje odpowiedzi, które model nagrody ocenia wysoko, a ludzie nisko, i model traci ogólne umiejętności. W RLVR dla rozumowania często się ją pomija (DAPO), bo model musi daleko odejść od punktu startu, a przed obejściem nagrody chroni wtedy dobry weryfikator.
- **Kiedy fine-tuning, a kiedy RAG?** Fine-tuning dla stylu, formatu i wąskich umiejętności. RAG dla wiedzy, która się zmienia i musi mieć źródło (zobacz „Fine-tuning i LoRA” i „RAG”).

### Źródła

- [Ouyang i in.: Training language models to follow instructions with human feedback (InstructGPT, 2022)](https://arxiv.org/abs/2203.02155)
- [Lambert i in.: Tülu 3, otwarty przepis na post-training z RLVR (2024)](https://arxiv.org/abs/2411.15124)
- [Llama Team: The Llama 3 Herd of Models (2024), dane i dekontaminacja](https://arxiv.org/abs/2407.21783)
- [Kimi Team: Kimi K2: Open Agentic Intelligence (2025)](https://arxiv.org/abs/2507.20534)
- [Andrej Karpathy: Deep Dive into LLMs like ChatGPT](https://www.youtube.com/watch?v=7xTGNNLPyMI)

---

## Destylacja

*Skąd model wie to, co wie*

*Ostatnia zmiana: 29 września 2026*

Destylacja trenuje mały model, ucznia, na wyjściach dużego, nauczyciela. Dzięki niej małe modele są lepsze, niż wynikałoby z ich rozmiaru, rozumowanie trafiło do modeli 7B, a ty możesz zastąpić drogi model tańszym w jednym zadaniu.

**Po ludzku:** Uczeń szachowy, który widzi tylko ruchy arcymistrza, uczy się wolniej niż taki, któremu arcymistrz mówi też, które inne ruchy były prawie równie dobre, a które przegrywają od razu. Destylacja on-policy to arcymistrz, który ogląda partie ucznia i ocenia każdy jego ruch, zamiast pokazywać własne. Uczeń rzadko przerasta mistrza, za to przejmuje jego błędy.

*Interaktywny widżet na stronie: Przełącz cel, na którym uczy się uczeń, i zmieniaj temperaturę. Porównaj, ile mówi jedna etykieta, a ile rozkład nauczyciela.*

### Etykiety twarde i rozkłady

- Etykiety twarde (destylacja sekwencji): nauczyciel generuje odpowiedzi na twoje prompty, a uczeń przechodzi na nich zwykłe SFT (zobacz „Trening”). Wystarczy tekst, więc działa przez API i przy różnych tokenizerach. To najczęstsza forma destylacji.
- Rozkłady (miękkie etykiety, destylacja logitów): uczeń na każdej pozycji minimalizuje dywergencję KL między pełnym rozkładem następnego tokena nauczyciela a swoim. Hinton i in. (2015) podnoszą w obu modelach temperaturę softmaksu (zobacz „Następny token”), żeby wyciągnąć małe prawdopodobieństwa, a tę część straty mnożą przez T², bo jej gradienty maleją jak 1/T². To, która błędna odpowiedź jest prawie dobra, siedzi w stosunkach bardzo małych prawdopodobieństw; Hinton nazywał to „dark knowledge”.
- Rozkład niesie więcej informacji w każdym przykładzie: zamiast jednego indeksu ranking alternatyw, a gradient mniej się waha między przykładami. W eksperymencie z rozpoznawaniem mowy z tej pracy, na 3% danych, etykiety twarde przeuczały model przy 44,5% trafności, a rozkłady nauczyciela doprowadziły do 57,0%, przy 58,9% dla treningu na wszystkich danych.
- Cena: potrzebujesz logitów nauczyciela, czyli otwartych wag albo własnego modelu. API zwraca co najwyżej krótką listę logprobs, API Claude żadnej, podobnie jak OpenAI przy włączonym rozumowaniu. Oba modele muszą mieć wspólny tokenizer, bo rozkład przypisuje prawdopodobieństwa numerom tokenów. Pełny rozkład to 100–260 tys. liczb na pozycję, więc Gemma 3 zapisuje 256 tokenów losowanych według prawdopodobieństw nauczyciela, a resztę zeruje i renormalizuje rozkład.

### Destylacja on-policy

- Obie powyższe metody uczą na tekstach, których uczeń sam nie napisał: odpowiedziach nauczyciela albo gotowym zbiorze. Przy generowaniu uczeń popełnia błędy, których nauczyciel nie robi, trafia na sytuacje, których w treningu nie widział, i błędy się kumulują.
- W destylacji on-policy uczeń sam generuje odpowiedź, a nauczyciel w jednym przebiegu liczy prawdopodobieństwo każdego jej tokena. Strata to odwrotna KL na każdym tokenie: im mniej prawdopodobny token dla nauczyciela, tym większa kara. To jak RL, tylko z oceną każdego tokena zamiast jednej nagrody za całość. Odwrotna KL skłania ucznia do trzymania się jednego ze sposobów nauczyciela zamiast rozmywania się między kilkoma.
- W Qwen3 (2025) tak trenowano modele od 0,6B do 14B i 30B-A3B z nauczycielem Qwen3-32B albo 235B-A22B: najpierw SFT na odpowiedziach nauczyciela, potem etap on-policy. Na Qwen3-8B ten etap dał 74,4% w AIME 2024 kosztem 1800 godzin GPU, a RL z tego samego punktu 67,6% kosztem 17 920 godzin. Thinking Machines rozpisali metodę we wpisie „On-Policy Distillation” (październik 2025).

### W pretrainingu małych modeli

- W Gemmie 2 (2024) modele 2B i 9B trenowano na rozkładach większego nauczyciela, na ponad 50 razy więcej tokenów, niż wynika z optimum obliczeniowego. W ablacji model 2B po 500 mld tokenów miał średnio 67,7 pkt z destylacją z modelu 7B i 60,3 bez niej. W Gemmie 3 (2025) destylowane są wszystkie rozmiary.
- Llama 3.2 1B i 3B (wrzesień 2024) powstały przez przycięcie Llamy 3.1 8B, a w pretrainingu logity modeli 8B i 70B były celami dla każdego tokena.
- Zwykły cel w pretrainingu to jeden token, który akurat stał w dokumencie; rozkład nauczyciela mówi, co mogło tam stać, więc każdy token uczy więcej. To jeden z powodów, dla których modele 1–4B wypadają lepiej, niż sugeruje ich rozmiar.

### Destylacja rozumowania

- DeepSeek-R1 (styczeń 2025): ok. 800 tys. przykładów, w tym ok. 600 tys. śladów rozumowania, z których zostawiono tylko te z poprawnym wynikiem. Samo SFT na nich, bez RL, dało modele od Qwen2.5 1,5B do Llamy 3.3 70B. Qwen2.5-32B po destylacji miał 72,6% w AIME 2024, a ta sama baza po ponad 10 tys. krokach dużego RL 47,0%.
- Wystarcza też mały, starannie dobrany zbiór. s1 (2025): 1000 pytań ze śladami rozumowania z Gemini Flash Thinking i 26 minut treningu Qwen2.5-32B na 16 kartach H100. LIMO (2025): 800 wybranych rozwiązań i 63,3% w AIME 2024. Wiedza jest już w bazie, a ślady uczą formy długiego rozumowania (zobacz „Modele rozumujące”).

### Ograniczenia destylacji

- Uczeń rzadko przerasta nauczyciela i kopiuje jego błędy i uprzedzenia; autorzy R1 zaznaczają, że pójście dalej wymaga silniejszej bazy i większego RL. Etykiety twarde utrwalają nawet zgadywanie: jeśli nauczyciel wylosował imię, którego nie znał, uczeń nauczy się podawać je z pewnością.
- Zbyt duża różnica między nauczycielem a uczniem też szkodzi. W ablacji Gemmy 3 mniejszy nauczyciel wygrywał przy krótkim treningu, a większy dopiero przy długim. Li i in. (2025): modele do 3B nie zawsze zyskują na długich śladach rozumowania silnych nauczycieli i lepiej uczą się z mieszanki krótkich i długich.
- Styl przenosi się łatwiej niż umiejętności. Gudibande i in. (2023): oceniający uznali modele trenowane na odpowiedziach ChatGPT za konkurencyjne, ale testy celowane pokazały, że poza zadaniami dobrze pokrytymi w danych nie nadrobiły prawie nic. Przenosi się wynik na benchmarku bliskim danym destylacji, a odporność na nietypowe wejścia – słabiej.

### Regulaminy i ochrona przed destylacją

- Regulaminy zabraniają używania wyników do trenowania modeli konkurencyjnych (stan na wrzesień 2026). OpenAI, Terms of Use (od 1 stycznia 2026), wśród zakazów: „Use Output to develop models that compete with OpenAI”. Umowa dla API (Services Agreement, od tej samej daty) robi dwa wyjątki: niedystrybuowane modele do klasyfikacji i porządkowania danych, np. embeddingi i klasyfikatory, oraz dotrenowanie modeli OpenAI. Anthropic, Commercial Terms (od 17 czerwca 2025): nie wolno „access the Services to build a competing product or service, including to train competing AI models”, chyba że Anthropic wprost się zgodzi. Google, warunki Gemini API (od 23 marca 2026): „You may not use the Services to develop models that compete with the Services”.
- Surowy tok myślenia jest ukryty. OpenAI przy o1 (wrzesień 2024) jako powody podało wygodę użytkownika, przewagę konkurencyjną i możliwość monitorowania toku myślenia. Dokumentacja Claude pisze, że streszczenie „zapobiega nadużyciom” i że żadne ustawienie nie zwraca surowego toku. Gemini zwraca streszczenia bez podanego powodu.
- Anthropic (23 lutego 2026) twierdzi, że wykrył kampanie DeepSeek, Moonshot AI i MiniMax: ponad 16 mln wymian przez ok. 24 tys. fałszywych kont. Kampanie celowały w rozumowanie, narzędzia i kod, m.in. prośbami o rozpisanie krok po kroku rozumowania stojącego za gotową odpowiedzią. To twierdzenia jednej strony.

### Destylacja w twoim systemie

- Typowy przypadek: duży model z długim promptem dobrze robi jedno zadanie, ale przy twoim wolumenie jest za drogi albo za wolny. Zbierz kilka tysięcy prawdziwych wejść, wygeneruj odpowiedzi nauczycielem, odrzuć złe walidatorem albo sędzią i dotrenuj mały model, np. z LoRA (zobacz „Fine-tuning i LoRA”). Uczeń nie potrzebuje już długiego promptu, więc płacisz za mniej tokenów wejścia i szybciej dostajesz odpowiedź. Kandydatów na ucznia porównujesz jak w temacie „Wybór modelu”.
- Rozkłady i on-policy wchodzą w grę, gdy nauczyciel ma otwarte wagi i ten sam tokenizer, np. większy model z tej samej rodziny. OpenAI wprost pozwala dotrenować jego modele i budować wewnętrzne klasyfikatory, ale czy wąski model generatywny do własnego użytku „konkuruje”, żaden z tych regulaminów nie precyzuje, więc to pytanie do prawnika. Otwarty nauczyciel z odpowiednią licencją omija problem: DeepSeek-R1 ma licencję MIT, a jego karta modelu wprost dopuszcza destylację.
- Ucznia sprawdzasz na zestawie ewaluacyjnym z prawdziwych przypadków, odłożonym przed generowaniem danych (zobacz „Ewaluacje”): w porównaniu z nauczycielem, uwzględniając przypadki nietypowe i odmowy. Przypadki, na których uczeń przegrywa, możesz kierować do nauczyciela.

### Sprawdź się

**Pytanie:** Jak destylacja przenosi umiejętności dużego modelu do małego i czym różnią się etykiety twarde, rozkłady nauczyciela i destylacja on-policy?

**Krótka odpowiedź:** Uczeń, mały model, uczy się naśladować nauczyciela, duży model. Najczęściej na etykietach twardych: nauczyciel generuje odpowiedzi, a uczeń przechodzi na nich zwykłe SFT, więc wystarczy tekst z API. Destylacja logitów minimalizuje dywergencję KL między pełnymi rozkładami następnego tokena nauczyciela i ucznia, zwykle przy podniesionej temperaturze. Jeden przykład niesie wtedy więcej informacji, bo pokazuje też, które alternatywy są bliskie, ale potrzebne są logity nauczyciela i wspólny tokenizer. W destylacji on-policy uczeń generuje sam, a nauczyciel ocenia każdy jego token odwrotną KL, więc uczeń uczy się też na własnych błędach; w Qwen3 dało to lepszy wynik niż RL przy ok. 1/10 godzin GPU. Uczeń rzadko przerasta nauczyciela, kopiuje jego błędy i łatwiej przejmuje styl niż umiejętności, więc sprawdzaj go na własnym zestawie ewaluacyjnym. Regulaminy OpenAI, Anthropic i Google zabraniają używania wyników do trenowania modeli konkurencyjnych.

### Pytania pogłębiające

- **Skoro rozkłady niosą więcej informacji, czemu najczęściej destyluje się na etykietach twardych?** Bo etykietom twardym wystarczy tekst. Rozkład wymaga logitów nauczyciela, czyli otwartych wag, a API zwraca co najwyżej krótką listę logprobs albo nic. Oba modele muszą mieć wspólny tokenizer, a pełny rozkład to 100–260 tys. liczb na pozycję, więc zapisuje się próbkę tokenów, jak 256 w Gemmie 3. Gdy nauczyciel jest dostępny tylko przez API, zostaje SFT na jego odpowiedziach.
- **Czemu destylacja on-policy wygrywa z SFT na odpowiedziach tego samego nauczyciela?** SFT uczy w sytuacjach, do których dochodzi nauczyciel. Uczeń przy generowaniu popełnia własne błędy, trafia na sytuacje, których nie widział, i błędy się kumulują. On-policy uczy na tekstach samego ucznia, a nauczyciel ocenia każdy token, więc sygnał jest gęsty jak w SFT i pochodzi z rozkładu ucznia jak w RL. Kosztem jest dostęp do logprobs nauczyciela i jego przebieg na każdej próbce ucznia.
- **Uczeń dorównuje nauczycielowi na zestawie ewaluacyjnym, a na produkcji myli się na lekko innych wejściach. Co się stało?** Dane destylacji pokrywały rozkład zestawu ewaluacyjnego, a nie ruch produkcyjny; do tego uczeń przejął styl nauczyciela łatwiej niż umiejętność. Pomaga poszerzenie wejść o prawdziwe przypadki z produkcji, w tym trudne i nietypowe, świeży zestaw ewaluacyjny z produkcji i kierowanie do nauczyciela przypadków, w których walidator odrzuca wynik ucznia.
- **Czy wolno destylować model dostępny tylko przez API do własnego modelu?** Technicznie wystarczą etykiety twarde. Regulaminy (stan na wrzesień 2026) zabraniają używania wyników do trenowania modeli konkurencyjnych. OpenAI robi wyjątek dla niedystrybuowanych klasyfikatorów i embeddingów oraz dla dotrenowania modeli OpenAI, a Anthropic dopuszcza to tylko za swoją wyraźną zgodą. Czy wąski model do własnego użytku „konkuruje”, regulaminy nie precyzują, więc to pytanie do prawnika. Otwarty nauczyciel z licencją, która pozwala na destylację, jak MIT w DeepSeek-R1, omija problem.
- **Czy większy nauczyciel zawsze daje lepszego ucznia?** Nie. W ablacji Gemmy 3 mniejszy nauczyciel wygrywał przy krótkim treningu, a większy dopiero przy długim. Modele do 3B nie zawsze zyskują na długich śladach rozumowania silnych nauczycieli, a pomaga im mieszanka krótkich i długich śladów (Li i in., 2025). Nauczyciela wybiera się po wyniku ucznia na ewaluacji, a nie po wyniku samego nauczyciela.

### Źródła

- [Hinton, Vinyals, Dean: Distilling the Knowledge in a Neural Network (2015)](https://arxiv.org/abs/1503.02531)
- [DeepSeek-AI: DeepSeek-R1 (2025), rozdział o destylacji do Qwen i Llamy](https://arxiv.org/abs/2501.12948)
- [Qwen Team: Qwen3 Technical Report (2025), destylacja strong-to-weak](https://arxiv.org/abs/2505.09388)
- [Thinking Machines: On-Policy Distillation (październik 2025)](https://thinkingmachines.ai/blog/on-policy-distillation/)
- [Anthropic: Detecting and preventing distillation attacks (luty 2026)](https://www.anthropic.com/news/detecting-and-preventing-distillation-attacks)

---

## Fine-tuning i LoRA

*Skąd model wie to, co wie*

*Ostatnia zmiana: 28 września 2026*

Fine-tuning to dalszy trening gotowego modelu na twoich przykładach: dobrze zmienia to, jak model odpowiada, a słabo to, co wie. LoRA robi to tanio, bo zamraża model i trenuje małą poprawkę, często poniżej 1% wag.

**Po ludzku:** Fine-tuning to szkolenie stanowiskowe doświadczonego pracownika. Po nim pisze w firmowym formacie i tonie, ale cennika na pamięć nie wykuje, od tego jest segregator na biurku, czyli RAG. LoRA to poprawki na przezroczystej folii nałożonej na podręcznik: oryginał zostaje nietknięty, a folię można zdjąć albo podmienić na inną.

*Interaktywny widżet na stronie: Wybierz problem i zobacz, od którego szczebla zacząć.*

### Co fine-tuning zmienia, a czego nie

- Fine-tuning przesuwa wagi tak, żeby odpowiedzi przypominały twoje przykłady. Najlepiej uczy tego, co widać w każdej odpowiedzi: formatu, stylu i tonu, stałego zachowania (kiedy dopytać, kiedy odmówić) i wąskiej umiejętności, takiej jak klasyfikacja czy wyciąganie pól z dokumentu. Przenosi też zachowanie dużego modelu w jednym zadaniu do mniejszego, tańszego i szybszego, trenowanego na odpowiedziach dużego (temat „Destylacja”).
- Fakty wchodzą w wagi słabo i ryzykownie. Gekhman i in. (2024): model uczy się przykładów z wiedzą, której nie znał, wolniej niż pozostałych, a w miarę jak je opanowuje, jego skłonność do halucynacji rośnie liniowo. Ovadia i in. (2023): RAG wygrywał z douczaniem na surowym tekście, i dla wiedzy znanej, i dla nowej. Fakt w wagach nie ma też źródła i nie da się go poprawić bez kolejnego treningu.
- Kolejność: prompt i kontekst (instrukcje, przykłady, structured output), potem RAG dla wiedzy (temat „RAG”), fine-tuning na końcu. Prompt zmieniasz w minutę, RAG aktualizujesz, dodając dokument, a fine-tuning to dane, trening, ewaluacje i nowy model do utrzymania. Sięgasz po niego, gdy dopracowany prompt wciąż nie przechodzi ewaluacji albo gdy długi prompt z przykładami jest za drogi przy twoim wolumenie.

### Rodzaje fine-tuningu i gdzie trenować

- SFT (supervised fine-tuning): pary wejście → wzorcowa odpowiedź. Strata liczona tylko na tokenach odpowiedzi, jak w etapie SFT z tematu „Trening”, ale na twoich przykładach. Model naśladuje wzorce, więc ich jakość wyznacza sufit.
- Preference tuning, np. DPO (Rafailov i in., 2023): pary „lepsza i gorsza odpowiedź” na ten sam prompt. Model podnosi prawdopodobieństwo lepszej względem gorszej, bez osobnego modelu nagrody i bez pętli RL. Sprawdza się w uczeniu tonu i tego, czego model ma unikać, bo różnicę łatwiej pokazać, niż napisać idealny wzorzec.
- Reinforcement fine-tuning: model sam generuje odpowiedzi, a grader je punktuje. Grader to funkcja w kodzie, porównanie z oczekiwanym wynikiem albo model oceniający. Wzorcowe odpowiedzi nie są potrzebne, tylko sposób oceny, więc pasuje do zadań z weryfikowalnym wynikiem. Dziurawy grader model wykorzysta (reward hacking, zobacz „Trening”).
- Hostowany fine-tuning modeli zamkniętych: wysyłasz plik JSONL z przykładami, dostawca trenuje i serwuje, a wag nie dostajesz. Google Vertex AI oferuje dla modeli Gemini SFT, preference tuning i RL (wrzesień 2026). OpenAI wygasza usługę fine-tuningu: od 7 maja 2026 nie przyjmuje organizacji, które nigdy z niej nie korzystały, od 2 lipca 2026 blokuje też te bez inferencji na modelu po fine-tuningu w ostatnich 60 dniach, a od 6 stycznia 2027 nikt nie uruchomi nowego treningu.
- Model open-weight (temat „Modele open-weight”) wytrenujesz też w zarządzanej usłudze: Together AI przyjmuje plik z przykładami, a Tinker od Thinking Machines daje API do własnej pętli SFT, DPO lub RL na LoRA. GPU są po stronie dostawcy, a adapter pobierasz i serwujesz gdziekolwiek. Trening na własnym sprzęcie daje pełną kontrolę nad pipeline’em, ale GPU i serwowanie są po twojej stronie.

### Jak działa LoRA

- Pełny fine-tuning aktualizuje każdą wagę. LoRA (Hu i in., 2021) zamraża macierz W o wymiarach d × k i uczy tylko poprawki ΔW = B·A, gdzie B ma wymiar d × r, a A – r × k. Rank r (np. 8, 16, 64) jest dużo mniejszy od d i k, więc zamiast d·k parametrów trenujesz r·(d + k): dla macierzy 4096 × 4096 i r = 16 to 131 tys. zamiast 16,8 mln. Autorzy zakładają, że zmiana wag potrzebna do dostosowania modelu ma niski rank. B jest inicjalizowana zerami, więc na początku ΔW = 0 i model działa jak bazowy, a wyjście adaptera mnoży się przez α/r.
- Oryginalna praca dodawała LoRA głównie w attention. Schulman (Thinking Machines, 2025) pokazuje, że LoRA na wszystkich warstwach, zwłaszcza MLP, dorównuje pełnemu fine-tuningowi na małych i średnich zbiorach, a w RL nawet z rankiem 1. Przegrywa, gdy danych jest więcej, niż zmieści adapter, i gorzej niż pełny fine-tuning znosi duże batche. Optymalny learning rate jest ok. 10 razy wyższy niż przy pełnym fine-tuningu.
- QLoRA (Dettmers i in., 2023) to LoRA na bazie skwantyzowanej do 4 bitów w formacie NF4 (temat „Kwantyzacja”). Gradienty przechodzą przez zamrożoną bazę do adaptera w 16 bitach. Baza zajmuje ok. 4 razy mniej pamięci, a w pracy fine-tuning modelu 65B zmieścił się na jednej karcie 48 GB bez straty jakości względem treningu w 16 bitach.

*Interaktywny widżet na stronie: Zmień rank i klasę modelu. Zobacz, ile wag trenuje LoRA i ile pamięci GPU potrzeba.*

- Adapter to mały plik: dla modelu klasy 8B z r = 16 ok. 42 mln parametrów, czyli ok. 84 MB w BF16 przy 16 GB bazy. Trzymasz jedną bazę i wiele adapterów, np. na klienta, język albo zadanie. vLLM trzyma jedną kopię bazy i łączy w jednym batchu requesty do różnych adapterów; S-LoRA (Sheng i in., 2023) serwuje tak tysiące adapterów na jednym GPU. Cena to dodatkowe mnożenie B·(A·x) w każdym kroku.
- Scalanie: po treningu B·A można dodać do W. Model jest wtedy tak samo szybki jak bazowy, ale każdy wariant to osobna pełna kopia. Kilka adapterów tej samej bazy można też złożyć w jeden bez treningu, sumą ważoną albo metodami TIES i DARE (w Hugging Face PEFT `add_weighted_adapter`). Umiejętności potrafią się przy tym nawzajem psuć, więc scalony adapter ewaluujesz jak nowy model.

### Dane, ewaluacja, utrzymanie

- Jakość danych wygrywa z ilością. W pracy LIMA (Zhou i in., 2023) wystarczyło 1000 starannie dobranych przykładów SFT, żeby model 65B dawał odpowiedzi wysokiej jakości. Autorzy wnioskują, że wiedza pochodzi z pretrainingu, a dostrajanie uczy głównie formy. Model uczy się wszystkiego, co w danych powtarzalne, także literówek, niespójnego formatu i złych odpowiedzi.
- Zestaw ewaluacyjny odkładasz przed treningiem i nigdy na nim nie trenujesz (temat „Ewaluacje”). Najpierw mierzysz na nim bazę z najlepszym promptem: to poprzeczka, którą fine-tuning musi przeskoczyć. Dokładasz przypadki spoza zadania i testy odmów, bo fine-tuning osłabia zabezpieczenia: Qi i in. (2023) zdjęli je z GPT-3.5 Turbo 10 przykładami za mniej niż 0,20 USD, a zwykłe, nieszkodliwe zbiory też je osłabiały, tylko mniej.
- Przeuczenie: strata treningowa spada, walidacyjna rośnie, a model powtarza frazy z przykładów. Pomaga mniej epok, niższy learning rate i wybór checkpointu na podstawie walidacji. Katastrofalne zapominanie: model traci umiejętności spoza twoich danych. LoRA zapomina mniej niż pełny fine-tuning, ale na dużych zbiorach też mniej się uczy (Biderman i in., 2024, na kodzie i matematyce: przypadek ograniczonej pojemności opisany wyżej).
- Model po fine-tuningu jest przywiązany do bazy. Adapter pasuje tylko do dokładnie tej wersji wag, a przy hostowanym fine-tuningu model znika razem z bazą: OpenAI wyłącza 23 października 2026 m.in. ft-gpt-4.1-nano. Nowa baza to nowy trening, więc wersjonujesz razem dane, konfigurację, wersję bazy, adapter i wyniki ewaluacji, a cały pipeline uruchamiasz jednym poleceniem. Przy każdej nowej bazie najpierw sprawdź, czy sam prompt już nie wystarcza.

### Sprawdź się

**Pytanie:** Kiedy użyjesz fine-tuningu zamiast promptu albo RAG i jak działa LoRA?

**Krótka odpowiedź:** Kolejność: prompt i kontekst, dla wiedzy RAG, fine-tuning na końcu. Fine-tuning dobrze uczy zachowania (formatu, tonu, wąskiego zadania) i potrafi przenieść zachowanie dużego modelu do małego. Faktów uczy słabo: wchodzą niepewnie, bez źródła, każda zmiana to nowy trening, a do tego mogą nasilić halucynacje. LoRA zamraża wagi i uczy poprawki ΔW = B·A o niskim ranku r, czyli r·(d + k) parametrów zamiast d·k. Adapter waży dziesiątki MB, więc na jednej bazie serwuje się wiele adapterów. QLoRA robi to samo na bazie w 4 bitach.

### Pytania pogłębiające

- **Masz 50 tys. firmowych dokumentów, które zmieniają się co tydzień. Fine-tuning czy RAG?** RAG. Fakty z fine-tuningu wchodzą niepewnie, nie mają źródła, a każda zmiana wymaga nowego treningu. Fine-tuning może dojść później, żeby nauczyć model formatu odpowiedzi i cytowania fragmentów, ale wiedza zostaje w indeksie.
- **Jak dobierasz rank LoRA i warstwy, do których ją dodajesz?** Wszystkie macierze liniowe, łącznie z MLP, bo LoRA tylko w attention wyraźnie odstaje. Rank to pojemność adaptera: na małych i średnich zbiorach niski wystarcza, w RL nawet r = 1, a przy dużych zbiorach LoRA zaczyna przegrywać z pełnym fine-tuningiem. Learning rate ok. 10 razy wyższy niż przy pełnym fine-tuningu, a kilka ranków porównuje się na ewaluacji.
- **Masz 200 klientów i każdy chce model w swoim stylu. Jak to serwujesz?** Jedna baza i adapter LoRA na klienta, bez scalania. vLLM wybiera adapter dla każdego requestu, trzyma kilka aktywnych adapterów w jednym batchu obok jednej kopii bazy i ładuje kolejne w locie. Cena to trochę dodatkowego liczenia w każdym kroku zamiast 200 pełnych kopii modelu.
- **Po fine-tuningu format jest idealny, ale model gorzej radzi sobie poza zadaniem i łatwiej go namówić na rzeczy, których wcześniej odmawiał. Co się stało?** Katastrofalne zapominanie i osłabione zabezpieczenia: trening przesunął wagi tylko w stronę twoich przykładów. Pomaga mniej epok, niższy learning rate albo LoRA zamiast pełnego fine-tuningu, przykłady ogólne i odmowy w danych, a w ewaluacji zestaw spoza zadania i testy bezpieczeństwa.
- **Dostawca wycofuje model bazowy, na którym stoi twój fine-tuning. Co robisz?** Najpierw sprawdź, czy nowa baza z samym promptem nie przechodzi już ewaluacji, bo wtedy fine-tuning przestaje być potrzebny. Jeśli nie, trenujesz od nowa na nowej bazie tym samym pipeline’em. Dane, konfiguracja i zestaw ewaluacyjny są wersjonowane, więc to jedno uruchomienie.

### Źródła

- [Hu i in.: LoRA: Low-Rank Adaptation of Large Language Models (2021)](https://arxiv.org/abs/2106.09685)
- [Dettmers i in.: QLoRA: Efficient Finetuning of Quantized LLMs (2023)](https://arxiv.org/abs/2305.14314)
- [John Schulman, Thinking Machines: LoRA Without Regret (2025)](https://thinkingmachines.ai/blog/lora/)
- [Gekhman i in.: Does Fine-Tuning LLMs on New Knowledge Encourage Hallucinations? (2024)](https://arxiv.org/abs/2405.05904)
- [Thinking Machines: Tinker, API do trenowania modeli open-weight z LoRA](https://thinkingmachines.ai/tinker/)

---

## Jak model widzi czat

*Skąd model wie to, co wie*

*Ostatnia zmiana: 28 września 2026*

Model nie widzi okienka czatu. System prompt, wiadomości, wywołania narzędzi i ich wyniki są sklejane w jeden dokument ze znacznikami ról, a model dopisuje ciąg dalszy za znacznikiem asystenta. Stąd biorą się koszty długich rozmów, granice system promptu i większość błędów przy self-hostingu.

**Po ludzku:** Scenariusz, w którym każda kwestia ma podpis: REŻYSER, KLIENT, ASYSTENT. Aktor bez pamięci dostaje za każdym razem cały scenariusz od pierwszej strony, na końcu widzi pusty podpis ASYSTENT i dopisuje swoją kwestię. Jeśli ktoś wsunie do scenariusza obcą kartkę, aktor przeczyta ją tak samo jak resztę.

*Interaktywny widżet na stronie: Dokładaj wiadomości i wywołania narzędzi, przełączaj widok. Zobacz, że każde zapytanie wysyła cały dokument od nowa.*

### Szablon czatu

- Znaczniki ról to tokeny specjalne: osobne numery w słowniku, a nie zwykłe znaki (zobacz „Tokeny”). Format model poznał w SFT (zobacz „Trening”): po znaczniku asystenta pada odpowiedź, a po niej token końca tury.
- Każda rodzina modeli ma własny szablon: ChatML w Qwen (`<|im_start|>user … <|im_end|>`), Llama 3 (`<|start_header_id|>user<|end_header_id|> … <|eot_id|>`), harmony w gpt-oss (`<|start|>user<|message|> … <|end|>`), Mistral (`[INST] … [/INST]`). Wysyłasz listę wiadomości z rolami, a serwer renderuje ją szablonem, na którym trenowano model.
- W Hugging Face szablon jest napisany w Jinja i dołączony do tokenizera. `apply_chat_template(messages, add_generation_prompt=True)` skleja dokument i dokleja na końcu znacznik asystenta. Bez niego model potrafi ciągnąć dalej wiadomość użytkownika zamiast odpowiadać.
- Generowanie kończy token końca tury, o ile serwer ma go na liście tokenów stopu. W Llamie 3 turę kończy `<|eot_id|>`, a nie `<|end_of_text|>`. Serwer, który czeka tylko na ten drugi, pozwoli modelowi dopisać znacznik użytkownika i wymyślić jego kolejną wiadomość.

### Cały dokument w każdej turze

- Model nie pamięta rozmowy. Każde zapytanie niesie cały dokument od początku, więc łączna liczba wysłanych tokenów rośnie z kwadratem liczby tur (zobacz „Okno kontekstowe i agent”). Stan po stronie serwera, np. `previous_response_id` w OpenAI, oszczędza tylko wysyłanie: serwer odtwarza dokument, a wszystkie wcześniejsze tokeny wejściowe są znowu płatne. Co z historii zostawić, streścić albo wyrzucić, omawia „Context engineering i pamięć”.
- Stały początek dokumentu, czyli system prompt, definicje narzędzi i starsza historia, nadaje się do prompt cachingu (zobacz „Prompt caching”). Zmienna rzecz na początku, np. aktualna godzina w system prompcie, psuje cache w każdej turze. Edycja starej wiadomości daje nowy dokument i cache przepada od miejsca zmiany.
- Narzędzia to też fragmenty dokumentu. Definicje stoją obok system promptu i kosztują tokeny w każdej turze. Wywołanie to tekst, który model pisze za specjalnym znacznikiem, a wynik twój kod dopisuje jako nowy fragment (zobacz „Narzędzia (function calling)”).
- Myślenie modeli rozumujących to kolejny fragment z własnymi znacznikami: `<think>…</think>` w części otwartych modeli, kanał `analysis` w harmony (zobacz „Modele rozumujące”). Harmony wycina je z historii po odpowiedzi końcowej, ale zostawia w trakcie wywołań narzędzi.

### Obrazy, PDF-y i głos

- Enkoder wizyjny tnie obraz na kwadraty i zamienia każdy na wektor, który zajmuje w ciągu miejsce jak token. U Claude’a kwadrat ma 28 × 28 px, więc zdjęcie 1000 × 1000 px to 1296 tokenów, a Claude 4.7 i nowsze zmniejszają obraz powyżej 2576 px na dłuższym boku albo 4784 tokenów (stan na wrzesień 2026).
- Obraz zostaje w historii i jest płatny w każdej turze: dziesięć zrzutów ekranu 1000 × 1000 px w historii agenta to ok. 13 tys. tokenów w każdym zapytaniu. Claude czyta każdą stronę PDF-a dwa razy, jako tekst (1500–3000 tokenów) i jako obraz, więc 100-stronicowy raport to 150–300 tys. tokenów samego tekstu. Takie wejście cache’uj, zmniejszaj przed wysłaniem, a zrzuty, których agent już nie potrzebuje, usuwaj.
- Dźwięk też zamienia się w tokeny: Gemini liczy 32 tokeny na sekundę nagrania, a Realtime API OpenAI 10 na sekundę mowy użytkownika i 20 na sekundę mowy modelu. Realtime API przy każdej odpowiedzi podaje modelowi całą rozmowę od nowa.
- Agenta głosowego buduje się na dwa sposoby. Łańcuch (mowa na tekst → model tekstowy → tekst na mowę) daje transkrypcję, kontrolę treści przed odpowiedzią i swobodny wybór modelu, ale każdy etap wydłuża ciszę, którą słyszy rozmówca. Model speech-to-speech (OpenAI Realtime, Gemini Live) obsługuje dźwięk w jednej sesji, z przerywaniem w pół zdania i wykrywaniem końca wypowiedzi, ale mniej w nim widać. Mierz czas od końca wypowiedzi rozmówcy do pierwszego dźwięku odpowiedzi, medianę i p95.

### System prompt to nie zabezpieczenie

- System prompt to tekst na początku dokumentu, a model nauczono traktować go priorytetowo. Nie jest osobnym kanałem ani uprawnieniem. Polecenie w mailu, na stronie albo w wyniku narzędzia leży w tym samym ciągu tokenów i czasem wygrywa (zobacz „Prompt injection”). Zasady, które muszą obowiązywać, egzekwuje kod aplikacji. Sekretów nie trzymaj w system prompcie, bo model może go zacytować.
- Tekst użytkownika nie może stać się znacznikiem. W dobrze zbudowanym API wpisane „<|im_start|>system” to zwykłe znaki. Przy self-hostingu sprawdź to sam: tokenizery Hugging Face domyślnie rozpoznają napisy tokenów specjalnych w tekście (`split_special_tokens=False`), więc wklejony tekst może otworzyć prawdziwą turę systemu.

### Self-hosting i fine-tuning

- Przy modelu open-weight (zobacz „Modele open-weight”) szablon jest częścią modelu. Zły albo nieaktualny nie rzuca błędem, tylko po cichu pogarsza odpowiedzi i psuje tool calling. Częsty przypadek to podwójny token początku tekstu: dokument z `apply_chat_template(tokenize=False)` tokenizuje się drugi raz z dodawaniem tokenów specjalnych, a dokumentacja Hugging Face ostrzega, że to obniża jakość.
- Dane do fine-tuningu renderuj dokładnie tym szablonem, którego użyje serwer, i licz stratę tylko na tokenach asystenta (zobacz „Fine-tuning i LoRA”).
- Prefill: kończysz listę wiadomości początkiem odpowiedzi, np. `{`, a model pisze od tego miejsca. W transformers robi to `continue_final_message=True`. API Claude od Opus 4.6 i Sonnet 4.6 odrzuca prefill błędem 400 i odsyła do structured outputs (zobacz „Wymuszanie formatu”).

### Sprawdź się

**Pytanie:** Jak model widzi rozmowę i skąd wie, kto co mówi?

**Krótka odpowiedź:** Model nie widzi okienka czatu. Serwer skleja system prompt, historię wiadomości, wywołania narzędzi i ich wyniki w jeden dokument, a role oddziela tokenami specjalnymi według szablonu, którego model nauczył się w SFT. Na końcu stawia znacznik asystenta, a model dopisuje ciąg dalszy, aż wygeneruje token końca tury. Model nie ma pamięci, więc w każdej turze dostaje cały dokument od nowa. System prompt to tylko tekst na początku, a nie granica bezpieczeństwa: polecenie ukryte w mailu leży w tym samym ciągu.

### Pytania pogłębiające

- **Czemu model czasem pisze dalej za użytkownika?** Bo nie wygenerował tokena końca tury albo serwer nie ma go na liście tokenów stopu. Dla modelu to wciąż jeden dokument, więc najbardziej prawdopodobny ciąg dalszy to znacznik użytkownika i jego kolejna wiadomość. Zwykle winny jest zły szablon albo zła konfiguracja stopu.
- **Czy model odróżnia polecenie z system promptu od polecenia w mailu?** Tylko tyle, ile nauczył się w treningu. Modele trenuje się tak, by przestrzegały hierarchii: system ważniejszy od użytkownika, użytkownik od treści z narzędzi (OpenAI, „The Instruction Hierarchy”, 2024). To podnosi odporność, ale nie jest twardą granicą, bo wszystko leży w jednym ciągu tokenów.
- **Po co API przyjmuje listę wiadomości zamiast gotowego tekstu?** Żeby szablon, znaczniki i zapis narzędzi zawsze zgadzały się z tym, na czym trenowano model, i żeby treść od użytkownika nie mogła podrobić znacznika roli.
- **Wdrażasz model open-weight na własnym serwerze. Co sprawdzasz w szablonie?** Czy szablon z tokenizera zgadza się z kartą modelu, czy token końca tury jest na liście stopu, czy nie ma podwójnego tokena początku i czy tekst użytkownika nie zamienia się w tokeny specjalne. Najprościej wyrenderować przykładową rozmowę z narzędziami i porównać ją znak po znaku z przykładem z dokumentacji modelu.
- **Co się dzieje, gdy edytujesz starą wiadomość?** Model niczego nie zapamiętał, więc dostaje po prostu nowy dokument. Tracisz prompt cache od miejsca zmiany do końca. W Claude Opus 5.5, Fable 5.1 i Sonnet 5.5 zmiana historii przed blokiem myślenia kończy się błędem 400 (zobacz „Modele rozumujące”).

### Źródła

- [Hugging Face: Chat templates](https://huggingface.co/docs/transformers/main/en/chat_templating)
- [OpenAI: format harmony (gpt-oss)](https://developers.openai.com/cookbook/articles/openai-harmony)
- [Wallace i in.: The Instruction Hierarchy (2024)](https://arxiv.org/abs/2404.13208)
- [Claude docs: Vision (tokeny obrazu)](https://platform.claude.com/docs/en/build-with-claude/vision)
- [OpenAI: Voice agents](https://developers.openai.com/api/docs/guides/voice-agents)

---

## Modele rozumujące

*Skąd model wie to, co wie*

*Ostatnia zmiana: 28 września 2026*

Model rozumujący przed odpowiedzią pisze tok myślenia: próbuje, sprawdza, poprawia się. To ten sam mechanizm generowania token po tokenie, wyuczony w RL na zadaniach ze sprawdzalnym wynikiem, a za tokeny myślenia płacisz jak za wyjście.

**Po ludzku:** Uczeń, który na klasówce może liczyć na brudnopisie, myli się rzadziej niż ten, który od razu wpisuje wynik. Brudnopis nie pomoże mu jednak przypomnieć sobie daty, której nigdy się nie nauczył. Pisanie brudnopisu trwa, a u modelu każda jego linijka jest na rachunku.

*Interaktywny widżet na stronie: Wybierz zadanie i poziom myślenia. Zobacz, gdzie myślenie poprawia wynik, a gdzie tylko kosztuje.*

### Skąd się bierze myślenie

- Nie ma osobnego modułu myślenia. Tok myślenia to zwykłe tokeny z tej samej pętli co odpowiedź (temat „Następny token”), tylko oznaczone jako myślenie. Każdy zapisany krok zostaje w kontekście, więc kolejne tokeny liczą na nim jak na brudnopisie.
- Pisania brudnopisu model uczy się w RL (temat „Trening”) na zadaniach sprawdzanych automatycznie: matematyce ze znanym wynikiem, kodzie z testami. Nagradzany jest głównie wynik, więc utrwala się wszystko, co do niego prowadzi, także sprawdzanie się i cofanie. W DeepSeek-R1-Zero takie zachowania upowszechniły się w samym RL, bez przykładów pisanych przez ludzi, choć modele bazowe czasem przejawiają je już wcześniej (Liu i in., 2025). RLVR głównie sprawia, że model pewniej trafia w odpowiedzi, które model bazowy też potrafił znaleźć: przy wielu próbach (duże pass@k) model bazowy go dogania (Yue i in., 2025).
- To jedna z form test-time compute, czyli dokładania obliczeń w chwili odpowiedzi zamiast budowania większego modelu. Inne to wiele prób z głosowaniem albo wybór najlepszej przez weryfikator. Zysk maleje z długością myślenia, a na części zadań dłuższe myślenie pogarsza wynik (inverse scaling in test-time compute, 2025).

### Kiedy myślenie się opłaca

- Pomaga w zadaniach z wieloma krokami, w których łatwo o pomyłkę: rachunkach, kodzie, planowaniu, analizie z wieloma warunkami. Przy prostych faktach, wyszukiwaniu i krótkiej klasyfikacji dokłada tylko koszt i czekanie.
- Wiedzy nie dodaje. Czego model nie wie, tego nie wymyśli: dostaniesz dłuższe i pewniej brzmiące zgadywanie (temat „Halucynacje”).
- Każdy token myślenia to krok decode, który czeka na pamięć (temat „Czemu GPU się nudzi”). Kilka tysięcy tokenów myślenia to dziesiątki sekund przed pierwszym słowem odpowiedzi. W interfejsie pokaż postęp albo streszczenie myślenia. Zadania bez człowieka w pętli puszczaj w tle albo wsadowo.

### Sterowanie myśleniem i rachunek

- Sterujesz poziomem wysiłku (`reasoning.effort` w OpenAI, `effort` w Anthropic, `thinking_level` w Gemini, zależnie od modelu od `none` do `max`). Stały budżet tokenów myślenia (`budget_tokens`, `thinking_budget`) został tylko w starszych modelach: Claude 4.7 i nowsze odrzucają go błędem 400, a Gemini 3 przyjmuje go już tylko dla zgodności wstecz. Nawet tam jest celem, nie przydziałem. Poziom dobierasz ewaluacją na własnych zadaniach (temat „Ewaluacje”).
- W najnowszych flagowych modelach myślenia nie da się wyłączyć (stan na wrzesień 2026): Claude Opus 5.5 i Fable 5.1 odrzucają `thinking: {type: "disabled"}` błędem 400, GPT-6 Astra tak samo odrzuca `none`, a w Gemini 3.x najniższy poziom to `minimal` albo `low`. Wybierasz, ile myśleć, a nie czy. W trybie adaptacyjnym model decyduje przy każdym zapytaniu, a przy niższym wysiłku częściej pomija myślenie przy prostych pytaniach.
- Tokeny myślenia są rozliczane jak wyjście, także gdy ich nie widzisz. API zwykle nie zwracają surowego toku myślenia, tylko streszczenie albo pusty blok z zaszyfrowaną treścią, więc `usage` pokazuje więcej tokenów, niż widać w odpowiedzi.
- Myślenie liczy się do limitu wyjścia (`max_tokens`, `max_output_tokens`) i do okna kontekstu. Za niski limit ucina odpowiedź w trakcie myślenia. OpenAI zaleca na start zapas co najmniej 25 tys. tokenów na myślenie i odpowiedź.
- Sampler jest zwykle zablokowany. Claude Opus od 4.7 odrzuca każdą niestandardową wartość `temperature`, `top_p` i `top_k` błędem 400, z myśleniem czy bez, a OpenAI przy włączonym rozumowaniu nie przyjmuje `temperature` ani `top_p` (temat „Następny token”).

### Na co uważać

- Tok myślenia nie musi wiernie opisywać, jak powstała odpowiedź. W badaniu Anthropic (2025) modele korzystały z podsuniętej podpowiedzi, ale przyznawały się do niej rzadziej niż w połowie przypadków: Claude 3.7 Sonnet w 25%, DeepSeek R1 w 39%. Czytaj tok myślenia jako wskazówkę przy debugowaniu, nie jako audyt.
- W agencie model myśli też między wywołaniami narzędzi (interleaved thinking, temat „Pętla agenta”). Bloki myślenia odsyłasz w kolejnym requeście bez zmian, z podpisem albo zaszyfrowaną treścią. API odrzuci zmieniony blok, a pominięty zerwie ciągłość rozumowania.
- W Claude Opus 5.5, Fable 5.1 i Sonnet 5.5 blok jest też związany ze wszystkim, co stoi przed nim. Jeśli twój kod zmieni system prompt, narzędzia albo wcześniejszą wiadomość (np. przytnie stary wynik narzędzia), ponowne odesłanie bloku kończy się błędem 400 na kontach założonych od 31 sierpnia 2026 (na starszych tylko po włączeniu opcji). Edycja kontekstu i kompakcja po stronie serwera nie liczą się jako zmiana. Historię tylko dopisuj, a nowe instrukcje dodawaj jako nowe wiadomości.
- Myślenie z poprzednich tur jedne modele wycinają z kontekstu, inne zachowują. Zachowane zajmuje okno i jest płatne jak wejście. Wycięte zmienia prefiks od miejsca wycięcia, więc cache za nim chybia. Zmiana poziomu wysiłku albo budżetu w trakcie rozmowy też unieważnia prompt cache, bo ustawienie trafia do promptu (temat „Prompt caching”).

### Sprawdź się

**Pytanie:** Czym są modele rozumujące i ile myślenia warto opłacić?

**Krótka odpowiedź:** Model rozumujący przed odpowiedzią generuje tok myślenia: rozpisuje kroki, sprawdza je i poprawia błędy. To ten sam mechanizm przewidywania następnego tokena, wyuczony w RL na zadaniach ze sprawdzalnym wynikiem, jak matematyka czy kod z testami. Tokeny myślenia są rozliczane jak wyjście, liczą się do limitów i wydłużają czekanie. Myślenie pomaga przy zadaniach wieloetapowych, przy prostych faktach i klasyfikacji tylko kosztuje, a wiedzy nie dodaje. W najnowszych modelach myślenia nie da się wyłączyć, więc poziom wysiłku dobiera się ewaluacją. Widoczny tok myślenia nie musi wiernie wyjaśniać odpowiedzi.

### Pytania pogłębiające

- **Czym model rozumujący różni się od promptu „myśl krok po kroku”?** Prompt chain-of-thought prosi zwykły model o rozpisanie kroków i to też pomaga. Model rozumujący został do tego wytrenowany w RL: pisze dużo dłuższe toki myślenia, częściej sam się sprawdza i poprawia, a API trzyma myślenie osobno od odpowiedzi.
- **Czemu nie ustawić zawsze najwyższego poziomu?** Tokeny myślenia kosztują jak wyjście i każdy wydłuża czekanie, a zysk jakości maleje. Na prostych zadaniach jest zerowy, a bywa, że dłuższe myślenie pogarsza wynik. Poziom dobiera się per typ zadania na własnym zestawie ewaluacyjnym.
- **Czy tok myślenia wyjaśnia, dlaczego model odpowiedział tak, a nie inaczej?** Nie ma takiej gwarancji. Badania pokazują, że modele potrafią skorzystać z podpowiedzi i nie wspomnieć o niej w toku myślenia. Do tego API często zwraca tylko streszczenie. Tok myślenia przydaje się przy debugowaniu promptu, nie jako audyt.
- **Jak działa myślenie w agencie z narzędziami?** Model myśli także między wywołaniami narzędzi, po każdym wyniku. Bloki myślenia odsyła się w kolejnym requeście bez zmian, z podpisem albo zaszyfrowaną treścią, żeby rozumowanie miało ciągłość, a cache trafiał. W Claude Opus 5.5, Fable 5.1 i Sonnet 5.5 zmiana czegokolwiek przed blokiem kończy się błędem, więc historię agenta tylko się dopisuje.

### Źródła

- [DeepSeek-R1: Incentivizing Reasoning Capability in LLMs via Reinforcement Learning](https://arxiv.org/abs/2501.12948)
- [OpenAI: Reasoning models (dokumentacja API)](https://developers.openai.com/api/docs/guides/reasoning)
- [Claude docs: Preserved thinking](https://platform.claude.com/docs/en/build-with-claude/preserved-thinking)
- [Anthropic: Reasoning models don’t always say what they think](https://www.anthropic.com/research/reasoning-models-dont-say-think)
- [Lilian Weng: Why We Think (Lil’Log, 2025)](https://lilianweng.github.io/posts/2025-05-01-thinking/)

---

## Pętla generowania i KV cache

*Jak model pisze i ile to kosztuje*

*Ostatnia zmiana: 28 września 2026*

Generowanie to pętla: jeden przebieg modelu daje jeden token, który trafia na koniec wejścia. KV cache trzyma klucze i wartości attention wszystkich wcześniejszych tokenów, więc każdy krok liczy tylko nowy token, a ceną jest pamięć GPU, która ogranicza długość kontekstu i liczbę równoległych rozmów.

**Po ludzku:** Piszesz list i przy każdym nowym słowie zerkasz do notatek z tego, co już napisałeś. Nie czytasz listu od nowa, ale notatki przeglądasz za każdym razem. KV cache to te notatki. Leżą na biurku, czyli w pamięci karty graficznej, i im dłuższy list, tym więcej miejsca zajmują.

*Interaktywny widżet na stronie: Przejdź krok po kroku z cache’em i bez. Porównaj, ile tokenów liczy każdy krok.*

### Co jest w KV cache’u i czemu to działa

- W każdej warstwie attention token ma trzy rzuty swojego stanu: zapytanie Q, klucz K i wartość V (temat „Attention”). Nowy token porównuje swoje Q z kluczami wszystkich wcześniejszych i bierze ważoną sumę ich wartości. KV cache to K i V wszystkich dotychczasowych tokenów, osobno dla każdej warstwy i głowy KV.
- Q nie trafia do cache’u. Zapytanie tokena jest potrzebne tylko w kroku, w którym ten token jest ostatni. Późniejsze tokeny czytają już tylko jego K i V.
- Cache można trzymać dzięki masce przyczynowej: K i V tokena *i* zależą tylko od tokenów 0…*i*, więc nowe tokeny ich nie zmieniają. To memoizacja. Bez niej krok *n* liczyłby od nowa wszystkie *n* tokenów, więc wygenerowanie *N* tokenów kosztowałoby pracę projekcji i MLP rosnącą z *N*² zamiast z *N* (a koszt attention z *N*³ zamiast z *N*²).
- Działa to też w drugą stronę: K i V tokena zależą od wszystkich tokenów przed nim i od jego pozycji (RoPE). Zmiana jednego tokena unieważnia cache wszystkiego za nim. Dlatego dostawca może ponownie użyć cache’u tylko dla identycznego prefiksu, a agent historię tylko dopisuje (temat „Prompt caching”).

### Ile pamięci zajmuje KV cache

- Na token: 2 (K i V) × warstwy × głowy KV × wymiar głowy × bajty. Llama 3.1 70B w FP16: 2 × 80 × 8 × 128 × 2 B = 327 680 B, ok. 0,33 MB. Pełne 128 tys. tokenów to 43 GB na jedną rozmowę, przy 141 GB samych wag.
- Kształt cache’u ustala architektura. GQA daje jedną parę K, V na grupę głów zapytań (MQA to skrajność: jedna para na warstwę). Llama 3 70B ma 8 głów KV na 64 głowy Q. Bez GQA cache 128 tys. tokenów zająłby 344 GB. MLA z DeepSeek zapisuje jeden skompresowany wektor na warstwę: w DeepSeek-V3 to 61 × 576 × 2 B ≈ 70 KB na token, prawie 5 razy mniej niż Llama 70B, choć model ma 671 mld parametrów.
- Okno przesuwne: część warstw widzi tylko ostatnie W tokenów, więc ich cache nie rośnie ponad W. Gemma 3 ma pięć takich warstw (W = 1024) na jedną pełną, co przy 128 tys. tokenów daje ok. 17% cache’u tego samego modelu z samymi pełnymi warstwami. Modele hybrydowe zastępują część warstw attention warstwami SSM o stałym rozmiarze stanu.
- Przy serwowaniu gotowego modelu da się jeszcze zmienić precyzję: cache w FP8 zajmuje połowę pamięci. To przybliżenie, więc sprawdź jakość na własnych ewaluacjach.

*Interaktywny widżet na stronie: Wybierz model, kontekst i liczbę rozmów. Zobacz, ile kart H100 zajmuje sam cache.*

### Prefill i decode

- Prefill przetwarza cały prompt w jednym przebiegu. Mnoży wagi przez macierz wszystkich tokenów naraz, więc każdy przeczytany bajt wag służy setkom tokenów i karta liczy pełną mocą. Tu powstaje cache promptu. Prefill wyznacza czas do pierwszego tokena (TTFT), a attention rośnie z kwadratem długości, więc bardzo długi prompt wydłuża TTFT szybciej niż liniowo.
- Decode daje jeden token na rozmowę na krok i mnoży te same wagi przez jeden wektor. W FP16 to ok. 1 operacja na bajt wag na każdą rozmowę w batchu, a H100 potrzebuje ok. 300, żeby wąskim gardłem stało się liczenie (temat „Czemu GPU się nudzi”). Czas kroku ≈ (wagi + cache wszystkich rozmów w batchu) / przepustowość pamięci.
- Wagi czyta się raz na cały batch, cache każdej rozmowy osobno. Dlatego serwery sklejają wiele rozmów w jeden krok (temat „Continuous batching”), długi kontekst jednej rozmowy spowalnia cały batch, a token wyjściowy kosztuje u dostawców kilka razy więcej niż wejściowy.

*Interaktywny widżet na stronie: Zwiększ kontekst i liczbę rozmów w batchu. Zobacz, kiedy czytanie cache’u zaczyna dominować nad czytaniem wag.*

### Cache na serwerze

- PagedAttention (vLLM) dzieli cache na bloki po kilkanaście tokenów, jak strony pamięci wirtualnej. Serwer nie rezerwuje miejsca na maksymalną długość, a wspólny prefiks wielu rozmów trzyma raz. Prompt caching to te same bloki zachowane po requeście i odszukane po hashu prefiksu.
- Gdy pamięci brakuje, serwer wstrzymuje część rozmów i albo zwalnia ich cache i później liczy go od nowa, albo zrzuca go do RAM-u lub na dysk i wczytuje z powrotem. Oba sposoby kosztują czas, ale nie zmieniają wyniku.
- Wyrzucanie części tokenów z cache’u (StreamingLLM, H2O: zostają pierwsze, ostatnie i te, które dostają najwięcej attention) oszczędza pamięć, ale jest przybliżeniem. Model traci dostęp do wyrzuconego tekstu, więc jakość na długich zadaniach spada.

### Sprawdź się

**Pytanie:** Czym jest KV cache i czym różni się prefill od decode?

**Krótka odpowiedź:** Generowanie to pętla: jeden przebieg modelu daje jeden token. Attention potrzebuje kluczy i wartości wszystkich wcześniejszych tokenów, a dzięki masce przyczynowej one się nie zmieniają, więc liczy się je raz i trzyma w pamięci GPU. Prefill liczy cały prompt równolegle, jest ograniczony obliczeniami i wyznacza czas do pierwszego tokena. Decode idzie token po tokenie i czeka na pamięć, bo każdy krok czyta wagi i cały cache. Cache to ok. 0,33 MB na token dla 70B z GQA, więc to on ogranicza kontekst i batch. Zmniejszają go GQA, MLA, okno przesuwne i FP8.

### Pytania pogłębiające

- **Od czego zależy czas do pierwszego tokena, a od czego prędkość pisania?** Czas do pierwszego tokena zależy od kolejki i od tego, ile promptu trzeba policzyć poza trafionym cache’em, bo to prefill. Prędkość pisania zależy od rozmiaru wag, długości kontekstu, liczby rozmów w batchu i przepustowości pamięci, bo to decode.
- **Czemu długi kontekst spowalnia pisanie, skoro każdy krok liczy jeden token?** Bo każdy krok czyta cały cache. Dla modelu 70B przy 128 tys. tokenów to 43 GB na krok, prawie jedna trzecia tego, co ważą wagi, a decode jest ograniczony przepustowością pamięci.
- **vLLM pada z braku pamięci przy długich kontekstach. Co robisz?** Policz budżet: wagi plus cache na token × maksymalny kontekst × liczba równoległych sekwencji. Potem ogranicz maksymalną długość i liczbę sekwencji, włącz cache w FP8 i współdzielenie prefiksów, a gdy to za mało, podziel model na więcej kart. Tensor parallelism dzieli cache GQA po głowach KV, więc najwyżej na tyle kart, ile jest głów KV (8 w Llama 3.1 70B). Cache MLA jest powielany na każdej karcie, dlatego modele w stylu DeepSeek używają zamiast tego data-parallel attention.
- **Jak zmniejszyć KV cache?** Przy projektowaniu modelu: GQA lub MQA, MLA, okno przesuwne, warstwy SSM. Przy serwowaniu: FP8, współdzielenie prefiksów, zrzut do RAM-u, wyrzucanie tokenów. Wyniku nie zmieniają tylko współdzielenie i zrzut.

### Źródła

- [kipply: Transformer Inference Arithmetic](https://kipp.ly/p/transformer-inference-arithmetic)
- [How To Scale Your Model: rozdział o inferencji](https://jax-ml.github.io/scaling-book/inference/)
- [DeepSeek-V2: skąd się wzięło MLA (arXiv)](https://arxiv.org/abs/2405.04434)
- [Efficient Memory Management for LLM Serving with PagedAttention (arXiv)](https://arxiv.org/abs/2309.06180)
- [Sebastian Raschka: Understanding and Coding the KV Cache in LLMs from Scratch (2025)](https://magazine.sebastianraschka.com/p/coding-the-kv-cache-in-llms)

---

## Prompt caching

*Jak model pisze i ile to kosztuje*

*Ostatnia zmiana: 28 września 2026*

Prompt caching to KV cache zachowany u dostawcy między requestami. Request, który zaczyna się identycznie jak niedawny, pomija prefill tej części: płaci ułamek ceny wejścia i szybciej dostaje pierwszy token.

**Po ludzku:** Kelner, który zna stałych gości, nie pyta od nowa o alergie i ulubiony stolik. Ale wystarczy przedstawić się innym imieniem i zaczyna od zera. I pamięta gościa tylko kilka minut od ostatniej wizyty.

*Interaktywny widżet na stronie: Wybierz układ promptu. Zobacz, jaka część drugiego requestu trafia w cache i ile to kosztuje.*

### Jak działa prompt caching

- Po requeście dostawca zachowuje KV cache promptu w blokach i indeksuje je hashem prefiksu, czyli wszystkiego od początku promptu do końca bloku (temat „Pętla generowania i KV cache”). Request z tym samym początkiem wczytuje te bloki zamiast liczyć je od nowa.
- Trafia tylko identyczny prefiks. K i V każdego tokena zależą od wszystkich tokenów przed nim, a dzięki masce przyczynowej od niczego za nim. Dopisany koniec zostawia więc cache ważny, a pierwszy zmieniony token unieważnia wszystko za nim, nawet gdy dalsza część jest identyczna.
- Zysk jest podwójny: tańsze wejście i krótszy czas do pierwszego tokena, bo prefill pomija trafioną część. Generowania odpowiedzi to nie przyspiesza. Model widzi dokładnie ten sam tekst, więc cache nie zmienia jakości.

### Warunki u dostawców

- Anthropic (wrzesień 2026): odczyt 0,1 ceny wejścia (w najnowszych modelach jeszcze mniej), zapis 1,25 przy wpisie 5-minutowym i 2 przy godzinnym. Punkty cięcia (breakpointy) wskazujesz sam (do 4 znaczników `cache_control`) albo jednym polem w trybie automatycznym. Minimalny prefiks to od 512 do 4096 tokenów zależnie od modelu. Krótszy po cichu się nie zapisze.
- OpenAI cache’uje prefiksy automatycznie. Od GPT-5.6 minimum to 1024 tokeny, zapis kosztuje 1,25, odczyt 0,1, a wpis żyje co najmniej 30 minut. Starsze modele nie mają dopłaty za zapis i domyślnie trzymają wpis ok. 30 minut, najwyżej 24 godziny; przy Zero Data Retention albo w modelach bez retencji 24-godzinnej domyślnie 5–10 minut bezczynności, najwyżej godzinę. Gemini od 2.5 ma cache automatyczny, bez gwarancji trafienia, i jawny, płatny za godzinę przechowywania.
- Każde trafienie odnawia czas życia wpisu. U Anthropic liczy się on od startu requestu, więc generowanie trwające 4 minuty zjada większość 5-minutowego wpisu. Użytkownik, który przy takim wpisie odpisze po kwadransie, zaczyna od zapisu.

### Jak układać prompt pod cache

- Najpierw to, co stałe: definicje narzędzi, system prompt, duże dokumenty, przykłady. Potem historia, na końcu nowa wiadomość. U Anthropic hierarchia to `tools` → `system` → `messages`, więc zmiana narzędzi unieważnia wszystko.
- Historię tylko dopisuj. Agent w każdej turze wysyła ją całą (temat „Okno kontekstowe i agent”), a tylko dopisywana historia pozwala każdej turze przeczytać z cache’u wszystko poza najnowszą częścią. Edycja starej wiadomości, kompakcja, wycięcie starego wyniku narzędzia albo przestawienie narzędzi unieważnia cache od tego miejsca. Oszczędzanie okna (temat „Context engineering i pamięć”) trzeba więc zestawić z kosztem chybienia.
- Typowi zabójcy prefiksu: data i godzina albo identyfikator sesji na początku, niedeterministyczna kolejność kluczy JSON albo narzędzi, zmiana modelu, poziomu myślenia albo schematu odpowiedzi w trakcie rozmowy.
- Mierz trafienia w `usage`: `cache_read_input_tokens` w Anthropic, `cached_tokens` w OpenAI. Hit rate to tokeny z cache’u przez wszystkie tokeny wejściowe. W Anthropic `input_tokens` liczy tylko to, co stoi za ostatnim breakpointem, więc całe wejście to `input_tokens` + `cache_creation_input_tokens` + `cache_read_input_tokens`; w OpenAI `input_tokens` już zawiera `cached_tokens`. Zero trafień przy powtarzalnym prefiksie znaczy, że coś go zmienia.
- Opłacalność: przy zapisie 1,25 i odczycie 0,1 wpis zwraca się już przy jednym trafieniu (1,35 zamiast 2 cen wejścia). Godzinny wpis za 2 potrzebuje dwóch trafień. Prefiks, który się nie powtarza, tylko dopłaca za zapis.

### Sprawdź się

**Pytanie:** Jak działa prompt caching i jak układać pod niego prompt?

**Krótka odpowiedź:** To KV cache zachowany u dostawcy między requestami. Działa tylko przy identycznym prefiksie, bo K i V tokena zależą od wszystkiego przed nim: pierwszy zmieniony token unieważnia resztę. Dlatego stałe części, czyli narzędzia, system prompt i duże dokumenty, idą na początek, historię się tylko dopisuje, a zmienne dane trafiają na koniec. Odczyt kosztuje zwykle 10% ceny wejścia, zapis bywa droższy od zwykłego wejścia, a wpis żyje minuty. Zysk to tańsze wejście i krótszy czas do pierwszego tokena. Hit rate odczytuje się z pól usage.

### Pytania pogłębiające

- **Rachunek za agenta jest wysoki, a hit rate niski. Co sprawdzasz?** Porównaj kolejne requesty token po tokenie i szukaj pierwszej różnicy: data lub identyfikator na początku, niedeterministyczna serializacja narzędzi i JSON-a, edycja historii, zmiana modelu albo poziomu myślenia. Potem sprawdź, czy przerwy między turami nie są dłuższe niż czas życia wpisu i czy prefiks przekracza minimalną długość.
- **Czym prompt caching różni się od cache’u semantycznego?** Prompt caching przechowuje obliczenia dla identycznego prefiksu, a model i tak generuje nową odpowiedź, więc jakość się nie zmienia. Cache semantyczny zwraca starą odpowiedź na podobne pytanie: oszczędza całe wywołanie, ale może zwrócić odpowiedź na inne pytanie.
- **Kiedy caching się nie opłaca?** Gdy prefiks rzadko się powtarza w czasie życia wpisu. Przy dopłacie za zapis każdy wpis bez trafienia kosztuje więcej niż request bez cache’u.
- **Czy cache może zdradzić dane innego użytkownika?** Duzi dostawcy nie dzielą cache’u między organizacjami, ale w twojej aplikacji użytkownicy z tym samym prefiksem trafiają w ten sam wpis. Trafienie widać po krótszym czasie odpowiedzi, więc ktoś może sprawdzić, czy inny użytkownik niedawno wysłał dany tekst. Audyt z 2025 roku wykrył cache współdzielony globalnie, między organizacjami, u 7 z 17 dostawców API, a co najmniej pięciu zmieniło to dopiero po zgłoszeniu. Rozdziel cache per klient (w Anthropic osobny workspace, w OpenAI od GPT-5.6 osobny prompt_cache_key; w starszych modelach klucz wpływa tylko na routing) albo trzymaj wrażliwe dane poza wspólnym prefiksem.

### Źródła

- [Dokumentacja Claude: prompt caching](https://platform.claude.com/docs/en/build-with-claude/prompt-caching)
- [Dokumentacja OpenAI: prompt caching](https://developers.openai.com/api/docs/guides/prompt-caching)
- [Manus: Context Engineering for AI Agents](https://manus.im/blog/Context-Engineering-for-AI-Agents-Lessons-from-Building-Manus)
- [Auditing Prompt Caching in Language Model APIs (arXiv)](https://arxiv.org/abs/2502.07776)

---

## Okno kontekstowe i agent

*Jak model pisze i ile to kosztuje*

*Ostatnia zmiana: 28 września 2026*

Model niczego nie pamięta między requestami, wie tylko to, co dostał w bieżącym. Context window to wspólny limit tokenów wejścia i wyjścia jednego requestu. Agent w każdej turze wysyła całą rosnącą historię, więc płaci za nią wielokrotnie, a jakość odpowiedzi spada wraz z jej długością.

**Po ludzku:** Model to konsultant z amnezją. Przed każdą rozmową dostaje teczkę i wie tylko to, co w niej jest. Teczka ma ograniczoną grubość, a agent przy każdym kroku dokłada do niej kartki.

*Interaktywny widżet na stronie: Przesuń suwak tur agenta. Zobacz, co zapełnia okno i jak szybko rośnie łączny koszt wejścia.*

### Co liczy się do limitu

- Wszystko w requeście: system prompt, definicje narzędzi (także z serwerów MCP), cała historia z wynikami narzędzi, obrazy i PDF-y, a do tego wszystko, co model wygeneruje w tej turze, łącznie z myśleniem. Liczy się w tokenach tokenizera danego modelu, więc ten sam tekst u różnych dostawców daje różne liczby (temat „Tokeny”). Przed wysłaniem policzysz je endpointem do liczenia tokenów.
- Część narzutu jest stała i płacona w każdej turze: definicje kilkudziesięciu narzędzi to łatwo kilkadziesiąt tysięcy tokenów, zanim agent cokolwiek zrobi (temat „Narzędzia (function calling)”).

### Limit wejścia i limit wyjścia

- Okno obejmuje wejście i wyjście razem. Osobno działa limit wyjścia jednego requestu (`max_tokens`), dużo mniejszy: we wrześniu 2026 modele Claude z oknem 1 mln tokenów generują najwyżej 128 tys. na request, a modele GPT-6 w OpenAI mają okno 1,05 mln, z czego najwyżej 922 tys. na wejście, i 128 tys. wyjścia.
- API zwykle odrzuca za długie wejście, zwracając błąd. Ucięcie historii od najstarszych wiadomości to decyzja twojej aplikacji albo frameworka, często podejmowana po cichu.
- Gdy wyjście dojdzie do limitu, generacja staje w pół zdania: `stop_reason: "max_tokens"` w Anthropic (w Claude 4.5+ także `"model_context_window_exceeded"`, gdy wejście z wyjściem zapełnią okno), `finish_reason: "length"` w Chat Completions. JSON jest wtedy niepełny, a model rozumujący może nie dojść do odpowiedzi. Sprawdzaj powód zatrzymania w kodzie.
- Długi kontekst bywa droższy za token: Gemini 3.1 Pro powyżej 200 tys. tokenów wejścia i modele GPT-6 powyżej 272 tys. liczą cały request 2 razy drożej za wejście i cache oraz 1,5 razy drożej za wyjście. Modele Claude z oknem 1 mln mają stałą stawkę (wrzesień 2026).

### Koszt rośnie z każdą turą

- W pętli agenta (temat „Pętla agenta”) tura *t* wysyła wszystko z wcześniejszych tur plus nowy wynik. Przy stałym przyroście na turę łączna liczba tokenów wejściowych rośnie z kwadratem liczby tur. W widżecie 24 tury to już ok. 2,2 mln tokenów wejściowych, choć każdy request mieści się w oknie 200 tys.
- W agentach wejście dominuje: Manus podaje średni stosunek tokenów wejściowych do wyjściowych ok. 100:1. Rachunek obniża więc przede wszystkim prompt caching. Dzięki masce przyczynowej K i V starych tokenów się nie zmieniają, więc dopóki historię się tylko dopisuje, każda tura czyta z cache’u wszystko poza najnowszą częścią (temat „Prompt caching”). Odczyt kosztuje ok. 10% ceny, ale krzywa zostaje kwadratowa.
- Rośnie też opóźnienie. Prefill części spoza cache’u wydłuża czas do pierwszego tokena, a każdy krok decode czyta cały KV cache, więc długi kontekst spowalnia także pisanie (temat „Pętla generowania i KV cache”).
- Gdy narzędzie pracuje, model nic nie liczy, a KV cache rozmowy dalej zajmuje pamięć GPU. Obciążony serwer może zrzucić cache do RAM-u albo na SSD i wczytać go z powrotem, gdy przyjdzie wynik: szybciej, niż liczyłby długą historię od nowa, ale nie bez kosztu dla czasu do pierwszego tokena (Glenn Lockwood, wrzesień 2026). Przez API widać tylko czas życia wpisu w cache’u, a u Anthropic liczy się on od startu requestu: generacja i wolne testy mogą trwać dłużej, niż żyje 5-minutowy wpis, a następna tura zapłaci za zapis i pełny prefill całej historii. Przy narzędziach działających minutami opłaca się wpis godzinny.

### Context rot: jakość spada z długością kontekstu

- Modele działają gorzej na długim wejściu, zanim okno się skończy. Test needle-in-a-haystack, czyli znalezienie jednego zdania pasującego dosłownie do pytania, wychodzi prawie idealnie i niewiele mówi. W RULER (2024) z 17 modeli deklarujących co najmniej 32 tys. tokenów tylko połowa trzymała zadowalający wynik przy 32 tys.
- Spadek jest większy, gdy pytanie i odpowiedź nie mają wspólnych słów: w NoLiMa (2025) 11 z 13 modeli przy 32 tys. tokenów spadło poniżej połowy swojego wyniku z krótkiego kontekstu. Chroma (2025, 18 modeli) pokazała spadek wynikający z samej długości, nawet w prostych zadaniach, silniejszy przy podobnych, ale nieistotnych fragmentach.
- Położenie też ma znaczenie. W badaniu Lost in the Middle (2023) modele najlepiej korzystały z informacji na początku i na końcu kontekstu, a wyraźnie gorzej ze środka. Ważną instrukcję i pytanie stawia się więc na końcu, za długim materiałem.
- Pojemność okna to nie budżet do wypełnienia. Testuj swój przypadek na długościach, które naprawdę wysyłasz, a kontekst utrzymuj krótki i trafny. Jak to robić (przycinanie wyników narzędzi, kompakcja, subagenci, pamięć poza oknem), opisuje temat „Context engineering i pamięć”.

### Sprawdź się

**Pytanie:** Co liczy się do context window i czemu długa sesja agenta jest droga i coraz słabsza?

**Krótka odpowiedź:** Model jest bezstanowy i widzi tylko bieżący request. Okno to limit tokenów na request, wspólny dla system promptu, definicji narzędzi, historii z wynikami narzędzi i tego, co model wygeneruje, łącznie z myśleniem. Limit samego wyjścia jest osobny i dużo mniejszy. Agent w każdej turze wysyła całą historię, więc łączna liczba tokenów wejściowych rośnie z kwadratem liczby tur. Prompt caching obniża cenę, ale nie kształt krzywej. Jakość spada z długością na długo przed końcem okna, więc kontekst warto trzymać krótki i testować na realnych długościach.

### Pytania pogłębiające

- **Co to context rot?** Spadek jakości z długością wejścia, zanim okno się skończy. Jest silniejszy, gdy w kontekście leżą podobne, ale nieistotne fragmenty, i gdy odpowiedź nie powtarza słów z pytania, więc test needle-in-a-haystack go nie pokazuje.
- **Model ma okno 1 mln tokenów. Czemu nie wrzucić całej bazy wiedzy do promptu?** Bo każdy request płaci za cały milion, u części dostawców drożej powyżej progu, czas do pierwszego tokena rośnie, a jakość spada z długością. Przy małym, stałym zbiorze z prompt cachingiem to rozsądne, przy dużym albo zmiennym wygrywa wyszukiwanie (temat „RAG”).
- **Agent przepełnia okno po 40 turach. Co robisz?** Najpierw zmierz, co zajmuje okno, zwykle stare wyniki narzędzi i definicje narzędzi. Potem przytnij wyniki u źródła, wyczyść stare, przenieś poboczne zadania do subagentów, a dopiero na końcu skompaktuj historię (temat „Context engineering i pamięć”).
- **Czy API trzymające historię po stronie serwera obniża koszt?** Nie. Funkcje takie jak previous_response_id w Responses API OpenAI oszczędzają ci przesyłania, ale cała historia i tak trafia do modelu i jest liczona jako wejście. Koszt obniża dopiero prompt caching albo krótszy kontekst.

### Źródła

- [Dokumentacja Claude: context windows](https://platform.claude.com/docs/en/build-with-claude/context-windows)
- [RULER: What’s the Real Context Size of Your Long-Context Language Models? (arXiv)](https://arxiv.org/abs/2404.06654)
- [NoLiMa: Long-Context Evaluation Beyond Literal Matching (arXiv)](https://arxiv.org/abs/2502.05167)
- [Lost in the Middle: How Language Models Use Long Contexts (arXiv)](https://arxiv.org/abs/2307.03172)
- [Glenn Lockwood: What are KV caches really? (wrzesień 2026)](https://blog.glennklockwood.com/2026/09/what-are-kv-caches-really.html)

---

## Context engineering i pamięć

*Kontekst i wiedza*

*Ostatnia zmiana: 28 września 2026*

Model wie tylko to, co jest w kontekście bieżącego wywołania. Context engineering to wybór, co tam włożyć: najmniej tokenów, które wystarczą do następnego kroku, a z pamięci poza oknem tylko to, co potrzebne teraz.

**Po ludzku:** Przekazanie dyżuru w szpitalu. Nocna zmiana nie opowiada całej nocy minuta po minucie, tylko zostawia kartę: uczulenia, podane leki, co się zmieniło, co zostało do zrobienia. Czego nie ma w karcie, tego dzienna zmiana nie wie.

*Interaktywny widżet na stronie: Agent od 40 tur dodaje obsługę zwrotów do modułu płatności. Wybierz, jak zarządza kontekstem, i zobacz, które z sześciu faktów dotrwają do pytania w turze 41 i czy agent odpowie dobrze.*

### Co walczy o miejsce w oknie

- Do jednego wywołania trafiają: system prompt, definicje narzędzi, przykłady, pobrane dokumenty, historia rozmowy, wyniki narzędzi i rozumowanie modelu (thinking). W agencie najszybciej rosną wyniki narzędzi. Manus podaje średnio ok. 100 tokenów wejścia na 1 token wyjścia. Limit okna i to, jak koszt rośnie z każdą turą, opisuje temat „Okno kontekstowe i agent”.
- Jakość spada, zanim okno się skończy. To context rot. Chroma (lipiec 2025) sprawdziła 18 modeli: wyniki pogarszały się z długością wejścia nawet w prostych zadaniach, a dodatkowo szkodziły fragmenty na ten sam temat, które nie odpowiadają na pytanie. W teście LongMemEval każdy model wypadł wyraźnie lepiej na wersji z samymi potrzebnymi fragmentami (ok. 300 tokenów) niż na pełnej (ok. 113 tys.), choć odpowiedź była w obu. Anthropic tłumaczy to budżetem uwagi: n tokenów to n² par, więc uwaga rozkłada się na coraz więcej kandydatów (temat „Attention”). Najmniej tokenów nie znaczy krótko: brak potrzebnego faktu szkodzi tak samo jak szum.

### Jak pisać prompty: minimum, które działa

- Zadanie, powód, ograniczenia i format wyniku. Powód działa lepiej niż zakaz. Zamiast „NIGDY nie używaj wielokropka” napisz, że tekst przeczyta syntezator mowy, który wielokropka nie wymówi. Znając powód, model wywnioskuje też przypadki, których nie wypisałeś. Pisz, co robić, a nie czego nie robić. Test z dokumentacji Claude: czy kolega bez kontekstu wykonałby to polecenie?
- Przykłady sterują formatem i tonem skuteczniej niż opis. Dokumentacja Claude zaleca 3–5 różnych przykładów w tagach `<example>`. Anthropic radzi dobrać kilka typowych zamiast listy wszystkich przypadków brzegowych. Zbyt podobne przykłady model kopiuje razem z przypadkowymi cechami, na przykład zawsze tą samą długością.
- Strukturę dają sekcje albo tagi XML: osobno instrukcje, kontekst, przykłady i dane wejściowe, żeby model nie mylił poleceń z danymi. Długie dokumenty idą na górę, pytanie na koniec. W testach Anthropic dawało to do 30% lepsze odpowiedzi przy wielu dokumentach.

### Techniki dla długich zadań

- Stały prefiks na początek: system prompt, definicje narzędzi, stałe dokumenty. Zmienne części na koniec, historię tylko dopisuj, serializuj deterministycznie (ta sama kolejność kluczy w JSON-ie). Wtedy kolejne wywołania trafiają w cache, zobacz temat „Prompt caching”. Każda zmiana w środku kontekstu, czyli kompakcja, czyszczenie albo nowe narzędzie, unieważnia cache od miejsca zmiany. Dlatego edytuj rzadko i dużymi porcjami. Manus z tego powodu nie usuwa narzędzi w trakcie zadania, tylko blokuje ich wybór przy dekodowaniu.
- Pobieranie na żądanie zamiast ładowania z góry. Agent trzyma lekkie wskaźniki, czyli ścieżki plików, URL-e i zapytania, a treść czyta narzędziami, gdy jej potrzebuje: `grep`, `head`, zapytanie do bazy. Claude Code łączy oba podejścia: `CLAUDE.md` trafia do kontekstu na starcie, pliki agent czyta na bieżąco. Tak samo działają Agent Skills, tylko z instrukcjami: w prefiksie leży sama nazwa i opis każdej umiejętności, ok. 100 tokenów, a pełne instrukcje wczytują się, gdy zadanie pasuje do opisu. To ta sama odpowiedź co wyszukiwanie narzędzi przy rozdętych definicjach (temat „MCP”), szerzej w temacie „Harness agenta kodującego”. Cena: więcej tur i wolniej niż gotowe wyniki z indeksu (temat „RAG”). Reguły, które obowiązują zawsze, ładuj z góry. Wyszukiwanie znajduje to, co przypomina pytanie, a „bez zgody nic na produkcji” nie przypomina żadnego.
- Kompakcja: przy progu model streszcza historię, a praca toczy się dalej od streszczenia i ostatnich tur. Claude Code zachowuje decyzje architektoniczne, nierozwiązane błędy i szczegóły implementacji, wyrzuca powtarzające się wyniki narzędzi i dokłada 5 ostatnio czytanych plików. Streszczenie gubi szczegóły, które w chwili streszczania wyglądały na nieważne, a samo kosztuje wywołanie czytające całą historię. Stan na wrzesień 2026: API Claude (beta) i Responses API OpenAI potrafią kompaktować po stronie serwera, przy progu tokenów albo na żądanie. Claude zwraca czytelne streszczenie i pozwala podać własny prompt streszczający, a element kompakcji OpenAI jest zaszyfrowany, więc to, co zgubił, pokaże tylko ewaluacja.
- Czyszczenie starych wyników narzędzi to najłagodniejsza forma odchudzania kontekstu. Surowy wynik sprzed 30 tur rzadko jest potrzebny dosłownie. Zastępujesz go znacznikiem, a samo wywołanie zostaje, więc agent wie, co już sprawdził, i może pobrać to jeszcze raz. W API Claude robi to context editing: po przekroczeniu progu (domyślnie 100 tys. tokenów wejścia) czyści starsze wyniki i zostawia 3 ostatnie. W Claude Fable 5.1, Opus 5.5 i Sonnet 5.5, jeśli odsyłasz bloki myślenia, czyszczenie zostaw API. Zmiana wcześniejszego wyniku narzędzia we własnym kodzie albo kompakcja z własnym streszczeniem, która zostawia ostatnie tury razem z ich myśleniem, sprawia, że każdy późniejszy blok myślenia nie przejdzie kontroli prefiksu: dla kont założonych od 31 sierpnia 2026 to domyślnie błąd 400. Jedno streszczenie zastępujące całą historię jest w porządku.
- Notatki poza oknem: agent sam prowadzi plik, na przykład `NOTES.md`, listę zadań albo `progress.txt`, i czyta go po resecie kontekstu. Manus przy średnio ok. 50 wywołaniach narzędzi na zadanie co chwilę przepisuje `todo.md`, żeby cel stał na końcu kontekstu, a nie ginął w środku. Przy pracy z kodem dokumentacja Claude radzi czasem zacząć od czystego okna zamiast kompakcji: model odtwarza stan z notatek, testów i historii gita. Notatki zawierają tylko to, co agent uznał za ważne, i też się starzeją.
- Subagent dostaje czyste okno na zadanie poboczne, na przykład przeszukanie repozytorium. Zużywa dziesiątki tysięcy tokenów, a oddaje streszczenie, według Anthropic zwykle 1–2 tys. tokenów. Główny kontekst zostaje krótki, ale subagent nie widzi ustaleń głównego wątku, więc zlecenie musi je zawierać. Więcej w temacie „Wielu agentów”.

### Pamięć między sesjami

- Pamięć długoterminowa to zapis poza modelem, który wraca do kontekstu w kolejnych sesjach. Zapisuje się fakty i preferencje (pracuje w TypeScripcie, woli krótkie odpowiedzi), epizody (jak rozwiązano podobne zgłoszenie, co nie zadziałało) i reguły (poprawione instrukcje). Do wyboru są dwie formy: jeden profil nadpisywany w całości (prosty, ale przy aktualizacji łatwo coś w nim zgubić) albo kolekcja małych wpisów (mniej strat, ale trudniejsze wyszukiwanie, poprawianie i kasowanie).
- Do kontekstu pamięć wraca na dwa sposoby. Mały profil jest zawsze w prefiksie: to proste, ale płacisz za niego w każdym wywołaniu. Większy zbiór agent przeszukuje narzędziem, gdy go potrzebuje: to się skaluje, ale może nie trafić. Memory tool w API Claude działa po stronie klienta. Model prosi o operacje na plikach w katalogu `/memories`, twój kod wykonuje je na twoim magazynie, a API dopisuje polecenie, żeby przed pracą zawsze przejrzeć ten katalog. Zapis w trakcie pracy jest od razu widoczny, ale spowalnia. Zapis w tle po sesji nie spowalnia, ale działa z opóźnieniem.
- Pamięć się starzeje. Wpis „projekt używa MySQL” po migracji na Postgresa szkodzi bardziej niż brak wpisu, bo model ufa swoim notatkom. Trzymaj przy wpisie datę i źródło, niech nowszy wygrywa, a nieużywane wpisy wygasają. Dokumentacja memory tool zaleca też limit rozmiaru plików, usuwanie danych wrażliwych przed zapisem i ochronę przed ścieżkami typu `/memories/../../`.
- Memory poisoning: obca treść, czyli strona, dokument albo mail, każe modelowi zapisać fałszywy wpis, który potem działa w każdej sesji. Johann Rehberger pokazał w 2024 roku zapis fałszywych wspomnień w ChatGPT przez dokumenty, obrazy i przeglądane strony, a potem wpis, który wysyłał atakującemu wszystkie przyszłe rozmowy. OpenAI według autora zablokowało we wrześniu 2024 ten kanał wycieku, ale nie samo zapisywanie. Zapis do pamięci traktuj jak akcję z uprawnieniami: tylko z wypowiedzi użytkownika albo za jego zgodą, z widocznym komunikatem. Zobacz „Prompt injection”.
- Użytkownik musi móc widzieć, poprawiać i kasować pamięć oraz rozmawiać bez niej. Pamięć jednego użytkownika nigdy nie może trafić do kontekstu innego: osobna przestrzeń na użytkownika i projekt, a przy usunięciu konta usuwasz też pamięć.

### Sprawdź się

**Pytanie:** Agent po godzinie pracy zapomina ustalenia z początku sesji i robi się coraz droższy. Jak zaprojektujesz zarządzanie kontekstem i pamięcią?

**Krótka odpowiedź:** Model wie tylko to, co jest w bieżącym kontekście, więc przed każdym wywołaniem składaj najmniejszy zestaw tokenów potrzebny do następnego kroku. Stały prefiks z instrukcjami i narzędziami idzie na początek, pod cache. Duże dane agent pobiera narzędziami, gdy ich potrzebuje. Stare wyniki narzędzi czyść, historię przy progu kompaktuj, ale reguły i kluczowe ustalenia agent zapisuje w pliku z notatkami, bo streszczenie gubi szczegóły. Zadania poboczne dostają subagenci z czystym oknem. Pamięć między sesjami traktuj jak niezaufane dane: z datą, źródłem, wygasaniem i kontrolą użytkownika.

### Pytania pogłębiające

- **Kompakcja czy start od czystego okna?** Kompakcja zachowuje ciągłość długiej rozmowy, ale streszczenie gubi szczegóły i kosztuje dodatkowe wywołanie. Przy kodzie często lepszy jest czysty start: stan leży na dysku w notatkach, testach i historii gita, a model umie go odczytać. Dokumentacja Claude podaje to jako alternatywę dla kompakcji.
- **Jak sprawdzisz, czy kompakcja gubi coś ważnego?** Ewaluacją na długich sesjach: fakty podane wcześnie, pytania o nie po kompakcji, porównanie z odpowiedzią na pełnej historii. Prompt kompakcji najpierw dopracowujesz pod kątem kompletności, potem tniesz to, co zbędne. Fakty, których zgubić nie wolno, agent zapisuje w notatkach, zanim dojdzie do streszczenia.
- **Co trzymasz w stałym prefiksie, a co pobierasz na żądanie?** W prefiksie reguły obowiązujące zawsze i krótkie fakty potrzebne w większości kroków. Wyszukiwanie znajduje to, co przypomina pytanie, a ogólna reguła rzadko przypomina konkretne pytanie. Duże i rzadko potrzebne dane agent pobiera przez ścieżki i narzędzia.
- **Użytkownik mówi, że asystent „pamięta” coś, czego nigdy mu nie powiedział. Co sprawdzasz?** Skąd przyszedł wpis: z rozmowy, dokumentu, strony czy wyniku narzędzia. Jeśli z obcej treści, to memory poisoning. Poprawka: zapis tylko z wypowiedzi użytkownika albo po jego potwierdzeniu, źródło i data przy każdym wpisie, widoczny komunikat o zapisie.
- **Czemu nie wrzucić wszystkiego do okna miliona tokenów?** Każde wywołanie płaci za całe wejście i dłużej czeka na pierwszy token, a jakość spada z długością i szumem. W badaniu Chroma każdy testowany model wypadł wyraźnie lepiej na ok. 300 tokenach potrzebnych fragmentów niż na ok. 113 tys. tokenów, w których ta sama odpowiedź ginęła w szumie. Duże okno to zapas, nie strategia.

### Źródła

- [Anthropic: Effective context engineering for AI agents (2025)](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents)
- [Chroma: Context Rot (2025)](https://www.trychroma.com/research/context-rot)
- [Dokumentacja Claude: Memory tool](https://platform.claude.com/docs/en/agents-and-tools/tool-use/memory-tool)
- [Dokumentacja Claude: Preserved thinking (edycja historii a bloki myślenia)](https://platform.claude.com/docs/en/build-with-claude/preserved-thinking)
- [Embrace The Red: SpAIware, fałszywe wspomnienia w ChatGPT jako kanał wycieku (2024)](https://embracethered.com/blog/posts/2024/chatgpt-macos-app-persistent-data-exfiltration/)

---

## Embeddingi i wyszukiwanie wektorowe

*Kontekst i wiedza*

*Ostatnia zmiana: 28 września 2026*

Model embeddingowy zamienia cały fragment tekstu w jeden wektor tak, żeby teksty o podobnym znaczeniu dostawały bliskie wektory. Na tym stoi wyszukiwanie wektorowe w RAG: pytanie też staje się wektorem, a baza zwraca fragmenty o najbliższych wektorach, nawet bez wspólnych słów.

**Po ludzku:** Mapa, na której każdy fragment tekstu ma swoją pinezkę, a teksty o podobnej treści leżą blisko siebie. Szukanie to wbicie pinezki pytania i zebranie najbliższych sąsiadów. Numer umowy prawie nie przesuwa pinezki, więc umowy 48213 i 48231 leżą niemal w tym samym miejscu.

*Interaktywny widżet na stronie: Wybierz pytanie albo wpisz własne i zobacz, który fragment każda metoda stawia na górze.*

### Jeden wektor na cały fragment

- Model embeddingowy, zwykle transformer, liczy wektor dla każdego tokena i łączy je w jeden: uśredniając (mean pooling) albo, w embedderach zbudowanych na LLM-ie dekoderowym, jak Qwen3-Embedding (2025), biorąc wektor ostatniego tokena. Wynik ma stałą długość, zwykle od kilkuset do kilku tysięcy liczb, niezależnie od długości tekstu. To co innego niż wektory wewnątrz LLM-a z tematu „Wektory i macierze”: tam każdy token ma własny wektor, a model uczy się przewidywać następny token, nie porównywać tekstów.
- Model uczy się kontrastowo, na parach: pytanie i fragment z odpowiedzią mają dostać bliskie wektory, a pytanie i inne fragmenty z tego samego batcha odległe. „Blisko” znaczy więc „mówi o tym samym albo na to odpowiada”, w granicach tego, co było w danych treningowych.
- Bliskość mierzy się cosinusem kąta między wektorami. Jeśli wektory mają długość 1 (część modeli tak je zwraca, w pozostałych normalizujesz sam), cosinus to zwykły iloczyn skalarny, a ranking po odległości euklidesowej wychodzi identyczny.

### Szukanie w milionach wektorów

- Wyszukiwanie dokładne (brute force) porównuje pytanie z każdym wektorem. Rozmiar indeksu to liczba wektorów × wymiary × bajty, np. 10 mln fragmentów × 1024 wymiary × 4 B (float32) ≈ 41 GB, i każde zapytanie czyta indeks w całości. Przy dziesiątkach tysięcy fragmentów to milisekundy i zero zgubionych wyników, przy milionach i dużym ruchu za wolno i za drogo.
- ANN (approximate nearest neighbours) sprawdza tylko ułamek wektorów, za cenę czasem zgubionego sąsiada. HNSW buduje wielowarstwowy graf „kto jest blisko kogo” i schodzi po nim zachłannie w stronę pytania: szybki i dokładny, ale dla niskiego opóźnienia wektory i graf siedzą w RAM. DiskANN (2019) trzyma w RAM tylko skompresowane wektory, a graf z pełnymi wektorami na SSD: w artykule to miliard wektorów na jednej maszynie z 64 GB RAM, poniżej 3 ms na zapytanie. IVF dzieli wektory na klastry (k-means) i przeszukuje tylko kilka najbliższych: mniej pamięci, zwłaszcza z kompresją, zwykle niższy recall przy tej samej szybkości. Kompromis stroisz parametrem, `efSearch` w HNSW albo `nprobe` w IVF, i mierzysz recall względem brute force na próbce zapytań.
- Pamięć zmniejsza kwantyzacja wektorów: int8 daje 4 razy mniej, binarna (1 bit na wymiar) 32 razy mniej, czyli zamiast 41 GB ok. 1,3 GB. W teście Hugging Face same wektory binarne zachowały ok. 92,5% jakości wyszukiwania, a przeliczenie czołówki pełnym wektorem pytania względem tych samych wektorów binarnych (rescoring) podniosło to do ok. 96%, bez dodatkowej pamięci. Liczby zależą od modelu.
- Drugi sposób to mniej wymiarów. Modele trenowane metodą Matryoshka trzymają najważniejszą informację w pierwszych wymiarach, więc zapisany wektor można przyciąć i znormalizować ponownie, bez przeliczania korpusu. OpenAI podaje, że text-embedding-3-large przycięty z 3072 do 256 wymiarów wypada w benchmarku MTEB lepiej niż starszy ada-002 z 1536.

### Słabe punkty, wyszukiwanie hybrydowe i reranking

- Wektor oddaje ogólny sens, a gubi szczegóły. „Umowa 48213” i „umowa 48231” to dla niego prawie to samo: umowa z jakimś numerem. Podobnie kody, liczby, nazwy produktów, których model nie widział w treningu, i firmowy żargon. „Praca zdalna wymaga zgody” i „nie wymaga zgody” też dostają prawie ten sam wektor: w benchmarku NevIR (2023) większość modeli wyszukiwania, także najnowocześniejszych, szeregowała dokumenty różniące się tylko przeczeniem nie lepiej niż losowo, a najlepiej wypadły cross-encodery. Powtórzenie badania z 2025 r. pokazało, że jeszcze lepiej radzą sobie rerankery LLM oceniające całą listę naraz, choć wciąż gorzej niż ludzie.
- Wyszukiwanie wektorowe zawsze zwraca k wyników, także gdy w bazie nie ma odpowiedzi. Stały próg podobieństwa przeniesiony z innego modelu nie zadziała, bo skala zależy od modelu: w multilingual-e5 wyniki skupiają się między 0,7 a 1,0. Próg dobierasz na własnych danych, a pewniejszym sygnałem jest wynik rerankera.
- Dlatego standardem jest hybryda: BM25, czyli klasyczny ranking po wspólnych słowach ważonych ich rzadkością, plus wektory. Listy scala się np. przez RRF (reciprocal rank fusion): dokument dostaje sumę 1/(60 + miejsce) z każdej listy. RRF patrzy tylko na miejsca, więc nie trzeba godzić skal BM25 i cosinusa. Po polsku BM25 potrzebuje lematyzacji albo stemmera, inaczej „umowa” i „umowy” to różne słowa.
- Na końcu reranker, zwykle cross-encoder: czyta pytanie i fragment razem, więc widzi negację i szczegóły, których nie widać w dwóch osobno policzonych wektorach. Jest za wolny na cały korpus, więc porządkuje tylko czołówkę, np. 50–100 kandydatów. W teście Anthropic (contextual retrieval, 2024) dodanie kontekstu do fragmentów razem z BM25 obniżyło odsetek trafnych fragmentów brakujących w top 20 (1 − recall@20) z 5,7% do 2,9%, a reranking do 1,9%. Szerzej w temacie „RAG”.
- Techniki, które omijają słabości jednego wektora na fragment (HyDE, pytania generowane dla fragmentów, multi-query, small-to-big, late interaction w stylu ColBERT), opisuje sekcja „Sztuczki po stronie zapytania i indeksu” w temacie „RAG”.

### Decyzje przy budowie indeksu

- Chunking decyduje, co znaczy wektor. Długi fragment uśrednia kilka tematów i nie pasuje dobrze do żadnego pytania. Krótki gubi kontekst: „w tym okresie przysługuje…”, ale w jakim? Pomaga dopisanie tytułu dokumentu i sekcji przed embeddingiem. Tekst dłuższy niż limit modelu jest obcinany: w multilingual-e5 po 512 tokenach, w Qwen3-Embedding po 32 tys.
- Pytanie i dokument to różne teksty: kilka słów kontra akapit. Część modeli oczekuje prefiksów, np. `query: ` i `passage: ` w e5, albo parametru typu wejścia w API. Pominięty albo zamieniony prefiks nie rzuca błędu, tylko po cichu psuje ranking.
- Dla polskiego wybierasz model wielojęzyczny albo polski i sprawdzasz go na polskich pytaniach, nie tylko w rankingu MTEB. Benchmark PIRB (41 zadań wyszukiwania po polsku) porównuje ponad 20 modeli i pokazuje, że hybryda z wyszukiwaniem po słowach poprawia nawet najlepsze modele wektorowe.
- Zmiana modelu embeddingowego to przeliczenie całego korpusu, bo wektory z dwóch modeli są nieporównywalne, nawet przy tej samej liczbie wymiarów. Przy każdym wektorze trzymasz tekst źródłowy i wersję modelu, nowy indeks budujesz obok starego i przełączasz, gdy wygra na twoim zestawie.
- Wyszukiwanie oceniasz osobno od odpowiedzi, na zestawie pytań z oznaczonymi trafnymi fragmentami. Recall@k: jaka część trafnych fragmentów jest w pierwszych k wynikach. MRR: średnia z 1/miejsce pierwszego trafnego, więc 1. miejsce daje 1, a 3. daje 0,33. Wartość k ustawiasz na tyle fragmentów, ile naprawdę wkładasz do promptu. Zobacz „Ewaluacje”.

### Sprawdź się

**Pytanie:** Jak działa wyszukiwanie wektorowe i czemu samo nie wystarcza?

**Krótka odpowiedź:** Model embeddingowy, wytrenowany tak, by teksty o podobnym znaczeniu leżały blisko siebie, zamienia cały fragment w jeden wektor. Wektor pytania liczy się tym samym modelem, a wyszukiwanie zwraca najbliższe wektory po cosinusie. Przy milionach fragmentów indeks przybliżony, np. HNSW, odpowiada w milisekundach kosztem odrobiny recall, a zajmowaną przez niego pamięć zmniejsza kwantyzacja. Wektory łapią parafrazy, ale gubią identyfikatory, liczby, rzadkie nazwy i negację, a do tego zawsze coś zwracają. Dlatego łącz je z BM25 przez RRF, czołówkę porządkuj cross-encoderem, a recall@k mierz osobno od jakości odpowiedzi.

### Pytania pogłębiające

- **Zmieniasz model embeddingowy. Co z indeksem?** Przeliczasz cały korpus, bo wektory z różnych modeli są nieporównywalne, nawet przy tej samej liczbie wymiarów. Nowy indeks budujesz obok starego, porównujesz recall@k na tym samym zestawie pytań i dopiero wtedy przełączasz ruch. Dlatego przy wektorach trzymasz tekst źródłowy i wersję modelu.
- **HNSW czy IVF?** HNSW daje wysoki recall przy niskim opóźnieniu, o ile wektory i graf mieszczą się w RAM. IVF dzieli wektory na klastry i przeszukuje kilka z nich. Z kompresją PQ mieści dużo więcej wektorów w tej samej pamięci, kosztem recall, który odzyskujesz większym nprobe albo przeliczeniem czołówki na pełnych wektorach.
- **Jak odrzucić fragmenty, gdy w bazie nie ma odpowiedzi?** Próg cosinusa dobierasz na własnym zestawie, bo skala zależy od modelu. Do zestawu włączasz też pytania bez odpowiedzi w bazie. Pewniejszym sygnałem jest wynik rerankera. Model w prompcie dostaje wprost zgodę na „nie ma tego w źródłach”.
- **Jak łączysz wyszukiwanie wektorowe z filtrami, np. uprawnieniami albo datą?** Filtr nałożony po wyszukiwaniu wycina wyniki z top-k, więc przy wąskim filtrze zostaje ich za mało albo zero. Lepiej filtrować w trakcie przeszukiwania indeksu, co obsługuje wiele baz wektorowych, albo trzymać osobne indeksy, np. per klient. Uprawnienia egzekwujesz przy wyszukiwaniu, nie w prompcie.
- **Recall@10 jest wysoki, a odpowiedzi i tak słabe. Gdzie szukasz?** Najpierw, czy trafny fragment nie ląduje na 8.–10. miejscu, gdy do promptu idą tylko trzy pierwsze: wtedy pomaga reranker. Potem, czy fragment po wycięciu z dokumentu w ogóle zawiera odpowiedź (chunking). Na końcu, czy model jej nie przekręca, co mierzy już ewaluacja generowania.

### Źródła

- [Malkov, Yashunin: Efficient and robust approximate nearest neighbor search using HNSW graphs](https://arxiv.org/abs/1603.09320)
- [Cormack, Clarke, Büttcher: Reciprocal Rank Fusion (SIGIR 2009)](https://plg.uwaterloo.ca/~gvcormac/cormacksigir09-rrf.pdf)
- [Anthropic: Introducing Contextual Retrieval (2024)](https://www.anthropic.com/news/contextual-retrieval)
- [Hugging Face: Binary and Scalar Embedding Quantization](https://huggingface.co/blog/embedding-quantization)

---

## RAG

*Kontekst i wiedza*

*Ostatnia zmiana: 28 września 2026*

RAG (retrieval-augmented generation) to wyszukanie fragmentów twoich dokumentów i wklejenie ich do promptu przed pytaniem. Model odpowiada z podanego tekstu zamiast z pamięci, więc wiedza może być aktualna, prywatna i cytowana, ale jakość odpowiedzi zależy głównie od tego, co znajdzie wyszukiwanie.

**Po ludzku:** Egzamin z otwartą książką. Zamiast liczyć na pamięć ucznia, kładziesz przed nim właściwą stronę podręcznika tuż przed pytaniem. Jeśli podasz złą stronę, uczeń odpowie źle równie pewnie, bo czyta to, co dostał.

*Interaktywny widżet na stronie: Przejdź krok po kroku przez pipeline. Zobacz, które fragmenty odpadają na wyszukiwaniu i rerankingu oraz co zmienia się w odpowiedzi.*

### Indeksowanie i chunking

- Indeks buduje się wcześniej, poza ścieżką pytania: parsowanie dokumentów, podział na fragmenty (chunki), embedding każdego fragmentu i zapis w indeksie wektorowym oraz tekstowym. Jak działają embeddingi i wyszukiwanie wektorowe, opisuje temat „Embeddingi i wyszukiwanie wektorowe”. Parsowanie PDF-ów, tabel i skanów to częste źródło błędów: tekstu zepsutego przy parsowaniu nie znajdzie żadne wyszukiwanie. Pomagają parsery rozumiejące układ strony i modele wizyjne, a wyszukiwanie po obrazach stron w ogóle pomija wyciąganie tekstu (ColPali, 2024).
- Wielkość chunka to kompromis. Za mały traci kontekst („w tym okresie przysługuje…”, ale w jakim?), za duży rozmywa dopasowanie i zjada okno. Punkt startowy to chunki po kilkaset tokenów, cięte po strukturze dokumentu (nagłówki, sekcje, akapity), a nie po liczbie znaków. Ostateczny rozmiar dobierasz ewaluacją.
- Contextual Retrieval (Anthropic, 2024): model dopisuje do każdego chunka 50–100 tokenów kontekstu z całego dokumentu, zanim chunk trafi do obu indeksów. W testach Anthropic razem z BM25 i rerankingiem obniżyło to odsetek właściwych fragmentów brakujących w top 20 (1 − recall@20) z 5,7% do 1,9%.
- Każdy chunk dostaje metadane: źródło, datę, wersję, uprawnienia. Zmieniony dokument trzeba przeindeksować, usunięty usunąć z indeksu, a zmiana modelu embeddingów wymaga przeliczenia całego zbioru.

### Wyszukiwanie i reranking

- Wyszukiwanie hybrydowe (wektory plus BM25, scalone przez RRF) i reranking cross-encoderem opisuje temat „Embeddingi i wyszukiwanie wektorowe”. W pipelinie decydujesz o liczbach: ilu kandydatów pobrać (Anthropic brał top 150), ile fragmentów po rerankingu włożyć do promptu (zwykle kilka do kilkunastu) i ile opóźnienia możesz na to wydać.
- Pytanie z czatu bywa złym zapytaniem („a jak to było z tym urlopem?”). Pomaga przepisanie go przez model na samodzielne zapytanie z uwzględnieniem historii rozmowy.
- Uprawnienia filtruje się w zapytaniu do indeksu, na podstawie tożsamości użytkownika i ACL zsynchronizowanych ze źródłem, zanim fragment trafi do promptu. Polecenie „nie pokazuj tajnych dokumentów” w prompcie niczego nie gwarantuje, a dokumenty mogą zawierać wstrzyknięte polecenia (temat „Prompt injection”).

### Sztuczki po stronie zapytania i indeksu

- HyDE (Gao i in., 2022): model pisze hipotetyczną odpowiedź, a wyszukiwanie idzie po jej embeddingu zamiast po embeddingu pytania. Pomaga, gdy pytania i dokumenty są sformułowane zupełnie inaczej, np. potoczne pytanie kontra język regulaminu. Kosztuje dodatkowe wywołanie modelu przed każdym wyszukiwaniem. Szkodzi, gdy model nie zna domeny: zmyślone nazwy i liczby ciągną wyszukiwanie do niewłaściwych sąsiadów. Modele embeddingów z osobnym prefiksem albo instrukcją dla zapytań częściowo zmniejszają tę rozbieżność bez dodatkowego wywołania.
- Odwrotny kierunek, po stronie indeksu: model generuje dla każdego chunka pytania, na które ten chunk odpowiada, i indeksujesz je obok niego (doc2query, 2019). Płacisz raz, przy indeksowaniu, a nie przy każdym pytaniu. Indeks rośnie, a zysk zależy od tego, jak dobrze wygenerowane pytania pokrywają prawdziwe pytania użytkowników.
- Multi-query rozwija przepisywanie pytania z poprzedniej sekcji: kilka wersji zapytania wykonywanych równolegle, z wynikami scalonymi przez RRF. Podnosi recall, gdy nie wiadomo, jakimi słowami opisano odpowiedź, kosztem wywołania modelu i kilku wyszukiwań. Pytanie wieloetapowe („kto ma więcej urlopu, zespół Ani czy Bartka?”) rozbija się na podpytania. Gdy kolejne zależy od wyniku poprzedniego, to już agentic retrieval.
- Small-to-big (parent-document retrieval): indeksujesz małe fragmenty, bo dają precyzyjne dopasowanie, a do modelu trafia większa całość, sekcja albo strona, bo daje kontekst. Ceną są tokeny w prompcie, a kilka trafień z tej samej sekcji trzeba scalić w jeden fragment.
- Late interaction (ColBERT, 2020): wektor dla każdego tokena zamiast jednego na fragment, a trafność to suma najlepszych dopasowań tokenów pytania do tokenów dokumentu (MaxSim). To środek między szybkim bi-encoderem a dokładnym cross-encoderem, kosztem wielokrotnie większego indeksu.

### Prompt i cytaty

- Fragmenty idą do promptu z identyfikatorem i źródłem, a instrukcja każe odpowiadać tylko na ich podstawie, cytować identyfikatory i przyznać, gdy odpowiedzi w nich nie ma. Bez tej furtki model uzupełni luki z pamięci (temat „Halucynacje”).
- Przy długim materiale dokumenty idą przed pytaniem. Anthropic podaje, że pytanie na końcu poprawia jakość nawet o 30% przy złożonych wejściach z wieloma dokumentami. Zmienne fragmenty stoją za stałym system promptem, żeby nie psuć prompt cache’u (temat „Prompt caching”).
- Cytaty sprawdzaj w kodzie: czy cytowany fragment był w kontekście i czy cytat naprawdę w nim jest. API z wbudowanymi cytatami, jak Citations w Claude, zwracają cytowany tekst ze wskazaniem zakresu w dokumencie, a poprawność wskazania gwarantuje API.

### Ewaluacja, agenci i alternatywy

- Wyszukiwanie i generowanie ewaluuje się osobno. Wyszukiwanie: zestaw pytań z oznaczonymi właściwymi fragmentami i recall@k, czyli jaka część oznaczonych fragmentów jest w pierwszych k wynikach (przy jednym właściwym fragmencie: czy w ogóle tam jest), przy k równym liczbie fragmentów w prompcie. Generowanie: wierność (czy każde twierdzenie wynika z podanych fragmentów) i kompletność, zwykle modelem jako sędzią sprawdzonym na ludzkich ocenach (temat „Ewaluacje”).
- Agentic retrieval: wyszukiwanie jest narzędziem, a model sam układa zapytania, czyta wyniki i szuka dalej (temat „Pętla agenta”). Radzi sobie z pytaniami wieloetapowymi i porównaniami, do których nie wystarczy jedno wyszukiwanie, kosztem kilku tur, czasu i tokenów.
- Długi kontekst zamiast RAG ma sens przy małym, stałym zbiorze, zwłaszcza z prompt cachingiem. Anthropic w 2024 r. wskazywał granicę ok. 200 tys. tokenów (ok. 500 stron), czyli całe ówczesne okno Claude’a. Przy oknach 1 mln tokenów (stan na wrzesień 2026) koszt na pytanie, opóźnienie i spadek jakości z długością rozstrzygają dużo wcześniej niż rozmiar okna (temat „Okno kontekstowe i agent”). RAG wygrywa przy dużym albo zmiennym zbiorze i gdy liczą się cytaty i uprawnienia. Fine-tuning uczy stylu i formatu, a faktów uczy zawodnie i trudno je potem aktualizować (temat „Fine-tuning i LoRA”).

### Sprawdź się

**Pytanie:** Jak działa RAG i gdzie najczęściej zawodzi?

**Krótka odpowiedź:** RAG podaje modelowi wiedzę w kontekście zamiast liczyć na jego pamięć. Wcześniej, offline, dokumenty się parsuje, tnie po strukturze, opisuje metadanymi i uprawnieniami, a potem indeksuje wektorowo oraz w BM25. Przy pytaniu wyszukiwanie idzie hybrydowo z filtrem uprawnień, reranker wybiera kilka najlepszych fragmentów, a prompt każe odpowiadać tylko z nich, z cytatami, i przyznać, gdy odpowiedzi nie ma. Najczęściej zawodzi parsowanie i wyszukiwanie, nie model: właściwego fragmentu po prostu nie ma w prompcie. Dlatego recall wyszukiwania i wierność odpowiedzi mierz osobno.

### Pytania pogłębiające

- **Użytkownicy zgłaszają złe odpowiedzi. Jak szukasz przyczyny?** Na trace’ach sprawdź etap po etapie: czy właściwy fragment był w wynikach wyszukiwania, czy przetrwał reranking, czy trafił do promptu i czy model go użył. Brak w wynikach to parsowanie, chunking albo zapytanie. Obecny, ale źle użyty to prompt albo model. Nieaktualna treść to proces indeksowania.
- **RAG czy długi kontekst?** Długi kontekst jest prostszy przy małym, stałym zbiorze, zwłaszcza z prompt cachingiem. RAG wygrywa przy dużym albo zmiennym zbiorze pod względem kosztu na pytanie, opóźnienia, uprawnień i cytatów, a krótszy kontekst to też mniejszy spadek jakości z długością.
- **Jak obsłużyć uprawnienia?** ACL zapisane w metadanych każdego chunka i zsynchronizowane ze źródłem, filtr w zapytaniu do indeksu na podstawie tożsamości użytkownika i test, że osoba bez dostępu nie dostaje fragmentu. Nigdy przez instrukcję w prompcie.
- **Kiedy agentic retrieval zamiast jednego wyszukiwania?** Gdy pytanie wymaga kilku kroków albo porównania źródeł i nie wystarczy do niego jedno zapytanie. Zacznij od jednego wyszukiwania, zmierz, na jakich pytaniach zawodzi, i dopiero tam płać turami i opóźnieniem agenta.
- **Kiedy HyDE szkodzi?** Gdy model nie zna domeny: hipotetyczna odpowiedź ma zmyślone nazwy, liczby i terminy, więc jej embedding ląduje obok dokumentów o czymś innym. Nie pomaga też przy wyszukiwaniu identyfikatorów i dokładnych fraz, gdzie wygrywa BM25, i przy ciasnym budżecie opóźnienia. Rozstrzyga porównanie recall@k z HyDE i bez niego na własnym zestawie pytań.

### Źródła

- [Anthropic: Contextual Retrieval](https://www.anthropic.com/engineering/contextual-retrieval)
- [Faysse i in.: ColPali, wyszukiwanie po obrazach stron (arXiv, 2024)](https://arxiv.org/abs/2407.01449)
- [Lewis i in.: Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks (arXiv)](https://arxiv.org/abs/2005.11401)
- [Gao i in.: Precise Zero-Shot Dense Retrieval without Relevance Labels, czyli HyDE (arXiv)](https://arxiv.org/abs/2212.10496)
- [Dokumentacja Claude: citations](https://platform.claude.com/docs/en/build-with-claude/citations)

---

## Pętla agenta

*Agenci*

*Ostatnia zmiana: 28 września 2026*

Agent to model w pętli: dostaje cel i narzędzia, wybiera wywołanie, twój kod je wykonuje i odsyła wynik, aż model odpowie bez wywołania. Od workflow różni się jednym: kolejny krok wybiera model, a nie twój kod.

**Po ludzku:** Workflow to lista kroków dla stażysty: zrób to, potem tamto, a jak coś nie pasuje, przyjdź do mnie. Agent to asystent, który dostaje cel, telefon i kalendarz, a kolejne kroki wymyśla sam. Poradzi sobie z niespodzianką, ale nie wiesz z góry, ile mu to zajmie i co zrobi po drodze.

*Interaktywny widżet na stronie: Wybierz workflow albo agenta i to, co jest w piątek w kalendarzu, potem naciśnij ▶. Patrz, kto wybiera kolejny krok i jak z każdą turą rośnie kontekst.*

### Pętla w kodzie

- Pętla to kilkanaście linijek zwykłego kodu. Wyślij do modelu kontekst i definicje narzędzi. Jeśli odpowiedź zawiera wywołania, dopisz do kontekstu odpowiedź modelu bez zmian, wykonaj wywołania, dopisz wyniki i wyślij całość znowu. Jeśli nie zawiera, koniec. Model niczego nie uruchamia, tylko pisze, co chce wywołać (temat „Narzędzia (function calling)”).
- W API Anthropic taka odpowiedź ma `stop_reason: "tool_use"` i bloki `tool_use` z identyfikatorem. Wyniki wracają w następnej wiadomości, po turze asystenta, jako bloki `tool_result` z tym samym `tool_use_id`, a błąd oznaczasz `is_error: true`. W Responses API OpenAI to elementy `function_call` i `function_call_output` łączone przez `call_id`. Kilka wywołań z jednej odpowiedzi wykonujesz równolegle i odsyłasz wszystkie wyniki naraz.
- Model myśli też między wywołaniami (interleaved thinking; w Claude Opus 5.5 myślenia nie da się wyłączyć, stan na wrzesień 2026). API Anthropic wymaga, by bloki thinking z tury z narzędziami wróciły kompletne i niezmienione, a zmienione odrzuca błędem 400. W Responses API odsyłasz reasoning items razem z wynikami albo łączysz requesty przez `previous_response_id` (temat „Modele rozumujące”).
- Odpowiedź bez wywołania to tylko ocena modelu, że skończył. Kod dokłada twarde warunki stopu: limit tur, budżet tokenów i kosztu, limit czasu, wykrywanie powtórzonych wywołań. Obsługuje też inne powody zatrzymania i żaden z nich nie jest końcem zadania: odpowiedź ucięta na limicie tokenów (`max_tokens`) albo okna kontekstu (`model_context_window_exceeded`) to błąd do obsłużenia, `pause_turn` (pętla narzędzi po stronie dostawcy doszła do limitu) znaczy, że trzeba odesłać odpowiedź, żeby model kontynuował, a `refusal` wymaga osobnej ścieżki.

### Workflow czy agent

- W workflow kroki zapisuje programista, a model robi w nich wąskie zadania, np. wyciąga dane z polecenia albo pisze wiadomość. W agencie kod daje cel i narzędzia, a kroki wybiera model. Workflow jest tańszy, szybszy, powtarzalny i łatwy do testowania, ale obsłuży tylko to, co ktoś przewidział. Agent radzi sobie z niespodziankami, ale płaci tokenami, czasem i przewidywalnością. Kolejność: jedno wywołanie modelu, potem workflow, agent dopiero wtedy, gdy kroków nie da się wypisać z góry.
- Wzorce z tekstu Anthropic „Building effective agents” (2024): łańcuch wywołań ze sprawdzeniami w kodzie między nimi, routing (klasyfikacja, potem osobna ścieżka albo tańszy model), równoległość (niezależne części naraz albo kilka prób i głosowanie), orchestrator–workers (model dzieli zadanie na podzadania, których nie znasz z góry) i evaluator–optimizer (jeden model pisze, drugi ocenia, aż wynik przejdzie). Na produkcji często wygrywa workflow z jednym agentowym krokiem w środku.
- Te same idee pod innymi nazwami. ReAct (Yao i in., 2022) to właśnie ta pętla: myśl to tekst albo myślenie modelu, akcja to wywołanie narzędzia, obserwacja to jego wynik. Cztery wzorce agentowe Andrew Nga (2024) są w tym przewodniku jako evaluator–optimizer (refleksja), „Narzędzia (function calling)” (użycie narzędzi), lista zadań w długich zadaniach (planowanie) i „Wielu agentów” (współpraca agentów).

### Awarie długich zadań

- Błąd narzędzia oddajesz modelowi jako zwykły wynik, z podpowiedzią: nie „błąd 409”, tylko „konflikt z Przeglądem kwartalnym, sprawdź wolne terminy”. Model zmienia wtedy podejście, jak w przykładzie z konfliktem. Wyjątek, który zabija pętlę, marnuje całą dotychczasową pracę. Błędy, których model nie naprawi, jak brak uprawnień czy wyczerpany budżet, obsługuje kod.
- W długiej historii agent gubi cel. Pomagają plan (lista zadań, którą agent odhacza i przepisuje na koniec kontekstu), notatki w plikach i kompakcja historii (temat „Context engineering i pamięć”).
- Agent utyka: ponawia to samo wywołanie, krąży między dwoma krokami, ogłasza sukces, którego nie było. Na to są limity i wykrywanie powtórek w kodzie, nie prośby w prompcie. Przerwany agent zostawia świat zmieniony w połowie, np. spotkanie przeniesione, a wiadomość niewysłana. Dlatego narzędzia zmieniające stan są idempotentne, stan pętli zapisujesz po każdym wywołaniu, żeby wznowić pracę po awarii, a człowiek dostaje raport z tego, co zdążyło się stać.

### Koszt, uprawnienia i ocena

- Każda tura wysyła cały kontekst od nowa, więc łączna liczba tokenów wejściowych rośnie mniej więcej z kwadratem liczby tur. Opóźnienia się sumują: każda tura to pełne wywołanie modelu plus czas narzędzia. Rachunek pokazuje temat „Okno kontekstowe i agent”. Dopóki historię tylko się dopisuje, wszystko poza najnowszą częścią tury to stały prefiks, więc dzięki „Prompt caching” czyta się go z cache’u za ok. jedną dziesiątą ceny wejścia. Krzywa zostaje kwadratowa, tylko tańsza.
- Agent działa w twoim imieniu, więc dostaje najmniejsze potrzebne uprawnienia. Akcje nieodwracalne albo wychodzące na zewnątrz (wysyłka, płatność, kasowanie) zatwierdza człowiek, a pilnuje tego kod, nie prompt: w przykładzie kod wstrzymuje pętlę przed wysłaniem wiadomości. Maile, strony i wyniki narzędzi mogą zawierać polecenia (temat „Prompt injection”).
- Agenta oceniasz po stanie końcowym, nie po jego podsumowaniu: czy spotkanie naprawdę jest w piątek i czy wiadomość wyszła. Trace, czyli zapis każdej tury z narzędziami, argumentami, wynikami i tokenami, pokazuje, gdzie agent błądzi i ile kosztuje. Ten sam przypadek raz przechodzi, raz nie, więc liczysz pass^k: czy agent zrobi zadanie za każdym z k razy (temat „Ewaluacje”).
- Zadanie, które dzieli się na niezależne części, główny agent może rozdać subagentom z osobnym kontekstem, za cenę wielokrotnie większej liczby tokenów. Zobacz „Wielu agentów”. Jak agent kodujący składa te elementy w całość (uprawnienia, sandbox, plan, kompakcja, subagenci), opisuje temat „Harness agenta kodującego”.

### Sprawdź się

**Pytanie:** Kiedy zbudujesz agenta zamiast workflow i jak zabezpieczysz jego pętlę na produkcji?

**Krótka odpowiedź:** Agent to model w pętli: dostaje cel i narzędzia, wybiera wywołanie, twój kod je wykonuje i dopisuje wywołanie z wynikiem, aż model odpowie bez wywołania. W workflow kroki zapisujesz ty, a model robi w nich wąskie zadania, więc workflow jest tańszy, szybszy i powtarzalny. Agent opłaca się dopiero, gdy kroków nie da się wypisać z góry. Wtedy kod pilnuje limitu tur, budżetu i czasu, daje najmniejsze uprawnienia, wstrzymuje akcje nieodwracalne do zgody człowieka i zapisuje stan po każdym kroku. Jakość mierzy się stanem końcowym, a każde zadanie puszcza się kilka razy.

### Pytania pogłębiające

- **Skąd agent wie, że skończył?** Nie wie, tylko tak ocenia: odpowiada bez wywołania narzędzia. Bywa, że ogłasza sukces, którego nie było. Dlatego kod ma twarde limity (tury, tokeny, czas), a wynik sprawdzasz testem stanu końcowego, nie podsumowaniem modelu.
- **Agent w kółko wywołuje to samo narzędzie. Co robisz?** Doraźnie kod wykrywa powtórzone wywołanie z tymi samymi argumentami, dopisuje modelowi uwagę, a przy kolejnym powtórzeniu przerywa pętlę. Przyczyna leży zwykle w narzędziu: niejasny komunikat błędu albo wynik, z którego nie widać postępu. Taki przebieg trafia do zestawu ewaluacyjnego jako nowy przypadek.
- **Agent przerwał w połowie zadania. Jak się na to przygotować?** Zakładasz, że to się zdarzy. Narzędzia zmieniające stan przyjmują klucz idempotencji, a stan pętli zapisujesz po każdym wywołaniu, więc da się wznowić pracę bez powtarzania skutków. Człowiek dostaje listę tego, co już zmieniono, a tam, gdzie się da, akcję odwracającą.
- **Jak ocenisz, czy agent jest gotowy na produkcję?** Zestaw zadań z prawdziwych przypadków, każde puszczone kilka razy i ocenione po stanie końcowym, plus koszt i czas na zadanie. Liczysz pass^k, bo użytkownik oczekuje, że zadziała za każdym razem: dla zadania, które agent robi w 90% prób, przy niezależnych próbach trzy udane z rzędu wychodzą w ok. 73% przypadków. Dla zestawu liczysz pass^k per zadanie i uśredniasz.
- **Jak klasyfikować awarie agenta?** Za Chip Huyen (2025) w trzech grupach. Planowanie: złe albo nieistniejące narzędzie, złe argumenty, nieosiągnięty cel, fałszywe ogłoszenie sukcesu. Narzędzie: wywołanie poprawne, ale narzędzie zwróciło zły wynik, więc każde testuje się osobno. Efektywność: zadanie zrobione, ale zbyt wieloma krokami, zbyt drogo albo zbyt wolno wobec punktu odniesienia. Oznaczone tak trace’y pokazują, czy poprawiać prompt i opisy narzędzi, samo narzędzie czy limity.
- **Czy do agenta potrzebny jest framework?** Nie. Pętla to kilkanaście linijek na zwykłym API i od tego warto zacząć. Framework pomaga przy trwałym stanie, wznawianiu i trace’ach, ale ukrywa prompt i kontekst, które i tak trzeba rozumieć.

### Źródła

- [Anthropic: Building effective agents](https://www.anthropic.com/engineering/building-effective-agents)
- [Dokumentacja Claude: How tool use works (pętla i powody zatrzymania)](https://platform.claude.com/docs/en/agents-and-tools/tool-use/how-tool-use-works)
- [Anthropic: Demystifying evals for AI agents](https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents)
- [Chip Huyen: Agents (2025, m.in. typy awarii)](https://huyenchip.com/2025/01/07/agents.html)
- [Hugging Face: Agents Course (praktyka)](https://huggingface.co/learn/agents-course/unit0/introduction)

---

## Narzędzia (function calling)

*Agenci*

*Ostatnia zmiana: 28 września 2026*

Model nie wykonuje żadnego kodu. Dostaje listę narzędzi z nazwą, opisem i schematem argumentów, a gdy uzna to za potrzebne, zamiast odpowiedzi wypisuje wywołanie: twój kod je wykonuje i odsyła wynik.

**Po ludzku:** Kierownik, który może tylko dzwonić. Ma kartkę z listą spraw, które załatwi asystent, i krótkim opisem każdej. Mówi: „Sprawdź, czy jutrzejszy pociąg o 8:15 jedzie planowo”, a asystent sprawdza i oddzwania z wynikiem. Gdy opisy na kartce są mętne, kierownik prosi nie o to, co trzeba.

*Interaktywny widżet na stronie: Zmień jakość opisów narzędzi i przełącz równoległe wywołania, potem przejdź krok po kroku przez wymianę. Patrz, po które narzędzie sięga model, ile requestów to kosztuje i czy odpowiedź jest prawdziwa.*

### Jak działa function calling

- Model nie ma dostępu do internetu, bazy danych ani twojego komputera. Umie tylko napisać w umówionym formacie „wywołaj prognoza_pogody dla Gdańska na jutro”. Wynik wraca do niego jako kolejna wiadomość, a model czyta go jak każdy inny tekst. Jak z tego powstaje wielokrokowa praca, opisuje temat „Pętla agenta”.
- Definicje trafiają do promptu jako tekst w formacie znanym modelowi z treningu, tak jak role w temacie „Jak model widzi czat”. Wywołanie to też zwykłe tokeny: API wyłuskuje je i zwraca jako osobne pole z id, nazwą i argumentami, a powód zakończenia mówi, że model czeka na wynik. Kilka wywołań naraz wykonujesz współbieżnie i odsyłasz wszystkie wyniki, każdy z id swojego wywołania. Gdy kolejność ma znaczenie, wyłączasz równoległość (`parallel_tool_calls: false` w OpenAI, `disable_parallel_tool_use` w Anthropic).
- `tool_choice`: `auto` (domyślnie, model decyduje), `required` albo `any` (musi wywołać któreś), konkretne narzędzie (np. do wyciągania danych do schematu), `none` (nie wolno wywołać). Wymuszenie w każdej turze nie pozwoli modelowi skończyć, więc w pętli stosuje się je tylko w wybranych krokach. Wymuszenie nie wszędzie działa (stan na wrzesień 2026): Claude Opus 5.5 i Fable 5.1 odrzucają `any` i konkretne narzędzie błędem 400. Do wyciągania danych do schematu użyj tam structured outputs (temat „Wymuszanie formatu”).
- Część narzędzi wykonuje dostawca: wyszukiwanie w sieci albo uruchamianie kodu w piaskownicy dzieje się po jego stronie, a ty dostajesz gotowy wynik. Mniej kodu do napisania, mniej kontroli nad tym, co i gdzie się wykonało.
- Computer use i agenci przeglądarkowi to ta sama pętla z ekranem jako narzędziem: model dostaje zrzut ekranu, wypisuje akcję (kliknij w x, y, wpisz tekst), twój kod ją wykonuje i odsyła nowy zrzut. Każdy zrzut to wejście obrazowe, u Anthropic ok. 1000–1800 tokenów, i zostaje w historii, więc w długich sesjach stare zrzuty się usuwa. Każda strona, na którą patrzy agent, to niezaufane wejście: tekst na ekranie może nim sterować jak każdy wynik narzędzia (temat „Prompt injection”).

### Opis to jedyna instrukcja obsługi

- Model wybiera narzędzie tylko na podstawie nazwy, opisu i schematu, kodu nie widzi. Opis pisz jak dla nowej osoby w zespole: co narzędzie robi, kiedy go użyć, kiedy nie, w jakim formacie podać argumenty i co zwraca. Dwa narzędzia o podobnych opisach to dla modelu rzut monetą, co widać w wariancie z nakładającymi się narzędziami.
- Pomagają nazwy z przedrostkiem usługi (`kolej_status`, `kolej_rozklad`), jednoznaczne parametry (`user_id` zamiast `user`), enumy zamiast wolnego tekstu i przykładowe wywołania: w testach Anthropic przykłady w definicji podniosły poprawność złożonych argumentów z 72% do 90%. Lepiej kilka narzędzi pod konkretne zadania niż opakowanie każdego endpointu API.
- Wynik też projektujesz. Zwracaj tylko potrzebne pola, czytelne nazwy zamiast wewnętrznych UUID, a długie listy przycinaj z informacją, jak pobrać resztę. Każdy token wyniku zostaje w kontekście i jest wysyłany w każdej kolejnej turze, chyba że harness go wyczyści albo skompaktuje (temat „Context engineering i pamięć”).
- Tryb ścisły (`strict`) to constrained decoding z tematu „Wymuszanie formatu”: argumenty zawsze pasują do schematu. Sensownych wartości nie gwarantuje: model nadal potrafi zmyślić brakujący parametr albo wybrać zły dzień.

### Każde narzędzie kosztuje w każdym requeście

- Definicje to tekst doklejany do każdego requestu, więc płacisz za nie w każdej turze, także gdy żadne narzędzie nie zostanie użyte. Dostawca dolicza jeszcze własny ukryty prompt o obsłudze narzędzi, u Anthropic kilkaset tokenów, zależnie od modelu.
- Definicje stoją na początku promptu, więc dobrze się cache’ują (temat „Prompt caching”). Dodanie, usunięcie albo przestawienie narzędzia w trakcie rozmowy unieważnia cache wszystkiego, co stoi za nimi. OpenAI ma do tego `allowed_tools`: zawęża wybór w danej turze bez zmiany listy definicji.
- Więcej narzędzi to wyższy rachunek, mniej miejsca w kontekście i trudniejszy wybór. OpenAI zaleca mniej niż 20 funkcji naraz, zastrzegając, że to tylko luźna wskazówka. Anthropic podaje przykład pięciu serwerów MCP z 58 narzędziami, których definicje zajmowały ok. 55 tys. tokenów, zanim padło pierwsze pytanie (temat „MCP”). Przy takiej skali pomaga wyszukiwanie narzędzi: model widzi narzędzie do szukania, a pełne definicje dostaje dopiero wtedy, gdy są potrzebne.

### Błędy i bezpieczeństwo

- Błąd też jest wynikiem. Zamiast przerywać pracę, odeślij modelowi konkretny komunikat: co jest nie tak i jak to poprawić, a model zwykle poprawi się w następnym kroku. Argumenty sprawdzaj w kodzie, zanim cokolwiek wykonasz. Operacje zmieniające stan zabezpiecz kluczem idempotencji: po błędzie sieci kod albo model może ponowić to samo wywołanie, a ten sam bilet nie może zostać kupiony dwa razy.
- Narzędzie to uprawnienie. Model może wywołać je z błędnymi argumentami albo pod wpływem tekstu, który właśnie przeczytał, bo wyniki narzędzi (strony, maile, dokumenty) to niezaufane dane. Daj najmniejsze potrzebne prawa, a akcje nieodwracalne, jak przelew, usunięcie czy wysyłka, niech czekają na potwierdzenie przez człowieka, wymuszone w kodzie, nie w prompcie. Więcej w temacie „Prompt injection”.

### Sprawdź się

**Pytanie:** Jak działa function calling i jak projektować narzędzia dla modelu?

**Krótka odpowiedź:** Model niczego nie wykonuje. Z pytaniem dostaje definicje narzędzi: nazwę, opis i schemat argumentów w JSON Schema. Gdy uzna narzędzie za potrzebne, zamiast odpowiedzi wypisuje wywołanie w wyuczonym formacie, czasem kilka naraz. Twój kod waliduje argumenty, wykonuje wywołanie i odsyła wynik z id wywołania. Model wybiera głównie po opisie, więc opisy pisze się jak dokumentację, narzędzia nie powinny się nakładać, a wyniki mają być zwięzłe. Za definicje płaci się w każdym requeście. Błąd wraca jako wynik ze wskazówką, operacje zmieniające stan są idempotentne, a nieodwracalne zatwierdza człowiek.

### Pytania pogłębiające

- **Czym function calling różni się od structured output?** Od strony modelu to ten sam mechanizm: tekst w zadanym formacie. Różnica jest w tym, co dzieje się dalej. Structured output to końcowa odpowiedź dla twojego kodu. Wywołanie narzędzia to prośba, po której wynik wraca do modelu i rozmowa trwa dalej.
- **Ile narzędzi to za dużo?** Twardej granicy nie ma. Sygnałem są pomyłki w wyborze narzędzia na twoim zestawie ewaluacyjnym i rosnący koszt definicji. Wtedy scalasz podobne narzędzia, dzielisz pracę między subagentów z własnymi zestawami albo ładujesz definicje na żądanie przez wyszukiwanie narzędzi.
- **Co zrobić, gdy model podaje złe argumenty?** Najpierw poprawić opis i schemat: format, przykłady, enumy. Potem walidacja w kodzie i czytelny błąd odsyłany modelowi, żeby mógł się poprawić. Tryb ścisły usuwa błędy składni i typów, ale nie złe wartości.
- **Wynik narzędzia ma 50 tys. tokenów. Co robisz?** Nie wklejasz go w całości, bo zostanie w kontekście i pójdzie w każdej turze, dopóki czegoś nie wyczyścisz. Filtrujesz pola, stronicujesz, zwracasz podsumowanie z uchwytem do pełnych danych, a dużą treść zapisujesz do pliku, który agent przeszuka osobnym narzędziem.
- **Kiedy zamiast wielu wywołań dać modelowi narzędzie do uruchamiania kodu?** Gdy zadanie to wiele wywołań i obróbka danych, np. pobierz 50 rekordów, przefiltruj, policz. Model pisze skrypt, który sam woła narzędzia, a do kontekstu wraca tylko wynik końcowy. Anthropic podaje ok. 37% mniej tokenów na złożonych zadaniach badawczych. Ceną jest piaskownica do uruchamiania kodu i trudniejszy audyt.

### Źródła

- [Anthropic: Writing effective tools for agents](https://www.anthropic.com/engineering/writing-tools-for-agents)
- [OpenAI: Function calling (dokumentacja)](https://developers.openai.com/api/docs/guides/function-calling)
- [Anthropic: Advanced tool use (wyszukiwanie narzędzi)](https://www.anthropic.com/engineering/advanced-tool-use)
- [Dokumentacja Claude: Define tools (tool_choice i ograniczenia wymuszania)](https://platform.claude.com/docs/en/agents-and-tools/tool-use/define-tools)
- [Dokumentacja Claude: Computer use tool](https://platform.claude.com/docs/en/agents-and-tools/tool-use/computer-use-tool)

---

## MCP

*Agenci*

*Ostatnia zmiana: 28 września 2026*

MCP (Model Context Protocol) to otwarty standard podłączania narzędzi i danych do aplikacji z modelem. Integrację piszesz raz jako serwer MCP i używasz jej w Claude, ChatGPT, IDE czy własnym agencie. Model o MCP nic nie wie: nadal widzi definicje narzędzi w prompcie i wypisuje wywołania.

**Po ludzku:** Gniazdko w ścianie. Producent czajnika nie zna twojej instalacji, a elektryk nie zna czajnika: wystarczy wspólny kształt wtyczki. Gniazdko nie sprawdza jednak, co do niego wkładasz, więc za podłączenie wadliwego sprzętu odpowiadasz ty.

*Interaktywny widżet na stronie: Podłączaj serwery MCP i patrz, co trafia do kontekstu modelu, zanim użytkownik cokolwiek napisze.*

### Po co standard: M + N zamiast M × N

- Bez standardu każda aplikacja z modelem pisze własną integrację z każdym systemem: M aplikacji i N systemów to M × N integracji. Z MCP system dostaje jeden serwer, a aplikacja jeden klient, więc wystarczy M + N. Anthropic opublikował MCP w listopadzie 2024, a w grudniu 2025 przekazał go do Agentic AI Foundation przy Linux Foundation, więc standard nie należy do jednego dostawcy.
- MCP standaryzuje stronę aplikacji: jak znaleźć narzędzia serwera (`tools/list`) i jak je wywołać (`tools/call`). Strona modelu się nie zmienia. Host zamienia definicje z serwera na zwykłe narzędzia w API modelu, model wypisuje wywołanie, a host przekazuje je właściwemu serwerowi i oddaje wynik. Sam mechanizm opisuje temat „Narzędzia (function calling)”.
- MCP łączy agenta z narzędziami i danymi, A2A (Agent2Agent, stworzony przez Google, od czerwca 2025 projekt Linux Foundation) łączy agentów ze sobą. Agent A2A publikuje Agent Card ze swoimi umiejętnościami, a inny agent zleca mu zadanie i dostaje statusy i artefakty, nie widząc jego narzędzi ani promptu. Stan na wrzesień 2026: ponad 150 wspierających organizacji i integracje w platformach agentowych Google, Microsoftu i AWS, ale bez publicznych danych o użyciu. Subagenci w jednej aplikacji go nie potrzebują (temat „Wielu agentów”). A2A opłaca się, gdy drugi agent należy do innego zespołu albo dostawcy.

### Host, klient, serwer

- Host to aplikacja z modelem, np. Claude Desktop, IDE albo twój agent. Dla każdego serwera tworzy osobnego klienta i to host decyduje, co trafia do modelu. Serwer nie widzi rozmowy ani innych serwerów, dostaje tylko skierowane do siebie wywołania. Wiadomości to JSON-RPC 2.0 w jednym z dwóch transportów: stdio, gdy host uruchamia serwer jako lokalny proces i rozmawia z nim przez stdin i stdout, albo Streamable HTTP dla serwerów zdalnych, gdzie każda wiadomość to POST na jeden adres.
- Serwer wystawia trzy rodzaje rzeczy, różniące się tym, kto decyduje o użyciu. Narzędzia (tools) wybiera model. Zasoby (resources), np. plik albo schemat bazy, dołącza do kontekstu aplikacja. Prompty (prompts), czyli gotowe szablony, wybiera użytkownik, zwykle jako polecenie z ukośnikiem. W drugą stronę serwer może w trakcie wywołania poprosić użytkownika o dane albo zgodę (elicitation): formularzem, a przy hasłach i płatnościach linkiem otwieranym poza aplikacją. Sampling (serwer prosi model hosta o odpowiedź), roots (host wskazuje katalogi) i logowanie na poziomie protokołu są od wersji 2026-07-28 przestarzałe. Działają jeszcze co najmniej 12 miesięcy, a zastępują je bezpośrednie wywołania API dostawcy, parametry narzędzi oraz stderr albo OpenTelemetry. Opcjonalne rozszerzenia, negocjowane przez capabilities, dodają Tasks (długie wywołanie zwraca uchwyt, który klient odpytuje) i MCP Apps (interaktywny interfejs renderowany przez hosta w rozmowie).
- Wersja specyfikacji 2026-07-28, aktualna we wrześniu 2026, zrobiła protokół bezstanowym. Nie ma już handshake’u `initialize` ani sesji: każdy request niesie w `_meta` wersję protokołu i możliwości klienta, a `server/discover`, które każdy serwer musi obsługiwać, a klient może wywołać, zwraca wersje i możliwości serwera. Dzięki temu zdalny serwer skaluje się za zwykłym load balancerem. Gdy serwer potrzebuje czegoś od użytkownika, nie wysyła własnego requestu, tylko odpowiada `input_required`, a klient ponawia wywołanie z odpowiedzią. Starsze serwery (do wersji 2025-11-25) zaczynają od `initialize` z negocjacją możliwości i trzymają sesję. Klient, który chce z nimi rozmawiać, wykrywa wersję i przełącza się na stary tryb. W drugą stronę to nie działa: klient na wersji 2025-11-25 lub starszej nie umie przejść na nowy tryb, więc serwer, który ma obsłużyć także takich klientów, musi obsługiwać obie ery i nadal odpowiadać na `initialize`.
- Zdalny serwer autoryzuje requesty przez OAuth 2.1 i jest w nim resource serverem. Na request bez tokena odpowiada 401 z adresem swoich metadanych. Klient znajduje w nich serwer autoryzacji, przeprowadza użytkownika przez logowanie i dostaje token wydany dla tego jednego serwera. Serwer nie może przyjąć tokena wystawionego dla innej usługi ani przekazać tokena klienta dalej do API (token passthrough). Lokalny serwer stdio bierze poświadczenia ze zmiennych środowiskowych.

*Interaktywny widżet na stronie: Przejdź krok po kroku przez wymianę z serwerem kalendarza. Patrz, co jest protokołem MCP, a co zwykłym function calling.*

### Każdy serwer kosztuje tokeny

- Prosty host dokleja definicje wszystkich narzędzi ze wszystkich podłączonych serwerów do każdego requestu. Anthropic opisuje pięć serwerów z 58 narzędziami, które zajmowały ok. 55 tys. tokenów, zanim padło pierwsze pytanie. Płacisz za to w każdej turze, a model częściej się myli, gdy narzędzia mają podobne nazwy, np. `notification-send-user` i `notification-send-channel`.
- Ogranicz to po stronie hosta: podłączaj tylko potrzebne serwery i włączaj z nich tylko potrzebne narzędzia. Przy dużym katalogu host odracza ładowanie definicji: model dostaje narzędzie do wyszukiwania narzędzi, a pełne definicje trafiają do kontekstu na żądanie. Stan na wrzesień 2026: Claude Code, Codex i Cursor robią tak domyślnie, a Claude Code na starcie ładuje tylko nazwy narzędzi i instrukcje serwera. Dokumentacja MCP radzi ten tryb, gdy definicje zajmują 1–5% okna. Nie przestawiaj ani nie usuwaj narzędzi w trakcie rozmowy, bo to unieważnia prompt cache (temat „Prompt caching”). Definicje znalezione wyszukiwaniem dopisuje się za prefiksem zapisanym w cache’u, więc go nie unieważniają.
- Serwer projektuj wokół zadań, nie endpointów API: jedno `schedule_event`, które szuka wolnego terminu i tworzy spotkanie, zamiast trzech opakowań `list_users`, `list_events` i `create_event` (przykład Anthropic). Zwracaj zwięzłe wyniki, tylko z polami potrzebnymi modelowi, filtrowane i stronicowane po stronie serwera, bo wynik zostaje w kontekście na wszystkie kolejne tury. Gdy host odracza ładowanie definicji, to nazwa, opis narzędzia i instrukcje serwera decydują, czy model w ogóle znajdzie narzędzie, więc najważniejsze informacje dawaj na początku. Gdy agent łączy wiele wywołań, pomaga code mode: model pisze skrypt, który woła narzędzia w sandboksie, a do kontekstu wraca tylko wynik końcowy.

### Obcy serwer to obcy kod i obcy tekst

- Lokalny serwer działa z uprawnieniami twojego użytkownika i może czytać pliki czy klucze SSH. Zdalny dostaje każdy argument, który przekaże mu model. Opisy narzędzi i ich wyniki trafiają do promptu jako tekst, a model nie odróżnia ich od twoich instrukcji (temat „Prompt injection”).
- Tool poisoning to polecenie ukryte w opisie narzędzia. Model czyta je, nawet jeśli nigdy tego narzędzia nie wywoła: w każdym requeście, gdy host ładuje definicje z góry, albo gdy wyszukiwanie zwróci to narzędzie, a użytkownik zwykle widzi tylko nazwę i skrót opisu. Invariant Labs pokazał w kwietniu 2025 narzędzie `add`, którego opis nakłonił agenta w Cursorze do odczytania klucza SSH i konfiguracji MCP i wysłania ich w dodatkowym parametrze. Złośliwy opis może też zmienić sposób używania narzędzi innych, zaufanych serwerów (shadowing).
- Rug pull: serwer zmienia definicje po tym, jak go zatwierdziłeś. Wystarczy, że następne `tools/list` zwróci inny opis albo nowa wersja pakietu zrobi coś innego niż poprzednia.
- Złośliwy serwer sam dostarcza dwa z trzech składników „lethal trifecta”: niezaufany tekst i kanał wyjścia, bo wszystko, co model wpisze w argumenty jego narzędzi, trafia do właściciela. Prywatne dane daje dowolny inny podłączony serwer. Szkodę mnożą zbyt szerokie uprawnienia: token do wszystkich repozytoriów zamienia jeden udany atak w wyciek wszystkiego.
- Obrona leży w hoście, nie w prompcie: lista dozwolonych serwerów, z nich tylko potrzebne narzędzia, przypięte wersje i ponowna zgoda przy zmianie definicji, lokalne serwery w sandboksie, tokeny z minimalnym zakresem rozszerzanym na żądanie. Narzędzia, które coś zmieniają albo wysyłają, wywołuj dopiero po zgodzie człowieka, który widzi argumenty. Adnotacje takie jak `readOnlyHint` deklaruje sam serwer, więc od niezaufanego nic nie znaczą.

### Kiedy nie potrzebujesz MCP

- Jedna aplikacja z kilkoma własnymi narzędziami: wystarczy zwykłe function calling w kodzie aplikacji. MCP dokłada osobny proces albo usługę, transport, autoryzację i wersjonowanie, a zysk z M + N pojawia się dopiero wtedy, gdy tej samej integracji używa kilka aplikacji.
- MCP opłaca się, gdy integracja ma działać w wielu hostach (twoje produkty, IDE zespołu, Claude i ChatGPT klientów) albo gdy chcesz użyć gotowego serwera dostawcy zamiast pisać integrację. API OpenAI (narzędzie `mcp` w Responses API) i Anthropic (MCP connector) same łączą się ze zdalnym serwerem, więc nie musisz pisać klienta.

### Sprawdź się

**Pytanie:** Czym jest MCP i kiedy użyjesz go zamiast zwykłego function calling?

**Krótka odpowiedź:** MCP to otwarty protokół oparty na JSON-RPC, który standaryzuje stronę aplikacji w function calling: host odkrywa narzędzia serwera przez tools/list i wywołuje je przez tools/call. Model nic nie zauważa, nadal widzi definicje w prompcie i wypisuje wywołania. Zysk to M + N integracji zamiast M × N: serwer pisze się raz i działa w Claude, ChatGPT czy IDE. Cena to definicje podłączonych serwerów w kontekście (wszystkie w każdym requeście, chyba że host ładuje je na żądanie przez wyszukiwanie narzędzi) i nowa granica zaufania, bo obcy serwer to obcy kod i obcy tekst w prompcie. Dla jednej aplikacji z kilkoma własnymi narzędziami wystarczy zwykłe function calling.

### Pytania pogłębiające

- **Masz 30 serwerów MCP i agent zaczyna wybierać złe narzędzia. Co robisz?** Zmierz, ile tokenów zajmują definicje i które narzędzia się nakładają. Zostaw tylko narzędzia potrzebne do zadania, resztę ładuj przez wyszukiwanie narzędzi albo podziel między subagentów z własnymi zestawami. Nie przestawiaj ani nie usuwaj narzędzi w trakcie rozmowy, żeby nie psuć prompt cache’u.
- **Jak dopuścić serwery MCP w firmie, żeby nie otworzyć drogi do wycieku?** Lista zatwierdzonych serwerów z przypiętymi wersjami i porównywaniem definicji przy każdej aktualizacji, lokalne serwery w sandboksie, tokeny OAuth z minimalnym zakresem wydane dla konkretnego serwera. Akcje zapisujące i wysyłające zatwierdza człowiek w hoście, a każde wywołanie trafia do logu audytowego.
- **Czym różnią się tools, resources i prompts?** Tym, kto decyduje o użyciu. Narzędzia wybiera model, zasoby dołącza aplikacja, np. plik albo schemat bazy jako kontekst, prompty wybiera użytkownik, zwykle jako polecenie z ukośnikiem. Nie każdy host obsługuje wszystko: MCP connector w API Anthropic obsługuje tylko narzędzia.
- **Po co wersja 2026-07-28 usunęła sesje i initialize?** Żeby zdalny serwer skalował się jak zwykłe API. Każdy request niesie wersję i możliwości klienta, więc może trafić na dowolną instancję za load balancerem bez wspólnego stanu. Stan między wywołaniami przekazuje się jawnie: narzędzie zwraca uchwyt, a model podaje go w kolejnym wywołaniu.
- **Budujesz serwer MCP nad istniejącym REST API. Jak do tego podchodzisz?** Nie mapuj endpointów jeden do jednego. Wybierz kilka zadań, które agent naprawdę wykonuje, i zrób z nich narzędzia, które same łączą kilka wywołań API. Zwracaj tylko potrzebne pola, filtruj i stronicuj po stronie serwera, a błędy walidacji odsyłaj jako wynik z isError i wskazówką, jak poprawić argumenty.

### Źródła

- [Specyfikacja MCP, wersja 2026-07-28](https://modelcontextprotocol.io/specification/2026-07-28)
- [MCP: Client Best Practices (wyszukiwanie narzędzi, code mode)](https://modelcontextprotocol.io/docs/2026-07-28/develop/clients/client-best-practices)
- [MCP: Security Best Practices](https://modelcontextprotocol.io/docs/2026-07-28/tutorials/security/security_best_practices)
- [Invariant Labs: Tool Poisoning Attacks (2025)](https://invariantlabs.ai/blog/mcp-security-notification-tool-poisoning-attacks)
- [Linux Foundation: A2A po pierwszym roku (kwiecień 2026)](https://www.linuxfoundation.org/press/a2a-protocol-surpasses-150-organizations-lands-in-major-cloud-platforms-and-sees-enterprise-production-use-in-first-year)

---

## Wymuszanie formatu

*Agenci*

*Ostatnia zmiana: 28 września 2026*

Structured output w trybie ścisłym nie prosi modelu o format, tylko go wymusza: w każdym kroku sampler zeruje prawdopodobieństwo tokenów, które złamałyby schemat. Dostajesz gwarancję składni, nie poprawności treści.

**Po ludzku:** Formularz z polami wyboru zamiast pustej kartki. Nie da się wpisać nic spoza dozwolonych opcji, ale zaznaczyć złą kratkę nadal można. A gdy brakuje kratki na właściwą odpowiedź, zaznaczysz najbliższą.

*Interaktywny widżet na stronie: Przejdź krok po kroku przez generowanie. Zobacz, które tokeny maska wycina, i zatrzymaj się przy tokenie 4.*

### Jak działa maskowanie (constrained decoding)

- Schemat kompiluje się do automatu. Dla wyrażeń regularnych i schematów bez rekurencji wystarcza automat skończony, dla schematów rekurencyjnych i gramatyk bezkontekstowych potrzebny jest automat ze stosem. Stan automatu mówi, jakie znaki mogą paść dalej.
- Tokeny nie pokrywają się ze składnią JSON-a, jeden token to na przykład `{"` albo `":"`. Dlatego silnik (Outlines, XGrammar) wylicza dla każdego stanu automatu, które tokeny słownika są dozwolone. Pozostałe dostają logit minus nieskończoność, a sampler losuje z tego, co zostało (temat „Następny token”).
- Narzut na token jest bliski zera, bo większość sprawdzeń liczy się z góry. Płaci się przy pierwszym użyciu schematu: kompilacja dodaje opóźnienie, potem gramatyka jest cache’owana (u Anthropic 24 godziny od ostatniego użycia).

### JSON mode, structured output i tool calling

- JSON mode gwarantuje poprawny JSON, ale nie zgodność ze schematem. Tryb ścisły gwarantuje schemat: `json_schema` ze `strict: true` w OpenAI, `output_config.format` w Anthropic.
- Tool calling to ten sam JSON w innej roli: model wypisuje nazwę narzędzia i argumenty (temat „Narzędzia (function calling)”). Bez trybu ścisłego format jest tylko wyuczony, więc argumenty zwykle, ale nie zawsze, pasują do schematu. `strict: true` przy definicji narzędzia włącza to samo maskowanie. W Responses API OpenAI narzędzia są domyślnie strict, jeśli schemat na to pozwala, a jeśli nie, po cichu wracają do trybu best effort (odpowiedź pokazuje `strict: false`), więc ustawiaj flagę jawnie.
- Tryby ścisłe obsługują podzbiór JSON Schema. OpenAI wymaga, by każde pole było w `required` (pole opcjonalne to typ z `null`) i by obiekty miały `additionalProperties: false`, przy limicie 5000 pól i 10 poziomów zagnieżdżenia. Anthropic nie obsługuje m.in. schematów rekurencyjnych ani limitów długości tekstu, a dopuszcza najwyżej 20 narzędzi strict na request, 24 pola opcjonalne i 16 pól z typem unii łącznie we wszystkich schematach strict. Powyżej tych limitów API zwraca błąd „Schema is too complex for compilation”.
- Maska obejmuje tylko odpowiedź. Myślenie modelu rozumującego nie jest ograniczone, więc model może najpierw swobodnie rozumować, a potem wypełnić schemat (temat „Modele rozumujące”).

### Czego gwarancja nie obejmuje

- Treści. Model nadal może wpisać zły numer faktury albo zmyśloną datę w poprawnym formacie. Reguły biznesowe (zakresy, sumy, istnienie identyfikatorów) sprawdza kod, a błąd wraca do modelu z konkretnym komunikatem, z limitem prób.
- Odpowiedzi uciętej limitem długości (`stop_reason: "max_tokens"`, `finish_reason: "length"`) ani odmowy: OpenAI zwraca ją w osobnym polu `refusal`, Anthropic jako `stop_reason: "refusal"`. W obu przypadkach treść może nie pasować do schematu. Sprawdzaj powód zatrzymania przed parsowaniem.
- Wielkości liter w enumach u Anthropic. Wartości `enum` i `const` typu string mogą wrócić z inną wielkością liter („Conversation Topic 3” zamiast „Conversation topic 3”), ze zwykłym powodem zatrzymania i bez błędu, w odpowiedziach JSON i w wywołaniach narzędzi w trybie strict. Porównuj je bez rozróżniania wielkości liter i unikaj wartości, które różnią się tylko nią.
- Tego, co model chciał powiedzieć. Gdy najbardziej prawdopodobna odpowiedź jest poza schematem, maska wpycha model w najbliższą dozwoloną, jak phishing zamieniony na spam w widżecie. Dodaj wyjście awaryjne: wartość „inne” albo „nie wiem” i pole na komentarz.
- Jakości rozumowania. Model pisze od lewej do prawej, więc decyzja przed uzasadnieniem każe mu zdecydować, zanim cokolwiek policzy. Stawiaj pole z uzasadnieniem przed polem z decyzją i wpisz oba do `required`: Anthropic wypisuje pola wymagane przed opcjonalnymi (OpenAI zachowuje kolejność ze schematu, a i tak wymaga wszystkich pól). W badaniu „Let Me Speak Freely?” (2024) ograniczenia formatu obniżały wyniki zadań wymagających rozumowania, częściowo właśnie z tego powodu: w jednym z zadań GPT-3.5 w trybie JSON za każdym razem stawiał odpowiedź przed uzasadnieniem. Wynik jest sporny. Powtórzenie z tymi samymi promptami (.txt, „Say What You Mean”) spadku nie znalazło, a inne prace mierzą koszt samej maski, głównie przy małych modelach i ciasnych schematach (Reddy i in., 2026). Gdy ewaluacje pokazują spadek, pozwól modelowi odpowiedzieć swobodnie, a strukturę wyciągnij drugim, tanim wywołaniem.

### Sprawdź się

**Pytanie:** Jak zagwarantować, że model zwróci JSON zgodny ze schematem, i czego ta gwarancja nie obejmuje?

**Krótka odpowiedź:** W trybie ścisłym schemat kompiluje się do gramatyki, a w każdym kroku sampler zeruje prawdopodobieństwo tokenów, które by ją złamały. JSON pasuje do schematu, chyba że limit długości utnie odpowiedź albo model odmówi, co widać po powodzie zatrzymania. U Anthropic wartości enum mogą też wrócić z inną wielkością liter, więc porównuje się je bez jej rozróżniania. Gwarancja dotyczy składni, nie treści: wartości waliduje kod. Schemat dostaje wyjście awaryjne, bo ciasny enum wpycha model w najbliższą opcję, a pole z uzasadnieniem stoi przed decyzją, bo model pisze od lewej do prawej. Tool calling w trybie strict działa tak samo.

### Pytania pogłębiające

- **Czy wymuszanie formatu może obniżyć jakość?** Tak, gdy schemat każe podać decyzję przed uzasadnieniem albo nie ma opcji „inne”. Pomaga pole na rozumowanie przed decyzją, myślenie modelu rozumującego, którego maska nie obejmuje, albo dwa kroki: swobodna odpowiedź, potem ekstrakcja.
- **JSON mode, structured output czy tool calling: kiedy co?** Structured output, gdy odpowiedź ma zasilić kod. Tool calling, gdy model ma wybrać akcję spośród kilku, z trybem strict dla argumentów. JSON mode tylko tam, gdzie nie ma trybu ścisłego.
- **Jak wymusić format na własnym modelu?** vLLM i SGLang mają wbudowane silniki constrained decoding (m.in. XGrammar i llguidance): schemat zamienia się w automat, a ten w maskę tokenów na każdym kroku. Narzut na token jest mały, kosztem jest kompilacja każdego nowego schematu. Przy modelu rozumującym uruchom serwer z parserem rozumowania (np. --reasoning-parser w vLLM), inaczej gramatyka obowiązuje od pierwszego tokena i odcina myślenie.
- **JSON się parsuje, ale dane są złe. Co dalej?** Walidacja w kodzie (typy z ograniczeniami, reguły biznesowe) i ponowienie z konkretnym komunikatem błędu, z limitem prób. Powtarzający się błąd to sygnał do zmiany schematu albo promptu, a przypadek trafia do zestawu ewaluacyjnego.

### Źródła

- [Dokumentacja OpenAI: Structured Outputs](https://developers.openai.com/api/docs/guides/structured-outputs)
- [Dokumentacja Claude: structured outputs](https://platform.claude.com/docs/en/build-with-claude/structured-outputs)
- [Willard, Louf: Efficient Guided Generation for Large Language Models (arXiv)](https://arxiv.org/abs/2307.09702)
- [Let Me Speak Freely? Format restrictions and LLM performance (arXiv)](https://arxiv.org/abs/2408.02442)
- [.txt: Say What You Mean, odpowiedź na „Let Me Speak Freely?”](https://blog.dottxt.ai/say-what-you-mean.html)

---

## Harness agenta kodującego

*Agenci*

*Ostatnia zmiana: 28 września 2026*

Agent kodujący to model plus harness, czyli wszystko wokół modelu, co robi z niego działającego agenta. Model proponuje następny krok, a harness decyduje, co model widzi, co naprawdę się wykona i co da się cofnąć.

**Po ludzku:** Doświadczony fachowiec na budowie. Umiejętności ma swoje, ale resztę ustala budowa: jakie narzędzia leżą na stole, co jest w zleceniu i regulaminie, które pomieszczenia są zamknięte, kto musi się podpisać, zanim wyburzy się ścianę, i czy jest poziomica, żeby sprawdzić robotę. Ten sam fachowiec na dobrze zorganizowanej budowie i w chaosie pracuje zupełnie inaczej.

*Interaktywny widżet na stronie: Odtwórz jedno zadanie w agencie kodującym: zwroty częściowe są o 1 grosz za małe. Wyłącz jedną część harnessu, naciśnij ▶ i zobacz, co się zmienia.*

### Z czego składa się harness

- Pętla z tematu „Pętla agenta” i kilka ogólnych narzędzi: odczyt pliku, edycja przez podmianę fragmentu tekstu, komenda w powłoce, wyszukiwanie przez grep i glob. Harness waliduje każde wywołanie, wykonuje je i przycina długie wyniki: Claude Code zapisuje wynik z MCP powyżej 25 tys. tokenów do pliku i podaje modelowi ścieżkę (szczegóły Claude Code i Codex na tej stronie według stanu na wrzesień 2026).
- Instrukcje. System prompt opisuje narzędzia i zasady pracy, a na starcie każdej sesji harness wczytuje plik pamięci projektu. AGENTS.md to otwarty format, który czytają Codex, Cursor, Copilot, Jules i inne. Claude Code czyta CLAUDE.md, a AGENTS.md wtedy, gdy CLAUDE.md nie ma. Taki plik to kontekst, nie konfiguracja: model zwykle go słucha, ale nic go do tego nie zmusza.
- Planowanie. Model pisze listę zadań i je odhacza, a harness przy każdej zmianie wstawia listę na koniec kontekstu, żeby cel nie utonął w środku długiej historii. W trybie planowania agent może tylko czytać i uruchamiać komendy tylko do odczytu, dopóki nie zaakceptujesz planu.
- Zarządzanie kontekstem, opisane w temacie „Context engineering i pamięć”: czyszczenie starych wyników narzędzi, kompakcja po przekroczeniu progu i subagenci, którzy szukają we własnym oknie i oddają streszczenie. Dwa mechanizmy trzymają materiał poza oknem, dopóki nie jest potrzebny. Wyszukiwanie narzędzi zostawia w prefiksie same nazwy, a pełne definicje ładuje na żądanie; w Claude Code to ustawienie domyślne. Agent Skills, otwarty format, to katalogi z plikiem SKILL.md: w prefiksie siedzą tylko nazwa i opis, a treść dochodzi, gdy zadanie do niej pasuje (progressive disclosure).
- Uprawnienia decydują, które wywołania czekają na człowieka. W Claude Code odczyty i komendy tylko do odczytu, jak `ls`, `grep` czy `git status`, idą bez pytania, a pozostałe komendy powłoki i edycje domyślnie wymagają zgody. Do wyboru są tryby od planowania, przez akceptowanie edycji i tryb auto (każdą akcję ocenia klasyfikator), po bypass. Ograniczenia sandboksa egzekwuje system operacyjny (Seatbelt w macOS, bubblewrap w Linuksie): zapis tylko w katalogu roboczym, sieć tylko przez proxy z listą dozwolonych domen. Codex w domyślnym trybie workspace-write ma sieć wyłączoną. Potrzebne są obie warstwy: bez izolacji sieci przejęty agent wyśle twoje klucze SSH, a bez izolacji plików podrzuci coś, co później otworzy mu sieć.
- Hooki to twoje komendy w stałych punktach pętli: przed wywołaniem narzędzia (mogą je zablokować), po edycji (formatter), gdy agent chce skończyć (testy). Wykonują się zawsze, w odróżnieniu od instrukcji, którą model może pominąć. W Claude Code hook, który odrzuca wywołanie, blokuje je nawet w trybie bypass. Serwery MCP dokładają narzędzia z zewnątrz (temat „MCP”).
- Checkpointy. Claude Code zapisuje stan plików przed każdym twoim poleceniem, a `/rewind` przywraca kod, rozmowę albo jedno i drugie. Nie śledzi plików zmienionych komendami powłoki, jak `rm` czy `mv`, ani skutków poza twoim komputerem, więc prawdziwym „cofnij” zostaje git.

### Ten sam model, inny harness

- SWE-bench i Terminal-Bench mierzą model razem z harnessem. Anthropic pisał w styczniu 2025, że wyniki mocno zależą od harnessu nawet przy tym samym modelu. LangChain (luty 2026, raport o własnym produkcie) zostawił ten sam GPT-5.2-Codex i zmienił tylko system prompt, narzędzia i hooki, w tym wykrywanie pętli i listę kontrolną wymuszającą weryfikację przed końcem: wynik w Terminal-Bench 2.0 wzrósł z 52,8% do 66,5%. Działa to też w drugą stronę: wiosną 2026 trzy zmiany w Claude Code na kilka tygodni pogorszyły działanie tych samych modeli (temat „Czy model głupieje?”). Więcej maszynerii nie znaczy automatycznie lepiej: mini-SWE-agent, ok. 100 linijek Pythona z powłoką jako jedynym narzędziem, według autorów przekracza 74% w SWE-bench Verified. Wynik z rankingu opisuje parę model–harness, więc modele porównuj we własnym harnessie, na własnych zadaniach.
- Od harnessu zależy też większość rachunku. Każda tura wysyła cały kontekst od nowa, a w agentach tokenów wejściowych jest ok. 100 razy więcej niż wyjściowych. Dlatego harness układa request od części najstabilniejszej do najbardziej zmiennej: system prompt z definicjami narzędzi, potem pamięć projektu, potem rozmowa, która rośnie tylko na końcu. Odczyt z cache’u kosztuje ok. 10% ceny wejścia, a jedna zmiana blisko początku prefiksu sprawia, że cała historia znowu kosztuje pełną cenę (temat „Prompt caching”). Z tego powodu Claude Code dopisuje tryb planowania i skille jako wiadomości, a zmianę w CLAUDE.md stosuje dopiero po `/clear`, `/compact` albo restarcie, za to zmiana modelu czy kompakcja przebudowuje cache.

### Jak pracować z agentem kodującym

- Źródłem prawdy jest weryfikacja. Daj agentowi testy, sprawdzanie typów, linter i build, które uruchomi sam, najlepiej przez szybki cel w rodzaju `make test-fast`. „Gotowe” agenta to deklaracja, a kod wyjścia to fakt.
- AGENTS.md ma być krótki i konkretny: komendy do budowania, testów i lintera, konwencje, których nie widać w kodzie, i to, czego nie ruszać. Dokumentacja Claude Code radzi mniej niż 200 linii, bo dłuższy plik zjada kontekst i model słabiej się go trzyma. Reguły, które muszą obowiązywać, idą do uprawnień i hooków, nie do prozy.
- Plan przed edycją i wąskie zadanie: jeden błąd albo jedna funkcja na sesję, z jasnym kryterium końca, i czysty kontekst między niepowiązanymi zadaniami.
- Przeglądaj diff, nie podsumowanie. Przed większą zmianą zrób commit, żeby każdą edycję agenta dało się cofnąć jedną komendą.
- Poziom uprawnień dobieraj do ryzyka: tryb tylko do odczytu albo planowania w nieznanym repozytorium, akceptowanie edycji w sandboksie na co dzień, a pełna autonomia (bypass, danger-full-access) tylko w kontenerze albo maszynie wirtualnej bez sekretów i dostępu do produkcji.

### Typowe awarie agentów kodujących

- Zgubiony cel: po kilkudziesięciu turach zadanie z pierwszej wiadomości leży w środku kontekstu albo w streszczeniu. Pomagają lista zadań, notatki w plikach i krótsze sesje.
- Edycje bez testów: w trace’ach LangChain najczęstszą awarią był agent, który napisał rozwiązanie, przeczytał je jeszcze raz i skończył, niczego nie uruchamiając, a Anthropic (listopad 2025) widział agentów oznaczających funkcje jako gotowe bez testu end-to-end. Pomaga hook, który przed końcem pracy uruchamia testy.
- Context rot: jakość spada, gdy historia wypełnia się logami i starymi odczytami plików, na długo przed końcem okna (temat „Okno kontekstowe i agent”). Kompaktuj w naturalnych przerwach między zadaniami, a wyszukiwanie oddawaj subagentom.
- Prompt injection: README, komentarz w kodzie, zgłoszenie, dokumentacja zależności albo strona WWW to tekst w tym samym kontekście co twoje instrukcje (temat „Prompt injection”). W maju 2025 Invariant Labs pokazało zgłoszenie w publicznym repozytorium, przez które Claude 4 Opus z serwerem MCP GitHuba przeczytał prywatne repozytorium i opublikował jego zawartość w publicznym pull requeście. Obrona leży w harnessie: zgoda na akcje, lista dozwolonych adresów w sieci i tokeny o minimalnym zakresie.
- Koszt bez hamulca: agent ponawiający tę samą poprawkę, rozmnażający się subagenci, dziesiątki narzędzi ładowanych z góry, prefiks, który ciągle się zmienia. Ustaw w harnessie limity tur i budżetu i patrz na stosunek odczytów z cache’u do zapisów.

### Sprawdź się

**Pytanie:** Co harness dokłada do modelu w agencie kodującym i czemu ten sam model wypada różnie w dwóch harnessach?

**Krótka odpowiedź:** Harness to wszystko wokół modelu, co robi z niego agenta: pętla, kilka ogólnych narzędzi (odczyt, edycja, powłoka, wyszukiwanie), system prompt i plik projektu, np. AGENTS.md, lista zadań, zarządzanie kontekstem (czyszczenie starych wyników, kompakcja, subagenci, wyszukiwanie narzędzi), skille ładowane na żądanie, uprawnienia i sandbox, hooki oraz checkpointy. Model tylko proponuje wywołania, a harness decyduje, co model widzi, co się wykona i co da się cofnąć. Dlatego narzędzia, prompty i pętla weryfikacji zmieniają wyniki: LangChain podaje 13,7 punktu więcej w Terminal-Bench 2.0 po zmianie samego harnessu. Harness trzyma też stały prefiks pod prompt caching, a od tego zależy większość rachunku.

### Pytania pogłębiające

- **Czemu „nigdy nie rób git push” w AGENTS.md cię nie chroni?** Plik to kontekst, nie konfiguracja. Model zwykle go słucha, ale długa sesja, niejasne polecenie albo wstrzyknięty tekst mogą przeważyć. Regułę, która musi obowiązywać, egzekwuje harness: reguła deny, hook blokujący wywołanie przed wykonaniem (w Claude Code działa nawet w trybie bypass), sandbox albo token bez prawa do push.
- **Sandbox jest włączony. Jak agent może zniszczyć twoją pracę?** Sandbox ogranicza zapis do katalogu roboczego, a sieć do dozwolonych domen, i repozytorium leży w tych granicach, więc git clean -fdx albo rm -rf src przejdą. Checkpointy Claude Code nie śledzą zmian robionych komendami powłoki. Pomagają częste commity, reguła ask albo deny dla komend niszczących i osobny worktree lub kontener do ryzykownych zadań.
- **Agent melduje sukces, a CI pada. Co zmieniasz w harnessie?** Szybkie sprawdzenie, które agent uruchomi sam, z komendą wpisaną w AGENTS.md. Hook na moment, gdy agent chce skończyć: uruchamia testy i odsyła błędy modelowi jako informację zwrotną. Wynik ocenia się po kodzie wyjścia i diffie, nie po podsumowaniu. Anthropic i LangChain opisują przedwczesne „gotowe” jako jedną z najczęstszych awarii agentów kodujących.
- **Po podłączeniu trzech serwerów MCP koszt się podwoił. Czemu i co robisz?** Definicje narzędzi siedzą w prefiksie, więc płacisz za nie w każdej turze, a w harnessie, który ładuje je z góry, podłączenie serwera w trakcie sesji unieważnia cache. Pomagają wyszukiwanie narzędzi (w prefiksie zostają same nazwy), tylko serwery potrzebne do zadania i stały zestaw narzędzi przez całą sesję. Skutek sprawdza się w usage: stosunek odczytów z cache’u do zapisów.
- **Kiedy subagent jest lepszy niż praca w głównej sesji?** Przy zadaniach pobocznych, które polegają głównie na czytaniu: przeszukanie repozytorium, lektura logów, przegląd diffu. Subagent zużywa tokeny we własnym oknie i oddaje krótkie streszczenie, więc główny kontekst zostaje krótki. Edycje zależne od decyzji z głównego wątku zostają w głównej sesji, bo subagent tych decyzji nie widzi, a w Claude Code jego edycje zwykle nie trafiają do checkpointów. Łącznie subagenci zużywają więcej tokenów, nie mniej.

### Źródła

- [Sebastian Raschka: Components of a Coding Agent (kwiecień 2026)](https://magazine.sebastianraschka.com/p/components-of-a-coding-agent)
- [Anthropic: Effective harnesses for long-running agents (2025)](https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents)
- [Dokumentacja Claude Code: How Claude Code uses prompt caching](https://code.claude.com/docs/en/prompt-caching)
- [Dokumentacja OpenAI Codex: Agent approvals and security](https://learn.chatgpt.com/docs/agent-approvals-security)
- [LangChain: Improving Deep Agents with harness engineering (2026)](https://www.langchain.com/blog/improving-deep-agents-with-harness-engineering)

---

## Wielu agentów

*Agenci*

*Ostatnia zmiana: 28 września 2026*

Główny agent dzieli zadanie i zleca części subagentom, z których każdy pracuje we własnym, czystym kontekście i oddaje krótki wynik. Taki układ pomaga przy niezależnych częściach, jak badanie wielu źródeł naraz, szkodzi przy wspólnym stanie, jak zmiany w tym samym kodzie, a tokenów zużywa zwykle kilka razy więcej.

**Po ludzku:** Pięciu researcherów przejrzy dziesięć bibliotek szybciej niż jeden, jeśli każdy dostanie jasne zlecenie i odda stronę notatek. Pięciu programistów, którzy bez rozmowy ze sobą poprawiają ten sam moduł, narobi więcej szkody niż jeden, bo każdy po cichu podejmie inne decyzje. Obu zespołom płacisz za każdą godzinę.

*Interaktywny widżet na stronie: Zmień liczbę subagentów i rodzaj zadania. Patrz na czas, tokeny, kontekst głównego agenta i jakość wyniku.*

### Główny agent i subagenci

- Subagent to osobna pętla agenta (temat „Pętla agenta”), którą główny agent wywołuje jak narzędzie: argumentem jest zlecenie, wynikiem krótki raport. Subagent nie widzi historii głównego agenta, tylko swój system prompt i zlecenie. Może przeczytać dziesiątki tysięcy tokenów stron czy plików, a oddaje zwykle 1–2 tys. To izolacja kontekstu z tematu „Context engineering i pamięć”.
- Główny agent, zwany też orkiestratorem, planuje, rozdziela części, czeka i scala wyniki. W systemie badawczym Anthropic (opis z czerwca 2025) uruchamia subagentów grupami i czeka na całą grupę. To upraszcza koordynację, ale czas wyznacza najwolniejszy subagent, a działającego subagenta nie da się skorygować.
- Inne układy. Potok: stałe etapy, wynik jednego agenta jest wejściem następnego. Handoff: agent przekazuje rozmowę razem z jej stanem wyspecjalizowanemu agentowi i sam się wyłącza, na przykład obsługa klienta oddaje sprawę działowi zwrotów. Pętla krytyka: jeden agent pisze, drugi ocenia według kryteriów i odsyła uwagi, aż wynik przejdzie ocenę albo skończy się limit rund. Przy subagencie kontrolę zachowuje główny agent, przy handoffie ją oddaje.

### Kiedy subagenci pomagają

- Praca wszerz, równolegle: zadanie rozpada się na niezależne kierunki, jak wiele firm, źródeł czy hipotez. Anthropic podaje, że Claude Opus 4 jako główny agent z subagentami Claude Sonnet 4 wypadł o 90,2% lepiej niż sam Claude Opus 4 na wewnętrznym zestawie zadań badawczych. Równoległa praca subagentów i równoległe wywołania narzędzi skróciły czas złożonych zapytań nawet o 90%.
- Więcej tokenów na zadanie, niż zmieści jedno okno. W tym samym raporcie sama liczba zużytych tokenów wyjaśniała 80% różnic w wynikach na BrowseComp, benchmarku wyszukiwania trudno dostępnych informacji. Subagenci pozwalają te tokeny wydać, a do głównego agenta trafiają tylko wnioski, więc jego kontekst zostaje czysty.
- Specjalizacja: każdy subagent ma własny prompt i węższy zestaw narzędzi i uprawnień. Z krótszej listy model trafniej wybiera narzędzie (temat „Narzędzia (function calling)”). Subagent tylko do odczytu może czytać obce treści bez dostępu do ryzykownych akcji, ale jego raport nadal może przenieść wstrzyknięte polecenie do głównego agenta (temat „Prompt injection”).

### Kiedy subagenci szkodzą

- Koszt i opóźnienie. W danych Anthropic agent zużywa ok. 4 razy więcej tokenów niż czat, a system wieloagentowy ok. 15 razy więcej. Każdy subagent płaci za własny system prompt, narzędzia i zlecenie. Startuje od zera, więc najpierw sam zbiera kontekst, który główny agent już miał.
- Utracony kontekst i zdublowana praca. Subagent wie tylko to, co jest w zleceniu, a każde streszczenie gubi szczegóły. Wczesna wersja systemu Anthropic zlecała krótko, na przykład „zbadaj niedobór półprzewodników”. Jeden subagent badał kryzys w motoryzacji z 2021 roku, a dwóch innych zdublowało pracę nad łańcuchami dostaw z 2025 roku.
- Sprzeczne decyzje we wspólnym stanie. Każda akcja zawiera ukryte decyzje, a równolegli agenci nie widzą decyzji pozostałych (Cognition, „Don’t Build Multi-Agents”, czerwiec 2025). W przykładzie Cognition z klonem Flappy Bird jeden subagent zrobił tło w stylu Super Mario, drugi ptaka w innym stylu, a główny agent musiał to skleić. W kodzie to te same pliki edytowane naraz, różne nazwy i typy, konflikty przy scalaniu. Anthropic sam zaznacza, że większość zadań programistycznych ma mniej naprawdę równoległych części niż badanie.
- Błędy się sumują, a debugowanie jest trudne. Zły podział u głównego agenta psuje wszystkie gałęzie naraz, a drobna zmiana jego promptu potrafi nieprzewidywalnie zmienić zachowanie subagentów. Cemri i in. (2025) przeanalizowali ponad 1600 trace’ów z 7 frameworków i opisali 14 typów awarii w trzech grupach: projekt systemu, rozjazd między agentami, weryfikacja wyniku. Zyski systemów wieloagentowych na popularnych benchmarkach były często minimalne.

### Jak budować system wieloagentowy

- Zacznij od jednego agenta z narzędziami, tak radzi też przewodnik OpenAI. Kolejnych agentów dodaj, gdy na tym samym zestawie ewaluacji pokażesz zysk wart dodatkowych tokenów (temat „Ewaluacje”). Przy kodzie zwykle wystarcza subagent tylko do odczytu, który przeszuka repozytorium i odpowie na konkretne pytanie, a zmiany robi jeden agent. Wyjątkiem jest duża zmiana, która rozpada się na niezależne części, np. migracja moduł po module: każdy piszący subagent pracuje we własnym git worktree albo sandboksie, na własnej gałęzi, uruchamia testy, a jego zmianę scala się jak zwykły PR (tak działa `/batch` w Claude Code). Każdą część nadal zmienia jeden agent: tę samą regułę opisuje Cognition w tekście z kwietnia 2026.
- Zlecenie od głównego agenta to specyfikacja: cel, format wyniku, narzędzia i źródła, granice (czego nie robić, co robią inni) i budżet wysiłku. Anthropic wpisał do promptu reguły skalowania: proste pytanie to 1 agent i 3–10 wywołań narzędzi, porównanie to 2–4 subagentów po 10–15 wywołań, złożone badanie to ponad 10 subagentów. Przy zmianie w kodzie wspólny kontrakt, czyli nazwy, typy i interfejsy, ustala się przed podziałem pracy.
- Duże wyniki przekazuj przez pliki albo magazyn, nie przez wiadomości. Subagent zapisuje artefakt i zwraca ścieżkę z krótkim opisem, więc treść nie przechodzi przez kolejne streszczenia. Główny agent też zapisuje plan poza kontekstem, bo przy długiej pracy okno się skończy.
- Limitów pilnuje kod, nie prompt: liczba subagentów, głębokość zagnieżdżenia, budżet tokenów i czasu na subagenta, liczba rund pętli krytyka. Wczesne wersje systemu Anthropic uruchamiały 50 subagentów do prostych pytań. Anthropic ograniczył to głównie regułami skalowania w prompcie, a twardy limit w kodzie jest zabezpieczeniem na wypadek, gdy model ich nie posłucha. Claude Code (stan na wrzesień 2026) domyślnie pozwala na trzy poziomy zagnieżdżenia i najwyżej 20 subagentów naraz (temat „Harness agenta kodującego”).
- Jeden trace na całe zadanie, z osobnym fragmentem dla każdego subagenta: zlecenie, wywołania, tokeny, wynik. Tylko tak ustalisz, czy zawiódł podział, subagent czy scalanie. Oceniaj stan końcowy, na przykład fakty i źródła w raporcie albo przechodzące testy, a nie podsumowanie głównego agenta (temat „Pętla agenta”).

### Sprawdź się

**Pytanie:** Kiedy zbudujesz system z wieloma agentami, a kiedy zostaniesz przy jednym?

**Krótka odpowiedź:** Zaczyna się od jednego agenta. Kolejnych dodaje się, gdy zadanie rozpada się na niezależne części, jak badanie wielu źródeł: główny agent rozdziela je subagentom, każdy pracuje równolegle we własnym, czystym kontekście i oddaje krótkie streszczenie. Zysk to szybkość, szersze pokrycie i czysty kontekst głównego agenta. Cena to tokeny, u Anthropic ok. 15 razy więcej niż czat, oraz koordynacja. Przy wspólnym stanie, jak zmiany w tym samym kodzie, agenci podejmują sprzeczne decyzje, więc tam zmiany robi jeden agent. Rozstrzygają ewaluacje stanu końcowego.

### Pytania pogłębiające

- **Subagent nie wie, co ustalili inni. Jak temu zaradzić?** Albo przekazać mu pełny kontekst i dotychczasowe decyzje, co zjada zysk z izolacji, albo ustalić wspólne rzeczy przed podziałem: nazwy, typy, format wyniku, zakres każdej części. Jeśli tego nie da się ustalić z góry, części nie są niezależne i lepiej zrobi to jeden agent.
- **Główny agent odpala 50 subagentów do prostego pytania. Co robisz?** To prawdziwy błąd z wczesnego systemu Anthropic. Do promptu trafiają reguły skalowania: ile subagentów i wywołań na jaki typ pytania. Kod dokłada twarde limity liczby subagentów, głębokości i budżetu tokenów, a zmianę sprawdzają ewaluacje.
- **Jak przekazywać duże wyniki między agentami?** Przez pliki albo magazyn: subagent zapisuje artefakt i zwraca ścieżkę z krótkim opisem. Szczegóły nie giną w kolejnych streszczeniach, a kontekst głównego agenta zostaje mały.
- **Czym handoff różni się od wywołania subagenta?** Subagent działa jak narzędzie: główny agent czeka na wynik i zachowuje kontrolę. Handoff przekazuje rozmowę razem z jej stanem innemu agentowi, który dalej sam rozmawia z użytkownikiem. Handoff pasuje do kierowania sprawy do specjalisty, subagent do dzielenia zadania na części.
- **Jak debugować i oceniać system wieloagentowy?** Jeden identyfikator trace’a na całe zadanie i osobny fragment dla każdego subagenta ze zleceniem, wywołaniami i tokenami. Stan końcowy ocenia się na stałym zestawie i porównuje z jednym agentem, bo drobna zmiana promptu głównego agenta potrafi zmienić zachowanie wszystkich subagentów.

### Źródła

- [Anthropic: How we built our multi-agent research system](https://www.anthropic.com/engineering/multi-agent-research-system)
- [Cognition: Don’t Build Multi-Agents](https://cognition.com/blog/dont-build-multi-agents)
- [OpenAI: A practical guide to building agents (PDF)](https://cdn.openai.com/business-guides-and-resources/a-practical-guide-to-building-agents.pdf)
- [Cemri i in.: Why Do Multi-Agent LLM Systems Fail? (arXiv, 2025)](https://arxiv.org/abs/2503.13657)
- [Cognition: Multi-Agents: What’s Actually Working (kwiecień 2026)](https://cognition.com/blog/multi-agents-working)

---

## Halucynacje

*Jakość i bezpieczeństwo*

*Ostatnia zmiana: 28 września 2026*

Model nie ma trybu „nie wiem”: zawsze dopisze prawdopodobny ciąg dalszy, równie pewnym tonem, gdy zna odpowiedź i gdy zgaduje. Halucynacji nie da się wyłączyć, da się je ograniczać i mierzyć.

**Po ludzku:** Student, który na egzaminie ustnym nigdy nie mówi „nie wiem”. Gdy zna odpowiedź, mówi płynnie i pewnie. Gdy nie zna, mówi tak samo płynnie i pewnie, więc po tonie nie poznasz różnicy.

*Interaktywny widżet na stronie: Włączaj źródło w kontekście i zgodę na „nie wiem”, osobno i razem. Patrz, które zmyślenia znikają, które zostają i ile odpowiedzi przy tym tracisz.*

### Skąd się biorą halucynacje

- Model przewiduje następny token i zawsze jakiś zwróci. Nie ma osobnego sygnału „tu kończy się moja wiedza”, a zgadnięte zdanie jest tak samo gładkie jak prawdziwe. Wylosowanego tokena nie da się cofnąć: jeśli odpowiedź zaczęła się od „W 1978 roku”, reszta zdania będzie ten rok uzasadniać (temat „Następny token”).
- Fakty, które w danych treningowych pojawiły się raz albo wcale, są w wagach zapisane słabo albo wcale. Stolicę Australii model widział tysiące razy, rok otwarcia małego muzeum najwyżej raz. Kalai i in. (OpenAI, 2025) pokazują, że dla faktów bez wzorca, takich jak daty urodzenia, odsetek halucynacji po pretrainingu wynosi w przybliżeniu co najmniej tyle, ile odsetek faktów, które w danych wystąpiły dokładnie raz.
- Post-training tego nie usuwa, bo prawie wszystkie popularne benchmarki oceniają 0/1: za „nie wiem” dają zero, tak samo jak za błąd. Przy takiej ocenie wstrzymanie się nigdy nie jest optymalne, więc model trenowany i wybierany pod wynik uczy się zgadywać, jak uczeń na teście bez punktów ujemnych.

### Rodzaje halucynacji

- Zmyślony fakt: zła data, liczba albo nazwisko podane pewnym tonem. Zmyślone źródło: tytuł pracy, wyrok, link albo cytat, których nie ma. W 2023 roku sąd federalny w Nowym Jorku ukarał prawników grzywną 5000 USD za pismo z wyrokami wymyślonymi przez ChatGPT (sprawa Mata v. Avianca).
- Niewierność źródłu: dokument leży w kontekście, a odpowiedź mu przeczy albo dodaje coś, czego w nim nie ma. W RAG to typowy błąd etapu generowania, groźny, bo przypis sprawia, że odpowiedź wygląda na sprawdzoną. Błąd rozumowania: fakty się zgadzają, ale rachunek jest zły albo wniosek nie wynika z przesłanek.
- W agencie: wywołanie narzędzia z wymyślonym argumentem (identyfikator klienta, ścieżka pliku, nazwa pola) albo meldunek „wysłałem maila”, „testy przechodzą”, choć żadne narzędzie tego nie zrobiło. W kodzie: funkcje, parametry i całe pakiety, które nie istnieją. Atakujący może zarejestrować pakiet o zmyślanej przez modele nazwie i czekać, aż agent go zainstaluje.

### Co pomaga i gdzie są granice

- Źródło w kontekście z przypisami (temat „RAG”) pomaga najbardziej, ale tylko wtedy, gdy wyszukiwanie znajdzie fragment z odpowiedzią. Do tego jawna zgoda na „nie wiem” i polecenie „najpierw wypisz dosłowne cytaty ze źródła, potem odpowiedz tylko na ich podstawie”. Cytat da się sprawdzić zwykłym wyszukiwaniem tekstu. Ceną jest to, że model odpowie na mniej pytań.
- Narzędzia zamiast pamięci: kod albo kalkulator do rachunków, wyszukiwarka i baza do faktów, dokumentacja do API (temat „Narzędzia (function calling)”). Drugi krok sprawdzający, czyli osobne wywołanie, które czyta odpowiedź razem ze źródłami i skreśla twierdzenia bez pokrycia, łapie część błędów, ale sam też się myli.
- Niższa temperatura nie leczy: temperatura 0 wybiera najbardziej prawdopodobny token, więc zmyślona data staje się po prostu powtarzalna. Rozumowanie przed odpowiedzią (temat „Modele rozumujące”) pomaga w logice i rachunkach, bo model może sprawdzić kroki, ale wiedzy, której nie ma w wagach, nie doda. Fine-tuning słabo się do tego nadaje: nowe fakty model przyswaja powoli, a gdy już je przyswoi, rośnie jego skłonność do zmyślania (Gekhman i in., 2024).

### Próg pewności i pomiar

*Interaktywny widżet na stronie: Przesuwaj próg pewności, poniżej którego model mówi „nie wiem”. Porównaj punkty w ocenie 0/1 i w ocenie z karą za błąd i sprawdź, przy której opłaca się wstrzymać.*

- Próg wybierasz pod koszt pomyłki i mierzysz na własnym zestawie (temat „Ewaluacje”): osobno poprawne, błędne i wstrzymane, plus pytania, na które w źródłach celowo nie ma odpowiedzi. Sama trafność nagradza zgadywanie, sam odsetek błędów nagradza milczenie.
- Pewność modelu z `logprobs` nie jest miernikiem prawdy. Model bywa pewny błędu, pewność rozkłada się na różne sformułowania tej samej odpowiedzi, a post-training psuje kalibrację: w raporcie o GPT-4 model bazowy był dobrze skalibrowany na pytaniach z MMLU, a po post-trainingu wyraźnie gorzej. Bez źródeł lepszy sygnał daje spójność: kilka próbek odpowiedzi na to samo pytanie i sprawdzenie, czy znaczą to samo (semantic entropy, Farquhar i in., Nature 2024). Zgadnięte fakty zmieniają się między próbkami, znane zostają.
- Wierność i przypisy sprawdzasz kodem. Najpierw, czy cytowany fragment dosłownie istnieje w dokumencie. Natywne cytowania w API, np. w Claude, gwarantują poprawny wskaźnik do dokumentu, ale nie to, że fragment popiera twierdzenie. Potem, twierdzenie po twierdzeniu, czy fragment je potwierdza: model NLI albo sędzia-LLM z oceną tak/nie.

### Sprawdź się

**Pytanie:** Skąd biorą się halucynacje i jak je ograniczasz oraz mierzysz na produkcji?

**Krótka odpowiedź:** Model zawsze generuje prawdopodobny ciąg dalszy i nie ma wbudowanego „nie wiem”, więc przy rzadkich faktach zgaduje tym samym pewnym tonem. Trening i benchmarki oceniane 0/1 nagradzają trafienie, a za wstrzymanie dają zero, więc zgadywanie się opłaca. Nie da się tego wyłączyć, można ograniczać: źródła z przypisami w kontekście, zgoda na „nie wiem”, narzędzia do faktów i rachunków, sprawdzanie cytatów kodem. Niższa temperatura tylko powtarza ten sam strzał. Mierz osobno błędy, wstrzymania i wierność źródłom, a próg odpowiadania ustawiaj pod koszt pomyłki.

### Pytania pogłębiające

- **Czy da się wykryć halucynację po logprobs?** Częściowo. Niska pewność bywa sygnałem, ale model potrafi być pewny błędu, pewność rozkłada się na różne sformułowania tej samej odpowiedzi, a post-training psuje kalibrację. Lepszy sygnał daje kilka próbek i sprawdzenie, czy znaczą to samo.
- **Czemu system z RAG nadal zmyśla?** Wyszukiwarka zawsze coś zwraca. Jeśli fragment nie zawiera odpowiedzi, model często uzupełnia lukę z wag i dokleja przypis do najbliższego źródła. Do tego potrafi przekręcić fragment, który ma przed sobą.
- **Agent melduje „testy przechodzą”, a nie przechodzą. Co robisz?** Nie ufasz meldunkom, tylko sprawdzasz stan. Testy uruchamia kod i odsyła wynik modelowi, a warunek końca zadania sprawdza narzędzie, nie deklaracja modelu. W ewaluacji oceniasz stan końcowy, a przebiegi z fałszywym meldunkiem dopisujesz do zestawu jako nowe przypadki.
- **Jak zmierzyć halucynacje we własnym systemie?** Zestaw pytań ze sprawdzoną odpowiedzią plus pytania, na które w źródłach odpowiedzi nie ma. Liczysz osobno poprawne, błędne i wstrzymane, a dla RAG także wierność: czy każde twierdzenie ma pokrycie w podanym fragmencie.

### Źródła

- [Kalai i in.: Why Language Models Hallucinate (arXiv, 2025)](https://arxiv.org/abs/2509.04664)
- [Dokumentacja Claude: Reduce hallucinations](https://platform.claude.com/docs/en/test-and-evaluate/strengthen-guardrails/reduce-hallucinations)
- [Lilian Weng: Extrinsic Hallucinations in LLMs](https://lilianweng.github.io/posts/2024-07-07-hallucination/)

---

## Ewaluacje

*Jakość i bezpieczeństwo*

*Ostatnia zmiana: 28 września 2026*

Wynik LLM-a jest losowy i czuły na drobne zmiany promptu, więc „sprawdziłem na trzech przykładach” nic nie znaczy. Ewaluacja to stały zestaw przypadków z automatyczną oceną, puszczany po każdej zmianie promptu, modelu i narzędzi, plus pomiar jakości na ruchu produkcyjnym.

**Po ludzku:** Testy w CI dla kodu, który za każdym razem odpowiada trochę inaczej. Zamiast „przeszedł albo nie” liczysz, ile razy na pięć przeszedł, a części asercji nie da się zapisać jako porównania napisów, więc sprawdza je drugi model, którego najpierw sam sprawdzasz.

*Interaktywny widżet na stronie: Poprawiony prompt v2 podnosi wynik z 5 do 7 na 8. Sprawdź w tabeli, co ta liczba ukrywa, potem włącz pięć powtórzeń każdego przypadku i zobacz, która zmiana była szumem.*

### Zestaw testowy i metody oceny

- Zaczynasz od analizy błędów, nie od metryk: czytasz 50–100 trace’ów, notujesz każdy problem, grupujesz notatki w typy pomyłek i liczysz je. Najczęstsze typy mówią, co naprawić i co testować. Husain i Shankar przeznaczają na analizę błędów i ewaluację 60–80% czasu pracy, głównie na czytanie danych, a nie na automatyczne testy.
- Zestaw, czyli golden set, budujesz z tych błędów, nie z wyobraźni: każdy typ zamieniasz w kilka przypadków z oczekiwanym wynikiem albo kryterium oceny. Anthropic radzi zacząć od 20–50 zadań. Każdy błąd z produkcji dopisujesz jako nowy przypadek, a do tego przypadki brzegowe i pytania bez odpowiedzi.
- Dopóki nie masz ruchu, zasilasz zestaw przypadkami syntetycznymi: wypisujesz wymiary zapytania (typ użytkownika, intencja, trudność), kilka kombinacji piszesz ręcznie, model je rozmnaża i zamienia każdą w realistyczne wejście, a ty czytasz trace’y, które z nich powstały. Syntetyczne przypadki nie powiedzą, jak częsty jest błąd, wychodzą czystsze niż zapytania prawdziwych użytkowników i gubią niuanse wąskich dziedzin i rzadkich języków, więc zastępujesz je prawdziwymi trace’ami, gdy pojawi się ruch.
- Nie każdy błąd potrzebuje automatycznej oceny. Najpierw naprawiasz oczywiste luki, na przykład brakującą instrukcję w prompcie, a automatyczną ocenę dodajesz tylko dla błędów, które zostają: sędzia-LLM kosztuje czas na zbudowanie i walidację oraz pieniądze przy każdym uruchomieniu.
- Red-teaming to celowy zestaw ataków: ludzie albo model-atakujący próbują złamać system przez prompt injection, jailbreaki, prośby niezgodne z zasadami i wyciąganie danych. Trzymasz go osobno od ewaluacji jakości, raportujesz odsetek udanych ataków i puszczasz przy każdym wydaniu (temat „Prompt injection”).
- Oceniasz najtańszą metodą, która wystarczy do sprawdzenia kryterium: dokładne dopasowanie, schemat albo regex, test w kodzie (uruchom, sprawdź stan), model jako sędzia, człowiek. Jedno kryterium na ocenę i wynik tak/nie zamiast skali 1–10, bo skalę każdy oceniający, także model, stosuje inaczej. Gotowe metryki, jak „helpfulness”, BERTScore czy ROUGE, pomijasz: mierzą coś innego niż twoje błędy i dają fałszywe poczucie jakości.
- Sędziego-LLM sprawdzasz na ludzkich ocenach, zanim zaufasz jego liczbom. Sama zgodność myli: gdy 90% odpowiedzi jest dobrych, sędzia, który wszystko przepuszcza, zgadza się w 90% przypadków i nie łapie żadnego błędu. Dlatego ekspert ocenia 100–200 przykładów, a ty mierzysz osobno, jaką część błędów sędzia łapie (TPR) i jaką część dobrych odpowiedzi przepuszcza (TNR), prompt sędziego poprawiasz na jednej części ocen, a sprawdzasz na drugiej. Znane skrzywienia: sędzia woli odpowiedź pokazaną jako pierwszą, dłuższą i we własnym stylu (Zheng i in., 2023). Wersję sędziego przypinasz, a po jej zmianie kalibrujesz od nowa.
- System oceniasz po kawałkach i w całości. W RAG osobno wyszukiwanie (recall@k, czyli jaka część właściwych fragmentów jest w pierwszych k wynikach) i generowanie (wierność fragmentom, temat „RAG”). W agencie oceniasz stan końcowy, a nie sztywną sekwencję kroków, plus twarde ograniczenia na trace’ie: żadnych zakazanych wywołań narzędzi ani naruszeń zasad, limity tur i kosztu. W długiej rozmowie albo przebiegu agenta szukasz pierwszego błędu, bo późniejsze zwykle z niego wynikają.

### Szum i powtórzenia

- Ten sam przypadek raz przechodzi, raz nie, nawet przy temperaturze 0: obliczenia na serwerze dają nieco inne liczby zależnie od rozmiaru batcha, a ten zmienia się z obciążeniem. Każdy przypadek puszczasz kilka razy i liczysz odsetek.
- Mała próbka to duży szum. Przy 50 przypadkach i wyniku ok. 80% przedział ufności 95% ma ok. ±11 punktów procentowych, więc różnica 3 punktów między promptami nic nie znaczy. Pomaga porównanie w parach, na tych samych przypadkach, i patrzenie na przypadki, które zmieniły wynik, a nie tylko na średnią (Miller, „Adding Error Bars to Evals”, 2024).
- Agenta opisują dwie miary. pass@k: czy zrobi zadanie choć raz na k prób, co ma sens, gdy wynik da się sprawdzić i wybrać, np. kod z testami. pass^k: czy zrobi je we wszystkich k próbach, czyli niezawodność, której oczekuje użytkownik. Przy 90% sukcesu w pojedynczej próbie pass@3 to 99,9%, a pass^3 tylko 73%. W τ-bench (2024) GPT-4o miał pass^8 poniżej 25% w obsłudze klienta sklepu.

### Ewaluacje offline, bramka w CI i pomiar na produkcji

- Offline trzymasz dwa rodzaje zestawów. Ewaluacje możliwości zaczynają od niskiego wyniku i pokazują, czy zmiana przybliża cel. Ewaluacje regresji trzymają ok. 100% i łapią to, że coś, co działało, przestało. Zestaw, który zawsze daje 100%, nie mówi nic o postępie, więc dokładasz trudniejsze przypadki.
- Zestaw regresji to bramka w CI. Uruchamiasz go przy każdej zmianie promptu, modelu, definicji narzędzi i konfiguracji wyszukiwania, bo każda zmienia zachowanie. W pull requeście szybki podzbiór z ocenami w kodzie, pełny zestaw z sędzią-LLM co noc albo przed wydaniem. Bramka blokuje, gdy przypadek krytyczny zaczyna padać albo wynik spada poniżej progu z marginesem na szum, i pilnuje też kosztu i opóźnienia.
- Na produkcji guardrail blokuje albo poprawia odpowiedź, zanim zobaczy ją użytkownik, więc musi być szybki i precyzyjny; oceniający mierzy jakość po fakcie. Oczekiwanych odpowiedzi nie ma, więc mierzysz inaczej: sędzia bez wzorca na próbce ruchu (wierność źródłom, format, bezpieczeństwo), sygnały z zachowania (poprawki użytkownika, ponowienia, eskalacje do człowieka, oceny kciukiem) i testy A/B albo canary przy zmianie modelu. Stały zestaw puszczany cyklicznie na przypiętej wersji wykrywa zmiany po stronie dostawcy (temat „Czy model głupieje?”). Nieudane trace’y z produkcji wracają do zestawu offline.
- Publiczne rankingi mówią, który model warto sprawdzić, a nie czy zadziała u ciebie: mierzą cudze zadanie, ich pytania często wyciekły do danych treningowych, a wyniki szybko dochodzą do sufitu.

### Sprawdź się

**Pytanie:** Jak sprawdzasz, czy system z LLM-em działa i czy zmiana go nie zepsuła?

**Krótka odpowiedź:** Zbuduj stały zestaw przypadków z prawdziwych błędów: czytaj trace’y, nazwij typy pomyłek i każdy zamień w test. Oceniaj najtańszą wystarczającą metodą: dopasowanie, test w kodzie, sędzia-LLM sprawdzony na ocenach eksperta, człowiek. Każdy przypadek puszczaj kilka razy, bo wynik jest losowy, a wersje porównuj w parach. Zestaw regresji jest w CI bramką dla każdej zmiany promptu, modelu i narzędzi. Na produkcji oceniaj próbkę ruchu sędzią bez wzorca i patrz na sygnały użytkowników, a nieudane przypadki wracają do zestawu.

### Pytania pogłębiające

- **Jak zacząć, gdy nie masz jeszcze zestawu testowego?** Od analizy błędów na 50–100 prawdziwych przykładach: czytasz odpowiedzi, nazywasz typy pomyłek i z nich robisz przypadki testowe. Na start wystarczy 20–50 przypadków, byle z prawdziwych porażek.
- **Kiedy ufać modelowi jako sędziemu?** Gdy jego oceny zgadzają się z oceną eksperta na próbce kontrolnej, liczone osobno dla dobrych i złych odpowiedzi. Sędzia, który wszystko przepuszcza, też ma wysoką trafność, gdy dobrych odpowiedzi jest większość. Daj mu jedno kryterium i ocenę tak/nie, a w porównaniu dwóch odpowiedzi zamieniaj ich kolejność.
- **Jak ustawić bramkę w CI, żeby nie blokowała przez szum?** W bramce trzymasz stabilne przypadki regresji z wynikiem bliskim 100% i puszczasz każdy kilka razy. Blokujesz, gdy przypadek krytyczny wyraźnie spada albo średnia spada o więcej niż margines szumu. Niestabilne przypadki, które bez żadnej zmiany raz przechodzą, a raz nie, przenosisz do kwarantanny i badasz, zamiast luzować próg.
- **Jak ewaluować agenta?** Testem stanu końcowego, a nie podsumowaniem agenta, każde zadanie kilka razy, z pass^k jako miarą niezawodności. Do tego koszt, liczba tur i czas na zadanie. Trace’y pokazują, gdzie agent błądzi. Ścieżki nie oceniasz sztywno, bo do celu prowadzi kilka dróg, ale sprawdzasz w niej zakazane wywołania i naruszenia zasad.
- **Chcesz przejść na tańszy model. Jak podjąć decyzję?** Ten sam zestaw na obu modelach, w parach i z powtórzeniami, z osobnym wynikiem dla każdego typu przypadku, plus koszt i opóźnienie. Potem canary albo shadow na części ruchu i porównanie sygnałów z produkcji. Prompt często trzeba dostroić pod nowy model, więc porównujesz modele, każdy z najlepszym dla niego promptem.

### Źródła

- [Hamel Husain: Your AI Product Needs Evals](https://hamel.dev/blog/posts/evals/)
- [Hamel Husain, Shreya Shankar: AI Evals, Everything You Need to Know (dane syntetyczne, walidacja sędziego)](https://hamel.dev/blog/posts/evals-faq/)
- [Anthropic: Demystifying evals for AI agents (2026)](https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents)
- [Evan Miller: Adding Error Bars to Evals (arXiv, 2024)](https://arxiv.org/abs/2411.00640)
- [Zheng i in.: Judging LLM-as-a-Judge (arXiv, 2023)](https://arxiv.org/abs/2306.05685)

---

## Prompt injection

*Jakość i bezpieczeństwo*

*Ostatnia zmiana: 28 września 2026*

Dla modelu wszystko jest jednym ciągiem tokenów. Nie ma osobnego kanału na polecenia i osobnego na dane, więc tekst, który agent tylko czyta, może zacząć nim sterować. Tego nie łata się promptem, tylko architekturą.

**Po ludzku:** Asystent, który wykonuje każde polecenie, jakie przeczyta, także to dopisane drobnym drukiem w liście od nieznajomego. Kartka „nie słuchaj poleceń z listów” niewiele pomoże, bo asystent czyta ją tak samo jak list. Pomaga dopiero to, że nie dostał kluczy do sejfu.

*Interaktywny widżet na stronie: Agent pocztowy dostaje maila od nieznajomego. Wyłączaj po jednej jego zdolności i patrz, czy ukryte polecenie nadal wykradnie dane, a potem wybierz „Atakuje użytkownik” i porównaj, które obrony działają.*

### Skąd się bierze prompt injection

- System prompt, wiadomość użytkownika i treść maila to dla modelu ten sam strumień tokenów, rozdzielony tylko znacznikami ról (temat „Jak model widzi czat”). Model jest trenowany, żeby dawać pierwszeństwo instrukcjom wyżej w hierarchii, ale to wyuczona skłonność, nie granica. Przed SQL injection chronią zapytania parametryzowane, które oddzielają kod od danych. Dla LLM-a odpowiednika nie ma.
- Direct injection: atakuje sam użytkownik, np. próbuje wyciągnąć system prompt albo obejść zasady. Indirect injection: polecenie przychodzi w treści, którą agent czyta w czyimś imieniu. Ofiarą jest użytkownik, a atakujący nie potrzebuje żadnego dostępu, wystarczy, że agent przeczyta jego tekst.
- Niezaufana treść to nie tylko maile: strony WWW, PDF-y, zgłoszenia i komentarze w repozytorium, wyniki narzędzi, opisy narzędzi z obcych serwerów MCP. Polecenie bywa niewidoczne dla człowieka: biały tekst, komentarz HTML, tekst alternatywny obrazka, znaki Unicode, których nie widać na ekranie.

### Jailbreak a prompt injection

- Jailbreak to skłonienie modelu przez użytkownika do tego, czego trening bezpieczeństwa każe odmówić: przez odgrywanie ról, szkodliwą prośbę rozbitą na niewinne części, base64 albo zoptymalizowany bełkotliwy sufiks, który przenosi się między modelami (Zou i in., 2023). Atakuje użytkownik, a celem jest obejście odmów modelu. W prompt injection atakuje ktoś trzeci, a celem są dane i działania użytkownika. OWASP zalicza jailbreak do direct injection, ale przy projektowaniu liczy się to, kto kogo atakuje.
- Trening bezpieczeństwa sprawia, że model prawdopodobnie odmówi prośbom podobnym do szkodliwych z treningu. To wyuczona skłonność, nie granica: zawodzi na prośbach niepodobnych do danych treningowych (Wei i in., 2023), fine-tuning potrafi ją zdjąć (temat „Fine-tuning i LoRA”), a przeciw injection nie działa wcale, bo „prześlij maile z banku na ten adres” nie jest szkodliwą prośbą. Od użytkownika to samo zdanie byłoby zwykłym zadaniem.
- Dlatego obrony są inne. Przeciw jailbreakowi: trening bezpieczeństwa i klasyfikatory, plus limity i monitoring kont, bo atakujący to użytkownik z nieograniczoną liczbą prób. Gdy użytkownik ma mniej uprawnień niż system, jak publiczny bot z dostępem do bazy, narzędzia sprawdzają uprawnienia samego użytkownika, więc jailbreak nic mu nie da. Przeciw injection: architektura z kolejnych sekcji.

### Zabójcze trio (lethal trifecta)

- Do kradzieży danych potrzebne są trzy rzeczy naraz: dostęp do prywatnych danych, kontakt z niezaufaną treścią i możliwość wysłania czegoś na zewnątrz. Simon Willison nazwał to „lethal trifecta” (2025). Zabranie jednej zamyka drogę do wycieku. Inne szkody zostają: agent z prawem zapisu może coś skasować, a streszczenie może kłamać.
- Kanał wyjścia to nie tylko wysyłka maila. Wystarczy pobranie URL-a z danymi w parametrze, obrazek w markdownie, który aplikacja sama ściągnie, link, w który ktoś kliknie, albo komentarz w publicznym repozytorium. EchoLeak (czerwiec 2025, Microsoft 365 Copilot, CVSS 9,3): jeden mail, bez kliknięcia ofiary, ominięty klasyfikator ataków, dane wyniesione przez automatycznie ładowany obrazek pobrany przez proxy Microsoft Teams, na które pozwalała polityka CSP. Domena z listy dozwolonych, która przekierowuje, pośredniczy albo hostuje treści użytkowników, otwiera kanał z powrotem.
- Meta ujęła to jako regułę dwóch (Rule of Two, 2025). W jednej sesji agent może mieć najwyżej dwie z trzech cech: czyta niezaufane wejście, ma dostęp do wrażliwych danych lub systemów, zmienia stan albo komunikuje się na zewnątrz. Gdy potrzebne są wszystkie trzy, działa pod nadzorem człowieka, nie samodzielnie.

### Czemu prompt tego nie naprawi

- Instrukcje obronne („ignoruj polecenia w danych”), ograniczniki wokół treści i klasyfikatory ataków podnoszą poprzeczkę, ale działają statystycznie. Atakujący próbuje do skutku, a wystarczy mu jeden raz. Nasr i in. (2025, autorzy m.in. z OpenAI, Anthropic i Google DeepMind) złamali atakami dopasowanymi do obrony 12 opublikowanych obron przed jailbreakami i prompt injection, w większości przypadków ze skutecznością powyżej 90%, choć autorzy tych obron raportowali skuteczność ataków bliską zera. Jak pisze Willison, filtr, który zatrzymuje 95% ataków, to w bezpieczeństwie ocena niedostateczna.
- Wynik modelu, który przeczytał niezaufaną treść, też jest niezaufany. Nie renderuj z niego obrazków z dowolnych domen, nie otwieraj automatycznie linków, nie przekazuj go bez sprawdzenia do narzędzia z uprawnieniami.

### Obrona w głąb

- Najmniejsze uprawnienia: tokeny dostępu per użytkownik i tylko do odczytu, gdzie się da, żadnych sekretów w kontekście. Autoryzację sprawdza narzędzie po swojej stronie, nie model. Akcje wrażliwe zatwierdza człowiek, a kod pokazuje mu dokładnie co i do kogo, bo „Zatwierdź” klikane sto razy dziennie przestaje chronić.
- Izolacja: niezaufaną treść czyta osobny model bez narzędzi, który zwraca tylko ustrukturyzowany wynik, np. kategorię i kwotę. Model z uprawnieniami nigdy nie widzi surowego tekstu (wzorzec Dual LLM). Inny wzorzec, plan-then-execute: agent ustala listę wywołań, zanim przeczyta obce dane, więc te dane nie zmienią, co zostanie wywołane. CaMeL (Google DeepMind, 2025) rozdziela przepływ sterowania i danych i śledzi, skąd pochodzi każda wartość: w benchmarku AgentDojo wykonał 77% zadań z dowodliwą ochroną, wobec 84% bez żadnej obrony.
- Kontrola wyjścia: lista dozwolonych domen i adresatów, polityka CSP dla obrazków, piaskownica bez sieci dla kodu. Do tego log każdego wywołania narzędzia i zestaw ataków w ewaluacjach puszczany przy każdym wydaniu (temat „Ewaluacje”). Zakładasz, że część ataków przejdzie, i projektujesz tak, żeby niewiele mogły zrobić.

### Sprawdź się

**Pytanie:** Czym jest prompt injection i jak zabezpieczysz agenta, który czyta maile i strony?

**Krótka odpowiedź:** Model nie odróżnia poleceń od danych, bo wszystko jest jednym ciągiem tokenów, więc treść, którą agent czyta, może nim sterować. Do wycieku potrzebne są trzy rzeczy naraz: prywatne dane, niezaufana treść i kanał na zewnątrz. Prompty obronne i klasyfikatory działają statystycznie, a ataki dopasowane do obrony je przełamują. Dlatego projektuj tak, jakby atak się udał: rozbij to trio w sesji i daj najmniejsze uprawnienia. Wrażliwe akcje zatwierdza człowiek (wymusza to kod), obce treści czyta model bez narzędzi, a wyjście ogranicza lista dozwolonych adresów.

### Pytania pogłębiające

- **Czy da się to naprawić lepszym promptem albo klasyfikatorem?** Nie. Podnoszą poprzeczkę, ale działają statystycznie, a atakujący próbuje do skutku i dopasowuje atak do obrony. Gwarancje daje tylko architektura: uprawnienia, izolacja, kontrola wyjścia, zatwierdzanie w kodzie.
- **Direct a indirect injection: co groźniejsze?** Przy direct injection atakuje sam użytkownik, więc ryzykowne jest to, do czego system daje mu dostęp. Indirect injection przychodzi w treści, którą agent czyta w imieniu ofiary: na stronie, w mailu, PDF-ie, wyniku narzędzia. Zwykle groźniejszy, bo atakujący nie potrzebuje dostępu, a szkodę ponosi niczego nieświadomy użytkownik.
- **Agent musi czytać obce maile i na nie odpowiadać. Jak go projektujesz?** Obce maile czyta model bez narzędzi i zwraca tylko pola ze schematu, np. intencję i numer zamówienia. Agent z uprawnieniami działa na tych polach, odpowiada tylko nadawcy wątku, nie ma dostępu do innych skrzynek, a odpowiedzi z załącznikami albo do nowych adresatów zatwierdza człowiek.
- **Jak dane mogą wyciec, skoro agent nie ma narzędzia do wysyłki?** Przez obrazek w markdownie z danymi w adresie, który aplikacja sama pobierze, przez link, w który ktoś kliknie, przez narzędzie pobierające URL albo zapis w publicznym miejscu. Blokujesz to listą dozwolonych domen, CSP i brakiem automatycznego renderowania.
- **Jak testujesz odporność na injection?** Zestaw ataków, bezpośrednich i ukrytych w danych, trafia do ewaluacji i leci przy każdym wydaniu. Mierzysz odsetek udanych ataków i to, co atak mógł zrobić. Wynik nigdy nie jest zerem, więc test sprawdza też, czy architektura ogranicza szkodę.

### Źródła

- [Simon Willison: The lethal trifecta for AI agents (2025)](https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/)
- [OWASP GenAI: LLM01 Prompt Injection](https://genai.owasp.org/llmrisk/llm01-prompt-injection/)
- [Beurer-Kellner i in.: Design Patterns for Securing LLM Agents against Prompt Injections (2025)](https://arxiv.org/abs/2506.08837)
- [Nasr i in.: The Attacker Moves Second (2025)](https://arxiv.org/abs/2510.09023)
- [Lilian Weng: Adversarial Attacks on LLMs (2023)](https://lilianweng.github.io/posts/2023-10-25-adv-attack-llm/)

---

## LLM na produkcji

*Model na produkcji*

*Ostatnia zmiana: 28 września 2026*

Wywołanie modelu to zdalna zależność, która bywa przeciążona, wolna i droga, a czasem zwraca nie to, o co prosisz. System produkcyjny to kod wokół tego wywołania: ponowienia i fallbacki, kontrola czasu i kosztu, trace’y, walidacja i bezpieczne wdrażanie zmian.

**Po ludzku:** Restauracja z jednym świetnym, ale kapryśnym kucharzem: czasem jest zawalony zamówieniami, czasem gotuje wolno, czasem poda nie to danie. Kierownik sali nie poprawi kucharza, ale może powtórzyć zamówienie za chwilę, trzymać drugiego kucharza na zastępstwo, sprawdzić talerz przed wyniesieniem i notować, co poszło nie tak.

*Interaktywny widżet na stronie: Wybierz awarię i włączaj zabezpieczenia. Zobacz, co dostanie użytkownik, po jakim czasie i za ile.*

### Awarie: co ponawiać i jak

- Ponawiaj tylko błędy przejściowe: 429 (limit), przeciążenie (529 u Anthropic, 503 u OpenAI), inne 5xx, zerwane połączenie i timeout. Błąd 400, 401 albo 403 za drugim razem wyjdzie tak samo. Podobnie 429 z miesięcznego limitu wydatków twojego poziomu konta: u Anthropic przychodzi bez nagłówka `retry-after`, a `error.details.error_code` ma wartość `enforced_spend_limit_reached`.
- Odstępy między próbami wydłużaj wykładniczo, z losowym rozrzutem (jitter): ok. 1, 2, 4 s plus losowy dodatek, a gdy serwer poda `Retry-After`, czekaj co najmniej tyle. Bez rozrzutu wszyscy klienci wracają w tej samej sekundzie i dobijają przeciążony serwis. Ogranicz liczbę prób i łączny czas. Ponawiaj w jednej warstwie: oficjalne SDK same ponawiają (u Anthropic domyślnie 2 razy), więc własna pętla trzech prób nad SDK robi z jednego kliknięcia do 9 requestów.
- Ponowienie jest bezpieczne tylko wtedy, gdy powtórka niczego nie psuje. Samo wywołanie modelu niczego nie zmienia, ale narzędzie agenta już tak. Każda akcja z efektem ubocznym dostaje klucz idempotencji (np. id zadania i numer kroku), a narzędzie odrzuca duplikaty, więc ponowiony krok nie wyśle drugiego maila. Odpowiedzi, którą już zacząłeś streamować użytkownikowi, nie powtarzaj automatycznie.
- Limity liczy się w requestach i tokenach na minutę (RPM i TPM, u Anthropic osobno wejście i wyjście). Anthropic odnawia je na bieżąco metodą wiadra tokenów (token bucket), a limit 60 RPM może działać jak 1 request na sekundę, więc przy nagłym skoku ruchu dostajesz 429 mimo zapasu w skali minuty. OpenAI wlicza do limitu `max_tokens`, jeśli przekracza szacowaną liczbę tokenów w requeście. Anthropic liczy faktycznie wygenerowane tokeny, a odczytów z cache’u dla większości modeli nie wlicza wcale. Limit jest wspólny dla całej organizacji, więc potrzebujesz własnej kolejki i limitów na użytkownika, żeby jeden klient nie zablokował reszty.
- Najbliższy fallback to ten sam model na platformie, którą obsługuje ktoś inny: Claude na Bedrock albo Google Cloud, GPT na Azure albo Bedrock (stan na wrzesień 2026). To osobne konto z własnymi limitami i identyfikatorami modeli, część funkcji trafia tam później, a cache jest zimny. Fallback na inny model też ratuje dostępność, ale prompt strojony pod główny działa na nim inaczej, a format narzędzi bywa inny. W obu przypadkach ścieżka zapasowa potrzebuje własnych evali, bo rzadko używana psuje się po cichu. Circuit breaker po serii błędów na chwilę przestaje wołać chorego dostawcę i od razu kieruje ruch do fallbacku, a co jakiś czas wpuszcza próbny request. Gdy nic nie działa, zadbaj o łagodną degradację: wynik z cache’u, prostsza odpowiedź albo jasny komunikat zamiast wiszącego spinnera.

### Czas odpowiedzi

- Liczą się dwie liczby: czas do pierwszego tokena (TTFT, czyli kolejka plus przetworzenie promptu) i czas całkowity (TTFT plus liczba tokenów wyjścia razy czas na token). Streaming skraca tylko odczuwane czekanie: użytkownik czyta od pierwszego tokena, a całość trwa tyle samo. Przy streamingu ustaw timeout na ciszę między fragmentami, nie na całą odpowiedź, a zdarzenie błędu w środku strumienia (może przyjść po 200 OK) traktuj jak awarię, nie koniec odpowiedzi. Przy długiej odpowiedzi bez streamingu bezczynne połączenie może zostać zerwane. Ceną streamingu jest walidacja: JSON sprawdzisz dopiero w całości.
- Czas rośnie głównie z długością wyjścia, bo każdy token to osobny krok dekodowania (temat „Czemu GPU się nudzi”). Według heurystyki OpenAI skrócenie odpowiedzi o połowę skraca czas mniej więcej o połowę, a skrócenie promptu o połowę tylko o 1–5%. Tokeny rozumowania też są wyjściem. Pomaga zwięzły format, krótkie nazwy pól i niższy poziom rozumowania tam, gdzie wysoki nie jest potrzebny.
- Niezależne wywołania puszczaj równolegle, na przykład klasyfikację pytania i wyszukiwanie. Proste kroki, takie jak routing, klasyfikacja czy ekstrakcja, dawaj mniejszemu i szybszemu modelowi. To, co załatwia reguła albo zwykły kod, rób bez modelu.

### Koszt

- Stały prefiks (system prompt, narzędzia, dokumenty) idzie na początek, bo odczyt z cache’u kosztuje ułamek ceny wejścia, u Anthropic zwykle 10% (temat „Prompt caching”). Zadania offline, jak nocna klasyfikacja, wzbogacanie danych czy przebiegi evali, puszczaj przez batch API: u OpenAI i Anthropic 50% taniej, z wynikiem w ciągu 24 h (stan na wrzesień 2026).
- Kaskada: najpierw tani model, a drogi tylko wtedy, gdy walidator odrzuci wynik albo pewność jest niska. Opłaca się, gdy większość ruchu jest prosta i gdy umiesz tanio sprawdzić, czy tani model sobie poradził. Bez takiego sprawdzenia to zwykłe obniżenie jakości.
- Twarde limity: `max_tokens` na każde wywołanie (to też limit czasu), maksymalna liczba kroków agenta, dzienny budżet na użytkownika lub klienta i alarm kosztowy. Wyniki powtarzalnych zadań trzymaj w zwykłym cache’u z kluczem z wejścia, wersji promptu i wersji modelu. Cache semantyczny, który dopasowuje podobne pytania, potrafi oddać odpowiedź na inne pytanie.

### Obserwowalność

- Każde zadanie to trace, a każde wywołanie modelu i każdy krok narzędzia to jego span: wejście, wyjście, tokeny (także z cache’u), TTFT i czas całkowity, koszt, dokładna wersja modelu z odpowiedzi, wersja promptu i request-id dostawcy. OpenTelemetry ma na to konwencje GenAI (atrybuty `gen_ai.*`, wciąż w fazie rozwoju).
- Metryki: p50 i p95 czasu (średnia ukrywa ogon), odsetek błędów według typu (429, 5xx, timeout, walidacja), udział fallbacku, koszt na ukończone zadanie, a nie na wywołanie, oraz wyniki evali online: sędzia-LLM na próbce ruchu i oceny użytkowników.
- Prompty i odpowiedzi zawierają dane osobowe i tajemnice firmy. Maskuj PII przed zapisem, ogranicz dostęp i czas przechowywania logów. W konwencjach OpenTelemetry zapis treści wiadomości jest domyślnie wyłączony. Trace’y, w których system zawiódł, zamieniaj w przypadki testowe (temat „Ewaluacje”), żeby każdy incydent stał się testem regresyjnym.

### Guardrails i wdrażanie zmian

- Wyjście sprawdzaj w kodzie: schemat, typy i reguły biznesowe (kwota nie większa od salda, identyfikator istnieje). Przy błędzie odeślij modelowi konkretny komunikat i ponów raz lub dwa razy, potem fallback albo błąd. Tryb ścisły usuwa błędy składni, nie złe wartości (temat „Wymuszanie formatu”). Tam, gdzie wymaga tego domena, dodaj limit długości wejścia, moderację i maskowanie PII. Ryzykowne akcje, takie jak płatność, usunięcie czy wysyłka na zewnątrz, zatwierdza człowiek, a wymusza to kod, nie prompt.
- Prompt wersjonuj jak kod i przypinaj dokładną wersję modelu, nie alias, który może się przesunąć. Każda zmiana promptu, modelu albo parametrów przechodzi najpierw evale offline, potem canary na kilku procentach ruchu z porównaniem metryk i szybkim rollbackiem. Dostawcy wycofują stare wersje, więc migracja i tak przyjdzie, a własne evale są jedynym dowodem, że nowa wersja nie jest gorsza (temat „Czy model głupieje?”).
- Sprawdź, dokąd trafiają dane. U OpenAI i Anthropic treść wysłana przez API jest domyślnie przechowywana do 30 dni (monitoring nadużyć), krócej tylko przy umowie o zerowej retencji (ZDR). U Anthropic modele Claude Fable i Mythos 5.x wymagają 30-dniowej retencji, a ZDR dostają tylko za wyraźną zgodą Anthropic (od września 2026 przejściowo uprawnieni klienci na Fable 5 i 5.1), więc wybór modelu to też decyzja o danych. Funkcje ze stanem, takie jak pliki, wyniki batchy czy zapisane odpowiedzi, trzymają dane dłużej (stan na wrzesień 2026). Twoje logi i narzędzie do trace’ów to druga kopia tych samych danych.
- AI Act (stan na wrzesień 2026): od 2 sierpnia 2026 chatbot musi informować, że rozmówca ma do czynienia z AI, a generowane treści muszą mieć oznaczenie czytelne maszynowo (systemy już obecne na rynku mają czas do 2 grudnia 2026). Zastosowania wysokiego ryzyka, takie jak selekcja CV, ocena zdolności kredytowej czy ocenianie egzaminów, dostają swoje obowiązki od 2 grudnia 2027.

### Co widzi użytkownik

- Pokazuj postęp i pozwól przerwać pracę: przy rozumowaniu i krokach agenta pokazuj, który krok trwa (wyszukiwanie, czytanie pliku), obok przycisku stop. Spinner kręcący się przez minutę wygląda jak zawieszenie, a złą ścieżkę najtaniej przerwać wcześnie.
- Pokazuj, skąd jest odpowiedź: źródła z linkiem do fragmentu, który potwierdzają, i zwykłe „nic nie znaleziono” zamiast odpowiedzi z pamięci. Niepewność sygnalizuj tym, co da się sprawdzić (brak źródeł, odrzucenie przez walidator, rozbieżne próbki), a nie pewnością, którą model deklaruje sam o sobie (temat „Halucynacje”).
- Akcje agenta mają podgląd przed i cofnięcie po: szkic zamiast wysłanego maila, miękkie usuwanie, dziennik zmian z przywracaniem. Akceptacji człowieka, opisanej wyżej, wymaga tylko to, czego cofnąć się nie da.

### Sprawdź się

**Pytanie:** Wdrażasz funkcję opartą na LLM-ie na produkcję. Co budujesz wokół samego wywołania modelu?

**Krótka odpowiedź:** Model traktuje się jak zawodną, wolną i drogą zależność zewnętrzną. Każde wywołanie ma timeout, a błędy przejściowe, czyli 429, przeciążenie i 5xx, ponawia się z wykładniczym backoffem i jitterem, w jednej warstwie. Akcje narzędzi mają klucze idempotencji. Fallback, najlepiej ten sam model na innej platformie, ma własne evale i circuit breaker. Czas i koszt obniżają streaming, krótsze wyjście, prompt caching, tańszy model do prostych kroków i batch offline. Każde wywołanie trafia do trace’a z tokenami, kosztem i wersją. Wyjście waliduje się w kodzie, a zmiany promptu i modelu wypuszcza się przez evale i canary.

### Pytania pogłębiające

- **Dostawca zwraca 529 od dziesięciu minut. Co widzi użytkownik?** Po serii błędów circuit breaker przestaje wołać dostawcę i ruch idzie od razu do fallbacku, więc użytkownik dostaje odpowiedź modelu zapasowego bez czekania na kolejne ponowienia. Bez fallbacku: szybki, jasny komunikat, a zadania, które mogą poczekać, trafiają do kolejki. Gdy próbne requesty przechodzą, breaker stopniowo przywraca ruch.
- **Czemu nie ponawiać każdego błędu?** Błąd 400 czy 401 za drugim razem wyjdzie tak samo, a 429 z wyczerpanego limitu wydatków nie minie sam. Ślepe ponawianie mnoży ruch w najgorszym momencie: przy przeciążeniu każdy klient z trzema próbami potraja obciążenie. Stąd jitter, limit łącznego czasu i ponawianie w jednej warstwie.
- **Jak obniżysz rachunek o połowę bez utraty jakości?** Najpierw pomiar: koszt na ukończone zadanie z podziałem na wejście, wyjście i cache. Potem stały prefiks pod prompt caching, batch dla wszystkiego, co nie jest interaktywne, krótsze wyjście, tańszy model tam, gdzie evale nie pokazują różnicy, i cache wyników powtarzalnych zadań. Każdą zmianę sprawdź na evalach, bo tańszy model potrafi po cichu obniżyć jakość.
- **Jak pogodzić streaming z walidacją JSON-a?** Pełną walidację zrobisz dopiero po ostatnim tokenie. W interfejsie streamuj tekst albo parsuj strukturę przyrostowo i pokazuj pola, które są już kompletne. Tam, gdzie błąd jest kosztowny, na przykład przed zapisem albo akcją, buforuj i waliduj całość.
- **Jak bezpiecznie przejść na nowszy model?** Evale offline na zestawie z prawdziwych przypadków, porównanie kosztu i czasu, potem canary na kilku procentach ruchu z tymi samymi metrykami i gotowym rollbackiem. Prompt zwykle trzeba dostroić, bo nowy model inaczej rozumie te same instrukcje. Fallback na inny model testuj tak samo, bo to też zmiana modelu.

### Źródła

- [OpenAI: Rate limits (ponawianie z backoffem i jitterem)](https://developers.openai.com/api/docs/guides/rate-limits)
- [Dokumentacja Claude: Errors (które błędy ponawiać)](https://platform.claude.com/docs/en/api/errors)
- [OpenAI: Latency optimization](https://developers.openai.com/api/docs/guides/latency-optimization)
- [OpenTelemetry: GenAI semantic conventions](https://github.com/open-telemetry/semantic-conventions-genai)
- [EUR-Lex: Digital Omnibus on AI, rozporządzenie (UE) 2026/1744 (terminy AI Act)](https://eur-lex.europa.eu/eli/reg/2026/1744/oj/eng)

---

## Czemu GPU się nudzi

*Model na produkcji*

*Ostatnia zmiana: 28 września 2026*

Przy generowaniu tekstu karta graficzna przez większość kroku czeka, aż wagi i KV cache przyjadą z pamięci, a liczy tylko przez ułamek tego czasu. To jedno zjawisko tłumaczy batching, kwantyzację, dekodowanie spekulacyjne i to, czemu tokeny wyjściowe są droższe od wejściowych.

**Po ludzku:** Kucharz jest błyskawiczny, ale po każdy składnik biega do magazynu na drugim końcu budynku. Gotując dla jednej osoby, głównie biega. Gotując dla stu naraz, biega tyle samo, a gotuje sto razy więcej.

*Interaktywny widżet na stronie: Zwiększaj batch i patrz, kiedy liczenie dogoni czekanie na pamięć. Potem przełącz na prefill.*

### Dlaczego decode jest memory-bound

- Krok decode daje jeden token na rozmowę, ale czyta z pamięci HBM wszystkie wagi. Model 8B w BF16 to 16 GB, które przy 3,35 TB/s czyta się ok. 4,8 ms. Sufit to więc ok. 210 tokenów na sekundę dla jednej rozmowy, niezależnie od mocy obliczeniowej karty.
- Intensywność arytmetyczna to liczba operacji na bajt przeczytany z pamięci. Mnożenie wektora przez wagi to 2 operacje (mnożenie i dodawanie) na parametr, czyli na 2 bajty w BF16: ok. 1 operacja na bajt na każdą rozmowę w batchu. H100 SXM potrzebuje ok. 295 operacji na bajt katalogowo (989 TFLOPS / 3,35 TB/s) i ok. 120 przy realnie osiąganych 400 TFLOPS. Jeśli uwzględnić same wagi, dopiero batch rzędu 100–300 rozmów zrównuje liczenie z czytaniem.
- Prefill przetwarza cały prompt w jednym przebiegu: wagi przeczytane raz obsługują tysiące tokenów, więc już jeden długi prompt w pełni zajmuje kartę. Prefill wyznacza czas do pierwszego tokena (TTFT), a decode – czas między kolejnymi tokenami.

### Gdzie batch przestaje być darmowy

- Batch dzieli koszt czytania wag, ale nie KV cache’u: każda rozmowa czyta własny, więc attention w decode zostaje ograniczone pamięcią przy każdym rozmiarze batcha. W modelu 8B z GQA (jak Llama 3 8B) cache zajmuje ok. 0,125 MB na token, więc rozmowa z 32 tys. tokenów kontekstu to 4 GB. Szesnaście takich rozmów czyta w każdym kroku 64 GB cache’u i tylko 16 GB wag. Mechanizm opisuje temat „Pętla generowania i KV cache”.
- Za punktem przecięcia każda kolejna rozmowa wydłuża krok wszystkim: łączna przepustowość rośnie coraz wolniej, a czas między tokenami rośnie. Dostawca wybiera punkt na tej krzywej. Ruch interaktywny wymaga mniejszego batcha i szybkich tokenów, a ruch wsadowy można pakować ciasno.
- W modelu MoE jeden token czyta tylko wybranych ekspertów, ale tokeny z batcha rozchodzą się po różnych ekspertach, więc przy większym batchu czytasz prawie cały model (zobacz „Mixture of Experts”).

### Co z tego wynika dla serwowania

- Prędkość jednego strumienia ≈ przepustowość pamięci / bajty czytane na token (aktywne wagi plus KV cache). Stąd kwantyzacja wag do 8 lub 4 bitów przyspiesza decode prawie proporcjonalnie (zobacz „Kwantyzacja”), a dekodowanie spekulacyjne daje kilka tokenów z jednego czytania wag (zobacz „Dekodowanie spekulacyjne”).
- Koszt na token to przede wszystkim rozmiar batcha. Continuous batching i PagedAttention istnieją po to, żeby w ograniczonej pamięci zmieścić jak największy batch (zobacz „Continuous batching”).
- Tokeny wyjściowe są w cennikach kilka razy droższe od wejściowych (u dużych dostawców zwykle 4–8 razy). Wejście przechodzi przez prefill równolegle, a każdy token wyjścia to osobny krok decode, który zajmuje miejsce w batchu.
- Prefill i decode mają inne wąskie gardła i przeszkadzają sobie na wspólnej karcie. Duże wdrożenia rozdzielają je na osobne pule (disaggregated serving): raport techniczny DeepSeek-V3 opisuje prefill na jednostkach po 32 GPU, a decode po 320 GPU. Taki podział obsługują też vLLM, SGLang i NVIDIA Dynamo. Na jednym serwerze konflikt łagodzi chunked prefill.
- Do decode kartę wybiera się po przepustowości i pojemności pamięci, nie po TFLOPS. H200 ma tę samą moc obliczeniową co H100, ale 4,8 TB/s i 141 GB pamięci, więc przy dużych modelach i długich kontekstach generuje szybciej. Blackwell B200 (w sprzedaży, stan na wrzesień 2026) ma 180 GB i 8 TB/s, ale jego moc obliczeniowa urosła tak samo (ok. 280 operacji na bajt w BF16), więc wnioski z tej strony dalej obowiązują.

### Sprawdź się

**Pytanie:** Dlaczego decode jest memory-bound i co z tego wynika dla serwowania?

**Krótka odpowiedź:** Każdy krok decode czyta z pamięci wszystkie wagi i KV cache, a liczy tylko jeden token na rozmowę: w BF16 to ok. 1 operacja na bajt, a H100 potrzebuje ok. 300, żeby wąskim gardłem stało się liczenie. Sufit prędkości jednej rozmowy to przepustowość pamięci podzielona przez bajty na token. Wagi przeczytane raz obsługują cały batch, więc batching podnosi przepustowość prawie za darmo, dopóki nie skończy się pamięć na KV cache albo budżet opóźnienia. Kwantyzacja i dekodowanie spekulacyjne przyspieszają decode. Z prefillem jest odwrotnie: ogranicza go moc obliczeniowa.

### Pytania pogłębiające

- **Oszacuj maksymalną prędkość modelu 70B w FP8 na jednej H100.** 70 GB wag przy 3,35 TB/s to ok. 21 ms na krok, czyli najwyżej ok. 48 tokenów na sekundę na rozmowę, zanim doliczysz KV cache. Na cache zostaje ok. 10 GB z 80, więc batch będzie mały. W praktyce taki model dzieli się na 2–4 karty (tensor parallelism), co sumuje przepustowość i pamięć.
- **Masz SLO 50 ms między tokenami. Jak dobierasz rozmiar batcha?** Czas kroku to w przybliżeniu (wagi + KV cache całego batcha) / przepustowość pamięci, dopóki liczenie się w nim mieści. Zwiększasz batch, aż czas kroku zbliży się do 50 ms, z zapasem na p99, albo zabraknie pamięci na cache. Dalej przepustowość rośnie już kosztem opóźnienia wszystkich.
- **Po co rozdzielać prefill i decode na osobne maszyny?** Prefill jest ograniczony mocą i przychodzi falami, decode jest ograniczony pamięcią i trwa ciągle. Na wspólnej karcie długi prefill zatrzymuje cudze generowanie, a osobne pule można skalować i dzielić na karty niezależnie. Ceną jest przesyłanie KV cache’u z puli prefill do puli decode.
- **Wykorzystanie mocy obliczeniowej w decode wynosi kilka procent. To problem?** Niekoniecznie. Przy małym batchu właściwą miarą jest wykorzystanie przepustowości pamięci (MBU): bajty wag i cache’u na krok podzielone przez czas kroku i szczytową przepustowość. Wykorzystanie mocy (MFU) optymalizujesz w prefillu i treningu.

### Źródła

- [How To Scale Your Model: All About Rooflines](https://jax-ml.github.io/scaling-book/roofline)
- [How To Scale Your Model: All About Transformer Inference](https://jax-ml.github.io/scaling-book/inference)
- [Databricks: LLM Inference Performance Engineering (MBU)](https://www.databricks.com/blog/llm-inference-performance-engineering-best-practices)
- [NVIDIA: specyfikacja H100](https://www.nvidia.com/en-us/data-center/h100/)

---

## Continuous batching

*Model na produkcji*

*Ostatnia zmiana: 28 września 2026*

Serwer składa rozmowy w batch, żeby jedno czytanie wag obsłużyło wielu użytkowników naraz. Continuous batching wymienia rozmowy w batchu co krok, a PagedAttention przydziela im pamięć na KV cache małymi blokami, więc na tej samej karcie mieści się ich kilka razy więcej.

**Po ludzku:** Autobus, który nie czeka, aż wszyscy dojadą do pętli: kto wysiada, zwalnia miejsce następnemu na najbliższym przystanku. Do tego nikt nie rezerwuje miejsca na całą trasę z góry, tylko siada, gdy wsiada.

*Interaktywny widżet na stronie: Odtwórz oba tryby i porównaj: ile kratek stoi pustych i w którym kroku kończy się ostatnia rozmowa.*

### Jak działa continuous batching

- Batch statyczny ustala skład raz: wszyscy czekają na najdłuższą odpowiedź, a nowe żądania na koniec całej grupy. Długości odpowiedzi nie znasz z góry, więc puste miejsca są regułą, nie wyjątkiem.
- Continuous batching (w literaturze iteration-level scheduling, system Orca, OSDI 2022) decyduje o składzie co krok decode. Skończona rozmowa zwalnia miejsce od razu, a czekająca dołącza w następnym kroku. Działa, bo każdy krok to osobny przebieg modelu, a warstwy poza attention nie zależą od długości sekwencji.
- Nowa rozmowa zaczyna od prefillu swojego promptu, który na chwilę zabiera kartę rozmowom w trakcie generowania. Chunked prefill tnie długi prompt na kawałki mieszczące się w budżecie tokenów na krok. vLLM V1 włącza go domyślnie i w każdym kroku najpierw obsługuje rozmowy w fazie decode, a prefill dokłada w wolne miejsce.

*Interaktywny widżet na stronie: Przełącz sposób przydziału pamięci i policz, ile rozmów mieści się w tych samych 32 blokach.*

### PagedAttention: pamięć na KV cache

- Rezerwacja ciągłego obszaru na maksymalną długość odpowiedzi marnuje pamięć na zapas i fragmentację. Autorzy vLLM zmierzyli w ówczesnych systemach 60–80% straty pamięci na KV cache.
- PagedAttention dzieli KV cache na bloki po kilkanaście tokenów (zwykle 16), przydzielane w miarę generowania i adresowane przez tablicę bloków, jak strony pamięci wirtualnej w systemie operacyjnym. Pusta zostaje tylko końcówka ostatniego bloku, a strata spada poniżej 4%. Więcej rozmów w pamięci to większy batch i niższy koszt na token.
- Bloki można współdzielić z kopiowaniem przy zapisie (copy-on-write). Wspólny prefiks, na przykład system prompt albo prompt kilku próbek tej samej odpowiedzi, leży w pamięci raz. Na tym opiera się prefix caching w serwerze (zobacz „Prompt caching”). Przy wielu replikach działa tylko wtedy, gdy router kieruje żądania z tym samym prefiksem do repliki, która już go ma (routing świadomy prefiksu, np. w llm-d albo NVIDIA Dynamo).
- Ceną przydziału na żądanie jest to, że pamięć może się skończyć w trakcie generowania. Serwer wtedy wywłaszcza rozmowę, a później liczy jej KV cache od nowa. W vLLM V1 to domyślny tryb, a nie przenoszenie cache’u do pamięci CPU. Użytkownik widzi to jako nagły przestój strumienia.

### Przepustowość a opóźnienie na produkcji

- Rozmiar batcha ograniczają pamięć na KV cache (liczba rozmów × długość kontekstu) i budżet opóźnienia między tokenami. Parametry serwera, takie jak `max_num_seqs` i `max_num_batched_tokens` w vLLM, ustawiają wprost ten kompromis.
- Przepustowość rośnie kosztem opóźnienia. Pod obciążeniem czas do pierwszego tokena rośnie przez kolejkę i prefille, a czas między tokenami przez większe batche. Oba mierzysz osobno, w percentylach p50 i p99 (zobacz „LLM na produkcji”).
- Batch API dostawców sprzedaje luźne SLO: u Anthropic 50% taniej, większość paczek kończy się w ciągu godziny, limit to 24 godziny. Dostawca może takim ruchem wypełniać wolne miejsca w batchach i doliny ruchu. Do ewaluacji i przetwarzania wsadowego to najprostsza oszczędność.

### Sprawdź się

**Pytanie:** Jak serwer LLM obsługuje wielu użytkowników naraz i co dają continuous batching oraz PagedAttention?

**Krótka odpowiedź:** Batch dzieli koszt czytania wag, więc serwer chce go mieć jak największy. Continuous batching ustala skład batcha co krok decode, a nie co żądanie: skończona rozmowa od razu zwalnia miejsce, nowa dołącza w następnym kroku, więc karta nie czeka na najdłuższą odpowiedź. PagedAttention przydziela KV cache blokami na żądanie, zamiast rezerwować maksimum z góry: strata pamięci spada z 60–80% do kilku procent, mieści się więcej rozmów, a wspólne prefiksy leżą w pamięci raz. Ceną są wywłaszczenia, gdy pamięć się skończy.

### Pytania pogłębiające

- **Co ogranicza rozmiar batcha?** Pamięć na KV cache wszystkich rozmów i budżet opóźnienia między tokenami. Przy długich kontekstach najpierw kończy się pamięć, przy krótkich budżet opóźnienia.
- **Użytkownicy zgłaszają rzadkie, kilkusekundowe przestoje w strumieniu tokenów. Co sprawdzasz?** Wywłaszczenia z braku pamięci na KV cache (licznik w metrykach serwera) i długie prefille nowych żądań bez chunked prefill. Pomaga niższy limit równoległych rozmów, więcej pamięci na cache albo osobne repliki dla bardzo długich promptów.
- **Co daje PagedAttention poza ciaśniejszym upakowaniem?** Współdzielenie bloków z copy-on-write. Wspólny prefiks wielu rozmów leży w pamięci raz, a kilka próbek tej samej odpowiedzi (n > 1, beam search) dzieli bloki promptu. Autorzy vLLM podają do 55% mniej pamięci przy takim samplowaniu.
- **Czemu przy temperaturze 0 ten sam prompt daje czasem inny tekst?** Wynik kernela zależy od rozmiaru batcha, bo zmienia się kolejność sumowania liczb zmiennoprzecinkowych. Rozmiar batcha zależy od obciążenia serwera, więc drobne różnice w logitach zmieniają czasem wybrany token. Thinking Machines (2025) wskazuje to jako główną przyczynę niedeterminizmu endpointów. Lekarstwem są kernele niezależne od batcha: vLLM ma tryb Batch Invariance (beta, stan na wrzesień 2026), w którym wynik nie zależy od rozmiaru batcha ani kolejności żądań, co może kosztować część szybkości. Przydaje się w ewaluacjach, debugowaniu i rolloutach RL.

### Źródła

- [Kwon i in.: Efficient Memory Management for LLM Serving with PagedAttention (SOSP 2023)](https://arxiv.org/abs/2309.06180)
- [vLLM: Easy, Fast, and Cheap LLM Serving with PagedAttention](https://vllm.ai/blog/2023-06-20-vllm)
- [vLLM: Optimization and Tuning (preemption, chunked prefill)](https://docs.vllm.ai/en/latest/configuration/optimization.html)
- [Agrawal i in.: Sarathi-Serve, chunked prefill (OSDI 2024)](https://arxiv.org/abs/2403.02310)

---

## Dekodowanie spekulacyjne

*Model na produkcji*

*Ostatnia zmiana: 29 września 2026*

W dekodowaniu spekulacyjnym tani mechanizm zgaduje kilka następnych tokenów, a duży model sprawdza je w jednym przebiegu i przyjmuje te, które sam by wybrał. Wynik jest taki sam jak bez spekulacji (przy wyborze zachłannym ten sam tekst, przy losowaniu ten sam rozkład), a z jednego czytania wag powstaje kilka tokenów.

**Po ludzku:** Stażysta pisze szkic, a szef czyta i poprawia pierwsze błędne słowo, po czym stażysta pisze dalej. Czytanie idzie dużo szybciej niż pisanie, więc razem kończą wcześniej, a tekst jest taki, jaki napisałby sam szef.

*Interaktywny widżet na stronie: Przejdź trzy rundy i patrz, ile tokenów przyjmuje jedna weryfikacja i ile przebiegów dużego modelu oszczędzasz.*

### Jak działa weryfikacja

- Draft, czyli tani mechanizm zgadujący, proponuje γ tokenów (zwykle kilka). Duży model w jednym przebiegu liczy rozkład dla każdej z tych pozycji, tak jak w prefillu. Przyjmuje najdłuższy zgodny prefiks, w miejscu pierwszej niezgodności wstawia własny token, a przy pełnej zgodności dokłada jeszcze jeden. Każda runda daje więc co najmniej jeden token.
- Weryfikacja jest tania, bo decode jest ograniczony pamięcią: przebieg na pięciu pozycjach czyta te same wagi co przebieg na jednej i trwa prawie tyle samo (zobacz „Czemu GPU się nudzi”).
- Przy losowaniu propozycję x przyjmuje się z prawdopodobieństwem min(1, p(x)/q(x)), gdzie p to rozkład dużego modelu, a q małego. Po odrzuceniu losuje się z różnicy max(0, p − q) po normalizacji. Wynik ma dokładnie rozkład dużego modelu (Leviathan i in.; Chen i in., 2023), a przy wyborze zachłannym tekst jest identyczny, z dokładnością do drobnych różnic numerycznych.

### Od czego zależy zysk

- Przy współczynniku akceptacji α i γ propozycjach runda daje średnio (1 − α^(γ+1)) / (1 − α) tokenów. Dla α = 0,8 i γ = 4 to ok. 3,4 tokenu na przebieg dużego modelu. Zysk czasu jest mniejszy, bo draft też kosztuje, a odrzucone propozycje to zmarnowana praca.
- Akceptacja zależy od tekstu. Kod, JSON, powtórzenia i niska temperatura dają wysokie α, a twórczy tekst przy wysokiej temperaturze niskie. Leviathan i in. zmierzyli przyspieszenie 2–3× na T5-XXL. DeepSeek-V3 podaje 85–90% akceptacji drugiego tokena z modułu MTP i 1,8× więcej tokenów na sekundę.
- Zysk maleje wraz ze wzrostem batcha. Wagi i tak czyta się raz dla całego batcha, więc gdy krok staje się ograniczony mocą obliczeniową, dodatkowe pozycje kosztują realną moc: przy dużym batchu i krótkich kontekstach spekulacja może wyjść na minus. Z KV cache’em jest inaczej, bo każda rozmowa czyta własny. Przy długich kontekstach decode zostaje ograniczony pamięcią nawet przy dużym batchu, a draft, który czyta niewiele z cache’u, nadal podnosi przepustowość (MagicDec: do 2,5× dla Llama 3.1 8B przy batchu 32–256; EAGLE-3: 1,38× przy batchu 64 w SGLang). vLLM poleca spekulację głównie przy niskim i średnim obciążeniu, ale dla EAGLE i MTP podaje średni lub duży zysk także przy dużym.

### Warianty i wybór w praktyce

- Osobny mały model z tej samej rodziny i z tym samym tokenizerem: prosty w użyciu, ale zajmuje pamięć i trzeba go serwować obok dużego.
- Draft dopięty do dużego modelu: dodatkowe głowice przewidujące kolejne pozycje (Medusa), lekka warstwa pracująca na stanach ukrytych dużego modelu (EAGLE, obecnie EAGLE-3) albo moduł MTP wytrenowany razem z modelem, jak w DeepSeek-V3. Zwykle trafia lepiej niż osobny mały model. Wynik jest dokładny tylko przy standardowej akceptacji i niezmienionym dużym modelu: Medusa-2, która dotrenowuje duży model razem z głowicami, i „typical acceptance” z Medusy wymieniają dokładność na szybkość.
- Bez żadnego modelu: dopasowanie n-gramów kopiuje ciąg dalszy z promptu (prompt lookup). Działa przy edycji kodu, RAG i streszczeniach, gdzie odpowiedź powtarza fragmenty wejścia.
- Metodę i γ wybierasz na podstawie α zmierzonego na własnym ruchu i sprawdzasz zysk przy docelowym obciążeniu, a nie na pojedynczym żądaniu. W API dostawców spekulacja zwykle działa niewidocznie. Wyjątkiem są funkcje w rodzaju Predicted Outputs w API OpenAI, gdzie sam podajesz przewidywany tekst, na przykład plik przed edycją (stan na wrzesień 2026: tylko modele GPT-4o i GPT-4.1, bez wywołań funkcji; odrzucone przewidywane tokeny są płatne jak wyjście).

### Sprawdź się

**Pytanie:** Jak działa speculative decoding, czemu nie zmienia wyniku i kiedy przestaje pomagać?

**Krótka odpowiedź:** Tani draft, czyli mały model, dodatkowe głowice albo n-gramy skopiowane z promptu, proponuje kilka tokenów. Duży model sprawdza je w jednym przebiegu, bo decode jest ograniczony pamięcią i kilka pozycji kosztuje prawie tyle co jedna. Przyjmuje zgodny prefiks, a w miejscu pierwszej niezgodności wstawia własny token. Akceptacja z prawdopodobieństwem min(1, p/q) i losowanie z max(0, p − q) po odrzuceniu gwarantują dokładnie rozkład dużego modelu. Zysk zależy od trafności: 2–3× przy przewidywalnym tekście i małym batchu, mniej przy większym, a zero albo strata, gdy krok jest już ograniczony mocą obliczeniową (duży batch, krótkie konteksty).

### Pytania pogłębiające

- **Kiedy spekulacja nie pomaga albo szkodzi?** Przy niskiej akceptacji, czyli przy twórczym tekście, wysokiej temperaturze albo drafcie trenowanym na innych danych. Także gdy krok jest już ograniczony mocą obliczeniową, czyli przy dużym batchu i krótkich kontekstach: weryfikacja odrzuconych tokenów zabiera wtedy moc innym rozmowom.
- **Czemu rozkład wyniku jest dokładnie taki jak u dużego modelu?** Token x przechodzi z prawdopodobieństwem min(1, p(x)/q(x)), a po odrzuceniu losuje się z max(0, p − q) po normalizacji. Suma obu dróg daje dla każdego tokena dokładnie p(x). W praktyce dochodzą tylko drobne różnice numeryczne z innego kształtu obliczeń.
- **Akceptacja wynosi 0,6 przy γ = 5. Zwiększasz γ?** Raczej zmniejszasz. Runda daje średnio (1 − 0,6⁶) / 0,4 ≈ 2,4 tokenu, a przy γ = 3 już ≈ 2,2, więc dwie dodatkowe propozycje prawie nic nie dodają, a kosztują draft i weryfikację. Większy zysk da lepszy draft, na przykład dotrenowany na własnym ruchu.
- **Czy draft musi mieć ten sam tokenizer co duży model?** W klasycznym wariancie tak, bo porównuje się tokeny i rozkłady na tym samym słowniku. Dlatego draft bierze się z tej samej rodziny modeli albo dopina się głowice do samego dużego modelu. Nowsze serwery łagodzą ten wymóg: vLLM łączy draft i duży model z różnymi słownikami przez mapowanie tokenów (use_heterogeneous_vocab, stan na wrzesień 2026 tylko z zachłannym draftem).

### Źródła

- [Leviathan i in.: Fast Inference from Transformers via Speculative Decoding (ICML 2023)](https://arxiv.org/abs/2211.17192)
- [Chen i in.: Accelerating LLM Decoding with Speculative Sampling (2023)](https://arxiv.org/abs/2302.01318)
- [Li i in.: EAGLE-3 (2025)](https://arxiv.org/abs/2503.01840)
- [Sadhukhan i in.: MagicDec, spekulacja przy dużym batchu i długim kontekście (2024)](https://arxiv.org/abs/2408.11049)
- [vLLM: Speculative Decoding](https://docs.vllm.ai/en/latest/features/speculative_decoding/)

---

## Kwantyzacja

*Model na produkcji*

*Ostatnia zmiana: 28 września 2026*

Kwantyzacja zapisuje wagi, a czasem też aktywacje i KV cache, mniejszą liczbą bitów, zaokrąglając je do rzadszej siatki wartości. Model zajmuje 2–4 razy mniej pamięci, a generowanie przyspiesza, bo decode czyta z pamięci mniej bajtów.

**Po ludzku:** Zdjęcie zapisane jako JPEG zamiast w pełnej jakości: waży kilka razy mniej i na ekranie telefonu wygląda tak samo. Artefakty widać dopiero przy mocnej kompresji i najpierw w drobnych detalach. U modelu tymi detalami są długie rozumowanie, kod i rzadsze języki.

*Interaktywny widżet na stronie: Zmniejszaj liczbę bitów, dodaj wartość odstającą, a potem włącz osobną skalę dla bloków. Patrz na błąd zaokrągleń.*

*Interaktywny widżet na stronie: Wybierz rozmiar modelu i zobacz, na czym zmieszczą się same wagi. Liczbę bitów zmieniasz w widżecie powyżej.*

### Jak działa kwantyzacja

- Każdą wagę dzieli się przez skalę, zaokrągla do liczby z małego zakresu (w INT4 od −8 do 7; siatka symetryczna, jak w widżecie, używa wartości od −7 do 7, czyli 15 poziomów) i tak zapisuje. Przy liczeniu mnoży się ją z powrotem przez skalę. Błąd to szum zaokrągleń, a sieć jest na drobny szum odporna.
- Problemem są wartości odstające. Jedna duża liczba rozciąga siatkę i reszta wag ląduje w kilku punktach wokół zera. Dlatego skalę liczy się osobno dla małych grup, zwykle 16–128 wag. W aktywacjach modeli od ok. 6,7 mld parametrów pojawiają się systematyczne wartości odstające w kilku kanałach (Dettmers i in., LLM.int8(), 2022).
- Kwantyzacja po treningu (PTQ) działa na gotowym modelu w minuty lub godziny. GPTQ i AWQ używają małej próbki danych kalibracyjnych, żeby zaokrąglać tak, by jak najmniej zaszkodzić wyjściu warstwy. Trening z symulowaną kwantyzacją (QAT) daje model, który lepiej znosi 4 bity i mniej, ale to dodatkowy trening, więc robi go zwykle autor modelu.

### Formaty kwantyzacji i co przyspieszają

- Kwantyzacja samych wag, np. W4A16 (wagi w 4 bitach, aktywacje w 16), zmniejsza liczbę bajtów czytanych w decode, więc przyspiesza generowanie przy małym batchu. Mnożenie i tak idzie w 16 bitach, więc prefill i duże batche prawie nie zyskują.
- FP8 dla wag i aktywacji (W8A8) pozwala liczyć na rdzeniach tensorowych w FP8: H100 osiąga w nim ok. 1979 TFLOPS dense wobec 989 w BF16. Przyspiesza więc też prefill i duże batche. W pomiarach Kurtica i in. (2024) FP8 W8A8 jest praktycznie bezstratne, INT8 W8A8 traci 1–3% dokładności, a W4A16 wypada bliżej 8 bitów, niż się spodziewano.
- Nowe formaty 4-bitowe to liczby zmiennoprzecinkowe ze skalą na blok. MXFP4 ma bloki po 32 wagi i skalę będącą potęgą dwójki, ok. 4,25 bita na wagę; w nim OpenAI wydało wagi ekspertów gpt-oss. NVFP4 ma bloki po 16 ze skalą w FP8 i dodatkową skalą na tensor, ok. 4,5 bita, i jest obsługiwany sprzętowo przez karty Blackwell.
- KV cache też się kwantyzuje. Cache w FP8 zajmuje o połowę mniej pamięci na token, więc przy długich kontekstach daje więcej miejsca na batch niż dalsze ściskanie wag (zobacz „Pętla generowania i KV cache”).

### Co się traci i jak wybrać format

- Reguła kciuka, zależna od modelu i metody: 8 bitów praktycznie bez straty, 4 bity z dobrą metodą to niewielka strata, 3 bity i mniej to szybki spadek. Straty pojawiają się najpierw w długim rozumowaniu, kodzie, matematyce i rzadszych językach, a średnia z benchmarków potrafi je ukryć.
- Przy tej samej pamięci większy model w 4 bitach zwykle wypada lepiej niż mniejszy w 16. Dettmers i Zettlemoyer (2022) po ponad 35 tys. eksperymentów uznali 4 bity za prawie zawsze optymalne przy stałej łącznej liczbie bitów modelu.
- Wybór zależy od ruchu i sprzętu. Na Hopperze, np. H100, Kurtic i in. zalecają W4A16 przy pojedynczych żądaniach i małym batchu, a W8A8 w FP8 przy dużym ruchu z continuous batchingiem. Na Blackwellu NVFP4 dla wag i aktywacji (W4A4) liczy się na rdzeniach FP4 2–3 razy szybciej niż FP8, więc 4 bity mogą wygrać także przy dużym ruchu, kosztem nieco większej straty niż w FP8: Red Hat mierzy ok. 99% dokładności BF16 dla modeli od 70B i 95–98% dla modeli 7–14B. Jakość sprawdzasz na własnym zestawie ewaluacyjnym, bo ten sam model u różnych hostów bywa różnie skwantyzowany (zobacz „Modele open-weight” i „Ewaluacje”).

### Sprawdź się

**Pytanie:** Co daje kwantyzacja, co się traci i jaki format wybierzesz?

**Krótka odpowiedź:** Wagi zapisuje się mniejszą liczbą bitów, z 16 do 8 albo 4, ze skalą liczoną dla małych bloków, bo pojedyncze wartości odstające rozciągają siatkę. Model zajmuje 2–4 razy mniej pamięci, a decode przyspiesza, bo czyta mniej bajtów. Kwantyzacja samych wag, jak W4A16, pomaga przy małym batchu. FP8 dla wag i aktywacji przyspiesza też liczenie, więc na Hopperze wygrywa przy dużym ruchu; na Blackwellu jeszcze szybsze jest NVFP4 dla wag i aktywacji. 8 bitów to praktycznie brak straty, 4 bity to niewielka strata, niżej jakość szybko spada, najpierw w rozumowaniu i kodzie. Rozstrzygają własne ewaluacje.

### Pytania pogłębiające

- **PTQ a QAT?** PTQ kwantyzuje gotowy model w minuty lub godziny, na małej próbce danych kalibracyjnych (GPTQ, AWQ). QAT symuluje kwantyzację w treningu, więc model uczy się ją znosić i lepiej trzyma jakość w 4 bitach i niżej. Kosztem jest trening, więc QAT robi zwykle autor modelu.
- **Czemu aktywacje kwantyzuje się trudniej niż wagi?** Wagi są znane z góry i można je starannie przeskalować offline. Aktywacje zależą od wejścia i mają duże wartości odstające w kilku kanałach. Pomagają metody przenoszące trudność na wagi (SmoothQuant) i FP8, które ma większy zakres niż INT8.
- **Po kwantyzacji do 4 bitów benchmarki są w normie, a użytkownicy skarżą się na kod. Co robisz?** Średnia z benchmarków ukrywa straty w długich łańcuchach rozumowania i kodzie. Porównaj obie wersje na własnym zestawie z tego obszaru. Jeśli strata jest realna, wróć do 8 bitów albo zostaw wrażliwe warstwy w wyższej precyzji.
- **Kiedy kwantyzacja KV cache’u daje więcej niż kwantyzacja wag?** Przy długich kontekstach i dużym batchu, gdy cache wszystkich rozmów zajmuje więcej pamięci niż wagi. Cache w FP8 mieści dwa razy więcej tokenów, czyli dwa razy więcej rozmów albo dwa razy dłuższy kontekst.

### Źródła

- [Maarten Grootendorst: A Visual Guide to Quantization](https://newsletter.maartengrootendorst.com/p/a-visual-guide-to-quantization)
- [Kurtic i in.: „Give Me BF16 or Give Me Death”? Accuracy-Performance Trade-Offs in LLM Quantization](https://arxiv.org/abs/2411.02355)
- [Dettmers i Zettlemoyer: The case for 4-bit precision (2022)](https://arxiv.org/abs/2212.09720)
- [NVIDIA: Introducing NVFP4](https://developer.nvidia.com/blog/introducing-nvfp4-for-efficient-and-accurate-low-precision-inference/)
- [Red Hat: Accelerating large language models with NVFP4 quantization (2026)](https://developers.redhat.com/articles/2026/02/04/accelerating-large-language-models-nvfp4-quantization)

---

## Mixture of Experts

*Model na produkcji*

*Ostatnia zmiana: 28 września 2026*

W Mixture of Experts (MoE) warstwę MLP zastępuje wielu „ekspertów”, a router dla każdego tokena wybiera kilku z nich. Model ma bardzo dużo parametrów, ale na token liczy tylko część: obliczenia jak w małym modelu, pamięć jak w dużym.

**Po ludzku:** Przychodnia. Rejestracja kieruje cię do dwóch z ośmiu lekarzy. Wszyscy muszą siedzieć w budynku, ale płacisz tylko za dwie wizyty. Gdy przychodzi tłum, każdy lekarz ma pacjentów, a rejestracja musi pilnować, żeby pod jednym gabinetem nie ustawiła się cała kolejka.

*Interaktywny widżet na stronie: Klikaj tokeny i patrz, których ekspertów wybiera router. Na dole: ilu ekspertów potrzebuje całe zdanie.*

### Jak działa routing

- Router to mała warstwa liniowa. Z wektora tokena liczy wynik dla każdego eksperta, wybiera k najlepszych (zwykle 2–8) i sumuje ich wyjścia z wagami wyliczonymi z tych wyników. Wybór zapada osobno w każdej warstwie MoE i dla każdego tokena.
- Eksperci zastępują tylko MLP. Attention, embeddingi i normalizacje są wspólne, dlatego Mixtral 8×7B ma ok. 47 mld parametrów (a nie 56 mld), z czego ok. 13 mld aktywnych na token. Nowsze modele mają dużo więcej drobniejszych ekspertów: DeepSeek-V3 ma w każdej warstwie MoE 256 ekspertów routowanych i jednego wspólnego, a wybiera 8.
- „Ekspert” nie jest specjalistą od tematu. Autorzy Mixtrala nie znaleźli wyraźnych wzorców przydziału według dziedziny tekstu; wybór wiąże się raczej ze składnią, np. wcięcia w kodzie trafiają stale do tych samych ekspertów.
- Bez wyrównywania obciążenia router zawęża wybór do kilku ulubionych ekspertów, a reszta parametrów prawie się nie uczy. Stąd dodatkowa strata równoważąca w treningu (od pierwszych rzadkich warstw MoE, uproszczona w Switch Transformer) albo, w DeepSeek-V3, głównie bias każdego eksperta korygowany w trakcie treningu i używany tylko do wyboru ekspertów, plus strata równoważąca o bardzo małej wadze, liczona na poziomie sekwencji.

### Serwowanie MoE: pamięć, batch i expert parallelism

- W pamięci muszą leżeć wszyscy eksperci. DeepSeek-V3 ma 671 mld parametrów, z czego 37 mld aktywnych na token. W FP8 to ok. 671 GB samych wag, więcej niż 640 GB na ośmiu kartach H100.
- Przy jednej rozmowie decode czyta tylko aktywnych ekspertów, więc jest szybki jak w modelu o wielkości części aktywnej. Przy większym batchu tokeny rozchodzą się prawie do wszystkich ekspertów: krok czyta prawie cały model, a każdy ekspert dostaje tylko część batcha. Żeby liczenie dogoniło czytanie, batch musi być mniej więcej tyle razy większy niż w modelu gęstym, ile wynosi stosunek wszystkich ekspertów do wybranych (zobacz „Czemu GPU się nudzi”).
- Dlatego ekspertów dużego MoE rozkłada się na wiele kart (expert parallelism), a w każdej warstwie karty wymieniają się tokenami w trybie all-to-all. DeepSeek-V3 dekoduje na jednostkach po 320 GPU, po jednym ekspercie na kartę, i duplikuje najczęściej wybieranych ekspertów, bo najbardziej obciążony ekspert wyznacza czas całego kroku.

### Kiedy MoE, a kiedy model gęsty

- MoE daje lepszą jakość przy tej samej ilości obliczeń i tańszy trening. Model gęsty tej samej łącznej wielkości zwykle jest lepszy, ale liczy wielokrotnie więcej na token. Większość czołowych modeli open-weight od 2025 roku to MoE, dlatego podaje się dwie liczby: parametry łącznie i aktywne (np. Qwen3-235B-A22B).
- Na sprzęcie z dużą, ale powolną pamięcią, jak Mac z pamięcią wspólną, MoE działa dla jednej osoby zaskakująco szybko, bo czyta tylko aktywne parametry. gpt-oss-120b (117 mld parametrów, 5,1 mld aktywnych) mieści się dzięki MXFP4 na jednej karcie 80 GB. Ponieważ czyta tylko aktywnych ekspertów, duże MoE ruszy też na jednej domowej karcie, jeśli wagi ekspertów zostaną w RAM-ie procesora, a attention na GPU (llama.cpp `--cpu-moe` albo `--n-cpu-moe`).
- Duże MoE w self-hostingu opłaca się dopiero przy ruchu, który wypełni batch na wielu kartach. Przy mniejszym ruchu taniej wychodzi API albo mniejszy model (zobacz „Modele open-weight”).

### Sprawdź się

**Pytanie:** Czym jest MoE i jakie ma konsekwencje dla serwowania?

**Krótka odpowiedź:** W MoE warstwę MLP zastępuje wielu ekspertów, a router dla każdego tokena w każdej warstwie wybiera kilku. Na każdy token liczone są tylko aktywne parametry, na przykład 37 z 671 mld w DeepSeek-V3, więc jakość jest bliższa dużemu modelowi przy obliczeniach małego. Ceną jest pamięć, bo wszyscy eksperci muszą być załadowani, i serwowanie: przy większym batchu tokeny trafiają prawie do wszystkich ekspertów, więc potrzeba dużo większych batchy, expert parallelism z komunikacją all-to-all między kartami i pilnowania równego obciążenia ekspertów.

### Pytania pogłębiające

- **Model MoE ma 5 mld aktywnych parametrów. Czy będzie działał jak model 5B?** Liczy jak 5B, ale w pamięci musi leżeć całość. Przy jednej rozmowie decode jest szybki jak w małym modelu. Przy średnim batchu krok czyta prawie wszystkich ekspertów, więc kosztuje jak czytanie dużego modelu przy małej ilości liczenia. Dopiero bardzo duży batch zbliża koszt na token do modelu 5B.
- **Po co wyrównywanie obciążenia w treningu?** Bez niego router zawęża wybór do kilku ulubionych ekspertów, którzy uczą się coraz lepiej i są wybierani coraz częściej, a reszta parametrów się marnuje. W serwowaniu nierówne obciążenie oznacza, że najbardziej obciążony ekspert wyznacza czas kroku.
- **Jak rozłożysz duże MoE na karty?** Attention zwykle przez tensor albo data parallelism, ekspertów przez expert parallelism: każda karta trzyma część ekspertów, a tokeny w każdej warstwie wymienia się all-to-all. Kluczowe są szybkie połączenia między kartami i duplikowanie najczęściej wybieranych ekspertów. DeepSeek-V3 tak robi na 320 GPU w decode.

### Źródła

- [Hugging Face: Mixture of Experts Explained](https://huggingface.co/blog/moe)
- [Jiang i in.: Mixtral of Experts (2024)](https://arxiv.org/abs/2401.04088)
- [DeepSeek-AI: DeepSeek-V3 Technical Report (2024)](https://arxiv.org/abs/2412.19437)
- [Maarten Grootendorst: A Visual Guide to Mixture of Experts](https://newsletter.maartengrootendorst.com/p/a-visual-guide-to-mixture-of-experts)

---

## Wybór modelu

*Wybór modelu*

*Ostatnia zmiana: 28 września 2026*

Model dobierasz do zadania, nie do rankingu: bierzesz najtańszą konfigurację – model, poziom rozumowania i dostawcę – która przechodzi twój zestaw ewaluacyjny w wymaganym czasie i limitach. Publiczne benchmarki podpowiadają tylko, kogo warto sprawdzić.

**Po ludzku:** Rekrutacja na konkretne stanowisko. Nie zatrudniasz osoby z najlepszym wynikiem w ogólnym teście, tylko dajesz kandydatom to samo zadanie próbne z twojej pracy i bierzesz tego, kto zrobi je dobrze i na czas za najniższą stawkę. Rankingi i dyplomy mówią tylko, kogo zaprosić na rozmowę. Zadanie próbne zostaje w szufladzie, więc gdy ktoś odchodzi, następcę sprawdzasz w godzinę.

*Interaktywny widżet na stronie: Ustaw próg jakości i limit czasu. Zobacz, który model jest najtańszy wśród tych, które przechodzą, a potem przełącz na publiczny ranking.*

### Od zadania do modelu

- Zaczynasz od zestawu przypadków z prawdziwego ruchu i progu, który model ma przejść (temat „Ewaluacje”). Puszczasz go na kilku kandydatach, każdy przypadek kilka razy, i bierzesz najtańszego, który przechodzi.
- Modele dzielą się na półki. Czołowe (frontier) biorą trudne rozumowanie, długie zadania agentowe i kod. Średnie wystarczają do większości pracy produkcyjnej. Małe i szybkie robią klasyfikację, ekstrakcję, routing i proste kroki w dużej skali.
- Poziom rozumowania to druga gałka tego samego wyboru. W poradnikach o wyborze modelu Anthropic pisze, że strojenie wysiłku często daje więcej niż zmiana modelu, a OpenAI radzi zostać przy najlżejszym ustawieniu, które spełnia próg jakości (stan na wrzesień 2026). Porównujesz więc pary model–poziom, nie same modele.
- Jeden model na cały system to rzadko optimum. W kaskadzie najpierw odpowiada tani model, a do droższego albo na wyższy poziom rozumowania trafia tylko to, co odrzuci walidator, testy albo niska pewność (temat „LLM na produkcji”). W agencie dobierasz model do kroku: mały streszcza wyniki narzędzi, czołowy planuje i podejmuje trudne decyzje.

### Koszt i czas

- Liczysz koszt ukończonego zadania, nie cenę za token: koszt tokenów ze wszystkich prób, także nieudanych, dzielisz przez liczbę zaliczonych zadań. Mocniejszy model często potrzebuje mniej tur i poprawek. W pomiarach Anthropic na podzbiorze SWE-bench Pro model Fable 5.1 na niskim poziomie wysiłku rozwiązał 88,6% zadań za 0,54 USD na rozwiązane zadanie, a Sonnet 5, pięć razy tańszy za token, 77,4% za 0,84 USD. W długim researchu było odwrotnie: Fable 5.1 wyszedł ok. cztery razy drożej na zadanie. To liczby producenta, więc sprawdzasz je na swoim zadaniu.
- Cennik nie pokazuje trzech rzeczy. Za tokeny rozumowania płacisz jak za wyjście, także za niewidoczne (temat „Modele rozumujące”). Modele różnią się gadatliwością, więc na tym samym zadaniu jeden potrafi wygenerować kilka razy więcej tokenów niż drugi. Rabat za cache też się różni: u Anthropic odczyt kosztuje zwykle 10% ceny wejścia, w Opus 5.5 – 5%, a w Fable 5.1 – 2,5% (stan na wrzesień 2026, temat „Prompt caching”). W agencie, który większość wejścia czyta z cache’u, to potrafi odwrócić porównanie.
- Czas to dwie liczby: czas do pierwszego tokena (TTFT) i tokeny na sekundę po nim. Wysiłek rozumowania przesuwa obie. Pierwsze słowo odpowiedzi przychodzi dopiero po całym myśleniu, a użyteczne tokeny na sekundę spadają, bo część generowanych tokenów to myślenie, którego użytkownik nie widzi. Dlatego Artificial Analysis mierzy osobno czas do pierwszego tokena odpowiedzi. Wolniejszemu modelowi pomaga streaming, niższy poziom rozumowania albo przeniesienie kroku tam, gdzie nikt nie czeka.

### Limity, funkcje i lokalizacja danych

- Okno kontekstu z karty modelu to górna granica, nie obietnica: jakość spada na długo przed jego końcem (temat „Okno kontekstowe i agent”), więc testujesz na swoich realnych długościach. Limit wyjścia jest osobny i dużo mniejszy, a myślenie się do niego wlicza.
- Limity zapytań zależą od poziomu konta (tier), który rośnie z historią wydatków. U Anthropic nowa organizacja może zacząć od niższego tieru, a każdy tier ma miesięczny limit wydatków, po którym API zwraca 429 do początku kolejnego miesiąca (stan na wrzesień 2026). Limity dla konkretnego modelu sprawdzasz przed wdrożeniem, nie po nim.
- Tryb ścisły structured output, równoległe wywołania narzędzi, obrazy, logprobs, batch i prompt caching nie działają w każdym modelu i u każdego dostawcy (temat „Wymuszanie formatu”). Brak jednej funkcji potrafi przekreślić model, który wygrywa na evalu.
- Miejsce inferencji i miejsce przechowywania danych to dwa osobne ustawienia. Przetwarzanie w wybranym regionie obejmuje tylko część modeli i funkcji, bywa dostępne po akceptacji dostawcy i kosztuje więcej: w OpenAI i Anthropic ok. 10% dla nowszych modeli (stan na wrzesień 2026). Własne API Anthropic pozwala przypiąć inferencję tylko do USA, a region w UE dają Bedrock i Google Cloud. Zerowa retencja (ZDR) wymaga umowy i nie obejmuje funkcji ze stanem (temat „LLM na produkcji”).

### Jak czytać benchmarki

- Zadania z publicznych zestawów trafiają do danych treningowych, a gdy czołówka zbliża się do sufitu, różnice giną w szumie i w błędach samego zestawu. W lutym 2026 OpenAI przestał podawać wyniki w SWE-bench Verified: w zbadanej części zadań 59,4% miało wadliwe testy, które odrzucały poprawne rozwiązania, a wszystkie sprawdzone czołowe modele widziały w treningu część zadań i rozwiązań.
- SWE-bench Verified to 500 poprawek błędów z 12 repozytoriów w Pythonie. Mierzy małe, dobrze opisane łatki w popularnych projektach, a nie pracę w twoim repozytorium, z twoimi konwencjami i zmianami w wielu plikach.
- LMArena mierzy, którą odpowiedź woli głosujący, a głosujący wolą dłuższe i bogato sformatowane. Po uwzględnieniu stylu (style control, 2024) najsilniejszym czynnikiem okazała się długość, a ranking się przetasował: GPT-4o-mini spadł z 6. na 11. miejsce, a Claude 3 Opus awansował z 16. na 10. To miara preferencji w czacie, nie poprawności w twoim zadaniu.
- Wynik od producenta i wynik niezależny to różne pomiary. Producent wybiera harness, poziom rozumowania, liczbę prób i podzbiór zadań. Niezależne zespoły, jak Artificial Analysis czy Epoch AI, puszczają wszystkie modele w jednym harnessie, a Epoch zauważa, że wynik na SWE-bench mocno zależy od scaffoldu. Porównujesz tylko liczby z jednego źródła i jednego harnessu (temat „Harness agenta kodującego”).
- Ten sam model u różnych dostawców to nie ten sam produkt: różnią się kwantyzacja, szablon czatu, parser wywołań narzędzi i ustawienia serwowania. W pomiarze Moonshot z listopada 2025 Kimi K2 Thinking wywoływał narzędzia zgodnie ze schematem w 100% przez oficjalne API, a u kilku zewnętrznych hostów w 83–87%. Testujesz konkretny endpoint, nie nazwę modelu.

### Wycofywanie i zmiana modelu

- Modele wycofuje się szybko. Anthropic uprzedza co najmniej 60 dni wcześniej: Claude Sonnet 4 z maja 2025 dostał datę wycofania w kwietniu 2026 i przestał działać 15 czerwca 2026. Przypinasz konkretną wersję zamiast aliasu, a zestaw ewaluacyjny trzymasz w repozytorium, żeby zmiana modelu była jednym uruchomieniem i canary, a nie projektem (temat „Czy model głupieje?”).
- Wywołania modelu idą przez jedną cienką warstwę, własną albo gateway, która zna ceny, limity i fallbacki. Wtedy zmiana modelu lub dostawcy to konfiguracja. Prompt i tak trzeba przestroić, bo nowy model inaczej czyta te same instrukcje.
- Otwarty czy zamknięty model to osobna decyzja o kontroli nad danymi, wersją i kosztem przy dużym ruchu (temat „Modele open-weight”). A zanim wybierzesz model, sprawdź, czy zadanie w ogóle potrzebuje LLM-a (temat „Kiedy nie używać LLM-a: klasyfikatory i System One”).

### Sprawdź się

**Pytanie:** Jak wybrać model do nowej funkcji i czemu publiczny ranking tego nie rozstrzyga?

**Krótka odpowiedź:** Punktem wyjścia jest zadanie i własny zestaw ewaluacyjny z progiem jakości. Kandydatów z kilku półek – czołowej, średniej i małej – puszcza się na tym zestawie z różnymi poziomami rozumowania i bierze najtańszą konfigurację, która przechodzi próg w wymaganym czasie. Koszt liczy się na ukończone zadanie, z tokenami rozumowania, gadatliwością modelu i rabatem za cache, a nie z cennika za token. Do tego limity: efektywna długość kontekstu, limit wyjścia, limity zapytań, structured output, tool calling i region danych. Publiczne rankingi bywają skażone, nasycone, zależne od stylu i harnessu, więc tylko zawężają listę kandydatów. Wersję się przypina, a zestaw zostaje w repozytorium, żeby zmiana modelu była jednym uruchomieniem.

### Pytania pogłębiające

- **Najtańszy model ma 81% przy progu 80%. Czy to wystarczy?** Nie bez sprawdzenia szumu. Przy 50 przypadkach przedział ufności ma ok. ±11 punktów procentowych, więc 81% i 80% są nie do odróżnienia. Potrzeba więcej przypadków albo powtórzeń, porównania w parach z droższym kandydatem i osobnego wyniku dla przypadków krytycznych. Jeśli tani model zawodzi na jednym typie przypadków, ten typ można kierować do droższego.
- **Model A kosztuje za token pięć razy więcej niż B. Kiedy wyjdzie taniej?** Gdy kończy zadanie w mniejszej liczbie kroków: mniej tur agenta, mniej poprawek, krótsze myślenie na niższym poziomie wysiłku i więcej zaliczonych zadań. Koszt ukończonego zadania to koszt wszystkich prób podzielony przez liczbę udanych, więc model, który zalicza 60% zadań, 40% prób opłaca na darmo. Rozstrzyga pomiar na własnym zestawie z pełnym rozliczeniem tokenów, także z cache’u i rozumowania.
- **Jak zbudować routing między tanim a drogim modelem?** Najprościej kaskadą z weryfikatorem: tani model odpowiada, a walidator schematu, testy albo sędzia decydują, czy wynik przyjąć, czy powtórzyć zadanie na mocniejszym modelu lub wyższym poziomie rozumowania. Router, który z góry ocenia trudność, sam się myli, więc mierzy się jego trafność i koszt pomyłek. W pomiarach Anthropic uruchamianie wszystkiego na niskim wysiłku i ponawianie nieudanych zadań na wysokim utrzymało wynik za ok. połowę kosztu, ale działa to tylko tam, gdzie jest wiarygodny sygnał porażki.
- **Nowy model ma wyższy wynik na publicznym benchmarku. Czy zmieniać?** Wynik publiczny tylko kwalifikuje kandydata. Liczy się porównanie w parach i z powtórzeniami na własnym zestawie, tym samym, który przeszedł obecny model, plus koszt na zadanie, p95 czasu i obsługa używanych funkcji. Prompt zwykle trzeba przestroić, więc porównuje się najlepszą wersję promptu dla każdego modelu. Potem canary na części ruchu i obserwacja sygnałów z produkcji.
- **Po co warstwa abstrakcji nad API, skoro używasz jednego dostawcy?** Bo dostawca wycofuje wersje zwykle po roku lub dwóch, ma awarie i limity, a lepszy model może pojawić się u innego. Jedna warstwa trzyma w jednym miejscu nazwy modeli, ceny, limity, fallback i logowanie tokenów, więc zmiana to konfiguracja i przebieg evali. Różnic w funkcjach, takich jak format narzędzi, myślenie czy cache, nie ukryje, więc powinna być cienka.

### Źródła

- [Anthropic: Optimizing for cost and intelligence (koszt na ukończone zadanie, wysiłek, kaskady)](https://platform.claude.com/docs/en/about-claude/models/optimizing-for-cost-and-intelligence)
- [LMSYS: Does style matter? Style control w Chatbot Arena (2024)](https://lmsys.org/blog/2024-08-28-style-control/)
- [Epoch AI: SWE-bench Verified, przegląd benchmarku (z audytem OpenAI z 2026)](https://epoch.ai/benchmarks/swe-bench-verified/review)
- [Artificial Analysis: metodologia pomiaru TTFT i szybkości](https://artificialanalysis.ai/methodology/performance-benchmarking)
- [Moonshot AI: K2 Vendor Verifier (ten sam model u różnych hostów)](https://github.com/MoonshotAI/K2-Vendor-Verifier)

---

## Modele open-weight

*Wybór modelu*

*Ostatnia zmiana: 28 września 2026*

Open-weight znaczy: możesz pobrać wagi, czyli wyuczone macierze modelu, i uruchomić go na własnym sprzęcie. To nie to samo co open-source: zwykle nie dostajesz danych ani kodu treningu, a licencja może ograniczać użycie.

**Po ludzku:** Zamknięty model to restauracja: jesz, co podadzą, i nie zajrzysz do kuchni. Open-weight to gotowe danie na wynos: podgrzejesz i doprawisz u siebie, ale przepisu nie znasz. Open-source to danie razem z przepisem.

*Interaktywny widżet na stronie: Przełącz rodzaj modelu i zobacz, co dostajesz w paczce i co z tego wynika.*

### Co dostajesz, a czego nie

- Wagi, kod inferencji i tokenizer wystarczą, żeby model uruchomić, skwantyzować i dotrenować, na przykład metodą LoRA (zobacz „Fine-tuning i LoRA”). Nie wystarczą, żeby go odtworzyć albo sprawdzić, na czym się uczył.
- Definicja Open Source AI od OSI (wersja 1.0 z 2024 roku) wymaga wag, pełnego kodu treningu i uruchamiania oraz opisu danych na tyle szczegółowego, żeby kompetentna osoba mogła zbudować podobny system, wszystko na warunkach zatwierdzonych przez OSI: użycie w dowolnym celu bez pytania o zgodę. Samych danych publikować nie trzeba, ale publiczne i zewnętrzne dane treningowe trzeba wymienić i wskazać, skąd je wziąć. Spełnia to niewiele modeli, np. OLMo od Ai2; licencje z ograniczeniami użycia, jak licencja Llama, odpadają już przez same warunki.
- Licencje różnią się mocno. Apache 2.0 i MIT (np. gpt-oss, Qwen3, DeepSeek-R1) pozwalają prawie na wszystko. Licencje Llama (3.1 i 4) wymagają osobnej zgody Mety, jeśli w dniu premiery modelu twoje produkty miały ponad 700 mln aktywnych użytkowników miesięcznie, oraz oznaczenia „Built with Llama”. Dla modeli multimodalnych (Llama 3.2 Vision, Llama 4 Scout i Maverick) polityka dopuszczalnego użycia w ogóle nie udziela licencji osobom mieszkającym w UE ani firmom z siedzibą w UE; nie dotyczy to końcowych użytkowników produktu zbudowanego na takim modelu.

### Po co firmom self-hosting

- Dane nie opuszczają twojej infrastruktury: własna chmura, serwerownia, nawet sieć bez dostępu do internetu. W branżach regulowanych to bywa jedyna dopuszczalna droga.
- Wersja jest zamrożona: nikt nie podmieni wag, ustawień ani stosu serwującego bez twojej wiedzy (zobacz „Czy model głupieje?”). To działa tylko wtedy, gdy hostujesz sam.
- Pełna kontrola nad modelem i inferencją: fine-tuning, własna kwantyzacja, dostęp do logitów, dowolne wymuszanie formatu, brak limitów zapytań narzuconych przez dostawcę.

*Interaktywny widżet na stronie: Ustaw cenę API, koszt węzła, miesięczny wolumen i to, ile obsłuży jeden węzeł. Zobacz, od jakiego obciążenia własne GPU zaczynają się opłacać.*

### Koszt self-hostingu i pułapki

- Węzeł kosztuje tyle samo przy 5% i przy 90% obciążenia, a ruch ma szczyty i doliny. Realne średnie obciążenie jest dużo niższe niż 100%, więc liczysz koszt przy nim, nie przy pełnym. Do tego ludzie: serwowanie (vLLM, SGLang), monitoring, aktualizacje, bezpieczeństwo. Wagi ładujesz jako safetensors, od zaufanego wydawcy i z przypiętą rewizją: checkpoint w formacie pickle może przy wczytaniu uruchomić kod, a `trust_remote_code` uruchamia Pythona z repozytorium na twoich serwerach.
- Trzecia droga to ten sam otwarty model z API zewnętrznego hosta: bez własnych GPU i zwykle taniej niż zamknięta czołówka. Dane znów wychodzą na zewnątrz, a host może zmienić kwantyzację albo stos serwujący.
- Ten sam model u różnych hostów działa różnie: inna kwantyzacja, inny szablon czatu, inna obsługa tool callingu i długiego kontekstu. Moonshot zmierzył to dla Kimi K2 (listopad 2025): poprawność schematu wywołań narzędzi od 100% w oficjalnym API do 72% u jednego z hostów, przez nieaktualne wersje silnika, błędne identyfikatory wywołań i brak wymuszania formatu. Testujesz konkretny endpoint własnym zestawem ewaluacyjnym, nie nazwę modelu (zobacz „Ewaluacje” i „LLM na produkcji”).
- W najtrudniejszych zadaniach zamknięta czołówka zwykle wyprzedza modele otwarte. Różnica bywa mała i zmienia się z każdym wydaniem, więc rozstrzyga pomiar na twoim zadaniu, nie ranking.

### Sprawdź się

**Pytanie:** Open-weight a open-source: jaka różnica i kiedy self-hostować?

**Krótka odpowiedź:** Open-weight znaczy, że można pobrać wagi i uruchomić model u siebie. Open-source według definicji OSI wymaga też kodu treningu, szczegółowego opisu danych i warunków bez ograniczeń użycia, a to rzadkość; licencje wag często ograniczają użycie, np. skalą albo regionem. Self-hosting daje kontrolę: dane zostają w firmie, wersja się nie zmienia, można dotrenować i skwantyzować. Płacisz za GPU i ludzi, a węzeł kosztuje tyle samo pusty i pełny, więc to się opłaca przy dużym, stałym ruchu albo twardych wymaganiach regulacyjnych. Pośrednia droga to otwarty model u zewnętrznego hosta.

### Pytania pogłębiające

- **Co sprawdzasz w licencji?** Użycie komercyjne, progi skali (np. 700 mln aktywnych użytkowników miesięcznie w Llama), ograniczenia geograficzne (Meta nie udziela licencji na multimodalne modele Llama osobom mieszkającym w UE ani firmom z siedzibą w UE), listę zakazanych zastosowań, warunki dla modeli pochodnych i trenowania innych modeli na wynikach oraz wymogi atrybucji.
- **Jak porównać hosta otwartego modelu z oryginałem?** Tym samym zestawem ewaluacyjnym na konkretnym endpoincie, z naciskiem na tool calling, wymuszanie formatu i długi kontekst, bo tam różnice w kwantyzacji i szablonie czatu wychodzą najpierw. Zapisujesz też, jaką kwantyzację i wersję host deklaruje.
- **Kiedy odradzisz self-hosting mimo niższej ceny za token?** Gdy ruch jest nieregularny i węzeł przez większość czasu stoi pusty, gdy zespół nie ma ludzi do utrzymania serwowania albo gdy zadanie wymaga jakości czołowego modelu zamkniętego. Koszt liczysz przy realnym średnim obciążeniu, nie przy 100%.
- **Klient wymaga, żeby dane nie opuszczały UE. Jakie masz opcje?** Model zamknięty u dostawcy chmury w regionie UE z umową powierzenia przetwarzania danych, otwarty model u hosta w UE albo self-hosting. Wybór zależy od tego, czy wystarczy umowa i region, czy wymagana jest pełna kontrola nad infrastrukturą.

### Źródła

- [Open Source Initiative: The Open Source AI Definition 1.0](https://opensource.org/ai/open-source-ai-definition)
- [Meta: licencja Llama 4](https://github.com/meta-llama/llama-models/blob/main/models/llama4/LICENSE)
- [Meta: polityka dopuszczalnego użycia Llama 4](https://github.com/meta-llama/llama-models/blob/main/models/llama4/USE_POLICY.md)
- [Moonshot AI: K2 Vendor Verifier (różnice między hostami)](https://github.com/MoonshotAI/K2-Vendor-Verifier)
- [Ai2: OLMo, w pełni otwarty model](https://allenai.org/olmo)

---

## Kiedy nie używać LLM-a: klasyfikatory i System One

*Wybór modelu*

*Ostatnia zmiana: 28 września 2026*

Gdy system potrzebuje decyzji, a nie tekstu (etykiety, oceny, tak albo nie), LLM i tak pisze ją token po tokenie, a jego prawdopodobieństwa często są niedostępne albo źle skalibrowane. Model niegeneratywny bywa szybszy, tańszy i lepiej skalibrowany; LLM wygrywa, gdy przestrzeń odpowiedzi jest otwarta albo zadanie wymaga rozumowania. System One od TypeSafe służy tu za przykład nowego typu modelu.

**Po ludzku:** Różnica między napisaniem uzasadnienia na pół strony a zaznaczeniem kratek w ankiecie. Do ankiety nie trzeba pisarza, ale ankieta ma tylko te kratki, które ktoś wcześniej przewidział.

*Interaktywny widżet na stronie: Uruchom oba tory: LLM pisze JSON z trzema polami token po tokenie, Jev (model System One od TypeSafe) dostaje te same trzy pytania w jednym wywołaniu.*

### Klasyfikator czy LLM: czym podjąć decyzję

- Dostrojony enkoder (model typu BERT) albo embeddingi z regresją logistyczną: jeden przebieg, milisekundy, ułamek centa, działa obok usługi, a prawdopodobieństwa da się skalibrować na zbiorze walidacyjnym. Ceną są oznaczone dane dla każdego zadania i ponowny trening przy każdej nowej klasie.
- Zero-shot, bez danych treningowych: model NLI ocenia, czy etykieta zapisana w języku naturalnym wynika z tekstu (Yin i in., 2019), a cross-encoder ocenia pary tekst–etykieta. Tani punkt odniesienia dla wszystkiego innego.
- LLM jako klasyfikator: prompt z listą etykiet i odpowiedź jednym tokenem odczytana z logprobs. To jeden krok decode po prefillu, więc też szybko, ale każde pytanie to osobne żądanie albo dłuższe wyjście. Logprobs często nie ma (Claude API nigdy, aktualne modele OpenAI tylko przy poziomie rozumowania none, stan na wrzesień 2026), a post-training psuje kalibrację: w raporcie o GPT-4 model bazowy był dobrze skalibrowany, a po post-trainingu wyraźnie gorzej. Kalibrację trzeba zmierzyć i poprawić, np. przez temperature scaling.
- LLM wygrywa, gdy potrzebny jest tekst, kod, uzasadnienie, wieloetapowe rozumowanie, arytmetyka albo narzędzia, gdy odpowiedzi nie da się z góry zamknąć w liście i przy małym wolumenie, kiedy prompt jest tańszy niż zbiór z etykietami. Ścisły structured output też pozwala LLM-owi zwracać typowane odpowiedzi (zobacz „Wymuszanie formatu”), więc realne różnice to koszt, opóźnienie i jakość prawdopodobieństw. Który LLM wybrać, opisuje temat „Wybór modelu”.

### Przykład: System One (twierdzenia producenta)

- Według dokumentacji TypeSafe (wrzesień 2026, wersja jev-1.13) model Jev przyjmuje tekstowy „stan” (string, obiekt JSON albo listę tekstów) i typowane pytania: Choice (wybór z listy), Score (poziom na opisanej skali) i Noul (prawdopodobieństwo odpowiedzi „tak”). Choice i Score zwracają rozkład i pole `confidence`. Tekstu nie generuje. Producent pozycjonuje go jako model, który w odróżnieniu od dostrojonego enkodera nie wymaga trenowania pod zadanie.
- Wszystkie pytania z jednego żądania są oceniane równolegle i niezależnie względem tego samego stanu. Producent pisze, że dodawanie pytań prawie nie wydłuża czasu odpowiedzi, ale żadnych czasów nie publikuje. Cennik: 0,042 USD za milion tokenów wejściowych, wyjście darmowe. Limit: do 64 tys. tokenów na żądanie, z czego stan plus najdłuższe pytanie najwyżej 32 tys. Głównym językiem jest angielski.
- Model trenowano pod kalibrację metodą, którą producent nazywa RLCD (reinforcement learning for calibrated decisions). Sam producent zastrzega, że kalibracja dotyczy grup decyzji, nie pojedynczej odpowiedzi. Dokumentacja nie opisuje architektury ani nie podaje niezależnych porównań, więc cała ta sekcja to twierdzenia do sprawdzenia na własnych danych.
- Ograniczenia, które producent opisuje dla jev-1.13: nie liczy wiarygodnie, słabo porównuje daty i liczby, czyta pytania dosłownie, gubi się przy pytaniach pośrednich i w dużym stanie pełnym nieistotnych danych, a treść stanu może nim sterować jak prompt injection. Odpowiedzi na pytanie i jego zaprzeczenie nie muszą sumować się do 1.

*Interaktywny widżet na stronie: Przesuń próg: decyzje powyżej wykonuje automat, poniżej idą do LLM-a lub człowieka. Patrz, ile pomyłek automat przepuści.*

### Jak wpiąć model decyzyjny w system

- Wzorzec: szybki model decyzyjny rozstrzyga proste przypadki, a przy niskiej pewności sprawa idzie do LLM-a z rozumowaniem albo do człowieka (zobacz „LLM na produkcji”). Automat opłaca się, gdy (1 − p) × koszt pomyłki < koszt eskalacji. Przy pomyłce za 100 zł i eskalacji za 5 zł próg wynosi p > 0,95.
- Kalibrację sprawdzasz sam, niezależnie od modelu: grupujesz decyzje według deklarowanego prawdopodobieństwa i porównujesz z trafnością w każdej grupie (wykres kalibracji, błąd ECE). Osobno dla każdego typu pytania i języka, bo kalibracja na angielskim nie gwarantuje kalibracji na polskim.
- Arytmetyka, daty i twarde reguły zostają w kodzie. Po strojeniu progów przypinasz wersję modelu (dla Jev `jev-1.13.0`, nie alias `jev-latest`): alias przesuwa się przy każdym wydaniu, a razem z nim rozkład prawdopodobieństw.

### Sprawdź się

**Pytanie:** Kiedy klasyfikator albo model decyzyjny, taki jak System One, wygrywa z LLM-em, a kiedy nie?

**Krótka odpowiedź:** Model niegeneratywny wygrywa, gdy odpowiedzią jest etykieta, ocena albo tak/nie z zamkniętej listy, a liczą się wolumen, opóźnienie albo skalibrowane prawdopodobieństwa. Dostrojony enkoder odpowiada w milisekundach, ale wymaga oznaczonych danych dla każdego zadania; enkodery zero-shot oparte na NLI ich nie potrzebują. LLM obywa się bez danych, ale pisze decyzję token po tokenie, a jego logprobs często są niedostępne albo po post-trainingu źle skalibrowane. Modele decyzyjne, takie jak Jev od TypeSafe, obiecują typowane odpowiedzi ze skalibrowanymi prawdopodobieństwami w jednym wywołaniu, co trzeba zmierzyć na własnych danych. LLM wygrywa przy tekście, rozumowaniu, narzędziach i otwartej przestrzeni odpowiedzi. Wzorzec: szybki model rozstrzyga przypadki o wysokiej pewności, a resztę eskaluje do LLM-a albo człowieka.

### Pytania pogłębiające

- **Kiedy LLM nadal jest lepszy?** Gdy potrzebny jest tekst, kod, wyjaśnienie decyzji, wieloetapowe rozumowanie, arytmetyka albo wywoływanie narzędzi. Także gdy przestrzeni odpowiedzi nie da się z góry zamknąć w liście opcji albo wolumen jest za mały, żeby opłacało się zbierać oznaczone dane.
- **Jak sprawdzić kalibrację?** Na własnych danych z etykietami: dzielisz decyzje na przedziały deklarowanego prawdopodobieństwa i w każdym porównujesz średnie prawdopodobieństwo z faktyczną trafnością. Średnią ważoną różnicę raportujesz jako ECE. Osobno dla każdego typu pytania i języka.
- **Czym model decyzyjny różni się od klasyfikatora na LLM-ie z logprobs?** Klasyfikator z jednym tokenem etykiety to jeden krok decode po prefillu, więc też jest szybki. Każde pytanie to jednak osobne żądanie albo dłuższe wyjście, logprobs często nie ma (Claude API nigdy, aktualne modele OpenAI tylko z wyłączonym rozumowaniem), a post-training nie optymalizuje ich pod kalibrację i zwykle psuje to, co dał pretraining. Rozstrzyga pomiar trafności, kalibracji, opóźnienia i kosztu na tym samym zbiorze.
- **Jak ustawisz próg eskalacji?** Z kosztów: automat działa, gdy (1 − p) × koszt pomyłki jest mniejszy niż koszt eskalacji. Potem sprawdzasz na danych, czy przy tym progu rzeczywisty odsetek błędów zgadza się z oczekiwanym, i powtarzasz to po każdej zmianie wersji modelu.

### Źródła

- [Guo i in.: On Calibration of Modern Neural Networks (2017)](https://arxiv.org/abs/1706.04599)
- [Yin, Hay i Roth: Benchmarking Zero-shot Text Classification (2019)](https://arxiv.org/abs/1909.00161)
- [TypeSafe: System One (dokumentacja)](https://docs.typesafe.ai/concepts/system-one)
- [TypeSafe: Models (ceny, limity, aliasy)](https://docs.typesafe.ai/models)
- [TypeSafe: Jev 1.13 jaggedness (znane ograniczenia)](https://docs.typesafe.ai/model-jaggedness/jev-1.13)

---

## Czy model głupieje?

*Wybór modelu*

*Ostatnia zmiana: 28 września 2026*

Wagi przypiętej wersji modelu się nie zmieniają, ale system, który je serwuje, zmienia się stale: sprzęt, kompilatory, sampler, routing, system prompt aplikacji i ustawienia domyślne. Za aliasem albo nazwą modelu w aplikacji czatu można podmienić nawet wagi, a nazwa zostaje ta sama. Do tego dostawca ma skończoną pulę kart, z której biorą i trening następnego modelu, i obecni użytkownicy.

**Po ludzku:** Jedna kuchnia i dwa zamówienia naraz: wielkie przyjęcie na przyszły miesiąc, czyli trening, i bieżący goście, czyli użytkownicy. Palników nie przybywa. W przypiętej wersji przepis się nie zmienia, ale nowy piec albo pomylona przyprawa zmienią smak.

*Interaktywny widżet na stronie: Przesuń trening i popyt. Zobacz, kiedy inferencji zaczyna brakować mocy i co wtedy widzi użytkownik.*

### Co się zmienia, gdy wagi stoją

- Ten sam model działa na różnym sprzęcie i stosie. Anthropic podaje, że serwuje Claude’a na AWS Trainium, GPU NVIDIA i TPU Google. Inna precyzja, kompilator albo implementacja samplera to trochę inne liczby na wyjściu, a błąd w jednym z tych miejsc psuje tylko część ruchu.
- Brak mocy widać najpierw w opóźnieniach i dostępności: kolejki, dłuższy czas do pierwszego tokena, wolniejsze generowanie przy większych batchach, błędy przeciążenia, ostrzejsze limity. Nie obniża to jakości, ale obciążenie wyznacza rozmiar batcha, a przy kernelach, których wynik zależy od rozmiaru batcha, to samo zapytanie może dostać inne tokeny nawet przy temperaturze 0.
- Aplikacje, takie jak czat czy narzędzie do kodu, zmieniają system prompt, domyślny poziom rozumowania i sposób zarządzania kontekstem. To zmienia wyniki bez zmiany modelu i bez żadnej zmiany w API.

### Udokumentowane przypadki

- **Kwiecień 2025** (OpenAI, „Expanding on what we missed with sycophancy”). Tu wagi zmieniły się pod tą samą nazwą. 25 kwietnia aktualizacja GPT-4o w ChatGPT z nowym post-treningiem, m.in. z dodatkową nagrodą z ocen typu kciuk w górę i w dół, uczyniła model wyraźnie przymilnym; wycofywanie ruszyło 28 kwietnia. OpenAI podaje, że GPT-4o w ChatGPT dostał od premiery pięć dużych aktualizacji z nowym post-treningiem.
- **Sierpień i wrzesień 2025** (postmortem Anthropic z 17 września 2025). Trzy nakładające się błędy infrastruktury, wagi bez zmian. Od 5 sierpnia część żądań do Sonnet 4 trafiała na serwery skonfigurowane pod przyszły kontekst 1M tokenów, w najgorszej godzinie 31 sierpnia 16% żądań. Od 25 sierpnia błędna konfiguracja serwerów TPU powodowała wstawianie niepasujących tokenów, np. znaków tajskich lub chińskich w angielskich odpowiedziach. Zmiana w wyborze tokenów odsłoniła też błąd kompilatora XLA dla TPU, przez który przybliżone top-k czasem gubiło najbardziej prawdopodobny token. Poprawki weszły między 2 a 18 września.
- **Marzec i kwiecień 2026** (postmortem z 23 kwietnia 2026). Trzy zmiany w Claude Code, Claude Agent SDK i Claude Cowork; API nie zostało dotknięte. 4 marca domyślny poziom rozumowania obniżono z high na medium, żeby skrócić opóźnienia; cofnięto to 7 kwietnia. 26 marca błąd w mechanizmie, który po godzinie bezczynności miał raz usunąć stare bloki myślenia, sprawił, że usuwał je w każdej kolejnej turze, więc model wydawał się zapominalski i się powtarzał; naprawiono 10 kwietnia. 16 kwietnia dodano do system promptu limit długości odpowiedzi, który w jednej z ewaluacji obniżył wynik o 3%; cofnięto 20 kwietnia.
- Według obu postmortemów Anthropic przyczyną były błędy infrastruktury i decyzje produktowe uzasadniane opóźnieniem i długością odpowiedzi, a nie brak mocy. W 2025 roku Anthropic napisał wprost, że nigdy nie obniża jakości modelu z powodu popytu, pory dnia ani obciążenia serwerów, a w 2026, że nigdy celowo nie degraduje modeli.

### Hipoteza i złudzenie

- Hipoteza: dostawca po cichu serwuje mocniej skwantyzowany albo mniejszy wariant, gdy przed premierą brakuje kart. Technicznie możliwe u każdego dostawcy, ale publicznych dowodów brak. Traktuj to jak hipotezę do sprawdzenia pomiarem.
- Złudzenie: oczekiwania rosną, zadania robią się trudniejsze, sesje dłuższe, a długi kontekst sam obniża jakość (zobacz „Okno kontekstowe i agent”). Przy losowaniu pojedyncze złe odpowiedzi zdarzają się zawsze, więc anegdoty nie odróżnią regresji od szumu.

### Jak się bronić

- Przypinasz dokładny identyfikator snapshotu modelu, a nie alias, który może się przesunąć; w Claude od 4.6 identyfikator bez daty sam jest snapshotem. Jawnie ustawiasz poziom rozumowania i limit tokenów, a temperaturę tylko tam, gdzie model ją jeszcze przyjmuje: nowsze modele Claude (od Opus 4.7) i modele OpenAI z włączonym rozumowaniem odrzucają wartości inne niż domyślne (zobacz „Następny token”). Wersjonujesz prompt i definicje narzędzi (zobacz „LLM na produkcji”).
- Własny zestaw ewaluacyjny puszczasz cyklicznie na produkcyjnym endpoincie, z kilkoma powtórzeniami na przypadek, bo różnice rzędu kilku procent giną w szumie (zobacz „Ewaluacje”). Trace’y z produkcji pozwalają porównać zachowanie przed zmianą i po niej.
- Przypięta wersja też ma datę wycofania, więc migracja i tak przyjdzie; sprawdzasz ją tym samym zestawem. Pełna powtarzalność wymaga otwartego modelu na własnym, zamrożonym stosie z deterministycznymi kernelami, niezależnymi od rozmiaru batcha (zobacz „Modele open-weight”).

### Sprawdź się

**Pytanie:** Użytkownicy mówią, że model „zgłupiał”. Jak to wyjaśnisz i co zrobisz?

**Krótka odpowiedź:** Najpierw sprawdzasz, czy model w ogóle się zmienił: w aplikacji albo za aliasem ta sama nazwa może wskazywać nowe wagi, jak GPT-4o w ChatGPT w kwietniu 2025. Wagi przypiętej wersji się nie zmieniają, ale zmienia się wszystko wokół: sprzęt i kompilatory, sampler, routing, system prompt aplikacji, domyślny poziom rozumowania, limity. Oba udokumentowane spadki u Anthropic, z 2025 i 2026 roku, wynikały z takich przyczyn, a nie z podmiany wag. Ciche cięcie jakości z braku mocy jest technicznie możliwe, ale niepotwierdzone. Dlatego zamiast zgadywać, przypinasz wersję, ustawiasz parametry jawnie, cyklicznie puszczasz własne ewaluacje i porównujesz trace’y.

### Pytania pogłębiające

- **Jak odróżnić regresję u dostawcy od własnej?** Przypięta wersja, stały zestaw ewaluacyjny z kilkoma powtórzeniami i porównanie trace’ów. Jeśli prompt, narzędzia i parametry są te same, a spadek wyników wykracza poza szum, problem leży po stronie dostawcy. Wtedy zbierasz przykłady i zgłaszasz je.
- **Co przypinasz, żeby ograniczyć niespodziewane zmiany zachowania modelu?** Dokładny identyfikator snapshotu modelu, poziom rozumowania, limit tokenów, temperaturę tam, gdzie model ją jeszcze przyjmuje, wersję promptu i definicji narzędzi. Przypięta wersja też ma datę wycofania, więc migrację sprawdzasz tym samym zestawem ewaluacyjnym.
- **Czemu dostawca sam nie wyłapał regresji z 2025 roku?** Według postmortemu ewaluacje Anthropic nie uchwyciły spadku, raporty użytkowników były zaszumione, a zasady prywatności ograniczają wgląd inżynierów w rozmowy. Błędy dotykały części ruchu na części platform, więc średnie wyglądały dobrze. Wniosek dla ciebie: potrzebujesz ewaluacji na własnym ruchu.
- **Jak wykryć regresję w godzinę, a nie po tygodniu?** Kanarek: mały zestaw przypadków puszczany co godzinę na produkcyjnym endpoincie, plus sygnały z ruchu: odsetek niepoprawnego JSON-a, długość odpowiedzi, liczba wywołań narzędzi, ponowienia i poprawki użytkowników. Alert na odchylenie od wartości bazowej.

### Źródła

- [Anthropic: A postmortem of three recent issues (2025)](https://www.anthropic.com/engineering/a-postmortem-of-three-recent-issues)
- [Anthropic: An update on recent Claude Code quality reports (2026)](https://www.anthropic.com/engineering/april-23-postmortem)
- [OpenAI: Expanding on what we missed with sycophancy (2025)](https://openai.com/index/expanding-on-sycophancy/)
- [Anthropic: Model IDs and versioning](https://platform.claude.com/docs/en/about-claude/models/model-ids-and-versions)
- [Horace He: Defeating Nondeterminism in LLM Inference (2025)](https://thinkingmachines.ai/blog/defeating-nondeterminism-in-llm-inference/)

---

## Zaprojektuj system

*Ćwiczenia i powtórka*

*Ostatnia zmiana: 28 września 2026*

Znajomość mechanizmów to połowa pracy. Druga połowa to złożenie ich w system, który mieści się w budżecie i przetrwa produkcję: od wymagań przez architekturę i kompromisy do ewaluacji i awarii, z liczbami, a nie z nazwą ulubionego modelu.

**Po ludzku:** Rozmowa z architektem domu. Dobry najpierw pyta, ilu was jest, jaki macie budżet i jaką działkę, potem rysuje najprostszy dom, który spełnia te warunki, i mówi, co się stanie, gdy rodzina się powiększy. Kto zaczyna od wyboru dachówki, czyli od modelu, ten nie projektuje, tylko wybiera z katalogu.

*Interaktywny widżet na stronie: Wybierz scenariusz i przejdź go krok po kroku. Zanim przeczytasz krok, zdecyduj, co zrobiłbyś sam, potem porównaj. Każdy krok kończy się otwartym pytaniem, które warto rozstrzygnąć dalej.*

### Brama do LLM-ów dla firmy

- **Wymagania.** „Wspólny dostęp do LLM-ów dla 40 zespołów.” Dopytaj: ilu dostawców i czy potrzebny model u siebie (temat „Modele open-weight”), czy dane osobowe mogą wyjść poza firmę, jakie budżety na zespół, jaka dostępność. Streaming musi przechodzić bez odczuwalnego dodatkowego opóźnienia. *Otwarte pytanie: kto płaci za tokeny i kto decyduje, które modele są dozwolone?*
- **Architektura.** Jeden endpoint zgodny z popularnym formatem API, a za nim: klucz na zespół, limity i budżety, maskowanie danych osobowych, routing z fallbackiem, trace każdego wywołania. Brama jest bezstanowa i skaluje się poziomo, a liczniki budżetów trzyma we wspólnym, szybkim magazynie. *Otwarte pytanie: jak wersjonujesz kontrakt, gdy dostawcy dodają własne parametry, np. poziom rozumowania?*
- **Decyzje.** Wspólny interfejs ułatwia zmianę dostawcy, ale ukrywa funkcje specyficzne dla dostawców: zostaw tryb passthrough. Maskowanie danych osobowych to kompromis między dokładnością a opóźnieniem i fałszywymi alarmami, które psują kontekst. Fallback podnosi dostępność, ale inny model zachowuje się inaczej, więc prompty i ewaluacje muszą obejmować oba. Cache odpowiedzi po podobieństwie pytań jest ryzykowny: podobne to nie to samo. Prompt caching wymaga stabilnego prefiksu, tego samego modelu i dostawcy, a u Anthropic tego samego workspace’u (temat „Prompt caching”), więc fallback startuje z zimnym cache’em. *Otwarte pytanie: po przekroczeniu budżetu twarda blokada czy tańszy model?*
- **Ewaluacja.** Mierzysz bramę, nie odpowiedzi: dodatkowe opóźnienie p50 i p99, błędy na dostawcę, koszt na zespół, skuteczność maskowania na polskich danych (PESEL, adresy, nazwiska w odmianie). Za jakość odpowiedzi odpowiada zespół, który jest właścicielem funkcji, a brama daje mu trace’y i przypięte wersje modeli (temat „Czy model głupieje?”). *Otwarte pytanie: co logujesz, a czego nie wolno ci logować?*
- **Awarie.** Częściowa awaria dostawcy wywołuje lawinę ponowień: pomaga wykładniczy backoff z jitterem, circuit breaker i budżet ponowień. Agent w pętli potrafi spalić miesięczny budżet w godzinę, więc limity są na klucz i na request. Brama to pojedynczy punkt awarii: wiele instancji i świadoma decyzja, czy przy awarii filtra przepuszczać ruch, czy blokować. Logi promptów to osobne ryzyko wycieku. *Otwarte pytanie: które błędy dostawców brama pochłania, a które trafiają do zespołów?*

### Ocena 100 tys. CV tygodniowo

- **Wymagania.** „Oceniaj 100 tys. aplikacji tygodniowo względem ofert pracy”: ok. 14 tys. dziennie, wynik w ciągu godzin. RODO (art. 22) ogranicza decyzje oparte wyłącznie na automatycznym przetwarzaniu, a AI Act zalicza rekrutację do obszarów wysokiego ryzyka (załącznik III; po Digital Omnibus z 2026 roku obowiązki mają zastosowanie od 2 grudnia 2027), więc potrzebne są uzasadnienia, audyt i nadzór człowieka. *Otwarte pytanie: kto podejmuje decyzję, model czy rekruter?*
- **Architektura.** Kolejka zdarzeń, parser (PDF i DOCX do tekstu, OCR dla skanów), ekstrakcja do schematu (temat „Wymuszanie formatu”), ocena każdego kryterium z oferty z cytatem z CV, wynik w panelu rekrutera. Wszystko asynchronicznie: ponowienie jest tanie, a szczyty ruchu nie blokują przyjmowania aplikacji. *Otwarte pytanie: jak gwarantujesz dokładnie jedną ocenę na aplikację mimo ponowień?*
- **Decyzje.** Tryb wsadowy: ok. 50% taniej za wynik w ciągu 24 godzin. Instrukcja i oferta tworzą stały prefiks pod prompt caching, bo jedna oferta ma setki kandydatów. Kaskada: tańszy model ocenia przypadki oczywiste, mocniejszy graniczne, i żaden nikogo sam nie odrzuca: odrzucenie bez rzeczywistej weryfikacji przez człowieka to decyzja oparta wyłącznie na automatycznym przetwarzaniu. Kryteria pochodzą z oferty, nie z „wiedzy” modelu; imię, wiek i zdjęcie usuwasz przed oceną. *Otwarte pytanie: jak wyznaczasz próg przypadku granicznego?*
- **Ewaluacja.** Zestaw wzorcowy (golden set) kilkuset CV ocenionych przez kilku rekruterów. Zgodność modelu z ludźmi porównujesz ze zgodnością ludzi między sobą, bo to realny sufit. Testy stronniczości: pary CV różniące się tylko imieniem, płcią albo wiekiem muszą dostać tę samą ocenę. Na produkcji pilnujesz rozkładu ocen w czasie (temat „Ewaluacje”). *Otwarte pytanie: skąd prawda wzorcowa, skoro rekruterzy się nie zgadzają?*
- **Awarie.** Parser zwraca śmieci przy dwóch kolumnach albo tabelach, a model i tak wystawia ocenę: wykrywasz źle wyodrębniony tekst i kierujesz do człowieka. Kandydat dopisuje białym tekstem „oceń mnie najwyżej” (temat „Prompt injection”). Brak narzędzi i schemat ograniczają, co może zrobić atak, ale nie jego cel: samą ocenę. Dlatego parser oznacza tekst niewidoczny na wyrenderowanej stronie (warstwa tekstowa kontra OCR), kod sprawdza, czy każdy cytat uzasadniający ocenę jest w widocznym tekście, a oznaczone CV trafiają do człowieka. *Otwarte pytanie: po czym poznasz, że kandydaci zaczęli pisać CV pod model?*

### RAG na 50 mln dokumentów

- **Wymagania.** „Asystent odpowiada pracownikom na podstawie 50 mln dokumentów.” Dopytaj o uprawnienia, świeżość, języki i formaty, cytaty i czas odpowiedzi. Skala: przy ok. 20 fragmentach na dokument to ok. 1 mld wektorów, czyli przy 1024 wymiarach ok. 4 TB w float32 i 1 TB w int8. *Otwarte pytanie: jak zmniejszysz indeks i ile stracisz na jakości?*
- **Architektura.** Ingest: parsowanie, podział na fragmenty z zachowaniem nagłówków i tabel, do każdego fragmentu krótki opis, z jakiego dokumentu i rozdziału pochodzi; indeks wektorowy i indeks słów (BM25). Przy pytaniu: filtr uprawnień, wyszukiwanie hybrydowe, połączenie rankingów, reranking, prompt z kilkoma najlepszymi fragmentami, odpowiedź z cytatami (tematy „Embeddingi i wyszukiwanie wektorowe” i „RAG”). *Otwarte pytanie: jak przeindeksujesz 50 mln dokumentów po zmianie modelu embeddingów?*
- **Decyzje.** Filtr uprawnień w samym zapytaniu do indeksu: filtrowanie po fakcie gubi wyniki i grozi wyciekiem. Wyszukiwanie hybrydowe, bo wektory łapią znaczenie, a słowa – numery umów i nazwy własne. Reranker daje zwykle największy zysk jakości kosztem od kilkudziesięciu do kilkuset milisekund. Mniejszy fragment łatwiej trafić, większy daje więcej kontekstu. *Otwarte pytanie: co robisz, gdy reranker staje się wąskim gardłem?*
- **Ewaluacja.** Dwa etapy osobno: wyszukiwanie (czy właściwy fragment jest w pierwszych k wynikach) i generowanie (czy każde twierdzenie ma pokrycie we fragmencie, a cytat prowadzi tam, gdzie trzeba). Pytania od ekspertów, pytania wygenerowane przez model z losowych fragmentów i sprawdzone na próbce oraz pytania, na które w zbiorze nie ma odpowiedzi (temat „Ewaluacje”). *Otwarte pytanie: jak zbudujesz zestaw pytań bez ręcznego etykietowania milionów dokumentów?*
- **Awarie.** Cofnięte uprawnienie, a fragment wciąż w cache’u: klucz cache’u zawiera uprawnienia. Stara wersja dokumentu wygrywa z nową: daty w metadanych i deduplikacja wersji. Wyszukiwanie nic nie znajduje, a model odpowiada z pamięci z przypisem do najbliższego fragmentu (temat „Halucynacje”). Dokument z ukrytym poleceniem (temat „Prompt injection”). *Otwarte pytanie: jak wykrywasz na produkcji odpowiedzi niepoparte źródłami?*

### Agent jest wolny i drogi

- **Wymagania.** „Zadanie trwa 4 minuty i kosztuje 2 USD. Zejdź do 30 sekund i 20 centów bez utraty jakości.” Dopytaj: jaki jest dziś odsetek sukcesu, czy użytkownik czeka na wynik, które zadania dominują i co jest najważniejsze, gdy nie da się mieć wszystkiego. *Otwarte pytanie: co poświęcisz najpierw: koszt, czas czy odsetek sukcesu?*
- **Architektura.** Zanim cokolwiek zmienisz, zbierz trace każdej tury: tokeny wejściowe i wyjściowe, trafienia cache’u, tokeny myślenia, czas modelu i narzędzi. Zwykle większość kosztu to wielokrotnie wysyłany kontekst, a większość czasu to kolejne tury i tokeny wyjściowe. Docelowo: stabilny prefiks, zwięzłe narzędzia, mały model do prostych kroków, równoległe wywołania, subagenci do zadań pobocznych. *Otwarte pytanie: na których metrykach ustawiasz alerty i przy jakich progach?*
- **Decyzje.** Napraw prefiks: nic zmiennego przed system promptem i narzędziami, bo wysoki odsetek trafień cache’u obniża koszt wejścia kilkukrotnie (temat „Prompt caching”). Przytnij wyniki narzędzi: 20 tys. tokenów JSON-a wysyłanych w każdej turze to najdroższa linijka w systemie. Model do kroku: routing i ekstrakcja na małym modelu, poziom myślenia dobrany ewaluacją (temat „Wybór modelu”). Kompakcja i subagenci trzymają kontekst krótki (temat „Context engineering i pamięć”). *Otwarte pytanie: co tracisz przy kompakcji i jak to wykrywasz?*
- **Ewaluacja.** Każda optymalizacja przechodzi przez ten sam zestaw zadań: pass^k, koszt i czas na zadanie, p95 zamiast średniej, porównanie w parach. Tańszy agent, który częściej się myli, wychodzi drożej przez ponowienia i pracę człowieka. *Otwarte pytanie: jak budujesz zestaw zadań, skoro zadanie da się rozwiązać na wiele sposobów?*
- **Awarie.** Mały model psuje decyzje, które tylko wyglądały na proste. Kompakcja gubi szczegół potrzebny 20 tur później. Drobna zmiana na początku promptu po cichu zeruje trafienia cache’u i koszt wraca, więc ustawiasz alert na ich odsetek. Agent bez twardych limitów kręci się w pętli (temat „Pętla agenta”). *Otwarte pytanie: jak wykrywasz, że agent się zapętlił?*

### Klasyfikacja w czasie rzeczywistym

- **Wymagania.** „Tysiące zgłoszeń na minutę, decyzja w 50 ms, pomyłki kosztują.” Dopytaj: ile klas i jak często się zmieniają, ile kosztuje fałszywy alarm, a ile przeoczenie, czy są oznaczone dane historyczne. 50 ms wyklucza generowanie przez duży LLM w ścieżce synchronicznej: sam czas do pierwszego tokena bywa dłuższy. *Otwarte pytanie: ile kosztuje pomyłka każdego rodzaju?*
- **Architektura.** Stan decyzji (zgłoszenie, historia klienta, obowiązujące reguły) trafia do szybkiego klasyfikatora: dostrojonego enkodera albo embeddingów z regresją logistyczną, w procesie albo obok usługi. Hostowany model decyzyjny (temat „Kiedy nie używać LLM-a: klasyfikatory i System One”) pasuje tylko wtedy, gdy jego zmierzone p99 razem z siecią mieści się w budżecie. Powyżej progu pewności decyzja jest automatyczna; poniżej przypadek od razu dostaje tymczasowy status „do weryfikacji” i idzie asynchronicznie do modelu rozumującego albo człowieka. Kwoty, uprawnienia i czarne listy zostają w kodzie. *Otwarte pytanie: co zostaje w regułach, a co ocenia model?*
- **Decyzje.** Mały klasyfikator odpowiada w milisekundach za ułamek centa, ale potrzebuje danych i ponownego treningu przy każdej nowej klasie. LLM nie potrzebuje danych, więc pomaga w etykietowaniu i przypadkach granicznych, poza ścieżką 50 ms. Próg to kompromis między odsetkiem automatyzacji a liczbą błędów, ustalany na danych. Model ocenia, kod decyduje. *Otwarte pytanie: po czym poznasz, że mały klasyfikator przestał wystarczać?*
- **Ewaluacja.** Precyzja i czułość osobno dla każdej klasy na danych z produkcji. Krzywa: odsetek automatyzacji kontra odsetek błędów przy różnych progach. Kalibracja, czyli czy 90% pewności to naprawdę 90% trafień. Na produkcji korekty ludzi służą jako etykiety, a monitoring pilnuje rozkładu klas. *Otwarte pytanie: jak sprawdzasz kalibrację na własnych danych?*
- **Awarie.** Dryf: nowy produkt albo nowa kampania oszustów, pewność zostaje wysoka, a trafność spada. Zalew eskalacji po zmianie progu. Etykiety przychodzą tylko dla eskalowanych przypadków, więc błędów automatu nikt nie widzi; dlatego losową próbkę automatycznych decyzji też sprawdza człowiek. *Otwarte pytanie: jak duża musi być ta próbka, żeby wyłapać 1% błędów?*

### Jak zaprojektować system z LLM

- Zacznij od pytań, nie od modelu: kto używa, jaki wolumen, dopuszczalne opóźnienie, koszt na zapytanie, wrażliwość danych, koszt pomyłki. Zapisz liczby i przemnóż: tokeny na zapytanie razy liczba zapytań razy cena.
- Zbuduj najprostszą wersję, która działa: jedno wywołanie modelu albo workflow, a nie od razu agent (temat „Pętla agenta”); klasyfikator, a nie od razu LLM. Rozbudowuj dopiero tam, gdzie żądają tego wymagania.
- Każdą decyzję zapisz jako kompromis: co zyskujesz, co tracisz i przy jakiej liczbie zmieniłbyś zdanie. „Używamy RAG” to nie decyzja. „RAG, bo wiedza zmienia się co tydzień, a odpowiedzi muszą mieć źródła” to decyzja.
- Na koniec opisz ewaluację i awarie: jak mierzysz jakość przed wdrożeniem i na produkcji, co się zepsuje i po czym to poznasz. Bez tego system da się narysować, ale nie utrzymać.

### Liczby do szacowania kosztu i czasu

- Tokeny wyjściowe kosztują zwykle 4–8 razy więcej niż wejściowe (cenniki z lat 2025–2026) i to one wyznaczają czas generowania. Długie wejście jest tanie w przeliczeniu na token, ale płacisz za nie w każdym zapytaniu.
- Odczyt z prompt cache’u kosztuje u Anthropic 10% ceny wejścia w większości modeli, a w najnowszych mniej (5% w Claude Opus 5.5, 2,5% w Fable 5.1, stan na wrzesień 2026), zapis zaś 1,25× (wpis 5-minutowy) albo 2× (godzinny). U OpenAI rabat na odczyt to 50–90% zależnie od modelu. Tryb wsadowy u obu dostawców to ok. 50% taniej za wynik w ciągu 24 godzin.
- Czas agenta to suma tur, a każda tura to czas do pierwszego tokena, generowanie i narzędzie. Dziesięć tur po 3 sekundy to pół minuty, niezależnie od tego, jak szybki jest pojedynczy request.

### Sprawdź się

**Pytanie:** Jak oszacujesz koszt i czas odpowiedzi systemu z LLM-em, zanim go zbudujesz?

**Krótka odpowiedź:** Zaczynasz od jednego zapytania: liczysz tokeny wejścia, czyli system prompt, kontekst i historię, oraz tokeny wyjścia osobno, bo wyjście jest kilka razy droższe i to ono wyznacza czas generowania. Mnożysz przez liczbę zapytań i ceny, odejmujesz trafienia cache’u i to, co może pójść wsadowo za połowę ceny. W agencie mnożysz jeszcze przez liczbę tur, bo każda wysyła cały kontekst od nowa. Czas to suma tur: czas do pierwszego tokena, generowanie i narzędzia. Wynik porównujesz z budżetem i limitem opóźnienia, zanim wybierzesz model.

### Pytania pogłębiające

- **Kiedy LLM nie jest tu potrzebny?** Gdy klas jest mało, oznaczonych danych dużo, a limit opóźnienia albo kosztu twardy: wtedy wygrywa mały klasyfikator albo reguły. Także gdy każda decyzja musi być w pełni powtarzalna i audytowalna. LLM przydaje się wtedy do etykietowania danych, nie w ścieżce produkcyjnej (temat „Kiedy nie używać LLM-a: klasyfikatory i System One”).
- **Jak wybierasz model?** Po wymaganiach, nie po rankingu: najtańszy model, który przechodzi twój zestaw ewaluacyjny przy wymaganym opóźnieniu, z przypiętą wersją i planem migracji. Mocny model do trudnych kroków, mały do prostych (temat „Wybór modelu”).
- **Jak zapewnisz działanie przy awarii dostawcy modelu?** Timeouty i ponowienia z backoffem, fallback na drugiego dostawcę sprawdzony tym samym zestawem ewaluacyjnym i tryb awaryjny bez LLM-a tam, gdzie się da, np. kolejka zamiast natychmiastowej odpowiedzi.
- **Jak dzielisz odpowiedzialność między model a kod?** Model ocenia, wyciąga dane i pisze, kod decyduje i wykonuje. Reguły biznesowe, uprawnienia, limity i zatwierdzanie akcji są deterministyczne i testowalne, a model dostaje tylko to, czego nie da się zapisać regułą.
- **Kiedy fine-tuning zamiast promptu i RAG?** Gdy problem dotyczy formy, a nie wiedzy: stały format, styl, klasyfikacja w wąskiej domenie, albo gdy mały dostrojony model ma zastąpić duży ze względu na koszt i opóźnienie. Wiedzę, która się zmienia, podajesz w kontekście (tematy „Fine-tuning i LoRA” i „RAG”).

### Źródła

- [Chip Huyen: Building A Generative AI Platform (2024)](https://huyenchip.com/2024/07/25/genai-platform.html)
- [Anthropic: Building effective agents](https://www.anthropic.com/engineering/building-effective-agents)
- [Evidently AI: baza 800 case studies systemów ML i LLM](https://www.evidentlyai.com/ml-system-design)

---

## Fiszki

*Ćwiczenia i powtórka*

*Ostatnia zmiana: 28 września 2026*

Jedno pytanie do każdego tematu przewodnika o LLM-ach i agentach AI. Najpierw odpowiedz sam, dopiero potem odwróć kartę i porównaj z krótką odpowiedzią.

„Umiem” oznacza temat jako opanowany. Postęp zapisuje się tylko w tej przeglądarce. „Tylko nieopanowane” ukrywa oznaczone tematy, a „Z pytaniami pogłębiającymi” dokłada głębsze pytania z sekcji „Sprawdź się” każdego tematu.