Aula 08 - CLARION

Introdução ao CLARION [The CLARION Project]

CLARION (Connectionist Learning with Adaptive Rule Induction ON-line) is a project investigating fundamental structures of the human mind.

Os estudos em torno do CLARION (o que envolve o design do próprio CLARION) estão centrados na formação de uma estrutura (considera-se que há uma estrutura) que capture diferentes processos cognitivos para servir de modelo (no mesmo sentido so Soar, ACT-R, LIDA e CogSys) explicativo de uma variedade de fenômenos relacionados à cognição humana. O encaminhamento do projeto CLARION considera dois escopos:

1. O desenvolvimento de agentes inteligentes para a realização de determinadas tarefas cognitivas em domínios específicos.
2. A compreensão de processos associados a tomadas de decisão, aprendizado, raciocínio, motivação e meta-cognição em diferentes domínios.

Apresentação

O texto que se segue é um excerto do Tutorial  (em The CLARION cognitive architecture project) e de explicações fornecidas nas video apresentações do grupo de estudo [The CLARION Library]. Esta apresentação serve de base para as atividades da Aula 10. Desse modo, deixamos alguns aspectos técnicos sobre o uso do framework CLARION para serem abordados no desenvolvimento do agente CLARION-WS3D. 

O CLARION é uma arquitetura cognitiva de processo (aprendizado) e representação duais, dualidade  centrada na distinção entre formas cognitivas (formas de conhecimento) implícitas e explícitas. A principal distinção entre as duas formas de conhecimento está no acesso: o conhecimento explícito é tido como de fácil acesso e o implícito de difícil acesso. De fato, o acesso também envolve a estrutura onde tais conhecimentos subsistem (existem (a partir de sua represenação), são (em sua forma de representação), persistem (em sua forma), estão (como representados)): o conhecimento explícito é mantido no nível superior (top level) de cada subsistema que compõe o CLARION, o conhecimento implícito está no nível inferior (bottom level). Esse foco na distinção entre conhecimento implícito e explícito é a base para caracterizar a noção de aprendizado. Por exemplo, a ocorrência do aprendizado chamado de bottom-up está na transformação do conhecimento implícito em conhecimento explícito (essa é uma das caracteríticas que diferenciam o CLARION de outras arquiteturas cognitivas). Essa formulação da noção de aprendizado permite que tal processo (em contextos definidos) possa ser capturado, mensurado e explicado (aspectos que interessam diversos ramos da psicologia cognitiva: cujo método primário são experimentos com participantes humanos, apesar do interesse em construções de teorias e modelos baseados em experimentos computacionais).

