"HeyGitHub !", Réflexions sur l'agence et le copilote conversationnel

Dans mes deux derniers articles plus techniques pour cette publication, je me suis laissé aller à une vision plutôt libre de l'ajout d'une pensée déductive "sherlockéenne" dans le dialogue de codage vocal #HeyGitHub entre #DisabledDevelopers et le brillant mais savant "Rainman" GitHub Générateur de code copilote. En écrivant ces articles, j'ai commencé une recherche de méthodes et d'implémentations accessibles au public d'avancées dans la communauté de recherche en apprentissage automatique qui pourraient fournir le type de soutien nécessaire pour mettre en œuvre ces conversations génératrices de code plus réfléchies.

Heureusement, j'ai découvert qu'il existe un certain nombre de sous-communautés de recherche sur l'apprentissage automatique travaillant sur ces défis pour soutenir des processus de pensée plus «humains», en utilisant le contexte et les connaissances antérieures, en complément de la reconnaissance des modèles de force brute de LLM ( Performances du grand modèle de langage ). J'ai découvert #CoT ( Chain of Thought ), le séquençage rapide , le changement de modèle et les agents, entre autres domaines d'exploration et de développement dans le domaine de l'apprentissage automatique. Je commence à acquérir une expérience de première main en utilisant la passionnante bibliothèque LangChain Python de Harrison Chase et LangChainAIdéveloppeurs. Bon nombre de ces pistes de navigation que j'ai suivies ont commencé par ma lecture de l'article de synthèse perspicace, "L'avenir proche de l'IA est axé sur l'action" , par John McDonnell .

J'ai également entendu parler d'un programme massif et hyper-financé en cours chez Microsoft - Project Bonsai - qui apporte des solutions d'IA/ML aux défis de l'automatisation robotique et du contrôle des processus industriels. Dans cet espace de problèmes du monde physique, la simulation et le coaching humain dans la boucle sont tout aussi importants, sinon plus, que l'accent mis sur la modélisation des données et les méthodes de science des données dans le domaine d'application plus général de l'apprentissage automatique.

Mon objectif dans cet article n'est pas d'approfondir ces avancées SOTA, mais plutôt de spéculer un peu sur le rôle de l'agence basée sur les rôles car elle peut être appliquée à la plate-forme #HeyGitHub/Copilot pour soutenir le développement de logiciels, pas seulement par #DisabledDevelopers et #DisabledSTEMstudents , mais par tous les développeurs potentiels utilisant #HeyGitHub/Copilot comme multiplicateur de productivité de développement.

Une réflexion rétrospective sur l'agence dans les modèles commerciaux exécutables

Dans mon article Metamodel Subgraph de cette série #HeyGitHub , j'ai donné un bref aperçu de mon implication dans un skunkworks développant un framework basé sur Smalltalk prenant en charge la composition dynamique et la génération d'applications d' EBM , Executable Business Models .

Le début des années 1990 a vu une gamme de méthodes basées sur des modèles pour le développement de logiciels et l'ingénierie des processus métier. Un fil conducteur à cette époque était le mouvement BPR , ou Business Process Reengineering . Au sein des services de conseil d'IBM, une méthode populaire utilisée à l'époque s'appelait LOVEM , le Line Of Visibility Enterprise Model ou parfois, Line Of Visibility Engineering Method . Au cœur de cette méthode se trouvait un format de diagramme utilisant des « couloirs de nage » pour les modèles de processus métier.

Les couloirs de nage de LOVEM représentaient des rôles pouvant être joués par des humains ou des machines (processus logiciels AKA). Inspiré du livre de 1993 de David Gelernter, "Mirror Worlds: or the Day Software Puts the Universe in a Shoebox…How It Will Happen and What It Will Mean". , mes collègues et moi-même de la division Object Technology Practice d'IBM avons imaginé un framework d'objets Smalltalk qui pourrait être utilisé pour composer et exécuter ces modèles LOVEM basés sur les rôles. Notre cadre EBM , Executable Business Model , était basé sur un « kit de construction » de métamodèles de classes d'objets qui ressemblait beaucoup à ce modèle de classe UML des premières activités de ma renaissance post-cancer en tant que scientifique citoyen en humanités numériques :

