AI แบบเอเจนต์มักไม่สำรองข้อมูลก่อนลงมือ

เนื้อหาส่วนใหญ่ที่ผมไล่อ่านจาก Arxiv และแหล่งข้อมูลอื่น ๆ ทุกวันค่อนข้างแห้งแล้ง แม้แต่สำหรับคนเนิร์ดอย่างผม ดังนั้นผมจึงมองหางานเขียนที่กระตุ้นอารมณ์ความรู้สึกของผมในฐานะผู้ใช้ ผู้สนับสนุน หรือผู้ตกเป็นเหยื่อของ AI อยู่เสมอ

วันนี้ งานวิจัยร่วมชิ้นใหม่จากสหรัฐฯ ทำให้ผมรู้สึกขนลุกขึ้นมา โดยศึกษาว่าโมเดล AI แนวหน้าที่ทำงานแบบเอเจนต์เผาสะพานก่อนลงมือก่อความเสียหายมากแค่ไหน—และเร็วกว่าที่คุณจะพิมพ์คำว่า “หยุด!” เสียอีก (เกร็ดเล็กน้อย: เตรียมคำนี้ไว้ในคลิปบอร์ด)

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

ถอดความจากงานวิจัยชิ้นใหม่ ช่วงเวลาชวนใจหายที่หลายคนคงเคยพบเมื่อติดตั้งเฟรมเวิร์กรุ่นล้ำสมัย หรือแม้แต่ดิสทริบิวชันยอดนิยมที่ไม่คำนึงถึงสภาพแวดล้อมที่ไม่ได้ใช้การตั้งค่ามาตรฐานซึ่งอาจนำไปติดตั้ง ที่มา

ในตัวอย่างชวนผวาที่คุ้นเคยเกินไปนี้ หุ่นยนต์ก็มีข้อแก้ตัวที่ฟังขึ้น เพราะโดยปกติแล้วเราไม่ได้ตรวจสอบผลที่อาจเกิดขึ้นได้ทั้งหมดจากการติดตั้งไลบรารีใหม่ในเฟรมเวิร์กที่เปราะบางและไม่ยืดหยุ่น อย่างไรก็ตาม งานวิจัยชิ้นใหม่เสนอว่าเราอาจควรทำเช่นนั้น และในฐานะคนที่ยังกด CTRL+S อยู่บ่อย ๆ แม้ในสภาพแวดล้อมที่บันทึกอัตโนมัติ ซึ่งตั้งค่าให้ไม่สนใจการกดปุ่มนี้ (ขอบคุณบาดแผลทางใจจากข้อมูลสูญหายในยุค 1990) ผมก็เห็นด้วย

Alexey Grigorev ผู้ก่อตั้งแพลตฟอร์มการศึกษา DataTalks.Club คงอยากให้มีท่าทีรอบคอบและระมัดระวังกว่านี้แน่นอน เพราะเมื่อเดือนมีนาคมที่ผ่านมา เอเจนต์ Claude Code ของเขาได้ ลบโครงสร้างพื้นฐานที่ใช้งานจริงและข้อมูลสำรองระหว่างการย้ายเซิร์ฟเวอร์ ส่งผลให้ข้อมูลเว็บไซต์ตลอดสองปีครึ่งสูญหาย

เหตุการณ์ประมาทเลินเล่อของเอเจนต์ในลักษณะเดียวกันที่เกิดขึ้นเมื่อไม่นานมานี้ ได้แก่ เอเจนต์ Cursor ลบฐานข้อมูลที่ใช้งานจริงและข้อมูลสำรองของ PocketOS ผู้ให้บริการซอฟต์แวร์เช่ารถในเดือนเมษายน ทำให้การจองของลูกค้าหยุดชะงักนานกว่าสองวัน และเอเจนต์อีเมล OpenClaw ลบข้อความจากกล่องจดหมายของนักวิจัย AI แห่ง Meta ในเดือนกุมภาพันธ์ ทั้งที่ได้รับคำสั่งซ้ำหลายครั้งให้หยุด

ไม่ว่าจะเป็นเอเจนต์หรือไม่ โมเดล LLM แนวหน้า ก็ทำงานอย่างรอบคอบและระมัดระวังได้ยากมาก จนการหาทางแก้ปัญหานี้กลายเป็น หัวข้อศึกษาเฉพาะทางในงานวิจัย

สำรองข้อมูลไว้สักหน่อย

