====== Modification de luminosité dans une pièce: Découverte de pattern sensorimoteur par deux objets ======
Ce scénario reprend le principe de //flux d'instances d'évènements// entre
les différents avatars définit dans [[scenario-nocaptor | une réflexion
sur la création de pattern pour un objet sans capteur]].
===== Introduction =====
==== Les objets ====
Dans une même pièce se trouve :
* Un système d'éclairage (lampe), avec interrupteur et capteur de luminosité.
* Une fenêtre équipée d'un store électrique, avec un interrupteur permettant de faire monter ou descendre plus ou moins le store (pas de capteur de luminosité).
==== La routine de travail de Billy ====
Billy, notre utilisateur, se lève et se rend dans son bureau. Faisant encore
nuit, Billy allume la lumière, il est 6h.
Vers 8h Billy sait qu'il fait jour dehors, il éteint donc la lumière et ouvre
en grand les stores électrique de sa fenêtre.
Ceux-ci reste ouvert jusqu'à ce que, vers 19h, Billy se rende compte
que le soleil se couche. Billy allume donc la lumière de son bureau,
puis ferme les stores.
Billy reste ensuite dans son bureau jusqu'à 22h, il éteint alors la lumière
avant de partir.
(oui, Billy travaille beaucoup plus qu'il ne le devrait).
L'action se déroule dans le bureau de notre utilisateur, Billy,
et ce durant plusieurs semaines.
==== Les variables d'entrée du système ====
Au départ de ce scénario, les avatars n'ont pas encore identifiés de pattern
récurrents, il n'existe donc pas encore de variables internes (ou de **flux
d'instances**), uniquement des variables d'entrées continues correspondant aux
capteurs et actionneurs des objets.
* Pour le système d'éclairage les variables d'entrées sont :
- l'état de l'interrupteur du système d'éclairage, que nous nommeront V1:1.
- l'intensité lumineuse de la pièce, nommée V1:2.
* Pour la fenêtre équipée d'un store électrique :
- l'état de l'actionneur de store, nommée V2:1 (-1 : descendre le store, 1 : monter le store, 0 : sinon).
- Pourcentage d'ouverture du store, nommée V2:2 (allant de 0, le store est fermé, à 1 le store est ouvert).
En se basant sur les actions de Billy, décrites précédemment,
nous pouvons supposer que les variables d'entrée du système
d'objets connectés varieraient, plus ou moins, comme présenté
sur les graphiques ci-dessous.
{{wiki:rplot_all_scenario_lum.png}}
Le but étant de voir comment le système
d'éclairage et le store pourraient arriver
à faire la relation entre la levée du store
et l'augmentation de luminosité, via leurs échanges.
{{wiki:rplot_v12_v22_relation.png}}
===== Système d'apprentissage (point de vue du système d'éclairage) =====
Nous allons voir dans cette partie le fonctionnement
du système d'apprentissage, en prenant le point de
vue de l'avatar du système d'éclairage.
Le système d'apprentissage est basé sur un système multi agents
qui arriveront, par leurs interactions, d'extraire des motifs
pertinents pour les interactions des avatars entre eux.
De plus il utilise un système de flux d'évènements lui permettant
d'échanger des informations avec les systèmes d'apprentissages des
autres avatars de la société (ici le store).
==== Couples Producteur-Similarité ====
Le système multi agents d'apprentissage implémente
des agents différencié en trois rôles :
* Les agents //Producteur//, qui manipulent des données et tentent d'en créer de nouvelles, ils sont différenciés en deux rôles :
* Les agents **Découper**, qui sont liés aux variables d'entrées du système d'apprentissage (correspondant aux données venant des capteurs et actionneurs de l'objet).
* Les agents **Association**, qui sont liés aux flux d'évènements (internes ou externes) et cherchent à associer des évènements provenants de ses flux pour en créer de nouveaux.
* Les agents **Similarité**, qui eux sont toujours liés à un agent //Producteur//, tentent de différencier les types //d'instances d'évènements// et d'identifier les plus pertinents.
Ainsi les agents du système d'apprentissage fonctionnent
toujours en **Couples Producteur-Similarité**.
=== Couple Découper - Similarité (D-S) ===
L'apprentissage de la découpe d'une variable
d'entrée est implémenté par un couple D-S. Leurs
interactions, dont nous allons voir le fonctionnement,
permet de connaître la "pertinence" du découpage
d'une variable en particulier. Ils font varier leurs
paramètres en explorant l'espace de marquage vu précédemment.
== Découpe ==
L'agent Découper d'un couple D-S associé à la variable V2:2
a pour paramètre un Δt qui est la taille de la fenêtre de découpe.
{{wiki:decoupe.png}}
L'agent Découper va alors parcourir la variable d'entrée en faisant
"glisser" sa fenêtre de découpe le long des variations. La fenêtre
peut être simplement glissante, ou bien glissante et suivant les
variations de la variable d'entrée, comme sur l'image ci-dessus.
La portion découpée par l'agent Découper est alors représenté sous
la forme d'un histogramme.
== Similarité ==
Les histogrammes produit par l'agent Découper sont alors récupéré
par l'agent Similarité qui lui associé.
Celui ci compare les nouvelles instances d'évènement avec ceux qu'il
a stocké précédemment, ou plutôt avec l'histogramme représentant la moyenne
de chaque groupe d'instances similaires. Cette "moyenne" peut être considéré
comme un pré-concept d'évènement.
La fonction de comparaison utilisée pour différencier les instances découpées
en une fonction d'intersection entre les deux histogrammes représentant les
instances.
{{wiki:similarite.png}}
Ainsi l'agent Similarité du couple D-S "rangera" les nouvelles instances
d'évènements avec celles qui lui sont le plus similaire, modifiant par la
même la moyenne de ce groupe d'instance. Si aucun groupe n'est trouvé pour
une instance, alors un nouveau lui correspondant sera créé.
le paramètre de l'agent Similarité serait son seuil d'acceptation
de similarité, mais cela reste à confirmer.
=== Couple Association Similarité (A-S) ===
Déterminer l'intérêt d'associer un flux à un autre est
la fonction des couples A-S. Les couples A-S de type
//Explorateur// se déplaçant et marquant l'intérêt des
paramètres testés dans l'espace de marquage.
== Association ==
L'agent Association d'un couple A-S prend pour référence
le flux (interne ou externe) au quel il est affecté dans
l'espace de marquage. Les paramètres de l'agent Association
étant les autres flux auquel il tente d'associer son flux
de référence.
== Similarité ==
Tout comme pour le couple D-S précédemment présenté, l'agent
Similarité va comparer et trier les différentes instances de
l'association.
=== L'espace de marquage ===
A partir des éléments de la section précédente, décrivant les
agents et les couples d'agents, nous pouvons décrire les choix
des paramètres de ces agents comme l'exploration d'un **espace
en trois dimensions** par les couples d'agents.
{{wiki:hemis_marquage.png}}
Ces trois dimensions représentent :
- Les variables ou flux, auquels peuvent se lier les couples.
- Les paramètres possibles de l'agent //Producteur//.
- Les paramètres possibles de l'agent //Similarité//.
Cet **espace en trois dimensions** sert de "mémoire" au
couples du même type qui le **marque** pour se "souvenir" des
paramètres potentiellement intéressants pour une variable
ou un flux, à la manière d'un dépôt de phéromones. Il existe
donc un **espace de marquage** par type de couple (voir plus
si certains agents implémente plusieurs fonctions différentes,
ex. deux espaces pour les couple D-S si les agents Découper
ont deux fonctions de découpe possibles).
Pour les **espaces de marquage**, les couples d'agents se
différencient en deux types : les **Explorateurs** et les
**Exploiteurs**.
== Les explorateurs ==
Comme leurs nom l'indique, ceux sont les couples "bougeant"
le plus dans l'espace de marquage, afin de déterminer
rapidement quels sont les paramètres les plus pertinents
pour une variable donnée.
Les //Explorateurs// commencent par se fixer à une position
fortement marquée (ou aléatoire si aucun marquage), puis se
déplacent en "spiral" jusqu'à trouver une place libre.
Alors ils testent les paramètres un certain temps, marque
l'emplacement de l'intérêt maximum trouvé, puis se redéplacent.
== Les exploiteurs ==
Ce type de couple se fixe sur les emplacements les plus
marqués, peuvent se déplacer légèrement autour et se
"téléporter" d'un emplacement pertinent à un autre.
Les //Exploiteurs// continue de marquer l'intérêt de
l'emplacement, les couples A-S y rajoute un marquage
de prédiction, permettant de donner plus de poids à
un emplacement.
=== Feedback d'intérêt ===
Dans la section précédente nous avons parlé du marquage
d'un intérêt dans **l'espace de marquage**. Celui-ci est
calculé à partir d'un **feedback d'intérêt** dont se sert
les agents Similarité pour classer les instances d'évènement
en groupe, chaque groupe ayant un intérêt, c'est l'intérêt
maximum qui est marqué dans l'espace de recherche aux coordonées
correspondant à la variable et aux paramètres des agents.
L'intérêt est calculé légèrement différemment pour les couple
D-S et A-S.
== L'intérêt intrapersonnel ==
Une découpe de variable, ou une association de flux, est évalué sur
sa capacité à découvrir des motifs pertinents pour soi, sans prendre
en compte autrui. Cet intérêt sert essentiellement au marquage de
n'importe quels évènements captés, que se soit des évènements internes
comme externes.
**L'intérêt intrapersonnel** se calcule à partir de la **spécificité**,
la **précision** et le **poids** des instances évaluées.
Le **poids** d'un type d'instance correspond à son nombre d'occurence
par rapport au
== L'intérêt interpersonnel ==
Pour nuancer le poids de l'intérêt intrapersonnel sur l'intérêt
global d'un évènement, et aussi pour éviter une certaine redondance
des motifs appris par les différents systèmes, un **intérêt
interpersonnel** est calculé.
Cet **intérêt interpersonnel** prend en essentiellement l'aspect
social de l'apprentissage et permet de donner un intérêt plus
fort pour les motifs étant plus pertinents d'indiquer aux autres,
c'est à dire du système (le //moi//) vers les autres systèmes (//autrui//).
L'**intérêt interpersonnel** est calculé à partir du **nombre de
flux/variables internes utilisé(e)s** pour l'élaboration du concept
d'évènement évalué et du **nombre de flux/variables nécessaires** pour
la création d'une instance en fonction du type de couple (1 pour les
couple D-S et 2 pour les couples A-S).
Ainsi cet intérêt permet de donner plus de poids aux évènements n'utilisant
que de flux/variables internes, puis aux évènements associant un flux interne
et externe, et enfin les associations de deux flux externes.
Un autre facteur pouvant être pris en compte est la "direction" du motif
lors d'une association entre un flux interne et un flux externe.
Pour éviter qu'un même motif soit appris par plusieurs systèmes échangeant
entre eux.
En partant du prédicat qu'il y aura potentiellement de la latence entre
l'émission d'une instance par un flux d'un système et la réception de
cette instance par un autre système, nous pouvons dire qu'il serait
plus pertinent pour un système de rechercher des motifs qu'il "fini" et
dont il peut avertir les autres.
remarque : prendre en compte ce facteur permettrait certes de réduire
la redondance mais risque de renforcer l'apparition de motifs "cyclique",
cependant ce types de motifs sont surement plus facilement indentifiable
que des redondances de motifs.
== Calcul du feedback ==
Le feedback d'intérêt Ί d'un évènement e se calcule donc à partir du rapport
de son intérêt intrapersonnel **Ία** sur son intérêt interpersonnel
Ίε.
Ί(e) = Ία(e)^δ / Ίε(e)^β
avec :
* intra_interest = specificity * accuracy * weight
* inter_interest = (Nb_Var_Necessary + 1) - Nb_Internal_Var_Used
remarque: les coefficients δ et β ne sont présent que pour donner
plus de "poids" à l'un ou l'autre des intérêt. Par défaut α = β = 1.
====== A remettre en forme ======
== Création de Flux ==
La découverte d'évènements récurrents se fait à l'aide d'un couple
d'agent Découper et Similarité. L'agent Découper faisant varier
ses paramètres de découpe et l'agent Similarité faisant varier
ses paramètres de différenciation, les deux en fonction de la
variable d'entrée à laquelle ils sont associés.
La qualité des paramètres, évaluée à partir d'un feedback //d'intérêt//,
est sauvegardé dans un **espace de marquage** à trois dimensions
(la variable sélectionné, les paramètres de l'agent Découper et
les paramètres de l'agent Similarité).
Cet espace de marque sert à garder, dans un espace commun de recherche
de paramètres à tous les couples d'agents, la trace de l'utilisation de
certains paramètres et leurs qualités.
{{wiki:hemis_marquage.png}}
Une fois qu'un couple, ou plutôt l'agent Similarité d'un couple d'agent,
aura déterminé qu'un //concept d'évènement// est assez récurrent il créera
un //flux d'instances d'évènements// dans lequel il fera passer les //instances//
correspondants au //concept d'évènement// du flux, et auxquels pourra se connecter
les agents Association du système d'apprentissage, mais aussi les agents
Association des autres systèmes d'apprentissage.
{{wiki:flux_creation.png}}
Pour connaitre la similarité, ou plutôt le pourcentage de similarité, entre deux
instances d'évènement, l'agent Similarité utilise une fonction d'intersection des
histogrammes représentants les instances.
{{wiki:similarite.png}}
=== Partage d'évènements ===
A peu près même moment que le système d'apprentissage de l'éclairage
créé ses //flux d'instances//, des //flux d'instances externes// font
leur apparitions.
Une notation possible est présentée ci-dessous. Noté **F**, un flux est
identifié par l'ip de l'objet fournissant le flux et l'id de ce flux.
De la même manière sont notés **e** les //concepts d'évènements// associés
à un flux, il sont donc identifiés de la même manière que les flux, avec
id et ip.
{{wiki:flux_notation.png}}
Pour simplifier la notation pour le scénario, l'ip du système d'éclairage
sera 1 et l'ip du store électrique sera 2. L'ip 0 est considéré comme un
"localhost", se sont les flux identifiés comme personnels par l'objet,
le fait de donner un ip 0 pour identifié le "moi" est totalement
arbitraire, un flux pourrait garder l'ip de l'objet apprenant, cependant
les agents du système d'apprentissage, en particulier les agents Découper,
devraient être capables de différencier les flux personnels et les flux
extérieurs.
Ainsi le système d'apprentissage voit apparaître, à peu près au même moment,
des flux d'instances //interne// (avec un ip 0) et des flux d'instances
//externes// (avec un ip différent de 0).
Les couples d'agents formés par des agents Association et Similarité vont
alors rechercher différentes Association de concepts d'évènements possibles
et pertinents.
{{wiki:flux_association.png}}
Les Associations vont être faites en prenant prioritairement en références
les flux internes du système d'apprentissage. Cet aspect "égoïste" de
l'apprentissage est nécessaire pour éviter une redondance de l'apprentissage
dans tous les avatars de la société, et permet aussi une spécialisation
de ces mêmes avatars. En effet, les avatars d'objets possédant peu de
capteurs et d'actionneurs seront plus enclin a tenter d'associer des évènements
provenant de flux externes; à l'inverse des avatars d'objets possédant beaucoup
de capteurs et d'actionneurs seront plus enclin à se concentrer uniquement sur
le découpage de leur variables d'entrées et sur la découverte de concepts d'évènements
"intéressants".
==== Point de vue du store électrique (Orienté Scénario) ====
Dans le point de vue précédent, l'accent a été mis sur le fonctionnement
globale du modèle. De ce point de vue, au contraire, nous allons nous
concentré, pas à pas, sur les suites logiques d'évènements pouvant arriver
à un système d'apprentissage.
=== Variables d'entrées et Découpe ===
Reprenons à partir de la découpe d'une variable d'entrée,
par exemple V2:2.
{{wiki:V2_2.png}}
== Couple Découper - Similarité (D-S) ==
L'apprentissage de la découpe d'une variable
d'entrée est implémenté par un couple D-S. Leurs
interactions, dont nous allons voir le fonctionnement,
permet de connaître la "pertinence" du découpage
d'une variable en particulier. Ils font varier leurs
paramètres en explorant l'espace de marquage vu précédemment.
== Découpe ==
L'agent Découper d'un couple D-S associé à la variable V2:2
a pour paramètre un Δt qui est la taille de la fenêtre de découpe.
{{wiki:decoupe.png}}
L'agent Découper va alors parcourir la variable d'entrée en faisant
"glisser" sa fenêtre de découpe le long des variations. La fenêtre
peut être simplement glissante, ou bien glissante et suivant les
variations de la variable d'entrée, comme sur l'image ci-dessus.
La portion découpée par l'agent Découper est alors représenté sous
la forme d'un histogramme.
== Similarité et Différenciation ==
Les histogrammes produit par l'agent Découper sont alors récupéré
par l'agent Similarité qui lui associé.
Celui ci compare les nouvelles instances d'évènement avec ceux qu'il
a stocké précédemment, ou plutôt avec l'histogramme représentant la moyenne
de chaque groupe d'instances similaires. Cette "moyenne" peut être considéré
comme un pré-concept d'évènement.
La fonction de comparaison utilisée pour différencier les instances découpées
en une fonction d'intersection entre les deux histogrammes représentant les
instances.
{{wiki:similarite.png}}
Ainsi l'agent Similarité du couple D-S "rangera" les nouvelles instances
d'évènements avec celles qui lui sont le plus similaire, modifiant par la
même la moyenne de ce groupe d'instance. Si aucun groupe n'est trouvé pour
une instance, alors un nouveau lui correspondant sera créé.
le paramètre de l'agent Similarité serait son seuil d'acceptation
de similarité, mais cela reste à confirmer.
== Feedback et sélection de concept ==
Avant que la moyenne d'un groupe d'instance soit considérée comme un réel
concept d'évènement, l'agent Similarité d'un couple D-S va calculer l'intérêt
de chaque pré-concept, et marquer le maximum de ces intérêts dans l'espace de
marquage des couple D-S.
Le feedback d'intérêt d'un pré-concept d'évènement est calculé à partir de la
spécificité de cet évènement, c'est à dire si l'évènement "sort du lot", et
de la redondance de cet évènement. Pour faire simple, parmi tous les évènements
"rare", celui qui aura le plus fort intérêt sera celui qui arrive le plus souvent,
donc potentiellement le moins dû au hasard.
intérêt = spécificité + redondance
C'est lorsqu'un couple D-S de type //Exploiteur// se positionnera, dans l'espace
de marquage, sur les paramètres de découpe de V2:2 que la création de
Flux d'instance se fera pour les concept ayant la plus haute spécificité.
== Conception de flux d'instances ==
Le fonctionnement de l'API de flux n'est, pour le moment, pas clairement
définie.
Comme dit précédemment, les couples D-S vont extraire
des //concepts d'évènements// et créer des //flux d'instances d'évènements//.
Ces flux pourraient correspondre à des flux RSS (ou tout autre outils permettant
le partage d'un "fil d'évènements"), ils seront ainsi mis à jour part l'agent
Similarité du couple associé, à chaque fois que l'agent Découper extrait une
nouvelle //instance d'évènement// correspondant au //concept d'évènement//
du flux.
Supposons qu'à partir de V2:2 deux concepts d'évènements soient
créés.
Il y aura donc deux flux de créé par le couple D-S affecté à cette variable
d'entrée. Ces flux étant internes du point de vue du store et externe
du point de vue du système d'éclairage.
{{wiki:conceptualisation_nntp.png}}
Exemple de description d'un flux en JSON-LD :
{
"@context": "http://www.w3.org/ns/activitystreams",
"@type": "Activity",
"published": "2016-01-25T12:34:56Z"
"author": {
"@type": "Object",
"@id": "URI de l'objet / URI du flux"
}
"orderedItems": [
{
"@type": "Event"
...
},
{
"@type": "Event"
...
}
]
}
=== Flux d'instances et Association ===
Reprenons à partir du moment où tous les flux (internes et externes)
de tous les objets de la société soient créés et accessibles par le store.
C'est à dire :
* 4 flux internes correspondant à :
* V2:1 à 1 pendant un certain temps.
* V2:1 à -1 pendant un certain temps.
* V2:2 augmentant progressivement de 0 à 1.
* V2:2 diminuant progressivement de 1 à 0.
* 6 flux externes correspondant à :
* V1:1 passant de 0 à 1 instantanément.
* V1:1 passant de 1 à 0 instantanément.
* V1:2 passant à 1 instantanément.
* V1:2 passant à 0 instantanément.
* V1:2 augmentant progressivement.
* V1:2 diminuant progressivement (sur plusieurs heures).
== Couple Association Similarité (A-S) ==
Déterminer l'intérêt d'associer un flux à un autre est
la fonction des couples A-S. Les couples A-S de type
//Explorateur// se déplaçant et marquant l'intérêt des
paramètres testés dans l'espace de marquage.
== Association ==
L'agent Association d'un couple A-S prend pour référence
le flux (interne ou externe) au quel il est affecté dans
l'espace de marquage. Les paramètres de l'agent Association
étant les autres flux auquel il tente d'associer son flux
de référence.
== Feedback d'intérêt ==
Comme pour le couple D-S, l'agent Similarité récupère
et classe les instances de l'association récupérées.
L'instance d'une association est, en partie, caractérisée
par le délai entre la référence et le flux associé, délai
pouvant bien entendu être négatif.
Un feedback d'intérêt est alors appliqué aux associations
découvertes par le couple A-S. Ce feedback est composé
de deux intérêts :
* L'**intérêt intrapersonnel** :
L'association des flux est évalué sur sa capacité à découvrir des motifs
pertinent pour soi, sans prendre en compte autrui. Il prend en compte
la spécificité et la précision des instances évalués.
* L'**intérêt interpersonnel** :
L'association des flux évalué sur sa capacité à découvrir des motifs
pertinent pour autrui, c'est à dire qu'il plus pertinent que se soit
le store qui prévienne les autres avatars de l'arrivé de l'association.
Ainsi cet intérêt est calculé à partir du nombre de flux interne utilisé
dans l'association, car nous partons du principe que chacun des avatars
cherche en priorité les motifs liés à ses capteurs, sans pour autant laisser
une probabilité nulle de trouver des motifs à partir de flux externe.
L'idée de prendre en compte le nombre de flux interne part du prédicat
qu'un objet possède des capteurs et des actionneurs potentiellement liés
(ex. capteur de luminosité + ampoule, chauffage + thermomètre...).
Le principe étant que les avatars créeront en priorité des associations
intrapersonnelles, les partageront, et qu'au bout d'un certain temps, avec
des concepts de plus en plus complexe, associer des motifs externes avec
des motifs internes sera plus pertinent que d'associer deux motifs internes
entre eux.
L'intérêt d'une association est donc calculé à partir de l'intérêt égoïste et altruiste.
intérêt = (intérêt égoïste) ^ alpha * (intérêt altruiste) ^ beta
<=> intérêt = ( ( spécificité + précision ) ^ alpha ) * ( ( nb_flux_interne + 1 ) ^ beta )
Les coefficients alpha et beta sont ici pour donner plus de poids à l'une ou l'autre des parties de l'intérêt,
par défaut nous pouvons les considérer comme égal à 1.
Autre possibilité :
intérêt = ((spécificité + précision) ^ alpha) / ( ( 3 - nb_flux_interne ) ^ beta )
Le but étant que le rapport intra/inter soit, pour un même intérêt
égoïste, plus important si plus de flux interne sont mis en jeux dans
l'association.
== Prédiction et Partage ==
A partir de ce feedback d'intérêt, marqué par les couples A-S de type //Explorateur//,
les couples A-S vont pouvoir tenter d'évaluer, à l'aide d'un second feedback, la capacité
prédictive des paramètres ayant le plus fort intérêt.
De nouveaux flux sont alors créé pour les évènements association les plus pertinents,
donc en priorité ceux dont l'avatar associe deux évènements internes, puis ceux avec un
évènement externe et un évènement interne, et enfin ceux avec deux évènements externes.
Donner un poids différents pour les associations flux externe -> flux interne et
flux interne -> flux externe, permettrais d'éviter des redondances pour les associations
avec un seul flux interne.
Cependant, la création de motif "cyclique" reste, voir est potentiellement renforcé. Mais
ces motifs "cyclique" sont plus facilement détectable que la redondance d'un motif, surtout
dans un apprentissage décentralisé.
==== Spécialisation des avatars ====
* Les objets possédant plus ou moins de capteurs et d'actionneurs, et leurs avatars étant capables de faire des associations aussi bien de flux interne que de flux externe, une première spécialisation peut se faire à partir du cas particulier de l'objet sans capteurs ni actionneurs : plus les objets possèderont de capteurs et d'actionneurs, plus les avatars se focaliseront sur la découpe et moins sur les associations, un objet sans capteurs ni actionneurs se focalisera au contraire uniquement sur les associations. (Bien entendu le cas de l'objet sans capteurs ni actionneurs est un cas extrêmement particulier, voir inexistant dans la réalité, mais pas impossible).
* Une fois qu'un avatar aura "épuisé" ses associations intrapersonnelles pertinentes, il s'orientera vers les associations prenant en compte un flux externe, ainsi il apprendra quels flux, et plus globalement quels objets, sont les plus à "écouter".
===== Problèmes =====
* Supposons maintenant que dans une autre pièce un système d'éclairage identique au notre soit installé, comment permettre que ce nouveau système d'éclairage apprenne plus vite avec l'aide de notre système d'éclairage ?
* En plus du feedback d'intérêt, il est censé il y avoir un feedback prédictif, comment un motif pourrait passer un "mode prédictif" s'il prend en compte des flux externes ?
* Comment les avatars pourrait arriver, de manière émergente, à un consensus concernant un motif, pour que celui-ci soit "commun" à la société ou à un groupe ?
* Comment à un niveau plus haut de l'avatar, ayant potentiellement conscience de faire partie d'une société, peut "extraire" des règles et des services des motifs appris ?