Eval sebelum fitur: suite uji sebelum prompt

Eval adalah uji yang dapat diulang yang menilai keluaran sistem AI terhadap standar yang ditentukan: sekumpulan input representatif, perilaku yang diharapkan, dan metode penilaian. Sebuah suite eval mengubah pertanyaan kabur 'apakah AI sudah cukup baik?' menjadi angka yang disepakati semua pihak sejak awal.

Menulisnya lebih dulu membalik urutan biasa. Alih-alih membangun fitur lalu bertanya apakah berfungsi, PRIONATION menentukan apa itu 'berfungsi' — dataset acuan, ambang kelulusan, kasus kegagalan — dan baru kemudian membangun sistem untuk memenuhinya.

Mode kegagalan yang umum adalah pengembangan berbasis demo: prototipe tampak mengesankan pada beberapa input pilihan, semua orang antusias, lalu dirilis. Di produksi ia bertemu input yang tak pernah diuji, gagal diam-diam, dan perdebatan menjadi subjektif — 'modelnya salah' versus 'promptnya benar' — tanpa standar bersama untuk memutuskan.

Tanpa eval, tidak ada pula garansi yang jujur. Jika 'selesai' tak pernah didefinisikan, tidak ada cara mengatakan apakah regresi di kemudian hari adalah bug yang diperbaiki gratis atau pekerjaan baru yang harus ditagih. Ketiadaan eval inilah yang membuat sebagian besar proyek AI diam-diam tak berujung.

Setiap Build dimulai dengan menyusun dataset acuan dari input nyata dan representatif, serta menentukan rubrik penilaian masing-masing — pencocokan persis bila sesuai, penilaian oleh model bila perlu pertimbangan, dengan ambang eksplisit. Ini menjadi pemeriksaan regresi otomatis yang berjalan di CI pada setiap perubahan.

Suite eval dispesifikasikan selama Diagnostic dua minggu, sebelum Build ditawarkan. Itu disengaja: suite adalah kontraknya. Itulah dasar penetapan harga tetap dan tolok ukur garansi pasca-peluncuran empat minggu.

Eval memberi makan telemetri: logika penilaian yang sama yang menjadi gerbang build dijalankan terhadap trafik produksi, sehingga performa langsung diukur dengan tolok ukur yang sama dengan build. Eval bergantung pada infrastruktur yang dimiliki, karena dataset acuan dan harness eval adalah aset klien yang dikirim bersama kode.

Dan eval membuat pod ramping menjadi mungkin. Tim kecil bisa bergerak cepat justru karena suite eval menangkap regresi secara otomatis, menghapus QA manual yang jika tidak akan memperlambat pod dua hingga tiga orang.

Harga tetap hanya jujur jika 'selesai' didefinisikan sebelum angka disepakati. Eval adalah definisi itu. Eval mengubah masalah riset terbuka menjadi masalah rekayasa yang berbatas: bangun sistem yang skornya di atas ambang pada suite yang disepakati.

Itulah sebabnya PRIONATION memperlakukan spesifikasi eval sebagai keluaran sebenarnya dari Diagnostic. Begitu ia ada, Build menjadi minim risiko bagi kedua pihak — ruang lingkup tidak bisa membengkak diam-diam, dan hasilnya tidak bisa diperdebatkan.

Kesalahan paling umum adalah memperlakukan eval sebagai langkah QA di akhir, bukan sebagai spesifikasi di awal. Ditulis belakangan, eval hanya mengonfirmasi apa yang sudah dibangun; ditulis lebih dulu, ia membatasi apa yang akan dibangun. Urutannya adalah inti persoalannya.

Kesalahan kedua adalah menilai berdasarkan kesan — segelintir contoh pilihan yang terlihat bagus saat demo. Suite yang sungguhan menyertakan input yang merusak sistem: kasus tepi, frasa adversarial, dan format yang tak terduga. Kasus-kasus itulah yang menentukan apakah sebuah sistem bertahan saat berhadapan dengan produksi.