“HeyGitHub!”, Suy nghĩ về Đại lý và Copilot đàm thoại

Trong hai bài báo cuối cùng mang tính kỹ thuật hơn cho ấn phẩm này, tôi đã để bản thân mình tiếp tục hình dung khá tự do về việc thêm tư duy suy luận “Sherlockean” vào cuộc đối thoại mã hóa giọng nói #HeyGitHub giữa #DisabledDevelopers và “Rainman” GitHub tài giỏi nhưng giống như một nhà thông thái. Trình tạo mã phi công phụ. Trong khi viết những bài báo này, tôi đã bắt đầu tìm kiếm các phương pháp và triển khai công khai các tiến bộ trong cộng đồng nghiên cứu Máy học có thể cung cấp loại hỗ trợ cần thiết để triển khai các cuộc trò chuyện tạo mã chu đáo hơn này.

Rất vui là tôi nhận thấy rằng có một số cộng đồng con nghiên cứu Máy học đang giải quyết những thách thức này để hỗ trợ các quy trình tư duy “giống con người” hơn, sử dụng ngữ cảnh và kiến ​​thức có sẵn, như một phần bổ sung cho việc nhận dạng mô hình vũ phu của LLM ( Mô hình ngôn ngữ lớn ) hiệu suất. Tôi đã tìm hiểu về #CoT ( Chuỗi suy nghĩ ), trình tự nhắc nhở , chuyển đổi mô hình và tác nhân trong số các lĩnh vực khám phá và phát triển khác trong miền Máy học. Tôi đang bắt đầu có được trải nghiệm trực tiếp khi sử dụng thư viện LangChain Python thú vị từ Harrison Chase và LangChainAInhà phát triển. Nhiều trong số những con đường dẫn dắt mà tôi đã theo dõi này bắt đầu bằng cách đọc bài báo tổng quan sâu sắc, “Tương lai gần của AI là được thúc đẩy bởi hành động” của John McDonnell .

Tôi cũng đã biết về một chương trình nghị sự khổng lồ, siêu tài trợ đang được triển khai tại Microsoft — Project Bonsai — mang đến các giải pháp AI/ML để giải quyết các thách thức về tự động hóa rô-bốt và kiểm soát quy trình công nghiệp. Trong không gian giải quyết vấn đề của thế giới vật lý này, mô phỏng và huấn luyện con người trong vòng lặp cũng quan trọng, nếu không muốn nói là quan trọng hơn, giống như việc nhấn mạnh vào các phương pháp mô hình hóa dữ liệu và khoa học dữ liệu trong miền ứng dụng Học máy tổng quát hơn.

Trọng tâm của tôi trong bài viết này không phải là nghiên cứu sâu hơn về những tiến bộ SOTA này, mà là suy đoán một chút về vai trò của đại lý dựa trên vai trò vì nó có thể được áp dụng cho nền tảng #HeyGitHub/Copilot để hỗ trợ phát triển phần mềm không chỉ bởi #DisabledDevelopers và #DisabledSTEMstudents , nhưng bởi tất cả các nhà phát triển tiềm năng sử dụng #HeyGitHub/Copilot làm hệ số năng suất phát triển.

Phản ánh ngược về đại lý trong các mô hình kinh doanh có thể thực thi

Trong bài viết Sơ đồ con Metamodel của tôi trong loạt bài #HeyGitHub này, tôi đã trình bày tổng quan ngắn gọn về sự tham gia của tôi trong một skunkworks đang phát triển khung dựa trên Smalltalk hỗ trợ thành phần động và tạo ứng dụng của EBM , Mô hình kinh doanh có thể thực thi .

Đầu giữa những năm 1990 đã chứng kiến ​​một loạt các phương pháp dựa trên mô hình cho cả phát triển phần mềm và kỹ thuật quy trình kinh doanh. Một chủ đề mạnh mẽ trong thời đại này là phong trào BPR , hay Tái cấu trúc quy trình kinh doanh . Trong các dịch vụ tư vấn của IBM, một phương pháp phổ biến được sử dụng vào thời điểm đó được gọi là LOVEM , Mô hình doanh nghiệp trực quan hoặc đôi khi là Phương pháp kỹ thuật trực quan . Trọng tâm của phương pháp này là một định dạng sơ đồ sử dụng “đường bơi” cho các mô hình quy trình kinh doanh.

