Einführung von gpt-oss-safeguard

Heute veröffentlichen wir eine Forschungsvorschau von gpt-oss-safeguard, unseren Open-Weight-Reasoning-Modellen für Sicherheitsklassifizierungsaufgaben, erhältlich in zwei Größen: gpt-oss-safeguard-120b und gpt-oss-safeguard-20b. Diese Modelle sind feinabgestimmte Versionen unserer gpt-oss⁠-Modelle und stehen unter derselben freizügigen Apache-2.0-Lizenz zur Verfügung, die es jedem ermöglicht, sie zu verwenden, zu ändern und frei bereitzustellen. Beide Modelle können ab heute von Hugging Face⁠(wird in einem neuen Fenster geöffnet) heruntergeladen werden.

Die gpt-oss-safeguard-Modelle nutzen Reasoning, um die von Entwicklern bereitgestellten Richtlinien während der Inferenz direkt zu interpretieren. Sie klassifizieren Benutzeranfragen, Completions und ganze Chats entsprechend den Anforderungen des Entwicklers. Der Entwickler entscheidet immer, welche Richtlinie verwendet wird, sodass die Reaktionen relevanter sind und auf den jeweiligen Anwendungsfall des Entwicklers zugeschnitten werden können. Das Modell nutzt eine Gedankenreihe, die der Entwickler einsehen kann, um zu verstehen, wie das Modell zu seinen Entscheidungen gelangt. Außerdem wird die Richtlinie während der Inferenz bereitgestellt, anstatt ins Modell integriert zu werden. So können Entwickler ihre Richtlinien iterativ überarbeiten, um die Leistung zu verbessern. Wir haben diesen Ansatz ursprünglich für den internen Gebrauch entwickelt. Er ist deutlich flexibler als die herkömmliche Methode, bei der ein Klassifikator trainiert wird, um aus vielen beschrifteten Beispielen indirekt eine Entscheidungsgrenze abzuleiten.

gpt-oss-safeguard ermöglicht Entwicklern, Richtlinien festzulegen, die optimal zu ihrem Anwendungsfall passen. So könnte beispielsweise ein Forum für Videospieldiskussionen eine Richtlinie entwickeln, um Beiträge zu klassifizieren, die sich mit Betrug im Spiel befassen; oder eine Produktbewertungsseite könnte ihre eigene Richtlinie verwenden, um Rezensionen zu prüfen, die vermutlich gefälscht sind.

Das Modell verarbeitet gleichzeitig zwei Eingaben – eine Richtlinie und den Inhalt, der unter dieser Richtlinie klassifiziert werden soll – und gibt eine Schlussfolgerung darüber aus, wo der Inhalt einzuordnen ist, zusammen mit seiner Begründung. Entwickler entscheiden selbst, ob und wie sie diese Schlussfolgerungen in ihre eigenen Sicherheits-Pipelines einbinden. Wir haben gesehen, dass dieser reasoning-basierte Ansatz besonders gut in Situationen funktioniert, in denen:

• das potenzielle Risiko neu entsteht oder sich weiterentwickelt und Richtlinien sich schnell anpassen müssen.
• das Themenfeld stark differenziert ist und kleinere Klassifikatoren damit schwer umgehen können.
• Entwickler verfügen oft nicht über genügend Datenbeispiele, um für jedes Risiko auf ihrer Plattform einen hochwertigen Klassifikator zu trainieren.
• Latenz ist weniger wichtig als die Erstellung hochwertiger, nachvollziehbarer Labels.

