Chain‑of‑Thought (CoT): od wzorca promptowania do kontrolowanej rozumności

I. Ramy: co w praktyce oznacza Chain‑of‑Thought

Chain‑of‑Thought (CoT) jest dziś słowem‑kluczem, ale w organizacji dojrzałej warto go od razu „uziemić”. W najprostszym ujęciu CoT oznacza, że model wykonuje serię kroków pośrednich zamiast próbować odpowiedzieć jednym skokiem. To może przyjmować postać:

• jawnego toku w tekście (model wypisuje kroki),
• niejawnego scratchpadu (kroki powstają w procesie, ale nie są publikowane),
• planu (krótki szkic działań, bez szczegółów),
• serii wywołań narzędzi (plan → narzędzie → wynik → synteza).

W każdym wariancie chodzi o to samo: zmniejszyć ryzyko pominięcia kroku. Jeżeli zadanie wymaga rozbicia na części (diagnostyka, porównanie opcji, policzenie wartości, analiza kontraktu), CoT zwykle zwiększa trafność.

II. Definicje operacyjne (CoT, rationale, scratchpad, plan)

W praktyce zespoły mieszają pojęcia. Dla porządku przyjmujemy następujący słownik roboczy:

Kluczowe rozróżnienie: CoT to mechanizm, rationale to forma komunikacji. Organizacje często proszą o „tok myślenia”, kiedy tak naprawdę potrzebują rationale + evidence (czyli krótkiej argumentacji opartej o źródła).

III. Kiedy CoT działa — a kiedy szkodzi

CoT działa najlepiej w zadaniach:

• kompozycyjnych (zależności, kilka etapów, kilka źródeł),
• warunkowych (jeżeli X, to Y; w przeciwnym razie Z),
• proceduralnych (procesy, checklisty, diagnostyka),
• decyzyjnych (porównanie opcji, trade‑offy, konsekwencje),
• opartych o źródła (RAG), gdzie trzeba połączyć fragmenty w jedną odpowiedź.

III.a. Kiedy CoT szkodzi

CoT bywa kosztowne. Typowe powody, dla których „psuje” wynik:

1. Wylewność zamiast kontroli: długi tok zwiększa koszt i liczbę miejsc, w których może pojawić się błąd.
2. Dryf formatu: przy długich wywodach rośnie ryzyko pominięcia wymaganych sekcji lub schematu.
3. Pozorna wiarygodność: wywód brzmi przekonująco nawet wtedy, gdy jest błędny.
4. Ryzyko ujawnień: w scratchpadzie łatwiej „przemycić” dane wrażliwe albo elementy wewnętrznego kontekstu.

III.b. Przykład: kontrolowane rozumowanie zamiast „krok po kroku”

Poniżej dwa polecenia o tym samym celu. Pierwsze jest typowe, drugie jest produkcyjne.

„Wyjaśnij wszystko krok po kroku, bardzo szczegółowo.”

„Ułóż plan w 3–5 punktach. Następnie podaj wynik.
Uzasadnienie ogranicz do 2–4 zdań. Jeżeli brak danych — wskaż brak.
Dla twierdzeń faktograficznych podaj źródła.”

IV. Warianty i podejścia pokrewne

CoT to nie jedna technika, tylko rodzina podejść. W praktyce warto znać przynajmniej te warianty:

W kontekście Luage ważne jest nie tyle „jaką nazwę ma wariant”, tylko czy jest: (1) kontrolowany, (2) testowalny, (3) audytowalny. Bez tych trzech cech CoT szybko staje się sztuką dla sztuki.

V. CoT w RAG i narzędziach (tool‑use)

W systemach opartych o Retrieval‑Augmented Generation CoT ma dwie użyteczne funkcje: łączy fragmenty oraz pilnuje braków. Model może przejść przez etapy: „co wiem ze źródeł”, „czego nie wiem”, „co muszę doprecyzować”.

V.a. Wzorzec: synteza źródeł bez „dopowiadania”

Największy błąd w RAG to sytuacja, w której model dopowiada fakty poza źródłami. Tutaj CoT nie jest celem samym w sobie — jest sposobem na wymuszenie dyscypliny: najpierw ekstrakcja, potem synteza, na końcu odpowiedź.

Wymagania (RAG):
- Najpierw wypisz tezy, które wynikają z dokumentów (z cytowaniem).
- Jeżeli w dokumentach nie ma odpowiedzi, powiedz „brak w źródłach”.
- Dopiero potem zsyntetyzuj rekomendację w 3–6 zdaniach.

V.b. CoT przy wywołaniach narzędzi

Jeżeli model ma używać narzędzi (wyszukiwarka, baza danych, kalkulator, system ticketowy), „tok” powinien być w praktyce planem i listą kroków narzędziowych. To jest tradycyjny wzorzec automatyzacji: najpierw plan, potem wykonanie, potem raport.

