„HeyGitHub!“, Gedanken zu Agency und Conversational Copilot

In meinen letzten beiden eher technischen Artikeln für diese Veröffentlichung ließ ich mich auf eine ziemlich ungebundene Vision ein, „sherlockeanisches“ deduktives Denken in den #HeyGitHub -Sprachcodierungsdialog zwischen #DisabledDevelopers und dem brillanten, aber savantartigen „Rainman“-GitHub einzufügen Copilot-Code-Generator. Während ich diese Artikel schrieb, begann ich mit der Suche nach Methoden und öffentlich verfügbaren Implementierungen von Fortschritten in der Forschungsgemeinschaft für maschinelles Lernen, die die Art von Unterstützung bieten könnten, die für die Implementierung dieser durchdachteren Gespräche zur Codegenerierung erforderlich ist.

Glücklicherweise habe ich festgestellt, dass es eine Reihe von Forschungsgemeinschaften für maschinelles Lernen gibt, die an diesen Herausforderungen arbeiten, um „menschenähnlichere“ Denkprozesse zu unterstützen, die Kontext und Vorwissen als Ergänzung zur Brute-Force-Mustererkennung von LLM verwenden ( Large Language Model )-Leistung. Ich habe unter anderem etwas über #CoT ( Chain of Thought ), Prompt-Sequencing , Model-Switching und Agents in anderen Bereichen der Erforschung und Entwicklung im Bereich des maschinellen Lernens gelernt. Ich fange an, Erfahrungen aus erster Hand mit der aufregenden LangChain- Python-Bibliothek von Harrison Chase und der LangChainAI zu sammelnEntwickler. Viele dieser Breadcrumb-Trails, denen ich gefolgt bin, begannen mit dem Lesen des aufschlussreichen Übersichtsartikels „The Near Future of AI is Action-Driven“ von John McDonnell .

Ich habe auch von einer massiven, hyperfinanzierten Agenda erfahren, die bei Microsoft im Gange ist – Project Bonsai – die KI/ML-Lösungen für die Herausforderungen der Robotikautomatisierung und der industriellen Prozesssteuerung bereitstellt. In diesem Problemfeld der physikalischen Welt sind Simulation und Human-in-the-Loop-Coaching genauso wichtig, wenn nicht sogar wichtiger, als die Betonung von Datenmodellierung und datenwissenschaftlichen Methoden im allgemeineren Anwendungsbereich des maschinellen Lernens.

Mein Fokus in diesem Artikel liegt nicht darauf, tiefer in diese SOTA-Fortschritte einzutauchen, sondern ein wenig über die Rolle der rollenbasierten Agentur zu spekulieren, wie sie auf die #HeyGitHub/Copilot - Plattform zur Unterstützung der Softwareentwicklung nicht nur von angewendet werden kann #DisabledDevelopers und #DisabledSTEMstudents , aber von allen angehenden Entwicklern, die #HeyGitHub/Copilot als Multiplikator für die Entwicklungsproduktivität verwenden.

Eine Wayback-Reflexion über Agency in ausführbaren Geschäftsmodellen

In meinem Metamodel Subgraph- Artikel in dieser #HeyGitHub- Reihe habe ich einen kurzen Überblick über meine Beteiligung an einem Skunkworks gegeben, das ein Smalltalk-basiertes Framework entwickelt, das die dynamische Komposition und Anwendungsgenerierung von EBMs , Executable Business Models , unterstützt .

Anfang bis Mitte der 1990er Jahre gab es eine Reihe modellgetriebener Methoden sowohl für die Softwareentwicklung als auch für das Business Process Engineering. Ein starker Faden in dieser Ära war die BPR- oder Business Process Reengineering- Bewegung. Innerhalb der Beratungsdienste von IBM hieß eine damals beliebte Methode LOVEM , das Line Of Visibility Enterprise Model oder manchmal Line Of Visibility Engineering Method . Im Mittelpunkt dieser Methode stand ein Diagrammformat mit „Schwimmspuren“ für Geschäftsprozessmodelle.

Die Swim Lanes von LOVEM stellten Rollen dar, die entweder von Menschen oder von Maschinen (auch bekannt als Softwareprozesse) gespielt werden könnten. Inspiriert von David Gelernters Buch „Spiegelwelten: oder der Tag, an dem Software das Universum in einen Schuhkarton bringt … Wie es passieren wird und was es bedeuten wird“ von David Gelernter aus dem Jahr 1993. , meine Kollegen und ich in der Object Technology Practice von IBM stellten uns ein Smalltalk - Objekt-Framework vor, das verwendet werden könnte, um diese rollenbasierten LOVEM-Modelle zu erstellen und auszuführen. Unser EBM , Executable Business Model , Framework basierte auf einem Metamodell-„Baukasten“ von Objektklassen, die diesem UML-Klassenmodell aus der frühen Aktivität in meiner Wiedergeburt nach dem Krebs als Digital Humanities Citizen Scientist sehr ähnlich sahen:

Der Aspekt unseres EBM-Modells, den ich in diesem Artikel hervorheben möchte, ist der Klassencluster, der im roten Kasten in der unteren linken Ecke dieses Diagramms zu sehen ist. Diese drei Klassen – Personen oder Agenten als Akteure – nehmen an zielorientierten , rollenbasierten Prozessen teil. Auf diese Weise implementierte unser EBM-Framework das Agenturkonzept, das für die LOVEM-Geschäftsprozessmethode wesentlich ist. Die Implementierung von Agency in unserem Metamodell wurde, wie Sie vielleicht erwarten, von unserer Inspiration für Spiegelwelten angetrieben.

In seinem Buch nahm Gelernter die Leser mit auf ein Gedankenexperiment, das hier paraphrasierend sagte: „Stellen Sie sich vor, wir würden detaillierte Softwaresimulationen unserer komplexen Systeme erstellen, die in der realen Welt arbeiten. Sobald wir diese Simulationen am Laufen haben, stellen Sie sich vor, was passieren würde, wenn wir alle Eingabe- und Ausgabe-Feeds unserer Simulationen nehmen und sie mit den tatsächlichen Feeds in diesen Systemen der realen Welt verbinden würden. An diesem Punkt würden unsere Softwaremodelle aufhören, Simulationen zu sein, und anfangen, Heads-up-Displays oder Dashboard-Ansichten der realen Welt zu sein …“ oder das, was Gelernter Spiegelwelten nannte .

Wir haben diesen Ansatz für die Agentur in unserem EBM-Metamodell-basierten Framework implementiert, damit Agentenobjekte als Software-Proxys für Personen als Akteure von Rollen in ausführbaren LOVEM-Modellen implementiert werden können. Dieses Design gab uns zwei wichtige Merkmale, die mit unserer Inspiration von Mirror Worlds übereinstimmen. Erstens könnten wir während Beratungssitzungen mit Führungskräften von Kunden SMEs, die Fachexperten der Kunden, an vernetzten Laptops in einem Konferenzraum sitzen lassen, um mit unseren sich entwickelnden Simulationsmodellen zu interagieren und diese zu validieren. Während dieser Sitzungen könnten wir eine ausführende Modellinstanz mit Sim-Actor-Agent-Software-Proxys füllen, um alle anderen Rollen in einem modellierten Geschäftsprozess auszuführen.

Sobald die KMU der Kunden davon überzeugt waren, dass wir diese Geschäftsprozesse in unserer EBM-Simulation festgenagelt hatten, konnten wir diese Modelle – in wahrer Spiegelwelten- inspirierter Manier – einfach als eingesetztes System in das eigentliche Kundengeschäft einbinden. Während dieses Verbindungsprozesses würden wir bestimmen, welche Rollen von Personen gespielt werden sollten – unter Verwendung von dynamisch generierten EBM-Ansichten auf dem Modell, das von Benutzern als typische Softwareanwendungen gesehen wird – oder von Rollen, die von Software-Proxy-Agent-Akteuren in den Kunden zu spielen sind Geschäftsabläufe.

Wenn ich an diese Zeit vor fast dreißig Jahren zurückdenke, waren meine Tage als Vordenker/Entwickler in diesem EBM-Skunkworks einige der aufregendsten Erfahrungen in meiner beruflichen Laufbahn.

Eine zukunftsgerichtete Spekulation über eine Agentur in der #HeyGitHub/Copilot-Plattform

Wie könnte also das Konzept der Agency dazu beitragen, die Fähigkeiten von Ansätzen wie Chain of Thought, Prompt-Sequencing und Model-Switching als Teil des sich entwickelnden Stacks von Technologien zu nutzen, die zur Implementierung des #HeyGitHub/Copilot-Dienstes von GitHub beitragen?

Ohne die Absicht, ein strenges oder nicht triviales Beispiel zu geben, könnten wir dieses Konzept der rollenbasierten Agentur aus meiner EBM-Erfahrung auf das Lösungsdesign des #HeyGitHub/Copilot-Dienstes anwenden, wie in diesem einfachen Swimlane-Diagramm:

Was wir in diesem übermäßig einfachen Diagramm sehen, ist eine Gruppe von vier Swimlanes in den oberen Schichten, die aktiv als Mensch und drei Software-Agenten interagieren, deren Konversation zur letztendlichen Generation in den „dummen“/Datenschreiber-ähnlichen Rollen der IDE führt App und Quelldatei (Speicher). Dieses einfache Diagramm macht deutlich, dass die enorme Herausforderung, vor der wir in Zukunft stehen, darin besteht, „Sherlockean Smarts“ in diese agentenbasierte Konversation einzubringen, bevor wir unseren gelehrten Rainman-Agent Copilot LLM optimal nutzen.

Stellen Sie sich vor, unsere Designanforderung besteht beispielsweise darin, einen hochfunktionalen Telefon-Callcenter-Bot-Agenten zu erstellen. In diesem Fall könnte ein flexibles Repertoire an vorlagenbasierten Eingabeaufforderungen, die für ein zielorientiertes Ergebnis dynamisch ausgewählt werden können, ausreichen, um zum Einsatz zu gelangen. Aber erfolgreich als nicht-menschlicher Paarprogrammierer (Agent „Buddy“) zu agieren, wie GitHub oft bei der Beschreibung seines Copilot-Dienstes behauptet, müssen die #HeyGitHub Listener und CoT Dialoguer Agents eine weitaus komplexere Intelligenz implementieren als ein skriptfähiger Call Center-Bot Konversation.

Nehmen wir zum Beispiel die Herausforderung für #HeyGitHub/Copilot, die einem Entwickler hilft, die UI/UX – Benutzeroberfläche und interaktive Erfahrung – für eine Anwendung zu erstellen. Es gibt eine anständige Anzahl hervorragender UI/UX-Frameworks, die der Entwickler verwenden könnte. Unser Rainman-Experte Copilot hat bereits unzählige Beispiele dieser Frameworks in der Grundlagenmodellschulung des Copiloten gesehen, um sein Talent zur Codegenerierung zu verfeinern. Aber in der Lage zu sein, hilfreiche Code-Vorschläge auf der Grundlage von Mustererkennung aus seiner Trainingserfahrung bereitzustellen, verleiht Copilot nicht das zugrunde liegende Verständnis der Framework-Architektur, Best Practices und Benutzeroberflächen-/Interaktionsrichtlinien, die ein kompetenter menschlicher Entwickler für die Rolle der Teilnahme mitbringt in einer Programmierpaar-Partnerschaft.

Betrachten Sie das Beispiel des wxPython- Wrappers auf dem ehrwürdigen C++- Framework wxWidgets . Kein beliebiger Spaziergang durch die unzähligen öffentlich zugänglichen Code-Repositories wird den Umfang des Wissens offenbaren, das durch einen tiefen Einblick in die ausgezeichnete Online-Dokumentations-Website unter vermittelt wirdhttps://docs.wxpython.org/. Keine noch so große NLP-Zerlegung, Themenmodellierung/summierende Grübelei über den Inhalt dieser Website wird ausreichen, um menschliches Entwicklerwissen in die #HeyGitHub/Copilot<>Entwickler-Konversation einzubringen.

Also, wohin gehen wir von hier aus?

Ich wünschte, ich hätte genug Domänenwissen, um einen spezifischen Lösungsentwurf und Entwicklungspfad vorzuschlagen, um die Technologien zu entwickeln, die erforderlich sind, um die Leistung der heutigen codegenerierenden LLMs auf das sprichwörtliche „nächste Niveau“ zu bringen. Während die vollständige Roadmap noch geschrieben werden muss, gibt es einige Annahmen, die wir über die nächsten Schritte treffen können. Wir können davon ausgehen, dass es für den #HeyGitHub-Listener- Agenten wichtig sein wird, zwischen Entwickler-Spracheingaben unterscheiden zu können, die eine Übergabe an den CoT-Dialoguer für eine weitere durchdachte Interaktion erfordern oder in Textform an den Copilot-LLM weitergeleitet werden müssen Generierung von Codevorschlägen.

Die knorrige Herausforderung, die vor uns liegt, besteht darin, die Informationsstrukturen und die semantische Bedeutung der Kunst und Wissenschaft des Software-Engineering so zu kapseln, dass der CoT Dialoguer glaubwürdig als echter Programmierpaar-Partner auftreten kann. Die Technologien zur Bewältigung dieser Herausforderung werden wahrscheinlich von den führenden Forschungsaktivitäten rund um Chain of Thought, Prompt Selection/Sequencing, Model Switching und Human-in-the-Loop Reinforcement Learning/Coaching stammen.

