Gridsearch pour l'estimation des paramètres SVM

J'expérimente actuellement avec gridsearch pour former une machine à vecteur de support. Je comprends que si j'ai des paramètres gamma et C, la fonction R tune.svm effectue une validation croisée 10 fois pour toutes les combinaisons de ces 2 paramètres.

Comme je ne savais pas par où commencer, j'ai essayé d'obtenir des informations à ce sujet, par exemple wikipedia 2 suggère des valeurs qui ne sont pas linéaires, par exemple C dans la plage {10, 100, 1000}.

Jusqu'à présent, j'utilise les exemples de mon deuxième lien wikipedia, qui est:

gammas = 2^(-15:3)
costs = 2^(-5:15)

Ce qui donne 399 combinaisons.

Cela prend très, très longtemps (~ 2000 échantillons). Par exemple pour le noyau "radial" mon meilleur résultat est gamma = 0,5 et coût = 2.

Ne pourrais-je pas obtenir le même résultat si je viens d'utiliser des valeurs comme (1, 2, 3, 4, ... 10) pour les coûts et (0, 0,5, 1, 1,5, 2) pour les gammas? Je sais que cet exemple est construit parce que je connais déjà le résultat.

Ma question:

Mais pourquoi cette échelle exponentielle?

Il y a tellement de valeurs entre 0 et 1 que je pense que c'est une perte de temps de calcul et seulement si peu de très gros nombres qu'il n'a pas pu trouver un résultat très précis de toute façon. Cela n'aurait de sens pour moi que si cela était utilisé pour trouver une gamme plus petite, disons que nous savons alors que le meilleur coût est 2 ^ 3, puis nous cherchons autour de cela. Mais il n'est mentionné nulle part qui est exécuté de cette façon.

La raison de la grille exponentielle est que C et gamma sont des paramètres d' échelle qui agissent de manière multiplicative, donc doubler le gamma est aussi susceptible d'avoir un effet à peu près aussi important (mais dans l'autre sens) que de le diviser par deux. Cela signifie que si nous utilisons une grille de valeurs augmentant approximativement de façon exponentielle, il y a à peu près la même quantité d '"informations" sur les hyperparamètres obtenus par l'évaluation du critère de sélection du modèle à chaque point de la grille.

Je recherche généralement sur une grille basée sur des puissances entières de 2, ce qui semble fonctionner assez bien (je travaille sur un document sur l'optimisation de la recherche de grille - si vous utilisez une grille trop fine, vous pouvez finir par sur-ajuster le critère de sélection du modèle , donc une grille assez grossière s'avère bonne pour la généralisation ainsi que pour les dépenses de calcul.).

En ce qui concerne la large gamme, malheureusement, les valeurs optimales d'hyper-paramètre dépendent de la nature du problème et de la taille de l'ensemble de données et ne peuvent être déterminées a priori. La raison de la grande grille, apparemment inutile, est de s'assurer que les bonnes valeurs peuvent être trouvées automatiquement, avec une forte probabilité.

Si les dépenses de calcul sont un problème, alors plutôt que d'utiliser la recherche dans la grille, vous pouvez utiliser l' algorithme Nelder-Mead simplex pour optimiser l'erreur de validation croisée. Il s'agit d'un algorithme d'optimisation qui ne nécessite pas d'informations sur le gradient, il est donc assez simple à utiliser pour tout problème où la recherche de grille est actuellement utilisée. Je ne suis pas un utilisateur R, mais Nelder-Mead est implémenté dans R via optim.

C'est ce qu'on appelle le problème de "réglage des paramètres" pour les SVM. L'une des approches les plus simples consiste à prendre la médiane de chacun pour les plus grands niveaux de précision de prédiction de classe obtenus au fur et à mesure que vous parcourez les plis du CV.

En outre, en règle générale, utilisez un classificateur plus simple pour déterminer si vos données sont linéairement séparables. Si k-le plus proche voisin (kNN) ou la régression linéaire fonctionne mieux, vous ne devriez pas utiliser une approche plus coûteuse (par calcul) comme SVM. SVM peut être facilement surutilisé, alors assurez-vous d'évaluer la régression linéaire, le kNN, l'analyse discriminante linéaire, les forêts aléatoires, etc.