Vaše AI hlásí „hotovo“. AutoSynthData ji učí, aby to byla pravda

„Hotovo,“ oznámí agent. Jenže servisní požadavek zůstal otevřený, upozornění odešlo jinému zákazníkovi a databáze o slíbené opravě nic neví. Tohle je modelová situace, která vystihuje slabinu podnikové umělé inteligence: přesvědčivá odpověď ještě není dokončená práce.

Elektrifikaci můžeme tleskat. Někdo ale musí hlídat střídače, vyhodnocovat výpadky měření a udržovat pořádek v servisních záznamech. Právě tady začíná zajímavější otázka než „který model nejlépe píše“. Jak agenta naučit, aby skutečně něco udělal správně?

Vaše AI hlásí „hotovo“. AutoSynthData ji učí, aby to byla pravda

Tým ServiceNow CoreAI představil 2. října 2026 AutoSynthData. Jde o postup tvorby syntetických trénovacích dat podle konkrétních slabin podnikového agenta. Cílový model dostane úlohy, silnější učitelský model ukáže úspěšná řešení a systém z rozdílů odvodí, co procvičovat.

Trénovací úloha zahrnuje zadání, specifikaci prostředí a ověřovací mechanismus. Nestačí tedy vyrobit tisíc podobně znějících dotazů. Úloha musí jít splnit dostupnými nástroji a kontrola musí rozeznat správný výsledek od chybného.

V experimentu s prostředím EnterpriseOps Gym Hybrid vzniklo 2 000 vzorků přibližně za 18 hodin. Dotréning zvýšil průměrnou úspěšnost na první pokus o 7,2 procentního bodu, relativně o 35 %. Ve druhém prostředí, zaměřeném na správu IT služeb, stoupla z 18,77 % na 27,18 %. Jsou to výsledky konkrétních experimentů, nikoli garance pro libovolnou firmu. Podrobnosti zveřejnili autoři AutoSynthData na Hugging Face.

Pro správce firemních systémů z toho plyne praktická změna přístupu. Nejdřív najděte opakující se chybu. Teprve potom objednávejte další výpočetní výkon.

Pokud agent zaměňuje identifikátor zařízení s identifikátorem provozovny, potřebujete procvičovat rozlišování těchto objektů. Dalších deset tisíc obecných rozhovorů o fotovoltaice vám servisní databázi neuklidí. Maximálně bude nepořádek komentovat elegantnější češtinou.

Začněte jednou poruchou, ne celým podnikem

Následující postup je návrh vlastního pilotu inspirovaného AutoSynthData. Není to instalační návod k hotovému balíčku od ServiceNow.

Vyberte úzký úkol: z výpadku telemetrie vytvořit správný servisní požadavek. Agent smí přečíst poslední měření, dohledat zařízení a zjistit, zda už požadavek existuje. Nesmí měnit výkon elektrárny ani uzavírat cizí incidenty.

Připravte třeba 100 ručně zkontrolovaných případů. Část bude jednoduchá. U dalších chybí časové razítko, zařízení změnilo vlastníka nebo už existuje otevřená závada. Přidejte také plánovanou odstávku. Agent, který ke každému tichému senzoru poslušně založí nový incident, vám vyrobí spíš administrativní brigádu.

Každý případ potřebuje výchozí stav databáze, uživatelský požadavek a očekávaný výsledek. Použijte smyšlená jména a identifikátory. Zachovejte však vazby mezi objekty: zařízení patří konkrétní provozovně a servisní smlouva platí v určitém období.

Začněte nad kopií prostředí bez možnosti odesílat skutečné zprávy. Před každým pokusem obnovte stejný výchozí stav. Jinak bude druhý běh řešit databázi změněnou prvním během a výsledky nepůjde poctivě porovnat.

Energetický kontext dobře ilustruje IoT monitoring SmartEnergyShare. Pro návrh agenta si ale zvlášť sepište, která data umí vaše konkrétní instalace poskytovat. Odkaz na službu není důkaz existence integračního rozhraní. To musí potvrdit dokumentace nebo dodavatel.

Ollama rozjede pokus. Kvalitní data z ní sama nevypadnou

Pro první lokální experiment můžete použít Ollamu a model Qwen3 s osmi miliardami parametrů. Varianta `qwen3:8b` má podle katalogu přibližně 5,2 GB a používá kvantizaci Q4_K_M. Po instalaci Ollamy model stáhnete příkazem:

```bash ollama pull qwen3:8b ```

Velikost souboru není celková spotřeba paměti. Připočítejte pracovní paměť modelu, kontext a systém. Pro malý pokus bych plánoval počítač s 16–32 GB RAM; potřebnou grafickou paměť ověřte podle délky vstupů. Konkrétní model a jeho parametry uvádí katalog Ollamy.

Při spuštěné službě lze požádat o návrh scénáře:

