Classificazione delle segnalazioni cliente in base alla rilevanza secondo tecniche neurolinguistiche

1. Università degli Studi di Trieste
Dipartimento di Ingegneria e Architettura
Corso di Studi in Ingegneria Elettronica e Informatica
Tesi di Laurea Magistrale
Classificazione delle segnalazioni cliente in
base alla rilevanza secondo tecniche
neurolinguistiche
Laureando:
Dario Crosera
Relatore:
Prof. Andrea De Lorenzo
Correlatore:
Dott. Alex Dagri
ANNO ACCADEMICO 2020–2021

2. Indice
1 Introduzione 3
2 Stato dell’arte 5
3 Approccio 7
3.1 Premesse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1.1 Ticket . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1.2 Urgenza . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2 Recupero del dataset . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.3 Pre elaborazione dati . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.4 Configurazione della rete neurale . . . . . . . . . . . . . . . . . . . . 12
3.4.1 Rappresentazione del testo . . . . . . . . . . . . . . . . . . . 13
3.4.2 Unione con le altre feature . . . . . . . . . . . . . . . . . . . 14
3.4.3 Strati connessi e finali . . . . . . . . . . . . . . . . . . . . . . 14
3.4.4 Altri parametri del modello . . . . . . . . . . . . . . . . . . . 15
4 Risultati 17
4.1 Convenienza utilizzo classificatore . . . . . . . . . . . . . . . . . . . . 18
4.1.1 Senza classificatore . . . . . . . . . . . . . . . . . . . . . . . . 19
4.1.2 Con classificatore . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.1.3 Esempio numerico . . . . . . . . . . . . . . . . . . . . . . . . 21
4.2 Varianti al modello . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.3 Altre tecniche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.3.1 LSTM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.3.2 Bi-LSTM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.3.3 BERT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.3.4 USEM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.4 Confronto risultati . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
5 Conclusioni 28
1

3. Bibliografia 31
2

4. Capitolo 1
Introduzione
Ad oggi, molte compagnie utilizzano un sistema di ticketing per gestire le segna-
lazioni dei propri clienti. Spesso, saper gestire correttamente il flusso di queste
segnalazioni è ciò che determina il successo dell’azienda. Inoltre, le segnalazioni de-
vono essere trattate in modi e soprattutto tempi differenti in base alla loro urgenza
e tutto ciò è solitamente regolato in un accordo tra le parti chiamato Service Level
Agreement (SLA).
Con questa tesi si vuole analizzare e introdurre un sistema di classificazione auto-
matica dell’urgenza dei ticket per Cybertec SRL, azienda leader in soluzioni software
ad elevate prestazioni nell’ambito della pianificazione della produzione e ottimizza-
zione della Supply Chain, con conseguente riduzione dei costi, massimizzazione della
produttività e aumento del livello di servizio. Ai fini di quest’ultimo obiettivo, è
di fondamentale importanza l’attività svolta dal team di support che si occupa di
assistere il cliente nel caso in cui riscontri anomalie o malfunzionamenti del prodotto
venduto da Cybertec: CyberPlan Web.
Se un cliente deve notificare Cybertec di un malfunzionamento, rallentamento,
blocco oppure una richiesta di spiegazioni lo può fare tramite il portale di assistenza
Jira Service Desk (SD). Una richiesta di aiuto corrisponde all’apertura di un ticket
su questo portale, in questo modo Cybertec può tenere traccia di queste richieste
e gestirle tutte da un unico punto. L’assistenza clienti di Cybertec si occuperà poi
di prendere in carico il ticket ed operare per risolvere il problema riscontrato. Il
tempo massimo di presa in carico di un ticket è regolamentato dallo SLA, siglato tra
Cybertec e i suoi clienti, e varia in base alla gravità del malfunzionamento. Siccome
Cybertec è un azienda in continua espansione, con il passare del tempo aumente-
ranno di conseguenza anche il numero di segnalazioni e sarà sempre più necessario
riuscire a prendere in carico per primi i ticket più urgenti, in modo da rispettare
i tempi accordati nello SLA. L’operazione di assegnazione di una priorità ai ticket
affinché emergano i più urgenti potrebbe essere svolta da un operatore, ma richie-
3

5. de del tempo prezioso. Per questo si ritiene opportuno che il ticket arrivi già con
un’urgenza assegnata in modo automatico. Grazie all’impiego del portale Jira si
viene a creare uno storico dei problemi riscontrati dai clienti durante l’utilizzo del
software CyberPlan. Con questa tesi si vuole utilizzare questo storico delle segna-
lazioni per costruire un modello di predizione dell’urgenza delle future segnalazioni.
Così facendo, si viene a ridurre il tempo di risposta per le segnalazioni più urgenti
che verranno prese in carico per prime dal servizio di assistenza clienti.
Il campo principale in un ticket è una descrizione testuale, perciò l’elaborazione
del linguaggio naturale è stata affidata ad una rete neurale, dati i recenti sviluppi
e i risultati ottenuti con questo metodo. Oltre alla descrizione vengono impiegate
delle feature testuali costruite a partire da essa. Nel capitolo 3, dopo una parentesi
sul dataset e sul suo recupero, viene illustrata la configurazione di tale rete neura-
le. Successivamente, nel capitolo 4, vengono presentati i risultati ottenuti sia dal
modello individuato come migliore che dalle prove con modelli ottenuti utilizzando
altre tecniche e configurazioni nella costruzione della rete. I risultati ottenuti sono
i seguenti: il modello di rete sbaglia ed etichetta come “non urgenti” ticket in realtà
“urgenti” solo l’8% delle volte. Tale modello è il più semplice considerato, nonostante
le varie prove effettuate con modelli più complessi quali Bidirectional Encoder Re-
presentations from Transformers (BERT) o Universal Sentence Encoder. Una delle
cause potrebbe essere la scarsa numerosità del dataset ma anche la natura del testo
presente nel ticket, che presenta al suo interno termini tecnici in inglese, talvolta
coniati dal creatore del ticket, oppure porzioni di codice o di messaggi di errore. Un
altro motivo è che per decidere l’urgenza del ticket il personale del team di support
potrebbe utilizzare delle informazioni che non ha avuto invece a disposizione du-
rante l’etichettatura del dataset, per esempio informazioni riguardanti l’autore del
ticket: se è un dipendente di Cybertec o meno, se è una persona competente o se
l’autore è dipendente di un’azienda da cui è noto che provengono solo segnalazioni
urgenti. Per i risultati intrapresi con questa tesi si potrebbe appunto indagare su
questi ultimi aspetti citati.
4

6. Capitolo 2
Stato dell’arte
In letteratura sono già presenti articoli che descrivono diversi metodi per la classifi-
cazione automatica dei ticket arrivati in assistenza. In [1] viene infatti sottolineata
l’importanza di avere un sistema informativo efficiente per gestire le segnalazioni dei
clienti e viene proposta un’implementazione di tale sistema.
Il tipo di classificazione automatica di gran lunga più popolare è quello che si pone
come obiettivo lo smistamento dei ticket in base alla categoria, in modo da evitare
che un ticket venga reindirizzato da un team ad un altro in cerca della persona
più competente che sappia risolvere il problema. Esempi di questo tipo si possono
trovare in [2, 3, 4]. In [2, 5] vengono utilizzati metodi probabilistici. In [3] vengono
usati Multinomial Naive Bayes (MNB) e Softmax Regression Neural Network (SNN),
anch’essi metodi probabilistici. In [4], invece, vengono utilizzate tecniche di machine
learning, quali Support Vector Machine (SVM) e K-Nearest Neighbours (KNN). Per
la classificazione di segnalazioni di bug nel software, [5] utilizza una struttura più
complessa con due classificatori, uno per il testo e l’altro per gli ulteriori dati non
testuali.
I ticket per la segnalazione di bug sono stati anche studiati linguisticamente
da [6]. Ne è emerso che sarebbe più semplice se la descrizione venisse richiesta in
maniera strutturata domandando qual è l’entità coinvolta, qual è il problema, che
qualità lede il problema (usabilità, velocità, ...), se è una segnalazione di bug o una
richiesta di funzionalità. In alternativa viene suggerito di utilizzare delle tecniche
per capire queste informazioni in modo automatico dalla descrizione testuale.
In [7] viene descritto lo stato dell’arte delle tecniche per la costruzione di featu-
re testuali per la classificazione di testi scritti in linguaggio naturale. Nell’articolo
vengono individuati tre tipi di metodologie: i modelli standard che usano comuni
feature, i modelli linguistici che utilizzano feature linguistiche complesse e i modelli
universali che utilizzano le reti neurali. Di quest’ultima categoria vengono cita-
te Long Short Term Memory (LSTM), Bidirectional LSTM (Bi-LSTM) e BERT.
5

