Differences

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

--- scenario-lum [2025/09/13 12:22]
66.249.68.35 old revision restored (2025/08/31 06:57)
+++ scenario-lum [2025/09/21 03:48] (current)
66.249.68.36 old revision restored (2025/08/31 07:51)
@@ Line 12: / Line 12: @@
   * Un système d'éclairage (lampe), avec interrupteur et capteur de luminosité.
   * Une fenêtre équipée d'un store électrique, avec un interrupteur permettant de faire monter ou descendre plus ou moins le store (pas de capteur de luminosité).
-==== La routine de travail de Billy ====
+==== Les variables ====
+Au départ de ce scénario, les avatars n'ont pas encore identifiés de pattern
+récurrents, il n'existe donc pas encore de variables internes (ou de **flux
+d'instances**), uniquement des variables d'entrées continues correspondant aux
+capteurs et actionneurs des objets.
+  * Pour le système d'éclairage les variables d'entrées sont :
+    - l'état de l'interrupteur du système d'éclairage, que nous nommeront 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é, et 1 le store est ouvert).
+===== Scénario =====
+L'action se déroule dans le bureau de notre utilisateur, Billy,
+et ce durant plusieurs semaines.
+==== Point de vue de l'utilisateur ====
 Billy, notre utilisateur, se lève et se rend dans son bureau. Faisant encore
