ปรับปรุงประสิทธิภาพการเขียนโค้ดของ LLM 15 ตัวได้ สิ่งที่เปลี่ยนมีแค่ harness

• เมื่อนำ LLM หลายตัวมาทดสอบภายใต้เงื่อนไขเดียวกัน พบว่าเพียงแค่เปลี่ยน เครื่องมือแก้ไขโค้ด ก็ช่วยเพิ่มประสิทธิภาพได้อย่างมาก
• แทนที่จะใช้วิธี Patch·Replace แบบเดิม ได้มีการใช้ฟอร์แมต ‘Hashline’ ที่กำหนดแฮชแท็กให้แต่ละบรรทัดของโค้ด เพื่อเพิ่มความแม่นยำในการแก้ไข
• Hashline ให้ความแม่นยำสูงกว่าวิธีเดิมใน 14 จาก 16 โมเดล และยังยืนยันได้ว่าช่วย ลดโทเค็นเฉลี่ย 20~30%
• โดยเฉพาะโมเดล Grok Code Fast 1 ที่มีอัตราความสำเร็จพุ่งจาก 6.7% เป็น 68.3% ดีขึ้น 10 เท่าเพียงแค่เปลี่ยน harness
• งานวิจัยนี้ชี้ให้เห็นว่า ‘harness’ คือคอขวดของประสิทธิภาพจริง มากกว่าตัวโมเดลเอง และเน้นย้ำถึงความจำเป็นของการทำงานร่วมกันในระบบนิเวศโอเพนซอร์ส

---

ภาพรวมของเบนช์มาร์กการแก้ไขโค้ด

• การทดลองดำเนินในรูปแบบการเปรียบเทียบฟอร์แมตการแก้ไข 3 แบบ ได้แก่ Patch, Replace, Hashline
  • ให้ 16 โมเดลดำเนินโจทย์แก้ไขโค้ดเดียวกัน
  • แต่ละโมเดลถูกทดสอบด้วยการแก้บั๊กในไฟล์ที่สุ่มเลือกจากโค้ดเบส React
• ฟอร์แมต Hashline ให้ผลดีกว่า Patch ใน 14 โมเดล และโดยเฉลี่ยประหยัดโทเค็นได้ 20~30%
  • การปรับปรุงที่มากที่สุดคือโมเดล Grok Code Fast 1 โดยอัตราความสำเร็จเพิ่มจาก 6.7% เป็น 68.3% (+61.6pp)
  • Gemini 3 Flash เพิ่มขึ้น 5.0pp และ Claude Sonnet 4.5 เพิ่มขึ้น 1.6pp

ปัญหาเรื่อง harness

• ปัจจุบันการถกเถียงมักมุ่งไปที่ “โมเดลไหนเขียนโค้ดเก่งที่สุด” แต่คอขวดที่แท้จริงคือ harness ไม่ใช่โมเดล
  • harness คืออินเทอร์เฟซหลักที่จัดการโทเค็นอินพุต และเชื่อมผลลัพธ์ของโมเดลเข้ากับการเปลี่ยนแปลงในเวิร์กสเปซ
  • ความล้มเหลวส่วนใหญ่ไม่ได้เกิดจากโมเดล แต่เกิดจากข้อจำกัดเชิงโครงสร้างของ harness
• ผู้เขียนได้ลองปรับปรุงผ่านโปรเจกต์ส่วนตัว oh-my-pi ซึ่ง fork มาจากเอเจนต์เขียนโค้ดโอเพนซอร์ส Pi โดยทำคอมมิตไปราว 1,300 ครั้ง
  • สภาพแวดล้อมนี้เป็นอิสระจากตัวโมเดล ทำให้ทดลองโดยเปลี่ยนเฉพาะ harness ได้

ข้อจำกัดของเครื่องมือแก้ไขแบบเดิม

• วิธี apply_patch ของ Codex ใช้ฟอร์แมต diff เฉพาะของ OpenAI จึงมีอัตราล้มเหลวสูงเมื่อใช้กับโมเดลอื่น
  • ตัวอย่าง: Grok 4 มีอัตราล้มเหลวของ patch ที่ 50.7% และ GLM-4.7 อยู่ที่ 46.2%
• วิธี str_replace ของ Claude Code ต้องตรงกับสตริงเดิมแบบสมบูรณ์ ทำให้เกิดข้อผิดพลาดจากความต่างของช่องว่างหรือการเยื้อง
  • มีรายงานข้อผิดพลาด “String to replace not found in file” จำนวนมากบน GitHub
