การทดสอบความสามารถในการเขียนโค้ดของ GPT-5 เมื่อเร็วๆ นี้ได้จุดประกายการอภิปรายเกี่ยวกับข้อจำกัดพื้นฐานของโมเดลภาษาขนาดใหญ่ (LLMs) ในการพัฒนาซอฟต์แวร์ เมื่อถูกถามเกี่ยวกับวิธีการบีบอัดข้อมูลด้วย zstd ใน Swift บน iPhone โดยไม่ใช้ dependencies จากบุคคลที่สาม AI ได้ให้โค้ดอย่างมั่นใจโดยใช้ฟังก์ชันของ Apple SDK ที่ไม่มีอยู่จริง ซึ่งเน้นย้ำถึงปัญหาที่ยังคงมีอยู่ในโซลูชันการเขียนโปรแกรมที่สร้างโดย AI
ปัญหาหลัก: คำตอบที่มั่นใจแต่ผิด
การทดสอบเผยให้เห็นว่า GPT-5 สร้างโค้ด Swift โดยใช้ค่าคงที่ COMPRESSION_ZSTD ที่ไม่มีอยู่ใน Compression framework ของ Apple โดย Apple ไม่เคยรองรับการบีบอัด zstd ใน SDK อย่างเป็นทางการ ทำให้คำตอบที่มั่นใจของ AI นั้นใช้งานไม่ได้เลย ข้อผิดพลาดประเภทนี้มีปัญหาเป็นพิเศษเพราะนักพัฒนาอาจใช้เวลาหลายชั่วโมงพยายามใช้งานโค้ดที่ไม่มีทางทำงานได้
สิ่งที่ทำให้ปัญหานี้น่ากังวลมากขึ้นคือระดับความมั่นใจของ AI โมเดลนำเสนอโซลูชันที่ไม่ถูกต้องด้วยความแน่นอน แม้กระทั่งอ้างว่าเข้ากันได้กับ iOS 16+ การนำเสนออย่างมั่นใจนี้อาจทำให้นักพัฒนาเข้าใจผิด โดยเฉพาะผู้ที่ไม่คุ้นเคยกับ API เฉพาะที่กำลังพูดถึง
การรองรับ Apple iOS Compression Framework
อัลกอริทึมที่รองรับอย่างเป็นทางการ:
- LZFSE (อัลกอริทึมของ Apple เอง)
- LZ4 (การบีบอัดที่รวดเร็ว)
- zlib/deflate (เข้ากันได้อย่างแพร่หลาย)
- LZMA (อัตราส่วนการบีบอัดสูง)
ไม่รองรับ:
- Zstandard (zstd) - ต้องใช้ไลบรารีจากบุคคลที่สาม
ชุมชนแบ่งออกเป็นสองฝ่ายเรื่องคุณค่าและข้อจำกัดของ LLM
ชุมชนโปรแกรมเมอร์ยังคงแบ่งออกเป็นสองฝ่ายในการตีความความล้มเหลวเหล่านี้ นักพัฒนาบางคนโต้แย้งว่า LLMs เป็นเครื่องมือที่มีข้อบกพร่องพื้นฐานที่สร้างการตอบสนองที่น่าจะเป็นไปได้ทางสtatistical มากกว่าที่จะถูกต้องตามข้อเท็จจริง พวกเขาชี้ให้เห็นว่าแตกต่างจากมนุษย์ โมเดลเหล่านี้ไม่สามารถพูดว่าไม่รู้เมื่อเผชิญกับช่องว่างของความรู้
อย่างไรก็ตาม สมาชิกชุมชนอื่นๆ ยืนยันว่า LLMs ยังคงมีคุณค่าแม้จะมีข้อบกพร่อง พวกเขาแนะนำให้ปฏิบัติต่อผู้ช่วย AI เหมือนเป็นนักศึกษาฝึกงานที่มั่นใจเกินไปที่ต้องการการดูแลและการตรวจสอบข้อเท็จจริง นักพัฒนาที่มีประสบการณ์หลายคนรายงานว่าได้รับประโยชน์ด้านประสิทธิภาพอย่างมากเมื่อใช้ LLMs สำหรับการสร้างโค้ด หากพวกเขาตรวจสอบผลลัพธ์
การตรวจสอบมักจะเร็วกว่าการเขียนจากเริ่มต้น ดังนั้นนี่ยังคงเป็น +EV
ความจริงทางเทคนิคเบื้องหลังการสร้างภาพลวงตา
การอภิปรายยังได้เน้นย้ำถึงความแตกต่างทางเทคนิคที่สำคัญเกี่ยวกับวิธีการทำงานของ LLMs จริงๆ แตกต่างจากการใช้เหตุผลของมนุษย์ โมเดลเหล่านี้สร้างการตอบสนองโดยอิงจากรูปแบบทางสถิติในข้อมูลการฝึกอบรมมากกว่าความเข้าใจเชิงตรรกะ เมื่อถูกถามเกี่ยวกับการบีบอัด zstd AI น่าจะรวมความรู้เกี่ยวกับค่าคงที่การบีบอัดที่มีอยู่กับชื่ออัลกอริธึมที่ขอ สร้างโค้ดที่ดูเหมือนจริงแต่ไม่ถูกต้อง
น่าสนใจที่เมื่อคำถามเดียวกันถูกถามกับ GPT-5 เวอร์ชันหรือการกำหนดค่าที่แตกต่างกัน บางตัวระบุได้อย่างถูกต้องว่าการบีบอัด zstd ไม่มีใน frameworks ของ Apple ความไม่สอดคล้องนี้แสดงให้เห็นว่าความสามารถในการใช้เหตุผลของโมเดลอาจขึ้นอยู่กับวิธีการกรอบคำถามและเส้นทางการใช้เหตุผลใดที่ถูกเปิดใช้งาน
การเปรียบเทียบผลการทดสอบ GPT-5
การตอบสนองที่ไม่สอดคล้องกันต่อคำถามเดียวกัน:
- การตอบสนองแบบมาตรฐาน: ให้โค้ดที่ไม่ถูกต้องโดยใช้ค่าคงที่
COMPRESSION_ZSTDที่ไม่มีอยู่จริง - การตอบสนองของโมเดลแบบใช้เหตุผล: ระบุได้อย่างถูกต้องว่า "คุณไม่สามารถ" ใช้ zstd ได้หากไม่มี third-party dependencies
- เวลาในการตอบสนอง: แบบมาตรฐาน (ทันที) เทียบกับแบบใช้เหตุผล (25 วินาที)
ความแตกต่างสำคัญ: โมเดลแบบใช้เหตุผลดูเหมือนจะยอมรับข้อจำกัดและให้ข้อมูลทางเทคนิคที่แม่นยำมากกว่า
โซลูชันที่เกิดขึ้นใหม่และวิธีแก้ไขชั่วคราว
ชุมชนได้เสนอแนวทางหลายประการเพื่อลดปัญหาเหล่านี้ นักพัฒนาบางคนสนับสนุนการใช้ผู้ช่วยการเขียนโค้ด AI ที่สามารถคอมไพล์และทดสอบโค้ดแบบเรียลไทม์ ช่วยให้พวกเขาจับข้อผิดพลาดได้ทันที คนอื่นๆ แนะนำให้ปฏิบัติต่อผลลัพธ์ของ LLM เป็นจุดเริ่มต้นที่ต้องการการตรวจสอบเสมอมากกว่าเป็นโซลูชันที่แน่นอน
ผู้ใช้ขั้นสูงแนะนำแนวทางแบบวนซ้ำที่นักพัฒนาวางข้อผิดพลาดของคอมไพเลอร์กลับไปให้ AI ช่วยให้มันแก้ไขข้อผิดพลาดผ่านลูปป้อนกลับ วิธีนี้สามารถช่วยเอาชนะการสร้างภาพลวงตาเริ่มต้นในขณะที่ยังได้รับประโยชน์จากความสามารถในการสร้างโค้ดของ AI
การถกเถียงนี้สะท้อนถึงคำถามที่กว้างขึ้นเกี่ยวกับวิธีการรวมเครื่องมือ AI เข้ากับเวิร์กโฟลว์การพัฒนาซอฟต์แวร์อย่างมืออาชีพอย่างมีประสิทธิภาพในขณะที่รักษาคุณภาพและความน่าเชื่อถือของโค้ด
อ้างอิง: Yet another LLM rant