"HeyGitHub!", Pensieri sull'agenzia e copilota conversazionale

Nei miei ultimi due articoli più tecnici per questa pubblicazione, mi sono lasciato andare a una visione piuttosto libera di aggiungere il pensiero deduttivo "sherlockiano" nel dialogo di codifica vocale #HeyGitHub tra #DisabledDevelopers e il brillante ma saggio "Rainman" GitHub Generatore di codice copilota. Durante la stesura di questi articoli, ho iniziato una ricerca di metodi e implementazioni pubblicamente disponibili dei progressi nella comunità di ricerca sull'apprendimento automatico che potrebbero fornire il tipo di supporto necessario per implementare queste conversazioni di generazione di codice più ponderate.

Fortunatamente ho scoperto che ci sono un certo numero di sotto-comunità di ricerca sull'apprendimento automatico che lavorano su queste sfide per supportare processi di pensiero più "umani", utilizzando il contesto e le conoscenze precedenti, come complemento al riconoscimento del modello di forza bruta di LLM ( prestazioni del Large Language Model ). Ho imparato a conoscere #CoT ( Chain of Thought ), il prompt sequencing , il cambio di modello e gli agenti tra le altre aree di esplorazione e sviluppo nel dominio del Machine Learning. Sto iniziando a fare esperienza diretta usando l'entusiasmante libreria LangChain Python di Harrison Chase e LangChainAIsviluppatori. Molti di questi percorsi di breadcrumb che ho seguito sono iniziati leggendo l'intelligente articolo di panoramica, "The Near Future of AI is Action-Driven" , di John McDonnell .

Ho anche appreso di un'agenda massiccia e iperfinanziata in corso presso Microsoft - Project Bonsai - che sta portando soluzioni AI / ML alle sfide dell'automazione robotica e del controllo dei processi industriali. In questo spazio problematico del mondo fisico, la simulazione e il coaching umano nel ciclo sono altrettanto importanti, se non di più, dell'enfasi sui metodi di modellazione dei dati e di scienza dei dati nel più generale dominio applicativo dell'apprendimento automatico.

Il mio obiettivo in questo articolo non è quello di approfondire questi progressi SOTA, ma piuttosto di speculare un po' sul ruolo dell'agenzia basata sui ruoli in quanto potrebbe essere applicata alla piattaforma #HeyGitHub/Copilot a supporto dello sviluppo software non solo da #DisabledDevelopers e #DisabledSTEMstudents , ma da tutti i potenziali sviluppatori che utilizzano #HeyGitHub/Copilot come moltiplicatore della produttività dello sviluppo.

Una riflessione di ritorno sull'agenzia nei modelli di business eseguibili

Nel mio articolo Metamodel Subgraph in questa serie #HeyGitHub , ho fornito una breve panoramica del mio coinvolgimento in uno skunkworks che sviluppa un framework basato su Smalltalk che supporta la composizione dinamica e la generazione di applicazioni di EBM , Executable Business Models .

La prima metà degli anni '90 ha visto una serie di metodi basati su modelli sia per lo sviluppo del software che per l'ingegneria dei processi aziendali. Un filo conduttore in quest'epoca era il movimento BPR , o Business Process Reengineering . All'interno dei servizi di consulenza di IBM, un metodo popolare utilizzato all'epoca era chiamato LOVEM , Line Of Visibility Enterprise Model o, talvolta, Line Of Visibility Engineering Method . Al centro di questo metodo c'era un formato di diagramma che utilizzava "corsie di nuoto" per i modelli di processi aziendali.

Le corsie di nuoto di LOVEM rappresentavano ruoli che potevano essere interpretati da esseri umani o macchine (processi software AKA). Ispirato al libro di David Gelernter del 1993, "Mirror Worlds: or the Day Software Puts the Universe in a Shoebox...How It Will Happen and What Will Mean". , io e i miei colleghi della Object Technology Practice di IBM abbiamo immaginato un framework di oggetti Smalltalk che potesse essere utilizzato per comporre ed eseguire questi modelli LOVEM basati sui ruoli. Il nostro framework EBM , Executable Business Model , era basato su un "kit di costruzione" di metamodelli di classi di oggetti che assomigliava molto a questo modello di classe UML sin dalle prime attività della mia rinascita post-cancro come Citizen Scientist di Digital Humanities:

L'aspetto del nostro modello EBM che voglio evidenziare in questo articolo è il gruppo di classi visto nel riquadro rosso nell'angolo in basso a sinistra di questo diagramma. Queste tre classi - persone o agenti come attori - partecipano a processi orientati agli obiettivi e basati sui ruoli . In questo modo il nostro framework EBM ha implementato il concetto di agenzia essenziale per il metodo dei processi aziendali LOVEM. L'implementazione di Agency nel nostro metamodello è stata, come ci si potrebbe aspettare, guidata dalla nostra ispirazione Mirror Worlds .

Nel suo libro, Gelernter ha portato i lettori in un esperimento mentale che diceva, parafrasando qui: “Immagina se costruissimo simulazioni software dettagliate dei nostri sistemi complessi al lavoro nel mondo reale. Una volta che queste simulazioni sono in corso, immagina cosa accadrebbe se prendessimo tutti i feed di input e output delle nostre simulazioni e li collegassimo ai feed effettivi in ​​​​questi sistemi del mondo reale. A quel punto, i nostri modelli software smetterebbero di essere simulazioni e inizierebbero a essere display a comparsa, o visualizzazioni di dashboard, nel mondo reale…” o ciò che Gelernter chiamava Mirror Worlds .

Abbiamo implementato questo approccio all'agenzia nel nostro framework basato su metamodelli EBM in modo che gli oggetti agente potessero essere implementati come proxy software per persone come attori di ruoli in modelli LOVEM eseguibili. Questo design ci ha dato due importanti caratteristiche coerenti con la nostra ispirazione Mirror Worlds . In primo luogo, durante le sessioni di consulenza con i dirigenti dei clienti, potremmo far sedere le PMI, gli esperti in materia dei clienti, ai laptop collegati in rete in una sala conferenze per interagire e convalidare i nostri modelli di simulazione in evoluzione. Durante queste sessioni, potremmo popolare un'istanza del modello in esecuzione con proxy software agente sim-actor per eseguire tutti gli altri ruoli in un processo aziendale modellato.

Una volta che le PMI dei clienti si fossero convinte che avessimo inchiodato questi processi di business nella nostra simulazione EBM, avremmo potuto — in vero stile ispirato a Mirror Worlds — collegare semplicemente questi modelli come un sistema implementato nell'attività reale del cliente. Durante questo processo di collegamento, determiniamo quali ruoli devono essere svolti dalle persone (utilizzando viste EBM generate dinamicamente sul modello visto dagli utenti come applicazioni software tipiche) o dai ruoli che devono essere svolti dagli agenti agenti proxy del software nei clienti processi di business.

Riflettendo su quel periodo di quasi trent'anni fa, i miei giorni trascorsi a lavorare come leader di pensiero/sviluppatore in questo skunkworks EBM sono state alcune delle esperienze più esaltanti della mia carriera lavorativa.

Una speculazione lungimirante sull'agenzia nella piattaforma #HeyGitHub/Copilot

Quindi, in che modo il concetto di agenzia può contribuire a sfruttare le capacità di approcci come Chain of Thought, prompt-sequencing e model-switching come parte dello stack di tecnologie in evoluzione che contribuiscono all'implementazione del servizio #HeyGitHub/Copilot di GitHub?

Senza alcuna intenzione di rigore o esempio non banale, potremmo applicare questo concetto di agenzia basata sui ruoli dalla mia esperienza EBM alla progettazione della soluzione del servizio #HeyGitHub/Copilot come in questo semplice diagramma di corsia di nuoto:

