Jak použít více AI modelů jako peer reviewery vlastního textu nebo kódu

AI reviewer umí být užitečný. Stejně snadno ale vrátí komentáře, které jen opakují vaše slepé skvrny.

To je hlavní důvod, proč jeden model často nestačí. Ne proto, že by byl nutně slabý, ale protože dostane příliš široké zadání: má být kritik logiky, kontrolor faktů (fact-checker), stylistický editor i tester okrajových případů (edge cases) najednou. Výsledek pak bývá uhlazený seznam poznámek bez jasné priority.

Vícemodelové peer review dává smysl ve chvíli, kdy rozdělíte revizní práci na role. Cílem není více textu v komentářích. Cílem je lepší signál.

Rámec tvrzení

Co článek tvrdí: Jeden AI model jako reviewer nestačí, protože dostane příliš široký úkol. Rozdělení review na kritéria a role zvyšuje kvalitu připomínek. Dvoukolový proces s editorskou syntézou je účinnější než paralelní review bez struktury.

Na čem to stojí: Heuer (1999) kognitivní analýza, Kahneman, Sibony & Sunstein (2021) Noise (šum v lidském úsudku), Du et al. (2023) multi-agentní debata, Dhuliawala et al. (2023) Chain-of-Verification.

Kde je to zjednodušení: Článek nepředkládá empirická srovnání jednomodelového vs. vícemodelového review. Doporučený dvoukolový proces je heuristika, ne validovaný standard.

Kdy tenhle postup použít

Tenhle workflow se hodí hlavně tehdy, když:

výstup má být publikovaný nebo sdílený dál,
chyba je dražší než několik minut navíc,
potřebujete odlišit věcné problémy od stylistických,
chcete opakovatelný revizní proces pro další texty nebo commity.

Naopak pro rychlý draft nebo interní poznámku může být celý proces zbytečně těžký. V takovém případě je často lepší jeden model plus rychlá lidská kontrola.

Co se naučíte

Jak rozdělit review na kritéria místo generického „zkontroluj to“
Jak přiřadit role reviewerů pro text i kód
Jak vést review ve dvou kolech, aby připomínky nebyly redundantní
Jak syntetizovat konfliktní komentáře bez hlasování

Krok 1: Rozdělte review na kritéria, ne na "další názor"

Nejčastější chyba v AI peer review je jednoduchá: požádáte dva nebo tři modely o totéž. Dostanete podobné komentáře, jen jinými slovy.

Lepší přístup je rozdělit review podle kritérií.

U textu typicky chcete oddělit:

argumentační logiku,
faktickou přesnost a práci se zdroji,
čitelnost a strukturu,
tón a vhodnost pro publikum.

U kódu dává smysl oddělit:

správnost (correctness),
bezpečnost,
udržovatelnost (maintainability),
okrajové případy (edge cases) a chování při chybě.

Tady se vyplatí vynutit formát připomínky:

problém,
dopad,
návrh opravy.

Bez tohoto formátu reviewer často píše dojmologii. S formátem dostanete komentáře, které se dají prioritizovat a skutečně zapracovat.

Praktická pointa: nepřidávejte model, dokud neumíte rozdělit kritéria. Jinak jen násobíte šum.

Krok 2: Nastavte role reviewerů a výstupní formát

Jakmile máte kritéria, převeďte je do rolí. Role by měly být rozdílné strukturou, ne jen tónem.

Špatně: "Reviewer 1: zkontroluj text. Reviewer 2: zkontroluj text kriticky."

Lépe:

Reviewer A: logika argumentu, hledej skoky v závěrech a nejasné předpoklady
Reviewer B: faktická přesnost, označ body k ověření a nepodložená tvrzení
Reviewer C: čitelnost a struktura, navrhni změny bez zásahu do významu

U kódu může být role mapování podobně konkrétní:

Reviewer A: správnost (correctness) a způsoby selhání (failure modes)
Reviewer B: bezpečnost a zneužitelné vstupy
Reviewer C: udržovatelnost (maintainability), názvy, rozhraní a čitelnost

Každé roli dejte i zákaz:

nepřepisuj celý text,
nehodnoť styl, pokud máš řešit correctness,
neřeš výkon, pokud máš řešit bezpečnost.

