“HeyGitHub!”, Reflexões sobre Agência e Copiloto Conversacional

Em meus dois últimos artigos mais técnicos para esta publicação, eu me permiti uma visão bastante livre de adicionar o pensamento dedutivo “Sherlockeano” ao diálogo de codificação de voz #HeyGitHub entre #DisabledDevelopers e o brilhante, mas sábio “Rainman” GitHub Gerador de código copiloto. Enquanto escrevia esses artigos, comecei uma busca por métodos e implementações publicamente disponíveis de avanços na comunidade de pesquisa de aprendizado de máquina que poderiam fornecer o tipo de suporte necessário para implementar essas conversas de geração de código mais ponderadas.

Felizmente, descobri que existem várias subcomunidades de pesquisa de aprendizado de máquina trabalhando nesses desafios para apoiar processos de pensamento mais “semelhantes aos humanos”, usando contexto e conhecimento prévio, como complemento ao reconhecimento de padrões de força bruta do LLM ( Modelo de linguagem grande ) desempenho. Aprendi sobre #CoT ( Chain of Thought ), prompt-sequencing , model-switching e agentes entre outras áreas de exploração e desenvolvimento no domínio de Machine-Learning. Estou começando a ter experiência em primeira mão usando a empolgante biblioteca LangChain Python de Harrison Chase e a LangChainAIdesenvolvedores. Muitas dessas trilhas de navegação que segui começaram com a leitura do perspicaz artigo de visão geral, “The Near Future of AI is Action-Driven” , de John McDonnell .

Também aprendi sobre uma agenda massiva e hiperfinanciada em andamento na Microsoft - o Projeto Bonsai - que está trazendo soluções de IA/ML para os desafios da automação robótica e controle de processos industriais. Nesse espaço de problemas do mundo físico, a simulação e o treinamento humano no loop são tão importantes, se não mais, quanto a ênfase na modelagem de dados e nos métodos de ciência de dados no domínio de aplicativo de aprendizado de máquina mais geral.

Meu foco neste artigo não é aprofundar esses avanços SOTA, mas sim especular um pouco sobre o papel da agência baseada em função, pois pode ser aplicada à plataforma #HeyGitHub/Copilot em suporte ao desenvolvimento de software não apenas por #DisabledDevelopers e #DisabledSTEMstudents , mas por todos os desenvolvedores em potencial usando #HeyGitHub/Copilot como um multiplicador de produtividade de desenvolvimento.

Uma reflexão retrógrada sobre agência em modelos de negócios executáveis

No meu artigo Metamodel Subgraph nesta série #HeyGitHub , dei uma breve visão geral do meu envolvimento em um skunkworks desenvolvendo uma estrutura baseada em Smalltalk que oferece suporte à composição dinâmica e geração de aplicativos de EBMs , Executable Business Models .

No início da década de 1990, houve uma variedade de métodos orientados a modelos para desenvolvimento de software e engenharia de processos de negócios. Um fio condutor forte nessa época foi o movimento BPR , ou Business Process Reengineering . Dentro dos serviços de consultoria da IBM, um método popular usado na época era chamado LOVEM , Line Of Visibility Enterprise Model ou, às vezes, Line Of Visibility Engineering Method . Central para este método foi um formato de diagrama usando “pistas de natação” para modelos de processos de negócios.

As raias de natação do LOVEM representavam papéis que poderiam ser desempenhados por humanos ou máquinas (processos de software AKA). Inspirado no livro 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.” , meus colegas e eu da IBM's Object Technology Practice imaginamos uma estrutura de objeto Smalltalk que poderia ser usada para compor e executar esses modelos LOVEM baseados em função. Nossa estrutura EBM , Modelo de Negócios Executável , foi baseada em um metamodelo "kit de construção" de classes de objetos que se parecia muito com este modelo de classe UML desde as primeiras atividades em meu renascimento pós-câncer como Cientista Cidadão de Humanidades Digitais:

O aspecto do nosso modelo EBM que quero destacar neste artigo é o agrupamento de classes visto na caixa vermelha no canto inferior esquerdo deste diagrama. Essas três classes — Pessoas ou Agentes como Atores — participam de processos orientados por objetivos e baseados em funções . Desta forma, nossa estrutura EBM implementou o conceito de agência essencial para o método de processo de negócios LOVEM. A implementação da Agência em nosso metamodelo foi, como você pode esperar, impulsionada por nossa inspiração de Mirror Worlds .

