คู่มือการออกแบบไฮบริด Cloud LLM × On-device SLM — กลยุทธ์การจัดเส้นทางงาน (Task Routing)

แนวทางการออกแบบที่ผสมผสานระหว่าง Cloud LLM และ On-device SLM โดยสลับการประมวลผลตามลักษณะของงาน เรียกว่า "Hybrid LLM Design"

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

บทความนี้มุ่งเน้นไปที่วิศวกร AI และสถาปนิกซอฟต์แวร์ โดยจะอธิบายกลยุทธ์การจัดเส้นทางงาน (Task Routing) ตามมุมมองด้านต้นทุน ความหน่วง และการปฏิบัติตามกฎระเบียบ (Compliance) เมื่ออ่านจบ คุณจะสามารถเลือกโครงสร้างแบบ Hybrid ที่เหมาะสมกับระบบขององค์กรและเข้าใจข้อควรระวังในการนำไปใช้งานจริงได้

แนวคิดการออกแบบที่ใช้ Cloud LLM ร่วมกับ On-device SLM เรียกว่า Hybrid LLM Design โดยมีหัวใจสำคัญคือการไม่ฝากงานทั้งหมดไว้กับโมเดลเดียว แต่เป็นการจัดสรรงานไปยังโมเดลที่เหมาะสมที่สุดตามลักษณะของกระบวนการประมวลผล

การตอบโจทย์ทั้งสามด้าน ได้แก่ ต้นทุน (Cost) ความหน่วง (Latency) และการปกป้องข้อมูล (Data Protection) พร้อมกันนั้น เป็นเรื่องยากหากใช้เพียง Cloud หรือ On-device เพียงอย่างเดียว ความเป็นจริงนี้จึงผลักดันให้โครงสร้างแบบ Hybrid กลายเป็นทางเลือกที่ใช้งานได้จริง

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

"การออกแบบแบบไฮบริด" (Hybrid Design) ที่ผสมผสานระหว่าง Cloud LLM และ On-device SLM (Small Language Model) นั้นแตกต่างจากการเลือกใช้เพียงอย่างใดอย่างหนึ่งอย่างสิ้นเชิง ความแตกต่างที่สำคัญที่สุดเมื่อเทียบกับการใช้งานแบบเดี่ยวคือ การมี "เลเยอร์การกำหนดเส้นทาง" (Routing Layer) ที่ทำหน้าที่จัดสรรการประมวลผลตามลักษณะของงานโดยอัตโนมัติ

ในการใช้งานแบบเดี่ยว คำขอทั้งหมดจะถูกส่งไปยังโมเดลเดียวกัน ในขณะที่การออกแบบแบบไฮบริดจะมีกลไกในการประเมินคุณลักษณะของงานทันทีที่ได้รับ และส่งไปยังโมเดลที่เหมาะสมที่สุด

สรุปความแตกต่างหลักได้ดังนี้:

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

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

การออกแบบแบบไฮบริดเป็นโครงสร้างที่ตั้งอยู่บนพื้นฐานของความไม่เป็นเนื้อเดียวกันนี้ ซึ่งช่วยให้สามารถปรับแต่งการแลกเปลี่ยน (Trade-off) ที่ไม่สามารถทำได้ในการใช้งานแบบเดี่ยว

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

นอกจากนี้ ยังมีประเด็นเรื่องการปกป้องข้อมูลที่มองข้ามไม่ได้ ในอุตสาหกรรมที่มีการกำกับดูแลเข้มงวด เช่น การแพทย์ การเงิน และกฎหมาย การส่งข้อมูลส่วนบุคคลหรือข้อมูลที่เป็นความลับไปยังเซิร์ฟเวอร์ภายนอก อาจสร้างความเสี่ยงในการละเมิดกฎหมาย EU AI Act, GDPR และกฎระเบียบการจัดเก็บข้อมูลในท้องถิ่น (Data Localization) ของแต่ละประเทศ ซึ่งการใช้โครงสร้างแบบคลาวด์เพียงอย่างเดียวมักทำให้การออกแบบระบบเพื่อรองรับข้อกำหนดด้านการปฏิบัติตามกฎระเบียบ (Compliance) มีความซับซ้อนมากขึ้น

ในทางกลับกัน หากพึ่งพา On-device SLM เพียงอย่างเดียว ก็จะพบกับขีดจำกัดด้านความสามารถ ดังนี้:

• การใช้เหตุผลที่ซับซ้อนและการสร้างข้อความยาว: โครงสร้างมักมี Context Window ที่จำกัด ทำให้ความแม่นยำลดลงในงานที่ต้องใช้การใช้เหตุผลหลายขั้นตอน (Multi-step reasoning)
• การรองรับหลายภาษา: คุณภาพของ Multilingual NLP มักได้รับอิทธิพลจากขนาดของโมเดลและปริมาณข้อมูลที่ใช้ฝึกฝน ซึ่ง SLM มักจะมีข้อจำกัดในส่วนนี้
• ต้นทุนการอัปเดตโมเดล: การรักษาโมเดลบนอุปกรณ์ให้เป็นเวอร์ชันล่าสุดนั้นมีภาระในการจัดการและการแจกจ่ายซอฟต์แวร์

