Fallback

Fallback คือแผนสำรองที่ระบบสลับไปใช้เองเมื่อทางหลักทำงานไม่สำเร็จ ในงาน AI คำนี้มักหมายถึงการเตรียม model สำรองไว้เป็นลำดับ พอตัวแรกตอบไม่ได้ ระบบจะส่งคำขอเดิมต่อไปยังตัวถัดไปให้อัตโนมัติโดยที่คนใช้งานไม่ต้องมานั่งกดใหม่เอง เอกสาร Model Fallbacks ของ openrouter อธิบายพารามิเตอร์ชื่อ models ว่ารับรายการ model ID เรียงตามลำดับความสำคัญ และเขียนไว้ว่าถ้า model ตัวแรกคืน error ระบบจะลอง model ตัวถัดไปในรายการให้เอง ฝั่ง Cloudflare AI Gateway มีของทำนองเดียวกันในชื่อ Fallbacks โดยหน้าเอกสาร Fallbacks ระบุว่ากำหนด model หรือผู้ให้บริการสำรองไว้กับ Universal endpoint ได้เพื่อรับมือคำขอที่ล้มเหลวและรักษาความน่าเชื่อถือของบริการ

หัวใจของเรื่องนี้อยู่ที่เงื่อนไขว่ากลไกทำงานกับกรณีไหนและไม่ทำงานกับกรณีไหน หน้า Model Fallbacks ของ OpenRouter เขียนว่าโดยค่าเริ่มต้น error แบบใดก็กระตุ้นให้ใช้ model สำรองได้ รวมถึง error เรื่องความยาว context การติด moderation flag ในกรณี model ที่มีการกรอง การชนเพดานเรียกใช้อย่าง rate-limit และช่วงที่บริการล่ม แต่หน้าเดียวกันเขียนกำกับไว้ด้วยว่าถ้า model สำรองล่มหรือคืน error ด้วย OpenRouter จะส่ง error นั้นกลับไปให้ผู้เรียก เรื่องค่าใช้จ่ายก็ระบุไว้ว่าคิดราคาตาม model ที่ได้ใช้จริง และคืนชื่อตัวนั้นไว้ในฟิลด์ model ของ response แปลว่าต้นทุนต่อคำขอขยับตามตัวสำรองที่วิ่งแทน ซึ่งควรนับรวมตอนประเมิน total-cost-of-ownership หน้าเดียวกันยังมีพารามิเตอร์อีกตัวชื่อ fallbacks ซึ่งเอกสารระบุว่าใช้กับ endpoint ของ Anthropic Messages API ที่ /api/v1/messages โดยรับได้มากสุด 3 รายการ ถ้ายาวกว่านั้นจะได้ error 400 ใช้พร้อมกับพารามิเตอร์ models ไม่ได้ ส่งมาทั้งคู่ก็ได้ 400 เหมือนกัน และแต่ละรายการรับเฉพาะฟิลด์ model เท่านั้น ฝั่ง Cloudflare เงื่อนไขกว้างออกไปอีกนิด หน้า Fallbacks บอกว่า Cloudflare สั่งใช้ผู้ให้บริการสำรองได้ทั้งตอนคำขอคืน error และตอนชนเวลารอที่กำหนดไว้ล่วงหน้า ซึ่งแปลว่า latency ที่สูงผิดปกติก็เป็นเหตุให้สลับได้เหมือนกัน โดยค่าเริ่มต้นนั้นระบบจะสลับเมื่อคำขอคืน error และหน้าเดียวกันยังบอกว่ามี response header ชื่อ cf-aig-step ที่ระบุว่าคำขอนั้นจบที่ชั้นไหน ค่า 0 คือ model ตัวหลักทำงานสำเร็จ ค่า 1 คือตกไปตัวที่สอง ค่า 2 คือตกไปตัวที่สาม และเพิ่มทีละ 1 ตามชั้นสำรองที่เพิ่มเข้าไป

