Rozdział 6 „Generative AI Design Patterns" opisuje cztery wzorce niezawodności: LLM-as-Judge, Reflection, Dependency Injection i Prompt Optimization. Wszystkie opierają się na ewaluatorze, więc to on decyduje, co system uzna za dobry wynik. Sprawdziłem dwa z tych wzorców na Qwen3.8-27B na stacji z RTX 5090. Jedna runda samokrytyki tym samym modelem podniosła wynik na 60 zadaniach kalendarzowych z 42 do 45. Krytyk przepuścił jednak połowę błędów, a jedną poprawną odpowiedź zepsuł. Automatyczny test, który mówił tylko „źle", podniósł wynik do 54, a poprawnych odpowiedzi z założenia nie ruszał. W Prompt Optimization obaj sędziowie wybrali prompt lepszy od bazowego, co zgadza się z autorami. Sędzia z ogólną rubryką ocenił jednak wyżej od bazowego także prompt, który ani razu nie podał numeru zgłoszenia.

„Bezpieczny vibe coding” w sensie właściwości modelu nie istnieje. Asystent kodu wykonuje polecenia z każdego tekstu, który trafi mu do kontekstu: z README, z treści issue, z dokumentacji pobranej z sieci. Nie da się mu tego wyperswadować promptem. Bezpieczny może być natomiast układ wokół asystenta: co agent widzi, do czego ma dostęp, dokąd może coś wysłać i co sprawdza kod, zanim trafi na produkcję. Ten wpis jest przewodnikiem po takim układzie: śmiertelna triada, halucynowane paczki, zasada najmniejszych uprawnień w IDE i bramki w CI/CD. Na końcu jest krótko o kursie Linux Foundation LFEL1012, po którym go spisałem.

Uruchomiłem NVIDIA garak, otwartoźródłowy skaner podatności modeli językowych, przeciwko Qwen3.8-27B INT4 z poprzednich wpisów. Garak dostał polecenie tłumaczenia ataków na polski. Probe promptinject zgłosił 0 udanych wstrzyknięć na 96 prób. Kiedy przejrzałem odpowiedzi ręcznie, wyszło 16 przypadków, w których model wypisał dokładnie to, co kazała mu wstrzyknięta instrukcja. Przyczyna leży w garak, nie w modelu: fraza, którą atak każe powtórzyć, jest w prompcie tłumaczona na polski, a wzorzec, którego szuka detektor, zostaje po angielsku. Zgłosiłem to jako błąd. Poprawka zaproponowana przez innego kontrybutora przechodzi swoje testy, ale na prawdziwym tłumaczeniu wykrywa 4 z tych 16 przypadków.

Gdy aplikacja zwalnia pod obciążeniem, pierwszym odruchem jest podniesienie maximumPoolSize z 20 do 100. Zwykle robi się gorzej, nie lepiej. Pula połączeń to nie jest zapas mocy, tylko kolejka przed bazą, która ma tyle samo rdzeni co przed zmianą. Kolejka istnieje tak czy inaczej. Rozmiar puli decyduje tylko o tym, gdzie ją widać: w puli, gdzie da się ją zmierzyć, czy w schedulerze systemu i w lock managerze Postgresa, gdzie jej nie widać. Poniżej arytmetyka rozmiaru puli, PgBouncer w trybie transaction z tym, co się w nim psuje, pułapka dwóch pul i metryka, która to wszystko pokazuje.

Sprawdziłem, czy obecny model w firmowym RAG-u, Qwen3.8-27B w INT4, da się zastąpić czymś szybszym. Kandydaci to Gemma 4 12B, Gemma 4 26B-A4B (MoE) i Qwen3.5-9B. Wszyscy działali na tej samej karcie RTX 5090, w tym samym vLLM i z tym samym zestawem pytań. Najszybszy kandydat, Gemma 4 26B-A4B, przy 16 zapytaniach naraz dał 4,1 raza więcej tokenów na sekundę i 11 razy krótszy czas do pierwszego tokenu. Mimo to obecny model zostaje, bo tylko on zaliczył wszystkie 52 tury w obu kanałach. W pierwszym pomiarze ta przewaga w czasie do pierwszego tokenu wyszła 85-krotna, bo kandydatom pomagał prefix cache, a obecnemu modelowi nie. To ten sam błąd, który opisałem tydzień temu, tylko tym razem w drugą stronę.

