“¡HeyGitHub!”, Reflexiones sobre la agencia y el copiloto conversacional

En mis últimos dos artículos más técnicos para esta publicación, me dejé llevar por una visión bastante libre de agregar el pensamiento deductivo "sherlockeano" al diálogo de codificación de voz #HeyGitHub entre #DisabledDevelopers y el brillante pero sabio "Rainman" GitHub Generador de código de copiloto. Mientras escribía estos artículos, comencé una búsqueda de métodos e implementaciones disponibles públicamente de avances en la comunidad de investigación de Machine-Learning que podrían proporcionar el tipo de apoyo necesario para implementar estas conversaciones de generación de código más reflexivas.

Afortunadamente, descubrí que hay varias subcomunidades de investigación de aprendizaje automático que trabajan en estos desafíos para respaldar procesos de pensamiento más "similares a los humanos", utilizando el contexto y el conocimiento previo, como complemento al reconocimiento de patrones de fuerza bruta de LLM ( Modelo de lenguaje grande ) rendimiento. Aprendí sobre #CoT ( Cadena de pensamiento ), secuenciación rápida , cambio de modelo y agentes , entre otras áreas de exploración y desarrollo en el dominio del aprendizaje automático. Estoy empezando a obtener experiencia de primera mano usando la emocionante biblioteca LangChain Python de Harrison Chase y LangChainAI.desarrolladores Muchos de estos rastros de migas de pan que seguí comenzaron con la lectura del perspicaz artículo de descripción general, "El futuro cercano de la IA está impulsado por la acción" , de John McDonnell .

También aprendí sobre una agenda masiva e hiperfinanciada en curso en Microsoft, Project Bonsai , que está brindando soluciones de IA/ML a los desafíos de la automatización robótica y el control de procesos industriales. En este espacio de problemas del mundo físico, la simulación y el entrenamiento humano en el circuito son tan importantes, si no más, como el énfasis en el modelado de datos y los métodos de ciencia de datos en el dominio de aplicación de aprendizaje automático más general.

Mi objetivo en este artículo no es ahondar más en estos avances de SOTA, sino más bien especular un poco sobre el papel de la agencia basada en roles, ya que puede aplicarse a la plataforma #HeyGitHub/Copilot en apoyo del desarrollo de software no solo por #DisabledDevelopers y #DisabledSTEMstudents , pero por todos los posibles desarrolladores que usan #HeyGitHub/Copilot como un multiplicador de productividad de desarrollo.

Una reflexión de Wayback sobre la agencia en modelos comerciales ejecutables

En mi artículo de Metamodel Subgraph en esta serie #HeyGitHub , brindé una breve descripción de mi participación en un skunkworks que desarrolla un marco basado en Smalltalk que admite la composición dinámica y la generación de aplicaciones de EBM , modelos de negocios ejecutables .

A principios y mediados de la década de 1990 se vio una variedad de métodos basados ​​en modelos tanto para el desarrollo de software como para la ingeniería de procesos comerciales. Un hilo fuerte en esta era fue el movimiento BPR , o Reingeniería de Procesos de Negocios . Dentro de los servicios de consultoría de IBM, un método popular utilizado en ese momento se llamaba LOVEM , el modelo empresarial de línea de visibilidad o, a veces, el método de ingeniería de línea de visibilidad . El elemento central de este método era un formato de diagrama que usaba "carriles de natación" para los modelos de procesos comerciales.

Los carriles de natación de LOVEM representaban roles que podían ser desempeñados por humanos o máquinas (procesos de software AKA). Inspirado en el libro de David Gelernter de 1993, "Mirror Worlds: or the Day Software Puts the Universe in a Shoebox...How It Will Happen and What It Will Mean". , mis colegas y yo en la práctica de tecnología de objetos de IBM imaginamos un marco de objetos de Smalltalk que podría usarse para componer y ejecutar estos modelos LOVEM basados ​​en roles. Nuestro marco EBM , modelo de negocio ejecutable , se basó en un "kit de construcción" de metamodelo de clases de objetos que se parecía mucho a este modelo de clase UML de actividad temprana en mi renacimiento poscáncer como científico ciudadano de humanidades digitales:

El aspecto de nuestro modelo EBM que quiero resaltar en este artículo es el grupo de clases que se ve en el cuadro rojo en la esquina inferior izquierda de este diagrama. Estas tres clases, Personas o Agentes como Actores , participan en procesos basados ​​en roles y dirigidos por objetivos . De esta forma, nuestro marco EBM implementó el concepto de Agencia esencial para el método de proceso de negocio LOVEM. La implementación de Agency en nuestro metamodelo fue, como era de esperar, impulsada por nuestra inspiración de Mirror Worlds .

En su libro, Gelernter llevó a los lectores a un experimento mental que decía, parafraseando aquí: “Imagínese si construyéramos simulaciones de software detalladas de nuestros sistemas complejos en funcionamiento en el mundo real. Una vez que tengamos estas simulaciones funcionando, imagine lo que sucedería si tomáramos todas las fuentes de entrada y salida de nuestras simulaciones y las conectáramos a las fuentes reales en estos sistemas del mundo real. En ese momento, nuestros modelos de software dejarían de ser simulaciones y comenzarían a ser pantallas de visualización frontal, o vistas de tablero, en el mundo real…” o lo que Gelernter llamó Mirror Worlds .

Implementamos este enfoque de Agencia en nuestro marco basado en metamodelo EBM para que los objetos Agente pudieran implementarse como proxies de software para Personas como Actores de Roles en modelos LOVEM ejecutables. Este diseño nos dio dos características importantes consistentes con nuestra inspiración de Mirror Worlds . En primer lugar, durante las sesiones de compromiso de consultoría con los ejecutivos de los clientes, podríamos hacer que las pymes, los expertos en la materia de los clientes, se sentaran frente a computadoras portátiles conectadas en red en una sala de conferencias para interactuar y validar nuestros modelos de simulación en evolución. Durante estas sesiones, podríamos llenar una instancia de modelo en ejecución con proxies de software de agente sim-actor para realizar todos los demás roles en un proceso de negocio modelado.

Una vez que las pymes de los clientes se convencieron de que habíamos acertado estos procesos comerciales en nuestra simulación EBM, pudimos, al más puro estilo inspirado en Mirror Worlds , simplemente conectar estos modelos como un sistema implementado en el negocio real del cliente. Durante este proceso de conexión, determinaríamos qué roles debían desempeñar las personas, utilizando vistas de EBM generadas dinámicamente en el modelo visto por los usuarios como aplicaciones de software típicas, o qué roles debían desempeñar los agentes de proxy de software en los clientes. Procesos de negocios.

Reflexionando sobre esa época hace casi treinta años, los días que pasé trabajando como líder intelectual/desarrollador en este skunkworks de EBM fueron algunas de las experiencias más emocionantes de mi carrera laboral.

Una especulación prospectiva sobre la agencia en la plataforma #HeyGitHub/Copilot

Entonces, ¿cómo podría contribuir el concepto de Agencia a que aprovechemos las capacidades de enfoques como Cadena de pensamiento, secuenciación rápida y cambio de modelo como parte de la pila en evolución de tecnologías que contribuyen a la implementación del servicio #HeyGitHub/Copilot de GitHub?

Sin intención de rigor o ejemplo no trivial, podríamos aplicar este concepto de agencia basada en roles de mi experiencia en EBM al diseño de la solución del servicio #HeyGitHub/Copilot como en este diagrama de carril simple:

Lo que vemos en este diagrama demasiado simple es un grupo de cuatro carriles de natación en las capas superiores que interactúan activamente como un ser humano y tres agentes de software cuya conversación conduce a la generación final en los roles "tontos"/tipo transcriptor de datos del IDE. aplicación y archivo fuente (memoria). Este diagrama simple deja en claro que el tremendo desafío que tenemos en el futuro es cómo inyectar "inteligencia sherlockeana" en esa conversación basada en agentes antes de hacer el mejor uso de nuestro Rainman-Agent Copilot LLM.

Imagine que nuestro requisito de diseño es, por ejemplo, crear un agente bot de Call Center telefónico de alto rendimiento. En este caso, un repertorio flexible de avisos basados ​​en plantillas que se pueden seleccionar dinámicamente para un resultado orientado a objetivos podría ser suficiente para pasar a la implementación. Pero al actuar con éxito como un programador de pares no humano ("amigo" del agente), como GitHub suele afirmar al describir su servicio Copilot, los agentes #HeyGitHub Listener y CoT Dialoguer necesitarán implementar una inteligencia mucho más compleja que un bot programable de Call Center. conversacion.

Tomemos, por ejemplo, el desafío de #HeyGitHub/Copilot ayudando a un desarrollador a crear la UI/UX (interfaz de usuario y experiencia interactiva) para una aplicación. Hay una cantidad decente de excelentes marcos de UI/UX que el desarrollador podría usar. Nuestro Rainman-savant Copilot ya ha visto innumerables ejemplos de estos marcos en la capacitación del modelo básico de Copilot para refinar su talento de generación de código. Pero ser capaz de proporcionar sugerencias de código útiles basadas en el reconocimiento de patrones extraídas de su experiencia de capacitación no le brinda a Copilot la comprensión subyacente de la arquitectura del marco, las mejores prácticas y las pautas de interacción/interfaz de usuario que un desarrollador humano competente aporta al rol de participante. en una asociación de Par de Programación.

Considere el ejemplo del envoltorio wxPython en el venerable marco wxWidgets de C++. Ninguna cantidad de caminatas aleatorias a través de la miríada de repositorios de códigos de acceso público revelará el alcance del conocimiento impartido al sumergirse profundamente en el excelente sitio web de documentación en línea enhttps://docs.wxpython.org/. Ninguna cantidad de descomposición de NLP, modelado de temas/rumia de resumen en el contenido de este sitio web será suficiente para impartir el conocimiento del desarrollador humano en la conversación #HeyGitHub/Copilot<>Developer.

¿Entonces, dónde vamos desde aquí?

Desearía tener suficiente conocimiento del dominio para sugerir un diseño de solución específico y una ruta de desarrollo para producir las tecnologías necesarias para llevar el rendimiento de los LLM de generación de código actuales a ese proverbial "siguiente nivel". Si bien aún no se ha escrito la hoja de ruta completa, hay algunas suposiciones que podemos hacer sobre los próximos pasos. Podemos anticipar que será importante que el agente de escucha #HeyGitHub pueda distinguir entre las entradas de voz del desarrollador que requieren una transferencia al CoT Dialoguer para una interacción más reflexiva, o que se transmiten en forma de texto al Copilot LLM para generación de sugerencias de código.

El reto retorcido que tenemos por delante es encapsular las estructuras de información y el significado semántico del arte y la ciencia de la ingeniería de software de tal manera que CoT Dialoguer pueda funcionar de manera creíble como un verdadero socio de programación. Las tecnologías para enfrentar este desafío probablemente provendrán de la vanguardia de la actividad de investigación en torno a Chain of Thought, selección/secuenciación rápida, cambio de modelo y aprendizaje/entrenamiento de refuerzo humano en el ciclo.

