emc 6607 sistemas especialistas aplicados à engenharia ementa · viabilidade de sistemas...

UNIVERSIDADE FEDERAL DE SANTA CATARINA

DEPARTAMENTO DE ENGENHARIA MECÂNICA

PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA

Sistemas Especialistas aplicados à Engenharia Prof. Jonny Carlos da Silva, Dr. Eng.

1

EMC 6607

Sistemas Especialistas aplicados à Engenharia (3 créditos)

Objetivo

Apresentar os principais aspectos teóricos e práticos relacionados ao desenvolvimento de Sistemas Especialistas (SE), enfocando sua aplicação no contexto do Projeto de engenharia.

Ementa

Histórico sobre SE. Vantagens e desvantagens de SE. Componentes e ciclo de vida de um SE. Aspectos relativos à definição do domínio de conhecimento. Técnicas de aquisição e representação do conhecimento. Validação e verificação de SE. Utilização de ferramentas SHELL.

• Programa

1. Definições básicas relacionadas a SE. Distinção entre SE e Programas Convencionais. Crescimento da aplicação de SE. Definição e tipos de sistemas SHELL.

2. Viabilidade de SE para certos tipos de problemas. Estudo das características de SE atualmente utilizados em aplicações práticas. Identificação de áreas de projeto aplicáveis para SE.

3. Processo de desenvolvimento de SE - dificuldades mais comuns encontradas. Técnicas de representação do conhecimento. Definição do domínio de aplicação. Escolha da técnica mais apropriada. Seleção da ferramenta SHELL.

4. Questões Humanas relacionadas ao desenvolvimento de SE. Engenharia de conhecimento. Perfil do engenheiro de conhecimento. Questões éticas em SE.

5. Aquisição do conhecimento. Relacionamento com os especialistas do domínio. Diferentes perfis de especialistas. Aplicação de ferramentas computacionais. Protótipo inicial como instrumento para facilitar a aquisição.

6. Validação e Verificação de SE - Comparação com técnicas utilizadas em sistemas convencionais. Metodologia de validação. Casos práticos e procedimento recomendável.

7. Aplicação de ferramentas. Introdução à programação utilizando sistemas SHELL. Estrutura geral, formas de representação do conhecimento, desenvolvimento de exemplos.

Forma de apresentação do conteúdo.

• Aulas expositivas e práticas. • Demonstração de sistemas. • Utilização de recursos disponíveis na Internet.

Forma de Avaliação Trabalhos e apresentação de seminários ao longo da disciplina. Avaliação conceitual geral no final da disciplina.





2

Bibliografia Básica

1. WATERMAN, D. A., A Guide to Expert Systems, Addison-Wesley Publ. Company, 1986.

2. DYM, C.L. and LEVITT, R.E..Knowledge-based Syst. in Eng., McGraw-Hill, 1991.

3. GIARRATANO, Joseph and RILEY, Gary, Expert Systems- Principles and

Programming, Second Edition, PWS Publishing Company, 1994.

4. GONZALEZ, Avelino J. and DANKEL, Douglas D., The Engineering of Knowledge-

Based Systems- Theory and Practice, Prentice-Hall, Inc., 1993.

5. RICH, E. and KNIGHT, K.. Artificial Intelligence, McGraw-Hill Book Company, 1991.

6. SILVA, Jonny C.. Expert System Prototype for Hydraulic System Design Focusing on Concurrent Engineering Aspects. Tese de Doutorado, Engenharia Mecânica da UFSC, março 1998.

7. ALVES, Guilherme D.. Sistema Especialista Protótipo para Diagnóstico de Falhas em um Sistema Hidráulico Naval. Dissertação de Mestrado em Engenharia Mecânica. Universidade Federal de Santa Catarina, Florianópolis, abril 2001.

8. NORDLANDER, Tomas E.. AI Surveying: Artificial Intelligence in Business, Dept. of Management Science and Statistics, De Monfort University, UK, September 2001.

9. GIARRATANO, Joseph C. CLIPS User´s Guide, Version 6.2- March 2002.

10. VINADÉ, Cesar Augusto do Canto. Sistematização do processo de projeto para confiabilidade e mantenabilidade aplicado a sistemas hidraulicos e implementação de um sistema especialita. Tese de Doutorado em Engenharia Mecânica, UFSC, abril 2003.

11. PASSOS, Alexandra dos. Desenvolvimento de Sistema Especialista aplicado à Assistência Técnica: Estudo de caso em uma organização fabricante de produtos de telecomunicações. Dissertação de Mestrado em Eng. Mecânica, UFSC, março 2005.

12. Starr, R. R.. Contribuições para a detecção de vazamentos em tubulações de gás natural: uma abordagem baseada em conhecimento. Dissertação de Mestrado em Eng. Mecânica, UFSC, julho 2006.

13. Mecabô, L. Desenvolvimento de um protótipo de sistema especialista para apoio à manutenção de turbocompressores de gás natural. Dissertação de Mestrado em Eng. Mecânica, UFSC, junho 2007.

Alguns websites de interesse CLIPS: A Tool for Building Expert Systems www.ghg.net/clips/CLIPS.html Aplicações de Sistemas Especialistas www.attar.com/pages/cases.htm AI Yahoo LINKS : www.yahoo.com/Science/Computer_Science/Artificial_Intelligence/ Artificial Intelligence History: www.aaai.org/AITopics/html/history.html

Página da disciplina: www.laship.ufsc.br/jonny/sist_esp/





3

Sumário 1. Introdução

• Definições básicas relacionadas a SE.

• Distinção entre SE e Programas Convencionais.

1.1. Origem dos Sistemas Especialistas 1.1.1. Distinção entre abordagem heurística e algorítmica

1.2. Algumas distinções entre SE e programas convencionais. 1.3. Diferentes perspectivas sobre SE 1.4. Vantagens relacionadas a Sistemas Especialistas 1.5. Elementos de um Sistema Especialista 1.6. Definições 1.7. Outras Definições 1.8. Típicas diferenças entre SE e programas convencionais

2. Crescimento da Aplicação de Sistemas Especialistas 3. Viabilidade de Sistemas Especialistas para certos tipos de problemas

3.1. Adequação da área de aplicação 3.2. Disponibilidade De Recursos

4. Processo de desenvolvimento de Sistemas Especialistas 4.1. Estágios gerais no desenvolvimento de Sistemas Especialistas 4.2. O problema da plataforma 4.3. Manutenção e evolução de SE 4.4. Possíveis erros no desenvolvimento de SE

5. A definição de Qualidade em Sistemas Especialistas 6. Ciclo de vida de um Sistema Especialista

6.1. Custos de Manutenção 6.2. Diferentes modelos de ciclo de vida

7. Definição do Domínio de Aplicação e Identificação das Fontes de Conhecimento 8. Projeto da Base de Conhecimento 9. Escolha da ferramenta de desenvolvimento

9.1. Questões quanto à escolha da ferramenta 9.2. Condições de suporte da ferramenta 9.3. Confiabilidade 9.4. Mantenabilidade 9.5. Características da tarefa

10. Escolha da equipe de desenvolvimento 10.1. Escolha do Engenheiro de Conhecimento 10.2. Desvantagens de ter um especialista como EC 10.3. Escolha do líder da equipe 10.4. Escolha do especialista





4

10.5. Critérios relativos à equipe 10.5.1. Sistemas pequenos

10.5.2. Sistemas de médio porte

10.5.3. Sistemas de grande porte

10.6. Problemas relativos à interação com especialistas 10.6.1. O Especialista Cínico 10.6.2. Especialista "sumo sacerdote" no domínio 10.6.3. O Especialista paternalista 10.6.4. O Especialista incomunicável 10.6.5. O Especialista descuidado

11. Estrutura do processo de aquisição do conhecimento 11.1. A entrevista inicial 11.2. Organização das sessões para aquisição do conhecimento 11.3. Sessões para definição de conhecimento genérico 11.4. Sessões para solução de problemas específicos

12. Organização Do Conhecimento 12.1. Técnicas observacionais 12.2. Técnicas intuitivas

13. Protótipo Inicial na aquisição do conhecimento 13.1. Impacto desta abordagem sobre o perfil do EC

14. Relação entre protótipo e sistema final 15. Verificação e Validação

15.1. Comparação de Verificação e Validação (V&V) com Programas Convencionais

15.2. Verificação 15.3. Validação

15.3.1. Metodologias de Validação

15.3.2. Testes de campo

15.3.3. Validação de subsistemas

15.3.4. Quando é apropriado validar?

16. Algumas observações sobre Orientação a Objetos 17. Incerteza

17.1. Redes Bayesianas 17.1.1. Vantagens e desvantagens das Redes Bayesianas

18. Lógica Difusa (Fuzzy Logic) 18.1. Definição de termos 18.2. Operadores difusos

ANEXO 1- Roteiro do 1o trabalho ANEXO 2- Roteiro do 2o trabalho





5

Proposta de Programa (número de aulas por tópico)

1.1 Introdução - apresentação do programa. Aspectos gerais da disciplina. 01

1.2 Definições básicas sobre SE. Distinção entre SE e Programas Convencionais. 01

1.3 Crescimento da aplicação de SE. Definição e tipos de sistemas SHELL. 01

2.1 Viabilidade de SE para certos tipos de problemas. 01

2.2 Estudo das características de SE atualmente utilizados em aplicações práticas. Identificação de áreas de projeto aplicáveis para SE.

02

3.1 Processo de desenvolvimento de SE - dificuldades mais comuns encontradas. 01

3.2 Técnicas de representação do conhecimento. Definição do domínio de aplicação. Escolha da técnica mais apropriada. Seleção da ferramenta SHELL.

03

4.1 Questões Humanas relacionadas ao desenvolvimento de SE. Engenharia de conhecimento. Perfil do engenheiro de conhecimento. Questões éticas em SE.

02

5.1 Aquisição do conhecimento. Relacionamento com os especialistas do domínio. Diferentes perfis de especialistas.

01

5.2 Aplicação de ferramentas computacionais. Protótipo inicial como instrumento para facilitar a aquisição.

01

6.1 Validação e Verificação de SE - Comparação com técnicas utilizadas em sistemas convencionais.

01

6.2 Metodologia de validação. Casos práticos e procedimento recomendável. 01

7.1 Aplicação de ferramentas. Introdução à programação utilizando sistemas SHELL. Estrutura geral e desenvolvimento de exemplos

05

7.2 Seminários de avaliação 02





6

1. Introdução

• Definições básicas relacionadas a SE.

• Distinção entre SE e Programas Convencionais.

1.1. Origem dos Sistemas Especialistas

No início dos anos 70, os pesquisadores em IA reconheceram que o conhecimento

genérico para solução de problemas e as técnicas de busca desenvolvidas na década anterior

eram insuficientes para resolver os problemas em fase de pesquisa e orientados a aplicações

da época. Eles concluíram:

O que era necessário era conhecimento específico sobre um domínio de

aplicaçãoparticular e limitado, em vez de conhecimento genérico aplicado a vários domínios.

Esta conclusão levou ao desenvolvimento de sistemas baseados em conhecimento ou

sistemas especialistas (SE). Desde sua origem, a área de sistemas especialistas tornou-se um

dos principais tópicos da IA.

De simples conceitos gerados em pesquisas esta área evoluiu para uma indústria de

milhões de dólares em aplicações práticas.

O conhecimento representado em SE é de especialistas de um domínio. Uma parte deste

conhecimento é composta de relações de causa e efeito. Estas relações ou regras práticas

(rules of thumb) originam-se da experiência dos especialistas e são comumente denominadas

heurísticas.

As heurísticas representam conhecimento informal, ou atalhos, que permitem um

especialista rapidamente pesquisar a solução de um problema sem ter que realizar uma

análise detalhada de uma situação particular, porque ou uma análise de um problema similar

já foi realizada, com êxito, anteriormente ou uma relação foi aprendida de uma tentativa mal

sucedida de um problema similar.

O especialista pode até nem se lembrar de todos os detalhes da análise anterior, mas

reconhece que se uma abordagem já funcionou a contento, a mesma abordagem irá

provavelmente se adequar a um problema similar em questão.





7

Uma heurística frequentemente fornece uma solução correta para um problema.

Contudo, considerando que isto não representa uma análise exaustiva, pode ocasionalmente

fornece respostas incorretas ou mesmo falhar em prover qualquer resposta. Esta falha em ser

sempre bem sucedida é baseada na aplicação de uma escolha "aceitável" em vez de uma

resposta completamente certa.

Isto ocorre porque:

• Algumas vezes o número de possibilidades a serem examinadas pode ser muito

grande.

• Uma avaliação algorítmica aplicada a cada possibilidade para verificar se esta é uma

resposta correta e muito complexa, ou

• A avaliação algorítmica é desconhecida e deve ser aproximada.

Um especialista é uma pessoa que possui habilidades que lhe permite concluir a partir de

experiências e rapidamente focalizar no núcleo de um dado problema. Enquanto um não-

especialista pode abordar um problema de forma sistemática, empregando uma metodologia

orientada e procedural (caso esta realmente exista), esta abordagem pode ser muito

complicada e suscetível a erros ou ainda pode necessitar um esforço e tempo inaceitáveis.

Este uso cego de uma metodologia pode ser resultado de um entendimento limitado a respeito

do domínio de conhecimento e suas relações de causa e efeito.

Um especialista, por outro lado, tem um maior êxito na solução de problema, pois já