Các làn bơi của LOVEM thể hiện các vai trò có thể được thực hiện bởi con người hoặc máy móc (quy trình phần mềm AKA). Lấy cảm hứng từ cuốn sách năm 1993 của David Gelernter, “Mirror Worlds: or the Day Software Puts the Universe in a Shoebox…How It Will Happen and What It Will Mean.” , các đồng nghiệp của tôi và tôi trong Thực hành Công nghệ Đối tượng của IBM đã hình dung ra một khung đối tượng Smalltalk có thể được sử dụng để soạn thảo và thực thi các mô hình LOVEM dựa trên vai trò này. Khung EBM , Mô hình kinh doanh có thể thực thi được của chúng tôi dựa trên “bộ công cụ xây dựng” siêu mô hình gồm các lớp đối tượng trông rất giống mô hình Lớp UML này từ hoạt động ban đầu trong quá trình tái sinh sau ung thư của tôi với tư cách là Nhà khoa học Công dân Nhân văn Kỹ thuật số:

Khía cạnh của mô hình EBM mà tôi muốn nhấn mạnh trong bài viết này là cụm các lớp được nhìn thấy trong hộp màu đỏ ở góc dưới bên trái của sơ đồ này. Ba lớp này — Người hoặc Đại lý với tư cách là Diễn viên — tham gia vào các quy trình dựa trên Vai trò , theo Mục tiêu . Bằng cách này, khung EBM của chúng tôi đã triển khai khái niệm Đại lý cần thiết cho phương pháp quy trình kinh doanh LOVEM. Việc triển khai Đại lý trong siêu mô hình của chúng tôi, như bạn có thể mong đợi, được thúc đẩy bởi cảm hứng Thế giới gương của chúng tôi .

Trong cuốn sách của mình, Gelernter đã đưa độc giả vào một thí nghiệm tưởng tượng, diễn giải ở đây, “Hãy tưởng tượng nếu chúng ta xây dựng các mô phỏng phần mềm chi tiết về các hệ thống phức tạp của chúng ta đang hoạt động trong Thế giới thực. Sau khi chúng tôi có các mô phỏng này, hãy tưởng tượng điều gì sẽ xảy ra nếu chúng tôi lấy tất cả các nguồn cấp dữ liệu đầu vào và đầu ra của các mô phỏng của mình và kết nối chúng với các nguồn cấp dữ liệu thực tế trong các hệ thống Thế giới thực này. Tại thời điểm đó, các mô hình phần mềm của chúng tôi sẽ không còn là mô phỏng và bắt đầu là màn hình hiển thị trực tiếp hoặc chế độ xem bảng điều khiển, trên Thế giới thực…” hoặc cái mà Gelernter gọi là Thế giới trong gương .

Chúng tôi đã triển khai cách tiếp cận này cho Đại lý trong khung dựa trên siêu mô hình EBM của mình để các đối tượng Đại lý có thể được triển khai dưới dạng proxy phần mềm cho Người với tư cách là Người thực hiện các vai trò trong các mô hình LOVEM có thể thực thi. Thiết kế này mang lại cho chúng tôi hai tính năng quan trọng phù hợp với nguồn cảm hứng Thế giới gương của chúng tôi . Đầu tiên, trong các phiên tham gia tư vấn với các giám đốc điều hành của khách hàng, chúng tôi có thể yêu cầu các doanh nghiệp vừa và nhỏ, các chuyên gia về chủ đề của khách hàng, ngồi trước máy tính xách tay nối mạng trong phòng hội nghị để tương tác và xác thực các mô hình mô phỏng đang phát triển của chúng tôi. Trong các phiên này, chúng tôi có thể đưa vào một phiên bản mô hình thực thi bằng proxy phần mềm Tác nhân mô phỏng để thực hiện tất cả các Vai trò khác trong một quy trình kinh doanh được mô hình hóa.

