เนื้อหา
บทความ ปัญหาของ Harness ของ Can Bölük แสดงให้เห็นว่าการแก้ไขแบบ hashline (ยึดกับหมายเลขบรรทัด เช่น 4#WB) ให้ผลดีกว่าการแก้ไขแบบ replace ดั้งเดิม (จับคู่ old_string/new_string) สำหรับเอเจนต์เขียนโค้ด
ผมกำลังทดลองสร้าง harness ของตัวเอง (tau) และอยากตรวจสอบผลนี้เพื่อดูว่าควรพิจารณาใช้ hashline เป็นวิธีแก้ไขเริ่มต้นในนั้นหรือไม่
ผมจึงสร้าง edit-bench เพื่อทดสอบด้วยตัวเองกับหลายภาษาและหลายโมเดล
การตั้งค่าการทดสอบ
edit-bench สร้างการทดสอบโดยดัดแปลงโค้ดจากฐานโค้ดที่มีอยู่ คุณระบุไดเรกทอรีให้สคริปต์ แล้วสคริปต์จะสร้างการดัดแปลง เช่น ลบคำสั่ง กลับค่าบูลีน สลับอาร์กิวเมนต์ เป็นต้น
- ภาษา: Python (จาก hive), TypeScript (จาก oh-my-pi), Rust (จาก irradiate)
- โมเดล:
gpt-4.1-mini,google/gemini-3-flash-preview,qwen/qwen3.5-397b-a17b - โหมดการแก้ไข: replace (old_string/new_string) เทียบกับ hashline (ยึดกับหมายเลขบรรทัด)
- 20 งานต่อภาษา แต่ละงานรันครั้งเดียวและให้ลองเพียงครั้งเดียว
- ผมยังเพิ่งเพิ่มการจับคู่แบบ fuzzy ให้กับ
tau(trim cascade:trim_end → trim_both → unicode normalization) และอยากดูว่าช่วยได้หรือไม่
ผลลัพธ์
โหมด Replace:
| โมเดล | Python | TypeScript | Rust |
|---|---|---|---|
| gemini-3-flash | 95% | 80% | 95% |
| qwen3.5-397b | 90% | 85% | 85% |
| gpt-4.1-mini | 65% | 75% | 45% |
โหมด Hashline (จากการรันทดสอบก่อนหน้านี้):
| โมเดล | Python | TypeScript | Rust |
|---|---|---|---|
| gemini-3-flash | 70% | 85% | 90% |
| qwen3.5-397b | 85% | 85% | 90% |
| gpt-4.1-mini | 50% | 70% | 55% |
Hashline ทำให้ผลของ Python แย่ลงอย่างเห็นได้ชัด และดูเหมือนจะให้ผลแทบไม่ต่างกันใน TypeScript และ Rust การที่ผลขึ้นอยู่กับภาษานั้นน่าสนใจ — การที่ whitespace มีความหมายใน Python อาจทำให้การแก้ไขที่ยึดกับบรรทัดผิดพลาดได้ง่ายขึ้น
การจับคู่แบบ Fuzzy ช่วยได้หรือไม่?
ดูเหมือนจะไม่ช่วย
ผมเพิ่มการเก็บ trace เพื่อดูว่า fuzzy trim cascade ของ tau เคยทำงานระหว่างการรันในโหมด replace หรือไม่ จากการแก้ไขที่สำเร็จ 114 ครั้ง และการแก้ไขที่ล้มเหลว 20 ครั้ง (3 โมเดล × 3 ภาษา) การจับคู่แบบ fuzzy ทำงาน ศูนย์ครั้ง
จากการแก้ไขที่ล้มเหลว 20 ครั้ง:
- 1 ครั้งมี whitespace ต่อท้าย (แก้ได้ในทางทฤษฎี)
- ~8 ครั้งใส่หมายเลขบรรทัดไว้ใน
old_string(ข้อผิดพลาดของโมเดล) - ~11 ครั้งมีเนื้อหาที่โมเดลแต่งขึ้นเองทั้งหมด
เมื่อโมเดลระบุ old_string ได้ถูกต้อง ก็ใส่ whitespace ได้ถูกต้องด้วย
เมื่อโมเดลทำผิด ก็ผิดไปไกลมาก — trim cascade ช่วยไม่ได้
(รายละเอียดการวิเคราะห์ trace)
ข้อสรุปที่ได้
-
ระหว่าง hashline กับ replace ยังไม่มีฝ่ายใดชนะอย่างชัดเจน ผลขึ้นอยู่กับทั้งภาษาและโมเดล Hashline ให้ผลแย่ลงใน Python ส่วน TypeScript ให้ผลไม่ต่างกัน และ Rust ยังไม่ชัดเจนว่าฝ่ายไหนดีกว่า
-
ผลการทดสอบของ Can นำไปใช้สรุปในบริบทอื่นได้ยาก react-edit-benchmark ใช้เฉพาะ JavaScript และใช้ LSP เพื่อให้ข้อมูลย้อนกลับจากการตรวจสอบความถูกต้อง การตั้งค่าการทดสอบของเรา (ไม่มี LSP และใช้หลายภาษา) ให้ภาพที่ต่างออกไป โดยเฉพาะวงจรข้อมูลย้อนกลับจาก LSP น่าจะเป็นตัวแปรกวน การให้โมเดลได้รับข้อผิดพลาดด้านชนิดข้อมูลเพื่อลองแก้ไขใหม่ช่วยเพิ่มประสิทธิภาพได้มากพอสมควร และส่งผลร่วมกับรูปแบบการแก้ไข
-
โมเดลปัจจุบันไม่มีปัญหาที่ต้องแก้ด้วยการจับคู่แบบ fuzzy LLM จะสร้างข้อความต้นฉบับได้ตรงทุกตัวอักษร หรือไม่ก็แต่งข้อความที่ต่างไปโดยสิ้นเชิงขึ้นมา กรณีที่เกือบตรงแต่ผิดแค่ whitespace ซึ่งการจับคู่แบบ fuzzy มุ่งแก้นั้น แทบไม่เกิดขึ้นในการใช้งานจริง
-
สำหรับโมเดลรุ่นปัจจุบันที่ใช้กับ harness ในยุคนี้ รูปแบบการแก้ไขไม่ใช่คอขวด ช่องว่างระหว่างโมเดล (gemini-3-flash ที่ 90%+ เทียบกับ gpt-4.1-mini ที่ 55-65%) ใหญ่กว่าช่องว่างระหว่างรูปแบบการแก้ไขมาก ควรทุ่มเทกับการเลือกโมเดลและการออกแบบพรอมป์ต์ก่อนที่จะกังวลเรื่องรูปแบบการแก้ไข
คำชี้แจงที่ต้องมี: n น้อย ไม่ได้เข้มงวดทางสถิติ จึงควรตีความโดยคำนึงถึงเรื่องนี้
ข้อมูลทั้งหมด: nwyin/edit-bench, ประเด็น #13 และ #14