Partitionnement des arbres dans R: party vs. rpart

Cela fait un moment que je n'ai pas regardé le partitionnement des arbres. La dernière fois que j'ai fait ce genre de choses, j'aime faire la fête en R (créé par Hothorn). L'idée de l'inférence conditionnelle via l'échantillonnage est logique pour moi. Mais rpart avait également un attrait.

Dans l'application actuelle (je ne peux pas donner de détails, mais cela implique d'essayer de déterminer qui ira en prison parmi un large échantillon de personnes arrêtées), je ne peux pas utiliser des méthodes avancées comme les forêts aléatoires, l'ensachage, le boosting, etc. règle.

J'aimerais également avoir un contrôle manuel sur les nœuds divisés, comme recommandé dans Zhang & Singer (2010) Recursive Partitioning and Applications . Le logiciel gratuit fourni avec ce livre le permet, mais est par ailleurs plutôt primitif dans sa saisie utilisateur.

Des recommandations ou suggestions?

Je suis d'accord avec @Iterator que la méthodologie est plus facile à expliquer pour rpart. Cependant, si vous cherchez des règles facilement explicables, la fête (sans arbres en sac) ne perd rien en ce qui concerne l'explication de la prédiction - vous avez toujours un seul arbre. Si vous êtes également intéressé à examiner les moteurs de la variable de résultat (pas seulement le pouvoir prédictif pur), je pense toujours que la partie est la voie à suivre - expliquant qu'un arbre de décision (comme rpart) peut être assez biaisé dans la façon dont il sélectionne lequel les variables sont importantes et comment elles créent des divisions. Party utilise des tests de permutation et détermine statistiquement quelles variables sont les plus importantes et comment les répartitions sont effectuées. Ainsi, au lieu de privilégier les variables catégorielles à plusieurs niveaux, comme rpart par exemple, le parti utilise des tests statistiques pour trouver la meilleure structure.

[NB: Voir la mise à jour 1 ci-dessous.] Je trouve que la méthodologie de rpartest beaucoup plus facile à expliquer qu'à party. Ce dernier est cependant beaucoup plus sophistiqué et susceptible de donner de meilleurs modèles. La façon dont j'explique parfois partyest d'en parler comme base pour produire des modèles linéaires locaux (ou GLM). Je construis pour cela en soulignant que les résultats pour rpartsont constants à travers tous les éléments qui tombent dans le nœud feuille, c'est-à-dire la boîte / région délimitée par les divisions. Même s'il pourrait y avoir des améliorations via des modèles locaux, vous n'obtenez rien d'autre qu'une prédiction constante.

En revanche, partydéveloppe les scissions pour potentiellement optimiser les modèles pour les régions. Il utilise en fait un critère différent de l'optimalité du modèle, mais vous devez évaluer votre propre capacité à expliquer la différence pour déterminer si vous pouvez bien l'expliquer. Les articles sont assez accessibles pour un chercheur, mais peuvent être assez difficiles pour quelqu'un qui ne veut pas envisager des méthodes plus simples comme les forêts aléatoires, le boost, etc. Mathématiquement, je pense que partyc'est plus sophistiqué ... Néanmoins, les modèles CART sont plus faciles à expliquer, à la fois en termes de méthodologie et de résultats, et ceux-ci fournissent un tremplin décent pour l'introduction de modèles d'arbres plus sophistiqués.

En bref, je dirais que vous devez faire rpartpour la clarté, et vous pouvez utiliser partypour la précision / performance, mais je ne présenterais pas partysans introduire rpart.

Mise à jour 1. J'ai basé ma réponse sur ma compréhension de partyce qu'il était il y a un an ou deux. Il a grandi un peu, mais je modifierais ma réponse pour dire que je recommanderais toujours rpartpour sa brièveté et son héritage, si "non fantaisie" devait être un critère important pour votre client / collaborateur. Pourtant, j'essaierais de migrer vers plus de fonctionnalités partyaprès avoir présenté quelqu'un à rpart. Il vaut mieux commencer petit, avec des fonctions de perte, des critères de fractionnement, etc., dans un contexte simple, avant d'introduire un package et une méthodologie qui impliquent des concepts beaucoup plus impliqués.