Tohle omezení je důležité. Jinak role utečou k obecnému hodnocení a ztratíte benefit specializace.

Krok 3: Použijte dvoukolový proces místo paralelního chaosu

Paralelní review je lákavé, protože je rychlé. Problém je, že autor pak dostane směs připomínek různé závažnosti a často začne opravovat kosmetiku dřív než věcné chyby.

Ve většině případů funguje lépe dvoukolový proces.

1. kolo: high-impact problémy

První kolo má chytit to, co může zneplatnit výstup:

chybnou logiku,
nepodložené tvrzení,
bezpečnostní problém,
špatný předpoklad,
rozbitý edge case.

V tomto kole neřešte styl, pokud nebrání porozumění.

Mezikrok: autor opraví jen priority

Po prvním kole autor zapracuje pouze kritické a důležité připomínky. Cílem není finální polish. Cílem je stabilní verze, kterou má smysl dál ladit.

2. kolo: čitelnost, konzistence, detail

Druhé kolo se soustředí na:

naming a terminologii,
strukturu odstavců nebo funkcí,
duplicity,
čitelnost a konzistenci.

Tento sled brání častému problému: stylistický reviewer přepisuje část, která se stejně bude měnit kvůli věcné opravě.

Třetí kolo přidávejte jen výjimečně. Pokud ho potřebujete pravidelně, bývá problém v zadání rolí nebo v syntéze připomínek.

Krok 4: Syntetizujte konfliktní připomínky jako editor

Jakmile máte více reviewerů, konflikt komentářů je normální. Jeden chce text zkrátit, druhý doplnit kontext. Jeden chce abstrakci, druhý explicitní okrajové případy (edge cases).

To není chyba workflow. To je signál, že role opravdu přinesly odlišný pohled.

Chyba je řešit to hlasováním.

Peer review není volba většiny. Je to editorská syntéza podle cíle výstupu:

Kdo je publikum?
Jaký je účel dokumentu?
Co je dražší chyba: nejasnost, nebo délka?
Který komentář chrání high-impact riziko?

Pomáhá jednoduchý editorial log:

připomínka,
rozhodnutí (přijmout / odmítnout / odložit),
důvod.

Tento log má dvě výhody. Zaprvé zkrátí další debatu nad stejným typem komentářů. Zadruhé zlepšuje konzistenci napříč dalšími texty nebo commity.

Právě tady má člověk největší hodnotu. Modely generují připomínky. Člověk drží kontext, účel a odpovědnost za finální verzi.

Krok 5: Nastavte stop condition a eskalaci na člověka

Bez konce se revizní proces snadno změní na nekonečné přepisování.

Praktická stop condition může být jednoduchá:

nové kolo nepřineslo žádný nový high-impact problém,
většina změn je už kosmetická,
konflikty se týkají preferencí, ne correctness nebo rizika.

Zároveň si předem řekněte, kdy AI review nestačí a je čas na člověka:

právní nebo compliance otázka,
produkční bezpečnostní změna,
veřejný text s reputačním dopadem,
doménový detail, který nelze rychle ověřit.

AI peer review má být filtr a akcelerátor, ne náhrada odpovědné odborné revize.

Mini šablona: jak zadat role reviewerů prakticky

Velká část kvality AI peer review stojí na tom, jak přesně zadáte role. Není nutné psát dlouhé prompty. Důležité je, aby byly srovnatelné.

Praktická šablona pro každého reviewera může mít pět částí:

Role: co přesně kontroluješ
Cíl: co má výstup pomoci rozhodnout
Zakázané chování: co nemáš hodnotit
Formát: problém -> dopad -> návrh
Priorita: kritické / důležité / kosmetické

Například u textu: "Jsi reviewer argumentační logiky. Hledej skryté předpoklady, skoky v závěru a slabé definice. Nehodnoť stylistiku. Vrať připomínky ve formátu problém -> dopad -> návrh a u každé označ prioritu."

U kódu: "Jsi reviewer correctness a failure modes. Hledej situace, kde funkce vrací chybný výsledek, selže na edge case nebo poruší očekávaný kontrakt. Neřeš naming ani formátování."

