1

UM SISTEMA DE RECOMENDAÇÃO DE COMPRAS BASEADO EM CASOS1

Luís Fernando Bittencourt <lf@lfbittencourt.com> Fabiana Lorenzi <lorenzi@ulbra.tche.br > – Orientadora

Universidade Luterana do Brasil (Ulbra) – Curso de Ciência da Computação – Câmpus Canoas Av. Farroupilha, 8.001 – Bairro São José – CEP 92425-900 – Canoas - RS

29 de novembro de 2010

RESUMO Sem um controle maior sobre o que se consome, é impossível responder questões simples como quantos

sabonetes são gastos em um mês ou quanto tempo dura a carga de um botijão de gás. Em uma época em que economia e sustentabilidade são temas frequentes, é necessário consumir conscientemente. Assim, este artigo apresenta um Sistema de Recomendação Baseado em Casos (SRBC) que gera listas de compras a partir do histórico de consumo do usuário e permite que ele controle seu estoque a partir de qualquer dispositivo conectado a Internet.

Palavras-chave: Sistemas de Recomendação Baseados em Casos; Listas de Compras.

ABSTRACT Title: “A Shopping Case-Based Recommender System”

Without greater control over what is consumed, it is impossible answer simple questions like how many soaps are spent in a month or how long a bottled gas lasts. In times in which economics and sustainability are frequent issues, it is necessary to consume consciously. This paper presents a Case-Based Recommender Systems (CBR-RS) that generates shopping lists based on the user consumption history and allows it control its stock from any device connected to the Internet.

Key-words: Case-Based Recommender Systems; Shopping Lists.

1 INTRODUÇÃO Os últimos anos presenciaram um grande esforço da indústria para tornar eletrodomésticos mais

inteligentes, sobretudo os equipamentos de cozinha, como refrigeradores. A geladeira do futuro, por exemplo, controla seu próprio estoque, avisa sobre itens vencidos e envia pedidos de compra ao supermercado (GALILEU, 2000). Os produtos também podem ser rastreados quando são jogados no lixo, fazendo com que a geladeira registre as alterações do estoque e atualize a lista do que precisa ser comprado (BONSOR, 2001).

Além disso, esse avanço tecnológico vem ao encontro de uma necessidade cada vez maior de se controlar o que se consome, funcionando como uma evolução natural das tradicionais listas de compras e planilhas para controle de estoque. Essas ferramentas são recomendadas principalmente para evitar despesas supérfluas (CERBASI, 2004) e compras feitas no modo “piloto automático”, ou seja, às pressas e sem uma noção exata do que se necessita (MARKMAN, 2009). Sua importância fica clara em estudo feito por Gilbert e Wilson (2000), comprovando que pessoas que utilizam listas habitualmente restringem as compras aos itens listados antes de sair de casa e são menos suscetíveis à propaganda.

Entretanto, devido, em boa parte, ao custo de desenvolvimento, os eletrodomésticos do futuro ainda não são uma realidade viável para a maioria das pessoas. Tida como fundamental nos eletrodomésticos do futuro, a tecnologia de identificação Radio-Frequency IDentification (RFID), por exemplo, ainda tem um custo de aplicação até 60 vezes maior do que o código de barras (BOECK, 2007), tornando a comercialização desses equipamentos bastante restrita. Os serviços existentes, como o ZipList2, restringem sua funcionalidade à criação de listas de compras e não trazem nenhuma das funcionalidades proporcionadas pelos eletrodomésticos do futuro.

1 Proposta de Trabalho de Conclusão de Curso em Ciência da Computação, submetida ao Curso de Ciência da Computação da Universidade Luterana

do Brasil, Câmpus Canoas. 2 Disponível em http://www.ziplist.com.

2

Motivado por essas limitações, este trabalho apresenta uma solução que permite a seus usuários ter acesso a funções inteligentes dos equipamentos de ponta sem precisar substituir nenhum aparelho. Utilizando um framework de Sistemas de Recomendação Baseados em Casos (SRBC) estruturado por Lorenzi e Ricci (2005), essa aplicação auxilia na criação de listas de compras e recomenda produtos baseada nos históricos de consumo do usuário e de outras pessoas com perfil semelhante. Além disso, fornece relatórios de estoque, gastos, itens com prazo de validade vencido e outras estatísticas sobre os produtos consumidos.

Este artigo é organizado em seis seções. Na seção 2, é apresentado o referencial teórico, isto é, a contextualização dos temas abordados no trabalho. As seções 3 e 4 apresentam, respectivamente, o desenvolvimento e a implementação do sistema. Em seguida, a seção 5 descreve detalhes sobre o período de testes e validação da solução criada. Por fim, a seção 6 traz as conclusões sobre o trabalho.

2 REFERENCIAL TEÓRICO Esta seção apresenta os temas que constituem a fundamentação teórica para a compreensão deste

trabalho. São eles: Sistemas de Recomendação, Raciocínio Baseado em Casos e Sistemas de Recomendação Baseados em Casos.

2.1 Sistemas de Recomendação O principal objetivo dos sistemas de recomendação é auxiliar no processo de fazer e receber

indicações de produtos, itens ou informações (REATEGUI e CAZELLA, 2005), sugerindo ao usuário itens mais adequados a sua necessidade a medida em que aprendem sobre suas preferências (LORENZI e RICCI, 2005). A importância desse tipo de sistema fica clara em diversas situações (LOH, 2008):

• Quando o universo de escolhas é potencialmente grande ou desconhecido; • Quando o usuário não tem conhecimento ou experiência para buscar e escolher entre as opções

existentes; • Quando tem-se acesso a registros de comportamento de outras pessoas com perfis semelhantes. Sistemas de recomendação consideram basicamente o perfil do usuário, as informações de outros

usuários com perfil semelhante e o histórico de ações de ambos. As indicações podem ser feitas manualmente de usuário para usuário, de grupo para usuário ou de grupo para grupo. De acordo com Loh (2008), também é possível fazê-las utilizando Inteligência Artificial. A coleta de informações é feita implícita ou explicitamente.

Segundo Reategui e Cazella (2005), esse tipo de sistema é usado em larga escala por sítios de comércio eletrônico, que empregam diferentes técnicas para encontrar os itens de maior interesse de cada cliente e, dessa forma, aumentar a lucratividade. Também é utilizado na educação, para criação, por exemplo, de comunidades virtuais de aprendizagem (MASIERO et al., 2006).

2.1.1 Filtragem colaborativa As técnicas mais populares dos sistemas de recomendação são a filtragem colaborativa, que faz

sugestões baseada em dados do usuário (livros já lidos, por exemplo), e a filtragem baseada em conteúdo, que explora o comportamento do usuário para gerar novas indicações (LORENZI e RICCI, 2005). O primeiro tipo depende de um número grande de interações para fornecer recomendações relevantes; o segundo baseia-se unicamente no histórico de ações do usuário.

Mesmo assim, se não houver uma massa considerável de exemplos, as duas técnicas são passíveis de erro. Essa limitação motivou o surgimento de uma terceira abordagem, baseada em conhecimento, que tenta fazer melhor uso do conhecimento pré-existente a respeito do domínio da aplicação.

