11 คะแนน โดย GN⁺ 2024-06-10 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ในปี 2019 วิศวกรซอฟต์แวร์ส่วนใหญ่ยังนึกภาพได้ยากว่าแมชชีนเลิร์นนิงจะช่วยงานของตนได้อย่างไร
  • แต่ในปี 2024 มีความตื่นตัวอย่างกว้างขวางต่อวิธีที่ AI ช่วยเขียนโค้ด
    • วิศวกรจำนวนมากได้ลองใช้การเติมโค้ดอัตโนมัติที่อิง ML ผ่านเครื่องมือภายในบริษัทหรือผลิตภัณฑ์เชิงพาณิชย์
  • บทความนี้นำเสนอการปรับปรุงล่าสุดที่ขับเคลื่อนด้วย AI ท่ามกลางการเปลี่ยนแปลงอย่างต่อเนื่องของเครื่องมือพัฒนาซอฟต์แวร์ภายในของ Google
    • รวมถึงพูดถึงการเปลี่ยนแปลงเพิ่มเติมที่คาดว่าจะเกิดขึ้นในอีก 5 ปีข้างหน้า
  • ยังนำเสนอแนวทางการสร้างผลิตภัณฑ์ AI ที่ส่งมอบคุณค่าให้กับการพัฒนาซอฟต์แวร์ระดับมืออาชีพ
    • ทีมนี้ดูแลสภาพแวดล้อมการพัฒนาซอฟต์แวร์ที่วิศวกรของ Google ใช้เวลาส่วนใหญ่อยู่กับมัน เช่น IDE, code review และ code search
    • แสดงให้เห็นว่าการปรับปรุงเหล่านี้สามารถส่งผลโดยตรงต่อประสิทธิภาพและความพึงพอใจของนักพัฒนาได้

ความท้าทาย

  • ความท้าทายต่อเนื่องในด้านนี้คือเทคโนโลยี AI พัฒนาอย่างรวดเร็วมาก จนยากจะคาดเดาได้ว่าควรสำรวจไอเดียใดก่อน
  • มักมีช่องว่างขนาดใหญ่ระหว่างเดโมที่ทำได้จริงทางเทคนิคกับการทำให้เป็นผลิตภัณฑ์ที่ประสบความสำเร็จ
  • แนวทางในการนำไอเดียไปใช้งานจริงในผลิตภัณฑ์มีหลักแนะนำอยู่ 3 ข้อ:
    1. จัดลำดับความสำคัญตามความเป็นไปได้ทางเทคนิคและผลกระทบ: ทำงานกับไอเดียที่พิสูจน์ความเป็นไปได้ทางเทคนิคแล้ว และคาดว่าจะมีผลกระทบสูงแบบวัดผลได้ต่อเวิร์กโฟลว์ของวิศวกร
    2. เรียนรู้อย่างรวดเร็วเพื่อปรับปรุง UX และคุณภาพของโมเดล: มุ่งเน้นการทำซ้ำอย่างรวดเร็วและสกัดบทเรียนที่ได้ โดยยังคงรักษาประสิทธิภาพการทำงานและความสุขของนักพัฒนาเอาไว้ ประสบการณ์ผู้ใช้สำคัญพอๆ กับคุณภาพของโมเดล
    3. วัดผลลัพธ์: เป้าหมายคือการเพิ่มตัวชี้วัดด้านประสิทธิภาพและความพึงพอใจ จึงต้องติดตามตัวชี้วัดเหล่านี้อย่างกว้างขวาง

