+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + Atividade 4: Criando um Agente para o Water Jug Problem + +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> Persistência de WMEs **Pergunta:** Depois que uma regra é executada, por quanto tempo o resultado permanece na memória de trabalho ? Como o Soar resolve esse problema, para que os resultados da inferência de uma regra possam ser utilizados em outras regras, sem fazer explodir a memória de trabalho ? **Resposta:** Quando os operadores são lançados, todas as estruturas são adicionadas nas WM. Depois de aplicados, Soar automaticamente os retira da WM pois não fazem mais match. Para que o sistema tenha progesso, o Soar difere a persistência da WM criados pelo operador da persistência de elementos criados por outros tipos de regras. Esta é uma importante feature do Soar que faz a distinção do conhecimento que altera o estado atual e o conhecimento que computa as decisões e detalhes da situação corrente. >> Elaboração de Estado A representação do estado é parte muito importante do agente Soar a ser desenvolvido. A estrutura é definida em parte por quais dados são percebidos pelo agente, além das ações/comandos do problema. No caso apresentado, a sugestão é ter na representação o tamanho e a quantidade atual de água em cada pote. A primeira sugestão ("state ^five-gallon-jug-contents 0 ^three-gallon-jug-contents 0") é detalhada mas ineficiente pois teríamos que escrever operadores específicos para cada pote. A segunda sugestão é criar um conceito de pote (jug) com dois atributos (^volume, ^contents) descritos da seguinte forma: (state ^jug ^jug ) ( ^volume 5 ^contents 0) ( ^volume 3 ^contents 0) Apesar da estrutura ser adequada para representar, o mais indicado é adicionar um identificador para a tarefa que está em tentativa. Neste caso, "water-jug" "(^name water-jug)". **Pergunta:*** O tutorial 1 sugere, para a resolução do problema Water Jug, a utilização de uma estratégia que ele chama de elaboração de estado. Como funciona essa estratégia ? Descubra e documente em seu relatório. **Resposta:** A elaboração de estado (anteriormente discutimos a representação) é um tipo de regra que permite criar abstrações e combinações úteis diretamente nos estados como novas 'augmentations'. Quando o conteúdo da 'jug', no exemplo, muda então esta regra 'elaborate' vai terirar o valor antigo e lançar o cálculo pro novo valor. >> Proposição de Operadores **Pergunta:** Como funciona o mecanismo de proposição de operadores do Soar ? Execute o exemplo do tutorial 1 e descubra. Documente em seu relatório. **Resposta:** Quando rodamos, os matches acontecerão com o operadores, que serão lançados e aplicados com base nos acceptable operators ("^operator +"). Quando Soar não tem conhecimento para continuar, ele dispara o impasse, chamado de 'tie impasse', e cria um subestado onde ele pode fazer uma solução refletiva de problema (reflective problem solving). No exemplo do tutorial, sugere-se utilizar um operador indiferente 'indifferent operator' para resolver (" operator + ="). Observe o sinal '=' no operador. >> Aplicação de Operadores **Pergunta:** Como o Soar faz para escolher os operadores que devem ser aplicados, a partir das proposições ? Descubra e documente em seu relatório. ** Resposta:** Temos que escrever as regras de aplicação para quando o operador é selecionado. As regras de aplicação podem alterar os estados (direta ou indiretamente), essas mudanças vão reiniciar o operador selecionado, as mudanças também geram novos matches e novas propostas de regras e assim a diante. Importante observar que o match para alterar de um atributo "^atributo ", é necessário adicionar o novo ("^atributo X") e remover o anterior ("^atributo -"). >> Monitoramento de Estados e Operadores **Pergunta:** Como é possível monitorar a operação do Soar, na aplicação dos operadores e regras ? Descubra e documente em seu relatório. ** Resposta:** Existem regras de monitoramente, o texto mostra 4 exemplos. Uma coisa boa do Soar é que ele lança essas regras de forma paralela, não interferindo o procedimento de solução. O autor comenta que neste estado a versão já consegue funcionar e pode resolver o problema, mas não saberá informar quando isso aconteceu. >> Reconhecimento do Estado Desejado **Pergunta:** Após executar os operadores, o Soar cria novos estados. Como reconhecer que se chegou a um estado desejado ? Como o Soar faz isso ? Descubra, e documente em seu relatório. ** Resposta:** É necessário criar uma regra que detecta o estado em que o objetivo foi alcançado. No texto, o autor dá uma solução rápida e direta. Em seguida, ele comenta que é mais interessante criar uma representação do estado desejado na WM. Assim, ele cria na inicialização uma entrada na WM do resultado esperado e adiciona uma produção que identifica se uma das 'jugs' está neste estado, cortando o processamento. >> Controle de Busca **Pergunta:** Como evitar que a proposição de novos operadores e sua escolha aconteça de maneira cega ? Como fazer para que alguns operadores tenham preferência sobre outros ? Como utilizar esse mecanismo no Soar para guiar o processo de busca por um estado-solução ? Descubra e documente em seu relatório. ** Resposta:** No exemplo ele roda 10 vezes e a solução demorou de 4 a 168 decisões para ser resolvido. Para evitar processamentos desnecessários, por exemplo encher e esvaziar a mesma 'jug' seguidamente, existe a possibilidade de controlar o fluxo de decisões, por exemplo, evitando as operações seguidas desnecessárias. Para isso o autor sugere gravar o último operador executado para que o próximo não desfaça o anterior. Para isso, escrevemos regras que detectam um operação já feita e reduzimos a prioridade do próximo estado que iria desfazer a operação, como no exemplo abaixo que reduz a prioridade de esvaziar um 'jug' que acabou de ser enchido: sp {water-jug*select*operator*avoid*inverse*fill (state ^name water-jug ^operator + ^last-operator ) ( ^name fill ^fill-jug ) ( ^name empty ^empty-jug ) --> ( ^operator <)} >> Conclusão **Pergunta:** Quais as conclusões que você pode tirar dos experimentos desenvolvidos na aula de hoje ? Como o Soar se compara com um sistema de processamento de regras convencional, como um sistema especialista ? Quais as semelhanças ? Quais as diferenças ? Especule em seu relatório. **Resposta:** Concluo que o Soar é um sistema de regras como os próprios criadores o identificam apesar de algumas confusões que eles se propõem a clarificar em alguns textos. São semelhantes pelo fato de existir um estado e descrição de manipulações/interpretações/resultados em forma de regras. São diferentes pelo fato do Soar ser paralelo e de memória associativa, lém de ter um mecanismo de decisão baseado em preferências muito útil no caso de um impasse. Além disso, um impasse cria um sub-problema a ser resolvido, e a solução dele passa a integrar a base de conhecimento em execução.