You are here

Home » Courses » IA006 » Apresentação de Atividades » Apresentação de Atividades - Turma 2013 » Aluno 2

Aula 02 - 08/03/2013 - Início dos estudos do Soar

published by aluno2 on Fri, 03/08/2013 - 18:04

 Relatório das atividades:

 



 
 
ATIVIDADE 1: Instalando o Soar
Esta atividade ocorreu sem maiores dificuldades.
 
 
 
A criação do primeiro programa Soar também não apresentou dificuldades; segue abaixo a execução do "Hello Soar" no "Soar Debugger":
 

 
COMENTÁRIOS SOBRE A MEMÓRIA DE TRABALHO
 
  1. Todos os elementos da memória de trabalho são organizados dentro de grafos de ESTADOS.
  2. Cada NÓ do grafo pode ser um IDENTIFICADOR (nó não terminal) ou  CONSTANTES (nós terminais).
  3. As arestas do grafo são direcionais e correspondem a ATRIBUTOS do NÓ origem; somente INDENTIFICADORES podem ter atributos.
  4. A memoria de trabalho é constituída, então, de triplas (IDENTIFICADOR, ATTRIBUTO, VALOR), sendo que VALOR pode ser um outro IDENTIFICADOR ou uma CONSTANTE.
  5. Um OBJETO é o nome dado ao conjunto de triplas que derivam de um mesmo IDENTIFICADOR comum. Cada tripla que compõe um OBJETO é chamada de EXTENSÃO (augmentation).
  6. Como cada OBJETO normalmente representa algo do mundo real, cada EXTENSÃO pode ser entendido como um ATRIBUTO do objeto ou RELAÇÃO desse objeto com outro.
  7. Para entrada e saída a memória de trabalho utiliza IDENTIFICADORES especiais que permitem acomplamentos externos.
 
 
 
O programa "Hello world" baseado em operadores também não apresentou dificuldades; sua execução diferiu um pouco da primeira versão:
 
 
 
COMENTÁRIOS SOBRE O USO DE REGRAS COM OPERADORES

Segundo o próprio tutorial, o uso de OPERADORES permite:
  1. Criar AÇÕES que serão consideradas (avaliadas) para execução em diversas situações, a partir das REGRAS DE PROPOSIÇÃO dos operadores;
  2. Permite que uma AÇÃO seja selecionada a partir de vários RACIOCÍONIOS, através das REGRAS DE SELEÇÃO dos operadores;
  3. Permite que uma AÇÃO seja executada de diversas maneiras, através das REGRAS DE APLICAÇÃO dos operadores.
 
Dessa maneira, o conceito de OPERADORES cria uma forma versátil para associar REGRAS, a partir de uma abstração (o próprio operador) construida ao redor de um objetivo (as ações associadas): pode-se chegar a essa abstração de diversas maneiras e o objetivo também pode ser atingido de formas distintas, tudo dependendo do conhecimento ou experiência prévia.
 
 
COMENTÁRIOS SOBRE O PROCESSO DE CRIAÇÃO DE OPERADORES

Na fase de PROPOSIÇÃO, a regra de proposição do operador funciona criando o operador como atributo específico - "^name hello-world" - no IDENTIFICADOR que a própria regra seleciona. Essa regra, quando ativada (condição é verdadeira), modifica a memória de trabalho, criando essa nova EXTENSÃO ao IDENTIFICADOR selecionado.

A regra de aplicação, já na fase de DECISÃO, utiliza a sua condição para selecionar um operador e definir o que serão, de fato, as suas AÇÕES. Essa regra, quando ativada, modifica a memória de trabalho, criando uma nova EXTENSÃO no IDENTIFICADOR que propôs o OPERADOR; essa nova extensão é que indica a execução do OPERADOR.
 
 
COMENTÁRIOS SOBRE O USO DO VisualSoar

Uma primeira análise do VisualSoar permite concluir a funcionalidade do "Datamap" adiciona uma facilidade durante o desenvolvimento de uma aplicação no Soar, não somente para a visualização gráfica da estrutura da memória de trabalho - os IDENTIFICADORES e suas EXTENSÕES, no formato que o "SoarDebugger" apresenta são um pouco difíceis de visualizar, especialmente para OBJETOS muito extensos. A funcionalidade de validação da memória de trabalho também parece aumentar a eficiência do desenvolvimento.
 
 
 
 
COMENTÁRIOS SOBRE CRIAÇÃO DO AGENTE PARA RESOLUÇÃO DO PROBLEMA DO JARRO DE ÁGUA
 
Código fonte o programa aqui.

PERSISTÊNCIA DE ELEMENTOS DA MEMÓRIA DE TRABALHO