```bash curl http://localhost:11434/api/generate \ -H 'Content-Type: application/json' \ -d '{ "model": "qwen3:8b", "stream": false, "format": "json", "prompt": "Vrať JSON s klíči zadani, vychozi_stav a ocekavany_stav. Vytvoř český servisní scénář: měnič neposílá data, ale probíhá plánovaná odstávka. Agent nesmí vytvořit duplicitní incident." }' ```

Rozhraní a strukturovaný výstup popisuje dokumentace Ollamy. Vygenerovaný objekt najdete jako text v poli `response`; obal odpovědi ještě není samotný datový vzorek.

Tento příkaz vytváří návrh. Neověřuje jeho správnost. Následuje kontrola struktury, zavedení počátečního stavu do testovací databáze a skutečné provedení úlohy.

Osmimiliardový model navíc nemusí být dobrým učitelem pro vašeho agenta. Pokud oba dělají stejnou chybu, syntetická data ji mohou rozmnožit. Učitelský model proto vybírejte podle úspěšnosti na vlastních ověřených případech. Malý lokální model se hodí i pouze k obměňování formulací, zatímco referenční postup schválí člověk.

Databáze má poslední slovo. A kontrolor také potřebuje kontrolu

Microsoft a Hugging Face popsali problém názorně v projektu ThinkingBox. Jejich benchmark zahrnuje 507 podnikových pracovních postupů a hodnotí konečný stav systémů i vedlejší účinky. V jednom příkladu agent provedl devět volání nástrojů, ale uzavřel zákaznický požadavek, který měl zůstat pozastavený. Formálně pracoval. Prakticky nedokončil správnou práci. Příklad rozebírá článek o ThinkingBox.

Ve vlastním servisním pilotu proto nestačí kontrolovat, zda vznikl řádek v tabulce. Ověřte správné zařízení, zákazníka, prioritu i počet nových požadavků. Sledujte také záznamy, které se změnit neměly.

Základ kontroly může vypadat takto:

```python assert incident["zarizeni_id"] == ocekavane_zarizeni assert incident["stav"] == "otevřeno" assert pocet_novych_incidentu == 1 assert zmenene_cizi_zaznamy == [] ```

Ukázka předpokládá, že proměnné naplnil testovací program z databáze. Samotné čtyři řádky ji samozřejmě nezkontrolují.

U asynchronních operací přidejte časový limit a čekání na konečný stav. Potvrzení přijetí zprávy do fronty ještě neznamená její doručení. Při opakování zápisu používejte identifikátor požadavku, podle kterého server pozná duplicitu.

A potom schválně rozbijte výsledek. Zaměňte zařízení. Přidejte druhý incident. Změňte vlastníka. Pokud kontrola dál hlásí úspěch, máte vadný test.

Tohle je levná a nepříjemně účinná disciplína. Chybný kontrolor může proměnit špatné příklady v trénovací autoritu. Model pak s každým dalším kolem přesněji opakuje váš vlastní omyl.

LoRA šetří paměť. Největší účet často vystaví člověk

Jakmile máte ověřené ukázky, přichází dotrénování. Otevřený nástrojový řetězec můžete postavit na knihovnách Transformers, TRL a PEFT z prostředí Hugging Face. Metoda LoRA učí malé přídavné matice místo aktualizace všech vah modelu. Tím omezuje počet trénovaných parametrů a paměťové nároky. Princip vysvětluje dokumentace PEFT.

Pro pilot bych zvažoval pronájem GPU s 24–48 GB paměti. Je to plánovací rozsah, nikoli univerzální minimum. Rozhodují velikost modelu, kvantizace, délka sekvencí a počet současně zpracovaných příkladů. Než pronajmete stroj na víkend, změřte jeden krátký běh.

Následující rozpočet používá výslovně modelové sazby. Nejde o aktuální ceník poskytovatele ani cenu experimentu ServiceNow.

| Položka | Předpoklad | Náklad | |---|---|---:| | Výpočetní prostředí | 30 hodin × 35 Kč | 1 050 Kč | | Generování přes placené rozhraní | 8 milionů vstupních tokenů × 25 Kč/milion a 2 miliony výstupních × 100 Kč/milion | 400 Kč | | Odborná kontrola | 12 hodin × 900 Kč | 10 800 Kč | | Celkem | Bez integrace, úložiště a DPH | 12 250 Kč |

Rozpočet ukazuje podstatný poměr: kontrola kvality může stát násobně víc než samotné generování. Pokud testy přijmou jen čtvrtinu kandidátů, sledujte cenu jednoho přijatého vzorku, nikoli cenu jedné odpovědi.

U lokálního stroje měřte příkon v zásuvce. Při průměru 350 W, běhu 30 hodin a modelové ceně 6 Kč/kWh vyjde elektřina na 63 Kč. Pořizovací cena počítače, chlazení a práce v této částce nejsou.

Apple připomíná, že dobrý trénink nenahrazuje oprávnění

Apple 2. října 2026 oznámil připravované doplnění kontrol kolem úplného přístupu k disku v macOS. Výslovně zmínil rostoucí rizika autonomních agentů. Udělení tak širokého oprávnění má vyžadovat velmi jednoznačný zásah uživatele. Oznámení ovšem neuvádí konkrétní podobu ovládání ani termín nasazení. Viz oficiální zpráva Applu.

