"HeyGitHub!", Agency 및 Conversational Copilot에 대한 생각

이 간행물에 대한 마지막 두 개의 기술적인 기사에서 저는 #DisabledDevelopers 와 훌륭하지만 정통한 "Rainman" GitHub 사이의 #HeyGitHub 음성 코딩 대화에 "Sherlockean" 연역적 사고를 추가하는 다소 자유로운 구상에 나 자신을 맡겼습니다. 부조종사 코드 생성기. 이 기사를 작성하는 동안 저는 보다 사려 깊은 코드 생성 대화를 구현하는 데 필요한 종류의 지원을 제공할 수 있는 기계 학습 연구 커뮤니티의 발전에 대한 방법 및 공개적으로 사용 가능한 구현에 대한 검색 탐구를 시작했습니다.

다행스럽게도 저는 LLM 의 무차별 대입 패턴 인식을 보완하기 위해 컨텍스트와 사전 지식을 사용하여 보다 "인간과 유사한" 사고 프로세스를 지원하기 위해 이러한 과제를 해결하는 기계 학습 연구 하위 커뮤니티가 많다는 것을 알게 되었습니다. 대규모 언어 모델 ) 성능. 기계 학습 영역에서 탐색 및 개발의 다른 영역 중에서 #CoT ( 생각의 사슬 ), 프롬프트 시퀀싱 , 모델 전환 및 에이전트 에 대해 배웠습니다 . 저는 Harrison Chase 의 흥미로운 LangChain Python 라이브러리 와 LangChainAI 를 사용하여 직접 경험하기 시작했습니다.개발자. 내가 따랐던 이러한 이동 경로의 대부분은 John McDonnell 의 통찰력 있는 개요 기사 "The Near Future of AI is Action-Driven"을 읽음 으로써 시작되었습니다 .

저는 또한 로봇 자동화 및 산업 프로세스 제어의 과제에 AI/ML 솔루션을 제공하는 Microsoft에서 진행 중인 막대한 자금 지원 아젠다인 Project Bonsai 에 대해서도 알게 되었습니다. 이 물리적 세계 문제 공간에서 시뮬레이션 및 인간 참여형 코칭 은 보다 일반적인 머신 러닝 응용 분야에서 데이터 모델링 및 데이터 과학 방법 을 강조하는 것만큼 중요 합니다.

이 기사에서 나의 초점은 이러한 SOTA 발전에 대해 더 깊이 파고드는 것이 아니라 소프트웨어 개발을 지원하는 #HeyGitHub/Copilot 플랫폼에 적용될 수 있는 역할 기반 에이전시 의 역할에 대해 약간 추측하는 것입니다. #DisabledDevelopers 및 #DisabledSTEMstudents , 그러나 #HeyGitHub/Copilot을 개발 생산성 승수로 사용하는 모든 예비 개발자가 사용합니다.

실행 가능한 비즈니스 모델의 에이전시에 대한 Wayback 반영

이 #HeyGitHub 시리즈의 Metamodel Subgraph 기사에서 EBM , 실행 가능한 비즈니스 모델 의 동적 구성 및 애플리케이션 생성을 지원하는 Smalltalk 기반 프레임워크를 개발하는 skunkworks에 대한 간략한 개요를 제공했습니다 .

1990년대 초중반에는 소프트웨어 개발과 비즈니스 프로세스 엔지니어링을 위한 다양한 모델 기반 방법이 나타났습니다. 이 시대의 강력한 스레드 중 하나는 BPR ( Business Process Reengineering ) 운동이었습니다. IBM의 컨설팅 서비스 내에서 당시에 사용된 인기 있는 방법은 LOVEM ( 가시성 엔터프라이즈 모델 ) 또는 때로는 가시성 엔지니어링 방법(가시성 라인 )이라고 했습니다. 이 방법의 핵심은 비즈니스 프로세스 모델에 "스윔 레인"을 사용하는 다이어그램 형식이었습니다.

LOVEM의 스윔 레인은 인간이나 기계(일명 소프트웨어 프로세스)가 수행할 수 있는 역할을 나타냅니다. David Gelernter의 1993년 책 "Mirror Worlds: or the Day Software Puts the Universe in a Shoebox…How It Will Happen and What It Will Mean"에서 영감을 받았습니다. , IBM Object Technology Practice의 동료들과 나는 이러한 역할 기반 LOVEM 모델을 구성하고 실행하는 데 사용할 수 있는 Smalltalk 객체 프레임워크를 구상했습니다. 우리의 EBM ( Executable Business Model ) 프레임워크는 디지털 인문학 시민 과학자로 재탄생한 암 후의 초기 활동에서 이 UML 클래스 모델과 매우 흡사해 보이는 개체 클래스의 메타모델 "구성 키트"를 기반으로 했습니다.

