aprendizagem computacional para gestão de incidentes em ... · outras bibliotecas para linguagem...

FACULDADE DE ENGENHARIA DA UNIVERSIDADE DO PORTO

Aprendizagem Computacional paraGestão de Incidentes em Tecnologia da

Informação

Leonardo de Jesus Macedo

Mestrado em Engenharia de Software

Orientador: Professor Dr. João Carlos Pascoal Farias

Co-Orientador: Professor João Pedro Carvalho Leal Mendes Moreira

24 de Julho de 2019

Aprendizagem Computacional para Gestão de Incidentesem Tecnologia da Informação

Leonardo de Jesus Macedo

Mestrado em Engenharia de Software

24 de Julho de 2019

Resumo

Atualmente, onde os serviços de TI se tornaram essenciais na vida de muitas pessoas, grandescompanhias de tecnologia enfrentam um complexo e caro problema operacional: manter os seussistemas estáveis e operacionais o maior tempo possível.

Para garantir a entrega e disponibilidade dos serviços de TI, companhias que possuem suaprópria infraestrutura de tecnologia, recorrem a frameworks de gerenciamento de serviços de tec-nologia da informação (GSTI ou ITSM) como a Biblioteca de Infraestrutura de Tecnologia daInformação (ITIL) para administrar os seus serviços.

A framework ITIL estrutura a gestão de serviços de TI através de 5 livros que descrevem osciclos de vida de um serviço de TI e seus respetivos processos e funções.

O livro "ciclo de vida de operações de serviços de TI"da biblioteca ITIL, descreve, entre outros,o processo de Gestão de Incidentes e solicitações de serviços, responsável por fornecer diretrizespara a equipa da central de serviços, que é o ponto único de contacto (SPOC) entre usuários dosserviços de TI e os SME, com o objetivo de restabelecer os serviços em caso de falha e proveratendimento às solicitações dos usuários.

Por ser um processo que exige da equipa de central de serviços a execução de tarefas repe-titivas e manuais, o processo de Gestão de Incidentes é muitas vezes considerado confuso, caro,demorado e totalmente dependente da perícia dos técnicos de primeiro nível, que precisam registar,categorizar, priorizar e tentar prover uma solução para cada ticket de suporte recebido.

Este trabalho tem como objetivo, demonstrar através de um conjunto de dados de 50 mil re-gistos históricos de tickets de suporte (previamente classificados), a implementação de um modelopreditivo de aprendizado de máquina que auxilie o processo de categorização e priorização detickets de suporte pela equipa de primeiro nível da central de serviços.

Diferentes algoritmos de classificação supervisionado foram implementados através da bibli-oteca open-source de aprendizagem de máquina Scikit-Learn para linguagem Python.

Outras bibliotecas para linguagem Python como NLTK, Pandas e Numpy, foram utilizadaspara as tarefas de pré processamento, formatação, normalização e extração de features do conjuntode dados.

Os resultados alcançados em cada modelo preditivo gerado, variaram de acordo com a distri-buição de amostras por classe para cada campo previsto. Para maximizar os resultados, técnicas dehiperparametrização foram utilizadas através de grid search atingindo uma precisão de até 98%.

Keywords: ITSM, ITIL, aprendizagem de máquina, classificação de incidentes, processamento delinguagem natural, classificação de texto, Python, SciKit-learn

i

Abstract

Nowadays, where IT services have become essential in many people’s lives, large technologycompanies face a complex and expensive operational problem: Keep their systems stable andoperational as long as possible.

In order to ensure the IT services reliability and availability, the Service Desk team acts as asingle point of contact (SPOC) between the customers and the IT support team.

Ordinarily, when customers report an IT issue to level-1 persons (service desk attendants), theperson must follow an IT Service Management (ITSM) process known as Incident Managementprocess, which has guidelines and tasks for the handling of incident tickets and user requests. Forbeing considered confusing, expensive, time-consuming and totally dependent of technical skillsby level-1 persons which are accountable for the registing, categorizing, prioritizing and findinga solution (or forward to a specialist to provide it) for each IT issue and customer request, theIncident Management process is often questioned by its current performance.

The aim of this work is automating the classification task for the incident and customer re-quests performed manually by the service desk team, using machine learning techniques and natu-ral language processing (NLP) processes to create a predictive model using the Python Librariessuch Scikit-Learn, NLTK, Pandas, Numpy and others.

Keywords: ITSM, ITIL, machine learning, incident classification, natural language processing,text classification, Python, SciKit-learn

iii

Agradecimentos

À minha mãe, todo o meu amor e agradecimento pelo apoio e confiança de sempre.

Aos orientadores, Prof. João Carlos Pascoal Farias e Prof. João Pedro Carvalho Leal MendesMoreira o meu reconhecimento.

E por fim, à todos, que de forma positiva, participaram um pouco desta jornada direta ouindiretamente.

Leonardo J. Macedo

v

Conteúdo

1 Introdução 11.1 Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Descrição do problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.3 Objetivo e metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.3.1 CRISP-DM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.4 Estrutura do documento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 O Processo de Gestão de Incidentes de TI 72.1 O Framework ITIL para gestão de Serviços de TI . . . . . . . . . . . . . . . . . 72.2 Os ciclos de vida e processos ITIL . . . . . . . . . . . . . . . . . . . . . . . . . 82.3 Central de Serviços . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.4 Classificação de Incidentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.4.1 Categorização . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.4.2 Priorização . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3 Estado da Arte 133.1 Aprendizagem de máquina . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.1.1 Aprendizagem supervisionada . . . . . . . . . . . . . . . . . . . . . . . 133.1.2 Aprendizagem não supervisionada . . . . . . . . . . . . . . . . . . . . . 14

3.2 Classificação de texto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.2.1 Classificação supervisionada de texto . . . . . . . . . . . . . . . . . . . 15

3.3 Extração de features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.3.1 Part-of-speech tagging . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.3.2 Stemização . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.4 Algoritmos de aprendizagem de máquina supervisionada . . . . . . . . . . . . . 173.4.1 Naive Bayes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.4.2 Support Vector Machine (SVM) . . . . . . . . . . . . . . . . . . . . . . 183.4.3 Random Forest e Decision Tree . . . . . . . . . . . . . . . . . . . . . . 193.4.4 Regressão Linear . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.5 Avaliação dos algoritmos de classificação e seleção de modelo . . . . . . . . . . 203.5.1 Métricas de avaliação do modelo classificador . . . . . . . . . . . . . . . 213.5.2 Aplicações técnicas para classificação de tickets de suporte . . . . . . . . 23

4 Compreensão e Preparação de Dados 254.1 Conjunto de dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254.2 Pré processamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4.2.1 Filtro de amostras indevidas . . . . . . . . . . . . . . . . . . . . . . . . 264.3 Distribuição de classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

vii

viii CONTEÚDO

4.3.1 Remoção de classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304.4 O problema de desequilíbrio de classes . . . . . . . . . . . . . . . . . . . . . . . 30

4.4.1 Oversampling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304.4.2 Undersampling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314.4.3 Técnicas aplicadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

5 Modelação e Avaliação 355.1 Pipelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355.2 Cross validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

5.2.1 Grid Search . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385.3 Especificações Técnicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395.4 Avaliação dos resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

5.4.1 Interpretação dos resultados - Negócio . . . . . . . . . . . . . . . . . . . 405.4.2 Interpretação dos resultados - Classificação . . . . . . . . . . . . . . . . 405.4.3 Resultados: tipo de ticket . . . . . . . . . . . . . . . . . . . . . . . . . . 415.4.4 Resultados: categoria . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435.4.5 Resultados: business service . . . . . . . . . . . . . . . . . . . . . . . . 455.4.6 Resultados: item ou sub-categoria . . . . . . . . . . . . . . . . . . . . . 475.4.7 Resultados: impacto . . . . . . . . . . . . . . . . . . . . . . . . . . . . 495.4.8 Resultados: urgência . . . . . . . . . . . . . . . . . . . . . . . . . . . . 515.4.9 Resultados: técnicas de balanceamento de classes . . . . . . . . . . . . . 535.4.10 Resultados: classificador hierárquico . . . . . . . . . . . . . . . . . . . 53

6 Conclusões 556.1 Trabalhos futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

6.1.1 Extração de features com técnicas de Part-of-Speech Tagging . . . . . . 56

Referências 57

Lista de Figuras

1.1 Quantidade média de tempo em que os tickets de suporte aguardam na fila . . . . 21.2 Quantidade média de tempo de trabalho (esforço) gasto para o atendimento de um

ticket de suporte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2.1 O ciclo de vida dos processos ITIL . . . . . . . . . . . . . . . . . . . . . . . . . 92.2 Ciclo de vida de um ticket de suporte . . . . . . . . . . . . . . . . . . . . . . . . 102.3 Definição de prioridade de um incidente: IMPACTO X URGÊNCIA . . . . . . . 12

3.1 Fluxo de trabalho do processo de extração de features, classificação e validaçãodo modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.2 Exemplo de conjunto de dados linearmente separável utilizando SVM . . . . . . 193.3 Exemplo de classificação com algoritmo Random Forest . . . . . . . . . . . . . 193.4 A função linear de relação entre as variáveis de entrada x e a consequência y . . 203.5 Exemplo de relatório consolidado de avaliação do modelo classificador . . . . . . 223.6 Exemplo de matriz de confusão comparando os resultados previstos com os valo-

res reais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4.1 Exemplo de tratamento de registos com a biblioteca Pandas . . . . . . . . . . . . 264.2 Distribuição de classes: Ticket Type . . . . . . . . . . . . . . . . . . . . . . . . 274.3 Distribuição de classes: Categoria . . . . . . . . . . . . . . . . . . . . . . . . . 274.4 Distribuição de classes: Business Service . . . . . . . . . . . . . . . . . . . . . . 284.5 Distribuição de classes: Item ou Sub_categoria . . . . . . . . . . . . . . . . . . 284.6 Distribuição de classes: Impacto . . . . . . . . . . . . . . . . . . . . . . . . . . 294.7 Distribuição de classes: Urgência . . . . . . . . . . . . . . . . . . . . . . . . . . 294.8 Remoção de classes campo Categoria . . . . . . . . . . . . . . . . . . . . . . . 304.9 Distribuição de amostras por classes de Categoria após a utilização de técnica de

Oversampling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324.10 Distribuição de amostras por classes de Categoria após a utilização de técnica de

Undersampling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324.11 Distribuição original de amostras por classes de Categoria . . . . . . . . . . . . 33

5.1 Implementação de scikit-learn pipeline para algoritmos de classificação supervi-sionada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

