Spoľahlivosť AI sa začína mimo modelu

Za posledný týždeň sa opakovane objavila jedna téma, hoci zakaždým v inom obale. Model MIT simuloval extrémnu búrku, ktorá ešte nemala historický záznam. Chatboty odpovedali na citlivú zdravotnú otázku, no používateľovi neoznačili zaujaté zdroje. Roboty prekonali ľudský šprint, ale po dobehu potrebovali pomoc. AI pri programovaní zrýchlila tvorbu kódu a zároveň zvýšila tlak na jeho kontrolu.

Na prvý pohľad ide o nesúvisiace správy. Všetky však riešia tú istú praktickú otázku: vieme zistiť, kedy je výstup systému použiteľný a kedy iba vyzerá presvedčivo?

Výskum MIT ukazuje, že AI môže vytvárať pravdepodobné scenáre aj mimo historických dát. To je užitočné, ale iba vtedy, keď firma rozumie, ktoré dáta model potrebuje a kde sú jeho hranice. Analýza AlgorithmWatch zasa ukázala, že chatbot môže podať formálne relevantnú odpoveď a súčasne zlyhať v transparentnosti.

To je rozdiel medzi schopnosťou a spoľahlivosťou. Schopnosť znamená, že systém niečo dokáže. Spoľahlivosť znamená, že firma vie, kedy to dokáže, kedy nie, čo sa stane pri chybe a kto ju zachytí.

Verejný benchmark neodpovie na firemnú otázku

Benchmark, teda štandardizovaný testovací súbor, je užitočný pri porovnávaní modelov. Bez neho by sa výber technológie zmenil na súťaž marketingových prezentácií. Benchmark však meria priemerný výkon v pripravených podmienkach. Firma potrebuje vedieť, čo sa stane pri jej konkrétnom dokumente, zákazníkovi alebo pracovnom postupe.

Výskum No Universal Signal Predicts Sample-Level LLM Regression under Version Updates porovnával aktualizované verzie modelov na viacerých typoch úloh. Autori sledovali otázky s výberom odpovede, matematiku a generovanie kódu. Zistili, že neexistuje jeden univerzálny signál, ktorý by spoľahlivo predpovedal, či nová verzia zlepší alebo zhorší každý konkrétny prípad.

Nešlo o drobný technický detail. Nový model môže mať lepšie celkové skóre a pritom horšie odpovedať na otázku, ktorá je pre firmu kritická. Môže presnejšie riešiť všeobecnú matematiku, ale nesprávne vypočítať zľavu podľa interného cenníka. Môže lepšie písať kód, no zmeniť správanie starého integračného rozhrania.

To je dôvod, prečo rebríček modelov nie je nákupné rozhodnutie. Je iba prvým sitom. Pri rozhodovaní treba oddeliť najmenej štyri veci: všeobecnú schopnosť modelu, správanie na vlastných dátach, cenu za spracovanie a riziko chyby.

Výskum PerceptionBench podobne rozlišuje medzi videním a uvažovaním. Multimodálny model môže pôsobiť inteligentne pri opise obrázka, no zlyhať pri základnej vizuálnej úlohe. Pre sklad, výrobu alebo kontrolu dokladov je takýto rozdiel praktický, nie akademický.

Vlastný eval set, teda testovací súbor reálnych prípadov, preto patrí medzi základné vybavenie každého pravidelne používaného AI systému. Na začiatok stačí 50 až 200 anonymizovaných príkladov. Majú obsahovať bežné úlohy, hraničné situácie, neúplné vstupy a prípady, pri ktorých je chybná odpoveď drahá alebo nebezpečná.

Dôležité je aj správne rozdelenie príkladov. Ak firma testuje iba bežné požiadavky, meria ideálnu prevádzku. Do súboru treba zaradiť aj dokument s chýbajúcou stranou, zákazníka s nejasnou otázkou, starú verziu cenníka či text, ktorý obsahuje pokyn určený pre model. Posledný prípad je forma prompt injection (podvrhnutie pokynu do vstupných dát), nie bežná požiadavka používateľa.

Testovací súbor nesmie zostať rovnaký navždy. Každá nová chyba z prevádzky sa má stať novým testovacím prípadom. Inak firma opakuje rovnakú chybu s čoraz väčšou dôverou v graf, ktorý už dávno nezodpovedá realite.

