Scikit-learn: Soporte para puntuaciones roc_auc de varias clases

No estoy seguro de lo que eso significa. ¿Tiene una referencia para ello?

El 19 de junio de 2014 a las 09:51, Madison May [email protected] escribió:

Solicitud de característica de baja prioridad: soporte para puntaje roc_auc de varias clases
cálculo en sklearn.metrics usando la metodología uno contra todos
sería increíblemente útil.

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/scikit-learn/scikit-learn/issues/3298.

Aquí hay una explicación bastante decente, junto con referencias: https://www.cs.bris.ac.uk/~flach/ICML04tutorial/ROCtutorialPartIII.pdf

hmm, ¿cuál es un anotador recomendado si no se implementa el auc de clases múltiples?

el soporte para el cálculo de la puntuación roc_auc de varias clases en sklearn.metrics utilizando la metodología uno contra todos sería increíblemente útil

¿Está hablando de lo que esas diapositivas consideran una aproximación al volumen bajo la superficie en la que se toma el promedio ponderado de frecuencia de AUC para cada clase? Esto parecería ser idéntico a usar el actual roc_auc_score con una representación binarizada y average='weighted' . ( @arjoly , ¿por qué estas puntuaciones basadas en curvas no permiten la multiclase?)

De lo contrario, esas diapositivas, y la mayoría de las referencias que puedo encontrar a "ROC de varias clases", se centran en la calibración de varias clases de OvR, no en una métrica de evaluación. ¿Es esto lo que le interesa? No tengo idea de cuán extendida está esta técnica, si vale la pena tenerla disponible en scikit-learn y si la optimización codiciosa debería mejorarse.

( @arjoly , ¿por qué estas puntuaciones basadas en curvas no permiten la multiclase?)

Siempre que falta una clase de y_true, no es posible calcular la puntuación. No quería agregar la magia para la inferencia de clase y metí a los usuarios en problemas.

Es posible que no estemos tratando adecuadamente en el caso de y_pred
tener una etiqueta que y_true no tiene. Esa etiqueta probablemente no debería
participar en algo parecido a un macropromedio (de acuerdo con Weka,
también), o una puntuación ROC.

El 1 de agosto de 2014 a las 17:08, Arnaud Joly [email protected] escribió:

( @arjoly https://github.com/arjoly, ¿por qué estos puntajes basados ​​en curvas
¿rechazar multiclase?)

Siempre que falta una clase de y_true, no es posible calcular
el marcador. No quise agregar la magia para la inferencia de la clase y obtuve
usuario en problemas.

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/scikit-learn/scikit-learn/issues/3298#issuecomment -50855460
.

@jnothman @arjoly ha habido mucho progreso en el frente de promedios. ¿Qué tan difícil es implementar esto ahora?

quizás podría ser similar a la función R del paquete pROC
http://www.inside-r.org/packages/cran/pROC/docs/multiclass.roc

Hola, implementé un borrador de la puntuación ROC / AUC promediada a nivel macro, pero no estoy seguro de si se ajustará a sklearn.

Aquí está el código:

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)

¿Podría ser tan simple como esto?

@fbrundu si este es el significado estándar. Ciertamente es una posible interpretación.

Aquí hay un buen resumen:
http://people.inf.elte.hu/kiss/13dwhdm/roc.pdf

El paquete pROC implementa 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.102.com% 252F10% 252Fart.102% 252F103 * ~ hmac = bc68686d3782ac6af3c3cda13c1b36aad6de5d01d16a25870cace5fe9699fb8a

La versión de Hand and Till parece ser generalmente aceptada y voto para que la implementemos.
También hay una versión de Provost y Domingos que probablemente debería rootear dado que Provost es actualmente mi director, pero eso no ha tenido éxito.
El Provost-Domingos es lo que dijo @fbrundu solo con average='weighted' .

TLDR: PR para Hand and Till welcome. Opcionalmente Provost y Domingos con opción de cambiar el promedio.

Hola, ¿ha habido algún progreso en la implementación de esto?
Lo que he visto en la mayoría de las otras bibliotecas (por ejemplo, WEKA) es que usan el promedio ponderado. Creo que esto es lo que propuso @fbrundu usando average = 'micro'?