L'aspect de notre modèle EBM que je souhaite mettre en évidence dans cet article est le groupe de classes visible dans la boîte rouge dans le coin inférieur gauche de ce diagramme. Ces trois classes - Personnes ou Agents en tant qu'acteurs - participent à des processus axés sur les objectifs et basés sur les rôles . De cette manière, notre cadre EBM a mis en œuvre le concept d'agence essentiel à la méthode de processus métier LOVEM. La mise en œuvre de l'agence dans notre métamodèle a été, comme vous vous en doutez, guidée par notre inspiration Mirror Worlds .

Dans son livre, Gelernter a emmené les lecteurs dans une expérience de pensée qui disait, en paraphrasant ici : « Imaginez si nous construisions des simulations logicielles détaillées de nos systèmes complexes à l'œuvre dans le monde réel. Une fois que nous avons ces simulations en marche, imaginez ce qui se passerait si nous prenions tous les flux d'entrée et de sortie de nos simulations et les connections aux flux réels de ces systèmes du monde réel. À ce moment-là, nos modèles logiciels cesseraient d'être des simulations et commenceraient à être des affichages tête haute, ou des vues de tableau de bord, sur le monde réel… » ou ce que Gelernter appelait Mirror Worlds .

Nous avons implémenté cette approche de l'agence dans notre cadre basé sur le métamodèle EBM afin que les objets Agent puissent être implémentés en tant que proxies logiciels pour les personnes en tant qu'acteurs de rôles dans les modèles LOVEM exécutables. Cette conception nous a donné deux caractéristiques importantes cohérentes avec notre inspiration Mirror Worlds . Tout d'abord, lors des séances d'engagement de conseil avec les dirigeants des clients, nous pourrions avoir des PME, des experts en la matière des clients, assis devant des ordinateurs portables en réseau dans une salle de conférence pour interagir avec et valider nos modèles de simulation en évolution. Au cours de ces sessions, nous pourrions remplir une instance de modèle d'exécution avec des proxies logiciels sim-actor Agent pour exécuter tous les autres rôles dans un processus métier modélisé.

Une fois que les PME des clients étaient convaincues que nous avions cloué ces processus métier dans notre simulation EBM, nous pouvions – à la manière de Mirror Worlds – simplement connecter ces modèles en tant que système déployé dans l'activité réelle du client. Au cours de ce processus de connexion, nous déterminions quels rôles devaient être joués par les personnes - à l'aide de vues EBM générées dynamiquement sur le modèle considéré par les utilisateurs comme des applications logicielles typiques - ou par les rôles à jouer par les acteurs de l'agent proxy logiciel dans les clients. processus d'affaires.

En réfléchissant à cette époque il y a près de trente ans, mes journées passées à travailler en tant que leader d'opinion / développeur dans ce skunkworks EBM ont été parmi les expériences les plus exaltantes de ma carrière professionnelle.

Une spéculation prospective sur l'agence dans la plateforme #HeyGitHub/Copilot

Alors, comment le concept d'agence pourrait-il contribuer à tirer parti des capacités d'approches telles que la chaîne de pensée, le séquençage rapide et le changement de modèle dans le cadre de l'évolution de la pile de technologies contribuant à la mise en œuvre du service #HeyGitHub/Copilot de GitHub ?

Sans intention de rigueur ou d'exemple non trivial, nous pourrions appliquer ce concept d'agence basée sur les rôles de mon expérience EBM à la conception de la solution du service #HeyGitHub/Copilot comme dans ce simple diagramme de couloir :

