Generative AI Design Patterns (Lakshmanan, Hapke): recenzja i mapa 32 wzorców

„Generative AI Design Patterns" Valliappy Lakshmanana i Hannesa Hapkego (O'Reilly) katalogizuje 32 wzorce projektowania aplikacji na modelach generatywnych: od maskowania logitów, przez RAG i agentów, po guardrails. Przeczytałem całość z jednym pytaniem przy każdym wzorcu: czy odpowiada na trwałą własność modeli, czy obchodzi brak funkcji w API z 2025 roku. Mój werdykt: część katalogu się zestarzeje, ale kryteria wyboru zostaną, bo autorzy przy większości wzorców piszą, kiedy go nie stosować, a przy kilku podpierają to liczbami. Ten wpis to recenzja i mapa serii — w dziesięciu kolejnych rozbieram wzorce grupami.

O książce

Autorzy to Valliappa Lakshmanan i Hannes Hapke; wydawca O'Reilly, pierwsze wydanie 2025-10-03, na stronie redakcyjnej ©2026. Czytałem wersję PDF, która jest przeformatowanym EPUB-em i nie ma numerów stron druku, dlatego w całej serii cytuję po rozdziale i numerze wzorca — np. (rozdz. 5, Pattern 13) — a nie po stronie. Wydawca robi zresztą to samo: indeks książki wskazuje sekcje, nie strony.

Układ jest prosty. Rozdział 1 buduje model pojęciowy (logity, sampling, in-context learning, rodzaje post-treningu). Rozdziały 2–9 to 32 wzorce w stałym schemacie: problem, rozwiązanie, przykład, rozważania (Considerations, często z alternatywami) i literatura. Rozdział 10 składa kilka wzorców w jedną aplikację agentową.

Rozdz.	Temat	Wzorce
2	Kontrola stylu i formatu	P1 Logits Masking, P2 Grammar, P3 Style Transfer, P4 Reverse Neutralization, P5 Content Optimization
3	Dodawanie wiedzy: podstawy	P6 Basic RAG, P7 Semantic Indexing, P8 Indexing at Scale
4	Dodawanie wiedzy: wyszukiwanie	P9 Index-Aware Retrieval, P10 Node Postprocessing, P11 Trustworthy Generation, P12 Deep Search
5	Rozszerzanie zdolności modelu	P13 Chain of Thought, P14 Tree of Thoughts, P15 Adapter Tuning, P16 Evol-Instruct
6	Niezawodność	P17 LLM-as-Judge, P18 Reflection, P19 Dependency Injection, P20 Prompt Optimization
7	Agenci i działanie	P21 Tool Calling, P22 Code Execution, P23 Multiagent Collaboration
8	Ograniczenia: koszt i latencja	P24 Small Language Model, P25 Prompt Caching, P26 Inference Optimization, P27 Degradation Testing, P28 Long-Term Memory
9	Zabezpieczenia	P29 Template Generation, P30 Assembled Reformat, P31 Self-Check, P32 Guardrails

Moja teza, z której wynika reszta

Klasyczne wzorce projektowe (GoF) porządkują kod, który sam napisałem. Wzorce z tej książki robią coś innego: obudowują komponent, którego nie napisałem i którego zachowania nie kontroluję. Model jest niedeterministyczny, bezstanowy, zmienia się z każdą wersją i nie wie, czego nie wie. Każdy z 32 wzorców da się więc czytać jako odpowiedź na konkretny tryb zawodności modelu.

To daje proste kryterium oceny. Jeśli wzorzec odpowiada na własność modelu (halucynuje, nie trzyma formatu, nie ma pamięci), to przeżyje zmianę dostawcy. Jeśli odpowiada na brak funkcji w API z 2025 roku, ma datę ważności — i w serii będę to przy każdym wzorcu zaznaczał jako moją ocenę trwałości, oddzieloną od tego, co piszą autorzy.

Kolejność sięgania po narzędzia

Rozdział 1 i rozdział 5 razem dają coś, co nazywam drabiną kosztu. Skala czasu to moja heurystyka, nie liczby z książki — autorzy dla samego treningu podają czasy od minut do godzin (np. w rozdz. 1 dla fine-tuningu przez API), a ja doliczam przygotowanie danych, ewaluację i utrzymanie:

1. Parametry generowania — temperatura, top-p, kary. Zmiana w minutę.
2. Prompt i few-shot — godziny.
3. RAG — dni: indeks, chunkowanie, ewaluacja wyszukiwania.
4. Post-training — tygodnie, a potem utrzymanie na zawsze, bo każda nowa wersja modelu bazowego wymaga powtórki.

