====== 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éé.
Les paramètres des agents Similarité est leur seuil de similarité, c'est
à dire le seuil qui leur fait dire si oui ou non deux instances sont similaires.
=== 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.
Un agent Association créé donc des motifs basés sur une
association d'un évènement **e1** et d'un évènement **e2**,
puis créé des instances de ce motif à chaque fois que des
instances de e1 et e2 sont captées, toujours une de chaque,
une puis l'autre, séparé d'un certain Δt pouvant être nul (voir
négatif).
{{wiki:motif.png?250}}
== 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.
La similarité entre deux associations est calculé par rapport
à la différence entre les Δt de chaque associations. L'agent
Similarité d'un couple A-S "rangera" donc les instances produite
par l'agent Association selon leurs Δt.
TODO : image/illustration
==== 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 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é**,
le **poids** et la **précision** des évènements évaluées.
La **spécificité** d'un évènement est calculé à partir de la différence
entre l'évènement et la moyenne générale de tous les évènements. La
spécificité permet ainsi d'identifier les évènements "sortant du lot".
Le **poids** d'un évènement correspond à son nombre d'occurence
par rapport au nombre d'occurence des autres évènements.
La **précision** d'un évènement, pour l'intérêt, peut être calculé
à partir de l'écart type des similarités entre les instances d'un
évènement.
=== 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.
Concernant les motifs "d'intéraction" :
Une certaine redondance de l'apprentissage se retrouve lors de la
découverte de motifs dit "d'intéraction", c'est à dire mettant
en jeux plusieurs systèmes, donc des associations entre un flux
interne et un flux externe. Un même motif peut potentiellement
être appris et diffusé par deux systèmes différents.
Exemple (en restant du point de vue du système d'éclairage) :
le store m'indique qu'il s'est ouvert (V2:2, ou V2:1, voir un motif
associant les deux), je capte une augmentation de la luminosité (V1:2)
que je communique aussi. L'association de l'ouverture du store (e1) et de
l'augmentation de la luminosité (e2) est faite par les deux systèmes et
les deux systèmes créent des flux correspondant à cette association, il
y a donc redondance.
Cette redondance est elle un mal ?
Doit-on utiliser cette redondance à notre avantage et l'utiliser
pour faire un consensus sur des motifs communs à certains objet ?
Si oui comment détecter qu'un même motif a été découvert par deux
systèmes différents et comment arriver à un consensus et comment
décider lequels des systèmes aura pour rôle de notifier les autres
des instances de ce motif ?
D'un autre point de vue, cette redondance est elle nécessaire ?
Ne pourait on pas faire en sorte "d'orienter" l'apprentissage
pour qu'un minimum de système, au mieux un seul, découvre ce motif ?
Personellement je penche plus vers ce second point de vue. Nous
pourrions par exemple donner plus d'intérêt à un concept d'association,
ou d'interaction, si l'évènement e2 de cette association est capté par un flux
interne.
Pour reprendre l'exemple: dans l'association "ouverture store" -> "augmentation
luminosité", e2 provient d'un flux interne pour le système d'éclairage l'association
et d'un flux externe pour le store. L'association aura donc un plus fort intérêt à
être exploité par le système d'éclairage que par le store électrique.
Partir sur ce principe permettrait de trouver plus rapidement des motifs "d'intéraction"
complexe, c'est à dire mettant en jeu plusieurs avatars.
De plus vérifier qu'un motif est "vrai" est plus facile que de détecter une redondance
(avis personnel), quand bien même qu'avant d'être diffusé un motif est passé par une
longue phase vérification, donc les systèmes n'ont pas vraiment de "raison" vérifier la
véracité d'un motif, juste de regarder si il leur est utile ou non. De plus les systèmes
ont les mêmes capacités d'apprentissage, raison de plus pour qu'ils se fasse "confiance"
leur de l'apprentissage de motif d'intéraction (je ne parle ici que d'apprentissage et non
de synchronisation entre eux).
=== 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
**Ίε**.
Pour le calcul de **Ία** d'un évènement, notons sa spécificité **s**,
sa précision **p**, son poids **π**.
Ί(e) = Ία(e)^δ / Ίε(e)^β
avec :
Ία(e) = s(e) * p(e) * π(e)
et
Ίε(e) = (Nb_Var_Necessary(e) + 1) - Nb_Internal_Var_Used(e)
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.
=== Feedback Prédictif ===
Lorsqu'un motif créé par un couple A-S semble "intéressant", celui-ci
passe un mode "prédictif", les couples A-S tente alors d'utiliser ce
motif pour prédire l'apparition d'évènement e2, à partir de l'apparition
d'un évènement e1.
Ce feedback prédictif est un score **s** caculé à partir d'une précision
**acc**, qui est calculé à partir d'une tolérance **tol** (qui est l'écart
type de la durée entre e1 et e2 lors des prédictions réussies) et de la
fréquence d'apparition de e2.
et d'une confiance **rel**, qui est le rapport de prédictions juste sur
le nombre de prédictions tentés.
s = acc * rel
avec :
rel = nb(prédictions) / nb(e1)
et
acc = 1 - ( tol * freq(e2) )
Le maximum des scores est ajouté à l'intérêt dans l'espace de marquage des
couple A-S pour la variable et les paramètres associés, leurs donnant ainsi
plus de poids.
Pour l'instant le feedback prédictif sera utilisé comme ceci, mais
n'est pas exclu d'être modifié.
Une possibilité serait d'utiliser les formules utilisées en statistique
pour évaluer un classifieur.
Le score serait calculé à partir :
* d'une **sensibilité** qui est le rapport des **vrais positifs** ou VP (les prédictions juste) sur toute les prédictions dite comme vrais (toutes les fois où l'on a supposé l'arrivé de e2 à partir de e1).
* et d'une **spécificité** qui est le rapport des **vrais négatifs** ou VN (les prédictions dite fausses et vraiment fausses) sur toutes les fois où l'on a dit que e2 n'arrivera pas après e2.
Si nous voulons utiliser ces formules il faudra donner la possibilité
au couple A-S prédicteur de dire Oui ou Non à la question : un évènement
e2 arrivera-t-il après cet évènement e1 ?
Ceci pourrait être fait à partir d'un de l'écart de temps entre les deux
instances, par exemple : si e2 n'est pas encore apparu un temps T après
l'apparition d'un évènement e1, alors il n'arrivera surement jamais.
==== Flux d'instances ====
Lorsqu'un concept d'évènement, qu'il soit découvert part un couple D-S
ou A-S, est déterminé comme "intéressant" alors un **flux d'instances**
correspondant au concept d'évènement est créé pour pouvoir y partager
les instances de ce concept (c'est à dire les instances similaires
au concept d'évènement) avec les autres systèmes.
=== Identification ===
Du point de vue d'un système, et donc de ses agents, un flux est perçu
comme un **flux interne** si celui-ci a été créé par le système, et
comme un **flux externe** si il a été créé par un autre système.
Par exemple :
Du point de vue du système d'éclairage, les flux d'instances correspondant
aux concepts : augmentation soudaine de la luminosité,
augmentation progressive de la luminosité, diminution soudaine de la luminosité,
interrupteur passe à ON, interrupteur passe à OFF, etc... seront perçus
comme des **flux interne** car créé par le système d'éclairage.
A l'inverse, les flux correspondant aux concepts : store s'ouvrent, store
se ferme; seront perçu comme des **flux externes**.
Pour aider à l'identification d'un flux par un système, et ses agents,
est associé au flux URI du système l'ayant créé (donc l'URI de l'avatar)
et l'URI du concept correspondant au flux (généré par le système). Les
agents d'un système connaiteront l'URI de l'objet.
{{wiki:flux_notation.png}}
TODO : mettre à jour l'image quand une notation aura été définie.
=== API de transfert d'instances ===
Le fonctionnement de l'API de flux n'est, pour le moment, pas clairement
définie. Ce qui est écrit dans cette section sont des idées sur le fonctionnement
général de l'API et sur l'adaptation possible de protocoles, API ou frameworks déjà
existant pour les besoins du système d'apprentissage.
== Fonctionnement hypothétique ==
Si nous prenons le point de vue d'un avatar, le principe des flux
reviens à proposer un service de notification d'évènements aux autres
avatars de la société.
Le mot service utilisé ici ne correspond pas forcément
à un service web à proprement parlé, ce n'est peut être pas
le bon mot à employer.
Ainsi lorsque le système d'apprentissage créé un flux correspondant
à un concept d'évènement, un flux/service de notification est alors
créé par l'avatar et les autres avatars de la société sont avertis
de la création du service de notification. (par la même, si un service
de notification est détruit, les autres avatars seront avertis de sa
destruction, et le flux externe du système d'apprentissage sera détruit).
Lorsqu'un avatar est avertis de la création d'un service de notification,
son système d'apprentissage créera un flux d'instance correspondant.
Lorsqu'un couple A-S prendra pour référence un flux externe, cela signifiera
que l'avatar "s'abonne" au service de notification proposé par un autre avatar.
De la même manière un avatar "s'abonnera" à un service de notification si un
couple A-S tente d'associer son flux référence à un flux externe.
== Protocoles, API, frameworks déjà existants ==
Pour implémenter une API permettant de mettre en place de tel fonctionnalités,
adapter certains protocole/API/frameworks à nos besoins pourrait être pertinents.
Ci-dessous sont listés quelques API potentiels :
* Les flux RSS
Le mode de fonctionnement des [[https://fr.wikipedia.org/wiki/RSS | flux RSS]] semble
plutôt bien correspondre au principe des flux d'instances (d'ailleurs c'est de là qu'ils
tirent leurs noms). Cependant les flux RSS ont quelque faiblesse, se sont des fichiers
XML où sont écrit toutes les notifications et sont accessible par tous. De plus se sont
les outils "abonnés" qui regarde, à intervals réguliers, si des modifications on eu lieu
dans le fichier XML. Ce ne sont donc pas de réelles "notification" fait d'un serveur à un
terminal (pour notre cas, d'un avatar à un avatar) et il faudrait mettre en place un
programme permettant de détecter la création (ou la suppression) d'un flux dans la société.
* Le réseau Usenet et le protocole NNTP/S
Le réseau [[https://fr.wikipedia.org/wiki/Usenet | Usenet]] est à la base un système
de réseaux de forums permettant le partage rapide, à des groupes "d'abonnés", de nouvelles
(ou news) concernant un forum. Il utilise le protocole [[https://tools.ietf.org/html/rfc3977 | NNTP]]
qui a été conçu spécialement pour le transport de news dans un réseau, il existe en version
"sécurisé": NNTPS. La [[https://tools.ietf.org/html/rfc1036 | RFC1036]] décrit le format
standard des échanges de messages dans un réseau Usenet.
==== Récapitulatif =====
Avant de passer au fonctionnement pas à pas de l'apprentissage en prenant le point de vue
du store électrique, voici un récapitulatif du fonctionnement général du système d'apprentissage.
=== Variables d'entrées & Découpe d'instances d'évènements ===
Les **couples D-S** vont explorer leur **espace de marquage** en y déposant l'intérêt maximum
trouvé avec les paramètres associés. Ce marquage sert de mémoire pour retrouver
facilement des paramètres pertinents et va aussi influencer les déplacements des
couple D-S dans l'espace de marquage, c'est à dire dans leurs choix de paramètres.
L'agent **Découper** d'un couple D-S fait "glisser" une fenêtre de découpe sur
la variable d'entrée, créant ainsi des instances d'évènement. L'agent **Similarité**
associé à cet agent **Découper**, c'est à dire formant un couple avec, va "trier"
par "type" d'instance plus ou moins similaire et évaluer l'intérêt Ί de chaque
"type" d'instance. (L'intérêt max trouvé avec leurs paramètres est la valeur
déposé dans l'espace de marquage).
Une fois des "type" d'instances validé comme "intéressants" ceux-ci deviennent
des **concepts d'évènements**, des **flux d'instances** sont créés et lorsque
l'agent Découper d'un couple D-S produit une instance d'évènement correspondant
à un concept d'évènements, l'agent Similarité lié diffuse l'instance par le flux.
{{wiki:flux_creation.png}}
=== Flux d'instances & Association d'évènements ===
Le système à maintenant accès des **flux d'instances** lui permettant d'étre informé
lors de l'apparition d'une instance d'un concept d'évènement.
Ces flux d'instances peuvent aussi bien être des **flux internes**, c'est à dire des
flux créés et mis à jour par le système, que des **flux externes**, c'est à dire des
flux créés et mis à jour par d'autre système.
A partir de ces flux des **couples A-S** vont tenter d'associer deux concepts d'évènements
en regardant si ils ont l'air plus ou moins corrélés, c'est à dire si l'un arrive toujours
après l'autre avec toujours le même délai.
Pour cela ils vont parcourir leur espace de marquage, ainsi l'agent **Association** d'un
couple A-S prend un flux, et donc le concept d'évènement associer, comme référence et
va explorer les possibilités de combinaisons via ses paramètres. Les instances d'associations
produite par l'agent **Association** sont récupéré, trier et évalué par l'agent **Similarité**
associé.
Comme pour les couples D-S, l'intérêt maximum trouvé avec des paramètres est noté dans l'espace
de marquage.
L'intérêt Ί de chaque "type" d'instance d'évènement association, c'est à dire les
différents types de délai entre les deux évènements associé, est calculé à partir
de la spécificité et la redondance de ce "type" d'instance, mais aussi à partir
du nombre de flux internes qui a entres en jeux lors de l'association. Ainsi, pour
une spécificié et redondance, plus d'intérêt est affecté à des associations entre deux
flux internes, puis entre un flux interne et un flux externe, puis entre deux flux externes.
Les associations sont aussi évalué à partir de leur capacité prédictive. Et une fois
qu'une association a été déterminé comme "intéressante" et permettant des prédictions
fiable, alors un flux d'instance est créé pour y faire passer les instances de cet
évènement (qui est l'association de deux évènements), et donc potentiellement "avertir"
autrui de l'arrivé des instances de cet évènement.
A partir de ce flux d'instance, autrui pourra peut être créer des associations pertinentes,
qui pourrons me permettre de créer des associations pertinentes, et ainsi de suite.
{{wiki:flux_association.png}}