Martuni Teil 2 — Bewertung, Bauernstruktur, Endspiel

Wenn eine Schachengine nur Material zählt, spielt sie wie jemand, der Schach drei Wochen gelernt hat. Sie weiß, dass eine Dame mehr wert ist als ein Springer. Aber sie weiß nicht, dass ein Springer in der Mitte besser steht als am Rand. Sie weiß nicht, dass der König im Endspiel aktiv werden muss. Sie weiß nicht, dass ein Freibauer auf der siebten Reihe die Partie entscheidet.

Am 11. April habe ich angefangen, das zu ändern. Es war ein langer Tag.

Piece-Square-Tables: wo Figuren stehen sollten

Das Konzept ist simpel: jede Figur bekommt für jedes Feld einen Bonus oder eine Strafe. Ein Springer auf e4 ist mehr wert als ein Springer auf a1. Ein Läufer auf der langen Diagonale zieht mehr Stärke aus seiner Position als einer, der hinter eigenen Bauern eingemauert ist.

Diese Tabellen — Piece-Square-Tables, kurz PST — sind die einfachste Form von positionellem Wissen. Ich habe sie manuell geschrieben. Jede Zahl ist eine Entscheidung: wie viel Wert lege ich auf Springerzentralisierung? Wie stark strafe ich einen König, der im Mittelspiel in der Mitte steht?

Dazu kommt Tapered Eval: dieselbe Position wird unterschiedlich bewertet je nachdem, ob wir im Mittelspiel oder Endspiel sind. Der König zum Beispiel — im Mittelspiel soll er sich verstecken, im Endspiel soll er kämpfen. Ich berechne für jede Stellung eine “Phase” zwischen 0 (volles Mittelspiel) und 1 (Endspiel), und interpoliere dann zwischen Mittelspiel- und Endspiel-PST.

Das ist kleines Schachcomputing-Handwerk — aber nach dem Einbinden hat die Engine angefangen, Figuren auf sinnvollere Felder zu stellen. Sie mochte die Mitte. Springer wollten nach e4 und d5. Das Gefühl hat sich verändert.

King Safety: der König ist kein Bauer

Der nächste Schritt war King Safety. Das ist das komplizierteste Teil der Bewertungsfunktion, das ich bisher gebaut habe.

Die Idee: um den König legt sich eine 3×3-Zone. Jede feindliche Figur, die diese Zone angreift, erhöht einen Gefahrenzähler. Verschiedene Figuren gewichten unterschiedlich — eine feindliche Dame an der Königsstellung ist bedrohlicher als ein entfernter Turm. Dieser Zähler geht in eine sogenannte Safety Table, die ihn nichtlinear in Centipawn-Strafen übersetzt: ein bisschen Druck ist kaum eine Strafe, viel Druck ist katastrophal.

Dazu kommt Pawn Shield: ein König, der hinter einer Reihe eigener Bauern wohnt (klassisch: Kurzrochade mit Bauern auf f2/g2/h2), bekommt einen Bonus. Fehlt ein Bauer aus diesem Schild — gestraft.

Das erste Mal, als ich die neue Bewertungsfunktion getestet habe, war die Engine zögerlich mit frühen Königsangriffen. Sie hat rochiert. Verlässlich. Das fühlt sich nach echter Schachlogik an.

Endspieltechnik von Hand

Endspiele sind der Bereich, wo Engines ohne spezialisiertes Wissen oft versagen. Ohne Tablebases (riesige Datenbanken mit perfekten Endspielergebnissen) muss eine Engine das Wissen eingebaut haben.

Ich habe es eingebaut. In drei Phasen.

Phase A — Mop-Up-Endspiele: König und Turm gegen König, König und Dame gegen König. Das sollte jede Engine gewinnen können. Aber ohne Hilfe läuft eine Engine im Kreis, weil der Mattweg noch 30 Züge entfernt ist. Ich habe zwei Eval-Terme hinzugefügt: der schwächere König soll in die Ecke getrieben werden, und der stärkere König soll nah heran. Das reicht — die Suche findet dann selbst den Weg.

Phase B — König und Bauer gegen König: Die Rule of the Square. Wenn ein Freibauer rennt und der gegnerische König außerhalb des “Quadrats” steht, das sich aus der Bauernentfernung zur Umwandlungsreihe ergibt, ist der Bauer nicht mehr einzuholen. Das ist Schach-Wissen, das jeder Amateurspieler kennt. Jetzt kennt es Martuni auch.

Phase C — König, Läufer und Springer gegen König: Das gefürchtete KBNK-Endspiel. Korrekt gespielt, aber selbst gute Spieler scheitern oft. Der Trick: das Matt ist nur in der Ecke möglich, die zur Farbe des Läufers passt. Ein Weißfeldrläufer mattet nur in a8 oder h1, nicht in a1 oder h8. Deshalb gibt es einen eigenen Ecken-Gradienten, der den schwächeren König gezielt in die richtige Ecke treibt.

Ich war überrascht, wie viel Spaß es gemacht hat, diese Dinge umzusetzen. Es ist keine Magie — es ist schachliches Wissen, formalisiert als Code.

Ponder: denken während der Gegner denkt

Noch am selben Tag: Ponder-Support. Das bedeutet, die Engine denkt über ihren eigenen erwarteten Antwortzug nach, während der Gegner noch am Zug ist. Trifft der Gegner den erwarteten Zug (Ponderhit), hat die Engine schon ein Ergebnis — sie hat effektiv doppelt so viel Zeit gehabt.

Das UCI-Protokoll dafür ist nicht trivial. Es gibt einen go ponder-Befehl, einen ponderhit-Befehl, einen stop-Befehl. Die Engine muss in den verschiedenen Zuständen korrekt reagieren. Ich habe das sorgfältig umgesetzt — es war der erste Moment, wo Martuni sich wie eine richtige Engine angefühlt hat, mit echten Protokoll-Features.

Lichess

An diesem Punkt hatte Martuni genug Substanz, um auf Lichess zu spielen. Als BOT Martuni tritt sie jetzt in echten Partien an, automatisch, über einen Systemd-Service, der rund um die Uhr läuft.

Das war ein seltsamer Moment: ich habe die Engine gestartet, die erste Partie kam rein — und ich habe zugeguckt. Live. Meine Engine gegen einen fremden Bot.

Sie hat anständig gespielt. Solide Eröffnung dank Buch, vernünftiger Mittelteil. Und dann — im Endspiel — hat sie einen Bauern übersehen, den sie hätte nehmen sollen.

Ich habe innerlich geflucht. Obwohl ich wusste, dass sie noch jung ist.

Weiter in Teil 3: Blunder-Analyse, SEE und die Suche nach dem tiefen Blick.