7. Gli autori concludono affermando che BERT è molto promettente, ma necessita di
calibrazione per riscuotere degni risultati in ambiti molto specifici.
Per quanto possano essere diversi i modelli di classificatori finora presentati, in
vari articoli, tra i quali [8], viene ribadita l’importanza di elaborare opportunamente
con varie tecniche (rimozione punteggiatura, stopwords, stemming, ...) il testo in
ingresso al classificatore.
Nei seguenti studi [8, 9, 10] non viene predetta la categoria del ticket ma viene
predetta rispettivamente la presenza di duplicati, la priorità e l’urgenza del ticket.
Ciò che serve in Cybertec è proprio un sistema per classificare l’urgenza dei ticket
in arrivo. Inoltre, si vuole provare ad utilizzare le tecniche più recenti in letteratura,
proprio come è stato fatto in [9]: è stata impiegata una rete neurale (con atten-
tion) per la previsione dell’urgenza dei ticket. Come fa notare [7], l’utilizzo delle
reti neurali per la classificazione dei ticket richiede una grande quantità di dati in
allenamento. Ci sono però alcuni modelli di reti neurali [11, 12, 13] che sono stati
pensati per essere allenati su dataset molto voluminosi e poi utilizzati in contesti
di dataset più ridotti, operando un cosiddetto trasferimento di conoscenza (transfer
learning).
6

8. Capitolo 3
Approccio
In questo capitolo, dopo una breve introduzione su come sono stati recuperati i ticket
che compongono il dataset, vengono esposte le feature e la configurazione della rete
neurale che hanno portato ad avere le migliori prestazioni tra le varie configurazioni
provate. (D’ora in avanti il modello di rete che ha riscosso le migliori prestazioni
verrà chiamato anche MM, che sta per modello migliore). Alcune significative con-
figurazioni di rete neurale costruite durante la ricerca del modello migliore verranno
illustrate nel capitolo 4.
3.1 Premesse
Per una maggiore chiarezza e comprensione è necessario spiegare alcuni concetti che
verranno poi utilizzati in tutto l’elaborato. É necessario chiarire:
• Cos’è un ticket
• Cosa si intende per urgenza di un ticket
3.1.1 Ticket
Un ticket è una segnalazione fatta alla divisione di supporto clienti di Cybertec tra-
mite il portale Jira Service Desk (SD). Si dice che il ticket è stato aperto quando
viene inviata questa segnalazione. I ticket possono essere di diversa natura. Un tipo
di ticket è quello che viene aperto dai clienti, che segnalano guasti o malfunziona-
menti o che richiedono spiegazioni o funzionalità. Anche un membro della divisione
supporto di Cybertec può aprire un ticket, magari perché è stato contattato per via
telefonica o via mail per la segnalazione di un problema e ne vuole tenere traccia
nel sistema. Un altro tipo di ticket è quello che può essere aperto da qualsiasi di-
pendente Cybertec che si è accorto di problemi al software, solitamente in fase di
7

9. configurazione. Questi ticket vengono aperti su un altro portale, Jira Product Tech-
nical Assistance (PTA). Ai fini della tesi, vengono presi in considerazione i ticket
provenienti da entrambi i portali, SD e PTA, senza fare più distinzione tra loro.
3.1.2 Urgenza
Il contratto che Cybertec stipula con i clienti prevede un patto per la gestione
di eventuali problemi in cui i clienti possono incorrere con l’utilizzo di CyberPlan.
Tale patto, detto Service Level Agreement (SLA), assicura che i problemi rilevati dal
cliente vengano presi in carico dalla divisione di supporto entro un tempo massimo
dalla segnalazione del cliente stesso. I problemi al software possono essere di molti
tipi e il tempo massimo della presa in carico varia in base alla loro gravità. Il limite
massimo per i problemi urgenti è di 1 ora, mentre per quelli meno urgenti è di 8 ore.
La scala per la decisione del livello di urgenza è indicata in tabella 3.1.
Ai fini della tesi si definisce urgente un ticket se ha un livello di priorità pari a
uno e quindi se è un ticket che deve essere preso in carico entro 1 ora. Così facendo
si riduce il problema della classificazione dell’urgenza ad un problema binario. Tutti
gli altri ticket che hanno priorità diversa da uno verranno considerati non urgenti.
La ragione di tale scelta è da ricondurre a due motivazioni. Prima di tutto, perché
agli utenti del supporto interessa di più individuare subito i ticket più urgenti, da
prendere in carico prima di tutti gli altri in quanto sono problemi che impediscono
l’operatività del cliente. In secondo luogo, perché si è voluto considerare un problema
più semplice ai fini dello studio da intraprendere. Lo scopo di questa tesi è proprio
quello di realizzare un modello per predire l’urgenza dei ticket in arrivo alla divisione
di assistenza clienti di Cybertec. Questa scelta di definizione binaria di urgenza non è
tanto restrittiva poiché poi si potrà riestendere il lavoro svolto ridefinendo l’urgenza
come una classe di 5 valori. Il tutto senza accantonare gli studi fatti e ricominciare
da capo.
3.2 Recupero del dataset
Per recuperare il dataset dei ticket è stato utilizzato CyberPlan, che ha al suo
interno un linguaggio di scripting simile a javascript. Il recupero dei ticket è stato
effettuato per mezzo di uno script che ha utilizzato le REST API esposte dalla
piattaforma Jira. Per non incorrere nel rischio di intasare la connessione con il
transito di tutti i dati in una sola volta, la richiesta dei ticket è stata spezzata in più
richieste con dimensione massima adeguata. I ticket presenti in Jira Service Desk
al momento del loro recupero erano 8198, sia ticket SD che PTA. Cybertec ha sia
clienti italiani che esteri, perciò oltre ai ticket in lingua italiana, sono presenti ticket
in lingua straniera, principalmente inglese. Contestualmente al recupero, lo script
si è occupato dell’anonimizzazione dei dati sensibili, come creatore e assegnatario
8