O Soar faz uma distinção entre os elementos da memória de trabalho considerando se eles foram gerados ou não por uma regra de APLICAÇÃO de um operador: caso tenham sido geradas, essas modificações são consideradas como tendo o SUPORTE DE OPERADOR ("operator-support" ou simplesmente "o-support"); as modificações que não geradas a partir de regras de aplicação são consideradas como tendo o SUPORTE DE INSTANCIAÇÃO ("instantiation-support" ou simplesmente "i-support").

Modificações com suporte de instanciação são aquelas geradas no processo de proposição e seleção - criadas durante o proceso ocorrido até checar na aplicação de fato de um operador.

De forma a garantir a consistência do conhecimento capturado na memória de trabalho, o Soar DESFAZ quaisquer modificações com SUPORTE DE INSTANCIAÇÃO a partir do momento que as CONDIÇÕES que levaram até elas (as condições descritas pelas regras que realizaram as modificações na memória de trabalho) DEIXAM de ser VERDADEIRAS.
 
 
REGRAS DE ELABORAÇÃO DE ESTADO
 
Regras de elaboração de estado criam estruturas na memória de trabalho (EXTENSÕES) a partir de combinação de outros elementos da mesma memória de trabalho. Dessa maneira, são extremamente úteis elaborando abstrações do conhecimento existente que passam a compor essa mesma base de conhecimento e que podem, por conseguinte, servir de base para novas decisões ou avaliações.
 
Regras de elaboração de estado criam estruturas na memória de trabalho com SUPORTE DE INSTANCIAÇÃO; assim, quando os estados que as regras testam se modificam, as estruturas na memória de trabalho são recomputadas (atualizadas) automaticamente.
 
 
PROPOSIÇÃO DE OPERADORES
 
O Soar funciona em 5 fases que acontecem na seguinte ordem:
 
  1. Fase de ENTRADA
  2. Fase de ELABORAÇÃO DO ESTADO e PROPOSIÇÃO DE OPERADORES
  3. Fase de DECISÃO - SELECÃO DE OPERADORES
  4. Fase de EXECUÇÃO - APLICAÇÃO do operador selecionado
  5. Fase de SAÍDA
 
Durante as fases 2 e 4 podem ocorrer a proposição de operadores; as regras de proposição de operadores definem CONDIÇÕES sobre o ESTADO da memória de trabalho; caso essas condições sejam verdadeiras, essas regras definem as PREFERÊNCIAS DE ACEITAÇÃO do operador utilizadas para determinar a sua posterior seleção.
 
A validação das condições de uma regra de proposição são avaliadas nos OBJETOS da memória de trabalho - a partir do seu ESTADO raiz, de onde derivam todas as suas extensões; as preferências de aceitação são armazenadas na memória de trabalho como EXTENSÕES contendo modificadores para indicar que correspondem a são PROPOSIÇÕES de operadores que estão ATIVAS naquele determinado objeto. Essas EXTENSÕES têm "i-support".
 
 
APLICAÇÃO DE OPERADORES
 
Na fase 3 acima - de SELEÇÃO DE OPERADORES - o Soar busca as PROPOSIÇÕES ativas e tenta decidir, entre elas, qual aplicar. Aparentemente, somente 1 operador pode ser aplicado por vez. Assim, se não for possível a partir das regras de preferência definir um operador preferencial, o Soar entra num estado de EMPATE que pode criar um impasse sem solução. É possível aplicar modificadores - como o randômico ("=") - para indicar ao Soar como determinar o operador a executar.
 
Uma vez selecionado o operador a ser aplicado, é criada na memória de trabalho uma EXTENSÃO correspondente à preferência de aceitação escolhida: essa extensão similar à extensão correspondente à proposição selecionada, porém não são utilizados os modificadores que indicam ser uma regra de proposição. Essa extensão também tem "i-support".
 
O Soar evolui então para a fase 4, de APLICAÇÃO do operador. Para tanto, avalia todas as regras de aplicação que contém uma condição que dependa, pelo menos parcialmente, da preferência de aceitação escolhida. TODAS as regras de aplicação que tiverem sua condição satisfeita serão executadas e, durante sua execução, todas as EXTENSÕES criadas terão "o-support".
 
Uma vez que a memória de trabalho é modificada, EXTENSÕES com "i-support" poderão ser desfeitas, correspondentes à RETRAÇÃO de regras que deixaram de ter suas condições satisfeitas. A própria regra de seleção bem como de proposição do operador aplicado podem estar dentre as regras retraídas.
 
Soar tem uma condição de que toda aplicação de operador tem que necessariamente modificar o estado da memória de trabalho.
 
 
MONITORAMENTO DE ESTADOS E OPERADORES

