Le même résultat qu'Apriori, obtenu beaucoup plus vite. FP-Growth compresse tous les tickets dans un arbre de préfixes, puis y lit directement les combinaisons fréquentes, sans générer et compter des milliers de candidats. C'est lui qu'on utilise quand le catalogue est large ou qu'on veut descendre à un support bas pour voir les produits de niche.
Plutôt que de relire les 4 000 tickets à chaque question, on les range une fois pour toutes dans un classeur à onglets où les tickets qui commencent pareil partagent le même chemin. Ensuite, on lit les réponses dans le classeur.
Premier passage : fréquence de chaque produit. Les produits sous le support minimum sont écartés, les autres triés du plus au moins fréquent.
Second passage : chaque ticket, réordonné, est inséré dans un arbre. Les tickets qui partagent les mêmes produits fréquents partagent les mêmes branches, avec un compteur. L'arbre est en général bien plus compact que les tickets de départ.
Pour chaque produit, on isole les branches qui y mènent et on y cherche récursivement les combinaisons fréquentes. Les règles se calculent ensuite comme avec Apriori.
Le même type de fichier qu'une analyse du panier classique, mais on descend à 1 % de support pour voir les produits peu vendus : couches, lingettes, parmesan. Sur le jeu d'exemple, cela fait près de 800 combinaisons fréquentes.
On ne garde que les règles à une condition, avec une confiance d'au moins 50 % et un lift d'au moins 3. Il en reste 5, dont « couches → lingettes » : 71 % des acheteurs de couches prennent des lingettes, 15 fois plus que la moyenne, sur 67 tickets seulement. Avec un support à 5 %, cette règle n'apparaît pas.
Un lift élevé sur 20 tickets peut être un hasard. On regarde donc le lift et le nombre de tickets concernés ensemble, puis on confirme sur une autre période avant d'agir.
Mêmes réglages qu'Apriori : FP-Growth change la vitesse, pas le résultat. Noms donnés pour R (arules, fim4r) et Python (mlxtend).
Le réglage qui pèse le plus sur le temps de calcul. FP-Growth permet de le descendre à 1 % ou moins, mais le nombre de règles grimpe vite : il faut filtrer ensuite.
Filtres appliqués aux règles une fois les combinaisons trouvées. Combiner une confiance minimale (50 %) et un lift minimal (2 ou 3) élimine l'essentiel du bruit.
Taille maximale des combinaisons. La limiter à 3 ou 4 produits accélère le calcul et évite des règles trop spécifiques pour être utiles.
# Produits de niche : FP-Growth en R
library(arules)
paniers <- read.transactions("tickets_caisse.csv", format = "single", sep = ",",
header = TRUE, cols = c("id_ticket", "produit"))
# FP-Growth via l'interface fim4r d'arules (installe au besoin le package fim4r, hors CRAN)
# Support bas (1 %, soit 40 tickets) pour ne pas rater les produits peu vendus
regles <- fim4r(paniers, method = "fpgrowth", target = "rules",
support = 0.01, confidence = 0.5, zmin = 2)
cat("Règles trouvées :", length(regles), "\n")
# Règles simples (un seul produit en condition) et fortes (lift >= 3)
fortes <- regles[size(lhs(regles)) == 1 & quality(regles)$lift >= 3]
inspect(sort(fortes, by = "lift"))# Produits de niche : FP-Growth en Python
import pandas as pd
from mlxtend.frequent_patterns import fpgrowth, association_rules
tickets = pd.read_csv("tickets_caisse.csv")
paniers = pd.crosstab(tickets["id_ticket"], tickets["produit"]) > 0
# Support bas (1 %, soit 40 tickets) pour ne pas rater les produits peu vendus
frequents = fpgrowth(paniers, min_support=0.01, use_colnames=True)
print(len(frequents), "combinaisons fréquentes")
regles = association_rules(frequents, num_itemsets=len(paniers), metric="lift", min_threshold=3)
# Règles simples (un seul produit en condition) et fiables (confiance >= 50 %)
simples = regles[(regles["antecedents"].apply(len) == 1) & (regles["confidence"] >= 0.5)]
colonnes = ["antecedents", "consequents", "support", "confidence", "lift"]
print(simples.sort_values("lift", ascending=False)[colonnes].round(3).to_string(index=False))Les deux trouvent exactement les mêmes combinaisons fréquentes. Apriori génère et compte des candidats à chaque niveau, en relisant les données. FP-Growth lit les données deux fois, les compresse dans un arbre et en extrait les combinaisons sans candidats, ce qui le rend beaucoup plus rapide sur de gros volumes.
FP signifie Frequent Pattern, motif fréquent. L'arbre FP (FP-tree) est la structure compressée qui stocke les tickets, et « growth » désigne la façon dont les motifs sont agrandis à partir de cet arbre.
Oui, c'est son intérêt. Spark MLlib en propose une version distribuée, qui répartit le calcul sur plusieurs machines. La limite pratique vient du support : très bas, il produit trop de règles pour être exploitables.
Même résultat, plus simple à expliquer, mais lent quand le support baisse ou que le catalogue grandit.
Voir la fiche → l'autre alternative rapideCroise des listes de tickets au lieu de construire un arbre. Souvent aussi rapide, très bien adapté aux combinaisons fréquentes.
Voir la fiche → pour personnaliserRecommande à chaque client selon les clients qui lui ressemblent, au lieu de règles valables pour tous.
Voir la fiche →Dataistudio forme les équipes au machine learning et à l'IA, sur des cas concrets.
Nous utilisons des cookies de mesure d'audience et de suivi publicitaire pour comprendre la fréquentation du site et l'efficacité de nos annonces. Rien n'est déposé sans votre accord. En savoir plus