10. Livello
priorità
Descrizione Impatto
1 Molto Alta Problema Critico. Da intervenire il prima possibile
perché il sistema produttivo è bloccato
2 Alta Da intervenire presto; il Sistema Produttivo non è
bloccato ma la situazione va risolta in tempi stretti
3 Media La perdita dati o il disservizio è non significa-
tiva. L’anomalia arreca un disturbo all’utente.
Esiste un workaround accettabile che ripristina le
funzionalità
4 Bassa Non si verifica una perdita di servizio. Il compor-
tamento non è corretto, tuttavia non impedisce in
alcun modo l’utilizzo del sistema in quanto esiste
un workaround, oppure è relativo a funzionalità se-
condarie non essenziali all’operatività del Sistema
Produttivo.
5 Molto Bassa Non si verifica alcuna perdita di servizio. Il com-
portamento andrebbe sistemato, ma non impedi-
sce in alcun modo l’utilizzo del sistema, oppure
è relativo a funzionalità secondarie non essenziali
all’operatività del Sistema Produttivo.
Tabella 3.1: Priorità nel SLA
del ticket, mediante una funzione di hash (sha1). Alcuni dati sensibili potrebbero
essere presenti nella descrizione testuale del ticket perché il cliente potrebbe aver
lasciato per iscritto una mail, un numero di telefono o nomi e cognomi di colleghi.
Si è deciso però di non anonimizzare la descrizione per poterla utilizzare così com’è
in ingresso al modello. Dato che non è stata anonimizzata e che per l’azienda è
fondamentale che nessun dato confidenziale venga caricato su qualche piattaforma
di servizi in cloud, tutti i processi sono stati svolti su una workstation in locale.
9

11. 3.3 Pre elaborazione dati
Le successive elaborazioni dei ticket sono state effettuate in python, perché vi sono a
disposizione online delle librerie molto valide e sempre aggiornate sia per l’appren-
dimento automatico che per svariati altri ambiti. Si è ritenuto opportuno lavorare
solamente con ticket in lingua italiana per non dover gestire i problemi legati all’e-
laborazione di testi di diverse lingue in contemporanea. Per isolare i ticket in lingua
italiana sono state utilizzate le librerie langdet e fasttext. Tali librerie, operanti in
parallelo, hanno riconosciuto entrambe la lingua italiana o inglese per 8035 ticket
su un totale di 8198, mentre erano in disaccordo su 163 ticket. Questo disaccordo è
probabilmente dovuto alla presenza di parole tecniche in inglese e segmenti di codice
SQL che rendevano incerta la determinazione della lingua. Per i ticket in disaccordo
è stato fatto un riconoscimento manuale della lingua. Alla fine del processo, sono
stati isolati 7443 ticket di lingua italiana e 755 di altra lingua.
Nel Codice 3.1 è possibile ispezionare i principali campi di un ticket in formato
json. Sono presenti il titolo, una descrizione, le informazioni di chi l’ha creato e
di chi l’ha preso in carico, la lingua in cui è scritto il ticket, le date di creazione e
ultima modifica. Tra i campi del ticket compare una voce definita “PRIORITY”,
tuttavia indica un aspetto differente da ciò che è stato definito alla sezione 3.1.2
come urgenza. Questa “PRIORITY” è impostata di default al valore Medium per la
maggior parte dei ticket e non viene quasi mai utilizzata e modificata.
{
" ASSIGNEE ": " 0c88028bf3aa6a6a143ed846f2be1ea4 ",
" CODE ": " PTA -1002" ,
" CREATED ": "2019-12-09T15:51:12.000+0100",
" CREATOR ": " a65156af8393a7c2f5dd5a41ee09f04d ",
" DESCRIPTION ": " Ciao, lanciando lo schedulatore esce l’errore unkown
error. Rispetto al momento precedente in cui funzionava sono stati
aggiunti degli ordini di produzione con le loro domande e operazioni (es
. 2019PROD8773, 2019PROD8776, 2019PRSL8929). ",
" FIXVERSIONS ": null ,
" HQL ": " CYBWEB -7695 " ,
" LANGUAGE ": " it ",
" PRIORITY ": " Medium ",
" PROJECT ": " PTA ",
" REPORTER ": " a65156af8393a7c2f5dd5a41ee09f04d ",
" STATUS ": " Resolved ",
" SUMMARY ": " Unkown error schedulatore ",
" UPDATED ": "2019-12-10T17:16:23.000+0100",
}
Codice 3.1: Principali campi di un ticket in formato json
10

12. Un campo che non è stato riportato tra i principali è quello dei commenti, in cui
l’utente dell’assistenza clienti può richiedere maggiori informazioni al creatore del
ticket o specificare la natura del guasto e l’esito dell’intervento. Per assegnare una
priorità al ticket, si potrebbero ricavare informazioni utili a partire dai commenti
appena citati; tuttavia queste informazioni potrebbero essere mescolate anche a del
rumore, derivante dai commenti degli strumenti aggiuntivi di Jira SD. Si è deciso
però di non utilizzare i commenti per stabilire l’urgenza di un ticket poiché questi non
sono ancora presenti all’apertura di un ticket, mentre ai fini della tesi è necessario
avere all’arrivo del ticket tutte le informazioni per determinarne l’urgenza.
É stato chiesto a degli esperti in azienda di classificare i ticket secondo la defi-
nizione di urgenza stabilita in precedenza. L’etichetta applicata al ticket vale 0 se
quel ticket non è urgente, 1 se è urgente.
La scelta delle feature da utilizzare nel modello è frutto di varie prove effettuate
con diverse configurazioni della rete. Quelle che sono state impiegate nel modello
MM sono:
• Summary, feature testuale
• Description, feature testuale
• Presenza di determinate parole, 6 feature binarie costruite a partire dalla de-
scrizione. Valgono 1 se nella descrizione è presente la parola aiut*, crash*,
problem*, urg*, bloc*, err*; altrimenti valgono 0
Le feature presenza di determinate parole sono state aggiunte in seguito ad un’analisi
delle descrizioni dei ticket e si è notato un miglioramento del modello con l’utilizzo
delle stesse. Esse aggiungono della conoscenza a priori che evidentemente il modello
non riesce a cogliere.
In ingresso al modello MM, il titolo (Summary) del ticket viene accorpato all’i-
nizio del testo della descrizione, quindi d’ora in poi ci si riferirà solo alla descrizione
intendendo che il titolo è al suo interno. Questa scelta era stata fatta per comodità
iniziale, poi con ulteriori prove si è visto che trattando il titolo a parte non sono
emersi miglioramenti significativi.
Le ulteriori fasi di pre elaborazione della descrizione del ticket in ingresso al
modello MM sono:
• Conversione in minuscolo
• Rimozione di url
• Rimozione di email
• Rimozione della punteggiatura
• Rimozione stopwords, eccetto “non” (articoli, congiunzioni, etc, libreria nltk)
11

13. • Porter2 stemming (snowball stemming della libreria nltk)
Per la rimozione delle email è stata utilizzata l’espressione regolare 3.2.
[a-z0-9!#$%&’*+/=?^_{|}~-]+(?:.[a-z0-9!#$%&’*+/=?^_{|}~-]+)*@(?:[a-
z0-9](?:[a-z0-9-]*[a-z0-9])?.)+[a-z0-9](?:[a-z0-9-]*[a-z0-9])?
Codice 3.2: Espressione regolare per l’individuazione di email
Per la rimozione degli URL è stata utilizzata l’espressione regolare 3.3.
(http|ftp|https)://([w_-]+(?:(?:.[w_-]+)+))([w.,@?^=%&:/~+#-]*[w@
?^=%&/~+#-])?
Codice 3.3: Espressione regolare per l’individuazione di URL
3.4 Configurazione della rete neurale
L’implementazione della rete neurale è stata fatta in python principalmente utiliz-
zando la libreria tensorflow. Verrà ora descritta la configurazione della rete utiliz-
zata per ottenere il miglior risultato tra tutte le prove effettuate. Possiamo vedere
in Figura 3.1 e in Figura 3.2 lo schema a blocchi del modello MM.
Figura 3.1: Schema a blocchi del modello MM, parte 1. Feature in input al
modello, strati per la rappresentazione del testo e concatenazione.
12

