Raciocínio Baseado em Casos – Estendendo RP com um Framework de IA

4.1. Introdução
4.2. Representação de Casos
4.3. Recuperação de Casos e Similaridade
4.4. Laboratório #1 – CBR-Works
4.5. Reutilização e Adaptação de Casos
4.6. Laboratório #2 – CBR-Works
4.7. Aplicações (Opc.)
4.8. Bibliografia

4.1. Introdução

Nos últimos anos, o Raciocínio Baseado em Casos (RBC) surgiu como uma técnica poderosa para solução automática de problemas. RBC é aplicável de forma simples e direta a um amplo espectro de tarefas, todas tipicamente relacionadas à Inteligência Artificial (IA).

A idéia básica do enfoque de RBC é resolver um novo problema relembrando uma situação anterior similar e, então, reutilizando informação e conhecimento daquela situação [RS89].

Neste capítulo será fornecida ao aluno uma visão geral da teoria, das tecnologias e das aplicações de RBC. Para isso, abordaremos cada uma das técnicas mais importantes e forneceremos, passo a passo, um exemplo de um sistema de RBC para diagnóstico de defeitos em impressoras, o qual servirá como linha-mestra para exemplificar e explicar as metodologias e aspectos do RBC que serão descritos neste capítulo. Cada aspecto da teoria ou técnica que for sendo descrito neste capítulo será demonstrado com utilização desse exemplo.

Ao final do capítulo será realizada uma discussão sobre as vantagens do RBC em relação a outras tecnologias, em aplicação em problemas similares. Citaremos vários aspectos técnicos que serão detalhados no decorrer desta disciplina.

O objetivo deste capítulo é apresentar ao aluno uma visão panorâmica do RBC e fornecer-lhe uma compreensão inicial, fundamentada em exemplos, do que seja um sistema de RBC simples.
Ao término da leitura deste capítulo, o leitor terá uma visão geral da estrutura e funcionalidade de um sistema típico de RBC, e será capaz de vislumbrar as suas potencialidade de aplicação, sua forma de organização e as técnicas para a implementação de um sistema de RBC simples. Todos os aspectos teóricos e técnicos abordados aqui serão aprofundados e fundamentados nos capítulos sub-sequentes.

4.1.1. Usando Casos

Um grande número de exemplos da vida diária pode ser utilizado para demonstrar como seres humanos utilizam casos conhecidos como uma forma de resolução de problemas de um modo extremamente natural.
Veja alguns exemplos:

• Ao atender um novo paciente e escutar seus problemas, o médico lembra-se do histórico da doença de um outro paciente devido ao conjunto similar de sintomas, e aplica-lhe um tratamento semelhante ao que administrou ao paciente que apresentou aqueles sintomas similares: «Os problemas apresentados nos ouvidos do paciente são parecidos com um caso típico de otite média. Assim vou administrar-lhe um tratamento para otite média.».
• Um técnico de serviço de um determinado tipo de aparelhos lembra-se de um defeito similar no tipo de máquina que está tentando consertar: «Essa TV tem os mesmos problemas de uma que eu consertei na semana passada, então, também vou trocar as válvulas de saída de áudio.»
• Um profissional jurídico reforça os seus argumentos com jurisprudências semelhantes: «Esse caso deve ser decidido como no caso Santos versus de Silva.»
• Um arquiteto estuda as plantas de um prédio já existente ao planejar uma construção similar: «No ano passado fiz uma casa de praia com três quartos, na encosta de um morro, vou usar o plano daquele caso como uma base.»
• Um vendedor relata para um cliente com necessidades e características semelhantes as de um cliente anterior fatos sobre a venda com sucesso de um determinado produto: «Muitos estudantes ficam nesse hotel em Porto de Galinhas.»

Todas estas situações têm em comum o fato de que uma solução para um problema obtida no passado foi reutilizada para guiar a solução do problema na situação presente. Raciocínio Baseado em Casos (RBC) é a tecnologia de Inteligência Artificial inspirada neste modelo de cognição e comportamento humanos.

A tecnologia de RBC pode ser vista de dois pontos de vista diferentes. Pode ser considerada como uma metodologia para modelar o raciocínio e o pensamento humanos e também como uma metodologia para construir sistemas computacionais inteligentes.

