Jawapan ringkas: Untuk menilai model AI dengan baik, mulakan dengan menentukan apa yang kelihatan seperti "baik" bagi pengguna sebenar dan keputusan yang sedang dibuat. Kemudian bina penilaian yang boleh diulang dengan data perwakilan, kawalan kebocoran yang ketat dan pelbagai metrik. Tambahkan tekanan, bias dan pemeriksaan keselamatan, dan apabila ada perubahan (data, gesaan, dasar), jalankan semula abah-abah dan teruskan pemantauan selepas pelancaran.
Kesimpulan utama:
Kriteria kejayaan : Tentukan pengguna, keputusan, kekangan dan kegagalan terburuk sebelum memilih metrik.
Kebolehulangan : Bina abah-abah penilaian yang menjalankan semula ujian yang setanding dengan setiap perubahan.
Kebersihan data : Kekalkan pemisahan yang stabil, cegah pendua dan halang kebocoran ciri lebih awal.
Pemeriksaan kepercayaan : Kekukuhan ujian tekanan, potongan keadilan dan tingkah laku keselamatan LLM dengan rubrik yang jelas.
Disiplin kitaran hayat : Dilaksanakan secara berperingkat, pantau hanyutan dan insiden, dan dokumentasikan jurang yang diketahui.
Artikel yang mungkin anda ingin baca selepas ini:
🔗 Apakah etika AI
Terokai prinsip-prinsip yang membimbing reka bentuk, penggunaan dan tadbir urus AI yang bertanggungjawab.
🔗 Apakah bias AI?
Ketahui bagaimana data yang berat sebelah mempengaruhi keputusan dan hasil AI.
🔗 Apakah skalabiliti AI
Fahami penskalaan sistem AI untuk prestasi, kos dan kebolehpercayaan.
🔗 Apakah AI?
Gambaran keseluruhan yang jelas tentang kecerdasan buatan, jenis dan kegunaan dunia sebenar.
1) Mulakan dengan definisi "baik" yang tidak glamor
Sebelum metrik, sebelum papan pemuka, sebelum sebarang perubahan penanda aras - tentukan bagaimana kejayaan itu kelihatan.
Jelaskan:
-
Pengguna: penganalisis dalaman, pelanggan, doktor, pemandu, ejen sokongan yang letih pada pukul 4 petang…
-
Keputusan: meluluskan pinjaman, menandakan penipuan, mencadangkan kandungan, meringkaskan nota
-
Kegagalan yang paling penting:
-
Positif palsu (menjengkelkan) vs negatif palsu (berbahaya)
-
-
Kekangan: latensi, kos setiap permintaan, peraturan privasi, keperluan penjelasan, kebolehcapaian
Ini adalah bahagian di mana pasukan beralih kepada pengoptimuman untuk "metrik yang cantik" dan bukannya "hasil yang bermakna". Ia banyak berlaku. Macam… banyak.
Satu cara yang kukuh untuk memastikan perkara ini sedar akan risiko (dan bukan berasaskan getaran) adalah dengan membingkaikan pengujian berdasarkan kepercayaan dan pengurusan risiko kitaran hayat, seperti yang dilakukan oleh NIST dalam Rangka Kerja Pengurusan Risiko AI (AI RMF 1.0) [1].
2) Apakah yang menjadikan versi “cara menguji model AI” yang baik ✅
Pendekatan pengujian yang kukuh mempunyai beberapa perkara yang tidak boleh dirundingkan:
-
Data perwakilan (bukan sekadar data makmal bersih)
-
Perpecahan yang jelas dengan pencegahan kebocoran (lebih lanjut mengenainya sebentar lagi)
-
Garis asas (model mudah yang perlu kalahkan - penganggar dummy wujud atas sebab tertentu [4])
-
Pelbagai metrik (kerana satu nombor berbohong kepada anda, dengan sopan, di hadapan anda)
-
Ujian tekanan (kes pinggir, input luar biasa, senario seperti permusuhan)
-
Gelung semakan manusia (terutamanya untuk model generatif)
-
Pemantauan selepas pelancaran (kerana dunia berubah, saluran paip rosak, dan pengguna… kreatif [1])
Juga: pendekatan yang baik termasuk mendokumentasikan apa yang anda uji, apa yang anda tidak uji, dan apa yang anda gementarkan. Bahagian "apa yang saya gementarkan" itu terasa janggal - dan di sinilah kepercayaan mula terjalin.
Dua corak dokumentasi yang secara konsisten membantu pasukan kekal jujur:
-
Kad Model (untuk apa model ini, bagaimana ia dinilai, di mana ia gagal) [2]
-
Helaian Data untuk Set Data (apakah data tersebut, bagaimana ia dikumpulkan, untuk apa ia sepatutnya/tidak sepatutnya digunakan) [3]
3) Realiti alat: apa yang digunakan orang ramai dalam praktik 🧰
Alatan adalah pilihan. Tabiat penilaian yang baik tidak.
Jika anda mahukan persediaan yang pragmatik, kebanyakan pasukan akan mendapat tiga pilihan:
-
Penjejakan eksperimen (jalan, konfigurasi, artifak)
-
Abah-abah penilaian (ujian luar talian berulang + suit regresi)
-
Pemantauan (isyarat hanyutan, proksi prestasi, amaran insiden)
Contoh yang akan anda lihat banyak di alam liar (bukan sokongan, dan ya - ciri/perubahan harga): MLflow, Weights & Biases, Great Expectations, Evidently, Deepchecks, OpenAI Evals, TruLens, LangSmith.
Jika anda hanya memilih satu idea daripada bahagian ini: bina abah-abah penilaian yang boleh diulang . Anda mahu “tekan butang → dapatkan hasil yang setanding,” bukan “jalankan semula buku nota dan berdoa.”
4) Bina set ujian yang betul (dan hentikan kebocoran data) 🚧
Sejumlah besar model "menakjubkan" secara tidak sengaja menipu.
Untuk ML standard
Beberapa peraturan tidak seksi yang menyelamatkan kerjaya:
-
Pastikan kereta api/pengesahan/ujian stabil (dan tuliskan logik pemisahan)
-
Cegah pendua merentasi pemisahan (pengguna yang sama, dokumen yang sama, produk yang sama, hampir pendua)
-
Perhatikan kebocoran ciri (maklumat masa hadapan yang menyelinap masuk ke dalam ciri "semasa")
-
Gunakan garis dasar (penganggar palsu) supaya anda tidak meraikan kejayaan… tiada apa-apa [4]
Takrifan kebocoran (versi ringkas): apa-apa sahaja dalam latihan/penilaian yang memberikan model akses kepada maklumat yang tidak akan dimilikinya pada masa keputusan. Ia boleh jadi jelas (“label masa hadapan”) atau halus (“baldi cap waktu pasca peristiwa”).
Untuk LLM dan model generatif
Anda sedang membina sistem gesaan dan dasar , bukan sekadar "model".
-
Cipta satu set gesaan emas (kecil, berkualiti tinggi, stabil)
-
Tambahkan sampel sebenar terkini (tanpa nama + selamat untuk privasi)
-
Kekalkan pek huruf besar-kecil : kesalahan taip, slanga, pemformatan tidak standard, input kosong, kejutan berbilang bahasa 🌍
Satu perkara praktikal yang saya saksikan berlaku lebih daripada sekali: satu pasukan menghantar skor luar talian yang "kuat", kemudian sokongan pelanggan berkata, "Hebat. Ia dengan yakin terlepas satu ayat yang penting." Pembetulannya bukanlah "model yang lebih besar". Ia adalah gesaan ujian yang lebih baik , rubrik yang lebih jelas dan suit regresi yang menghukum mod kegagalan yang tepat itu. Biasa sahaja. Berkesan.
5) Penilaian luar talian: metrik yang bermakna 📏
Metrik adalah baik. Monokultur metrik tidak.
Pengelasan (spam, penipuan, niat, triaj)
Gunakan lebih daripada sekadar ketepatan.
-
Ketepatan, penarikan balik, F1
-
Penalaan ambang (ambang lalai anda jarang sekali "betul" untuk kos anda) [4]
-
Matriks kekeliruan setiap segmen (rantau, jenis peranti, kohort pengguna)
Regresi (ramalan, penetapan harga, pemarkahan)
-
MAE / RMSE (pilih berdasarkan cara anda mahu menghukum ralat)
-
Pemeriksaan seakan-akan penentukuran apabila output digunakan sebagai "skor" (adakah skor selaras dengan realiti?)
Sistem kedudukan / pengesyorkan
-
NDCG, MAP, MRR
-
Hiris mengikut jenis pertanyaan (kepala vs ekor)
Penglihatan komputer
-
mAP, IoU
-
Persembahan setiap kelas (kelas yang jarang berlaku adalah di mana model memalukan anda)
Model generatif (LLM)
Di sinilah orang ramai menjadi… berfalsafah 😵💫
Pilihan praktikal yang berkesan dalam pasukan sebenar:
-
Penilaian manusia (isyarat terbaik, gelung paling perlahan)
-
Keutamaan berpasangan / kadar kemenangan (A vs B lebih mudah daripada pemarkahan mutlak)
-
Metrik teks automatik (berguna untuk sesetengah tugas, mengelirukan untuk tugasan lain)
-
Semakan berasaskan tugasan: “Adakah ia mengekstrak medan yang betul?” “Adakah ia mematuhi dasar?” “Adakah ia memetik sumber apabila diperlukan?”
Jika anda mahukan titik rujukan "berbilang metrik, banyak senario" yang berstruktur, HELM adalah sauh yang baik: ia secara eksplisit mendorong penilaian melangkaui ketepatan kepada perkara seperti penentukuran, kekukuhan, bias/ketoksikan dan keseimbangan kecekapan [5].
Sedikit penyimpangan: metrik automatik untuk kualiti penulisan kadangkala terasa seperti menilai sandwic dengan menimbangnya. Ia bukannya tiada apa-apa, tetapi… ayuhlah 🥪
6) Ujian kekukuhan: buat ia berpeluh sedikit 🥵🧪
Jika model anda hanya berfungsi pada input yang kemas, ia pada dasarnya adalah pasu kaca. Cantik, rapuh, mahal.
Ujian:
-
Hingar: kesalahan taip, nilai yang hilang, kod unikod bukan standard, gangguan pemformatan
-
Anjakan pengedaran: kategori produk baharu, slanga baharu, sensor baharu
-
Nilai ekstrem: nombor di luar julat, muatan gergasi, rentetan kosong
-
Input "agak adversarial" yang tidak kelihatan seperti set latihan anda tetapi kelihatan seperti pengguna
Untuk LLM, sertakan:
-
Percubaan suntikan segera (arahan tersembunyi di dalam kandungan pengguna)
-
Corak "Abaikan arahan sebelumnya"
-
Kes pinggir penggunaan alat (URL rosak, tamat masa, output separa)
Kekukuhan adalah salah satu sifat kepercayaan yang kedengaran abstrak sehinggalah anda mengalami insiden. Kemudian ia menjadi… sangat ketara [1].
7) Kecenderungan berat sebelah, keadilan, dan siapa yang ia berkesan ⚖️
Model boleh menjadi "tepat" secara keseluruhan tetapi secara konsisten lebih teruk untuk kumpulan tertentu. Itu bukan pepijat kecil. Itu masalah produk dan kepercayaan.
Langkah praktikal:
-
Nilaikan prestasi mengikut segmen yang bermakna (sesuai dari segi undang-undang/etika untuk diukur)
-
Bandingkan kadar ralat dan penentukuran merentasi kumpulan
-
Uji ciri proksi (poskod, jenis peranti, bahasa) yang boleh mengekod sifat sensitif
Jika anda tidak mendokumentasikan perkara ini di suatu tempat, pada dasarnya anda meminta anda yang akan datang untuk menyelesaikan krisis kepercayaan tanpa peta. Kad Model adalah tempat yang kukuh untuk meletakkannya [2], dan pembingkaian kepercayaan NIST memberi anda senarai semak yang kukuh tentang apa yang "baik" harus sertakan [1].
8) Ujian keselamatan dan sekuriti (terutamanya untuk LLM) 🛡️
Jika model anda boleh menjana kandungan, anda menguji lebih daripada sekadar ketepatan. Anda sedang menguji tingkah laku.
Sertakan ujian untuk:
-
Penjanaan kandungan yang tidak dibenarkan (pelanggaran dasar)
-
Kebocoran privasi (adakah ia mencerminkan rahsia?)
-
Halusinasi dalam domain berisiko tinggi
-
Penolakan berlebihan (model menolak permintaan biasa)
-
Output ketoksikan dan gangguan
-
Percubaan penyingkiran data melalui suntikan segera
Pendekatan berasaskan asas adalah: tentukan peraturan dasar → bina gesaan ujian → skor output dengan pemeriksaan manusia + automatik → jalankannya setiap kali ada perubahan. Bahagian "setiap masa" itu adalah sewa.
Ini sesuai dengan pemikiran risiko kitaran hayat: tadbir, petakan konteks, ukur, urus, ulangi [1].
9) Ujian dalam talian: pelancaran berperingkat (di mana kebenarannya wujud) 🚀
Ujian luar talian adalah perlu. Pendedahan dalam talian adalah tempat realiti muncul memakai kasut berlumpur.
Anda tidak perlu bermewah. Anda hanya perlu berdisiplin:
-
Jalankan dalam mod bayang (model berjalan, tidak menjejaskan pengguna)
-
Pelancaran secara beransur-ansur (trafik kecil dahulu, kembangkan jika sihat)
-
Jejaki hasil dan insiden (aduan, peningkatan, kegagalan dasar)
Walaupun anda tidak dapat mendapatkan label serta-merta, anda boleh memantau isyarat proksi dan kesihatan operasi (latensi, kadar kegagalan, kos). Perkara utama: anda mahukan cara terkawal untuk menemui kegagalan sebelum seluruh pangkalan pengguna anda melakukannya [1].
10) Pemantauan selepas penggunaan: hanyutan, pereputan dan kegagalan senyap 📉👀
Model yang anda uji bukanlah model yang akhirnya anda gunakan. Data berubah. Pengguna berubah. Dunia berubah. Saluran paip rosak pada pukul 2 pagi. Anda tahu bagaimana keadaannya…
Pantau:
-
Hanyutan data input (perubahan skema, kehilangan, anjakan taburan)
-
Hanyutan output (anjakan keseimbangan kelas, anjakan skor)
-
Proksi prestasi (kerana kelewatan label adalah nyata)
-
Isyarat maklum balas (tidak digalakkan, suntingan semula, peningkatan)
-
Regresi peringkat segmen (pembunuh senyap)
Dan tetapkan ambang amaran yang tidak terlalu bergerak-gerak. Monitor yang sentiasa menjerit diabaikan - seperti penggera kereta di bandar.
Gelung "pantau + perbaiki dari semasa ke semasa" ini bukanlah pilihan jika anda mementingkan kepercayaan [1].
11) Aliran kerja praktikal yang boleh anda tiru 🧩
Berikut ialah gelung mudah yang diskalakan:
-
Takrifkan mod kejayaan + kegagalan (termasuk kos/latensi/keselamatan) [1]
-
Cipta set data:
-
set emas
-
pek kes tepi
-
sampel sebenar terkini (selamat privasi)
-
-
Pilih metrik:
-
metrik tugasan (F1, MAE, kadar kemenangan) [4][5]
-
metrik keselamatan (kadar kelulusan dasar) [1][5]
-
metrik operasi (latensi, kos)
-
-
Bina satu abah-abah penilaian (berjalan pada setiap model/perubahan segera) [4][5]
-
Tambahkan ujian tekanan + ujian seperti permusuhan [1][5]
-
Semakan manusia untuk sampel (terutamanya untuk output LLM) [5]
-
Hantar melalui pelancaran shadow + berperingkat [1]
-
Pantau + beri amaran + latih semula dengan disiplin [1]
-
Dokumen menghasilkan penulisan gaya kad model [2][3]
Latihan itu glamor. Pengujian itu membayar sewa.
12) Nota penutup + ringkasan ringkas 🧠✨
Jika anda hanya ingat beberapa perkara tentang cara menguji model AI :
-
Gunakan data ujian yang representatif dan elakkan kebocoran [4]
-
Pilih berbilang metrik yang dikaitkan dengan hasil sebenar [4][5]
-
Untuk LLM, bergantung pada ulasan manusia + perbandingan gaya kadar kemenangan [5]
-
Uji kekukuhan - input luar biasa adalah input normal yang terselindung [1]
-
Gulungkan dengan selamat dan pantau, kerana model hanyut dan saluran paip pecah [1]
-
Dokumentasikan apa yang anda lakukan dan apa yang anda tidak uji (tidak selesa tetapi berkesan) [2][3]
Pengujian bukan sekadar "membuktikan ia berkesan." Ia adalah "mencari bagaimana ia gagal sebelum pengguna anda gagal." Dan ya, itu kurang menarik - tetapi ia adalah bahagian yang memastikan sistem anda kekal stabil apabila keadaan menjadi goyah… 🧱🙂
Soalan Lazim
Cara terbaik untuk menguji model AI supaya ia sepadan dengan keperluan pengguna sebenar
Mulakan dengan mentakrifkan "baik" dari segi pengguna sebenar dan keputusan yang disokong oleh model, bukan sekadar metrik papan pendahulu. Kenal pasti mod kegagalan kos tertinggi (positif palsu vs negatif palsu) dan jelaskan kekangan keras seperti kependaman, kos, privasi dan kebolehjelasan. Kemudian pilih metrik dan kes ujian yang mencerminkan hasil tersebut. Ini menghalang anda daripada mengoptimumkan "metrik yang cantik" yang tidak pernah diterjemahkan kepada produk yang lebih baik.
Menentukan kriteria kejayaan sebelum memilih metrik penilaian
Tuliskan siapa pengguna tersebut, keputusan yang ingin disokong oleh model tersebut dan bagaimana rupa "kegagalan terburuk" dalam pengeluaran. Tambahkan kekangan operasi seperti latensi yang boleh diterima dan kos setiap permintaan, serta keperluan tadbir urus seperti peraturan privasi dan dasar keselamatan. Sebaik sahaja ia jelas, metrik menjadi cara untuk mengukur perkara yang betul. Tanpa pembingkaian itu, pasukan cenderung beralih ke arah mengoptimumkan apa sahaja yang paling mudah untuk diukur.
Mencegah kebocoran data dan penipuan tidak sengaja dalam penilaian model
Pastikan pemisahan latih/pengesahan/ujian stabil dan dokumentasikan logik pemisahan supaya keputusan kekal boleh dihasilkan semula. Sekat pendua dan hampir pendua secara aktif merentasi pemisahan (pengguna, dokumen, produk atau corak berulang yang sama). Perhatikan kebocoran ciri di mana maklumat "masa hadapan" menyelinap ke dalam input melalui cap waktu atau medan pasca peristiwa. Garis dasar yang kukuh (walaupun penganggar dummy) membantu anda menyedari apabila anda meraikan hingar.
Apa yang perlu disertakan dalam abah-abah penilaian supaya ujian kekal boleh diulang merentasi perubahan
Harness praktikal menjalankan semula ujian setanding pada setiap model, gesaan atau perubahan dasar menggunakan set data dan peraturan pemarkahan yang sama. Ia biasanya merangkumi suit regresi, papan pemuka metrik yang jelas dan konfigurasi serta artifak yang disimpan untuk kebolehkesanan. Bagi sistem LLM, ia juga memerlukan "set emas" gesaan yang stabil serta pek kes pinggir. Matlamatnya adalah "tekan butang → hasil yang setanding," bukan "jalankan semula buku nota dan berdoa."
Metrik untuk menguji model AI melebihi ketepatan
Gunakan berbilang metrik, kerana satu nombor boleh menyembunyikan pertukaran penting. Untuk pengelasan, pasangkan ketepatan/panggilan balik/F1 dengan penalaan ambang dan matriks kekeliruan mengikut segmen. Untuk regresi, pilih MAE atau RMSE berdasarkan cara anda ingin menghukum ralat dan tambahkan semakan gaya penentukuran apabila output berfungsi seperti skor. Untuk kedudukan, gunakan NDCG/MAP/MRR dan pertanyaan hirisan mengikut kepala vs ekor untuk mengesan prestasi yang tidak sekata.
Menilai output LLM apabila metrik automatik tidak mencukupi
Anggap ia sebagai sistem gesaan dan dasar serta tingkah laku skor, bukan sekadar persamaan teks. Banyak pasukan menggabungkan penilaian manusia dengan keutamaan berpasangan (kadar kemenangan A/B), serta semakan berasaskan tugas seperti "adakah ia mengekstrak medan yang betul" atau "adakah ia mematuhi dasar." Metrik teks automatik boleh membantu dalam kes yang sempit, tetapi ia sering terlepas pandang apa yang pengguna pentingkan. Rubrik yang jelas dan suit regresi biasanya lebih penting daripada satu skor.
Ujian kekukuhan untuk dijalankan supaya model tidak rosak pada input yang bising
Uji tekanan model dengan kesalahan taip, nilai yang hilang, pemformatan yang pelik dan kod unikod yang tidak standard, kerana pengguna sebenar jarang sekali kemas. Tambahkan kes anjakan pengedaran seperti kategori baharu, slanga, sensor atau corak bahasa. Sertakan nilai ekstrem (rentetan kosong, muatan besar, nombor di luar julat) untuk menonjolkan tingkah laku rapuh. Untuk LLM, uji juga corak suntikan gesaan dan kegagalan penggunaan alat seperti tamat masa atau output separa.
Memeriksa isu berat sebelah dan keadilan tanpa tersesat dalam teori
Nilaikan prestasi pada hirisan yang bermakna dan bandingkan kadar ralat dan penentukuran merentasi kumpulan yang sesuai dari segi undang-undang dan etika untuk diukur. Cari ciri proksi (seperti poskod, jenis peranti atau bahasa) yang boleh mengekod sifat sensitif secara tidak langsung. Model boleh kelihatan "tepat secara keseluruhan" sambil gagal secara konsisten untuk kohort tertentu. Dokumentasikan apa yang anda ukur dan apa yang anda tidak ukur, supaya perubahan masa hadapan tidak secara senyap-senyap memperkenalkan semula regresi.
Ujian keselamatan dan sekuriti untuk dimasukkan ke dalam sistem AI dan LLM generatif
Uji penjanaan kandungan yang tidak dibenarkan, kebocoran privasi, halusinasi dalam domain berisiko tinggi dan penolakan berlebihan di mana model menyekat permintaan biasa. Sertakan percubaan suntikan gesaan dan penapisan data, terutamanya apabila sistem menggunakan alatan atau mendapatkan semula kandungan. Aliran kerja yang berasaskan ialah: mentakrifkan peraturan dasar, membina set gesaan ujian, memberi skor dengan pemeriksaan manusia serta automatik dan menjalankannya semula apabila gesaan, data atau dasar berubah. Ketekalan ialah sewa yang anda bayar.
Melancarkan dan memantau model AI selepas pelancaran untuk mengesan hanyutan dan insiden
Gunakan corak pelancaran berperingkat seperti mod bayangan dan tanjakan trafik secara beransur-ansur untuk mencari kegagalan sebelum pangkalan pengguna penuh anda melakukannya. Pantau hanyutan input (perubahan skema, kehilangan, anjakan pengedaran) dan hanyutan output (anjakan skor, anjakan keseimbangan kelas), serta kesihatan operasi seperti kependaman dan kos. Jejaki isyarat maklum balas seperti suntingan, peningkatan dan aduan serta perhatikan regresi peringkat segmen. Apabila ada perubahan, jalankan semula abah-abah yang sama dan terus pantau secara berterusan.
Rujukan
[1] NIST - Rangka Kerja Pengurusan Risiko Kecerdasan Buatan (AI RMF 1.0) (PDF)
[2] Mitchell dkk. - “Kad Model untuk Pelaporan Model” (arXiv:1810.03993)
[3] Gebru dkk. - “Helaian Data untuk Set Data” (arXiv:1803.09010)
[4] scikit-learn - Dokumentasi “Pemilihan dan penilaian model”
[5] Liang dkk. - “Penilaian Holistik Model Bahasa” (arXiv:2211.09110)