Faut-il donner des cas d'entraînement «trompeurs» à un classificateur Naive Bayes?

Question

Je suis en train de mettre en place un classificateur Naive Bayes pour essayer de déterminer l'identité entre deux enregistrements de cinq propriétés de corde. Je ne compare que chaque paire de propriétés exactement (c'est-à-dire, avec une méthode java .equals()). J'ai quelques données d'entraînement, à la fois TRUE et FALSE, mais concentrons-nous sur les cas VRAI pour le moment. Disons qu'il existe des cas de formation TRUE où les cinq propriétés sont différentes. Cela signifie que chaque comparateur échoue, mais les enregistrements sont en fait déterminés à être les mêmes après une évaluation humaine.

Est-ce que ce cas d'entraînement doit être acheminé au classificateur Naive Bayes? D'une part, compte tenu du fait que NBC traite chaque variable séparément, ces cas ne devraient pas le casser totalement. Cependant, il semble certainement vrai que l'alimentation d'un nombre suffisant de ces cas ne serait pas bénéfique pour la performance du classificateur. Je comprends que voir beaucoup de ces cas signifierait que de meilleurs comparateurs sont nécessaires, mais je me demande ce qu'il faut faire pour le moment. Une autre considération est que le revers de la médaille est impossible; c'est-à-dire qu'il est impossible que les cinq propriétés soient identiques entre deux enregistrements et qu'elles soient toujours des enregistrements 'différents'.

S'agit-il d'un problème préférentiel, ou y a-t-il une pratique généralement acceptée pour ce faire?

Answer 1

Habituellement, vous voudrez avoir un ensemble de données d'apprentissage aussi représentatif que possible du domaine à partir duquel vous espérez classer les observations (souvent difficile). Un ensemble non représentatif peut conduire à un classificateur qui fonctionne mal, en particulier dans un environnement de production où diverses données sont reçues. Cela étant dit, le prétraitement peut être utilisé pour limiter l'exposition d'un classificateur formé sur un sous-ensemble particulier de données, de sorte qu'il dépend tout à fait de l'objectif du classificateur.

Je ne sais pas exactement pourquoi vous souhaitez exclure certains éléments. L'estimation/l'apprentissage des paramètres doit tenir compte du fait que deux entrées différentes peuvent correspondre à la même sortie --- c'est pourquoi vous utiliseriez l'apprentissage automatique au lieu d'utiliser simplement un hashmap. Considérant que vous n'avez généralement pas 'toutes les données' pour construire votre modèle, vous devez vous fier à ce type d'inférence.

Avez-vous jeté un coup d'œil au NLTK; il est en python mais il semble que OpenNLP peut être un substitut approprié en Java? Vous pouvez utiliser de meilleures techniques d'extraction de caractéristiques qui conduisent à un modèle qui tient compte des variations mineures dans les chaînes d'entrée (voir here).

Enfin, il me semble que vous voulez apprendre une application de chaînes d'entrée aux classes « même » et « pas même » --- vous semblez vouloir déduire une mesure de distance (juste vérifier). Il serait plus logique d'investir des efforts pour trouver directement une meilleure mesure (par exemple, pour les problèmes de transposition de caractères, vous pouvez utiliser edit distances). Je ne suis pas sûr que NB soit bien adapté à votre problème car il essaie de déterminer une classe à partir d'une observation (ou de ses caractéristiques). Cette classe devra être discernable sur différentes chaînes (je suppose que vous allez concaténer string1 & chaîne2, et les offrir au classificateur). Y aura-t-il suffisamment de structure pour dériver une propriété aussi largement applicable? Ce classificateur va fondamentalement devoir être capable de gérer toutes les «comparaisons» par paires, sauf si vous construisez des NB pour chaque appariement un-à-plusieurs. Cela ne semble pas être une approche simple.