Chain‑of‑Thought: kontrola ujawniania, uzasadnienia i audyt

I. Problem: rozliczalność bez nadmiaru ujawnień

Zespoły często dochodzą do pozornie prostego wniosku: „skoro model popełnia błędy, to poprośmy o tok myślenia”. Krótkoterminowo to pomaga w debugowaniu. Długoterminowo potrafi stać się obciążeniem: dłuższe odpowiedzi, większy koszt, większa powierzchnia naruszeń (PII, sekrety, złośliwy kontekst) i rosnąca trudność review.

Dojrzałe podejście enterprise jest tradycyjne: rozliczalność buduje się przez kontrakt, bramki jakości i audyt, a nie przez publikowanie pełnego scratchpadu.

II. Trzy poziomy: wynik, rationale, ślad audytu

W praktyce porządkujemy temat w trzech poziomach:

Ten podział jest praktyczny: możemy być „przezroczyści” tam, gdzie to potrzebne (audyt), i oszczędni tam, gdzie to właściwe (komunikacja).

III. Kontrakt odpowiedzi: „uzasadnienie produkcyjne”

Uzasadnienie produkcyjne ma trzy cechy: jest krótkie, jest weryfikowalne i nie zdradza „mechaniki systemu”. Najprostszy kontrakt, który sprawdza się w praktyce:

Kontrakt (rationale):
1) Teza / wniosek (1–2 zdania)
2) Evidence: źródła lub cytowania (jeżeli wymagane)
3) Założenia i braki danych (jeżeli występują)
4) Następny krok (jeżeli potrzebny)

To podejście jest bliskie temu, jak tradycyjnie pisze się uzasadnienia decyzji w organizacji: wniosek, podstawa, założenia, konsekwencje. Dodatkowo jest testowalne: można sprawdzić, czy istnieją źródła, czy założenia są jawne i czy format jest kompletny.

III.a. Rationale nie jest „dowodem”

Rationale można napisać ładnie i błędnie. Dlatego w systemach o podwyższonych wymaganiach elementem obowiązkowym powinno być evidence: dokument, log narzędzia, link do KB, numer procedury. Bez evidence rationale jest tylko narracją.

IV. Polityka ujawniania (Disclosure Policy)

Polityka ujawniania to zestaw reguł: co wolno publikować w odpowiedzi, a co zostaje w warstwie audytu. Dobrze, jeśli jest prosta, wersjonowana i ma jasno zdefiniowane poziomy.

Poniżej przykład „czytelnego” zapisu reguł w formie, którą da się wersjonować (w praktyce to może być YAML/JSON w repozytorium polityk):

disclosure_policy:
  external:
    rationale: short
    citations_required: true
    forbid:
      - pii
      - secrets
      - system_prompts
      - internal_identifiers
  internal:
    rationale: medium
    citations_required: true
    allow:
      - assumptions
      - decision_tradeoffs
  audit:
    rationale: off
    log:
      - trace_id
      - policy_versions
      - sources
      - validation_results

V. Walidacje i bramki jakości

Największy postęp jakościowy robi się wtedy, gdy zamiast „wierzyć w dobre rozumowanie”, wprowadzamy walidacje. Typowe bramki jakości dla workflow opartych o CoT:

• Walidacja formatu (schemat, obowiązkowe sekcje, JSON schema).
• Walidacja cytowań (pokrycie tez vs źródła).
• Wykrywanie PII i sekretów (DLP, redakcja).
• Wykrywanie injection (instrukcje w źródłach, próby nadpisania polityk).
• Spójność terminologii (glosariusz, standard językowy).

VI. Operacje: trace_id, retencja, regresje, wyjątki

Jeżeli CoT ma pracować w produkcji, musi być obsługiwane jak każdy element systemu: z wersjonowaniem, monitoringiem i procedurą wyjątków.

VI.a. trace_id jako kręgosłup

Każda odpowiedź powinna mieć trace_id. W śladzie audytu zapisujemy: wersję policy packa, wersję glosariusza, listę źródeł, wyniki walidacji oraz — jeżeli dotyczy — logi narzędzi. To pozwala odtwarzać incydenty i regresje.

VI.b. Retencja i kontrola dostępu

Audyt jest wrażliwy, bo zawiera „prawdę o systemie”: wersje, źródła, wyniki bramek. Dlatego ślad audytu wymaga retencji, uprawnień i zasad udostępniania (kto, kiedy, na jakiej podstawie).

VI.c. Regresje i golden set

Zmiany w promptach, politykach i kontekście to zmiany w zachowaniu systemu. Tradycyjnie rozwiązuje się to testami regresji. W Luage rekomendujemy golden set: przykłady reprezentatywne + progi jakości (format, cytowania, naruszenia).

VI.d. Wyjątki

Zawsze będą przypadki, w których źródeł nie ma lub odpowiedź nie przechodzi walidacji. To powinno kończyć się decyzją operacyjną: odmowa, eskalacja, prośba o doprecyzowanie albo tryb „tylko streszczenie”. Nie powinno kończyć się automatycznym „dopiszmy więcej CoT”.

VII. Antywzorce (czego unikać)

1. Publikowanie scratchpadu na zewnątrz — zwykle jest zbędne i zwiększa ryzyko.
2. Rationale bez źródeł w systemie, który deklaruje oparcie o KB/RAG.
3. „Zwiększmy temperaturę i dodajmy CoT” jako odpowiedź na problemy jakościowe.
4. Brak trace_id — brak odtwarzalności, brak kontroli zmian.
5. Brak polityki wyjątków — chaos operacyjny i niejawne obejścia.

VIII. Checklista dla zespołu

• Ustal poziomy: wynik vs rationale vs audyt.
• Zdefiniuj politykę ujawniania: co wolno publikować, co zawsze redagujemy.
• Wprowadź walidacje: format, cytowania, PII/secrets, injection.
• Zadbaj o ślad audytu: trace_id, wersje, źródła, wyniki bramek.
• Testuj regresyjnie: golden set i progi jakości.
• Zaplanuj wyjątki: odmowa, eskalacja, tryb awaryjny.

To jest konserwatywny zestaw praktyk — i właśnie dlatego działa. W organizacji liczy się przewidywalność i rozliczalność, a nie efektowność wywodu.