ผู้เขียนงานวิจัยชิ้นใหม่* ได้พัฒนาปลั๊กอินแบบหลายเอเจนต์สำหรับระบบควบคุมการทำงานของเอเจนต์ ซึ่งทำงานควบคู่ไปกับ AI ที่เป็นตัวหลัก และบังคับให้ AI สร้างข้อมูลสำรองเมื่อจำเป็น:

ภาพรวมปัญหาการสำรองข้อมูลที่งานวิจัยศึกษาพร้อมแนวทางแก้ไขที่เสนอ ในสถานการณ์ 205 แบบ โมเดล AI แนวหน้า 6 รุ่นสำรองสถานะสำคัญไว้เพียง 15.2% ของงานทั้งหมด แต่ระบบ BackUpper ของนักวิจัยครอบคลุมการกระทำสำคัญทุกอย่าง โดยข้อมูลที่กู้คืนได้มีความคล้ายคลึงกับข้อมูลต้นฉบับเฉลี่ย 92.2% (ดูด้านล่างว่าทำไมการทำให้ได้ 100% จึงเป็นเรื่องยาก)

ประเด็นหนึ่งที่โดดเด่นที่สุดในงานวิจัยชิ้นใหม่นี้คือ โมเดลแนวหน้าไม่สำรองข้อมูลก่อนลงมือทำสิ่งที่อาจก่ออันตรายมากเพียงใด นักวิจัยพบว่า GPT-5.6-Terra สำรองข้อมูลสำคัญเพียง 4.4% ของกรณี ส่วน GPT-5.6-Sol ทำได้เพียง 5.9% ของกรณีที่ทดสอบ และ Gemini 3.7-Flash ทำได้ต่ำสุดเพียง 2.4% ของกรณี

แม้แต่โมเดลที่ทำผลงานดีที่สุดอย่าง Claude Opus-5 ก็ยังไม่สำรองข้อมูลสำคัญในกรณีที่ทดสอบมากกว่าหนึ่งในสาม

งานวิจัยระบุ^†ว่า:

‘ในบรรดาโมเดลแนวหน้า 6 รุ่น เอเจนต์ทำงานสำเร็จโดยเฉลี่ย 86.1% แต่สำรองสถานะก่อนถึงจังหวะที่อาจต้องเสียใจภายหลังเพียง 15.2% เท่านั้น GPT 5.6-Sol ใน Codex ทำเช่นนั้นเพียง 5.9% ของงาน ส่วน DeepSeek V4-Pro ใน Hermes ทำได้เพียง 2.9%

‘ผลการค้นพบนี้ชี้ให้เห็นว่าปัจจุบันเอเจนต์ยังตระหนักถึงความสำคัญของการสำรองข้อมูลอย่างจำกัด และจำเป็นต้องมีระบบรองรับการสำรองข้อมูลโดยเฉพาะ’

โซลูชันของผู้เขียนที่ตั้งชื่อว่า BackUpper ทำงานควบคู่ไปกับเอเจนต์ในลักษณะกระบวนการเงาภายในระบบควบคุมการทำงาน โดยตรวจสอบสิ่งที่เอเจนต์กำลังจะทำ และสร้างข้อมูลสำรองไว้ก่อนหากมีความเสี่ยงที่จะสูญเสียสิ่งที่มีประโยชน์

สำหรับการทำงานทั่วไป เช่น การอัปเกรดซอฟต์แวร์ ระบบจะใช้ชุดกฎง่าย ๆ แต่หากเป็นสถานการณ์ที่ซับซ้อนขึ้น ระบบจะเรียกใช้โมเดล AI ขนาดเล็กกว่าเพื่อพิจารณาว่าควรบันทึกอะไรไว้

ในการทดสอบ BackUpper ครอบคลุมการดำเนินการสำคัญทุกอย่าง และกู้คืนข้อมูลที่มีความคล้ายคลึงกับต้นฉบับ 92.2% โดยมีค่าใช้จ่ายเพิ่มขึ้น 0.014 ดอลลาร์ต่อภารกิจ ซึ่งในบริบทนี้ถือว่าไม่มากนัก แต่เป็นค่าใช้จ่ายที่สูงสำหรับ LLM ระดับแนวหน้าซึ่งให้บริการลูกค้าหลายพันล้านราย นี่อาจเป็นเหตุผลที่ทำให้บริการภายนอกในลักษณะนี้ หรือการผนวกฟังก์ชันดังกล่าวไว้ในฮาร์เนสโดยตรง เป็นแนวทางที่มีโอกาสช่วยปรับปรุงสถานการณ์ได้มากกว่า แทนที่จะหวังให้ยักษ์ใหญ่ด้านเทคโนโลยีแก้ปัญหานี้โดยตรง (ซึ่งก็คาดได้อย่างสมเหตุสมผลว่าอาจผลักภาระค่าใช้จ่ายส่วนเพิ่มไปให้ผู้บริโภค ไม่ว่าจะด้วยการขึ้นราคาหรือ การเพิ่มจำนวนโทเค็น)