• Cursor ฝึกโมเดล 70B แยกต่างหากเพื่อจัดการการรวมโค้ด แต่ในไฟล์ที่มีไม่เกิน 400 บรรทัด การเขียนใหม่ทั้งหมด (full rewrite) กลับให้ผลดีกว่า
• งานวิจัย Diff-XYZ และ EDIT-Bench ของ JetBrains ก็ยืนยันเช่นกันว่าประสิทธิภาพต่างกันมากตามฟอร์แมตการแก้ไข

หลักการของวิธี Hashline

• แต่ละบรรทัดของโค้ดจะถูกกำหนด คอนเทนต์แฮชความยาว 2~3 ตัวอักษร เพื่อให้โมเดลระบุตำแหน่งที่ต้องแก้ได้อย่างชัดเจน
  • ตัวอย่าง: 22:f1| return "world";
  • โมเดลจะสั่งแก้โดยอิงจากแฮช เช่น “replace line 2:f1”
• หากไฟล์มีการเปลี่ยนแปลงจนแฮชไม่ตรงกัน การแก้ไขจะถูกปฏิเสธเพื่อป้องกันความเสียหาย
• วิธีนี้ทำให้โมเดลไม่จำเป็นต้องสร้างเนื้อหาเดิมซ้ำ จึงลดข้อผิดพลาดเรื่องช่องว่างและการเยื้อง และทำให้การแก้ไขเสถียรมากขึ้น

ผลลัพธ์ของเบนช์มาร์ก

• การทดสอบประกอบด้วยโจทย์แก้บั๊ก 180 ข้อ ทำซ้ำ 3 รอบ และใช้เครื่องมือ 4 อย่าง (read, edit, write, etc.)
• โดยสรุป ฟอร์แมต Patch แย่ที่สุดในแทบทุกโมเดล ขณะที่ Hashline ให้ผลเทียบเท่าหรือดีกว่า Replace
  • ยิ่งเป็นโมเดลที่อ่อนกว่า ก็ยิ่งเห็นขนาดของการปรับปรุงชัดเจน
  • Grok 4 Fast ลดโทเค็นเอาต์พุตได้ 61% และ MiniMax ดีขึ้นมากกว่าสองเท่า
• อัตราความสำเร็จของ Gemini เพิ่มขึ้น +8% ซึ่งมากกว่าการอัปเกรดโมเดลทั่วไป และทำได้โดยไม่ต้องฝึกเพิ่ม

นโยบายของผู้ขายและระบบนิเวศโอเพนซอร์ส

• Anthropic บล็อกการเข้าถึง Claude Code ของเอเจนต์เขียนโค้ดโอเพนซอร์ส OpenCode
  • เหตุผลคือ “การย้อนรอยวิศวกรรม API แบบปิด” แต่ในทางปฏิบัติถูกตีความว่าเป็นสัญญาณว่า “ให้ใช้เฉพาะ harness ของตัวเอง”
• Google บล็อกบัญชีของผู้เขียน ทำให้ไม่สามารถเข้าถึง Gemini ได้
  • เหตุการณ์นี้เกิดขึ้นไม่นานหลังเบนช์มาร์กที่แสดงว่า Gemini 3 Flash มีประสิทธิภาพเพิ่มเป็น 78.3% เมื่อใช้ Hashline
• ผู้เขียนชี้ว่ามาตรการเหล่านี้เป็น การกระทำที่ถอยหลังและขัดขวางโอกาสในการพัฒนาโมเดล
  • การเพิ่มประสิทธิภาพ harness เป็นงานวิจัยสาธารณะที่ช่วยยกระดับคุณภาพของทุกโมเดล ไม่ใช่แค่โมเดลใดโมเดลหนึ่ง
  • เขาสรุปด้วยวลีว่า “โมเดลคือคูเมือง ส่วน harness คือสะพาน” เพื่อชี้ว่าความปิดกั้นแบบนี้ขัดขวางการเติบโตของระบบนิเวศ

บทสรุป

• ปัญหาเรื่อง harness ได้รับการยืนยันว่าเป็น ปัจจัยที่วัดผลได้และส่งผลโดยตรงต่อประสิทธิภาพจริง
• เพียงเปลี่ยนฟอร์แมตอย่างง่ายก็สามารถให้ผลการปรับปรุงในระดับใกล้เคียงกับการอัปเกรดโมเดลได้
• ทิศทางการพัฒนาในอนาคตควรเป็น ความร่วมมือแบบเปิดที่ขับเคลื่อนโดยชุมชน ไม่ใช่ การปรับปรุงแบบปิดของบริษัทเดียว
• โค้ด เบนช์มาร์ก และผลการรันทั้งหมดถูกเปิดเผยไว้ใน GitHub รีโพซิทอรี oh-my-pi

