ทีมวิจัยได้สร้างเราเตอร์ขึ้นมาเพื่อตัดสินใจว่าโมเดลภาษาที่มีราคาถูกจะสามารถจัดการกับคำขอเขียนโค้ดได้หรือไม่ โดยหวังว่าจะช่วยลดต้นทุนในการประมวลผล (inference costs) แต่เราเตอร์กลับไม่สามารถทำผลงานได้ดีกว่าเกณฑ์มาตรฐานแบบ "ไม่ส่งต่อเลย" (never-escalate baseline) ความล้มเหลวนี้แสดงให้เห็นว่าทำไมตัวชี้วัดที่เน้นความแม่นยำเป็นหลักจึงทำให้การใช้โมเดลแบบลำดับชั้น (cascades) ผิดพลาด และชี้ให้เห็นถึงสัญญาณที่สามารถจับความยากของงานได้อย่างแท้จริง

ทำไมเราเตอร์ถึงมีความสำคัญ

การใช้โมเดลแบบลำดับชั้น (Model cascades) จะส่งแต่ละคำขอไปยังโมเดลขนาดเล็กที่สุดที่สามารถตอบคำถามได้อย่างถูกต้อง หากเราเตอร์ส่งคำสั่ง (prompt) ที่ง่ายไปยังโมเดลราคาถูก ระบบจะข้ามขั้นตอนการประมวลผลที่มีราคาแพงซึ่งจำเป็นสำหรับโมเดลขนาดใหญ่ไป ทีมวิจัยได้ฝึกฝนเราเตอร์ด้วยงานเขียนโค้ดจริง 539 งาน โดยแบ่งเป็นงานง่าย 428 งาน และงานยาก 111 งาน โดยคาดหวังว่ามันจะเรียนรู้ว่าเมื่อใดที่โมเดลราคาถูกเพียงพอต่อการใช้งาน

ตัวเลขที่ไม่เป็นไปตามเป้า

  • Held-out AUC (พื้นที่ใต้เส้นโค้ง ROC): 0.594
  • ช่วงจากการทำ 5-fold cross-validation: 0.55 – 0.57
  • ค่าเกณฑ์ (threshold) ที่ดีที่สุด: ตรงกับนโยบายแบบ "ไม่ส่งต่อเลย" (never escalate)

ค่า Held-out AUC อยู่ที่ 0.594 และช่วงจากการทำ cross-validation อยู่ที่ 0.55 ถึง 0.57 ซึ่งหมายความว่าตัวจำแนกประเภท (classifier) แทบจะไม่สามารถแยกแยะระหว่างกรณีที่ง่ายและยากได้เลย เมื่อค่าเกณฑ์ที่เหมาะสมที่สุดให้ผลลัพธ์ตรงกับนโยบายที่ไม่ใช้โมเดลราคาแพงเลย แสดงว่าเราเตอร์ไม่ได้สร้างมูลค่าเพิ่มขึ้นมา มันทำงานเหมือนตัวทำนายค่าคงที่มากกว่าจะเป็นผู้ช่วยตัดสินใจ

สิ่งที่การทดลองได้ทดสอบ

นักวิจัยได้เปรียบเทียบชุดคุณลักษณะ (feature sets) สามรูปแบบ:

ชุดคุณลักษณะ (Feature set) AUC
คุณลักษณะพื้นฐานแบบง่าย 11 อย่าง (เช่น จำนวน token, การปรากฏของคำสำคัญ) 0.610
prompt embedding ขนาด 1024 มิติ (semantic vector) 0.552
รวมทั้งสองแบบ 0.609

สิ่งที่น่าประหลาดใจคือ คุณลักษณะพื้นฐาน (surface features) ที่มีน้ำหนักเบากลับให้ผลลัพธ์ดีกว่า semantic embedding ที่มีมิติสูง การทำ embedding สามารถจับหัวข้อของ prompt ได้ แต่ไม่สามารถจับความยากที่แท้จริงของมันได้ การส่งร่างคำตอบ (draft) ของโมเดลราคาถูกให้เราเตอร์ช่วยพิจารณาทำให้ค่า AUC เพิ่มขึ้นเป็น 0.640 ซึ่งบ่งชี้ว่าสัญญาณที่ปรากฏขึ้นระหว่างการสร้างคำตอบ (generation) ให้ข้อมูลที่เป็นประโยชน์มากกว่าสัญญาณที่มีอยู่แค่ใน prompt เพียงอย่างเดียว

ข้อผิดพลาดพื้นฐานสองประการ

1. ความแม่นยำไม่ใช่บรรทัดฐานที่ถูกต้อง

เราเตอร์ต้องปรับปรุงการแลกเปลี่ยนระหว่างต้นทุนและความแม่นยำ (cost-accuracy trade-off) ให้ดีกว่านโยบายแบบพื้นฐาน ไม่ใช่แค่ทำนายความถูกต้องเท่านั้น หากมันไม่สามารถทำผลงานได้ดีกว่า "การไม่ส่งต่อเลย" มันก็ไม่ช่วยลดต้นทุน ไม่ว่าความแม่นยำดิบจะเป็นอย่างไรก็ตาม ตัวชี้วัดแบบดั้งเดิมอย่าง AUC มักจะละเลยมิติทางเศรษฐศาสตร์ของการใช้โมเดลแบบลำดับชั้น

2. "การส่งต่อเสมอ" ไม่ใช่เพดานสูงสุด

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

การออกแบบสัญญาณการจัดเส้นทาง (routing signals) ที่ดีกว่าเดิม

ผลการวิจัยเสนอแนะแนวทางปฏิบัติสามประการ:

  • รวมสัญญาณในช่วงระหว่างการสร้าง (generation-time cues): การส่งผลลัพธ์ระหว่างทาง (intermediate output) ของโมเดลราคาถูกให้เราเตอร์ จะช่วยจับความยากที่ prompt เพียงอย่างเดียวไม่สามารถบอกได้
  • ให้ความสำคัญกับคุณลักษณะพื้นฐานเฉพาะงาน: ตัวชี้วัดง่ายๆ เช่น ความยาว, การปรากฏของตัวดำเนินการ (operators) บางอย่าง หรือเครื่องหมายบ่งชี้สไตล์ของโค้ด อาจทำนายผลได้ดีกว่า semantic embeddings แบบทั่วไป
  • วัดความสำเร็จด้วยตัวชี้วัดที่คำนึงถึงต้นทุน: แทนที่จะใช้ความแม่นยำหรือ AUC เพียงอย่างเดียว ให้ประเมินว่าสามารถหลีกเลี่ยงการเรียกใช้โมเดลราคาแพงได้มากน้อยเพียงใด ในขณะที่ยังคงรักษาคุณภาพตามระดับที่กำหนดไว้

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