adquiriu um conjunto valioso de relações de causa e efeito com base em sua experiência.

Um especialista é capaz de usar este conhecimento básico para rapidamente reconhecer as

características relevantes de um problema, categorizá-lo de acordo com tais características e

corretamente definir uma solução.

1.1.1. Distinção entre abordagem heurística e algorítmica

Exemplo: Um potencial comprador de uma residência, com plano arquitetônico definido

deseja uma estimativa de custo antes de comprometer-se em fechar o contrato com um

construtor.





8

Caso 1: Um certo construtor determinar o preço da obra após uma análise detalhada dos

custos.

Isto envolve calcular cuidadosamente a quantidade de material necessário para obra;

contatar um fornecedor de materiais para obter lista de preços; avaliar cotações de

empreiteiras sobre o custo de mão-de-obra; determinar as taxas de supervisão; permitir uma

adequada margem para contingências, etc. Este processo tem a vantagem de praticamente

garantir o resultado preciso (considerando inexistência de erros de cálculo) e implica em

muito pouco risco para o construtor. Todavia, a desvantagem é que isto envolve um

considerável esforço e tempo. O que acontece se o comprador precisa a cotação para hoje?

Caso 2: Um construtor especialista.

Um construtor especialista tem uma outra opção. Ele compara o tamanho desta casa

com outras que já tenha construído. Ao encontrar uma obra com aproximadamente a

mesma metragem, ele obtém uma estimativa inicial (baseada em experiência) do preço por

metro quadrado. Então analisa as diferenças entre as construções que podem aumentar ou

reduzir a estimativa. Tais diferenças podem incluir inclusões como uma piscina

(aumentando em cerca de $15 mil), simplificações nas instalações de cozinha (reduzindo em

$1,5 mil) ou exclusão do tipo menor número de banheiros (reduzindo em $6 mil). Após

avaliar tais diferenças, ele é capaz de realizar a estimativa em cerca de 30 minutos.

Obviamente, a vantagem é que o especialista pode fornecer uma rápida cotação. A

desvantagem é que existe a possibilidade que uma consideração mal feita torne a

estimativa inválida. Porém, se o indivíduo é um verdadeiro especialista, isto é improvável

que aconteça.

A primeira abordagem é algorítmica: completa, detalhada e altamente precisa, mas

possivelmente inadequada devido às limitações de tempo e esforço.

A segunda abordagem é heurística: não tão completa e detalhada, mas talvez o

bastante precisa e desenvolvida em função das limitações de tempo e recursos disponíveis.

Sendo assim, enquanto os resultados de procedimentos algorítmicos são sempre

precisos, são freqüentes os casos onde uma estimativa heurística com quase a mesma

precisão pode ser obtida com muito menos esforço. Porém apenas especialistas são capazes

de obtê-la e, às vezes, existe o risco de cometer erros.





9

1.2. Algumas distinções entre SE e programas convencionais.

• A separação do conhecimento de um domínio específico de como ele é aplicado.

• Uso de conhecimento altamente específico.

• Aplicação de abordagem heurística, em vez de algorítmica, do conhecimento

empregado.

• Capacidade de explicar como as soluções foram obtidas.

• O conhecimento é apresentado de forma explícita.

1.3. Diferentes perspectivas sobre SE

Função Relacionamento

Gerente Para que posso usá-lo?

Programador Como posso melhor implementá-lo?

Pesquisador Como posso expandi-lo?

Usuário Como este sistema poderá me auxiliar?

Vale a pena as mudanças e o investimento para aquisição?

Quão confiável é o sistema?

1.4. Vantagens relacionadas a Sistemas Especialistas

• Aumento da disponibilidade do conhecimento - com este tipo de sistema a

experiência torna-se mais disponível.

• Redução do custo - o custo de acesso ao conhecimento por usuário é bastante

reduzido.

• Redução do risco - Sistemas Especialistas podem ser usados em ambientes perigosos

para o ser humano.

• Permanência - diferentemente de especialista humano (EH) que pode aposentar-se,

pedir demissão ou vir a falecer, o conhecimento armazenado em SE terá permanência.





10

• Múltiplas especialidades - o conhecimento de múltiplos EH poderá estar disponível

para trabalhar simultaneamente e continuamente em um problema a qualquer tempo. Além

disto, o nível de conhecimento combinado de vários EH pode superar o de um único

especialista.

• Aumento da confiabilidade - SE podem aumentar a confiança que uma solução

correta foi tomada, pois fornecem uma segunda opinião para um especialista ou servem como

desempate no caso de múltiplos EH discordarem entre si. Certamente, isto não ocorrerá se o

sistema foi desenvolvido por um dos EH. Um SE sempre concordará com o especialista, a

menos que um erro tenha sido cometido pelo especialista (ou no desenvolvimento do

sistema). Erros podem ser cometidos por EH como conseqüência de cansaço ou sob estresse.

• Explicação - um SE pode (ou deve) explicitamente explicar em detalhes as razões que

levaram a uma conclusão, enquanto que um EH pode estar cansado, não desejar ou não ser

capaz de prover tal explicação todo o tempo. Esta característica de SE pode aumentar a

confiança na solução adotada.

• Resposta rápida - em algumas aplicações pode ser necessária uma resposta rápida ou

em tempo real. Dependendo do software e hardware utilizados, um SE pode responder mais

rapidamente e ser mais disponível que um EH.

• Resposta completa, * consistente e imparcial em todas as condições - Isto pode ser

muito importante em aplicações de tempo real e situações de emergência quando um operador

pode não operar na eficiência máxima devido a estresse ou fadiga.

• Tutor inteligente - um SE pode atuar como um tutor conduzido um estudante através

de certos problemas e explicando as razões da solução.

• Banco de dados inteligente - um SE pode ser usado para acessar um banco de dados

de uma forma mais inteligente.

• Alta performance - o sistema deve ser capaz de responder em um nível de

competência igual ou superior a um especialista do campo de conhecimento. Isto implica

dizer que a solução apresentada pelo sistema deve ser de alta qualidade.

O processo de desenvolver um SE tem também um benefício indireto, pois o

conhecimento dos EH deve ser formulado de forma explícita para ser modelado via

computador.





11

Por que a capacidade de prover explicação é fundamental?

Uma das razões é que algo de grande valor pode depender das respostas do sistema.

Devido ao seu grande potencial de causar dano, um SE deve ser capaz de justificar sua

resposta de forma semelhante a um EH.

A capacidade de explicação é importante também na fase de desenvolvimento do

sistema para confirmar se o conhecimento foi corretamente adquirido e modelado no sistema.

Tal aspecto é fundamental no debugging do sistema, pois pode prevenir erros de sintaxe ou

conceitos mal entendidos entre o Engenheiro de Conhecimento (EC) e o EH. Outra razão é o

fato de que devido à forma como um típico SE é desenvolvido é muito difícil entender seu

funcionamento através da leitura da listagem. Pois, o fluxo de execução não é seqüencial.

1.5. Elementos de um Sistema Especialista

1.6. Definições

• Interface com o usuário - mecanismo de comunicação entre usuário e o SE.

• Módulo de explicação - esclarece as razões encontradas pelo SE.

• Memória operacional - um "banco de dados" de fatos usados pelas regras.

MÁQUINA DE INFERÊNCIA

AGENDA

BASE DE

CONHECIMENTO

(REGRAS)

MEMÓRIA

OPERACIONAL

(FATOS)

HABILIDADE DE

EXPLICAÇÃO

HABILIDADE DE AQUISIÇÃO DE

CONHECIMENTO

INTERFACE COM O USUÁRIO





12

• Máquina de Inferência - mecanismo que decide quais regras são satisfeitas, prioriza

as regras satisfeitas e executa a regra de maior prioridade.

• Agenda - uma lista das regras priorizadas pela Máquina de Inferência, cujas condições

são satisfeitas pelos fatos ou objetos na memória operacional.

• Módulo de aquisição - propicia ao usuário uma forma automática para inserir

conhecimento no sistema, sem necessitar codificação por parte do EC.

O módulo de aquisição é um atributo adicional em muitos sistemas. Algumas

ferramentas de desenvolvimento (SHELL) oferecem um mecanismo para indução de regras.

Contudo, a maioria dos exemplos que permitem indução é baseado em conhecimento advindo

de uma forma relativamente simples e bem classificada.

• Algumas comparações - Dos modelos propostos pela teoria cognitiva de Newel e

Simon (base dos sistemas especialistas)

• A Memória Operacional - atua como memória de curto prazo, uma vez que é usada

para armazenamento temporário de conhecimento (fatos) durante a solução de um problema.

• A Base de Conhecimento (regras) - representa uma memória de longo prazo, onde o

conhecimento permanente é armazenado.

Uma REGRA corresponde a uma pequena e modular parte do conhecimento (chunk).

Na solução de problemas, um especialista humano organiza partes do conhecimento de

forma flexível através de conexões com outras partes. Embora a memória de longo prazo

possa armazenar centenas de milhares destas partes, a capacidade da memória de curto prazo

é muito pequena. Isto pode ser exemplificado da seguinte forma:

A maioria dos seres humanos consegue visualizar mentalmente apenas em torno de 4 a

7 números ao mesmo tempo. Certamente, conhecemos mais do que esta quantidade, que na

verdade está armazenada na memória de longo prazo.

Na busca de uma solução, uma parte do conhecimento é ativada (ou estimulada) e

desencadeia a ativação de outras partes. Para que tal processo ocorra, é necessário a

existência de um processador cognitivo que tenta determinar que REGRAS serão ativadas

por um conjunto determinados de estímulos (FATOS).





13

• A Máquina de Inferência - corresponde ao processador cognitivo.

Funções da Máquina de Inferência

• Selecionar que regras são ativadas

• Priorizar as regras selecionadas

• Ativar ou disparar as regras selecionadas na prioridade selecionada

• Processar a "refração" das regras disparadas

(Analogia com o neurônio)

1.7. Outras Definições

• Engenharia de Conhecimento - processo de desenvolvimento de um SE

• Engenheiro de Conhecimento - responsável por desenvolver um SE

• SHELL - ferramenta computacional para implementação de um SE.

• Usuário - pode ser o usuário final (sem conhecimento do domínio), o engenheiro de

conhecimento ou o próprio especialista do domínio.

1.8. Típicas diferenças entre SE e programas convencionais

Característica Programa Convencional Sistema Especialista

Controle Declaração explícita Máquina de Inferência

Controle e dados Integração implícita Separação Explícita

Solução via Algoritmo Regras e inferência

Resolução Algorítmica correta Regras

Entrada de dados Assumida correta Incompleta, incorreta.

Entrada imprevista Dificuldade para manipular Muito adequado

Saída Sempre correta Varia com o problema

Explicação Nenhuma Geralmente

Aplicações Numérica, arquivos e texto Manipulação simbólica

Execução Geralmente seqüencial Regras mais apropriadas

Projeto do sistema Estruturado Pouco ou nenhum

Facilidade de mudança Difícil Razoável

Expansão Feita em saltos Incremental





14

2. Crescimento da Aplicação de Sistemas Especialistas

Desde o início da década de 70 (quando o paradigma de SE foi estabelecido) vários

sistemas já foram desenvolvidos, aqui estão alguns exemplos:

SISTEMA FUNÇÃO

MYCIN (76) Diagnóstico de doenças baseada em amostra de sangue e especificação de tratamento para infecção. Desenvolvido pela Universidade de STANFORD.

XCON/R1 (82) Configuração de sistemas computacionais

Obs.: Desenvolvido pela Digital Equipament Corporation (DEC) em parceria com a Universidade de Carnegie Mellon, com sua aplicação, a DEC já economizou milhões de dólares por ano.

PROSPECTOR

(78)

Análise geológica de dados para prospecção de minerais

Obs.: Através PROSPECTOR foi descoberta uma jazida valendo $100 milhões.

ISIS (84) Geração de planos de alocação de mão-de-obra para chão de fábrica. Desenvolvido pela parceria da Universidade de Carnegie Mellon e Westinghouse Electric Corporation.

GENAID (86) Monitoramento e diagnóstico de condições operacionais de grande geradores em tempo real. Desenvolvido pela Westinghouse Electric Corporation com suporte da Texas Utilities e da Universidade de Carnegie-Mellon

LES (87) Monitoramento e diagnóstico do processo de abastecimento de oxigênio líquido em tanque de naves espaciais. Desenvolvido por MITRE Corporation e NASA-KSC (Kennedy Space Center)

PTRANS (83) Suporte ao controle da manufatura e distribuição da DEC. Desenvolvimento conjunto entre DEC e Universidade de Carnegie-Mellon.

DENDRAL Interpretação espectrogramas de massa para identificar os elementos químicos.

DELTA (83) Diagnóstico / conserto de locomotivas GE. Desenvolvido pela General Electric e atualmente encontra-se em uso nesta empresa.

INTERNIST

(82)

Suporte ao médico no processo de diagnose de infecções de hospitalares. Desenvolvido pela Universidade de Pittsburgh.

REACTOR Diagnóstico / conserto de acidentes em reatores

STEAMER

(84)

Instrução de operação de máquinas a vapor. Desenvolvido pela Marinha Americana em colaboração com a BBN Corporation.

CADHELP Instrução para CAD

SOPHIE Instrução para diagnóstico de falhas em circuitos eletrônicos

DIPMETER Análise geológica de dados para prospecção de petróleo.





15

http://www.osha.gov/oshasoft/

OSHA - Organization of Safety and Health Administration, US Department of Labor -

Desenvolveu alguns Sistemas Especialistas (com versões demo) para aplicações industriais.

Exemplos:

• HAZARD AWARENESS ADVISOR - um sistema especialista para identificar os

riscos nos ambientes industriais. O sistema apresenta um relatório com as recomendações da

OSHA.

• $AFETY PAYS - uma ferramenta para auxiliar empregadores na análise do impacto

financeiro com doenças ou acidentes ocupacionais que causam dias fora do trabalho.

• Lead Construction Advisor - fornece regras gerais e orientação sobre procedimentos

ligados à exposição o chumbo em construções.

• Fire Safety Advisor - apresenta as normas gerais da OSHA para segurança contra

incêndio, emergências e sistemas de detecção de incêndio.

• Asbestos Advisor 2.0 - sistema dedicado a proprietários, gerentes e locatários de

prédios. Após uma entrevista o sistema apresenta um relatório sobre regras quanto à

exposição ao asbesto.

• Confined Spaces Advisor 2.0 - o sistema auxilia na definição quanto à identificação e

permissão relativa às tarefas em espaços confinados.

3. Viabilidade de Sistemas Especialistas para certos tipos de problemas

Selecionar a aplicação correta com base numa razão correta pode acarretar numa positiva

influência no sucesso final do projeto. Enquanto selecionar mesmo uma aplicação certa por

uma razão não adequada pode não ser tão satisfatório.

Os critérios para analisar a viabilidade de SE consistem em vários fatores que podem ser

agrupados em duas categorias:

• Adequação da área de aplicação

• Disponibilidade de recursos





16

A seguir são apresentadas algumas orientações sobre cada uma destas categorias. Nem

todas estas orientações devem ser necessariamente seguidas, mas a grande maioria delas deve

ser considerada.

3.1. Adequação da área de aplicação

Muitas falhas de projetos envolvendo SE podem ser atribuídas a uma definição

inapropriada da aplicação. Algumas questões a considerar: O problema realmente existe? A

técnica de SE é aplicável? A abordagem de SE é realmente justificável?...

• O problema realmente existe?

Esta é a primeira questão a ser considerada. O risco de desenvolver um projeto para um

problema que realmente não existe é que a solução não terá real impacto na operação da

organização. Desta forma o interesse nesta tecnologia pode diminuir ou até desaparecer antes

que aplicações de real valor sejam reconhecidas. Além disto, tal aspecto pode ser

erroneamente tomada por alguns como justificativa para indicar uma falha da tecnologia.

Contra-exemplo: O problema de visitantes numa fábrica de equipamentos de combate a

incêndio. Uma solução em busca de um problema, e não um problema real para o qual deve-

se desenvolver uma solução.

A verdadeira questão a ser considerada é se um sistema especialista proposto representa

um valor considerável para a organização. Considerável valor não necessariamente significa

econômico, mas pode envolver, por exemplo, prestígio ou imagem da empresa.

Quanto maior o valor mais a organização estará disposta a se empenhar no

desenvolvimento do sistema.

• A técnica de SE é aplicável?

Para auxiliarem neste aspecto, certas sub-questões são postas, a busca destas razões

representa em si um processo inexato, e por tanto heurístico.

• O tipo de problema reproduz o conhecimento humano na busca de solução?

Uma resposta positiva implica que SE pode ser a solução adequada, enquanto uma

resposta contrária não necessariamente numa má aplicação.





17

• O tipo de problema é heurístico em sua natureza ou é predominantemente

algorítmico?

Nenhuma tarefa é apenas de uma forma, a maioria dos problemas no mundo real contem

ambos elementos.

A chave é qual é a forma predominante.

• O conhecimento ou especialização muda periodicamente ou permanece

constante?

Se o conhecimento muda freqüentemente o tipo de problema é aplicável para SE devido

à sua facilidade inerente em incorporar mudanças.Isto também pode justificar a aplicação de

SE para problemas predominantemente algorítmicos, mas cujas regras mudam

freqüentemente.

• Se experiência é envolvida, ela é relativamente bem entendida e aceita?

Se são difíceis de desenvolver para domínios que não são bem desenvolvidos.

Exemplo: é relativamente simples identificar, organizar e representar a experiência de

como diagnosticar um problema num automóvel, mas bem mais difícil fazer o mesmo com

relação a interpretar sinais de rádio de ondas extra-terrestes ou astrologia. Por outro lado, se a

experiência pode ser adequadamente reduzida a fórmulas e modelos matemáticos então

programas convencionais podem ser mais adequados.

• As entradas do problema são sempre corretas e completas?

Se a resposta é não então SE podem apresentar uma vantagem distintiva.

• O problema pode ser resolvido por outros meios?

Embora SE ofereçam excelentes características para resolver algum tipo de problema,

estas características poderão não ser necessárias para outros. Em certos casos, a melhor

solução pode não ser computacional. Exemplo: um simples mapa pode ser a solução no caso

do contra-exemplo.

• O problema passa o teste do telefone?

Este teste questiona se um especialista, através apenas de uma conversação por telefone,

pode apresentar suficiente solução para permiti-lo a resolver um problema. Este teste não





18

deve ser tomado ao pé da letra. O teste é um meio de classificar o tipo de conhecimento que é

necessário para resolver o problema. Ele certifica que o tipo de conhecimento não é de

natureza visual, auditiva ou táctil. Embora uma limitada porção deste tipo de conhecimento

pode ser manipulada por um SE caso a informação seja claramente categorizada e organizada,

uma predominância deste tipo de conhecimento pode tornar o desenvolvimento de um SE

extremamente difícil.

• A abordagem via SE é justificável?

O custo de desenvolver um SE é geralmente bem superior ao de programas

convencionais. Por várias razões, primeiro é necessário recursos (software e "hardware")

apropriados. Além disto, há a necessidade de pessoal especializado, tais pessoas são difíceis

de encontrar, implicam em alto custo e/ou difíceis de treinar. Sendo assim, a solução via SE

deve ser avaliada de acordo com a relação custo/benefício como qualquer outro projeto.

3.2. Disponibilidade de Recursos

Mesmo que um problema específico possa satisfazer todos os critérios anteriores, ainda

assim pode não se tornar uma implementação bem-sucedida. Alguns fatores podem

comprometer o projeto.

Primeiro, o engenheiro de conhecimento deve ser altamente capacitado.

Em segundo lugar, como tais projetos não existem isoladamente eles estão sujeitos a

algumas restrições geralmente encontradas em governo, indústrias, e organizações acadêmicas

que afetam o desenvolvimento de projetos. Sendo assim, as próximas questões devem ser

consideradas muito cuidadosamente.

• Existe apoio gerencial para o projeto?

A menos que o desenvolvedor seja proprietário da empresa ou tenha um excelente

relacionamento com a direção (CEO), sempre haverá conflitos com a gerência. O apoio da

gerência não garante o sucesso do projeto, mas a falta dele implica quase que certamente em

sua falha. Tal apoio pode se apresentar de várias formas, todas essenciais à implementação

bem sucedida do projeto.





19

• Disponibilidade de tempo

Isto é a primeira e a mais importante forma de apoio. Existem excelentes aplicações que

nunca decolaram devido à falta de tempo do engenheiro de conhecimento.

A gerência deve ser bastante consciente da natureza de trabalho intensivo em

desenvolver um SE. Além disto, a equipe de engenharia de conhecimento deve considerar o

desenvolvimento sua maior prioridade.

• Ferramentas e treinamento

A escolha das ferramentas de desenvolvimento pode ser geralmente restrita por

parâmetros fora do controle direto da gerência.

O treinamento pode variar de alocar tempo ao engenheiro de conhecimento para estudar

materiais sobre a ferramenta até providenciar cursos específicos sobre a ferramenta.

• Disponibilidade do Especialista

Neste aspecto, dois problemas podem ocorrer.

• Os especialistas do domínio, devido à sua especialidade em uma área, podem ser

altamente requisitados. Neste sentido, sua disponibilidade pode ser muito limitada.

• Em algumas organizações o especialista e o EC podem pertencer a diferentes

unidades. Neste caso, a gerência deve ser um nível suficientemente alto para abranger as duas

unidades.

• Existe apoio da parte do Especialista?

O especialista cooperativo que está estimulado pela idéia de ver seu conhecimento

reproduzido é ideal. Todavia, em si, este conceito pode parecer uma ameaça à segurança do

especialista, acarretando o fato dele não se mostrar cooperativo.

• O Especialista é competente?

Em muitos casos o EC não é capaz de julgar se o especialista é competente, devido à sua

falta (do EC) de conhecimento sobre o domínio. Além disto, isto pode ser delicado para

questionar. Contudo, é fundamental para o sucesso do projeto que o especialista seja

verdadeiramente especialista no domínio.





20

A decisão mais importante que o EC deve tomar é se assegurar que existe mais de uma

fonte de conhecimento disponível. Seria ideal ter dois ou três especialistas comprometidos

com o projeto. Todavia, nesta abordagem existe um risco, ou seja, o principal especialista

pode considerar isto uma ofensa.

• O Especialista é bem articulado?

Isto implica dizer que o especialista deve ser articulado para transmitir não apenas

"conhecimento dos livros" mas também, e mais importante, sua própria experiência.

O especialista altamente qualificado no problema que afirma: "a solução é tão óbvia, que

qualquer idiota pode ver" ou "não posso explicar porque esta é a solução apenas que ela é",

não de grande assistência.

Neste sentido, o especialista deve ser capaz de verbalizar o processo aplicado para

resolver um problema e propor uma solução. O EC dispõe de várias técnicas para "extrair"

este conhecimento, as quais serão apresentadas posteriormente.

• "O Especialista está fisicamente próximo?"

A distância pode limitar o acesso do EC ao especialista, o que pode retardar o processo

de desenvolvimento. Embora um especialista cooperativo pode superar tal deficiência.

4. Processo de desenvolvimento de Sistemas Especialistas

Como em qualquer projeto, o desenvolvimento de um SE depende dos recursos

disponíveis bem como de como o processo é organizado e gerenciado.

O gerenciamento do projeto deve englobar:

Gerenciamento da Atividade (processo)

Planejamento - Definir atividades

• especificar prioridades das atividades

• recursos

• principais eventos (milestones)

• duração

• responsabilidades





21

Cronograma - Definir datas de início e término

• resolver conflitos no encaminhamento de atividades de igual prioridade

• monitorar o desenvolvimento

• análise de planos, prazos e atividades

Gerenciamento do Produto

• organizar as diferentes versões do produto

• gerenciar propostas de mudança e avaliações do impacto

• definir pessoal para executar as modificações

• instalar novas versões do produto

Gerenciamento dos recursos

• prever necessidade de recursos

• aquisição de recursos

• definir responsabilidades para otimizar o uso dos recursos

• prover recursos críticos para minimizar gargalos

4.1. Estágios gerais no desenvolvimento de Sistemas Especialistas

• Estudo de Viabilidade

• Protótipo Rápido (Inicial) - um SE rapidamente desenvolvido para demonstrar idéias,

despertar entusiasmo e impressionar o alto nível de gerência.

• Sistema Refinado (αααα- teste) - Verificação interna do sistema em problemas reais,

executada pelos EC e EH

• Teste de Campo (ββββ- teste) - sistema testado por usuários selecionados (não EC ou

EH)

• Sistema comercial - validado e testado. Documentação do usuário, treinamento e

rápido apoio ao usuário via telefone ou e-mail.

• Manutenção ou evolução - corrigir bugs e ampliar as capacidades.





22

4.2. O problema da plataforma

Dependendo do número de sistemas a serem fornecidos (amplitude do mercado), o

problema de "para qual plataforma o SE será desenvolvido?" Pode ser um importante fator

no desenvolvimento, o qual deve ser considerado nos estágios iniciais do processo.

De uma forma ideal, os SE devem ser capazes de operar num hardware padrão. Todavia,

muitos sistemas desenvolvidos em LISP necessitam de microprocessador especial, que

aumenta substancialmente o custo. Deve também ser prevista a comunicação do SE com

outros programas.

4.3. Manutenção e evolução de SE

Neste contexto, estas atividades são tarefas com fim menos definido (open-ended

activity) que no caso de programas convencionais. Devido ao fato de SE não serem baseados

em algoritmos, seu desempenho depende do conhecimento. Sendo assim, a medida que um

novo conhecimento é adquirido e o antigo modificado, o desempenho do sistema melhora.

No aspecto comercial, os desenvolvedores de SE devem estar atentos aos desejos dos

usuários, também no aspecto de melhoramento. A identificação e correção de bugs deve ser

uma alta prioridade.

Num sentido bem real, um sistema especialista comercial pode nunca realmente ser

concluído, ele apenas melhora.

4.4. Possíveis erros no desenvolvimento de SE

• Erros no conhecimento do especialista - como o especialista é a fonte de

conhecimento, seus erros podem se propagar através de todo o processo. A detecção destes

erros pode ocorrer quando o conhecimento é explicitado. Para projetos de missão crítica, onde

vidas humanas ou propriedades estão em risco, deve ser necessário definir procedimentos

formais (com um painel de especialistas e gerentes) para certificar o conhecimento do

especialista.

• Erros de semântica - erros deste tipo ocorrem quando o significado do conhecimento

não é apropriadamente comunicado. Como exemplo, suponha que o especialista diga "você





23

pode extinguir um incêndio com água" e o engenheiro de conhecimento interprete "todo

