CURSO SISTEMAS DE INFORMAÇÃO
Diogo Campos Viana Luiz
EXTRAÇÃO E COMBINAÇÃO POR SIMILARIDADE: UM ESTUDO DE CASO NAS REDES DE SUPERMERCADOS EM FLORIANÓPOLIS
Florianópolis 2022
EXTRAÇÃO E COMBINAÇÃO POR SIMILARIDADE: UM ESTUDO DE CASO NAS REDES DE SUPERMERCADOS EM FLORIANÓPOLIS.
Trabalho Conclusão do Curso, etapa de Projetos I de Graduação em Sistemas de Informação da Universidade Federal de Santa Catarina como requisito para a aprovação para cursar a etapa seguinte, Projetos II e consequentemente obter o título de Bacharel em Sistemas de Informação
Orientadora: Prof. Dra. Carina Friedrich Dorneles
Florianópolis 2022
Este trabalho de conclusão de curso é submetido ao corpo docente do Departamento de Informática e Estatística da Universidade Federal de Santa Catarina como um dos requisitos
para a obtenção do título de Bacharel em Sistemas de Informação.
________________________
Prof. Álvaro Junio Pereira Franco, Dr.
Coordenador do Curso
Banca Examinadora:
________________________
Prof.(a) Carina Friedrich Dorneles, Dr.(a) Orientador(a)
Instituição UFSC
________________________
Prof.(a) André Wüst Zibetti, Dr.(a) Avaliador(a)
Instituição UFSC
________________________
Prof.(a) Roberto Willrich, Dr.(a) Avaliador(a)
Instituição UFSC
Este trabalho é dedicado à minha mãe Maria Fátima Campos Viana Luiz, ao meu pai Pedro Viana Luiz e a todos os professores e colegas que contribuíram nesta jornada.
Agradeço ao apoio da minha família por me dar forças em momentos que pensei em desistir. A minha orientadora Carina F. Dorneles que auxiliou durante todo o processo do desenvolvimento deste trabalho. Aos colegas que auxiliaram em momentos em que em momentos de desespero sentaram comigo e me ajudaram a encontrar soluções.
Com a ascensão do comércio eletrônico, para bens de consumo básicos, a quantidade de ofertas na qual o consumidor final pode optar ao realizar compras de Supermercados aumentou muito. Considerando o cenário econômico brasileiro, cada vez mais se opta por formas de realizar economia financeira. Hoje em dia, é possível encontrar diversas ferramentas e plataformas online que realizam comparações de preços de produtos, mas a maioria das ferramentas disponíveis são focadas em eletrônicos, eletrodomésticos e outros bens que não são consumíveis. A proposta deste trabalho de conclusão de curso consiste em criar uma ferramenta para auxiliar a identificar, catalogar e classificar produtos similares através de diversos pontos de vendas de supermercados de Florianópolis. A solução proposta conta com o desenvolvimento de uma API que age como um Web scraper a fim de realizar a extração de preços de produtos de supermercados, que disponibilizam serviço de vendas online, localizados em Florianópolis. Os dados passam por um processo de transformação e normalização. Após o pré-processamento, os dados são processados por etapas definidas como integração e indexação, onde os dados extraídos são comparados através de algoritmos de similaridades a fim de combinar os produtos identificados como similares e salvar estas combinações. A ferramenta irá construir uma base de dados indexada e consolidada que facilitará a comparação de preços entre diferentes supermercados.
Palavras-chave: Wrapper; algoritmos de Similaridade; Comparação de preços; Extração de dados; Transformação de dados, Pré-processamento, Scraper, Web Scraping;
With the rise of electronic commerce, for basic consumer goods, the number of websites offer in which the final consumer can choose when making purchases from groceries stores has increased. Considering the Brazilian economic scenario, often more ways are being chosen to achieve financial savings. Nowadays, you can find several online tools and platforms that perform product price comparisons, but most of the tools available are focused on electronics, appliances and other goods that are not consumables. The purpose of this article is to develop a tool that will help to identify, catalog and classify similar products through different groceries stores. An api that acts as a Web scraper in order to extract prices from online retailers’ products, located in Florianópolis. The data will undergo a process of transformation and normalization then will the data goes through the steps of indexing and integrations, in order to identify and combine similar products. The tool will build an indexed database that will facilitate the comparison of prices between different groceries stores.
Keywords: Wrapper; Similarity algorithms; Price comparison; Data extraction; Data Transformation, Pre-processing, Scraper, Web Scraping;
Figura 1 – Exibição de histórico de produto no app Meus Preços ... 22
Figura 2 – Exibição de mapa com preços de produtos de interesse ... 23
Figura 3 – Detalhamento de uma oferta ... 24
Figura 4 – Arquitetura em camadas do WebTable2SQL ... 25
Figura 5 – Arquitetura do crawler Ifrit ... 26
Figura 6 – Visão geral da arquitetura do qFex ... 27
Figura 7 – Visão geral da arquitetura da ferramenta desenvolvida neste projeto... 30
Figura 8 – Prateleira online de um PDV ... 32
Figura 9 – Interface do Wrap Api ... 33
Figura 10 – Exemplo de JSON de produto criado através do WrapApi... 34
Figura 11 – Fluxo Geral da Ferramenta ... 34
Figura 12 – Objeto de produto capturado em formato JSON ... 35
Figura 13 – Documento do catálogo de produtos ... 41
Figura 14 – JSON exibindo a estrutura de produtos candidatos ... 42
Figura 15 – Modelo de JSON do resultado indexação com os PDVs e produtos candidatos .. 43
Figura 16 – Taxa matches 100% perfeitos ... 45
Figura 17 – Comparação com similaridade entre 90 a 99.9% na medida Jaro-Winkler ... 46
Figura 18 – Comparação com similaridade entre 80 e 89.9% na medida Jaro-Winkler ... 47
Tabela 1 – Comparação das características dos trabalhos relacionados com a ferramenta
desenvolvida neste projeto... 28
Tabela 2 – Análise quantitativa dos dados extraídos ... 32
Tabela 3 – Modelo de dados para documento de produto gerado após a transformação ... 37
Tabela 4 – Modelo de dados do objeto produto salvo product_list ... 38
Tabela 5 – Dicionário de transformação... 38
Tabela 6 – Modelo de dados do documento de histórico de produto ... 39
HTML Hypertext Markup Language SQL Structured Query Language
API Application Programming Interface APP Aplicativo
TCC Trabalho de Conclusão de Curso CSS Cascading Style Sheets
NLP Neural Language Processing URL Uniform Resource Locator LCCS Longest Common Subsequence LCS Longest Common Substring OCR Optical Character Recognition
1 INTRODUÇÃO ... 14
2 FUNDAMENTAÇÃO ... 17
2.1 EXTRAÇÃO DE DADOS NA WEB ... 17
2.1.1 Web Scrapping ... 17
2.2 PRÉ-PROCESSAMENTO DE DADOS ... 18
2.3 SIMILARIDADES DE TEXTO ... 18
2.3.1 Distância de Levenshtein ... 19
2.3.2 Distância de Jaro-Winkler ... 19
2.3.3 Maior Subsequência comum ... 20
2.3.4 Maior Substring comum ... 20
3 TRABALHOS RELACIONADOS ... 21
3.1 APLICATIVOS E PLATAFORMAS WEB ... 21
3.1.1 Meus Preços ... 21
3.1.2 Com Oferta ... 23
3.2 TRABALHOS DE CONCLUSÃO DE CURSO ... 24
3.2.1 WebTable2SQL ... 25
3.2.2 Ifrit ... 25
3.2.3 Qfex ... 27
3.3 ANÁLISE COMPARATIVA ... 28
4 DESENVOLVIMENTO DA FERRAMENTA ... 30
4.1 VISÃO GERAL ... 30
4.1.1 Ferramentas ... 31
4.2 EXTRAÇÃO DOS DADOS ... 31
4.2.1 Fonte de dados ... 31
4.2.2 Análise inicial dos dados ... 32
4.2.3 Extração dos dados ... 33
4.2.4 Qualidade dos dados ... 36
4.3 PRÉ-PROCESSAMENTO DOS DADOS ... 36
4.3.1 Limpeza dos dados ... 37
4.3.2 Transformação dos dados ... 37
4.4 INTEGRAÇÃO E INDEXAÇÃO DOS DADOS ... 39
4.4.1 Histórico de produtos ... 39
4.4.3 Indexação de Produtos ... 41
5 EXPERIMENTOS ... 44
5.1 avaliação do grau de similaridade ... 44
5.1.1 Metodologia ... 44
5.1.2 Resultados ... 45
6 CONSIDERAÇÕES FINAIS E TRABALHOS FUTUROS ... 47
REFERÊNCIAS ... 49
APÊNDICE ... 52
O crescimento do uso da tecnologia por todos já é amplamente conhecimento , situações atuais da sociedade atenuaram ainda mais o uso para tarefas diárias, principalmente atualmente, com o surgimento da pandemia causado pela covid 19. Novos serviços surgiram ou se desenvolveram a fim atender a demanda da população com suas novas necessidades.
Um estudo demonstrou que a demanda, inclusive de alimentos como frutas, hortaliças e feijão aumentou via delivery. Novos dados do setor mostram um salto de 155% no número de usuário entre março e abril de 2020 (JÚNIOR, 2021).
Na Web temos diversas ferramentas que tem como objetivo contribuir com a economia financeira do consumidor, sites como Buscapé e Zoom oferecem a proposta de varrer a Web buscando produtos similares, normalmente com foco em eletrodomésticos, eletrônicos, materiais escolares e afins, comparando preços e oferecendo ao consumidor a melhor oferta. Hoje, entretanto, a mesma proposta de serviço não é encontrada para bens de consumo, como alimentos perecíveis e produtos de higiene básica.
O desenvolvimento de um produto que compare preços de produtos de redes exige que seja desenvolvida uma ferramenta para extração, processamento e comparação de produtos, para que seja possível disponibilizar estas informações ao consumidor.
Nos trabalhos relacionados, são apresentadas algumas propostas de soluções que buscam oferecer ao consumidor a oportunidade de realizar economia em produtos de redes de supermercados. São citados Meus Preços (MEUS..., 2019) para dispositivos móveis e Com Oferta (COMOFERTA..., 2019), para plataforma Web. Ambos serviços possuem propostas similares, oferecer economia em bens de consumos considerados básicos comparando os preços através de redes de supermercados, porém apresentam falhas que são discutidas em seus capítulos.
A extração de dados é fundamental para automatizar tarefas, obter informações e identificar oportunidades. Dado ao grande volume e diferentes tipos de dados disponíveis na internet existem diversas maneiras de coletar dados. OCR é uma ferramenta que permite fazer leitura de textos a partir de imagens, é possível combinar ferramentas de extração como um web crawlling e scrapping a fim de atingir os objetivos desejados.
Entre as abordagens possíveis para o desenvolvimento dessa tarefa, o usuário pode optar por utilizar ferramentas existentes no mercado, como, Web Scrapper Api (OXYLABS, 2021) ou Data Collector (BRIGHT DATA, 2021). Através delas, é possível, desenvolver
consolidadas.
Os dados extraídos de diversas fontes da web, para este projeto, apesar de representarem a mesma entidade no mundo real, apresentam-se de diferentes formas na web, sendo necessário o uso de técnicas de similaridades para identificar produtos que representam a mesma entidade, mensurando através de estratégias e algoritmos de similaridade o quão semelhantes dois produtos distintos na Web representam a mesma entidade no mundo real.
Este projeto apresenta uma estratégia para extração de dados, de produtos de redes de supermercados de Florianópolis e região. É considerado as informações disponibilizadas em suas lojas virtuais, os produtos são identificados e extraídos, Além disso, é descrito o desenvolvimento de uma ferramenta responsável pelo processamento de dados e utilização de técnicas de similaridades de textos para identificar e indexar produtos considerados similares através de diferentes fornecedores. A ideia é possibilitar que seja possível identificar produtos realizar o “matching” de produtos iguais.
Como proposta de resolução para o problema de comparação de produtos entre diferentes redes de supermercados, é proposto o desenvolvimento de uma ferramenta de extração de dados de supermercados, pré-processamentos e indexação de dados.
Os objetivos são especificamente:
1. Extração de dados de redes de supermercados e gerar endpoints para extração através do WrapApi
2. Pré-processar os dados; identificar e remover dados sujos, transformar os dados para o formato adequado desejado.
3. Desenvolver uma ferramenta em Python que utiliza técnicas de medidas de similaridade para realizar matching de produtos
4. Construir uma base de dados com os valores obtidos das comparações e valores históricos dos produtos
5. Realização de experimentos para validar a abordagem definida.
Este trabalho está estruturado da seguinte forma: no Capítulo 2 é apresentada a fundamentação teórica, abordando os algoritmos de similaridades, técnicas de pré- processamento de dados e Web crawlers; no Capítulo 3 são apresentados os aplicativos
incorporadas ao desenvolvimento deste; no Capítulo 4 é descrita a ferramenta, a visão geral sobre a mesma, a arquitetura e sua implementação; no Capítulo 5 são apresentados os experimentos realizados e seus resultados; no Capítulo 6 são apresentadas as considerações finais e oportunidades futuras para dar continuidade a este trabalho.
2 FUNDAMENTAÇÃO
Neste capítulo são descritas definições e os conceitos necessários para melhor compreensão do projeto.
2.1 EXTRAÇÃO DE DADOS NA WEB
A internet conta com pelo menos 40 bilhões de páginas indexadas e 400 vezes mais páginas não indexadas na deep web. Estes dados estão disponíveis de diversas formas e na maioria delas em formato não estruturado.
Web Data Extraction System, ou web scrapper é uma sequência de procedimentos utilizados para extração de dados de páginas da Web (LAENDER 2002). Encontrar e acessar os sites que possuam dados procurados, utilizando crawlers ou técnicas similares e utilizar técnicas, normalmente um wrapper, para extrair e manipular os dados, transformando-os em dados estruturados.
O processo de extração e combinação de conteúdos de interesse da Web de uma forma sistemática. Em tal processo, um agente de software, também conhecido como robô, imita a interação de navegação entre os servidores da Web e o humano. Passo a passo, o robô acessa os sites conforme necessário, analisa seu conteúdo para encontrar e extrair dados de interesse e estruturar esses conteúdos conforme desejado (LOURENÇO, 2013).
2.1.1 Web Scrapping
Web Scraping que é uma forma automatizada de entrar em um determinado site e extrair informações dele. Por meio de processos automatizados, implementados utilizando um robô, o Web Scraping exporta dados de um site para um banco de dados ou uma planilha local para posterior recuperação e análise das informações extraídas.
Web Scrapping e Web Crawling, ambos são formas de usar ferramentas para automatizar o processo de extração de dados, o scrapping e mais assertivo em sua busca, é necessária uma inteligência sobre o domínio em que os dados serão extraídos e tratados.
Devido ao fato de que uma enorme quantidade de dados heterogêneos é constantemente gerada na internet, web scraping é amplamente reconhecido como uma técnica eficiente e poderá para coleta de big data
2.2 PRÉ-PROCESSAMENTO DE DADOS
O processo de análise de dados se beneficiou muito com o avanço da tecnologia e o aumento do uso dos computadores. Em 1890, o inventor Herman Hollerith, com a ajuda de uma máquina de cartões perfurados, conseguiu acelerar o tempo de realização do censo dos Estados Unidos de 7 anos para 18 meses (FOOTE, 2021)
Por mais avançada que esteja a tecnologia acerca da análise de dados atualmente, para que se possa obter conjuntos de dados mais enxutos, descritivos e que forneçam melhores resultados, o pré-processamento é de suma importância. Em adição a isso, é necessário saber que pré-processar uma base de dados do mundo real, pode solucionar problemas como atributos que não foram extraídos da melhor maneira possível, ou até mesmo ajudar a escolher atributos que forneçam mais informações para a sua análise. Ao realizar esse processo, é possível ter um maior entendimento da natureza dos dados, podendo inclusive auxiliar na construção de modelos mais robustos (FAMILI et al., 1997)
A fase de pré-processamento pode ser empregada em dois grupos gerais, tarefas fortemente dependentes de conhecimento de domínio e tarefas fracamente depende de conhecimento de domínio.
De forma geral, pré-processamento de dados é um processo semiautomático. Por semiautomático entende-se que essa fase depende da capacidade da pessoa que conduz em identificar os problemas presentes nos dados. Além da natureza desses problemas, e utilizar os métodos mais apropriados para solucionar os problemas.
2.3 SIMILARIDADES DE TEXTO
Existem diferentes abordagens para calcular a similaridade entre textos, as palavras podem ser similares de duas formas, semanticamente e lexicamente. Lexicamente caso os textos tenham as mesmas sequenciais de caracteres. Semanticamente caso os textos tenham o mesmo contexto, mas são utilizados de forma diferentes (GOMAA; FAHMY, 2013). Neste trabalho serão abordados algoritmos que realizam busca por similaridade léxica nos textos utilizando medidas de distância e medidas de sequência.
Em geral, as medidas de distâncias mapeiam a distância ou semelhança entre a descrição simbólica de dois objetos e expressa essa diferença em um valor numérico que depende de dois fatores: A própria medida e as propriedades do objeto medido.
2.3.1 Distância de Levenshtein
A distância de Levenshtein é uma métrica de distância de edição que tem como objetivo medir a diferença entre duas sequencias de strings através de operações simples como: inserção, remoção e substituição. A distância de Levenshtein é uma medida que calcula o número de operações mínimas necessárias para transformar uma sequência de caracteres em outra sequência de caracteres. Quanto menor o número, mais similares as sequências são.
(MOSLEM, 2018). Uma forma de calcular a distância Levenshtein, por exemplo, tentar metrificar o quão similar a palavra “sol” é da palavra “sala”:
1. Substituir o caractere “o” pelo caractere “a”: Sal 2. Adicionar o caractere “a” ao final: Sala
Um total de 2 operações foram realizadas – isto assumindo que todas as operações têm o mesmo peso 1 - uma substituição e uma adição. Quando o peso é o mesmo para as operações a distância é simétrica, caso contrário, é assimétrica. Para o resultado, quanto o valor, implica menos operações foram realizadas para transformar uma sequência de caracteres em outra, portanto, existe uma maior probabilidade de serem similares. Em NLP buscamos sempre minimizar esta distância, mas para casos de erros na correção de códigos, buscamos maximizar esta distância para que uma palavra-chave não seja facilmente confundida com outra.
2.3.2 Distância de Jaro-Winkler
As métricas de similaridade Jaro e Jaro-Winkler pesam os erros nos inícios das sequencias de caracteres com maior valor que os erros que ocorrem nos finais das sequências de caracteres, estes algoritmos também reduzem a penalidade para as letras que estão deslocadas nas sequências de caracteres (JARO, 1989). É assumido que erros de transcrição ocorrem mais nos inícios das sequências do que no final. Jaro-Winkler reduz a penalidade para erros envolvendo caracteres similares – “I” e “l” – e para caracteres que estão fisicamente próximos – “t” e “y” – assumindo que erros de digitação é uma fonte de desconformidade entre as combinações de sequencias de caracteres. (WINKLER, 1999)
2.3.3 Maior Subsequência comum
Para compreender sobre o algoritmo maior substring comum, é necessário saber que ele se baseia no algoritmo maior subsequência comum, que possui a seguinte definição. O comprimento da maior subsequência comum (LCCS) de duas ou mais strings é uma ótima medida de similaridade. O LCCS de um par de sequência de strings pode ser inclusive relacionado como uma unidade de medida de distância, ou número de mutações necessárias requeridas para passar de uma string para outra. (PATERSONJ; DANCÍK, 2005)
2.3.4 Maior Substring comum
O algoritmo de maior substring (LCS) comum diferencia-se da maior subsequência comum, apenas pelo princípio de buscar strings inteiras e não apenas sequencias de caracteres. Em ambos os métodos, a similaridade da string é baseada no tamanho padrão.
Para encontrar a LCS entre duas sequencias de caracteres é necessário encontrar todas as substrings de uma das sequencias de strings, preferencialmente a menor e para cada uma destas substrings, determinar se ela é uma substring da segunda sequência de substrings.
(BLUROCK, 2021). É utilizado o padrão Gestalt para matching, no cálculo em LCS recursivamente para estabelecer uma medida de similaridade no LCS O Gestalt Pattern Matching é um padrão para medidas de similaridade também conhecido como Ratcliff e é geramente utilizada em rotinas que buscam matches idênticos.
3 TRABALHOS RELACIONADOS
Neste capítulo, são apresentados os trabalhos similares ao presente trabalho de conclusão de curso. Na Seção 1.1 são explicados os aplicativos e plataformas Web relacionadas ao trabalho desenvolvido. Na Seção 1.2, são apresentadas propostas de crawlers e extratores de dados, com objetivos diversos, desenvolvidos em trabalhos de conclusão de curso da UFSC.
3.1 APLICATIVOS E PLATAFORMAS WEB
Nesta seção serão apresentados aplicativos e plataformas web que tem relação com o tema abordado neste projeto de trabalho de conclusão de curso.
3.1.1 Meus Preços
A proposta do aplicativo Meus Preços é ser um centralizados de preços cobrados por produtos e serviços oferecidos na região de São Paulo. Disponível para Android e iOS. O aplicativo oferece visualização do histórico do preço do produto conforme a Figura 1.
Figura 1 – Exibição de histórico de produto no app Meus Preços
Fonte: Meus Preços (2022)
O aplicativo tem como proposta oferecer uma gama de serviços, dentre eles:
Sincronização automática da NFP para contribuição com a plataforma, ampla cobertura de estabelecimentos, acesso ao histórico e variação de preços. O aplicativo oferece a funcionalidade de controle de gastos, para que o usuário possa realizar o controle de sua renda. A integração com o Google Maps, pode ser observada na Figura 2, permite a identificação do ponto de venda e criação de uma rota de navegação até o ponto de venda de interesse.
Figura 2 – Exibição de mapa com preços de produtos de interesse
Fonte: Meus Preços (2022)
O aplicativo não é atualizado desde 2019, por esta razão, muitas de suas funcionalidades não estão em conformes com a proposta oferecida, não sendo possível realizar a criação de uma nova conta. A interface gráfica apresentada não possui padrões de design que são amplamente adotados na indústria contemporânea, como Material Design, e tampouco é considerada uma interface intuitiva. O app não tem boas avaliações e entre as reclamações mais constantes encontram-se: “Não funciona”, “Lento” e “Não sincroniza”
(GOOGLE PLAY STORE, 2019).
3.1.2 Com Oferta
A proposta do Com Oferta é oferecer uma plataforma online, com dados inseridos por usuários. A plataforma agrega ofertas de diferentes regiões e estados do Brasil. Para que as ofertas estejam disponíveis na plataforma, é necessário que o usuário tire uma foto de uma oferta identificada e envie para a plataforma.
A plataforma oferece suporte somente a produtos que estão em com preço promocional e ao selecionar uma oferta é possível observar o histórico de alteração de preços, localização do ponto de venda da oferta de interesse, botão de acionamento automático para
calcular a rota através do Google Maps, duração da oferta e informações adicionais que podem ser observados na Figura 3.
Figura 3 – Detalhamento de uma oferta
Fonte: comoferta.com (2022)
A plataforma oferece a opção de realizar a busca por produtos de interesse, porém carece de informações atualizadas e cobertura em grande parte do território nacional. A plataforma é simples e intuitiva, porém restrita a produtos que estão em ofertas e não possui muitos dados para consulta.
3.2 TRABALHOS DE CONCLUSÃO DE CURSO
Nesta seção serão apresentados os trabalhos de conclusão de curso que tratam de assuntos similares, como webscrapping.
3.2.1 WebTable2SQL
A proposta de WebTable2SQL de Marcelo M (SCHEIDT, 2013) é oferecer uma ferramenta, definida como um crawler focado, pois procura especificamente por tabelas em sites, para extração de webtables e criação de SQL scripts.
A ferramenta, desenvolvida em JAVA, possui 61% de sucesso em extração de tabelas disponíveis nos sites destino. Focando especificamente em tabelas categorizadas, como tabelas relacionais, o WebTable2SQL considera também estruturas complexas, como tabelas aninhadas. O funcionamento difere de um crawler padrão pois existe uma camada intermediária que filtra o conteúdo extraído da página, a fim de encontrar somente páginas que tenham a tag <table>. O extrator de tabelas busca as tabelas nas páginas através das tags HTML <ul>, <ol> e <li>, ao encontrar, ele busca o header da tabela, ao identificar, a ferramenta extrai os dados e envia para a escrita em disco.
Após a extração, através do uso de heurísticas, são definidos os sujeitos e predicados para a criação dos rótulos na entidade de banco de dados. Utiliza-se então de um escritor de arquivos, SqlGenerator. Neste processo é gerado o script de criação da tabela a partir do cabeçalho. Para cada rótulo de coluna, uma nova coluna é adicionada no script que será executado para criar a entidade e inserir os dados no banco de dados relacional.
O projeto também contribuiu para o artigo Web Table Taxonomy and Formalization aceito em 2013 no SIGMOD Record. (LAUTERT; SCHEIDT; DORNELES, 2013).
Figura 4 – Arquitetura em camadas do WebTable2SQL
Fonte: WebTable2SQL (2013)
3.2.2 Ifrit
O Ifrit é uma ferramenta desenvolvida em JAVA capaz de navegar de uma página para outra a procura de formulários Web, desenvolvida como Trabalho de Conclusão de Curso por Leonardo B. (SANTOS, L. B dos, 2012).
Figura 5 – Arquitetura do crawler Ifrit
Fonte: Ifrit (2012)
A proposta do Ifrit é ser um Web Crawler focado que implementa uma heurística que consiga, na maioria dos casos, identificar, com base nas tags HTML utilizadas, se uma página da Web contém ou não um formulário. Já para o problema do reconhecimento dos rótulos, é proposto uma segunda heurística que calcula a 16 distância entre os elementos e os rótulos a fim de se encontrar o relacionamento entre eles.
Para resolver o problema da descoberta de um formulário em uma página qualquer da Web, foram definidas as características que o código HTML deve apresentar para que seja possível inferir de maneira segura a existência de um formulário, e utilizou de atributos configuráveis, para identificar estes padrões, como, distância entre os elementos, elementos visíveis ou não visíveis e forma de submissão do formulário. O algoritmo que verifica a existência de um formulário faz, basicamente, uma varredura pela árvore de elementos e uma série de testes para saber se as configurações apresentadas anteriormente estão sendo atendidas
O crawler possui precisão de 64%, em seus testes, 32 de 50 páginas avaliadas foram identificados os formulários corretamente. Para os valores referentes a rótulos, foram
considerados somente os casos em que o formulário foi reconhecido pela aplicação, pois nos outros casos o crawler nem chegou a inferir os rótulos para os componentes.
A ferramenta ainda possui algumas falhas, como a não identificação de formulários que são representados por imagens, incapacidade de reconhecer mais que um formulário por página, porém apresenta algumas vantagens a outros extratores de formulários já existentes, como tratar a página sem que seja realizado o download do conteúdo além de considerar os formulários que não estão tratados dentro da tab <form>.
3.2.3 Qfex
A proposta do Web Crawler focado e Extrator qFex - Finder and Extractor of Questionnaires (MATHIAS, G. N., 2017) é fazer a detecção de questionários em uma página qualquer da Web; e conseguir fazer a extração dos dados neles contidos, de forma genérica, para um banco de dados relacional. A ferramenta é dividida em dois componentes: Crawler e Extractor. Ambos recebem como entrada um arquivo de configuração que possui as configurações do banco de dados, da biblioteca de crawler utilizada, de seeds para a busca/extração e de valores para os parâmetros utilizados nos mesmos.
Figura 6 – Visão geral da arquitetura do qFex
Fonte: qFex (2017)
O crawler deve varrer a Web, utilizando como base as seeds fornecidas no arquivo de configuração, em busca de questionários que possuam certas características e então deve salvar seus links em um banco de dados. O Extractor, por sua vez, deve apanhar os links do banco de dados do crawler, e possivelmente também do arquivo de configuração, e extrair os dados dos questionários para uma outra base de dados.
Para realizar a detecção, e em seguida a extração, de questionários em páginas Web, foi necessário primeiro encontrar características que distinguem os questionários online de outros tipos de formulários (WebForms) quaisquer. Após a análise de diversos sites, e de vários testes, chegou-se a um conjunto de heurísticas que são utilizadas nos algoritmos do crawler e do extrator para fazer tal detecção e extração.
A precisão do crawler atingiu 94,47%, ou seja, 2137 dos links encontrados pelo crawler realmente possuíam um ou mais questionários neles. Notou-se que os outros 5,53%
de links encontrados não possuíam questionários, mas sim formulários muito grandes ou múltiplos formulários pequenos, porém próximos uns dos outros, o que acabou confundindo o algoritmo de detecção de questionários do crawler.
3.3 ANÁLISE COMPARATIVA
Nesta seção, é apresentado um comparativo entre os trabalhos analisados, elencando características importantes: (I) domínio do problema; (II) dados considerados; (III) ambiente de execução; (IV) pontos negativos; (V) método de coleta de dados; (VI) indexa registros para melhor desempenho. A Tabela 1 apresenta um comparativo entre os trabalhos relacionados e este projeto. Este projeto oferece uma estratégia de extração, matching por similaridade e indexação com alto incide de assertividade.
Tabela 1 – Comparação das características dos trabalhos relacionados com a ferramenta desenvolvida neste projeto
Característica Meus Preços Com Ofertas Web Table2SQL
Ifrit Qfex Ferramenta
proposta
Domínio do Problema
Coleta e exibição de
preços de produtos e serviços
Coleta e exibição de
preços de produtos em
ofertas em supermercado
s
Extração de Web tables e criação de scrpts SQL
de forma automática
Extraçao de webform
Extração de questionário
s de pesquisas
HTML
Extração de produtos de supermercado s, comparação
por similaridade e
indexação Dados
Considerado s
Nota fiscal eletrônica
Fotos submetidas
Conteúdo HTML
Conteúdo HTML
Conteúdo HTML
Conteúdo HTML
Ambiente Android e Web Java Java Java Python
de Execução iOS Pontos
negativo
Requer o número da nota fiscal.
Não é atualizado
desde 2019, não indexa os produtos, informaçõe
s incompleta
s
Para atualizar necessita da
entrada de dados de
clientes
Dependent e da semântica
da construção
da tabela HTML.
Não possui verificação
de resultados
para garantir a integridade
dos dados
Detecta somente formulário
s que contém
tags específicas
Detecta somente formulários
que possuem entradas de
dados
Não oferece interface para
buscas. Alta carga de dados diárias
para processament
o. Demanda alto poder de processament
o
Indexa registros
Não Não Não Não Não Sim
4 DESENVOLVIMENTO DA FERRAMENTA
Este capítulo detalha características das etapas de desenvolvimento, assim como suas características e componentes. É apresentada uma visão geral, os dados, os componentes mais relevantes e como são adaptados para funcionar a fim de atingir o objetivo do desenvolvimento.
4.1 VISÃO GERAL
Neste capítulo, é apresentado o diagrama, exibindo o fluxo com as principais etapas realizadas durante o desenvolvimento e são apresentadas as tecnologias utilizadas. Para cada etapa do diagrama, apresentada na Figura 7, será descrito em seu respectivo capítulo as abordagens utilizadas para atingir os objetivos desejados.
Figura 7 – Visão geral da arquitetura da ferramenta desenvolvida neste projeto.
4.1.1 Ferramentas
WrapApi: É uma ferramenta para extração de dados da Web através de uma interface gráfica, adotando o padrão codeless (XU, 2021). A ferramenta abstrai a necessidade de conhecimentos específicos em determinada linguagem de programação para implementação de um wrapper, disponibilizando uma api API própria que retorna os dados selecionados a serem extraídos.
Python: O backend é desenvolvido utilizando Python 3.9.0 (PYTHON..., 2020). A plataforma utilizada para desenvolver a ferramenta de indexação e integração é PyCharm Community Edition 2021.1.3.
Bibliotecas: Para o backend atender as necessidades da ferramenta, foram utilizadas bibliotecas desenvolvidas por terceiros, sendo estas as mais relevantes:
• Requests, versão 2.26.0, biblioteca que simplifica o desenvolvimento de envio e recebimento de requisições HTTP/1 (REQUESTS: ..., 2022);
• PyMongo, versão 4.0, é uma ferramenta desenvolvida em Python, com maior número de recomendações, para trabalhar com banco de dados MongoDB em Python (PYMONGO..., 2021).
• TextDistance, é uma biblioteca para Python que auxilia na comparação entre duas ou mais sequências de caracteres através de diversos algoritmos.
4.2 EXTRAÇÃO DOS DADOS
Neste capítulo são abordadas as etapas de análise inicial dos dados e o processo de extração, especificando as abordagens utilizadas para cada PDV.
4.2.1 Fonte de dados
Os dados são extraídos da Web, disponibilizados nas lojas virtuais dos pontos de vendas, onde são disponibilizados pelos supermercados para realização de compras online. Os Pontos de venda que fornecem os dados para o desenvolvimento deste trabalho são: Bistek, Imperatriz e Fort Atacadista.
Nesta etapa, não é possível quantificar objetivamente o número de produtos disponíveis por ponto de venda. Também não é transparente, nesta etapa, quais são os atributos CSS de cada site que devem ser capturados ou como o dado de produto é construído.
A Figura 8 apresenta a prateleira virtual do PDV Forte Atacadista.
Figura 8 – Prateleira online de um PDV
Fonte: Delivery Fort Atacadista (2022)
Cada ponto de venda apresenta uma estrutura de dados diferente para produto e que influencia na forma que os dados são capturados. Mais detalhes são apresentados no Capítulo 4.2.2 Análise Inicial dos Dados.
4.2.2 Análise inicial dos dados
A análise inicial dos dados tem como objetivo, verificar se os dados necessários para a realização da extração são existentes nos pontos de vendas e quantificá-los. Para cada ponto de venda, é necessário adotar estratégias específicas para extrair e avaliar os dados, estas estratégias são abordadas no Capítulo 4.2.3, Extração de Dados.
O relatório preliminar da análise inicial dos dados está apresentado na Tabela 2.
Tabela 2 – Análise quantitativa dos dados extraídos
Rede de
Supermercado
Total de Categorias Total de Subcategorias
Total de Produtos
Forte 13 79 4868
Imperatriz 12 73 4994
Bistek 12 105 11738
O supermercado Fort e Imperatriz possuem estruturas idênticas de produtos e em ambos o JSON pode ser interceptado durante a comunicação com o servidor. Esta estrutura é apresentada na Figura 12.
4.2.3 Extração dos dados
A ferramenta WrapApi é utilizada nesta etapa, Figura 10, que age conforme um wrapper, especificamente em sites de supermercado, não havendo a necessidade de implementação de um crawler, pois os domínios são conhecidos, extraindo das páginas Web os produtos que estão disponibilizados para compra.
Figura 9 – Interface do Wrap Api
Fonte: wrapapi.com (2022)
Para cada supermercado é criada uma estrutura básica de um objeto com as características de um produto e as informações necessárias do produto. Independente do formato original interceptado, (Figura 12), o Wrap Api constrói o objeto na estrutura desejada, apresentado na Figura 10, este objeto contém as informações relevantes baseado nos parâmetros desejados à extração
Figura 10 – Exemplo de JSON de produto criado através do WrapApi
{
"success": true, "data": {
"product": [ {
"subcategory_name": "Vinho TInto",
"thumbnail":"https://fortatacadista.vteximg.com.br/arquivos/ids/212763- 180-180/053.jpg?v=637448504639200000",
"link": "https://www.deliveryfort.com.br/vinho-chileno-cosecha-tarapaca- merlot-750ml/p",
"name": "Vinho Chileno Cosecha Tarapacá Merlot 750ml", "on_sale": false,
"price": "R$ 34,90"
}]
}
Fonte: WrapApi.com (2022)
A API construída no Wrap Api é parametrizável, permitindo a navegação na página do ponto de venda, categorias e subcategorias. Para acessar a API é necessário possuir as chaves criptografadas que são obtidas através da ferramenta, esta API fica disponibilizada para acesso do micro serviço Extrator.
O Extrator realiza a comunicação com a API disponibilizada pela ferramenta WrapApi, realiza a busca dos dados, o objeto já vem em um formato conhecido pelo extrator que então, realiza requisições para a API, essas requisições podem ser parametrizadas ou não, dependendo especificamente da abordagem utilizada para o site específico.
Os dados dos produtos são extraídos dos supermercados e então segue o seguinte fluxo:
padronização, salvamento, transformação e disponibilização (Figura 11).
Figura 11 - Fluxo Geral da Ferramenta
A ferramenta WrapApi é configurada para cada prateleira virtual de forma específica, desta forma, gerando um endpoints diferente para extração de produtos em diferentes pontos de venda, porém mantendo o fluxo de dados.
A extração dos dados do supermercado Fort e Imperatriz é realizada incialmente através da leitura das categorias e subcategorias. Um endpoint específico extrai estas informações e seus respectivos ids.
A extração dos produtos é realizada através de outro endpoint, que utiliza os ids das categorias e subcategorias extraídos previamente como query params, realizando a extração de forma paginada, a cada requisição 30 produtos são extraídos, outro endpoint verifica se há nova página, se houver, o processo de extração de produtos é repetido. O JSON obtido na consulta para supermercados Fort e Imperatriz estão representados na Figura 12.
Figura 12– Objeto de produto capturado em formato JSON
{
"produto_id": 6877,
"classificacao_mercadologica_id": 71, "marca_id": 1048,
"descricao": "Bebida Energética Fusion Gf 1 L", "imagem": "f71e618e-6311-4d4a-9216-75053f6b58b8.jpg", "disponivel": true,
"preco": "9.98", "priorizado": false, "quantidade_minima": "1", "quantidade_maxima": "4", "bebida_alcoolica": false,
"link": "bebida-energetica-fusion-gf-1-l", "codigo_barras": "7891991011808",
"quantidade_vendida": 0, "em_oferta": false, "oferta": null,
"quantidade_unidade_diferente": 1, "exibe_preco_original": false, "preco_original": 0,
"unidade_sigla": "GF",
"possui_unidade_diferente": false, "permitir_observacao_na_compra": false, "observacao": null,
"unidade_fracao": { "sigla": null, "quantidade": null, "fracao": 1,
"preco": 0 },
"secao_id": 71, "busca_item": null, "colecoes": null, "id": "5139"
}
Fonte: Delivery Fort Atacadista (2022)
Para o supermercado Bistek não é possível capturar o JSON trafegado, devido a programação utilizada no desenvolvimento do site, portanto, a estratégia para extrair os dados do Bistek requer conhecer o domínio do marketplace, identificar e selecionar os CSSs que contém as informações relevantes através da interface Web do Wrap Api, utilizando jQuery CSS Selectors (JQUERY, 2022), para realizar a extração das informações. O documento JSON extraído do Bistek é na verdade informações capturadas na página e montadas através do Wrap Api apresentado na Figura 11.
Para este PDV as categorias e subcategorias são parametrizadas diretamente no extrator que monta a requisição internamente e realiza a consulta para a extração dos dados.
A abordagem de navegabilidade das páginas é a mesma para todos os PDVs.
Primeiramente, encontram-se as categorias e para cada categoria, buscam-se os produtos que a esta pertencem, até a última página da categoria, então, navega-se para a próxima categoria.
O backend, desenvolvido em Python executa a chamada para a API do WrapApi com a intenção de recuperar os dados dos produtos neste momento ocorre a primeira transformação dos dados, a fim de padronizá-los.
4.2.4 Qualidade dos dados
A etapa de avaliação de qualidade, neste trabalho, tem o objetivo de verificar a estrutura que os dados são disponibilizados, verificar formatos e atributos a fim de determinar as transformações necessárias para os objetos da extração. Através da ferramenta é possível ver as informações que se deseja coletar, mas não é possível enxergar a estrutura dos dados trafegados e armazenados nos PDVs. A ferramenta WrapApi disponibiliza um plugin para navegadores que permite obter mais informações que transitam nas requisições entre os sites e os servidores, estas informações são capturadas para que seja possível avaliar a qualidade dos dados.
4.3 PRÉ-PROCESSAMENTO DOS DADOS
O pré-processamento dos dados, neste trabalho, é feito com o objetivo de sanitarizar os dados e padronizá-los. Ele inicia no processo de extração na ferramenta WrapApi, padronizando o formato dos documentos na base de dados e atuando na etapa de limpeza de dados. Nesta etapa, ocorrem transformações necessárias observadas através da exploração
inicial dos dados. Esta transformação tem como objetivo padronizar os dados para obter maior número de positivos durante a indexação do catálogo com o histórico de produtos.
4.3.1 Limpeza dos dados
Não há muitos dados a serem limpos nesta etapa, isto ocorre devido a extração dos dados ser realizada somente para produtos disponíveis no site, mesmo que o produto não possua disponibilidade de estoque ou seu preço não esteja disponível, este produto ainda será considerado na base de dados para finalidade de dados de histórico. Mas alguns dados de produtos contém um documento incompletos, estes documentos são descartados e desconsiderados na segunda etapa da transformação.
4.3.2 Transformação dos dados
A primeira etapa da transformação dos dados inicia de forma estruturada já no momento da extração, visto que cada ecommerce possui uma estrutura de dados diferente, independente que incluir diferentes estratégias de obtenção de dados, neste momento, já se inicia a transformação dos dados a fim de aproximar a um modelo comum (Tabela 3).
Tabela 3 – Modelo de dados para documento de produto gerado após a transformação
Nome do Atributo Tipo Descrição
_id ObjectId ID único aleatório gerado pelo mongo
store_name String Nome do Ponto de Venda
date_time Datetime Hora e data da extração do dado no formato UTC
categories_list Array de Categorias
Array de Categorias é constituído pelo nome e lista de subcategorias
category_name String Nome da categoria
subcategories_list Array de Subcategorias
Lista de subcategorias é constituída pelo nome e lista de produtos subcategory_name String
product_list Array de Produtos Lista de produtos, cada produto é constituído pelas características
apresentadas na tabela XX
A segunda etapa de transformação dos dados ocorre no backend. Após a extração, mas antes de salvar os dados nos bancos, os produtos são salvos em suas respectivas collections no MongoDB por dia de extração, cada ponto de venda possui sua collection e cada extração de dados gera um documento único (Tabela 4)
Tabela 4 – Modelo de dados do objeto produto salvo product_list Nome do atributo Tipo do Atributo Descrição
thumbnail String String que contém url para acessar uma imagem do produto link String String que contém url para acessar o
produto no ecommerce
name String Nome do produto
price String Preço do produto
on_sale String Indica se produto está ou não em
promoção
Para cada documento de cada ponto de venda é iterado sobre todos os produtos deste documento a fim de gerar o documento de histórico do produto. Durante este processo, o preço é validado como um preço real positivo e transformado para o tipo double. Os nomes dos produtos, categorias e subcategorias tem seus acentos removidos e todos os caracteres transformados para minúsculo.
Nesta etapa, ocorrem as transformações necessárias que foram observadas através da exploração inicial dos dados, esta transformação tem como objetivo padronizar os dados para obter maior número de similaridades durante a indexação do catálogo com o histórico de produtos. O modelo de dicionário de transformação de strings é apresentado na Tabela 5
Tabela 5 – Dicionário de transformação
Padrão Identificado Estado após transformação
Cx/cx caixa
Pct/pct pacote
Und/und unidade
Ferm/ferm fermentado
Achoc/achoc achocolatado
Choc/choc chocolate
Sorv/sorv sorvete
[$Número] seguido do caractere ‘l’. Ex.: 1,0l [$Número] litro. Ex.: 1,0 litro [$Número] seguido do caractere ‘ l’. Ex.: 1,0 l [$Número] litro. Ex.: 1,0 litro
4.4 INTEGRAÇÃO E INDEXAÇÃO DOS DADOS
Neste capítulo é apresentado o fluxo de integração e indexação dos dados
4.4.1 Histórico de produtos
O histórico de produtos é criado no após a limpeza e transformação dos dados, o objetivo do histórico de produtos é manter, para cada produto, de cada PDV, um histórico de preços e data da extração. Criando somente um registro por produto para cada PDV. Este processo ocorre após a extração dos dados. Os produtos extraídos são lidos e então identificado o mesmo produto na tabela de histórico para aquele PDV, o documento de histórico é editado então com as novas informações obtidas. Tabela 6
Tabela 6 – Modelo de dados do documento de histórico de produto Nome do atributo Tipo do Atributo Descrição
_id ObjectId Url para imagem do produto
name String Nome do produto
update_at datetime Data da última atualização do documento
category String Nome da categoria do produto
subcategory String Nome da subcategoria
thumbnail String String que contém url para acessar uma imagem do produto
link String String que contém url para acessar o
produto no ecommerce
price_history Array Array de preços que contém o preço em formato Double e a data em formato
datetime
dates_processed Array Array de data em formato datetime que indica as datas de extração que foram
processadas
Caso não seja identificado o produto, é criado um documento para o histórico de produtos e considerando que o portifólio do PDV é constantemente alterado, nem todos os produtos têm seu histórico atualizado visto que depende da disponibilização do produto no portifólio do PDV no momento da extração.
4.4.2 Catálogo de Produtos
O catálogo de produtos é a coleção que terá todos os produtos de todos os PDVs, servirá para relacionar com itens que estão no histórico de produto, esta coleção é a coleção que serve de busca para os produtos pesquisados. Esta etapa de busca não é apresentada neste trabalho de conclusão de curso, é considerado um projeto de desenvolvimento futuro.
O processo de catalogação de produtos é uma integração que ocorre uma vez, na primeira execução da aplicação, e posteriormente sempre que identificado um novo produto no portifólio. Este processo tem a finalidade de criar uma collection única para buscas de produtos, esta base única de produtos é denominada product_catalog. A collection product_catalog é gerada a partir dos dados extraídos. Neste processo, o PDV Fort originalmente para compor a base do catálogo, um total de 4.868 produtos distintos existentes no portifólio.
Para os demais PDVs é comparado se o produto consta no catálogo, se não consta, o produto é adicionado, a refência utilizada entre as collections é sempre o parâmetro ObjectId
Figura 13 - Documento do catálogo de produtos
O documento do catálogo, Figura 13, é um documento simples e com poucos parâmetros. A maioria dos parâmetros são auto descritíveis, exceto pelo parâmetro tags, este parâmetro está disponível para ser implementado seu uso em trabalhos futuros, a intenção é adicionar o uso de tags para facilitar a busca por produtos.
4.4.3 Indexação de Produtos
O processo de indexação de produtos tem como objetivo relacionar os produtos do catálogo com a collection de histórico de produtos para cada PDV através dos ObjectIds dos documentos. Para cada produto na product_catalog, através do atributo name de é realizada a consulta porsimilaridade, com todos os produtos do histórico de um determinado PDV. E
Este processo constitui em realizar uma comparação utilizando o método Longest Common Subsequence Similarity, esta função retorna o conjunto, esta função retorna a sequência de caracteres em comum para as sequências comparadas, não considerando que os elementos da subsequência estejam na mesma ordem (WANG, 2007).
Os produtos possuem, em sua maioria, múltiplas variantes, por exemplo: Amaciante 450ml, amaciante 900ml. A única diferença entre estes produtos é a quantidade. Quando aplicado diretamente um algoritmo de edição de distância, estas variantes têm um peso irrelevante para a maioria dos algoritmos existentes, mas, para o produto, este é um fator relevante de similaridade, portanto, antes da comparação utilizando a medida de edição, é realizada uma comparação buscando identificar se o produto possui descrição de quantidade e unidade, esperando um resultado positivo caso encontre a informação de quantidade na descrição do produto.
O peso inicial de um candidato é 1 e é calculado da seguinte forma: Para cada similaridade de substring encontrada na comparação adicionar 1 unidade ao peso. Se não houver similaridade na descrição de quantidade e/ou unidade do produto é descartado como candidato. Os candidatos elencados são atribuídos a uma lista e então comparados através da medida de distância Jaro-Winkler e Damerau-Levenshtein.
A candidatura é definida pelas características:
• O resultado da operação Longest Common Subsequence Similarity (index_products [name], product_catalog [name) deve ser um conjunto de substrings maior que 1;
• Ao menos uma substring deve ter quantidade de caracteres maior que 3
• Quantidade similar do volume do produto;
Se o produto em product_catalog não conseguiu identificar nenhum candidato, o processo se repete para o próximo produto até o último produto disponível em product_catalog ser comparado com todos os produtos de todos os PDVs. Com as informações de relacionamento de product_catalog e candidatura de product_history, é gerado um documento de indexação na collection index_products, com os parâmetros da Figura 14.
JSON exibindo a estrutura de produtos candidatos
Figura 14 - JSON exibindo a estrutura de produtos candidatos
{
id : 62bb53f718b9ac4605d97e09,
name_history : "amaciante de roupas concentrado comfort intense puro cuidado 1,5 litro"
score_damerau_levenshtein : 25
score_jaro_winkler: 0.8564285714285714 weight: 5
identical_words : [
"amaciante",
"roupas",
"concentrado",
"1,5",
"litro", ]
}
Considerando que existem produtos nos PDVs que não foram inicialmente catalogados, é realizada uma busca, pelo parâmetro ObjectId por todos os produtos no histórico de produto do PDV que não consta como candidato a nenhum produto em index_products. Para este produto é adicionado um novo documento na collection product_catalog em seguida, já indexado em index_products.
Ao final do processamento, um documento de indexação tem a estrutura conforme a Figura 15.
Figura 15– Modelo de JSON do resultado indexação com os PDVs e produtos candidatos
{
"product_catalog_id":{
"$oid":"62bb66882c451b76618c974b"
},
"product_catalog_name":"chocolate peccin trento dark 32g", "pdvs":[
{
"pdv_name":"fort", "candidates":[
{
"id":{
"$oid":"62bb6772ee71d70f27319dea"
},
"name_history":"biscoito waffer peccin trento recheado cheesecake de morango 32g",
"score_damerau_levenshtein":38,
"score_jaro_winkler":0.6160714285714285, "weight":2,
"identical_words":[
"peccin", "trento"
] }, { ... }, { ... },
] }, {
"pdv_name":"bistek", "candidates": [...]
}, {
"pdv_name":"imperatriz", "candidates":[...]
} ] }
5 EXPERIMENTOS
Neste capítulo, são apresentados os experimentos realizados e os resultados obtidos.
5.1 AVALIAÇÃO DO GRAU DE SIMILARIDADE
No processo de integração, a medida da distância é calculada utilizando Jaro- Winkler e Damerau-Levenshtein.
Além dos valores calculados pelos algoritmos de distância, uma medida de peso, chamada de weigth, é utilizada para verificar a quantidade de ocorrências de substrings similares dentro da sequência de caracteres do produto a ser comparado. Para cada substring similar identificada durante o processo de integração, 1 unidade é acrescentado no atributo weight. Este valor representa a quantidade de palavras iguais em ambas as sequências de caracteres.
5.1.1 Metodologia
É verificado o maior score Jaro Winkler para elencar o melhor candidato. Após isso, é esperado que este candidato tenha o maior valor de weight quando comparado com os demais. Não há tratativas especiais caso não a amostra dos produtos indexados e apresentar os resultados, como taxa de acertos, taxa de erros e outros parâmetros.
É verificado o maior score Jaro Winkler para elencar o melhor candidato. Após isso, é esperado que este candidato tenha o maior valor de weight quando comparado com os demais. Não há tratativas especiais caso não seja o maior weight.
Os seguintes passos são abordados na metodologia dos experimentos:
1. Para os documentos selecionados, os produtos devem ter candidatos elencados para os 3 PDVs
2. É selecionado o candidato com maior score Jaro-Winkler.
3. São realizadas 3 medições para avaliação dos resultados.
São avaliados os seguintes resultados:
1. Maior quantidade de matches idênticos para uma amostra de 400 produtos
2. Avaliação dos resultados para amostra de 30 produtos, quando o valor do score Jaro-Winker estiver entre 90 e 99.999 pontos na medida Jaro-Winkler. 3. Avaliação dos resultados para amostra de 30 produtos, quando o valor do
score Jaro-Winker estiver entre 80 e 89.999 pontos na medida Jaro-Winkler.
As amostras são extraídas da base de dados e tem seus modelos avaliados com o auxílio do Microsoft Excel para geração de gráficos e análise de valores. A avaliação de similaridade, apesar da contribuição da ferramenta, é um processo manual, para garantir que não haja interpretação errada dos valores comparados. São exibidas as listas de produtos originais, e produto com o qual o original foi comparado, e as medidas de valores obtidas através dos cálculos de similaridades. Estes valores são analisados e gerados os resultados apresentados no Capítulo 5.1.2.
5.1.2 Resultados
Em uma amostra de 200 produtos, é de se esperar que os produtos do ponto de venda que serviu de base para o catálogo de produtos alcance 100% de similaridade. Para outros PDVs, a situação é menos promissora. Imperatriz apresenta apenas 0,4% de matches perfeitos, ou seja, apenas um produto da amostra possui nome similar (Figura 16). Nesta comparação, tanto a medida Jaro-Winkler quando Damerau-Levenshtein apresentam o mesmo resultado.
Figura 16 – Taxa matches 100% perfeitos
Considerado um cenário onde é utilizada uma amostra de tamanho 30 e avaliado os resultados para similaridades entre os produtos que apresentam resultados entre 90 e 99.999 pontos na medida de similaridade Jaro Winkler é possível obter 28 produtos que são similares, atingindo uma margem de 93,3% de precisão para o mercado Bistek, enquanto para o Imperatriz é possível atingir uma taxa de 80,8%, Figura 16, Neste cenário, o Fort não apresenta valores pois sua taxa de assertividade é de 100%
Figura 17 – Comparação com similaridade entre 90 a 99.9% na medida Jaro-Winkler
Considerado um cenário onde é utilizada uma amostra de tamanho 30 e avaliado os resultados para similaridades que estão entre 80 e 89.999 pontos na medida de similaridade Jaro-Winkler a qualidade da assertividade é drasticamente impactada, com apenas 0,7% de assertividade para o supermercado Imperatriz e 1,4% de assertividade para o supermercado Bistek.
Figura 18 – Comparação com similaridade entre 80 e 89.9% na medida Jaro-Winkler
6 CONSIDERAÇÕES FINAIS E TRABALHOS FUTUROS
Nesta monografia foi apresentada uma solução para busca e comparação de preços através de múltiplos produtos e PDVs simultaneamente. Os resultados obtidos apesar de satisfatórios ainda podem ter um grau maior de assertividade através de implementação de mais etapas durante a integração.
A manipulação de grandes massas de dados sempre busca operar por algoritmos mais performáticos possíveis, porém, a otimização dos algoritmos e velocidade de processamento das operações não está sendo considerado neste trabalho. É observado que as operações mais custosas ocorrerão apenas uma vez por produto, por esta razão, não foram coletadas métricas de performance ou otimizar o código para obter os resultados com menor consumo de processamento e de forma mais eficiente.
Para que os resultados apresentem melhores valores, é necessário compreender ainda mais o domínio dos dados afim de realizar transformações que vão ao encontro de melhorar o grau de similaridade. É observado também, que falsos positivos costumam ser candidatos com grande potencial, isto acontece na maioria das vezes para produtos que possuem nomes grandes e que mudam apenas uma característica, como o sabor.
Conhecer o domínio e definir uma estrutura de dados mais robusta, não baseando apenas pelo nome, mas também por outros atributos como: volume, marca e sabor irão contribuir para que alcance um grau de similaridade ainda maior, porém, este
desenvolvimento envolve técnicas de aprendizagem de máquina que não foram aplicados neste trabalho.
Para trabalhos futuros, é possível elaborar novas estratégias, após dominar o domínio do problema, que ajudem a atingir um maior resultado de similaridade e que também seja mais performático.
Baseando-se nos resultados obtidos, é possível afirmar que a ferramenta possui um grau satisfatório de similaridade, porém precisa tratar exceções para produtos que não estão presente em todos os pontos de venda, a ferramenta sugere baseado na pontuação, mesmo que o produto seja completamente discrepante ou esteja indisponível. Na maioria das vezes a sugestão oferecida é um produto similar, com as mesmas características, porém não há garantias que funciona desta forma sem uma melhor definição das estruturas de dados, utilizar técnicas de aprendizagem de máquina podem contribui para melhor taxa de assertividade da ferramenta
