# AI จะแก้ไขโค้ดโดยไม่สร้างโปรแกรมทั้งชุดขึ้นใหม่ได้อย่างไร

Canonical HTML: https://aogavrilov.com/th/projects/discrete-latent-generation/

Document language: th

คู่มือวิจัยเชิงปฏิบัติสําหรับการปรับแก้โค้ดเฉพาะบริเวณด้วยแบบจําลองเชิงกําเนิด: สิ่งใดควรคงเดิม สิ่งใดเปลี่ยนแปลงได้ และต้องมีหลักฐานใดก่อนเรียกการแปลงนั้นว่าเป็นการคงโครงสร้าง

เผยแพร่แล้ว 25 กรกฎาคม 2026 ปรับปรุงล่าสุด 30 กรกฎาคม 2026 [Alexey Gavrilov](https://aogavrilov.com/about/)

## สาระที่แท้จริงของปัญหา

การแก้ไขโค้ดมิใช่เพียงการสร้างโค้ดด้วยพรอมป์ที่สั้นลง ตัวแก้ไขได้รับทั้งชิ้นงานเดิม การเปลี่ยนแปลงที่ต้องการ และข้อตกลงการรักษาโดยนัย ดังนั้น คําถามหลักจึงมีสองด้าน: **บริเวณใดเปลี่ยนแปลงได้ และคุณสมบัติใดของส่วนที่เหลือต้องคงเสถียร**

คู่มือนี้มุ่งสําหรับผู้อ่านที่มีพื้นฐานทางเทคนิคและเริ่มศึกษาการแก้ไขซอฟต์แวร์ด้วยความช่วยเหลือของ AI โดยแยกแนวคิดเชิงสัญชาตญาณของการแก้ไขเฉพาะที่ออกจากข้อกล่าวอ้างที่เข้มกว่าเกี่ยวกับการคงไว้ซึ่งวากยสัมพันธ์ โครงสร้าง ความหมาย และการทํางาน

## แนวคิดหลัก

ตัวแก้ไขที่มีขอบเขตจําเป็นต้องมีขอบเขตการคงสภาพที่ระบุชัดเจน มิใช่มีเพียงเป้าหมายการสร้าง

### สิ่งที่ต้องคงที่

สิ่งนี้อาจเป็นช่วงข้อความ ไวยากรณ์ ลายเซ็น API บริเวณ AST พฤติกรรมการทดสอบ ข้อตกลงการพึ่งพา หรือภาพแทนระดับหยาบที่เรียนรู้ แต่ละทางเลือกปกป้องนิยามของเสถียรภาพที่แตกต่างกัน

### สิ่งที่อาจเปลี่ยนแปลง

บริเวณที่แก้ไขได้ต้องมีเสรีภาพเพียงพอสําหรับแก้โจทย์ที่ร้องขอ วิธีควบคุมที่คัดลอกทุกอย่างย่อมเสถียรแต่ไร้ประโยชน์ ส่วนวิธีที่เขียนใหม่ทั้งหมดให้เสรีภาพแต่ปราศจากความเป็นเฉพาะที่

## แบบจําลองเชิงอุปมา: ปรับปรุงหนึ่งห้อง โดยคงอาคารไว้

ลองนึกถึงการปรับปรุงห้องหนึ่งโดยไม่กระทบโครงสร้างรับน้ําหนัก จุดเชื่อมต่อระบบประปา และห้องข้างเคียง การสร้างใหม่ทั้งหมดเปรียบเสมือนการสร้างบ้านขึ้นใหม่จากคําบรรยาย ส่วนการแก้ไขเฉพาะบริเวณจะระบุโครงสร้างที่ต้องคุ้มครอง เปิดพื้นที่ทํางานที่มีขอบเขต ดําเนินการเปลี่ยนแปลง และตรวจสอบผลก่อนยอมรับ

**จุดที่การเปรียบเทียบเทียบเคียงใช้ไม่ได้** รหัสแฝงที่เรียนรู้มิใช่แบบแปลนสถาปัตยกรรมที่ผ่านการรับรอง การตรึงรหัสระดับหยาบอาจเพิ่มเสถียรภาพเชิงโครงสร้างที่วัดได้ แต่ไม่รับประกันว่าโหนด AST พฤติกรรม หรือส่วนต่อประสานใดโดยเฉพาะจะไม่เปลี่ยนแปลง

## มุมมองที่แม่นยํายิ่งขึ้นต่อการสร้างใหม่บางส่วน

กําหนดให้ตัวเข้ารหัสแมปโปรแกรม `x` ไปเป็นภาพแทนแฝงที่มีโครงสร้าง `z` . มาสก์การคงสภาพเลือกตําแหน่ง `L` ให้คงที่ ตัวสร้างจะสุ่มเฉพาะตําแหน่งส่วนเติมเต็มพร้อมทั้งบังคับใช้ `z'l = zl` สําหรับทุกตําแหน่งที่ตรึงไว้ จากนั้นตัวถอดรหัสจะแปลงการแทนที่เสร็จสมบูรณ์แล้ว `z'` กลับเป็นซอร์สโค้ด

กลไกนี้สร้างส่วนต่อประสานการควบคุมเหนือระดับโทเค็นที่ตรวจสอบได้ แต่ยังต้องพิสูจน์ความหมายของมันเชิงประจักษ์ โดยทดสอบว่าตําแหน่งที่ตรึงไว้คงสิ่งใดได้บ้างหลังการถอดรหัส และตําแหน่งที่แก้ไขได้ยังมีความยืดหยุ่นเพียงพอหรือไม่

## เวิร์กโฟลว์การแก้ไขสี่ขั้น

1. กําหนดขอบเขต ระบุบริเวณหรือคุณสมบัติที่ต้องคุ้มครอง และกําหนดการเปลี่ยนแปลงที่มุ่งหมาย
2. สร้างตัวแทนของสิ่งประดิษฐ์ ใช้ข้อความ วากยสัมพันธ์ บริบทจากการค้นคืน หรือรหัสระดับหยาบและละเอียดที่เรียนรู้
3. สร้างขึ้นใหม่เฉพาะส่วน สุ่มตัวอย่างเฉพาะตําแหน่งที่แก้ไขได้โดยคงข้อจํากัดที่เลือกไว้
4. ตรวจสอบก่อนยอมรับ วัดความเฉพาะที่ วากยสัมพันธ์ โครงสร้าง พฤติกรรม และผลข้างเคียงที่ไม่ได้ตั้งใจ

## การแก้ไขโค้ด การซ่อมแซมโปรแกรม และการสร้างภายใต้ข้อจํากัดมิใช่งานเดียวกัน

| แนวทาง | เป้าหมายหลัก | กลไกการคงไว้โดยทั่วไป | สิ่งที่ยังต้องตรวจสอบ |
| --- | --- | --- | --- |
| การสร้างโค้ดทั้งชุด | สร้างสิ่งประดิษฐ์ให้สมบูรณ์ | พรอมป์และบริบท | ทุกส่วนที่อยู่นอกเหนือการเปลี่ยนแปลงที่ร้องขอ |
| การซ่อมแซมโปรแกรมอัตโนมัติ | แก้ข้อบกพร่องที่วินิจฉัยพบ | การระบุตําแหน่งข้อผิดพลาด การทดสอบ แม่แบบ หรือแพตช์ | ความถูกต้องที่เกินขอบเขตการทดสอบที่มีอยู่และความเล็กที่สุดของแพตช์ |
| แบบจําลองเติมส่วนที่ขาดหรือแก้ไข | แก้ไขบริเวณข้อความที่เลือก | ส่วนนําหน้า ส่วนต่อท้าย diff หรือบริบทการแก้ไขที่มองเห็นได้ | การเปลี่ยนแปลงโครงสร้างและพฤติกรรมที่มิได้ตั้งใจ |
| การถอดรหัสภายใต้ข้อจํากัดทางไวยากรณ์ | จํากัดผลลัพธ์ให้อยู่ภายในภาษารูปนัย | สถานะการถอดรหัสที่ถูกต้องตามไวยากรณ์ | ความหมายของโปรแกรม ความถูกต้องของงาน และความเป็นเฉพาะที่ |
| การควบคุมปริภูมิแฝงเชิงลําดับชั้น | สร้างตําแหน่งที่เรียนรู้และได้รับเลือกขึ้นใหม่ | โค้ดแฝงระดับหยาบหรือละเอียดที่ถูกตรึง | สิ่งที่รหัสเหล่านั้นคงไว้หลังการถอดรหัส |

## แนวทางวัดความเฉพาะที่และการคงรักษาโครงสร้าง

## ส่วนต่อประสานการควบคุมแบบใดเหมาะกับงานแก้ไขนี้

“อย่าเขียนฟังก์ชันทั้งฟังก์ชันใหม่” เป็นข้อกําหนด มิใช่วิธีการที่สมบูรณ์ ควรเริ่มจากผลลัพธ์ที่จําเป็นต้องคาดการณ์ได้ แล้วจึงเลือกพื้นผิวการควบคุมและหลักฐานที่สอดคล้องกัน

| หลักประกันที่จําเป็น | พื้นผิวการควบคุมที่สอดคล้องยิ่งขึ้น | หลักฐานที่ควรเรียกร้อง |
| --- | --- | --- |
| การปรับโครงสร้างด้วย AI โดยคงพฤติกรรม | ให้ LLM ระบุหรือเสนอการแปลง แล้วดําเนินการด้วยเอนจินปรับโครงสร้างโค้ดที่เชื่อถือได้เมื่อสามารถทําได้ โปรดดู [RefactoringMirror](https://arxiv.org/abs/2411.04444) . | การคอมไพล์ การทดสอบ การตรวจสอบแบบสถิต และการตรวจจับการปรับโครงสร้างโค้ด [SWE-Refactor](https://arxiv.org/abs/2602.03712) กําหนดการตรวจสอบเหล่านี้ไว้อย่างชัดเจนในระดับคลังเก็บโค้ด |
| การดัดแปลงโค้ดเฉพาะส่วนโดยไม่เขียนฟังก์ชันทั้งชุดขึ้นใหม่ | นําช่วงซอร์สโค้ดที่ไม่เปลี่ยนแปลงกลับมาใช้ และสร้างเฉพาะบริเวณที่เป็นตัวเลือกสําหรับการแก้ไข ดังเช่นใน [EfficientEdit](https://arxiv.org/abs/2506.02780) . | ความแตกต่างนอกบริเวณ ความสําเร็จของงาน การใช้โทเคนที่ยอมรับแล้วซ้ํา และการตรวจสอบว่าบริบทที่ละไว้ทําให้พลาดการเปลี่ยนแปลงข้ามไฟล์หรือไม่ |
| การสร้างโค้ดภายใต้ข้อจํากัดสําหรับวิศวกรรมซอฟต์แวร์ | บังคับใช้คุณสมบัติที่นิยามอย่างเป็นทางการระหว่างการถอดรหัส ดังเช่นใน [ดิฟฟิวชันภายใต้ข้อจํากัดทางไวยากรณ์](https://arxiv.org/abs/2508.10111) , หรือบันทึกจุดตรวจของส่วนขึ้นต้นที่ถูกต้อง แล้วย้อนกลับเฉพาะบริเวณที่เป็นสาเหตุ ดังเช่นใน [Hydra](https://arxiv.org/abs/2605.15238) . | ความสําเร็จตามไวยากรณ์ คอมไพเลอร์ หรือตัวตรวจสอบชนิดข้อมูล ร่วมกับการทดสอบเชิงฟังก์ชัน ความเป็นเฉพาะที่ เวลาแฝงในการซ่อมแซม และปริมาณโค้ดที่ถูกต้องซึ่งสร้างขึ้นใหม่ |
| การสร้างฟังก์ชัน Python ขึ้นใหม่แบบเลือกเฉพาะส่วน โดยรักษาสมดุลระหว่างความเป็นเฉพาะที่กับความหลากหลาย | ตรึงตําแหน่งแฝงระดับหยาบหรือละเอียดที่เลือกไว้ และสุ่มตัวอย่างเฉพาะตําแหน่งที่เหลือ | ประเมินความเฉพาะบริเวณหลังถอดรหัส วากยสัมพันธ์ คุณสมบัติคงตัวเชิงโครงสร้าง เสรีภาพในการแก้ไข ความหลากหลาย และความไม่แน่นอน การตรึงตัวแปรแฝงเพียงอย่างเดียวมิใช่หลักประกันการปรับโครงสร้างโค้ด |
| การสร้างโค้ดที่คาดการณ์ได้ภายใต้ข้อตกลงการคงรักษาที่ชัดเจน | กําหนดคุณสมบัติที่ต้องปกป้องซึ่งสังเกตได้และเกณฑ์ตรวจสอบผ่าน/ไม่ผ่านก่อนการสร้าง จากนั้นเลือกกลไกที่แคบที่สุดซึ่งสามารถบังคับใช้หรือทําให้คุณสมบัติเหล่านั้นตรวจสอบได้ | วัดคุณสมบัติเหล่านั้นโดยตรงหลังการถอดรหัส และรายงานอัตราการยอมรับ การปฏิเสธ และความล้มเหลวจากการรันซ้ํา การสุ่มตัวอย่างแบบกําหนดแน่นอนเพียงอย่างเดียวไม่รับประกันการคงรักษา |

## คําถามวิจัยที่คู่มือนี้ตอบ

คําตอบโดยสังเขปเหล่านี้กําหนดขอบเขตของข้อกล่าวอ้างและหลักฐานที่ใช้ตลอดคู่มือนี้

1. แบบจําลองเชิงกําเนิดจะแก้ไขโค้ดโดยไม่เขียนทั้งฟังก์ชันขึ้นใหม่ได้อย่างไร กําหนดขอบเขตที่แก้ไขได้ก่อนการสร้าง รักษาหรือนําซอร์สโค้ดนอกขอบเขตนั้นกลับมาใช้ สร้างเฉพาะการเปลี่ยนแปลงที่เป็นคําตอบผู้สมัคร และปฏิเสธผลลัพธ์ที่ทํางานไม่สําเร็จหรือเปลี่ยนบริเวณที่ต้องปกป้อง การตรึงตัวแปรแฝงเชิงลําดับชั้นเป็นกลไกควบคุมเชิงทดลองรูปแบบหนึ่ง แต่ไม่รับประกันว่าช่วงซอร์สโค้ดจะเหมือนเดิมทุกประการ [เปรียบเทียบกลไกควบคุมการแก้ไขเฉพาะบริเวณ](https://aogavrilov.com/th/projects/discrete-latent-generation/#control-surface) .
2. หลักฐานใดแสดงว่าการแก้ไขโค้ดเกิดขึ้นเฉพาะที่ มิใช่เพียงถูกต้องตามวากยสัมพันธ์ วัดความแตกต่างภายนอกบริเวณที่ร้องขอ ควบคู่กับความสําเร็จของงาน การเปลี่ยนแปลงในบริเวณที่แก้ไขได้ คุณสมบัติคงตัวเชิงโครงสร้าง การทดสอบหรือการตรวจสอบแบบสถิต และความแปรผันระหว่างการรันซ้ํา อัตราการแจงเพียงอย่างเดียวยืนยันได้เฉพาะความถูกต้องตามวากยสัมพันธ์ [ทบทวนรายการตรวจสอบหลักฐานด้านความเป็นเฉพาะที่](https://aogavrilov.com/th/projects/discrete-latent-generation/#measurement) .
3. ควรสร้างสมดุลระหว่างความเฉพาะที่ของการแก้ไขโค้ดกับความหลากหลายของการสร้างอย่างไร รายงานเสถียรภาพของบริเวณคุ้มครองควบคู่กับเสรีภาพในบริเวณที่แก้ไขได้และความเป็นเอกลักษณ์ของผลลัพธ์ตัวเลือก การคัดลอกอินพุตอาจเพิ่มเสถียรภาพสูงสุดโดยไม่ทําให้งานคืบหน้า ขณะที่การเขียนใหม่โดยไร้ข้อจํากัดอาจเพิ่มการเปลี่ยนแปลงสูงสุดแต่ทําลายความเป็นเฉพาะที่ [ดูหลักฐานที่มีขอบเขตเกี่ยวกับเสถียรภาพและเสรีภาพ](https://aogavrilov.com/th/projects/discrete-latent-generation/#evidence) .
4. การแก้ไขโค้ดเฉพาะส่วน การสร้างแบบมีข้อจํากัด และการซ่อมแซมโปรแกรมแตกต่างกันอย่างไร การแก้ไขเฉพาะส่วนเน้นสิ่งที่ต้องคงเดิม การสร้างแบบมีข้อจํากัดบังคับใช้คุณสมบัติรูปนัยของผลลัพธ์ เช่น การเป็นสมาชิกของไวยากรณ์ ส่วนการซ่อมแซมโปรแกรมกําหนดให้การเปลี่ยนแปลงต้องสอดคล้องกับข้อบกพร่องหรือข้อกําหนดของงาน วากยสัมพันธ์เพียงอย่างเดียวมิได้พิสูจน์ความสมมูลเชิงความหมาย ความถูกต้องเชิงหน้าที่ ความสําเร็จของงาน หรือความเฉพาะที่ [เปรียบเทียบวัตถุประสงค์ทั้งสาม](https://aogavrilov.com/th/projects/discrete-latent-generation/#comparison) .
5. จะสร้างใหม่เฉพาะบางส่วนของฟังก์ชัน Python โดยให้ส่วนที่เหลือคงเดิมได้อย่างไร กําหนดบริเวณที่ต้องปกป้องและบริเวณที่แก้ไขได้ก่อนการสร้าง ปรับเฉพาะตัวแทนของส่วนที่แก้ไขได้ แล้วถอดรหัสและปฏิเสธคําตอบผู้สมัครที่เปลี่ยนโค้ดซึ่งต้องปกป้อง หรือไม่ผ่านไวยากรณ์ การทดสอบ การตรวจสอบแบบสถิต หรือคุณสมบัติคงตัวเฉพาะงาน การทดลองตัวแปรแฝงเชิงลําดับชั้นที่รายงานวัดเสถียรภาพเชิงความน่าจะเป็นบนฟังก์ชันขนาด 64 โทเคน มิได้รับประกันว่าช่วงข้อความหรือพฤติกรรมจะไม่เปลี่ยนแปลง [ตรวจสอบกระบวนงานการสร้างใหม่แบบเลือกเฉพาะส่วน](https://aogavrilov.com/th/projects/discrete-latent-generation/#workflow) .
6. กลยุทธ์การควบคุมใดเหมาะกับการปรับโครงสร้างโค้ดโดยคงพฤติกรรมด้วยความช่วยเหลือของ AI ใช้แบบจําลองเพื่อระบุหรือเสนอการแปลง แล้วดําเนินการด้วยเอนจินปรับโครงสร้างโค้ดที่เชื่อถือได้เมื่อทําได้ พร้อมตรวจสอบการคอมไพล์ การทดสอบ การตรวจสอบแบบสถิต และการปรับโครงสร้างที่ตั้งใจ แพตช์ที่สร้างขึ้นและดูสมเหตุสมผลเพียงอย่างเดียวยังไม่ใช่หลักฐานที่เพียงพอ [เปิดแถวการตัดสินใจเกี่ยวกับการปรับโครงสร้างโค้ด](https://aogavrilov.com/th/projects/discrete-latent-generation/#control-surface) .
7. สิ่งใดทําให้การสร้างโค้ดคาดการณ์ได้ แทนที่จะเพียงควบคุมได้ กําหนดพันธสัญญาการคงรักษาที่สังเกตได้และการตรวจสอบเพื่อการยอมรับก่อนเลือกตัวสร้าง ความสามารถในการคาดการณ์ขึ้นอยู่กับว่าสิ่งใดยังคงเสถียรหลังการถอดรหัสและการทวนสอบ ไม่ได้ขึ้นอยู่เพียงว่าพรอมต์ มาสก์ ไวยากรณ์ หรือโค้ดแฝงถูกตรึงไว้หรือไม่ [กําหนดข้อตกลงการรักษา](https://aogavrilov.com/th/projects/discrete-latent-generation/#core-idea) .

## สิ่งที่การทดลองปัจจุบันแสดงให้เห็น — และสิ่งที่ยังมิได้แสดง

ใน [*การควบคุมที่ตรวจสอบได้สําหรับการสร้างซอฟต์แวร์ขึ้นใหม่โดยคงโครงสร้าง*](https://aogavrilov.com/th/publications/inspectable-control/) , VQ-VAE แบบลําดับชั้นแมปฟังก์ชัน Python ขนาด 64 โทเค็นไปยังตําแหน่งไม่ต่อเนื่องระดับบน 16 ตําแหน่งและระดับล่าง 32 ตําแหน่ง การล็อกรหัสระดับบนสี่รหัสเพิ่มอัตราการแจงจาก **0.453 ถึง 0.591** , ขณะที่ตําแหน่งที่ไม่ได้ล็อกยังคงเปลี่ยนแปลงในอัตรา **0.936** และตัวอย่างแบบมีเงื่อนไขยังคงมีค่า **มีความไม่ซ้ํากัน 0.998** .

นี่เป็นหลักฐานของภาวะได้อย่างเสียอย่างระหว่างเสถียรภาพกับอิสระที่วัดได้ในบริบทขนาดเล็กหนึ่งบริบท มิใช่การรับประกันการคง AST อย่างแม่นตรง ความสมมูลเชิงความหมาย ความถูกต้องเชิงการทํางาน ความสําเร็จในการซ่อมแซม หรือพฤติกรรมในระดับคลังโค้ด

งานศึกษาที่ทําควบคู่กัน [*จุดที่คุณภาพสูญเสียไปในการสร้างข้อความสั้นแบบบีบอัด*](https://aogavrilov.com/th/publications/where-quality-breaks/) ให้บทเรียนสําคัญด้านการประเมินว่า ตัวชี้วัดตัวแทนในปริภูมิแฝงที่ดีขึ้นไม่จําเป็นต้องทําให้ผลลัพธ์หลังถอดรหัสดีขึ้น ควรตรวจสอบตัวแทน การสร้าง และพฤติกรรมหลังถอดรหัสเป็นคนละขั้น

สําหรับกระบวนการตัดสินใจที่นํากลับมาใช้ได้ โปรดดูคู่มือประกอบเรื่อง [การแยกการสูญเสียจากโคเดกออกจากการสูญเสียจากตัวสร้าง](https://aogavrilov.com/th/projects/codec-bottleneck-diagnosis/) .

## ความเข้าใจผิดที่พบบ่อย

### “แจงได้จึงถูกต้อง”

การแจงพิสูจน์ได้เพียงความถูกต้องตามวากยสัมพันธ์ โปรแกรมอาจยังคงไม่เป็นไปตามการทดสอบ ข้อตกลง หรือเจตนาที่กําหนด

### “รหัสระดับหยาบคือโหนด AST”

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

### “ตัวแปรแฝงที่ล็อกไว้หมายถึงข้อความต้นฉบับไม่เปลี่ยนแปลง”

การถอดรหัสเป็นกระบวนการทั่วทั้งข้อมูลที่ได้จากการเรียนรู้ การตรึงตําแหน่งตัวแปรแฝงอาจเพิ่มเสถียรภาพ แต่ไม่รับประกันว่าจะได้ช่วงข้อความที่เหมือนเดิมทุกประการ

### “เปลี่ยนแปลงน้อยกว่าย่อมดีกว่าเสมอ”

ตัวแก้ไขที่คัดลอกอินพุตย่อมมีเสถียรภาพสมบูรณ์ แต่ไม่มีความคืบหน้าในการทํางาน จึงต้องวัดทั้งความเฉพาะที่และความสําเร็จของการแก้ไขควบคู่กัน

## เนื้อหาที่ควรอ่านต่อ

งานที่เกี่ยวข้องใช้กลไกควบคุมคนละรูปแบบ จึงไม่ควรถือว่างานใดใช้แทนกันเป็นเส้นฐานได้หากยังไม่ได้จัดแนวงานให้สอดคล้องกัน

1. [Self-Edit: Fault-Aware Code Editor for Code Generation](https://arxiv.org/abs/2305.04087) ถือว่าการสร้างเป็นกระบวนการที่แก้ไขได้ และใช้ข้อผิดพลาดที่ตรวจพบเป็นแนวทางในการแก้ไข
2. [Coeditor: การใช้ประโยชน์จากการเปลี่ยนแปลงตามบริบทเพื่อแก้ไขโค้ดอัตโนมัติหลายรอบ](https://arxiv.org/abs/2305.18584) สร้างแบบจําลองการเปลี่ยนแปลงโค้ดตามบริบทข้ามรอบการแก้ไข แทนการสร้างใหม่ทั้งหมดตั้งแต่ต้น
3. [PAFT: Preservation Aware Fine-Tuning for Minimal-Edit Program Repair](https://arxiv.org/abs/2604.03113) กําหนดการคงรักษาและการเปลี่ยนแปลงให้น้อยที่สุดไว้อย่างชัดเจนในการฝึกเพื่อซ่อมแซมโปรแกรม
4. [การถอดรหัส Diffusion LLMs ภายใต้ข้อจํากัดด้วยไวยากรณ์ไม่พึ่งบริบท](https://arxiv.org/abs/2508.10111) แสดงให้เห็นว่าข้อจํากัดเชิงรูปนัยสามารถให้หลักประกันด้านวากยสัมพันธ์ระหว่างการถอดรหัสแบบแพร่ได้อย่างไร
5. [Neural Discrete Representation Learning](https://arxiv.org/abs/1711.00937) นําเสนอ VQ-VAE ซึ่งเป็นกลไกพื้นฐานสําหรับการแทนข้อมูลแฝงแบบไม่ต่อเนื่องที่เรียนรู้ได้
6. [Simple and Effective Masked Diffusion Language Models](https://arxiv.org/abs/2406.07524) นําเสนอกรอบการแพร่แบบไม่ต่อเนื่องที่มีมาสก์ ซึ่งใช้เป็นตัวสร้างในปริภูมิแฝงสําหรับการศึกษาวินิจฉัยที่จัดทําควบคู่กัน
7. [การศึกษาเชิงประจักษ์ว่าด้วยศักยภาพของ LLM ในการปรับโครงสร้างซอฟต์แวร์โดยอัตโนมัติ](https://arxiv.org/abs/2411.04444) ตรวจหาการปรับโครงสร้างโค้ดที่ไม่ปลอดภัยซึ่ง LLM เสนอ และประเมินการนําการแปลงที่ตรวจพบไปใช้อีกครั้งผ่านเอนจินปรับโครงสร้างโค้ดที่เชื่อถือได้
8. [SWE-Refactor: A Repository-Level Benchmark for Real-World LLM-Based Code Refactoring](https://arxiv.org/abs/2602.03712) ประเมินการปรับโครงสร้างโค้ดระดับคลังซึ่งรักษาพฤติกรรม โดยใช้การคอมไพล์ การทดสอบ และการตรวจจับการปรับโครงสร้างโค้ด
9. [EfficientEdit: Accelerating Code Editing via Edit-Oriented Speculative Decoding](https://arxiv.org/abs/2506.02780) นําส่วนของซอร์สโค้ดที่ไม่เปลี่ยนแปลงกลับมาใช้และทํานายตําแหน่งแก้ไข แทนการมองว่าการแก้ไขคือการสร้างแบบถดถอยอัตโนมัติขึ้นใหม่ทั้งหมด
10. [Hydra: Efficient, Correct Code Generation via Checkpoint-and-Rollback Support](https://arxiv.org/abs/2605.15238) ใช้การตรวจสอบแบบสถิต จุดตรวจ และการย้อนกลับแบบเจาะจง เพื่อหลีกเลี่ยงการสร้างส่วนนําหน้าที่ถูกต้องอยู่แล้วซ้ําอีกหลังเกิดข้อผิดพลาด

## สรุปโดยย่อ

การสร้างโค้ดใหม่เฉพาะส่วนเป็นข้อตกลงระหว่าง **การเปลี่ยนแปลง** และ **การคงรักษา** . ตัวแปรแฝงไม่ต่อเนื่องแบบลําดับชั้นเป็นวิธีหนึ่งที่ตรวจสอบได้ในการระบุข้อตกลงดังกล่าว แต่ตัวแทนนี้จะมีประโยชน์ก็ต่อเมื่อโปรแกรมที่ถอดรหัสแล้วได้รับการประเมินด้านความเฉพาะที่ วากยสัมพันธ์ โครงสร้าง พฤติกรรม ความหลากหลาย และความไม่แน่นอน

## สิ่งพิมพ์ในทิศทางการวิจัยนี้

### [Where Quality Breaks in Compressed Short-Text Generation: Staged Bottleneck Localization](https://aogavrilov.com/th/publications/where-quality-breaks/)

จุดที่คุณภาพลดลงในการสร้างข้อความสั้นแบบบีบอัด: การระบุคอขวดเป็นลําดับขั้น

ระเบียบวิธีการวินิจฉัย FRUCT 39 2026 การประชุมวิชาการหลัก

### [Inspectable Control for Structure-Preserving Software Regeneration](https://aogavrilov.com/th/publications/inspectable-control/)

การควบคุมที่ตรวจสอบได้สําหรับการสร้างซอฟต์แวร์ขึ้นใหม่โดยคงโครงสร้าง

วิธีควบคุมในปริภูมิแฝง FSE Companion '26 2026 โปสเตอร์ประกอบ