“HeyGitHub!” ความคิดเกี่ยวกับเอเจนซีและนักบินร่วมสนทนา

ในบทความเชิงเทคนิคอีกสองบทความล่าสุดของฉันสำหรับเอกสารเผยแพร่นี้ ฉันปล่อยให้ตัวเองจินตนาการไปเองโดยเพิ่มความคิดแบบนิรนัย “Sherlockean” เข้าไปใน บทสนทนาการเข้ารหัสเสียง #HeyGitHubระหว่าง#DisabledDevelopersและ GitHub “Rainman” ที่ฉลาดแต่ดูเหมือนคนฉลาด เครื่องสร้างโค้ด Copilot ในขณะที่เขียนบทความเหล่านี้ ฉันเริ่มค้นหาวิธีการและการใช้งานความก้าวหน้าที่เปิดเผยต่อสาธารณะในชุมชนการวิจัยแมชชีนเลิร์นนิงที่สามารถให้การสนับสนุนที่จำเป็นในการดำเนินการสนทนาการสร้างรหัสที่รอบคอบมากขึ้นเหล่านี้

ฉันพบว่ามีชุมชนย่อยการวิจัยการเรียนรู้ด้วยเครื่องจำนวนมากที่ทำงานเกี่ยวกับความท้าทายเหล่านี้เพื่อสนับสนุนกระบวนการคิดที่ "เหมือนมนุษย์" มากขึ้น โดยใช้บริบทและความรู้เดิม เป็นส่วนเสริมของการจดจำรูปแบบกำลังดุร้ายของLLM ( โมเดลภาษาขนาดใหญ่ ) ประสิทธิภาพ ฉันได้เรียนรู้เกี่ยวกับ#CoT ( ห่วงโซ่แห่งความคิด ) การจัดลำดับ ทันที การสลับโมเดลและเอเจนต์รวมถึงการสำรวจและการพัฒนาอื่นๆ ในโดเมน แมชชีนเลิร์นนิง ฉันเริ่มได้รับประสบการณ์โดยตรงโดยใช้ ไลบรารี LangChain Python ที่น่าตื่นเต้นจากHarrison ChaseและLangChainAIนักพัฒนา เส้นทางเบรดค รัมบ์เหล่านี้หลายเส้นทางที่ฉันติดตามเริ่มต้นจากการอ่านบทความภาพรวมเชิงลึก“อนาคตอันใกล้ของ AI คือการดำเนินการที่ขับเคลื่อนด้วย”โดยJohn McDonnell

ฉันยังได้เรียนรู้เกี่ยวกับวาระการประชุมขนาดใหญ่ที่ได้รับทุนสนับสนุนสูงซึ่งกำลังดำเนินการอยู่ที่ Microsoft — Project Bonsai — นั่นคือการนำโซลูชัน AI/ML มาสู่ความท้าทายของระบบอัตโนมัติของหุ่นยนต์และการควบคุมกระบวนการทางอุตสาหกรรม ในพื้นที่ปัญหาทางกายภาพนี้การจำลองและการฝึกสอนแบบมนุษย์ในลูปมีความสำคัญพอๆ กับการเน้นการสร้างแบบจำลอง ข้อมูล และวิธีการวิทยาศาสตร์ข้อมูลในโดเมนแอปพลิเคชันแมชชีนเลิร์นนิงทั่วไป

ความสนใจของฉันในบทความนี้ไม่ใช่การเจาะลึกลงไปในความก้าวหน้าของ SOTA เหล่านี้ แต่เป็นการคาดเดาเล็กน้อยเกี่ยวกับบทบาทของหน่วยงานตามบทบาทเนื่องจากอาจนำไปใช้กับ แพลตฟอร์ม #HeyGitHub/Copilotเพื่อสนับสนุนการพัฒนาซอฟต์แวร์ ไม่ใช่แค่โดย#DisabledDevelopersและ#DisabledSTEMstudentsแต่โดยนักพัฒนาในอนาคตทั้งหมดที่ใช้ #HeyGitHub/Copilot เป็นตัวคูณประสิทธิภาพการพัฒนา

