Masalah lokasi kesalahan setelah pengurangan biaya dalam perutean multi-model

Pertama kali saya merasa ada yang tidak beres saat online adalah keluhan yang sulit dijelaskan: pengguna yang sama menanyakan pertanyaan yang sama tiga kali dalam waktu 5 menit. Pertama kali dia merespons dengan baik, kedua kalinya dia mulai berbicara omong kosong, dan ketiga kalinya dia kembali normal.

Tidak ada kelainan pada log, latensi stabil, dan penggunaan token tidak melonjak. Satu-satunya perubahan yang dapat dilihat adalah kami baru saja mengaktifkan “perutean multi-model” dan menggunakan model yang lebih murah untuk mencakup sebagian lalu lintas.

Pada saat itu, intuisi tim sangat konsisten: modelnya adalah distribusi probabilitas, dan fluktuasinya normal. Selain itu, routing hanya merupakan satu lapisan gateway, jadi masalah besar apa yang bisa terjadi?

Dalam dua minggu berikutnya, kami berkali-kali menderita akibat hukuman ini.

Penilaian inti

Biaya inti dari perutean multi-model adalah mengubah perilaku permintaan yang sama dari “dapat direproduksi” menjadi “distribusi probabilitas”.

Di era model tunggal, betapapun sulitnya suatu masalah online, selama Anda mendapatkan masukan, prompt, konteks, dan nomor versi, kemungkinan besar Anda dapat mereproduksinya di lingkungan tertentu, dan kemudian mengikuti rantai panggilan untuk menentukan akar masalahnya.

Setelah perutean dilibatkan, masalahnya akan menjadi:

-Model apa, versi apa, dan kumpulan parameter apa yang saya gunakan saat ini?

• Mengapa rute dipilih dengan cara ini, dan karakteristik apa yang dicapai ambang batas tersebut?
• Apakah Anda mengambil jalur berbeda dua kali dalam sesi yang sama?
• Ketika terjadi kegagalan, apakah mungkin untuk menjalankan kembali “keputusan yang diambil saat itu”?

Jika tidak ada log yang dapat dilacak dan mekanisme rollback, kesalahan online akan ditingkatkan dari “model tidak akurat” menjadi “akar penyebab yang tidak dapat ditemukan”.

Bagaimana segalanya menjadi lebih sulit langkah demi langkah

Kami hanya mengadopsi strategi paling sederhana di awal: gunakan model kecil bila memungkinkan, dan hanya tingkatkan ke model besar jika “terlihat rumit”.

Yang disebut “terlihat rumit” adalah beberapa fitur murah: panjang input, apakah berisi blok kode, apakah ada beberapa putaran dialog, dan kepercayaan dari pengklasifikasi kecil.

Gelombang masalah pertama setelah online adalah metode pemecahan masalah gagal.

Perintah yang sama tidak dapat direproduksi oleh rekan penguji di lingkungan skala abu-abu, dan tidak dapat direproduksi secara lokal oleh pengembang. Pada akhirnya, hanya pengguna online yang dapat memicunya secara stabil.

Kami pernah curiga bahwa ini adalah bug dalam penyambungan konteks, caching, atau pasca-pemrosesan. Baru setelah kami menangkap masukan lengkap dari permintaan, kami menemukan bahwa model kecil digunakan secara online kali ini, dan model besar digunakan secara default saat kami mereproduksinya.

Ini adalah “perubahan jalur”.

Perubahan jalur mengubah pemecahan masalah dari “input berulang” menjadi “keputusan berulang”. Keputusan tidak dapat diulang pada saat itu.

Kesalahpahaman 1: Perlakukan perutean sebagai pengoptimalan biaya murni

Apa yang Anda lihat di tabel biaya adalah:

• 30% lalu lintas ditujukan ke model kecil
• Rata-rata biaya per panggilan turun 18%

Namun yang tidak dapat Anda lihat di tabel kesalahan adalah:

• Setiap masalah kualitas akan memerlukan waktu 1-2 hari tambahan untuk menentukan apakah masalah tersebut disebabkan oleh perutean.
• Reproduksi online memerlukan “konteks pengambilan keputusan” yang lebih lengkap
• Rollback bukan lagi “model rollback”, tetapi “strategi rollback + ambang batas rollback + logika ekstraksi fitur rollback”

Ketika Anda memperlakukan perutean sebagai perubahan ringan seperti “mengganti pemasok”, Anda pasti harus membayar bunga nanti dalam pemecahan masalah.

Kesalahpahaman 2: Menafsirkan ketidakstabilan sebagai “LLM pada dasarnya acak”

Sebagian besar masalah yang disebabkan oleh keacakan suatu model adalah “mengambil sampel masukan yang sama beberapa kali dengan keluaran berbeda”.

Masalah yang disebabkan oleh keacakan perutean adalah “input yang sama masuk ke sistem yang berbeda”.

Keduanya tampak seperti fluktuasi, tetapi didiagnosis dengan cara yang sangat berbeda.

Yang pertama sering kali menyesuaikan suhu, perintah sistem, dan menambahkan batasan; yang terakhir harus menjawab terlebih dahulu: Apakah kali ini mereka salah jalan?

Tanpa routing log keputusan, tim akan jatuh ke dalam kebiasaan yang sangat buruk: menghubungkan semua anomali dengan “ketidakstabilan model”, sehingga strategi menjadi semakin agresif, dan kualitasnya menjadi semakin seperti dadu.

Tiga jenis ketertelusuran yang sangat perlu diselesaikan

Untuk menjadikan perutean sebagai sistem yang “dapat dipecahkan”, setidaknya tiga jenis rekaman harus diselesaikan, dan harus dapat dirangkai dalam satu dimensi permintaan.

1) Log keputusan perutean (log keputusan)

Tidak hanya mencatat “model mana yang dipilih”, tetapi juga mencatat:

• Kumpulan kandidat (model apa yang tersedia saat itu)
• Penilaian atau penilaian ambang batas untuk setiap kandidat
• Nilai fitur yang digunakan (panjang masukan, hitungan multi-putaran, keluaran pengklasifikasi, dll.)
• Nomor versi kebijakan (sangat penting)

Hanya dengan cara inilah kita dapat menjawab “Mengapa saya memilihnya kali ini?”

2) Meminta snapshot (memutar ulang snapshot)

Setidaknya hal-hal berikut harus tersedia jika terjadi kegagalan:

• Masukan pengguna mentah
• Prompt benar-benar dikirim ke model (termasuk kata-kata prompt sistem, konteks yang disambung, dan hasil alat)
• Konfigurasi kunci (suhu, top_p, max_tokens, stop, dan sakelar pasca-pemrosesan sendiri)

Tanpa snapshot, pengulangan hanyalah dugaan saja.

3) Perutean kembalikan (kembalikan primitif)

Rollback harus cukup “kasar” dan dapat dijalankan dengan satu klik:

• Memaksa semua pemain untuk mengikuti model stabil tertentu
• Atau memperbaiki versi strategi tertentu

Jangan berharap untuk sementara mengubah ambang batas jika terjadi kecelakaan. Yang dibutuhkan dalam suatu kecelakaan adalah kepastian.

Kasus kegagalan: “ambang batas adaptif” yang tampaknya cerdas

Kami kemudian mencoba pendekatan yang lebih “cerdas”: secara dinamis menyesuaikan ambang batas berdasarkan kualitas sinyal 10 menit terakhir untuk memungkinkan model kecil menerima lebih banyak lalu lintas.

Hasilnya adalah osilasi diri yang sangat khas:

• Model kecil menelan lebih banyak dan kualitas sinyal menjadi buruk
• Ambang batas dinaikkan, model besar menelan lebih banyak, dan kualitas sinyal menjadi lebih baik.
• Ambang batas diturunkan, dan model kecil menelan lebih banyak

Secara eksternal, hal ini terlihat seperti “saat baik dan buruk”, namun secara internal strategi ini sedang goyah.

Jika tidak ada nomor versi kebijakan dan log keputusan untuk masalah seperti ini, pada dasarnya tidak mungkin menjelaskannya dengan jelas, apalagi memperbaikinya.

Batasan yang berlaku

Perutean multi-model bukan tidak mungkin, namun lebih cocok untuk tim yang memenuhi prasyarat berikut:

• Apakah diperbolehkan membayar biaya penyimpanan tambahan dan kepatuhan privasi untuk ketertelusuran?
• Memiliki metrik dan peringatan kualitas yang jelas, daripada mengandalkan keluhan pengguna
• Dapatkah strategi dipertahankan sebagai “sistem online” dengan versi, skala abu-abu, dan rollback?

Jika observabilitas saat ini masih sebatas “volume permintaan, penundaan, kode kesalahan”, maka jangan terburu-buru melakukan perutean yang rumit dulu. Uang yang dihemat mungkin hilang dalam waktu pemecahan masalah.

Ringkasan

Hal yang paling diremehkan tentang perutean multi-model adalah ia mengubah objek pemecahan masalah.

Yang dulunya direproduksi adalah masukan, namun kini yang perlu direproduksi adalah pengambilan keputusan. Tanpa log keputusan, snapshot permintaan, dan rollback primitif, kegagalan online akan menjadi “acak” yang tidak dapat dijelaskan dan diperbaiki.

Akun pengurangan biaya mudah untuk dihitung, sedangkan akun berulang adalah yang paling sulit untuk dihitung, tetapi pada akhirnya pasti akan muncul dalam tinjauan kecelakaan.