5.2 A função train_test_split do Scikit-Learn . . . . . . . . . . . . . . . . . . . . . . 375.3 Cross Validation - Fluxograma . . . . . . . . . . . . . . . . . . . . . . . . . . . 375.4 Cross Validation - Avaliação de modelo . . . . . . . . . . . . . . . . . . . . . . 385.5 Exemplo de implementação de hiperparametrização com Grid Search . . . . . . 395.6 Avaliação e eleição de hiperparâmetros com Grid Search e CV . . . . . . . . . . 395.7 Matriz de confusão Ticket Type - Algoritmo Naive Bayes - accuracy: 0.97 . . . . 42

ix

x LISTA DE FIGURAS

5.8 Matriz de confusão Ticket Type - Algoritmo Naive Bayes e Grid Search - accuracy:0.98 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

5.9 Matriz de confusão Categoria - Algoritmo Random Forest - accuracy: 0.83 . . . 445.10 Matriz de confusão Categoria - Algoritmo Naive Bayes e Grid Search - accuracy:

0.85 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445.11 Matriz de confusão Business Service - Algoritmo Naive Bayes - accuracy: 0.48 . 465.12 Matriz de confusão Business Service - Algoritmo Naive Bayes e Grid Search -

accuracy: 0.60 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465.13 Matriz de confusão Item ou Sub-Categoria - Algoritmo Naive Bayes - accuracy:

0.52 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485.14 Matriz de confusão Item ou Sub-Categoria - Algoritmo Naive Bayes e Grid Search

- accuracy: 0.57 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485.15 Matriz de confusão Impacto - Algoritmo Random Forest - accuracy: 0.97 . . . . 505.16 Matriz de confusão Impacto - Algoritmo Random Forest e Grid Search - accuracy:

0.97 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 505.17 Matriz de confusão Urgência - Algoritmo Random Forest - accuracy: 0.97 . . . . 525.18 Matriz de confusão Urgência - Algoritmo Random Forest e Grid Search - accu-

racy: 0.97 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 525.19 Estrutura Hierárquica para classificação do campo Categoria . . . . . . . . . . . 54

Lista de Tabelas

2.1 Exemplo de notificação de falha a equipa da central de serviços através de texto . 112.2 Categorização de incidente com modelo TCI baseado em tecnologia . . . . . . . 112.3 Categorização de incidente com modelo TCSI baseado em serviço . . . . . . . . 11

3.1 Texto de entrada para extração de features em part-of-speech . . . . . . . . . . . 163.2 Saída de seleção de features: nouns NN e proper nouns NNP . . . . . . . . . . . 17

5.1 Tipo de Ticket - Avaliação de resultados . . . . . . . . . . . . . . . . . . . . . . 415.2 Tipo de Ticket - Hiperparametrização . . . . . . . . . . . . . . . . . . . . . . . 415.3 Categoria - Avaliação de resultados . . . . . . . . . . . . . . . . . . . . . . . . . 435.4 Categoria - Hiperparametrização . . . . . . . . . . . . . . . . . . . . . . . . . . 435.5 Business Services - Avaliação de resultados . . . . . . . . . . . . . . . . . . . . 455.6 Business Service - Hiperparametrização . . . . . . . . . . . . . . . . . . . . . . 455.7 Item - Avaliação de resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . 475.8 Item - Hiperparametrização . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475.9 Impacto - Avaliação de resultados . . . . . . . . . . . . . . . . . . . . . . . . . 495.10 Impacto - Hiperparametrização . . . . . . . . . . . . . . . . . . . . . . . . . . . 495.11 Urgência - Avaliação de resultados . . . . . . . . . . . . . . . . . . . . . . . . . 515.12 Urgência - Hiperparametrização . . . . . . . . . . . . . . . . . . . . . . . . . . 515.13 Resultados a partir das técnicas aplicadas para o desbalanceamento de classes . . 53

6.1 Resultados finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

xi

xii LISTA DE TABELAS

Abreviações

ADASYM Adaptive SyntheticANS Acordo de Nível de ServiçoCMDB Configuration Manager Data BaseCPU Central Processing UnitCRISP-DM Cross Industry Standard Process for Data MiningCV Cross ValidationDDR Double Data RateGB Giga ByteGS Grid SearchHDD Hard Disk DriveIA Inteligência ArtificialIC Item de ConfiguraçãoISO International Organization for StandardizationIT Information TechnologyITIL Information Technology Infrastructure LibraryITSM Information Technology Service ManagementKPI Key Performance IndicatorML Machine LearningNB Naive BayesNLP Natural Language ProcessOS OversampingRF Random ForestSLA Service Level AgreementSME Subject Matter ExpertSMOTE Synthetic Minority Over-sampling TechniqueSMOTE-NC Synthetic Minority Over-sampling Technique for Nominal and ContinuousSPOC Single Point of ContactSSD Solid State DriveSVM Support Vector MachineTB Tera ByteTI Tecnologia da InformaçãoTCI Tipo, Categoria, ItemTCSI Tipo, Categoria, Serviço, ItemREN Reconhecimento de Entidades NomeadasNLP Natural Language ProcessingNLTK Natural Language ToolkitURL Uniform Resource LocatorUS Undersampling

xiii

Capítulo 1

Introdução

Este capítulo descreve a motivação que levou ao desenvolvimento deste trabalho, bem como a

apresentação do problema abordado.

1.1 Motivação

Na maioria dos casos, onde um usuário solicita ou relata alguma falha dos serviços de TI, é

necessário acionar o único ponto de contacto (Single Point of Contact da sigla SPOC) entre ele e

a equipa de suporte. A central de serviços (Service Desk).

Ao ser acionada, a equipa de primeiro nível da central de serviços (Service Desk), precisa

classificar e registar a solicitação/incidente através de um ticket de suporte, categorizando e prio-

rizando a partir da descrição do usuário.

O registo incorreto do ticket de suporte pode ocasionar entre outros problemas, no diagnóstico

incorreto de uma falha, o encaminhamento incorreto para a equipa de especialistas (SME), o não

atendimento dos acordos de serviços de serviço (ANS) e métricas incorretos/imprecisas sobre o

trabalho realizado pelas equipas de suporte.

Apesar de os debates e discussões regulares da comunidade que questiona por quanto tempo

este atual modelo de atendimento, que muitas vezes é considerado caro e ultrapassado, sobre-

viverá a atual revolução digital, o relatório anual mais recente de Techinical Support Practices& Salary:Ticket Management and Metrics Edition [1] divulgado pela HDI, uma das principais

organizações de eventos e serviços do mundo e reconhecida pelo trabalho na melhoria dos proces-

sos em gestão de serviços de TI, mostra que em 2018 61% das organizações observaram umaumento no número de tickets de suporte atendidos pelas equipas da central de serviços.

Dados do mesmo relatório, mostram também que, 56% das empresas observadas, tiveram um

tempo médio de espera por atendimento de suporte (em fila) superior a 24 horas (figura 1.1),

mas 74% destas mesmas empresas observaram que o tempo médio de esforço (effort), ou seja,

o trabalho efetivo da equipa na resolução da demanda foi entre menos de 15 minutos a 2 horas,

somando todos os níveis de atendimento (Figura 1.2).

1

2 Introdução

Figura 1.1: Quantidade média de tempo em que os tickets de suporte aguardam na fila

Figura 1.2: Quantidade média de tempo de trabalho (esforço) gasto para o atendimento de umticket de suporte

1.2 Descrição do problema 3

Estes dados demonstram que, de facto, o processo de gestão de incidentes, começa a se mos-

trar ineficiente no atual cenário de crescente demanda de trabalho para as equipas de central de

serviços, dado a grande quantidade de informações e registos que os técnicos precisam lidar para

proceder com o atendimento de cada ticket de suporte recebido.

1.2 Descrição do problema

Ao receber uma solicitação de serviços ou notificação de falha, a equipa de primeiro nível da

Central de Serviços precisa registar, categorizar, priorizar e tentar encontrar uma resposta/solução

para a solicitação, ou então, redirecionar o ticket para um especialista técnico (Subject Matter

Expert da sigla SME) para que o ticket de suporte seja resolvido.

Todo este processo manual feito pela equipa da central de serviços, além do alto consumo de

tempo, pode ocasionar problemas caso ocorra alguma falha ao categorizar e/ou priorizar o ticket

de suporte.

1.3 Objetivo e metodologia

O objetivo deste trabalho é demonstrar através da utilização de técnicas de Aprendizagem de

Máquina (Machine Learning) e Processamento de Linguagem Natural (Natural Language Proces-

sing da sigla NLP), um modelo preditivo de classificação de texto que forneça suporte a categori-

zação e priorização de tickets pela equipa de primeiro nível da central de serviços.

Trabalhos anteriores como [4] e [21] apresentaram resultados interessantes através da utili-

zação de tickets históricos de suporte associados ao Configuration Management Data Base ou

CMDB para associação dos tickets com itens de configuração da infraestrutura da companhia, uti-

lizando técnicas de processamento de Linguagem Natural (NLP) e aprendizagem de máquina para

construção de modelos preditivos.

Como neste trabalho o CMDB não foi utilizado para associação com Itens de Configuração

e a solicitação/falha descrita pelos usuários, uma abordagem de aprendizagem supervisionada

(descrito em 3.4) será utilizada. Para isso, a metodologia conhecida como processo entre indústrias

para mineração de dados (Cross Industry Standard Process for Data Mining) da sigla CRISP-DM(descrita em 1.3.1) foi utilizada.

1.3.1 CRISP-DM

Esta metodologia, fornece uma abordagem estruturada de tarefas a serem executadas em um

projeto de mineração de dados. Na prática, muitas destas tarefas podem ser executadas em uma

ordem diferente ou até mesmo serem executadas repetidas vezes para atingir os resultados espera-

dos.

O ciclo de vida de um projeto de mineração de dados é dividido em seis fases que são descritas

de forma resumida a seguir:

4 Introdução

1. Compreensão do negócio ou em inglês Business Understanding - Esta fase inicial concentra-

se em entender os objetivos e requisitos do projeto de uma perspetiva do negócio, para em

seguida, converter este conhecimento em uma definição de problema de mineração de dados.

2. Compreensão de dados ou em inglês Data Understanding - A fase de compreensão de dados

é iniciada com uma coleta de dados inicial e prossegue com atividades para se familiarizar

com os dados, identificar problemas de qualidade, descobrir os primeiros padrões sobre os

dados ou detetar subconjuntos interessantes de hipóteses.

3. Preparação de dados ou do inglês Data Preparation - A preparação de dados, provavel-

mente, será realizada várias vezes durante o processo, e não precisamente em uma ordem

prescrita. As tarefas desta fase incluem a normalização dos dados, seleção de atributos

(features), limpeza de dados, construção de novos atributos e transformação de dados.

4. Modelagem ou do Inglês Modeling - Nesta fase, várias técnicas de modelagem são seleci-

onadas e aplicadas, e os seus parâmetros são ajustados para os melhores resultados. Nor-

malmente, existem várias técnicas para o mesmo tipo de problema de mineração de dados.