ภาพสะท้อนกลับด้านเอเจนซี่ในรูปแบบธุรกิจที่สามารถดำเนินการได้

ในบทความMetamodel Subgraph ของฉัน ใน ซีรีส์ #HeyGitHub นี้ ฉันได้ให้ภาพรวมโดยย่อเกี่ยวกับการมีส่วนร่วมของฉันใน skunkworks ที่กำลังพัฒนาเฟรมเวิร์กที่ใช้ Smalltalk ซึ่งสนับสนุนองค์ประกอบแบบไดนามิกและการสร้างแอปพลิเคชันของEBM , Executable Business Models

ช่วงต้นถึงกลางทศวรรษที่ 1990 มีวิธีการที่ขับเคลื่อนด้วยแบบจำลองมากมายสำหรับทั้งการพัฒนาซอฟต์แวร์และวิศวกรรมกระบวนการทางธุรกิจ หัวข้อหนึ่งที่แข็งแกร่งในยุคนี้คือBPRหรือBusiness Process Reengineeringการเคลื่อนไหว ภายในบริการให้คำปรึกษาของ IBM วิธีที่นิยมใช้กันในขณะนั้นเรียกว่าLOVEMซึ่งเป็นLine Of Visibility Enterprise Modelหรือบางครั้ง เรียก ว่าLine Of Visibility Engineering Method ศูนย์กลางของวิธีนี้คือรูปแบบไดอะแกรมที่ใช้ "ช่องทางว่ายน้ำ" สำหรับแบบจำลองกระบวนการทางธุรกิจ

เลนว่ายน้ำของ 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” เพื่อนร่วมงานของฉันและฉันใน Object Technology Practice ของ IBM ได้จินตนาการถึงSmalltalk object framework ที่สามารถใช้ในการเขียนและดำเนินการโมเดล LOVEM ตามบทบาทเหล่านี้ กรอบงาน EBM , Executable Business Modelของเราอิงจาก metamodel “construction kit” ของคลาสอ็อบเจกต์ที่ดูคล้ายกับโมเดลคลาส UML นี้มากตั้งแต่เริ่มต้นกิจกรรมในการเกิดใหม่หลังมะเร็งของฉันในฐานะนักวิทยาศาสตร์พลเมืองดิจิทัลด้านมนุษยศาสตร์:

แง่มุมของโมเดล EBM ของเราที่ฉันต้องการเน้นในบทความนี้คือคลัสเตอร์ของคลาสที่เห็นในกล่องสีแดงที่มุมซ้ายล่างของไดอะแกรมนี้ ทั้งสามคลาสนี้ — บุคคลหรือตัวแทนในฐานะ ผู้ ดำเนิน การ — มีส่วนร่วมในกระบวนการที่ขับเคลื่อนด้วยเป้าหมาย และ อิงตามบทบาท ด้วยวิธีนี้ กรอบงาน EBM ของเราได้นำแนวคิดของหน่วยงานที่จำเป็นต่อวิธีกระบวนการทางธุรกิจของ LOVEM การนำ Agency ไปใช้ในเมตาโมเดลของเราเป็นไปตามที่คุณคาดไว้ ซึ่งได้แรงหนุนจากแรงบันดาลใจMirror Worlds ของเรา

ในหนังสือของเขา เกลเลิร์นเทอร์นำผู้อ่านไปทดลองทางความคิดโดยถอดความว่า"ลองนึกภาพถ้าเราสร้างการจำลองซอฟต์แวร์โดยละเอียดของระบบที่ซับซ้อนของเราที่ทำงานในโลกแห่งความจริง เมื่อเราฮัมเพลงจำลองเหล่านี้แล้ว ลองจินตนาการว่าจะเกิดอะไรขึ้นหากเรานำฟีดอินพุตและเอาต์พุตทั้งหมดของการจำลองของเราไปเชื่อมต่อกับฟีดจริงในระบบโลกแห่งความจริงเหล่านี้ เมื่อถึงจุดนั้น โมเดลซอฟต์แวร์ของเราจะเลิกเป็นเพียงการจำลองและเริ่มเป็นการแสดงผลล่วงหน้าหรือมุมมองแดชบอร์ดในโลกแห่งความจริง…”หรือที่ Gelernter เรียกว่าMirror Worlds

