HarnessDev: เมื่อ LLM สร้างโครงสร้างพื้นฐานของตัวเอง
ByteDance และกลุ่มมหาวิทยาลัยได้เปิดตัว HarnessDev ซึ่งเป็นเฟรมเวิร์กที่ช่วยให้โมเดลภาษาขนาดใหญ่ (LLMs) สามารถเขียน “ระบบปฏิบัติการเอเจนต์” (agent operating systems) ของตัวเองได้ ซึ่งเรียกว่า Agent Harnesses โดยทีมงานได้มอบชุดเริ่มต้น (starter kit) ขนาดเล็กให้แก่ LLM และปล่อยให้มันขยายรายละเอียดส่วนที่เหลือ ซึ่งแสดงให้เห็นว่า AI สามารถสร้างเลเยอร์ควบคุม (control layer) ที่รันลูปการใช้เครื่องมือ (tool-use loops) ขั้นตอนการตรวจสอบ (verification steps) และการจัดการข้อผิดพลาด (error handling) ได้ด้วยตัวเอง โดยไม่ต้องให้มนุษย์มานั่งพิมพ์โค้ดทุกบรรทัด
ทำไมการสร้าง harness ด้วยตัวเองถึงสำคัญ
AI agents ได้วิวัฒนาการจากผู้ช่วยที่ตอบโต้ผ่านพรอมต์เดียว ไปสู่การเป็นคนทำงานแบบหลายขั้นตอนที่สามารถเรียกใช้ API, สอบถามฐานข้อมูล และรวบรวมผลลัพธ์เข้าด้วยกัน จนถึงปัจจุบัน นักพัฒนาต้องเขียนโค้ดการจัดการ (orchestration code) ด้วยตัวเอง เพื่อสั่งการโมเดลว่าควรเรียกใช้เครื่องมือค้นหาเมื่อใด จะจัดเก็บสถานะระหว่างทาง (intermediate state) อย่างไร และจะตรวจสอบคำตอบสุดท้ายได้อย่างไร HarnessDev ได้เปลี่ยนโมเดลนั้น: โดยใช้ seed harness เป็นโครงร่าง (scaffolding) ที่มีเพียงฟังก์ชันพื้นฐานสำหรับการทำลูป การเลือกเครื่องมือ และการติดตามสถานะ จากนั้น LLM จะขยายโครงร่างนี้ให้กลายเป็น runtime ที่มีฟีเจอร์ครบถ้วน
จากการทดสอบ (benchmark) ในงานวิจัย พบว่าโมเดลสามารถสร้าง harness ที่แตกต่างกันถึง 18 แบบ โดยเพิ่มโค้ดเข้าไปมากกว่า 17,000 บรรทัด จากชุดเริ่มต้น (seed) เดิม โดยแต่ละ harness สามารถจัดการวงจรชีวิต (life-cycle) ของงานได้อย่างครบถ้วน ตั้งแต่การรันลูป, การเลือกเครื่องมือที่เหมาะสม, การรักษาบริบท (context), การติดตามสถานะ, การตรวจสอบผลลัพธ์ ไปจนถึงการกู้คืนจากข้อผิดพลาด
ต้นทุนแฝงที่การศึกษานี้ค้นพบ
แม้ตัวเลขจะดูน่าประทับใจ แต่ผู้เขียนได้เตือนว่าการเขียนโค้ดขึ้นมาได้นั้นไม่ได้หมายความว่าจะสามารถนำไปใช้งานจริงได้เสมอไป
- ส่วนประกอบที่ไม่ได้ใช้งาน (Unused components) – โค้ดที่ถูกสร้างขึ้นจำนวนมากไม่ได้ถูกเรียกใช้งานเลยในระหว่างการทำงานจริง LLM เขียนฟังก์ชันที่เอเจนต์ไม่เคยเรียกใช้ ซึ่งเป็นการทำให้ฐานโค้ดบวมขึ้นโดยไม่ได้สร้างมูลค่าเพิ่ม
- การยึดติดกับโมเดล (Model lock-in) – Harness มักจะถูกปรับแต่งมาให้เข้ากับ LLM เฉพาะตัวที่สร้างมันขึ้นมา เมื่อนำ harness เดียวกันนี้ไปใช้กับโมเดลอื่น ประสิทธิภาพจะลดลงอย่างเห็นได้ชัด ซึ่งบ่งชี้ว่าตรรกะการควบคุมที่สร้างขึ้นโดยอัตโนมัตินั้นแฝงไปด้วยลักษณะเฉพาะ (quirks) ของโมเดลนั้นๆ
- ช่องว่างในการตรวจสอบ (Verification gaps) – มี harness ทดสอบหนึ่งที่รายงานอัตราความสำเร็จสูงถึง 99% (99 จาก 100 ครั้ง) แต่กลับมีความถูกต้องเพียง 48% เท่านั้น หากไม่มีการตรวจสอบที่เข้มงวด เอเจนต์อาจนำเสนอคำตอบที่ผิดพลาดด้วยความมั่นใจ
- ภาระด้านโทเคน (Token overhead) – การใช้งานโทเคน ซึ่งเป็นตัวบ่งชี้ต้นทุนการประมวลผล มีความผันผวนอย่างมาก โดย harness หนึ่งอาจต้องใช้โทเคนมากกว่าอีกอันถึง 7 เท่า เพื่อให้ได้ผลลัพธ์แบบเดียวกัน ซึ่งทำให้เกิดความกังวลเรื่องความสามารถในการขยายระบบ (scalability) ในสภาพแวดล้อมการใช้งานจริง
สิ่งที่ค้นพบเหล่านี้เน้นย้ำถึงความจำเป็นในการออกแบบอย่างมีระเบียบวินัย แม้ว่าโค้ดนั้นจะถูกสร้างขึ้นโดย LLM ก็ตาม
สิ่งที่นักพัฒนาควรคำนึงถึง
- มองการออกแบบ harness ให้เป็นเรื่องของสถาปัตยกรรม – อย่าหวังพึ่งพาแค่ให้โมเดลทำให้มัน “ใช้งานได้เอง” ควรนิยามโมดูลที่ชัดเจนสำหรับการควบคุมลูป, การเลือกเครื่องมือ, การจัดการสถานะ และการตรวจสอบ ก่อนที่จะปล่อยให้ LLM เข้ามาเติมเต็มรายละเอียด
- สร้างระบบการตรวจสอบที่แข็งแกร่ง – ใส่การตรวจสอบที่ชัดเจนเพื่อเปรียบเทียบสิ่งที่เอเจนต์อ้างกับความจริง (ground truth) หรือใช้โมเดลที่สองช่วยตรวจสอบ ความแม่นยำเพียง 48% ของการศึกษานี้ ทั้งที่มีอัตราความสำเร็จที่รายงานเองถึง 99% แสดงให้เห็นว่าการตรวจสอบไม่ควรเป็นสิ่งที่มาคิดทีหลัง
- ระวังงบประมาณโทเคน – Harness ที่มีความซับซ้อนมากขึ้นอาจทำให้จำนวนโทเคนพุ่งสูงขึ้น ควรทำการทดสอบ (profile) harness รูปแบบต่างๆ ตั้งแต่เนิ่นๆ เพื่อหลีกเลี่ยงต้นทุนที่อาจพุ่งสูงขึ้นอย่างไม่คาดคิด
- ทดสอบกับหลายโมเดล – ลองรัน harness เดียวกันกับ LLM back-ends หลายๆ ตัว หากประสิทธิภาพลดลงอย่างรวดเร็ว คุณอาจจำเป็นต้องใช้การออกแบบที่เป็นกลางต่อโมเดล (model-agnostic) มากขึ้น หรือสร้าง harness แยกเฉพาะสำหรับแต่ละโมเดล
สรุป: HarnessDev พิสูจน์ให้เห็นว่า LLM สามารถร่างโค้ดควบคุมที่มีลักษณะคล้ายกับระบบปฏิบัติการได้ด้วยตัวเอง