Algumas técnicas exigem formatos de dados específicos.

5. Avaliação ou do inglês Evaluation - Antes de prosseguir para a implantação final do modelo,

é importante avaliar mais detalhadamente o modelo e revisar as etapas executadas, para

garantir que os objetivos do negócio sejam cumpridos. No final desta fase, uma decisão

sobre o uso dos resultados de mineração de dados deve ser obtida.

6. Implantação ou do inglês Deployment - Dependendo dos requisitos, a fase de implantação

pode ser tão simples quanto gerar um relatório ou tão complexa quanto implementar um

processo de mineração de dados repetitivo hospedado em um serviço da web, por exem-

plo. Em muitos casos, será o usuário, não o analista de dados, quem executará a etapa de

implantação. Neste trabalho, esta fase não será abordada.

1.4 Estrutura do documento

Deste ponto em diante, o documento foi estruturado em 6 capítulos principais:

• Capítulo 2. Gestão de Incidentes de TI – Neste capítulo será apresentado o processo de

gestão de Serviços de TI, o Framework ITIL e o processo de Gestão de Incidentes de TI.

• Capítulo 3. Estado da arte – Neste capítulo será introduzido o conceito de aprendizagem de

máquina, os principais algoritmos de classificação supervisionado, as técnicas de classifica-

ção de texto, extração de atributos (features) e como são feitas as avaliações dos resultados.

• Capitulo 4. Compreensão e Preparação dos dados - Neste capítulo serão abordados tópicos