Wir veröffentlichen diese Vorschau von gpt-oss-safeguard, um Feedback aus der Forschungs- und Sicherheits-Community zu erhalten und die Modellleistung weiter zu verbessern. Über mehrere Monate hinweg haben wir gemeinsam mit ROOST⁠(wird in einem neuen Fenster geöffnet) an dieser Open-Weight-Version gearbeitet, um die wichtigsten Bedürfnisse von Entwicklern zu identifizieren, das Modell zu testen und Entwicklerdokumentation zu erstellen. Im Rahmen dieser Veröffentlichung wird ROOST eine Model-Community⁠(wird in einem neuen Fenster geöffnet) aufbauen, die ebenfalls heute startet, um OpenAI-Modelle zu erforschen und den Schutz digitaler Räume zu stärken. Parallel zur Veröffentlichung erscheint ein kurzer technischer Bericht⁠, der die Sicherheitsleistung dieses Vorschau-Modells beschreibt.

Wenn es um Sicherheit geht, setzen wir auf Defense-in-Depth⁠. Wir trainieren unsere Modelle so, dass sie sicher reagieren, und fügen zusätzliche Schutzebenen hinzu, um potenziell unsichere Eingaben und Ausgaben gemäß unseren Richtlinien zu erkennen und zu beheben. Sicherheitsklassifikatoren, die sichere von unsicheren Inhalten in einem bestimmten Risikobereich unterscheiden, bilden seit Langem eine zentrale Verteidigungsschicht für unsere eigenen und andere große Sprachmodelle.

Herkömmliche Sicherheitsklassifikatoren – etwa die, die über unsere Moderation API⁠(wird in einem neuen Fenster geöffnet) verfügbar sind, werden entwickelt, indem Tausende von Beispielen für sichere und unsichere Inhalte manuell kuratiert und auf vordefinierte Sicherheitsrichtlinien angewendet werden. Aus diesen Trainingsdaten lernt der Klassifikator, sichere von unsicheren Ausgaben zu unterscheiden. In diesem herkömmlichen Ansatz sieht der Klassifikator die Sicherheitsrichtlinie jedoch nie. Stattdessen versucht er, die zugrunde liegende Richtlinie zu erschließen, die zur Kennzeichnung der Beispiele verwendet wurde, indem er Ähnlichkeiten in den als unsicher markierten Inhalten und Unterschiede zwischen unsicheren und sicheren Inhalten erkennt.

Herkömmliche Klassifikatoren können eine hohe Leistung bei niedriger Latenz und geringen Betriebskosten erreichen. Doch das Sammeln einer ausreichenden Menge an Trainingsbeispielen ist zeitaufwendig und kostspielig, und das Aktualisieren oder Ändern der Richtlinie erfordert ein erneutes Training des Klassifikators.

gpt-oss-safeguard unterscheidet sich, weil seine Reasoning-Funktionen Entwicklern ermöglichen, beliebige Richtlinien anzuwenden, auch solche, die sie selbst schreiben oder aus anderen Quellen übernehmen, und weil Reasoning den Modellen hilft, auf neu formulierte Richtlinien zu verallgemeinern. Über Sicherheitsrichtlinien hinaus kann gpt-oss-safeguard auch dazu verwendet werden, Inhalte in anderer Hinsicht zu kennzeichnen, etwa in Bereichen, die für bestimmte Produkte und Plattformen relevant sind.

Unsere primären Reasoning-Modelle lernen nun unsere Sicherheitsrichtlinien direkt und nutzen ihre Reasoning-Fähigkeiten, um über Sicherheit nachzudenken. Dieser Ansatz, den wir deliberative alignment⁠ nennen, verbessert frühere Trainingsmethoden für Sicherheit deutlich und macht unsere Reasoning-Modelle in mehreren Dimensionen sicherer als ihre nicht auf Reasoning basierten Vorgänger – selbst wenn ihre Fähigkeiten zunehmen. Reasoning ist jedoch nicht nur nützlich, um die Modelle selbst zu trainieren. Es eröffnet auch neue Möglichkeiten für Defense-in-Depth. Reasoning-basierte Ansätze sind flexibler und weniger durch die Details ihres vorherigen Trainings begrenzt, Vorteile, die den zusätzlichen Rechenaufwand und die höhere Latenz oft mehr als rechtfertigen.

