Dynamic Prompt Routing คืออะไร? การออกแบบเพื่อเลือกใช้ LLM ที่เหมาะสมที่สุดตาม Query

Dynamic Prompt Routing คือรูปแบบการออกแบบ (Design Pattern) ที่จะทำการคัดเลือกและส่งต่อ LLM หรือ Prompt ที่เหมาะสมที่สุดโดยอัตโนมัติในขณะประมวลผล (Runtime) โดยพิจารณาจากเนื้อหาและคุณลักษณะของ Query ที่ป้อนเข้ามา หากมอบหมายงานทั้งหมดให้กับโมเดลประสิทธิภาพสูงเพียงตัวเดียว จะทำให้ต้องเสียค่าใช้จ่ายและเผชิญกับ Latency ที่สูงเกินความจำเป็นสำหรับคำถามง่ายๆ ในทางกลับกัน หากใช้เพียงโมเดลขนาดเล็ก ก็อาจไม่สามารถสร้างผลลัพธ์ที่มีคุณภาพในงานที่ซับซ้อนได้

การเพิ่ม Routing Layer เข้าไปจะช่วยให้สามารถจัดสรรงานได้ว่า "Query ง่ายให้ใช้โมเดลที่ราคาถูกและรวดเร็ว ส่วน Query ยากให้ใช้โมเดลประสิทธิภาพสูง" ซึ่งช่วยให้สามารถปรับสมดุล (Trade-off) ระหว่างต้นทุน ความแม่นยำ และความเร็วได้อย่างเหมาะสมแบบไดนามิก บทความนี้จัดทำขึ้นสำหรับนักพัฒนาและสถาปนิกที่ต้องการสร้างสมดุลระหว่างต้นทุนและคุณภาพของแอปพลิเคชัน LLM โดยจะอธิบายอย่างเป็นระบบตั้งแต่ความแตกต่างของกลยุทธ์การจัดสรรหลัก มุมมองในการเปรียบเทียบ ขั้นตอนการนำไปใช้งาน ไปจนถึงข้อผิดพลาดในการออกแบบที่มักพบได้บ่อย

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

การเลือกโมเดลแบบคงที่ (Static Model Selection) คือวิธีการที่กำหนดไว้ในแอปพลิเคชันว่า "เอนด์พอยต์นี้จะใช้โมเดลนี้เสมอ" แม้การนำไปใช้งานจะทำได้ง่าย แต่เนื่องจากทุกคำถาม (Query) ต้องผ่านโมเดลเดียวกันทั้งหมด จึงทำให้คำถามง่ายๆ ต้องเสียค่าใช้จ่ายสูงจากโมเดลราคาแพง ในขณะที่คำถามเฉพาะทางอาจได้ผลลัพธ์ที่ไม่เพียงพอ

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

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

การทำ Routing มีเป้าหมายเพื่อเพิ่มประสิทธิภาพให้กับตัวชี้วัด 3 ประการที่มักจะขัดแย้งกันให้ได้พร้อมกัน ดังนี้:

1. ต้นทุน (Cost): โมเดลประสิทธิภาพสูงมีราคาต่อโทเค็นที่สูง หากส่ง "งานง่าย" ซึ่งเป็นส่วนใหญ่ของเควรีไปให้โมเดลราคาประหยัด จะช่วยลดต้นทุนการประมวลผลโดยรวมลงได้อย่างมาก
2. ความแม่นยำ (Accuracy): หากประมวลผลทุกอย่างด้วยโมเดลขนาดเล็ก งานที่ยากอาจเกิดข้อผิดพลาดได้ การส่งเฉพาะเควรีที่ยากไปยังโมเดลประสิทธิภาพสูง จะช่วยรักษาคุณภาพเฉลี่ยไว้ได้โดยไม่ต้องเสียค่าใช้จ่ายสูงโดยไม่จำเป็น
3. ความเร็ว (Speed): โมเดลขนาดเล็กและเบามีการตอบสนองที่รวดเร็ว หากส่งเควรีที่ต้องการคำตอบทันทีไปยังโมเดลที่รวดเร็ว จะช่วยปรับปรุงค่าความหน่วง (Latency) ที่ผู้ใช้งานสัมผัสได้

ประเด็นสำคัญคือ ตัวชี้วัดทั้ง 3 ประการนี้มีความสัมพันธ์แบบแลกเปลี่ยนกัน (Trade-off) ซึ่งโมเดลเดี่ยวไม่สามารถตอบโจทย์ได้ครบทุกด้านพร้อมกัน การทำ Routing จึงเข้ามาช่วยปรับสมดุลของ Trade-off นี้ในภาพรวม โดยการ "เลือกจุดที่เหมาะสมที่สุดสำหรับแต่ละเควรี"

