IQuest-Coder: โมเดลโค้ดโอเพนซอร์สตัวใหม่เหนือกว่า Claude Sonnet 4.5 และ GPT 5.1 [pdf]

 (github.com/IQuestLab)
2 คะแนน โดย GN⁺ 2026-01-05 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • โอเพนโค้ด LLM ที่ออกแบบมาเฉพาะสำหรับงานเขียนโค้ด โดยเรียนรู้ผ่าน การฝึกหลายขั้นแบบ code-flow ซึ่งเน้น การเปลี่ยนแปลงของรีโพซิทอรีและกระบวนการพัฒนา แทนโค้ดแบบสถิต
  • เสริมความสามารถด้านการให้เหตุผลระยะยาวและงานแบบเอเจนต์ผ่าน ไปป์ไลน์การเรียนรู้แบบวิวัฒนาการ ที่ต่อเนื่องจาก pretraining–mid-training–post-training
  • ที่คอนเท็กซ์ 32K·128K มีการใส่ ข้อมูลการให้เหตุผลและเส้นทางการทำงานของเอเจนต์ เพื่อให้แก้ปัญหาซับซ้อนแบบหลายไฟล์และระดับรีโพซิทอรีได้
  • เสนอการออกแบบเชิงปฏิบัติด้วย สถาปัตยกรรม LoopCoder ที่นำโครงสร้างวนซ้ำมาใช้ เพื่อปรับปรุงประสิทธิภาพการนำไปใช้งานเมื่อเทียบกับขนาดโมเดล
  • ทำผลงานได้ แข่งขันกับโมเดลเชิงพาณิชย์ได้ บน SWE-Bench, LiveCodeBench, Terminal-Bench และอื่น ๆ ด้วยโมเดลโอเพนน้ำหนัก

ภาพรวม

  • IQuest-Coder-V1 คือโมเดลตระกูลภาษาขนาดใหญ่สำหรับโค้ดโดยเฉพาะ ประกอบด้วย 7B·14B·40B·40B-Loop
  • ใช้พาราไดม์ code-flow ที่เรียนรู้จาก คอมมิตและกระบวนการวิวัฒนาการของรีโพซิทอรี แทนการใช้สแนปช็อตโค้ดแบบคงที่
  • ประเมินประสิทธิภาพในงานวิศวกรรมซอฟต์แวร์แบบเอเจนต์ การแข่งขันเขียนโปรแกรม และการใช้เครื่องมือโดยรวม

ไปป์ไลน์การฝึกแบบ Code-Flow

  • ในขั้น pretraining มีการฝึกจากข้อมูลทั่วไปผสมกับข้อมูลโค้ดขนาดใหญ่ ก่อนใช้ การ annealing โค้ดคุณภาพสูง
  • ในขั้น mid-training มีการ ขยายคอนเท็กซ์จาก 32K → 128K และฝึกด้วยข้อมูล QA เชิงเหตุผล เส้นทางของเอเจนต์ และข้อมูลโค้ดระดับรีโพซิทอรี
  • ในขั้น post-training แยกเป็น เส้นทาง Thinking (RL เน้นการให้เหตุผล) และ เส้นทาง Instruct (การปรับให้เหมาะกับผู้ช่วยทั่วไป)

ผลการวิจัยสำคัญ

  • การทดลองยืนยันว่าข้อมูลลำดับการไหลของคอมมิตในรีโพซิทอรีให้ สัญญาณสำหรับการวางแผนงานได้ดีกว่าสแนปช็อตโค้ดแบบสถิต
  • โครงสร้างที่ใส่ข้อมูลการให้เหตุผลและข้อมูลเอเจนต์ในช่วง mid-training หลังจากทำ high-quality code annealing แล้ว ให้ ความเสถียรต่อการเปลี่ยนแปลงของการกระจายข้อมูล
  • ในเส้นทาง Thinking ที่ใช้ RL เน้นการให้เหตุผล พบ ความสามารถในการกู้คืนจากข้อผิดพลาดของตนเองระหว่างงานระยะยาว อย่างชัดเจน