gpt-oss-safeguard ist eine Open-Weight-Implementierung eines Ansatzes, den wir intern in einem Tool namens Safety-Reasoner entwickelt haben. Wir begannen mit Reinforcement-Fine-Tuning bei Aufgaben zur Richtlinienkennzeichnung und belohnten das Modell dafür, die richtigen Bewertungen von menschlichen Experten zu übernehmen. Dadurch lernte das Modell, mithilfe von Reasoning nachzuvollziehen, wie die Richtlinie zu seiner Bewertung führt. Heute ermöglicht uns Safety-Reasoner, unsere Sicherheitsrichtlinien in der Produktion dynamisch zu aktualisieren, und das in kürzerer Zeit, als ein Klassifikator für das erneute Training benötigen würde. Dadurch wird Safety-Reasoner zu einem wichtigen Tool für iterative Bereitstellung⁠: Wenn wir neue Modelle in die Produktion überführen, beginnen wir häufig mit strengeren Richtlinien und setzen, wo nötig, größere Rechenressourcen ein, damit Safety-Reasoner diese Richtlinien sorgfältig anwenden kann. Anschließend passen wir unsere Richtlinien an, sobald sich unser Verständnis der Risiken in der Produktion verbessert. In einigen unserer jüngsten Launches lag der Anteil der gesamten Rechenleistung, die für Safety-Reasoning aufgewendet wurde, bei bis zu 16 %.

Safety-Reasoner ist zu einem zentralen Bestandteil unseres Sicherheits-Stacks geworden. Für Bildgenerierung und Sora 2 führt er dynamische, schrittweise Bewertungen von Ausgaben durch, um unsichere Generierungen in Echtzeit zu erkennen und zu blockieren. In Bereichen wie Biologie und Selbstverletzung verwenden wir Modelle wie jene in der Moderation API, kleine, schnelle Klassifikatoren mit hoher Trefferquote, um zu bestimmen, welche Inhalte in einen relevanten Themenbereich fallen, und lassen diese anschließend von Safety-Reasoner prüfen. Safety-Reasoner vergleicht Modellausgaben mit einer detaillierten Taxonomie, um die bestmögliche Reaktion zu bestimmen, und ist Teil unserer mehrschichtigen Sicherheitsmechanismen in Systemen wie GPT‑5 und ChatGPT Agent. Mit gpt-oss-safeguard steht dieser Ansatz nun allen zur Verfügung.

Wir haben die gpt-oss-safeguard-Modelle anhand interner und externer Evaluationsdatensätze bewertet.

In der internen Evaluation haben wir gpt-oss-safeguard während der Inferenz mehrere Richtlinien gleichzeitig bereitgestellt. Für jede Testeingabe prüfen wir, ob gpt-oss-safeguard den Text unter allen enthaltenen Richtlinien korrekt klassifiziert. Diese Aufgabe ist anspruchsvoll. Das Modell gilt nur dann als korrekt, wenn seine Klassifizierung exakt mit den Referenz-Labels für alle Richtlinien übereinstimmt.

Unsere gpt-oss-safeguard-Modelle und der interne Safety-Reasoner übertreffen gpt-5-thinking und die gpt-oss-open-Modelle in der Multi-Policy-Genauigkeit. Dass die gpt-oss-safeguard-Modelle gpt-5-thinking übertreffen, ist besonders bemerkenswert, da ihre Modellgröße deutlich geringer ist.

Wir haben diese Modelle außerdem mit dem Moderation-Datensatz⁠(wird in einem neuen Fenster geöffnet) getestet, den wir zusammen mit unserem Forschungsbericht von 2022⁠(wird in einem neuen Fenster geöffnet)veröffentlicht haben, sowie mit ToxicChat⁠(wird in einem neuen Fenster geöffnet), einem öffentlichen Benchmark, der auf Benutzeranfragen an einen Open-Source-Chatbot basiert.

