Kalau aplikasi kamu memakai beberapa model AI, memilih yang termurah dari panjang pesan saja bisa keliru. Satu kalimat yang meminta perubahan rekening dapat membutuhkan kendali lebih ketat daripada rangkuman panjang bahan publik. Panjang teks belum menjadi ukuran tunggal kesulitan.
Penentuan jalur ke model disebut routing. Mulailah dari batas yang wajib dipenuhi, lalu bandingkan kualitas, waktu tunggu, dan biaya. Contoh di sini memakai profil fiktif yang bisa diperiksa tanpa memanggil layanan, bukan hasil uji kinerja atau pengaturan yang disarankan untuk semua organisasi.
Saring syarat wajib sebelum membandingkan pilihan
Periksa kelas data, wilayah pemrosesan yang disetujui, jenis masukan dan keluaran, aturan bentuk hasil, serta hak penggunaan. Jika salah satunya tidak terpenuhi, keluarkan profil itu dari pilihan. Model yang cepat tetap tidak bisa dipilih bila tidak boleh menerima datanya.
Sesudah itu, bandingkan pilihan yang sah menurut hasil uji tugas. Label “besar” atau “kecil” belum cukup untuk menilai kualitas. Simpan versi profil agar keputusan bisa ditelusuri saat daftar model berubah.
Berikut contoh daftar profil internal:
| Profil fiktif | Tugas yang sudah diuji | Kelas data | Catatan |
|---|---|---|---|
brief-fast-v1 |
Rangkuman bahan publik | publik | Hasil dibatasi singkat |
document-v1 |
Mengambil isi dokumen visual | publik, internal | Perlu dukungan dokumen |
analysis-v1 |
Analisis beberapa sumber | publik | Tetap perlu pemeriksaan editor |
Daftar ini tidak menyatakan kemampuan produk nyata. Saat dipakai, setiap baris perlu terhubung ke pengaturan layanan yang tersedia dan sudah diperiksa.
Bedakan apa yang diukur dari targetnya
Google SRE membedakan indikator mutu layanan, atau service level indicator (SLI), dari target mutu layanan, atau service level objective (SLO). Untuk aplikasi AI, kamu bisa mengukur bagian hasil valid yang diterima sebelum tenggat atau deadline. Jawaban sukses dari penyedia dengan kode HTTP 200 saja belum mencakup hal itu.
Tentukan kapan pengukuran dimulai dan selesai. Jika pengguna menunggu sampai pemeriksaan hasil selesai, durasinya perlu masuk waktu tunggu atau latensi. Draf yang baru ditinjau beberapa jam kemudian punya pengalaman pemakaian berbeda dari percakapan interaktif.
Contoh target internal fiktif adalah sebagian tertentu ringkasan bahan publik selesai dengan bentuk yang sesuai dalam tenggat tim. Itu bukan klaim tingkat layanan penyedia. Ketepatan fakta tetap perlu ukuran terpisah, karena jawaban cepat bisa tetap salah.
Pilih biaya setelah memeriksa kelayakan
Sebelum melihat kode, kenali p95 sebagai batas waktu tunggu yang masih mencakup hampir semua permintaan. Contoh Python ini memilih biaya perkiraan terendah setelah memeriksa syarat wajib dan batas latensi:
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 menganggap daftar profil sudah diperiksa. Perkiraan p95 tidak menjamin setiap permintaan selesai dalam batas itu. Pada aplikasi yang dipakai pengguna, tambahkan pemeriksaan aturan keluaran, wilayah, kuota, dan keadaan layanan yang relevan.
Jika tidak ada pilihan yang memenuhi syarat, kembalikan status yang jelas. Jangan beralih ke jalur cadangan, atau fallback, tanpa izin.
Satu tenggat berlaku untuk seluruh pekerjaan
Jika tenggat pengguna 10 detik, tiga percobaan dengan batas tunggu masing-masing 10 detik sudah melewati janji pengalaman tersebut. Batas tunggu satu pemanggilan disebut timeout. Hitung sisa tenggat keseluruhan, lalu bagi untuk koneksi, model, alat bantu, dan pemeriksaan hasil.
Uraian AWS mengenai timeout dan retry menjelaskan bahwa percobaan ulang atau retry dapat menambah beban layanan yang sedang bermasalah. Batasi percobaan dan gunakan jeda yang meningkat atau backoff, dengan variasi acak atau jitter. Periksa juga apakah perangkat penghubung layanan atau SDK dan aplikasimu sama-sama mencoba ulang sehingga jumlahnya berlipat.
Kesalahan identitas, masukan tidak valid, dan pelanggaran kebijakan perlu perbaikan, bukan pengulangan panggilan yang sama. Pisahkan masalah yang mungkin sementara dari masalah yang memerlukan perubahan masukan atau pengaturan.
Jalur cadangan tetap harus memenuhi tugas yang sama
Fallback bisa memakai profil yang sudah disetujui atau mengembalikan tugas ke antrean pemeriksaan. Jika profil kedua tidak bisa membaca dokumen visual, teks hasil pengambilan yang kehilangan grafik tidak boleh dianggap setara. Pergantian jalur tidak boleh diam-diam mengubah arti hasil.
Pisahkan pembuatan hasil dari tindakan di luar proses, atau efek samping. Membuat draf kedua berbeda dari mengirim pesan kedua. Simpan identitas tugas dan langkahnya agar pemulihan model tidak menggandakan tindakan, seperti dibahas dalam panduan antrean dan idempotensi.
Panggilan ke profil yang terus gagal dapat dihentikan sementara lewat circuit breaker. Tentukan rentang pengamatan, ambang kegagalan, waktu tunggu, dan percobaan untuk memeriksa pemulihan atau probe. Satu pengguna dengan masukan salah tidak semestinya membuat seluruh layanan ditutup.
Uji keadaan yang seharusnya ditolak atau gagal
Siapkan kasus data internal yang hanya punya calon profil publik, tenggat terlalu pendek, dan semua profil dinonaktifkan. Tambahkan penyedia yang melewati batas tunggu serta hasil fallback yang gagal diperiksa. Tulis dulu hasil yang diharapkan untuk tiap kasus.
Catat profil yang dipertimbangkan, alasan penolakan, versi kebijakan, dan profil terpilih. Catatan proses atau log tidak perlu memuat isi data sensitif hanya demi menjelaskan keputusan routing. Ukur frekuensi fallback, retry per tugas, hasil diterima, dan biaya tambahannya.
Uji ulang saat model atau aturan layanan berubah. Kode pemilih yang benar masih bisa memberi pilihan buruk bila perkiraannya usang. Gunakan contoh acuan dan uji perubahan agar aturan pemilihan tetap sesuai mutu pekerjaan nyata.
