[Wikide-l] Automatisierte Kontrolle von Neuen Artikeln

Bjoern Hoehrmann derhoermi at gmx.net
Do Dez 17 01:34:01 UTC 2009


Hallo,

  Ich hab vor einiger Zeit mit etwas Fassungslosigkeit zur Kenntnis ge-
nommen, dass die Kontrolle von neuen Artikeln inklusive dem Stellen von
Schnelllöschanträgen bzw. dem administrativem Schnelllöschen im Wesent-
lichen manuell erfolgt. Ich hab daraufhin angeregt, die neuen Artikel
einfach mal durch einen klassichen Spamfilter zu schicken um so Tasta-
turtests und derlei automatisch zu erkennen (und dann gegebenenfalls
gleich zu verhindern).

Um zu schauen wie da die Trefferquote wäre hab ich das schnell mal im-
plementiert, wie ich auch schon auf der Liste erwähnte. Ich hab das an
einem zweiten Datensatz nochmal verifiziert. Beim zweiten Anlauf ist 
der Prozess denkbar einfach: Ich hab von 2009-12-06T00:43:49Z bis hin
zu 2009-12-07T14:10:07Z alle Neueinstellungen inklusive Löschungen und
Verschiebungen mitgeschnitten.

Darunter waren 1737 neue Artikel. Ich hab dann versucht die von CRM114
(http://crm114.sourceforge.net/) in eine von zwei Kategorien ("+", "-")
einzuteilen. Dazu hab ich zu jeder Neueinstellung das "Lemma", den Be-
nutzer und seinen Einstellungskommentar sowie das Wiki-Markup zu einem
Textzusammengefasst und den an CRM114 weitergegeben.

Ich bin davon ausgegangen, wenn der Artikel im Beobachtungszeitraum
schnellgelöscht wurde, dann soll er in die Kategorie "-", ansonsten in
die Kategorie "+". Jedesmal wenn CRM114 dem widerspricht wird der Text
zum "lernen" übergeben, wenn CRM114 richtig rät wird das als Erfolg ge-
wertet.

So ist in der Erwartungshaltung natürlich einiges an Rauschen drin, zum
Beispiel gibt es von der Artikelqualität her einige recht gute Beiträge
für das Humorarchiv, ebensowenig lassen sich Artikel mit leicht werb-
lichen Charakter, Redundanzen, Urheberrechtsverletzungen, und so weiter
auf diese Weise zuverlässig erkennen. Im Datensatz sind auch ein paar
Fälle mit dabei wo das administative Schnelllöschen wenig nachvollzieh-
bar ist.

Die Löschkommentare geben es derzeit leider nicht her, dass man damit
wirklich sinnvoll solche Datenprobleme beseitigen kann; in der englisch-
sprachigen Wikipedia gibt es ein Codesystem für Schnelllöschungen. Ich
weiss nicht wie da die Disziplin der Administratoren ist, aber es sieht
von aussen durchaus wohlstrukturiert aus. Vor allem können Löschopfer
da auch eine detailiertere Erklärung anhand des Codes nachlesen.

Ich hab vornehmlich den experimentellen "hyperspace" Matcher verwendet
da der schnell durchläuft und augenscheinlich gute Ergebnisse liefert.
Über den gesamten Datensatz entscheidet der (inklusive der Lernphase,
beim ersten Artikel entscheidet ja praktisch der Zufall) in 87% der
Fälle richtig.

Betrachtet man die 1000 Fälle (von etwas unter 1737, bei einigen der
Artikel war mein Skript nicht schnell genug um den Text zu beziehen),
bei denen CRM114 sich am sichersten war, oder einfach nur die letzten
1000 Artikel, liegt CRM114 in rund 92% der Fälle richtig.

Nach manueller Durchsicht der Fehlentscheidungen gehe ich davon aus,
dass man mit etwas sauberer Datenbasis (man bräuchte eigentlich für
jeden Artikel "Sollte ein Filter hier 'behalten' oder 'löschen' ent-
scheiden?" mit der dazugehörigen Portion Realismus, sowie mehr als
die 38 Stunden Daten die ich benutzt habe), so wie ein paar mehr Da-
ten ala "Neuautor vs. Alter Hase", oder wahrscheinlich eher noch "Hat
Markup, Überschriften, Kategorien" dass man das auf 95% steigern kann.

Das dürfte in etwa der Erfolgsquote der momentanen manuellen Kontrolle
entsprechen. Die ist damit also rein technisch und theoretisch durchaus
vermeidbar. Ich würde entsprechend mal anraten, dass ein geneigter Bot-
schreiber mit Zugriff auf die "archive" Tabelle das Experiment hier mal
für einen Monat an Daten wiederholt und die Ergebnisse veröffentlicht.
-- 
Björn Höhrmann · mailto:bjoern at hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/