4.1.2. Elementos Básicos do RBC

Os elementos básicos de um sistema de RBC são:

• Representação do Conhecimento: Em um sistema de RBC, o conhecimento é representado principalmente em forma de casos que descrevem experiências concretas. No entanto, se for necessário, também outros tipos de conhecimento sobre o domínio de aplicação podem ser armazenados em um sistema de RBC (por exemplo, casos abstratos e generalizados, tipos de dados, modelos de objetos usados como informação).
• Medida de Similaridade: Temos de ser capazes de encontrar um caso relevante para o problema atual na base de casos e responder à pergunta quando um caso relembrado for similar a um novo problema.
• Adaptação: Situações passadas representadas como casos dificilmente serão idênticas às do problema atual. Sistemas de RBC avançados têm mecanismos e conhecimento para adaptar os casos recuperados completamente, para verificar se satisfazem às características da situação presente.
• Aprendizado: Para que um sistema se mantenha atualizado e evolua continuamente, sempre que ele resolver um problema com sucesso, deverá ser capaz de lembrar dessa situação no futuro como mais um novo caso.

Nas próximas seções serão apresentados os aspectos teóricos e técnicos básicos. Cada um desses aspectos será posteriormente aprofundado.

4.2. Representação de Casos

A representação do conhecimento é um aspecto essencial do RBC. A forma principal de representação de conhecimento em um sistema de RBC são os casos. Um caso é uma peça de conhecimento contextualizado que registra um episódio em que um problema ou situação problemática foi total ou parcialmente resolvido.

Um caso representa tipicamente a descrição de uma situação (problema) conjuntamente com as experiências adquiridas (solução) durante a sua resolução, sendo visto como essa associação dos dois conjuntos de informações: descrição do problema e respectiva solução.

4.2.1. Casos representam experiências concretas

Casos podem, por exemplo, representar:

• o conjunto dos sintomas de um paciente e os passos do tratamento médico aplicado;
• a descrição dos sintomas do defeito técnico apresentado por um equipamento (por exemplo: uma impressora) e da estratégia de conserto aplicada;
• os objetivos de um processo legal e a respectiva jurisprudência;
• os requisitos para um prédio e sua respectiva planta de construção;
• a descrição de um pacote de viagem.

Um caso pode também conter outros itens, como os efeitos da aplicação da solução ou a justificativa para aquela solução e sua respectiva explicação. Pode ainda ser enriquecido por dados administrativos, como o número do caso, a data de sua criação ou o nome do engenheiro de conhecimento que o incorporou à base.

Casos contêm primordialmente experiências concretas, vividas em uma situação específica. No entanto, podemos também criar casos abstratos, que realizam a subsunção de experiências adquiridas em um conjunto de situações.

4.2.2. Casos são armazenados na Base de Casos

Para que estejam à disposição para serem reutilizados, casos são organizados e armazenados em uma base de casos (BC), um conjunto de casos apropriadamente organizados. Geralmente, uma base de casos contém experiências positivas descrevendo estratégias de solução que contribuíram com sucesso para resolver o problema descrito, de forma que possam ser reutilizadas. Experiências negativas, expressando tentativas frustradas de solução de um problema podem também ser armazenadas, com o objetivo de indicar problemas potenciais e prevenir a repetição de erros passados.

4.2.3. Repositórios de Conhecimento

Ao lado de casos, um sistema de RBC pode também incluir conhecimento geral acerca do seu domínio de aplicação. Existem quatro diferentes repositórios nos quais um sistema de RBC pode armazenar conhecimento, denominados Repositórios de Conhecimento. São:

• o vocabulário utilizado para descrever o conhecimento geral do domínio que é utilizado durante os diferentes estágios do processo de RBC. Por exemplo, um sistema help desk via Internet de um fabricante de impressoras, em que o comprador pode procurar perguntas de ajuda freqüentemente apresentadas (Frequently Asked Questions – FAQs)apenas formulando questões, necessita possuir modelado o vocabulário técnico do audiófilo, com termos como “cartucho”, “luz do estado de tinta”, “fonte de alimentação” etc;
• casos concretos experimentados no passado armazenados em uma base de casos (como descrito anteriormente). Por exemplo, o protocolo de perguntas feitas ao telefone e as respectivas respostas dadas pelos técnicos humanos da empresa dos seis últimos meses de atendimento a clientes, referente ao tempo em que o help desk desse fabricante de impressoras era por telefone (veja a figura 2.2 na página 11);
• conhecimento sobre como identificar casos que podem ser úteis para resolver o problema atual. Esta utilidade é predita pela similaridade entre as descrições do problema atual e dos casos armazenados na base utilizando-se uma medida de similaridade. Por exemplo, perguntas de clientes anteriores relacionadas ao mesmo modelo de impressora, em que o maior número de palavras-chave é o mesmo. O grau da similaridade entre dois casos é relativo e depende do domínio de aplicação. Conseqüentemente, o conceito de similaridade tem que ser modelado explícitamente em um sistema de RBC.
• conhecimento sobre como adaptar casos recuperados de forma a satisfazer completamente os requisitos da situação atual. Por exemplo, o problema presente refere-se a cartucho preto vazio, enquanto o caso mais similar refere-se a um problema do cartucho colorido. Neste caso, a solução aplicada no passado (troca da cartucho de tinta colorida) deve ser adaptada à situação atual, sugerindo, então, a troca do cartucho preto. Este conhecimento de adaptação é geralmente representado na forma de heurísticas ou regras de adaptação.

Dependendo das características da aplicação de RBC específica, o foco da representação do conhecimento pode variar de um repositório de conhecimento para outro. Discutiremos isto em detalhes na aula.

4.3. Recuperação de Casos e Similaridade

Uma das hipóteses básicas de sistemas de RBC é que problemas similares possuem soluções similares. Com base nesta hipótese, o critério a posteriori da utilidade de soluções passa a ser reduzido ao critério a priori similaridade de descrições de problema. Esta forma de se proceder é justificada pela premissa de que, em muitas aplicações, a similaridade de definições de problemas implica a aplicabilidade da solução de um sobre outro.

A eficácia de enfoques baseados em casos depende essencialmente, portanto, da escolha de um conceito de similaridade adequado para o domínio de aplicação e a estrutura dos casos usados. Este conceito de similaridade deveria permitir a estimativa da utilidade de um caso com base na similaridade observada entre a descrição do problema atual e a contida no caso.

No cerne da definição do conceito de similaridade é preciso, portanto, que esteja a questão da determinação da utilidade do caso escolhido para a solução da problemática atual. A solução descrita em um exemplo de caso escolhido pode ser útil para um novo problema, caso ela:

• permita o solucionamento do problema atual de alguma forma;
• evite a repetição de um erro anterior;
• permita um solucionamento eficiente do problema, que seja mais rápido do que, por exemplo, utilizar uma heurística passo a passo para calcular uma solução;
• ofereça a melhor solução para o problema de acordo com um critério de otimalidade qualquer;
• ofereça ao usuário uma solução cuja lógica possa ser compreendida por ele.

4.3.1. Metas de Recuperação

Em linguagem coloquial, similaridade é entendida como sendo a correspondência ou co-ocorrência de atributos ou características. No contexto do RBC, esta visão simplista deve ser tomada de forma mais diferenciada.
As aplicações de sistemas de RBC e os objetivos que almejam atingir podem ser muitos e variados. Alguns exemplos são:

• Pessoal de um Serviço de Atendimento ao Consumidor de um fabricante de impressoras pode usar um sistema de RBC de help desk para realizar o diagnóstico de um defeito descrito por um cliente, ao telefone, e indica soluções.
• Um viajante potencial pode usar um sistema de comércio eletrônico baseado em RBC, na Internet, para encontrar um pacote de viagem de acordo com as suas exigências.
• Um arquiteto pode utilizar um sistema de planejamento baseado em RBC para obter os primeiros esboços de um projeto de um prédio atendendo a um conjunto de requisitos.