Tahle úroveň konkrétnosti obvykle stačí, aby role přestaly splývat.

Jak vypadá dobrá syntéza konfliktu připomínek

Typický konflikt v textu:

reviewer A chce text zkrátit kvůli rytmu,
reviewer B chce doplnit kontext kvůli přesnosti.

Špatná reakce je přepsat odstavec dvakrát a doufat, že se problém ztratí.

Lepší postup:

Vraťte se k cíli textu (např. vysvětlit princip začátečníkovi).
Označte, která část je povinná pro přesnost a která je jen doplňující.
Zachovejte přesnost v hlavním textu a doplňující kontext zkraťte nebo přesuňte.

U kódu je to podobné: bezpečnostní reviewer může chtít explicitní validaci vstupu, zatímco maintainer reviewer navrhuje zjednodušení rozhraní. Syntéza není kompromis "napůl". Syntéza je rozhodnutí, které chrání dražší failure mode a teprve pak optimalizuje čitelnost.

Právě proto se vyplatí udržet v procesu lidského editora nebo autora jako final decision maker.

Provozní tip: logujte opakující se typy připomínek

Pokud peer review děláte opakovaně, založte si krátký log opakujících se chyb. Nemusí být složitý. Stačí tabulka:

typ chyby,
kde vznikla,
kdo ji zachytil,
jaká úprava procesu by jí příště předešla.

Po několika bězích často zjistíte, že problém není v kvalitě reviewerů, ale v šabloně zadání nebo v tom, že autor vynechává stejný krok. Přesně tady se z peer review stává zlepšování procesu, ne jen opravování jednotlivých výstupů. Takový log je užitečný i při zaškolování dalších lidí do stejného review workflow a při ladění rolí v čase napříč projekty i týmy interně.

Časté chyby

Všichni revieweři dostanou stejné zadání a vrátí stejné komentáře.
Autor opravuje všechno najednou bez priorit.
Konflikty připomínek se řeší hlasováním místo návratu k cíli dokumentu.
Review se spouští po každé drobné změně a režie převálcuje přínos.
Reviewer role nemají předepsaný formát výstupu, takže komentáře nejdou srovnat.

Rychlý přehled

Rozděl review na kritéria (logika, fakta, styl, edge cases).
Každému reviewerovi dej jinou roli a zákaz "dělat všechno".
V 1. kole řeš high-impact chyby.
Ve 2. kole řeš čitelnost a konzistenci.
Konflikty připomínek syntetizuj podle cíle dokumentu.
Zastav review, když nové kolo nepřidává high-impact signál.

Závěr

AI peer review funguje nejlépe jako strukturovaný proces, ne jako jednorázový dotaz "zkontroluj mi to".

Jakmile oddělíte role reviewerů, nastavíte priority a ponecháte syntézu editorovi, kvalita review obvykle stoupne rychleji než při přidávání dalších a dalších modelů bez procesu.

V CrossChat můžete stejné role rozdělit mezi modely v jednom workflow. Stejná metodika ale funguje i ručně, pokud držíte disciplínu kol, priorit a jasného konce review.

Zdroje

Heuer, R. J. (1999). Psychology of Intelligence Analysis. CIA Center for the Study of Intelligence. https://www.cia.gov/resources/csi/books-and-monographs/psychology-of-intelligence-analysis-2/
Kahneman, D., Sibony, O., Sunstein, C. R. (2021). Noise: A Flaw in Human Judgment. Little, Brown Spark. ISBN: 978-0316451406.
Du, Y. et al. (2023). Improving Factuality and Reasoning in Language Models through Multiagent Debate. arXiv:2305.14325. DOI: 10.48550/arXiv.2305.14325.
Dhuliawala, S. 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 + GPT-5.2 Verze 1: Codex + GPT-5.2

Jazyková revize (2026-02-25, Codex + GPT-5): zlepšena stylistika, sjednocena terminologie a omezeny zbytečné anglicismy; workflow peer review zůstává zachováno. Kvalitativní audit (2026-03-23, Claude Code + Claude Opus 4.6): přidán Rámec tvrzení, ověřeny zdroje, jazyková úprava.