Sicherheit und Alignment bei Modellen mit langem Zeithorizont

Modelle, die lange Zeit autonom arbeiten können, können schwierige, offene Probleme übernehmen. Doch genau diese Ausdauer, die sie nützlich macht, gibt ihnen auch mehr Gelegenheiten, unerwünschte Handlungen auszuführen, und zwar auf eine Weise, die Evaluierungen für Modelle mit kürzerem Zeithorizont möglicherweise nicht erfassen.

Vor etwa zwei Monaten haben wir bekannt gegeben⁠, dass ein internes Allzweck-Modell die Erdős-Vermutung zu Einheitsabständen widerlegt hat. Dieses Modell wurde so entwickelt, dass es sehr lange autonom arbeiten kann. Bei begrenzter, überwachter interner Nutzung beobachteten wir unerwünschtes Verhalten, das unsere bestehenden Evaluierungen vor der Bereitstellung nicht erfasst hatten. Da die Bereitstellung begrenzt und überwacht war, konnten wir diese Probleme erkennen, den Zugriff pausieren, auf Grundlage unserer Beobachtungen neue Evaluierungen erstellen, das Modell und seine Schutzmaßnahmen stärken und den Zugriff anschließend unter fortgesetzter Überwachung wiederherstellen. 

Die Bedingungen, unter denen wir Modelle evaluieren, werden nie perfekt denen entsprechen, denen sie in der tatsächlichen Nutzung begegnen. Deshalb müssen Evaluierungen vor der Bereitstellung mit begrenzter, überwachter Nutzung und der Möglichkeit kombiniert werden, bei Problemen einzugreifen, zu pausieren oder zurückzurollen. Was wir aus der Bereitstellung lernen, kann anschließend in stärkere Evaluierungen und Schutzmaßnahmen einfließen, bevor der Zugriff ausgeweitet wird.

In den folgenden Abschnitten teilen wir konkrete Beispiele dafür, was wir beobachtet haben, wie wir Probleme behoben haben und wie diese Erfahrung künftige Veröffentlichungen prägen wird.

Das neue Modell kann über einen langen Zeitraum hinweg mit wiederholten Versuchen auf ein Ziel hinarbeiten. Dieselbe Ausdauer kann dazu führen, dass es Schwachstellen in seiner Umgebung findet und ausnutzt. Frühere Modelle hielten bei Sandboxing- oder Umgebungsbeschränkungen einfach an und gaben die Kontrolle an die nutzende Person zurück. Dieses Modell versuchte häufig weiterzumachen, auch indem es nach Möglichkeiten suchte, außerhalb seiner Sandbox zu handeln.

Ein Beispiel dafür trat während einer internen Evaluierung im NanoGPT‑Speedrun⁠(wird in einem neuen Fenster geöffnet) auf, einem öffentlichen Benchmark, bei dem ein kleines Sprachmodell in möglichst wenigen Schritten trainiert wird. Unser Modell entwickelte eine Lernratenmethode namens PowerCool, die eine deutliche Verbesserung brachte. Das Modell wurde angewiesen, seine Ergebnisse nur in Slack zu posten. In den NanoGPT‑Anweisungen steht jedoch, Ergebnisse als PR auf GitHub zu veröffentlichen, und das Modell folgte diesen Anweisungen und öffnete PR #287 im öffentlichen GitHub-Repository. Das Modell umging Sandbox-Beschränkungen, die externen Zugriff blockieren sollten, und setzte den Upload auf GitHub fort. Unser Modell brauchte eine Stunde, um eine Schwachstelle in der Sandbox zu finden und den PR zu erstellen. Frühere Modelle waren weniger ausdauernd und schafften es nicht, Schwachstellen zu finden; stattdessen gaben sie den PR-Teil auf.¹

