Engenharia de Conhecimento Fred Freitas CIn - UFPE Fred Freitas - fred@cin.ufpe.br

Fred Freitas - fred@cin.ufpe.br Como construir SBCs?? Sabemos como funcionam Regras de produção ou programação em lógica ... O que possuem Motor de inferência Mas não sabemos de métodos para Adquirir o conhecimento Do domínio => como construir ontologias Das tarefas => como construir uma boa base de regras Item importante Reuso => em especial para ontologias Fred Freitas - fred@cin.ufpe.br

Etapas da Engenharia do Conhecimento Nível de Conhecimento AQUISIÇÃO linguagem natural linguagem de representação de conhecimento FORMALIZAÇÃO Nível Lógico Nível de Implementação linguagens de programação IMPLEMENTAÇÃO BC REFINAMENTO Fred Freitas - fred@cin.ufpe.br

Aquisição de Conhecimento Fred Freitas - fred@cin.ufpe.br

Ciclo de Desenvolvimento de um Sistema Especialista Inicialização Fechamento da Base de Conhecimento e dos módulos, Testes, Avaliação Análise Definição do Problema, Requisitos Aquisição de Conhecimento, o Gargalo! Prototipagem Validação pelos usuários, Treinamento, Documentação Projeto, Identificação das fontes de conhecimento Desenvolvi- mento Operação, Upgrades, Avaliação periodica Implemen- tação Definição e Representação do Conhecimento, Protótipos, Módulos, Interface, Testes Manutenção Fred Freitas - fred@cin.ufpe.br

Soluções para os Problemas de Aquisição Métodos de aquisição Manuais Semi-automáticos Automáticos Sistemas Especialistas de 2ª. geração Fred Freitas - fred@cin.ufpe.br

Métodos Manuais de Aquisição especialista Base de conhecimento Engenheiro de documentação codificação explicitação Entrevistas Desestruturada Estruturada: agendas, formulários, casos, etc Rastreamento cognitivo Gravações de descrições detalhadas do especialista Engenheiro faz regras e valida com o especialista Fred Freitas - fred@cin.ufpe.br

Fred Freitas - fred@cin.ufpe.br Entrevistas método de aquisição de conhecimento mais usado informação e o conhecimento são recolhidos através de diversos meios questionários, anotações, gravações posteriormente transcritos, analisados e codificados normalmente são necessárias várias entrevistas ou sessões de trabalho o espaçamento entre as entrevistas deverá permitir: que o Engenheiro do Conhecimento possa processar todo o conhecimento adquirido na entrevista anterior que o conhecimento adquirido seja representado, codificado e testado por um protótipo do sistema Fred Freitas - fred@cin.ufpe.br

Entrevistas Desestruturadas Pode-se estabelecer uma relação professor/aluno entre o Especialista e o Engenheiro de Conhecimento. O Especialista : faz o acompanhamento de casos explica o que faz e porque o faz explicita conceitos, habilidades e estratégias que usa aconselha a leitura de documentos, bibliografia Freqüentemente as descrições dos processos cognitivos do perito parecem incompletas ou desorganizadas complexidade do domínio faltam os relacionamentos dos diversos itens de informação e conhecimento falta de treino dos Engenheiros do Conhecimento na condução das entrevistas Fred Freitas - fred@cin.ufpe.br

Entrevistas Estruturadas processo sistemático orientado a objetivos a comunicação entre o Engenheiro do Conhecimento e o especialista é previamente organizada o Engenheiro do Conhecimento prepara as sessões de aquisição do conhecimento identificando as questões mais relevantes uso de formulários, documentos, atas, protocolos, ... Fred Freitas - fred@cin.ufpe.br

Aquisição de Conhecimento usando Acompanhamento do Raciocínio técnica popular na Psicologia Cognitiva na qual se tenta rastrear o raciocínio do especialista concluir como ele raciocina os métodos podem ser mais ou menos formais Análise do Protocolo - método formal mais conhecido o especialista é solicitado a resolver problemas concretos e a verbalizar o raciocínio que utiliza na resolução desse problema fica registado o o processo de tomada de decisão efetuado pelo especialista passo-a-passo pode ser efetuada a gravação da sessão processo essencialmente unilateral, ao contrário das entrevistas Fred Freitas - fred@cin.ufpe.br

Aquisição de Conhecimento com observação do especialista modo mais natural de efetuar a aquisição pode ser complexo O especialista pode dirigir uma equipe de várias pessoas O especialista pode resolver vários problemas simultaneamente  Comportamento do especialista pode ser diferente pelo fato de saber que está sendo observado o conhecimento que se adquire pode não corresponder exatamente Fred Freitas - fred@cin.ufpe.br