We wpisie o rozdziale 4 „Generative AI Design Patterns" reranker bge oddzielił pytania spoza domeny od pozostałych na sztucznym korpusie. Ostrzegłem wtedy, że ten rozdział zniknie, gdy w bazie pojawią się fragmenty z tematów sąsiednich. Teraz powtórzyłem pomiar na prawdziwej bazie wiedzy w firmie, na stacji z RTX 5090, i rozdział zniknął. Sędzia-LLM nadal układał fragmenty lepiej niż wyspecjalizowany reranker (MRR 0,87–0,95 wobec 0,84), ale ten sam pomysł w dwóch implementacjach dał dwa różne wyniki. Gdy karta równolegle przetwarzała długie konteksty, sędzia potrzebował 9–14 s, a reranker 0,12 s. Próg odmowy na ocenie rerankera wyglądał na odporny, dopóki liczyłem go na 21 pytaniach z etykietą źródła. Na wszystkich 37 pytaniach z odpowiedzią nie oddziela pytań spoza bazy żaden model. Ten błąd złapałem dopiero przy weryfikacji tego wpisu.

Rozdział 5 „Generative AI Design Patterns" opisuje cztery sposoby rozszerzania tego, co model potrafi: Chain of Thought, Tree of Thoughts, Adapter Tuning i Evol-Instruct. Każdy naprawia inny brak, a najczęstszy błąd to dostrajanie modelu, gdy brakuje mu faktu. Autorzy sami datują Chain of Thought i radzą co pół roku sprawdzać, czy jest jeszcze potrzebny. Sprawdziłem to na 20 nowych zadaniach i czterech lokalnych modelach, w tym na Qwen3.8-27B na RTX 5090. Wynik zgadza się z tą częścią tezy autorów, którą da się sprawdzić lokalnie. Dopisek „rozwiąż krok po kroku" podniósł wyniki modeli bez trybu myślenia lub z wyłączonym myśleniem z 1 do 9, z 4 do 16 i z 6 do 19 na 20, a Qwen3.8 z włączonym myśleniem osiągnął bez dopisku te same 19. U większych modeli błędy, które zostały, to głównie poprawnie rozpisane kroki ze źle policzonymi datami.

Karta z rodziny Blackwell obsługuje FP4 sprzętowo, więc kwantyzacja NVFP4 powinna być na niej najszybsza. U mnie nie była. Qwen3.8-27B w kwantyzacji INT4 od Red Hata generował na RTX 5090 o 19–28% więcej tokenów na sekundę niż ten sam model w NVFP4 od NVIDII. Do tego zostawił ponad dwa razy więcej pamięci na KV cache. Bielik 11B w FP8 był szybszy od obu, ale ma ponad dwa razy mniej parametrów, więc ta różnica niewiele mówi. Ten wpis pokazuje liczby, warunki pomiaru i to, czego z nich nie da się wyczytać. W pomiarze TTFT znalazłem też błąd, który sam zrobiłem.

Rozdział 4 „Generative AI Design Patterns" dokłada do RAG-a cztery wzorce: przepisywanie zapytania (w tym HyDE), przetwarzanie pobranych fragmentów z rerankingiem, sygnalizowanie wiarygodności odpowiedzi i iteracyjne wyszukiwanie. Sprawdziłem wszystkie cztery na fikcyjnej polskiej instrukcji serwisowej i lokalnych modelach. Najmocniej potwierdziło się zastrzeżenie, które autorzy sami stawiają przy HyDE: w domenie, której model nie zna, hipotetyczna odpowiedź jest zmyślona, a wyszukiwanie po niej trafiło właściwy fragment w 10 przypadkach na 20 zamiast w 17. Reranking poprawił kolejność, ale lepszy okazał się wolny sędzia-LLM niż wyspecjalizowany reranker. Pętla Deep Search z promptem z książki w trzech pytaniach na pięć kończyła pracę po pierwszym kroku z odpowiedzią niepełną, bo jej ewaluator uznawał „brakuje informacji" za odpowiedź kompletną.

Rozdział 3 „Generative AI Design Patterns" buduje RAG w trzech krokach: wyszukiwanie po słowach, wyszukiwanie po znaczeniu i metadane, które pozwalają bazie przetrwać wzrost. Sprawdziłem wszystkie trzy na polskiej instrukcji serwisowej i lokalnych modelach. Dwie tezy książki potwierdziły się w formie mocniejszej, niż je zapisano: surowe BM25 w języku fleksyjnym trafia na pierwszej pozycji 2 z 10 zapytań, a usunięcie starych biuletynów z bazy zmieniło poprawną odpowiedź na błędną. Trzecia teza okazała się zależna od modelu. bge-m3 bez BM25 rozróżnił 24 z 24 kodów części różniących się jednym znakiem, gdy kod był zapisany tak jak w katalogu, a naiwna hybryda wypadła od niego gorzej.