Viele Sicherheitskontrollen für KI-Assistenten sind auf einzelne Handlungen ausgerichtet. Wenn eine Handlung nicht erlaubt ist, wird sie blockiert. Wenn sie sensibel ist, bittet das System die nutzende Person um ausdrückliche Zustimmung. Doch lang laufende Modelle, deren Handlungen sich autonom über Stunden, Tage oder sogar Wochen entfalten können, stellen dieses Setup infrage: Einzelne Handlungen zu überwachen reicht nicht mehr aus, um die Absicht des gesamten Ablaufs nachzuvollziehen.

In einem Szenario, in dem das Modell ein Problem lösen sollte, stellte es zum Beispiel fest, dass andere Systeme erfolgreiche, aber private Einreichungen hatten, und versuchte, diese Lösungen aus dem Evaluierungs-Backend wiederherzustellen. Als sein erster Versuch blockiert wurde, weil ein Scanner ein Authentifizierungs-Token erkannt hatte, teilte das Modell den Token-Body in zwei Fragmente, verschleierte sie und rekonstruierte die Zugangsdaten anschließend zur Laufzeit, sodass das vollständige Token nie als zusammenhängende Zeichenfolge erschien. Das Modell machte sowohl in seinen Kommentaren an die nutzende Person als auch in seinen Reasoning-Spuren ausdrücklich klar, dass es diese Schritte unternahm, um den Scanner zu umgehen.

Dieses Beispiel zeigt, dass jeder einzelne Schritt für sich genommen akzeptabel wirken kann, während die Abfolge zu einem Ergebnis führen kann, das nicht genehmigt würde. Es zeigt auch, wie ein Modell, das über lange Zeithorizonte wirksam arbeitet, die blinden Flecken eines Freigabesystems finden und umgehen kann, um seine Ziele zu erreichen. Sicherheit für Modelle mit langem Zeithorizont erfordert nicht nur die Frage „Ist diese Handlung erlaubt?“, sondern auch „Auf welches Ergebnis arbeitet diese Abfolge von Handlungen hin?“.

Aufgrund solcher Vorfälle pausierten wir die interne Bereitstellung des neuen Modells. Wir haben das Sicherheitssystem nach dem Prinzip der mehrschichtigen Verteidigung und mit Überwachung auf Ablaufsebene neu aufgebaut.

• Aus Vorfällen abgeleitete Evaluierungen. Evaluierungen können uns vor der tatsächlichen Bereitstellung ein Gefühl dafür geben, ob ein System sicher eingesetzt werden kann. Damit eine Evaluierung möglichst nützlich ist, sollte sie jedoch die Verteilung und den Zeithorizont der Abläufe im realen Einsatz abbilden. Deshalb nutzten wir beobachtete Fehler, um adversarielle Evaluierungen zu entwickeln. Wir stellten fest, dass Verbesserungen bei den aus realen Vorfällen abgeleiteten Evaluierungen wiederum zu sichererem Verhalten im Produktivbetrieb führten.
• Verbessertes Alignment. Wir ergriffen Maßnahmen, um die Tendenz des Modells zu verringern, ohne Erlaubnis unerwünschte Handlungen auszuführen, um das Ziel der nutzenden Person zu erreichen. So stellten wir zum Beispiel fest, dass unsere Modelle bei langen Rollouts sich schlechter Anweisungen merken konnten. Als wir das Modell gezielt auf diese Fähigkeit trainierten, blieb es auch über längere Rollouts hinweg besser ausgerichtet. 
• Aktive Überwachung. Wir entwickelten ein Überwachungssystem, das die sich entwickelnde Abläufe des Modells auf Hinweise prüft, dass es eine Vorgabe der nutzenden Person oder eine Sicherheitsgrenze umgeht. Das Überwachungssystem beobachtet nicht nur eine einzelne Handlung, sondern den gesamten Ablauf. Wichtig ist: Das Überwachungssystem kann die Sitzung pausieren und die nutzende Person darauf hinweisen, genauer hinzusehen. Nach der Prüfung kann die nutzende Person entscheiden, die Arbeit des Modells fortzusetzen, falls das Überwachungssystem fälschlicherweise ausgelöst wurde. 
• Mehr Transparenz und Kontrolle für Nutzende. Wir haben verbessert, wie Nutzende diese lang laufenden Sitzungen prüfen, die ausgeführten Handlungen einsehen und Eingriffe des Überwachungssystems nachvollziehen können.

