โครงการที่ทะเยอทะยานของนักพัฒนาในการสร้างระบบเอกสารซอฟต์แวร์อัตโนมัติโดยใช้ AI ได้จุดประกายการถกเถียงเกี่ยวกับความพร้อมของระบบดังกล่าวสำหรับสภาพแวดล้อมการใช้งานจริง ระบบนี้ใช้การค้นหาแบบเวกเตอร์และคำสั่ง AI เพื่อสร้างเอกสารความต้องการ ข้อกำหนดทางเทคนิค และแผนการทดสอบจาก user stories โดยอัตโนมัติ แต่ข้อเสนอแนะจากชุมชนเน้นย้ำถึงช่องว่างที่สำคัญในการประเมินคุณภาพ
ส่วนประกอบของสถาปัตยกรรมระบบ:
- การจัดระเบียบ cloud flow ของ Power Automate
- การผสานรวม Azure DevOps สำหรับการเรียกใช้ user story
- Google Gemini AI สำหรับการสร้างเนื้อหา
- Azure AI Search สำหรับการค้นหาโค้ดแบบ vector-based
- การเรียกใช้ REST API โดยตรงสำหรับการผสานรวมแพลตฟอร์ม
การขาดการตรวจสอบคุณภาพเป็นข้อกังวลหลัก
ประเด็นที่เร่งด่วนที่สุดที่ชุมชนเทคโนโลยีหยิบยกขึ้นมาคือการขาดการประเมินคุณภาพอย่างเข้มงวด นักวิจารณ์ชี้ให้เห็นว่าแม้ระบบจะดูเหมือนทำงานได้ แต่ยังไม่มีข้อมูลเพียงพอเกี่ยวกับความถี่ในการสร้างข้อกำหนดที่ไม่ถูกต้องหรือไม่สมบูรณ์ นักพัฒนายอมรับข้อจำกัดนี้ โดยระบุว่าระบบมีความสอดคล้องประมาณ 80% จากการทดสอบเบื้องต้น พร้อมแผนการให้สถาปนิกตรวจสอบก่อนมอบหมายให้นักพัฒนา
สิ่งนี้ทำให้เกิดคำถามที่กว้างขึ้นเกี่ยวกับการตรวจสอบ AI ในการพัฒนาซอฟต์แวร์ องค์กรหลายแห่งกำลังนำเครื่องมือ AI มาใช้โดยอิงจากตัวชี้วัดความสำเร็จระดับผิวเผิน โดยไม่ได้ทดสอบความถูกต้องหรือความสมบูรณ์อย่างละเอียด ความเสี่ยงจะรุนแรงขึ้นเป็นพิเศษเมื่อข้อกำหนดที่ AI สร้างขึ้นดูน่าเชื่อถือ แต่มีข้อผิดพลาดเล็กน้อยที่อาจนำความพยายามในการพัฒนาทั้งหมดไปในทิศทางที่ผิด
เมตริกคุณภาพที่รายงาน:
- ความสม่ำเสมอของผลลัพธ์ 80% ในการทำงานหลายครั้ง
- ความแปรปรวน 20% รวมถึงข้อเสนอแนะการเปลี่ยนแปลงเพิ่มเติม
- ต้องการการตรวจสอบจากสถาปนิกก่อนมอบหมายให้นักพัฒนา
- ยังไม่ได้ทดสอบสำหรับปริมาณการผลิตขนาดใหญ่
ข้อจำกัดของ Embedding และแนวทางทางเลือก
การอภิปรายทางเทคนิคเผยให้เห็นข้อกังวลเกี่ยวกับการพึ่งพา vector embeddings อย่างมากสำหรับบริบทของโค้ด สมาชิกชุมชนอ้างอิงถึงทางเลือกใหม่ๆ สำหรับแนวทาง Retrieval Augmented Generation (RAG) แบบดั้งเดิม โดยแนะนำว่าโซลูชันที่อิงจาก embedding อาจมีข้อจำกัดโดยธรรมชาติสำหรับฐานโค้ดที่ซับซ้อน นักพัฒนาแสดงความเปิดกว้างในการสำรวจทางเลือกเหล่านี้ ซึ่งบ่งชี้ว่าสาขานี้ยังคงพัฒนาอย่างรวดเร็ว
การทดสอบความสอดคล้องเผยให้เห็นปัญหาความแปรปรวน
เมื่อถูกซักถามเกี่ยวกับความสอดคล้องของผลลัพธ์ นักพัฒนาเปิดเผยว่าการรัน user story เดียวกันหลายครั้งให้ผลลัพธ์ที่แตกต่างกัน โดยมีความสอดคล้องเพียง 80% ความแปรปรวน 20% ที่เหลือรวมถึงข้อเสนอแนะสำหรับการเปลี่ยนแปลงเพิ่มเติม ซึ่งอาจเป็นข้อมูลเชิงลึกที่มีค่าหรือความไม่สอดคล้องที่เป็นปัญหาขึ้นอยู่กับบริบท
เป็นเรื่องน่าทึ่งที่เราไปได้ไกลขนาดนี้กับ LLM และทุกคนเชื่อว่าคนอื่นๆ ได้ตรวจสอบการอ้างว่า LLM ของพวกเขาสร้างผลลัพธ์ที่ถูกต้องแล้ว
ผลลัพธ์ที่สร้างขึ้น:
- เอกสารความต้องการพร้อมข้อกำหนดทางเทคนิค
- แผนการทดสอบและกลยุทธ์การทดสอบ
- งานพัฒนาที่มีโครงสร้างสำหรับ Azure DevOps
- แผนผังสถาปัตยกรรม Mermaid
- การรวมเอกสาร Wiki
ความพร้อมสำหรับการใช้งานจริงยังคงเป็นที่น่าสงสัย
แม้จะมีความสำเร็จทางเทคนิค แต่ระบบยังคงอยู่ในขั้นทดลอง นักพัฒนายอมรับว่ายังไม่พร้อมสำหรับการใช้งานจริงและต้องการการดูแลจากมนุษย์ในหลายขั้นตอน สิ่งนี้เน้นย้ำรูปแบบทั่วไปในเครื่องมือ AI ที่การสาธิตที่น่าประทับใจไม่ได้แปลเป็นระบบการใช้งานจริงที่เชื่อถือได้ทันที
โครงการนี้แสดงให้เห็นทั้งศักยภาพและข้อจำกัดปัจจุบันของ AI ในขั้นตอนการพัฒนาซอฟต์แวร์ แม้ว่าการทำงานอัตโนมัติของงานเอกสารที่น่าเบื่อจะเป็นที่ดึงดูดใจ แต่เทคโนโลยียังคงต้องการการดูแลและการตรวจสอบจากมนุษย์อย่างมากเพื่อให้มั่นใจในคุณภาพและความถูกต้องในสภาพแวดล้อมระดับมืออาชีพ
อ้างอิง: Grounding AI in Reality: How Vector Search on Our Codebase Transformed Our SDLC Automation