Sau khi các doanh nghiệp vừa và nhỏ của khách hàng tin rằng chúng tôi đã đóng đinh các quy trình kinh doanh này trong mô phỏng EBM của mình, chúng tôi có thể - theo kiểu lấy cảm hứng từ Mirror World thực sự - chỉ cần kết nối các mô hình này thành một hệ thống được triển khai trong hoạt động kinh doanh thực tế của khách hàng. Trong quá trình kết nối này, chúng tôi sẽ xác định Vai trò nào sẽ được thực hiện bởi Người — sử dụng chế độ xem EBM được tạo động trên mô hình mà người dùng xem là ứng dụng phần mềm điển hình — hoặc theo Vai trò do Tác nhân đại lý ủy quyền phần mềm đóng trong khách hàng' quy trình kinh doanh.

Hồi tưởng lại khoảng thời gian gần ba mươi năm trước, những ngày tôi làm việc với tư cách là nhà lãnh đạo tư tưởng/nhà phát triển trong EBM skunkworks này là một trong những trải nghiệm thú vị nhất trong sự nghiệp làm việc của tôi.

Một suy đoán hướng tới tương lai về đại lý trong #HeyGitHub/Nền tảng Copilot

Vì vậy, khái niệm Đại lý có thể đóng góp như thế nào vào việc chúng tôi tận dụng khả năng của các phương pháp như Chuỗi suy nghĩ, sắp xếp theo trình tự nhanh và chuyển đổi mô hình như một phần của nhóm công nghệ đang phát triển góp phần triển khai dịch vụ #HeyGitHub/Copilot của GitHub?

Không có ý định làm ví dụ nghiêm ngặt hoặc không tầm thường, chúng tôi có thể áp dụng khái niệm Đại lý dựa trên vai trò này từ trải nghiệm EBM của tôi vào thiết kế giải pháp của dịch vụ #HeyGitHub/Copilot như trong sơ đồ làn bơi đơn giản này:

Những gì chúng ta thấy trong sơ đồ quá đơn giản này là một cụm gồm bốn đường bơi ở các lớp trên tương tác tích cực với tư cách là Con người và ba Tác nhân phần mềm mà cuộc trò chuyện của họ dẫn đến việc tạo ra cuối cùng trong các Vai trò giống như người sao chép dữ liệu/người sao chép dữ liệu của IDE app và tệp nguồn (bộ nhớ). Sơ đồ đơn giản này cho thấy rõ rằng thách thức to lớn mà chúng tôi phải đối mặt trong tương lai là làm thế nào để đưa “sự thông minh của Sherlockean” vào cuộc trò chuyện dựa trên Đại lý đó trước khi sử dụng tốt nhất Rainman-Agent Copilot LLM giống như nhà thông thái của chúng tôi.

Ví dụ, hãy tưởng tượng yêu cầu thiết kế của chúng tôi là tạo ra một Tác nhân bot Call Center điện thoại có chức năng cao. Trong trường hợp này, một danh mục linh hoạt các lời nhắc dựa trên mẫu có thể được chọn động cho kết quả hướng đến mục tiêu có thể đủ để đi đến triển khai. Nhưng hoạt động thành công với tư cách là một Lập trình viên theo cặp không phải con người (Đặc vụ “bạn thân”), như GitHub thường khẳng định khi mô tả dịch vụ Copilot của mình, #HeyGitHub Listener và Đại lý đối thoại CoT sẽ cần triển khai một trí thông minh phức tạp hơn nhiều so với bot Trung tâm cuộc gọi có thể viết được kịch bản cuộc nói chuyện.

Ví dụ: hãy lấy thử thách dành cho #HeyGitHub/Copilot giúp Nhà phát triển tạo UI/UX — giao diện người dùng và trải nghiệm tương tác — cho một ứng dụng. Có khá nhiều khung UI/UX xuất sắc mà Nhà phát triển có thể sử dụng. Copilot hiểu biết về Rainman của chúng tôi đã thấy vô số ví dụ về các khung này trong quá trình đào tạo mô hình nền tảng của Copilot để tinh chỉnh tài năng tạo mã của nó. Nhưng việc có thể cung cấp các đề xuất mã một cách hữu ích dựa trên nhận dạng mẫu được rút ra từ kinh nghiệm đào tạo của nó không mang lại cho Copilot sự hiểu biết cơ bản về kiến ​​trúc khung, các phương pháp hay nhất và nguyên tắc tương tác/giao diện người dùng mà một Nhà phát triển có năng lực mang lại cho vai trò tham gia trong quan hệ đối tác Cặp lập trình.

