Preskočiť na hlavný obsah
OpenAI

28. septembra 2026

Bezpečnosť

K bezpečnostnej argumentácii pri tréningu prelomovej AI

Načítava sa…

Veríme, že vstupujeme do novej éry, v ktorej by sa pred pokračovaním akéhokoľvek tréningového behu prelomovej AI s učením posilňovaním mala vyžadovať štruktúrovaná bezpečnostná dokumentácia. V ideálnom prípade by takáto dokumentácia dosahovala úroveň „bezpečnostných argumentácií“ – komplexných, štruktúrovaných argumentov o riziku podložených dôkazmi, aké sa používajú v iných odvetviach, kde je bezpečnosť kritická. Bezpečnostné argumentácie vnímame ako ambiciózny cieľ, ku ktorému smerujeme. Zároveň si uvedomujeme, že zabezpečiť pri modeloch AI rovnakú dôslednosť ako v letectve či jadrovej energetike je náročné, pretože s každou novou úrovňou schopností AI sa objavuje nová komplexnosť. Pracujeme na rámci, ktorý tieto postupy formalizuje.

Nižšie uvádzame úvodné usmernenia, ktoré by podľa nás mali byť súčasťou takýchto bezpečnostných argumentácií pre tréning prelomovej AI. Tieto osvedčené postupy odrážajú naše súčasné poznatky a očakávame, že sa budú vyvíjať spolu s priebežným zdokonaľovaním interných procesov pre obozretný vývoj. Zverejňujeme ich už teraz, aby sme transparentne predstavili naše súčasné uvažovanie, a privítame spätnú väzbu od komunity. Upozorňujeme, že tento dokument sa zameriava na tréning prelomovej AI pomocou učenia posilňovaním. Interné aj externé nasadenie si vyžaduje zvážiť oveľa širší súbor vlastností súvisiacich so zosúladením.

1. Technické ochranné opatrenia