เราใช้แนวทางนี้กับเอเจนซีในเฟรมเวิร์กที่อิงตามโมเดลเมตาของ EBM ดังนั้นออบเจ็กต์ Agent จึงสามารถนำไปใช้เป็นพร็อกซีซอฟต์แวร์สำหรับบุคคลในฐานะนักแสดงของบทบาทในโมเดล LOVEM ที่ดำเนินการได้ การออกแบบนี้ทำให้เรามีคุณลักษณะสำคัญสองอย่างที่สอดคล้องกับแรงบันดาลใจ ของ Mirror Worlds ประการแรก ในระหว่างการปรึกษาหารือกับผู้บริหารลูกค้า เราสามารถให้ SME ซึ่งเป็นผู้เชี่ยวชาญเฉพาะเรื่องของลูกค้า นั่งที่แล็ปท็อปที่เชื่อมต่อเครือข่ายในห้องประชุมเพื่อโต้ตอบและตรวจสอบความถูกต้องของแบบจำลองการจำลองที่พัฒนาขึ้นของเรา ในระหว่างเซสชันเหล่านี้ เราสามารถเติมอินสแตนซ์โมเดลที่กำลังดำเนินการด้วยพร็อกซีซอฟต์แวร์ตัวแทนของ sim-actor เพื่อดำเนินการตามบทบาทอื่นๆ ทั้งหมดในกระบวนการทางธุรกิจแบบจำลอง

เมื่อ SME ของลูกค้ามั่นใจแล้ว เราได้ตอกย้ำกระบวนการทางธุรกิจเหล่านี้ในการจำลอง EBM ของเรา เราสามารถทำได้ - ใน รูปแบบที่ได้รับแรงบันดาลใจจาก Mirror Worlds ที่แท้จริง - เพียงแค่เชื่อมต่อโมเดลเหล่านี้เป็นระบบที่ปรับใช้ในธุรกิจของลูกค้าจริง ในระหว่างกระบวนการเชื่อมต่อนี้ เราจะพิจารณาว่าบุคคลควรเล่นบทบาทใด โดยใช้มุมมอง EBM ที่สร้างขึ้นแบบไดนามิกบนโมเดลที่ผู้ใช้มองเห็นเป็นแอปพลิเคชันซอฟต์แวร์ทั่วไป หรือโดยบทบาทที่จะแสดงโดยพร็อกซีซอฟต์แวร์ Agent Actors ในลูกค้า กระบวนการทางธุรกิจ.

เมื่อนึกถึงช่วงเวลานั้นเมื่อเกือบ 30 ปีที่แล้ว ช่วงเวลาที่ผมทำงานเป็นผู้นำทางความคิด/นักพัฒนาในผลงานสกั๊งค์ EBM นี้เป็นประสบการณ์ที่น่าตื่นเต้นที่สุดในอาชีพการทำงานของผม

การคาดเดาล่วงหน้าเกี่ยวกับเอเจนซีในแพลตฟอร์ม #HeyGitHub/Copilot

ดังนั้น แนวคิดของเอเจนซีอาจมีส่วนช่วยในการใช้ประโยชน์จากความสามารถของแนวทางต่างๆ เช่น ห่วงโซ่แห่งความคิด การจัดลำดับแบบทันที และการสลับโมเดล ซึ่งเป็นส่วนหนึ่งของกองเทคโนโลยีที่มีการพัฒนาซึ่งเอื้อต่อการนำบริการ #HeyGitHub/Copilot ของ GitHub ไปใช้ได้อย่างไร