14. Figura 3.2: Schema a blocchi del modello MM, parte 2. Connessione dallo strato
di concatenazione della Figura 3.1 con gli strati completamente connessi (Dense),
seguono strato di dropout e strato finale di normalizzazione.
3.4.1 Rappresentazione del testo
Dopo aver subito i processi di pre elaborazione la descrizione viene fatta passare in
uno strato di TextVectorization e poi di WordEmbedding.
Figura 3.3: Strato di Text Vectorization
Come si evince dalla Figura 3.3 lo strato di Text Vectorization trasforma la de-
scrizione, opportunamente scomposta in token, in una lista di interi. Ciascun intero
corrisponde alla posizione del token in un vocabolario passato come parametro al
layer. Tale vocabolario è formato dall’insieme dei token che compongono le descri-
zioni del training set. Se un token non è presente nel vocabolario allora è un termine
sconosciuto e gli viene assegnato il valore 0.
Un token individua un pezzetto della descrizione. In Figura 3.3, i token sono le
singole parole che compongono il testo. Tuttavia, si è visto che la tecnica migliore è
quella di utilizzare per token gli n-grammi con n = 1, 2, 3, 4.
[14] Un n-gramma è una sottosequenza di n elementi di una data se-
quenza. Secondo l’applicazione, gli elementi in questione possono essere
fonemi, sillabe, lettere, parole, ecc.
13

15. In questo contesto di lavoro, gli elementi citati nella precedente definizione sono le
parole delle descrizioni. Per esempio, l’insieme dei bi-grammi(n = 2) è l’insieme
delle coppie di parole consecutive nella descrizione:
Descrizione: “Il cane abbaia molto”
Bi-grammi: “Il cane”, “cane abbaia”, “abbaia molto”.
Per quanto riguarda invece l’insieme degli n-grammi con n = 1, 2, 3, 4 ecco un
esempio:
Descrizione: “Il cane abbaia molto”
1-2-3-4-grammi: “Il”, “cane”, “abbaia”, “molto”, “Il cane”, “cane abbaia”, “abbaia
molto”, “Il cane abbaia”, “cane abbaia molto”, “Il cane abbaia molto”
Il dizionario passato allo strato di Text Vectorization è quindi composto dall’insieme
di tutti i token, ovvero gli n-grammi con n = 1, 2, 3, 4, e ciascuna descrizione viene
rappresentata come la lista degli interi che identificano la posizione dei token nel
dizionario, se questi token sono presenti nella descrizione. Per limitare la comples-
sità del modello il limite al numero di token del dizionario è stato impostato a 10000.
Le descrizioni con questa nuova rappresentazione passano attraverso lo strato
WordEmbedding. Il suo compito è quello di rappresentare ciascun intero con un
vettore lungo k (embedding dimension). Dopo l’allenamento della rete lo strato di
word embedding dovrebbe assegnare a token simili tra loro dei vettori vicini tra loro.
La dimensione del vettore che è stata utilizzata è k = 32.
Dopo aver ottenuto questa rappresentazione delle descrizioni mediante una lista di
vettori lunghi k = 32, bisogna passare ad una rappresentazione della descrizione che
utilizza un un solo vettore di lunghezza k. A tale scopo viene utilizzato lo strato di
GlobalAveragePooling1D. La sua funzione è quella di fare la media dei valori lungo
una dimensione, in questo caso quella dei token che compongono la descrizione. Si
ottiene così un unico vettore che rappresenta la descrizione in input.
3.4.2 Unione con le altre feature
La descrizione così rappresentata è solo una delle feature e deve essere in qualche
modo legata alle altre feature in ingresso alla rete. Le restanti feature presenza di
determinate parole non necessitano di particolari rielaborazioni perché sono binarie.
Si è scelto di unire tutte le feature assieme concatenandole tra loro, usando appunto
uno strato di concatenazione. Ora, per ogni ticket si ha un vettore lungo 32+6 = 38
che contiene l’informazione di tutte le feature scelte per rappresentare un ticket.
3.4.3 Strati connessi e finali
Come si vede nello schema in Figura 3.2, il vettore derivato dalla concatenazione
va ora in ingresso a uno strato connesso con funzione di attivazione relu. Questo
14

16. strato ha 80 neuroni mentre gli strati successivi, sempre completamente connessi
hanno rispettivamente 40, 40 e 20 neuroni. Per limitare l’overfitting, segue a questi
strati uno strato di dropout con spegnimento impostato al 20%. Ad ogni epoca,
casualmente, il 20% dei neuroni avrà ingresso 0 e il restante avrà un ingresso scalato
di 1
1−0.2 , per compensare l’azzeramento del 20% degli ingressi. L’ultimo strato ha
un solo neurone e la funzione di attivazione è una sigmoide. In questo modo l’uscita
della rete avrà valori compresi tra zero e uno. La soglia è stata impostata a 0.5
perciò i valori predetti che sono sotto la soglia verranno considerati 0, quindi non
urgenti, e i valori sopra la soglia verranno considerati 1, quindi urgenti.
3.4.4 Altri parametri del modello
Dopo numerose prove, le quali verranno in parte descritte nel capitolo successivo,
vengono riportati di seguito i parametri del modello che hanno portato al miglior
risultato.
• Ottimizzatore: ADAM
– Learning rate: 0.0005
– Beta1: 0.9
– Beta2: 0.999
– Epsilon: 10−9
• Perdita (loss): Cross-entropia binaria
• Tutti i seed delle librerie utilizzate (per rendere gli esperimenti ripetibili):
889102
Per limitare ulteriormente l’overfitting viene utilizzata una tecnica chiamata early
stopping guardando al numero di falsi negativi presenti nell’evaluation set con una
pazienza di 20 epoche. É stato scelto di basarsi sui falsi negativi perché sono quelli
che si vogliono minimizzare. La tecnica dell’early stopping consiste in:
• Ad ogni epoca, partizionare casualmente il training set in training e evaluation
set
• Allenare il modello sul training set ristretto e valutare una misura, in questo
caso il numero di falsi negativi, sull’ evaluation set
• Interrompere l’allenamento quando questa misura non migliora per un certo
numero di epoche p. Il parametro p si chiama pazienza
• Ripristinare i pesi che la rete aveva all’epoca in cui ha prodotto le misure
migliori
15

17. La divisione del dataset in training e test è stata fatta col metodo 10-fold cross-
validation con media sugli indici. In questo modo, facendo 10 allenamenti dello stesso
modello e prendendo ogni volta una porzione del dataset diversa come test si rende
più robusta la valutazione delle prestazioni del modello. Utilizzando early stopping,
è necessaria un’ulteriore divisione del training set in training set e evaluation set ad
ogni epoca, che è stata effettuata con una percentuale rispettivamente di 80%/20%.
Le prestazioni complessive del modello dovranno essere valutate sul test set perché
l’evaluation set è stato impiegato nel processo di allenamento della rete e quindi non
si può considerare un dato nascosto che la rete non ha mai visto.
16

18. Capitolo 4
Risultati
Per valutare le prestazioni del modello di rete neurale costruito e per confrontarlo
con i vari tentativi effettuati è necessario definire degli indici di prestazione. Si
procede innanzitutto nel chiarire che cosa si intende per:
• True Positive (TP): il ticket è Urgente e viene predetto come Urgente
• True Negative (TN): il ticket è Non urgente e viene predetto come Non urgente
• False Positive (FP): il ticket è Non urgente e viene predetto come Urgente
• False Negative (FN): il ticket è Urgente e viene predetto come Non urgente
Come detto in precedenza, l’aspetto più importante per l’azienda è avere un numero
di falsi negativi più basso possibile. Perciò, è più problematico etichettare un ticket
come non urgente quando invece lo è per davvero. Per questo motivo, come misure
monitorate sono stati scelti False Positive Ratio (FPR), False Negative Ratio (FNR)
e in secondo luogo l’accuratezza per avere un’idea in generale di come si comporta
la rete.
FPR =
FP
FP + TN
FNR =
FN
FN + TP
accuracy =
TP + TN
TP + FN + TN + FP
É importante prima di tutto avere un FNR basso, poi anche un FPR basso. Ci
sono casi in cui l’FPR è prossimo a uno e FNR è prossimo a zero. In questi casi,
sebbene l’FNR sia molto basso, non è stato ottenuto un buon modello perché vuol
17