Schodzić w dół możliwie późno. Jedna obserwacja z rozdziału 2 zmieniła mi odruch: prośba w prompcie („zwróć JSON") nie jest tanim szczeblem tej drabiny, tylko jego brakiem. Autorzy nazywają poleganie na posłuszeństwie modelu antywzorcem, bo koszt przenosi się na każdego konsumenta wywołania, który musi się zabezpieczać osobno.

Rodzaj braku wyznacza narzędzie

Najużyteczniejsza tabela, jaką z tej książki wyniosłem, nie jest w niej wydrukowana — składa się z fragmentów rozdziałów 1, 3 i 5:

Czego modelowi brakuje	Narzędzie	Dlaczego
formy, stylu, formatu	few-shot, Style Transfer (P3)	zmiana przykładów działa natychmiast
logiki, procedury	Chain of Thought (P13)	„RAG gives the model a (few) fish, while Few-shot CoT shows the model how to fish" (rozdz. 5, Pattern 13)
faktu	RAG (P6–P12)	„You need that specific data point, and the only time you know it is during inference" (rozdz. 3, Pattern 6)
umiejętności bliskiej temu, co model już umie	Adapter Tuning (P15)	typowo kilkaset do kilku tysięcy przykładów, czasem wystarczy ok. 100 (rozdz. 5, Pattern 15)
żargonu, nowego języka	continued pretraining	adapter zmienia model za mało
całkiem nowego, złożonego zadania	instruction tuning, Evol-Instruct (P16)	tysiące przykładów i świadoma utrata części zdolności ogólnych

Argument, dlaczego dostrajanie nie jest sposobem na dodanie faktu, jest intuicyjny: kilkaset przykładów z nazwiskiem nowego premiera nie przeważy tysięcy artykułów o poprzedniku, które model widział w pretreningu.

Co jest mocne

Kryteria „kiedy nie używać". To jest główna wartość książki. Przy Tree of Thoughts autorzy podają, że w ich przykładzie (optymalizacja łańcucha dostaw) jedna odpowiedź wymagała 41 wywołań API i trwała 93 sekundy (rozdz. 5, Pattern 14). Przy Evol-Instruct liczą, że każdy wygenerowany przykład to co najmniej trzy wywołania modelu, więc zbiór 10 tysięcy przykładów to ponad 30 tysięcy wywołań (rozdz. 5, Pattern 16) — to ich szacunek, nie pomiar, ale wystarczy do decyzji. Przy systemach wieloagentowych przytaczają analizę z 2025 roku, według której 40–80% zadań w takich systemach kończy się porażką, i sami rekomendują zrobienie wszystkiego, żeby wystarczył jeden agent (rozdz. 7, Pattern 23). Zastrzeżenie: w przypisie autorzy zaznaczają, że badacze opublikowali zaktualizowaną wersję pracy, gdy książka była w druku — do tej liczby wrócę przy wpisie o agentach.

Datowanie własnych tez. Autorzy wiedzą, że piszą o ruchomym celu. O Chain of Thought: „If you do use CoT, put a reminder on your calendar to check back every six months to see if CoT is still required" (rozdz. 5, Pattern 13). Uważam, że ta rada powinna być domyślnym odruchem wobec każdego wzorca z tej książki, nie tylko wobec CoT.

Uczciwość wobec własnego kodu. W rozdziale 10 autorzy ustawiają w przykładowej aplikacji ponowienie wywołania i sami nazywają to antywzorcem „try-and-try-again" z rozdziału 2, z rachunkiem, dlaczego w tym miejscu jest dopuszczalne. Książka, która przyznaje się do antywzorca we własnym przykładzie, zasługuje na zaufanie w pozostałych ocenach.

Stare wzorce w nowym kostiumie. Najbardziej wiarygodne okazały się te wzorce, które nie są nowe: Dependency Injection (P19) do testowania łańcuchów wywołań, Prompt Optimization (P20) jako kompilacja promptu z przykładów i ewaluatora, Template Generation (P29), czyli mail merge z lat 80. z modelem w trybie offline.

Słabe punkty

Część katalogu ma datę ważności. Według mojej oceny 8 z 32 wzorców jest datowanych albo trwałych tylko częściowo (m.in. Chain of Thought, Tree of Thoughts, Small Language Model, Inference Optimization), a przy kolejnych datowane są szczegóły — progi, frameworki, limity. Kto wystawia logity, czy Zero-shot CoT jest jeszcze potrzebny, Tree of Thoughts wobec modeli rozumujących, progi cache'owania promptów, limity okien kontekstu — to wszystko jest stan z połowy 2025 roku. Rozdział 8 (małe modele, cache, optymalizacja inferencji) zestarzeje się najszybciej.

Liczby bez źródła. Część liczb to szacunki autorów podane bez przypisu: że limit to według nich 3–10 narzędzi, zależnie od modelu (stan na czerwiec 2025, rozdz. 7, Pattern 21), że 3–10% wartości wyciąganych z obrazów to halucynacje (rozdz. 9, Pattern 31), statystyki call center uzasadniające cache'owanie (rozdz. 8, Pattern 25). W serii oznaczam je jako szacunki autorów, a deklaracje dostawców (np. procent redukcji kosztu przy cache'owaniu) — jako deklaracje.