Uma vez que se pode associar idéias muito diferentes com o conceito de utilidade, é necessário que primeiro se defina de maneira clara quais são os objetivos do processo de escolha de casos em um sistema baseado em casos. Um cálculo de similaridade necessita estar sempre integrado num processo cognitivo objetivo. No julgamento de similaridade existe uma dependência dos objetivos a serem atingidos pelo processo de solução do problema. Essa dependência manifesta-se, entre outras coisas, no fato de que tipos de características de um caso relevantes ao objetivo do sistema têm um papel essencial.

Uma meta de recuperação explicitamente coloca o objeto a ser reutilizado, a finalidade de sua reutilização, a tarefa relacionada à reutilização, o ponto de vista específico e o contexto particular.

4.3.2. Indexação

Para que se possa encontrar casos similares na base de casos para um problema dado, temos de definir quais atributos usaremos para realizar a comparação entre um caso e a situação presente.
Estes atributos, utilizados para a determinação de casos adequados para comparação, são denotados índices.

Assuma que, independentemente da representação de casos específica utilizada (veja Capítulo 4), um caso consista de um conjunto de entidades de informação. Uma entidade de informação (EI) é uma parte atômica de um caso ou descrição de problema. Por exemplo, em relação à representação de pares atributo-valor, cada atributo representa uma entidade de informação do caso.

Podemos então diferenciar as entidades de informação no âmbito de um caso de acordo com seu uso:

• entidades de informação utilizadas para a recuperação, também denotadas como índices;
• entidades de informação que provêm informação contextual ou de soluções do problema úteis ao usuário, mas que não são diretamente utilizadas para a recuperação, também chamadas de informações não-indexadas.

Tomemos por exemplo uma agência de viagens vendendo pacotes de viagem pela Internet. O seu sistema poderá utilizar a categoria dos hotéis, o seu país e o tipo de férias desejado (aventura, cultural, descanso) como entidades de informação indexadas. Num sistema de help desk, os sintomas do problema podem ser usados como índices, enquanto o diagnóstico e a terapia são informações não-indexadas.

4.3.3. Similaridade

Ao lado da análise e caracterização empíricas de critérios de similaridade, modelos formais também ocupam um espaço bastante grande no RBC. Modelos formais de similaridade procuram axiomatizar o processo da determinação da similaridade realizado pelo ser humano. As suposições assumidas no modelo podem então ser verificadas de forma empírica. Uma série de suposições básicas a respeito de julgamentos de similaridade são:

• Reflexividade: Um objeto ou fato é similar a si mesmo.
• Simetria: Se A é similar a B, então B também é similar a A. A simetria das características de similaridade é questionada por alguns autores, e não precisa necessariamente prevalecer. Um exemplo é a seguinte afirmação: “Ele se parece com o Presidente”. Neste caso, a similaridade de um elemento de uma categoria (a pessoa em questão) com o respectivo protótipo (o presidente) é considerada muito maior do que a similaridade do protótipo a um determinado elemento da categoria (“O Presidente se parece com este cidadão?”). A pergunta sobre a simetria dos julgamentos de similaridade será determinada muito menos pela formalização do conceito de similaridade do que pela pragmática subjacente. Em algumas aplicações pode fazer sentido desconsiderar a simetria.
• Transitividade: Se A é similar a B e B é similar a C, então A também é similar a C. A transitividade de julgamentos de similaridade é amplamente rejeitada na literatura [Wes95]. Um exemplo é a seguinte afirmativa: “Um quadrado pequeno é similar a um quadrado grande. Um quadrado grande é similar a um círculo grande. Um quadrado pequeno e um círculo grande não são similares”. A transitividade é aqui invalidada porque a pragmática subjacente foi substituída (da forma dos objetos para o tamanho dos objetos). Em virtude disso, os resultados dos dois primeiros julgamentos de similaridade não são mais passíveis de comparação. Devido a isso, podemos afirmar que a transitividade dos julgamentos de similaridade sempre será ferida, quando se argumentar a respeito da presença de diferenças pequenas. Julgamentos de similaridade que se baseiam na identidade parcial de características podem, no entanto, possuir transitividade. Observe o seguinte exemplo: “O círculo vermelho e o quadrado vermelho são parecidos. O quadrado vermelho e o triângulo vermelho são parecidos. Logo o quadrado vermelho e o triângulo vermelho são parecidos”. Neste exemplo a pragmática (comparação de cores) permaneceu constante.
• Monotonicidade: A similaridade de dois objetos cresce monotonicamente com o aumento de correspondências e a redução de diferenças. O requisito de monotonia é, à primeira vista, bastante elucidativo e necessário, uma vez que vem ao encontro da compreensão humana do conceito de similaridade. Existem, no entanto, muitos exemplos em que julgamentos de similaridade não se comportam de forma monotônica. Para a satisfação do requisito de monotonicidade é também a pragmática dos julgamentos de similaridade que vai ser o critério final. Em muitos domínios a monotonicidade é satisfeita como um requisito natural, mas não pode ser vista como uma propriedade de todos os julgamentos de similaridade.

