Agentní workflow na limdem.io: jak osm AI specialistů a lidský editor společně tvoří hluboké popularizační články

---

1. Proč se i nejmodernější jazykové modely potýkají s „povrchními“ texty?

„Kde končí schopnost modelu a začíná lidský zásah?“ – tato otázka rezonuje u každého, kdo se setkal s dlouhými výstupy generativních sítí, jež se chlubí „rozuměním“ světa, ale přesto sklouzávají do klišé a nejasností. Přesnost, koherence a stylistická čistota jsou často jen sliby, které se v praxi rozpadají, když model zpracovává složitější témata, jako jsou etika umělé inteligence, kvantová fyzika nebo filozofie budoucnosti.

Příkladem typické halucinace je situace, kdy model v odstavci o etice AI uvádí neexistující studii, že 70 % veřejnosti podporuje plné autonomní řízení vozidel, a přitom taková statistika nebyla nikdy publikována. Tento fiktivní údaj je snadno odhalen při faktické kontrole, ale bez takové kontroly může čtenáře uvést v omyl.

Příčina není v nedostatku výpočetního výkonu, ale v samotné architektuře: jeden velký model je nucen zvládat všechny úkoly najednou – od shromažďování faktů po psaní úvodních odstavců a kontrolu pravopisu. Tato univerzálnost vede k „kognitivnímu úzkému hrdlu“, kdy model vynakládá veškerou kapacitu na generování slov a ztrácí schopnost kriticky zhodnotit vlastní výstup.

Proto se vývojáři a redaktoři obracejí k více‑agentnímu přístupu – rozdělení úkolu mezi specializované komponenty. Myšlenka je jednoduchá: pokud má člověk v redakci editora, korektora, odborníka a designéra, proč by to neměl mít i AI? V následujících řádcích rozebíráme konkrétní implementaci tohoto principu, kterou používá limdem.io. Nejde o komerční produkt, ale o experimentální pracovní postup, jehož výsledek můžete právě nyní číst.

2. Přehled architektury: osm AI specialistů a lidský editor

„Kdo přesně tvoří řetězec, který nakonec přetvoří nápad na hotový článek?“ – v limdem.io se používá osm specializovaných agentů doplněných o jednoho lidského editora, který do procesu vnáší finální kontrolu a infrastrukturu. Každý specialista má jasně definovanou roli, podobně jako redakční tým v tradičním časopise. Níže uvádíme stručnou tabulku, která objasňuje jejich funkce:

Specialista	Název	Hlavní úkol	Klíčová výstupní forma
1	Planner	Vytvoří analytický rámec, identifikuje klíčová témata, mapuje terminologii, nastaví strukturu sekcí a vyznačí potenciální faktická rizika	Analytické uvažování (žádný text článku)
2	Proofreader (revize plánu)	Zkontroluje plán, doplní chybějící perspektivy, navrhne ověřovací dotazy, ověří terminologii	Editorská poznámka k plánu
3	Writer – první draft	Na základě plánu a poznámek napíše kompletní první verzi článku, dodržuje stylistické požadavky (zakázané anglicismy, autentický úvod, otevřený závěr)	Draft v Markdownu
4	Writer – sebekritika	Posoudí vlastní draft ze čtyř úhlů (hloubka, struktura, jazyk, faktická rizika) a vytvoří seznam prioritních úprav	Analýza draftu
5	Writer – revize	Provede cílený zásah do slabých míst, zachovává silné pasáže beze změny	Druhý draft
6	Checker A – technická fakta	Hledá nesprávná nebo neověřená technická tvrzení (čísla, názvy technologií, postupy)	Report o technických chybách
7	Checker B – logická konzistence	Identifikuje rozporuplné argumenty, chybějící logické spojky, nesoulad v dedukci	Report o logických nedostatcích
8	Checker C – terminologie a styl	Odhaluje anglicismy, doslovné překlady, nejednotnosti v pojmech, stylistická klišé	Report o jazykových nedostatcích
9	Proofreader (analýza fact-checků)	Dodává supervizorovi v následujícím kroku svůj pohled k fact-checkům	Editorská poznámka k fact-checkům
10	Supervisor	Nejvyšší autorita: vyhodnocuje všechny reporty, rozhoduje, které nálezy opraví, které odmítne, a provádí finální přepis textu	Finální verze článku
11	Translator (volitelný)	Přetvoří český text do plynulé americké angličtiny, zachovává terminologii a strukturu	Anglická verze