การทำ Routing ยังทำหน้าที่เป็นจุดเริ่มต้นของโครงสร้างแบบ Multi-agent อีกด้วย

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

กล่าวคือ Prompt Routing ไม่ได้เป็นเพียงมาตรการลดต้นทุนเท่านั้น แต่ยังเป็นรากฐานสำคัญในการรวบรวมและใช้งานโมเดลเฉพาะทางหลายตัว หากเริ่มต้นจากจุดเล็กๆ คุณสามารถเริ่มจาก "การแบ่งงานระหว่าง 2 โมเดล" และเมื่อพัฒนาขึ้น ก็สามารถขยายแนวคิดเดียวกันนี้ไปสู่ "การเป็น Dispatcher ให้กับเอเจนต์เฉพาะทางจำนวนมาก" ได้ ในทางกลับกัน หากการออกแบบชั้น Routing ทำอย่างไม่รอบคอบ ความแม่นยำและต้นทุนของระบบ Multi-agent ทั้งหมดก็จะติดอยู่ที่จุดนั้นเช่นกัน

เบื้องหลังความสนใจในเรื่อง Routing มาจากตัวเลือกของโมเดลที่เพิ่มขึ้นอย่างรวดเร็วและแรงกดดันด้านต้นทุน ในที่นี้จะขอสรุปเหตุผลว่าทำไมการออกแบบการจัดสรร (Routing design) จึงกลายเป็นประเด็นสำคัญในการปฏิบัติงานจริงในขณะนี้

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

"ทางเลือกที่มีมากมาย" และ "ส่วนต่างของราคา" เหล่านี้เองที่เป็นเงื่อนไขเบื้องต้นของการทำ Routing หากเป็นสมัยก่อนที่โมเดลมีให้เลือกจำกัด การจัดสรรงานคงไม่มีความหมายเท่าใดนัก แต่ในปัจจุบันที่มีโมเดลหลากหลายทั้งในด้านประสิทธิภาพและต้นทุน การเลือก "โมเดลที่ไม่เกินความจำเป็นและไม่ต่ำกว่ามาตรฐานสำหรับ Query นั้นๆ" จึงกลายเป็นช่องทางในการเพิ่มประสิทธิภาพ (Optimization)

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

หัวใจสำคัญของการลดต้นทุนคือการเลือกใช้ SLM (Small Language Models) และ LLM ให้เหมาะสมกับงาน

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

ดังนั้น การใช้โครงสร้างแบบคาสเคด (Cascade) โดยเริ่มจากการให้ SLM ประมวลผลก่อน และส่งต่อ (Escalate) ไปยัง LLM เฉพาะในกรณีที่ตัดสินว่าผลลัพธ์มีความน่าเชื่อถือต่ำหรือเป็นงานที่ยาก จึงเป็นวิธีที่มีประสิทธิภาพ การจัดการงานส่วนใหญ่ด้วยชั้นที่ราคาถูกและใช้ชั้นที่มีต้นทุนสูง "เฉพาะเมื่อจำเป็นจริงๆ เท่านั้น" จะช่วยลดต้นทุนได้โดยไม่ทำให้คุณภาพลดลงอย่างมีนัยสำคัญ หากรัน SLM บนเครื่องท้องถิ่น (Local) หรือที่ปลายทาง (Edge) ก็จะสามารถลดต้นทุน API ลงได้อีกด้วย

สำหรับการใช้งานในองค์กร ความสามารถในการสังเกตการณ์ (Observability) และการกำกับดูแล (Governance) จะกลายเป็นข้อกำหนดสำคัญในการออกแบบระบบ Routing นอกเหนือไปจากเรื่องของต้นทุนและความแม่นยำ

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

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

วิธีการติดตั้งใช้งาน Routing สามารถแบ่งออกได้เป็น 3 รูปแบบหลัก โดยความชาญฉลาดในการตัดสินใจและต้นทุนในการติดตั้งใช้งานมีความสัมพันธ์แบบแลกเปลี่ยนกัน (Trade-off) จึงควรเลือกวิธีที่เหมาะสมกับการใช้งาน

วิธีที่ง่ายที่สุดคือการใช้ Rule-based ซึ่งเป็นการกำหนดเส้นทางการทำงานตามเงื่อนไข เช่น การจับคู่คีย์เวิร์ด, ความยาวของอินพุต หรือประเภทของงานที่ระบุไว้อย่างชัดเจน (เช่น Flag หรือ Metadata)

