Trendtracking 015 | Nach drei Monaten der Schelte kam diese Veröffentlichung: Verhaltensaudit von OpenAIs 722 mathematischen Manuskripten

Fixieren wir zunächst die Zeit. Am 6. Oktober veröffentlichte OpenAI den Blogbeitrag ‘Sharing AI progress in mathematics’ und machte am selben Tag das Repository openai/math auf GitHub öffentlich – es sammelte in zwei Tagen 9832 Sterne%2

Was ist passiert

OpenAI hat die mathematischen Ergebnisse eines internen Modells als Ganzes veröffentlicht – 722 Forschungsmanuskripte, eingeteilt in 372 Ergebnisfamilien, das Repository enthält 132.880 Dateien, 3,1 GB, die Hauptsprache ist die formale Beweissprache Lean, Apache-2.0-Lizenz.

Das Repository ist in drei Ebenen unterteilt. Die erste Ebene ist preprints, PDFs und Quelldateien der 722 Papiere; die zweite Ebene ist das lean-Verzeichnis, 120.000 Lean-Dateien, organisiert nach 24 Fachgebieten, abhängig von einer festen Version der Community-Mathematikbibliothek mathlib4; die dritte Ebene ist reasoning_traces, 10 zusammengefasste Auszüge des Inferenzprozesses – beachte, dass die offizielle Formulierung „zusammengefasste Auszüge“ lautet, nicht der vollständige Denkprozess. Auch der Einstiegspunkt für die Verifikation ist vorbereitet: Offiziell wird der comparator-Workflow empfohlen, bei dem die drei Werkzeuge comparator, landrun und lean4export in die Umgebung konfiguriert werden, lake update die Abhängigkeiten herunterlädt, lake exe cache get den Community-Kompilierungs-Cache abruft, und so jede Ergebnisfamilie einzeln verifiziert werden kann. Das Modell, das diese Ergebnisse erzeugt hat, wurde nicht veröffentlicht; die offizielle Darstellung lautet „unveröffentlichtes internes Spitzenmodell“. Es bearbeitete etwa 4.000 Aufgaben, wobei durchschnittlich für jedes Ergebnis 3 Stunden an Rechenleistung für das Denken aufgewendet wurden, äquivalent zu ChatGPT Pro. Von den 722 Papieren haben 162 ein Lean-formalisiertes Hauptergebnis, die restlichen 560 Papiere enthalten nur das Paper selbst. Der Blog verspricht gleichzeitig, eine Reihe von Workshops zu finanzieren, und gibt an, dass an einem „verantwortungsvollen Release des Modells, das diese Ergebnisse erzeugt hat“, gearbeitet wird – wann das Modell selbst veröffentlicht wird, ist ein Köder für die Zukunft. Wie die interne Struktur des Repositories und der Verifikations-Workflow ablaufen, wird in der am selben Tag erschienenen Analyse 019 ausführlich behandelt; darauf wird in diesem Artikel nicht näher eingegangen. Der rote Faden dieses Artikels ist eine andere Sache: wie dieses Release durch Schimpfen erzwungen wurde.

Drei Monate lang kritisiert, bis zu dieser Veröffentlichung

Zunächst die Zeitlinie.

Im August führte OpenAI mit dem Astra-Modell in der Sprache Lean (Beweisassistent) eine Demonstration von zehn mathematischen Problemen durch – Formalisierungswerkzeuge an sich sind die öffentliche Infrastruktur der mathematischen Gemeinschaft, und dass ein KI-Unternehmen sie als Showbühne für Modellfähigkeiten nutzt, ließ einige Mathematiker zum ersten Mal ein ungutes Gefühl haben. Am 10. September tauchte eine Behauptung über einen Beweis im Zusammenhang mit den Navier-Stokes-Gleichungen auf – dies ist ein Jahrhundertproblem der Strömungsmechanik, und eine nicht peer-reviewed Behauptung direkt der Öffentlichkeit zu präsentieren, war an Augenfälligkeit kaum zu überbieten. Am 11. September veröffentlichten 25 Fields-Medaillen-Gewinner eine gemeinsame Erklärung, die auf die Veröffentlichungsweise von KI-Unternehmen im Bereich der Mathematik abzielte; letztes Mal haben wir darüber geschrieben (Trend 003, 12. September). Mitte September wurde die Kritik der Mathematiker an der Veröffentlichungsweise in den Medien kontinuierlich berichtet, wobei der Fokus von einem einzelnen Ereignis auf den Veröffentlichungsmechanismus selbst überging. Dann kam der 6. Oktober: Der Blog erklärte, dass diese Veröffentlichung nach den Empfehlungen der Beratergruppe für Mathematik und KI gestaltet wurde.