Em seu livro, Gelernter levou os leitores a um experimento mental que dizia, parafraseando aqui: “Imagine se construíssemos simulações de software detalhadas de nossos sistemas complexos em funcionamento no mundo real. Assim que tivermos essas simulações funcionando, imagine o que aconteceria se pegássemos todos os feeds de entrada e saída de nossas simulações e os conectássemos aos feeds reais desses sistemas do mundo real. Nesse ponto, nossos modelos de software deixariam de ser simulações e começariam a ser exibições heads-up, ou exibições de painel, no mundo real…” ou o que Gelernter chamou de Mirror Worlds .

Implementamos essa abordagem para a Agência em nossa estrutura baseada em metamodelo EBM para que os objetos do Agente pudessem ser implementados como proxies de software para Pessoas como Atores de Papéis em modelos LOVEM executáveis. Este design nos deu duas características importantes consistentes com nossa inspiração Mirror Worlds . Primeiro, durante as sessões de consultoria com executivos de clientes, poderíamos ter SMEs, especialistas no assunto dos clientes, sentados em laptops conectados em rede em uma sala de conferência para interagir e validar nossos modelos de simulação em evolução. Durante essas sessões, poderíamos preencher uma instância de modelo em execução com proxies de software do agente sim-actor para executar todas as outras funções em um processo de negócios modelado.

Uma vez que as PMEs dos clientes estivessem convencidas de que havíamos acertado esses processos de negócios em nossa simulação de EBM, poderíamos — na verdadeira moda inspirada em Mirror Worlds — simplesmente conectar esses modelos como um sistema implantado no negócio real do cliente. Durante esse processo de conexão, determinaríamos quais Papéis seriam desempenhados por Pessoas - usando visualizações EBM geradas dinamicamente no modelo visto pelos usuários como aplicativos de software típicos - ou por Papéis a serem desempenhados por agentes de proxy de software nos clientes processos de negócios.

Refletindo sobre aquela época há quase trinta anos, meus dias trabalhando como um líder de pensamento/desenvolvedor nesta EBM skunkworks foram algumas das experiências mais estimulantes em minha carreira profissional.

Uma especulação prospectiva sobre agência na plataforma #HeyGitHub/Copilot

Então, como o conceito de Agência pode contribuir para alavancar os recursos de abordagens como Chain of Thought, prompt-sequencing e model-switching como parte da evolução da pilha de tecnologias que contribuem para a implementação do serviço #HeyGitHub/Copilot do GitHub?

Sem intenção de rigor ou exemplo não trivial, podemos aplicar este conceito de agência baseada em função da minha experiência com EBM ao design da solução do serviço #HeyGitHub/Copilot como neste diagrama simples de raia:

O que vemos neste diagrama excessivamente simples é um agrupamento de quatro raias de natação nas camadas superiores que interagem ativamente como um Humano e três Agentes de software cuja conversa leva à geração eventual nos Papéis “burros”/do tipo transcritor de dados do IDE app e arquivo de origem (memória). Este diagrama simples deixa claro que o tremendo desafio que temos daqui para frente é como injetar “inteligência sherlockiana” naquela conversa baseada em agente antes de fazer o melhor uso de nosso Rainman-Agent Copilot LLM savant.

Imagine que nosso requisito de design seja, por exemplo, a criação de um agente de bot de call center de alto funcionamento. Nesse caso, um repertório flexível de prompts baseados em modelos que podem ser selecionados dinamicamente para um resultado orientado a um objetivo pode ser suficiente para ir para a implantação. Mas atuando com sucesso como um Pair Programmer não-humano (Agent “amigo”), como o GitHub frequentemente afirma ao descrever seu serviço Copilot, o #HeyGitHub Listener e CoT Dialoguer Os agentes precisarão implementar uma inteligência muito mais complexa do que um bot de Call Center programável conversação.

Vejamos, por exemplo, o desafio do #HeyGitHub/Copilot ajudando um desenvolvedor a criar a UI/UX — interface do usuário e experiência interativa — para um aplicativo. Há um número decente de excelentes estruturas de UI/UX que o desenvolvedor pode usar. Nosso Rainman-savant Copilot já viu inúmeros exemplos dessas estruturas no treinamento do modelo básico do Copilot para refinar seu talento de geração de código. Mas ser capaz de fornecer sugestões de código com base no reconhecimento de padrões extraídos de sua experiência de treinamento não oferece ao Copilot a compreensão subjacente da arquitetura da estrutura, das melhores práticas e das diretrizes de interface/interação do usuário que um desenvolvedor humano competente traz para o papel de participante em uma parceria de Par de Programação.

Considere o exemplo do wrapper wxPython na venerável estrutura C++ wxWidgets . Nenhuma quantidade de passeios aleatórios através da miríade de repositórios de código acessíveis ao público revelará a extensão do conhecimento transmitido ao mergulhar profundamente no excelente site de documentação on-line emhttps://docs.wxpython.org/. Nenhuma quantidade de decomposição de NLP, ruminação de modelagem de tópico/soma no conteúdo deste site será suficiente para transmitir conhecimento humano-desenvolvedor na conversa #HeyGitHub/Copilot<>Developer.

