เร่งการย้ายการทดสอบขนาดใหญ่ด้วย LLM

• Airbnb ประสบความสำเร็จในการย้ายไฟล์ทดสอบราว 3,500 ไฟล์ที่อิงกับ Enzyme ไปเป็น React Testing Library(RTL) แบบอัตโนมัติ
• งานที่เดิมคาดว่าจะใช้เวลา 1.5 ปี ถูกย่นเหลือเพียง 6 สัปดาห์ด้วย LLM และไปป์ไลน์อัตโนมัติ พร้อมอัปเดตไฟล์ทดสอบ 3.5K ไฟล์เสร็จสิ้น
• ใช้การตรวจสอบความถูกต้องอัตโนมัติ, retry loop, dynamic prompt และการจัดบริบทขนาดใหญ่ เพื่อให้ได้อัตราความสำเร็จของระบบอัตโนมัติที่สูง
• สุดท้ายสามารถ แปลงไฟล์ทั้งหมดแบบอัตโนมัติได้ 97% และปิดงานที่เหลือด้วยการแก้ไขด้วยมือจนเสร็จ 100%
• จากประสบการณ์นี้ บริษัทกำลัง วางแผนขยายไปสู่งานย้ายระบบที่ซับซ้อนขึ้นและเครื่องมือพัฒนาที่ขับเคลื่อนด้วย LLM

---

การย้ายการทดสอบขนาดใหญ่ด้วย LLM ของ Airbnb

เบื้องหลัง

• Airbnb ใช้ React Testing Library(RTL) กับการทดสอบใหม่มาตั้งแต่ปี 2020 และเริ่ม เปลี่ยนผ่านออกจาก Enzyme
• Enzyme ใช้วิธีเข้าถึงรายละเอียดการทำงานภายในอย่างลึก ซึ่งไม่สอดคล้องกับแนวคิด React สมัยใหม่ จึงเกิด ความจำเป็นในการเลิกใช้อย่างค่อยเป็นค่อยไป
• การลบออกแบบตรง ๆ อาจทำให้ เกิดช่องว่างของ test coverage จึงจำเป็นต้องแปลงโดยคงเจตนาและ coverage เดิมไว้

กลยุทธ์การย้ายระบบ

1. การตรวจสอบความถูกต้องและรีแฟกเตอร์แบบเป็นขั้นตอน

• จัดไฟล์เป็นไปป์ไลน์ตามสถานะ และจะไปยังขั้นถัดไปเมื่อผ่านการตรวจสอบของแต่ละขั้น
• หากล้มเหลวจะเรียก LLM มาช่วยแก้ไข โดยขั้นตอนตัวอย่างคือ ลบ enzyme → แก้ jest → ผ่าน lint/tsc → ทำเครื่องหมายว่าเสร็จ
• รองรับการประมวลผลแบบขนานหลายร้อยไฟล์, ไฟล์ง่ายเสร็จเร็ว ส่วนไฟล์ซับซ้อนค่อย ๆ แก้ไปทีละขั้น

2. Retry loop และ dynamic prompt

• ขั้นที่ล้มเหลวจะ รันซ้ำตามจำนวนครั้งสูงสุดที่กำหนดไว้
• ในแต่ละครั้งจะ ใส่ข้อความ error และไฟล์ที่แก้ไขแล้วลงใน prompt เพื่อส่ง feedback ให้ LLM
• ไฟล์ส่วนใหญ่ที่มีความยากระดับง่ายถึงปานกลาง สำเร็จได้ภายในไม่เกิน 10 ครั้ง

3. ขยายบริบทของ prompt

• ไฟล์ที่ซับซ้อนไม่สามารถแก้ได้ด้วยการ retry แบบง่าย ๆ จึง เปลี่ยนไปใช้แนวทางให้บริบทที่สมบูรณ์ยิ่งขึ้น
• จัดบริบทได้สูงสุดถึง 100,000 โทเค็น โดยมีสิ่งที่รวมเข้าไป เช่น
  • ซอร์สโค้ดของคอมโพเนนต์นั้น
  • การทดสอบ Enzyme เดิม
  • การทดสอบข้างเคียงและตัวอย่าง (few-shot prompting)
  • สไตล์ภายในทีมและแพตเทิร์นที่ใช้ร่วมกัน
• แก่นสำคัญคือ การเลือกไฟล์ที่เกี่ยวข้องและมีคุณภาพ ซึ่งสำคัญกว่าเนื้อประโยคใน prompt เองว่า "จะใส่อะไรเข้าไป"

4. ดันจาก 75% ไปสู่ 97%: การปรับปรุงอย่างเป็นระบบ

• หลังจากแปลงอัตโนมัติได้ 75% แล้ว ในอีก 25% ที่เหลือยังมี 900 ไฟล์ที่อยู่ในสถานะล้มเหลว
• มีการวิเคราะห์ปัญหาและปรับปรุงซ้ำตามรอบ:
  1. รวบรวมประเด็นร่วมของไฟล์ที่ล้มเหลว
  2. เลือกตัวอย่างที่เป็นตัวแทน (5~10 ไฟล์)
  3. ปรับปรุง prompt/สคริปต์
  4. ทดสอบกับตัวอย่างก่อน แล้วค่อยลองใหม่ทั้งชุด
• รันวนซ้ำเป็นเวลา 4 วัน จน อัตราการทำงานอัตโนมัติสำเร็จแตะ 97%

3% ที่เหลือจัดการด้วยมือ

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

ผลลัพธ์และผลกระทบ

• การรันอัตโนมัติครั้งแรกใช้เวลาเพียง 4 ชั่วโมงและย้ายได้เสร็จ 75%
• ปรับปรุงซ้ำต่อเนื่อง 4 วันจนทำอัตโนมัติได้ 97%
• เมื่อรวมส่วนที่ต้องแก้ด้วยมือแล้ว ก็ ย้ายทั้งหมดเสร็จ 100% ภายใน 6 สัปดาห์
• เลิกใช้ Enzyme ได้ทั้งหมด โดยยังคงเจตนาของการทดสอบและ coverage ไว้
• แม้นับรวมค่าใช้จ่าย API ของ LLM และทรัพยากรวิศวกรรม ก็ยังมีประสิทธิภาพสูงมากเมื่อเทียบกับการทำมือ

ขั้นต่อไป

• จากประสบการณ์ครั้งนี้ บริษัทเริ่ม เดินหน้าสู่การทำงานแปลงโค้ดอัตโนมัติขนาดใหญ่ยิ่งขึ้นด้วย LLM
• กำลังสำรวจความเป็นไปได้ในการนำไปใช้กับรีแฟกเตอร์ที่ซับซ้อนและการเปลี่ยนโครงสร้างระบบ