Pisahkan cubaan semula daripada fallback
Cubaan semula menghantar permintaan ke laluan yang sama sekali lagi kerana kegagalan mungkin bersifat sementara. Fallback menukar pembekal atau model kerana laluan asal tidak tersedia atau tidak sesuai.
Menganggap kedua-dua tindakan ini sebagai satu gelung cubaan semula generik menjadikan insiden lebih sukar didiagnosis dan boleh menggandakan kos tanpa meningkatkan kadar kejayaan.
- Cubaan semula: tamat masa, tetapan semula sambungan, 429 atau respons 5xx sementara.
- Fallback: kegagalan pembekal berulang, isu kapasiti model atau sekatan dasar.
- Henti: permintaan tidak sah, parameter tidak disokong atau pengesahan output gagal.
Bina jadual laluan yang serasi dengan keupayaan
Model fallback harus dikelompokkan mengikut keupayaan, bukan jenama. Permintaan penglihatan tidak boleh fallback ke model teks sahaja, dan aliran kerja JSON yang ketat tidak sepatutnya dialihkan ke model yang kerap melanggar skema.
- Mod input dan output yang diperlukan.
- Konteks minimum dan panjang output.
- Sokongan panggilan alat dan output berstruktur.
- Harga dan latensi maksimum yang boleh diterima.
Gunakan satu bajet di peringkat permintaan
Bajet permintaan harus meliputi setiap cubaan semula dan percubaan fallback. Sebelum memulakan percubaan lain, semak sama ada baki bajet latensi dan kos masih mampu menyokongnya.
const routePolicy = {
maxAttempts: 3,
maxLatencyMs: 18_000,
maxEstimatedCost: 0.12,
retryOn: [408, 429, 500, 502, 503, 504],
fallbackModels: ['primary-model', 'quality-fallback', 'fast-fallback'],
};Ukur kualiti fallback, bukan hanya ketersediaan
Permintaan yang kembali berjaya masih boleh menjadi kegagalan produk. Jejaki pengesahan output, kadar pembetulan pengguna dan penyelesaian tugas selepas peristiwa fallback.
Papan pemuka yang disyorkan: kejayaan laluan, kadar fallback, latensi p95, kos anggaran, kadar lulus pengesahan dan skor kualiti mengikut model.
