In un’architettura cognitiva schema-based la mente non è un programma che esegue passi in sequenza, ma un insieme di unità che girano insieme e si contendono una risorsa scarsa: il tempo di calcolo. Modellare quella contesa è un problema di ingegneria del software prima ancora che di scienza cognitiva, e decide se l’architettura resta una teoria su carta o gira davvero.

Il problema

L’intelligenza artificiale classica scompone un agente in moduli che si chiamano a vicenda: il percettore passa al ragionatore, il ragionatore al pianificatore, il pianificatore all’attuatore. È una catena, e una catena ha un ordine. Le architetture a schemi rifiutano quell’ordine. L’idea risale alla schema theory di Michael Arbib: il comportamento nasce dall’interazione di molti schemi percettivi e motori che lavorano in parallelo, ciascuno con una sua attività, senza un direttore d’orchestra che li sequenzia.

Il precedente più netto è il Pandemonium che Oliver Selfridge descrisse nel 1959: una folla di demoni, piccole entità specializzate, che gridano con un’intensità proporzionale a quanto riconoscono qualcosa nell’input; un demone più in alto nella gerarchia ascolta le grida e decide. Riconoscere non è un algoritmo che parte e finisce, ma un livello di clamore che emerge dalla competizione.

Tradurre tutto questo in codice porta a una domanda precisa. Se gli schemi non si chiamano in sequenza ma vivono in parallelo, chi decide quale schema gira adesso e per quanto? In un calcolatore reale i core sono pochi e i thread vanno schedulati. La metafora cognitiva — tante unità che competono — diventa, sotto, un problema di concorrenza e di allocazione delle risorse.

Architettura

La risposta tipica di un runtime schema-based è far girare ogni schema come un’unità concorrente — nella pratica un thread, o un’unità leggera multiplexata su pochi thread — e introdurre una grandezza scalare associata a ciascuno: la sua energia, o livello di attivazione. L’energia non è un dettaglio cosmetico. È la valuta con cui il sistema compra calcolo.

Il meccanismo si regge su tre scelte:

  • Attivazione come risorsa finita. Il sistema dispone di una quantità totale di energia che ridistribuisce continuamente fra gli schemi. Uno schema rilevante per il contesto attira energia; uno irrilevante la perde. La somma resta limitata, quindi attivare qualcosa significa, di fatto, disattivare qualcos’altro.
  • Scheduling pesato dall’attivazione. Il tempo di CPU che uno schema riceve è funzione della sua energia. Non è lo scheduler del sistema operativo a decidere chi conta di più: è lo stato cognitivo a modulare quanto calcolo riceve ciascuna unità. Lo scheduler diventa un attuatore della politica di attenzione.
  • Comunicazione disaccoppiata. Gli schemi non si invocano per nome. Pubblicano e leggono su uno spazio condiviso — una lavagna, nel lessico classico del blackboard model — oppure si scambiano messaggi strutturati. Il disaccoppiamento serve perché l’insieme degli schemi attivi cambia a runtime: non si può cablare a tempo di compilazione una rete di chiamate fra unità che vanno e vengono.

Sopra questo nucleo serve un modo per definire schemi senza riscrivere il runtime ogni volta. Le implementazioni mature affiancano al motore in C++ un linguaggio di descrizione degli schemi e un protocollo di messaggi basato su XML, così che il ricercatore dichiari un nuovo agente come configurazione anziché come codice di sistema. Un’architettura cognitiva a schemi di questo tipo, scritta in C++ multithread, è stata sviluppata da noze nel framework A.K.I.R.A. all’interno del progetto europeo MindRACES: https://www.noze.it/open-source/akira/.

Il punto critico

Il punto difficile non è far partire i thread: è la politica di ridistribuzione dell’energia. Da quella politica dipende il comportamento osservabile dell’intero sistema, e la politica giusta non si deriva dalla teoria cognitiva — va sintonizzata.

Tre tensioni la rendono delicata.

La prima è la stabilità. Se l’energia si concentra troppo in fretta su un solo schema, il sistema si fissa e ignora il resto del mondo; se si disperde, nessuno schema raccoglie abbastanza calcolo per concludere qualcosa e l’agente oscilla senza decidere. È lo stesso compromesso fra exploration ed exploitation, qui sotto forma di gestione delle risorse.

La seconda è il grado di parallelismo. La metafora promette migliaia di schemi simultanei, l’hardware ne regge molti meno. Il numero di thread, il costo dei cambi di contesto e la contesa sui dati condivisi pongono un limite duro a quanto la metafora si avvicina all’implementazione. Una lavagna condivisa è semplice da spiegare ma diventa un collo di bottiglia di lock quando troppi schemi vi scrivono insieme.

La terza è la causalità sfumata. Per decidere quanto attivare uno schema servono giudizi che non sono booleani: quanto questo input somiglia a una preda, quanto quel contesto è pericoloso. Qui rientrano gli strumenti di soft computing — logica fuzzy e fuzzy cognitive maps, le mappe causali sfumate introdotte da Bart Kosko nel 1986 — non come ornamento, ma come modo di calcolare i pesi che alimentano la ridistribuzione di energia. La rete causale fra concetti diventa la funzione che converte percezione in attivazione.

Implicazioni

Se l’attivazione è la risorsa e lo scheduling la segue, una conseguenza progettuale è che il comportamento dell’agente si osserva e si regola dall’esterno guardando l’energia, non leggendo il codice. La traccia di quanto ciascuno schema è stato attivo nel tempo è la spiegazione di cosa l’agente stava facendo: dove ha messo l’attenzione, cosa ha ignorato, quando ha cambiato fuoco. È una forma di trasparenza che nasce dall’architettura, non aggiunta dopo.

Questo conta oltre i mondi virtuali per cui questi framework sono nati. Un sistema fatto di unità che competono per risorse condivise è governabile nella misura in cui quella competizione è osservabile e si possono imporre vincoli: tetti all’energia di certe classi di schemi, priorità non scavalcabili, registrazione di chi ha ottenuto calcolo e quando. Sono le stesse leve che servono quando le unità non sono schemi cognitivi ma processi che agiscono sul mondo. La concorrenza, qui, non è un dettaglio implementativo da nascondere: è il livello su cui si esercita il controllo.

Limiti

Quanto descritto riguarda l’architettura del runtime, non la qualità cognitiva di ciò che il runtime produce. Che gli schemi competano in modo ordinato non dice nulla su quanto siano sensati i comportamenti che emergono: una politica di attivazione stabile può sostenere un agente sciocco quanto uno capace. Resta poi aperto il problema della verifica. Un sistema dove il flusso di controllo emerge dalla competizione e non da un grafo di chiamate fisso è difficile da testare con i metodi del software sequenziale: gli stati raggiungibili dipendono da una grandezza continua che si ridistribuisce, e riprodurre un comportamento richiede di riprodurre l’intera traiettoria dell’energia. Lo scarto fra la promessa della metafora — migliaia di schemi liberi — e l’hardware che la esegue non si chiude con un’astrazione più elegante: si paga in thread, in lock e in tempo di calcolo.

Immagine di copertina: logo del progetto A.K.I.R.A. (noze).