用概率下棋——運用「空壓法」,首先相信自己「一無所知」

用概率下棋——運用「空壓法」,首先相信自己「一無所知」
Photo Credit: Reuters/達志影像

我們想讓你知道的是

圍棋是藝術還是競賽,是永無答案的大哉問,但也可說答案其實很明瞭,圍棋既是藝術也是競賽。既是A又是B,這不是矛盾嗎?的確如此,人的自我本來就是一個矛盾,人類樂此不疲的圍棋存在矛盾,反而合情合理。

文:王銘琬

相信自己「一無所知」

十年前,圍棋軟體「狂石(CrazyStone)」用蒙地卡羅方法,以勝率為局面的評價函數,讓當時的電腦圍棋界大吃一驚,它的機制是,在所有局面做非常多次「隨機」的模擬到終局,其後選擇其中勝率最高的一手。

當時圍棋被認為是好棋與壞棋很分明的遊戲,教電腦下好棋都來不及了,哪有閒工夫讓電腦玩「隨機」的擲骰子遊戲?蒙地卡羅方法是統計學上很常用的手法,但沒有人覺得跟圍棋有關,將概率這個東西扯上圍棋的,除了十七年前我用空壓法拿到本因坊以外,就是「狂石」作者雷米柯龍。

結果狂石為圍棋軟體帶來重大突破,就算已經明顯超越人類的AlphaGo,它的評價函數一半還是蒙地卡羅法,而另一半的價值網路也是用概率來處理的。

圍棋可以計算著手價值為「×目」,因為有數字指標,至今圍棋評估以「大小是幾目」做基礎,對人來說是最方便的方法。然而如《新棋紀樂園》上集〈開天篇〉所敘述的,大小的比較對我而言非常困難,只好以概率作為自己的起點,「概率」雖然也是數字,但運用起來和確定的數字很不一樣。

把著手定位於「大小」可以說是靜態的思維,空壓法因為起源於人類的計算力不足,而什麼都無法確定,只好由概率出發;這樣圍棋會呈現動態的面向,對局者必須意識的,是自己在什麼樣的姿勢下,採取什麼樣的動作,本書下集〈闢地篇〉提供了兩個運用空壓法的訣竅「中點」與「交點」,我認為在最近的AI對局裡,多少得到驗證。

闢地篇_圖1
Photo Credit: 大塊文化
圖1:黑棋Master下出黑1,令人驚嘆,這個局面黑棋必須花一手把白A吃乾淨,至今的手法是黑B;此後的實戰例,對於黑B白棋還時常千方百計,在右下角黑棋模樣做活,以此而言,人類沒有捨B而改下1的理由;但從空壓法來看,現在局面的「易受影響區域」是下邊C至上邊D跨斷,加上左邊寬廣空間,黑1在確保白A征子的前提下,盡可能靠近易受影響區域的「中點」,是空壓法的標準動作。
闢地篇_圖2
Photo Credit: 大塊文化
圖2:黑1是至今還膾炙人口的阿法肩,對此李世乭長考後2、4應,這樣阿法肩就成為好棋,黑5後棋局一直在AlphaGo的主動下進行。
闢地篇_圖3
Photo Credit: 大塊文化
圖3:白1壓,才能打擊阿法肩損失實利的弱點,但黑2跳,黑棋中央厚實;李世乭對此圖沒有信心,不過我懷疑他是否沒有考慮白3肩,這個局面不只模樣,還有黑AB二子的引出,白3是空壓法不折不扣的「交點」。
闢地篇_圖4
Photo Credit: 大塊文化
圖4:Master白棋對黑1手拔,下白2這也是先鞭「交點」的標準動作,次有白A,而黑若是A應,白棋就得到明顯的「壓」的果實。
闢地篇_圖5
Photo Credit: 大塊文化
圖5:所以我一眼就覺得黑應立刻下1,才是此局面的「交點」,不過經過研究,對黑1白有2的逆襲,黑1不見得能那麼如意,Master讓白A巧妙的派上用場。

