Differences

This shows you the differences between two versions of the page.

--- scenario-lum [2025/12/08 07:41]
47.128.36.32 old revision restored (2025/07/23 02:08)
+++ scenario-lum [2025/12/11 17:11] (current)
47.128.56.207 old revision restored (2025/10/23 17:22)
@@ Line 1: / Line 1: @@
 ====== Modification de luminosité dans une pièce: Découverte de pattern sensorimoteur par deux objets ======
-Ce scénario reprend le principe de //flux d'intances d'évènements// entre
+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]].
@@ Line 11: / Line 11: @@
 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é).
+  * 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 ====
-==== Les variables ====
+Billy, notre utilisateur, se lève et se rend dans son bureau. Faisant encore
+nuit, Billy allume la lumière, il est 6h.
-Au départ de ce scénario, les avatars n'ont pas encore indentifiés de pattern
+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
@@ Line 26: / Line 46: @@
   * Pour la fenêtre équipée d'un store électrique :
     - l'état de l'actionneur de store, nommée V<sub>2:1</sub> (-1 : descendre le store, 1 : monter le store, 0 : sinon).
-    - Pourcentage d'ouverture du store, nommée V<sub>2:2</sub> (allant de 0, le store est fermé, et 1 le store est ouvert).
+    - Pourcentage d'ouverture du store, nommée V<sub>2:2</sub> (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 V<sub>2:2</sub>
+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) ===
+<note important>
+Le fonctionnement des agents Association décrit
+dans cette section n'est pas celui décrit dans la
+thèse de Mazac, mais plutôt une interprétation.
+Pour moi ils devraient fonctionner comme suit, mais
+la discussion reste ouverte.
+</note>
+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.
+<note>
+TODO : image/illustration
+</note>
+==== 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.
+<note tip>
+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).
+</note>
+=== 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 **Ί<sub>α</sub>** sur son intérêt interpersonnel
+**Ί<sub>ε</sub>**.
+Pour le calcul de **Ί<sub>α</sub>** d'un évènement, notons sa spécificité **s**,
+sa précision **p**, son poids **π**.
+<code>
+Ί(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.
+</code>
+<note>
+Cette formule d'intérêt peut aussi bien être utilisé par les couples
+D-S ou A-S, puisque pour l'intérêt **Ί** d'un découpage :
+Ίε(e) = (Nb_Var_Necessary(e) + 1) - Nb_Internal_Var_Used(e)
+= 1 + 1 - 1 = 1.
+=> Ί(e) = Ία(e) = s(e) * π(e)
+avec p(e) = 1.
+Donc nous retrouvons la formule proposée par Mazac
+</note>
+=== 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.
+<code>
+s = acc * rel
+avec :
+  rel = nb(prédictions) / nb(e1)
+et
+  acc = 1 - ( tol * freq(e2) )
+</code>
+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.
+<note tip>
+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.
+</note>
+==== 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.
+<note>
+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**.
+</note>
+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}}
+<note>
+TODO : mettre à jour l'image quand une notation aura été définie.
+</note>
+=== API de transfert d'instances ===
+<note important>
+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.
+</note>
+== 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é.
+<note>
+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.
+</note>
+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}}
+===== Déroulement de l'apprentissage (point de vue du store électrique) =====
+Afin de mieux comprendre le fonctionnement du système d'apprentissage décrit
+dans la partie précédente, illustrons le déroulement pas à pas du processus
+d'apprentissage du store électrique.
+==== Capteurs, actionneurs & variables d'entrées ====
+Au départ de son apprentissage, lors de sa mise en route pour la première fois,
+le système d'apprentissage du store électrique ne connais pas les liens entre
+ses différents capteurs et effecteurs (ses patterns sensorimoteurs). Il ne
+connais pas encore l'existence d'autres objets, il n'a pas "conscience" de faire
+parti d'une société.
+<note>
+Ne pas confondre l'avatar et son système d'apprentissage, l'avatar à "conscience"
+d'être connecté à d'autres objets, mais son système d'apprentissage non, du moins
+pas pour l'instant, pas au début de ce scénario.
+</note>
+L'objet "store électrique" a à sa disposition :
+  * Un interrupteur permettant de descendre ou monter le store.
+  * Un "capteur" permettant de savoir à combien de pourcentage le store est ouvert.
+=== Variations des valeurs captées dans une journée type ===
+Comme nous l'avons vu dans l'introduction, l'utilisateur Billy, a pour habitude
+d'ouvrir les stores de son bureau lorsqu'il est environ 8h et qu'il sait
+que le jour est levé. Il ferme ensuite ses stores vers 19h, lorsque le soleil
+se couche, pour ensuite rallumer la lumière de son bureau. Rappelons que le
+store n'es connecté à aucun objets lui permettant de connaitre la luminosité extérieur.
+== Variations de l'interrupteur (V2:1) ==
+{{wiki:V2_1.png}}
+== Variations de l'ouverture du store (V2:2) ==
+{{wiki:V2_2.png}}
+==== Découverte d'évènements intéressants à partir des variables d'entrées ====
+Nous allons maintenant voir comment les **couples Découper-Similarité** génèrent, trient
+et évaluent des instances d'évènements, et aussi comment ils explorent **l'espace de
+marquage**.
+=== Exploration de l'espace de marquage ===
+Au début de son apprentissage l'espace de marquage est vide, ou nul, sans aucun
+marquage. Ainsi, les couples D-S le parcourant, qui sont pour l'instant tous de
+type //explorateur//, se positionnent de manière aléatoire dans l'espace de marquage,
+c'est à dire qu'ils sélectionnent leurs paramètres de manière aléatoire. Si un couple
+D-S veut utiliser une place déjà occupée, des paramètres déjà utilisés, par un autre
+couple D-S, alors il cherchera une autre position.
+Rappellons que **l'espace de marquage** d'un couple D-S est définit par rapport
+à trois axes :
+  * La **variable d'entrée** que va découper l'agent Découper du couple (ici soit V2:1, soit V2:2).
+  * Les **paramètres des agents Découper**, c'est à dire les différentes tailles de fenètres de découpe, simplement glissante, à leur disposition (ici //immédiat//, //1 seconde//, //10 secondes//, //1 minute//).
+  * Les **paramètres des agents Similarité**, c'est à dire les seuils de similarité d'un agent similarité (ici //25%//, //50%//, //75%//).
+<note>
+TODO : image/illustration
+</note>
+=== Découpe des variables ===
+<note important>
+En chantier
+</note>
+Supposons la position aléatoire d'un couple D-S dans l'espace de marquage comme
+étant variable V2:1 (l'interrupteur), fenètre de découpe de 1 minute et seuil
+de similarité à 25%, et regardons les instances d'évènements découpées. Rappellons
+que l'apprentissage se déroule sur plusieurs semaines avec des journées identiques
+(bien que cela ne soit pas réaliste). Rappelons aussi que d'autres couples D-S
+explorent l'espace de marquage.
+== Variable : V2:1, Fenètre de découpe : 1 minutes, Seuil de similarité : 25 % ==
+{{v2_1_decoupe.png}}

DokuWiki

Site Tools

Differences

Page Tools