Esta discussão das propriedades dos julgamentos de similaridade mostra que a pragmática subjacente a um determinado julgamento de similaridade tem um papel essencial na avaliação da similaridade. Essa observação implica que não é possível definir uma teoria universal da determinação de similaridade. Por causa dos múltiplos aspectos que necessitam ser levados em consideração e da incerteza inerente a estes associada, não se pode considerar o processo de seleção de casos em um sistema de RBC de forma geral como certo ou errado, mas apenas avaliá-lo como melhor ou pior no contexto de um cenário de aplicação específico.

4.3.4. Formalização do conceito de similaridade

A medida de similaridade é a formalização de uma determinada filosofia de julgamento de semelhança através de um modelo matemático concreto. No RBC se pode formalizar o conceito de similaridade por meio de três formas diferentes:

• Similaridade como Predicado
• Similaridade como Relação de Preferência
• Similaridade como Medida

A primeira idéia concebe similaridade como uma relação entre objetos ou fatos, que existe ou não existe. A segunda pressupõe a idéia de uma similaridade maior ou menor, enquanto o terceiro enfoque postula a quantificação da extensão dessa semelhança.

Provavelmente a forma mais conhecida de formalização do conceito de similaridade é a definição de uma medida numérica de distância ou similaridade. Em contraste com a utilização de uma relação de preferência, na utilização de uma medida em conjunto com informação de precedência é realizada também uma quantificação da similaridade.

Similaridade entre dois objetos, como a entendemos de forma intuitiva, recebe o nome de similaridade global em RBC. Para determinarmos a utilidade de um caso em relação a uma determinada pergunta, a similaridade global entre o caso e a pergunta deve ser determinada.

Para o exame compreensivo da similaridade entre uma questão dada e os casos na base de casos, a similaridade local entre atributos específicos pode ser considerada ao se computar a similaridade global. Como conseqüência, um caso com valores de atributo diferentes, mas que podem ainda ser similares ao procurado, não é passível de ser distinguido de outro, cujos valores são completamente diferentes. A consideração de similaridades locais permite a integração das similaridades entre atributos isolados ao cálculo da similaridade global, tornando-a muito mais sensitiva.

Durante a aula examinaremos todos os aspectos da similaridade globbal e local e suas formas de definição e cálculo.

4.4. Laboratório #1 – CBR-Works

Neste laboratório vamos ver a  parte inicial do desenvolvimento de um sistema de RBC, partindo da definição do problema e suas variáveis mais importantes até o desenvovlimento de uma aplicação simples com recuperação de casos similares e definição de medidas de similaridade simples sobre vocabulários previamente definidos.

CBR-Works

4.5. Reutilização e Adaptação de Casos

Uma vez que um caso adequado é recuperado da base de casos, a solução sugerida por este caso é objeto de uma tentativa de reutilização para a solução do problema atual. Durante este passo, dá-se uma reutilização de conhecimento de solução de problemas por meio da transferência de conhecimento (a descrição da solução) do caso anterior, conhecido, para o caso atual, ainda não solucionado.  Nesta seção examinaremos brevemente o que é necessário que um sistema de RBC seja capaz de realizar, para que tenha condições de, com ou sem interação com o usuário, aplicar ao problema atual a solução descrita para um problema similar recuperado da base de casos. Chamamos este passo de reutilização. A reutilização consiste principalmente da adaptação da solução do caso anterior ao caso atual, e as técnicas tratadas na reutilização de casos tentam resolver os problemas envolvidos na adaptação de casos, que são: quais aspectos da situação devem ser adaptados, quais modificações devem ser realizadas para esta adaptação, que método aplicar para realizar a adaptação e como controlar este processo. No correr da aula, analisaremos estes problemas e veremos técnicas para a sua solução.