AI的概率判斷,是強大機器能力的產物,人類無法模仿;人在日常生活可能不知不覺會用概率的基準去行動,但人運用概率去思考,說不定因為經驗不夠,其實是不擅長的,人在做決定的時候,還是希望這個決定是確實的,而不是基於一個概率數字就拚命,這可說是人的本能。我是人,雖說我認為圍棋的廣大,能讓概率轉換為實際收穫,比起AI,我運用概率其實還是怕三怕四的。

DeepZenGo對趙治勳三番棋的第三局

闢地篇_圖6
Photo Credit: 大塊文化
圖6:DeepZenGo白棋,白1二間高締,手法的大膽超出我的預料。

這個局面,誰都會補強白棋左上角模樣,因為這個模樣很容易成為地,一般都會想補得堅實一點,很多人可能會下A,我充其量也是下B而已,直接下D、C,意圖讓模樣成為確定地也大有人在,然而白1至今是幾乎不被列入選項的。

闢地篇_圖7
Photo Credit: 大塊文化
圖7:黑1是白型的弱點,黑5為止白棋沒有立刻追擊的手段,上邊白地蕩然無存,想到這個結果,我會立刻放棄圖6白1的下法。
闢地篇_圖8
Photo Credit: 大塊文化
圖8:緊接著DeepZenGo白1打入下邊,這個打入與A相關聯,黑棋不好應付,實戰白13為止環顧全局,驚覺白棋形勢大好,從這個局面來看,白B,C,D與黑E,F,G的交換,白棋明顯佔了便宜,達到了「壓」的效果。

圖6白1因為是二間高締,十足用上「空」的壓力才能逼黑棋立刻侵入, DeepZenGo動用包括白A的全局資源,成功啟動「空壓連鎖」,從左上,下邊,左下,做到了一連串的「壓」的動作,可是我為了怕黑棋在上邊生根,一定無法得到這麼好的結果。

本書〈開天篇〉討論過,運用空壓法,首先需要信心——相信概率,而信心的依據,是自己的「一無所知」,在AI的棋力超過人的今天,自己「一無所知」這個理由應該是越來越堅強,而我看AI的對局,最常有的感想是「自己的信心還不夠」,因為人總愛幻想——認為自己得到了某些領悟!

圍棋是藝術還是競賽,是永無答案的大哉問,但也可說答案其實很明瞭,圍棋既是藝術也是競賽。既是A又是B,這不是矛盾嗎?的確如此,人的自我本來就是一個矛盾,人類樂此不疲的圍棋存在矛盾,反而合情合理。

人們忘我下棋,想要比前一刻多理解一點圍棋,但圍棋什麼都懂了就不好玩了,什麼都不懂才最能享受圍棋,這是一個快樂的矛盾,深知自己什麼都不懂,才能深知圍棋的奧妙。

李世乭對AlphaGo三連敗後,第四局終於贏得勝利,記者問他,在連戰連敗窮途末路的時候,為何還有力氣從強大對手扳回一城?

李世乭說:「儘管狀況超壞,我自己提醒自己,對局時不要忘記下棋的樂趣!」

相關書摘 ►AlphaGo下的棋看不懂?「空壓法」或許可以成為我們理解AI圍棋的切入口

書籍介紹

本文摘錄自《新棋紀樂園:闢地篇》,大塊文化出版
*透過以上連結購書,《關鍵評論網》由此所得將全數捐贈兒福聯盟

作者:王銘琬

在AI與真人棋士對局屢獲勝績後,趙治勳有感而言,王銘琬的棋術最像AI下法。新版《新棋紀樂園》的開天篇和闢地篇兩本書,王銘琬將為此做了精闢的解說。

有了「空」與「壓」的概念之後,《新棋紀樂園—闢地篇》中,王銘琬繼續為讀者指出尋找次一手的捷徑——「中點」與「交點」。著眼於「空」的邏輯,就從「中點」著手,下在中點,可讓對方失去選擇寬廣方向的餘地;著眼於「壓」的邏輯,則要找出雙方空間量交會的「交點」,因為該處的影響範圍是盤上最大,因此要從該處的「交點」去尋找次一手。

不過,不管是空壓戰法或是中點、交點,都有無盡的可能,王銘琬透過300盤不同棋局與詰問,講解圍棋的「無限」。圍棋要學AI下法,就從《新棋紀樂園》開始。

