今天大部分時間都在鑽研數據庫建構的程式碼，嘗試理解它如何將撲克牌局記錄轉化為結構化的資料庫。老實說，雖然大概掌握了60%的邏輯，但細節處仍有許多迷霧籠罩著我。
程式的核心邏輯其實與我之前用來提取特徵點訓練機器學習模型的代碼類似，只是現在轉向了資料庫的建構。然而，縱使我對SQL有基本認識，表與表之間的關聯（SQL的外鍵邏輯）對我來說還是顯得有些陌生。這就像是知道每個房間的功能，卻不太清楚它們之間的走廊如何相連。
當我開始拿自己建構的數據與Hand2Note產生的統計資料進行對比時，表面上看似相符，但深入特定情境（如小盲位置在14-18大盲籌碼區間的行動分佈）後，卻發現了一些差異。這並不意外，畢竟我的程式還處於初期階段，我對它的理解也還不夠深入，無法進行全面檢查。
其中一個有趣的差異是在all-in的定義上。在Hand2Note中，只有玩家將所有籌碼都推出去才被視為全押；而在我的程式中，即使玩家留下了一點點籌碼（例如推出80%的籌碼），也被歸類為全押。這種細微的差異可能會導致統計結果的偏差。
目前當我需要查詢特定資料點時，由於不熟悉SQL語法，我不得不依賴語言模型為我編寫查詢語句。這帶來了一個不小的挑戰：語言模型確實能依照我的指令生成查詢，但問題在於我常常表達不夠精確。就像今天，我只請求了「小盲位置的行動分佈」，而沒有明確指定是「小盲位置的第一個行動分佈」，這意味著結果中可能混入了小盲在面對BB反應後的行動，而非我真正想要的資訊。
與使用現成工具如Hand2Note相比，這些細節在專業軟體中都已經被考慮周全，用戶只需選擇想要的統計資料即可。而自建系統則要求我思考每一個細節，這確實是一種學習，但也是一種障礙。我需要訓練自己更加細緻地思考每個查詢需求。
儘管如此，我還是看到了自建數據庫的潛力。相較於現成工具的固定框架，自建系統提供了無與倫比的靈活性。例如，對於「幾乎全押」的情況，我可以根據需要自由定義分類標準，而不受限於工具的預設規則。
下一步的關鍵是確保數據庫的準確性，因為這是整個項目的基石。若基礎數據有誤，後續所有分析都將偏離正軌，導致誤導性的結果。一旦確立了準確的數據基礎，我希望能建立一個系統，讓我能瀏覽決策樹的每個節點，繪製出行動頻率和手牌分佈。這將為訓練撲克機器人或學習如何對抗特定類型的玩家提供強大的工具。
在過去，我需要手動收集這些數據，然後自行分析，這不僅耗時耗力，而且常常難以保證準確性。例如，分析手牌分佈時，即使能從Hand2Note獲取一些數據，我還是需要手動將手牌範圍輸入到像Cardrunners EV或Solver這樣的工具中，而這些工具之間又是相互獨立的，整合起來相當費力，最終結果也往往不夠精確。
而透過這個自建且靈活的數據庫，我可以將所有資訊整合在一起，無論是用來尋找對抗特定玩家類型的最佳策略，還是訓練撲克模型，都能更加精確高效。
回顧今天的工作，我意識到有時候選擇較為困難的道路可能會帶來更多收穫。雖然自建系統需要更多的前期投入，但長遠來看，這種靈活性和控制力或許正是突破瓶頸的關鍵。
