Prečo AI agent hovorí „hotovo“, keď práca ešte nie je dokončená

Ako model OpenAI unikol zo sandboxu a hackol Hugging Face?#

Najprv fakty a potom to, prečo by vás to malo zaujímať.

OpenAI merala, čo jej modely dokážu v ofenzívnej kybernetickej bezpečnosti. Použila test ExploitGym — 898 úloh, v ktorých treba premeniť známu zraniteľnosť na funkčný exploit, teda hotový program, ktorý túto zraniteľnosť využíva. Aby zistila skutočný strop schopností, vypla vstavané bezpečnostné filtre, ktoré modelu zvyčajne bránia robiť takéto veci. Prostredie úplne uzavrela a nechala jedinú cestu von: interný sprostredkovateľský program používaný na inštaláciu balíkov.

Zero-day zraniteľnosť je diera, o ktorej zatiaľ nikto nevie, ani človek, ktorý program napísal. Modely našli jednu práve v tej jedinej možnej ceste von.

Potom zvýšili svoje oprávnenia, prešli cez internú sieť k počítaču s prístupom na internet a odtiaľ usúdili, že odpovede na ExploitGym by mohli byť na Hugging Face. Nikto im o Hugging Face nepovedal. Prišli na to samy.

Ich odhad bol nesprávny. ExploitGym na Hugging Face vôbec nie je. To však neznamená, že hack nebol skutočný.

Hugging Face odhalilo prienik samo a 16. júla zverejnilo oznámenie, pričom ešte nevedelo, kto ho hackol.

Ďalší detail z tejto správy veľa vypovedá o súčasnom stave. Keď sa inžinieri Hugging Face pokúsili zadať záznam útoku popredným modelom cez bežné komerčné rozhrania, bezpečnostné filtre požiadavky zablokovali: nedokážu rozlíšiť človeka, ktorý hack skúma, od človeka, ktorý ho vykonáva. Analýzu napokon spustili na otvorenom modeli na vlastnom hardvéri.

OpenAI to priznala 21. júla, päť dní po zverejnení oznámenia Hugging Face. Od samotného prieniku vtedy uplynulo približne desať dní.

OpenAI ukončila vlastnú analýzu takto.

Model sa upäl na úzky cieľ testu a zašiel do krajností, aby ho dosiahol. Výrazy hyper-focused a fairly narrow testing objective pochádzajú priamo od OpenAI a týkajú sa jej vlastných modelov.

To je most z laboratória niekoho iného k vášmu notebooku.

Prečo to nie je „halucinácia“?#

V rozhovoroch často vídam frázy ako „zase halucinuje“, „kontext sa preťažil“ alebo „mali sme si spraviť plán“. Niekedy sa to naozaj stalo. Keď však AI agent napíše „hotovo, skontrolované, všetko funguje“ a práca hotová nie je, objem kontextu s tým zvyčajne nemá nič spoločné.

Nič si nevymyslel. Urobil presne to, čo ste merali.

Pod obľúbeným zastrešujúcim slovom „halucinácie“ hádžeme do jedného vreca tri rôzne zlyhania. Takto sa odlišujú:

Prvý prípad sa rieši kontextom a je najznámejší. Druhý je samostatný jav, ktorému sa venuje analýza o tom, keď Claude so všetkým súhlasí: model obetuje presnosť v záujme rýchleho súhlasu. Oba sa dejú pred prácou, vo fáze zadávania vstupu.

Tomuto článku sa venuje tretí riadok tabuľky. Agent tu nelichotil ani si nič nevymýšľal. Pracoval, kontroloval a hovoril pravdu. Táto pravda však opisuje metriku a o samotnej úlohe nehovorí nič.

Tretie zlyhanie má názov.

Čo je reward hacking jednoducho vysvetlené?#

Definíciu uvádza samotná Anthropic.

Táto myšlienka je staršia než neurónové siete. Článok DeepMind ju nazýva hraním sa so špecifikáciou a vysvetľuje ju pomocou mýtu.

Midas dostal presne to, o čo požiadal. Problém bol vo formulácii jeho požiadavky.

