Classificateur pour les étiquettes de classe incertaines

11

Disons que j'ai un ensemble d'instances avec des étiquettes de classe associées. Peu importe comment ces instances ont été étiquetées, mais la certitude de leur appartenance à la classe. Chaque instance appartient à exactement une classe. Disons que je peux quantifier la certitude de chaque appartenance à une classe avec un attribut nominal qui va de 1 à 3 (très certain à incertain, respectivement).

Existe-t-il une sorte de classificateur qui prend en compte une telle mesure de certitude et si oui, est-il disponible dans la boîte à outils WEKA?

J'imagine que cette situation se produit assez souvent, par exemple lorsque des cas sont classés par des êtres humains qui ne sont pas toujours complètement sûrs. Dans mon cas, je dois classer des images, et parfois une image peut appartenir à plusieurs classes. Si cela se produit, je donne à la classe une grande incertitude, mais je la classe toujours avec une seule classe.

Ou existe-t-il d'autres approches à ce problème, sans classificateur spécialisé? Par exemple, prendre uniquement "certaines" classifications pour la formation? Je crains que dans ce cas, il y ait davantage de fausses classifications car les cas "frontaliers" ne sont pas couverts.

wnstnsmth
la source
1
Chaque entrée appartient-elle à une seule classe? Ou est-il possible que certaines entrées appartiennent à la classe 12 avec certitude 1 et à la classe 34 avec certitude 2?
user31264
Dans ce cas, chaque entrée appartient à une seule classe.
wnstnsmth

Réponses:

8

Tout d'abord, comme @Marc Claesen l'a déjà expliqué, la classification semi-supervisée est l'une des techniques pour gérer la situation où vous savez que les classes sont vraiment distinctes, mais vous n'êtes pas certain de la classe à laquelle le cas appartient réellement.

Cependant, il existe également des situations connexes, où la «réalité» n'est pas aussi claire et l'hypothèse d'avoir des classes vraiment distinctes n'est pas remplie: les cas limites peuvent être une réalité «physique» (voir ci-dessous pour les articles sur une application où nous avons rencontré une telle condition).

Il y a une hypothèse cruciale pour les classificateurs semi-supervisés dont vous devez vous assurer qu'elle est respectée: l'hypothèse selon laquelle dans l'espace des entités, les limites des classes s'accompagnent d'une faible densité d'échantillonnage . C'est ce que l'on appelle l'hypothèse de cluster.
Même si la réalité sous-jacente à vos données a des classes distinctes, votre ensemble de données peut avoir des cas disproportionnellement plus nombreux: par exemple, si votre technique de classification vise à classer les cas difficiles, alors que les cas clairs et faciles ne sont pas intéressants et que vos données de formation le reflètent déjà situation.

ne prendre que "certaines" classifications pour la formation? Je crains que dans ce cas, il y ait davantage de fausses classifications car les cas "frontaliers" ne sont pas couverts.

Je suis entièrement d'accord avec vous qu'exclure les cas limites est souvent une mauvaise idée: en supprimant tous les cas difficiles, vous vous retrouvez avec un problème artificiellement facile. À mon humble avis, il est encore pire que l'exclusion des cas limites ne s'arrête généralement pas avec la formation au modèle, mais les cas limites sont également exclus du test, testant ainsi le modèle uniquement avec des cas faciles. Avec cela, vous ne vous rendriez même pas compte que le modèle ne fonctionne pas bien avec les cas limites.