Então, para onde vamos a partir daqui?

Eu gostaria de ter conhecimento de domínio suficiente para sugerir um projeto de solução específico e um caminho de desenvolvimento para produzir as tecnologias necessárias para levar o desempenho dos LLMs de geração de código de hoje para o proverbial “próximo nível”. Embora o roteiro completo ainda não tenha sido escrito, há algumas suposições que podemos fazer sobre os próximos passos. Podemos antecipar que será importante para o agente #HeyGitHub Listener ser capaz de distinguir entre as entradas de voz do desenvolvedor que exigem uma transferência para o CoT Dialoguer para uma interação mais ponderada ou transmitidas em forma de texto para o Copilot LLM para geração de sugestões de código.

O grande desafio que temos pela frente é encapsular as estruturas de informação e o significado semântico da arte e da ciência da engenharia de software de forma que o CoT Dialoguer possa atuar com credibilidade como um verdadeiro parceiro de Par de Programação. As tecnologias para enfrentar esse desafio provavelmente virão da vanguarda da atividade de pesquisa em torno da Cadeia de Pensamento, seleção/sequenciamento imediato, troca de modelo e aprendizado/treinamento de reforço humano-in-the-loop.

Algumas das inovações neste espaço de solução de “inteligência sherlockiana” envolverão codificação inovadora e brilhante por engenheiros de pesquisa de aprendizado de máquina. Também acredito, no entanto, que uma contribuição não trivial para esse desafio virá do design e desenvolvimento de conjuntos de dados de modelo de referência Ground Truth eficazes que servirão como materiais curriculares de treinamento para modelos específicos de domínio para trabalhar lado a lado em um contexto de troca de modelos com o Copilot Large Language Model fundamental em constante evolução. Um exemplo desses conjuntos de dados de referência emergentes é o design Metamodel Subgraph Ground Truth Storage que tenho buscado por meio de minha pesquisa em Humanidades Digitais e visualizado aqui em minha série de artigos #HeyGitHub.

Mas o desenvolvimento de um formato padrão de conjunto de dados de referência Ground Truth orientado a agente não será suficiente para evocar os diálogos sherlockeanos que imagino entre um desenvolvedor humano e um parceiro de programação em pares de copilotos baseado em ML. Em vez disso, esses conjuntos de dados de referência do conhecimento do domínio do Ground Truth precisarão servir como material instrucional em cenários interativos de usuário simulados de treinamento de modelo que refinam a capacidade do agente CoT Dialoguer de se envolver em conversas colaborativas com seu parceiro desenvolvedor humano. Essas sessões de simulação podem reduzir o tempo e buscar incansavelmente o refinamento do uso efetivo do conhecimento do domínio pelo CoT Dialoguer.

Assim como agora usamos as melhores práticas de modelagem de dados para gerar conjuntos de dados de treinamento para aplicativos de ML atuais com uso intensivo de dados, também seremos capazes de gerar experiências de simulação baseadas em agentes que permitem que nossos aplicativos orientados ao conhecimento treinem e refinem modelos como o imaginado futuro serviço #HeyGitHub/Copilot. Como parte deste ambiente de treinamento de simulação semelhante ao Mirror Worlds , as trocas de conversação que bloqueiam o modelo #HeyGitHub CoT Dialoguer em treinamento aparecerão para o Supervisor humano-in-the-loop cujo treinamento de resposta incentivará e reforçará o comportamento do modelo apropriado.

Algumas Abelhas nos Bonnets no GitHub e na Microsoft

Neste ponto, meus voos de imaginar o caminho a seguir são pouco mais do que os sonhos febris de um Cientista Cidadão de Humanidades Digitais independente e Desenvolvedor Deficiente. Mas se eu tirasse o pó do meu velho chapéu de consultor da IBM para colocar algumas abelhas nos gorros do GitHub e da Microsoft, sei o que sugeriria…

Em primeiro lugar, não posso deixar de dizer que, se eu fizesse parte do gerenciamento do GitHub, me ofereceria um emprego como membro da equipe de pesquisa do GitHub Next. Nessa posição, eu trabalharia diligentemente nas ideias sobre as quais escrevi nesta série de artigos #HeyGitHub * .

Em seguida, assim que tivermos a prova de conceito para os conjuntos de dados de treinamento de modelo de conhecimento do domínio Metamodel Subgraph Ground Truth, eu faria lobby para dedicar uma parte do recém-anunciado GitHub Accelerator ou do M12 GitHub Fund para fornecer estipêndios ou financiamento inicial de projetos para alto desempenho , desenvolvedores especialistas de código aberto para criar uma coleção desses conjuntos de dados de treinamento de modelo orientados a agentes específicos de domínio. Uma ênfase particular deve ser considerada para o desenvolvimento de conjuntos de dados de treinamento baseados em metamodelos específicos da estrutura de UI/UX.