19. dire che tutte le predizioni sono quasi sempre positive. Perciò, i risultati di questo
tipo sono stati scartati.
Con il modello MM descritto nel capitolo precedente sono stati ottenuti i seguenti
risultati:
FNR FPR Accuracy
MM 0.25 0.28 0.73
Tabella 4.1: Risultati del modello migliore, MM
4.1 Convenienza utilizzo classificatore
Per verificare l’utilità e la convenienza del classificatore verrà di seguito fatto un
ragionamento sul tempo medio impiegato da un operatore della divisione support
per:
1. leggere i ticket da una coda composta di T ticket, ∆ urgenti e Γ non urgenti.
2. capire se il ticket è urgente o no. Se non è urgente il ticket viene rimesso alla
fine della coda per essere preso in carico successivamente.
Il tempo verrà calcolato sia considerando la presenza di un classificatore che predica
in automatico l’urgenza del ticket sia in sua assenza, cioè la situazione attuale in
azienda.
Sia τu il tempo che l’operatore impiega per leggere, capire e prendere in carico
un ticket urgente e sia τū il tempo che ci impiega, invece, per leggere, accorgersi che
il ticket non è urgente e rimandarlo in coda. Ciò che interessa di più nello specifico
è il tempo che l’operatore “spreca” perché incontra ticket non urgenti, mentre la
situazione ideale sarebbe quella di incontrare prima tutti i ticket urgenti. Si vuole
allora trovare il numero γ di ticket non urgenti che in media verranno visti
dall’operatore prima di incontrare tutti i ticket urgenti. Il tempo medio
impiegato sarà quindi τγ = γ · τū. Per calcolare tale caso medio verrà utilizzata
una distribuzione di probabilità chiamata ipergeometrica negativa (o inversa). Il suo
scopo è quello di modellare la probabilità di ottenere r successi estraendo da un’urna
senza reimmissione. Appena viene estratto l’r-mo successo si ferma l’estrazione. Per
ottenere r successi vengono estratti anche k insuccessi. La distribuzione è data dalla
formula:
18

20. Pr(Xr = k) =
(︁k+r−1
k
)︁(︁N−r−k
K−k
)︁
(︁N
K
)︁
• N, Numero totale di ticket
• K, Numero totale di insuccessi (ticket non urgenti, negativi)
• r, Numero di successi (ticket urgenti)
• k, Numero di insuccessi osservati
La media e varianza della variabile aleatoria è
γ(r) = E[Xr] =
rK
N − K + 1
V ar[Xr] =
(rK)(N + 1)(N − K − r + 1)
(N − K + 1)2(N − K + 2)
Verrà ora calcolato il numero medio γ(r) di ticket non urgenti estratti prima di
incontrare r ticket urgenti nei due casi: con e senza classificatore automatico.
4.1.1 Senza classificatore
Nel caso in cui non venga utilizzato alcun classificatore per l’etichettatura dei ticket,
cioè come avviene attualmente in azienda, l’operatore comincia a vedere i ticket così
come sono nella coda e si ha che:
• N = T, Numero totale di ticket
• K = Γ, Numero totale di insuccessi (ticket non urgenti, negativi)
Per trovare gli r ticket urgenti si vedranno anche in media γc̄(r) = E[Xr] ticket non
urgenti, con varianza vc̄(r) = V ar[Xr]. Volendo trovare tutti i r = ∆ ticket urgenti
si vedranno anche in media
γc̄(r = ∆) =
rK
N − K + 1
=
∆ Γ
∆ + Γ − Γ + 1
=
∆ Γ
∆ + 1
4.1.2 Con classificatore
Se è presente un sistema automatico di classificazione con un certo FPR e FNR, si
avrà che i ticket saranno così distribuiti:
• TP + FP Ticket con etichetta positiva, di cui
19

21. – TP = ∆ − FN, realmente positivi
– FP = Γ · FPR, in realtà negativi
• TN + FN Ticket con etichetta negativa, di cui
– TN = Γ − FP, realmente negativi
– FN = ∆ · FNR, in realtà positivi
L’operatore dell’assistenza clienti comincerà prima a visionare i ticket che sono stati
classificati come urgenti. Perciò, per quanto riguarda la distribuzione di probabilità
si ha che:
• N = TP + FP, Numero totale di ticket con etichetta urgente
• K = FP, Numero totale di insuccessi (ticket non urgenti)
Per trovare r ticket realmente urgenti si vedranno anche in media γ1(r) = E[Xr]
ticket non urgenti, con varianza v1(r) = V ar[Xr]. Per trovare tutti i r = TP ticket
realmente urgenti si vedranno anche in media γ1(TP) = E[XT P ] ticket non urgenti,
con varianza v1 = V ar[X]. In particolare
γ1(r = TP) =
rK
N − K + 1
=
TP FP
TP + FP − FP + 1
=
TP FP
TP + 1
Quando l’operatore ha terminato di vedere i ticket che il sistema ha etichettato
come urgenti comincerà a vedere quelli etichettati come non urgenti. Allora si avrà
che:
• N = TN + FN, Numero totale di ticket con etichetta non urgente
• K = TN, Numero totale di insuccessi (ticket non urgenti)
Con questi parametri si potrà sapere che per trovare r ticket realmente urgenti si
vedranno anche in media γ2(r) = E[Xr] ticket non urgenti, con varianza v2(r) =
V ar[Xr]. Per trovare tutti i r = FN ticket realmente urgenti si vedranno anche
in media γ2(FN) = E[XF N ] ticket non urgenti, con varianza v2 = V ar[X]. In
particolare
γ2(r = FN) =
rK
N − K + 1
=
TN FN
TN + FN − FN + 1
=
TN FN
TN + 1
Mettendo insieme le informazioni delle due partizioni, quella contenente i ticket
con predizione urgente e quella contenente i ticket con predizione non urgente, si
trova che il numero di ticket γc non urgenti che in media si vedono prima di incontrare
tutti i ∆ ticket realmente urgenti sono:
γc = γ1(TP) + γ2(FP)
20

22. Il tempo medio τc per vedere gammac ticket non urgenti prima di incontrare ∆
ticket realmente urgenti sarà:
τc = γc ∗ τ(ū)
Basterà poi confrontare il tempo medio τc, dato dal caso con il classificatore,
con il tempo medio τc̄(r) dato dal caso senza il classificatore per capire a quanto
ammonta il risparmio di tempo guadagnato dall’impiego dal classificatore, con quei
determinati FPR e FNR. La formula per il calcolo del tempo medio risparmiato,
considerando la visualizzazione di tutti i ∆ ticket realmente urgenti, è la seguente
τrisparmio(∆) = (γc̄(r) − γc)τū =
(︃
∆ Γ
∆ + 1
−
TP FP
TP + 1
−
TN FN
TN + 1
)︃
τū
La formula per il calcolo del tempo medio risparmiato, considerando la visua-
lizzazione dei primi TP ticket realmente urgenti sul totale di TP + FN, cioè una
percentuale di T P
T P +F N = 1 − FNR, è invece la seguente:
τrisparmio(TP) = (γc̄(TP) − γ1(TP)) τū =
(︃
TP Γ
∆ + 1
−
TP FP
TP + 1
)︃
τū
4.1.3 Esempio numerico
In un caso reale di applicazione potrebbe accadere che all’apertura del portale di
ticketing l’operatore di support trovi già in coda T = 50 ticket, di cui ∆ = 15 so-
no urgenti (positivi). Per prendere in carico un ticket urgente potrebbe essere che
occorrano in media τu = 180s e che invece per accorgersi che si sta leggendo un
ticket non urgente e quindi rimetterlo in coda per prenderlo in carico successiva-
mente servano in media τū = 40s. Si vuole calcolare il tempo medio in cui,
cominciando a leggerli dal primo in poi, si incontra il primo ticket urgen-
te, il diciottesimo ticket urgente e infine il ventesimo (cioè tutti i ticket
urgenti).
Nel caso in cui non venga utilizzato alcun classificatore per l’etichettatura dei
ticket si ha che:
• N = 50, Numero totale di ticket
• K = 35, Numero totale di insuccessi (ticket non urgenti, negativi)
Con questi valori si ottiene
E[X] = 2.18
V ar[X] = 6.15
21

