“HeyGitHub!”, Pemikiran tentang Agensi dan Kopilot Percakapan

Dalam dua artikel terakhir saya yang lebih teknis untuk publikasi ini, saya membiarkan diri saya membayangkan menambahkan pemikiran deduktif "Sherlockean" ke dalam dialog kode suara #HeyGitHub antara #DisabledDevelopers dan "Rainman" GitHub yang brilian namun cerdas Pembuat kode kopilot. Saat menulis artikel ini, saya memulai pencarian-pencarian untuk metode dan implementasi kemajuan yang tersedia untuk umum dalam komunitas riset Machine-Learning yang dapat memberikan jenis dukungan yang diperlukan untuk mengimplementasikan percakapan pembuatan kode yang lebih bijaksana ini.

Untungnya saya menemukan bahwa ada sejumlah sub-komunitas penelitian Machine-Learning yang mengerjakan tantangan ini untuk mendukung proses berpikir yang lebih "mirip manusia", menggunakan konteks dan pengetahuan sebelumnya, sebagai pelengkap pengenalan pola brute-force dari LLM ( Performa Model Bahasa Besar ). Saya belajar tentang #CoT ( Chain of Thought ), prompt-sequencing , model-switching , dan agen di antara area eksplorasi dan pengembangan lainnya di domain Machine-Learning. Saya mulai mendapatkan pengalaman langsung menggunakan perpustakaan LangChain Python yang menarik dari Harrison Chase dan LangChainAIdeveloper. Banyak dari jejak remah roti yang saya ikuti ini dimulai dengan membaca artikel ikhtisar yang berwawasan, “The Near Future of AI is Action-Driven” , oleh John McDonnell .

Saya juga belajar tentang agenda besar-besaran yang didanai berlebihan yang sedang berlangsung di Microsoft — Project Bonsai — yang membawa solusi AI/ML ke tantangan otomatisasi robotika dan kontrol proses industri. Dalam ruang masalah dunia fisik ini, simulasi dan pelatihan manusia-in-the-loop sama pentingnya, jika tidak lebih penting, seperti penekanan pada pemodelan data dan metode ilmu data dalam domain aplikasi Machine-Learning yang lebih umum.

Fokus saya dalam artikel ini bukan untuk menggali lebih dalam tentang kemajuan SOTA ini, melainkan untuk berspekulasi sedikit tentang peran agen berbasis peran karena dapat diterapkan pada platform #HeyGitHub/Copilot untuk mendukung pengembangan perangkat lunak bukan hanya oleh #DisabledDevelopers dan #DisabledSTEMstudents , tetapi oleh semua calon pengembang menggunakan #HeyGitHub/Copilot sebagai pengganda produktivitas pengembangan.

Refleksi Wayback pada Agensi dalam Model Bisnis yang Dapat Dijalankan

Dalam artikel Metamodel Subgraph saya di seri #HeyGitHub ini, saya memberikan gambaran singkat tentang keterlibatan saya dalam skunkworks yang mengembangkan kerangka kerja berbasis Smalltalk yang mendukung komposisi dinamis dan pembuatan aplikasi EBM , Model Bisnis yang Dapat Dijalankan .

Awal-pertengahan 1990-an melihat serangkaian metode berbasis model untuk pengembangan perangkat lunak dan rekayasa proses bisnis. Salah satu benang merah yang kuat di era ini adalah gerakan BPR atau Business Process Reengineering . Dalam layanan konsultasi IBM, metode populer yang digunakan pada saat itu disebut LOVEM , Model Perusahaan Garis Visibilitas atau terkadang, Metode Rekayasa Garis Visibilitas . Inti dari metode ini adalah format diagram menggunakan "swim lanes" untuk model proses bisnis.

Jalur renang LOVEM mewakili peran yang dapat dimainkan oleh manusia atau mesin (proses perangkat lunak AKA). Terinspirasi oleh buku David Gelernter tahun 1993, “Mirror Worlds: or the Day Software Puts the Universe in a Shoebox…How It Will Happen and What It Will Artinya.” , rekan saya dan saya di IBM's Object Technology Practice membayangkan kerangka objek Smalltalk yang dapat digunakan untuk menyusun dan menjalankan model LOVEM berbasis peran ini. Kerangka kerja EBM , Executable Business Model , kami didasarkan pada "kit konstruksi" metamodel dari kelas objek yang sangat mirip dengan model Kelas UML ini dari aktivitas awal dalam kelahiran kembali pasca-kanker saya sebagai Ilmuwan Warga Humaniora Digital:

Aspek model EBM yang ingin saya soroti dalam artikel ini adalah kelompok kelas yang terlihat di kotak merah di pojok kiri bawah diagram ini. Ketiga kelas ini — Orang atau Agen sebagai Aktor — berpartisipasi dalam proses yang digerakkan oleh Tujuan , berbasis Peran . Dengan cara ini kerangka kerja EBM kami menerapkan konsep Agensi yang penting untuk metode proses bisnis LOVEM. Penerapan Agensi metamodel kami, seperti yang Anda duga, didorong oleh inspirasi Dunia Cermin kami.

Dalam bukunya, Gelernter mengajak pembaca melakukan eksperimen pemikiran yang mengatakan, memparafrasekan di sini, “Bayangkan jika kita membangun simulasi perangkat lunak terperinci dari sistem kompleks kita yang sedang bekerja di Dunia Nyata. Begitu kita menjalankan simulasi ini, bayangkan apa yang akan terjadi jika kita mengambil semua input dan output feed dari simulasi kita dan menghubungkannya ke feed sebenarnya di sistem Dunia Nyata ini. Pada saat itu, model perangkat lunak kami akan berhenti menjadi simulasi dan mulai menjadi tampilan kepala, atau tampilan dasbor, di Dunia Nyata…” atau yang disebut Gelernter Mirror Worlds .

Kami menerapkan pendekatan ini ke Agensi dalam kerangka kerja berbasis metamodel EBM kami sehingga objek Agen dapat diimplementasikan sebagai proksi perangkat lunak untuk Orang sebagai Aktor Peran dalam model LOVEM yang dapat dieksekusi. Desain ini memberi kami dua fitur penting yang konsisten dengan inspirasi Dunia Cermin kami. Pertama, selama sesi keterlibatan konsultasi dengan eksekutif pelanggan, kami dapat meminta UKM, pakar materi pokok pelanggan, duduk di depan laptop berjaringan di ruang konferensi untuk berinteraksi dan memvalidasi model simulasi kami yang terus berkembang. Selama sesi ini, kami dapat mengisi instance model pelaksana dengan proksi perangkat lunak Agen sim-actor untuk melakukan semua Peran lain dalam proses bisnis yang dimodelkan.

Setelah UKM pelanggan yakin bahwa kami telah menerapkan proses bisnis ini dalam simulasi EBM kami, kami dapat — dengan cara yang benar-benar terinspirasi dari Mirror Worlds — cukup menghubungkan model ini sebagai sistem yang diterapkan dalam bisnis pelanggan yang sebenarnya. Selama proses pemasangan ini, kami akan menentukan Peran mana yang akan dimainkan oleh Orang — menggunakan tampilan EBM yang dihasilkan secara dinamis pada model yang dilihat oleh pengguna sebagai aplikasi perangkat lunak tipikal — atau oleh Peran yang akan dimainkan oleh proxy perangkat lunak Agen Aktor di pelanggan proses bisnis.

Merefleksikan waktu itu hampir tiga puluh tahun yang lalu, hari-hari yang saya habiskan untuk bekerja sebagai pemimpin pemikiran/pengembang di skunkworks EBM ini adalah beberapa pengalaman yang paling menggembirakan dalam karir kerja saya.

Spekulasi Ke Depan Tentang Agensi di Platform #HeyGitHub/Copilot

Jadi, bagaimana konsep Agensi dapat berkontribusi pada peningkatan kemampuan pendekatan seperti Rantai Pemikiran, pengurutan cepat, dan pengalihan model sebagai bagian dari tumpukan teknologi yang berkembang yang berkontribusi pada implementasi layanan #HeyGitHub/Copilot GitHub?

Tanpa niat untuk contoh kaku atau non-sepele, kita dapat menerapkan konsep Agensi Berbasis Peran ini dari pengalaman EBM saya ke desain solusi layanan #HeyGitHub/Copilot seperti dalam diagram jalur berenang sederhana ini:

Apa yang kita lihat dalam diagram yang terlalu sederhana ini adalah sekelompok empat jalur berenang di lapisan atas yang secara aktif berinteraksi sebagai Manusia dan tiga Agen perangkat lunak yang percakapannya mengarah ke generasi akhirnya dalam Peran IDE yang "bodoh"/data transcriptionist-like aplikasi dan file sumber (memori). Diagram sederhana ini memperjelas bahwa tantangan luar biasa yang kami hadapi adalah bagaimana menyuntikkan "kecerdasan Sherlockean" ke dalam percakapan berbasis Agen sebelum memanfaatkan sebaik-baiknya Rainman-Agent Copilot LLM kami yang cerdas.

Bayangkan persyaratan desain kami adalah, misalnya, membuat Agen bot Call Center telepon yang berfungsi tinggi. Dalam hal ini, repertoar fleksibel permintaan berbasis template yang dapat dipilih secara dinamis untuk hasil berorientasi tujuan mungkin cukup untuk digunakan. Tetapi berhasil bertindak sebagai Programmer Pasangan non-manusia (Agen "teman"), seperti yang sering ditegaskan GitHub dalam menggambarkan layanan Copilotnya, Pendengar #HeyGitHub dan Agen Dialog CoT perlu mengimplementasikan kecerdasan yang jauh lebih kompleks daripada bot Call Center yang dapat ditulisi . percakapan.

Misalnya, tantangan untuk #HeyGitHub/Copilot membantu Pengembang membuat UI/UX — antarmuka pengguna dan pengalaman interaktif — untuk sebuah aplikasi. Ada sejumlah kerangka kerja UI/UX luar biasa yang mungkin digunakan oleh Pengembang. Copilot Rainman-savant kami telah melihat banyak sekali contoh kerangka kerja ini dalam pelatihan model dasar Copilot untuk menyempurnakan bakat pembuat kodenya. Tetapi mampu memberikan saran kode berdasarkan pengenalan pola yang diambil dari pengalaman pelatihannya tidak memberi Copilot pemahaman yang mendasari arsitektur kerangka kerja, praktik terbaik, dan panduan antarmuka/interaksi pengguna yang dibawa oleh Pengembang manusia yang kompeten untuk peran berpartisipasi dalam kemitraan Pasangan Pemrograman.

Pertimbangkan contoh pembungkus wxPython pada kerangka kerja C++ wxWidgets yang terhormat . Tidak ada jumlah perjalanan acak melalui segudang repositori kode yang dapat diakses publik yang akan mengungkapkan sejauh mana pengetahuan yang diberikan dengan melakukan penyelaman mendalam ke situs web dokumentasi online yang sangat baik dihttps://docs.wxpython.org/. Dekomposisi NLP, perumusan topik-pemodelan/penjumlahan pada konten situs web ini tidak akan cukup untuk memberikan pengetahuan pengembang-manusia ke dalam percakapan #HeyGitHub/Copilot<>Pengembang.

Jadi Ke Mana Kita Pergi Dari Sini?

Saya berharap saya memiliki pengetahuan domain yang cukup untuk menyarankan desain solusi spesifik dan jalur pengembangan ke depan untuk menghasilkan teknologi yang diperlukan untuk membawa kinerja LLM penghasil kode saat ini ke "tingkat selanjutnya" yang terkenal itu. Meskipun peta jalan lengkap ke depan belum ditulis, ada beberapa asumsi yang dapat kami buat tentang langkah selanjutnya. Kami dapat mengantisipasi bahwa penting bagi agen Pendengar #HeyGitHub untuk dapat membedakan antara input suara Pengembang yang memerlukan penyerahan ke CoT Dialoger untuk interaksi lebih lanjut, atau diteruskan dalam bentuk tekstual ke Copilot LLM untuk pembuatan saran kode.

Tantangan berat di depan kita adalah merangkum struktur informasi dan makna semantik dari seni dan ilmu rekayasa perangkat lunak sedemikian rupa sehingga CoT Dialoguer dapat bekerja secara kredibel sebagai mitra Pasangan Pemrograman sejati. Teknologi untuk memenuhi tantangan ini kemungkinan besar akan datang dari aktivitas penelitian terdepan di sekitar Rantai Pemikiran, pemilihan/pengurutan cepat, pergantian model, dan pembelajaran/pelatihan penguatan manusia-dalam-putaran.