Hãy xem xét ví dụ về trình bao bọc wxPython trên khung wxWidgets C++ đáng kính . Không có số lần đi bộ ngẫu nhiên qua vô số kho lưu trữ mã có thể truy cập công khai sẽ tiết lộ mức độ kiến ​​thức được truyền đạt bằng cách đi sâu vào trang web tài liệu trực tuyến tuyệt vời tạihttps://docs.wxpython.org/. Không có số lượng phân tách NLP, mô hình hóa chủ đề/nghiên cứu tổng kết về nội dung của trang web này sẽ đủ để truyền đạt kiến ​​thức của nhà phát triển con người vào cuộc trò chuyện #HeyGitHub/Copilot<>Nhà phát triển.

Vì vậy, nơi nào chúng ta đi từ đây?

Tôi ước mình có đủ kiến ​​thức về miền để đề xuất một lộ trình phát triển và thiết kế giải pháp cụ thể phía trước nhằm tạo ra các công nghệ cần thiết để đưa hiệu suất của các LLM tạo mã ngày nay lên “cấp độ tiếp theo” theo câu tục ngữ đó. Mặc dù lộ trình đầy đủ phía trước vẫn chưa được viết ra nhưng chúng tôi có thể đưa ra một số giả định về các bước tiếp theo. Chúng tôi có thể dự đoán rằng điều quan trọng đối với tác nhân #HeyGitHub Listener là có thể phân biệt giữa các đầu vào bằng giọng nói của Nhà phát triển yêu cầu chuyển giao cho Người đối thoại CoT để tương tác chu đáo hơn hoặc được chuyển ở dạng văn bản tới LLM Copilot cho tạo các đề xuất mã.

Thách thức nan giải trước mắt chúng ta là gói gọn các cấu trúc thông tin và ý nghĩa ngữ nghĩa của nghệ thuật và khoa học công nghệ phần mềm sao cho CoT Dialoguer có thể hoạt động đáng tin cậy như một đối tác Cặp lập trình thực sự. Các công nghệ để đáp ứng thách thức này có thể sẽ đến từ hoạt động nghiên cứu hàng đầu xung quanh Chuỗi suy nghĩ, lựa chọn nhanh/xếp thứ tự, chuyển đổi mô hình và học tập/huấn luyện củng cố con người trong vòng lặp.

Một số bước đột phá trong không gian giải pháp “Sherlockean smarts” này sẽ liên quan đến mã hóa sáng tạo xuất sắc của các kỹ sư nghiên cứu Machine Learning. Tuy nhiên, tôi cũng tin rằng một đóng góp không hề nhỏ cho thách thức này sẽ đến từ việc thiết kế và phát triển các bộ dữ liệu mô hình tham chiếu Ground Truth hiệu quả . bối cảnh chuyển đổi mô hình với Mô hình ngôn ngữ lớn Copilot nền tảng không ngừng phát triển. Một ví dụ về các bộ dữ liệu tham chiếu mới nổi này là thiết kế Lưu trữ sự thật nền tảng đồ thị con Metamodel mà tôi đã theo đuổi thông qua nghiên cứu về Nhân văn kỹ thuật số của mình và đã hình dung ở đây trong loạt bài viết #HeyGitHub của tôi.

Nhưng việc phát triển định dạng bộ dữ liệu tham chiếu Ground Truth hướng đến Đại lý tiêu chuẩn sẽ không đủ để gợi lên các cuộc đối thoại Sherlockean mà tôi hình dung giữa Nhà phát triển là con người và đối tác Lập trình cặp phi công phụ dựa trên ML. Thay vào đó, các bộ dữ liệu tham chiếu Ground Truth về kiến ​​thức miền này sẽ cần đóng vai trò là tài liệu hướng dẫn trong các tình huống tương tác với người dùng mô phỏng đào tạo mô hình nhằm tinh chỉnh khả năng của tác nhân CoT Dialoguer để tham gia vào cuộc trò chuyện cộng tác với đối tác Nhà phát triển là con người của nó. Các phiên mô phỏng này có thể nén thời gian và theo đuổi không mệt mỏi việc tinh chỉnh cách sử dụng hiệu quả kiến ​​thức miền của Người đối thoại CoT.

