Generative AI Design Patterns #4: Chain of Thought, Tree of Thoughts, Adapter Tuning i Evol-Instruct, czyli który brak naprawia które narzędzie

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.

To szósty wpis serii o książce Valliappy Lakshmanana i Hannesa Hapkego. Recenzja i mapa serii są we wpisie 0, poprzedni wpis dotyczył wyszukiwania i zaufania w RAG-u. Cytuję po rozdziale i numerze wzorca, bo PDF nie ma stron druku.

Teza

Rozdziały 3 i 4 dokładały modelowi wiedzy. Rozdział 5 zajmuje się czymś innym: tym, czego model nie umie, choć ma potrzebne fakty. Cztery wzorce odpowiadają na cztery różne braki. Chain of Thought dokłada sposób rozumowania, Tree of Thoughts możliwość cofnięcia się, Adapter Tuning umiejętność bliską tej, którą model już ma, a Evol-Instruct dane do nauczenia zupełnie nowego zadania.

Moja teza ma trzy części. Narzędzie wybiera się według rodzaju braku, a najczęstszy błąd to sięganie po dostrajanie, gdy brakuje faktu. Chain of Thought i Tree of Thoughts są datowane, bo modele z trybem myślenia robią to same. Mój pomiar dotyczy tylko CoT i to potwierdza: dopisek „myśl krok po kroku" mocno pomógł każdemu z trzech lokalnych modeli bez trybu myślenia lub z wyłączonym myśleniem, a Qwen3.8 z włączonym myśleniem osiągnął bez dopisku ten sam wynik. Pojedynczych błędów w arytmetyce kalendarza nie usunęło ani jedno, ani drugie. Widoczne rozumowanie modelu jest tekstem wygenerowanym tak samo jak odpowiedź, więc nie dowodzi, że odpowiedź jest dobra.

Zanim zaczniesz testować: opublikowany błąd przestaje być testem

Wstęp rozdziału zawiera ramkę, którą uważam za najważniejszą metodologicznie w całej książce. Dostawcy modeli śledzą publikacje i media społecznościowe pod kątem zgłaszanych błędów i „in many cases, they fix such errors immediately with hardcoded detection and responses", a dopiero potem dokładają dane treningowe. Autorzy uprzedzają, że ich przykłady błędów mogą nie działać, zanim książka trafi do czytelnika, ale „they're symptoms of larger phenomena that are unlikely to have been fixed" (rozdz. 5, wstęp).

Wniosek dla każdego, kto sprawdza cudze twierdzenia o zawodności modelu: powtórzenie opublikowanego promptu niczego nie dowodzi, bo właśnie ten prompt jest najbardziej prawdopodobnym miejscem punktowej łatki. Dlatego zadania w moim pomiarze niżej są nowe. Po publikacji tego wpisu przestają się do tego nadawać.

Autorzy zastrzegają też, że do pokazania granic modeli używają zadań matematycznych i logicznych tylko dlatego, że te łatwo pokazać. Wzorce z rozdziału „are not solutions to math or reasoning problems—they are solutions to problems such as writing investment committee memos" (rozdz. 5, wstęp). Wszystko, co jest opisane w publicznych źródłach, model z definicji widział, więc prawdziwe braki są w zadaniach branżowych i wewnętrznych.

Pattern 13: Chain of Thought

Problem. Autorzy wymieniają trzy tryby awarii. Pierwszy to brak pokrycia w danych: zadanie o przepływie ropy w rurze model odmówił policzyć i wyliczał brakujące dane, co autorzy nazywają „filibustering". Drugi to rozumowanie wieloetapowe: reguła „50 kg bagażu, jeśli celem końcowym są USA" dała 50 kg na trasie Singapur–Dallas–Toronto, bo model uznał przesiadkę w Dallas za cel. Trzeci to odpowiedź z czarnej skrzynki, której nie da się sprawdzić (rozdz. 5, Pattern 13).

