My Blog

Étiquette : SOAT

  • Quand l’intelligence Artificielle devient profondément humaine…

    L’intelligence artificielle est plus collective et humaine que vous ne le pensez

    Par Hugo Cornu, Head of Data Expertise Team & Senior Consultant chez SOAT

    Connaissez-vous les célébrités du monde de l’intelligence artificielle ? Moi non plus !

    La communauté scientifique est un des plus beaux exemples d’intelligence collective (IC) : des milliers de chercheurs ajoutent chaque année leur pierre à un édifice commun qui dépasse les frontières, les langues, les idéologies. Mais la science est aussi le terrain du génie individuel comme Curie, Einstein ou Hawking qui à eux seuls ont révolutionné la pensée collective de leur époque.

    L’intelligence artificielle (IA) progresse différemment : il n’y a pas de héros ou de star.

    Il y a plusieurs raisons à cela. Tout d’abord, la discipline est encore jeune. Ensuite, et surtout, les passionnés d’apprentissage machine (Machine Learning) sont des passionnés d’apprentissage tout court. En effet, les data scientists forment une communauté remarquable par sa capacité à mêler compétition, entraide et partage de connaissance : les maîtres d’un sujet sont eux-mêmes élèves sur les autres. Bien sûr, cela peut être dit de beaucoup de communautés professionnelles, mais c’est d’autant plus marqué en IA que la matière première est collective par essence.

    Par exemple, pour apprendre à une machine à recommander de bons articles, il faut mesurer les comportements de milliers de lecteurs. Entraîner une IA est donc toujours un travail d’équipe et ouvert sur le monde. Tandis que les algorithmes (et leurs auteurs) sont entraînés, remplacés, interchangés à un rythme effréné, les données restent et s’accumulent. Plus que toutes autres ressources, elles représentent un capital auquel nous, grand public, contribuons collectivement.

    Malgré des appels en faveur de l’Open Data, les gisements de données les plus riches appartiennent à de grandes multinationales et c’est dommage. Mais que ces données soient privées ou publiques, nous devons cultiver à leur égard un sentiment de responsabilité, car elles sont le reflet de notre intelligence collective, bonne ou mauvaise. Par exemple, Microsoft a dû suspendre son IA conversationnel “Tay” après les efforts coordonnés de plusieurs centaines d’utilisateurs pour abuser de son système d’apprentissage et le faire répondre de manière inappropriée.

    L’intelligence artificielle peut donc être considérée comme l’une des manifestations orchestrées d’intelligence collective. Et c’est ce qui la rend profondément humaine.

    Pourtant, les peurs liées à l’IA tournent en majorité autour de son « inhumanité » perçue. Combien de scénarios dystopiens explorent la possibilité d’une domination de l’homme par la machine ? Plus concrètement, dans certains domaines (prise de décision militaire, véhicules autonomes …), la technologie existe, mais la société n’est pas prête à lui faire confiance. C’est bien justifié puisque l’IA reste une boîte noire : même lorsqu’on peut mesurer objectivement la qualité des décisions prises par une IA, il est difficile d’en expliquer le processus de raisonnement et les biais.

    En pratique, il devient de plus en plus clair que les algorithmes peuvent intégrer des biais vis-à-vis de minorités, d’objectifs pécuniaires ou de valeurs morales. Ces biais sont parfois transmis inconsciemment par les créateurs de l’IA, mais le plus souvent ils résident dans les données d’entraînement. Qui n’a jamais été surpris ou déçu par les recommandations automatiques de Youtube ?

    La pertinence de l’IA repose donc essentiellement sur la qualité des données d’entraînement, données fournies par l’intelligence collective. Et c’est une bonne nouvelle. Car, plus nous en sommes conscients, plus nous pouvons intégrer à l’IA des composantes humaines et éthiques. Le projet MoralMachine du MIT en témoigne : il propose aux internautes de résoudre des dilemmes moraux et donc participer à construire des bases de données éthiques.

    Puisqu’il est possible et pratiquement nécessaire d’enseigner nos valeurs aux premières générations d’IA, n’avons-nous pas le devoir de les éduquer avec fermeté et bienveillance comme nous le faisons avec les nouvelles générations d’humains ? Un beau projet… collectif.

     

     

  • Quand Amazon déploie une nouvelle mise à jour de son site toutes les 11 secondes …

    L’architecture distribuée : un levier concurrentiel ?

    Par David Wursteisen – Expert Java et Test Driven chez SOAT

    Le temps que vous lisiez cette phrase, Amazon aura fait plus de 2000$ de chiffre d’affaires. Toutes les 11 secondes, Amazon déploie une nouvelle mise à jour de son site d’E-commerce. Une coupure, même très courte, provoquée par ces mises en production, serait très pénalisante pour ce géant du web qui a tout misé sur l’extrême rapidité du cycle d’achat de ses clients.

    Pour proposer un service sans discontinuité, tout en mettant à jour les composants qui le constituent, Amazon utilise une architecture distribuée : les services sont éclatés, répartis sur un ensemble de serveurs et découplés les uns des autres. Les composants se retrouvent ainsi isolés, et le crash ou la mise à jour de l’un d’entre eux n’a d’impact que sur lui-même.

    Grâce à cette architecture distribuée, Amazon peut se permettre des mises à jour fréquentes et proposer rapidement de nouvelles fonctionnalités. D’autres acteurs, comme Netflix, ont aussi opté pour ce type d’architecture. Netflix n’hésite d’ailleurs pas à mettre à rude épreuve ses services, en simulant constamment des pannes, allant jusqu’à arrêter ses services sur un continent complet. Tout ceci dans une transparence totale pour l’utilisateur grâce à une distribution des applicatifs et des données dans le monde entier.

    Un peu d’histoire

    Cette notion de distribution de services n’est pourtant pas nouvelle. Java EE proposait des composants distribuables (EJB pour Entreprise Java Beans) dès les années 2000, tout comme la spécification SOAP (Simple Object Access Protocol) qui, à la même époque, permettait de décrire un protocole de communication entre systèmes hétérogènes, pour faciliter le dialogue entre eux (ces systèmes pouvant être distants et reposer sur des technologies différentes).

    Mais on est encore loin du concept de distribution massive des services, qui n’est apparue que très récemment. Il y a quinze ans en effet, l’utilisation des systèmes informatiques était beaucoup moins omniprésente et la pression exercée sur eux, moins forte.

    Internet n’était pas disponible partout, tout le temps, pour tout le monde, et la technologie elle-même n’était pas adaptée à la distribution des services.

    Aujourd’hui, de nouveaux paradigmes ont émergé qui eux, sont idéaux pour une utilisation de services distribués.

    Reste qu’aucune des technologies de l’époque n’est aujourd’hui un critère de choix pour concevoir ce type d’architecture. Leurs premières utilisations restent axées sur une communication synchrone, une gestion des erreurs complexes et occasionnent des coûts d’utilisation supplémentaires. Développer une application distribuée en se basant sur ces technologies, est contraignant, compliqué et plus couteux.

    No Pain No Gain : Changement de paradigme

    Mettre en place une architecture distribuée, c’est avant tout savoir faire des compromis. Vous vous connectez à un service distant qui doit toujours être disponible ? Un message ne doit être consommé qu’une seule et unique fois ? Votre service doit répondre dans un temps constant ?

    Il faut avoir conscience que dans un contexte distribué, c’est impossible. Vous dire le contraire serait vous mentir. Les services peuvent tomber, les messages se perdre ou votre service dépendre d’autres services subissant des lenteurs contre lesquelles vous ne pourrez rien faire.

    Des solutions néanmoins existent : il faut accepter qu’un service ne soit plus disponible et y pallier par des temporisations ou des coupes circuits. La duplication de messages peut être gérée avec de l’idempotence et il est possible d’isoler vos services, en rendant vos appels asynchrones.

    La mise en œuvre de ces concepts n’est pas triviale. Il faut revoir les modes de communication, la structures des messages et gérer de nouveaux cas d’erreurs. Ces notions sont complexes à saisir, tout comme les changements qu’elles imposent. Il sera donc nécessaire de réaliser des prototypes pour le découvrir par soi-même ou se faire accompagner pour gagner un temps précieux.

    Une architecture distribuée, c’est aussi de nouveaux services qui vont communiquer entre eux. Comment s’assurer de la compatibilité des APIs entre elles ? Comment réaliser la mise en production régulière, non plus d’un, mais d’une multitude de services ?

    Votre outil de supervision est-il adapté à cette nouvelle distribution applicative ?

    Si ces problématiques ne sont pas nouvelles, leur mise à l’échelle peut, elle, se révéler problématique.

    Impact Business des architectures distribuées :

    L’investissement peut sembler important, mais le gain l’est tout autant. Votre dépendance technique se réduira puisque vous pourrez mélanger des services utilisant des technologies hétérogènes. Vous ne serez plus contraint à utiliser la technologie historique qui est trop souvent le choix par défaut, car votre prochain service pourra faire des arbitrages techniques correspondant mieux à un contexte précis. Sa mise à disposition s’effectuera plus vite, avec un coût réduit et sa maintenance simplifiée n’aura aucun impact sur les briques existantes.

    Une architecture distribuée garantit par ailleurs la qualité et la disponibilité des services : si l’une de vos dépendances tombe, votre service lui, isolé de cette dépendance, continuera à répondre. Cette réponse se fera en mode dégradé certes, mais sera toujours plus pertinente qu’aucune réponse.

    Vous gagnerez également en performance puisque vous pourrez profiter du temps d’attente de vos appels asynchrones pour traiter plus de données.

    Avoir des applicatifs distribués, isolés entre eux et résilients, c’est la possibilité de changer à tout moment de composants sans impacter directement vos utilisateurs. Plus besoin de réserver un créneau, à l’heure où la fréquentation sur votre site est la plus faible, pour mettre en production. Le temps de mise à disposition de nouvelles fonctionnalités s’en trouve drastiquement réduit, une fois validées, elles sont effectives et opérationnelles.

    Pour finir sur une métaphore qui parlera à tous ; passer à une architecture distribuée, c’est se donner les moyens de changer les roues de sa F1 tout en continuant à rouler, quand les autres écuries s’efforcent de diminuer leurs temps au pit-stop.