Scikit-learn: Prise en charge des scores roc_auc multi-classes

Je ne suis pas certain de ce que cela signifie. Avez-vous une référence pour cela?

Le 19 juin 2014 à 09h51, Madison May [email protected] a écrit :

Demande de fonctionnalité à faible priorité : prise en charge du score roc_auc multi-classes
calcul dans sklearn.metrics en utilisant la méthodologie un contre tous
serait incroyablement utile.

-
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/scikit-learn/scikit-learn/issues/3298.

Voici une explication assez décente, ainsi que des références : https://www.cs.bris.ac.uk/~flach/ICML04tutorial/ROCtutorialPartIII.pdf

hmm, qu'est-ce qu'un marqueur recommandé alors que l'auc multi-classe n'est pas implémenté ?

la prise en charge du calcul du score roc_auc multi-classes dans sklearn.metrics en utilisant la méthodologie un contre tous serait incroyablement utile

Parlez-vous de ce que ces diapositives considèrent comme une approximation du volume sous la surface dans laquelle la moyenne pondérée en fréquence de l'AUC pour chaque classe est prise ? Cela semble être identique à l'utilisation du roc_auc_score actuel avec une représentation binarisée et average='weighted' . ( @arjoly , pourquoi ces scores basés sur des courbes interdisent-ils la multiclasse ?)

Sinon, ces diapositives, et la plupart des références que je peux trouver sur le "ROC multi-classes", se concentrent sur l'étalonnage multi-classes de l'OvR, et non sur une métrique d'évaluation. Est-ce cela qui vous intéresse ? Je ne sais pas à quel point cette technique est répandue, si cela vaut la peine de l'avoir disponible dans scikit-learn, et si l'optimisation gourmande doit être améliorée.

( @arjoly , pourquoi ces scores basés sur des courbes interdisent-ils la multiclasse ?)

Chaque fois qu'une classe est manquante dans y_true, il n'est pas possible de calculer le score. Je ne voulais pas ajouter la magie de l'inférence de classe et causait des problèmes aux utilisateurs.

Il est possible que nous ne traitions pas de manière appropriée dans le cas de y_pred
ayant une étiquette que y_true n'a pas. Cette étiquette ne devrait probablement pas
participer à quelque chose comme une moyenne macro (conformément à Weka,
aussi) ou un score ROC.

Le 1er août 2014 17:08, Arnaud Joly [email protected] a écrit :

( @arjoly https://github.com/arjoly, pourquoi ces scores basés sur des courbes
interdire multiclasse ?)

Chaque fois qu'une classe est manquante dans y_true, il n'est pas possible de calculer
le score. Je ne voulais pas ajouter la magie pour l'inférence de classe et j'ai obtenu
l'utilisateur en problèmes.

-
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/scikit-learn/scikit-learn/issues/3298#issuecomment -50855460
.

@jnothman @arjoly il y a eu beaucoup de progrès sur le front de la moyenne. Est-il difficile de mettre cela en œuvre maintenant ?

cela pourrait peut-être être similaire à la fonction R du package pROC
http://www.inside-r.org/packages/cran/pROC/docs/multiclass.roc

Bonjour, j'ai mis en place un brouillon du score ROC/AUC moyenné par macro, mais je ne sais pas s'il conviendra à sklearn.

Voici le code :

from sklearn.metrics import roc_auc_score
from sklearn.preprocessing import LabelBinarizer

def multiclass_roc_auc_score(truth, pred, average="macro"):

    lb = LabelBinarizer()
    lb.fit(truth)

    truth = lb.transform(truth)
    pred = lb.transform(pred)

    return roc_auc_score(truth, pred, average=average)

Cela pourrait-il être aussi simple que cela?

@fbrundu si c'est la signification standard. C'est certainement une interprétation possible.

Il y a un bon résumé ici :
http://people.inf.elte.hu/kiss/13dwhdm/roc.pdf