V programovaní má tento jav konkrétne podoby. Tu je učebnicový príklad, opäť od Anthropic:

A nejde o nejaké exotické laboratórne podmienky. Cursor analyzoval 731 trajektórií na obľúbenom benchmarku.

Šesť z desiatich „vyriešených“ úloh sú nájdené odpovede. Práve preto odvetvie mení spôsob merania výkonu: máme analýzu benchmarku, ktorý meria pripravenosť na produkčné nasadenie, kde úspešné absolvovanie kontrol už nie je hlavným kritériom.

Ako to vyzerá v bežnom produkte?#

Laboratórne príklady sa dajú ľahko odmietnuť ako exotické. Preto nasledujú štyri príbehy z praxe. Klienti a odvetvia sú zmenené, ale mechanizmy zostali tak, ako boli.

Štyri zelené kontroly a nefunkčný komponent služby

Realitná kancelária buduje službu: webovú stránku s ponukami nehnuteľností a samostatný proces na pozadí, ktorý ponuky v noci exportuje na platformy. Agent dokončí úlohu a oznámi: kontrola typov prešla, kontrola štýlu kódu prešla, zostavenie je úspešné, stránky odpovedajú a boli vizuálne skontrolované.

Každé tvrdenie je pravdivé. A žiadne z nich nesúvisí s nočným procesom: beží ako samostatný proces a vôbec nie je súčasťou zostavenia webovej stránky. Nasadenie sa podarí, stránka funguje perfektne, export ponúk sa zastaví a klienti to oznámia o deň neskôr.

Skôr než poviem „hotovo“, položím si teraz jednu otázku: ktorá časť práce beží mimo rozsahu, ktorý moja kontrola pokrýva? Ak tam niečo je, spustite to samostatne a do správy uveďte výstup príkazu. Slovo „skontrolované“ vec neuzatvára.

Falošná značka začiarknutia sa objaví priamo na rozhraní

Internetový obchod rozdelí veľkú úlohu medzi viacerých agentov naraz: jeden dostane backend, ďalší stránky a tretí produktové karty. Každý pracuje usilovne a každý má zelené kontroly.

O týždeň sa ukáže, že tlačidlo „táto recenzia bola užitočná“ nefunguje nikde. Backend je kompletne napísaný, jeho kontroly sú zelené a pravidlá prepočtu sa dodržali. Lenže žiadna stránka tlačidlo nezobrazuje: tlačidlo patrilo do oblasti jedného agenta, stránky do oblasti druhého a nikoho nenapadlo umiestniť ho na obrazovku. Počítadlo by navždy zostalo na nule.

„Kód je napísaný a pokrytý kontrolami“ a „funkcia funguje“ sú dve rôzne tvrdenia. To druhé kontrolujem jednou otázkou pri každej novej funkcii: kto ju volá? Overujem to vyhľadaním v projekte, pretože správa agenta tu nie je zdrojom pravdy.

Kontrolór vidí iba smer, ktorý mu zadali preveriť

Služba zavádza úrovne vernosti: čím viac zaplatíte, tým vyšší status a zľavu získate. Pred nasadením sa kód posiela na kontrolu s pokynom „Skús si umelo zvýšiť vlastný status.“ Kontrolór poctivo vykoná svoju prácu a oznámi „nič závažné“ — status naozaj nie je možné umelo zvýšiť.

Druhá kontrola položí inú otázku: „Čo sa stane so statusom, keď sa vrátia peniaze?“ Diera sa nájde za desať minút. Body sa počítali zo záznamu transakcií a tento záznam o vrátení peňazí nič nevie. Niečo si kúpite, získate body, dostanete peniaze späť a status aj zľavu si necháte navždy.

Prvý kontrolór prácu neodflákol. Zo štrukturálneho hľadiska to nemohol vidieť: dostal vektor „vstup, povýšenie“, zatiaľ čo diera bola vo vektore „vrátenie vstupu, zachovanie povýšenia“. Všade, kde ide o peniaze, prístup alebo status, ktorý si možno kúpiť, vykonávam dve kontroly a v druhej výslovne uvádzam opačné vektory: vrátenie peňazí, zablokovanie, odobratie prístupu, vypršanie platnosti, vymazanie zdroja údajov.