การประยุกต์ใช้ LLM กับการพัฒนาซอฟต์แวร์

  • เมื่อสถาปัตยกรรม Transformer ปรากฏขึ้น ก็เริ่มสำรวจวิธีนำ LLM มาใช้กับการพัฒนาซอฟต์แวร์
  • การเติมโค้ดแบบ inline ที่อิง LLM เป็นหนึ่งในการประยุกต์ใช้ AI กับการพัฒนาซอฟต์แวร์ที่ได้รับความนิยมมากที่สุด
    • การใช้โค้ดเองเป็นข้อมูลฝึกถือเป็นการประยุกต์ใช้เทคโนโลยี LLM ที่เป็นธรรมชาติ
    • UX ให้ความรู้สึกเป็นธรรมชาติกับนักพัฒนา เพราะการเติมอัตโนมัติระดับคำเป็นฟีเจอร์หลักของ IDE มานานแล้ว
    • สามารถวัดผลกระทบแบบคร่าวๆ ได้ เช่น สัดส่วนของอักขระใหม่ที่เขียนโดย AI
    • ด้วยเหตุผลเหล่านี้ จึงสมเหตุสมผลที่การใช้งาน LLM รูปแบบนี้จะถูกนำไปใช้ก่อน
  • ในบล็อกก่อนหน้านี้ได้อธิบายวิธีปรับปรุงประสบการณ์ผู้ใช้ด้วย code completion และวิธีวัดผลกระทบ
    • หลังจากนั้นก็เติบโตอย่างรวดเร็วต่อเนื่อง คล้ายกับที่เห็นในสภาพแวดล้อมองค์กรอื่นๆ
    • อัตราการยอมรับในหมู่วิศวกรซอฟต์แวร์อยู่ที่ 37% และช่วยเติมอักขระโค้ดได้ 50%
  • การปรับปรุงหลักมาจากทั้งโมเดลและ UX
    • วงจรนี้จำเป็นอย่างยิ่งต่อการเรียนรู้จากพฤติกรรมจริง ไม่ใช่สูตรสังเคราะห์
  • มีการใช้ทั้งข้อมูลบันทึกจากเครื่องมือต่างๆ และข้อมูลการใช้งานที่สะท้อนความชอบและความต้องการของผู้ใช้ เพื่อปรับปรุงฟีเจอร์ AI ในเครื่องมือเขียนโค้ด เช่น IDE
  • สัดส่วนของโค้ดที่สร้างขึ้นด้วยความช่วยเหลือจาก AI เพิ่มขึ้นอย่างต่อเนื่อง
    • โดยนิยามเป็นจำนวนอักขระที่ยอมรับจากข้อเสนอของ AI หารด้วยผลรวมของจำนวนอักขระที่พิมพ์ด้วยมือและจำนวนอักขระที่ยอมรับจากข้อเสนอของ AI
    • สิ่งที่ควรสังเกตคืออักขระที่มาจากการคัดลอกและวางจะไม่ถูกนับในตัวส่วน
  • ใช้ log ภายในด้านกิจกรรมวิศวกรรมซอฟต์แวร์ที่มีขนาดใหญ่และคุณภาพสูง ซึ่งถูกคัดสรรมานานจากหลายเครื่องมือ
    • ข้อมูลนี้ทำให้สามารถอธิบายการแก้ไขโค้ดแบบละเอียด ผลลัพธ์การ build การแก้ไขเพื่อแก้ปัญหา build การคัดลอกและวางโค้ด การแก้ไขโค้ดที่วางมา code review การแก้ไขเพื่อตอบข้อคิดเห็นของ reviewer และการส่งการเปลี่ยนแปลงเข้า repository ได้
  • ข้อมูลฝึกเป็นคลังโค้ดที่จัดแนวกัน โดยมีคำอธิบายกำกับตามงานทั้งในส่วนอินพุตและเอาต์พุต
  • การนำไปใช้งานที่สำคัญถัดมาคือการช่วยแก้ข้อคิดเห็นใน code review (ปัจจุบันมากกว่า 8% ถูกจัดการด้วยความช่วยเหลือจาก AI) และการปรับโค้ดที่วางมาให้เข้ากับบริบทโดยรอบโดยอัตโนมัติ (ปัจจุบันคิดเป็นราว 2% ของโค้ดใน IDE)
  • การนำไปใช้งานเพิ่มเติมรวมถึงการสั่งให้ IDE แก้ไขโค้ดด้วยภาษาธรรมชาติ และการคาดเดาวิธีแก้สำหรับ build ที่ล้มเหลว
    • ยังมีการประยุกต์ใช้อื่นได้อีก เช่น การคาดเดาคำแนะนำด้านความอ่านง่ายของโค้ดที่เป็นไปตามรูปแบบคล้ายกัน
  • เมื่อนำมารวมกัน แอปพลิเคชันที่นำไปใช้จริงเหล่านี้ถือว่าประสบความสำเร็จและมีการใช้งานมากใน Google พร้อมสร้างผลกระทบต่อประสิทธิภาพการทำงานที่วัดผลได้ในสภาพแวดล้อมอุตสาหกรรมจริง