[github88]

โมเดลมันแปลก ๆ อยู่แล้ว ทำไมยังต้องมานั่งทำ prompt engineering อีกรอบ..

[cosine20]

ฮาร์เนสกับการทำ prompt engineering เป็นคนละเรื่องกันโดยสิ้นเชิง

[GN⁺]

ความคิดเห็นจาก Hacker News

• ฉันอ่านบทความนี้แล้วรู้สึกว่าน่าสนใจมาก คิดว่าผู้เขียน ชี้ประเด็นสำคัญได้ตรงมาก
  แม้แต่โมเดลที่มีอยู่ตอนนี้เอง ก็ยังมีพื้นที่ให้ทำงานได้มีประสิทธิภาพขึ้นมาก ขึ้นอยู่กับว่าเราออกแบบ agent harness อย่างไร
  ฉันคิดว่าการมอง “AI” เป็นแค่ตัว LLM อย่างเดียวไม่ถูกนัก แต่ควรมองเป็น ระบบไซเบอร์เนติกทั้งระบบ ที่ LLM กับ harness เชื่อมกันด้วย feedback loop
  โมเดลกับ harness เป็นโครงสร้างที่เสริมแรงกันและพัฒนาไปด้วยกัน ดังนั้นทั้งสองอย่างจึงสำคัญพอๆ กัน
  มุมมองแบบนี้ไม่ได้ช่วยแค่เรื่องเพิ่มประสิทธิภาพ แต่ยังทำให้เราตีความ generative AI ใหม่เป็นโครงการแบบ neurosymbolic ได้ด้วย

  • ผมคิดว่าตอนนี้แค่ GPT-4 ก็สร้างอะไรได้เยอะมากแล้ว
    ผมเคยสร้าง coding agent โดยใช้ GPT-4 เวอร์ชันปี 2023 จริงๆ
    พอทำงานกับโมเดลเก่า เราจำเป็นต้องรักษาความเรียบง่ายไว้ เลยทำให้มองปัญหาในอีกแบบหนึ่ง
    ตัวอย่างเช่น ใน Python การทำ semantic compression แบบง่ายๆ อย่าง grep -r def . เป็นสิ่งจำเป็น
    ถ้าเพิ่ม hook ง่ายๆ แบบนี้เข้าไปในเครื่องมืออย่าง Claude Code ก็จะเข้าใจโครงสร้างโค้ดได้ทันทีโดยไม่เปลืองโทเคน
  • ผมกำลังทำ CLI ชื่อ Peen เป็นเครื่องมือที่ช่วยให้โมเดล Ollama แบบรันบนเครื่องเรียกใช้ tool ได้มีประสิทธิภาพ
    แค่ปรับแต่ง prompt ไม่กี่ชั่วโมงและเขียนโค้ดจัดการ response เพิ่มอีกหน่อย คุณภาพ output ของโมเดลเล็กแบบ local ก็ดีขึ้นอย่างน่าทึ่ง
    ลิงก์ GitHub
  • Harness ของ Claude Code และ OpenAI Codex ก็กำลังพัฒนาตัวเองอยู่เหมือนกัน
    OpenAI ใช้ GPT-5.3-Codex เวอร์ชันแรกๆ ดีบักกระบวนการฝึกของตัวเองและจัดการ deployment
    Claude Code ส่ง PR มากกว่า 20 รายการต่อวันโดย สร้างโค้ดของตัวเองทั้งหมด
  • ขอเสริมนิดหนึ่งว่า สำนวนเขียนของผมมักใช้โครงแบบ “It’s not just X, it’s Y” บ่อย แต่เป็นเพราะผมเหนื่อย ไม่ใช่เพราะ LLM เขียน
  • ถ้าอ่านเอกสารของ SWE-bench จะเห็นว่ามีการใช้ context engineering ที่แทบจะดูตามอำเภอใจ
    ที่จริงเรายังไม่ค่อยรู้ด้วยซ้ำว่าโมเดลไหนไวต่อ context engineering ที่ดีมากน้อยแค่ไหน
    แต่ผมเห็นด้วยว่ามันยังมี low hanging fruit อยู่เยอะมากแน่นอน