กล่าวคือ ทั้งคลาวด์และ On-device ต่างก็มีข้อดีข้อเสียที่แตกต่างกัน หากพยายามใช้เพียงอย่างใดอย่างหนึ่งเพื่อครอบคลุมทุกงาน ย่อมต้องมีการยอมแลกเปลี่ยน (Trade-off) ในบางจุดเสมอ เกณฑ์การตัดสินใจในการทำ Routing ที่จะอธิบายในหัวข้อถัดไป จึงเป็นกรอบแนวคิดสำหรับการเลือกใช้ทั้งสองรูปแบบให้เหมาะสมกับลักษณะของงาน โดยตั้งอยู่บนพื้นฐานที่ว่า "ไม่มีวิธีใดที่เป็นคำตอบที่ดีที่สุดเพียงหนึ่งเดียว"

"การกำหนดเส้นทาง" (Routing) เพื่อเลือกว่าจะส่งงานไปยังโมเดลใดถือเป็นหัวใจสำคัญของการออกแบบแบบไฮบริด หากตัดสินใจผิดพลาด สิ่งที่ควรจะเป็นการลดต้นทุนอาจกลายเป็นการทำให้ค่าความหน่วง (Latency) แย่ลง หรือการให้ความสำคัญกับความสะดวกสบายมากเกินไปอาจนำไปสู่การละเมิดกฎระเบียบ (Compliance) ได้

ในส่วนนี้ เราจะจัดระเบียบปัจจัยหลัก 3 ประการ ได้แก่ ต้นทุน (Cost), ค่าความหน่วง (Latency) และการปฏิบัติตามกฎระเบียบ (Compliance) (รวมถึงการคุ้มครองข้อมูล) โดยแต่ละปัจจัยไม่ได้แยกจากกันโดยสิ้นเชิง ในการออกแบบการกำหนดเส้นทางจริง จำเป็นต้องพิจารณาปัจจัยเหล่านี้ไปพร้อมๆ กัน รายละเอียดของแต่ละปัจจัยจะถูกเจาะลึกในหัวข้อ H3 ถัดไป

การเพิ่มประสิทธิภาพด้านต้นทุนเป็นหนึ่งในแรงจูงใจที่สำคัญที่สุดของการออกแบบแบบไฮบริด (Hybrid Design) โดย Cloud LLM มีราคาต่อโทเค็นที่สูง ซึ่งเมื่อมีการส่งคำขอจำนวนมากสะสมกัน มักจะทำให้ค่าใช้จ่ายรายเดือนพุ่งสูงขึ้น ในขณะที่ On-device SLM มีต้นทุนในการอนุมาน (Inference cost) ใกล้เคียงกับศูนย์ ดังนั้น การมอบหมายงานที่มีปริมาณโทเค็นสูงหรือมีการเรียกใช้งานบ่อยครั้งให้กับ SLM จึงช่วยลดค่าใช้จ่ายลงได้อย่างมาก

เกณฑ์พื้นฐานในการแบ่งงาน

• จำนวนโทเค็นขาเข้า (Input tokens): SLM มีความโดดเด่นในงานประเภทการจำแนกหรือการสกัดข้อมูลสั้นๆ ที่ไม่เกินหลักร้อยโทเค็น ส่วนงานสรุปความยาวหรือการใช้เหตุผลที่ซับซ้อนซึ่งเกินหลักพันโทเค็น ควรใช้ Cloud LLM
• ความถี่ในการเรียกใช้งาน: งานประมวลผลแบบแบตช์ (Batch processing) หรือการวิเคราะห์แบบฟอร์มมาตรฐานที่ทำซ้ำหลายหมื่นครั้งต่อวัน ควรให้ SLM เป็นผู้รับผิดชอบ เพื่อลดจำนวนครั้งในการเรียกใช้งาน Cloud โดยตรง
• ข้อกำหนดด้านความแม่นยำ: งานที่หากเกิดข้อผิดพลาดจะมีต้นทุนสูง เช่น การตรวจสอบสัญญาหรือเอกสารทางการแพทย์ ควรเลือกใช้ Cloud LLM ที่ให้ความสำคัญกับความแม่นยำเป็นอันดับแรก แม้จะมีต้นทุนที่สูงกว่าก็ตาม

แนวคิดเชิงปฏิบัติ

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

