Ketika Permintaan Berhasil tetapi Pengalaman Tetap Gagal
Bayangkan Anda sudah berbicara dengan karakter yang sama selama berminggu-minggu. Suaranya terasa akrab, bahasanya konsisten, dan balasannya cerdas serta hidup.
Lalu, tanpa mengganti karakter atau model, tiba-tiba ada yang terasa salah.
Balasan berikutnya membutuhkan sepuluh detik untuk mulai muncul. Fitur yang bergantung pada output terstruktur mendadak rusak. Karakter mulai meracau, menyisipkan potongan bahasa lain, atau menjawab dengan gaya yang terasa seperti berasal dari model yang jauh lebih lemah.
Dari sudut pandang server, tidak ada kegagalan. API mengembalikan 200 OK, token tiba, dan permintaan tetap ditagihkan.
Dari sudut pandang pengguna, modelnya baru saja memburuk.
Kesenjangan inilah yang membuat kami membangun sistem probe canary penyedia dan karantina routing untuk Reverie.
Satu Nama Model, Banyak Lingkungan Inferensi
OpenRouter adalah gateway model utama kami. Salah satu kekuatannya adalah satu model dapat dijalankan oleh banyak penyedia inferensi independen. Jika satu penyedia tidak tersedia, penyedia lain dapat menerima permintaan. Ini memberi kami kapasitas lebih besar, harga yang kompetitif, dan ketahanan yang lebih baik dibanding bergantung pada satu endpoint.
Namun, hal itu juga menghadirkan variabel tersembunyi.
Nama model dapat tetap sama, sementara infrastruktur yang menjalankannya berubah dari satu permintaan ke permintaan lain. Setiap penyedia bisa memakai mesin inferensi, konfigurasi perangkat keras, tingkat kuantisasi, parser, template chat, antrean, atau lapisan kebijakan tambahan yang berbeda.
Dokumentasi routing penyedia OpenRouter menjelaskan bahwa routing default mempertimbangkan ketersediaan terbaru dan harga, dengan penyedia lain sebagai fallback. Sinyal tersebut penting, tetapi sebuah endpoint dapat tetap online dan murah sambil menghasilkan keluaran yang tidak dapat diterima untuk produk tertentu.
OpenRouter juga telah membahas secara terbuka perbedaan terukur antara penyedia yang menjalankan model yang sama. Secara teori, bobot identik dengan presisi identik seharusnya berperilaku serupa. Dalam produksi, menjalankan model besar itu rumit dan perbedaan pun muncul.
Apa yang Kami Maksud dengan “Degradasi Model”
“Degradasi model” bukan satu diagnosis baku, dan tidak otomatis berarti penyedia sengaja mengganti model dengan versi yang lebih kecil.
Kami menggunakan istilah ini secara operasional: sebuah endpoint inferensi mengalami degradasi ketika tidak lagi mempertahankan perilaku, kemampuan, atau performa interaktif yang kami harapkan dari model yang diminta pada prompt representatif, meskipun permintaan tersebut secara teknis berhasil.
Bagi Reverie, bentuk yang paling jelas adalah:
- Degradasi latensi: koneksi berhasil, tetapi waktu menuju token pertama cukup lama untuk merusak rasa percakapan langsung.
- Degradasi kemampuan: endpoint yang seharusnya mendukung output terstruktur menghasilkan teks yang salah format atau tidak lagi memenuhi schema.
- Degradasi perilaku: balasan menjadi rusak, tidak koheren, berulang secara tidak wajar, atau berpindah jelas ke bahasa lain.
- Ketidaksesuaian kebijakan: host upstream menambahkan lapisan filter sendiri dan mengubah adegan yang didukung Reverie menjadi penolakan, respons kosong, atau balasan terpotong.
Penyebabnya bisa beragam. Kuantisasi berpresisi lebih rendah dapat memengaruhi prompt yang sulit, sebagaimana dicatat dalam dokumentasi OpenRouter dan penelitian kuantisasi yang telah dipublikasikan. Namun, kuantisasi bukan penjelasan untuk segala hal: bug mesin inferensi, parser alat, kesalahan tokenizer atau template chat, antrean yang kelebihan beban, dan middleware penyedia dapat sama pentingnya. OpenRouter telah mengamati bahwa pada pemanggilan alat, implementasi parser sering menyebabkan lebih banyak variasi dibanding presisi saja.
Pertanyaan pentingnya bukan “penyebab mana yang terdengar paling mencurigakan?”, melainkan “dapatkah kita mengisolasi endpoint dan mereproduksi kegagalannya?”.
Dua Kasus yang Membuat Masalah Ini Nyata
Ini bukan kekhawatiran teoretis bagi kami.
Dalam perbandingan yang dikunci ke masing-masing penyedia, satu penyedia merusak awal 19 dari 20 balasan dengan menyisipkan tanda baca atau fragmen token yang tidak terkait. Pada empat belas host lain yang menjalankan model sama, masalah tersebut muncul 0 kali dalam 49 balasan. Dalam roleplay, karakter pertama sering berupa penanda penekanan Markdown, sehingga satu byte asing juga dapat merusak format seluruh balasan.
Dalam pengujian lain, satu endpoint menghasilkan campuran parah bahasa Portugis dan Spanyol dalam 3 dari 3 generasi. Prompt yang sama tetap menggunakan bahasa Portugis pada host resmi model dan host lain yang diuji dengan kelas presisi yang sama. “Model memang tidak konsisten” tidak lagi menjadi penjelasan yang memadai; cacat tersebut mengikuti endpoint.
Kegagalan seperti ini sulit terlihat karena tidak selalu memunculkan exception. Pemantauan uptime tradisional melihat API yang sehat. Pengguna melihat karakter yang tiba-tiba tidak dapat berbicara dengan benar.
Jawaban Kami: Uji Setiap Rute, Bukan Hanya Model
Setiap tiga puluh menit, canary kami menemukan penyedia aktif yang menjalankan model chat default Reverie. Sistem kemudian mengirimkan sekumpulan kecil permintaan sintetis kepada setiap penyedia, dikunci hanya ke penyedia tersebut dengan fallback dinonaktifkan.
Penguncian ini penting. Jika sebuah probe boleh menggunakan fallback, penyedia sehat kedua dapat menyembunyikan kegagalan penyedia pertama. Kami perlu tahu persis lingkungan inferensi mana yang menghasilkan keluaran.
Sistem menguji empat kontrak sempit yang dapat dinilai oleh kode.
1. Waktu Menuju Token Pertama
Dalam percakapan streaming, throughput hanyalah separuh pengalaman. Token pertama menentukan berapa lama pengguna menatap indikator pemuatan.
Kami mengukurnya langsung dari stream. Penyedia yang tidak menghasilkan teks dalam sepuluh detik gagal dalam probe latensi. Ambang ini sengaja dibuat longgar, dan satu putaran lambat tidak cukup untuk menyingkirkan host; tekanan antrean sementara memang dapat terjadi.
2. Filter dan Penolakan Diam-diam
Kami mengirimkan kelanjutan roleplay tetap yang mewakili traffic yang didukung Reverie. Probe memeriksa alasan penyelesaian, pola penolakan berkeyakinan tinggi, dan output kosong.
Kami juga menjalankannya terhadap host yang diketahui menerapkan filter sebagai kontrol positif. Jika suatu kontrol tiba-tiba lolos, kami tidak menyatakan semua penyedia lain sehat; kami menandai probe itu sendiri sebagai lemah. Pengujian yang tidak lagi mampu mendeteksi kegagalan yang sudah diketahui bukanlah bukti kesehatan.
3. Output Terstruktur
Kami meminta objek kecil dengan schema tetap dan memvalidasi hasilnya. Kesalahan transport dan output yang salah format diperlakukan berbeda: koneksi terputus berarti penyedia tidak dapat dijangkau, sedangkan generasi selesai yang gagal memenuhi schema menunjukkan regresi kemampuan.
“Endpoint menyatakan mendukung parameter” dan “endpoint menjalankannya secara andal” bukan janji yang sama.
4. Integritas Bahasa
Reverie mendukung 17 bahasa antarmuka, sehingga smoke test berbahasa Inggris saja akan melewatkan sebagian kegagalan yang benar-benar dialami pengguna kami.
Canary bergiliran menguji bahasa yang didukung dengan prompt roleplay sintetis. Pendeteksi bahasa lokal dan deterministik mencari peralihan bahasa penuh yang meyakinkan, pencampuran bahasa berkelanjutan, serta kerusakan encoding yang jelas. Sistem tidak menggunakan percakapan nyata dan tidak meminta model lain memberikan penilaian subjektif.
Output ambigu atau terlalu pendek dianggap tidak konklusif, bukan gagal. Ketika anomali bahasa terdeteksi, canary segera melakukan dua percobaan konfirmasi dan memerlukan hasil mayoritas. Bahasa yang sama diulang pada putaran berikutnya agar penyedia tidak lolos dari aturan putaran berturut-turut hanya karena rotasi telah bergerak.
Kami Merancang Sistem untuk Meragukan Kesimpulannya Sendiri
Menghapus kapasitas inferensi secara otomatis berguna, tetapi false positive dapat menimbulkan gangguan yang lebih besar daripada cacat awal. Karena itu, canary memiliki beberapa pengaman:
- Kesalahan transport tidak dihitung sebagai kegagalan kualitas. Timeout, rate limit, dan respons 5xx membekukan skor alih-alih memperpanjang rangkaian menuju suspensi.
- Satu putaran buruk tidak cukup. Penyedia harus gagal pada dua putaran berturut-turut yang dijalankan setiap setengah jam.
- Observasi dan penegakan dipisahkan. Kami dapat menjalankan sistem dalam mode observasi, mencatat host yang seharusnya ditangguhkan, memberi tahu administrator, dan mengukur false positive sebelum mengaktifkan tindakan otomatis.
- Kapasitas memiliki batas bawah. Canary tidak menangguhkan penyedia jika tindakan itu menyisakan kurang dari dua host produksi. Sebagai gantinya, administrator akan diperingatkan.
- Pemulihan juga diuji. Penyedia yang ditangguhkan tetap menerima probe. Dua putaran bersih berturut-turut memulihkan host lebih awal.
- Kegagalan berulang meningkat secara bertahap. Suspensi berlangsung satu hari untuk insiden pertama, tiga hari untuk insiden berikutnya, lalu tujuh hari. Setelah empat belas hari tanpa suspensi baru, riwayat memudar dan tangga dimulai kembali.
Tujuannya bukan menghukum penyedia. Tujuannya adalah memindahkan traffic pengguna dari rute yang terbukti tidak sehat, sekaligus meninggalkan jalur kembali yang jelas setelah masalah diperbaiki.
Tiga Lapisan Perlindungan
Keputusan routing akhir menggabungkan tiga jenis pengecualian:
- Pengecualian bawaan yang telah ditinjau untuk cacat atau ketidaksesuaian kebijakan yang sudah kami ukur dan tidak ingin kami hadirkan kembali secara tidak sengaja.
- Pengecualian insiden saat runtime yang dapat ditambahkan administrator segera tanpa menunggu deployment.
- Suspensi canary berbatas waktu untuk penyedia yang melewati ambang kegagalan otomatis.
Daftar tersebut digabungkan ke preferensi provider.ignore OpenRouter ketika Reverie membuat permintaan. Pengguna tidak perlu mencoba lagi sampai kebetulan mendapatkan penyedia yang lebih baik; rute tidak sehat dikeluarkan dari kandidat.
Setiap keputusan otomatis dicatat, administrator diberi tahu pada perubahan status penting, dan suspensi dapat dicabut secara manual jika diperlukan.
Apa yang Dijamin Sistem Ini — dan Apa yang Tidak
Canary sengaja dibuat sempit. Kode dapat menilai latensi, validitas schema, filter berkeyakinan tinggi, integritas bahasa, dan kesehatan encoding. Sistem tidak berpura-pura dapat menilai apakah karakter cukup lucu, cukup peka secara emosional, atau setia pada kepribadian yang kompleks.
Pertanyaan yang lebih luas itu masih memerlukan evaluasi dengan prompt representatif, tinjauan manusia, telemetri produksi, dan yang terpenting, laporan pengguna.
Sistem ini juga tidak berarti setiap balasan aneh membuktikan degradasi. Model generatif bersifat probabilistik. Percakapan panjang dapat mengumpulkan konteks yang bertentangan, dan definisi karakter dapat berisi instruksi yang saling bersaing. Terkadang balasan aneh hanyalah balasan aneh.
Yang berubah adalah “modelnya sama” tidak lagi mengakhiri penyelidikan kami. Kini kami dapat mengisolasi rute pelayanan, mereproduksi kegagalan objektif, dan menjauhkan traffic berikutnya dari rute tersebut.
Keandalan Berarti Menjaga Pengalaman
Routing multipenyedia tetap berharga. Sistem ini memberikan Reverie kapasitas dan ketahanan untuk menjaga percakapan tetap tersedia ketika endpoint tertentu mati.
Namun, ketahanan bukan sekadar menerima respons HTTP. Balasan yang terlambat dimulai, kehilangan struktur wajib, menolak konten yang didukung, atau tiba-tiba berpindah bahasa tidak menjadi sehat hanya karena tagihan menyatakan permintaan berhasil.
Untuk produk karakter AI, keandalan berarti sesuatu yang lebih manusiawi: karakter harus tetap terasa sebagai karakter yang sama, mesin mana pun yang kebetulan berbicara untuknya.
Itulah standar yang ingin dijaga oleh perlindungan routing baru kami.
Jika Anda melihat perubahan mendadak pada kualitas atau bahasa balasan, kirimkan laporan dengan nama model dan perkiraan waktunya. Informasi itu membantu kami menghubungkan pengalaman yang Anda lihat dengan rute persis yang melayaninya.