Najväčšie riziko vzniká medzi výstupom a rozhodnutím

Odpoveď nie je ešte rozhodnutie

Chatbot môže nájsť zdroj, robot môže vykonať pohyb a agent môže odoslať správu. Ani jeden z týchto výkonov však automaticky neznamená, že systém môže rozhodnúť namiesto človeka.

Pri zdravotnej otázke je problémom zamlčaná zaujatosť zdroja. Pri obsahovom marketingu je problémom text bez vlastnej hodnoty. Pri automatizovanom rozhodovaní o vodičoch môže byť problémom vypnutie účtu bez vysvetlenia. Správa Engadgetu o pokute pre Uber ukazuje, že automatické rozhodnutie má právne a ľudské následky, aj keď vzniklo v softvéri.

Pri rozhodovaní o úrovni automatizácie pomáha rozdeliť proces na tri stupne. Prvý je návrh. AI pripraví podklad a človek rozhodne. Druhý je asistované vykonanie. Systém urobí časť práce, ale potrebuje schválenie pred zápisom alebo odoslaním. Tretí je automatické vykonanie bez kontroly pri každom prípade.

Väčšina firiem by mala začať na prvej alebo druhej úrovni. Automatické vykonanie patrí iba tam, kde je proces dobre opísaný, chyba má obmedzený dopad a existuje jednoduchá cesta späť. Ak systém posiela návrhy odpovedí, oprava je lacná. Ak mení ceny, ruší objednávky alebo rozhoduje o nároku zákazníka, rovnaký model potrebuje oveľa prísnejšie hranice.

Námietka znie rozumne: ľudská kontrola znižuje úsporu. Ak má zamestnanec prečítať každý výstup, prečo AI vôbec používať? Odpoveď závisí od procesu. Kontrola návrhu môže byť podstatne rýchlejšia než písanie od začiatku. Zároveň však treba merať skutočný čas po kontrole. Ak pracovník opravuje každý druhý výstup, systém nevytvoril automatizáciu. Vytvoril novú redakčnú úlohu.

Tiché zlyhanie je horšie než výpadok

Systém, ktorý prestane fungovať a pošle chybu, si niekto všimne. Horší je systém, ktorý ďalej vytvára odpovede, no ich kvalita sa potichu zhoršila.

Takýto problém môže vzniknúť zmenou modelu, úpravou promptu, zmenou dokumentov, novým formátom dát alebo aktualizáciou rozhrania dodávateľa. Pri agentoch pribúda ďalšie riziko. Agent môže mať prístup k nástrojom, ktoré mu umožnia upraviť objednávku, poslať e-mail alebo zmeniť záznam v systéme.

Každá automatizácia preto potrebuje monitorovanie. Firma má sledovať počet spracovaných prípadov, chybovosť, podiel zásahov človeka, čas do opravy a náklady na jeden prípad. Pri generatívnom systéme treba navyše náhodne kontrolovať výstupy, nie iba merať počet úspešne dokončených úloh.

Zmysel má aj jednoduchý alerting (upozorňovanie na problém). Ak sa podiel manuálnych opráv zvýši nad dohodnutý limit, systém má zastaviť automatické odosielanie a oznámiť to vlastníkovi procesu. Ak integrácia nevráti odpoveď alebo začne vracať prázdne dáta, nemá sa pokračovať s predpokladom, že všetko je v poriadku.

Systém musí mať aj kill switch, teda spôsob rýchleho vypnutia. Nemusí ísť o komplikovanú bezpečnostnú platformu. Pri malej firme môže byť riešením vypnutie automatického kroku v nástroji, presmerovanie úloh do schvaľovacieho zoznamu a jasne určený človek, ktorý to smie urobiť.

Dobré skóre na začiatku projektu nestačí. Prevádzkový systém musí vedieť povedať, že sa zhoršil. Inak meria iba sebavedomie vlastníka projektu.

Dáta určujú, čo môže AI predpovedať

MIT metóda Extreme Event Aware, označovaná aj ako η-learning, je dobrým príkladom toho, čo AI vie a čo nevie. Výskumníci Kai Chang a Themis Sapsis pracovali s 25 rokmi hodinových údajov o daždi, ktoré zoskupili do denných máp. Pri priestorovej časti modelu však použili iba prvých šesť mesiacov záznamu, teda obdobie s malým počtom silných dažďov.