Adaptação tem um papel fundamental na flexibilidade dos sistemas de RBC, e a sua capacidade de resolver novos problemas depende de sua habilidade em adaptar casos recuperados a novas circunstâncias e em sua habilidade de consertar soluções que falham ao serem aplicadas. A dificuldade maior surge quando tentamos definir como realizar a adaptação. Há muitas maneiras de se adaptar um caso, e a adaptação efetiva depende, tanto de se possuir conhecimento sobre possíveis modificações válidas, como de se possuir maneiras de selecionar quais serão apropriadas e efetivas em uma determinadas situação. Questões centrais para a adaptação de casos são:

• quais são os aspectos de uma situação (descrita por meio de um caso) que devem ser adaptados;
• quais modificações são razoáveis de serem realizadas para adaptar o caso;
• quais são os métodos de adaptação aplicáveis para modificar estes aspectos;
• como controlar o processo de adaptação para saber que as modificações estão sendo realizadas no rumo certo.

Para tornar possível a adaptação automática de casos, as técnicas desenvolvidas enfocam dois aspectos: (a) as diferenças entre o caso passado (cuja solução é conhecida e deve ser adaptada) e o caso corrente e (b) qual parte do caso recuperado pode se transferida para o caso novo. Com base nesta informação a solução proposta é consertada de forma a satisfazer completamente os requisitos da situação presente. Para esta modificação orientada à solução existe uma série de estratégias básicas de adaptação, variando desde técnicas muito simples até algumas bastante complexas.

Uma visão geral destas técnicas, que são exploradas por muitos autores da atualidade, é dada na figura abaixo:

Estratégias de Adaptação

4.6. Laboratório #2 – CBR-Works

Neste laboratório vamos ver os passos finais par o desenvolvimento de uma aplicação completa em RBC, utilizando todos os recursos de CBR-Works, inclusive com disponibilização da aplicação na Web.

Figura: Exemplo de sistema on-line para compra de carros usados.

Exemplo de Sistema On-line

4.7. Aplicações

Para prover uma visão geral da aplicação de sistemas de RBC, faremos distinção, aqui, entre o domínio de aplicação e o tipo de tarefa a ser executado pelo sistema.

4.7.1. Tarefas

A tarefa de um sistema de RBC descreve o tipo de ação para a qual o sistema será utilizado, como, por exemplo, diagnóstico, configuração, planejamento, etc. Isto determinará o tipo de problemas e de soluções, bem como a natureza das atividades a serem desenvolvidas pelo solucionador de problemas baseado em casos. Como discutimos em capítulos anteriores, tarefas podem ser classificadas em tarefas sintéticas e tarefas analíticas.

Tarefas analíticas cobrem uma ampla faixa de aplicações que compartilham determinadas características. Geralmente um novo caso é comparado àqueles da base de casos para determinar a qual tipo, categoria ou classe pertence. A solução associada ao caso mais similar dentro da classe correspondente é então apresentada. Tarefas analíticas de sistemas de RBC típicas são:

• Classificação
• Diagnóstico
• Suporte à decisão
• Tutoriais

Tarefas de síntese, por outro lado, tentam criar uma nova solução por meio da combinação de partes de soluções prévias. Exemplos de tarefas sintéticas são:

• Configuração
• Planejamento
• Projeto

Na prática, a maioria dos sistemas comerciais de RBC disponíveis suporta somente tarefas analíticas e é dedicada primordialmente à recuperação de casos.

4.7.2. Domínio de aplicação

O domínio de aplicação de um sistema de RBC é a área na qual o sistema é aplicado, por exemplo, medicina, arquitetura, administração, finanças ou engenharia mecânica. Cada domínio possui suas características próprias, que influenciam fortemente a escolha da forma de representação de conhecimento a ser utilizada. Daremos abaixo alguns exemplos de domínios, mas que não são exaustivos. Sugerimos a literatura no fim desta página para detalhes.