sobre o conjunto de dados (dataset utilizado neste trabalho bom como as tarefas realizadas

para normalização dos dados e extração de atributos.

1.4 Estrutura do documento 5

• Capitulo 5. Modelação e Avaliação - Neste capítulo serão mostrados as técnicas de mode-

lagem para cada previsão de campo para o processo de Classificação de tickets, bem como

o ajuste dos parâmetros para atingir os melhores resultados.

• Capitulo 6. Conclusões e trabalhos Futuros - No último capítulo serão apresentadas as

conclusões sobre o trabalho realizado e quais futuros trabalhos não abordados ou abordados

de forma parcial neste trabalho, podem contribuir com este tema.[20]

6 Introdução

Capítulo 2

O Processo de Gestão de Incidentes deTI

A gestão de Serviços de TI do inglês Information Technology Service Management (ITSM),

tem como objetivo prover um serviço de TI com qualidade e alinhado às necessidades do negócio,

buscando redução dos custos operacionais a longo prazo.[19]

Neste capítulo, uma abordagem introdutória ao framework Information Technology Infraes-

truture Library ITIL, um dos mais utilizados no mundo para ITSM, será feita.

Uma demonstração do fluxo de trabalho do primeiro nível da Central de Serviços, que clas-

sifica e faz o atendimento inicial de solicitações e falhas reportados pelos usuários, também será

abordada neste capítulo.

2.1 O Framework ITIL para gestão de Serviços de TI

Por possuir um conjunto de práticas que proporciona uma estrutura de entrega e gestão dos

mais diversos serviços de TI, o Information Technology Infraestruture Library (ITIL) é atualmente

o framework de ITSM mais aceito no mundo.

Desenvolvido no final dos anos 80 pela CCTA (Central Computer Telecommunications Agency),

é atualmente promovido pelo office for Government Commerce (OGC), um órgão público do Reino

Unido.

Antes da criação do ITIL, a falta de disciplina e perícia na gestão de serviços levaram a que

muitos projetos de TI não cumprissem o orçamento, desviassem do seu curso ou falhassem devido

a erros de escopo, má gestão e resultados abaixo do esperado.[17] [18]

Actualmente, para se adequar as novas tecnologias e metodologias de TI, o framework ITIL

está em processo transitório para a versão 4, lançada em fevereiro de 2019 e que irá substituir de

forma gradual a versão 3 originalmente publicada no ano de 2007 e atualizada no ano de 2011.

Neste trabalho, porém, serão abordados os conceitos e processos utilizados na versão 3 do

framework ITIL, uma vez que, todos os dados utilizados neste trabalho, foram coletados de com-

panhias que utilizavam esta versão da framework nas suas operações.

7

8 O Processo de Gestão de Incidentes de TI

2.2 Os ciclos de vida e processos ITIL

Na versão 3 do ITIL, foram publicados uma série de 5 livros com 26 processos e 4 funções.

Cada volume desta biblioteca cobre uma fase do ciclo de vida de ITSM, apoiando-se na ISO/IEC

20000.[17] [18]

A figura 2.1 ilustra a relação entre os ciclos de vida de ITSM segundo o framework ITIL, e

abaixo, são descritos de forma resumida, todos os processos ITIL que compõe cada ciclo.

• Estratégia de serviços - Os princípios de estratégia de serviço abordam processos de negócio,

governança corporativa e conformidade, políticas, cultura corporativa, e tomada de decisão

para garantir que a empresa esteja focada constantemente na evolução dos serviços.

• Desenho de Serviços - Esta fase inclui a avaliação dos processos de gestão do negócio (nível

de serviço, disponibilidade, capacidade, etc.) para desenhar e desenvolver novos serviços

ou melhorar serviços já oferecidos.

• Transição de Serviços - Esta fase cobre a transição do desenvolvimento para as operações,

incluindo testes e controlo de qualidade.

• Operação de Serviços - A fase mais importante para este trabalho, pois, aborda o processo

de gestão de Incidentes e a função de Central de Serviços, que são focos centrais deste

trabalho, aborda também os processos de cumprimento de requisições, gestão de acessos,

gestão de eventos e gestão de problemas, além das funções de gestão técnica, gestão de

operações e aplicação.

• Melhoria contínua de Serviços - Esta fase define novos requisitos para as fases anteriores

do ITIL baseados no feedback das operações e níveis de serviço ajudando a garantir que as

políticas e procedimentos serão seguidos e que o nível de serviço acordado será cumprido.

2.3 Central de Serviços 9

Figura 2.1: O ciclo de vida dos processos ITIL

2.3 Central de Serviços

O processo de gestão de Incidentes de TI faz parte do ciclo de vida de operações de serviço

e tem como objetivo garantir o restabelecimento dos serviços de TI quando uma interrupção não

programada ocorre por motivo de uma falha.

A razão de existir a função de Central de Serviços é que este departamento deve ser o único

ponto de contacto, ou single point of contact (SPOC), entre usuários e a equipa de TI, centralizando

demandas para qualquer assunto relacionado aos serviços de tecnologia da companhia.

Ao atender a uma demanda do usuário, o primeiro nível da central de serviços segue algumas

atividades definidas pelo processo de Gestão de Incidentes da ITIL, com o objetivo de restabele-

cer a correta operação dos serviços afetados.

A figura 2.2 ilustra o ciclo de vida de uma demanda recebida pela central de serviços e os

papeis desempenhados neste processo.

1. Registar o evento através de um ticket de incidente ou solicitação de serviço, coletando o

máximo de informações que ajude a classificar a demanda.

2. Categorizar o evento através da taxonomia TSCI – Tipo, Serviço, Categoria e Item.

3. Priorizar o evento de acordo com o impacto definido no acordo de nível de serviço ou do

inglês Service Level Agreement (SLA) e a urgência de acordo com o impacto causado pela

falha.

4. Analisar, diagnosticar e solucionar a demanda com o objetivo de restabelecer o serviço.

Nesta tarefa, a central de serviço segue os procedimentos listados abaixo:


(a) Tentar localizar uma solução ou procedimento conhecido na base de dados de conhe-

cimento para restabelecer o serviço ou atender a solicitação.

(b) Caso não encontre uma solução para o incidente ou não exista um procedimento para

atender a solicitação, deve redirecionar o ticket para fila do SME mais indicado.

(c) O SME deve efetuar o diagnóstico avançado e prover uma solução de contorno ou

definitiva, envolvendo, se necessário, fornecedores ou atender a demanda.

5. A equipa de primeiro nível da central de serviços deve validar a solução proposta junto ao

usuário e, caso atenda as necessidades, encerrar o incidente. Nesta etapa, o primeiro nível

da central de serviços também deve efetuar os procedimentos necessários para o fecho do

ticket e inserir uma nova entrada na base de dados de conhecimento para futuras referências.

Figura 2.2: Ciclo de vida de um ticket de suporte

Segundo o relatório [1], 41% dos tickets de suporte, ou seja, incidentes e solicitações de

serviços, não são resolvidos em primeiro nível e precisam ser encaminhados para atendimento do

SME.

2.4 Classificação de Incidentes 11

2.4 Classificação de Incidentes

No processo de gestão de incidentes, a tarefa de classificação de um ticket de suporte é a ação

de identificar o exato tipo de falha e quais os respetivos componentes envolvidos.

Faz parte também da tarefa de classificação, determinar a prioridade do incidente e a urgên-

cia da demanda. Ou seja, determinar a criticidade do incidente de acordo com o impacto que a

indisponibilidade daquele serviço representa para a companhia.

2.4.1 Categorização

A categorização do incidente, em regra, ocorre no primeiro nível da Central de Serviço, a partir

do entendimento do analista e das informações transmitidas pelo usuário que reportou o incidente.

A correta categorização de um incidente é fundamental para solucionar ou escalonar o ticket para

que o SME apropriado resolva a questão reportada.

Atualmente, é comum que ferramentas de gestão de tickets em ITSM utilizem o modelo de

taxonomia TCSI - Tipo, Categoria, Serviço, Item ou Subcategoria substituindo o modelo de taxo-

nomia TCI – Tipo, Categoria, Item.

A substituição do modelo TCI para o modelo TCSI foi discutido nos artigos [10] e [14] que

sugeriram a adição do campo Serviço para categorização de incidentes, utilizando informações

oriundas do catálogo de serviço. Deste modo, o registo de um ticket de incidente seria baseado no

negócio ao invés de tecnologia e indicaria com clareza os serviços afetados.

Abaixo, a tabela 2.1 mostra o exemplo de notificação de indisponibilidade de uma rede wi-

reless através de uma mensagem de texto (e-mail, SMS, mensagem, etc.). As tabelas 2.2 e 2.3

mostram, respetivamente, a categorização deste incidente através das taxonomias TCI e TCSI.

TICKET - DESCRIÇÃOOlá! Não é possível aceder a rede wireless corporativa. A mesma tem o status de indisponível

Tabela 2.1: Exemplo de notificação de falha a equipa da central de serviços através de texto

TIPO CATEGORIA ITEM (Subcategoria)Falha Rede Hardware

Tabela 2.2: Categorização de incidente com modelo TCI baseado em tecnologia

TIPO CATEGORIA SERVIÇO ITEM (Subcategoria)Falha Rede Rede Wireless corporativa Hardware

Tabela 2.3: Categorização de incidente com modelo TCSI baseado em serviço


Com o modelo TCSI, o primeiro nível da central de serviços pode categorizar o incidente ou a

requisição de serviço com base na descrição do usuário, sem a necessidade de um conhecimento

profundo da arquitetura dos sistemas e serviços da companhia. As informações técnicas, quando

necessárias, podem ser consultadas na base de dados de gestão de Configuração (Configuration

Management DataBase CMDB) e no catálogo de serviços.

2.4.2 Priorização

A definição de prioridade no processo de gestão de Incidentes, é identificar a importância

relativa de um incidente ou solicitação de serviços. A prioridade é definida utilizando as métricas

de impacto e urgência, identificando os tempos necessários para que as ações sejam tomadas.

Urgência é uma métrica de avaliação da rapidez com a qual é necessário resolver um incidente,

enquanto o impacto se refere ao efeito provável que o incidente terá sobre o negócio.

A figura 2.3 mostra as prioridades a partir da relação Impacto X Urgência, sendo o menor

valor (1) a maior prioridade e o maior valor (6) a menor prioridade de atendimento.

Figura 2.3: Definição de prioridade de um incidente: IMPACTO X URGÊNCIA

Capítulo 3

Estado da Arte

Conforme abordado nos capítulos anteriores, o problema a ser discutido neste trabalho aborda

a automatização de parte das tarefas desempenhadas pela equipa de primeiro nível da central de

serviços quanto a classificação de demandas vindas dos usuários de serviços de TI.

Neste capitulo, serão abordadas técnicas existentes nos dias de hoje para implementar a auto-

mação das tarefas de classificação de tickets de suporte com técnicas de classificação de texto e

treinamento de modelos preditivos através da aprendizagem supervisionada de máquina.

3.1 Aprendizagem de máquina

As tarefas de aprendizagem de máquina são divididas basicamente em duas categorias: apren-dizagem supervisionada e aprendizagem não supervisionada. Neste trabalho, será utilizada a

aprendizagem supervisionada de máquina para lidar com os problemas de classificação dos tic-

kets de suporte. Porém, nos tópicos abaixo, ambos os conceitos serão explicados em um contexto

geral.

3.1.1 Aprendizagem supervisionada

Na aprendizagem supervisionada, um modelo é treinado para descrever uma relação entre um

conjunto de variáveis independentes (causa) e variáveis dependentes (consequência). O conjunto

de amostras utilizado para criação de um modelo é conhecido como conjunto de treinamento.

Cada amostra em um conjunto de treinamento D consiste em um conjunto de variáveis inde-

pendentes de entrada x = {x1, ...,xn} e uma variável dependente de saída y.

O objetivo da aprendizagem supervisionada é ajustar uma função f ao conjunto de treinamento

D, de modo que ela descreva a relação y= f (x) com a maior precisão possível para todo o conjunto

de treinamento.[6]

Os problemas de aprendizagem supervisionada podem ser agrupados em problemas de classi-ficação e regressão, onde:

13

14 Estado da Arte

• Classificação: Um problema de classificação é definido quando uma variável de saída y é

uma categoria, como, por exemplo “solicitação” ou “falha”.

• Regressão: Um problema de regressão é quando a variável de saída y é um valor real

quantitativo como valores monetários ou tempo.

Alguns dos algoritmos mais utilizados para lidar com aprendizagem supervisionada são:

• Naive Bayes abordado na secção 3.4.1

• Support Vector Machine (SVM) abordado na secção 3.4.2

• Decision Tree abordado na secção3.4.3

• Random Forest abordado na secção 3.4.3

• Regressão Linear abordado na secção 3.4.4

3.1.2 Aprendizagem não supervisionada

O objetivo da aprendizagem não supervisionada de máquina é modelar a estrutura ou distri-

buição de dados não etiquetados, fazendo isto, de forma automática. Daí, a nomenclatura “não

supervisionada”.[5]

Problemas de aprendizagem não supervisionados podem ser agrupados em clustering e asso-ciação, onde:

• Clustering: Identifica pontos comuns nos dados que não foram rotulados, classificados ou

categorizados e os agrupa. Por exemplo, agrupar um grupo de pessoas baseado no seu

comportamento de consumo.

• Associação: Em associação, encontram-se regras que descrevam grande parte dos seus da-

dos, como as pessoas que compram X também tendem a comprar Y .

Alguns algoritmos mais usados para lidar com aprendizagem não supervisionadas, são:

• k-means - Para problemas de cluster.

• Algoritmo apriori - Para problemas de aprendizagem de regras de associação.

Por tratar de um problema de classificação, este trabalho abordará a implementação e técnicas

somente de aprendizagem supervisionada de máquina.

3.2 Classificação de texto 15

3.2 Classificação de texto

A classificação de texto descreve uma classe geral de problemas, como, por exemplo, decidir

qual o tópico de um artigo de notícias a partir de uma lista fixa de tópicos, como "desportos",

"tecnologia"ou "política". Outro exemplo, seria a classificação de uma mensagem de e-mail como

spam ou não.

O objetivo da classificação de texto é definir um rótulo de classe para uma determinada entrada.

Existem diversas variantes de classificação de texto, como por exemplo a classificação de várias

classes onde cada instância pode receber vários rótulos ou a classificação de sequência que recebe

uma lista de entradas para classificação de um conjunto. [7]

Neste trabalho, a classificação supervisionada de texto é apresentada mais profundamente em

3.2.1.

3.2.1 Classificação supervisionada de texto

A classificação supervisionada de texto é construída através de um extrator de features que

converte cada valor de entrada em um conjunto de atributos (features). Um classificador é chamado

supervisionado se for construído com base no corpus linguístico ou corpora que contém o rótulo

correto para cada entrada (palavra).[7]

Este processo é feito para ambas entradas de texto, no conjunto de dados de treinamento (a),

para treinar o modelo de classificação e para o conjunto de dados de previsão ou testes (b), que

avalia o modelo gerado em (a).

A figura 3.1 ilustra o processo de aprendizagem de máquina e extração de features a partir da

entrada de um conjunto de dados de texto.

Figura 3.1: Fluxo de trabalho do processo de extração de features, classificação e validação domodelo

16 Estado da Arte

Neste trabalho, a extração de features foi feita através da biblioteca Natural Language Tool Kit

ou NLTK, uma das principais plataformas para o desenvolvimento de programas em linguagem

Python para lidar com dados de linguagem natural como textos.

3.3 Extração de features

O processo de extração de features pode ser um fator determinante na qualidade do processo

de aprendizado de um modelo preditivo. Existem diversas técnicas para extração de features a

partir de textos, porém, neste trabalho, serão apresentadas somente as duas técnicas utilizadas a

partir do texto de descrição da solicitação/incidente.

3.3.1 Part-of-speech tagging

Nos artigos [4] e [21] os autores atingiram bons resultados em um modelo de classificação de

tickets de incidentes utilizando um processo de extração de features a partir de textos denominado

part-of-speech Tagging. Nesta técnica, o processo de extração de features rotula cada palavra do

texto de entrada com sua devida classe gramatical (part-of-speech em inglês) para que somente as

palavras de um grupo gramatical específico fossem extraídas.

Por exemplo, nos artigos citados anteriormente, os autores extraíram somente palavras das

classes gramaticais substantivo (noun em inglês), substantivo próprio (proper noun em inglês)

e frases nominais (noun phrases em inglês) como features para relacionar com o CMDB e iden-

tificar o Item de Configuração do qual se trata a solicitação.

As tabelas 3.1 e 3.2 mostram um exemplo de como as palavras são transformadas em toc-

kens, etiquetadas devidamente com suas respetivas classes gramaticais (part-of-speech em inglês)

e filtradas.

TEXTO DE ENTRADAThe FS /root has no free space on sigarra.up.pt serverDT NNP NNP VVZ DT JJ NN IN NNP NN

Tabela 3.1: Texto de entrada para extração de features em part-of-speech

Legenda: DT = Determiner, NN = Noun, NNP = Proper Noun, VVZ = Verb, JJ = Adjective, IN =Preposition

http://www.nltk.org

3.4 Algoritmos de aprendizagem de máquina supervisionada 17

FEATURES DE SAIDAFS /root space sigarra.up.pt server

NNP NNP NN NNP NN

Tabela 3.2: Saída de seleção de features: nouns NN e proper nouns NNP

Legenda: DT = Determiner, NN = Noun, NNP = Proper Noun, VVZ = Verb, JJ = Adjective, IN =Preposition

3.3.2 Stemização

Stemização (stemming) é a prática de reduzir palavras que, por razões gramaticais da língua

inglesa, foram estendidas.[9]

O processo mais simples de stemização é através da utilização de uma tabela de consulta que

contenha todas as variações de uma mesma palavra tronco (stem).

Por exemplo, para as palavras em inglês “fishing”, “fished”, “fisher” todas seriam reduzidas

para a sua versão tronco fish.

Outra forma de stemização é através da remoção de sufixos da língua inglesa como “ed”,

“ing” e “ly”.

Alguns exemplos da contração por remoção de sufixos, são:

• A palavra Stemming fica Stem

• A palavra Processed fica Process

• A palavra Slowly fica Slow

A utilização de stemização no processo de extração de features de texto pode ser útil tanto

para reduzir o vocabulário quanto para se concentrar no sentido de uma sentença.

3.4 Algoritmos de aprendizagem de máquina supervisionada

Como discutido em 3.1, para encontrar uma função f de modo que ela descreva a relação

f (x) = y, onde x é um conjunto de variáveis independentes e y uma variável dependente de saída,

é necessário utilizar um algoritmo de aprendizagem para treinamento de um modelo preditivo.

Os métodos de aprendizagem utilizam um conjunto de treinamento D, contendo um conjunto

de features e rótulos para definição do modelo preditivo.

Neste trabalho, as features x serão extraídas através de técnicas explicadas em 3.3 a partir

da descrição dos tickets de incidentes e seus respetivos rótulos y necessários para categorização

conforme o modelo TCSI explicado em 2.4.1 – Tipo, Categoria, Serviço e Item - sendo necessário

o treinamento de modelos individuais para cada rotulo.

Os tópicos a seguir apresentam os principais algoritmos de aprendizagem supervisionada de

máquina utilizados neste trabalho para o treinamento do modelo preditivo.

18 Estado da Arte

3.4.1 Naive Bayes

Naive Bayes é um dos algoritmos de aprendizagem indutiva mais eficientes e eficazes para

aprendizagem de máquina e mineração de dados.[15]

Os classificadores Naive Bayes baseiam-se no teorema de Bayes, que afirma que a relação entre

uma classe y e um vetor de entrada x com componentes x1, ...,xn é definido matematicamente por:

P(y|x) = P(y)P(x|y)p(x)

Onde:

• P(y|x) é a probabilidade de que o vetor de entrada x pertença à classe de saída y.

• P(y) é a probabilidade a priori de y

• P(x|y) é a probabilidade de x na classe y,

• P(x) a probabilidade global de entrada x

3.4.2 Support Vector Machine (SVM)

Em Support Vector Machine (SVM), ao invés de calcular as probabilidades dos recursos que

compõem os modelos de espaço vetorial de entrada como é feito pelo algoritmo Naive Bayes, o

algoritmo SVM trata cada vetor de entrada de comprimento N como um ponto em uma dimensão

de espaço N.

No caso da classificação binária, os pontos das duas classes podem ser separados linearmente

uns dos outros por um plano de decisão. Para calcular a posição deste plano, um número de pontos

de cada classe é utilizado.

Esses pontos são chamados de vetores de suporte e o plano de decisão pode ser calculado a

partir deles na função f para prever a classe de um vetor de entrada desconhecido. Isso faz com

que o SVM seja eficiente, pois só é preciso considerar um subconjunto.[6]

3.4 Algoritmos de aprendizagem de máquina supervisionada 19

Figura 3.2: Exemplo de conjunto de dados linearmente separável utilizando SVM

3.4.3 Random Forest e Decision Tree

Os algoritmos classificadores Decision Tree e Random Forest constroem modelos que con-

sistem em um conjunto de perguntas organizadas em forma de árvores que levam a uma resposta.

O algoritmo Random Forest adiciona ainda alguma aleatoriedade no processo de classificação.

O princípio geral dos algoritmos baseado em "árvores"consiste em dividir aleatoriamente o

conjunto de treinamento em subconjuntos menores, onde cada novo conjunto é usado para treinar

uma pequena árvore de decisão separada. A resposta média dessas classificações é selecionada

como a classe de saída.[2]

A imagem 3.3 demonstra graficamente o processo de eleição de uma classe após o treinamento

de 4 sub conjuntos de dados extraídos do conjunto principal.

Figura 3.3: Exemplo de classificação com algoritmo Random Forest

20 Estado da Arte

3.4.4 Regressão Linear

O algoritmo de Regressão Linear é uma função linear que descreve a relação estatística entre

as variáveis de entrada (features) e a variável de saída y. [11]

A regressão linear tenta encontrar a linha que melhor representa as variáveis de entrada (causa)

com a variável de saída (efeito).

A figura 3.4 demonstra graficamente o algoritmo de regressão linear.

Figura 3.4: A função linear de relação entre as variáveis de entrada x e a consequência y

3.5 Avaliação dos algoritmos de classificação e seleção de modelo

Para decidir se um modelo de classificação atende as expectativas de previsão, é necessário

avaliar, através de métricas, o desempenho deste modelo. O resultado da avaliação é importante

para decidir o quão confiável o modelo é.

Em aprendizagem supervisionada de máquina, para o processo de avaliação do modelo, é

necessário dividir o conjunto de dados em duas partes. 1) treinamento e 2) teste/validação.