กรอบการทำงานนี้พัฒนาขึ้นโดยอิงจาก RegretBench ซึ่งเป็นชุดทดสอบ 205 ภารกิจที่สร้างจากกรณีจริงที่ผู้คนสูญเสียข้อมูลซึ่งภายหลังนึกเสียดายว่าไม่ได้บันทึกไว้ ชุดทดสอบนี้ประเมินว่าเอเจนต์ AI มองการณ์ไกลพอที่จะเก็บรักษาข้อมูลดังกล่าวไว้ก่อนดำเนินการเปลี่ยนแปลงที่อาจย้อนคืนไม่ได้หรือไม่ เหตุการณ์ในชุดข้อมูลนี้รวบรวมมาจากการสนทนาและรายงานออนไลน์บนแพลตฟอร์มต่าง ๆ รวมถึง X.com, GitHub และ Stack Overflow

แผนผังแสดงวิธีที่ RegretBench เปลี่ยนเหตุการณ์จริงให้เป็นสถานการณ์ทดสอบ แต่ละกรณีที่มีการบันทึกไว้จะถูกสร้างขึ้นใหม่โดยอาศัยการกระทำที่ทำให้ข้อมูลสูญหาย สภาพแวดล้อมการทำงานที่สมจริง และชุดคำสั่งตามลำดับ ในตัวอย่างนี้ การอัปเกรด ipykernel จะแทนที่เวอร์ชันเดิมของ traitlets โดยไม่มีการแจ้งเตือน ทำให้เอเจนต์ทำงานจนเสร็จได้ แต่ไม่เหลือวิธีกู้คืนการติดตั้งเดิม

แม้ตัวเลข 92% อาจทำให้ผู้ที่มุ่งหวังความสมบูรณ์แบบรู้สึกท้อใจ แต่ผู้เขียนระบุว่าการกู้คืนข้อมูลบางประเภทมีอุปสรรคทางเทคนิค ดังนี้:

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

ในการทดสอบ หลังเกิดความเสียหายแล้วสามารถกู้คืนข้อมูลให้มีความคล้ายคลึงกับสถานะเดิมได้ 33.8% เทียบกับเพียง 14.3% ในกรณีที่ไม่มีการกู้คืน

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

BackUpper รองรับ Claude Code, Codex, Hermes, OpenHands, DeepSeek Harness และ OpenClaw ผู้เขียนเปิดให้เข้าถึงโค้ดได้ที่ นี่ พร้อมกับ ชุดข้อมูล ที่เกี่ยวข้อง (แต่ต้องยื่นคำขออนุญาตผ่านแบบฟอร์ม) นอกจากนี้ยังมีข้อมูลเพิ่มเติมเล็กน้อยและวิดีโออธิบายสั้น ๆ ที่เข้าใจง่ายบนเว็บไซต์โครงการ

วิธีการ

ในการสร้าง RegretBench ผู้พัฒนาจงใจไม่นำข้อมูลที่ระบบสำรองข้อมูลในตัวของเอเจนต์ปกป้องไว้แล้วมารวมด้วย เพื่อทดสอบว่าเอเจนต์ตระหนักด้วยตนเองหรือไม่ว่าควรสำรองข้อมูลเมื่อใด จากนั้นจึงจัดทำสถานการณ์ทดสอบโดยได้รับความช่วยเหลือจาก Claude Opus-5 และ GPT-5.6-Sol แล้วตรวจสอบด้วยตนเองเพื่อให้แน่ใจว่าสถานการณ์เหล่านั้นใช้งานได้และสะท้อนเหตุการณ์ต้นทางได้อย่างถูกต้อง

การทดสอบ 205 รายการของ RegretBench ครอบคลุมห้าด้าน ได้แก่ การทำงานผ่านเทอร์มินัล, ฐานข้อมูล, เว็บแอปพลิเคชัน, อีเมล และ DevOps เหตุการณ์ต้นทางส่วนใหญ่มาจากแพลตฟอร์มพัฒนาซอฟต์แวร์และเพิ่มประสิทธิภาพการทำงาน (44.4%); การสนทนาบนสื่อสังคมหรือชุมชนออนไลน์ (39%); และคลังข้อมูลกับรายงานสื่อ (16.6%):