Kromě těchto specialistů funguje lidský editor, který zajišťuje běh infrastruktury, monitoruje stav jednotlivých úkolů a zasahuje v případě technických problémů (např. selhání API). Lidská kontrola je také nezbytná pro etické posouzení obsahu – žádný automatizovaný řetězec nedokáže zcela nahradit lidský úsudek v otázkách citlivých témat.

3. Proč potřebujeme více‑agentní přístup?

3.1 Technické limity jednoho modelu

Jedním ze zásadních problémů je halucinace (fabulace) a nedostatek kontextové konzistence. Halucinace nastává, když model vytvoří informaci, která není podložena žádným zdrojem – například neexistující statistiku nebo nesprávné datum. Nedostatek kontextové konzistence se projevuje, když se v rámci jednoho textu střídají protichůdná tvrzení nebo se opakovaně mění tón a styl.

Dalším omezením je pevně dané kontextové okno – starší nebo menší komerční LLM pracovaly s okny 8 000–32 000 tokenů; současné modely nabízejí typicky 128 000 až 200 000 tokenů, přičemž frontierové modely dosahují až milionu tokenů. I tak platí, že u rozsáhlých textů může model ztrácet koherenci — nominální délka kontextu nezaručuje efektivní využití celého okna. Při tvorbě rozsáhlých článků se tak část dříve generovaného textu může dostat mimo toto okno a model ztrácí přehled o celkové struktuře. Když se navíc požaduje, aby model současně vyhledal fakta, zformuloval argumentaci, zajistil jazykovou přesnost a přizpůsobil styl pro konkrétní cílovou skupinu, dochází k přetížení kapacity a tím i k výše zmíněným chybám.

3.2 Výhody rozdělení úkolů

Rozdělení úkolů mezi více specialistů umožňuje každému z nich soustředit se na úzký úkol, který má dobře definovaný vstup a výstup. Jeden specialista může být zodpovědný za analýzu informací, druhý za jazykovou korekturu, další za kontrolu faktů, a tak dále. Tím se snižuje riziko, že jedna komponenta vytvoří výstup, který není podložený kontrolou. Navíc lze každému specialistovi přiřadit specifické vstupní šablony a paměťové instrukce, které eliminují opakované chyby a podporují konzistentní styl.

4. Technická infrastruktura: OpenWebUI jako orchestrátor

„Jakým způsobem jsou jednotlivé AI komponenty propojeny a kde se nachází sídlo celého systému?“ – jádro workflow stojí na OpenWebUI, open‑source rozhraní, které slouží jako grafické i programové prostředí pro komunikaci s LLM (velký jazykový model/large language model) přes různé API poskytovatelů. OpenWebUI umožňuje:

1. Správu modelů a jejich vstupních šablon – uživatelé mohou v reálném čase měnit šablony, nastavit délku výstupu, teplotu a další parametry, což je klíčové pro odlišné úkoly (plánování vs. korektura).
2. Orchestrace paralelních požadavků – díky podpoře asynchronního volání lze spouštět faktické kontroly (Checker A, B, C) současně, čímž se šetří čas a efektivně využívají limity API.
3. Logování a kontextovou paměť – OpenWebUI umožňuje uchovávat historii konverzací a předávat paměťové tokeny (např. seznam false positive, který supervisor vkládá do následujících iterací).
4. Rozšíření o externí modely (open‑weight) – kromě proprietárních API lze připojit open‑weight modely (např. Llama, Mistral), což zvyšuje transparentnost a snižuje závislost na jedné platformě.

OpenWebUI také poskytuje uživatelské rozhraní pro monitorování běhu workflow – v reálném čase vidí editor, kteří specialisté jsou aktivní, kolik iterací proběhlo a jaký je aktuální stav faktické kontroly. To je nezbytné, protože celý proces je navržen jako plně automatizovaný, avšak s možností manuálního zásahu v případě výpadku nebo neočekávané chyby.

