• Aucun résultat trouvé

traction de modèles de processus partiels profi-

tables

Dans cette section, nous présentons différentes applications des heuristiques proposées pour le problème d’extraction de modèles de processus profitables. Dans un premier temps, nous évaluons dans quelle mesure les différentes configurations des heuristiques répondent à notre objectif de réduire les temps de calcul, tout en permettant l’extraction de HU- LPMs de bonne qualité. Nous définissons une configuration comme la combinaison d’une heuristique et d’une valeur de k. Dans un second temps, nous explorons les relations entre la performance des configurations en termes de gain de temps de calcul et de qualité des HU-LPMs extraits, et les propriétés du log.

Nous détaillons le contexte des expérimentations et notre méthodologie d’évaluation dans la sous-section 7.2.1 et analysons les résultats dans la sous-section 7.2.2. Nous pré- sentons l’analyse détaillée des relations entre la performance des heuristiques et les carac- téristiques du log dans la sous-section 7.2.3.

7.2.1

Contexte d’évaluation

Pour évaluer la performance des différentes configurations heuristiques, nous appli- quons chacune d’elles sur une collection d’event logs composée de 3 logs réels issus de la littérature et d’un ensemble de logs générés pour nos expérimentations. Les logs réels sont le BPI’13 closed problems, composé de 1 487 traces, du BPI’13 open problems composé de 819 traces et d’un log artificiel extrait du "Process Mining book" [van der Aalst, 2016] (Chapitre 1) composé de 6 traces.

Étant donné que nous désirons explorer les relations entre la performance des diffé- rentes configurations et les caractéristiques d’un log, nous générons un ensemble de logs aux propriétés diverses. Pour générer les logs, nous utilisons l’outil PTandLogGenera- tor [Jouck and Depaire, 2016], qui permet de générer des process trees aléatoirement, en demandant à l’utilisateur de définir comme paramètres le pourcentage des différents types de noeud-opérateur. Nous générons donc 27 process trees uniques à partir des répartitions présentées dans le Tableau 7.2, avec les types séquence (Séq.), boucle (Bou.), parallélisme (Par.) et choix (Ch.). Comme le temps de calcul nécessaire à l’extraction de LPMs dépend entre autres du nombre d’activités dans le log, il est aussi important de faire varier ce

Chapitre 7

