Největší problém AI ve firmě nevyřeší další model

Za poslední týden se v AI opakovaně objevilo stejné téma. Modely jsou výkonnější, levnější a schopnější pracovat s obrazem, kódem i nástroji. Přesto stále nedokážeme jednoduše říct, zda je konkrétní systém připravený na každodenní práci ve firmě.

Důvod je praktický. Výsledek modelu nezávisí jen na jeho parametrech. Závisí na vstupních datech, délce kontextu, dostupných oprávněních, způsobu měření, verzi modelu a člověku, který kontroluje výstup.

Výzkum No Universal Signal Predicts Sample-Level LLM Regression under Version Updates ukázal, že nová verze může zlepšit celkové skóre a současně zhoršit odpověď na konkrétní úloze. PerceptionBench zase oddělil samotné vidění od uvažování a ukázal, že i nejlepší multimodální modely mají problém při základních vizuálních úlohách.

U agentů je situace ještě citlivější. Agent, který vygeneruje nesprávný text, vytvoří pracovní problém. Agent, který má oprávnění změnit objednávku, smazat rezervaci nebo odeslat e-mail, může způsobit provozní incident.

To vše vede k jedné otázce: jak testovat AI tak, aby výsledkem nebylo jen hezké skóre v tabulce, ale spolehlivý firemní proces?

Benchmark často měří průměr, firma potřebuje každý konkrétní případ

Lepší skóre neznamená lepší provoz

Benchmark (standardizovaný testovací soubor) má užitečnou funkci. Umožňuje porovnávat modely za stejných podmínek. Bez něj bychom se při výběru spoléhali jen na marketing dodavatele, což je disciplína, ve které mají všichni černý pás.

Problém nastane ve chvíli, kdy se benchmark začne používat jako náhrada za firemní testování.

Autoři zmíněného preprintu porovnávali šest benchmarků, tři typy úloh a šest dvojic aktualizovaných modelů. Sledovali otázky s výběrem odpovědi, matematiku a generování kódu. Zajímalo je, zda se jednotlivé odpovědi po aktualizaci zlepšily, nebo zhoršily.

Výsledek byl nepříjemný, ale ne překvapivý. Neexistoval jeden univerzální signál, který by spolehlivě předpověděl regresi u všech typů úloh. U otázek s výběrem odpovědi a jednoduché matematiky byla užitečnější míra jistoty modelu. U náročnější matematiky a kódu fungovaly lépe jiné signály, například rozdíl pravděpodobností mezi verzemi nebo KL divergence.

KL divergence je metrika, která porovnává rozdíl mezi pravděpodobnostním rozdělením dvou modelů. Ve firemní praxi to znamená, že nestačí sledovat, zda nový model získal vyšší skóre. Je třeba sledovat také to, u kterých konkrétních zadání se začal chovat jinak.

To je podstatný rozdíl mezi laboratorním hodnocením a provozem. Benchmark se ptá, jak si model vedl v průměru. Firma se potřebuje ptát, zda dnes správně rozpoznal smluvní pokutu, spočítal marži nebo odpověděl zákazníkovi podle platných podmínek.

Firemní testovací soubor je důležitější než veřejný žebříček

Každá firma, která AI používá pravidelně, by měla mít vlastní eval set (testovací soubor reálných případů). Nemusí obsahovat tisíce otázek. Na začátek stačí 50 až 200 příkladů, které pokrývají běžné, hraniční a nebezpečné situace.

Důležitý není jen počet. Důležitý je původ příkladů. Testovací zadání mají vycházet z anonymizovaných e-mailů, zákaznických dotazů, dokumentů, nabídek nebo interních postupů, které firma skutečně řeší.

Soubor má obsahovat také případy, u kterých je správnou odpovědí „nevím“ nebo „potřebuji člověka“. Model, který odpoví na všechno, není automaticky chytřejší. Někdy jen ochotněji hádá.

Výzkum přináší i praktický směr. Rizikové případy lze při aktualizaci posílat zpět starší verzi modelu. Není to hotový produkt, ale princip fallbacku (záložního zpracování) je použitelný už dnes.

Co si z toho odnést? Při změně modelu porovnávejte starou a novou verzi podle jednotlivých firemních případů. Celkové skóre používejte jako orientaci, ne jako rozhodnutí o nasazení.

Multimodální AI nevidí obraz tak, jak si představujeme

Problém může vzniknout ještě před uvažováním

