Routing model tanpa tebakan: fallback, deadline, dan SLO

Sebuah aplikasi memilih model termurah untuk permintaan pendek dan model besar untuk permintaan panjang. Aturan itu mudah ditulis, tetapi panjang teks bukan ukuran tunggal kesulitan. Satu kalimat yang meminta perubahan rekening dapat memerlukan kontrol lebih ketat daripada ringkasan panjang materi publik.

Routing model sebaiknya dimulai dari batas yang wajib dipenuhi, kemudian kualitas, latensi, dan biaya. Rancangan di artikel ini memakai profil fiktif agar logikanya dapat diperiksa tanpa memanggil layanan. Ia bukan benchmark atau konfigurasi rekomendasi untuk semua organisasi.

Bedakan syarat keras dari preferensi

Syarat keras mencakup kelas data, region yang disetujui, modalitas, kontrak output, dan hak penggunaan. Profil yang tidak memenuhi salah satunya harus dikeluarkan sebelum biaya dibandingkan. Model yang cepat tetapi tidak boleh menerima input tersebut bukan kandidat yang valid.

Preferensi baru dinilai di antara kandidat yang sah. Gunakan hasil evaluasi tugas untuk menilai kualitas, bukan label “besar” atau “kecil”. Catat versi profil agar keputusan routing dapat direproduksi ketika daftar model berubah.

Contoh katalog internal:

Daftar ini tidak menyatakan kemampuan produk nyata. Pada implementasi, setiap baris perlu menunjuk konfigurasi layanan yang benar-benar tersedia dan telah diperiksa.

SLI menjelaskan pengukuran, SLO menjelaskan target

Google SRE membedakan service level indicator dari service level objective. Untuk produk AI, indikator dapat berupa proporsi hasil valid yang diterima sebelum deadline, bukan sekadar HTTP 200 dari provider.

Definisikan awal dan akhir pengukuran. Jika pengguna menunggu sampai hasil lolos validator, waktu validasi harus masuk latensi. Jika produk membuat draf untuk review beberapa jam kemudian, pengalaman yang diukur berbeda dari chatbot interaktif.

Contoh target internal fiktif: sebagian tertentu dari brief publik selesai dengan struktur valid dalam tenggat yang ditetapkan tim. Jangan memakai target contoh sebagai klaim tingkat layanan provider. Kualitas faktual juga perlu indikator terpisah karena respons cepat dapat tetap salah.

Selector lokal menolak kandidat yang melanggar batas

Kode Python berikut memilih berdasarkan biaya estimasi hanya setelah syarat keras dan batas latensi diperiksa:

def choose_profile(profiles, task, data_class, deadline_ms):
    eligible = [p for p in profiles
                if task in p["tasks"]
                and data_class in p["data_classes"]
                and p["enabled"]
                and p["estimated_p95_ms"] <= deadline_ms]
    if not eligible:
        return None
    return min(eligible,
               key=lambda p: (p["estimated_cost"], p["name"]))["name"]


profiles = [
    {"name": "public-fast", "tasks": ["brief"],
     "data_classes": ["public"], "enabled": True,
     "estimated_p95_ms": 2000, "estimated_cost": 1},
    {"name": "internal", "tasks": ["brief"],
     "data_classes": ["public", "internal"], "enabled": True,
     "estimated_p95_ms": 3500, "estimated_cost": 2}
]
print(choose_profile(profiles, "brief", "internal", 4000))

Contoh mengasumsikan katalog sudah tervalidasi. Estimasi p95 tidak menjamin setiap permintaan selesai dalam batas tersebut. Pada produksi, tambahkan pemeriksaan kontrak, region, kuota, dan kondisi layanan yang relevan. Ketiadaan kandidat harus menghasilkan status eksplisit, bukan fallback tanpa izin.

Deadline berlaku untuk seluruh pekerjaan

Jika pengguna memberi tenggat 10 detik, tiga percobaan yang masing-masing memiliki timeout 10 detik sudah melanggar kontrak pengalaman. Hitung sisa waktu dari deadline menyeluruh, lalu alokasikan untuk koneksi, model, tool, dan validasi.

Uraian AWS mengenai timeout dan retry menjelaskan mengapa retry dapat memperbesar beban layanan yang sedang bermasalah. Gunakan batas percobaan, backoff, dan jitter. Perhatikan apakah SDK dan aplikasi sama-sama melakukan retry sehingga jumlah percobaan berlipat.

Error autentikasi, input tidak valid, dan pelanggaran kebijakan tidak diselesaikan dengan mengulang panggilan yang sama. Pisahkan kegagalan yang mungkin sementara dari kegagalan yang memerlukan perubahan input atau konfigurasi.

Fallback harus mempertahankan kontrak pekerjaan

Fallback dapat berpindah ke profil yang telah disetujui atau mengembalikan tugas ke antrean review. Keduanya lebih jelas daripada mengubah arti keluaran. Jika profil kedua tidak mendukung dokumen visual, ia tidak boleh menerima teks hasil ekstraksi yang kehilangan grafik lalu dianggap setara.

Jangan mengulang efek samping bersama generasi. Menghasilkan draf kedua berbeda dari mengirim pesan kedua. Simpan identitas pekerjaan dan langkah agar pemulihan model tidak menggandakan tindakan eksternal. Rancangan antrean dan idempotensi membahas bagian tersebut secara terpisah.

Circuit breaker dapat menghentikan sementara panggilan ke profil yang terus gagal. Definisikan jendela pengamatan, ambang, waktu tunggu, dan probe pemulihan. Hindari menutup seluruh layanan hanya karena satu pengguna mengirim input yang salah.

Uji kebijakan dengan skenario negatif

Siapkan kasus: data internal hanya memiliki kandidat publik; deadline terlalu pendek; semua profil dinonaktifkan; provider mengembalikan timeout; hasil fallback tidak lolos validator. Untuk setiap kasus, tulis hasil yang diharapkan sebelum menjalankan sistem.

Simpan jejak keputusan berisi profil yang dipertimbangkan, alasan penolakan, versi kebijakan, dan profil terpilih. Hindari memasukkan isi data sensitif ke log hanya untuk menjelaskan routing. Ukur frekuensi fallback, retry per pekerjaan, hasil diterima, dan biaya tambahan.

Evaluasi ulang saat model atau kontrak layanan berubah. Selector yang benar secara kode dapat tetap memilih buruk bila katalognya berisi estimasi usang. Gunakan golden set dan tes regresi untuk menjaga hubungan antara aturan routing dan kualitas pekerjaan yang sebenarnya.