Ciò che vediamo in questo diagramma eccessivamente semplice è un gruppo di quattro corsie di nuoto negli strati superiori che interagiscono attivamente come un essere umano e tre agenti software la cui conversazione porta all'eventuale generazione nei ruoli "stupidi"/trascrittori di dati dell'IDE app e file sorgente (memoria). Questo semplice diagramma chiarisce che l'enorme sfida che dobbiamo affrontare è come iniettare "intelligenza sherlockiana" in quella conversazione basata su agenti prima di utilizzare al meglio il nostro LLM copilota Rainman-Agent simile a un esperto.

Immagina che il nostro requisito di progettazione sia, ad esempio, la creazione di un Call Center bot Agent telefonico ad alte prestazioni. In questo caso, un repertorio flessibile di prompt basati su modelli che possono essere selezionati dinamicamente per un risultato orientato all'obiettivo potrebbe essere sufficiente per passare alla distribuzione. Ma agendo con successo come programmatore di coppia non umano (agente "amico"), come afferma spesso GitHub nel descrivere il suo servizio Copilot, l' ascoltatore #HeyGitHub e gli agenti di dialogo CoT dovranno implementare un'intelligenza molto più complessa di un bot di call center programmabile conversazione.

Prendiamo, ad esempio, la sfida per #HeyGitHub/Copilot che aiuta uno sviluppatore a creare l'interfaccia utente/UX (interfaccia utente ed esperienza interattiva) per un'applicazione. Esiste un discreto numero di eccellenti framework UI/UX che lo sviluppatore potrebbe utilizzare. Il nostro copilota Rainman-savant ha già visto innumerevoli esempi di questi framework nell'addestramento del modello di base del copilota per affinare il suo talento nella generazione di codice. Ma essere in grado di fornire utili suggerimenti di codice basati sul riconoscimento di modelli tratti dalla sua esperienza di formazione non offre a Copilot la comprensione sottostante dell'architettura del framework, delle best practice e delle linee guida di interfaccia/interazione utente che uno sviluppatore umano competente porta al ruolo di partecipante in una partnership di coppia di programmazione.

Considera l'esempio del wrapper wxPython sul venerabile framework C++ wxWidgets . Nessuna quantità di passeggiate casuali attraverso la miriade di repository di codici pubblicamente accessibili rivelerà l'estensione della conoscenza impartita facendo un tuffo nell'eccellente sito Web di documentazione online all'indirizzohttps://docs.wxpython.org/. Nessuna quantità di scomposizione della PNL, riflessione sulla modellazione degli argomenti/riepilogo sul contenuto di questo sito Web sarà sufficiente per trasmettere la conoscenza dello sviluppatore umano nella conversazione #HeyGitHub/Copilot<>Sviluppatore.

Quindi dove andiamo da qui?

Vorrei avere una conoscenza del dominio sufficiente per suggerire un percorso specifico di progettazione e sviluppo della soluzione per produrre le tecnologie necessarie per portare le prestazioni degli odierni LLM di generazione del codice a quel proverbiale "livello successivo". Sebbene la tabella di marcia completa debba ancora essere scritta, ci sono alcune ipotesi che possiamo fare sui prossimi passi. Possiamo anticipare che sarà importante per l' agente #HeyGitHub Listener essere in grado di distinguere tra gli input vocali dello sviluppatore che richiedono un trasferimento al CoT Dialoguer per un'ulteriore interazione ponderata o passati in forma testuale al Copilot LLM per generazione di suggerimenti di codice.

La difficile sfida che ci attende è incapsulare le strutture informative e il significato semantico dell'arte e della scienza dell'ingegneria del software in modo tale che CoT Dialoguer possa agire in modo credibile come un vero partner della coppia di programmazione. Le tecnologie per far fronte a questa sfida proverranno probabilmente dall'avanguardia dell'attività di ricerca sulla catena del pensiero, la selezione rapida/sequenziamento, il cambio di modello e l'apprendimento/coaching di rinforzo umano.