Model dokázal vytvoriť pravdepodobnú mapu udalosti s denným úhrnom 300 milimetrov, hoci najvyšší zaznamenaný úhrn v New Yorku bol 200 milimetrov. Simulácia obsahovala aj odhad trvania, intenzity, veľkosti a zasiahnutej oblasti.

Hodnota tejto metódy nie je v tom, že „uhádne budúcnosť“. Model využíva existujúce štatistické a priestorové vzťahy na vytvorenie scenára, ktorý sa ešte nestal. Autori zároveň upozorňujú, že potrebuje relevantné bodové štatistiky a priestorové údaje. Demonstrácia sa týkala amerických zrážok, nie povodia Dunaja alebo Moravy.

To je dobrá odpoveď aj na častú námietku, že AI predsa nevie predpovedať niečo, čo nikdy nevidela. Nemusí kopírovať konkrétnu historickú udalosť. Môže kombinovať vzorce, ktoré v dátach existujú, a vytvoriť nový pravdepodobný scenár. Zároveň však nemôže spoľahlivo odhadnúť premennú, ktorú firma vôbec nezbierala.

Ak chce napríklad predpovedať výpadky dodávok, potrebuje nielen históriu objednávok. Potrebuje aj údaje o dodacích lehotách, reklamáciách, sezónnosti, závislosti od konkrétnych dodávateľov a prípadne počasí. Ak tieto premenné chýbajú, systém môže vytvoriť presvedčivú simuláciu, ale nie spoľahlivý plán.

Dáta majú tri vrstvy. Prvou je pokrytie, teda či firma vôbec eviduje potrebné udalosti. Druhou je kvalita, teda či sú údaje úplné, konzistentné a správne označené. Treťou je časová platnosť. Starý cenník alebo zmenená logistická trasa môžu byť technicky dostupné, ale pre dnešné rozhodnutie nesprávne.

Pri zavádzaní AI sa preto oplatí viesť katalóg dát. Pri každom procese má byť jasné, odkiaľ vstupy pochádzajú, ako často sa aktualizujú, kto ich vlastní, aké majú obmedzenia a čo v nich chýba. Táto práca je menej atraktívna než výber modelu. Je však bližšie k výsledku.

Ak firma používa externý model, pribúda otázka, kam dáta odchádzajú. Pri nákupe treba zistiť, či dodávateľ používa vstupy na trénovanie, ako dlho uchováva konverzácie, v akej krajine ich spracúva a či poskytuje auditnú stopu. Zmluva má riešiť aj export dát a ukončenie služby. Uzavretosť je náklad, ktorý sa objaví až neskôr.

Modely sa menia, preto sa musí meniť aj testovanie

Aktualizácia modelu sa vo firme často vníma ako technické zlepšenie. V skutočnosti môže ísť o zmenu pracovného nástroja. Inak sa môže správať pri rovnakom prompte, rovnakom dokumente aj rovnakej požiadavke.

Pri každej zmene treba zopakovať regresný test (overenie, či sa nezhoršili existujúce funkcie). Nemusí pokrývať celý internet ani všetky schopnosti modelu. Musí pokrývať úlohy, za ktoré firma ručí. Ak AI triedi dopyty, test má overiť kategórie, chýbajúce údaje, duplicitné požiadavky a nesprávne zaradenie. Ak pripravuje zmluvné zhrnutie, test má obsahovať aj výnimky, lehoty a finančné záväzky.

Praktické je rozdeliť výsledky na tri skupiny. Pass znamená, že výstup spĺňa pravidlá. Review znamená, že odpoveď môže pokračovať iba po kontrole človekom. Fail znamená, že systém nesmie výstup použiť a prípad sa má vrátiť do ručného procesu.

Takéto označenie je užitočnejšie než jedno celkové percento. Pri kritickej úlohe môže byť 95 % priemer prijateľných, ale zvyšných 5 % môže obsahovať chybu v platbe alebo právnej lehote. Firma potrebuje vedieť, ktoré chyby sa skrývajú v priemere.

