Úvod
Iterativní self‑correction — opakované vylepšování vlastních odpovědí modelem, aby se opravil vlastní chyby — je dnes běžnou součástí agentních systémů. Článek z arXivu si klade jednoduchou, ale praktickou otázku: kdy takové opakování skutečně zvyšuje přesnost a kdy ji naopak snižuje?
Co se vlastně stalo
Autoři framingují self‑correction jako kybernetickou zpětnou vazbu, kde ten samý LLM funguje současně jako controller (řídicí část) i plant (proces, který řídíme). Pro zjednodušení použijí dvoustavový Markovův model se stavy {Correct, Incorrect} a definují dvě důležité metriky: ECR (error correction rate — jak často iterace opraví chybu) a EIR (error introduction rate — jak často iterace zavede novou chybu). Dají z toho jednoduchý diagnostický test: iterate pouze když ECR/EIR > Acc/(1 − Acc).
Empiricky testují sedm modelů na třech datech (GSM8K, MATH, StrategyQA). Hlavní zjištění: existuje ostrý prah EIR ~ 0.5 % — nad ním self‑correction často škodí, pod ním pomáhá nebo je aspoň neškodná. Konkrétní příklady z paperu: o3‑mini zlepší o +3.4 procentního bodu (EIR = 0 %), Claude Opus 4.6 +0.6 pp (EIR ≈ 0.2 %), o4‑mini se drží ±0 pp, zatímco GPT‑5 degraduje o −1.8 pp. Verify‑first prompting (nejprve ověřit, než upravit) na GPT‑4o‑mini sníží EIR z 2 % na 0 % a změní degradaci −6.2 pp na +0.2 pp (p < 10^−4). Alternativní přístup ASC (adaptive stopping criterion) zastaví škodlivé iterace, ale má náklad: −3.8 pp kvůli dotazování na sebevědomí odpovědí.
Proč mě to zaujalo
Jednoduchost diagnostiky je osvěžující: formule ECR/EIR > Acc/(1 − Acc) je něco, co si můžete spočítat i bez hluboké teorie řízení. To znamená, že self‑correction nemusí být „nastaveno defaultně“ — je to kontrolní rozhodnutí založené na měřitelných datech. Také mi přijde praktické, že autorům stačí jednoduché promptingové zásahy (verify‑first) k posunu modelu přes kritický práh.
Co mě v tom zaráží
Papíru chybí několik provozních detailů, které mě zajímají: jak spolehlivě odhadnout EIR v nasazení bez ground‑truth anotací? Jaký je vliv nákladů a latence na rozhodnutí točit iterace? Nevidím zde rozbor, jak se chová dlouhý chain‑of‑thought (více kroků) nebo systémy, kde různé kroky dělají různé modely. Autorská data dávají jasné čísla pro testovací sady, ale nasazení v produktivním prostředí může mít jiné dynamiky chyb.
Co s tím v praxi
Nejpraktičtější takeaway: nechte self‑correction být adaptivní. Pokud dokážete odhadnout ECR a EIR (např. z validačních dat), použijte diagnostiku a neiterujte automaticky. Zkuste verify‑first prompting jako levný zásah: pokud to srazí EIR pod práh, můžete změnit degradaci v plus. Kdo nechce měřit, může nasadit ASC, ale musí počítat s cenou za vyžádání sebevědomí modelu.
Závěr
Self‑correction není vždy benefitem — může být kontrolní rozhodnutí založené na chování chyb, a autoři dávají praktickou metriku, kterou lze vyzkoušet. Mně osobně se líbí, že to dává jednoduchou operacionalizaci problému, i když v praxi bude rozhodovat, jak dobře umíme EIR měřit.
Zdroje
- When Does LLM Self‑Correction Help? A Control‑Theoretic Markov Diagnostic and Verify‑First Intervention — arXiv 2026‑04‑28: https://arxiv.org/abs/2604.22273