Weka中决策树和混淆矩阵中正确/错误分类实例之间的差异

Posted 2023-03-13

【中文标题】Weka中决策树和混淆矩阵中正确/错误分类实例之间的差异

【英文标题】：Difference between correctly / incorrectly classified instances in decision tree and confusion matrix in Weka

【发布时间】：2012-08-05 21:18:25

【问题描述】：

我一直在使用 Weka 的 J48 决策树对关键词的频率进行分类 在 RSS 提要到目标类别。我想我可能有问题 将生成的决策树与正确分类的数量相协调 报告的实例和混淆矩阵中的实例。

例如，我的一个 .arff 文件包含以下数据提取：

@attribute Keyword_1_nasa_Frequency numeric
@attribute Keyword_2_fish_Frequency numeric
@attribute Keyword_3_kill_Frequency numeric
@attribute Keyword_4_show_Frequency numeric
...
@attribute Keyword_64_fear_Frequency numeric
@attribute RSSFeedCategoryDescription BFE,FCL,F,M, NCA, SNT,S

@data
0,0,0,34,0,0,0,0,0,40,0,0,0,0,0,0,0,0,0,0,24,0,0,0,0,13,0,0,0,0,0,0,0,0,0,0,0,0,
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,BFE
0,0,0,10,0,0,0,0,0,11,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,BFE
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,BFE
...
20,0,64,19,0,162,0,0,36,72,179,24,24,47,24,40,0,48,0,0,0,97,24,0,48,205,143,62,78,
0,0,216,0,36,24,24,0,0,24,0,0,0,0,140,24,0,0,0,0,72,176,0,0,144,48,0,38,0,284,
221,72,0,72,0,SNT
...
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,6,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,8,0,0,0,0,0,
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,S

依此类推：总共有 64 个关键字（列）和 570 行，每个行都包含一天中某个关键字在提要中出现的频率。在这种情况下，有 57 个供稿 10 天，总共有 570 条要分类的记录。每个关键字都有前缀 带有代理编号并以“频率”为后缀。

我对决策树的使用是使用 10 倍验证的默认参数。

Weka 报告如下：

Correctly Classified Instances         210               36.8421 %
Incorrectly Classified Instances       360               63.1579 %

具有以下混淆矩阵：

=== Confusion Matrix ===

   a   b   c   d   e   f   g   <-- classified as
  11   0   0   0  39   0   0 |   a = BFE
   0   0   0   0  60   0   0 |   b = FCL
   1   0   5   0  72   0   2 |   c = F
   0   0   1   0  69   0   0 |   d = M
   3   0   0   0 153   0   4 |   e = NCA
   0   0   0   0  90  10   0 |   f = SNT
   0   0   0   0  19   0  31 |   g = S

树如下：

Keyword_22_health_Frequency <= 0
|   Keyword_7_open_Frequency <= 0
|   |   Keyword_52_libya_Frequency <= 0
|   |   |   Keyword_21_job_Frequency <= 0
|   |   |   |   Keyword_48_pic_Frequency <= 0
|   |   |   |   |   Keyword_63_world_Frequency <= 0
|   |   |   |   |   |   Keyword_26_day_Frequency <= 0: NCA (461.0/343.0)
|   |   |   |   |   |   Keyword_26_day_Frequency > 0: BFE (8.0/3.0)
|   |   |   |   |   Keyword_63_world_Frequency > 0
|   |   |   |   |   |   Keyword_31_gaddafi_Frequency <= 0: S (4.0/1.0)
|   |   |   |   |   |   Keyword_31_gaddafi_Frequency > 0: NCA (3.0)
|   |   |   |   Keyword_48_pic_Frequency > 0: F (7.0)
|   |   |   Keyword_21_job_Frequency > 0: BFE (10.0/1.0)
|   |   Keyword_52_libya_Frequency > 0: NCA (31.0)
|   Keyword_7_open_Frequency > 0
|   |   Keyword_31_gaddafi_Frequency <= 0: S (32.0/1.0)
|   |   Keyword_31_gaddafi_Frequency > 0: NCA (4.0)
Keyword_22_health_Frequency > 0: SNT (10.0)

我的问题涉及将矩阵与树调和，反之亦然。据，直到...为止 我了解结果，像 (461.0/343.0) 这样的评级表明 461 个实例已被归类为 NCA。但是当矩阵只显示 153 时，这怎么可能呢？我是 不知道如何解释，所以欢迎任何帮助。

提前致谢。

【参考方案1】：

每个叶子的括号中的数字应读作（此叶子上此分类的总实例数/此叶子上错误分类的数量）。

在您的第一个 NCA 叶示例中，它表示有 461 个测试实例被归类为 NCA，而在这 461 个测试实例中，有 343 个错误分类。所以在那个叶子上有 461-343 = 118 个正确分类的实例。

查看您的决策树，注意 NCA 也在其他叶子上。在 NCA 的 461 + 3 + 31 + 4 = 499 个总分类中，我计算出 118 + 3 + 31 + 4 = 156 个正确分类的实例。

您的混淆矩阵显示了 39 + 60 + 72 + 69 + 153 + 90 + 19 = 502 个 NCA 分类中的 153 个正确分类。

因此，树 (156/499) 和您的混淆矩阵 (153/502) 之间存在细微差别。

请注意，如果您从命令行运行 Weka，它会输出一棵树和一个混淆矩阵，用于测试所有训练数据以及使用交叉验证进行测试。请注意，您正在查看正确树的正确矩阵。 Weka 输出训练和测试结果，产生两对矩阵和树。你可能把它们弄混了。

【讨论】：

非常感谢您的清晰解释。我担心我的数据存在潜在问题，我有 72 个 .arff 文件需要分类。我知道树和矩阵之间的细微差别是错误分类的实例，我想总会有一些这样的实例。但是你的最后两句话让我感到困惑：我使用的是 10 倍验证，所以每个分类我应该只有一棵树和一个矩阵，不是吗？

是的，如果您使用的是 GUI，那么输出将是一棵树和一个矩阵，两者都用于交叉验证测试。我几乎总是从命令行使用 Weka，在这种模式下，它会输出一棵树和一个矩阵，用于测试训练数据和交叉验证测试。我会改变我的答案来反映这一点。

再次感谢：就我而言，我直接从 Java 生成树并通过 GraphViz 重新格式化它们以改善它们的外观。这种方法的唯一问题是我不确定如何输出混淆矩阵和其他细节。所以现在这部分是通过 GUI 手动完成的。

Weka GUI 已经具有生成树可视化的功能。在分类选项卡下，在右下角选择一个模型，然后右键单击以找到该选项。另外，感谢指向 GraphViz 的指针；我没听说过。您是否正在实施一些转换工具来将 Weka 输出移动到 GraphViz 中？

无转换实用程序。我让 Weka 将决策树编写为 .dot 文件，由 GraphViz 重新格式化。