Beberapa terobosan dalam ruang solusi "kecerdasan Sherlockean" ini akan melibatkan pengkodean inovatif yang brilian oleh para insinyur penelitian Pembelajaran Mesin. Saya juga percaya, bagaimanapun, bahwa kontribusi non-sepele untuk tantangan ini akan datang dari desain dan pengembangan dataset model referensi Ground Truth yang efektif yang akan berfungsi sebagai materi kurikuler pelatihan untuk model khusus domain untuk bekerja bahu-membahu dalam sebuah konteks peralihan model dengan Copilot Large Language Model dasar yang terus berkembang. Contoh dari kumpulan data referensi yang muncul ini adalah desain Metamodel Subgraph Ground Truth Storage yang telah saya kejar melalui penelitian Humaniora Digital saya dan membayangkannya di sini dalam seri artikel #HeyGitHub saya.

Tetapi mengembangkan format dataset referensi Ground Truth standar yang berorientasi Agen tidak akan cukup untuk membangkitkan dialog Sherlockean yang saya bayangkan antara Pengembang manusia dan mitra Pemrograman Pasangan Copilot berbasis ML. Alih-alih, kumpulan data referensi Ground Truth dari pengetahuan domain ini perlu berfungsi sebagai bahan instruksional dalam simulasi pelatihan model skenario pengguna-interaktif yang menyempurnakan kemampuan agen Dialog CoT untuk terlibat dalam percakapan kolaboratif dengan mitra Pengembang manusianya. Sesi simulasi ini dapat memampatkan waktu dan tanpa lelah mengejar penyempurnaan penggunaan pengetahuan domain CoT Dialoguer yang efektif.

Sama seperti kami sekarang menggunakan praktik terbaik pemodelan data untuk menghasilkan kumpulan data pelatihan untuk aplikasi ML intensif data saat ini, kami juga akan dapat menghasilkan pengalaman simulasi berbasis Agen yang memungkinkan aplikasi berbasis pengetahuan kami untuk melatih dan menyempurnakan model seperti yang dibayangkan layanan #HeyGitHub/Copilot di masa mendatang. Sebagai bagian dari lingkungan pelatihan simulasi seperti Dunia Cermin ini , pertukaran percakapan yang menghalangi model #HeyGitHub CoT Dialoguer dalam pelatihan akan muncul ke Supervisor manusia-dalam-putaran yang pelatihan responsnya akan mendorong dan memperkuat perilaku model yang sesuai.

Sepasang Lebah di Topi di GitHub dan Microsoft

Pada titik ini penerbangan saya untuk membayangkan jalan ke depan tidak lebih dari mimpi demam dari Ilmuwan Warga Digital Humaniora indie dan Pengembang Penyandang Cacat. Tetapi jika saya menghapus topi konsultan IBM lama saya untuk menempatkan beberapa lebah di topi di GitHub dan Microsoft, saya tahu apa yang akan saya sarankan…

Pertama, saya tidak bisa tidak mengatakan, jika saya adalah bagian dari manajemen GitHub, saya akan menawarkan saya pekerjaan sebagai anggota tim riset GitHub Next. Dalam posisi itu saya akan bekerja dengan rajin pada ide-ide yang telah saya tulis dalam rangkaian artikel #HeyGitHub ini * .

Selanjutnya, setelah kita memiliki Proof of Concept untuk dataset pelatihan model pengetahuan domain Metamodel Subgraph Ground Truth, saya akan melobi untuk mendedikasikan sebagian dari Akselerator GitHub yang baru diumumkan atau Dana GitHub M12 untuk memberikan tunjangan atau pendanaan proyek awal untuk kinerja tinggi , ahli pengembang Open Source untuk membuat kumpulan dataset pelatihan model berorientasi Agen khusus domain ini. Penekanan khusus harus dipertimbangkan untuk mengembangkan kumpulan data pelatihan berbasis metamodel kerangka kerja UI/UX.

Mengapa UI/UX framework-spesifik kumpulan data pengetahuan domain? Karena "binatang buas" ini seringkali berukuran besar, arsitektur kompleks dengan penyesuaian parameter yang terlalu detail. Dan untuk sebagian besar skenario proyek pengembangan, menyusun UI aplikasi dan interaksi penggunanya adalah aktivitas yang diperlukan yang membutuhkan waktu dan upaya jauh dari pengkodean solusi ke ruang masalah proyek yang disediakan UI/UX aplikasi sederhana untuk pengguna akhir proyek. Menyediakan pembuatan kode framework UI/UX yang kuat dengan input suara di #HeyGitHub/Copilot kemudian dapat dibandingkan dengan memiliki framework UI/UX yang memiliki aplikasi pembuat antarmuka WYSIWYG yang kuat.