Einige der Durchbrüche in diesem „Sherlockean Smarts“-Lösungsbereich werden brillante innovative Codierungen von Forschungsingenieuren für maschinelles Lernen beinhalten. Ich glaube jedoch auch, dass ein nicht trivialer Beitrag zu dieser Herausforderung aus dem Design und der Entwicklung effektiver Ground-Truth-Referenzmodelldatensätze kommen wird, die als Lehrplanmaterialien für domänenspezifische Modelle dienen werden, um Hand in Hand zu arbeiten Modellwechselkontext mit dem sich ständig weiterentwickelnden grundlegenden Copilot Large Language Model. Ein Beispiel für diese neuen Referenzdatensätze ist das Metamodel Subgraph Ground Truth Storage- Design, das ich während meiner Digital Humanities-Forschung verfolgt habe und das ich hier in meiner #HeyGitHub-Artikelserie vorgestellt habe.

Aber die Entwicklung eines standardmäßigen agentenorientierten Ground-Truth-Referenzdatensatzformats wird nicht ausreichen, um die Sherlocke-Dialoge hervorzurufen, die ich mir zwischen einem menschlichen Entwickler und einem ML-basierten Copilot Pair Programming-Partner vorstelle. Vielmehr müssen diese Ground-Truth-Referenzdatensätze mit Domänenwissen als Lehrmaterial in Modelltrainingsszenarien für simulierte benutzerinteraktive Szenarien dienen, die die Fähigkeit des CoT Dialoguer-Agenten verfeinern, sich an einem kooperativen Gespräch mit seinem menschlichen Entwicklerpartner zu beteiligen. Diese Simulationssitzungen können die Zeit komprimieren und unermüdlich die effektive Nutzung von Domänenwissen durch den CoT Dialoguer verfeinern.

So wie wir jetzt Best Practices für die Datenmodellierung verwenden, um Trainingsdatensätze für aktuelle datenintensive ML-Anwendungen zu generieren, werden wir auch in der Lage sein, agentenbasierte Simulationserfahrungen zu generieren, die es unseren wissensbasierten Anwendungen ermöglichen, Modelle wie die vorgestellten zu trainieren und zu verfeinern zukünftiger #HeyGitHub/Copilot-Dienst. Als Teil dieser Mirror Worlds -ähnlichen Simulationstrainingsumgebung wird der Gesprächsaustausch, der das #HeyGitHub CoT Dialoguer-Modell im Training behindert, dem Human-in-the-Loop-Supervisor angezeigt, dessen Reaktionscoaching angemessenes Modellverhalten fördert und verstärkt.

A Couple Bees in the Bonnets bei GitHub und Microsoft

An diesem Punkt sind meine Vorstellungen von der Zukunft kaum mehr als die Fieberträume eines unabhängigen Digital Humanities Citizen Scientist und behinderten Entwicklers. Aber wenn ich meinen alten IBM-Beraterhut abstauben müsste, um ein paar Bienen in die Motorhauben von GitHub und Microsoft zu stecken, wüsste ich, was ich vorschlagen würde…

Zunächst kann ich nicht anders als zu sagen, wenn ich Teil des GitHub-Managements wäre, würde ich mir eine Stelle als Mitglied des GitHub Next-Forschungsteams anbieten. In dieser Position würde ich fleißig an den Ideen arbeiten, über die ich in dieser Reihe von #HeyGitHub-Artikeln * geschrieben habe .

Als Nächstes, sobald wir einen Proof of Concept für die Trainingsdatensätze des Metamodel Subgraph Ground Truth-Domänenwissensmodells haben, würde ich mich dafür einsetzen, einen Teil des kürzlich angekündigten GitHub Accelerator oder des M12 GitHub Fund zu widmen, um Stipendien oder die Finanzierung von Projektstarts für hohe Leistung bereitzustellen , erfahrene Open-Source-Entwickler, um eine Sammlung dieser domänenspezifischen agentenorientierten Modelltrainingsdatensätze zu erstellen. Ein besonderer Schwerpunkt sollte auf die Entwicklung von UI/UX-Framework-spezifischen metamodellbasierten Trainingsdatensätzen gelegt werden.

Warum UI/UX-Framework-spezifische Domänenwissensdatensätze? Denn diese „Beasts“ sind oft große, komplexe Architekturen mit parameterweise zu detaillierter Anpassung. Und für die meisten Entwicklungsprojektszenarien sind das Erstellen einer Anwendungs-UI und ihrer Benutzerinteraktionen notwendige Aktivitäten, die Zeit und Mühe kosten, um die Lösung für den Problembereich des Projekts zu codieren, den die Anwendungs-UI/UX dem Endbenutzer des Projekts einfach zur Verfügung stellt. Die Bereitstellung einer starken UI/UX-Framework-Codegenerierung durch Spracheingabe in #HeyGitHub/Copilot ist dann vergleichbar mit einem UI/UX-Framework mit einer leistungsstarken WYSIWYG-Interface-Builder-Anwendung.

