Strategi Fallback Model: Playbook 3 Workflow

Fallback model bukanlah satu perilaku. Ini adalah seperangkat keputusan pemulihan dengan batas keselamatan yang berbeda-beda.

Strategi fallback model untuk produksi harus memisahkan tiga workflow:

1. Retry atau failover ekuivalen ketika permintaan masih aman untuk diulang.
2. Fallback lintas model ketika model lain dapat memenuhi kapabilitas dan kontrak kualitas yang sama.
3. Berhenti, rekonsiliasi, atau eskalasi ketika output sudah sampai ke pengguna atau efek samping alat mungkin sudah terjadi.

Pemisahan ini penting karena tindakan pemulihan tercepat tidak selalu yang paling aman. Mengulangi permintaan klasifikasi yang gagal biasanya berisiko rendah. Beralih model secara diam-diam di tengah jawaban streaming atau setelah panggilan alat pembayaran yang tidak pasti tidaklah demikian.

Playbook ini mengubah kebijakan fallback menjadi tiga workflow operasional yang dapat diimplementasikan, diuji, dan dipantau oleh tim Anda.

Keputusan fallback model dalam satu tabel

Mulailah dari status permintaan, bukan nama penyedianya.

Aturan intinya sederhana: retry mempertahankan target, failover ekuivalen mempertahankan kontrak model, dan fallback lintas model mengubah risiko kontrak. Setiap langkah memerlukan pemeriksaan kelayakan yang lebih kuat.

Untuk pembahasan lebih mendalam tentang circuit breaker, normalisasi error, dan controller netral penyedia, lihat playbook routing fallback LLM API.

Sebelum workflow: definisikan satu envelope fallback

Setiap permintaan harus masuk ke lapisan routing dengan envelope yang dibatasi. Envelope memberi tahu sistem seberapa banyak pemulihan yang diizinkan sebelum permintaan harus berhenti.

type FallbackEnvelope = {
  requestId: string;
  deadlineMs: number;
  maxAttempts: number;
  maxAddedLatencyMs: number;
  maxCostUsd?: number;
  allowEquivalentFailover: boolean;
  allowCrossModelFallback: boolean;
  allowAfterPartialOutput: false;
  sideEffectMode: "none" | "read_only" | "write_possible";
  requiredCapabilities: string[];
  requiredSchemaVersion?: string;
};

Nilai-nilai ini harus berasal dari workflow produk, bukan dari default global. Job ringkasan di latar belakang dapat menoleransi latensi yang lebih tinggi daripada asisten coding interaktif. Jawaban chat tanpa tools dapat menoleransi perilaku pemulihan yang berbeda dibanding agen yang dapat men-deploy kode atau mengirim email.

Envelope juga mencegah retry bersarang. Jika SDK, aplikasi, gateway, dan adapter provider semuanya retry secara independen, insiden kecil bisa berlipat menjadi ledakan percobaan yang besar. Pilih satu lapisan untuk memiliki total anggaran percobaan dan wajibkan setiap lapisan di bawahnya melaporkan apa yang sudah dikonsumsinya.

Workflow 1: retry, lalu equivalent failover

Gunakan workflow ini ketika operasi dapat diulang dan sistem belum mengekspos output parsial atau memasuki status side effect yang tidak pasti.

Target yang equivalent adalah rute lain yang mempertahankan kontrak penting: kelas perilaku model yang sama, kapabilitas yang diperlukan, ekspektasi skema, konfigurasi keamanan, dan batas konteks yang kompatibel. Ini bisa berupa region, deployment, endpoint provider, atau pool kapasitas yang berbeda.

Step 1: normalisasi kegagalan

Petakan respons spesifik provider ke taksonomi internal yang kecil:

• transport_transient
• rate_limited
• provider_overloaded
• provider_server_error
• authentication_or_permission
• invalid_request
• deadline_exhausted
• contract_failure
• partial_output
• side_effect_uncertain

Hanya empat yang pertama biasanya memenuhi syarat untuk replay otomatis. Kesalahan autentikasi, permission, dan invalid-request harus dihentikan karena endpoint yang berbeda kemungkinan tidak akan memperbaiki request. Kegagalan kontrak termasuk dalam Workflow 2. Output parsial dan side effect yang tidak pasti termasuk dalam Workflow 3.

