เหตุใด AI จึงประสบปัญหาเมื่อต้องรับช่วงงานที่ทำค้างไว้

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

หนึ่งในสิ่งที่เหนื่อยแต่จำเป็นเมื่อทำงานกับเอเจนต์ AI และอินเทอร์เฟซต่าง ๆ คือการอธิบายสถานการณ์ล่าสุดให้ AI เข้าใจเมื่อเริ่มการสนทนาแทบทุกครั้ง ^{[1] [2]}

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

รับช่วงงานของผู้อื่นในโลกจริง

แน่นอนว่าปัญหานี้มีมาก่อน AI หลายบริษัทกำหนดให้พนักงานจัดทำและดูแลเอกสารเกี่ยวกับกระบวนการที่ตนพัฒนาหรือปรับปรุง ส่วนหนึ่งเพื่อให้พนักงานใหม่เรียนรู้งานได้ราบรื่นขึ้น แต่ก็อาจมองได้ว่าเป็นการป้องกันไม่ให้พนักงานมีอำนาจต่อรองมากขึ้นด้วย

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

เอกสารที่ครบถ้วนสมบูรณ์ย่อมช่วยประหยัดงานหลายวัน หลายสัปดาห์ หรือแม้แต่หลายเดือน หากการจัดทำเอกสารนั้นคุ้มค่าในทางการเงิน ^[1]

แต่เมื่อผู้ลงมือทำงานเป็นเอเจนต์ AI ก็อาจมีช่องทางแก้ปัญหานี้ได้มากขึ้น

ส่งมอบงาน

งานวิจัยใหม่จากสหรัฐอเมริกาวัดภาระจากการขาดเอกสารนี้ในเชิงปริมาณ และเรียกปัญหาว่า หนี้จากการส่งมอบงาน

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

งานวิจัยใหม่นี้^† เป็นผลงานร่วมของนักวิจัยอิสระและนักวิจัยที่เกี่ยวข้องกับ Georgia State University โดยศึกษาหนี้จากการส่งมอบงานใน เอเจนต์เขียนโค้ด ที่ต้องทำงานในฐานโค้ดต่อจากจุดที่เซสชัน บุคคล หรือหน่วยงานอื่นหยุดไว้ ^[1]

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

ข้อจำกัดด้านงบประมาณ

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

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

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

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

ผู้เขียนงานวิจัยใหม่เรื่อง Handoff Debt: The Rediscovery Cost When Coding Agents Take Over Interrupted Tasks พิจารณาสถานการณ์ทั้งหมดนี้ และปรับแบบจำลองงานเดิมเพื่อวัดและจัดการหนี้จากการส่งมอบงานด้วยวิธีใหม่ แม้งานวิจัยมุ่งที่เอเจนต์เขียนโค้ดโดยเฉพาะ แต่ก็อาจชี้แนวทางที่มีประโยชน์สำหรับการใช้ AI ในวงกว้างและการจัดการนโยบายเอกสาร

ผู้เขียนระบุว่า:

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

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

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

วิธีการ

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

เพื่อสร้างเกณฑ์ทดสอบที่วัดต้นทุนการถ่ายทอดงานวิศวกรรมซอฟต์แวร์ที่ยังไม่เสร็จระหว่างเอเจนต์ งาน 75 งานจาก SWE-bench Verified ถูกแปลงเป็นสถานการณ์ การส่งมอบงาน 181 สถานการณ์ แต่ละสถานการณ์ตรงกับจุดที่งานถูกหยุดแล้วส่งต่อให้เอเจนต์ผู้รับช่วง จากนั้นทดลองโมเดลผู้รับช่วงสามแบบในการรับช่วงงานรวม 2,172 ครั้ง

ตระกูลโมเดลที่นำมาใช้จับคู่กันในรูปแบบต่าง ๆ ในการทดสอบส่งมอบงาน ได้แก่ Qwen, Gemma และ Devstral

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

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

การทดลองกำหนด จุดที่เริ่มส่งมอบงาน สามแบบ และ สถานะขณะส่งมอบงาน สามแบบดังนี้:

ข้อมูลและการทดสอบ

เพื่อสร้างสถานการณ์ส่งมอบที่สมจริง ผู้เขียนสร้างเกณฑ์ทดสอบจากงานวิศวกรรมซอฟต์แวร์ 75 งานใน SWE-bench Verified โดยเน้นโจทย์ที่ปกติใช้เวลาแก้ตั้งแต่ 15 นาทีถึง 4 ชั่วโมง

แทนที่จะประเมินเฉพาะงานที่เสร็จแล้ว ผู้วิจัยบันทึกจุดตรวจสอบระหว่างทำงานหลายจุด เพื่อสร้างสถานการณ์ที่เอเจนต์ AI ตัวหนึ่งต้องรับช่วงจากอีกตัว:

การสร้างเกณฑ์ทดสอบรับช่วงงาน งาน SWE-bench Verified 75 งานถูกขยายเป็นจุดส่งมอบ 181 จุด ครอบคลุมงานสามระยะ ติดป้ายตามสถานะคลังโค้ดขณะรับช่วง และประเมินภายใต้เงื่อนไขแบ่งปันข้อมูลสี่แบบ รวมเป็นการรับช่วงงานของเอเจนต์ผู้รับช่วงทั้งหมด 2,172 ครั้ง แหล่งที่มา

เพราะแต่ละงานอาจสร้างจุดส่งมอบได้หลายจุด และแต่ละจุดถูกทดสอบด้วยข้อมูลที่ถ่ายทอดสี่รูปแบบ เกณฑ์ทดสอบจึงขยายอย่างรวดเร็ว ข้อมูลสุดท้ายประกอบด้วยงานส่งมอบที่แตกต่างกัน 181 งาน และการประเมินรับช่วง 724 ครั้งต่อโมเดลผู้รับช่วง รวมเป็นการรับช่วง 2,172 ครั้งในระบบ AI ที่ทดสอบสามระบบ

การทดสอบเขียนโค้ดใช้สภาพแวดล้อมแบบ OpenHands ที่รองรับการใช้เทอร์มินัล การตรึงสถานะคลังโค้ด ณ จุดส่งมอบ การแก้ไขไฟล์ และการตรวจสอบอย่างเป็นทางการของ SWE-bench

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

คู่ที่ทดสอบคือ Qwen → Qwen, Qwen → Gemma และ Qwen → Devstral

บันทึกดิบ ช่วยลดแรงของผู้รับช่วงได้มากที่สุด โดยลดจำนวนเหตุการณ์ของเอเจนต์ลง 57–59% ส่วน บันทึกสรุป และ บันทึกแบบมีโครงสร้าง ลดจำนวนเหตุการณ์ลง 20–46% การใช้โทเค็นขาเข้าลดลงเช่นกันในทั้งสามวิธี โดยลดลง 42–63%:

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

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

บันทึกเหตุการณ์ทั้งหมดช่วยลดงานได้มากที่สุด ขณะที่บันทึกสรุปและบันทึกแบบมีโครงสร้างก็ประหยัดงานได้มากเช่นกัน ผลนี้ปรากฏทั่วทั้งเกณฑ์ทดสอบ ไม่ได้เกิดจากกรณีผิดปกติเพียงไม่กี่กรณี:

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

ข้อคิดสำคัญ…

โดยสรุป^† ผู้เขียนพบว่าเมื่อเอเจนต์ AI ส่งงานให้อีกตัวหนึ่ง แม้แต่บันทึกง่าย ๆ ก็ช่วยให้ผู้รับช่วงทำงานต่อได้อย่างมีประสิทธิภาพขึ้น

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

บทสรุป

แม้บทความวิจัยนี้จะเขียนสำหรับนักวิจัยด้วยกันโดยเฉพาะ และมีความน่าสนใจจำกัดสำหรับผู้อ่านทั่วไป งานใหม่นี้ก็ยังศึกษาหนึ่งในปัญหาที่น่าสนใจและเร่งด่วนที่สุดของอินเทอร์เฟซและโพรโทคอลมนุษย์–AI ในปัจจุบัน

หวังว่าแนวทางที่พัฒนาและความเข้าใจที่ได้จากการศึกษาลักษณะนี้จะขยายไปสู่การใช้ AI ที่กว้างขึ้น ไม่จำกัดเพียงการเขียนโค้ดโดยเอเจนต์

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

* โดยส่วนตัว สำหรับการสนทนา ChatGPT ที่ช้าลงเพราะการตอบสนองล่าช้าและบริบทมากเกินไป ช่วงหลังฉันเริ่มส่งออกบทสนทนาเป็น PDF ที่สะอาด แม้จะทำได้ยากอยู่บ้าง แล้วใช้เป็นจุดเริ่มต้นของการสนทนาใหม่ ซึ่งกลายเป็น “ส่วนที่ 2”

^† น่าเสียดายที่นี่ไม่ใช่เอกสารที่อ่านง่ายที่สุดที่ฉันเคยอ่านในปีนี้ และด้วยเหตุนี้ ฉันจึงไม่สามารถแนะนำให้ผู้อ่านไปที่เอกสารต้นฉบับได้ แม้ว่าผลลัพธ์ที่สรุปให้อ่านง่ายแล้วจะยังคงน่าสนใจ

เผยแพร่ครั้งแรกวันพุธที่ 3 มิถุนายน พ.ศ. 2569