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.
Wird geladen …
Von KI aus dem Text dieses Beitrags erstellt und von der synthetischen Stimme „Sulafat“ gelesen; keine wörtliche Fassung, Fehler sind möglich.Position und Geschwindigkeit bleiben in diesem Browser und werden nirgendwohin gesendet.
Die Aufnahme konnte nicht abgespielt werden. Audiodatei öffnen
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.
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.
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.