機器學習告訴你：《紅樓夢》後40回到底是不是曹雪芹寫的？|數位時代 BusinessNext

前幾天燈神給我發了一篇文章，講的是用機器學習的方式來判定紅樓夢後40回到底是不是曹雪芹寫的。

圖說明

黛玉重建桃花社。畫家孫溫。圖片來自：Wikipedia

我這段時間也在自學Andrew Ng的機器學習課程，還差4週就能完成課程了。

電腦是一個很強調learning by doing的學科，於是我也來「學以致用」，用剛學到的SVM演算法來分析下雪芹老師到底有沒有寫後面的40回。

作為一個從沒看過紅樓夢的人，我的大致思路是這樣的：

受到《獵人》裡蟻王破解會長無敵招數的啟發，每個人的寫作都有些小習慣，雖然文章前後說的內容會有差別，但是這些用詞的小習慣不容易改變；
用開源的分詞工具把全書分詞（python的jieba分詞），然後統計詞頻。把出現頻率超過100次的詞語找出來，人工去掉一些可能因為文章內容造成前後出現不一致的人名、地名；
然後每一章按照2中的詞頻表，看這一章中出現這些詞語的頻率；
前80回、後40回各選15回作為機器學習的資料，讓機器學習這些章節的用詞特點，然後推算其他章節的用詞特點是屬於前80回呢、還是後40回；
如果機器根據這些用詞特徵推算的是否屬於後40回的結果跟實際的結果吻合，那麼就說明後40回的寫作風格跟前80回有很大不同，很可能是兩個人寫的；

好了，下面我儘量少涉及數學跟程式設計的知識，來一步步解讀機器學習是怎麼完成這個問題的。

生成全書的詞頻表

圖說明

我截取了其中一段的詞頻表。像寶二爺、黛玉笑這種涉及人物的詞語，可能前面戲份多、後面戲份少，所以就不選它們作為用詞習慣的特徵，而像忽然、故、只要、可不是這種承接性質的碎詞，就不太容易會受情節的影響，所以適合選出來作為用詞習慣的特徵。

最終，我按照出現從多到少排序，選擇了278個詞作為機器學習的用詞習慣。

將120回的詞頻進行統計

接下來我把每一回出現這278個詞的頻率統計出來，得到我們給機器學習的樣本。這個樣本的樣子大概是這樣的：

圖說明

比如以B行2列舉例，說明在第一回裡面「道」這個動詞，出現了36次。

通常我們在進行複雜的事情前，喜歡先簡化問題，或者給自己一些直觀的圖表，以便瞭解問題。機器學習也是一樣的。

我嘗試著在圖上把前80回和後40回習慣用詞出現的頻率畫出來。以第一回為例，x1座標代表「道」出現多少次，x2座標代表「說」出現多少次，x3座標代表「也」出現多少次......x280座標代表「則」出現多少次。

什麼？超過三維了，那人類的大腦可是沒辦法理解的啊。

沒關係，當我們用燈光照射一個立體的圖時，平面會有它的影子。這個影子雖然沒有立體圖的資訊這麼豐富，不過我們看影子還是可以猜出來大致的樣子。對於高緯度的問題，我們也可以用投影的方式來降低緯度。

雖然資訊損失了不少，不過能給我們一個直觀的感受。

圖說明

這個是120個章節的用詞習慣從278緯降到3維以後的圖，紅色+的點是前80回，藍色o的點是後40回。

從這個圖可以很直接地看到，確實在用詞習慣上有明顯的區別。就算我們沒有機器學習工具的幫忙，也可以大膽猜測後40回是出自於另外一個人了。

下面我們用機器學習來看精確一點的判斷。

機器學習

透過課程我大致瞭解了SVM的原理和簡化版問題的演算法實現，不過對於複雜問題我還是沒這個能力寫程式。於是用python的scikit庫來幫助我來完成這個預測。

演算法的步驟很簡單，前80回、後40回各選15個來餵給機器學習它們的特點，然後把剩下的章節輸入給機器，問它們屬於前80回還是後40回。

圖說明

看out[44]的結果，代表了機器預測這120回的用詞習慣到底屬不屬於後40回（0為不屬於，1為屬於）。

如果你看不懂上面的程式碼，沒關係。我告訴你結果好了。

機器在學習以後告訴我，如果我把隨便一章的用詞習慣告訴它、但不告訴它到底是前80回還是後40回，那麼機器有95%的把握能猜出它是不是後40回。