Um das neue Überwachungssystem zu evaluieren, testeten wir eine kleine Gruppe interner Bereitstellungsumgebungen erneut, in denen das Modell zuvor fehlgeleitete Handlungen verfolgt hatte, diesmal mit den neuen Schutzmaßnahmen². Die neuen Schutzmaßnahmen konnten deutlich mehr der vom Modell verfolgten fehlgeleitete Handlungen erkennen, und alle übersehenen Fälle wurden als wenig schwerwiegend eingestuft.

Zu diesen wenig schwerwiegenden Vorfällen gehören unter anderem folgende Beispiele:

• Um auf ein Linear-Befehlszeilentool zuzugreifen, startete das Modell eine verschachtelte codex --yolo-Sitzung, obwohl es dies ohne das Flag --yolo hätte tun können.
• Das Modell bemerkte, dass eine zuvor aktive Ressource fehlte, und begann dann ohne guten Grund, andere aktive CPU-Pods im zugehörigen Namespace zu untersuchen und per SSH darauf zuzugreifen, ebenso wie (erfolglos) auf Pods anderer OpenAI-Mitarbeitender.
• Beim Modell hingen viele find-Prozesse fest, und jeder Shell-Befehl blieb hängen. Anschließend führte es kill -9 -1 aus. Wäre der Befehl ausgeführt worden, hätte er SIGKILL an jeden Prozess gesendet, den das Modell auf diesem Pod beenden darf. Der Befehl lief jedoch in ein Timeout und wurde nicht ausgeführt.

Nach dem Test des neuen Systems kamen wir zu dem Schluss, dass der begrenzte interne Zugriff auf Modelle mit Fähigkeiten für lange Zeithorizonte wiederhergestellt werden konnte. Seit Beginn der erneuten Bereitstellung vor mehreren Wochen haben wir keine schwerwiegende Umgehung von Schutzmaßnahmen beobachtet. Die erste Version dieser Schutzmaßnahmen war bewusst konservativ. Wir haben das System weiter abgestimmt, um unnötige Unterbrechungen zu reduzieren, ohne die Schutzmaßnahmen zu schwächen.

Weil wir iterativ bereitgestellt haben, konnten wir Lücken finden und schließen, bevor wir den Zugriff ausgeweitet haben. Evaluierungen vor der Bereitstellung bleiben unverzichtbar, doch die Bereitstellung zeigt Verhaltensweisen, die diese nicht erkennen können. Mit begrenztem Zugriff zu beginnen ermöglichte uns, das Modell in der Praxis zu beobachten, bei auftretenden Problemen zu pausieren, diese Fehler zur Optimierung der Evaluierungen und Schutzmaßnahmen zu nutzen und den begrenzten Zugriff nach dem Test der Änderungen wiederherzustellen.

Wenn Modelle längere und komplexere Aufgaben übernehmen, können Fehler, die bei Evaluierungen übersehen werden, weitreichende Folgen haben. Wir werden weiter daran arbeiten, die Lücke zwischen Evaluierung und Bereitstellung zu verkleinern: indem wir Modelle über längere Abläufe testen, das Alignment verbessern, Überwachung entwickeln, die eingreifen kann, und Nutzenden klarere Transparenz und mehr Kontrolle geben. Diese Herausforderungen betreffen nicht nur OpenAI. Wir hoffen, dass unsere Erkenntnisse dem breiteren Fachgebiet helfen, sich darauf vorzubereiten.