สถาปัตยกรรม LoopCoder

  • นำ โครงสร้าง loop transformer ที่รันบล็อกพารามิเตอร์เดียวกันซ้ำสองครั้งมาใช้
  • ผสาน global attention และ local attention ด้วยกลไก gating เพื่อให้ได้ทั้ง การกลั่นกรองบริบทยาว และ การคงไว้ซึ่งเหตุและผลเชิงลำดับ พร้อมกัน
  • มีเป้าหมายเพื่อรับมือข้อจำกัดของสภาพแวดล้อมการนำไปใช้งาน โดยปรับปรุงประสิทธิภาพการคำนวณเมื่อเทียบกับขนาดโมเดล

องค์ประกอบข้อมูลและกลยุทธ์ pretraining

  • ในการฝึกแบบผสมโค้ดหลายภาษา มีการทำให้ ผลเสริมกันระหว่างภาษา เป็นรูปแบบทางการด้วยกฎการสเกลที่อิงสมการ
  • สร้างข้อมูลแบบ ทริปเปิลเล็ต (R_old, Patch, R_new) โดยใช้คอมมิตในช่วง 40~80% ของวงจรชีวิตรีโพซิทอรี
  • เสริมความสามารถในการเติมโค้ดด้วยเทคนิค Fill-In-the-Middle ระดับไฟล์และระดับรีโพซิทอรี

ผลการประเมิน

  • ทำคะแนน 76.2 บน SWE-Bench Verified และทำผลงานระดับแนวหน้าบนหลายเบนช์มาร์ก เช่น LiveCodeBench v6·Terminal-Bench·Mind2Web
  • มีการประเมินครอบคลุมทั้งการสร้างโค้ด การให้เหตุผล การแก้ไข ประสิทธิภาพ Text-to-SQL และงานแบบเอเจนต์
  • ในบางตัวชี้วัดพบผลลัพธ์ที่ ใกล้เคียงหรือแข่งขันได้กับโมเดลปิด อย่าง Claude Sonnet 4.5 และ GPT-5.1

การประเมินความปลอดภัย

  • บนเบนช์มาร์กด้านความปลอดภัยอย่าง BeaverTails, HarmBench และ TrustLLM โมเดล Thinking ทำผลงานด้วย ความแม่นยำในการปฏิเสธสูงและสมดุลโดยรวมที่ดี
  • นำเสนอผลที่ชี้ว่า RL ที่เน้นการให้เหตุผลส่งผลเชิงบวกต่อด้านความปลอดภัยด้วย

บทสรุป

  • พิสูจน์เชิงประจักษ์ว่าการฝึกที่เน้นลำดับวิวัฒนาการของโค้ดและเส้นทางของเอเจนต์ มีประสิทธิภาพต่อการก่อรูปความฉลาดด้านโค้ดแบบอัตโนมัติ
  • สถาปัตยกรรม LoopCoder นำเสนอ แนวทางการออกแบบ code LLM เชิงปฏิบัติที่คำนึงถึง trade-off ระหว่างประสิทธิภาพและความคุ้มค่า
  • ตั้งเป้าเร่งการวิจัยด้าน code intelligence แบบเปิดและการพัฒนาระบบเอเจนต์จริง ด้วยการเปิดเผยทุกขั้นของการฝึกและเช็กพอยต์

