Pengembangan Agen Berbasis Evaluasi: Bagaimana Saya Berhenti Menyetel Prompt Berdasarkan Intuisi

Saya mengubah sebuah prompt. Hasil eksekusi berikutnya terlihat lebih baik. Apakah perubahan itu membantu, atau saya hanya sedang beruntung?

Untuk waktu yang lama, jawaban saya adalah "Sepertinya begitu." Saya akan mengubah sedikit sebuah perintah, menjalankan pipeline, melihatnya berhasil, lalu meluncurkannya. Ini adalah rekayasa berbasis intuisi (vibes-based engineering). Hampir semua orang yang membangun agen melakukan ini karena alternatifnya terasa sulit.

Namun, agen pengkodean bersifat non-deterministik. Anda dapat menjalankan tugas yang sama dua kali dan mendapatkan dua hasil yang berbeda. Satu kali eksekusi yang berhasil tidak memberi tahu apa pun. Anda tidak bisa membedakan apakah perubahan Anda berhasil atau apakah lemparan dadunya saja yang sedang bagus.

Saya mengatasi hal ini dengan menggunakan disiplin machine learning. Saya membangun kerangka kerja evaluasi (evaluation framework) untuk membungkus seluruh sistem saya.

Berikut adalah cara kerja kerangka kerja tersebut:

• Target: Kode dasar (codebase) yang dibekukan. Ini tetap sama agar skor tetap dapat dibandingkan. • Tugas: Item benchmark spesifik dengan prompt dan oracle. • Oracle: Pemeriksaan deterministik. Ini adalah perintah shell yang harus lolos. • Varian: Perubahan spesifik yang Anda uji, seperti planner baru. • Uji coba (Trial): Satu kali eksekusi. Saya menjalankan setiap tugas berkali-kali untuk memperhitungkan faktor keacakan.

Saya menggunakan dua jenis penilaian untuk menangkap kegagalan yang berbeda:

  • Code Graders (Deterministik): Ini memeriksa tingkat kelulusan tes, biaya, waktu, dan perubahan file.
  • LLM Judge (Probabilistik): Model terpisah yang tetap akan menilai kualitas spesifikasi dan akurasi implementasi.

Code grader memberi tahu Anda apakah kodenya berjalan. Judge memberi tahu Anda apakah kodenya bagus. Anda membutuhkan keduanya.

Saya juga berhenti menggunakan rata-rata. Nilai rata-rata (mean) menipu dalam hal agen. Jika sebuah tugas berhasil 2 dari 3 kali, itu terlihat oke. Namun, itu tidak dapat diandalkan. Sebagai gantinya, saya menggunakan dua metrik:

  • pass@k: Apakah agen berhasil setidaknya satu kali? (Kapabilitas)
  • pass^k: Apakah agen berhasil setiap saat? (Reliabilitas)

Lonjakan pada pass^k adalah kemenangan yang sebenarnya. Itu berarti Anda membuat agen menjadi konsisten, bukan sekadar beruntung.

Untuk menjaga sistem tetap tajam, saya menambahkan tugas-tugas sulit yang membutuhkan pemahaman mendalam. Ketika agen gagal menangani bug nyata, saya mengubah kegagalan tersebut menjadi tugas permanen. Ini menciptakan loop tertutup (closed loop). Benchmark menjadi lebih sulit seiring dengan semakin baiknya agen tersebut.

Infrastruktur ini membutuhkan banyak kerja keras, tetapi ini adalah hal dengan daya ungkit (leverage) tertinggi yang saya bangun. Ini mengubah "Saya rasa ini lebih baik" menjadi "ini 20% lebih andal dengan biaya yang lebih rendah."

Agen pengkodean mudah untuk didemonstrasikan tetapi sulit untuk dipercaya. Jika Anda ingin melampaui sekadar demo, Anda harus memutuskan untuk melakukan pengukuran.

Sumber: https://dev.to/rickjms/eval-driven-agent-development-how-i-stopped-tuning-prompts-on-vibes-1189

Komunitas pembelajaran opsional: https://t.me/GyaanSetuAi