Model routing

Model routing คือการออกแบบระบบให้ตัวมันเองเลือกได้ว่าคำขอแต่ละครั้งควรส่งไปให้โมเดลตัวไหนตอบ แทนที่จะยิงทุกงานเข้าโมเดลตัวที่เก่งและแพงที่สุดเหมือนกันหมด แนวคิดนี้ตั้งอยู่บนข้อเท็จจริงเรื่องราคาที่ห่างกันจริง เอกสารทางการของ Anthropic ระบุว่า Claude Opus 5 คิดค่าใช้งาน 5 ดอลลาร์ต่อ input token หนึ่งล้านตัว และ 25 ดอลลาร์ต่อ output token หนึ่งล้านตัว ขณะที่ Claude Fable 5 คิด 10 และ 50 ดอลลาร์ตามลำดับ ต่างกันเท่าตัวทั้งที่เป็นรุ่นของผู้ให้บริการเจ้าเดียวกัน เมื่องานจริงในองค์กรมีตั้งแต่ "ช่วยสรุปอีเมลฉบับนี้ให้หน่อย" ไปจนถึง "ไล่หาสาเหตุที่ระบบล่มจาก log สามพันบรรทัด" การบังคับให้ทั้งสองอย่างใช้โมเดลตัวเดียวกันจึงกลายเป็นการจ่ายแพงเกินจำเป็นในงานกลุ่มแรก หรือได้คำตอบไม่ดีพอในงานกลุ่มหลัง

ตัวจัดเส้นทางใช้อะไรตัดสินใจนั้นดูได้จากสองแพลตฟอร์มที่เปิดเอกสารไว้ชัด ฝั่ง amazon-bedrock มีฟีเจอร์ชื่อ intelligent prompt routing ที่เปิดปลายทางเดียวให้แอปเรียก แล้วระบบจะทำนายคุณภาพคำตอบของแต่ละโมเดลสำหรับคำขอนั้นก่อนจึงส่งไปยังตัวที่ให้ผลดีที่สุด เอกสารของ AWS กำหนดให้เลือกโมเดลสองตัวในตระกูลเดียวกัน ตั้งโมเดลสำรองไว้เป็นหลักยึด แล้วกำหนดเกณฑ์ที่เรียกว่า response quality difference ว่าอีกโมเดลต้องให้คำตอบดีกว่าหลักยึดมากแค่ไหนจึงจะยอมสลับไปใช้ ตัวอย่างในเอกสารใช้ค่า 10 เปอร์เซ็นต์ ส่วน openrouter ใช้อีกวิธี เอกสารอธิบายว่า Auto Router มี classifier ตัวเล็กและเร็วคอยจัดคำขอเข้ากลุ่มงานราวสามสิบประเภท เช่น งานไล่บั๊กโค้ดหรืองานถามความรู้ทั่วไป แล้วดูว่าในช่วงเจ็ดวันล่าสุดชุมชนผู้ใช้จ่ายเงินไปกับโมเดลไหนในงานประเภทนั้น ผู้ใช้เลือกย่านราคาที่จะให้ระบบพิจารณาผ่านค่า cost_tier ซึ่งมีห้าระดับคือ low, medium, high, xhigh และ max โดยเอกสารย้ำว่าค่านี้เป็นย่านราคาไม่ใช่เพดานราคา ตั้งไว้ระดับไหนโมเดลที่ถูกกว่าย่านนั้นก็ถูกตัดออกเช่นเดียวกับตัวที่แพงกว่า ระบบจะจำโมเดลที่บทสนทนาหนึ่งลงตัวแล้วเพื่อใช้ต่อในเทิร์นถัดไป เท่าที่โมเดลตัวนั้นยังติดกลุ่มตัวเลือกอันดับต้นของคำขอใหม่อยู่ และถ้าตัวจัดอันดับใช้การไม่ได้ เอกสารระบุว่าจะถอยไปใช้ชุดโมเดลตั้งต้นเพื่อไม่ให้คำขอล้มเพราะปัญหาของ router เอง ตำแหน่งของ routing จึงอยู่ระหว่างแอปกับโมเดล คือแอปเรียกปลายทางเดียวแล้วชั้นนี้เลือกให้ ที่ต้องแยกให้ออกคือบน OpenRouter ยังมีการจัดเส้นทางอีกชั้นชื่อ provider routing ซึ่งไม่ได้เลือกว่าใช้โมเดลรุ่นไหน แต่เลือกว่าจะใช้ ผู้ให้บริการ รายไหนที่โฮสต์โมเดลรุ่นเดียวกันนั้น โดยค่าเริ่มต้นคือกระจายโหลดตามราคาแบบผกผันกำลังสอง ให้น้ำหนักกับรายที่ไม่มี outage ครั้งใหญ่ในสามสิบวินาทีที่ผ่านมาก่อน และเก็บรายที่เหลือไว้เป็นตัวสำรอง ถ้าสั่งให้เรียงตามราคา ตาม throughput หรือตาม latency ระบบจะปิดการกระจายโหลดแล้วไล่ตามลำดับที่สั่งแทน

