在航班延误数据集的一个版本上，使用scikit-learn中的LogisticRegression类。

我使用pandas选择了一些列：

df = df[["MONTH", "DAY_OF_MONTH", "DAY_OF_WEEK", "ORIGIN", "DEST", "CRS_DEP_TIME", "ARR_DEL15"]]

我用0填充NaN值：

df = df.fillna({'ARR_DEL15': 0})

确保分类列标记为’category’数据类型：

df["ORIGIN"] = df["ORIGIN"].astype('category')df["DEST"] = df["DEST"].astype('category')

然后调用pandas中的get_dummies()：

df = pd.get_dummies(df)

现在我训练和测试我的数据集：

from sklearn.linear_model import LogisticRegressionlr = LogisticRegression()test_set, train_set = train_test_split(df, test_size=0.2, random_state=42)train_set_x = train_set.drop('ARR_DEL15', axis=1)train_set_y = train_set["ARR_DEL15"]test_set_x = test_set.drop('ARR_DEL15', axis=1)test_set_y = test_set["ARR_DEL15"]lr.fit(train_set_x, train_set_y)

一旦我调用score方法，我得到大约0.867。然而，当我调用roc_auc_score方法时，我得到一个更低的数值，大约0.583

 probabilities = lr.predict_proba(test_set_x) roc_auc_score(test_set_y, probabilities[:, 1])

为什么ROC AUC比score方法提供的要低很多，有什么原因吗？

回答：

首先，说AUC 0.583比分数0.867“低”，就像把苹果和橘子进行比较一样。

[* 我假设你的分数是平均准确度，但这对本讨论来说并不关键——原则上它可能是任何其他东西]

根据我的经验，至少大多数机器学习从业者认为AUC分数测量的是与其实际测量内容不同的某物：常见（且不幸）的用法就像任何其他越高越好的指标，如准确度，这自然可能导致像你表达的那样的困惑。

事实是，大体上来说，AUC测量的是二元分类器在所有可能的决策阈值上的平均性能。

二元分类中的（决策）阈值是我们决定将样本标记为1的值（回想一下，概率分类器实际上返回一个在[0, 1]之间的值p，通常被解释为概率——在scikit-learn中，这是predict_proba返回的内容）。

现在，在像scikit-learn的predict这样返回标签（1/0）的方法中，这个阈值默认设置为0.5，但这不是唯一的可能性，在某些情况下甚至可能不是理想的（例如，不平衡数据）。

需要记住的要点是：

• 当你请求score（它在幕后使用predict，即标签而不是概率）时，你也隐式地将这个阈值设为0.5
• 当你请求AUC（相反，它使用predict_proba返回的概率）时，不涉及阈值，你得到的是（类似于）在所有可能的阈值上的平均准确度

鉴于这些澄清，你的特定例子提供了一个非常有趣的案例：

我的模型得到足够好的准确度~87%；我应该在意根据AUC 0.58，我的分类器仅比随机猜测略好吗？

假设你的数据中的类别表示是合理平衡的，到现在为止答案应该很明显了：不，你不应该在意；对于所有实际情况，你关心的是使用特定阈值部署的分类器，而这个分类器在纯粹的理论和抽象情况下在所有可能的阈值上的平均表现应该对从业者来说几乎没有兴趣（这对提出新算法的研究者来说确实有兴趣，但我假设这不是你的情况）。

（对于不平衡数据，论点会有所不同；在这里准确度实际上毫无用处，你应该考虑精确度、召回率和混淆矩阵。）

因此，AUC在文献中开始受到严重的批评（不要误读这一点——ROC曲线本身的分析非常有信息量和有用）；强烈推荐阅读维基百科条目及其提供的参考文献：

因此，AUC度量的实际价值已经被质疑，提出AUC实际上可能给机器学习分类准确度比较带来更多不确定性而不是解决方案的可能性。

[…]

最近对ROC AUC问题的解释是，将ROC曲线简化为一个数字忽略了它是关于绘制的不同系统或性能点之间的权衡而不是单个系统的性能这一事实

强调我的观点——另见关于AUC的危险…