Differences

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

--- scenario-lum [2025/12/11 04:21]
66.249.64.232 old revision restored (2025/08/29 16:48)
+++ scenario-lum [2025/12/11 17:11] (current)
47.128.56.207 old revision restored (2025/10/23 17:22)
@@ Line 133: / Line 133: @@
 une instance, alors un nouveau lui correspondant sera créé.
-<note>
+Les paramètres des agents Similarité est leur seuil de similarité, c'est
-le paramètre de l'agent Similarité serait son seuil d'acceptation
+à dire le seuil qui leur fait dire si oui ou non deux instances sont similaires.
-de similarité, mais cela reste à confirmer.
-</note>
 === 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
@@ Line 152: / Line 158: @@
 é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é ==
@@ Line 159: / Line 174: @@
 l'association.
-=== L'espace de marquage ===
+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
@@ Line 186: / Line 210: @@
 **Exploiteurs**.
-== Les explorateurs ==
+=== Les explorateurs ===
 Comme leurs nom l'indique, ceux sont les couples "bougeant"
@@ Line 200: / Line 224: @@
 l'emplacement de l'intérêt maximum trouvé, puis se redéplacent.
-== Les exploiteurs ==
+=== Les exploiteurs ===
 Ce type de couple se fixe sur les emplacements les plus
@@ Line 211: / Line 235: @@
 un emplacement.
-=== Feedback d'intérêt ===
+==== Feedback d'intérêt ====
 Dans la section précédente nous avons parlé du marquage
@@ Line 221: / Line 245: @@
 correspondant à la variable et aux paramètres des agents.
-<note>
+=== L'intérêt intrapersonnel ===
-L'intérêt est calculé légèrement différemment pour les couple
-D-S et A-S.
-</note>
-== L'intérêt intrapersonnel ==
 Une découpe de variable, ou une association de flux, est évalué sur
@@ Line 235: / Line 254: @@
 **L'intérêt intrapersonnel** se calcule à partir de la **spécificité**,
-la **précision** et le **poids** des instances évaluées.
+le **poids** et la **précision** des évènements évaluées.
-Le **poids** d'un type d'instance correspond à son nombre d'occurence
+La **spécificité** d'un évènement est calculé à partir de la différence
-par rapport au
+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".
-== L'intérêt interpersonnel ==
+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
@@ Line 263: / Line 290: @@
 <note tip>
-Un autre facteur pouvant être pris en compte est la "direction" du motif
+Concernant les motifs "d'intéraction" :
-lors d'une association entre un flux interne et un flux externe.
+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 ?
-Pour éviter qu'un même motif soit appris par plusieurs systèmes échangeant
+Ne pourait on pas faire en sorte "d'orienter" l'apprentissage
-entre eux.
+pour qu'un minimum de système, au mieux un seul, découvre ce motif ?
-En partant du prédicat qu'il y aura potentiellement de la latence entre
+Personellement je penche plus vers ce second point de vue. Nous
-l'émission d'une instance par un flux d'un système et la réception de
+pourrions par exemple donner plus d'intérêt à un concept d'association,
-cette instance par un autre système, nous pouvons dire qu'il serait
+ou d'interaction, si l'évènement e2 de cette association est capté par un flux
-plus pertinent pour un système de rechercher des motifs qu'il "fini" et
+interne.
-dont il peut avertir les autres.
+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).
-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.
 </note>
-== Calcul du feedback ==
+=== 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 **π**.
-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>.
 <code>
@@ Line 292: / Line 358: @@
 avec :
