„HeyGitHub!”, Myśli o agencji i Drugi pilot konwersacyjny

W moich dwóch ostatnich bardziej technicznych artykułach do tej publikacji pozwoliłem sobie na raczej nieskrępowaną wizję dodania dedukcyjnego myślenia „Sherlocke” do dialogu kodowania głosowego #HeyGitHub między #DisabledDevelopers a genialnym, ale przypominającym uczony „Rainman” GitHub Generator kodu drugiego pilota. Pisząc te artykuły, zacząłem szukać metod i publicznie dostępnych implementacji postępów w społeczności badaczy uczenia maszynowego, które mogłyby zapewnić wsparcie potrzebne do wdrożenia tych bardziej przemyślanych konwersacji generujących kod.

Na szczęście odkryłem, że istnieje wiele subspołeczności badawczych zajmujących się uczeniem maszynowym, które pracują nad tymi wyzwaniami, aby wspierać bardziej „ludzkie” procesy myślenia, wykorzystując kontekst i wcześniejszą wiedzę, jako uzupełnienie rozpoznawania wzorców LLM metodą brutalnej siły ( Model dużego języka ) wydajność. Dowiedziałem się o #CoT ( Chain of Thought ), sekwencjonowaniu podpowiedzi , przełączaniu modeli i agentach wśród innych obszarów eksploracji i rozwoju w domenie uczenia maszynowego. Zaczynam zdobywać doświadczenie z pierwszej ręki, korzystając z ekscytującej biblioteki LangChain Python od Harrisona Chase'a i LangChainAIprogramiści. Wiele z tych ścieżek nawigacyjnych, którymi podążałem, zaczęło się od przeczytania wnikliwego artykułu przeglądowego „The Near Future of AI is Action-Driven” autorstwa Johna McDonnella .

Dowiedziałem się również o szeroko zakrojonym, hiperfinansowanym programie realizowanym w firmie Microsoft — Project Bonsai — który polega na wprowadzaniu rozwiązań AI/ML w odpowiedzi na wyzwania związane z automatyzacją robotyki i kontrolą procesów przemysłowych. W tej przestrzeni problemowej świata fizycznego symulacja i coaching typu „człowiek w pętli” są równie ważne, jeśli nie ważniejsze, jak nacisk na modelowanie danych i metody analizy danych w bardziej ogólnej domenie aplikacji uczenia maszynowego.

W tym artykule nie skupiam się na głębszym zagłębianiu się w te postępy SOTA, ale raczej na spekulacjach na temat roli agencji opartej na rolach, ponieważ może ona być zastosowana na platformie #HeyGitHub/Copilot we wspieraniu rozwoju oprogramowania nie tylko przez #DisabledDevelopers i #DisabledSTEMstudents , ale przez wszystkich potencjalnych programistów używających #HeyGitHub/Copilot jako mnożnika produktywności programistycznej.

Refleksja Wayback na temat agencji w wykonywalnych modelach biznesowych

W moim artykule Metamodel Subgraph w tej serii #HeyGitHub przedstawiłem krótki przegląd mojego zaangażowania w skunkworks rozwijającą platformę opartą na Smalltalk, wspierającą dynamiczną kompozycję i generowanie aplikacji EBM , wykonywalnych modeli biznesowych .

Na początku połowy lat 90. pojawił się szereg metod opartych na modelach, zarówno dla rozwoju oprogramowania, jak i inżynierii procesów biznesowych. Jednym z silnych wątków tej epoki był ruch BPR , czyli Business Process Reengineering . W ramach usług konsultingowych IBM popularna metoda stosowana w tamtym czasie nosiła nazwę LOVEM , Line Of Visibility Enterprise Model lub czasami Line Of Visibility Engineering Method . Centralnym elementem tej metody był format diagramu wykorzystujący „ścieżki do pływania” dla modeli procesów biznesowych.

Tory pływackie LOVEM reprezentowały role, które mogą odgrywać ludzie lub maszyny (procesy oprogramowania AKA). Zainspirowany książką Davida Gelerntera z 1993 r. „Mirror Worlds: or the Day Software Puts the Universe in the Shoebox… How It Will Happen and What It Will Mean”. , moi koledzy i ja z działu technologii obiektowych IBM wyobraziliśmy sobie platformę obiektową Smalltalk , której można by użyć do komponowania i wykonywania tych opartych na rolach modeli LOVEM. Nasz EBM , Executable Business Model , został oparty na metamodelu „zestawie konstrukcyjnym” klas obiektów, który wyglądał bardzo podobnie do tego modelu klasy UML z wczesnej działalności mojego odrodzenia po chorobie nowotworowej jako naukowca obywatelskiego humanistyki cyfrowej:

Aspektem naszego modelu EBM, który chcę podkreślić w tym artykule, jest klaster widoczny w czerwonym polu w lewym dolnym rogu tego diagramu. Te trzy klasy — osoby lub agenci jako aktorzy — uczestniczą w procesach opartych na celach i rolach . W ten sposób nasz framework EBM zaimplementował koncepcję Agencji niezbędną dla metody procesów biznesowych LOVEM. Implementacja Agencji w naszym metamodelu była, jak można się spodziewać, inspirowana Lustrzanymi Światami .

W swojej książce Gelernter zabrał czytelników na eksperyment myślowy, który parafrazując tutaj, powiedział: „Wyobraź sobie, że zbudowaliśmy szczegółowe symulacje oprogramowania naszych złożonych systemów działających w prawdziwym świecie. Kiedy już te symulacje będą nucić, wyobraź sobie, co by się stało, gdybyśmy wzięli wszystkie kanały wejściowe i wyjściowe naszych symulacji i podłączyli je do rzeczywistych kanałów w tych rzeczywistych systemach. W tym momencie nasze modele oprogramowania przestałyby być symulacjami i zaczęłyby być wyświetlaczami przeziernymi lub widokami deski rozdzielczej w prawdziwym świecie… lub jak Gelernter nazwał światy lustrzane .

Wdrożyliśmy to podejście do agencji w naszym frameworku opartym na metamodelu EBM, aby obiekty agentów mogły być implementowane jako programowe proxy dla osób jako aktorów ról w wykonywalnych modelach LOVEM. Ten projekt dał nam dwie ważne cechy zgodne z naszą inspiracją Mirror Worlds . Po pierwsze, podczas sesji konsultacyjnych z kierownikami klientów mogliśmy poprosić MŚP, ekspertów merytorycznych klientów, aby siedzieli przy podłączonych do sieci laptopach w sali konferencyjnej, aby wchodzić w interakcje z naszymi ewoluującymi modelami symulacyjnymi i weryfikować je. Podczas tych sesji mogliśmy zapełnić działającą instancję modelu agentami oprogramowania sim-actor Agent, aby wykonywać wszystkie pozostałe role w modelowanym procesie biznesowym.

Kiedy MŚP klientów przekonały się, że udało nam się uchwycić te procesy biznesowe w naszej symulacji EBM, mogliśmy — w sposób prawdziwie inspirowany Mirror Worlds — po prostu podłączyć te modele jako wdrożony system w rzeczywistej działalności klienta. Podczas tego procesu łączenia określalibyśmy, jakie Role mają odgrywać Osoby — korzystając z dynamicznie generowanych widoków EBM na modelu postrzeganym przez użytkowników jako typowe aplikacje — lub Role, które mają odgrywać programowe proxy Agent Aktorzy w środowisku klienta procesy biznesowe.

Zastanawiając się nad tym okresem prawie trzydzieści lat temu, dni spędzone jako lider myśli/programista w skunkworks EBM były jednymi z najbardziej ekscytujących doświadczeń w mojej karierze zawodowej.

Przyszłościowe spekulacje na temat agencji na platformie #HeyGitHub/Copilot

W jaki sposób koncepcja agencji może przyczynić się do wykorzystania przez nas możliwości takich podejść, jak łańcuch myśli, szybkie sekwencjonowanie i przełączanie modeli w ramach ewoluującego stosu technologii przyczyniających się do wdrażania usługi GitHub #HeyGitHub/Copilot?

Bez intencji rygoryzmu lub nietrywialnego przykładu, możemy zastosować tę koncepcję agencji opartej na rolach z mojego doświadczenia w EBM do projektu rozwiązania usługi #HeyGitHub/Copilot, jak na tym prostym schemacie toru pływania:

To, co widzimy na tym zbyt prostym diagramie, to skupisko czterech torów pływackich w górnych warstwach, które aktywnie wchodzą w interakcje jako człowiek i trzech agentów oprogramowania, których rozmowa prowadzi do ostatecznego wygenerowania „głupich”/podobnych do transkrypcji danych ról IDE aplikacja i plik źródłowy (pamięć). Ten prosty diagram jasno pokazuje, że ogromnym wyzwaniem, przed którym stoimy, jest wstrzyknięcie „sprytnych Sherlocków” do rozmowy opartej na agentach, zanim jak najlepiej wykorzystamy naszego uczonego Rainmana-Agenta drugiego pilota LLM.

Wyobraź sobie, że naszym wymaganiem projektowym jest na przykład stworzenie wysoce funkcjonalnego bota telefonicznego Call Center Agent. W takim przypadku elastyczny repertuar monitów opartych na szablonach, które można dynamicznie wybierać w celu uzyskania wyniku zorientowanego na cel, może wystarczyć do wdrożenia. Ale z powodzeniem działając jako nie-ludzki programista w parze (Agent „kumpel”), jak GitHub często zapewnia opisując swoją usługę Copilot, agenci #HeyGitHub Listener i CoT Dialoguer będą musieli zaimplementować znacznie bardziej złożoną inteligencję niż skryptowalny bot Call Center rozmowa.

Weźmy na przykład wyzwanie #HeyGitHub/Copilot pomagające programiście w stworzeniu UI/UX — interfejsu użytkownika i interaktywnego doświadczenia — dla aplikacji. Istnieje przyzwoita liczba doskonałych frameworków UI/UX, z których może korzystać programista. Nasz drugi pilot, znający się na Rainmanie, widział już niezliczone przykłady tych ram podczas podstawowego szkolenia drugiego pilota, aby udoskonalić jego talent do generowania kodu. Jednak możliwość pomocnego dostarczania sugestii dotyczących kodu w oparciu o rozpoznawanie wzorców na podstawie doświadczenia szkoleniowego nie zapewnia Copilotowi podstawowego zrozumienia architektury ramowej, najlepszych praktyk i wytycznych dotyczących interfejsu użytkownika/interakcji, które kompetentny programista wnosi do roli uczestniczącego w partnerstwie Par Programujących.

Rozważmy przykład opakowania wxPython w czcigodnym środowisku C++ wxWidgets . Żadna ilość przypadkowych spacerów po niezliczonych publicznie dostępnych repozytoriach kodu nie ujawni zakresu wiedzy przekazanej poprzez głębokie zanurzenie się w doskonałej witrynie internetowej z dokumentacją online pod adresemhttps://docs.wxpython.org/. Żadna ilość dekompozycji NLP, modelowania tematów/podsumowywania treści tej witryny nie wystarczy, aby przekazać wiedzę człowieka i programisty w rozmowie #HeyGitHub/Copilot<>Developer.

Więc dokąd idziemy stąd?

Chciałbym mieć wystarczającą wiedzę dziedzinową, aby zasugerować konkretną ścieżkę projektowania i rozwoju rozwiązania, aby stworzyć technologie potrzebne do przeniesienia wydajności dzisiejszych LLM generujących kod na przysłowiowy „wyższy poziom”. Chociaż pełna mapa drogowa nie została jeszcze napisana, możemy przyjąć pewne założenia dotyczące kolejnych kroków. Możemy przewidzieć, że dla agenta #HeyGitHub Listener ważne będzie rozróżnienie poleceń głosowych programisty, które wymagają przekazania do Dialogera CoT w celu dalszej przemyślanej interakcji lub przekazane w formie tekstowej do Copilot LLM w celu generowanie sugestii kodu.

Stojącym przed nami wielkim wyzwaniem jest hermetyzacja struktur informacyjnych i semantycznego znaczenia sztuki i nauki inżynierii oprogramowania, tak aby CoT Dialoguer mógł wiarygodnie działać jako prawdziwy partner Programming Pair. Technologie umożliwiające sprostanie temu wyzwaniu będą prawdopodobnie pochodzić z najnowocześniejszych działań badawczych związanych z Łańcuchem Myśli, szybką selekcją/sekwencjonowaniem, przełączaniem modeli i uczeniem się/coachingiem ze wzmacnianiem człowieka w pętli.