Dôležitý je aj denominator, teda menovateľ výpočtu. „AI spracovala 1 000 prípadov“ nehovorí, koľko ich bolo správnych. „90 % automatizácie“ nemusí znamenať, že 90 % práce zmizlo. Môže to znamenať iba to, že systém vytvoril 900 návrhov, ktoré niekto musel skontrolovať.

Rovnako treba odlíšiť presnosť od úplnosti. Odpoveď môže byť fakticky správna, ale vynechať dôležitú výnimku. Chatboty pri analýze AlgorithmWatch neboli problémové iba preto, že odkazovali na konkrétne stránky. Zlyhanie spočívalo aj v tom, že používateľovi nepovedali, z akej pozície zdroj hovorí.

Pri firemnom obsahu je podobné riziko bežné. Text môže byť gramaticky bezchybný, no nemusí obsahovať vlastnú skúsenosť firmy, overiteľný zdroj ani rozhodnutie, ktoré má pre čitateľa hodnotu. Výskum Pew Research Center ukázal, že približne 35 % novších anglických stránok nieslo významné znaky AI autorstva alebo úprav. Samotná prítomnosť AI však nie je dôkazom nízkej kvality. Rozhodujúci je redakčný proces.

Ako to použiť: kontrola pred nasadením

Bežná firma s dvadsiatimi ľuďmi nepotrebuje oddelenie dátových vedcov. Potrebuje človeka, ktorý vlastní proces, človeka, ktorý rozumie dátam, a jednoduchý záznam o výsledkoch. Postup môže vyzerať takto:

1. Vyberte jednu opakovanú úlohu. Nie „zaveďme AI do marketingu“, ale napríklad triedenie prichádzajúcich dopytov, kontrola úplnosti faktúr alebo príprava návrhu odpovede zákazníkovi.
2. Napíšte dnešný ručný postup. Uveďte vstup, jednotlivé kroky, výnimky, zodpovedného človeka a čas spracovania. Ak proces nikto nevie opísať, ešte nie je pripravený na automatizáciu.
3. Zostavte vlastný testovací súbor. Použite anonymizované reálne prípady. Rozdeľte ich na bežné, hraničné a kritické.
4. Pridajte negatívne prípady. Zahrňte neúplný dokument, protichodné údaje, neplatný formát a vstup s pokynom, ktorý nemá patriť do pracovného procesu.
5. Definujte toleranciu chyby. Pri návrhu predmetu e-mailu môže byť prijateľné, že človek upraví každú piatu verziu. Pri výpočte ceny alebo právnom stanovisku nie.
6. Určte úroveň oprávnení. Na začiatku nech AI číta a navrhuje. Odosielanie, mazanie a zápis do kľúčových systémov nech vyžaduje schválenie.
7. Zmerajte základný stav. Zapíšte čas na jeden prípad, počet chýb, počet zásahov človeka a cenu práce. Bez toho sa návratnosť nedá vypočítať.
8. Spustite skúšobnú prevádzku. AI môže pripravovať výsledky paralelne s človekom. Porovnávajte ich aspoň jeden pracovný týždeň alebo počas 50 až 100 prípadov.
9. Zaveďte monitorovanie. Kontrolujte náhodnú vzorku výstupov a nastavte upozornenie pri raste chybovosti, nezvyčajnom počte výnimiek alebo výpadku integrácie.
10. Po aktualizácii test zopakujte. Zmena modelu, promptu alebo zdrojových dát je zmena systému. Neberte ju ako technický detail.
11. Rozhodnite podľa výsledku. Systém buď rozšírte, upravte, alebo vypnite. Pilot bez rozhodnutia je iba dlhšie trvajúca prezentácia.

Ako počítať cenu

Cena AI systému nie je iba mesačné predplatné. Treba pripočítať nastavenie, integráciu, čas na prípravu dát, kontrolu výstupov, údržbu a náklady na chyby.

Jednoduchý výpočet môže vyzerať takto:

čistá úspora = ušetrený čas × interná hodinová cena - cena nástroja - kontrola - údržba - náklady na chyby

Ak pracovník dnes strávi spracovaním jedného dopytu 12 minút a AI skráti prípravu na 4 minúty, nejde automaticky o osem minút úspory. Ak musí ďalšie 4 minúty overovať každú odpoveď, čistý zisk je menší. Ak sa ušetrený čas nepoužije na inú hodnotnú prácu, finančná úspora nemusí vzniknúť vôbec.