이 기사에서 강조하고 싶은 EBM 모델의 측면은 이 다이어그램의 왼쪽 하단 모서리에 있는 빨간색 상자에 표시된 클래스 클러스터입니다. 이 세 가지 클래스 ( 행위자 로서의 개인 또는 에이전트 )는 목표 기반, 역할 기반 프로세스 에 참여 합니다. 이러한 방식으로 우리의 EBM 프레임워크는 LOVEM 비즈니스 프로세스 방법에 필수적인 에이전시 개념을 구현했습니다. 우리 메타모델의 Agency 구현은 예상할 수 있듯이 Mirror Worlds 영감에 의해 주도되었습니다.

Gelernter는 자신의 저서에서 독자들에게 다음과 같은 사고 실험을 하게 했습니다. 이러한 시뮬레이션이 진행되면 시뮬레이션의 모든 입력 및 출력 피드를 이러한 실제 시스템의 실제 피드에 연결하면 어떤 일이 일어날지 상상해 보십시오. 그 시점에서 우리의 소프트웨어 모델은 시뮬레이션이 아니라 Real World에서 헤드업 디스플레이 또는 대시보드 뷰가 되기 시작합니다…” 또는 Gelernter가 Mirror Worlds 라고 부르는 것 입니다.

EBM 메타모델 기반 프레임워크에서 에이전시에 대한 이 접근 방식을 구현하여 에이전트 객체가 실행 가능한 LOVEM 모델에서 역할의 행위자로서 사람을 위한 소프트웨어 프록시로 구현될 수 있습니다. 이 디자인은 Mirror Worlds 영감과 일치하는 두 가지 중요한 기능을 제공했습니다. 첫째, 고객 경영진과의 컨설팅 참여 세션에서 고객의 주제 전문가인 SME를 회의실의 네트워크 노트북에 앉아 진화하는 시뮬레이션 모델과 상호 작용하고 검증하도록 할 수 있습니다. 이 세션 동안 모델화된 비즈니스 프로세스에서 다른 모든 역할을 수행하기 위해 시뮬레이션 에이전트 소프트웨어 프록시로 실행 모델 인스턴스를 채울 수 있습니다.

고객의 SME가 EBM 시뮬레이션에서 이러한 비즈니스 프로세스를 확정했다고 확신하면 진정한 Mirror Worlds 에서 영감을 얻은 방식으로 이러한 모델을 실제 고객 비즈니스에 배포된 시스템으로 연결하기만 하면 됩니다. 이 훅업 프로세스 동안 우리는 사용자가 일반적인 소프트웨어 애플리케이션으로 보는 모델에서 동적으로 생성된 EBM 보기를 사용하여 개인이 수행할 역할 또는 고객의 소프트웨어 프록시 에이전트 액터가 수행할 역할을 결정합니다. 비즈니스 프로세스.

거의 30년 전 그 시간을 돌이켜보면, 이 EBM 스컹크웍스에서 생각의 리더/개발자로 일하면서 보낸 시간은 내 작업 경력에서 가장 짜릿한 경험 중 일부였습니다.

#HeyGitHub/Copilot 플랫폼의 에이전시에 대한 미래 지향적 추측

그렇다면 에이전시의 개념은 GitHub의 #HeyGitHub/Copilot 서비스 구현에 기여하는 진화하는 기술 스택의 일부로서 생각의 사슬, 프롬프트 시퀀싱 및 모델 전환과 같은 접근 방식의 기능을 활용하는 데 어떻게 기여할 수 있습니까?

엄격하거나 사소하지 않은 예를 의도하지 않고 이 간단한 스윔 레인 다이어그램과 같이 내 EBM 경험에서 #HeyGitHub/Copilot 서비스의 솔루션 설계에 이 역할 기반 에이전시 개념을 적용할 수 있습니다.

