Deletion avoidance

Deletion avoidance เป็นชื่อที่ผู้เขียนเปเปอร์ "To Add Is Machine, To Delete Is Human: Measuring and Mitigating Deletion Avoidance in LLM Code Editing" ตั้งให้กับอาการที่คนใช้ AI เขียนโค้ดบ่นกันมานานแต่ยังไม่มีชื่อเรียก เปเปอร์ส่งขึ้น arXiv เมื่อ 30 กรกฎาคม 2026 และนิยามคำนี้ไว้ว่า "deletion avoidance, the systematic tendency to retain code that an intended edit requires removing" แปลว่าเป็นแนวโน้มอย่างเป็นระบบที่โมเดลจะเก็บโค้ดเดิมไว้ ทั้งที่การแก้ที่ถูกต้องต้องลบมันทิ้ง สิ่งที่โมเดลเลือกทำแทนคือเอาโค้ดเป้าหมายไปครอบด้วยเงื่อนไขหรือทางสำรอง ซึ่งผู้เขียนตั้งชื่อรูปแบบนี้ว่า Guard-and-Go ผลลัพธ์คือ patch ผ่านเทสต์ ฟีเจอร์ทำงาน แต่โค้ดที่ควรหายไปยังอยู่ครบ

ตัวเลขจากการวัดชี้ว่าปัญหานี้ไม่ใช่เรื่องบังเอิญ ผู้เขียนทดสอบโมเดลห้าอันดับแรกบนกระดาน SWE-bench Verified อย่างเป็นทางการ แล้วพบว่าแม้ในโจทย์ที่ทั้งห้าตัวแก้ผ่านหมด ความสามารถในการลบให้ครบเทียบกับสิ่งที่นักพัฒนาจริงลบยังทำได้สูงสุดแค่ 71.7% ที่น่าสนใจกว่านั้นคือโมเดลรู้ว่าปัญหาอยู่ที่ไหนแต่ลงมือไม่ตรง มันหาไฟล์ที่ต้องแก้ถูกเกิน 92% ของกรณีที่ต้องลบ แต่ตัดบรรทัดที่ถูกต้องจริงได้ไม่ถึง 52% และ 29.0% ของ patch ที่สอบผ่านใช้รูปแบบ Guard-and-Go สาเหตุที่วิธีนี้รอดมาตลอดคือเทสต์เดิมแทบไม่เคยตรวจว่าของเก่าหายไปหรือยัง เมื่อผู้เขียนเอาโจทย์ 34 ข้อมาเติมเทสต์ที่จะไม่ผ่านถ้าโค้ดเป้าหมายยังอยู่ โมเดลระดับแนวหน้าสี่ตัวทั้งแบบปิดและแบบเปิดตกจาก 63.2% เหลือ 41.9% และเมื่อสร้างชุดทดสอบใหม่ชื่อ CanItDelete ที่รวบรวม 200 โจทย์จาก commit จริงซึ่งงานทั้งหมดคือการลบล้วน โมเดลที่ดีที่สุดยังพลาดหนึ่งในห้าข้อ ส่วนโมเดลเปิดขนาดเล็กเหลือ 18.0%

สิ่งที่คำนี้อธิบายได้ตรงที่สุดคือประสบการณ์ของทีมพัฒนาที่เริ่มให้ AI แก้โค้ดจริง คือเทสต์เขียว ฟีเจอร์ใช้ได้ แต่ผ่านไปหกเดือนไม่มีใครกล้าแตะไฟล์นั้นเพราะไม่รู้ว่าเงื่อนไขที่ซ้อนกันอยู่ทำอะไรบ้าง เปเปอร์ชี้ว่ารากของปัญหาอยู่ที่วิธีที่เราตัดสินว่างานเสร็จ เพราะเทสต์ตอบได้แค่ว่าของใหม่ทำงานไหม แต่ไม่ได้ตอบว่าของเก่าหายไปหรือยัง สิ่งที่ทำได้ทันทีมีสองอย่าง อย่างแรกคือเวลาสั่งให้ลบอะไร ให้ระบุชัดว่าต้องไม่เหลือโค้ดนั้นในไฟล์ ไม่ใช่แค่สั่งให้เลิกใช้ อย่างที่สองคือเวลารีวิว patch ให้ดูจำนวนบรรทัดที่ถูกลบด้วย เพราะ patch ที่มีแต่การเพิ่มโดยไม่มีการลบเลยในงานที่ควรมีการลบ คือสัญญาณของอาการนี้พอดี ข้อควรระวังคือขอบเขตของงานนี้อยู่บน SWE-bench Verified เป็นหลัก ส่วนการทดลองเติมเทสต์ใช้แค่ 34 โจทย์กับ 4 โมเดล และวิธีแก้ที่เสนอคือการสอนเรื่องการลบตอนเทรนเพิ่มนั้น ผู้เขียนเรียกเองว่าเป็นการศึกษานำร่อง แต่ข้อสรุปของเขาก็ให้ความหวังว่า "teaching deletion during post-training reduces deletion avoidance and improves broader code-editing performance, suggesting the behavior is undertrained rather than beyond reach"

ตัวอย่างจากบทสนทนาจริง

นักพัฒนา: "พี่ครับ ผมสั่งให้ agent เอา logic การคิดส่วนลดแบบเก่าออก มันบอกว่าเสร็จแล้วและเทสต์ผ่านหมด แต่ผมเปิดไฟล์ดูแล้วโค้ดเก่ายังอยู่ครบเลย มันแค่เติม if ครอบไว้"

หัวหน้าทีม: "อันนี้คืออาการที่เขาเรียกว่า deletion avoidance ครับ มีเปเปอร์วัดออกมาแล้วว่าโมเดลแนวหน้าลบได้ครบสูงสุดแค่เจ็ดสิบกว่าเปอร์เซ็นต์ แล้วเกือบสามสิบเปอร์เซ็นต์ของ patch ที่ผ่านเทสต์ใช้วิธีครอบเงื่อนไขแบบที่น้องเจอนี่แหละ วิธีแก้คือสั่งใหม่ให้ชัดว่าห้ามเหลือฟังก์ชันนั้นในไฟล์ แล้วเวลารีวิวให้ดูเลขบรรทัดที่ลบด้วย ถ้ามีแต่บวกไม่มีลบทั้งที่งานคือการลบ แปลว่ายังไม่จบ"

ระวังสับสนกับ

• ai-slop : AI slop เป็นคำกว้างสำหรับเนื้อหาหรือโค้ดคุณภาพต่ำที่ AI ผลิตออกมาปริมาณมาก ส่วน deletion avoidance คือกลไกเฉพาะเจาะจงอย่างหนึ่งที่ทำให้ codebase บวมขึ้น และเป็นอาการที่วัดเป็นตัวเลขได้
• hallucination : hallucination คือการที่โมเดลแต่งข้อมูลที่ไม่มีอยู่จริงขึ้นมา ส่วน deletion avoidance ไม่ได้แต่งอะไร โค้ดที่มันเขียนถูกต้องและทำงานได้จริง ปัญหาอยู่ที่มันไม่ยอมเอาของเก่าออก
• evals : evals คือชุดวิธีวัดความสามารถของโมเดล ซึ่งงานนี้ชี้ว่าเป็นต้นตอส่วนหนึ่งของปัญหา เพราะเทสต์ที่ใช้กันตรวจแค่ว่าของใหม่ทำงานไหม จึงมองไม่เห็นอาการนี้มาตลอด