ICE v praxi: kolik iterací stačí a jak poznat, kdy zastavit

Iterace umí zlepšit odpověď. Stejně snadno z ní ale udělají průměr: uhlazený text, který nikoho neurazí a nic neriskuje.

ICE (Iterative Consensus Ensemble) je užitečné číst jako procesní rámec: více kol, více zpětné vazby (feedbacku), postupné zpřesňování. Ne jako slib, že „víc kol = víc pravdy“. Cílem je konvergence na kvalitě, ne na stylu.

Tady je praktický postup, jak ICE řídit tak, aby iterace vytvářely nové signály, ne jen další verzi stejného dojmu.

Rámec tvrzení

• Co článek tvrdí: Iterace v ICE mají hodnotu jen tehdy, když přidávají nové ověřitelné signály. Bez definice kvality, rozdělení rolí a stop podmínek konvergují k průměrnému textu. Minority report je klíčový pro zachování důležitých námitek.
• Na čem to stojí: Shinn et al. (2023) Reflexion (verbální zpětná vazba), Wu et al. (2025) multi-agentní debata, Dhuliawala et al. (2023) Chain-of-Verification, interní dokumentace ICE v CrossChat.
• Kde je to zjednodušení: Článek nenabízí empirická data o počtu iterací potřebných pro konvergenci. Stop podmínky jsou heuristické, nikoli měřitelné prahy.

1) Definuj, co je “lepší” (jinak bude konvergence jen rétorika)

Bez kritéria se iterace přirozeně sbližují v tom, co je nejbezpečnější: obecné formulace, opatrné závěry, méně konkrétnosti.

Nejdřív si napiš 2–3 kontrolní otázky:

• Co musí odpověď obsahovat, aby byla použitelná?
• Jak poznám, že je něco špatně? (kontra-příklad, test, zdroj)
• Co je cena chyby? (a tedy co musím ověřit)

Tohle je nejlepší prevence konvergence na “pěkném textu”.

2) Odděl role: generátor, kritik, kontrolor faktů, syntéza

ICE často selže, když všechny modely dělají totéž: všichni generují odpověď a pak ji kosmeticky upravují.

Role rozbijí monotónnost:

• Generátor: navrhne řešení a varianty.
• Kritik: hledá slabiny argumentu a chybějící předpoklady.
• Kontrolor faktů: vyžaduje zdroje nebo testovatelné kroky.
• Syntéza: spojí, ale nesmí vymazat neshodu.

Bez rolí je “iterace” často jen parafráze.

3) Každé kolo musí přidat nový typ signálu

Užitečná iterace není “je to lepší napsané”. Je to “přibylo něco, co můžu ověřit nebo co mění rozhodnutí”.

Příklady signálů, které mají hodnotu:

• konkrétní proti-příklad (“tady to selže”),
• explicitní kompromis (trade-off) („získáš X, ztratíš Y“),
• definice pojmů (“co přesně znamená ‘spolehlivé’”),
• testovatelný krok (“ověř v datech / v logu / v dokumentaci”),
• “co by odpověď vyvrátilo”.

Pokud se v kole nepřidal žádný signál, kolo bylo zbytečné.

4) „Minority report“ jako povinný výstup

Největší ztráta v iteracích je tichá: menšinová námitka se rozpustí v syntéze.

Zaveď povinnost:

• Na konci každého kola existuje krátký „minority report“.
• Ten report musí být přepsaný do podoby ověřitelného tvrzení nebo konkrétního rizika.

Příklad:

• Špatně: “Mám pocit, že to je risk.”
• Dobře: “Tvrzení A stojí na předpokladu B. Pokud B neplatí, návrh selže. Ověř B tímto testem.”

Minority report je palivo pro další kolo. Bez něj budete konvergovat k průměru.

5) Kdy zastavit: stop podmínky místo magického počtu iterací

Otázka “kolik kol stačí” svádí k univerzálnímu číslu. Lepší je mít stop podmínky.

Zastav, když platí většina z těchto bodů:

• Nová kola už nepřidávají nové signály (jen přepisují).
• Klíčová tvrzení jsou stabilní a mají oporu (zdroj, test, logika).
• Minority report se buď vyřešil ověřením, nebo se proměnil v jasný kompromis (trade-off).
• Víš přesně, co bys musel ověřit dál, ale to už vyžaduje externí data.

Pokud naopak iterace vytváří stále nové a konkrétní námitky, znamená to, že úloha je složitá a potřebuje ověření mimo chat.

Časté chyby

• Honit shodu místo kvality.
• Dělat kritiku jen o stylu, ne o předpokladech a testech.
• Smazat menšinu syntézou bez toho, aby se námitka proměnila v ověřitelný bod.

Rychlý přehled: ICE checklist (jedna relace)

• Definuj kritérium kvality.
• Rozdej role (generátor/kritik/fakta/syntéza).
• Vyžaduj nový signál v každém kole (test, zdroj, kontra-příklad).
• Vynucuj „minority report“.
• Používej stop podmínky (saturace signálů, stabilita tvrzení).
• Když jde o fakta, přidej ověření mimo chat.

Závěr

ICE dává smysl, když iterace nejsou “víc textu”, ale “víc kontroly”. Jakmile přestanou přibývat ověřitelné signály, další kolo už je často jen kosmetika.

Praktický závěr: Pokud chcete ICE používat systematicky, CrossChat dává smysl ve chvíli, kdy role, iterace a kontrolní kroky nejsou improvizace, ale explicitní workflow.

Zdroje

• Interní popis ICE v CrossChat: docs/WORKFLOW-TECHNIKY.md (sekce ICE)
• Shinn et al. (2023). Reflexion: Language Agents with Verbal Reinforcement Learning. arXiv:2303.11366 DOI: 10.48550/arXiv.2303.11366
• Wu et al. (2025). Can LLM Agents Really Debate? A Controlled Study of Multi-Agent Debate in Logical Reasoning. arXiv:2511.07784 DOI: 10.48550/arXiv.2511.07784
• Dhuliawala et al. (2023). Chain-of-Verification Reduces Hallucination in Large Language Models. arXiv:2309.11495 DOI: 10.48550/arXiv.2309.11495

Historie úprav

Koncept: Codex CLI + GPT-5.2 Verze 1: Codex CLI + GPT-5.2

Jazyková revize (2026-02-25, Codex + GPT-5): upraveny formulace, uvozovky a zbytečné anglicismy; metodika ICE a význam textu zachovány. Kvalitativní audit (2026-03-23, Claude Code + Claude Opus 4.6): přidán Rámec tvrzení, ověřeny zdroje, jazyková úprava.