ตัวอย่างเช่น การเขียนโค้ดเพื่อแยกประเภทว่า หาก Query มีคำว่า "โค้ด" หรือ "แปลภาษา" ให้ส่งไปยังโมเดลเฉพาะทาง หรือหากอินพุตมีความยาวเกินจำนวน Token ที่กำหนด ให้ส่งไปยังโมเดลที่รองรับข้อความยาว ข้อดีคือพฤติกรรมของระบบมีความแน่นอน อธิบายได้ง่าย และดีบั๊กได้สะดวก อีกทั้งยังมีต้นทุนในการตัดสินใจแทบจะเป็นศูนย์

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

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

Embedding-based เป็นวิธีการที่แปลง Query ให้เป็นเวกเตอร์ แล้วจัดกลุ่มตามความใกล้เคียงทางความหมายกับหมวดหมู่ที่เตรียมไว้ (เวกเตอร์ตัวแทน)

เนื่องจากตัดสินด้วยความหมายไม่ใช่การจับคู่คำสำคัญ (Keyword matching) ทั้ง "แก้บั๊กให้หน่อย" และ "โค้ดไม่ทำงาน" จึงถูกจัดอยู่ในหมวดหมู่ 'การช่วยเหลือด้านโค้ด' เดียวกัน วิธีนี้ทนต่อความหลากหลายของสำนวนและช่วยอุดช่องโหว่ของระบบที่ใช้กฎเกณฑ์ (Rule-based) ได้

ในการใช้งานจริง จะทำการ Embedding ประโยคตัวแทนของแต่ละหมวดหมู่ แล้วจัด Query ที่ป้อนเข้ามาไปยังหมวดหมู่ที่มีค่าความคล้ายคลึง (Similarity) สูงที่สุด การคำนวณ Embedding สามารถทำได้อย่างรวดเร็วด้วยโมเดลขนาดเล็ก จึงมี Latency เพิ่มขึ้นเพียงเล็กน้อยเท่านั้น

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

วิธีที่ยืดหยุ่นที่สุดคือ Meta LLM Routing โดยให้ LLM ขนาดเล็กทำหน้าที่ตัดสินว่า "คิวรีนี้ควรประมวลผลด้วยโมเดลใด" แล้วจึงส่งต่อไปตามผลลัพธ์นั้น

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

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

กลยุทธ์มาตรฐานคือการใช้โมเดลที่ราคาถูกและรวดเร็วมาทำหน้าที่ตัดสินใจ และจำกัดรูปแบบของเอาต์พุตให้เข้มงวด (เช่น การระบุชื่อโมเดลเป็นรายการ) เนื่องจากเป็นวิธีที่ต้องแลกด้วย Overhead เพื่อให้ได้ความฉลาด จึงควรเลือกใช้ในกรณีที่การจำแนกมีความซับซ้อนสูง หรือไม่สามารถจัดการได้ด้วยการใช้กฎ (Rule-based) หรือการทำ Embedding

สรุป: หากการจำแนกประเภทของ Query มีความชัดเจน ควรใช้แบบ Rule-based หากมีความผันแปรของรูปแบบคำสูง ควรใช้แบบ Embedding-based และหากเป็นการคัดแยกที่ซับซ้อนซึ่งไม่สามารถกำหนดเกณฑ์ล่วงหน้าได้ ควรใช้ Meta-LLM ก่อนอื่น ขอนำเสนอภาพรวมในรูปแบบตารางดังนี้

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

เมื่อพิจารณาจาก 3 แกน จะทำให้เห็นลักษณะเฉพาะของแต่ละกลยุทธ์ได้อย่างชัดเจน

ต้นทุน (Cost): แบบ Rule-based แทบไม่มีค่าใช้จ่ายในการตัดสินใจ ส่วนแบบ Embedding-based จะมีค่าใช้จ่ายเพิ่มขึ้นเล็กน้อยจากการคำนวณ Embedding ที่มีน้ำหนักเบา สำหรับ Meta-LLM จะมีต้นทุนสูงที่สุดเนื่องจากต้องเรียกใช้โมเดลทุกครั้งที่มีการตัดสินใจ อย่างไรก็ตาม หากความแม่นยำในการคัดแยกเพิ่มขึ้นจนช่วยลดการเรียกใช้โมเดลที่มีต้นทุนสูงได้ ในภาพรวมอาจทำให้ต้นทุนถูกลงกว่าเดิมได้เช่นกัน