A filtragem colaborativa, utilizada neste trabalho para sugerir ao usuário itens comprados habitualmente por outros usuários com perfil semelhante, é um processo de filtragem de informação ou padrões que usa técnicas como colaboração entre múltiplos agentes, pontos de vista e fontes de dado. Em geral, trabalha com grandes volumes de informação e é utilizada em diferentes tipos de aplicação, como serviços de web 2.0 (CISCO, 2008).

A abordagem mais usual da filtragem colaborativa baseia-se no número de visualizações dos itens. Quando um usuário visualiza um produto pela primeira vez, por exemplo, é possível listar rapidamente quais usuários já acessaram esse item e sugerir, em ordem decrescente de popularidade, outros itens visualizados

3

por eles. Segundo a Cisco (2008), as principais desvantagens são: • O “problema Harry Potter3”, em que um item extremamente popular aparece no topo de todas as

listas, reduzindo a eficácia das recomendações; • A necessidade de se estabelecer um critério extra que determine quais interações do usuário

(visualizações, por exemplo) serão consideradas para medir a popularidade de um item; • A curva de aprendizado a ser vencida por novos itens até que possam ser recomendados.

2.2 Raciocínio Baseado em Casos Raciocínio Baseado em Casos (RBC)4 tornou-se, nos últimos anos, uma das abordagens mais

populares para o desenvolvimento de sistemas baseados em conhecimento, aplicando a experiência passada à resolução de problemas e ao aprendizado. De uma forma simplificada, pode-se dizer que o RBC é a solução de novos problemas por meio da utilização de casos anteriores já conhecidos (WANGENHEIN e WANGENHEIN, 2003).

A memória de um sistema baseado em casos, de acordo com Luger (2004), é um conjunto de soluções que podem ser coletadas junto a especialistas por meio da engenharia de conhecimento ou refletir resultados anteriores da aplicação do RBC, ou seja, seus sucessos e fracassos. No Direito há analogia plausível: advogados selecionam casos jurídicos passados similares (e favoráveis) ao de seu cliente e defendem junto ao tribunal um veredicto semelhante.

A escolha de Raciocínio Baseado em Casos como abordagem apropriada ao desenvolvimento do sistema de recomendação de compras foi influenciada principalmente por duas características:

• Sistemas de RBC podem comprovar seu raciocínio apresentando ao usuário os casos armazenados na base (KOSLOSKY, 1999 apud FERNANDES, 2003). No projeto, isso equivalerá a mostrar listas de compras realizadas para justificar a sugestão de compra de determinado produto;

• Os problemas aos quais o RBC é aplicado são tipicamente regulares e tendem à repetição. Há pequenas mudanças na interpretação de novos casos e, consequentemente, alterações mínimas na solução (KOSLOSKY, 1999 apud FERNANDES, 2003). Essa mesma regularidade é observada nos perfis de consumo, nos quais apenas 10% dos itens comprados fogem ao padrão do que é consumido habitualmente (MARKMAN, 2009).

2.2.1 Etapas do ciclo de desenvolvimento Segundo Fernandes (2003), o processo característico do Raciocínio Baseado em Casos, representado

na Figura 1, consiste da identificação do problema, busca na base de casos pelo problema com maior similaridade e aplicação dessa experiência ao problema atual. Essas etapas, comuns a todos os sistemas que implementam o RBC, podem ser detalhadas em cinco partes:

• Representação do conhecimento: em um sistema RBC, o conhecido é representado primariamente por casos que representam experiências concretas (WANGENHEIN e WANGENHEIN, 2003). Fernandes (2003) salienta, todavia, que em algumas situações pode ser necessário representar o conhecimento de algum especialista;

• Indexação: processo de catalogação dos casos, ou seja, rotulação das experiências de forma com que possam ser facilmente encontradas para uso posterior. É nessa etapa que são determinados quais atributos (índices) serão utilizados para comparar o caso de entrada com os casos da base (KOLODNER e LEAKE, 1996 apud FERNANDES, 2003; LEE, 1998 apud FERNANDES, 2003);

• Recuperação: nessa etapa, a base de casos é pesquisada em busca de casos semelhantes ao caso de entrada. De acordo com Luger (2004), a similaridade é definida com base em características comuns. Caso a etapa de indexação tenha sido bem feita, é bastante provável que os casos similares ocupem posições próximas na memória. Mesmo assim, segundo Fernandes (2003), é importante definir um limiar para que a busca não se estenda além do esperado;

• Adaptação: se necessário, essa etapa tem a função de alterar um caso recuperado para resolver o problema de entrada (LEE, 1996 apud FERNANDES, 2003), com a inclusão, eliminação ou

3 Série de livros de grande sucesso comercial escrita por J. K. Rowling. 4 Do inglês, Case-Based Reasoning (CBR).

4

substituição de parte de um comportamento (LAGEMANN, 1998 apud FERNANDES, 2003). Wangenhein e Wangenhein (2003) afirmam, porém, que sistemas avançados em RBC têm mecanismos e conhecimentos para adaptar completamente um caso para satisfazer as necessidades do problema de entrada;

• Aprendizado: armazena a solução encontrada para o problema de entrada na base de casos para uso posterior junto a um registro de sucesso ou fracasso (LUGER, 2004). De acordo com Wangenhein e Wangenhein (2003), isso é importante para manter o sistema atualizado e em constante evolução.

Figura 1 – Ciclo básico de RBC

2.3 Sistemas de Recomendação Baseados em Casos Sistemas de Recomendação Baseados em Casos (SRBC) especializam a metodologia de resolução de

problemas do RBC e possuem uma arquitetura complexa (LORENZI e RICCI, 2005). No cenário mais comum, o usuário procura algum item e é questionado pelo sistema sobre quais características desse artigo julga mais importantes. Com base nessas informações, a aplicação varre a base de casos à procura de itens que satisfaçam essas condições.

Os elementos básicos desse processo são a entrada (as informações fornecidas pelo usuário), a busca dos itens e a saída, que é o item ou conjunto de itens sugerido. Como pode-se perceber, essa operação é muito parecida com o ciclo básico do RBC, pois inicia com um novo problema, busca casos similares, exibe o melhor resultado ao usuário ou adapta-o adequadamente e retém a solução.

Segundo Lorenzi e Ricci (2005), a procura por um novo item se encaixa em três possíveis cenários: • O usuário sabe exatamente o que quer; • O usuário sabe o que quer mas não lembra o nome do produto; • O usuário não sabe exatamente o que está procurando.

Com base nessa perspectiva, os autores estruturaram um framework onde um caso pode ser decomposto em quatro subcomponentes:

5

!" ⊆ !×!×!×! Onde: • X é o modelo de conteúdo, que descreve o item recomendado ou a ser recomendado. Sua

representação mais usual é um vetor de características; • U é o modelo do usuário, que contém dados como nome, idade e endereço e informações sobre

