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.
- Pri vyššej
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.
- Pri úlohách, kde je stabilita dôležitejšia než kreativita: nižšia
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.