Conception du programme phénotrope

J'ai récemment rencontré une idée avancée par Jaron Lanier appelée «programmation phénotrope».

L'idée est d'utiliser des interfaces «de surface» au lieu d'interfaces à point unique dans des programmes informatiques utilisant des statistiques pour détecter des erreurs mineures qui entraîneraient généralement un crash «catastrophique» d'un programme «classique».

La description en deux lignes est ici:

Selon Jaron, la «vraie différence entre l'idée actuelle de logiciel, qui est l'adhésion au protocole, et l'idée [qu'il discute], la reconnaissance des formes, a à voir avec les types d'erreurs que nous créons» et si «nous ne faisons pas 'ne trouvons pas une manière différente de penser et de créer des logiciels, nous n'écrirons pas de programmes de plus de 10 millions de lignes de code, quelle que soit la vitesse de nos processeurs.'

L'explication un peu plus longue est ici . Et l'explication encore plus longue est ici .

Donc, la question, en passant devant les connotations évidentes de robot-suzerain que les gens ont tendance à choisir, comment pourrait-on réellement concevoir et écrire un "programme phénotrope?"

Lanier a inventé un mot de 50 cents dans le but de jeter un filet autour d'un ensemble spécifique d'idées qui décrivent un modèle informatique pour créer des programmes informatiques ayant certaines caractéristiques identifiables.

Le mot signifie:

Mécanisme d'interaction de composants qui utilise la reconnaissance de formes ou la cognition artificielle à la place de l'invocation de fonctions ou de la transmission de messages.

L'idée vient en grande partie de la biologie. Votre œil s'interface avec le monde, non pas via une fonction comme See(byte[] coneData), mais à travers une surface appelée rétine. Ce n'est pas une distinction triviale; un ordinateur doit analyser tous les octets coneDataun par un, tandis que votre cerveau traite toutes ces entrées simultanément.

Lanier affirme que cette dernière interface est plus tolérante aux pannes, ce qui est le cas (un seul bit glissé coneDatapeut casser tout le système). Il prétend qu'il permet la correspondance de modèles et une foule d'autres capacités qui sont normalement difficiles pour les ordinateurs, ce qu'il fait.

Le mécanisme «phénotrope» par excellence dans un système informatique serait le réseau de neurones artificiels (ANN). Il prend une "surface" en entrée, plutôt qu'une interface définie. Il existe d'autres techniques pour atteindre une certaine mesure de reconnaissance des formes, mais le réseau neuronal est le plus étroitement aligné sur la biologie. Faire un ANN est facile; il est difficile de lui faire exécuter la tâche que vous souhaitez effectuer de manière fiable, pour plusieurs raisons:

1. À quoi ressemblent les "surfaces" d'entrée et de sortie? Sont-ils stables ou varient-ils en taille au fil du temps?
2. Comment obtenez-vous la bonne structure de réseau?
3. Comment formez-vous le réseau?
4. Comment obtenez-vous des caractéristiques de performances adéquates?

Si vous êtes prêt à vous séparer de la biologie, vous pouvez vous passer du modèle biologique (qui tente de simuler le fonctionnement de neurones biologiques réels) et construire un réseau qui est plus étroitement lié aux «neurones» réels d'un système informatique numérique (logique portes). Ces réseaux sont appelés réseaux de logique adaptative (ALN). La façon dont ils fonctionnent consiste à créer une série de fonctions linéaires qui se rapprochent d'une courbe. Le processus ressemble à ceci:

... où l'axe X représente une entrée dans l'ALN et l'axe Y représente une sortie. Imaginez maintenant le nombre de fonctions linéaires s'étendant au besoin pour améliorer la précision, et imaginez ce processus se produisant à travers n dimensions arbitraires, implémenté entièrement avec des portes logiques ET et OU, et vous avez une idée de ce à quoi ressemble un ALN.

Les ALN ont certaines caractéristiques très intéressantes:

1. Ils sont assez facilement entraînables,
2. Ils sont très prévisibles, c'est-à-dire que de légères variations dans les entrées ne produisent pas de fluctuations sauvages de la sortie,
3. Ils sont rapides comme l'éclair, car ils sont construits sous la forme d'un arbre logique et fonctionnent un peu comme une recherche binaire.
4. Leur architecture interne évolue naturellement grâce à l'ensemble de formation