sua utilização do sistema, como produtos preferidos; • S é o modelo da sessão, ou seja, toda a informação disponível sobre a sessão em que o item foi

recomendado; • E é o modelo de avaliação, que descreve o quanto a recomendação foi apropriada. Essa avaliação

pode ser feita pelo usuário, através de questionamento posterior, ou por meio de um algoritmo que calcule a eficácia da indicação com base em recomendações anteriores.

Lorenzi e Ricci afirmam que cada SRBC tem uma forma particular de implementar esses modelos, que podem ser vazios, textuais ou vetoriais. A maioria das implementações trabalha apenas com a camada de conteúdo, ou seja, o próprio item recomendado é considerado como caso.

O primeiro passo do ciclo de recomendação, representado na Figura 2, é a fase de recuperação, em que a base é varrida em busca de casos com potencial de recomendação. Em seguida, a fase de reúso avalia se o caso recuperado pode ser utilizado como solução ou parte da solução do novo problema. O próximo passo, a revisão, consiste em adaptar o caso de forma a atender a necessidade do usuário. Na fase de crítica, o próprio usuário pode customizar a recomendação recebida.

Figura 2 – Ciclo básico de SRBC

A etapa de iteração é implementada somente em sistemas conversacionais e consiste em repetir o ciclo de recuperação, reúso, revisão e crítica até que haja casos recomendáveis ou um dado limite de tentativas seja atingido. Uma das formas mais utilizadas consiste em apresentar um caso ao usuário e solicitar sua avaliação. Enquanto esse parecer for negativo, a consulta à base de casos é alterada e novos resultados são exibidos ao usuário.

6

Por último, a recomendação é armazenada na base de casos na fase de retenção, desenvolvendo o aprendizado do sistema. Nessa etapa também são salvas novas informações sobre o usuário, seu interesse no item do caso retido e a sessão de recomendação (BACCIGALUPO, 2007).

3 DESENVOLVIMENTO DO SISTEMA Conforme mencionado na Subseção 2.3, sistemas de recomendação baseados em casos são uma

especialização do RBC. Assim, o desenvolvimento do sistema obedeceu as etapas básicas de um sistema de Raciocínio Baseado em Casos. Após pesquisa sobre seus principais aspectos e a aquisição do conhecimento, foram definidos a representação dos casos, os atributos considerados para medida de similaridade e os algoritmos de recuperação e adaptação do caso mais apropriado ao problema de entrada.

O ciclo básico do SRBC aplicado ao projeto está ilustrado na Figura 3.

Figura 3 – ciclo básico do SRBC aplicado ao projeto

3.1 Aquisição do conhecimento A etapa de aquisição do conhecimento é considerada o componente crítico do RBC. Dessa forma, o

desenvolvimento de um sistema não pode ser baseado unicamente em senso comum, ainda que as atividades envolvidas sejam compreendidas pela maioria das pessoas. Como o processo de compras se encaixa nesse contexto, foi necessária uma imersão na literatura para formalizar o domínio da aplicação e, sobretudo, definir a representação dos casos.

Foi descoberto, por exemplo, que 9 entre cada 10 produtos comprados em todas as idas ao supermercado obedecem ao padrão do que é comprado regularmente pelo consumidor (MARKMAN, 2009). Outro dado importante levantado durante a pesquisa foi o fato de que pessoas que não utilizam listas de compras tendem a adquirir mais produtos do que o necessário (GILBERT e WILSON, 2000).

De maneira geral, há muitos fatores que podem fazer com que seja comprado mais do que o previsto. Pessoas que sentem fome durante as compras tendem a comprar mais comida do que o necessário (GILBERT e WILSON, 2000) e consumidores que não sabem exatamente o que precisam são atraídos mais

7

facilmente por promoções (MARKMAN, 2009), exemplos que reforçam a utilidade das listas de compra.

3.2 Representação do caso No sistema de recomendação desenvolvido, cada lista de compras representa um caso. Os atributos

iniciais, derivados da modelagem de dados, foram Usuário, Duração prevista das compras (em dias) e Data de criação da lista, além da listagem de itens.

Para o sistema, no entanto, o usuário em si não tem nenhuma influência no processo de comparação com outros casos. Dessa forma, esse atributo foi substituído por algumas de suas características essenciais para a filtragem colaborativa: Sexo, Idade (dedutível da data de nascimento), Número de adultos no grupo familiar, Número de crianças no grupo familiar e Renda média familiar.

As faixas de renda média familiar adotadas no projeto, listadas na Tabela 1, correspondem às classes econômicas definidas pelo Critério de Classificação Econômica Brasil (CCEB), sistema publicado pela Associação Brasileira de Empresas de Pesquisa (ABEP) para estimar o poder de compra da população brasileira (ABEP, 2010).

Tabela 1 – Faixas de renda média familiar Classe econômica Renda média familiar (valor bruto em R$)5 A1 14.366 A2 8.099 B1 4.558 B2 2.327 C1 1.391 C2 933 D 618 E 403

Como certos itens são comprados mais comumente em determinados períodos do ano, era preciso registrar a data da compra para consultas posteriores. O atributo Data de criação da lista não era um indicador confiável, já que nem sempre o usuário efetua a compra no dia em que cria a lista. Dessa forma, foi substituído por Mês de realização das compras, informação gerada no processo de check-in.

Por fim, era necessário criar parâmetros que permitissem determinar o quanto uma lista é válida como solução de um novo problema – ou seja, a criação de uma nova lista. Partindo-se do princípio de que a lista ideal é aquela em que é comprado exatamente o necessário para o período de tempo a que se propõe, foram incluídos mais cinco atributos oriundos das operações de check-in e check-out: Percentual de produtos comprados não-previstos na lista, Percentual de produtos previstos na lista não-comprados, Percentual de produtos comprados a mais do que o necessário, Percentual de produtos comprados a menos do que o necessário e Percentual de produtos cujo prazo de validade venceu antes de seu consumo.

De acordo com Wilson e Martinez (1997), os atributos podem ser lineares ou nominais. Os valores do primeiro tipo são basicamente números, enquanto que os do segundo não têm necessariamente uma ordem linear. Um atributo representando cor, por exemplo, pode conter valores como verde, amarelo e vermelho, que podem ser representados pelos valores inteiros 1, 2 e 3. Mesmo assim, usar uma métrica de distância entre dois desses valores não produz um resultado válido.

Assim, conforme apresentado no Quadro 1, cada atributo foi classificado em linear ou nominal e recebeu uma faixa de valores válidos.

Quadro 1 – Definição e tipo dos atributos Atributo Tipo Valores válidos Sexo do usuário Nominal [M, F] Idade do usuário Linear [0, ...] Número de adultos no grupo familiar Linear [0, ...] Número de crianças no grupo familiar Linear [0, ...]

5 Dados com base no Levantamento Sócio Econômico 2008 – IBOPE.

8

Atributo Tipo Valores válidos Renda média familiar Linear [403, 618, 933,

1.391, 2.327, 4.558, 8.099, 14.366]