• เทคโนโลยีนี้น่าสนใจ แต่ก็ให้ความรู้สึกว่า ถูกประเมินค่าสูงเกินไป
  ผู้เขียนเห็นการปรับปรุง 5% ใน benchmark แบบ find/replace ง่ายๆ ที่ตัวเองทำขึ้น แล้วพูดเหมือนกับว่าประสิทธิภาพโดยรวมเพิ่มขึ้น 14 จุด
  ในความเป็นจริง มันอาจเป็นการปรับปรุงด้านประสิทธิภาพการใช้โทเคนรวมไม่ถึง 1% ด้วยซ้ำ
  แถมน้ำเสียงในบทความที่ พูดเกินจริง และสำนวนแบบ ChatGPT ยังทำให้ความน่าเชื่อถือลดลง

  • ถ้าเป็นฟอร์แมตอย่าง “replace line 2:f1…” ประสิทธิภาพจริงอาจสูงกว่า 20% มากก็ได้
  • ใน benchmark บอกว่าการใช้โทเคนลดลง 25~50% แต่ก็ยังสงสัยว่าในสภาพแวดล้อมการใช้งานจริงจะได้ผลขนาดนั้นหรือเปล่า

• บทความนี้แสดงให้เห็นชัดว่าระดับ harness ยังมี พื้นที่ให้ปรับปรุง ได้มากแค่ไหน
  agent เปลืองโทเคนไปมากกับการแก้ไข การ sandbox และการส่งผ่านข้อมูลระหว่าง tool call
  การจับคู่กันของ การอ้างอิงตามเนื้อหา + การใส่เลขบรรทัด ทั้งใช้งานได้จริงและสวยงาม

  • ความสิ้นเปลืองที่ใหญ่ที่สุดอาจเป็นการใช้ MCP ทุกที่
    มันทำให้การพัฒนาเริ่มต้นง่ายขึ้น แต่กลับไม่มีประสิทธิภาพเพราะต้องเรียกโมเดลใหญ่โดยไม่จำเป็น
  • ผมเคยลองปลั๊กอิน ClaudeCode Superpowers ฟีเจอร์ดีนะ แต่ ค่าใช้จ่ายสูงมาก
    ใน CC มีคำสั่ง /cost ให้ดูค่าใช้จ่ายต่อ session ได้ ดังนั้นน่าจะใช้ตัวชี้วัดแบบนี้ประเมินประสิทธิภาพของปลั๊กอินได้
  • ในทางกลับกัน ก็อาจใช้โทเคนมากขึ้นเพื่อแก้ปัญหาซับซ้อนด้วยการ แบ่งเป็นปัญหาย่อยขนาดเล็ก ได้เช่นกัน

• ความสำคัญของ harness นั้นมากกว่าที่คนส่วนใหญ่คิดไว้เยอะมาก
  ตัวอย่างเช่น คะแนน benchmark CORE ของ Opus พอเปลี่ยนจาก harness ภายในของตัวเองมาเป็น Claude Code ก็แทบจะเพิ่มเป็นสองเท่า
  ลิงก์ที่เกี่ยวข้อง

  • ในบล็อกโพสต์ ของ Mario ผู้สร้าง Pi terminal agent ก็อธิบายเหมือนกันว่า
    คะแนนสูงสุดของ TerminalBench เกิดขึ้นได้เพราะ harness Terminus 2
  • เพราะงั้นเราควรจะเปลี่ยน harness ได้อย่างอิสระหรือสร้างเองได้
    การถูกผูกกับ harness ตัวใดตัวหนึ่งเพียงเพราะค่าสมัครสมาชิกรายเดือน 20 ดอลลาร์นั้นไม่สมเหตุสมผล

• ผมทำเครื่องมือชื่อ tilth ที่ใช้แนวทางอ่าน/แก้ไขแบบอิง hash
  ติดตั้งได้ผ่าน npm และ cargo และเชื่อมกับ editor อย่าง Claude Code หรือ Cursor ได้
  ลิงก์ GitHub
  เป้าหมายคือช่วยให้ LLM ใช้ tool ได้มีประสิทธิภาพขึ้นและลดการเปลืองโทเคน

  • น่าจะเอาไปใช้กับ Markdown ได้ด้วย ถ้าเพิ่ม การอ้างอิงระดับ section ก็จะทำให้เสถียรขึ้นระหว่างเวอร์ชัน
  • การเปรียบเทียบ benchmark กับ grep ก็น่าสนใจเหมือนกัน

