Page MenuHomePhabricator

Inconsistent data type for articlequality score predictions on ptwiki
Closed, ResolvedPublic1 Estimated Story PointsBUG REPORT

Description

Steps to replicate the issue (include links if applicable):

What happens?: The predicted article class is now a boolean instead of one of the strings that appear as keys for the probability dictionary:

{
  "ptwiki": {
    "models": {
      "articlequality": {
        "version": "0.8.0"
      }
    },
    "scores": {
      "60845189": {
        "articlequality": {
          "score": {
            "prediction": true,
            "probability": {
              "1": 0.6505766596726758,
              "2": 0.09876741829105372,
              "3": 0.0634780511261501,
              "4": 0.06104126161283134,
              "5": 0.0573997480745124,
              "6": 0.06873686122277664
            }
          }
        }
      }
    }
  }
}

What should have happened instead?: The predicted article class should be identical to one of the keys in the probability dictionary (the string "1" in the example, which is the key that maximizes the probability value):

...
            "prediction": "1",
            "probability": {
              "1": 0.6505766596726758,
...

Other information:

The problem does not happen when one of the other classes has the highest probability:

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald Transcript
calbon set the point value for this task to 1.
calbon moved this task from Unsorted to Ready To Go on the Machine-Learning-Team board.

I found that this is caused because of the mixed schema of the responses returned by ORES. The prediction field is either a boolean, a string or a list of strings and we have the following in our schema

class Score(BaseModel):
    prediction: Union[bool, str, List[str]]
    probability: Dict[str, float]

The prediction field in the above pydantic model also declares a priority. This means that first it will try to evaluate a boolean and this is what happens as "1" is evaluated as true.
I'm working to provide a universal solution for this to cater for both options properly (booleans and strings).

Change rOMWC1009470b3df7 had a related patch set uploaded (by Ilias Sarantopoulos; author: Ilias Sarantopoulos):

[machinelearning/liftwing/inference-services@main] ores-legacy: fix mixed boolean and string field

https://gerrit.wikimedia.org/r/1009470

The attached patch solves the issue. I will deploy it to staging and add some httpbb tests that capture this behavior before I deploy to production.

Change rOMWC1009470b3df7 merged by jenkins-bot:

[machinelearning/liftwing/inference-services@main] ores-legacy: fix mixed boolean and string field

https://gerrit.wikimedia.org/r/1009470

Change 1009720 had a related patch set uploaded (by Ilias Sarantopoulos; author: Ilias Sarantopoulos):

[operations/deployment-charts@master] ml-services: update ores-legacy image (fix boolean/str fields)

https://gerrit.wikimedia.org/r/1009720

Change 1009720 merged by jenkins-bot:

[operations/deployment-charts@master] ml-services: update ores-legacy image (fix boolean/str fields)

https://gerrit.wikimedia.org/r/1009720

@He7d3r I have deployed the fix in production and it is working as expected.

That is great! Thank you! 😃