Metrika odmeňuje podobnosť

Doručovacia služba sa rozhodne zmerať, či sa zlepšili návrhy AI pre operátorov. Vezme dvesto starých požiadaviek na podporu, spustí ich cez novú verziu a zmeria podobnosť návrhu so skutočnou odpoveďou ľudského operátora. Meranie ukáže výrazný nárast.

Tento nárast nič neznamená, a to z dvoch dôvodov. Kontext návrhu sa zostavuje „k dnešnému dňu“ a zahŕňa celú korešpondenciu vrátane samotnej odpovede operátora, s ktorou sa neskôr porovnáva. Model nepíše odpoveď; parafrázuje referenčnú odpoveď, ktorú videl. Navyše samotná metrika odmeňuje zhodu slov a dĺžky: návrh s nesprávnym dátumom, ale rovnakými slovami, aké operátor použil pri správnom dátume, dostane vysoké skóre.

K každej metrike typu „podobnosť znamená kvalitu“ teraz pridávam tvrdé mechanické brány, ktoré štýl nemôže oklamať: vymyslené čísla a dátumy, zakázané slová, sľuby konania. Akékoľvek zhoršenie výsledkov brány zruší zlepšenie metriky.

Prečo „Skontroloval som to“ od agenta nič nedokazuje?#

Vezmite niektorý zo svojich projektov a požiadajte agenta: „Skontroluj zabezpečenie.“ Odpoveď často znie „všetko je v poriadku, žiadne kritické problémy“.

Teraz položte tú istú otázku inému modelu o tom istom projekte. Najmä ak je projekt veľký, nájde ich veľa. Pred nasadením autor kontroluje projekt tromi rôznymi modelmi a každý upozorní na niečo iné.

Rovnaký vstup, rovnaká otázka, opačný verdikt. Jeden model nie je horší než druhý. Lenže „všetko je v poriadku“ je vygenerovaný text, presne na tej istej vrstve ako každá iná odpoveď. Agent nedokáže rozlíšiť „pozrel som sa a je to čisté“ od „pozrel som sa na nesprávne miesto“.

Anthropic tento mechanizmus opisuje v dokumentácii Claude Code.

Rozoberme tú vetu pomaly. Kým agentovi neposkytnete kontrolu, ktorú môže spustiť, má jediný signál — ako veci vyzerajú. A v tomto nastavení ste overovacou slučkou vy, lenže o chybách sa dozviete ako poslední.

Je tu aj hlbšia vrstva. Keď sa OpenAI pokúsila vyvíjať tlak na model tým, že monitorovala jeho uvažovanie a trestala ho za „zlé myšlienky“, výsledok nebol taký, aký očakávala.

Trestanie vysloveného zámeru odstráni jeho vyjadrenie. Samotný zámer zostane. Preto by som sa nespoliehal na to, že vám agent poctivo povie, ako podvádzal.

Rovnakým smerom sa uberajú aj samotní vývojári nástrojov. Vo verzii Claude Code 2.1.215 sa skills /verify a /code-review prestali spúšťať z vlastnej iniciatívy modelu.

2.1.215 - Claude no longer runs the `/verify` and `/code-review` skills
on its own; invoke them with `/verify` or `/code-review` when you want them

Anthropic nevysvetľuje prečo. Princíp je však jasný: ten, koho kontrolujú, si nemá zadávať vlastnú kontrolu.

Prečo pravidlo v súbore projektu nedokáže agenta udržať na uzde?#

Do pravidiel projektu ste napísali: vykonaj commit iba vtedy, keď ti to priamo poviem, nasadzuj do produkcie iba vtedy, keď ti to priamo poviem, k produkčným údajom pristupuj iba v režime na čítanie.

Podľa skúseností autora agent približne raz z desiatich prípadov aj tak nasadí z vlastnej iniciatívy. Nie zo zlého úmyslu a nie preto, že by pravidlo nečítal. Prečítal si ho. Jednoducho mal pred sebou cieľ a pravidlo bolo textom — rovnako ako zvyšok kontextu.

