機器學習告訴你:《紅樓夢》後40回到底是不是曹雪芹寫的?
機器學習告訴你:《紅樓夢》後40回到底是不是曹雪芹寫的?

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

圖說明

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

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

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

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

  1. 受到《獵人》裡蟻王破解會長無敵招數的啟發,每個人的寫作都有些小習慣,雖然文章前後說的內容會有差別,但是這些用詞的小習慣不容易改變;

  2. 用開源的分詞工具把全書分詞(python的jieba分詞),然後統計詞頻。把出現頻率超過100次的詞語找出來,人工去掉一些可能因為文章內容造成前後出現不一致的人名、地名;

  3. 然後每一章按照2中的詞頻表,看這一章中出現這些詞語的頻率;

  4. 前80回、後40回各選15回作為機器學習的資料,讓機器學習這些章節的用詞特點,然後推算其他章節的用詞特點是屬於前80回呢、還是後40回;

  5. 如果機器根據這些用詞特徵推算的是否屬於後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回了。

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

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

關鍵字: #機器學習
往下滑看下一篇文章
從台灣走進北美千家速食門市!Berry AI 如何攜手博弘雲端,讓 AI 規模化落地?
從台灣走進北美千家速食門市!Berry AI 如何攜手博弘雲端,讓 AI 規模化落地?

一家來自台灣的 AI 新創,如何讓美國上千家速食餐廳,都用它的 AI「看」得來速車道?

這家公司就是專注於 AI 影像辨識技術的 Berry AI (華捷智能),透過攝影機蒐集匿名數據並轉化為多項營運指標,協助速食品牌找出流程瓶頸、提升現場營運效率與整體顧客滿意度。以美國連鎖炸雞品牌 Zaxby’s 為例,在全面導入 Berry AI 解決方案後,服務速度提升 13%-20%,業績表現最好與最差的門市,每週營收差距從 2.4 萬美元縮小至約 9,000 美元。另一家連鎖速食品牌 Culver’s 在導入後,得來速車道的服務時間也立刻改善,進而提升整體吞吐量。

然而,支撐 Berry AI 解決方案的,不只有前端看得見的攝影機與影像辨識技術,還有後端穩定且具彈性的雲端平台。Berry AI 結合 Amazon Web Services (AWS) 全球雲端資源及博弘雲端顧問服務,打造兼顧即時性、穩定性與成本效益的雲地混合架構,成為推動 Berry AI 持續擴大北美市場版圖的重要關鍵。

從台灣 PoC 走向北美千店規模,Berry AI 面臨架構升級新挑戰

Berry AI 執行長林逸中表示,團隊成立初期投入近2年半的時間,探索最適合影像辨識技術的應用場景,最終將目光鎖定高度標準化的速食餐飲業(Quick Service Restaurant;QSR),推出得來速計時器、餐廳計數器等解決方案,運用 AI 影像分析技術,辨識顧客進入得來速車道或餐廳後的狀態,例如:排隊、點餐、候餐等。

同時,Berry AI 也進一步將現場蒐集到的數據轉化為可量化的營運指標,例如:不同門市、日期或時段的顧客等候時間,協助管理者從數據中找出流程瓶頸與可以優化的環節,進而提升服務效率及顧客滿意度。

在確立發展方向並於台灣完成 PoC (概念驗證)後,Berry AI 決定前進全球最大、也是 QSR 最核心的北美市場。然而,隨著合作客戶與部署門市持續增加,資料量快速攀升,加上服務範圍橫跨不同區域,既有以地端為主的架構開始面臨規模化挑戰。

林逸中補充指出,尤其 QSR 業者在選擇 AI 解決方案時,格外重視技術效能與穩定性,包括 AI 辨識精準度、能否因應突發狀況、系統能否穩定運作,以及網路發生問題時能否維持服務等。在這樣的要求下,若將所有運算與資料都留在地端,不僅難以因應日益增加的部署門市與資料量體,設備建置與維運成本也會隨之增加。

BerryAI 攜手博弘雲端 打造高可用性 AWS 雲地混合架構,突破北美規模化部署挑戰

如何確保系統的即時性、穩定性與成本效益,成為 Berry AI 進軍北美後必須解決的新課題。為此,Berry AI 選擇與博弘雲端合作,取得穩定且高可用的 AWS 運算與資料庫服務架構,將即時運算留在地端,同時在雲端環境整合資料庫處理大量資料與後續分析工作,形成兼顧地端即時運算與雲端彈性擴充的雲地混合架構。

Berry AI研發同仁汪楚剛說明,包括車輛偵測、追蹤與狀態辨識等需要即時反應的工作,會先在地端完成;再將辨識結果傳送至 AWS 雲端,計算各項營運指標,提供後續分析與決策使用。透過這套架構,Berry AI 至今已處理超過 2 億筆車輛狀態資料。

