Answer Thrashing

Answer Thrashing je jav, keď LLM „stráca stabilitu" pri odpovedi: začne sa preklápať medzi viacerými kandidátnymi odpoveďami, opakovane si odporuje, koriguje sa a niekedy sa ani nevie jednoznačne „uzamknúť" na finálnom výsledku. V praxi to znižuje spoľahlivosť, zvyšuje náklady (tokeny, latencia) a pri agentoch môže viesť k chaotickým akciám. S nástupom reasoning modelov — ako Claude s rozšíreným myslením, OpenAI o3/o4 alebo Gemini s thinking módom — ktoré veľa „rozmýšľajú" pred odpoveďou, je tento jav aktuálnejší než kedykoľvek predtým.

1. Definícia (čo to je)

  • Podstata: model v krátkom čase vyprodukuje sériu nekonzistentných odpovedí (alebo interných krokov), kde sa odpoveď mení bez nových dôkazov.
  • Typický vzor: „Správne je A… nie, počkaj, je to B… prepáč, vlastne A… alebo B?"
  • Kde sa objaví: matematika, logika, extrakcia z dlhého kontextu, agentický režim (plánovanie + tool-calling), alebo pri promptoch typu „over si to ešte 3×".
  • Čo to nie je: normálna korekcia na základe nových informácií. Ak model dostane nový fakt a zmení odpoveď, to je žiaduce správanie. Answer thrashing je zmena bez externého podnetu — čisto z vnútornej nestability.

2. Prečo k tomu dochádza

Zvyčajne nejde o jeden „bug", ale o súbeh viacerých tlakov:

  • Konflikt „vypočítaného" a „naučeného" vzoru: jedna časť výpočtu naznačuje A, ale natrénované asociácie (časté šablóny) ťahajú na B. Tu sa prejavuje inductive bias modelu.
  • Príliš agresívna seba-kontrola (overthinking): keď model nútiš opakovane revidovať, namiesto verifikácie rozkolíše rozhodnutie. Paradoxne, viac kontroly = horšia odpoveď.
  • Stochastika generovania: pri vyššej temperature model ľahšie „preskočí koľaj" na iný variant. Každý token ovplyvňuje pravdepodobnostné rozdelenie nasledujúcich tokenov — malá náhoda sa môže kaskádovito zosilniť.
  • Kontextové preťaženie: ak je v kontexte veľa podobných čísel, pravidiel a protichodných signálov, model robí „ping-pong" medzi interpretáciami. Súvisí s limitmi kontextového okna.
  • Nejednoznačný prompt: ak zadanie pripúšťa viacero rovnako pravdepodobných odpovedí, model sa môže cykliť medzi nimi.
  • Rozdiel medzi „rozmýšľaním" a „finálom": ak sa deliberácia zacyklí, finál pôsobí ako séria panických opráv namiesto premysleného záver.

3. Hlavné prejavy a riziká

Ako vyzerá v praxi

Flip-flop v matematike:

„Výsledok je 47. Počkaj, prepočítam: 52. Alebo… vlastne 47, ako som povedal."

Flip-flop v extrakcii faktov:

„Článok hovorí, že termín je 15. júna. Ale nie, v ďalšom odseku je 20. júna. Takže asi 15? Alebo 20."

Flip-flop v kóde:

Model vygeneruje funkciu, potom ju prepíše, potom sa vráti ku pôvodnej verzii s mierne iným formátovaním.

Riziká

Riziko Závažnosť Kontext
Zhoršená dôvera používateľa Vysoká Chatboty, asistenti
Vyššie náklady na tokeny Stredná Všetky prípady
Vyššia latencia Stredná Reasoning modely
Chaotické tool-cally Vysoká Agentické systémy
Nekonzistentné dáta v pipeline Kritická Automatizácia, RAG
Zacyklenie agenta Kritická Multi-krokové úlohy

4. Meranie a detekcia

Thrashing je možné detekovať automaticky — čo je kľúčové pri nasadení v produkcii.

Signály v texte

  • Počet ospravedlnení: výrazy ako „prepáč", „omyl", „opravujem", „vlastne" — viac ako 2–3 v jednej odpovedi sú varovným signálom.
  • Protirečenia: finálna odpoveď sa líši od odpovede na rovnakom mieste v predskornej časti (napríklad v CoT reťazci).
  • Opakované bloky: dlhé identické alebo takmer identické pasáže signalizujú zacyklenie.

Kvantitatívne metriky

import re
from difflib import SequenceMatcher