เราอาจใช้แนวคิดของหน่วยงานตามบทบาทนี้จากประสบการณ์ EBM ของฉันกับการออกแบบโซลูชันของบริการ #HeyGitHub/Copilot โดยไม่ได้มีเจตนาจะเข้มงวดหรือเป็นตัวอย่างเล็กน้อย

สิ่งที่เราเห็นในไดอะแกรมที่เรียบง่ายเกินไปนี้คือกลุ่มของเลนว่ายน้ำสี่เลนในชั้นบนที่โต้ตอบอย่างแข็งขันในฐานะมนุษย์และตัวแทนซอฟต์แวร์สามตัวที่การสนทนานำไปสู่การสร้างในที่สุดในบทบาทของ "โง่" / ผู้ถอดความข้อมูลของ IDE แอพและไฟล์ต้นฉบับ (หน่วยความจำ) แผนภาพง่ายๆ นี้ทำให้ชัดเจนว่าความท้าทายอันยิ่งใหญ่ที่เรากำลังเผชิญอยู่คือวิธีใส่ "Sherlockean smarts" ลงในการสนทนาที่อิงกับเจ้าหน้าที่ก่อนที่จะใช้ประโยชน์จาก Rainman-Agent Copilot LLM ที่เหมือนนักปราชญ์ของเราให้เกิดประโยชน์สูงสุด

ลองนึกภาพความต้องการในการออกแบบของเรา เช่น การสร้าง Call Center bot Agent ทางโทรศัพท์ที่มีประสิทธิภาพสูง ในกรณีนี้ ทางเลือกที่ยืดหยุ่นของการแจ้งเตือนตามเทมเพลตที่สามารถเลือกได้แบบไดนามิกสำหรับผลลัพธ์ที่มุ่งเน้นเป้าหมายอาจเพียงพอสำหรับการปรับใช้ แต่ประสบความสำเร็จในการทำหน้าที่เป็น Pair Programmer ที่ไม่ใช่มนุษย์ (ตัวแทน “บัดดี้”) ดังที่ GitHub มักจะอ้างในการอธิบายบริการ Copilot ของตน#HeyGitHub ListenerและCoT Dialoguer Agents จะต้องนำระบบอัจฉริยะที่ซับซ้อนกว่าบอท Call Center ที่เขียนสคริปต์ได้มาใช้ การสนทนา.

ตัวอย่างเช่น ความท้าทายสำหรับ #HeyGitHub/Copilot ช่วยนักพัฒนาสร้าง UI/UX — ส่วนต่อประสานผู้ใช้และประสบการณ์เชิงโต้ตอบ — สำหรับแอปพลิเคชัน มีเฟรมเวิร์ก UI/UX ที่ยอดเยี่ยมจำนวนมากที่นักพัฒนาอาจใช้ Copilot ผู้เชี่ยวชาญ Rainman ของเราได้เห็นตัวอย่างมากมายของเฟรมเวิร์กเหล่านี้แล้วในการฝึกอบรมโมเดลพื้นฐานของ Copilot เพื่อปรับแต่งพรสวรรค์ในการสร้างโค้ด แต่การที่สามารถให้คำแนะนำโค้ดอย่างเป็นประโยชน์โดยอาศัยการจดจำรูปแบบที่มาจากประสบการณ์การฝึกอบรมนั้นไม่ได้ทำให้ Copilot มีความเข้าใจพื้นฐานของสถาปัตยกรรมเฟรมเวิร์ก แนวปฏิบัติที่ดีที่สุด และแนวทางส่วนติดต่อผู้ใช้/การโต้ตอบที่นักพัฒนาที่มีความสามารถนำมาสู่บทบาทของการมีส่วนร่วม ในการเป็นหุ้นส่วนโปรแกรมมิ่งแพร์

