AI Model Routing: เลือกโมเดลเล็กหรือใหญ่ต่อคำขอ ไม่ใช่ล็อกโมเดลเดียวทั้งระบบ

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

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

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

AI Model Routing คืออะไร ต่างจากการเลือกโมเดลตัวเดียวใช้ทั้งระบบอย่างไร

AI Model Routing คือชั้น Logic ที่แทรกอยู่ระหว่างแอปพลิเคชันกับ Provider โมเดลต่าง ๆ ทำหน้าที่ตัดสินใจว่าคำขอแต่ละครั้งควรถูกส่งไปยังโมเดลตัวไหน อาจเป็นการเลือกระหว่างโมเดลขนาดต่างกันจาก Provider เดียวกัน หรือเลือกข้ามผู้ให้บริการหลายเจ้าตามความเหมาะสมของแต่ละงาน

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

สิ่งสำคัญที่ต้องเข้าใจคือ Routing ไม่ใช่แค่เรื่อง 'ถูกกว่า' อย่างเดียว บางครั้งการ Route ไปโมเดลที่เร็วกว่าแต่แพงกว่าเล็กน้อยก็คุ้มค่ากว่า ถ้างานนั้นต้องการ Latency ต่ำเป็นพิเศษ เช่น ฟีเจอร์ที่ผู้ใช้รอคำตอบแบบ Real-time

ใช้สัญญาณอะไรตัดสินใจว่าจะ Route ไปโมเดลไหน

สัญญาณที่ใช้ตัดสินใจ Route มีได้หลายแบบ และระบบที่ดีมักผสมหลายสัญญาณเข้าด้วยกัน ไม่ใช่ตัดสินจากปัจจัยเดียว

• ความยาวและความซับซ้อนของ Input เช่น จำนวน Token ของข้อความหรือเอกสารที่ต้องประมวลผล
• ประเภทของงาน เช่น Classification ที่มีคำตอบจำกัด กับ Reasoning ที่ต้องคิดหลายขั้นตอน
• ระดับความมั่นใจที่ต้องการในผลลัพธ์ งานที่ผลกระทบสูง เช่น การตัดสินใจทางการเงิน อาจต้องบังคับใช้โมเดลใหญ่เสมอ
• Latency ที่ผู้ใช้ยอมรับได้ ฟีเจอร์ที่ต้องตอบทันทีอาจต้องเลี่ยงโมเดลใหญ่ที่ตอบช้ากว่า แม้จะแม่นยำกว่าก็ตาม
• งบประมาณคงเหลือของ Feature นั้นในช่วงเวลานั้น บางระบบ Route ไปโมเดลเล็กเมื่อใกล้ชนเพดานงบที่ตั้งไว้รายวันหรือรายเดือน

เปรียบเทียบกลยุทธ์ Routing แบบต่าง ๆ ที่ใช้กันจริง

มีหลายวิธีในการตัดสินใจ Route แต่ละแบบมีความซับซ้อนในการสร้างและความแม่นยำต่างกัน ทีมควรเลือกตามขนาดของระบบและทรัพยากรที่มี ไม่จำเป็นต้องเริ่มจากวิธีที่ซับซ้อนที่สุดตั้งแต่วันแรก

เริ่มสร้างระบบ Model Routing จากศูนย์อย่างเป็นขั้นตอน