Bezpečnostné argumentácie by mali pokrývať tri aspekty technického systému: tréning na zosúladenie, izoláciu a monitorovanie. Tieto ochranné opatrenia pomáhajú zabezpečiť, aby sa model nepokúšal konať v rozpore s našimi zámermi. Aj keby sa o to pokúsil, malo by byť preňho náročné prelomiť izoláciu a monitorovanie by to malo zachytiť skôr, než by mohla vzniknúť škoda.

  • Zosúladenie modelu: Prvou líniou obrany by mal byť tréning modelov na zosúladenie, teda na to, aby spoľahlivo konali v súlade s našimi zámermi. Mohlo by to zahŕňať:

    • Tréningové prostredia a hodnotenie: Znižovať riziko vzniku nezosúladeného správania modelov tým, že sa počas tréningu zabráni pozitívnemu posilňovaniu zneužívania systému odmien. Mohlo by to zahŕňať:

      • Automatizované kontroly dátových súborov: Pomocou agentov vyhľadávať a opravovať chybné prostredia RL, v ktorých by nezosúladené postupnosti krokov mohli získavať vysokú odmenu zneužívaním chýb namiesto zamýšľaného správania. Tým sa obmedzia príležitosti na posilňovanie nesúladu počas tréningu.

      • Manuálne kontroly dátových súborov: Doplniť automatizovaný red teaming o manuálne kontroly dátových súborov a ich kvality s cieľom odhaliť chybné úlohy, ktoré by mohli neúmyselne posilňovať nezosúladené správanie.

      • Ladenie hodnotiacich systémov: Doladiť hodnotiace systémy tak, aby penalizovali pokusy modelu zneužívať chyby v prostrediach RL alebo tieto prostredia napádať počas tréningu.

      • Analýza predchádzajúcich behov: Použiť klasifikátory na záznamy z predchádzajúcich experimentov a overiť tak, či hodnotiace systémy fungujú podľa zámeru.

    • Meranie zosúladenia: Vykonávať hodnotenia, ktoré sledujú sklony modelu k nesúladu, a merať tak účinnosť tréningu na zosúladenie. Mohlo by to zahŕňať:

      • Offline hodnotenia zosúladenia: Počas tréningových behov prelomových modelov vykonávať hodnotenia zosúladenia na posúdenie, či tréning funguje podľa zámeru, a preskúmať každé výrazné zhoršenie.

      • Spätné testovanie: Spätne testovať hodnotenia zosúladenia na predchádzajúcich incidentoch a overiť tak, či odhalia modely, ktoré už vykazovali nesúlad, a či nie sú príliš prispôsobené konkrétnym incidentom.

      • Sledovanie obchádzania hodnotení: Sledovať povedomie o hodnotení alebo metaherné správanie (keď modely rozpoznajú, že sú testované), ktoré by mohli vyvolať zmenu správania. Napríklad pri hodnoteniach zosúladenia zapnúť monitorovanie povedomia o hodnotení a metaherného správania a stanoviť konkrétne prahové hodnoty na blokovanie.

      • Záťažové testy najhorších scenárov: Vyvolať najhoršie možné nežiaduce správanie a overiť, či by ho zachytilo aspoň jedno hodnotenie.

    • Zabránenie tréningu na reťazení myšlienok: Počas učenia posilňovaním neposkytovať automatizovaným hodnotiacim systémom prístup k reťazeniu myšlienok, aby sa modely nenaučili unikať monitorovaniu reťazenia myšlienok.

  • Izolácia: Zabezpečiť dostatočne silnú izoláciu v sandboxe a zabezpečenie, aby sa zabránilo škodlivým činnostiam v prípade, že sa model stane nezosúladeným. Mohlo by to zahŕňať:

    • Viacero vrstiev zabezpečenia infraštruktúry: Výrazne investovať do posilnenia zabezpečenia sandboxu, v ktorom model beží, aj výskumnej infraštruktúry, ktorá sandbox hostí. Tým sa zabezpečí ďalšia vrstva ochrany pre prípad úniku zo sandboxu.

    • Red teaming izolácie: Zlepšovať zabezpečenie sandboxu, výskumnej infraštruktúry a jej hraníc opakovaným red teamingom týchto systémov s využitím priebežne uložených verzií modelov z tréningových behov prelomovej AI. Tento postup má podliehať bezpečnostnej analýze a slúžiť na hľadanie a odstraňovanie medzier. Red teamingu podrobiť aj všetky služby, s ktorými by model mohol počas tréningu prísť do kontaktu (napr. internetovú vyrovnávaciu pamäť).

    • Komunikácia medzi vzorkami: Obmedziť vysokokapacitnú komunikáciu medzi vzorkami na schválené cesty, napríklad nástroje pre viacero agentov, a uzavrieť postranné kanály infraštruktúry, ktoré majú vysokú prenosovú kapacitu a agenti ich ľahko objavia.

    • Nemenné prepisy: Pri všetkých tréningoch RL, hodnoteniach a interných nasadeniach ukladať prepisy činnosti agentov v nezmeniteľnej podobe na primeraný čas (napríklad do úložných účtov s jednorazovým zápisom). To umožní spoľahlivé vyšetrovanie incidentov a zabráni neúmyselným úpravám.

  • Monitorovanie: Pre prípad, že modely začnú konať v rozpore s našimi zámermi, mať k dispozícii monitorovací systém v reálnom čase, ktorý zachytí potenciálny nesúlad a umožní rýchlo riešiť prioritné problémy skôr, než dôjde k závažnému incidentu. Mohlo by to zahŕňať:

    • Zabezpečenie monitorovateľnosti: Zabezpečiť, aby modely zostali monitorovateľné, a overovať to hodnoteniami monitorovateľnosti a obchádzania monitorovania s jasnými prahovými hodnotami, aby sa znepokojujúce správanie zachytilo včas.

    • Vysoká miera zachytenia známych problémov: Zabezpečiť, aby monitorovací systém pri hodnotení na vyčlenených dátach zachytil vysoký podiel minulých incidentov.

    • Aktuálnosť hodnotení monitorovacích systémov: Vytvárať hodnotiace príklady, ktoré reprezentujú úplne nové riziká nových behov, aby merania miery zachytenia a presnosti monitorovania nezastarávali.

    • Rýchla reakcia: Zaviesť prioritné upozornenia, ktoré povedú k zásahu v lehote stanovenej dohodou SLA, a to buď privolaním pracovníka pohotovostnej služby, alebo automatickým pozastavením dotknutého behu skôr, než model spôsobí škodu (napr. počas dňa pri incidentoch privolať bezpečnostnú pohotovostnú službu a osobu zodpovednú za beh a v noci pri nepotvrdených upozorneniach behy automaticky pozastaviť).

2. Prevádzkové usmernenia