Rozdział 10 to przewodnik po repozytorium, a nie rozdział koncepcyjny. Przykłady kodu są w repozytorium GitHub autorów i warto je przejrzeć, ale do czytania ten rozdział wnosi najmniej.

Luka, którą dzieli cała dziedzina. Przeszedłem książkę z pytaniem, czy ktoś zapyta o uprawnienia pytającego: czy użytkownik ma prawo zobaczyć to, co system RAG dla niego pobierze. Metadane autoryzacyjne przy chunkach pojawiają się w jednym wyliczeniu w rozdziale 3 i nie wracają; w rozdziale 10 pada jeszcze ogólne zalecenie kontroli dostępu, logowania audytowego i punktów akceptacji przez człowieka dla użytkowników i agentów — bez przełożenia na retrieval. „Trustworthy Generation" dotyczy wiarygodności treści, prywatność w rozdziale 9 to nieujawnianie danych osobowych, a zaufanie w rozdziale 7 to uprawnienia agenta, nie użytkownika. To raczej opis stanu dziedziny w 2025 roku niż wada tej konkretnej książki — ale jeśli budujesz RAG na dokumentach z różnymi poziomami dostępu, konkretnego rozwiązania tu nie znajdziesz.

Motyw, którego autorzy nie nazwali

Czytając rozdziały 2, 7 i 9 obok siebie, zauważyłem, że najskuteczniejsze wzorce obniżania ryzyka robią ten sam ruch: przesuwają niedeterminizm poza moment, w którym błąd kosztuje.

• Grammar (P2) nie dopuszcza błędnego tokenu, zamiast go potem wycinać.
• Template Generation (P29) generuje szablony offline, gdzie da się je przejrzeć, a w czasie działania zostaje deterministyczne podstawienie tekstu.
• Assembled Reformat (P30) zostawia modelowi tylko przeformułowanie faktów zebranych innymi metodami.
• Obrony przed prompt injection z rozdziału 7 dają uprawnienia do działania temu komponentowi, który nie czyta niezaufanych danych.

Model zostaje w systemie, ale nie w chwili, w której decyduje się szkoda. To jest, moim zdaniem, najogólniejsza lekcja tej książki i mocniejsza niż którykolwiek z 32 wzorców osobno.

Ocena

4/5. Nie za katalog, tylko za kryteria wyboru i uczciwość wobec własnych ograniczeń. Do rozdziałów 1, 5, 6 i 7 będę wracał; rozdziałów 8 i 10 drugi raz nie otworzę. Dla kogo: dla kogoś, kto ma już za sobą pierwszy prototyp na LLM i zderzył się z tym, że działa w demo, a nie działa w produkcji. Na pierwszą styczność z LLM-ami to za dużo naraz.

Mapa serii

Kolejne wpisy rozbierają wzorce grupami, w stałym schemacie: problem, rozwiązanie, kiedy nie używać, moja ocena trwałości i — jeśli istnieje — starszy krewny wzorca spoza świata AI.

#	Wpis	Wzorce
0	Recenzja i mapa serii (ten wpis)	—
1a	Twarde ograniczanie wyjścia modelu	P1–P2
1b	Styl i optymalizacja treści	P3–P5
2	RAG: fundamenty	P6–P8
3	RAG: wyszukiwanie i zaufanie	P9–P12
4	Rozszerzanie zdolności modelu	P13–P16
5	Niezawodność	P17–P20
6	Agenci i narzędzia	P21–P23
7	Koszt, latencja, pamięć	P24–P28
8	Zabezpieczenia	P29–P32
9	Kompozycja wzorców i podsumowanie	rozdz. 10

Linki pojawią się tu w miarę publikacji. Na tym blogu są już wpisy blisko związane z częścią tych wzorców: o chunkowaniu strukturalnym w RAG, o OWASP Top 10 dla MCP i o rozdzieleniu pętli agenta od wykonania narzędzi w Managed Agents.