Cara Mengevaluasi Model Baru dalam 48 Jam: Daftar Periksa Hari Rilis
Sebuah model baru diluncurkan. Video demo terlihat kuat, halaman harga sedang ramai, tangkapan layar leaderboard sudah beredar, dan kanal roadmap Anda menginginkan jawaban besok: apakah model ini harus masuk ke produk?
Jawaban terburuk adalah "kami mencoba beberapa prompt dan rasanya lebih baik." Jawaban terburuk kedua adalah proyek evaluasi selama sebulan yang melewatkan jendela rilis.
Panduan ini memberi tim produk AI jalur tengah yang praktis. Gunakan Cara Mengevaluasi Model Baru dalam 48 Jam: Daftar Periksa Hari Rilis sebagai rencana operasional hari rilis: buat set eval yang kecil tetapi representatif, bandingkan dengan rute produksi Anda saat ini, jalankan gate kompatibilitas dan keamanan, normalkan biaya berdasarkan output yang diterima, dan akhiri dengan memo keputusan yang benar-benar bisa ditandatangani oleh tim engineering, produk, dan keuangan Anda.
Tujuannya bukan untuk membuktikan bahwa model baru secara universal lebih baik. Tujuannya adalah untuk memutuskan apakah model tersebut cukup aman, cukup berguna, dan cukup ekonomis untuk satu alur kerja produk yang didefinisikan dengan jelas.
Jawaban 48 jam
Jika Anda hanya punya dua hari, evaluasi model baru terhadap satu pekerjaan produksi, bukan terhadap internet.
Pilih beban kerja yang sudah memiliki pengguna, log, mode kegagalan, dan baseline saat ini. Lalu jawab enam pertanyaan:
| Gate | Pertanyaan | Sinyal lulus |
|---|---|---|
| Kecocokan | Apakah model menyelesaikan tugas target lebih baik daripada rute saat ini? | Tingkat output yang diterima lebih tinggi pada contoh yang menyerupai produksi |
| Kontrak | Apakah model mempertahankan skema, panggilan alat, sitasi, pengaturan media, atau format respons yang Anda butuhkan? | Tidak ada kegagalan pemblokir dalam pengujian kontrak output |
| Keamanan | Apakah model menciptakan kegagalan baru terkait kebijakan, privasi, halusinasi, atau risiko merek? | Tingkat kegagalan berat sama atau lebih rendah daripada baseline |
| Keandalan | Apakah model dapat bertahan dalam kondisi latensi, retry, rate-limit, dan konteks panjang? | Latensi p90 dan perilaku error sesuai dengan SLO produk |
| Biaya | Apakah model menurunkan biaya per output yang diterima, bukan hanya harga token? | Biaya output yang diterima lebih rendah atau sama yang dapat dibenarkan |
| Peluncuran | Bisakah Anda meluncurkannya melalui shadow traffic, canary routing, dan rollback? | Kebijakan rute, pemantauan, dan kondisi berhenti yang jelas |
Itulah inti dari Cara Mengevaluasi Model Baru dalam 48 Jam: Daftar Periksa Hari Rilis: memadatkan keputusan menjadi perbandingan produksi yang paling kecil namun andal.
Sebelum jam 0: pilih satu beban kerja
Jangan mulai dengan bertanya, "Apakah model baru lebih baik?" Mulailah dengan bertanya, "Lebih baik untuk pekerjaan yang mana?"
Pilih satu alur kerja dengan keluaran yang terukur:
- Generasi jawaban customer support.
- Perencanaan patch kode.
- Ringkasan hasil pencarian.
- Ekstraksi OCR.
- Penulisan ulang konten produk.
- Brief riset penjualan.
- Generasi kreatif yang dimoderasi.
- Langkah agen panggilan alat.
- Ekspansi prompt video atau gambar.
Lalu definisikan baseline saat ini. Baseline bisa berupa model langsung dari penyedia, rute model di gateway Anda, alur kerja dengan bantuan manusia, atau versi model sebelumnya. Baseline inilah yang mengubah antusiasme hari rilis menjadi perbandingan yang terukur.
Untuk tim Flatkey, inilah juga saat router terpadu membantu: jaga kontrak aplikasi tetap stabil saat Anda menguji rute model baru, lalu bandingkan request ID, biaya, error, dan penerimaan output dalam satu ledger. Jika stack Anda masih terpencar di berbagai direct key, gunakan prinsip yang sama secara manual: satu tugas, satu baseline, satu catatan keputusan.
Jam 0-3: bekukan memo keputusan
Buat memo sebelum siapa pun melihat hasilnya. Ini mencegah tim mengubah definisi "baik" setelah model menghasilkan beberapa contoh yang mengesankan.
Gunakan templat ini:
Model baru:
Tanggal rilis:
Pemilik evaluasi:
Workflow target:
Baseline saat ini:
Segmen pengguna:
Volume traffic yang terdampak:
Keputusan yang dibutuhkan:
[ ] tidak ada tindakan
[ ] lanjutkan pengujian
[ ] shadow traffic
[ ] canary
[ ] penggantian rute penuh
Penghambat keras:
- Data/privasi:
- Kepatuhan:
- Kontrak output:
- Keamanan:
- Latensi/SLO:
- Biaya:
- Kualitas produk:
Kriteria lulus:
- Kualitas:
- Keandalan:
- Biaya per output yang diterima:
- Rollback:
Batas waktu keputusan:
Pihak yang menyetujui keputusan:
Memo ini sengaja dibuat sempit. Evaluasi model pada hari rilis tidak seharusnya menentukan arsitektur AI untuk tahun berikutnya. Memo ini seharusnya hanya menentukan satu perubahan rute.
Jam 3-8: bangun set eval sekecil mungkin yang berguna
Set eval 48 jam yang berguna memiliki empat bagian.
| Set | Ukuran | Tujuan |
|---|---|---|
| Tugas emas | 25-50 contoh | Contoh yang sudah diketahui dengan output yang diharapkan atau telah ditinjau |
| Tugas produksi yang berantakan | 50-100 contoh | Kasus tepi nyata dari log, tiket dukungan, kueri pencarian, unggahan, atau trace agen |
| Uji kontrak | 20-40 contoh | JSON, tool-call, sitasi, format, media, atau batasan latensi |
| Probe red-team | 20-50 contoh | Perilaku keamanan, privasi, jailbreak, merek, halusinasi, dan penolakan |
Pedoman eval OpenAI memposisikan eval sebagai pengujian terstruktur dengan dataset, grader, dan run. Pedoman pengujian Anthropic dimulai dengan kriteria keberhasilan dan test case. Pipeline evaluasi berbasis komputasi dari Google juga memperlakukan evaluasi sebagai pipeline yang dapat diulang, bukan sesi chat ad hoc. Pelajaran yang sama sederhana: model baru harus menghadapi set tes, bukan sekadar penilaian berdasarkan rasa.
Jika Anda sudah memiliki eval harness, gunakan itu. Jika belum, spreadsheet plus skrip deterministik sudah cukup untuk 48 jam pertama.
Tambahkan kolom-kolom ini:
| Kolom | Contoh |
|---|---|
case_id |
support_refund_017 |
workflow |
support_answer |
input |
Pertanyaan pengguna, jejak alat, dokumen, prompt, atau spesifikasi media |
expected_behavior |
Apa yang harus dilakukan jawaban yang baik |
hard_fail_conditions |
Kutipan hilang, JSON salah, saran tidak aman, bahasa salah |
baseline_output |
Hasil rute saat ini |
new_model_output |
Hasil kandidat |
accepted_baseline |
ya/tidak |
accepted_new_model |
ya/tidak |
reviewer_notes |
Mengapa lolos atau gagal |
Jangan terlalu mengoptimalkan harness pada hari rilis. Jam peluncuran model terus berjalan. Anda perlu struktur yang cukup untuk menghindari menipu diri sendiri.
Jam 8-14: jalankan smoke test sebelum quality test
Run pertama bukan tentang kualitas. Ini tentang apakah model dapat dipanggil, dirutekan, ditagihkan, dicatat, dan diurai tanpa merusak produk.
Jalankan smoke test berikut:
- Autentikasi: kunci, base URL, dan nama model berfungsi dari lingkungan bersih.
- Kompatibilitas endpoint: model mendukung endpoint yang dipanggil aplikasi Anda.
- Bentuk request: pesan sistem, input multimodal, alat, format respons, max tokens, streaming, dan parameter keamanan berperilaku seperti yang diharapkan.
- Kontrak output: JSON, XML, Markdown, kutipan, panggilan alat, atau output file yang diperlukan dapat diurai.
- Envelope error: timeout, 400, 429, dan error penyedia dipetakan dengan rapi ke kebijakan retry Anda.
- Logging: ID permintaan, ID model, unit input/output, latensi, status, dan field biaya tercatat.
- Rollback: rute lama dapat dipulihkan tanpa perubahan kode.
Untuk pengguna Flatkey, mulailah dengan direktori model dan pola base URL kompatibel OpenAI yang sama yang Anda gunakan di produksi. Jika model kandidat belum dikonfirmasi di direktori model langsung, jangan mengisyaratkan ketersediaan dalam artikel, produk, atau catatan rilis. Perlakukan itu sebagai rute tertunda dan simpan memo keputusan dalam "lanjutkan pengujian."
Jam 14-24: nilai kualitas tugas terhadap baseline
Sekarang bandingkan model baru dengan rute Anda saat ini.
Gunakan peninjauan berpasangan. Untuk setiap kasus, tampilkan output baseline dan output kandidat berdampingan. Sembunyikan nama model jika peninjau bisa bias oleh narasi peluncuran.
Nilai hanya hal yang penting untuk alur kerja yang dipilih:
| Kriteria | 0 | 1 | 2 |
|---|---|---|---|
| Penyelesaian tugas | Gagal memenuhi kebutuhan pengguna | Sebagian menyelesaikannya | Menyelesaikannya |
| Keakuratan faktual | Tidak didukung atau salah | Ketidakpastian kecil | Cukup berlandaskan untuk peluncuran |
| Kepatuhan format | Melanggar kontrak | Perlu perbaikan | Output valid |
| Penggunaan alat/sitasi | Hilang atau salah | Dapat digunakan dengan edit | Benar dan lengkap |
| Upaya pengguna | Lebih banyak pekerjaan daripada baseline | Serupa | Lebih sedikit pekerjaan daripada baseline |
| Kecocokan merek/produk | Corak tidak dapat digunakan | Dapat diterima | Lebih baik daripada baseline |
Kemudian ubah skor menjadi tingkat penerimaan:
accepted_output_rate =
accepted_outputs / total_cases
candidate_lift =
candidate_accepted_output_rate - baseline_accepted_output_rate
Di sinilah banyak pengujian hari rilis salah. Harga token terlihat, tetapi output yang diterima adalah yang benar-benar dikirim. Model yang 30 persen lebih murah per token tetap bisa lebih mahal jika dua kali lebih sering gagal, memerlukan prompt perbaikan, atau menghasilkan output yang ditolak peninjau.
Untuk metodologi yang lebih luas, HELM adalah pengingat yang berguna bahwa evaluasi model harus mempertimbangkan lebih dari sekadar akurasi. Di dalamnya dibahas skenario dan metrik seperti ketahanan, keadilan, toksisitas, kalibrasi, dan efisiensi. Versi 48 jam Anda akan lebih kecil, tetapi tetap harus multi-metrik.
Jam 24-30: uji kontrak, alat, dan edge perutean
Kebanyakan kegagalan produksi tidak terlihat seperti "jawabannya buruk." Mereka terlihat seperti:
- Skema JSON gagal pada 7 persen permintaan.
- Panggilan alat secara diam-diam menghilangkan argumen yang diperlukan.
- Model menolak tugas aman yang harus didukung produk Anda.
- Model mengabaikan batasan bahasa atau lokal.
- Model terlalu sering menggunakan output penalaran panjang dan melanggar target latensi.
- Rute fallback mengubah bentuk respons.
- Model media baru mengembalikan rasio aspek, durasi, atau field status file yang berbeda.
Jalankan suite kontrak sebelum Anda merayakan kemenangan kualitas.
contract_pass_rate =
valid_contract_outputs / total_contract_cases
fallback_mismatch_rate =
fallback_outputs_with_contract_or_semantic_mismatch / fallback_cases
Jika model hanya lebih baik ketika semuanya berjalan lancar, model itu belum siap untuk perutean produksi. Model itu mungkin masih berguna di belakang feature flag, dalam alur kerja peninjauan manual, atau sebagai kandidat fallback, tetapi memo keputusan harus menyatakannya demikian.
Jam 30-36: normalisasi latensi, batas, dan biaya
Model baru dapat gagal memenuhi kasus bisnis meskipun menang dalam tinjauan kualitatif.
Catat:
| Metrik | Mengapa ini penting |
|---|---|
| latensi p50 dan p90 | Pengguna merasakan ekor yang lambat, bukan demo rata-rata |
| tingkat timeout | Respons yang lambat bisa menjadi error produk |
| tingkat retry | Retry meningkatkan latensi dan biaya |
| tingkat 429/rate-limit | Permintaan pada hari rilis dapat melebihi kuota praktis |
| pemanfaatan konteks | Konteks yang besar dapat menyembunyikan biaya prompt yang tak terkendali |
| panjang output | Model yang verbose bisa lebih mahal per hasil yang diterima |
| biaya output yang diterima | Penyebut yang sesungguhnya bagi tim produk |
Gunakan rumus biaya ini:
cost_per_accepted_output =
total_candidate_cost / accepted_candidate_outputs
Kemudian bandingkan dengan baseline:
cost_delta =
candidate_cost_per_accepted_output - baseline_cost_per_accepted_output
Jangan menyetujui model hanya karena harga input-token pada judul terlihat lebih baik. Setujui karena biaya output yang diterima, keandalan, dan kualitas produk masuk akal secara bersamaan.
Jam 36-42: jalankan shadow traffic atau replay traffic
Jika model lolos evaluasi offline, jalankan replay atau shadow traffic sebelum canary.
Replay traffic berarti Anda menjalankan permintaan historis melalui model baru dan membandingkan output tanpa memengaruhi pengguna. Shadow traffic berarti permintaan langsung disalin ke rute baru, tetapi pengguna tetap menerima output baseline.
Untuk setiap permintaan yang di-shadow, catat:
- Segmen pengguna atau alur kerja.
- Model baseline dan model kandidat.
- ID permintaan.
- Ukuran input dan ukuran output.
- Latensi.
- Jenis error.
- Validitas kontrak.
- Biaya.
- Reviewer atau penerimaan otomatis.
- Setiap flag keamanan atau privasi.
Di sinilah gateway atau router menjadi praktis. Artikel Cara Mengevaluasi Model Baru dalam 48 Jam: Daftar Periksa Hari Rilis mengasumsikan tim Anda dapat mengganti rute tanpa menulis ulang aplikasi setiap saat. Jika Anda menggunakan Flatkey, arahkan aplikasi Anda ke lapisan OpenAI-compatible yang stabil, uji nama model dan kebijakan di rute yang terkontrol, dan periksa catatan penggunaan sebelum canary.
Jam 42-48: canary hanya jika aturan berhentinya jelas
Canary bukan "nyalakan 10 persen dan pantau Slack." Canary adalah uji produksi terkontrol dengan aturan rollback.
Gunakan rencana canary minimum ini:
| Bidang | Contoh |
|---|---|
| Ruang lingkup | 2 persen pengguna beta yang login pada satu alur kerja |
| Durasi | 2 jam atau 1.000 permintaan, mana yang lebih dulu |
| Guardrail | Tingkat error kurang dari baseline ditambah 1 poin persentase |
| Gerbang kontrak | Kegagalan parse JSON di bawah 0,5 persen |
| Gerbang keamanan | Tidak ada insiden keamanan parah yang belum terselesaikan |
| Gerbang biaya | Biaya output yang diterima tidak lebih dari 10 persen di atas baseline kecuali peningkatan kualitas disetujui |
| Pemilik rollback | Engineer on-call |
| Pemilik keputusan | PM plus lead engineering |
Canary harus menghasilkan satu dari empat keputusan:
- Jangan adopsi: kandidat gagal pada penghalang keras.
- Lanjutkan pengujian: menjanjikan tetapi belum cukup aman untuk produksi.
- Rollout terbatas: berguna untuk segmen atau alur kerja yang sempit.
- Adopsi dengan kebijakan routing: pemenang untuk beban kerja yang diuji, dengan kondisi rollback yang terdokumentasi.
Kartu skor hari rilis
Salin scorecard ini ke dalam memo keputusan.
| Dimensi | Bobot | Baseline | Kandidat | Catatan keputusan |
|---|---|---|---|---|
| Tingkat output yang diterima | 25 | |||
| Tingkat kelulusan kontrak | 20 | |||
| Tingkat kegagalan parah keselamatan | 15 | |||
| Latensi p90 | 10 | |||
| Perilaku 429/retry | 10 | |||
| Biaya per output yang diterima | 15 | |||
| Kesiapan rollback | 5 |
Aturan yang disarankan:
approve_for_canary =
no_hard_blockers
and candidate_accepted_output_rate >= baseline_accepted_output_rate
and candidate_contract_pass_rate >= minimum_contract_gate
and candidate_severe_failure_rate <= baseline_severe_failure_rate
and rollback_ready == true
Aturan ini sengaja dibuat konservatif. Model baru bisa saja menarik dan tetap belum cocok untuk produk Anda hari ini.
Apa yang harus dilewati dalam 48 jam pertama
Lewati apa pun yang terlihat rigoros tetapi tidak mengubah keputusan rilis:
- Serangkaian benchmark besar yang tidak relevan dengan produk Anda.
- Eksperimen prompt tanpa test set yang terkunci.
- Tinjauan side-by-side tanpa blind dari para penggemar model.
- Perbandingan harga token tanpa tingkat penerimaan.
- Perencanaan migrasi penuh sebelum model lolos uji kontrak.
- Salinan peluncuran publik sebelum keputusan canary.
Alat benchmark terbuka seperti Language Model Evaluation Harness dari EleutherAI dapat sangat berguna ketika Anda membutuhkan run benchmark yang dapat direproduksi untuk banyak tugas. Untuk keputusan produk pada hari rilis, gunakan alat tersebut sebagai bagian dari tumpukan bukti, bukan sebagai pengganti pengujian Anda sendiri yang menyerupai produksi.
Di mana Flatkey berperan
Flatkey berguna ketika sebuah tim ingin proses evaluasi tetap dekat dengan produksi:
- Gunakan satu lapisan API yang stabil saat membandingkan rute model.
- Periksa direktori model sebelum menganggap sebuah rute tersedia.
- Simpan ID permintaan, penggunaan, biaya, dan kelas error dalam satu buku besar.
- Uji kebijakan fallback dan rollback tanpa menyebarkan kunci penyedia secara terpisah.
- Bandingkan model berdasarkan pekerjaan yang diterima, bukan hanya berdasarkan harga daftar.
CTA praktisnya sederhana: mulai dengan Flatkey API quickstart, tinjau panduan katalog model AI, dan gunakan artikel metrik API routing AI untuk menentukan bidang telemetry mana yang harus wajib ada dalam evaluasi 48 jam Anda.
Jika tim Anda masih membangun kerangka kerja yang lebih luas, baca dulu AI Routing API Tools: Evaluation Framework for Production Teams. Jika Anda mengganti penyedia, gunakan checklist alur kerja evaluasi model AI sebagai pendamping migrasi jangka panjang.
Pertanyaan umum
Apakah 48 jam cukup untuk mengevaluasi model baru?
Empat puluh delapan jam tidak cukup untuk membuktikan bahwa suatu model adalah pilihan terbaik untuk jangka panjang. Namun, waktu itu cukup untuk memutuskan apakah model tersebut layak tidak ditindaklanjuti, perlu pengujian lebih lanjut, shadow traffic, canary terbatas, atau rute produksi yang sempit.
Berapa banyak contoh yang kita perlukan untuk evaluasi model di hari rilis?
Untuk penilaian awal, gunakan 25-50 tugas golden, 50-100 tugas produksi yang berantakan, 20-40 tes kontrak, dan 20-50 probe red-team. Tambahkan jumlah set ini sebelum peluncuran yang lebih luas.
Haruskah kita menggunakan benchmark publik atau eval internal?
Gunakan keduanya jika waktu memungkinkan. Benchmark publik menunjukkan kemampuan umum dan reproduktibilitas. Eval internal menunjukkan apakah model bekerja untuk pengguna, prompt, skema, tools, target latensi, dan batasan biaya nyata Anda.
Apa metrik terpenting dalam evaluasi 48 jam?
Tingkat output yang diterima biasanya merupakan metrik garis atas yang paling praktis karena menggabungkan kualitas, kegunaan, dan kesesuaian produk. Padukan dengan tingkat lolos kontrak, tingkat kegagalan serius, latensi, dan biaya per output yang diterima.
Bagaimana tim harus membandingkan biaya model pada hari rilis?
Bandingkan biaya per output yang diterima, bukan hanya harga token. Sertakan retry, output yang ditolak, prompt perbaikan, panjang output yang lebih panjang, dan beban tinjauan manual sejauh yang bisa Anda ukur.
Kapan tim sebaiknya menghindari canarying model baru?
Hindari canarying ketika model merusak kontrak output yang ketat, menimbulkan kegagalan keselamatan yang serius, tidak dapat memenuhi kebutuhan latensi atau rate limit, tidak memiliki cakupan rollback, atau tidak dapat dilog dengan cukup baik untuk debugging.
Checklist akhir
Gunakan Cara Mengevaluasi Model Baru dalam 48 Jam: Daftar Periksa Hari Rilis sebagai disiplin untuk melawan kebisingan pada hari peluncuran.
Sebelum Anda menyetujui model baru untuk canary, pastikan:
- Beban kerja sempit dan dinamai.
- Baseline dibekukan.
- Set eval mencakup kasus golden, berantakan, kontrak, dan red-team.
- Output dinilai berdasarkan penerimaan, bukan perasaan.
- Biaya dinormalisasi berdasarkan output yang diterima.
- Perilaku latensi, retry, dan rate-limit dicatat.
- Shadow atau replay traffic telah dijalankan.
- Ruang lingkup canary dan aturan rollback sudah ditulis.
- Memo keputusan menyatakan adopsi, lanjutkan pengujian, peluncuran terbatas, atau tidak ada tindakan.
Model baru akan terus berdatangan. Tim yang menang bukanlah tim yang mencoba setiap model lebih dulu. Melainkan tim yang dapat membuat keputusan pada hari rilis tanpa merusak produk.
