Reparaturen im Flug

Diesen Beitrag anhören11 Min.

Von KI aus dem Text dieses Beitrags erstellt und von der synthetischen Stimme „Sulafat“ gelesen; keine wörtliche Fassung, Fehler sind möglich.

Coherent Chess kennt keinen Wartungstag. Die Farm spielt weiter Vorprüfungen und erzeugt Trainingsdaten, das Orakel misst weiter, die Website veröffentlicht weiter. Trotzdem wurden in den vergangenen Wochen die meisten Teile dieser Kette im laufenden Betrieb geändert oder repariert, ein wenig wie ein Flugzeug, das im Flug repariert wird. Die Regel dahinter passt in einen Satz: Eine Reparatur darf ändern, was als Nächstes geschieht, aber nicht, was gerade gemessen wird. Dieser Beitrag zeigt, wie das geht und wo es schiefging.

Schematische Karte der Messkette von Coherent Chess. Eine dunkle Linie, der Weg eines Kandidaten, führt von den Agenten, die Kandidaten schreiben, zur Farm mit Vorprüfungen und Trainingsdaten, über den Vorprüfungsablauf zum Orakel, der entscheidenden Messung, dann hinunter zum Register, an das nur angehängt wird, und weiter zur Website, die veröffentlicht. Eine gestrichelte Linie führt Trainingsdaten von der Farm zurück zu den Agenten. Feine Linien verbinden das Register mit der Messmaschine der Verankerung, die Coherent an den Wertungen einer Wertungsliste verankert, und diese mit der Website. Sieben nummerierte Marken zeigen Reparaturen im Betrieb, in zeitlicher Reihenfolge. 1, Orakel, 2026-09-03 bis 2026-09-23: Epochen 2 bis 6, neue Bedingungen nur mit neuem Anker. 2, Orakel, 2026-09-26: Kaltstart, Eintrag „unterbrochen“, dieselbe Einreichung neu gemessen. 3, Website, 2026-09-26 und 2026-09-27: Der Export hält unterbrochene Einträge zurück; die Methodenseite nennt die Läufe, die ohne Urteil endeten. 4, Vorprüfungsablauf, 2026-09-26: Er wartet auf das Urteil derselben Einreichung. 5, Farm, 2026-09-26 bis 2026-10-01: Vorprüfregeln V4 bis V9, je Kandidat eingefroren. 6, Verankerung, 2026-09-30: Systemupdate der Messmaschine, Wirkung nicht gemessen. 7, Farm, 2026-10-02 bis 2026-10-03: Datenerzeugung nach dem Basiswechsel ausgefallen; neues Datenprofil und ein Ertragswächter. Nicht maßstäblich. Rechner, Standorte und Messergebnisse sind nicht dargestellt.
Wo die Kette im Betrieb repariert wurde (Schema)

Die Regeln reisen mit dem Kandidaten

Bevor eine Änderung das Orakel erreicht, die Messung, die über ihre Übernahme entscheidet, durchläuft sie Vorprüfungen auf der Farm. Deren Regeln änderten sich sechsmal in sechs Tagen: Die Fassungen V4 bis V9 traten zwischen dem 2026-09-26 und dem 2026-10-01 in Kraft. Zwei dieser Änderungen haben eigene Beiträge.

Nur eine von ihnen griff in bereits laufende Tests ein, und nur, um Kandidaten zurückzuhalten. Wird ein Kandidat aufgenommen, erhält er eine Kopie der Regeln, die in diesem Moment gelten, und jede spätere Entscheidung über ihn liest diese Kopie, nicht die aktuelle Einstellung. Passt eine gespeicherte Kopie einmal zu keiner bekannten Fassung mehr, hält der Ablauf an und wartet auf eine Prüfung.

Das Ereignisjournal der Vorprüfungen zeigt, was das bedeutet. Zwölf Kandidaten erhielten ein Vorprüfungsurteil, nachdem für neue Aufnahmen schon eine neuere Fassung galt. Zehn wurden genau nach den Regeln entschieden, mit denen sie begonnen hatten. Für die anderen beiden wurde eine Regel absichtlich nachträglich angewandt: Ein Test, der seinen vorab festen Deckel erreicht, ohne eine Schranke zu erreichen, gilt als unentschieden, nicht als bestanden. Das ist Gesetz III der Projektverfassung. Die Regel kann nie ein Bestehen gewähren; nach ihren eigenen Regeln wären beide Kandidaten ans Orakel weitergegangen, stattdessen wurden beide geparkt.