แหล่งที่มาของเหตุการณ์จริงใน RegretBench แบ่งออกเป็นสามหมวด

โมเดลระดับแนวหน้าทั้งหกที่นำมาประเมิน ได้แก่ Claude Opus-5 และ Claude Sonnet-5 ใน Claude Code; GPT-5.6-Sol และ GPT-5.6-Terra ใน Codex; และ Gemini 3.7-Flash กับ DeepSeek V4-Pro ใน Hermes

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

มีการใช้ผู้ประเมิน AI สองรายซึ่งทำงานด้วย Claude Sonnet-5 เพื่อประเมินผล อัตราการผ่านภารกิจ (PR) คำนวณจากสัดส่วนของภารกิจที่ทำตามคำขอของผู้ใช้ได้ครบทุกข้อ ส่วนการประเมินการสำรองข้อมูลนั้น จะตรวจสอบการแก้ไขแต่ละครั้งนอกพื้นที่ทำงาน (OOW) ว่ามีการเก็บรักษาข้อมูลไว้ล่วงหน้าเพียงพอที่จะกู้คืนได้หรือไม่

ตัวชี้วัดการสำรองข้อมูลที่ใช้ ได้แก่ Regret Moment Backup Rate (RMBR) ซึ่งสะท้อนการดำเนินการเฉพาะที่เชื่อมโยงกับกรณีข้อมูลสูญหายที่มีการบันทึกไว้ และ อัตราการสำรองข้อมูลนอกพื้นที่ทำงาน (OWBR) ซึ่งสะท้อนการเปลี่ยนแปลงทั้งหมดที่เกิดขึ้นนอกไดเรกทอรีทำงานของเอเจนต์

ผลการประเมินของผู้ตัดสินการสำรองข้อมูลยังได้รับการตรวจสอบเทียบกับคำกำกับข้อมูลโดยมนุษย์ด้วย และพบว่าตรงกัน 95.3%

ผลลัพธ์

เพื่อพิสูจน์ว่าการตระหนักถึงการสำรองข้อมูลที่ต่ำมีสาเหตุมาจากโมเดล AI หรือเฟรมเวิร์กที่ใช้รันโมเดล Claude Opus-5, GPT-5.6-Sol และ DeepSeek V4-Pro จึงได้รับการประเมินกับงาน RegretBench จำนวน 60 งานใน Claude Code, Codex และ Hermes เป็นอันดับแรก

สัดส่วนของงานที่มีการสำรองข้อมูลสำคัญแตกต่างกันเพียงเล็กน้อยระหว่างเฟรมเวิร์ก ซึ่งบ่งชี้ว่าตัวโมเดลเองเป็นสาเหตุหลัก นอกจากนี้ ยังมีการตรวจสอบความสัมพันธ์ระหว่างความสามารถโดยทั่วไปของ AI กับการตระหนักถึงการสำรองข้อมูล โดยใช้ GPT-5.4, GPT-5.5 และ GPT-5.6-Sol

แม้ความสามารถโดยทั่วไปจะพัฒนาขึ้นอย่างต่อเนื่อง แต่ก็ไม่พบว่าการตระหนักถึงการสำรองข้อมูลจะพัฒนาขึ้นตามไปด้วย:

ผลการทดสอบ RegretBench ของโมเดล AI หกรุ่น ด้านซ้าย: เปรียบเทียบอัตราการทำงานสำเร็จของงานกับสัดส่วนของการกระทำสำคัญที่ได้รับการสำรองข้อมูลไว้ล่วงหน้า แสดงให้เห็นว่าโมเดลส่วนใหญ่ทำงานสำเร็จในอัตราสูง แต่ตระหนักถึงการสำรองข้อมูลน้อย ด้านขวา: จำนวนครั้งเฉลี่ยที่เรียกใช้เครื่องมือต่องาน โดยเน้นการดำเนินการสำรองข้อมูลด้วยสีน้ำเงิน Claude Opus-5 มีอัตราการสำรองข้อมูลสูงที่สุด แต่ใช้การเรียกใช้เครื่องมือ 8.9% ไปกับการสำรองข้อมูล

