Ergebnispräsentation Steffen Ciupke Jörg Hipp Vergleich der Ansätze des „Inkrementellen Lernen“ mit den Ideen des „Online Data Mining“ Ergebnispräsentation Steffen Ciupke Jörg Hipp

Inkrementelle Online Assoziationsregeln Zusammenfassende Kritik Agenda Rückblick Online COBWEB Inkrementelle Online Assoziationsregeln Zusammenfassende Kritik

Vorgehen nach der Einführungspräsentation Rückblick Vorgehen nach der Einführungspräsentation Vergleich der Ansätze Inkrementelles Lernen und Online Data Mining und der Anforderungen an die dabei verwendeten Algorithmen Erweiterung des Conceptual Clusterings um Elemente mit Online Behavior Prüfung der Vereinbarkeit von Online Assoziationsregeln mit Methoden des Inkrementellen Lernens Synthese beider Ansätze in Hinblick auf große Datenmengen Ziel

Inkrementelle Online Assoziationsregeln Zusammenfassende Kritik Agenda Rückblick Online COBWEB Inkrementelle Online Assoziationsregeln Zusammenfassende Kritik

Online COBWEB Idee: Parameter (insb. Cuttoff) während der Laufzeit des Algorithmus anpassen Fragen Kann ein bestehender Baum unter Verwendung der Operationen „Merge“ und „Split“ sinnvoll restrukturiert werden? Kann Informationsverlust durch zu geringer Clusteranzahl zu Beginn vermieden werden?

Online COBWEB Durch inkrementelle Eigenschaft des COBWEB-Algorithmus ist Veränderung der Parameter möglich Vorgehen: Mit einem Cuttoff von Null beginnen Nach einer best. Anzahl Instanzen Ergebnis prüfen Bei Overfitting Cuttoff schrittweise erhöhen

Online COBWEB COBWEB Kontroll-Struktur Funktion COBWEB (Objekt, Root) 1.) Update Counts in der Wuzel 2.) Finde den Sohn der Wurzel mit bester CU und mache eines der Folgenden a) Erschaffung einer neuen Klasse b) Mergen?  COBWEB(Objekt, Merged node) c) Splitten?  COBWEB(Objekt, Root) d) Keines der Obigen  COBWEB(Objekt, Best Host)

Merge Operation ohne Cuttoff Ca: „best fitting host“; Cb: „runner up“ Online COBWEB Merge Operation ohne Cuttoff Ca: „best fitting host“; Cb: „runner up“ CU(C1,....Ca+b,...Ck) > CU(C1,...,Ca,...,Cb,...Ck) Einfügen der neuen Instanz K K C A B C A B D

Merge Operation mit Cuttoff Entscheidung (Merge) analog Online COBWEB Merge Operation mit Cuttoff Entscheidung (Merge) analog CU(Situation1) – CU(Situation 2) < Cuttoff  Situation 2 Einfügen der neuen Instanz unter Berücksichtigung des Cuttoff Situation 1 K Situation 2 K C A B C A B

A: #Attibute V: durchschnittliche #Attributwerte Online COBWEB Performance (COBWEB) Kosten des Einfügens einer Instanz: O(B2 logB n*AV) A: #Attibute V: durchschnittliche #Attributwerte COBWEB ist fähig Schlussfolgerungen zu treffen bzw. besitzt die Eigenschaft Regelmäßigkeiten zu entdecken COBWEB ist ein inkrementelles, ökonomisches und robustes Conceptual Clustering System

Zusammenfassende Kritik Online COBWEB Zusammenfassende Kritik Keine Literatur zu diesem (trivialen) Ansatz zu finden, obwohl zu COBWEB diverse Erweiterungen existieren Praktische Test mit WEKA-COBWEB lassen auf einen relativ geringen Einfluss der Parameter schließen Daten besitzen keine „Clusterstruktur“  „Overfitting“ trotz scharfen Cuttoffs Hauptproblem inkrementeller Algorithmen (Reihenfolge der Instanzen) wird von diesem Ansatz keineswegs gelöst

Inkrementelle Online Assoziationsregeln Zusammenfassende Kritik Agenda Rückblick Online COBWEB Inkrementelle Online Assoziationsregeln Zusammenfassende Kritik Rückblick: wesentlicherAnsatzOnline: Tradeoff... ...laufzeitoptimierter Abarbeitung Einzelquery  ...Performancereduktion durch Onlineeigenschaften (ermöglicht Nutzer jedoch interaktives Einbringen von Intuition und externem Wissen )

Inkrementelle Online Assoziationsregeln erforderliche Leistungen des Verfahrens inkrementelle Eigenschaft: ... Wissen aus Ausgangsdaten DB (repräsentiert durch Assoziationsregeln) wird um neue Transaktion in db erweitert (ohne Zugriff auf DB) Möglichkeiten der Inkrementierung: 1. Pruning von bestehenden großen Itemsets/ Assoziationsregeln 2. Aktualisierung von Support und Konfidenz 3. Hinzufügen neuer Assoziationsregeln Hinweis auch auf Beibehaltung der Onlineeigenschaften, die auch wieder (v.a. ?) für Fall 3 problematisch (lösbar evtl. nur durch mathematische Abschätzung von supportSequence) sind einfacher (jedoch teurer) Lösungsansatz: Speichern von allen großen Itemsets bzgl. eines sehr geringen minSupports ( evtl Verbesserung wenn dieser auf der ersten abzuarbeitenden DB interaktiv festgelegt wird) Problemfall Transaktionsdaten DB nicht mehr vorhanden