此外,AWS 也是 Berry AI 持續優化 AI 模型的重要基礎。Berry AI 將整套資料蒐集流程建構於 AWS 上,透過完整且多樣化的資料,持續訓練與優化模型,進一步提升地端影像辨識的準確度。

博弘雲端
Berry AI 鎖定高度標準化的速食餐飲業(Quick Service Restaurant;QSR),推出得來速計時器、餐廳計數器等解決方案,運用 AI 影像分析技術,辨識顧客進入得來速車道或餐廳後的狀態,例如:排隊、點餐、候餐等,協助管理者從數據中找出流程瓶頸與可以優化的環節,進而提升服務效率及顧客滿意度。
圖/ Berry AI網站圖

成為企業技術團隊的延伸,博弘雲端助 BerryAI 把 AWS 用得更好、更省

隨著北美業務持續成長,Berry AI 也迎來新的課題:如何把雲端資源用得更有效率、更省成本,這也成為 Berry AI 與博弘雲端合作的重要契機。

對此,可能有很多人好奇,像 Berry AI 這類技術能力成熟、具備自行建置架構能力的企業,為什麼還需要與博弘雲端合作?「關鍵在於,博弘雲端長期深耕 AWS,對相關服務與技術架構更加熟悉,可以成為企業內部技術團隊的延伸。」博弘雲端技術長宋青雲說。

當 Berry AI 遇到特定 AWS 服務或技術問題時,可以直接尋求博弘雲端協助;若需要進一步與 AWS 原廠確認,博弘雲端也能協助溝通與處理,減少 Berry AI 自行研究與排除問題所需投入的時間,讓內部研發團隊可以將更多心力和資源集中在核心產品開發。

更重要的是,博弘雲端不只提供技術支援,還能從 Berry AI 實際用量與成長需求出發,客製化設計最適合的節費方案,這對 Berry AI 降低營運成本有很大的幫助。宋青雲說明,博弘雲端根據 Berry AI 既有的 AWS 用量,推估未來 1-3 年內的使用需求,並以此為基礎規劃合適的長期雲端資源用量;同時考量 Berry AI 所屬飛捷集團旗下還有 3 家子公司同樣使用 AWS,進一步整合集團需求進行評估,放大整體採購規模,爭取更大的節費空間。

宋青雲強調,雲端採取隨需即付的計價模式,雖然具備彈性優勢,但若缺乏持續管理,仍可能出現資源配置不符商務規劃,或費用超出預期等情況。而博弘雲端不只能從使用現況出發、建議適合的節費方案,也會從效能、資安與成本等面向進行架構健檢,提出相應的優化建議;同時還會提供相關管理介面,讓企業隨時查看帳戶使用狀況、預估未來用量,在業務規模持續成長的同時,也能兼顧雲端架構的效能、安全與成本效益。

而架構健檢與成本優化,只是博弘雲端服務的一環。從企業準備上雲開始,博弘雲端便能協助將應用程式與資料從地端搬遷至雲端,或直接在雲端完成部署;進一步還能協助建置數據平台、數據中台,進行資料分析及導入 AI 應用,讓企業資料發揮更大價值。當服務正式上線後,博弘雲端也能接續提供維運服務。換言之,從前期 PoC、雲端建置到後續維運,博弘雲端都能依據企業需求,提供相應的服務與支援。

對 Berry AI 來說,藉由與博弘雲端合作,深化 AWS 雲端資源使用,不只是突破規模化挑戰,更重要的是能把有限的資源集中在核心業務,持續優化解決方案、開發更多貼近餐飲營運需求的應用,進一步爭取更多品牌合作,擴大北美市場版圖。目前,Berry AI 正全力拓展北美市場,也持續尋找對 AI 技術與餐飲產業應用充滿好奇心、重視團隊協作的人才加入。徵才方向涵蓋機器學習與電腦視覺、Platform & System(DevOps、Infrastructure),以及 Full Stack 軟體開發。從門市邊緣裝置上運行的 AI 模型、串連雲端與數千家門市的系統平台,到協助餐飲品牌提升營運效率的分析產品,每個環節都還有發揮的空間。 期待匯聚更多優秀夥伴,一起用 AI 解決真實的營運問題,讓來自台灣的技術走進更多全球 QSR 門市。

職缺詳情:https://www.cake.me/companies/berryai/jobs

登入數位時代會員

開啟專屬自己的主題內容,

每日推播重點文章

閱讀會員專屬文章

請先登入數位時代會員

看更多獨享內容

請先登入數位時代會員

開啟收藏文章功能,

請先登入數位時代會員

開啟訂閱文章分類功能,

請先登入數位時代會員

我還不是會員, 註冊去!
追蹤我們
一次搞懂工業AI
© 2026 Business Next Media Corp. All Rights Reserved. 本網站內容未經允許,不得轉載。
106 台北市大安區光復南路102號9樓