Preskočite na glavno vsebino
OpenAI

28. september 2026

Varnost

Na poti k utemeljitvam varnosti za učenje prelomne umetne inteligence

Nalaganje …

Menimo, da vstopamo v novo obdobje, v katerem bi morala biti strukturirana varnostna dokumentacija obvezna pred nadaljevanjem vsakega cikla okrepljenega učenja prelomnih modelov. V idealnem primeru bi takšna dokumentacija dosegala raven »utemeljitev varnosti« – celovitih, strukturiranih in z dokazi podprtih argumentov o tveganju, kakršne uporabljajo v drugih panogah, kjer je varnost ključnega pomena. Utemeljitve varnosti so naš dolgoročni cilj, ki usmerja naše delo. Ob tem se zavedamo, kako zahtevno je pri modelih umetne inteligence doseči enako strogost kot v letalstvu ali jedrski energetiki, saj vsaka nova raven zmogljivosti umetne inteligence prinaša novo kompleksnost. Pripravljamo okvir, ki bo te prakse sistematično opredelil.

V nadaljevanju je nekaj začetnih smernic, ki bi po našem mnenju morale biti del takšnih utemeljitev varnosti za učenje prelomne umetne inteligence. Te dobre prakse odražajo naša dosedanja spoznanja. Pričakujemo, da se bodo razvijale, ko bomo še naprej izpopolnjevali notranje procese za skrben razvoj. Objavljamo jih že zdaj, da pregledno predstavimo svoj trenutni pogled in skupnost povabimo k podajanju povratnih informacij. Ta dokument se osredotoča na okrepljeno učenje prelomnih modelov; pri interni in zunanji uporabi je treba upoštevati precej širši nabor lastnosti, povezanih z usklajenostjo.

1. Tehnična varovala