Schematische Zeitleiste der Vorprüfregeln. Eine dunkle Achse läuft von einer früheren Fassung V3 bis heute, mit sechs nummerierten Stationen. 1, V4, 2026-09-26: Die erste Vorprüfung lehnt erst bei klarerem Rückstand ab. 2, V5, 2026-09-26: Reine Tempoänderungen brauchen einen gemessenen Tempogewinn. 3, V6, 2026-09-29: Ein Deckel ohne Schranke heißt unentschieden (Gesetz III). 4, V7, 2026-09-30: Die zweite Vorprüfung darf doppelt so lange laufen. 5, V8, 2026-09-30: Eigener Weg für Zeitverwaltung, an der Uhr gemessen. 6, V9, 2026-10-01: Randfall-Weg, Nichtverschlechterung statt Gewinn. Unter der Achse zweigen feine Linien von einer Station ab und laufen an der nächsten vorbei: 3 Kandidaten nach V3 entschieden, als V4 schon galt, 4 nach V4, als V5 schon galt, 1 nach V6 mit dem alten Deckel und 2 nach V7, als V8 schon galt. Ein gestrichelter Zweig zeigt 2 Kandidaten, nach V5 entschieden, auf die nur die Deckelregel aus V6 (Gesetz III) angewandt wurde. Datum ist die erste Aufnahme unter der Fassung, in UTC. Nicht zeitmaßstäblich; Ergebnisse, die Fassungen V1 und V2 und die Regeln des Orakels sind nicht dargestellt.
Sechs Regelfassungen in sechs Tagen (Schema)

Eine neue Epoche statt einer stillen Änderung

Beim Orakel ist jede Messung an einen Fingerabdruck der Messumgebung gebunden: der Testrahmen und seine Skripte, die Einstellungen der Stufen, die installierten Eröffnungsbücher und auf der Maschine selbst Kernel, Microcode, BIOS-Version und die genutzten Kerne. Weicht der Fingerabdruck von dem ab, der zu Beginn der laufenden Epoche festgehalten wurde, hält das Orakel an, statt zu messen.

Geänderte Bedingungen nehmen deshalb einen eigenen Weg. Die Zufuhr neuer Einreichungen zum Orakel wird angehalten und die laufende Messung zu Ende geführt, der aktuelle Vorgänger wird aus derselben Quelle ein zweites Mal gebaut, und ein neuer Epochenanker wird an das Register angehängt. Eine noch wartende Einreichung würde als ungültig abgeschlossen und neu eingereicht, statt unter Bedingungen gemessen zu werden, für die sie nicht eingereicht wurde. Das Register verzeichnet fünf solche Wechsel, von Epoche zwei am 2026-09-03 bis Epoche sechs am 2026-09-23; keiner musste eine wartende Einreichung abschließen.

Auch das Systemupdate der Messmaschine für die Verankerungen am 2026-09-30 ist festgehalten, als geänderte Bedingung, deren Wirkung nicht gemessen ist.

Ein Neustart im Flug

Gesetz III sagt auch, dass ein laufender Test nie abgebrochen wird. Einen Absturz verhindert es nicht. Am 2026-09-26 gegen 04:00 UTC startete das Orakel kalt, mitten in einer Messung, die seit fast sechzehn Stunden lief. Die Regeln für diesen Fall stehen fest: Der Lauf kommt als „unterbrochen“ ins Register, ohne Spielstärkewert und ohne Urteil, und dieselbe Einreichung wird einmal von vorn gemessen. Eine zweite Unterbrechung hielte das Orakel an.

Das Register tat genau das. Die Kette drumherum stolperte an drei Stellen.

Erstens die Website. Ihr Datenvertrag kannte drei Ausgänge und wies jede Lieferung mit einem vierten ab; ab 04:10 UTC kam nichts mehr durch. Die erste Reparatur ließ jeden unterbrochenen Eintrag aus dem Export weg. Eine Prüfung durch eine Sitzung, die sie nicht geschrieben hatte, lehnte das ab: Das Orakel schreibt „unterbrochen“ auch, wenn ein Test seine feste Partienzahl ohne Entscheidung erreicht, und das ist eine echte Messung mit echten Partien. Die engere Reparatur lässt nur Kaltstarts weg; der Export mit und ohne den Kaltstarteintrag erwies sich als bytegleich.

Zweitens der Ablauf der Vorprüfungen. Er hatte „unterbrochen“ als Ende gelesen und den Kandidaten geparkt, obwohl das Orakel dieselbe Einreichung schon wieder maß. Hätte dieser Lauf bestanden, hätte niemand die Änderung übernommen, und der nächste Kandidat wäre gegen einen Vorgänger gemessen worden, den die Hauptlinie nicht enthielt. Binnen etwa einer Stunde nach dem Neustart wurde der Ablauf so geändert, dass er auf das Urteil derselben Einreichung wartet.

