Retry мен fallback-ты бөліңіз
Retry сұрауды сол маршрутқа қайта жібереді, өйткені қате уақытша болуы мүмкін. Fallback provider немесе model-ді өзгертеді, өйткені бастапқы маршрут қолжетімсіз немесе жарамсыз.
Осы екі әрекетті бір жалпы retry циклі ретінде қарастыру инциденттерді талдауды қиындатады және сәттілік деңгейін жақсартпай-ақ шығынды көбейте алады.
- Retry: timeout, connection reset, 429 немесе уақытша 5xx response.
- Fallback: провайдердің қайталанған істен шығуы, model capacity мәселесі немесе policy шектеуі.
- Тоқау: жарамсыз сұрау, қолдау көрсетілмейтін параметр немесе output validation сәтсіздігі.
Capability-мен үйлесімді route table құрыңыз
Fallback model-дер бренд бойынша емес, capability бойынша топтастырылуы керек. Vision сұрауы text-only model-ге fallback жасай алмайды, ал қатаң JSON workflow схеманы жиі бұзатын model-ге бағытталмауы тиіс.
- Қажетті input және output modality-лері.
- Ең аз context және output ұзындығы.
- Tool calling және structured-output қолдауы.
- Рұқсат етілетін ең жоғары price және latency.
Бір request-level бюджет қолданыңыз
Request бюджеті әр retry және fallback әрекетін қамтуы тиіс. Келесі әрекетті бастамас бұрын, қалған latency және cost бюджеті оны қолдай алатынын тексеріңіз.
const routePolicy = {
maxAttempts: 3,
maxLatencyMs: 18_000,
maxEstimatedCost: 0.12,
retryOn: [408, 429, 500, 502, 503, 504],
fallbackModels: ['primary-model', 'quality-fallback', 'fast-fallback'],
};Тек availability емес, fallback сапасын да өлшеңіз
Сәтті қайтқан сұрау да өнімдік сәтсіздік болуы мүмкін. Fallback оқиғасынан кейін output validation, пайдаланушы түзетуі және task completion көрсеткіштерін қадағалаңыз.
Ұсынылатын dashboard: route success, fallback rate, p95 latency, estimated cost, validation pass rate және model бойынша quality score.
