人機大戰結束了。感覺人類棋手已經勘破一些alphago的破綻，大致掌握了戰略走向，只
是實踐起來仍有非常難度。假如說李世石在五場對弈中取得進步，那麼alphago呢？或者
說alphago背後的google工程師呢？
評論alphago在唯一敗局中展露的缺點，應該以FB工程師田淵棟的分析最具公信力。畢竟
他手上有一套darkforest隨時可以佐證棋步的勝率估計，更重要的是他本身就是頂尖ML演
算法工程師，對演算法缺失的直覺應該同等於李世石對圍棋勝負的理解。他提出了兩種面
向，一種是MCTS搜索過早結束，一種是對葉節點的勝率估計出了問題。然而相同的猜測是
，這兩種失誤都容易在盤面需要複雜計算才能算清的情況下出現。假設google事後調閱
log檔發現原因果真如此，這個工程問題該如何解決呢？
也許一般人會想，換掉訓練資料就好啦，這次挑選一些複雜盤面的棋譜再對兩個神經網路
重新或增強訓練，還不把人類棋手趕盡殺絕？不過要訓練出一個好的ML模型並不是真的狂
灌資料就能辦到了。假如模型複雜度不足，卻硬吃太多資料變異性，相當於加偏差
(biased)資料下去，可能降低模型的泛化能力。反過來說，一味提升模型複雜度則會造成
訓練過程困難。雖說ML研究本來就有一些經驗法則的味道，但工程師困在這種try and
error的迴圈裡不是google這種等級應該花時間幹的事。以下試著提供三點從工程師思維
出發的解決方案：
1. 目前論文上的MCTS搜尋策略還是有缺點的。當搜尋樹抵達一定深度時，就開始對葉節
點進行勝率估計。若沒看漏細節alphago並沒有對這個搜尋深度進行動態調整，但當棋局
陷入難以算清的盤面時，棋手本來就該投入更多思考時間分析最佳解，例如第四局李世石
的40分鐘78手就如是。所以最直覺的做法是一旦陷入這種局面，alphago的搜尋深度就得
在考慮時間限制之下盡可能提高。
2. 勝率估計出問題可能原因有二。一個是價值網路預測不準，一個是快速走子模擬勝負
的結果不佳，最糟的情況是如前面一篇分析文章的作者陳經所說的兩者皆差(順帶一提我
覺得他的分析很不錯)。論文中對勝率估計的權重設計相當偷懶，就是一半一半。Google
工程師若事後檢查，發現在難以算清的盤面上其中一種估計品質極差，就該根據盤面複雜
度動態調整權重值。若不幸的是worst case兩者皆差，那麼我建議在時間限制許可下啟用
policy network進行走子勝負預測。
3. 採用前兩點補丁都有一個前提：如何決定盤面複雜度？這裡就是很主觀的個人看法了
，我認為google可以再訓練一個風險網路(risk network)，專門根據盤面判斷此時落子的
風險程度。這個模型的預測目標與勝率無關，所以與價值網路/走棋網路的性質應該要起
到互補作用，專門泛化那些一觸及發的棋局的pattern。當然這個做法的問題是如何定義
與生成訓練資料，但這件事對有豐富圍棋知識背景的開發團隊而言應該不難解決。
基本上工程師思維就是主要框架不動，並且在方法原本精神下(ML+MCTS)提供可靠的補丁
機制。以google現在擁有的資源，完成這些事應該不用三個月。三個月後……alphgo可能
真的可以變身betago了。