5. Vstup uživatele a cesta dat: od nápadu k plánu

„Jak se z jednoduchého tématu stane strukturovaný pracovní řetězec?“ – proces začíná uživatelským zadáním. Čtenář (nebo redaktor) napíše téma, například „Budoucnost agentních workflow v AI“, a může připojit volitelné podrobnosti oddělené speciálním oddělovačem. Tyto podrobnosti mohou zahrnovat požadovaný tón, cílovou skupinu, nutnost zahrnout konkrétní příklady nebo požadovanou délku.

Příklad takového bloku:

POŽADAVKY:

• tón: analytický
• délka: ≥ 6000 slov
• zakázat: „v konečném důsledku“, „představte si“

Všechny tyto informace jsou zabaleny do bloku s označením „závazné požadavky zadavatele“ a jsou automaticky vloženy do vstupních šablon Planneru, Writeru a Proofreadera. Tím se zajišťuje, že klíčové instrukce (např. „zakázat anglicismy“, „zachovat autentický úvod“) se neztratí v žádné fázi.

Po zadání vstupního bloku OpenWebUI spustí Planner, který vytvoří analytické uvažování. Výstup tohoto kroku slouží jako základní kostra celého textu – určuje, která témata jsou nejzajímavější, kde jsou informační mezery a jaké konkrétní terminologické výzvy mohou nastat. Následně Proofreader provede revizi plánu, doplní chybějící perspektivy a připraví editorské poznámky. Teprve až s těmito dvěma vstupy přistupuje Writer k psaní.

Tento přístup zaručuje, že každý krok má jasně definovaný vstup a výstup, a tím se eliminuje riziko, že se požadavky zadavatele „rozplynou“ v nejasném kontextu.

6. Fáze 1‑3: Příprava a první draft

6.1 Planner – analytické uvažování

„Co je jádrem přípravy a proč není plán samotným článkem?“ – Planner nevytváří žádný text, ale generuje strukturovaný rámec. V tomto kroku se provádí:

• Identifikace informačních mezer – oblasti, kde je málo publikovaných zdrojů, ale vysoký potenciál pro nový pohled.
• Mapování české terminologie – např. „trénovací data“ místo „training data“, „falešný poplach“ místo „false positive“.
• Vymezení faktických rizik – kde se pravděpodobně objeví čísla, názvy modelů nebo citace, které je třeba ověřit.
• Návrh struktury – minimálně osm sekcí, každá s jedinečnou informační hodnotou, aby se dosáhlo požadované délky (více než 6 000 slov).

Výstup je analytické uvažování – seznam bodů, ne text článku. Tento dokument slouží jako „červený plán“ pro další etapy.

6.2 Proofreader – revize plánu

„Jak zajistit, že plán není jen dobře strukturovaný, ale i fakticky spolehlivý?“ – Proofreader funguje jako první editor. Kontroluje, zda plán pokrývá všechny důležité úhly (technické, filozofické, společenské) a upozorňuje na potenciální halucinace. V případě, že je povoleno webové vyhledávání, provede rychlé ověření čísel a citací a připojí výsledky k poznámkám.

Klíčové výstupy jsou:

• Komentáře k pokrytí – doplnění chybějících perspektiv (např. etické implikace více‑agentního workflow).
• Upozornění na faktická rizika – konkrétní dotazy, které je potřeba ověřit ve fázi 4.
• Návrhy na terminologické úpravy – např. nahrazení „deep dive“ výrazem „hloubkový rozbor“.

6.3 Writer – první draft a sebekritika

„Jak se z plánu stane čitelný text a jak se následně hodnotí jeho kvalita?“ – Writer přijímá tři vstupy: plán, editorské poznámky a uživatelské zadání. Na jejich základě vytvoří první kompletní draft v Markdownu, přičemž dodržuje:

• Zakázané formulace – žádné anglicismy, žádné úvodní definice, žádné klišé typu „v konečném důsledku“.
• Autentický úvod – otázka nebo kontradikce, která čtenáře vtáhne (např. „Co když vám model řekne, že AI už dnes řídí 80 % světové energetiky, a přitom neexistuje žádná taková statistika?“).
• Závěr, který otevírá novou perspektivu – ne jen shrnutí, ale výzva k dalšímu zamyšlení.

