การทดลองของนักพัฒนาอิสระคนหนึ่งด้วยโมเดล Claude สามรูปแบบ ช่วยลดค่าใช้จ่าย API รายเดือนลงได้ถึง 35% และลดค่ามัธยฐานของความหน่วงในการทำงาน (latency) จาก 42 วินาที เหลือเพียง 27 วินาที ด้วยการส่งงานที่ง่ายและมีความคลุมเครือต่ำไปยังโมเดล Haiku ที่ราคาถูก, ส่งงานประจำไปยัง Sonnet, และสำรองโมเดลหนักอย่าง Opus ไว้สำหรับปัญหาที่มีความสำคัญสูง ผู้เขียนได้พิสูจน์ให้เห็นว่านิสัยการใช้ "โมเดลที่ดีที่สุดสำหรับทุกอย่าง" นั้นเป็นเรื่องที่สิ้นเปลือง
ทำไมการจัดเส้นทาง (routing) ถึงสำคัญ
ผู้เขียนรันเอเจนต์เขียนโค้ดอัตโนมัติ (autonomous coding agent) ที่ได้รับงานพัฒนาอย่างต่อเนื่อง ไม่ว่าจะเป็นการแก้ไข lint, การเพิ่มฟีเจอร์, การตรวจสอบความปลอดภัย และการดีบั๊กเชิงลึก เป็นเวลาหลายเดือนที่เอเจนต์ส่งทุกคำขอไปยัง Opus ซึ่งเป็นโมเดล Claude ที่มีความสามารถสูงสุด โดยสมมติว่าคุณภาพที่สูงกว่าจะคุ้มค่ากว่าราคาเสมอ แต่เนื่องจาก Opus มีราคาต่อโทเคน (token) ที่สูงมาก ค่าใช้จ่ายจึงเพิ่มขึ้นอย่างควบคุมไม่ได้
เมื่อผู้เขียนนำระบบการจัดเส้นทางแบบแบ่งระดับ (tiered routing scheme) มาใช้ ค่าใช้จ่ายลดลงเหลือเพียง 65% ของระดับเดิม และการใช้งาน Opus ลดลงเหลือเพียง 11% ของงานทั้งหมด
ระบบสามระดับทำงานอย่างไร
ตรรกะการจัดเส้นทางขึ้นอยู่กับ ความคลุมเครือ (ambiguity) ไม่ใช่จำนวนบรรทัดของโค้ดที่งานนั้นต้องแตะ โดยผู้เขียนได้แบ่งงานออกเป็นสามกลุ่ม:
- Haiku – งานที่มีความคลุมเครือต่ำและมีผลลัพธ์ที่แน่นอน (deterministic) ตัวอย่างเช่น: การแก้ไขคำเตือน lint, การเปลี่ยนชื่อตัวแปร, การสรุปไฟล์ log ซึ่งคำตอบที่ถูกต้องมักจะเป็นโค้ดหรือข้อความเพียงบรรทัดเดียว
- Sonnet – ม้างานหลัก (workhorse) สำหรับงานทั่วไป จัดการกับการเพิ่มฟีเจอร์, การแก้ไขบั๊กประจำวัน และการทำ refactor มาตรฐาน ซึ่งปัญหาจะมีความชัดเจนแต่ขั้นตอนการแก้ไขอาจต้องใช้หลายขั้นตอน
- Opus – งานที่มีความสำคัญสูงและมีความคลุมเครือสูง เช่น การตัดสินใจด้านสถาปัตยกรรม (architecture), การตรวจสอบความปลอดภัย, การดีบั๊กที่ซับซ้อน หรือไม่ว่าจะเป็นงานใดก็ตามที่เส้นทางที่ถูกต้องยังไม่ชัดเจน และความผิดพลาดเพียงเล็กน้อยอาจทำให้ pipeline พังได้
ตารางค้นหาแบบคงที่ (static lookup table) จะจับคู่แต่ละคำขอที่เข้ามากับโมเดลที่เหมาะสมตามกฎเหล่านี้ ผู้เขียนได้ลองใช้โมเดลแบบ "ฉลาด" ที่จะตัดสินใจเลือกเลเยอร์ในขณะนั้นเลย แต่การใช้โทเคนส่วนเกินที่เพิ่มขึ้นมาทำให้ความประหยัดที่ควรจะได้หายไปหมด กฎแบบคงที่ (static rules) ที่เรียบง่ายสามารถครอบคลุมภาระงานได้ประมาณ 80% และช่วยให้ระบบมีราคาถูกและคาดการณ์ได้
ตาข่ายนิรภัยสำหรับการยกระดับงาน (escalation safety net)
โมเดลราคาถูกยังคงมีข้อผิดพลาด เพื่อป้องกันไม่ให้คำตอบที่ผิดพลาดจาก Haiku หรือ Sonnet มาทำให้การ build พัง ระบบจะทำการยกระดับ (escalate) คำขอหลังจากเกิดความล้มเหลวสองครั้ง โดยเลื่อนงานนั้นไปยังระดับถัดไป ตาข่ายนิรภัยนี้จะช่วยตรวจจับข้อผิดพลาดได้ตั้งแต่เนิ่นๆ และช่วยให้ pipeline ทำงานได้อย่างราบรื่นโดยไม่ต้องใช้คนเข้ามาจัดการ
ตัวเลขที่พิสูจน์ได้ด้วยตัวเอง
หลังจากรันระบบจัดเส้นทางแบบแบ่งระดับเป็นเวลาสี่สัปดาห์ ผู้เขียนได้บันทึกการเปลี่ยนแปลงดังนี้:
- ค่าใช้จ่าย API ลดลงเหลือ 65% ของค่าใช้จ่ายเดิม (ลดลง 35%)
- เวลาทำงานเฉลี่ย (Median turnaround time) ลดลงจาก 42 วินาที เหลือ 27 วินาที
- การใช้งาน Opus ลดลงจากการที่ต้องจัดการทุกคำขอ เหลือเพียง 11% ของงานทั้งหมด
ตัวเลขเหล่านี้แสดงให้เห็นว่างานพัฒนาส่วนใหญ่สามารถมอบหมายให้กับโมเดลที่ราคาถูกกว่าได้โดยไม่ทำให้คุณภาพลดลงอย่างเห็นได้ชัด ในขณะที่ปัญหาที่ยากที่สุดยังคงได้รับประโยชน์จาก context window ที่ใหญ่กว่าของ Opus
บทเรียนสำหรับนักพัฒนาคนอื่นๆ
- เริ่มจากระดับต่ำ ไม่ใช่ระดับสูง งานเขียนโค้ดประจำวันส่วนใหญ่ไม่จำเป็นต้องใช้โมเดลที่ทรงพลังที่สุด การตั้งค่าให้ Sonnet เป็นค่าเริ่มต้นสำหรับงานที่มีความคลุมเครือช่วยประหยัดเงินได้มากกว่าการพยายามผลักดันทุกอย่างผ่าน Haiku
- วัดความยาก ไม่ใช่ขนาด การแก้ไข race condition เพียงบรรทัดเดียวอาจยากกว่าการทำ refactor ทั้งไฟล์เสียอีก ให้จัดเส้นทางตามความคลุมเครือของวิธีแก้ปัญหา ไม่ใช่ตามจำนวนบรรทัดที่เปลี่ยนไป
- เฝ้าดูอัตราการยกระดับงาน (escalation rate) จำนวนการยกระดับงานที่เพิ่มขึ้นเป็นสัญญาณว่ากฎแบบคงที่เริ่มไม่สอดคล้องกับภาระงานแล้ว ควรปรับปรุงการแบ่งกลุ่มงานก่อนที่โมเดลราคาถูกจะเริ่มทำให้ pipeline ล้มเหลวมากขึ้น
การสำรองโมเดลที่แพงที่สุดไว้สำหรับปัญหาที่ยากที่สุด และปล่อยให้โมเดลที่ราคาถูกกว่าจัดการส่วนที่เหลือ ช่วยให้การพัฒนาที่ใช้ AI สนับสนุนนั้นรวดเร็วและราคาประหยัด ข้อได้เปรียบที่แท้จริงอยู่ที่กลยุทธ์การจัดเส้นทางที่มีวินัย ซึ่งเลือกใช้เครื่องมือที่เหมาะสมกับงานที่ถูกต้อง