Popri odporúčaniach k technickým ochranným opatreniam pracujeme aj na osvedčených prevádzkových postupoch pre bezpečnostné argumentácie k tréningovým behom prelomovej AI. Mohli by zahŕňať:

  • Oponentské stanoviská (analýzy možného zlyhania): Po vypracovaní návrhu bezpečnostnej argumentácie by mal člen iného tímu napísať oponentské stanovisko, ktoré odhalí možné medzery a poskytne primeraný odhad rizika. Tréningový tím by sa s ním mal následne vysporiadať, čím sa bezpečnostná argumentácia posilní.

  • Schvaľovanie: Bezpečnostnú argumentáciu by mali preskúmať členovia vrcholového vedenia, pričom každý z nich by mal mať možnosť tréningový beh vetovať. Tým sa zabezpečí viacero interných kontrol behu (napr. zo strany vedúceho výskumnej organizácie alebo viceprezidenta pre výskum, vedúceho bezpečnosti a hlavného vedeckého pracovníka).

  • Zodpovednosť: Člen vrcholového vedenia zodpovedný za tréningový beh (napr. vedúci výskumnej organizácie alebo viceprezident pre výskum) by mal niesť zodpovednosť za bezpečnostnú argumentáciu aj za reakciu na prípadné incidenty, a to aj v rámci hodnotenia pracovného výkonu. Aj tréningové tímy tak budú motivované presadzovať bezpečnosť a zosúladenie.

  • Pozastavenie: Pre prípad zistenia problémov, ktoré by spochybnili platnosť bezpečnostnej argumentácie (napr. nového bezpečnostného problému), treba zabezpečiť prevádzkové postupy, technické kontrolné mechanizmy a dohody o úrovni služieb (SLA) na pozastavenie všetkých dotknutých behov.

  • Interná transparentnosť: Bezpečnostné argumentácie by mali byť dostupné interným orgánom dohľadu (napr. Výboru pre bezpečnosť a ochranu).

  • Audity: Audítori by mali mať dostatočný prístup na overenie platnosti a podloženosti tvrdení v bezpečnostnej argumentácii a na upozornenie na zistené medzery.

  • Eskalácia: Mal by existovať jasný postup eskalácie problémov s nesúladom vrátane tabuľky definovaných úrovní závažnosti a pohotovostnej služby pre tieto problémy. Tá by mala vedieť privolať členov vedenia (napr. generálneho riaditeľa), keď beh dosiahne určitú úroveň závažnosti.

  • Technické kontrolné mechanizmy: Pre ľudí aj agentov by malo byť náročné spustiť behy, ktoré nespĺňajú požiadavky. Bezpečnostné funkcie, ako sú monitorovanie a automatické pozastavenie, by pri zlyhaní mali blokovať ďalšiu prevádzku (napr. by nemalo byť možné spustiť behy bez zapnutého náležitého monitorovania ani vypnúť monitorovací systém zvnútra tréningu RL, hodnotenia či interného nasadenia).

  • Možnosť vrátiť zmeny: Malo by byť jednoduché identifikovať všetky následné použitia nezosúladeného modelu v tréningovom procese (napríklad generovanie dát alebo hodnotenie), aby sa v prípade potreby dali zvrátiť účinky nezosúladených výstupov.

  • Úplnosť prehľadu zvyškových rizík: Bezpečnostné argumentácie by mali obsahovať čo najúplnejší zoznam zvyškových rizík, ktoré nepokrývajú aktuálne zavedené opatrenia na ich zmiernenie. To umožní informované rozhodovanie o prijatí rizika.

Toto sú naše súčasné odporúčania, ktoré v OpenAI práve zavádzame. Očakávame, že naše postupy sa budú v najbližších týždňoch ďalej vyvíjať.

3. Vyšetrovanie incidentov súvisiacich s nesúladom

Vyvíjame aj osvedčené postupy na vyšetrovanie závažných incidentov súvisiacich s nesúladom AI. Laboratóriá by sa mali snažiť z jednotlivých incidentov čo najviac poučiť (podobne ako pri vyšetrovacích postupoch⁠(otvorí sa v novom okne) v iných odvetviach, kde zlyhania majú vážne následky), aby im v budúcnosti dokázali predchádzať. Medzi takéto kroky by mohli patriť:

  • Interná transparentnosť: Keďže vyšetrovanie môže trvať dlho, mali by sa o jeho priebehu interne pravidelne zdieľať aktuálne informácie (napr. denné správy o prebiehajúcich vyšetrovaniach). Zamestnanci by mali mať stanovené postupy na získanie širšieho prístupu vrátane nespracovaných prepisov a generovania vzoriek výstupov nezosúladených modelov, ak je to bezpečné a relevantné pre ich prácu.

  • Koreňová príčina nesúladu: Výskumníci by mali identifikovať koreňové príčiny v dynamike tréningu (napr. cielenými ablačnými experimentmi alebo experimentmi s opakovaným vzorkovaním), aby pochopili, ako nezosúladené správanie vzniklo. Tým prehĺbia vedecké poznanie nesúladu a dokážu mu v budúcnosti lepšie predchádzať.

  • Spätná analýza incidentu: Mala by sa vykonať spätná analýza prevádzky a organizačnej kultúry s cieľom pochopiť všetky príčiny, ktoré prispeli k incidentu, napríklad prečo problémy vznikli a prečo ich pred incidentom nikto neodhalil alebo neeskaloval.

  • Detekcia: Mali by sme vyvíjať metódy testovania zosúladenia, ktoré dokážu odhaliť sklon spôsobiť daný incident, no bez priameho dolaďovania podľa informácií získaných z incidentu (napr. prepisov alebo súhrnov incidentu). Hodnotenia odvodené z incidentov by sa mali vytvárať ako „regresné testy“, aby sa zabezpečilo, že budúce modely nebudú vykazovať sklon k nesúladu pri veľmi podobných incidentoch.

  • Zverejňovanie informácií: Výsledky vyšetrovania, spätné analýzy incidentov a prevádzkové zmeny by sa po ukončení vyšetrovania mali sprístupniť verejnosti. Dotknuté tretie strany by mali byť informované čo najskôr.

Autor

OpenAI