Belajar AI Engineer - Production Reliability AI

#Pendahuluan

Episode 16-24 membangun kemampuan. Episode ini memastikan semuanya tetap berjalan: reliability. Produk AI punya lapisan kegagalan yang unik — provider LLM down, model menjawab aneh, biaya melonjak, kualitas menurun diam-diam. Produk yang andal bukan yang tidak pernah gagal, melainkan yang gagal dengan anggun.

Mengapa penting? Karena pengguna tidak peduli penyebab error — mereka peduli produk bekerja. Satu outage LLM provider di jam sibuk seharusnya berarti degradasi halus (jawaban lebih lambat via fallback), bukan halaman error. Episode ini membangun pola yang membuat perbedaan itu.

#Retry dengan Exponential Backoff

Penyebab paling umum kegagalan: rate limit (429) dan timeout (5xx) dari provider. Pola yang benar: retry dengan backoff + jitter, bukan retry langsung (yang justru memperkuat beban):

Retry dengan exponential backoff

import time
import random
from openai import OpenAI
 
client = OpenAI()
 
def call_with_retry(messages: list[dict], max_retries: int = 4) -> str:
    for attempt in range(max_retries):
        try:
            r = client.chat.completions.create(
                model="gpt-4o-mini", messages=messages)
            return r.choices[0].message.content
        except Exception as e:
            if attempt == max_retries - 1:
                raise
            wait = (2 ** attempt) + random.uniform(0, 0.5)
            print(f"retry {attempt + 1} setelah {wait:.1f}s: {e}")
            time.sleep(wait)
    raise RuntimeError("unreachable")

Aturan backoff: eksponensial (2^n) + jitter (acak kecil). Jitter mencegah semua klien retry di detik yang sama (thundering herd). Sebagian besar SDK modern punya retry bawaan — aktifkan dan konfigurasi, jangan tulis sendiri kecuali butuh kontrol.

#Fallback: Cadangan Saat Provider Gagal

Retry menangani kegagalan sementara. Untuk kegagalan berkepanjangan, butuh fallback — jalur cadangan yang diaktifkan otomatis:

Fallback multi-provider

PROVIDERS = [
    {"name": "openai", "model": "gpt-4o-mini"},
    {"name": "anthropic", "model": "claude-3-5-haiku"},
    {"name": "local", "model": "qwen3:8b", "base_url": "http://localhost:8000/v1"},
]
 
def robust_call(messages: list[dict]) -> str:
    last_error = None
    for p in PROVIDERS:
        try:
            return provider_call(p, messages)
        except Exception as e:
            last_error = e
            print(f"fallback: {p['name']} gagal ({e}), coba berikutnya")
    raise RuntimeError(f"semua provider gagal: {last_error}")

Hierarki fallback yang baik: API utama → API cadangan → model lokal. Untuk workload non-kritis, model lokal di tier terakhir bisa memberi jawaban "cukup" alih-alih gagal total. Kombinasikan dengan circuit breaker — jika OpenAI gagal 5x dalam 1 menit, lewati langsung sampai pulih:

Circuit breaker sederhana

class CircuitBreaker:
    def __init__(self, fail_threshold: int = 5, cooldown: int = 60):
        self.failures = 0
        self.threshold = fail_threshold
        self.cooldown = cooldown
        self.open_until = 0.0
 
    def allow(self) -> bool:
        if time.time() < self.open_until:
            return False
        return True
 
    def record_failure(self) -> None:
        self.failures += 1
        if self.failures >= self.threshold:
            self.open_until = time.time() + self.cooldown
            self.failures = 0
 
    def record_success(self) -> None:
        self.failures = 0

#Evaluation Gate: Jangan Deploy yang Menurunkan Kualitas

Di episode 9 kita membangun eval suite. Sekarang jadikan itu gate — setiap deploy harus lolos evaluasi sebelum masuk produksi:

Evaluation gate di pipeline

BASELINE_FAITHFULNESS = 0.85
 
def deploy_gate(new_system) -> bool:
    skor = run_eval_suite(new_system)          # episode 9
    if skor["faithfulness"] < BASELINE_FAITHFULNESS:
        print("GAGAL: faithfulness turun, deploy dibatalkan")
        return False
    if skor["answer_relevancy"] < skor["answer_relevancy_baseline"] * 0.95:
        print("GAGAL: relevansi turun >5%")
        return False
    print(f"LOLOS: {skor}")
    return True

Gagal-gate bisa berarti: prompt berubah buruk, chunking rusak, data pipeline kotor, atau model provider berubah diam-diam. Ini persis saat eval suite membayar kembali investasinya.

#A/B Testing Model

Ketika ragu antara dua model atau dua prompt, jangan tebak — ukur. Pola A/B sederhana:

A/B testing model

import random
 
def serve(question: str, features: dict) -> str:
    bucket = random.random()
    variant = "B" if bucket < features["b_weight"] else "A"
    if variant == "B":
        return llm_call("gpt-4o", question, features.get("prompt_b"))
    return llm_call("gpt-4o-mini", question, features.get("prompt_a"))

Ukur dengan metrik produk: approval rate, retry, churn — bukan hanya skor eval. A/B yang baik butuh traffic; untuk volume kecil, andalkan evaluasi offline (golden dataset) yang lebih teliti. Episode 26 dan 27 akan menutup dengan konteks pasar.

#Common Pitfalls

• Retry tanpa backoff: retry langsung memperkuat beban provider yang sedang down.
• Fallback tanpa circuit breaker: provider yang mati terus dicoba, menambah latensi tiap request.
• Deploy tanpa gate: perubahan prompt "kecil" masuk produksi tanpa evaluasi — regresi diam-diam.
• Satu jalur saja: tidak ada fallback = setiap kegagalan provider adalah kegagalan produk.

#Penutup

Inti yang harus dibawa pulang:

• Retry dengan exponential backoff + jitter untuk 429/5xx.
• Fallback multi-provider + circuit breaker untuk kegagalan berkepanjangan.
• Evaluation gate di CI dan berkala — kualitas adalah syarat deploy.
• A/B testing untuk keputusan model/prompt berdasarkan data produk.

Di episode 26 selanjutnya kita melihat gambaran besar: ekosistem & tren modern 2026 — agentic AI, voice agents, RAG as default, local models, dan peta karier AI engineer di pasar kerja saat ini. Sampai jumpa di episode 26!