• Plan jest częścią audytu: „jakie narzędzie, dlaczego, jakie parametry”.
• Wynik narzędzia jest źródłem (evidence).
• Odpowiedź jest syntezą, a nie zgadywaniem.

VI. CoT a jakość: zyski, złudzenia i metryki

CoT może podnosić trafność, ale nie jest dowodem poprawności. Z perspektywy jakości interesują nas dwa pytania:

1. czy wynik jest poprawny i zgodny z kontraktem (format, źródła, polityki),
2. czy proces jest kontrolowany (ryzyka, regresje, obserwowalność).

VI.a. Trzy typowe złudzenia

1. „Długi tok = prawda” — nie. Długi tok = więcej tekstu do zweryfikowania.
2. „Uzasadnienie = źródło” — nie. Źródłem jest dokument, log narzędzia, baza, polityka.
3. „CoT jest stabilne” — nie. Bywa wrażliwe na drobne zmiany kontekstu i kolejność instrukcji.

VI.b. Metryki praktyczne

• Zgodność formatu (schemat, sekcje, JSON) — walidowalna automatycznie.
• Pokrycie cytowań — odsetek tez z przypisanym źródłem.
• Naruszenia polityk — PII/DLP, zakazane obietnice, prompt injection.
• Stabilność — regresje na golden set.
• Efektywność — koszt tokenów i czas odpowiedzi.

VII. Ujawnianie „toku myślenia”: polityka, ryzyko, zgodność

W środowisku enterprise pytanie nie brzmi „czy model ma rozumować”, tylko: co wolno ujawnić odbiorcy i w jakiej formie. Jeżeli system dotyka danych wrażliwych, pełny scratchpad bywa niepożądany.

W Luage standardem jest rozdzielenie dwóch rzeczy: mechanizmu (CoT w procesie) i publikacji (rationale). Jeżeli organizacja potrzebuje rozliczalności, to nie „publikujemy wszystko”, tylko wdrażamy politykę ujawniania i dowozimy audyt (trace_id, wersje polityk, źródła, walidacje).

VIII. Wdrożenie produkcyjne: wzorce Luage

W praktyce produkcyjnej CoT powinno być częścią pakietu kontekstu. Dwa wzorce, które sprawdzają się w Luage:

VIII.a. „Plan → Wynik → Rationale”

Zamiast prosić o pełny „tok myślenia”, prosimy o plan (kontrolowany), wynik oraz krótkie uzasadnienie. Plan jest łatwy do przetestowania i pozwala utrzymać tradycyjną dyscyplinę: najpierw porządek, potem wykonanie.

Format:
1) Plan (3–5 punktów)
2) Wynik
3) Rationale (2–4 zdania)
4) Źródła / cytowania (jeżeli wymagane)
5) Założenia i brakujące dane

VIII.b. „Generator + Weryfikator”

Rozdzielamy generowanie od kontroli. Generator tworzy treść, weryfikator ocenia zgodność. To stara, dobra inżynieria jakości: redakcja i kontrola są osobnymi krokami.

VIII.c. Budżet tokenów i latency

W praktyce CoT kosztuje. Zanim włączymy „więcej rozumowania”, warto ustalić:

• jakie są progi akceptowalnej latencji (SLA),
• jakie są limity kosztu na żądanie,
• czy CoT ma być używane zawsze, czy tylko w „trudnych przypadkach”.

Dojrzałe wdrożenia robią to po staremu: najpierw progi i kontrola kosztu, potem optymalizacja.

IX. Checklista wdrożeniowa

• Cel: czy CoT jest potrzebne dla tej klasy zadań, czy wystarczy plan?
• Ujawnianie: czy publikujemy rationale, czy tylko wynik + źródła?
• Źródła: czy wymagamy cytowań i czy pipeline to egzekwuje?
• Walidacje: PII/DLP, injection, zakazane zwroty, zgodność schematu.
• Testy regresji: golden set, progi jakości, monitoring dryfów.
• Obserwowalność: trace_id, wersje polityk, lista źródeł i wynik walidacji.
• Tryb awaryjny: co robimy, gdy brakuje źródeł lub walidacja nie przechodzi?

X. Podsumowanie

CoT jest użyteczne w zadaniach wielokrokowych, ale tylko wtedy, gdy jest osadzone w procesie: polityki, format, źródła, walidacje i audyt. W organizacji dojrzałej nie pytamy „czy model rozumuje”, tylko „jak kontrolujemy wejście, wynik i ryzyko”.

Dla zastosowań enterprise rekomendujemy prostą zasadę: wynik + zwięzłe rationale + evidence. Pełny tok rozumowania traktujemy jako narzędzie wewnętrzne procesu, nie jako produkt końcowy.