Evaluasi agen AI: cara membangun evals dan mengukur keandalan, bukan sekadar perasaan

Mengapa perlu evaluasi jika jelas agen sudah bekerja

Justru di sinilah masalahnya: kesannya tidak jelas. Selama seminggu agen tidak pernah macet setelah prompt diubah — apakah itu karena perbaikan, atau karena minggu itu kebetulan berisi tugas-tugas mudah? Seorang insinyur yakin template baru mengubah segalanya, sementara rekannya membaca log yang sama dan tidak melihat perbedaan. Keduanya benar sejauh mereka tidak menghitung apa pun.

Evaluasi agen AI (evals) mengganti kesan dengan angka. Anda mengambil kumpulan tugas yang tetap, menjalankan agen, memeriksa hasilnya secara otomatis, dan membandingkan metrik sebelum dan sesudah perubahan. Dengan begitu perdebatan «apakah sudah lebih baik» diselesaikan oleh tabel, bukan oleh otoritas.

Tanpa evals, setiap perubahan harness — prompt, AGENTS.md, kumpulan alat, model — adalah taruhan membabi buta. Dengan evals, perubahan menjadi eksperimen dengan hasil yang terukur.

Mengapa «perasaan» menipu

Kesan dari kerja agen dipengaruhi tiga kesalahan sistematis, dan ketiganya mendorong ke keyakinan yang keliru.

• Bias penyintas. Percobaan yang berhasil diingat dan ditunjukkan ke rekan, sedangkan yang gagal diulang lalu dilupakan. Keandalan yang dihitung dari percobaan sukses saja tidak mengatakan apa-apa tentang tempat agen benar-benar patah.
• Sampel kecil. Tiga tugas sukses berturut-turut adalah kejadian biasa, bahkan bagi agen yang berhasil di separuh kasus. Peluangnya 0,5³ = 12,5%, yaitu kira-kira satu dari delapan rangkaian.
• Nada yakin. Agen menulis «selesai, semua tes lolos» dengan keyakinan yang sama, baik itu benar maupun tidak. Keyakinan model tidak terkalibrasi: nada jawaban bukan sinyal ketepatan.

Dari sini lahir aturan: apa pun yang tidak dicatat dan dihitung ulang dianggap tidak terukur.

pass@k dan pass^k: dua metrik yang sering tertukar

Agen bersifat non-deterministik: tugas yang sama bisa lolos di satu percobaan dan gagal di percobaan lain. Karena itu satu tugas dijalankan beberapa kali, lalu dihitung salah satu dari dua metrik.

pass@k: setidaknya satu dari k percobaan berhasil

Metrik ini berasal dari evaluasi generasi kode. Ia menjawab pertanyaan «mampukah sistem menyelesaikan tugas ini jika diberi beberapa kesempatan». Ini metrik yang jujur untuk skenario ketika manusia memilih yang terbaik dari beberapa hasil, atau ketika ada pemeriksaan otomatis yang andal untuk menyaring yang gagal.

pass^k: semua k percobaan berhasil

Metrik ini menjawab pertanyaan lain: «seberapa stabil agen menyelesaikan tugas ini». Ia menggambarkan kerja tanpa pengawasan — ketika agen dijalankan berkali-kali dan setiap kegagalan membuang uang atau waktu.

Perbedaannya sangat besar. Misalkan agen menyelesaikan tugas dengan peluang 70% per percobaan dan percobaan bersifat independen:

Dengan pass@5 agen tampak hampir sempurna, dengan pass^5 ia tampak tidak andal. Kedua angka benar, hanya menggambarkan hal yang berbeda. Jika Anda ingin melepas agen bekerja secara otonom, lihatlah pass^k: itu yang lebih dekat dengan apa yang akan Anda temui dalam pekerjaan nyata.

Cara menghitungnya dalam praktik

Jalankan setiap tugas n kali (misalnya 5) dan catat jumlah keberhasilan c. Untuk pass^k, perkiraannya adalah proporsi percobaan di mana k percobaan berturut-turut semuanya berhasil; secara praktis, perkirakan peluang sukses p = c / n lalu pangkatkan. Untuk kumpulan tugas, ratakan hasil per tugas.

import json
from statistics import mean

# results.jsonl: {"task": "add-pagination", "runs": [true, true, false, true, true]}
rows = [json.loads(line) for line in open("results.jsonl")]

def pass_at_k(runs, k):
    p = sum(runs) / len(runs)
    return 1 - (1 - p) ** k

def pass_pow_k(runs, k):
    p = sum(runs) / len(runs)
    return p ** k

for k in (1, 3, 5):
    print(k,
          round(mean(pass_at_k(r["runs"], k) for r in rows), 3),
          round(mean(pass_pow_k(r["runs"], k) for r in rows), 3))

Estimasi p pangkat k kasar jika n kecil, tetapi untuk membandingkan versi harness biasanya sudah cukup. Yang lebih penting: n dan kumpulan tugas tidak boleh berubah di antara perbandingan.

