Wenn ich zwei Engines dazu bringe, mit denselben Farben gegeneinander zu spielen, wird dann jedes Mal das gleiche Spiel resultieren? Wenn nicht, woher kommt die Zufälligkeit im Motorspiel? (Vernachlässigen Sie das Eröffnungsbuch. Wenn ich mich nicht irre, kann das Buch den Motor anweisen, zufällig zwischen zwei Zügen zu wählen, da diese gleich gut sind.)
Ich gehe davon aus, dass es Zufälligkeiten gibt, weil wir im Match Alphazero gegen Stockfish nicht viele Male hintereinander dasselbe Spiel gespielt haben. Ich verstehe jedoch nicht warum. Vermutlich ist die einzige Möglichkeit, dies zu tun, die Engine dazu zu bringen, manchmal einen unterdurchschnittlichen Zug zu spielen, was nach Seppuku klingt.
Antworten:
In Bezug auf die AlphaZero vs Stockfisch Spiel, hat diese Frage bereits behandelt worden hier von SmallChess .
Abgesehen von AlphaZero (das bei der Erforschung der Spiellinien eine spezielle Monte-Carlo- 1- Routine verwendet), die konstruktionsbedingt nicht deterministisch ist , für die üblichen heuristikbasierten Schach-Engines wie Stockfish und andere (obwohl es andere gibt) AFAIK Rybka hatte Motoren mit MC-basierten Routinen) ist die Quelle der Zufälligkeit im Allgemeinen nur eine Folge technischer Aspekte bei der Implementierung, anstatt dass absichtliche Zufälligkeit algorithmisch in die Entscheidungsfindung des Motors eingeführt wird. Abstrakt gesehen ist ein Grund dafür die Tatsache, dass die Engines nicht rein sequentiell laufen (eine Aufgabe nach der anderen ausführen). Um die Engines effizienter zu machen, führen sie stattdessen parallele Suchvorgänge in verschiedenen Zweigen des Baums möglicher Bewegungen durch. Sie tun dies über das sogenannte Multithreading (oder -processing, aber das ist ein bisschen anders). Es sind also mehrere Threads der CPUs gleichzeitig vorhandenFühren Sie Operationen aus, um den Baum zu durchsuchen (und die Auswertungen der besuchten Positionen zwischenzuspeichern). Stellen Sie sich also vor, jedem Thread wird ein Teilbaum zugewiesen. Das Problem bei dieser Art der Implementierung besteht darin, dass die Gesamtausführung der Threads stark von allen möglichen Bedingungen abhängt (Wartezeiten, RAM-Swaps, ...), sodass am Ende eine Hauptvariante ausgewählt werden kann, ohne alle anderen zuzulassen Threads, um ihre Suche zu beenden.
Dies geschieht in der Tat häufig, weil die Engine so eingestellt ist, dass sie innerhalb einer bestimmten Zeit eine Entscheidung trifft, sodass das Zeitmanagement das Verhalten ändert. Sie können diese Aussage auch rückgängig machen, indem Sie sagen: Die Kenntnis des Algorithmus und die Implementierung deterministischer Threading-Routinen reichen nicht aus, um den Status des Programms nach einem beliebigen Zeitpunkt t zuverlässig vorherzusagen. Wenn man immer zulässt, dass alle Threads ihre Suche beenden, und während dieser Ausführung keine Parallelitätsprobleme aufgetreten sind (z. B. ein Thread, der versucht, auf einen bestimmten Cache zuzugreifen, auf den nicht zugegriffen werden kann), ist das Verhalten tatsächlich vollständig reproduzierbar vorausgesetzt, alles andere ist das gleiche 2 .
1 : Zusammen mit der Tatsache, dass sich das neuronale Netzwerk durch zusätzliches Training (zum Beispiel Selbstspiel) ständig weiterentwickelt (neu angepasste Parameter) oder wenn Sie so wollen, hat seine Bewertungsfunktion keine konstante, feste Definition (im Gegensatz zu heuristikbasierten Engines) ).
2 : Selbst dann, wie Sie sagten, gibt es auf der Eröffnungsebene mit einem Eröffnungsbuch manchmal absichtliche zufällige Entscheidungen der Engine, welche Variante zu wählen ist. In ähnlicher Weise kann es außerhalb der Eröffnungsphase Momente geben, in denen mehrere Variationen nahezu gleiche Bewertungen haben (innerhalb der für das Eval gewählten Auflösung), und dann basierend auf dem Design möglicherweise zufällig eine auswählen. Schließlich müssen Sie auf der Ebene der Motoreinstellungen auch vorsichtig sein, z. B. die Suchtiefe und die für jede Engine ausgewählten Überlegungszeiten (und ob sie während der Überlegungszeiten des jeweils anderen weiter berechnet werden können).
quelle
Vielen Dank an @Phonon, der meine vorherigen Antworten ausführlich behandelt hat. Ich möchte noch einen Punkt hinzufügen: Zeitsteuerung .
Die einzige deterministische Zeitsteuerung erfolgt über die Anzahl der Knoten , dies ist jedoch ungewöhnlich. Die weitaus häufigere Zeitsteuerung - feste Anzahl von Sekunden oder Spielzeit - ist im Allgemeinen nicht deterministisch.
Versuchen wir ein Beispiel. Führen Sie Stockfisch auf Ihrem Terminal aus. Art:
Dieser Befehl weist den Motor an, nach 20 Sekunden eine Bewegung auszuführen. Meine Ergebnisse:
Der Zug war 1.Sf3. Als nächstes habe ich meinen Stockfisch getötet und einen neuen gestartet. Wieder 20 Sekunden. Ich habe:
Es ist 1.d4! Gleiche Position, beide 20 Sekunden suchen!
Siehst du? Beide 20 Sekunden für den Umzug, aber aufgrund von Schwankungen im Linux-Betriebssystem hatte mein zweiter Lauf eine tiefere Suche (26185280> 24325860).
Bitte beachten Sie, dass dieses kleine Experiment nicht einmal Multithreading war (Anzahl der Threads = 1). Multithreading würde die Dinge noch nicht deterministischer machen.
Stockfish erhielt im Google AlphaZero-Match eine Minute pro Zug. Die Anzahl der Threads betrug 64. Stockfishs Entscheidungen im Match konnten unmöglich deterministisch sein.
quelle