การสำรวจโมเดลภาษาโอเพ่นซอร์สสำหรับช่วยเหลือการเขียนโค้ดเมื่อเร็วๆ นี้ได้เผยให้เห็นช่องว่างที่สำคัญระหว่างความคาดหวังและความเป็นจริง แม้ว่าโมเดลเหล่านี้จะสัญญาว่าจะให้อิสรภาพจากการผูกมัดกับผู้ขายและความกังวลเรื่องต้นทุน แต่ประสิทธิภาพในทางปฏิบัติในงานพัฒนายังคงน่าผิดหวังเมื่อเปรียบเทียบกับทางเลือกเชิงพาณิชย์
ประสิทธิภาพของโมเดลต่ำกว่าความคาดหวัง
การทดสอบเผยให้เห็นว่าโมเดลโอเพ่นซอร์สยอดนิยมมีปัญหาในการจัดการงานเขียนโค้ดพื้นฐาน โมเดล Deepseek R1 8B ที่ถูกพูดถึงอย่างกว้างขวาง แม้จะมีเบนช์มาร์กที่น่าประทับใจ แต่มักติดอยู่ในลูปการใช้เหตุผลและล้มเหลวในการทำคำขอการเขียนโปรแกรมง่ายๆ ให้สำเร็จ ในขณะที่ Mistral 7B มีแนวโน้มที่จะสร้างฟังก์ชันที่ไม่มีอยู่จริงและแก้ไขส่วนโค้ดที่ไม่เกี่ยวข้องแบบสุ่ม มีเพียง Qwen3 8B เท่านั้นที่แสดงประสิทธิภาพที่เชื่อถือได้ในระดับหนึ่ง แม้ว่าจะยังไกลจากอุดมคติ
ชุมชนได้สังเกตเห็นความแตกต่างที่สำคัญตรงนี้ - โมเดลขนาดเล็กหลายตัวเหล่านี้เป็นเวอร์ชันที่ถูกกลั่นมาจากโมเดลที่ใหญ่กว่า ซึ่งอาจอธิบายความสามารถที่จำกัดของพวกมันได้ ดังที่ผู้สังเกตการณ์คนหนึ่งชี้ให้เห็น โมเดル Deepseek 8B นั้นเป็นเวอร์ชันบีบอัดของ Qwen2 โดยพื้นฐาน ซึ่งแนะนำว่าผู้ใช้อาจได้ผลลัพธ์ที่ดีกว่าด้วยโมเดล Qwen3 ต้นฉบับในขนาดที่ใหญ่กว่า
ตารางเปรียบเทียบโมเดล
| โมเดล | ขนาด | ประสิทธิภาพ | ปัญหาหลัก |
|---|---|---|---|
| Deepseek R1 8B | 5.2 GB | แย่ | ติดอยู่ในลูปการใช้เหตุผล ล้มเหลวในงานง่ายๆ |
| Mistral 7B | ~7B params | ต่ำกว่าเกณฑ์ | สร้างฟังก์ชันที่ไม่มีจริง ลบโค้ดแบบสุ่ม |
| Qwen3 8B | ~8B params | ยอมรับได้ | มีประสิทธิภาพดีที่สุดแต่ยังมีข้อจำกัด รองรับทั้งโหมดการใช้เหตุผลและไม่ใช้เหตุผล |
การถกเถียงเรื่องโอเพ่นซอร์สทวีความรุนแรงขึ้น
การอภิปรายที่ร้อนแรงได้เกิดขึ้นเกี่ยวกับสิ่งที่ถือว่าเป็นโอเพ่นซอร์สอย่างแท้จริงในโลก AI นักวิจารณ์โต้แย้งว่าโมเดลที่เรียกว่าโอเพ่นซอร์สหลายตัวเป็นเพียงฟรีแวร์ ขาดองค์ประกอบสำคัญที่จำเป็นสำหรับความเปิดกว้างอย่างแท้จริง รวมถึงข้อมูลการฝึกอบรม โค้ดการฝึกอบรม และใบอนุญาตที่เหมาะสม
การตัดสินใจของ Open Source Initiative เมื่อเร็วๆ นี้ที่จะผ่อนปรนมาตรฐานสำหรับโมเดล AI ได้จุดประกายความขัดแย้ง แม้ว่าพวกเขาจะไม่ต้องการให้เผยแพร่ข้อมูลการฝึกอบรมอีกต่อไป แต่สมาชิกชุมชนหลายคนเชื่อว่าสิ่งนี้ทำลายหลักการหลักของซอฟต์แวร์โอเพ่นซอร์ส ความกังวลขยายออกไปนอกเหนือจากข้อกำหนดทางเทคนิคไปสู่ผลกระทบในทางปฏิบัติ - หากไม่มีข้อมูลการฝึกอบรม ผู้ใช้ไม่สามารถตรวจสอบโมเดลเพื่อหาอคติ สร้างผลลัพธ์ซ้ำ หรือทำการปรับปรุงที่มีความหมายได้
ข้อมูลการฝึกอบรมควรจะต้องเผยแพร่เพื่อให้ถือว่าเป็นโมเดลโอเพ่นซอร์ส หากไม่มี สิ่งที่ฉันทำได้คือตั้งค่าน้ำหนักเป็นต้น หากไม่มีข้อมูลการฝึกอบรม ฉันไม่สามารถสร้างโมเดลซ้ำอย่างแท้จริง ตรวจสอบข้อมูลเพื่อหาอคติ/ตรวจสอบโมเดลเพื่อความยุติธรรมได้
ข้อกำหนดสำหรับโมเดล AI แบบโอเพนซอร์ส (มาตราส่วน 10 ข้อ)
- โค้ดของโมเดล ( PyTorch , ฯลฯ)
- โค้ดสำหรับการฝึกอบรมเบื้องต้น
- โค้ดสำหรับการปรับแต่ง
- โค้ดสำหรับการอนุมาน
- ข้อมูลการฝึกอบรมดิบ
- ข้อมูลการฝึกอบรมที่ผ่านการประมวลผลแล้ว
- น้ำหนักของโมเดล
- ข้อมูลนำเข้า/ส่งออกสำหรับการอนุมานพร้อมใบอนุญาตที่เหมาะสม
- เอกสารงานวิจัยและเอกสารประกอบ
- ข้อมูลสิทธิบัตรหรือการไม่มีสิทธิบัตร
การทดสอบในโลกจริงเผยผลลัพธ์ที่หลากหลาย
การทดสอบในทางปฏิบัติด้วยเครื่องมืออย่าง Aider แสดงให้เห็นว่าแม้ว่าโมเดลเหล่านี้จะสามารถจัดการงาน refactoring ง่ายๆ ได้เมื่อได้รับคำแนะนำที่ชัดเจน แต่มักใช้เวลานานกว่าการเขียนโค้ดด้วยมือ กรณีการใช้งานที่มีแนวโน้มดีที่สุดปรากฏในการแก้ไขปัญหา - โมเดลเก่งในการอธิบายข้อความแสดงข้อผิดพลาดเมื่อได้รับบริบทโค้ดที่เกี่ยวข้อง ซึ่งอาจลดเวลาการแก้ไขจุดบกพร่องลงครึ่งหนึ่ง
อย่างไรก็ตาม ความพยายามในการพัฒนาแบบ greenfield กลับกลายเป็นหายนะ โดยโมเดลผลิตโค้ดที่ไม่สามารถใช้งานได้และเต็มไปด้วยภาพลวงตา การขาดบริบทโค้ดที่มีอยู่ดูเหมือนจะขัดขวางประสิทธิภาพของโมเดลอย่างมีนัยสำคัญ ซึ่งแนะนำว่าเครื่องมือเหล่านี้ทำงานได้ดีที่สุดในฐานะผู้ช่วยมากกว่านักพัฒนาที่ทำงานอิสระ
ผลการทดสอบประสิทธิภาพของเครื่องมือ Aider
- การปรับปรุงโครงสร้างโค้ด (Refactoring): ประสบความสำเร็จแต่ช้ากว่าการเขียนโค้ดด้วยตนเอง (มากกว่า 10 นาที เทียบกับการทำงานด้วยตนเอง)
- การพัฒนาโปรเจกต์ใหม่ (Greenfield Development): ล้มเหลวสิ้นเชิงด้วยโค้ดที่สร้างขึ้นมาเองและไม่สามารถใช้งานได้
- การแก้ไขปัญหา (Troubleshooting): กรณีการใช้งานที่ประสบความสำเร็จมากที่สุด สามารถลดเวลาในการ debug ได้ประมาณ 50%
- ความต้องการบริบท (Context Requirements): ทำงานได้ดีที่สุดเมื่อมีบริบทของโค้ดที่มีอยู่แล้ว แต่จะมีปัญหาเมื่อไม่มีบริบท
ข้อจำกัดของฮาร์ดแวร์สร้างอุปสรรคเพิ่มเติม
ความเป็นจริงของการรันโมเดลเหล่านี้ในเครื่องท้องถิ่นนำเสนอความท้าทายอีกประการหนึ่ง โมเดลโอเพ่นซอร์สส่วนใหญ่ได้รับการปรับให้เหมาะสมสำหรับการใช้งานบนคลาวด์ขนาดใหญ่ที่มีหน้าต่างบริบทขนาดใหญ่ การตั้งค่าท้องถิ่นที่มีฮาร์ดแวร์จำกัดมีปัญหากับข้อจำกัดขนาดบริบท มักนำไปสู่ความล้มเหลวเมื่อประมวลผล repository โค้ดทั้งหมด
เครื่องมืออย่าง Qwen Code ที่ออกแบบมาสำหรับการทำงานอิสระ มักล้มเหลวบนฮาร์ดแวร์ท้องถิ่นเนื่องจากข้อจำกัดเหล่านี้ ขีดจำกัดบริบท 40,000 โทเค็นของโมเดลท้องถิ่นยังน้อยกว่าความสามารถ 1 ล้านโทเค็นที่เครื่องมือเหล่านี้คาดหวังจากบริการเชิงพาณิชย์
สถานะปัจจุบันของเครื่องมือเขียนโค้ด AI โอเพ่นซอร์สแนะนำว่าพวกมันยังไม่พร้อมที่จะทดแทนทางเลือกเชิงพาณิชย์สำหรับงานพัฒนาที่จริงจัง แม้ว่าจะแสดงแนวโน้มที่ดีในพื้นที่เฉพาะอย่างการช่วยเหลือการแก้ไขจุดบกพร่อง แต่ข้อจำกัดในการเขียนโค้ดอิสระและปัญหาความน่าเชื่อถือทำให้พวกมันเหมาะสมกับการทดลองมากกว่าการใช้งานจริง การถกเถียงที่กำลังดำเนินอยู่เกี่ยวกับความเปิดกว้างที่แท้จริงในโมเดล AI เพิ่มความซับซ้อนอีกชั้นหนึ่งสำหรับนักพัฒนาที่แสวงหาทางเลือกที่แท้จริงแทนโซลูชันที่เป็นกรรมสิทธิ์
อ้างอิง: Playing with open source LLMs