Upgrade model AI bisnis tidak selesai ketika aplikasi berhasil memanggil versi baru. Model pengganti dapat menulis ringkasan lebih rapi, tetapi juga mengubah cara memilih tool, menolak permintaan, menggunakan sumber, atau menafsirkan batas approval. Perubahan yang tampak kecil bagi pengguna dapat menggeser risiko proses operasional.
Bagi AI product owner dan head of IT, pertanyaannya adalah: apakah kandidat baru tetap memenuhi kontrak kerja yang sudah diterima bisnis? Panduan ini membahas uji regresi, keputusan rilis, dan pemulihan. Rancangannya merupakan rekomendasi implementasi, bukan bukti bahwa suatu model atau layanan tertentu sudah aman untuk lingkungan Anda.
Definisikan Unit Perubahan Sebelum Membandingkan Hasil
Jangan mengganti model, prompt, knowledge base, dan skema tool sekaligus lalu menganggap semua perbedaan berasal dari model. Catat komponen yang berubah dan tahan komponen lain sebisa mungkin. Jika perubahan harus digabung, evaluasi sebagai satu paket rilis dan nyatakan bahwa atribusi penyebabnya terbatas.
Baseline perlu menyertakan identitas model yang tersedia dari provider, konfigurasi, versi prompt, daftar tool, aturan akses, dataset, serta versi aplikasi. Alias model yang diperbarui provider dapat membuat lingkungan berubah tanpa perubahan nama di kode; periksa dokumentasi provider yang digunakan sebelum menetapkan strategi penguncian versi. Tidak semua layanan menawarkan kontrol versi yang sama.
Bedakan Pembaruan Model dan Pembaruan Sumber
Upgrade model mengubah mesin yang menafsirkan konteks dan menghasilkan keluaran. Pembaruan knowledge base mengubah bahan yang dapat dirujuk sistem. Keduanya perlu diuji, tetapi memiliki jenis kegagalan berbeda. Untuk siklus dokumen, lihat panduan pembaruan knowledge base RAG; di sini fokusnya adalah perilaku aplikasi ketika komponen AI diganti.
Buat Dataset Regresi yang Mewakili Pekerjaan Nyata
Gunakan tugas yang telah dinilai reviewer bisnis, dengan data yang boleh digunakan. Setiap kasus menyimpan input, konteks, tool yang tersedia, hak pengguna, keluaran yang dapat diterima, serta tindakan yang harus ditolak. Jangan membatasi dataset pada pertanyaan yang mudah dijawab dari satu dokumen.
Pisahkan dataset penyusunan prompt dari dataset penerimaan. Tambahkan kasus baru dari temuan produksi setelah melalui penyamaran dan pengendalian akses yang sesuai. Catat asal kasus, agar contoh sintetis tidak disebut sebagai kejadian nyata atau statistik pelanggan.
- Kasus normal: informasi lengkap, sumber konsisten, dan jalur kerja yang diizinkan.
- Kasus tidak pasti: dokumen hilang, sumber bertentangan, atau pertanyaan yang membutuhkan klarifikasi.
- Kasus batas akses: pengguna tidak berhak membaca entitas lain atau menjalankan tindakan tertentu.
- Kasus kegagalan tool: timeout, hasil kosong, perubahan skema, serta request yang ternyata sudah berhasil saat respons terputus.
Nilai Hasil dan Jejak Tindakan Secara Terpisah
Jawaban akhir yang benar belum membuktikan prosesnya benar. Agent mungkin sempat membaca sumber terlarang atau mencoba mengirim tindakan yang tidak disetujui sebelum akhirnya memberi jawaban aman. Simpan jejak pemanggilan tool, parameter yang telah disamarkan, status, dan relasi approval untuk pemeriksaan.
Artikel Demystifying Evals for AI Agents dari Anthropic membahas evaluasi agent melalui tugas, percobaan, grader, dan jejak eksekusi. Untuk kebutuhan bisnis, turunkan prinsip evaluasi tersebut menjadi rubrik domain yang disepakati pemilik proses; skor umum bukan pengganti pemeriksaan tindakan kritis.
Gabungkan Pemeriksaan Deterministik dan Review Manusia
Gunakan kode untuk memeriksa struktur keluaran, ID referensi, angka hasil hitung, dan izin tindakan. Gunakan reviewer domain untuk menilai dukungan penjelasan, relevansi, serta apakah klarifikasi memang diperlukan. Bila model lain dipakai sebagai grader, kalibrasikan terhadap penilaian manusia dan audit contoh yang berbeda hasil.
Hindari syarat semua kalimat harus identik dengan baseline. Model bahasa dapat menghasilkan parafrasa yang tetap benar. Sebaliknya, jangan menerima jawaban hanya karena mirip secara semantik bila jumlah, identitas pelanggan, status persetujuan, atau referensinya salah.
Bandingkan Kandidat pada Kondisi yang Setara
Jalankan baseline dan kandidat terhadap snapshot data serta tool uji yang setara. Ulangi kasus yang memiliki variasi hasil untuk melihat kestabilan, dengan jumlah percobaan yang disepakati sebelum evaluasi. Catat seluruh hasil, bukan hanya jawaban terbaik. Variasi keluaran merupakan informasi untuk keputusan rilis.
Untuk pengujian awal, gunakan sandbox atau tool simulasi yang tidak mengirim pesan, memindahkan dana, mengubah kontrak, atau menyunting transaksi produksi. Perbedaan antara chatbot, workflow tetap, dan agent pemilih tool menentukan cakupan pengujian: semakin besar ruang tindakan, semakin penting bukti lintasan eksekusinya.
Contoh Ilustratif: Ringkasan Lebih Baik, Approval Memburuk
Misalkan kandidat baru membuat ringkasan kasus pelanggan yang dinilai lebih jelas oleh reviewer. Namun, pada kasus kontrak berubah, kandidat mencoba membuat order menggunakan approval dari versi lama. Baseline menahan kasus tersebut. Nilai bahasa yang naik tidak boleh menutupi kegagalan authority ini.
Tim memperbaiki validasi versi approval di aplikasi, lalu menguji ulang kedua model. Kasus tersebut ditambahkan ke suite regresi agar tidak hilang setelah demo. Skenario ini ilustratif dan tidak menyatakan frekuensi kegagalan model tertentu. Pelajarannya adalah bahwa kontrol aplikasi harus bertahan terhadap variasi perilaku model.
Susun Gate Rilis dan Rollback yang Dapat Dieksekusi
Tetapkan ambang per kelompok risiko, bukan hanya skor rata-rata. Contoh kriteria yang perlu disepakati: tidak ada tindakan terlarang pada suite penerimaan, sumber dan angka benar pada kasus kritis, beban review tidak memburuk melewati batas, serta biaya dan latensi berada dalam anggaran yang diuji. Ini kriteria penerimaan rancangan, bukan jaminan perilaku semua input masa depan.
Setelah lolos offline, lakukan pengamatan terbatas tanpa efek eksternal, kemudian perluasan pada kelompok yang disetujui. Tentukan siapa yang boleh melanjutkan, menahan, atau mengembalikan versi. Catat rilis pada audit trail aplikasi agar perubahan dapat ditelusuri.
Rollback model tidak membatalkan tindakan yang sudah terjadi. Simpan daftar request dalam proses dan hasil yang terkonfirmasi; hentikan tindakan baru bila status ambigu, lalu rekonsiliasi sebelum melanjutkan. Bila provider tidak lagi menyediakan baseline lama, opsi pemulihan dapat berupa penghentian fitur atau alur manual yang telah disiapkan, bukan janji kembali ke model yang tidak tersedia.
KPI yang Perlu Dibawa ke Keputusan Upgrade
- Keberhasilan tugas: kasus yang memenuhi rubrik bisnis dibanding seluruh kasus per kategori.
- Regresi kritis: pelanggaran akses, approval, angka, dan identitas dibanding baseline.
- Keandalan eksekusi: tool call salah, retry berulang, tugas ganda, serta kebutuhan pemulihan manual.
- Biaya dan waktu: biaya per hasil diterima, waktu respons, serta waktu koreksi reviewer.
Laporkan ukuran sampel dan cakupan yang belum diuji. Dataset kecil yang seluruhnya lolos tidak membuktikan tingkat kesalahan nol di produksi. Gunakan temuan pilot untuk memilih antara upgrade, perbaikan kontrol, atau menunda perubahan.
Siapkan Paket Evaluasi Sebelum Mengganti Model
Bawa daftar use case, baseline, contoh kegagalan yang sudah disamarkan, tool yang dapat dijalankan, dan pemilik approval. Melalui layanan AI dan machine learning Layana.ID, kebutuhan evaluasi dapat dibahas bersama rancangan integrasinya. Diskusikan pemetaan evaluasi upgrade AI untuk menentukan suite penerimaan, batas rollout, serta jalur pemulihan yang sesuai proses bisnis Anda.