KI-Methoden zur Email-Archivierung -- Technologische Studie zum "Inbox-Szenario"
Available from
Ingo Frommholz's profile on Mendeley.
Page 1
KI-Methoden zur Email-Archivierung -- Technologische Studie zum "Inbox-Szenario"
KI-Methoden zur Email-Archivierung
Technologische Studie zum „Inbox-Szenario“
Ingo Frommholz und Norbert Fuhr
8. November 2006
UNIVERSITÄTD U I S B U R GE S S E N
Fakultät für Ingenieurwissenschaften
Universität Duisburg-Essen
47048 Duisburg
Technologische Studie zum „Inbox-Szenario“
Ingo Frommholz und Norbert Fuhr
8. November 2006
UNIVERSITÄTD U I S B U R GE S S E N
Fakultät für Ingenieurwissenschaften
Universität Duisburg-Essen
47048 Duisburg
Page 3
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 relevan-
ten Informationen aus Emails. Als Beispielkollektion dient uns dabei der vor einigen
Jahren freigegebene Enron-Korpus, der insgesamt aus 619.446 Nachrichten von 158 Be-
nutzern enthält und somit sehr repräsentativ für das Benutzerverhalten bei der Email-
Kategorisierung 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 Fol-
derschema sowie deren Inhalt sind ständigen Veränderungen unterzogen, die ein Katego-
risierungsverfahren 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 Kategorisie-
rung 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 haupt-
sächlich zur Textklassifikation eingesetzt wurden:
• Mittel probabilistischer, entscheidungsorientierter Ansätze ist es möglich, verschie-
dene Term- und Dokumenteigenschaften (z.B., ob ein Term im Betreff einer Email
auftaucht) zu berücksichtigen. Regressionsfunktionen können nun eine Indexie-
rungsfunktion 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. Fol-
der angewendet werden.
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 relevan-
ten Informationen aus Emails. Als Beispielkollektion dient uns dabei der vor einigen
Jahren freigegebene Enron-Korpus, der insgesamt aus 619.446 Nachrichten von 158 Be-
nutzern enthält und somit sehr repräsentativ für das Benutzerverhalten bei der Email-
Kategorisierung 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 Fol-
derschema sowie deren Inhalt sind ständigen Veränderungen unterzogen, die ein Katego-
risierungsverfahren 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 Kategorisie-
rung 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 haupt-
sächlich zur Textklassifikation eingesetzt wurden:
• Mittel probabilistischer, entscheidungsorientierter Ansätze ist es möglich, verschie-
dene Term- und Dokumenteigenschaften (z.B., ob ein Term im Betreff einer Email
auftaucht) zu berücksichtigen. Regressionsfunktionen können nun eine Indexie-
rungsfunktion 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. Fol-
der angewendet werden.
Page 4
4• Ein Ranking absteigend nach der berechneten Wahrscheinlichkeit P(d → C), dass
ein Dokument eine Kategorie impliziert, kann potentiell zu minimalem Benutzer-
aufwand führen.
• Dr. Holthausen-Netzwerke stellen eine weitere Möglichkeit der Email-
Kategorisierung dar, wobei diese mit den entscheidungsorientierten Ansätzen
kombiniert werden können.
• Verfahren zum Lernen probabilistischer Regeln verknüpfen die Vorteile der regelba-
sierten 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 vorge-
gebenen Templates oder Frames geeignete Instanzen aus Emails zu extrahieren. Wir zei-
gen, dass sowohl die Bearbeitung als auch die Archivierung von Emails von der Informa-
tionsextraktion 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 Anwen-
dungsfällen verglichen wird. Wir stellen danach einige Informationsextraktionsverfahren
vor. Es bestätigt sich, dass die Informationsextraktion aus Texten eine sehr große Heraus-
forderung 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 Text-
fragmenten (Einteilung in „enthält eine gesuchte Instanz“ oder „enthält keine ge-
suchte 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 Extraktionsergeb-
nis gar nicht erforderlich, sondern wir können hier mit den auftretenden Unsicher-
heiten 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 er-
kannt und aus ihr die relevanten Daten extrahiert werden, die dann gemäß des vor-
liegenden Workflows weiter bearbeitet werden.
2. Das Email-Archiv kann so genannten wissensintensiven Aufgaben als wertvolle In-
formationsquelle dienen. Solche wissensintensiven Aufgaben produzieren in der
kiib
ein Dokument eine Kategorie impliziert, kann potentiell zu minimalem Benutzer-
aufwand führen.
• Dr. Holthausen-Netzwerke stellen eine weitere Möglichkeit der Email-
Kategorisierung dar, wobei diese mit den entscheidungsorientierten Ansätzen
kombiniert werden können.
• Verfahren zum Lernen probabilistischer Regeln verknüpfen die Vorteile der regelba-
sierten 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 vorge-
gebenen Templates oder Frames geeignete Instanzen aus Emails zu extrahieren. Wir zei-
gen, dass sowohl die Bearbeitung als auch die Archivierung von Emails von der Informa-
tionsextraktion 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 Anwen-
dungsfällen verglichen wird. Wir stellen danach einige Informationsextraktionsverfahren
vor. Es bestätigt sich, dass die Informationsextraktion aus Texten eine sehr große Heraus-
forderung 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 Text-
fragmenten (Einteilung in „enthält eine gesuchte Instanz“ oder „enthält keine ge-
suchte 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 Extraktionsergeb-
nis gar nicht erforderlich, sondern wir können hier mit den auftretenden Unsicher-
heiten 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 er-
kannt und aus ihr die relevanten Daten extrahiert werden, die dann gemäß des vor-
liegenden Workflows weiter bearbeitet werden.
2. Das Email-Archiv kann so genannten wissensintensiven Aufgaben als wertvolle In-
formationsquelle dienen. Solche wissensintensiven Aufgaben produzieren in der
kiib
Page 5
5Regel 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.
KI-Methoden zur Email-Archivierung
aus dem Information Retrieval (wie z.B. der Suche nach relevanten Emails oder auch
nach Experten) gesättigt werden können.
KI-Methoden zur Email-Archivierung
Page 6
Inhaltsverzeichnis
1 Einleitung 8
2 Anwendungsfälle und Problemstellungen im Inbox-Szenario 10
2.1 Das Inbox-Szenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.1.1 Beschreibung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.1.2 Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.1.3 Erweitertes Szenario: Ontologien und Annotationen . . . . . . . . . 13
2.2 Problemstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2.1 Information Retrieval . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2.2 Datenbanken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.2.3 Summarization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.2.4 Informationsextraktion . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.2.5 Kategorisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3 Analyse der Datenbasis 18
3.1 Der Enron-Korpus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.2 Multifacettenklassifikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4 Email-Kategorisierung 23
4.1 Bisherige Erfahrungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.1.1 Evaluierungsmaße . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.1.2 Verfahren aus der Textklassifikation . . . . . . . . . . . . . . . . . . . 25
4.1.3 Regelbasierte Ansätze . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.1.4 Zusammenfassung der bisherigen Klassifikationsverfahren . . . . . 34
4.2 Mögliche neue Ansätze . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.2.1 Probabilistische, entscheidungsorientierte Verfahren . . . . . . . . . 35
4.2.2 Dr. Holthausen-Netzwerke . . . . . . . . . . . . . . . . . . . . . . . . 44
4.2.3 Lernen probabilistischer Regeln . . . . . . . . . . . . . . . . . . . . . 45
4.2.4 Andere Verfahren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5 Informationsextraktion 52
5.1 Überblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.2 Beispiel: Beantworten von Emails . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.3 Ansätze zur Informationsextraktion . . . . . . . . . . . . . . . . . . . . . . . 55
5.3.1 WHISK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.3.2 SRV / Kategorisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
1 Einleitung 8
2 Anwendungsfälle und Problemstellungen im Inbox-Szenario 10
2.1 Das Inbox-Szenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.1.1 Beschreibung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.1.2 Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.1.3 Erweitertes Szenario: Ontologien und Annotationen . . . . . . . . . 13
2.2 Problemstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2.1 Information Retrieval . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2.2 Datenbanken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.2.3 Summarization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.2.4 Informationsextraktion . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.2.5 Kategorisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3 Analyse der Datenbasis 18
3.1 Der Enron-Korpus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.2 Multifacettenklassifikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4 Email-Kategorisierung 23
4.1 Bisherige Erfahrungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.1.1 Evaluierungsmaße . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.1.2 Verfahren aus der Textklassifikation . . . . . . . . . . . . . . . . . . . 25
4.1.3 Regelbasierte Ansätze . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.1.4 Zusammenfassung der bisherigen Klassifikationsverfahren . . . . . 34
4.2 Mögliche neue Ansätze . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.2.1 Probabilistische, entscheidungsorientierte Verfahren . . . . . . . . . 35
4.2.2 Dr. Holthausen-Netzwerke . . . . . . . . . . . . . . . . . . . . . . . . 44
4.2.3 Lernen probabilistischer Regeln . . . . . . . . . . . . . . . . . . . . . 45
4.2.4 Andere Verfahren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5 Informationsextraktion 52
5.1 Überblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.2 Beispiel: Beantworten von Emails . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.3 Ansätze zur Informationsextraktion . . . . . . . . . . . . . . . . . . . . . . . 55
5.3.1 WHISK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.3.2 SRV / Kategorisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Page 7
Inhaltsverzeichnis 7
5.3.3 ELIE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.4 Beurteilung der Verfahren zur Informationsextraktion . . . . . . . . . . . . . 63
5.5 Anwendung der Informationsextraktion im Inbox-Szenario . . . . . . . . . 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
KI-Methoden zur Email-Archivierung
5.3.3 ELIE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.4 Beurteilung der Verfahren zur Informationsextraktion . . . . . . . . . . . . . 63
5.5 Anwendung der Informationsextraktion im Inbox-Szenario . . . . . . . . . 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
KI-Methoden zur Email-Archivierung
Page 8
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 Email-
Kollektionen 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ünsch-
ten Email einen hohen kognitiven Aufwand vom Benutzer. Abhilfe kann hier mit der Be-
reitstellung eines persönlichen Email-Assistenten geschaffen werden, der den Benutzer bei
den anfallenden Aufgaben im Zusammenhang mit der Email-Bearbeitung und Archivie-
rung 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 Hinter-
grundinformationen 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 Organisatorisch Sozial
Gegenwärtig
Region A:
Individuelle
Inbox des Benut-
zers
Region B:
Email innerhalb
einer Organisati-
on
Region C:
Öffentliche Dis-
kussion
Archiviert
Region D:
Individuelle
Mailbox des
Benutzers
Region E:
Email-Archiv der
Organisation
Region F:
Öffentliche
Email-Archive
Tabelle 1.1: Interaktionstypen mit Email-Kollektionen (Perer u. a. 2005)
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 Email-
Kollektionen 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ünsch-
ten Email einen hohen kognitiven Aufwand vom Benutzer. Abhilfe kann hier mit der Be-
reitstellung eines persönlichen Email-Assistenten geschaffen werden, der den Benutzer bei
den anfallenden Aufgaben im Zusammenhang mit der Email-Bearbeitung und Archivie-
rung 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 Hinter-
grundinformationen 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 Organisatorisch Sozial
Gegenwärtig
Region A:
Individuelle
Inbox des Benut-
zers
Region B:
Email innerhalb
einer Organisati-
on
Region C:
Öffentliche Dis-
kussion
Archiviert
Region D:
Individuelle
Mailbox des
Benutzers
Region E:
Email-Archiv der
Organisation
Region F:
Öffentliche
Email-Archive
Tabelle 1.1: Interaktionstypen mit Email-Kollektionen (Perer u. a. 2005)
Page 9
9Inbox 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 archi-
vieren. Dies umfasst insbesondere die Klassifikation von Emails, d.h. die Einsortierung in
bestimmte Kategorien nach bestimmten Facetten, sowie die Informations- undAttributex-
traktion. 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) Ordner-
oder Folderstruktur, die vom jeweiligen Benutzer angelegt wurde.
Im weiteren Verlauf dieser Studie werden wir zunächst einmal konkrete Problemstel-
lungen ansprechen, bevor wir eine repräsentative Datenbasis, den Enron-Korpus, in Ka-
pitel 3 analysieren. In den darauf folgenden Kapiteln 4 und 5 werden Methoden zur Klas-
sifikation und Attributextraktion besprochen. Da das Inbox-Szenario häufig Ausgangs-
punkt 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 Gemeinschaftsinitiati-
ve 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.
KI-Methoden zur Email-Archivierung
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 archi-
vieren. Dies umfasst insbesondere die Klassifikation von Emails, d.h. die Einsortierung in
bestimmte Kategorien nach bestimmten Facetten, sowie die Informations- undAttributex-
traktion. 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) Ordner-
oder Folderstruktur, die vom jeweiligen Benutzer angelegt wurde.
Im weiteren Verlauf dieser Studie werden wir zunächst einmal konkrete Problemstel-
lungen ansprechen, bevor wir eine repräsentative Datenbasis, den Enron-Korpus, in Ka-
pitel 3 analysieren. In den darauf folgenden Kapiteln 4 und 5 werden Methoden zur Klas-
sifikation und Attributextraktion besprochen. Da das Inbox-Szenario häufig Ausgangs-
punkt 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 Gemeinschaftsinitiati-
ve 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.
KI-Methoden zur Email-Archivierung
Page 10
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. Die-
ser 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 gehenwir 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 wichti-
gen 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, Ordner-
struktur anlegen. Einkommenden Emails können zur Archivierung in geeignete Ordner
verschoben werden und sind durch Browsing dieser Ordnerstruktur relativ einfach wie-
der 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 Inbox-
Szenario 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 ein-
zige 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
im Inbox-Szenario
2.1 Das Inbox-Szenario
Es soll nun zunächst mal auf das zu Grunde liegende Szenario eingegangen werden. Die-
ser 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 gehenwir 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 wichti-
gen 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, Ordner-
struktur anlegen. Einkommenden Emails können zur Archivierung in geeignete Ordner
verschoben werden und sind durch Browsing dieser Ordnerstruktur relativ einfach wie-
der 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 Inbox-
Szenario 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 ein-
zige 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
Page 11
2.1 DAS INBOX-SZENARIO 11
Benutzer
Recherchieren
Known-Item-Suche
Diskussionssuche
Personensuche
Autom. Priorisieren
Selektieren
Öffnen
<<extend>>
Kontext zeigen
<<extend>>
Relevante Emails zeigen
Kontakt- und Termininfo anzeigen
Zusammenfassen
Kategorisieren
Priorisieren
<<extend>>
<<extend>>
<<extend>> Manuell kategorisieren
Automatisch vorkategorisieren
0..*
0..*
0..*
<<extend>>
Suchagent
Extraktionsagent
Kategorisierungsagent
Datenbankagent
Extrahieren
<<extend>>
Email-Suche
BenachrichtigungsagentBenachrichtigen
0..*
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 Recher-
chen beinhalten, neben anderen, die Known-Item-Suche, bei der der Benutzer ein schon
einmal gesehenes Dokument wiederfinden möchte. Die Email-Suche dient dem Wieder-
auffinden von bereits archivierten Emails; der Benutzer kann dabei eine Anfrage formu-
lieren 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. Dement-
sprechend 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 aus-
1Streng genommen beziehen sich die Recherchemöglichkeiten nicht auf die Inbox allein, sondern auf den
gesamten Mailkorpus des Benutzers
KI-Methoden zur Email-Archivierung
Benutzer
Recherchieren
Known-Item-Suche
Diskussionssuche
Personensuche
Autom. Priorisieren
Selektieren
Öffnen
<<extend>>
Kontext zeigen
<<extend>>
Relevante Emails zeigen
Kontakt- und Termininfo anzeigen
Zusammenfassen
Kategorisieren
Priorisieren
<<extend>>
<<extend>>
<<extend>> Manuell kategorisieren
Automatisch vorkategorisieren
0..*
0..*
0..*
<<extend>>
Suchagent
Extraktionsagent
Kategorisierungsagent
Datenbankagent
Extrahieren
<<extend>>
Email-Suche
BenachrichtigungsagentBenachrichtigen
0..*
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 Recher-
chen beinhalten, neben anderen, die Known-Item-Suche, bei der der Benutzer ein schon
einmal gesehenes Dokument wiederfinden möchte. Die Email-Suche dient dem Wieder-
auffinden von bereits archivierten Emails; der Benutzer kann dabei eine Anfrage formu-
lieren 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. Dement-
sprechend 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 aus-
1Streng genommen beziehen sich die Recherchemöglichkeiten nicht auf die Inbox allein, sondern auf den
gesamten Mailkorpus des Benutzers
KI-Methoden zur Email-Archivierung
Page 12
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 Behand-
lung 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 rea-
gieren, muss der Benutzer in der Regel Kontextinformationen einholen. So kann es nützlich
sein, relevante Emails anzuzeigen (wobei das angewandte Relevanzkriterium hier unberück-
sichtigt gelassenwerden soll), umwertvolle Hintergrundinformationen für einen Vorgang
zu bekommen. Werden Personen in der Email erwähnt, können die zugehörigen Kontakt-
informationen angezeigt werden. Werden Termine in der Email vorgeschlagen, können alle
eigenen Termine, die in den angesprochenen Zeitraum fallen, aus dem persönlichen Ter-
minkalender 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 Zusammen-
fassung reicht. Ferner wäre es interessant, die je nach Dokumenttyp relevanten Informa-
tionen 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 kategorisiertwerden. Die Kategorisierung kannma-
nuell vorgenommen werden. Es kann aber auch eine automatische Vorkategorisierung statt-
finden, 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 Priori-
tä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 wer-
den, die im Diagramm als gesonderte Akteure auftreten. So kann ein Suchagent herange-
kiib
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 Behand-
lung 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 rea-
gieren, muss der Benutzer in der Regel Kontextinformationen einholen. So kann es nützlich
sein, relevante Emails anzuzeigen (wobei das angewandte Relevanzkriterium hier unberück-
sichtigt gelassenwerden soll), umwertvolle Hintergrundinformationen für einen Vorgang
zu bekommen. Werden Personen in der Email erwähnt, können die zugehörigen Kontakt-
informationen angezeigt werden. Werden Termine in der Email vorgeschlagen, können alle
eigenen Termine, die in den angesprochenen Zeitraum fallen, aus dem persönlichen Ter-
minkalender 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 Zusammen-
fassung reicht. Ferner wäre es interessant, die je nach Dokumenttyp relevanten Informa-
tionen 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 kategorisiertwerden. Die Kategorisierung kannma-
nuell vorgenommen werden. Es kann aber auch eine automatische Vorkategorisierung statt-
finden, 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 Priori-
tä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 wer-
den, die im Diagramm als gesonderte Akteure auftreten. So kann ein Suchagent herange-
kiib
Page 13
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, re-
levante Informationen aus der Email zu ziehen, die dann Datenbankagenten genutzt wird,
um zugehörige Kontextinformation zu bereitzustellen. Wurde z.B. der Name einer Per-
son extrahiert, kann nun in der Datenbank die jeweilige Kontaktinformation nachgefragt
werden. Schließlich kann die automatische Vorkategorisierung von einem bestimmten Ka-
tegorisierungsagenten vorgenommenwerden; ein derartiger Agent kann auch zur Priorisie-
rung 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 Benachrichtigungs-
agent 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 hierarchi-
schen Ordnerstruktur ablegen kann. Eine solche Hierarchie hat aber gewisse Nachteile,
da zwischen den einzelnen Ordnern nur eine hierarchische Beziehung hergestellt wer-
den 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 Reise-
bestätigung einer Fluggesellschaft zu tun, auf der die Daten für eine Dienstreise zu fin-
den 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 rele-
vanten Emails zu finden. Es wäre also sinnvoll, Emails in eine komplexere Datenstruktur
zu indexieren, die ein schnelles Auffinden hinsichtlich verschiedener Facetten und Infor-
mationsbedü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. Kon-
zepte enthalten dabei bestimmte Attribute, die die jeweilige Klasse beschreiben. Instan-
zen eines Konzepts (oder einer Klasse) sind die Objekte der Ontologie. Mit Ontologien
lassen sich recht komplexe Wissenstrukturen modellieren, die sich zur Recherche in ei-
nem 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 ver-
knüpft werden. Ferner könnten alle Instanzen Referenzen zu relevanten Email enthal-
ten. Somit wäre die Bearbeitung komplexerer Suchanfragen möglich. Wird beispielsweise
nach den Emails eines bestimmtem Projekts gesucht, könnten dem Benutzer die Email-
KI-Methoden zur Email-Archivierung
zogen werden, wenn es um die einzelnen Rechercheaufgaben geht oder nach relevanten
(z.B. ähnlichen) Emails gesucht wird. Ein Extraktionsagent wiederum hat die Aufgabe, re-
levante Informationen aus der Email zu ziehen, die dann Datenbankagenten genutzt wird,
um zugehörige Kontextinformation zu bereitzustellen. Wurde z.B. der Name einer Per-
son extrahiert, kann nun in der Datenbank die jeweilige Kontaktinformation nachgefragt
werden. Schließlich kann die automatische Vorkategorisierung von einem bestimmten Ka-
tegorisierungsagenten vorgenommenwerden; ein derartiger Agent kann auch zur Priorisie-
rung 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 Benachrichtigungs-
agent 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 hierarchi-
schen Ordnerstruktur ablegen kann. Eine solche Hierarchie hat aber gewisse Nachteile,
da zwischen den einzelnen Ordnern nur eine hierarchische Beziehung hergestellt wer-
den 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 Reise-
bestätigung einer Fluggesellschaft zu tun, auf der die Daten für eine Dienstreise zu fin-
den 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 rele-
vanten Emails zu finden. Es wäre also sinnvoll, Emails in eine komplexere Datenstruktur
zu indexieren, die ein schnelles Auffinden hinsichtlich verschiedener Facetten und Infor-
mationsbedü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. Kon-
zepte enthalten dabei bestimmte Attribute, die die jeweilige Klasse beschreiben. Instan-
zen eines Konzepts (oder einer Klasse) sind die Objekte der Ontologie. Mit Ontologien
lassen sich recht komplexe Wissenstrukturen modellieren, die sich zur Recherche in ei-
nem 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 ver-
knüpft werden. Ferner könnten alle Instanzen Referenzen zu relevanten Email enthal-
ten. Somit wäre die Bearbeitung komplexerer Suchanfragen möglich. Wird beispielsweise
nach den Emails eines bestimmtem Projekts gesucht, könnten dem Benutzer die Email-
KI-Methoden zur Email-Archivierung
Page 15
2.2 PROBLEMSTELLUNG 15
2.2 Problemstellung
Aus dem im letzten Abschnitt diskutierten Use Cases ergeben sich einige Problemstel-
lungen, 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 Kate-
gorisierung.
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, wich-
tige Email wiederzufinden. Ein typisches Anwendungsbeispiel hier ist die Suche
nach Ankündigungen für Projekttreffen, die auch Zeit und Ort dieses Treffens bein-
halten. Andere Beispiele sind dasWiederfinden von Protokollen oder anderen wich-
tigen 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 Do-
kumentklassifikation und Informationsextraktion hier gewinnbringend eingesetzt
werden können.
Email-Suche Hier geht es darum, thematisch relevante, bereits archivierte Emails zu fin-
den. Der Benutzer stellt dabei eine Anfrage; Emails sind die Dokumente, über denen
gesucht wird. Das System berechnet eine Rangordnung der Emails gemäß ihrem Re-
trievalgewicht.
Diskussionssuche Ähnlich wie bei der Email-Suche geht es bei der Diskussionsuche
darum, aus Email-Diskussionen thematisch relevante Emails zu finden. Als weite-
rer 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 an-
dere 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
KI-Methoden zur Email-Archivierung
2.2 Problemstellung
Aus dem im letzten Abschnitt diskutierten Use Cases ergeben sich einige Problemstel-
lungen, 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 Kate-
gorisierung.
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, wich-
tige Email wiederzufinden. Ein typisches Anwendungsbeispiel hier ist die Suche
nach Ankündigungen für Projekttreffen, die auch Zeit und Ort dieses Treffens bein-
halten. Andere Beispiele sind dasWiederfinden von Protokollen oder anderen wich-
tigen 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 Do-
kumentklassifikation und Informationsextraktion hier gewinnbringend eingesetzt
werden können.
Email-Suche Hier geht es darum, thematisch relevante, bereits archivierte Emails zu fin-
den. Der Benutzer stellt dabei eine Anfrage; Emails sind die Dokumente, über denen
gesucht wird. Das System berechnet eine Rangordnung der Emails gemäß ihrem Re-
trievalgewicht.
Diskussionssuche Ähnlich wie bei der Email-Suche geht es bei der Diskussionsuche
darum, aus Email-Diskussionen thematisch relevante Emails zu finden. Als weite-
rer 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 an-
dere 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
KI-Methoden zur Email-Archivierung
Page 16
16 2 ANWENDUNGSFÄLLE UND PROBLEMSTELLUNGEN IM INBOX-SZENARIO
Emails wären in diesem Fall thematisch ähnliche Emails, so dass wir es hier mit ei-
nem typischen Suchproblem zu tun haben. Die aktuelle Email kann dabei als eine
Anfrage an den Email-Korpus gesehen werden, wobei das System dann eine Rang-
ordnung 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 hinzie-
len.
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. Dement-
sprechend 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 Auf-
gabe, aus dem Text Namen und Termine zu extrahieren. Mittels einer Datenban-
kabfrage kann dann z.B. aus dem persönlichen Adressbuch die Kontaktdaten der
extrahierten Personen angezeigt werden. Für extrahierte Termine könnte eine An-
zeige 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 unmittelba-
ren Problemstellung, dass zunächst einmal Personen und Termine erkannt und mit
entsprechenden Einträgen in der Datenbank assoziiert werden müssen. Das Erken-
nen 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 ei-
ne Problemstellung des Information Retrieval darstellt. Die Informationsextraktion
kiib
Emails wären in diesem Fall thematisch ähnliche Emails, so dass wir es hier mit ei-
nem typischen Suchproblem zu tun haben. Die aktuelle Email kann dabei als eine
Anfrage an den Email-Korpus gesehen werden, wobei das System dann eine Rang-
ordnung 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 hinzie-
len.
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. Dement-
sprechend 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 Auf-
gabe, aus dem Text Namen und Termine zu extrahieren. Mittels einer Datenban-
kabfrage kann dann z.B. aus dem persönlichen Adressbuch die Kontaktdaten der
extrahierten Personen angezeigt werden. Für extrahierte Termine könnte eine An-
zeige 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 unmittelba-
ren Problemstellung, dass zunächst einmal Personen und Termine erkannt und mit
entsprechenden Einträgen in der Datenbank assoziiert werden müssen. Das Erken-
nen 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 ei-
ne Problemstellung des Information Retrieval darstellt. Die Informationsextraktion
kiib
Page 17
2.2 PROBLEMSTELLUNG 17
kann aber auch hier Hilfestellung leisten, wie wir in Abschnitt 5.5 diskutieren wer-
den.
Extrahieren Hier geht es darum, aus einer Email relevante Daten zu extrahieren. Han-
delt 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ön-
nen.
2.2.5 Kategorisierung
Ein großer Teil der Problemstellungen fällt in den Bereich der Email-Kategorisierung. Ka-
tegorisierungsmethoden 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 Kate-
gorisierung zu tun, da in gängigen Emailsystemen die Möglichkeit besteht, ein hier-
archische Ordnerschema anzulegen. Aufgabe der Email-Folder-Kategorisierung ist es,
für eine automatische Vorkategorisierung der Daten die passenden Ordner inner-
halb der Ordnerstruktur zu finden.
• Auch zur Priorisierung können Kategorisierungsverfahren angewendet werden,
wenn man die Aufgabe der Priorisierung als Kategorisierung in verschiedene Prio-
ritä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 unter-
schiedliche Kategorienschemata zu Grunde zu legen sind. Global betrachtet ergibt sich
daraus eineMultifacetten-Klassifikation, bei der die einzelnen Facetten unterschiedliche Ka-
tegorisierungsverfahren 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 Da-
tenbasis basieren, wie sie im nächsten Kapitel durchgeführt wird. Gesucht sind also Kate-
gorisierungsverfahren, die mit unterschiedlichen Facetten klar kommen.
KI-Methoden zur Email-Archivierung
kann aber auch hier Hilfestellung leisten, wie wir in Abschnitt 5.5 diskutieren wer-
den.
Extrahieren Hier geht es darum, aus einer Email relevante Daten zu extrahieren. Han-
delt 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ön-
nen.
2.2.5 Kategorisierung
Ein großer Teil der Problemstellungen fällt in den Bereich der Email-Kategorisierung. Ka-
tegorisierungsmethoden 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 Kate-
gorisierung zu tun, da in gängigen Emailsystemen die Möglichkeit besteht, ein hier-
archische Ordnerschema anzulegen. Aufgabe der Email-Folder-Kategorisierung ist es,
für eine automatische Vorkategorisierung der Daten die passenden Ordner inner-
halb der Ordnerstruktur zu finden.
• Auch zur Priorisierung können Kategorisierungsverfahren angewendet werden,
wenn man die Aufgabe der Priorisierung als Kategorisierung in verschiedene Prio-
ritä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 unter-
schiedliche Kategorienschemata zu Grunde zu legen sind. Global betrachtet ergibt sich
daraus eineMultifacetten-Klassifikation, bei der die einzelnen Facetten unterschiedliche Ka-
tegorisierungsverfahren 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 Da-
tenbasis basieren, wie sie im nächsten Kapitel durchgeführt wird. Gesucht sind also Kate-
gorisierungsverfahren, die mit unterschiedlichen Facetten klar kommen.
KI-Methoden zur Email-Archivierung
Page 18
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 Multifacetten-
Klassifikation 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 En-
ron freigegeben. Es handelt sich dabei um Emails, die in den Mailboxen der ehemali-
gen 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 Ord-
ner, die in den Mailboxen der meisten Benutzer auftraten, entweder als automatisch ge-
neriert („discussion_thread“ und „notes_inbox“) oder als Sammelbecken für Duplikate
(„all_documents“) identifiziert. Diese Ordner sind nicht geeignet für eine weitere Betrach-
tung, 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 meis-
ten 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 zei-
gen, 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 Be-
nutzers 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 Ex-
perimente 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 Informati-
onsextraktion mit deutschsprachlichen oder sogar multilingualen Korpora umgehen kön-
nen. Da sich beim Enron-Korpus aber inzwischen um einen Standardkorpus zumindest
1Zu beziehen unter http://www.cs.cmu.edu/~enron/
Wir werden nun die für unsere weiteren Betrachtungen zu Grunde liegende Datenbasis,
den Enron-Korpus beschreiben. Auf Basis dieser Kollektion haben wir eine Multifacetten-
Klassifikation 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 En-
ron freigegeben. Es handelt sich dabei um Emails, die in den Mailboxen der ehemali-
gen 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 Ord-
ner, die in den Mailboxen der meisten Benutzer auftraten, entweder als automatisch ge-
neriert („discussion_thread“ und „notes_inbox“) oder als Sammelbecken für Duplikate
(„all_documents“) identifiziert. Diese Ordner sind nicht geeignet für eine weitere Betrach-
tung, 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 meis-
ten 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 zei-
gen, 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 Be-
nutzers 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 Ex-
perimente 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 Informati-
onsextraktion mit deutschsprachlichen oder sogar multilingualen Korpora umgehen kön-
nen. Da sich beim Enron-Korpus aber inzwischen um einen Standardkorpus zumindest
1Zu beziehen unter http://www.cs.cmu.edu/~enron/
Page 19
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 Kate-
gorisierungsaufgabe 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 Betrach-
tung des Enron-Korpus und ein bereits vorhandenes Multifacettenschema, welches unter
http://bailando.sims.berkeley.edu/enron/enron_Categories.txt zu be-
ziehen 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
KI-Methoden zur Email-Archivierung
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 Kate-
gorisierungsaufgabe 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 Betrach-
tung des Enron-Korpus und ein bereits vorhandenes Multifacettenschema, welches unter
http://bailando.sims.berkeley.edu/enron/enron_Categories.txt zu be-
ziehen 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
KI-Methoden zur Email-Archivierung
Page 21
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 ver-
schiedene 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 be-
schreiben die Absicht des Autors. Dabei ist zu beachten, dass in einer Email natür-
lich 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
2Basierend auf der Analyse englischsprachiger Emails
3Hier nicht in der vollen Hierarchie dargestellt
KI-Methoden zur Email-Archivierung
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 ver-
schiedene 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 be-
schreiben die Absicht des Autors. Dabei ist zu beachten, dass in einer Email natür-
lich 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
2Basierend auf der Analyse englischsprachiger Emails
3Hier nicht in der vollen Hierarchie dargestellt
KI-Methoden zur Email-Archivierung
Page 22
22 3 ANALYSE DER DATENBASIS
ii. Data
iii. Meeting
iv. Logistics
v. Opinion
vi. Meeting
Die Identifikation eines bestimmten Email Acts kann verschiedene Aktionen zur
Folge haben; ein ausgehendes Commitment kann beispielsweise einen Eintrag in ei-
ner 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, Pro-
jekt 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
ii. Data
iii. Meeting
iv. Logistics
v. Opinion
vi. Meeting
Die Identifikation eines bestimmten Email Acts kann verschiedene Aktionen zur
Folge haben; ein ausgehendes Commitment kann beispielsweise einen Eintrag in ei-
ner 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, Pro-
jekt 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
Page 23
4 Email-Kategorisierung
Bei der Email-Kategorisierung geht es nun darum, Emails in die verschiedenen Katego-
rien der Multifacetten-Klassifikation, wie sie im Abschnitt 3.2 vorgestellt wurde, einzu-
ordnen. 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 dynami-
schen 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 Unterschei-
dung 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änder-
ter 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 prakti-
sche industrielle Einsetzbarkeit derselben. Abschnitt 4.2 beschäftigt sich nun mit mögli-
chen 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 vorge-
stellten Verfahren sollen die Kategorisierung hinsichtlich aller Facetten ermöglichen.
4.1 Bisherige Erfahrungen
In diesem Abschnitt sollen bisherige Verfahren zur Email-Klassifikation vorgestellt wer-
den, die experimentell evaluiert wurden und somit einen Eindruck über deren Anwend-
barkeit gewinnen lassen. Die Techniken aus dem Bereich des maschinellen Lernens lassen
Bei der Email-Kategorisierung geht es nun darum, Emails in die verschiedenen Katego-
rien der Multifacetten-Klassifikation, wie sie im Abschnitt 3.2 vorgestellt wurde, einzu-
ordnen. 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 dynami-
schen 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 Unterschei-
dung 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änder-
ter 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 prakti-
sche industrielle Einsetzbarkeit derselben. Abschnitt 4.2 beschäftigt sich nun mit mögli-
chen 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 vorge-
stellten Verfahren sollen die Kategorisierung hinsichtlich aller Facetten ermöglichen.
4.1 Bisherige Erfahrungen
In diesem Abschnitt sollen bisherige Verfahren zur Email-Klassifikation vorgestellt wer-
den, die experimentell evaluiert wurden und somit einen Eindruck über deren Anwend-
barkeit gewinnen lassen. Die Techniken aus dem Bereich des maschinellen Lernens lassen
Page 24
24 4 EMAIL-KATEGORISIERUNG
sich grob in zwei Klassen einteilen:
1. Verfahren aus der Textklassifikation, die für die gegebene Aufgabe angewendet wer-
den 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 ge-
nannte 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):
r =
#richtig vorgenommene Zuweisungen
#richtige Zuweisungen
(4.1)
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 er-
mittelt 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
sich grob in zwei Klassen einteilen:
1. Verfahren aus der Textklassifikation, die für die gegebene Aufgabe angewendet wer-
den 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 ge-
nannte 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):
r =
#richtig vorgenommene Zuweisungen
#richtige Zuweisungen
(4.1)
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 er-
mittelt 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
Page 25
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 frequen-
cy, 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 Kol-
lektion C vorhanden Terme ti (mit 1 ≤ i ≤ |T |) aufgespannt. Jede Email m wird dement-
sprechend als Vektor ~x(m) repräsentiert; die Komponente xi(m) ergibt sich aus der Vor-
kommenshäufigkeit des Terms ti in der Nachricht. Jeder Folder f wird durch den Vektor
~w( f ) repräsentiert, dessen Komponenten gewichtete Wordhäufigkeiten darstellen. ~w be-
rechnet sich dabei aus den im Folder enthaltenen Emails bzw. deren Termen als
wi( f ) = tf ( f , ti) · idf (ti)
mit
idf (ti) =
1
df (ti)2
und
df (ti) =
#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) =
ci( f )
∑ti∈ f ci( f )
und
ci( f ) =
∑
m∈ f
xi(m)
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 kategorisie-
renden Nachricht m und einem Folder f berechnet (Segal u. Kephart 1999):
SIM4(m, f ) =
∑ti∈m xi(m) · wi( f )
min
(
∑ti∈m xi(m),∑ti∈m wi( f )
)
Auf dieseWeise erhält man nun ein Ranking der Folder absteigend nach ihrer Ähnlichkeit
zur kategorisierenden Email. In dem von Segal u. Kephart beschriebenen MailCat-System
KI-Methoden zur Email-Archivierung
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 frequen-
cy, 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 Kol-
lektion C vorhanden Terme ti (mit 1 ≤ i ≤ |T |) aufgespannt. Jede Email m wird dement-
sprechend als Vektor ~x(m) repräsentiert; die Komponente xi(m) ergibt sich aus der Vor-
kommenshäufigkeit des Terms ti in der Nachricht. Jeder Folder f wird durch den Vektor
~w( f ) repräsentiert, dessen Komponenten gewichtete Wordhäufigkeiten darstellen. ~w be-
rechnet sich dabei aus den im Folder enthaltenen Emails bzw. deren Termen als
wi( f ) = tf ( f , ti) · idf (ti)
mit
idf (ti) =
1
df (ti)2
und
df (ti) =
#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) =
ci( f )
∑ti∈ f ci( f )
und
ci( f ) =
∑
m∈ f
xi(m)
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 kategorisie-
renden Nachricht m und einem Folder f berechnet (Segal u. Kephart 1999):
SIM4(m, f ) =
∑ti∈m xi(m) · wi( f )
min
(
∑ti∈m xi(m),∑ti∈m wi( f )
)
Auf dieseWeise erhält man nun ein Ranking der Folder absteigend nach ihrer Ähnlichkeit
zur kategorisierenden Email. In dem von Segal u. Kephart beschriebenen MailCat-System
KI-Methoden zur Email-Archivierung
Page 26
26 4 EMAIL-KATEGORISIERUNG
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 zentro-
iden 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 da-
zu 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 ange-
passt, 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 ein-
sortieren 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 Accu-
racy 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 (Se-
gal 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 meh-
reren 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
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 zentro-
iden 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 da-
zu 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 ange-
passt, 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 ein-
sortieren 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 Accu-
racy 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 (Se-
gal 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 meh-
reren 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
Page 27
4.1 BISHERIGE ERFAHRUNGEN 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 Da-
tenpunkte zweier Klassen möglichst sauber trennt. Solch eine Hyperebene ist im zweidi-
mensionalen Fall eine Gerade, wie in Abbildung 4.1 illustriert. Das Verfahren sucht dabei
eine Hyperebene mit einemmaximalen 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
~w ·~x− b (4.4)
wobei ~x der zu klassifizierende Datenpunkt ist. Dieser kann als Featurevektor beschrie-
ben werden, wobei jedes Element einen Term repräsentiert und dazu dessen kombiniertes
tf × idf -Gewicht genommenwird (Joachims 1998). Sobald die Hyperebene gegeben ist, be-
rechnet die Funktion
sign(~w ·~x− b) =
{
+1, wenn ~w ·~x− b > 0
−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
~w ·~x− b =
∑
i
αiK
(
~d,~di
)
+ b
KI-Methoden zur Email-Archivierung
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 Da-
tenpunkte zweier Klassen möglichst sauber trennt. Solch eine Hyperebene ist im zweidi-
mensionalen Fall eine Gerade, wie in Abbildung 4.1 illustriert. Das Verfahren sucht dabei
eine Hyperebene mit einemmaximalen 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
~w ·~x− b (4.4)
wobei ~x der zu klassifizierende Datenpunkt ist. Dieser kann als Featurevektor beschrie-
ben werden, wobei jedes Element einen Term repräsentiert und dazu dessen kombiniertes
tf × idf -Gewicht genommenwird (Joachims 1998). Sobald die Hyperebene gegeben ist, be-
rechnet die Funktion
sign(~w ·~x− b) =
{
+1, wenn ~w ·~x− b > 0
−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
~w ·~x− b =
∑
i
αiK
(
~d,~di
)
+ b
KI-Methoden zur Email-Archivierung
Page 28
28 4 EMAIL-KATEGORISIERUNG
wobei K eine so genannte Kernelfunktion darstellt. Man unterscheidet zwischen linearen
und nicht-linearen Kernelfunktionen; es sind
Klin(~d,~di) = ~d · ~di
Kpoly(~d,~di) =
(
~d · ~di + 1
)d
Krb f (~d,~di) = exp
(
γ
(
~d− ~di
)2
)
Ksigmoid(~d,~di) = tanh
(
s
(
~d · ~di
)
+ c
)
lineare, polynominale, radialbasierte und sigmoide Kernelfunktionen, die im nichtlinea-
ren Fall neue Parameter (d,γ,s,c) einführen. Die Wahl der Kernelfunktion kann das Klas-
sifikationsergebnis beeinflussen (Joachims 1998). Die di sind die so genannten Supportvek-
toren; 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 Supportvek-
toren 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 Ka-
tegorienraumes in die zu überprüfende Kategorie und alle restlichen Kategorien vorge-
nommen werden. Platt (2000) berichtet zudem noch von Möglichkeiten, die Wahrschein-
lichkeit 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 ge-
sorgt, 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 Nach-
richten 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 Klassifikationsentschei-
dung 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 Email-
Organisation benutzen. Interessant ist hierbei auch die Beobachtung, dass für Benutzer
mit vielen Emails pro Folder schlechtere Ergebnisse erzielt wurden, was im Widerspruch
kiib
wobei K eine so genannte Kernelfunktion darstellt. Man unterscheidet zwischen linearen
und nicht-linearen Kernelfunktionen; es sind
Klin(~d,~di) = ~d · ~di
Kpoly(~d,~di) =
(
~d · ~di + 1
)d
Krb f (~d,~di) = exp
(
γ
(
~d− ~di
)2
)
Ksigmoid(~d,~di) = tanh
(
s
(
~d · ~di
)
+ c
)
lineare, polynominale, radialbasierte und sigmoide Kernelfunktionen, die im nichtlinea-
ren Fall neue Parameter (d,γ,s,c) einführen. Die Wahl der Kernelfunktion kann das Klas-
sifikationsergebnis beeinflussen (Joachims 1998). Die di sind die so genannten Supportvek-
toren; 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 Supportvek-
toren 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 Ka-
tegorienraumes in die zu überprüfende Kategorie und alle restlichen Kategorien vorge-
nommen werden. Platt (2000) berichtet zudem noch von Möglichkeiten, die Wahrschein-
lichkeit 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 ge-
sorgt, 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 Nach-
richten 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 Klassifikationsentschei-
dung 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 Email-
Organisation benutzen. Interessant ist hierbei auch die Beobachtung, dass für Benutzer
mit vielen Emails pro Folder schlechtere Ergebnisse erzielt wurden, was im Widerspruch
kiib
Page 31
4.1 BISHERIGE ERFAHRUNGEN 31
Diao u. a. (2000) führen Experimente mit NB aus, in dem sie Emails in die nicht-
topikalischen Kategorien „interessant“ und „nicht interessant“ einsortieren. Der imple-
mentierte 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 nicht-
interessant 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 Katego-
rien „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 berech-
net 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-
bei durch einen Eigenschaftsvektor ~wi (1 ≤ i ≤ c) repräsentiert. Genauso werden Emails
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 zu-
nächst mittels j = argmaxi=1,...,c{~wi ·~x} den Index einer Klasse. Ist j 6= y, die Abschätzung
also falsch, so werden ~wy und ~wj an den Koordinaten, an denen ~x nicht 0 ist, entsprechend
angepasst. Bekkerman u. a. erweitern diesen klassischen Winnow-Algorithmus um eine
Heuristik, nach der das Gewicht der Vektoren auch dann angepasst wird, wenn der Al-
gorithmus 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 zwi-
schen 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 Wide-
Margin-Winnow-Algorithmus auf dem Enron-Korpus. Sie gehen dabei wie in Ab-
schnitt 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
KI-Methoden zur Email-Archivierung
Diao u. a. (2000) führen Experimente mit NB aus, in dem sie Emails in die nicht-
topikalischen Kategorien „interessant“ und „nicht interessant“ einsortieren. Der imple-
mentierte 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 nicht-
interessant 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 Katego-
rien „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 berech-
net 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-
bei durch einen Eigenschaftsvektor ~wi (1 ≤ i ≤ c) repräsentiert. Genauso werden Emails
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 zu-
nächst mittels j = argmaxi=1,...,c{~wi ·~x} den Index einer Klasse. Ist j 6= y, die Abschätzung
also falsch, so werden ~wy und ~wj an den Koordinaten, an denen ~x nicht 0 ist, entsprechend
angepasst. Bekkerman u. a. erweitern diesen klassischen Winnow-Algorithmus um eine
Heuristik, nach der das Gewicht der Vektoren auch dann angepasst wird, wenn der Al-
gorithmus 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 zwi-
schen 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 Wide-
Margin-Winnow-Algorithmus auf dem Enron-Korpus. Sie gehen dabei wie in Ab-
schnitt 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
KI-Methoden zur Email-Archivierung
Page 32
32 4 EMAIL-KATEGORISIERUNG
Eingabe:
Trainingsmenge {(~xk, yk)|k = 1, . . . , n}
Gewichtsjustierung e
Kühlungsrate α
Konfidenzmaß δ
Ausgabe: ~w1, . . . , ~wc, (m + 1)-dimensionale Vektoren von Gewichten jeder Kategorie
1: Initialisiere Vektoren ~w1, . . . , ~wc zu 1-Vektoren
2: for p← 1 to t do
3: for k← 1 to n do
4: j← argmaxi=1,...,c{~wi · ~xk}
5: j′ ← arg secondmaxi=1,...,c{~wi · ~xk}
6: if j 6= y then
7: wy, f ← wy, f (1− eαp) an Koordinaten f wo ~xk nicht 0
8: wj, f ← wj, f (1− eαp) an Koordinaten f wo ~xk nicht 0
9: else if ~wj′ · ~xk < δwy · xk then {es ist y = j}
10: wy, f ← wy, f (1− eαp) an Koordinaten f wo ~xk nicht 0
11: wj′, f ← wj′, f (1− eαp) an Koordinaten f wo ~xk 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% einzusortie-
ren. 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 er-
brachte ein kNN-Verfahren eine Accuracy von 87%.
In ihren Experimenten benutzen Brutlag u. Meek (2000) auch einen auf Language Mo-
dels basierten Unigram-Klassifizierer. Damit erreichen sie teilweise eine Accuracy von
über 90%.
Diao u. a. (2000) wenden einen Entscheidungsbaumalgorithmus (C4.5) zur Email-
Klassifikation an und erreichen damit ähnliche Werte wie mit tf × idf .
kiib
Eingabe:
Trainingsmenge {(~xk, yk)|k = 1, . . . , n}
Gewichtsjustierung e
Kühlungsrate α
Konfidenzmaß δ
Ausgabe: ~w1, . . . , ~wc, (m + 1)-dimensionale Vektoren von Gewichten jeder Kategorie
1: Initialisiere Vektoren ~w1, . . . , ~wc zu 1-Vektoren
2: for p← 1 to t do
3: for k← 1 to n do
4: j← argmaxi=1,...,c{~wi · ~xk}
5: j′ ← arg secondmaxi=1,...,c{~wi · ~xk}
6: if j 6= y then
7: wy, f ← wy, f (1− eαp) an Koordinaten f wo ~xk nicht 0
8: wj, f ← wj, f (1− eαp) an Koordinaten f wo ~xk nicht 0
9: else if ~wj′ · ~xk < δwy · xk then {es ist y = j}
10: wy, f ← wy, f (1− eαp) an Koordinaten f wo ~xk nicht 0
11: wj′, f ← wj′, f (1− eαp) an Koordinaten f wo ~xk 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% einzusortie-
ren. 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 er-
brachte ein kNN-Verfahren eine Accuracy von 87%.
In ihren Experimenten benutzen Brutlag u. Meek (2000) auch einen auf Language Mo-
dels basierten Unigram-Klassifizierer. Damit erreichen sie teilweise eine Accuracy von
über 90%.
Diao u. a. (2000) wenden einen Entscheidungsbaumalgorithmus (C4.5) zur Email-
Klassifikation an und erreichen damit ähnliche Werte wie mit tf × idf .
kiib
Page 33
4.1 BISHERIGE ERFAHRUNGEN 33
4.1.3 Regelbasierte Ansätze
Eine andere Klasse von maschinellen Lernverfahren, die für die Email-Klassifikation in-
teressant sind, sind regelbasierte Ansätze. Dabei wird aus einer Lernstichprobe eine Theorie
von Regeln gelernt, die dann zur Kategorisierung angewendet werden. Regeln haben da-
bei 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 Lernan-
sätzen den Vorteil, dass sie (je nach deren Repräsentation) relativ einfach nachzuvollzie-
hen und auch zu modifizieren sind. Wie wir bereits festgestellt haben, ist die Aufgabe der
Email-Klassifikation eine sehr dynamische; Benutzerinteressen und Verteilung der Nach-
richten 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 posi-
tive 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 Überad-
aption 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 Opti-
mierungen vollzogen.
Experimente Cohen (1996) wendet RIPPER zur Email-Klassifikation an. Dabei wer-
den mehrere unterschiedliche Szenarien betrachtet. In einem Experiment sollen Vor-
tragsankündigungen gefunden werden (ein interessantes Experiment hinsichtlich der
Document Type-Facette). In einem weiteren Experiment soll eine Einordnung in eine ge-
gebene Folderstruktur vorgenommen werden, wobei die Folder teilweise mit dem jewei-
ligen Autoren korreliert oder semantisch definiert sind. Zu guter Letzt ging es darum,
KI-Methoden zur Email-Archivierung
4.1.3 Regelbasierte Ansätze
Eine andere Klasse von maschinellen Lernverfahren, die für die Email-Klassifikation in-
teressant sind, sind regelbasierte Ansätze. Dabei wird aus einer Lernstichprobe eine Theorie
von Regeln gelernt, die dann zur Kategorisierung angewendet werden. Regeln haben da-
bei 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 Lernan-
sätzen den Vorteil, dass sie (je nach deren Repräsentation) relativ einfach nachzuvollzie-
hen und auch zu modifizieren sind. Wie wir bereits festgestellt haben, ist die Aufgabe der
Email-Klassifikation eine sehr dynamische; Benutzerinteressen und Verteilung der Nach-
richten 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 posi-
tive 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 Überad-
aption 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 Opti-
mierungen vollzogen.
Experimente Cohen (1996) wendet RIPPER zur Email-Klassifikation an. Dabei wer-
den mehrere unterschiedliche Szenarien betrachtet. In einem Experiment sollen Vor-
tragsankündigungen gefunden werden (ein interessantes Experiment hinsichtlich der
Document Type-Facette). In einem weiteren Experiment soll eine Einordnung in eine ge-
gebene Folderstruktur vorgenommen werden, wobei die Folder teilweise mit dem jewei-
ligen Autoren korreliert oder semantisch definiert sind. Zu guter Letzt ging es darum,
KI-Methoden zur Email-Archivierung
Page 35
4.2 MÖGLICHE NEUE ANSÄTZE 35
sind unter anderen Aspekten auch andere Klassifizierer interessant. tf × idfarbeitet
inkrementell, d.h. sobald eine neue Email in einen Folder einsortiert wird, kann
tf × idf sich an die neue Situation schnell anpassen. Auch derWide-Margin-Winnow-
Klassifizierer liefert gute Ergebnisse und ist dabei SVM geschwindigkeitsmäßig vor-
aus. 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 Verfah-
ren, 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 be-
kommt 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 ge-
eignet sind, die aber noch nicht für diese Aufgabe benutzt oder evaluiert wurden. Wir
legen dabei unser Hauptaugenmerk auf probabilistische, entscheidungsorientierte Ver-
fahren 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 Nicht-
Vorkommen eines Terms im Dokument und eventuell noch auf dessen Häufigkeit. Ge-
rade für semi-strukturierte Daten, wie wir sie bei Emails vorliegen haben, ist es inter-
essant, auch die Eigenschaften (Features) eines Terms zu berücksichtigen, wie ja auch in
einigen der oben erwähnten Klassifikationsverfahren schon geschehen ist. Solche Eigen-
schaften 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 Eigen-
schaften definiert werden, wie z.B. das wiederholte Auftreten gewisser Satzzeichen (z.B.
„!!!!!“). Man sieht also, dass solche Eigenschaften eine komplexere Beschreibung ei-
ner 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 Do-
kument 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
KI-Methoden zur Email-Archivierung
sind unter anderen Aspekten auch andere Klassifizierer interessant. tf × idfarbeitet
inkrementell, d.h. sobald eine neue Email in einen Folder einsortiert wird, kann
tf × idf sich an die neue Situation schnell anpassen. Auch derWide-Margin-Winnow-
Klassifizierer liefert gute Ergebnisse und ist dabei SVM geschwindigkeitsmäßig vor-
aus. 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 Verfah-
ren, 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 be-
kommt 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 ge-
eignet sind, die aber noch nicht für diese Aufgabe benutzt oder evaluiert wurden. Wir
legen dabei unser Hauptaugenmerk auf probabilistische, entscheidungsorientierte Ver-
fahren 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 Nicht-
Vorkommen eines Terms im Dokument und eventuell noch auf dessen Häufigkeit. Ge-
rade für semi-strukturierte Daten, wie wir sie bei Emails vorliegen haben, ist es inter-
essant, auch die Eigenschaften (Features) eines Terms zu berücksichtigen, wie ja auch in
einigen der oben erwähnten Klassifikationsverfahren schon geschehen ist. Solche Eigen-
schaften 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 Eigen-
schaften definiert werden, wie z.B. das wiederholte Auftreten gewisser Satzzeichen (z.B.
„!!!!!“). Man sieht also, dass solche Eigenschaften eine komplexere Beschreibung ei-
ner 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 Do-
kument 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
KI-Methoden zur Email-Archivierung
Page 36
36 4 EMAIL-KATEGORISIERUNG
-
Term-Dokument-Paar
(t, d)
@
@
@
@
@R
Beschreibung
~x(t, d)
Relevanzbeschreibung
*
Prob. Indexierungsgewicht
P(R|t, d)
P(R|~x(t, d)) ≈ idx(~x(t, d))
Entscheidung
Abbildung 4.2: Indexierung beim beschreibungsorientierten Ansatz
die normierte Häufigkeit von t im Dokument und x3 ∈ [0, 1] die normierte Dokument-
länge darstellen. In einem nächsten Schritt wird mittels eines Regressionsverfahrens in
der Entscheidungsphase die Wahrscheinlichkeit P(R|~x(t, d)) durch eine Indexierungsfunkti-
on 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. Fol-
der) 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 be-
trachten. 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 d′ ∈ D,
wenn sich d und d′ in derselben Kategorie befinden, und nicht-relevant (R) sonst. Die Funk-
tion r : D ×D −→ {R,R} bestimmt dabei die Relevanz zwischen zwei Dokumenten.
Mit diesem Begriff der Relevanz können wir nun unsere Lernstichprobe definieren. Zu-
nächst mal sei
L =
{(
d, d′, r
(
d, d′
))
|d, d′ ∈ D
}
.
Die Lernstichprobe selbst ist eine Multimenge von Relevanzbeschreibungen mit Rele-
vanzurteilen:
Lx = [(~x(t, d), r(d, d′))|t ∈ dT ∩ d′T ∧ (d, d′, r(d, d′) ∈ L]
wobei dT die Menge der in d vorkommenden Terme ist.
kiib
-
Term-Dokument-Paar
(t, d)
@
@
@
@
@R
Beschreibung
~x(t, d)
Relevanzbeschreibung
*
Prob. Indexierungsgewicht
P(R|t, d)
P(R|~x(t, d)) ≈ idx(~x(t, d))
Entscheidung
Abbildung 4.2: Indexierung beim beschreibungsorientierten Ansatz
die normierte Häufigkeit von t im Dokument und x3 ∈ [0, 1] die normierte Dokument-
länge darstellen. In einem nächsten Schritt wird mittels eines Regressionsverfahrens in
der Entscheidungsphase die Wahrscheinlichkeit P(R|~x(t, d)) durch eine Indexierungsfunkti-
on 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. Fol-
der) 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 be-
trachten. 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 d′ ∈ D,
wenn sich d und d′ in derselben Kategorie befinden, und nicht-relevant (R) sonst. Die Funk-
tion r : D ×D −→ {R,R} bestimmt dabei die Relevanz zwischen zwei Dokumenten.
Mit diesem Begriff der Relevanz können wir nun unsere Lernstichprobe definieren. Zu-
nächst mal sei
L =
{(
d, d′, r
(
d, d′
))
|d, d′ ∈ D
}
.
Die Lernstichprobe selbst ist eine Multimenge von Relevanzbeschreibungen mit Rele-
vanzurteilen:
Lx = [(~x(t, d), r(d, d′))|t ∈ dT ∩ d′T ∧ (d, d′, r(d, d′) ∈ L]
wobei dT die Menge der in d vorkommenden Terme ist.
kiib
Page 37
4.2 MÖGLICHE NEUE ANSÄTZE 37
Beispiel. Legt man folgende Relevanzbeschreibung für Emails zu Grunde
x1(t, d) = normierte Termhäufigkeit (nt f ) des Terms t in d
x2(t, d) =
{
1 wenn t im Subject-Header von d enthalten ist,
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
Lx =
[((
1
1
)
,R
)
,
((
1
1
)
,R
)
,
((
2
0
)
,R
)
,
((
1
1
)
,R
)
,
((
2
0
)
,R
)
,
((
1
0
)
,R
)]
.
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 d′ t ∈ dT ∩ d′T ~x r(d, d′)
d1 d2 t2 (1,1) R
d2 d1 t2 (1,1) R
d1 d3 t1 (2,0) R
d3 d1 t1 (1,1) R
d2 d3 t4 (2,0) R
d3 d2 t4 (1,0) 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 vorge-
nommen. Sei dabei zunächst mal
y = y(d, d′) =
{
1 wenn r(d, d′) = R,
0 sonst.
die Klassenvariable y. Es soll nun der mittlere quadratische Schätzfehler minimiert werden;
Optimierungskriterium ist also
E((y− idx(~x))2 != min .
KI-Methoden zur Email-Archivierung
Beispiel. Legt man folgende Relevanzbeschreibung für Emails zu Grunde
x1(t, d) = normierte Termhäufigkeit (nt f ) des Terms t in d
x2(t, d) =
{
1 wenn t im Subject-Header von d enthalten ist,
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
Lx =
[((
1
1
)
,R
)
,
((
1
1
)
,R
)
,
((
2
0
)
,R
)
,
((
1
1
)
,R
)
,
((
2
0
)
,R
)
,
((
1
0
)
,R
)]
.
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 d′ t ∈ dT ∩ d′T ~x r(d, d′)
d1 d2 t2 (1,1) R
d2 d1 t2 (1,1) R
d1 d3 t1 (2,0) R
d3 d1 t1 (1,1) R
d2 d3 t4 (2,0) R
d3 d2 t4 (1,0) 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 vorge-
nommen. Sei dabei zunächst mal
y = y(d, d′) =
{
1 wenn r(d, d′) = R,
0 sonst.
die Klassenvariable y. Es soll nun der mittlere quadratische Schätzfehler minimiert werden;
Optimierungskriterium ist also
E((y− idx(~x))2 != min .
KI-Methoden zur Email-Archivierung
Page 38
38 4 EMAIL-KATEGORISIERUNG
(E ist der Erwartungswert). i wird mit Hilfe einer Polynomstruktur ~v(~x) und eines Koeffizi-
entenvektors~a als Polynom ausgedrückt:
idx(~x) =~aT ·~v(~x)
Für ~v(~x) = (1, x1, x2)T und~a = (a1, a2, a3)T würde man z.B. das Polynom a1 + a2x1 + a3x2
als Schätzfunktion bekommen. Berücksichtigt man das o.g. Optimierungskriterium, so
kann man mittels des linearen Gleichungssystems
E(~v ·~vT) ·~a = E(~v · y)
~a berechnen. Siehe auch (Frommholz 2001, Kapitel 4.1) für eine ausführlichere Beschrei-
bung der Methode. Im vorliegenden Beispiel würde man als Indexierungsfunktion
idx(~x) = −
1
2
+
1
2
x1 +
1
3
x2
bekommen.
Logistische Regression
Bei der logistischen Regression erfolgt die Abschätzung von P(R|~x) nicht mittels eines
Polynoms, sondern durch die Formel
P(R|~x) ≈ idx(~x) =
e~b
T~x
1+ e~bT~x
=
eb0+b1x1+...+bnxn
1+ eb0+b1x1+...+bnxn
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 li-
neare 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+b1x1+...+bnxn .
Dies kann man nun logarithmieren und erhält die so genannten Logodds:
logO(R|~x) = b0 + b1x1 + . . . + bnxn.
Es reicht völlig aus, die Logodds zu berechnen. Bei Bedarf können die so erhaltenenWerte
in die tatsächlichen Wahrscheinlichkeitsabschätzungen überführt werden.
Zur Ermittlung von idx wird nun zunächst ~b als Argument der Indexierungsfunkti-
on hinzugefügt, so dass wir idx(~x,~b) bekommen. Sei nun Lx eine solche Lernstichpro-
be und t = |Lx|, 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öglich-
keiten, den gesuchten Parametervektor~b zu finden: eine Maximum-Likelihood- und eine
Least-Square-Regression. Beide basieren dabei auf unterschiedlichen Optimierungskrite-
rien, wie wir im Folgenden beschreiben.
kiib
(E ist der Erwartungswert). i wird mit Hilfe einer Polynomstruktur ~v(~x) und eines Koeffizi-
entenvektors~a als Polynom ausgedrückt:
idx(~x) =~aT ·~v(~x)
Für ~v(~x) = (1, x1, x2)T und~a = (a1, a2, a3)T würde man z.B. das Polynom a1 + a2x1 + a3x2
als Schätzfunktion bekommen. Berücksichtigt man das o.g. Optimierungskriterium, so
kann man mittels des linearen Gleichungssystems
E(~v ·~vT) ·~a = E(~v · y)
~a berechnen. Siehe auch (Frommholz 2001, Kapitel 4.1) für eine ausführlichere Beschrei-
bung der Methode. Im vorliegenden Beispiel würde man als Indexierungsfunktion
idx(~x) = −
1
2
+
1
2
x1 +
1
3
x2
bekommen.
Logistische Regression
Bei der logistischen Regression erfolgt die Abschätzung von P(R|~x) nicht mittels eines
Polynoms, sondern durch die Formel
P(R|~x) ≈ idx(~x) =
e~b
T~x
1+ e~bT~x
=
eb0+b1x1+...+bnxn
1+ eb0+b1x1+...+bnxn
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 li-
neare 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+b1x1+...+bnxn .
Dies kann man nun logarithmieren und erhält die so genannten Logodds:
logO(R|~x) = b0 + b1x1 + . . . + bnxn.
Es reicht völlig aus, die Logodds zu berechnen. Bei Bedarf können die so erhaltenenWerte
in die tatsächlichen Wahrscheinlichkeitsabschätzungen überführt werden.
Zur Ermittlung von idx wird nun zunächst ~b als Argument der Indexierungsfunkti-
on hinzugefügt, so dass wir idx(~x,~b) bekommen. Sei nun Lx eine solche Lernstichpro-
be und t = |Lx|, 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öglich-
keiten, den gesuchten Parametervektor~b zu finden: eine Maximum-Likelihood- und eine
Least-Square-Regression. Beide basieren dabei auf unterschiedlichen Optimierungskrite-
rien, wie wir im Folgenden beschreiben.
kiib
Page 39
4.2 MÖGLICHE NEUE ANSÄTZE 39
Logistische Maximum-Likelihood-Regression Hier geht es darum, die so genannte
Likelihood-Funktion (Fuhr u. Pfeifer 1991)
L(~b) =
∏
yi=1
idx(~xi,~b) ·
∏
yi=0
(1− idx(~xi,~b))
=
t
∏
i=1
idx(~xi,~b)
yi · (1− idx(~xi,~b))
1−yi
zumaximieren. Das Optimierungskriterium für die optimale logistische Regressionsfunk-
tion ist daher
L(~b) != max .
Imweiteren Verlauf wird die logarithmische Likelihood-Funktion l(~b) = log L(~b) betrach-
tet. Es ergibt sich
l(~b) =
t
∑
i=1
yi · log idx(~xi,~b) + (1− yi) · log(1− idx(~xi,~b)).
Das Optimierungskriterium hat als notwendige Bedingung, dass die Ableitungen von l
nach den Komponenten bj aus~b gleich 0 sind, d.h.
∂l
∂bj
=
t
∑
i=1
(yi − idx(~xi,~b))xi j = 0.
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
∑
i=1
(idx(~xi,~b)− yi)
2 != min .
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))
∂R
∂bj
= 2 ·
t
∑
i=1
(idx(~xi,~b)− y · idx(~xi,~b)− idx(~xi,~b)
3 + y · idx(~xi,~b)
2) · xi j = 0
Es wird wiederum das Newton-Raphson-Verfahren benutzt, um die Gleichung zu lösen
(Frommholz 2001, Kap. 5.1.2).
KI-Methoden zur Email-Archivierung
Logistische Maximum-Likelihood-Regression Hier geht es darum, die so genannte
Likelihood-Funktion (Fuhr u. Pfeifer 1991)
L(~b) =
∏
yi=1
idx(~xi,~b) ·
∏
yi=0
(1− idx(~xi,~b))
=
t
∏
i=1
idx(~xi,~b)
yi · (1− idx(~xi,~b))
1−yi
zumaximieren. Das Optimierungskriterium für die optimale logistische Regressionsfunk-
tion ist daher
L(~b) != max .
Imweiteren Verlauf wird die logarithmische Likelihood-Funktion l(~b) = log L(~b) betrach-
tet. Es ergibt sich
l(~b) =
t
∑
i=1
yi · log idx(~xi,~b) + (1− yi) · log(1− idx(~xi,~b)).
Das Optimierungskriterium hat als notwendige Bedingung, dass die Ableitungen von l
nach den Komponenten bj aus~b gleich 0 sind, d.h.
∂l
∂bj
=
t
∑
i=1
(yi − idx(~xi,~b))xi j = 0.
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
∑
i=1
(idx(~xi,~b)− yi)
2 != min .
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))
∂R
∂bj
= 2 ·
t
∑
i=1
(idx(~xi,~b)− y · idx(~xi,~b)− idx(~xi,~b)
3 + y · idx(~xi,~b)
2) · xi j = 0
Es wird wiederum das Newton-Raphson-Verfahren benutzt, um die Gleichung zu lösen
(Frommholz 2001, Kap. 5.1.2).
KI-Methoden zur Email-Archivierung
Page 43
4.2 MÖGLICHE NEUE ANSÄTZE 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)
︸ ︷︷ ︸
<1
< P(R|Ci+1, d) (cr − c¯r)
︸ ︷︷ ︸
<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 Wahrscheinlich-
keit 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 kNN-
Ansatz 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 effizi-
ent durchzuführen sein. Da die Indexierungsfunktion im Grunde genommen die Wich-
tigkeit 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 Re-
chenzeit 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 Facet-
te unterschiedliche Features zu bestimmen, machen die Verfahren zu einem universellen
Werkzeug. Welche Features dabei bei welcher Facette Sinn machen, bedarf einer genaue-
ren Analyse der Email-Kollektion hinsichtlich der einzelnen Facetten.
KI-Methoden zur Email-Archivierung
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)
︸ ︷︷ ︸
<1
< P(R|Ci+1, d) (cr − c¯r)
︸ ︷︷ ︸
<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 Wahrscheinlich-
keit 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 kNN-
Ansatz 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 effizi-
ent durchzuführen sein. Da die Indexierungsfunktion im Grunde genommen die Wich-
tigkeit 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 Re-
chenzeit 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 Facet-
te unterschiedliche Features zu bestimmen, machen die Verfahren zu einem universellen
Werkzeug. Welche Features dabei bei welcher Facette Sinn machen, bedarf einer genaue-
ren Analyse der Email-Kollektion hinsichtlich der einzelnen Facetten.
KI-Methoden zur Email-Archivierung
Page 46
46 4 EMAIL-KATEGORISIERUNG
oder nicht. Schön wäre es jedoch, auch hier eineWahrscheinlichkeit, dass eine Email zu ei-
nem Folder/einer Kategorie gehört, zu berechnen. Dadurch wäre es dem Systemmöglich,
ein Ranking von Foldern zu erstellen und die besten k Folder dem Benutzer zur Auswahl
zu stellen. Hier können Inferenzsystemewie 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 Varia-
blen 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 eineWahrscheinlichkeit
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% demOrdner cfp95 zuzuordnen ist, wenn im Subject die Terme „cfp“ und „1995“
auftauchen. Die Email ist mit einer Wahrscheinlichkeit von 60% dem Ordner cfp95 zu-
zuordnen, 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 wer-
den. 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 probabilisti-
sche 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 Lernverfahrenwürde nun sowohl obige Regeln als auch derenWahr-
scheinlichkeiten aus der Lernstichprobe lernen. Dabei ergibt sich ein zusätzliches Pro-
blem, 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,
5Eine 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 FirmaApriorie Ltd. bietet eine kos-
tenpflichtige, aber in vielerlei Hinsicht effizientere kommerzielle Version. Eine alternative freie Implemen-
tierung von pDatalog ist das an der Universität Duisburg-Essen entwickelte PIRE (Nottelmann 2005).
kiib
oder nicht. Schön wäre es jedoch, auch hier eineWahrscheinlichkeit, dass eine Email zu ei-
nem Folder/einer Kategorie gehört, zu berechnen. Dadurch wäre es dem Systemmöglich,
ein Ranking von Foldern zu erstellen und die besten k Folder dem Benutzer zur Auswahl
zu stellen. Hier können Inferenzsystemewie 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 Varia-
blen 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 eineWahrscheinlichkeit
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% demOrdner cfp95 zuzuordnen ist, wenn im Subject die Terme „cfp“ und „1995“
auftauchen. Die Email ist mit einer Wahrscheinlichkeit von 60% dem Ordner cfp95 zu-
zuordnen, 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 wer-
den. 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 probabilisti-
sche 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 Lernverfahrenwürde nun sowohl obige Regeln als auch derenWahr-
scheinlichkeiten aus der Lernstichprobe lernen. Dabei ergibt sich ein zusätzliches Pro-
blem, 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,
5Eine 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 FirmaApriorie Ltd. bietet eine kos-
tenpflichtige, aber in vielerlei Hinsicht effizientere kommerzielle Version. Eine alternative freie Implemen-
tierung von pDatalog ist das an der Universität Duisburg-Essen entwickelte PIRE (Nottelmann 2005).
kiib
Page 48
48 4 EMAIL-KATEGORISIERUNG
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 ent-
halten. Wir schätzen nun γc f p95 ab, indem wir zunächst für alle Teilmengen A ⊆ P =
{cfp95_1,cfp95_2} die Menge EXA ermitteln, in denen A und nur A vorkommt, also
EXA = {(~ci, yi)|
∧
a∈A a(~c) ∧
∧
a∈P\A ¬a(~c)}. Im Fall A = {cfp95_1} wären das alle bei-
den 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 EXA am
Anteil Beispiele in EXA, also
|{(~ci, yi) ∈ EXA|yi = 1}|
|EXA|
.
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 er-
rechneten Hypothese hp ermitteln als
Eˆ =
1
|EX|
|EX|
∑
i=1
(P(hp(~ci))− yi)
2
wobei P(hp(~ci)) z.B. mit HySpirit berechnet werden kann (Nottelmann u. Fuhr 2001). Al-
gorithmus 2 zeigt die generische Struktur des Algorithmus learnOptimum, der ähnlich
wie oben gezeigt aus einer gegebenen Regelmenge die benötigten Gewichte γ berechnet.
kiib
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 ent-
halten. Wir schätzen nun γc f p95 ab, indem wir zunächst für alle Teilmengen A ⊆ P =
{cfp95_1,cfp95_2} die Menge EXA ermitteln, in denen A und nur A vorkommt, also
EXA = {(~ci, yi)|
∧
a∈A a(~c) ∧
∧
a∈P\A ¬a(~c)}. Im Fall A = {cfp95_1} wären das alle bei-
den 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 EXA am
Anteil Beispiele in EXA, also
|{(~ci, yi) ∈ EXA|yi = 1}|
|EXA|
.
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 er-
rechneten Hypothese hp ermitteln als
Eˆ =
1
|EX|
|EX|
∑
i=1
(P(hp(~ci))− yi)
2
wobei P(hp(~ci)) z.B. mit HySpirit berechnet werden kann (Nottelmann u. Fuhr 2001). Al-
gorithmus 2 zeigt die generische Struktur des Algorithmus learnOptimum, der ähnlich
wie oben gezeigt aus einer gegebenen Regelmenge die benötigten Gewichte γ berechnet.
kiib
Page 50
50 4 EMAIL-KATEGORISIERUNG
Eingabe:
Zielprädikat p
Wissensbasis KB
Lernbeispiele EXAMPLES
Anzahl zu lernender Regeln n
Ausgabe:
Regelsatz R, Verlustrate l
1: R← ∅
2: l ← 0
3: for i← l; i ≤ n; i← i + 1 do
4: l ← ∞
5: r ← leere Regel für p
6: while better rule found do
7: H = {R ∪ {r′}|R′direkte Spezialisierung vonr}
8: (hr, l)← learnOptimum(p,KB, EXAMPLES,H)
9: h← h′′
10: end while
11: R← hr
12: end for
Algorithmus 3: Algorithmus zum Lernen von Regeln (Nottelmann u. Fuhr 2001)
neue Regeln generiert wurden. Für weitere Details verweisenwir 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 wur-
de der Ansatz in (Nottelmann 2001) mit gemischten Ergebnissen in der Textklassifikation
und Spamerkennung hinsichtlich der Effektivität getestet, doch steht eine Evaluierungmit
einer realistischen Email-Kollektionwie 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 Re-
gelmenge 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
Eingabe:
Zielprädikat p
Wissensbasis KB
Lernbeispiele EXAMPLES
Anzahl zu lernender Regeln n
Ausgabe:
Regelsatz R, Verlustrate l
1: R← ∅
2: l ← 0
3: for i← l; i ≤ n; i← i + 1 do
4: l ← ∞
5: r ← leere Regel für p
6: while better rule found do
7: H = {R ∪ {r′}|R′direkte Spezialisierung vonr}
8: (hr, l)← learnOptimum(p,KB, EXAMPLES,H)
9: h← h′′
10: end while
11: R← hr
12: end for
Algorithmus 3: Algorithmus zum Lernen von Regeln (Nottelmann u. Fuhr 2001)
neue Regeln generiert wurden. Für weitere Details verweisenwir 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 wur-
de der Ansatz in (Nottelmann 2001) mit gemischten Ergebnissen in der Textklassifikation
und Spamerkennung hinsichtlich der Effektivität getestet, doch steht eine Evaluierungmit
einer realistischen Email-Kollektionwie 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 Re-
gelmenge 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
Page 51
4.2 MÖGLICHE NEUE ANSÄTZE 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.
KI-Methoden zur Email-Archivierung
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.
KI-Methoden zur Email-Archivierung
Page 52
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 Attribut-
Werte-Paaren.
Grob besteht die Informationsextraktion aus zwei Schritten: der Definition des Templa-
tes durch den Benutzer, und dem Füllen des Templates durch das System (Abolhassa-
ni u. a. 2003). Grundsätzlich gibt es zwei Strategien bei IE-Ansätzen: im Knowledge Engi-
neering-Ansatz werden Regeln zur Extraktion der gesuchten Information manuell durch
einen Knowledge-Engineer angelegt. In der Regel erfolgt dies iterativ, indemmanmit sim-
plen 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, in-
dem 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 Named-
Entity-Recognition (s.u.) durchgeführt werden. Auch können hier strukturierte Ein-
heiten 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“,
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 Attribut-
Werte-Paaren.
Grob besteht die Informationsextraktion aus zwei Schritten: der Definition des Templa-
tes durch den Benutzer, und dem Füllen des Templates durch das System (Abolhassa-
ni u. a. 2003). Grundsätzlich gibt es zwei Strategien bei IE-Ansätzen: im Knowledge Engi-
neering-Ansatz werden Regeln zur Extraktion der gesuchten Information manuell durch
einen Knowledge-Engineer angelegt. In der Regel erfolgt dies iterativ, indemmanmit sim-
plen 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, in-
dem 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 Named-
Entity-Recognition (s.u.) durchgeführt werden. Auch können hier strukturierte Ein-
heiten 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“,
Page 53
5.1 ÜBERBLICK 53
„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 Accu-
racy bis zu 95% erreichen.
• Bei der Coreference Resolution werden Beziehungen zwischen Entitäten erkannt. Bei-
spielsweise 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 Informationenmit den
in den vorherigen Schritten gefundenen Elementen. Hier werden die vorher defi-
nierten 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 An-
gestelltenverhältnis zwischen einer Firma und einer Person.
• Die Scenario Template Extraction stellt den finalen Schritt bei der Informationsextrak-
tion dar. Alle in den bisherigen Schritten ermittelten Informationen werden hier zu-
sammengefügt. Ein Szenario-Template kann in einemManagement-Szenario z.B. er-
kennen welche Person, von welcher Firma kommend, den bisherigen Manager ei-
ner 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 Ty-
pen 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 Benut-
zer 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 HTML-
Dokumente geeignet. Hierbei wird das Dokument durch seinen DOM-Tree reprä-
sentiert. Tools operieren semi-automatisch oder automatisch.
1http://gate.ac.uk/
KI-Methoden zur Email-Archivierung
„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 Accu-
racy bis zu 95% erreichen.
• Bei der Coreference Resolution werden Beziehungen zwischen Entitäten erkannt. Bei-
spielsweise 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 Informationenmit den
in den vorherigen Schritten gefundenen Elementen. Hier werden die vorher defi-
nierten 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 An-
gestelltenverhältnis zwischen einer Firma und einer Person.
• Die Scenario Template Extraction stellt den finalen Schritt bei der Informationsextrak-
tion dar. Alle in den bisherigen Schritten ermittelten Informationen werden hier zu-
sammengefügt. Ein Szenario-Template kann in einemManagement-Szenario z.B. er-
kennen welche Person, von welcher Firma kommend, den bisherigen Manager ei-
ner 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 Ty-
pen 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 Benut-
zer 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 HTML-
Dokumente geeignet. Hierbei wird das Dokument durch seinen DOM-Tree reprä-
sentiert. Tools operieren semi-automatisch oder automatisch.
1http://gate.ac.uk/
KI-Methoden zur Email-Archivierung
Page 54
54 5 INFORMATIONSEXTRAKTION
NLP-basierte Tools Hierwerden Techniken aus demNatural 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 Formatie-
rungseigenschaften 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 be-
schreibt, manuell erstellt werden; ist diese repräsentativ genug, kann die Informati-
onsextraktion vollautomatisch erfolgen.
Man kann weiterhin noch zwischen Single-Slot- und Multi-Slot-Extraktion unterschei-
den (Soderland 1999). Bei der Single-Slot-Extraktion wird ein einziges Frame gefüllt, wäh-
rend 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
esmit einerMulti-Slot-Extraktion zu tun, wenn der Text vonmehreren Produkten handelt,
deren Daten alle zu extrahieren sind.
Wie schon erwähnt bestehen Emails aus strukturierten Daten (dem Header) und zu-
meist unstrukturiertem Volltext (dem Body). Dementsprechend sollte bei der Informati-
onsextraktion 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 Wrapper-
Induktions-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 Ver-
fahren 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 Informationsex-
traktion 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 dar-
um, 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
NLP-basierte Tools Hierwerden Techniken aus demNatural 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 Formatie-
rungseigenschaften 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 be-
schreibt, manuell erstellt werden; ist diese repräsentativ genug, kann die Informati-
onsextraktion vollautomatisch erfolgen.
Man kann weiterhin noch zwischen Single-Slot- und Multi-Slot-Extraktion unterschei-
den (Soderland 1999). Bei der Single-Slot-Extraktion wird ein einziges Frame gefüllt, wäh-
rend 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
esmit einerMulti-Slot-Extraktion zu tun, wenn der Text vonmehreren Produkten handelt,
deren Daten alle zu extrahieren sind.
Wie schon erwähnt bestehen Emails aus strukturierten Daten (dem Header) und zu-
meist unstrukturiertem Volltext (dem Body). Dementsprechend sollte bei der Informati-
onsextraktion 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 Wrapper-
Induktions-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 Ver-
fahren 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 Informationsex-
traktion 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 dar-
um, 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
Page 55
5.3 ANSÄTZE ZUR INFORMATIONSEXTRAKTION 55
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 zwi-
schen 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 Pat-
terns 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.
Print Event 1 Template
Field Value
Sender User 1 Template
Destination Printer 1 Template
Source
File to print File 1 Template
Action tried
Printer 1 Template
Field Value
Name hp2248
Room X-234
Status
File printing
File 1 Template
Field Value
Name
Current format single sided
Source
Desired format
Owner
Job number
User 1 Template
Field Value
Name John Smith
Email smith@abc.ca
Laboratory
Abbildung 5.1: Gefüllte Templates
Neben der eigentlichen Informationsextraktion sieht der von Kosseim u. a. (2001) be-
schrieben Ansatz auch eine Validierung der extrahierten Daten unter Einbeziehung ex-
terner 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 ex-
trahieren. 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 Informations-
extraktion bei Emails angewendet wurde, wollen wir nun einige prominente Verfahren
zur Informationsextraktion vorstellen, die sowohl auf strukturierten Texten (wie HTML-
Dokumenten) als auch auf Freitexten, wie wir sie ja im Email-Body vorfinden. Diese Sys-
teme sind WHISK, eine Kombination aus Kategorisierer und Regellerner, und ELIE.
KI-Methoden zur Email-Archivierung
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 zwi-
schen 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 Pat-
terns 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.
Print Event 1 Template
Field Value
Sender User 1 Template
Destination Printer 1 Template
Source
File to print File 1 Template
Action tried
Printer 1 Template
Field Value
Name hp2248
Room X-234
Status
File printing
File 1 Template
Field Value
Name
Current format single sided
Source
Desired format
Owner
Job number
User 1 Template
Field Value
Name John Smith
Email smith@abc.ca
Laboratory
Abbildung 5.1: Gefüllte Templates
Neben der eigentlichen Informationsextraktion sieht der von Kosseim u. a. (2001) be-
schrieben Ansatz auch eine Validierung der extrahierten Daten unter Einbeziehung ex-
terner 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 ex-
trahieren. 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 Informations-
extraktion bei Emails angewendet wurde, wollen wir nun einige prominente Verfahren
zur Informationsextraktion vorstellen, die sowohl auf strukturierten Texten (wie HTML-
Dokumenten) als auch auf Freitexten, wie wir sie ja im Email-Body vorfinden. Diese Sys-
teme sind WHISK, eine Kombination aus Kategorisierer und Regellerner, und ELIE.
KI-Methoden zur Email-Archivierung
Page 56
56 5 INFORMATIONSEXTRAKTION
@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 Ana-
lyse eines Textes ist in Abb. 5.2 dargestellt. Eine solche Analyse markiertWorte 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 han-
delt es sich in der Regel um einen Satz oder eine Klausel, welche durch die syntakti-
sche 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 ei-
nes 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 gefunde-
ne 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). $1wird mit der gefunden Person gebunden. Danach werden wieder al-
le Zeichen bis zum Auftauchen des Tokens @Passive ignoriert. Die nächste Wildcard ist
2Dieses Thema war eine Vorgabe bei der sechsten Message Understanding Conference (MUC-6); siehe auch
http://cs.nyu.edu/cs/faculty/grishman/muc6.html
kiib
@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 Ana-
lyse eines Textes ist in Abb. 5.2 dargestellt. Eine solche Analyse markiertWorte 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 han-
delt es sich in der Regel um einen Satz oder eine Klausel, welche durch die syntakti-
sche 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 ei-
nes 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 gefunde-
ne 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). $1wird mit der gefunden Person gebunden. Danach werden wieder al-
le Zeichen bis zum Auftauchen des Tokens @Passive ignoriert. Die nächste Wildcard ist
2Dieses Thema war eine Vorgabe bei der sechsten Message Understanding Conference (MUC-6); siehe auch
http://cs.nyu.edu/cs/faculty/grishman/muc6.html
kiib
Page 58
58 5 INFORMATIONSEXTRAKTION
Eingabe:
ReservoirR
Ausgabe:
Regelsatz R
1: R← ∅
2: Training← ∅
3: while User wants to continue do
4: select NewInst ⊂ R
5: NewInst← tag(NewInst)
6: NewInst← discard_rules_with_errors(NewInst)
7: Training← Training ∪ NewInst
8: for all inst ∈ Training do
9: for all tag of inst do
10: if tag is not covered by RuleSet then
11: rule← grow_rule(inst, tag, Training)
12: R← RuleSet ∪ rule
13: end if
14: end for
15: end for
16: end while
17: prune(R)
Algorithmus 4: Hauptebene des WHISK-Algorithmus
der Extraktion haben können. Start- und Endzeit konnten mit 100% Recall bei 96% Pre-
cision (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% Precisi-
on, F1 ≈ 0, 52) und beim Sprecher werden noch schlechtere Werte berichtet. Ein weiteres
Experiment befasste sich mit der Datenextraktion auf freien, unstrukturierten Texten. Da-
bei 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 Pru-
ning) 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 Informations-
extraktion betrachten. Streng genommen handelt es sich hier um mehrere Ansätze, die
kiib
Eingabe:
ReservoirR
Ausgabe:
Regelsatz R
1: R← ∅
2: Training← ∅
3: while User wants to continue do
4: select NewInst ⊂ R
5: NewInst← tag(NewInst)
6: NewInst← discard_rules_with_errors(NewInst)
7: Training← Training ∪ NewInst
8: for all inst ∈ Training do
9: for all tag of inst do
10: if tag is not covered by RuleSet then
11: rule← grow_rule(inst, tag, Training)
12: R← RuleSet ∪ rule
13: end if
14: end for
15: end for
16: end while
17: prune(R)
Algorithmus 4: Hauptebene des WHISK-Algorithmus
der Extraktion haben können. Start- und Endzeit konnten mit 100% Recall bei 96% Pre-
cision (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% Precisi-
on, F1 ≈ 0, 52) und beim Sprecher werden noch schlechtere Werte berichtet. Ein weiteres
Experiment befasste sich mit der Datenextraktion auf freien, unstrukturierten Texten. Da-
bei 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 Pru-
ning) 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 Informations-
extraktion betrachten. Streng genommen handelt es sich hier um mehrere Ansätze, die
kiib
Page 61
5.3 ANSÄTZE ZUR INFORMATIONSEXTRAKTION 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 bestimm-
te Eigenschaft hat. some(?A, [], captializedp, true) bedeutet „das Frag-
ment 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 ha-
ben. every(numericp, false) bedeutet „jedes Token im Fragment ist nicht-
numerisch“.
position(Var, From, Relop, N) Ein Token in der gegenwärtigen Regel muß sich im spe-
zifizierten 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 Verfah-
ren 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 weni-
ger 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 Experi-
menten die besten Ergebnisse. Bei den schon für die WHISK-Evaluation benutzen Se-
minarankü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 unstruk-
turierte Dokumente. Hierbei erreichte der kombinierte Ansatz für die einzelnen Slots F1-
KI-Methoden zur Email-Archivierung
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 bestimm-
te Eigenschaft hat. some(?A, [], captializedp, true) bedeutet „das Frag-
ment 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 ha-
ben. every(numericp, false) bedeutet „jedes Token im Fragment ist nicht-
numerisch“.
position(Var, From, Relop, N) Ein Token in der gegenwärtigen Regel muß sich im spe-
zifizierten 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 Verfah-
ren 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 weni-
ger 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 Experi-
menten die besten Ergebnisse. Bei den schon für die WHISK-Evaluation benutzen Se-
minarankü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 unstruk-
turierte Dokumente. Hierbei erreichte der kombinierte Ansatz für die einzelnen Slots F1-
KI-Methoden zur Email-Archivierung
Page 62
62 5 INFORMATIONSEXTRAKTION
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 wur-
den, F1-Werte zwischen 0,341 (beim Projekttitel) und 0,889 (bei der Kursnummer) ermit-
telt. Problematisch an dieser Aufgabenstellung war, dass eine Web-Seite Informationen
über mehrere Kurse oder Projekte enthalten kann, wodurch die Extraktionsaufgabe er-
schwert wird.
5.3.3 ELIE
Die in ROPE und BAYES aufgekommene Idee, die Informationsextraktion als Klassifizie-
rungsaufgabe anzusehen, wird auch von Finn u. Kushmerick (2004) aufgegriffen. Hier
wird auch jede Position im Dokument als mögliche Start- oder Endposition oder als irre-
levant bezüglich einer gesuchten Slot-Instanz kategorisiert. Beim vorgeschlagenen ELIE-
Algorithmus 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 Sup-
port 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 Na-
men, Städte usw. aufgelistet sein.
Orthographie Orthographische Information über das Token, wie z.B. Groß- und Klein-
schreibung, Punktuation, alphabetisch oder numerisch, etc.
Weiterhin können noch Beziehungsinformationen zwischen Token in Features darge-
stellt 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. de-
ren Featurerepräsentationen werden nun analog zu der Beschreibung in Abschnitt 4.1.2
benutzt, um eine Hyperebenenfunktion zu berechnen. Wir bekommen dabei eine Funk-
tion 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 niedri-
gen 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
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 wur-
den, F1-Werte zwischen 0,341 (beim Projekttitel) und 0,889 (bei der Kursnummer) ermit-
telt. Problematisch an dieser Aufgabenstellung war, dass eine Web-Seite Informationen
über mehrere Kurse oder Projekte enthalten kann, wodurch die Extraktionsaufgabe er-
schwert wird.
5.3.3 ELIE
Die in ROPE und BAYES aufgekommene Idee, die Informationsextraktion als Klassifizie-
rungsaufgabe anzusehen, wird auch von Finn u. Kushmerick (2004) aufgegriffen. Hier
wird auch jede Position im Dokument als mögliche Start- oder Endposition oder als irre-
levant bezüglich einer gesuchten Slot-Instanz kategorisiert. Beim vorgeschlagenen ELIE-
Algorithmus 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 Sup-
port 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 Na-
men, Städte usw. aufgelistet sein.
Orthographie Orthographische Information über das Token, wie z.B. Groß- und Klein-
schreibung, Punktuation, alphabetisch oder numerisch, etc.
Weiterhin können noch Beziehungsinformationen zwischen Token in Features darge-
stellt 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. de-
ren Featurerepräsentationen werden nun analog zu der Beschreibung in Abschnitt 4.1.2
benutzt, um eine Hyperebenenfunktion zu berechnen. Wir bekommen dabei eine Funk-
tion 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 niedri-
gen 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
Page 63
5.4 BEURTEILUNG DER VERFAHREN ZUR INFORMATIONSEXTRAKTION 63
Token vor einem Endtoken befinden. Zur Bestimmung der Funktion für Endtokenwerden
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 trai-
niert. 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 ange-
wendet, 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 f1-Wert von 0,885 erreicht wurde. Dies lässt sich unter An-
derem 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 Heraus-
forderung darstellt. Einfache Verfahren wie die Named Entity Recognition liefern gu-
te Ergebnisse, ebenso, wenn sehr strukturierte Daten vorliegen, wie im Fall der CNN-
Wettervorhersage, wowir es einerseits mit strukturierten Texten (HTML) und andererseits
mit einer inhärenten Datenbankstruktur zu tun haben. Daraus resultierende Regelmäßig-
keiten 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. Semi-
narankü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 Verfah-
ren 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 je-
dem Iterationsschritt eine neue Menge von Instanzen aus dem Reservoir vorzulegen, die
er dann markiert; dieser Prozess wiederholt sich so lange, bis ein befriedigendes Ergeb-
KI-Methoden zur Email-Archivierung
Token vor einem Endtoken befinden. Zur Bestimmung der Funktion für Endtokenwerden
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 trai-
niert. 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 ange-
wendet, 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 f1-Wert von 0,885 erreicht wurde. Dies lässt sich unter An-
derem 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 Heraus-
forderung darstellt. Einfache Verfahren wie die Named Entity Recognition liefern gu-
te Ergebnisse, ebenso, wenn sehr strukturierte Daten vorliegen, wie im Fall der CNN-
Wettervorhersage, wowir es einerseits mit strukturierten Texten (HTML) und andererseits
mit einer inhärenten Datenbankstruktur zu tun haben. Daraus resultierende Regelmäßig-
keiten 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. Semi-
narankü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 Verfah-
ren 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 je-
dem Iterationsschritt eine neue Menge von Instanzen aus dem Reservoir vorzulegen, die
er dann markiert; dieser Prozess wiederholt sich so lange, bis ein befriedigendes Ergeb-
KI-Methoden zur Email-Archivierung
Page 64
64 5 INFORMATIONSEXTRAKTION
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 ge-
lernt, 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 Inbox-
Szenario beschäftigt, sowie ein erweitertes Szenario, das auf Ontologien beruht, beschrie-
ben. 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 ei-
ner 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 ge-
schehen, 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 be-
nutzt 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 er-
wä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 betref-
fende 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. pDatalog-
Implementierungen ermöglichen es, ein solches Wissensnetz mit Hilfe von Datalog-
Regeln 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 Hinter-
grundinformation fördern kann.
kiib
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 ge-
lernt, 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 Inbox-
Szenario beschäftigt, sowie ein erweitertes Szenario, das auf Ontologien beruht, beschrie-
ben. 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 ei-
ner 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 ge-
schehen, 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 be-
nutzt 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 er-
wä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 betref-
fende 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. pDatalog-
Implementierungen ermöglichen es, ein solches Wissensnetz mit Hilfe von Datalog-
Regeln 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 Hinter-
grundinformation fördern kann.
kiib
Page 70
Literaturverzeichnis
Abecker u. a. 2000
ABECKER, Andreas ; BERNARDI, Ansgar ; HINKELMANN, Knut ; KHN, Otto ; SINTEK,
Michael: Context-Aware, Proactive Delivery of Task-Specific Knowledge: The Know-
More Project. In: International Journal on Information System Frontiers (ISF) 2 (2000), Nr.
(3/4), S. 139–162
Abolhassani u. a. 2003
ABOLHASSANI, M. ; FUHR, N. ; GÖVERT, N.: Information Extraction and Automatic
Markup for XML documents. In: BLANKEN, HenkM. (Hrsg.) ; GRABS, Torsten (Hrsg.)
; SCHEK, Hans-Jörg (Hrsg.) ; SCHENKEL, Ralf (Hrsg.) ; WEIKUM, Gerhard (Hrsg.): Intel-
ligent Search on XML Data. Applications, Languages, Models, Implementations, and Bench-
marks Bd. 2818. Heidelberg et al. : Springer, 2003, S. 159–174
Appelt u. Israel 1999
APPELT, E. ; ISRAEL, 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
BEKKERMAN, Ron ; MCCALLUM, Andrew ; HUANG, Gary: Automatic Categorization
of Email into Folders: Benchmark Experiments on Enron and SRI Corpora / Univer-
sity of Massachusetts, CIIR. 2004 (IR-418). – Forschungsbericht
Belkin u. Croft 1992
BELKIN, Nicholas J. ; CROFT, 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
BOONE, 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
BRILL, Eric: Some Advances in Transformation-Based Part of Speech Tagging. In:
National Conference on Artificial Intelligence, 1994, 722–727
Brutlag u. Meek 2000
BRUTLAG, Jake D. ; MEEK, Christopher: Challenges of the Email Domain for Text Clas-
Abecker u. a. 2000
ABECKER, Andreas ; BERNARDI, Ansgar ; HINKELMANN, Knut ; KHN, Otto ; SINTEK,
Michael: Context-Aware, Proactive Delivery of Task-Specific Knowledge: The Know-
More Project. In: International Journal on Information System Frontiers (ISF) 2 (2000), Nr.
(3/4), S. 139–162
Abolhassani u. a. 2003
ABOLHASSANI, M. ; FUHR, N. ; GÖVERT, N.: Information Extraction and Automatic
Markup for XML documents. In: BLANKEN, HenkM. (Hrsg.) ; GRABS, Torsten (Hrsg.)
; SCHEK, Hans-Jörg (Hrsg.) ; SCHENKEL, Ralf (Hrsg.) ; WEIKUM, Gerhard (Hrsg.): Intel-
ligent Search on XML Data. Applications, Languages, Models, Implementations, and Bench-
marks Bd. 2818. Heidelberg et al. : Springer, 2003, S. 159–174
Appelt u. Israel 1999
APPELT, E. ; ISRAEL, 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
BEKKERMAN, Ron ; MCCALLUM, Andrew ; HUANG, Gary: Automatic Categorization
of Email into Folders: Benchmark Experiments on Enron and SRI Corpora / Univer-
sity of Massachusetts, CIIR. 2004 (IR-418). – Forschungsbericht
Belkin u. Croft 1992
BELKIN, Nicholas J. ; CROFT, 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
BOONE, 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
BRILL, Eric: Some Advances in Transformation-Based Part of Speech Tagging. In:
National Conference on Artificial Intelligence, 1994, 722–727
Brutlag u. Meek 2000
BRUTLAG, Jake D. ; MEEK, Christopher: Challenges of the Email Domain for Text Clas-
Page 76
76 Literaturverzeichnis
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 ; LIU, Xin: A re-examination of text categorization methods. In: Pro-
ceedings of the 22nd International Conference on Research and Development in Information
Retrieval. New York : ACM, 1999, S. 42–49
kiib
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 ; LIU, Xin: A re-examination of text categorization methods. In: Pro-
ceedings of the 22nd International Conference on Research and Development in Information
Retrieval. New York : ACM, 1999, S. 42–49
kiib
Sign up today - FREE
Mendeley saves you time finding and organizing research. Learn more
- All your research in one place
- Add and import papers easily
- Access it anywhere, anytime
Start using Mendeley in seconds!
Readership Statistics
1 Reader on Mendeley
by Discipline
by Academic Status
100% Post Doc
by Country
100% United Kingdom