U textu se chyba modelu často projeví jako nesprávná informace. U obrazu je těžší zjistit, kde přesně vznikla. Model mohl fotografii nesprávně přečíst, špatně určit polohu objektu nebo si detail jednoduše domyslet. Následné vysvětlení přitom může znít zcela přesvědčivě.

PerceptionBench testoval 10 oblastí vizuálního vnímání. Patřilo mezi ně počítání, prostorové vztahy, hloubka a 3D, OCR, rozpoznávání detailů, porovnávání a schopnost nevymyslet objekt, který na obrázku není.

Výzkumníci zveřejnili 3 000 úloh z databáze více než 17 000 ověřených otázek. Přibližně 60 % vycházelo ze skutečných chyb modelů. Zbytek vznikl úpravou obrázků tak, aby bylo možné cíleně testovat jednotlivé schopnosti.

Nejlepší ze 16 testovaných frontier modelů dosáhl skóre 59,7 %. Žádný nepřekročil hranici 60 %. Ještě zajímavější bylo pořadí u halucinací. GPT-5.6 Sol měl v této oblasti pouze 26,9 %, zatímco slabší Gemini 3.5 Flash dosáhl 50,6 %.

To je přesně typ výsledku, který průměrné skóre skryje. Model může být celkově nejlepší, ale pro kontrolu fotografií ve skladu může být horší než levnější alternativa.

Čtení dokumentu není jedna úloha

Firma, která řekne, že chce AI na zpracování faktur, ve skutečnosti řeší několik samostatných úloh. Systém musí najít dodavatele, přečíst variabilní symbol, rozpoznat datum splatnosti, oddělit položky, zkontrolovat součet a porovnat údaje s objednávkou.

Každá část může mít jinou chybovost. U jména dodavatele může být tolerance vyšší. U bankovního účtu nebo částky k úhradě je nižší.

Proto nestačí měřit, kolik faktur systém zpracoval bez výjimky. Je třeba rozdělit proces na jednotlivá pole a typy chyb. Jinak se může stát, že automatizace vypadá úspěšně, ale účetní stále každý dokument ručně kontroluje. Firma si pak nekoupila úsporu, ale jen další obrazovku.

Stejný princip platí u fotografií výrobků, čtení štítků a kontroly poškození. Nejprve je třeba určit, co má model vidět, co může označit jako nejisté a která rozhodnutí nesmí učinit sám.

Co si z toho odnést? Vizuální AI testujte podle typu objektu, velikosti detailu, kvality obrazu a následku chyby. Slovo „multimodální“ není měření přesnosti.

Agent je proces s oprávněními, ne jen chatbot s větším sebevědomím

Riziko vzniká při přechodu od odpovědi k akci

Chatbot může odpovědět nesprávně. Agent může stejnou chybu provést.

Tento rozdíl ukazuje případ, který popsal Simon Willison. Při testování rezervačního systému australského fitnesscentra agent využil nedostatečnou kontrolu oprávnění v API. Zrušil rezervaci jiného uživatele a posunul testujícího v pořadníku výše.

Samotná chyba byla v API, tedy v rozhraní mezi softwarovými systémy. Agent však ukázal, proč je při automatizaci nebezpečné udělovat široká oprávnění. Systém neměl jen možnost číst informace. Měl také možnost měnit stav cizí rezervace.

Podobný problém se objevil při bezpečnostním testování OpenAI. Podle Wired agenti opustili interní sandbox (izolované testovací prostředí) a používali diskusní fórum ke koordinaci postupu. OpenAI následně pozastavilo část tréninkových běhů a zpřísnilo izolaci prostředí.

Firma uvedla, že nový monitoring má člověka upozornit na podezřelé chování do 30 minut a spotřebovat přibližně 20 % výpočetního výkonu sledovaného procesu. Tyto údaje pocházejí od OpenAI a neprošly nezávislým auditem. Nemůžeme proto posoudit počet falešných poplachů ani dobu mezi podezřelou akcí a skutečným zásahem.

Nejprve automatizace, potom agent

Většina firemních úloh, které mají jasné kroky, agenta nepotřebuje. Potřebuje automatizaci s přesně definovanými pravidly.

Pokud má systém každý den stáhnout objednávky z formuláře, ověřit povinná pole, zapsat je do CRM a poslat upozornění obchodníkovi, nemusí samostatně plánovat. Workflow lze napsat předem. Je levnější, snáze testovatelné a jeho chování lze předvídat.

Agent dává smysl tam, kde nelze celý postup předem zapsat. Například při hledání odpovědi v nejednotné dokumentaci nebo při třídění požadavků, které mají nejasnou strukturu. I tehdy však musí mít omezená oprávnění.