สิ่งที่ได้เรียนรู้

  • จากงานจนถึงตอนนี้ ได้เรียนรู้ข้อเท็จจริงหลายประการ:
    1. ผลกระทบสูงสุดเกิดจาก UX ที่ผสานเข้ากับเวิร์กโฟลว์ของผู้ใช้อย่างเป็นธรรมชาติ ในทุกตัวอย่างข้างต้น ข้อเสนอจะถูกแสดงให้ผู้ใช้เห็นและสามารถไปยังขั้นตอนถัดไปของเวิร์กโฟลว์ได้ด้วยการแตะหรือคลิกครั้งเดียว การทดลองที่ต้องให้ผู้ใช้จำว่าต้องเป็นฝ่ายเรียกใช้ฟีเจอร์เองไม่สามารถขยายผลได้
    2. สังเกตว่าเมื่อมีข้อเสนอจาก AI ผู้เขียนโค้ด กำลังกลายเป็น reviewer มากขึ้นเรื่อยๆ สิ่งสำคัญคือการหาสมดุลระหว่างต้นทุนของการตรวจทานกับมูลค่าเพิ่ม โดยทั่วไปจะแก้โจทย์นี้ด้วยการตั้งเป้าหมายด้านอัตราการยอมรับ
    3. เนื่องจาก metric แบบออฟไลน์มักเป็นเพียงตัวแทนคร่าวๆ ของคุณค่าที่ผู้ใช้ได้รับ การทำซ้ำอย่างรวดเร็วผ่านการทดลองออนไลน์แบบ A/B จึงเป็นหัวใจสำคัญ การเปิดฟีเจอร์ AI ในเครื่องมือภายในมีข้อดีมาก เพราะทำให้ปล่อยใช้งานและทำซ้ำได้ง่าย วัดข้อมูลการใช้งานได้ และถามประสบการณ์จากผู้ใช้โดยตรงผ่าน UX research ได้
    4. ข้อมูลคุณภาพสูง จากกิจกรรมของวิศวกร Google ในเครื่องมือซอฟต์แวร์ต่างๆ รวมถึงการโต้ตอบกับฟีเจอร์ของเราเอง เป็นสิ่งจำเป็นต่อคุณภาพของโมเดล
  • การใช้การปรับปรุงด้าน UX และโมเดลเพื่อลดคอขวดในขั้นกลาง พร้อมเพิ่มประสิทธิภาพการเปลี่ยนผ่านจากโอกาส (กิจกรรมของผู้ใช้เป็นหลัก แสดงด้านบนของ funnel ด้านล่าง) ไปสู่ผลกระทบ (ความช่วยเหลือจาก AI ที่ถูกนำไปใช้จริง ด้านล่างของ funnel) เป็นสิ่งสำคัญ

