แยกการลองใหม่ออกจากการสำรอง
การลองใหม่คือการส่งคำขอไปยังเส้นทางเดิมอีกครั้ง เนื่องจากข้อผิดพลาดอาจเกิดขึ้นเพียงชั่วคราว ส่วนการสำรองคือการเปลี่ยนผู้ให้บริการหรือโมเดล เนื่องจากเส้นทางเดิมไม่พร้อมใช้งานหรือไม่เหมาะสม
การปฏิบัติต่อทั้งสองการดำเนินการเป็นลูปการลองใหม่แบบทั่วไป จะทำให้วิเคราะห์เหตุการณ์ขัดข้องได้ยากขึ้น และอาจทำให้ต้นทุนเพิ่มขึ้นโดยไม่เพิ่มอัตราความสำเร็จ
- ลองใหม่: timeout, การรีเซ็ตการเชื่อมต่อ, 429 หรือการตอบกลับ 5xx ชั่วคราว
- สำรอง: ผู้ให้บริการขัดข้องซ้ำ ปัญหาความจุของโมเดล หรือข้อจำกัดด้านนโยบาย
- หยุด: คำขอไม่ถูกต้อง พารามิเตอร์ที่ไม่รองรับ หรือการตรวจสอบผลลัพธ์ไม่ผ่าน
สร้างตารางเส้นทางที่สอดคล้องกับความสามารถ
ควรจัดกลุ่มโมเดลสำรองตามความสามารถ ไม่ใช่ตามแบรนด์ คำขอด้านการมองเห็นไม่สามารถเปลี่ยนไปใช้โมเดลที่รองรับเฉพาะข้อความได้ และเวิร์กโฟลว์ JSON แบบเข้มงวดไม่ควรกำหนดเส้นทางไปยังโมเดลที่ละเมิด schema เป็นประจำ
- รูปแบบข้อมูลนำเข้าและผลลัพธ์ที่จำเป็น
- ความยาวบริบทและผลลัพธ์ขั้นต่ำ
- การรองรับการเรียกใช้เครื่องมือและผลลัพธ์แบบมีโครงสร้าง
- ราคาและเวลาแฝงสูงสุดที่ยอมรับได้
ใช้งบประมาณเดียวในระดับคำขอ
งบประมาณของคำขอควรครอบคลุมการลองใหม่และการสำรองทุกครั้ง ก่อนเริ่มการพยายามครั้งถัดไป ให้ตรวจสอบว่างบประมาณด้านเวลาแฝงและต้นทุนที่เหลืออยู่เพียงพอที่จะรองรับหรือไม่
const routePolicy = {
maxAttempts: 3,
maxLatencyMs: 18_000,
maxEstimatedCost: 0.12,
retryOn: [408, 429, 500, 502, 503, 504],
fallbackModels: ['primary-model', 'quality-fallback', 'fast-fallback'],
};วัดคุณภาพของการสำรอง ไม่ใช่เฉพาะความพร้อมใช้งาน
คำขอที่ส่งกลับผลลัพธ์สำเร็จอาจยังถือเป็นความล้มเหลวของผลิตภัณฑ์ได้ ติดตามการตรวจสอบผลลัพธ์ อัตราการแก้ไขโดยผู้ใช้ และการทำงานสำเร็จของภารกิจหลังเกิดเหตุการณ์สำรอง
แดชบอร์ดที่แนะนำ: ความสำเร็จของเส้นทาง อัตราการสำรอง เวลาแฝง p95 ต้นทุนโดยประมาณ อัตราการตรวจสอบผ่าน และคะแนนคุณภาพแยกตามโมเดล