Alcune delle scoperte in questo spazio di soluzioni "Sherlockean smarts" comporteranno una brillante codifica innovativa da parte degli ingegneri di ricerca sull'apprendimento automatico. Credo anche, tuttavia, che un contributo non banale a questa sfida verrà dalla progettazione e dallo sviluppo di efficaci set di dati del modello di riferimento Ground Truth che serviranno come materiali curriculari di formazione per i modelli specifici del dominio per lavorare mano nella mano in un contesto di cambio di modello con il Copilot Large Language Model di base in continua evoluzione. Un esempio di questi set di dati di riferimento emergenti è il progetto Metamodel Subgraph Ground Truth Storage che ho perseguito attraverso la mia ricerca sulle discipline umanistiche digitali e ho immaginato qui nella mia serie di articoli #HeyGitHub.

Ma lo sviluppo di un formato di set di dati di riferimento Ground Truth orientato all'agente standard non sarà sufficiente per evocare i dialoghi sherlockiani che immagino tra uno sviluppatore umano e un partner di Copilot Pair Programming basato su ML. Piuttosto, questi set di dati di riferimento Ground Truth della conoscenza del dominio dovranno servire come materiale didattico in scenari interattivi utente simulati di addestramento del modello che perfezionano la capacità dell'agente CoT Dialoguer di impegnarsi in una conversazione collaborativa con il suo partner sviluppatore umano. Queste sessioni di simulazione possono comprimere il tempo e perseguire instancabilmente il perfezionamento dell'uso efficace della conoscenza del dominio da parte del Dialogatore CoT.

Proprio come ora utilizziamo le migliori pratiche di modellazione dei dati per generare set di dati di addestramento per le attuali applicazioni ML a uso intensivo di dati, allo stesso modo saremo in grado di generare esperienze di simulazione basate su agenti che consentano alle nostre applicazioni basate sulla conoscenza di addestrare e perfezionare modelli come l'immaginario futuro servizio #HeyGitHub/Copilot. Come parte di questo ambiente di addestramento simulato simile a Mirror Worlds , gli scambi di conversazione che ostacolano il modello #HeyGitHub CoT Dialoguer in formazione appariranno al Supervisore umano nel giro il cui coaching di risposta incoraggerà e rafforzerà il comportamento del modello appropriato.

Un paio di api nei cofani su GitHub e Microsoft

A questo punto i miei voli di immaginazione sulla via da seguire sono poco più che i sogni febbrili di un cittadino scienziato indipendente di discipline umanistiche e sviluppatore disabile. Ma se dovessi rispolverare il mio vecchio cappello da consulente IBM per mettere un paio di api nei cofani di GitHub e Microsoft, so cosa suggerirei...

Innanzitutto, non posso fare a meno di dire che se facessi parte della gestione di GitHub mi offrirei un lavoro come membro del team di ricerca di GitHub Next. In quella posizione lavorerei diligentemente sulle idee di cui ho scritto in questa serie di articoli #HeyGitHub * .

Successivamente, una volta che avremo la prova del concetto per i set di dati di addestramento del modello di conoscenza del dominio della verità del sottografo del metamodello, farei pressioni per dedicare una parte dell'acceleratore GitHub recentemente annunciato o del fondo GitHub M12 per fornire stipendi o finanziamenti per l'avvio di progetti a prestazioni elevate , esperti sviluppatori Open Source per creare una raccolta di questi set di dati di addestramento del modello orientati all'agente specifici del dominio. Un'enfasi particolare dovrebbe essere presa in considerazione per lo sviluppo di set di dati di addestramento basati su metamodelli specifici del framework UI/UX.

Perché i set di dati di conoscenza del dominio specifici del framework UI/UX? Perché queste "bestie" sono spesso architetture grandi e complesse con una personalizzazione eccessivamente dettagliata in termini di parametri. E per la maggior parte degli scenari di progetti di sviluppo, la creazione di un'interfaccia utente dell'applicazione e le sue interazioni con l'utente sono attività necessarie che richiedono tempo e fatica dalla codifica della soluzione allo spazio problematico del progetto che l'interfaccia utente/UX dell'applicazione mette a disposizione dell'utente finale del progetto. Fornire una forte generazione di codice del framework UI/UX tramite input vocale in #HeyGitHub/Copilot è quindi paragonabile ad avere un framework UI/UX con una potente applicazione per la creazione di interfacce WYSIWYG.