Der schmerzhafteste Punkt dieser Ursachenkette verbirgt sich im Empfehlungsschreiben der Beratergruppe selbst. Laut einem Verweis in der HN (Hacker News)-Diskussion schrieb diese am Institute for Advanced Study in Princeton angesiedelte Beratergruppe (AGMAI (Advisory Group on Mathematics and AI)) in ihrem Empfehlungsschreiben gleich zu Beginn zwei Bedeutungsebenen: Sie sprach sich deutlich gegen eine Billigung dieser Praxis aus und forderte, das Testen fortgeschrittener mathematischer Probleme auf proprietären Modellen einzustellen. Vergleicht man dies mit dem tatsächlichen Verhalten von OpenAI, ist das Ergebnis der Überprüfung von Worten und Taten klar: Die Hälfte zu den Veröffentlichungsstandards – Einrichtung eines öffentlichen Repositorys, Nennung von Zitierungsregeln, Lean-Formalisierung, Anfügen von Inferenzzusammenfassungen und Angabe des Rechenleistungsumfangs – wurde vollständig übernommen; die Hälfte mit der Aufforderung „Hört auf zu testen“ wurde hingegen ignoriert, und der Original-Blogbeitrag widmete eigens Absätze der Argumentation, warum es wichtig sei, weiterhin mathematische Probleme an internen Grenzmodellen zu testen. Wie man veröffentlicht, wurde befolgt; aufhören zu testen, wurde nicht befolgt. Von jeder Seite wurde die Hälfte genommen. Diese Entscheidung an sich verdeutlicht die Prioritäten: Über Verfahrensgerechtigkeit kann man verhandeln, das Testtempo wird nicht abgegeben. Der Blog beschreibt diese Veröffentlichung als Beispiel für die Zusammenarbeit mit der mathematischen Gemeinschaft, aber die hartnäckigste Bedingung dieser Zusammenarbeit – die Einstellung der Tests – taucht in keinem Absatz auf. Bis zum Zeitpunkt der Veröffentlichung gab OpenAI auf die Forderung nach „Einstellung der Tests“ keine positive Antwort. Der Fields-Medaillen-Gewinner Terence Tao veröffentlichte einen Beitrag auf Mastodon (laut Zitat auf HN), dessen Haltung milder war als die der gemeinsamen Erklärung: Er hofft, dass KI menschlichen Mathematikern Ergebnisse erklären kann, und glaubt auch, dass KI bei der Darlegung, dem Community-Aufbau und neuen Forschungsrichtungen positive Beiträge leisten kann – so mild diese Haltung auch ist, auch er sagte nicht „Bitte testet weiter“.

Die dritte Kritike2bene richtet sich gegen das Verkaufsargument der „maschinellen Verifizierbarkeit“. 162 geteilt durch 722 ergibt eine Formalisierungsrate von etwa 22 %; die verbleibenden 560 Arbeiten haben nur ein PDF, keinen Lean-Beweis – mit anderen Worten, bei fast 80 % der Manuskripte fehlt die Sicherheitsschicht der maschinellen Verifizierung. Und die Formalisierung selbst ist auch kein Freifahrtschein: Die Arbeit auf arxiv (Preprint-Server) 2610.08144 weist darauf hin, dass das Problem der Treuebestimmung bei der automatischen Formalisierung in der SCI (Schwierigkeitsgrad)-Hierarchie SCI=∞ ist, was schwieriger ist als das Halteproblem (SCI=1) – umgangssprachlich ausgedrückt: Zu bestimmen, ob eine maschinelle Übersetzung die Originalarbeit treu wiedergegeben hat, hat noch weniger einen allgemeinen Algorithmus als zu bestimmen, ob ein Programm anhalten wird. Das heißt, Lean verifiziert die Aussagen nach der Formalisierung, kann aber nicht garantieren, dass diese Formalisierung die Originalarbeit treu übersetzt hat. Eine ähnliche Fragestellung auf HN erhielt viele Zustimmungen: Die Voraussetzung für ein Lean-Zertifikat ist, dass der Theoremsatz korrekt übersetzt wurde, und über so breite Fachgebiete hinweg gibt es diese Garantie nicht. Das README des Repositorys räumt selbst ein: Die nicht formalisierten Teile könnten Fehler enthalten, die so schnell wie möglich behoben werden. Die Aussagen der drei Seiten sind hier selten so einig – Offizielle, Arbeit und Gemeinschaft stimmen überein, dass ein Verifikationsvakuum existiert, nur dass die Offiziellen es als Haftungsausschluss formuliert haben.