ความหน่วง (Latency): ในทำนองเดียวกัน เวลาที่ใช้ในการตัดสินใจจะเพิ่มขึ้นตามลำดับคือ Rule < Embedding < Meta-LLM แต่เนื่องจาก "เวลาในการอนุมานของโมเดลปลายทาง" มักจะมีผลมากกว่า "เวลาในการตัดสินใจคัดแยก" ดังนั้น การคัดแยกไปยังโมเดลที่เหมาะสมจึงส่งผลต่อประสบการณ์การใช้งานมากกว่า

ความแม่นยำ (Accuracy): ความถูกต้องในการคัดแยกมักจะสูงขึ้นตามลำดับคือ Rule < Embedding < Meta-LLM แต่ Meta-LLM ก็มีความเสี่ยงที่จะเกิดข้อผิดพลาดในการตัดสินใจได้เช่นกัน ทั้ง 3 แกนนี้เป็นเรื่องของการแลกเปลี่ยน (Trade-off) ซึ่งมีเงื่อนไขสำคัญคือต้องทำการวัดผลและประเมินจากข้อมูลการกระจายตัวของ Query จริงในบริษัทของคุณ

ในมุมมองของการดำเนินงานระยะยาว ต้นทุนการบำรุงรักษาจะส่งผลมากกว่าการติดตั้งใช้งานในระยะเริ่มต้น

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

สำหรับ Embedding-based หากมีการจัดเตรียมหมวดหมู่และตัวอย่างที่เป็นตัวแทนไว้ ก็จะสามารถรองรับสำนวนใหม่ๆ ได้โดยอัตโนมัติ อย่างไรก็ตาม เมื่อต้องการเพิ่มหรือทบทวนตัวหมวดหมู่เอง จำเป็นต้องมีการออกแบบตัวอย่างที่เป็นตัวแทนใหม่และปรับค่า Threshold ใหม่

สำหรับ Meta-LLM มีความยืดหยุ่นเนื่องจากสามารถกำหนดตรรกะการตัดสินใจผ่าน Prompt ได้ แต่หากพฤติกรรมของโมเดลเปลี่ยนไป การจัดสรรก็จะเปลี่ยนตาม ทำให้การรักษาความสามารถในการทำซ้ำ (Reproducibility) และการทดสอบทำได้ยาก

ในความเป็นจริงแล้ว การใช้แนวทางแบบ Hybrid โดยรักษาโครงสร้างหลักให้เป็นแบบ Rule-based เพื่อความชัดเจน และใช้ Embedding หรือ Meta-LLM เข้ามาเสริมเฉพาะในส่วนที่กำกวม จะช่วยให้สร้างสมดุลกับความสามารถในการบำรุงรักษาได้ดีที่สุด

การทำ Routing จะถูกนำไปใช้ร่วมกับเทคนิคอื่นๆ เช่น RAG และ Chain-of-Thought (CoT)

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

การใช้งานร่วมกับ CoT: การให้โมเดลใช้การคิดแบบเป็นขั้นตอน (Step-by-step reasoning) กับคำถามที่ง่ายเกินไปจะทำให้เสียเวลาและสิ้นเปลืองต้นทุนโดยเปล่าประโยชน์ การแยกประเภทคำถามโดยส่งเฉพาะคำถามที่ยากไปยัง CoT (หรือโมเดลที่มีประสิทธิภาพสูงกว่า) และให้คำถามที่ง่ายได้รับคำตอบทันที จึงเป็นวิธีที่มีประสิทธิภาพ

กล่าวคือ Routing ทำหน้าที่เป็นสวิตช์สำหรับ "เปิดใช้งาน" เทคนิคที่หนักเหล่านี้เฉพาะในเวลาที่จำเป็นเท่านั้น การไม่เปิดใช้งาน RAG หรือ CoT ตลอดเวลา แต่ใช้ Routing เพื่อจำกัดขอบเขตการประยุกต์ใช้ จะช่วยลดต้นทุนเฉลี่ยและค่า Latency ลงได้ในขณะที่ยังคงรักษาคุณภาพของผลลัพธ์ไว้ได้

จากนี้ไปจะขออธิบายขั้นตอนการดำเนินงานโดยแบ่งออกเป็น 3 ขั้นตอน ได้แก่ การออกแบบตัวจำแนกประเภทคิวรี (Query Classifier), การจัดสรรโมเดล (Model Assignment) และการสำรองข้อมูล (Fallback) โดยมีหลักการพื้นฐานคือ เริ่มต้นจากจุดเล็กๆ และค่อยๆ พัฒนาไปพร้อมกับการวัดผล

