Inteligência Artificial

Transcrição

1 Inteligência Artificial Apontamentos para as aulas Luís Miguel Botelho Departamento de Ciências e Tecnologias da Informação Instituto Superior de Ciências do Trabalho e da Empresa Julho de

2 Sistemas Baseados em Regras Índice 1 REGRAS CONDIÇÃO-CONCLUSÃO RACIOCÍNIO DEDUTIVO ENCADEADO PARA A FRENTE 5 Novos factos 5 Raciocínio RACIOCÍNIO DEDUTIVO ENCADEADO PARA TRÁS 5 2 REGRAS CONDIÇÃO-AÇÃO (REGRAS DE PRODUÇÃO) RESOLUÇÃO DE CONFLITOS 8 3 GERAÇÃO AUTOMÁTICA DE EXPLICAÇÕES SISTEMA PARA AVALIAÇÃO DE PEDIDOS DE FINANCIAMENTO GERAÇÃO AUTOMÁTICA DE EXPLICAÇÕES 12 Explicações Why 12 Explicações How 13 4 VALIDAÇÃO DA BASE DE CONHECIMENTOS VERIFICAÇÃO DE CONSISTÊNCIA BASE DE CONHECIMENTOS NÃO COMPLETA 16 5 IMPLEMENTAÇÃO EM PROLOG DE MECANISMOS DE REPRESENTAÇÃO E RACIOCÍNIO META-INTERPRETADORES (PROLOG EM PROLOG) EXPLICAÇÕES WHY EXPLICAÇÕES HOW VALIDAÇÃO DA BASE DE CONHECIMENTOS Incompletude da Base de Conhecimentos Inconsistência da Base de Conhecimentos IMPLEMENTAÇÃO DE UM SISTEMA DE REGRAS DE PRODUÇÃO 28 6 REFERÊNCIAS 31 2

3 Sistemas Baseados em Regras As regras SE ENTÃO são as estruturas mais usadas para representar conhecimento em sistemas baseados em conhecimento, sobretudo em sistemas periciais ( expert systems ). Existem dois tipos de regras: as regras condição-conclusão e as regras condição-ação (mais vulgarmente chamadas regras de produção). Em ambos os casos, as regras podem ser descritas através de estruturas com o formato IF LHS THEN RHS, em que LHS significa o lado esquerdo da regra ( left hand side ) e RHS significa o lado direito da regra ( right hand side ). O raciocínio usado com este método de representação de conhecimento pode ser encadeado para trás (no caso das regras condição-conclusão) ou encadeado para a frente (tanto nas regras condição-conclusão como nas regras condição-ação). 3

4 1 Regras condição-conclusão As regras condição-conclusão são regras que especificam a conclusão que pode ser gerada quando uma determinada condição é verdadeira. Dito de outra forma, uma regra condição-conclusão diz que a conclusão é verdade quando a condição é verdade. Em geral, uma regra condição-conclusão representa-se através de uma estrutura de representação com o formato IF condição THEN conclusão. Também é relativamente vulgar deparar-se com a notação condição conclusão. Esta última notação realça a semelhança que existe entre a representação baseada em regras e a representação baseada em lógica. Na maioria dos sistemas de representação baseados em regras, a condição pode ser uma condição atómica ou uma condição composta através das conectivas lógicas not, and e or, enquanto que a conclusão é, em geral, uma proposição atómica. Para exemplificar a utilização de regras condição-conclusão, considere-se o caso em que uma pessoa ou uma empresa pretendem escolher o sistema operativo a instalar nos seus computadores. Para isso, poderão recorrer a um conjunto de regras simples como as apresentadas na Figura 1. Regra 1 SE o ambiente de utilização é um ambiente empresarial; e é necessário usar software aplicativo da Microsoft ENTÃO o sistema operativo selecionado é o Windows NT Regra 2 SE o ambiente de utilização é um ambiente particular; e é necessário usar software aplicativo da Microsoft ENTÃO o sistema operativo selecionado é o Windows98 Regra 3 SE o sistema operativo selecionado é o Windows NT; e é necessário disponibilizar serviços a vários clientes ENTÃO a versão do sistema operativo é Windows NT Server Regra 4 SE é necessário usar Excel ENTÃO é necessário usar software aplicativo da Microsoft Regra 5 SE é necessário usar Access ENTÃO é necessário usar software aplicativo da Microsoft Figura 1 - Regras condição-conclusão para escolha de um sistema operativo As regras exibidas na Figura 1 poderão integrar a base de conhecimentos de um sistema pericial. Para utilizar as regras para responder a perguntas ou para reagir à introdução de nova informação, o sistema tem que efetuar raciocínio. Em geral, o tipo de raciocínio mais usado com este método de representação é o raciocínio dedutivo, isto é, o raciocínio em que se usam as regras de inferência da dedução (e.g., o modus ponens, o modus tolens, a introdução e eliminação da conjunção e da disjunção, ver capítulo Error! Reference source not 4

5 found.). No entanto, também seria possível usar regras condição-conclusão através de outros tipos de raciocínio, entre os quais a abdução (ver capítulo Error! Reference source not found.) e uma forma muito particular de raciocínio não monótono conhecida pela hipótese do mundo fechado (CWA, Closed world assumption, capítulo Error! Reference source not found.). Qualquer destes tipos de raciocínio pode ser encadeado para trás ou encadeado para a frente. Em certas ferramentas computacionais usadas para representar conhecimento através de regras utiliza-se um encadeamento misto. 1.1 Raciocínio dedutivo encadeado para a frente As regras condição-conclusão da Figura 1 podem ser usadas por um mecanismo de inferência com encadeamento para a frente ( forward reasoning, ou forward chaining ) também conhecido por encadeamento guiado pelos dados ( data-driven ). Neste modo de utilização, o raciocínio é desencadeado por dados geralmente introduzidos pelo utilizador (ou por outro programa) ou por resultados produzidos pelo próprio sistema. O sistema determina as regras com as condições satisfeitas e produz as conclusões especificadas. As conclusões produzidas juntamente com os factos previamente existentes são, de novo, comparadas com as condições das regras e o processo é repetido. A figura mostra uma interação do sistema em que a introdução de nova informação despoleta um raciocínio. Novos factos Raciocínio Utilizador: é necessário disponibilizar serviços a vários clientes Utilizador: é necessário usar o Access Sistema: é necessário usar software aplicativo da Microsoft Regra 5 Utilizador: o ambiente de utilização é um ambiente empresarial Sistema: o sistema operativo selecionado é o Windows NT Regra 1 Sistema: a versão do sistema operativo é Windows NT Server Regra 3 Figura 2 - Interação guiada pelos dados (Raciocínio encadeado para a frente) Na interação, assume-se que todos os novos factos são memorizados pelo sistema na sua memória de trabalho. No primeiro passo da interação, o utilizador informa o sistema que é necessário disponibilizar serviços a vários clientes. Este novo facto memorizado pelo sistema é usado para verificar se há regras com a condição satisfeita. Nesta altura, nenhuma regra fica com as condições totalmente satisfeitas. Apenas uma parte da condição da regra 3 fica satisfeita, mas não toda a condição. No segundo passo da interação, o utilizador informa o sistema que é necessário usar o MS-Access. Este facto é memorizado e o sistema determina se a condição de alguma das suas regras fica satisfeita. A condição da regra 5 fica completamente satisfeita dando origem à geração da conclusão especificada, i.e., o sistema produz o novo facto é necessário usar software aplicativo da Microsoft que é memorizado. Dado que existe um novo facto, o sistema volta a verificar a satisfação das condições das regras. Tanto a regra 1 como a regra 5 têm a condição satisfeita. Desta vez, a regra 5 não é usada porque nenhuma regra pode ser usada duas vezes com a mesma informação. Aplicando a regra 1, o sistema produz o novo facto o sistema operativo selecionado é o Windows NT. Dado que existe um novo facto, as regras são de novo verificadas. As regras 1 e 5 têm a condição satisfeita mas não são usadas porque as regras não podem ser usadas mais do que uma vez com a mesma informação. Mas a condição da regra 3 fica agora totalmente satisfeita, pelo que a conclusão especificada é produzida, gerando o novo facto a versão do sistema operativo é Windows NT Server que é igualmente memorizado. Agora nenhuma regra está em condições de poder ser aplicada. 1.2 Raciocínio dedutivo encadeado para trás As regras da Figura 1 podem ser usadas de forma diferente da usada na interação descrita na secção 1.1. Em vez de introduzir informação de forma voluntária, o utilizador poderá fazer perguntas ao sistema. Para responder, o sistema percorre toda a sua base de conhecimentos procurando um facto ou uma regra cujo lado direito (i.e., conclusão) emparelhe com a pergunta do utilizador. Quando uma regra adequada é 5