What's Next

  • ด้วยแรงหนุนจากความสำเร็จจนถึงตอนนี้ จึงมุ่งเน้นการผสานโมเดลฐานล่าสุด (ตระกูล Gemini) เข้ากับข้อมูลนักพัฒนา (ส่วนหนึ่งของ DIDACT ที่กล่าวถึงข้างต้น) เพื่อขับเคลื่อนทั้งแอปพลิเคชันเดิมและแอปพลิเคชันใหม่ในการประยุกต์ใช้ ML กับงานวิศวกรรมซอฟต์แวร์ของ Google
  • ทั่วทั้งอุตสาหกรรม code completion ที่อิง ML ได้มอบความช่วยเหลืออย่างมากแก่ผู้พัฒนาซอฟต์แวร์
    • แม้ยังมีโอกาสปรับปรุงการสร้างโค้ดได้อีก แต่คาดว่าประโยชน์ในขั้นถัดไปจะมาจากความช่วยเหลือของ ML ในกิจกรรมวิศวกรรมซอฟต์แวร์ที่กว้างขึ้น เช่น การทดสอบ การทำความเข้าใจโค้ด และการดูแลรักษาโค้ด
    • ด้านหลังนี้ได้รับความสนใจเป็นพิเศษในสภาพแวดล้อมองค์กร
    • โอกาสเหล่านี้ช่วยให้ข้อมูลกับงานที่เรากำลังดำเนินอยู่เช่นกัน
  • เน้นย้ำ 2 เทรนด์ที่เห็นได้ในอุตสาหกรรม:
    1. ปฏิสัมพันธ์ระหว่างมนุษย์กับคอมพิวเตอร์กำลังเคลื่อนไปสู่ภาษาธรรมชาติในฐานะรูปแบบทั่วไป และเปลี่ยนไปสู่การใช้ภาษาเป็นอินเทอร์เฟซสำหรับงานวิศวกรรมซอฟต์แวร์ รวมถึงเป็นประตูสู่ความต้องการข้อมูลของนักพัฒนาซอฟต์แวร์ที่ถูกรวมไว้ใน IDE
    2. ระบบอัตโนมัติด้วย ML สำหรับงานขนาดใหญ่ ตั้งแต่การวินิจฉัยปัญหาไปจนถึงการนำวิธีแก้ไปใช้ เริ่มแสดงหลักฐานของความเป็นไปได้ในระยะแรกแล้ว
      • ความเป็นไปได้นี้ขับเคลื่อนโดยนวัตกรรมด้าน agent และการใช้เครื่องมือ ซึ่งทำให้สามารถสร้างระบบที่ใช้ LLM หนึ่งตัวหรือมากกว่านั้นเป็นองค์ประกอบเพื่อทำงานขนาดใหญ่ขึ้นได้
  • เพื่อขยายความสำเร็จข้างต้นไปสู่ความสามารถรุ่นถัดไปเหล่านี้ ชุมชนนักปฏิบัติและนักวิจัยที่ศึกษาเรื่องนี้อาจได้รับประโยชน์จาก benchmark กลางร่วมกัน ซึ่งช่วยผลักดันให้สาขานี้ก้าวไปสู่งานวิศวกรรมที่ใช้งานได้จริง
    • จนถึงตอนนี้ benchmark ส่วนใหญ่ยังเน้นไปที่การสร้างโค้ดเป็นหลัก (เช่น HumanEval)
    • แต่ในสภาพแวดล้อมองค์กร benchmark สำหรับงานที่กว้างกว่า เช่น code migration และ production debugging อาจมีคุณค่าเป็นพิเศษ
    • มีการเผยแพร่ benchmark สำหรับการแก้บั๊ก (เช่น SWEBench) และต้นแบบที่มุ่งเป้า benchmark ดังกล่าว (เช่น Cognition AI) แล้ว
  • สนับสนุนให้ชุมชนร่วมมือกันเสนอ benchmark เพิ่มเติม เพื่อให้ครอบคลุมงานวิศวกรรมซอฟต์แวร์ที่กว้างขึ้น

ความเห็นของ GN⁺

  • การพัฒนาอย่างรวดเร็วของ AI: เทคโนโลยี AI กำลังก้าวหน้าอย่างรวดเร็ว จึงสำคัญที่จะต้องเรียนรู้และนำเทคโนโลยีล่าสุดมาใช้ต่อเนื่อง
  • UX และคุณภาพของโมเดล: ประสบการณ์ผู้ใช้และคุณภาพของโมเดลเป็นปัจจัยสำคัญต่อความสำเร็จของเครื่องมือ AI
  • ความสำคัญของข้อมูล: ข้อมูลคุณภาพสูงมีผลอย่างมากต่อประสิทธิภาพของโมเดล AI
  • ความเป็นไปได้ในอนาคต: AI มีแนวโน้มจะมีบทบาทมากขึ้นในหลายด้านของวิศวกรรมซอฟต์แวร์
  • เทรนด์ของอุตสาหกรรม: อินเทอร์เฟซภาษาธรรมชาติและระบบอัตโนมัติสำหรับงานขนาดใหญ่จะเป็นแรงขับอนาคตของการพัฒนาซอฟต์แวร์