• ผมก็คิดวิธีคล้ายๆ กันขึ้นมาได้อย่างอิสระ แต่สุดท้ายเลิกใช้เพราะ การพึ่งพา abstraction
  ผมหันไปใช้ ระยะ Damerau-Levenshtein เพื่อคำนวณความคล้ายคลึงของการแก้ไข แล้วถ้าเกิน threshold ที่กำหนดก็ให้การแก้ไขผ่านได้
  วิธีนี้ทำให้โมเดลต้องพิมพ์ source token ที่จะถูกแทนที่ออกมาอย่างชัดเจน เลยเพิ่มความแม่นยำได้
  ตัวอย่างโค้ด
  แก่นสำคัญคือข้อความ error ต้องเจาะจง — การจัดการ error แบบมี คำสั่งสำหรับกู้คืน อย่าง “Content mismatch. Reread the file” นั้นสำคัญมาก
  วิธีนี้ใช้ได้ดีแม้กับโมเดล 4B และสำหรับโมเดลที่ไม่รองรับ tool call ก็รับมือด้วย การแฮ็กฉีด system prompt
  โค้ดที่เกี่ยวข้อง

• แม้แต่โมเดลเก่าๆ ก็ยังให้ผลลัพธ์ที่ค่อนข้างแม่นยำได้
  แก่นสำคัญคือการ “จัดการโมเดลให้ถูกวิธี”
  บทความนี้ชี้เป็นนัยว่า ถ้าโมเดลไม่ได้จัดการแค่ข้อความ แต่จัดการ การแทนโครงสร้างของ source code (AST) ได้โดยตรง ก็จะได้ผลลัพธ์ที่ดียิ่งกว่า
  ตัวอย่างเช่น OpenRewrite ใช้ Lossless Semantic Tree ที่รวมทั้งชนิดข้อมูลของโค้ด รูปแบบ และข้อมูล dependency เอาไว้ครบ
  ถ้าโมเดลใช้โครงสร้างแบบนี้ได้ ก็จะทำการแก้ไขได้แม่นยำมากโดยไม่เปลืองโทเคนโดยไม่จำเป็น
  ท้ายที่สุดแล้ว นี่ก็เหมือนเหตุผลที่คำตอบของการถกเถียง “Vim vs Emacs” คือ “IntelliJ” — ข้อมูลเชิงโครงสร้างคืออาวุธทรงพลัง
  ถ้าโมเดลได้เรียนรู้ทั้งโค้ด เอกสาร และ syntax/semantic tree ไปพร้อมกัน มันก็จะกลายเป็น โมเดลเขียนโค้ดแบบ neurosymbolic อย่างแท้จริง

• ผมทดลองใช้ LLM กับ gptel บน Emacs แล้วพบว่า LLM แก้โค้ดด้วยเครื่องมือ Unix patch ได้ไม่ค่อยดี
  เลยสร้าง tool สำหรับ gptel ขึ้นมาเองโดยใช้ tree-sitter ของ Emacs
  พอให้มันแก้ AST node โดยตรงด้วยคำสั่งอย่าง tree_sitter_list_nodes, tree_sitter_update_nodes ก็ทำงานได้สมบูรณ์แบบ

  • น่าสนใจมาก อยากรู้ว่าสามารถแชร์โค้ดนั้นได้ไหม

• apply_patch ของ Codex จริงๆ แล้วใช้ schema การสุ่มตัวอย่างแบบมีข้อจำกัด
  โค้ดที่เกี่ยวข้อง
  ผู้เขียนไม่รู้เรื่องนี้แล้วเอามาเปรียบเทียบแบบตรงๆ ดังนั้น benchmark ที่สมจริงกว่าควรทำในสภาพที่เปิด schema นี้ไว้ด้วย

• มีช่วงหนึ่งในคำคมของบทความนี้ที่ผมประทับใจเป็นพิเศษ
  “ปัญหาไม่ใช่ว่าโมเดลไม่เข้าใจโจทย์ แต่คือ รูปแบบการแทนที่ไม่เสถียร อย่าโทษนักบินเพราะปัญหาที่ชุดลงจอด”
  “โมเดลคือ moat, harness คือ bridge”
  “ความต่างระหว่างเดโมที่เท่กับเครื่องมือที่เชื่อถือได้ ไม่ใช่เวทมนตร์ แต่คือ วิศวกรรมที่น่าเบื่อแต่ประณีต”

  • เห็นด้วยมาก นี่ไม่ใช่แค่คำแนะนำธรรมดา แต่เหมือน งานศิลปะเชิงเทคนิค ที่ถ่ายทอดวิธีคิดของผู้เขียนออกมาอย่างมีชีวิตชีวา
  • ประโยคที่ผมชอบที่สุดคือ “นั่นไม่ใช่ภัยคุกคาม แต่มันคือ R&D ฟรี”