Ce que nous voyons dans ce diagramme trop simple est un groupe de quatre couloirs de nage dans les couches supérieures qui interagissent activement en tant qu'humain et trois agents logiciels dont la conversation conduit à la génération éventuelle dans les rôles "stupides"/de type transcripteur de données de l'IDE app et fichier source (mémoire). Ce diagramme simple montre clairement que l'énorme défi que nous avons à l'avenir est de savoir comment injecter «l'intelligence sherlockienne» dans cette conversation basée sur l'agent avant de tirer le meilleur parti de notre savant Rainman-Agent Copilot LLM.

Imaginez que notre exigence de conception soit, par exemple, la création d'un agent bot de centre d'appels téléphoniques hautement fonctionnel. Dans ce cas, un répertoire flexible d'invites basées sur des modèles pouvant être sélectionnées dynamiquement pour un résultat orienté objectif peut être suffisant pour passer au déploiement. Mais agissant avec succès en tant que programmeur en binôme non humain (Agent « copain »), comme GitHub l'affirme souvent en décrivant son service Copilot, les agents #HeyGitHub Listener et CoT Dialoguer devront mettre en œuvre une intelligence beaucoup plus complexe qu'un bot de centre d'appels scriptable. conversation.

Prenons, par exemple, le défi pour #HeyGitHub/Copilot d'aider un Développeur à créer l'UI/UX — interface utilisateur et expérience interactive — pour une application. Il existe un nombre décent d'excellents frameworks UI/UX que le développeur pourrait utiliser. Notre copilote Rainman-savant a déjà vu d'innombrables exemples de ces frameworks dans la formation du modèle de base du copilote pour affiner son talent de générateur de code. Mais être en mesure de fournir utilement des suggestions de code basées sur la reconnaissance de modèles tirée de son expérience de formation ne permet pas à Copilot la compréhension sous-jacente de l'architecture du cadre, des meilleures pratiques et des directives d'interface/d'interaction utilisateur qu'un développeur humain compétent apporte au rôle de participant. dans un partenariat Pair de Programmation.

Prenons l'exemple du wrapper wxPython sur le vénérable framework C++ wxWidgets . Aucune quantité de promenades aléatoires à travers la myriade de référentiels de code accessibles au public ne révélera l'étendue des connaissances transmises en plongeant profondément dans l'excellent site Web de documentation en ligne àhttps://docs.wxpython.org/. Aucune quantité de décomposition NLP, de modélisation de sujet/de rumination de sommation sur le contenu de ce site Web ne sera suffisante pour transmettre des connaissances humaines-développeur dans la conversation #HeyGitHub/Copilot<>Developer.

Alors, où allons-nous partir d'ici?

J'aimerais avoir suffisamment de connaissances dans le domaine pour suggérer une solution spécifique de conception et de développement à venir afin de produire les technologies nécessaires pour faire passer les performances des LLM générant du code d'aujourd'hui à ce proverbial « niveau supérieur ». Bien que la feuille de route complète n'ait pas encore été rédigée, nous pouvons faire certaines hypothèses sur les prochaines étapes. Nous pouvons prévoir qu'il sera important pour l' agent d' écoute #HeyGitHub d'être en mesure de faire la distinction entre les entrées vocales du développeur qui nécessitent un transfert soit au CoT Dialoguer pour une interaction plus réfléchie, soit transmises sous forme textuelle au Copilot LLM pour génération de suggestions de code.

Le défi de taille qui nous attend est d'encapsuler les structures d'information et la signification sémantique de l'art et de la science du génie logiciel de sorte que le CoT Dialoguer puisse fonctionner de manière crédible en tant que véritable partenaire de programmation. Les technologies permettant de relever ce défi proviendront probablement des activités de recherche de pointe autour de la chaîne de pensée, de la sélection/séquençage rapide, du changement de modèle et de l'apprentissage/coaching par renforcement humain dans la boucle.