Log (#) Séquence Boucle Parallélisme Choix Log (#) Séquence Boucle Parallélisme Choix

1 0.4 0.0 0.0 0.6 15 0.5 0.1 0.2 0.2 2 0.4 0.0 0.1 0.5 16 0.5 0.2 0.0 0.3 3 0.4 0.0 0.2 0.4 17 0.5 0.2 0.1 0.2 4 0.4 0.1 0.0 0.5 18 0.5 0.2 0.2 0.1 5 0.4 0.1 0.1 0.4 19 0.5 0.0 0.0 0.5 6 0.4 0.1 0.2 0.3 20 0.5 0.0 0.1 0.4 7 0.4 0.2 0.0 0.4 21 0.5 0.0 0.2 0.3 8 0.4 0.2 0.1 0.3 22 0.6 0.1 0.0 0.3 9 0.4 0.2 0.2 0.2 23 0.6 0.1 0.1 0.2 10 0.5 0.0 0.0 0.5 24 0.6 0.1 0.2 0.1 11 0.5 0.0 0.1 0.4 25 0.6 0.2 0.0 0.2 12 0.5 0.0 0.2 0.3 26 0.6 0.2 0.1 0.1 13 0.5 0.1 0.0 0.4 27 0.6 0.2 0.2 0 14 0.5 0.1 0.1 0.3

Tableau 7.2 – Propriétés des différents logs générés aléatoirement.

nombre entre les différents logs générés. Par conséquent, nous choisissons aléatoirement le nombre d’activités utilisées par chaque process tree généré à partir d’une loi triangulaire ; avec un minimum de 10 activités, un maximum de 30 activités et un mode de 20 activités. Nous simulons 100 traces à partir de chacun des process trees pour générer 27 events logs avec des caractéristiques diverses.

Ces 27 logs générés n’ont pas de profit qui pourrait être utilisé pour l’extraction de HU-LPMs. Par conséquent, nous ajoutons artificiellement un attribut cost pour chaque log comme base de calcul du profit d’un HU-LPM. Nous ajoutons cet attribut de deux façons. Tout d’abord, nous ajoutons un profit à chaque event de sorte que les différentes valeurs attribuées soient assez homogènes ; i.e., la mesure dans laquelle un event peut contribuer à un HU-LPM varie peu d’un event à un autre. Pour cela, la valeur attribuée est extraite d’une loi Normale avec une moyenne de 10 et un écart-type de 1. Ensuite, nous ajoutons un profit à chaque event de sorte que les différentes valeurs attribuées soient très dispersées ; i.e., une petite partie des events se partage la majorité du profit total du log. Pour cela, la valeur attribuée est extraite d’une loi de Pareto avec une location de 1 et une forme de 1.

Pour chacun des 27 logs, nous générons un log avec des profits issus d’une distribution Normale et un log avec des profit issus d’une distribution de Pareto. Nous avons donc au total 54 logs générés.

A partir de ces 54 logs, la méthode d’évaluation que nous proposons est la suivante. Pour chaque log, nous effectuons une extraction de HU-LPMs "naïve" ; i.e., sans aucune technique d’élagage. De cette manière, nous aurons accès à la liste complète des meilleurs HU-LPMs et à la taille de l’espace de recherche lorsque tous les LPMs sont explorés. Ensuite, nous effectuons une extraction de HU-LPMs pour chacune des 4 heuristiques et {1,2,3} les valeurs de k, pour un total de 12 configurations. Pour rappel, nous considérons les heuristiques sans mémoire H1 et H2 où H1 exige que l’expansion d’un LPM soit arrêtée

si les k dernières expansions ont généré un LPM avec un profit inférieur ou égal à celui de son parent, et H2 la version assouplie de H1 où un LPM a le droit d’avoir un LPM

identique à celui de son parent ; et les heuristiques avec mémoire H3 et H4où H3 exige que

l’expansion d’un LPM soit arrêtée si les k dernières expansions ont généré un LPM avec un profit inférieur ou égal à celui de son meilleur ancêtre, et H4 la version assouplie de H3 où

un LPM a le droit d’avoir un LPM identique à celui de son meilleur ancêtre. Nous limitons l’expansion des différents LPMs à 4 expansions successives ; i.e., exp_max=4, pour que

Section 7.2

les expérimentations s’effectuent dans un temps raisonnable. Enfin, nous évaluons le gain en termes d’espace de recherche exploré par les différentes configurations. Nous avons volontairement décidé de ne pas évaluer le gain en temps CPU. Certains logs sont très long à analyser, et les temps de calcul nécessaires à l’extraction des HU-LPMs explosent une fois que la consommation en mémoire RAM arrive à saturation. Ces résultats ne sont pas exploitables dans le sens où les ratios calculés ne seraient pas pertinents.

Comme nous l’avons énoncé, l’utilisation d’heuristiques peut empêcher l’extraction de HU-LPM avec un profit élevé, menant à une extraction de moins bonne qualité. Nous appellons une HU-list la collection de HU-LPMs extraits par une technique. Soit Sa = hM1, M2, . . . , Mni la HU-list obtenue par la technique a. Nous appelons HU-list

idéale la HU-list extraite par une extraction naïve sans élagage. La qualité d’une HU-list dépend de la qualité des HU-LPMs qu’elle contient par rapport à la qualité des HU-LPMs contenus par la HU-list idéale. Pour effectuer cette comparaison, nous utilisons le nor- malized Discounted Cumulative Gain (nDCG) [Burges et al., 2005]. Le nDCG est une mesure servant à évaluer un classement, et est une des mesures les plus utilisées dans le domaine de la Recherche d’Information [Tax et al., 2015]. Le Discounted Cumulative Gain (DCG) évalue la qualité d’un classement à partir de la pertinence des éléments du classement de telle sorte qu’il donne plus d’importance aux éléments placés en haut du classement. Nous notons reli la pertinence d’un élément du classement à la position i.

Pour l’évaluation d’une HU-list, nous définissons reli comme le profit du HU-LPM à la

position i. Nous présentons dans l’Équation 7.4 la définition formelle du DCG pour les p premiers éléments d’un classement.

DCG@p = p X i=1 2reli− 1 log2(i + 1) (7.3)

Nous définissons le IDCG comme le DCG obtenu à partir de la HU-list idéale. Nous présentons dans l’Équation 7.4la formalisation du nDCG à partir du DCG de la HU-list extraite par une configuration et le IDCG de la HU-list idéale :

nDCG@p = DCG@p

IDCG@p (7.4)

Nous limitons l’évaluation du nDCG aux p premiers HU-LPMs d’une HU-list, noté nDCG@p. La borne supérieure de p est le nombre de HU-LPMs dans une HU-list obtenue par une extraction avec élagage avec la méthode a ; 0 < p ≤ |Sa|.

7.2.2

Analyse des résultats

Nous présentons dans la Figure7.5a les nDCG@p obtenus pour différentes valeurs de p et pour chaque configuration heuristique. L’axe des abscisses représente la valeur de p utilisée pour calculer le nDCG@p, dont la valeur est représentée sur l’axe des ordonnées. Chaque courbe de ce graphe représente un des 54 logs générés artificiellement ou un des trois logs existants. Nous constatons que les 4 heuristiques obtiennent un nDCG proche de 1 sur la plupart des logs. Les heuristiques H1 et H3 obtiennent les nDCG les

plus bas, surtout avec k=1. Nous présentons dans le Tableau 7.5b, le ratio d’espace de recherche (Ratio Esp. Rech.) exploré ; i.e., quelle part de l’espace de recherche exploré par une extraction "naïve" est explorée par la configuration heuristique pour les 57 logs, en termes de nombre de LPMs générés et évalués.

Chapitre 7

(a)

Ratio Esp. Rech. H k méd. E.A.M H1 1 0.16 0.10 2 0.84 0.08 3 1.00 0.00 H2 1 0.32 0.08 2 0.88 0.07 3 1.00 0.00 H3 1 0.16 0.10 2 0.75 0.16 3 1.00 0.00 H4 1 0.32 0.08 2 0.75 0.16 3 0.99 0.02 (b)

Figure 7.5 – (a) Le nDCG pour chaque configuration heuristique sur les différents logs et (b) la réduction de l’espace de recherche en termes de nombre de LPMs explorés lors des différentes expansions.

Pour ne pas être perturbés par des valeurs dispersées, nous utilisons les mesures de médiane (méd.) et d’écart absolu médian (E.A.M) (plutôt que la moyenne et l’écart- type). Nous constatons que les heuristiques H1 et H3 mènent à la plus grosse réduction de

l’espace de recherche, avec une médiane à 0,16 indiquant que seulement 16% de l’espace de recherche total est exploré par ces heuristiques avec k=1. Cela correspond à une extraction de HU-LPM potentiellement 0,161 =6, 25 fois plus rapide. En utilisant k=3, les heuristiques H1, H2 et H3 explorent l’espace de recherche dans son ensemble, obtenant un nDCG de

1. Pour H4, il n’y a qu’un seul log pour lequel l’espace de recherche n’est pas exploré

entièrement, représenté par la seule courbe avec un nDCG inférieur à 1.

De manière générale, le nDCG pour les différentes configurations et les 57 logs, décroît au fur et à mesure que p augmente. Cela signifie que la majorité des HU-LPMs "ignorés" par l’heuristique sont positionnés dans la partie basse de la HU-list idéale. Par extension, nous pouvons dire que les HU-LPMs les mieux classés sont extraits même en utilisant une heuristique. Les valeurs de l’écart absolu médian que nous présentons dans le Tableau7.5

montrent aussi que la réduction de l’espace de recherche est sensiblement homogène sur les différents logs pour chaque configuration.