ความหน่วง (Latency) และการรองรับการทำงานแบบออฟไลน์เป็นเกณฑ์ที่ชัดเจนที่สุดในการตัดสินใจเลือกระหว่าง Cloud LLM กับ On-device SLM ในกรณีที่ต้องพึ่งพาการรับส่งข้อมูลผ่านเครือข่ายซึ่งอาจเกิดความล่าช้า (Overhead) หลายร้อยมิลลิวินาทีเมื่อเทียบกับการประมวลผลในเครื่อง (Local Inference) ของ SLM ที่ตอบสนองได้ทันทีนั้น อาจส่งผลให้ประสบการณ์การใช้งานของผู้ใช้แตกต่างกันอย่างเห็นได้ชัด

เกณฑ์การตัดสินใจตามความต้องการด้านความหน่วง (Latency Requirements)

• กรณีที่ต้องการการตอบสนองภายใน 200ms หรือน้อยกว่า (เช่น ระบบสั่งการด้วยเสียง, คำบรรยายแบบเรียลไทม์, NPC ในเกม) → ให้ความสำคัญกับ On-device SLM
• กรณีที่ยอมรับการตอบสนองได้ประมาณ 1-3 วินาที (เช่น การสรุปเอกสาร, การแนะนำการเติมโค้ด) → Cloud LLM เป็นทางเลือกที่พิจารณาได้
• การประมวลผลแบบแบตช์ (Batch Processing) หรือภารกิจแบบอะซิงโครนัส (เช่น การสร้างรายงานตอนกลางคืน, การแปลเอกสารจำนวนมาก) → ให้ความสำคัญกับความแม่นยำและต้นทุนมากกว่าความหน่วง จึงเลือกใช้ Cloud LLM

ความต้องการในสภาพแวดล้อมแบบออฟไลน์หรือการเชื่อมต่อที่ไม่เสถียร

ในสภาพแวดล้อมที่ไม่สามารถรับประกันการเชื่อมต่อเครือข่ายได้ เช่น พื้นที่โรงงาน, บนเครื่องบิน หรือพื้นที่ห่างไกลบนภูเขา การส่งข้อมูลไปยัง Cloud LLM อาจทำไม่ได้เลย ในสถานการณ์เช่นนี้ การใช้สถาปัตยกรรมที่ติดตั้ง SLM ไว้ในอุปกรณ์ในฐานะ Edge AI เพื่อใช้งาน และใช้ Cloud LLM เพื่อตรวจสอบหรือเสริมข้อมูลหลังจากที่การเชื่อมต่อกลับมาเป็นปกติแล้วนั้นถือว่ามีประสิทธิภาพ

ข้อควรระวังในการออกแบบ

สิ่งสำคัญคือการประเมินความต้องการด้านความหน่วงโดยใช้ "ค่าผิดปกติที่ P95-P99" (P95-P99 Outliers) ไม่ใช่ "ค่าเฉลี่ย" เนื่องจาก Cloud API มีแนวโน้มที่เวลาในการตอบสนองจะพุ่งสูงขึ้นในช่วงที่มีการใช้งานหนาแน่น ดังนั้นในสถานการณ์ที่มีข้อกำหนด SLA เข้มงวด การติดตั้ง On-device SLM ไว้เป็นระบบสำรอง (Fallback) จะช่วยรักษาเสถียรภาพของคุณภาพการบริการได้

สำหรับการแบ่งประเภทตามมุมมองด้านการปฏิบัติตามกฎระเบียบ (Compliance) จะกล่าวถึงโดยละเอียดในส่วนถัดไป

ระดับความลับของข้อมูลและข้อกำหนดด้านกฎระเบียบมักเป็นปัจจัยสำคัญที่สุดในการตัดสินใจเลือกระหว่างการใช้ Cloud LLM และ On-device SLM

ประเภทของข้อมูลที่ควรหลีกเลี่ยงการส่งไปยังคลาวด์

• ข้อมูลระบุตัวบุคคล (ชื่อ-นามสกุล, ที่อยู่, หมายเลขประจำตัวประชาชน ฯลฯ)
• เอกสารลับด้านการแพทย์ การเงิน และกฎหมาย
• ข้อมูลภายในที่ยังไม่เปิดเผยต่อสาธารณะหรือความลับทางการค้า
• ข้อมูลที่อยู่ภายใต้การกำกับดูแลของ EU AI Act, GDPR และกฎหมายคุ้มครองข้อมูลส่วนบุคคลภายในประเทศ

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

แนวคิดการแบ่งประเภทตามกฎระเบียบและนโยบาย

ขอแนะนำให้ใช้แนวคิด Privacy-by-Isolation โดยออกแบบระบบไม่ให้ข้อมูลลับรั่วไหลออกนอกขอบเขตของอุปกรณ์

ในทางกลับกัน แม้จะใช้ Cloud LLM ก็จำเป็นต้องตรวจสอบเงื่อนไขการประมวลผลข้อมูลในสัญญา (DPA) และการตั้งค่า Opt-out เพื่อไม่ให้ข้อมูลถูกนำไปใช้ฝึกฝนโมเดล นอกจากนี้ การกำหนด Guardrails ควบคู่ไปกับการสร้างไปป์ไลน์เพื่อตรวจจับและปกปิด (Mask) ข้อมูล PII ก่อนการส่งข้อมูล จะช่วยให้สามารถขยายขอบเขตการใช้งานคลาวด์ได้อย่างปลอดภัยยิ่งขึ้น