Step 2: hitung sisa anggaran

Sebelum setiap percobaan, periksa:

remaining time > estimated next-attempt latency + response safety margin
remaining attempts > 0
remaining added latency > 0
remaining cost budget > estimated attempt cost, when a cost ceiling exists

Jika anggaran yang diperlukan habis, keluar alih-alih mencoba satu provider lagi.

Step 3: retry dengan backoff dan jitter

Gunakan panduan retry provider jika tersedia. Jika tidak, terapkan exponential backoff dengan jitter dan jaga delay tetap berada di dalam deadline request.

function retryDelayMs(attempt: number, retryAfterMs?: number): number {
  if (retryAfterMs !== undefined) return retryAfterMs;

  const base = Math.min(250 * 2 ** attempt, 4_000);
  const jitter = Math.random() * base * 0.3;
  return Math.round(base + jitter);
}

Jitter penting karena banyak klien simultan jika tidak dapat mencoba lagi pada jadwal yang sama dan memperpanjang kejadian overload. Panduan batas rate LLM Anda seharusnya mendefinisikan bagaimana RPM, TPM, antrean, konkurensi, dan anggaran retry saling berinteraksi.

Langkah 4: beralih ke kapasitas yang setara

Jika target yang sama tetap tidak sehat, arahkan ke endpoint yang setara hanya setelah memeriksa:

• Circuit dalam keadaan tertutup atau setengah terbuka untuk probe.
• Target mendukung mode input dan output yang diperlukan.
• Target dapat menerima permintaan dalam batas konteksnya.
• Target menggunakan konfigurasi keamanan dan penanganan data yang diharapkan.
• Percobaan tersebut masih sesuai dengan batas waktu dan batas biaya.

Failover yang setara biasanya lebih kecil risikonya daripada mengganti model karena bertujuan mempertahankan kontrak respons.

Langkah 5: catat alasan pemulihan

Kembalikan hasil rute seperti:

{
  "workflow": "retry_equivalent_failover",
  "primary_attempts": 2,
  "equivalent_failover_attempts": 1,
  "recovered": true,
  "recovery_reason": "provider_overloaded",
  "added_latency_ms": 684
}

Jangan menampilkan detail penyedia internal kepada pengguna akhir kecuali produk Anda memang menjanjikan transparansi tersebut. Namun, simpan detail itu dalam trace dan log operasional.

Workflow 2: fallback lintas model yang terkontrol

Fallback lintas model hanya tepat ketika model alternatif telah disetujui sebelumnya untuk tugas tersebut. Model yang mengembalikan teks saja tidak cukup; model tersebut harus memenuhi kontrak workflow.

Langkah 1: buat kontrak kapabilitas

Tentukan persyaratan yang tidak bisa ditawar untuk setiap kelas rute.

{
  "route_class": "support_ticket_triage_v3",
  "required": {
    "input": ["text"],
    "output": ["json_schema"],
    "tools": [],
    "minimum_context_tokens": 24000,
    "schema": "triage-result-v3",
    "languages": ["en", "es", "de"],
    "safety_profile": "customer-support-standard"
  },
  "fallback_models": [
    "approved-model-b",
    "approved-model-c"
  ]
}

Untuk rute yang menggunakan alat, sertakan perilaku pemilihan alat, dukungan alat paralel, penanganan skema argumen, dan apakah model secara andal mengikuti kondisi “jangan panggil”. Untuk output terstruktur, validasi respons aktual terhadap skema setelah setiap percobaan.

Langkah 2: pisahkan keberhasilan transport dari keberhasilan tugas

Respons HTTP yang sukses masih bisa gagal dalam workflow produk. Evaluasi setidaknya tiga lapisan:

1. Keberhasilan transport: penyedia mengembalikan respons lengkap.
2. Keberhasilan kontrak: respons berhasil diparse, cocok dengan skema, dan menggunakan alat yang didukung dengan benar.
3. Keberhasilan tugas: output benar-benar menyelesaikan pekerjaan pengguna dengan tingkat kualitas yang dapat diterima.

Pembedaan ini penting saat membandingkan kandidat fallback. Model dengan tingkat respons tinggi tetapi sering gagal pada skema atau alat bukan fallback yang andal.

Langkah 3: beri peringkat kandidat yang disetujui berdasarkan kebijakan

Router produksi dapat memberi skor pada target yang memenuhi syarat menggunakan sinyal operasional tanpa berpura-pura bahwa satu model adalah yang paling baik secara universal.

type Candidate = {
  id: string;
  capabilitiesPass: boolean;
  circuitOpen: boolean;
  estimatedLatencyMs: number;
  estimatedCostUsd: number;
  recentContractSuccess: number;
  recentTaskSuccess: number;
};

function eligible(candidate: Candidate, envelope: FallbackEnvelope): boolean {
  return (
    candidate.capabilitiesPass &&
    !candidate.circuitOpen &&
    candidate.estimatedLatencyMs <= envelope.maxAddedLatencyMs &&
    (envelope.maxCostUsd === undefined ||
      candidate.estimatedCostUsd <= envelope.maxCostUsd)
  );
}

Hindari daftar statis “utama, cadangan, cadangan” untuk setiap tugas. Set fallback terbaik untuk pembuatan kode mungkin berbeda dari set terbaik untuk ekstraksi, terjemahan, visi, atau eksekusi alat.

Langkah 4: validasi output fallback

Terapkan pemeriksaan deterministik terlebih dahulu:

• Validasi JSON atau skema
• Pemeriksaan field wajib
• Validasi argumen alat
• Pemeriksaan format sitasi atau URL
• Batas panjang dan bahasa
• Pola output yang dilarang

Kemudian tambahkan pemeriksaan kualitas yang spesifik untuk workflow. Ini bisa berupa aturan ringan, evaluator tugas, peninjauan manusia sampel, atau model judge yang tervalidasi. Jika quality gate gagal, jangan labeli fallback sebagai berhasil dipulihkan.

Langkah 5: kebijakan canary untuk perubahan

Sebelum memperluas model fallback baru:

1. Putar ulang set evaluasi offline.
2. Jalankan shadow traffic jika kebijakan mengizinkannya.
3. Aktifkan kandidat untuk persentase kecil dari kegagalan yang memenuhi syarat.
4. Bandingkan keberhasilan kontrak, keberhasilan tugas, latensi, dan biaya.
5. Perluas hanya jika nilai pemulihan melebihi risiko regresi.

Lacak metrik ini dengan skema observabilitas API LLM yang mencatat satu route dan satu span per percobaan.

Workflow 3: berhenti, rekonsiliasi, atau eskalasi

Beberapa kegagalan seharusnya tidak memicu panggilan model lain. Fallback yang benar adalah penghentian terkontrol.

Kasus 1: output streaming parsial

Begitu token respons telah sampai ke pengguna, mengganti model secara diam-diam dapat menimbulkan kontradiksi, konten duplikat, blok kode yang rusak, atau perubahan gaya yang tiba-tiba. Ini juga membuat respons akhir sulit diatribusikan dan di-debug.

Gunakan salah satu hasil eksplisit berikut sebagai gantinya:

• Akhiri stream dengan error yang dapat dipulihkan dan tindakan “retry”.
• Tawarkan untuk memulai ulang jawaban dari awal.
• Lanjutkan hanya jika aplikasi memiliki protokol resume yang dirancang dan model baru menerima prefix yang sama persis yang telah diterima.

Default-nya harus allowAfterPartialOutput: false.

Kasus 2: efek samping alat yang tidak pasti

Misalkan sebuah model memilih alat pembayaran, email, deployment, tiket, atau penulisan database. Alat tersebut mungkin berhasil meskipun koneksi gagal sebelum orkestrator Anda mencatat hasilnya. Memutar ulang seluruh workflow dapat menggandakan efek samping.

Lindungi alat sisi tulis dengan:

• Kunci idempotensi berdasarkan operasi pengguna, bukan percobaan provider.
• Rekaman eksekusi yang tahan lama dengan status planned, started, succeeded, failed, dan unknown.
• Deduplikasi pada batas tool.
• Query rekonsiliasi sebelum melakukan replay apa pun.
• Peninjauan manusia untuk tindakan berisiko tinggi yang masih belum pasti.

