Om verder te kijken wat we in de (IT) bedrijfsprocessen met AI zouden kunnen doen heb ik opnieuw een setje incidenten (GCS - Global Customer Service) geladen (24.586 records) maar deze keer met de tijdsduur die het heeft genomen om het incident te behandelen. Hiermee wil ik kijken of ik kan voorspellen hoe moeilijk (tijdsintensief) het betreffende incident is. (Of dus 'gaat zijn').
Omdat de tijdsduur in seconden staat opgenomen lijkt het mij zinvol om een logaritmische schaal toe te passen. Hierdoor krijgen we uitkomsten van tussen de 0 en de 7 (6.792 om precies te zijn).
Bij het omzetten naar logaritmische waarden krijg ik -inf waarden als de tijdsduur 0 is. Dat moet ik eerst even corrigeren om het model goed te laten werken.
Hier is een verdeling van de (naar beneden) afgeronde logaritmische waarden:
Als input gebruik ik de 'Short description', de 'Service' en de 'Assignmentgroup' en de 'Description' tot een maximum lengte van 128 tokens. De Service blijkt uitsluitend 'GCS Helpdesk' te zijn, dus die kan ik eigelijk uitsluiten. De assignmentgroup moet er ook eigelijk uit. Dat is wellicht juist iets wat later op basis van de complexiteit moet worden gestuurd.
Normaal heb ik met het Bert model classificaties uitgevoerd. Nu gaat het om een regressie probleem: Het vinden van een getal welke de 'duur' (complexiteit) aangeeft. De loss pas ik aan naar 'mse' (mean squared error) Al snel weet ik het model nu aan de praat te krijgen.
Bij 4 epochs vindt die het beste resultaat. Maar hoe goed doet die het nou? Een error van, zeg maar, 0.82 is dat nu goed (genoeg) of niet?
Door ook weer hier te tellen hoeveel voorspellingen goed zouden zijn krijg je een beetje een indruk. Dit wordt in dit geval bepaald door de 'acceptabele afwijking'.
Bij een maximale afwijking van 1.0 krijg ik 0,79% correctheid. Dus in vrijwel 80% van de gevallen lijkt de complexiteit redelijk juist te voorspellen.
Of dit ook in de praktijk bruikbaar kan gaan zijn moet nog blijken.
Ik ga nu ook even kijken of ik de hierboven genoemde overbodige 'features' eruit kan halen en alleen op basis van de korte beschrijving andere resultaten krijg.
Dat lijkt toch wat minder positief.
print("Percentage correct :",count / len(test_y))
Percentage correct : 0.4493877551020408
Als ik de lange omschrijving toch mee neem krijg ik dit resultaat:
Percentage correct : 0.6557142857142857
Met het toevoegen van alle initiele (door de gebruiker ingevulde) invoervelden, zoals 'Incident Type', ('Service'), 'Configuration item', 'Impact', 'Short description' en 'Description' haal ik ruim 70%
Percentage correct : 0.7157788944723618
Dat valt niet tegen.
Incident type = {'Question', 'Complaint', 'Incident'}
Configuration item verwijst meestal naar de betreffende applicatie ('Incenter Online' of bijv. 'MS Office') maar kan ook nar en locatie verwijzen (bijv. 'ServiceMax NAM')
Impact = {'3 - Low', '2 - Medium', '1 - High'}
Als ik een opschoning doe door veel voorkomende afkortingen om te zetten alsmede email adressen weg te halen wordt het nog beter (hoewel de beste 'val loss' iets hoger lijkt uit te komen- ruim 74%:
Percentage correct : 0.744321608040201
Een 2e keer hetzelfde, met anders geshuffelde gegevens, geeft iets vergelijkbaars.
Percentage correct : 0.7276381909547739
>>> confusion_matrix(np.round(test_y),np.round(predicts))
array([[ 0, 0, 4, 4, 19, 1, 0, 0],
[ 0, 0, 1, 0, 0, 0, 0, 0],
[ 0, 0, 404, 595, 205, 6, 0, 0],
[ 0, 0, 144, 764, 738, 10, 0, 0],
[ 0, 0, 16, 181, 1017, 45, 0, 0],
[ 0, 0, 5, 67, 423, 51, 2, 0],
[ 0, 0, 7, 42, 186, 29, 3, 0],
[ 0, 0, 0, 1, 4, 1, 0, 0]], dtype=int64)
Geen opmerkingen:
Een reactie posten