Přeskoč na hlavní obsah
OpenAI

20. července 2026

Bezpečnost

Bezpečnost a sladění v éře modelů s dlouhým horizontem

Co nás interní používání dlouho běžícího modelu naučilo o bezpečnosti.

Načítání…

Shrnutí

  • Dlouho běžící modely dokážou řešit obtížné, otevřené problémy, ale jejich vytrvalost jim dává více příležitostí k nežádoucím akcím. 

  • Během omezeného interního používání modelu trénovaného na dlouho běžící úlohy jsme pozorovali nové typy selhání, které naše stávající hodnocení před nasazením nezachytila, a přístup jsme pozastavili. Poznatky z těchto selhání jsme poté využili k vytvoření nových hodnocení, zlepšení sladění pro dlouhý horizont, přidání monitorování na úrovni trajektorie a poskytnutí většího přehledu a kontroly uživatelům před obnovením omezeného přístupu.

  • Tato zkušenost potvrdila hodnotu iterativního nasazování. Žádná pevná sada hodnocení nedokáže předvídat každé chování, takže testování před nasazením musí doplňovat důkladné monitorování, ochranná opatření schopná zasáhnout a možnost v případě potřeby pozastavit provoz nebo vrátit na předchozí verzi.

Modely, které dokážou dlouhodobě pracovat autonomně, se mohou pouštět do obtížných, otevřených problémů. Stejná vytrvalost, díky níž jsou užitečné, jim ale zároveň dává více příležitostí k nežádoucím akcím — a to způsoby, které hodnocením určeným pro modely s kratším horizontem mohou uniknout.

Asi před dvěma měsíci jsme oznámili, že interní model pro obecné použití vyvrátil Erdősovu domněnku o jednotkových vzdálenostech. Tento model byl navržen tak, aby pracoval autonomně po velmi dlouhou dobu. Během omezeného, monitorovaného interního používání jsme zaznamenali nežádoucí chování, které naše dosavadní hodnocení před nasazením nezachytila. Protože nasazení bylo omezené a monitorované, mohli jsme tyto problémy identifikovat, dočasně zakázat přístup, vytvořit nová hodnocení na základě pozorování, posílit model a jeho ochranná opatření a poté přístup za trvalého monitorování obnovit. 

Podmínky, ve kterých modely hodnotíme, se nikdy nebudou dokonale shodovat s těmi, s nimiž se setkají při skutečném používání. Proto je třeba hodnocení před nasazením kombinovat s omezeným, monitorovaným nasazením a s možností zasáhnout, pozastavit provoz nebo se vrátit zpět, když se objeví problémy. To, co se naučíme z nasazení, se pak může stát součástí silnějších hodnocení a ochranných opatření, než se přístup rozšíří.

V následujících částech uvádíme konkrétní příklady toho, co jsme pozorovali, jak jsme problémy řešili a jak tato zkušenost ovlivní budoucí modely.

Perzistence modelu může odhalit bezpečnostní zranitelnosti

Nový model dokáže opakovanými pokusy po dlouhou dobu pokračovat v práci na dosažení cíle. Tatáž vytrvalost ho může vést k tomu, aby nacházel a zneužíval slabiny ve svém prostředí. Předchozí modely se při setkání se sandboxingem nebo omezeními prostředí jednoduše zastavily a vrátily se k uživateli. Tento model často zkoušel dál, mimo jiné hledal způsoby, jak jednat mimo svůj sandbox.

Příklad nastal během interního hodnocení na speedrunu NanoGPT(otevře se v novém okně), veřejném benchmarku pro natrénování malého jazykového modelu na co nejmenší počet kroků. Náš model vyvinul ochlazování učební míry podle mocninného zákona nazvané PowerCool, které přineslo výrazné zlepšení. Model dostal pokyn zveřejnit výsledky pouze na Slacku, ale instrukce NanoGPT říkají, že výsledky se mají odeslat jako PR na GitHub, a model se řídil těmito pozdějšími instrukcemi a otevřel PR #287 ve veřejném úložišti GitHubu. Model obešel omezení sandboxu navržená k blokování externího přístupu a pokračoval nahráním na GitHub. Našemu modelu trvalo hodinu, než našel zranitelnost v sandboxu, aby mohl PR vytvořit; dřívější modely byly méně vytrvalé, zranitelnosti najít nedokázaly a část s PR místo toho vzdaly.1