กลยุทธ์การทำ Routing มีแนวทางที่หลากหลายขึ้นอยู่กับการแลกเปลี่ยน (Trade-off) ระหว่างความซับซ้อนในการออกแบบและต้นทุนการดำเนินงาน โดยสามารถแบ่งออกเป็น 3 รูปแบบหลัก ได้แก่ "Static Routing" ซึ่งเป็นการกำหนดและแยกประเภทงานไว้ล่วงหน้า, "Cascading" ซึ่งเป็นการสลับโมเดลแบบไดนามิกโดยพิจารณาจากค่าความเชื่อมั่น (Confidence score) ของผลลัพธ์จากโมเดล และ "SLM Draft + Cloud Verification" ซึ่ง SLM จะทำหน้าที่ร่างเนื้อหาและให้ Cloud LLM เป็นผู้ตรวจสอบ ทั้งนี้ แต่ละรูปแบบมีกรณีการใช้งาน (Use case) และความยากในการนำไปใช้งานจริงที่แตกต่างกัน การเลือกรูปแบบที่เหมาะสมกับความต้องการขององค์กรจึงเป็นจุดเริ่มต้นสำคัญของการออกแบบ

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

ตรรกะพื้นฐานในการจัดสรร

• ตัวอย่างงานที่ส่งไปยัง SLM: การเติมข้อความในแบบฟอร์มมาตรฐาน, การตอบคำถาม FAQ, การจำแนกอารมณ์ในข้อความสั้น, การสกัดคำสำคัญในสภาพแวดล้อมแบบออฟไลน์
• ตัวอย่างงานที่ส่งไปยัง Cloud LLM: การสรุปความยาว, การวิเคราะห์ข้ามเอกสารหลายฉบับ, การแปลหลายภาษา, การสร้างโค้ด

โดยทั่วไปมักใช้การผสมผสานระหว่าง 3 แกนการจำแนก ได้แก่ "จำนวน Input Token", "Task Category ID" และ "User Role" ตัวอย่างเช่น สามารถเขียนกฎได้ว่า หาก Input มีขนาดไม่เกิน 256 Token และอยู่ในหมวดหมู่ "FAQ" ให้ส่งไปยัง SLM แต่ถ้าไม่ใช่ให้ส่งไปยัง Cloud LLM

ข้อควรระวังในการติดตั้งใช้งาน

Static Routing ขึ้นอยู่กับความแม่นยำของการจำแนกประเภทในขั้นตอนการออกแบบ หากความละเอียดของหมวดหมู่งานหยาบเกินไป งานที่เดิมที SLM สามารถประมวลผลได้เพียงพอมักจะถูกส่งไปยัง Cloud LLM ทำให้ต้นทุนเพิ่มสูงขึ้น ในทางกลับกัน หากการจำแนกละเอียดเกินไป ภาระในการดูแลรักษาตารางกฎก็จะเพิ่มขึ้น

หลังจากเริ่มใช้งานจริง ควรใช้เครื่องมือ AI Observability เพื่อวัดค่า Latency และคะแนนคุณภาพแยกตามเส้นทางอย่างต่อเนื่อง และควรทบทวนกฎการจำแนกประเภทเป็นระยะ

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

การกำหนดเส้นทางแบบไดนามิกตามระดับความเชื่อมั่น (Cascade) คือวิธีการตัดสินใจโดยอัตโนมัติว่าจะยกระดับ (Escalate) ไปยัง Cloud LLM หรือไม่ โดยใช้ คะแนนความเชื่อมั่น (Confidence Score) ของผลลัพธ์ที่ได้จาก SLM เป็นเกณฑ์ในการตัดสิน ซึ่งแตกต่างจากการกำหนดเส้นทางแบบคงที่ (Static Routing) ตรงที่ไม่ได้ใช้ประเภทของงานเป็นเกณฑ์ แต่ใช้ "ความมั่นใจในการอนุมานนั้น" เป็นมาตรฐาน จึงสามารถตอบสนองต่ออินพุตที่ไม่คาดคิดได้อย่างยืดหยุ่น

ภาพรวมของกลไก

1. SLM ดำเนินการอนุมานและคำนวณคะแนนความเชื่อมั่นจากการกระจายความน่าจะเป็นของโทเค็น
2. หากคะแนนเกินเกณฑ์ที่กำหนด (เช่น 0.85) ให้ส่งคำตอบของ SLM ออกไปทันที
3. เฉพาะในกรณีที่คะแนนต่ำกว่าเกณฑ์เท่านั้น จึงจะส่งพรอมต์เดียวกันไปยัง Cloud LLM
4. ส่งคำตอบของ Cloud LLM กลับไปเป็นผลลัพธ์สุดท้าย