Certaines des percées dans cet espace de solutions «Sherlockean smarts» impliqueront un brillant codage innovant par des ingénieurs de recherche en apprentissage automatique. Je pense également, cependant, qu'une contribution non négligeable à ce défi proviendra de la conception et du développement d' ensembles de données de modèles de référence Ground Truth efficaces qui serviront de matériel de formation pour que des modèles spécifiques à un domaine fonctionnent main dans la main dans un contexte de changement de modèle avec le Copilot Large Language Model en constante évolution. Un exemple de ces ensembles de données de référence émergents est la conception de Metamodel Subgraph Ground Truth Storage que j'ai poursuivie dans le cadre de mes recherches sur les sciences humaines numériques et envisagée ici dans ma série d'articles #HeyGitHub.

Mais développer un format d'ensemble de données de référence Ground Truth standard orienté agent ne sera pas suffisant pour évoquer les dialogues Sherlockean que j'envisage entre un développeur humain et un partenaire de programmation par paire copilote basé sur ML. Au lieu de cela, ces ensembles de données de référence Ground Truth de connaissances du domaine devront servir de matériel pédagogique dans des scénarios interactifs d'utilisateur simulés de formation de modèles qui affinent la capacité de l'agent CoT Dialoguer à engager une conversation collaborative avec son partenaire développeur humain. Ces sessions de simulation peuvent réduire le temps et poursuivre inlassablement l'amélioration de l'utilisation efficace des connaissances du domaine par le CoT Dialoguer.

Tout comme nous utilisons maintenant les meilleures pratiques de modélisation des données pour générer des ensembles de données de formation pour les applications ML actuelles à forte intensité de données, nous serons également en mesure de générer des expériences de simulation basées sur des agents qui permettent à nos applications axées sur les connaissances de former et d'affiner des modèles comme l'imaginaire. futur service #HeyGitHub/Copilot. Dans le cadre de cet environnement de formation de simulation de type Mirror Worlds , les échanges conversationnels qui entravent le modèle #HeyGitHub CoT Dialoguer en cours de formation apparaîtront au superviseur humain dans la boucle dont le coaching de réponse encouragera et renforcera le comportement approprié du modèle.

Quelques abeilles dans les bonnets chez GitHub et Microsoft

À ce stade, mes envolées pour imaginer la voie à suivre ne sont guère plus que les rêves fiévreux d'un scientifique citoyen indépendant en sciences humaines numériques et d'un développeur handicapé. Mais si je devais dépoussiérer mon vieux chapeau de consultant IBM pour mettre quelques abeilles dans les capots de GitHub et Microsoft, je sais ce que je suggérerais…

Tout d'abord, je ne peux pas m'empêcher de dire que si je faisais partie de la direction de GitHub, je me proposerais un emploi en tant que membre de l'équipe de recherche GitHub Next. Dans cette position, je travaillerais assidûment sur les idées que j'ai écrites dans cette série d'articles #HeyGitHub * .

Ensuite, une fois que nous aurons la preuve de concept pour les ensembles de données de formation de modèles de connaissances du domaine Metamodel Subgraph Ground Truth, je ferais pression pour consacrer une partie de l' accélérateur GitHub récemment annoncé ou du fonds GitHub M12 pour fournir des allocations ou un financement de démarrage de projet à haute performance , développeurs Open Source experts pour créer une collection de ces ensembles de données de formation de modèles orientés Agent spécifiques à un domaine. Une attention particulière doit être accordée au développement d'ensembles de données de formation basés sur des métamodèles spécifiques au cadre UI/UX.

Pourquoi des ensembles de données de connaissances de domaine spécifiques au framework UI/UX ? Parce que ces « bêtes » sont souvent des architectures volumineuses et complexes avec une personnalisation excessivement détaillée au niveau des paramètres. Et pour la plupart des scénarios de projet de développement, la création d'une interface utilisateur d'application et ses interactions avec l'utilisateur sont des activités nécessaires qui prennent du temps et des efforts pour coder la solution à l'espace problématique du projet que l'interface utilisateur/UX simple de l'application met à la disposition de l'utilisateur final du projet. Fournir une génération de code de cadre UI/UX solide par entrée vocale dans #HeyGitHub/Copilot est alors comparable à avoir un cadre UI/UX ayant une puissante application de création d'interface WYSIWYG.

