การเลือกโมเดลภาษาขนาดใหญ่ (LLM) หลักอาจใช้เวลาเพียงช่วงบ่าย แต่การจัดการกับสิ่งที่เกิดขึ้นเมื่อมันล้มเหลวต่างหากคืองานวิศวกรรมที่แท้จริง

ทีมส่วนใหญ่มักจะปรับแต่งระบบเพื่อรองรับเฉพาะกรณีที่ทุกอย่างราบรื่น (happy path) พวกเขาทำการทดสอบความแม่นยำบนชุดข้อมูลที่สะอาด ปรับแต่ง prompt กับอินพุตที่สมบูรณ์แบบ และเริ่มใช้งานด้วยความมั่นใจ แต่เมื่อทราฟฟิกในระบบจริงมาถึง โมเดลเริ่มใช้เวลานานเกินไป (timeout) ในช่วงเวลาที่มีการใช้งานสูงสุด ส่งคืน JSON ที่รูปแบบผิดพลาดในเย็นวันศุกร์ หรือจู่ๆ ค่าใช้จ่ายก็พุ่งสูงขึ้นถึงสามเท่าหลังจากการอัปเดตราคา ฟีเจอร์ AI ที่คุณออกแบบมาอย่างดีอาจกลายเป็นภาระ เพราะไม่มีใครวางแผนรับมือเมื่อโมเดลเกิดปัญหา

ในแอปพลิเคชันที่ใช้หลายโมเดล (multi-model) อย่างจริงจัง กฎการสำรอง (fallback rules) ไม่ใช่สิ่งที่คิดขึ้นมาทีหลัง แต่มันคือโครงสร้างพื้นฐานหลัก พฤติกรรมของระบบเมื่อโมเดลหลักสะดุดจะเป็นตัวตัดสินว่าผู้ใช้จะยังอยู่หรือจะจากไป

เริ่มต้นด้วยสัญญาณความล้มเหลวที่ชัดเจน

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

คอยเฝ้าระวัง API timeout เมื่อ endpoint ของผู้ให้บริการค้าง คอยดูข้อผิดพลาดด้านขีดจำกัดการใช้งาน (rate limit errors) — มักจะเป็น HTTP 429 — ซึ่งจะเกิดขึ้นเมื่อมีการใช้งานพุ่งสูงขึ้นหรือถึงโควตารายเดือน คอยดูเอาต์พุต JSON ที่ไม่ถูกต้องซึ่งทำให้ pipeline การ parse ข้อมูลของคุณพัง คอยดูการตอบกลับที่ว่างเปล่าหรือไม่สมบูรณ์ซึ่งดูเหมือนจะสำเร็จในระดับ HTTP แต่ไม่มีเนื้อหาที่ใช้งานได้ คอยดูความหน่วงสูง (high latency) ที่ทำให้ประสบการณ์การแชทแย่ลงก่อนที่จะเกิด timeout จริงๆ คอยดูข้อมูลที่เกินขีดจำกัดความยาวบริบท (context length overflow) เมื่ออินพุตของผู้ใช้ยาวเกินหน้าต่างบริบทของโมเดล และคอยดูความแม่นยำที่ลดลง (quality regression) ซึ่งเป็นความล้มเหลวที่แนบเนียนที่สุด: โมเดลยังตอบกลับอยู่ แต่คำตอบเริ่มออกนอกลู่นอกทาง คลุมเครือ หรือเพิกเฉยต่อคำสั่งการจัดรูปแบบหลังจากมีการอัปเดตจากฝั่งผู้ให้บริการ

สัญญาณแต่ละอย่างควรส่งผลให้เกิดการตอบสนองที่แตกต่างกัน การ timeout ควรใช้วิธีลองใหม่ (retry) JSON ที่ผิดพลาดควรเปลี่ยนโมเดล ส่วนข้อจำกัดด้าน rate limit อาจหมายความว่าคุณต้องเปลี่ยนไปใช้ผู้ให้บริการรายอื่นไปเลย

ปรับการสำรองให้เข้ากับเวิร์กโฟลว์

การใช้กฎการสำรองแบบเดียวกันกับทุกงานคือหนทางสู่หายนะ แชทบอทและงานดึงข้อมูลเบื้องหลัง (background data extraction) มีความต้องการที่ตรงกันข้ามกัน จงออกแบบการสำรองของคุณตามเวิร์กโฟลว์ที่เฉพาะเจาะจง

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

RAG systems ต้องการความแม่นยำ คุณได้จ่ายต้นทุนสำหรับการดึงข้อมูล (retrieval) ไปแล้ว — ทั้งการค้นหาแบบ vector, การจัดลำดับใหม่ (reranking), หรืออาจรวมถึงการทำ web crawling หากตัวสร้าง (generator) ไม่สามารถปฏิบัติตามบริบทที่ให้ไว้ งานทั้งหมดนั้นก็สูญเปล่า ให้สำรองด้วยโมเดลที่มีชื่อเสียงด้านการปฏิบัติตามคำสั่งที่แม่นยำและการทำความเข้าใจบริบทที่ยาว (long-context comprehension) แม้ว่ามันจะทำงานช้ากว่าก็ตาม

Coding tools ต้องการตรรกะ นักพัฒนาต้องการไวยากรณ์ที่ถูกต้องและการเรียกใช้ API ที่ใช้งานได้จริง มากกว่าคำอธิบายที่สละสลวย หากโมเดลหลักเริ่มสร้างฟังก์ชันที่ไม่มีอยู่จริง (hallucinating) หรือข้ามกรณีขอบเขต (edge cases) ให้เปลี่ยนไปใช้โมเดลที่ถูกปรับแต่งมาเพื่อการเขียนโค้ดโดยเฉพาะ ยอมรับความหน่วงที่สูงขึ้นเพื่อแลกกับเอาต์พุตที่พร้อมนำไปคอมไพล์ได้

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

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