至此，我們可以很有信心地判斷它們的寫作風格不同。

那麼，問題來了，會不會因為是情節的需要所以導致寫作風格不同了呢？

情節不同會造成用詞習慣多大的差別？

好吧，那我再來做一個旁證。我把另外一部四大名著「三國演義」拿來分析，看看上部跟下部的用詞習慣會不會有比較明顯的差別。

圖說明

這個是三國演義的用詞習慣縮到三維以後的圖，紅色+代表前60部的用詞習慣，藍色o代表後60部的用詞習慣。

你可能會說，雖然中間交叉的地方比較多，但是還是可以看出來是有區分的。

可如果你比對一下跟紅樓夢的圖，你就會發現紅樓夢的差別會明顯得多。

圖說明

紅色+為紅樓夢前80回／三國前60回，藍色o紅樓夢後40回／三國後60回

最後，用機器學習的方式來說，如果我把三國演義隨便一章的用詞習慣告訴它、但不告訴它到底是前60回還是後60回，那麼機器有7成的把握猜對，這個準確度已經遠遠低於紅樓夢的95%的預測水準。

所以，我們用「三國演義」這個旁證來分析，即便是因為情節需要導致的用詞習慣差別也不應該這麼大。

所以，我們就更有信心說曹老先生沒有寫後40回了。

更多的機器學習有趣的玩法，我會在學習的過程中慢慢嘗試的。以上。

本文作者黎晨，原文刊載於他的微信公眾號：黎小晨想太多

2026台灣設計展於9月24日至10月11日在桃園登場，以「桃園流」為主題，結合千塘之鄉的水文地景、國門之都的航空與物流優勢、多元族群文化匯流，以及 AI 科技應用，展現城市運轉的動態美學。

其中，為提供民眾不同於以往的互動體驗，AIoT 智慧感知大數據平台服務商棋苓（Chylyng）推出全展區 AI 穿戴互動體驗「FLOW CHECK」。參觀者配戴主辦單位提供的智慧手環後，可沿著展場動線於不同站點進行互動。即使多人同時參與，每位參觀者仍可依照不同的路徑、選擇與互動節奏完成體驗；系統並依據互動過程與結果，即時生成專屬的 Flowmomo 數位卡牌，讓參觀者儲存並帶走屬於自己的展覽體驗紀錄。

看似簡單的手環互動，背後其實是一套整合穿戴裝置、即時感測、場域互動、資料處理與雲端服務的完整系統。尤其在大型公開展覽環境中，不僅必須因應大量參觀者於短時間內同時使用，也必須確保從手環感測、站點互動、資料傳輸到最終結果產出的每一個環節，都能維持即時且穩定的服務品質。

棋苓以自主開發的 Eleplo AIoT Platform 為技術核心，整合穿戴裝置、感測設備、人員與資產定位，以及即時事件與資料管理，並負責建構 FLOW CHECK 的手環互動邏輯、站點應用、卡牌生成及參觀者操作介面。

專業分工合作：諾德資訊坐鎮後端，撐住大型公開展覽的服務韌性

為了讓系統從開發與測試環境順利進入大型公開場域，並進一步提升正式服務的可用性、資安與系統韌性，諾德資訊與棋苓採取專業分工合作。棋苓聚焦於 AIoT 平台、穿戴應用及使用者體驗；諾德資訊則負責後端基礎架構、正式環境部署、壓力測試、高可用性驗證，以及服務上線後的系統與流量監控。

由於展場現地部署時間僅有兩天，雙方將大量驗證工作提前至開展前完成。諾德資訊於正式開展前約一個月即建置專用測試環境，讓棋苓的應用服務提早與正式營運架構整合，並進行壓力測試、高可用性驗證及異常情境測試，使原本必須於現場進行的系統驗證工作大幅提前完成。

諾德資訊業務開發經理邱柏瑞表示：「FLOW CHECK 的挑戰在於大量參觀者可能集中於同一時段使用手環，因此除了確保服務穩定之外，也必須辨識進入系統的流量究竟來自真人使用者、合法自動化程式、AI Bot 或惡意攻擊，並透過即時監控及早發現異常。」為此，諾德資訊導入 IntelliFend Bot Management，協助辨識真人使用者、合法自動化及異常機器人流量，並於展覽公開服務期間透過遠端監控，持續掌握主機、資料庫、應用服務及外部流量狀態。