Inkrementelle Online Assoziationsregeln theoretische Ansätze für „Inkrementierung“ von CARMA Hinzunahme neuer Assoziationsregeln: ...einfache Abschätzung untere und obere Schranke Support des Itemsets (T-1) + t(v) lim Support(v) = t(v) N + n lim Support(v) = Steffen Ciupke: evtl. Abschätzung (v.a. maxSupport) angeben N + n Abschätzung der oberen Grenze: in Abhängigkeit von supportSequence, (da diese Assoziationsregel aus DB NICHT generiert wurde) und in Abhängigkeit von Gesamtzahl der Transaktionen in DB T(v)  minSupport(DB)•N T(v) : # Transaktionen mit Itemset v in DB t : # Transaktionen mit Itemset v in db N : # Transaktionen gesamt DB n : # Transaktionen gesamt db

Inkrementelle Online Assoziationsregeln theoretische Ansätze für „Inkrementierung“ von CARMA Hinzunahme neuer Assoziationsregeln: Fallunterscheidung: 1. lim Support(v) > supportSequence(t):  neue Assoziationsregel 2. lim Support(v) < supportSequence(t):  Regel bleibt unberücksichtigt 3. lim Support(v) < supportSequence(t) < lim Support(v) Steffen Ciupke: evtl. Abschätzung (v.a. maxSupport) angeben Abschätzung der oberen Grenze: in Abhängigkeit von supportSequence, (da diese Assoziationsregel aus DB NICHT generiert wurde) und in Abhängigkeit von Gesamtzahl der Transaktionen in DB zur Überleitung unterschiedliche Indizierungsansätze erläutern: 1. Häufigkeitszählung aller Items bzw. Untermengen 2. naheliegender,einfacher Ansatz: (läßt sich auch nutzerseitig duch generell niedriger gewählten Support ausführen) während Abarbeitung DB, Speicherung von Itemsets mit reduziertem Support (d.h unischtbaren Index auf Itemsets mit geringfügig niedrigerem Support) 3. Speicherung von sinnvollen (Unter)mengen bzgl. relevanter (Itemsets deren zukünftige Aufnahme wahrscheinlich) Kandidaten Problemfall Notwendigkeit Index auf DB zu erstellen

Inkrementelle Online Assoziationsregeln Lösungsansatz existierendes, effizientes Verfahren Negative Border Algorithmus (S. Thomas et al.) ermöglicht inkrementelle Anwendung von Assoziationsregeln: best case, average case: ohne Zugriff auf DB worst case: maximal einmaliger Scan DB bei stark reduzierter Anzahl zu überprüfender Transaktionen Algorithmus läßt sich für herkömmliche Assoziationsregelverfahren anwenden (z.B. APRIORI) große Performancevorteile (Faktor 20 ggü. APRIORI bereits bei 100000 Transaktionen (v.a. bei mittlerem Support)) Hinweis: zweitbestes Verfahren (FUP) arbeitet im worst case mit „maxKardinalität großes Itemset“-Scans auf DB ! zusätzlich ermöglicht Verfahren auch unter Verwendung der bestehenden Funktionen das Löschen von Transaktionen, d.h. es wird aus einem DB und db- ein DB- erzeugt! Steffen Ciupke: wichtig: Restriktion bzgl konstanter MinSupport-Grenzwerte ! Erweiterung von CARMA um Negative Border

Inkrementelle Online Assoziationsregeln Ansatzpunkte in CARMA Menge der Kandidaten für Menge der großen Itemsets Itemset v wird in Menge der großen Itemsets (V) aufgenommen wenn alle Teilmengen von v bereits Element V und es ausreichend großen maxSupport besitzt während des Scans auf DB werden nur „nichtgeprunte“ Kandidaten für Assoziationsregeln verwandt für Indizierung (Negative Border) werden diese jedoch gespeichert, da bei vermehrtem Auftreten in db eine Überschreiten der Supportschranke wahrscheinlich (alle Teilmengen von Kandidaten in Negative Border besitzen ja bereits einen ausreichenden Support) es wird jeweils der Support count(v) von allen Kandidaten (damit von NBd(L) vereinigt L) gespeichert ! -> notwendig für alle folgenden Supportberechnungen Pruning der Kandiaten mit zu geringem Support

Inkrementelle Online Assoziationsregeln Funktion Negative Border äquivalent: Generierung Kandidaten Phase I CARMA Negative Border ist Index über maximale Itemsets  L (NBd(Lk) = Ck - Lk ) apriori-gen: Join&Prune-Phase d. Apriori-Algorithmus um Kandidaten zu generieren, hier identisch zu ersetzen durch Kandidatengenerierung in CARMA NBd(L) : Negative Border von L Li : Menge der großen Itemsets (Kardinalität i: Anzahl Items) Ck : Menge der Kandiaten (Kardinalität k: Anzahl Items)