พิจารณาตัวอย่างwxPython wrapper บนเฟรมเวิร์กwxWidgets ของ C++ ไม่มีการสุ่มเดินผ่านคลังเก็บรหัสที่สาธารณชนเข้าถึงได้จำนวนมากจะเปิดเผยขอบเขตของความรู้ที่ได้รับจากการเจาะลึกเข้าไปในเว็บไซต์เอกสารออนไลน์ที่ยอดเยี่ยมที่https://docs.wxpython.org/. จำนวนของการแยกย่อย NLP การสร้างแบบจำลองหัวข้อ/การสรุปรวมในเนื้อหาของเว็บไซต์นี้จะเพียงพอที่จะให้ความรู้แก่นักพัฒนาที่เป็นมนุษย์ใน #HeyGitHub/Copilot<>การสนทนาสำหรับนักพัฒนา

แล้วเราจะไปจากที่นี่ที่ไหน?

ฉันหวังว่าฉันจะมีความรู้ด้านโดเมนมากพอที่จะแนะนำการออกแบบโซลูชันเฉพาะและเส้นทางการพัฒนาเพื่อผลิตเทคโนโลยีที่จำเป็นในการนำประสิทธิภาพของ LLM ที่ใช้สร้างโค้ดในปัจจุบันไปสู่ ​​"ระดับถัดไป" ที่เป็นที่เลื่องลือ แม้ว่าแผนงานทั้งหมดข้างหน้าจะยังไม่ได้รับการเขียน แต่ก็มีข้อสันนิษฐานบางประการที่เราสามารถทำได้เกี่ยวกับขั้นตอนต่อไป เราคาดการณ์ได้ว่า ตัวแทน #HeyGitHub Listener จะมีความสำคัญใน การแยกแยะระหว่างการป้อนข้อมูลด้วยเสียงของนักพัฒนาที่ต้องส่งต่อไปยังCoT Dialoguerเพื่อการโต้ตอบอย่างรอบคอบเพิ่มเติม หรือส่งต่อในรูปแบบข้อความไปยังCopilot LLMสำหรับ การสร้างคำแนะนำรหัส

ความท้าทายที่น่ากลัวรออยู่ข้างหน้าคือการสรุปโครงสร้างข้อมูลและความหมายทางความหมายของศาสตร์และศิลป์ของวิศวกรรมซอฟต์แวร์ เพื่อให้CoT Dialoguerสามารถทำงานได้อย่างน่าเชื่อถือในฐานะคู่หูโปรแกรมมิ่งอย่างแท้จริง เทคโนโลยีสำหรับการรับมือกับความท้าทายนี้น่าจะมาจากแนวหน้าของกิจกรรมการวิจัยเกี่ยวกับห่วงโซ่แห่งความคิด การเลือก/การจัดลำดับโดยทันที การเปลี่ยนแบบจำลอง และการเรียนรู้/การฝึกสอนเสริมกำลังโดยมนุษย์

ความก้าวหน้าบางอย่างในพื้นที่โซลูชัน "Sherlockean smarts" นี้จะเกี่ยวข้องกับการเขียนโค้ดที่เป็นนวัตกรรมที่ยอดเยี่ยมโดยวิศวกรวิจัยการเรียนรู้ของเครื่อง อย่างไรก็ตาม ฉันยังเชื่อด้วยว่าการมีส่วนร่วมที่ไม่สำคัญสำหรับความท้าทายนี้จะมาจากการออกแบบและการพัฒนาชุดข้อมูลแบบจำลองอ้างอิงความจริง พื้นฐานที่มีประสิทธิภาพ ซึ่งจะทำหน้าที่เป็นสื่อหลักสูตรการฝึกอบรมสำหรับแบบจำลองเฉพาะโดเมนเพื่อทำงานร่วมกันใน บริบทการสลับโมเดลด้วย Copilot Large Language Model พื้นฐานที่พัฒนาตลอดเวลา ตัวอย่างของชุดข้อมูลอ้างอิงที่เกิดขึ้นใหม่เหล่านี้คือการ ออกแบบ Metamodel Subgraph Ground Truth Storageที่ฉันดำเนินการผ่านการวิจัยด้านมนุษยศาสตร์ดิจิทัล และจินตนาการไว้ที่นี่ในบทความชุด #HeyGitHub ของฉัน

