ลดค่าใช้จ่ายของเอเจนต์ AI ช่วยเขียนโค้ดโดยไม่ลดคุณภาพงาน: สี่การทดลองที่วัดผลได้จริง

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

ทำไมการทำให้ผลลัพธ์สั้นลงถึงไม่ช่วยลดต้นทุน

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

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

สี่การทดลองและผลที่ได้

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

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

บทเรียนจากการทดลองที่เกือบพลาด

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

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

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

วัดคุณภาพอย่างไรให้เชื่อได้

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

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

ห้าบทเรียนที่ทีมไทยใช้ได้ทันที

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

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