Niektóre z przełomowych rozwiązań w tej przestrzeni rozwiązań „Sherlockean smarts” będą obejmować genialne, innowacyjne kodowanie opracowane przez inżynierów zajmujących się uczeniem maszynowym. Wierzę jednak również, że niebanalnym wkładem w to wyzwanie będzie zaprojektowanie i opracowanie skutecznych zestawów danych modelu referencyjnego Ground Truth , które posłużą jako materiały szkoleniowe dla modeli specyficznych dla danej dziedziny, które będą pracować ramię w ramię w kontekst przełączania modeli dzięki stale ewoluującemu podstawowemu dużemu modelowi językowemu Copilot. Przykładem tych pojawiających się zestawów danych referencyjnych jest projekt Metamodel Subgraph Ground Truth Storage , który realizowałem w ramach moich badań nad humanistyką cyfrową i wyobrażałem sobie tutaj w mojej serii artykułów #HeyGitHub.

Jednak opracowanie standardowego zestawu danych referencyjnych Ground Truth zorientowanego na agenta nie wystarczy, aby wywołać dialogi Sherlocka, jakie sobie wyobrażam, między programistą-człowiekiem a partnerem w zakresie drugiego pilota programistycznego opartego na ML. Te referencyjne zestawy danych Ground Truth będą raczej musiały służyć jako materiał instruktażowy w symulowanych interaktywnych scenariuszach szkolenia modeli, które udoskonalają zdolność agenta CoT Dialoguer do angażowania się we wspólną rozmowę z jego ludzkim partnerem programistą. Te sesje symulacyjne mogą skrócić czas i niestrudzenie dążyć do udoskonalenia efektywnego wykorzystania wiedzy domenowej przez CoT Dialoguer.

Tak jak obecnie używamy najlepszych praktyk modelowania danych do generowania zestawów danych szkoleniowych dla bieżących aplikacji ML intensywnie korzystających z danych, tak też będziemy w stanie generować doświadczenia symulacyjne oparte na agentach, które pozwolą naszym aplikacjom opartym na wiedzy trenować i udoskonalać modele, takie jak wyimaginowane przyszła usługa #HeyGitHub/Copilot. W ramach tego symulacyjnego środowiska szkoleniowego przypominającego Mirror Worlds wymiany konwersacyjne, które utrudniają treningowy model #HeyGitHub CoT Dialoguer, pojawią się u Supervisora, którego coaching odpowiedzi zachęci i wzmocni odpowiednie zachowanie modelu.

A Couple Bees in the Bonnets w GitHub i Microsoft

W tym momencie moje próby wyobrażenia sobie przyszłości są niczym więcej niż gorączkowymi marzeniami niezależnego naukowca i niepełnosprawnego programisty zajmującego się humanistyką cyfrową. Ale gdybym miał odkurzyć mój stary kapelusz konsultanta IBM, aby włożyć kilka pszczół do maski w GitHub i Microsoft, wiem, co bym zasugerował…

Po pierwsze, nie mogę się powstrzymać od stwierdzenia, że ​​gdybym był częścią zarządzania GitHub, zaoferowałbym mi pracę jako członek zespołu badawczego GitHub Next. Na tym stanowisku sumiennie pracowałbym nad pomysłami, o których pisałem w tej serii artykułów #HeyGitHub * .

Następnie, kiedy już będziemy mieć Proof of Concept dla zestawów danych do szkolenia modeli wiedzy w domenie Metamodel Subgraph Ground Truth, lobbowałbym za przeznaczeniem części niedawno ogłoszonego GitHub Accelerator lub funduszu M12 GitHub, aby zapewnić stypendia lub fundusze na start projektów dla wysokowydajnych , doświadczeni programiści Open Source, aby stworzyć kolekcję tych zestawów danych do szkolenia modeli zorientowanych na agentów. Szczególny nacisk należy wziąć pod uwagę przy opracowywaniu zestawów danych szkoleniowych opartych na metamodelach specyficznych dla ram UI/UX.

Dlaczego zestawy danych domeny specyficzne dla UI/UX? Ponieważ te „bestie” to często duże, złożone architektury z nadmiernie szczegółowymi parametrami dostosowywania. W przypadku większości scenariuszy projektów rozwojowych tworzenie interfejsu użytkownika aplikacji i interakcji z użytkownikiem to niezbędne czynności, które zabierają czas i wysiłek od kodowania rozwiązania przestrzeni problemowej projektu, którą prosty interfejs użytkownika/UX aplikacji udostępnia użytkownikowi końcowemu projektu. Zapewnienie silnego generowania kodu frameworka UI/UX poprzez wprowadzanie głosowe w #HeyGitHub/Copilot jest zatem porównywalne z posiadaniem frameworka UI/UX z potężną aplikacją do tworzenia interfejsów WYSIWYG.