Utemeljitve varnosti naj zajemajo tri vidike tehnološkega sklopa: učenje za usklajenost, omejevanje delovanja in spremljanje. Ta varovala pomagajo zagotavljati, da model ne poskuša delovati neusklajeno. Tudi če bi to poskusil, bi težko prebil omejitve, spremljanje pa bi to zaznalo, še preden bi lahko nastala škoda.

  • Usklajenost modela: Prva obrambna linija naj bo učenje modelov za usklajenost, torej za zanesljivo delovanje v skladu z našimi nameni. To bi lahko vključevalo:

    • Učna okolja in ocenjevanje: Zmanjšajte tveganje, da bi modeli razvili neusklajeno vedenje, tako da med učenjem preprečite pozitivno ojačevanje zlorab sistema nagrajevanja. To bi lahko vključevalo:

      • Samodejni pregledi podatkovnih zbirk: Z agenti poiščite in popravite pomanjkljiva okolja za okrepljeno učenje, v katerih bi lahko neusklajena zaporedja dejanj prejela visoko nagrado zaradi izkoriščanja ranljivosti namesto predvidenega vedenja. Tako zmanjšate možnosti za ojačevanje neusklajenosti med učenjem.

      • Ročni pregledi podatkovnih zbirk: Avtomatizirano simulirano iskanje šibkih točk v nadzorovanem okolju dopolnite z ročnimi pregledi in preverjanjem kakovosti podatkovnih zbirk, da prepoznate pomanjkljive naloge, ki bi lahko nenamerno ojačevale neusklajeno vedenje.

      • Prilagajanje ocenjevalnikov: Ocenjevalnike prilagodite tako, da med učenjem kaznujejo poskuse modela, da bi izkoristil ranljivosti v okoljih za okrepljeno učenje ali vanje vdrl.

      • Analiza preteklih ciklov: S klasifikatorji analizirajte sledi preteklih poskusov in preverite, ali ocenjevalniki delujejo po pričakovanjih.

    • Merjenje usklajenosti: Izvajajte evalvacije, ki spremljajo nagnjenost modela k neusklajenosti, da izmerite učinkovitost učenja za usklajenost. To bi lahko vključevalo:

      • Evalvacije usklajenosti zunaj živega delovanja: Med cikli učenja prelomnih modelov izvajajte evalvacije usklajenosti, da ocenite, ali učenje poteka po pričakovanjih, in raziščite vsa bistvena poslabšanja.

      • Preverjanje na preteklih primerih: Evalvacije usklajenosti preverite na preteklih incidentih, da potrdite, da zaznajo prej neusklajene modele in niso pretirano prilagojene posameznim incidentom.

      • Spremljanje izigravanja evalvacij: Spremljajte evalvacijsko zavedanje ali strateško izigravanje preizkusov (ko modeli prepoznajo, da jih preizkušajo), ki bi lahko povzročilo spremembo vedenja. Pri evalvacijah usklajenosti na primer vklopite spremljanje evalvacijskega zavedanja in izigravanja ter določite konkretne pragove za blokiranje.

      • Obremenitveni preizkusi najhujših scenarijev: Izzovite najhujše oblike neustreznega vedenja in preverite, ali bi ga zaznala vsaj ena evalvacija.

    • Preprečevanje učenja na podlagi verige sklepanja: Samodejnim ocenjevalnikom pri okrepljenem učenju ne omogočite vpogleda v verigo sklepanja, da se modeli ne bi naučili izogibati sistemom za spremljanje verige sklepanja.

  • Omejevanje delovanja: Izolacijo v peskovniku in varnost okrepite dovolj, da preprečita škodljiva dejanja, če model postane neusklajen. To bi lahko vključevalo:

    • Večplastna varnost infrastrukture: Veliko vlagajte v utrjevanje peskovnika, v katerem deluje model, in raziskovalne infrastrukture, ki gosti peskovnik, da zagotovite dodatno plast zaščite ob morebitnem pobegu iz peskovnika.

    • Simulirano iskanje šibkih točk v nadzorovanem okolju za preverjanje omejitev delovanja: Izboljšujte varnost peskovnika, raziskovalne infrastrukture in omrežnega oboda s ponavljajočim se simuliranim iskanjem šibkih točk v nadzorovanem okolju teh sistemov. Pri tem na podlagi varnostne analize uporabljajte shranjena vmesna stanja modelov iz ciklov učenja prelomnih modelov, da odkrijete in odpravite morebitne vrzeli. Preizkusom z namernim iskanjem šibkih točk podvrzite tudi vse storitve, s katerimi bi model med učenjem lahko prišel v stik (npr. spletni predpomnilnik).

    • Komunikacija med vzorci: Komunikacijo med vzorci z veliko pasovno širino omejite na odobrene poti, kot so orodja za več agentov, ter zaprite stranske kanale v infrastrukturi, ki imajo veliko pasovno širino in jih agenti zlahka odkrijejo.

    • Nespremenljivi prepisi: Prepise agentov za vse okrepljeno učenje, evalvacije in interno uporabo hranite razumno dolgo v nespremenljivi obliki (na primer v računih za shranjevanje z enkratnim zapisom), da omogočite zanesljivo preiskovanje incidentov in preprečite nenamerne spremembe.

  • Spremljanje: Za primer, da modeli začnejo delovati neusklajeno, vzpostavite sistem spremljanja v živo, ki bo zaznal morebitno neusklajenost in omogočil hitro obravnavo prednostnih težav, še preden bi lahko prišlo do resnega incidenta. To bi lahko vključevalo:

    • Zagotavljanje možnosti spremljanja: Zagotovite, da je modele še naprej mogoče spremljati. To merite z evalvacijami možnosti spremljanja in izogibanja spremljanju z jasno določenimi pragovi, da boste skrb vzbujajoče vedenje zaznali zgodaj.

    • Visok priklic pri znanih težavah: Zagotovite, da sistem spremljanja pri evalvaciji na ločenem testnem naboru zazna velik delež preteklih incidentov.

    • Ažurne evalvacije sistemov spremljanja: Za nove cikle pripravite evalvacijske primere, ki predstavljajo povsem nova tveganja, da meritve priklica in natančnosti sistemov spremljanja ne zastarajo.

    • Hiter odziv: Uvedite prednostna opozorila, ki sprožijo ukrepanje v roku, določenem v dogovoru o ravni storitve (SLA), bodisi z nujnim obvestilom dežurni osebi bodisi s samodejno začasno ustavitvijo prizadetega cikla, še preden model povzroči škodo. Podnevi na primer ob incidentih nujno obvestite dežurno varnostno osebo in odgovornega za cikel, ponoči pa cikle samodejno začasno ustavite, če prejem opozorila ni potrjen.

2. Operativne smernice