Algunos de los avances en este espacio de soluciones de "inteligencia sherlockeana" implicarán una codificación innovadora y brillante por parte de los ingenieros de investigación de Machine Learning. Sin embargo, también creo que una contribución no trivial a este desafío provendrá del diseño y desarrollo de conjuntos de datos de modelos de referencia Ground Truth efectivos que servirán como materiales curriculares de capacitación para que los modelos específicos de dominio funcionen de la mano en un contexto de cambio de modelo con el Copilot Large Language Model fundacional en constante evolución. Un ejemplo de estos conjuntos de datos de referencia emergentes es el diseño Metamodel Subgraph Ground Truth Storage que he estado siguiendo a través de mi investigación de Humanidades digitales y que visualicé aquí en mi serie de artículos #HeyGitHub.

Pero desarrollar un formato de conjunto de datos de referencia Ground Truth estándar orientado al agente no será suficiente para evocar los diálogos Sherlockean que visualizo entre un desarrollador humano y un socio de programación de pares de copilotos basado en ML. Más bien, estos conjuntos de datos de referencia de Ground Truth del conocimiento del dominio deberán servir como material instructivo en escenarios interactivos de usuario simulados de entrenamiento de modelos que refinan la capacidad del agente CoT Dialoguer para entablar una conversación colaborativa con su socio desarrollador humano. Estas sesiones de simulación pueden comprimirse en el tiempo y perseguir incansablemente el perfeccionamiento del uso eficaz del conocimiento del dominio por parte de CoT Dialoguer.

Así como ahora usamos las mejores prácticas de modelado de datos para generar conjuntos de datos de entrenamiento para las aplicaciones ML actuales con uso intensivo de datos, también podremos generar experiencias de simulación basadas en agentes que permitan que nuestras aplicaciones basadas en el conocimiento entrenen y refinen modelos como los imaginados. futuro servicio #HeyGitHub/Copilot. Como parte de este entorno de entrenamiento de simulación similar a Mirror Worlds , los intercambios conversacionales que obstaculizan el modelo #HeyGitHub CoT Dialoguer en entrenamiento aparecerán para el supervisor humano en el circuito cuyo entrenamiento de respuesta alentará y reforzará el comportamiento del modelo apropiado.

Un par de abejas en los capós en GitHub y Microsoft

En este punto, mis vuelos de imaginar el camino a seguir son poco más que los sueños febriles de un científico ciudadano independiente de humanidades digitales y desarrollador discapacitado. Pero si tuviera que desempolvar mi viejo sombrero de consultor de IBM para poner un par de abejas en el capó de GitHub y Microsoft, sé lo que sugeriría...

Primero, no puedo evitar decir que si fuera parte de la administración de GitHub, me ofrecería un trabajo como miembro del equipo de investigación de GitHub Next. En ese puesto, trabajaría diligentemente en las ideas sobre las que he escrito en esta serie de artículos de #HeyGitHub * .

A continuación, una vez que tengamos la prueba de concepto para los conjuntos de datos de capacitación del modelo de conocimiento del dominio Subgraph Ground Truth de Metamodel, cabildearía para dedicar una parte del Acelerador GitHub recientemente anunciado o el Fondo GitHub M12 para proporcionar estipendios o financiamiento de inicio de proyectos para proyectos de alto rendimiento. , desarrolladores expertos de código abierto para crear una colección de estos conjuntos de datos de entrenamiento de modelos orientados a agentes específicos de dominio. Se debe considerar un énfasis particular para desarrollar conjuntos de datos de entrenamiento basados ​​en metamodelos específicos del marco UI/UX.

¿Por qué conjuntos de datos de conocimiento de dominio específicos del marco de UI/UX? Porque estas “bestias” suelen ser arquitecturas grandes y complejas con una personalización excesivamente detallada en cuanto a parámetros. Y para la mayoría de los escenarios de proyectos de desarrollo, la creación de una interfaz de usuario de la aplicación y sus interacciones con el usuario son actividades necesarias que requieren tiempo y esfuerzo para codificar la solución al espacio del problema del proyecto que la aplicación UI/UX simple pone a disposición del usuario final del proyecto. Proporcionar una sólida generación de código de marco de UI/UX mediante la entrada de voz en #HeyGitHub/Copilot es entonces comparable a tener un marco de UI/UX con una potente aplicación de creación de interfaz WYSIWYG.