É possível fazer o monitoramento de estados e operadores criando regras que tenham como condições o que se quer monitorar e cuja ação seja o comando Soar "write", o qual concatena todos os seus parâmetro e manda para a saída do programa.

Dessa maneira, essas regras de monitoramento são disparadas durante as fases 2 (ELABORAÇÃO DO ESTADO e PROPOSIÇÃO DE OPERADORES) e 4 (EXECUÇÃO - APLICAÇÃO do operador selecionado), produzindo as saídas que permitem o monitoramento.


RECONHECIMENTO DO ESTADO DESEJADO

Para se fazer com que o Soar reconheça o um estado desejado, é preciso criar regras que determinem quais são esses estados. Assim como uma regra de monitoramento, uma regra que define um estado desejado tem como condições justamente a configuração dos elementos da memória de trabalho que definem um estado desejado; como ação, essa regra pode, por exemplo, interromper o programa com o comando "halt".

Durante as fases 2 e 4, o Soar irá continuamente testar essas regras de reconhecimento de estado desejado e, eventualmente, dispará-las.

É possível criar essas regras de reconhecimento contendo diretamente em suas condições os parâmetros que descrevem um estado desejado. Uma maneira um pouco mais versátil é criar estruturas na memória de trabalho - durante a etapa de inicialização da aplicação - para armazenar esses parãmetros: dessa maneira, as regras de reconhecimento comparariam as estruturas da memória de trabalho com essas estruturas de referência.


CONTROLE DE BUSCA

Através do uso dos modificadores das preferências é possível alterar a semântica de uma preferência, estabelecendo critérios para a sua escolha.

Da mesma maneira que foi acrescentado o modificador "=" para indicar que a seleção do operador pode ser randômica, no caso de haver mais de um operador proposto; alguns dos modificadores adicionais existentes são:
  • "op >" - para indicar que um operador é o melhor de todos
  • "op <" - para indicar que um operador é o pior de todos
  • "op1 >, op2 <" - para indicar que "op1" é melhor que "op2", caso ambos estejam propostos
  • "op -" - para rejeitar um operador


Com esses operadores, é possível criar regras que verifiquem se um determinado operador foi proposto e, em determinadas condições adicionais, modifiquem a sua preferência, adicionando modificadores.

Na aplicação "water-jug" é exatamente isso que faz as regras adicionadas para cada operação, como a abaixo, adicionada para a operação "fill", de maneira a torná-la a pior, caso a última operação executada tenha sido justamente a inversa, ou seja, "empty" sobre o mesmo jarro:

 
sp {water-jug*select*operator*avoid*inverse*fill
   (state <s> ^name water-jug
              ^operator <o> +
              ^last-operator <lo>)
   (<o> ^name fill
        ^fill-jug <i>)
   (<lo> ^name empty
         ^empty-jug <i>)
-->
(<s> ^operator <o> <)
}

 
Com a aplicação do controle de busca a execução do water-jug fica mais eficiente; abaixo a resolução do problema em 13 passos:
 
 
 
CONCLUSÃO

Os experimentos realizados dentro do tutorial 1 permitiram criar uma noção básica a respeito do funcionamento do Soar, no que diz respeito ao seu mecanismo de armazenamento do conhecimento na forma de conhecimento de longo-prazo - o que pode ser chamado de programa Soar - e na forma de conhecimento intermediário - a memória de trabalho.

O funcionamento do Soar está baseado na premissa de que o processo de resolução de um problema pode ser modelado em uma sucessão de diferentes estados, transicionados a partir da aplicação de operadores. A busca de um estado meta é, então, a sucessão contínua de etapas de proposição de operadores, seleção de apenas um operador e aplicação do operador.

Até o que foi explorado nesse primeiro tutorial, o Soar se assemelha com um sistema especialista uma vez que:

- O conhecimento existente é modelado;
- As regras para análise desse conhecimento são modeladas;
- O funcionamento do sistema busca reproduzir a cognição humana;

De fato, as primeiras implementação de larga escala do Soar foram feitas sobre reimplementações de sistemas especialistas - vide R1-Soar (Rosenbloom et al. 1985).

Entretanto, ao contrário de sistemas especialistas que focam em um domínio específico e estático, visando reproduzir o pensamento e conclusões de um especialista nesse mesmo domínio, pode ser considerado que o Soar tem um alcance mais amplo, sendo possível a implementação de sistemas especialistas a partir do Soar, mas com outras possibilidades, como a criação de modelos cognitivos baseados na aplicação do conhecimento, modelos de comportamento humano e agentes autônomos.

Essa possibilidade de aplicar diversos métodos cognitivos talvez seja o ponto que faz com que o Soar englobe as características dos sistemas especialistas.
 
 
 
 
  
  


  
  



 

 
  



						

 

    


 




 


 




Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer