Strategi Fallback Model: Playbook 3 Workflow

Fallback model bukanlah satu perilaku. Ini adalah serangkaian keputusan pemulihan dengan batas keselamatan yang berbeda.

Strategi fallback model dalam produksi harus memisahkan tiga alur kerja:

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

Pemisahan ini penting karena tindakan pemulihan tercepat tidak selalu yang paling aman. Memutar ulang permintaan klasifikasi yang gagal biasanya berisiko rendah. Mengganti model secara diam-diam di tengah jawaban streaming atau setelah panggilan tool pembayaran yang tidak pasti bukanlah tindakan yang aman.

Playbook ini mengubah kebijakan fallback menjadi tiga alur kerja operasional yang dapat diimplementasikan, diuji, diamati, dan dirilis oleh tim Anda melalui peluncuran produksi yang terkontrol.

Keputusan fallback model dalam satu tabel

Mulailah dari status permintaan, bukan nama penyedia.

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

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

Sebelum alur kerja: definisikan satu envelope fallback

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

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 tersebut harus berasal dari alur kerja produk, bukan dari default global. Job ringkasan latar belakang dapat menoleransi latensi yang lebih besar daripada asisten coding interaktif. Jawaban chat tanpa tools dapat menoleransi perilaku pemulihan yang berbeda dibandingkan agen yang dapat men-deploy kode atau mengirim email.

Envelope juga mencegah retry bertingkat. Jika SDK, aplikasi, gateway, dan adapter penyedia semuanya melakukan retry secara independen, insiden kecil dapat berlipat ganda menjadi lonjakan percobaan yang besar. Pilih satu lapisan untuk memiliki total anggaran percobaan dan wajibkan setiap lapisan di bawahnya melaporkan apa yang sudah dikonsumsinya.

Ubah fallback envelope menjadi policy as code

Definisi tipe mendokumentasikan maksud, tetapi routing produksi membutuhkan policy berversi yang dapat ditinjau operator tanpa mengubah kode aplikasi. Jaga policy tetap cukup kecil untuk diaudit dan cukup spesifik untuk mencegah rantai fallback generik merembes ke alur kerja berisiko tinggi.

Konfigurasi awal ini memisahkan tiga kelas rute umum:

policy_version: 2026-08-02

routes:
  interactive_chat:
    deadline_ms: 12000
    max_attempts: 2
    max_added_latency_ms: 2500
    allow_equivalent_failover: true
    allow_cross_model_fallback: true
    allow_after_partial_output: false
    side_effect_mode: none
    required_capabilities: [streaming]

  structured_extraction:
    deadline_ms: 30000
    max_attempts: 3
    max_added_latency_ms: 8000
    allow_equivalent_failover: true
    allow_cross_model_fallback: true
    allow_after_partial_output: false
    side_effect_mode: none
    required_capabilities: [structured_output]
    required_schema_version: invoice-v4

  tool_agent_write:
    deadline_ms: 45000
    max_attempts: 2
    max_added_latency_ms: 5000
    allow_equivalent_failover: true
    allow_cross_model_fallback: false
    allow_after_partial_output: false
    side_effect_mode: write_possible
    required_capabilities: [tool_use]

Nilai di atas adalah contoh, bukan ambang universal. Tetapkan berdasarkan objektif latensi yang terlihat oleh pengguna, ekonomi tugas, hasil evaluasi, dan risiko efek samping. Pilihan desain yang penting adalah bahwa agen yang mampu melakukan write tidak dapat diam-diam beralih ke model yang berperilaku berbeda.

Pada runtime, router harus menggabungkan policy dengan state permintaan dan state kegagalan yang teramati. Fungsi keputusan yang ringkas dapat membuat batasnya dapat diuji:

type RecoveryAction =
  | "retry_same_target"
  | "failover_equivalent"
  | "fallback_approved_model"
  | "reconcile_side_effect"
  | "restart_required"
  | "stop";

function chooseRecovery(input: {
  errorClass: string;
  attemptsUsed: number;
  deadlineRemainingMs: number;
  partialOutput: boolean;
  sideEffectState: "none" | "safe" | "uncertain";
  equivalentAvailable: boolean;
  approvedAlternateAvailable: boolean;
  policy: FallbackEnvelope;
}): RecoveryAction {
  if (input.sideEffectState === "uncertain") return "reconcile_side_effect";
  if (input.partialOutput) return "restart_required";
  if (input.attemptsUsed >= input.policy.maxAttempts) return "stop";
  if (input.deadlineRemainingMs <= 0) return "stop";

  const transient = [
    "transport_transient",
    "rate_limited",
    "provider_overloaded",
    "provider_server_error",
  ].includes(input.errorClass);

  if (transient && input.attemptsUsed === 0) return "retry_same_target";
  if (transient && input.equivalentAvailable) return "failover_equivalent";

  if (
    input.policy.allowCrossModelFallback &&
    input.approvedAlternateAvailable
  ) {
    return "fallback_approved_model";
  }

  return "stop";
}

Jaga pemilihan kandidat tetap terpisah dari keputusan recovery. chooseRecovery memutuskan workflow mana yang diizinkan; kemudian selector kandidat memfilter target berdasarkan kapabilitas, konteks, region, biaya, dan kebijakan kualitas. Pemisahan ini membuat peninjauan insiden lebih mudah karena tim dapat membedakan “kami memilih workflow recovery yang salah” dari “kami memilih model alternatif yang salah.”

Versikan kebijakan dan lampirkan versi itu ke setiap trace percobaan. Saat regresi fallback muncul, operator harus dapat menjawab kebijakan mana yang membuat keputusan, kandidat mana yang memenuhi syarat, dan budget mana yang tersisa pada saat itu.

Workflow 1: retry, lalu failover ekuivalen

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

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

Langkah 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

Biasanya hanya empat yang pertama yang memenuhi syarat untuk replay otomatis. Error autentikasi, izin, dan invalid-request harus berhenti 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.

Langkah 2: hitung budget yang tersisa

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 salah satu anggaran yang diperlukan habis, keluar alih-alih mencoba satu penyedia lagi.

Langkah 3: retry dengan backoff dan jitter

Gunakan panduan retry dari penyedia jika tersedia. Jika tidak, terapkan exponential backoff dengan jitter dan jaga agar penundaan 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 retry dengan jadwal yang sama dan memperpanjang kejadian overload. Panduan batas laju LLM Anda harus mendefinisikan bagaimana RPM, TPM, antrean, concurrency, dan anggaran retry saling berinteraksi.

Langkah 4: pindah ke kapasitas yang setara

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

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

Failover yang setara biasanya kurang berisiko daripada mengganti model karena bertujuan mempertahankan kontrak respons.

Langkah 5: catat alasan pemulihan

Kembalikan hasil route seperti:

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

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

Workflow 2: fallback lintas model yang terkontrol

Fallback lintas model hanya tepat ketika model alternatif sudah 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 route.

{
  "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 sukses HTTP masih bisa gagal dalam alur kerja 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 sangat penting saat membandingkan kandidat fallback. Model dengan tingkat respons tinggi tetapi sering gagal pada skema atau alat bukanlah fallback yang andal.

Langkah 3: beri peringkat kandidat yang disetujui berdasarkan kebijakan

Router produksi dapat menilai target yang memenuhi syarat menggunakan sinyal operasional tanpa berpura-pura bahwa satu model adalah yang terbaik untuk semua kasus.

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 bisa 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

Lalu tambahkan pemeriksaan kualitas khusus alur kerja. Ini bisa berupa aturan ringan, evaluator tugas, tinjauan manusia pada sampel, atau model penilai yang tervalidasi. Jika gerbang kualitas gagal, jangan labeli fallback sebagai berhasil dipulihkan.

Langkah 5: perubahan kebijakan canary

Sebelum memperluas model fallback baru:

1. Putar ulang set evaluasi offline.
2. Jalankan traffic bayangan 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 pengukuran ini dengan skema observability API LLM yang mencatat satu rute 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, berpindah model secara diam-diam dapat menciptakan kontradiksi, konten duplikat, blok kode yang rusak, atau perubahan gaya yang mendadak. Ini juga membuat respons akhir sulit diatribusikan dan di-debug.

Gunakan salah satu hasil eksplisit berikut sebagai gantinya:

• Akhiri aliran 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 diterima secara persis.

Default-nya harus allowAfterPartialOutput: false.

Case 2: uncertain tool side effects

Misalkan sebuah model memilih alat pembayaran, email, deployment, tiket, atau penulisan database. Alat tersebut mungkin telah berhasil meskipun koneksi gagal sebelum orchestrator Anda mencatat hasilnya. Memutar ulang seluruh alur kerja dapat menggandakan side effect.

Lindungi alat di sisi penulisan dengan:

• Idempotency key berdasarkan operasi pengguna, bukan percobaan provider.
• Catatan eksekusi yang tahan lama dengan state planned, started, succeeded, failed, dan unknown.
• Deduplication di batas alat.
• Query rekonsiliasi sebelum replay apa pun.
• Tinjauan manusia untuk tindakan berdampak 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";
}

Jaga agar kredensial provider dan kredensial alat tetap terpisah. panduan pengelolaan kunci API yang aman mencakup model secret dan kontrol akses di sekitarnya.

Case 3: safety, permission, or policy uncertainty

Ketersediaan tidak boleh melemahkan keputusan keselamatan 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, gagal secara tertutup atau eskalasi sesuai model risiko produk.

Case 4: no candidate satisfies the contract

Kembalikan kegagalan bertipe yang dapat ditangani aplikasi:

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

Respons degraded yang jelas lebih baik daripada jawaban yang tampak berhasil tetapi melanggar schema, menggunakan alat yang salah, atau melakukan side effect yang salah.

Masukkan ketiga 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
  -> equivalent failover dalam batas anggaran
  -> jika alternate yang kompatibel diizinkan: WORKFLOW_2
  -> jika tidak: STOP

WORKFLOW_2
  -> pengecekan kapabilitas
  -> percobaan alternate
  -> validasi kontrak dan tugas
  -> kembalikan hanya saat sukses tervalidasi
  -> jika tidak: STOP

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

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 intent workflow: batas waktu, mode side effect, tools 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.

Jalankan lima drill kegagalan sebelum mengaktifkan fallback otomatis

Jalur fallback yang belum pernah menangani kegagalan terkontrol hanyalah sebuah diagram. Uji setiap kelas rute terhadap kegagalan yang menguji batas keselamatan yang berbeda.

Jalankan drill terlebih dahulu di lingkungan lokal atau staging, lalu di production game day yang cakupannya sempit. Tujuannya bukan membuktikan bahwa setiap permintaan selamat. Tujuannya adalah membuktikan bahwa sistem gagal dalam state yang dimaksud, mengekspos bukti yang cukup untuk mendiagnosis kejadian, dan tidak menghabiskan lebih banyak latensi, biaya, atau risiko side effect daripada yang diizinkan kebijakan.

Untuk setiap drill, verifikasi empat lapisan secara independen:

1. Kebenaran keputusan: router memilih alur kerja yang dimaksud.
2. Kebenaran anggaran: semua percobaan tetap berada dalam batas waktu, batas percobaan, dan batas biaya bersama.
3. Kebenaran output: hasil akhir lolos validasi kontrak dan tugas, atau mengembalikan status degradasi yang eksplisit.
4. Kebenaran audit: jejak mencatat versi kebijakan, kelas kegagalan, kelayakan kandidat, alasan rute, dan hasil yang terlihat oleh pengguna.

Ulangi drill setiap kali Anda mengubah adapter penyedia, pemilik retry, kandidat model, versi skema, kontrak alat, atau implementasi streaming. Perubahan tersebut dapat mengubah keamanan replay bahkan ketika bentuk API publik tampak tidak berubah.

Gunakan scorecard kesiapan fallback sebelum produksi

Lulus beberapa pengujian happy-path saja tidak cukup untuk mengaktifkan fallback otomatis. Suatu rute harus mendapatkan automasi dengan melewati lima gerbang rilis independen.

Perlakukan scorecard sebagai artefak rilis. Catat kelas rute, versi kebijakan, kandidat yang disetujui, versi evaluator, hasil drill, pemilik, dan tanggal peninjauan. Satu flag global “fallback diaktifkan” menyembunyikan terlalu banyak risiko; persetujuan harus dilakukan per kelas alur kerja.

Rekam kesiapan yang dapat disalin

fallback_readiness:
  route_class: support_ticket_extraction
  policy_version: fallback-v4
  owner: ai-platform
  primary_target: primary-model
  approved_candidates:
    - equivalent-deployment
    - alternate-model

  gates:
    replay_safety: pass
    contract_compatibility: pass
    task_quality: pass
    budget_control: pass
    operational_control: pass

  evidence:
    capability_matrix: contracts/support-ticket-v3.yaml
    evaluation_set: evals/support-ticket-2026-08.jsonl
    failure_drill_run: drills/2026-08-03.json
    dashboard: ai-routing/support-ticket
    runbook: runbooks/support-ticket-fallback.md

  release:
    mode: canary
    rollback_owner: oncall-ai-platform
    next_review_at: 2026-09-03

Berkas ini tidak harus menggunakan format persis seperti ini. Yang penting adalah keputusan rilis dapat ditinjau dan terkait dengan versi kebijakan yang sama seperti yang tercatat dalam jejak produksi.

Luncurkan strategi fallback model dalam empat tahap

Fallback otomatis tidak boleh melompat dari pengujian offline ke setiap permintaan produksi. Gunakan empat tahap yang menyingkap kesalahan keputusan sebelum menjadi terlihat oleh pengguna.

Tahap 1: shadow keputusan

Jalankan controller fallback dalam mode observe-only. Jalur utama tetap menentukan respons pengguna, sementara controller mencatat apa yang akan dilakukannya.

Tinjau:

• Seberapa sering kebijakan menandai kegagalan sebagai dapat di-retry.
• Seberapa sering sebuah kandidat memenuhi syarat.
• Anggaran mana yang akan menghentikan pemulihan.
• Apakah kebijakan mengusulkan fallback setelah output parsial atau side effect yang tidak pasti.
• Apakah error yang dinormalisasi provider mempertahankan detail yang cukup untuk diagnosis insiden.

Mode shadow sangat berguna untuk menemukan aturan yang terlalu luas seperti “fallback pada setiap 429” atau “coba model lain setelah error schema apa pun.” Aturan seperti itu bisa tampak masuk akal saat code review, tetapi berperilaku buruk terhadap state permintaan yang nyata.

Tahap 2: canary workflow berisiko rendah

Aktifkan fallback untuk sebagian kecil traffic yang aman untuk replay, seperti klasifikasi read-only, ekstraksi, atau ringkasan latar belakang. Kecualikan tool sisi tulis, keputusan yang sensitif terhadap keselamatan, dan route dengan streaming yang terlihat oleh pengguna.

Bandingkan canary dengan jalur primary-only menggunakan hasil tingkat route:

• Tingkat task yang diterima, bukan hanya keberhasilan HTTP.
• Latensi tambahan dari pemulihan.
• Delta biaya per task yang diterima.
• Kegagalan validasi kontrak per kandidat.
• Kehabisan deadline dan tingkat tidak ada fallback yang memenuhi syarat.
• Pembatalan pengguna atau tingkat restart eksplisit.

Jangan memperluas canary hanya karena tingkat error provider menurun. Perluas hanya ketika hasil akhir pengguna tetap dapat diterima dan jalur pemulihan tetap berada dalam batasannya.

Tahap 3: batasi pemulihan otomatis berdasarkan kelas risiko

Perluas hanya kelas workflow yang lolos scorecard kesiapan. Jaga perbedaan kebijakan tetap eksplisit:

Tahap ini adalah saat gateway dan kontrak aplikasi bertemu. Gateway dapat menormalkan error, memberlakukan budget, dan memilih kapasitas yang memenuhi syarat. Aplikasi tetap harus menyatakan apakah output sudah lolos, apakah side effect mungkin terjadi, dan pemeriksaan kualitas atau kebijakan mana yang wajib.

Tahap 4: perluas secara bertahap dan sertifikasi ulang perubahan

Naikkan traffic dalam langkah-langkah yang dibatasi. Pada setiap langkah, pertahankan kemampuan untuk menonaktifkan satu versi kebijakan, satu kelas rute, satu adapter provider, atau satu kandidat tanpa mematikan seluruh layer routing.

Jalankan ulang gate scorecard yang relevan ketika salah satu dari hal berikut berubah:

• Model atau versi model.
• Adapter provider atau endpoint.
• Template prompt atau instruksi sistem.
• Definisi tool atau cakupan izin.
• Skema output terstruktur.
• Kepemilikan retry atau konfigurasi timeout.
• Transport streaming atau perilaku client.
• Kebijakan keselamatan atau evaluator kualitas.

Kesiapan fallback kedaluwarsa ketika asumsi-asumsinya berubah. Kandidat yang disetujui untuk prompt, skema, atau set tool sebelumnya tidak boleh tetap otomatis memenuhi syarat hanya karena inersia.

Tentukan pemicu rollback sebelum mengaktifkan canary

Canary hanya aman ketika tim menyepakati sebelumnya apa yang menghentikannya. Gunakan pemicu khusus per rute alih-alih menunggu insiden yang luas.

Lakukan rollback atau nonaktifkan kebijakan yang terdampak ketika Anda mengamati:

• Efek samping penulisan yang duplikat atau tidak pasti.
• Keberhasilan kontrak lintas-model tanpa keberhasilan tugas yang dapat diterima.
• Kenaikan kegagalan partial-stream atau splicing respons yang tidak terlihat.
• Kegagalan batas waktu berulang yang disebabkan oleh upaya pemulihan.
• Batas budget terlampaui atau diabaikan.
• Pemilihan kandidat yang melanggar kemampuan yang disyaratkan atau kebijakan keselamatan.
• Perubahan yang tidak dapat dijelaskan pada distribusi alasan fallback setelah deploy.
• Data trace versi kebijakan atau tingkat percobaan yang hilang selama insiden.

Tindakan rollback harus sesempit kegagalannya. Bergantung pada peristiwanya, itu bisa berarti menonaktifkan satu kandidat, memaksa rute hanya ke failover ekuivalen, menetapkan allowCrossModelFallback ke false, membuka circuit untuk satu provider, atau mengembalikan workflow ke mode primary-only.

Hindari mekanisme rollback yang mengharuskan membangun ulang aplikasi. Perubahan kebijakan pemulihan sering terjadi selama insiden, dan respons paling aman sering kali adalah perubahan konfigurasi dengan versi yang dapat diaudit, bukan patch kode darurat.

Gunakan satu lembar kerja insiden untuk setiap kejadian fallback

Insiden fallback menjadi sulit didiagnosis ketika setiap penyedia menampilkan bentuk error yang berbeda dan setiap aplikasi mencatat state permintaan yang berbeda. Catat satu lembar kerja yang netral terhadap penyedia.

fallback_incident:
  incident_id: inc-2026-08-03-001
  route_class: support_ticket_extraction
  request_id: req_123
  policy_version: fallback-v4

  request_state:
    output_started: false
    side_effect_mode: none
    tool_execution_state: not_started
    deadline_remaining_ms: 1820
    attempts_remaining: 1

  primary_failure:
    normalized_class: overloaded
    provider_status: 529
    retry_guidance_present: true

  recovery_decision:
    workflow: cross_model_fallback
    candidate: alternate-model
    reason: equivalent_capacity_unavailable

  validation:
    transport_success: true
    contract_success: true
    task_success: false
    failure_reason: required_field_omitted

  user_outcome:
    state: explicit_failure
    partial_output: false
    duplicate_side_effect: false

  containment:
    action: disable_candidate_for_route
    owner: oncall-ai-platform

Perbedaan paling penting adalah antara keberhasilan pemulihan dan keberhasilan pengguna. Sebuah permintaan fallback dapat mengembalikan respons HTTP yang valid namun tetap gagal pada skema, memilih alat yang salah, menghilangkan fakta yang wajib, atau melanggar ambang batas kualitas rute. Tinjauan insiden harus mengikuti hasilnya hingga ke tugas yang terlihat oleh pengguna.

Jalankan game day fallback model selama 60 menit

Unit test membuktikan bahwa cabang individual dapat dieksekusi. Game day fallback membuktikan bahwa seluruh sistem pemulihan berperilaku dengan benar saat batas waktu, retry, stream, validasi, alat, telemetri, dan kontrol operator saling berinteraksi.

Jalankan latihan ini untuk satu kelas workflow pada satu waktu. Jangan mulai dengan simulasi outage penyedia secara global. Rute sempit seperti ekstraksi read-only atau ringkasan internal menghasilkan bukti yang lebih jelas dan membatasi radius dampak jika kebijakannya salah.

Tentukan charter game day

Tulis charter satu halaman sebelum siapa pun menyuntikkan kegagalan. Charter ini mencegah latihan berubah menjadi outage dadakan.

game_day:
  id: fallback-gd-2026-08-04-extraction
  route_class: structured_extraction
  policy_version: fallback-v4
  environment: staging
  exercise_owner: ai-platform
  incident_commander: reliability

  primary_target: primary-model
  approved_fallbacks:
    - equivalent-deployment
    - alternate-schema-capable-model

  traffic_scope:
    synthetic_requests: 100
    production_percentage: 0

  safety_limits:
    stop_after_minutes: 60
    max_error_rate_percent: 5
    max_duplicate_side_effects: 0
    max_unexplained_route_decisions: 0

  success_definition:
    - every request ends accepted, explicitly degraded, or safely stopped
    - no request exceeds the shared attempt budget
    - no partial stream is silently continued by another model
    - every fallback decision includes a policy version and route reason

Gunakan traffic sintetis atau replay-safe terlebih dahulu. Jika rute dapat memicu penulisan, ganti alat dengan test double yang terkontrol atau sandbox yang mendukung pencarian idempotency. Game day harus menguji kontrol pemulihan, bukan mempertaruhkan state pelanggan.

Tetapkan empat peran

Jaga tim tetap cukup kecil untuk mengambil keputusan dengan cepat, tetapi pisahkan observasi dari eksekusi.

Untuk tim yang sangat kecil, satu orang dapat menjalankan dua peran, tetapi orang yang menyuntikkan fault tidak seharusnya menjadi satu-satunya orang yang mengevaluasi apakah sistem merespons dengan benar.

Bangun tangga skenario

Mulailah dengan kegagalan yang paling tidak ambigu dan tambahkan risiko hanya setelah rute melewati tingkat sebelumnya.

Jangan langsung melompat ke skenario lintas-model yang rumit. Jika equivalent failover tidak dapat mempertahankan budget dan trace contract, menambahkan model yang berbeda secara perilaku akan membuat diagnosis lebih sulit, bukan lebih realistis.

Suntikkan fault pada boundary yang eksplisit

Labeli boundary yang tepat tempat fault masuk ke lifecycle request. “Provider failed” terlalu samar untuk catatan pengujian yang berguna.

type InjectionPoint =
  | "before_connect"
  | "after_connect_before_headers"
  | "after_headers_before_body"
  | "after_partial_stream"
  | "after_tool_dispatch_before_ack"
  | "after_tool_ack_before_model_response"
  | "after_transport_success_before_validation";

Batas menentukan tindakan pemulihan mana yang aman. Timeout sebelum koneksi sering kali dapat dicoba ulang. Putus koneksi setelah pengguna melihat output memerlukan restart eksplisit. Acknowledgement yang hilang setelah panggilan tool di sisi tulis memerlukan rekonsiliasi. Memperlakukan ketiganya sebagai kelas timeout yang sama adalah bagaimana tindakan duplikat dan respons yang tidak koheren masuk ke produksi.

Jika lapisan fault injection Anda tidak dapat menargetkan batas-batas tersebut, tambahkan penanda batas ke adapter provider atau lapisan orkestrasi sebelum latihan. Toggle kegagalan yang kasar berguna untuk pengujian ketersediaan tetapi tidak cukup untuk pengujian replay-safety.

Catat satu baris bukti per permintaan

Game day seharusnya menghasilkan ledger di tingkat permintaan, bukan hanya tangkapan layar dashboard. Baris yang ringkas membuat keputusan yang tidak terjelaskan menjadi terlihat.

Simpan ledger di samping snapshot kebijakan, versi validator, konfigurasi fault, dan ekspor dashboard. Tanpa versi-versi tersebut, latihan yang berhasil tidak dapat direproduksi setelah perubahan adapter atau model berikutnya.

Beri skor pada latihan dengan aturan promosi

Gunakan tiga keputusan yang mungkin: promote, perbaiki dan jalankan ulang, atau hentikan otomatisasi. Hindari hasil yang kabur seperti “sebagian besar lulus”.

Promote rute hanya ketika semua hal berikut benar:

• Setiap permintaan memiliki state terminal yang dijelaskan.
• Tidak ada rantai percobaan yang melampaui tenggat bersama, jumlah percobaan, atau batas biaya yang dikonfigurasi.
• Setiap output yang diterima lolos validator atau aturan evaluasi rute.
• Output parsial dan efek samping yang tidak pasti masuk ke state stop atau rekonsiliasi yang eksplisit.
• Operator dapat menonaktifkan satu kandidat atau seluruh kebijakan tanpa men-deploy kode aplikasi.
• Alerting mengidentifikasi kegagalan pemulihan dan pemulihan yang merugikan, seperti keberhasilan fallback dengan kualitas tugas yang tidak dapat diterima.

Pilih perbaiki dan jalankan ulang ketika model keselamatannya benar tetapi bukti atau implementasinya belum lengkap. Contohnya termasuk alasan rute yang hilang, alert yang berbunyi terlalu terlambat, atau kandidat yang lolos kontrak tetapi tidak memenuhi target latensi.

Pilih hentikan otomatisasi ketika exercise menemukan ambiguitas replay, efek samping duplikat, pemotongan stream yang diam-diam, routing yang tak terjelaskan, bypass kebijakan, atau mode kegagalan yang tidak dapat direpresentasikan oleh state machine saat ini. Itu adalah celah desain, bukan masalah tuning.

Gunakan scorecard game-day yang bisa disalin

game_day_result:
  game_day_id: fallback-gd-2026-08-04-extraction
  route_class: structured_extraction
  policy_version: fallback-v4
  evaluator_version: extraction-eval-v7
  started_at: 2026-08-04T09:00:00Z
  completed_at: 2026-08-04T10:00:00Z

  scenarios:
    equivalent_failover: pass
    retry_pressure: pass
    semantic_contract_failure: pass
    partial_stream: pass
    uncertain_tool_completion: not_applicable
    fallback_degradation: fix

  totals:
    requests: 100
    accepted: 94
    explicitly_degraded: 6
    unsafe_or_unexplained: 0
    duplicate_side_effects: 0
    deadline_violations: 0

  decision: fix_and_rerun
  blockers:
    - alternate p95 latency exceeded the route objective during degradation
  owner: ai-platform
  rerun_due: 2026-08-11

Nilai contoh bersifat ilustratif. Gunakan objective rute dan ambang evaluasi Anda sendiri. Yang penting adalah keputusan akhir menunjuk pada bukti yang disimpan dan pemilik yang disebutkan namanya.

Ubah temuan menjadi kontrol rilis

Selesaikan game day dengan mengubah setiap temuan menjadi salah satu dari empat kontrol yang tahan lama:

1. Perubahan kebijakan: kelayakan kandidat, anggaran percobaan, tenggat, atau aturan kelas rute.
2. Uji kontrak: pemeriksaan kompatibilitas kapabilitas, skema, tool, streaming, atau keselamatan.
3. Kontrol operasional: alert, dashboard, kill switch, karantina kandidat, atau prosedur insiden.
4. Perilaku produk: restart eksplisit, pesan state terdegradasi, konfirmasi manual, atau layar rekonsiliasi.

Jangan menutup exercise dengan daftar observasi. Temuan tanpa pemilik, jenis kontrol, dan kondisi rerun akan muncul lagi selama insiden nyata.

Untuk lapisan telemetry di balik latihan ini, gunakan panduan observabilitas API LLM. Untuk kepemilikan retry dan perilaku rate limit, padukan game day dengan rate limit LLM dan strategi retry. Jika tim Anda masih mendefinisikan batas gateway, mulailah dengan panduan pemula gateway LLM.

Sekuens implementasi tujuh hari

Tim dapat menggunakan urutan ini untuk bergerak dari daftar model ad hoc ke playbook workflow yang terkontrol:

1. Hari 1 — Inventarisasi rute: klasifikasikan mode output, risiko side effect, tools, schema, tenggat waktu, dan pemilik retry saat ini.
2. Hari 2 — Definisikan envelope: tetapkan batas attempt, latensi, biaya, kapabilitas, dan replay per kelas rute.
3. Hari 3 — Bangun kontrak: dokumentasikan kandidat yang disetujui dan uji kompatibilitas tool, schema, konteks, modalitas, dan kebijakan.
4. Hari 4 — Instrumentasikan keputusan: catat kegagalan yang dinormalisasi, status request, versi kebijakan, kelayakan kandidat, anggaran, validasi, dan hasil pengguna.
5. Hari 5 — Jalankan drill kegagalan: injeksikan timeout, lonjakan rate limit, output tidak valid, putus koneksi di tengah stream, dan eksekusi tool yang ambigu.
6. Hari 6 — Shadow dan canary: amati keputusan terlebih dahulu, lalu aktifkan satu rute sempit berisiko rendah dengan pemicu rollback yang telah ditentukan sebelumnya.
7. Hari 7 — Tinjau dan perluas: periksa tingkat tugas yang diterima, latensi tambahan, delta biaya, sinyal replay yang tidak aman, dan event tanpa fallback yang layak sebelum memperluas.

Sekuens ini secara sengaja berfokus pada workflow terlebih dahulu. Memilih daftar model berperingkat hanyalah satu langkah kecil. Pekerjaan produksi adalah membuktikan kapan sistem boleh melanjutkan, kapan harus memvalidasi, dan kapan harus berhenti.

Checklist peluncuran strategi fallback model

Kebijakan

• Setiap kelas rute memiliki fallback envelope.
• Kebijakan fallback diberi versi dan dapat ditinjau sebagai konfigurasi.
• Error yang dapat di-retry dinormalisasi lintas provider.
• Total anggaran retry memiliki satu pemilik.
• Endpoint yang setara dibedakan dari model alternatif.
• Kandidat lintas model memiliki kontrak kapabilitas yang diberi versi.
• Output parsial menonaktifkan fallback transparan secara default.
• Tools pada sisi tulis menggunakan catatan idempotency yang tahan lama.

Validasi

• Keberhasilan transport, kontrak, dan tugas diukur secara terpisah.
• Output terstruktur divalidasi setelah fallback.
• Argumen tool dan perilaku pilihan tool diuji per model.
• Set evaluasi fallback merepresentasikan kelas rute yang nyata.
• Kandidat baru lolos evaluasi offline dan canary produksi.
• Kelima drill kegagalan lolos untuk setiap kelas rute yang berlaku.

Operasi

• Setiap percobaan mencatat alasan rute, target, latensi, dan hasil.
• Dasbor menampilkan primary, retry, equivalent failover, dan cross-model recovery secara terpisah.
• Alert mencakup kehabisan deadline dan laju no-eligible-fallback.
• Circuit breaker menggunakan probe half-open yang terkontrol.
• Tinjauan insiden mencakup kualitas yang terlihat oleh pengguna dan risiko efek samping duplikat.
• Setiap trace percobaan mencatat versi kebijakan fallback yang aktif.
• Setiap rute memiliki scorecard kesiapan yang selesai dan owner yang disebutkan namanya.
• Trigger rollback canary dan kill switch yang sempit diuji.
• Lembar kerja insiden menangkap status permintaan, validasi, dan hasil pengguna.

Metrik yang membuktikan fallback membantu

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

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

Selama rollout, bandingkan metrik ini menurut versi kebijakan dan tahap rilis. Itu memungkinkan pemisahan insiden penyedia dari perubahan controller, perubahan kandidat, atau canary yang diperluas.

Pertanyaan yang sering diajukan

Apa itu strategi fallback model?

Strategi fallback model adalah kebijakan untuk menentukan kapan permintaan AI harus retry ke 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 mengulangi permintaan ke target atau deployment yang sama. Equivalent failover memindahkan permintaan ke kapasitas yang dimaksudkan untuk mempertahankan kontrak model yang sama. Cross-model fallback mengubah model dan karena itu memerlukan validasi kemampuan dan kualitas.

Haruskah setiap error 429 memicu model lain?

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

Bisakah respons streaming melakukan fallback di tengah jawaban?

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

Berapa banyak model fallback yang seharusnya dimiliki sebuah route?

Gunakan set yang paling kecil dan disetujui yang memberikan pemulihan yang bermakna. Setiap kandidat menambah pekerjaan evaluasi, pemantauan, dan respons insiden. Daftar panjang yang belum diuji bukanlah ketahanan.

Di mana logika fallback harus berada?

Sentralisasikan normalisasi provider, routing, budget percobaan, dan observability di gateway atau layer orkestrasi. Pertahankan intent khusus workflow—risiko efek samping, persyaratan skema, kebijakan keamanan, dan ambang kualitas—dekat dengan aplikasi.

Bagaimana tim harus meluncurkan fallback model otomatis?

Mulailah dalam mode shadow, canary hanya workflow yang aman untuk diulang, definisikan pemicu rollback sebelum memperluas traffic, dan sertifikasi ulang kebijakan fallback setiap kali model, prompt, tools, skema, kepemilikan retry, atau persyaratan keamanan berubah.

Bangun fallback berdasarkan risiko workflow

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

• Workflow 1 memulihkan request yang dapat diulang dengan retry dan kapasitas yang setara.
• Workflow 2 beralih model hanya setelah pemeriksaan kapabilitas dan kualitas.
• Workflow 3 menghentikan replay otomatis ketika output atau efek samping membuat pemulihan tidak aman.

Desain itu meningkatkan ketersediaan tanpa menyembunyikan kegagalan kontrak atau menduplikasi tindakan pengguna. Jika tim Anda sedang menstandardisasi akses di berbagai provider model, gunakan lapisan API terpadu yang kompatibel dengan OpenAI dari Flatkey sebagai permukaan integrasi, lalu kaitkan 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