ความสำเร็จล่าสุดของ Qodo Command ที่ทำคะแนนได้ 71.2% ใน SWE-bench Verified ได้จุดประกายการถกเถียงอย่างร้อนแรงในชุมชนนักพัฒนาเกี่ยวกับความน่าเชื่อถือของ benchmark การเขียนโค้ดด้วย AI แม้ว่าคะแนนนี้จะทำให้ Qodo อยู่ใน top 5 ทั่วโลก แต่เรื่องราวที่แท้จริงอยู่ที่วิธีการที่บริษัทต่างๆ เข้าหาการประเมินเหล่านี้
ผู้ที่มีผลงานโดดเด่นใน SWE-bench Verified :
- Refact: 74.4% (พร้อมกับเฟรมเวิร์กแบบกำหนดเองขนาด 2,000 บรรทัด)
- Qodo Command: 71.2% (เวอร์ชันที่ใช้ในการผลิต ไม่มีการปรับแต่ง)
- Claude Sonnet 4: ~72.2% (การส่งผลงานของ Anthropic)
- SWE-bench Multilingual ที่ดีที่สุด: ~43% ( Claude 3.7 Sonnet )
ปัญหาการเล่นกล Benchmark
ชุมชนเทคโนโลยีกำลังแสดงความกังวลอย่างจริงจังเกี่ยวกับวิธีที่ผลงานชั้นนำบรรลุคะแนนสูง รายการที่ประสิทธิภาพดีหลายรายการในลีดเดอร์บอร์ด SWE-bench ไม่ได้ใช้ผลิตภัณฑ์ที่พร้อมใช้งานจริงเลย แต่พวกเขาสร้าง framework การทดสอบที่ซับซ้อนขึ้นมาเฉพาะเพื่อเล่นกลกับผลลัพธ์ benchmark
ยกตัวอย่าง Refact ที่อยู่อันดับสองในปัจจุบันด้วยคะแนน 74.4% พวกเขาสร้าง code framework 2,000 บรรทัดเฉพาะสำหรับ SWE-bench พร้อมด้วย agent หลายตัวและกลไกการลองใหม่ที่ซับซ้อน เมื่อ agent หลักล้มเหลว debug agent จะวิเคราะห์ความล้มเหลวและให้ข้อมูลเชิงลึกสำหรับการพยายามครั้งต่อไป วิธีการนี้ให้โอกาสหลายครั้งสำหรับแต่ละปัญหาในขณะที่อ้างว่าเป็นการพยายามเพียงครั้งเดียว
การสร้างความพยายามหลายครั้งเข้าไปใน agent ของคุณเป็นการยืดกฎเกณฑ์ แม้ว่าในทางเทคนิคจะยอมรับได้ก็ตาม
การปฏิบัตินี้เป็นตัวอย่างของกฎหมาย Goodhart - เมื่อการวัดกลายเป็นเป้าหมาย มันก็สูญเสียคุณค่าในฐานะการวัด benchmark นี้ถูกออกแบบมาเพื่อทดสอบความสามารถในการเขียนโค้ดในโลกจริง แต่บริษัทต่างๆ กำลังปรับให้เหมาะสมเฉพาะสำหรับการทดสอบแทนที่จะเป็นงาน software engineering จริง
โซลูชันสำหรับ Production กับ Benchmark เฉพาะ
สิ่งที่ทำให้แนวทางของ Qodo น่าสนใจไม่ใช่แค่คะแนนเท่านั้น แต่เป็นวิธีที่พวกเขาบรรลุผลนั้น ต่างจากคู่แข่งที่สร้าง scaffolding แบบกำหนดเอง Qodo อ้างว่าพวกเขาใช้ production CLI agent ตรงตามที่ลูกค้าจะติดตั้ง - ด้วยคำสั่ง npm อย่างง่าย ไม่มีการปรับแต่งพิเศษ ไม่มีการแก้ไขเฉพาะ benchmark เป็นเพียงผลิตภัณฑ์ที่พร้อมใช้งานทันที
ความแตกต่างนี้มีความสำคัญอย่างมากสำหรับนักพัฒนาที่พิจารณาเครื่องมือเหล่านี้ ระบบที่ปรับให้เหมาะสมกับ benchmark ที่ได้คะแนน 75% อาจทำงานได้แย่ในสถานการณ์โลกจริง ในขณะที่ระบบ production ที่ได้คะแนน 71% สามารถให้ผลลัพธ์ที่สม่ำเสมอในงานการเขียนโค้ดที่หลากหลาย
ชุมชนมีความกังวลเป็นพิเศษเกี่ยวกับข้อจำกัดความยาว context และระบบการดึงข้อมูล ปัญหา SWE-bench อาจเกี่ยวข้องกับ codebase ขนาดใหญ่ และวิธีที่ agent จัดการการเลือก context มักจะเป็นตัวกำหนดความสำเร็จ ระบบบางตัวเล่นกลโดยใช้กลไกการดึงข้อมูลที่ซับซ้อนที่สร้างขึ้นเฉพาะสำหรับ benchmark แทนที่จะเป็นโซลูชันที่ใช้งานได้จริงที่นักพัฒนาจะใช้งานจริง
คุณสมบัติสถาปัตยกรรม Qodo Command:
- การสรุปบริบท: กลั่นกรองโค้ดเบสหลายไฟล์ให้เป็นสรุปที่มีโครงสร้าง
- การวางแผนการดำเนินงาน: แนวทาง "วางแผนก่อน" พร้อมการแยกย่อยเป้าหมายอย่างมีโครงสร้าง
- กลไกการลองใหม่: การลองใหม่สูงสุด 3 ครั้งพร้อมการวินิจฉัยข้อผิดพลาดอย่างชาญฉลาด
- เฟรมเวิร์ก LangGraph: ระบบการจัดการแบบโมดูลาร์และใช้กราฟเป็นฐาน
- เครื่องมือเอเจนต์: การดำเนินการระบบไฟล์, การรันเชลล์, การค้นหา Raggap, การคิดแบบลำดับ
การเรียกร้องให้มีการตรวจสอบอิสระ
ความผิดหวังกับ benchmark ที่อาจทำให้เข้าใจผิดได้นำไปสู่การเรียกร้องให้มีหน่วยงานทดสอบอิสระ สมาชิกชุมชนแนะนำให้สร้างมาตรฐานสากลสำหรับการประเมิน AI coding คล้ายกับวิธีที่อุตสาหกรรมอื่นๆ จัดการการทดสอบประสิทธิภาพ ระบบปัจจุบันพึ่งพาผลลัพธ์ที่รายงานตนเองจากบริษัทที่มีแรงจูงใจทางการเงินที่ชัดเจนในการเพิ่มคะแนน
แนวทางทางเลือกอย่าง LiveBench ที่ปล่อยการทดสอบใหม่เป็นประจำเพื่อป้องกัน overfitting กำลังได้รับความสนใจ นอกจากนี้ยังมีความสนใจที่เพิ่มขึ้นใน multilingual benchmark เนื่องจาก SWE-bench Verified มุ่งเน้นเฉพาะปัญหา Python ประสิทธิภาพ multilingual ที่ดีที่สุดในปัจจุบันอยู่ที่ประมาณ 43% แสดงให้เห็นว่ามีพื้นที่สำหรับการปรับปรุงมากแค่ไหนในสถานการณ์การเขียนโค้ดที่หลากหลายในโลกจริง
การติดตั้งและความพร้อมใช้งาน:
- การติดตั้ง:
npm install -g @qodocommand - การรองรับโมเดล: LLM ระดับท็อปทุกตัว ปรับให้เหมาะสมกับ Claude
- ความร่วมมือ: โซลูชัน "Powered by Claude" ร่วมกับ Anthropic
- การรวม UI: รวม Qodo Merge สำหรับเวิร์กโฟลว์การตรวจสอบโค้ด
มองเกินตัวเลข
การถกเถียงเผยให้เห็นความตึงเครียดพื้นฐานในการพัฒนา AI บริษัทต่างๆ ต้องการเมตริกเพื่อแสดงความก้าวหน้าและดึงดูดลูกค้า แต่การปรับให้เหมาะสมกับ benchmark เฉพาะอาจสร้างผลิตภัณฑ์ที่เก่งในสถานการณ์การทดสอบแคบๆ ในขณะที่ล้มเหลวในการใช้งานจริง
สำหรับนักพัฒนาที่ประเมินเครื่องมือ AI coding บทเรียนชัดเจน: มองเกินคะแนน benchmark หัวข้อ พิจารณาว่าแนวทางการทดสอบสะท้อน workflow จริงของคุณหรือไม่ เครื่องมือจัดการภาษาการเขียนโปรแกรมและประเภทโปรเจกต์ของคุณหรือไม่ และที่สำคัญที่สุดคือประสิทธิภาพ benchmark แปลเป็นการเพิ่มผลผลิตในสภาพแวดล้อมเฉพาะของคุณหรือไม่
เมื่อพื้นที่ AI coding เติบโตขึ้น การผลักดันของชุมชนเพื่อวิธีการประเมินที่ซื่อสัตย์และใช้งานได้จริงมากขึ้นน่าจะเปลี่ยนแปลงวิธีที่เครื่องมือเหล่านี้ถูกพัฒนาและทำการตลาด ผู้ชนะที่แท้จริงจะเป็นบริษัทที่มุ่งเน้นการแก้ปัญหานักพัฒนาที่แท้จริงแทนที่จะเล่นกลกับเมตริกเทียม