Giống như hiện tại chúng tôi sử dụng các phương pháp hay nhất về lập mô hình dữ liệu để tạo tập dữ liệu đào tạo cho các ứng dụng ML sử dụng nhiều dữ liệu hiện tại, nên chúng tôi cũng sẽ có thể tạo trải nghiệm mô phỏng dựa trên Tác nhân cho phép các ứng dụng dựa trên kiến ​​thức của chúng tôi đào tạo và tinh chỉnh các mô hình giống như trong tưởng tượng. dịch vụ #HeyGitHub/Copilot trong tương lai. Là một phần của môi trường đào tạo mô phỏng giống như Mirror Worlds này , các cuộc trao đổi trò chuyện cản trở mô hình Người đối thoại #HeyGitHub CoT trong quá trình đào tạo sẽ xuất hiện trước Người giám sát trực tiếp của con người, người mà việc huấn luyện phản hồi sẽ khuyến khích và củng cố hành vi phù hợp của người mẫu.

Một vài con ong trong Bonnets tại GitHub và Microsoft

Tại thời điểm này, những chuyến bay tưởng tượng về con đường phía trước của tôi không chỉ là giấc mơ gây sốt của một Nhà khoa học Công dân và Nhà phát triển Người khuyết tật Kỹ thuật số Nhân văn độc lập. Nhưng nếu tôi phủi bỏ chiếc mũ cố vấn IBM cũ kỹ của mình để đặt một vài con ong vào nắp ca-pô tại GitHub và Microsoft, tôi biết mình sẽ đề xuất điều gì…

Đầu tiên, tôi không thể không nói rằng, nếu tôi là một phần của ban quản lý GitHub, tôi sẽ mời tôi làm thành viên của nhóm nghiên cứu GitHub Next. Ở vị trí đó, tôi sẽ làm việc chăm chỉ với những ý tưởng mà tôi đã viết trong loạt bài viết #HeyGitHub * này .

Tiếp theo, khi chúng tôi có Bằng chứng về khái niệm cho bộ dữ liệu đào tạo mô hình kiến ​​thức miền Metamodel Subgraph Ground Truth, tôi sẽ vận động hành lang để dành một phần của Công cụ tăng tốc GitHub được công bố gần đây hoặc Quỹ M12 GitHub để cung cấp các khoản trợ cấp hoặc tài trợ khởi động dự án cho hiệu suất cao , các nhà phát triển Nguồn mở chuyên nghiệp để tạo một bộ sưu tập các tập dữ liệu đào tạo mô hình hướng đến Tác nhân dành riêng cho miền này. Cần xem xét một điểm nhấn đặc biệt để phát triển bộ dữ liệu đào tạo dựa trên siêu mô hình dành riêng cho khung UI/UX.

Tại sao phải có bộ dữ liệu kiến ​​thức miền dành riêng cho khung UI/UX? Bởi vì những “con thú” này thường là những kiến ​​trúc lớn, phức tạp với khả năng tùy chỉnh quá chi tiết về thông số. Và đối với hầu hết các tình huống của dự án phát triển, việc tạo giao diện người dùng ứng dụng và các tương tác với người dùng của nó là các hoạt động cần thiết tốn thời gian và công sức để viết mã giải pháp cho không gian vấn đề của dự án mà UI/UX của ứng dụng đơn giản cung cấp cho người dùng cuối của dự án. Khi đó, việc cung cấp khả năng tạo mã khung UI/UX mạnh mẽ bằng đầu vào bằng giọng nói trong #HeyGitHub/Copilot có thể so sánh với việc có một khung UI/UX có ứng dụng trình tạo giao diện WYSIWYG mạnh mẽ.

Là một đề xuất chiến lược và có phạm vi rộng hơn, tôi sẽ khuyến khích những người liên hệ có tư tưởng hàng đầu từ GitHub Next và Project Bonsai của Microsoft thành lập Ủy ban cộng tác. Mục đích của nhóm này là khám phá những cách mà GitHub có thể tận dụng các phương pháp hay nhất và kinh nghiệm về cam kết sâu rộng mà Microsoft đã đưa vào thị trường robot và tự động hóa quy trình công nghiệp.