def detect_thrashing(response: str) -> dict:
    hedges = len(re.findall(
        r'\b(vlastne|opravujem|prepáč|omyl|počkaj|nie,\s+skôr|alebo\s+skôr)\b',
        response, re.IGNORECASE
    ))
    sentences = response.split('.')
    pairs = zip(sentences, sentences[1:])
    flips = sum(
        1 for a, b in pairs
        if SequenceMatcher(None, a.strip(), b.strip()).ratio() < 0.3
        and len(a) > 20 and len(b) > 20
    )
    return {
        "hedge_count": hedges,
        "flip_score": flips,
        "thrashing_likely": hedges > 2 or flips > 3
    }

Monitoring v agentoch

Pri dlhších agentických úlohách sleduj:

  1. Počet opakovaných tool-callov s rovnakými parametrami.
  2. Entropiu plánov — ak agent mení plán viackrát bez nového vstupu, je to thrashing na úrovni plánovania.
  3. Divergenciu medzi krokom N a krokom N+2 — návrat k odmietnutému riešeniu.

5. Riešenia pre používateľa (promptovanie)

Základné techniky

  • Zníž počet revízií v jednom pase: namiesto „over si to 5×" skús „Urob jednu kontrolu a potom daj finálny výsledok."
  • Vynúť commit na finál:
Na konci uveď IBA jednu finálnu odpoveď vo formáte:
FINÁLNA ODPOVEĎ: [odpoveď]

Ak si nie si istý, pridaj mieru istoty (0–100 %),
ale NEMEŇ výsledok bez nového dôkazu.
  • Zmeň typ kontroly: namiesto „prepíš celé riešenie" skús „Nájdi 2 najpravdepodobnejšie chyby a skontroluj len tie."
  • Rozdeľ problém: najprv medzi-výsledky (premenné, predpoklady), až potom finále.

Štruktúrovaný prístup pre zložité úlohy

Postup:
1. Zapíš predpoklady a vstupné dáta.
2. Vypočítaj výsledok.
3. Skontroluj JEDEN krát: je výsledok konzistentný s predpokladmi?
4. Napíš FINÁLNA ODPOVEĎ: [výsledok].
Neprekračuj krok 3 viac ako raz.
  • Použi externú verifikáciu: pre výpočty nech model vygeneruje krátky kontrolný kód, ktorý sa dá overiť.
  • Anchor technikou: explicitne pomenuj „správnu trasu" na začiatku a žiadaj modelu, aby sa k nej vrátil, nie aby ju prepisoval.

6. Riešenia pre vývojára (systémové)

Nastavenia pri inference

  • Deterministickejšie nastavenia: pri úlohách, kde je dôležitejšia stabilita než kreativita, zníž temperature a daj pevné formáty (JSON schema, structured outputs).
  • Obmedz „reflection budget": strop na počet kontrolných iterácií a dĺžku deliberácie. Reasoning modely dnes ponúkajú priamy parameter — budget_tokens v Anthropic API, reasoning_effort v OpenAI API.
  • Výstupné schémy: ak model musí odpovedať v pevnom JSON formáte, má menej priestoru na flip-flop v prirodzenom jazyku.

Self-consistency hlasovanie

Namiesto jedného dlhého seba-prepisovania spravíš viac krátkych nezávislých odpovedí a vyberieš najčastejšiu:

from collections import Counter

def self_consistent_answer(prompt: str, model_fn, n: int = 5) -> str:
    answers = [model_fn(prompt, temperature=0.7) for _ in range(n)]
    # majority vote
    final = Counter(answers).most_common(1)[0][0]
    return final
    # až potom krátka validácia finálu — nie ďalšie prepisovanie

Táto technika je obzvlášť účinná pri matematických úlohách a extrakcii faktov, kde odpovede sú diskrétne a porovnateľné.

Detekcia a eskalácia v pipeline

def safe_inference(prompt: str, model_fn, fallback_tool=None) -> str:
    response = model_fn(prompt)
    result = detect_thrashing(response)
    if result["thrashing_likely"]:
        if fallback_tool:
            return fallback_tool(prompt)  # kalkulačka, parser, externý nástroj
        # alebo prepni na self-consistency
        return self_consistent_answer(prompt, model_fn)
    return response
  • Tool-first pri presných úlohách: pri matematike, parsovaní a extrakcii radšej nástroj alebo štruktúrovaný pipeline než „čisté rozprávanie".
  • Skrátenie kontextu: ak je kontext preťažený, pred opakovaným volaním ho prefiltruj na relevantné pasáže.

7. Answer Thrashing v agentických systémoch