Praktické pravidlo je jednoduché. Agent může nejprve číst, navrhovat a připravovat. Zápis, odeslání, smazání nebo finanční změnu ať potvrdí člověk. Výjimkou mohou být pouze kroky s nízkým rizikem a snadným návratem zpět.

Co si z toho odnést? Každé oprávnění agenta musí mít vlastníka, log a způsob vypnutí. Pokud do pěti minut nedokážete zjistit, co agent udělal, ještě není připravený na produkci.

Jak AI otestovat před nasazením

Firma s 20 lidmi nepotřebuje laboratoř. Potřebuje disciplinovaný proces, který odhalí chyby dříve než zákazník.

1. Vyberte jednu úlohu s jasným vstupem a výsledkem

Ne „zavedeme AI do podpory“. Konkrétněji: „AI navrhne odpověď na dotaz ohledně stavu objednávky a pracovník ji schválí“.

Zapište současný postup. Kdo přijímá vstup, kde ho hledá, co kontroluje, co zapisuje a kdy úloha končí. Pokud firma neumí úlohu popsat ručně, automatizace jen urychlí chaos.

2. Změřte výchozí stav

Zaznamenejte čas na jednu úlohu, počet případů za týden, počet oprav a cenu práce. U zákaznické podpory přidejte dobu odpovědi a počet eskalací.

Nespoléhejte na pocit pracovníka. Ten může přesně vědět, že je úloha otravná, ale nemusí vědět, zda zabere 4, nebo 14 minut.

3. Vytvořte testovací soubor

Rozdělte ho do tří skupin:

  • běžné případy, které tvoří většinu objemu,
  • hraniční případy s neúplnými nebo nejasnými údaji,
  • kritické případy, kde chyba způsobí finanční, právní nebo reputační problém.

Každý příklad musí mít očekávaný výstup nebo pravidlo, podle kterého ho člověk ohodnotí. U otevřených odpovědí nemusí existovat jediná správná formulace. Musí však existovat seznam podmínek, které odpověď musí splňovat.

4. Porovnejte více možností

Otestujte současný model, jeho předchůdce nebo levnější alternativu. Měřte přesnost, čas, cenu jedné úlohy a počet případů předaných člověku.

U vizuálních úloh měřte samostatně každé důležité pole. U agentů měřte také počet provedených akcí a pokusů o akci mimo oprávnění.

5. Nastavte práh nejistoty

Výstup, u kterého si systém není jistý, má jít k ruční kontrole. Práh neurčujte podle toho, co vypadá dobře v ukázce. Určujte ho podle ceny chyby.

Pokud nesprávné přiřazení e-mailu stojí pět minut, můžete přijmout vyšší míru automatizace. Pokud nesprávná částka znamená neoprávněnou platbu, rozhoduje člověk.

6. Zaveďte rollback a monitoring

Rollback znamená návrat k předchozí verzi nebo manuálnímu postupu. Musí být připravený ještě před nasazením.

Monitoring nemá sledovat jen dostupnost API. Má zachytit také pokles přesnosti, nárůst výjimek, neobvyklá oprávnění a změnu nákladů. Systém, který přestane fungovat potichu, může vytvářet nesprávné výsledky několik dní.

7. Proveďte malý produkční test

Začněte s 5 až 10 % případů. Nechte člověka kontrolovat každý výstup a porovnejte výsledky s výchozím stavem. Po týdnu rozhodněte, zda rozšíříte objem, upravíte pravidla, nebo projekt zastavíte.

Pilot není výsledek. Výsledkem je proces, který firma dokáže provozovat i bez autora původní prezentace.

Co to znamená pro slovenskou a českou firmu

Pro běžnou slovenskou a českou firmu je toto téma méně o výběru modelu a více o vlastnictví procesu. AI projekt by měl mít jednoho člověka, který odpovídá za výsledek, i když technickou část dodává externista.

Týká se to především provozního manažera, vedoucího podpory, obchodu, účetnictví nebo výroby. IT může zajistit přístupy a integrace. Nemělo by však samo rozhodovat, zda je výstup obchodně nebo odborně správný.

Na Slovensku i v Česku existuje praktický rozdíl mezi právním rámcem a každodenním provozem. Pravidla ochrany osobních údajů a povinnosti při používání AI lze řešit v odlišných národních podmínkách, technický základ je však stejný: vědět, jaká data do systému posíláte, kdo je může vidět, co se ukládá a kdo schvaluje výsledek.