Por que conjuntos de dados de conhecimento de domínio específicos da estrutura de UI/UX? Porque essas “bestas” geralmente são arquiteturas grandes e complexas com personalização excessivamente detalhada em termos de parâmetros. E para a maioria dos cenários de projeto de desenvolvimento, criar uma interface do usuário do aplicativo e suas interações com o usuário são atividades necessárias que consomem tempo e esforço da codificação da solução para o espaço do problema do projeto que a interface do usuário/UX simples do aplicativo disponibiliza para o usuário final do projeto. Fornecer forte geração de código de estrutura de UI/UX por entrada de voz em #HeyGitHub/Copilot é então comparável a ter uma estrutura de UI/UX com um poderoso aplicativo construtor de interface WYSIWYG.

Como uma recomendação mais abrangente e estratégica, eu encorajaria os contatos líderes de opinião do GitHub Next e do Projeto Bonsai da Microsoft a formar um Comitê de Colaboração. O objetivo desse grupo seria explorar maneiras pelas quais o GitHub poderia aproveitar as melhores práticas e a experiência do amplo compromisso que a Microsoft colocou nos mercados de automação robótica e de processos industriais.

E esperançosamente à espreita além do horizonte

Olhando ainda mais adiante na Rodovia da Inovação enquanto coloco meus óculos cor-de-rosa e minha camiseta com slogan otimista, aonde essa agenda de pesquisa pode levar? Se, depois de criar um número limitado de conjuntos de dados Ground Truth de referência de metamodelo específicos de domínio e dedicar tempo e esforço para treinar um modelo de aprendizado de máquina para desempenhar o papel de agente CoT Dialoguer em vários domínios, poderemos um dia ver o sistema Dialoguer demonstrar comportamento emergente .

Com isso, quero dizer que o modelo CoT Dialoguer Agent pode entender a estrutura generalizada e o uso do conhecimento do domínio tão bem que não precisa ser pré-carregado com um novo modelo de referência específico do domínio para se tornar útil na participação em um novo contexto. Nesse nível de função, o sistema multimodelo #HeyGitHub/Copilot do futuro distante pode simplesmente se envolver em uma conversa de aprendizado autodirigida com seu parceiro de programação de pares de desenvolvedores para criar e validar seu próprio novo modelo de conhecimento de domínio. Por meio desse processo, o serviço #HeyGitHub/Copilot pode se tornar um colaborador verdadeiramente versátil em nível de pares no design e desenvolvimento de sistemas de software essenciais.

Para encerrar

Depois de sobreviver à minha batalha contra o câncer e aprender a lidar com os desafios de destreza e mobilidade da minha lesão na medula espinhal, eu adoraria ter a chance de Vencer o Ceifador, contribuindo para a empolgante onda de inovações notáveis ​​no design e desenvolvimento de software conforme previsto na minha série de artigos #HeyGitHub. ✌️

Happy Healthy Vibes do Colorado EUA,
-: Jim :-

* PS Para ser claro, além do meu interesse em seguir a agenda de pesquisa prevista nesta série de artigos #HeyGitHub, continuo fortemente comprometido com a implementação da agenda do Copilot como #AssistiveTechnology por meio do estudo de pesquisa e programa de suporte para #DisabledDevelopers e # DisabledSTEMstudents descritos na maior parte dos artigos nesta publicação do Medium.

Jim Salmons é um Cientista Cidadão de Humanidades Digitais pós-câncer de setenta e um anos. Sua pesquisa principal está focada no desenvolvimento de um formato de armazenamento de dados do solo que fornece uma estrutura de documento complexa integrada e um modelo de representação de conteúdo para o estudo de coleções digitalizadas de revistas e jornais da era impressa. Uma queda em casa em julho de 2020 resultou em uma grave lesão na medula espinhal que comprometeu drasticamente sua destreza manual e mobilidade.

Jim teve a sorte de ter acesso à Comunidade de Acesso Antecipado da Tecnologia Copilot do GitHub durante seus esforços iniciais para voltar a trabalhar nas atividades de desenvolvimento de ferramentas baseadas em Python de seu principal interesse de pesquisa. Ao experimentar o dramático impacto positivo do GitHub Copilot em sua própria produtividade de desenvolvimento, ele se interessou apaixonadamente em projetar um programa de pesquisa e suporte para investigar e documentar o uso dessa tecnologia assistiva de programação inovadora para uso por desenvolvedores deficientes.