Was die Kommentatoren sagen

Bei HN (Hacker News) gab es über 1.400 Kommentare, von denen einige Stimmen repräsentativ sind.

Der bestbewertete Kommentar sprach der Interaktion zwischen OpenAI und der Mathematikergemeinschaft eine positive Bewertung aus, fügte jedoch eine messerscharfe Bedingung hinzu: Dies geschah erst, nachdem es öffentliche Kritik gab. Eine andere Strömung der Meinungen ging noch weiter: Die Mathematikergemeinschaft wollte nie Erlaubnis, sondern Regeln – und warf dem bisherigen Veröffentlichungsprozess vor, Forschungsrichtungen von menschlichen Forschern vorwegzupublizieren und bestehende Arbeiten nicht zu zitieren (laut Aussagen im Diskussionsbereich). Solcher aufgestaute Groll lässt sich nicht durch eine einzige große Veröffentlichung auf null setzen.

Auch über den Veröffentlichungskanal selbst wird gestritten: Einige sind der Meinung, dass ein öffentliches Repository plus Lean-Code ein neues Paradigma für mathematische Veröffentlichungen darstellt, während andere darauf bestehen, dass Paper auf arXiv gehören und ein Peer-Review durchlaufen sollten; GitHub kann ein Review nicht ersetzen, und die bloße Existenz von Code wiegt das Fehlen eines Review-Verfahrens nicht auf. In der Mathematik, einem Bereich, dessen Vertrauensgrundlage das Peer-Review ist, ist der Streit um den Veröffentlichungskanal letztlich ein Streit um Vertrauen.

Der menschlichste Kommentar stammt von einem PhD-Studenten: Was soll man tun, wenn die Richtung der zur Hälfte geschriebenen Arbeit von 722 Papern überrollt wird? Die Empathie in den Antworten war sehr direkt – gib deine Forschung nicht der KI, sie wird zum Training verwendet und dann vorwegpubliziert. Das Problem der Autorenschaft wird hier ebenfalls angesprochen: Die 722 Paper nennen nur OpenAI als Autor, nicht die einzelnen Forscher; einige schlugen vor, zumindest die Gutachter als Mitautoren zu nennen, woraufhin die Antwort war, dass dies der Öffentlichkeit beibringen würde, der Maschine statt den Gutachtern zu vertrauen; andere erklärten, dass in einem wettbewerbsorientierten Umfeld die Teamliste ohnehin nicht öffentlich gemacht werden sollte. In einer einzigen Autorenzeile drängen sich drei Standpunkte.

Es gibt auch eine weit verbreitete persönliche Schätzung: Diese Ergebnisse entsprechen einem mathematischen Fortschritt von 50 bis 100 Jahren – beachten Sie, dass dies die Schätzung eines einzelnen Nutzers ist und keinen Konsens darstellt; im Kommentarbereich gab es erheblichen Widerspruch. Bei Beurteilungen dieser Größenordnung muss man nicht voreilig Partei ergreifen: Das Repository3pository ist öffentlich, die Ergebnisse werden von der Mathematikergemeinschaft Stück für Stück verarbeitet, und wie hochwertig sie wirklich sind, wird die Zeit zeigen.

Drei Dinge, die normale Nutzer tun können

Erstens: einen Satz selbst verifizieren. Die Repository-Dokumentation bietet einen vollständigen comparator-Prozess (Vergleichsprogramm-Prozess). Wenn man die Umgebung gemäß den Schritten in lean/README einrichtet, kann man mit einem einzigen Befehl eine Ergebnisfamilie verifizieren – zum Beispiel das 7/8-Ergebnis der quasi-Riemann-Hypothese. Der menschliche Rekord liegt bei 11/12; 7/8 ist ein schwächerer Fortschritt als der menschliche Rekord und nicht das Endziel. Dies ist auch das erste Mal, dass normale Leser eine Behauptung aus der Spitzenforschung der KI-Mathematik aus erster Hand überprüfen können – man muss die Beweisdetails nicht verstehen, es reicht, den Befehl gemäß der Dokumentation auszuführen. Das README warnt zudem ausdrücklich davor, dass das Kompilieren des gesamten Repositorys an das Limit des Systemspeicher-Mappings stößt, und gibt Parameter an, um dies zu umgehen – dass das Repository so groß ist, dass spezielle Dokumentation zum Vermeiden von Kompilierungsfehlern geschrieben werden muss, ist an sich schon eine Fußnote.