이 지나치게 단순한 다이어그램에서 우리가 볼 수 있는 것은 인간으로서 능동적으로 상호 작용하는 상위 계층에 있는 4개의 스윔 레인과 IDE의 "멍청한"/데이터 기록 전문가와 같은 역할에서 최종 생성으로 이어지는 대화를 나누는 3개의 소프트웨어 에이전트의 클러스터입니다. 앱 및 소스 파일(메모리). 이 간단한 다이어그램은 우리가 앞으로 나아가야 할 엄청난 도전이 우리의 정통한 Rainman-Agent Copilot LLM을 최대한 활용하기 전에 에이전트 기반 대화에 "Sherlockean smarts"를 주입하는 방법이라는 것을 분명히 보여줍니다.

예를 들어 우리의 설계 요구 사항이 고성능 전화 콜 센터 봇 에이전트를 만드는 것이라고 상상해 보십시오. 이 경우 목표 지향적인 결과를 위해 동적으로 선택할 수 있는 템플릿 기반 프롬프트의 유연한 레퍼토리가 배포하기에 충분할 수 있습니다. 그러나 비인간 페어 프로그래머(에이전트 "버디") 역할을 성공적으로 수행하려면 GitHub가 Copilot 서비스를 설명할 때 종종 주장하는 것처럼 #HeyGitHub 리스너 및 CoT 대화 에이전트는 스크립팅 가능한 콜 센터 봇보다 훨씬 더 복잡한 인텔리전스를 구현해야 합니다. 대화.

예를 들어 개발자가 응용 프로그램의 UI/UX(사용자 인터페이스 및 대화형 경험)를 만드는 데 도움을 주는 #HeyGitHub/Copilot의 도전을 살펴보겠습니다. 개발자가 사용할 수 있는 우수한 UI/UX 프레임워크는 상당히 많습니다. 우리의 Rainman-savant Copilot은 Copilot의 기본 모델 교육에서 코드 생성 능력을 개선하기 위해 이미 이러한 프레임워크의 수많은 예를 보았습니다. 그러나 교육 경험에서 얻은 패턴 인식을 기반으로 유용하게 코드 제안을 제공할 수 있다고 해서 유능한 인간 개발자가 참여 역할에 제공하는 프레임워크 아키텍처, 모범 사례 및 사용자 인터페이스/상호 작용 지침에 대한 기본적인 이해를 Copilot에 제공할 수 있는 것은 아닙니다. 프로그래밍 쌍 파트너십에서.

유서 깊은 C++ wxWidgets 프레임워크의 wxPython 래퍼 의 예를 고려하십시오 . 공개적으로 액세스할 수 있는 수많은 코드 리포지토리를 무작위로 탐색해도 우수한 온라인 문서 웹 사이트에 대한 심층 분석을 통해 제공되는 지식의 범위는 드러날 수 없습니다.https://docs.wxpython.org/. 이 웹 사이트의 콘텐츠에 대한 NLP 분해, 주제 모델링/요약 반추는 인간 개발자 지식을 #HeyGitHub/Copilot<>개발자 대화에 전달하기에 충분하지 않습니다.

그래서 우리는 여기서 어디로 가야합니까?

나는 오늘날의 코드 생성 LLM의 성능을 "다음 수준"으로 끌어올리는 데 필요한 기술을 생산하기 위해 특정 솔루션 설계 및 개발 경로를 제안할 수 있는 충분한 도메인 지식이 있었으면 합니다. 앞으로의 전체 로드맵은 아직 작성되지 않았지만 다음 단계에 대해 몇 가지 가정을 할 수 있습니다. #HeyGitHub 리스너 에이전트가 추가 사려 깊은 상호 작용을 위해 CoT Dialoguer 로 전달해야 하는 개발자 음성 입력 또는 Copilot LLM 에 텍스트 형식으로 전달되는 개발자 음성 입력을 구별할 수 있는 것이 중요할 것으로 예상할 수 있습니다. 코드 제안 생성.

우리 앞에 놓인 끔찍한 도전은 CoT Dialoguer 가 진정한 프로그래밍 쌍 파트너로서 확실하게 수행할 수 있도록 소프트웨어 공학의 예술과 과학의 정보 구조와 의미론적 의미를 캡슐화하는 것입니다 . 이 문제를 해결하기 위한 기술은 생각의 사슬, 프롬프트 선택/시퀀싱, 모델 전환 및 인간 참여형 강화 학습/코칭과 관련된 최첨단 연구 활동에서 나올 것입니다.

