AI hlásí hotovo. Tenhle test odhalí, jestli vám právě rozbíjí databázi

„Hotovo, problém je vyřešený.“ Jenže zásilka pořád visí u dopravce a zákaznický požadavek je předčasně uzavřený. Agent provedl devět volání nástrojů. Na pohled pracoval pečlivě. Výsledkem byl nesprávný stav v databázi.

Takový případ popisují Microsoft a Hugging Face v benchmarku ThinkingBox. Jde o syntetický scénář, nikoli zveřejněnou reklamaci skutečného zákazníka. Přesto trefuje slabinu podnikové automatizace přesně: přesvědčivá zpráva o dokončení není důkaz dokončené práce. Popis benchmarku ThinkingBox.

Pro správce systémů začíná nová disciplína údržby. Vedle dostupnosti serveru musí hlídat, zda digitální zaměstnanec skutečně udělal to, co tvrdí. A zda přitom omylem nepřestavěl půl kanceláře.

AI hlásí hotovo. Tenhle test odhalí, jestli vám právě rozbíjí databázi

ThinkingBox pracuje s 507 podnikovými scénáři. Každý se opakuje dvacetkrát z čistého výchozího stavu. Hodnotí se výsledné záznamy a vedlejší účinky, nikoli jen formulace odpovědi.

V jedné analýze zahrnující 121 680 platných pokusů selhalo 79 853 pokusů při kontrolách výsledku. Z těchto neúspěchů přitom 67,24 % skončilo řádně, zahrnovalo nástroj měnící stav a nehlásilo závěrečnou chybu nástroje. Pozor na jmenovatel: nejde o dvě třetiny všech pokusů. Jde o dvě třetiny neúspěšných. Výsledky a metodika ThinkingBox.

Pro vlastní systém z toho plyne jednoduchá otázka: co přesně znamená „hotovo“? U servisního požadavku třeba existující přiřazení technikovi. U změny tarifu správné datum účinnosti. U exportu soubor, který lze otevřít a který obsahuje očekávané řádky.

Tuto podmínku napište předem. Měla by být ověřitelná programem a nezávislá na slovním hodnocení agenta. Jinak necháváte pracovníka podepisovat vlastní kontrolní protokol.

Stejně pečlivě rozlišujte jednorázový úspěch a opakovatelnost. Dvacet pokusů může znamenat „alespoň jednou uspěl“ nebo „uspěl pokaždé“. Pro provoz jsou to zásadně odlišné informace. Ani dvacet úspěchů ovšem není zárukou bezchybné budoucnosti. Je to užitečný test, ne věštecká koule.

Větší model nepřidá chybějící kontrolu

Říjnové technologické zprávy nabízejí výmluvnou kulisu. Tesla znovu předvádí Roadster a podle Ars Technica sází také na efekty se stlačeným plynem. Působivá demonstrace ovšem sama nedokládá připravenost sériového výrobku. U agentů je rozdíl mezi ukázkou a provozem podobný. Jen místo auta ve vzduchu sledujete zelenou fajfku. Reportáž Ars Technica.

NVIDIA a AI4Bharat mezitím oznámily korpus přibližně 2,8 bilionu tokenů pro 22 indických jazyků a otevřený postup generování dat. Původní článek uvádí, že vydání korpusu teprve přijde. Není tedy přesné automaticky tvrdit, že už je celý ke stažení. Podstatná je také dohledatelnost zdrojových dokumentů a kontrola překladů. Oznámení NVIDIA.

Další novinkou je Beam od Reflection. Podle oznámení má 501 miliard parametrů, z nichž se pro jednotlivý token aktivuje 23 miliard, a licenci Apache 2.0. Je určený také pro programování a agentní úlohy. Představení modelu Beam.

To všechno může pomoci. Více jazykových dat zlepší pokrytí, otevřené váhy umožní vlastní provoz. Žádné z těchto čísel ale nedokládá, že konkrétní změna zákaznického záznamu proběhla správně. Schopnost modelu a spolehlivost aplikace jsou dvě samostatné položky technického návrhu.

Zápis do databáze musí mít účtenku

Představme si vlastní modelový příklad. Agent má přiřadit technika k servisnímu požadavku číslo 1842. Aplikace mu nabídne úzce vymezenou operaci: identifikátor požadavku, identifikátor technika a očekávanou verzi záznamu.

Kontrola verze brání tomu, aby agent přepsal změnu kolegy. Pokud mezitím někdo požadavek upravil, operace musí oznámit konflikt. Tiché přepsání je přesně ten druh „pomoci“, který si správce pamatuje dlouho.

V PostgreSQL může základ vypadat takto. Názvy tabulky a sloupců jsou ilustrační:

```sql BEGIN;

UPDATE pozadavky SET technik_id = 27, stav = 'prirazeno', verze = verze + 1 WHERE id = 1842 AND verze = 7 AND stav = 'otevreno' RETURNING id, technik_id, stav, verze;

-- Aplikace ověří právě jeden vrácený řádek -- a očekávané hodnoty. Jinak provede ROLLBACK. ```

Teprve po úspěšné kontrole aplikace odešle `COMMIT`. Samotný komentář v ukázce žádnou kontrolu neprovádí. Tu musí skutečně obsahovat obslužný kód.

Transakce umožňuje související změny potvrdit společně, případně je zahodit. Nezaručuje však správnost obchodního rozhodnutí: dokonale atomicky lze uložit i nesmysl. Dokumentace transakcí PostgreSQL.

Po potvrzení následuje nové načtení z autoritativní databáze. Čtení ze zpožděné repliky může ukázat starší stav. Výsledek navíc spojte s identifikátorem operace, protože další oprávněná změna může přijít okamžitě.

Agent pak dostane konkrétní důkaz: změněný záznam, verzi a výsledek kontroly. Z toho sestaví odpověď. Když důkaz chybí, správný stav je „neověřeno“.

Časový limit není povolení udělat všechno znovu

Nejzrádnější chyba vypadá nenápadně. Aplikace odešle požadavek, server ho provede, ale odpověď se ztratí. Agent vidí překročený časový limit. Zkusí to znovu. A najednou máte dvě objednávky servisního výjezdu.

Řešením je identifikátor operace, který zůstává při opakování stejný. Server jej uloží a při dalším požadavku vrátí výsledek původní operace. Databázové omezení jedinečnosti musí zabránit souběžnému založení dvou kopií. Pouhá prosba v zadání modelu nestačí.

Oddělte také přijetí od dokončení. Odpověď rozhraní může znamenat jen zařazení do fronty. Praktický stavový postup má například čtyři kroky: přijato, provádí se, ověřeno, selhalo. Uživatelská zpráva musí odpovídat skutečnému kroku.

U operací přes více systémů narazíte na další hranici. Databázový návrat změn nevezme zpět již odeslaný e-mail. Proto lze záměr odeslat zprávu uložit ve stejné transakci jako obchodní změnu. Samostatný proces jej následně doručí. I ten potřebuje ochranu před duplicitami.

Do provozního záznamu patří identifikátor operace, verze modelu, verze nástroje, ověřené změny a časy. Přístupové klíče tam nepatří. Stejně tak není nutné kopírovat celý zákaznický profil, pokud k vyšetření stačí číslo požadavku. Dobrá dohledatelnost má pomoci opravě, ne vytvořit druhou neřízenou databázi.

Vlastní pokus spustíte přes Ollamu. Beam si nechte na větší rozpočet

Pro první laboratoř nepotřebujete serverovnu. Po instalaci Ollamy stáhněte menší model a spusťte jednoduchý rozhovor:

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

Balíček `qwen3:8b` má podle katalogu přibližně 5,2 GB a používá kvantizaci Q4_K_M. Velikost souboru ovšem není celková spotřeba paměti při běhu. Další prostor vyžaduje kontext a obsluha modelu. Karta modelu v Ollamě.

Jako praktický výchozí odhad počítejte s počítačem se 16 GB operační paměti a krátkým kontextem. Grafická karta s 12–16 GB vlastní paměti poskytne větší rezervu pro menší kvantizovaný model. Konkrétní rychlost musíte změřit; závisí na hardwaru, délce vstupu i souběhu požadavků.

Tyto dva příkazy ještě nevytvoří databázového agenta. K tomu potřebujete aplikaci, která předá dostupné operace, zkontroluje jejich argumenty a vyhodnotí výsledek. První pokus proto provádějte nad testovacími záznamy a s omezenými oprávněními.

U Beamu je paměťová matematika jiná. Prostý výpočet pro 501 miliard parametrů při dvou bajtech na parametr vychází na 1 002 GB samotných vah. Při idealizovaných čtyřech bitech je to přibližně 250,5 GB před další režií. Aktivace pouze části parametrů neznamená, že zbytek vah nemusíte nikde skladovat.

Pro přizpůsobení menšího modelu existuje LoRA. Učí malé dodatečné matice namísto úpravy všech vah. Šetří prostředky při trénování, ale nenahrazuje kontrolu výsledků. Dokumentace LoRA v knihovně PEFT.

Kolik stojí úspěšná operace? Tokeny jsou jen začátek

Rozpočet sestavujte na ověřený výsledek. Levné volání, po kterém člověk deset minut opravuje data, je drahé volání s hezkou fakturou.