Agentické systémy sú na thrashing osobitne citlivé, pretože nestabilné rozhodnutia sa propagujú naprieč krokmi:

  1. Thrashing v plánovaní: agent opakovane mení plán (A → B → A), čo vedie k zbytočným tool-callom a plytvaniu zdrojmi.
  2. Thrashing pri tool selection: agent volá viaceré nástroje na ten istý podproblém namiesto commitnutia na jeden.
  3. Thrashing tesne pred akciou: najnebezpečnejší prípad — model zmení plán pri poslednom kroku, keď je akcia (napríklad zmazanie súboru, odoslanie správy) nezvratná.

Ochranné vzory pre agenty

Vzor Popis Kedy použiť
Plan lock Plán sa uzamkne po schválení, ďalšie revízie sú zakázané Nezvratné akcie
Iteration cap Maximálny počet plánovacích iterácií (napr. 3) Všetky agenty
Confirmation gate Pred každou nezvratnou akciou explicitné potvrdenie Produkčné nasadenie
State snapshot Snímka stavu pred každým krokom, rollback pri thrashingu Dlhé multi-krokové úlohy
Escalation handler Pri detekcii thrashingu eskaluj na človeka alebo fallback Kritické systémy

8. Súvislosť s reasoning modelmi

Moderné reasoning modely — Claude s extended_thinking, OpenAI o3/o4, Google Gemini 2.5 s thinking módom — zámerne generujú dlhý interný „chain of thought". To zvyšuje kvalitu na ťažkých úlohách, ale aj riziko thrashingu, ak nemajú jasný signál, kedy uvažovanie ukončiť.

Čo sa zmenilo v roku 2026

  • Thinking budgets sú explicitné: Anthropic API umožňuje nastaviť budget_tokens pre extended thinking. Príliš nízky budget = skrátené uvažovanie, príliš vysoký = priestor na zacyklenie.
  • Streaming thinking tokenov: vývojári môžu sledovať interné uvažovanie v reálnom čase a detekovať thrashing skôr, ako model dôjde k finálnej odpovedi.
  • Trénované "commit" signály: lepšie modely sú trénované cez RLHF rozpoznať, kedy je problém dostatočne vyriešený a zastaviť deliberáciu. Slabšie alebo zle promptované modely sa točia donekonečna.
  • Propagácia v multi-agentových sieťach: ak jeden reasoning agent thrashuje a posiela nekonzistentné správy ďalším agentom, celá sieť môže upadnúť do chaosu. Toto je nová výzva špecifická pre rok 2025–2026, keď sa multi-agentové frameworky stali bežnou praxou.

Praktické nastavenie thinking budgetu

import anthropic

client = anthropic.Anthropic()

response = client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=8000,
    thinking={
        "type": "enabled",
        "budget_tokens": 3000  # strop pre deliberáciu — znižuje thrashing
    },
    messages=[{
        "role": "user",
        "content": "Vypočítaj..."
    }]
)

Nastavenie budget_tokens na rozumnú hodnotu (nie príliš nízku, nie príliš vysokú) je jeden z najefektívnejších spôsobov, ako potlačiť thrashing pri reasoning modeloch bez straty kvality.

Quick Reference

Príznak Príčina Čo spraviť
Flip-flop odpovede Overthinking, konflikt vzorov Zníž reflexiu, vynúť jedno finále
Ide o presnosť Vysoká temperature, nejednoznačný prompt Deterministické nastavenia + nástroje
Dlhý kontext Preťaženie kontextového okna Skráť vstup, ukotvi pravidlá
Agent sa točí Thrashing v plánovaní Iteration cap + detekcia + eskalácia
Reasoning model sa zacyklí Príliš veľký thinking budget Nastav budget_tokens, použij streaming detekciu
Nekonzistentné výstupy v pipeline Stochastika + flip-flop Self-consistency hlasovanie (n=5)

Zhrnutie

  • Answer Thrashing je nestabilita, keď sa model preklápa medzi odpoveďami bez nových dôkazov — typicky z dôvodu overthinkingu, preťaženého kontextu alebo stochastiky generovania.
  • Najnebezpečnejší je v agentických systémoch, kde sa nestabilné rozhodnutia propagujú a vedú k nezvratným akciám.
  • Pre používateľov: vynúť jasný commit na finálnu odpoveď, obmedziť počet revízií, rozdeliť problém na menšie kroky.
  • Pre vývojárov: kombinuj nízku temperature, structured outputs, self-consistency hlasovanie, detekciu thrashingu a eskalačné mechanizmy.
  • S reasoning modelmi v roku 2026 pribudli nové nástroje: explicitné thinking budgety, streaming monitoring a trénované commit signály. Thrashing tu nie je nevyhnutný — je to konfiguračný a promptovací problém, nie fundamentálna chyba architektúry.