1. O conjunto de dados de treinamento é utilizado para treinar o algoritmo de classificação.

Geralmente, neste processo é utilizado uma proporção de dados maior que o utilizado pelo

conjunto de dados de testes. Neste trabalho por exemplo, a proporção utilizada entre teste e

treinamento foi de 70% e 30% respetivamente.

2. O conjunto de dados de teste, é utilizado para validar a qualidade do modelo treinado através

do conjunto de dados de treinamento. Esta validação é feita comparando os resultados

gerados pelo modelo de classificação com os dados reais.

3.5 Avaliação dos algoritmos de classificação e seleção de modelo 21

Desta forma, com o resultado gerado no processo de teste, pode-se atribuir a linha de even-

tos previstos como POSITIVO (falsos e verdadeiros) e uma linha de não eventos NEGATIVOS(falsos e verdadeiros), explicado detalhadamente a seguir:

• “Verdadeiro positivo” (VP) - Para valores de eventos previstos de forma correta.

• "Falso positivo"(FP) - Para valores de eventos previstos de forma incorreta.

• “Verdadeiro negativo” (VN) - Para valores não previstos de forma correta.

• "Falso negativo"(FN) - Para valores não previstos de forma incorreta.

3.5.1 Métricas de avaliação do modelo classificador

Para medir a eficiência do modelo de classificação, é necessário o uso de métricas que de-

monstre a qualidade da previsão e também auxilie no processo iterativo de treinamento e melhoria

constante do modelo.

A seguir, serão exibidas as principais métricas de avaliação de desempenho dos classificadores.

• Accuracy - Mede a percentagem de entradas no conjunto de testes que o classificador rotulou

corretamente. Por exemplo, se o classificar prever corretamente 85 rótulos de 100, sua

precisão será de 0.85 ou 85% de acerto. É representado pela seguinte equação:

Accuracy =V P+V NTOTAL

• Precision - É a razão entre a quantidade de instâncias que foram corretamente previstas e a

quantidade total de instâncias que foram previstas. É representada pela equação:

Precision =V P

V P+FP

ou também:

Precision =V P

RESULTADOREAL

• Recall – É a razão entre a quantidade de instâncias que foram corretamente previstas e a

quantidade total de instâncias que deveriam pertencer a uma classe. É Representada pela

equação:

22 Estado da Arte

Recall =V P

V P+FN

ou também:

Recall =V P

RESULTADOPREV ISTO

• F1-score – É a média harmónica para as métricas de Precision e Recall (ambos possuem o

mesmo peso). É representada pela equação:

F1 = 2precision∗ recallprecision+ recall

Na figura 3.5 é mostrado um exemplo de relatório consolidado de avaliação de um modelo

classificador, contendo as métricas por classe de precision, recall, f1-score e a métrica global de

accuracy.

Figura 3.5: Exemplo de relatório consolidado de avaliação do modelo classificador

• Matriz de confusão - Uma matriz de confusão é um resumo dos resultados da previsão

para cada classe em um problema de classificação. Os valores na diagonal principal da

matriz, representam o número de pontos para os quais o rótulo previsto foi igual ao rótulo

real, enquanto os elementos fora dessa orientação, foram rotulados de forma incorreta pelo

classificador.

3.5 Avaliação dos algoritmos de classificação e seleção de modelo 23

Figura 3.6: Exemplo de matriz de confusão comparando os resultados previstos com os valoresreais

3.5.2 Aplicações técnicas para classificação de tickets de suporte

Algumas técnicas supervisionadas e não supervisionadas de aprendizagem de máquina e clas-

sificação de textos, foram propostas para classificação automática de tickets de suporte com o

objetivo de reduzir o esforço das equipas de primeiro nível da central de serviços no processo de

classificação manual dos tickets.

Nos artigos [10] e [14], através do uso de técnicas de aprendizagem supervisionada e extração

de features a partir de diferentes fontes de dados, como, por exemplo o CMDB (dados estrutura-

dos) e a descrição dos ticktes (dados não estruturados), resultados preditivos acima de 90% para

deteção de Itens de Configuração responsáveis por falhas em sistemas de TI, foram alcançados.

Outra abordagem utilizada em [8], descreve a utilização de aprendizagem não supervisionada

através de clustering hierárquico como solução para a tarefa de classificação de tickets com um

esforço mínimo. Esta abordagem, porém, é descrita por seus autores como muito boa para classi-

ficação de classes que não tenham um número muito grande de amostras.

Neste trabalho, uma abordagem de classificação Hierárquica para aprendizagem supervisio-

nada foi utilizada como tentativa em melhorar os modelos preditivos gerados, onde se observou,

resultados piores para classes com menos amostras no conjunto de treinamento.

24 Estado da Arte

Capítulo 4

Compreensão e Preparação de Dados

A classificação através da aprendizagem supervisionada requer um conjunto de dados com

número suficiente de amostras para treinar e validar uma função de classificação. Geralmente, um

conjunto de treinamento maior é a melhor maneira de aumentar o desempenho futuro da classifi-

cação. Neste capítulo, serão descritos com maiores detalhes em 4.1 o conjunto de dados utilizado

neste trabalho além das tarefas de compreensão e preparação dos dados para o treinamento do

modelo preditivo.

4.1 Conjunto de dados

O conjunto de dados utilizado foi extraído de um repositório de dados para treinamento de

modelos de Machine Learning e possuí aproximadamente 50 mil registos de tickets de suporte já

classificados com a descrição dos usuários em inglês.

Todos os registos foram previamente anonimados retirando toda a informação que era sensível

para a empresa. Isso inclui, por exemplo, a substituição do nome real de cada classe por números

apenas.

Este conjunto possuí 9 colunas denominadas respetivamente: ’title’, ’body’, ’ticket_type’, ’ca-

tegory’, ’sub_category1’, ’sub_category2’, ’business_service’, ’urgency’ e ’impact’

Deste momento em diante, algumas categorias serão traduzidas para o português e ficam com

as seguintes nomenclaturas: ’body’, ’Ticket_type’, ’Categoria’, ’Item’, ’Business_Service’, ’Ur-

gência’ e ’Impacto’.

A coluna Body possuí a descrição enviada pelos usuários sobre a perspetiva da falha ou soli-

citação feita a equipa de primeiro nível da central de serviços. Esta categoria será utilizada para

extração de atributos (features) que serão utilizadas como entrada para o treinamento dos modelos

classificadores.

A coluna sub_category2, por ser uma particularidade da companhia, foi eliminada e não será

utilizado neste trabalho.

25

26 Compreensão e Preparação de Dados

4.2 Pré processamento

Como dito anteriormente, parte das atividades de pré-processamento foram realizadas antes

de disponibilizar o conjunto de dados no repositório público.

