LLM Model Routing คือวิธีการทางสถาปัตยกรรมที่ทำการจัดสรรโมเดลหลายรูปแบบ เช่น GPT, Claude และ Gemini ให้กับงานต่างๆ อย่างเหมาะสมตามความซับซ้อนของงานและข้อกำหนดด้านต้นทุน

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

ในบทความนี้ เราจะอธิบายเนื้อหาตามหัวข้อต่อไปนี้ตามลำดับ

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

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

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

การใช้โมเดลเดียวในการดำเนินงานมักก่อให้เกิดปัญหาหลัก 3 ประการ ดังนี้:

• ความไม่มีประสิทธิภาพด้านต้นทุน: การเรียกใช้โมเดลประสิทธิภาพสูงกับงานง่ายๆ เช่น การตอบคำถาม FAQ หรือการจัดหมวดหมู่ข้อมูล จะทำให้ต้นทุน API ต่อโทเค็นสะสมสูงขึ้น จากกรณีศึกษาของ AWS พบว่าแม้จะประมวลผลจำนวนโทเค็นเท่ากันในงานประเภท History และ Math แต่ต้นทุนในการสร้างคำตอบกลับมีความแตกต่างกันอย่างมาก ซึ่งแสดงให้เห็นว่าการกำหนดเส้นทาง (Routing) โดยไม่คำนึงถึงความยากง่ายของงานนั้นส่งผลให้ต้นทุนพุ่งสูงขึ้นอย่างไร
• ความล่าช้าที่หลีกเลี่ยงไม่ได้: โมเดลขนาดใหญ่ใช้เวลาในการประมวลผลนาน ทำให้ความเร็วในการตอบสนองช้าลงแม้จะเป็นคำขอที่เรียบง่าย ซึ่งถือเป็นจุดตายสำหรับงานที่ต้องการความรวดเร็วแบบเรียลไทม์ที่ส่งผลโดยตรงต่อประสบการณ์ของผู้ใช้
• ข้อจำกัดด้านคุณภาพ: ในทางกลับกัน หากพยายามจัดการงานที่ต้องใช้การอนุมาน (Inference) ที่ซับซ้อนด้วยโมเดลขนาดเล็กเพียงอย่างเดียว ความแม่นยำของคำตอบก็จะลดลง นี่คือภาวะกลืนไม่เข้าคายไม่ออกเชิงโครงสร้างที่ว่า หากปรับให้เหมาะสมกับโมเดลหนึ่ง ก็จะไม่สามารถตอบโจทย์ความต้องการของอีกโมเดลหนึ่งได้

การก้าวข้ามขีดจำกัดเหล่านี้คือสิ่งที่เรียกว่า LLM Model Routing ซึ่งเป็นการจัดสรรงานไปยังโมเดลที่เหมาะสมที่สุดโดยอัตโนมัติตามลักษณะของงาน (ความซับซ้อน, โดเมน, และข้อกำหนดด้านความเร็วในการตอบสนอง) ทำให้สามารถควบคุมทั้งต้นทุนและคุณภาพไปพร้อมกันได้

ในงานวิจัยของ HyDRA ได้รายงานผลลัพธ์ว่า ค่ามัธยฐานของความล่าช้าในการอนุมานบน CPU ของตัวทำนาย (Predictor) อยู่ที่ 86 ms ในขณะที่สามารถลดต้นทุนลงได้ถึง 54.1% ภายใต้เงื่อนไข iso-quality (คุณภาพเท่าเดิม)

แนวคิดที่ว่า "ควรใช้โมเดลความแม่นยำสูงตลอดเวลา" มักจะดำเนินต่อไปจนกว่าต้นทุนจะกลายเป็นอุปสรรคในความเป็นจริง

ในขณะที่โมเดลระดับสูงของ GPT และ Claude มีความสามารถในการใช้เหตุผลสูง แต่ราคาต่อโทเค็นก็สูงเช่นกัน ในกรณีศึกษาของ AWS ต้นทุนการสร้างคำตอบสำหรับโจทย์คณิตศาสตร์สูงถึง 7,425 ดอลลาร์ต่อเดือน ในขณะที่โจทย์ประวัติศาสตร์ที่มีปริมาณโทเค็นเท่ากันกลับมีต้นทุนเพียง 618.75 ดอลลาร์ ซึ่งเป็นตัวอย่างที่ดีที่แสดงให้เห็นว่าโครงสร้างต้นทุนมีความแตกต่างกันอย่างมากตามระดับความยากของงาน

Model Routing ทำหน้าที่เป็นวิธีการลดช่องว่างนี้ โดยสามารถแก้ไขข้อแลกเปลี่ยน (Trade-off) ได้ 3 ประการ ดังนี้:

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

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

ใน Intelligent Prompt Routing ของ Amazon Bedrock มีรายงานว่าแนวทางนี้ช่วยลดต้นทุนได้สูงสุดถึง 30% นอกจากนี้ งานวิจัยของ HyDRA ยังแสดงให้เห็นผลลัพธ์ที่สามารถลดต้นทุนได้ถึง 54.1% โดยยังคงรักษาคุณภาพไว้ได้ และหากตั้งค่าแบบเชิงรุก (Aggressive setting) จะสามารถลดต้นทุนได้ถึง 72.5% (โดยมีส่วนต่างของคุณภาพอยู่ที่ 3.2 จุด)

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

รูปแบบ Routing สามารถแบ่งออกเป็น 3 ประเภทหลัก ดังนี้:

• Rule-based Routing: จัดสรรตามเงื่อนไขแบบคงที่ เช่น ความยาวของ Query, คำสำคัญ (Keyword) หรือประเภทของงาน เป็นวิธีที่เรียบง่ายที่สุดในการนำไปใช้งานจริง และแทบไม่มี Overhead ของ Latency แต่หากเงื่อนไขการแบ่งแยกมีความซับซ้อนขึ้น มักจะทำให้ค่าใช้จ่ายในการบำรุงรักษาเพิ่มสูงขึ้น
• Dynamic Routing โดยใช้ Classification Model: ใช้ตัวจำแนกประเภท (Classifier) ขนาดเบาในการคาดการณ์ความยากหรือเจตนาของ Query แล้วส่งต่อไปยังโมเดลที่เหมาะสม ในงานวิจัยอย่าง HyDRA ได้แสดงให้เห็นว่าค่ามัธยฐานของ Latency ในการอนุมาน (Inference) ด้วย CPU ของตัวคาดการณ์นั้นถูกจำกัดไว้ที่ 86 ms ซึ่งสามารถลดผลกระทบต่อ Throughput ให้เหลือน้อยที่สุดได้
• Cascaded Routing: เริ่มจากการสร้างคำตอบด้วยโมเดลขนาดเบาที่มีต้นทุนต่ำ และจะส่งต่อ (Escalate) ไปยังโมเดลประสิทธิภาพสูงก็ต่อเมื่อคะแนนความเชื่อมั่น (Confidence Score) ต่ำกว่าเกณฑ์ที่กำหนดเท่านั้น งานวิจัยของ TRIM รายงานว่ากลยุทธ์นี้สามารถลดปริมาณการใช้ Token ของโมเดลที่มีต้นทุนสูงลงได้อย่างมาก

รูปแบบเหล่านี้ไม่ได้แยกขาดจากกัน และมักมีการนำมาใช้ร่วมกัน ตัวอย่างเช่น การใช้โครงสร้างสองชั้นที่ "ใช้ Rule-based ในการจำแนกประเภทงานคร่าวๆ แล้วส่งเฉพาะ Query ที่กำกวมให้ Classification Model จัดการ" เป็นโครงสร้างที่ช่วยให้รักษาสมดุลระหว่างความแม่นยำและ Overhead ได้ง่าย

ในส่วนถัดไป เราจะมาสรุป "การเตรียมความพร้อม" ที่จำเป็นต้องทำเหมือนกันไม่ว่าจะเลือกใช้รูปแบบใดก็ตาม

บทสรุป: ความสำเร็จหรือความล้มเหลวของการออกแบบ Routing ตัดสินกันที่ 80% ตั้งแต่ขั้นตอนการเตรียมการก่อนเริ่ม Implement

หากละเลยการเตรียมการทั้ง 3 ด้าน ได้แก่ การจัดระเบียบ Use Case, การคัดเลือก Model Candidate และการตรวจสอบ Infrastructure Requirements จะนำไปสู่การแก้ไขงานจำนวนมากในขั้นตอนถัดไป ในแต่ละหัวข้อ H3 ต่อจากนี้ จะอธิบายขั้นตอนการดำเนินงานอย่างละเอียดตามลำดับ

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

สิ่งแรกที่ควรทำคือการระบุ Use case ของบริษัทและจัดหมวดหมู่ Query โดยเกณฑ์การจำแนกประเภทที่สำคัญมีดังนี้:

• ความซับซ้อน (Complexity): การตอบ FAQ แบบง่าย / คำถามที่ต้องใช้การอนุมานหลายขั้นตอน / การสร้างโค้ดหรือการประมวลผลทางคณิตศาสตร์
• โดเมน (Domain): ความรู้ทั่วไป / สาขาเฉพาะทาง (กฎหมาย, การแพทย์, การเงิน) / ข้อมูลเฉพาะภายในองค์กร
• รูปแบบเอาต์พุต (Output Format): คำตอบสั้นๆ / การสรุปความยาว / ข้อมูลที่มีโครงสร้าง (JSON, ตาราง)
• ข้อกำหนดด้าน Latency: ต้องการการตอบสนองแบบเรียลไทม์ / สามารถยอมรับการประมวลผลแบบ Batch ได้

จากนั้น ให้ทำการ Mapping เบื้องต้นว่า "โมเดลใดเหมาะสม" กับแต่ละหมวดหมู่ ตัวอย่างเช่น การจัดสรรโมเดลขนาดเล็กให้กับ FAQ แบบง่าย และจัดสรรโมเดลประสิทธิภาพสูงให้กับ Query ที่ต้องใช้การอนุมานหลายขั้นตอน

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

สุดท้าย การสร้างชุดข้อมูลตัวอย่าง (Sample Dataset) ที่มีการติดป้ายกำกับ (Label) ไว้ จะช่วยให้สามารถนำไปใช้ในการสร้างโมเดลจำแนกประเภทหรือประเมินความแม่นยำของ Routing ในภายหลังได้โดยตรง ความพยายามเพียงเล็กน้อยในขั้นตอนการออกแบบนี้จะช่วยลดงานที่ต้องย้อนกลับมาแก้ไขในขั้นตอนการใช้งานจริงได้อย่างมหาศาล

การคัดเลือกโมเดลเริ่มต้นจากการตอบคำถามที่ว่า "จะใช้โมเดลอะไรสำหรับงานใด" หากเริ่มประเมินโดยไม่จำกัดตัวเลือกให้แคบลงก่อน จะทำให้เกณฑ์การเปรียบเทียบไม่ชัดเจนและส่งผลให้การออกแบบการทำ Routing โดยรวมหลงทางได้ง่าย

ประเด็นที่ควรตรวจสอบเมื่อทำการคัดเลือก

• ความเหมาะสมกับงาน (Task Suitability): โมเดลแต่ละตัวมีความถนัดแตกต่างกันไปตามประเภทของงาน เช่น การสรุปความยาว การเขียนโค้ด หรือการใช้เหตุผลทางคณิตศาสตร์
• ช่วงราคา (Cost Range): เปรียบเทียบราคาต่อ Token ของ Input และ Output ระหว่างโมเดลขนาดเล็กและโมเดลประสิทธิภาพสูง เพื่อทำความเข้าใจส่วนต่างของต้นทุนเป็นตัวเลข
• ความยาวของบริบท (Context Length): หากต้องจัดการกับเอกสารที่มีความยาวมาก ความยาวสูงสุดของบริบทจะเป็นเงื่อนไขเบื้องต้นในการคัดเลือกโมเดล
• ลักษณะของความหน่วง (Latency Characteristics): กำหนดเกณฑ์การตัดสินใจไว้ล่วงหน้า เช่น เลือกโมเดลขนาดเล็กหากต้องการการตอบสนองแบบเรียลไทม์ หรือเลือกโมเดลประสิทธิภาพสูงหากเน้นความแม่นยำในการประมวลผลแบบ Batch