Come raccomandazione più ampia e strategica, incoraggerei i contatti di GitHub Next e Project Bonsai di Microsoft a formare un Comitato di collaborazione. Lo scopo di questo gruppo sarebbe quello di esplorare i modi in cui GitHub potrebbe sfruttare le migliori pratiche e l'esperienza dell'ampio impegno che Microsoft ha profuso nei mercati dell'automazione dei processi robotici e industriali.

E, si spera, in agguato appena oltre l'orizzonte

Guardando ancora più in basso lungo l'autostrada dell'innovazione mentre indosso i miei occhiali color rosa e la maglietta con lo slogan ottimista, dove potrebbe portare questo programma di ricerca? Se, dopo aver creato un numero limitato di set di dati Ground Truth di riferimento del sottografo del metamodello specifici del dominio e aver impiegato il tempo e gli sforzi per addestrare un modello di Machine Learning per svolgere il ruolo di agente CoT Dialoguer in una serie di domini, un giorno potremmo vedere il sistema Dialoguer dimostrare un comportamento emergente .

Con questo intendo dire che il modello CoT Dialoguer Agent può comprendere la struttura generalizzata e l'uso della conoscenza del dominio così bene da non dover essere precaricato con un nuovo modello di riferimento specifico del dominio per diventare utile nella partecipazione a un nuovo contesto. A questo livello di funzionamento, il futuro sistema multi-modello #HeyGitHub/Copilot può semplicemente impegnarsi in una conversazione di apprendimento autodiretta con il suo partner di programmazione della coppia di sviluppatori per creare e convalidare il proprio nuovo modello di conoscenza del dominio. Attraverso questo processo il servizio #HeyGitHub/Copilot può diventare un collaboratore a livello di pari davvero versatile nella progettazione e nello sviluppo di sistemi software essenziali.

In chiusura

Dopo essere sopravvissuto alla mia battaglia contro il cancro e aver imparato ad affrontare le sfide di destrezza e mobilità della mia lesione del midollo spinale, non mi piacerebbe altro che avere la possibilità di battere il mietitore contribuendo all'entusiasmante ondata di notevoli innovazioni nel design e nello sviluppo di software come previsto nella mia serie di articoli #HeyGitHub. ✌️

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

* PS Per essere chiari, oltre al mio interesse a perseguire l'agenda di ricerca prevista in questa serie di articoli di #HeyGitHub, resto appassionatamente impegnato nell'implementazione dell'agenda di Copilot come #AssistiveTechnology attraverso lo studio di ricerca e il programma di supporto per #DisabledDevelopers e # Studenti STEM disabili descritti nella maggior parte degli articoli in questa pubblicazione Medium.

Jim Salmons è un cittadino scienziato di Digital Humanities post-cancro di settantun anni. La sua ricerca principale è incentrata sullo sviluppo di un formato Ground Truth Storage che fornisca una struttura di documenti complessa integrata e un modello di rappresentazione del contenuto per lo studio di raccolte digitalizzate di riviste e giornali dell'era della stampa. Una caduta in casa nel luglio 2020 ha provocato una grave lesione del midollo spinale che ha compromesso drasticamente la sua destrezza manuale e mobilità.

Jim è stato fortunato a ricevere l'accesso alla community di GitHub Copilot Technology Early Access durante i suoi sforzi iniziali per tornare a lavorare sulle attività di sviluppo di strumenti basati su Python del suo principale interesse di ricerca. Dopo aver sperimentato il notevole impatto positivo di GitHub Copilot sulla propria produttività di sviluppo, si è appassionato alla progettazione di un programma di ricerca e supporto per indagare e documentare l'uso di questa innovativa tecnologia di assistenza alla programmazione per l'utilizzo da parte di sviluppatori disabili.