Algumas atividades, como filtrar caracteres especiais (!,#,$,&,*,/,etc) e remoção dos dados

sensíveis da companhia, já haviam sido realizados. Mas ao analisar mais detalhadamente o con-

junto de dados, foi percebido que existia ainda algum trabalho a ser feito.

4.2.1 Filtro de amostras indevidas

Alguns registos continham informações vazias (Null) ou linhas em branco que podem afetar a

qualidade do modelo final e precisavam ser filtrados.

A biblioteca Pandas, para linguagem Python, foi utilizada para as tarefas de coleta e preparação

de dados, lidando, por exemplo, com esta tarefa.

A figura 4.1 demonstra um exemplo de forma didática para o tratamento de registos nulos

(linha 1) e em branco (linha 2) da coluna ’body’ com a biblioteca Pandas.

Figura 4.1: Exemplo de tratamento de registos com a biblioteca Pandas

4.3 Distribuição de classes

Ao analisar o conjunto de dados de forma mais detalhada, um grande desbalanceamento de

classes, ou seja, conjuntos de dados cujo instâncias são distribuídas desigualmente sobre as classes

https://pandas.pydata.org/

4.3 Distribuição de classes 27

4.4, pôde ser observado para alguns campos como Categoria, Business Service e Item. Em alguns

casos, 90% das amostras estão concentradas em apenas uma ou duas classes.

As figuras 4.2, 4.3, 4.4. 4.5, 4.6 e 4.7 mostram a distribuição de classe para os campos Tic-

ketType, Categoria, BusinessService, Item, Impacto e Urgência respetivamente. Para melhorar a

visualização dos gráficos, em alguns casos, foi necessária a remoção da quantidade, em percenta-

gem, das classes.

Figura 4.2: Distribuição de classes: Ticket Type

Figura 4.3: Distribuição de classes: Categoria


Figura 4.4: Distribuição de classes: Business Service

Figura 4.5: Distribuição de classes: Item ou Sub_categoria

4.3 Distribuição de classes 29

Figura 4.6: Distribuição de classes: Impacto

Figura 4.7: Distribuição de classes: Urgência


4.3.1 Remoção de classes

Algoritmos de classificação precisam de uma quantidade mínima de amostras para treinamento

de um modelo preditivo. Como mostrado anteriormente em 4.3, algumas classes no conjunto de

treinamento utilizado neste trabalho, possuem uma quantidade insuficiente de amostras, mesmo

para se utilizar as técnicas de redimensionamento de amostras. Por este motivo, algumas classes

precisaram ser eliminadas.

A figura 4.8 mostra a implementação deste filtro para o campo categoria, onde foi necessária

a remoção das classes 0, 2 e 10 que possuíam ao todo apenas 9 amostras.

Figura 4.8: Remoção de classes campo Categoria

Além do campo categoria, este procedimento também precisou ser feito para os campos Busi-

ness Service e Item.

4.4 O problema de desequilíbrio de classes

O desequilíbrio de classes ocorre quando num problema de classificação, existe uma quanti-

dade muito maior de amostras para algumas classes do que para outras. Nestes casos, os algorit-

mos classificadores tendem a ser sobrecarregados pela grande quantidade de instâncias das classes

maioritárias e ignorar as classes minoritárias.[3]

A maioria dos algoritmos de aprendizado de máquina funcionam melhor quando o número

de amostras em cada classe são aproximados. Isso ocorre, porque, a maioria dos algoritmos de

classificação são projetados para maximizar a precisão e reduzir erros.

Existem diversas técnicas para lidar com o desbalanceamento de amostras em classes, mas

mesmo aplicando estas técnicas, ainda é necessário um número mínimo de amostras para o pro-

cesso de treinamento por isso, algumas classes precisaram ser eliminadas.

Neste trabalho, foram aplicadas duas técnicas conhecidas para lidar com o problema de des-

balanceamento de classes, mostradas a seguir.

4.4.1 Oversampling

Oversampling pode ser definido como uma técnica em que são adicionados mais cópias de

amostras à classes minoritárias.

Para aplicar esta técnica, a biblioteca imbalanced-learn para linguagem Python disponibiliza

diversos métodos para aplicar o Oversampling, tais como:

https://imbalanced-learn.readthedocs.io/en/stable/index.html

4.4 O problema de desequilíbrio de classes 31

• ADASYN

• Random Oversampling

• SMOTE

• SMOTE-NC

4.4.2 Undersampling

Ao contrário do Oversampling o Undersampling remove algumas observações das classes

maioritárias para balancear com as classes minoritárias.

A desvantagem em utilizar esta técnica é justamente ter de remover informações que podem

ser importantes para o processo de aprendizado. Isto pode reduzir significativamente o conjunto

de dados utilizado para testes e reduzir a qualidade do modelo preditivo.

A biblioteca imbalanced-learn para linguagem Python também disponibiliza diversos métodos

para aplicar o Undersampling:

• Condensed Nearest Neighbour

• Edited Nearest Neighbours

• Repeated Edited Nearest Neighbour

• All KNN

• Instance Hardness Threshold

• Near Miss

• Neighbourhood Cleaning Rule

• One Sided Selection

• Random Under Sample

• TomekLinks

4.4.3 Técnicas aplicadas

Em alguns casos, a utilização de técnicas de Oversampling e Undersampling foram testadas

no conjunto de treinamento para o treinamento de um modelo preditivo.

As imagens 4.9 e 4.10 mostram respetivamente a distribuição de amostras por classes do

campo Categoria após a utilização de Oversampling e Undersampling respetivamente. A ima-

gem 4.11 mostra a distribuição original sem a aplicação de técnicas de redistribuição.

Os resultados finais de classificação utilizando as técnicas de redimensionamento de amostras

por classes, são apresentados em 5.4.9

https://imbalanced-learn.readthedocs.io/en/stable/index.html


Figura 4.9: Distribuição de amostras por classes de Categoria após a utilização de técnica deOversampling

Figura 4.10: Distribuição de amostras por classes de Categoria após a utilização de técnica deUndersampling

4.4 O problema de desequilíbrio de classes 33

Figura 4.11: Distribuição original de amostras por classes de Categoria

Capítulo 5

Modelação e Avaliação

Para treinar os modelos de classificação, a biblioteca SciKit-Learn para linguagem Pythonfoi utilizada. Esta biblioteca possuí um conjunto de algoritmos e ferramentas que maximizam

todo o processo de modelação e classificação em aprendizado de máquina (supervisionada e não

supervisionada). [12]

Para este trabalho, três algoritmos diferentes de classificação supervisionada foram utilizados:

Naive Bayes (descrito em 3.4.1), Support Vector Machine SVM (descrito em 3.4.2) e RandomForest (descrito em 3.4.3).

Alguns modelos gerados por estes algoritmos tiveram resultados semelhantes uns aos outros,

mas houve casos em que os algoritmos Naive Bayes e Random Forest conseguiram atingir re-

sultados melhores, e isso, ficou ainda mais evidente ao utilizar a técnica de hiperparametrização,

descrito em 5.2.1. Por outro lado, o algoritmo SVM além de consumir mais recursos computacio-

nais e por consequência ser mais demorado, teve os piores resultados.

5.1 Pipelines

Em trabalho de aprendizagem de máquina, são necessárias várias etapas de transformação,

como codificação de variáveis, dimensionamento de recursos e normalização.

No entanto, em um fluxo típico de aprendizagem de máquina, será necessário aplicar todas

estas transformações pelo menos duas vezes. 1) ao treinar o modelo e 2) ao testar o modelo.

Os pipelines para Scikit-learn são ferramentas feitas para simplificar este processo e foram

utilizadas neste trabalho de forma a agilizar a construção dos algoritmos de classificação com seus

diferentes parâmetros.[12] [13]

A figura 5.1 mostra a implementação de scikit-learn pipelines executando os métodos neces-

sários para a construção dos classificadores utilizados neste trabalho.

35

scikit-learn.org

36 Modelação e Avaliação

Figura 5.1: Implementação de scikit-learn pipeline para algoritmos de classificação supervisio-nada

5.2 Cross validation

Em aprendizado supervisionado, é prática comum, reter parte do conjunto de dados como um

conjunto de testes para avaliar a qualidade do classificador e evitar o chamado overfitting, ou

seja, a condição onde um classificador consegue atingir um bom resultado com um conjunto de

dados, mas não é capaz de prever outros dados com o mesmo sucesso.

Neste trabalho, para dividir os dados entre um conjunto de treinamento e um conjunto de testes

de forma aleatória, a função do SciKit-Learn train_test_split foi utilizada.

O exemplo de implementação da função train_test_split para a coluna categoria é mostrado na

figura 5.2

A proporção utilizada entre dados para treinamento e dados para teste foi de 70/30 ou seja,

70% dos dados reservados para treinamento (a) e 30% para os testes (b).

Mesmo utilizando a técnica de dividir os dados em dois conjuntos (treinamento e teste), ainda

5.2 Cross validation 37

Figura 5.2: A função train_test_split do Scikit-Learn

há o risco de overfitting. Para resolver isto, outra técnica normalmente é utilizada, a divisão do

conjunto de dados em três subconjuntos: Treinamento, Validação e Teste.

Neste cenário, o treinamento prossegue utilizando o conjunto de dados de treinamento, mas

a avaliação é feita utilizando o conjunto de dados de validação e quando tudo parecer bem, a

avaliação final pode ser feita utilizando o conjunto de dados de testes. Desta forma, outro problema

pode ocorrer: o número de amostras a serem utilizadas para aprendizagem do modelo é reduzido

drasticamente.

Uma solução para este problema é o procedimento conhecido como Cross Validation (CV).

Neste cenário, um conjunto de testes ainda deve ser oferecido para avaliação final, mas o conjunto

de validação não é mais necessário.

K-fold é o método de cross validation mais conhecido e utilizado. Este método consiste em

dividir o conjunto de dados em k partes, usando k-1 partes para treino e a porção remanescente

em teste. Em cada uma das k vezes, testa-se o modelo com um fold diferente calculando a métrica

escolhida para avaliação do modelo. Ao final do processo, teremos k medidas da métrica de

avaliação escolhida.

A figura 5.3 mostra um fluxograma típico de cross validation no treinamento de modelo en-

quanto a figura 5.2 mostra o processo de validação do modelo com k-fold.

Figura 5.3: Cross Validation - Fluxograma


Figura 5.4: Cross Validation - Avaliação de modelo

5.2.1 Grid Search

Hiperparâmetros são parâmetros que não são aprendidos automaticamente dentro dos algorit-

mos de classificação. No scikit-learn eles são passados como argumentos para o construtor das

classes dos classificadores. O conceito de hiperparametrização visa encontrar um conjunto de

melhores hiperparâmetros para um algoritmo classificador.

O Grid Search é indiscutivelmente hoje, o método mais básico de ajuste de hiperparâme-

tros. Com essa técnica, é possível construir um modelo para cada combinação possível de todos

os valores de hiperparâmetro possíveis, avaliando e elegendo o modelo que atingiu os melhores

resultados.

Duas abordagens genéricas de hiperparametrização com Grid Search estão disponíveis na bi-

blioteca scikit-learn: o primeiro, é o método GridSearchCV que considera exaustivamente todas

as combinações de parâmetros, e o segundo é o RandomizedSearchCV que pode demonstrar um

determinado número de candidatos a partir de um espaço de parâmetros com uma distribuição

especificada.

Para este trabalho, o GridSearchCV foi utilizado no treinamento de todos os modelos aborda-

dos nos próximos capítulos. A figura 5.5, mostra um exemplo de implementação de hiperparame-

trização exaustiva para o classificador SVM utilizando o parâmetro C com os valores 1, 10, 100 e

1000 e o parâmetro Kernel com os valores ’linear’ e ’rbf’.

Os outros dois parâmetros cv e n_jobs utilizados na construção da classe GridSearchCV re-

presentam respetivamente o número de vezes em que o conjunto de treinamento será dividido (k) e

o uso ilimitado de todos os recursos computacionais para processamento. Se possível, a utilização

5.3 Especificações Técnicas 39

deste ultimo parâmetro é de extrema utilidade, uma vez que o processo de hiperparametrização e

CV utilizam muitos recursos computacionais.

Figura 5.5: Exemplo de implementação de hiperparametrização com Grid Search

