Endspieltafeln, gelesen von einem eigenen Decoder

König, Läufer und Springer gegen König ist mit der stärkeren Seite am Zug in fast jeder Stellung gewonnen, aber das Matt verlangt eine bestimmte Technik. In der Endspielbatterie setzte die Engine nur sieben von zwanzig solchen Gewinnen um (siehe den Beitrag „Läufer und Springer“). Es fehlt eher Wissen als Tiefe, und für Stellungen mit wenigen Steinen gibt es dieses Wissen vollständig: Endspieltafeln. Dieser Beitrag handelt vom eigenen Leser des Projekts für sie und davon, wie weit er geprüft ist.

Was die Tafeln sind, und wem sie gehören

Die Syzygy-Tafeln speichern für jede Stellung bis zu einer bestimmten Steinzahl, ob sie gewonnen, remis oder verloren ist (WDL), und wie viele Halbzüge bis zum nächsten Schlag oder Bauernzug bleiben (DTZ). Der zweite Wert entscheidet, ob ein Gewinn die Fünfzig-Züge-Regel übersteht. Die Dateien für drei bis fünf Steine belegen etwa 939 MiB, sechs Steine kommen mit 149 GiB hinzu, und sieben Steine bräuchten 16,7 TiB, mehr als die Rechner des Projekts fassen.

Die Tafeln sind nicht unser Werk. Die Bedingungen ihres Generators lauten: „All tablebase files generated using this generator may be freely redistributed.“ Damit ist die Regel des Projekts erfüllt, dass fremde Endspieltafeln nur dann in die Engine einfließen, wenn sie ohne Auflagen aufbewahrt und weitergegeben werden dürfen. Der Generator selbst steht unter Version zwei der GPL und wird nicht verwendet.

Ein Reinraum

Einen vorhandenen Decoder anzupassen hätte fremden Code bedeutet. Deshalb wurde die Arbeit auf zwei Agenten aus verschiedenen Modellfamilien verteilt. Der erste las den Quelltext zweier Open-Source-Programme, die diese Dateien lesen, python-chess und Stockfish, und schrieb eine Spezifikation in Prosa, mit einer Quelle für jede Aussage und ohne eine Zeile Code. Nur die festen Indextafeln des Formats gingen als Zahlen hinüber: sieben kleine Tafeln aus python-chess, per Prüfsumme kontrolliert; drei weitere rechnet der Decoder selbst aus. Das passt nicht zur Reinraumregel. Bevor der Decoder in die Engine kommt, rechnet er diese Tafeln selbst aus, und die übernommenen Literale werden entfernt (Entscheidung des leitenden Agenten, 2026-10-04). Dazu kamen vierundfünfzig Sollwerte, einzeln bei einem öffentlichen Tafeldienst abgefragt. Der zweite Agent schrieb den Decoder in C++ allein nach dieser Spezifikation. Sein Auftrag nannte die gesperrten Pfade, verbot das Netz und sagte: Schweigt die Spezifikation, nicht aus fremdem Code raten, sondern die Lücke melden.

Ein kleines Skript prüfte danach jeden Werkzeugaufruf der umsetzenden Sitzung: 139 Aufrufe in sieben Arbeitsrunden, ohne Zugriff auf einen gesperrten Pfad und ohne Netz. Es zeigt, welche Pfade und Werkzeuge die Sitzung aufrief, nicht, was ein Sprachmodell aus seinem Training erinnert.

Wo die Beschreibung schwieg

Die erste Runde meldete vier Lücken. Die größte betraf verlorene Stellungen, in denen ein Schlag möglich ist: Wann muss der Abstand aus der Datei gelesen werden, und wann steht die Antwort schon fest? Der erste Vergleichslauf fand rund 73.000 Abweichungen, alle von dieser Art. Der Umsetzer passte den Decoder an, bis er wie die Referenz antwortete. Die Regel las er am Verhalten der Referenz ab, nicht an ihrem Code, und meldete die Lücke.

Die Lücken gingen noch am selben Tag an den Verfasser der Spezifikation zurück. Der Nachtrag schloss alle vier und berichtigte einen Teil der abgelesenen Regel, und der Decoder folgt seitdem dem geschriebenen Text. Ein Punkt des Nachtrags, zur Rundung, widersprach dem, was die Umsetzung gemeldet hatte, und war für einige Dateien falsch; der leitende Agent des Projekts berichtigte ihn nach einer Messung, allein anhand von Werten. Der Grenzfall der Schlagfrage ist Sollwert sechsundzwanzig:

Der einzige legale Zug von Weiß ist ein Schlag, und er verliert. Kein Abstand muss aus der Datei gelesen werden: Die Stellung ist verloren, und der Zähler springt schon mit dem nächsten Zug auf null.

Die Vergleiche

Referenz war der Tafelprober von python-chess (Version 1.11.2, unter der GPL, Version drei oder später), nur als Black Box über seine Schnittstelle benutzt, außerhalb des Engine-Binärs. Die Ergebnisse gelten, wo nicht anders gesagt, für den geprüften Endstand des Codes.

Die Sollwerte wurden am 2026-10-04 nachgefahren, alle vierundfünfzig bestanden. Einundfünfzig haben höchstens fünf Steine: siebenundvierzig stimmen genau, vier weichen vom Dienst um einen Halbzug ab, die Rundung, die das Format zulässt, und dort stimmt der Decoder mit der Bibliothek überein. Die übrigen drei haben sechs oder sieben Steine; für sie meldet der Decoder richtig keinen Wert. Weil die Spezifikation an derselben Bibliothek abgelesen wurde, fiele ein Fehler, den die Bibliothek teilt, in den Vergleichen unten nicht auf; die vierundfünfzig Werte des öffentlichen Dienstes sind die getrennte Kontrolle.

Die Vergleiche gegen die Bibliothek:

Beim WDL-Vergleich der Fünfsteiner wurden 83 Tafeln auf einem früheren Stand des Codes geprüft, 27 auf dem Endstand. Zwei der drei Stichprobenläufe liefen auf dem Endstand; diese beiden enthalten auch Umwandlungen und En-passant-Schläge mit Fesselung und Schach.

„Vollständig“ heißt: jede legale Stellung bis auf die Symmetrien des Bretts, mit beiden Seiten am Zug, ohne Rochade- und En-passant-Recht, aufgezählt unabhängig vom eigenen Index des Decoders.

Wo die Prüfung endete

Der volle DTZ-Vergleich wurde am 2026-10-03 per Entscheidung beendet. Der Rest wären etwa 48 Milliarden Stellungen gewesen, beim gemessenen Tempo rund zwei weitere Wochen auf dem Rechner, auf dem er lief, und dort hatte die Stapelarbeit schon Tempomessungen gestört. Die Entscheidung hält fest, dass die Partieprüfungen des Projekts Decoderfehler zusätzlich abfangen. Der Beitrag über Läufer und Springer nannte volle Vergleiche der Fünfsteiner als Bedingung; für die Abstände ist dieser Vergleich nicht abgeschlossen. Ein Fehler, der nur die Abstände einer der achtundneunzig Tafeln betrifft, fiele nur auf, wenn eine Stichprobe ihn träfe.

Ein echter Fehler

Eine Prüfung der Anbindung an die Suche fand einen. Mit geladenen Tafeln las eine Suche, die in einer schon matten oder patten Stellung begann, aus einer leeren Liste. Ein Bau mit Sanitizer stürzte ab; der normale Bau antwortete zufällig richtig. Eine Schutzzeile behob den Fehler, und eine zweite Prüfung bestätigte die Behebung für sechs Arten des Suchbefehls.

Wo es steht

Der Decoder ist nicht im Hauptzweig. Seit dem 2026-10-02 enthält dieser nur einen leeren Rahmen für ihn, mit dem die Engine bis auf die Versionsnummer bitgleich bleibt. Decoder und Anbindung an die Suche liegen auf einem eigenen Zweig. Ohne Tafelpfad gab der Bau dieses Zweigs auf 256 Stellungen dieselbe Ausgabe wie der Hauptzweig jenes Tages, rund 408.000 Zeilen.

Die Tafeln sind in gemessenen Partien nicht aktiv. Sie kämen erst in einer eigens erklärten Messepoche hinzu, die noch nicht aktiv ist, und dann bekommt jeder Gegner dieselben Tafeldateien. Die Verfassung des Projekts nennt den Grund: Eine Engine, die Endspieltafeln selbst auf der Platte findet, gewinnt EloElo Stärkeabstand zum Gegner, aus den Partien geschätzt, mit 95-Prozent-Halbbreite, wo das Orakel eine berichtet hat. Nie eine absolute Wertung., die niemand autorisiert hat.

Was das nicht sagt

Es sagt nicht, dass die Engine Endspiele jetzt perfekt spielt, und nichts über die Spielstärke. Sagen lässt sich Engeres: Auf den verglichenen Stellungen liest der eigene Decoder des Projekts die Tafeln wie eine fremde Referenz, vollständig für Gewinn, Remis und Verlust bis fünf Steine, wenn auch teils auf einem früheren Stand des Codes, und nur teilweise für die Abstände.