音韻推論 Engine 要如何測試？Quizzman Fanqie Engine QA 流程解析

Quizzman Fanqie Engine 系列（第十三篇）

上一篇：從 Middle Chinese 到拼音與漢越音：支援多種讀音系統

音韻推論 Engine 要如何測試？Quizzman Fanqie Engine QA 流程解析

一般軟體通常只要比較輸出結果是否符合預期即可完成測試。然而，對於歷史音韻推論 Engine 而言，問題要複雜得多。一個漢字可能同時存在多個反切、多種讀音層、不同文獻來源，以及各種歷史變體。如果僅以「正確」或「錯誤」來判斷，往往無法反映真正的情況。因此，Quizzman Fanqie Engine 建立了一套多層次 QA 系統，讓演算法的每一步推論都能被驗證、分類與追蹤。

為什麼 Fanqie Engine 的測試這麼困難？

先看一個最簡單的例子：

國
 ↓
quốc

如果只是一本電子字典，

測試非常簡單：

Expected
 ↓
quốc

Actual
 ↓
quốc

兩者一致，

測試即可通過。

然而，

對 Quizzman Fanqie Engine 而言，

事情遠不只是如此。

Engine 不只是產生：

quốc

它還必須決定：

使用哪一條反切。
Middle Chinese 如何重建。
採用哪個聲母。
採用哪個韻。
聲調如何演變。
為什麼最終得到 quốc。

只要其中任一步驟出錯，

整條推論鏈都可能受到影響。

結果正確，不代表演算法正確

假設 Engine 最後輸出：

quốc

這並不足以證明演算法正確。

例如，

Engine 可能：

重建錯誤的 Middle Chinese。
選錯反切。
套用了錯誤規律。
卻碰巧仍然得到 quốc。

這種情況稱為：

偶然正確（Accidentally Correct）。

若未能及時發現，

這類錯誤可能影響數百甚至數千個漢字。

因此，

Quizzman Fanqie Engine 不只驗證最終輸出，

而是檢查整個推論流程。

分層測試 Pipeline

Quizzman Fanqie Engine 的 Pipeline 分為多個階段：

反切
   ↓
Middle Chinese
   ↓
Projection
   ↓
Lexical
   ↓
Hybrid

每一層，

都有各自的測試。

例如：

Parser Test
Middle Chinese Test
Tone Test
Rime Test
Projection Test
Candidate Ranking Test
API Test

因此，

一旦出現問題，

開發者可以迅速定位錯誤發生的位置。

Golden Fixture

QA 系統中最重要的組成之一，

就是 Golden Fixture。

這是一套經人工驗證的標準資料集。

它與一般 Benchmark 不同，

目的不是涵蓋最多漢字，

而是挑選最具代表性的案例，

驗證各項核心規律。

例如：

平聲。
上聲。
去聲。
入聲。
清聲母。
濁聲母。
入聲 -p、-t、-c、-ch。
各種歷史例外。

即使只是某一條小規律被破壞，

Golden Fixture 也能立即發現。

Regression Test

所有 Rule Engine 都面臨同一個風險：

修正一個問題，卻破壞更多地方。

例如，

改善：

江攝

可能意外影響：

宕攝

又或者：

次濁平
 ↓
陰平

若規則寫錯，

可能影響數百個漢字。

因此，

每次修改規則後，

系統都會重新執行完整測試。

若出現 Regression（回歸錯誤），

修改內容便需要重新檢查，

確認無誤後才能正式發布。

聲調測試

聲調系統，

是最容易產生錯誤的模組之一。

測試內容，

不只是確認：

陰平。
去聲。

更會檢查：

Eight Tone Slot。
陰／陽。
平、上、去、入。
聲母條件。

例如：

次濁
+
平聲

必須確認是否正確演變為：

陰平

如此才能避免演算法更新時，

破壞已經確認的歷史音變規律。

韻母測試

韻母系統同樣具有獨立測試。

例如：

通攝。
江攝。
梗攝。
流攝。
深攝。

針對入聲，

還會驗證：

-p
-t
-c
-ch

測試內容，

不只是確認最終韻尾是否正確，

更要確認：

形成該韻尾的歷史條件是否正確。

例如：

-k
 ↓
-c

與：

-k
 ↓
-ch

雖然都源自中古漢語 -k，

形成條件卻完全不同。

Candidate Audit

許多漢字同時具有：

多個反切。
多個文獻來源。
多種重建方案。

因此，

僅驗證最終輸出並不足夠。

Quizzman Fanqie Engine 還會檢查：

Candidate Ranking 排序是否合理。
每個 Candidate 的分數。
為何某個 Candidate 被選為最佳結果。

如此，

即使資料持續增加，

Candidate Ranking 仍能保持穩定。

Batch Audit

除了單元測試外，

Engine 還會定期執行大型資料集測試。

例如：

Random Corpus
Benchmark
標準 Corpus
數千漢字 Audit

目的不只是統計準確率，

更重要的是找出：

被破壞的新規律。
錯誤集中出現的區域。
每次更新後的異常變化。

這也是團隊長期追蹤 Engine 品質的重要方式。

分類錯誤，而非只統計錯誤

Quizzman Fanqie Engine 的另一項特色是：

並非所有差異都被視為錯誤。

Audit 完成後，

系統會進一步分類，例如：

True Rule Error：音韻規則真正錯誤。
Colloquial Variant：口語讀音差異。
Polyphonic Character：多音字。
Orthographic Difference：正字法差異。
Historical Variant：歷史變體。
Lexical Difference：詞彙層差異。

透過分類，

開發團隊能判斷：

究竟需要修改演算法，

還是只需更新資料。

API 測試

除了核心演算法，

所有 API 也都納入測試。

例如：

反切解析。
漢越音生成。
拼音生成。
反向查詢。
Projection。
Health Check。

目的是確保無論使用：

Web。
CLI。
API。

都能取得一致且穩定的結果。

為什麼 QA 如此重要？

一套歷史音韻推論 Engine，

可能包含數百條音韻規則。

而每一條規則，

都可能影響數千個漢字。

若缺乏完整 QA，

即使只是微小修改，

也可能讓整個系統品質下降，

卻難以及時發現。

因此，

QA 並不是程式完成後才開始的工作，

而是整體架構的一部分。

每新增一條規則，

相應的測試也必須同步建立。

測試，也是研究的一部分

Quizzman Fanqie Engine 的最終目標，

並不只是打造一套穩定的軟體。

更重要的是建立一個可以驗證歷史音韻假說的平台。

當 Pipeline 的每一層都有獨立測試後，

研究者便能：

修改一條規則。
重新執行整個 Corpus。
觀察規則帶來的影響。
以資料驗證假說，而非依賴主觀判斷。

因此，

Quizzman Fanqie Engine 的 QA 系統，

不只是軟體品質保證工具，

也是歷史語言學研究的重要基礎設施。

在介紹完架構、演算法、Benchmark 與 QA 系統後，

本系列最後一篇將展望 Quizzman Fanqie Engine 的未來發展。

除了漢越音推論之外，

平台還可持續擴展至：

漢日音（Kan-on、Go-on）。
漢韓音。
漢語各地方言。
古文獻處理。
OCR。
東亞歷史語言研究中的 AI 應用。

Quizzman Fanqie Engine 的目標，

不只是打造一套漢越音推論 Engine，

更希望成為東亞歷史音韻研究的共用基礎平台。

音韻推論 Engine 要如何測試？Quizzman Fanqie Engine QA 流程解析