ข้อดีและข้อควรระวัง

• ความคุ้มค่า: เนื่องจากคำถามง่ายๆ ที่พบบ่อยจะถูกจัดการโดย SLM ทำให้มีแนวโน้มที่จะลดการเรียกใช้ Cloud API ได้
• การรับประกันคุณภาพ: เนื่องจากจะส่งเฉพาะคำถามที่คลุมเครือหรือซับซ้อนไปยังโมเดลระดับสูงโดยอัตโนมัติ จึงช่วยลดความเสี่ยงในการเกิดอาการประสาทหลอน (Hallucination) ได้ง่ายขึ้น
• ความเสี่ยงด้านความหน่วงแฝง (Latency): เมื่อเกิดการยกระดับ เวลาในการอนุมานของทั้ง SLM และ LLM จะถูกนำมารวมกัน จึงจำเป็นต้องระมัดระวังในการออกแบบเรื่องการหมดเวลา (Timeout)

ประเด็นสำคัญในการนำไปใช้งาน

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

รูปแบบ "SLM ร่างคำตอบ → Cloud LLM ตรวจสอบ" ที่จะแนะนำในส่วนถัดไป ถือเป็นโครงสร้างที่พัฒนาต่อยอดมาจาก Cascade นี้

เป็นรูปแบบการทำงานแบบสองขั้นตอน (Two-stage pattern) ที่ใช้ On-device SLM สร้างร่างคำตอบอย่างรวดเร็ว และให้ Cloud LLM ทำหน้าที่ตรวจสอบและเติมเต็มเนื้อหา ซึ่งมีประสิทธิภาพอย่างยิ่งในสถานการณ์ที่ต้องการปรับสมดุลระหว่างความหน่วง (Latency), ต้นทุน และคุณภาพไปพร้อมกัน

ภาพรวมการทำงาน

1. SLM รับอินพุตจากผู้ใช้และสร้างร่างแรกภายในเวลาไม่กี่ร้อยมิลลิวินาที
2. ตัดสินใจว่าจะส่งต่อไปยัง Cloud LLM หรือไม่ โดยพิจารณาจากคะแนนความน่าเชื่อถือ (Confidence score), จำนวนตัวอักษร หรือความซับซ้อนของร่างแรก
3. เฉพาะในกรณีที่จำเป็นต้องส่งต่อเท่านั้น จึงจะส่งร่างแรกไปเป็นบริบท (Context) ให้กับ Cloud LLM เพื่อตรวจสอบและแก้ไขเพิ่มเติม

สถานการณ์ที่เหมาะสมกับรูปแบบนี้

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

ผลลัพธ์ด้านต้นทุน

การใช้ SLM กรองคำขอก่อนส่งไปยัง Cloud LLM มักช่วยลดปริมาณโทเค็นที่ต้องส่งได้ เนื่องจากคำถามทั่วไปหรือการตอบกลับตามรูปแบบมาตรฐานจะเสร็จสิ้นได้ด้วย SLM ทำให้ลดจำนวนการเรียกใช้ Cloud API ลง

ข้อควรระวังในการออกแบบ

• หากคุณภาพร่างแรกของ SLM ต่ำเกินไป อัตราการส่งต่อข้อมูลไปยัง Cloud LLM จะสูงขึ้น ทำให้ประสิทธิภาพในการลดต้นทุนลดลง
• การนำร่างแรกไปใส่ใน Prompt โดยตรงจะสิ้นเปลือง Context window ดังนั้นการทำ Pre-processing เพื่อสรุปหรือบีบอัดข้อมูลจึงเป็นวิธีที่มีประสิทธิภาพ
• ควรออกแบบระบบโดยฝังตรรกะการตรวจจับอาการประสาทหลอน (Hallucination) ไว้เป็น Guardrail เพื่อป้องกันไม่ให้ข้อมูลที่ผิดพลาดหลุดออกไปสู่ขั้นตอนถัดไป

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

การจะ "ออกแบบ" กลยุทธ์การทำ Routing ไม่ใช่แค่เรื่องของการวางแผน แต่รวมถึงการ "ทำให้ระบบทำงานได้อย่างต่อเนื่อง" ซึ่งจำเป็นต้องเข้าใจถึงความซับซ้อนในการติดตั้งและภาระในการดูแลรักษาล่วงหน้า รูปแบบการทำ Routing ทั้งแบบ Static, Dynamic และ Hybrid ต่างมีต้นทุนในการสร้างช่วงเริ่มต้นและปริมาณงานในการบำรุงรักษาที่แตกต่างกันอย่างมาก การประเมินว่ารูปแบบใดเหมาะสมกับขนาดทีมและ Tech Stack ขององค์กรมากที่สุด คือจุดเริ่มต้นของการออกแบบที่ยั่งยืน

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