Voici deux articles que nous avons écrits sur un problème qui diffère du vôtre en ce que dans notre application, la réalité peut également avoir des classes "mixtes" (une version plus générale de votre problème: l'incertitude dans les étiquettes de référence est également couverte).

Les liens mènent à une page de projet d'un package R que j'ai développé pour effectuer les calculs de performances. Il existe d'autres liens vers la page Web officielle et mes manuscrits des articles. Bien que je n'aie pas utilisé Weka jusqu'à présent, je comprends qu'une interface vers R est disponible .


considérations pratiques:

  • Bien que l'approche copier-et-étiqueter différemment soit simple, elle ne fonctionne pas bien avec tous les classificateurs et implémentations dans la pratique. Par exemple, AFAIK, il n'y a aucun moyen de déterminer libSVMle réglage par validation croisée que toutes les copies de chaque point de données doivent être conservées dans le même pli de validation croisée. Ainsi, libSVMle réglage s donnerait probablement un modèle massivement surajusté.
  • Également pour la régression logistique, j'ai constaté que de nombreuses implémentations ne permettaient pas les étiquettes d'appartenance partielles dont j'avais besoin.
  • L'implémentation que j'ai utilisée pour les articles ci-dessus est en fait un ANN sans couche cachée utilisant la logistique comme fonction de lien sigmoïde ( nnet::multinom).
cbeleites mécontents de SX
la source
Votre première considération pratique, bien que vraie, ne s'applique pas libsvmen particulier. Les libsvmauteurs proposent une version alternative de chaque version dans laquelle une classification pondérée par les instances est possible, évitant complètement ce problème. Ce sont ces choses qui me poussent à utiliser directement les bibliothèques d'algorithmes, plutôt que des wrappers comme Weka / scipy / ... csie.ntu.edu.tw/~cjlin/libsvmtools/#weights_for_data_instances
Marc Claesen
@MarcClaesen: merci - je n'avais pas vu ça. Mais n'auriez-vous pas besoin de fournir deux instances du même cas, l'une pondérée disons avec 1/3 classe A et l'autre avec 2/3 classe B? Dans tous les cas, le fait de ne pas avoir à fournir de nombreuses copies des cas clairs rendra le réglage moins problématique (pour mes données, je dois de toute façon effectuer les répartitions de réglage en externe car j'ai une structure de données "hiérarchique" avec plusieurs mesures des cas réels )
cbeleites mécontents de SX
@cbeiteles lorsqu'une instance peut appartenir à plusieurs classes, vous devrez en effet la fournir plusieurs fois, même avec cette pondération d'instance. Je n'avais pas envisagé cette possibilité.
Marc Claesen
6

C'est l'une des généralisations de la classification qui sont abordées dans l'apprentissage semi-supervisé. Si vous avez une mesure de certitude, vous pouvez utiliser des approches qui permettent de pondérer les instances de formation. Plus la certitude est élevée, plus le poids d'instance correspondant est élevé. Des exemples de telles approches incluent la SVM pondérée par l'instance et la régression logistique.

Je suis sûr que weka a implémenté ces algorithmes. Si tout le reste échoue, échantillonnez plusieurs instances des instances avec une grande certitude. Vous pouvez utiliser cette approche pour SVM ou LR traditionnel.

Exemple: SVM

Si je ne me trompe pas, weka a des interfaces avec LIBSVM . LIBSVM vous permet de résoudre SVM pondéré par classe dans toutes ses versions, et SVM pondéré par instance dans les versions spéciales de chaque version. Je vais supposer que weka ne prend pas en charge ce dernier (ce dont vous avez besoin).

Le SVM pondéré par classe minimise la fonction d'objectif suivante: avec l'hyperplan de séparation dans l'espace des fonctions, les variables lentes (qui modélisent la classification erronée de la formation) et et l'ensemble des vecteurs de support appartenant respectivement à la classe positive et négative. En utilisant les poids et vous pouvez attribuer différentes pénalités de mauvaise classification entre les classes.

minw,ξw2+CposiPξi+CnegiNξi,
wξPNCposCneg

Sur la base de votre question, il semble que vous souhaitiez idéalement utiliser 6 poids différents (2 classes 3 niveaux de certitude). Vous pouvez y parvenir pour de nombreuses approches en dupliquant des échantillons des points avec une grande certitude.×

Par exemple, en termes de SVM, l'utilisation de la même instance de données donne deux fois une solution identique pour doubler sa valeur associée . Il s'agit d'un moyen très simple d'attribuer des pénalités de classification erronée élevées à certaines instances de données. Vous pouvez suivre la même approche pour la régression logistique.C

Marc Claesen
la source
(+1) c'est ça! En dupliquant des instances avec des étiquettes et des poids d'instance différents (alias certitudes d'étiquette), on peut également appliquer des algorithmes comme Random Forests, Naive Bayes etc. Les poids d'instance sont si courants, weka doit avoir des apprenants qui le prennent en charge. Rapidminer (concurrent de weka) le fait. En définissant la certitude à 1, on peut même modéliser des problèmes multi-étiquettes "nets".
steffen
Vous avez raison, WEKA prend en charge LIBSVM, mais ne prend pas en charge la pondération d'instance, afaik. L'idée de dupliquer des instances est très bonne, je pense, surtout parce que chaque apprenant "traditionnel" peut y faire face.
wnstnsmth
2

La difficulté du problème dépend fortement de l’erreur des étiquettes incertaines. Si les étiquettes incertaines sont correctes, disons, 90% du temps, vous pouvez probablement vous en tirer en utilisant simplement la régression logistique. D'un autre côté, si les étiquettes sont erronées presque la moitié du temps, vous devrez peut-être recourir à certaines techniques spéciales. Voici un coup de couteau que j'ai pris à un problème très similaire. (Nous avons eu plusieurs observations par étiquette, mais sinon la configuration est assez similaire.)

Stefan Wager
la source
-5

J'ai eu un bref aperçu de la reconnaissance et de la classification des images.

Les forêts aléatoires est une technique facile à utiliser. Je l'ai implémenté sur R, il devrait également être disponible sur Weka. La facilité d'utilisation l'emporte cependant sur la précision des prévisions. Si vous disposez d'un ensemble d'entraînement suffisamment grand, il peut classer plusieurs étiquettes.

Cela a fonctionné pour reconnaître assez bien les chiffres manuscrits, mais si vos images sont plus complexes, seul un essai vous dira si cela fonctionne bien.

Arun Jose
la source
4
Qu'est-ce que cela a à voir avec les étiquettes de classe incertaines?
wnstnsmth