Ce scénario reprend le principe de flux d'instances d'évènements entre les différents avatars définit dans une réflexion sur la création de pattern pour un objet sans capteur.
Dans une même pièce se trouve :
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.
L'action se déroule dans le bureau de notre utilisateur, Billy, et ce durant plusieurs semaines.
Billy, notre utilisateur, se lève et se rend dans son bureau. Faisant encore nuit, Billy allume la lumière, il est 6h.
Vers 8h Billy sait qu'il fait jour dehors, il éteint donc la lumière et ouvre en grand les stores électrique de sa fenêtre.
Ceux-ci reste ouvert jusqu'à ce que, vers 19h, Billy se rende compte que le soleil se couche. Billy allume donc la lumière de son bureau, puis ferme les stores.
Billy reste ensuite dans son bureau jusqu'à 22h, il éteint alors la lumière avant de partir.
(oui, Billy travaille beaucoup plus qu'il ne le devrait).
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.
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.
Si nous prenons le point de vue du système d'éclairage, celui-ci sera capable de découvrir, dans un premier temps, des motifs liés à ses propres capteurs et actionneurs (puisque aucun flux n'est disponible pour le moment).
Puis dans un second temps de faire le lien entre ses motifs et ceux découvert par les autres objets de la société.
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.
La découverte de motifs récurrents à partir des entrées continues que sont V1:1 et V1:2 est fait les couples formés par des agents Découper et des agents Similarité paramétrés de diverses manières.
Comme dit précédemment, le système d'apprentissage doit commencer 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.
Ces fragments de variables sont évaluer via un feedback d'intérêt, aidant ainsi à la sélection des paramètres de découpe par l'agent Découper.
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.
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 de paramètres à tous les couples d'agents, la trace de l'utilisation de certains paramètres et leurs qualités.
Une fois qu'un couple, ou plutôt l'agent Similarité d'un couple d'agent, 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.
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.
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.
Une notation possible est présentée ci-dessous. Noté F, un flux est identifié par l'ip de l'objet fournissant le flux et l'id de ce flux. 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.
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.
Ainsi le système d'apprentissage voit apparaître, à peu près au même moment, des flux d'instances interne (avec un ip 0) et des flux d'instances externes (avec un ip différent de 0).
Les couples d'agents formés par des agents Association et Similarité vont alors rechercher différentes Association de concepts d'évènements possibles et pertinents.
Les Associations vont être faites en prenant prioritairement en références les flux internes du système d'apprentissage. Cet aspect “égoïste” de 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”.
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.
Reprennons à partir de la découpe d'une variable d'entrée, par exemple V2:2.
L'apprentissage de la découpe d'une variable d'entrée est implémenté par un couple D-S. Leurs 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.
L'agent Découper d'un couple D-S associé à la variable V2:2 a pour paramètre un Δt qui est la taille de la fenêtre de découpe.
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.
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.
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 sont seuil d'acceptation de similarité, mais cela reste à confirmer. </note>
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, 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.
intérêt = spécificité + redondance
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 V2:2 que la création de Flux d'instance se fera pour les concept ayant la plus haute spécificité.
<note important> Le fonctionnement de l'API de flux n'est, pour le moment, pas clairement définie. </note>
Comme dit précédemment, les couples D-S vont extraire 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 V2:2 deux concepts d'évènements soient créés.
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.
Exemple de description d'un flux en JSON-LD :
{
"@context": "http://www.w3.org/ns/activitystreams",
"@type": "Activity",
"published": "2016-01-25T12:34:56Z"
"author": {
"@type": "Object",
"@id": "URI de l'objet / URI du flux"
}
"orderedItems": [
{
"@type": "Event"
...
},
{
"@type": "Event"
...
}
]
}
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.
C'est à dire :
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.
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 reférence.
Comme pour le couple D-S, l'agent Similarité récupére et classe les instances de l'association récupérées. L'instance d'une association est, en partie, caractérisée par le delai entre la reférence et le flux associé, délai pouvant bien entendu être négatif.
Un feedback d'intérêt est alors appliqué aux associations découvertes par le couple A-S. Ce feedback est composé de deux intérêts :
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 redondance du type d'instance évalué, exactement comme le feedback des couples D-S.
L'association des flux évalué sur sa capacité à découvrir des motifs 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é dans l'association et, s'il n'y a qu'un seul flux interne dans l'association, de “la place” de l'instance interne dans l'association. Si le flux interne émet une instance après la captation d'une instance provenant d'un flux externe alors l'association aura plus de poids que si ça avait été l'inverse. La notion, plutôt arbitraire, de “place” se base sur le prédicat qu'il y a de la latence entre deux avatars, entre l'émission et la réception d'une instance d'évènement, ainsi il semble plus logique que se soit l'avatar “finissant” un motif qui tente de le prédire et d'avertir les autres avatars de l'arrivé de l'association.
Ainsi l'intérêt d'une association est calculé à partir de l'intérêt égoiste et altruiste.
intérêt = intérêt égoiste ^ alpha * intérêt altruiste ^ beta <=> intérêt = ( ( spécificité + redondance ) ^ alpha ) * ( ( nb_flux_interne + f(nb_flux_interne) ) ^ beta ) Les coefficients alpha et beta sont ici pour donner plus de poids à l'une ou l'autre des parties de l'intérêt, par défaut nous pouvons les considérer comme égale à 1. f(nb_flux_interne), retourne : * 0 si il n'y a aucun flux interne dans l'association, ou si il y a un flux interne et que ses instances arrivent avant. * 1 si il y a flux interne et que ses instances arrivent après. * 2 si les deux flux sont internes.
<note tip> Nous retrouvons ici le principe de cycle intrapersonnel-interpersonnel de Doise et Mugny. </note>
A partir de ce feedback d'intérêt, marqué par les couples A-S de type Explorateur, les couples A-S vont pouvoir tenter d'évaluer, à l'aide d'un second feedback, la capacité prédictrice des paramètres ayant le plus fort intérêt.
De nouveaux flux sont alors créé pour les évènements association les plus pertinents, donc en priorité ceux dont l'avatar associe deux évènements internes, ou un évènement externe puis un évènement interne.
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.