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, leider fehlt die wichtige Aufgliederung der "falschen" Entscheidungen in die Fälle falsch positiv und falsch negativ.
Peter
* Peter Jacobi wrote:
Björn, leider fehlt die wichtige Aufgliederung der "falschen" Entscheidungen in die Fälle falsch positiv und falsch negativ.
Die Frage ist nicht unbedingt sinnvoll. Mir ging es darum mal zu sehen was man ohne sich vorher mit dem Thema beschäftigt zu haben in ein paar Stunden machen kann; die Zahlen bedingen hier auch einander. Ich hab grad mal den Lernmechanismus sehr grob verändert, so dass vor allem be- halten-Entscheidungen dazugelernt werden und Löschungen vernachlässigt. Damit werden dann behalten-Entscheidungen mit einer Treffsicherheit von 99% vorausgesagt, Löschentscheidungen aber nur noch mit 37%.
(Immer wenn richtig klassifiziert wird lass ich den Text lernen wenn sich die "Wahrscheinlichkeit" in einem bestimmten Bereich befindet, dafür hat CRM114 einen "pR" Wert, beim Löschen muss der zwischen 0.51 und 0.55 sein, beim behalten kleiner als 1.0).
Ferner gibt es ja das Problem mit der Erwartungshaltung. Im Datensatz ist zum Beispiel ein Artikel, ein grammatikalisch schlechter Wörterbuch- eintrag in einem Satz zu einem Begriff aus der Pornographie zu dem es einen Artikel gibt; mein Skript erwartet Löschung, der Artikel wurde aber zu einer Weiterleitung gemacht und behalten. Das zählt dann als Fehler.
Ein anderes Beispiel ist ein Artikel der in der falschen Sprache war, aber offensichtlich mitsamt {{inuse}} zur Übersetzung die dann folgte importiert. Mein Skript erwartet hier auch eher die Löschung, wurde aber behalten, wieder ein Fehler.
Hinzu kommen dann mehrere dutzend Artikel bei denen ich die Löschung nicht gut nachvollziehen kann, oder die Begründung falsch ist (wobei ich die Begründung ohnehin schon ignoriere). Ich nehme da mal als ein Beispiel einen Artikel zu einer Hilfsorganisation von einem angemelde- ten Benutzer der schon länger angemeldet ist und andere Artikelarbeit verrichtet hat; die Organisation ist fern ab von offensichtlicher Ir- relevanz, der Artikel war durchaus umfangreich und inhaltlich stimmig, mit leicht werblichem Charakter (und allerdings auch Kritik).
Nach 101 Sekunden musste der Artikel schnellverschwinden ohne Antrag, ohne Ansprache, "[[WP:WWNI|Reiner Werbeeintrag]]". Wenn man Skript da eine Behaltensentscheidung vorhersagt kann ich das kaum als Fehler ein- ordnen.
Bei einigen Fällen muss man wohl auch die geheime Versionsgeschichte zu Hilfe ziehen um die Löschung irgendwie nachvollziehen zu können. So zum Beispiel bei einem überaus relevantem deutschem, inzwischen ver- storbenen Archäologen mit einem sehr brauchbaren Stub. Wurde keine 10 Minuten später schnellentfernt, angeblich (ich kann das ja selbst nicht nachprüfen) weil der Autor die Seite geleert hat. "Kein Artikel". Da kann man dem Skript das behalten auch nicht vorwerfen.
Ein Stadtteil der kroatischen Hauptstadt von einem altgedienten Be- nutzer musste auch mit fast schon böswilligem Löschkommentar schnell- verschwinden, und ist nach Löschprüfung wieder da. Ist da ein Löschen jetzt die richtige, oder die falsche Einschätzung?
So kann man das noch das eine oder andere dutzend Beiträge weiterführen. Da bietet es sich nicht an, daraus derart detailierte Zahlen abzuleiten, zumal ja ohnehin wieviele der schnelllöschfähigen Beiträge durch miser- able Benutzerführung zustande kommen. Man benutzt die Suchbox, es gibt zu der genauen Anfrage keinen Artikel aber einen rot leuchtenden Link gleich ganz oben über den sonstigen Ergebnissen; den klicked man, dann kommt eine grosse Textbox, da gibt man was ein und schickt es ab. Wenn man den Link in den Sucherebnissen unter statt über die Einzelergebnisse nimmt, und statt einen Roten zur Erstellungsmaske zu setzen, lieber nen blauen zu "Neuen Artikel erstellen", hätte man schon mal eine weitgehend andere Artikeleingangssituation (behaupte ich mal bis zum Beweis des Ge- genteils).
(Davon abgesehen, um die Frage zu beantworten, wenn ich mich recht er- innere waren die "Fehl"-einschätzungen anteilig an der Klassengrösse in etwa gleich auf, für genaueres bräuchte ich auch eine Zählmethode. Wenn man einen Artikel erstellt, man fängt an ihn zu ändern, dann wird er ge- löscht, und mit dem Speichern erstellt man ihn neu, und dann wird er er- neut gelöscht. Zählt das als ein neuer Artikel oder zwei?)
Am 19. Dezember 2009 03:47 schrieb Bjoern Hoehrmann derhoermi@gmx.net:
Hinzu kommen dann mehrere dutzend Artikel bei denen ich die Löschung nicht gut nachvollziehen kann, oder die Begründung falsch ist (wobei ich die Begründung ohnehin schon ignoriere). Ich nehme da mal als ein Beispiel einen Artikel zu einer Hilfsorganisation von einem angemelde- ten Benutzer der schon länger angemeldet ist und andere Artikelarbeit verrichtet hat; die Organisation ist fern ab von offensichtlicher Ir- relevanz, der Artikel war durchaus umfangreich und inhaltlich stimmig, mit leicht werblichem Charakter (und allerdings auch Kritik).
Nach 101 Sekunden musste der Artikel schnellverschwinden ohne Antrag, ohne Ansprache, "[[WP:WWNI|Reiner Werbeeintrag]]". Wenn man Skript da eine Behaltensentscheidung vorhersagt kann ich das kaum als Fehler ein- ordnen.
Bei einigen Fällen muss man wohl auch die geheime Versionsgeschichte zu Hilfe ziehen um die Löschung irgendwie nachvollziehen zu können. So zum Beispiel bei einem überaus relevantem deutschem, inzwischen ver- storbenen Archäologen mit einem sehr brauchbaren Stub. Wurde keine 10 Minuten später schnellentfernt, angeblich (ich kann das ja selbst nicht nachprüfen) weil der Autor die Seite geleert hat. "Kein Artikel". Da kann man dem Skript das behalten auch nicht vorwerfen.
Ein Stadtteil der kroatischen Hauptstadt von einem altgedienten Be- nutzer musste auch mit fast schon böswilligem Löschkommentar schnell- verschwinden, und ist nach Löschprüfung wieder da. Ist da ein Löschen jetzt die richtige, oder die falsche Einschätzung?
So kann man das noch das eine oder andere dutzend Beiträge weiterführen.
Könntest du hier oder im Wiki mal eine Liste der deiner Ansicht nach zu Unrecht schnellgelöschten Artikel anlegen, damit man die wiederherstellen kann?
viele Grüße, elian
Hallo,
das ist nur halb korrekt. Ich habe bereits seit zwei Jahren ein Programm laufen, das auf Basis von Naive Bayes [1] sämtliche neue Artikel von IPs bewertet [2]. Dabei sind alle Artikel positiv, die nach 7 Tagen noch existieren, alle anderen negativ (also alle, die schnellgelöscht wurden sind "SPAM"). Seit das läuft wurden 440.000 Artikel bewertet, wovon 350.000 SPAM waren (also innerhalb der ersten 7 Tage wurden knapp 80% gelöscht). Wie das bei Naive Bayes so ist kann man schön für jedes Wort sehen, wie oft es in SPAM-Artikeln vorkam und wie oft in HAM-Artikeln und es gibt wenige Überraschungen (67% aller Vorkommen von "das" waren in Spam-Artikeln - das liegt im Durchschnitt, wohingegen über 99% aller Vorkommen von "mudda" in Spam-Artikeln waren und nur 35% aller Vorkommen von "Kirche" in Spam-Artikeln waren).
Für jeden neuen Artikel wird eine Spam-Klassifikation vorgenommen, die von 0 bis 100% reicht. Um den Erfolg zu messen, protokolliere ich, wie es sich dann wirklich verhält. Es lässt sich dabei erkennen, dass der Anteil echter SPAM-Artikel mit der Spam-Wahrscheinlichkeit korreliert. Aber selbst von den Artikeln mit 0% werden am Ende knapp über 50% gelöscht und von denen mit über 98% Spam-Wahrscheinlichkeit werden trotzdem rund 3,5% behalten!
Automatisch kann man daher mit einfachen Mitteln meiner Meinung nach nicht viel tun. Vermutlich kann man mit besseren Algorithmen ein wenig mehr erreichen (Naive Bayes ist ja einer der einfachsten, aber Thunderbird arbeitet auch mit nicht viel besserem). 100% Sicherheit wird man aber nicht hinbekommen.
Und ich spreche mich stark dagegen aus, etwas automatisch zu löschen. Bei all den Diskussionen sind die Artikel, die so einwandfrei Spam sind, dass sie ein Algorithmus erkennen könnte, nicht das Problem - diese werden zu den meisten Zeiten verdammt schnell gelöscht - das kostet ja kaum Zeit. Problematisch sind die Fälle, in denen halt selbst für einen Menschen schwierig zu entscheiden ist, was man mit dem schlechten Artikelanfang macht.
Grüße, Christian Thiele
[1] http://de.wikipedia.org/wiki/Bayes-Klassifikator [2] http://toolserver.org/~apper/npp/
Moin
On 17.12.2009, at 17:58, Christian Thiele wrote:
Automatisch kann man daher mit einfachen Mitteln meiner Meinung nach nicht viel tun. Vermutlich kann man mit besseren Algorithmen ein wenig mehr erreichen (Naive Bayes ist ja einer der einfachsten, aber Thunderbird arbeitet auch mit nicht viel besserem). 100% Sicherheit wird man aber nicht hinbekommen.
Und ich spreche mich stark dagegen aus, etwas automatisch zu löschen. Bei all den Diskussionen sind die Artikel, die so einwandfrei Spam sind, dass sie ein Algorithmus erkennen könnte, nicht das Problem - diese werden zu den meisten Zeiten verdammt schnell gelöscht - das kostet ja kaum Zeit. Problematisch sind die Fälle, in denen halt selbst für einen Menschen schwierig zu entscheiden ist, was man mit dem schlechten Artikelanfang macht.
hmm also als jemand der im studium schonmal mit automatischen plagiat-prüfungen stress hatte, bin ich da gespaltener meinung. zum einen denke ich das es durchaus sinn macht auch diese "verdammt schnell gelöscht " zu automatisieren. hier eingespaarte zeit ist sicherlich besser anderen ortes genutzt. dennoch sollte man es nicht dem automaten vertrauen und dies in regelmäßigen abständen überprüfen.
aber die plagiats suche zum beispiel.... wo setzt man da die grenze? in meiner schulzeit hieß es immer "ihr dürft nicht mehr als 4 wörter am stück aus der quelle übernehmen. wenn ich aber den namen einer RFC übernehmen muß, dann sind es meistens schon mehr. allerdings denke ich das es sinn machen könnte dies zu automatisieren. wenn jemand in kurzen abstand viele lange neue artikel anlegt, dann könnte man nen bot nutzen um schonmal admins auf mögliche quellen für plagiate hinzuweisen.
also teilweise automatisieren um die entscheidungsprozesse zu unterstützen... klares ja. aber klares nein zu: automatisieren um entscheidungen vollständig zu ersetzen!
cu assetburned
2009/12/17 Bjoern Hoehrmann derhoermi@gmx.net:
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.
Ah, ein Neuling in der Wikipedia....
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.
crm114 verspricht 99,9% was ich auch glaube weil ich mich mit den bayes'schen theoremen genug auseinandergesetzt habe. Die Diskrepanz kann nicht an deiner unvollständigen Datenmenge liegen, da diese Filter schon ab zweihundert Datensätzen stabil laufen. Was dir in deiner Datenmenge wahrscheinlich fehlt sind ein paar Artikel die schon mehrere Edits hinter sich haben. Könntest du diese also bitte auch noch mit einbeziehen?
Statt aber zu löschen würde ich es interessant finden den User um einige Verbesserungen zu bitten und dann nochmal zu testen.
ciao, tom
* Thomas R. Koll wrote:
crm114 verspricht 99,9% was ich auch glaube weil ich mich mit den bayes'schen theoremen genug auseinandergesetzt habe. Die Diskrepanz kann nicht an deiner unvollständigen Datenmenge liegen, da diese Filter schon ab zweihundert Datensätzen stabil laufen.
Naja das Versprechen kommt in der Form von "has been seen" und die Frage wäre 99,9% von was genau, es gibt ja eine Reihe von Löschgründen die man so nicht vorhersagen kann, und wenn man die Grenzen der Methode berück- sichtigt, und ständig nachtrainiert bei Fehlentscheidungen und geringem Entscheidungsfaktor, dann sind 99,9% natürlich die fast logische Folge.
Meinem Eindruck nach sind rund 5% der Schnelllöschungen so, dass da auch Menschen sich uneins darüber wären, ob der jeweilige Artikel jetzt unbe- dingt schnellgelöscht werden musste, da bräuchte es dann schon struktu- relle Änderungen (wie zum Beispiel die Administratoren zur Verwendung von leicht maschinenlesbaren und vor allem zutreffenden Löschbegründun- gen anzuhalten) um in die Nähe derlei Raten zu kommen.
Sicherlich richtig ist wohl, dass man mit etwas mehr Aufwand und Ahnung vom Thema da auch noch ein bisschen rauskitzeln kann, ich verwende mit TOE ("train on error") zum Beispiel die falsche Lernmethode für den Hy- perspace Matcher (bei dem das Bayestheorem übrigens nicht zum Einsatz kommt). Wenn das jemand näher verfolgen möchte stelle ich auch Nachfrage mein Skript zur Datensammlung bzw. die damaligen Rohdaten gerne zur Ver- fügung.
Mir ging es viel eher darum mal zu gucken was man als Ahnungsloser da an nem Nachmittag schon erreichen kann.
Was dir in deiner Datenmenge wahrscheinlich fehlt sind ein paar Artikel die schon mehrere Edits hinter sich haben. Könntest du diese also bitte auch noch mit einbeziehen?
Das kann ich so nicht nachvollziehen, zumal die Zahl der Neuen Artikel die praktisch fertig sind (mit Infobox, Kategorien, Tabellen, Listen, Quellen, Weblinks, und Bildern) erschreckend hoch ist. Ich wüsste dem- nach nicht, welche zusätzlichen Artikel ich da einspeisen sollte.
(Interessant wäre es übrigens mal die deutschsprachige Wikipedia zu klonen, wobei allerdings von jedem Artikel nur die erste Version ge- nommen wird. Das wäre eventuell mal ein Lehrstück in Sachen Wikiprin- zip.)
* Bjoern Hoehrmann wrote:
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).
Ich hab das Experiment nochmal wiederholt von 2010-01-24T18:51:18Z bis 2010-01-26T09:38:30Z mit 2127 neuen Artikeln bzw. Weiterleitungen. Die Lernmethode habe ich leicht angepasst, wenn der Hyperspace classifier einen pR-Wert von unter 0.55 liefert, wird der Artikel nachgelernt. Es wurde jeweils die Kombination "Lemma - Benutzer - ZQ - Text" betrachtet.
Nicht betrachtet habe ich diesmal Weiterleitungen und zähle es nicht als Fehler, wenn die erste Revision einer Neuanlage automatisch ge- sichtet wurde, CRM114 aber eine Löschung prophezeit. Die Fehler teilen sich so auf:
46 mal (inklusive der Lernphase) falsch "löschen", davon inzwischen
2 x URV 4 x Gelöscht (sprich, nach Ende der Aufzeichnung) 5 x Redirect draus gemacht 12 x LA 23 x Ausgebaut, Erkennungsfehler, ...
77 mal (inklusive der Lernphase) falsch "behalten", davon inzwischen
1 x Wieder da als URV 2 x Wieder da als Redirect 1 x Wieder da nach BNR Überarbeitung 73 x Blieb gelöscht
Das wäre also eine Fehlerrate von irgendwo zwischen
(46 + 77) / 2127 = 5.78% (23 + 73) / 2127 = 4.51%
Eine gewisse Fehlerrate ist natürlich zwangsläufig, Relevanz und Re- dundanz und Urheberrechtsverletzungen lassen sich so natürlich nicht aufspüren, ebenfalls findet man schnelle Ausbauten nicht, zum Beispiel http://de.wikipedia.org/w/index.php?oldid=69757056 wäre ein Fall wo die Löschung nahe lag, zwei Stunden später dann aber nicht mehr. Und natürlich sind auch einige nicht nachvollziehbare Schnellöschungen da- bei.
Bei den Neuanlagen die gelöscht wurden schaffte es nur ein Drittel länger als zwei Minuten zu bleiben, ein Drittel war in unter einer halben Minute weg, der Median liegt um und bei 53 Sekunden.
Damit sehe ich meine im Dezember geäusserte Vermutung bestätigt, dass man den Anteil der richtigen Voraussagen problemlos auf 95% steigern kann, allerdings reichte eine leicht angepasste Lernmethode und eine etwas saubere Datenbasis aus, bei der Evaluierung sehe ich auch nicht, dass man über eine Analyse des Wikifizierungsgrades oder derlei noch viel herausholen könnte. Die Benutzeraktivität habe ich hier insoweit berücksichtigt, als dass ich das automatische Sichten der ersten Re- vision herangezogen habe.
Interessanter Weise, wie ich grad noch festgestellt habe, ist der In- halt der Kommentarzeile (zusammen damit, Sichtern alles durchgehen zu lassen) fast ausreichend um auf eine Richtig-Erkennungs-Rate von 92% zu kommen. Offenbar ist "Lemma - Benutzer - ZQ - Text" analysieren zu lassen auch nicht unbedingt die beste Methode, nimmt man "- Text -" alleine verbessert sich die Rate auf 95.25%, nimmt man noch ein paar von den Problemfällen von oben hinzu (ohne jetzt geguckt zu haben wie die genauen Auswirkungen sind) wäre man damit wohl bei bei einer Feh- lerrate von unter 4%.