音韵推论 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 流程解析