การกำหนดตัวชี้วัดในการประเมิน

เมื่อเปรียบเทียบโมเดลที่เป็นตัวเลือก สิ่งสำคัญคือต้องมีทั้งการประเมินเชิงคุณภาพและตัวชี้วัดเชิงปริมาณ โดยตัวชี้วัดที่สำคัญมีดังนี้:

• คะแนนความแม่นยำ (Accuracy Score): อัตราการตอบถูกใน Benchmark เฉพาะของงานนั้นๆ (เช่น MATH-500 หรือ AIME สำหรับการใช้เหตุผลทางคณิตศาสตร์)
• ความคุ้มค่า (Cost Efficiency): อัตราส่วนของต้นทุน Token ที่จำเป็นเพื่อให้ได้คุณภาพในระดับเดียวกัน
• ความหน่วง (Latency - P50/P95): ประเมินโดยดูจากส่วนกระจายของข้อมูลที่รวมค่าผิดปกติ (Outliers) ไม่ใช่แค่ค่ามัธยฐานเท่านั้น
• อัตราการสำรอง (Fallback Rate): สัดส่วนที่ Router ไม่สามารถส่งงานไปยังโมเดลที่ตั้งใจไว้ได้

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

「การเพิ่ม Routing layer เข้าไปกลับทำให้การตอบสนองช้าลง」เป็นเสียงสะท้อนที่มักได้ยินบ่อยครั้งในหน้างาน หากไม่มีการกำหนดการออกแบบโครงสร้างพื้นฐานและค่าความหน่วงที่ยอมรับได้ (Latency tolerance) ไว้ล่วงหน้า ก็มีความเสี่ยงที่ตัว Routing เองจะกลายเป็นคอขวด (Bottleneck) ได้

สิ่งแรกที่ต้องตรวจสอบคือ ขีดจำกัดของค่าความหน่วงที่ยอมรับได้ ซึ่งผู้ใช้งานปลายทางจะสัมผัสได้ ในการสนทนาแบบเรียลไทม์อย่างแชทบอท ค่ามาตรฐานจะอยู่ที่ภายในไม่กี่วินาที ในขณะที่การประมวลผลแบบแบตช์ (Batch processing) หรือการสร้างรายงานแบบอะซิงโครนัส (Asynchronous report generation) อาจยอมรับความล่าช้าได้ถึงหลายสิบวินาที ซึ่งค่าที่ยอมรับได้นี้จะส่งผลอย่างมากต่อความซับซ้อนของตรรกะการทำ Routing และขอบเขตของการเลือกโมเดล

ถัดมาคือการประเมินต้นทุนการประมวลผลของตัว Router เอง ในเอกสารของ Microsoft Azure Foundry ได้ระบุค่าความหน่วงตัวอย่างเมื่อมีการจัดสรรงานไปยังโมเดลต่างๆ ผ่าน model-router ไว้ว่า สำหรับโมเดลขนาดเล็กจะอยู่ที่ประมาณ 0.59 วินาที และสำหรับโมเดลขนาดใหญ่จะอยู่ที่ประมาณ 1.14 วินาที ดังนั้น โปรดออกแบบโดยตั้งอยู่บนสมมติฐานที่ว่า การเพิ่มกระบวนการของ Router จะทำให้ค่าความหน่วงแบบ End-to-end ยาวนานกว่าเวลาในการประมวลผล (Inference time) ของตัวโมเดลเพียงอย่างเดียว

อุปสรรคแรกในการออกแบบ Routing logic คือคำถามที่ว่า "ควรเริ่มจากตรงไหน" หากพยายามนำ Classification model มาใช้ทันที ความซับซ้อนของตัว Logic เองอาจทำให้ผลประโยชน์จากการลดต้นทุนหมดไป การเริ่มต้นด้วย Rule-based จึงเป็นแนวทางที่สมเหตุสมผลกว่า ซึ่งเพียงแค่การคัดแยกตามเงื่อนไขง่ายๆ เช่น จำนวน Token หรือการมีอยู่ของ Keyword เฉพาะ ก็สามารถช่วยลดต้นทุนได้อย่างมหาศาล

เมื่อวางรากฐานจนมั่นคงแล้ว ขั้นตอนมาตรฐานคือการค่อยๆ เปลี่ยนผ่านไปสู่ Dynamic routing ด้วย Classification model อย่างไรก็ตาม การใช้ Classification model จะทำให้เกิดความเสี่ยงใหม่คือ "ความผิดพลาดในการจำแนกประเภท" (Classification failure) ด้วยเหตุนี้ การออกแบบ Fallback จึงเป็นสิ่งที่ขาดไม่ได้ หากไม่มีการกำหนดเงื่อนไขการยกระดับ (Escalation) ไปยังโมเดลที่มีความแม่นยำสูงไว้อย่างชัดเจน ก็อาจเกิดสถานการณ์ที่โมเดลราคาถูกยังคงตอบสนองในสถานการณ์ที่ต้องการความแม่นยำสูง

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

การทำ Rule-based routing มักจะทำให้เราเผลอเตรียมโมเดลการจำแนกประเภทที่ซับซ้อนตั้งแต่เริ่มต้น แต่ในความเป็นจริง การเริ่มจากเงื่อนไขแบบ Branching ง่ายๆ จะช่วยให้ดูแลรักษาได้ง่ายกว่า และเห็นผลลัพธ์ในการลดต้นทุนการดำเนินงานในช่วงแรกได้รวดเร็วกว่า

โดยทั่วไปแล้ว การนำไปใช้งานจะดำเนินการตามลำดับดังนี้:

1. การสกัดคุณลักษณะของคำถาม (Query attribute extraction): สกัดคุณลักษณะต่างๆ ออกมา เช่น ค่าประมาณของจำนวน Token, การมีอยู่ของคำสำคัญ (เช่น "สร้างโค้ด", "สรุปความ", "แปลภาษา" ฯลฯ) และกลุ่มผู้ใช้งานที่เป็นต้นทางของคำขอ
2. การกำหนดกฎ (Rule definition): จับคู่คุณลักษณะกับโมเดลปลายทาง เช่น "หากค่าประมาณ Token ไม่เกิน 500 และอยู่ในหมวดหมู่ FAQ ให้ใช้โมเดลขนาดเล็ก", "งานสร้างโค้ดให้ใช้โมเดลขนาดกลาง"
3. การตั้งค่าลำดับความสำคัญ (Priority setting): ระบุลำดับความสำคัญให้ชัดเจนในกรณีที่กฎหลายข้อขัดแย้งกัน ตัวอย่างเช่น หากมีการตั้งค่าสถานะจำกัดต้นทุนไว้ ให้ถือว่ามีความสำคัญเหนือกว่ากฎข้ออื่นและส่งต่อไปยังโมเดลขนาดเล็กทันที
4. การกำหนดการสำรอง (Fallback definition): ต้องกำหนดโมเดลเริ่มต้นไว้เสมอสำหรับกรณีที่ได้รับคำถามที่ไม่ตรงกับกฎข้อใดเลย การปล่อยให้มีกรณีที่ไม่ได้กำหนดไว้จะกลายเป็นบ่อเกิดของข้อผิดพลาดหรือคุณภาพที่ลดลง

การแยกกฎออกมาไว้ในไฟล์การตั้งค่า (YAML หรือ JSON) แทนที่จะเขียนไว้ในโค้ดโดยตรง จะช่วยให้สามารถอัปเดตเงื่อนไขต่างๆ ได้โดยไม่ต้องทำการ Deploy ใหม่ จากกรณีศึกษาของ AWS มีรายงานว่าเมื่อเปรียบเทียบกับ Semantic routing แล้ว Rule-based มีต้นทุนในการนำไปใช้งานที่ต่ำกว่า และสามารถช่วยลดค่าใช้จ่ายรายเดือนในงานลักษณะเดียวกันได้

เพื่อรองรับเควรีที่หลากหลายซึ่งกฎเกณฑ์ (Rule-based) ไม่สามารถจัดการได้ทั้งหมด การใช้การกำหนดเส้นทางแบบไดนามิก (Dynamic Routing) โดยใช้โมเดลการจำแนกประเภท (Classification Model) ถือเป็นวิธีที่มีประสิทธิภาพ โดยระบบจะจำแนกข้อความที่ป้อนเข้ามาตามแกนต่างๆ เช่น "ความซับซ้อน" "โดเมน" และ "เจตนา" แบบเรียลไทม์ และส่งต่อไปยังโมเดลที่เหมาะสมที่สุดตามผลลัพธ์นั้น

โครงสร้างพื้นฐานของการกำหนดเส้นทางแบบไดนามิก

• การเลือกตัวจำแนกประเภท (Classifier): นิยมใช้โมเดลขนาดเล็กตระกูล BERT หรือตัววัดความคล้ายคลึงแบบ Embedding-based งานวิจัย HyDRA แสดงให้เห็นว่าค่ามัธยฐานของความหน่วง (Latency) ในการอนุมานบน CPU สำหรับตัวทำนายนั้นถูกควบคุมไว้ที่ 86 ms ซึ่งพิสูจน์ให้เห็นว่าค่า Overhead ของตัว Router เองนั้นอยู่ในระดับที่ใช้งานได้จริง
• การออกแบบฟีเจอร์ (Feature Engineering): การรวมจำนวนโทเค็น โครงสร้างของคำถาม (เช่น รายการแบบ Bullet point หรือการมีโค้ด) และคะแนนคุณภาพการตอบกลับในอดีตเข้าเป็นฟีเจอร์ จะช่วยเพิ่มความแม่นยำในการจำแนกประเภทได้
• ป้ายกำกับผลลัพธ์ (Output Labels): การจำกัดไว้ที่ประมาณ 3 คลาส ได้แก่ "โมเดลขนาดเล็ก" "โมเดลประสิทธิภาพสูง" และ "โมเดลเฉพาะทาง" จะช่วยให้การดำเนินงานมีความเรียบง่าย

เกณฑ์การตัดสินใจตามสถานการณ์

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

ข้อควรระวังในการนำไปใช้งาน

ต้นทุนการอนุมานของตัวโมเดลการจำแนกประเภทเองนั้นเป็นสิ่งที่ละเลยไม่ได้ การใช้ประโยชน์จาก Embedding Cache เพื่อข้ามการจำแนกประเภทซ้ำสำหรับเควรีเดิมหรือเควรีที่คล้ายคลึงกัน จะช่วยปรับปรุงปริมาณงาน (Throughput) ได้อย่างมาก

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

ในการตั้งค่าเกณฑ์ต้นทุน โดยทั่วไปจะบริหารจัดการเป็น 2 ระดับ ได้แก่ ขีดจำกัดโทเค็นที่อนุญาตต่อ 1 คำขอ (Per-request token limit) และ เพดานงบประมาณรายเดือน (Monthly budget cap) ตัวอย่างเช่น ในกรณีของ AWS การสอบถามประเภท History และประเภท Math แม้จะมีปริมาณโทเค็นเท่ากัน แต่ต้นทุนในการสร้างคำตอบกลับแตกต่างกันมาก การกำหนดเกณฑ์แยกตามประเภทงานจะช่วยป้องกันการจัดสรรโมเดลที่เกินความจำเป็นได้

ขั้นตอนพื้นฐานในการออกแบบเกณฑ์มีดังนี้:

• ขั้นตอนที่ 1: กำหนด "ต้นทุนสูงสุดที่ยอมรับได้" และ "คะแนนคุณภาพขั้นต่ำที่จำเป็น" สำหรับงานแต่ละประเภท
• ขั้นตอนที่ 2: วัดสัดส่วนที่สามารถประมวลผลด้วยโมเดลขนาดเล็ก (Lightweight model) เพื่อประเมินขีดจำกัดในการลดต้นทุน
• ขั้นตอนที่ 3: ตั้งค่ากฎการสำรอง (Fallback rule) เพื่อยกระดับไปใช้โมเดลที่สูงกว่าโดยอัตโนมัติเมื่อเกินเกณฑ์ที่กำหนด

เงื่อนไขการสำรองส่วนใหญ่จะใช้การผสมผสานตัวกระตุ้น (Trigger) 2 ประเภท:

• ตัวกระตุ้นด้านคุณภาพ (Quality trigger): ส่งคำขอไปยังโมเดลที่สูงกว่าอีกครั้งเมื่อคะแนนความเชื่อมั่นของผลลัพธ์จากโมเดลขนาดเล็กต่ำกว่าค่าที่กำหนด
• ตัวกระตุ้นด้านต้นทุน (Cost trigger): ปรับอัตราการกำหนดเส้นทาง (Routing ratio) เมื่อการใช้งานรายเดือนถึง 80% ของเพดานที่ตั้งไว้ โดยเพิ่มการแบ่งสัดส่วนไปยังโมเดลขนาดเล็กให้มากขึ้น

ขอแนะนำให้จัดเตรียมปลายทางสำหรับการสำรอง (Fallback destination) ไว้ไม่ต่ำกว่า 2 โมเดลเสมอ

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

การตัดสินใจในสามประเด็นนี้ ได้แก่ การผสมผสานระหว่างโมเดลน้ำหนักเบาและโมเดลประสิทธิภาพสูง, การเลือกระหว่างโครงสร้างแบบ Cascade หรือแบบ Parallel และการกำหนดจุดที่จะนำโมเดลที่ผ่านการ Fine-tuning มาใช้งาน คือหัวใจสำคัญของการออกแบบที่จะกำหนดความสมดุลระหว่างต้นทุนและคุณภาพ

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

แนวคิดพื้นฐานในการแบ่งบทบาทหน้าที่ มีดังนี้:

• งานที่เหมาะกับโมเดลขนาดเล็ก: การตอบคำถาม FAQ, การสร้างข้อความตามรูปแบบที่กำหนด, การวิเคราะห์อารมณ์ (Sentiment analysis), การจำแนกเจตนา (Intent classification) และงานอื่นๆ ที่มีโครงสร้างเรียบง่ายและมีรูปแบบคำตอบที่จำกัด
• งานที่เหมาะกับโมเดลประสิทธิภาพสูง: การใช้เหตุผลหลายขั้นตอน (Multi-step reasoning), คำถามที่ต้องใช้ความรู้เฉพาะทาง เช่น กฎหมาย การแพทย์ หรือการเงิน, การเขียนโค้ด และการสรุปความยาว ซึ่งเป็นงานที่ยอมรับความผิดพลาดได้น้อย

กรณีศึกษาจาก AWS แสดงให้เห็นว่า แม้จะเป็นปริมาณโทเค็นที่เท่ากัน แต่โจทย์ประเภท History (ต้นทุนการสร้างคำตอบรายเดือนประมาณ $619) และโจทย์ประเภท Math (ต้นทุนประมาณ $7,425) กลับมีส่วนต่างของค่าใช้จ่ายสูงมาก ซึ่งชี้ให้เห็นว่าการประมวลผลงานที่มีระดับความยากต่างกันด้วยโมเดลเดียวกัน มักก่อให้เกิดต้นทุนที่เกินความจำเป็น

จุดสำคัญในการนำไปใช้งานมี 3 ประการ ดังนี้:

1. การให้คะแนนความยาก (Difficulty Scoring): ประเมินความซับซ้อนของคำถามล่วงหน้าโดยใช้จำนวนโทเค็น คำศัพท์ และความสัมพันธ์ของประโยค หากคะแนนต่ำกว่าเกณฑ์ที่กำหนด ให้ส่งต่อไปยังโมเดลขนาดเล็ก
2. ตัวกรองความเชื่อมั่น (Confidence Filter): หากคะแนนความเชื่อมั่น (Confidence score) ที่มาพร้อมกับผลลัพธ์ของโมเดลขนาดเล็กอยู่ในระดับต่ำ ให้ส่งต่อ (Escalate) ไปยังโมเดลประสิทธิภาพสูงโดยอัตโนมัติ
3. กฎเฉพาะโดเมน (Domain-specific Rules): ติดป้ายกำกับหมวดหมู่คำถามว่าเป็น "ข้อมูลทั่วไป" หรือ "การตัดสินใจเชิงผู้เชี่ยวชาญ" และกำหนดโมเดลให้ตายตัวตามหมวดหมู่นั้นๆ

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

รูปแบบ Cascade และรูปแบบ Parallel ต่างก็เป็นวิธีการรวมโมเดลหลายตัวเข้าด้วยกัน แต่มีสถานการณ์ที่เหมาะสมแตกต่างกัน หากต้องการให้ความสำคัญกับการลดต้นทุนมากกว่าความหน่วง (Latency) รูปแบบ Cascade จะเหมาะสมกว่า แต่หากต้องการให้ความสำคัญกับความแม่นยำและความน่าเชื่อถือเป็นอันดับแรก รูปแบบ Parallel จะเหมาะสมกว่า

รูปแบบ Cascade คือโครงสร้างที่เริ่มประมวลผลด้วยโมเดลขนาดเล็กก่อน และจะส่งต่อไปยังโมเดลระดับสูงกว่าก็ต่อเมื่อคะแนนความน่าเชื่อถือ (Confidence Score) ต่ำกว่าเกณฑ์ที่กำหนดเท่านั้น

• ขั้นตอนการประมวลผล: โมเดลขนาดเล็ก → การตัดสินคะแนนความน่าเชื่อถือ → โมเดลประสิทธิภาพสูง (แบบมีเงื่อนไข)
• Amazon Bedrock Intelligent Prompt Routing ของ AWS มีแนวคิดที่ใกล้เคียงกับวิธีนี้ ซึ่งมีการรายงานว่าสามารถลดต้นทุนได้สูงสุดถึง 30%
• การตอบคำถาม FAQ แบบง่ายหรือการตอบกลับตามรูปแบบมาตรฐานจะเสร็จสิ้นได้ด้วยโมเดลขนาดเล็ก และจะยกระดับไปยังโมเดลระดับสูงก็ต่อเมื่อจำเป็นต้องมีการใช้เหตุผลที่ซับซ้อนเท่านั้น

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

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

เกณฑ์ในการตัดสินใจคือ หากเน้นความคุ้มค่าของต้นทุนให้เลือกรูปแบบ Cascade แต่หากให้ความสำคัญกับการรับรองความน่าเชื่อถือของคำตอบเป็นอันดับแรกให้เลือกรูปแบบ Parallel

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

หลายหน้างานมักเกิดความลังเลว่า "ในเมื่อเรามีโมเดลที่ผ่านการ Fine-tuning มาแล้ว เราควรปฏิบัติกับมันเหมือนกับโมเดลทั่วไปหรือไม่"

โมเดลที่ผ่านการ Fine-tuning สามารถแสดงความแม่นยำที่เทียบเท่าหรือเหนือกว่าโมเดลประสิทธิภาพสูงทั่วไปในงานเฉพาะทาง (Specific domain) ได้ด้วยต้นทุนที่ต่ำกว่า ในการออกแบบ Routing จึงเป็นเรื่องสำคัญที่จะต้องกำหนดตำแหน่งของโมเดลนี้ให้ชัดเจนในฐานะ "เส้นทางเฉพาะทาง (Domain-specific route)"

ขั้นตอนพื้นฐานในการนำไปใช้งาน มีดังนี้:

• การระบุขอบเขตของโดเมนให้ชัดเจน: กำหนดงานที่โมเดลนั้นมีความเชี่ยวชาญ (เช่น การสรุปเอกสารทางกฎหมาย, การตอบคำถาม FAQ ของผลิตภัณฑ์เฉพาะ) ให้เป็นป้ายกำกับประเภท (Classification label)
• การตั้งค่าคะแนนความเชื่อมั่น (Confidence score): ทำการ Routing เฉพาะในกรณีที่ความน่าจะเป็นที่ Query ขาเข้าจะตรงกับโดเมนของโมเดลที่ผ่านการ Fine-tuning มานั้นเกินเกณฑ์ที่กำหนดไว้ (เช่น 0.8 ขึ้นไป)
• การเตรียมจุดสำรอง (Fallback): หากคะแนนต่ำกว่าเกณฑ์ที่กำหนด หรือโมเดลส่งสัญญาณว่า "ไม่ทราบคำตอบ" ให้โอนย้ายไปยังโมเดลทั่วไปโดยอัตโนมัติ

ข้อควรระวัง คือ โมเดลที่ผ่านการ Fine-tuning มักมีแนวโน้มที่จะตอบคำถามผิดด้วยความมั่นใจเกินจริงเมื่อเจอ Query ที่อยู่นอกเหนือโดเมน ดังนั้น กลไกที่ฝั่ง Router ในการคัดกรอง Query ที่อยู่นอกโดเมนออกอย่างแม่นยำจึงเป็นสิ่งที่ขาดไม่ได้

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

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

เราจะอธิบายขั้นตอนการวัดผลและการปรับปรุงที่ควรดำเนินการในขั้นตอนการปฏิบัติงาน ตั้งแต่การทำให้ปริมาณการใช้ Token มองเห็นภาพได้ชัดเจน ไปจนถึงการตรวจสอบความแม่นยำของ Routing ผ่านการทำ A/B Testing

หากละเลยการทำ Monitoring กว่าจะรู้ตัวว่าค่าใช้จ่ายเกินงบก็มักจะสายเกินไป แม้ในช่วงแรกเรามักจะคิดว่า "ให้ระบบ Routing ทำงานได้ก่อนแล้วค่อยมาจัดการเรื่อง Log ทีหลัง" แต่ในความเป็นจริง การสร้างระบบวัดผล (Measurement Infrastructure) ไปพร้อมกับการเริ่มใช้งาน Routing จะช่วยให้ตรวจพบปัญหาได้เร็วขึ้นและช่วยลดรอบการปรับปรุง (Improvement Cycle) ให้สั้นลงได้

ตัวชี้วัดหลักที่ควรติดตามมี 4 ประการ ดังนี้:

• ปริมาณการใช้ Token แยกตามโมเดล (บันทึกแยก Input และ Output)
• ค่าใช้จ่าย API แยกตามเส้นทาง (Route) (ราคาต่อหน่วยของ Request × จำนวนครั้ง)
• Latency ในการตัดสินใจของ Routing (แยกเวลาประมวลผลของ Router ออกจากการเรียกใช้โมเดล)
• อัตราการเกิด Fallback (เพื่อตรวจสอบการไหลเข้าของข้อมูลไปยังโมเดลที่มีต้นทุนสูงโดยไม่ได้ตั้งใจ)

กรณีศึกษาของ AWS แสดงให้เห็นว่า แม้จะเป็นปริมาณ Token ที่เท่ากัน แต่ต้นทุนในการสร้างคำตอบสำหรับโจทย์ประเภท History และ Math นั้นมีความแตกต่างกันมาก หากไม่รวบรวมต้นทุนแยกตามประเภทงาน (Task Type) เราจะไม่สามารถมองเห็นได้เลยว่าเส้นทางใดกำลังกดดันงบประมาณอยู่

จุดสำคัญในการนำไปใช้งานมี 3 ประการ:

1. รูปแบบ Log ที่มีโครงสร้างเป็นมาตรฐานเดียวกัน: รวม Request ID, ชื่อโมเดล, จำนวน Token ขาเข้า/ขาออก, ต้นทุน และ Latency ไว้ในเรคคอร์ดเดียว
2. การออกแบบความละเอียดในการสรุปผล: เตรียมระบบให้สามารถสรุปผลแยกตามช่วงเวลา, ประเภทงาน และกลุ่มผู้ใช้งานได้
3. การตั้งค่าเกณฑ์แจ้งเตือน (Alert Threshold): จัดทำกลไกแจ้งเตือนเมื่ออัตราการไหลเข้าของข้อมูลไปยังโมเดลที่มีต้นทุนสูงเกินกว่าสัดส่วนที่กำหนด

ขอแนะนำให้นำข้อมูลที่รวบรวมได้ไปแสดงผลบน Dashboard และนำเข้าสู่รอบการทบทวนกฎการ Routing เป็นรายสัปดาห์

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

ตัวชี้วัดที่ควรวัดมี 3 ประการ ดังนี้:

• Routing Accuracy (ความแม่นยำในการทำ Routing): สัดส่วนที่ถูกส่งไปยังโมเดลที่ตั้งใจไว้ โดยวัดจากชุดข้อมูลทดสอบ (Test Set) ที่ติดป้ายกำกับไว้ล่วงหน้า
• Quality Score (คะแนนคุณภาพ): ค่าคะแนนผลลัพธ์ของแต่ละโมเดลที่ได้จากการประเมินโดยมนุษย์หรือ LLM-as-a-Judge
• Quality per Cost (อัตราส่วนคุณภาพต่อต้นทุน): การเปรียบเทียบด้วยความคุ้มค่าแทนที่จะดูแค่ความแม่นยำเพียงอย่างเดียว

ในขั้นตอนการประเมิน ให้เตรียมชุดคำถามที่มีป้ายกำกับ (Labeled Query Set) แล้วนำผลการจำแนกของ Router มาเปรียบเทียบกับป้ายกำกับที่ถูกต้อง หากพบหมวดหมู่ที่มีความแม่นยำต่ำ ให้แก้ไขโดยการเพิ่มข้อมูลการเรียนรู้ให้กับโมเดลจำแนกประเภท หรือปรับค่า Threshold ของกฎที่ตั้งไว้

การออกแบบ A/B Test จะมีแนวทางที่เปลี่ยนไปตามวัตถุประสงค์ หากต้องการตรวจสอบประสิทธิภาพของตรรกะการทำ Routing ทั้งหมด ให้แบ่ง Traffic ออกเป็น "กลุ่มที่มีการทำ Routing" และ "กลุ่มที่ใช้โมเดลเดียวคงที่" แล้วเปรียบเทียบทั้งในด้านต้นทุนและคุณภาพ ในทางกลับกัน หากต้องการดูผลลัพธ์การปรับปรุงเฉพาะกฎบางอย่าง การทำ Split Test โดยสลับเฉพาะหมวดหมู่คำถามที่เป็นเป้าหมายจะเหมาะสมกว่า

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

ข้อผิดพลาดที่เป็นตัวอย่างสำคัญมี 2 ประการ ได้แก่ การเพิ่มขึ้นของความหน่วง (Latency) ที่ตัว Router เอง และความเสื่อมถอยของคุณภาพอันเนื่องมาจากความแม่นยำในการจำแนกประเภท (Classification Accuracy) ที่ต่ำ โดยเราจะอธิบายถึงสาเหตุและแนวทางแก้ไขของแต่ละประเด็นดังนี้

เราอาจเปรียบเทียบเราเตอร์ (Router) ได้กับ "สัญญาณไฟจราจร" แต่หากสัญญาณไฟเกิดติดขัด ถนนทั้งสายก็จะกลายเป็นอัมพาต เช่นเดียวกับการที่การประมวลผลของเร้าเตอร์ล่าช้า ซึ่งจะส่งผลกระทบโดยตรงต่อค่าความหน่วง (Latency) ของทั้งระบบ

สาเหตุทั่วไปที่ทำให้เกิดคอขวด (Bottleneck) อย่างแรกคือ การนำการตัดสินใจด้านการกำหนดเส้นทาง (Routing decision) ไปทำเป็นกระบวนการแบบซิงโครนัส (Synchronous processing) ซึ่งทำให้การเรียกใช้โมเดลในลำดับถัดไปไม่สามารถเริ่มต้นได้จนกว่าการตัดสินใจจะเสร็จสิ้น ส่งผลให้เวลาที่ต้องรอคอยนั้นกระทบต่อประสบการณ์ของผู้ใช้งานโดยตรง ต่อมาคือการเลือกใช้โครงสร้างที่เรียกใช้ LLM ขนาดใหญ่ในการตัดสินใจ ซึ่งอาจทำให้ค่าความหน่วงของตัวเราเตอร์เองสูงถึงหลายวินาที กลายเป็นปรากฏการณ์ย้อนแย้งที่ตัวเราเตอร์ซึ่งควรจะถูกนำมาใช้เพื่อเพิ่มความรวดเร็ว กลับกลายเป็นส่วนที่ประมวลผลหนักที่สุดเสียเอง นอกจากนี้ ในโครงสร้างที่ไม่มีการทำแคช (Cache) ซึ่งต้องรันกระบวนการจำแนกประเภทใหม่ทุกครั้งสำหรับรูปแบบคำถามเดิม ก็จะเกิดค่าโอเวอร์เฮด (Overhead) ที่ไม่จำเป็นสะสมขึ้นอย่างเงียบๆ

งานวิจัยของ HyDRA ได้แสดงให้เห็นว่า การควบคุมค่าความหน่วงในการอนุมาน (Inference latency) ของตัวทำนาย (Predictor) บน CPU ในสภาพแวดล้อมจริงให้มีค่ามัธยฐานอยู่ที่ 86 ms นั้น สามารถช่วยให้ความล่าช้าที่เกิดจากเราเตอร์อยู่ในระดับที่ใช้งานได้จริง ตัวเลขนี้แสดงให้เห็นอย่างชัดเจนว่าแนวคิดการออกแบบที่มุ่งเน้นให้ตัวเราเตอร์มีน้ำหนักเบานั้นมีความสำคัญเพียงใด

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

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