Aquisição de Conhecimento guiada pelo especialista os Engenheiros do Conhecimento costumam não cobrir bem o conhecimento do domínio podem surgir problemas na comunicação com o perito aquisição de conhecimento pode ser um processo demorado, com várias iterações Os especialistas podem agir também como Engenheiros, codificando diretamente o seu conhecimento Manualmente: através de relatórios e questionários Automaticamente: através de uma ferramenta computacional que ajuda o perito a introduzir o conhecimento e procura detectar falhas nesse mesmo conhecimento (incoerências, ambiguidades, redundâncias, etc). Fred Freitas - fred@cin.ufpe.br

Métodos Semi-automáticos de Aquisição especialista Ferramentas de apoio Base de conhecimento Engenheiro de conhecimento Ferramentas para o engenheiro Editores, ambientes integrados (ex: Protégé), ferramentas visuais Ferramentas para o especialista Análise de grades de características (repertory grid analysis) Fred Freitas - fred@cin.ufpe.br

Métodos Automáticos de Aquisição Casos e exemplos Indução automática Regras Técnicas de Aprendizado Automático É preciso gerar conhecimento explícito, muitas vezes em forma de regras! Por isso... Técnicas simbólicas de aprendizado Árvores de Decisão Espaço de Versões, ... Fred Freitas - fred@cin.ufpe.br

Engenharia de ontologias Fred Freitas - fred@cin.ufpe.br

Princípios de construção Clareza Legibilidade Coerência Extensibilidade Mínima codificação Mínimo compromisso ontológico Clareza-definir apenas o que se presume ser útil na resolução da classe de problemas a ser atingida. Definições completas, com condições necessárias e suficientes, devem ter precedência sobre definições parciais. Legibilidade: correspondência com as definições correntes e informais. jargão e terminologia Coeencia-As inferências derivadas da ontologia devem ser corretas Mínima codificação: Devem ser especificados conceitos genéricos independente de padrões estabelecidos para mensuração, notação e codificação, garantindo a extensibilidade. Essa genericidade é limitada pela clareza. Esta característica se contrapõe à programação imperativa orientada a objetos, porque, por exemplo, atributos de objetos trazem tipos básicos e informações sobre a implementação. Mínimo compromisso ontológico: Para maximizar o reuso, apenas o conhecimento essencial deve ser incluído, permitindo a criação de conceitos novos, mais especializados. Fred Freitas - fred@cin.ufpe.br

Fred Freitas - fred@cin.ufpe.br Ontologia Ciência Reusada a partir da ontologia do projeto europeu (KA)2 [Benjamins et al 98] do espelho da Ontolingua na Universidade de Madri Refinada em granularidade e engajamento ontológico Inclui ontologias auxiliares de tempo, locais e turismo [Freitas 2001] auxiliares de tempo, locais e turismo, esta última englobando definições de moedas correntes de país, tipos de acomodações, etc, enfim, definições úteis para a extração de atruibutos da classe Evento ao Vivo. Reusada por analistas da Mercedes-Benz de Stuttgart, Alemanha Fred Freitas - fred@cin.ufpe.br

Fred Freitas - fred@cin.ufpe.br Princípios usados Clareza e legibilidade – Jargão empregado Mínimo compromisso ontológico – na classe Documento Científico, não há restrições desnecessárias para o slot Autores (qualquer subclasse da classe Pessoa inclusive a subclasse Pesquisador) Extensibilidade - novas classes puderam ser definidas a partir das já existentes Coerência - a relação parte-todo entre artigos de um proceedings, ou entre capítulos de um livro, não estava explicitada a definição da classe Documento Científico, apresentada na figura 9. Pode-se perceber que não há restrições desnecessárias na definição do atributo Autores. Poder-se-ia especificar que subclasse da classe Pessoa pode ser autor de artigos, como, por exemplo, a subclasse Pesquisador. Porém, especificou-se exclusivamente o conhecimento do conceito sem definir prematuramente certas decisões Fred Freitas - fred@cin.ufpe.br

O uso e a engenharia de ontologias estão atrelados... Knowledge Meta-process Design, Implementation, Evolution of the Ontology Knowledge Process Use of the Ontology Fred Freitas - fred@cin.ufpe.br

Metaprocesso de construção Reverse Use Ont-O-Mat Portals & Portal Generation Crawling / Syndication Create Navigation Context Concepts Attributes, Rules Semantic - Syntactic Bridge Context Rules Common Language Import Ontobroker Semantic Miner Find Capture Ont-O-Mat Organize Fred Freitas - fred@cin.ufpe.br