บทความที่เกี่ยวข้อง

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

 
GN⁺ 2026-01-05
ความคิดเห็นบน Hacker News

  • ลิงก์ที่ดีกว่าคือ iquestlab.github.io
    แต่น่าเสียดายที่ดูเหมือนว่าในระหว่างการประเมินผล เอเจนต์ได้โกง

    • ตาม GitHub issue หลังจากแก้การโกงแล้ว ผลลัพธ์ก็ยังดีอยู่
      คะแนนลดจาก 81.4% เหลือ 76.2% แต่ก็ยัง สูงกว่า Opus 4.5 (74.4%)
    • เมื่อไม่กี่วันก่อน ลิงก์นี้ยัง ได้คะแนนโหวตไม่พอ

  • สรุปคือ โมเดลอ้างอิงการแก้ไขจากคอมมิตในอนาคตในลักษณะของ reward hacking เพราะไม่ได้ล้างโฟลเดอร์ .git/
    อยากยกความดีความชอบให้คนที่ช่วยกันแก้ปัญหานี้
    ดูการพูดคุยที่เกี่ยวข้องได้ใน ทวีตนี้ และ กระทู้ Reddit
    เมื่อดูจากที่ IQuestLab เปิดเผยข้อมูล SWE-Bench Verified แล้ว ก็ดูเหมือนเป็น ความผิดพลาดของมือใหม่กับเบนช์มาร์ก มากกว่าจะเป็นการจงใจปั่นผล

    • อย่างที่ John พูดไว้ ปัญหานี้ใน SWE-bench ถูกแก้ไปแล้ว
      แค่ใช้โค้ดล่าสุดแล้วรันการประเมินด้วย Docker image ที่อัปเดตแล้ว ก็พอ
      ทวีตที่เกี่ยวข้อง
    • ฉันก็คิดว่าเป็นแค่ความผิดพลาดธรรมดา แต่ก็น่าเสียดายที่ถ้านักวิจัยได้ลองดูผลลัพธ์ที่ออกมาสักครั้ง ก็น่าจะสังเกตเห็นได้ทันที
    • SWEbench ก็ยังไม่พ้นจาก ข้อถกเถียงเรื่องกระแสเกินจริง อยู่ดี

  • จากประสบการณ์ของฉัน GLM-4.7 (เวอร์ชัน opencode) ใกล้เคียงที่สุดในฝั่งโอเพนซอร์ส
    บางครั้งมีสำนวนที่เหมือนปนข้อมูลของ Claude เลยคิดว่าน่าจะมีการ ใช้ข้อมูลของ Claude อยู่บ้าง

    • แต่ประสิทธิภาพก็ยังห่างจาก Sonnet 4.5 มาก และเทียบกับ Opus ไม่ติดเลย
    • ยังเห็นวลีอย่าง “What’s your use-case?” โผล่มาบ่อย ๆ
      นี่เป็นสำนวนที่ Claude ชอบใช้เพื่อเลี่ยงตอนเริ่มชนข้อจำกัด

  • โมเดล 40B พารามิเตอร์ชนะ Sonnet 4.5 กับ GPT 5.1 เนี่ยนะ? สงสัยว่ามันเป็นไปได้จริงหรือเปล่า

    • เดาของฉันเอง (ไม่แน่ใจ) คืออาจมี ข้อมูลทดสอบรั่ว หรือไม่ก็มีบางส่วนของชุดเบนช์มาร์กหลุดเข้าไปในข้อมูลฝึก
      ถึงอย่างนั้น Sonnet 4.5 ก็เป็นโมเดลที่ค่อนข้างเก่าแล้ว และช่วงหลังมีนวัตกรรมออกมาเยอะ
      น่าสนใจที่โมเดลโอเพนกำลัง ไล่ตาม โมเดลใหญ่ได้เร็วมาก
    • ถึงขั้นมีมุกเล่นคำว่า ชื่อ “IQuest” มัน น่าสงสัย (It's questionable)
    • อาจเป็นไปได้ว่าใช้เทคนิค model pruning ด้วย ทุกวันนี้มีวิธีใหม่ ๆ เยอะมาก
    • แต่สุดท้ายก็พบว่าแท้จริงแล้ว เอเจนต์แฮ็ก evaluation harness

  • มีใครลองรันโมเดลนี้เอง หรือเคยทดสอบผ่าน API แบบโฮสต์ไว้แล้ว บ้างไหม

  • นี่คือ คำกล่าวอ้างเท็จ แล้วทำไมมันยังค้างอยู่บนหน้าหลักก็ไม่เข้าใจ