-  * intra_interest = specificity * accuracy * weight
+  Ία(e) = s(e) * p(e) * π(e)
+et
-  * inter_interest = (Nb_Var_Necessary + 1) - Nb_Internal_Var_Used
+  Ίε(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.
+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.
-====== A remettre en forme ======
+<code>
+s = acc * rel
+avec :
+  rel = nb(prédictions) / nb(e1)
+et
-== Création de Flux ==
+  acc = 1 - ( tol * freq(e2) )
+</code>
-La découverte d'évènements récurrents se fait à l'aide d'un couple
+Le maximum des scores est ajouté à l'intérêt dans l'espace de marquage des
-d'agent Découper et Similarité. L'agent Découper faisant varier
+couple A-S pour la variable et les paramètres associés, leurs donnant ainsi
-ses paramètres de découpe et l'agent Similarité faisant varier
+plus de poids.
-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
+<note tip>
-de paramètres à tous les couples d'agents, la trace de l'utilisation de
+Pour l'instant le feedback prédictif sera utilisé comme ceci, mais
-certains paramètres et leurs qualités.
+n'est pas exclu d'être modifié.
-{{wiki:hemis_marquage.png}}
+Une possibilité serait d'utiliser les formules utilisées en statistique
+pour évaluer un classifieur.
-Une fois qu'un couple, ou plutôt l'agent Similarité d'un couple d'agent,
+Le score serait calculé à partir :
-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}}
+  * 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.
-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}}
+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 ?
-=== Partage d'évènements ===
+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>
-A peu près même moment que le système d'apprentissage de l'éclairage
+==== Flux d'instances ====
-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
+Lorsqu'un concept d'évènement, qu'il soit découvert part un couple D-S
-identifié par l'ip de l'objet fournissant le flux et l'id de ce flux.
+ou A-S, est déterminé comme "intéressant" alors un **flux d'instances**
-De la même manière sont notés **e** les //concepts d'évènements// associés
+correspondant au concept d'évènement est créé pour pouvoir y partager
-à un flux, il sont donc identifiés de la même manière que les flux, avec
+les instances de ce concept (c'est à dire les instances similaires
-id et ip.
+au concept d'évènement) avec les autres systèmes.
-{{wiki:flux_notation.png}}
+=== Identification ===
-Pour simplifier la notation pour le scénario, l'ip du système d'éclairage
+Du point de vue d'un système, et donc de ses agents, un flux est perçu
-sera 1 et l'ip du store électrique sera 2. L'ip 0 est considéré comme un
+comme un **flux interne** si celui-ci a été créé par le système, et
-"localhost", se sont les flux identifiés comme personnels par l'objet,
+comme un **flux externe** si il a été créé par un autre système.
-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,
+<note>
-des flux d'instances //interne// (avec un ip 0) et des flux d'instances
+Par exemple :
-//externes// (avec un ip différent de 0).
-Les couples d'agents formés par des agents Association et Similarité vont
+Du point de vue du système d'éclairage, les flux d'instances correspondant
-alors rechercher différentes Association de concepts d'évènements possibles
+aux concepts : augmentation soudaine de la luminosité,
-et pertinents.
+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.
-{{wiki:flux_association.png}}
+A l'inverse, les flux correspondant aux concepts : store s'ouvrent, store
+se ferme; seront perçu comme des **flux externes**.
+</note>
-Les Associations vont être faites en prenant prioritairement en références
+Pour aider à l'identification d'un flux par un système, et ses agents,
-les flux internes du système d'apprentissage. Cet aspect "égoïste" de
+est associé au flux URI du système l'ayant créé (donc l'URI de l'avatar)
-l'apprentissage est nécessaire pour éviter une redondance de l'apprentissage
+et l'URI du concept correspondant au flux (généré par le système). Les
-dans tous les avatars de la société, et permet aussi une spécialisation
+agents d'un système connaiteront l'URI de l'objet.
-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) ====
+{{wiki:flux_notation.png}}
-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 V<sub>2:2</sub>.
-{{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 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é 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éé.
 <note>
-le paramètre de l'agent Similarité serait son seuil d'acceptation
+TODO : mettre à jour l'image quand une notation aura été définie.
-de similarité, mais cela reste à confirmer.
 </note>
-== Feedback et sélection de concept ==
+=== API de transfert d'instances ===
-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.
-<code>
-    intérêt = spécificité + redondance
-</code>
-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 V<sub>2:2</sub> que la création de
-Flux d'instance se fera pour les concept ayant la plus haute spécificité.
-== Conception de flux d'instances ==
 <note important>
 Le fonctionnement de l'API de flux n'est, pour le moment, pas clairement
-définie.
+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>
-Comme dit précédemment, les couples D-S vont extraire
+== Fonctionnement hypothétique ==
-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 V<sub>2:2</sub> deux concepts d'évènements soient
+Si nous prenons le point de vue d'un avatar, le principe des flux
-créés.
+reviens à proposer un service de notification d'évènements aux autres
+avatars de la société.
-Il y aura donc deux flux de créé par le couple D-S affecté à cette variable
+<note>
-d'entrée. Ces flux étant internes du point de vue du store et externe
+Le mot service utilisé ici ne correspond pas forcément
-du point de vue du système d'éclairage.
+à un service web à proprement parlé, ce n'est peut être pas
+le bon mot à employer.
+</note>
-{{wiki:conceptualisation_nntp.png}}
+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).
-<code>
+Lorsqu'un avatar est avertis de la création d'un service de notification,
-Exemple de description d'un flux en JSON-LD :
+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 ==
-  "@context": "http://www.w3.org/ns/activitystreams",
-  "@type": "Activity",
+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 :
-  "published": "2016-01-25T12:34:56Z"
+  * 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é.
-  "author": {
+  * Le réseau Usenet et le protocole NNTP/S
-    "@type": "Object",
+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.
-    "@id": "URI de l'objet / URI du flux"
+==== Récapitulatif =====
-  }
-  "orderedItems": [
+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.
-      "@type": "Event"
-        ...
+=== Variables d'entrées & Découpe d'instances d'évènements ===
-    },
-    {
-      "@type": "Event"
-       ...
+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.
-</code>
-=== Flux d'instances et Association ===
+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).
-Reprenons à partir du moment où tous les flux (internes et externes)
+Une fois des "type" d'instances validé comme "intéressants" ceux-ci deviennent
-de tous les objets de la société soient créés et accessibles par le store.
+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.
-C'est à dire :
+{{wiki:flux_creation.png}}
-  * 4 flux internes correspondant à :
+=== Flux d'instances & Association d'évènements ===
-    * 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) ==
+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.
-Déterminer l'intérêt d'associer un flux à un autre est
+Ces flux d'instances peuvent aussi bien être des **flux internes**, c'est à dire des
-la fonction des couples A-S. Les couples A-S de type
+flux créés et mis à jour par le système, que des **flux externes**, c'est à dire des
-//Explorateur// se déplaçant et marquant l'intérêt des
+flux créés et mis à jour par d'autre système.
-paramètres testés dans l'espace de marquage.
-== Association ==
+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.
-L'agent Association d'un couple A-S prend pour référence
+Pour cela ils vont parcourir leur espace de marquage, ainsi l'agent **Association** d'un
-le flux (interne ou externe) au quel il est affecté dans
+couple A-S prend un flux, et donc le concept d'évènement associer, comme référence et
-l'espace de marquage. Les paramètres de l'agent Association
+va explorer les possibilités de combinaisons via ses paramètres. Les instances d'associations
-étant les autres flux auquel il tente d'associer son flux
+produite par l'agent **Association** sont récupéré, trier et évalué par l'agent **Similarité**
-de référence.
+associé.
-== Feedback d'intérêt ==
+Comme pour les couples D-S, l'intérêt maximum trouvé avec des paramètres est noté dans l'espace
+de marquage.
-Comme pour le couple D-S, l'agent Similarité récupère
+L'intérêt **Ί** de chaque "type" d'instance d'évènement association, c'est à dire les
-et classe les instances de l'association récupérées.
+différents types de délai entre les deux évènements associé, est calculé à partir
-L'instance d'une association est, en partie, caractérisée
+de la spécificité et la redondance de ce "type" d'instance, mais aussi à partir
-par le délai entre la référence et le flux associé, délai
+du nombre de flux internes qui a entres en jeux lors de l'association. Ainsi, pour
-pouvant bien entendu être négatif.
+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.
-Un feedback d'intérêt est alors appliqué aux associations
+Les associations sont aussi évalué à partir de leur capacité prédictive. Et une fois
-découvertes par le couple A-S. Ce feedback est composé
+qu'une association a été déterminé comme "intéressante" et permettant des prédictions
-de deux intérêts :
+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.
-  * L'**intérêt intrapersonnel** :
+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.
-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** :
+{{wiki:flux_association.png}}
-L'association des flux évalué sur sa capacité à découvrir des motifs
+===== Déroulement de l'apprentissage (point de vue du store électrique) =====
-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é
+Afin de mieux comprendre le fonctionnement du système d'apprentissage décrit
-dans l'association, car nous partons du principe que chacun des avatars
+dans la partie précédente, illustrons le déroulement pas à pas du processus
-cherche en priorité les motifs liés à ses capteurs, sans pour autant laisser
+d'apprentissage du store électrique.
-une probabilité nulle de trouver des motifs à partir de flux externe.
-<note tip>
+==== Capteurs, actionneurs & variables d'entrées ====
-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.
+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'intérêt d'une association est donc calculé à partir de l'intérêt égoïste et altruiste.
+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 ===
-<code>
+Comme nous l'avons vu dans l'introduction, l'utilisateur Billy, a pour habitude
-intérêt = (intérêt égoïste) ^ alpha  *  (intérêt altruiste) ^ beta
+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.
-<=> intérêt = ( ( spécificité + précision ) ^ alpha ) * ( ( nb_flux_interne + 1 ) ^ beta )
+== Variations de l'interrupteur (V2:1) ==
+{{wiki:V2_1.png}}
-Les coefficients alpha et beta sont ici pour donner plus de poids à l'une ou l'autre des parties de l'intérêt,
+== Variations de l'ouverture du store (V2:2) ==
-par défaut nous pouvons les considérer comme égal à 1.
-</code>
+{{wiki:V2_2.png}}
-<note tip>
+==== Découverte d'évènements intéressants à partir des variables d'entrées ====
-Autre possibilité :
-intérêt = ((spécificité + précision) ^ alpha) / ( ( 3 - nb_flux_interne ) ^ beta )
+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**.
-Le but étant que le rapport intra/inter soit, pour un même intérêt
+=== Exploration de l'espace de marquage ===
-égoïste, plus important si plus de flux interne sont mis en jeux dans
-l'association.
-</note>
-== Prédiction et Partage ==
+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.
-A partir de ce feedback d'intérêt, marqué par les couples A-S de type //Explorateur//,
+Rappellons que **l'espace de marquage** d'un couple D-S est définit par rapport
-les couples A-S vont pouvoir tenter d'évaluer, à l'aide d'un second feedback, la capacité
+à trois axes :
-prédictive des paramètres ayant le plus fort intérêt.
+  * 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>
-De nouveaux flux sont alors créé pour les évènements association les plus pertinents,
+=== Découpe des variables ===
-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.
-<note tip>
+<note important>
-Donner un poids différents pour les associations flux externe -> flux interne et
+En chantier
-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é.
 </note>
-==== Spécialisation des avatars ====
+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
-  * 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).
+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
-  * 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".
+(bien que cela ne soit pas réaliste). Rappelons aussi que d'autres couples D-S
+explorent l'espace de marquage.
-===== 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 ?
+== Variable : V2:1, Fenètre de découpe : 1 minutes, Seuil de similarité : 25 % ==
-  * 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 ?
+{{v2_1_decoupe.png}}
-  * 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 ?

DokuWiki

Site Tools

Differences

Page Tools