แต่การพัฒนารูปแบบชุดข้อมูลอ้างอิง Ground Truth ที่เป็นมาตรฐานนั้นไม่เพียงพอที่จะทำให้เกิดบทสนทนาของ Sherlockean ที่ฉันมองเห็นระหว่างนักพัฒนาที่เป็นมนุษย์และหุ้นส่วนโปรแกรม Copilot Pair ที่ใช้ ML แต่ชุดข้อมูลอ้างอิง Ground Truth ของความรู้ในโดเมนจะต้องทำหน้าที่เป็นสื่อการสอนในการฝึกแบบจำลองสถานการณ์จำลองการโต้ตอบกับผู้ใช้ ซึ่งจะปรับแต่งความสามารถของตัวแทน CoT Dialoguer ในการมีส่วนร่วมในการสนทนาร่วมกับพันธมิตรนักพัฒนาที่เป็นมนุษย์ เซสชันการจำลองเหล่านี้สามารถบีบอัดเวลาและดำเนินการปรับปรุงการใช้ความรู้โดเมนอย่างมีประสิทธิภาพของ CoT Dialoguer อย่างไม่รู้จักเหน็ดเหนื่อย

เช่นเดียวกับที่ตอนนี้เราใช้แนวทางปฏิบัติที่ดีที่สุดในการสร้างโมเดลข้อมูลเพื่อสร้างชุดข้อมูลการฝึกอบรมสำหรับแอปพลิเคชัน ML ที่ใช้ข้อมูลจำนวนมากในปัจจุบัน เราจะสามารถสร้างประสบการณ์การจำลองตามเอเจนต์ที่ช่วยให้แอปพลิเคชันที่ขับเคลื่อนด้วยความรู้ของเราสามารถฝึกและปรับแต่งโมเดลได้เหมือนในจินตนาการ บริการ #HeyGitHub/Copilot ในอนาคต ในฐานะที่เป็นส่วนหนึ่งของ สภาพแวดล้อมการฝึกจำลองที่เหมือน โลกกระจกเงาการแลกเปลี่ยนการสนทนาที่ขัดขวางโมเดล #HeyGitHub CoT Dialoguer ที่อยู่ระหว่างการฝึกจะแสดงขึ้นต่อ Supervisor ที่เป็นมนุษย์ในลูป ซึ่งการฝึกสอนการตอบสนองจะกระตุ้นและเสริมสร้างพฤติกรรมของโมเดลที่เหมาะสม

ผึ้งคู่ใน Bonnets ที่ GitHub และ Microsoft

ณ จุดนี้ จินตนาการถึงหนทางข้างหน้าของฉันนั้นไกลเกินกว่าความฝันของนักวิทยาศาสตร์พลเมืองดิจิทัลและนักพัฒนาผู้พิการ แต่ถ้าฉันจะปัดฝุ่นหมวกที่ปรึกษาของ IBM เก่าออกเพื่อใส่ผึ้งสองสามตัวในหมวกที่ GitHub และ Microsoft ฉันรู้ว่าฉันจะแนะนำอะไร ...

ก่อนอื่น ฉันอดไม่ได้ที่จะพูดว่า ถ้าฉันเป็นส่วนหนึ่งของการจัดการ GitHub ฉันจะเสนองานให้ฉันในฐานะสมาชิกของทีมวิจัย GitHub Next ในตำแหน่งนั้น ฉันจะทำงานอย่างขยันขันแข็งกับแนวคิดที่ฉันเขียนเกี่ยวกับบทความ #HeyGitHub ชุดนี้*

