Soyons en contact

 

L'intelligence Artificielle dans TRQL

11-02-2017 - 10:2615-07-2019 - 10:51

Cette page doit davantage se lire comme un journal que comme un texte délié.

11/02/2017

De quoi s'agit-il lorsque nous parlons d'Intelligence Artificielle dans TRQL ?

S'agit-il de systèmes capables d'agir ou de penser comme des humains ? Non, ce n'est pas ce que TRQL essaye d'accomplir (bien qu'une définition de Kurzweil nous convienne assez bien qui se classe néanmoins dans la catégorie des systèmes qui agissent comme des humains). S'agit-il de penser ou d'agir rationnellement ? Oui, en partie.

TRQL correspond ainsi plus ou moins bien aux 3 définitions de l'Intelligence Artificielle suivantes :

L'étude des moyens informatiques qui rendent possibles la perception, le raisonnement et l'action. — , 1992.
[…] l'étude de la conception d'agents Intelligents. — , 1998
l'étude du comportement intelligent dans des artéfacts. — , 1998.

En-dehors de ces définitions que nous trouvons pertinentes dans notre travail, nous cherchons aussi à concevoir un système capable d'agir sur lui-même, un système réflexif à défaut d'être conscient, trop ambitieux à ce stade. Par système réflexif nous entendons, par exemple, un système dont le code informatique est capable de se modifier lui-même (ce que TRQL est déjà capable de faire en mode très mineur).

Voici la définition de Kurzweil qui correspond néanmoins à ce que TRQL tente de réaliser, en particulier dans le développement de notre module AKNTI-FLY, un module dont l'objectif est de catégoriser automatiquement les dépenses (notes de frais, factures, etc.) :

L'art de créer des machines capables de prendre en charge des fonctions exigeant de l'intelligence quand elles sont réalisées par des gens. — , 1990.

Aujourd'hui, nous avons mis en place les mécanismes de senseurs qui collectent les informations que nous pensons déterminantes pour les objectifs que nous nous fixons : nous les appelons “impulsions” ou “pulses”. Nous avons néanmoins été sensibles, et continuons à l'être, à la flexibilité du système parce que nous savons qu'il devra évoluer au fur et à mesure de nos avancées, avancées impossibles à anticiper dans le détail : nous savons qu'elles auront lieu; nous ne savons pas ce qu'elles seront. Ainsi, les pulses, bien qu'ils aient une structure générale définie (représentation générale de la connaissance, du moins une fois traitée par le Cardio — voire plus loin), ont aussi une structure interne variable (représentation spécifique d'une connaissance particulière, toujours une fois que le pulse a été traité par le Cardio). Par exemple, un pulse qui indique une tentative de hacking (HACKING_PULSE) n'a pas la même structure interne qu'un pulse qui décrit une condition d'erreur (ERROR_PULSE), bien qu'il ait exactement la même enveloppe. À ce stade de notre développement, cette structure nous suffit mais nous sommes bien en peine de nous prononcer sur la structure définitive. Nous admettons cette incertitude, nous l'acceptons.

Les impulsions, ou pulses donc, sont centralisées. On peut voir cela comme le cerveau du système bien que “cerveau” soit, à ce stade, un excès de langage que nous ne nous permettons pas (“cerebellum” —(petite) cervelle, “siège de la pensée”). Ce centre nous l'appelons TRQL Cardio : il traite les impulsions et les catégorise et les stocke (constitution de la mémoire). Rien de plus, du moins à ce jour, soit le 11/02/2017 à 10:50. Certaines impulsions ont pourtant plus d'importance que d'autres à nos yeux, dans notre contexte actuel — la notion de contexte est importantissime, non seulement le nôtre, mais aussi le contexte des impulsions. C'est ainsi qu'aujourd'hui nous attachons pas mal d'importance aux impulsions qui décrivent des conditions d'erreur (ERROR_PULSE) et d'avertissement (WARNING_PULSE). En la présence de telles impulsions, notre Cardio se charge d'alimenter automatiquement notre backlog, implémentant en cela le troisième paradigme de DevOps : la mise en place de boucles de feedbacks automatiques. Au passage, notez également que la mise en place de cette boucle automatisée change la face même du testing et de la manière de s'en acquitter. Comme on le voit, notre implémentation de l'Intelligence Artificielle, même excessivement limitée — à tel point qu'on a parfois l'impression d'exagérer — a des impacts sur le processus même de développement. Ceci est intéressant à plus d'un titre et j'essaierai de décrire ces influences au fur et à mesure.

À vrai dire, nous continuons à ajouter des senseurs à gauche et droite (des pulses) et nous nous attachons à faire en sorte que le Cardio puisse y répondre, même si cela reste très modeste : l'intelligence de TRQL dépend (1) du nombre et de la finesse des senseurs en place (2) de la capacité du système d'y répondre par des décisions automatiques et utiles (qui ont de la valeur) de plus en plus fines au fur et à mesure de notre travail.

Tout ceci correspond à la définition d'un système rationnel : Un système est rationnel s'il opère de manière appropriée compte tenu de ce qu'il sait. Stuart Russel, Peter Norvig. J'ajoute, comme le précisent d'ailleurs Russel et Norvig, qu'un tel système fait appel aux mathématiques et aux statistiques (“d'ingénierie”, disent les auteurs), et c'est ce que fait d'ailleurs TRQL en ayant recours aux analyses prédictives que permet la formule de Bayes.

Mémoire

Un petit ex-cursus sur la mémoire m'apparaît idoine. En effet, nous venons de voir que TRQL est un système rationnel et, qu'en tant que tel, il doit engranger de la connaissance (“compte tenu de ce qu'il sait”). Cela implique le “stockage des données”, leur “transformation en informations”, le “stockage desdites informations”, leur “restitution”, et enfin leur utilisation ou “exploitation”. C'est de tout cela dont il s'agit lorsque nous parlons de mémoire. J'aurai l'occasion d'y revenir lorsque nos développements sur le sujet seront suffisamment intéressants. Pour l'instant nos développements génèrent d'autres préoccupations au centre desquelles se trouve … l'oubli, la capacité d'oublier.

En effet, l'oubli et la capacité d'oublier est une fonction importante de toute mémoire[/figcaption]. Sans oubli, on en serait à prendre des décisions sur base de données et d'informations qui se sont révélées sinon fausses au moins inintéressantes, accessoires ou dérisoires. En tant qu'être humain nous ne portons pas suffisamment d'attention à ce que nous avons oublié. C'est au moins aussi important que ce que nous avons retenu. Nous imaginons cependant que le cerveau humain garde trace de patterns de ce qu'il est bon de ne pas retenir afin de pouvoir, quand ce genre de données refait son apparition, la filtrer à propos. Là encore une réflexion générale doit se faire : ce qu'il était bon d'oublier dans le temps devrait peut-être considéré maintenant simplement parce que le contexte n'est plus le même. Pour être pratique, un système informatique doit donc être capable d'oublier mais de se souvenir des conditions de son oubli, lesquelles doivent être régulièrement réévaluées. Nous avons très vite découvert cette nécessité d'oubli lorsque notre Cardio a capturé 4490 impulsions en une nuit. Toutes ces impulsions étaient totalement correctes mais leur étude a démontré leur côté parfaitement secondaire. L'oubli, en la circonstance, a consisté en l'effacement manuel des impulsions reçues. Mais cela a généré un nouveau besoin (nouvelle exigence) que nous avons immédiatement placé dans notre backlog : tous les pulses non traités après 2 mois doivent être éliminés. La rationalité de ce besoin est la suivante : si le pulse n'a pas été traité dans les 2 mois c'est qu'il y en a toujours d'autres plus urgents à traiter d'abord et ce n'est pas la peine de les garder car cela ne fait qu'encombrer le système, ici … sa mémoire, et ralentir toutes les opérations qui traitent les impulsions.

La capacité d'oubli est aussi nécessaire lorsque les impulsions ET leur traitement sont en genèse (développement non terminé). On peut penser que c'est parfaitement accessoire, que cela n'arrive qu'au début de la naissance du système. En vérité c'est le propre des systèmes intelligents d'être en genèse permanente — c'est d'ailleurs la raison fondamentale pour laquelle TRQL est toujours annoncé dans sa phase beta et cela n'est pas prêt de changer — et donc ce sera plus la normalité que l'exception. Par exemple, lorsque les premiers pulses de création de page ont été conçus (PAGE_CREATION_PULSE et PAGE_EDITION_PULSE), ils n'avaient pas la maturité (toute relative) des pulses actuels. Est-il donc encore utile de garder les tout premiers pulses de ces catégories ? Non ! Il faut les oublier ! Ce principe peut être aisément démontré par le cas réel suivant :

  1. Une alerte de type warning nous a prévenu que l'affichage de mots-clés dans les pages web causait un problème.
  2. Une correction a été apportée au code
  3. La correction causait plus de problèmes encore, jusqu'à générer 2813 nouvelles alertes, toutes de même type

La question se posait donc en ces termes : la nouvelle alerte, bien que justifiée, a causé un encombrement du TRQL Cardio. Il aurait été plus intéressant de stocker une seule fois l'alerte au lieu de 2813 fois, mais cette unique information aurait dû s'accompagner d'une autre information : cela est arrivé 2813 fois ! AU lieu de 2813 alertes, le Cardio aurait dû transformer le problème en une seule alerte flanquée d'un attribut de sévérité ou d'importance ("c'est arrivé 2813 fois en 1/2 heure !"). On le voit donc bien, la capacité d'oublier est importante comme l'est la capacité à se souvenir du pourquoi on a oublié (ici la récurrence du même problème). Ce problème a été résolu, dans le cas de TRQL, en se basant sur un md5() du texte principal du warning : pas la peine de garder des alertes en de multiples exemplaires si leur md5 est identique dans un contexte donné (ici, le moment auquel le problème est survenu constitue un élément clef de la décision “oubli” ou “pas oubli” — il suffirait qu'un problème similaire se présente dans le futur suite à un bug de non régression pour qu'on se mette à l'oublier parce qu'un jour il a pu l'être !).

Apprentissage

Je n'ai quasi rien dit de la capacité d'apprentissage. C'est à dessein ! Bien que TRQL possède à ce stade d'une capacité d'apprentissage, celle-ci est embryonnaire et ne permet pas de déclarer que l'apprentissage est au cœur de notre solution. Ce serait de l'exagération gratuite. Néanmoins, voyons ce que l'équipe TRQL envisagé lorsqu'elle parle d'apprentissage. Il s'agit essentiellement des quatre éléments suivants :

  1. Détecter les invariants et leur contexte,
  2. Extrapoler les invariants dans des contextes similaires,
  3. Tenir compte des exceptions, leur assigner une probabilité d'apparition,
  4. Déterminer des périodes d'expérience (recolte de nouvelles connaissances) et des périodes d'exploitation des connaissances récoltées. Cela peut se résumer par la capacité de s'adapter (notamment à de nouveaux contextes)

12/02/2017

Nous avons continué à établir des senseurs dans le code de TRQL. Aujourd'hui nous avons implémenté les EMPTY_PAGE_DESCRIPTION_PULSE. Cette implémentation a été intéressante à plus d'un titre. Voici pourquoi.

Tout d'abord, avant ce jour, TRQL n'exigeait pas de description de page pour chaque page créée. Dès lors, un nombre incalculable de pulses ont été envoyés vers le Cardio pour signaler les pages qui n'avaient pas de description : 8896 en deux heures de temps! Parmi ces pulses (ou notifications si vous préférez) il y avait donc énormément de doublons : chaque fois que la même page était demandée, un nouveau pulse du même type était envoyé, pour la même page. Il était donc indispensable de se souvenir que tel pulse n'était pas différent d'un autre reçu précédemment, implémentant en cela la capacité à oublier.

Par une représentation interne de la connaissance sous forme simple de hashage nous avons été capables de nous "souvenir" que cette "erreur" particulière avait déjà été rencontrée : le nom de la page, combiné à son type de pulse, formait la valeur à hasher, ce que nous avons fait par un simple md5() stocké dans un fichier dont le nom était formé sur base de la valeur de hashage (exemple: cb5ead95928c1f073c172c68b982f7d2.dejavu-pattern). Voici un extrait de notre code:

case EMPTY_PAGE_DESCRIPTION_PULSE:
    {
        $oPage = $oQP->xCargo;

        if ( isset( $oPage->szShelter ) )
        {
            $szDejaVuPattern    = md5( $oPage->szShelter );

            // Have we seen this before
            if ( FIL_Exists( $szPulsesDir . '/' . $szDejaVuPattern . '.dejavu-pattern' ) )
            {
                $bRetVal = true;
            }
            else
            {
                // Let's remember this pattern
                FIL_StrToFile( $szDejaVuPattern,$szPulsesDir . '/' . $szDejaVuPattern . '.dejavu-pattern' );
            }
        }
    }
    break;

Après quelques heures de travail à modifier TRQL tout gardant notre code compatible avec les versions antérieures, nous avons laissé le système tourner pour voir comment il évoluait. Les conclusions ne sont pas encore finales — nous tirerons des conclusions objectives après plusieurs jours de fonctionnement — mais nous avons pu observer que des conditions de “déjà vu” se rencontraient dans 37% des cas après seulement 82 minutes de fonctionnement. Ce résultat nous a beaucoup satisfait. Nous avons néanmoins continué à améliorer nos sources et sommes maintenant en attente d'un résultat quantifié totalement objectif.

Quel était le but poursuivi avec ce nouveau senseur (EMPTY_PAGE_DESCRIPTION_PULSE)? En fait ce genre de pulse se donne pour but de débusquer les pages qui pourraient être pénalisées par les moteurs de recherche parce que sans description (condition dans laquelle TRQL préfère déjà positionner la description générale du site que de ne pas avoir de description du tou). Pour être sûr que nous poursuivons une valeur concrète nous allons établir une boucle de feedback. Cette boucle sera établir entre le Cardio et le le code qui s'exécute dans l'espace même d'un site web donné. Si les pulses EMPTY_PAGE_DESCRIPTION_PULSE ne sont pas traités par le responsable d'un site endéans un temps raisonnable, alors nous désactiverons l'envoi de tels pulses au départ du site web considéré parce que considérés comme gâchis, comme stérile. Cela correspond à l'attitude de quelqu'un qui décide de ne plus faire ce qu'il juge désormais sans objet. Cette boucle automatisée sera mise en place dans les jours qui suivent et nous devrons évaluer son fonctionnement de manière objective.

À avoir vu le mot “objectif” un certain nombre de fois, vous pensez certainement que nous insistons lourdement sur le caractère objectif des décisions qui sont prises, que ce soit par nous ou via notre code. C'est effectivement le cas et pour ce faire nous collectons des compteurs qui nous permettent de chiffrer et mesurer précisément tous ces paramètres. Cela fait indéniablement partie du paradigme de l'AI: établir dans le code les compteurs qui vont bien ! Pas de mesure, pas d'intelligence, pas de science. Ces compteurs sont donc indispensables au système même. Ils échappent malheureusement — ou serait-ce heureusement ? — complètement aux spécifications fonctionnelles habituelles; ils sont même souvent impossibles à détecter en-dehors de la phase de coding qui devient ainsi un design évolutif permanent. Il faut en être conscient et accepter ce travail comme partie intégrante du boulot à réaliser.

Au rang de ces mesures, voici ce que nous avons collecté après les dernières modifications entreprises sur TRQL : 6557 pulses entre 17:13 et 20:02, dont 530 "no-page-desc", 2 "sitemap", 5377 "déjavu" (pulses rejetés car forme de doublon), 538 "dejavu-pattern", 6 "page-edition", 104 "pulse" (pas encore traités). Ces mesures nous permettent de nous rendre compte de l'importance de l'oubli : 5377 / 6557 = 82% des pulses récoltés. Si nous n'avions pas implémenté la faculté d'oubli, et si l'échantillon récolté en 2h49 minutes peut être considéré comme représentatif, nous serions amener à récolter 82% d'informations inutiles. Un fameux gâchis.

13/02/2017

Représentation des connaissances

Pour le Cardio qui n'a à traiter que des pulses, il ne lui faut qu'en connaître la structure. Un pulse prend la forme d'un tableau à deux cellules. La première cellule (son indice 0) indique le type de pulse (HACKING_PULSE, ERROR_PULSE, …). La deuxième cellule n'est rien d'autre qu'un cargo, une cellule dont l'interprétation dépendra de la valeur de la première cellule).

17/02/2017

Systèmes auto-organisés et émergence

L'idée des pulses s'est généralisée dans TRQL. Nous commençons à utiliser des pulses pour des sujets pour lesquels ils n'étaient pas faits au départ. Ceci me rappelle une interpellation de Sugata Mitra qui disait ceci des systèmes auto-organisés :

A self-organizing system is one where the system structure appears without explicit intervention from outside the system. A self-organizing system also always shows emergence which is that the system starts to do things it was never designed for. Emergence, the appearance of a property not previously observed as a functional characteristic of the system. — in The child-driven education

Cette évolution n'était pas du tout anticipée : nous avons commencé à utiliser le système des pulses pour s'occuper de tâches différées. L'envoi d'emails par exemple, des démarrages de backup, des copies de fichiers, des renommages de fichiers, des réorganisations de répertoires, etc. etc. Comme l'a décrit Sugata Mitra, la structure du système s'est modifiée d'elle même et on a commencé à voir émerger des fonctionnalités pour lesquelles le système des pulses n'avait pas été conçu.

15/07/2019

La qualité des sources de données

Bien entendu, j'ai continué à travaillé sur l'IA de TRQL Radio. Je ne me suis pas pour autant inquiété de documenter ce travail depuis bientôt 2 ans. Jusqu'à que …

En juin 2019, je me suis enquis de la manière que nous pourrions avoir de déterminer automatiquement l'année de release des morceaux que nous avons en catalogue. Pour ce faire je me suis avant tout dirigé vers l'utilisation des APIs de Deezer et de iTunes qui tous deux donnent la date de release s'ils en disposent.

L'utilisation de ces APIs mène à des questions intéressantes. En effet, quelle source choisir ? La réponse tient en fait à la disponibilité de l'information que je recherche. Dans certains cas, iTunes donne la réponse; dans d'autres cas, Deezer donne la réponse; enfin, parfois, les deux donnent des réponses différentes.

Dans le cas qui nous occupe, je dirais que l'utilisation d'un API ou d'un autre relève de la logique pure : on ne peut pas parler d'intelligence artificielle. Là où cela se corse, c'est les cas de collision et les cas d'erreur.

Dans le cas d'une collision (les différents API retournent des données), si les deux APIs retournent la même date, aucune inquiétude à avoir (seule l'année m'intéressait vraiment). Le cas le plus problématique est celui où les dates retournées sont différentes (où l'année est différente) car cela pose d'emblée la question de la qualité des données. C'est cette qualité de données qui constitue la plongée dans l'intelligence artificielle car en effet, un véritable système intelligent est en réflexion permanente concernant ses sources d'information. Il s'agit de les sélectionner (ce qui peut se faire facilement avec une intervention humaine) et d'en estimer la qualité, avec pour l'un et l'autre l'obligation de faire cela, sinon en permanence, du moins régulièrement.

Enfin, se pose encore la question de la connaissance engendrée : il s'agit de remettre en question régulièrement ce qu'on sait si cela s'avère nécessaire, c'est-à-dire si on considère que ce que l'on sait ne forme pas une connaissance parfaite. Pour être très concret, on peut avoir acquis une connaissance erronée sur base de sources qu'on considère néanmoins comme fiables : l'année du morceau "Living It Up" de Ricky Lee Jones établie au 01/01/1970 par exemple sur base de la réponse donnée par l'API de Deezer. Deezer étant considéré comme fiable dans son ensemble, on fait confiance à ce que son API nous retourne. Pour autant, cette date est incorrecte ! En consultant d'autres sources, on remarque que plusieurs d'entre elles renseignent 1981 comme l'année de sortie de ce morceau et dès lors, les programmes optent pour 1981 en lieu et place de 1970. Par la suite, il se pourrait bien qu'on considère cette connaissance comme imparfaite car nous n'avons pas ni le mois ni le jour de la sortie du morceau. Ainsi, même en connaissant l'année, il se peut que les programmes décident de modifier la date encore pour acquérir jour et mois. Une fois acquis, encore faut-il que les programmes croisent les sources pour aboutir, in fine, si tant est que ce soit possible, à une connaissance parfaite.

Je continuerai à expliquer notre travail relatif à l'Intelligence Artificielle dans TRQL au fur et à mesure.


Top
Le Blog Apocryphe utilise des cookies pour sauver vos préférences et RIEN d'autre. Je vous demande de bien vouloir accepter les cookies qui sont positionnés sur mon blog et je vous promets en retour de ne RIEN laisser transparaître de votre parcours de visite, dont d'ailleurs vous me faites l'honneur. Au cas où néanmoins vous n'accepteriez pas d'utiliser les cookies, vous aurez probablement une navigation LÉGÈREMENT dégradée sur le Blog Apocryphe. Bonne visite!X