Cara menyusun kumpulan tugas untuk evals

Kumpulan tugas adalah aset utama. Metrik sebagus apa pun akan mengukur hal yang keliru jika tugasnya buruk.

Ambil tugas dari kenyataan Anda sendiri

Benchmark publik seperti SWE-bench berguna untuk membandingkan model, tetapi tugasnya sudah dipilih: deskripsinya jelas, tesnya tersedia. Di repositori Anda, persyaratan sering kabur dan tes kadang tidak ada, sehingga angka benchmark hampir selalu lebih tinggi daripada yang akan ditunjukkan agen di proyek Anda. Sumber tugas terbaik adalah tiket yang sudah ditutup dan kegagalan nyata agen dari log.

Komposisi kumpulan

• 20–50 tugas untuk memulai. Lebih sedikit, dan derau akan menelan selisih antarversi. Lebih banyak, dan setiap run menjadi mahal sehingga tidak lagi dijalankan.
• Jenis yang bervariasi: fitur baru, perbaikan bug, refaktor, tugas di modul orang lain, tugas dengan jebakan (jawaban yang benar adalah «jangan dilakukan begitu» atau «perlu klarifikasi»).
• Setiap tugas yang gagal di pekerjaan nyata menjadi tes. Dengan cara ini kumpulan tumbuh bersama pemahaman tentang kelemahan agen, dan regresi tidak luput tanpa diketahui.
• Keadaan awal yang tetap: commit tertentu, dependensi yang dikunci, lingkungan yang sama. Jika tidak, yang Anda ukur adalah pergeseran lingkungan, bukan agennya.

Format tugas

Setiap tugas terdiri dari deskripsi, keadaan awal, dan kriteria keberhasilan yang bisa diperiksa tanpa manusia.

id: add-pagination
repo_ref: 3f2c1ab
prompt: |
  Tambahkan paginasi ke GET /payments: parameter limit (default 20, maksimum 100)
  dan cursor. Respons berisi next_cursor.
check:
  - pytest tests/test_payments_pagination.py
  - mypy app/
limits:
  max_changed_files: 6

Perhatikan bahwa kriteria keberhasilan adalah Definition of Done yang ditulis dalam bentuk perintah. Jika Anda tidak bisa menuliskan kriteria untuk suatu tugas, itu tanda bahwa tugas itu juga diberikan kepada agen secara ambigu.

Pemeriksaan otomatis atau LLM-juri

Hasil bisa diperiksa dengan kode atau dengan model lain. Setiap cara punya wilayahnya sendiri.

Aturan: kode dulu, juri di atasnya

Semua yang bisa diperiksa secara deterministik, periksa secara deterministik. LLM-juri hanya ditambahkan untuk sifat yang tidak bisa diungkapkan dengan kode, dan tidak pernah sebagai pengganti tes.

Cara membuat LLM-juri berguna

• Konteks yang berbeda dari generator. Juri tidak boleh melihat penalaran agen — hanya tugas, kriteria, dan diff akhir. Jika tidak, ia akan mengulangi kesalahan yang sama: inilah N-versioning, dua pandangan independen alih-alih satu.
• Rubrik, bukan «nilai dari skala sepuluh». Pertanyaan konkret dengan jawaban ya/tidak: «apakah ada validasi limit > 100», «apakah berkas di luar app/payments berubah».
• Kalibrasi dengan penandaan manual. Tandai secara manual 20–30 hasil dan bandingkan dengan vonis juri. Jika kesesuaiannya rendah, perbaiki rubriknya, jangan malah makin mempercayai juri.
• Asimetri kesalahan. «Selesai» yang keliru lebih mahal daripada «belum selesai» yang keliru: yang pertama masuk ke produksi, yang kedua hanya biaya satu kali jalan ulang. Atur juri agar menolak jika ragu.

Metrik apa saja selain persentase keberhasilan

Persentase tugas yang terselesaikan hanya puncak gunung es. Untuk mengetahui di mana harus memperbaiki, diperlukan metrik keandalan dari rekayasa klasik.

• MTBF — berapa banyak langkah atau tugas yang dilalui agen sebelum macet. Menunjukkan seberapa jarang ia rusak.
• MTTR — berapa lama waktu untuk kembali ke keadaan kerja setelah kegagalan. Menurunkannya hampir selalu lebih murah daripada menaikkan MTBF: berkas kemajuan yang baik dan lingkungan yang bisa direproduksi bisa memangkas pemulihan berkali-kali lipat.
• Radius dampak — berapa banyak kode yang rusak akibat satu langkah yang gagal. Dibatasi oleh batas ukuran diff dan isolasi salinan kerja.
• Proporsi «selesai» yang keliru — tugas ketika agen menyatakan sukses, tetapi pemeriksaan gagal. Ini metrik paling berbahaya: justru di sinilah terlihat apakah laporan agen bisa dipercaya.
• Biaya dan waktu — token dan menit per tugas. Harness yang menaikkan keberhasilan 5% tetapi menggandakan biaya tidak selalu menang.