Assim como a representação do conhecimento (que identifica o conhecimento em si) está subdivida em cada um dos subsistemas do CLARION, o processo de aprendizado também subsiste em partes diferenciadas: em top e bottom level. No bottom level, associações implícitas são efetivadas ("aprendidas") por meio de tentativa-e-erro (o processo é capturado por aprendizado associativo (de contraste hebbiano). No top level o conhecimento é explicitado (declarado) pela linguagem (estrutura sintático-semântica) do CLARION (na forma de regras de aprendizado).  

Estruturalmente o CLARION é composto de quatro subsistemas o Action-Centered Subsystem (ACS), o Non-Action-Centered Subsystem (NACS), o Meta-Cognitive Subsystem (MCS)  e o  Motivational Subsystem (MS). A figura abaixo mostra o esquema de integração desses quatro subsistemas:

OBS.: Antes de prosseguirmos destacamos o uso de alguns temos na arquitetura CLARION

• Component: objeto interno (i.e., funcional) que define como os níveis superior e inferior (top e bottom levels) dos subsistemas nos agentes operam. Na biblioteca CLARION a classe das componentes (e component templates) é a ClarionComponent (localizada no namespace Clarion.Framework.Templates).
• Implicit Component: componente do nível inferior (bottom level). A classe correspondente é a ImplicitComponent  localizada no namespace Clarion.Framework.Templates.
• Rule: componente do nível superior. A classe correspondente é Rule localizada no namespace Clarion.Framework.Templates.
• Drive: é uma componente especial do nível inferior do subsistema MS. A classe correspondente a Drive também localizada no namespace Clarion.Framework.Templates.
• Module: O MCS não é exatamente um subsistema (per se) e, em termos técnicos, não possui a identificação por níveis superior e inferior (top e bottom level).  De fato, é um "container de módulos meta-cognitivos" onde cada módulo possui os níveis superior e inferior. Esses módulos atuam como mini ACSs, possuem muitas das mesmas características de um  ACS.
  • Todos os módulos meta-cognitivos são extensões da classe MetaCognitiveModule (localizada no namespace Clarion.Framework.Templates).

O ACS está envolvido com os processos de tomadas de decisão (processos do sistema de controle) que controlam ações físicas (ações externas) e mentais (manipulação da memória de trabalho: working memory actions) e adequações referentes às metas (goal actions). Mais especificamente, o ACS produz recomendações, a partir dos dados de entrada, para a escolha da "melhor" ação a ser escolhida. O NACS, usualmente um sistema escravo do ACS, é utilizado para armazenar conhecimento declarativo e episódico: é o motor raciocínio do CLARION (a camada (nível) superior do NACS faz uso de regras lógicas enquanto a inferior utiliza uma rede neural não-linear). O MS mantém o nível de  orientação motivacional relacionado às metas. O MCS monitora a cognição (ou alguns aspectos da cognição) no ACS e NACS, mantendo o direcionamento da meta conforme os níveis motivacionais determinados pelo MS. O MS contém direcionamentos que levam em consideração fatores externos (capturados do ambiente) e internos (digamos, estados motivacionais), tais direcionamentos são enviados para o MCS que regula as estruturas relacionadas ao objetivo juntamente com os processos cognitivos que viabilizam alcançar as metas propostas (a figura abaixo mostra o esquema do MS):

Os níveis superior e inferior dos subsistemas não são totalmente genéricos, cada subsistema possui características próprias:

• O ACS é definido pela classe ActionCenteredSubsystem e possui a seguinte estutura:

1. O nível inferior do ACS aguarda componentes que estendem a classe ImplicitComponent (qualquer componente desse nível deve estender essa classe).
2. O nível superior do ACS aceita somente três tipos de regras (deixamos os termos técnicos no original): refineable action rules, IRL rules, e fixed rules (o acrônimo IRL é de Independent Rule Learning). Qualquer componente desse nível deve estender a classe RefineableActionRule, IRLRule, ou FixedRule (todas no namespace Clarion.Framework).

• O NACS, definido pela classe NonActionCenteredSubsystem, tem a seguinte estrutura:

1. O nível inferior do NACS, assim como o nível inferior do ACS, aguarda componentes que estendem a classe ImplicitComponent.
2. O nível superior do NACS espera componentes que estendem a classe AssociativeRule (localizada no namespace Clarion.Framework.Templates).

• O MS é definido pela classe MotivationalSubsystem e segue a estrutura descrita abaixo:

1.  O nível inferior do MS é formado por componentes que derivam da classe Drive. A própria classe Drive guarda componentes que estendem a classe ImplicitComponent.
2. O nível superior do MS, diferentemente dos outros subsistemas, não contém componentes. De fato, o nível superior do MS contém metas (goals).

• O MCS, apesar de ser definido pela classe MetaCognitiveSubsystem, possui todas as suas funcionalidades definidas pelas classes MetaCognitiveModule. Cada módulo tem a seguinte estrutura:

1. O nível inferior de um módulo meta-cognitivo é essencialmente como o nível inferior do ACS: possui componentes que estendem a classe ImplicitComponent (qualquer componente desse nível de um módulo meta-cognitivo deve estender essa classe).
2. O nível superior do módulo meta-cognitive também é similar ao nível superior do ACS, exceto pelo fato de apenas um único tipo de regra ser aceito: refineable action rules  (qualquer componente desse nível de um módulo meta-cognitivo deve estender a classe RefineableActionRule.

Esquematicamente, temos a seguinte estrutura de comunicação entre os níveis inferiores e superiores do ACS e NACS:

É no nível superior do NACS onde são implementados os chunks. São estruturas de dados da forma:

Chunk-ID_i : (Dim_i1, Val_i1), (Dim_i2, Val_i2), ... , (Dim_in, Val_in).

São coleções de DV-pares que representam ou condições ou ações (no top level). Chunks são usados para codificar informações, por exemplo, sobre o estado de um agente.

Para cada chunk criado há um nó criado no Generalized Knowledge Story (GKS), localizado no nível superior do NACS, contendo ponteiros  para uma estrutura de dados no nível inferior que representa os valores das dimensões  dos chunks. Desse modo, cada chunk (conceito: um nó no nível superior) é representado por suas micro-características (nós no nível inferior) e podem ocorrer duas formas possíveis de interações de ativações: uma top-down (chunks na camada explícita ativam a representação na camada implícita referente ao mesmo chunks) e outra bottom-up (chunks na camada implícito ativam representação referente ao mesmo chunks). A figura abaixo mostra as relações entre as partes envolvidasd num processo de decisão.

As entradas (world state nodes) são comparadas com os DV-pares (condition nodes) de uma regra no nível inferior, se a ocorrer o match, então as condition nodes ativam o condition chunk (no nível superior) que, por sua vez, ativam o conclusion chunk (que no caso da figura é uma recomendação).  Como mostra a figura, o condition chunk e o conclusion chunk (action chunk) estão ligados na forma de uma regra (um action chunk atua como um operador no Soar).

• As interações entre níveis podem ocorrer por seleção estocásticas ou por combinação (retificação bottom-up, orientação top-down); envolvem uma rede no nível inferior e um grupo de regras no nível superior. Conclusões positivas  (resp., negativas) alcançadas no nível superior podem indicar recomendações (respec., vetar) de ação no nível inferior.
  • Retificação bottom-up: a saída do nível inferior é enviada para o nível superior que, com base no conhecimento armazenado, faz a devida retificação para ser utilizada.  
  • Orientação top-down (TD-Guidance): a saída do nível superior é enviada para o nível inferior que, com base no conhecimento armazenado, a utiliza para decidir sobre a ação final.

O ciclo operacional no ACS começa com a observação  do estado corrente:

• o estado corrente é representado por DV-pares: (dim₁, val₁) ...  (dim_n, val_n). Cada par corresponde a um nó de entrada na rede  IDN. As entradas fornecem "um descrição do estado do mundo" e são de três tipos: Sensory Input (visual, sonoro, etc), Working Memory Itens (vide seção mais adiante) e Goal Structure Itens (vide seção mais adiante).  O nível de ativação do nó é dado pelo quociente abaixo: 

onde x_i é o valor da entrada i (do nó), w_i é o peso da entrada e n é o número de entradas do nó.  

segue com o processamento no nível inferior (em que se determina uma ação);

• a escolha de uma ação é baseada na distribuição de Boltzman das ativações dos nós da camadas de saída. Isto é,  a probabilidade, P(chunk j), de um chunk j ser selecionado como saída do ACS é estocasticamente calculado por: 

onde s_j é a ativação do chunk j e alfa é um parâmetro que representa o grau de randomicidade. Veja [ aqui ] para maiores detalhes. 

• ações são representadas como nós na camada de saída, são de três tipos: WorkingMemoryActions, GoalActions, ExternalActions. Cada ação é formada por uma ou mais ActionDimensions: (dim₁, val₁) ...  (dim_n, val_n). A figura abaixo mostra o esquema de escolha da ação de saída no nível inferior (bbottom level):

com o processamento no nível superior (que também determina uma ação), passa para a seleção de uma ação apropriada combinando as ações  derivadas dos níveis inferior e superior; prossegue com a execução da ação selecionada e observação do próximo estado e, finalmente, o processamento do aprendizado nos níveis inferior e superior.

• A aprendizagem no nível inferior do ACS é baseada em backpropagation para realizar a correção do erro na IDN: são três métodos: Standard Backpropagation; Q-Learning (reinforcement learning) e Simplified Q-Learning. No nível superior, também temos três métodos: RER (Bottom-Up Rule Extraction and Refinement): pares condição-ação são extraídos do nível inferior e refinados; IRL (Independent Rule Learning): regras de várias formas são geradas de maneira independente e então refinadas ou deletadas e FR (Fixed Rule): regras são obtidas de experiências anteriores, ou fornecidas por fontes externas.

• Na arquitetura CLARION, a memória de curto prazo (Working Memory - WM)  atua como meio entre os processos cognitivos e a memória de longo prazo ( Long Term Memory- LTM). A WM é uma área temporária de armazenamento dos dados para uso dos módulos action-centered. Apesar da WM ser considerado como parte do ACS é, de fato, um sistema separado. A WM interage com a memória de longo prazo (pega pedaços de informações contidas na LTM, armazena, utiliza e as remove da WM).

  Similar à memória de curto prazo em humanos, a WM no CLARION está sujeita a um fator de decaimento, com o passar do tempo os itens não utilizados são removidos. Um elemento na WM pode ser mantido se for ativo na memória (alvo das working memory actions). Na arquitetura CLARION, a WM em papel específico: é usada unicamente para ações de tomadas de decisão, não atua como memória de acesso geral (general memory access).

A seguir apresentamos formas de uso dessas subsistemas que compõem o CLARION em experimentos computacionais: implementações usando as componentes da biblioteca CLARION. Iniciamos com o clássico Hello World sob a perspectiva CLARION.  

Um Hello-World sob a perspectiva CLARION

O clássico Hello World ganha a seguinte roupagem no CLARION:

If someone says “hello” or “goodbye” to me, 
then I should respond with either “hello” or “goodbye” respectively.
                          

A construção acima considera a necessidade de um mundo (um lugar num dado tempo), de um personagem (algo capaz de atuar nesse mundo), de um contexto (a ação de dizer "Hello" é situada) e de uma motivação (impulsiona o personagem à adequação ao contexto). Todos esses elementos, em geral,  fazem parte de uma codificação CLARION (abaixo um roteiro geral para implementar um ambiente de simulação CLARION): 

1. Descrever o mundo: suas características e seus objetos 
2. Definir as ações e motivações (goals) que irão conduzir a forma como os agentes irão interagir no mundo
3. Criar os agentes: ativar nos agentes as funções internas para que possam perceber o mundo e tomar decisões adequadas ao papel a que foram criados.

Após a elaboração do cenário (do mundo e seus elementos), atores e seus respectivos papéis num dado contexto e enredo é necessário traduzir tudo isso sob a estrutura do CLARION. Abaixo mostramos um resumo dos recursos que o CLARION oferece (como biblioteca).

A figura acima mostra o esquema hierárquico dos namespaces da biblioteca CLARION, a lista completa de todas as classes (com dada namespace) está disponível na pasta documentation que acompanha o pacote CLARION: que encontra-se organizado como segue:

• Clarion – O namespace base da biblioteca CLARION. Contém três classes: World, AgentInitializer e ImplicitComponentInitializer.
• Clarion.Framework – Este namespace contém a maioria das classes necessárias para cirar e executar uma simulação. São classes diretamente relacionadas aos conceitos e termos do  CLARION como modelo da cognição humana. 
• Clarion.Framework.Core – Como o nome diz, este namespace contém o núcleo operacional  do sistema.
•  Clarion.Framework.Extensions Neste namespace estão as extensões (p.ex., os módulos de meta-cognição). São classes que não são necessariamente especificados no CLARION como teoria, porém podem ser utilizado da mesma forma como as classes dm  Clarion.Framework.
• Clarion.Framework.Templates – Este namespace contém as classes abstratas, interfaces e delegadas, que atuam como "templates" para a construção de objetos (p.ex., componentes implícitas, drives, etc).
• Clarion.Plugins – Neste namespace temos diversos plugins e ferramentas para construções de simulações baseados em agentes.
• Clarion.Samples – Este namespace contém exemplos de ambientes de simulação que servem como guias para os iniciantes no uso da biblioteca (e teoria) CLARION. De fato, este namespace é um apêndice da biblioteca CLARION. 

A figura abaixo mostra um esquema com as principais classes do framework.

Alguns dos elementos da figura acima e outros são apresentados ao longo do exemplo Hello-World que iniciamos aqui (em C# via MonoDevelop) com a inclusão dos namespaces. OBS.: veja [ aqui ] uma discussão sobre as vantagens e desvantagens do C# em comparação com o JAVA (base do Soar). 

A codificação do HelloWorld no CLARION segue o esquema abaixo: o primeiro bloco mostra as bibliotecas utilizadas e o segundo bloco exibe o esqueleto do código. 

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.IO;
using System.Threading;
using System.Diagnostics;
using Clarion;
using Clarion.Framework;

namespace Clarion.Samples {
    public class HelloWorldSimple {
        static void Main(string[] args) {

            //Initialize the task
            Console.WriteLine("Initializing the Simple Hello World Task");
            ...

            //Initialize the Agent
            Agent John = World.NewAgent("John");
            ... 

            //Run the task
            Console.WriteLine("Running the Simple Hello World Task");
            ... 

            a implementação propriamente dita ... 

            //Report Results
            Console.WriteLine("Reporting Results for the Hello World Task");
            ...

            //Kill the agent to end the task
            Console.WriteLine("Killing John to end the program");
            John.Die();
            ...
 
        }
    }
}

As primeira bibliotecas (System) tratam de classes do .NET Framwork, as duas últimas contém as classes: World, AgentInitializer, ImplicitComponentInitializer e outras diretamente relacionadas aos conceitos e termos do  CLARION como modelo da cognição humana. A seguir detalhamos as partes que compõem o esqueleto acima. 

Após a declaração do namespace (Clarion.Samples) temos a classe principal (SimpleHelloWorld) que contém todo código da simulação: as inicializações do mundo e do agente e os mecanismos que permitem a interação do agente com o mundo (tudo isso num único método: Main). 

Iniciamos com o bloco referente à inicialização das variáveis globais, configuração do dispositivo de saída (um arquivo texto chamado HelloWorldSimple) e um valor para o LoggingLevel (o valor padrão é on: ativa o serviço de trace para verificar as ocorrências internas ao agente CLARION). 

//Initialize the task
Console.WriteLine("Initializing the Simple Hello World Task");

int CorrectCounter = 0;
int NumberTrials = 10000;
int progress = 0;

World.LoggingLevel = TraceLevel.Off;

TextWriter orig = Console.Out;
StreamWriter sw = File.CreateText("HelloWorldSimple.txt");

DimensionValuePair hi = World.NewDimensionValuePair("Salutation", "Hello");
DimensionValuePair bye = World.NewDimensionValuePair("Salutation", "Goodbye");

ExternalActionChunk sayHi = World.NewExternalActionChunk("Hello");
ExternalActionChunk sayBye = World.NewExternalActionChunk("Goodbye"); 

Os elementos que compõem o mundo (onde ocorre a simulação) são estabelecidos pela codificação abaixo (são chamados de  Dimension-Value pairs ou DV pairs):

DimensionValuePair hi = World.NewDimensionValuePair("Salutation", "Hello");
DimensionValuePair bye = World.NewDimensionValuePair("Salutation", "Goodbye");

Neste caso, os elementos são identificados pelos pares ("Salutation", "Hello") e ("Salutation", "Goodbye").  Uma vez estabelecida a existência dos DV-pairs no mundo é necessário definir o conjunto de ações associado a tais elementos. A ligação entre ações e objetos é declarada usando o método ExternalActionChunk.

ExternalActionChunk sayHi = World.NewExternalActionChunk("Hello");
ExternalActionChunk sayBye = World.NewExternalActionChunk("Goodbye"); 

A codificação acima determina a forma de atuação do agente, neste caso: o agente na presença de  uma saudação (Salutation) responde com Hello ou Goodbye.

O outro objeto cuja existência também precisa ser declarada (pelo método NewAgent) é o agente, neste caso rotulado de John (rótulo do agente é passado para o método). Tecnicamente, o agente é como outro objeto qualquer e o uso do rótulo é opcional; necessário nos casos em que o agente é requisitado posteriormente (em algum lugar da simulação). A declaração de existência do agente não lhe confere nenhum tipo de conhecimento prévio (não possui nenhuma informação sobre os DV-pairs). Também não possui nenhuma funcionalidade que permita ao agente interagir no mundo.

//Initialize the Agent
Agent John = World.NewAgent("John");

SimplifiedQBPNetwork net = AgentInitializer.InitializeImplicitDecisionNetwork(
                             John, 
                             SimplifiedQBPNetwork.Factory
                           );

net.Input.Add(hi);
net.Input.Add(bye);

net.Output.Add(sayHi);
net.Output.Add(sayBye);

John.Commit(net);

Parte das funcionalidades do agente são determinadas pela Implicit Decision Network (IDN), componente do ACS localizada no bottom level, que é inicializado com uma versão simplificada do Q-learning backpropagation network (SimplifiedQBPNetwork): a rede IDN é acoplada ao agente (neste caso, a rede não pode ser usada por outro agente) e gerada por padrões em Factory. SimplifiedQBPNetwork.Factory fornece os elementos básicos para a criação da SimplifiedQBPNetwork no bottom level no ACS. InitializeImplicitDecisionNetwork retorna uma componete  implícita (do tipo especificado em Factory). Outras informações iniciais são colocadas: os elementos de entrada  e saída da rede (as  ações que o agente pode executar de acordo com as informações que ele captura do mundo).

net.Input.Add(hi);
net.Input.Add(bye);

net.Output.Add(sayHi);
net.Output.Add(sayBye);

Com a codificação finalizamos a inicialização da IDN. Após a fase de incialização o agente deve ser mantido como é, ou seja, deve ser imutável: 

John.Commit(net);

Estabelecido os elementos de cena determinamos a dinâmica da simulação:

• especificar a informação capturada durante um ciclo percepção-ação
• registrar o comportamento do agente (as ações que ele escolheu)
• atualizar o estado do mundo de acordo com as ações praticadas pelo agente
• fornecer feedback para o agente sobre ações "bem sucedidas" e "mal sucedidas".
• rastrear a performance do agente (para relatórios finais)

A dinâmica do agente para o Hello World sergue o esquema da codificação abaixo: 

//Run the task
Console.WriteLine("Running the Simple Hello World Task");
Console.SetOut(sw);

Random rand = new Random();
SensoryInformation si;

ExternalActionChunk chosen;

for (int i = 0; i < NumberTrials; i++) {     // The major body of the task

    //Randomly choose an input to perceive.
    ...
    //Perceive the sensory information
    ...
    //Choose an action
    ...
    //Deliver appropriate feedback to the agent
    ...
          //The agent responded correctly
          ...
          //Record the agent's success.
          ...
          //Give positive feedback.
          ...
          //The agent responded incorrectly
          ...          
          //Give negative feedback.
          ...

} 

Na implementação usamos um gerador randômico (rand) associado à informação capturada (SensoryInformation) pelo agente e uma variável chamada chosen vinculada à ação escolhida pelo agente. O corpo do programa está no laço for (..).   Cada iteração,  0 <= i < NumberTrials,  corresponde a um ciclo percepção-ação (i.ex., um trial): a captura da informação, a escolha da ação, o registro da ação (armazenada em chosen) e o feedback (descrito mais abaixo). As primeiras etapas do ciclo estão codificadas abaixo:

for (int i = 0; i < NumberTrials; i++) {

    si = World.NewSensoryInformation(John);

    //Randomly choose an input to perceive.
    if (rand.NextDouble() < .5)   {
       //Say "Hello"
        si.Add(hi, John.Parameters.MAX_ACTIVATION);
        si.Add(bye, John.Parameters.MIN_ACTIVATION);
    }
    else {
         //Say "Goodbye"
         si.Add(hi, John.Parameters.MIN_ACTIVATION);
         si.Add(bye, John.Parameters.MAX_ACTIVATION);
    }

    //Perceive the sensory information
    John.Perceive(si);

    //Choose an action
    chosen = John.GetChosenExternalAction(si);

    //Deliver appropriate feedback to the agent
    ...

}
 

Usamos o método NewSensoryInformation que permite ao agente capturar uma informação do mundo, neste caso o agente é John.

    si = World.NewSensoryInformation(John);

Nesta simulação, John percebe "hi" ou "bye" randomicamente (50% contra 50%):

for (int i = 0; i < NumberTrials; i++) {
    ...

    //Randomly choose an input to perceive.
    if (rand.NextDouble() < .5)   {
       //Say "Hello"
        si.Add(hi, John.Parameters.MAX_ACTIVATION);
        si.Add(bye, John.Parameters.MIN_ACTIVATION);
    }
    else {
         //Say "Goodbye"
         si.Add(hi, John.Parameters.MIN_ACTIVATION);
         si.Add(bye, John.Parameters.MAX_ACTIVATION);
    }
    ...

}
 

Feito o sorteio, o agente captura a informação e escolhe uma ação de acordo. O método Perceive dispara o processo de decisão e GetChosenExternalAction retorna a ação escolhida pelo agente (de acordo com a informação capturada).  

for (int i = 0; i < NumberTrials; i++) {
    ...

    //Perceive the sensory information
    John.Perceive(si);

    //Choose an action
    chosen = John.GetChosenExternalAction(si);
    ...

}
 

Após a escolha e registro da ação, ocorre o processo de determinar as "conseqüências" da ação tomada (se a ação escolhida foi "bem sucedida" ou não). Para esta simulação, o processo é simples: basta efetuar uma comparação ("==") entre a ação e o informação capturada e, de acordo com o resultado da compração, dar o feedback para John (isso é feito com o método ReceiveFeedback que dispara um ciclo de aprendizado).

for (int i = 0; i < NumberTrials; i++) {

    ... 

    //Deliver appropriate feedback to the agent
    if (chosen == sayHi) {
       //The agent said "Hello".
       if (si[hi] == John.Parameters.MAX_ACTIVATION) {
          //The agent responded correctly
          Trace.WriteLineIf(World.LoggingSwitch.TraceWarning, "John was correct");
          //Record the agent's success.
          CorrectCounter++;
          //Give positive feedback.
          John.ReceiveFeedback(si, 1.0);
        }
        else {
          //The agent responded incorrectly
          Trace.WriteLineIf(World.LoggingSwitch.TraceWarning,"John was incorrect");         
          //Give negative feedback.
          John.ReceiveFeedback(si, 0.0);
        }
     }
     else {
        //The agent said "Goodbye".
        if (si[bye] == John.Parameters.MAX_ACTIVATION) {
           //The agent responded correctly
           Trace.WriteLineIf(World.LoggingSwitch.TraceWarning, "John was correct");
           //Record the agent's success.
           CorrectCounter++;
           //Give positive feedback.
           John.ReceiveFeedback(si, 1.0);
        }
        else {
          //The agent responded incorrectly
          Trace.WriteLineIf(World.LoggingSwitch.TraceWarning,"John was incorrect");
          //Give negative feedback.
          John.ReceiveFeedback(si, 0.0);
        }
     }
     ... 
}

Terminado o processo de feedback fazemos as atualizações das variáveis para avançar com a simulação.

for (int i = 0; i < NumberTrials; i++) {

    ... 

    //Deliver appropriate feedback to the agent
    if (chosen == sayHi) {
       ... 
     } 
     else { 
       ... 
     }

     Console.SetOut(orig);
     progress = (int)(((double)(i+1) / (double)NumberTrials) * 100);
     Console.CursorLeft = 0;
     Console.Write(progress + "% Complete..");
     Console.SetOut(sw);
}

Após a execução do programa (fim dos ciclos de percepção-ação), algumas informações sobre a simulação são publicadas.

//Report Results
Console.WriteLine("Reporting Results for the Simple Hello World Task");
Console.WriteLine("John got " + CorrectCounter + 
                  " correct out of " + NumberTrials + 
                  " trials (" + 
                  (int)Math.Round(((double)CorrectCounter / (double)NumberTrials) 
                  * 100) + "%)");

Console.WriteLine("At the end of the task, John had learned the following rules:");
foreach (var i in John.GetInternals(Agent.InternalContainers.ACTION_RULES))
Console.WriteLine(i);

sw.Close();
Console.SetOut(orig);
Console.CursorLeft = 0;
Console.WriteLine("100% Complete..");

Resta, como último passo, eliminar o agente: John.Die().

//Kill the agent to end the task
Console.WriteLine("Killing John to end the program");
John.Die();
Console.WriteLine("John is Dead");

Console.WriteLine("The Simple Hello World Task has finished");
Console.WriteLine("The results have been saved to \"HelloWorldSimple.txt\"");
Console.Write("Press any key to exit");
Console.ReadKey(true);

A codificação acima exibe os passos necessários para o término da simulação (e do agente). Os comandos de finalização evitam que alguns processos continuem ativos mesmo com o término da simulação.

A Estrutura de Meta (Goal Structure)

Processos dedicados à resolução de tarefas complexas, em geral, necessitam de um mecanismo de direcionamento para o objetivo em questão, para identificar se o objetivo foi alcançado ou não, para gerenciar múltiplos sub-objetivos e objetivos. Uma goal structure é uma estrutura que serve para guiar as ações (goal actions) do agente de modo construtivo. O ACS é o subsistema que lida diretamente com a goal structure através das goal actions. A goal structure é um sistema separado, porém pode ser considerado parte do ACS; análogo à WM. 

Em termos de estrutura abstrata de dados, a goal structure pode ser implementada como uma lista (mais precisamente, uma lista encadeada).  Uma lista de metas (ou goal list) é uma estrutura linear e a alteração de sua forma depende unicamente de uma goal action: o acesso a um goal item (elemento da lista) não possui restrições: p.ex., se a estrutura de dados fosse uma pilha: o acesso ao objetivo corrente (current goal) só seria possível pelo topo da pilha (como ocorre com a Goal Stack).  A implementação da goal estructure em forma de lista não possui as restrições operacionais de uma pilha, é possível efetuar alteração na lista de objetivos de maneira mais próxima ao modo com que as pessoas usualmente fazem: se cumprir o objetivo, basta removê-la da lista, se não cumprir o objetivo, então faz um rearranjo dos objetivos, pode-se arranjar os objetivos conforme o desejo do agente de simplesmente cumprir (atender um drive do MS) o objetivo ou pela necessidade de fazê-lo (decorrente de um raciocínio: processo do topo level do NACS).

Raciocínio e Aprendizado no CLARION

Raciocínio no CLARION

No CLARION, o processo de raciocínio move (via regras associativas (associative rules) e chunks) o conhecimento estabelecido em novas formulações por meio das relações que associam suas diferentes representações internalizadas na arquitetura cognitiva. O processo tem início com a entrada de dados no NACS, dependendo do tipo de entrada os dados são enviado para o nível superior ou inferior. A figura abaixo mostra o esquema do NACS:

Chunks enviados como entrada ativam chunks no GKS onde DV-pares ativam outros pares DV nas redes de memória associativa (Associative Memory Networks - AMN). Uma entrada, seja para o GKS ou para o AMN, ativa chunks ou  DV-pares nos dois níveis do NACS.  Regras associativas (no nível superior) relacionam chunks com outros chunks na forma de um encadeamento para frente (forward chaining reasoning). Essa etapa do raciocínio termina com a determinação de chunks (no top level via regras) e DV-pares (no bottom level via rede). O passo seguinte tem início com os conclusions chunks (vide esquema [ aqui ]) ativando os respectivos DV-pares do nível inferior e os DV-pares ativando os respectivos chunks no top level. O processo se reprete a cada entrada de novos chunks e DV-pares.

O CLARION possui um método opcional de raciocíno chamado similarity-based reasoning. Neste tipo de raciocínio um chunk é  comparado com outro chunk, se são suficientemente similares, então diz-se que um chunk infere o outro (ocorre uma associação entre esses chunks). Esse processo ativa certos chunks a partir da aplicação do raciocínio juntamente com a ativação dos chunks associados. Nessa forma de inferência o escopo das conclusões é mais abrangente que a forma usual de raciocínio.

Aprendizado no CLARION

A estrutura do NACS (vide figura acima) sugere duas formas de apendizado. No nível superior, o conhecimento explícito pode ser codificado baseado em informação externa ao agente (p.ex., informação  capturada por algum sensor, enviada para o ACS que a codifica e armazena na memória). Outra forma de conhecimento explícito é aquela derivada nas redes do nível inferior. Conhecimento que leva ao aprendizado bottom-up: decorrente das conexões entre entrada (DV-pares) e saída (DV-pares) estabelecidas pelas AMNs. Esse processo, como apresentado anteriormente - vide esquema [ aqui ], cria associações entre chunks do nível superior (no GKS) que estão associados a outros DV-pares do nível inferior. O aprendizado, qualquer que seja a forma, guarda lições (conhecimentos) sobre os estados e ações experienciadas pelo agente que interferem em futuros processos de tomadas de decisão.

O conhecimento sobre as experiências do agente (ou o aprendizado sobre o conhecimento declarativo implícito - learning of implicit declarative knowledge) requer um tipo especial de memória, a memória episódica. Este tipo de memória armazena informações, por exemplo,  sobre como certas ações e metas se relacionam. Note-se que a LTM armazena representações simbólicas de objetos (ou conceitos) sem preocupação com um contexto, na memória episódica informações relacionadas ao como e quando são relevantes; segundo Ron Sun: “we feel that the distinction between episodic memory and semantic memory in CLARION is justified, because of the need to separate knowledge regarding specific experience and knowledge that is more generic and not experience-specific” (A Tutorial on CLARION 5.0., páginas 8-9: último parágrafo).

O Subsistema Motivacional do CLARION

O papel do MS é o de prover ao agente um mecanismo que trate de suas necessidades internas (drives) básicas (p.ex., relativas à sobrevivência), de seus propósitos (p.ex., de conhecer um dado lugar), da atenção (p.ex., manter ou desviar o foco em um dado propósito)  e de sua adaptabilidade (p.ex., relativas aos métodos de aprendizado). No MS (veja um diagrama do MS aqui) os drives orientam as necessidades, por exemplo, eles atuam no processo de raciocínio subjacente à escolha das ações (comportamento) do agente (há uma razão (motivo) pelas escolhas feitas).

Há uma hierarquia entre drives, alguns drives são mais importantes que outros: quanto mais alto na hierarquia maior a prioridade de satisfazer a necessidade que representa, desde que rspetiradas algumas especificações:.

•  Ativação Proporcional: a ativação de um drive deve ser proporcional a existência (ou ausência) de recursos;
• Oportunismo: o agente deve considerar a oportunidade de se mudar o comportamento diante do surgimento de um recurso;
• Contiguidade das ações: o agente não deve ficar mudando de objetivo o tempo todo;
• Persistência: após satisfazer um drive, o agente deve persistir durante um tempo, até um certo nível de satisfação;
• Interrupção em urgências: drives mais urgentes podem interromper outros de menor prioridade;
• Combinação de Preferências: Satisfazer diversos drives simultaneamente, com menos efetividade deve ser preferível a satisfazer um único drive com maior efetividade.

Evidentemente, para atender a um determinado drive, o objeto requerido pelo drive deve estar disponível, isto é, não adianta escolher uma meta para satisfazer uma dada necessidade se o objeto requerido não  estiver presente. Assim, é razoável poder escolher diferentes objetivos. Note-se que múltiplos drives podem estar ativados ao mesmo tempo, porém  apenas uma meta pode ser perseguida a cada instante. 

O Módulo Meta-Cognitivo do CLARION

O módulo meta-cognitivo é o responsável pelo controle da cognição: coordena atividades dos outros subsistemas;  monitora a passagem de informações entre os subsistemas; faz ajustes em todos os subsistemas; altera o estado de atenção do agente; determina os objetivos e reforça o comportamento do agente (é o MCS que determina quais objetivos adicionar na goal structure em resposta aos drives do subsistema motivacional). A figura abaixo mostra o esquema em que se enquadra o MCS: 

Um dos papéis do MSC é atuar como filtro de informações quando estes são passados de um subsistema a outro. A filtragem é feita  suprimindo certas dimensões dos DV-pares, na prática basta remover (alterar o nível da) a ativação fornecida para o nó correspondente (também é possível aumentar o nível de ativação). As decisões sobre a filtragem são feitas com base em informações recolhidas da WM, do estado corrente e drives do MS. Esse processo de filtrar informações é um modo do MCS direcionar a cognição (uma maneira de centrar o foco nas informações relevantes)

Na interação do ACS e NACS, quando uma memory action (ocorrência no ACS) é disparada, é o MCS que trasnfere a  informação para o NACS. Em relação à aprendizagem, é o MCS que determina qual o método de aprendizagem deve ser utilizado e quando aplicar. Além disso, o MCS estabelece (ajusta) os parâmetros de ação de cada um dos subsistemas em separado, desse modo pode modificar processos individualmente aumentando a eficiência do sistema como um todo. A idéia do MCS de controlar as atividades dos subsistemas individualmente de modo que possa coordená-los visa tornar o CLARION um modelo efetivo de cognição.

Considerações

Um forma de avaliar as potencialidades da arquitetura CLARION como modelo da cognição humana é pela construção de simulações envolvendo agentes em situações que exigem resoluções de tarefas complexas (que exigem raciocínio,  aprendizado, planejamento em ambientes dinâmicos) de forma autônoma (em cenários em que o agente interage em tempo real com o ambiente). A partir das avaliações de tais simulações (mais especificamente, do comportamentos dos agentes) seria possível mensurar as características da arquitetura CLARION em relação a aspectos da cognição humana. Um dos setores que podem contribuir para produzir tais cenários para as simulações é o de jogos de computador (e.g., jogos de estratégia em tempo real).

Mencionamos aqui apenas dois aspectos que distinguem o CLARION do Soar. Como parte do design da arquitetura cognitiva o CLARION integra o uso de técnicas de redes neurais com sistemas baseados em "regras"; o Soar não faz uso de redes neurais na concepção de sua arquitetura. Como ferramenta de implementação o CLARION é uma biblioteca de recursos que, aparentemente,  oferece maior grau de liberdade que a utilização do Soar como plataforma de implementação de agentes cognitivos.