Metodologias de desenvolvimento [Gómez-Perez 99] Processo iterativo, com revisões constantes Nas metodologias propostas, são considerados passos similares aos de engenharia de software: Especificação Conceitualização Implementação Atividades de suporte são executadas concomitantemente com o desenvolvimento Aquisição Avaliação Documentação Integração com ontologias existentes Atividades de suporte (corrigir) – que verifica se a ontologia atende aos requisitos e propósitos planejados -, Fred Freitas - fred@cin.ufpe.br

Metodologias de desenvolvimento (cont.) Fred Freitas - fred@cin.ufpe.br

Fred Freitas - fred@cin.ufpe.br Especificação Determina o propósito e escopo da ontologia Deve incluir uma análise para decidir se é possível, necessário ou adequado o reuso de ontologias Sugere-se elaborar uma lista de questões de competência [Uschold & Gruninger 96] Servirão para a avaliação da ontologia durante o desenvolvimento Ex: “Jornais científicos são considerados eventos científicos?” A onto precisa dar condicoes ao sist/agente de responder as questoes Fred Freitas - fred@cin.ufpe.br

Fred Freitas - fred@cin.ufpe.br Conceitualização [Noy 97] Fase crítica, nela ocorrem a maior parte das atividades de suporte de aquisição e avaliação Passos e dicas: Enumerar os termos do domínio Definir as classes - não confundir nomes de um conceito com o próprio conceito Definir a hierarquia das classes - passo capcioso Definir os slots e facetas de cada classe, interagindo com os dois passos anteriores Criar as instâncias - Se elas não possuem uma hierarquia natural, é preciso revisar a hierarquia das classes Usar convenções de nomes e nomes facilmente compreensíveis Enumerar os termos do domínio, sem preocupar-se com similaridade, repetições e relações entre ele. Costuma-se usar o processo de brainstorming para este fim. Definir as classes. É preciso não confundir nomes de um conceito com o próprio, inclusive existem sistemas que permitem a inclusão de sinônimos e termos associados a conceitos de uma ontologia. Definir a hierarquia das classes. Ocorrendo junto com a anterior, esse constitui o passo mais capcioso do desenvolvimento, devido às sutilezas das hierarquias os novos atributos ou facetas que definem uma classe, exceto em classes terminológicas, como, por exemplo, em medicina. Criar as instâncias, tendo como lema que são os conceitos mais específicos de uma ontologia, ou seja, os elementos separados por menor granularidade Fred Freitas - fred@cin.ufpe.br

Fred Freitas - fred@cin.ufpe.br Especificação Fred Freitas - fred@cin.ufpe.br © York Sure

Fontes de Conhecimento Fred Freitas - fred@cin.ufpe.br © York Sure

Questões de Competência Fred Freitas - fred@cin.ufpe.br © York Sure

Fred Freitas - fred@cin.ufpe.br Rastreamento Fred Freitas - fred@cin.ufpe.br © York Sure

Definir a hierarquia das classes Observar a clareza e consistência da hierarquia Evitar subclasses demais pelo uso de classes intermediárias Ver se não há poucas subclasses - a informação dos slots pode tornar-se insuficiente para refletir diferenças entre as instâncias. Abordagens para a definição de hierarquias [Uschold & Gruninger 96]: top-down, classes mais gerais e depois as específicas bottom-up middle-out, que começa por classes intermediárias que vão sendo especializadas (para baixo) e generalizadas (para cima) Fred Freitas - fred@cin.ufpe.br

Definir os slots e facetas Slots intrínsecos – ex: número de pernas Slots extrínsecos – ex: nome de uma pessoa Partes de uma classe – ex: partes do corpo: cabeça, tronco e membros Relacionamentos - instâncias de outras classes. Especificar a classe mais geral possível EX: a faceta classes-permitidas do slot Participantes da classe Projeto são instâncias da classe Pesquisadores Pesquisadores incluem estudantes de pós-graduação, professores, etc Partes é importante para a inferencia Pariticipantes - errata Fred Freitas - fred@cin.ufpe.br

Implementação e Avaliação Objetivo: transformar a ontologia em algo computável Na fase de implementação, a ontologia é escrita numa linguagem de representação de conhecimento Na fase de avaliação, são executados testes para verificar se a ontologia atende aos requisitos especificados na fase de especificação Testes freqüentemente provocam mudanças na implementação Fred Freitas - fred@cin.ufpe.br

Fred Freitas - fred@cin.ufpe.br Ontology Engineering: OTK Methodology (EU Project: On-To-Knowledge) [Studer & Volz 2003] Applications Fred Freitas - fred@cin.ufpe.br

Fred Freitas - fred@cin.ufpe.br Tool Support for Methodology OntoEdit KAON Ontology Evolution Applications OntoMat-Annotizer Fred Freitas - fred@cin.ufpe.br