6 encontrada, o sistema verifica se a condição é verdadeira. Para isso, volta a procurar regras (ou factos) e o processo repete-se. Supondo que o utilizador pergunta se P é verdade, o sistema vai procurar o facto P na sua base de conhecimentos ou uma regra com o formato SE condição ENTÃO P. Tendo encontrado esta regra, o sistema só pode responder afirmativamente se a condição for verdadeira. Supondo que a condição tem a forma A B, o sistema tem que verificar se A é verdade e se B também é verdade. Para isso procura os factos A e B na sua base de conhecimentos ou regras que permitam concluir A e B. Para isso, o processo repete-se. A este método de encadeamento das regras chama-se encadeamento para trás ( backward chaining, backward reasoning ) ou raciocínio guiado pelos objetivos ( goal-driven ) porque é aquilo que se pretende provar que guia a seleção de regras na base de conhecimentos. Vejamos agora o que acontece quando o utilizador pretende saber que sistema operativo deve instalar. A Figura 3 (b) representa uma interação entre o utilizador e um sistema com raciocínio encadeado para trás. Assume-se que a base de conhecimentos do sistema é constituída pelas regras apresentadas na Figura 1 e pelos factos representados na Figura 3 (a). (a) Factos É necessário usar o Access O ambiente de utilização é um ambiente empresarial (b) Interação Utilizador: Qual é o sistema operativo selecionado? Sistema: O sistema operativo selecionado é o Windows NT Figura 3 - Interação guiada pelos objetivos Na interação da Figura 3, o utilizador pergunta qual é o Sistema Operativo selecionado (sugerido) pelo sistema. Para responder a esta pergunta, o sistema percorre a sua base de conhecimentos procurando um facto ou uma regra que permitem responder afirmativamente à pergunta do utilizador. Se não encontrar, falha. Neste caso, encontra a Regra 1 cuja conclusão é o sistema operativo selecionado é o Windows NT. Para poder responder afirmativamente ao utilizador, o sistema tem que verificar se a condição da regra está satisfeita. Neste caso, tem que verificar se o ambiente de utilização é um ambiente empresarial e se é necessário usar software aplicativo da Microsoft. Começando pela primeira parte da condição, o sistema tenta encontrar o facto o ambiente de utilização é um ambiente empresarial ou uma regra com esta conclusão. O facto 2 permite-lhe satisfazer esta parte da condição. Agora tem que verificar se é necessário usar software da Microsoft. A conclusão da Regra 4 diz que é necessário usar software Microsoft. Para que o sistema possa usar esta regra, tem que verificar se a sua condição está satisfeita, isto é, tem que verificar se é necessário usar Excel. Dado que não existe qualquer regra nem facto que permitam satisfazer esta condição, a Regra 5 é abandonada. No entanto, a Regra 6 também permite concluir que é necessário usar software aplicativo da Microsoft. Para isso é necessário verificar se é necessário usar Access. O facto 1 satisfaz esta parte da condição. Assim, a condição da Regra 1 ( o ambiente de utilização é um ambiente empresarial; e é necessário usar software aplicativo da Microsoft ) é satisfeita. Emparelhando a conclusão da regra ( o sistema operativo selecionado é o Windows NT ) com a pergunta ( o sistema operativo selecionado é Qual?, obtém-se a instanciação da variável Qual com a expressão Windows NT. É o valor desta variável que é exibido ao utilizador. 6

7 2 Regras condição-ação (regras de produção) As regras usadas nos exemplos anteriores são regras condição-conclusão. Nesta secção apresenta-se um exemplo com regras de produção, isto é, com regras que especificam a execução de ações quando a sua condição se encontra satisfeita. As regras de produção são encadeadas para a frente. No exemplo usado para apresentar este assunto, temos um mundo quadriculado com um vilão e um herói, como se mostra na Figura 4. Figura 4 - O mundo do vilão O vilão ocupa uma quadrícula fixa no mundo (1,2), e o herói vai movimentar-se de acordo com a aplicação de um conjunto de regras de produção apresentadas na Figura 5. O objetivo é controlar o herói desde a sua posição atual (3,3) até à mesma posição do vilão. Quando o herói tiver atingido o vilão, deverá liquidá-lo. As regras são escritas do ponto de vista do herói. Regra 1 Regra 2 Regra 3 Regra 4 Regra 5 SE a posição atual for a mesma que a posição do vilão ENTÃO Liquidar o vilão SE o número da coluna da posição atual for superior ao número da coluna da posição do vilão ENTÃO Dar um passo para a esquerda SE o número da coluna da posição atual for inferior ao número da coluna da posição do vilão ENTÃO Dar um passo para a direita SE o número da linha da posição atual for inferior ao número da linha da posição do vilão ENTÃO Dar um passo para baixo SE o número da linha da posição atual for superior ao número da linha da posição do vilão ENTÃO Dar um passo para cima Figura 5 - Regras de produção As ações possíveis no mundo do vilão são liquidar o vilão e dar um passo para baixo, para cima, para a direita e para a esquerda. Além das regras, um sistema baseado em regras de produção tem que ter um mecanismo de aplicação das regras e a programação das ações. 7

8 Figura 6 - Sequências de ações do herói Na Figura 6 mostra-se a sequência de ações efetuadas pelo herói, de acordo com as regras de produção representadas na Figura 5. No início, as posições do vilão (1,2) e do herói (3,3) são introduzidas. O sistema determina as regras com a condição satisfeita. Tanto a regra 2 como a regra 5 têm a condição satisfeita. Em princípio qualquer delas poderia ser usada. O sistema escolhe a regra 2 (não há razão especial para preferir a regra 2 em relação à regra 5). De acordo com a regra 2, o herói dá um passo para a esquerda, alterando a representação interna do estado atual (a posição do herói passa a ser (3,2). A segunda configuração exibida na Figura 6 representa o resultado desta ação. Devido à alteração na posição do herói, o sistema volta a verificar se alguma regra tem a condição satisfeita. Apenas a regra 5 tem a condição satisfeita pelo que o herói dá um passo para cima ficando na posição (2,2). Devido à nova alteração da posição do herói, o sistema volta a verificar as suas regras. De novo, a regra 5 é a única com a condição satisfeita. Ela é usada porque a satisfação da sua condição foi obtida à custa de novos dados. No passo anterior, as posições do vilão e do herói eram (1,2) e (3,2) respetivamente. Na situação atual, as suas posições são (1,2) e (2,2). A regra 5 especifica que o herói dá um passo para cima. Como resultado desta ação, o herói e o vilão ficam ambos na posição (1,2) (quarto quadro da Figura 6). A alteração da posição do herói conduz o sistema a verificar as condições das suas regras. Desta vez, a regra 1 é a única cuja condição está satisfeita. De acordo com a regra 1, o herói mata o vilão. 1.3 Resolução de conflitos Quando é usado raciocínio encadeado para a frente, pode acontecer que as condições de mais que uma regra fiquem satisfeitas. Nesta eventualidade o sistema tem que escolher a que vai usar porque não poderá usar mais do que uma. De facto, ao executar a ação da primeira regra com a condição satisfeita, o estado do mundo altera-se e, consequentemente, é possível que as regras que tinham a condição satisfeita deixem de a ter. Ao conjunto de regras com a condição satisfeita chama-se conjunto de conflito ( conflict set ). Aos critérios usados pelo sistema para selecionar apenas uma regra do conjunto de conflito chama-se política ou estratégia de resolução de conflitos ( conflict resolution strategy ). Os vários sistemas usam diferentes políticas de resolução de conflitos constituídas por vários critérios, entre os quais os seguintes: 1 Nenhuma regra pode ser usada duas vezes com os mesmos dados 2 Escolhe-se a regra que depende dos dados mais recentes 3 Escolhe-se a regra mais específica (i.e., a regra cuja condição é constituída pelo maior número de subcondições) 8

9 4 Escolhe-se a regra mais importante (neste caso, as regras têm que ser associadas a um fator de importância ou prioridade). 5 Escolhe-se a regra cuja ação seja a mais importante O primeiro critério é bastante útil porque evita que a mesma regra possa continuar a ser usada devido aos mesmos factos. Ainda assim, há muitos sistemas que não implementam esse critério, nas suas políticas de resolução de conflitos. Nesse caso cabe ao programador criar mecanismos que invalidem a utilização repetida da regra. A escolha da regra que depende de factos mais recentes (critério 2) é muito útil em sistemas que devem reagir rapidamente às alterações do mundo em que existem. De facto, se o sistema continuar a reagir a informação mais antiga, negligenciando alterações recentes, pode acontecer que o seu comportamento se torne desatualizado. No entanto, haverá aplicações em que seria preferível reagir a alterações mais antigas. De acordo com o critério 3, quando duas ou mais regras têm a condição satisfeita, escolhe-se a regra mais específica. De facto, se o programador criou regras mais específicas do que outras é porque tinha em menta a sua utilização, sempre que as circunstâncias o permitissem. Os critérios 4 e 5 permitiriam ao programador atribuir graus de importância (ou de prioridade) às regras ou mesmo às ações. Desta forma, se duas regras tiverem a condição satisfeita, seria natural que o sistema escolhesse aquela com maior importância ou aquela cujas ações fossem mais importantes. Infelizmente, este critério tem sido muito criticado porque as importâncias de regras e de ações pode variar, de acordo com as circunstâncias. 9

10 3 Geração automática de explicações Este capítulo centra-se na descrição de funcionalidades desejáveis dos sistemas baseados em conhecimento e das ferramentas computacionais usadas para o seu desenvolvimento. Entre as funcionalidades dos sistemas baseados em conhecimento, analisa-se a capacidade de geração automática de explicações para o utilizador. Esta funcionalidade pode ser criada graças à arquitetura dos sistemas baseados em conhecimento. Para facilitar a sua compreensão, recorre-se a um exemplo de aplicação de sistemas baseados em conhecimento. Trata-se de um sistema para avaliar o mérito de pedidos de financiamento para subsidiar atividades de investigação e desenvolvimento (I&D) num centro de investigação. A primeira secção deste capítulo descreve os aspetos mais relevantes do sistema, a segunda secção descreve a geração automática de explicações. 1.4 Sistema para avaliação de pedidos de financiamento A UIDIA (Unidade de Investigação e Desenvolvimento em Inteligência Artificial) 1 é uma organização que faz a gestão de fundos para o financiamento de atividades de investigação e desenvolvimento em áreas da inteligência artificial, nomeadamente em Sistemas Baseados em Conhecimento, e em Sistemas de Agentes, entre outros. A UIDIA financia diversos tipos de despesas, tais como a aquisição de livros, a aquisição de equipamentos, e a deslocação a reuniões de organizações de I&D e a conferências científicas. De todas estas despesas, as mais significativas são as deslocações a reuniões e a conferências. Esta secção analisa muito sumariamente um sistema baseado em conhecimento para avaliar o mérito das propostas de financiamento para suportar a deslocação a conferências dos membros da UIDIA. Os critérios de que depende a avaliação do mérito de uma proposta de financiamento são o seu mérito quanto à apresentação de trabalhos na dita conferência, o seu mérito quanto à participação na organização da conferência e a importância da conferência para a UIDIA. O mérito quanto à apresentação de trabalhos depende não linearmente do número de trabalhos. O mérito da proposta será tende a aumentar com o número de trabalhos a apresentar, mas o aumento não é linear. O mérito relativo à participação na organização da conferência depende não linearmente da quantidade de papéis desempenhados pelo delegado nas comissões e cargos da conferência: comissão de programa ("program committee"), comissão de organização local ("local-arrangements committee"), presidente da conferência ("conference chairman"), ou presidente de sessão ("session chairman"). O mais importante é a participação em uma destas comissões ou o desempenho de um desses cargos. Se o delegado desempenhar mais do que um papel, o mérito do pedido será maior mas o aumento não é linear. A importância da conferência para a UIDIA depende da relação entre os temas da conferência e as atividades científicas da UIDIA, e da importância da conferência em termos da sua projeção internacional e do seu reconhecimento pelas entidades que atribuem o financiamento geral à UIDIA. A concessão de financiamento depende de muitos outros fatores além do mérito da proposta. O mais importante desses fatores é a disponibilidade orçamental na altura em que o pedido é feito. Outro fator importante é a capacidade de previsão dos proponentes. Se uma deslocação for prevista com antecedência (i.e., no início do ano), a proposta tem mais possibilidades de ser contemplada do que se não for prevista. Seguidamente, apresentam-se regras que ilustram o conhecimento usado no sistema. 1 A unidade de investigação UIDIA não tem existência real; foi inventada para estes apontamentos. No entanto, o problema descrito é um problema real das unidades de investigação. 10

11 Regra 1 Se o mérito da proposta em termos da participação na organização da conferência tem o valor MéritoParticipação, e o mérito da proposta em termos da apresentação de trabalhos tem o valor MéritoApresentação, e a importância da conferência para a UIDIA tem o valor Importância Então o mérito global da proposta tem o valor Mérito 0.4 MéritoApresentação 0.4 MéritoParticipação 0.2 Importância Regra 2 Se o número de artigos apresentados é maior ou igual a 2 Então o mérito da proposta em termos da apresentação de trabalhos tem o valor MéritoApresentação 5 Regra 3 Se o número de artigos apresentados é 1 Então o mérito da proposta em termos da apresentação de trabalhos tem o valor MéritoApresentação 3 Regra 4 Se o número de artigos apresentados é 0 Então o mérito da proposta em termos da apresentação de trabalhos tem o valor MéritoApresentação 0 Regra 5 Se a importância da conferência para a área científica da UIDIA tem valor ImportânciaAreaCientifica, e a importância da conferência para o reconhecimento da UIDIA tem valor ImportânciaReconhecimento Então a importância da conferência para a UIDIA é Importância 0.4 ImportânciaAreaCientifica 0.6 ImportânciaReconhecimento Regra 6 Se o delegado à conferência pertence ao Program Committee, e o delegado à conferência NÃO pertence ao Local-Arrangements Committee Então o mérito devido à participação na organização da conferência é MéritoParticipação 4 Regra 7 Se o delegado à conferência pertence ao Local-Arrangements Committee, e o delegado à conferência NÃO pertence ao Program Committee Então o mérito devido à participação na organização da conferência é MéritoParticipação 4 Regra 8 Se o delegado à conferência pertence ao Program Committee e ao Local-Arrangements Committee Então o mérito devido à participação na organização da conferência é MéritoParticipação 5 Figura 7 Exemplos de regras do sistema de avaliação de mérito A Figura 7 não contém todo o conhecimento do sistema; apenas um número significativo de regras. O sistema de avaliação do mérito de propostas de financiamento de deslocações a conferências pode conter outras regras e também factos. 11

12 As regras da Figura 7 serão usadas seguidamente para ilustrar o conceito de geração de explicações e o funcionamento dos mecanismos que as geram. 1.5 Geração automática de explicações Uma das vantagens da utilização de representações explícitas é a possibilidade de usar o próprio conhecimento do sistema para gerar explicações acerca do seu raciocínio. Esta característica dos Sistemas Baseados em Conhecimento (os quais têm forçosamente representações explícitas) tem as seguintes vantagens: Facilita a tarefa de depurar, atualizar e gerir o conhecimento do sistema. Contribui para que o utilizador perceba e reforce a sua confiança nas sugestões do sistema. Existem essencialmente dois tipos de explicações que um SBC pode gerar: explicações why e explicações how. Quando o sistema faz uma pergunta ao utilizador para poder prosseguir o seu raciocínio, o utilizador pode querer saber por que razão o sistema fez a pergunta. A explicação apresentada neste tipo de situação é uma explicação why (i.e., Porque razão perguntas isso? ). Quando o sistema apresenta uma conclusão, uma sugestão ou qualquer outro tipo de resultado, o utilizador poderá querer saber como é que o sistema chegou ao resultado apresentado. As explicações apresentadas pelo sistema, em situações deste tipo, são explicações how (i.e., Como chegaste a esse resultado? ). Pelo facto de ser possível usar o conhecimento armazenado na base de conhecimento para produzir quer as soluções para os problemas apresentados ao sistema, quer para gerar explicações automaticamente, a geração de explicações é desempenhada pelo próprio mecanismo de inferência, sem ter de ser programado pelo programador do sistema. O programador tem apenas de preencher o conhecimento na base de conhecimento do sistema. Tanto a resolução de problemas como a geração de explicações estão a cargo do seu mecanismo de inferência, o qual é oferecido pela ferramenta usada para a criação do sistema baseado em conhecimento. Explicações Why Um sistema gera uma explicação why quando, após ter pedido ao utilizador para este lhe fornecer uma dada informação, o utilizador lhe pergunta Porque queres saber isso? ( Why do you ask? ). A explicação why consiste em mostrar a regra que se pretende usar e salientar que a utilização dessa regra depende da informação pedida e permite produzir uma determinada conclusão (intermédia ou final). Considerando o exemplo do sistema baseado em conhecimento para auxiliar na tomada de decisões de financiamento de deslocações a conferências (secção 1.4), as explicações why podem ser compreendidas através da interação representada na Figura 8. Sistema: O delegado à conferência pertence ao Program Committee (sim / não / why)? Utilizador: why // Porque queres saber isso? Sistema: Utilizador: Porque se o delegado à conferência pertencer ao program committee e não pertencer ao local arrangements committe, o mérito devido à participação na organização da conferência é MeritoParticipação = 4, e eu preciso saber qual é o valor de MeritoParticipação. O delegado à conferência pertence ao Program Committee (sim /não / why)? não. Figura 8 - Explicações why numa interação Na Figura 8, a explicação do sistema consiste em apresentar a regra usada no seu raciocínio. Neste caso, o texto da explicação obtém-se da regra 6: se o delegado à conferência pertencer ao program committee e não pertencer ao local arrangements committe, o mérito devido à participação na organização da conferência é MeritoParticipação = 4. Esta é exatamente uma das regras da BC do sistema, a regra que despoleta a pergunta do sistema. Se, na interação, em vez de ter respondido à segunda vez que o sistema apresenta a pergunta (mostrando a sua satisfação com a explicação), o utilizador voltasse a pedir explicações, o sistema daria uma explicação baseada na regra que utiliza a conclusão da regra 6 (usada na explicação anterior). A regra 6 produz a variável MeritoParticipação. A regra 1 utiliza o valor dessa variável para determinar o mérito global da proposta de financiamento. Seria produzida uma explicação com base na regra 1: 12

13 Porque se o mérito da proposta em termos da participação na organização da conferência tem o valor MéritoParticipação, o mérito da proposta em termos da apresentação de trabalhos tem o valor MéritoApresentação, e a importância da conferência para a UIDIA tem o valor Importância, então o mérito global da proposta tem o valor Mérito 0.4 MéritoApresentação 0.4 MéritoParticipação 0.2 Importância, e eu preciso saber qual é o valor de Mérito. Se, depois desta explicação, o utilizador voltasse a exigir mais explicações, o sistema procuraria a regra que iria utilizar o resultado da regra 1, a qual fi usada na última explicação. Como não existe nenhuma regra que use o valor do mérito global (Mérito), o sistema não teria mais explicações a dar. A próxima secção ocupa-se da geração de explicações do tipo How. Explicações How Um sistema gera uma explicação how quando o utilizador pretende que o sistema explique como é que chegou a um determinado resultado. Recorrendo ao exemplo da avaliação de propostas de deslocação a conferências, podemos admitir que o utilizador não percebe por que razão o sistema produziu uma dada avaliação para uma determinada proposta. Neste caso, o sistema pode apresentar as regras que usou para produzir essa avaliação. A interação da Figura 9 mostra este tipo de explicações. Sistema: A proposta A tem mérito 2 (numa escala de 0 a 5). Utilizador: Sistema: Utilizador: Sistema: How? (Como foi produzida essa avaliação?) Se o mérito da proposta em termos da participação do seu delegado na organização da conferência tem o valor MéritoParticipação, o mérito da proposta em termos da apresentação de trabalhos tem o valor MéritoApresentação, e e a importância da conferência para a UIDIA tem o valor Importância, então o mérito global da proposta tem o valor dado pela fórmula Mérito 0.4 MéritoApresentação 0.4 MéritoParticipação 0.2 Importância. O mérito da proposta em termos da participação do seu delegado na organização tem o valor MéritoParticipação 0. O mérito da proposta em termos da apresentação de trabalhos tem o valor MéritoApresentação 3. A importância da conferência para a UIDIA tem o valor Importância 4. Portanto o mérito global da proposta é Mérito Como se conclui que o mérito da conferência em termos da apresentação de trabalhos tem o valor 3? Se o número de artigos apresentados é 1 então o mérito da proposta em termos da apresentação de trabalhos tem o valor MéritoApresentação 3. O número de artigos a apresentar é igual a 1 Portanto, o mérito da proposta em termos da apresentação de trabalhos é MéritoApresentação 3. Figura 9 - Interação com explicações how Para que o sistema produza uma explicação how, o utilizador tem que perguntar como é que ele chegou a determinado resultado. Em reposta, o sistema mostra a regra e os factos que lhe permitiram chegar ao resultado. Na geração automática de explicações que serviu de base à interação da Figura 9, o sistema mostra a regra usada para produzir o resultado final, neste caso, a regra 1. Essa regra depende de resultados que podem ser conhecidos do sistema (i.e., são factos na base de conhecimento) ou que podem ser gerados pela utilização de outras regras. A explicação produzida na Figura 9 apresenta apenas os resultados usados pela regra que usou para gerar a explicação, sem explicar se eles eram conhecidos pelo sistema ou se foram produzidos por outras regras. Neste caso, o sistema apresenta os seguintes resultados: 13

14 O mérito da proposta em termos da participação do seu delegado na organização tem o valor MéritoParticipação 0. O mérito da proposta em termos da apresentação de trabalhos tem o valor MéritoApresentação 3. A importância da conferência para a UIDIA tem o valor Importância 4. No entanto, quando o utilizador pretende obter mais explicações sobre um destes resultados intermédios, o sistema de geração automática de explicações apresenta a forma como ele foi produzido. No caso desta interação, o utilizador pretende obter explicações adicionais sobre o mérito da proposta em termos da apresentação de trabalhos (MéritoApresentação). Mais uma vez, o sistema apresenta uma explicação que consiste em mostrar a regra usada para produzir MéritoApresentação (regra 3) e os resultados intermédios de que essa regra depende (neste caso, o número de artigos apresentados): Se o número de artigos apresentados é 1 então o mérito da proposta em termos da apresentação de trabalhos tem o valor MéritoApresentação 3. O número de artigos a apresentar é igual a 1. Tal como acontece com a geração automática de explicações do tipo Why, a geração automática de explicações do tipo How também recorre ao conhecimento explicitamente representado na base de conhecimentos para gerar a explicação. Se esse conhecimento não estivesse explicitamente representado, não poderiam ser geradas explicações automáticas sem que o programador do sistema, para cada aplicação específica, tivesse de programar as próprias explicações. Pelo contrário, num sistema com conhecimento representado explicitamente, as explicações podem ser automaticamente geradas pelo mecanismo de inferência do sistema, sem que o programador tenha de a programar. A próxima secção trata da validação automática da base de conhecimentos, a qual é também uma possibilidade que se deve à representação explícita de conhecimento. 14

15 4 Validação da base de conhecimentos Uma ferramenta computacional para desenvolvimento de sistemas baseados em conhecimento pode permitir a validação automática da base de conhecimentos em termos da sua consistência e completude. Em termos de consistência pode verificar-se se os conhecimentos que a compõem são contraditórios. A verificação de inconsistência consiste em determinar se é possível derivar uma proposição (P) e a sua negação ( P) a partir da base de conhecimentos do sistema. Em termos de completude, podem fazer-se duas coisas: verificar se os factos existentes na base de conhecimento e se as conclusões geradas pelas regras são usados (noutras regras), e verificar se existe a informação necessária à avaliação das condições das regras. Estas validações podem ser feitas por mecanismos existentes no motor de inferência, sem qualquer intervenção do programador do sistema baseado em conhecimento. Como o conhecimento é representado explicitamente, os mecanismos de validação da base de conhecimentos limitam-se a percorrer toda a base de conhecimentos e detetar as deficiências para que tiverem sido concebidos. Se não fossem usadas representações explícitas, seria impossível (ou muito difícil) criar mecanismos capazes de examinar o conhecimento do sistema e detetar deficiências. Os exemplos que ilustram os mecanismos de validação da base de conhecimentos foram inspirados num sistema pericial, descrito na secção Error! Reference source not found., concebido para auxiliar decisões de atribuição de financiamento a deslocações a conferências científicas, numa unidade de investigação imaginada, designada UIDIA (Unidade de Investigação e Desenvolvimento em Inteligência Artificial) Verificação de consistência Para explicar em que consiste a deteção de contradições / inconsistências, considerem-se as três regras e os dois factos apresentados na Figura 10. As duas primeiras regras são versões deficientes das regras 6 e 7 da Figura 7. 2 A unidade de investigação UIDIA não tem existência real; foi inventada para estes apontamentos. No entanto, o problema descrito é um problema real das unidades de investigação. 15

16 Regra 1 Se o delegado à conferência pertence ao Program Committee Então o mérito devido à participação na organização da conferência é MéritoParticipação 4 Regra 2 Se o delegado à conferência pertence ao Local-Arrangements Committee Então o mérito devido à participação na organização da conferência é MéritoParticipação 4 Regra 3 Se o delegado à conferência pertence ao Program Committee e ao Local-Arrangements Committee Então o mérito devido à participação na organização da conferência é MéritoParticipação 5 Facto 1 o delegado à conferência pertence ao Program Committee Facto 2 o delegado à conferência pertence ao Local-Arrangements Committee Figura 10 - Regras e factos inconsistentes A base de conhecimentos apresentada na Figura 10 é inconsistente no sentido em que é possível derivar que o mérito da proposta devido à participação na organização tem o valor 4 (regra 1 e facto 1; ou regra 2 e facto 2) e também é possível derivar que o mérito tem o valor 5 (i.e., não tem o valor 4). Seria útil que a ferramenta computacional usada para implementar o sistema de avaliação do mérito de pedidos de financiamento pudesse detetar este tipo de inconsistências. 4.2 Base de conhecimentos não completa A base de conhecimentos da Figura 11 serve de exemplo para ilustrar dois tipos de não completude: a BC contém factos que não são usados; e a BC tem regras que dependem de factos que não são conhecidos nem se podem derivar, nem se podem perguntar ao utilizador. 16

17 Regras Regra 1 Se o mérito da proposta em termos da participação na organização da conferência tem o valor MéritoParticipação, e o mérito da proposta em termos da apresentação de trabalhos tem o valor MéritoApresentação, e a importância da conferência para a UIDIA tem o valor Importância Então o mérito global da proposta tem o valor Mérito 0.4 MéritoApresentação 0.4 MéritoParticipação 0.2 Importância Regra 2 Se o número de artigos apresentados é maior ou igual a 2 Então o mérito da proposta em termos da apresentação de trabalhos tem o valor MéritoApresentação 5 Regra 3 Se o número de artigos apresentados é 1 Então o mérito da proposta em termos da apresentação de trabalhos tem o valor MéritoApresentação 3 Regra 4 Se o número de artigos apresentados é 0 Então o mérito da proposta em termos da apresentação de trabalhos tem o valor MéritoApresentação 0 Regra 5 Se a importância da conferência para a área científica da UIDIA tem valor ImportânciaAreaCientifica, e a importância da conferência para o reconhecimento da UIDIA tem valor ImportânciaReconhecimento Então a importância da conferência para atividades existentes na área da UIDIA é ImportânciaUIDIA 0.4 ImportânciaAreaCientifica 0.6 ImportânciaReconhecimento Informação que pode ser pedida ao utilizador Número de artigos a apresentar Importância da conferência para a área científica da UIDIA Importância da conferência para o reconhecimento da UIDIA Figura 11- Base de conhecimentos incompleta para o sistema de atribuição de financiamento da UIDIA As regras incluídas na base de conhecimento apresentada na Figura 11 constituem versões com alterações das regras realmente existentes na base de conhecimento do sistema (Figura 7). Nomeadamente, o resultado produzido pela versão alterada da regra 5 designa-se ImportânciaUIDIA, enquanto a versão original da regra produz o resultado Importância. Esta alteração foi introduzida propositadamente para que o mecanismo de deteção de incompletude pudesse detetar um problema. Para facilitar a compreensão do problema de determinar que conhecimento/informação faltam na base de conhecimento, apresenta-se uma representação gráfica do conhecimento nela armazenado e das relações entre os seus diversos componentes. Para isso recorremos aos diagramas de dependências da metodologia de análise e conceção de sistemas baseados em conhecimento descrita em [Botelho e Ramos 1992]. Os diagramas de dependência são constituídos por unidades de decisão que representam dependências entre variáveis do domínio. Cada unidade de decisão é representada graficamente por um triângulo. As variáveis do domínio são representadas por retângulos. As variáveis de input (variáveis 17

18 independentes) são também representadas por retângulos mas com um ponto de interrogação antes do seu nome. A Figura 12 representa o diagrama de dependências correspondente à Base de Conhecimentos de papel da Figura 11. Figura 12 - Diagrama de decisão para o sistema de atribuição de financiamento da UIDIA Os dois retângulos da Figura 12 com linha a tracejado não fazem parte do diagrama de decisão; apenas servem para indicar explicitamente a insuficiência do conhecimento disponível. Falta de informação Uma ferramenta computacional para sistemas baseados em conhecimento pode analisar o conhecimento disponível e detetar possíveis insuficiências. Em termos simplistas, a deteção de insuficiências de informação consiste essencialmente em determinar se existe alguma implicação A B e não se pode provar se A nem se A a partir da Base de Conhecimentos, nem se pode perguntar se A é verdade. Usando, como exemplo, a base de conhecimentos descrita na Figura 11 e na Figura 12, a deteção de informação insuficiente produziria o seguinte resultado: O mérito da proposta depende do mérito devido à apresentação de trabalhos (MéritoApresentação), do mérito devido à participação na organização da conferência (MéritoParticipação) e da importância da conferência para a UIDIA (Importância). A importância da conferência para a UIDIA (Importância) não é conhecida nem é perguntada ao utilizador. O mérito da proposta devido à participação na organização da conferência (MéritoParticipação) não é conhecida nem é perguntada ao utilizador. Repare-se que esta variável não é conhecida porque, talvez por engano, a unidade de decisão U3 produz um resultado com a designação ImportânciaUIDIA em vez de Importância. Não há pois uma ligação entre o resultado da unidade de decisão U3 e a unidade de decisão U1. Relativamente ao mérito devido à participação na organização da conferência (MéritoParticipação), de facto essa variável não é conhecida, nem pode ser perguntada, nem pode ser determinada por uma ou mais regras. Factos e conclusões não usadas Além da deteção de informação insuficiente, a ferramenta de desenvolvimento de sistemas baseados em conhecimento poderá também detetar se existem factos inúteis na base de conhecimento ou se podem ser geradas conclusões não usadas. Em termos simples, a deteção de informação não usada consiste essencialmente em determinar se existe algum facto B ou alguma implicação A B e não existe nenhuma implicação D C, tal que D seja igual ou contenha B.. 18

19 Considere-se uma vez mais o exemplo da Figura 11 e da Figura 12. Por exemplo, a importância da conferência para atividades existentes no âmbito da UIDIA (variável ImportânciaUIDIA, unidade de decisão U 3 ) é determinada por uma das regras da base de conhecimentos e não é usada. A análise da base de conhecimentos em termos de informação não usada produziria o seguinte relatório. A importância da conferência para atividades existentes no âmbito da UIDIA (variável ImportânciaUIDIA) é determinada pela regra 5 e não é usada. O mérito global da conferência (variável Mérito) é determinado pela regra 1 e não é usado. O mérito global da proposta é determinado e não usado em nenhuma outra regra, no entanto este é o objetivo final do sistema. Ou seja, o aviso produzido pelo mecanismo de deteção de insuficiências na base de conhecimento, relativamente à variável Mérito pode ser ignorado. 19

20 5 Implementação em Prolog de mecanismos de representação e raciocínio 5.1 Meta-interpretadores (Prolog em Prolog) Os mecanismos de geração automática de explicações são mecanismos que usam o próprio conhecimento do domínio do sistema para gerar explicações que podem ser exibidas ao utilizador. Idealmente, a geração destas explicações não exige nenhum trabalho adicional ao Engenheiro do Conhecimento que cria o sistema. O Engenheiro do Conhecimento apenas tem que representar o conhecimento da aplicação. A utilização desse conhecimento para gerar explicações é da exclusiva responsabilidade do sistema. Esta secção analisa a implementação de um sistema de raciocínio dedutivo encadeado para trás. Este programa será estendido em secções posteriores. Os mecanismos de geração de explicações apresentados são definidos para o caso concreto do raciocínio dedutivo encadeado para trás. Para outros tipos de raciocínio ou para outras estratégias de encadeamento teriam que ser criados outros mecanismos de geração de explicações. Através de uma tecnologia de programação muito simples chamada meta-programação é possível criar um programa em Prolog capaz de interpretar o próprio Prolog. Este programa não tem qualquer utilidade por si só, mas a sua análise permite compreender mecanismos indispensáveis noutras secções deste documento. Um programa capaz de interpretar Prolog é um programa que recebe um objetivo Prolog e verifica se o objetivo pode ser satisfeito pela instanciação de variáveis. Para isso, o programa verifica se o objetivo que recebe é o objetivo verdade, ou se é uma conjunção cujos componentes são objetivos que se podem satisfazer, ou se existe alguma cláusula na base de conhecimentos do Prolog que possa ser usada na satisfação do objetivo. Posteriormente, o programa será sofisticado com a verificação de outras condições (negações e objetivos built-in ). A Figura 13 mostra a definição do predicado solve/1 o qual é capaz de verificar se um objetivo Prolog se pode satisfazer. solve(verdade). solve((a, B)):- solve(a), solve(b). solve(p):- clause(p, Body), solve(body). Figura 13 Meta-interpretador de Prolog Embora simples, o predicado solve/1 constitui a base do Prolog. solve(p) tem sucesso, se o objetivo P puder ser satisfeito, isto é, se existir uma instanciação das variáveis de P tal que P seja verdade (i.e., tal que P se possa derivar da Base de Conhecimentos). A primeira cláusula da definição de solve/1 (Figura 13) diz que o objetivo verdade é verdade. A segunda cláusula de solve/1 diz que uma conjunção (A, B) pode ser satisfeita se tanto A com B puderem ser satisfeitos. É importante referir que, devido ao mecanismo de associatividade do Prolog, (A, B) pode ser uma conjunção com mais do que dois argumentos. A é o primeiro argumento da conjunção, B é o resto (eventualmente, outra conjunção). A terceira cláusula de solve/1 diz que o objetivo P pode ser satisfeito se existir uma cláusula para P com o formato P:-Body e se Body puder ser satisfeito. Para verificar se existe uma cláusula para um dado objetivo, usa-se o predicado especial clause/2. clause(head, Body) tem sucesso se existir uma clausula com o formato Head:-Body na Base de Conhecimentos. Isto é, clause/2 devolve o corpo de cada cláusula de um determinado predicado. Para verificar se Body pode ser satisfeito, solve/1 recorre a si próprio. Para melhor compreender o funcionamento de solve/1, analisa-se um exemplo simples. A Figura 14 mostra uma pequena Base de Conhecimentos com cláusulas de relações familiares. 20

21 avo(x, Y):- pai(x, Z), pai(z, Y). avo(x, Y):- pai(x, Z), mae(z, Y). pai(bernardo, luis). pai(luis, miguel). Figura 14 Pequena base de conhecimentos A Figura 15 ilustra a utilização do predicado solve/1 no interpretador de Prolog. Na interação usa-se a pequena Base de Conhecimentos da Figura 14.?- solve(avo(bernardo, miguel)). yes?- solve(avo(x, Y)). X bernardo, Y miguel; no?- Figura 15 Interação com o predicado solve/1 Na segunda interação, o Prolog não pode usar a primeira cláusula da definição de solve/1 porque o objetivo avo(x, Y) não emparelha com verdade. A segunda cláusula da definição também não pode ser usada porque o objetivo avo(x, Y) não emparelha com a conjunção (A, B). Como existe a cláusula avo(x, Y):- pai(x, Z), pai(z, Y), o Prolog tenta usar a terceira cláusula da definição de solve/1. De acordo com a terceira cláusula, avo(x, Y) pode ser satisfeito se (pai(x, Z), pai(z, Y)) também puder ser satisfeito. Portanto, o objetivo inicial solve(avo(x, Y)) é substituído pelo novo objetivo solve((pai(x, Z), pai(z, Y))). A primeira cláusula da definição não pode ser usada porque (pai(x, Z), pai(z, Y)) não emparelha com verdade. A segunda cláusula pode ser usada porque (pai(x, Z), pai(z, Y)) emparelha com (A, B). Seguindo a segunda cláusula, a conjunção (pai(x, Z), pai(z, Y)) pode ser satisfeita se o objetivo pai(x, Z) puder ser satisfeito e se o objetivo pai(z, Y) também puder ser satisfeito. O objetivo inicial é agora substituído pelos dois objetivos solve(pai(x, Z)) e solve(pai(z, Y)). Mais uma vez, o objetivo solve(pai(x, Z)) não pode ser resolvido pela primeira nem pela segunda cláusula de solve/1. O mesmo acontece em relação ao objetivo solve(pai(z, Y)). Como um facto P é equivalente à cláusula P:-verdade, a terceira cláusula pode ser aplicada para resolver o objetivo solve(pai(x, Z)), desde que X bernardo, Z luis e Body verdade. Consequentemente, solve(pai(x, Z)) é substituído por solve(verdade). solve(verdade) é resolvido pela primeira cláusula da definição de solve/1. A instanciação da variável Y é propagada para o segundo objetivo por resolver, nomeadamente solve(pai(luis, Y)). solve(pai(luis, Y)) é resolvido por um processo análogo ao da resolução de solve(pai(x, Z)), resultando na instanciação de X com a constante bernardo. Como solve(pai(x, Z)) e solve(pai(z, Y)) foram resolvidos, então solve((pai(x, Z), pai(z, Y))) também foi resolvido. Consequentemente, solve(pai(x, Y)) também foi resolvido. O predicado solve/1 definido na Figura 13 pode ser facilmente aumentado de modo a que a negação por falha seja resolvida. Para isso basta dizer que not(p) é satisfeito se a satisfação de P falha. Em Prolog, a satisfação de diversos predicados e a avaliação de diversos operadores recorrem a procedimentos específicos: são os chamados predicados e operadores built-in. Destes destacam-se os operadores aritméticos, certos predicados relacionais, e procedimentos para ler e escrever, operadores de manipulação da base de conhecimentos (i.e., assert e retract) e operadores de controlo. Um meta-interpretador pode recorrer ao predicado call/1 para avaliar a satisfação de predicados pré-construídos na linguagem. Na Figura 16 apresenta-se a extensão do meta-interpretador solve/1 com a negação e com predicados pré-construídos. 21

22 solve(verdade). solve((a, B)):- solve(a), solve(b). solve(not(p)):- \+ solve(p). solve(p):- clause(p, Body), solve(body). solve(p):- system(p), call(p). Figura 16 Meta-interpretador com negação e predicados built-in Na última cláusula da Figura 16, surge o predicado especial system/1. system/1 serve para testar se um predicado é pre-construído a linguagem. A sintaxe de system/1 não é sempre a mesma, varia de implementação para implementação. Em certas implementações, o argumento do predicado system/1 é um termo formado pelo nome do predicado e pela sua aridade, por exemplo write/1. Também pode acontecer que system/1 nem sequer exista e que tenha que se utilizar outro com o mesmo objetivo. 5.2 Explicações Why Quando o sistema faz uma pergunta ao utilizador, este pode não perceber porque razão o sistema o faz. Se o sistema tiver a capacidade de gerar explicações Why, será capaz de explicar ao utilizador qual é a finalidade da pergunta. A interação da Figura 17 ilustra esta situação. O sistema explica ao utilizador que quer saber se o Luís é pai da Catarina porque se o Bernardo é pai do Luís e o Luís é pai da Catarina, então o sistema conclui que o Bernardo é avô da Catarina que é o que ele está a tentar fazer.?- avo(bernardo, catarina). pai(luis, catarina) (sim/nao/porquê)? porquê Porque Se pai(bernardo, luis) e pai(luis, catarina) Então avo(bernardo, catarina) pai(luis, catarina) (sim/nao/porquê)? sim yes?- Figura 17 Interação com explicações Why Como as explicações do tipo Why servem para o sistema explicar por que razão faz determinada pergunta, este mecanismo de geração de explicações está intimamente ligado à possibilidade de fazer perguntas ao utilizador. O meta-interpretador que vamos analisar tenta provar se um determinado objetivo é verdade. Se necessário, pede ao utilizador para dizer se uma dada proposição é verdade ou falsa. Para isso tem que se poder especificar que factos podem ser perguntados ao utilizador. Vamos usar o predicado especial askable/1. askable(p) significa que o sistema pode perguntar ao utilizador se P é verdade ou falso. Quando o meta-interpretador tenta provar um dado objetivo P, e o sistema não sabe que P é falso e P não é igual a verdade, nem é uma conjunção, nem é uma negação, nem há uma cláusula para P, e P pode ser perguntado, então o meta-interpretador pergunta se P é verdade. Se o utilizador responder que sim, P é acrescentado à base de conhecimentos. Se o utilizador responder que não, untrue(p) é acrescentado à base de conhecimentos. Se o utilizador quiser saber porque razão o sistema faz a pergunta, este apresenta uma explicação de tipo why. Se o sistema guardar as regras usadas no seu raciocínio, poderá apresentá-las como explicação daquilo que tenta provar em cada passo. Para isso, o predicado solve/2 terá dois argumentos: objetivo que se pretende provar e a lista das regras usadas até ao passo de prova atual. 22