UNIVERSIDADE FEDERAL DE SANTA CATARINA
1
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
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.
Sistemas Especialistas aplicados à Engenharia
Prof. Jonny Carlos da Silva, Dr. Eng.
UNIVERSIDADE FEDERAL DE SANTA CATARINA
2
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
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 SystemsProgramming, Second Edition, PWS Publishing Company, 1994.
Principles
and
4. GONZALEZ, Avelino J. and DANKEL, Douglas D., The Engineering of KnowledgeBased 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/
Sistemas Especialistas aplicados à Engenharia
Prof. Jonny Carlos da Silva, Dr. Eng.
UNIVERSIDADE FEDERAL DE SANTA CATARINA
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
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
Sistemas Especialistas aplicados à Engenharia
Prof. Jonny Carlos da Silva, Dr. Eng.
3
UNIVERSIDADE FEDERAL DE SANTA CATARINA
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
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
Sistemas Especialistas aplicados à Engenharia
Prof. Jonny Carlos da Silva, Dr. Eng.
4
UNIVERSIDADE FEDERAL DE SANTA CATARINA
5
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
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. 02
Identificação de áreas de projeto aplicáveis para SE.
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. 03
Escolha da técnica mais apropriada. Seleção da ferramenta SHELL.
4.1 Questões Humanas relacionadas ao desenvolvimento de SE. Engenharia de 02
conhecimento. Perfil do engenheiro de conhecimento. Questões éticas em SE.
5.1 Aquisição do conhecimento. Relacionamento com os especialistas do domínio. 01
Diferentes perfis de especialistas.
5.2 Aplicação de ferramentas computacionais. Protótipo inicial como instrumento 01
para facilitar a aquisição.
6.1 Validação e Verificação de SE - Comparação com técnicas utilizadas em 01
sistemas convencionais.
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 05
SHELL. Estrutura geral e desenvolvimento de exemplos
7.2 Seminários de avaliação
Sistemas Especialistas aplicados à Engenharia
Prof. Jonny Carlos da Silva, Dr. Eng.
02
UNIVERSIDADE FEDERAL DE SANTA CATARINA
6
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
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.
Sistemas Especialistas aplicados à Engenharia
Prof. Jonny Carlos da Silva, Dr. Eng.
UNIVERSIDADE FEDERAL DE SANTA CATARINA
7
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
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ãoespecialista 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.
Sistemas Especialistas aplicados à Engenharia
Prof. Jonny Carlos da Silva, Dr. Eng.
UNIVERSIDADE FEDERAL DE SANTA CATARINA
8
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
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.
Sistemas Especialistas aplicados à Engenharia
Prof. Jonny Carlos da Silva, Dr. Eng.
UNIVERSIDADE FEDERAL DE SANTA CATARINA
9
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
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.
Sistemas Especialistas aplicados à Engenharia
Prof. Jonny Carlos da Silva, Dr. Eng.
UNIVERSIDADE FEDERAL DE SANTA CATARINA
10
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
• 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.
Sistemas Especialistas aplicados à Engenharia
Prof. Jonny Carlos da Silva, Dr. Eng.
UNIVERSIDADE FEDERAL DE SANTA CATARINA
11
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
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
BASE DE
CONHECIMENTO
MÁQUINA DE
INFERÊNCIA
MEMÓRIA
OPERACIONAL
(REGRAS)
AGENDA
(FATOS)
HABILIDADE DE
EXPLICAÇÃO
HABILIDADE DE
AQUISIÇÃO DE
CONHECIMENTO
INTERFACE COM O
USUÁRIO
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.
Sistemas Especialistas aplicados à Engenharia
Prof. Jonny Carlos da Silva, Dr. Eng.
UNIVERSIDADE FEDERAL DE SANTA CATARINA
12
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
• 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).
Sistemas Especialistas aplicados à Engenharia
Prof. Jonny Carlos da Silva, Dr. Eng.
UNIVERSIDADE FEDERAL DE SANTA CATARINA
13
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
• 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
Assumida correta
Incompleta, incorreta.
Dificuldade para manipular
Muito adequado
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
Estruturado
Pouco ou nenhum
Difícil
Razoável
Feita em saltos
Incremental
Entrada de dados
Entrada imprevista
Saída
Projeto do sistema
Facilidade de mudança
Expansão
Sistemas Especialistas aplicados à Engenharia
Prof. Jonny Carlos da Silva, Dr. Eng.
UNIVERSIDADE FEDERAL DE SANTA CATARINA
14
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
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
Análise geológica de dados para prospecção de minerais
Obs.: Através PROSPECTOR foi descoberta uma jazida valendo $100
milhões.
(78)
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
Suporte ao médico no processo de diagnose de infecções de hospitalares.
Desenvolvido pela Universidade de Pittsburgh.
(82)
REACTOR
Diagnóstico / conserto de acidentes em reatores
STEAMER
Instrução de operação de máquinas a vapor. Desenvolvido pela Marinha
Americana em colaboração com a BBN Corporation.
(84)
CADHELP
SOPHIE
DIPMETER
Instrução para CAD
Instrução para diagnóstico de falhas em circuitos eletrônicos
Análise geológica de dados para prospecção de petróleo.
Sistemas Especialistas aplicados à Engenharia
Prof. Jonny Carlos da Silva, Dr. Eng.
UNIVERSIDADE FEDERAL DE SANTA CATARINA
15
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
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
Sistemas Especialistas aplicados à Engenharia
Prof. Jonny Carlos da Silva, Dr. Eng.
UNIVERSIDADE FEDERAL DE SANTA CATARINA
16
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
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 devese 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.
Sistemas Especialistas aplicados à Engenharia
Prof. Jonny Carlos da Silva, Dr. Eng.
UNIVERSIDADE FEDERAL DE SANTA CATARINA
17
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
• 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
Sistemas Especialistas aplicados à Engenharia
Prof. Jonny Carlos da Silva, Dr. Eng.
UNIVERSIDADE FEDERAL DE SANTA CATARINA
18
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
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.
Sistemas Especialistas aplicados à Engenharia
Prof. Jonny Carlos da Silva, Dr. Eng.
UNIVERSIDADE FEDERAL DE SANTA CATARINA
19
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
• 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.
Sistemas Especialistas aplicados à Engenharia
Prof. Jonny Carlos da Silva, Dr. Eng.
UNIVERSIDADE FEDERAL DE SANTA CATARINA
20
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
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
Sistemas Especialistas aplicados à Engenharia
Prof. Jonny Carlos da Silva, Dr. Eng.
UNIVERSIDADE FEDERAL DE SANTA CATARINA
21
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
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.
Sistemas Especialistas aplicados à Engenharia
Prof. Jonny Carlos da Silva, Dr. Eng.
UNIVERSIDADE FEDERAL DE SANTA CATARINA
22
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
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ê
Sistemas Especialistas aplicados à Engenharia
Prof. Jonny Carlos da Silva, Dr. Eng.
UNIVERSIDADE FEDERAL DE SANTA CATARINA
23
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
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).
Sistemas Especialistas aplicados à Engenharia
Prof. Jonny Carlos da Silva, Dr. Eng.
UNIVERSIDADE FEDERAL DE SANTA CATARINA
24
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
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.
Sistemas Especialistas aplicados à Engenharia
Prof. Jonny Carlos da Silva, Dr. Eng.
UNIVERSIDADE FEDERAL DE SANTA CATARINA
25
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
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.
Sistemas Especialistas aplicados à Engenharia
Prof. Jonny Carlos da Silva, Dr. Eng.
UNIVERSIDADE FEDERAL DE SANTA CATARINA
26
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
7.
Definição Do Domínio De Aplicação E Identificação Das Fontes De
Conhecimento
Tarefa
Objetivo
Identificação da Quem e quais são as fontes de conhecimento, sem considerar
fonte
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
Representação
Objetivo
Especificar como o conhecimento será representado, isto dependerá
e implicará na seleção da ferramenta de desenvolvimento
Estrutura de controle Definir como as regras terão interação entre si, partição da agenda
no sistema
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 Especificar o projeto da interface e obter o mais rápido possível um
interface
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
Sistemas Especialistas aplicados à Engenharia
Prof. Jonny Carlos da Silva, Dr. Eng.
UNIVERSIDADE FEDERAL DE SANTA CATARINA
27
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
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?
Sistemas Especialistas aplicados à Engenharia
Prof. Jonny Carlos da Silva, Dr. Eng.
UNIVERSIDADE FEDERAL DE SANTA CATARINA
28
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
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.
Sistemas Especialistas aplicados à Engenharia
Prof. Jonny Carlos da Silva, Dr. Eng.
UNIVERSIDADE FEDERAL DE SANTA CATARINA
29
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
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:
Sistemas Especialistas aplicados à Engenharia
Prof. Jonny Carlos da Silva, Dr. Eng.
UNIVERSIDADE FEDERAL DE SANTA CATARINA
30
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
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.
Sistemas Especialistas aplicados à Engenharia
Prof. Jonny Carlos da Silva, Dr. Eng.
UNIVERSIDADE FEDERAL DE SANTA CATARINA
31
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
• 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.
Sistemas Especialistas aplicados à Engenharia
Prof. Jonny Carlos da Silva, Dr. Eng.
UNIVERSIDADE FEDERAL DE SANTA CATARINA
32
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
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.
Sistemas Especialistas aplicados à Engenharia
Prof. Jonny Carlos da Silva, Dr. Eng.
UNIVERSIDADE FEDERAL DE SANTA CATARINA
33
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
• 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.
Sistemas Especialistas aplicados à Engenharia
Prof. Jonny Carlos da Silva, Dr. Eng.
UNIVERSIDADE FEDERAL DE SANTA CATARINA
34
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
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;
Sistemas Especialistas aplicados à Engenharia
Prof. Jonny Carlos da Silva, Dr. Eng.
UNIVERSIDADE FEDERAL DE SANTA CATARINA
35
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
• 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.
Sistemas Especialistas aplicados à Engenharia
Prof. Jonny Carlos da Silva, Dr. Eng.
UNIVERSIDADE FEDERAL DE SANTA CATARINA
36
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
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,
Sistemas Especialistas aplicados à Engenharia
Prof. Jonny Carlos da Silva, Dr. Eng.
UNIVERSIDADE FEDERAL DE SANTA CATARINA
37
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
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.
Sistemas Especialistas aplicados à Engenharia
Prof. Jonny Carlos da Silva, Dr. Eng.
UNIVERSIDADE FEDERAL DE SANTA CATARINA
38
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
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.
Sistemas Especialistas aplicados à Engenharia
Prof. Jonny Carlos da Silva, Dr. Eng.
UNIVERSIDADE FEDERAL DE SANTA CATARINA
39
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
• 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.
Sistemas Especialistas aplicados à Engenharia
Prof. Jonny Carlos da Silva, Dr. Eng.
UNIVERSIDADE FEDERAL DE SANTA CATARINA
40
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
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.
Sistemas Especialistas aplicados à Engenharia
Prof. Jonny Carlos da Silva, Dr. Eng.
UNIVERSIDADE FEDERAL DE SANTA CATARINA
41
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
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.
Sistemas Especialistas aplicados à Engenharia
Prof. Jonny Carlos da Silva, Dr. Eng.
UNIVERSIDADE FEDERAL DE SANTA CATARINA
42
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
12. Organização Do Conhecimento
Uma técnica de organização do conhecimento bastante utilizada é conhecida como saídaentrada-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.
Sistemas Especialistas aplicados à Engenharia
Prof. Jonny Carlos da Silva, Dr. Eng.
UNIVERSIDADE FEDERAL DE SANTA CATARINA
43
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
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
Sistemas Especialistas aplicados à Engenharia
Prof. Jonny Carlos da Silva, Dr. Eng.
UNIVERSIDADE FEDERAL DE SANTA CATARINA
44
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
• 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.
Sistemas Especialistas aplicados à Engenharia
Prof. Jonny Carlos da Silva, Dr. Eng.
UNIVERSIDADE FEDERAL DE SANTA CATARINA
45
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
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.
Sistemas Especialistas aplicados à Engenharia
Prof. Jonny Carlos da Silva, Dr. Eng.
UNIVERSIDADE FEDERAL DE SANTA CATARINA
46
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
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
Sistemas Especialistas aplicados à Engenharia
Prof. Jonny Carlos da Silva, Dr. Eng.
UNIVERSIDADE FEDERAL DE SANTA CATARINA
47
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
• 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.
Sistemas Especialistas aplicados à Engenharia
Prof. Jonny Carlos da Silva, Dr. Eng.
UNIVERSIDADE FEDERAL DE SANTA CATARINA
48
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
• 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
Sistemas Especialistas aplicados à Engenharia
Prof. Jonny Carlos da Silva, Dr. Eng.
UNIVERSIDADE FEDERAL DE SANTA CATARINA
49
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
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.
Sistemas Especialistas aplicados à Engenharia
Prof. Jonny Carlos da Silva, Dr. Eng.
UNIVERSIDADE FEDERAL DE SANTA CATARINA
50
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
• 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
Sistemas Especialistas aplicados à Engenharia
Prof. Jonny Carlos da Silva, Dr. Eng.
UNIVERSIDADE FEDERAL DE SANTA CATARINA
51
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
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.
Sistemas Especialistas aplicados à Engenharia
Prof. Jonny Carlos da Silva, Dr. Eng.
UNIVERSIDADE FEDERAL DE SANTA CATARINA
52
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
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.
Sistemas Especialistas aplicados à Engenharia
Prof. Jonny Carlos da Silva, Dr. Eng.
UNIVERSIDADE FEDERAL DE SANTA CATARINA
53
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
É 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.
Sistemas Especialistas aplicados à Engenharia
Prof. Jonny Carlos da Silva, Dr. Eng.
UNIVERSIDADE FEDERAL DE SANTA CATARINA
54
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
• 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"
Sistemas Especialistas aplicados à Engenharia
Prof. Jonny Carlos da Silva, Dr. Eng.
UNIVERSIDADE FEDERAL DE SANTA CATARINA
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
• 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 viceversa (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
?x2:nome)
(printout t "estas pessoas tem a mesma idade" ?x1:nome e
)
)
Sistemas Especialistas aplicados à Engenharia
Prof. Jonny Carlos da Silva, Dr. Eng.
55
UNIVERSIDADE FEDERAL DE SANTA CATARINA
56
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
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.
Sistemas Especialistas aplicados à Engenharia
Prof. Jonny Carlos da Silva, Dr. Eng.
UNIVERSIDADE FEDERAL DE SANTA CATARINA
57
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
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 ) =
p( E | H ) * p ( H )
p( E )
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:
Sistemas Especialistas aplicados à Engenharia
Prof. Jonny Carlos da Silva, Dr. Eng.
UNIVERSIDADE FEDERAL DE SANTA CATARINA
58
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
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)
p( E ) = p ( E | H ) * p ( H ) + p ( E |~ H ) * p (~ H )
p( E ) = (0.75) * (0.2) + (0.2) * (0.8) = 0.31
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( E | H ) * p ( H )
p( E )
P(H|E) =(0.75)*(0.2)/(0.31)= 0.48387
p( H | E ) =
Calcular a probabilidade do paciente estar resfriado considerando que ele não esteja
espirrando.
p( H |~ E ) =
p (~ E | H ) * p ( H ) (1 − 0.75) * (0.2)
=
= 0.07246
p (~ E )
(1 − 0.31)
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.
Sistemas Especialistas aplicados à Engenharia
Prof. Jonny Carlos da Silva, Dr. Eng.
UNIVERSIDADE FEDERAL DE SANTA CATARINA
59
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
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:
p( H i | E1 E 2 ... E n ) =
p ( E1 E 2 ... E n | H i ) * p ( H i )
p ( E1 E 2 ... E n )
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
i=2
i=3
(resfriado)
(alergia)
(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)
Sistemas Especialistas aplicados à Engenharia
Prof. Jonny Carlos da Silva, Dr. Eng.
UNIVERSIDADE FEDERAL DE SANTA CATARINA
60
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
p( H 1 | E1 ) =
p ( E1 | H 1 ) * p ( H 1 )
0 .3 * 0 .6
=
= 0 .4
∑ p( E1 | H i ) * p( H i ) 0.3 * 0.6 + 0.8 * 0.3 + 0.3 * 0.1
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.
Sistemas Especialistas aplicados à Engenharia
Prof. Jonny Carlos da Silva, Dr. Eng.
UNIVERSIDADE FEDERAL DE SANTA CATARINA
61
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
• 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.
Sistemas Especialistas aplicados à Engenharia
Prof. Jonny Carlos da Silva, Dr. Eng.
UNIVERSIDADE FEDERAL DE SANTA CATARINA
62
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
• 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:
Sistemas Especialistas aplicados à Engenharia
Prof. Jonny Carlos da Silva, Dr. Eng.
UNIVERSIDADE FEDERAL DE SANTA CATARINA
63
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
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
" mais..ou..menos"± A =
=(1- 2(1-A)2)
A
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.
Sistemas Especialistas aplicados à Engenharia
Prof. Jonny Carlos da Silva, Dr. Eng.