ย้อนกลับไปเมื่อซักสามสี่ปีที่แล้วราวๆปี 2021 สิ่งที่ทำให้ผมรู้จักกับ Generative AI เป็นอย่างแรกเลยคือ Github Copilot นี่แหละครับ ด้วยความสามารถอันแพรวพราวของการช่วยให้เหล่า Developer ทำงานได้อย่างสบายมากขึ้นด้วยการที่มีเจ้าปลาหมึกน้อยมานั่งข้างๆ Pair programming กับเรานี่มันแสนที่จะทำให้คุณภาพชีวิตของเราดีขึ้นกว่า Code Sugesstion ธรรมดาๆ แม้ว่าจะไม่ได้ไว้ใจน้องซักทีเดียว แต่แอบหนาวๆร้อนๆว่าอยู่เหมือนกันว่าอนาคตเราอาจจะไปสู่จุดที่มันอาจจะไม่ใช่ผู้ช่วยอีกต่อไปแต่อาจจะเป็นกัปตันแทนเราได้เลยทีเดียว
จริงๆแล้วการนำ AI มาใช้กับงานการพัฒนา Software เรามีทางเลือกอยู่มากมาย ไม่ว่าจะเป็น AWS CodeWhisperer (Amazon Q for Developer) / Gemini Code Assist (Google Duet AI for Developer) หรือไม่ว่าจะเป็นของฟรีๆที่เป็น Open Source / Open Weight Model ต่างๆแข่งกันขิงกันออกมามากมายทั้ง CodeLlama, CodeGemma, Mistral Codestral, DeepSeekCoder แล้วเอาไป Serve ผ่าน llamp.cpp / Ollama / LMStudio ใช้งานผ่าน IDE Extension ต่างๆที่มีให้เลือกสรร เช่น Continue.dev แต่วันนี้เราจะมาขอพูดถึงเจ้าแรกในตลาดอย่าง Github Copilot ก่อนแล้วกันตามมากันเลย
เริ่มแรกของ Github Copilot เป็นความร่วมมือกันของบริษัทในเคลือของ Microsoft นั่นก็คือ Github และ OpenAI ซึ่งทำให้เจ้า Copilot นั้นได้ใช้โมเดล Codex ของ OpenAI แบบ Exclusive ฉ่ำๆไปเลยจร้า ซึ่ง ณ เวลานั้นก็คงเปรียบเทียบ Codex ได้เท่ากับ GPT-3 ได้ (ChatGPT เปิดตัวด้วย GPT-3.5 โดยห่างกันซักสองปีน่าจะได้) แต่ ณ ปัจจุบัน (as of November 2023) เจ้า Github Copilot จะใช้ GPT-3.5-Turbo สำหรับ Code completion เพื่อ Latency ที่รวดเร็ว และใช้ GPT-4 สำหรับงาน Conversation AI เพื่อความ Robust ของการตอบ
ในระหว่างที่ทุกคนกำลังมีคำถามในหัวว่าเราจะมั่นใจกับการนำ Generative AI อย่าง Large Language Model (LLM) มาใช้ว่ามันจะให้ข้อมูลได้ถูกต้องไหมมันจะกาวหนักแค่ไหนกับงานเฉพาะทางนึงๆแล้ว ส่วนตัวผมเห็นว่าการนำมาใช้เป็น Copilot เพื่อช่วยในงาน Develop แล้วเป็น Usecase ที่ดีเอามากๆ เพราะการนำ AI เข้ามาทำให้เสมือนเรามีคู่คิดเพิ่มอีกคนในการแก้ไขปัญหาของการเป็น Software Engineer ทำงานเพียงคนเดียว (Pair Programming) อีกทั้งยังเพิ่ม Productivity ให้กับพวกเราได้เป็นอย่างมาก เพราะว่าไม่ว่าการที่เราจะนำมาใช้ให้มันเขียน Code หรือใดๆก็ตามแล้วทั้งหมดนี้จะถูกเหล่า Developer จะได้ตรวจทานคำตอบชั้นแรกก่อนเสมอ ซ้ำไปด้วย IDE Compiler/Intepreter ต่างๆที่คอยตรวจ Syntax ของ Programming Language และท้ายที่สุดสิ่งที่เหล่า Developer เราสร้างกันขึ้นมาเพื่อเป็น Safetynet อย่าง Unitest/Integration-test/E2E test ต่างๆ จะคอยช่วยให้สิ่งที่รังสรรค์ร่วมกันระหว่างเรากับเจ้า Copilot ออกมามีคุณภาพและจากการมีเพื่อนคู่คิดเพิ่มอีกคนที่เพิ่มประสิทธิภาพมากขึ้นกว่าเดิมเลยทีเดียว
และด้วยความสามารถของเจ้า Copilot ก็ทำให้เราอาจจะว้าวุ่นอยู่ไม่น้อยว่าความมหัศจรรย์หลังบ้างของ Copilot มันเกิดขึ้นได้ยังไงหว่า และวันนี้เราจะพาเพื่อนๆทุกคนไปทำความรู้จักเจ้า Github Copilot ให้มากขึ้นไปกว่าเดิมว่าเบื้องหลังแล้วมันทำงานยังไงหล่ะหนิ ซึ่งเดชะบุญที่ไปเจอ Talk นึงในงานของ Goto Conferences ที่มีทาง VP Product ของ Github Copilot มาเล่าให้ฟังที่น่าสนใจไม่น้อย วันนี้เลยอยากเอามาสรุปให้เพื่อนๆ หรือถ้าใครอยากไปรับชมด้วยก็ตามยูทูปลิงค์นี้ https://www.youtube.com/watch?v=m0skYNIO3mk ได้เลย
เบื้องหลังของผู้ช่วยนักเขียนโค๊ด (Github Copilot)
ทางคุณ Ryan เล่าแบบ High level ว่าตัว Github Copilot ประกอบไปด้วยสามส่วนที่จะ Interact กันนั่นคือ Code editor หรือ IDE ต่างๆ ส่วนที่สองคือ Proxy Service และสุดท้ายก็คือ Model ที่ทาง Github Copilot จะเลือกใช้สำหรับงานเฉพาะทางต่างๆ
ในส่วนแรกที่ใกล้ชิดกับ Developer มากที่สุดคือ Code Editor ต่างๆ ไม่ว่าจะเป็น VSCode หรือ IDE ต่างๆ ส่วนนี้ Github Copilot จะมี Extension ที่พยายามจะรวบรวม Context ของ Code ที่เรากำลังทำงานอยู่ ซึ่งเราต้องยอมรับว่าหาก LLM มี Context มากเท่าไรแล้วก็จะยิ่งตอบได้มีประสิทธิ์ภาพมากขึ้นเท่านั้น คุณ Ryan เล่าว่าตัว Extension จะ Assemble จาก Current cursor ใน code ของเรา รวมไปถึง Files ที่เปิดใน Open tab ต่างๆที่ทาง Extension จะนำมาหาความสัมพันธ์ต่างๆด้วย Jacobian difference algorithms หรือที่เรารู้จักกันจาก Venn diagram นั่นเอง เพื่อทั้งหมดจะนำไปสู่การสร้าง Prompt เพื่อให้ Model ของ Copilot ทราบถึง Relavant Context ทั้งหมดกับงานที่ Developer กำลังทำอยู่ นอกจากนี้หากเป็นการทำงานให้ Copilot เข้าใจ Codebase ทั้งหมด (@workspace) เจ้าตัว Extension ก็จะทำเหมือน RAG ที่จะ Vectorize codebase ทั้งหมดของเราเพื่อส่งให้ทาง Copilot นำไปใช้เป็น Context เพื่อตอบเรานั่นเอง
หลังจากนั้นจะเริ่มออกเดินทางไปสู่ Proxy service ที่ทาง Github Copilot เตรียมไว้เป็นปราการแรก (Pre-processing) ซึ่งจะคอยหา Toxic ต่างๆไม่ว่าจะเป็น Hate speech ต่างๆ รวมไปถึง Prompt Injection ต่างๆที่จะมาหลอกล่อน้องปลาหมึก Proxy service จะกรอง (sanitizing) ให้เหลือแต่สิ่งที่ Copilot จะช่วยเหลือได้เท่านั้นสำหรับงาน Coding
เมื่องานเข้ามาถึงตัว Model จริงๆแล้วก็ถึงเวลาทำหน้าที่แสดงศักยภาพออกมาแล้ว โดยที่คุณ Ryan บอกว่างานต่างๆจะถูกเลือกใช้ Model ที่แตกต่างกันเช่น Code completion เราต้องการความเร็ว Latency ต่ำๆ (300–400ms) เพราะ developer กำลังใจจดใจจ่อกับการ Code การตอบได้เราจะทำให้ Dev มันมือเขียน Code ต่อได้ไวไว หากแต่เป็นเราหันไปคุยกับ Copilot เพื่อหา Idea หรือว่าให้มัน Analyst อะไรบางอย่างแล้วละก็จะเลือกใช้ Model ที่มีความฉลาดมากขึ้นเพราะว่าใน Conversaion นั้นก็เหมือนกับการ Chat คุยเราสามารถรอใน Latency ที่มากขึ้นได้
นอกจากนี้ Github Copilot ยังเปิดโอกาสให้สามารภ Fine tuning model เพื่อใช้เฉพาะทางกับงาน Dev ของเราโดยเฉพาะเช่นการที่เราอาจจะมี Knowledge base /SDKs/APIs หรือ Library ส่วนตัวไว้ใช้เอง ซึ่งจะทำให้ Model สามารถตอบแบบมี Bias มาที่สิ่งที่เราสอนไปเพิ่มได้อีกด้วย
และท้ายที่สุดแล้วเค้าเคลมว่า Github Copilot จะลบ Prompt ที่เราส่งไปเพราะถือว่าเป็นข้อมูล Private ของเรา (🤞🏻)
มาถึงขากลับ Proxy services ก็มาแบบพระเอกหล่อๆอีกแล้ว (Post-processing)โดยเค้าจะคอยดูว่า Model ตอบ Code อะไรแปลกๆมาป่าว มี Valunerbility Issues อะไรที่มันทำให้ไม่ดีต่อการนำ Code ไปใช้งานหรือเปล่า หรือตอบ Unique ID / PII Data อะไรออกมารวมไปถึง Public code ของชาวบ้านชาวช่องที่ไม่สมควรไปนำมาใช้หรือเปล่าเอามากรองออกให้หมด
และเมื่อกลับมาสู่ IDE ของพวกเราแล้วก็จะเป็นคำตอบที่ทาง Copilot ช่วยเราทำงานให้เราเลือกใช้หรือไม่ใช้ต่อไปนั่นเอง และเหมือนเดิมเค้าเคลมว่าคำตอบก็จะลบทิ้งไม่เอาไป Train ต่อนาจา (🤞🏻) ฮ่าๆ
Github Copilot ยังต่อยอด Ecosystem ของการพัฒนา Software ได้อย่างน่าขนลุก คือผมว่าเค้าคิดมาค่อนข้างขาดดีไม่ว่าจะเป็น Github Copilot Workspace ที่สามารถ Planning > Coding > Testing ได้อย่างครบวงจรด้วย Concept ของ AI Agents เอง ซึ่งก็เป็นการนำความฉลาดของ LLM เท่าที่มีปัจจุบันมาทำให้เห็นศักยภาพที่น่าทึ่งจนไม่อาจจินตนาการไปถึงอนาคตได้เลยว่าจะยิ่งมากไปกว่านี้อีกเท่าไหน
หลังจากที่เราได้ทราบถึงการทำงานของ Github Copilot ไปกันแล้วก็จะเห็นว่าจริงๆมันก็คือหลักการที่ใช้พัฒนา Application AI ในปัจจุบันเพียงแค่ Github Copilot ถูกปรับแต่งมาให้ใช้กับงาน Software Development โดยเฉพาะนั้นเอง แล้วคำถามคือเราควรจะใช้งานมันไหม งั้นเรามาดูสถานการณ์ที่เค้าไปทำสำรวจการใช้งาน AI กับ งาน Software Development กันต่อเลย
Trends การนำ AI มาใช้กับงานพัฒนา Software
อย่างที่เราทราบกันไปแล้วนั้นว่าเบื้องลึกเบื้องหลังแล้ว Github Copilot นั้นทำงานอะไรบ้างเรามาต่อกันด้วย Research ที่ทาง Github และ Stackoverflow ไปสำรวจการใช้งาน AI กับงาน Develop กันดูบ้าง จะพบว่า Usecase หลักๆของการใช้งาน AI ในงาน Development คือการให้ AI ช่วยเขียน Code อาจด้วยเพราะงาน Literal หรือ Text Generation เป็นความสามารถอันโดดเด่นสำหรับ LLM ในช่วงนี้จึงเป็น Usecase ที่ถูกนำมาใช้มากที่สุดในวงการ
และผลสำรวจก็พบว่าการใช้งาน AI ช่วยเพิ่ม Productivity ในการทำงานได้ก็จริงแต่ก็ยังไม่ได้รับการ Trust มากจาก Developer อยู่หรอกนะเจ้าเอไอ ฮ่าๆ ซึ่งก็มีความสอดคล้องกับสถิติจากทาง Github Copilt ที่พบว่า Developer ที่ชั่วโมงบินน้อยอยู่จะยอมรับคำตอบที่มาจาก AI มากกว่า Developer ที่มีประสบการณ์โชคโชนผ่านร้อนผ่านหนาวมาเยอะๆ
ก็คงอาจจะไม่แปลกใจซักเท่าไร เนื่องจากจริงๆแล้วเราต้องยอมรับว่าความสามารถด้าน Rational Thinking ของ LLM ปัจจุบันยังไม่ได้เก่งพอที่จะไว้ใจได้ LLM เป็นแค่ Model ทางสถิติที่ได้เจอกับข้อมูลจำนวนมากๆ(แบบมว๊ากๆจริงๆ) เห็นมากก็เลยตอบได้มากเท่านั้น ดังนั้นการตอบจึงอาจเกิดจากการได้เจอของซ้ำบ่อยๆโดยปราศจากการความเข้าใจอย่างแท้จริง ซึ่งหากเหล่า Developer เทพๆได้เจอ Code แล้วอาจจะไม่ถูกใจซักทีเดียว ต่างจาก Developer ที่ชั่วโมงบินยังน้อยอยู่ก็อาจจะพบว่าเป็นสิ่งใหม่ที่จะช่วยเพิ่ม Productivity ได้มากขึ้นและพร้อมที่จะเรียนรู้ไปกับมันนั้นเอง
นอกจากนี้ทาง Accenture ยังมีการทำ Research กับ 450 Developers ที่ได้ลองใช้ Copilot ในการทำงานตลอดระยะเวลา 6 เดือนพบว่า Productivity และ Quality เพิ่มขึ้นกว่าการที่ไม่มี AI ช่วยในงาน Development
โดยหลักการ Measurement เค้าวัดจาก Pull Requests / Merge Requests มีอัตราการเพิ่มสูงขึ้น ซึ่งเป็นตัวชี้วัดถึง Throughput ของการทำงานที่เพิ่มขึ้น และการได้รับการ Merged เข้า Branch หลัก (Merged Rate) เป็นตัวชี้วัดถึง Quality ที่เพิ่มขึ้นหลังจากนำ AI เข้ามาใช้งาน และนอกจากนี้ตัวชี้วัดอื่นๆก็เป็น Consequence ของการมี PR/Merged ที่เพิ่มก็ตามมาด้วย จำนวน Build ที่เพิ่มมากขึ้น และเมื่อ Build ที่มากขึ้นเราก็จะมี Feedback loop ที่เร็วขึ้นซึ่งหมายถึง Productivity ที่สูงขึ้นด้วย
ท้ายที่สุดแล้วอยากปลอบใจชาว Dev ทุกคนว่าไม่ต้องกลัว AI แย่งงานครับ มันแย่งแน่ๆในอนาคต 555 แต่หากเรามองย้อนกลับมาที่ตัวเทคโนโลยีของ LLM ณ ปัจจุบันยังมีความห่างไกลกับระบบกระบวนความคิดและแก้ไขปัญหาของมนุษย์อยู่มาก คงจะมีเทคโนโลยีที่สามารถ Breakthorugh ได้ในอนาคต แต่ในปัจจุบันหากเป็นงาน Software Engineer แล้ว AI แค่เข้ามาช่วยเติมเต็มเป็นเพื่อนคู่คิดช่วยทำงานให้เราสามารถสื่อสารกับ Machine ผ่าน Programming Syntax ได้มีประสิทธิภาพมากขึ้น แต่ทักษะในการคิดวิเคราะห์ การออกแบบ และแก้ปัญหายังเป็นสิ่งที่ AI ยังห่างไกลอีกเยอะ หากเราสามารถ Upskill ให้อยู่ในสิ่งที่ AI ยังทำงานไม่ได้หรือรู้จักใช้งาน AI ให้เป็นและพัฒนาตัวเองอยู่ตลอดเวลา ยังไงเราก็จะยังได้ทำงานที่เรารักต่อไปครับ แล้วพบกับ #แอลแอลเอ็มเดอะซีรี่ย์ กันใหม่ในตอนหน้าค้าบบบ 👋🏻