1. เก็บข้อมูล Log การใช้งานจริงก่อน อย่างน้อย 2-4 สัปดาห์ เพื่อดูว่า Endpoint ไหนมีปริมาณ Request สูง และงานแบบไหนที่ปัจจุบันใช้โมเดลใหญ่เกินความจำเป็นจริง
2. จัดกลุ่มประเภทงานตามความซับซ้อน แบ่งเป็นอย่างน้อยสามระดับ เช่น งานง่าย (Classification, Extraction สั้น), งานปานกลาง (สรุปเอกสารความยาวปกติ), งานซับซ้อน (Reasoning หลายขั้น, วิเคราะห์เอกสารยาว)
3. เริ่มจาก Rule-based Routing ก่อนเสมอ เพราะสร้างง่ายและ Debug ตรงไปตรงมา ยังไม่ต้องรีบทำ Classifier-based Routing ตั้งแต่วันแรก
4. ตั้งค่า Monitoring แยกตามโมเดลที่ใช้ เพื่อเปรียบเทียบทั้งต้นทุนและคุณภาพผลลัพธ์ระหว่างโมเดลเล็กกับโมเดลใหญ่ในงานประเภทเดียวกัน
5. ทยอยปรับ Threshold การ Route ตามข้อมูลจริงที่เก็บได้ ไม่ใช่ตั้งครั้งเดียวแล้วปล่อยไว้ตลอด เพราะพฤติกรรมผู้ใช้และราคาของแต่ละโมเดลเปลี่ยนแปลงได้ตลอดเวลา

ความเสี่ยงด้านคุณภาพที่มาพร้อม Model Routing

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

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

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

ทำแบบนี้แล้วพัง: กับดักที่ทีมมักเจอตอนเริ่มทำ Model Routing

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

• ทำแบบนี้แล้วพัง เพราะตั้ง Threshold แบ่งงานง่าย-ยากจากความยาว Input อย่างเดียว โดยไม่ดูความซับซ้อนของเนื้อหา ทำให้คำถามสั้นแต่ต้องใช้เหตุผลลึกถูก Route ไปโมเดลเล็กแล้วตอบผิด
• ทำแบบนี้แล้วพัง เพราะไม่มี Monitoring แยกตามโมเดล เมื่อคุณภาพคำตอบโดยรวมลดลง ทีมไม่รู้ว่าเป็นเพราะโมเดลเล็กที่เพิ่ง Route ไปใช้เยอะขึ้น หรือเป็นปัญหาจาก Prompt เดิม
• ทำแบบนี้แล้วพัง เพราะเปลี่ยน Provider ของโมเดลเล็กที่ใช้ Route โดยไม่ทดสอบ Prompt เดิมซ้ำ ผลลัพธ์ที่เคยดีจากโมเดลเล็กตัวเก่ากลับแย่ลงเพราะโมเดลใหม่ตีความ Prompt ต่างออกไป
• ทำแบบนี้แล้วพัง เพราะไม่มีกลไก Fallback เมื่อโมเดลเล็กตอบด้วยความมั่นใจต่ำ ปล่อยให้คำตอบคุณภาพต่ำหลุดไปถึงผู้ใช้โดยตรง ทั้งที่ควรมีการยกระดับไปโมเดลใหญ่โดยอัตโนมัติในกรณีแบบนี้

Model Routing เชื่อมโยงกับ Fallback Strategy และการคุมต้นทุนอย่างไร

Model Routing ไม่ได้ทำงานอย่างโดดเดี่ยว มันมักอยู่คู่กับ LLM Fallback Strategy ในระบบเดียวกัน เพราะการ Route ไปโมเดลใดโมเดลหนึ่งอาจล้มเหลวได้จากหลายสาเหตุ เช่น Provider ตอบช้าเกินไปหรือ Error ชั่วคราว ระบบที่ดีจึงควรมีทั้งตรรกะ Routing ตามความเหมาะสมของงาน และ Fallback ตามความพร้อมใช้งานของแต่ละ Provider ควบคู่กัน รายละเอียดของการวางแผนสำรองนี้อธิบายไว้ใน บทความเรื่อง LLM Fallback Strategy

ในมุมของการคุมต้นทุนโดยรวม Model Routing เป็นเพียงหนึ่งในหลายเทคนิคที่ใช้ร่วมกันได้ เช่น การทำ Prompt Caching เพื่อลดค่าใช้จ่ายของ Context ที่ซ้ำกันบ่อย หรือการกำหนด Token Budget ต่อ Feature ไว้ล่วงหน้า ทีมที่อยากเห็นภาพรวมของแนวทางลดต้นทุนทั้งหมดควรอ่านเพิ่มเติมที่ บทความเรื่องลดค่าใช้ AI Application ซึ่งอธิบายว่าเทคนิคเหล่านี้ควรใช้ร่วมกันอย่างไรจึงจะได้ผลสูงสุด