โครงสร้างพื้นฐานในการติดตั้ง

• กำหนด Task Label เมื่อมีการป้อนข้อมูล (เช่น task_type: summarize / translate / reason)
• จัดการตาราง Mapping ระหว่าง Label กับโมเดลผ่านโค้ดหรือไฟล์การตั้งค่า
• Router ทำหน้าที่เพียงการแยกเงื่อนไขเท่านั้น เนื่องจากไม่ได้ใช้ LLM จึงแทบไม่มี Latency เพิ่มเติม

สถานการณ์ที่เหมาะสม

Static Routing จะแสดงประสิทธิภาพได้ดีที่สุดในกรณีที่ประเภทของงานถูกกำหนดไว้ล่วงหน้าในขั้นตอนการทำงาน (Workflow) แล้ว

• แอปพลิเคชันด้านการผลิตและหน้างาน: การวิเคราะห์เบื้องต้นของสัญญาณเตือนอุปกรณ์จะประมวลผลแบบ Offline ด้วย SLM และส่งเฉพาะการยกระดับการตัดสินความผิดปกติไปยัง Cloud เท่านั้น
• ฝ่ายบริการลูกค้า: ให้ SLM รับผิดชอบการตอบ FAQ และ Routing เฉพาะการจัดการข้อร้องเรียนหรือคำถามที่ซับซ้อนไปยัง Cloud LLM
• อุตสาหกรรมที่มีข้อกำหนดด้าน Compliance ชัดเจน: ข้อมูลที่รวมถึงข้อมูลส่วนบุคคลจะถูกกำหนดให้อยู่บนอุปกรณ์ (On-device) เสมอ เพื่อป้องกันการส่งข้อมูลออกภายนอกเชิงโครงสร้าง

ข้อควรระวัง

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

Dynamic Routing คือกลไกที่ประเมินคะแนนความเชื่อมั่น (Confidence Score) ของ SLM แบบเรียลไทม์ และจะส่งต่อ (Escalate) ไปยัง Cloud LLM ก็ต่อเมื่อคะแนนไม่ผ่านเกณฑ์ที่กำหนดเท่านั้น หัวใจสำคัญของการนำไปใช้งานมี 2 ประการ คือ "ตรรกะการตัดสินความเชื่อมั่น" (Confidence Judgment Logic) และ "ตัวกระตุ้นการสำรองข้อมูล" (Fallback Trigger)

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

1. SLM ดำเนินการอนุมาน (Inference) และคำนวณคะแนนความเชื่อมั่นจากผลลัพธ์ Softmax หรือ Log Probability
2. หากคะแนนต่ำกว่าเกณฑ์ที่ตั้งไว้ (เช่น 0.85) ให้ส่งต่อ Prompt เดียวกันไปยัง Cloud LLM
3. แคช (Cache) การตอบกลับจาก Cloud LLM เพื่อป้องกันการส่งต่อซ้ำสำหรับคำถามที่คล้ายคลึงกัน

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

ตัวชี้วัดหลักที่ควรเฝ้าระวัง

• อัตราการส่งต่อ (Escalation Rate): สัดส่วนที่ถูกส่งไปยัง Cloud หากเพิ่มขึ้นอย่างรวดเร็วอาจเป็นสัญญาณของ SLM ที่เสื่อมประสิทธิภาพหรือเกิด Data Drift
• การกระจายตัวของ Latency: แยกวัดเวลาการตอบสนองระหว่างการประมวลผลด้วย SLM เพียงอย่างเดียวกับการประมวลผลหลังการส่งต่อ
• การแลกเปลี่ยนระหว่างต้นทุนและความแม่นยำ (Cost-Accuracy Trade-off): คำนวณจากอัตราการส่งต่อคูณกับปริมาณ Token ที่ใช้ เพื่อตรวจสอบ AI ROI เป็นรายสัปดาห์
• อัตราการตรวจพบอาการประสาทหลอน (Hallucination Detection Rate): ผสานการตรวจสอบ Grounding เพื่อเปรียบเทียบคุณภาพผลลัพธ์ระหว่าง SLM และ Cloud LLM

ควรออกแบบโดยใช้เครื่องมือ AI Observability และตั้งค่าการแจ้งเตือนอัตโนมัติหากอัตราการส่งต่อเกินค่ามาตรฐานในช่วงเวลาที่กำหนด ทั้งนี้ ค่ามาตรฐานจำเป็นต้องตั้งค่าและตรวจสอบตามกรณีการใช้งานขององค์กร การปรับเทียบ (Recalibration) ค่าเกณฑ์อย่างสม่ำเสมอเพื่อให้สอดคล้องกับการอัปเดตเวอร์ชันของโมเดลและการเปลี่ยนแปลงของข้อมูลเฉพาะทาง (Domain Data) ถือเป็นกุญแจสำคัญในการดำเนินงานอย่างต่อเนื่อง