type ToolExecution = {
  operationId: string;
  toolName: string;
  state: "planned" | "started" | "succeeded" | "failed" | "unknown";
  externalReference?: string;
};

function nextAction(execution: ToolExecution): "continue" | "reconcile" | "stop" {
  if (execution.state === "succeeded") return "continue";
  if (execution.state === "failed") return "stop";
  return "reconcile";
}

Pisahkan kredensial provider dan kredensial tool. panduan manajemen kunci API yang aman membahas model rahasia dan kontrol akses di sekitarnya.

Kasus 3: ketidakpastian keamanan, izin, atau kebijakan

Ketersediaan tidak boleh melemahkan keputusan keamanan atau otorisasi. Jika kandidat fallback tidak mendukung kontrol kebijakan yang diperlukan, rute tersebut tidak memenuhi syarat. Jika sistem tidak dapat menentukan apakah suatu operasi diizinkan, gagalkan secara tertutup atau eskalasi sesuai model risiko produk.

Kasus 4: tidak ada kandidat yang memenuhi kontrak

Kembalikan kegagalan bertipe yang dapat ditangani aplikasi:

{
  "status": "unavailable",
  "reason": "no_eligible_fallback",
  "retryable": true,
  "retry_after_ms": 30000,
  "request_id": "req_123"
}

Respons yang jelas dalam kondisi degradasi lebih baik daripada jawaban yang tampak berhasil tetapi melanggar skema, menggunakan tool yang salah, atau melakukan efek samping yang salah.

Masukkan tiga workflow ke dalam satu state machine

Lapisan orkestrasi harus membuat transisinya eksplisit.

START
  -> PRIMARY_ATTEMPT
     -> SUCCESS: validasi dan kembalikan
     -> TRANSIENT + replayable: WORKFLOW_1
     -> CONTRACT_FAILURE + alternate yang disetujui: WORKFLOW_2
     -> PARTIAL_OUTPUT or SIDE_EFFECT_UNCERTAIN: WORKFLOW_3

WORKFLOW_1
  -> retry dalam batas anggaran
  -> failover ekuivalen dalam batas anggaran
  -> jika alternate yang kompatibel diizinkan: WORKFLOW_2
  -> jika tidak: STOP

WORKFLOW_2
  -> pemeriksaan kemampuan
  -> percobaan alternate
  -> validasi kontrak dan tugas
  -> kembalikan hanya pada keberhasilan yang tervalidasi
  -> jika tidak: STOP

WORKFLOW_3
  -> tandai status parsial atau tidak pasti
  -> rekonsiliasi efek samping eksternal bila memungkinkan
  -> tawarkan restart eksplisit atau eskalasi ke manusia
  -> jangan pernah replay pekerjaan yang tidak aman secara diam-diam

Ini juga merupakan batas yang tepat untuk gateway multi-model. Memusatkan akses model di balik endpoint yang kompatibel dengan OpenAI dapat mengurangi duplikasi integrasi, tetapi aplikasi tetap perlu menyediakan maksud workflow: tenggat waktu, mode side effect, tool yang diperlukan, versi skema, dan apakah fallback lintas model diizinkan. Flatkey menyediakan lapisan akses API terpadu untuk tim yang menginginkan satu kunci dan satu permukaan integrasi di berbagai penyedia model; kebijakan routing yang paling aman tetap dimulai dengan kontrak aplikasi yang eksplisit.

Checklist penerapan strategi fallback model

Kebijakan

• [ ] Setiap kelas rute memiliki envelope fallback.
• [ ] Error yang dapat di-retry dinormalisasi di seluruh penyedia.
• [ ] Total anggaran retry memiliki satu pemilik.
• [ ] Endpoint yang setara dibedakan dari model alternatif.
• [ ] Kandidat lintas model memiliki kontrak kapabilitas yang diversi.
• [ ] Output parsial menonaktifkan fallback transparan secara default.
• [ ] Tool sisi tulis menggunakan catatan idempotensi yang tahan lama.

Validasi

• [ ] Keberhasilan transport, kontrak, dan tugas diukur secara terpisah.
• [ ] Output terstruktur divalidasi setelah fallback.
• [ ] Argumen tool dan perilaku pemilihan tool diuji per model.
• [ ] Set evaluasi fallback merepresentasikan kelas rute yang nyata.
• [ ] Kandidat baru lolos evaluasi offline dan canary produksi.