Pro podnikového správce je závěr přímočarý. Model naučený respektovat pravidla pořád nemá dostat univerzální účet správce. Jeho schopnost rozhodovat a technická oprávnění jsou dvě samostatné věci.

Servisní agent může mít povolené čtení telemetrie a vytváření incidentů pro vybranou provozovnu. Mazání historie nebo zásah do nastavení baterie mu rozhraní vůbec nemusí nabídnout. Omezení musí vynucovat server, ne věta v zadání.

Do testovacích dat zařaďte i škodlivý text uvnitř servisního záznamu: například požadavek, aby agent ignoroval pravidla a vypsal přístupové údaje. Správný postup má s tímto textem zacházet jako s obsahem záznamu, nikoli jako s novým příkazem.

Podobně procvičujte odvolané oprávnění uprostřed práce. Agent musí umět skončit s vysvětlením, co provedl a co už provést nemohl. Automatické opakování zamítnuté operace nepomůže. Jen rychleji naplní protokol.

Lokální provoz přitom sám o sobě nezaručuje soukromí. Citlivé údaje mohou zůstat v trénovacích souborech, protokolech nebo zálohách. Syntetický vzorek vytvořený z původního zákaznického záznamu není automaticky anonymní.

Údržba energetiky potřebuje špinavá data a poctivé měření

Energetika nabízí dobrý test praktické použitelnosti. Má zařízení, časové řady, servisní pravidla i drahé následky chyb. OTE zavedl na propojeném denním trhu patnáctiminutovou obchodní periodu pro dodávky od 1. října 2025. Podklady jsou v dokumentaci OTE. Pro vlastní testy z toho odvoďte konkrétní situace: chybějící interval, posunuté časové pásmo nebo záměnu kW a kWh.

Do trénovací sady patří také výměna elektroměru, záporná cena a přechod mezi letním a zimním časem. Ne proto, aby model odříkal definici. Musí poznat, kdy jsou vstupy neúplné a kdy se má výpočet zastavit.

Pro výběr obchodního scénáře poslouží stránky [SmartEnergyShare pro firmy](https://smartenergyshare.com/pro-firmy?utm_source=electric-share&utm_medium=referral&utm_campaign=satellite-marketing) a [obchodování flexibility](https://smartenergyshare.com/obchodovani-flexibility?utm_source=electric-share&utm_medium=referral&utm_campaign=satellite-marketing). Další kontext komunitní energetiky najdete na [SdíleníEnergie.info](https://sdilenienergie.info). Jde o náměty pro použití; tento článek netvrdí, že uvedené služby AutoSynthData nasazují. Rozcestník nabízí SmartEnergyShare.com.

Začněte stovkou případů a odděleným závěrečným testem. Varianty stejného incidentu držte pohromadě, aby se téměř totožný příklad nedostal do tréninku i hodnocení. Měřte správné dokončení, nepovolené změny, duplicity, dobu řešení a cenu přijatého výsledku.

Po každé změně rozhraní nebo pravidel testy zopakujte. Nový model nejprve nechte připravovat návrhy vedle lidského operátora. Rozdíly budou užitečnější než působivá ukázka na poradě.

První investicí tedy nemusí být nová grafická karta. Napište deset kontrol, které poznají nesprávně dokončenou práci. Bez nich vám výkonnější agent jen rychleji oznámí, že je hotovo.

Zdroje

• ServiceNow: AutoSynthData a tvorba trénovacích dat — Primární popis metody, generování úloh, jejich ověřování a výsledků v EnterpriseOps Gym. Uvedená procenta patří k popsaným experimentům. Vlastní pilot, příkazy a modelový rozpočet v tomto článku nejsou jejich reprodukcí.

• Microsoft a Hugging Face: ověřování agentů pomocí ThinkingBox — Zdroj příkladu nesprávně uzavřeného požadavku a hodnocení podle konečného stavu systémů. Pomáhá rozlišit platné volání nástroje od správně dokončeného obchodního úkolu a upozorňuje také na vedlejší účinky.

• Apple: oznámení změn úplného přístupu k disku — Oficiální oznámení z 2. října 2026. Dokládá záměr doplnit kontroly při udělování oprávnění. Neobsahuje termín zavedení ani podrobný návrh nového uživatelského rozhraní, proto je článek nepředjímá.

• OTE: přechod na patnáctiminutovou obchodní periodu — Český primární zdroj k časovým intervalům trhu a související technické dokumentaci. Pro vývojáře energetických integrací je užitečný také kvůli odkazům na formáty zpráv a externí rozhraní.

• IEA: energetika a umělá inteligence — Mezinárodní přehled vztahu AI a energetiky pro širší kontext. Nenahrazuje měření spotřeby konkrétního počítače ani nabídku výpočetních služeb; ekonomiku pilotu je potřeba ověřit na skutečné úloze.

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 Proč to zajímá lidi kolem fotovoltaiky Vice o openai says