รู้ข้อจำกัดของคุณก่อนที่จะเปลี่ยน

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

ก่อนที่คุณจะยกระดับโมเดลใดให้เป็นสถานะสำรอง (fallback status) จงตรวจสอบโมเดลนั้นเทียบกับปัจจัย 6 ประการ

  • ความสามารถของโมเดล: มันสามารถจัดการกับประเภทของ prompt ได้จริง หรือจะล้มเหลวในรูปแบบอื่น?
  • การรองรับภาษา: โมเดลสำรองของคุณอาจทำได้ดีเยี่ยมในภาษาอังกฤษ แต่อาจเกิดอาการหลอน (hallucinate) ในภาษาฮินดี สเปน หรือญี่ปุ่น
  • ขนาดของ Context window: หากอินพุตของคุณมี 50,000 tokens โมเดลสำรองที่มีขีดจำกัดเพียง 16,000 tokens จะทำการตัดข้อความ (truncate) และทำลายความหมายไปโดยไม่รู้ตัว
  • ความหน่วง (Latency): ผู้ให้บริการบางรายมีความเร็วที่สม่ำเสมอกว่ารายอื่นในภูมิภาคของคุณ
  • ต้นทุนต่อคำขอ (Cost per request): กำหนดเพดานสูงสุดไว้ และต้องรู้ว่าโมเดลสำรองจะมีค่าใช้จ่ายเท่าใดในช่วงที่มีปริมาณการใช้งานสูงสุด
  • ความน่าเชื่อถือของผลลัพธ์ (Output reliability): มันจะทำตามรูปแบบผลลัพธ์ที่กำหนดไว้ทุกครั้ง หรือจะทำแค่บางวัน?

รูปแบบการทำ Fallback 4 แบบที่ใช้งานได้จริง

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

Retry fallback. สำหรับข้อผิดพลาดทางเครือข่ายชั่วคราวหรือการหยุดชะงักสั้นๆ ของผู้ให้บริการ ให้ลองใช้โมเดลเดิมซ้ำด้วยวิธี exponential backoff อย่าลองซ้ำเมื่อผลลัพธ์ผิดรูปแบบ (malformed output) หรือเกิด context overflow เพราะการส่ง prompt ที่แย่แบบเดิมซ้ำสองแทบจะไม่ช่วยอะไรเลย

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

Cheaper fallback. สำรองโมเดลที่มีราคาถูกไว้สำหรับงานที่ไม่สำคัญ หากตัวเลือกราคาถูกทำงานได้ไม่ดี ให้ลดระดับฟีเจอร์ลงอย่างนุ่มนวล (degrade gracefully) แทนที่จะต้องเสีย token ราคาแพงไปกับงานที่มีมูลค่าต่ำ

Stronger fallback. ฟังดูเหมือนจะสวนทางกัน แต่นี่เป็นสิ่งจำเป็น เมื่อโมเดลระดับกลางล้มเหลวในการจัดการกับเหตุผลที่ซับซ้อน (complex reasoning), การคำนวณหลายขั้นตอน หรือการวิเคราะห์ทางกฎหมายที่ละเอียดอ่อน ให้ยกระดับไปใช้โมเดลที่มีความสามารถสูงกว่า ใช้แนวทางนี้อย่างประหยัดสำหรับเส้นทางของผู้ใช้ที่มีมูลค่าสูง ซึ่งความแม่นยำจะช่วยปกป้องรายได้หรือความปลอดภัย

ฝังตรรกะไว้ในสถาปัตยกรรมของคุณ

อย่ากระจายตรรกะการทำ fallback ไปตามบล็อก try-catch จำนวนมากในโค้ดแอปพลิเคชัน ให้มองว่าการทำ routing เป็นส่วนหนึ่งของโครงสร้างพื้นฐาน (infrastructure) สร้างเลเยอร์ middleware ที่จับคู่ประเภทของงานเข้ากับรายการโมเดลที่เรียงลำดับไว้ โดยแต่ละโมเดลจะมีเกณฑ์เวลาหมดอายุ (timeout threshold), นโยบายการลองใหม่ (retry policy) และ circuit breaker เป็นของตัวเอง

ติดตามเหตุการณ์การทำ fallback ในฐานะเมทริกซ์ (metrics) ที่สำคัญ อัตราข้อผิดพลาด (error rates) จะบอกคุณว่าเมื่อใดที่โมเดลล่ม แต่อัตราการทำ fallback จะบอกคุณว่าเมื่อใดที่โมเดลนั้นไม่เหมาะสมกับงาน หากระบบของคุณต้องทำ fallback ถึง 30 หรือ 40 เปอร์เซ็นต์ แสดงว่าโมเดลหลักของคุณไม่สอดคล้องกับภาระงาน นั่นคือสัญญาณให้คุณประเมินการเลือกโมเดลใหม่ ไม่ใช่แค่การจัดการข้อผิดพลาดเท่านั้น

กำหนดงบประมาณที่ชัดเจน การทำ fallback ไม่ควรเป็นการเขียนเช็คเปล่า (blank check) หากคุณต้องยกระดับไปใช้โมเดลระดับพรีเมียมในช่วงที่มีภาระงานหนัก ให้จำกัดจำนวนคำขอที่ถูกยกระดับต่อนาทีไว้ด้วย ปกป้องกระเป๋าเงินของคุณด้วยความเข้มงวดเช่นเดียวกับที่คุณปกป้องเวลาทำงานของระบบ (uptime)

บททดสอบที่แท้จริง

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

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

Source: How to Design AI Model Fallback Rules for Multi-Model Apps

Community: GyaanSetu AI on Telegram