Poleg priporočil o tehničnih varovalih razvijamo tudi dobre operativne prakse za utemeljitve varnosti posameznih ciklov učenja prelomne umetne inteligence. Te bi lahko vključevale:

  • Ugovori (vnaprejšnje analize možnih neuspehov): Ko je osnutek utemeljitve varnosti pripravljen, naj član druge ekipe napiše ugovor, v katerem poišče morebitne vrzeli in poda stvarno oceno tveganja. Ekipa, odgovorna za učenje, naj nato te pomisleke obravnava in tako okrepi utemeljitev varnosti.

  • Odobritve: Utemeljitev varnosti naj pregledajo člani višjega vodstva, pri čemer naj ima vsak možnost preprečiti izvedbo cikla učenja. Tako se zagotovi več ravni notranjega preverjanja (npr. vodja raziskovalne organizacije oziroma podpredsednik za raziskave, vodja varnosti in glavni znanstvenik).

  • Odgovornost: Višji vodja, odgovoren za cikel učenja (npr. vodja raziskovalne organizacije oziroma podpredsednik za raziskave), naj odgovarja za utemeljitev varnosti in odzivanje na morebitne incidente, tudi v okviru ocenjevanja delovne uspešnosti. Tako bodo tudi ekipe, odgovorne za učenje, motivirane za zagotavljanje varnosti in usklajenosti.

  • Začasna ustavitev: Če se odkrijejo težave, ki bi ovrgle utemeljitev varnosti (npr. nova varnostna težava), naj bodo na voljo operativna navodila, tehnični nadzorni ukrepi in dogovori o ravni storitve (SLA) za začasno ustavitev vseh ciklov, ki jih utemeljitev zajema.

  • Notranja preglednost: Utemeljitve varnosti naj bodo dostopne notranjim nadzornim skupinam (npr. odboru za varnost in zaščito).

  • Revizije: Revizorjem naj se zagotovi zadosten dostop, da lahko preverijo veljavnost in utemeljenost trditev v utemeljitvi varnosti ter opozorijo na morebitne vrzeli.

  • Obveščanje pristojnih ravni: Obstaja naj jasen postopek za prijavo neusklajenosti višjim ravnem, s tabelo opredeljenih stopenj resnosti in dežurno osebo za neusklajenost, ki lahko nujno obvesti vodstvo (npr. glavnega izvršnega direktorja), ko cikel učenja doseže določeno stopnjo resnosti.

  • Tehnični nadzorni ukrepi: Ljudem in agentom naj bo otežen zagon ciklov učenja, ki niso skladni z zahtevami. Varnostne funkcije, kot sta spremljanje in samodejna začasna ustavitev, naj ob odpovedi blokirajo delovanje (npr. ciklov naj ne bo mogoče zagnati brez vklopljenega ustreznega spremljanja ali izklopiti sistema za spremljanje iz okolja za okrepljeno učenje, evalvacijo ali interno uporabo).

  • Možnost povrnitve stanja: V procesu učenja naj bo preprosto prepoznati vse nadaljnje uporabe neusklajenega modela (na primer za ustvarjanje podatkov ali ocenjevanje), da je po potrebi mogoče odpraviti učinke neusklajenih izhodnih podatkov.

  • Celovit pregled preostalih tveganj: Utemeljitve varnosti naj vsebujejo kar najbolj izčrpen seznam preostalih tveganj, ki jih trenutno uvedeni blažilni ukrepi ne obravnavajo, da omogočijo premišljene odločitve o sprejemanju tveganj.

To so naša trenutna priporočila, ki jih v OpenAI že uvajamo. Pričakujemo, da se bodo naše prakse v prihodnjih tednih še naprej razvijale.

3. Preiskovanje incidentov zaradi neusklajenosti

Razvijamo tudi dobre prakse za preiskovanje resnih incidentov zaradi neusklajenosti umetne inteligence. Raziskovalni laboratoriji naj si prizadevajo, da se iz posameznih incidentov naučijo čim več (podobno kot pri preiskovalnih praksah⁠(odpre se v novem oknu) v drugih panogah, kjer imajo napake lahko hude posledice), da bi takšne dogodke v prihodnje preprečili. Takšni ukrepi bi lahko vključevali:

  • Notranja preglednost: Ker lahko preiskave incidentov trajajo precej časa, naj se o njihovem poteku interno redno poroča (npr. dnevno pri preiskavah, ki še potekajo). Zaposleni naj imajo na voljo opredeljene postopke za pridobitev širšega dostopa, tudi do neobdelanih prepisov in vzorčenja izhodnih podatkov neusklajenih modelov, če je to varno in pomembno za njihovo delo.

  • Temeljni vzrok neusklajenosti: Raziskovalci naj raziščejo temeljne vzroke v dinamiki učenja (npr. s ciljnim izločanjem posameznih komponent ali poskusi ponovnega vzorčenja), da bi razumeli, kako se je pojavilo neusklajeno vedenje. Tako bodo izboljšali znanstveno razumevanje neusklajenosti in jo v prihodnje uspešneje preprečevali.

  • Naknadna analiza: Izvede naj se analiza operativnih vidikov in organizacijske kulture, da bi razumeli vse vzroke, ki so prispevali k incidentu, denimo zakaj so se težave pojavile in zakaj jih pred incidentom niso zaznali ali o njih obvestili višjih ravni.

  • Zaznavanje: Razviti moramo metode preizkušanja usklajenosti, ki lahko odkrijejo nagnjenost k povzročitvi takšnega incidenta, ne da bi jih neposredno optimizirali na podlagi informacij iz incidenta (npr. prepisov ali povzetkov incidenta). Evalvacije, ki izhajajo iz incidentov, naj se oblikujejo kot »regresijski testi«, da bodo prihodnji modeli pri zelo podobnih incidentih preverjeno brez nagnjenosti k neusklajenosti.

  • Javna razkritja: Po zaključku preiskave naj se rezultati, naknadne analize in operativne spremembe predstavijo javnosti. Prizadete tretje osebe naj se obvesti čim prej.

Avtorji

OpenAI