ต่อไป เมื่อเรามี Proof of Concept สำหรับชุดข้อมูลการฝึกอบรมโมเดลความรู้ในโดเมน Metamodel Subgraph Ground Truth ฉันจะล็อบบี้เพื่ออุทิศส่วนหนึ่งของGitHub AcceleratorหรือM12 GitHub Fund ที่เพิ่งประกาศไปเมื่อเร็วๆ นี้ เพื่อมอบค่าตอบแทนหรือเงินทุนเริ่มต้นโครงการให้กับประสิทธิภาพสูง นักพัฒนาโอเพ่นซอร์สผู้เชี่ยวชาญเพื่อสร้างคอลเลกชันของชุดข้อมูลการฝึกอบรมแบบจำลองที่มุ่งเน้นตัวแทนเฉพาะโดเมนเหล่านี้ ควรพิจารณาความสำคัญเป็นพิเศษสำหรับการพัฒนาชุดข้อมูลการฝึกอบรมตามเมตาโมเดลเฉพาะเฟรมเวิร์ก UI/UX

เหตุใดจึงต้องมีชุดข้อมูลความรู้โดเมนเฉพาะเฟรมเวิร์ก UI/UX เนื่องจาก "สัตว์เดรัจฉาน" เหล่านี้มักมีขนาดใหญ่ สถาปัตยกรรมที่ซับซ้อนพร้อมการปรับแต่งรายละเอียดมากเกินไปโดยใช้พารามิเตอร์ที่ชาญฉลาด และสำหรับสถานการณ์โครงการพัฒนาส่วนใหญ่ การสร้าง UI ของแอปพลิเคชันและการโต้ตอบกับผู้ใช้เป็นกิจกรรมที่จำเป็นซึ่งต้องใช้เวลาและความพยายามในการเขียนโค้ดโซลูชันไปยังพื้นที่ปัญหาของโครงการที่ UI/UX ของแอปพลิเคชันทำให้พร้อมใช้งานสำหรับผู้ใช้ปลายทางของโครงการ การสร้างรหัสเฟรมเวิร์ก UI/UX ที่แข็งแกร่งด้วยการป้อนข้อมูลด้วยเสียงใน #HeyGitHub/Copilot เทียบได้กับการมีเฟรมเวิร์ก UI/UX ที่มีแอปพลิเคชันตัวสร้างอินเทอร์เฟซ WYSIWYG ที่ทรงพลัง

ในฐานะคำแนะนำเชิงกลยุทธ์ที่กว้างไกลยิ่งขึ้น ฉันขอแนะนำให้ผู้ติดต่อที่เป็นผู้นำทางความคิดจากGitHub Next และ Project Bonsaiของ Microsoft จัดตั้งคณะกรรมการการทำงานร่วมกัน จุดประสงค์ของกลุ่มนี้คือเพื่อสำรวจวิธีที่ GitHub สามารถใช้ประโยชน์จากแนวทางปฏิบัติที่ดีที่สุดและประสบการณ์ของความมุ่งมั่นที่กว้างขวางที่ Microsoft ได้มอบให้กับตลาดหุ่นยนต์และกระบวนการอัตโนมัติทางอุตสาหกรรม

และหวังว่าจะซุ่มซ่อนอยู่เหนือเส้นขอบฟ้า

มองไปไกลกว่านั้นบนทางหลวงนวัตกรรมขณะสวมแว่นตาสีกุหลาบและเสื้อยืดสโลแกนที่มองโลกในแง่ดี วาระการวิจัยนี้อาจนำไปสู่ที่ใด หากหลังจากสร้าง Metamodel Subgraph อ้างอิงชุดข้อมูล Ground Truth ในจำนวนจำกัด และสละเวลาและความพยายามในการฝึกโมเดล Machine Learning เพื่อเล่นบทบาทตัวแทน CoT Dialoguer ในหลายๆ โดเมน สักวันหนึ่งเราอาจได้เห็นระบบ Dialoguer แสดงพฤติกรรมที่เกิดขึ้น