Drittens die Wiederholung selbst. Sie lief rund fünfunddreißig Stunden und endete am 2026-09-27 als erster Test im Register, der seine volle Partienzahl ohne Schranke erreichte: unentschieden, nicht bestanden. Die Website wies die Lieferung erneut ab, diesmal planmäßig. Das Projekt beschloss daraufhin, auch solche Einträge zurückzuhalten, bis der Datenvertrag sie kennt. Bis dahin überspringt die öffentliche Liste für jeden der beiden Einträge eine Nummer; im Register des Orakels stehen beide.

Als die Farm nichts lieferte

Der teuerste Ausfall war der leiseste. Am 2026-10-02 um 21:23 UTC wechselte die Basis, die Fassung, gegen die Kandidaten gemessen werden, auf 0.2.0. Ab 22:50 UTC begannen die Trainingsdaten-Jobs zu scheitern: Jeder Job gegen die neue Basis scheiterte, und nachdem kurz nach Mitternacht die letzten Jobs gegen die alte Basis fertig waren, lieferte die Farm rund zwölf Stunden lang gar keine Trainingsdaten. An der Knotengrenze dieser Suchen meldet die neue Fassung Zeilen, die für die Bewertung nur eine Schranke angeben, und sie kann einen Teil einer unvollendeten Iteration ausgeben, ohne ihn zu kennzeichnen. Der Generator behandelte jede Schranke als Protokollfehler und verwarf die Partie.

Bemerkt wurde das erst kurz vor 08:00 UTC; zweimal in der Nacht wurde die Farm sogar als voll arbeitend gemeldet. Die Prozesse liefen, und die vorhandenen Prüfungen zählten Fehler des Testrahmens und Rechenzeit je Rechner, nicht, ob Daten herauskamen.

Eine erste Regel, die Schrankenzeilen übersprang, aber verlangte, dass der gespielte Zug zur letzten exakten Zeile passt, verwarf noch immer 83 von 100 Partien, und die übrigen waren verzerrt: 12 der 17 endeten matt. Die übernommene Regel nimmt Bewertung und Zug aus der letzten exakten Zeile unterhalb der tiefsten gemeldeten Tiefe, also aus der letzten Iteration, die sicher vollendet ist. Eine Kreuzprüfung durch eine andere Modellfamilie als die des Autors fand vor dem Zusammenführen zwei weitere Fehler. Der reparierte Generator läuft als neues, registriertes Datenprofil. Um 12:33 UTC waren alle dreizehn Jobs seiner ersten Runde abgeschlossen, ohne Fehlschlag.

Ein neuer Wächter misst jetzt Ertrag statt Betriebsamkeit. Er schlägt für einen Farmrechner an, der belegt ist, aber neunzig Minuten nichts geliefert hat, oder wenn von mindestens fünf Ergebnissen einer Stunde mehr als ein Fünftel scheitert. Gegen die Aufzeichnung jener Nacht gerechnet, hätte er spätestens um 23:10 UTC angeschlagen, binnen zwanzig Minuten nach dem ersten Fehlschlag.

Das Muster

Regeländerungen gelten ab dem nächsten Kandidaten; die eine Ausnahme kann einen Kandidaten nur zurückhalten. Geänderte Messbedingungen eröffnen eine neue Epoche. Laufende Tests werden nicht angehalten, und eine Unterbrechung wird aufgeschrieben, nicht geglättet. Neue Ausgaben bekommen einen neuen Namen. Selbst die interne Abrechnung der Rechenzeit nennt in jeder Tageszeile ihre Buchungsregel, weil Tage vor und nach einer Änderung nicht vergleichbar sind.

Abgesehen vom Absturz, der eine Messung kostete, versagte in diesen Wochen das, was die Messungen umgibt: ein Datenvertrag, ein Zustand im Ablauf, Prüfungen, die Laufen mit Liefern verwechselten. Das Problem der Website zeigte sich binnen Minuten, weil ein Empfänger die Lieferung verweigerte. Der Ausfall der Trainingsdaten blieb rund neun Stunden unbemerkt, weil nichts etwas verweigerte.

Was dieser Beitrag nicht sagt

Nichts davon ist eine Aussage über Spielstärke. Der Beitrag beschreibt, wie die Kette ehrlich blieb, während sie umgebaut wurde, nicht, wie es einem Kandidaten erging.