A figura 5.6 demonstra a saída gerada com a hiperparametrização mostrada no exemplo ante-

rior.

Oito resultados foram exibidos (um para cada combinação de parâmetros), e a linha final,

mostra o conjunto de parâmetros eleito (C: 1 e kernel: ’linaer) com o melhor score: 0.57.

Figura 5.6: Avaliação e eleição de hiperparâmetros com Grid Search e CV

5.3 Especificações Técnicas

As especificações técnicas do ambiente onde os treinamentos e avaliações foram realizadas

são:

CPU: AMD A12-9720P, Quad Core, 3.60 GHz

Memoria: 16 GB DDR4

Discos: 128 GB SSD + 1 TB HDD

5.4 Avaliação dos resultados

A seguir, serão exibidos os resultados de treinamento para cada campo necessário ao processo

de classificação de tickets de suporte, feito de forma manual pela equipa de primeiro nível da

central de serviços.


As métricas utilizadas para avaliação final do modelo foram Accuracy ou previsão, F1 na ava-

liação dos resultados individuais de cada classe prevista e matriz de confusão, gerada graficamente

através da biblioteca matplotlib para linguagem Python.

No processo de extração de Features, somente a técnica de Stemming 3.3.2 foi utilizada. A

classificação de texto a partir da classe gramatical de cada palavra denominada Part-of-Speech

Tagging e descrita em 3.3.1, foi incluída no capitulo de trabalhos futuros por ter sido pouco ex-

plorada e, em abordagens iniciais, apresentar resultados inferiores em comparação com o uso

exclusivo da técnica de Stemming.

Para definir se os resultados foram satisfatórios, é necessário avaliar os resultados a partir de

suas perspetivas: Do problema de negócio e do problema de classificação.

5.4.1 Interpretação dos resultados - Negócio

A abordagem do ponto de vista do negócio tem como objetivo reduzir os esforços de classifi-

cação manual dos tickets de suporte feito pela equipa de primeiro nível da central de serviços. Ou

seja, os resultados devem ser confiáveis para que um ticket de suporte seja registado automatica-

mente com a tipificação prevista pelo modelo.

Por não existirem métricas confiáveis da percentagem de acerto de registos manuais feito pela

equipa de central de serviços para comparar com os resultados dos modelos gerados nesse trabalho,

será considerada uma taxa de acerto confiável de accuracy resultados acima de 85% ou 0.85

(inclusive).

Resultados entre 70% ou 0.70 (inclusive) e 84% ou 0.84 serão considerados como uma re-

comendação para a equipa de primeiro nível da central de serviços, sendo necessária a análise e

validação da classificação antes de registar o ticket e/ou redireciona-lo para o SME.

Resultados abaixo de 70% ou 0.70 serão considerados insuficientes para a previsão do campo.

Estes números serão utilizados apenas como referência para avaliar a qualidade do modelo

preditivo, sendo que uma companhia pode ser mais tolerante com resultados menores.

5.4.2 Interpretação dos resultados - Classificação

A abordagem do ponto de vista de classificação tem como objetivo criar um modelo preditivo

que descreva a relação entre um conjunto de variáveis independentes (causa) e variáveis depen-

dentes (consequência).

Algoritmos de aprendizagem de máquina são desenvolvidos para minimizar os erros e por

isso, os algoritmos têm uma probabilidade maior de classificar novas observações para a classe

maioritária chawla2009data.

Sabendo disso, para avaliar se um modelo foi satisfatório do ponto de vista de classificação,

será utilizada como métrica de desempenho para efeito de comparação, a classe maioritária de

cada campo.

Por exemplo, para o campo categoria a classe maioritária (4) possuí pouco mais de 70% das

amostras de todo o conjunto de dados (vide figura 4.3). Sendo assim, se o modelo rotular todas

https://matplotlib.org/

5.4 Avaliação dos resultados 41

as observações como classe 4, "acertaria"70% das previsões, e isso, seria um resultado falso de

previsão.

Por outro lado, um resultado de accuracy de 85% evidenciaria que o modelo foi capaz de

prever novas observações com certo grau de suporte.

5.4.3 Resultados: tipo de ticket

O Tipo de Ticket ou Ticket Type, é a categoria com apenas duas classes (vide figura 4.2) e

também com menos problemas de desbalanceamento de amostras entre elas. A classe maioritária

(1) possuí 71,3% do total de amostras do conjunto de dados.

O melhor resultado foi obtido com a utilização do algoritmo Naive Bayes com accuracy de

0.97 (tabela 5.1 e matriz de confusão 5.7).

Com a utilização da hiperparametrização e CV, através da técnica de Grid Search, o resultado

obtido teve uma pequena melhora com accuracy de 0.98 para todos os algoritmos (tabela 5.2 e

matriz de confusão 5.8).

Na perspetiva do negócio, este resultado seria muito bom, podendo ser utilizado para o registo

e/ou encaminhamento automático de tickets por atingir mais de 85% de accuracy.

Na perspetiva de classificação, o modelo possuí um bom grau de suporte por prever acima da

percentagem de distribuição de amostras da classe maioritária

Algoritmo Parâmetros No de amostras No de Classes AccuracyNB fit_prior=True 48.546 2 0.97

SVM n_estimators=300, random_state=5 48.546 2 0.72RF n_estimators=100, random_state=50 48.546 2 0.97

Tabela 5.1: Tipo de Ticket - Avaliação de resultados

Algoritmo Grid Search hiperparâmetros hiperparâmetros eleito AccuracyNB ngram_range: [(1,1), (1,2)],

use_idf: (True, False), alpha: (1e-2,1e-3)

ngram_range: (1,1), use_idf: False,alpha:0.001

0.98

SVM n_estimators:[100,200,300], ran-dom_state:(5, 10, 20)

n_estimators:300, random_state:20 0.98

RF n_estimators:[200,300.500], ran-dom_state:(10, 20, 50)


Tabela 5.2: Tipo de Ticket - Hiperparametrização


Figura 5.7: Matriz de confusão Ticket Type - Algoritmo Naive Bayes - accuracy: 0.97

Figura 5.8: Matriz de confusão Ticket Type - Algoritmo Naive Bayes e Grid Search - accuracy:0.98


5.4.4 Resultados: categoria

As amostras do campo Categoria têm um grande problema com o desbalanceamento de amos-

tras entre as classes (veja figura 4.3) e também com o número de amostras insuficientes em algu-

mas classes para o treinamento do modelo. Este problema foi melhor explicado em 4.3.

A classe maioritária (4) possuí 70,2% do total de amostras do conjunto de dados.

O melhor resultado foi obtido com a utilização do algoritmo Random Forest com accuracy de

0.83 (tabela 5.3 e matriz de confusão 5.9).

Utilizando a técnica de hiperparametrização com grid search e cross validation para melhoria

do modelo, o resultado alcançado foi de 0.85 de accuracy utilizando o algoritmo Naive Bayes

(tabela 5.4 e matriz de confusão 5.10).

Na perspetiva do negócio, este resultado seria muito bom, podendo ser utilizado para o registo

e/ou encaminhamento automático de tickets por atingir mais de 85% de accuracy.


percentagem de distribuição de amostras da classe maioritária.



Tabela 5.3: Categoria - Avaliação de resultados




0.85





Tabela 5.4: Categoria - Hiperparametrização


Figura 5.9: Matriz de confusão Categoria - Algoritmo Random Forest - accuracy: 0.83

Figura 5.10: Matriz de confusão Categoria - Algoritmo Naive Bayes e Grid Search - accuracy:0.85


5.4.5 Resultados: business service

As amostras do campo Business Service possuem um número elevado de classes (vide figura

4.4) e diversas destas classes precisaram ser eliminadas por não possuírem um número mínimo de

amostras para treinamento. Isto, causou diversos problemas com o treinamento dos modelos tendo

em vista, os recursos computacionais limitados utilizados neste trabalho.


Devido as restrições computacionais, neste caso, em especifico, somente o algoritmo Naive