Classificação

O objetivo da tarefa de classificação é classificar uma nova situação ou problema em um contexto específico. Em aplicações de classificação, um problema é descrito por meio de um conjunto de sintomas ou observações e da solução para o problema; assim, o resultado da classificação é a seleção de uma ou mais classes ou categorias nas quais o problema poderia ser classificado.

Em sistemas de classificação baseados em casos, um caso representa, portanto, uma descrição de problema e sua classificação. Uma forma pela qual um classificador baseado em casos trabalha é perguntando se o novo conceito ou problema é suficientemente similar a outro do qual se sabe que possui uma determinada classificação. O sistema de RBC tenta, então, adivinhar a categoria à qual o novo problema pertence olhando o quanto as EIs importantes do novo caso correspondem a EIs importantes de categorias armazenadas na base de casos.

Diagnóstico

No diagnóstico, um conjunto de sintomas é dado e o objetivo é explicá-los. Ao contrário da classificação, o diagnóstico usualmente inclui o processo de levantamento de sintomas adicionais com o objetivo de melhorar a acurácia da solução do problema. Portanto, durante o processo de diagnóstico, testes podem ser realizados com o objetivo de obter-se valores de sintomas adicionais. Além disso, enquanto a tarefa principal continua sendo a de prover um diagnóstico, subtarefas podem objetivar encontrar diferenças entre conjuntos de observações para determinar qual teste deveria ser aplicado a seguir.

Um sistema de RBC pode utilizar casos para oferecer explicações para sintomas e também alertar sobre explicações que se mostraram erradas no passado. O diagnóstico de um caso passado não necessariamente se adapta exatamente ao novo caso, podendo ser necessário adaptá-lo por meio de conhecimento baseado em modelos do domínio.

Projeto e Configuração

Projeto e configuração são geralmente compreendidos como a construção de um artefato a partir de um conjunto de componentes dados, de forma que certas condições sejam satisfeitas, podendo ser compreendido como um problema de satisfação de restrições. O projeto introduz certo nível de criatividade, pois alguns componentes ou elementos estruturais necessários podem não ter sido explicitados na descrição do problema.

Normalmente as restrições sub-restringem o problema, possibilitando a existência de várias soluções. Algumas vezes, no entanto, o problema se encontra super-restringido, fazendo com que nenhuma solução satisfaça todas as restrições. Nestes dois contextos, sistemas de RBC oferecem várias vantagens.

Casos sugerem soluções satisfatórias para problemas sub-restringidos. As soluções podem não ser todas corretas, mas, como em problemas sub-restritos muitas soluções podem ser aplicadas e várias são apresentadas, uma delas poderá ser apropriada, e estratégias de adaptação podem ser usadas para adequá-la completamente.

Em problemas super-restringidos, casos podem sugerir um conjunto alternativo de restrições que funcionou em combinação com problemas similares no passado. Enquanto alguma adaptação ainda tem de ser realizada, uma relaxação de restrições completa e computacionalmente complexa pode ser evitada.

Suporte a Vendas

O objetivo do suporte a vendas é oferecer auxílio à venda de produtos, estimando custos ou realizando análises de mercado. Inclui também aplicações de comércio eletrônico inteligente.

A área mais ativa em RBC é o comércio eletrônico. Comércio eletrônico pode ser definido como qualquer atividade de comunicação em forma eletrônica realizada para oferecer suporte a atividades comerciais [WLW98]. Isto pode se inserir em diferentes momentos da venda, da pré-venda à pós-venda.

Durante a pré-venda, um cliente expressa um desejo e é provido com toda a informação solicitada sobre produtos e serviços. Isto geralmente é realizado com utilização de catálogos eletrônicos de produtos disponíveis pela Internet.
Durante a venda, um cliente e um agente de vendas negociam produtos e serviços, incluindo preços, descontos especiais, forma de entrega, etc. A tarefa é descobrir as necessidades do cliente e oferecer-lhe um produto ou serviço adequado. Geralmente este é um processo complexo, com muitas interações entre comprador e vendedor.