Log kegagalan: evals dari pekerjaan sehari-hari

Tidak semua tim siap langsung membangun pengelola run. Versi minimal dari evaluasi adalah log kegagalan dengan tiga kolom.

| Tugas                   | Hasil                              | Lapisan       |
|-------------------------|------------------------------------|---------------|
| paginasi /payments      | «selesai», 2 tes merah             | verifikasi    |
| perbaikan timeout webhook | 30 menit untuk pip install       | lingkungan    |
| refaktor refunds        | sintaks ORM lama                   | konteks       |

Lapisan adalah salah satu dari lima tempat agen biasanya patah: spesifikasi tugas, konteks, lingkungan eksekusi, umpan balik verifikasi, dan manajemen keadaan. Setelah dua puluh catatan, terlihat di mana hambatan sebenarnya, dan hampir tidak pernah berada di tempat yang Anda kira. Setiap baris log adalah kandidat tugas untuk evals.

Mengapa model yang lebih kuat tidak selalu menyelesaikan masalah

Reaksi pertama terhadap kegagalan agen adalah memilih model yang lebih mahal. Kadang ini membantu, tetapi lebih sering yang menutup jurang antara benchmark dan kenyataan Anda bukan modelnya, melainkan lingkungan di sekitarnya.

Jika agen menghabiskan setengah jam untuk menyiapkan lingkungan, itu masalah lapisan lingkungan, dan model paling canggih pun akan menghabiskan waktu yang sama. Jika agen mengatakan «selesai» padahal tesnya merah, itu masalah lapisan verifikasi: tidak ada perintah yang memberitahunya kebenaran. Jika ia menulis kode dengan gaya yang asing, berarti konvensi proyek tidak diberikan kepadanya. Tidak satu pun dari masalah ini berkaitan dengan kecerdasan model.

Evals memungkinkan Anda menguji ini dengan jujur. Jalankan kumpulan dengan model saat ini dan model yang lebih mahal, lalu dengan model saat ini dan AGENTS.md yang ditambahi perintah verifikasi. Sering kali perubahan kedua memberi peningkatan lebih besar daripada yang pertama, tanpa biaya. Tetapi jangan percaya begitu saja: untuk perbandingan semacam inilah kumpulan dibutuhkan.

Rencana langkah demi langkah: evaluasi agen AI dalam seminggu

1. Hari 1. Buat log kegagalan dan catat setiap kegagalan agen beserta lapisannya.
2. Hari 2. Pilih 20 tugas dari tiket yang sudah ditutup dan dari log. Untuk setiap tugas, catat commit dan tuliskan kriteria keberhasilan dalam bentuk perintah.
3. Hari 3. Tulis pengelola run: salinan kerja yang bersih, menjalankan agen dengan prompt tugas, menjalankan pemeriksaan, dan mencatat hasil ke JSONL.
4. Hari 4. Jalankan setiap tugas 3–5 kali. Hitung pass@1, pass^3, proporsi «selesai» yang keliru, dan rata-rata biaya.
5. Hari 5. Ubah satu hal di harness dan jalankan ulang. Bandingkan hanya jika kumpulan dan jumlah pengulangan sama.

Ubah satu variabel dalam satu waktu. Jika dalam satu eksperimen Anda mengganti model, prompt, dan alat sekaligus, Anda tidak akan tahu apa yang berhasil.

Kesalahan umum dalam mengevaluasi agen

• Satu run per tugas. Sifat non-deterministik agen membuat hasil seperti undian. Minimal tiga pengulangan.
• Kumpulan berubah di antara perbandingan. Menambah tugas baru dan sekaligus mengubah prompt membuat angka tidak bisa dibandingkan.
• Agen melihat tes verifikasi. Jika tes ada di repositori, agen bisa menyesuaikan kode dengannya atau malah mengubah tesnya. Simpan pemeriksaan tersembunyi di luar salinan kerja dan pastikan agen tidak menyentuh berkas tes.
• Laporan agen sebagai pengganti verifikasi. «Semua tes lolos» dalam jawaban model bukan hasil. Hasilnya adalah kode keluar dari perintah yang dijalankan pengelola run.
• Hanya pass@k. Angka yang cantik untuk presentasi, tetapi prediksi yang buruk untuk kerja otonom.

Ringkasnya

Evaluasi agen AI adalah kumpulan tugas nyata yang tetap, pemeriksaan otomatis, dan metrik yang dihitung ulang setiap kali harness berubah. pass@k menunjukkan apa yang mampu dilakukan agen, pass^k menunjukkan apakah ia bisa dipercaya tanpa pengawasan. Pemeriksaan otomatis memberi kebenaran, LLM-juri dengan rubrik dan konteks terpisah melengkapinya di tempat kode tidak bisa menjangkau. Log kegagalan berdasarkan lima lapisan menunjukkan apa yang harus diperbaiki lebih dulu, dan seringkali bukan modelnya. Metrik keandalan dan loop diagnostik dibahas dengan praktik nyata dalam kursus harness engineering.