Bert testen met incident beschrijvingen

Nu ik de methodiek van classificatie van teksten met Bert "onder de knie" lijk te hebben wil ik ook eens wat andere situaties testen die meer in mijn vakgebied liggen. Ik laad daartoe , als eerste, de korte omschrijvingen van 15000 incidenten (helaas is er tegenwoordig een export aantal ingericht in ServiceNow) en kijk of ik de bijbehorende prioriteit kan voorspellen.

De teksten zijn merendeels in Engels dus ik gebruik "Bert-base-uncased".
Voorbeelden zijn:

1 - Critical - customer master block - W & K MOVEIS LTDA
1 - Critical - Error message upon GATP simulation CRITICAL
1 - Critical - update Profit Centers as per attached file
1 - Critical - The Production system is completely down for BPDH , PDH and FORDH
3 - Moderate - Error while updating master data
3 - Moderate - CDP050909: Deliveries failed
3 - Moderate - CN137684
3 - Moderate - Error 500 - Internal Server Error
3 - Moderate - Subcontractor Work Order WO-00905176 not changing to fixed after service receipt is done.

3 - Moderate hk18 MM DOC#5255057187 blocked in SAP, but no reflect in RBAM

We hebben: ['1 - Critical', '2 - High', '3 - Moderate'] als labels.
De eerste keer lijkt nergens op. Al na de 2e epoch zakt de accuracy terug naar bij de .50. Dan bedenk ik mij dat ik natuurlijk wel de teksten 'uncased' moet maken. Dat gaat heel veel beter:

Het lijkt er dus op dat ik (eh ... Bert), aan de hand van de korte omschrijvingen, met 81% zekerheid kan voorspellen wat de juiste prioriteit is. Omdat Moderate het meeste voorkomt check ik een deel van de voorspelde waarden:

>>> df.priority.value_counts()
3 - Moderate    8578
2 - High        5718
1 - Critical     704

>>> predicts[:100]
array([2, 1, 2, 1, 1, 2, 1, 1, 2, 2, 2, 2, 2, 2, 2, 1, 1, 2, 1, 2, 1, 2,
       1, 1, 2, 2, 2, 1, 1, 2, 0, 1, 1, 2, 2, 2, 1, 2, 2, 2, 2, 2, 2, 1,
       2, 2, 2, 0, 2, 2, 2, 2, 1, 1, 1, 2, 2, 2, 1, 2, 2, 1, 1, 2, 2, 1,
       2, 2, 2, 1, 2, 2, 0, 2, 2, 2, 1, 1, 2, 2, 2, 2, 2, 2, 2, 1, 1, 1,
       2, 2, 1, 2, 2, 2, 2, 2, 1, 2, 1, 2], dtype=int64)

Hij gaat er dus zeker niet vanuit dat alles een moderate uitkomst moet hebben. (wat al een 58% correcte uitkomst zou kunnen opleveren)

Update 17/2/2020: Ik merk bij mijn DIRKje test dat het inkorten van de teksten tot op zekere hoogte verbetering van het resultaat geeft. Daarnaast worden de traintijden veel korter. Ik probeer dat ook met deze dataset. Ik maak de lengte maximaal 32 tokens. De batchsize kan ik dan 100 maken waardoor de traintijd teruggaat naar zo'n 55 seconden per epoch. Dat is leuk testen! (Ik weet niet zeker meer hoeveel hij er oorspronkelijk over deed. ) 
Ik kijk ook eens naar de vorm van de tokenopslag:

'[CLS] us : cleveland : net ##app na ##01 ##6 is down global hosting hosting database em ##ea at ##os supply team [SEP] [PAD] [PAD] [PAD] [PAD] [PAD] [PAD] [PAD] [PAD] [PAD] '

of

'[CLS] [ ultrasound hyper ##care ] { cs j ##ms rc mb ##p 2 } aix _ on _ demand - nl ##yeh ##vb ##pa ##12 procedure : jd _ mb [SEP] '

De [PAD] blijkt bij Bert basis op nummer 0 te staan. De padding gaat hier dus iig goed.

Interessant! Ook hier geeft het wegnemen van informatie ongeveer een % verbetering in zowel de F1 als in de test accuracy.