Buku petunjuk untuk layanan LLM yang sedang on-call
Pengaturan peringatan klasik untuk keterlambatan dan kesalahan tidak dapat mendeteksi kegagalan yang penting di sini: penurunan kualitas, degradasi penyedia, pertumbuhan konteks diam-diam. Buku petunjuk harus menamai sinyal-sinyal tersebut terlebih dahulu.
Sinyal yang Terlewatkan oleh Pemantauan Klasik
Latensi, tingkat kesalahan, dan kejenuhan menangkap kegagalan yang terlihat seperti infrastruktur. Layanan LLM memiliki keluarga kedua kegagalan yang tidak menghasilkan kesalahan dan permintaan lambat.
- Penurunan Kualitas. Sampel bulanan item evaluasi, dinilai dan diarahkan. Tanpa itu, degradasi dilaporkan oleh pengguna beberapa minggu kemudian, dalam bentuk ketidakpercayaan.
- Tingkat Penolakan. Meningkatnya tingkat penolakan sering kali menjadi tanda pertama yang terlihat dari masalah pengambilan atau penguraian, dan lebih murah untuk diselidiki daripada keluhan.
- Ukuran Konteks per Permintaan. Ini tumbuh secara diam-diam karena korpus dan riwayat percakapan menumpuk, dan memindahkan biaya dan latensi pada saat yang sama.
- Jumlah Token Keluaran. Perubahan distribusi di sini biasanya berarti perubahan prompt atau model, dan muncul di tagihan sebelum muncul di tempat lain.
- Kesehatan Penyedia. Tingkat kesalahan hanya satu sinyal dari penyedia; pergeseran latensi yang tidak terjelaskan dan perubahan bentuk respons juga penting, dan mereka adalah bagian terdepan dari insiden sisi penyedia.
Menulisnya agar Dapat Diikuti pada Pukul Tiga Pagi
Entri runbook memiliki empat bagian: sinyal, tindakan pertama, kondisi eskalasi, dan fallback. Tindakan pertama harus mekanis dan spesifik — tidak menyelidiki, tetapi: periksa halaman ini, bandingkan angka ini dengan nilainya dari seminggu yang lalu, dan jika delta melebihi ambang yang tercatat, lakukan ini.
Fallbacks termasuk dalam runbook karena mereka adalah keputusan, bukan improvisasi. Fallback yang mungkin termasuk routing ke penyedia yang berbeda, mengurangi model yang lebih kecil, mempersingkat konteks, menonaktifkan reranking, dan menonaktifkan fitur secara keseluruhan. Masing-masing memerlukan pemicu yang telah disepakati sebelumnya dan orang yang bernama yang dapat mengotorisasi.
Mode Degradasi yang Layak Dimiliki
- Konteks yang Lebih Singkat. Lebih sedikit passage yang diambil, kualitas yang lebih rendah, biaya dan latensi yang jauh lebih rendah. Murah untuk diimplementasikan dan biasanya hal pertama yang dijangkau.
- Model yang Lebih Kecil. Kualitas menurun secara tidak merata di seluruh jenis tugas; ketahui sebelumnya tugas mana yang dapat didegradasi secara dapat diterima dan mana yang harus gagal daripada menjawab dengan buruk.
- Cache-only. Melayani jawaban yang telah dihitung sebelumnya dan menolak apa pun yang baru. Jarang berlaku, tetapi menentukan ketika korpus sebagian besar pertanyaan yang stabil.
- Fitur Off. Fallback terakhir, dan satu-satunya yang harus selalu tersedia. Jika menonaktifkan fitur memerlukan penggunaan kembali, runbook belum selesai.
Praktik yang Biayanya Satu Jam per Kuartal
Latih jalur yang didegradasi dan sakelar fitur selama jam kerja, dan catat berapa lama waktu yang dibutuhkan masing-masing. Sakelar yang tidak diuji tidak berfungsi ketika diperlukan, dan kegagalan biasanya sepele — izin yang hanya dimiliki sistem penggunaan kembali, atau konfigurasi yang tidak pernah diuji di lingkungan tempat itu penting. Satu jam per kuartal adalah biaya keseluruhan untuk mengetahui jawabannya.
Yang bisa Anda lakukan sekarang
- Tambahkan kualitas, tingkat penolakan, dan ukuran konteks ke sinyal on-call
- Setiap peringatan memerlukan tindakan pertama yang tidak memerlukan penalaran di bawah tekanan
- Simpan mode degradasi yang didokumentasikan dan dapat diakses tanpa deploy