getImage_(1)
Photo Credit: 大塊文化

責任編輯:王國仲
核稿編輯:翁世航


猜你喜歡


挖掘雲端開放架構優勢!Amazon EKS高可用性叢集快速部署容器

挖掘雲端開放架構優勢!Amazon EKS高可用性叢集快速部署容器

我們想讓你知道的是

企業如何在 Amazon EKS(Elastic Kubernetes Services)上使用 GitLab 創建自動化部署,減輕人力負擔,提升專案服務運作效率?

所謂現代化智慧 IT,所有工程師最希望的境界,莫過於只要輕鬆點幾下設定,系統就會自動跑起來,管理者再也不用隨時待命在機台旁邊,從此工作悠哉又快樂!儘管這樣情境還沒到來,但隨著敏捷式開發的流行,除了 DevOps 人員,有越來越多開發者將 CI/CD 概念融入到工作流程當中,例如從 build code、執行 unit test、到部署應用程式。

透過 AWS 增加雲端技能 在組織發揮影響力

上述種種反覆步驟自動化執行,也就能提昇服務品質、主動通知開發人員以減輕人力負擔,讓專案服務能持續運作。

其中,GitLab 是執行 CI/CD 常用的工具之一,也是開發者使用程式碼儲存庫的地方。為了讓 GitLab Runner 在雲端快速實踐 CI/CD,《AWS 開發者系列》透過影片分享,如何在 Amazon EKS(Elastic Kubernetes Services)上使用 GitLab 創建自動化部署。

以下節錄工作坊影音內容,幫助開發者快速理解如何運用 Amazon EKS 的高可用性且安全的叢集,將修補、部署節點、更新等關鍵任務,全部做到自動化設定。同時影片也會示範 Amazon EKS 搭配 GitLab 如何展開自動部署,幫助工程團隊實踐 CI/CD 價值。

Amazon EKS 對容器管理輕鬆簡單、維運省時省力

容器化服務越來越興盛,當容器(Container)越來越多,在複雜的微服務(Microservice)系統環境之下,運維團隊的管理成本可能相對會增加不少,為了有效調度容器部署, 導入Kubernetes 無疑是近年企業熱門的話題之一。

建構 Kubernetes Cluster 流主要可區分兩大塊,一是安排容器調度的Control Plane、另一則是容器運行時需要用到的 Worker Node。

Control Plane 裡面涵蓋有儲存狀態的 ETCD、CoController manager 、Scheduler 的調度管理、甚至是操作時進行互動的 APIServer,若是自己創建 的 Kubernetes Cluster ,需要自己安裝這些元件,後續仍需要對 Control Plane 進行相關管理、維護、升級工作。為了減少上述 Components 的繁複維護,在透過 AWS EKS 代管的 Kubernete Control Plane 部可以獲得以下三大好處。

Amazon EKS 一鍵式部署,展現三大優勢

第一,Amazon EKS代管的 Control Plane實踐了跨AZ的高可用部署,使用者不需要擔心單一節點故障的風險。

第二,Amazon EKS 支持至少四個 Kubernetes版本,持續跟進每季 CNCF 的發佈,同時 EKS 也完全符合上游 CNCF 規範。

第三,部署 Amazon EKS 之後,可直接使用 AWS 平台上現成的服務工具,在安全性管理、網路設定方面,可以做到無縫整合。

最後 AWS 台灣解決方案架構師也提到,若想在容器環境進行 CI/CD 及應用程式的管理,可以進一步透過 IaC 整合部署 Amazon EKS 叢集,透過使用 Console、把 EKS 變成 Cloudformation 的模板、使用 AWS 所開發出來的 eksctl.io、或指令是採用 AWS CDK 可以讓開發者用自身熟悉的語言,在 AWS 平台整合 CI/CD 工具進行維運及部署 EKS。

打造第一個在 AWS 上的應用程式

了解 Amazon EKS 整合 GitLab ,獲得三面向價值

對開發者而言,想把 Amazon EKS 整合到 CI/CD 工具之一的 GitLab 平台上,可以看到那些實際的優勢?