@@ Line 30: / Line 50: @@
 (oui, Billy travaille beaucoup plus qu'il ne le devrait).
-L'action se déroule dans le bureau de notre utilisateur, Billy,
+==== Point de vue du système d'objets connectés ====
-et ce durant plusieurs semaines.
-==== Les variables d'entrée du système ====
-Au départ de ce scénario, les avatars n'ont pas encore identifiés de pattern
-récurrents, il n'existe donc pas encore de variables internes (ou de **flux
-d'instances**), uniquement des variables d'entrées continues correspondant aux
-capteurs et actionneurs des objets.
-  * Pour le système d'éclairage les variables d'entrées sont :
-    - l'état de l'interrupteur du système d'éclairage, que nous nommeront 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
@@ Line 62: / Line 66: @@
 {{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
+==== Point de vue du système d'éclairage (Orienté description du modèle) ====
-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
+Si nous prenons le point de vue du système d'éclairage,
-qui arriveront, par leurs interactions, d'extraire des motifs
+celui-ci sera capable de découvrir, dans un premier temps,
-pertinents pour les interactions des avatars entre eux.
+des motifs liés à ses propres capteurs et actionneurs (puisque
+aucun //flux// n'est disponible pour le moment).
-De plus il utilise un système de flux d'évènements lui permettant
+Puis dans un second temps de faire le lien entre ses motifs et
-d'échanger des informations avec les systèmes d'apprentissages des
+ceux découvert par les autres objets de la société.
-autres avatars de la société (ici le store).
-==== Couples Producteur-Similarité ====
+Nous allons voir plus en détail dans cette partie le fonctionnement
+du système d'apprentissage de l'avatar du système d'éclairage.
-Le système multi agents d'apprentissage implémente
+=== Découverte d'évènements ===
-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) ===
+La découverte de motifs récurrents à partir des entrées continues
+que sont V<sub>1:1</sub> et V<sub>1:2</sub> est fait les couples
-L'apprentissage de la découpe d'une variable
+formés par des agents Découper et des agents Similarité paramétrés
-d'entrée est implémenté par un couple D-S. Leurs
+de diverses manières.
-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>
+Comme dit précédemment, le système d'apprentissage doit commencer
-a pour paramètre un Δt qui est la taille de la fenêtre de découpe.
+par essayer d'extraire des informations liés à ses variables d'entrées
+avant d'essayer de les relier à un quelconque évènement "extérieur"
+(de plus, à cette étape du scénario aucun flux n'est disponible pour
+l'autre objet).
+Ce travail de découpe est effectué par les agents Découper du système
+d'apprentissage. Ceux-ci, suivant divers paramètres, vont "déplacer"
+une fenêtre de découpe le long de la variable. Ces fragments de
+variables sont décrit à l'aide d'histogrammes par les agents Découper.
 {{wiki:decoupe.png}}
-L'agent Découper va alors parcourir la variable d'entrée en faisant
+Ces fragments de variables sont évaluer via un feedback //d'intérêt//,
-"glisser" sa fenêtre de découpe le long des variations. La fenêtre
+aidant ainsi à la sélection des paramètres de découpe par l'agent Découper.
-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
+== Création de Flux ==
-la forme d'un histogramme.
-== Similarité ==
+La découverte d'évènements récurrents se fait à l'aide d'un couple
+d'agent Découper et Similarité. L'agent Découper faisant varier
+ses paramètres de découpe et l'agent Similarité faisant varier
+ses paramètres de différenciation, les deux en fonction de la
+variable d'entrée à laquelle ils sont associés.
-Les histogrammes produit par l'agent Découper sont alors récupéré
+La qualité des paramètres, évaluée à partir d'un feedback //d'intérêt//,
-par l'agent Similarité qui lui associé.
+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é).
-Celui ci compare les nouvelles instances d'évènement avec ceux qu'il
+Cet espace de marque sert à garder, dans un espace commun de recherche
-a stocké précédemment, ou plutôt avec l'histogramme représentant la moyenne
+de paramètres à tous les couples d'agents, la trace de l'utilisation de
-de chaque groupe d'instances similaires. Cette "moyenne" peut être considéré
+certains paramètres et leurs qualités.
-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 :
+Une fois qu'un couple, ou plutôt l'agent Similarité d'un couple d'agent,
-  - Les variables ou flux, auquels peuvent se lier les couples.
+aura déterminé qu'un //concept d'évènement// est assez récurrent il créera
-  - Les paramètres possibles de l'agent //Producteur//.
+un //flux d'instances d'évènements// dans lequel il fera passer les //instances//
-  - Les paramètres possibles de l'agent //Similarité//.
+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
-Cet **espace en trois dimensions** sert de "mémoire" au
+Association des autres systèmes d'apprentissage.
-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
+{{wiki:flux_creation.png}}
-différencient en deux types : les **Explorateurs** et les
-**Exploiteurs**.
-=== Les explorateurs ===
-Comme leurs nom l'indique, ceux sont les couples "bougeant"
+Pour connaitre la similarité, ou plutôt le pourcentage de similarité, entre deux
-le plus dans l'espace de marquage, afin de déterminer
+instances d'évènement, l'agent Similarité utilise une fonction d'intersection des
-rapidement quels sont les paramètres les plus pertinents
+histogrammes représentants les instances.
-pour une variable donnée.
-Les //Explorateurs// commencent par se fixer à une position
+{{wiki:similarite.png}}
-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
+=== Partage d'évènements ===
-l'emplacement de l'intérêt maximum trouvé, puis se redéplacent.
-=== Les exploiteurs ===
+A peu près même moment que le système d'apprentissage de l'éclairage
+créé ses //flux d'instances//, des //flux d'instances externes// font
+leur apparitions.
-Ce type de couple se fixe sur les emplacements les plus
+Une notation possible est présentée ci-dessous. Noté **F**, un flux est
-marqués, peuvent se déplacer légèrement autour et se
+identifié par l'ip de l'objet fournissant le flux et l'id de ce flux.
-"téléporter" d'un emplacement pertinent à un autre.
+De la même manière sont notés **e** les //concepts d'évènements// associés
+à un flux, il sont donc identifiés de la même manière que les flux, avec
+id et ip.
-Les //Exploiteurs// continue de marquer l'intérêt de
+{{wiki:flux_notation.png}}
-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 ====
+Pour simplifier la notation pour le scénario, l'ip du système d'éclairage
+sera 1 et l'ip du store électrique sera 2. L'ip 0 est considéré comme un
+"localhost", se sont les flux identifiés comme personnels par l'objet,
+le fait de donner un ip 0 pour identifié le "moi" est totalement
+arbitraire, un flux pourrait garder l'ip de l'objet apprenant, cependant
+les agents du système d'apprentissage, en particulier les agents Découper,
+devraient être capables de différencier les flux personnels et les flux
+extérieurs.
-Dans la section précédente nous avons parlé du marquage
+Ainsi le système d'apprentissage voit apparaître, à peu près au même moment,
-d'un intérêt dans **l'espace de marquage**. Celui-ci est
+des flux d'instances //interne// (avec un ip 0) et des flux d'instances
-calculé à partir d'un **feedback d'intérêt** dont se sert
+//externes// (avec un ip différent de 0).
-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 ===
+Les couples d'agents formés par des agents Association et Similarité vont
+alors rechercher différentes Association de concepts d'évènements possibles
-Une découpe de variable, ou une association de flux, est évalué sur
+et pertinents.
-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é**,
+{{wiki:flux_association.png}}
-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
+Les Associations vont être faites en prenant prioritairement en références
-entre l'évènement et la moyenne générale de tous les évènements. La
+les flux internes du système d'apprentissage. Cet aspect "égoïste" de
-spécificité permet ainsi d'identifier les évènements "sortant du lot".
+l'apprentissage est nécessaire pour éviter une redondance de l'apprentissage
+dans tous les avatars de la société, et permet aussi une spécialisation
+de ces mêmes avatars. En effet, les avatars d'objets possédant peu de
+capteurs et d'actionneurs seront plus enclin a tenter d'associer des évènements
+provenant de flux externes; à l'inverse des avatars d'objets possédant beaucoup
+de capteurs et d'actionneurs seront plus enclin à se concentrer uniquement sur
+le découpage de leur variables d'entrées et sur la découverte de concepts d'évènements
+"intéressants".
-Le **poids** d'un évènement correspond à son nombre d'occurence
+==== Point de vue du store électrique (Orienté Scénario) ====
-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é
+Dans le point de vue précédent, l'accent a été mis sur le fonctionnement
-à partir de l'écart type des similarités entre les instances d'un
+globale du modèle. De ce point de vue, au contraire, nous allons nous
-évènement.
+concentré, pas à pas, sur les suites logiques d'évènements pouvant arriver
+à un système d'apprentissage.
-=== L'intérêt interpersonnel ===
+=== Variables d'entrées et Découpe ===
-Pour nuancer le poids de l'intérêt intrapersonnel sur l'intérêt
+Reprennons à partir de la découpe d'une variable d'entrée,
-global d'un évènement, et aussi pour éviter une certaine redondance
+par exemple V<sub>2:2</sub>.
-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
+{{wiki:V2_2.png}}
-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
+== Couple Découper - Similarité (D-S) ==
-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
+L'apprentissage de la découpe d'une variable
-que de flux/variables internes, puis aux évènements associant un flux interne
+d'entrée est implémenté par un couple D-S. Leurs
-et externe, et enfin les associations de deux flux externes.
+intéractions, 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.
-<note tip>
+== Découpe ==
-Concernant les motifs "d'intéraction" :
-Une certaine redondance de l'apprentissage se retrouve lors de la
+L'agent Découper d'un couple D-S associé à la variable V<sub>2:2</sub>
-découverte de motifs dit "d'intéraction", c'est à dire mettant
+a pour paramètre un Δt qui est la taille de la fenêtre de découpe.
-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) :
+{{wiki:decoupe.png}}
-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 ?
+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.
-Doit-on utiliser cette redondance à notre avantage et l'utiliser
+La portion découpée par l'agent Découper est alors représenté sous
-pour faire un consensus sur des motifs communs à certains objet ?
+la forme d'un histogramme.
-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 ?
+== Similarité et Différenciation ==
-Ne pourait on pas faire en sorte "d'orienter" l'apprentissage
+Les histogrammes produit par l'agent Découper sont alors récupéré
-pour qu'un minimum de système, au mieux un seul, découvre ce motif ?
+par l'agent Similarité qui lui associé.
-Personellement je penche plus vers ce second point de vue. Nous
+Celui ci compare les nouvelles instances d'évènement avec ceux qu'il
-pourrions par exemple donner plus d'intérêt à un concept d'association,
+a stocké précédemment, ou plutôt avec l'histogramme représentant la moyenne
-ou d'interaction, si l'évènement e2 de cette association est capté par un flux
+de chaque groupe d'instances similaires. Cette "moyenne" peut être considéré
-interne.
+comme un pré-concept d'évènement.
-Pour reprendre l'exemple: dans l'association "ouverture store" -> "augmentation
+La fonction de comparaison utilisée pour différencier les instances découpées
-luminosité", e2 provient d'un flux interne pour le système d'éclairage l'association
+en une fonction d'intersection entre les deux histogrammes représentant les
-et d'un flux externe pour le store. L'association aura donc un plus fort intérêt à
+instances.
-ê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"
+{{wiki:similarite.png}}
-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
+Ainsi l'agent Similarité du couple D-S "rangera" les nouvelles instances
-(avis personnel), quand bien même qu'avant d'être diffusé un motif est passé par une
+d'évènements avec celles qui lui sont le plus similaire, modifiant par la
-longue phase vérification, donc les systèmes n'ont pas vraiment de "raison" vérifier la
+même la moyenne de ce groupe d'instance. Si aucun groupe n'est trouvé pour
-véracité d'un motif, juste de regarder si il leur est utile ou non. De plus les systèmes
+une instance, alors un nouveau lui correspondant sera créé.
-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>
+n.b: le paramètre de l'agent Similarité serait sont seuil d'acceptation
+de similarité, mais cela reste à confirmer.
-=== Calcul du feedback ===
+== Feedback et sélection de concept ==
-Le feedback d'intérêt **Ί** d'un évènement e se calcule donc à partir du rapport
+Avant que la moyenne d'un groupe d'instance soit considérée comme un réel
-de son intérêt intrapersonnel **Ί<sub>α</sub>** sur son intérêt interpersonnel
+concept d'évènement, l'agent Similarité d'un couple D-S va calculer l'intérêt
-**Ί<sub>ε</sub>**.
+de chaque pré-concept, et marquer le maximum de ces intérêts dans l'espace de
+marquage des couple D-S.
-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 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 récurence de cet évènement. Pour faire simple, parmis 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>
-Ί(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 **Ί** un découpage :
-Ίε(e) = (Nb_Var_Necessary(e) + 1) - Nb_Internal_Var_Used(e)
-      = 1 + 1 - 1 = 1.
-=> Ί(e) = Ία(e)
-</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)
+    TODO: equation with MathJax
-et
-  acc = 1 - ( tol * freq(e2) )
 </code>
-Le maximum des scores est ajouté à l'intérêt dans l'espace de marquage des
+C'est lorsqu'un couple D-S de type //Exploiteur// se positionnera, dans l'espace
-couple A-S pour la variable et les paramètres associés, leurs donnant ainsi
+de marquage, sur les paramètres de découpe de V<sub>2:2</sub> que la création de
-plus de poids.
+Flux d'instance se fera pour les concept ayant la plus haute spécificité.
+== Conception de flux d'instances ==
-<note tip>
+Comme dit précédemment, les couples D-S vont extraire
-Pour l'instant le feedback prédictif sera utilisé comme ceci, mais
+des //concepts d'évènements// et créer des //flux d'instances d'évènements//.
-n'est pas exclu d'être modifié.
+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.
-Une possibilité serait d'utiliser les formules utilisées en statistique
+Supposons qu'à partir de V<sub>2:2</sub> deux concepts d'évènements soient
-pour évaluer un classifieur.
+créés.
-Le score serait calculé à partir :
+{{wiki:conceptualisation_nntp.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).
+Il y aura donc deux flux de créé par le couple D-S affecté à cette variable
+d'entrée. Ces flux étant internes du point de vue du store et externe
+du point de vue du système d'éclairage.
-  * 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.
+<code>
+Exemple de description d'un flux en JSON-LD :
-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
+  "@context": "http://www.w3.org/ns/activitystreams",
-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
+  "@type": "Activity",
-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 ====
+  "published": "2016-01-25T12:34:56Z"
-Lorsqu'un concept d'évènement, qu'il soit découvert part un couple D-S
+  "author": {
-ou A-S, est déterminé comme "intéressant" alors un **flux d'instances**
+    "@type": "Object",
-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 ===
+    "@id": "URI de l'objet / URI du flux"
+  }
-Du point de vue d'un système, et donc de ses agents, un flux est perçu
+  "orderedItems": [
-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.
+      "@type": "Event"
-<note>
+        ...
-Par exemple :
+    },
+    {
+      "@type": "Event"
-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.
+</code>
-A l'inverse, les flux correspondant aux concepts : store s'ouvrent, store
+n.b: Le fonctionnement de l'API de notification et de partage de flux n'est pour
-se ferme; seront perçu comme des **flux externes**.
+l'instant pas clairement définie.
-</note>
-Pour aider à l'identification d'un flux par un système, et ses agents,
+=== Flux d'instances et Association ===
-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}}
+Reprennons à partir du moment où tous les flux (internes et externes)
+de tous les objets de la société soient créés et accessibles par le store.
-<note>
+C'est à dire :
-TODO : mettre à jour l'image quand une notation aura été définie.
-</note>
-=== API de transfert d'instances ===
+  * 4 flux internes correspondant à :
+    * V2:1 à 1 pendant un certain temps.
-<note important>
+    * V2:1 à -1 pendant un certain temps.
-Le fonctionnement de l'API de flux n'est, pour le moment, pas clairement
+    * V2:2 augmentant progressivement de 0 à 1.
-définie. Ce qui est écrit dans cette section sont des idées sur le fonctionnement
+    * V2:2 diminuant progressivement de 1 à 0.
-général de l'API et sur l'adaptation possible de protocoles, API ou frameworks déjà
+  * 6 flux externes correspondant à :
-existant pour les besoins du système d'apprentissage.
+    * V1:1 passant de 0 à 1 instantanément.
-</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 ====
+===== Problèmes =====
-Nous allons maintenant voir comment les **couples Découper-Similarité** génèrent, trient
+  * Supposons que dans cette pièce nous rajoutons un chauffage électrique connecté, comment faire en sorte que les échanges entre les objets se "spécialisent" ?
-et évaluent des instances d'évènements, et aussi comment ils explorent **l'espace de
-marquage**.
-=== Exploration de l'espace de marquage ===
+Les évènements proposé par les flux d'instances du chauffage sont en effet peu utile pour le
+système d'éclairage (peut être un peu moins pour le store),
+le but ici serait qu'au flux externes d'un système, voir à tout l'objet proposant ces flux,
+soit associé un feedback "d'utilité". Puisque les systèmes
+d'apprentissage cherche prioritairement des associations avec pour référence leurs
+flux d'instances internes, nous pouvons facilement l'imaginer évaluer l'utilité
+d'un flux d'instances externes lui ayant permis ou non de trouver des motifs
+avec pour références ses concepts personnels.
-Au début de son apprentissage l'espace de marquage est vide, ou nul, sans aucun
+  * 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 ?
-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
+  * 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 ?
-à 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 à 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>
+  * Comment les avatars pourrait arriver, de manière émergente, à un consensus concernant un motif, pour que celui soit "commun" à la société ou à un groupe ?

DokuWiki

Site Tools

Differences

Page Tools