จากสิ่งนี้ ฉันหมายความว่าโมเดล CoT Dialoguer Agent อาจเข้าใจโครงสร้างทั่วไปและการใช้ความรู้ในโดเมนได้ดีจนไม่ต้องโหลดโมเดลอ้างอิงเฉพาะโดเมนใหม่ล่วงหน้าเพื่อให้มีประโยชน์ในการเข้าร่วมในบริบทใหม่ ในระดับของฟังก์ชันนี้ ระบบหลายโมเดล #HeyGitHub/Copilot ในอนาคตอันไกลอาจเข้าร่วมในการสนทนาการเรียนรู้ด้วยตนเองกับพันธมิตรการเขียนโปรแกรมคู่นักพัฒนาเพื่อสร้างและตรวจสอบความถูกต้องของโมเดลความรู้โดเมนใหม่ของตนเอง ด้วยกระบวนการนี้ บริการ #HeyGitHub/Copilot อาจกลายเป็นผู้ทำงานร่วมกันระดับเดียวกันที่หลากหลายอย่างแท้จริงในการออกแบบและพัฒนาระบบซอฟต์แวร์ที่จำเป็น

ในการปิด

หลังจากรอดตายจากการต่อสู้กับโรคมะเร็งและเรียนรู้ที่จะรับมือกับความท้าทายด้านความคล่องแคล่วและการเคลื่อนไหวจากอาการบาดเจ็บที่ไขสันหลังของฉัน ฉันไม่รักอะไรมากไปกว่าการมีโอกาสเอาชนะ Reaper ด้วยการมีส่วนร่วมในนวัตกรรมอันน่าทึ่งในการออกแบบและพัฒนา ของซอฟต์แวร์ตามที่จินตนาการไว้ในบทความชุด #HeyGitHub ของฉัน ✌️

Happy Healthy Vibes จาก Colorado USA,
-: จิม :-

* ป.ล.เพื่อให้ชัดเจน นอกเหนือจากความสนใจของฉันที่จะติดตามวาระการวิจัยที่จินตนาการไว้ในชุดบทความ #HeyGitHub นี้ ฉันยังคงมุ่งมั่นอย่างแรงกล้าที่จะดำเนินการตามวาระของ Copilot ในฐานะ #AssistiveTechnology ผ่านการศึกษาวิจัยและโปรแกรมสนับสนุนสำหรับ #DisabledDevelopers และ # DisabledSTEMstudents ที่อธิบายไว้ในกลุ่มของบทความในสื่อสิ่งพิมพ์นี้

Jim Salmonsเป็นนักวิทยาศาสตร์พลเมืองดิจิทัลด้านมนุษยศาสตร์ยุคหลังมะเร็งอายุเจ็ดสิบเอ็ดปี งานวิจัยหลักของเขามุ่งเน้นไปที่การพัฒนารูปแบบ Ground Truth Storage ซึ่งให้โครงสร้างเอกสารที่ซับซ้อนแบบบูรณาการและรูปแบบการพรรณนาเนื้อหาสำหรับการศึกษาคอลเลกชันดิจิทัลของนิตยสารและหนังสือพิมพ์ในยุคสิ่งพิมพ์ การหกล้มที่บ้านในเดือนกรกฎาคม 2020 ส่งผลให้เกิดอาการบาดเจ็บที่ไขสันหลังอย่างรุนแรง ซึ่งทำให้ความคล่องแคล่วและความคล่องตัวแบบแมนนวลของเขาลดลงอย่างมาก

จิมโชคดีที่ได้รับการเข้าถึงชุมชน GitHub Copilot Technology Early Access ระหว่างความพยายามเริ่มต้นของเขาในการกลับไปทำงานในกิจกรรมการพัฒนาเครื่องมือที่ใช้ Python ตามความสนใจในงานวิจัยหลักของเขา เมื่อได้สัมผัสกับผลกระทบในเชิงบวกอย่างมากของ GitHub Copilot ต่อประสิทธิภาพการพัฒนาของเขาเอง เขาเริ่มสนใจในการออกแบบโปรแกรมการวิจัยและสนับสนุนเพื่อตรวจสอบและจัดทำเอกสารเกี่ยวกับการใช้เทคโนโลยีช่วยเหลือในการเขียนโปรแกรมที่เป็นนวัตกรรมใหม่นี้สำหรับใช้งานโดยนักพัฒนาที่ทุพพลภาพ