ก่อนที่จะเริ่มนำการออกแบบแบบไฮบริด (Hybrid Design) มาใช้งานจริง การจัดระเบียบเกณฑ์การตัดสินใจบางประการจะช่วยลดการแก้ไขงานในขั้นตอนถัดไปได้ การเลือกนโยบายการกำหนดเส้นทาง (Routing Policy) ที่สามารถตอบโจทย์ทั้งการประมาณการต้นทุน เป้าหมายด้านความหน่วง (Latency) และข้อกำหนดด้านการปกป้องข้อมูลไปพร้อมกันนั้น จะเป็นตัวกำหนดคุณภาพของการออกแบบ ในหัวข้อ H3 ถัดไป เราจะเจาะลึกถึงประเด็นที่มักถูกมองข้ามแต่มีความสำคัญอย่างยิ่ง นั่นคือการปรับให้สอดคล้องกับแนวทางปฏิบัติ (Guardrails) และนโยบายการกำกับดูแล (Governance Policy) ที่มีอยู่เดิม

เมื่อนำการออกแบบแบบไฮบริด (Hybrid Design) มาใช้ หากไม่มีการตรวจสอบความสอดคล้องกับแนวทางปฏิบัติ (Guardrails) และระบบธรรมาภิบาล (Governance) ที่มีอยู่ก่อนล่วงหน้า มักจะนำไปสู่ปัญหาด้านการปฏิบัติตามกฎระเบียบ (Compliance) ที่รุนแรงหลังเริ่มใช้งานจริง เนื่องจาก Cloud LLM และ On-device SLM มีขอบเขตของนโยบายที่ต้องนำมาใช้แตกต่างกัน จึงจำเป็นต้องมีกลไกการบริหารจัดการแบบรวมศูนย์

ประเด็นสำคัญที่ต้องตรวจสอบ

• ความสอดคล้องกับนโยบายการจำแนกข้อมูล (Data Classification Policy): กำหนดกฎการจัดเส้นทาง (Routing Rules) ให้ชัดเจนตามระดับความลับที่บริษัทกำหนด (เช่น ลับที่สุด, ลับเฉพาะ, เผยแพร่ได้) โดยต้องตั้งค่า Router ให้ส่งเฉพาะข้อมูลที่มีความลับระดับสูงไปยัง On-device SLM เท่านั้น
• การปฏิบัติตาม EU AI Act และแนวทางของ NIST (NIST AI RMF): งานที่ถูกตัดสินว่าเป็นงานที่มีความเสี่ยงสูง อาจจำเป็นต้องมีการเก็บรักษาบันทึกการตรวจสอบ (Audit Log) แม้ว่าจะผ่าน Cloud LLM ก็ตาม ดังนั้นจึงต้องออกแบบจุดจัดเก็บ Log และสิทธิ์การเข้าถึงไว้ล่วงหน้า
• สายการรายงานต่อคณะกรรมการธรรมาภิบาล AI (AI Governance Committee): การเปลี่ยนแปลงเกณฑ์การตัดสินใจในการจัดเส้นทาง (Routing) ต้องรวมอยู่ในขั้นตอนการอนุมัติของคณะกรรมการธรรมาภิบาล หากละเลยการจัดการการเปลี่ยนแปลง อาจเสี่ยงต่อการเกิดสภาวะใกล้เคียงกับ Shadow AI
• การใช้ Guardrails ซ้ำซ้อน: การติดตั้ง Prompt Firewall หรือ Grounding Check แยกกันทั้งใน SLM และ LLM จะทำให้ต้นทุนการประมวลผลเพิ่มขึ้น การออกแบบโดยวางชั้น Guardrails ส่วนกลางไว้หน้า Router เพื่อลดความซ้ำซ้อนถือเป็นวิธีที่มีประสิทธิภาพ

ยิ่งดำเนินการตรวจสอบความสอดคล้องในช่วงเริ่มต้นของการออกแบบมากเท่าใด ก็จะยิ่งลดการแก้ไขงานภายหลังได้มากเท่านั้น การจัดทำเอกสารตรรกะการจัดเส้นทาง (Routing Logic) โดยอ้างอิงจากกรอบการทำงาน AI TRiSM ที่มีอยู่และนโยบายความปลอดภัยของบริษัท จะช่วยลดความซับซ้อนในการรองรับการตรวจสอบ (Audit) ในอนาคตได้อย่างมาก

เมื่อพิจารณาและเริ่มนำการออกแบบแบบไฮบริด (Hybrid Design) มาใช้งานจริง คำถามต่างๆ มักจะเกิดขึ้นตามมา เช่น "จะสร้าง Router อย่างไร" หรือ "จะรับมืออย่างไรหาก SLM ตัดสินใจผิดพลาด" ในส่วนนี้ เราจะหยิบยกคำถามที่พบบ่อยในหน้างานด้านการออกแบบและการดำเนินงานมาตอบอย่างกระชับ การทำความเข้าใจข้อสงสัยให้ชัดเจนก่อนเริ่มการติดตั้งใช้งานจริง จะช่วยให้การตัดสินใจในขั้นตอนต่อไปเป็นไปอย่างราบรื่น

