Чи все ще FPGrowth вважається "найсучаснішим" при частому видобутку шаблонів?

Наскільки я знаю, що розробляються алгоритми для вирішення проблеми частого видобутку шаблонів (FPM), шлях удосконалення має деякі основні контрольні точки. По-перше, алгоритм Апріорі був запропонований в 1993 році Agrawal et al. разом із формалізацією проблеми. Алгоритм зміг зняти деякі набори з 2^n - 1наборів (powerset), використовуючи решітку для підтримки даних. Недоліком підходу була необхідність перечитувати базу даних для обчислення частоти кожного розширеного набору.

Пізніше, у 1997 році, Закі та ін. запропонував алгоритм Eclat , який вставив отриману частоту кожного набору всередині решітки. Це було зроблено шляхом додавання на кожному вузлі решітки набору транзакційних ідентифікаторів, які мали елементи від кореня до згаданого вузла. Основний внесок полягає в тому, що не потрібно перечитувати весь набір даних, щоб знати частоту кожного набору, але пам'ять, необхідна для збереження такої структури даних, може перевищувати розмір самого набору даних.

У 2000 році Хан та ін. запропонував алгоритм з назвою FPGrowth , а також структуру даних префіксного дерева з назвою FPTree. Алгоритм міг забезпечити значне стиснення даних, одночасно надаючи, що отримуватимуться лише часті набори елементів (без генерації набору елементів). Це було зроблено головним чином шляхом сортування елементів кожної транзакції у порядку зменшення, так що найчастіші елементи - це найменші повтори в структурі даних дерева. Оскільки частота знижується лише під час глибокого обходу дерева, алгоритм може викреслити нечасті набори елементів.

Редагувати :

Наскільки я знаю, це може вважатися найсучаснішим алгоритмом, але я хотів би знати про інші запропоновані рішення. Які ще алгоритми FPM вважаються "найсучаснішими"? У чому полягає інтуїція / головний внесок таких алгоритмів?

Чи все-таки алгоритм FPGrowth вважається "найсучаснішим" при частому розробці шаблонів? Якщо ні, то який алгоритм може ефективніше витягувати часті набори елементів із великих наборів даних?

Найсучасніший: як застосовується на практиці або працює теоретично?

APRIORI використовується скрізь, за винятком розробки нових частих алгоритмів набору елементів. Це легко здійснити і легко використовувати в дуже різних областях. Ви знайдете сотні реалізацій APRIORI різної якості. І легко насправді помилитися з АПРІОРИ.

Розвиток ПП значно складніше здійснити, але також набагато цікавіше. Отже, з академічної точки зору, всі намагаються покращити ріст FP - зростання роботи на основі прийнятих APRIORI на сьогоднішній день буде дуже важким.

Якщо у вас є хороша реалізація, кожен алгоритм має це добре, і на мою думку це погані ситуації. Для гарної реалізації APRIORI потрібно буде лише сканувати базу даних k раз, щоб знайти всі часті набори елементів довжиною k . Зокрема, якщо ваші дані вписуються в основну пам'ять, це дешево. Що може вбити APRIORI - це занадто багато частих наборів 2 предметів (зокрема, коли ви не використовуєте Trie та подібні методи прискорення тощо). Найкраще він працює у великих даних із низькою кількістю частих наборів елементів.

Еклат працює над колонами; але читати його потрібно набагато частіше. Існує деяка робота над дифсетами, щоб зменшити цю роботу. Якщо ваші дані не входять в основну пам'ять, Eclat страждає, ймовірно, більше, ніж Apriori. Поглибивши спочатку глибину, ви також зможете повернути перший цікавий результат набагато раніше, ніж Apriori, і ви можете використовувати ці результати для коригування параметрів; тому вам потрібно менше ітерацій, щоб знайти хороші параметри. Але задумом вона не може використовувати обрізку так акуратно, як це робив Апріорі.

FPGrowth стискає набір даних у дерево. Це найкраще працює, коли у вас є багато повторюваних записів. Ви, ймовірно, можете отримати ще й певні вигоди для Apriori та Eclat, якщо зможете зібрати свої дані та об'єднати дублікати у зважені вектори. FPGrowth робить це на екстремальному рівні. Недолік полягає в тому, що реалізація набагато складніше; і коли це дерево більше не вписується в пам’ять, воно стає безладним.

Що стосується результатів та орієнтирів - не довіряйте їм. Є так багато речей, які можна неправильно реалізувати. Спробуйте 10 різних реалізацій, і ви отримаєте 10 дуже різних результатів роботи. Зокрема, для APRIORI, у мене складається враження, що більшість реалізацій порушені в сенсі відсутності деяких основних внесків APRIORI ... і тих, які мають ці частини правильно, якість оптимізацій значно варіюється.

Насправді навіть є документи про те, як ефективно реалізувати ці алгоритми:

Ефективне впровадження Apriori та Eclat.
Крістіан Боргельт
воркшоп з впровадження гірничих виробів, що часто використовуються (FIMI 2003, Мельбурн, штат Флорида, США).

Ви також можете прочитати ці опитування в цьому домені:

• Ґетели, Барт. "Опитування щодо частого видобутку шаблону". Ун-т. Гельсінкі (2003).

• Ференц Бодон, опитування щодо видобутку частих предметів, Технічний звіт, Будапештський технологічний та економічний університет, 2006 р.,

• Часте Комплект Mining
  Christian Borgelt
  Wiley міждисциплінарні Огляди: інтелектуальний аналіз даних і виявлення знань 2 (6): 437-456. 2012 рік

Більшість останніх підходів із частою схемою, які я бачив у літературі, ґрунтуються на оптимізації FPGrowth. Треба визнати, я не бачив багатьох подій в літературі FPM протягом багатьох років.

Ця вікікнига висвітлює багато варіантів FPGrowth, які існують там.