นอกจากนี้ ยังมีการตรวจสอบความสัมพันธ์ระหว่างความสามารถโดยทั่วไปของ AI กับการตระหนักถึงการสำรองข้อมูล โดยใช้ GPT-5.4, GPT-5.5 และ GPT-5.6-Sol แม้ความสามารถโดยทั่วไปจะพัฒนาขึ้นอย่างต่อเนื่อง แต่ก็ไม่พบว่าการตระหนักถึงการสำรองข้อมูลจะพัฒนาขึ้นตามไปด้วย

BackUpper

BackUpper ใช้การป้องกันสี่ระดับ ซึ่งแต่ละระดับมีต้นทุนด้านทรัพยากรแตกต่างกัน: ระดับ 1 แทนที่คำสั่งที่ทำลายข้อมูลด้วยทางเลือกที่ย้อนกลับได้ เช่น ย้ายไฟล์ไปยังถังขยะ; ระดับ 2 จับคู่การดำเนินการกับคำสั่งสำรองข้อมูล เช่น บันทึกเวอร์ชันของแพ็กเกจก่อนอัปเกรด; ระดับ 3 สร้างสแนปช็อตของไฟล์ในพื้นที่ทำงานที่ได้รับผลกระทบ; และระดับ 4 ใช้เอเจนต์ย่อย GPT-5.6-Luna เพื่อระบุและเก็บรักษาข้อมูลที่ได้รับผลกระทบจากการดำเนินการที่ซับซ้อนยิ่งขึ้น

เมื่อเปิดใช้งาน BackUpper การกระทำทุกอย่างที่เปลี่ยนสถานะได้รับการสำรองข้อมูลครบถ้วนในโมเดลทั้งหกรุ่น เทียบกับอัตราการสำรองข้อมูลเฉลี่ยที่ 15.2% สำหรับการกระทำสำคัญ และ 17.4% สำหรับการเปลี่ยนแปลงอื่น ๆ เมื่อไม่ได้ใช้ BackUpper:

ผลการครอบคลุมการสำรองข้อมูลและการกู้คืนด้วย BackUpper ด้านซ้าย: แท่งสีน้ำเงินและสีส้มแสดงอัตราการสำรองข้อมูลของแต่ละโมเดลสำหรับการกระทำสำคัญและการเปลี่ยนแปลงอื่น ๆ นอกพื้นที่ทำงาน เส้นประสีเขียวเข้มแสดงความแม่นยำในการกู้คืน ส่วนเส้นจุดสีเขียวอ่อนแสดงการครอบคลุมการสำรองข้อมูล 100% ด้วย BackUpper ด้านขวา: เปรียบเทียบความแม่นยำในการกู้คืนในเครื่องมือห้าหมวดหมู่ โดยใช้ BackUpper (สีเขียว), การกู้คืนภายหลังด้วย Claude Opus-5 (สีม่วง) และกรณีที่ไม่มีการกู้คืน (สีเทา) BackUpper ให้ความแม่นยำสูงที่สุดในทุกกรณี

ในบรรดาข้อมูลสำรองที่ผู้ประเมินอัตโนมัติตัดสินว่าทำสำเร็จ ผู้ตรวจสอบที่เป็นมนุษย์ยืนยันว่าทำสำเร็จเช่นกัน 94%

กู้คืนสถานะเดิมได้ด้วยความคล้ายคลึงเฉลี่ย 92.2% เทียบกับ 33.8% เมื่อใช้ Claude Opus-5 และ 14.3% ในกรณีที่ไม่มีการกู้คืน (ดูภาพด้านบน) ความแตกต่างที่เหลือส่วนใหญ่มีสาเหตุมาจากตัวระบุที่สร้างขึ้นใหม่และข้อมูลเมตาเล็กน้อย รวมถึงสถานะการอ่านอีเมล ดังที่กล่าวไว้ก่อนหน้านี้

ทำเอง.. ได้ไหม?

เมื่อให้คำแนะนำโดยละเอียดแก่เอเจนต์เพื่อให้สำรองข้อมูลด้วยตนเอง การกระทำสำคัญ 81.4% ได้รับการป้องกัน เทียบกับ 100% เมื่อใช้ BackUpper โดยพบว่าความล้มเหลวสามในสี่ส่วนเกิดจากข้อมูลสำรองมีข้อมูลไม่เพียงพอสำหรับการกู้คืน

