𝗕𝗶𝗮𝘆𝗮 𝗧𝗲𝗿𝘀𝗲𝗯𝘂𝗻𝘆𝗶 𝗱𝗮𝗿𝗶 𝗔𝗜 𝗣𝗿𝗼𝗱𝘂𝗸𝘀𝗶
Bug terburuk di produksi tidak membuat sistem Anda crash. Mereka hanya gagal secara diam-diam.
Penyedia LLM mungkin mengalami gangguan parsial. Mereka mengembalikan status 200 OK, tetapi responsnya kosong atau tidak masuk akal. Tidak ada error. Tidak ada peringatan. Terlihat seperti berhasil, padahal sebenarnya gagal.
Inilah biaya nyata dari AI. Bukan tagihan API-nya. Melainkan kegagalan yang terlihat normal sampai seorang pengguna memberi tahu Anda bahwa ada sesuatu yang salah.
Saya menjalankan pipeline yang memberikan skor pada 10.000 lowongan kerja setiap hari. Saya menggunakan OpenAI, Anthropic, Gemini, DeepSeek, dan Groq. Berikut cara membangun fallback chain yang berfungsi.
Kebanyakan tim hanya menggunakan satu penyedia. Ini berhasil saat pengembangan. Lalu trafik produksi datang. Anda menghadapi rate limit, respons yang menurun kualitasnya, atau model yang sudah usang (deprecated).
Anda membutuhkan arsitektur tiga lapis:
- Layer 1: Model utama. Kualitas tinggi dan biaya tinggi.
- Layer 2: Model fallback. Kualitas baik dan biaya lebih rendah.
- Layer 3: Mode degradasi. Kualitas minimal dan biaya mendekati nol.
Setiap layer harus menggunakan penyedia yang berbeda. Jika satu penyedia mati, yang lain tetap berjalan.
Tips krusial: Jangan hanya memeriksa status HTTP. Anda harus memvalidasi output. Gunakan validasi skema untuk data terstruktur. Gunakan pengecekan panjang untuk teks.
Saya menggunakan tiga tier untuk tugas-tugas saya:
- Tier 1: Tugas kompleks. Saya menggunakan GPT-4o atau Claude 3.5 Sonnet.
- Tier 2: Klasifikasi. Saya menggunakan GPT-4o mini atau Gemini 2.0 Flash.
- Tier 3: Tugas yang kritis terhadap kecepatan. Saya menggunakan Groq atau DeepSeek V4 Flash.
Perutean ini memangkas biaya dengan hanya menggunakan model mahal saat diperlukan.
Jangan lupakan penyedia embedding Anda. Jika API embedding Anda gagal, pipeline RAG Anda akan berhenti bekerja. Saya memelihara dua penyedia embedding secara paralel untuk setiap pipeline.
Untuk menangkap kegagalan diam-diam, pantau tiga metrik ini:
- Waktu respons. Jika prompt yang kompleks kembali terlalu cepat, kemungkinan model mengembalikan respons yang tersimpan di cache atau kosong.
- Panjang output. Respons yang pendek adalah tanda bahaya.
- Kepatuhan skema. Periksa apakah kontennya benar-benar berguna atau hanya sekumpulan nilai null.
Fallback chain yang baik memastikan setiap permintaan mendapatkan respons yang dapat digunakan. Anda membayar untuk kapasitas ekstra, tetapi Anda melindungi kepercayaan pengguna.
Optional learning community: https://t.me/GyaanSetuAi