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
Reprennons à partir de la découpe d'une variable d'entrée, par exemple V2:2.
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 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.
Découpe
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.
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.
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éé.
n.b: le paramètre de l'agent Similarité serait sont seuil d'acceptation de similarité, mais cela reste à confirmer.
Feedback et sélection de concept
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 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.
TODO: equation with MathJax
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é.
Conception de flux d'instances
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.
TODO : image
Il y aura donc de 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"
...
}
]
}
n.b: Le fonctionnement de l'API de notification et de partage de flux n'est pour l'instant pas clairement définie.
Flux d'instances et Association
Reprennons à partir du moment où tous les flux (internes et externes) de tous les objets de la société soient créés et accessible par le store.
Problèmes
- 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” ?
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.
- 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 ?
- 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 ?
