Evaluasi AI sebelum rilis: golden set, rubrik, dan tes regresi

Model baru menghasilkan tulisan yang terasa lebih bagus. Editor menyukainya pada tiga contoh, lalu prompt itu dipasang untuk semua pekerjaan. Dua hari kemudian, sistem menghilangkan syarat akses pada pengumuman produk. Tanpa kumpulan evaluasi yang tetap, tim sulit mengetahui apakah perubahan itu kemajuan atau hanya cocok dengan contoh yang kebetulan dipilih.

Panduan evaluasi OpenAI menekankan tugas yang spesifik, dataset yang mewakili penggunaan, pemeriksaan manusia, dan evaluasi berkelanjutan. Kita akan menerapkannya pada ringkasan berita AI. Semua angka dan kasus di artikel ini bersifat sintetis; bukan perbandingan kinerja model tertentu.

Tetapkan keputusan yang ingin dibantu

Evaluasi harus berakhir pada keputusan operasional: rilis, tahan, atau batasi penggunaan pada jenis tugas tertentu. “Skor lebih tinggi” belum cukup jika kenaikan gaya bahasa disertai penurunan ketepatan fakta.

Tuliskan kriteria keras dan preferensi lunak. Kriteria keras dapat berupa tidak menambah angka, mempertahankan status preview, dan menyertakan bukti untuk klaim utama. Preferensi lunak dapat berupa ringkas, runtut, dan sesuai suara redaksi. Kriteria keras sebaiknya tidak hilang di rata-rata berbobot yang dapat ditutupi oleh nilai gaya.

Definisikan pula unit penilaian. Satu artikel dapat memiliki banyak klaim, sehingga akurasi per artikel dan akurasi per klaim memiliki penyebut berbeda. Pilih ukuran yang menjawab risiko kerja yang ingin dikendalikan.

Golden set harus mencakup kasus sulit

Bagi data menjadi bahan pengembangan dan kumpulan evaluasi yang ditahan. Bila semua contoh berulang kali dilihat saat memperbaiki prompt, kumpulan tersebut berubah menjadi bahan latihan informal. Tambahkan evaluasi baru dari kegagalan nyata yang telah ditinjau.

Contoh pembagian kasus untuk redaksi:

Dataset perlu merepresentasikan distribusi kerja, tetapi kelompok langka yang berisiko tetap harus terlihat. Laporkan hasil keseluruhan dan hasil per kelompok. Dominasi kasus mudah dapat menyembunyikan kegagalan pada kelompok kecil.

Buat rubrik yang dapat dipakai dua penilai

Rubrik “bagus atau buruk” terlalu longgar. Tulis definisi konkret: klaim utama didukung, syarat akses utuh, tanggal tepat, atribusi tidak berpindah, dan analisis diberi label. Sertakan contoh batas antara revisi kecil dan kesalahan faktual.

Minta dua penilai membaca sampel yang sama tanpa mengetahui model atau versi prompt. Perbedaan penilaian adalah sinyal untuk memperbaiki rubrik. Jangan langsung merata-ratakan ketidaksepakatan tentang apa yang dianggap salah.

Jika memakai model sebagai penilai, kalibrasikan terhadap penilaian manusia dan uji bias urutan. Pada evaluasi berpasangan, tukar posisi A/B untuk sebagian sampel. Penilai otomatis yang konsisten menyukai jawaban lebih panjang belum tentu mengukur ketepatan.

Hitung metrik dari label, bukan dari kesan

Untuk komponen pendeteksi klaim bermasalah, gunakan confusion matrix. Contoh Python lokal berikut mengasumsikan label 1 berarti bermasalah dan 0 berarti tidak:

def classification_report(expected, predicted):
    if len(expected) != len(predicted) or not expected:
        raise ValueError("Label harus berpasangan dan tidak kosong")
    if any(value not in (0, 1) for value in expected + predicted):
        raise ValueError("Gunakan label 0 atau 1")
    tp = sum(a == 1 and b == 1 for a, b in zip(expected, predicted))
    fp = sum(a == 0 and b == 1 for a, b in zip(expected, predicted))
    fn = sum(a == 1 and b == 0 for a, b in zip(expected, predicted))
    precision = tp / (tp + fp) if tp + fp else None
    recall = tp / (tp + fn) if tp + fn else None
    return {"tp": tp, "fp": fp, "fn": fn,
            "precision": precision, "recall": recall}


print(classification_report([1, 1, 0, 0], [1, 0, 1, 0]))

Hasil contoh memiliki satu true positive, satu false positive, dan satu false negative. Precision serta recall masing-masing 0,5. None menandakan penyebut tidak tersedia; jangan diam-diam menggantinya dengan skor sempurna. Untuk tugas generatif, metrik ini hanya berlaku setelah definisi label ditetapkan.

Perubahan kecil membutuhkan perbandingan yang adil

Jalankan versi lama dan baru pada input yang sama. Simpan konfigurasi model, prompt, tools, indeks sumber, dan waktu pengujian. Perubahan retrieval dapat memengaruhi jawaban meski model tetap sama.

Model dapat menghasilkan variasi antarrun. Untuk kasus yang tidak stabil, ulangi pengukuran secukupnya dan laporkan variasinya. Selisih satu kasus pada sampel kecil tidak layak diklaim sebagai peningkatan universal. Bila memakai interval statistik, jelaskan metode dan unit sampelnya.

Selain kualitas, ukur waktu hasil diterima dan biaya per hasil lolos review. Konsep SLO Google SRE membantu memisahkan indikator yang diukur dari target layanan. Target internal perlu disesuaikan dengan kebutuhan produk, bukan disalin dari contoh perusahaan lain.

Jadikan hasil evaluasi bagian dari keputusan rilis

Buat laporan singkat yang menampilkan perubahan per kelompok, kegagalan baru, kasus yang diperbaiki, serta tradeoff biaya dan latensi. Tetapkan ambang sebelum melihat hasil akhir agar kriteria tidak digeser untuk meloloskan versi yang sudah disukai.

Jika versi baru lebih baik untuk ringkasan sederhana tetapi lebih buruk pada dokumen bertentangan, batasi penggunaannya. Rilis bertahap dengan jalur kembali lebih berguna daripada satu keputusan “model ini terbaik” untuk semua tugas.

Simpan contoh kegagalan sebagai aset evaluasi yang diberi revisi dan hak akses. Latihan pertama dapat dimulai dari dua puluh dokumen yang sudah dipahami editor, lalu diperluas secara terarah. Untuk menghubungkan hasil kualitas dengan keputusan anggaran, lanjutkan ke ledger biaya AI.