Volltext - an der Universität Duisburg

Transcrição

KI-Methoden zur Email-Archivierung
Technologische Studie zum „Inbox-Szenario“
Ingo Frommholz und Norbert Fuhr
8. November 2006
UNIVERSITÄT
D U I S B U R G
E S S E N
Fakultät für Ingenieurwissenschaften
Universität Duisburg-Essen
47048 Duisburg
Zusammenfassung
Thema dieser Studie ist das so genannte „Inbox-Szenario“, bei dem es um die Bearbeitung
und Archivierung eingehender Emails geht. Um die in der Regel große Menge solcher
Emails zu bearbeiten, bedarf es der Unterstützung eines persönlichen Email-Assistenten.
Wir beschreiben mögliche Use Cases im Inbox-Szenario und konzentrieren uns dann auf
die Kategorisierung hinsichtlich verschiedener Facetten und der Extraktion von relevanten Informationen aus Emails. Als Beispielkollektion dient uns dabei der vor einigen
Jahren freigegebene Enron-Korpus, der insgesamt aus 619.446 Nachrichten von 158 Benutzern enthält und somit sehr repräsentativ für das Benutzerverhalten bei der EmailKategorisierung ist.
Die Email-Klassifikation unterscheidet sich von der Textklassifikation, da wir es hier
mit sehr heterogenen Kriterien beim Anlegen eines Kategorienschemas zu tun haben, und
das Ablegen von Emails in diese Struktur ein äußerst dynamischer Prozess ist. Das Folderschema sowie deren Inhalt sind ständigen Veränderungen unterzogen, die ein Kategorisierungsverfahren zu berücksichtigen im Stande sein sollte. Folgende Schlüsse können
dabei aus der Literatur gezogen werden:
• Support Vector Machines erzielen, wie schon in der Textklassifikation, die zumeist
besten Kategorisierungsergebnisse;
• andere Klassifizierer sind interessant, wenn es z.B. um die Effizienz der Kategorisierung geht oder wenn der Klassifizierer im Stande sein soll, inkrementell zu arbeiten;
• regelbasierte Ansätze sind eine interessante Alternative zu den anderen Verfahren,
da sich hier die Kategorisierungsentscheidung besser erklären lässt und Regeln auch
manuell verändert bzw. neu angelegt werden können. Der Benutzer selbst bekommt
also mehr Kontrolle über das Geschehen.
Wir betrachten neben den Machine-Learning-Verfahren, für die uns die Ergebnisse von
Experimenten aus der Email-Domäne vorliegen, auch andere Verfahren, die bisher hauptsächlich zur Textklassifikation eingesetzt wurden:
• Mittel probabilistischer, entscheidungsorientierter Ansätze ist es möglich, verschiedene Term- und Dokumenteigenschaften (z.B., ob ein Term im Betreff einer Email
auftaucht) zu berücksichtigen. Regressionsfunktionen können nun eine Indexierungsfunktion berechnen, mit der Terme sowohl der vorhandenen Kategorien als
auch neu einzusortierender Emails gewichtet werden können.
• Unterschiedliche Kategorisierungsstrategien wie k-Nearest-Neighbour oder der
Megadokumenten-Ansatz können auf dermaßen indexierte Dokumente bzw. Folder angewendet werden.
4
• Ein Ranking absteigend nach der berechneten Wahrscheinlichkeit P(d → C ), dass
ein Dokument eine Kategorie impliziert, kann potentiell zu minimalem Benutzeraufwand führen.
• Dr. Holthausen-Netzwerke stellen eine weitere Möglichkeit der EmailKategorisierung dar, wobei diese mit den entscheidungsorientierten Ansätzen
kombiniert werden können.
• Verfahren zum Lernen probabilistischer Regeln verknüpfen die Vorteile der regelbasierten Verfahren mit Methoden der Wahrscheinlichkeitstheorie.
Neben der Email-Klassifikation stellt die Informationsextraktion einen weiteren
Schwerpunkt dieser Studie dar. Bei der Informationsextraktion geht es darum, zu vorgegebenen Templates oder Frames geeignete Instanzen aus Emails zu extrahieren. Wir zeigen, dass sowohl die Bearbeitung als auch die Archivierung von Emails von der Informationsextraktion profitieren kann. Ein beispielhaftes Szenario ist das eines Kontaktcenters,
bei dem mittels Informationsextraktion Emails automatisch beantwortet werden, indem
die relevante Information aus eingehenden Emails extrahiert und mit vorherigen Anwendungsfällen verglichen wird. Wir stellen danach einige Informationsextraktionsverfahren
vor. Es bestätigt sich, dass die Informationsextraktion aus Texten eine sehr große Herausforderung darstellt.
• Einfache Verfahren wie die Named Entity Recognition liefern gute Ergebnisse, die
wir ebenso bekommen, wenn sehr strukturierte Daten vorliegen.
• Je weniger Struktur die Texte haben, desto schlechter ist die Informationsextraktion.
• Verfahren, die die Informationsextraktion mit Hilfe einer Kategorisierung von Textfragmenten (Einteilung in „enthält eine gesuchte Instanz“ oder „enthält keine gesuchte Instanz“) durchführen, liefern recht brauchbare Resultate, wobei wir noch
davon entfernt sind, alle Informationen 100% genau zu extrahieren.
• In Anwendungsfällen wie dem Indexieren von Emails gegen eine Ontologie oder
dem Bereitstellen von Hintergrundinformationen ist ein perfektes Extraktionsergebnis gar nicht erforderlich, sondern wir können hier mit den auftretenden Unsicherheiten umgehen.
Den Abschluss der Studie bildet ein Ausblick, in dem wir das Email-Szenario als Teil
eines größeres Workflows sehen wollen. Emails können hier zweierlei Rolle spielen:
1. Eine eingehende Email kann bestimmten Problemklassen zur Weiterverarbeitung
vorgelegt werden. Beispielsweise könnte eine eingehende Rechnung als solche erkannt und aus ihr die relevanten Daten extrahiert werden, die dann gemäß des vorliegenden Workflows weiter bearbeitet werden.
2. Das Email-Archiv kann so genannten wissensintensiven Aufgaben als wertvolle Informationsquelle dienen. Solche wissensintensiven Aufgaben produzieren in der
kiib
5
Regel unterschiedliche Informationsbedürfnisse, die mit verschiedenen Methoden
aus dem Information Retrieval (wie z.B. der Suche nach relevanten Emails oder auch
nach Experten) gesättigt werden können.
Inhaltsverzeichnis
1 Einleitung
8
2 Anwendungsfälle und Problemstellungen im Inbox-Szenario
2.1 Das Inbox-Szenario . . . . . . . . . . . . . . . . . . . . . . . .
2.1.1 Beschreibung . . . . . . . . . . . . . . . . . . . . . . .
2.1.2 Use Cases . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.3 Erweitertes Szenario: Ontologien und Annotationen
2.2 Problemstellung . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.1 Information Retrieval . . . . . . . . . . . . . . . . . .
2.2.2 Datenbanken . . . . . . . . . . . . . . . . . . . . . . .
2.2.3 Summarization . . . . . . . . . . . . . . . . . . . . . .
2.2.4 Informationsextraktion . . . . . . . . . . . . . . . . .
2.2.5 Kategorisierung . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
10
10
10
10
13
15
15
16
16
16
17
3 Analyse der Datenbasis
18
3.1 Der Enron-Korpus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.2 Multifacettenklassifikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4 Email-Kategorisierung
4.1 Bisherige Erfahrungen . . . . . . . . . . . . . . . . . . . . . . . . . .
4.1.1 Evaluierungsmaße . . . . . . . . . . . . . . . . . . . . . . . .
4.1.2 Verfahren aus der Textklassifikation . . . . . . . . . . . . . .
4.1.3 Regelbasierte Ansätze . . . . . . . . . . . . . . . . . . . . . .
4.1.4 Zusammenfassung der bisherigen Klassifikationsverfahren
4.2 Mögliche neue Ansätze . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2.1 Probabilistische, entscheidungsorientierte Verfahren . . . .
4.2.2 Dr. Holthausen-Netzwerke . . . . . . . . . . . . . . . . . . .
4.2.3 Lernen probabilistischer Regeln . . . . . . . . . . . . . . . .
4.2.4 Andere Verfahren . . . . . . . . . . . . . . . . . . . . . . . . .
5 Informationsextraktion
5.1 Überblick . . . . . . . . . . . . . . . .
5.2 Beispiel: Beantworten von Emails . .
5.3 Ansätze zur Informationsextraktion
5.3.1 WHISK . . . . . . . . . . . . .
5.3.2 SRV / Kategorisierung . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
23
23
24
25
33
34
35
35
44
45
51
.
.
.
.
.
52
52
54
55
56
58
Inhaltsverzeichnis
5.4
5.5
7
5.3.3 ELIE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Beurteilung der Verfahren zur Informationsextraktion . . . . . . . . . . . . .
Anwendung der Informationsextraktion im Inbox-Szenario . . . . . . . . .
62
63
64
6 Knowledge Intensive Tasks
65
6.1 Knowledge Intensive Tasks in Workflows . . . . . . . . . . . . . . . . . . . . 65
6.2 Emails und Knowledge Intensive Tasks . . . . . . . . . . . . . . . . . . . . . 66
7 Zusammenfassung und Ausblick
68
1 Einleitung
Heutzutage sind Emails in der betrieblichen sowie privaten Kommunikation nicht mehr
wegzudenken. Viele Benutzer erhalten täglich dutzende Emails, die auf eine passende
Bearbeitung warten. Eine maschinelle Unterstützung bei der Verwaltung solcher EmailKollektionen kann dabei von großem Wert sein. So sorgen Spam-Erkennungsprogramme
dafür, dass viel unerwünschte Email (so genannter Spam) erst gar nicht dem Benutzer präsentiert wird. Allerdings erfordert auch die Bearbeitung und Archivierung der erwünschten Email einen hohen kognitiven Aufwand vom Benutzer. Abhilfe kann hier mit der Bereitstellung eines persönlichen Email-Assistenten geschaffen werden, der den Benutzer bei
den anfallenden Aufgaben im Zusammenhang mit der Email-Bearbeitung und Archivierung unterstützt. Dieser operiert auf der zu Grunde liegenden Email-Kollektion, wobei
die Reichweite dieses Begriffes in sechs verschiedene Regionen eingeteilt werden kann,
wie Tabelle 1.1 zeigt.
Wir unterscheiden hier zunächst zwischen den gegenwärtigen und archivierten Emails.
Erstere sind neu ankommende Mails, die einer Bearbeitung bedürfen. Letztere sind alte
Emails, die in der Regel bereits bearbeitet wurden, aber eine wichtige Quelle für Hintergrundinformationen zur Bearbeitung neuerer Emails darstellen. Eine andere Dimension
teilt die Email-Kollektion in den individuellen, organisatorischen und sozialen Bereich ein. Bei
der individuellen Kollektion handelt es sich um die persönliche Mailbox des Benutzers.
Im organisatorischen Bereich befinden sich die Emails, die einer gesamten Organisation
zugänglich sind. Der soziale Bereich umfasst öffentliche Mailinglisten und Archive. Wir
gehen im Folgenden davon aus, dass alle gegenwärtigen Emails aus den Regionen A-C
in der Inbox des Benutzers befinden und dort auf weitere Bearbeitung warten. Die zu den
Regionen D-F gehörenden Emails liegen in der persönlichen Mailbox des Benutzers. Die
Individuell
Region A:
Individuelle
Gegenwärtig Inbox des Benutzers
Region D:
Individuelle
Archiviert
Mailbox
des
Benutzers
Organisatorisch
Region B:
Email innerhalb
einer Organisation
Region E:
Email-Archiv der
Organisation
Sozial
Region C:
Öffentliche Diskussion
Region F:
Öffentliche
Email-Archive
Tabelle 1.1: Interaktionstypen mit Email-Kollektionen (Perer u. a. 2005)
9
Inbox ist dabei als Teil der Mailbox anzusehen.
Das Inbox-Szenario umfasst die Regionen A-C. Eine neue Email wird empfangen und in
den Eingangskorb (Inbox) der Mailzugangs des Benutzers gelegt. Von dort aus soll nun
der Benutzer bei der Weiterbearbeitung der Email unterstützt werden, sei es, indem das
System ihm relevante Kontextinformationen zum Inhalt der Email berichtet, oder aber
hilft, die Email und die möglichen Reaktionen darauf korrekt einzuordnen und zu archivieren. Dies umfasst insbesondere die Klassifikation von Emails, d.h. die Einsortierung in
bestimmte Kategorien nach bestimmten Facetten, sowie die Informations- und Attributextraktion. Wir werden sehen, dass auch bereits archivierte Emails, also die Bereich D bis F,
für uns relevant sind. Das Email-Archiv besteht dabei aus einer (hierarchischen) Ordneroder Folderstruktur, die vom jeweiligen Benutzer angelegt wurde.
Im weiteren Verlauf dieser Studie werden wir zunächst einmal konkrete Problemstellungen ansprechen, bevor wir eine repräsentative Datenbasis, den Enron-Korpus, in Kapitel 3 analysieren. In den darauf folgenden Kapiteln 4 und 5 werden Methoden zur Klassifikation und Attributextraktion besprochen. Da das Inbox-Szenario häufig Ausgangspunkt für weitere Aktionen ist, werden wir die so genannten Knowledge Intensive Tasks
besprechen, die das Inbox-Szenario im größeren Workflow-Kontext sehen. Dies geschieht
in Kap. 6. Kapitel 7 schließlich fasst die Ergebnisse zusammen und gibt einen Ausblick
auf zukünftige Aktivitäten.
Diese Studie wurde von der EUREGIO im Rahmen eines von der Gemeinschaftsinitiative INTERREG IIIA unterstützten Projektes im Bereich „Künstliche Intelligenz im Betrieb“
(kiib) gefördert und von der d.velop AG in Gescher in Auftrag gegeben.
2 Anwendungsfälle und Problemstellungen
im Inbox-Szenario
2.1 Das Inbox-Szenario
Es soll nun zunächst mal auf das zu Grunde liegende Szenario eingegangen werden. Dieser wird zuerst informell beschrieben; anschließend werden konkrete Anwendungsfälle
diskutiert.
2.1.1 Beschreibung
Ausgangspunkt unserer Problemstellung ist das so genannte Inbox-Szenario. In diesem
Szenario gehen wir davon aus, dass der Benutzer einen Email-Zugang hat und neue Email
in dem speziellen Mailordner „Inbox“ landet, wovon diese Mail dann weiter verarbeitet
wird. Eine Email kann dabei in der Regel eine Fülle von möglichen Aktionen nach sich
ziehen; auch können sich nach einer Zeit eine Menge Emails in der Inbox ansammeln, so
dass der Benutzer vor dem Problem steht, aus der Fülle Emails die relevanten und wichtigen auszusuchen. Es geht also darum, den Benutzer beim Verwalten der einkommenden
Emails zu unterstützen und ggf. bestimmte Aktionen im Zusammenhang mit einer Email
anzustoßen und zu unterstützen.
Benutzer verwalten Emails i.d.R. indem sie eine, typischerweise hierarchische, Ordnerstruktur anlegen. Einkommenden Emails können zur Archivierung in geeignete Ordner
verschoben werden und sind durch Browsing dieser Ordnerstruktur relativ einfach wieder aufzufinden. Idealerweise sollte ein System dabei Ordner automatisch vorschlagen,
in denen sich eine Email geeignet einsortieren lässt. Neben dem Verwalten von Emails
kann sollen diese natürlich auch bearbeitet werden. In diesem Sinne kann man das InboxSzenario als ein Element eines größeren Workflows ansehen – die Ankunft einer Email
stößt i.d.R. weitere Aktionen an. Welche Aktion durchzuführen ist, hängt dabei von Art,
Metadaten und Inhalt der Email ab. Ist es z.B. eine unerwünschte Email, so ist die einzige Aktion, diese ungelesen zu löschen. Andere Emails brauchen u.U. nur zur Kenntnis
genommen werden. Emails die von bestimmten Personen (wie Vorgesetzten) kommen,
sollten evtl. bevorzugt behandelt werden.
2.1.2 Use Cases
Abbildung 2.1 zeigt mögliche Anwendungsfälle des Inbox-Szenarios (die allerdings nicht
weiter spezifiziert werden sollen). Hat der Benutzer seinen Inbox-Ordner geöffnet, sieht
2.1 DAS INBOX-SZENARIO
11
Known-Item-Suche
Recherchieren
Diskussionssuche
0..*
Email-Suche
Suchagent
Relevante Emails zeigen
Personensuche
Selektieren
Kontext zeigen
0..*
<<extend>>
<<extend>>
<<extend>>
Öffnen
Kontakt- und Termininfo anzeigen
<<extend>>
Benutzer
<<extend>>
Datenbankagent
Zusammenfassen
<<extend>>
0..*
Extrahieren
Manuell kategorisieren
Extraktionsagent
<<extend>>
Autom. Priorisieren
Kategorisieren
Automatisch vorkategorisieren
Kategorisierungsagent
Priorisieren
0..*
Benachrichtigungsagent
Benachrichtigen
Abbildung 2.1: Use Cases des Inbox-Szenarios
er alle sich dort befindlichen Emails. Hier hat er nun mehrere Aktionsmöglichkeiten. Der
Benutzer kann zunächst mal über die Menge der Emails recherchieren1 . Mögliche Recherchen beinhalten, neben anderen, die Known-Item-Suche, bei der der Benutzer ein schon
einmal gesehenes Dokument wiederfinden möchte. Die Email-Suche dient dem Wiederauffinden von bereits archivierten Emails; der Benutzer kann dabei eine Anfrage formulieren und das System erstellt eine Rangliste von Emails, die zu dieser Anfrage passen. Die
Diskussionssuche ist ähnlich der Email-Suche, allerdings sollen hier relevante Beiträge aus
Diskussionen gefunden, etwa um eine Entscheidungsgrundlage zu bekommen. Dementsprechend kann versucht werden, gezielt nach Pro- oder Kontra-Argumenten zu einem
Thema zu suchen, und es wird i.d.R. die Thread-Struktur als struktureller Kontext aus1 Streng
genommen beziehen sich die Recherchemöglichkeiten nicht auf die Inbox allein, sondern auf den
gesamten Mailkorpus des Benutzers
12
2 ANWENDUNGSFÄLLE UND PROBLEMSTELLUNGEN IM INBOX-SZENARIO
genutzt. Bei der Personensuche sollen zu einer gewissen Aufgabe relevante Personen, z.B.
Experten, gefunden werden.
Eine weitere vom Benutzer ausführbare Aktion ist die automatische Priorisierung. Diese
bezieht sich direkt auf die Inbox und veranlasst, dass Emails, die einer schnellen Behandlung bedürfen, hervorgehoben dargestellt werden. Dies ist insbesondere wichtig, wenn
Benutzer nach einer Zeit lang (z.B. am nächsten Morgen oder nach einer Sitzung) die neu
angekommenen Emails lesen wollen. Wie eine Studie zeigt, lesen Anwender gerne Emails
in der Reihenfolge ihrer Priorität (Venolia u. a. 2001).
Neben den vorher genannten Aktionen kann der Benutzer eine Email selektieren. Die
Auswahl einer Email führt in der Regel zu weiteren Aktionen; der Benutzer kann die
selektiere Email nun öffnen und sie sich ansehen. Um angemessen auf den Inhalt zu reagieren, muss der Benutzer in der Regel Kontextinformationen einholen. So kann es nützlich
sein, relevante Emails anzuzeigen (wobei das angewandte Relevanzkriterium hier unberücksichtigt gelassen werden soll), um wertvolle Hintergrundinformationen für einen Vorgang
zu bekommen. Werden Personen in der Email erwähnt, können die zugehörigen Kontaktinformationen angezeigt werden. Werden Termine in der Email vorgeschlagen, können alle
eigenen Termine, die in den angesprochenen Zeitraum fallen, aus dem persönlichen Terminkalender extrahiert und angezeigt werden. Bevor der Benutzer eine selektierte Email
liest, möchte er sich evtl. vorher ein Bild über den Inhalt machen. Dazu wäre es sinnvoll,
eine automatische Zusammenfassung des Email-Inhalts erstellen zu lassen. Der Benutzer
kann danach entscheiden, ob er den gesamten Inhalt liest oder ob ihm die Zusammenfassung reicht. Ferner wäre es interessant, die je nach Dokumenttyp relevanten Informationen zu extrahieren. Handelt es sich bei einer Email um einen Auftrag, so können die
Auftragsdaten extrahiert und ggf. automatisch weiterverarbeitet werden.
Sobald Emails bearbeitet wurden, sollten sie archiviert werden. Benutzer bevorzugen
dabei die Möglichkeit, eine hierarchische Orderstruktur zu nutzen (Venolia u. a. 2001).
Emails können in die einzelnen Ordner kategorisiert werden. Die Kategorisierung kann manuell vorgenommen werden. Es kann aber auch eine automatische Vorkategorisierung stattfinden, in denen relevante Kategorien aus der gegebenen Ordnerstruktur des Benutzers
automatisch ausgewählt und dem Benutzer vorgeschlagen werden. Basierend auf diesem
Vorschlag kann dann letztendlich eine manuelle Kategorisierung stattfinden. Schließlich
sollte es dem Benutzer möglich sein, eine ausgewählte Email manuell zu priorisieren, etwa,
um eine vorherige automatische Priorisierung zu korrigieren oder aber geänderte Prioritäten zu vergeben, wenn etwa die dringendsten Aktivitäten schon veranlasst wurden und
eine Email erst später wieder vorgelegt werden muss.
Ein spezieller Use Case ist Benachrichtigen. Hier geht die Aktion vom System aus, das
den Benutzer über den Eingang neuer Emails informiert. Dabei ist von Nachteil, dass
diese Benachrichtigung bei jeder eingehenden Email geschieht (Venolia u. a. 2001); besser
wäre es, wenn der Benutzer entscheiden könnte, nur bei eingehenden Emails ab einer
gewissen Wichtigkeit oder Priorität von seiner aktuellen Tätigkeit abgelenkt zu werden.
Die oben spezifizieren Use Cases sollen mit Hilfe von spezielle Agenten realisiert werden, die im Diagramm als gesonderte Akteure auftreten. So kann ein Suchagent herange-
kiib
2.1 DAS INBOX-SZENARIO
13
zogen werden, wenn es um die einzelnen Rechercheaufgaben geht oder nach relevanten
(z.B. ähnlichen) Emails gesucht wird. Ein Extraktionsagent wiederum hat die Aufgabe, relevante Informationen aus der Email zu ziehen, die dann Datenbankagenten genutzt wird,
um zugehörige Kontextinformation zu bereitzustellen. Wurde z.B. der Name einer Person extrahiert, kann nun in der Datenbank die jeweilige Kontaktinformation nachgefragt
werden. Schließlich kann die automatische Vorkategorisierung von einem bestimmten Kategorisierungsagenten vorgenommen werden; ein derartiger Agent kann auch zur Priorisierung benutzt werden, da eine Priorisierung eine Einteilung in verschiedene Klassen wie
„dringend“ und „nicht dringend“ ist. Ein spezieller Benachrichtigungsagent sorgt für die
Benachrichtigung des Benutzers nach Eingang einer neuen Email. Um eine eingehende
Email nach Wichtigkeit und Priorität beurteilen zu können, kann der Benachrichtigungsagent hierbei vom Kategorisierungsagenten gebrauch machen.
2.1.3 Erweitertes Szenario: Ontologien und Annotationen
Heutige Mailprogramme lassen es zu, dass der Benutzer seine Emails in einer hierarchischen Ordnerstruktur ablegen kann. Eine solche Hierarchie hat aber gewisse Nachteile,
da zwischen den einzelnen Ordnern nur eine hierarchische Beziehung hergestellt werden kann. Eine Email können aber hinsichtlich verschiedener Facetten betrachtet werden,
wie das in Abb.2.2 skizzierte Beispiel darlegen soll. Hier haben wir es mit einer Reisebestätigung einer Fluggesellschaft zu tun, auf der die Daten für eine Dienstreise zu finden sind. Dienstreisen sind häufig an Projekte gebunden, also wäre der naheliegendste
Weg, die Email in den Ordner, in dem sich alle dieses Projekt betreffende Emails befinden,
einzusortieren (eventuell in einen Unterordner, der nur Dienstreisen betrifft). Auf diese
Weise lassen sich zwar die Emails zu Dienstreisen, die ein bestimmtes Projekt betreffen,
schnell auffinden, aber das Problem fängt schon an, wenn wir nach allen Dienstreisen,
unabhängig vom Projekt, suchen wollen – hier müssten wir alle . Folder, die Dienstreisen
enthalten, besuchen, oder aber hoffen, mit einer Volltextsuche über die Mailbox alle relevanten Emails zu finden. Es wäre also sinnvoll, Emails in eine komplexere Datenstruktur
zu indexieren, die ein schnelles Auffinden hinsichtlich verschiedener Facetten und Informationsbedürfnisse ermöglichen. Unser Vorschlag wäre hier, Emails mit den Instanzen
einer Ontologie zu annotieren.
Ontologien sind ein formal definiertes System von Konzepten (oder auch Klassen) und
Relationen, die zudem noch aus Inferenz- und Integritätsregeln bestehen können. Konzepte enthalten dabei bestimmte Attribute, die die jeweilige Klasse beschreiben. Instanzen eines Konzepts (oder einer Klasse) sind die Objekte der Ontologie. Mit Ontologien
lassen sich recht komplexe Wissenstrukturen modellieren, die sich zur Recherche in einem Email-Archiv ausnutzen lassen. So könnte es in unserem obigen Beispiel sinnvoll
sein, die Konzepte „Reise“ und „Projekt“ mit entsprechenden Attributen anzulegen. Für
jede Dienstreise könnte nun eine neue Instanz angelegt und mit einer Projekt-Instanz verknüpft werden. Ferner könnten alle Instanzen Referenzen zu relevanten Email enthalten. Somit wäre die Bearbeitung komplexerer Suchanfragen möglich. Wird beispielsweise
nach den Emails eines bestimmtem Projekts gesucht, könnten dem Benutzer die Email-
14
Verweise der entsprechenden “Projekt“-Instanz präsentiert werden. Benötigt der Benutzer die Emails über die im Rahmen eines Projektes getätigten Dienstreisen, so könnte das
System eine Schnittmenge der Emails der Projektinstanz mit denen aller Reiseinstanzen,
die mit diesem Projekt verknüpft sind, ausgeben.
Abbildung 2.2: Beispielemail mit Ontologie und Annotation
Natürlich sollten auch weitere relevante Konzepte in der Ontologie modelliert werden,
wobei auch externe Quellen herangezogen werden können. Man könnte sich z.B. vorstellen, Personen aus dem eigenen Adressbuch in die Ontologie einzufügen, oder Informationen über Orte, Städte und Länder.
Es ist weiterhin heutzutage möglich, einer Email ein Flag mitzugeben, das z.B. anzeigt,
ob eine Mail wichtig ist oder es zu einer ToDo-Liste zuzuweisen ist. Allerdings kann es
vorkommen, dass man eine Email erst nach einiger Zeit bearbeitet und Ideen, Gedanken
oder auch Direktiven zur weiteren Bearbeitung, die man beim erstmaligen Öffnen der
Email bekommen hat, wieder vergessen sind. Evtl. fragt man sich sogar, warum man eine
Email einst als „wichtig“ eingestuft hat. Hier können Annotationen im Sinne von Textkommentaren weiterhelfen, wie man sie in Abbildung 2.2 sieht.
kiib
2.2 PROBLEMSTELLUNG
15
2.2 Problemstellung
Aus dem im letzten Abschnitt diskutierten Use Cases ergeben sich einige Problemstellungen, die in dieser Studie hinsichtlich möglicher Lösungen untersucht werden sollen.
Wir beschäftigen uns, mehr oder weniger ausführlich, mit den folgenden Fachgebieten:
Information Retrieval, Datenbanken, Informationsextraktion, Summarization und Kategorisierung.
2.2.1 Information Retrieval
Hier geht es vornehmlich um Lösungen, die für die Implementierung des Suchagenten
nötig sind. Für die einzelnen Use Cases ergeben sich dabei folgende Problemstellungen:
Known-Item-Suche Ziel hierbei ist es, aus bisher gelesenen Emails eine bestimmte, wichtige Email wiederzufinden. Ein typisches Anwendungsbeispiel hier ist die Suche
nach Ankündigungen für Projekttreffen, die auch Zeit und Ort dieses Treffens beinhalten. Andere Beispiele sind das Wiederfinden von Protokollen oder anderen wichtigen Informationen. Es wird klar, dass es sich bei der Known-Item-Suche nicht um
ein ausschließliches Suchproblem handelt, da auch andere Techniken wie die Dokumentklassifikation und Informationsextraktion hier gewinnbringend eingesetzt
werden können.
Email-Suche Hier geht es darum, thematisch relevante, bereits archivierte Emails zu finden. Der Benutzer stellt dabei eine Anfrage; Emails sind die Dokumente, über denen
gesucht wird. Das System berechnet eine Rangordnung der Emails gemäß ihrem Retrievalgewicht.
Diskussionssuche Ähnlich wie bei der Email-Suche geht es bei der Diskussionsuche
darum, aus Email-Diskussionen thematisch relevante Emails zu finden. Als weiterer Schritt kann versucht werden, zusätzlich noch diejenigen Emails zu finden, die
ein Pro oder Kontra zu einem gegebenen Thema enthalten. Dies kann z.B. wichtig
für die Entscheidungsfindung sein. Diskussionsbeiträge sind dabei in so genannte
Threads organisiert, die sich durch die Beziehungen der Emails als Antworten auf andere Emails ergeben. Verfahren zur Diskussionssuche können diese Threadstruktur
zum Retrieval ausnutzen.
Personensuche Hier geht es darum, relevante Personen zu finden. Ein Beispiel hierfür ist
die Expertensuche. Hier sollen anhand von Emails Experten zu einem bestimmten
Thema identifiziert werden. Ein Anwendungsbeispiel ist, einen geeigneten Kontakt
für ein Problem zu finden. Das System würde dann anhand der Emails eine Liste
von geeigneten Personen ausmachen und dem Benutzer diese präsentieren.
Relevante Emails zeigen Welche Emails als „relevant“ einzuschätzen sind, ist ein breit
gefächertes Thema. Eine Definition von „Relevanz“ wäre „Ähnlichkeit“ – relevante
16
Emails wären in diesem Fall thematisch ähnliche Emails, so dass wir es hier mit einem typischen Suchproblem zu tun haben. Die aktuelle Email kann dabei als eine
Anfrage an den Email-Korpus gesehen werden, wobei das System dann eine Rangordnung von Emails gemäß deren Ähnlichkeit zur Ursprungsmail erstellt.
Die o.g. Problemstellungen sollen in dieser Studie nicht weiter betrachtet werden. Für
die Known-Item-Suche, die Personensuche und die Diskussionssuche sei an dieser Stelle
auf die Ergebnisse des letztjährigen TREC Enterprise-Track (siehe Voorhees u. Buckland
2005) verwiesen; hier wurden Verfahren erprobt, die auf die o.g. Problemstellung hinzielen.
2.2.2 Datenbanken
Zur Implementierung des Datenbank-Agenten sind klassische Datenbank-Anfragen nötig, deshalb soll diese Thematik hier nicht mehr weiter behandelt werden.
2.2.3 Summarization
Bei der Summarization geht es darum, aus einem gegebenen Dokument oder aber aus
einer Menge von Dokumenten eine geeignete Zusammenfassung zu erstellen. Dementsprechend sind diese Methoden für den Zusammenfassen Use Case interessant. Allerdings
wollen wir in dieser Studie auf die Summarization nicht weiter eingehen. Zur Übersicht
sei daher auf (Mani u. Maybury 1999) verwiesen.
2.2.4 Informationsextraktion
Hierbei geht es darum, semantische Informationen aus dem Text zu extrahieren. Typische
Beispiele sind das Erkennen von Personen, Orten und Terminen. Von Lösungen aus dem
Gebiet der Informationsextraktion können dabei folgende Use Cases profitieren:
Kontakt- und Termininfo zeigen Aus Sicht der Informationsextraktion ist hier die Aufgabe, aus dem Text Namen und Termine zu extrahieren. Mittels einer Datenbankabfrage kann dann z.B. aus dem persönlichen Adressbuch die Kontaktdaten der
extrahierten Personen angezeigt werden. Für extrahierte Termine könnte eine Anzeige aus dem persönlichen Kalender die Information liefern, ob der Benutzer zu
dem genannten Termin Zeit hat oder nicht. Wir stehen hier also vor der unmittelbaren Problemstellung, dass zunächst einmal Personen und Termine erkannt und mit
entsprechenden Einträgen in der Datenbank assoziiert werden müssen. Das Erkennen von Personen und Terminen kann u.U. mit regulären Ausdrücken geschehen,
wobei sich hier das Problem ergibt, wie mit unvollständigen Angaben (z.B. wurde
nur ein Vorname erkannt) umgegangen wird.
Relevante Emails zeigen Wir haben gesehen, dass dieser Anwendungsfall zunächst eine Problemstellung des Information Retrieval darstellt. Die Informationsextraktion
kiib
2.2 PROBLEMSTELLUNG
17
kann aber auch hier Hilfestellung leisten, wie wir in Abschnitt 5.5 diskutieren werden.
Extrahieren Hier geht es darum, aus einer Email relevante Daten zu extrahieren. Handelt es sich beispielsweise um eine Auftragsbestätigung, so sind die entsprechenden
Posten wie Auftragsnummer, Lieferdatum etc. zu extrahieren.
Wir suchen also nach Verfahren, die vorgegebene Daten aus einer Email extrahieren können.
2.2.5 Kategorisierung
Ein großer Teil der Problemstellungen fällt in den Bereich der Email-Kategorisierung. Kategorisierungsmethoden können dabei auf mehreren Ebenen hilfreich sein:
• Im Kategorisierungs-Use-Case geht es darum, dass Benutzer eine Email in ein oder
mehrere Ordner einsortieren wollen. Hierbei haben wir mit einer hierarchischen Kategorisierung zu tun, da in gängigen Emailsystemen die Möglichkeit besteht, ein hierarchische Ordnerschema anzulegen. Aufgabe der Email-Folder-Kategorisierung ist es,
für eine automatische Vorkategorisierung der Daten die passenden Ordner innerhalb der Ordnerstruktur zu finden.
• Auch zur Priorisierung können Kategorisierungsverfahren angewendet werden,
wenn man die Aufgabe der Priorisierung als Kategorisierung in verschiedene Prioritätsklassen ansieht. Ferner kann die Kategorisierung eine Schlüsseltechnologie bei
der Entscheidungsfindung des Benachrichtigungsagenten sein, um herauszufinden,
ob eine neu angekommene Email die benötigte Wichtigkeit und Priorität hat, um
den Benutzer damit bei seiner primären Tätigkeit zu stören.
Die bisherige Diskussion über die Anwendungsmöglichkeiten der Kategorisierung im
Inbox-Szenario macht deutlich, dass den einzelnen Kategorisierungsaufgaben unterschiedliche Kategorienschemata zu Grunde zu legen sind. Global betrachtet ergibt sich
daraus eine Multifacetten-Klassifikation, bei der die einzelnen Facetten unterschiedliche Kategorisierungsverfahren erfordern, bei denen unterschiedliche Features von Emails und
deren Inhalten zum Tragen kommen können. Die sinnvolle Definition der Facetten und
dazugehörigen Kategorienschema sollten dabei auf einer Analyse der vorhandenen Datenbasis basieren, wie sie im nächsten Kapitel durchgeführt wird. Gesucht sind also Kategorisierungsverfahren, die mit unterschiedlichen Facetten klar kommen.
3 Analyse der Datenbasis
Wir werden nun die für unsere weiteren Betrachtungen zu Grunde liegende Datenbasis,
den Enron-Korpus beschreiben. Auf Basis dieser Kollektion haben wir eine MultifacettenKlassifikation zusammengestellt, die in Abschnitt 3.2 diskutiert wird.
3.1 Der Enron-Korpus
Beim Enron-Korpus1 handelt es sich um eine große Menge von Email-Nachrichten der
US-amerikanischen Firma Enron. Der Korpus wurde während des Verfahrens gegen Enron freigegeben. Es handelt sich dabei um Emails, die in den Mailboxen der ehemaligen Enron-Mitarbeitern zu finden sind. Wie eine Analyse von Klimt und Yang (Klimt
u. Yang 2004) zeigt, enthält der Enron-Korpus 619.446 Nachrichten von 158 Benutzern.
Klimt und Yang haben dabei eine Säuberung des Korpus vorgenommen und einige Ordner, die in den Mailboxen der meisten Benutzer auftraten, entweder als automatisch generiert („discussion_thread“ und „notes_inbox“) oder als Sammelbecken für Duplikate
(„all_documents“) identifiziert. Diese Ordner sind nicht geeignet für eine weitere Betrachtung, da für eine Kategorisierung in Ordner von einer vom Benutzer selbst angelegten
Ordnerstruktur ausgegangen wird, die keine automatisch generierten Ordner enthalten
soll. Der von diesen Ordnern bereinigte Korpus enthält noch 200.399 Nachrichten der 158
Benutzer mit einem Durchschnitt von 757 Emails pro Benutzer. Dabei stellt sich heraus,
dass die Anzahl Nachrichten pro Benutzer grundsätzlich exponentiell anwächst; die meisten Emails verteilen sich auf eine geringe Anzahl Benutzer. Die meisten Benutzer haben
tatsächlich ihre Emails in Ordner einsortiert. Die Betrachtungen von Klimt und Yang zeigen, dass Benutzer nicht mehr Ordner als Emails haben; die obere Grenze für die Anzahl
Ordner, die ein Benutzer hat, scheint dabei der Logarithmus der Anzahl Emails des Benutzers zu sein.
Alles in allem stellt sich der Enron-Korpus als durchaus repräsentativer Korpus für die
anfallenden Aufgaben hinsichtlich der im letzten Kapitel vorgestellten Szenarien dar. Im
Bereich der Email-Klassifikation sind in der Literatur mehrere Artikel zu finden, wo Experimente mit diesem Korpus beschrieben sind. Allerdings hat der Korpus für uns den
Nachteil, dass sich hier nur englischsprachliche Emails befinden; um für den hiesigen
Markt erfolgreich zu sein, müssten Verfahren zur Email-Kategorisierung und Informationsextraktion mit deutschsprachlichen oder sogar multilingualen Korpora umgehen können. Da sich beim Enron-Korpus aber inzwischen um einen Standardkorpus zumindest
1 Zu
beziehen unter http://www.cs.cmu.edu/~enron/
3.2 MULTIFACETTENKLASSIFIKATION
19
für die Kategorisierung handelt, wollen wir das Problem der Mutlilingualität auf einen
späteren Zeitpunkt verschieben und an dieser Stelle nicht behandeln.
3.2 Multifacettenklassifikation
In Abschnitt 2.2.5 wurde die Email-Kategorisierung als ein zentrales Problem sowohl für
die Priorisierung von Emails und natürlich die automatische Einordnung von Emails in
die persönliche Ordnerstruktur eines Benutzers identifiziert. Grundlegend für jede Kategorisierungsaufgabe ist dabei ein zu Grunde liegendes Kategorienschema. Wir schlagen
an dieser Stelle eine Multifacettenklassifikation vor, durch die alle eine Email betreffenden
Facetten erfasst werden können. Diese Schema kann dabei als Vorstufe einer komplexeren
Wissensbasis, etwa durch eine Ontologie ausgedrückt, betrachtet werden.
Es wird hier versucht, ein Schema für eine Multifacettenklassifikation von Emails zu
definieren. Dabei wurde Wert darauf, möglichst objektive und generische Kategorien und
Dimensionen zu erzeugen. Die einzelnen Dimensionen können natürlich vom Benutzer
entsprechend verfeinert werden. Grundlage für die einzelnen Facetten war eine Betrachtung des Enron-Korpus und ein bereits vorhandenes Multifacettenschema, welches unter
http://bailando.sims.berkeley.edu/enron/enron_Categories.txt zu beziehen ist.
Automatische Verfahren können versuchen, Emails bezüglich der einzelnen Facetten
einzuordnen. Dabei ist zu beachten, dass pro Facette unterschiedliche Features und Terme
relevant sein können. So ist z.B. die Termhäufigkeit entscheidend, um die Topikalität eines
Textes zu ermitteln, aber nicht unbedingt relevant für andere Facetten wie z.B. Scope oder
den Dokumenttyp. Hier müssen sich im einzelnen andere Features überlegt werden.
Die vorgeschlagenen Facetten und ihre Kategorien sind im Einzelnen:
1. Document Type
Diese Facette gibt den Dokumenttyp einer Email an. Mögliche Kategorien sind:
1.1 Schedule, meetings
Einladungen zu Treffen, Termine
1.2 Technical Support, Requests
Verschiedene Anfragen, z.B. um technische Unterstützung
1.3 Collaboration
Emails zum Organisieren kollaborativer Tätigkeiten
1.4 Business letters and documents
Geschäftsdokumente
1.5 News
Nachrichten aller Art, Newsletter
1.6 Press release
Pressemitteilungen
1.7 Legal documents
Verträge, Non-Disclosure-Agreements, alles was rechtlich bindend ist
20
3 ANALYSE DER DATENBASIS
1.8 Announcement
Zum Beispiel Ankündigungen neuer Produkte oder von Veranstaltungen
1.9 Minutes
Protokolle von Treffen
1.10 Discussion and comments
Diskussionsbeiträge und Kommentare
1.11 Invoice/bills
Rechnungen
1.12 Bookmarks and references
Bookmarks, Hinweise auf relevantes Material
1.13 Jokes
Humor
1.14 Attachment
Hinweise auf eine angehängte Datei
1.15 SPAM/Unwanted
Unerwünschte Mail, die sofort wieder gelöscht werden sollte
2. Scope
In welchen Bereich eine Email einzuordnen ist. Bereiche können dabei noch in Unterbereiche gegliedert werden, z.B:
2.1 Business
Geschäftsmails
2.1.1 Project 1
Zugehörig zu Projekt 1
2.1.2 Project 2
Zugehörig zu Projekt 2
2.2 Private
Private Emails
3. Personal, Topics
Unter diese Facette fällt die klassische persönliche Folderstruktur, die ein Benutzer
unter seinem Mailaccount anlegt. Diese Folderstruktur ist in der Regel hierarchisch
und kann Kategorien anderer Facetten beinhalten (z.B. kann ein Benutzer hier zwischen privater und geschäftlicher Email unterscheiden). Wir gehen aber vereinfachend davon aus, dass die vom Benutzer angelegten Folder disjunkt zu den Kategorien anderer Facetten und zunehmend topikalischer Natur sind. Da eine derartige
Folderstruktur i.A. sehr stark vom eigentlichen Anwender und seinem Umfeld abhängig und sehr dynamisch ist, wird hier auf eine weitere Aufgliederung verzichtet.
4. Priority
Die Dringlichkeit, mit der eine Email bearbeitet werden sollte. Emails, die als hoch
priorisiert klassifiziert werden, können so dem Benutzer direkt angezeigt werden
bzw. kann der Benutzer über deren Eingang direkt benachrichtigt werden.
kiib
3.2 MULTIFACETTENKLASSIFIKATION
21
4.1 High priority
Sofort zu erledigen
4.2 Medium priority
Kann noch etwas warten
4.3 Low priority
Spätere Wiedervorlage
5. Importance
Bestimmung der Wichtigkeit einer Email. Eine Benachrichtigungsstrategie kann z.B.
sein, Benutzer nur über sehr wichtige Emails direkt zu benachrichtigen.
5.1 Very important
Sehr wichtige Emails
5.2 Important
Wichtige Emails
5.3 Less important
Unwichtige Emails
6. Email Act
Eine interessante weitere mögliche Facette von Emails ist deren Einteilung in verschiedene Sprechakte (Cohen u. a. 2004; de Carvalho u. Cohen 2005). Solche Email
Acts bestehen aus einem Verb und einem Substantiv (z.B. „deliver data“)2 und beschreiben die Absicht des Autors. Dabei ist zu beachten, dass in einer Email natürlich mehrere Sprechakte vorkommen können. Die Identifikation eines bestimmten
Email Acts kann verschiedene Aktionen zur Folge haben; ein ausgehendes Folgende
Email Acts werden in (Cohen u. a. 2004; de Carvalho u. Cohen 2005) vorgeschlagen3 :
6.1 Verb
i. Propose
ii. Request
iii. Amend
iv. Conclude
v. Commit
vi. Refuse
vii. Greet
viii. Deliver
ix. Remind
x. Other
6.2 Noun
i. Information
2 Basierend
3 Hier
auf der Analyse englischsprachiger Emails
nicht in der vollen Hierarchie dargestellt
22
3 ANALYSE DER DATENBASIS
ii.
iii.
iv.
v.
vi.
Data
Meeting
Logistics
Opinion
Meeting
Die Identifikation eines bestimmten Email Acts kann verschiedene Aktionen zur
Folge haben; ein ausgehendes Commitment kann beispielsweise einen Eintrag in einer To-Do-Liste zur Folge haben. Oder aber es könnte ein Request eine Höherstufung
der Email in der Priorität nach sich ziehen.
7. Emotional Tone
Emotional Tone könnte z.B. interessant sein, um die Stimmung über ein Thema, Projekt oder eine Maßnahme rauszufinden (evtl. in Kombination mit anderen Facetten
wie Discussion/Comments).
7.1 Jubilant
Jubilierend, triumphierend, sich freuend
7.2 Angry
Wütender, aggressiver Ton
7.3 Businesslike
Geschäftsmäßiger, sachlicher Ton
7.4 Frustrated
Frustrierter, unzufriedener Ton, z.B. bei wenig befriedigem Projektverlauf
7.5 Promotional
Anpreisend, werbend, wenn in der Email z.B. für ein neues Produkt geworben
wird
7.6 Neutral
Kein besonderer emotionaler Ton, evtl. ähnlich wie „businesslike“
Eine Email könnte so z.B. in die Multifacetten-Kategorie
(’Press Release’, ’Business/Project_1’, ’Product XY’,
’Medium priority’, ’Less important’, ’Deliver Information’,
’Jubilant’)
eingeordnet werden.
kiib
4 Email-Kategorisierung
Bei der Email-Kategorisierung geht es nun darum, Emails in die verschiedenen Kategorien der Multifacetten-Klassifikation, wie sie im Abschnitt 3.2 vorgestellt wurde, einzuordnen. Emails selbst sind als semi-strukturelle Texte zu betrachten, die aus einer Menge
von strukturierten Feldern (dem Header) und aus dem zumeist unstrukturierten Body, in
dem der eigentliche Inhalt der Email, bestehen. Die betrachteten Ansätze ignorieren dabei
meist mögliche Dateianhänge (Attachments) und gehen davon aus, dass die Kernaussage
einer Email im Body steckt.
Bevor wir uns nun mit den einzelnen Kategorisierungsmöglichkeiten beschäftigen,
müssen zunächst zwei Begriffe geklärt werden. Während wir uns in dieser Studie mit
der Kategorisierung oder Klassifizierung befassen, wird in der Literatur häufig der Begriff
des Email Filtering verwendet. Die Filterung und die Kategorisierung sind aus Prozesssicht
sehr stark miteinander verwandt; der Hauptunterschied ist der, dass bei der Filterung von
eher dynamischen Profilen ausgegangen wird, nach denen Dokumente einsortiert werden,
während Kategorien eine eher statische Natur haben (Belkin u. Croft 1992). Bei dynamischen Kategorien wie denen, die unter der Facette Personal, Topics zu erwarten sind, hat
man es also streng genommen mit einem Filterungsprozeß zu tun, wie in einiger Literatur
auch erwähnt wird. Wir verzichten an dieser Stelle allerings auf eine genaue Unterscheidung und sehen alle Verfahren als Kategorisierungsverfahren an.
Im folgenden Abschnitt werden wir den State-of-the-Art in der Email-Kategorisierung
beleuchten. Hierbei handelt es sich hauptsächlich um Verfahren, die ein (semi-)automatisches Einsortieren in eine gegebene Folderstruktur vornehmen. Die Verfahren
sind somit besonders für die Personal, Topics-Facette interessant, sollten aber in veränderter Form auch auf andere Facetten anwendbar sein. Wir berichten von Resultaten der
durchgeführten Experimente; diese zeigen die Effektivität und (teilweise) die Effizienz
der Verfahren und bilden somit eine wertvolle Entscheidungsgrundlage für die praktische industrielle Einsetzbarkeit derselben. Abschnitt 4.2 beschäftigt sich nun mit möglichen neuen Ansätzen, die auf dem Gebiet der Email-Kategorisierung bisher ungeprüft
sind, deren praktische Einsetzbarkeit also erst noch gezeigt werden muss. Die dort vorgestellten Verfahren sollen die Kategorisierung hinsichtlich aller Facetten ermöglichen.
4.1 Bisherige Erfahrungen
In diesem Abschnitt sollen bisherige Verfahren zur Email-Klassifikation vorgestellt werden, die experimentell evaluiert wurden und somit einen Eindruck über deren Anwendbarkeit gewinnen lassen. Die Techniken aus dem Bereich des maschinellen Lernens lassen
24
4 EMAIL-KATEGORISIERUNG
sich grob in zwei Klassen einteilen:
1. Verfahren aus der Textklassifikation, die für die gegebene Aufgabe angewendet werden und
2. regelbasierte Verfahren, bei denen aus einer gegebenen Stichprobe eine Menge von
Regeln gelernt werden.
Wir werden nun beide Klassen und repräsentative Verfahren aus diesen vorstellen. Vorher
aber wollen wir kurz auf die in der Literatur üblichen Evaluierungsmaße eingehen.
4.1.1 Evaluierungsmaße
Für die Evaluation der Effektivität eines Kategorisierungsansatzes wird häufig das so genannte F1 -Maß benutzt, das auf den traditionellen Maßen Recall r und Precision p basiert
und diese kombiniert. Diese sind für die Kategorisierung wie folgt definiert (Yang u. Liu
1999):
#richtig vorgenommene Zuweisungen
(4.1)
r=
#richtige Zuweisungen
und
p=
#richtig vorgenommene Zuweisungen
.
#vorgenommene Zuweisungen
(4.2)
Das F1 -Maß definiert sich dann als (Fuhr 1996, Kap. 3, in der Fassung von 2005)
F1 (r, p) =
2pr
.
p+r
(4.3)
Die Werte können dabei entweder für jede binäre Entscheidung auf jeder Kategorie ermittelt und dann über die Kategorien gemittelt werden. Dies bezeichnet man dann als
macro-averaging. Oder aber man berechnet sie global über alle n · m Entscheidungen (mit n
als der Anzahl Textdokumente und m als der Anzahl Kategorien); in diesem Falle spricht
man von micro-averaging.
In der Literatur findet man häufig auch den Begriff der Accuracy. Diese ist in der Regel
definiert der Anteil der korrekt klassifizierten Emails zu der Anzahl der Instanzen im
Testset. Ist letzteres gleich der Anzahl der vorgenommenen Zuweisungen, so entspricht
es der Precision.
Die Definition einer „richtigen Zuweisung“ hängt vom jeweiligen Verfahren ab; wollen
wir exakt eine Kategorie zuweisen, so wird nur geschaut, ob das System diese richtig
erkennt. Manche Systeme bieten dem Benutzer aber mehrere Kategorien zu Auswahl an;
in diesem Sinne bedeutet „richtige Zuweisung“, dass sich die korrekte Kategorie unter
den vom System gefunden befindet.
kiib
4.1 BISHERIGE ERFAHRUNGEN
25
4.1.2 Verfahren aus der Textklassifikation
tf × idf -Klassifizierer
tf × idf -Klassifizierer werden auch Information Retrieval-Klassifizierer genannt, weil sie
auf einem im IR typischen Prinzip, der Kombination der Termhäufigkeit (term frequency, tf ) mit der inversen Dokumenthäufigkeit (inverse document frequency, idf ) beruhen. Der
hier besprochene Ansatz wurde von Segal u. Kephart (1999) vorgestellt und ähnelt dem
Megadokumenten-Ansatz von Klas u. Fuhr (2000), wobei letzterer noch nicht auf eine
Email-Kollektion angewendet wurde. Man geht beim tf × idf -Klassifizierer von einem
vektorbasierten Modell aus; der Vektorraum wird durch die Menge T aller in der Kollektion C vorhanden Terme ti (mit 1 ≤ i ≤ |T |) aufgespannt. Jede Email m wird dementsprechend als Vektor ~x (m) repräsentiert; die Komponente xi (m) ergibt sich aus der Vorkommenshäufigkeit des Terms ti in der Nachricht. Jeder Folder f wird durch den Vektor
~ ( f ) repräsentiert, dessen Komponenten gewichtete Wordhäufigkeiten darstellen. w
~ bew
rechnet sich dabei aus den im Folder enthaltenen Emails bzw. deren Termen als
wi ( f ) = tf ( f , ti ) · idf (ti )
mit
idf (ti ) =
und
df (ti ) =
1
df (ti )2
#Folder, die ti enthalten
#Folder
sowie
tf ( f , ti ) =
ff ( f , ti )
ff ( A, ti )
wobei A die Menge aller in der Kollektion vorhandenen Emails ist. ff wiederum ist die
anteilige Frequenz (fractional frequency) und berechnet sich als
ff ( f , ti ) =
und
ci ( f ) =
ci ( f )
∑ ti ∈ f c i ( f )
∑
xi ( m )
m∈ f
mit m als in f enthaltene Email. Nachdem auf diese Weise Emails und Folder jeweils als
Vektoren repräsentiert werden, wird nun die Ähnlichkeit zwischen einer zu kategorisierenden Nachricht m und einem Folder f berechnet (Segal u. Kephart 1999):
SIM4(m, f ) =
∑ ti ∈ m x i ( m ) · wi ( f )
min ∑ti ∈m xi (m), ∑ti ∈m wi ( f )
Auf diese Weise erhält man nun ein Ranking der Folder absteigend nach ihrer Ähnlichkeit
zur kategorisierenden Email. In dem von Segal u. Kephart beschriebenen MailCat-System
26
wird diese Rangordnung benutzt, um dem Benutzer die drei höchstrangigen Folder für
eine Email anzubieten.
Ein Vorteil des tf × idf -Klassifizierers ist, dass er vollständig inkrementell arbeitet und
sich dementsprechend hervorragend für eine dynamische Umgebung, wie wir sie z.B. in
der Personal, Topic-Facette vorliegen haben – es werden ständig Emails einer Kategorie
neu hinzugefügt oder dieser wieder entnommen. Das System speichert nun den zentroiden Vektor ~c( f ) = (c1 ( f ), . . . , c|T | ( f )) eines jeden Folders f in einem invertierten Index.
Wenn eine Email m kategorisiert werden soll, so werden für alle in m vorkommenden
Terme aus den Komponenten des zentroiden Vektors von f mit Hilfe obiger Formeln die
jeweiligen für die Berechnung von SIM4(m, f ) nötigen Komponenten ermittelt (siehe dazu Segal u. Kephart 1999). Der Index der zentroiden Vektoren kann effizient aktualisiert
werden, wenn eine Email zu einem Folder hinzugefügt oder aus diesem entfernt wird; es
ist dann
ci ( f ) ← ci ( f ) + xi ( m )
für alle ti ∈ m, wenn eine Email m dem Folder f hinzugefügt wurde. Entsprechend wird
xi (m) subtrahiert, wenn m aus f entfernt wurde. Der Index wird also inkrementell angepasst, sobald sich hinsichtlich der kategorisierten Emails eine Veränderung vollzogen hat.
Es ist dabei kein aufwändiger neuer Lernschritt notwendig, wie bei anderen Methoden
des maschinellen Lernens.
Experimente Wie oben erwähnt wird das Verfahren im MailCat-System eingesetzt, um
dem Benutzer drei mögliche Kategorien zur Auswahl zu geben, in die er eine Email einsortieren kann. In diesem Sinne sollte die korrekte Kategorie unter den ersten dreien im
Ranking zu finden sein. Für die Evaluation der Effektivität des Ansatzes wurde die Accuracy gemessen. Experimente wurden über 6 verschiedenen Mailboxen durchgeführt. Sie
zeigen eine Accuracy von 80% bis 90% für die mögliche Auswahl von drei Kategorien (Segal u. Kephart 1999). Brutlag u. Meek (2000) führen weitere Experimente mit der tf × idf Methode durch, wobei hier 5 Kategorien präsentiert werden (statt 3). Die Experimente
zeigen eine Accuracy zwischen 65% und 90%, gemessen auf 5 verschiedenen Mailboxen.
Interessant bei den Ergebnissen ist, dass der tf × idf -Ansatz auch bei Foldern mit wenigen
Emails („karge Folder“) gute Resultate zeigt, während die Accuracy bei Foldern mit mehreren Emails (>100) sogar teilweise abnahm. Ferner zeigt sich, dass der tf × idf -Ansatz
selbst dann noch akzeptable Ergebnisse liefert, wenn statt der gesamten Email (Header
und Body) nur der Header berücksichtigt wird (was einen Performanzgewinn hinsichtlich
der Anzahl der verwendeten Features mit sich bringt). Eine Erklärung kann sein, dass bei
der Berechnung der anteiligen Frequenz ff nur der relative Anteil eines Terms innerhalb
eines Folders berücksichtigt wird, der auch bei kargen Foldern groß sein kann.
Support Vector Machines
Bei Support Vector Machines (SVM) handelt es sich um ein maschinelles Lernverfahren,
das sehr gute Ergebnisse in der Textkategorisierung gegenüber anderen Verfahren erzielt
kiib
27
hat (Yang u. Liu 1999; Joachims 1998). Support Vector Machines basieren auf dem Prinzip
Abbildung 4.1: Support Vector Machines
der Structural Risk Minimation; die Idee ist, eine Hyperebene zu ermitteln, die die Datenpunkte zweier Klassen möglichst sauber trennt. Solch eine Hyperebene ist im zweidimensionalen Fall eine Gerade, wie in Abbildung 4.1 illustriert. Das Verfahren sucht dabei
eine Hyperebene mit einem maximalen Rand; innerhalb des Randes (in Abb. 4.1 durch die
schmalen Linien repräsentiert) befinden sich keine Datenpunkte aus den beiden Klassen.
Die Hyperebene kann beschrieben werden als
~ · ~x − b
w
(4.4)
wobei ~x der zu klassifizierende Datenpunkt ist. Dieser kann als Featurevektor beschrieben werden, wobei jedes Element einen Term repräsentiert und dazu dessen kombiniertes
tf × idf -Gewicht genommen wird (Joachims 1998). Sobald die Hyperebene gegeben ist, berechnet die Funktion
(
sign(~
w · ~x − b) =
~ · ~x − b > 0
+1, wenn w
−1, sonst
die positive (+1) oder negative (−1) Zugehörigkeit des zu klassifizierenden Datenpunktes
~x zur überprüften Klasse. (4.4) kann auch umgeschrieben werden als
~ · ~x − b =
w
~
~
α
K
d,
d
i +b
∑ i
i
28
wobei K eine so genannte Kernelfunktion darstellt. Man unterscheidet zwischen linearen
und nicht-linearen Kernelfunktionen; es sind
~ ~di ) = d~ · ~di
Klin (d,
d
~ ~di ) = d~ · ~di + 1
K poly (d,
2 ~
~
~
~
Krb f (d, di ) = exp γ d − di
~
~
~
~
Ksigmoid (d, di ) = tanh s d · di + c
lineare, polynominale, radialbasierte und sigmoide Kernelfunktionen, die im nichtlinearen Fall neue Parameter (d,γ,s,c) einführen. Die Wahl der Kernelfunktion kann das Klassifikationsergebnis beeinflussen (Joachims 1998). Die di sind die so genannten Supportvektoren; dies sind die Vektoren, die genau auf dem Rand um die Hyperebene liegen und
von dieser exakt den Abstand 1/||~
w|| haben (in Abb. 4.1 fett umrandet). Die Supportvektoren sind deshalb bemerkenswert, weil sie die einzigen effektiven Datenpunkte in der
Trainingsmenge sind; entfernt man alle anderen Datenpunkte aus der Trainingsmenge, so
würde sich die ermittelte Hyperebene nicht ändern.
SVM bietet die Möglichkeit zu entscheiden, ob ein Dokument zu einer Kategorie gehört
oder nicht. Für jede zu überprüfende Kategorie muss also eine Partitionierung des Kategorienraumes in die zu überprüfende Kategorie und alle restlichen Kategorien vorgenommen werden. Platt (2000) berichtet zudem noch von Möglichkeiten, die Wahrscheinlichkeit einer Zuweisung (statt einer binären ja/nein-Entscheidung) zu berechnen. Mittels
einer derartigen Erweiterung ist es auch mit SVM möglich, ein Ranking von Kategorien
bezüglich des einzusortierenden Dokumentes zu erzeugen.
Experimente Der Erfolg des SVM-Verfahrens bei der Textklassifikation hat dafür gesorgt, dass die Support Vector Machines in vielen Experimenten zur Email-Klassifikation
berücksichtigt und neu evaluiert wurden. Brutlag u. Meek (2000) erzielen dabei in ihren
Experimenten, bei denen 5 Kategorien zu Auswahl gegeben wurden, eine Accuracy bis zu
98%, sofern Folder mehr als 100 Nachrichten aufweisen. Bei Foldern mit weniger Nachrichten geht die Accuracy stetig zurück. Klimt u. Yang (2004) führen u.A. Experimente
mit dem Enron-Korpus durch (siehe Abschnitt 3.1) durch. Dabei sehen sie eine Email als
Bag-of-Words, basieren Features aber auf unterschiedliche, in einer Email anzutreffende
Felder wie „From“, „Subject“, „Body“ und „To, CC“ oder auf die gesamte Email. Dabei
stellt sich heraus, dass der Email-Body am brauchbarsten für die Klassifikationsentscheidung ist (micro-averaged F1 ≈ 0, 59, macro-averaged F1 ≈ 0, 46). Die besten Ergebnisse
wurden jedoch bei einer Linearkombination aller Features erzielt, bei der deren Werte
kombiniert wurden (micro-averaged F1 ≈ 0, 69, macro-averaged F1 ≈ 0, 54). Dies weist
darauf hin, dass die Benutzer des Enron-Korpus mehrere Email-Felder für ihre EmailOrganisation benutzen. Interessant ist hierbei auch die Beobachtung, dass für Benutzer
mit vielen Emails pro Folder schlechtere Ergebnisse erzielt wurden, was im Widerspruch
kiib
29
zu den in Brutlag u. Meek (2000) gefundenen Ergebnissen steht. Klimt und Yang schließen
daraus, dass sie wichtige Features nicht modelliert haben.
Die bisherigen Experimente haben den Nachteil, dass sie eine entscheidende Eigenart
von Email-Inboxen unberücksichtigt lassen: ein System kann natürlich nur von Nachrichten lernen, die älter sind als die einzusortierenden Nachrichten, und eine Email-Inbox entwickelt sich mit der Zeit von einem fast leeren zu einem immer mehr gefüllten Zustand.
Man sollte also auch wissen, wie sich ein automatischer Klassifizierer im Laufe der Zeit
verhält. Aus diesem Grund haben Bekkerman u. a. (2004) eigene Experimente mit SVM
auf dem Enron-Korpus durchgeführt. Dabei nutzen sie eine inkrementelle, zeitbasierte
Aufteilung in Trainings- und Testdokumente (incremental time-based split). Emails werden
dabei zunächst nach ihrem Zeitstempel sortiert und die Kollektion dann in k gleichgroße
Teile der Größe n aufgeteilt. Zunächst wird der Klassifizierer mit den ersten n Testdokumenten trainiert und auf den folgenden n Emails getestet. Danach wird der Klassifizierer
mit den ersten 2n Email trainiert und auf den darauf folgenden n-Nachrichten getestet,
bis zum Schluss auf den ersten (k − 1)n Dokumenten trainiert und den letzten n Dokumenten getestet wird. Auf diese Weise wird das stetige Wachstum der Inbox simuliert und
auf verschiedenen Entwicklungsstufen getestet. In den Experimenten hat SVM am besten
abgeschnitten, mit einer durchschnittlichen (gemittelt über alle zeitbasierten Aufteilung)
Accuracy zwischen 56.4% und 94.6%, je nach Mailbox. Allerdings sind die Werte überraschenderweise niedrig (die 94.6% wurden auf einer besonderen Mailbox erzielt, über
die wir noch diskutieren werden). Die meisten Werte sind zwischen besagten 56.4% und
82.7%, was niedriger ist, als man sonst bei SVM in der Textklassifikation erwarten könnte.
Bekkerman, McCallum, u. Huang sehen darin einen Effekt ihrer (realistischeren) Aufteilung in Test- und Trainingsmenge die anzeigt, dass die Email-Klassifikation ein komplexeres Problem als die Standard-Testklassifikation darstellt. Ein großes Problem stellen dabei
neu angelegte Folder dar, die inital noch leer sind. Die ist besonders deutlich zu sehen in
der williams-w3-Mailbox, wo sich zwei sehr große Folder (mehr als 1000 Nachrichten)
und einige kleinere (zumeist deutlich unter 100 Nachrichten) befinden, wobei einer der
größeren Folder ältere Nachrichten und der andere nur jüngere Nachrichten enthält. Sobald das Testverfahren den neuen großen Folder anlegt, minimiert sich hier die Accuracy
signifikant und erholt sich danach wieder. Eine weitere interessante Beobachtung bei den
Experimenten von Bekkerman u. a. ist auch, dass sich die Accuracy meistens nicht signifikant mit der Anzahl Trainingsdokumente erhöht, sondern eine Stagnation aufweist. Dies
wird damit erklärt, dass große Folder ältere Emails beinhalten, die bei der Einsortierung
neuerer Emails keine Rolle mehr spielen.
Die o.g. Experimente beziehen sich auf das Kategorisieren in ein persönliches FolderSchema des Benutzers, behandelt also unsere Facette Personal, Topics. Es sind aber in der
Literatur auch Experimente mit nicht-topikalischen Kategorien vermerkt, die mit SVM
durchgeführt wurden. Nenkova u. Bagga (2003) kategorisieren Emails in so genannte Root
Messages und Single Messages. Das zu Grunde liegende Szenario ist das eines Kontaktcenters, bei denen eingehende Kundenemails bezüglich ihrer Priorität (sofort zu beantworten
oder nicht) klassifiziert werden. Root Messages bestehen dabei aus Fragen oder Hilfegesu-
30
chen, die in einem Kontaktcenter sofort beantwortet werden sollten. Single Messages sind
solche, die z.B. Anregungen zur Verbesserung von Produkten, Vorschläge für zusätzliche
Produkteigenschaften, etc. enthalten und somit nicht ganz dringlicher Natur sind. Support Vector Machines vermögen es, mit einer Accuracy von annähernd 80% zwischen Root
und Single Messages zu unterscheiden. Emails wurden dabei durch verschiedene Features wie nicht-inflektierte Wörtern, Phrasen (Substantive, Verben), Interpunktion, Länge
der Email und das Vorkommen eines Terms in einem speziellen Wörterbuch repräsentiert.
Auch wenn sich die Ergebnisse nicht vollständig auf die Kategorisierung mit der PriorityFacette übertragen lassen, so geben sie doch einen ersten Eindruck der Anwendbarkeit
von SVM in dieser Facette.
Cohen u. a. (2004) benutzen Support Vector Machines für die Einteilung von Emails
in Sprechakte (siehe auch Facette Email Act). Das Problem der Einordnung in Sprechakte
stellt sich (erwartungsgemäß) als komplexer als die herkömmliche Textklassifikation heraus, auch wenn für bestimmte Sprechakte ein F1 -Wert von über 0,8 erzielt wird. Weiterhin
stellt sich heraus, dass Features wie tf × idf bei der Einteilung in Sprechakte eine eher negative Wirkung haben. Bigramme und Part-of-Speech-Tags scheinen hier angebrachter zu
sein.
Naïve Bayes
Auch mit dem Naïve-Bayes-Ansatz wurden einige interessante Experimente zur EmailKlassifikation durchgeführt, deshalb soll er hier auch kurz vorgestellt werden. Bei Naïve
Bayes (NB) geht es darum, die Kategorie c für ein Dokument d herauszufinden als
c = arg max P(ci |d) = arg max P(d|ci ) P(ci )
i =1,...,m
i =1,...,m
mit m als der Anzahl Kategorien. Es wird üblicherweise vereinfachend die Unabhängikeitsannahme
P ( d | ci ) = P ( f 1 | ci ) · . . . · P ( f n | ci )
gemacht, wobei f 1 , . . . , f n verschiedene Dokumenteigenschaften beschreiben. P( f j |ci ) mit
1 ≤ j ≤ n und 1 ≤ i ≤ m und P(ci ) werden dabei aus der Lernstichprobe ermittelt.
Experimente Provost (1999) führt Email-Klassifikations-Experimente mit NB aus und
erreicht eine Accuracy von bis zu 87%, getestet auf seiner eigenen Mailbox (über 4 Monate gesammelt). Dabei wurde NB benutzt, um eine Kategorie pro Email auszuwählen.
Die von Bekkerman u. a. (2004) durchgeführten Experimente mit NB, die auf einer realistischeren Konfiguration beruhen (siehe letzter Abschnitt), zeigen aber, dass NB bei der
Einteilung von Emails in ein vom Benutzer vorgegebenes Folderschema schlechter ist
als vergleichbare Verfahren. NB liefert auf dem Enron-Korpus signifikant schlechtere Ergebnisse als SVM, auch wenn auf verschiedenen Mailboxen eine Accuracy bis zu 92.2%
(williams-w3, siehe dazu Anmerkungen im letzten Abschnitt) erreicht wird.
kiib
31
Diao u. a. (2000) führen Experimente mit NB aus, in dem sie Emails in die nichttopikalischen Kategorien „interessant“ und „nicht interessant“ einsortieren. Der implementierte NB-Algorithmus stuft dabei eine Email d als „nicht interessant“ ein , wenn die
Wahrscheinlichkeit P(„nicht interessant“|d) größer als ein gegebener Schwellwert α ≥ 0, 5
ist. Der Hintergrund ist der, dass die Klassifikation einer interessanten Nachricht als nichtinteressant zu höheren Kosten führt als umgekehrt; α = 0, 5 bedeutet, dass wir diese
Überlegungen nicht berücksichtigen. Diao u. a. führen verschiedenen Experimente mit
0, 5 ≤ α ≤ 0.99 durch. Hierbei ergaben sich sowohl beim Recall als auch bei der Precision
Werte größer als 0,9. Die Experimente fanden auf fünf Datensätzen statt, bei denen die
Personen, die die Email-Daten zur Verfügung stellten, diese sehr subjektiv in die Kategorien „interessant“ und „nicht interessant“ einsortierten. Was die Experimente allerdings
nicht beachten ist die Tatsache, dass diese Kategorien sehr dynamisch sein können; die
Beurteilung, was interessant ist und was nicht, kann sich sich mit der Zeit schnell ändern
und theoretisch wäre jedesmal die Erstellung einer neuen Lernmenge notwendig, was
sehr aufwändig ist.
Wide-Margin-Winnow
Der in Bekkerman u. a. (2004) vorgeschlagene Wide-Margin-Winnow-Algorithmus berechnet für jede Klasse einen Gewichtsvektor über die gegebenen Features. Dabei bezeichne c
die Anzahl der Klassen und m die Größe des Eigenschaftsraumes. Jede Klasse ci wird da~ i (1 ≤ i ≤ c) repräsentiert. Genauso werden Emails
bei durch einen Eigenschaftsvektor w
als Eigenschaftsvektor repräsentiert. Ist nun ein neues Trainingsbeispiel (~x, y) gegeben (y
bezeichnet hierbei den Index der korrekten Klasse), so schätzt der Algorithmus nun zunächst mittels j = arg maxi=1,...,c {~
wi · ~x } den Index einer Klasse. Ist j 6= y, die Abschätzung
~ y und w
~ j an den Koordinaten, an denen ~x nicht 0 ist, entsprechend
also falsch, so werden w
angepasst. Bekkerman u. a. erweitern diesen klassischen Winnow-Algorithmus um eine
Heuristik, nach der das Gewicht der Vektoren auch dann angepasst wird, wenn der Algorithmus zwar die richtige Kategorie erkannt hat, aber zwischen der ersten und zweiten
Wahl nur ein marginaler Unterschied besteht. Es wird dann versucht, den Abstand dieser
Kategorien zu vergrößern (daher der Name „wide-margin“), wenn das Verhältnis zwischen bester und zweitbester Kategorie unter einem Wert δ liegt. Algorithmus 1 zeigt den
Pseudocode für den Wide-Margin-Winnow-Algorithmus
Experimente Bekkerman u. a. (2004) berichten von Experimenten mit dem WideMargin-Winnow-Algorithmus auf dem Enron-Korpus. Sie gehen dabei wie in Abschnitt 4.1.2 beschrieben vor, benutzen also wieder die zeitbasierte Aufteilung in
Trainings- und Testdokumente. Auch wenn der Wide-Margin-Winnow-Algorithmus hier
von der Effektivität her etwas schlechter abschnitt als Support Vector Machines, wurde
er doch als bei weitem schnellster Lernalgorithmus erkannt. Während SVM bei den in
den Experimenten herrschenden Bedingungen bis zu einer halben Stunde zum Lernen
auf einer größeren Testmenge benötigt, kommt der Wide-Margin-Winnow-Algorithmus
32
Eingabe:
Trainingsmenge {(~xk , yk )|k = 1, . . . , n}
Gewichtsjustierung e
Kühlungsrate α
Konfidenzmaß δ
~ 1, . . . , w
~ c , (m + 1)-dimensionale Vektoren von Gewichten jeder Kategorie
Ausgabe: w
~ 1, . . . , w
~ c zu 1-Vektoren
1: Initialisiere Vektoren w
2: for p ← 1 to t do
3:
for k ← 1 to n do
4:
j ← arg maxi=1,...,c {~
wi · x~k }
0
5:
j ← arg secondmaxi=1,...,c {~
wi · x~k }
6:
if j 6= y then
7:
wy, f ← wy, f (1 − eα p ) an Koordinaten f wo x~k nicht 0
8:
w j, f ← w j, f (1 − eα p ) an Koordinaten f wo x~k nicht 0
~ j0 · x~k < δwy · xk then {es ist y = j}
9:
else if w
10:
wy, f ← wy, f (1 − eα p ) an Koordinaten f wo x~k nicht 0
11:
w j0 , f ← w j0 , f (1 − eα p ) an Koordinaten f wo x~k nicht 0
12:
end if
13:
end for
14: end for
Algorithmus 1: Wide-Margin-Winnow-Algorithmus nach (Bekkerman u. a. 2004). Zeilen
9 und 11 wurden gegenüber der Originalpublikation geändert, da sie dort wahrscheinlich
fehlerhaft sind.
mit ca. 1,5 Minuten aus. Bei den erwähnten Experimenten wurden als Parameter t = 5
und e = α = δ = 0, 5 gewählt.
Andere Verfahren
Boone (1998) benutzt neuronale Netze und ein k-Nearest-Neighbour-Verfahren (kNN), um
Emails in die Kategorie Work und Other mit einer Accuracy um die 96%–97% einzusortieren. Diese Einteilung ist interessant für die Scope-Facette. In einem weiteren Experiment
wurden Emails in die 4 Kategorien Research, Interest, School und Fun einsortiert; hier erbrachte ein kNN-Verfahren eine Accuracy von 87%.
In ihren Experimenten benutzen Brutlag u. Meek (2000) auch einen auf Language Models basierten Unigram-Klassifizierer. Damit erreichen sie teilweise eine Accuracy von
über 90%.
Diao u. a. (2000) wenden einen Entscheidungsbaumalgorithmus (C4.5) zur EmailKlassifikation an und erreichen damit ähnliche Werte wie mit tf × idf .
kiib
33
4.1.3 Regelbasierte Ansätze
Eine andere Klasse von maschinellen Lernverfahren, die für die Email-Klassifikation interessant sind, sind regelbasierte Ansätze. Dabei wird aus einer Lernstichprobe eine Theorie
von Regeln gelernt, die dann zur Kategorisierung angewendet werden. Regeln haben dabei die Form
cfp95 ← subject("cfp") ∧ subject("1995");
die obige Regel könnte z.B. bedeuten, dass alle Emails, bei denen in der Subject-Kopfzeile
die Terme „cfp“ (für „Call for Paper“) und „1995“ vorkommt, automatisch in die Klasse
cfp95 (für „Call for Paper aus dem Jahre 1995“) einsortiert werden.
Regelbasierte Ansätze haben gegenüber den bisher behandelten maschinellen Lernansätzen den Vorteil, dass sie (je nach deren Repräsentation) relativ einfach nachzuvollziehen und auch zu modifizieren sind. Wie wir bereits festgestellt haben, ist die Aufgabe der
Email-Klassifikation eine sehr dynamische; Benutzerinteressen und Verteilung der Nachrichten können sich mit der Zeit ändern, so dass eine Mischung aus automatisch erstellten
und manuell modifizierten Regeln hier sinnvoll wäre (Cohen 1996).
Ein bei der Email-Klassifikation häufig anzufindener Regellerner ist RIPPER (Cohen
1995). Sind aus der Lernstichprobe eine Menge von positiven und negativen Beispielen
für eine Klasse gegeben, so lernt RIPPER dazugehörige Regeln in zwei Phasen (siehe auch
Cohen 1995):
1. In der Growing-Phase wird zunächst eine Regel aufgebaut, die möglichst viele positive Beispiele abdeckt. Beginnend mit einer leeren Konjunktion von Bedingungen,
wird eine Konjunktion der Form a1 ∧ . . . ∧ an aufgebaut.
2. In der Pruning-Phase wird nun versucht, die Regel zu generalisieren (um Überadaption vermeiden) und redundante Elemente zu entfernen.
Bleibt die gelernte Regel unter einer bestimmten Fehlerrate, wird sie der Regelmenge für
die Kategorie hinzugefügt und die von der Regel abgedeckten positiven Beispiele werden
aus der Lernmenge für diese Klasse entfernt. Der Algorithmus beginnt nun von neuem.
Ansonsten bricht der Algorithmus ab, wenn eine Regel mit zu hoher Fehlerrate gelernt
wurde oder keine positiven Beispiele für die zu lernende Klasse mehr vorhanden sind.
Sind alle Regeln gelernt, werden in einem Nachprozessierungsschritt noch weitere Optimierungen vollzogen.
Experimente Cohen (1996) wendet RIPPER zur Email-Klassifikation an. Dabei werden mehrere unterschiedliche Szenarien betrachtet. In einem Experiment sollen Vortragsankündigungen gefunden werden (ein interessantes Experiment hinsichtlich der
Document Type-Facette). In einem weiteren Experiment soll eine Einordnung in eine gegebene Folderstruktur vorgenommen werden, wobei die Folder teilweise mit dem jeweiligen Autoren korreliert oder semantisch definiert sind. Zu guter Letzt ging es darum,
34
eine Filterungsaufgabe zu lösen, um ungelesene Email zu priorisieren. In allen Experimenten zeigte sich sich RIPPER gegenüber dem in Abschnitt 4.1.2 beschriebenen tf × idf Verfahren zumindest gleichwertig, wenn nicht sogar besser1 . Dabei ist eine signifikante
Verminderung der Fehlerrate schon bei (realistischen) 100 Trainingsbeispielen zu beobachtet, und es reichen anscheinend 200 Beispiele, um RIPPER geeignet lernen zu lassen.
Die Resultate bezüglich der Fehlerraten werden indirekt auch durch Crawford u. a. (2001)
unterstützt. Dort wird zwar nicht RIPPER benutzt, aber durch den RIPPER-ähnlichen
FOIL-Klassifizierer eine Accuracy von 72% erreicht, verglichen mit 68% bei tf × idf . Allerdings wendet Provost (1999) das RIPPER-Verfahren im Vergleich mit Naïve Bayes an
und kommt dabei auf das Ergebnis, dass NB effektiver ist (RIPPER: 78% Accuracy nach
400 Trainingsbeispielen (NB: 87%), 67% Accuracy nach 175 Beispielen (NB: 80%)). Dieses
Resultat ist aber vor dem Hintergrund des generell eher schlechten Abschneidens von NB
überraschend.
4.1.4 Zusammenfassung der bisherigen Klassifikationsverfahren
Bei der abschließenden Bewertung der bisher vorgestellten Email-KategorisierungsVerfahren aus der klassischen Textkategorisierung bzw. aus den regelbasierten Ansätzen
muss man die jeweils zu Grunde liegenden Testkollektionen mit berücksichtigen. So hat
die Freigabe des Enron-Korpus für einen Schub neuer Experimente gesorgt, da nun eine
repräsentative Kollektion vorliegt, die hinsichtlich der Menge der zur Verfügung stehenden Mailboxen weit über die persönlichen Mailboxen oder Diskussionslisten, auf denen
sonst Experimente durchgeführt wurden, hinausgeht. Dadurch ist eine große Fülle unterschiedlicher Mailboxtypen abgebildet, die die subjektiven Kriterien der Benutzer beim
Anlegen einer persönlichen Folderstruktur reflektieren. Die Experimente von Bekkerman
u. a. (2004) gehen dabei vom bisher realistischsten Szenario aus, indem sie auch die temporären Aspekte in der Entwicklung einer Mailbox in Betracht ziehen. In vielen Experimenten wird auch versucht, die eine beste Kategorie für eine Email zu finden. Bei einer
semi-automatischen Klassifikation macht es aber Sinn, dem Benutzer mehrere Folder zur
Auswahl zu stellen, wie dies im MailCat-System geschieht (Segal u. Kephart 1999). Mehr
Experimente auf dem Enron-Korpus, gerade auch der regelbasierten Verfahren, sind aber
nötig. Folgende (vorläufige) Schlüsse kann man aber dennoch ziehen:
• Die Email-Klassifikation unterscheidet sich von der Textklassifikation, da wir es hier
mit sehr heterogenen Kriterien beim Anlegen eines Kategorienschemas zu tun haben, und das Ablegen von Emails in diese Struktur ein äußerst dynamischer Prozess
ist. Das Folderschema sowie deren Inhalt sind ständigen Veränderungen unterzogen, die das Kategorisierungsverfahren zu berücksichtigen im Stande sein sollte.
Auch die Füllmenge der Folder ist sehr unterschiedlich; einige können annähernd
leer sein, während andere mit eventuell tausenden Emails gefüllt sind.
• Es kristallisiert sich heraus, dass Support Vector Machines, wie schon in der Textklassifikation, die zumeist besten Kategorisierungsergebnisse erzielen. Dennoch
1 Es
kiib
werden in (Cohen 1996) keine Accuracy oder f 1 -Maße angegeben, sondern nur allgemein die Fehlerrate
35
4.2 MÖGLICHE NEUE ANSÄTZE
sind unter anderen Aspekten auch andere Klassifizierer interessant. tf × idf arbeitet
inkrementell, d.h. sobald eine neue Email in einen Folder einsortiert wird, kann
tf × idf sich an die neue Situation schnell anpassen. Auch der Wide-Margin-WinnowKlassifizierer liefert gute Ergebnisse und ist dabei SVM geschwindigkeitsmäßig voraus. Die jeweilige Anwendung entscheidet dabei, welchen der Kriterien das größte
Gewicht zu geben ist.
• Regelbasierte Ansätze liefern eine interessante Alternative zu den anderen Verfahren, da sich hier die Kategorisierungsentscheidung besser erklären lässt und Regeln
auch manuell verändert bzw. neu angelegt werden können. Der Benutzer selbst bekommt also die Kontrolle über das Geschehen. Die bisherigen Experimente legen
nahe, dass eventuelle Einbußen (wenn vorhanden) in der Kategorisierungsqualität
minimal sind, auch wenn diese Aussage noch einiger Untersuchung bedarf.
4.2 Mögliche neue Ansätze
Die in Abschnitt 4.1 angesprochenen Verfahren sind alle schon einmal in verschiedenen
Email-Klassifizierungs-Szenarios angewendet worden. An dieser Stelle wollen wir nun
Verfahren beschreiben, von denen wir glauben, dass sie zur Email-Kategorisierung geeignet sind, die aber noch nicht für diese Aufgabe benutzt oder evaluiert wurden. Wir
legen dabei unser Hauptaugenmerk auf probabilistische, entscheidungsorientierte Verfahren und Methoden zum automatischen Lernen probabilistischer Regeln.
4.2.1 Probabilistische, entscheidungsorientierte Verfahren
Probabilistische, entscheidungsorientierte Ansätze wurden ursprünglich zur Indexierung
im Information Retrieval eingesetzt (Fuhr u. Buckley 1991). Dabei geht man hier von
Dokument-Term-Paaren (t, d) aus. Im klassischen probabilistischen Retrieval wird nun
die Wahrscheinlichkeit P( R|t, d), dass ein mit Term t indexiertes Dokument d relevant
(R) ist, berechnet. Diese Vorgehensweise basiert aber nur auf das Vorkommen und NichtVorkommen eines Terms im Dokument und eventuell noch auf dessen Häufigkeit. Gerade für semi-strukturierte Daten, wie wir sie bei Emails vorliegen haben, ist es interessant, auch die Eigenschaften (Features) eines Terms zu berücksichtigen, wie ja auch in
einigen der oben erwähnten Klassifikationsverfahren schon geschehen ist. Solche Eigenschaften können z.B. das Vorkommen eines Terms in der Betreffzeile der Email sein,
aber auch dessen Häufigkeit im Email-Body. Auch können dokumentspezifische Eigenschaften definiert werden, wie z.B. das wiederholte Auftreten gewisser Satzzeichen (z.B.
„!!!!!“). Man sieht also, dass solche Eigenschaften eine komplexere Beschreibung einer Email ermöglichen. Es wird also zunächst mal aus dem Dokument-Term-Paar (t, d) in
der Beschreibungsphase eine Relevanzbeschreibung erzeugt, die aus einem Eigenschaftvektor
~x (t, d) besteht. Jede Koordinate dieses Vektors kodiert eine Eigenschaft des Terms im Dokument oder eine Dokumenteigenschaft. Beispielsweise könnte für ~x (t, d) = ( x1 , x2 , x3 )
dann x1 ∈ {0, 1} das Vorkommen von t im Email-Subject kodieren, x2 ∈ [0, 1] könnte
36
Term-Dokument-Paar
Prob. Indexierungsgewicht
(t, d)
P( R|t, d)
-
P( R|~x (t, d)) ≈ idx (~x (t, d))
@
@
@
Beschreibung @
R
@
*
Entscheidung
~x (t, d)
Relevanzbeschreibung
Abbildung 4.2: Indexierung beim beschreibungsorientierten Ansatz
die normierte Häufigkeit von t im Dokument und x3 ∈ [0, 1] die normierte Dokumentlänge darstellen. In einem nächsten Schritt wird mittels eines Regressionsverfahrens in
der Entscheidungsphase die Wahrscheinlichkeit P( R|~x (t, d)) durch eine Indexierungsfunktion idx (~x (t, d)) abgeschätzt. Um welche Art Funktion (Polynom, logistische Funktion) es
sich bei idx handelt, hängt dabei vom verwendeten Regressionstyp ab. Wurde idx nun aus
der Lernstichprobe ermittelt, so berechnet idx (~x (t, d)) ∈ R das Termgewicht des Terms t
in Dokument d. Dokumente (und wie wir später sehen werden auch Kategorien bzw. Folder) werden letztendlich also als Vektoren von Termgewichten repräsentiert. Der Prozess
ist noch einmal in Abbildung 4.2 illustriert.
Wir wollen nun einige Möglichkeiten zur Bestimmung von idx mittels Regression betrachten. Dazu betrachten wir zunächst den Aufbau der Lernstichprobe. Dieser liegt ein
spezieller Begriff der Relevanz zwischen zwei Dokumenten zu Grunde:
Definition. Bezeichne D die Menge der Dokumente. d ∈ D ist relevant (R) zu d0 ∈ D ,
wenn sich d und d0 in derselben Kategorie befinden, und nicht-relevant (R) sonst. Die Funktion r : D × D −→ { R, R} bestimmt dabei die Relevanz zwischen zwei Dokumenten.
Mit diesem Begriff der Relevanz können wir nun unsere Lernstichprobe definieren. Zunächst mal sei
L=
d, d0 , r d, d0
|d, d0 ∈ D .
Die Lernstichprobe selbst ist eine Multimenge von Relevanzbeschreibungen mit Relevanzurteilen:
L x = [(~x (t, d), r (d, d0 ))|t ∈ d T ∩ d0T ∧ (d, d0 , r (d, d0 ) ∈ L]
wobei d T die Menge der in d vorkommenden Terme ist.
kiib
37
Beispiel. Legt man folgende Relevanzbeschreibung für Emails zu Grunde
x1 (t, d) = normierte Termhäufigkeit (nt f ) des Terms t in d
(
1 wenn t im Subject-Header von d enthalten ist,
x2 (t, d) =
0 sonst.
und hat man die drei Emails d1 , d2 und d3 , die aus den Termen {t1 , t2 }, {t2 , t3 , t4 } und
{t1 , t4 } bestehen, bekommt man beispielsweise die in Tabelle 4.1 dargestellte Stichprobe.
Man erhält in diesem Fall also
! !
! !
! !
! !
! !#
"
! !
1
2
1
2
1
1
,R ,
,R ,
,R ,
,R ,
,R
.
Lx =
,R ,
1
0
1
0
0
1
In diesem simplen Beispiel kann man die Schätzung für P( R|~x (t, d)) für einige Ausprägungen von ~x (t, d) sehr leicht ablesen: P( R|(2, 0)) = 1/2, P( R|(1, 1)) = 1/3.
d
d0
t ∈ d T ∩ d0T
d1
d2
d1
d3
d2
d3
d2
d1
d3
d1
d3
d2
t2
t2
t1
t1
t4
t4
~x
(1,1)
(1,1)
(2,0)
(1,1)
(2,0)
(1,0)
r (d, d0 )
R
R
R
R
R
R
Tabelle 4.1: Beispiel einer Stichprobe
Lineare Regression
Um aus der Lernstichprobe nun die Indexierungsfunktion zu berechnen, wird in z.B. in
Gövert u. a. (1999) eine lineare Regression nach der Methode der kleinsten Quadrate vorgenommen. Sei dabei zunächst mal
(
1 wenn r (d, d0 ) = R,
y = y(d, d0 ) =
0 sonst.
die Klassenvariable y. Es soll nun der mittlere quadratische Schätzfehler minimiert werden;
Optimierungskriterium ist also
!
E((y − idx (~x ))2 = min .
38
(E ist der Erwartungswert). i wird mit Hilfe einer Polynomstruktur ~v(~x ) und eines Koeffizientenvektors ~a als Polynom ausgedrückt:
idx (~x ) = ~a T · ~v(~x )
Für ~v(~x ) = (1, x1 , x2 )T und ~a = ( a1 , a2 , a3 )T würde man z.B. das Polynom a1 + a2 x1 + a3 x2
als Schätzfunktion bekommen. Berücksichtigt man das o.g. Optimierungskriterium, so
kann man mittels des linearen Gleichungssystems
E(~v · ~v T ) ·~a = E(~v · y)
~a berechnen. Siehe auch (Frommholz 2001, Kapitel 4.1) für eine ausführlichere Beschreibung der Methode. Im vorliegenden Beispiel würde man als Indexierungsfunktion
1
1 1
idx (~x ) = − + x1 + x2
2 2
3
bekommen.
Logistische Regression
Bei der logistischen Regression erfolgt die Abschätzung von P( R|~x ) nicht mittels eines
Polynoms, sondern durch die Formel
~ T~x
P( R|~x ) ≈ idx (~x ) =
eb
1 + e~b
T~
x
=
eb0 +b1 x1 +...+bn xn
1 + eb0 +b1 x1 +...+bn xn
Dabei ist ~b = (b0 , b1 , . . . , bn )T der gesuchte Parametervektor und ~x = (1, x1 , . . . , xn )T ein
Eigenschaftsvektor. Die logistische Funktion nimmt einen S-förmigen Verlauf an durch
den man sich eine bessere Approximation der Klassenvariable y erhofft als durch die lineare Regression, zumal die logistische Funktion sehr flexibel ist.
Zur leichteren maschinellen Berechnung der Wahrscheinlichkeitsabschätzung kann
man obige Formel umwandeln, indem man den Begriff der Odds einführt. Mit O( A) =
P( A)/P( A) für ein Ereignis A bekommt man
O( R|~x ) = eb0 +b1 x1 +...+bn xn .
Dies kann man nun logarithmieren und erhält die so genannten Logodds:
log O( R|~x ) = b0 + b1 x1 + . . . + bn xn .
Es reicht völlig aus, die Logodds zu berechnen. Bei Bedarf können die so erhaltenen Werte
in die tatsächlichen Wahrscheinlichkeitsabschätzungen überführt werden.
Zur Ermittlung von idx wird nun zunächst ~b als Argument der Indexierungsfunktion hinzugefügt, so dass wir idx (~x,~b) bekommen. Sei nun L x eine solche Lernstichprobe und t = | L x |, d.h. t beschreibt die Anzahl der vorhandenen Stichprobenelemente.
X = {~
x1 , . . . , ~
xt } ist die Menge der Relevanzbeschreibungen und Y = {y1 , . . . , yt } die
Menge der dazugehörigen Relevanzurteile in der Stichprobe. Es gibt nun zwei Möglichkeiten, den gesuchten Parametervektor ~b zu finden: eine Maximum-Likelihood- und eine
Least-Square-Regression. Beide basieren dabei auf unterschiedlichen Optimierungskriterien, wie wir im Folgenden beschreiben.
kiib
39
Logistische Maximum-Likelihood-Regression Hier geht es darum, die so genannte
Likelihood-Funktion (Fuhr u. Pfeifer 1991)
L(~b) =
∏ idx(~xi ,~b) · ∏ (1 − idx(~xi ,~b))
y i =0
y i =1
t
=
∏ idx(~xi ,~b)y
i
· (1 − idx (~xi ,~b))1−yi
i =1
zu maximieren. Das Optimierungskriterium für die optimale logistische Regressionsfunktion ist daher
!
L(~b) = max .
Im weiteren Verlauf wird die logarithmische Likelihood-Funktion l (~b) = log L(~b) betrachtet. Es ergibt sich
l (~b) =
t
∑ yi · log idx(~xi ,~b) + (1 − yi ) · log(1 − idx(~xi ,~b)).
i =1
Das Optimierungskriterium hat als notwendige Bedingung, dass die Ableitungen von l
nach den Komponenten b j aus ~b gleich 0 sind, d.h.
t
∂l
= ∑ (yi − idx (~xi ,~b)) xi j = 0.
∂b j
i =1
Da diese Gleichung normalerweise nicht direkt gelöst werden kann, wird das iterative
Newton-Raphson-Verfahren zu dessen Lösung benutzt (Fuhr u. Pfeifer 1991; Pfeifer 1990;
Pollmann 1993). Siehe auch (Frommholz 2001, Kap. 5.1.2) für weitere Details.
Logistische Least-Square-Regression Hier wird das gleiche Optimierungskriterium
verwendet wie bei der linearen Regression. Als Ziel kann also formuliert werden:
R(~b) =
t
∑ (idx(~xi ,~b) − yi )2 = min .
!
i =1
Auch hier muss wieder die Ableitung von R(~b) nach den Komponenten von ~b gleich 0
sein. Es ist ((Pollmann 1993, Kap. 3.2.3))
t
∂R
= 2 · ∑ (idx (~xi ,~b) − y · idx (~xi ,~b) − idx (~xi ,~b)3 + y · idx (~xi ,~b)2 ) · xi j = 0
∂b j
i =1
Es wird wiederum das Newton-Raphson-Verfahren benutzt, um die Gleichung zu lösen
(Frommholz 2001, Kap. 5.1.2).
40
Klassifizierungsfunktionen
Hat man die Indexierungsfunktion idx mittels linearer oder logistischer Regression aus
der Lernstichprobe ermittelt, wird diese nun benutzt, um Dokumente zu indexieren, wobei dann jedes als Vektor d~ = (wt1 , . . . , wtn ) von Termgewichten dargestellt wird (mit n
als Anzahl der in der Kollektion vorhandenen Termen und wti = 0 wenn ti im Dokument nicht vorkommt). Dies bedeutet, dass für jedes neu zu kategorisierenden Dokument
(Email) d~ die Features zu extrahieren, der Eigenschaftsvektor ~x (t, d) für jedes DokumentTerm-Paar aufzubauen und daraus mittels idx dann das jeweilige Termgewicht zu berechnen ist, um d~ zu erhalten. Wie aber können wir nun die indexierten Dokumente benutzen,
um an eine Klassifikationsentscheidung zu kommen?
k-Nearest-Neighbour Gövert u. a. (1999) wenden eine probabilistische Variante von kNearest-Neighbour (kNN) (Yang 1994) an. Es wird die Wahrscheinlichkeit P(d → C ), dass
das zu klassifizierende Dokument d die Kategorie C impliziert, ermittelt2 . Dazu wird zunächst einmal die Wahrscheinlichkeit
P(d → d0 ) =
∑
t
P(d|t) P(t)
P ( d 0 | t ).
P(d)
berechnet, die ein Ähnlichkeitsmaß für die beiden Dokumente d und d0 darstellt. Die Menge NN definiert sich dann als die Menge der k Dokumente d0 , die den höchsten Wert für
P(d → d0 ) aufweisen. P(t) wird durch die inverse Dokumentenhäufigkeit (idf ) des Terms t
approximiert3 , P(d) ist ein Normalisierungsfaktor (mit ∑t P(t|d) = 1). P(d|t) und P(d0 |t)
sind die mit idx ermittelten Termgewichte. Darauf aufbauend berechnet man nun
P(d → C ) ≈
∑
P(d0 | NN ) · P(d → d0 ) · P(d0 → C ),
(4.5)
d0 ∈ NN
wobei P(d0 | NN ) ein Normalisierungsfaktor ist (mit ∑d0 ∈ NN P(d0 | NN ) = 1)). P(d0 → C )
ist 1, wenn d0 in Kategorie C ist, und 0 sonst.
Megadokumente Ein anderer möglicher Klassifizierer ist in (Frommholz 2001,
Kap. 8.3) beschrieben. Hierbei kommt der in (Klas u. Fuhr 2000) erwähnte
Megadokumenten-Ansatz (der ja dem in Abschnitt 4.1.2 geschildertem tf × idf -Klassifizierer
ähnlich ist) in Kombination mit Regressionsalgorithmen zum Einsatz. Jede Kategorie (jeder Folder) C wird dabei als einzelnes Megadokument MC aufgefasst, das sich aus dem
Verschmelzen der in dem Folder befindlichen Emails ergibt. Es ist nun
P ( d → C ) = P ( d → MC ) =
∑
t
P(d|t) P(t)
P ( Mc | t ) .
P(d)
Bei diesem Ansatz ist zu beachten, dass wir die Lernstichprobe zum Erlernen von idx
etwas anders aufbauen müssen. Zunächst mal haben wir es mit einem leicht veränderten
2 Zur
Erläuterung des Implikationsbegriffes siehe auch van Rijsbergen (1986)
fallen Terme, die nur in wenigen Dokumenten vorkommen, stärker ins Gewicht
3 Dadurch
kiib
41
Relevanzbegriff zu tun – ein Dokument d ist relevant zu einem Megadokument MC wenn
es zu der von M repräsentierten Klasse C gehört. Die Lernstichprobe ist nun aufzuteilen in
die Menge M der Lern-Megadokumente und die Menge D der Lerndokumente. Daraus
ergibt sich als neue Lernmenge
L = {( M, d), r ( M, d))| M ∈ M, ∈ D} .
Daraus kann man nun die eigentliche Lernstichprobe bilden. Mit
L xM = [(~x (t, M), r ( M, d))|t ∈ M T ∩ d T ∧ ( M, d, r ( M, d)) ∈ L]
und
Ldx = [(~x (t, d), r ( M, d))|t ∈ M T ∩ d T ∧ ( M, d, r ( M, d)) ∈ L]
ist
L x = L xM ∪ Ldx .
L xM beinhaltet die Features von Termen in Megadokumenten, während Ldx jene von Termen
in Einzeldokumenten enthält. Man beachte hierbei, dass ein Megadokument und ein Dokument wahrscheinlich unterschiedliche Größen haben, was u.U. die Vergleichbarkeit der
jeweiligen Eigenschaftswerte verschlechtert (man denke nur an das Feature „Dokumentlänge“, das für Dokumente und Megadokumente sehr unterschiedlich ausfallen dürfte).
Von daher kann es sinnvoll sein, statt einer Indexierungsfunktion idx, die auf L x basiert,
zwei Indexierungsfunktionen idx M und idxd für Megadokumente und Einzeldokumente
zu lernen, die dann auf L xM und Ldx basieren. Es ist eine offene Frage, inwiefern solch eine
Unterscheidung zu veränderten Ergebnissen bei der Kategorisierung führt.
Das Probability-Ranking-Prinzip zur Email-Kategorisierung
Die hier vorgestellten probabilistischen, entscheidungsorientierten Verfahren erstellen für
eine neue Email d ein Ranking von Kategorien C absteigend nach ihrer Implikationswahrscheinlichkeit P(d → C ). Inwiefern produziert diese Vorgehensweise nun ein optimales
Ranking? Aus dem Information Retrieval kennen wir die von Robertson (1977) vorgestellte entscheidungstheoretische Rechtfertigung des Probability-Ranking-Prinzips; dieses
besagt, dass für eine Anfrage q ein Ranking nach absteigendem P( R|q, d) für ein Dokument d optimal ist. Wir definieren nun den Begriff der Relevanz für die Kategorisierungsaufgabe derart, dass ein Dokument zu einer Kategorie genau dann relevant ist, wenn es
unter dieser einzuordnen ist. Probabilistische Kategorisierungsverfahren berechnen dann
die Wahrscheinlichkeit P( R|C, d), dass eine Kategorie C zu einem Dokument d relevant
ist. Um zu zeigen, dass ein nach dieser Wahrscheinlichkeit sortiertes Ranking optimal ist,
definieren wir zunächst einmal einige Kostenmaße. Wir gehen dabei davon aus, dass die
Kategorisierung von Emails auf Basis der vom System mittels des erstellten Rankings angebotenen Kategorien zu einer Email dem Benutzer Kosten in Form des benötigten Auf-
42
wands verursacht. Daraus ergeben sich nun folgende Kostenmaße:
cr := Kosten des Anbietens einer relevanten Kategorie
c̄r := Kosten des Anbietens einer nicht-relevanten Kategorie
co := Kosten des Auslassens einer relevanten Kategorie
c̄o := Kosten des Auslassens einer nicht-relevanten Kategorie
Weiter definieren wir die erwarteten Kosten für das Anbieten einer Kategorie als
ECr (C, d) = P( R|C, d) · cr + (1 − P( R|C, d)) · c̄r
und für das Auslassen
ECo (C, d) = P( R|C, d) · co + (1 − P( R|C, d)) · c̄o .
Dabei kann man prinzipiell mit Kategorie-spezifischen Kosten arbeiten; wir gehen an dieser Stelle aber davon aus, dass die Kosten für das Anbieten und Auslassen für jede Kategorie gleich sind, da ansonsten die Vereinfachung auf die reine Betrachtung der Wahrscheinlichkeit wegfällt. cr , c̄r , co und c̄o sind in unserem Fall also konstant.
Grundsätzlich geht es darum, die erwarteten Kosten für den Benutzer zu minimieren.
Dies kann dazu führen, dass wir die Anzahl der Kategorien, die dem Benutzer zur EmailKlassifikation vom System angeboten werden, dynamisch halten (im Gegensatz z.B. zu
den in Abschnitt 4.1.2 beschriebenen Experimenten, wo dem Benutzer eine, drei oder
fünf Kategorien angeboten wurden, dieser Wert aber a priori festgelegt wurde). Aus Kostensicht ist das Kriterium, wieviele und welche Kategorien angeboten werden, definiert
durch
ECr (C, d) < ECo (C, d),
d.h. wir bieten nur jene Kategorien an, für die es erwartungsgemäß teurer wäre, sie nicht
anzubieten. Wir gehen dabei davon aus, dass cr , c̄r , co und c̄o unabhängig von der Anzahl
der vorgeschlagenen Kategorien sind. Ferner gehen wir davon aus, dass cr < c̄r < co
sowie c̄o = 0 ist. Wird eine nicht-relevante Kategorie ausgelassen, so entstehen dem Benutzer dadurch keine Kosten. Auf der anderen Seite ist der erwartete Aufwand am geringsten, wenn dem Benutzer eine relevante Kategorie präsentiert wird und er diese z.B.
mittels eines einfachen Mausklicks zuweisen kann. Der Aufwand für nicht-relevante Kategorien ist höher, da der Benutzer an diesen nicht interessiert ist4 . Am höchsten sind
die Kosten für das Auslassen relevanter Kategorien, da der Benutzer diese mühsam auf
anderem Wege suchen muss. Wegen des obigen Kostenkriteriums ist es sinnvoll, die Kategorien nach aufsteigendem ECr (C, d) zu ranken. Wir bekommen somit eine Rangordnung
4 Das
Anbieten einer nicht-relevanten Kategorie mag für dein Benutzer an sich sehr wenig Aufwand bedeuten, aber auf der anderen Seite hat er davon auch keinen Ertrag – ansonsten wäre es am billigsten,
dem Benutzer nur nicht-relevante Kategorien vorzuführen, was die vorliegende Problematik ad absurdum führen würde.
kiib
43
von l Kategorien C1 , . . . , Cl mit ECr (Ci , d) ≤ ECr (Ci+1 , d) für i = 1, . . . , l − 1. Wegen cr < c̄r
gilt:
ECr (Ci , d) ≤ ECr (Ci+1 , d)
⇔
P( R|Ci , d) · cr + (1 − P( R|Ci , d)) · c̄r ≤ P( R|Ci+1 , d) · cr + (1 − P( R|Ci+1 , d)) · c̄r
⇔
P( R|Ci , d) (cr − c̄r ) < P( R|Ci+1 , d) (cr − c̄r )
| {z }
| {z }
<1
⇔
<1
P( R|Ci , d) ≥ P( R|Ci+1 , d).
Die von den Kategorisierungsverfahren ermittelte Wahrscheinlichkeit P(d → C ) lässt
sich frei nach van Rijsbergen (1992) auf P( R|C, d) abbilden:
P( R|C, d) = P( R|d → C ) · P(d → C ) + P( R|¬(d → C )) · P(¬(d → C ))
= f ( P(d → C )).
f wird dabei als monoton steigend angenommen. Nottelmann u. Fuhr (2003) ermitteln
mögliche Abbildungsfunktionen f mittels linearer und logistischer Regressionsverfahren.
Beurteilung der entscheidungsorientierten Verfahren
Die probabilistischen, entscheidungsorientierten Verfahren ermitteln die Wahrscheinlichkeit P(d → C ). Wir haben gezeigt, dass ein auf diesen Wahrscheinlichkeiten aufbauendes
Ranking potentiell den Kategorisierungsaufwand des Benutzers minimieren kann.
Wird eine Email nun vom Benutzer in einen Folder geschoben, kann diese im kNNAnsatz sofort dem Index hinzugefügt werden, zusammen mit Informationen über deren
Klassenzugehörigkeit. Die so hinzugefügte Email wird damit sofort zur Klassifizierung
einer nachfolgenden Email berücksichtigt. Im Megadokumenten-Ansatz müsste zunächst
mal das Megadokument für den jeweiligen Folder aktualisiert und neu indexiert werden
werden. Wie aufwändig dieser Prozess ist, hängt in beiden Fällen von den zu wählenden
Features ab – sind sie leicht zu extrahieren, wird eine inkrementelle Indexierung effizient durchzuführen sein. Da die Indexierungsfunktion im Grunde genommen die Wichtigkeit eines Features beim Klassifizierungsprozess ermittelt, ist damit zu rechnen, dass
diese nicht sehr häufig neu berechnet werden muss. Es wird vermutlich ausreichen, sie
periodisch neu zu berechnen. Dies ist erfreulich im Hinblick auf die Tatsache, dass die
Berechnung der Indexierungsfunktion durch Regression höchst wahrscheinlich einige Rechenzeit kosten wird.
Die probabilistischen, entscheidungsorientierten Verfahren können potentiell für alle in
Abschnitt 3.2 vorgestellten Facetten eingesetzt werden. Die Möglichkeit, für jede Facette unterschiedliche Features zu bestimmen, machen die Verfahren zu einem universellen
Werkzeug. Welche Features dabei bei welcher Facette Sinn machen, bedarf einer genaueren Analyse der Email-Kollektion hinsichtlich der einzelnen Facetten.
44
4.2.2 Dr. Holthausen-Netzwerke
Das in der Offenlegungsschrift (Holthausen u. a. 2000) beschriebene Verfahren, das wir
hier Dr. Holthausen-Netzwerke nennen, ist ein Retrieval-Verfahren, das die semantische
Ähnlichkeit von Dokumenten benutzt, um dem Benutzer ein erweitertes Suchergebnis
zu liefern. Dabei ist bisher nicht bekannt, dass die Offenlegungsschrift auch tatsächlich
zum Patent angemeldet wurde. Das Verfahren soll hier zunächst erläutert werden. Danach diskutieren wir die Anwendung des Verfahrens auf die Email-Klassifikation und die
mögliche Kombination mit probabilistischen, entscheidungsorientierten Verfahren.
Beschreibung des Verfahrens
Dr. Holthausen-Netzwerke wurden ursprünglich zur Dokumentsuche eingesetzt. Die
Idee hierbei ist, nicht nur Dokumente zu präsentieren, die die benötigten Suchbegriffe
enthalten, sondern auch dazu ähnliche Dokumente. Dadurch können dem Benutzer potentiell relevante Dokumente präsentiert werden, ohne dass diese die Suchbegriffe enthalten.
Wir gehen nun davon aus, dass eine boolesche Suche eine Anzahl K von Dokumenten gefunden hat, die die vom Benutzer gegebenen Suchbegriffe enthalten. Das System
erzeugt nun eine Rangordnung der gefundenen Dokumente nach ihrem relativen Informationsgehalt (s.u.). Zusätzlich dazu werden Dokumente ermittelt, die ähnlich zu denen
in der Rangordnung sind; diese werden nach ihrer Ähnlichkeit zu den im Ursprungsranking vorkommenden Dokumenten sortiert.
Sei D = {d j |1 ≤ j ≤ K } die Menge der K zurückgelieferten Dokumente. Die Menge
T = {ti |1 ≤ i ≤ n} ist die Menge der n in der D vorkommenden Terme. Ferner sei die
relative Häufigkeit des Terms ti in d j wird berechnet als normierte Termfrequenz
F ( ti , d j ) =
N ( ti , d j )
,
N (d j )
wobei N (ti , d j ) angibt, wie oft ti in d j vorkommt, und N (d j ) die Anzahl Terme in d j ist.
Zudem sei noch
F ( t i ) = ∑ F ( t i , d j ).
j
Dann ergibt sich das Informationsmaß I (t j ) als
I (ti ) = ln(K ) + ∑
j
F ( ai , d j )
F ( ai , d j )
· ln(
).
F ( ti )
F ( ti )
Für einen seltenen Term würde I einen Maximalwert annehmen; für Stoppwörter würde
I gegen 0 gehen. Als nächstes berechnen wir den relativen Informationsgehalt G (ti , d j ) eines
Dokuments d j bezüglich eines Terms ti wie folgt:
G ( t i , d j ) = I ( t i ) F ( t i , d j ).
kiib
45
Daraus bekommen wir den gemeinsamen relativen Informationsgehalt
GI (d j , dk ) = I (ti ) F (ti , d j ) F (ti , dk )
welcher die Ähnlichkeit zweier Dokumente bezüglich eines Terms ti angibt. Durch Aufsummierung aller Begriffe ti in der Kollektion erhalten wir
S ( d j , d k )2 =
∑ I ( a i ) F ( t i , d j ) F ( t i , d k ),
i
das Ähnlichkeitsmaß S zweier Dokumente d j und dk . F kann dabei zum Indexierungszeitpunkt berechnet werden, während wir I effizient aus der Anzahl K der im ersten Schritt
gefundenen Dokumente ermitteln können. Das obige Verfahren kann auf der Basis neuronaler Netzwerke implementiert werden, daher auch sein Name.
Das Dr. Holthausen-Netzwerk kann nun auf verschiedene Art und Weise zum Retrieval genutzt werden. Zunächst können mittels einer booleschen Anfrage alle Dokumente,
die alle Suchterme enthalten gefunden werden; K ist dann die Anzahl dieser Dokumente.
Über das Informationsmaß I kann ein Ranking dieser Dokumente erzeugt werden. Ferner
können über das Ähnlichkeitsmaß S dem Benutzer zur Trefferliste semantisch ähnliche
Dokumente präsentiert werden. Es besteht aber auch die Möglichkeit, zu einem Referenzdokument ähnliche Dokumente zu suchen, indem man alle im Referenzdokument
enthaltenen Terme als Suchterme ansieht.
Email-Kategorisierung mit Dr. Holthausen-Netzwerken
Um die Dr. Holthausen-Netzwerke zur Email-Kategorisierung zu nutzen, kann man sich
den in Abschnitt 4.2.1 beschriebenen kNN-Ansatz nutzbar machen. Das zu kategorisierende Dokument wird als Anfrage gesehen. Daraus wird nun ein Ranking von Dokumenten
erzeugt, aus dem die ersten k Dokumente die Menge NN der nächsten Nachbarn bilden.
Aus diesen kann analog zu Gleichung (4.5) und den gegebenen Kategoriezuordnungen
der Dokumente eine Rangordnung der Kategorien zum zu klassifizierenden Dokument
erzeugt werden.
Des Weiteren besteht die Möglichkeit, die im letzten Abschnitt besprochenen probabilistischen, entscheidungsorientierten Ansätze mit Dr. Holthausen-Netzwerken zu verknüpfen. Anstatt F (ti , d j ) als relative Häufigkeit von ti in d j anzusehen, können wir hier
die gelernte Indexierungsfunktion nehmen und setzen
F (ti , d j ) = idx (~x (ti , d j )).
4.2.3 Lernen probabilistischer Regeln
Wie schon in Abschnitt 4.1.3 besprochen, sind regelbasierte Ansätze hilfreich, dem Benutzer die Kategorisierung transparent zu machen und ihn dazu selbst Regeln anlegen oder
modifizieren zu lassen. Wir haben es bei RIPPER und ähnlichen Verfahren jedoch mit einer
binären Entscheidung zu tun: entweder die Zugehörigkeit zu einem Folder wird inferiert,
46
oder nicht. Schön wäre es jedoch, auch hier eine Wahrscheinlichkeit, dass eine Email zu einem Folder/einer Kategorie gehört, zu berechnen. Dadurch wäre es dem System möglich,
ein Ranking von Foldern zu erstellen und die besten k Folder dem Benutzer zur Auswahl
zu stellen. Hier können Inferenzsysteme wie probabilistisches Datalog (pDatalog) (Fuhr 2000)
hilfreich sein, die unsicheres Wissen verarbeiten können.
Datalog ist eine Variante der Prädikatenlogik, die auf funktionsfreien Horn-Klauseln
basiert. Horn-Klauseln haben die Form {h, ¬b1 , . . . , ¬bn }, die in Datalog als Regel h ←
b1 ∧ . . . ∧ bn dargestellt werden. h ist dabei der Kopf der Regel und b1 ∧ . . . ∧ bn stellt den
Regelrumpf dar. h ist das Zielprädikat; jedes Prädikat aus {b1 , . . . , bn } ist ein so genanntes
Subziel. Prädikate können dabei Variablen und Konstanten enthalten; dabei werden Variablen durch Großbuchstaben ausgedrückt. Besitzt eine Regel weder Rumpf noch Variablen,
so ist es ein Fakt. In pDatalog kann nun jedem Fakt und jeder Regel eine Wahrscheinlichkeit
zugewiesen werden, die bei der Auswertung einer Regel berücksichtigt werden.
Beispielsweise könnten die Regeln
0.9
cfp95(D) ← subject(D,"cfp") ∧ subject(D,"1995")
(4.6)
0.6
cfp95(D) ← author(D,"mccoy") ∧ year(D,"1995")
(4.7)
besagen, dass eine Email (ausgedrückt durch die Variable D) mit einer Wahrscheinlichkeit
von 90% dem Ordner cfp95 zuzuordnen ist, wenn im Subject die Terme „cfp“ und „1995“
auftauchen. Die Email ist mit einer Wahrscheinlichkeit von 60% dem Ordner cfp95 zuzuordnen, wenn ein gewisser McCoy der Autor der Email ist und diese 1995 abgeschickt
wurde. Eine Email von McCoy aus dem Jahre 1995, die „cfp“ und „1995“ im Betreff hat,
würde mit einer Wahrscheinlichkeit größer als 90% in den Ordner cfp95 einsortiert werden. Durch den probabilistischen Charakter der Regeln hat der Benutzer die Möglichkeit,
weiteren Einfluss zu nehmen, etwa wenn klar ist, dass 95% der Emails von McCoy aus
1995 Calls for Papers sind; hier könnte der Benutzer die Wahrscheinlichkeit von 60% auf
95% anheben. Man sieht an diesem simplen Beispiel die Möglichkeiten, die probabilistische Regeln in Datalog hinsichtlich einer personalisierten Regelbasis bieten. Mit HySpirit5
existiert eine Implementierung von pDatalog (Fuhr u. Rölleke 1998).
Lernen von Regelgewichten
Ein probabilistisches Lernverfahren würde nun sowohl obige Regeln als auch deren Wahrscheinlichkeiten aus der Lernstichprobe lernen. Dabei ergibt sich ein zusätzliches Problem, wenn für ein Regelkopf p mehr als eine Regel formuliert wurde. Hat man z.B. die
Regeln p ← r1 und p ← r2 , so genügen uns nicht die Wahrscheinlichkeiten P( p|r1 ) und
P( p|r2 ), denn aus ihnen können wir immer noch nicht die Wahrscheinlichkeit P( p|r1 ∧ r2 )
ermitteln. Um also die korrekten Wahrscheinlichkeiten der Regel abschätzen zu können,
5 Eine
nichtkommerzielle Variante von HySpirit ist an der Queen Mary University of London zu beziehen
(siehe auch http://qmir.dcs.qmul.ac.uk/hyspirit.php). Die Firma Apriorie Ltd. bietet eine kostenpflichtige, aber in vielerlei Hinsicht effizientere kommerzielle Version. Eine alternative freie Implementierung von pDatalog ist das an der Universität Duisburg-Essen entwickelte PIRE (Nottelmann 2005).
kiib
47
benötigen wir die Einzelwahrscheinlichkeiten P( p|¬r1 ∧ ¬r2 ) P( p|r1 ∧ ¬r2 ), P( p|¬r1 ∧ r2 )
und P( p|r1 ∧ r2 ). Dabei macht die erste Wahrscheinlichkeit P( p|¬r1 ∧ ¬r2 ) wenig Sinn
und wird ignoriert. Allgemein formuliert: haben wir n Regeln mit dem Zielprädikat p gegeben, so sind 2n − 1 bedingte Wahrscheinlichkeiten zu berechnen (Nottelmann u. Fuhr
2001; Nottelmann 2001). Das System liefert also für die n Regeln mit Zielprädikat p 2n − 1
neue Regeln mit deren Wahrscheinlichkeiten zurück.
Generell haben wir es also mit dem Fall zu tun, dass es mehrere Regeln mit dem Zielprädikat p geben kann. In Datalog können diese Regeln die Form p( ~
X ) ← pi ( ~
X ) annehmen,
~
wobei X die sich in der Regel befindlichen Variablen bezeichnet. In dieser Notation wären
beispielsweise unsere obigen Regeln (4.6) und (4.7) dargestellt als
cfp95(D) ← cfp95_1(D)
cfp95(D) ← cfp95_2(D)
mit
cfp95_1(D) ← subject(D,"cfp") ∧ subject(D,"1995")
cfp95_2(D) ← author(D,"mccoy") ∧ year(D,"1995")
(hier wäre also ~
X = (D)). Für Zielprädikat p gibt es also eine Menge Φ = { p1 , . . . , pn }.
Wir definieren nun eine Funktion γ p : 2Φ → [0, 1] als
γ p ( A) := P( p( ~
X )|
^
a∈ A
a( ~
X) ∧
^
¬ a( ~X ))
a∈Φ\ A
und γ(∅) = 0. γ berechnet also für jede beliebige Kombination der pi die jeweilige Wahrscheinlichkeit, z.B.
γc f p95 ({cfp95_1}) = P(cfp95(D)|cfp95_1(D) ∧ ¬cfp95_2(D)).
Eine Hypothese h sei nun eine nichtleere Menge P von Regeln mit dem Zielprädikat p
und den dazugehörigen Werten γ p . Der Hypothesenraum H ist die Menge aller Hypothesen
h p . KB ist unsere zu Grunde liegende Wissensbasis, bestehend aus Regeln und Fakten.
EXAMPLES sei eine Routine, die vom Lernalgorithmus aufgerufen werden kann und ein
willkürliches Beispiel ~c und ein Label y ∈ {0, 1}, welches ein Beispiel als positiv (y = 1)
oder negativ (y = 0) markiert, aus der Lernstichprobe zurückliefert. Ferner sei EX =
{(~ci , yi )} die Menge der von EXAMPLES gelieferten positiven und negativen Beispiele.
Wir wollen nun anhand eines Beispiels die Abschätzung der γ-Gewichte verdeutlichen.
Beispiel. Angenommen, wir haben folgende Wissensbasis KB:
subject(d1,"cfp")
subject(d1,"1995")
subject(d2,"cfp")
48
subject(d2,"1995")
author(d3,"mccoy")
year(d3,"1995")
author(d4,"mccoy")
year(d4,"1995")
author(d5,"mccoy")
year(d5,"1995")
und bekommen von EXAMPLES die Menge EX mit folgenden positiven Beispielen:
cfp95(d1)
cfp95(d3)
cfp95(d5)
und folgenden negativen Beispielen:
cfp95(d2)
cfp95(d4)
cfp95_1 ist in 2 Fällen enthalten, nämlich für d1 und d2, da
cfp95_1(d1) ← subject(d1,"cfp") ∧ subject(d1,"1995")
cfp95_1(d2) ← subject(d2,"cfp") ∧ subject(d2,"1995").
Analog ist cfp95_2 in 3 Fällen enthalten; cfp95_1 ∧ cfp95_2 ist in keinem Fall enthalten. Wir schätzen nun γc f p95 ab, indem wir zunächst für alle Teilmengen A ⊆ P =
{cfp95_1, cfp95_2} die Menge EX A ermitteln, in denen A und nur A vorkommt, also
V
V
EX A = {(~ci , yi )| a∈ A a(~c) ∧ a∈ P\ A ¬ a(~c)}. Im Fall A = {cfp95_1} wären das alle beiden Testfälle, in denen cfp95_1 enthalten ist, da in ihnen cfp95_2 nicht enthalten ist.
Als Approximation von γc f p95 nehmen wir nun den Anteil positiver Beispiele in EX A am
Anteil Beispiele in EX A , also
|{(~ci , yi ) ∈ EX A |yi = 1}|
.
| EX A |
Wir bekommen dann γc f p95 (cfp95_1)
=
1/2 und γc f p95 (cfp95_2)
=
2/3.
Aus der Menge EX können wir auch den empirischen quadratischen Verlust aus der errechneten Hypothese h p ermitteln als
1
Ê =
| EX |
| EX |
∑ ( P(h p (~ci )) − yi )2
i =1
wobei P(h p (~ci )) z.B. mit HySpirit berechnet werden kann (Nottelmann u. Fuhr 2001). Algorithmus 2 zeigt die generische Struktur des Algorithmus learnOptimum, der ähnlich
wie oben gezeigt aus einer gegebenen Regelmenge die benötigten Gewichte γ berechnet.
kiib
49
Eingabe:
Zielprädikat p
Wissensbasis KB
Lernbeispiele EXAMPLES
Hypothesenraum H
Ausgabe:
Optimale Hypothese h ∈ H mit minimalem Verlust Ê = l
l←∞
2: for all h0 ∈ H do
3:
h00 ← learnGammas( p, h0 , KB, EXAMPLES)
4:
l 0 ← computeLoss(h00 , KB, EXAMPLES)
5:
if l 0 < l then
6:
l ← l0
7:
h ← h00
8:
if l = 0 then
9:
stop
10:
end if
11:
end if
12: end for
Algorithmus 2: Generische Struktur des Algorithmus learnOptimum (Nottelmann u.
Fuhr 2001)
1:
Lernen von probabilistischen Regeln
Wir haben skizziert, wie man aus einer gegebenen Menge Regeln deren Wahrscheinlichkeiten errechnen kann. Werden solche Regeln manuell angelegt, ist dies somit ausreichend. Aber wir wollen ja aus einer gegebenen Lernstichprobe neue probabilistische
Regeln zur Email-Kategorisierung lernen. In (Nottelmann u. Fuhr 2001) wird dazu ein
Ansatz aus der induktiven logischen Programmierung vorgeschlagen, den wir nun kurz
vorstellen wollen.
Der Kern des Verfahren besteht darin, zu einer Regel die direkte Spezialisierung zu generieren. In unserem Beispiel wäre
cfp95_1(D) ← subject(D,"cfp") ∧ subject(D,"1995")
eine direkte Spezialisierung von
cfp95_1(D) ← subject(D,"cfp"),
was wiederum eine direkte Spezialisierung von cfp95_1(D) ist. Eine (wenn auch nicht
die einzige) Möglichkeit, eine direkte Spezialisierung zu generieren, ist also das Hinzufügen neuer Literale. Algorithmus 3 beschreibt nun grob den Algorithmus zum Lernen
probabilistischer Regeln. Dieser ruft Algorithmus 2 auf, nachdem durch Spezialisierung
50
Eingabe:
Zielprädikat p
Wissensbasis KB
Lernbeispiele EXAMPLES
Anzahl zu lernender Regeln n
Ausgabe:
Regelsatz R, Verlustrate l
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
R←∅
l←0
for i ← l; i ≤ n; i ← i + 1 do
l←∞
r ← leere Regel für p
while better rule found do
H = { R ∪ {r 0 }| R0 direkte Spezialisierung vonr }
(hr , l ) ← learnOptimum( p, KB, EXAMPLES, H)
h ← h00
end while
R ← hr
end for
Algorithmus 3: Algorithmus zum Lernen von Regeln (Nottelmann u. Fuhr 2001)
neue Regeln generiert wurden. Für weitere Details verweisen wir auf (Nottelmann u. Fuhr
2001) und (Nottelmann 2001). Algorithmus 3 geht von einer leeren Regelmenge R für das
gesuchte Zielprädikat p aus. Daraus ergeben sich exponentiell viele Möglichkeiten, eine
direkte Spezialisierung zu finden, von denen die meisten unsinnig sind. Es sollte also in
Betracht gezogen werden, den Benutzer geeignete Startregeln definieren zu lassen.
Beurteilung der Regellern-Verfahren
Die Möglichkeit, Kategorisierungsregeln zu lernen und diese dann vom Benutzer nach
seinen Bedürfnissen anpassen zu lassen, ist sehr attraktiv für die Email-Klassifikation. Es
stellt sich aber die Frage, welche Ergebnisse vom Lernsystem zu erwarten sind. Zwar wurde der Ansatz in (Nottelmann 2001) mit gemischten Ergebnissen in der Textklassifikation
und Spamerkennung hinsichtlich der Effektivität getestet, doch steht eine Evaluierung mit
einer realistischen Email-Kollektion wie dem Enron-Korpus noch aus. Es wäre interessant,
in Zukunft solch eine Evaluierung durchzuführen und die Ergebnisse zu untersuchen.
Wie oben erwähnt wäre es sinnvoll, wenn Algorithmus 3 nicht mit einer leeren Regelmenge starten müsste, sondern der Benutzer ein paar Startregeln spezifizieren könnte.
Wie dies allerdings geschehen soll und wie solche Startregeln aussehen sollten, muss noch
untersucht werden.
kiib
51
4.2.4 Andere Verfahren
Pang u. a. (2002) benutzen Support Vector Machines zur Sentiment Classification. Dabei
geht es darum, aus einer Menge von Dokumenten herauszufinden, wie die jeweiligen
Autoren über ein gewisses Thema oder Produkt denken. Die hier gemachten Erfahrungen
sind für die Emotional Tone-Facette interessant.
Die Arbeiten im Bereich der Genre Classification bzw. Document Type Classification sind
interessant im Hinblick auf die Document Type-Facette. Beispiele hierfür werden u.A. in
(Semeraro u. a. 2001) und (Kim u. Ross 2006) gegeben.
Sebastiani (2002) gibt einen Überblick über weitere Textklassifizierungsverfahren.
5 Informationsextraktion
5.1 Überblick
Die Informationsextraktion (IE) kann grob als das Füllen von strukturierten Vorlagen (so
genannten Templates oder auch Frames) angesehen werden. Benutzer sind interessiert an
bestimmten Fakten eines bestimmten Bereichs, die vom System extrahiert werden sollen,
und die in den Frames als Slots dargestellt ist. Slot bestehen in der Regel aus AttributWerte-Paaren.
Grob besteht die Informationsextraktion aus zwei Schritten: der Definition des Templates durch den Benutzer, und dem Füllen des Templates durch das System (Abolhassani u. a. 2003). Grundsätzlich gibt es zwei Strategien bei IE-Ansätzen: im Knowledge Engineering-Ansatz werden Regeln zur Extraktion der gesuchten Information manuell durch
einen Knowledge-Engineer angelegt. In der Regel erfolgt dies iterativ, indem man mit simplen Regeln startet und diese dann verbessert. Dadurch können sehr effektive Regelsätze
definiert werden, was aber sehr arbeitsintensiv ist. Der Machine Learning-Ansatz benötigt
einen annotierten Korpus, der als Trainingsmenge gilt und aus der dann die benötigten
Regeln automatisch gelernt werden. Das Lernen kann dabei auch interaktiv geschehen, indem ein Benutzer die gelernten Regeln bestätigt oder ablehnt und daraufhin im nächsten
Iterationsschritt vom System neue Regeln gelernt werden.
Ein typisches IE-System besteht aus den folgenden 4 Blöcken (Abolhassani u. a. 2003;
Appelt u. Israel 1999):
1. In der Tokenisierung wird zunächst eine Wortsegmentierung durchgeführt.
2. Die morphologische und lexikalische Prozessierung erkennt nun inflektierte Wortformen
und führt ein Part-of-Speech-Tagging durch. Zusätzlich dazu kann eine NamedEntity-Recognition (s.u.) durchgeführt werden. Auch können hier strukturierte Einheiten wie Datum und Uhrzeit erkannt werden; meist genügen hier entsprechende
reguläre Ausdrücke.
3. Die syntaktische Analyse benutzt die Ausgabe der vorherigen Phase, um z.B. Gruppen
von Verben und Substantiven zu identifizieren. Meistens benutzt man hier einen so
genannten Shallow Parser.
4. Die Domänenanalyse beschäftigt sich mit dem eigentlichen Extrahieren der Fakten.
Hier gibt es generell zwei Probleme. Zunächst einmal müssen Koreferenzen aufgelöst
werden (Coreference Resolution), die dieselbe Entität oder Person beschreiben (z.B.
„IBM“, „International Business Machines, „Big Blue“ oder auch „William H. Gates“,
53
5.1 ÜBERBLICK
„Bill Gates“, „Mr. Gates“, usw). Ein anderes Problem besteht in der Auflösung von
Anaphern.
Cunningham (1999) unterscheidet zwischen fünf Typen der Informationsextraktion:
• Die Named Entity Recognition findet und klassifiziert Personen, Orte, Produkte oder
Firmen. Hierzu werden entsprechende Tools wie GATE1 eingesetzt, die eine Accuracy bis zu 95% erreichen.
• Bei der Coreference Resolution werden Beziehungen zwischen Entitäten erkannt. Beispielsweise würde bei der Anaphernauflösung in dem Satz
Alas, poor Yorick, I knew him well.
„Yorick“ mit „him“ verknüpft werden.
• Die Template Element Reconstruction assoziiert nun deskriptive Informationen mit den
in den vorherigen Schritten gefundenen Elementen. Hier werden die vorher definierten Templates zunächst mit Daten gefüllt.
• Bei der Template Relation Reconstruction werden auf den obigen Schritten aufbauend
Relationen zwischen den einzelnen Elementen der Templates erkannt, z.B. ein Angestelltenverhältnis zwischen einer Firma und einer Person.
• Die Scenario Template Extraction stellt den finalen Schritt bei der Informationsextraktion dar. Alle in den bisherigen Schritten ermittelten Informationen werden hier zusammengefügt. Ein Szenario-Template kann in einem Management-Szenario z.B. erkennen welche Person, von welcher Firma kommend, den bisherigen Manager einer anderen Firma abgelöst hat. Die Template Element Reconstruction ist eine sehr
komplexe Aufgabe, bei der der automatische Systeme eine Accuracy von rund 60%
erreichen.
Der klassische Ansatz, Informationen aus Datenquellen zu extrahieren, ist der Einsatz
so genannter Wrapper. Laender u. a. (2002) geben einen Überblick über verschiedene Typen von Wrappern und Ansätzen der Wrappergenerierung. Diese lassen sich in folgende
Kategorien einteilen:
Sprachen zu Wrappergenerierung Hierbei handelt es sich um Sprachen, die den Benutzer bei der manuellen Konstruktion von Wrappern unterstützen. Diese werden als
Alternativen und benutzerfreundlichere Varianten zu Programmiersprachen wie
Perl und Java angesehen.
HTML-basierte Tools Diese Tools sind für die Generierung von Wrappern für HTMLDokumente geeignet. Hierbei wird das Dokument durch seinen DOM-Tree repräsentiert. Tools operieren semi-automatisch oder automatisch.
1 http://gate.ac.uk/
54
5 INFORMATIONSEXTRAKTION
NLP-basierte Tools Hier werden Techniken aus dem Natural Language Processing (NLP)
verwendet, um Extraktionsregeln zu lernen.
Wrapper-Induktions-Tools Diese Tools generieren Wrapper für Daten, die so genannte
Feldtrenner besitzen. Die drunterliegenden Daten müssen also gewisse Formatierungseigenschaften besitzen, die die enthaltenen Daten strukturieren.
Modellbasierte Tools Diese Tools operieren auf semistrukturierten Daten. Dabei muss
man eine Struktur für die relevanten Objekte angeben; es wird dann probiert, diese
Struktur in den Daten wiederzufinden.
Ontologiebasierte Tools Hier muss zunächst sorgfältig eine Ontologie, die die Daten beschreibt, manuell erstellt werden; ist diese repräsentativ genug, kann die Informationsextraktion vollautomatisch erfolgen.
Man kann weiterhin noch zwischen Single-Slot- und Multi-Slot-Extraktion unterscheiden (Soderland 1999). Bei der Single-Slot-Extraktion wird ein einziges Frame gefüllt, während die Multi-Slot-Extraktion mehrere Templates gleichzeitig füllen kann. Ein Text, der
z.B. von einem Produkt handelt, könnte Grundlage einer Single-Slot-Extraktion sein,
wenn es darum geht, die Produktdaten aus dem Text zu ermitteln; umgekehrt hätten wir
es mit einer Multi-Slot-Extraktion zu tun, wenn der Text von mehreren Produkten handelt,
deren Daten alle zu extrahieren sind.
Wie schon erwähnt bestehen Emails aus strukturierten Daten (dem Header) und zumeist unstrukturiertem Volltext (dem Body). Dementsprechend sollte bei der Informationsextraktion aus Emails zunächst einmal NLP-basierte Verfahren angewendet werden.
Besteht die Möglichkeit, eine entsprechende Ontologie sorgfältig zu erstellen, könnten
hier auch ontologiebasierte Tools interessant sein. Mit Abstrichen wären auch WrapperInduktions-Systeme geeignet, wenn die gesuchte Information in strukturierter Form (z.B.
Tabellen) vorliegt. An dieser Stelle werden wir uns deshalb primär mit NLP-basierten Verfahren beschäftigen, die auf Volltexten basieren. Dazu zählen wir auch Verfahren, die ein
gegebenes Textfragment dahingegen kategorisieren, ob es eine gesuchte Instanz enthält
oder nicht. Vorab aber wollen wir ein Beispiel geben, wie mit Hilfe von Informationsextraktion ein System zur automatischen Beantwortung von Emails aufgebaut werden kann.
5.2 Beispiel: Beantworten von Emails
Wir wollen an dieser Stelle ein Szenario vorstellen, bei dem Informationsextraktion für
Emails genutzt wird. Bei dem in (Kosseim u. a. 2001) vorgestellten Beispiel geht es darum, Anfragen, die per Email gestellt werden, automatisch zu beantworten. Die Emails
behandeln Fragen und Probleme zu in einer Firma eingesetzten Druckern. Dazu wurden
u.A. die Templates Print Event, Printer, User und File definiert. Diese werden nun mittels
Informationsextraktionsverfahren gefüllt und anhand dieser Daten wird ein passendes
Antwortformular gesucht.
kiib
55
5.3 ANSÄTZE ZUR INFORMATIONSEXTRAKTION
Abbildung 5.1 zeigt ein Beispiel für gefüllte Templates nach der Informationsextraktion.
Wie wir hier sehen, wurden nicht nur die Templates gefüllt, sondern auch Relationen zwischen den Templates ermittelt, um somit letztendlich das Print Event zu beschreiben. Um
die Templates zu füllen, wurden im vorliegenden Fall ein Lexikon aufgebaut, das Namen
bekannter Benutzer, Labore, Software und Drucker enthält. Für Named Entities wurden
Grammatiken wie reguläre Ausdrücke gebildet. Ferner wurden lexiko-syntakische Patterns definiert. So erlaubt das Aufkommen des Musters printer::name in room X
die Tatsache zu inferieren, dass der Drucker printer::name im Raum X steht.
Field
Print Event 1 Template
Value
Sender
Destination
Source
File to print
Action tried
User 1 Template
Printer 1 Template
File 1 Template
File 1 Template
Value
Field
Name
Current format
Source
Desired format
Owner
Job number
single sided
Printer 1 Template
Field
Name
Room
Status
File printing
Value
hp2248
X-234
Field
User 1 Template
Value
Name
Email
Laboratory
John Smith
[email protected]
Abbildung 5.1: Gefüllte Templates
Neben der eigentlichen Informationsextraktion sieht der von Kosseim u. a. (2001) beschrieben Ansatz auch eine Validierung der extrahierten Daten unter Einbeziehung externer Quellen vor. So kann für das Beispiel in Abb. 5.1 überprüft werden, ob in X-234
tatsächlich ein Drucker mit Namen hp2248 steht.
Das hier gegebene Beispiel ist in gewisser Weise simpel, da die Domäne doch sehr stark
eingeschränkt ist. Dadurch ist es möglich, auch Beziehungen zwischen Templates zu extrahieren. Kann man eine solche Einschränkung der Domäne nicht vornehmen, wird die
Informationsextraktion entsprechend anspruchsvoller.
5.3 Ansätze zur Informationsextraktion
Nachdem wir im letzten Abschnitt eine Beispiel gebracht haben, bei dem Informationsextraktion bei Emails angewendet wurde, wollen wir nun einige prominente Verfahren
zur Informationsextraktion vorstellen, die sowohl auf strukturierten Texten (wie HTMLDokumenten) als auch auf Freitexten, wie wir sie ja im Email-Body vorfinden. Diese Systeme sind WHISK, eine Kombination aus Kategorisierer und Regellerner, und ELIE.
56
@S[
{SUBJ
@PN[ C. Vincent Protho ]PN , @PS[chairman and chief
executive officer ]PS of this maker of semiconductors, }
{VB
@Passive was named @nam }
{PP
to the additional post of @PS[ president ]PS , }
{REL_V succeeding @succeed @PN[ John W. Smith ]PN ,
who resigned @resign to pursue @pursu other interests. }
]@S 8910130051-1
Abbildung 5.2: Syntaktisch analysierter Text (entnommen aus Soderland (1999))
5.3.1 WHISK
WHISK wird in (Soderland 1999) vorgestellt. Wie schon erwähnt kann das System sowohl
mit semi-strukturierten als auch mit Freitexten umgehen. Freitexte werden zunächst mal
einer syntaktischen Analyse unterzogen. Eine mögliches Resultat der syntaktischen Analyse eines Textes ist in Abb. 5.2 dargestellt. Eine solche Analyse markiert Worte als Subjekt,
Personalpronomen, usw., aber auch Personennamen (@PN), Stellen (@PS, engl. „posts“)
oder auch Firmennamen. Des Weiteren wurden hier auch Passivformen (@Passive) und
Stammformen (z.B. @nam) erkannt. Das abgebildete Beispiel bildet eine Instanz; dabei handelt es sich in der Regel um einen Satz oder eine Klausel, welche durch die syntaktische Analyse determiniert wird. Wie wir weiter unten erläutern werden, wendet WHISK
auf solche Instanzen maschinell erlernte Regeln an. Unser Beispiel ist entnommen aus
der Management Succession-Domäne2 ; hier galt es herauszufinden, welche Person eine
Management-Position in einer Firma verlässt und mit wem die Position neu besetzt wird.
WHISK würde nun anhand des syntaktisch analysierten Textes entsprechende Slots eines solchen Succession Events füllen, z.B. PersonIn=C. Vincent Protho, PersonOut=John W.
Smith, Post=President.
Wie oben erwähnt, lernt WHISK Regeln der Form
Pattern:: * ( Person ) * ’@Passive’ *F ’named’
* {PP *F ( Position )} * ’@succeed ’ ( Person )
Output:: Succession {PersonIn $1} {Post $2} {PersonOut $3}
aus einer Testmenge und wendet diese auf die Instanzen an. Die Pattern sorgen dabei für
eine Perl-ähnliche Bindung an die Variablen. Die in der ersten Umklammerung gefundene Person wird an die Variable $1 gebunden, während die Position $2 und die zweite
Person $3 bindet. Das erste * ist eine Wildcard und bedeutet, dass alle Eingabezeichen
ignoriert werden, bis eine Person gefunden wird (Person bezeichnet dabei eine Liste mit
Personennamen). $1 wird mit der gefunden Person gebunden. Danach werden wieder alle Zeichen bis zum Auftauchen des Tokens @Passive ignoriert. Die nächste Wildcard ist
2 Dieses
Thema war eine Vorgabe bei der sechsten Message Understanding Conference (MUC-6); siehe auch
http://cs.nyu.edu/cs/faculty/grishman/muc6.html
kiib
57
*F und bedeutet, dass das Wort „named“ im selben Feld sein muss wie der „Passive“-Tag.
Weiter sucht der Ausdruck nach einer Präpositionalphrase, die eine Position (wie Person
ein Platzhalter für eine Liste, wird an $2 gebunden) und die Stammform @succeed enthält, gefolgt von einer weiteren Person (die an $3 gebunden wird).
Algorithmus 4 beschreibt die oberste Ebene des WHISK-Lernalgorithmus. Beim Ablauf
des Algorithmus wird der Benutzer involviert. Der Algorithmus startet mit einem Reservoir von unmarkierten Lernbeispielen (dabei handelt es sich um eine Menge von Instanzen wie in Abb. 5.2). Bei jeder Iteration wird nun eine Menge von unmarkierten Instanzen
ausgewählt. Diese Instanzen werden dem Benutzer vorgeführt, der nun die zum Frame
passenden Slotinstanzen im Text identifiziert und markiert. Ein solches vom Benutzer erstelltes Tag für unser Beispiel hätte die Form
@@TAGS Succession {PersonIn C. Vincent Protho }
{Post president}
{PersonOut John W. Smith}
Im nächsten Schritt werden nun alle bisher gelernten Regeln, die auf der neuen, markierten Trainingsmenge Fehler produzieren, entfernt3 . Die Trainingsmenge wird aktualisiert
und es wird nun für alle Trainingsinstanzen und deren Tags überprüft, ob das Tag von
dem bisherigen Regelsatz abgedeckt ist. Dabei ist ein Tag von einer Regel abgedeckt, wenn
diese erfolgreich auf die Instanz angewendet werden kann und die richtigen Daten des
Tags extrahiert. Ist ein Tag nicht abgedeckt, dann dient es, zusammen mit der Trainingsmenge, als Eingabe der grow_rule-Funktion, die nun mittels eines Top-Down-Verfahrens
eine Regel lernt, die dieses Tag abdeckt (für eine genaue Beschreibung der grow_ruleRoutine sei auf (Soderland 1999) verwiesen). Ist das Training abgeschlossen, findet ein
Pruning der Regeln statt.
Experimente Soderland beschreibt Experimente mit strukturierten, semi-strukturierten
und Freitexten. Ein Versuch wurde auf Wettervorhersagen von CNN durchgeführt. Diese Daten wurden aus einer Datenbank extrahiert und in HTML konvertiert. Sie liegen
also in sehr strukturierter Form vor; WHISK versucht quasi, das ursprüngliche Datenbankschema zu erlernen. Dabei wird eine Precision4 und ein Recall5 von annähernd 100%
erreicht. Etwas gemischter sieht der Fall bei semi-strukturierten Daten aus. So wurden auf
einem Datensatz bestehend aus Wohnungsanzeigen, bei denen Ort, Anzahl Schlafzimmer
und Preis extrahiert wurden, 70% Recall und 97% Precision erreicht. Es wurden hier also
nicht alle möglichen Datensätze erkannt, aber die Fehlerrate bei den erkannten Daten war
doch noch recht niedrig. Ein interessantes Experiment wurde auf Seminarankündigungen
durchgeführt. Diese Ankündigungen können dabei in unterschiedlicher Form vorliegen,
mehr oder weniger strukturiert in tabellarischer Form, aber auch relativ unstrukturiert
als quasi freier Text. Aufgabe hier war es, Start- und Endzeit, Ort und Sprecher zu ermitteln. Hier zeigt sich interessanterweise, dass verschiedene Slots unterschiedliche Güte bei
3 wenn
z.B. eine Instanz ein Gegenbeispiel zu einer bereits gelernten Regel darstellt
richtig extrahierter Slots durch die Anzahl extrahierter Slots
5 Anzahl richtig extrahierter Slots durch die Anzahl aller möglichen zu extrahierenden Slots
4 Anzahl
58
Eingabe:
Reservoir R
Ausgabe:
Regelsatz R
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
R←∅
Training ← ∅
while User wants to continue do
select NewInst ⊂ R
NewInst ← tag( NewInst)
NewInst ← discard_rules_with_errors( NewInst)
Training ← Training ∪ NewInst
for all inst ∈ Training do
for all tag of inst do
if tag is not covered by RuleSet then
rule ← grow_rule(inst, tag, Training)
R ← RuleSet ∪ rule
end if
end for
end for
end while
prune( R)
Algorithmus 4: Hauptebene des WHISK-Algorithmus
der Extraktion haben können. Start- und Endzeit konnten mit 100% Recall bei 96% Precision (F1 ≈ 0, 98) bzw. 87% Recall bei 89% Precision (F1 ≈ 0, 88) ermittelt werden. Beim
Ermitteln des Ortes aber werden geringere Werte erreicht (Recall 36% bei 94% Precision, F1 ≈ 0, 52) und beim Sprecher werden noch schlechtere Werte berichtet. Ein weiteres
Experiment befasste sich mit der Datenextraktion auf freien, unstrukturierten Texten. Dabei ging es um das bereits erwähnte Management-Succession-Szenario. Hier besteht das
gesonderte Problem, dass viele Informationen eher implizit im Text vorhanden ist; aus
linguistischer Sicht haben wir es also mit einer höchst anspruchsvollen Aufgabe zu tun.
Die höchste hier gemessene Rate is 46% Recall bei 69% Precision (F1 = 0, 552, ohne Pruning) bzw. 61% Recall bei 48% Precision (F1 ≈ 0, 54, mit Pruning); allerdings wurden
diese Werte mit einer immens hohen Trainingsmenge von 6915 Instanzen ermittelt. Bei
einer Trainingsmenge von 400 Instanzen ließ sich ein Recall von 54% bei einer Precision
von 36% erreichen (F1 = 0, 432).
5.3.2 SRV / Kategorisierung
Als nächstes wollen wir den von Freitag (2000) vorgestellten Ansatz zur Informationsextraktion betrachten. Streng genommen handelt es sich hier um mehrere Ansätze, die
kiib
59
miteinander kombiniert werden. Es handelt sich auf der einen Seite um Kategorisierungsansätze und auf der anderen Seite um ein regelbasiertes System (SRV).
Kategorisierungsansätze
Sind ein Template und Slots gegeben, so soll die Kategorisierung die Frage beantworten,
ob ein gegebenes Textfragment eine Instanz des gesuchten Slot enthält oder nicht. Präziser
formuliert, soll eine reele Zahl ausgegeben werden die besagt, zu welchem Grade das
Textfragment eine gesuchte Instanz enthält. Dabei kommen zwei Klassifikationsverfahren
zum Einsatz, die wir hier kurz vorstellen wollen: ROTE und BAYES.
ROTE Hierbei handelt es sich um ein sehr simples Kategorisierungsverfahren. Auf Basis einer Lernstichprobe, in der die relevanten Instanzen vom Benutzer markiert wurden,
lernt das System relevante Einträge „auswendig“. Es wird somit ein Lexikon relevanter
Einträge erzeugt. Wird ein neues Dokument untersucht, wird ein Matching auf die Einträge im Lexikon durchgeführt; wurde ein Eintrag gefunden, wird der entsprechende Slot
gefüllt.
Ein Konfidenzmaß kann folgendermaßen errechnet werden. Für jedes Textfragment im
Lexikon wird die Anzahl p ermittelt, in der dieses Textfragment tatsächlich als Instanz
eines Slots markiert wurde. Ferner zählt man noch die Gesamtvorkommenshäufigkeit t in
der Testkollektion. Das Konfidenzmaß ergibt sich dann als ( p + 1)/(t + 2).
Es ist offensichtlich, dass dieses Verfahren sich nur für spezielle Aufgaben eignet. Der
Nachteil ist ganz klar, dass nur bereits im Lexikon vorhandene Instanzen wiedererkannt
werden. In diesem Fall aber ist tatsächlich mit einem guten Ergebnis zu rechnen.
BAYES Diese Ansatz wird auch „Term-Space-Lerner“ genannt. Möchte man in einer Seminarankündigung z.B. den Sprecher ermitteln, so wird die Hypothese formuliert, dass
das Textfragment, welches beim Token i beginnt und k Token lang ist, den Sprecher enthält. Diese Hypothese bezeichnen wir mit Hi,k . Si ist H309,2 die Hypothese, dass das mit
dem 309. Token beginnende Textfragment, das 2 Token groß ist, den Sprecher (bzw. allgemeiner die gesuchte Instanz für den Slot) enthält. Der Algorithmus berechnet nun für ein
Dokument d die Wahrscheinlichkeiten P( Hi,k |d) für den zu extrahierenden Slot.
Mittels der Bayes’schen Regel erhalten wir
P( Hi,k |d) =
P(d|hi,k ) · P( Hi,k )
.
P(d)
Dabei gilt
P( Hi,k ) = P(position = i ) · P(length = k).
Zu den Abschätzungen von P(position = i ) und P(length = k) siehe auch (Freitag 2000,
S. 176). Die Abschätzung von P(d|hi,k ) besteht aus drei Komponenten:
P(d| Hi,k ) = P(before| Hi,k ) · P(in| Hi,k ) · P(after| Hi,k )
60
wobei „before“, „in“ und „after“ das Ereignis beschreiben, dass wir ein Token vor, in oder
nach einer Instanz vorfinden. Es sei nun
w B (t
j (i − j ) )
P(before| Hi,k ) = ∏
,
G ( t (i − j ) )
j =1
wobei Bi (t) angibt, wie häufig der Term t i Token vor einer erkannten Instanz aufgefunden
wurde, und G (t) angibt, wie häufig t irgendwo in der Trainingskollektion auftauchte.
w ist eine vorgegebene Fenstergröße. Die Berechnungen für P(in| Hi,k ) und P(after| Hi,k )
erfolgen analog. Ein Beispiel soll das Prinzip verdeutlichen.
Beispiel. Angenommen, wir haben folgende, aus den Enron-Daten entnommene Tokensequenz gegeben:
Our meeting will be in the
new
Enron
building
,
Room 6104 .
| {z } | {z } | {z } |{z}
B4 (’new’) B3 (’enron’) B2 (’building’) B1 (’,’)
Hierbei ist nun „Room 6104“ die markierte Instanz des Slots „Ort“. Für
die Berechnung von P(before| Hi,k ) und einer angenommenen Fenstergröße von w = 4 betrachten wir nun die 4 (eingerahmten) Token vor der erkannten Instanz. Wir berechnen nun B1 (’,’), d.h. wie häufig ein Komma vor
einer markierten Instanz aufgefunden wurde, und analog B2 , B3 und B4 .
Durch die Berechnung von P( Hi,k |d) bekommen wir eine Abschätzung für jedes Fragment. Hier gilt es nun Fragmente abzulehnen, die keine Instanz eines Slot enthalten. Dies
kann über einen Konfidenzschwellwert gesteuert werdem, der sich als vom Benutzer gegeben Parameter γ multipliziert mit dem niedrigsten aus den Trainingsdaten bekannten
Konfidenzwert6 . Ist γ = 1, dann extrahiert BAYES nur Fragmente, für die mindestens eine
auch mit den Trainingsdaten erreichte Konfidenz ermittelt wird.
Der bisher dargestellte BAYES-Algorithmus hat den Vorteil, dass er auch Instanzen erkennen kann, die nicht in Trainingsbeispielen vorhanden sind. Ein Nachteil ist aber, dass
die Instanzgrenzen mitunter nicht erkannt werden – der Algorithmus könnte ein Textfragment zurück liefern, das neben der Instanz auch noch weitere Token enthält. Abhilfe
soll hier die so genannte Grammatikalische Inferenz schaffen, für die wir auf (Freitag 2000,
S. 177ff) verweisen.
SRV
Zusätzlich zu ROTE und BAYES schlägt Freitag den Einsatz von SRV, einem Top-DownRegellerner, der nach der induktiven logischen Programmierung funktioniert, vor. SRV
6 Über
kiib
diesen Wert werden in (Freitag 2000) leider keine näheren Angaben gemacht
61
beginnt also mit einer Nullregel, die die ganze Menge von Trainingsbeispielen abdeckt,
und fügt dabei gierig („greedily“) neue Literale hinzu. Dabei kommen folgenden fünf
Prädikate zum Einsatz:
length(Relop,N) Die Anzahl Token im Fragment ist größer, kleiner oder gleich einem
Integer-Wert. Beispiel: length(>,2).
some(Var, Path, Feature, Value) Bei einem Token wird getestet, ob er eine bestimmte Eigenschaft hat. some(?A, [], captializedp, true) bedeutet „das Fragment hat Token, die großgeschrieben sind“. Die entsprechenden Token würden
dann an die Variable A gebunden. some(?A, [prev_token prev_token],
captializedp, true) bedeutet: „es existiert ein Token im Fragment, das ein
großgeschriebenenes Token zwei Stellen vorher hat“. Ein Feature kann dabei eine
Texteigenschaft sein, aber bei strukturierten Texten z.B. auch aus dem HTML-Code
extrahierte Features beinhalten.
every(Feature, Value) Jedes Token im Fragment muss die gegebene Eigenschaft haben. every(numericp, false) bedeutet „jedes Token im Fragment ist nichtnumerisch“.
position(Var, From, Relop, N) Ein Token in der gegenwärtigen Regel muß sich im spezifizierten Abstand vom Anfang oder Ende der Sequenz befinden. Beispielsweise
heißt position(?A,fromfirst,<,2) „das an Variable ?A gebundene Token ist
das erste oder zweite Token im Fragment“.
relpos(Var2, Var2, Relop, N) Zwei Token kommen in der gegebenen Reihenfolge mit
dem gegebenen Abstand vor. relpos(?A, ?B, =, 1) bedeutet beispielsweise
„das an ?A gebundenen Token folgt sofort dem an ?B gebundenen Token“.
Multistrategy-Ansatz
Es hat sich bei der Evaluation gezeigt, dass SRV sowohl bei semistrukturierten als auch
Freitexten die besten Ergebnisse erzielt. Dennoch stellt sich heraus, dass das eine Verfahren gut auf einem Slot operiert, bei dem andere Verfahren eher schlechter abschneiden.
Man kann also nicht mit letzter Sicherheit sagen, ob das eine oder andere Verfahren weniger oder mehr geeignet ist. Freitag schlägt daher eine Kombination der Verfahren vor, um
die Schwächen des einen mit den Stärken des anderen Verfahrens zu kombinieren.
Tatsächlich zeigen Versuche mit diesem so genannten Multistrategy-Ansatz in Experimenten die besten Ergebnisse. Bei den schon für die WHISK-Evaluation benutzen Seminarankündigungen erreichte das Multistrategy-Verfahren beim Sprecher einen F1 -Wert
von 0,662, beim Ort 0,797, bei der Startzeit 0,993 und bei der Endzeit 0,943. Damit werden
bei dieser Aufgabe bessere Werte als mit dem WHISK-Ansatz erreicht.
Bei einem anderen Test wurde die Reuters „Acquisition“-Klasse herangezogen, um
Slots wie “Was erworben“ und „Käufer“ usw. zu füllen. Es handelt sich hier um unstrukturierte Dokumente. Hierbei erreichte der kombinierte Ansatz für die einzelnen Slots F1 -
62
Werte zwischen 0,431 und 0,643. Schließlich wurden in einem weiteren Experiment, in
dem aus den Webseiten einer Universität Kurs- und Projektinformationen extrahiert wurden, F1 -Werte zwischen 0,341 (beim Projekttitel) und 0,889 (bei der Kursnummer) ermittelt. Problematisch an dieser Aufgabenstellung war, dass eine Web-Seite Informationen
über mehrere Kurse oder Projekte enthalten kann, wodurch die Extraktionsaufgabe erschwert wird.
5.3.3 ELIE
Die in ROPE und BAYES aufgekommene Idee, die Informationsextraktion als Klassifizierungsaufgabe anzusehen, wird auch von Finn u. Kushmerick (2004) aufgegriffen. Hier
wird auch jede Position im Dokument als mögliche Start- oder Endposition oder als irrelevant bezüglich einer gesuchten Slot-Instanz kategorisiert. Beim vorgeschlagenen ELIEAlgorithmus handelt es sich dabei um ein zweistufiges Verfahren, bei dem die einzelnen
Token durch Features repräsentiert sind. Zum Einsatz kommt dabei eine Variante der Support Vector Machines.
Die in ELIE benutzten Features sind im Einzelnen:
Token Das aktuelle Token.
POS Der Part-of-Speech des Tokens, ermittelt durch einen Part-of-Speech-Tagger (Brill
1994).
GAZ Assoziation mit einem benutzerdefinierten Lexikon (Gazetteer). Hier können Namen, Städte usw. aufgelistet sein.
Orthographie Orthographische Information über das Token, wie z.B. Groß- und Kleinschreibung, Punktuation, alphabetisch oder numerisch, etc.
Weiterhin können noch Beziehungsinformationen zwischen Token in Features dargestellt werden. Zu einem Token werden für eine bestimmte Fenstergröße w die Features
der vorherigen w und nachfolgenden w Token mit repräsentiert.
Lernen in ELIE besteht wie erwähnt aus zwei Phasen, L1 (level one) und L2 (level two).
Der L1-Lerner arbeitet dabei auf der gesamten Trainingsmenge. Die Eigenschaften jedes
Tokens werden in Featurevektoren repräsentiert. Jedes Token kann dabei als positives
oder negatives Beispiel für Start- bzw. Endpositionen gelten. Die Trainingstoken bzw. deren Featurerepräsentationen werden nun analog zu der Beschreibung in Abschnitt 4.1.2
benutzt, um eine Hyperebenenfunktion zu berechnen. Wir bekommen dabei eine Funktion zur Ermittlung der Startposition und eine zur Ermittlung der Endposition. Da wir
beim L1-Lerner alle Token in der Trainingsmenge berücksichtigen, haben wir dort viele
negative Beispiele. Dies sorgt dafür, dass der L1-Lerner eine hohe Precision, aber niedrigen Recall ermöglicht.
Beim L2-Lerner nehmen wir nun eine eingeschränkte Trainingsmenge. Zur Ermittlung
der Funktion für Starttoken werden die Token genommen, die sich eine fixe Anzahl von
kiib
5.4 BEURTEILUNG DER VERFAHREN ZUR INFORMATIONSEXTRAKTION
63
Token vor einem Endtoken befinden. Zur Bestimmung der Funktion für Endtoken werden
die Token genommen, die eine fixe Anzahl von Token nach einem Starttoken auftauchen.
Dadurch wird L2 nur auf einer sehr eingeschränkte Teilmenge der Trainingsmenge trainiert. Die daraus resultierenden Funktionen für Start- und Endtoken verursachen einen
hohen Recall, aber eine niedrige Precision.
L1 und L2 werden nun kombiniert angewendet. Die L2-Funktion für Endtoken wird
dabei auf die Token angewendet, die von L1 als Startknoten erkannt hat, plus den drei
darauf folgenden Token. Analog wird die L2-Funktion für Starttoken auf die Token angewendet, die L1 als Endtoken erkannt hat, plus deren drei vorherigen Token. Die Annahme
ist, dass L2 Start-oder Endtoken identifizieren kann, die L1 entgangen sind. Man erhofft
sich im Endeffekt eine gute Precision (durch L1) und einen guten Recall (durch L2). Durch
die hohe Precision aber niedrigen Recall von L1 kann es nämlich häufig vorkommen, dass
L1 ein Starttoken erkennt, aber den dazugehörigen Endtoken nicht (und umgekehrt). Das
fehlende Start- oder Endtoken würde dann durch L2 erkannt.
Evaluierung von ELIE Bei der Evaluierung wurde ELIE u.A. auf die Reuters
„Acquisition“-Klasse und den Seminarankündigungen getestet. Interessant hierbei ist,
dass bei den Seminarankündigungen auf das Sprecher-Feld, das bei anderen Verfahren
noch Probleme bereitet hat, ein f 1 -Wert von 0,885 erreicht wurde. Dies lässt sich unter Anderem auf den Einsatz des benutzerdefinierten Lexikons zurückführen, indem in diesem
Fall Vor-und Nachnamen gespeichert wurden. Generell werden die Werte der anderen
vorgestellten IE-Verfahren übertroffen.
5.4 Beurteilung der Verfahren zur Informationsextraktion
Es bestätigt sich, dass die Informationsextraktion aus Texten eine sehr große Herausforderung darstellt. Einfache Verfahren wie die Named Entity Recognition liefern gute Ergebnisse, ebenso, wenn sehr strukturierte Daten vorliegen, wie im Fall der CNNWettervorhersage, wo wir es einerseits mit strukturierten Texten (HTML) und andererseits
mit einer inhärenten Datenbankstruktur zu tun haben. Daraus resultierende Regelmäßigkeiten in der Darstellung lassen einen Recall und eine Precision von annähernd 100% zu.
Grundsätzlich kann man sagen: je weniger Struktur die Texte haben, desto schlechter
ist die Informationsextraktion. Dies legen die bisherigen Experimente nahe. Auch sollte
die Domäne recht eingeschränkt sein, d.h. bei der Erstellung eines Templates sollte man
sich wie in den vorgestellten Experimenten auf ein bestimmtes Thema (wie z.B. Seminarankündigungen) konzentrieren. Inwieweit die Effektivität der vorgestellten Verfahren
dann akzeptabel ist, hängt natürlich von der jeweiligen Anwendung ab. Dabei sind der
Multistrategy- und der ELIE-Ansatz vielversprechend, allerdings brauchen diese Verfahren eine bereits vollständig aufbereitete Lernemenge, in denen die relevanten Instanzen
schon markiert sind. Beim WHISK-Ansatz ist es hingegen möglich, dem Benutzer in jedem Iterationsschritt eine neue Menge von Instanzen aus dem Reservoir vorzulegen, die
er dann markiert; dieser Prozess wiederholt sich so lange, bis ein befriedigendes Ergeb-
64
nis erreicht wird. Auch hier hängt wieder von der jeweiligen Anwendung ab, ob welche
Vorgehensweise zu bevorzugen ist.
5.5 Anwendung der Informationsextraktion im Inbox-Szenario
Wir haben bisher einige repräsentative Verfahren zur Informationsextraktion kennen gelernt, die in Form eines Wrappers oder von Kategorisierungsfunktionen im Stande sind,
Daten aus einem gegebenen Text zu extrahieren. Wie können wir nun diese Techniken
gewinnbringend im Inbox-Szenario einbringen?
In Abschnitt 2.1 haben wir uns mit verschiedenen Anwendungsfällen für das InboxSzenario beschäftigt, sowie ein erweitertes Szenario, das auf Ontologien beruht, beschrieben. Wir wollen diese Gedanken hier wieder aufgreifen und einige Einsatzmöglichkeiten
von IE-Verfahren diskutieren.
Methoden der Informationsextraktion können beim Indexieren der Emails, im
Ontologie-Szenario also beim Erstellen neuer Instanzen, behilflich sein. Jedes Konzept einer Ontologie definiert dabei ein Template. Wird eine neue Email empfangen, so kann
mit IE-Methoden versucht werden, ein solches Template zu füllen. Ist dies erfolgreich geschehen, kann nun abgeglichen werden, ob eine entsprechende Instanz schon vorliegt.
Im Reise-Beispiel könnte dies z.B. geschehen, indem man das Hin- und Rückflugsdatum
mit bestehenden Reisedaten abgleicht. Ergibt sich ein Matching, so wird die Email zu den
Email-Referenzen der gefundenen Instanz hinzugefügt. Ergibt sich kein Matching, wird
nach Rücksprache mit dem Benutzer eine neue Instanz erzeugt.
Ein anderes Anwendungsbeispiel ist das Bereitstellen von Hintergrundinformationen.
Wird eine Email geöffnet, beschafft das System automatisch Hintergrundinformationen,
die dem Benutzer auf Anfrage präsentiert werden können. Hier können IE-Methoden benutzt werden, um Entitäten aus dem Text zu extrahieren und dazu relevante Emails oder
andere Informationen zu finden. Werden z.B. eine Person und ein Projekt erkannt, so kann
das System alle Emails, in denen diese Person im Zusammenhang mit dem Projekt erwähnt wird, auswählen. Oder es können für Termine ein Start- und Endtermin extrahiert
und mit Einträgen im Kalender abgeglichen werden, z.B. um festzustellen, ob der betreffende Termin noch frei ist.
Zusätzlich zu den extrahierten Daten ist es ferner noch möglich, die Beziehungen
zwischen den Objekten der zu Grunde liegenden Ontologie auszunutzen. pDatalogImplementierungen ermöglichen es, ein solches Wissensnetz mit Hilfe von DatalogRegeln zu modellieren. Diese Regeln können dann im Retrievalprozess mit eingebunden
werden.
Aus der Sicht des Information Retrieval wäre es sicherlich interessant, inwiefern ein
ontologiebasierter Ansatz kombiniert mit IE-Methoden das Beschaffen relevanter Hintergrundinformation fördern kann.
kiib
6 Knowledge Intensive Tasks
Bisher haben wir in unserer Studie dargelegt, wie Methoden der Kategorisierung und Informationsextraktion im Inbox-Szenario eingesetzt werden können. Beide Methoden dienen letztendlich dazu, in einem Email-Archiv die gesuchte Information wieder aufzufinden.
Wir wollen an dieser Stelle nun den Horizont ein wenig weiten und das Inbox-Szenario
bzw. die Email-Archivierung als Teil eines größeren Workflows betrachten. Generell können Emails verschiedene Rollen im Zusammenhang mit Prozessen und Workflows einnehmen:
• Eingehende Emails können bestimmten Problemklassen zur (automatischen
oder manuellen) Weiterverarbeitung vorgelegt werden. Hier bieten sich sowohl
Kategorisierungs- als auch IE-Methoden an. Ein Beispiel wäre das in Abschnitt 4.1.2
erwähnte Kontaktcenter-Szenario, bei dem Emails danach kategorisiert werden, ob
sie einer sofortigen oder späteren Bearbeitung bedürfen. Oder aber es können die
relevanten Informationen aus einer eingehenden Rechnung extrahiert und zur Weiterverarbeitung aufbereitet werden.
• Das Email-Archiv kann für so genannte wissensintensive Aufgaben (Knowledge Intensive Tasks) als Informationsquelle abgerufen werden. Dieses Szenario wollen wir im
Folgenden diskutieren. Wir folgen dabei den Ausführungen in (Abecker u. a. 2000).
6.1 Knowledge Intensive Tasks in Workflows
In einem Workflow gibt es häufig Prozesse und Aufgaben, deren Bearbeitung ein reiches Hintergrundwissen erfordern. Diese sind in der Literatur als Knowledge Intensive
Tasks (KIT) bekannt. KITs sind dabei aus technischer Sicht gewöhnliche Workflowaktivitäten, die um die zusätzliche Spezifikation von Informationsbedürfnissen und zugehörigen Prozessierungsanweisungen erweitert wurden. Um das Ziel der jeweiligen Aufgabe zu erreichen, müssen diese Informationsbedürfnisse befriedigt werden, wobei es
von gewissen Vorbedingungen abhängt, welche Informationsbedürfnisse konkret anfallen. Zur Erfüllung werden pro spezifiziertem Informationsbedürfnis Informationsagenten
eingesetzt. Diese erhalten als Eingabe eine Anfrage und zusätzliche Kontextinformationen. Die Kontextinformationen enthalten dabei Variablen, die bei der bisherigen Abarbeitung des Workflows gesetzt wurden und das Retrievalergebnis u.U. beeinflussen können.
Zur Abarbeitung der Anfragen beziehen die Informationsagenten Wissen aus dem Organizational Memory. Hierbei handelt es sich in der Regel um drei Ontologien:
66
6 KNOWLEDGE INTENSIVE TASKS
• die Informationsontologie beinhaltet Meta-Aspekte der einzelnen Informationsquellen, d.h. hier werden keine Inhalte, aber deren Charakteristika beschrieben;
• die Domänenontologie beschreibt das Gebiet, über welches die Dokumente berichten.
Eine Dokumentindexierung kann Dokumente und Konzepte in Verbindung bringen. Für Retrievalzwecke kann der Recall erhöht werden, indem man im Falle einer Resultatliste mit Hilfe der Ontologie Anfragen reformuliert. Die Precision wird
durch die Auflösung von Polysemen erhöht;
• die Enterprise-Ontologie enthält das Wissen, um Kontexte zu modellieren. In dieser Ontologie können z.B. die betriebliche Struktur des Unternehmens als auch
Personen-, Projekt- und Kontaktdaten abgelegt sein.
Abbildung 6.1 fasst noch einmal die wichtigsten Elemente im Zusammenhang mit Knowledge Intensive Tasks zusammen. Methoden des Information Retrieval können hierbei
helfen, die anfallenden Informationsbedürfnisse zu decken.
Abbildung 6.1: Knowledge Intensive Tasks
6.2 Emails und Knowledge Intensive Tasks
Das Email-Archiv kann in vielerlei Hinsicht eine sehr wichtige Informationsquelle für wissensintensive Aufgaben sein. In (Abecker u. a. 2000) wird das Beispiel einer Bestellung
von Grafikkarten gebracht, bei der es nötig sein kann Personen zu finden, die mit dieser
Karte schon Erfahrungen gemacht haben. Wir haben es hier mit dem in Abschnitt 2.2.1
kurz diskutierten Problem der Expertensuche zu tun, für die Email-Diskussionen die
Grundlage bieten können. Allerdings können uns hier auch Verfahren der Informationsextraktion weiterhelfen. So können erkannte Named Entities Emails mit Objekten aus der
Enterprise-Ontologie verknüpft werden. Ferner können IE-Methoden angewendet werden um Emails mit Objekten der Domänenontologie zu verknüpfen; wie in Abschnitt 5.5
kiib
6.2 EMAILS UND KNOWLEDGE INTENSIVE TASKS
67
erwähnt, können die Konzepte der Ontologie als Grundlagen für entsprechende zu füllende Templates dienen. Wiederum können pDatalog-Implementierungen das Ontologiewissen benutzen, um geeignete kontextbasierte Retrievalfunktionen zu definieren.
7 Zusammenfassung und Ausblick
Wir haben in dieser Studie das so genannte „Inbox-Szenario“ betrachtet, in dem es um die
Weiterverarbeitung und Archivierung in einer Mailbox eingehender Emails geht. Dazu
haben wir verschiedene Use Cases erstellt und dargelegt, dass im vorleigenden Szenario Problemlösungen aus den Bereichen Information Retrieval, Datenbanken, Summarization, Kategorisierung und Informationsextraktion relevant sind. Das erweiterte InboxSzenario fügt der Folderstruktur einer Mailbox noch ontologisches Wissen hinzu, das
besonders für die Informationsextraktion interessant ist. Als Beispieldaten haben wir
den Enron-Korpus untersucht, der einen repräsentativen Querschnitt verschiedener Mailboxen und unterschiedlicher Benutzer mit unterschiedlichen Präferenzen bei der Wahl
der Folderhierarchie darstellt. Wir haben festgestellt, dass sich Emails hinsichtlich unterschiedlicher Facetten kategorisieren lassen. Dazu haben wir im weiteren Verlauf verschiedenen Machine Learning-Verfahren betrachtet, die entweder schon einmal auf einem
Email-Korpus getestet wurden oder für die Emails eine neuartige Anwendung darstellen.
Neben klassischen Verfahren aus der Textkategorisierung haben wir uns dazu auch regelbasierte Ansätze angeschaut. Es stellt sich heraus, dass diese Kategorisierungsverfahren
durchaus das Potential haben, Emails hinsichtlich verschiedener Facetten zu klassifizieren. Allerdings sind manche Verfahren erneut zu evaluieren, da sie entweder auf dem
Enron-Korpus oder aber auf die Email-Domäne allgemein noch nicht getestet wurden. Im
weiteren Verlauf der Studie haben wir Informationsextraktionsverfahren kennen gelernt,
die bei präzise definierter Problemstellung in der Lage sind, die benötigte Information
aus den Emails heraus zu extrahieren. Wie gut solche Verfahren dabei sind, ist durch weitere Experimente zu zeigen. Zu guter Letzt haben wir unseren Blick erweitert und das
Inbox-Szenario und die Email-Archivierung im Kontext eines größeren Workflows gesehen; hierbei kann das Email-Archiv als Teil eines Organizational Memory angesehen
werden, welches für die Bearbeitung wissensintensiver Aufgaben benötigt wird.
Es stellt sich heraus, dass es sowohl bei der Kategorisierung als auch bei der Informationsextraktion kein Verfahren gibt, dass man generell empfehlen kann. Letztendlich
hängt die Auswahl eines geeigneten Verfahrens von der eigentlichen Anwendung und
auch von Fragen der Usability ab. Ziel unserer Studie war es aber, eine solide Grundlage für eine Entscheidung zu geben. In zukünftigen Schritten sollte zunächst einmal ein
Szenario definiert werden, bei denen Kategorisierungs- oder Extraktionsansätze potentiell gewinnbringend zum Einsatz kommen können. Die Kapitel 5 und 6 enthalten schon
grobe Beschreibungen möglicher nächster Schritte. Neben der Einsatzfähigkeit der in Abschnitt 4.2 beschriebenen probabilistischen, beschreibungsorientierten bzw. regelbasierten
Verfahren zur Email-Klassifikation sollte auch erforscht werden, inwieweit Methoden der
Informationsextraktion im Stande sind, gute Ergebnisse bei der Beschaffung von Hinter-
69
grundinformationen zu liefern.
Literaturverzeichnis
Abecker u. a. 2000
A BECKER, Andreas ; B ERNARDI, Ansgar ; H INKELMANN, Knut ; K HN, Otto ; S INTEK,
Michael: Context-Aware, Proactive Delivery of Task-Specific Knowledge: The KnowMore Project. In: International Journal on Information System Frontiers (ISF) 2 (2000), Nr.
(3/4), S. 139–162
Abolhassani u. a. 2003
A BOLHASSANI, M. ; F UHR, N. ; G ÖVERT, N.: Information Extraction and Automatic
Markup for XML documents. In: B LANKEN, Henk M. (Hrsg.) ; G RABS, Torsten (Hrsg.)
; S CHEK, Hans-Jörg (Hrsg.) ; S CHENKEL, Ralf (Hrsg.) ; W EIKUM, Gerhard (Hrsg.): Intelligent Search on XML Data. Applications, Languages, Models, Implementations, and Benchmarks Bd. 2818. Heidelberg et al. : Springer, 2003, S. 159–174
Appelt u. Israel 1999
A PPELT, E. ; I SRAEL, D. J.: Introduction to Information Extraction Technology. A Tutorial
Prepared for IJCAI 1999. 1999. – http://www.ai.mit.edu/people/jimmylin/
papers/intro-to-ie.pdf
Bekkerman u. a. 2004
B EKKERMAN, Ron ; M C C ALLUM, Andrew ; H UANG, Gary: Automatic Categorization
of Email into Folders: Benchmark Experiments on Enron and SRI Corpora / University of Massachusetts, CIIR. 2004 (IR-418). – Forschungsbericht
Belkin u. Croft 1992
B ELKIN, Nicholas J. ; C ROFT, W. B.: Information Filtering and Information Retrieval:
Two Sides of the Same Coin? In: Communications of the ACM 35 (1992), Nr. 12, S. 29
Boone 1998
B OONE, Gary: Concept features in Re:Agent, an intelligent Email agent. In: AGENTS
’98: Proceedings of the second international conference on Autonomous agents. New York,
NY, USA : ACM Press, 1998. – ISBN 0–89791–983–1, S. 141–148
Brill 1994
B RILL, Eric: Some Advances in Transformation-Based Part of Speech Tagging. In:
National Conference on Artificial Intelligence, 1994, 722–727
Brutlag u. Meek 2000
B RUTLAG, Jake D. ; M EEK, Christopher: Challenges of the Email Domain for Text Clas-
71
sification. In: L ANGLEY, Pat (Hrsg.): Proceedings of the Seventeenth International Conference on Machine Learning (ICML 2000), Morgan Kaufmann, 2000. – ISBN 1–55860–
707–2, S. 103–110
de Carvalho u. Cohen 2005
C ARVALHO, Vitor R. ; C OHEN, William W.: On the collective classification of email
„speech acts“. In: M ARCHIONINI, Gary (Hrsg.) ; M OFFAT, Alistair (Hrsg.) ; TAIT, John
(Hrsg.): Proceedings of the 28th Annual International ACM SIGIR Conference on Research
and Development in Information Retrieval. New York : ACM, 2005, S. 345–352
Cohen 1995
C OHEN, William W.: Fast Effective Rule Induction. In: P RIEDITIS, Armand (Hrsg.) ;
R USSELL, Stuart J. (Hrsg.): Proceedings of the Twelfth International Conference on Machine
Learning (ICML 1995), Morgan Kaufmann, July 1995. – ISBN 1–55860–377–8, S. 115–
123
Cohen 1996
C OHEN, William W.: Learning rules that classify e-mail. In: Papers from the AAAI
Spring Symposium on Machine Learning in Information Access, 1996, 18–25
Cohen u. a. 2004
C OHEN, William W. ; C ARVALHO, Vitor R. ; M ITCHELL, Tom M.: Learning to Classify
Email into „Speech Acts“. In: L IN, Dekang (Hrsg.) ; W U, Dekai (Hrsg.): Proceedings
of the 2004 Conference on Empirical Methods in Natural Language Processing (EMNLP).
Barcelona, Spain : Association for Computational Linguistics, July 2004, S. 309–316
Crawford u. a. 2001
C RAWFORD, Elisabeth ; K AY, Judy ; M C C REATH, Eric: Automatic Induction of Rules
for e-mail Classification. In: Proceedings of the Sixth Australasian Document Computing
Symposium (ADCS2001). Coffs Harbour, Australia, December 2001, S. 13–20
Cunningham 1999
C UNNINGHAM, H.: Information Extraction: a User Guide (Revised Version) / University of Sheffield. 1999. – Technical Report
Diao u. a. 2000
D IAO, Yanlei ; L U, Hongjun ; W U, Dekai: A comparative study of classification-based
personal e-mail filtering. In: T ERANO, Takao (Hrsg.) ; L IU, Huan (Hrsg.) ; C HEN,
Arbee L. P. (Hrsg.): Proceedings of PAKDD-00, 4th Pacific-Asia Conference on Knowledge
Discovery and Data Mining. Kyoto, JP : Springer Verlag, Heidelberg, DE, 2000, 408–419
Finn u. Kushmerick 2004
F INN, Aidan ; K USHMERICK, Nicholas: Multi-level Boundary Classification for Information Extraction. In: B OULICAUT, Jean-François (Hrsg.) ; E SPOSITO, Floriana (Hrsg.)
; G IANNOTTI, Fosca (Hrsg.) ; P EDRESCHI, Dino (Hrsg.): ECML Bd. 3201, Springer, 2004
(Lecture Notes in Computer Science). – ISBN 3–540–23105–6, S. 111–122
72
Freitag 2000
F REITAG, Dayne: Machine Learning for Information Extraction in Informal Domains.
In: Machine Learning 39 (2000), Nr. 2/3, S. 169–202
Frommholz 2001
F ROMMHOLZ, Ingo: Automatische Kategorisierung von Web-Dokumenten, Universität
Dortmund, FB Informatik, Diplomarbeit, 2001
Fuhr u. Buckley 1991
F UHR, N. ; B UCKLEY, C.: A Probabilistic Learning Approach for Document Indexing.
In: ACM Transactions on Information Systems 9 (1991), Nr. 3, S. 223–248
Fuhr u. Pfeifer 1991
F UHR, N. ; P FEIFER, U.: Combining Model-Oriented and Description-Oriented Approaches for Probabilistic Indexing. In: Proceedings of the Fourteenth Annual International ACM SIGIR Conference on Research and Development in Information Retrieval. New
York : ACM, 1991, S. 46–56
Fuhr u. Rölleke 1998
F UHR, N. ; R ÖLLEKE, T.: HySpirit – a Probabilistic Inference Engine for Hypermedia Retrieval in Large Databases. In: Proceedings of the 6th International Conference on
Extending Database Technology (EDBT). Heidelberg et al. : Springer, 1998, S. 24–38
Fuhr 1996
F UHR, Norbert: Information Retrieval. Skriptum zur Vorlesung / Universität Dortmund, Fachbereich Informatik. 1996. – Forschungsbericht
Fuhr 2000
F UHR, Norbert: Probabilistic Datalog: Implementing Logical Information Retrieval
for Advanced Applications. In: Journal of the American Society for Information Science 51
(2000), Nr. 2, S. 95–110
Gövert u. a. 1999
G ÖVERT, Norbert ; L ALMAS, Mounia ; F UHR, Norbert: A probabilistic descriptionoriented approach for categorising Web documents. In: G AUCH, Susan (Hrsg.) ;
S OONG, Il-Yeol (Hrsg.): Proceedings of the Eighth International Conference on Information and Knowledge Management. New York : ACM, 1999, S. 475–482
Holthausen u. a. 2000
Schutzrecht DE 19859838 A1 – Offenlegungsschrift ( Juni 2000). H OLTHAUSEN, Klaus
; B REIDBACH, Olaf ; K HAIKINE, Maxim ; F LIGUIL, Oleg (Erfinder).
Joachims 1998
J OACHIMS, Thorsten: Text categorization with support vector machines: learning with
many relevant features. In: N ÉDELLEC, Claire (Hrsg.) ; R OUVEIROL, Céline (Hrsg.):
Proceedings of ECML-98, 10th European Conference on Machine Learning. Heidelberg et
al. : Springer, 1998, 137–142
kiib
73
Kim u. Ross 2006
K IM, Yunhyong ; R OSS, Seamus: Genre Classification in Automated Ingest and Appraisal Metadata. In: G ONZALO, Julio (Hrsg.) ; T HANOS, Costantino (Hrsg.) ; V ERDE JO , M. F. (Hrsg.) ; C ARRASCO, Rafael C. (Hrsg.): Research and Advanced Technology for
Digital Libraries. Proc. of the 10th European Conference on Digital Libraries (ECDL 2006).
Heidelberg et al. : Springer, September 2006 (Lecture Notes in Computer Science), S.
63–74
Klas u. Fuhr 2000
K LAS, Claus-Peter ; F UHR, Norbert: A new Effective Approach for Categorizing Web
Documents. In: Proceedings of the 22th BCS-IRSG Colloquium on IR Research, 2000
Klimt u. Yang 2004
K LIMT, Bryan ; YANG, Yiming: The Enron Corpus: A New Dataset for Email Classification Research. In: C ARBONELL, J. G. (Hrsg.) ; S IEKMANN, J. (Hrsg.): Proc. of the
15th European Conference on Machine Learning (ECML 2004) Bd. 3201/2004. Pisa, Italy :
Springer, September 2004 (Lecture Notes in Artificial Intelligence), S. 217–226
Kosseim u. a. 2001
K OSSEIM, Leila ; B EAUREGARD, Stéphane ; L APALME, Guy: Using Information Extraction and Natural Language Generation to Answer E-Mail. In: NLDB ’00: Proceedings
of the 5th International Conference on Applications of Natural Language to Information Systems – Revised Papers. London, UK : Springer-Verlag, 2001. – ISBN 3–540–41943–8, S.
152–163
Laender u. a. 2002
L AENDER, Alberto H. F. ; R IBEIRO -N ETO, Berthier A. ; S ILVA, Altigran S. ; T EIXEIRA,
Juliana S.: A brief survey of web data extraction tools. In: SIGMOD Rec. 31 (2002), Nr.
2, S. 84–93. – ISSN 0163–5808
Mani u. Maybury 1999
M ANI, Inderjeet (Hrsg.) ; M AYBURY, Mark T. (Hrsg.): Advances in automatic text summarization. MIT Press, 1999. – ISBN 0262133598
Nenkova u. Bagga 2003
N ENKOVA, Ani ; B AGGA, Amit: Email classification for contact centers. In: SAC ’03:
Proceedings of the 2003 ACM symposium on Applied computing. New York, NY, USA :
ACM Press, 2003. – ISBN 1–58113–624–2, S. 789–792
Nottelmann 2005
N OTTELMANN, H.: PIRE: An extensible IR engine based on probabilistic Datalog.
In: L OSADA, David E. (Hrsg.) ; L UNA, Juan M. F. (Hrsg.): 27th European Conference on
Information Retrieval Research (ECIR 2005), 2005
Nottelmann u. Fuhr 2001
N OTTELMANN, H. ; F UHR, N.: Learning probabilistic Datalog rules for information
74
classification and transformation. In: PAQUES, Henrique (Hrsg.) ; L IU, Ling (Hrsg.) ;
G ROSSMAN, David (Hrsg.): Proceedings of the 10th International Conference on Information and Knowledge Management. New York : ACM, 2001, S. 387–394
Nottelmann u. Fuhr 2003
N OTTELMANN, H. ; F UHR, N.: From uncertain inference to probability of relevance for
advanced IR applications. In: S EBASTIANI, Fabrizio (Hrsg.): 25th European Conference
on Information Retrieval Research (ECIR 2003). Heidelberg et al. : Springer, 2003, S. 235–
250
Nottelmann 2001
N OTTELMANN, Henrik: Lernen unsicherer Regeln für HySpirit, Universität Dortmund,
Fachbereich Informatik, Diplomarbeit, April 2001
Pang u. a. 2002
PANG, Bo ; L EE, Lillian ; VAITHYANATHAN, Shivakumar: Thumbs up? Sentiment
Classification using Machine Learning Techniques. In: Proc. of the 2002 Conference on
Empirical Methods in Natural Language Processing (EMNLP), 2002, S. 79–86
Perer u. a. 2005
P ERER, Adam ; S HNEIDERMAN, Ben ; O ARD, Douglas: Using Rhythms of Relationships to Understand Email Archives / University of Maryland. 2005 (HCIL-2005-08).
– Forschungsbericht. – To appear in the Journal of the American Society for Information Science and Technology
Pfeifer 1990
P FEIFER, U.: Development of Log-Linear and Linear-Iterative Indexing Functions (in German), TH Darmstadt, FB Informatik, Datenverwaltungssysteme II, Diplomarbeit, 1990
Platt 2000
P LATT, J.: Probabilistic outputs for support vector machines and comparison to regularize likelihood methods. In: S MOLA, A.J. (Hrsg.) ; B ARTLETT, P. (Hrsg.) ; S CHOEL KOPF , B. (Hrsg.) ; S CHUURMANS , D. (Hrsg.): Advances in Large Margin Classifiers, 2000,
61–74
Pollmann 1993
P OLLMANN, Michael: Entwicklung und Untersuchung von verbesserten probabilistischen
Indexierungsfunktionen für Freitext-Indexierung (in German), Universität Dortmund,
Fachbereich Informatik, Diplomarbeit, 1993
Provost 1999
P ROVOST, Jefferson: Naive-Bayes vs. Rule-Learning in Classification of Email / The
University of Texas at Austin, Department of Computer Sciences. 1999 (AI-TR-99-284).
– Forschungsbericht
kiib
75
van Rijsbergen 1986
R IJSBERGEN, C. J.: A Non-Classical Logic for Information Retrieval. In: The Computer
Journal 29 (1986), Nr. 6, S. 481–485
van Rijsbergen 1992
R IJSBERGEN, C. J.: Probabilistic Retrieval Revisited. In: The Computer Journal 35 (1992),
Nr. 3, S. 291–298
Robertson 1977
R OBERTSON, S. E.: The Probability Ranking Principle in IR. In: Journal of Documentation
33 (1977), S. 294–304
Sebastiani 2002
S EBASTIANI, Fabrizio: Machine learning in automated text categorization. In: ACM
Computing Surveys 34 (2002), Nr. 1, S. 1–47
Segal u. Kephart 1999
S EGAL, Richard B. ; K EPHART, Jeffrey O.: MailCat: an intelligent assistant for organizing e-mail. In: AGENTS ’99: Proceedings of the third annual conference on Autonomous
Agents. New York, NY, USA : ACM Press, 1999. – ISBN 1–58113–066–X, S. 276–282
Semeraro u. a. 2001
S EMERARO, Giovanni ; F ERILLI, Stefano ; FANIZZI, Nicola ; E SPOSITO, Floriana: Document Classification and Interpretation through the Inference of Logic-Based Models.
In: C ONSTANTOPOULOS, Panos (Hrsg.) ; S ØLVBERG, Ingeborg T. (Hrsg.): Research and
Advanced Technology for Digital Libraries. Proc. European Conference on Digital Libraries
(ECDL 2001) Bd. 2163. Heidelberg et al. : Springer, 2001 (Lecture Notes in Computer
Science), S. 59–70
Soderland 1999
S ODERLAND, Stephen: Learning Information Extraction Rules for Semi-Structured
and Free Text. In: Machine Learning 34 (1999), Nr. 1-3, S. 233–272. – citeseer.ist.
psu.edu/soderland99learning.html
Venolia u. a. 2001
V ENOLIA, G. ; D ABBISH, L. ; C ADIZ, J. ; G UPTA, A.: Supporting email workflow /
Microsoft Research, Collaboration & Multimedia Group. Version: 2001. http://
citeseer.ist.psu.edu/venolia01supporting.html. 2001 (MSR-TR-200188). – Forschungsbericht
Voorhees u. Buckland 2005
V OORHEES, E. M. (Hrsg.) ; B UCKLAND, Lori P. (Hrsg.): The Fourteenth Text REtrieval
Conference (TREC 2005). Gaithersburg, MD, USA : NIST, 2005
Yang 1994
YANG, Yiming: Expert Network: Effective and Efficent Learning from Human Decisions in Text Categorisation and Retrieval. In: C ROFT, Bruce W. (Hrsg.) ; R IJSBERGEN,
76
C. J. (Hrsg.): Proceedings of the Seventeenth Annual International ACM SIGIR Conference
on Research and Development in Information Retrieval. London, et al. : Springer-Verlag,
1994, S. 13–22
Yang u. Liu 1999
YANG, Yiming ; L IU, Xin: A re-examination of text categorization methods. In: Proceedings of the 22nd International Conference on Research and Development in Information
Retrieval. New York : ACM, 1999, S. 42–49
kiib

Volltext - an der Universität Duisburg

Transcrição

Documentos relacionados

1. www.lo-net2.de eingeben in Internetexplorer oder anderen

Email-Tipps - Treffpunkt Freiburg

Automatische Zertifikatssuche in Thunderbird einrichten

Die E-Mail-Netiquette Inhaltsverzeichnis 1 Ziele

Outlook Express Einrichten von eMail-Adressen und eMail

ERASMUS in Nizza - Heinrich-Heine

WIN-911®

¨Ubungsblatt 6 Aufgabe 1: Codebreaker (6 Punkte, B)

Hosting Pakete - Starter Kit XL - i-net

AGB herunterladen als PDF-Datei