1 ความคิดเห็น

 
GN⁺ 2024-06-10
ความคิดเห็นจาก Hacker News
  • เมื่อใช้ AI อย่างถูกต้อง มันทำได้สองบทบาท: 1) ช่วยประหยัดเวลาของนักพัฒนาและลดภาระทางความคิดด้วยการแก้ไขที่ไม่เป็นข้อถกเถียง 2) ทำให้ผู้ใช้ฉลาดขึ้นและมีความรู้มากขึ้นผ่านข้อเสนอแนะ ตัวอย่างเช่น บางครั้งฟีเจอร์เติมโค้ดอัตโนมัติก็ทำงานได้ดี

  • มีข้อสังเกตที่น่าสนใจว่าเครื่องมือ AI มัก "ขยายต่อไม่ได้" เมื่อถึงจุดที่ผู้ใช้ต้องเป็นคนทริกเกอร์ฟีเจอร์เอง กำลังคิดอยู่ว่า AI ใน IDE จะถูกออกแบบให้เสนอแนวคิดระดับดีไซน์และแนวคิดเชิงนามธรรมที่เป็นประโยชน์ได้อย่างไร

  • มีการสังเกตเห็นปรากฏการณ์ที่ผู้เขียนโค้ดค่อย ๆ กลายเป็นผู้รีวิวมากขึ้นเพราะข้อเสนอแนะจาก AI สิ่งสำคัญคือการหาสมดุลระหว่างต้นทุนของการรีวิวกับมูลค่าเพิ่มที่ได้รับ

  • รู้สึกว่าการใช้ GPT-4 สร้าง React UI และ Python UI ได้ภายในไม่กี่นาที แล้วรีวิวโค้ดเพื่อทำความเข้าใจวิธีการทำงานของมันนั้นมีประโยชน์

  • เนื่องจากมนุษย์มี RAM จำกัด จึงต้องนำไอเดียออกไปเก็บไว้ในสื่อภายนอก ข้อเสนอแนะของ AI ช่วยให้เดินหน้าในช่วงเริ่มต้นได้เร็วขึ้น

  • ปฏิเสธไม่ได้ว่า LLMs (โมเดลภาษาขนาดใหญ่) มีประโยชน์ต่อการเขียนโปรแกรม โดยความท้าทายหลักคือ UX ที่เหมาะสมเพื่อทำให้ประสบการณ์ลื่นไหลขึ้น เคยลองใช้ระบบเติมอัตโนมัติแล้ว แต่ปิดไปเพราะข้อเสนอแนะส่วนใหญ่ไม่ดี

  • รู้สึกว่าการใช้แอปเดสก์ท็อป ChatGPT เพื่อถามคำถามเกี่ยวกับโค้ดมีประโยชน์มากกว่า แต่การต้องอธิบายรายละเอียดทุกครั้งก็ยุ่งยาก

  • แนวโน้มที่สัดส่วนการเขียนโค้ดด้วยความช่วยเหลือของ AI เพิ่มขึ้นถึง 50% น่าสนใจ

  • AI บอกวิธีทำงานที่ร้องขอได้ แต่ไม่ได้บอกว่านั่นเป็นไอเดียที่ไม่ดี คุณภาพของโค้ดที่สร้างโดย ML ขึ้นอยู่กับข้อมูลที่ใช้ฝึก

  • สงสัยว่าจะต้องใช้เวลาอีกนานแค่ไหนกว่า AI จะเข้ามาแทนที่วิศวกรซอฟต์แวร์ของ Google ได้ทั้งหมด

  • เป้าหมายสูงสุดของ AI คือการดูแลระบบ ดีบักแอป จัดการ data store และเขียนโค้ดแอปตามคำอธิบายความต้องการและฟีดแบ็กจากผู้ใช้

  • การทดลองใช้เครื่องมือ AI เป็นเรื่องที่ดี แต่การที่คนอื่นคัดลอกแบบไม่ลืมหูลืมตาอาจส่งผลเสียได้ ยากที่จะหาจุดขายหลักของการเขียนโค้ดด้วย LLM