Als weitreichendere und strategische Empfehlung würde ich richtungsweisende Kontakte von GitHub Next und Microsofts Project Bonsai ermutigen, ein Collaboration Committee zu bilden. Der Zweck dieser Gruppe wäre es, Möglichkeiten zu erkunden, wie GitHub die Best Practices und Erfahrungen aus dem umfassenden Engagement von Microsoft in den Märkten für Roboter und industrielle Prozessautomatisierung nutzen könnte.

Und lauert hoffentlich direkt hinter dem Horizont

Wenn ich den Innovation Highway noch weiter hinunterblicke, während ich meine rosafarbene Brille und mein optimistisches Slogan-T-Shirt aufsetze, wo könnte diese Forschungsagenda hinführen? Wenn wir nach dem Erstellen einer begrenzten Anzahl von domänenspezifischen Metamodel Subgraph-Referenz-Ground-Truth-Datensätzen und dem Aufbringen der Zeit und Mühe, ein maschinelles Lernmodell so zu trainieren, dass es die Rolle des CoT Dialoguer-Agenten in einer Reihe von Domänen spielt, werden wir eines Tages das Dialoguer-System sehen emergentes Verhalten demonstrieren .

Damit meine ich, dass das CoT Dialoguer Agent-Modell die verallgemeinerte Struktur und Verwendung von Domänenwissen so gut verstehen kann, dass es nicht mit einem neuen domänenspezifischen Referenzmodell vorab geladen werden muss, um bei der Teilnahme an einem neuen Kontext nützlich zu werden. Auf dieser Funktionsebene kann das Multi-Modell-System #HeyGitHub/Copilot der fernen Zukunft einfach in ein selbstgesteuertes Lerngespräch mit seinem Developer Pair Programming-Partner eintreten, um sein eigenes neues Domänenwissensmodell zu erstellen und zu validieren. Durch diesen Prozess kann der #HeyGitHub/Copilot-Dienst zu einem wirklich vielseitigen Partner auf Peer-Level-Ebene beim Design und der Entwicklung wesentlicher Softwaresysteme werden.

Abschließend

Nachdem ich meinen Krebskampf überstanden und gelernt habe, mit den Geschicklichkeits- und Mobilitätsherausforderungen meiner Rückenmarksverletzung umzugehen, würde ich nichts mehr lieben, als die Chance zu haben, den Reaper zu besiegen, indem ich zu der aufregenden kommenden Welle bemerkenswerter Innovationen in Design und Entwicklung beitragen würde von Software, wie sie in meiner Artikelserie #HeyGitHub vorgestellt wird. ✌️

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

* PS Um es klar zu sagen: Zusätzlich zu meinem Interesse, die in dieser #HeyGitHub-Artikelserie vorgesehene Forschungsagenda zu verfolgen, setze ich mich weiterhin leidenschaftlich für die Umsetzung der Agenda von Copilot als #AssistiveTechnology durch das Forschungsstudien- und Unterstützungsprogramm für #DisabledDevelopers und # Behinderte MINT-Studenten, die in der Mehrzahl der Artikel in dieser Medium-Publikation beschrieben werden.

Jim Salmons ist ein 71-jähriger Digital Humanities Citizen Scientist nach seiner Krebserkrankung. Seine Hauptforschung konzentriert sich auf die Entwicklung eines Ground-Truth-Speicherformats, das ein integriertes komplexes Dokumentstruktur- und Inhaltsdarstellungsmodell für das Studium digitalisierter Sammlungen von Zeitschriften und Zeitungen aus der Druckzeit bereitstellt. Ein Sturz im Juli 2020 zu Hause führte zu einer schweren Rückenmarksverletzung, die seine manuelle Geschicklichkeit und Mobilität dramatisch beeinträchtigt hat.

Jim hatte das Glück, während seiner anfänglichen Bemühungen, wieder an den Aktivitäten zur Entwicklung von Python-basierten Tools zu arbeiten, die seinem primären Forschungsinteresse entsprechen, Zugang zur GitHub Copilot Technology Early Access Community erhalten. Als er die dramatischen positiven Auswirkungen von GitHub Copilot auf seine eigene Entwicklungsproduktivität erlebte, interessierte er sich leidenschaftlich dafür, ein Forschungs- und Unterstützungsprogramm zu entwickeln, um die Verwendung dieser innovativen unterstützenden Programmiertechnologie für behinderte Entwickler zu untersuchen und zu dokumentieren.