Situações de pós-venda ocorrem quando clientes enfrentam problemas com produtos ou serviços adquiridos anteriormente, ou quando necessitam de suporte adicional para efetivamente utilizarem o produto. O suporte a clientes é normalmente localizado nos call centers, em que o pessoal de atendimento oferece auxílio pelo telefone. Outras opções são as listas de FAQs na Internet.

Neste contexto, o objetivo do RBC é oferecer ao cliente serviços e facilidades melhores de seleção. Por exemplo, durante a situação de pré-venda, o RBC pode ser aplicado para oferecer catálogos de produtos inteligentes (e não apenas listas de produtos estáticas), capazes de oferecer um produto ou serviço similar, caso o requisitado pelo cliente não esteja disponível, ou, então, capazes simplesmente de oferecer um produto com base em um conjunto de características dadas pelo usuário.

4.7.3. Novos pacotes para aplicações industriais e comerciais

Orenge (Open Retrieval ENGinE)  é o nome da ferramenta que está se estabelecendo como o mais novo ambiente para desenvolvimento de sistemas de RBC. Orenge é uma ferramenta de desenvolvimento de aplicações de RBC recentemente lançada e desenvolvida em JAVA. Sua principal área de aplicação é servir para o desenvolvimento de aplicações de RBC na área de Raciocínio Baseado em Casos textual, servindo principalmente para desenvolver aplicações comerciais e industriais que lidam com grandes quantidades de texto. Orenge é uma infra-estrutura para o desenvolvimento de máquinas de busca multiconteúdo inteligentes para a gestão de conhecimento em JAVA e XML. Existe tanto para ambientes Linux como para Microsoft Windows.

Orenge foi desenvolvido pelo mesmo grupo de pesquisadores chefiado por Stefan Wess, que desenvolveu CBR-Works, tendo também sido desenvolvido na empresa tecInno/empolis Knowledge Management. Ao contrário de CBR-Works, Orenge é uma ferramenta exclusivamente para o desenvolvedor profissional, e não possui uma interface gráfica de usuário. É constituída por uma coleção de ferramentas de linha de comando, que devem ser usadas em conjunto com o editor de programas de escolha do desenvolvedor, no qual os modelos de casos, medidas de similaridade etc., são codificados seguindo a sintaxe definida por Orenge.

Como Orenge é um conjunto de ferramentas de possibilidades bastante extensas, vamos aqui descrever apenas suas características principais. Mais adiante, exemplificaremos os resultados produzidos, apresentando um site desenvolvido utilizando Orenge.

As principais ferramentas disponibilizadas por Orenge são:

• tengerine: Tengerine é um ambiente de autoria para modelos Orenge.
• orenge:Profiler: Ferramenta para a personalização da aplicação desenvolvida.
• orenge:Controller: Ferramenta para desenvolver interfaces de cliente em XML e controle de fluxo de operação.
• orenge:CaseBaseBuilder: Pode gerar diferentes tipos de representação em XML de fontes de dados textuais.
• orenge:Connect/Model: Ferramenta integrável para importar dados de fontes externas diversas.
• orenge:Observer: Uma ferramenta para habilitar a resposta automática de emails.
• orenge:Validator: Ferramenta para checagem de consistência de modelos de objetos e casos.

Orenge disponibiliza ainda ferramentas para a construção de clientes para a aplicação, estruturas de diretórios e configuração de servidores de aplicação e acesso a bancos de dados.

Como se pode ver pela breve listagem acima, Orenge inicia uma nova geração de ferramentas de RBC: a das ferramentas complexas e maduras para o desenvolvimento de aplicações comerciais. Ao contrário de CBR-Works, Orenge é uma ferramenta complexa, voltada ao profissional, e não possui o enfoque acadêmico que CBR-Works ainda possuía.

Orenge

4.8. Bibliografia

Christiane Gresse von Wangenheim; Aldo von Wangenheim. Raciocínio Baseado em Casos. Curitiba: Editora Manole, 2003. v. 1. 296 p.

Christiane Gresse von Wangenheim. Case-Based Reasoning – A Short Introduction. Relatório Técnico, Universidade do Vale do Itajaí – UNIVALI, 2002.