Keuntungan:
- Kemampuan untuk mengenali penyebab diam dari degradasi model (penyimpangan data, penyimpangan konsep, kesalahan hulu) dan membangun pemantauan tiga lapis (operasional, masukan, keluaran)
- Kemampuan untuk mengevaluasi sistem LLM dalam beberapa lapisan dengan pemeriksaan aturan, wasit LLM dan evaluasi manusia, dan mengkalibrasi dengan jangkar manusia wasit LLM
- Kemampuan untuk merancang set evaluasi yang berisi kasus tepi dan keamanan dan mengubah setiap kesalahan yang tertangkap menjadi kasus uji permanen
Setelah model mulai diproduksi, pekerjaan Anda belum selesai; Tanggung jawab sebenarnya baru saja dimulai. Karena modelnya bisa rusak secara diam-diam saat tidak ada yang melihat. Dalam unit ini, kami membahas dua disiplin ilmu yang saling melengkapi: evaluasi (mengukur kualitas model secara sistematis) dan pemantauan (pemantauan terus-menerus terhadap model dalam produksi). Khususnya dalam sistem LLM, evaluasi lebih sulit dan memerlukan perhatian lebih dibandingkan ML klasik.
Mengapa model produksi diam-diam mogok
Bug mogok, log tercetak, alarm berbunyi. Sebaliknya, model ML bisa saja salah tanpa menimbulkan kesalahan. Tiga penyebab utama degradasi:
- Penyimpangan data: Distribusi data masukan berubah seiring waktu (produk baru, perubahan perilaku pengguna, musiman). Modelnya tetap sama tetapi dunia berubah.
- Penyimpangan konsep: Hubungan input-output berubah. Taktik penipuan dan pola spam terus berkembang; Apa yang benar kemarin akan menjadi salah hari ini.
- Korupsi di hulu: Sumber data berubah format, suatu wilayah menjadi bebas; Model diam-diam ngiler dengan input yang rusak.
Penelusuran membuat distorsi senyap ini terdengar.
Yang harus diperhatikan: tiga lapis
Pemantauan yang baik mencakup tiga lapisan:
- Metrik operasional: Latensi, tingkat kesalahan, volume permintaan, penggunaan sumber daya. “Apakah sistemnya baik-baik saja?”
- Metrik data/masukan: Apakah distribusi masukan serupa dengan pelatihan? Apakah tingkat nilai yang hilang meningkat? Apakah kategori baru telah tiba? “Apakah model melihat data yang familier?”
- Metrik model/keluaran: Log distribusi prediksi? Apakah skor kepercayaan diri turun? Dan jika memungkinkan, seberapa akuratkah dibandingkan dengan kebenaran dasar? “Apakah modelnya masih akurat?”
Lapisan ketiga adalah yang paling berharga namun paling sulit; karena hasil sebenarnya biasanya datang terlambat (setelah berbulan-bulan menjadi jelas apakah pinjaman akan dilunasi atau tidak).
Tip: Jika hasil sebenarnya tertunda, pantau distribusi input dan prediksi terlebih dahulu. Pergeseran distribusi masukan merupakan tanda awal penurunan akurasi dan dapat menimbulkan peringatan tanpa menunggu hasil sebenarnya.
Mengevaluasi sistem LLM: tantangan khusus
Dalam ML klasik, "jawaban yang benar" sudah jelas (kelas 0 atau 1). Hasil LLM, sebaliknya, bersifat terbuka: mungkin ada banyak jawaban yang benar untuk pertanyaan yang sama, "kebenaran" tidak cocok dengan satu nomor pun. Pendekatan evaluasi LLM:
- Metrik yang direferensikan: Membandingkan keluaran dengan jawaban ideal. Terbatas; karena mungkin menganggap jawaban benar yang dinyatakan berbeda sebagai "salah".
- Pemeriksaan berbasis aturan: Apakah keluaran JSON valid? Apakah ada kata-kata yang dilarang? Apakah itu berisi bidang yang diinginkan? Murah, andal, ketat.
- Hakim LLM (LLM sebagai hakim): Jangan membuat model bertanya "apakah jawaban ini bagus menurut kriteria ini?" Memang berskala, tapi wasitnya sendiri harus diverifikasi.
- Ulasan manusia: Standar emas tapi mahal dan lambat. Ini digunakan pada sampel.
Dalam praktiknya, hal-hal ini digunakan bersama-sama: pemeriksaan aturan yang murah pada setiap keluaran, penilaian LLM pada sampel yang besar, evaluasi manusia pada sampel yang kecil namun teliti.
Pendekatan lemah / Pendekatan kuat
Lemah: "LLM-Saya bertanya kepada wasit, 92% jawaban kami bagus. Sistemnya bagus."
Güçlü: "Pertama-tama kami memberi label manusia pada 100 hasil cetakan. Kami menjalankan juri LLM pada 100 hasil cetakan yang sama dan mengukur kesepakatan manusia-hakim — 85% setuju, dapat diterima. Kami mendokumentasikan kesalahan yang dilakukan hakim secara sistematis (kecenderungan untuk menganggap jawaban panjang tidak baik secara tidak adil) dan memperbaiki perintahnya. Baru setelah itu kami memercayai skor juri."
Bedanya: pendekatan kuat memverifikasi wasit dengan jangkar manusia, bukan membabi buta. Wasit LLM yang tidak terverifikasi memberikan kepercayaan diri yang terlihat bagus tetapi salah.
Perhatian: Wasit LLM juga seorang model; halusinogen, bias (menyukai jawaban panjang/percaya diri), bisa tidak konsisten. Kalibrasi skor wasit dengan tag manusia sebelum membuat keputusan produksi.
Kumpulan evaluasi: dirancang dengan cermat
Kumpulan evaluasi yang baik mewakili variasi penggunaan nyata dan kasus-kasus sulit. Evaluasi yang hanya berisi contoh-contoh mudah akan membuat Anda percaya diri. Pastikan untuk meletakkannya di cluster eval:
- Kasus tepi: Input kosong, input sangat panjang, format tidak biasa.
- Kasus sulit yang diketahui: Contoh ketika model pernah melakukan kesalahan di masa lalu (sebagai uji regresi).
- Insiden keamanan: Upaya injeksi yang cepat, permintaan jahat, jebakan pelanggaran privasi.
Cluster eval berkembang seiring waktu: setiap bug baru yang Anda temukan dalam produksi menjadi kasus uji untuk evaluasi berikutnya.
Alarm dan intervensi
Pemantauan tetap tidak lengkap tanpa alarm. Harus ada ambang batas dan rencana respons untuk setiap metrik penting: "Beri tahu teknisi jika penyimpangan masukan melebihi X", "Putar kembali otomatis jika tingkat kesalahan melebihi Y". Jaga agar alarm tetap bermakna — terlalu banyak alarm palsu akan menurunkan kepekaan tim dan membuat mereka melewatkan alarm yang sebenarnya.
tiga kasus mini
Kasus 1 - Peringatan dini. Keakuratan sebenarnya dari model perkiraan permintaan baru terlihat pada akhir minggu. Tim tersebut memantau distribusi masukan dan melihat munculnya kategori produk baru secara tiba-tiba pada hari Selasa – sesuatu yang belum pernah dilihat oleh model tersebut. Mereka memperbarui model tanpa menunggu penurunan akurasi. Pemantauan masukan menghemat hari.
Kasus 2 - Wasit yang tidak terverifikasi. Satu tim melaporkan "kualitas kami sangat bagus" berdasarkan pengulas LLM. Ketika keluhan pelanggan meningkat, pemantauan manusia diperkenalkan: wasit menghitung jawaban yang yakin tetapi salah sebagai "baik". Setelah wasit dikalibrasi dengan tag manusia, kualitas sebenarnya terungkap dan jauh lebih rendah. Pelajaran: jangan mempercayai wasit tanpa memverifikasinya.
Kasus 3 - Pengujian regresi. Perubahan yang cepat menyelesaikan satu masalah dan memecahkan masalah lainnya secara diam-diam. Namun tim terus mengatasi bug dalam keranjang evaluasi; Ketika perubahan baru diuji pada cluster ini, kasus yang rusak segera ditangkap dan perubahan tersebut diperbaiki. Pelajaran: setiap bug yang diperbaiki harus menjadi test case permanen.
Templat yang dapat disalin
Buat rencana pelacakan untuk model produksi ini. Mencakup tiga lapisan:1) Operasional (latensi, tingkat kesalahan, volume)2) Input/data (pergeseran distribusi, nilai yang hilang, kategori baru)3) Model/output (distribusi prediksi, keyakinan, akurasi jika memungkinkan)Model: [deskripsi]. Berapa lama waktu yang dibutuhkan hingga hasil sebenarnya muncul: [durasi]Tambahkan ambang batas dan rekomendasi intervensi untuk setiap metrik.
Usulkan strategi evaluasi (eval) untuk sistem LLM ini. Tugas: [deskripsi] Tentukan lapisan: - Pemeriksaan berbasis aturan mana yang harus dijalankan pada setiap keluaran? - Kriteria apa yang harus dievaluasi oleh arbiter LLM dan bagaimana cara memvalidasinya (jangkar manusia)?
Periksa perintah wasit LLM ini:- Apakah kriteria evaluasi jelas atau subyektif?- Apakah rentan terhadap bias panjang/keyakinan?- Bagaimana cara mengkalibrasi wasit dengan tag manusia?Permintaan wasit: [prompt]
Tulis runbook respons untuk alarm pemantauan ini.Alarm: [mis. ambang batas penyimpangan masukan terlampaui]Harus berisi: langkah-langkah pengendalian awal, kemungkinan penyebab, kriteria rollback, siapa yang harus diberitahu.
Tabel penyebab kerusakan
distorsi
gejala
Cara deteksi dini
penyimpangan data
Perubahan distribusi masukan
Pemantauan distribusi masukan
pergeseran konsep
Kebenaran jatuh secara diam-diam
Prediksi + perbandingan aktual
kesalahan hulu
Bidang menjadi kosong/format berubah
Validasi skema + tingkat yang hilang
Inkonsistensi model
Pergeseran distribusi output
Pemantauan distribusi keluaran
Kesalahan umum
- Tidak melakukan pemantauan. Model itu rusak secara diam-diam, tidak ada yang melihatnya.
- Lacak metrik operasional saja. Sistemnya sudah aktif, tapi prediksi bisa saja salah.
- Menggunakan LLM tanpa memverifikasi wasit. Ini memberikan keyakinan palsu.
- Evaluasi dengan contoh mudah. Ini tidak menunjukkan kesulitan yang nyata.
- Tidak termasuk kesalahan masa lalu di eval. Kesalahan yang sama kembali lagi.
- Alarm keras. Tim menjadi tidak peka, kehilangan alarm yang sebenarnya.
Singkatnya
Modelnya bisa saja tidak akurat tanpa menyebabkan kesalahan dalam produksi; jadi evaluasi dan pemantauan sama pentingnya dengan pembangunan. Menetapkan pemantauan pada tiga lapisan (operasional, input, output); Gunakan penyimpangan masukan sebagai peringatan dini jika hasil sebenarnya tertunda. Dalam sistem LLM, eval bersifat terbuka; Gunakan pemeriksaan aturan, wasit LLM, dan evaluasi manusia secara bersamaan — tetapi pastikan untuk memvalidasi wasit LLM dengan jangkar manusia. Perkaya klaster Eval Anda dengan kasus edge dan keamanan dan ubah setiap kesalahan yang tertangkap menjadi kasus uji permanen.
Tugas aplikasi
Tulis rencana pemantauan tiga lapis untuk model produksi (atau hampir produksi) dan tentukan ambang batas + alarm untuk setidaknya satu metrik distribusi masukan. Jika Anda memiliki sistem LLM: tandai 30 keluaran dengan manusia, jalankan wasit LLM pada keluaran yang sama, dan ukur kesepakatan manusia-wasit; Perhatikan bias sistematis wasit. Tambahkan setidaknya 3 edge dan 2 kasus keamanan ke cluster eval Anda.
daftar periksa
- [ ] Pemantauan mencakup ketiga lapisan (operasional, input, output).
- [ ] Saya menggunakan input drift sebagai peringatan dini jika hasil sebenarnya tertunda.
- [ ] Saya mengkalibrasi arbiter LLM dengan label manusia.
- [ ] Cluster Eval berisi kasus edge dan keamanan.
- [ ] Saya mengubah setiap bug yang saya tangkap menjadi test case permanen.
- [ ] Setiap metrik penting memiliki ambang batas dan rencana respons.