If we deploy wp10 storage, it will take lots of space and also lots of work as each class will take one row per revision, SP team decided to keep a squeezed version of it in the database that is called weighted sum and we used it before too. See this mock: https://gist.github.com/halfak/b925a2d45a3903a3e10dc5d6cd7c01b1
Description
Details
Status | Subtype | Assigned | Task | ||
---|---|---|---|---|---|
Resolved | None | T190471 [Epic] Store ORES predictions for article quality, draft quality, and draft topic in MediaWiki | |||
Resolved | Ladsgroup | T175757 Store wp10 predictions in the MediaWiki database. | |||
Resolved | Ladsgroup | T194297 Make wp10 rows be a squeezed to a weighted sum in ores_classification |
Event Timeline
Change 434689 had a related patch set uploaded (by Ladsgroup; owner: Amir Sarabadani):
[mediawiki/extensions/ORES@master] Make squeezing of score results possible so they take less rows
It seems that this metaphor works for damaging and goodfaith too. There, we want to aggregate two probabilities into one row.
E.g. a "class_selector(true)" aggregator would turn {"probability": {"true": 0.95, "false": 0.05}} into damaging 0.95
Similarly a "weighted_sum(weights)" aggregator would turn {"probability": {"Stub": 0.34, ..., "FA": 0.01}} into weighted_sum 1.67
We already store one row for damaging classes because you can get the other one by subtracting from 1
Right. I guess what I was getting at is that storing one row is already a form of aggregation (selection).
Change 434689 merged by jenkins-bot:
[mediawiki/extensions/ORES@master] Make aggregation of score results possible so they take less rows
Change 437295 had a related patch set uploaded (by Ladsgroup; owner: Amir Sarabadani):
[mediawiki/extensions/ORES@master] Make ScoreParser aggregate wp10 predictions
Change 437295 merged by jenkins-bot:
[mediawiki/extensions/ORES@master] Make ScoreParser aggregate wp10 predictions