Vezměme čistě modelový provoz s 10 000 úlohami měsíčně. Předpokládejme průměrnou cenu modelových volání 0,20 Kč na úlohu. To je 2 000 Kč. Nejde o ceník konkrétního poskytovatele, ale o vstup do výpočtu, který nahradíte vlastní naměřenou hodnotou.

Pokud 5 % úloh vyžaduje pětiminutovou kontrolu člověkem, vznikne 2 500 minut práce. Při zvoleném interním nákladu 600 Kč za hodinu jde o 25 000 Kč. Lidská kontrola zde stojí více než dvanáctinásobek samotných volání. Připočtěte hosting, dohled a údržbu integračního kódu.

Lokální provoz má zase odpisy hardwaru a elektřinu. Při naměřeném průměrném příkonu celé sestavy 150 W a nepřetržitém běhu po 30 dní spotřebujete 108 kWh. S modelovou konečnou cenou 6 Kč/kWh vychází energie na 648 Kč. Pořád bez pořizovací ceny počítače.

Burzovní cenu přitom nezaměňujte za konečnou cenu odběru. Pro orientaci můžete sledovat spotové ceny elektřiny a podkladová data denního trhu OTE. Do vlastního výpočtu ale dosaďte odpovídající cenu z vyúčtování.

Nejlepší optimalizace tak často začíná omezením oprav a opakovaných pokusů. O několik procent levnější model může být výhodný. O polovinu méně ručních zásahů bývá zajímavější.

U energetiky musí souhlasit i měřidlo

V energetické aplikaci nestačí ani správný zápis do databáze. Agent může uložit plán nabíjení baterie, zatímco zařízení je odpojené. Databáze potvrdila záměr. Fyzický svět zatím nepotvrdil provedení.

Rozlišujte proto vytvoření plánu, jeho přijetí řídicím systémem a naměřený účinek. Každý krok potřebuje vlastní důkaz. Pro tento rozdíl je relevantní IoT monitoring SmartEnergyShare: bez měření nemáte s čím porovnávat očekávaný stav.

V modelovém příkladu má baterie hodinu nabíjet výkonem 10 kW. Očekávaný odběr je přibližně 10 kWh, ale kontrola musí zohlednit místo měření, vlastní spotřebu a dostupná omezení. Samotný zápis „výkon nastaven“ nic neříká o tom, zda nabíjení skutečně proběhlo.

Podobnou disciplínu potřebují i administrativní procesy kolem [energetických řešení pro firmy](https://smartenergyshare.com/pro-firmy?utm_source=share-electric&utm_medium=referral&utm_campaign=satellite-marketing). Při napojování automatizace na řešení SmartEnergyShare si předem vyjasněte dostupná rozhraní a potvrzení jednotlivých kroků. Existence webové služby sama nedokládá podporu autonomního řízení.

Pro související čtení o inovacích a umělé inteligenci můžete pokračovat na ElectricShare.cz. Vlastní ověření však začněte skromně: vyberte jeden proces, připravte dvacet opakování a nasimulujte výpadek spojení po zápisu. Spočítejte správné výsledky, duplicity i nutné zásahy.

Moje předpověď? Nejžádanější funkcí podnikových agentů nebude výřečnost. Bude to věrohodná odpověď na otázku: „Podle čeho víš, že je hotovo?“

Zdroje

• Microsoft a Hugging Face: ThinkingBox — Primární podklad pro úvodní příklad, rozsah benchmarku a údaje o neúspěšných pokusech. Při čtení výsledků rozlišujte úspěšnost jednotlivých pokusů, alespoň jeden úspěch a úspěch ve všech opakováních.
• NVIDIA: předtrénování pro indické jazyky — Oznámení korpusu a otevřeného postupu jeho tvorby. Pro vlastní experiment si nejprve ověřte dostupnost konkrétního vydání, licenci a způsob počítání tokenů; oznámený rozsah není automaticky rozpočtem jednoho trénování.
• Hugging Face: představení Beamu — Zdroj parametrů a licenčních informací o modelu. Před nasazením porovnejte podporovaný formát vah, požadavky obslužného programu a rezervu paměti pro skutečnou délku kontextu i počet uživatelů.
• PostgreSQL: transakce — Technický základ pro potvrzování a rušení souvisejících databázových změn. Ukázku v článku berte jako návrhový vzor; skutečná aplikace musí doplnit kontrolu výsledků, oprávnění a zpracování konfliktů.
• OTE: denní trh s elektřinou — Český primární zdroj tržních dat pro energetickou část. Uvedené korunové rozpočty jsou vlastní modelové výpočty s výslovnými předpoklady, nikoli cenová nabídka OTE, dodavatele elektřiny nebo provozovatele modelu.

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: ElectricShare.cz AWS prodává AI bloky za miliony. Tady je, jak trénovat vl... Vice o autosynthdata: generating