incêndio pode ser extinto com água". O erro de semântica pode ocorrer se o EC interpretar

erroneamente as respostas do EH, ou o EH interpretar erroneamente as perguntas do EC, ou

ambos.

• Erros de sintaxe - estes são erros simples, correspondem a formas incorretas de

definir regras, fatos, etc... As ferramentas de desenvolvimento devem apontar tais erros.

• Erros na máquina de inferência - alguns bugs devem aparecer apenas em

circunstâncias especiais (por exemplo, ordenamento de condicionais em uma regra), tais bugs

devem ser difíceis de detectar. A maioria dos sistemas tem uma lista de usuários, e bugs já

consertados, esta experiência deve ser a principal fonte para solucionar este tipo de erro.

• Erros na cadeia de inferência - este tipo pode ser causado por uma combinação dos

tipos anteriores e mais uma incorreta especificação do encadeamento de regras ou uma má

interação entre regras.

Outras possibilidades são propagação de incerteza nas regras e não-monotonicidade.

No processo de busca de uma solução um especialista humano usa certas hipóteses que

posteriormente são provadas falsas, sendo assim as conclusões tomadas com base nestas

hipóteses devem ser reconsideradas. Sendo assim, sistemas que admitem não-

monotonicidade devem ser capazes de modelar tal propriedade.

• Erros devidos aos limites de ignorância - como os especialistas humanos conhecem

a extensão de seu conhecimento, seu desempenho gradativamente (espera-se) decresce a

medida que se aproximam deste limite. Tal característica deve ser prevista em SE.

5. A definição de Qualidade em Sistemas Especialistas

Qualidade é um termo difícil de descrever num sentido geral porque significa coisas

diferentes para pessoas diferentes. Uma forma de definir qualidade é um conjunto dos

atributos desejáveis de um objeto em uma determinada escala. Os atributos e seus valores são

chamados métricas.

Por exemplo, a confiabilidade de um dispositivo é uma métrica de sua qualidade, uma

medida deste atributo é o MTBF (Mean Time Between Failures).





24

A lista a seguir fornece algumas métricas relativas à qualidade de SE

• Saídas corretas para entradas corretas

• Saídas completas para entradas corretas

• Saída consistente para a mesma entrada

• Confiável, ou seja, o sistema não deve abortar (com freqüência) devido a bugs.

• Utilizável e preferencialmente amigável ao usuário

• De fácil manutenção, de fácil melhoramento

• Validado, comprovado que satisfaz as necessidades do usuário

• Viável economicamente

• Código re-aproveitável para outras aplicações

• Compatível com outros ambientes (hardware/software)

• Permite interface com outros softwares

• Código compreensível. Sistema preciso

• Gradativa queda de desempenho na fronteira do conhecimento

• Base de conhecimento verificável

• Facilidade de explicação

Uma lista de métricas permite mais facilmente priorizá-las, pois pode ser que haja

conflitos entre as métricas. Por exemplo, aumentar a fase de testes de um sistema para

assegurar sua precisão aumentará também o custo. Decidir quando os testes devem terminar

envolve vários fatores como cronograma, custo e requisitos. De forma ideal, todos estes

fatores devem ser satisfeitos. Na prática, alguns serão mais importantes.

6. Ciclo de vida de um Sistema Especialista

O conceito do ciclo de vida fornece uma continuidade que conecta todos os estágios do

desenvolvimento. O planejamento para manutenção e evolução nas primeiras fases do ciclo de

vida reduz os custos nos estágios posteriores.





25

6.1. Custos de Manutenção

Para sistemas convencionais, a manutenção tipicamente responde por cerca de 60 a 80

% dos custos e é geralmente de duas a quatro vezes o custo do desenvolvimento original.

Embora haja limitada informação deste tipo para SE, pelo fato de ser uma tecnologia

nova, os dados devem ser provavelmente piores.

Sistemas Especialistas que executam bastante inferência com base em incertezas são

mais suscetíveis a maiores custos de manutenção e evolução.

6.2. Diferentes modelos de ciclo de vida

• Modelo cachoeira (waterfall) - muito familiar entre programadores de sistemas

convencionais. Neste modelo, cada estágio termina com uma verificação e validação para

minimizar qualquer problema naquele estágio. (Apresentar figura e discutir)

• Modelo codificar-&-corrigir - mais comum entre programadores iniciantes. Neste

caso, uma certa parte do código é implementada e então consertada quando não funciona

adequadamente. As deficiências deste "modelo" levaram ao desenvolvimento de outros.

• Modelo incremental - este modelo é um refinamento do waterfall. A idéia básica é

desenvolver o sistema com base em incrementos de sua funcionalidade.

O modelo incremental foi usado com sucesso no desenvolvimento de grandes programas

convencionais. Este modelo é também aplicável a sistemas especialistas onde o incremento de

regras amplia as capacidades do sistema numa escala de vários níveis (de um assistente, para

um coadjuvante e finalmente para um especialista).

A principal vantagem do modelo incremental é que o acréscimo nas capacidades

funcionais é mais fácil de testar, verificar e validar que no caso de estágios individuais como

no modelo waterfall.

Com este modelo, os custos de incorporar correções no modelo são menores.

O modelo incremental é equivalente a dizer que o sistema na forma de protótipo inicial

se desenvolve ao longo do ciclo de vida, ao invés de implementar um protótipo apenas

determinar os requisitos do futuro sistema, ou seja, o protótipo que evolui é o próprio sistema.





26

7. Definição Do Domínio De Aplicação E Identificação Das Fontes De

Conhecimento

Tarefa Objetivo

Identificação da fonte

Quem e quais são as fontes de conhecimento, sem considerar disponibilidade

Importância Priorizar a lista das fontes em ordem de importância

Disponibilidade Listar as fontes de conhecimento de acordo com a disponibilidade. Livros e outros documentos são em geral mais disponíveis que especialistas humanos.

Seleção da fonte Selecionar as fontes com base na importância e disponibilidade

8. Projeto da Base de Conhecimento

Tarefa Objetivo

Representação Especificar como o conhecimento será representado, isto dependerá e implicará na seleção da ferramenta de desenvolvimento

Estrutura de controle no sistema

Definir como as regras terão interação entre si, partição da agenda ou uma regra global para gerenciar o fluxo de informações

Estrutura interna de Fatos

Especificar de forma consistente a estrutura interna de fatos, o que auxiliar o entendimento do fluxo de informações

Projeto preliminar da interface

Especificar o projeto da interface e obter o mais rápido possível um retorno no usuário sobre a interface.

Planejamento dos testes

Determinar como o código será testado e como os resultados serão analisados.

Estratégia de implementação

Definir como o sistema será implementado, ou seja, que modelo de desenvolvimento será adotado.

Elaboração de relatório

Documentar o projeto, incluindo todas as definições anteriores





27

9. Escolha da ferramenta de desenvolvimento

Escolher o correto escopo (meta, finalidade, objetivo) do problema e selecionar a

ferramenta certa para desenvolvimento são duas das mais difíceis decisões a tomar no projeto

de um SE.

Selecionar a ferramenta é uma tarefa difícil, pois, a maioria dos sistemas não foi

desenvolvida para aplicação a uma classe particular de problemas.

Lei de Davis:

Para cada ferramenta existe uma tarefa perfeitamente adequada a ela.

Todavia o contrário não é verdade, ou seja, para uma dada tarefa pode existir uma gama

de ferramentas igualmente se aplicam. Em alguns casos, a ferramenta foi escolhida por

motivos errôneos.

• O engenheiro de conhecimento já conhecia o sistema.

• A ferramenta era a mais eficiente disponível para o hardware a ser usado.

• A ferramenta foi desenvolvida e então domínios foram pesquisados para testá-la- "a

solução buscando um problema"

9.1. Questões quanto à escolha da ferramenta

• A ferramenta oferece à equipe de desenvolvimento a capacidade e sofisticação

necessária?

• As condições de suporte da ferramenta são adequadas considerando as restrições de

tempo do projeto?

• A ferramenta é disponível?

• Existe manutenção da ferramenta?

• A ferramenta possui as características sugeridas pelas necessidades do problema em

questão?





28

Os fatores de desenvolvimento (tempo, recursos financeiros, pessoal, etc.) influenciam a

decisão sobre que tipo de ferramenta escolher: uma linguagem de programação (tipo LISP ou

PROLOG) ou um sistema de engenharia de conhecimento (SHELL).

As linguagens de programação oferecem maior flexibilidade, mas geralmente requerem

da equipe de desenvolvimento a implementação da máquina de inferência para acessar a base

de conhecimento. Em geral, o desenvolvimento leva mais tempo com uma linguagem de

programação, mas o resultado pode ser mais adequado ao domínio do problema.

Por outro lado, sistemas SHELL, apesar de oferecerem menos flexibilidade, fornecem

mais orientações e mecanismos de como representar e acessar o conhecimento. O

desenvolvimento deve ser mais fácil, rápido barato com este tipo de sistema, mas pode

resultar num sistema tão eficiente quanto um implementado em linguagem de programação.

A orientação neste sentido é: Escolher a ferramenta que complementa os aspectos

fortes da equipe de desenvolvimento.

9.2. Condições de suporte da ferramenta

Estas devem incluir mecanismos de depuração (debugging), editores de base de

conhecimento, adequadas interfaces (I/O), e mecanismos de explicação.

9.3. Confiabilidade

O desenvolvimento será seriamente comprometido se a ferramenta não for confiável.

Ferramentas não suficientemente validadas podem causar problemas devido a testes

incompletos, documentação obsoleta e a linguagem ainda está em especificação.

É mais provável que a ferramenta seja confiável se existe uma grande comunidade de

usuários e considerada robusta e bem depurada.

Orientação: Não implementar um SE numa ferramenta ainda em desenvolvimento.





29

9.4. Mantenabilidade

A manutenção é de responsabilidade do desenvolvedor da ferramenta, um sistema antigo

pode ser um problema se seu criador não tiver mais interesse em mantê-lo ou fornece

adequada documentação.

Orientação: Não escolha uma ferramenta que deva ser mantida por você mesmo.

9.5. Características da tarefa

Aspectos como:

• forma de representação do conhecimento,

• habilidade de programação da equipe de desenvolvimento e

• tipo de encadeamento de regras a ser aplicado é determinante para a seleção da

ferramenta

Uma vez escolhida a ferramenta, considere implementar um sistema protótipo num prazo

de quatro a seis semanas para testar a eficácia do sistema. Isto envolve aplicar a ferramenta

para resolver um problema pequeno, mas representativo no domínio de interesse.

Esta etapa coincide com a necessidade de implementar um protótipo rapidamente para

verificar se o escopo do problema e o esquema de representação estão bem fundamentados.

Durante esta fase, considere com particular atenção a velocidade de execução, pois se o

sistema levar horas ou minutos, em vez de segundos, para obter respostas parciais, então

testes e refinamentos serão lentos e o desenvolvimento poderá estar comprometido.

Outro aspecto de relevância é que a medida que o sistema se torna mais complexo, a

performance da ferramenta deve decair gradualmente e não abruptamente.

10. Escolha da equipe de desenvolvimento

Uma etapa decisiva é a escolha da equipe. O tamanho e a composição desta equipe varia

grandemente dependendo de vários fatores, a seguir abordados:





30

10.1. Escolha do Engenheiro de Conhecimento

Algumas características:

• Competência - assim como na engenharia de software, o EC deve possuir habilidades

de interpretar os requisitos de uma tarefa e o projeto da solução de forma bem clara. Sendo

assim, um completo entendimento de engenharia de conhecimento e das ferramentas é um

requisito.

• Organização - a capacidade de analisar os requisitos de projeto e planejar uma

solução geral no estágio inicial é importante. O processo de gerar um protótipo de forma

rápida determina a validade da solução proposta. Se a solução é cuidadosamente organizada e

estruturada, as chances de ser incorreta são bem menores.

• Paciência - apesar de ser possível adotar o modelo incremental e obter um protótipo

de maneira relativamente rápida, o desenvolvimento do sistema pode ser um processo

demorado, principalmente em projetos de grande e médio porte. O tempo entre a definição do

projeto e seu término pode levar de três a quatro anos. Consequentemente é necessário uma

considerável paciência para acompanhar um projeto até seu final.

Outro aspecto importante é que a rotatividade de pessoal pode ser um grande problema,

pois o desenvolvimento do sistema depende grandemente de como a equipe interpreta o

conhecimento sobre o domínio de aplicação.

• Facilidade de relacionar-se (friendliness)- não é possível subestimar a importância

da habilidade do EC de interagir facilmente com outras pessoas. O EC dedica grande parte de

seu tempo para entrevistar e interagir com especialistas. Tais especialistas podem ou não ter

resistência a participar do projeto, de qualquer forma sua paciência será levada ao limite.

• Habilidade de comunicação interpessoal - para ser efetivo, o EC deve ter a

capacidade de se comunicar com os mais variados especialistas, alguns dos quais podem ser

muito difíceis de lidar.

• Interesse em expandir o conhecimento - aqueles que pretendem desempenhar o

papel de EC devem apreciar aprender sobre novos assuntos, caso contrário poderá haver um

desestímulo durante o projeto resultando em rotatividade de pessoal.





31

• Auto Confiança - como a atividade do EC pode envolver interação com um domínio

de conhecimento bem diverso, isto pode levar a uma certa frustração do EC, posto que este