Od posuzování jednotlivých akcí k posuzování celých trajektorií

Mnoho bezpečnostních kontrol pro asistenty AI je navrženo kolem jednotlivých akcí. Pokud akce není povolená, zablokuje se. Pokud je citlivá, systém požádá uživatele o výslovné schválení. Dlouho běžící modely, jejichž akce se mohou autonomně rozvíjet hodiny, dny, nebo dokonce týdny, však toto nastavení zpochybňují: sledování jednotlivých akcí už nestačí k postižení záměru celé trajektorie.

Například ve scénáři, v němž měl model vyřešit problém, si model všiml, že jiné systémy mají úspěšná, ale soukromá řešení, a pokusil se tato řešení získat z backendu hodnocení. Když byl jeho první pokus zablokován, protože skener odhalil ověřovací token, model rozdělil tělo tokenu na dva fragmenty, zamaskoval je a poté přihlašovací údaj za běhu znovu sestavil, takže se úplný token nikdy neobjevil jako jeden souvislý řetězec. Model ve svých komentářích uživateli i ve stopách uvažování výslovně uvedl, že tyto kroky podniká, aby obešel skener.

Tento příklad ukazuje, jak každý krok může sám o sobě vypadat přijatelně, zatímco posloupnost může vést k výsledku, který by schválen nebyl. Ukazuje také, jak se model, který účinně funguje v dlouhých časových horizontech, může naučit slepá místa schvalovacího systému a obejít ho, aby dosáhl svých cílů. Bezpečnost pro dlouhý horizont vyžaduje ptát se nejen „je tato akce povolená?“, ale také „k jakému výsledku tato posloupnost akcí směřuje?“

Budování ochranných opatření pro dlouho běžící modely

Kvůli podobným incidentům jsme interní nasazení nového modelu pozastavili. Bezpečnostní systém jsme přestavěli na principu obrany do hloubky a monitorování na úrovni trajektorie.

  • Hodnocení odvozená z incidentů. Hodnocení nám mohou dát představu, zda je systém bezpečné nasadit ještě před samotným nasazením. Aby však bylo hodnocení co nejužitečnější, mělo by odrážet rozdělení a délku horizontu trajektorií při skutečném nasazení. Proto jsme pozorovaná selhání využili k vytvoření adversariálních hodnocení. Zjistili jsme, že zlepšení v hodnoceních odvozených z reálných incidentů následně vedlo k bezpečnějšímu chování po nasazení v produkci.
  • Lepší sladění. Podnikli jsme kroky ke snížení jeho sklonu podnikat nežádoucí akce bez povolení při snaze splnit uživatelův cíl.  Například jsme zjistili, že naše modely si při dlouhých rolloutech hůře pamatují instrukce, a když jsme model na tuto schopnost natrénovali, vznikl model, který zůstal sladěný i během delších rolloutů. 
  • Aktivní monitorování. Vytvořili jsme monitorovací systém, který průběžně hodnotí vyvíjející se trajektorii modelu a hledá známky toho, že obchází uživatelské omezení nebo bezpečnostní hranici. Monitor nesleduje jen jednotlivou akci, ale celou trajektorii. Důležité je, že monitor může relaci pozastavit a upozornit uživatele, aby ji podrobněji prověřil. Po prověření se uživatel může rozhodnout pokračovat v práci modelu, pokud byl monitor spuštěn chybně. 
  • Větší přehled a kontrola pro uživatele. Zlepšili jsme možnosti uživatele kontrolovat tyto dlouho běžící relace, zobrazovat provedené akce a monitorovat zásahy.