Un programme phénotrope ressemblerait donc à quelque chose comme ceci; il aurait une "surface" pour l'entrée, une architecture et un comportement prévisibles, et il tolérerait les entrées bruyantes.

Lectures complémentaires
Introduction aux réseaux de logique adaptative avec une application pour l'audit de l'évaluation des risques
«orientée objet» vs «orientée message», par Alan Kay

Je pense que nous sommes au tout début d'une des étapes qu'il faudra pour y arriver et qui consiste à rassembler de nombreuses données dans des formats qui peuvent être analysés. Internet, les recherches Google, Fitbit (chaque étape que vous faites, chaque mouvement que vous faites, je vous surveillerai.), FourSquare, une géolocalisation pour téléphone intelligent, des publications Facebook et des données de question SO sont tous en cours de collecte. Nous ne sommes pas du tout près de la quantité de données sensorielles que l'humain moyen compile sur une durée de vie, mais nous nous rapprochons.

Commencez à catégoriser des millions de photos d'oiseaux et à obtenir des commentaires de personnes vous disant que ce n'est pas un oiseau et vous pouvez commencer à créer un algorithme. De là, une impression plus floue (je l'appellerais un modèle, mais c'est trop exact pour ce que nous essayons de coder.) Peut être créée.

class Birdish

Comment un chien de compagnie sait-il autant de choses sur le propriétaire? Parce que ça la regarde beaucoup. Le chien a écouté les voitures se garer dans l'allée et corrélant avec le fait que le propriétaire ouvrant la porte d'entrée, il semble que le chien puisse reconnaître une voiture par son son. Nous pourrions le faire aussi, mais nous ne voyons aucune raison de nous y atteler. Et c'est ce qui ne va pas avec le logiciel actuel, il ne fait pas attention à ce que fait l'utilisateur. Il attend simplement que l'utilisateur fasse ce que l'informatique attend de lui.

Quelque chose d'aussi simple que de régler un réveil pourrait être fait par une petite observation / analyse de mes habitudes actuelles. Nous avons renoncé à régler les minuteries du magnétoscope avant que la technologie ne soit remplacée par le numérique. Et cela se serait-il produit aussi rapidement si nous avions pu interfacer le TV Guide avec le magnétoscope? J'ai regardé la même émission de télévision 4 semaines de suite en même temps, mais la 5e, je n'ai même pas allumé le téléviseur. Évidemment, je veux qu'il soit enregistré. Ne pouvez-vous pas dire que je reste en retard au travail en écrivant cet article et avec mon trajet typique ne rentrera pas à temps? Vous avez les données, faites le calcul.

Rassemblez de plus en plus de données et vous pourrez alors trouver de meilleures façons de les analyser, de les reconnaître et de les convertir. Nous allons au-delà de ce qui ne peut être entré qu'à partir d'un clavier avec nos caméras de téléphone et bientôt nos caméras en verre oculaire. C'est juste le début.

Voici un ensemble de diapositives pour définir un langage de programmation probabiliste dans Scala .

C'est le premier exemple de mise en œuvre décente pour certains des composants de base du système que Jaron Lanier propose.

Une pensée que j'avais récemment:

Si vous avez utilisé des idées de haut niveau comme Maybe Monad de Haskell pour encapsuler les appels de procédure à distance vers d'autres systèmes. Vous envoyez une demande au serveur. Mais rien ne revient (le serveur est cassé). Ou une promesse revient (le serveur est occupé) et vos programmes continuent de fonctionner avec ces valeurs Aucune ou Promise. C'est un peu comme la tolérance aux pannes que Lanier recherche.

Il existe peut-être des moyens d'encapsuler d'autres éventualités. Par exemple, les appels distants qui reviennent avec une approximation qui est de plus en plus affinée au fil du temps par une sorte de négociation en arrière-plan. c'est à dire. ce qui revient est quelque chose comme une promesse mais pas seulement "continuez à tenir et à travailler avec cela et une valeur appropriée apparaîtra bientôt" mais "continuez à tenir et à travailler avec cela et une meilleure approximation apparaîtra bientôt". (Et encore et encore). Cela pourrait cacher beaucoup de défauts au programmeur, tout comme les protocoles de mise en réseau cachent beaucoup d'échecs de mise en réseau de bas niveau au programmeur.