เส้นแบ่งที่คนทำงานควรจับให้ได้คือระหว่างกฎที่คนเขียนเองกับตัวจัดเส้นทางที่เรียนรู้เอง แบบแรกคือทีมเขียนเงื่อนไขตรงไปตรงมา เช่น งานแปลและงานสรุปสั้นให้วิ่งไป โมเดลตัวเล็ก ส่วนงานวิเคราะห์เอกสารยาวให้ไปรุ่นใหญ่ ข้อดีคือเปิดดูได้ว่าทำไมคำขอนี้ถึงไปทางนั้นและแก้ได้ทันทีเมื่อผิด ข้อเสียคือต้องมีคนคอยดูแลกฎทุกครั้งที่รุ่นโมเดลเปลี่ยน แบบที่สองคือให้โมเดลตัวเล็กทำนายเองว่างานนี้รุ่นไหนก็พอ งานวิจัย RouteLLM ซึ่งฝึกตัวจัดเส้นทางจากข้อมูลความชอบของมนุษย์ ระบุใน abstract ว่าลดต้นทุนได้มากกว่าสองเท่าในบางกรณีโดยคุณภาพคำตอบไม่ตก และ router ที่ฝึกกับคู่โมเดลหนึ่งยังใช้กับคู่โมเดลอื่นได้โดยไม่ต้องฝึกใหม่ ข้อควรระวังคือบทคัดย่อเขียนว่าลดต้นทุนได้เกินสองเท่าเฉพาะในบางกรณี ไม่ใช่ทุกกรณี ตัวงานผ่านการรีวิวและได้นำเสนอเป็น poster ที่ ICLR 2025 แล้ว แม้หน้า arXiv จะไม่ได้ระบุ venue ไว้ก็ตาม ข้อควรระวังที่ใกล้ตัวคนไทยกว่านั้นมาจากเอกสารของ AWS เอง ซึ่งเขียนไว้ตรงๆ ว่า intelligent prompt routing ปรับมาให้เหมาะกับ prompt ภาษาอังกฤษเท่านั้น ปรับการตัดสินใจตามข้อมูลผลงานเฉพาะของแอปเราไม่ได้ และอาจให้เส้นทางที่ไม่เหมาะกับงานเฉพาะทาง เพราะผลลัพธ์ขึ้นกับข้อมูลที่ใช้ฝึกตั้งแต่ต้น ก่อนเปิดใช้จริงจึงควรมีชุด evals ของตัวเองไว้วัดว่าคำตอบแย่ลงตรงไหน เอกสารของ Anthropic บอกว่าการสร้างชุดทดสอบเฉพาะงานของเราคือขั้นตอนที่สำคัญที่สุดในกระบวนการเลือกโมเดล ส่วนคู่มือของ OpenAI แนะนำให้ตั้งเป้าความแม่นยำให้ถึงก่อน แล้วค่อยไล่ลดต้นทุนและ latency ทีหลัง ด้วยเหตุผลว่าถ้าโมเดลยังทำงานไม่ได้ตามเป้า เรื่องราคาก็ยังไม่มีความหมาย

ตัวอย่างจากบทสนทนาจริง

หัวหน้าฝ่ายปฏิบัติการ: บิลค่า AI เดือนนี้ขึ้นมาเกือบเท่าตัว ผมสั่งให้ทุกคนเลิกใช้รุ่นใหญ่แล้วย้ายไปรุ่นเล็กทั้งบริษัทเลยดีไหม

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

หัวหน้าฝ่ายปฏิบัติการ: แล้วตัวจัดเส้นทางสำเร็จรูปที่ผู้ให้บริการ cloud เขามีให้ เปิดใช้เลยไม่ได้เหรอ

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

ระวังสับสนกับ

• effort : effort คือการบอกโมเดลตัวเดิมว่าให้ทุ่มแรงคิดมากน้อยแค่ไหน เป็นการปรับภายในโมเดลตัวเดียว ส่วน model routing คือการสลับไปคนละตัว เอกสารของ Anthropic ระบุว่าการปรับ effort มักเป็นคันโยกที่ดีกว่าการเปลี่ยนโมเดล
• ai-spend-cap : เพดานค่าใช้จ่ายคือการสั่งหยุดเมื่อถึงวงเงิน คำขอที่เกินมาจะถูกปฏิเสธไปเลย ส่วน model routing ไม่ได้หยุดใคร แต่ทำให้คำขอเดิมถูกลงด้วยการเลือกโมเดลให้พอดีกับงาน ของจริงมักใช้คู่กัน
• Provider routing : เป็นการเลือกว่าจะใช้ผู้ให้บริการรายไหนที่โฮสต์โมเดลรุ่นเดียวกัน ตอบโจทย์เรื่องราคาต่อหน่วย ความเร็ว และตัวสำรองเวลาปลายทางล่ม ส่วน model routing เลือกว่าจะใช้โมเดลรุ่นไหน ซึ่งกระทบคุณภาพคำตอบโดยตรง
• total-cost-of-ownership : TCO คือมุมมองต้นทุนรวมทั้งชีวิตของระบบ รวมค่าดูแลและค่าคน ส่วน model routing เป็นกลไกที่ไปลดเฉพาะค่าเรียกใช้โมเดล ซึ่งเป็นแค่ก้อนหนึ่งใน TCO และตัว routing เองก็เพิ่มงานดูแลขึ้นมาอีกชิ้น