Operasional

• [ ] Setiap percobaan mencatat alasan rute, target, latensi, dan hasil.
• [ ] Dashboard menampilkan primary, retry, failover setara, dan pemulihan lintas model secara terpisah.
• [ ] Alert menyertakan habisnya tenggat waktu dan tingkat tidak adanya fallback yang memenuhi syarat.
• [ ] Circuit breaker menggunakan probe half-open yang terkontrol.
• [ ] Tinjauan insiden mencakup kualitas yang terlihat oleh pengguna dan risiko side effect ganda.

Metrik yang membuktikan fallback membantu

Jangan mengoptimalkan hanya untuk tingkat error penyedia. Lacak hasil pengguna.

Segmentasikan metrik ini berdasarkan kelas rute. Tingkat pemulihan agregat dapat menyembunyikan bahwa fallback bekerja dengan baik untuk ekstraksi tetapi buruk untuk pembuatan kode atau penggunaan tool.

Pertanyaan yang sering diajukan

Apa itu strategi fallback model?

Strategi fallback model adalah kebijakan untuk menentukan kapan suatu permintaan AI harus mencoba ulang target yang sama, fail over ke kapasitas yang setara, beralih ke model alternatif yang disetujui, atau berhenti karena replay tidak aman.

Apa perbedaan antara retry dan fallback?

Retry mengulang permintaan terhadap target atau deployment yang sama. Failover yang setara memindahkan permintaan ke kapasitas yang dimaksudkan untuk mempertahankan kontrak model yang sama. Fallback lintas model mengubah model dan karena itu memerlukan validasi kapabilitas dan kualitas.

Apakah setiap error 429 harus memicu model lain?

Tidak. Pertama klasifikasikan limit-nya, patuhi panduan retry, periksa deadline yang tersisa, dan gunakan retry terbatas atau antrean. Beralih model mungkin membantu ketika kapasitas alternatif yang disetujui tersedia, tetapi hal itu juga dapat mengubah kualitas output, perilaku tool, atau biaya.

Apakah respons streaming bisa fallback di tengah jawaban?

Biasanya lebih aman untuk tidak beralih secara transparan setelah token mencapai pengguna. Hentikan stream dan tawarkan restart yang eksplisit kecuali aplikasi memiliki protokol resume yang telah diuji.

Berapa banyak model fallback yang seharusnya dimiliki suatu route?

Gunakan set yang paling kecil dan disetujui yang memberikan pemulihan yang bermakna. Setiap kandidat menambah beban evaluasi, pemantauan, dan penanganan insiden. Daftar panjang yang belum diuji bukanlah resilien.

Di mana logika fallback sebaiknya ditempatkan?

Sentralisasikan normalisasi provider, routing, anggaran percobaan, dan observabilitas dalam gateway atau lapisan orkestrasi. Jaga intent khusus workflow—risiko side effect, kebutuhan skema, kebijakan keamanan, dan ambang kualitas—tetap dekat dengan aplikasi.

Bangun fallback berdasarkan risiko workflow

Strategi fallback model terbaik bukanlah “coba model berikutnya.” Melainkan sistem keputusan yang dibatasi:

• Workflow 1 memulihkan permintaan yang dapat direplay dengan retry dan kapasitas yang setara.
• Workflow 2 mengganti model hanya setelah pemeriksaan kapabilitas dan kualitas.
• Workflow 3 menghentikan replay otomatis ketika output atau side effect membuat pemulihan tidak aman.

Desain itu meningkatkan ketersediaan tanpa menyembunyikan kegagalan kontrak atau menduplikasi tindakan pengguna. Jika tim Anda menstandardisasi akses lintas penyedia model, gunakan lapisan API OpenAI-compatible terpadu dari Flatkey sebagai surface integrasi, lalu lampirkan envelope khusus workflow ini ke setiap route produksi.

Sumber dan bacaan lanjutan

• Kode error API OpenAI
• Structured Outputs OpenAI
• Error API Anthropic
• Streaming messages Anthropic
• Pola retry dengan backoff AWS
• Pola circuit breaker AWS
• Strategi retry Google Cloud