Và hy vọng ẩn nấp ngay bên kia đường chân trời

Nhìn xa hơn nữa xuống Đại lộ Đổi mới trong khi đeo cặp kính màu hồng và mặc áo phông có khẩu hiệu lạc quan, chương trình nghiên cứu này có thể dẫn đến đâu? Nếu sau khi tạo một số lượng giới hạn bộ dữ liệu Sơ đồ cơ sở tham chiếu Siêu mô hình dành riêng cho miền và dành thời gian và công sức để đào tạo mô hình Học máy để đóng vai trò tác nhân CoT Dialoguer trong một số miền, thì một ngày nào đó chúng ta có thể thấy hệ thống Dialoguer thể hiện hành vi mới nổi .

Ý tôi là, mô hình Tác nhân đối thoại CoT có thể hiểu cấu trúc tổng quát và việc sử dụng kiến ​​thức miền tốt đến mức không cần phải tải sẵn mô hình tham chiếu dành riêng cho miền mới để trở nên hữu ích khi tham gia vào ngữ cảnh mới. Ở cấp độ chức năng này, hệ thống đa mô hình #HeyGitHub/Copilot trong tương lai xa có thể chỉ cần tham gia vào một cuộc trò chuyện học tập tự định hướng với đối tác Lập trình cặp nhà phát triển để tạo và xác thực mô hình kiến ​​thức miền mới của riêng mình. Thông qua quá trình này, dịch vụ #HeyGitHub/Copilot có thể trở thành cộng tác viên cấp ngang hàng thực sự linh hoạt trong việc thiết kế và phát triển các hệ thống phần mềm thiết yếu.

Kết thúc

Sau khi sống sót sau trận chiến ung thư và học cách đối phó với những thách thức về sự khéo léo và khả năng vận động do chấn thương tủy sống, tôi không mong gì hơn là có cơ hội đánh bại Thần chết bằng cách đóng góp vào làn sóng đổi mới đáng chú ý sắp tới trong thiết kế và phát triển của phần mềm như đã hình dung trong loạt bài viết #HeyGitHub của tôi. ✌️

Happy Healthy Vibes từ Colorado USA,
-:Jim:-

* Tái bút Để rõ ràng, ngoài sở thích theo đuổi chương trình nghiên cứu được hình dung trong loạt bài viết #HeyGitHub này, tôi vẫn nhiệt tình cam kết thực hiện chương trình nghị sự của Copilot với tư cách là #AssistiveTechnology thông qua nghiên cứu nghiên cứu và chương trình hỗ trợ cho #DisabledDevelopers và # Sinh viên bị vô hiệu hóaSTEM được mô tả trong phần lớn các bài báo trong ấn phẩm Phương tiện này.

Jim Salmons là một nhà khoa học Công dân Nhân văn Kỹ thuật số bảy mươi mốt tuổi sau ung thư. Nghiên cứu chính của ông tập trung vào việc phát triển định dạng Lưu trữ Sự thật Căn bản cung cấp cấu trúc tài liệu phức hợp tích hợp và mô hình mô tả nội dung để nghiên cứu các bộ sưu tập tạp chí và báo thời kỳ in được số hóa. Một cú ngã tại nhà vào tháng 7 năm 2020 đã dẫn đến chấn thương cột sống nghiêm trọng làm ảnh hưởng nghiêm trọng đến sự khéo léo và khả năng vận động bằng tay của anh ấy.

Jim đã may mắn được cung cấp quyền truy cập vào Cộng đồng Truy cập sớm Công nghệ Copilot của GitHub trong những nỗ lực ban đầu của anh ấy để quay lại làm việc với các hoạt động phát triển công cụ dựa trên Python mà anh ấy quan tâm nghiên cứu chính. Sau khi trải nghiệm tác động tích cực đáng kể của GitHub Copilot đối với năng suất phát triển của chính mình, anh ấy đã rất quan tâm đến việc thiết kế một chương trình nghiên cứu và hỗ trợ để điều tra và ghi lại việc sử dụng công nghệ hỗ trợ lập trình sáng tạo này cho các nhà phát triển khuyết tật.