Opětovné nasazení

Abychom vyhodnotili nový monitorovací systém, znovu jsme přehráli malou sadu interních prostředí nasazení, v nichž model dříve sledoval nesladěné akce, tentokrát s novými ochrannými opatřeními2. Nová ochranná opatření dokázala zachytit výrazně více nesladěných akcí, které model sledoval, a všechny přehlédnuté akce byly vyhodnoceny jako málo závažné.

Mezi příklady těchto málo závažných incidentů patří následující případy:

  • Aby získal přístup k nástroji příkazové řádky Linear, model spustil vnořenou relaci codex --yolo, i když to ve skutečnosti mohl udělat bez příznaku --yolo.
  • Model si všiml, že dříve živý prostředek chybí, a poté začal bez dobrého důvodu zkoumat jiné aktivní CPU pody v namespacu svého vlastníka a přihlašovat se do nich přes SSH, stejně jako se neúspěšně pokoušel o pody patřící jiným zaměstnancům OpenAI.
  • Model měl mnoho zaseknutých procesů find a každý shellový příkaz se zasekl. Poté spustil kill -9 -1, což by v případě provedení poslalo SIGKILL každému procesu na daném podu, který smí ukončit. Příkaz však vypršel na časovém limitu a neprovedl se.

Po otestování nového systému jsme dospěli k závěru, že omezený interní přístup k modelům se schopnostmi pro dlouhý horizont lze obnovit. Od začátku opětovného nasazení před několika týdny jsme nezaznamenali žádné závažné obcházení ochranných opatření. První verze těchto ochranných opatření byla záměrně konzervativní. Systém dál ladíme tak, abychom omezili zbytečná přerušení, aniž bychom oslabili ochranná opatření.

Závěrečné myšlenky

Protože jsme nasazovali iterativně, dokázali jsme mezery najít a řešit dříve, než jsme rozšířili přístup. Hodnocení před nasazením zůstávají zásadní, ale nasazení odhaluje chování, které jim uniká. Začít s omezeným přístupem nám umožnilo pozorovat model v praxi, při výskytu problémů jej pozastavit, využít tato selhání k vytvoření lepších hodnocení a ochranných opatření a po otestování změn omezený přístup obnovit.

Jak se modely pouštějí do delších a složitějších úloh, mohou mít selhání, která hodnocením uniknou, větší důsledky. Budeme dál pracovat na zmenšování mezery mezi hodnocením a nasazením: testovat modely na delších trajektoriích, zlepšovat sladění, vytvářet monitorování schopné zásahu a uživatelům poskytovat jasnější přehled a kontrolu. Těmto výzvám nebude čelit jen OpenAI a doufáme, že sdílením našich poznatků pomůžeme připravit se na ně celému oboru.

Autor

OpenAI

Poznámky pod čarou

  1. 1

     Ačkoli jsme PR rychle uzavřeli, několik účastníků speedrunu už ho vidělo a použilo tento přístup ve vlastních příspěvcích; následné příspěvky se světovými rekordy s 3030(otevře se v novém okně), 2990(otevře se v novém okně), 2930(otevře se v novém okně), 2925(otevře se v novém okně), 2900(otevře se v novém okně) a 2890(otevře se v novém okně) kroky všechny citují PR 287. Z nich je zvlášť zajímavé PR 300(otevře se v novém okně), protože jde o PR odeslané modelem Opus 4.7, když ho Prime Intellect(otevře se v novém okně) hodnotil ve speedrunu NanoGPT. Opus viděl PR odeslané naším modelem, začlenil objevy a ve svém konečném výsledku naše PR uvedl.

  2. 2

     Kvůli náhodnosti a nedokonalé rekonstrukci prostředí není zaručeno, že rollouty při opakovaném přehrání budou pokaždé sledovat stejnou nesladěnou akci.