Le package pROC implémente Hand and Till :
http://download.springer.com/static/pdf/398/art%253A10.1023%252FA%253A1010920819831.pdf?originUrl=http%3A%2F%2Flink.springer.com%2Farticle%2F10.1023%2FA% 3A1010920819831&token2=exp=1469743016 ~acl=%2Fstatic%2Fpdf%2F398%2Fart%25253A10.1023 %25252FA%25253A1010920819831.pdf%3ForiginUrl%3Dhttp%253A%252F%252Flink.springer.com%2252102Farticle1981981253A%225109Farticle *~hmac=bc68686d3782ac6af3c3cda13c1b36aad6de5d01d16a25870cace5fe9699fb8a

La version de Hand and Till semble être généralement acceptée et je vote que nous l'implémentions.
Il existe également une version de Provost et Domingos pour laquelle je devrais probablement m'appuyer étant donné que Provost est actuellement mon directeur, mais cela n'a pas fait son chemin.
Le Provost-Domingos, c'est ce que @fbrundu a dit seulement avec average='weighted' .

TLDR : PR pour Hand and Till bienvenue. En option Provost et Domingos avec possibilité de modifier la moyenne.

Salut, y a-t-il eu des progrès dans la mise en œuvre de cela?
Ce que j'ai vu dans la plupart des autres bibliothèques (par exemple WEKA), c'est qu'elles utilisent la moyenne pondérée. Je pense que c'est ce que @fbrundu a proposé en utilisant average='micro' ?

@joaquinvanschoren R utilise le Hand and Till. Je préférerais celui-là aussi. J'ai un étudiant qui va travailler dessus bientôt.

@amueller je peux travailler dessus :)

@kchen17 merci !

Nous en avons pas mal discuté à OpenML. Pour l'AUC multiclasse, il n'y a aucune garantie qu'une approche (macro-moyenne, micro-moyenne, moyenne pondérée, ...) soit meilleure que l'autre. Dans R, vous pouvez trouver au moins 5 approches différentes (toutes également disponibles dans MLR maintenant).
Lors de l'implémentation de ceci dans scikit-learn, ce serait formidable s'il y avait au moins la possibilité de choisir celui qui a le plus de sens pour votre application, même si vous utilisez Hand-Till par défaut. Hand-Till est d'ailleurs une approche non pondérée, elle ne prend pas en compte le déséquilibre des labels.

Je suis content d'avoir plusieurs versions. non pondéré et "ne pas tenir compte du déséquilibre des étiquettes" sont deux choses différentes ;) Avez-vous une liste et des références ?

Qu'est-ce que la micro-moyenne dans ce cas ?

Notez que nous avons déjà fait des micro et macro-moyennes ROC AUC pour les problèmes multiclasses implémentés dans cet exemple :

http://scikit-learn.org/stable/auto_examples/model_selection/plot_roc.html#multiclass -settings

En fait, je pense que la documentation est incorrecte et devrait dire
multi-étiquettes...

Le 26 septembre 2016 à 23h16, Olivier Grisel [email protected]
a écrit:

Non pas que nous ayons déjà fait la micro et macro moyenne ROC AUC pour multiclasse
problèmes mis en œuvre dans cet exemple :

http://scikit-learn.org/stable/auto_examples/model_
selection/plot_roc.html#multiclass-settings

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/scikit-learn/scikit-learn/issues/3298#issuecomment -249566346,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AAEz65IeU7k2CFwyHxTTAjk-5orIxWe6ks5qt8WsgaJpZM4CFzud
.

En micro-moyenne, votre taux de vrais positifs (TPR) est calculé en prenant la somme de tous les TP de toutes les classes, et en divisant par la somme de tous les TP et FN de toutes les classes, c'est-à-dire pour un problème à 3 classes :
TPR = (TP1+TP2+TP3)/(TP1+TP2+TP3+FN1+FN2+FN3)

Exemple de matrice de confusion :
[[1,2,3],
[4,5,6],
[7,8,9]]
TPR = (1+5+9)/(1+5+9+(2+3)+(4+6)+(7+8))
Faites de même pour le taux de faux positifs et vous pourrez calculer l'AUC.

