Your Agent Aced the Task. Will It Do It Again?

Svěřili byste správu firemního účtu člověku, který úkol jednou zvládne a podruhé při stejném zadání udělá chybu? U umělé inteligence často stačí povedená demonstrace. Agent najde fakturu, připraví odpověď, zavolá správný nástroj. Potlesk. Jenže skutečná zkouška začíná až otázkou: zvládne to znovu?
Váš AI agent uspěl? Zopakujte test pětkrát, než mu svěříte peníze
Výzkumníci IBM zveřejnili 15. září 2026 nepříjemná čísla. Agent využívající GPT-4.1 dosáhl na 168 úlohách prostředí AppWorld průměrné úspěšnosti 77,4 procenta. Jenže všech pět opakování zvládl bez chyby pouze u 53 procent úloh. Rozdíl činil 24,4 procentního bodu. Test přitom používal teplotu generování nula. Výsledky IBM na Hugging Face.
Průměr tedy může schovat přesně to, co provozovatele zajímá nejvíc: kolísání výsledků při stejném zadání. Představte si účetního asistenta. Devět faktur zpracuje správně, desátou přiřadí jiné firmě. Celková úspěšnost vypadá slušně. Účetní, který chybu hledá v pátek odpoledne, bude mít jiný názor.
Agent navíc vytváří řetězec rozhodnutí. Vybere dokument, rozpozná zákazníka, přečte částku, zavolá rozhraní a vyhodnotí odpověď. Problém se může objevit v kterémkoli kroku. Správný poslední odstavec ještě nedokazuje správně provedenou práci.
Rozlišujte proto tři metriky:
| Metrika | Co skutečně měří | |---|---| | Mean@5 | Průměrnou úspěšnost pěti opakování | | Pass@5 | Podíl úloh s alespoň jedním úspěšným pokusem | | Pass^5 | Podíl úloh úspěšných ve všech pěti pokusech |
Pro návrh reklamního sloganu může stačit jeden povedený výstup. Pro zaúčtování platby potřebujete opakovanou správnost. Stejný model tak může být výborným pomocníkem v jednom procesu a drahou komplikací ve druhém. O nasazení musí rozhodovat konkrétní práce, nikoli pořadí v univerzálním žebříčku.
Vymyšlený náklad lodi a skuteční útočníci
Podle zářijové reportáže CNN, kterou shrnul Ars Technica, se americká armáda připravovala zadržet čínskou loď a vstoupit na její palubu. Podkladem byla zpráva vytvořená s pomocí AI, která chybně identifikovala náklad jako komponenty pro jaderný zbrojní program. Omyl byl odhalen před zásahem. Jde o novinářské zjištění opřené o anonymní zdroje, nikoli o zveřejněný technický rozbor systému. Ars Technica k případu čínské lodi.
Praktické poučení není omezené na armádu. Pokud model vytvoří věrohodnou zprávu a další člověk převezme její závěr bez kontroly podkladů, získá chyba úřední razítko. Formátování umí být velmi přesvědčivý kostým. Zvlášť když obsahuje tabulku.
Druhá zpráva ukazuje jinou slabinu automatizace. WIRED popsal analytika Googlu, který pronikl do vnitřního okruhu skupiny TeamPCP, spojované s útoky na softwarový dodavatelský řetězec. Reportáž WIRED o infiltraci TeamPCP.
Tyto případy nedokazují stejnou příčinu selhání. Jeden se týká chybného analytického závěru, druhý napadeného softwarového prostředí. Pro návrh agentů ale představují dva samostatné testy: rozpozná systém nedostatečné důkazy? A odolá situaci, kdy jeho nástroj nebo vstup přestane být důvěryhodný?
Agent může uvažovat správně nad podvrženými daty a přesto provést špatnou akci. Samotné vylepšování modelu proto nestačí. Potřebujete kontrolovat původ informací, oprávnění nástrojů i výsledný stav systému.
Chcete ušetřit na energiích?
Zjistěte, kolik můžete ušetřit sdílením elektřiny z FVE nebo optimalizací bateriového úložiště.
Spočítat úsporu →Test za odpoledne: třicet úloh, pět opakování
Začněte třiceti úlohami z vlastní praxe. Vyberte běžné případy, několik nejednoznačných zadání a několik situací, ve kterých má agent práci zastavit. Například fakturu bez čísla účtu, dva zákazníky stejného jména nebo neúplnou tabulku spotřeby.
Každý případ spusťte pětkrát. Dostanete 150 běhů. To je rozumný první screening, nikoli certifikát bezpečnosti. Ještě před spuštěním napište podmínku úspěchu: správný identifikátor zákazníka, přesná částka, zachované jednotky a žádná nepovolená změna.
Před každým opakováním obnovte stejný stav prostředí. Jestli první běh vytvoří objednávku a druhý ji už najde v databázi, netestujete opakovatelnost stejné úlohy. Testujete dvě rozdílné situace. Použijte kopii databáze a simulované platební či řídicí rozhraní.
Pro každý běh ukládejte zadání, verzi modelu, nastavení, volání nástrojů, jejich odpovědi, délku zpracování a cenu. Tajné klíče do záznamů nepatří. Výsledky ověřujte programově všude, kde existuje jednoznačná odpověď. Druhý jazykový model může pomoci s hodnocením textu, ale přesnou částku raději porovnejte obyčejným kódem.
Teprve potom přidejte poruchové scénáře: pomalou odpověď rozhraní, prázdný výsledek vyhledávání, duplicitní záznam nebo dokument s vloženým příkazem „ignoruj předchozí pokyny“. Sledujte také cenu neúspěchu. Pět chybných čtení a jedna neoprávněná platba nemají stejnou váhu.
Po opravě ponechte část úloh stranou jako kontrolní sadu. Jinak můžete pouze naučit agenta projít vlastní zkouškou. Výsledek bude krásný, dokud nepřijde první skutečný zákazník.
Ollama: vlastní model bez účtu za každý dotaz
Pro první místní experiment poslouží Ollama a model Qwen3 8B. Varianta `qwen3:8b` v katalogu zabírá přibližně 5,2 GB, používá kvantizaci Q4_K_M a uvádí licenci Apache 2.0. To je velikost modelového souboru, nikoli celková spotřeba paměti při provozu. Karta modelu v Ollama.
Po instalaci Ollama stáhněte model:
```bash ollama pull qwen3:8b ```
S běžícím místním serverem můžete poslat jednoduchý požadavek:
```bash curl http://localhost:11434/api/generate \ -H 'Content-Type: application/json' \ -d '{ "model": "qwen3:8b", "prompt": "Vrať JSON s klíčem castka_kc. Text: Celkem 1250 Kč.", "format": "json", "stream": false, "think": false, "options": {"temperature": 0} }' ```
Výsledný text najdete v poli `response`. Režim JSON pomáhá vynutit formát, správnost částky ale musíte ověřit zvlášť. Parametry požadavku popisuje dokumentace rozhraní Ollama.
Pro první pokus bych vyhradil počítač s 16 GB operační paměti a krátkým kontextem. Je to praktický výchozí rozpočet, nikoli garantovaný požadavek výrobce. Dlouhé dokumenty a souběžné požadavky spotřebu paměti zvednou. Grafická karta může výpočet urychlit, konkrétní rychlost však změřte na vlastních úlohách.
Tento příkaz ještě nevytváří agenta. Testuje jednu jeho součást: model. Agent vznikne až přidáním nástrojů, rozhodovací smyčky a práce se stavem.
Další otevřené modely najdete na Hugging Face. Kontrolujte licenci konkrétního modelu, původ souborů a verzi. Místní provoz dává větší kontrolu nad daty, ale správnost odpovědí si s instalací nestáhnete.
Kolik stojí spolehlivost? Počítejte i opravy
U místního provozu začněte zásuvkovým wattmetrem. Pokud sestava při testování odebírá průměrně 120 W a běží čtyři hodiny denně, za třicet dní spotřebuje 14,4 kWh. Při modelové ceně 6 Kč/kWh vychází elektřina na 86,40 Kč měsíčně. Jde o ilustrativní výpočet, nikoli nabídku dodavatele nebo změřenou spotřebu konkrétního počítače.
Stejná sestava při nepřetržitém průměrném odběru 120 W spotřebuje 86,4 kWh měsíčně. Účet už činí 518,40 Kč. Přidejte pořízení hardwaru, servis a svůj čas. „Model zdarma“ je licenční údaj, nikoli provozní rozpočet.
U placeného rozhraní počítejte vstupní i výstupní tokeny každého kroku. Pokud celá úloha spotřebuje 8 000 vstupních a 2 000 výstupních tokenů, při čistě ilustrativních sazbách 25 a 100 Kč za milion tokenů stojí 0,40 Kč. Sto padesát takových běhů vyjde na 60 Kč. Vyhledávání, další nástroje a opakované pokusy mohou účet zvýšit.
Rozhodující ukazatel je cena správně dokončené úlohy. Zahrňte do ní také lidskou kontrolu a opravu chyb. Levnější model, po kterém zaměstnanec deset minut uklízí, nemusí být levnější řešení.
Energetickou stránku AI rozebírá také zpráva Mezinárodní energetické agentury. Pro domácí rozhodnutí však začněte vlastním měřením. Celosvětová prognóza vám neřekne, zda se vyplatí nechat pracovní stanici běžet přes noc.
AI u baterie: nejdražší chyba může mít správný JSON
Energetika je pro agenty lákavá. Nabízí ceny, předpovědi, měření a opakované rozhodování. Jenže právě zde může drobná chyba změnit skutečný tok peněz nebo elektřiny.
OTE oznámil spuštění patnáctiminutového obchodování na propojeném denním trhu 30. září 2025, pro dodávku od 1. října. Běžný den tak představuje 96 čtvrthodinových intervalů. Při změně času jich může být 92 nebo 100. Informace OTE o přechodu.
Představte si vlastní prototyp asistenta pro baterii. Dostane ceny, stav nabití a očekávanou spotřebu. Má navrhnout plán. Kontrolní program musí ověřit časová pásma, úplnost dat, výkonové limity a jednotky. Záměna MWh za kWh znamená tisícinásobný rozdíl. Bezchybná syntaxe JSON tomu nijak nebrání.
Pro orientaci v souvisejících službách nabízí platforma SmartEnergyShare stránky věnované [spotovým cenám elektřiny](https://smartenergyshare.com/spotova-cena-elektriny-denni-trh?utm_source=share-electric&utm_medium=referral&utm_campaign=satellite-marketing), [IoT monitoringu](https://smartenergyshare.com/iot-monitoring?utm_source=share-electric&utm_medium=referral&utm_campaign=satellite-marketing) a [obchodování flexibility](https://smartenergyshare.com/obchodovani-flexibility?utm_source=share-electric&utm_medium=referral&utm_campaign=satellite-marketing). Popsaný prototyp je návrh architektury, nikoli tvrzení o konkrétní implementaci této platformy.
V takovém návrhu bych jazykovému modelu svěřil vysvětlení plánu a rozpoznání nejasností. Výpočet harmonogramu a vynucení limitů by obstaral samostatný program. Při výpadku dat musí existovat předem stanovený náhradní režim.
Další energetický kontext nabízejí SmartEnergyShare.info a SmartEnergyShare.cz. Při hodnocení úspor ale vždy porovnávejte stejné období, tarif a podmínky provozu. Povedený slunečný den ještě nedokazuje přínos algoritmu.
Lepší instrukce pomohou. Oprávnění rozhodnou
IBM zkusilo nestabilní rozhodování omezit pomocí systému ALTK-Evolve. Ten z průběhů úloh odvozuje opakovaně použitelné instrukce. V popsaném experimentu vzrostl podíl úloh úspěšných ve všech pěti bězích z 53 na 69 procent a průměrná úspěšnost z 77,4 na 81 procent. Je to zlepšení v konkrétním testu, ne univerzální záruka. Metodika a výsledky IBM.
Další možností je LoRA. Místo úpravy všech vah modelu se trénují menší adaptační matice. Postup podporuje knihovna PEFT od Hugging Face. Může pomoci přizpůsobit model určitému typu úloh, ale sám neověřuje pravdivost vstupů ani správnost vykonaných akcí. Dokumentace LoRA.
Před trénováním bych proto opravil rozhraní nástrojů. Agent potřebuje jednoznačné parametry, srozumitelné chyby a omezená oprávnění. Nástroj pro čtení faktur nemá současně umožňovat změnu bankovního účtu. Opakování požadavku po výpadku nesmí vytvořit druhou platbu; tomu pomáhá jedinečný identifikátor operace a kontrola jejího stavu.
Nasazení začněte režimem návrhů. Porovnávejte doporučení s výsledkem běžného procesu. Samostatné provádění povolujte postupně podle naměřených chyb a jejich dopadů. Po změně modelu, instrukcí nebo nástrojů zopakujte kontrolní sadu.
Ještě tento týden vezměte deset úloh, které váš agent údajně umí, a spusťte každou pětkrát. Zapisujte chyby i čas oprav. Moje předpověď? Nejlepší agenti budou brzy působit trochu nudně. Stejnou práci totiž dokončí správně i bez publika.
Zdroje
Následující výběr propojuje původní experiment, technickou dokumentaci a energetický kontext. Reportáže o bezpečnostních incidentech jsou odkazované přímo u příslušných tvrzení. Při vlastním nasazení sledujte také datum dokumentace a verzi testovaného systému; výsledky jednoho experimentu nelze automaticky přenést na jiného agenta.
- IBM Research: opakovatelnost výsledků agentů — Primární podklad pro uvedená procenta, rozlišení hodnoticích metrik a výsledky ALTK-Evolve. Popisuje konkrétní experimentální prostředí, které je nutné zohlednit při interpretaci závěrů.
- Ollama: rozhraní pro generování odpovědí — Technická reference k ukázkovému požadavku, strukturovanému výstupu a vraceným údajům. Hodí se při stavbě vlastního měření délky zpracování a spotřebovaných tokenů.
- Hugging Face: princip a použití LoRA — Dokumentace úsporného přizpůsobování modelů pomocí adaptačních matic. Vysvětluje techniku trénování; neslouží jako důkaz spolehlivosti konkrétního modelu v produkčním provozu.
- OTE: úspěšné zavedení patnáctiminutového obchodního intervalu — Český primární zdroj potvrzující změnu denního trhu. Pro energetické aplikace představuje podklad k práci s časovým rozlišením cenových dat.
- IEA: energetika a umělá inteligence — Mezinárodní zpráva věnovaná energetickým nárokům AI a možnostem jejího využití v energetice. Poskytuje širší souvislosti pro hodnocení provozních nákladů a přínosů automatizace.
Obchodujete s batteriovými úložišti nebo hledáte partnera pro flexibilitu a day trading elektřiny? SmartEnergyShare nabízí kompletní řešení pro BESS projekty od 50 do 250 kW — obchodování flexibility, SVR služby a IoT monitoring. Zjistěte víc →
Další články na toto téma najdete na: SmartEnergyShare.info Příklad výstupu EMO monitoring sidecar Vice o deploy local