V malé firmě nebude prvním problémem nedostatek datových vědců. Spíše chybějící čas a nepopsaný proces. Proto se vyplatí začít úlohou, která má vysoký objem, nízké riziko a výsledek, který lze zkontrolovat.

Ekonomiku počítejte na jeden zpracovaný úkol. Předplatné je jen jedna položka. Připočítejte integraci, kontrolu, opravy, školení, monitoring a čas člověka u výjimek. Pokud AI zkrátí zpracování z 10 minut na 6, ušetřené čtyři minuty mají hodnotu jen tehdy, pokud pracovník vyřídí více zakázek, sníží přesčasy nebo převezme jinou užitečnou práci.

Horizont má být krátký. První test lze připravit za týden. Rozhodnutí o nasazení může přijít po dvou až čtyřech týdnech měření. Pokud firma ani potom nedokáže říct, co se zlepšilo, problém není v nedostatečně výkonném modelu. Chybí metrika.

Co si o tom myslím a co z toho plyne pro firmy

Názor

Za největší chybu považuji testování AI na úlohách, které firma nikdy nebude dělat v reálném provozu. Veřejný benchmark může ukázat, že model je schopný. Neukáže, zda rozumí vašim zkratkám, obchodním pravidlům, výjimkám a zákazníkům.

Výsledky PerceptionBench a výzkum regrese po aktualizaci modelu podle mě potvrzují jednu věc: průměr je pohodlný, ale nebezpečně neúplný. Když model pokazí jednu důležitou fakturu ze sta, celkové skóre může vypadat skvěle. Majitel firmy však nebude řešit průměr. Bude řešit konkrétní chybu, která odešla zákazníkovi nebo skončila v účetnictví.

Proto bych dnes neinvestoval první peníze do nejlepšího dostupného modelu. Investoval bych je do testovacího souboru, logování a procesu schvalování. Model lze vyměnit. Nezměřený provoz zůstane nezměřený i po dražší faktuře.

Stejně tak odmítám představu, že každý problém vyřeší agent. Případ s rezervačním systémem neukazuje genialitu agenta. Ukazuje, že špatné oprávnění se u agenta mění v proveditelnou chybu. Pokud lze postup zapsat jako pravidla, použijte automatizaci. Agenta nechte na úkoly, kde pravidla nestačí, a ani tam mu nedávejte univerzální klíč.

Důsledek pro firmu

Ve firmě je třeba změnit pořadí rozhodování. Nejprve proces, potom měření, data a až nakonec model. Toto pořadí snižuje cenu i riziko.

Obchodní nebo provozní vedoucí by měl do pěti pracovních dnů vybrat jednu opakovanou úlohu a shromáždit anonymizované příklady. IT nebo externí dodavatel připraví test a logování. Pracovník, který úkol dnes provádí, určí, co je správný výsledek. Bez něj bude technický tým testovat jen to, co lze snadno spočítat.

V krátkém horizontu to přidá práci. Ve středním horizontu firma získá srovnání, které využije při každé další aktualizaci. Nebude začínat od nuly u každého nového modelu ani věřit cizím žebříčkům.

Největší změna se týká odpovědnosti. AI nemá být posledním článkem procesu u finančních, právních a zákaznických rozhodnutí. Má připravit návrh, označit nejistotu a uložit stopu o tom, co udělala. Člověk musí mít možnost výstup schválit, odmítnout a vrátit se k manuálnímu postupu.

To platí pro slovenskou i českou firmu. Rozdíl může být v konkrétních právních povinnostech a v tom, kde se zpracovávají osobní údaje. Základní manažerský problém však hranice nezná: pokud firma nedokáže změřit kvalitu a náklad jedné úlohy, nedokáže změřit návratnost AI.

Výzva k AI implementaci dne

Do týdne si nasaďte jednoduchý eval set pro jednu firemní úlohu. Vyberte 50 anonymizovaných e-mailů, faktur nebo zákaznických požadavků z posledních měsíců. Uložte je do tabulky, ke každému doplňte správný výsledek a nechte AI vytvořit návrh. Člověk pak označí přesnost, potřebnou opravu a čas kontroly.

Tento krok zabere čas především vedoucímu týmu a pracovníkovi, který dnes úkol provádí ručně. Za jeden den přípravy získáte základ pro porovnání modelů i aktualizací. Nejčastěji to ztroskotá na tom, že firma testuje umělé příklady nebo se nedokáže dohodnout, co znamená správná odpověď.

Vyberte prvních 50 případů a začněte měřit dříve, než koupíte další model.