이 "Sherlockean smarts" 솔루션 공간의 일부 혁신에는 기계 학습 연구 엔지니어의 뛰어난 혁신 코딩이 포함됩니다. 그러나 나는 또한 도메인별 모델이 서로 협력하여 작업할 수 있도록 교육 커리큘럼 자료 역할을 할 효과적인 Ground Truth 참조 모델 데이터 세트 의 설계 및 개발에서 이 과제에 대한 적지 않은 기여를 할 것이라고 믿습니다. 끊임없이 진화하는 기본 Copilot Large Language Model을 사용하여 모델 전환 컨텍스트. 이러한 새로운 참조 데이터 세트의 예는 내가 Digital Humanities 연구를 통해 추구하고 여기 내 #HeyGitHub 기사 시리즈에서 구상 한 Metamodel Subgraph Ground Truth Storage 디자인입니다.

그러나 표준 에이전트 지향 Ground Truth 참조 데이터 세트 형식을 개발하는 것만으로는 인간 개발자와 ML 기반 Copilot 쌍 프로그래밍 파트너 간의 Sherlockean 대화를 불러일으키기에 충분하지 않습니다. 오히려 도메인 지식의 이러한 Ground Truth 참조 데이터 세트는 CoT Diaguer 에이전트가 인간 개발자 파트너와 협력 대화에 참여할 수 있는 능력을 개선하는 모델 교육 시뮬레이션 사용자 상호 작용 시나리오에서 교육 자료 역할을 해야 합니다. 이러한 시뮬레이션 세션은 CoT Diaguer의 도메인 지식의 효과적인 사용을 개선하기 위해 시간을 단축하고 끊임없이 추구할 수 있습니다.

현재 데이터 모델링 모범 사례를 사용하여 현재 데이터 집약적인 ML 애플리케이션을 위한 교육 데이터 세트를 생성하는 것처럼 지식 기반 애플리케이션이 상상한 것과 같은 모델을 교육하고 개선할 수 있는 에이전트 기반 시뮬레이션 경험을 생성할 수 있습니다. 향후 #HeyGitHub/Copilot 서비스. 이 Mirror Worlds 와 같은 시뮬레이션 교육 환경의 일부로, 교육 중 #HeyGitHub CoT 대화 모델을 방해하는 대화 교환이 응답 코칭이 적절한 모델 동작을 장려하고 강화할 인간 참여형 감독자에게 나타납니다.

GitHub 및 Microsoft의 Bonnets에 꿀벌 몇 마리

이 시점에서 앞으로 나아갈 길을 상상하는 나의 비행은 인디 디지털 인문학 시민 과학자 및 장애인 개발자의 열렬한 꿈에 지나지 않습니다. 그러나 GitHub와 Microsoft의 보닛에 꿀벌 두어 마리를 넣기 위해 오래된 IBM 컨설턴트 모자를 벗는다면 제가 제안할 것을 알고 있습니다…

첫째, 내가 GitHub 관리의 일원이라면 GitHub Next 연구팀의 일원으로 일자리를 제공할 것이라고 말할 수 밖에 없습니다. 그 위치에서 나는 이 #HeyGitHub 기사 시리즈 * 에서 내가 쓴 아이디어에 대해 부지런히 작업할 것입니다 .

다음으로 Metamodel Subgraph Ground Truth 도메인 지식 모델 교육 데이터 세트에 대한 개념 증명이 있으면 최근에 발표된 GitHub Accelerator 또는 M12 GitHub Fund 의 일부 를 할당하여 고성능 프로젝트에 대한 봉급 또는 프로젝트 시작 자금을 제공하기 위해 로비를 할 것입니다. , 전문 오픈 소스 개발자가 이러한 도메인별 에이전트 지향 모델 훈련 데이터 세트 모음을 생성합니다. UI/UX 프레임워크별 메타모델 기반 교육 데이터 세트를 개발할 때는 특히 강조해야 합니다.