在 DevOps 開發者示範工作坊當中,GitLab 資深解決方案架構師指出,GitLab 使用到 Kubernetes 技術,主要有三種搭配方法,包含 GitLab Server、GitLab Runner、以及創建 Deployment Environment。

本次示範教學會主要聚焦在 GitLab Runner 如何採取 Auto-scaled 方式進行 Build、Test、Package Apps;以及在 Deployment Environment 運用 Kubernetes 技術,做到 Auto Deploy、Review App。

正因為 Amazon EKS 能夠在 DevOps 過程提供所需要的彈性計算資源,幫助開發者在 GitLab 平台上面獲得以下三個層次的優勢:

  • 在 GitLab 內建的部署工作流程當中,自動生成整套 CI/CD 最佳實踐腳本。
  • Review App 過程,從 Merge Request 中可直接訪問應用程式 /App 的 UI 介面,並且根據 Git branch 名稱、專案名稱,自動生成 Review App 的 URL,以及在 Merge 前的最後防線進行 Approval 檢查。
  • 加速 CI/CD 流水線,GitLab Runner 運行時候還可藉由 Amazon EKS Cluster 進行 Auto-scaled 的支援。

Amazon EKS 整合 GitLab ,需要兩大流程

影片最後,GitLab 資深解決方案架構師示範如何把 Amazon EKS 整合至 GitLab 執行 Auto Deploy,主要可分為兩大區塊流程,第一部分聚焦在 Amazon EKS cluster 的設置,第二部分則執行 Auto Deploy 設置。

第一塊可拆分為四個階段,首先教學怎麼創建 EC2 節點的 EKS cluster,第二階段示範把 EKS Cluster 連接到開發者的 GitLab Instance、Group 或 Project,下一步則使用 Cluster Management Project Template 創建一個 Cluster Management Project,以及最後一階段透過 Cluster Management Project 自帶的 Helm Chart,安裝在 Cluster 所需要的內建 App。

第二塊執行 Auto Deploy 設置,針對需要部署的 App 創建一個 GitLab Project,接著再把 gitlab-ci.yml 添加到 Project,並從 Web IDE 選擇及導入 Auto Deploy 的 CI 模版,讓 GitLab 自動生成最佳實踐的整套流水線。

幫助開發者更了解 Amazon EKS 整合 GitLab 的 QA 系列

Q:使用 Amazon EKS 之後,如何更有效率或優化資源去配置 Worker Node 的機器數量,以及如何有效空管開發維運的成本?

A:Kubernetes 除了本身有 HPA(Horizontal Pod Autoscaling)可根據使用程度自動調整資源流量,另外也能延伸使用 AWS Auto Scaling 方案,針對可擴展資源去設定自動擴展管理。另外在成本管控,雖然 Amazon EKS 會收取額外管理費用,但可透過 AWS 平台的 Calculato r計算每個 EKS 的價格,你會發現自動化部署及管理的費用,相對工程師人力的成本更加便宜。

Q:越來越多客戶考慮把現有 Application 變成容器部署,大多是爲了加快部署的效率,那麼變成容器模式之後,對 CI/CD 的工作流程有什麽影響嗎?

A:運用容器技術最直接的效果,可以讓應用程式的環境更一致化,例如 testing 環節、stage production,讓容器避開一些差異問題。至於 CD 部分要 delivery 一些 usage 不太一樣的時候,容器會幫忙做配置,所以 CI/CD 對容器的效益是相輔相成的。

Q: 客戶在開發流程漸漸會把 Infrastructure 變成代碼或文檔,是不是可以把程式碼跟現有的應用程式的 CI/CD 流水線整合在一起,達到一套完整的 CI/CD 部署流程?

A:觀察目前市場作法,主要分成兩個階段去做整體部署。如果規模比較小的團隊,會把 Infrastructure 代碼跟 App 代碼分開,在管理上會比較靈活;如果企業規模比較大,會有另外一個 Infrastructure 團隊來控制部署事情,這種情况之下,APP 的項目會生成一個 APP package,主要做到 delivery 這個階段爲止。而 Infrastructure 的項目會指定把需要版本的文檔,部署到他們的 Kubernetes Cluster。

填寫表單 找到適合的快速上雲服務與工具!


猜你喜歡