Im Moderation-Evaluationsdatensatz von 2022 haben wir unsere internen Sicherheitsrichtlinien verwendet und dabei eine Richtlinie an spätere Änderungen angepasst. In diesem Test schnitt gpt-oss-safeguard leicht besser ab als alle anderen Modelle, darunter auch der interne Safety-Reasoner und gpt-5-thinking. Der Unterschied zwischen Safety-Reasoner und gpt-oss-safeguard ist jedoch statistisch nicht signifikant.

Für ToxicChat haben wir ein kurzes, handgeschriebenes Prompt verwendet, das aus einigen unserer internen Richtlinien abgeleitet wurde. Unser interner Safety-Reasoner übertraf erneut gpt-5-thinking, während sowohl gpt-5-thinking als auch Safety-Reasoner geringfügig besser abschnitten als gpt-oss-safeguard-120b und gpt-oss-safeguard-20b. Wir gehen davon aus, dass die vergleichsweise kleine Größe von gpt-oss-safeguard ihn für diese Art von Aufgabe weiterhin besonders geeignet macht.

Es gibt zwei spezifische Einschränkungen von gpt-oss-safeguard. Erstens haben wir beobachtet, dass Klassifikatoren, die mit Zehntausenden hochwertiger, beschrifteter Beispiele trainiert wurden, Inhalte teilweise besser klassifizieren können als gpt-oss-safeguard, wenn dieser direkt mithilfe von Reasoning aus der Richtlinie arbeitet. Für höhere Leistung bei komplexeren Risiken kann es daher sinnvoll sein, die Zeit in das Training eines speziellen Klassifikators zu investieren.

Zweitens kann gpt-oss-safeguard zeit- und rechenintensiv sein, was es schwierig macht, ihn plattformweit zu skalieren. Intern gehen wir damit auf verschiedene Weise um, mithilfe von Safety-Reasoner. (1) Wir verwenden kleinere und schnellere Klassifikatoren, um zu bestimmen, welche Inhalte bewertet werden sollen, und (2) in bestimmten Fällen setzen wir Safety-Reasoner asynchron ein, um eine Benutzererfahrung mit niedriger Latenz zu ermöglichen und gleichzeitig die Fähigkeit beizubehalten, einzugreifen, wenn unsichere Inhalte erkannt werden.

gpt-oss-safeguard ist OpenAIs erstes Set offener Safety-Modelle, das gemeinsam mit der Community entwickelt wurde. Wir haben gemeinsam mit Vertrauens- und Sicherheitsexperten von SafetyKit, ROOST, Tomoro und Discord am gpt-oss-safeguard gearbeitet, als Teil der frühen Testphase. ROOST-CTO Vinay Rao sagt: „gpt-oss-safeguard ist das erste Open-Source-Reasoning-Modell mit einem Design, das eigene Richtlinien und Definitionen von Schaden zulässt. Organisationen sollen die Möglichkeit haben, sicherheitskritische Technologien frei zu studieren, zu verändern und zu nutzen und so Innovation zu fördern. In unseren Tests zeigte es großes Geschick im Verständnis unterschiedlicher Richtlinien, bei der Erklärung seines Reasoning und bei der differenzierten Anwendung dieser Richtlinien, was unserer Ansicht nach für Entwickler und Sicherheitsteams von Vorteil sein wird.“

Wir werden weiterhin gemeinsam mit der Community an der Verbesserung offener Sicherheitstools arbeiten, unter anderem über die ROOST Model Community (RMC). Die RMC bringt Sicherheitspraktiker und Forscher zusammen, um bewährte Verfahren für die Integration von Open-Source-KI-Modellen in Sicherheits-Workflows auszutauschen – einschließlich der Bewertung von Ergebnissen und Feedback zu Modellen. Besuche das RMC-GitHub-Repository⁠(wird in einem neuen Fenster geöffnet), um mehr über diese Partnerschaft und Möglichkeiten zur Mitwirkung zu erfahren.

Um mit diesen Modellen zu arbeiten, lade sie von Hugging Face⁠(wird in einem neuen Fenster geöffnet) herunter.