UI/UX 프레임워크 특정 도메인 지식 데이터 세트가 필요한 이유는 무엇입니까? 이러한 "짐승"은 종종 매개 변수별로 지나치게 세부적인 사용자 지정이 포함된 크고 복잡한 아키텍처이기 때문입니다. 그리고 대부분의 개발 프로젝트 시나리오에서 응용 프로그램 UI 및 해당 사용자 상호 작용을 만드는 것은 프로젝트의 최종 사용자가 응용 프로그램 UI/UX를 간단하게 사용할 수 있도록 하는 프로젝트의 문제 공간에 솔루션을 코딩하는 것에서 시간과 노력이 필요한 활동입니다. #HeyGitHub/Copilot에서 음성 입력으로 강력한 UI/UX 프레임워크 코드 생성을 제공하는 것은 강력한 WYSIWYG 인터페이스 빌더 애플리케이션이 있는 UI/UX 프레임워크를 갖는 것과 비슷합니다.

보다 광범위하고 전략적인 권장 사항으로 GitHub Next 및 Microsoft의 Project Bonsai 에서 생각을 선도하는 연락처를 통해 협업 위원회를 구성하도록 권장합니다. 이 그룹의 목적은 GitHub가 Microsoft가 로봇 및 산업 프로세스 자동화 시장에 투입한 광범위한 노력의 모범 사례와 경험을 활용할 수 있는 방법을 탐색하는 것입니다.

그리고 바라건대 수평선 너머에 숨어

장밋빛 안경과 낙관적인 슬로건 티셔츠를 입고 혁신 고속도로를 더 멀리 내다보면 이 연구 의제는 어디로 이어질까요? 제한된 수의 도메인별 Metamodel Subgraph 참조 Ground Truth 데이터 세트를 생성하고 여러 도메인에서 CoT Dialoguer 에이전트 역할을 수행하도록 기계 학습 모델을 교육하는 데 시간과 노력을 기울인다면 언젠가는 Dialoguer 시스템을 보게 될 것입니다. 응급 행동을 보여줍니다 .

즉, CoT Dialoguer Agent 모델은 일반화된 구조와 도메인 지식의 사용을 잘 이해할 수 있으므로 새로운 컨텍스트에 참여하는 데 유용하기 위해 새로운 도메인별 참조 모델을 미리 로드할 필요가 없습니다. 이 수준의 기능에서 먼 미래의 #HeyGitHub/Copilot 다중 모델 시스템은 개발자 쌍 프로그래밍 파트너와 자기주도 학습 대화에 참여하여 자체적인 새로운 도메인 지식 모델을 만들고 검증할 수 있습니다. 이 프로세스를 통해 #HeyGitHub/Copilot 서비스는 필수 소프트웨어 시스템의 설계 및 개발에서 진정으로 다재다능한 피어 레벨 협력자가 될 수 있습니다.

마무리 중

암 투병에서 살아남고 척수 손상으로 인한 손재주 및 이동성 문제에 대처하는 방법을 배운 후 디자인 및 개발 분야에서 놀라운 혁신의 흥미진진한 다가오는 물결에 기여함으로써 사신을 이길 기회를 갖는 것보다 더 좋은 것은 없습니다. 내 #HeyGitHub 기사 시리즈에서 구상한 소프트웨어. ✌️

미국 콜로라도에서 온 Happy Healthy Vibes,
-: Jim :-

* 추신 : 이 #HeyGitHub 기사 시리즈에서 구상한 연구 의제를 추구하는 데 관심이 있는 것 외에도 #DisabledDevelopers 및 #DisabledDevelopers 및 # 이 Medium 간행물에 있는 대부분의 기사에 설명된 장애가 있는 STEM 학생.

Jim Salmons 는 71세의 암 후 디지털 인문학 시민 과학자입니다. 그의 주요 연구는 인쇄 시대 잡지 및 신문의 디지털화된 컬렉션 연구를 위한 통합된 복합 문서 구조 및 콘텐츠 묘사 모델을 제공하는 Ground Truth Storage 형식의 개발에 중점을 두고 있습니다. 2020년 7월 집에서 넘어져 심각한 척수 손상을 입어 손재주와 이동성이 크게 손상되었습니다.

Jim은 그의 주요 연구 관심사인 Python 기반 도구 개발 활동으로 돌아가기 위한 초기 노력 중에 GitHub Copilot 기술 조기 액세스 커뮤니티에 대한 액세스 권한을 제공받은 행운을 누렸습니다. GitHub Copilot이 자신의 개발 생산성에 미치는 극적이고 긍정적인 영향을 경험한 후 그는 장애가 있는 개발자가 사용할 이 혁신적인 프로그래밍 보조 기술의 사용을 조사하고 문서화하기 위한 연구 및 지원 프로그램을 설계하는 데 열정적으로 관심을 갖게 되었습니다.