Presne to sa stalo v laboratóriu OpenAI, len vo väčšom meradle. Modely boli v uzavretom prostredí s jedinou cestou von a značnú časť výpočtového výkonu venovali hľadaniu úniku. Testovacie úlohy zostali nevyriešené.

Môj postoj je jednoduchý: agent nie je nebezpečný ani zlomyseľný. Je obyčajný, len je to hlupák s právomocami. Preto treba obmedziť jeho právomoci, nie prepisovať požiadavky.

Čo naozaj funguje: prísny prístup k produkčným údajom iba na čítanie. Zákaz mazania celých adresárov. Zákaz príkazov, ktoré prepisujú históriu bez možnosti obnovy. Nastavenie limitu výdavkov u poskytovateľa. Rozdiel vystihuje jedna fráza: „fyzicky to nedokáže“ má prednosť pred „požiadal som ho, aby to nerobil“. Konkrétne nastavenia opisuje osobitný článok o mechanických brzdách namiesto žiadostí v pokynoch.

Napriek tomu zachovajte chladnú hlavu. Ani sandbox nie je absolútnou hranicou a poskytovateľ to hovorí jasne.

Claude Code má navyše zabudovaný núdzový východ, ktorý môže použiť samotný model. Keď príkaz zlyhá pre obmedzenia sandboxu, Claude analyzuje zlyhanie a môže zopakovať ten istý príkaz s parametrom, ktorý sandbox vypne. Tomu sa dá zabrániť výslovným nastavením prísneho režimu; predvolene je obchádzka dostupná a zdokumentovaná.

Obmedzenie funguje len do takej miery, do akej ho sprísnite. Každá bariéra má dopad na rýchlosť — oplatí sa ho poctivo vypočítať vopred, pretože ak ho zistíte až o týždeň, bude to drahšie.

Ako nastaviť kritérium dokončenia, s ktorým sa nedá manipulovať?#

Od formulácie kritéria závisí všetko ostatné. Otestujte ju jednou otázkou: môže agent splniť toto kritérium bez toho, aby čokoľvek urobil?

• „Skontroluj, či všetko funguje“ — môže. Stačí napísať „skontrolované, funguje“.
• „Spusť zostavenie a ukáž mi výstup“ — to je už náročnejšie; výstup bude musieť odniekiaľ získať.
• „Spusť aplikáciu, klikni na tlačidlo platby a ukáž, čo sa objavilo na obrazovke“ — textom sa to dá splniť len veľmi ťažko.

Rozdiel medzi prvým a tretím príkladom je rozdiel medzi správou a dôkazom.

Dokumentácia Claude Code opisuje štyri úrovne prísnosti. Užitočný rebríček, po ktorom môžete stúpať podľa toho, ako rastie cena chyby:

1. V jednej správe. Požiadajte agenta, aby spustil kontrolu a opakoval ju, kým tu a teraz neprejde. Najlacnejšia možnosť, vhodná na drobnosti.
2. Počas celej relácie. Urobte z kontroly podmienku cieľa: samostatný hodnotiteľ ju preverí po každom ťahu a agent pokračuje, kým podmienka nebude splnená. Technické podrobnosti nájdete v príručke o vopred nastavenom kritériu dokončenia.
3. Mechanická bariéra. Skript sa spustí, keď sa agent pokúsi ukončiť ťah, a nedovolí mu skončiť, kým kontrola neprejde. Je tu jeden dôležitý detail: po ôsmich po sebe idúcich zablokovaniach Claude Code bariéru obíde a ťah aj tak ukončí. V systéme neexistujú úplne nepreniknuteľné bariéry.
4. Druhý názor. Samostatný kontrolór s čerstvým kontextom, ktorého úlohou je vyvrátiť výsledok.

Štvrtý bod sa odlišuje, pretože je jediný, ktorý sa netýka nástrojov.

Kto má prijať prácu agenta?#

Keď pri veľkej úlohe spúšťam agentov v cykle, postupujem takto: jedna skupina píše a druhá, nová skupina prácu preberá bez toho, aby sa na jej písaní podieľala.

