Sieben auf einen Streich
In einer Woche (11.–17. Juni) hat unser Lichess-Bot @clrsrc_lc0 von 2498 auf 2602 Blitz zugelegt – +104 Punkte. Das ist kein Silberbullet, sondern die Summe aus sieben Verbesserungen, jede einzeln per SPRT bzw. bench-Gate abgesichert, bevor sie live ging. Der technische Durchlauf:
1. Neue NNUE-Generation
Neu trainiertes Bewertungsnetz auf überarbeiteter Datenpipeline, mit feineren Königs-Buckets (16 Buckets – ein Paar pro Rang statt grober Zusammenfassung), breiterer erster Schicht (1024) und Feature-Faktoriser im Training. Feinere Buckets = positionsabhängigere Königssicherheit, mehr Schichtbreite = mehr Kapazität. Der größte Einzelsprung.
2. IIR-Neuplatzierung
Internal Iterative Reductions feuern jetzt nach den Pruning-Gates statt davor – ein Ein-Zeilen-Reorder, der die Zugsortierung messbar verbessert (mehr Knoten auf den besten Zug).
3. Buch-Kuration
Vorhandene Buchlinien gegen eine starke Referenz-Engine bei hoher Tiefe neu bewertet und klar unterlegene Züge entfernt – selbstverschuldete Nachteile aus dem Eröffnungsbuch geschnitten.
4. Mop-up-Term
Gegateter König-Treib-Gradient, der nur in bauernlosen, klar gewonnenen Blank-König-Endspielen greift: treibt den einsamen König an den Rand und bringt den eigenen näher → Gewinn in weniger Zügen, geringeres 50-Züge-/Zeit-Remis-Risiko. Außerhalb des Gates exakt null Einfluss.
5. rule50-Eval-Skalierung
Das NNUE sieht den Halfmove-Clock nicht und überschätzt darum Stellungen, die real ins 50-Züge-Remis laufen. Das Netz-Output linear mit steigendem Clock heruntergeskaliert (NNUE-Standard) – die Engine spielt nicht mehr auf einen Gewinn, den die 50-Züge-Regel kassiert.
6. Kritikalitäts-bewusstes Zeitmanagement
Die Per-Zug-Zeitdecke war zugleich Budget und harte Grenze – das flachte die eingebaute Eskalation ab. Beides entkoppelt: die Engine darf in instabilen/Verteidigungs- Stellungen (fallende Eval, wechselnder bester Zug) länger rechnen, während eine separate, großzügige Hard-Grenze garantiert, dass sie nie die Zeit überzieht.
7. Zuverlässigere Gegnersuche
Infrastruktur-Fix: der Gegner-Pool wurde zu flach abgefragt → Leerlauf, wenn passende Gegner außerhalb der ersten Seite saßen. Tiefere Abfrage → weniger Idle, mehr Wertungspartien.
Wie das entsteht – die Arbeitsweise
clrsrc wird von mehreren spezialisierten KI-Instanzen (Claude) entwickelt, die über einen gemeinsamen Nachrichten-Bus zusammenarbeiten – jede mit eigener Domäne: Engine/Suche, Bot-Betrieb auf Lichess, NNUE-Training, Engine-Architektur-Referenz (Abgleich gegen Dutzende Open-Source-Engines) und Website. Der Mensch gibt die Richtung vor und gibt jeden Live-Deploy frei.
Der Zeitmanagement-Fix (Punkt 6) ist das Musterbeispiel – drei Instanzen, ein Tag:
- Die Bot-Instanz bemerkte über die Live-Telemetrie, dass die Engine in Verteidigungsstellungen genauso wenig Zeit nahm wie in Gewinnstellungen – flach über die ganze Bewertungs-Lage.
- Die Engine-Instanz führte das am Quelltext auf die Ursache zurück: die Kritikalitäts-Eskalation war da, wurde aber von der Zeitdecke abgeklemmt.
- Die Referenz-Instanz lieferte aus dem Vergleich starker Open-Source-Engines das Lösungsmuster – weiche Schwelle und harte Decke entkoppeln statt das Produkt zu klemmen.
- Gebaut, per SPRT geprüft, freigegeben, deployt – am selben Tag.
Sieben solcher Schleifen in einer Woche: das ist, was diese Aufteilung möglich macht.
Kein einzelner Silberbullet – NNUE, Suche, Buch, Endspiel, Zeit, Infrastruktur, jeweils ein kleiner sauberer Schritt, einzeln verifiziert. Zusammen: die sieben des Schneiderleins auf einen Streich. Den Bot im Live-Betrieb siehst du auf der Live-Seite; der Quellcode liegt auf GitHub.