Page MenuHomePhabricator

Suggesting AbuseFilter by machine learning
Open, Needs TriagePublic

Description

Currently, we should manually write down Extension:AbuseFilter's pattern (string match, regex, etc). It is a very hard task for non-technical users and consumes technical user's time.

I propose a machine learning approach that would suggest patterns to be used for AbuseFiliter; this would reduce difficulties and development time. For example, when I put marks on some revisions or users, I can get the suggested pattern generated by machine learning which extracts points in common among the specified revisions or user's contributions.

I don't have any concrete methods or implementations because I'm specialized in neither the machine learning or natural language processing. But I heard it's not impossible.

--aokomoriuta (talk) 23:56, 9 November 2015 (UTC)

This card tracks a proposal from the 2015 Community Wishlist Survey: https://meta.wikimedia.org/wiki/2015_Community_Wishlist_Survey

This proposal received 0 support votes, and was ranked last out of 107 proposals. https://meta.wikimedia.org/wiki/2015_Community_Wishlist_Survey/Moderation_and_admin_tools#Suggesting_AbuseFilter_by_machine_learning

Event Timeline

DannyH raised the priority of this task from to Needs Triage.
DannyH updated the task description. (Show Details)
DannyH subscribed.
IMPORTANT: If you are a community developer interested in working on this task: The Wikimedia Hackathon 2016 (Jerusalem, March 31 - April 3) focuses on #Community-Wishlist-Survey projects. There is some budget for sponsoring volunteer developers. THE DEADLINE TO REQUEST TRAVEL SPONSORSHIP IS TODAY, JANUARY 21. Exceptions can be made for developers focusing on Community Wishlist projects until the end of Sunday 24, but not beyond. If you or someone you know is interested, please REGISTER NOW.

Bad-Words-Detection-System sounds very similar to this. We use BWDS to find content that is added in revisions that get reverted, but is also uncommon in revisions that are not reverted. We'd probably want to put some sort of user-interface on top of it in order to make it work ad-hoc.

Seems a lot easier to just provide better editing tools (for example something regex101-ish for the regular expressions and Blocky or something similar for the general program structure).

@Tgr, I think this task is about discovering textual patterns in diffs that are worth flagging in AbuseFilter. I'm not sure how better editing tools would make it easier to discover these patterns.

Part of the problem statement was that regexes are hard to use for non-technical users. I was just suggesting that writing an AI might not be the most effective approach to fix that. (For one thing, they still need to be able to evaluate whatever regex suggestions a machine learning system would come up with.)

Oh! That's a good point. Seems like we're looking at two separate problems here. (1) regex syntax is hard and (2) discovering patterns that should exist in abusefilter is hard.

Perhaps instead of suggesting patterns, some kind of score could be passed to filters.

Making ORES scores available to AbuseFilter as variables would be a relatively easy way to partially fix this.

Agreed with MGChecker. There's no need to write from scratch a new AI for detecting vandalism. We already have ORES, let's keep improving it and make it communicate with AF. It'd be a huge advantage to have its score available in AF. I just don't know if it's feasible.