Sebagai rekomendasi yang lebih luas dan strategis, saya akan mendorong kontak pemikiran terkemuka dari GitHub Next dan Microsoft Project Bonsai untuk membentuk Komite Kolaborasi. Tujuan grup ini adalah untuk mengeksplorasi cara GitHub dapat memanfaatkan praktik terbaik dan pengalaman dari komitmen ekstensif Microsoft yang telah dimasukkan ke dalam pasar otomasi proses robotik dan industri.

Dan Semoga Bersembunyi Di Atas Cakrawala

Melihat lebih jauh ke Jalan Raya Inovasi sambil mengenakan kacamata berwarna mawar dan kaus berslogan optimis, kemana tujuan agenda penelitian ini? Jika, setelah membuat referensi Metamodel Subgraph khusus domain dalam jumlah terbatas, dataset Ground Truth, dan meluangkan waktu dan upaya untuk melatih model Pembelajaran Mesin untuk memainkan peran agen Dialog CoT di sejumlah domain, suatu hari nanti kita mungkin akan melihat sistem Dialog menunjukkan perilaku yang muncul .

Maksud saya, model Agen Dialog CoT dapat memahami struktur umum dan penggunaan pengetahuan domain dengan sangat baik sehingga tidak harus dimuat sebelumnya dengan model referensi khusus domain baru agar berguna dalam berpartisipasi dalam konteks baru. Pada tingkat fungsi ini, sistem multi-model #HeyGitHub/Copilot yang jauh di masa depan dapat dengan mudah terlibat dalam percakapan pembelajaran mandiri dengan mitra Pemrograman Pasangan Pengembangnya untuk membuat dan memvalidasi model pengetahuan domain barunya sendiri. Melalui proses ini, layanan #HeyGitHub/Copilot dapat menjadi kolaborator tingkat sejawat yang benar-benar serbaguna dalam desain dan pengembangan sistem perangkat lunak penting.

Di Penutup

Setelah selamat dari pertempuran kanker saya dan belajar untuk mengatasi tantangan ketangkasan dan mobilitas dari cedera tulang belakang saya, saya sangat ingin memiliki kesempatan untuk Mengalahkan Reaper dengan berkontribusi pada gelombang inovasi luar biasa yang menarik dalam desain dan pengembangan. perangkat lunak seperti yang dibayangkan dalam seri artikel #HeyGitHub saya. ✌️

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

* PS Agar jelas, selain minat saya untuk mengejar agenda penelitian yang dibayangkan dalam rangkaian artikel #HeyGitHub ini, saya tetap berkomitmen dengan penuh semangat untuk mengimplementasikan agenda Copilot sebagai #AssistiveTechnology melalui studi penelitian dan program dukungan untuk #DisabledDevelopers dan # DisabledSTEMstudents dijelaskan dalam sebagian besar artikel dalam publikasi Medium ini.

Jim Salmons adalah Ilmuwan Warga Digital Humaniora berusia tujuh puluh satu tahun pasca-kanker. Penelitian utamanya difokuskan pada pengembangan format Ground Truth Storage yang menyediakan struktur dokumen kompleks yang terintegrasi dan model penggambaran konten untuk studi koleksi digital majalah dan surat kabar era cetak. Jatuh Juli 2020 di rumah mengakibatkan cedera tulang belakang yang parah yang secara dramatis membahayakan ketangkasan dan mobilitas manualnya.

Jim beruntung diberi akses ke Komunitas Akses Awal GitHub Copilot Technology selama upaya awalnya untuk kembali mengerjakan aktivitas pengembangan alat berbasis Python dari minat penelitian utamanya. Setelah mengalami dampak positif yang dramatis dari GitHub Copilot pada produktivitas pengembangannya sendiri, dia menjadi sangat tertarik untuk merancang program penelitian dan dukungan untuk menyelidiki dan mendokumentasikan penggunaan teknologi bantu pemrograman inovatif ini untuk digunakan oleh pengembang yang cacat.