Como una recomendación estratégica y de mayor alcance, alentaría a los contactos de pensamiento líder de GitHub Next y Project Bonsai de Microsoft a formar un Comité de colaboración. El propósito de este grupo sería explorar formas en que GitHub podría aprovechar las mejores prácticas y la experiencia del amplio compromiso que Microsoft ha puesto en los mercados de automatización de procesos industriales y robóticos.

Y con suerte al acecho justo sobre el horizonte

Mirando aún más allá en la Autopista de la Innovación mientras me pongo mis anteojos de color rosa y mi camiseta con un eslogan optimista, ¿adónde podría conducir esta agenda de investigación? Si, después de crear una cantidad limitada de conjuntos de datos Ground Truth de referencia de Metamodel Subgraph específicos de dominio, y tomarse el tiempo y el esfuerzo para entrenar un modelo de aprendizaje automático para que desempeñe el rol de agente de CoT Dialoguer en una cantidad de dominios, es posible que algún día veamos el sistema Dialoguer demostrar un comportamiento emergente .

Con esto quiero decir que el modelo CoT Dialoguer Agent puede comprender la estructura generalizada y el uso del conocimiento del dominio tan bien que no tiene que estar precargado con un nuevo modelo de referencia específico del dominio para que sea útil para participar en un nuevo contexto. En este nivel de función, el sistema multimodelo #HeyGitHub/Copilot del futuro lejano puede simplemente entablar una conversación de aprendizaje autodirigido con su socio de programación de pares de desarrolladores para crear y validar su propio nuevo modelo de conocimiento de dominio. A través de este proceso, el servicio #HeyGitHub/Copilot puede convertirse en un colaborador de nivel par verdaderamente versátil en el diseño y desarrollo de sistemas de software esenciales.

Para concluir

Después de sobrevivir a mi batalla contra el cáncer y aprender a hacer frente a los desafíos de destreza y movilidad de mi lesión en la médula espinal, nada me gustaría más que tener la oportunidad de vencer al segador contribuyendo a la emocionante ola venidera de notables innovaciones en el diseño y desarrollo. de software tal como lo imaginé en mi serie de artículos #HeyGitHub. ✌️

Happy Healthy Vibes de Colorado, EE. UU.,
-: Jim :-

* PD Para ser claros, además de mi interés en seguir la agenda de investigación prevista en esta serie de artículos de #HeyGitHub, sigo apasionadamente comprometido con la implementación de la agenda de Copilot como #AssistiveTechnology a través del estudio de investigación y el programa de apoyo para #DisabledDevelopers y # Estudiantes STEM discapacitados descritos en la mayor parte de los artículos de esta publicación de Medium.

Jim Salmons es un ciudadano científico de humanidades digitales poscáncer de setenta y un años. Su investigación principal se centra en el desarrollo de un formato Ground Truth Storage que proporciona una estructura de documento compleja integrada y un modelo de representación de contenido para el estudio de colecciones digitalizadas de revistas y periódicos de la era impresa. Una caída en su casa en julio de 2020 resultó en una lesión grave en la médula espinal que ha comprometido drásticamente su destreza manual y movilidad.

Jim tuvo la suerte de tener acceso a la comunidad de acceso anticipado de GitHub Copilot Technology durante sus esfuerzos iniciales para volver a trabajar en las actividades de desarrollo de herramientas basadas en Python de su principal interés de investigación. Al experimentar el impacto positivo dramático de GitHub Copilot en su propia productividad de desarrollo, se interesó apasionadamente en diseñar un programa de investigación y soporte para investigar y documentar el uso de esta innovadora tecnología de asistencia de programación para el uso de desarrolladores discapacitados.