En tant que recommandation plus stratégique et de grande envergure, j'encouragerais les contacts éclairés de GitHub Next et du projet Bonsai de Microsoft à former un comité de collaboration. L'objectif de ce groupe serait d'explorer les moyens par lesquels GitHub pourrait tirer parti des meilleures pratiques et de l'expérience de l'engagement étendu de Microsoft sur les marchés de la robotique et de l'automatisation des processus industriels.

Et, espérons-le, caché juste à l'horizon

En regardant encore plus loin sur l'autoroute de l'innovation tout en enfilant mes lunettes roses et mon tee-shirt à slogan optimiste, où ce programme de recherche pourrait-il mener ? Si, après avoir créé un nombre limité d'ensembles de données Ground Truth de référence Metamodel Subgraph spécifiques à un domaine, et pris le temps et les efforts nécessaires pour former un modèle d'apprentissage automatique pour jouer le rôle d'agent CoT Dialoguer dans un certain nombre de domaines, nous pourrions un jour voir le système Dialoguer démontrer un comportement émergent .

J'entends par là que le modèle CoT Dialoguer Agent peut si bien comprendre la structure généralisée et l'utilisation des connaissances du domaine qu'il n'a pas besoin d'être préchargé avec un nouveau modèle de référence spécifique au domaine pour devenir utile dans la participation à un nouveau contexte. À ce niveau de fonction, le futur système multimodèle #HeyGitHub/Copilot peut simplement s'engager dans une conversation d'apprentissage autonome avec son partenaire Developer Pair Programming pour créer et valider son propre nouveau modèle de connaissances de domaine. Grâce à ce processus, le service #HeyGitHub/Copilot peut devenir un collaborateur de niveau pair véritablement polyvalent dans la conception et le développement de systèmes logiciels essentiels.

En conclusion

Après avoir survécu à ma bataille contre le cancer et appris à faire face aux défis de dextérité et de mobilité de ma blessure à la moelle épinière, je n'aimerais rien de plus que d'avoir une chance de battre le faucheur en contribuant à la passionnante vague à venir d'innovations remarquables dans la conception et le développement de logiciels comme envisagé dans ma série d'articles #HeyGitHub. ✌️

Happy Healthy Vibes du Colorado USA,
-: Jim :-

* PS Pour être clair, en plus de mon intérêt à poursuivre le programme de recherche envisagé dans cette série d'articles #HeyGitHub, je reste passionnément engagé dans la mise en œuvre du programme de Copilot en tant que #AssistiveTechnology à travers l'étude de recherche et le programme de soutien pour #DéveloppeursDéveloppeurs et # DisabledSTEMstudents décrit dans la plupart des articles de cette publication Medium.

Jim Salmons est un scientifique citoyen post-cancer âgé de soixante et onze ans. Ses recherches principales portent sur le développement d'un format Ground Truth Storage fournissant une structure de document complexe intégrée et un modèle de représentation du contenu pour l'étude des collections numérisées de magazines et de journaux de l'ère de l'impression. Une chute à domicile en juillet 2020 a entraîné une grave blessure à la moelle épinière qui a considérablement compromis sa dextérité manuelle et sa mobilité.

Jim a eu la chance d'avoir accès à la communauté d'accès anticipé à la technologie GitHub Copilot lors de ses premiers efforts pour se remettre au travail sur les activités de développement d'outils basés sur Python de son principal intérêt de recherche. Après avoir expérimenté l'impact positif spectaculaire de GitHub Copilot sur sa propre productivité de développement, il s'est passionnément intéressé à la conception d'un programme de recherche et de soutien pour étudier et documenter l'utilisation de cette technologie d'assistance à la programmation innovante à l'usage des développeurs handicapés.