Rozwiązanie. Trzy warianty. Zero-shot CoT to dopisek „think step-by-step". Few-shot CoT pokazuje modelowi rozumowanie na przykładach. Auto-CoT buduje bazę takich przykładów maszynowo i dobiera je do pytania po słowach albo embeddingach. Różnicę wobec RAG-u autorzy ujmują tak: „in RAG, you add knowledge (data), whereas in CoT, you demonstrate logic. … RAG gives the model a (few) fish, while Few-shot CoT shows the model how to fish" (rozdz. 5, Pattern 13).

Kiedy nie używać. Gdy brakuje danych, a nie logiki. Przy pytaniu, gdzie się wyląduje, jadąc 300 km na zachód od Hyderabadu, model z dopiskiem „krok po kroku" przeszedł wzorcową procedurę i wskazał złe miasto: „The logic is correct, but the destination is hallucinated". Pomogło dopiero dołożenie mapy do promptu, czyli danych. Drugi przypadek to logika niesekwencyjna, jak rozgrywka w brydżu, w której ekspert optymalizuje pod wiele scenariuszy naraz. Takiej logiki nie da się pokazać na przykładach (rozdz. 5, Pattern 13).

Najważniejsze zdanie wzorca stoi przy alternatywach. Dostawcy w praktyce już doklejają rozumowanie: API klasyfikują pytanie i decydują, czy uruchomić CoT, a demonstracje w stylu Auto-CoT są w pretreningu. Stąd wniosek autorów, że Zero-shot CoT jest bardziej przydatny dla małych modeli lokalnych niż dla modeli z czołówki, i rada: „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). Ten wniosek sprawdziłem niżej.

Druga obserwacja dotyczy samego rozumowania: „Asking the model »why« after the fact does not get the model to provide the actual reasoning it used—in fact, its explanation is likely to be hallucinated" (rozdz. 5, Pattern 13). Autorzy pokazują też, że model poprawnie recytuje brydżową maksymę „eight ever, nine never", a chwilę później w dokładnie takiej sytuacji radzi zagrać wbrew niej: „just because a model can reproduce a standard piece of advice, it does not mean that the model can apply that advice".

Pattern 14: Tree of Thoughts

Problem. Pojedyncza ścieżka rozumowania utyka. W przykładzie autorów cytat z Hamleta na początku eseju pchnął go w stronę filozoficzną, do której nie pasowały kolejne cytaty. Model nie ma jak się cofnąć ani ocenić kroków pośrednich (rozdz. 5, Pattern 14).

Rozwiązanie. Generowanie kilku myśli na każdy krok, ocena ścieżek przez model w skali 0–100, beam search po najlepszych K i podsumowanie z najlepszej ścieżki. To nie jest ten sam beam search co przy Logits Masking z wpisu 1a: tam działał na tokenach, tu działa na krokach rozumowania.

Kiedy nie używać. Gdy zadanie jest proste albo budżet nie zniesie kosztu. W przykładzie autorów, optymalizacji łańcucha dostaw z drzewem głębokości 4, jedna odpowiedź wymagała 41 wywołań API i 93 sekund. To pomiar na jednym przykładzie, nie ogólny koszt metody. Zrównoleglenie pomaga tylko częściowo, bo przed zejściem na kolejny poziom trzeba mieć wszystkich kandydatów bieżącego (rozdz. 5, Pattern 14).

Jako tańsze alternatywy autorzy wymieniają modele rozumujące z trybem myślenia, które sami zalecają zamiast budowania ToT, dekompozycję least-to-most, Reflection (wzorzec 18) i budget forcing: nadpisanie tokenu końca generacji słowem Wait, żeby model przejrzał to, co przed chwilą napisał (rozdz. 5, Pattern 14).

Pattern 15: Adapter Tuning