Zweitens: CONTENTS.md (Inhaltsdatei) als Suchkarte verwenden. Die 722 Artikel sollte man nicht wie ein Magazin von Anfang bis Ende durchblättern. Offiziell sind die Ergebnisfamilien bereits nach 24 Disziplinen in dieser Datei aufgelistet; man sucht zuerst nach den paar interessanten Einträgen im eigenen Bereich und wechselt dann in das entsprechende Manuskript. Die Suche hat Vorrang vor dem Durchlesen – das ist der richtige Umgang mit einem Output dieser Größenordnung und die einzige Möglichkeit, Zeit zu sparen.

Drittens: gegenüber Schlussfolgerungen, die nur als PDF vorliegen, die Leseeinstellung „nicht formalisiert = fraglich“ beibehalten. Die 560 Manuskripte ohne einen Beweis in Lean (Theorembeweiser) sollten als Beweisbehauptungen und nicht als verifizierte Fakten gelesen werden – das ist keine Schikane, sondern die Richtlinie, die das README des Repositorys selbst festlegt. Beim Zitieren, Paraphrasieren oder Verbreiten von abgeleiteten Werken dieses Label anzubringen, ist das Konkreteste, was normale Leser für die Informationsumgebung tun können.

Fazit

Zuletzt das richtige Maß bewahren. Diese Ausgabe dokumentiert die zeitliche Abfolge und den Textvergleich; wir interpretieren keine Motive in OpenAI hinein und verurteilen es auch nicht; es bleibt gegenüber der Forderung des Beirats nach einem ‘Teststopp’ stumm, und dieses Stillschweigen selbst ist eine dokumentierte Tatsache, keine Antwort, die wir an seiner Stelle geben. Dass die Veröffentlichung erst nach Kritik erfolgte, dieser Satz ist eine Zusammenfassung der Zeitlinie, kein Urteil über die Motive.

Zwei Dinge gilt es künftig im Auge zu behalten. Erstens: Wird das Modell, das 722 Ergebnisse hervorbrachte, wie im Blog versprochen verantwortungsvoll veröffentlicht? – Ob es veröffentlicht wird oder nicht, beides prüft unmittelbar die Aufrichtigkeit des ‘Wie der Veröffentlichung’: ob sie beim Manuskript Halt macht oder bis zum Modell selbst reicht. Zweitens: Wann wird die erste Nachricht unter den 722 Ergebnissen widerlegt oder korrigiert? – Unter der Voraussetzung, dass die offizielle Seite selbst zugibt, dass ohne Formalisierung Fehler möglich sind, wird dieser Zeitpunkt maßgeblich darüber entscheiden, wie diese große Veröffentlichung am Ende bewertet wird: als eine ehrliche Demonstration oder als eine Reihe von zu überprüfenden Behauptungen. Wie schnell dann auf die im README versprochene ‘schnelle Behebung’ reagiert wird, steht ebenfalls auf der Beobachtungsliste.

Referenzquellen

• OpenAI-Blog „Sharing AI progress in mathematics“ (2026-10-06, Wayback-Volltextarchiv, Primärquelle)
• github.com/openai/math (Primärquelle: README, CONTENTS.md, formalization.yaml, comparator-Dokumentation; 722 Manuskripte / 372 Familien / 132,880 Dateien / 3.1GB / 9832★)
• Hacker News Story 49984923 (1241▲ / 1412💬, Algolia-Daten; Ansichten im Kommentarbereich sind paraphrasiert und ohne Anführungszeichen, AGMAI-Vorschlag und Terence Taos Beitrag sind aus dem Diskussionsbereich zitiert)
• arxiv 2610.08144 „Navier–Stokes Lost in Translation“ (Abstract als Primärquelle; Quelle der SCI=∞ Schlussfolgerung)
• Berichterstattung über die gemeinsame Erklärung von 25 Fields-Medaillen-Gewinnern (9-11; abgedeckt in Highlight 003 dieses Kontos, Rückverweis)
• Astra 10 Probleme, Navier-Stokes-Behauptung, Berichte über Kritik Mitte September (MSN-Archiv, ForkLog, The Next Web etc. Sekundärquellen-Pool, verwendet als Ankerpunkte für die Zeitleiste)