@Makyen I think the real fix is to make a db constraint to prevent duplicate identical feedbacks. There still could be duplicate non-identical feedbacks after that, but at least half the problem would be solved.
@thesecretmaster I'm not familiar enough to say if it's better to have both, but just a check for exact duplicates isn't sufficient to cover all cases. Given that it's necessary to check for non-exact-duplicates anyway, it seems doing such a check would solve both problems, as long as the check doesn't ignore exact duplicates.
A constraint against duplicates sounds reasonable, and we certainly don't want duplicates. I just don't know what the trade-offs are for having such a constraint vs not having it.
So, random question. Was there a reason the particular spam scoring method in use was chosen? Interested in reading up on the theory behind how it works so well. (Full disclosure: facing a similar problem at work that I'm debating using this scoring method for vs. a bayesian/consensus opinion pool method.)
I am not really sure whether to consider that spam or just blatantly off-topic - still I mentioned it here in case the same link is posted also on other sites.
@DanielWiddis Yes, but it was chosen prior to my being involved with the project, so I don't feel I'm the appropriate person to answer.
That being said, it's a relatively common, simplified method of combining multiple criteria where you know the probability (in this case, the demonstrated historical incidence) of each one being the state that you are desiring to determine.
@DanielWiddis OTOH, the formulas for actually treating the "weights", which are equivalent to Floor(% incidence), as probabilities and calculating the probability that item A is actually TP when detected by L, M, and N, which have historically seen (85% TP, 53% TP, and 47% TP), aren't all that difficult.
@DanielWiddis For each detection, the detection's "weight" is the Floor(historical percentage of posts detected by that reason which are TP).
@DanielWiddis I've actually been thinking about trying sort of Bayesian approach to calculating flag weight, because our current system sometimes gives too much weight to tightly-correlated reasons.
For example, "Toxic answer detected" and "Offensive answer detected" both have flag weights around ~80, but over half of toxic answers are also offensive (and the two reasons combined has a 90% TP rate)
I still have to do some experiments though, to see if a different approach could actually improve our accuracy significantly.
@NobodyNada I was going to post a thread on the teams about that, but don't have enough background. I've actually spent a significant amount of time professionally dealing with the bayesian approach which works well when the final probability (as a percentage) is important. However, for a simple "is it bad or not" it may be overkill.
IIRC we came to the current approach by writing the simple formula, trying it out on real data, and figuring out what thresholds we needed to achieve ~99.9% accuracy. Nothing beats actually experimenting with the data
It does slightly bother the statistician in me to see people say things in chat like "adding this rule to up the score" or "not adding this because the score is too high already and it's overkill". I don't like excluding information! :)
@NobodyNada That works. In my current work situation we have a bunch of single rules where any single one of them triggers the "failure" threshold. Which we think is catching a lot of false positives and costing us $$$. So my job is to improve it. Not the only reason I'm here but it's a good excuse to be logged in here while at work as a form of research. ;)
teward/Osiris: In getting MS post information, recovered from requests.exceptions.ReadTimeout: HTTPSConnectionPool(host='metasmoke.erwaysoftware.com', port=443): Read timed out. (read timeout=10.0)
teward/Osiris: In getting MS post information, recovered from requests.exceptions.ReadTimeout: HTTPSConnectionPool(host='metasmoke.erwaysoftware.com', port=443): Read timed out. (read timeout=10.0)
teward/Osiris: In getting MS post information, recovered from json.decoder.JSONDecodeError: Expecting value: line 1 column 1 (char 0)
@DanielWiddis "Adding this rule to up the score" isn't really a problem IMO -- if it significantly increases the score, then it means we've added a highly-accurate rule, and we're essentially just feeding more information into the system.
"Not adding this because the score is too high already and it's overkill", on the other hand, doesn't sound like a good idea to me -- although this post doesn't not need more reasons, the next post linking to the same domain/whatever might.
Which goes back to my comment that I'm new and don't have enough info yet and it seems to be working pretty well as is. So I'll keep taking notes and stealing ideas. :)
@NobodyNada That's not true the way it's used when something like that is said. The reasons have a specific historical accuracy, which is based on the criteria which is used to place something on that list, or remove it. If the criteria which are in place for something to qualify to be on that list is ignored in order to "Adding this rule to up the score", then it's really just adding that number, it's not really adding the actual weight of that detection to the real probability.
@DanielWiddis Do keep in mind that we've never really had anyone with professional stats/ML expertise, so we've mostly just kinda figured it out as we went along. We're super-pleased with the results -- if it ain't broke, don't fix it -- but our implementations aren't going down in textbooks as prime examples of pure applied statistics :)
Basically, he fed data dumps into Tensorflow, came up with a model that was OK but not great (way less accurate than our current rules), and then presented at a conference talking about how he changed the world for all of us silly old dinosaurs who still use regex!
after giving the talk, he disappeared and hasn't been back -- the project never went anywhere, since we don't have anyone with the expertise to make the model both useful enough and performant enough
AI overpromises and underdelivers. Except in the narrow edge case of serving ads on social media, where thanks to lax privacy laws it's pretty effective.
@Makyen That pattern looks like it's already caught by Potentially bad keyword in answer and Potentially bad keyword in body; append -force if you really want to do that.
@Mast That pattern looks like it's already caught by Potentially bad keyword in answer and Potentially bad keyword in body; append -force if you really want to do that.
Figuring out what is and isn't spam can be tricky at times. For example, take this post on Magento. On any other site it would've been spam. It's written like spam. But it's actually an answer.
@Mast That pattern looks like it's already caught by Potentially bad keyword in answer and Potentially bad keyword in body; append -force if you really want to do that.
:55609440 That pattern looks like it's already caught by Potentially bad keyword in answer and Potentially bad keyword in body; append -force if you really want to do that.
[ SmokeDetector | MS ] Bad ip for hostname in body, bad keyword in body, bad keyword in title, blacklisted website in body, body starts with title and ends in url, +3 more (537): Alpha Femme Keto Genix Canada by orlandois on graphicdesign.SE
@Mast That pattern looks like it's already caught by Blacklisted website in answer and Blacklisted website in body; append -force if you really want to do that.