Bayes foi utilizado para treinamento do modelo. O resultado foi de 0.48 de accuracy (tabela 5.5 e

matriz de confusão 5.11.


do modelo, o resultado alcançado foi de 0.60 de accuracy (tabela 5.6 e matriz de confusão 5.12.

Na perspetiva do negócio, este resultado seria ruim, por atingir menos de 70% de accuracy.

Na perspetiva de classificação, o modelo possuí um bom grau de suporte por prever mais queo dobro da percentagem de distribuição de amostras da classe maioritária.


SVM - 43.858 26 -RF - 43.858 26 -

Tabela 5.5: Business Services - Avaliação de resultados




0.60

SVM - - -RF - - -

Tabela 5.6: Business Service - Hiperparametrização


Figura 5.11: Matriz de confusão Business Service - Algoritmo Naive Bayes - accuracy: 0.48

Figura 5.12: Matriz de confusão Business Service - Algoritmo Naive Bayes e Grid Search - accu-racy: 0.60


5.4.6 Resultados: item ou sub-categoria

As amostras do campo Item possuem características semelhantes a de Business Service em

5.4.5. Ou seja, existe uma grande quantidade de classes e muitas delas, não possuem amostras

suficientes para o treinamento de um modelo e precisaram ser descartadas (vide figura 4.5)


O melhor resultado foi alcançado com a utilização do algoritmo Naive Bayes que obteve um

accuracy de 0.52 (tabela 5.7 e matriz de confusão 5.13).


do modelo, o resultado alcançado foi de 0.57 de accuracy através do algoritmo Naive Bayes (tabela

5.8 e matriz de confusão 5.14.

Na perspetiva do negócio, este resultado seria ruim, por atingir menos de 70% de accuracy.

Na perspetiva de classificação, o modelo possuí um bom grau de suporte por prever mais queo dobro da percentagem de distribuição de amostras da classe maioritária


SVM n_estimators=300, random_state=5 48.197 26 0.23RF n_estimators=100, random_state=50 48.197 26 -

Tabela 5.7: Item - Avaliação de resultados




0.57




n_estimators:500, random_state:20 -

Tabela 5.8: Item - Hiperparametrização


Figura 5.13: Matriz de confusão Item ou Sub-Categoria - Algoritmo Naive Bayes - accuracy: 0.52

Figura 5.14: Matriz de confusão Item ou Sub-Categoria - Algoritmo Naive Bayes e Grid Search -accuracy: 0.57


5.4.7 Resultados: impacto

O campo Impacto, assim como o campo Categoria, possuem um grande problema com o

desbalanceamento de amostras entre as classes. Duas das cinco classes possuem 98% do total de

amostras do conjunto de dados (vide figura 4.6).


O melhor resultado foi obtido através da utilização do algoritmo Random Forest que obteve

textitaccuracy de 0.97 (tabela 5.10 e matriz de confusão 5.15.


do modelo, o resultado alcançado foi de 0.97 de accuracy através do algoritmo Random Forest

(tabela 5.10 e matriz de confusão 5.16).

Na perspetiva do negócio, este resultado seria muito bom, por atingir mais de 85% de accu-

racy.





Tabela 5.9: Impacto - Avaliação de resultados




0.96





Tabela 5.10: Impacto - Hiperparametrização


Figura 5.15: Matriz de confusão Impacto - Algoritmo Random Forest - accuracy: 0.97

Figura 5.16: Matriz de confusão Impacto - Algoritmo Random Forest e Grid Search - accuracy:0.97


5.4.8 Resultados: urgência

A distribuição de amostras do campo Urgência, são muito semelhantes ao apresentado no

campo Impacto, mas com um menor volume de desbalanceamento (vide figura 4.7).


O melhor resultado foi obtido com a utilização do algoritmo Random Forest com accuracy de

0.85 (tabela 5.11 matriz de confusão 5.17).


do modelo, o resultado alcançado foi de 0.86 de accuracy através do algoritmo SVM (tabela 5.12

e matriz de confusão 5.16).

Na perspetiva do negócio, este resultado seria muito bom, por atingir mais de 85% de accu-

racy.





Tabela 5.11: Urgência - Avaliação de resultados




0.85





Tabela 5.12: Urgência - Hiperparametrização


Figura 5.17: Matriz de confusão Urgência - Algoritmo Random Forest - accuracy: 0.97

Figura 5.18: Matriz de confusão Urgência - Algoritmo Random Forest e Grid Search - accuracy:0.97


5.4.9 Resultados: técnicas de balanceamento de classes

Conforme descrito em 4.4, devido ao grande desbalanceamento de classes para alguns casos

como Business Service e Item, as técnicas de Oversampling, descrito em 4.4.1 e Undersampling,

descrito em 4.4.2 foram utilizadas como tentativa de otimizar o desempenho dos modelos. Os

resultados, como mostrado na tabela 5.13 não melhoraram os modelos de previsão que utilizaram

o conjunto de dados real..

Coluna Método Algoritmo Accuracy GS Accuracy MelhorBusiness Service OS - SMOTE NB 0.50 0.54 0.60

Categoria OS - SMOTE NB 0.51 0.71 0.85Item US - Random RF 0.31 0.31 0.57Item US - Random NB 0.32 0.31 0.57

Tabela 5.13: Resultados a partir das técnicas aplicadas para o desbalanceamento de classes

5.4.10 Resultados: classificador hierárquico

O conceito do classificador hierárquico é explorar a estrutura hierárquica das classes existentes

em um conjunto de dados[16]. Este conceito é amplamente explorado para resolver problemas de

classificação em grandes conjuntos de dados e que possuem muitas classes para previsão.[6]

A utilização da classificação hierárquica neste trabalho teve como objetivo separar as classes

do conjunto de dados de treinamento em hierarquias. Esta abordagem foi uma tentativa de otimizar

os resultados dos conjuntos de dados que tinham um grande desbalanceamento de amostras entre

classes.

Utilizando o campo categoria foi criada a estrutura hierárquica mostrada na figura 5.19 sepa-

rando as classes em três grupos maioritária 1, maioritária 2 e minoritária antes do treinamento

do modelo. Desta forma, o treinamento seria feito de forma separada para cada hierarquia.

Os resultados obtidos, inicialmente, foram satisfatórios, obtendo 0.85 de accuracy com hiper-

parametrização e cross validation.Igualando o melhor resultado para o campo categoria.

Porém, ao replicar a mesma técnica e condições para o campo de Business Scenario, um dos

campos com maior problema de desbalanceamento neste conjunto de dados, os resultados foram

abaixo do esperado, alcançando apenas o resultado de 0.16 de accuracy.


Figura 5.19: Estrutura Hierárquica para classificação do campo Categoria

Capítulo 6

Conclusões

Esta tese descreve a implementação de classificadores através da linguagem Python e da bibli-

oteca scikit-learn, e como os modelos preditivos gerados podem ser úteis ao reduzir o esforço da

equipa de primeiro nível da central de serviços quanto ao processo de classificação de tickets de

suporte.

Os classificadores foram avaliados usando vários métodos de aprendizagem diferentes para

cada campo da taxonomia TCSI necessária para classificação de um ticket de suporte. Os resulta-

dos sugerem que existe uma relação inversa entre os melhores resultados obtidos para cada campo

e o problema com a distribuição de amostras por classes (desbalanceamento de classes).

As tentativas de utilização de técnicas como Oversampling, Undersampling e classificação

hierárquica de classes nos campos mais afetados, como Business Services e Item por exemplo,

não resultaram em melhorias significativas dos modelos preditivos.

Porém, para outros campos, bons resultados foram alcançados, atingindo ótimas pontuações

como, por exemplo, a previsão do campo Ticket Type e Impacto que tiveram accuracy de 0.98 e

0.97 respetivamente.

É claro que sem mais testes, não se pode afirmar com certeza de que estes modelos possam ser

utilizados em aplicações do mundo real. Para isso, seria necessário aplicar estas mesmas técnicas

para outros conjuntos de dados, se possível com um maior número de amostras para reavaliação

dos resultados.

O resultado deste trabalho pode ser usado no futuro como solução (ou parte de uma solução)

de redução do esforço de trabalho da equipa de central de serviços e melhoria dos indicadores de

desempenho e satisfação dos usuários (KPI) dos serviços de TI.

A tabela 6.1 mostra os melhores resultados obtidos para cada campo.

55

56 Conclusões

Tipo Algoritmo Accuracy Grid Search Classificador Grid Search AccuracyTicket Type Naive Bayes 0.97 Naive Bayes 0.98Categoria Random Forest 0.83 Naive Bayes 0.85

Business Service Naive Bayes 0.48 Naive Bayes 0.60Item Naive Bayes 0.52 Naive Bayes 0.57

Impacto Random Forest 0.97 Random Forest 0.97Urgência Random Forest 0.85 Support Vector Machine 0.86

Tabela 6.1: Resultados finais

6.1 Trabalhos futuros

Algumas técnicas que deixaram de ser exploradas, ou foram explorados de forma superficial

neste trabalho, podem contribuir para a melhoria da qualidade preditiva dos modelos classificado-

res. Elas serão descritas neste tópico.

6.1.1 Extração de features com técnicas de Part-of-Speech Tagging

Em 3.3.1 é mostrado que a técnica de Part-of-Speech Tagging como recurso de extração de

features em textos pode trazer bons resultados aos modelos preditivos.

O processo que classifica as palavras com suas respetivas classes gramaticais é conhecido em

NLP como Part-of-Speech Tagging, e pode ser usado para criar, por exemplo, frases nominais ou

então nomear entidades que possam ser úteis ao processo de escolha/extração de features.

Existe um campo vasto de estudo em NLP que pode, e deve, ser utilizado no processo de

análise preditiva, mas que foram pouco abordados neste trabalho, se resumindo a utilização de

stemming, stop words e frases nominais.

Referências

[1] Roy Atkinson e Megan Selva. Techinical support practices & salary:ticket management &metrics. HDI, 2018.

[2] Leo Breiman. Random forests. Machine learning, 45(1):5–32, 2001.

[3] Nitesh V Chawla, Nathalie Japkowicz, e Aleksander Kotcz. Special issue on learning fromimbalanced data sets. ACM Sigkdd Explorations Newsletter, 6(1):1–6, 2004.

[4] Rajeev Gupta, K Hima Prasad, e Mukesh Mohania. Automating itsm incident managementprocess. Em 2008 International Conference on Autonomic Computing, páginas 141–150.IEEE, 2008.

[5] Geoffrey E Hinton, Terrence Joseph Sejnowski, e Tomaso A Poggio. Unsupervised learning:foundations of neural computation. MIT press, 1999.

[6] Mikael Karlsson e Anton Karlstedt. Product classification-a hierarchical approach. LU-CS-EX 2016-31, 2016.

[7] Edward Loper e Steven Bird. Nltk: the natural language toolkit. arXiv preprint cs/0205028,2002.

[8] Andrii Maksai, Jasmina Bogojeska, e Dorothea Wiesmann. Hierarchical incident ticket clas-sification with minimal supervision. Em 2014 IEEE International Conference on Data Mi-ning, páginas 923–928. IEEE, 2014.

[9] Christopher D Manning, Prabhakar Raghavan, e Hinrich Schütze. Text classification andnaive bayes. Introduction to information retrieval, 1(6), 2008.

[10] Hank Marquis. How to classify incidents. 2010.

[11] Douglas C Montgomery, Elizabeth A Peck, e G Geoffrey Vining. Introduction to linearregression analysis, volume 821. John Wiley & Sons, 2012.

[12] F. Pedregosa, G. Varoquaux, A. Gramfort, V. Michel, B. Thirion, O. Grisel, M. Blondel,P. Prettenhofer, R. Weiss, V. Dubourg, J. Vanderplas, A. Passos, D. Cournapeau, M. Brucher,M. Perrot, e E. Duchesnay. Scikit-learn: Machine learning in Python. Journal of MachineLearning Research, 12:2825–2830, 2011.

[13] Fabian Pedregosa, Gaël Varoquaux, Alexandre Gramfort, Vincent Michel, Bertrand Thi-rion, Olivier Grisel, Mathieu Blondel, Peter Prettenhofer, Ron Weiss, Vincent Dubourg,et al. Scikit-learn: Machine learning in python. Journal of machine learning research,12(Oct):2825–2830, 2011.

57

58 REFERÊNCIAS

[14] Artur Rodrigues. How to classify incidents. 2012.

[15] K Sankar, S Kannan, e P Jennifer. Prediction of code fault using naive bayes and svmclassifiers. Middle-East Journal Of Scientific Research, 20(1):108–113, 2014.

[16] Fabrizio Sebastiani. Machine learning in automated text categorization. ACM computingsurveys (CSUR), 34(1):1–47, 2002.

[17] Anel Tanovic e Fahrudin Orucevic. Improvement of implementation of iso-iec 20000 edition2 standard in it systems of telecom operator through comparison with itil v3 best practi-ces. Em 1st WSEAS International Conference on Information Technology and ComputerNetworks (ITCN 2012), páginas 333–337, 2012.

[18] Sharon Taylor, Gary Case, e George Spalding. Continual service improvement. StationeryOffice, 2007.

[19] J van Bon. IT Service Management: An Introduction. 2002.

[20] Rüdiger Wirth e Jochen Hipp. Crisp-dm: towards a standard process modell for data mining.2000.

[21] Mingchun Yun, Yuqing Lan, e Tao Han. Automate incident management by decision-makingmodel. Em 2017 IEEE 2nd International Conference on Big Data Analysis (ICBDA)(, pági-nas 217–222. IEEE, 2017.

aprendizagem computacional para gestão de incidentes em ... · outras bibliotecas para linguagem...

Documents