Pri agentovi treba do kalkulácie zaradiť aj údržbu integrácií. Cena nasadenia môže byť nízka, no zmena API alebo oprávnení na strane dodávateľa vytvorí opakovanú prácu. Automatizácia, ktorá funguje iba dovtedy, kým sa nezmení obrazovka v cudzej aplikácii, nie je lacná. Iba zatiaľ nevystavila účet.

Pri agentovi pridajte skúšku s nepriateľskými vstupmi. Overte, či ignoruje pokyn vložený do cudzieho dokumentu, či neprekročí oprávnenia a či sa dá jeho krok zrušiť. Pri citlivých dátach spíšte, čo môže dodávateľ ukladať, kde sa dáta spracúvajú a ako firma službu opustí.

Čo to znamená pre slovenskú a českú firmu

Pre firmu na Slovensku alebo v Česku je prvým dôsledkom zmena vlastníka AI projektu. Nemá ho vlastniť iba IT oddelenie. IT vie pripojiť nástroj, nastaviť prístup a riešiť bezpečnosť. O tom, či je odpoveď správna, však musí rozhodovať človek, ktorý pozná proces a zodpovedá za jeho výsledok.

V malej firme môže túto úlohu zastávať jeden procesný vlastník. Musí mať čas raz týždenne prejsť vzorku výstupov, zapísať chyby a rozhodnúť, či sa zmenil pracovný postup. Ak to nikto nemá v pracovnej náplni, kontrola sa po prvom nadšení vytratí.

Druhým dôsledkom je zmena výpočtu návratnosti. Firma nemá počítať iba počet vygenerovaných odpovedí. Má porovnať čas do dokončenia, počet opráv, počet eskalácií, reklamácie a hodnotu práce, ktorú zamestnanec použil inde.

Rozdiel medzi slovenským a českým trhom tu nie je technologický. Bežná firma v oboch krajinách rieši rovnaký problém, má obmedzený počet ľudí a často nemá vlastný dátový tím. Rozdiel môže vzniknúť v právnom detaile, jazyku alebo konkrétnom regulovanom odvetví. Zdravotníctvo, financie a pracovné rozhodnutia preto treba posudzovať podľa miestnych pravidiel a podľa toho, kde firma pôsobí.

Pri slovenskom a českom jazyku treba navyše testovať lokálne formulácie. Model môže mať dobré skóre v angličtine a horšie rozlišovať odborné skratky, obchodné podmienky alebo právne výrazy v slovenčine a češtine. Pri zákazníckej podpore treba sledovať aj tón, vykávanie, diakritiku a schopnosť pracovať s miešaným jazykom. To nie je kozmetika. Nesprávne oslovenie neohrozí sklad, ale môže znížiť dôveru v značku.

Tretí dôsledok sa týka nákupu. Pri dodávateľovi sa pýtajte na export dát, zmenu modelu, uchovávanie konverzácií, audit log, dostupnosť oprávnení a cenu pri raste objemu. Cena pilotu môže byť nízka. Nákladom sa stane až údržba, keď dodávateľ zmení API, model alebo podmienky spracovania.

Do rozhodnutia patrí aj otázka, čo sa stane pri výpadku. Ak je AI iba pomocníkom pri návrhu odpovede, firma môže pokračovať ručne. Ak systém riadi príjem objednávok, musí existovať manuálny režim. Prevádzka bez záložného postupu je závislosť, nie efektivita.

V horizonte jedného týždňa sa dá zaviesť testovací súbor a manuálne porovnanie. V horizonte jedného mesiaca sa dá pridať dashboard s chybami, nákladmi a zásahmi človeka. Do jedného štvrťroka by firma mala vedieť, ktoré prípady môže automatizovať, ktoré iba asistovať a ktoré má nechať úplne na človeka.

Najväčšia výhoda malej firmy nie je rozpočet. Je to kratší rozhodovací reťazec. Kým veľká organizácia schvaľuje rámec AI governance, teda riadenia používania AI, menšia firma môže mať vlastný test, pravidlá prístupu a zodpovedného vlastníka hotové v priebehu niekoľkých dní.

Čo si o tom myslím a čo z toho plynie pre firmy

Názor