Po dokončení draftu Writer sebekriticky hodnotí ze čtyř úhlů (hloubka, struktura, jazyk, faktická rizika) a sestaví seznam prioritních úprav (3–5 nejdůležitějších). Tento krok neprodukuje nový text, ale poskytuje konkrétní vodítka pro revizi. Posledním krokem writera je vyprodukovat opravený článek na základě svých vlastních vodítek.

7. Iterační zpětnovazebná smyčka: faktická kontrola a korekce

„Proč nestačí jedna kontrola a jak se dosahuje ‘čistého’ článku?“ – po první revizi vstupuje do hry iterativní smyčka (fáze 4‑6). Jejím cílem je postupně eliminovat všechny halucinace a jazykové nedostatky, přičemž se zachovává co nejmenší zásah do dobře fungujících částí.

7.1 Fact‑check – tři specialisté

• Checker A – technická fakta – ověřuje čísla, názvy modelů, postupy.
• Checker B – logická konzistence – zkoumá, zda argumentace nepřináší rozpory.
• Checker C – terminologie a styl – kontroluje zakázané anglicismy, doslovné překlady a stylistická klišé.

Každý checker pracuje samostatně, ale výstupy jsou strukturované (typ problému, citace, popis, navrhovaná oprava, závažnost, míra jistoty).

7.2 Proofreader – detekční krok a případná analýza fact-checků

Po získání reportů od všech tří checkerů Proofreader v prvním kroku neposuzuje správnost, ale pouze detekuje přítomnost nálezů. Pokud se objeví alespoň jeden nález vysoké nebo střední závažnosti, spustí se plná analýza výstupu fact-checkerů od proofreadera a proces přepisu od supervizora. Pokud jsou všechny nálezy nízké nebo žádné, smyčka se ukončí a text se považuje za „čistý“.

7.3 Supervisor – rozhodnutí a přepis

Supervisor je nejvyšší autoritou. Dostává dva vstupy: surové reporty checkerů a analýzu Proofreadera. Na jejich základě rozhoduje, které nálezy jsou:

• Vysoké priority – nutné opravit.
• Střední priority – opravit, pokud neohrožují strukturu.
• Nejisté – rozhodne podle vlastního úsudku.
• False positive – explicitně označí, že se neopraví.

Pro každou opravu vytvoří strukturovaný plán (lokace, popis, zdroj, rozsah zásahu). Tento plán následně použije k provedení přepisu.

7.4 Paměť false positives

Aby se zabránilo opakovanému hlášení stejných chyb, supervisor generuje sekci „FC_PAMĚŤ_NEOPRAVUJE_SE“, která obsahuje všechny zamítnuté nálezy spolu s důvody (např. „falešný poplach – akceptované zjednodušení“). Tato sekce je předávána všem checkerům od druhé iterace dál a slouží jako konkrétní instrukce, aby dané položky nehlásili znovu. Tento mechanismus výrazně snižuje počet redundantních upozornění a urychluje dosažení čistého stavu.

7.5 Ukončení smyčky

Smyčka končí buď detekčním krokem Proofreadera (žádné nálezy) nebo po dosažení maximálního počtu iterací (obvykle 10). V průběhu experimentu limdem.io dosáhl čistého stavu po čtyřech iteracích při testu na tématu etika AI. To naznačuje, že takový proces může být životaschopný.

8. Hierarchie pravomocí a ochranné mechanismy

„Proč je důležité, že supervisor má absolutní pravomoc a jaké další bariéry chrání výstup před degradací?“ – hierarchie v workflow je navržena tak, aby minimalizovala demokratické selhání – situaci, kdy by se rozhodování roztroušilo mezi příliš mnoho hlasů a vedlo k nekonzistentnímu výsledku. Supervisor, jako jediný, kdo může přepsat text, zajišťuje, že finální verze odpovídá jak zadavatelovým požadavkům, tak redakčnímu standardu.

Další ochranné prvky zahrnují:

1. Zákaz zástupných textů – v promptu je výslovně uvedeno, že výrazy jako “SEKCE_BEZE_ZMENY” jsou zakázány. Každý specialista musí zkopírovat obsah v plném znění, což vylučuje možnost „vynechat“ problematické úseky.
2. Paměť false positives – již zmíněná sekce brání opakovanému hlášení stejných položek.
3. Omezení počtu iterací – zabraňuje nekonečnému cyklu a nutí tým soustředit se na nejkritičtější problémy.
4. Transparentní logování – OpenWebUI uchovává kompletní historii promptů a odpovědí, což umožňuje audit a zpětnou analýzu.

Díky těmto principům se workflow chová jako samozavádějící redakční řetězec, který dokáže eliminovat typické slabiny autonomních LLM, aniž by ztratil lidský dohled.

9. Překlad a transkreace: z češtiny do angličtiny

„Jak se český text mění, když má dorazit k anglicky mluvícím čtenářům?“ – pokud je zapotřebí anglická verze, vstupuje do řetězce Translator. Tento specialista neprovádí doslovný překlad, ale transkreaci – přizpůsobení idiomů, rytmu a terminologie tak, aby text působil jako originál v americké angličtině.

Klíčové vlastnosti transkreace:

• Lokalizace idiomů – např. české „mít oči na stopkách“ se nahradí ekvivalentem „to keep a close eye on“.
• Udržení struktury – nadpisy, seznamy a odkazy zůstávají ve stejné hierarchii.
• Zachování technických termínů – výrazy jako “LLM”, “API” a “OpenWebUI” zůstávají, protože jsou běžně používané i v anglickém prostředí.

Stejně jako u předchozích fází je i u Translatoru zákaz zástupných textů a požadavek na plné přepsání každé sekce.

10. Lidský editor a experimentální charakter workflow

„Kde končí automatizace a kde začíná lidská odpovědnost?“ – i přes vysokou míru automatizace lidský editor zůstává nezbytnou součástí. Jeho úkoly zahrnují:

• Monitorování infrastruktury – údržba OpenWebUI, správa API klíčů, řešení výpadků.
• Etické posouzení – kontrola, zda článek neobsahuje nevhodné nebo citlivé informace, které by mohly být problematické.
• Konečná korektura – i po všech automatizovaných kontrolách editor provádí finální čtení, aby se ujistil, že text odpovídá redakčnímu stylu portálu.

Je důležité zdůraznit, že celý workflow je stále experiment. Tým Limdem.io zatím neprovedl systematické studie, které by kvantifikovaly zlepšení oproti tradičnímu psaní pomocí jediného LLM. Co však lze říci, je, že článek, který právě čtete, byl vytvořen právě tímto řetězcem; pokud se vám zdá přesný a stylisticky vyvážený, je to první praktický důkaz, že přístup funguje.

11. Co to znamená pro čtenáře? Praktické dopady a výhled do budoucna

„Jaký užitek získává čtenář z tohoto technického experimentu?“ – pro čtenáře portálu limdem.io představuje tento workflow záruku vyšší kvality. Díky:

• Hloubkovému plánování – každý článek má robustní kostru, která zaručuje, že se neztratí klíčové úhly.
• Vícenásobné faktické kontroly – pravděpodobnost, že se v textu objeví nesprávné číslo nebo neověřený citát, je výrazně snížena; výzkum v oblasti multi-agentních systémů naznačuje, že přidání nezávislých kontrolních vrstev může snižovat míru chyb — avšak konkrétní výsledky závisí na implementaci a typu obsahu.
• Jazyková čistota – zakázané anglicismy a doslovné překlady jsou systematicky odstraňovány, což vede k čistší češtině.

Každý takto publikovaný článek obsahuje footer, kde jsou uvedeny použité LLM a stručný popis workflow (Planner, Writer, Fact‑check, atd.). Tento footer slouží jako transparentní výpis pro čtenáře, kteří chtějí pochopit, jak byl text vytvořen, a případně se inspirovat k vlastnímu experimentování s AI.

Co se týče budoucnosti, lze očekávat:

• Rozšíření o další kontrolní vrstvy – například automatické citace z databází nebo rozšířená etická kontrola.
• Zavedení adaptivního počtu iterací – systém by mohl dynamicky rozhodovat, kdy je dosaženo dostatečné kvality, aniž by byl omezen pevnou hranicí deseti kol.
• Integraci s vícejazyčnými modely – umožní publikovat články ve více jazycích s jediným workflow, což je v souladu s vícejazyčnou vizí limdem.io.

