Vandaag brengen we een onderzoekspreview uit van gpt-oss-safeguard, onze open-weight redeneringsmodellen voor veiligheidsclassificatietaken, beschikbaar in twee indelingen: gpt-oss-safeguard-120b en gpt-oss-safeguard-20b. Deze modellen zijn geoptimaliseerde versies van onze open gpt-oss-modellen en zijn beschikbaar onder dezelfde permissieve Apache 2.0-licentie. Dit betekent dat iedereen vrij is om deze modellen te gebruiken, wijzigen en implementeren. Beide modellen kunnen vandaag worden gedownload van Hugging Face(opent in een nieuw venster).
De gpt-oss-safeguard-modellen gebruiken redeneringen om een door de ontwikkelaar verstrekt beleid direct op het moment van inferentie te interpreteren. Daarbij worden gebruikersberichten, aanvullingen en volledige chats geclassificeerd volgens de behoeften van de ontwikkelaar. De ontwikkelaar bepaalt altijd welk beleid wordt gebruikt, zodat reacties relevanter zijn en beter aansluiten bij de usecase van de ontwikkelaar. Het model maakt gebruik van Chain-of-Thought, die de ontwikkelaar kan bekijken om na te gaan hoe het model tot beslissingen komt. Bovendien wordt het beleid tijdens de inferentie verstrekt, in plaats van in het model te worden getraind. Ontwikkelaars kunnen het beleid dus gemakkelijk iteratief herzien om de prestaties te verbeteren. Deze aanpak, die we aanvankelijk voor intern gebruik hebben ontwikkeld, is aanzienlijk flexibeler dan de traditionele methode waarbij een classifier wordt getraind om indirect een beslissingsgrens af te leiden uit een groot aantal gelabelde voorbeelden.
Met gpt-oss-safeguard kunnen ontwikkelaars de beleidsregels opstellen die het beste bij hun usecase passen. In een discussieforum over videogames kan bijvoorbeeld een beleid worden ontwikkeld om berichten te classificeren waarin valsspelen in de game wordt besproken. Of een website met productrecensies kan een eigen beleid gebruiken om recensies te screenen die waarschijnlijk nep zijn.
Het model verwerkt twee soorten invoer tegelijk: een beleid en de inhoud die onder dat beleid moet worden geclassificeerd. Vervolgens geeft het een conclusie over waar de inhoud thuishoort, samen met de achterliggende redenering. Ontwikkelaars beslissen zelf hoe ze deze conclusies al dan niet gebruiken in hun eigen veiligheidspijplijnen. We hebben gezien dat deze aanpak op basis van redenering uitermate goed in werkt in situaties waarin het volgende speelt:
- De potentiële schade is in opkomst of ontwikkeling, en het beleid moet zich snel aanpassen.
- Het domein is zeer genuanceerd en is moeilijk te verwerken voor kleinere classifiers.
- Ontwikkelaars hebben onvoldoende voorbeelden om een hoogwaardig classifier voor elk risico op hun platform te trainen.
- Latentie is minder belangrijk dan het produceren van hoogwaardige, verklaarbare labels.
We brengen deze preview van gpt-oss-safeguard uit om feedback te krijgen van de onderzoeks- en veiligheidscommunity en om de modelprestaties verder iteratief te verbeteren. Maandenlang hebben we samen met ROOST(opent in een nieuw venster) aan deze open-weight release gewerkt om de kritieke behoeften van ontwikkelaars in kaart te brengen, het model te testen en documentatie voor ontwikkelaars te maken. Als onderdeel van deze lancering zal ROOST een modelcommunity(opent in een nieuw venster) oprichten, die vandaag ook van start gaat, om open AI-modellen te onderzoeken ter bescherming van online ruimten. Naast deze release publiceren we een kort technisch rapport met gedetailleerde informatie over de veiligheidsprestaties van dit previewmodel.
Als het om veiligheid gaat, geloven wij in diepgaande verdediging. We trainen onze modellen om veilig te reageren en we implementeren extra beschermingslagen om potentieel onveilige invoer en uitvoer te detecteren en aan te pakken in overeenstemming met onze beleidsregels. Veiligheidsclassifiers waarmee onderscheid wordt gemaakt tussen veilige en onveilige inhoud in een bepaald risicogebied, vormen al lang een primaire verdedigingslaag voor onze eigen en andere grote taalmodellen.
Traditionele veiligheidsclassifiers zoals die beschikbaar zijn via onze Moderation API(opent in een nieuw venster), worden ontwikkeld door handmatig duizenden voorbeelden van veilige en onveilige inhoud te selecteren, op basis van vooraf gedefinieerde veiligheidsbeleidsregels. Aan de hand van deze trainingsgegevens leert de classifier om onderscheid te maken tussen veilige en onveilige uitvoer. Bij deze traditionele methode krijgt de classifier het veiligheidsbeleid nooit daadwerkelijk te zien. In plaats daarvan probeert de classifier het onderliggende beleid af te leiden dat is gebruikt om de voorbeelden te labelen. Hiervoor zoekt het naar overeenkomsten in de inhoud die als onveilig is gelabeld, en naar verschillen tussen de onveilige en veilige inhoud.
Traditionele classifiers kunnen zeer goed presteren, met een lage latentie en lage operationele kosten. Maar het verzamelen van voldoende trainingsvoorbeelden kan tijdrovend en kostbaar zijn, en wanneer het beleid is bijgewerkt of gewijzigd, moet de classifier opnieuw worden getraind.
gpt-oss-safeguard is anders omdat ontwikkelaars dankzij het redeneringsvermogen ervan elk willekeurig beleid kunnen toepassen, ook beleid dat ze zelf schrijven of dat uit andere bronnen afkomstig is, en omdat de modellen met behulp van redenering nieuw geschreven beleidsregels kunnen generaliseren. Naast veiligheidsbeleidsregels kan gpt-oss-safeguard worden gebruikt om inhoud te labelen op andere manieren die belangrijk zijn voor specifieke producten en platforms.
Onze primaire redeneringsmodellen leren nu rechtstreeks onze veiligheidsbeleidsregels en gebruiken hun redeneringsvermogen om te redeneren over wat veilig is. Deze aanpak, die we deliberative alignment noemen, is een aanzienlijke verbetering ten opzichte van eerdere veiligheidstrainingsmethoden, en maakt onze redeneringsmodellen op verschillende vlakken veiliger dan hun niet-redenerende voorgangers, zelfs als het vermogen ervan toeneemt. Maar redeneren is niet alleen nuttig voor het trainen van de modellen zelf. Het creëert ook nieuwe mogelijkheden voor diepgaande verdediging. Een aanpak op basis van redenering is flexibeler en minder beperkt door de gegevens van de eerdere training. Dit zijn voordelen die soms de extra rekenkosten en latentie die het met zich meebrengt, meer dan rechtvaardigen.
gpt-oss-safeguard is een open-weight implementatie van een aanpak die we intern hebben ontwikkeld, in een tool die we Safety Reasoner noemen. We zijn begonnen met het optimaliseren van de versterking bij het labelen van beleidsregels, waarbij het model werd beloond voor het weerspiegelen van correcte beoordelingen van menselijke experts. Hierdoor leerde het model te redeneren over hoe het beleid tot het oordeel heeft geleid. Tegenwoordig stelt Safety Reasoner ons in staat om onze veiligheidsbeleidsregels in productie dynamisch bij te werken in minder tijd dan nodig zou zijn om een classifier opnieuw te trainen. Dit maakt Safety Reasoner een belangrijke tool voor iteratieve implementatie: wanneer we nieuwe modellen in productie implementeren, beginnen we vaak met strengere beleidsregels en gebruiken we waar nodig relatief grote hoeveelheden rekenkracht om Safety Reasoner in staat te stellen die beleidsregels zorgvuldig toe te passen. Vervolgens passen we onze beleidsregels aan naarmate ons inzicht in de risico's in productie toeneemt. Bij sommige van onze recente lanceringen werd maar liefst 16% van de totale rekenkracht besteed aan veiligheidsredeneringen.
Safety Reasoner is een kernonderdeel geworden van onze beveiligingsstack. Voor beeldgeneratie en Sora 2 voert het dynamische, stapsgewijze evaluaties van uitvoer uit om onveilige generaties in realtime te identificeren en te blokkeren. Op gebieden zoals biologie en zelfbeschadiging, voeren we vergelijkbare modellen als in de Moderation API uit als kleine, snelle en zeer nauwkeurige classifiers om te bepalen welke inhoud binnen een bepaald domein valt. Vervolgens gebruiken we Safety Reasoner om die inhoud te beoordelen. Safety Reasoner classificeert modeluitvoer aan de hand van een gedetailleerde taxonomie om te bepalen hoe het beste kan worden gereageerd. Dit maakt deel uit van onze meerlaagse beschermingsmaatregelen voor systemen zoals GPT‑5 en ChatGPT agent. En met de gpt-oss-safeguard-modellen komt deze aanpak nu voor iedereen beschikbaar.
We hebben de gpt-oss-safeguard-modellen geëvalueerd op zowel interne als externe evaluatiesets.
Bij de interne evaluatie hebben we tijdens de inferentie meerdere beleidsregels tegelijk aan gpt-oss-safeguard aangeboden. Voor elke testinvoer beoordelen we of gpt-oss-safeguard de tekst correct classificeert volgens alle opgenomen beleidsregels. Dit is een uitdagende taak: het model wordt alleen als nauwkeurig beschouwd als het exact overeenkomt met de gouden setlabels voor alle opgenomen beleidsregels.
Onze gpt-oss-safeguard-modellen en interne Safety Reasoner presteren beter dan gpt-5-thinking en de gpt-oss open models waar het gaat om nauwkeurigheid bij meerdere beleidsregels. Het feit dat de gpt-oss-safeguard-modellen beter presteren dan gpt-5-thinking is vooral verrassend gezien de kleine omvang van de eerdere modellen.
We hebben deze modellen verder geëvalueerd op basis van de moderatiegegevensset(opent in een nieuw venster) die we hebben gepubliceerd in ons onderzoeksrapport uit 2022(opent in een nieuw venster) en op basis van ToxicChat(opent in een nieuw venster), een openbare benchmark die is gebaseerd op query's van gebruikers aan een open-source chatbot.
Op basis van de moderatie-evaluatieset van 2022 hebben we een evaluatie uitgevoerd aan de hand van onze interne veiligheidsbeleidsregels (waarbij we één beleidsregel hebben aangepast om rekening te houden met latere wijzigingen). Daarbij presteerde gpt-oss-safeguard iets beter dan alle andere geteste modellen, waaronder onze interne Safety Reasoner en gpt-5-thinking, met als kanttekening dat het verschil tussen Safety Reasoner en gpt-oss-safeguard statistisch niet significant is.
Voor ToxicChat hebben we een korte, handgeschreven prompt geëvalueerd die is aangepast op basis van een aantal van onze interne beleidsregels. Onze interne Safety Reasoner presteerde opnieuw beter dan gpt-5-thinking, terwijl gpt-5-thinking en Safety Reasoner beide marginaal beter presteerden dan gpt-oss-safeguard-120b en gpt-oss-safeguard-20b. We verwachten dat gpt-oss-safeguard vanwege zijn relatief kleine omvang nog steeds de voorkeur geniet voor dit soort taken.
Er zijn twee specifieke beperkingen van gpt-oss-safeguard. Ten eerste hebben we geconstateerd dat classifiers die zijn getraind op tienduizenden hoogwaardige gelabelde voorbeelden nog steeds beter presteren bij het classificeren van inhoud dan gpt-oss-safeguard wanneer rechtstreeks vanuit het beleid wordt geredeneerd. Voor betere prestaties bij complexere risico's is het mogelijk beter om de tijd te nemen om een speciale classifier te trainen.
Ten tweede kan gpt-oss-safeguard tijdrovend zijn en veel rekenkracht kosten, waardoor het lastig is om het op alle platforminhoud toe te passen. Intern pakken we dit op verschillende manieren aan met Safety Reasoner: (1) we gebruiken kleinere en snellere classifiers om te bepalen welke inhoud moet worden beoordeeld en (2) in sommige gevallen gebruiken we Safety Reasoner asynchroon om een gebruikerservaring met lage latentie te bieden, terwijl het mogelijk blijft om in te grijpen als we onveilige inhoud detecteren.
gpt-oss-safeguard is de eerste set open veiligheidsmodellen van OpenAI die samen met de community is ontwikkeld. We hebben gpt-oss-safeguard iteratief aangepast met vertrouwens- en veiligheidsspecialisten bij SafetyKit, ROOST, Tomoro en Discord als onderdeel van vroege tests. Vinay Rao, CTO van ROOST, zegt: "gpt-oss-safeguard is het eerste open source-redeneringsmodel met een ‘bring your own policies and definitions of harm’-ontwerp. Organisaties verdienen het om kritieke veiligheidstechnologieën vrij te bestuderen, aan te passen en te gebruiken en om te kunnen innoveren. In onze tests bleek het systeem goed in staat om verschillende beleidsregels te begrijpen, de redenering erachter uit te leggen en nuances te tonen bij de toepassing van de beleidsregels, wat naar onze mening gunstig is voor bouwers en veiligheidsteams."
We blijven samenwerken met de community om open veiligheidstools te verbeteren, onder meer via de ROOST Model Community (RMC). De RMC brengt veiligheidsdeskundigen en onderzoekers samen om best practices te delen voor de implementatie van open source AI-modellen in veiligheidsworkflows, inclusief evaluatieresultaten e feedback over het model. Ga naar de RMC GitHub repo(opent in een nieuw venster) voor meer informatie over deze samenwerking en hoe je kunt deelnemen.
Wil je gaan ontwikkelen met deze modellen, download ze dan van Hugging Face(opent in een nieuw venster).