此外，為驗證系統在大型展覽情境下的承載能力，正式展出前，諾德資訊亦協助棋苓進行大規模壓力測試，模擬最高約 3 萬人同時使用的流量情境，提前觀察系統資源使用狀況、服務反應與可能的效能臨界點，並據此進行相關調校。

透過棋苓在 AIoT、智慧穿戴與互動應用上的技術能力，以及諾德資訊在正式營運環境、資安、壓力測試與維運監控上的經驗，雙方在展覽正式開放前，即完成從應用層到基礎架構的完整驗證，讓 FLOW CHECK 能夠在大型公開場域中穩定提供即時的 AI 穿戴互動體驗。

AI加速開發腳步，但也增加「上線」考驗

從生成式AI到代理式AI，軟體開發速度快速提升，過去需要長時間才能完成的產品原型（Prototype）與概念性驗證（PoC）專案，現在可以很快完成驗證，讓軟體商有更多時間跟資源投入客戶需求、產品創意與使用體驗。

但是，從PoC走到Production，面對的是完全不同的考驗。
諾德資訊技術長張家榮解釋，進入正式環境（Production）後，軟體服務必須面對真實使用者的流量、不同客戶的IT環境、計算資源擴充、資料庫負載、網路連線、資安攻擊，以及服務異常時的切換與處理，就算在壓力測試時表現正常的系統，也可能在Production的時候出現問題。

更值得特別注意的是，AI不只讓開發者更快，也讓攻擊者發現漏洞的速度加快；過去，服務上線後還有時間慢慢觀察、修正，現在，服務一上線，可能很快就遭到掃描甚至攻擊。

也因如此，軟體商、系統整合商選擇基礎架構夥伴的條件開始改變，從過去關注功能與價格轉向：產品能不能順利上線？出了問題誰來處理？面對流量變化與資安風險，服務能不能持續運作？

張家榮表示：「諾德資訊可以提供從公有雲、私有雲、地端、邊緣運算、主機代管、網路，到維運與監控等服務，讓軟體夥伴可以將資源集中在應用與客戶需求，無須擔憂Production議題。」

不僅提供資源，諾德資訊將Production變成一項服務

而這也是諾德資訊會提出「Production as a Service」的原因：不是在提供另一種雲端或主機服務，而是將軟體從開發走向正式營運所需的Production流程，轉化成可以被專業分工、驗證與持續維運的一項服務。

「Production as a Service不是單純把主機或雲端資源租給客戶，而是共同檢視這套軟體能不能順利上線與正常營運。」邱柏瑞表示。

實際做法包括，在上線前協助檢視架構，建立與正式環境相近的測試環境，確認系統正常狀態、最大承載量與資源需求，並驗證高可用性、資安、備援及服務切換機制；上線後則持續監看服務狀態、容量與流量，及早發現異常並處理。

諾德資訊之所以有這樣的服務能力，可以歸結為三點：

第一，長期累積的基礎架構與維運經驗，目前，諾德資訊同時服務的客戶數近30家，應用情境涵蓋IoT、購物平台、遊戲、音樂等不同類型的軟體服務。

第二，諾德資訊將每一個客戶遇到的問題與解決方案收攏至知識庫，讓團隊成員可以快速處理、借鏡，滿足客戶需求。

第三，依循ITIL的維運精神，並具備ISO 27001等資安相關認證，將服務流程、操作紀錄、備份、監控與異常處理等機制內化到服務之中。

這也是諾德資訊與單純提供雲端、IDC或主機代管服務的業者之間的最大差異：交付的不僅是基礎設施，而是讓服務持續運作的能力。面對客戶同時使用公有雲、私有雲、地端與邊緣運算環境，諾德資訊另以 MQloud 提供統一管理，把網路、防火牆、流量、監控與帳務收進同一套平台，降低跨環境營運的複雜度。

「軟體商負責開發，就像晶片設計公司；諾德資訊則負責協助完成測試、製程調整與正式生產，讓產品真正走向市場，希望成為『軟體界的台積電』。」張家榮如是說道。

展望未來，諾德資訊將持續深化 Production as a Service，成為軟體公司從上線到長期營運的夥伴。自構想階段起即與軟體商共同討論架構，於測試階段協助驗證，於準備上市時承接正式環境，上線後則持續守住流量、資安與服務韌性。軟體開發者與 SaaS 業者可將資源集中於產品與客戶，完整基礎架構與 24×7 維運則由諾德資訊端到端承接。