terá pouco envolvimento com cada domínio, ou seja, é pouco provável que chegará a ser um

especialista em um domínio específico.

O candidato ideal a EC é alguém com um excelente entendimento sobre sistemas

baseados em conhecimento e uma compreensão básica sobre o domínio de aplicação. Tal

pessoa provavelmente não demande extensa "atividade de doutrinação" num certo domínio

para ser familiarizado com este domínio. Na realidade, tal combinação é rara e em muitos

casos soluções de compromissos devem ser estabelecidas.

É mais fácil ensinar quase-especialistas a arte da engenharia de conhecimento que

ensinar analistas de sistemas os princípios básicos de um domínio do conhecimento para o

qual eles não foram preparados.

Algumas vezes pode ser vantajoso que o EC seja completamente "novo" e imparcial num

certo domínio de conhecimento. Isto pode acarretar o domínio a ser mais amplamente tratado

e resultar numa melhor base de conhecimento. Todavia, existe uma desvantagem: a aquisição

de conhecimento pode levar muito tempo, devido ao tempo necessário para o EC entender o

domínio de aplicação.

Qualquer que seja a situação é fundamental que o EC tenha uma fundamentação em

representação e aquisição de conhecimento, pois estas são suas responsabilidades principais.

10.2. Desvantagens de ter um especialista como EC

• o sistema não refletirá o conhecimento de uma coletividade sobre o domínio;

• a granularidade do sistema (ou seja, o nível de detalhe) pode não ser apropriado à

tarefa (em geral muito detalhista);

• apesar disto, não se pode dizer que um especialista nunca seja um EC, isto depende do

domínio, e principalmente, do próprio especialista; nesta abordagem a vantagem é que não

serão necessárias entrevistas e nem a curva de aprendizagem no domínio.

O contrário, todavia é verdade, ou seja, o EC nunca deve desempenhar o papel do

especialista e tomar decisões sobre o sistema sem consultar o especialista.





32

Alguém só se torna um verdadeiro especialista desempenhando tarefas específicas e

não apenas interagindo com um especialista.

10.3. Escolha do líder da equipe

Os critérios para definição do líder dependem do tamanho da equipe e da sofisticação

técnica do sistema. Contudo, independente disto, esta pessoa deve possuir uma significativa

experiência no desenvolvimento de sistemas baseados em conhecimento. Isto inclui:

• um entendimento a respeito da aquisição de conhecimento,

• suficiente experiência na implementação,

• bom entendimento da linguagem de programação,

• e se possível uma percepção e compreensão do domínio.

Tal lista de requisitos é bastante ampla e um aspecto mais realístico seria que o líder

tenha pelo menos um conhecimento compatível com o domínio.

10.4. Escolha do especialista

• Competência - pode ser medida de várias formas: anos de trabalho, publicações,

patentes no domínio, reputação entre os pares, etc.

• Capacidade de Articulação - isto facilita grandemente o processo de aquisição do

conhecimento. O especialista deve ser capaz de explicar precisamente como e porque chegou

a uma conclusão.

• Auto-confiança - o especialista deve estar seguro de sua posição na organização. É

muito difícil trabalhar com alguém numa posição defensiva sobre seu papel.

• Disponibilidade - o desenvolvimento de SE é uma tarefa que demanda tempo,

portanto o especialista deve satisfazer também este critério.

• Mente aberta - uma abertura para novos campos da tecnologia é importante. Pois a

resistência pode ser um grande obstáculo no desenvolvimento do sistema.





33

• De fácil relacionamento - embora não seja um requisito absoluto, se existe uma

escolha, trabalhar com um especialista que trata os outros de forma equânime é uma

vantagem.

• Entusiástico - isto auxilia não apenas o processo de entrevista, mas também, e

principalmente, o tempo das entrevistas quando são necessárias a documentação e compilação

de dados.

10.5. Critérios relativos à equipe

O fator mais determinante para composição da equipe é a complexidade do sistema em

desenvolvimento. Considerando que haja uma relação direta entre o tamanho do sistema e sua

complexidade (o que nem sempre é verdadeiro), a descrição das equipes pode ser dividida em

três categorias de sistemas, a saber, pequeno, médio e grande:

10.5.1. Sistemas pequenos - contem aproximadamente de 100 a 200 regras. O

conhecimento neste tipo de sistema pode ser exclusivamente heurístico ou uma combinação

de procedural e heurístico. A experiência usada nestes sistemas pode estar disponível em

literatura ou através de contatos pessoais com especialistas.

Algumas características destes sistemas podem incluir:

• Geralmente empregam regras como principal forma de representação do

conhecimento.

• Usam sistemas Shell disponíveis comercialmente.

• Normalmente são implementados em PC's.

• Geralmente são desenvolvidos pelo próprio especialista.

• Usam um único especialista se um engenheiro de conhecimento é necessário.

Caso um engenheiro de conhecimento seja necessário haverá apenas um. A duração é de

cerca de 6 meses. Estes tipos de sistemas são ideais para treinamento de novos engenheiros de

conhecimento. Pelo fato de serem relativamente pequenos, é realístico afirmar que tais

sistemas sejam desenvolvidos por estudantes em um semestre acadêmico.





34

10.5.2. Sistemas de médio porte - tais sistemas envolvem domínios mais complexos

onde a solução é tipicamente heurística. Estes sistemas contem aproximadamente de 250 a

1000 regras. No entanto, o número de regras nem sempre reflete a complexidade do sistema,

pois outras formas de representação, tais como frames, podem ser usadas. Apesar disto, o

número de regras pode fornecer uma maneira conveniente de classificar os sistemas.

Estrutura da equipe

• pelo menos um engenheiro de conhecimento, às vezes mais de um;

• no mínimo um especialista do domínio;

• possivelmente um analista de sistemas, em tempo parcial.

Atividades do líder da equipe - estruturar o sistema, o que minimiza possibilidades de

modificações ao longo do projeto. Também coordena as entrevistas com os especialistas, e

supervisiona as tarefas do engenheiro de conhecimento júnior. Este por sua vez é responsável

por implementar e validar a base conhecimento.

O analista de sistemas auxilia os EC's na interface do SE com outros sistemas como

banco de dados. Mesmo que vários especialistas sejam empregados no projeto, é importante

que um especialista atue como principal fonte de conhecimento. Os outros especialistas

podem servir para verificar e também esclarecer o conhecimento implementado.

Um importante ponto deve ser destacado. No desenvolvimento de um SE de porte médio

ou grande, pode ser arriscado empregar um especialista como EC. Pois, o sistema tenderia a

refletir suas opiniões e não a de outros especialistas. Embora isto seja aceitável em sistemas

de pequeno porte, não é o caso de sistemas maiores onde é necessária uma maior gama de

conhecimento. A duração de projetos de médio porte, da sua concepção à implementação, é

tipicamente de 1 a 2 anos.

10.5.3. Sistemas de grande porte - possuem em geral mais de 1000 regras. Aplicam

uma combinação de diferentes técnicas de representação do conhecimento. São desenvolvidos

para problemas de natureza altamente heurística.

Uma estrutura típica para projetos deste porte compreende:

• vários EC's juniores sob a supervisão de um líder (um EC mais experiente);

• um analista de sistema a tempo integral;





35

• um gerente geral do projeto.

A logística inerente a tais projetos possivelmente leva o problema a ser dividido em

vários componentes, que são implementados independentemente, cujas fronteiras devem ser

definidas pelo líder da equipe. Sempre é necessário definir que o conhecimento não esteja

sendo duplicado, isto está entre as tarefas do líder da equipe.

Uma grande diferença deste tipo de projeto, comparando com os anteriores, é a

necessidade de incluir um gerente para lidar com orçamento e aspectos organizacionais

comuns a qualquer projeto de grande porte.

10.6. Problemas relativos à interação com especialistas

Segue abaixo uma lista de diferentes perfis de especialistas e formas de abordá-los.

10.6.1. O Especialista fraco ou tímido

Este tipo de especialista teme perder seu emprego ou status na organização caso um

SE seja desenvolvido para desempenhar sua função. Como conseqüência disto, ele raramente

fornece uma resposta direta a qualquer questão. Este tipo é o mais difícil para se trabalhar

inicialmente, mas frequentemente o mais fácil de se modificar. Neste caso, o EC deve ser

capaz de convencê-lo de que o SE será implementado para livrá-lo de tarefas mais rotineiras.

Alguns argumentos

• o SE permitirá o especialista se concentrar em tarefas mais desafiadoras;

• o SE não poderá substituir totalmente um humano. Tais sistemas carecem de

conhecimento de senso comum e criatividade, limitam-se a realizar um sub-conjunto das

tarefas do especialista;

• um SE não realizar descobertas. Isto ainda será a tarefa do especialista;

• a importância e o significado das realizações do especialista são demonstrados pelo

interesse da empresa em codificar sua experiência.

• a área da Inteligência Artificial representa uma nova tecnologia, a qual alguém se

sentirá interessado em aprender.





36

O mais importante é que o EC deve ser cuidadoso no trato com tal especialista,

para não despertar insegurança.

10.6.2. O Especialista Cínico

Um especialista deste tipo, num caso extremo, detesta seu trabalho, a empresa e seu

chefe, e até mesmo a idéia de participar no projeto de um SE. Por várias razões (senioridade,

salário, benefícios) prefere continuar na empresa.

Algumas dicas para identificar este tipo de especialista:

• constante recusa em gravar entrevistas;

• críticas de seus pares e/ou superiores;

• outro sinal de amargura

Este tipo pode compartilhar informação de forma relutante, ou em casos raros, fornecer

propositadamente informação incorreta. Se a única opção for trabalhar com tal especialista, o

EC deve tomar as seguintes providências:

• Examinar cuidadosamente toda informação passada, pois pode haver o risco de

sabotagem do projeto. Isto reforça a importância dos testes de validação e de empregar outros

especialistas como revisores;

• Mostrar simpatia ao especialista. Caso ele perceba o EC também como "vítima" da

organização poderá criar uma identificação;

• Apelar para o senso de profissionalismo do especialista. Isto pode ser obtido através

de uma atitude consciente e precisa do EC, geralmente isto se aplica mais quando ambos

trabalham na mesma organização.

10.6.3. Especialista "sumo sacerdote" no domínio

Este tipo considera-se acima de todos em seu domínio. Encara o EC como um ser

ignorante que gasta seu tempo com questões banais, se arriscando a pensar que ele, o

especialista, pode ser substituído por uma máquina.

Para este tipo, a tecnologia de SE está extremamente subdesenvolvida. Por causa de sua

arrogância, este tipo pode ser muito difícil de se interagir, nunca está disponível para reuniões,





37

permite várias interrupções durante as poucas audiências, e não se interessa em cumprir as

tarefas entre as reuniões.

O EC deve ser paciente para lidar com tal especialista, deve conquistar a conquistar sua

confiança, através da capacidade intelectual mostrada com o desenvolvimento de um

protótipo. Isto ganhará o respeito do especialista e poderá convencê-lo da viabilidade da

tecnologia.

Reclamar aos superiores é improvável de resultar em melhoras no comportamento deste

tipo devido ao alto status do especialista na organização, de fato pode até piorar o

relacionamento.

10.6.4. O Especialista paternalista

Semelhante a um "velho" professor que deseja auxiliar e agradar um bom ouvinte através

da narrativa de suas proezas. Este tipo é difícil de trabalhar apesar de suas boas intenções,

pois geralmente fala demais. Este tipo de relação professor-aluno pode ser muito benéfica ao

processo de aquisição de conhecimento se adequadamente gerenciada.

Na interação com tal especialista, o EC deve tentar: minimizar os longos discursos com

diplomacia, e prosseguir para outras questões. Muitas vezes senso de humor pode atingir o

efeito desejado.

10.6.5. O Especialista incomunicável

Este tipo se expressa via questões curtas e não elabora sobre suas respostas- isto pode

frustrar o EC. Este perfil não pretende provocar um dano ao projeto, apenas é um indivíduo

calado e introspectivo. Neste tipo de interação, a paciência é extremamente importante.

O EC deve explorar cuidadosamente as respostas e explicações, deve estudar o domínio

de conhecimento para tentar desvendar outros ângulos enfoques que podem não ser óbvios

para ele.

10.6.6. O Especialista descuidado

É uma variação do perfil anterior. Nunca discorda do EC, pois simplesmente levaria

muito tempo para explicar as razões. O EC deve ter um cuidado extra para entender o domínio

a fim de verificar o conhecimento do especialista. O uso de gravação, se o especialista

concorda, pode forçá-lo a pensar mais sobre suas respostas.





38

10.6.7. O Especialista "pseudo conhecedor da AI"

Este tipo já leu um ou dois artigos sobre sistemas especialistas e pensa que já conhece

tudo. Este perfil pode subestimar o processo de aquisição de conhecimento e tentar se

envolver em detalhes da implementação do sistema que são da responsabilidade do EC.

Este especialista pode continuamente sugerir melhorias no processo de entrevistas e

tentar conduzir o EC. A forma de lidar com tal perfil e tentar gentilmente mostrar quem ele é

e quem é o EC.

11. Estrutura do processo de aquisição do conhecimento

Este processo pode se apresentar de várias formas, mas independente destas a aquisição

se processa um a um. De forma ideal, tal processo consiste em uma série de entrevistas, cada

uma com diferentes aspectos.

11.1. A entrevista inicial

Principal objetivo do primeiro encontro- estabelecer uma relação harmoniosa com o