Inkrementelle Online Assoziationsregeln Umsetzung inkrementeller Ablauf Update des count(s) Ausgangs- Itemsets aus DB Ermittlung der Menge der großen Itemsets mit Standard- CARMA Assoziations-regeln aus DB werden beibehalten od. geprunt mathemat. Abschätzung support-Sequence auf DB notwendig Generierung von neuen Assoziations-regeln Funktionen arbeiten ohne Scan auf DB

Inkrementelle Online Assoziationsregeln Umsetzung inkrementeller Ablauf • • • Gesamtmenge der vorgehaltenen Itemsets ist gewachsen Generierung der Menge der neuen großen Itemsets und Negative Border (Schrittweite: jeweils um 1 vergrößerte Kardinalität der Itemsets) wichtig ist dabei, daß es wahrscheinlich ist, daß neue Assoziationsregeln generiert werden , ohne daß Rescan notwendig (best und average case) S wächst mehr als einmal, wenn Kardinalität eines großen Itemsets aus db größer um mehr als 1 größer als Kardinalität bisheriger großer Itemsets Zusätzliche Einschränkung der Rescan-Menge an Itemsets um grobe Abschätzung obere und untere Schranke Support (Folie 15) ! Rescan auch notwendig, wenn minSupport(db) unter minSupport(DB) gesenkt wurde -> vorherrschende Restriktion : niedriger Start-minSupport, der dann schnell verschärft werden kann ! (s.a. 1. Online-Folie(Folie 13) „vituellen“ MinSupport während Ausgangsdatensatz festlegen) Rescan DB ermittelt Support  Itemsets s {s  LDB+  NBd(LDB+ ) | sLdb  NBd(LDB+ )  sLDB  NBd(LDB )}

Inkrementelle Online Assoziationsregeln Eigenschaftsänderung durch Kombination inkrementeller & Online Ansatz maximal einmaliger Scan der Datenmenge nur für konstanten MinSupport möglich für CARMA-Verfahren mit exakten Ergebnissen für Support und Konfidenz maximal 2 Scans über Update-Datensatz (db) und 1 Scan über ursprüngliche Datensätze (DB) notwendig dabei jedoch Reduzierung der Komplexität/Kosten Einschränkung der auf Support zu überprüfenden Itemsets Forwardpruning nutzt bei erstem Durchlauf gewonnene Erkenntnisse (vorzeitiger Abbruch des Prunings möglich)

Zusammenfassende Kritik: Online Ansatz Hellerstein fruchtbarer Denkanstoß... ...Berücksichtigung Tradeoff: + interaktive Einbindung Intuition/externes Wissen Laufzeitoptimierung Effizienz Online Ansatz auf sehr großen Datenmengen (Telekomdaten, generell Terrabyteberreich) durch strukturelle Eigenschaften (v.a. ABC-Tool , Basis-Verfahren „Online Reordering“) fragwürdig - kein Widerleg durch Performancedaten ! offensichtlich Probleme in der Umsetzung für weitere Data Mining Anwendungen - bisher nur für Assoziationsregeln verwirklicht -

Zusammenfassende Kritik Prinzipielle Vereinbarkeit der beiden Ansätze? Jedes inkrementelle Verfahren besitzt per Definition ANYTIME- Verhalten Vorgehen bei Erweiterung von existierenden inkrementellen Data Mining Methoden mit..: ...Problem: Repräsentation der Wissensbasis ...Shift der Kostenorientierung für große DB Rechenzeitminimierung DB-Zugriffsminimierung

Fragen

Merge Operation mit Cuttoff Online COBWEB Merge Operation mit Cuttoff Einfügen der neuen Instanz unter Berücksichtigung des Cuttoff K K C A B D C A B D

Inkrementelle Online Association Rules Beispielhafter Ablauf Online Associatione Rules ( CARMA )

Inkrementelle Online Association Rules CARMA 1. Scan : firstTrans(): Transaktion zu der Itemset in Menge der potentiell großen Itemsets hinzugenommen wird count(): Anzahl des Vorkommen des Itemset nach firstTrans maxMissed:() obere Schranke für Vorkommen vor firstTrans (in Abh. von bearbeiteter Datenmenge und supportSequence) supportSequence: dynamische Speicherung der nutzerspezifizierten Supportgrenzwerte Ermöglicht Angabe einer oberen und unteren Schranke für Support

Backup Untere Schranke für Abschätzung minSupport in Abhängigkeit von supportSequence  minSupport(LDB) = avgn (n) + c - 1 n Durch CARMA generierte LDB (Basis supportSequence ) ist Menge der großen Itemsets bzgl. minSupport Erweiterung: CARMA (i) statt CARMA (i) gewährleistet minSupport(LDB) = n n = avgn (n) + c - 1 n c: Kardinalität des größten Itemsets in LDB n: # Transaktionen in LDB