ปัญหาหลักที่เกิดจากความแม่นยำในการจำแนกประเภทต่ำ มีดังนี้:

• การส่งงานไปยังโมเดลขนาดเล็กมากเกินไป (Over-routing to lightweight models): หากงานที่ต้องใช้การอนุมาน (Inference) ที่ซับซ้อนถูกส่งไปยังโมเดลขนาดเล็กโดยผิดพลาด จะทำให้ความถูกต้องของคำตอบลดลง ส่งผลให้ความพึงพอใจของผู้ใช้ลดลงและมีการยกระดับปัญหา (Escalation) เพิ่มมากขึ้น
• การส่งงานไปยังโมเดลประสิทธิภาพสูงโดยไม่จำเป็น: หากงานง่ายๆ ถูกส่งไปยังโมเดลประสิทธิภาพสูง จะทำให้ประสิทธิภาพในการลดต้นทุนลดลง และทำให้การนำระบบ Routing มาใช้สูญเสียความหมายไป
• การเรียกใช้ Fallback บ่อยครั้ง: หากมีการจำแนกผิดพลาดบ่อย เงื่อนไขการทำ Fallback จะถูกกระตุ้นอยู่ตลอดเวลา ส่งผลให้ Latency เพิ่มสูงขึ้น

เพื่อป้องกันการเสื่อมถอยของคุณภาพ ควรพิจารณามาตรการดังต่อไปนี้:

• การขยายชุดข้อมูลประเมินผล (Evaluation set) อย่างต่อเนื่อง: จัดตั้งวงจรการดำเนินงานที่รวบรวมตัวอย่างการจำแนกผิดพลาดจาก Log การใช้งานจริง เพื่อนำไปรวมเป็นข้อมูลสำหรับการเทรนโมเดลการจำแนกประเภทใหม่
• การใช้คะแนนความเชื่อมั่น (Confidence score): กำหนดคะแนนความเชื่อมั่นให้กับผลการจำแนก และสร้างกลไกที่ส่งคำถามที่มีคะแนนต่ำไปยังโมเดลประสิทธิภาพสูงโดยอัตโนมัติ
• การกำหนดขอบเขตของงานให้ชัดเจน: หากนิยามของหมวดหมู่ เช่น "การอนุมานที่ซับซ้อน" หรือ "Q&A แบบง่าย" มีความคลุมเครือ จะทำให้การเทรนตัวจำแนกประเภท (Classifier) ทำได้ยาก ดังนั้นควรจัดทำเอกสารเกณฑ์การติดป้ายกำกับ (Labeling criteria) และแบ่งปันให้ผู้เกี่ยวข้องรับทราบ

ในช่วงแรก เรามักจะมุ่งเน้นไปที่การปรับปรุงความแม่นยำของโมเดลการจำแนกประเภทเพียงอย่างเดียว แต่ในความเป็นจริง การปรับปรุงคุณภาพของการออกแบบป้ายกำกับ (Label design) ให้เรียบร้อยก่อน จะช่วยยกระดับความแม่นยำในการจำแนกประเภทได้ดีกว่า

จุดเริ่มต้นของการออกแบบที่ควรให้ความสำคัญคือ การจำแนกประเภทของ Query ตามระดับความยาก (Difficulty), โดเมน (Domain) และข้อกำหนดด้าน Latency หากสร้าง Router โดยที่แกนการจำแนกเหล่านี้ยังไม่ชัดเจน จะไม่สามารถบรรลุทั้งความแม่นยำและประสิทธิภาพในการลดต้นทุนได้

สำหรับการเลือกตรรกะการทำ Routing แนวทางที่สมเหตุสมผลคือการเริ่มจาก Rule-based แบบง่าย แล้วค่อยเปลี่ยนไปใช้โมเดลการจำแนกประเภท (Classification Model) เมื่อความหลากหลายของ Query เพิ่มมากขึ้น กรณีศึกษาของ HyDRA แสดงให้เห็นว่าสามารถลดต้นทุนได้ถึง 54.1% ภายใต้เงื่อนไข iso-quality และ TRIM สามารถลดการใช้ Token ของโมเดลที่มีต้นทุนสูงได้ถึง 80% ใน MATH-500 ซึ่งพิสูจน์ให้เห็นว่าคุณภาพของการออกแบบส่งผลโดยตรงต่อตัวเลขผลลัพธ์

ในส่วนของโครงสร้างสถาปัตยกรรม การแบ่งบทบาทหน้าที่ระหว่างโมเดลขนาดเล็ก (Lightweight Model) และโมเดลประสิทธิภาพสูง (High-performance Model) ให้ชัดเจน ควบคู่ไปกับโครงสร้างแบบ Cascade ที่มีการยกระดับ (Escalation) เป็นขั้นเป็นตอน จะนำไปสู่การดำเนินงานที่เสถียร กรณีศึกษาของ AWS รายงานว่า Amazon Bedrock Intelligent Prompt Routing สามารถลดต้นทุนได้สูงสุดถึง 30% ดังนั้นการพิจารณาใช้ Managed Service จึงเป็นทางเลือกที่คุ้มค่า

เพื่อให้การออกแบบเหล่านี้ใช้งานได้ในระยะยาว จำเป็นต้องมีระบบปฏิบัติการที่คอยติดตาม (Monitoring) 3 แกนหลัก ได้แก่ ปริมาณการใช้ Token, ความแม่นยำในการ Routing และคุณภาพที่ส่งถึงผู้ใช้งานปลายทาง รวมถึงการทบทวนเกณฑ์ (Threshold) อย่างสม่ำเสมอผ่านการทำ A/B Testing การจัดสรรงานแบบไดนามิกตามลักษณะของ Task ไม่ใช่สิ่งที่ทำครั้งเดียวจบ แต่เป็นสิ่งที่ต้องพัฒนาไปพร้อมกับการสั่งสมข้อมูลจากการใช้งานจริง