especialista. Neste sentido, o EC deve tentar deixar uma boa impressão. Isto pode ser obtido

mostrando ao especialista que o EC já tentou adquirir um certo entendimento básico do

domínio de conhecimento antes do encontro.

Uma típica agenda

• Introdução e uma conversa leve

• Uma explicação do que são sistemas especialistas e sua relação com o projeto.

• Uma discussão sobre a importância do projeto (se aplicável)

• Uma discussão sobre o que é esperado do especialista e também o que ele pode

esperar do EC.

• Uma discussão de materiais para leitura que o especialista recomenda para que o EC

possa se familiarizar com o domínio.





39

• A programação para o próximo encontro.

Nesta primeira reunião as vantagens de um projeto deste tipo devem ser claramente

expostas. A profundidade da discussão deve ser determinada pelo grau de conhecimento que o

especialista tem sobre informática. Caso o especialista não tenha conhecimento sobre esta

área, pode ser necessária a definição de termos básicos.

Um ponto chave é tornar o especialista familiarizado com o que será feito e não os

detalhes de como será feito.

As regras básicas que definem o desenvolvimento de um SE devem ser discutidas. O

principal requisito para estabelecer uma relação harmoniosa entre o especialista e o EC é a

identificação das expectativas de ambos. É crítico que o especialista saiba deste o princípio o

que lhe será solicitado em termos de tempo, esforço e cooperação. Da mesma forma, é

importante que ele saiba o que pode esperar do EC. Por exemplo, no processo de aquisição de

conhecimento, será necessário apenas obter do especialista uma orientação geral e o EC

saberá definir os passos posteriores?

Se o especialista não pode ou não deseja se comprometer com o projeto, é melhor saber

disto no início de tal forma que alternativas possam ser exploradas.

Juntamente com esta discussão, deverá haver uma descrição do processo de entrevistas,

uma explicação do que é o processo incremental, e possivelmente alguns aspectos sobre

verificação e testes.

É importante que esta primeira reunião seja curta, não mais que uma hora. Lembrando

que o objetivo principal é estabelecer uma relação harmoniosa com o especialista.

11.2. Organização das sessões para aquisição do conhecimento

Estas podem ser classificadas em dois grupos:

• sessões para definição de conhecimento genérico

• sessões para solução de problemas específicos

O conhecimento adquirido das sessões do primeiro tipo, embora importante e educativo,

provavelmente não será codificado na base de conhecimento, mas será vital para obter o

entendimento necessário para a solução de problemas específicos.





40

11.3. Sessões para definição de conhecimento genérico

As sessões que seguem a entrevista inicial são deste tipo.

Os principais objetivos são:

• Entender melhor o domínio

• Entender as opiniões e pontos de vista do especialista sobre o domínio.

• Continuar desenvolvendo uma relação harmoniosa com o especialista

Antes destas sessões o EC deve ter se familiarizado com a literatura sugerida pelo

especialista e conhecer o vocabulário e o entendimento básico do domínio, para capacitá-lo a

dialogar com o especialista.

Neste tipo de sessão, a aquisição de conhecimento se dá principalmente através de

questões abertas. Este tipo de questão requer uma discussão e não pode ser respondida

apenas com sim, não, um termo ou um número.

Geralmente, os especialistas apreciam a oportunidade de falar abertamente sobre o

domínio. Além disto, este tipo de questão serve com um aprendizado para o EC. Mesmo

especialistas que são relutantes ou desconfiados tornam-se mais cooperativos com este tipo de

questão. Com este tipo de questão, o EC verifica seu entendimento básico sobre o domínio. Se

alguns conceitos ou termos não são entendidos, é aqui o momento de perguntar.

O risco com as questões abertas é que o especialista pode divagar nas respostas, e um

considerável tempo pode ser perdido.

Este tipo de questões requer uma boa dose de tato e paciência do EC para manter

controle da entrevista sem provocar desconforto no especialista.

Entrevistas deste tipo podem variar de uma a três horas de duração. É frequentemente

difícil e indesejável marcar períodos mais longos com especialistas, pois estes são muito

requisitados.

A habilidade de manter a concentração também diminui após duas ou três horas. Caso

seja uma opção, é melhor agendar tais reuniões para o período da manhã, pois a mente ainda

está "fresca" e menos provável que o especialista já tenha se envolvido com algum problema.





41

As entrevistas via questões abertas devem continuar até que o EC tenha obtido um

adequado entendimento do problema, das opiniões e pontos de vista do especialista.

11.4. Sessões para solução de problemas específicos

Uma vez que o EC tenha obtido o entendimento básico do problema, o processo

incremental terá início com a definição de uma sub-área que servirá de primeira parte do

conhecimento a ser representada.

Apesar de ter sua definição um tanto quanto nebulosa esta sub-área deve envolver

problemas que são:

• Bem entendidos pelo especialista em questão.

• Relativamente bem compreendidos pelo EC.

• De largura e profundidade suficientes para representar dificuldades na solução de

problemas do domínio.

• Suficiente pequena para requerer apenas de dois a três meses de esforço.

Nesta ocasião deve-se modificar a abordagem de questões genéricas, amplas, para

questões altamente direcionadas.

O objetivo destas entrevistas é mostrar como o especialista soluciona os problemas

específicos. Muitas das questões aqui empregadas são do tipo questões fechadas, cujas

respostas podem ser do tipo sim/não ou números.

Durante estas entrevistas, deve-se estar atento para manter o especialista focalizado no

problema em questão, diplomaticamente evitando que ele divirja das questões apresentadas.

Esforços devem ser feitos no sentido de relacionar cada entrevista com as demais,

resumir e revisar o conhecimento adquirido nas entrevistas anteriores.

Esta revisão permite ao especialista verificar quão corretamente o conhecimento foi

entendido, e promove uma continuidade do processo de aquisição.





42

12. Organização Do Conhecimento

Uma técnica de organização do conhecimento bastante utilizada é conhecida como saída-

entrada-meio. A seqüência é:

• Identificar as respostas ou soluções para o problema em questão - as saídas do

sistema. Estas representam os objetivos que o especialista e o EC têm quando buscam uma

resposta. No caso de existir mais de uma resposta, as diferenças entre elas devem ser

claramente identificadas e entendidas pelo EC.

• Identificar as fontes de informação que o especialista usa para deduzir a solução - as

entradas do sistema. Como estas entradas são identificadas, determinadas e geradas deve

também ser entendido pelo EC.

• Finalmente e mais importante, determinar as conexões entre entradas e saídas - o

meio. Estas conexões representam o núcleo do conhecimento do especialista. Algumas

entradas podem não ser necessárias inicialmente. Adicionalmente, algumas metas

intermediárias ou hipóteses podem ser requeridas para se completar as conexões.

Exemplo: um sistema especialista para diagnose de mau funcionamento no sistema de

refrigeração de automóveis.

O sistema baseia-se no fato de que o motorista não tem conhecimento de mecânica e que

a comunicação entre o motorista e o sistema se dá via telefone, ou seja, o especialista não vê o

automóvel.

O EC define uma lista de possíveis problemas que podem ocorrer com o sistema de

refrigeração do automóvel.

SAÍDAS: as possíveis saídas deste tipo de problema são:

• Vazamento no radiador.

• Correia quebrada no ventilador.

• Bomba de água defeituosa.

• Perda de refrigerante por evaporação devido à folga da tampa do radiador.

• Mangueira de água quebrada ou rachada.

• Refrigerante congelado.





43

ENTRADAS: as informações que um mecânico necessita para diagnosticar o mau

funcionamento do sistema são:

• Indicador de temperatura no painel.

• Vapor saindo do capô do motor.

• Condições ambientais.

• Poça de refrigerante embaixo do motor.

A fim de relacionar as entradas às saídas, o especialista define regras. Algumas destas

apresentadas a seguir:

Regra 1: a presença de indicação "quente" no medidor de temperatura no painel

geralmente implica que pelo menos um problema existe.

Regra 2: a ausência de indicação "quente" não necessariamente implica na ausência de

um problema.

Regra 3: uma grande poça de refrigerante embaixo do motor pode indicar vazamento no

radiador, mangueiras quebradas, e/ou bomba defeituosa.

Regra 4: uma pequena poça de refrigerante embaixo do motor geralmente implica na

bomba defeituosa.

Regra 5: ausência de poça de refrigerante e uma indicação “quente” no medidor de

temperatura indicam uma correia quebrada no ventilador.

Regra 6: uma temperatura ambiente abaixo de 10o F sugere o refrigerante congelado.

Regra 7: a presença de um ruído chiado e uma pequena poça de refrigerante embaixo do

motor indica vazamento no radiador e/ou mangueiras.

Embora as técnicas baseadas em entrevistas sejam muito utilizadas, elas nem sempre são

as mais eficientes. A razão disto é que alguns especialistas por mais interessados que sejam

em cooperar com o EC têm dificuldade em verbalizar o conhecimento.

Nestes casos, técnicas alternativas devem ser empregadas, estas podem ser divididas em

duas categorias:

• Observacionais - onde o EC observa o especialista em sua tarefa e busca entender seu

método de resolução





44

• Intuitiva - onde o EC tenta se tornar um "pseudo-especialista" e implementa parte do

conhecimento sobre o domínio.

12.1. Técnicas observacionais

• Observação em silêncio no local

Devido ao fato do raciocínio do especialista não sofre interrupção, ele pode executar uma

tarefa de forma bem eficiente.

Com a falta de interação o EC pode deixar de perceber detalhes sobre a forma de solução

adotada. Consequentemente, esta técnica deve ser considerada apenas para se ter uma noção

geral do problema, e não para obter conhecimento detalhado.

• Observação no local com discussão

Se o problema é rotineiro para o especialista, não haverá uma grande diferença devido à

interação. Caso contrário, o especialista pode ter uma certa dificuldade em obter a solução.

Alguns sintomas de que essa técnica não é adequada: hesitação para tomar uma decisão,

sinais de desconforto, ou recusa em criar uma solução perante o EC.

• Exercitando o especialista

Baseia-se em preparar casos especiais de dificuldade variável para exercitar o

especialista. Isto considera o fato de que, em algumas áreas, os problemas são em sua maioria

rotineiros.

Formas destas técnicas:

• Tarefas com informações limitadas - neste caso, uma tarefa rotineira é executada,

mas o especialista não conhece uma certa informação que tipicamente é disponível.

• Tarefas com restrições - uma tarefa típica é desempenhada, mas o especialista deve

executá-la com restrições, por exemplo, de tempo.

• Descrição e análise de problemas

Esta técnica é baseada na análise de problemas clássicos de um domínio de

conhecimento. Geralmente, são usados problemas de sala de aula que representam

importantes relações no domínio.





45

A análise destes problemas pelo EC é tipicamente na forma de estudo de caso, onde

algumas questões chaves são:

• Por que tais problemas são usados para ensinar este domínio?

• Quais são as características que tornam cada um destes problemas importantes?

12.2. Técnicas intuitivas

Estas técnicas são idealmente aplicadas para situações onde o EC já tem um significativo

entendimento do processo de tomada de decisão e deseja verificar quão correto é este

entendimento.

Estas técnicas não são aplicadas geralmente para aquisição, mas sim verificação de

conhecimento antes de representá-lo. Neste caso, o EC e o especialista trocam de papéis, e o

EC tenta resolver um problema na presença de um especialista. Este processo pode esclarecer

e modificar abordagens previamente consideradas como adequadas e pode fornecer novas

informações de como proceder a solução.

13. Protótipo Inicial na aquisição do conhecimento

No início do desenvolvimento de sistemas computacionais, tinha-se como padrão tentar

obter uma completa e correta especificação do sistema antes de começar sua implementação.

Todavia, para SE, a experiência demonstra que tal forma não mostrou-se eficiente.

No início do projeto, as idéias das pessoas envolvidas do que é necessário e como isto se

dará na prática são difusas e imprecisas.

Uma especificação pode ser difícil de entender, particularmente se for usado um jargão

computacional, e é extremamente difícil se imaginar como será "um sistema dinâmico"

partindo-se de uma "descrição estática".

O processo de "prototipagem" envolve desenvolver um modelo relativamente barato e

mais simples de um futuro produto, e usá-lo como um dispositivo para aprender sobre o

futuro trabalho.





46

Todavia, se este processo não for disciplinado pode ser perigoso, pois o ciclo de

construir, modificar e descartar pode se repetir indefinidamente.

No contexto de sistemas especialistas, prototipagem geralmente envolve três aspectos:

• Protótipo descartável - isto implica em desenvolver um modelo com a intenção de

aprender com base nele e depois descartá-lo.

• Protótipo incremental - uma versão para teste de um produto. Neste caso, um projeto é

dividido em pequenos projetos e a cada estágio de incremento na funcionalidade do sistema,

uma versão é apresentada para teste da parte a ser adicionada no sistema.

• Protótipo evolutivo - contínua modificação de uma versão em estágio de operação.

Neste sentido, o sistema deve ser concebido para permitir constantes atualizações.

Na prototipagem, um aspecto chave a ser investigado é a interface do sistema. Alguns

estudos mostram que tal aspecto pode significar até 50 % do esforço no desenvolvimento.

13.1. Impacto desta abordagem sobre o perfil do EC

Caso a prototipagem seja adotada, o conhecimento técnico do EC sobre programação

deve ser consideravelmente mais amplo que no caso de considerar apenas um "modelo no

papel".