Duração prevista das compras Linear [1, ...] Mês de realização das compras Linear [1..12] Lista de itens Nominal Vetor Percentual de produtos comprados não-previstos na lista Linear [0..1] Percentual de produtos previstos na lista não-comprados Linear [0..1] Percentual de produtos comprados a mais do que o necessário Linear [0..1] Percentual de produtos comprados a menos do que o necessário Linear [0..1] Percentual de produtos cujo prazo de validade venceu antes de seu consumo Linear [0..1]

Em seguida, foram determinados quais atributos atributos deviam ser usados para medir a similaridade dos casos, sendo identificados por índices. Além disso, cada atributo recebeu um peso, um valor de 0 a 1 indicando sua influência no processo de recuperação de casos, de forma que a soma de todos os pesos fosse igual a 1.

Os índices e seus devidos pesos estão listados na Tabela 2.

Tabela 2 – Definição dos índices e peso dos atributos Atributo Índice Peso Sexo do usuário Sim 0,03 Idade do usuário Sim 0,05 Número de adultos no grupo familiar Sim 0,15 Número de crianças no grupo familiar Sim 0,15 Renda média familiar Sim 0,1 Duração prevista das compras Sim 0,25 Mês de realização das compras Sim 0,02 Lista de itens Não – Percentual de produtos comprados não-previstos na lista Sim 0,05 Percentual de produtos previstos na lista não-comprados Sim 0,05 Percentual de produtos comprados a mais do que o necessário Sim 0,05 Percentual de produtos comprados a menos do que o necessário Sim 0,05 Percentual de produtos cujo prazo de validade venceu antes de seu consumo Sim 0,05

Assim, um caso pode ser representado conforme a Figura 4, onde a parte cinza contém os índices e a parte rosa contém os atributos não-discriminantes.

9

Figura 4 – Exemplo de caso

Contextualizada no framework de SRBC estruturado por Lorenzi e Ricci (2005), a representação do caso implementa os modelos de conteúdo (X), de usuário (U) e de avaliação (E). O modelo de sessão (S) é exclusivo de sistemas conversacionais (com suporte a iterações) e não foi implementado. A divisão de atributos e pesos nos espaços X, U e E está representada no Quadro 2.

Quadro 2 – Divisão dos atributos e pesos nos espaços X, U e E Modelo Peso Atributo Peso Usuário 0,48 Sexo do usuário 0,03

Idade do usuário 0,05 Número de adultos no grupo familiar 0,15 Número de crianças no grupo familiar 0,15 Renda média familiar 0,1

Conteúdo 0,27 Duração prevista das compras 0,25 Mês de realização das compras 0,02

Avaliação 0,25 Percentual de produtos comprados não-previstos na lista 0,05 Percentual de produtos previstos na lista não-comprados 0,05 Percentual de produtos comprados a mais do que o necessário 0,05 Percentual de produtos comprados a menos do que o necessário 0,05 Percentual de produtos cujo prazo de validade venceu antes de seu consumo 0,05

A implementação dos modelos de usuário e avaliação fazem com que o sistema de recomendação de compras suporte um processo real de aprendizado, o que não ocorre na maioria dos SRBC, que incluem apenas o modelo de conteúdo (LORENZI e RICCI, 2005).

3.3 Recuperação dos casos Os métodos mais comuns de recuperação trabalham medindo a distância entre os casos, de forma

que o menor valor é obtido na comparação com o caso mais similar ao de entrada. O resultado dessas funções, no entanto, não demonstra com clareza o quanto um caso é similar ao outro, servindo unicamente para fins de classificação. Assim, o primeiro aspecto levado em consideração na procura por uma métrica foi

10

o intervalo dos resultados, onde foram analisados apenas métodos que trabalhassem no intervalo 0..1, ou seja, 0 a 100% de similaridade ou distância. O algoritmo de recuperação também deveria funcionar tanto para atributos numéricos quanto para atributos nominais, já que a representação de casos adotada no sistema possui propriedades desses dois tipos.

Dentre as várias técnicas citadas por Wilson e Martinez (1997), a métrica que melhor atende essas duas condições se chama Heterogeneous Euclidean-Overlap Metric (HEOM), que utiliza distância euclidiana para atributos lineares e overlap para atributos nominais. Para garantir o intervalo 0..1, os valores dos atributos lineares são normalizados, ou seja, o maior passa a ser 1 e o menor é ajustado na mesma razão. Essa função define a distância entre dois valores x e y de um dado atributo a como:

!! !, ! =1, se  !  ou  !  estiver  faltando

!"#$%&' !, ! , se  !  for  categórico, senão!"_!"##! !, !

Se o atributo que está sendo calculado não existe em um dos dois casos, o resultado é 1, equivalente à distância máxima. A função overlap, que calcula a distância entre atributos nominais retornando 0 para valores iguais e 1 para valores diferentes, é definida como:

!"#$%&' !, ! = 0, se  ! = !1, caso  contrário

Já a função rn_diff, usada para calcular a distância euclidiana normalizada entre dois valores de um atributo linear, é definida como:

!"_!"##! !, ! =! − !!"#$%!

A função rangea, definida abaixo, escala o atributo até o ponto em que a diferença entre os casos é menor ou igual a 1. As variáveis maxa e mina representam, respectivamente, o maior e o menor valor observados em todo o conjunto de casos para o atributo a.

!"#$%! = !"#! −!"#!

Antes de ser utilizada no projeto, a função HEOM foi adaptada para calcular similaridade ao invés de distância, considerar os pesos definidos na Subseção 3.2 e resultar na soma do valor dos atributos. Assim, a similaridade S foi definida como:

! !, ! = !! 1 −  !! !, !!

!!!

Onde wa é o peso do atributo. Ao final do processo de comparação, verifica-se se o caso mais similar possui índice maior ou igual

ao que o usuário especificou como mínimo em suas configurações pessoais. Em caso afirmativo, a lista recuperada é adaptada (etapa detalhada na Subseção 3.4), caso contrário não há sugestão de itens.

Tabela 3 – Comparação de casos Atributo Caso 1 Caso 2 Mínimo Máximo Peso Sexo do usuário M F – – 0,03 Idade do usuário 33 27 18 48 0,05 Número de adultos no grupo familiar 1 2 1 3 0,15 Número de crianças no grupo familiar 0 1 0 2 0,15 Renda média familiar 2.327 8.099 1.391 14.366 0,1 Duração prevista das compras 30 30 7 30 0,25 Mês de realização das compras 9 5 1 12 0,02 Percentual de produtos comprados não-previstos na lista 0 0,2 0 0.48 0,05 Percentual de produtos previstos na lista não-comprados 0 0,08 0 0.3 0,05

11

Percentual de produtos comprados a mais do que o necessário 0 0,12 0 0.4 0,05 Percentual de produtos comprados a menos do que o necessário 0 0,16 0 0.32 0,05 Percentual de produtos cujo prazo de validade venceu antes de seu consumo

0 0,02 0 0.1 0,05