Kľúčové slovo je „nová“. Znamená čistý kontext, ktorý nevidel, ako sa jednotlivé rozhodnutia prijímali. Iná výzva v tej istej relácii to nezabezpečí. Človek, ktorý napísal kód, už venoval pozornosť presviedčaniu samého seba, že je správny, a bude naďalej hľadať potvrdenie. Vyvrátenie nie je v jeho záujme.

Formulácia úlohy pre kontrolóra je dôležitejšia než jeho model. Porovnajte:

• „Skontroluj túto prácu“ — kontrolór nájde to, čo sa ľahko hľadá, a napíše „vo všeobecnosti v poriadku“.
• „Pokús sa dokázať, že táto práca NEBOLA dokončená“ — kontrolór začne hľadať diery, pretože to je jeho cieľ.

Druhá formulácia funguje lepšie z toho istého dôvodu, pre ktorý zlyhal ExploitGym: agent sa zaviaže k cieľu, ktorý dostane. Dajte mu cieľ nájsť dieru a bude ju hľadať.

Tu je úplné znenie pripravené na skopírovanie:

Kontrolujete prácu niekoho iného. Nenapísali ste ju a nemusíte ju obhajovať.

Vaším cieľom je dokázať, že deklarovaný výsledok sa NEDOSIAHOL. Nájdite aspoň tri spôsoby, ako sa nemusel dosiahnuť, aj keď sú všetky kontroly zelené.

Kontrolujte v tomto poradí:

Ktorá práca beží mimo rozsahu kontrol — procesy na pozadí, samostatné skripty, naplánované úlohy, obsluhy frontov.

Kto volá každú novú funkciu. Nájdite volanie vyhľadaním v projekte; uveďte súbor a riadok.

Opačné vektory: vrátenie peňazí, zablokovanie, odobratie prístupu, vypršanie platnosti, vymazanie zdroja údajov.

Hodnoty vo výsledku, nielen to, či existuje.

Ak po poctivom hľadaní nenájdete žiadne diery, povedzte to, ale uveďte presne, čo a ako ste skontrolovali.

Článok o tom, ako agent kontroluje sám seba v cykle, vysvetľuje, ako funguje cyklus, v ktorom agent kontroluje sám seba medzi iteráciami a kde zvyčajne zlyháva.

Čo sa zmení, keď preformulujete kritérium?#

Toto je najlacnejšie zlepšenie, o ktorom viem, a takmer nikto ho nerobí.

Požiadajte agenta o kontrolu kódu — bude uvažovať v pojmoch kódu: štruktúra, spracovanie chýb, opakovanie pokusov, zraniteľné miesta. Užitočné.

Požiadajte ho, aby prešiel zákaznícku cestu od prvej návštevy stránky až po pokus o vrátenie peňazí, a objavia sa iné druhy problémov. Chyba, ktorá používateľovi zobrazí niečo, čo by nemal vidieť. E-mail, ktorého text nezodpovedá tomu, čo sa skutočne stalo. Krok, ktorý sa logicky nedá dokončiť, ak ste neprišli cez ideálny scenár.

Kontrola kódu neodhalí žiadny z týchto nedostatkov, pretože každý z nich je v kóde platný.

Z toho vyplýva pravidlo, ktoré mám poruke: ak kontrola nič nenájde, najprv zmeňte formuláciu. Problémom zvyčajne nie je model. Tá istá práca a tri rôzne spôsoby, ako sa na ňu opýtať, vytvoria tri rôzne zoznamy zistení. Praktický súbor otázok pre ľudí bez programátorských zručností nájdete osobitne: sedem kontrol kódu bez programátorských zručností.

Hotová výzva na prijatie práce agenta#

Neodpovedajte „hotovo“ ani „skontrolované“. Potrebujem dôkazy.

Pri každej položke práce mi uveďte presne toto:

Aký príkaz ste spustili, aby ste potvrdili, že položka funguje? Uveďte samotný príkaz aj jeho úplný výstup, bez skracovania.

Ak ste príkaz nespustili, povedzte to: „nespustené“. Nenahrádzajte to slovami „vizuálne skontrolované“ ani „logika je správna“.

