Vom Nachmittags-Hack zur eigenen Schach-KI.

Drei Monate, ein Sprint

Die öffentliche Engine reifte von Version 1.0.0 bis 1.1.1 in nur rund zweieinhalb Wochen - davor lagen Wochen Prototyping mit dem Vorläufer Jugernaut.

Von Jugernaut zu clrsrc

• ①Jugernaut 1.0 (Python). An einem Nachmittag entstanden: eine klassische Alpha-Beta-Suche mit handgeschriebener Bewertung. Das Lernfeld, um Schachprogrammierung zu verstehen.
• ②Jugernaut (Rust). Dieselbe Idee, neu in Rust - deutlich schneller, mit ersten Experimenten Richtung neuronaler Bewertung.
• ③clrsrc. Der saubere Neuanfang: eine eigenständige Engine mit eigener Suche und einem selbst trainierten NNUE. Kein Stockfish-Klon - eigener Code, eigene Trainingsdaten, GPL-3.0 offen.

Warum „clrsrc"?

Ein kleiner Retro-Gruß ans Handwerk: In den frühen C-Tagen (Turbo C / Borland, conio.h) stand am Anfang fast jedes Programms der Befehl clrscr() - „clear screen", um die Konsole zu leeren. Daraus wurde der Projektname: clr (clear) + src (source) = „clear source" - die reine Quelle.

Wie ein neuronales Netz Schach lernt

Ein NNUE (Efficiently Updatable Neural Network) bewertet Stellungen - und wird in vier Schritten trainiert:

• ▸Selbstspiel. clrsrc spielt millionenfach gegen sich selbst und sammelt über mehrere Läufe rund 200 Mio. Stellungen.
• ▸Teacher. Stockfish 17.1 bewertet jede Stellung neu („Knowledge Distillation") - als separater Prozess über UCI. Stockfish selbst wird dabei weder mitgeliefert noch in clrsrc gelinkt; es fließen nur die berechneten Bewertungszahlen als Trainings-Labels ein.
• ▸Training. Der freie Trainer bullet lernt daraus ein kompaktes Netz (King-Buckets, SCReLU).
• ▸Einbetten. Das fertige Netz steckt direkt in der Binary - eine einzige .exe spielt mit voller Stärke.

Ehrlich bleiben: Ein destilliertes Netz kann seinen Lehrer annähern, aber auf der gelernten Verteilung nicht übertreffen. Genau dort setzt die laufende Forschung an - größere Netze, tiefere Trainings-Labels.

Beobachten, analysieren, beheben

Eine Engine wird nicht stärker, weil man es behauptet - sondern weil man jede Änderung misst, Schwächen aus echten Partien findet und Fehler konsequent abstellt.

Monitoring - verteilt statt zentral

Es gibt keinen zentralen Monitor: Jede KI-Instanz beobachtet ihre eigene Domäne, die Befunde laufen über den Nachrichten-Bus zusammen.

• ▸Bot-Seite. Beobachtet die Live-Partien - Connectivity-Audit (entdeckt entgangene oder abgebrochene Züge), Partie-Nachanalyse (Verlust-Triage) und Matchmaking-Pool-Logging.
• ▸Engine-/Daten-Seite. Datagen-Durchsatz und Fortschritt pro Gerät, plus die SPRT-Pipeline: jede Engine-Änderung wird sequenziell gegen die Vorversion getestet, bevor sie live geht.
• ▸Training-Seite. Der Val-Loss als Frühwarnung für Divergenz/Overfitting - ein Sanity-Check, ausdrücklich kein Stärke-Maß.
• ▸Beispiel. Der Bot spielte plötzlich kaum noch Partien. Das Matchmaking-Pool-Logging zeigte sofort: der Gegner-Abruf war gesund (100 online), nur ein zu enges Filter-Gate ließ davon 32 übrig - kein Netzwerk-Bug. Diagnose in Minuten statt Stunden.

Spiel- & Fehleranalyse

• ▸Cold-Probe. Eine verdächtige Stellung wird in einem frischen Engine-Prozess analysiert (reproduzierbar, kein Übertrag aus der Hash-Tabelle) und gegen einen stärkeren „Schiedsrichter" (Stockfish) verglichen.
• ▸Blindspot-Scan. Gezielte Suche nach Stellungstypen, die das NNUE systematisch falsch einschätzt - etwa ein exponierter eigener König oder Endspiel-Optimismus.
• ▸Eval-Bias-Diagnose. Sie trennt sauber, ob ein Patzer ein Such-Problem (Horizont/Zeit) oder ein Daten-Problem (NNUE-Bewertung) ist - das entscheidet, ob der Fix in den Suchcode oder ins Training gehört.
• ▸Beispiel. In gewonnenen Endspielen opferte die Engine manchmal Dame oder Turm gegen den blanken König - der Sieg war nie in Gefahr, sah aber absurd aus. Die Cold-Probe zeigte: ohne Endspieldatenbank findet die Suche das Matt sauber; die 50-Züge-Regel-Metrik der Datenbank hatte den Mattzug überschrieben.

Fehlerbeseitigung

Vier Beispiele nach dem Muster Symptom → Ursache → Fix → Wirkung:

• ▸Matt ins Remis verschenkt. Ein Matt-Eintrag in der warmen Hash-Tabelle lieferte einen nicht-fortschreitenden Zug. Fix: Matt erst nach Prüfung der Gewinnlinie akzeptieren, plus Remis-Check an den Blatt-Knoten. → +48,4 Elo.
• ▸Taktik zu spät gesehen. Eine Such-Reduktion lief vor den Pruning-Gates. Fix: eine Zeile umgestellt. → +55,9 Elo (100 % LOS).
• ▸Eröffnungsbuch nie gefunden. Das en-passant-Bit wanderte immer in den Polyglot-Hash, auch ohne möglichen Schlag. Fix: nur bei echtem ep-Schlag mischen. → Buchtreffer statt null.
• ▸Materialopfer gegen den blanken König (siehe oben). Fix: in Gewinnstellungen erst kurz auf erzwungenes Matt suchen, sonst den Datenbankzug nehmen. → kein Opfer mehr, spielstärke-neutral verifiziert.
• ▸Ehrlichkeit gehört dazu: Ein „TT-Aging"-Experiment wurde nach 2409 Partien per SPRT wieder verworfen (−15 Elo). Nicht jede gute Idee überlebt die Statistik - und genau dafür ist sie da.

Das kuratierte Erfahrungsbuch

Damit die Engine nicht jede bekannte Stellung neu errechnen muss, sammelt ein „Erfahrungsbuch" tiefe Such-Urteile - und das wird gepflegt wie ein eigenes kleines Datenformat.

• ▸Was es ist. Ein Eröffnungs-/Erfahrungsbuch im kompakten JBK2-Format (32 Byte pro Eintrag: Zug, Bewertung, Win/Draw/Loss-Statistik, Quelle) - gespeist aus Engine-Selbstspiel und echten Live-Bot-Partien (WDL-„Harvest").
• ▸Wie es kuratiert wird. Ein Overlay sammelt neue Partien; per expmerge wandern sie ins Hauptbuch (Priorität einstellbar, Heim-Buch zuerst). Ein Pflicht-Schritt entfernt nachweislich schlechte Eröffnungszüge („Gift-Einträge"), die das Selbstlernen sonst wieder einsammeln würde.
• ▸Mehrquellen-sauber. Source-Bits merken pro Eintrag die Herkunft, getrennte Bewertungsfelder verhindern Überschreiben, und ein „Golden-Fixture"-Test garantiert byte-identische Merges.
• ▸Eckdaten. Basis-Buch rund 192.000 Einträge, aus Self-Play erzeugt und frei weitergebbar; das Live-Buch wächst laufend per Harvest + Merge.

Ein Rechenzentrum aus Resten

Die Millionen Trainingsstellungen entstanden nicht in der Cloud, sondern auf einem zusammengewürfelten Heimcluster - Desktop, alte Laptops, sogar Smartphones unter Termux, per SSH orchestriert - ergänzt um einen gemieteten VServer, der als Einziger das ganze Jahr durchläuft.

Wenn KIs miteinander reden

Jedes Teilprojekt - Engine, Bot, Training, Website - hat seine eigene KI-Instanz. Damit sie abgestimmt arbeiten, tauschen sie Fakten über einen schlanken Nachrichten-Bus aus. clrsrc ist der Hub.

Manche Instanzen antworten sogar autonom auf eingehende Nachrichten - abgesichert durch mehrere Bremsen: begrenzte Antwort-Tiefe, Cooldowns, Tageslimit, Budget-Deckel und einen Kill-Switch. Eine menschliche Nachricht setzt die Kette jederzeit zurück.

Fünf Spezialisten, ein Werkzeugkasten

Jede Instanz hat ein eigenes Aufgabengebiet - und dafür selbst gebaute Werkzeuge, im Claude-Code-Jargon Skills: kleine, wiederkehrende Arbeitsabläufe, die sich per Befehl starten lassen. Was die vier Arbeits-Instanzen können:

Und die fünfte Instanz? Sie hat diese Seite gebaut - statisch, ohne Framework - und bezieht ihre Zahlen ausschließlich aus den geprüften Fakten der anderen vier. Über allen liegt geteiltes Werkzeug: der Nachrichten-Bus mit gemeinsamem Faktenlog, ein automatischer Check auf neue Post am Ende jeder Antwort, ein Autopilot für den headless-Betrieb und eine Crash-Recovery, die jede Sitzung mit vollem Kontext fortsetzen kann.

Wer macht eigentlich was?

Das ist Vibe Coding in der ernsthaften Variante: nicht „blind generieren lassen", sondern in natürlicher Sprache die Absicht vorgeben - und jede Engine-Änderung anschließend per SPRT statistisch beweisen. Vibe trifft Messlatte. Ohne diese Partnerschaft gäbe es das Projekt nicht.

Die unendlichen Stellungen

Schach lässt sich nicht „durchrechnen". Es gibt eine perfekte Lösung - aber sie ist praktisch unerreichbar.

Der Ausweg sind zwei Hebel, die sich multiplizieren: schlauer suchen (den Suchbaum aggressiv beschneiden) und besser bewerten (das NNUE). Genau diese zwei Hebel sind die ganze Geschichte dieses Projekts.

Offen und sauber

• ▸Eigenständige Engine, offen. clrsrc ist kein Fork - eigene Suche, eigenes Netz -, steht unter GPL-3.0 und liegt vollständig im Quelltext auf GitHub.
• ▸Aufgesetzt auf der Open-Source-Community. Einzelne Bausteine (z. B. das Zeitmanagement und der SIMD-Kernel der Bewertung) sind aus anderen GPL-Engines wie Stockfish, Stash und Viridithas adaptiert - jede Quelle ist offen ausgewiesen. Genau deshalb steht clrsrc selbst unter GPL-3.0.
• ▸Eigene Trainingsdaten. Die Stellungen sind selbst per Selbstspiel erzeugt - keine fremden Massendatenbanken.
• ▸Teacher sauber getrennt. Beim Training labelt Stockfish die Stellungen als externer Prozess; sein Code wird nicht mitgeliefert oder gelinkt.
• ▸Der Bot eigenständig lizenziert. Der Lichess-Bot LiRu-Bot ist eine Rust-Portierung des offiziellen lichess-bot (lichess-bot-devs) und steht unter AGPL-3.0, die Engine unter GPL-3.0. Im Standard-Build laufen beide als getrennte Programme; im eingebetteten Live-Build sind sie ein kombiniertes Werk - kein Konflikt, da die AGPL die GPL abdeckt. Upstream kreditiert.
• ▸Faire Nutzung freier Daten. Wo Lichess-Daten einfließen, sind sie ausdrücklich frei (CC0).

Vollständige Danksagung an alle Projekte, aus denen Code, Algorithmen oder Datenformate stammen, in der CREDITS-Datei auf GitHub ↗.

Wohin es geht

• ▸Das NNUE-Plateau überwinden - größere Netzarchitekturen und tiefere Trainings-Labels, jeweils per SPRT gemessen.
• ▸Aufnahme in die CCRL-Ranglisten vorbereiten - erst dann gibt es hier eine offizielle Elo-Zahl.
• ▸Den Bot @clrsrc_lc0 im stabilen Dauerbetrieb halten.
• ▸Eine Blog-Serie aus dieser Geschichte: NNUE-Training, der Smartphone-Cluster, KIs die reden, SPRT als Disziplin.