엔진 플레이의 임의성

동일한 색상으로 두 대의 엔진을 서로 맞대면 매번 같은 게임 결과가 나옵니까? 그렇지 않다면, 엔진 플레이의 무작위성은 어디에서 오는가? (시작 실수를 무시합니다. 실수하지 않으면 책이 엔진이 두 가지 동작 중 똑같이 좋기 때문에 무작위로 선택하도록 지시 할 수 있습니다.)

Alphazero와 Stockfish 경기에서 같은 경기가 여러 번 연속적으로 발생하지 않기 때문에 임의성이 있다고 가정합니다. 그러나 나는 왜 그런지 이해하지 못한다. 아마도이 작업을 수행하는 유일한 방법은 엔진이 일부 시간 동안 서브 파 이동을 수행하는 것입니다.

AlphaZero 건어 대 경기와 관련,이 질문은 이미 덮여있다 여기 에서 SmallChess .

Stockfish 및 기타와 같은 일반적인 휴리스틱 기반 체스 엔진의 경우 건설에 의해 결정적이지 않게 만들어 지는 AlphaZero (제외 된 몬테카를로 ¹ 루틴을 사용) MC 기반 루틴이있는 엔진 인 AFAIK Rybka는 이러한 기능을 가지고있었습니다.) 랜덤 소스는 일반적으로 엔진의 의사 결정에 의도적으로 랜덤이 도입되는 것이 아니라 구현상의 기술적 측면의 결과 일뿐입니다. 추상적으로 말하면, 그 이유 중 하나는 엔진이 순차 방식으로 실행되고 있지 않기 때문입니다 (하나의 작업을 차례로 수행함). 대신 엔진의 효율성을 높이기 위해 가능한 이동 트리의 다양한 분기에서 병렬 검색을 수행합니다. 그들은 멀티 스레딩 (또는 프로세싱)을 통해 그렇게 하지만 약간 다릅니다. 따라서 여러 CPU 스레드가 동시에트리를 검색하고 방문한 위치의 평가를 캐시하기 위해 작업을 실행하므로 각 스레드에 하위 트리가 할당되어 있다고 가정하십시오. 이러한 종류의 구현의 문제점은 스레드의 전체 실행이 모든 종류의 조건 (대기 시간, RAM 스왑 등)에 크게 의존하므로 결국 다른 모든 것을 허용하지 않고 주요 변형을 선택할 수 있다는 것입니다. 검색을 완료하기 위해 스레드.

실제로 엔진이 일정 시간 내에 결정을 내 리도록 설정되어 있기 때문에 종종 발생하므로 시간 관리가 동작을 변경합니다. 알고리즘을 알고 결정 론적 스레딩 루틴을 구현하는 것만으로는 시간 t 이후 프로그램의 상태를 안정적으로 예측하기에 충분하지 않습니다. 물론 모든 스레드가 항상 검색을 완료하도록 허용하고 해당 실행 중에 동시성 문제가없는 경우 (예 : 액세스 할 수없는 특정 캐시에 액세스하려는 스레드) 동작은 실제로 완전히 재현 가능합니다. 다른 모든 것을 감안할 때 ² 입니다.

^{1 : 추가 훈련 (예 : 셀프 플레이)을 통해 신경망이 계속 진화하고 (재조정 된 매개 변수), 평가 기능에 휴리스틱 기반 엔진과 달리 일정하고 고정 된 정의가없는 경우 ).}

^{2 : 그럼에도 불구하고, 당신이 말한 것처럼 오프닝 레벨에서 오프닝 북으로, 어떤 변형을 선택해야하는지에 따라 엔진에 의해 의도적 인 무작위 결정이 내려지는 경우가 있습니다. 마찬가지로, 개방 단계 외부에서는 여러 변형이 동일한 평가에 거의 근접하는 순간이있을 수 있으며 (Eval에 대해 선택된 해상도 내에서) 설계에 따라 무작위로 하나를 선택할 수 있습니다. 마지막으로, 엔진 설정 수준에서 각 엔진에 대해 선택된 검색 깊이 및 숙고 시간 (및 서로의 숙고 시간 동안 추가로 계산할 수 있는지 여부)과 같이주의해야합니다.}

@Phonon 덕분에 이전 답변에 대해 자세히 설명했습니다. 시간 제어라는 점을 하나 더 추가하고 싶습니다 .

결정적인 시간 제어는 노드 수에 의해서만 이루어 지지만 이는 드문 일입니다. 훨씬 더 일반적인 시간 제어- 고정 된 초 수 또는 게임 시간 은 일반적으로 결정적이지 않습니다.

예를 들어 봅시다. 터미널에서 stockfish를 실행하십시오. 유형:

이동 시간 20000으로 이동

이 명령은 20 초 후에 엔진이 움직 이도록 지시합니다. 내 결과 :

info depth 23 seldepth 32 multipv 1 score cp 6 upperbound nodes 24325860 nps 1216171 hashfull 999 tbhits 0 time 20002 pv g1f3 d7d5
bestmove g1f3 ponder d7d5

이동은 1.Nf3이었다. 다음으로, 나는 Stockfish를 죽이고 새로운 것을 시작했습니다. 다시 20 초. 나는 얻었다 :

info depth 23 seldepth 32 multipv 1 score cp 20 nodes 26185280 nps 1309067 hashfull 999 tbhits 0 time 20003 pv d2d4
bestmove d2d4 ponder g8f6

1.d4입니다! 같은 위치, 20 초 검색!

당신이 보여요? 이동하는 데 20 초가 걸렸지 만 Linux 운영 체제의 변동으로 인해 두 번째로 더 많이 검색했습니다 (26185280> 24325860).

이 작은 실험은 다중 스레드조차도 아니 었습니다 (스레드 수 = 1). 멀티 스레딩은 일을 더욱 비 결정적으로 만듭니다.

스톡 피시는 구글 알파 제로 경기에서 1 분마다 1 분씩 받았다. 스레드 수는 64 개였습니다. 경기에서 Stockfish의 결정은 결정적 일 수 없었 습니다 .