@joaquinvanschoren R usa Hand and Till. Yo también prefiero ese. Tengo un estudiante que trabajará en esto pronto.

@amueller puedo trabajar en esto :)

@ kchen17 gracias!

Hablamos bastante de esto en OpenML. Para AUC multiclase no hay garantías de que un enfoque (macropromedio, micropromedio, promedio ponderado, ...) sea mejor que el otro. En R puede encontrar al menos 5 enfoques diferentes (todos también disponibles en MLR ahora).
Al implementar esto en scikit-learn, sería genial si hubiera al menos la posibilidad de elegir el que tenga más sentido para su aplicación, incluso si usa Hand-Till como predeterminado. Hand-Till es un enfoque no ponderado, por cierto, no tiene en cuenta el desequilibrio de etiquetas.

Estoy feliz de tener varias versiones. no ponderado y "no tener en cuenta el desequilibrio de etiquetas" son dos cosas diferentes;) ¿Tiene una lista y referencias?

¿Qué es el micropromedio en este caso?

Tenga en cuenta que ya hemos implementado el AUC de ROC micro y macro para problemas multiclase en este ejemplo:

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

En realidad, creo que la documentación es incorrecta y debería decir
multilabel ...

El 26 de septiembre de 2016 a las 23:16, Olivier Grisel [email protected]
escribió:

No es que ya hayamos micro y macro promediados AUC de ROC para multiclase
problemas implementados en este ejemplo:

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

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/scikit-learn/scikit-learn/issues/3298#issuecomment -249566346,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AAEz65IeU7k2CFwyHxTTAjk-5orIxWe6ks5qt8WsgaJpZM4CFzud
.

En el micropromedio, su tasa positiva verdadera (TPR) se calcula tomando la suma de todos los TP de todas las clases y dividiendo por la suma de todos los TP y FN de todas las clases, es decir, para un problema de 3 clases:
TPR = (TP1 + TP2 + TP3) / (TP1 + TP2 + TP3 + FN1 + FN2 + FN3)

Ejemplo de matriz de confusión:
[[1,2,3],
[4,5,6],
[7,8,9]]
TPR = (1 + 5 + 9) / (1 + 5 + 9 + (2 + 3) + (4 + 6) + (7 + 8))
Haga lo mismo con la tasa de falsos positivos y podrá calcular el AUC.

El promedio de macros solo calcula el TPR para cada clase por separado y los promedia (ponderado por el número de ejemplos en esa clase o no):
TPR = (1/3) * (TP1 / (TP1 + FN1) + TP2 / (TP2 + FN2) + TP2 / (TP2 + FN2))

Con el mismo ejemplo:
TPR = (1/3) * (1 / (1+ (2 + 3)) + 5 / (5+ (4 + 6)) + 9 / (9+ (7 + 8)))

Quizás esto ayude (esto usa precisión, pero la idea es la misma):
http://stats.stackexchange.com/questions/156923/should-i-make-decisions-based-on-micro-averaged-or-macro-averaged-evaluation-mea

Personalmente, nunca usaría un macropromedio no ponderado, pero veré si puedo encontrar los artículos que estudiaron esto.

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

Esto es lo que se apoya en R (con literatura adicional):
https://mlr-org.github.io/mlr-tutorial/devel/html/measures/index.html

¡Hola! Pude comenzar a investigar este problema la semana pasada y quería publicar una actualización rápida / algunas preguntas, solo para asegurarme de que estoy en el camino correcto.

• Hasta ahora: estoy comenzando con la implementación de una función multiclass_roc_auc_score que, por defecto, tendrá algún parámetro average configurado en Ninguno. Este valor predeterminado utilizará el algoritmo Hand-Till (como se discutió, esto no tiene en cuenta el desequilibrio de etiquetas).
• ¿Aceptaría el método los mismos parámetros que los de roc_auc_score ?
• Y saliendo de eso, la diferencia sería entonces que y_true podría tener más de 2 clases de etiquetas. Hand-Till implicaría encontrar todos los pares posibles de etiquetas, calcular roc_auc_score para cada uno de estos pares y luego calcular la media de estos.

¡Déjeme saber qué correcciones / sugerencias puede tener!

