Differences

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

--- scenario-lum [2025/10/17 13:58]
20.171.207.175 old revision restored (2025/10/15 09:14)
+++ scenario-lum [2025/10/17 20:50] (current)
20.171.207.175 old revision restored (2025/10/13 00:06)
@@ 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'instances d'évènements// entre
+Ce scénario reprend le principe de //flux d'intances 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 ====
-Billy, notre utilisateur, se lève et se rend dans son bureau. Faisant encore
+==== Les variables ====
-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
+Au départ de ce scénario, les avatars n'ont pas encore indentifiés de pattern
-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 43: / Line 23: @@
     - l'état de l'interrupteur du système d'éclairage, que nous nommeront V<sub>1:1</sub>.
     - l'intensité lumineuse de la pièce, nommée V<sub>1:2</sub>.
-  * 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é, à 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 % ==
-{{wiki:V2_1_decoupe.png}}

DokuWiki

Site Tools

Differences

Page Tools