Problem. Zadanie jest bliskie temu, co model już umie, ale prompt przestaje się opłacać. Autorzy podają trzy powody, dla których prompt engineering przestaje wystarczać. Pierwszy to koszt: prompt puchnie z każdym przypadkiem brzegowym i „not unusual for such prompts to amount to two or three pages". Drugi to lokalizacja: wdrożenie on-premises albo na urządzeniu wymusza mniejszy model, który gorzej wykonuje długie instrukcje. Trzeci to utrzymanie: system wrażliwy na brzmienie promptu trzeba testować od nowa przy każdej zmianie modelu i każdego narzędzia (rozdz. 5, Pattern 15).

Rozwiązanie. Wagi modelu bazowego są zamrożone, a trenuje się tylko małe warstwy adaptera: gęstą warstwę zmniejszającą wymiar (w przykładzie 768 → 64), nieliniowość i warstwę odtwarzającą wymiar. Potocznie mówi się na to LoRA, „even though it's not strictly what researchers think of as a LoRA architecture". Według autorów trening „often be accomplished on a single GPU in under an hour", a czasem wystarcza około 100 przykładów (rozdz. 5, Pattern 15).

Kiedy nie używać. Tu autorzy łamią konwencję własnej książki. Ograniczenia wyciągnęli z sekcji Considerations do osobnej ramki przed nią, bo wzorzec jest „so commonly misused". Ramka nosi tytuł „Adapter tuning is not for industry jargon or new facts". Adapter nadaje się do klasyfikacji, streszczania, odpowiadania na pytania z podanego tekstu i tonu marki. Do żargonu i nowego języka potrzebny jest continued pretraining, bo adapter „doesn't change the model enough to enable such learning". Do nowych faktów potrzebny jest RAG (rozdz. 5, Pattern 15). Intuicja jest prosta: gdy kraj wybiera nowego premiera, kilkaset zdań z jego nazwiskiem w danych do dostrajania nie przeważy tysięcy tekstów o poprzedniku z pretreningu.

Pattern 16: Evol-Instruct

Problem. Potrzebny jest model do nowego, złożonego zadania firmowego, a nie ma zbioru instrukcji, na którym dałoby się go nauczyć. Autorzy wiążą to z umowami enterprise, w których dostawca zobowiązuje się nie trenować na danych klienta. Skutek: „the models don't automatically improve over time to cover the kinds of tasks that enterprise users want the models to do", w odróżnieniu od zadań konsumenckich (rozdz. 5, Pattern 16). Z tego wyciągam wniosek, którego autorzy wprost nie stawiają: przy wyborze między czekaniem na lepszy model a dostrajaniem liczy się nie to, jak duża jest przewaga, tylko to, czy zadanie ma publiczny odpowiednik, na którym dostawca będzie trenował.

Rozwiązanie. Cztery kroki według WizardLM: model przepisuje instrukcję na trudniejszą (dokłada ograniczenia, uszczegóławia, komplikuje), generuje odpowiedź, odpowiedzi są oceniane i filtrowane, a na końcu model przechodzi instruction tuning (rozdz. 5, Pattern 16). Poprawne odpowiedzi do wymyślonych instrukcji mogą pochodzić od ekspertów, z narzędzi branżowych, z ewaluacji w pętli (dla kodu kompilator i sandbox), z RAG-u albo od silniejszego modelu-nauczyciela.

Kiedy nie używać. Gdy model z czołówki daje sobie radę. Autorzy podają rachunek, który jest ich szacunkiem, bez źródła: model o miliardzie parametrów potrzebuje co najmniej 10 000 przykładów, model o x miliardach 1/x tej liczby. Każda wyewoluowana instrukcja to co najmniej trzy wywołania modelu, więc zbiór 10 000 przykładów to ponad 30 000 wywołań, bo część odpada na kontroli jakości (rozdz. 5, Pattern 16). Wynik to model, który umie wąski zbiór zadań, i autorzy ostrzegają: „make sure you don't use an instruction-tuned model outside the narrow set of tasks you've trained it to do". Przy źródle RAG zadają też pytanie, które warto powtórzyć przy każdym projekcie: „if you have a RAG system capable of answering the question, why would you train a model to do that task?"

Sprawdziłem Chain of Thought na lokalnych modelach

Autorzy piszą, że dostawcy wbudowali rozumowanie w modele, więc Zero-shot CoT jest dziś przydatniejszy dla małych modeli lokalnych niż dla modeli z czołówki. Sprawdziłem tę część tezy, którą da się zmierzyć lokalnie. Porównałem modele bez trybu myślenia, z dopiskiem i bez niego, z modelami, które myślą same. Na stacji z GPU zrobiłem to na jednym modelu z myśleniem wyłączonym i włączonym. Modeli z czołówki nie sprawdzałem. Tree of Thoughts, Adapter Tuning i Evol-Instruct wymagają osobnej implementacji albo zbioru treningowego, więc ich nie mierzyłem.

Środowisko. Pomiar z 7 października 2026, temperatura 0, po jednym przebiegu na zadanie. Dwie maszyny:

Maszyna	Model	Tryb myślenia
laptop, sam CPU, llama.cpp b6153 (--device none, 6 wątków)	IBM Granite 4.0 H Tiny, Q4_K_M, 4,3 GB	nie
jw.	Qwen3-Coder-30B-A3B-Instruct, UD-Q3_K_XL, 13,8 GB	nie
jw.	Qwen3-30B-A3B-Thinking-2507, Q4_K_M, 18,6 GB	zawsze włączony
stacja z RTX 5090, vLLM v0.30.0	Qwen3.8-27B w INT4 od Red Hata, ten sam co w poprzednim wpisie	wyłączany i włączany na zapytanie (enable_thinking)

Zadania. 20 nowych zadań po polsku z jedną poprawną odpowiedzią, napisanych na ten pomiar zgodnie z ramką o odtwarzalności. Osiem to reguły z wyjątkami, wzorowane na regule bagażowej z książki: parking z limitem sobotnim, bagaż zależny od celu podróży, a nie przesiadki, staż pracy z limitem lat studiów, cennik muzeum z progami wieku. Sześć to obliczenia wieloetapowe (zbiornik z wyciekiem, płytki z zapasem i paczkami, dwa pociągi), sześć to daty i strefy czasowe. Odpowiedzi policzyłem sam, a daty sprawdziłem w Pythonie.

Dwa warianty promptu: bez CoT („Odpowiedz wyłącznie jedną linią w formacie: ODPOWIEDŹ: …, bez wyjaśnień") i z CoT („Rozwiąż to krok po kroku. Na końcu… ODPOWIEDŹ: …"). Modele z włączonym myśleniem dostały tylko wariant bez CoT, bo i tak rozumują przed odpowiedzią.

Wyniki

Model	Bez CoT	Z CoT	Z trybem myślenia	Tokeny wyjścia na 20 zadań (mediana na zadanie)
Granite 4.0 H Tiny	1/20	9/20	—	225 (11) → 5 641 (293)
Qwen3-Coder-30B-A3B	4/20	16/20	—	247 (11) → 8 110 (365)
Qwen3-30B-A3B-Thinking	—	—	20/20	22 115 (825)
Qwen3.8-27B INT4 (GPU)	6/20	19/20	19/20	243 (11) → 11 519 (480); z myśleniem 14 588 (306)

Wynik zgadza się z tą częścią tezy autorów, którą da się sprawdzić lokalnie. Każdy model bez trybu myślenia lub z wyłączonym myśleniem zyskał na dopisku dużo: 1 → 9, 4 → 16 i 6 → 19 zadań. Modele z włączonym myśleniem osiągnęły bez dopisku wynik równy najlepszemu z dopiskiem albo lepszy. Najczystsze porównanie daje Qwen3.8 na GPU, bo to te same wagi: z wyłączonym myśleniem i dopiskiem rozwiązał 19 zadań, z włączonym myśleniem bez dopisku też 19. Dopisek „krok po kroku" i wbudowany tryb myślenia dały tu ten sam wynik, co jest zgodne z tym, co autorzy piszą o wchłonięciu CoT przez modele i API.

Za rozumowanie płaci się tokenami w obu formach. Qwen3.8 z myśleniem miał niższą medianę niż z dopiskiem (306 wobec 480 tokenów), ale dłuższy ogon. Najdłużej, 6 034 tokeny, myślał nad zadaniem, które okazało się niejednoznaczne (niżej). Czy modelom z czołówki dopisek jeszcze pomaga, z tego pomiaru nie wynika, bo wszystkie testowane modele są lokalne i mniejsze od nich.

Czasów nie podaję jako wyniku. Część pomiaru na laptopie szła na baterii i ten sam model generował od 6,6 do 2,5 tokena na sekundę (odczyt z logu llama-server). Liczba tokenów nie zależy od zasilania, więc to ona jest tu miarą kosztu.

Jedno zadanie okazało się niejednoznaczne. W zadaniu o karze bibliotecznej nie napisałem, czy dzień zwrotu liczy się do zwłoki. Qwen3-Thinking wprost to rozważył i go nie policzył (3,50 zł zamiast moich 4,00 zł). Uznałem obie odpowiedzi. Żaden inny model nie podał 3,50 zł, więc nie zmieniło to pozostałych wyników.

Co poszło źle w rozumowaniu

Najciekawsze są błędy, które zostały mimo CoT, bo widać w nich dokładnie te dwie rzeczy, które opisują autorzy.

Logika poprawna, liczby zmyślone. Trzy z czterech błędów Qwen3-Codera z CoT to arytmetyka kalendarza i zegara, a nie rozumowanie. W zadaniu o terminie faktury model poprawnie rozpisał procedurę: dodaj 26 dni, sprawdź, czy wypada w weekend, przesuń na poniedziałek. Potem napisał, że 10.02.2026 + 26 dni to 05.03.2026 (jest 08.03), że 05.03.2026 to sobota (to czwartek) i że najbliższy poniedziałek po nim to 06.03.2026 (to piątek). Trzy fałszywe kroki w poprawnej strukturze. W zadaniu o spotkaniach co trzy tygodnie dodał 21 dni do 17 lutego i dostał 9 marca zamiast 10. W zadaniu o locie policzył 22:40 + 9 h 50 min jako 7:30 zamiast 8:30.

Na GPU jedyny błąd Qwen3.8 w obu wariantach z rozumowaniem dotyczył tego samego zadania o fakturze. Z dopiskiem model dobrze policzył datę 8 marca, ale uznał 28 lutego za piątek, a 8 marca za sobotę, i przesunął termin na „poniedziałek 10 marca". Z włączonym myśleniem sam zapisał, że luty 2026 ma 28 dni, a kilka linijek dalej liczył dni tygodnia przez „29 lut 2026" i wyszło mu, że 8 marca to poniedziałek. Bez dopisku i bez myślenia odpowiedział na to zadanie poprawnie. To ten sam rodzaj błędu co zhalucynowane mnożenie ze wstępu rozdziału. Lekarstwem według autorów jest narzędzie, a nie lepszy prompt. Wariantu z kalkulatorem albo kodem nie mierzyłem.

Poprawne kroki, sprzeczny wniosek. Granite w zadaniu o urlopie bez CoT odpowiedział poprawnie (20 dni). Z CoT policzył staż 5 + 3 = 8 lat i napisał: „Staż pracownika wynosi 8 lat, co spełnia warunek, aby pracownik miał 26 dni urlopu". Kroki są poprawne, wniosek sprzeczny z progiem 10 lat z treści zadania, a całość wygląda bardziej przekonująco niż samo „26". Razem z zadaniem o fakturze u Qwen3.8 to dwa przypadki, w których rozpisane rozumowanie zepsuło odpowiedź poprawną bez niego. Oba ilustrują obserwację autorów, że poprawnie wyglądające kroki mogą prowadzić do złej odpowiedzi („The logic is correct, but the destination is hallucinated"). Z tej i dwóch innych ich obserwacji składam własną tezę, że widoczne kroki nie są zapisem procesu.

Czwarty błąd Qwen3-Codera to odczytanie reguły: 16-latka zaliczył do przedziału ulgowego, choć reguła mówiła „nie ukończyły 16 lat". Granite podał w tym zadaniu ten sam wynik, 42 zł, ale z innego powodu. 16-latka policzył poprawnie, za to obojgu rodzicom naliczył razem 12 zł, a babcię policzył dwa razy. Zgodny wynik końcowy nie znaczy zgodnego rozumowania.

Czego ten pomiar nie mówi

Dwadzieścia zadań i jeden przebieg na zadanie to za mało, żeby różnice o jedno czy dwa zadania coś znaczyły. Duże różnice (1 → 9, 4 → 16, 6 → 19) są wyraźne, drobne nie. Nie mierzyłem modeli z czołówki ani wpływu kwantyzacji. Na Qwen3.8 nie łączyłem dopisku z włączonym myśleniem. Ten wpis publikuje zadania, więc zgodnie z ramką autorów od dziś nie nadają się do kolejnego testu.

Który brak naprawia które narzędzie

Tę tabelę złożyłem z rozdziałów 1, 3 i 5. Uważam ją za najużyteczniejszą rzecz decyzyjną w książce, choć autorzy nie zestawiają jej w jednym miejscu.

Czego brakuje modelowi	Narzędzie	Dlaczego nie inne
formy, stylu, formatu	few-shot, Style Transfer (wzorzec 3)	zmiana przykładów działa od razu
logiki, procedury	Chain of Thought (wzorzec 13) albo model z trybem myślenia	„RAG gives the model a (few) fish, while Few-shot CoT shows the model how to fish" (rozdz. 5, Pattern 13)
faktu	RAG (wzorce 6–12)	„You need that specific data point, and the only time you know it is during inference" (rozdz. 3, Pattern 6)
poprawnej arytmetyki	narzędzie, np. kalkulator (wzorzec 21)	lepszy prompt nie naprawi zhalucynowanego mnożenia (rozdz. 5, wstęp)
umiejętności bliskiej temu, co model umie	Adapter Tuning (wzorzec 15)	według autorów zwykle od kilkuset do kilku tysięcy przykładów, czasem około 100, często poniżej godziny na jednym GPU
żargonu, nowego języka	continued pretraining	adapter „doesn't change the model enough to enable such learning" (rozdz. 5, Pattern 15)
całkiem nowego złożonego zadania	instruction tuning z danymi z Evol-Instruct (wzorzec 16)	tysiące przykładów i świadoma utrata części ogólnych zdolności

Wiersz o arytmetyce wziąłem ze wstępu rozdziału. Autorzy pokazują tam, że model poprawnie zamienia 84 m² na stopy kwadratowe, ale samo mnożenie zmyśla: podaje 903,20 zamiast 904,1676. Lekarstwem jest kalkulator jako narzędzie, a nie lepszy prompt (rozdz. 5, wstęp). W moim pomiarze potwierdziła się część o błędach arytmetyki. Poprawy przez narzędzie nie mierzyłem.

To samo w innych książkach

François Chollet w Deep Learning with Python opisuje dostrajanie sieci wizyjnych sprzed ery LLM-ów i dochodzi do dwóch wniosków zbieżnych z Adapter Tuning. Pierwszy: bazę trzeba zamrozić, bo losowo zainicjalizowana nowa warstwa wysyła na początku treningu „very large weight updates", co skończyłoby się „effectively destroying the representations previously learned" (s. 231). Stąd kolejność: nowa głowa na zamrożonej bazie, dopiero potem odmrożenie kilku górnych warstw z bardzo niskim learning rate (s. 234, 236). Drugi wniosek jest ostrzeżeniem przed własnym wynikiem. 98,5% trafności po dostrojeniu na zdjęciach psów i kotów Chollet nazywa „not quite a fair comparison", bo pretrenowane cechy już wiedziały o psach i kotach (s. 237).

Chollet nie pisze o modelach językowych, więc przeniesienie jest moje. Pasuje jednak dokładnie do ramki Lakshmanana i Hapkego: dostrajanie przestawia to, co model już ma, a dobry wynik po dostrojeniu łatwo przypisać dostrajaniu, choć pochodzi z pretreningu.

Kiedy nie używać — zestawienie

Wzorzec	Nie używaj, gdy	Zamiast tego
Chain of Thought	brakuje danych, a nie logiki	RAG, dane w prompcie
Chain of Thought	wynik zależy od arytmetyki albo kalendarza	narzędzie liczące, kod
Chain of Thought	model ma wbudowany tryb myślenia	tryb myślenia, sprawdzany co pół roku
Tree of Thoughts	zadanie jest proste albo liczy się czas (u autorów 41 wywołań i 93 s na odpowiedź)	model rozumujący, least-to-most, Reflection
Adapter Tuning	potrzebny jest nowy fakt	RAG
Adapter Tuning	potrzebny jest żargon albo nowy język	continued pretraining
Evol-Instruct	model z czołówki daje radę, a zadanie ma publiczny odpowiednik	poczekać na następną wersję modelu
Evol-Instruct	istnieje RAG, który odpowiada na te pytania	RAG

Ocena trwałości

Moja ocena, nie autorów. Chain of Thought jako dopisek w prompcie jest datowany. Autorzy sami to przyznają, a mój pomiar pokazuje, gdzie dziś leży jego wartość: przy modelach bez trybu myślenia dopisek dawał dużo, a ten sam model z włączonym myśleniem osiągał bez niego to samo. Pojedynczych błędów w arytmetyce kalendarza nie usuwało ani jedno, ani drugie. Tree of Thoughts jest datowany z tego samego powodu i dodatkowo przez koszt. Trwała jest z niego idea oceniania kroków pośrednich, którą przejmują pętle agentowe. Adapter Tuning jest trwały, bo opiera się na stałej obserwacji: mała zmiana wag przestawia zachowanie, ale nie dopisuje wiedzy. Datowane są tylko liczby (ile przykładów, ile minut GPU). Evol-Instruct jest trwały jako technika danych. Jego opłacalność spada jednak z każdą wersją modelu ogólnego, chyba że zadanie nie ma publicznego odpowiednika.

Najtrwalsze w całym rozdziale nie są jednak wzorce, tylko dwa zdania autorów. Pierwsze: opublikowany błąd modelu przestaje być testem. Drugie: wstaw w kalendarz przypomnienie i za pół roku sprawdź, czy CoT jest jeszcze potrzebny. To drugie stosuję szerzej niż do CoT: każde obejście ograniczenia modelu dostaje u mnie datę przeglądu.

Starszy krewny

Tree of Thoughts to przeszukiwanie przestrzeni stanów z klasycznej sztucznej inteligencji: beam search z funkcją oceny, w której heurystykę zastąpił model. Adapter Tuning to transfer learning, który Chollet opisywał na sieciach konwolucyjnych. Evol-Instruct przypomina fuzzing mutacyjny: z poprawnego wejścia robi się automatycznie trudniejsze i sprawdza, czy system je przetrwa. Tu jednak celem nie jest znalezienie błędu, tylko zbiór treningowy. Chain of Thought ma krewnego w szkolnym „pokaż obliczenia", z tym samym zastrzeżeniem: zapis obliczeń da się sprawdzić tylko wtedy, gdy ktoś go sprawdza.

Dalej w serii

Następny wpis (5) dotyczy rozdziału 6, czyli niezawodności: LLM-as-Judge, Reflection, Dependency Injection i Prompt Optimization. Zajmę się w nim tym, że ewaluator staje się specyfikacją systemu, a prompt jest artefaktem kompilacji pod konkretną wersję modelu. Mapa całej serii jest we wpisie 0.