Normalmente, evitaríamos crear otra función si reutilizar roc_auc_score es razonablemente factible. Creo que dejar el valor predeterminado como "macro" es aceptable.

Una cosa clave en la que debería pensar es cómo probar estos cambios, incluido el cambio de los rasgos de roc_auc_score en metrics / tests / test_common.py

sí, deberíamos actualizar los documentos.

@joaquinvanschoren, curiosamente, ese artículo no discutió ninguno de los artículos de AUC de clases múltiples mencionados anteriormente, en particular, no el artículo de Fawcett de 2005 ... hm, ¿supongo que es una renormalización de la clase múltiple 1 contra 1?

por lo que actualmente solo tenemos etiquetas múltiples, por lo que queremos agregar clases múltiples con 1vs1 y 1vsRest y cada una tiene variantes ponderadas y no ponderadas.
Realmente no entiendo cómo funcionan los promedios de sample y micro para AUC :(

Entonces ... propongo que agreguemos un parámetro multi-class a AUC y que puede ser ovo o ovr , y consideraremos el parámetro de ponderación. No estoy seguro de que queramos permitir sample y micro ya que eso realmente no tiene sentido para mí.

@arjoly entonces micro y sample operan en las filas en lugar de en las columnas de la matriz? ¿Hay artículos sobre eso? No encontré eso en la literatura de la República de China.

El problema con eso es que para hacer que la medida de labranza manual sea predeterminada, tendríamos que hacer un OvO promedio ponderado y realmente no podemos cambiar la opción de ponderación. Entonces, ¿tal vez hacemos OVR por defecto y explicamos en la narrativa que OvO con ponderación también es una buena opción y agregamos una referencia?

El resumen del artículo citado por @joaquinvanschoren también dice que todas las versiones de AUC dan prácticamente los mismos resultados.

@amueller : Tuve la oportunidad de leer tu comentario nuevamente, y estoy un poco confundido acerca de esta parte:

El problema con eso es que para hacer que la medida de labranza manual sea predeterminada, tendríamos que hacer un OvO promedio ponderado y realmente no podemos cambiar la opción de ponderación. Entonces, ¿tal vez hacemos OVR por defecto y explicamos en la narrativa que OvO con ponderación también es una buena opción y agregamos una referencia?

Iba a modificar el roc_auc_score para incorporar un parámetro multiclass=['ovo', 'ovr'] según su respuesta. Si OvR es el valor predeterminado ( roc_auc_score(y_true, y_score, multiclass="ovo" ... ) ), pero Hand & Till es OvO, ¿qué debo hacer para abordar la parte OvR de la implementación? (es decir, si detecto que y_true es multiclase, ¿simplemente generar un error si "ovr" no está implementado e indicar a los usuarios que pasen "ovo"?)

Lo siento, esperaba que implementaras tanto ovo como ovr ;) Creo que debería ser bastante sencillo.

@amueller : ¡ y_score pero rápidamente me di cuenta de que esto no sería suficiente. (es decir, ¿solo verificar que las etiquetas sean solo 0 y 1?)

Multilabel significa que se predicen varias etiquetas a la vez: obtienes un
vector de predicciones por instancia. Multiclase significa que obtienes una
predicción, pero esa predicción puede tener más de dos valores (no es
binario).

A veces, la gente resuelve el caso multiclase binarizando la salida, por lo tanto
obtienes múltiples valores binarios por instancia (por lo tanto, multilabel) y esto
a menudo causa confusión.
El sábado 8 de octubre de 2016 a las 16:33, Kathy Chen [email protected] escribió:

@amueller https://github.com/amueller : Anotado y eso será
incorporado también! También quería preguntar: ¿hay algún consejo sobre cómo
detectar la diferencia entre multiclase y multilabel? Al principio, estaba
solo verificando las dimensiones de y_score pero rápidamente me di cuenta de esto
no sería suficiente.

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/scikit-learn/scikit-learn/issues/3298#issuecomment -252427642,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/ABpQV7Mv0rHGEfrkYi5Xezz3PItyrLZ6ks5qx6mdgaJpZM4CFzud
.

Hola, espero que type_of_target pueda resolver el propósito de diferenciar entre multi-label y multi-class salida. HTH