W ramach bardziej dalekosiężnej i strategicznej rekomendacji zachęcam wiodące kontakty z GitHub Next i Microsoft Project Bonsai do utworzenia Komitetu Współpracy. Celem tej grupy byłoby zbadanie, w jaki sposób GitHub mógłby wykorzystać najlepsze praktyki i doświadczenie wynikające z rozległego zaangażowania firmy Microsoft w rynek robotyki i automatyzacji procesów przemysłowych.

I miejmy nadzieję, że czai się tuż za horyzontem

Patrząc jeszcze dalej w dół Autostrady Innowacji, zakładając moje różowe okulary i optymistyczną koszulkę z hasłem, dokąd może prowadzić ten program badawczy? Jeśli po utworzeniu ograniczonej liczby specyficznych dla domeny zestawów danych Metamodel Subgraph odwołujących się do Ground Truth oraz poświęceniu czasu i wysiłku na wytrenowanie modelu uczenia maszynowego, aby odgrywał rolę agenta CoT Dialoguer w wielu domenach, pewnego dnia możemy zobaczyć system Dialoguer zademonstrować wyłaniające się zachowanie .

Rozumiem przez to, że model agenta dialogu CoT może tak dobrze rozumieć uogólnioną strukturę i wykorzystanie wiedzy domenowej, że nie musi być wstępnie ładowany z nowym modelem referencyjnym specyficznym dla domeny, aby stać się użytecznym w uczestnictwie w nowym kontekście. Na tym poziomie funkcji wielomodelowy system #HeyGitHub/Copilot z dalekiej przyszłości może po prostu zaangażować się w samodzielną rozmowę edukacyjną ze swoim partnerem programistycznym w parze programistów, aby stworzyć i zweryfikować własny nowy model wiedzy w domenie. Dzięki temu procesowi usługa #HeyGitHub/Copilot może stać się prawdziwie wszechstronnym współpracownikiem na poziomie równorzędnym w projektowaniu i rozwoju podstawowych systemów oprogramowania.

W zamknięciu

Po tym, jak przeżyłem walkę z rakiem i nauczyłem się radzić sobie z wyzwaniami związanymi ze zręcznością i mobilnością spowodowanymi urazem rdzenia kręgowego, niczego nie pragnę bardziej niż szansy na pokonanie Żniwiarza, przyczyniając się do nadchodzącej ekscytującej fali niezwykłych innowacji w zakresie projektowania i rozwoju oprogramowania zgodnie z moją serią artykułów #HeyGitHub. ✌️

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

* PS Aby było jasne, oprócz mojego zainteresowania realizacją programu badawczego przewidzianego w tej serii artykułów #HeyGitHub, pozostaję z pasją zaangażowany we wdrażanie programu Copilot jako #AssistiveTechnology poprzez badanie badawcze i program wsparcia dla #DisabledDevelopers i # Niepełnosprawni studenci STEM opisali większość artykułów w tej publikacji Medium.

Jim Salmons jest siedemdziesięciojednoletnim naukowcem obywatelskim zajmującym się humanistyką cyfrową. Jego główne badania koncentrują się na opracowaniu formatu Ground Truth Storage zapewniającego zintegrowaną złożoną strukturę dokumentów i model przedstawiania treści do badania zdigitalizowanych zbiorów czasopism i gazet z epoki drukowanej. Upadek w domu w lipcu 2020 roku doprowadził do poważnego urazu rdzenia kręgowego, który dramatycznie ograniczył jego sprawność manualną i mobilność.

Jim miał szczęście, że uzyskał dostęp do społeczności GitHub Copilot Technology Early Access Community podczas swoich początkowych starań o powrót do pracy nad rozwojem narzędzi opartych na Pythonie, które były jego głównymi zainteresowaniami badawczymi. Doświadczywszy dramatycznego pozytywnego wpływu GitHub Copilot na własną produktywność programistyczną, z pasją zainteresował się projektowaniem programu badawczego i wsparcia w celu zbadania i udokumentowania wykorzystania tej innowacyjnej technologii wspomagającej programowanie dla niepełnosprawnych programistów.