Com o protótipo inicial, a equipe de EC tem condições de receber um rápido retorno

sobre:

• escopo de conhecimento

• necessidades dos usuários

• validade das decisões tomadas no projeto.

Com isto, caso uma mudança de paradigma seja necessária seu impacto será minimizado

pelo fato da mudança ter sido constatada num estágio inicial do desenvolvimento.

O desenvolvimento do protótipo envolve o seguinte ciclo:

• adquirir partes do conhecimento das fontes

• implementar tais partes no sistema

• rever o resultado da implementação com especialistas





47

• refinar a base de conhecimento para corrigir os problemas detectados

• adquirir outras partes de conhecimento ...

Com a progressiva adição de módulos, a base de conhecimento pode ser rapidamente

obtida, ainda que com uma funcionalidade parcial, e colocada em teste, embora não esteja

completa. Tal abordagem não é aplicável para Programas Convencionais, que por sua

natureza procedural, geralmente devem ser completamente implementados antes do uso.

14. Relação entre protótipo e sistema final

Algumas referências recomendam que o protótipo seja descartado após sua avaliação e

se inicie o desenvolvimento do sistema final da estaca zero, a menos que todas as decisões

tomadas no protótipo sejam justificadas (um cenário bem raro).

Aspectos Gerais sobre o Protótipo Inicial

• A base de conhecimento deve ser suficiente para resolver alguns subproblemas de

início ao fim, mas relativamente pequena para não requerer um significativo esforço. Por

exemplo, num sistema para diagnóstico de problemas em veículos, um protótipo inicial pode

corresponder ao sistema de injeção de combustível.

• Uma vez que o conhecimento, as entradas e saídas de, por exemplo, 5 a 10

subproblemas tenham sido implementadas e para expandir o sistema o processo seja

simplesmente repetitivo, então o protótipo inicial estará concluído.

• A equipe de desenvolvimento deve aprender o máximo possível com o protótipo

inicial. E determinar quanto do sistema final já está implementado no protótipo.

• O esforço esperado deve ser em torno de 2 a 4 semanas para um sistema pequeno, e de

2 a 4 meses para sistemas de médio e grande porte.

• A interface é um aspecto importante a ser verificada com o protótipo. Todavia, a

equipe não deve alocar tempo para a interface em detrimento da base de conhecimento.

• O protótipo deve ser validado da mesma forma que o sistema final será. Assim, alguns

usuários do futuro sistema devem ser permitidos e até estimulados a usarem o protótipo.





48

• Um relatório final deve ser escrito na conclusão do protótipo, incluindo aspectos de

sua validação.

15. Verificação e Validação

O futuro de Sistemas Especialistas será severamente comprometido, se os

desenvolvedores destes sistemas não atribuírem a devida atenção ao problema da

confiabilidade. Além disto, considerando o fato que SE são considerados programas

"inteligentes", a perda de credibilidade pelo usuário pode resultar de conclusões errôneas do

sistema.

As principais fontes de erro em SE são:

• A falta de especificação do sistema, ou quando esta existe, a falta de seu cumprimento.

• Erros de semântica e sintaxe introduzidos durante a implementação do sistema (bugs).

• A incorreta representação do domínio, resultando numa solução errônea ou na

incapacidade de encontrar uma solução para o problema.

A verificação aborda as duas primeiras categorias de erros. Examinando o cumprimento

das especificações e assegurando a consistência e abrangência da base de conhecimento, que

são afetadas por erros de semântica ou sintaxe.

A validação envolve várias questões, como as descritas acima, mais ainda, busca detectar

se o domínio de conhecimento está correto e que o sistema desenvolve as soluções de forma

correta e precisa.

15.1. Comparação de Verificação e Validação (V&V) com Programas

Convencionais

O que torna V&V diferentes em sistemas convencionais?

Parte disto origina-se de como SE são diferentes de sistemas convencionais.

• SE não são de natureza completamente objetiva. A estrutura de solução de problemas

neles representada é baseada em impressões subjetivas. De fato, para algumas aplicações

se a mesma situação for apresentada a dois especialistas de mesma competência, cada





49

um pode decidir abordar o problema de forma diferente, ainda que correta, tendo como

resultado duas soluções diferentes. Mesmo que ambas as soluções sejam apropriadas, cada

especialista considerará sua solução a melhor e a do outro menos ótima.

• Uma certa dose de incerteza é tolerada em sistemas especialistas. As soluções não são

sempre precisas e exatas, mas têm uma incerteza ou imprecisão ou devido aos dados ou ao

domínio de conhecimento.

• Enquanto para certas aplicações programas convencionais podem ser verificados em

laboratórios, SE, por outro lado, não podem facilmente ser verificados em laboratórios.

Isto porque eles geralmente não geram um modelo físico, mas sim a impressão compilada de

um sistema físico.

• Em sistemas convencionais, a questão de correção dos resultados de um teste não é em

geral um problema, pois o verificador do sistema sempre pode determinar se a resposta

fornecida pelo programa está certa ou não. No caso de SE, como estes modelam o

conhecimento de um especialista sobre um domínio, um especialista humano está sempre

envolvido. Isto implica que um especialista (ou um grupo de especialistas) é o avaliador final

da eficácia de um SE.

Dadas estas diferenças, novos métodos de avaliar SE são necessários para assegurar sua

confiabilidade. Nenhuma técnica única foi desenvolvida que tenha ganho aceitação universal,

ao invés disto, recomenda-se a combinação destas técnicas.

15.2. Verificação

Um dos objetivos da verificação é assegurar que existe uma correspondência entre a

especificação do sistema e o que este realmente executa.

Duas etapas compreendem a verificação de SE: 1 - verificar que o sistema adere às suas

especificações e 2 - verificar quanto à existência de erros de semântica e sintaxe na base de

conhecimento.

Quanto às especificações:

• O adequado paradigma de representação do conhecimento foi implementado.

• A técnica de raciocínio adequada foi empregada.





50

• O projeto e implementação foram modulares.

• O sistema tem uma interface apropriada com outros sistemas.

• A interface do usuário corresponde às especificações.

• A forma de explicação foi apropriada ao usuário pretendido.

• Os requisitos de tempo de execução do sistema foram satisfeitos.

• O sistema tem manutenção conforme o grau especificado.

• O sistema satisfaz as especificações de segurança.

• Foram adotadas medidas de segurança para proteger que a base de conhecimento seja

modificada sem autorização.

A verificação de regras quanto a erros de sintaxe deve checar:

• Regras redundantes - duas regras são redundantes se elas possuem premissas

idênticas e levam a conclusões idênticas. Isto também acontece mesmo quando as conclusões

não são sintaticamente idênticas, mas levam ao mesmo significado, exemplo:

Se a umidade for alta e a temperatura quente

Então haverá tempestades com trovões

OU

Se a temperatura é quente umidade for alta

Então haverá tempestades com raios.

Redundância semântica é menos comum, porém mais difícil de detectar porque o sistema

não conhece a diferença entre o significado das conclusões.

• Regras conflitantes - quando a premissa de duas regras é idêntica, mas suas

conclusões são conflitantes.

• Regras incluídas - uma regra é incluída por outra se esta tem mais restrições

condicionais com as conclusões idênticas. Exemplo:

(Regra 7)

Se a temperatura está quente e





51

a umidade está alta

a pressão barométrica é baixa

Então Haverá trovoadas

(Regra 8)

Se a temperatura está quente e

a umidade está alta

Então Haverá trovoadas

A regra 7 está incluída na regra 8, porque a primeira tem uma condição a mais que a

última.

• Regras circulares - conjunto de regras que apresentam um encadeamento entre si

formando loops. (já apresentado)

• Condicionais desnecessárias - quando duas regras com conclusões idênticas têm

quase as mesmas premissas.

• Regra sem-saída (dead-end rules) - no encadeamento direto, estas são regras cujas

ações não afetam qualquer conclusão e não são usadas por outras regras para gerar outras

conclusões.

• Regras "perdidas" - são caracterizadas por fatos que não são usados no processo de

inferência, conclusões não afetadas por qualquer outra regra ou função, ou falhas em cobrir

todos os possíveis valores das entradas.

Se o marcador de combustível indica vazio

Então o tanque está vazio

Neste caso, se a conclusão não for empregada para conectar a premissa à solução do

problema de partida do motor, então esta será uma regra perdida.

• Regras inatingíveis - no sistema de encadeamento direto, este tipo de regra indica que

suas premissas jamais serão satisfeitas, ou pela ausência de certas regras ou pela falta de

dados de entrada. Isto é equivalente a uma "regra sem-saída" no sistema de encadeamento

reverso.





52

Validação

Esta tarefa é inerentemente mais complexa que verificação. Envolve a determinação da

eficácia do sistema final com relação às necessidades e requisitos do usuário.

O Que Validar?

A validação da base de conhecimento pode ser executada validando:

• os resultados intermediários

• os resultados finais

• alguma combinação destes

Os resultados finais são as metas principais do sistema, portanto tais resultados não

podem estar ausentes na validação. Todavia, a validação de resultados intermediários pode

fornecer valiosas orientações quanto à operação do sistema e auxiliar a rapidamente corrigir

problemas a custo relativamente baixo.

15.2.1. Metodologias de Validação

• Validação Informal - avaliação superficial e qualitativa através de reuniões com um

ou mais especialistas do domínio. Embora, tal avaliação seja útil durante o desenvolvimento

de um módulo da base de conhecimento, este método não pode ser considerado satisfatório

com único meio de avaliar a base de conhecimento.

• Validação Formal - isto requer testes predefinidos, onde o sistema é tratado como

uma "caixa preta", tendo suas saídas comparadas com respostas de especialistas. Na

comparação, as opiniões dos especialistas podem variar de simples respostas na forma de sim

ou não, ou uma faixa de valores, tanto qualitativos como quantitativos. Se esta abordagem é

adotada, os desenvolvedores devem assegurar que os especialistas/usuários não têm

dificuldade em operar o sistema.

Uma forma alternativa de eliminar as dificuldades dos usuários é apenas apresentar os

resultados a um painel de avaliadores. Deve ser considerado, que alguns especialistas podem

ser favoráveis ou desfavoráveis ao uso de computadores, o que neste caso pode influenciar na

opinião deles sobre o sistema.





53

É recomendável definir um painel de avaliadores com uma combinação de membros que

participaram do desenvolvimento e membros externos. Isto confere objetividade e, ao mesmo

tempo, diminui a tendência de preconceitos na avaliação.

Uma alternativa de avaliação é baseada no Teste de Turing. Neste contexto, a um

avaliador são apresentados resultados obtidos pelo sistema e de um especialista. A idéia

básica deste teste é muito simples, porém sua implementação pode ser complicada. O tipo de

saída do sistema deve ser na forma de um diálogo. A vantagem desta abordagem é a

eliminação da parcialidade pró ou contra o uso de computadores.

Um aspecto adicional a ser considerado na elaboração de testes de avaliação é o fato de

que à medida que o número de regras ou classes no sistema cresce, o conjunto de testes

exaustivos expande exponencialmente.

15.2.2. Testes de campo

Independente de quantos testes sejam realizados na fase de desenvolvimento ou quão

exaustivos estes sejam, através dos testes de campo sempre descobrem-se erros inesperados

ou efeitos indesejáveis.

No teste protótipo existe um risco inerente:

O sistema pode perder credibilidade antes dos usuários operarem o produto final.

Recuperar esta credibilidade pode ser difícil.

Algumas etapas para diminuir este risco.

• Os usuários devem ser receptivos ao conceito de SE.

• Eles devem estar conscientes que estão testando apenas um protótipo.

15.2.3. Validação de subsistemas

Este método requer que a base de conhecimento seja particionada em submódulos. Uma

metodologia adequada de projeto requer que o sistema seja modular, porém este método

possui duas desvantagens:

• Nem todos os sistemas são claramente decompostos em sub-sistemas independentes.





54

• A validação de todos sub-sistemas não equivale à validação do sistema completo.

15.2.4. Quando é apropriado validar?

A abordagem mais amplamente aceita é que o processo de validação deve começar com

a especificação do sistema e prosseguir ao longo de seu desenvolvimento. Mesmo assim, deve

existir uma validação formal no "estágio final" do sistema.

A validação formal deve se iniciar tão logo o protótipo inicial seja desenvolvido. Neste

estágio, geralmente conhecido como teste-alfa os objetivos iniciais do projeto do sistema são

reconsiderados e as necessárias modificações são feitas.

16. Algumas observações sobre Orientação a Objetos

(defclass designer (is-a USER)

(role concrete)

(pattern-match reactive) ;; importante para permitir que o objeto seja usado no lado esquerdo da regra. (Ver manual pag. 97.)

(slot id (type SYMBOL) (create-accessor read-write) )

)

Regras usando objetos:

(defrule <nome da regra>

;; this rule is necessary because of inconsistence in the user input

(object (is-a <nome da classe>) <uso de alguma variável baseada no slot>... )

..outros condicionais

=>

;;ações da regra

)

Considerações para definição de classes (manual pag. 105)

• a hierarquia da classe deve ser definida em incrementos lógicos de especialização

usando a relação "is-a"





55

• uma classe é desnecessária se ela possui apenas uma instância

• uma classe não deve ser identificada com o mesmo nome de uma instância e vice-

versa (isto é apenas para eliminar alguma confusão)

Algumas funções para manipulação de objetos:

(do-for-instance ((?var <nome da classe>)) (comparação de algum atributo)

(progn ... ações

)

)

Exemplo: imprimir o nome do valor do slot nome de uma instância pessoa cuja idade seja maior que 20

(do-for-instance ((?alguem PESSOA)) (> ?alguem:idade 20)

(progn (printout t "pessoa com idade maior que 20" ?alguem:nome)

)

)

(do-for-all-instances ( (?var1 <nome da classe>) (?var2 <nome da classe>) )

(comparação de atributos das instâncias)

(progn ... ações

)

)

Exemplo: imprimir os nomes das pessoas com mesma idade

(do-for-all-instances ( (?x1 PESSOA) (?x2 PESSOA) ) (eq ?x1:idade ?x2:idade)

(progn (printout t "estas pessoas tem a mesma idade" ?x1:nome e ?x2:nome)

)

)





56

17. Incerteza

Mesmo considerando que existem aplicações de SE que podem ser implementadas com

solução (abordagem) exata, muitos outros requerem um raciocínio inexato envolvendo fatos

ou regras com incerteza. Exemplos clássicos de sistemas que lidam com incerteza são

MYCIN e PROSPECTOR.

Nestes sistemas, conclusões são obtidas mesmo quando todas as evidências para provar

completamente tais conclusões não são conhecidas.

Embora seja possível obter uma conclusão mais confiável através de mais testes, existem

problemas com o aumento de tempo e custo de testes. Estas restrições de tempo e custo são

particularmente importantes no caso de tratamento médico. Atrasar um tratamento devido a

mais testes aumenta os custos e, enquanto isto, o paciente pode vir a falecer.

No caso de mineração, o custo de testes adicionais também é um fator significante. Pode

ser mais vantajoso iniciar as escavações se tem 95% de chance de sucesso do que gastar mais

centenas de milhares de dólares para se obter um grau de confiança de 98%.

As fontes de incerteza possíveis em SE podem ser causadas por problemas nos dados,

por exemplo:

• dados ausentes ou não disponíveis;

• os dados podem estar presentes mas não confiáveis ou ambíguos devido aos erros de

medida, ou medições conflitantes, etc.

• a representação dos dados pode ser imprecisa ou inconsistente

• os dados podem ser apenas a melhor suposição do usuário

• os dados podem ser baseados em valores "default" e tais valores podem ter exceções

Além disto, a incerteza pode ser causada pelo conhecimento modelado:

• representar as melhores suposições dos especialistas que são baseadas em associações

plausíveis ou estatísticas que eles observaram

• não ser apropriado em todas as situações

Considerando estas várias fontes de erro, a maioria dos SE requer a incorporação de

alguma forma de representação de incerteza.





57

Ao se implementar um esquema de incerteza, deve-se considerar três questões principais:

• como representar dados incertos

• como combinar dois ou mais dados incertos

• como gerar inferência usando-se dados incertos

17.1. Redes Bayesianas

Um dos mais conhecidos métodos de modelar incerteza é a chamada Rede Bayesiana.

Este método é baseado na Teoria da Probabilidade.

Como se sabe, os SE descrevem o conhecimento no formato Se-Então, no caso de uma

regra Bayesiana, este formato é acrescido de um fator de probabilidade:

Se X é verdadeiro

Então Y pode ser concluído com probabilidade p

Por exemplo:

Se o paciente está resfriado

Então o paciente irá espirrar (0.75)

Contudo, o que ocorre quando se observa a presença de Y (i.e. o paciente espirrou) sem

nada se saber sobre a existência de X (ou seja, o paciente está resfriado)?

O que se pode concluir sobre a possibilidade do paciente estar resfriado?

Neste contexto, uma regra bayesiana descreve como calcular esta probabilidade.

p(H | E) - a probabilidade da existência da hipótese H dada a existência do evento E.

p(H) e p(E) - descrevem as probabilidades das existências da hipótese H e evento E,

respectivamente

Exemplo: sejam H- hipótese e E- evidência

Considerando que:

)(

)(*)|()|(

Ep

HpHEpEHp =





58

H- paciente esteja resfriado, E- paciente está espirrando

p(H)= p(paciente esteja resfriado)= 0.2

p(E | H)= p(paciente esteja espirrando | ele esteja resfriado)= 0.75

p(E | ~H)= p(paciente esteja espirrando | ele não esteja resfriado)= 0.2

Então

p(E)= p(paciente esteja espirrando)

Observação: vale destacar que a probabilidade de certo efeito dada uma certa hipótese,

ou seja, p(E | H), é o fundamento de toda a construção da base de conhecimento, e deve ser

conhecida a priori.

Calcular a probabilidade do paciente estar resfriado considerando o fato dele estar

espirrando.

P(H|E) =(0.75)*(0.2)/(0.31)= 0.48387

Calcular a probabilidade do paciente estar resfriado considerando que ele não esteja

espirrando.

Sendo assim o fato do paciente estar espirrando aumenta a probabilidade dele estar

resfriado de aproximadamente 2,5 vezes (de 0.2 para 0.48). Enquanto que o fato dele não estar

espirrando diminui a probabilidade de estar resfriado de 3 vezes.

No exemplo apresentado, uma evidência afeta apenas uma hipótese. Contudo isto deve

ser generalizado pelo fato de que no mundo real se trabalha com "m" hipóteses e "n"

evidências.

31.0)8.0(*)2.0()2.0(*)75.0()(

)(~*)|~()(*)|()(

=+=

+=

Ep

HpHEpHpHEpEp

)(

)(*)|()|(

Ep

HpHEpEHp =

07246.0)31.01(

)2.0(*)75.01(

)(~

)(*)|(~)|~( =

−

−==

Ep

HpHEpEHp





59

Desta forma a equação que determina a probabilidade de uma certa hipótese Hi baseada

num conjunto de evidências E1, E2...En, é dada por:

Esta probabilidade é definida como a probabilidade a posteriori da hipótese Hi com a

observação das evidências E1, E2...En.

Tal equação é derivada do fato de que as evidências são eventos condicionalmente

independentes com base na hipótese. Esta suposição causa dificuldades na implementação

deste método.

A fim de exemplificar a aplicação deste método considere o seguinte problema:

Três hipóteses mutuamente exclusivas

H1- paciente resfriado

H2- paciente é alérgico

H3- paciente é sensível à luz

E duas evidências condicionalmente independentes

E1- paciente espirra e E2- paciente tosse

Apresenta-se a seguinte tabela de probabilidades

i=1

(resfriado)

i=2

(alergia)

i=3

(sensibilidade à luz)

p(Hi) 0.6 0.3 0.1

p(E1|Hi) 0.3 0.8 0.3

p(E2|Hi) 0.6 0.9 0.0

Neste caso, sendo observada a evidência E1 (paciente espirra), pode-se calcular a

probabilidade posterior da hipótese do paciente estar resfriado (H1)

)...(

)(*)|...()...|(

21

2121

n

iinni

EEEp

HpHEEEpEEEHp =





60

17.1.1. Vantagens e desvantagens das Redes Bayesianas

O aspecto mais significante é que este método é fundamentado na lei das probabilidades.

É considerada a forma mais bem estabelecida de todos os métodos de manipulação de

incerteza. Também possui uma semântica bem definida para suporte à decisão.

Algumas desvantagens

• Este método requer uma significante quantidade de dados probabilísticos para

construir a base de conhecimento. Por exemplo, um sistema de diagnóstico tendo 50

conclusões detectáveis (p) e 300 características observáveis e relevantes (q) requer um

mínimo de 15050 (p*q + p) valores de probabilidades, assumindo que todas as conclusões

sejam eventos mutuamente exclusivos, que as características sejam condicionalmente

independentes para cada conclusão e se todas as características são valores coerentes. Caso

estas considerações não sejam satisfeitas a inteira rede pode ser comprometida.

• Em que são baseadas as probabilidades usadas?

Se estas são baseadas em estatística, o tamanho das amostras deve ser suficiente de tal

forma que as probabilidades obtidas sejam precisas. Se os valores foram fornecidos por

especialistas humanos, estes valores são consistentes e amplos?

• Com freqüência o tipo de relação entre a hipótese e a evidência é importante para

determinar como a incerteza deve ser modelada. Reduzir esta associação a simples números

remove informações relevantes que podem ser necessárias para uma manipulação adequada

da incerteza. Por exemplo, redes bayesianas para sistemas de diagnóstico médico falharam em

obter aceitação, pois médicos desconfiam de sistemas que não possam fornecer explicações

descrevendo as conclusões obtidas, tal aspecto é difícil de modelar via rede bayesiana.

4.01.0*3.03.0*8.06.0*3.0

6.0*3.0

)(*)|(

)(*)|()|(

1

11111 =

++==

∑ ii HpHEp

HpHEpEHp





61

• A redução das associações a números também elimina a aplicação deste conhecimento

em outras tarefas. Por exemplo, neste tipo de sistema as associações que permitiriam explicar

o encadeamento lógico ao usuário são perdidas.

18. Lógica Difusa (Fuzzy Logic)

Em meados da década de 60, Zadeh desenvolveu o conceito de conjuntos difusos para

considerar vários conceitos usados no raciocínio humano que são intrinsecamente vagos e

imprecisos, tais como alto, velho, etc... Mais tarde ele desenvolveu a lógica difusa para

considerar a imprecisão de "quantificadores" usados na linguagem natural, tais como muito,

poucos, etc...

Pelo fato de que muitos especialistas expressam seu conhecimento usando conceitos

similares aos conjuntos difusos, a lógica difusa aplica-se naturalmente aos sistemas

especialistas.

18.1. Definição de termos

Dado um conjunto S={S1,S2,...,Sk} de possíveis membros de um outro conjunto C, o

predicado difuso Fp classifica os membros de S na faixa [0 1] dependendo do grau de

pertinência em relação ao conjunto C.

Fp(Si) -> [0 1]

Fp(Si)= 1 define a pertinência de Si em relação a C, e

Fp(Si)= 0 define a não-pertinência

Os valores entre 0 e 1 descrevem a medida do grau com que um dado elemento Si

satisfaz um certo predicado Fp. Sendo assim, este predicado define o conjunto difuso.

Sp= {<si ni> si ∈ S, ni ∈ [0 1], Fp(si)= ni}

Todas as operações fundamentais da teoria de conjuntos foram expandidas com seus

correspondentes conjuntos difusos.





62

• dois conjuntos difusos Sa e Sb são iguais se e somente se A(Si)=B(Si) para todos

elementos Si.

• O complemento de um conjunto difuso Sp é definido como ~Sp e tem o predicado

Fp~(Si)= 1- Fp(Si).

• O conjunto difuso Sa é um subconjunto de Sb se e somente se A(Si)≤ B(Si) para todos

elementos Si.

• A união de dois conjuntos difusos, Sa e Sb , é um conjunto difuso Sc onde C(Si)=

MAX[A(Si), B(Si)] para todos Si.

• A interseção de dois conjuntos difusos, Sa e Sb , é um conjunto difuso Sc onde C(Si)=

MIN[A(Si), B(Si)] para todos Si.

Exemplo classificação de pessoas conforme a altura

Altura alto baixo gigante

1,5 0.00 1.00 0.00

1,6 0.08 0.92 0.04

1,7 0.32 0.68 0.08

1,75 0.50 0.50 0.18

1,8 0.82 0.18 0.32

1,9 0.98 0.02 0.50

2,0 1.00 0.00 0.75

Esta tabela representa três conjuntos difusos (alto, baixo e gigante) com seus valores de

pertinência (ni).

Como se definem os conjuntos "estatura média" e "não estatura média"?

Pode-se dizer que estatura média é definida como um indivíduo nem alto e nem baixo.

Portanto é a interseção dos conjuntos "não alto" e "não baixo". E por definição o conjunto

"não estatura média" é o complemento desse. Sendo assim, tem-se:





63

Altura Não alto Não baixo Estatura

média

Não

Estatura média

1,5 1.00 0.00 0.00 1.00

1,6 0.92 0.08 0.08 0.92

1,7 0.68 0.32 0.32 0.68

1,75 0.50 0.50 0.50 0.50

1,8 0.18 0.82 0.18 0.82

1,9 0.02 0.98 0.02 0.98

2,0 0.00 1.00 0.00 1.00

Por exemplo, se João tem entre 1,70 e 1,75 a possibilidade dele ser considerado alto será:

Poss (João ∈ Alto)= MAX ni ∈ {1,70; 1,75}= 0,50

18.2. Operadores difusos

• & lógico. Poss(A & B)= MIN [Poss(A),Poss(B)]

• OU lógico. Poss(A + B)= MAX [Poss(A),Poss(B)]

• Implica. A proposição de que se A então B Poss(B|A)= MIN[1, (1-Poss(A) +Poss(B))]

Modificadores comumente usados: "muito" muito A= A2 "não" não A= 1-A "extremamente" A =2A2 para valores entre 0 e 0.5

=(1- 2(1-A)2) para outros valores

Este operador de intensificação reduz o grau de "difusão" do conjunto.

Apesar desta técnica ser amplamente aplicada, ainda existe o debate sobre sua

viabilidade tendo em vista as dificuldades inerentes à técnica. Sobretudo, o desenvolvimento

das funções de pertinência não é trivial, e geralmente requer um tempo mais longo que o

desenvolvimento da base de conhecimento.

AAmenosoumais =±"...."

emc 6607 sistemas especialistas aplicados à engenharia ementa · viabilidade de sistemas...

Documents