23. Che vuol dire che per trovare r = 1 ticket urgente si vedono in media γc̄(1) = 2.18
ticket non urgenti, con varianza 6.15. Mentre, per trovare r = 13 ticket urgenti si
vedranno anche γc̄(13) = 24.06 ticket non urgenti, con varianza 22.55. Per trovarli
tutti, r = 15 si incontreranno in media γc̄(15) = 32.82 ticket non urgenti.
Utilizzando il classificatore del modello MM, avente FPR = 40% e FNR = 16%
si avrà che i ticket, facendo un’approssimazione, saranno così distribuiti:
• 27 Ticket con etichetta positiva, di cui
– 13 TP, realmente positivi
– 14 FP, in realtà negativi
• 23 Ticket con etichetta negativa, di cui
– 21 TN, realmente negativi
– 2 FN, in realtà positivi
L’operatore dell’assistenza clienti comincerà prima a visionare i ticket che sono stati
classificati come urgenti. Perciò, per quanto riguarda la distribuzione di probabilità
si ha che:
• N = 27, Numero totale di ticket con etichetta urgente
• K = 14, Numero totale di insuccessi (ticket non urgenti, FP)
Con ciò, si può affermare che per trovare r = 1 ticket urgenti si vedono in media
γ1(1) = 1.00 ticket non urgenti, con varianza 1.73. Mentre, per trovare tutti i r = 13
ticket urgenti si vedranno anche γ1(13) = 13.00 ticket non urgenti, con varianza 1.73.
Quando l’operatore ha terminato di vedere i ticket che il sistema ha etichettato
come urgenti comincerà a vedere quelli etichettati come non urgenti. Allora si avrà
che:
• N = 23, Numero totale di ticket con etichetta non urgente
• K = 21, Numero totale di insuccessi (ticket non urgenti, TN)
In questo caso, per trovare il primo urgente si vedono in media γ2(1) = 7.00 ticket
non urgenti, con varianza 28.00. Mentre, per trovare r = 2 ticket urgenti si vedranno
anche γ2(2) = 14.00 ticket non urgenti, con varianza 28.00.
Mettendo assieme le informazioni dei precedenti due casi, sempre utilizzanti il
classificatore, si ha che vengono trovati tutti i 20 ticket urgenti dopo che sono stati
visti in media anche γ = γ1(13) + γ2(2) = 13.00 + 14.00 = 27.00 ticket non urgenti.
Si possono riassumere i risultati trovati con la seguente Tabella 4.2, dove γ(r) è
il numero di ticket non urgenti estratti in media prima di trovare r ticket urgenti e
τγ(r) = γ(r) · τū è il tempo impiegato per visionare i γ ticket non urgenti:
22

24. classificatore r γ(r) τγ(r)
[ticket] [ticket] [secondi]
no 1 2.18 87
si 1 1.00 40
no 13 28.44 1138
si 13 13.00 520
no 15 32.82 1312
si 15 27.00 1080
Tabella 4.2: Confronto tempi per incontrare r ticket urgenti, con e senza classifica-
tore.
Perciò, utilizzando il classificatore c’è un risparmio medio di tempo nell’incon-
trare il primo ticket urgente di 47s. Il risparmio medio per arrivare ad incontrare 13
ticket urgenti su 15, quindi l’87% è di 618s, cioè circa 10 minuti. Inoltre, per vedere
tutti i 15 ticket urgenti c’è un risparmio medio di 232s cioè di circa 4 minuti.
Ipotizzando invece che il numero dei ticket totali sia N = 500, il risparmio medio
per arrivare ad incontrare 130 ticket urgenti su 150, quindi l’87%, è di circa 108
minuti. Inoltre, per vedere tutti i 150 ticket urgenti c’è un risparmio medio di circa
6 minuti.
4.2 Varianti al modello
Sono state fatte varie prove modificando leggermente il modello MM:
• Mantenere o togliere il titolo nella descrizione.
• Mantenere o togliere la rimozione stopwords.
• Mantenere o togliere lo stemming.
• Mantenere o togliere o modificare l’early stopping.
• Mantenere o togliere la rimozione di URL/email/punteggiatura.
• Aumentare o ridurre il numero di strati completamente connessi e il loro
numero di neuroni.
• Aumentare o ridurre la dimensione k del Word Embedding.
• Aumentare o ridurre il numero il learning rate.
23

25. • Cambiare la funzione di attivazione dell’ultimo strato.
• Mantenere o togliere le feature presenza di determinate parole.
• Utilizzare solo le feature presenza di determinate parole per allenare il modello,
senza fornire in input la descrizione.
• Introdurre altre feature: tempo di permanenza del ticket in stato aperto, nome
dell’assegnatario...
Tuttavia, questi tentativi non hanno portato a significativi miglioramenti e quindi
la configurazione descritta nel MM porta alla rete neurale con le migliori prestazioni
trovate finora.
4.3 Altre tecniche
Prima di decretare il modello MM come miglior modello di rete neurale per la
classificazione dei ticket, sono state effettuate altre prove con delle modifiche alla
rete che impiegano alcune tecniche descritte in letteratura. Queste tecniche sono
ritenute sempre più accurate nell’ambito dell’elaborazione del linguaggio naturale.
4.3.1 LSTM
Long Short Term Memory [15] è un’architettura di rete neurale ricorrente che mira
a cogliere il collegamento tra parole all’interno dello stesso testo, anche se molto di-
stanti tra loro. Per farlo deve tenere in considerazione gli stati precedenti della rete e
non solo quelli attuali. In pratica, il cambiamento rispetto alla rete MM in Figura 3.1
è che uno strato LSTM con 8 neuroni sostituisce lo strato GlobalAveragePooling1D.
4.3.2 Bi-LSTM
Bidirectional LSTM è un’architettura di rete neurale ricorrente simile a LSTM ma
al posto di utilizzare un solo strato LSTM ne utilizza due combinando poi assieme
i risultati. Nel primo strato LSTM il testo in ingresso alla rete viene fornito così
com’è, nel secondo strato LSTM l’ingresso è fornito al contrario, dalla fine all’inizio.
Per entrambi gli strati il numero di neuroni utilizzati è 80. Il fatto di utilizzare i due
strati LSTM dovrebbe comportare maggiore velocità di apprendimento in termini
di epoche e un generale miglioramento [16] perché c’è più informazione di contesto a
disposizione della rete in un determinato momento, in quanto, oltre all’informazione
della parte di testo precedente c’è anche quella della parte di testo successiva. Nelle
prove effettuate sono strati utilizzati due strati Bi-LSTM identici in cascata.
24