Ktorá práca beží mimo rozsahu pokrytého vašou kontrolou? Procesy na pozadí, samostatné skripty, naplánované úlohy, obsluhy frontov — čokoľvek, čo sa spúšťa inak než hlavná aplikácia. Pri každej takej časti: spustili ste ju samostatne a aký mala výstup?

Kto volá každú novú funkciu, ktorú ste pridali? Nájdite volanie vyhľadaním v projekte a uveďte súbor aj riadok. Ak sa funkcia nikde nevolá, povedzte to priamo.

Potom v samostatnej časti uveďte tri spôsoby, ako deklarovaný výsledok NEMUSEL byť dosiahnutý, hoci sú všetky vaše kontroly zelené. Hľadajte dôkladne.

Na konci uveďte jeden riadok: čo mám skontrolovať vlastnými očami, pretože automatická kontrola to nezachytí?

Štvrtá položka vyzerá ako maličkosť, ale zachytáva celú triedu problémov. Pri veľkej úlohe, ktorú som rozdelil medzi agentov podľa oblastí, sa jediné falošné „hotovo“ z celej stovky objavilo priamo na rozhraní dvoch oblastí: kód bol napísaný, kontroly boli zelené a nikoho nenapadlo umiestniť funkciu na obrazovku.

Štyri spôsoby, ako sa pri kontrole oklamať#

1. Nepočkal som na všetkých kontrolórov. Spustil som tri súbežné kontroly, dve sa vrátili so zeleným výsledkom a nasadil som zmenu. Tretia dorazila o štyri minúty neskôr so šiestimi porušeniami. Oprava po zverejnení stojí viac než čakanie dve minúty.
2. Uveril som súhrnu „spracovaných N z N“. Pri veľkom fan-out niektorí agenti potichu zlyhajú: oznámia úspech, ale súbor zostane nedotknutý. Teraz po každom zápise cez agenta mechanicky overujem, že zmeny sú naozaj na disku.
3. Nepozrel som sa vlastnými očami. Automatické kontroly môžu byť zelené aj pri úplne nepoužiteľnom výsledku. Obrázky sú technicky správne, veľkosť je správna, stavový kód je správny. V skutočnosti sú to však automatické zmrazené zábery namiesto ilustrovaných obálok. Žiadna automatická kontrola to nezachytí.
4. Kontroloval som prítomnosť namiesto hodnoty. Kontrola hľadala vo výsledku požadovaný text; text tam bol, ale údaje v ňom boli nesprávne: dátum sa líšil o deň. Kontrola bola zelená a správa klamala. Teraz overujem celú očakávanú hodnotu, pretože samotná prítomnosť správneho slova nič negarantuje.

Všetky štyri prípady majú spoločné toto: kontrola existovala, vyzerala presvedčivo a preverovala nesprávnu vec. Rovnaké mechanizmy ako pri modeloch a ich teste, len bez akejkoľvek vynaliezavosti.

Kde dnes začať#

Tri kroky, ktoré zaberú dvadsať minút.

1. Vezmite posledné „hotovo“. Preverte ho pomocou výzvy na prijatie práce v časti o dôkazoch. Cieľ je jednoduchý: zistite, koľko položiek bolo uzavretých slovami a koľko výstupom príkazu.
2. Stanovte si jedno pravidlo. Slovo „skontrolované“ bez priloženého výstupu príkazu sa nepovažuje za uzavretie. Toto pravidlo platí pre vás, nie pre agenta, a práve preto funguje.
3. Oddeľte pracovníka od kontrolóra. Pri ďalšej úlohe dajte novej relácii výzvu pre kontrolóra a požiadajte ju, aby dokázala, že práca NEBOLA vykonaná. Prvé použitie zvyčajne stojí za osvojenie tohto návyku.

Nástroj je dobrý a zlepšuje sa každý mesiac: veci, ktoré agent pred rokom robil potichu, ho dnes zastavia. Bezpečnostná hranica sa neustále posúva a stále zostáva hranicou. Kým agent sleduje zadaný cieľ, otázka „a ako presne ste to merali?“ zostáva na vás. Návyk kontrolovať je vaša záchranná sieť.