比賽結果
這 600 盤棋來自 300 組暗子佈局,每組紅黑互換各下一次,用 4 個執行緒,每步 4 秒。和 jqe 對上一版 AB-JChess 的比賽一樣,我們的裁判程式把任何三次重複局面,以及雙方各連續 60 步無吃子,都判為和棋。暗子被吃時,裁判程式會向兩個引擎公開它是什麼;在 Mistboard 上,只有吃子方才會知道。
| AB-JChess | 勝-和-負 | 得分率 |
|---|---|---|
| 全部 600 盤 | 306-67-227 | 57% |
| 執紅 | 172-34-94 | 63% |
| 執黑 | 134-33-133 | 50% |
AB-JChess 的優勢幾乎全部來自執紅的對局。整場比賽約合 +46 Elo,95% 區間為 +23 to +69。按 Mistboard 自己的重複局面規則計分則約為 +41,下文會說明。
用兩個引擎解讀五盤棋
如何查看這些對局
每個棋盤都從兩個引擎意見不同的一步開始,走這步棋的一方最終輸棋或和棋。只要兩個引擎選擇的著法不同,藍色箭頭就表示 AB-JChess 的選擇,橙色箭頭表示 jqe 的選擇。棋盤下方的曲線是兩個引擎按比賽設定評估的勝方勝率,AB-JChess 用青綠色,jqe 用橙色;著法列表中的註釋說明局勢在哪裡轉變,以及各引擎當時的預期。翻子旁的骰子根據雙方可見的資訊,為這次翻子的運氣評分;研究中收錄了全部六盤棋。
第 1 盤 AB-JChess 獲勝:一步進兵輸掉殘局
所有棋子都已翻開,局面均衡。jqe(紅方)選擇進兵,AB-JChess 則會用馬換掉黑方的士。AB-JChess 立刻看出,進兵會讓黑炮轉到另一側攻擊紅帥;jqe 八個回合後才看出來。第 103 回合,紅方無合法著法,黑方獲勝。jqe 為什麼進兵?時間不夠並不是原因:把搜尋量增至 16 倍,它仍選擇進兵,仍判斷為必和。它對局面的判斷有誤,並非漏算了某步棋。AB-JChess 關閉長捉規則,並增加同樣的搜尋量後,仍能看出進兵會輸。
第 2 盤 AB-JChess 獲勝:翻子決定勝負
黑車已經進入紅方底線。jqe 把它撤回,AB-JChess 則會讓它留下。後來的兩步棋決定了勝負:第 35 回合紅方翻出兵,兩個引擎都認為局面均衡;第 36 回合紅方暗吃一子,兩個引擎都認為紅方已是勝勢。紅方在第 66 回合獲勝。兩個引擎對這兩步的判斷相同,所以這盤棋無法說明它們對車的處理誰對誰錯。
第 3 盤 AB-JChess 獲勝:jqe 走炮引出一連串不利的兌子
紅方在第 14 回合用炮暗吃一子後佔優。jqe 走炮,引出一連串兌子:黑方用卒和馬換掉紅方的相和仕。AB-JChess 認為這些兌子對黑方不利,jqe 卻認為沒有問題,兩個回合後才同意 AB-JChess 的判斷。紅方在第 72 回合獲勝。連續三次翻子促使 jqe 改變判斷,所以這個例子的說服力不如第 1 盤。
第 4 盤 jqe 獲勝:AB-JChess 兩次翻子不利
棋盤上還有很多暗子,jqe 已經認為黑方佔優。AB-JChess 走了一步沒有直接威脅的炮棋,jqe 則會翻子。兩個引擎都無法看清翻子後的走向,所以無法判斷誰對。運氣決定了勝負:AB-JChess 在第 19 回合翻出兵,隨後又翻出車,立刻被黑炮吃掉。黑方在第 30 回合獲勝。
第 5 盤和棋:AB-JChess 已是勝勢,卻走成重複局面
紅方在這盤棋的大部分時間裡都大幅領先,但黑方逐漸追了回來。第 50 回合紅方翻出兵後,AB-JChess 認為黑方已是勝勢。隨後紅車和黑象來回移動,同一局面出現三次,比賽判為和棋。AB-JChess 沒有預見到重複局面,因為比賽只向每個引擎提供當前局面,沒有提供此前的著法。
第 1 盤相差八個回合,是較長的情況,另外四盤只差兩三個回合。縱觀整場比賽,以每個引擎自己的評分開始持續給最終勝方至少 70% 勝率的回合為起點比較,AB-JChess 的 304 盤勝局中,有 232 盤兩個引擎相差不超過一個回合;判斷有先後時,較晚的是 jqe 的有 119 盤,是 AB-JChess 的有 72 盤。在 jqe 的 227 盤勝局中,兩者判斷較晚的次數接近,AB-JChess 有 76 盤,jqe 有 75 盤。
它們的下法有何不同
jqe 高估了小幅優勢
jqe 認為自己略佔優勢時,最終贏棋的比例低於 AB-JChess 給出相同評分時的比例。
| 小幅優勢(+50 to +150),第 6 到第 30 回合 | jqe | AB-JChess |
|---|---|---|
| 最終得分率 | 46% | 64% |
| 局面數 | 592 | 595 |
無論輸贏,jqe 都暗吃更多棋子
兩個引擎在贏棋時都暗吃得更多,因此表格按比賽結果分組。
| 每盤暗吃子數 | jqe | AB-JChess |
|---|---|---|
| 勝局中 | 2.2 | 1.8 |
| 和局中 | 2.2 | 1.4 |
| 負局中 | 1.8 | 1.4 |
我們沒有測出這給 jqe 帶來什麼損失。在接近均衡的局面中,暗吃後再走一步,jqe 的勝率平均下降 1.7 個百分點,AB-JChess 下降 0.7 個百分點,這一差距小於樣本中的隨機波動。
這場比賽說明了什麼
一半暗子佈局本身就決定了勝負
每組暗子佈局都紅黑互換下了兩盤。在 300 組佈局中,有 147 組是同一顏色兩盤都贏,其中紅方 93 組,黑方 54 組,也就是說,無論哪個引擎執這一方,勝負都由佈局決定。AB-JChess 的優勢來自其餘佈局:同一組佈局的兩盤都贏,它做到了 56 次,jqe 做到了 34 次。
AB-JChess 的優勢在於判斷,而非搜尋深度
在 AB-JChess 的勝局中,jqe 判斷出結果較晚;而在 jqe 的勝局中,兩個引擎沒有誰明顯更晚。第 1 盤裡,把搜尋量增至 16 倍後,jqe 仍把必輸殘局判斷為必和;它認為自己略佔優勢時,最終得分也低於 AB-JChess 給出相同評分時的得分。兩者都說明:jqe 的問題在於如何評估平靜局面和兌子,而非搜尋得不夠遠。兩個引擎都不會搜尋翻子之後的著法,所以對雙方而言,翻子都仍需猜測,第 4 盤就是如此。
按 Mistboard 的規則,大部分和棋都不該判和
我們的裁判程式把所有三次重複局面都判為和棋。Mistboard 則將重複過程中每一步都將軍的一方判負。67 盤和棋中,有 42 盤是一方長將,其中 40 盤兩個引擎都已認為另一方是勝勢,持續將軍成了劣勢方避免輸棋的辦法。按 Mistboard 的規則計分,AB-JChess 贏 323 盤,和 25 盤,輸 252 盤,約合 +41 Elo,95% 區間為 +17 to +66。上面的 +46 保留了裁判程式的規則,和 jqe 對上一版 AB-JChess 的比賽相同,便於比較兩場比賽。
仍判和棋的 25 盤中,有 9 盤兩個引擎都認為一方已是勝勢,卻仍走成了重複局面,其中 8 盤是 AB-JChess 佔勝勢。這正是第 5 盤暴露的問題:比賽中每個引擎只能看到當前局面,無法預見重複。Mistboard 會向電腦發送自上次吃子或翻子以來的著法,所以它們能夠發現重複局面。
兩個引擎還各自帶有長捉規則,也就是一方持續攻擊同一棋子所形成的重複局面的規則,兩者都與 Mistboard 不同。jqe 將重複過程中每一步都捉同一棋子的一方判負。AB-JChess 則只要一方有任何一步捉子,而另一方從未捉子,就將前者判負。
此後紅車每走一步都攻擊黑馬。按 jqe 的規則紅方判負,所以 jqe 直到終局都給黑方至少 72% 的勝率;按 AB-JChess 的規則,黑馬也在反捉,因此它判斷為和棋。Mistboard 對長捉判和,所以 jqe 依賴的是本站對局並不採用的規則。逐步查看棋盤,可以比較兩個引擎開啟和關閉各自規則時的搜尋結果。
神經網路更小,搜尋更快
新版本基於 Devin O'Keefe 以 MIT 授權發布的 jqe 程式碼重建,使用自己的神經網路。這個網路是 0.6 MB,上一版是 144 MB,jqe 的是 1.5 MB。小網路執行得快,所以新版本每秒查看的局面數約為上一版的 65 倍,也比 jqe 略多。
每個引擎在 4 秒內搜尋約 22 百萬個局面。為檢驗它們是否時間不足,我們讓各引擎用兩倍搜尋量,重新搜尋 20 盤棋中自己走過的著法。AB-JChess 會在 20% 的時候改走別的棋,jqe 則是 18%,對兩者而言,每步改動平均都只增加 0.07 個百分點的勝率。提高至少 5 個百分點的改動,AB-JChess 在 754 步中出現一次,jqe 在 750 步中出現一次。更多時間對雙方都有一點幫助,幫助的程度也相近。
覆盤
揭棋覆盤使用 AB-JChess,因此新覆盤會採用新版本。在我們的伺服器上,它每秒搜尋的局面數約為舊版的 47 倍,同樣時間裡覆盤能看得更遠。
覆盤中的評分是引擎自己的數值,每個神經網路的尺度不同。舊網路的尺度很陡:+1.1 就已表示 75% 的勝率。新網路的尺度與 jqe 接近,75% 對應 +4.1。所以同一局面現在會顯示更大的數值,我們用這場比賽中的 9,776 個局面擬合了新網路的勝率。舊覆盤保留舊數值,因此比較新舊覆盤時,要看勝率,不要直接比較評分。
致謝
AB-JChess 以 GPL-3.0 授權開源,地址是 github.com/lxsgx23/AB-JChess。每次建置網站時,神經網路都從作者自己的發布版本下載,我們不另行託管。感謝 Huorongrong 和 Laoxu(Kouza)。Laoxu 負責訓練 AB-JChess 的神經網路,這次測試了四種翻子搜尋方法,保留了最好的一種;他與 Huorongrong 共同設計了這個小而快的網路。也感謝 Devin O'Keefe,新版本基於他提供的程式碼開發。