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, často si protirečí, opakovane sa opravuje 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/latenciu) a pri agentoch môže viesť k chaotickým akciá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 to je A… nie, počkaj, je to B… prepáč… vlastne A…“

  • Kde sa to objaví: matematika, logika, extrakcia z dlhého kontextu, rozhodovanie v agentickom režime (plánovanie + tool-calling), alebo pri promptoch typu „over si to ešte 3ד.


2. Ako to funguje / prečo k tomu dochádza

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

  • Konflikt medzi „vypočítaným“ a „naučeným“ vzorom

    • Model môže naraziť na situáciu, kde mu jedna časť výpočtu naznačuje výsledok A, ale natrénované asociácie (časté príklady, šablóny) ťahajú na B.
  • Príliš agresívna seba-kontrola (overthinking)

    • Keď ho nútiš opakovane „revidovať“, model môže namiesto verifikácie rozkolísať rozhodnutie.

    • Pri dlhých odpovediach sa zvyšuje šanca, že „nájde“ niečo, čo si sám vyloží ako rozpor, aj keď to rozpor nie je.

  • Stochastika generovania

    • Pri vyššej temperature (alebo všeobecne menej deterministickom dekódovaní) môže model ľahšie „preskočiť koľaj“ na iný variant odpovede.
  • Kontextové preťaženie a slabé ukotvenie

    • Ak je v kontexte veľa podobných čísel, pravidiel, výnimiek alebo protichodných signálov, model môže robiť „ping-pong“ medzi interpretáciami.
  • Rozdiel medzi „rozmýšľaním“ a „finálom“

    • Niektoré režimy/šablóny odpovede podporujú rozsiahle deliberovanie. Ak sa deliberácia zacyklí, finál môže pôsobiť ako séria panických opráv.

3. Hlavné prejavy a riziká

  • Flip-flop odpovede: A → B → A (bez novej informácie).

  • Rast verbosity: čím viac sa opravuje, tým viac textu produkuje (a tým viac šancí na ďalšiu chybu).

  • Zhoršenie dôvery: používateľ nevie, ktorý výsledok je „ten pravý“.

  • Nákladovosť: vyššie tokeny, vyššia latencia.

  • Riziko pri agentoch: nestabilné rozhodovanie môže spôsobiť:

    • zbytočné tool-cally,

    • opakované kroky,

    • zlé „commitnutie“ akcie (napr. zmena plánu tesne pred vykonaním).


4. Praktické riešenia (čo robiť v praxi)

Pre používateľa (promptovanie)

  • 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ď. Ak si nie si istý, pridaj mieru istoty, ale nemeníš výsledok bez nového dôkazu.“
  • Zmeň typ kontroly

    • Namiesto „prepíš celé riešenie“: „Nájdi 2 najpravdepodobnejšie chyby a skontroluj len tie.“
  • Rozdeľ problém

    • Najprv nech vyrobí medzi-výsledky (premenné, predpoklady), až potom finále.
  • Použi externú verifikáciu

    • Pre výpočty: nech vygeneruje krátky kontrolný kód / postup, ktorý sa dá ľahko overiť.

Pre vývojára (systémové opatrenia)

  • Deterministickejšie nastavenia

    • Pri úlohách, kde je stabilita dôležitejšia než kreativita: nižšia temperature, pevnejšie formáty.
  • Obmedz „reflection budget“

    • Nastav strop na počet kontrolných iterácií / dĺžku deliberácie.
  • Hlasovanie viacerých behov, potom uzamknutie

    • Namiesto jedného dlhého „seba-prepisovania“: 3 nezávislé krátke odpovede → vyber najčastejšiu → už len krátka validácia.
  • Detekcia thrashingu

    • Sleduj signály ako opakované ospravedlnenia, protirečenia, zmeny finálnej voľby, a vtedy:

      • prepnúť na nástroj (kalkulačka),

      • skrátiť kontext,

      • vyžiadať doplňujúci vstup (alebo eskalovať človeku).

  • Tool-first pri presných úlohách

    • Pri matematike, parsovaní, extrakcii: radšej nástroj alebo štruktúrovaný pipeline než „čisté rozprávanie“.

Quick Reference

  • Keď vidíš flip-flop odpovede: zníž „overthinking“, rozdeľ úlohu, vynúť jedno finále.

  • Keď ide o presnosť: použi deterministické nastavenia a/alebo nástroje.

  • Keď ide o dlhý kontext: skráť vstup na relevantné pasáže a ukotvi pravidlá (čo je cieľ, čo sa nesmie meniť).


Zhrnutie

  • Answer trashing/thrashing je nestabilita, kde sa model preklápa medzi odpoveďami a nevie sa rozhodnúť.

  • Často ho zhoršuje prehnaná seba-kontrola a preťažený kontext.

  • Najlepšie funguje kombinácia: jednoznačný commit na finále, menej reflexie, deterministickejšie nastavenia a externá verifikácia.