universidade federal de pernambuco - cin ufpetg/2019-1/tg_cc/tg_ehammo.pdf · 2019. 7. 14. ·...
TRANSCRIPT
-
Universidade Federal de Pernambuco
Curso de Ciência da Computação
ANÁLISE DE ALGORITMOS DE APRENDIZAGEM DE
MÁQUINA EM UM AMBIENTE DINÂMICO DE MOBILE
CLOUD COMPUTING
Trabalho de Conclusão de Curso de Graduação
por
Eduardo Henrique Alves Maia Mattos Oliveira
Orientador: Prof. Kelvin Dias
Recife, Julho/ 2019
-
Eduardo Henrique Alves Maia Mattos Oliveira
ANÁLISE DE ALGORITMOS DE APRENDIZAGEM DE MÁQUINA EM
UM AMBIENTE DINÂMICO DE MOBILE CLOUD COMPUTING
Trabalho apresentado ao Programa deGraduação em Ciência da Computaçãodo Departamento de Informática daUniversidade Federal de Pernambuco comorequisito parcial para a obtenção do grau deBacharel em Ciência da Computação.
Orientador: Prof. Kelvin Dias
Recife
2019
-
Agradecimentos
Esta fase da minha vida é muito especial e não posso deixar de agradecer a Deus por
toda bênção, força e coragem que me ofereceu para ter alcançado minha meta.
Quero agradecer à minha famı́lia, especialmente aos meus pais Eduardo e Uiára por
serem essenciais na minha vida e pelo amor, incentivo e apoio incondicional.
Aos meus amigos deixo aqui minha gratidão por torcerem e vibrarem com a minha
conquista. Foram eles que me ajudaram a seguir sempre de cabeça erguida.
Meu muito obrigado à instituição UFPE, que me proporcionou a chance de expandir os
meus horizontes. Obrigado pelo ambiente criativo e amigável nesses anos de formação.
Agradeço à professora Renata Maria Rodrigues por todos os conselhos e por sempre
estar disposta a me ajudar. Ao meu orientador professor Kelvin Dias que me orientou
no decorrer desse semestre e por todo apoio à elaboração do meu projeto final.
Gostaria de agradecer também aos meus amigos do Centro de Informática e ao CESAR,
que me acolheu e tem me proporcionado experiências construtivas para minha carreira
profissional, especialmente a todos da equipe Motorola CBS.
Agradeço a todos que fizeram parte desta caminhada ao meu lado.
Que venha o futuro!
-
A satisfação está no esforço
e não apenas na realização final.
Mahatma Gandhi
-
RESUMO
Offloading computacional em computação em nuvem móvel, ou Mobile Cloud Compu-
ting (MCC), tem atráıdo muita atenção pelos seus benef́ıcios em economia de energia
e melhorias de desempenho. No entanto, esta técnica apresenta um baixo desempenho
quando é executada ignorando informações contextuais. Estudos recentes destacam o
uso de informações contextuais para o melhoramento da decisão de offloading, porém
ainda há desafios sobre o ambiente dinâmico de MCC. Então, esse trabalho oferece uma
análise entre vários algoritmos de classificação binária (J48, JRIP, NAIVE BAYES, IBk,
RandomForest, SMO, MLP) para tomar decisões sobre a realização do offloading com-
putacional, utilizando o banco de dados contextual adquirido em um trabalho anterior.
Além disso, este documento também apresenta um programa que automatiza o ajuste,
treinamento, teste e comparação dos algoritmos. Também foi modificado o BenchFace
(aplicativo benchmarking de reconhecimento facial) capacitando-o para um posśıvel re-
treinamento automático.
Palavras-chave: Mobile cloud computing, senśıvel ao contexto, sistema de offloading, of-
floading computacional, aprendizagem de máquina, algoritmos de classificação
-
ABSTRACT
Computational offloading in Mobile Cloud Computing (MCC) has attracted attention due
its benefits in energy saving and improved mobile application performance. Nevertheless,
this technique underperforms if the offloading decision ignores contextual informations.
While recent studies have highlighted the use of contextual information to improve the
computational offloading decision, challenges still remain regarding the dynamic nature
of MCC environment. Thus, this work offers an analysis between several binary classifica-
tion algorithms (J48, JRIP, NAIVE BAYES, IBk, RandomForest, SMO, MLP), to make
the decision if a device should do the computational offloading, utilizing the contextual
database acquired in a previous work. Furthermore, a program to automate the tuning,
training, testing and comparing of the algorithms was made. Besides that, the BenchFace
application (Facial recognition app for benchmarking) was also modified to be ready for
a possible automatic retraining.
Keywords: Mobile cloud computing, offloading system, context-sensitive, machine-learning,
classification algorithms.
-
LISTA DE FIGURAS
Figura 1 Arquitetura de offloading computacional adaptada de [1] . . . . . . . . . . . . . . . . . . 13
Figura 2 BenchFace.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
-
LISTA DE TABELAS
Tabela 1 Comparação qualitativa de soluções senśıveis ao contexto . . . . . . . . . . . . . . . . . . 20
Tabela 2 Atributos e valores contextuais. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Tabela 3 Resultados Friedman. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Tabela 4 Resultados Nemenyi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
-
LISTA DE SIGLAS
ARC AnyRun Computing
D2D Device to Device
FN False Negative
FNR False Negative Rate
FP False Positive
FPR False Positive Rate
IBk Instance-based K-nearest neighbours
javaNPST Non Parametric Statistical Tests in java
KNN K — Nearest Neighbors
MCC Mobile Cloud Computing
MLP Multi-Layered Perceptron
ML Machine Learning
MSN Mobile Social Network
OC Offloading Candidate
RF Random Forest
RSU Roadside Unit
SVM Support Vector Machine
SMO Sequential minimal optimization
TOPSIS Technique for Order of Preference by Similarity to ideal Solution
TN True Negative
TNR True Negative Rate
TP True Positive
TPR True Positive Rate
UFPE Universidade Federal de Pernambuco
V2I Vehicle to Infrastructure
V2V Vehicle to Vehicule
VANETS Vehicular Ad-hoc Network
-
SUMÁRIO
1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2 FUNDAMENTOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.1 Sistema de offloading senśıvel ao contexto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2 Algoritmos de classificação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3 TRABALHOS RELACIONADOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4 SOLUÇÃO PROPOSTA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.1 BenchFace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.2 AlgorithmCompare. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.2.1 Tuning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
5 EXPERIMENTOS E ANÁLISE DE RESULTADOS . . . . . . . . . . . . . . . . . 29
5.1 Base de dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.2 Treinamento e teste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
5.3 Comparação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
6 CONCLUSÃO E TRABALHOS FUTUROS . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
-
10
1 INTRODUÇÃO
Computação em nuvem móvel, ou Mobile cloud computing (MCC), oferece serviços
de nuvem no ecossistema móvel [2]. Esse paradigma surge da cooperação entre a com-
putação móvel e a computação em nuvem, permitindo a migração do armazenamento e
da computação de dispositivos móveis, que têm recursos limitados, para servidores na nu-
vem, diminuindo a carga computacional e o consumo de bateria desses dispositivos. Essa
migração deve ser feita de forma a considerar recursos como disponibilidade, velocidade e
confiabilidade sem reduzir o desempenho da aplicação [3]. Isso pode ser alcançado através
de operações de offloading, i.e., a transferência de informações e códigos de dispositivos
móveis para uma nuvem local (cloudlet) ou pública (Amazon EC2). [4]
De acordo com Huber Flores em [5], offloading computacional é o processo em que
um dispositivo com poucos recursos delega uma tarefa para outro com mais recursos, e
em seu outro trabalho [1], ele afirma que o offloading computacional só é produtivo se
economiza energia sem degradar o desempenho da aplicação. Para que essa migração
ocorra como o esperado é importante que tomemos notas de algumas caracteŕısticas do
contexto envolvido, tais como: largura de banda, a força do sinal, o tamanho dos dados,
as capacidades dos dispositivo. Já que esses parâmetros podem mudar com frequência, os
momentos oportuńısticos para fazer a migração para um servidor remoto de nuvem são
esporádicos. Por este motivo, a efetividade de uma operação de offloading é determinada
pela sua habilidade de inferir onde a execução daquele código terá um menor esforço
computacional, localmente ou na nuvem [1].
O offloading poderá ser feito para três tipos de nuvem: nuvem pública, um servidor
cloudlet, ou uma cloudlet ad-hoc. Uma nuvem pública é criada por recursos computaci-
onais localizados em data centers e mantidos por provedores de serviços de nuvem. Um
servidor cloudlet é um conjunto de baixo custo de computadores multicore, localizado
na mesma rede Wireless Local Area Network (WLAN) que os dispositivos móveis. Ele
pode prover serviços de nuvem numa escala pequena e é comumente encontrado em am-
bientes domésticos, corporativos e públicos. Por fim, uma cloudlet ad-hoc é formada por
um grupo de dispositivos móveis com alto poder de processamento que compartilha seus
recursos com seus vizinhos locais com menos recursos [2].
Este problema introduz a necessidade da adaptabilidade ao contexto. Os sistemas
-
11
capazes de offloading computacional precisam se adaptar baseados na informação sobre
os recursos que estão sendo oferecidos, inferindo informações de contexto dos dispositivos,
para decidir onde e quando se deve fazer o offloading. Em outras palavras, um sistema
senśıvel ao ambiente em que está inserido, capaz de monitorar, coletar, selecionar, pro-
cessar e compartilhar essa informação contextual [3] envolvida na tomada de decisão e na
execução da migração da tarefa computacional. Informação contextual é qualquer tipo
de informação que caracterize uma entidade de um domı́nio espećıfico; Alguns exemplos
de posśıveis entidades são; uma pessoa, um celular, uma aplicação, um servidor (nuvem),
um elemento de rede [6] [7].
Tradicionalmente, os sistemas de offloading dinâmico já existentes propõem no-
vos frameworks [8], middlewares que usem algoritmos de aprendizagem de máquina ou
modelos de classificação utilizando informações contextuais para a tomada de decisão.
Máquinas de vetores de suporte [9], Naive Bayes [10], Árvores de decisão [11] constituem
alguns dos algoritmos de aprendizagem de máquina que operam construindo um modelo
a partir de de uma amostra de dados, objetivando realizar previsões ou decisões. Porém,
caso a amostra seja pequena ou não cubra alguns casos importantes, esses algoritmos
podem tomar decisões erradas quando colocados no mundo real. Em [3] foi feita uma
comparação com alguns algoritmos, para determinar quais deles seriam mais adequados
para o contexto de MCC. Os algoritmos foram escolhidos com o objetivo de minimizar
o custo computacional, isto é, escolher aqueles que demoram menos para treinar e tes-
tar. Porém, muitos algoritmos importantes foram deixados de fora, inclusive alguns cujo
alto custo computacional se encontrava no treinamento (que poderia ser feito na nuvem)
e não na inferência (que seria feito no cliente). Portanto, nesse trabalho fazemos uma
análise, usando a mesma base de dados de [3], incluindo diversos importantes algoritmos
de classificação binária não mencionados por [3], buscando esclarecer diferenças entre os
algoritmos e porque eles se encaixam ou não no contexto desses experimentos.
O resto deste documento é organizado da seguinte forma: Seção 2 descreve a
informação de background. Seção 3 discute os trabalhos relacionados. Seção 4 apresenta
os passos feitos para a análise e a comparação dos algoritmos, e os testes feitos para
avaliá-los. Por fim a Seção 6 conclui o documento e apresenta os trabalhos futuros.
-
12
2 FUNDAMENTOS
Nessa Seção, descrevemos a arquitetura de um sistema de offloading senśıvel ao
contexto e alguns exemplos de aplicações no mundo real (seção 2.1). Em seguida descreve-
mos os algoritmos de classificação de aprendizagem de máquina utilizados nesse trabalho
(seção 2.2).
2.1 Sistema de offloading senśıvel ao contexto
A arquitetura de offloading computacional adaptada de [1] é mostrada na Figura
1. A arquitetura consiste em duas partes: um conjunto de clientes e outro de servidores.
Nessa abordagem, qualquer entidade móvel, seja ela um carro conectado, um smartphone,
um drone, ou um dispositivo IoT qualquer, pode delegar uma tarefa computacional para
qualquer modelo de nuvem, seja ela uma cloudlet, uma nuvem remota ou até uma cloudlet
ad-hoc, também chamada de dispositivo a dispositivo, Device-to-Device (D2D), em outros
estudos. Candidatos para migração (Offloading Candidates - OCs), podem ser porções de
código (C) como métodos, threads, ou classes inteiras, e esses candidatos são identificados
pelo programador do software. [3]
A sensibilidade ao contexto refere-se a capacidade do sistema de se adaptar às
mudanças do ambiente em que ele está inserido [6]. Em MCC, um sistema de offloading
senśıvel ao contexto é capaz de monitorar, coletar, selecionar, processar e compartilhar
a informação contextual de uma entidade. É altamente utilizado em ambientes onde a
fonte energética ou o poder computacional é escasso. O objetivo deste tipo de sistema é
ser ciente de toda informação contextual para migrar apenas quando processar na nuvem
for melhor que processar localmente [7].
O processo de offloading pode ser melhorado usando informação contextual para
dinamicamente tomar decisões, e apenas começar o processo de migração quando o con-
texto for vantajoso [3], já que o offloading estático não traz benef́ıcios em todos os contex-
tos [12]. Em MCC, um contexto vantajoso é aquele cujas informações fazem o processo
de offloading ter um custo computacional menor do que a execução local da tarefa [1].
-
13
C
OC
C
public class image {
void method1(){
//...
}
void method2(){
// Offloading Candidate
}
void method3(){
//...
}
main(){
method1();
method2();
method3();
}
}
Synchronizaon
point
Synchronizaon
point
Local
processing
Transfer
rao
Invocaon
Execuon
flow
Cloudlet
D2D
Remote cloud
Transfer
rao
Remote
processing
External processingLocal processing
Vanets
Healthcare
Augmented
reality
OC
Figura 1 Arquitetura de offloading computacional adaptada de [1]
Um exemplo no ambiente de Saúde é a tecnologia de smart-band [13], que tem
vários sensores cuja função é monitorar batimentos card́ıacos, ńıvel de insulina no san-
gue, temperatura corporal, além de outras métricas. Essas smart-bands não têm bateria
suficiente ou poder computacional para lidar com todas essa tarefas, considerando que
existem tarefas que necessitam de um alto poder computacional. Muitos dos sistemas
que usam smart-bands fazem um offloading estático para um aparelho celular via blue-
tooth. Nos casos onde o dispositivo e o paciente estão muito distantes, outros meios de
transmissão devem ser considerados para economizar energia. Após a transferência de
dados brutos dos sensores para o celular, o sistema então migra a tarefa de processá-los
para a nuvem estaticamente [13]. Porém, em algumas situações é mais vantajoso que essa
execução não seja migrada para um nuvem pública e seja executada localmente no celu-
lar do paciente, inclusive em [13] algumas funcionalidades foram escolhidas para serem
executadas localmente e outras para serem migradas para a nuvem. Essas decisões de
-
14
quais métodos devem sempre executar locais e quais devem sempre executar na nuvem
são pasśıveis de erro à medida que o contexto muda. Em um dia que não há internet na
casa do paciente é melhor que as execuções de algumas features sejam feitas localmente
ao invés de funcionarem apenas com o sistema online. Então, um sistema de offloading
ciente de contexto conhece o número de sensores, o tamanho da informação a ser trans-
ferida, o quão rápida está a latência da rede, como está a capacidade da nuvem, qual é
a capacidade de processamento local e usa todas essas informações para decidir onde os
dados coletados nos sensores podem ser melhor processados. Portanto, essa smart-band
só vai processar na nuvem quando o contexto for vantajoso para isso.
Este tipo de sistema também pode ser usado em redes veiculares Ad-Hoc (VA-
NETs), que tem como objetivo prover assistência de viagem, informação dos véıculos e
entretenimento no geral, trazendo facilidade, conforto e uma viagem prazerosa como um
todo [14] [15]. Carros e Roadside Units (RSUs) podem compartilhar o recurso do poder de
processamento, seja de véıculo para véıculo (V2V) ou de véıculo para infraestrutura (V2I),
processando vários tipos de informações diferentes. Isso significa que todo conteúdo, seja
ele áudio, imagens ou v́ıdeos requisitados por passageiros, ou dados coletados por senso-
res, têm que ser processados localmente ou em VANETs de acordo com o tamanho dos
dados, a largura da banda, a distância entre os carros, a velocidade dos carros, etc. Essa
mudança frequente de contexto torna um sistema senśıvel ao contexto necessário para
decidir qual o melhor lugar para processar a informação.
Outro exemplo é a Rede social móvel ou MSN, do inglês Mobile Social Networ-
king. MSN envolve a interação entre usuários que têm os mesmos interesses e/ou obje-
tivos através dos seus dispositivos dentro de redes sociais virtuais [16]. Os dispositivos
desses usuários podem compartilhar os seus recursos para processar dados juntos. Seja
um processamento de imagem ou tradução de texto, toda tarefa poderia ser dividida e
compartilhada entre dispositivos. Porém, dependendo do tamanho dos arquivos a serem
transmitidos, não vale a pena compartilhar a tarefa.
2.2 Algoritmos de classificação
Para melhorar a decisão sobre o melhor lugar para processar as tarefas (No disposi-
tivo ou na nuvem), algoritmos de classificação de aprendizagem de máquina são necessários
em sistemas de offload senśıveis ao contexto. Aprendizagem de Máquina, ou ML, do inglês,
-
15
Machine learning é definida por [17] [18] como um sistema ou algoritmo capaz de apren-
der baseado em experiências passadas, gerando regras a partir de instâncias (exemplos em
um conjunto de treinamento) [19], sem nenhuma assistência de um ser humano [20]. Um
subdomı́nio do campo de ML é o aprendizado supervisionado. Nele, o treinamento é feito
com dados categorizados com as entradas e as sáıdas desejadas [17] [21]. A função desses
algoritmos é classificar uma instância baseada em seu conjunto de treinamento, decidindo
assim qual a classe mais adequada.
Os algoritmos de classificação usados nesse documento foram: Árvore de decisão,
RandomForest, Aprendizagem baseada em regras, Máquina de vetores de suporte (SVM
do inglês, Support Vector Machine), Perceptron de Multi Camadas (MLP do inglês Multi
Layer Perceptron), O vizinho K mais próximo (KNN, do inglês k-Nearest Neighbor) e
Naive-Bayes. A árvore de decisão, o KNN, o aprendizado baseado em regras, e o Naive-
Bayes são algoritmos bastante usados em computação ub́ıqua pela sua alta acurácia e
baixo custo computacional. Já que em [3] o J48 apresentou um dos melhores desempe-
nhos dentre os algoritmos comparados, decidiu-se incluir o RandomForest, que também é
baseado em Árvore de decisão, na análise estat́ıstica comparativa deste trabalho. A SVM
foi introduzida pela sua robustez e flexibilidade. Acredita-se que ela pode ser uma boa
opção para este problema e o MLP também foi considerado devido ao seu relacionamento
com SVMs [22] e com Deep Learning.
O KNN é um algoritmo de classificação que identifica a instância baseado no K-
vizinho mais próximo cuja classe já se conhece [23]. A escolha do melhor K vai variar
de acordo com o conjunto de dados. O vizinho mais próximo é calculado com base no
valor desse K, que significa quantos vizinhos devem ser considerados. A similaridade é
medida de acordo com a distância das instâncias mais próximas. Esse algoritmo requer
um pouco mais de memória, e esta é a principal desvantagem. Além disso, KNN pode
se confundir caso a instância tenha muitos atributos irrelevantes [23]. A versão do KNN
utilizada neste trabalho foi o IBk [24], implementada pela biblioteca do Weka.1
Um classificador Naive-Bayes usa uma função de probabilidade para definir a qual
classe uma dada instância pertence [25]. A probabilidade é calculada de acordo com suas
caracteŕısticas e a distribuição condicional de dada instância. Então, a probabilidade final
é calculada usando essas probabilidades e funções distribúıdas entre as classes objetivo.
1Weka é coleção de algoritmos de aprendizagem de máquina. Permite a exportação dos modelos declassificação para o uso em código java. http://www.cs.waikato.ac.nz/ml/weka/downloading.html
-
16
As principais vantagens de usar Naive-Bayes são a rapidez do treinamento e teste. Esse
algoritmo é bom com valores numéricos e nominais, requer pouca memória e tem um baixo
custo computacional [26] [27]. A maior desvantagem está em supor a forte independência
entre as funcionalidades causando uma perda de acurácia e no fato de funcionar melhor
em um grande conjunto de dados.
A Árvore de decisão é uma técnica de aprendizado supervisionado que constrói, a
partir de um conjunto de informações, uma árvore capaz de classificar dados. O algoritmo
de árvore de decisão usado neste trabalho foi o J48 - implementação em Java da árvore de
decisão C4.5 que é um conjunto de algoritmos usado para criar árvores de decisão para ML
e mineração de dados [25]. A árvore é constrúıda usando uma estratégia top-down, onde
a raiz é a feature, ou caracteŕıstica, que tem o maior ganho de informação e o processo
continua recursivamente até que todas as instâncias sejam particionadas em subconjuntos
pertencentes a mesma classe. O ganho de informação de uma feature indica o quão
importante ela é. Os atributos mais próximos a raiz são os atributos mais importantes.
Desta forma a árvore vai ter menos regras. C4.5 tem muitas vantagens, como a facilidade
de visualização e entendimento, possibilidade de conversão em um conjunto de regras,
capacidade lidar com dados nominais, numéricos e valores vazios no conjunto de dados.
Porém tem um baixo desempenho caso muitas interações complexas causem o problema
da replicação, isto é, muitas sub-árvores sejam iguais [28].
Random forest (RF) é um classificador que combina árvores de decisão onde o
resultado da classificação é a classe mais votada entre as árvores. Breiman em [29] define
esse classificador como uma coleção de classificadores com a estrutura de árvores {h(x,
k), k = 1,...} onde k são vetores aleatórios distribúıdos independentemente, e cada árvore
tem um único voto para a classe mais popular de uma dada entrada x. O fato que esse
classificador é uma combinação de outros classificadores entrega algumas caracteŕısticas
especiais para o Random Forest que o diferencia substancialmente das tradicionais árvores
de decisão [30]. Como já foi mencionado, há uma limitação do quão complexa uma árvore
de decisão pode se tornar [28], pois, caso se torne muito complexa, podemos sofrer com
sobre-ajuste, i.e. o modelo se ajusta muito bem ao conjunto de dados anteriormente ob-
servado, mas se mostra ineficaz para prever novos resultados. RF aumenta a diversidade
das árvores crescendo-as a partir de diferentes subconjuntos do banco de dado de trei-
-
17
namento [30]. Assim, as árvores em diferentes sub-espaços generalizam sua classificação
de forma complementar [31]. Então, RF é uma ferramenta efetiva em predição. É um
classificador bastante acurado e não sofre do problema de sobre-ajuste [29].
Máquinas de vetores de suporte, ou SVM, do inglês Support Vector Machines, é
uma estratégia de classificação baseada no prinćıpio de minimização de risco estrutural. A
ideia é encontrar a hipótese h que aproximadamente minimiza o erro verdadeiro, contro-
lando eficientemente e efetivamente as dimensões do espaço que contém h, classificando
as instâncias e separando-as em um hiper-espaço [32]. SVMs também podem ser con-
sideradas, como uma entidade matemática ou um algoritmo que maximiza uma função
matemática particular, de acordo com uma base de dados, rotulando instâncias a partir
de exemplos [33]. As SVMs, em sua forma mais básica, aprendem uma função de limiar
linear. Porém, integrando um kernel apropriado [32], as SVMs podem usar classificado-
res polinomiais, redes de funções de base radial, redes neurais sigmoidais, dentre outros.
Cada kernel da SVM têm hiper parâmetros desconhecidos que devem ser escolhidos antes
do treinamento. E cada problema tem um valor diferente para estes hiper parâmetros.
Por isso, para esse algoritmo é necessário fazer uma busca pelos melhores parâmetros, ou
tuning, antes do treinamento [34]. Por fim, SVMs conseguem ser robustas mesmo quando
a base de treinamento é tendenciosa (por nossa base ser pequena essa caracteŕıstica é
interessante) e são flex́ıveis, sendo boas soluções para diversos problemas já que podemos
introduzir diferentes kernels [35]. Um classificador SVM nem sempre supera a solução
mais simples [36], como uma árvore de decisão por exemplo. SVMs são mais dif́ıceis de
se interpretar, quando o kernel não é linear, e, quando misturamos atributos nominais
e numéricos, Random Forests tem melhores resultados em diversos casos [37]. Ou seja,
apesar do SVM ser uma ótima e flex́ıvel ferramenta, é necessário escolher o kernel apro-
priado e seus hiper parâmetros cuidadosamente para cada problema e para cada base de
dados de forma a obter bons resultados.
O perceptron multi camadas ou, MLP, do inglês Multi Layer Perceptron, também
chamado de Feed-forward network é um tipo de rede neural formada por uma função de
ativação em uma camada escondida, provendo um mapeamento de um vetor de entrada
e um de sáıda. Normalmente uma MLP tem 3 camadas: uma de entrada, uma escondida
e uma de sáıda. Cada camada é cheia de neurônios, e cada neurônio possui uma função
matemática, chamada de função de ativação. Esses neurônios são interconectados entre si
-
18
através de pesos [38]. MLP é um algoritmo muito utilizado para problemas de regressão,
porém também é usado em problemas de classificação, como o apresentado nesse trabalho,
pela sua capacidade de aprender e modelar relações complexas e não lineares entre as
caracteŕısticas dos dados. Porém, além de ter um alto custo de treinamento e teste, o
MLP muitas vezes cai no erro mı́nimo local ao invés do global, ou seja, por vezes ele não
encontra a melhor solução.
Por último, um algoritmo de classificação baseado em regras é o meio mais simples
e mais direto de todos. Normalmente o algoritmo forma uma estrutura no formato de IF-
THEN-ELSE. JRip (RIPPER) [39] é um algoritmo que funciona baseado em um conjunto
de regras. Usa um método de ”dividir e conquistar”com o objetivo de reduzir o erro. A
construção desse conjunto de regras é feito adicionando regras, adicionando condições até
as instâncias convergirem na mesma classe [40]. Suas vantagens são a flexibilidade, fácil
implementação de novas regras que podem ser criadas ou modificadas para novos dados,
fácil interpretação, pouca exigência de recursos de memória e processamento [41]. Sua
principal desvantagem é que ele não apresenta bons resultados quando alguns exemplos
do banco de dados de treinamento apresentam caracteŕısticas faltantes, isto é, exemplos
incompletos [42].
-
19
3 TRABALHOS RELACIONADOS
A migração de qualquer tarefa para a nuvem é senśıvel a múltiplos parâmetros do
sistema, como o contexto do dispositivo, o tipo da aplicação, o estado da rede, e com
tantos parâmetros torna-se dif́ıcil saber qual o momento mais oportuńıstico para fazer o
offload [5]. Consequentemente, para lidar com esses desafios, os trabalhos mais recentes
trazem propostas de novos frameworks, algoritmos, modelos, middlewares, que dependem
do monitoramento periódico de várias métricas para inferir onde a execução do código
exigirá menos esforço computacional.
As soluções mais recentes, como Thinkair [8], Mobibyte [43], Anyrun [10], CADA
[44], Kwon et al. [45], OMMC [46], mCloud [47], Majeed et al. [9] e CSOS [3], implemen-
tam um sistema de monitoramento, modelos energéticos, modelos de decisão, e sistemas
que gerenciam a comunicação entre a nuvem e o dispositivo. Esses sistemas são implemen-
tados em smartphones, ou seja, os dispositivos monitoram e decidem onde a tarefa será
executada. Outros estudos como o MAUI [48], EMCO [49] e Rego et al. [11], executam
operações complexas para a tomada de decisão fora do dispositivo móvel.
A Tabela 1 apresenta um resumo das soluções existentes e suas caracteŕısticas.
Provê informação sobre as fontes contextuais adotadas por cada solução, quais técnicas
foram usadas para a tomada de decisão de onde executar o OC, de forma a melhorar o
desempenho da aplicação, ou economizar o máximo a energia do dispositivo. A tabela
também informa se o estudo avalia o desempenho do algoritmo que toma as decisões,
analisando a acurácia por exemplo.
-
20
Tabela 1 Comparação qualitativa de soluções senśıveis ao contexto
Nome das
soluções
Fontes contextuais Caracteŕısticas
App DispositivoRede sem
Fio
Nuvem/
CloudletDecisão
Acurácia
(%)
MAUI x x x - Programação linear None
ThinkAir x x x - Modelo energético NA
Mobibyte x x x - Modelo energético NA
ARC - x x - Naive Bayes NA
Kwon et al. x x - - Regressão polinomial NA
OMMC x x x -TOPSIS e
Modelo energéticoNA
mCloud x x x -TOPSIS e
Modelo de custoNA
EMCO x x x - Lógica Fuzzy NA
Rego et al. x x x - Árvore de decisão NA
CADA - x x - Modelo energético 90
Majeed et al. x x x - SVM 92
CSOS x x x x
(K-NN, Regras,
Naive Bayes,
e Árvore de decisão)
95
Este trabalho x x x x
(K-NN, Regras,
Naive Bayes,
SVM, MLP
Árvore de decisão
Random Forest)
95
Quanto à decisão de onde a tarefa deverá ser executada, ThinkAir, MobiByte,
CADA, e OMMC fazem essas decisões considerando a energia envolvida tanto na com-
putação da tarefa quanto na comunicação entre o dispositivo e a nuvem. As medições de
energia usam modelos de estimação energéticas. A solução do MAUI no entanto resolve
um problema de programação linear no servidor remoto granularizando que métodos de-
vem ser executados remotamente e quais devem ser executados localmente. Depois, essa
informação é enviada e atualizada nos dispositivos.
Outras soluções como EMCO e Majeed et al., lidam com decisões de offloading
baseado em modelos de decisão baseado em contexto, como lógica fuzzy e Support Vector
-
21
Machine (SVM), respectivamente. EMCO propõe o uso de lógica fuzzy para agregar as
informações contextuais, que em conjunto com os dados históricos constroem um sistema
de inferência que classifica onde cada tarefa deve ser executada, local ou remotamente. Já
o sistema proposto por Majeed et al. usa SVM para esse mesmo propósito. O classificador
SVM adapta sua decisão de acordo com os dados contextuais internos e externos providos
pelo modulo de profiling que monitora e armazena essas informações.
Tanto o CSOS quanto o Rego et al. utilizam abordagens baseadas em Árvore
de decisão para a tomada de decisão de onde executar determinada tarefa, levando em
conta tanto a informação contextual atual quanto os dados históricos. Já o sistema ARC,
ou AnyRun Computing, escolheu usar o modelo de decisão Naive Bayes para analisar a
probabilidade que o processo de offloading é vantajoso quando o compara a execução local
do OC. Knwon et al. e mCloud usam outras técnicas para essa previsão de onde a execução
é mais benéfica. mCloud, framework de offloading proposto por [47], contém um algoritmo
para tomar decisões de onde executar tarefas computacionais em tempo de execução, além
de selecionar o tipo de rede sem fio (Wifi, 4G, bluetooth, etc) e para qual nuvem o offload
deve ocorrer. Os autores aplicam a técnica de ordenação de preferência por similaridade,
do inglês Technique for Order of Preference by Similarity to Ideal Solution (TOPSIS) [50].
Para o tipo de rede sem fio vários critérios são analisados como: disponibilidade da
tecnologia escolhida, congestionamento da rede, custo energético da migração por este
canal); e aplicam um modelo de estimação de custo para calcular o custo de cada pedido
de offloading. Já o Knwon et al. propõe uma técnica de predição para superar o problema
da sensibilidade da entrada do desempenho da aplicação móvel. Esta técnica foi nomeada
de fMantis, e ela gera uma predição do desempenho da aplicação, analisando métricas
como: tempo de execução, consumo energético e uso de memória.
O trabalho CSOS [3] não aborda nem compara algumas técnicas de decisão, pre-
sentes em vários dos trabalhos relacionados, como o Support Vector Machine por exemplo.
Além disso, outra técnica importante que não foi abordada é o Random Forest, que é ex-
tremamente relevante quando se analisa que as melhores técnicas em [3] e [11] foram as
baseadas em regras e de árvore de decisão. Nosso trabalho visa complementar o trabalho
feito em [3], analisando e comparando esses outros algoritmos, utilizando a mesma base
de dados.
-
22
4 SOLUÇÃO PROPOSTA
Nesta Seção, descrevemos os detalhes de implementação das mudanças feitas na
aplicação BenchFace1 desenvolvida para a produção de [3] (4.1) e do AlgorithmCompare2
para automatizar o treinamento e teste dos algoritmos de machine learning (4.2).
4.1 BenchFace
BenchFace é um aplicativo de detecção de face que usa Haar features baseado
em classificadores em cascata, um método proposto pelos pesquisadores Michael Jones
e Paul Viola [51]. O algoritmo de detecção de face usa uma abordagem baseada em
aprendizagem de máquina, onde funções em cascata são treinadas com um conjunto de
imagens positivas (imagens que contêm faces) e negativas (imagens que não possuem
faces). Para a detecção facial, o aplicativo usa o openCV, biblioteca em c/c++ voltada
para o desenvolvimento de aplicativos na área de Visão computacional, que nos entrega
classificadores pre-treinados em formato de xml para uso. O classificador escolhido foi
o ”haarcascade frontalface default.xml”. Além disso, o aplicativo também possui uma
única imagem com diferentes resoluções contendo 77 faces para detecção. Sua execução
pode ocorrer na nuvem, local e dinamicamente. Ao final da execução é exibida na tela a
quantidade de faces detectadas e o tempo decorrido para detectá-las.
1Aplicação de benchmarking para detecção facial: https://github.com/ehammo/BenchFace2Programa de automação para o ajuste, treinamento e teste, usando validação cruzada, dispońıvel
para a comunidade no site: https://github.com/ehammo/algorithmCompare
-
23
A Figura 2 representa o aplicativo após a execução local da detecção facial.
Figura 2 BenchFace.
No sistema do CSOS [3], o desenvolvedor precisa anotar cada método que ele de-
seje classificar como OC, Offloading Candidate, estabelecendo se a migração deve sempre
acontecer, offloading estático, ou se uma decisão deve ser tomada, offloading dinâmico.
No caso de offloading dinâmico há a necessidade de determinar qual classificador será
usado para tomar a decisão. O Listing 4.1 ilustra justamente este passo
public interface DynamicDetectFacesJ48 extends DetectFaces {
@Remotable ( va lue=Remotable . Of f load .DYNAMIC, s t a tu s=true ,
c l a s s i f i e r=Remotable . C l a s s i f i e r . J48 )
Proper t i e sFace detec tFaces ( S t r ing c a s c a d e C l a s s i f i e r , byte [ ]
o r i g ina l Image ) ;
[ . . . ]
}
-
24
Listing 4.1 Anotação para especificar o classificador
Durante esse trabalho foi feita a portabilidade da aplicação para o Android P.
Essa tarefa foi extremamente necessária para que a aplicação funcione como esperado nos
dispositivos Android mais recentes. Para migrar a aplicação também foi necessário migrar
o middleware do lado do cliente. Dentre as maiores modificações destacamos:
• A compilação da biblioteca do OpenCV, que é em C++, não poderia usar mais o
NDK e deveria ser compilada usando CMake.
• Várias APIs públicas mudaram do Android N para o P. Foi necessário adaptá-las
ou trocá-las. Um exemplo foi a API que verifica a conexão com a internet.
• Também adicionamos várias permissões para a aplicação e as solicitamos para o
usuário.
Além disso adicionamos a funcionalidade de baixar os modelos de aprendizagem
de máquina do servidor sempre que o usuário desejar, automatizando a implantação dos
modelos. Esse passo também passa pelo middleware e deve ser anotado como um método
que exige um offloading estático. Isso se deve ao fato de que o treinamento e teste
dos modelos sempre é feito no servidor, que contém os dados e tem mais recursos. O
Listing 4.2 representa a interface para essa nova tarefa. O Objetivo é facilitar um posśıvel
retreinamento, onde o dispositivo enviaria novas informações para o servidor, que treinaria
diversos algoritmos de aprendizagem de máquina e os melhores seriam enviados de volta
logo em seguida.
public interface CloudletUpdateServ ice {
@Remotable ( va lue = Remotable . Of f load .STATIC, s t a tu s = true )
HashMap u p d a t e C l a s s i f i c a t o r s ( S t r ing [ ]
newInstances ) ;
}
Listing 4.2 Atualizar classificadores
O Retreinamento em si não foi implementado nesse trabalho. Como já foi men-
cionado, o objetivo era enviar novas informações das últimas execuções para o servidor
-
25
para retreinar os algoritmos. Porém, os algoritmos utilizados no estudo anterior [3] são
supervisionados, i.e. para treiná-los é necessário rotular os dados para a classe ”Sim”ou
”Nao”. No entanto, não se sabe se o algoritmo acertou ou errou em sua classificação, e
portanto não podemos rotular a execução para usá-la como novo dado de treinamento
para os algoritmos supervisionados.
4.2 AlgorithmCompare
O programa AlgorithmCompare foi desenvolvido para automatizar o ajuste, treina-
mento, teste e comparação dos algoritmos de decisão. Este programa funciona da seguinte
forma: inicialmente os parâmetros de cada modelo de ML são ajustados. Em seguida cada
classificador é treinado medindo o seu desempenho pela sua acurácia e outras métricas.
O teste é feito com 30 repetições de validação cruzada (10-fold) variando a semente (seed)
do Weka que distribui o banco em teste e treinamento de 1 a 30. Os resultados devem
então ser analisados e comparados usando técnicas estat́ısticas como matriz de confusão
e métricas de desempenho como especificidade, sensitividade, precisão e acurácia. Mais
detalhes sobre o teste foram descritos no caṕıtulo 5
O desenvolvimento do programa começou em [3], porém, muito dos passos ainda
eram manuais como a comparação entre os algoritmos. Os testes estat́ısticos eram feitos
em outros scripts não integrados, e, por fim, a implantação dos modelos da biblioteca Weka
para a aplicação também era feito de forma manual. Com o objetivo de posteriormente
trabalharmos com retreinamento, a aplicação do AlgorithmCompare e o BenchFace foram
integrados em um único arquivo ”.jar”, para que, desta forma, possamos acessar o código
de retreinamento pelo middleware da aplicação.
Outra grande mudança foi a inserção dos novos algoritmos de classificação no sis-
tema, como o SVM, MLP e RandomForest. E com eles, surgiu a necessidade de descobrir
quais eram os melhores valores para seus hiper parâmetros, aqueles que são escolhidos an-
tes de começar o treinamento. Anteriormente em [3], a escolha desses hiper parâmetros era
feita de forma manual, rodando o programa para obter os resultados para cada mudança e
posteriormente compará-los usando outras ferramentas. Apenas algumas alterações eram
feitas no programa em tempo de execução, como a podagem da árvore. Como agora
temos o objetivo de um posśıvel retreinamento e aumento da quantidade de dados em
mente, e com a inserção de algoritmos como SVM, a aplicação precisava ser capaz de
-
26
fazer um tuning automatizado de seus algoritmos. Então, inserimos o Grid Search, que é
uma das abordagens mais utilizadas para a otimização dos hiper parâmetros de um dado
modelo, isto é, encontrar os valores que entregam o melhor resultado. No caso do Algo-
rithmCompare, o Grid Search1 utilizado foi o da biblioteca do Weka, que foi configurado
para buscar pelo classificador com melhor acurácia. É necessário também configurar, para
cada algoritmo, quais dois hiper parâmetros serão otimizados.
4.2.1 Tuning
O algoritmo 1 mostra a configuração do grid search para cada algoritmo de clas-
sificação usado no programa. No MLP no entanto, o número de camadas escondidas não
pode ser escolhido como hiper parâmetro. Isso se deve ao fato que a implementação do
MLP do Weka recebe esse parâmetro em formato de texto, e a variação do GridSearch só
funciona com números e booleanos. É por este motivo que a variação da quantidade de ca-
madas escondidas do MLP é considerada como uma variação do algoritmo, ou seja, MLP
com uma camada escondida e MLP com 3 camadas escondidas são considerados como
dois algoritmos distintos. Isso também ocorre com o SMO, o algoritmo de otimização
mı́nima sequencial de John Platt usado para treinar uma SVM comum. Quando o kernel
do SMO muda, os seus hiper parâmetros também mudam. Então, SMO com um kernel
polinomial (SMO poly) é considerado um algoritmo diferente do SMO com um kernel de
função de base radial (SMO rbf).
1 http://weka.sourceforge.net/doc.stable/weka/classifiers/meta/GridSearch.html
-
27
Algorithm 1 Algoritmo que decide quais hiper parâmetros serão otimizados
1: gs← GridSearch()
2: gs.Evaluation← Acuracy
3: if classifierType = IBK then
4: gs.X ← KNN
5: gs.Y ←MeanSquare
6: else if classifierType = J48 then
7: gs.X ← Unpruned
8: gs.Y ← ConfidenceFactor
9: else if classifierType = JRIP then
10: gs.X ← UsePruning
11: gs.Y ← Optimizations
12: else if classifierType = SMO poly then
13: gs.X ← kernel.Exponent
14: gs.Y ← C
15: else if classifierType = SMO rbf then
16: gs.X ← kernel.gamma
17: gs.Y ← C
18: else if classifierType = MLP 1hidden or classifierType = MLP 3hidden then
19: gs.X ← LearningRate
20: gs.Y ←Momentum
21: else if classifierType = NAIVE BAYES then
22: gs.X ← UseKernelEstimator
23: gs.Y ← UseSupervisedDiscretization
24: else if classifierType = RANDOMFOREST then
25: gs.X ← Seed
26: gs.Y ← NumIterations // Number of trees
27: end if
No Algoritmo 1, podemos ver quais foram os hiper parâmetros escolhidos de cada
algoritmo para otimização. Para o algoritmo IBk (K-NN), alteramos o número K de vi-
zinhos que o algoritmo deve usar (KNN) e se usamos o erro médio quadrado ou absoluto
quando estamos fazendo a validação cruzada (MeanSquare). Para o J48, a árvore de
-
28
decisão, alteramos se vamos podá-la ou não (Unpruned) e o fator de confiança (Confi-
denceFactor), que também é intrinsecamente ligado com o quanto a árvore será podada.
Para o JRIP os parâmetros foram similares aos do J48: um sobre podagem das regras
(UsePruning) e o outro, ’Optimization’, refere-se a quantidade de vezes que o JRIP po-
dará a lista de regras. Para os dois SMOs temos um parâmetro geral, o C, que determina
a influência da classificação errada na função objetivo, e um espećıfico por kernel. Para o
SMO com kernel polinomial, alteramos o expoente (kernel.Exponent) do polinômio e para
o com kernel de função de base radial alteramos o gamma (kernel.gamma) que determina
a influência de um único exemplo de treinamento no todo. Para MLP, alteramos a taxa
de aprendizado (LearningRate) que controla o quanto o modelo muda em resposta ao erro
estimado a cada atualização de pesos, e o momento (Momentum) que é o parâmetro res-
ponsável por mudar o tamanho dos passos para tentar escapar dos erros mı́nimos locais.
Para Naive Bayes se escolhe se ele vai ou não usar um estimador de kernel (UseKerne-
lEstimator), ao invés de tentar normalizar os atributos, e se ele vai ou não discretizar
os dados não nominais (UseSupervisedDiscretization). E, por fim, para o RandomForest,
mudamos a quantidade de árvores (NumIterations), e a semente (Seed) para a geração
aleatória das árvores. Os demais hiper parâmetros foram mantidos com valores fixos.
-
29
5 EXPERIMENTOS E ANÁLISE DE RESULTADOS
5.1 Base de dados
A base de dados utilizada, foi a preenchida no trabalho [3]. Para a alimentação
dela foi necessário controlar os elementos contextuais, tais como: largura de banda, CPU
do smartphone, CPU da nuvem, o próprio smartphone, o tamanho dos dados a serem
transmitidos e a aplicação. A cada faixa de dados numéricos (contexto de baixo ńıvel)
desses elementos associou-se um dado nominal (contexto de alto ńıvel), a Tabela 2 mostra
este mapeamento. Foram feitos diversos testes emṕıricos para definir a faixa de valores
dos atributos 1, 3 e 5 [3]; Para os atributos 2 e 4 as faixas foram escolhidas de acordo
com os resultados de pesquisas feitas pelos autores de [3]. Por exemplo, para definir os
limites de memória RAM e velocidade de clock, utilizou-se uma biblioteca que analisa as
especificações do dispositivo.
Por fim, para cada variação contextual, i.e. para cada combinação de valores con-
textuais comparou-se o QoS da aplicação executada localmente ou utilizando a técnica de
offloading computacional. O QoS da aplicação foi medido através do tempo de execução.
Caso o tempo de execução na nuvem fosse igual ou menor ao tempo local, classifica-se
aquele contexto com o rótulo ’SIM’ - é melhor fazer offloading neste contexto. Caso
contrário, com ’NAO’ - indicando que é melhor executar essa tarefa localmente nesta
situação.
-
30
Tabela 2 Atributos e valores contextuais.
Núm Nome do atributo Contexto baixo ńıvel Contexto de alto ńıvel
1 Largura de Banda
[up/down>20] Livre
[2
-
31
planeja-se comparar todos os algoritmos entre si e os testes estat́ısticos utilizados exigem
2 ou mais amostras. Então cada resultado para cada semente é usado como uma amostra
daquele classificador.
Várias métricas, como a taxa de negativos verdadeiros (especificidade), taxa de
positivos verdadeiros ( sensitividade), taxa de falso positivo(FPR) e negativo(FNR), pre-
cisão e acurácia da classificação das classes de acordo com as fórmulas (5.1)-(5.7) descritas
abaixo:
Acurácia =TP + TN
TP + TN + FP + FN(5.1)
F1 =2TP
2TP + FP + FN(5.2)
Sensitividade = TPR =TP
TP + FN(5.3)
Especificidade = TNR =TN
TN + FP(5.4)
Precisão =TP
TP + FP(5.5)
FPR =FP
FP + TN= 1− TNR (5.6)
FNR =FN
FN + TP= 1− TPR (5.7)
Onde:
TP = O número de exemplos positivos classificados corretamente.
TN = O número de exemplos negativos classificados corretamente.
FP = O número de exemplos classificados erroneamente como positivos.
FN = O número de exemplos classificados erroneamente como negativos.
A acurácia de um classificador é indicado pela porcentagem do conjunto de dados
-
32
que foi classificado corretamente. A sensitividade mede a taxa em que os exemplos são
classificados positivamente, nos casos em que se deveria classificar positivamente. En-
quanto Especificidade mede a taxa em que os exemplos são classificados negativamente,
em caso em que se deveria classificar negativamente. Precisão é a fração dos exemplos
positivos classificados como positivos do grupo de todos os exemplos classificados como
positivos. Sensitividade e precisão são resumidas por outra métrica conhecida como
F1 (ver formula (5.2)). E FPR (5.6) e FNR (5.7) são respectivamente ’1 - Sensitivi-
dade’ e ’1 - Especificidade’, e representam a proporção de exemplos positivos e negativos
classificados erroneamente [52].
5.3 Comparação
Tendo os classificadores ajustados, treinados e testados, vamos comparar os re-
sultados de cada um deles de forma a criar um ranque entre os algoritmos, verificando
se há diferenças estat́ısticas entre cada um deles. Segundo Demsar [53], os testes mais
adequados para comparar acurácia de classificadores são os não-paramétricos. Dos testes
apresentados, podemos usar o teste de Wilcoxon ou o de Friedman. O teste de Wilcoxon
apresenta bons resultados quando se está comparando algoritmos treinados em bases di-
ferentes, que não é o nosso caso, já que as acurácias de cada fold da validação cruzada
não são completamente independentes. O teste de Friedman é um teste não-paramétrico
equivalente ao ANOVA com medidas repetidas [3,53], que ranqueia os resultados dos algo-
ritmos de forma diretamente proporcional para a acurácia do resultado de cada validação
cruzada. Após isso calcula-se a soma dos ranques e a média deles para cada algoritmo.
Usamos essa soma dos ranques para rejeitar ou não a hipótese nula de que há uma dife-
rença significativa entre esses algoritmos. Em [3], foi utilizado o teste de Friedman com o
pós teste Nemenyi para criar um ranque entre os algoritmos, e [53–55] mostram que esse
realmente é o melhor teste para nosso caso.
Sendo assim, usando a biblioteca javaNPST, Non Parametric Statistical Tests in
java [56] (Testes estat́ısticos não-paramétricos em java), podemos aplicar o teste de Fri-
edman com 95% de intervalo de confiança. Após aplicar o teste, vimos que a hipótese
nula foi rejeitada comprovando que existem diferenças significativas entre esses algorit-
mos. Na Tabela 3 podemos ver o resultados das somas e das médias dos ranques para
cada algoritmo:
-
33
Tabela 3 Resultados FriedmanAlgoritmo de classificação
RF MLP1 MLP3 NAIVE IBK J48 JRIP SMOpoly SMOrbf
Soma dos ranques 231,5 142,5 170 67 92,5 241,5 242 67,5 95,5
Média dos ranques 7,72 4,75 5,67 2,23 3,08 8,05 8,07 2,25 3,18
Desvio padrão dos ranks 1,60 2,69 2,02 1,79 2,19 1,57 1,24 2,28 2,59
No qual:
RF = Random Forest.
MLP1 = Perceptron multi camada, ou Multilayer Perceptron, com 1 camada escondida.
MLP3 = Perceptron multi camada, ou Multilayer Perceptron, com 3 camadas
escondida.
NAIVE = Naive Bayes.
IBk = Aprendiz baseado em instâncias, ou Instance-based learner, que usa o algoritmo
dos k vizinhos mais próximos, ou KNN do inglês k-nearest neighbors.
J48 = Implementação de código aberto em Java do algoritmo de árvore de decisão C4.5.
JRIP = Implementação em java do algoritmo de regras Podagem Incremental Repetida
para Produzir Redução do Erro, ou RIPPER do inglês, Repeated Incremental Pruning to
Produce Error Reduction.
SMOpoly = Algoritmo de otimização mı́nima sequencial de John Platt usado para
treinar uma SVM (Support Vector Machine) comum, usando um kernel polinomial.
SMOrbf = Algoritmo de otimização mı́nima sequencial de John Platt usado para
treinar uma SVM (Support Vector Machine) comum, usando um kernel de funções de
base radial.
Depois disso aplicamos o pós teste de Nemenyi usando o procedimento de múltiplas
comparações para analisar os pares dos algoritmos e montarmos um outro ranque, dessa
vez do número 1 ao 10, onde o ranque 1 é o melhor algoritmo e o 10 o pior. Para a
montagem do novo ranque, utilizamos apenas a soma dos ranques do teste de Friedman,
ordenando-o, onde os algoritmos com a maior soma são os melhores. O teste de Nemenyi
é aplicado em cada dupla de algoritmos com o objetivo de afirmar se a diferença entre os
valores da soma dos ranques são estatisticamente diferentes. Para isso, um valor cŕıtico
é calculado, apresentado na tabela a seguir como CV, critical value. Caso os valores
não sejam estatisticamente diferentes, os algoritmos podem compartilhar a mesma
-
34
posição no ranque. Os resultados podem ser analisados na tabela a seguir:
Tabela 4 Resultados Nemenyi
Algoritmo de classificação
J48 JRIP RF MLP3 MLP1 SMOrbf IBK SMOpoly NAIVE CV
Ranque 1 1 1 2 2 3 3 3 3 2.26
Friedman 8,07 8,05 7,72 5,67 4,75 3,18 3,08 2,25 2,24 -
Tempo treino(ms) 217 4028 4552 57929 26838 1238 597 1505 419 -
Tempo teste(ms) 9 589 1776 10026 4388 254 18 2262 3 -
Tamanho (bytes) 501 521 1471 2452 2446 1680 1278 1676 506 -
A Tabela 4, informa, além do novo ranque, da soma média do ranque de Friedman
e do valor cŕıtico utilizado nas comparações, o tempo para ajustar e treinar cada algoritmo
e o tempo médio para testar o modelo. Os tempos foram medidos em milissegundos. Além
disso, também se apresenta o tamanho em bytes que cada modelo ocuparia no cliente em
que seria implantado.
Os resultados foram similares ao trabalho passado, com os algoritmos J48, JRIP
e RandomForest empatando em primeiro lugar como os mais acurados. Já era esperado
que o Random Forest entregasse um bom resultado, pois, como explicado, esse algoritmo
é uma coletânea de árvores de decisão, e no trabalho passado a árvore de decisão (J48) foi
o algoritmo mais acurado. Porém isso não instantaneamente faz desse algoritmo a melhor
escolha sobre a árvore de decisão comum (J48). O principal diferencial do RF é suprir
o problema do sobre-ajuste, da instabilidade da árvore. Para nossos testes, como nosso
banco de dados é pequeno, a árvore de decisão se encontra estável e tem um menor custo
de recursos, já que consome em média 197 vezes menos tempo para testes, ou classificação
de instâncias (ocorrem com frequência no cliente) e ocupam 2.9 vezes menos espaço.
Acredita-se que os resultados são, em parte, consequência do tamanho da base de
dados. Tanto os MLPs quanto as SVMs tiveram um resultado ruim, se comparados com
os algoritmos baseados em árvores de decisão ou regras. Levando em conta que eles são
mais custosos para serem implementados, já que demoram milhares ou centenas de vezes
mais para treinar e testar, e seus modelos ocupam muito mais espaço que os algoritmos
mais simples, isso os torna opções inadequadas para este problema. Além disso, tanto os
MLPs quanto as SVMs, tiveram um ranque menor que as estratégias mais simples.
-
35
6 CONCLUSÃO E TRABALHOS FUTUROS
Este trabalho apresentou um novo comparativo de diversos algoritmos de apren-
dizagem de máquina: J48, JRIP, NAIVE BAYES, IBk, RandomForest, SMO, MLP, jun-
tamente com a aplicação AlgorithmCompare que automatizou o tuning, o treinamento,
o teste e a comparação desses algoritmos. O programa pode ser utilizado para qualquer
banco de dados, mas nesse trabalho ele foi utilizado apenas com os dados adquiridos
em [3], pois o foco aqui foi encontrar o algoritmo mais adequado para montagem de um
sistema de offloading senśıvel ao contexto.
Esse software, AlgorithmCompare, de forma robusta utiliza da biblioteca Weka
para otimizar (tuning), treinar e testar uma gama de algoritmos bem maior do que outros
frameworks similares apresentados na literatura. E é bastante simples adicionar novos
algoritmos ou diferentes versões de outros algoritmos nesse software, caso necessário. Para
comparar os algoritmos, foi estendido a classe que implementa o teste de Friedman e de
Nemenyi da biblioteca javaNPTS [56].
Os principais algoritmos introduzidos neste trabalho foram MLP, RandomForest
e SVM (SMO). O RandomForest foi introduzido pois, no trabalho passado, os melho-
res algoritmos foram os baseados em árvore de decisão e seria interessante verificar se
RandomForest teria um resultado melhor ou similar quando comparado a J48. SVM foi
introduzido pela sua robustez e flexibilidade. Acreditava-se que ela poderia ser uma boa
opção para este problema e o MLP também foi considerado devido ao seu relacionamento
com SVMs [22] e com Deep Learning.
Com a introdução desses novos algoritmos surgiu a necessidade de fazer o tuning
deles também de forma automatizada. Foi adicionado então um grid search na aplicação
do AlgorithmCompare com o intuito de escolher melhor os hiper parâmetros de cada um
dos algoritmos que estamos treinando. Para os testes, foi feita validação cruzada para cada
algoritmo, variando a semente de 1 a 30. Para a comparação automática se viu necessária
a execução de testes estat́ısticos em java. Para isso usamos a biblioteca javaNPST.
Os testes implementados em AlgorithmCompare foram os de Friedman, Wilcoxon e
Nemenyi. Mas nesse trabalho, utilizamos apenas o de Friedman seguido pelo de Nemenyi.
Com esses testes estat́ısticos foi gerado um rank dos melhores algoritmos.
Os três melhores algoritmos foram J48, JRIP e RandomForest. RandomForest foi
-
36
um algoritmo que entregou um bom resultado, se equiparando estatisticamente com J48
e o JRIP. Porém, por ser um algoritmo mais complexo, ele ocupa mais espaço e demora
mais para treinar e classificar instâncias. Além disso, tanto as SVMs quanto os MLPs
testados não obtiveram um bom resultado se comparados com as estratégias mais simples,
baseadas em regras e árvore de decisão. SVMs e MLPs demoram ainda mais para treinar
e classificar instâncias e seus modelos treinados são os maiores (em bytes) de todos os
algoritmos testados, ocupando mais espaço no armazenamento do cliente. E além disso
sua acurácia foi inferior aos outros algoritmos. Acredita-se que esses resultados são, em
parte, consequência do tamanho da base de dados. A base de dados adquirida em [3] é
considerada muito pequena, e possui apenas 302 exemplos devido ao fato que cada um
desses exemplos foi adquirido com testes manuais no mundo real.
Em trabalhos futuros, os dados poderão ser adquiridos de forma mais automática,
sem necessariamente controlar todos os aspectos contextuais para a alimentação desse
banco. Assim, mesmo que o banco de dados fique um pouco desbalanceado (entre as clas-
ses ’SIM’ e ’NAO’), seria posśıvel trabalhar com mais dados e obter classificadores capazes
de lidar melhor com o mundo real. Automatizando o controle contextual, também seria
posśıvel executar um determinado dado vindo do cliente para sua classe complementar e,
posteriormente, alimentar os algoritmos com os novos dados. Por exemplo, caso o cliente
enviasse um dado em que ele decidiu executar na nuvem, e enviasse dados como o QoS
da aplicação para aquela tarefa e o seu gasto energético, poderia-se executar esse dado
localmente, em um aparelho virtual simulando as caracteŕısticas no cliente, comparando
o QoS e o gasto energético para decidir se aquele contexto é adicionado a base como um
contexto da classe ”SIM”, é vantajoso fazer offloading, ou ”NAO”, não é vantajoso.
-
37
REFERÊNCIAS
[1] FLORES, H. et al. Mobile code offloading: from concept to practice and beyond. IEEE
Communications Magazine, v. 53, n. 3, p. 80–88, mar 2015. ISSN 0163-6804.
[2] JUNIOR, W. et al. Supporting mobility-aware computational offloading in mobile
cloud environment. Journal of Network and Computer Applications, Elsevier Ltd, v. 94,
n. July, p. 93–108, sep 2017. ISSN 10848045.
[3] JUNIOR, W. et al. A context-sensitive offloading system using machine-learning
classification algorithms for mobile cloud environment. Future Generation Com-
puter Systems, v. 90, p. 503 – 520, 2019. ISSN 0167-739X. Available at:
.
[4] FERNANDO, N.; LOKE, S. W.; RAHAYU, W. Mobile cloud computing: A survey.
Future Generation Computer Systems, Elsevier B.V., v. 29, n. 1, p. 84–106, jan 2013.
ISSN 0167739X.
[5] FLORES, H. et al. Social-aware hybrid mobile offloading. Pervasive and Mobile Com-
puting, v. 36, p. 25–43, apr 2017. ISSN 15741192.
[6] BETTINI, C. et al. A survey of context modelling and reasoning techniques. Pervasive
and Mobile Computing, Elsevier B.V., v. 6, n. 2, p. 161–180, 2010. ISSN 15741192.
[7] ABOWD, G. D. et al. Towards a better understanding of context and context-
awareness. In: Proceedings of the 1st International Symposium on Handheld and Ubi-
quitous Computing. London, UK, UK: Springer-Verlag, 1999. (HUC ’99), p. 304–307.
ISBN 3-540-66550-1.
[8] KOSTA, S. et al. ThinkAir: Dynamic resource allocation and parallel execution in the
cloud for mobile code offloading. In: 2012 Proceedings IEEE INFOCOM. [S.l.]: IEEE,
2012. p. 945–953. ISBN 978-1-4673-0775-8. ISSN 0743166X.
[9] MAJEED, A. A. et al. Code offloading using support vector machine. In: 2016
Sixth International Conference on Innovative Computing Technology (INTECH). [S.l.]:
IEEE, 2016. p. 98–103. ISBN 978-1-5090-2000-3.
-
38
[10] FERRARI, A.; GIORDANO, S.; PUCCINELLI, D. Reducing your local footprint
with anyrun computing. Computer Communications, Elsevier B.V., v. 81, p. 1–11, may
2016. ISSN 01403664.
[11] REGO, P. A. L. et al. Decision Tree-Based Approaches for Handling Offloading De-
cisions and Performing Adaptive Monitoring in MCC Systems. In: 2017 5th IEEE
International Conference on Mobile Cloud Computing, Services, and Engineering (Mo-
bileCloud). [S.l.]: IEEE, 2017. p. 74–81. ISBN 978-1-5090-6325-3.
[12] HUANG, D.; WANG, P.; NIYATO, D. A Dynamic Offloading Algorithm for Mobile
Computing. v. 11, n. 6, p. 1991–1995, 2012.
[13] WANG, Q. et al. Mobile Healthcare Systems with Multi-cloud Mobile Healthcare
Systems with Multi-cloud Offloading. n. June, 2013.
[14] WANG, Z. et al. Bus-Based Content Offloading for Vehicular Networks. v. 19, n. 3,
p. 250–258, 2017.
[15] MERSHAD, K. SCORE : Data Scheduling at Roadside Units in Vehicle Ad Hoc
Networks. n. Ict, p. 0–5, 2012.
[16] ARCHITECTURES, S. et al. A Survey on Mobile Social Networks : and Future
Research Directions. v. 17, n. 3, p. 1557–1581, 2015.
[17] QIU, J. et al. A survey of machine learning for big data processing. EURASIP Journal
on Advances in Signal Processing, EURASIP Journal on Advances in Signal Processing,
2016. ISSN 1687-6180.
[18] KOTSIANTIS, S. B. Supervised Machine Learning : A Review of Classification
Techniques. v. 31, p. 249–268, 2007.
[19] DOMINGOS, P. A few useful things to know about machine learning. Communica-
tions of the ACM, v. 55, n. 10, p. 78, 2012. ISSN 00010782.
[20] DAS, K.; BEHERA, R. N. A Survey on Machine Learning : Concept ,. p. 1301–1309,
2017.
-
39
[21] ROKACH, L.; MAIMON, O. Top-Down Induction of Decision Trees Classifiers—A
Survey. IEEE Transactions on Systems, Man and Cybernetics, Part C (Applications
and Reviews), v. 35, n. 4, p. 476–487, 2005. ISSN 1094-6977.
[22] COLLOBERT, R.; BENGIO, S. Links between perceptrons, mlps and svms. In:
ACM. Proceedings of the twenty-first international conference on Machine learning.
[S.l.], 2004. p. 23.
[23] BHATIA, N.; AUTHOR, C. Survey of Nearest Neighbor Techniques. IJCSIS) Inter-
national Journal of Computer Science and Information Security, v. 8, n. 2, p. 302–305,
2010. ISSN 1098-6596.
[24] AHA, D.; KIBLER, D. Instance-based learning algorithms. Machine Learning, v. 6,
p. 37–66, 1991.
[25] WU, X. et al. Top 10 algorithms in data mining. Knowledge and information systems,
Springer, v. 14, n. 1, p. 1–37, 2008.
[26] ARCHANA, S.; ELANGOVAN, K. Survey of Classification Techniques in Data Mi-
ning. International Journal of Computer Science and Mobile Applications, v. 2, n. 2,
p. 65–71, 2014. ISSN 2321-8363.
[27] KEOGH, E. Näıve Bayes Classifier. 2006. ISSN 13652753.
[28] PAGALLO, G.; HAUSSLER, D. Boolean Feature Discovery in Empirical Learning.
Machine Learning, v. 5, n. 1, p. 71–99, 1990. ISSN 15730565.
[29] BREIMAN, L. Random forests. Machine learning, Springer, v. 45, n. 1, p. 5–32,
2001.
[30] RODRIGUEZ-GALIANO, V. F. et al. An assessment of the effectiveness of a random
forest classifier for land-cover classification. ISPRS Journal of Photogrammetry and
Remote Sensing, Elsevier, v. 67, p. 93–104, 2012.
[31] HO, T. K. Random decision forests. In: IEEE. Proceedings of 3rd international con-
ference on document analysis and recognition. [S.l.], 1995. v. 1, p. 278–282.
-
40
[32] JOACHIMS, T. Text categorization with support vector machines: Learning with
many relevant features. In: SPRINGER. European conference on machine learning.
[S.l.], 1998. p. 137–142.
[33] NOBLE, W. S. What is a support vector machine? Nature biotechnology, Nature
Publishing Group, v. 24, n. 12, p. 1565, 2006.
[34] HSU, C.-W. et al. A practical guide to support vector classification. Taipei, 2003.
[35] AURIA, L.; MORO, R. A. Support vector machines (svm) as a technique for solvency
analysis. 2008.
[36] LEWIS, D. P.; JEBARA, T.; NOBLE, W. S. Support vector machine learning from
heterogeneous data: an empirical analysis using protein sequence and structure. Bioin-
formatics, Oxford University Press, v. 22, n. 22, p. 2753–2760, 2006.
[37] FERNÁNDEZ-DELGADO, M. et al. Do we need hundreds of classifiers to solve real
world classification problems? The Journal of Machine Learning Research, JMLR. org,
v. 15, n. 1, p. 3133–3181, 2014.
[38] SAHOO, G.; KUMAR, Y. Analysis of parametric & non parametric classifiers for
classification technique using weka. International Journal of Information Technology
and Computer Science (IJITCS), v. 4, n. 7, p. 43, 2012.
[39] COHEN, W. Fast effective rule induction. Twelfth International Conference on Ma-
chine Learning, p. 115–123, 1995.
[40] ENGG, S.; SCIENCE, C. Survey on Classification Methods using WEKA. v. 86,
n. 18, p. 16–19, 2014.
[41] LORENA, A. C. et al. Comparing machine learning classifiers in potential distribu-
tion modelling. Expert Systems with Applications, Elsevier, v. 38, n. 5, p. 5268–5275,
2011.
[42] DUMA, M. et al. Improving the Performance of the Ripper in Insurance Risk Clas-
sification : a Comparitive Study Using Feature Selection. Electrical Engineering, 2010.
-
41
[43] KHAN, A. u. R. et al. MobiByte: An Application Development Model for Mobile
Cloud Computing. Journal of Grid Computing, v. 13, n. 4, p. 605–628, dec 2015. ISSN
1570-7873.
[44] Ting-Yi Lin et al. Context-aware decision engine for mobile cloud offloading. In: 2013
IEEE Wireless Communications and Networking Conference Workshops (WCNCW).
[S.l.]: IEEE, 2013. p. 111–116. ISBN 978-1-4799-0110-4.
[45] KWON, Y. et al. Precise execution offloading for applications with dynamic behavior
in mobile cloud computing. Pervasive and Mobile Computing, v. 27, p. 58–74, 2016.
ISSN 15741192.
[46] GHASEMI-FALAVARJANI, S.; NEMATBAKHSH, M.; Shahgholi Ghahfarokhi, B.
Context-aware multi-objective resource allocation in mobile cloud. Computers & Elec-
trical Engineering, Elsevier, v. 44, p. 218–240, may 2015. ISSN 00457906.
[47] ZHOU, B. et al. mCloud: A Context-aware Offloading Framework for Heterogeneous
Mobile Cloud. IEEE Transactions on Services Computing, PP, n. 99, p. 1–1, 2015. ISSN
1939-1374.
[48] CUERVO, E. et al. MAUI : Making Smartphones Last Longer with Code Offload. In:
8th international conference on Mobile systems, applications, and services. [S.l.: s.n.],
2010. p. 49–62. ISBN 9781605589855.
[49] FLORES, H.; SRIRAMA, S. Adaptive code offloading for mobile cloud applications:
Exploiting fuzzy sets and evidence-based learning. MCS ’13, p. 9–16, 2013.
[50] HWANG, C.-L.; LAI, Y.-J.; LIU, T.-Y. A new approach for multiple objective deci-
sion making. Computers & operations research, Elsevier, v. 20, n. 8, p. 889–899, 1993.
[51] VIOLA, P.; JONES, M. et al. Rapid object detection using a boosted cascade of
simple features. CVPR (1), v. 1, p. 511–518, 2001.
[52] WENG, C.-H.; HUANG, T. C.-K.; HAN, R.-P. Disease prediction with different
types of neural network classifiers. Telematics and Informatics, Elsevier, v. 33, n. 2, p.
277–292, 2016.
-
42
[53] DEMŠAR, J. Statistical comparisons of classifiers over multiple data sets. Journal of
Machine learning research, v. 7, n. Jan, p. 1–30, 2006.
[54] FRIEDMAN, M. The use of ranks to avoid the assumption of normality implicit in
the analysis of variance. Journal of the American Statistical Association, v. 32, n. 200,
p. 675–701, 1937.
[55] FRIEDMAN, M. A comparison of alternative tests of significance for the pro-
blem of m rankings. The Annals of Mathematical Statistics, Institute of Mathe-
matical Statistics, v. 11, n. 1, p. 86–92, 1940. ISSN 00034851. Available at:
.
[56] DERRAC, J.; GARCÍA, S.; HERRERA, F. Javanpst: Nonparametric statistical tests
in java. arXiv preprint arXiv:1501.04222, 2015.
introduçãoFundamentosSistema de offloading sensível ao contextoAlgoritmos de classificação
Trabalhos RelacionadosSOLUÇÃO PROPOSTABenchFaceAlgorithmCompareTuning
EXPERIMENTOS E ANÁLISE DE RESULTADOSBase de dadosTreinamento e testeComparação
CONCLUSÃO E TRABALHOS FUTUROS