黑棋在棋盤中央落下一子，白棋眼前沒有非擋不可的四連，卻看見兩條逐漸靠近的斜線。引擎把一個遠離交叉點的防守點排在前面；只看眼前的棋型，你可能想知道它究竟看見了什麼。
搜尋停下時，誰來為局面評分
引擎會沿著候選著法向前搜尋，嘗試雙方的應對。以alpha-beta 搜尋為例，它會剪去一些已無須繼續檢查的分支，但仍不可能在每個分支都走到終局。
搜尋在某個局面停下時，評估函數要給這個葉節點一個分數，供上層比較走法。比如黑棋的一條斜線尚未構成直接威脅，評分仍可能認為白棋此後更難兼顧兩側；搜尋據此決定要不要繼續追這條變化。
這個分數是對當前局面的估計，勝負還要看接下來的著法。葉節點停得越早，評估越需要辨認那些尚未成形、卻會影響後續選擇的關聯。
手寫棋型表能看見什麼
傳統做法會識別活三、衝四等形狀，再按預設權重合計。這樣寫很清楚：一處衝四通常比一處還需準備才能進攻的棋型更緊急，引擎可以據此先檢查防守著法。
以 15×15 自由規則下輪到白棋行棋的局面為例：黑棋左上方的斜向棋形與右側的橫向棋形都朝空著的天元延伸，白棋落在天元就能同時擋住兩邊。若手寫表分別給兩處棋形加分，卻預設每處都要單獨防守，就會重複計算防守代價，抬高黑棋的估值。手寫表還受限於編寫者預先列出的形狀。搜尋能發現部分遺漏，卻得先把相關分支展開；如果評估較早排除了關鍵候選，算力未必會花在那條線上。
從手寫規則走向訓練型評估
NNUE是「可高效更新的神經網路」的縮寫。據關於將棋引擎 YaneuraOu 與 NNUE 起源的公開資料，它由 Yu Nasu 於 2018 年發明，最先用於將棋引擎 YaneuraOu；名稱也借用了日本傳說中「鵺」的讀音。它讓訓練得來的判斷能在落子後較快更新，適合放進反覆評估局面的搜尋過程。
一個有用的參照來自西洋棋。據Stockfish NNUE 的公開引擎紀錄，到 2020 年 8 月，其搜尋速度約降了一半，棋力卻比使用傳統評估時至少高 80 Elo，隨後納入官方引擎。這說明較慢的搜尋有時仍能從更好的葉節點判斷中獲益。
評估換了方法，搜尋仍要驗證變化
學到的判斷，仍須逐手檢驗
訓練型評估可以從大量局面中學習棋形的組合關係，但它給出的仍是估計。白棋若有一步必須應對的衝四，黑棋看似寬裕的位置優勢就可能迅速失效；引擎還得把這條強制變化走出來。
搜尋方法也各有分工。PVS會先完整搜尋首選著法，再用很窄的窗口檢驗其餘著法，必要時回頭重算；蒙地卡羅樹搜尋則把更多模擬分配給值得追的分支；遇到VCT一類連續威脅，有的引擎另用證明數搜尋檢查是否存在必然的進攻路線。
因此，同一手棋可以先憑評估進入候選，再因具體應對被否定。看到引擎改變主意時，值得先找出雙方哪一步改變了威脅關係，而不要只比較前後兩個分數。
2026 年賽場上的不同搭配
據Gomocup 2026 官方賽事頁面的引擎更新說明，參賽引擎展示了幾種搭配：Figrid 用 alpha-beta 搜尋配合 NNUE 評估，還用威脅快取和延續歷史安排著法順序；Chloris 的自製 NNUE 約用 300 萬個 Standard-15 局面訓練，搜尋之外另設強制著法檢查和緊急防守層。
同一Gomocup 2026 官方賽事頁面記載，TKGomoku 保留手寫棋型評估，同時使用輕量 NNUE、策略檔案和開局庫；DDQK-Conquer 也採用了類似 NNUE 的演算法。頁面還提到，Starpoint 以蒙地卡羅樹搜尋配合 transformer 評估，並在內部用證明數搜尋處理 VCT。訓練型判斷進入了多種架構，具體用法並不相同。
賽果也不宜直接歸功於某一種評估。據Gomocup 2026 官方賽事頁面的賽果，RAPFI 在 2026 年衛冕 20×20 自由規則冠軍，又贏得 15×15 自由規則與快棋；新參賽的 KATAGOMO 在兩個自由規則組別均列第二，其中 15×15 組只差 9 Elo。評估、搜尋和時間分配共同決定一台引擎如何下棋。
讀懂一個出乎意料的推薦
引擎把安靜的一手排在直接成三之前，可能是看重它同時限制了兩條後續路線。手寫棋型表在落子當下看不到明確的高分形狀，訓練型評估卻可能給這種局面關係更高的權重；是否站得住腳，還要看搜尋找到的應對。
讀分數時要記住它的條件：規則、搜尋深度、用時和評估方式都會影響結果。同一局面換一個引擎，數值刻度和著法排序可能不同；先看推薦著法之後雙方怎麼走，再看分差是否穩定。
讓分數回到棋盤
復盤時，可以先找必須回應的威脅，再觀察引擎如何處理較遠的關聯。若一手棋暫時沒有造出衝四，卻讓對方下一回合只能守一側，就記下那道限制是從哪一步開始出現的。
評估函數改變了引擎挑選和衡量局面的方式，搜尋繼續負責檢驗具體變化。把兩者分開看，遇到陌生的推薦著法時，你就能問得更細：它看中了什麼，又算到了哪裡？
先核對強制變化，再讀局面分數