ตัวอย่างตัวเลขประกอบ: Routing ลดต้นทุนได้เท่าไรในทางปฏิบัติ

ลองดูตัวอย่างสมมติต่อไปนี้เพื่อให้เห็นภาพว่าการ Route งานอย่างเหมาะสมส่งผลต่อต้นทุนรวมอย่างไร (ตัวอย่างสมมติสำหรับกรอบวิเคราะห์เท่านั้น ไม่ใช่ราคาจริงของ Provider ใด และไม่ใช่ผลลัพธ์ของลูกค้ารายใด)

สมมติระบบหนึ่งมี Request เข้ามาวันละ 100,000 ครั้ง แบ่งเป็นงานจำแนกข้อความสั้น 70% งานสรุปเอกสารความยาวปานกลาง 20% และงานวิเคราะห์เชิงเหตุผลซับซ้อน 10% ถ้าระบบเดิมส่งทุก Request ไปโมเดลใหญ่ตัวเดียวโดยไม่มี Routing ต้นทุนรวมต่อวันจะคำนวณจากราคาต่อ Token ของโมเดลใหญ่คูณกับทั้ง 100,000 Request

เมื่อเพิ่ม Routing เข้ามา งานจำแนกข้อความสั้น 70,000 Request ถูกส่งไปโมเดลเล็กที่ราคาต่อ Token ต่ำกว่าโมเดลใหญ่หลายเท่า งานสรุปเอกสาร 20,000 Request ยังคงใช้โมเดลขนาดกลาง ส่วนงานวิเคราะห์เชิงเหตุผล 10,000 Request เท่านั้นที่ยังต้องใช้โมเดลใหญ่ที่แพงที่สุด ผลลัพธ์คือสัดส่วนต้นทุนของ Request ที่ใช้โมเดลราคาแพงที่สุดลดลงจาก 100% เหลือเพียง 10% ของปริมาณ Request ทั้งหมด แม้ตัวเลขต้นทุนที่ประหยัดได้จริงจะขึ้นกับราคาต่อ Token ของแต่ละ Provider ณ ช่วงเวลานั้น แต่หลักการที่ว่าสัดส่วน Request ที่ใช้โมเดลแพงลดลงตามการจัดกลุ่มงานอย่างเหมาะสม คือแก่นของสิ่งที่ Model Routing ทำให้เกิดขึ้นจริง

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

สรุป

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

ทีมที่เริ่มทำควรเริ่มจากกลยุทธ์ง่ายที่สุดก่อน มี Monitoring แยกตามโมเดล และเตรียมกลไก Fallback ไว้เสมอเพื่อจับกรณีที่โมเดลเล็กตอบได้ไม่ดีพอ Model Routing ที่ดีไม่ใช่แค่เรื่องลดต้นทุน แต่คือการทำให้ทั้งต้นทุนและคุณภาพสมดุลกันตามลักษณะงานจริงของแต่ละ Endpoint

• Model Routing คือการเลือกโมเดลตามความซับซ้อนของแต่ละคำขอ ไม่ใช่ล็อกโมเดลเดียวใช้ทั้งระบบ
• เริ่มจาก Rule-based Routing ก่อน แล้วค่อยพัฒนาไปสู่ Classifier-based เมื่อข้อมูลจริงบ่งชี้ว่าจำเป็น
• ต้องมี Fallback ยกระดับไปโมเดลใหญ่เมื่อคำตอบจากโมเดลเล็กความมั่นใจต่ำ เพื่อรักษาคุณภาพโดยรวม

คำถามที่พบบ่อย