Za najväčšiu chybu považujem otázku, ktorý model je najlepší. Výskum o regresii po aktualizácii ukazuje, že neexistuje jednoduchý signál, ktorý by ochránil každý konkrétny firemný prípad. MIT dokázal vytvárať scenáre mimo historických záznamov, ale výsledok stále závisí od kvality vstupných dát a správnej interpretácie. Pri chatbotovej analýze sme videli opačný problém: systém dokázal nájsť relevantný zdroj, no nepomenoval jeho zaujatosť. Schopnosť bez kontextu nie je spoľahlivosť.

Preto by som firmám neodporúčal začínať veľkým AI projektom. Začal by som jednou úlohou, vlastným testovacím súborom a meraním pred nasadením. Ak dodávateľ nevie ukázať, ako sa systém správa pri chybe, neponúka hotový produkt, ale iba demonštráciu. A prezentácia nie je výsledok. Výsledok je proces, ktorý beží každý deň a firma ho vie sama skontrolovať.

Rovnako odmietam predstavu, že ľudská kontrola je iba dočasná barlička, ktorú treba čo najskôr odstrániť. Pri niektorých jednoduchých procesoch sa jej rozsah môže zmenšiť. Pri rozhodnutiach s právnym, finančným alebo bezpečnostným dopadom však zostane súčasťou systému. Automatizovať sa dá iba to, čo niekto vie opísať, otestovať a v prípade chyby vrátiť späť.

Dôsledok pre firmy

Praktická zmena sa týka troch ľudí. Vlastník procesu musí pomenovať, čo je správny výstup. IT alebo externý dodávateľ musí obmedziť prístupy a nastaviť logovanie. Používateľ musí mať jednoduchý spôsob, ako označiť chybu a vrátiť prípad človeku.

To nevyžaduje drahý dátový tím. Vyžaduje to disciplínu. Pri testovacom súbore firma rýchlo zistí, či AI šetrí čas, alebo iba presúva prácu do kontroly. Ak systém vytvorí viac opráv, než koľko ušetrí, nemá sa škálovať len preto, že je nový.

Rozhodovanie by malo mať tri brány. Najprv kvalita, teda či odpoveď spĺňa pravidlá. Potom ekonomika, teda či sa po započítaní kontroly oplatí. Nakoniec riziko, teda čo sa stane pri najhoršom rozumnom zlyhaní. Až keď prejdú všetky tri, môže automatizácia dostať širšie oprávnenia.

Tento prístup sa hodí pre slovenskú aj českú firmu, ktorá nemá veľký rozpočet ani dátových vedcov. Menší tím si nemôže dovoliť desať paralelných pilotov bez vlastníka. Môže si však dovoliť jeden test, týždeň merania a rozhodnutie založené na vlastných prípadoch. Práve to je často rýchlejšie než ďalší výber nástroja.

Pri každej automatizácii by som trval aj na odpovedi na tri nepríjemné otázky: Kto si všimne zhoršenie? Kto systém vypne? Kto rozhodne, či sa má opraviť alebo odstrániť? Ak na ne firma nevie odpovedať, problémom nie je nedostatok AI. Problémom je, že proces nemá vlastníka.

Výzva na AI implementáciu dňa

Do jedného týždňa nasaďte jednoduchý firemný eval set pre jednu AI úlohu. Vyberte 50 anonymizovaných prípadov z e-mailov, dokumentov alebo zákazníckej podpory. Ku každému napíšte správny výsledok, označte kritickú chybu a doplňte aspoň päť hraničných prípadov, pri ktorých má systém radšej požiadať o kontrolu človeka.

Nástroj môže byť obyčajná tabuľka s výstupmi z používaného modelu. Nemusí to byť nový softvér. Tento krok zoberie procesnému vlastníkovi časť ručného hádania a IT človeku neskoršie hasenie problémov. Za jeden pracovný deň ho vie pripraviť dvojica ľudí. Vyhodnotenie 50 prípadov zaberie približne 3 až 5 hodín.

Najčastejšie to padne na tom, že firma testuje umelé otázky namiesto reálnych prípadov alebo si vopred nedefinuje, čo znamená správna odpoveď. Vyberte dnes jednu úlohu a zajtra zmerajte prvých 50 výsledkov, kým sa z AI nestane ďalší projekt bez majiteľa.