หัวใจสำคัญของการทำ Routing คือกลไกในการจำแนกประเภทของ Query

ขั้นแรก ให้กำหนดหมวดหมู่ที่ต้องการแยก (เช่น การพูดคุยทั่วไป, FAQ, โค้ด, การวิเคราะห์ข้อความยาว, การสรุปความ) จากนั้นให้รวบรวมบันทึก Query จริง แล้วนำมาจัดหมวดหมู่เพื่อสร้างเป็นชุดข้อมูล "Query จริงของบริษัท" นี้มีความสำคัญเหนือสิ่งอื่นใด เพราะตัวอย่างที่สร้างขึ้นจากจินตนาการเพียงอย่างเดียวอาจมีความคลาดเคลื่อนจากข้อมูลที่เกิดขึ้นจริงในการใช้งาน

สำหรับการนำไปใช้งานจริง ตัวจำแนกประเภท (Classifier) สามารถทำได้หลายวิธี ได้แก่ การใช้เงื่อนไข (Rule-based), การใช้เวกเตอร์ตัวแทนของหมวดหมู่ (Embedding-based) หรือการใช้ Prompt ในการตัดสินใจ (Meta-LLM) ไม่ว่าจะใช้วิธีใด ไม่จำเป็นต้องทำให้สมบูรณ์แบบตั้งแต่แรก แต่สามารถเริ่มต้นจากหมวดหมู่หลักๆ ก่อนได้

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

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

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

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

ในการปฏิบัติงานจริง การตัดสินใจแบบสองขั้นตอนจะช่วยให้จัดการได้ง่ายขึ้น คือ (1) คัดกรอง "กลุ่มโมเดลที่รองรับ" ด้วยจำนวน Input Token และ (2) เลือกความสมดุลระหว่างประสิทธิภาพและราคาจากกลุ่มนั้นตามระดับความยากของหมวดหมู่ ทั้งนี้ ควรประเมินจำนวน Token ก่อนการตัดสินใจ Routing และหากคาดว่าจะเกินขีดจำกัด ให้ทำการสรุปหรือแบ่งส่วนอินพุตก่อนดำเนินการ

ในการใช้งานจริง ย่อมต้องเกิดปัญหาขึ้นอย่างหลีกเลี่ยงไม่ได้ เช่น โมเดลปลายทางส่งค่า Error กลับมา, เกิด Timeout หรือติด Rate Limit การเตรียมพร้อมรับมือกับสิ่งเหล่านี้คือหน้าที่ของ Fallback และ Circuit Breaker

Fallback: หากโมเดลตัวเลือกแรกเกิดความล้มเหลว ให้สลับไปใช้โมเดลสำรองโดยอัตโนมัติ โดยเตรียมเส้นทางสำรองไว้เป็นลำดับขั้น เช่น หากโมเดลประสิทธิภาพสูงล่ม ให้เปลี่ยนไปใช้โมเดลอีกระบบหนึ่ง หรือหาก API ภายนอกใช้งานไม่ได้ ให้เปลี่ยนไปใช้โมเดลที่รันในเครื่อง (Local model) แทน

Circuit Breaker: หากโมเดลใดโมเดลหนึ่งเกิด Error ติดต่อกัน ให้หยุดการส่งคำขอไปยังโมเดลนั้นชั่วคราวเพื่อรอให้ระบบฟื้นตัว วิธีนี้จะช่วยป้องกันไม่ให้ระบบส่งคำขอไปยังจุดที่ล่มอยู่ซ้ำๆ ซึ่งจะทำให้เกิดความล่าช้าสะสมจนส่งผลกระทบต่อภาพรวม

การรวมกลไกเหล่านี้ไว้ใน Routing Layer จะช่วยป้องกันไม่ให้ความล้มเหลวของโมเดลแต่ละตัวส่งผลโดยตรงต่อการหยุดชะงักของบริการทั้งหมด สิ่งนี้มีความสำคัญอย่างยิ่งในการตั้งค่าแบบ Edge หรือ Multi-provider โดยการออกแบบที่เน้น "แม้ตัวใดตัวหนึ่งจะล่ม แต่ระบบยังคงทำงานต่อไปได้ในรูปแบบที่ลดทอนลง (Graceful Degradation)" คือหัวใจสำคัญที่ช่วยรักษาความน่าเชื่อถือของบริการ

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

ความผิดพลาดที่พบบ่อยคือการเชื่อมั่นในการตัดสินใจของ Routing มากเกินไป

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

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

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

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

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

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

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