คนทำงานเจอคำนี้ตอนที่ระบบซึ่งต้องเดินทุกวันเริ่มมีคนพึ่งพาจริง เช่น agent ที่รันงานเป็นชุดตอนกลางคืน หรือผู้ช่วยตอบลูกค้าที่ทั้งทีมใช้ ข้อควรระวังข้อแรกคือการมี fallback ไม่ได้แปลว่าระบบจะไม่ล้ม เพราะเมื่อตัวสำรองล้มด้วย error ก็เด้งกลับมาถึงผู้เรียกอยู่ดีตามที่ OpenRouter เขียนไว้ ข้อสองคือคำตอบที่ได้ในวันนั้นอาจมาจาก model คนละตัวกับที่ทีมทดสอบไว้ สำนวน รูปแบบผลลัพธ์ และราคาจึงต่างจากที่คาด ทางแก้คือทดสอบตัวสำรองด้วยเหมือนกัน และดูชื่อ model ที่ระบบคืนมาว่าวิ่งบนตัวไหน ข้อสามคือกลไกฝั่งผู้ให้บริการย้ายบ้านได้ หน้า Universal Endpoint ของ Cloudflare AI Gateway ประกาศว่า Universal Endpoint เลิกใช้แล้ว ให้ใช้ endpoint ที่เข้ากันได้กับ openai สำหรับการต่อใหม่ และใช้ Dynamic Routing สำหรับ fallback, retry และการ route แบบมีเงื่อนไข แต่ประโยคถัดมาบอกด้วยว่า Universal Endpoint จะยังทำงานต่อสำหรับระบบที่ต่อไว้อยู่แล้ว ประกาศแบบนี้คือเหตุผลที่ต้องอ่านข่าว model-deprecation ให้จบทั้งย่อหน้าก่อนตกใจ ส่วนของใหม่ที่เขาชี้ให้ไปใช้นั้น หน้า Dynamic Routing อธิบายว่าผังการวิ่งของคำขอประกอบด้วย node หลายชนิด ในนั้นมี node ชนิด Rate Limit ที่บังคับเพดานจำนวนคำขอต่อ key ต่อช่วงเวลาและสลับไปใช้ fallback เมื่อใช้เกินเพดาน กับ node ชนิด Budget Limit ที่บังคับเพดานค่าใช้จ่ายต่อ key ต่อช่วงเวลาและสลับไปใช้ fallback เมื่อเกินเช่นกัน

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

หัวหน้าฝ่ายปฏิบัติการ: ทีม IT บอกว่าระบบสรุปเอกสารของเราตั้ง fallback ไว้เรียบร้อยแล้ว แปลว่าต่อไปนี้ต่อให้เจ้าของ model ล่ม งานเราก็ไม่สะดุดใช่ไหมคะ

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

หัวหน้าฝ่ายปฏิบัติการ: แล้ววันที่มันสลับไปตัวสำรอง เราจะรู้ได้ยังไงคะ กลัวคุณภาพงานเปลี่ยนแล้วไม่มีใครเห็น

ทีม IT: ดูจากชื่อ model ที่ระบบคืนกลับมาพร้อมคำตอบครับ OpenRouter คืนไว้ในฟิลด์ model และคิดเงินตามตัวที่ใช้จริง ส่วน Cloudflare AI Gateway มี header ชื่อ cf-aig-step บอกเป็นตัวเลขว่าคำขอนั้นจบที่ชั้นสำรองที่เท่าไร ผมจะเก็บสองค่านี้ไว้ดูรายสัปดาห์ให้

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

• model-routing : routing คือการตัดสินใจตั้งแต่ต้นทางว่าคำขอนี้ควรวิ่งไปที่ model หรือผู้ให้บริการรายไหน ส่วน fallback คือแผนที่เพิ่งเริ่มทำงานหลังจากทางที่เลือกไว้ล้มไปแล้ว จึงเป็นคนละจังหวะของเรื่องเดียวกัน
• kill-switch : kill switch คือการสั่งหยุดโดยตั้งใจเมื่อเห็นว่าระบบทำอะไรผิดพลาด เป้าหมายคือให้หยุด ส่วน fallback มีเป้าหมายตรงข้ามคือพยายามให้งานเดินต่อด้วยทางสำรอง
• guardrails : guardrails คือกติกาที่กันไม่ให้ระบบทำหรือพูดสิ่งที่ไม่ควร ส่วน fallback ไม่ได้ตัดสินว่าคำตอบเหมาะสมหรือไม่ หน้าที่มันคือหาทางให้คำขอสำเร็จ แม้ว่าการติด moderation flag ในกรณี model ที่มีการกรองจะเป็นหนึ่งในเหตุที่ OpenRouter ระบุว่ากระตุ้นให้สลับตัวได้ก็ตาม