HENRIQUE VENEZIANO GUISASOLARAFAEL CAMARGOS SANTOS
SMARTAD - FERRAMENTA DE MARKETINGMOBILE DIRECIONADO
São Paulo2018
HENRIQUE VENEZIANO GUISASOLARAFAEL CAMARGOS SANTOS
SMARTAD - FERRAMENTA DE MARKETINGMOBILE DIRECIONADO
Trabalho apresentado à Escola Politécnica
da Universidade de São Paulo para obtenção
do T́ıtulo de Engenheiro da Computação.
São Paulo2018
HENRIQUE VENEZIANO GUISASOLARAFAEL CAMARGOS SANTOS
SMARTAD - FERRAMENTA DE MARKETINGMOBILE DIRECIONADO
Trabalho apresentado à Escola Politécnica
da Universidade de São Paulo para obtenção
do T́ıtulo de Engenheiro da Computação.
Orientador:
Jorge Luis Risco Becerra
São Paulo2018
RESUMO
Dentro do universo de marketing e propaganda aumentar a conversão de um anúnciose torna uma necessidade cada vez maior, quanto mais eficiente for uma campanha publi-citária, maior a conversão de vendas de determinado produto. Aliado a isso tem-se áreade marketing mobile crescendo cada vez mais, e a maioria das plataformas de marketingmobile não utilizam de métodos de sugestão direcionada para mostrar propagandas aosusuários de smartphones.
Este projeto visa melhorar o cenário desse problema, ou seja, desenvolver uma plata-forma, utilizando tecnologias de inteligência artificial e algoritmos de buscas otimizadaspara sugerir propagandas direcionadas a um determinado usuário a partir das informaçõesde localização e das fotos que o usuário tiradas dentro de aplicativos mobile.
Para isso as fotos dos usuários são classificadas dentro de categorias pré determina-das com uma precisão de 80% e com essas informações, utilizando algoritmos de busca,propagandas que mais se aproximam do perfil do usuário são buscadas e enviadas para ousuário.
Palavras-Chave – marketing mobile, inteligência artificial, propagandas direciona-das, algoritmos de busca
ABSTRACT
Within the universe of marketing and advertising increasing the conversion of an adbecomes an increasing need, the more efficient an advertising campaign, the greater theconversion of sales of a particular product. Associated to this is the mobile marketing areais growing more and more, and most mobile marketing platforms do not use suggestiondirected methods to show advertisements to smartphone users.
This project aims to improve the scenario of this problem, that is, to develop a plat-form, using artificial intelligence technologies and optimized search algorithms to suggesttargeted advertisements to a given user using the location information and photos thatthe user takes within mobile applications.
For this, user photos are classified within predetermined categories with an accuracyof 80% and with this information, using search algorithms, advertisements that mostclosely approximate the user profile are searched and sent to the user.
Keywords – mobile marketing, artificial intelligence, targeted advertisements, searchalgorithms
LISTA DE FIGURAS
1 Percentual de pessoas utilizando smartphones no mundo . . . . . . . . . . 11
2 Gráfico de iterações do algoritmo K-Means . . . . . . . . . . . . . . . . . . 18
3 Processo de negócio do projeto . . . . . . . . . . . . . . . . . . . . . . . . . 32
4 Diagrama de Entidade e Relacionamento . . . . . . . . . . . . . . . . . . . 34
5 Diagrama da NIST SP 800-145 . . . . . . . . . . . . . . . . . . . . . . . . 35
6 Diagrama da arquitetura em camadas do sistema . . . . . . . . . . . . . . 37
7 Diagrama da arquitetura de serviços . . . . . . . . . . . . . . . . . . . . . 40
8 Diagrama do fluxo do módulo de classificação . . . . . . . . . . . . . . . . 43
9 Diagrama do fluxo do módulo de sugestão . . . . . . . . . . . . . . . . . . 48
10 Fórmula para o cálculo do score de um documento no Elasticsearch . . . . 53
11 Tela do feed de propagandas . . . . . . . . . . . . . . . . . . . . . . . . . . 54
12 Tela de upload de fotos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
13 Tela de galeria de fotos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
SUMÁRIO
Parte I: INTRODUÇÃO 9
1 Introdução 10
1.1 Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.2 Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.3 Justificativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.4 Estrutura do trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Parte II: DESENVOLVIMENTO 13
2 Aspectos Conceituais 14
2.1 Marketing Digital . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.1.1 Segmentação de mercado . . . . . . . . . . . . . . . . . . . . . . . . 14
2.1.2 Marketing Inviśıvel . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2 Inteligência Artificial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3 Machine Learning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.4 Algoritmos de Classificação . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.4.1 K-Means . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.5 Deep Learning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.6 Visão Computacional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.7 Cloud Computing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.7.1 IaaS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.7.2 FaaS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.8 Serverless . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3 Tecnologias Utilizadas 21
3.1 Elasticsearch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.2 API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.3 HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.4 Javascript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.5 Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.6 AWS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.6.1 Rekognition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.6.2 Sagemaker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.6.3 Lambda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.6.4 DynamoDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.6.5 API Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.6.6 S3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.6.7 Elasticsearch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.6.8 EC2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4 Metodologia de Trabalho 29
4.1 Estudos de Inteligência Artificial . . . . . . . . . . . . . . . . . . . . . . . . 29
4.2 Planejamento de arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.3 Implementação Rekognition . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.4 Implementação Elasticsearch . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.5 Treinamento do modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.6 Criação e integração do aplicativo . . . . . . . . . . . . . . . . . . . . . . . 30
5 Especificação de Requisitos do Sistema 31
5.1 Visão Empresa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.2 Visão Informação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.3 Visão Computação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.3.1 Arquitetura de Referência . . . . . . . . . . . . . . . . . . . . . . . 34
5.3.2 Arquitetura da Visão Computação . . . . . . . . . . . . . . . . . . 36
5.3.3 Aplicação da Clean Architecture . . . . . . . . . . . . . . . . . . . . 37
5.4 Visão Engenharia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.5 Visão Tecnologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.5.1 Backend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.5.1.1 Serverless . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.5.1.2 Node.js . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.5.2 Frontend Mobile . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.5.3 Frontend Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
6 Implementação 43
6.1 Módulo de classificação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
6.1.1 Configurações Rekognition . . . . . . . . . . . . . . . . . . . . . . . 43
6.1.2 Aquisição de dataset de imagens . . . . . . . . . . . . . . . . . . . . 44
6.1.3 Refinamento da sáıda do Rekognition . . . . . . . . . . . . . . . . . 45
6.1.4 Treinamento do modelo de classificação utilizando o Amazon Sage
Maker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
6.1.5 Estruturação de dados no DynamoDB . . . . . . . . . . . . . . . . 47
6.2 Módulo de sugestão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
6.2.1 Criação da API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
6.2.2 Configuração do Elasticsearch . . . . . . . . . . . . . . . . . . . . . 49
6.2.3 Criação de propagandas no Elasticsearch . . . . . . . . . . . . . . . 50
6.2.4 Query para busca de propagandas . . . . . . . . . . . . . . . . . . . 51
6.3 Módulo de demonstração (Aplicação mobile) . . . . . . . . . . . . . . . . . 53
6.3.1 Criação do projeto Java . . . . . . . . . . . . . . . . . . . . . . . . 53
6.3.2 Integração . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
7 Considerações Finais 58
7.1 Conclusões do Projeto de Formatura . . . . . . . . . . . . . . . . . . . . . 58
7.2 Contribuições . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
7.3 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Referências 61
PARTE I
INTRODUÇÃO
10
1 INTRODUÇÃO
1.1 Objetivo
O objetivo deste trabalho é, por meio do uso de tecnologias de estado da arte de
inteligência artificial e arquitetura de serviços, fornecer para o crescente mercado de mar-
keting digital uma solução de alta eficiência para segmentação de público e veiculação de
campanhas de marketing inviśıvel integrada a aplicações já existentes.
Para tal, se propõe desenvolver uma ferramenta de marketing mobile direcionado utili-
zando visão computacional para reconhecimento de locais e interesses em fotos do usuário
alimentando uma inteligência artificial treinada para agrupar as imagens em categorias
pré definidas e em seguida, usando ferramentas de busca, sugerir propagandas relevantes
aos usuários.
O intuito final do trabalho é fornecer uma ferramenta, através de uma biblioteca
para desenvolvimento android, que permite que diversas empresas implementem a nossa
ferramentas dentro de seus próprios aplicativos, melhorando a satisfação do usuário e do
anunciante.
1.2 Motivação
Na sociedade brasileira atual é muito comum ver pessoas entretidas por seus Smartpho-
nes. Seja na rua, no ônibus, nos restaurantes, as pessoas sempre estão com, pelo menos,
um Smartphone em sua posse.
No ińıcio de 2017, o estudo “Google Consumer Barometer”, mostrou que, em 2012,
14% da população brasileira tinha um Smartphone. Em 2016, esse número aumentou
para 62%, ou seja, em 5 anos, houve um aumento de 450%.
Atualmente o acesso a Internet é feito principalmente através de aparelhos celulares,
a utilização de aplicativos para facilitar a vida das pessoas ou simplesmente como forma
11
Figura 1: Percentual de pessoas utilizando smartphones no mundo
de entretenimento já se tornou algo cotidiano. Os smartphones já se tornaram parte da
vida da população, e assim como outras formas de entretenimento, grandes empresas têm
o desejo de explorar essa grande utilização dos smartphones para fazerem anúncios de
seus produtos.
É previsto um crescimento no investimento em marketing para smartphones de apro-
ximadamente 22% ao ano, de 2017 até 2023, chegando a marca de um investimento de
102 bilhões de dólares no ano de 2023. Todo esse investimento é normalmente utilizado
em plataformas de propaganda genéricas, sem o foco no cliente.
1.3 Justificativa
Com esse cenário de crescimento de marketing para smartphones é fácil justificar a
necessidade desse projeto, atualmente existem diversas empresas focadas no desenvolvi-
mento de plataforma para gerar propaganda e conteúdo personalizado. O Google é um
dos grandes competidores desse mercado, sendo responsável por boa parte do dinheiro
envolvido quando falamos sobre marketing digital.
Mesmo assim, não temos conhecimento de uma plataforma capaz de otimizar essa
geração de conteúdo, a maioria das plataformas de marketing utiliza uma quantidade
limitada de fatores para determinar o conteúdo que será visualizado pelo cliente final.
A ideia desse projeto é expandir esses limites aplicando conceitos de inteligência ar-
tificial como Visão Computacional e Machine Learning, ou seja, com a nossa plataforma
será posśıvel fornecer um conteúdo patrocinado de maior relevância para o usuário final,
12
essa solução é benéfica para os dois lados, dado que grandes empresas que contratam o
espaço de propaganda terão a certeza que os usuários atingidos por aquela propaganda
tem uma maior chance de adquirir o produto final.
Além disso é uma vantagem para o usuário que quando ver conteúdo patrocinado
provavelmente será algo de seu interesse e será relevante para o momento que o usuário
visualizar esse conteúdo.
1.4 Estrutura do trabalho
A seguir está descrita a organização do restante da monografia, mostrando o principal
objetivo de cada um do caṕıtulos.
O caṕıtulo 2 irá abordar os principais aspectos conceituais abordados no trabalho,
tanto do ponto de vista técnico quanto do ponto de vista de produto.
No caṕıtulo 3 serão apresentadas as principais tecnologias utilizadas no projeto, vi-
sando apresentar o funcionamento básico da tecnologia e sua aplicação no projeto.
No caṕıtulo 4 será explicada a metodologia usada para implementação do trabalho,
contando os principais passos tomados durante o trabalho e como o trabalho foi dis-
tribúıdo.
O caṕıtulo 5 apresentará as especificações técnicas do projeto, utilizando para isso o
Reference Model of Open Distributed Processing (RM-ODP).
Já o caṕıtulo 6 irá apresentar toda a implementação do projeto, passando pelos prin-
cipais problemas encontrados, as formas como o problema foi solucionado e os principais
resultados obtidos.
Finalmente o caṕıtulo 7 apresentará as considerações finais do grupo, tanto do ponto
vista técnico, pessoal e de produto.
PARTE II
DESENVOLVIMENTO
14
2 ASPECTOS CONCEITUAIS
2.1 Marketing Digital
Marketing Digital pode ser entendido como a divulgação de produtos e serviços utili-
zando meios digitais para atingir os consumidores. O objetivo principal a ser atingido é
a promoção de marcas por meio das diferentes formas de mı́dia digital dispońıveis.
O conceito tem se expandido na última década, incorporando marketing realizado por
meio de telefones celulares por SMS, mı́dias sociais, marketing de busca etc.
Atualmente, a maioria dos especialistas em marketing acreditam que o meio digital
tem caracteŕısticas e exigências muito diferentes dos demais canais de marketing. Com a
introdução de tecnologias disruptivas como os smartphones e outros devices com conexão
a internet, o consenso é que o entendimento do comportamento dos consumidores e seus
padrões de uso das plataformas que essas tecnologias proporcionam é um dos fatores mais
importantes para o sucesso do marketing digital.
Dentre os novos fatores levantados pelo segmento para otimização de campanhas no
contexto digital, esse projeto utiliza dois conceitos em evidência no mercado de marketing:
segmentação de mercado e marketing inviśıvel.
2.1.1 Segmentação de mercado
Um conceito bastante discutido, mesmo no contexto de marketing tradicional, a seg-
mentação de público, também chamada de segmentação de mercado, tornou-se fator fun-
damental no ambiente digital.
Pela forma como o modelo de negócios de veiculação de propagandas se estabeleceu na
internet, onde anunciantes pagam pelo alcance de suas divulgações, a otimização de cam-
panhas de marketing invariavelmente passa por um trabalho de segmentação de público
que determine qual a fatia de usuários está mais propensa a comprar o seu produto. Para
15
atingir tal objetivo, aspectos demográficos, geográficos, sociais e econômicos são inferidos
a partir de padrões comportamentais dos usuários.
No caso desse projeto, a aplicação desse conceito se dará pela identificação de usuários
com categorias de anúncios por meio da classificação das suas fotos. Tal estratégia apre-
senta a vantagem de se basear em um conjunto de dados, fotos tiradas pelo próprio usuário,
que tem alta correlação com padrões de compra e facilita a identificação de interesses dos
usuários.
2.1.2 Marketing Inviśıvel
Com a popularização da internet e de tecnologias disruptivas como os smartphones, o
mercado de marketing rapidamente buscou ocupar as plataformas utilizadas pelos usuários
diariamente. Navegando por redes sociais, portais de not́ıcias e sites de criadores de
conteúdo, o público dessas plataformas recebe uma quantidade enorme de campanhas de
divulgação de produtos e serviços, muitas vezes irrelevantes para esse usuário.
Dentro desse contexto e buscando evitar uma saturação e perda de relevância do
marketing no contexto digital, o conceito de marketing inviśıvel tem ganhado força no
mercado. O objetivo é integrar o marketing dentro dessas plataformas de maneira trans-
parente para o usuário, de maneira a tornar a visualização das campanhas o menos dis-
ruptiva posśıvel.
Uma estratégia comum e que foi explorada no desenvolvimento desse projeto é a de
integrar material promocional nos fluxos de uso das plataformas, por exemplo criando
campanhas de marketing que coexistam dentro do feed de not́ıcias do usuário como um
post comum, em meio às publicações de outros usuários.
2.2 Inteligência Artificial
O conceito de inteligência artificial(IA) é muito abrangente, diversos livros e artigos di-
vergem sobre uma definição concreta, tanta divergência levou a subdivisão da inteligência
artificial em diferentes áreas de pesquisa como: processamento de linguagem natural, re-
presentação de conhecimento, racioćınio automatizado, visão computacional, robótica e
aprendizado de máquina.
Apesar de tantas divergências podemos explicar a IA como a forma de uma máquina
pensar ou atuar de forma humana ou racional, ou seja, se uma máquina é capaz de simular
16
comportamentos humanos como pensamento e atuar de forma a seguir uma lógica racional
ou humana podemos dizer que isso é inteligência artificial.
A cultura popular aborda isso de diversas formas, muitas vezes de forma exagerada e
de certa forma ainda distante da realidade, mas o conceito por trás é muito interessante
como analogia, a inteligência artificial tenta transformar máquinas em humanos, se um
robô consegue possuir tantas caracteŕısticas humanas, que se torna dif́ıcil diferenciar a
máquina de um humano podemos dizer que esse robô é realmente uma máquina ou na
verdade devemos considerá-lo como um humano?
2.3 Machine Learning
O conceito de aprendizado de máquina pode ser explicado como a criação de um
modelo que dado um conjunto de dados de entrada será capaz de fazer uma previsão de
outra variável do sistema, ou de uma sáıda do sistema. O aprendizado de máquina utiliza
algumas terminologias que serão bastante comuns durante a apresentação do trabalho:
• Label: Uma label é considerada como a variável dentro do problema que será des-coberta, ou seja, o ponto que será previsto pela máquina.
• Feature: São todas as variáveis de entrada do problema, ou seja, todos os dados quedevem ser usados para prever o resultado de uma Label.
• Modelo: Um modelo define a relação entre as label e features, e pode ser divididoem duas etapas, o treinamento e a dedução. No treinamento, o modelo conhece o
valor tanto das Labels quanto das Features, e com isso é mostrado para o modelo
a relação entre as variáveis. Depois vem a etapa de dedução, onde as Labels não
são conhecidas, mas o modelo já é capaz de inferir o resultado a partir das Features
apresentadas para ele.
Durante o projeto será criado um modelo capaz de sugerir propagandas para um
usuário, ou seja, dado a entrada de um perfil de usuário, com várias Features como
idade, onde mora, locais que mais frequenta, rotina, etc, será gerada uma Label de qual
propaganda mais se aproxima do perfil do usuário.
17
2.4 Algoritmos de Classificação
Na raiz do modelo de sugestão está um algoritmo de classificação. No caso do sistema
apresentado aqui, será necessário determinar um algoritmo que, a partir das caracteŕısticas
levantadas sobre as fotos analisadas, as classifique em categorias pré-definidas de acordo
com os grupos de propagandas que serão exibidas.
Dentro do contexto de aprendizado de máquina, a operação de classificação é uma
técnica de aprendizado supervisionado na qual o programa aprende a partir de um con-
junto de dados e utiliza esse aprendizado para classificar um novo input dado a ele.
Algoritmos utilizando esse prinćıpio são comumente encontrados na literatura para so-
lucionar problemas do tipo: reconhecimento de linguagem natural, reconhecimento de
escrita manual, identificação biométrica etc.
Tendo em vista a amplitude de algoritmos que podem ser usados para a classificação,
a definição do algoritmo a ser utilizado passou pelo levantamento de vantagens e des-
vantagens na utilização de algumas das estratégias. Por fim, tendo em vista o tamanho
do nosso conjunto de dados de treinamento e capacidade computacional, optamos por
utilizar para esse projeto o algoritmo K-Means, descrito abaixo.
2.4.1 K-Means
O algoritmo k-means trabalha com um método iterativo simples para dividir um
conjunto de dados de entrada em um número k de clusters, definido pelo usuário. A
partir dessa organização, predições podem ser feitas ligando novos pontos de entrada a
proximidade a cada um dos clusters.
O conjunto inicial de dados é organizado em um conjunto de vetores de dimensão d, D
= xi — i = 1,..., N onde xi � d é o dado de ordem i. Para inicializar o algoritmo, devemos
escolher k pontos em d, que serão os centros iniciais dos clusters. Existem algumas técnicas
para selecionar esses pontos, incluindo a seleção ao acaso, selecionar a partir da resolução
do algoritmo para um conjunto filho do conjunto inicial ou partir da média do conjunto
e realizar k desvios em diferentes direções.
A partir de então, o algoritmo itera entre dois passos até a convergência:
• Atribuição dos dados
Cada ponto do conjunto de entrada é atribúıdo ao centro de cluster mais próximo.
Dessa forma, separamos os dados em subconjuntos.
18
• Realocação dos centros
Nessa etapa o centro de cada um dos k clusters é realocado a partir do cálculo da
média dos pontos que compõem o subconjunto desse cluster.
O algoritmo converge quando os pontos não mudam mais de clusters. Abaixo temos
uma representação visual do funcionamento do algoritmo com três clusters e vetores de
duas dimensões:
Figura 2: Gráfico de iterações do algoritmo K-Means
2.5 Deep Learning
O Deep Learning, ou aprendizagem profunda, é um ramo de algoritmos da inteligência
de máquina, baseado em um conjunto de algoritmos que tentam modelar abstrações de
alto ńıvel de dados usando um grafo profundo com várias camadas de processamento.
Softwares baseados no conceito de deep-learning tentam reproduzir o comportamento de
camadas de neurônios no neocórtex, a parte do cérebro onde o pensamento acontece. Com
esse modelo, algoritmos desse tipo aprendem a reconhecer padrões em sons, imagens e
outros tipos de dados. A ideia por trás desse conceito de rede neural já existe a algu-
mas décadas, no entanto avanços em formulações matemáticas e poder computacional
possibilitaram recentemente que redes neurais mais complexas fossem constrúıdas.
19
2.6 Visão Computacional
A visão computacional é uma das vertentes do deep learning que estuda como re-
construir, interpretar e compreender uma cena 3D a partir de imagens 2D em termos das
propriedades das estruturas presentes na cena. O principal objetivo da visão computa-
cional é modelar, replicar e mais importante exceder a visão humana usando software e
hardware em diferentes ńıveis.
A visão computacional é a construção de significativas descrições de objetos f́ısicos
de suas imagens. A sáıda de visão computacional é uma descrição, uma interpretação
ou alguma medida quantitativas das estruturas na cena 3D. Processamento de imagem e
reconhecimento de padrões estão entre muitas técnicas de visão computacional empregada
para atingir seus objetivos.
Dentro do contexto do projeto, a visão computacional será usada para categorizar as
imagens tiradas pelo usuário da aplicação, ou seja, iremos retirar uma descrição do local
da foto.
2.7 Cloud Computing
A computação na nuvem pode ser explicada como a entrega sob demanda de poder
computacional, armazenamento de dados e diversos serviços via Internet com um custo
conforme o uso. As principais vantagens da computação na nuvem são a facilidade de
integração dos serviços, a escalabilidade e o custo reduzido devido ao pagamento sobre o
uso, assim evitando gastos de poder computacional ocioso.
2.7.1 IaaS
O conceito de IaaS (Infrastructure as a Service) está ligado ao provisionamento de
estrutura computacional na forma de um serviço, ou seja, todo o hardware necessário
para executar um sistema é fornecido como um sistema.
Quando falamos de computação em nuvem esse é o conceito mais comum aplicado a
empresas devido a fácil migração de servidores f́ısicos para servidores na nuvem, o caso
de uso mais comum de utilização de servidores na nuvem são o de servidores dedicados
para operação de sistemas e sistemas de armazenamento de dados de larga escala.
20
2.7.2 FaaS
Já o conceito de FaaS (Function as a Service) vem ganhando força nos últimos anos,
com o lançamento de serviços especializados nesse conceito. No FaaS o serviço é contrato
para a execução de um função e o pagamento é feito apenas sobre o consumo da função
individual.
O FaaS trabalha juntamente com o conceito de aplicações stateless, ou seja, sua função
deve ser executada sem nenhum estado de servidor, e apenas com dados de entrada. As
principais vantagens do FaaS estão nos custos, foi você paga apenas pela utilização e é
fácil balancear o uso de diferentes funções, na computação mais tradicional isso é um
problema, pois não é fácil dividir um sistema de forma a não sobrecarregar uma parte
dele que está sendo mais requisitada.
2.8 Serverless
Apoiado no conceito de FaaS surge o conceito de Serverless, onde o intuito é a operação
de um sistema sem servidor, todas as funções do sistema ficam dispońıveis através de
funções stateless e são invocadas conforme a necessidade, esse tipo de arquitetura requer
a utilização de vários serviços em conjunto de forma a criar um rede de funções que
representa o sistema.
Os principais provedores de cloud da atualidade oferecem os principais serviços ne-
cessários para a implantação de uma arquitetura serverless, e com aux́ılio de frameworks
espećıficos é fácil criar e manter esses serviços sem grandes necessidades de manutenção
acompanhada.
As principais vantagens do serverless estão no custo, pois o valor gasto é apenas o
valor utilizado, não existe computação ociosa no serverless, a escalabilidade, garantida
pelos diversos serviços inerentes da arquitetura, e a facilidade de manutenção, os serviços
garantem o funcionamento do sistema, não é necessário contratação de pessoas para cuidar
do servidor e verificar quando é necessário contratar mais poder computacional.
21
3 TECNOLOGIAS UTILIZADAS
3.1 Elasticsearch
O Elasticsearch é um mecanismo de busca altamente escalável e open-source. Com
o Elasticsearch é posśıvel armazenar uma grande quantidade de dados, na ordem de
terabytes, e fazer busca em cima desses dados de forma rápida e escalável. O Elasticsearch
utiliza uma estrutura com uma API Rest para fazer a comunicação com o Apache Lucene,
que é responsável pelo motor de busca.
O Apache Lucene é responsável por armazenar os dados de forma indexada e realizar
as buscas desses dados. Ele funciona de forma tão eficiente pois todos os seus dados
armazenados são indexados, tornando a busca por termos muito eficiente, ou seja, com
ele é posśıvel buscar um conjunto de propagandas que esteja vinculado a determinadas
categorias, ou além disso, é posśıvel filtrar essas propagandas de acordo com distancia ou
com algum conteúdo espećıfico do anuncio.
O Lucene funciona de forma a separar todos os campos de um determinado documento
e indexar essas palavras de forma individual, com isso todos os termos do documento são
indexados de forma separada, tornando a busca tão rápida e precisa.
As buscas feitas com esse mecanismo são classificadas através de um score que é
calculado baseado na relevância dos resultados. Neste trabalho, o elasticsearch é usado
para fazer a busca de propagandas, o cálculo dos scores é feito em cima das categorias
pré-definidas e da distância do usuário para o anúncio.
3.2 API
API (Application Programming Interface), como o nome diz, é simplesmente uma
interface de comunicação entre várias aplicações. Podemos dizer que existe uma aplicação
pai, que é responsável por tratar de alguma lógica espećıfica, e aplicações filhas, que irão
22
consumir dessa aplicação pai.
Para facilitar o trabalho de desenvolvedores, foi criado o conceito de API, onde a
aplicação pai define uma interface de comunicação, ou seja, um protocolo que deve ser
seguido por todas as aplicações filhas que desejam usar as funcionalidades da aplicação
pai.
Para o desenvolvimento do trabalho foi utilizada um API do tipo REST. REST (RE-
presentational State Transfer) é uma abstração da arquitetura World Wide Web, é com-
posto por um estilo arquitetural que consiste em um conjunto de restrições a serem apli-
cados em um API, ou seja, REST nada mais é do que um conjunto de regras que uma
API deve seguir, um padrão para facilitar a comunicação entre desenvolvedores.
As principais regras impostas pelo REST são:
• Uso de protocolo HTTP (verbos, accept headers, códigos de estado HTTP, Content-Type) de forma expĺıcita e representativa para se comunicar, usando XML ou JSON
como forma de transferência de dados.
• Não possui estado entre essas comunicações.
• Deve facilitar o cache de conteúdo no cliente.
• Deve ter clara definição do que faz parte do cliente e do servidor.
Dada uma API REST é fácil entender o funcionamento do sistema e como utilizá-
lo pois a API irá seguir regras pré-estabelecidas e comuns a uma grande quantidade de
sistemas.
3.3 HTTP
O HTTP (Hypertext Transfer Protocol) é um protocolo de comunicação, na camada
de aplicação do modelo OSI utilizado para transferência de dados na World Wide Web.
Para que o protocolo HTTP consiga transferir seus dados pela Web, é necessário que os
protocolos TCP e IP (Internet Protocol, Protocolo de Internet) tornem posśıvel a conexão
entre clientes e servidores através de sockets TCP/IP.
Para garantir a segurança dentro da rede, foi utilizada uma extensão do protocolo
HTTP, o HTTPS. É o protocolo de comunicação encriptado usando Transport Layer
Security (TLS) ou Secure Sockets Layer (SSL). A principal motivação do HTTPS é realizar
23
a autenticação de requisições na rede de forma segura, protegendo os dados de quem faz
a requisição e garantindo a integridade de quem processa a requisição.
O HTTPS protege a rede de ataques intermediários, ou seja, após uma requisição
ser feita se alguém interceptar essa requisição não é posśıvel alterá-la ou ler os dados da
mesma, tornando a comunicação entre cliente e servidor segura.
3.4 Javascript
Node.js é um interpretador de código Javascript, open-source, projetado para rodar
código escrito em javascript fora do navegador, ou seja, com ele é posśıvel criar um servidor
que interpreta código javascript, sendo posśıvel criar uma abordagem server-side para uma
linguagem originalmente criada como client-side.
Javascript é um linguagem de programação interpretada, foi inicialmente introduzida
como uma forma de executar scripts dentro de navegadores web, assim era posśıvel que si-
tes estáticos executassem trechos de código com lógicas para realizar ações mais complexas
como animações espećıficas, requisições para servidores e etc.
Uma das maiores reclamações dos desenvolvedores Web em relação ao Javascript é a
falta de organização e tipagem dentro da linguagem. Isso levou a necessidade de utilizar
outras bibliotecas e ferramentas para auxiliar os desenvolvedores a controlar melhor seus
códigos. Uma dessas bibliotecas é o Typescript, criado pela Microsoft, ela permite a uti-
lização de diversas ferramentas para o desenvolvimento que não são nativas ao javascript,
como a utilização de interfaces, classes, tipos de variável bem definidos.
Entre várias caracteŕısticas do framework podemos destacar como principais: operação
em uma única thread, suporte para operações asśıncronas, grande otimização para me-
lhorar escalabilidade e vazão, suporte para os principais sistemas operacionais e um ge-
renciador de dependências integrado com a plataforma.
3.5 Android
O Android SDK é a ferramenta usada para criação de aplicações mobile para An-
droid, ele é usado para compilar código escritos em Java para serem rodados na ART e
Dalvik(máquinas virtuais personalizadas para rodar dentro de dispositivos Android).
Java é uma linguagem de programação interpretada orientada a objetos. Diferente
24
das linguagens de programação convencionais, que são compiladas para código nativo,
a linguagem Java é compilada para um bytecode que é interpretado por uma máquina
virtual (Java Virtual Machine, mais conhecida pela sua abreviação JVM).
Java é uma das linguagens utilizadas para a programação de aplicações mobile para
Android Embora as ferramentas do SDK possam ser usadas por linha de comando, no
trabalho foi usado o software para desenvolvimento Android Studio, que compila e executa
os projetos Android através de emuladores ou devices reais.
3.6 AWS
Para a realização do trabalho será utilizado os serviços de cloud da AWS (Amazon
Web Services), a AWS é uma das pioneiras na construção de arquiteturas serverless, além
disso a AWS oferece serviços de treinamento de Machine Learning e serviços de análise de
imagem, sendo uma solução completa para os problemas de infraestrutura do trabalho.
A seguir serão apresentados os serviços utilizados no trabalho, quais suas principais
funcionalidades, suas limitações e seus usos dentro do trabalho
3.6.1 Rekognition
Serviço de análise imagens e v́ıdeo da AWS, o Rekognition possui três principais
funcionalidades: detecção de objetos, reconhecimento facial, reconhecimento de texto em
imagens.
Para o trabalho será utilizada apenas a funcionalidade de detecção de objetos, com
esse recurso é posśıvel identificar diversas tags vinculadas a uma imagem, ou seja, são
identificados todos os elementos relevantes em uma imagem com uma porcentagem de
confiabilidade vinculada.
A principal limitação do Rekognition está na precisão do seu algoritmo, como não
é algo controlado pelo grupo, não conseguimos aprimorar o algoritmo de Deep Learning
do serviço para alcançar melhores resultados ou resultados mais espećıficos para o pro-
blema que queremos resolver. Além disso o serviço possui uma limitação de conexões
simultâneas, onde é apenas permitido a análise de 50 imagens por segundo.
25
3.6.2 Sagemaker
O Sagemaker é a plataforma gerenciada da AWS para criação, treinamento e im-
plementação de modelos de Machine Learning. Podemos dividir o Sagemaker em três
principais recursos:
• Notebook: Local para criação dos modelos, permite você criar algoritmos, organizardados, ativar o treinamento do modelo e verificar resultados do treinamento.
• Training: Recebe um input de um notebook e aloca uma máquina para o treina-mento do modelo, a máquina é alocada apenas durante o treinamento, evitando o
uso de recursos ociosos.
• Endpoints: Após o treinamento, é gerado um endpoint para realização de previsões,ou seja, uma API é criada e disponibilizada na forma de um endpoint HTTP, esse
endpoint recebe um input apropriado e faz a previsão de resultado a partir do modelo
pré-treinado.
3.6.3 Lambda
A Lambda é o serviço da AWS para a execução de código sem a provisão de um
servidor dedicado para essa tarefa, como comentado o AWS Lambda é um dos pilares
da arquitetura serverless, além de ter sido um dos primeiros serviços criados para essa
finalidade entre todos os provedores de Cloud do mundo.
A lambda funciona com uma configuração simples, onde é necessário fazer o upload
de um código em algumas linguagem suportada pelo serviço, o Lambda é compat́ıvel com
Node.js (JavaScript), Python, Java (compat́ıvel com Java 8), C (.NET Core) e Go. Além
disso é necessário especificar o gatilho da sua função, ou seja, o evento que irá invocar a
execução do seu código.
As principais limitações do Lambda estão vinculadas as configurações do serviço, a
função executa com um memória RAM pré-definida, ou seja, é função do cliente estipular
quanta memória será usada e isso irá influenciar diretamente no custo e no tempo de
execução, mas esse valores são pré-definidos e podem não ser suficientes para determinadas
aplicações.
Além disso a lambda possui uma limitação de timeout, ou seja, a execução de funções
Lambda podem durar no máximo 15 minutos, o que pode ser um limitante dependendo
da forma como a função for escrita.
26
3.6.4 DynamoDB
O DynamoDB é um banco de dados não relacional que fornece performance confiável
em qualquer escala. Assim como os principais serviços associados a uma arquitetura
serverless não o DynamoDB não está localizado em um servidor dedicado, a distribuição
de dados é operada pela própria AWS, permitindo que desenvolvedores definam um limite
de capacidade para utilização do banco e a AWS garanta a capacidade estipulada.
Uma das grandes vantagens do DynamoDB é a sua confiabilidade, e sua escalabilidade,
permitindo o desenvolvimento de aplicações de grande porte sem a preocupação com
alocação de recursos para dados.
3.6.5 API Gateway
O API Gateway é o serviço de gerenciamento de APIs da Amazon, esse serviço provê
a geração de endpoints customizados e configuráveis que são usados como acionadores
de eventos da Lambda, ou seja, o endpoint possui as suas configuração HTTP (método,
url, porta, domı́nio, etc) e umas vez que esse endpoint é chamado uma função Lambda é
invocada e todos os parâmetros passados pelo endpoints são direcionados para a Lambda.
Esse funcionamento permite a criação de APIs completas para o gerenciamento de
aplicações web e mobile mantendo a segurança provisionada pelo protocolo HTTPS e
todos os padrões de comunicação estipulados pelo protocolo HTTP.
3.6.6 S3
O S3(Simple Storage Service) é o serviço de armazenamento de dados em larga escala
da AWS, é um dos serviços de storage mais confiáveis do mercado e um dos ’carros chefe’
da empresa, possui uma resiliência de 99,999999999% a um custo muito acesśıvel.
O S3 é dividido em buckets, quem funcionam como grandes pastas, onde cada buc-
ket possui uma configuração e acesso próprio, o serviço é usado como storage de todas
as fotos da nossa aplicação, tanto imagens de usuários quanto as imagens usadas para o
treinamento do nosso modelo de Machine Learning, o S3 também é usado para o armazena-
mento dos códigos das nossas funções Lambda e para o armazenamento das configurações
de treinamento do Sagemaker.
Outra utilidade do S3 é a de ser usado como fonte de eventos para disparar funções
Lambda, esse serviço pode ser configurado para quando houver um upload em determi-
27
nado bucket de um arquivo de determinado tipo, ou com determinado nome, uma função
Lambda é acionada e o endereço onde tal arquivo foi salvo é enviado como parâmetro
para o Lambda.
3.6.7 Elasticsearch
Como comentado anteriormente o Elasticsearch é um algoritmo open source para
a realização de buscas, mas isso permite apenas a utilização do algoritmo, nenhuma
infraestrutura é fornecida, é necessário que o algoritmo seja instalado e configurado em
um servidor, isso traz diversas consequências, como o gerenciamento de fluxo de dados
dentro da máquina, algo que pode facilmente se tornar muito complicado quando uma
aplicação escala rapidamente.
A AWS fornece um serviço gerenciamento de Elasticsearch, chamado AWS Elasticse-
arch, ele permite a configuração de um servidor com o algoritmo já instalado e com um
controle de acesso e de rede através de poĺıticas de acesso. Esse serviço também permite a
mudança de máquina alocada, permitindo a migração para servidores menores ou maiores
de forma rápida e segura, sem a perda de dados ou de disponibilidade.
A principal desvantagem desse serviço é que ele não opera como os outros serviços
utilizados no projeto, onde o custo de operação é apenas o utilizado, nesse caso você
contrata uma máquina de tamanho variado e paga pelos recursos em tempo integral,
sendo eles ociosos ou não.
3.6.8 EC2
O EC2 (Elastic Compute Cloud) é o serviço de disponibilização de capacidade com-
putacional segura e redimensionável na nuvem, é o principal produto da AWS, e podemos
resumi-lo como: servidores na nuvem, com esse serviço você possui acesso quase total a
uma máquina de tamanho configurável e pode fazer qualquer tipo de operação dentro
dele, o caso de uso mais comum para esse serviço é fazer a hospedagem de servidores e de
bancos de dados, sendo uma solução completa para a criação do backend de um projeto
de qualquer tamanho.
Empresas do mundo todo utilizam o EC2 como principal fonte de hospedagem de
seus servidores, dada a fácil configuração de seus servidores e pelo fato de ser facilmente
redimensionável. Além disso com a ajuda de outros serviços é posśıvel fazer a distribuição
de diversas máquinas para a operação em conjunto, permitindo que a quantidade de
28
servidores disponibilizado para uma aplicação cresça infinitamente, onde o único limitante
é o tamanho dos data centers provisionados pela AWS.
Esse serviço foi usado apenas para testes dos algoritmos de Elasticsearch em um ambi-
ente real, fora isso o serviço foi usado apenas de forma indireta, tanto o AWS Elasticsearch
quanto o AWS Sagemaker utilizam máquinas do EC2 espećıficas e com configurações es-
peciais para otimização de seus processos.
29
4 METODOLOGIA DE TRABALHO
O trabalho foi divido em X categorias, onde a realização das mesmas aconteceu de
forma paralela devido a independÊncia de completude de uma categoria para a realização
de outras.
4.1 Estudos de Inteligência Artificial
Assim que o tema do trabalho foi definido identificamos a necessidade de dedicar
tempo de estudo para a principal tecnologia envolvida no trabalho, para isso o grupo
realizou cursos de machine learning, associado a leitura de diversos artigos relacionados a
machine learning, deep learning e visão computacional.
Também utilizamos as aulas da matéria PCS 3838 e o livro Artificial Intelligence: A
Modern Approach como base teórica de inteligência artificial para o desenvolvimento do
trabalho.
4.2 Planejamento de arquitetura
Com os conhecimentos necessários consolidados fizemos um estudo de como seria
organizada a arquitetura no projeto, como seriam abordados diversos conceitos e uma
grande quantidade de tecnologias seria usada o grupo optou por utilizar os serviços da
AWS como base do trabalho e com isso modelamos como cada serviço seria usada de
forma a atender as necessidades do grupo.
4.3 Implementação Rekognition
O primeiro serviço a ser integrado foi o serviço do AWS Rekognition, ele seria o ponto
de entrada da nossa aplicação, pois com ele teŕıamos uma classificação inicial de nossas
30
imagens, por isso optamos por começar a implementação por ele e entender suas principais
funcionalidade e limitações para adequar o resto do trabalho aos outputs do Rekognition.
4.4 Implementação Elasticsearch
A necessidade da implementação do Elasticsearch surgiu durante o planejamento da
arquitetura, o que necessitou em mais um peŕıodo de estudos sobre o algoritmo, e através
de cursos online e leitura de documentações sobre o algoritmo. Em seguida foram realiza-
das provas de conceito do funcionamento e da instalação de um algoritmo de elasticsearch
dentro computadores pessoais e dentro de máquinas da AWS.
4.5 Treinamento do modelo
O treinamento e aperfeiçoamento do mesmo durou quase toda a implementação do
trabalho, foi necessário a aquisição de datasets de imagens que atendessem as categorias
de propaganda que t́ınhamos interesse. Além disso tivemos etapas de estudo e testes do
serviço de machine learning da AWS e de modificações do algoritmo para atenderem as
necessidades do projeto.
4.6 Criação e integração do aplicativo
A última etapa do projeto consistiu na criação da aplicação mobile que seria usada
para demonstração e validação do projeto. Além disso nessa etapa foi feita a integração
de todos os serviços e foram feitos os testes de validação do funcionamento do projeto.
31
5 ESPECIFICAÇÃO DE REQUISITOS DO
SISTEMA
Para a especificação do sistema será utilizado o modelo proposto pelo Reference Model
of Open Distributed Processing (RM-ODP). Esse modelo divide a arquitetura do projeto
em cinco visões, onde cada visão foca em descrever o sistema de um ponto de vista
diferente com o objetivo de criar uma arquitetura mı́nima do projeto, sendo capaz de
descrever todo o projeto.
5.1 Visão Empresa
Como apresentado anteriormente o mercado mobile vem crescendo de forma assom-
brosa, a mudança de tecnologia predominante, do computador pessoal para os smartpho-
nes, já é realidade. Pessoas deixam de comprar um computador de mesa ou um notebook
para comprar um smartphone de última geração, e o mercado de marketing já está rea-
gindo a essa mudança.
O mercado de marketing e propaganda é um dos mercados que mais movimenta a
economia mundial, bilhões de dólares são investidos anualmente com propagandas pu-
blicitárias com o intuito de impulsionar as vendas de determinado produto. Atualmente
empresas não competem para fazer o melhor produto, mas sim a melhor propaganda, pois
é isso que provavelmente irá fazer o produto vender mais.
Com essa necessidade estão associados dois principais problemas: Como fazer propa-
gandas que atraem o cliente para comprar o produto e como fazer que os clientes vejam
essa propaganda. O principal objetivo do projeto é resolver esse segundo problema, ou
seja, como entregar as propagandas certas para os clientes certos.
O SmartAd entra como um facilitador entre 3 personagens, sendo eles os clientes
finais, os anunciantes e os desenvolvedores de aplicações de redes sociais. O nosso projeto
conecta esses três personagens através de uma plataforma espećıfica para cada um, nesse
32
modelo o anunciante não precisa se preocupar em quais lugares a sua propaganda será
exibida, ele apenas define quantas visualizações direcionadas ele deseja e paga de acordo
com esse número.
Para os clientes nada muda, eles não precisam baixar uma nova aplicação para ver
essas propagandas, elas serão inseridas dentro dos aplicativos de rede social do usuário
de forma direcionada. Para os desenvolvedores de aplicações de rede social é necessária a
integração com a plataforma de mobile desenvolvida no projeto, e a forma de remuneração
para essas aplicações é proporcional a quantas propagandas os seus usuários estão visu-
alizando, ou seja, quanto mais usuários na aplicação, mais remuneração a rede social irá
ganhar.
A figura 3 compreende como a Visão Empresa compreende o negócio do projeto,
explicitando como os personagens interagem com o sistema.
Figura 3: Processo de negócio do projeto
No diagrama podemos ver a interação entre os 3 personagens citados anteriormente
e como cada um deles participa dentro do sistema de forma diferente. O Anunciante irá
primariamente utilizar a plataforma Web, todo o fluxo de caixa do negócio depende desse
fluxo, uma vez que, dentro dessa plataforma Web, o anunciante criará os anúncios e fará
o pagamento por essa divulgação.
A partir desse fluxo a nossa empresa consegue operar, nesse ponto entra o outro
participante do sistema, os Parceiros, tão essenciais quanto os Anunciantes, uma vez
que o produto desses parceiros será o local de divulgação das plataformas, portanto a
33
existência de parceiros com grande volume de usuários garante que os Anunciantes terão
suas propagandas exibidas aos usuários finais.
Esse personagem age através da integração da biblioteca mobile desenvolvida no pro-
jeto, seria necessário algum tipo de plataforma onde os parceiros poderiam se cadastrar,
e com esse cadastro, a nossa empresa faria o liberamento do acesso a biblioteca e daria o
suporte para a instalação da mesma, como benef́ıcio, esses parceiros ganham uma parte
do valor arrecadado com o pagamentos das propagandas.
Finalmente temos o nosso personagem final, o Usuário, o nosso produto tem pouco im-
pacto viśıvel para esse personagem, uma vez que ele não vê o nosso produto diretamente,
mas sim consome ele através das propagandas exibidas pelos aplicativos nos nossos Par-
ceiros, além de ser esse personagem que alimenta o nosso banco de dados com informações
sobre seu próprio perfil.
5.2 Visão Informação
A Visão Informação deve representar as informações que o sistema necessita para
resolver o problema, portanto essa visão deve exemplificar toda o fluxo de informação
para que uma propaganda seja sugerida.
Para isso o mais importante é mostrar o fluxo para a geração do perfil de um usuário,
ou seja, como a partir de uma foto tirada pelo usuário, será criado um conjunto de
informações que definem o perfil do usuário, e que posteriormente serão usadas na busca
de propagandas.
Para mostrar esse fluxo foi utilizado um Diagrama Entidade-Relacionamento (DER),
indicado na figura 4, que mostra o fluxo de informação a partir do momento que uma foto
é tirada, a partir disso são extráıdos dois tipos de informação, os metadados da imagem,
que serão utilizados como forma de identificação da imagem, e as categorias provenientes
do serviço de análise de imagem, essas categorias servem então de input para o modelo
de aprendizado de máquina que gera um cluster associado a imagem, finalmente esse
conjunto de informações, metadados e cluster, são salvos em um banco de dados.
5.3 Visão Computação
A visão computacional descreve como o sistema interage entre cada um dos módulos,
portanto, com esse documento podemos entender o relacionamento entre as camadas do
34
Figura 4: Diagrama de Entidade e Relacionamento
projeto, qual a responsabilidade de cada camada, e como funciona o interfaceamento entre
essas partes do sistema.
5.3.1 Arquitetura de Referência
A arquitetura do projeto foi montada seguindo como referência os padrões definidos
pelo NIST (National Institute of Standards and Technology). Para o trabalho foram
considerados dois artigos espećıficos, um que diz respeito a computação Cloud e outro
que referencia a segurança em aplicações Cloud.
O NIST SP 800-145 define o que é a computação na nuvem, e quais padrões devem
ser seguidos para atender as especificações da arquitetura, o artigo define as principais
caracteŕısticas que o sistema deve possuir para ser considerado um sistema Cloud. as
caracteŕısticas essenciais do artigo podem ser vistas no diagrama da figura 5.
35
Figura 5: Diagrama da NIST SP 800-145
O outro artigo que foi usado como base foi o NIST SP 800-53 que explicita padrões
de segurança a serem seguidos por sistemas de forma que os dados de usuários estejam
seguros e não possa haver vazamento de dados. Esse artigo estipula regras arquiteturais
que o sistema deve possuir para garantir a segurança dos usuários dentro do sistema.
O sistema desenvolvido para o projeto segue as especificações definidas pelos dois
artigo, para o NIST SP 800-53, a provedora de Cloud AWS, utilizada para o projeto,
segue as referências de segurança implementando protocolos de VPN entre suas camadas
para garantir o acesso apenas de usuários autorizados, além do uso de policies de segurança
para comunicação entre serviços da provedora.
As regras NIST SP 800-145 são garantidas também pela AWS em conjunto com a
arquitetura definida pelo projeto, a utilização de uma arquitetura de três camadas garante
a segurança dos dados de forma a apenas usuários autenticados serem capazes de fazer
modificações senśıveis ao sistema.
Abordando as caracteŕısticas do NIST 800-145 com a estrutura do projeto podemos
associar várias caracteŕısticas com o projeto, do ponto de vista de Deployment Models, o
projeto trabalhou com uma abordagem Hı́brida, isso se deu devido a necessidade de alguns
micro serviços serem privados, como o treinamento do modelo de machine learning, e
outros micro serviços, como a api criada para sugestão de propagandas e a api para criação
de propagandas, serem de domı́nio público, e podem ser acessados independemente do host
de origem.
36
Do lado de Service Models, apesar de boa parte do projeto operar com conceitos FaaS,
que não foram considerados na NIST 800-145, vários serviços utilizados pelo projeto se
apoiam no conceito de IaaS, um dos mais conhecidos serviços de IaaS do mundo é a EC2,
serviço de computação dedicada da AWS, se entrarmos mais no detalhe de alguns serviços
como Sagemaker e Elasticsearch, podemos ver que na verdade todo o processamento
é operado em uma máquina da própria EC2, customizada para resolver um problema
espećıfico.
Sobre as Essential Characteristics, podemos levantar alguns pontos interessantes, o
nosso projeto opera com uma disponibilidade de mais de 99%, garantido pelo AWS
Lambda, esse serviço possui essa propriedade devido a caracteŕıstica distribúıda do próprio
serviço, ou seja, o projeto não está vinculado a uma máquina, mas sim a um hub de
máquinas da AWS dedicado a isso.
Essa caracteŕıstica, associado a facilidade de escalar dentro da Cloud, garante o cres-
cimento do serviço oferecido pelo projeto de forma segura e natural, tendo como respaldo
esses números, conseguimos garantir uma eficiência de quase 100% a qualquer parceiro
que quiser integrar o nosso serviço em sua plataforma, ou dar uma certeza a qualquer
anunciante que o serviço de anúncio contratado será entregue ao usuário final.
5.3.2 Arquitetura da Visão Computação
Como mencionado, o projeto utiliza uma arquitetura de três camadas para realizar a
comunicação dos serviços e aplicações do projeto, isso garante que a responsabilidade de
cada camada esteja bem definida e os acessos de cada camada sejam restritos de forma a
impedir de usuários mal intencionados consigam danificar o sistema de alguma forma.
A utilização dessa arquitetura também auxilia o projeto no sentido de organizar a
estrutura de código e garantir que cada camada tenha uma responsabilidade de software
bem definida, ou seja, quando um problema surgir, ou uma nova implementação for feita,
a organização sistema garante que as lógicas do projeto possam ser reaproveitados ou que
a modificação em uma camada da aplicação não irá afetar diretamente o funcionamento
do sistema. As três camadas, que compõe o sistema estão descritas a seguir:
• Camada de Aplicação: Camada de apresentação do sistema, responsável por mostrartelas, coletar dados do usuário, validar esse dados e se comunicar com a camada de
negócio.
• Camada de Negócios: Responsável por contar todas as regras de negócio da aplicação,
37
Figura 6: Diagrama da arquitetura em camadas do sistema
essa camada trata de dados senśıveis e deve ser protegida, sendo capaz de acessá-la
apenas por meio de interfaces bem definidas.
• Camada de Dados: Trata a persistência de dados e consulta desses dados, camadamais senśıvel da aplicação, uma vez que alterar essa camada impacta a veracidade
dos dados da aplicação.
5.3.3 Aplicação da Clean Architecture
Para a arquitetura de software do backend foi usado o conceito de clean architecture.
Essa arquitetura prega a independência de banco de dados, independência de frameworks
e independência de agentes externos, ou seja, cada camada da arquitetura é independente
e pode ser substitúıda sem alterar o funciona do sistema como um todo.
Outro conceito da Clean Architecture é o uso de interfaces para a comunicação entre
camada. as interfaces definidas são um guia para cada camada, e considerando que as
interfaces não mudem, cada camada pode mudar a forma como trata um operação, ou um
serviço pode mudar, sem afetar o funcionamento do sistema. A seguir estão apresentadas
as camadas utilizadas no projeto, sua função e os principais módulos contidos em cada
camada.
38
• presentation: Essa camada pouco difere pelo definido pela arquitetura, a camadacontém os entry points de todas as funções Lambda que serão utilizadas no projeto,
essa camada é dividida em módulos que englobam todas as funções referentes a um
fluxo espećıfico da aplicação. Essa camada também é responsável pela validação
dos dados de entrada, ou seja, qualquer parâmetro enviado para a função lambda
é validado nesse primeiro momento e caso seja necessário a execução da função
Lambda já é interrompida e uma mensagem de erro é enviado informando que
houveram erros na validação de dados Nessa camada temos dois módulos principais:
suggestion e classification, o módulo de suggestion é responsável por contém todas as
funções de entrada referentes a busca e adição de propagandas dentro da aplicação.
O módulo de classification é responsável por conter todas as funções de classificação
de imagens, criação de perfil, e treinamento do modelo de machine learning.
• core: Essa camada engloba dois módulos principais: use-cases e data-sources, omódulo de use-cases é responsável por conter todas os arquivos referentes a lógica
de negócios do projeto, neste módulo estão presentes funcionalidades como o parse
de dados para atender as especificações do projeto, lógicas de paginação, etc. Essa
camada pode ser considerada como o coração da função, ela é responsável por orga-
nizar toda a lógica da função e também é responsável por montar a sáıda da função e
tratar eventuais erros de lógica e de serviço. O outro módulo presente nessa camada
são os data-sources, esse módulo contém todas as interfaces de comunicação entre
use-cases e serviços gerais, também contém a definição dos modelos de comunicação
entre as camadas. De forma resumida este módulo define quais serviços podem ser
chamados, que parâmetros devem ser passados para a função e o que ela irá devolver.
• data: Camada engloba todas as definições vinculadas com dados, nesse trabalho foidivida em três módulos: tables, dictionaries e services. O módulo de tables contém
as definições de todas as tabelas do banco de dados, apesar de estar trabalhando
com banco de dados não relacional, essas definições são importantes, pois permitem
que a segurança dos dados que estão sendo armazenados não seja comprometida e
impede que usuários maliciosos tentem inserir dados estranhos para a aplicação. O
módulo de dictionaries contém arquivos gerados durante o treinamento do modelo
que contém uma lista de todas as tags utilizadas durante o treinamento, esses arqui-
vos foram salvos dentro do projeto pois não representavam uma grande quantidade
de dados, mas caso fosse guardado em algum sistema de storage poderia acarretar
em uma adição de latência indesejada na execução de algumas funções. Finalmente,
o módulo de services contém todos os serviços utilizados dentro do projeto, cada
39
classe deste módulo implementa pelo menos um data-source e segue as suas de-
finições implementado suas funções, permitindo que os serviços sejam facilmente
trocas contando que elas sigam as definições estipuladas pelos data-source. Esse
módulo contém as integrações com todos os serviços externos a aplicação (rekogni-
tion, elasticsearch, s3, etc..), implementado as principais usabilidades do serviços,
um exemplo é que para o serviços de DynamoDB estão implementadas as principais
funcionalidades de CRUD de banco de dados.
5.4 Visão Engenharia
A visão engenharia trata a distribuição de sistemas do projeto, ou seja, como o sis-
tema se comunica entre cliente e servidor, para a realização do projeto foi utilizada uma
infraestrutura de servidor cloud, utilizando como provedor a AWS. Esses serviços traba-
lham em conjunto para atender as necessidades de infraestrutura do projeto e simular
uma estrutura de servidor clássico.
É importante ressaltar que toda a comunicação entre cliente e servidor foi feita através
de uma API REST, utilizando como protocolo de comunicação o HTTP e toda a troca
de dados foi feita utilizando JSON.
O projeto englobou um total de sete serviços da AWS, apresentados em três fluxos
principais. A seguir serão explicados os três fluxos e como os serviços se ligam para atender
todas as especificações do projeto. É importante ressaltar que os três fluxos apresentam
funcionalidades da aplicação e não englobam o processo de treinamento do modelo, que
foi feito através da execução de scripts diversos e será abordada durante a explicação do
item 6.1.
O primeiro fluxo principal do projeto é iniciado quando um usuário tira uma foto
dentro do aplicativo mobile, a partir desse momento começam as integrações com a AWS,
é então feito upload da foto do usuário dentro do S3, a partir disso o upload de um
arquivo espećıfico em um determinado bucket no S3 aciona uma função Lambda, essa
função valida o endereço da imagem e o id do usuário, enviado através de metadados da
imagem e aciona um use-case responsável por fazer a análise da imagem, esse use-case
então aciona o Rekognition enviando como parâmetro a foto em questão, com as tags de
sáıda do Rekognition é acionado o endpoint do Sagemaker para realizar a previsão de qual
cluster essa imagem se enquadra. Com a resposta do Sagemaker os dados da imagem, id
do usuário e dados de cluster são salvos no DynamoDB.
40
Figura 7: Diagrama da arquitetura de serviços
O segundo fluxo principal do projeto acontece quando o usuário acessa o seu feed,
nesse momento a aplicação mobile faz uma requisição HTTPS, essa requisição é validada
pelo API Gateway que redireciona os parâmetros enviados para uma função Lambda,
essa função é responsável primeiramente por validar os dados enviados, em seguida um
use-case é acionado para buscar as propagandas relevantes para o usuário, este use-case
primeiro recupera um parcela de informações do Dynamo, contendo as informações das
fotos tiradas pelo usuário, com isso é montado um modelo de perfil do usuário que é
enviado para realizar um busca dentro do elasticsearch, essa busca leva em consideração
a localização e as preferências do usuário, o retorno dessa busca são as propagandas que
são então retornadas para o usuário como resposta dessa requisição HTTPS.
O terceiro fluxo engloba o processo de inserir uma propaganda dentro do sistema,
apesar de ser o fluxo mais simples é o que traz mais valor para aplicação, dado que é
o local em que ocorrerá o pagamento para inserir propagandas no sistema. Similar ao
segundo fluxo, dentro de uma plataforma Web é feita uma requisição HTTPS, enviando
para o servidor as informações da propagandas e as informações de pagamento, isso é então
validado do lado do servidor e finalmente as informações são salvas dentro do Elasticsearch.
41
5.5 Visão Tecnologia
A Visão Tecnologia do projeto deixa claro as implementações do sistema, ou seja,
quais as tecnologias utilizadas para o desenvolvimento do software do projeto. A imple-
mentação do projeto pode ser descrita com uma divisão em três partes: Desenvolvimento
do Backend, Desenvolvimento do Frontend Mobile, Desenvolvimento do Frontend Web.
5.5.1 Backend
5.5.1.1 Serverless
Como mencionado no item 2.7, para o projeto foi utilizada uma arquitetura serverless,
onde os serviços são instalados na nuvem de forma separada e acionados entre si. O
principal framework utilizado para gerenciar aplicações desse tipo se chama Serverless
Framework, ele permite que através de um arquivo de configurações escrito na linguagem
YAML todos os serviços sejam implantados no provedor de nuvem escolhido através de
um comando executado na linha de comando.
Nessa seção serão abordados as configurações que englobam o processo de deploy e de
execução de um projeto serverless.
• provider: esse trecho de configurações informa as principais informações de provedorde cloud e as configurações necessárias para deploy dessas informações. Os principais
parâmetros definidos aqui são o provedor (AWS), linguagem de execução das funções
lambda, ambiente de desenvolvimento (dev), perfil de credenciais para execução do
deploy e permissões de quais serviços da AWS as funções lambda irão acessar.
• plugins: define os plugins adicionais usados para execução do comandos do server-less. Os plugins usados foram: serverless-webpack utilizado para o transpile e build
do código a ser executado, serverless-prune para remover versões antigas de código
que são armazenadas pelo Lambda e serverless-offline que permite a execução do
projeto de forma emulada, onde as funções ficam dispońıveis para execução sem a
necessidade de um deploy na AWS.
• resources: definição de todos os recursos a serem criados pelo serverless além dasfunções lambda e de seus eventos, por exemplo, com esses recursos podem definir
um modelo de tabela para ser criada dentro do DynamoDB junto com o deploy da
aplicação.
42
• functions: definição de todas as funções lambda a serem implantadas na AWS assimcomo a definição de todos os eventos que acionam essas funções lambdas
5.5.1.2 Node.js
O AWS Lambda permite executar código em algumas linguagens, para o projeto
foi utilizado o Node.js, na sua versão 8.10, que é um interpretador de código Javas-
cript, portanto todo backend foi escrito em javascript, com aux́ılio de algumas bibliotecas
open-source como typescript (tipagem dentro do Javascript), class-validator (usado para
validação de inputs), aws-sdk (biblioteca com sdk de todos os serviços da AWS), request-
promise (biblioteca para gerenciamento de requisições HTTP), entre outras.
5.5.2 Frontend Mobile
Para o desenvolvimento do Frontend mobile, foi utilizada a linguagem nativa do an-
droid, Java, com aux́ılio do Android SDK, esse aplicativo funciona como um módulo de
demonstração, onde é posśıvel visualizar um feed de propagandas, tirar fotos e ver a sua
galeria de fotos.
A ideia desse aplicativo é demonstrar o funcionamento do projeto, uma vez que essa
funcionalidades descritas aqui já estariam implementadas dentro de outros aplicativos
de rede social, e o nosso projeto entraria como uma biblioteca a ser utilizada por esses
aplicativos, integrando dentro dos seus aplicativos já existentes.
5.5.3 Frontend Web
Para o desenvolvimento do Frontend Web, foi utilizada a biblioteca React. Esse
módulo é responsável por ser uma plataforma onde anunciantes poderão criar propagan-
das, pagar por uma quantidade de visualizações, escolhidas por esse anunciante, e salvar
esses dados de forma que a propaganda seja encontrada pelo sistema.
43
6 IMPLEMENTAÇÃO
Nesse tópico serão apresentados os principais módulos que compõe o sistema, como eles
foram implementados, as principais dificuldades encontradas e os resultados alcançados.
6.1 Módulo de classificação
Figura 8: Diagrama do fluxo do módulo de classificação
6.1.1 Configurações Rekognition
O Rekognition não requer nenhuma configuração especial, é um serviço que pode
ser utilizado diretamente pela SDK da AWS é necessário apenas a autenticação para
associar a chamada do SDK com uma conta espećıfica da AWS. O serviço cobra de forma
indiscriminada, ou seja, as chamadas da SDK não estão associadas a um projeto ou
domı́nio espećıfico, mas apenas a conta vinculada.
44
A principal limitação encontrada pelo grupo durante o trabalho com o Rekognition
foi o fato de ele suportar um máximo de 50 requisições por segundo, o que reduziu a
eficiência de análise, inicialmente toda a análise de dados pelo rekognition era feita de
forma paralela, ou seja, todas as imagens eram enviadas para o S3, o que disparava
lambdas que faziam a análise das imagens e jogando os resultados em arquivos de texto
de volta para o S3.
Para um pequeno volume de imagens esse procedimento não deu problemas, mas
quando trabalhamos com uma quantidade de imagens na casa dos milhares o Rekognition
começou a travar a execução da análise de imagens, o que forçou o grupo a reduzir a
quantidade de imagens enviadas para o S3 com o intuito de reduzir o fluxo de dados
requisitados ao Rekognition.
6.1.2 Aquisição de dataset de imagens
Um dos primeiros desafios encontrados foi o de montar um dataset de imagens que
atendesse os requisitos do grupo, esse processo levou alguns meses que inclúıram definição
de categorias relevantes, busca de dados relevantes e todo processo de upload de dados
na infraestrutura da nuvem.
Assim que começamos a trabalhar com o rekognition o grupo decidiu algumas cate-
gorias de interesse inicial, essas categorias seriam as categorias chave na hora de mostrar
uma propaganda, ou seja, cada imagem tirada por um usuário seria classificada dentro da
categorias definidas pelo grupo e na hora de sugerir uma propaganda seria consultado todo
o histórico de fotos tiradas pelo usuário e com as classificações vinculadas seria sugeria
um conjunto de propagandas organizadas pela relevância.
Nesse primeiro momento definimos um total de seis categorias: comida, esportes,
viagem, beleza, saúde e animais domésticos. As categorias foram definidas através de
pesquisa de opinião direta com colegas de faculdade, trabalho e familiares de forma in-
formal, com o intuito de entender quais os tipos de propaganda mais comuns em redes
sociais e quais os tipos mais comuns de fotos colocadas em redes sociais.
Com as categorias definidas o primeiro experimento do grupo foi adquirir um dataset
de forma manual, ou seja, acessamos sites de imagens sem copyright, fizemos download
dessas imagens e usamos elas como dataset inicial, nesse primeiro momento foi agrupado
um total de 600 imagens (100 para cada categoria).
Nos primeiros testes percebemos algumas dificuldades que seriam muito dif́ıceis de se-
45
rem superadas sem utilizar de um poder computacional muito maior e um dataset também
muito maior, da forma como estávamos fazendo a classificação algumas categorias eram
misturadas em uma mesma classificação, os detalhes sobre os resultados do treinamento
serão abordados na seção 5.2.X. Como resultado decidimos por diminuir a quantidade de
categorias, dado que o principal foco do trabalho é validar a ideia do produto por trás
da implementação, com isso reduzimos para quatro categorias (comida, esportes, viagem
e animais domésticos), mesmo assim as categorias de esportes e viagem acabavam se
misturando, devido a dificuldade de definir quando uma foto é de viagem ou de esporte.
Como solução decidimos fazer duas principais modificações no projeto, a primeira é
mudar as categorias novamente, utilizando objetos mais facilmente identificados e aumen-
tar a quantidade de imagens do dataset.
Para as categorias resolvemos retirar as categorias que mais causavam conflito e adici-
onar outras duas categorias relevantes para o trabalho, com isso ficamos com as seguintes
categorias: comida, animais domésticos, carros, bebês.
Em relação ao aumento da quantidade de imagens, seria inviável continuar com a
estratégia de seleção de imagens manualmente, para resolver esse problema utilizamos
datasets open source de imagens espećıficos para o treinamento de modelos de deep le-
arning. Utilizando o dataset de imagens do ImageNet(Dispońıvel em http://www.image-
net.org/¿. Acesso em: 21 nov. 2018.) conseguimos agrupar um total de 4000 imagens
(1000 para cada categoria).
Para o resto do desenvolvimento do trabalho, esse foi o dataset usado, contendo 4000
imagens de comida, animais domésticos, carros e bebês.
6.1.3 Refinamento da sáıda do Rekognition
O serviço do Rekognition utilizado chama-se detectLabels, com eles é posśıvel identi-
ficar labels dentro de imagens e é atribúıdo uma confiabilidade para a label identificada,
inicialmente todas as imagens do dataset eram analisadas utilizando o serviço de detec-
tLabels e a sáıda dele era utilizada diretamente como entrada para o modelo de machine
learning, após alguns testes percebemos que isso nos fornecia resultados errados.
O primeiro problema dessa abordagem é que o Rekognition retorna toda e qualquer
label encontrada, não importando o ńıvel de confiabilidade encontrado, portanto muito
imagens retornavam labels que quando verificado nem se encontravam na imagem, por-
tanto para garantir que utilizaŕıamos apenas labels que realmente se encontravam na
46
imagem, definimos um ńıvel mı́nimo de confiabilidade, e antes de passar para o modelo
de machine learning as labels que não atendessem esse ńıvel mı́nimo eram filtradas.
Além disso encontramos outro problema, algumas labels encontradas, apesar de fa-
zerem parte de imagem, e terem uma confiabilidade alta não eram o foco principal da
imagem, mas quando esses valores eram passados para o modelo de machine learning ele
entendia que essas labels indesejadas na verdade formavam uma nova categoria.
Para resolver esse problema, tivemos um trabalho de identificar as labels mais pro-
blemáticas e que não tinham uma categoria bem definida e mais uma vez fizemos umas
filtragem das labels antes de enviar esses dados para o modelo de machine learning.
6.1.4 Treinamento do modelo de classificação utilizando o Ama-zon Sage Maker
Tendo o dataset de labels geradas a partir do processamento das 4000 imagens, pas-
samos a implementar o algoritmo escolhido, K-Means, na plataforma do Sage Maker para
possibilitar o treinamento do nosso modelo de aprendizado de máquina.
O primeiro passo foi configurar e provisionar um bloco de anotações Jupyter para a
execução do tratamento necessário para inputar o dataset no algoritmo para treinamento.
Os cadernos Jupyter são uma tecnologia open source para edição de texto online que
suportam a execução de código em 40 linguagens diferentes. Para a implementação do
algoritmo do projeto foi escolhido Python. Para a execução do bloco de notas, provisio-
namos uma máquina na infraestrutura da AWS, pelo serviço EC2, e fizemos o deploy da
aplicação pelo console do Sage Maker.
Com o caderno Jupyter em execução, acessamos a interface gráfica e importamos o
código desenvolvido em Python para importação, tratamento dos dados e execução do
treinamento do modelo. As etapas para o treinamento do modelo, portanto, se deram na
seguinte ordem:
• Importação de dataset a partir de arquivo de texto salvo do S3:
Como resultado do processo de análise da base de fotos categorizada, geramos um
documento de texto contendo as labels inferidas a partir de cada foto. Tal arquivo
foi armazenado no S3 e do ambiente do caderno Jupyter, estando dispońıvel para
os demais processos lerem o arquivo da memória.
• Leitura do arquivo de dataset e configuração do algoritmo:
47
Com o arquivo importado em memória na máquina rodando o caderno Jupyter, exe-
cutamos um script para leitura do arquivo e tratamento do mesmo para uma matriz
de floats. Em seguida, fazemos a importação do algoritmo KMeans, disponibilizado
na sdk nativa do Sage Maker. Para a configuração do algoritmo, precisamos definir
qual o dimensionamento de máquina queremos disponibilizar para o treinamento do
modelo, qual o valor de K a ser aplicado, 4 no caso do projeto e caminhos para os
outputs gerados.
• Alimentação do algoritmo com o dataset e treinamento do modelo:
Com o algoritmo inicializado com o ambiente de treinamento, alimentamos o mesmo
com o dataset tratado, em formato de matriz. Isso dispara o processo de treinamento
do modelo, disponibilizando a infraestrutura definida na configuração do algoritmo
e rodando o mesmo com o dataset fornecido.
• Deploy de endpoint de inferência:
Em seguida, ao final do processo de treinamento iniciado acima, nosso script realiza
o deploy do endpoint de predição, determinando qual o tamanho e tipo da instância
de máquina EC2 que queremos disponibilizar para tratamento das inferências. A
partir desse ponto, o Sage Maker faz o provisionamento de recursos para o deploy do
endpoint de inferências e temos a nossa disposição um endpoint REST para realizar
as consultas no modelo.
6.1.5 Estruturação de dados no DynamoDB
Com a sáıda do modelo treinado e com todas as informações referentes a foto tirado
pelo usuário é necessário salvar esses dados para consultas futuras pelo módulo de su-
gestão, para isso os dados foram guardados em um banco de dados não relacional da
AWS o DynamoDB.
Esse banco, apesar de ser não relacional, possui algumas peculiaridades, ao contrário
de banco não relacionais tradicional, toda tabela possui uma chave primária e opcional-
mente uma chave secundário (primary key e sort key respectivamente), o conjunto de
chaves é chamado de partition key, e essa chave deve ser única. Esse é um comporta-
mento comum em banco relacionais, mas foi introduzido no DynamoDB com o intuito
de melhorar a performance e eficiência das buscas, dados que toda partition key de uma
tabela tabela contém um index para agilizar as buscas.
Os dados do resultado do modelo são organizados da seguinte forma:
48
• primary key: id do usuário que tirou a foto, com isso é fácil em outro momentoresgatar todas as fotos que um usuário tirou.
• sort key: horário que a foto foi tirada, isso permite organizar as buscas de formarápida, ou seja, o próprio Dynamo é capaz de retornar os dados ordenados pela sort
key, com isso podemos resgatar as entradas do banco inseridas mais recentemente
dado que serão as informações mais relevantes (quanto mais nova a foto tirada pelo
usuário provavelmente é algo que ele tem mais interesse no momento).
• outros dados: como estamos trabalhando com um banco não relacional os outrosdados não são necessárias estruturados, e por sua vez não contém um index para
a busca, eles são apenas retornados junto com as informações de primary key e
sort key como dados do documento. As informações guardadas são o cluster mais
próximo da imagem e a distância para esse cluster.
6.2 Módulo de sugestão
Figura 9: Diagrama do fluxo do módulo de sugestão
49
6.2.1 Criação da API
Para o módulo de sugestão foi necessário montar uma estrutura de API com endpoints
para integração ext
Top Related