Ontology Evolution Process How to discover a change? How to resolve a change? How to ensure the consistency? Discovery Validation Semantics of change Representation Implementation Semantics of change Propagation Representation Implementation Core component Refinement requirement Functional & Guidance requirement Refinement requirement Fred Freitas - fred@cin.ufpe.br

Fred Freitas - fred@cin.ufpe.br Evolution Strategies An evolution strategy unambiguously defines the way how changes will be resolved Semantics of change Required change Required and derived changes Evolution strategy X reconnect to the parent to the root delete Fred Freitas - fred@cin.ufpe.br

Revendo os passos rapidamente... Fred Freitas - fred@cin.ufpe.br

Engenharia de Conhecimento 1) Decida sobre o que falar 2) Escolha o vocabulário de predicados, funções e constantes (Ontologia do Domínio) 3) Codifique o conhecimento genérico sobre o domínio (axiomas) " x,y,z Americano(x) Ù Arma(y) Ù Nação(z) Ù Hostil(z) Ù Vende(x,z,y) Þ Criminoso(x) 4) Codifique uma descrição de uma instância específica do problema Nação(Cuba), Nação(USA), Vende(West,Arma1,Cuba) 5) Proponha questões para o procedimento de inferência e obtenha respostas ou decisões West é criminoso? Fred Freitas - fred@cin.ufpe.br

Um Exemplo: Circuitos Digitais Estabelecer o objetivo: determinar se o circuito está de acordo com sua especificação (o circuito acima é um somador) responder a perguntas sobre o valor da corrente em qualquer ponto do circuito Fred Freitas - fred@cin.ufpe.br

Decida sobre o que falar Para alcançar o objetivo, é relevante falar sobre circuitos, terminais, sinais nos terminais, conexões entre terminais Para determinar quais serão esses sinais, precisamos saber sobre: portas e tipos de portas: AND, OR, XOR e NOT Não é relevante falar sobre: fios, caminhos dos fios, cor e tamanho dos fios, etc Tudo isso tem de estar na ontologia! Fred Freitas - fred@cin.ufpe.br

Decida qual vocabulário usar Nomear os objetos e relações do domínio com funções, predicados e constantes constantes distinguir as portas : X1, X2... distinguir os tipos de porta: AND, OR, XOR... funções e predicados tipo de uma porta: Tipo(X1) = XOR, Tipo(X1, XOR), XOR(X1) indicar entradas e saídas: Out(1, X1), In(1, X2) indicar conectividade entre portas: Conectado(Out(1, X1), In(1, X2)) Fred Freitas - fred@cin.ufpe.br

Codifique regras genéricas (1) Dois terminais conectados têm o mesmo sinal: " t1, t2 Conectado(t1, t2) Þ Sinal(t1) = Sinal(t2) (2) O sinal de um terminal é On ou Off (nunca ambos) " t Sinal(t) = On Ú Sinal(t) = Off, On ¹ Off (3) Conectado é um predicado comutativo " t1,t 2 Conectado(t1, t2) Û Conectado(t2, t1) (4) Uma porta OR está On sse qualquer das suas entradas está On: " g Tipo(g) = OR Þ Sinal(Out(1,g)) = On Û $ n Sinal(In(n,g))=On (5) etc... Fred Freitas - fred@cin.ufpe.br

Codifique a instância específica Portas: Tipo(X1) = XOR Tipo(X2) = XOR Tipo(A1) = AND Tipo(A2) = AND Tipo(O1) = OR Conexões: Conectado(Out(1,X1),In(1,X2)) Conectado(Out(1,X1),In(2,A2)) Conectado(Out(1,A2),In(1,O1)) . . . Fred Freitas - fred@cin.ufpe.br

Proponha questões ao Procedimento de Inferência Que entradas causam Out(1,C1) = Off e Out(2, C1) = On? $ i1, i2, i3, o1, o2 Sinal(In(1,C1)) = i1 Ù Sinal(In(2,C1)) = i2 Ù Sinal(In(3,C1)) = i3 Ù Sinal(Out(1,C1)) = o1 Ù Sinal(Out(2,C1) = o2. Resposta: (i1 = On Ù i2 = On Ù i3 = Off) Ú (i1 = On Ù i2 = Off Ù i3 = On) Ú (i1 = Off Ù i2 = On Ù i3 = On) Fred Freitas - fred@cin.ufpe.br

Proponha questões ao Procedimento de Inferência Quais são os conjuntos de valores possíveis para todos os terminais do circuito? $ i1, i2, i3 Sinal(In(1,C1)) = i1 Ù Sinal(In(2,C1)) = i2 Ù Sinal(In(3,C1)) = i3 Ù Sinal(Out(1,C1)) = Off Ù Sinal(Out(2,C1) = On Resposta é o objetivo do agente! Fred Freitas - fred@cin.ufpe.br