12. Závěr: otevřená výzva k reflexi

„Kdyby se specialisté stali čtenáři, co by si o svém vlastním díle řekli?“ – tento dotaz nás vede k hlubší úvaze o recipročním vztahu mezi tvůrcem a publikací. V našem případě jsou specialisté nástrojem, jehož úspěšnost měříme nejen četností chyb, ale také tím, jak čtenář vnímá hloubku a přesnost argumentace.

Článek, který právě čtete, je živým důkazem – ukazuje, že rozdělení úkolů mezi osm AI specialistů a člověka může vést k textu, který má strukturu a jazykovou úroveň odpovídající náročným popularizačním standardům. Přesto zůstává otevřenou otázkou, jak daleko lze automatizaci posunout, než se setkáme s novými limity – například s etickými dilematy, kde se rozhoduje o tom, co je vhodné publikovat.

Proto vyzýváme každého čtenáře, aby nejen pasivně konzumoval obsah, ale i kriticky zkoumal proces jeho tvorby. Pokud vás zaujal styl, struktura nebo jazyková čistota, podívejte se na footer, kde najdete podrobný seznam použitých LLM a popis workflow. Vaše zpětná vazba může být dalším impulzem pro vylepšení tohoto experimentu a pro vytvoření ještě robustnějších nástrojů, které budou sloužit nejen vědecké popularizaci, ale i širšímu spektru lidské komunikace.

Zkuste si představit, že by se v budoucnu každý článek podobal této vrstvě: automatické plánování, nezávislé faktické kontroly a lidská etická brána. Kde by taková redakční struktura mohla najít uplatnění mimo internetové portály? Jaký dopad by měla na vzdělávací materiály, novinářskou praxi nebo vědecké publikace? To jsou otázky, na které se můžeme společně snažit najít odpovědi.

---

Transparentnost obsahu a AI-asistence

Jak byl tento článek vytvořen:
Tento článek byl generován s podporou umělé inteligence. Konkrétně jsme použili agentní workflow složenou z osmi jazykových modelů spuštěných v aplikaci Open WebUI. Redakce stanovila téma, výzkumný směr a primární zdroje; umělá inteligence pak vygenerovala základní strukturu a text.

Chcete se o tomto postupu dozvědět více?

Přečtěte si náš článek:
Agentní workflow na limdem.io: jak osm AI specialistů a lidský editor společně tvoří hluboké popularizační články

Redakční zpracování a ověřování:

• ✓ Text byl redakčně revidován
• ✓ Fact-checking: Všechna klíčová tvrzení a data byla ověřena
• ✓ Korekce faktů a doplnění: Redakce doplnila vlastní poznatky a opravila potenciální nepřesnosti

Omezení AI modelů (důležité varování):
Jazykové modely mohou generovat přesvědčivě znějící, ale nepřesné nebo zavádějící informace (tzv. „hallucinations“). Proto důrazně doporučujeme:

• Ověřit si kritická fakta v primárních zdrojích (oficiální dokumentace, vědecké články, autority v oboru)
• Nespoléhat se na AI obsah jako na jediný zdroj pro rozhodnutí
• Aplikovat kritické myšlení při čtení

Použité jazykové modely:

Role	Model	Licence
🧠 Planner	deepseek-ai/DeepSeek-R1	MIT Licence
🔍 Proofreader	zai-org/glm-5:thinking	MIT Licence
✍️ Writer	openai/gpt-oss-120b	Apache 2.0
🔍 Fact-checker A	deepseek/deepseek-v3.2	MIT Licence
🧠 Fact-checker B	moonshotai/kimi-k2.5:thinking	Modified MIT Licence
📝 Fact-checker C	qwen/qwen3.5-397b-a17b-thinking	Apache 2.0
👔 Supervisor	nousresearch/hermes-4-405b	Llama 3.1 Community Licence
🌍 Translator	openai/gpt-oss-120b	Apache 2.0

Zdrojový kód použité workflow:
limdemioarticlewriterprov25frontier.py