26. 4.3.3 BERT
Bidirectional Encoder Representations from Transformers [12] è un modello di rete
neurale ideato dai ricercatori di Google, con architettura Transformer [17] basata
sul meccanismo dell’attenzione (attention). Il punto di forza di questo modello è il
trasferimento della conoscenza (transfer learning), ovvero, si pre allena il modello
su un dataset molto ampio e poi senza operare grandi cambiamenti si utilizza la
conoscenza acquisita per fare predizioni anche su dataset con contesti molto diversi
da quelli del dataset usato in allenamento. Per migliorare le prestazioni è possibile
allenare il modello sul nuovo dataset per un po’ di epoche prima di passare alla fase
di predizione. Questa tecnica è detta fine tuning del modello. Il modello BERT
utilizzato nelle prove è stato scaricato da Tensorflow Hub, già pre allenato con un
dataset di testi di Wikipedia.
4.3.4 USEM
Universal Sentence Encoder Model [18] è un modello ideato dai ricercatori di Google
per la rappresentazione di frasi o testi come vettori di word embedding. Come per
BERT, anche USEM si basa sull’architettura Transformer [17] e si presta molto
bene per effettuare transfer learning. Sono stati utilizzati due modelli USEM che
differiscono per complessità. Verranno identificati con USEM [19] e USEM-Large
[20]. Questi modelli forniti da Google tramite Tensorflow Hub sono già allenati
con un grande dataset composto da testi provenienti da Wikipedia, pagine web di
quotidiani e forum di discussione online. Le differenze rispetto alla rete MM in
Figura 3.1 sono che lo strato di input della descrizione è direttamente collegato
allo strato di Word Embedding. In questo strato di Word Embedding è contenuta,
mediante le informazioni dei pesi, la conoscenza iniziale acquisita dall’allenamento
sul dataset di Wikipedia, web, etc... Sono state effettuate diverse prove, con e senza
fine tuning ma non si sono notati miglioramenti rispetto a MM.
4.4 Confronto risultati
Vengono presentati ora alcuni risultati ottenuti con i vari tipi di reti neurali decli-
nati, effettuando 10-fold cross-validation con successiva media sugli indici. La rete
neurale utilizzata come base è quella utilizzata dal MM e descritta al Capitolo 3,
con l’unica differenza che non sono presenti gli ultimi due strati completamente con-
nessi di 40 e 20 neuroni, per questo verrà utilizzato il riferimento MM−2D. Per ogni
tecnica - MM−2D, LSTM, BiLSTM, BERT, USEM, USEM-Large - sono state effet-
tuate prove sia con parametri di default sia cambiandone alcuni o tutti. Le tecniche
BERT, USEM e USEM-Large utilizzano nel loro nucleo la stessa tecnologia chia-
mata Transformer e probabilmente è per questo che sono stati riscontrati risultati
25

27. molto simili tra loro. Perciò verranno omessi i risultati con BERT e USEM e ver-
ranno visualizzati solo quelli con USEM-Large. Sono state anche provate le varianti
presenti alla sezione 4.2, tuttavia, di seguito, non sono presenti tutte le prove di
combinazioni effettuate ma ne sono state selezionate solo un campione significativo.
In tabella 4.3 sono presenti i risultati della rete con architettura MM−2D e con
le altre tecniche esposte. Se non espressamente specificato tutti i parametri della
rete hanno i valori definiti in precedenza per il modello MM. Utilizzando BERT e le
tecniche USEM, sono stati effettuati sia allenamenti con fine-tuning finale (ft) che
allenamenti senza. Si è visto che è più efficace utilizzare il fine-tuning. Pertanto,
nelle successive tabelle non verranno più mostrati i risultati senza fine-tuning.
FNR FPR Accuracy
MM−2D 0,25 0,28 0,73
LSTM 0.13 0.61 0.58
Bi-LSTM 0.26 0.37 0.68
USEM-Large 0.45 0.36 0.59
USEM-Largeft∗ 0.42 0.19 0.71
Tabella 4.3: Confronto prestazioni
(*) ft = fine tuning
Nei modelli di tabella 4.5 l’unica feature in ingresso è la descrizione. Si può notare
un leggero calo delle prestazioni rispetto ai modelli che utilizzano anche le feature
presenza di determinate parole, in tabella 4.3. É stata fatta inoltre una prova con un
modello che considera solamente le feature presenza di determinate parole (risultati
in Tabella 4.4) ma si è visto che il modello non riusciva a catturare le relazioni
tra queste feature e l’urgenza/non urgenza del ticket (underfitting). In particolare,
al contrario delle prove con gli altri modelli, l’accuracy durante il training non è
salita mai sopra a 0.65 e quindi non ha mai raggiunto il valore unitario. In questa
variante non è presente la descrizione e perciò non ha senso parlare di prove con
le tecniche MM−2D, LSTM, BiLSTM, BERT, USEM, USEM-Large. Il modello di
rete utilizzato è simile a quello usato da MM, ma senza il ramo che si occupa di
analizzare la descrizione.
FNR FPR Accuracy
0.51 0.26 0.64
Tabella 4.4: Prestazioni modello solo feature presenza di determinate parole
26

28. FNR FPR Accuracy
MM−2D 0.22 0.38 0.68
LSTM 0.15 0.59 0.59
Bi-LSTM 0.22 0.39 0.68
USEM-Largeft∗ 0.41 0.19 0.72
Tabella 4.5: Confronto prestazioni, solo feature descrizione
Nelle prove di tabella 4.6 è stato aumentato di un fattore 10 il learning rate.
MM−2D e LSTM hanno FPR molto alto e infatti l’accuratezza è molto bassa, per-
ciò vengono scartati a priori. Per le altre tecniche, si può vedere che non ci sono
miglioramenti significativi rispetto ai valori in Tabella 4.3.
FNR FPR Accuracy
MM−2D 0.12 0.53 0.64
LSTM 0.23 0.49 0.62
Bi-LSTM 0.31 0.32 0.69
USEM-Largeft∗ 0.41 0.19 0.72
Tabella 4.6: Confronto prestazioni, learning rate 0.005
Nelle prove di tabella 4.7 sono stati aggiunti due strati completamente connessi,
rispettivamente di 40 e 20 neuroni, subito dopo i due strati completamente connessi
di 80 e 40 neuroni. Quindi questa è la configurazione della rete MM della sezione
3.4. In questo caso MM ha FNR più basso al risultato di MM−2D in Tabella 4.3 e
FPR è ancora accettabile, perciò risulta questo il miglior modello visto finora. Per
quanto riguarda le altre tecniche, infatti, non si notano particolari miglioramenti.
FNR FPR Accuracy
MM 0.16 0.40 0.70
LSTM 0.2 0.47 0.65
Bi-LSTM 0.28 0.36 0.67
USEM-Largeft∗ 0.41 0.19 0.71
Tabella 4.7: Confronto prestazioni, aggiunta due strati connessi
27