usar type_of_target es una buena idea. Aunque en scikit-learn, la dimensionalidad de y es en realidad el indicador de si queremos hacer múltiples etiquetas o múltiples objetivos. Si binarización en la salida como @joaquinvanschoren sugerido scikit-learn siempre asumir varias etiquetas.

type_of_target está bien para distinguir entre los y_trues, @amueller

El 9 de octubre de 2016 a las 05:18, Andreas Mueller [email protected]
escribió:

usar type_of_target es una buena idea. Aunque en scikit-learn the
La dimensionalidad de y es en realidad el indicador de si queremos hacer
multi-etiqueta o multi-objetivo. Si binariza la salida como
@joaquinvanschoren https://github.com/joaquinvanschoren sugirió
scikit-learn siempre asumirá múltiples etiquetas.

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/scikit-learn/scikit-learn/issues/3298#issuecomment -252439908,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AAEz6wa5fnE_LX3LLXbCoc0Z4hBbSAQ0ks5qx95rgaJpZM4CFzud
.

Hola a todos, solo quería informarles que envié un PR "preliminar". Estoy interesado en escuchar algunos comentarios sobre la implementación (por ejemplo, estoy seguro de que hay formas de aprovechar numpy / etc. de una mejor manera de lo que estoy haciendo ahora), junto con las mejores prácticas para agregar nuevas pruebas, redacción de la documentación, etc.

¡Gracias por toda la ayuda hasta ahora!

¿Algún progreso en la adición de soporte multiclase para AUC?

@joaquinvanschoren : trabajando en revisiones después de una revisión de código por @jnothman en # 7663. Probablemente envíe otra actualización sobre eso la próxima semana cuando haya terminado con las elecciones parciales.

Hola @kathyxchen , @jnothman ,

¿Alguna actualización sobre las relaciones públicas?

¿Solo se está registrando para ver si hay algún progreso en la adición de soporte multiclase para AUC?

tenemos problemas para determinar lo que es un principio aceptado y
formulación de ROC AUC para multiclase. Ver
https://github.com/scikit-learn/scikit-learn/pull/7663#issuecomment -307566895
y por debajo.

Así que amigos. ¿Hay algún progreso con la puntuación auc multiclase? Encontré un código de documentación oficial muy confuso con el conjunto de datos de iris. Porque este método muestra que mi modelo predice números aleatorios bastante bien.

Esto casi está hecho, necesitamos decidir sobre un detalle de API antes de fusionar: https://github.com/scikit-learn/scikit-learn/pull/12789#discussion_r295693965

@trendsearcher, ¿ puede dar un ejemplo, por favor? Ahora está combinado, pero me gustaría ver el problema que experimentó.

Encantado de ayudar. ¿Cómo puedo dar un ejemplo (tiene mucho código y puede que no
intuitivo)? ¿Quizás pueda escribirlo en texto plano?

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

@trendsearcher https://github.com/trendsearcher ¿ puede proporcionar un
ejemplo por favor? Ahora está fusionado, pero me gustaría ver el problema.
experimentado.

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/scikit-learn/scikit-learn/issues/3298?email_source=notifications&email_token=AKS7QOFYRQY7RZJBWUVVJSTP76GDFA5CNFSM4AQXHOO2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2GU7EI#issuecomment-512577425 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AKS7QOFQ5LAIZ2ZBR4M4EATP76GDFANCNFSM4AQXHOOQ
.

Hola, implementé un borrador de la puntuación ROC / AUC promediada a nivel macro, pero no estoy seguro de si se ajustará a sklearn.

Aquí está el código:

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)

¿Podría ser tan simple como esto?

@fbrundu ¡ Gracias por compartir! Probé tu código. Pero cuando llamo a esta función, encuentro un problema que dice "Los datos de destino de salida múltiple no son compatibles con la binarización de etiquetas". Luego elimino el código "pred = lb.transform (pred)" en la función. Sin embargo, me encuentro con otro problema que "Encontré variables de entrada con números inconsistentes de muestras: [198, 4284]".

¿Puedo preguntar si podría ayudarme a resolver esto? ¡Gracias!

@ Junting-Wang

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

tienes que usar predecir en lugar de predecir_proba

@fbrundu ¿su implementación es correcta? Lo uso y funciona.