เปรียบเทียบอัตราการสำรองข้อมูลด้วยห้าวิธี ซึ่งทดสอบกับงาน 205 งานโดยใช้โมเดล AI หกรุ่น แผนภูมิด้านซ้ายแสดงข้อมูลสำรองที่สร้างไว้ก่อนการกระทำที่ภายหลังพบว่าน่าเสียดาย ส่วนด้านขวาแสดงการป้องกันการเปลี่ยนแปลงอื่น ๆ นอกพื้นที่ทำงาน BackUpper สำรองข้อมูลได้ครอบคลุมทั้งหมดในทั้งสองหมวดหมู่ เทียบกับ 81.4% และ 80.5% เมื่อให้คำแนะนำการสำรองข้อมูลโดยละเอียดแก่เอเจนต์

เมื่อใช้การแคชพรอมป์ต์ ค่าใช้จ่ายในการสำรองข้อมูลลดลงจาก $0.344 เหลือ $0.014 ต่องาน และเวลาแฝงลดลง 31.7% ใช้โทเค็นน้อยลงเจ็ดเท่า ส่วนใหญ่เป็นเพราะจัดการการดำเนินการตามปกติโดยไม่ต้องอาศัย AI

ในการทดสอบเพิ่มเติมอีก 40 งานจาก Terminal-Bench 4 และ DeepSWE GPT-5.6-Sol และ Claude Opus-5 สำรองข้อมูลได้ครอบคลุม 100% โดยไม่ทำให้อัตราการทำงานสำเร็จลดลง

นโยบายการสำรองข้อมูลแบบเลือกเฉพาะ 3 แบบที่นำมาประเมิน ได้แก่ ผลกระทบสูง สำหรับการเปลี่ยนแปลงที่สำคัญ, นอกเหนือจากคำขอ สำหรับการเปลี่ยนแปลงที่อยู่นอกเหนือคำสั่งของผู้ใช้ และ งานที่มนุษย์ทำ สำหรับเนื้อหาที่มนุษย์สร้างขึ้น ในกรณีนี้ได้คะแนน F1 เฉลี่ย 84.5% เมื่อเทียบกับการประเมินของมนุษย์

นอกจากนี้ ยังทดสอบความสามารถของ BackUpper ในการเรียนรู้กฎการสำรองข้อมูลที่นำกลับมาใช้ซ้ำได้ด้วย หลังจากทำงานเทอร์มินัลเพิ่มเติมอีก 30 งาน ความครอบคลุมของกฎที่อิงตามกฎเพิ่มขึ้นจาก 14.9% เป็น 31.2% ทำให้พึ่งพาเอเจนต์ย่อย GPT-5.6-Luna น้อยลง

บทสรุป

เมื่อพิจารณาจากอาชีพของผม ผมน่าจะเริ่มทดลองกับ AI แบบเอเจนต์ให้เร็วกว่านี้ แต่สภาพที่ยังอยู่ในช่วงก่อนอัลฟาอย่างเห็นได้ชัดของการยับยั้งชั่งใจตนเองของ AI แบบเอเจนต์ทำให้ผมกลัว จนกระทั่งไม่กี่สัปดาห์ก่อน ผมจึงตัดสินใจปล่อยให้ Codex ทำงานอย่างอิสระใน VM ของ Windows

แม้จะทำงานอยู่ภายใน VM ผมก็ยังระบุขอบเขตคำสั่งอย่างรอบคอบมาก เพราะรู้ว่า Astra มีแนวโน้มจะพุ่งไปข้างหน้าอย่างไม่ยั้งคิด แล้วค่อยกล่าวขอโทษเมื่อไม่อาจย้อนคืนจากข้อมูลสูญหายหรือโค้ดเสียหายได้ และส่วนหนึ่งของเฟรมเวิร์ก Python ที่ผมกำลังพัฒนาที่นั่นคือฟังก์ชัน “บันทึก .7z ไปยังโฟลเดอร์เครือข่าย” แบบเพิ่มข้อมูลทีละส่วนที่ทำงานได้ด้วยคลิกเดียว ซึ่งบีบอัดและสำรองข้อมูลเฟรมเวิร์กทั้งหมด โดยผมเรียกใช้ฟังก์ชันนี้บ่อยครั้ง

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

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

^† การเน้นข้อความเป็นของผู้เขียน ไม่ใช่ของผม ส่วนไฮเปอร์ลิงก์ทั้งหมดนั้น ผมสร้างขึ้นจากการอ้างอิงในเนื้อหาของผู้เขียน

เผยแพร่ครั้งแรกเมื่อวันพฤหัสบดีที่ 22 ตุลาคม 2026