29. Capitolo 5
Conclusioni
L’obiettivo di questa tesi è stato quello di realizzare un modello capace di predi-
re l’urgenza di un ticket in arrivo all’assistenza Cybertec. Si potrà, in tal modo,
individuare e mettere in cima ad una coda di priorità i ticket più urgenti, così da
far risparmiare agli operatori il tempo necessario per riconoscere l’urgenza. Questa
esigenza nasce dalle intenzioni e dai segnali di crescita delle vendite di CyberPlan
Web.
Come esposto nel capitolo 4 riguardante i risultati, si evince che l’utilizzo del
modello MM permette di risparmiare in media circa 4 minuti se si ipotizza di avere
50 ticket in coda. Ciò non sembra un risultato molto appetibile, tuttavia, è possibile
affermare che, sempre con l’impiego del modello MM, il risparmio riscontrato al mo-
mento della visualizzazione dell’87% dei ticket effettivamente urgenti risulta essere
di 10 minuti. Questa percentuale, infatti, è contrassegnata dall’etichetta urgente e
farà quindi parte dell’insieme di ticket visualizzato per primo dall’operatore. Inol-
tre, tale risparmio diventerà più evidente man mano che aumenterà il numero dei
ticket in coda. Si può dire dunque che, utilizzando il classificatore MM, la maggior
parte dei ticket veramente urgenti verrà vista per prima dagli operatori del team di
support, perciò l’impiego di tale classificatore è conveniente per l’azienda.
Nell’analisi iniziale delle tecnologie utilizzate finora per l’elaborazione del lin-
guaggio è stata evidenziata la potenza di tecniche quali BERT e USEM, tuttavia,
in questa applicazione non si sono rivelate particolarmente efficaci. La tecnica più
semplice impiegata nel MM, cioè l’utilizzo di Word Embedding + GlobalAverage1D,
è stata in fin dei conti quella che ha portato al miglior risultato. Le motivazioni
di questi esiti sono molteplici. In primo luogo, le descrizioni dei ticket contengono
termini tecnici particolari e frammenti di codice SQL o javascript o di messaggi di
errore che potrebbero essere fonte di rumore. Un altro motivo è che per decidere
l’urgenza del ticket il personale del team di support potrebbe utilizzare delle infor-
mazioni che non ha avuto invece a disposizione durante l’etichettatura del dataset,
28

30. per esempio informazioni riguardanti l’autore del ticket: il ticket proviene da un
cliente che è molto importante (paga molto) o no, il ticket lo ha scritto un consu-
lente interno a Cybertec o no, il ticket lo ha scritto da una persona molto o poco
competente. Per motivi di tempo queste informazioni non sono state prese in con-
siderazione ma lo potrebbero essere in ottica di un futuro miglioramento. Inoltre,
se non è subito chiara la situazione descritta nel ticket, l’operatore ha la possibili-
tà di richiedere ulteriori informazioni al cliente per cercare di comprendere più nel
dettaglio la situazione.
La bassa numerosità di ticket che compongono il dataset potrebbe essere un ul-
teriore spiegazione al problema delle basse prestazioni con le tecniche più complesse.
Le valutazioni riscontrate negli articoli riguardanti LSTM e BiLSTM si basavano
su dataset più ampi rispetto a quello utilizzato in questo lavoro. I modelli BERT
e USEM, invece, sono principalmente pensati per trasferire la conoscenza appresa
con grandi moli di dati su dataset di piccole dimensioni, ma in questa particolare
applicazione non sono stati riscontrati particolari miglioramenti.
É possibile estendere questo studio anche per la predizione di altre caratteristiche
dei ticket, oppure per raggruppare i ticket simili, perché magari fanno riferimento
tutti ad uno stesso bug riscontrato da più clienti. In tal caso converrebbe raggrup-
parli per prendere in considerazione contemporaneamente varie segnalazioni dello
stesso problema, raccogliendo così maggiori informazioni che potrebbero rivelarsi
utili alla risoluzione dello stesso.
In fin dei conti, penso che questa esperienza sia stata edificante dal punto di
vista formativo poiché mi sono affacciato al mondo delle reti neurali e del Natural
Language Processing, ho imparato ad utilizzare un nuovo linguaggio, ovvero Python,
e ho potuto toccare con mano tutte le fasi volte alla realizzazione di un progetto
in Cybertec. Tutto ciò è stato possibile grazie alla guida e all’esperienza del mio
Tutor aziendale e a quella di altri colleghi nel campo della programmazione e della
matematica.
29

31. Bibliografia
[1] Serhat Serbest et al. «Design and Implementation of Help Desk System on the
Effective Focus of Information System». In: Procedia Economics and Finance
33 (2015). The Economies of Balkan and Eastern Europe Countries in the
Changed World (EBEEC 2015), pp. 461–467.
[2] Ea-Ee Jan, Kuan-Yu Chen e Tsuyoshi Idé. «Probabilistic text analytics fra-
mework for information technology service desk tickets». In: 2015 IFIP/IEEE
International Symposium on Integrated Network Management (IM). 2015, pp. 870–
873.
[3] Gwang Son, Victor Hazlewood e Gregory D. Peterson. «On Automating XSE-
DE User Ticket Classification». In: Proceedings of the 2014 Annual Conferen-
ce on Extreme Science and Engineering Discovery Environment. XSEDE ’14.
Atlanta, GA, USA: Association for Computing Machinery, 2014.
[4] Sara Silva, Rubén Pereira e Ricardo Ribeiro. «Machine learning in incident
categorization automation». In: 2018 13th Iberian Conference on Information
Systems and Technologies (CISTI). 2018, pp. 1–6.
[5] Yu Zhou et al. «Combining Text Mining and Data Mining for Bug Report Clas-
sification». In: 2014 IEEE International Conference on Software Maintenance
and Evolution. 2014, pp. 311–320.
[6] Amy J. Ko, Brad A. Myers e Duen Horng Chau. «A Linguistic Analysis of
How People Describe Software Problems». In: Visual Languages and Human-
Centric Computing (VL/HCC’06). 2006, pp. 127–134.
[7] Ksenia Lagutina e Nadezhda Lagutina. «A Survey of Models for Construc-
ting Text Features to Classify Texts in Natural Language». In: 2021 29th
Conference of Open Innovations Association (FRUCT). 2021, pp. 222–233.
[8] Rajeshwari MR e K Kavitha. «Reduction of duplicate bugs and classification
of bugs using a text mining and contingency approach». In: International
Journal of Applied Engineering Research 12.11 (2017), pp. 2840–2847.
30

32. [9] Volodymyr Lyubinets, Taras Boiko e Deon Nicholas. «Automated labeling
of bugs and tickets using attention-based mechanisms in recurrent neural
networks». In: CoRR abs/1807.02892 (2018). arXiv: 1807.02892.
[10] Bogdan Walek. «Intelligent System for Ordering Incidents in Helpdesk Sy-
stem». In: 2017 21st International Computer Science and Engineering Confe-
rence (ICSEC). 2017, pp. 1–5.
[11] Matthew E. Peters et al. «Deep contextualized word representations». In:
CoRR abs/1802.05365 (2018). arXiv: 1802.05365.
[12] Jacob Devlin et al. «BERT: Pre-training of Deep Bidirectional Transformers
for Language Understanding». In: CoRR abs/1810.04805 (2018). arXiv: 1810.
04805.
[13] Alexis Conneau et al. «Supervised Learning of Universal Sentence Represen-
tations from Natural Language Inference Data». In: CoRR abs/1705.02364
(2017). arXiv: 1705.02364.
[14] Wikipedia. N-gramma. url: https : / / it . wikipedia . org / wiki / N - gramma
(visitato il 22/11/2021).
[15] Sepp Hochreiter e Jürgen Schmidhuber. «Long short-term memory.» In: Neural
Computation 9.8 (1997), pp. 1735–1780.
[16] M. Schuster e K.K. Paliwal. «Bidirectional recurrent neural networks». In:
IEEE Transactions on Signal Processing 45.11 (1997), pp. 2673–2681.
[17] Ashish Vaswani et al. Attention Is All You Need. 2017. arXiv: 1706.03762
[cs.CL].
[18] Daniel Cer et al. «Universal Sentence Encoder». In: In submission to: EMNLP
demonstration. In submission. Brussels, Belgium, 2018.
[19] Universal Sentence Encoder Model - Tensorflow Hub. url: https://tfhub.dev/
google/universal-sentence-encoder-multilingual/3.
[20] Universal Sentence Encoder Model Large - Tensorflow Hub. url: https://
tfhub.dev/google/universal-sentence-encoder-multilingual-large/3.
31