วิธีการใช้งานเราเตอร์ (Router) แบ่งออกเป็น 2 ประเภทหลัก ได้แก่ "แบบใช้กฎ (Rule-based)" และ "แบบใช้ LLM (LLM-based)" ซึ่งแต่ละประเภทมีสถานการณ์ที่เหมาะสมแตกต่างกันไป จึงไม่จำเป็นต้องเลือกใช้อย่างใดอย่างหนึ่งเพียงอย่างเดียว

เราเตอร์แบบใช้กฎ (Rule-based Router)

• ใช้การแบ่งเงื่อนไขตามจำนวนโทเค็น, เอนด์พอยต์ (Endpoint), หรือคำสำคัญ (Keyword)
• การใช้งานมีน้ำหนักเบา และค่าความหน่วง (Latency) ของตัวเราเตอร์เองเกือบจะเป็นศูนย์
• เงื่อนไขมีความตายตัว หากต้องการรองรับประเภทงานใหม่ๆ จำเป็นต้องอัปเดตด้วยตนเอง

เราเตอร์แบบใช้ LLM (LLM-based Router)

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

ในการออกแบบจริง การใช้ "โครงสร้างสองชั้น" โดยเริ่มจากการคัดกรองคร่าวๆ ด้วยกฎ แล้วจึงส่งเฉพาะกรณีที่ตัดสินใจได้ยากไปยัง SLM ถือเป็นวิธีที่มีประสิทธิภาพ ตัวอย่างเช่น หากเข้าเงื่อนไข "จำนวนโทเค็นไม่เกินที่กำหนดและไม่มีการตั้งค่าสถานะความลับ" ให้ส่งไปยัง SLM บนอุปกรณ์ (On-device SLM) ทันที แต่หากไม่เข้าเงื่อนไขดังกล่าว ให้ตัวจำแนกประเภทแบบ LLM-based ประเมินเจตนาก่อนส่งไปยัง Cloud LLM

สรุปแนวทางในการเลือกใช้ได้ดังนี้:

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

การออกแบบแบบไฮบริดระหว่าง Cloud LLM และ On-device SLM เป็นแนวทางที่สมเหตุสมผลในการเพิ่มประสิทธิภาพทั้งสามด้านไปพร้อมกัน ได้แก่ ต้นทุน (Cost) ความหน่วง (Latency) และการปฏิบัติตามกฎระเบียบ (Compliance) เพราะหากพึ่งพาเพียงอย่างใดอย่างหนึ่ง ย่อมต้องมีการประนีประนอมในด้านใดด้านหนึ่งอย่างหลีกเลี่ยงไม่ได้

เมื่อย้อนกลับไปดูกลยุทธ์การกำหนดเส้นทาง (Routing Strategy) ที่อธิบายไว้ในบทความนี้ สามารถแบ่งทางเลือกออกเป็น 3 รูปแบบหลัก ดังนี้:

• Static Routing: กำหนดการใช้งาน Cloud หรือ On-device ไว้ล่วงหน้าตามประเภทของงาน มีความเรียบง่ายในการดำเนินงานและต้นทุนการนำไปใช้ต่ำ
• Dynamic Routing (Cascade): พิจารณาจากคะแนนความเชื่อมั่น (Confidence Score) ของ SLM เพื่อส่งต่อ (Escalate) ไปยัง Cloud LLM ช่วยปรับสมดุลระหว่างความแม่นยำและต้นทุนได้โดยอัตโนมัติ
• SLM Draft → Cloud LLM Verification: เหมาะสำหรับงานสร้างเนื้อหา (Generation Task) ที่ต้องการทั้งความเร็วและคุณภาพที่รับประกันได้

ในฐานะจุดเริ่มต้นของการออกแบบ ขอแนะนำให้ระบุให้ชัดเจนก่อนว่า "งานใดบ้างที่เกี่ยวข้องกับข้อมูลที่เป็นความลับ" เมื่อข้อกำหนดด้าน Compliance ชัดเจนแล้ว ขอบเขตของการประมวลผลบนอุปกรณ์ (On-device) จะถูกกำหนดโดยธรรมชาติ และปริมาณ Token ที่ส่งไปยัง Cloud ก็จะลดลงด้วย

ถัดมาคือการรวม Guardrails และนโยบาย AI Governance เข้าไว้ที่ส่วนต้นน้ำ (Upstream) ของ Router เนื่องจากตัวการตัดสินใจของ Routing เองอาจกลายเป็นจุดเสี่ยงใหม่ได้ จึงจำเป็นต้องมีระบบตรวจสอบบันทึกการตัดสินใจอย่างต่อเนื่องด้วยกลไก AI Observability

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