La moyenne macro calcule simplement le TPR pour chaque classe séparément et en fait la moyenne (pondérée par le nombre d'exemples dans cette classe ou non) :
TPR = (1/3)* (TP1/(TP1+FN1) + TP2/(TP2+FN2) + TP2/(TP2+FN2))

Avec le même exemple :
TPR = (1/3)* (1/(1+(2+3)) + 5/(5+(4+6)) + 9/(9+(7+8)))

Peut-être que cela aide (cela utilise de la précision, mais l'idée est la même):
http://stats.stackexchange.com/questions/156923/should-i-make-decisions-based-on-micro-averaged-or-macro-averaged-evaluation-mea

Personnellement, je n'utiliserais jamais de moyenne macro non pondérée, mais je vais voir si je peux trouver les articles qui ont étudié cela.

Papier:
https://www.math.ucdavis.edu/~saito/data/roc/ferri-class-perf-metrics.pdf

C'est ce qui est pris en charge dans R (avec de la littérature supplémentaire) :
https://mlr-org.github.io/mlr-tutorial/devel/html/measures/index.html

Salut! J'ai pu commencer à étudier ce problème la semaine dernière et je voulais poster une mise à jour rapide/quelques questions, juste pour m'assurer que je suis sur la bonne voie.

• Jusqu'à présent : je commence par l'implémentation d'une fonction multiclass_roc_auc_score qui, par défaut, aura un paramètre average défini sur Aucun. Cette valeur par défaut utilisera l'algorithme Hand-Till (comme indiqué, cela ne prend pas en compte le déséquilibre des étiquettes).
• La méthode accepterait-elle les mêmes paramètres que ceux de roc_auc_score ?
• Et à partir de là, la différence serait alors que y_true pourrait avoir plus de 2 classes d'étiquettes. Le Hand-Till impliquerait de trouver toutes les paires d'étiquettes possibles, de calculer roc_auc_score pour chacune de ces paires, puis de prendre la moyenne de celles-ci.

Faites-moi savoir quelles corrections/suggestions vous pourriez avoir !

Normalement, nous éviterions de créer une autre fonction si la réutilisation de roc_auc_score est raisonnablement faisable. Je pense que laisser la valeur par défaut comme « macro » est acceptable.

Une chose clé à laquelle vous devriez penser est de savoir comment tester ces changements, y compris changer les traits de roc_auc_score dans metrics/tests/test_common.py

ouais nous devrions mettre à jour les docs.

@joaquinvanschoren il est intéressant de

donc actuellement, nous n'avons que des multi-étiquettes, et nous voulons donc ajouter des multi-classes avec 1vs1 et 1vsRest et ils ont chacun des variantes pondérées et non pondérées.
Je ne comprends pas vraiment comment fonctionnent les moyennes de sample et micro pour l'AUC :(

Donc... Je propose que nous ajoutions un paramètre multi-class à AUC et qui peut être ovo ou ovr , et considérerons le paramètre de pondération. Je ne suis pas sûr que nous voulions autoriser sample et micro car cela n'a pas vraiment de sens pour moi.

@arjoly donc micro et sample opèrent sur les lignes plutôt que sur les colonnes de la matrice ? Y a-t-il des papiers à ce sujet ? Je n'ai pas trouvé cela dans la littérature ROC.

Le problème avec cela est que pour faire de la mesure à la main par défaut, nous aurions à faire une moyenne pondérée OvO et nous ne pouvons pas vraiment changer l'option de pondération. Alors peut-être que nous faisons OVR par défaut et expliquons dans le récit qu'OvO avec pondération est également un bon choix et ajoutons une référence ?

Le résumé de l'article cité par @joaquinvanschoren indique également que toutes les versions de l'AUC donnent à peu près les mêmes résultats.

@amueller : J'ai eu la chance de relire votre commentaire, et je suis un peu confus à propos de cette partie :

Le problème avec cela est que pour faire de la mesure à la main par défaut, nous aurions à faire une moyenne pondérée OvO et nous ne pouvons pas vraiment changer l'option de pondération. Alors peut-être que nous faisons OVR par défaut et expliquons dans le récit qu'OvO avec pondération est également un bon choix et ajoutons une référence ?

J'allais modifier le roc_auc_score pour incorporer un paramètre multiclass=['ovo', 'ovr'] selon votre réponse. Si OvR est par défaut ( roc_auc_score(y_true, y_score, multiclass="ovo" ... ) ), mais Hand & Till est OvO, que dois-je faire pour aborder la partie OvR de l'implémentation ? (c'est-à-dire que si je détecte que y_true est multiclasse, il suffit de déclencher une erreur si "ovr" n'est pas implémenté et de demander aux utilisateurs de passer "ovo" ?)

Désolé, je m'attendais à ce que vous implémentiez à la fois ovo et ovr ;) Je pense que cela devrait être assez simple.

@amueller : C'est noté et ça sera intégré aussi ! Je voulais également demander : existe-t-il des conseils sur la façon de détecter la différence entre multiclass et multilabel ? Au début, je vérifiais juste les dimensions de y_score mais je me suis très vite rendu compte que ce ne serait pas suffisant. (c'est-à-dire en vérifiant simplement que les étiquettes ne sont que des 0 et des 1 ?)

Multilabel signifie que plusieurs labels sont prédits à la fois : vous obtenez un
vecteur de prédictions par instance. Multiclass signifie que vous obtenez un seul
prédiction mais cette prédiction peut avoir plus de deux valeurs (ce n'est pas
binaire).

Parfois, les gens résolvent le cas multiclasse en binarisant la sortie, d'où
vous obtenez plusieurs valeurs binaires par instance (d'où multilabel) et ceci
cause souvent de la confusion.
Le samedi 8 octobre 2016 à 16h33, Kathy Chen [email protected] a écrit :

@amueller https://github.com/amueller : Noté et ce sera
incorporé aussi! Je voulais aussi demander : y a-t-il des conseils sur la façon de
détecter la différence entre multiclass et multilabel ? Au début, j'étais
juste en vérifiant les dimensions de y_score mais s'en est très vite rendu compte
ne serait pas suffisant.

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/scikit-learn/scikit-learn/issues/3298#issuecomment-252427642 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/ABpQV7Mv0rHGEfrkYi5Xezz3PItyrLZ6ks5qx6mdgaJpZM4CFzud
.

Salut, j'espère que type_of_target pourrait résoudre le problème de la différenciation entre la sortie multi-label et multi-class . HTH

utiliser type_of_target est une bonne idée. Bien que dans scikit-learn, la dimensionnalité de y soit en fait l'indicateur si nous voulons faire du multi-label ou du multi-cible. Si vous binarisez la sortie comme @joaquinvanschoren l'a suggéré, scikit-learn assumera toujours le multi-label.

type_of_target est bien pour faire la distinction entre les y_trues, @amueller

Le 9 octobre 2016 à 05:18, Andreas Mueller [email protected]
a écrit:

utiliser type_of_target est une bonne idée. Bien que dans scikit-learn le
la dimensionnalité de y est en fait l'indicateur si nous voulons faire
multi-label ou multi-cible. Si vous binarisez la sortie comme
@joaquinvanschoren https://github.com/joaquinvanschoren suggéré
scikit-learn assumera toujours le multi-label.

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/scikit-learn/scikit-learn/issues/3298#issuecomment-252439908 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AAEz6wa5fnE_LX3LLXbCoc0Z4hBbSAQ0ks5qx95rgaJpZM4CFzud
.

Salut à tous, je voulais juste vous faire savoir que j'ai soumis un PR "préliminaire". Je suis intéressé à entendre des commentaires sur la mise en œuvre (par exemple, je suis sûr qu'il existe des moyens d'exploiter numpy/etc. d'une meilleure manière que je ne le fais actuellement), ainsi que les meilleures pratiques pour ajouter de nouveaux tests, la formulation de la documentation, etc.

Merci pour toute l'aide apportée jusqu'à présent !

Des progrès sur l'ajout de la prise en charge multiclasse pour AUC ?

@joaquinvanschoren : travail sur les révisions après une revue de code par @jnothman dans #7663. Je soumettrai probablement une autre mise à jour à ce sujet la semaine prochaine lorsque j'aurai terminé les mi-sessions

Salut @kathyxchen , @jnothman ,

Des mises à jour sur le PR?

Juste vérifier pour voir s'il y a des progrès sur l'ajout de la prise en charge multiclasse pour AUC ?

nous avons du mal à déterminer ce qui est à la fois accepté et fondé sur des principes
formulation de ROC AUC pour multiclasse. Voir
https://github.com/scikit-learn/scikit-learn/pull/7663#issuecomment -307566895
et plus bas.

Alors les gars. Y a-t-il des progrès avec le score auc multiclasse ? J'ai trouvé un code de documentation officiel très déroutant avec l'ensemble de données iris. Parce que cette méthode montre que mon modèle prédit assez bien les nombres aléatoires.

C'est presque fait, nous devons décider d'un détail d'API avant de fusionner : https://github.com/scikit-learn/scikit-learn/pull/12789#discussion_r295693965

@trendsearcher pouvez-vous fournir un exemple s'il vous plaît ? Il est maintenant fusionné, mais j'aimerais voir le problème que vous avez rencontré.

Heureux de vous aider. Comment puis-je donner un exemple (il contient beaucoup de code et peut ne pas être
intuitif)? Peut-être que je peux l'écrire en texte brut?

чт, 18 июл. 2019 . 00:35, Andreas Mueller [email protected] :

@trendsearcher https://github.com/trendsearcher pouvez-vous fournir un
exemple s'il vous plait ? Il est maintenant fusionné mais j'aimerais voir le problème que vous
expérimenté.

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/scikit-learn/scikit-learn/issues/3298?email_source=notifications&email_token=AKS7QOFYRQY7RZJBWUVVJSTP76GDFA5CNFSM4AQXHOO2YY3PNVWWK3TUL52HS4DFJBWUVVVJSTP76GDFA5CNFSM4AQXHOO2YY3PNVWWK3TUL52HS4DFJBWUVVVJSTP76GDFA5CNFSM4AQXHOO2YY3PNVWWK3TUL52HS4DFVREXG43GUVMXVBT
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AKS7QOFQ5LAIZ2ZBR4M4EATP76GDFANCNFSM4AQXHOOQ
.

Bonjour, j'ai mis en place un brouillon du score ROC/AUC moyenné par macro, mais je ne sais pas s'il conviendra à sklearn.

Voici le code :

from sklearn.metrics import roc_auc_score
from sklearn.preprocessing import LabelBinarizer

def multiclass_roc_auc_score(truth, pred, average="macro"):

    lb = LabelBinarizer()
    lb.fit(truth)

    truth = lb.transform(truth)
    pred = lb.transform(pred)

    return roc_auc_score(truth, pred, average=average)

Cela pourrait-il être aussi simple que cela?

@fbrundu Merci pour le partage ! J'ai essayé ton code. Mais lorsque j'appelle cette fonction, je rencontre un problème en disant "Les données cibles multisorties ne sont pas prises en charge avec la binarisation des étiquettes". Ensuite, je supprime le code "pred=lb.transform(pred)" dans la fonction. Cependant, je rencontre un autre problème : "Variables d'entrée trouvées avec des nombres d'échantillons incohérents : [198, 4284]".

Puis-je vous demander si vous pouvez m'aider à résoudre ce problème ? Merci!

@Junting-Wang

 I meet a problem saying "Multioutput target data is not supported with label binarization". 

vous devez utiliser predict au lieu de predict_proba

@fbrundu est-ce que votre implémentation est correcte ? Je l'utilise et fonctionne.