Bert testen met incident beschrijvingen 2 (vervolg)

Eindelijk heb ik ook mensen op het werk geinteresseerd gekregen voor een AI experiment :-)
We gaan testen of het bijsturen van de priority van GCS incidenten zinvol kan zijn. Omdat het maart is geweest dat ik hier het laatst mee bezig ben geweest (en tussendoor vooral met chars2word2vec) moet ik alles even weerophalen.
Ik maak een nieuwe dataset aan van 55.448 records. Nu met alleen GCS incidenten. Ik neem ook de langere omschrijving mee om te zien of ik de validation accuracy daarmee wellicht omhoog kan brengen. 

De eerste test lijkt wat raar te verlopen:

Zeker de loss schiet in epoch 4 en 5 naar een rare hoogte en blijft dan fixed. Ook de accuracy waarden blijven constant. Maar goed, dit is een eerste test.
Ik ga eerst de descriptions wat opschonen. Dit is zonder de 'tags'.

 
Niet heel erg veel verschil. Dan nu maar eens helemaal goed opschonen. Leestekens verwijderen en linefeeds.

Lijkt alleen maar te verslechteren. Hmmm
Dan maar eens weer terug naar alleen korte omschrijvingen:

De loss en de accuracy vertonen nu iig een mooi verloop.  Maar ook hier gaan de validatie waarden omslaan bij de 3e epoch. Ik verlaag de learning rate:

Dat geeft een iets vertraagd maar verder vergelijkbaar resultaat.
Terugkijkend lijkt de training met langere omschrijving feitelijk de beste resulaten te geven. In de 2e grafiek van boven komt de validation accuracy bij de 4e epoch zo rond de 90%. Dat die daarna raar gaat doen maakt het resultaat denk ik niet minder. Toch eens opnieuw proberen te trainen met deze situatie. Ik bouw nu een 'callback' in waardoor die stopt na een keer mindere validation loss en ook steeds het beste model opslaat.

Het lukt mij eerst niet om het opgeslagen model weer op te laden. Heeft te maken met 'customer definities'. Uiteindelijk lukt het mij om alleen de weights weer op te laden. 

  Met maar 2 epochs zit ik aan bijna de 90% validation accuracy. De F1 blijft echter steeds erg laag. Ik kijk naar de sklearn definities en zie dat een imbalanced dataset daar een oorzaak van kan zijn. 

Even kijken:

>>> Counter(val_y)

Counter({3: 46634, 2: 8364, 1: 383, 0: 44})

of

>>> Counter (test_y)

Counter({3: 9351, 2: 1642, 1: 78, 0: 4})

Ja dat is verwacht. Dat kan je wel imbalanced noemen. 

Ook even kijken hoe de predicions zijn:

>>> Counter(predicts)

Counter({3: 9785, 2: 1290})

Uiteraard ook uit balans. Wellicht moet ik meet high en critical incidenten meenemen uit andere services om het een beetje in balans te brengen.

De F1 kan ik iig ergens op laten lijken. Dat 'micro' doet wonderen:

(micro : Calculate metrics globally by counting the total true positives, false negatives and false positives.)

>>> [f1_score(test_y, predicts, average='micro')]

[0.8924604966139955]

Sluit in ieder geval beter aan bij het gevoel.