Como exemplo do processo de recuperação, tome-se a Tabela 3 para comparação do problema de entrada (Caso 1) com um caso qualquer da base (Caso 2). As colunas 4 e 5 representam, respectivamente, o menor e o maior valor observados em todo o conjunto de casos para cada atributo. O cálculo de similaridade resultante desses dois casos está representado na Figura 5.

S(x, y) = w1(1 – d(x1, y1)) + w2(1 – d(x2, y2)) + w3(1 – d(x3, y3)) + w4(1 – d(x4, y4)) + w5(1 – d(x5, y5)) + w6(1 – d(x6, y6)) + w7(1 – d(x7, y7)) + w8(1 – d(x8, y8)) + w9(1 – d(x9, y9)) + w10(1 – d(x10, y10)) + w11(1 – d(x11, y11)) + w12(1 – d(x12, y12)) S(x, y) = 0.03(1 – d(M,F)) + w2(1 – (|x2 - y2| / range2) + w3(1 – (|x3 - y3| / range3) + w4(1 – (|x4 - y4| / range4) + w5(1 – (|x5 - y5| / range5) + w6(1 – (|x6 - y6| / range6) + w7(1 – (|x7 - y7| / range7) + w8(1 – (|x8 - y8| / range8) + w9(1 – (|x9 - y9| / range9) + w10(1 – (|x10 - y10| / range10) + w11(1 – (|x11 - y11| / range11) + w12(1 – (|x12 - y12| / range12) S(x, y) = 0.03(1 – 1) + w2(1 – (|x2 - y2| / (max2 - min2)) + w3(1 – (|x3 - y3| / (max3 - min3)) + w4(1 – (|x4 - y4| / (max4 - min4)) + w5(1 – (|x5 - y5| / (max5 - min5)) + w6(1 – (|x6 - y6| / (max6 - min6)) + w7(1 – (|x7 - y7| / (max7 - min7)) + w8(1 – (|x8 - y8| / (max8 - min8)) + w9(1 – (|x9 - y9| / (max9 - min9)) + w10(1 – (|x10 - y10| / (max10 - min10)) + w11(1 – (|x11 - y11| / (max11 - min11)) + w12(1 – (|x12 - y12| / (max12 - min12)) S(x, y) = 0.03 × 0 + 0.05(1 – (|33 - 27| / (48 - 18)) + 0.15(1 – (|1 - 2| / (3 - 1)) + 0.15(1 – (|0 - 1| / (2 - 0)) + 0.1(1 – (|2327 - 8099| / (14366 - 1391)) + 0.25(1 – (|30 - 30| / (30 - 7)) + 0.02(1 – (|9 - 5| / (12 - 1)) + 0.05(1 – (|0 - 0.2| / (0.48 - 0)) + 0.05(1 – (|0 - 0.08| / (0.3 - 0)) + 0.05(1 – (|0 - 0.12| / (0.4 - 0)) + 0.05(1 – (|0 - 0.16| / (0.32 - 0)) + 0.05(1 – (|0 - 0.02| / (0.1 - 0)) S(x, y) = 0 + 0.05(1 – (6 / 30)) + 0.15(1 – (1 / 2)) + 0.15(1 – (1 / 2)) + 0.1(1 – (5772 / 12975)) + 0.25(1 – (0 / 23)) + 0.02(1 – (4 / 11)) + 0.05(1 – (0.2 / 0.48)) + 0.05(1 – (0.08 / 0.3)) + 0.05(1 – (0.12 / 0.4)) + 0.05(1 – (0.16 / 0.32)) + 0.05(1 – (0.02 / 0.1)) S(x, y) = 0 + 0.05(1 – 0.2) + 0.15(1 – 0.5) + 0.15(1 – 0.5) + 0.1(1 – 0.444855491) + 0.25(1 – 0) + 0.02(1 – 0.363636364) + 0.05(1 – 0.416666667) + 0.05(1 – 0.266666667) + 0.05(1 – 0.3) + 0.05(1 – 0.5) + 0.05(1 – 0.2) S(x, y) = 0 + 0.05 × 0.8 + 0.15 × 0.5 + 0.15 × 0.5 + 0.1 × 0.555144509 + 0.25 × 1 + 0.02 × 0.636363636 + 0.05 × 0.583333333 + 0.05 × 0.733333333 + 0.05 × 0.7 + 0.05 × 0.5 + 0.05 × 0.8 S(x, y) = 0 + 0.04 + 0.075 + 0.075 + 0.055514451 + 0.25 + 0.012727273 + 0.029166667 + 0.036666667 + 0.035 + 0.025 + 0.04 S(x, y) = 0.674075057

Figura 5 – Cálculo de similaridade entre os casos

É importante ressaltar que a normalização permite que a similaridade entre os casos 1 e 2 seja expressa em porcentagem (no exemplo, 67%), o que não aconteceria se tivesse sido utilizada distância euclidiana simples. Note-se também que, em um novo caso, o valor dos atributos do modelo de avaliação é sempre zero (valor ideal). Se isso não fosse feito, esses atributos seriam considerados como inexistentes e a comparação com qualquer outro caso resultaria sempre na distância máxima. Assim, até mesmo um caso com valores ideais (nenhum produto comprado sem estar previsto na lista, nenhum produto comprado em quantidade maior do que o necessária etc) seria considerado irrelevante como solução para o caso de entrada.

3.4 Adaptação do caso A etapa de recuperação, descrita na seção anterior, não leva em consideração o único atributo não-

discriminante do caso, a lista de itens. Na prática, isso significa que a base de casos é varrida em busca de listas de compras bem sucedidas, independentemente dos itens comprados. Como é pouco provável que os dois usuários comprem exatamente os mesmos produtos, o sistema precisa adaptar a lista recuperada, ou seja, reduzí-la aos itens que podem efetivamente ser sugeridos para a nova lista. Os produtos são avaliados um a um, levando-se em consideração sua recorrência nos históricos de consumo dos dois usuários.

Como exemplo, considere-se novamente os dois casos da Tabela 3. A lista recuperada da base de

12

casos (Caso 2) pertence a um usuário que já criou cinco listas de 30 dias, ao passo em que o usuário autenticado está criando sua segunda lista de compras com duração prevista de um mês. A Tabela 4 representa a ocorrência de um determinado produto nas listas dos dois usuários.

Tabela 4 – Ocorrência de um produto em dois históricos de consumo Usuário Lista 1 Lista 2 Lista 3 Lista 4 Lista 5 Usuário 1 5 0 3 3 3 Usuário 2 0 0 – – –

Para evitar que a inclusão em um grande número de listas antigas ocasione a recomendação de um

item que o usuário já não consome, a importância das ocorrências é reduzida gradativamente. Esse mecanismo é similar ao atributo drift, utilizado na técnica Interest Confidence Value (ICV) para medir o quão recentemente o usuário demonstrou interesse no produto indicado (LORENZI e RICCI, 2005).

Dessa forma, o produto só é recomendado se satisfizer a seguinte equação:

! !! + !!

!

!!!

≥  !!! + !2

Onde n é o número total de listas, l é o número da lista, ox e oy são o número de ocorrências na lista l para os casos x e y, respectivamente, e s é o índice de similaridade determinado pelo usuário em suas configurações pessoais. Caso ox ou oy não existam, é utilizado o valor 0.

Assim, se s for 0,8, tem-se o cálculo representado na Figura 6:

∑l(ox + oy) ≥ s((n2 + n) / 2) 1(ox1 + oy1) + 2(ox2 + oy2) + 3(ox3 + oy3) + 4(ox4 + oy4) + 5(ox5 + oy5) ≥ 0.8((52 + 5) / 2) 1(5 + 0) + 2(0 + 0) + 3(3 + 0) + 4(3 + 0) + 5(3 + 0) ≥ 0.8((25 + 5) / 2) 1 × 5 + 2 × 0 + 3 × 3 + 4 × 3 + 5 × 3 ≥ 0.8(30 / 2) 5 + 0 + 9 + 12 + 15 ≥ 0.8 × 15 41 ≥ 12

Figura 6 – Cálculo para verificar se determinado produto é recomendável

Como 41 é maior ou igual a 12, a equação é satisfeita e o produto é sugerido ao usuário. A quantidade será o valor arredondado da média de ocorrências descontado do estoque do usuário para aquele produto (no exemplo, ((5 + 0 + 3 + 3 + 3) / 5) - 0 = 2,8, ou seja, 3). Caso a quantidade seja menor ou igual a zero, a sugestão é descartada.

Por último, a aplicação procura itens relevantes no histórico de consumo do próprio usuário que está criando a lista. Para isso, são avaliados pelo método descrito acima todos os produtos pertencentes a listas de mesma duração prevista, desde que haja um número mínimo de duas listas criadas.

3.5 Crítica É natural que o usuário adicione itens à lista que o sistema recomendou automaticamente, pois é

pouco provável que as sugestões incluam todos os produtos que ele deseja comprar. Na etapa de crítica, o usuário também pode alterar ou remover as próprias recomendações, dando forma final ao caso que será retido – a nova lista de compras.

Para que seja possível mensurar a eficácia das recomendações, toda e qualquer interação do usuário com os itens indicados – incluindo aceitação – é registrada como crítica implícita. Assim, é possível saber, por exemplo, quantos produtos foram recomendados em quantidades erradas e quais itens sugeridos pelo sistema não eram desejados pelo usuário (falsos positivos), informações que podem ser úteis em eventuais ajustes nas etapas de recuperação e adaptação de casos.

13

3.6 Retenção Após a confirmação do usuário, a lista de compras é retida e armazenada no banco de dados, que

armazena fisicamente a base de casos da aplicação. Na prática, a etapa de retenção desenvolve a aprendizagem do sistema salva ainda novas informações sobre o usuário, seu interesse no item do caso retido e a sessão de recomendação (BACCIGALUPO, 2007).

A exemplo do que acontece no sistema DieToRecs, SRBC para a recomendação de destinos de viagem, voos e hotéis (LORENZI e RICCI, 2005), o caso é sempre armazenado na base e é atualizado toda vez que o usuário altera algum de seus componentes (fazendo check-in ou check-out de um determinado produto, por exemplo).

4 IMPLEMENTAÇÃO DO SISTEMA O sistema de recomendação de compras desenvolvido necessita de um servidor web Internet

Information Services (IIS) 7 e usa o framework ASP.NET 3.5 e linguagem de programação C#. Essas tecnologias, mantidas pela Microsoft Corporation, foram escolhidas visando o crescimento harmônico do sistema e levando em consideração o material de apoio disponível. As informações são salvas em MySQL 5.1, sistema de gerenciamento de banco de dados desenvolvido pela Oracle Corporation e utilizado pela NASA, Wikipedia e Nokia, entre outros clientes (MYSQL, 2010).

Em uma visão geral, cada usuário pode gerenciar suas listas de compras e controlar seu estoque a partir de qualquer computador conectado à Internet. Uma vez autenticado no sistema, o usuário tem cinco opções principais:

• Criação de novas listas e consulta ao histórico de compras; • Check-in ou verificação de itens, isto é, confirmação do que realmente foi comprado a partir de

determinada lista de compras; • Check-out ou descarte de itens, ou seja, registro de quando determinado item terminou de ser

consumido; • Relação de estoque, relatório de itens com prazo de validade vencido e estatísticas baseadas no

histórico de consumo; • Configurações pessoais. As próximas subseções descrevem detalhadamente cada uma dessas opções.

4.1.1 Criação de uma nova lista A criação de uma nova lista ocorre em dois passos simples. No primeiro, o usuário fornece o único

dado de entrada do sistema, informando se as compras são semanais, mensais ou têm uma duração prevista diferente, especificando-a em dias. Na sequência, procurando simular a criação de uma lista manual, o sistema oferece um único campo de texto livre para que o usuário digite sua lista. Caso o sistema tenha sugestões a fazer, o campo já vem preenchido com a quantidade e o nome dos produtos.

O texto submetido pelo usuário é interpretado linha a linha na busca de um dos seguintes padrões: quantidade-unidade-produto, quantidade-produto ou produto. Para isso, a linha é varrida da esquerda para a direita à procura de um número. Se for encontrado, esse número é salvo em memória e removido da linha, que é varrida novamente à procura de um produto já conhecido. Assim, se a linha contiver “2 caixas de pasta de dente”, por exemplo, a aplicação executa os seguintes passos:

• Encontra o número 2 e o remove da linha; • Procura por todas as combinações de palavras sequenciais possíveis a partir da frase caixas de

pasta de dente, ordenando-as do maior para o menor número de termos (caixas de pasta de dente, caixas de pasta de, de pasta de dente, caixas de pasta, de pasta de, pasta de dente, caixas de, de pasta, pasta de, de dente, caixas, de, pasta e dente);

• Caso uma das combinações seja o nome de um produto conhecido, adiciona a unidade correspondente e o nome do produto à quantidade e descarta o restante da linha;

• Caso contrário, procura por uma unidade conhecida, como quilo ou litro. Se encontrar, salva a unidade em memória e a remove da linha;

• O texto restante é sanitizado (limpo de caracteres indesejados e termos da blacklist, detalhada na Subseção 4.1.5) e passa a ser o nome do novo produto.

14

Ao finalizar a lista, o usuário pode imprimi-la ou acessá-la a partir de um dispositivo móvel através uma URL curta. Essa página contém apenas a listagem dos itens organizados por categorias e a opção de marcá-los como comprado, uma experiência próxima da que se tem com uma lista de compras tradicional.

4.1.2 Check-in Após as compras, o usuário deve informar à aplicação quais itens foram efetivamente comprados.

Para isso, deve acessar a seção Check-in e selecionar a lista de compras correspondente. Na tela, são exibidos todos os produtos listados e a quantidade que deveria ter sido comprada. Antes de finalizar a operação, o usuário deve verificar cada item, ajustar as quantidades adequadamente, remover quaisquer produtos não-comprados e adicionar eventuais itens que não haviam sido previstos. É possível ainda informar prazo de validade e preço de cada produto.

Toda e qualquer alteração da lista de compras no processo de check-in é registrada e a deprecia em consultas futuras, já que os itens comprados diferem do que foi previsto. Essas informações estão disponíveis em dois atributos: Número de produtos comprados não-previstos na lista e Número de produtos previstos na lista não-comprados.

4.1.3 Check-out Quando um produto acaba de ser consumido, o usuário deve acessar a seção Check-out, selecionar o

item correspondente e dar baixa no estoque. Caso haja mais de uma unidade do mesmo produto em estoque, o sistema elimina o item mais antigo. Esse processo é importante para mensurar a duração dos produtos e ajustar sua quantidade em novas listas. Além disso, fazer check-out evita que o sistema deixe de sugerir certos produtos por concluir erroneamente que eles ainda foram consumidos.

4.1.4 Relatórios e configurações pessoais A seção de relatórios oferece acesso rápido à relação de estoque, itens com prazo de validade

vencido e informações estatísticas baseadas no histórico de consumo. Se o usuário preencher o preço dos produtos na etapa de check-in, o sistema apresenta também o quanto tem sido gasto em compras, sendo possível visualizar essa informação por meses ou como média mensal. Para facilitar a compreensão dos dados, as estatísticas são expressas também na forma de gráficos.

As configurações pessoais são um dos pontos mais importantes do sistema, pois influenciam todo o modelo de usuário do SRBC, responsável por 48% do peso total de um caso. Assim, além de nome, e-mail e senha, é recomendável preencher corretamente sexo, data de nascimento, composição do grupo familiar e renda média familiar, pois depende desses dados a eficácia da filtragem colaborativa. Nessa seção o usuário determina ainda qual é o menor índice de similaridade aceitável para a recuperação de casos e a inclusão de produtos na etapa de adaptação.

4.1.5 Demais funcionalidades Como pode ser visto na Figura 7, o modelo de dados do sistema de recomendação de compras

permite que cada usuário seja vinculado a um conjunto de seções diferente. Enquanto os usuários comuns têm acesso limitado às seções de criação de lista, check-in, check-out, relatórios e configurações pessoais, os administradores gerenciam seções, permissões de acesso, unidades, produtos-padrão e blacklist.

15

Figura 7 – Modelo de dados

No contexto do sistema, um produto é considerado padronizado quando já foi moderado por um administrador e ligado a uma unidade-padrão, como “quilo” ou “litro”. O objetivo desse controle é manter a base de dados limpa, sem produtos duplicados ou grafados incorretamente. A blacklist, por sua vez, é uma

16

listagem de termos que devem ser ignorados quando a lista digitada pelo usuário for interpretada. Consta nessa lista, por exemplo, a preposição reduzida “de” (presente em “3 pacotes de sabão em pó”, por exemplo).

4.2 Validação e resultados De acordo com o cronograma estipulado para o projeto, 10 voluntários testaram a aplicação durante

setembro e outubro de 2010. A escolha desses testadores teve como princípio norteador a formação de um grupo heterogêneo de perfis de consumo. Dessa forma, participaram pessoas de ambos os sexos, de 18 a 48 anos, das classes econômicas A, B e C e com gastos médios mensais de supermercado entre R$ 180,00 e R$ 2.000,00. Os grupos familiares também eram variados, contendo desde pessoas que moravam sozinhas a chefes de família com até dois filhos. Em média, os testadores tinham 33 anos, gastavam cerca de R$ 668,00 em compras de supermercado e tinham um grupo familiar composto de 1,9 adultos e 0,4 crianças.

A primeira conclusão dos testes foi a de que o atributo Sexo possuía um peso superestimado na solução de novos problemas (a criação de novas listas), já que, independente do sexo do usuário, as compras são feitas para o grupo familiar, que pode conter tanto homens quanto mulheres. O peso inicial de 0,1 restringia o número de casos retornado na etapa de recuperação, pois listas criadas por usuários de gênero diferente do usuário autenticado eram depreciadas pelo algoritmo de comparação.

Assim, ainda durante o primeiro mês de testes, o peso desse atributo foi reduzido para 0,03, só não sendo excluído por haver grupos familiares de apenas um indivíduo e produtos que são comprados habitualmente por apenas um dos gêneros, como creme de barbear. O resultado dessa mudança foi o aumento no número de possíveis soluções ao problema de entrada.

Em média, cada usuário criou 2,8 listas. Observou-se que o número de listas criadas tende a diminuir a medida em que o grupo familiar aumenta, ou seja, pessoas que não moram sozinhas tendem a fazer compras para períodos mais longos, geralmente 30 dias. Por outro lado, não há relação aparente entre o número de listas criadas e a economia obtida, o que não significa, no entanto, que o sistema seja incapaz de aprender, já que um número maior de listas em determinado período de tempo significa também um número menor de itens por lista. Na média, foi relatada uma economia de 13% nas despesas com supermercado.

Os perfis de cada usuário e a economia obtida por eles estão listados no Quadro 3.

Quadro 3 – Perfil dos testadores e economia relatada Sexo Idade Renda média Gasto médio com supermercado Adultos Crianças Listas criadas Economia M 35 R$ 2.327,00 R$ 700,00 2 2 2 0% F 28 R$ 2.327,00 R$ 450,00 2 0 3 5% F 35 R$ 2.327,00 R$ 400,00 2 0 2 10% F 18 R$ 933,00 R$ 180,00 2 0 5 10% M 37 R$ 8.099,00 R$ 1.000,00 2 1 2 10% M 37 R$ 8.099,00 R$ 400,00 2 0 3 15% M 28 R$ 2.327,00 R$ 800,00 2 0 2 15% F 34 R$ 2.327,00 R$ 450,00 1 0 3 20% M 48 R$ 8.099,00 R$ 2.000,00 3 1 2 20% M 26 R$ 2.327,00 R$ 300,00 1 0 4 20%

Outro ponto observado por alguns testadores foi a pouca praticidade das operações de check-in e check-out. Na primeira, o relato mais comum foi o de que é incômodo levar as sacolas de compra até o computador conectado à Internet para marcar cada item como comprado e conferir a quantidade adquirida. Se houvesse uma versão específica para dispositivos móveis, o check-in poderia ser feito através de um telefone celular e evitaria esse inconveniente.

Sobre o processo de check-out, parte dos usuários relatou que não fez o processo de descarte tão logo o produto acabou de ser consumido. Ao invés disso, optou por check-outs periódicos, descartando vários itens de uma só vez. Como as datas de descarte e check-out são diferentes e a aplicação não permite editar esses valores, as listas acabam salvas na base de casos com três atributos potencialmente imprecisos: Número de produtos comprados a mais do que o necessário, Número de produtos comprados a menos do que o necessário e Número de produtos cujo prazo de validade venceu antes de seu consumo.

17

5 CONCLUSÃO Consumir conscientemente deixou de ser opção para tornar-se uma necessidade social e econômica.

Por outro lado, é difícil saber exatamente o quanto se consome sem tempo hábil ou ferramentas de controle mais apurado. Fazer listas de compras, nesse contexto, é uma forma comprovada de conhecer melhor o próprio estoque e de reduzir tanto o custo quanto o tempo gasto no supermercado.

Este artigo apresentou um sistema de recomendação que automatiza a criação de listas de compras indicando produtos que o usuário provavelmente necessita. Utilizando Raciocínio Baseado em Casos e técnicas de filtragem colaborativa, a aplicação varre listas de compras armazenadas anteriormente e verifica quais delas são similares a que o usuário autenticado está criando. Em seguida, filtra quais itens podem ser recomendados e apresenta os resultados ao usuário, que pode customizar a lista antes de salvá-la.

A lista de compras criada pode ser impressa ou acessada através de um dispositivo móvel. O sistema fornece ainda relatórios de estoque, gastos, itens com prazo de validade vencido e outras informações sobre o histórico de consumo, formando um conjunto de ferramentas que auxiliam o usuário a controlar melhor suas despesas com compras de supermecado.

O sistema contorna dois dos principais problemas da filtragem colaborativa, usada para recomendar produtos entre usuários com perfil semelhante. Em primeiro lugar, não há itens extremamente populares, pois a aplicação trabalha basicamente com produtos de uso cotidiano, como alimentos e produtos de limpeza, eliminando o “problema Harry Potter”. Em segundo lugar, não há necessidade de se estabelecer um critério extra para determinar quais interações do usuário devem ser consideradas durante a filtragem, pois o sistema pesquisa todas as listas salvas, sem exceção.

Por fim, foi comprovado durante a fase de testes e validação que a adoção do sistema leva o usuário a ter um controle maior sobre o que consome e, consequentemente, a economizar. Em apenas dois meses, os testadores relataram economia de até 20%, atestando os estudos sobre a eficácia das listas de compra. Considerando-se o funcionamento dos Sistemas de Raciocínio Baseados em Casos, acredita-se que reajustes dos pesos e até mesmo redefinições de atributos podem melhorar ainda mais esses resultados.

5.1 Trabalhos futuros Apesar de ter seu escopo limitado às funcionalidades básicas, o projeto possui uma arquitetura que

permite a implementação de novas funcionalidades. Dessa forma, a aplicação pode servir de base para trabalhos futuros como:

• Criação de versão para dispositivos móveis; • Integração com controles de estoque legados; • Adaptação para utilização comercial/industrial; • Integração com sistemas de compras para a realização de pedidos online; • Suporte à leitura de código de barras.

AGRADECIMENTOS Agradeço o apoio e a ajuda paciente de Art Markman, Daniele Andres, Fabiana Lorenzi, Fernando

Rossi, Marcelo e Antonio Cabeda, Renato Abrahão e Roland Teodorowitsch. Meu muito obrigado também a todos os que se dispuseram a testar o sistema, registrando pacientemente suas compras.

Esse trabalho é dedicado à memória de Adão Maurício Moreira de Oliveira, amigo que me incentivou a dar os primeiros passos no que hoje é meu meio de vida.

REFERÊNCIAS ASSOCIAÇÃO BRASILEIRA DE EMPRESAS DE PESQUISA (ABEP). Critério de Classificação Econômica Brasil, 2010. Disponível em: < http://www.abep.org/novo/CMS/Utils/FileGenerate.ashx?id=46 >. Acesso em: 29 nov. 2010.

BACCIGALUPO, Claudio. Case-based Reasoning and Recommender Systems, 2007. Disponível em: < http://www.iiia.csic.es/~claudio/keynotes/Baccigalupo-2007-ML-Exam.pdf >. Acesso em: 29 nov. 2010.

18

BOECK, Harold. Some Hot North American RFID Applications (Episode 002), 2007. Disponível em: < http://www.rfidradio.com/some-hot-north-america-rfid-applications/ >. Acesso em: 29 nov. 2010.

BONSOR, Kevin. HowStuffWorks - Como funciona a etiqueta RFID, 2007. Disponível em: < http://eletronicos.hsw.uol.com.br/etiqueta-rfid2.htm >. Acesso em: 29 nov. 2010.

CERBASI, Gustavo. Casais inteligentes enriquecem juntos. 20ª ed. São Paulo: Editora Gente, 2004, 172 p.

CISCO SYSTEMS, INC. Socially Collaborative Filtering: Give Users Relevant Content, 2008. Disponível em: < http://www.cisco.com/web/solutions/cmsg/C11-484492-00_Filtering_wp.pdf >. Acesso em: 29 nov. 2010.

FERNANDES, Anita Maria da Rocha. Inteligência Artificial: noções gerais. Florianópolis: Visual Books, 2003, 160 p.

GALILEU. Tecnovas: Câmeras de resolução baixa custam menos e produzem boas imagens, 2000. Disponível em: < http://galileu.globo.com/edic/109/tecnovas.htm >. Acesso em: 29 nov. 2010.

GILBERT, D. T.; WILSON, T. D. Miswanting: Some problems in the forecasting of future affective states. In: FORGAS, J. (Ed.), Thinking and feeling: The role of affect in social cognition. New York, 2000, p. 178-197.

LOH, Stanley. Sistemas de Recomendação, 2008. Disponível em: < http://paginas.ucpel.tche.br/~loh/recomend.htm >. Acesso em: 29 nov. 2010.

LORENZI, Fabiana; RICCI, Francesco. Case-Based Recommender Systems: a Unifying View: Universidade Luterana do Brasil e eCommerce and Tourism Research Laboratory, [2005]. 25 p.

LUGER, George F. Inteligência artificial: estruturas e estratégias para a solução de problemas complexos. 4ª ed. Porto Alegre: Bookman, 2004, 776 p.

MARKMAN, Art. Take a list to the supermarket, because you’re on autopilot, 2009. Disponível em: < http://www.psychologytoday.com/blog/ulterior-motives/200909/take-list-the-supermarket-because-you-re-autopilot >. Acesso em: 29 nov. 2010.

MASIERO, T; REATEGUI, E. B.; CAZELLA, S. C. Utilizando sistemas de recomendação na criação de comunidades virtuais de aprendizagem. In: Novas Tecnologias na Educação. Porto Alegre, 2006, 10 p.

MYSQL (2010). MySQL Customers, 2010. Disponível em: < http://www.mysql.com/customers/?id=110 >. Acesso em: 29 nov. 2010.

REATEGUI, E. B.; CAZELLA, S. C. Sistemas de Recomendação. In: XXV Congresso da Sociedade Brasileira de Computação. São Leopoldo, 2005, p. 1-3.

WANGENHEIN, Christiane Gresse von; WANGENHEIN, Aldo von. Raciocínio Baseado em Casos. Barueri: Manole, 2003, 300 p.

LORENZI, Fabiana; RICCI, Francesco. Case-Based Recommender Systems: a Unifying View: Universidade Luterana do Brasil e eCommerce and Tourism Research Laboratory, [2005]. 25 p.

WILSON, Randall; MARTINEZ, Tony R. Improved Heterogeneous Distance Functions: Brigham Young University, [1997]. 34 p.