Saat Anda membuat perintah untuk aplikasi nyata, akan muncul pertimbangan penting: menyeimbangkan keringkasan dengan efektivitas. Jika semua faktor setara, perintah yang ringkas akan lebih cepat, lebih murah, dan lebih mudah dikelola daripada perintah yang lebih panjang. Hal ini sangat relevan di lingkungan web yang sensitif terhadap latensi dan batas token. Namun, jika perintah Anda terlalu minim, model mungkin tidak memiliki konteks, petunjuk, atau contoh untuk menghasilkan hasil berkualitas tinggi.
Pengembangan berbasis evaluasi (EDD) memungkinkan Anda memantau dan mengoptimalkan kompromi ini secara sistematis. EDD menawarkan proses yang dapat diulang dan diuji untuk meningkatkan output dalam langkah-langkah kecil yang meyakinkan, mendeteksi regresi, dan menyelaraskan perilaku model dengan ekspektasi pengguna dan produk dari waktu ke waktu.
Anggap saja ini sebagai pengembangan berbasis pengujian (TDD), yang disesuaikan untuk ketidakpastian AI. Tidak seperti pengujian unit deterministik, evaluasi AI tidak dapat di-hardcode karena output, baik yang terbentuk dengan baik maupun yang gagal, dapat mengambil bentuk yang tidak terduga.
EDD juga mendukung upaya penemuan Anda. Sama seperti menulis pengujian yang membantu memperjelas perilaku fitur, menentukan kriteria evaluasi dan meninjau output model memaksa Anda menghadapi kurangnya kejelasan dan secara bertahap menambahkan lebih banyak detail dan struktur pada tugas yang terbuka atau tidak dikenal.
Mendefinisikan masalah
Anda dapat menyusun masalah Anda seperti kontrak API, termasuk jenis input, format output, dan batasan tambahan. Contoh:
- Jenis masukan: draf postingan blog
- Format output: Array JSON dengan 3 judul postingan
- Batasan: kurang dari 128 karakter, menggunakan bahasa yang ramah
Kemudian, kumpulkan contoh input. Untuk memastikan keragaman data, Anda menyertakan contoh ideal dan input yang nyata dan tidak teratur. Pikirkan variasi dan kasus ekstrem, seperti postingan dengan emoji, struktur bertingkat, dan banyak cuplikan kode.
Melakukan inisialisasi dasar pengukuran
Tulis perintah pertama Anda. Anda dapat memulai dengan zero-shot dan menyertakan:
- Petunjuk yang jelas
- Format output
- Placeholder untuk variabel input
Anda meningkatkan kompleksitas dan bekerja dengan komponen lain serta teknik perintah lanjutan saat mengevaluasi dan mengoptimalkan. Pertama, kita perlu menyiapkan sistem evaluasi untuk mengarahkan upaya pengoptimalan ke arah yang tepat.
Membuat sistem evaluasi
Dalam TDD, Anda mulai menulis pengujian setelah mengetahui persyaratan. Dengan AI generatif, tidak ada output pasti yang dapat diuji, jadi Anda perlu berupaya lebih keras untuk membuat loop evaluasi.
Anda mungkin memerlukan beberapa alat pengukuran untuk mengevaluasi secara efektif.
Tentukan metrik evaluasi Anda
Metrik evaluasi dapat bersifat deterministik. Misalnya, Anda dapat memeriksa apakah model menampilkan JSON yang valid atau menghasilkan jumlah item yang benar.
Namun, sebagian besar waktu Anda harus didedikasikan untuk mengidentifikasi dan menyempurnakan metrik subjektif atau kualitatif, seperti kejelasan, kegunaan, nada bahasa, atau kreativitas. Anda mungkin memulai dengan sasaran yang luas, tetapi dengan cepat menghadapi masalah yang lebih rumit.
Misalnya, generator judul Anda terlalu sering menggunakan frasa atau pola tertentu, sehingga menghasilkan hasil yang berulang dan tidak alami. Dalam hal ini, Anda akan menentukan metrik baru untuk mendorong variasi dan mencegah penggunaan berlebihan pada struktur atau kata kunci. Seiring waktu, metrik inti Anda akan stabil dan Anda dapat melacak peningkatannya.
Proses ini dapat memanfaatkan pakar yang memahami seperti apa kualitas yang baik dalam domain aplikasi Anda dan dapat menemukan mode kegagalan yang tidak terlihat jelas. Misalnya, jika Anda mengembangkan asisten penulisan, berkolaborasilah dengan produser atau editor konten untuk memastikan evaluasi Anda selaras dengan pandangan dunia mereka.
Pilih juri Anda
Kriteria evaluasi yang berbeda memerlukan evaluator yang berbeda:
- Pemeriksaan berbasis kode berfungsi dengan baik untuk output deterministik atau berbasis aturan. Misalnya, Anda dapat memindai judul untuk mencari kata-kata yang ingin dihindari, memeriksa jumlah karakter, atau memvalidasi struktur JSON. Ini cepat, dapat diulang, dan sempurna untuk elemen UI output tetap, seperti tombol atau kolom formulir.
- Masukan dari manusia sangat penting untuk menilai kualitas yang lebih subjektif, termasuk nada bahasa, kejelasan, atau kegunaan. Terutama pada tahap awal, meninjau sendiri output model (atau dengan pakar domain) memungkinkan iterasi yang cepat. Namun, pendekatan ini tidak dapat diskalakan dengan baik. Setelah meluncurkan aplikasi, Anda juga dapat mengumpulkan sinyal dalam aplikasi, seperti rating bintang, tetapi sinyal ini cenderung bising dan tidak memiliki nuansa yang diperlukan untuk pengoptimalan yang presisi.
- LLM sebagai juri menawarkan cara yang skalabel untuk mengevaluasi kriteria subjektif dengan menggunakan model AI lain untuk memberi skor atau mengkritik output. Proses ini lebih cepat daripada peninjauan manual, tetapi bukan tanpa kekurangan: dalam penerapan yang naif, proses ini dapat melanggengkan dan bahkan memperkuat bias dan kesenjangan pengetahuan model.
Prioritaskan kualitas daripada kuantitas. Dalam machine learning klasik dan AI prediktif, praktik umumnya adalah melakukan crowdsource anotasi data. Untuk AI generatif, anotator yang diperoleh dari banyak sumber sering kali tidak memiliki konteks domain. Evaluasi berkualitas tinggi dan kaya konteks lebih penting daripada skala.
Mengevaluasi dan mengoptimalkan
Semakin cepat Anda dapat menguji dan menyempurnakan perintah, semakin cepat Anda akan mendapatkan sesuatu yang sesuai dengan ekspektasi pengguna. Anda harus membiasakan diri melakukan pengoptimalan berkelanjutan. Coba lakukan peningkatan, evaluasi, dan coba yang lain.
Setelah dalam produksi, terus amati dan evaluasi perilaku pengguna Anda dan sistem AI Anda. Kemudian, analisis dan ubah data ini menjadi langkah-langkah pengoptimalan.
Mengotomatiskan pipeline evaluasi
Untuk mengurangi hambatan dalam upaya pengoptimalan, Anda memerlukan infrastruktur operasional yang mengotomatiskan evaluasi, melacak perubahan, dan menghubungkan pengembangan ke produksi. Proses ini biasanya disebut LLMOps. Meskipun ada platform yang dapat membantu otomatisasi, Anda harus mendesain alur kerja yang ideal sebelum menggunakan solusi pihak ketiga.
Berikut beberapa komponen utama yang perlu dipertimbangkan:
- Pembuatan versi: Simpan perintah, metrik evaluasi, dan input pengujian dalam kontrol versi. Perlakukan sebagai kode untuk memastikan reproduksibilitas dan histori perubahan yang jelas.
- Evaluasi batch otomatis: Gunakan alur kerja (seperti GitHub Actions) untuk menjalankan evaluasi pada setiap pembaruan perintah dan membuat laporan perbandingan.
- CI/CD untuk perintah: Membatasi deployment dengan pemeriksaan otomatis, seperti pengujian deterministik, skor LLM sebagai hakim, atau pembatasan, dan memblokir penggabungan saat kualitas menurun.
- Logging dan kemampuan observasi produksi: Mencatat input, output, error, latensi, dan penggunaan token. Pantau penyimpangan, pola yang tidak terduga, atau lonjakan kegagalan.
- Penyerapan masukan: Mengumpulkan sinyal pengguna (jempol, penulisan ulang, pengabaian) dan mengubah masalah berulang menjadi kasus pengujian baru.
- Pelacakan eksperimen: Lacak versi perintah, konfigurasi model, dan hasil evaluasi.
Lakukan iterasi dengan perubahan kecil yang ditargetkan
Penyempurnaan perintah biasanya dimulai dengan meningkatkan kualitas bahasa perintah Anda. Hal ini dapat berarti membuat petunjuk lebih spesifik, memperjelas maksud, atau menghilangkan ambiguitas.
Berhati-hatilah agar tidak terlalu cocok (overfit). Kesalahan umum adalah menambahkan aturan yang terlalu sempit untuk menambal masalah model. Misalnya, jika generator judul Anda terus menghasilkan judul yang dimulai dengan Panduan Lengkap, Anda mungkin tergoda untuk melarang frasa ini secara eksplisit. Sebagai gantinya, abstraksikan masalah dan sesuaikan petunjuk tingkat yang lebih tinggi. Hal ini dapat berarti Anda menekankan orisinalitas, variasi, atau gaya editorial tertentu, sehingga model mempelajari preferensi yang mendasarinya, bukan satu pengecualian.
Cara lainnya adalah bereksperimen dengan lebih banyak teknik perintah dan menggabungkan upaya ini. Saat memilih teknik, tanyakan pada diri Anda: apakah tugas ini paling baik diselesaikan melalui analogi (few-shot), penalaran langkah demi langkah (chain-of-thought), atau penyempurnaan iteratif (self-reflection)?
Saat sistem Anda memasuki tahap produksi, siklus EDD Anda tidak boleh melambat. Jika ada, seharusnya lebih cepat. Jika sistem Anda memproses dan mencatat input pengguna, input tersebut akan menjadi sumber insight yang paling berharga. Tambahkan pola berulang ke rangkaian evaluasi Anda, dan terus identifikasi serta terapkan langkah-langkah pengoptimalan terbaik berikutnya.
Kesimpulan Anda
Pengembangan perintah berbasis evaluasi memberi Anda cara terstruktur untuk mengatasi ketidakpastian AI. Dengan mendefinisikan masalah secara jelas, membangun sistem evaluasi yang disesuaikan, dan melakukan iterasi melalui peningkatan kecil yang ditargetkan, Anda akan membuat feedback loop yang terus meningkatkan output model.
Resource
Berikut beberapa bacaan yang direkomendasikan jika Anda ingin menerapkan LLM sebagai hakim:
- Membandingkan kemampuan LLM dengan ringkasan.
- Baca panduan Hamel Husain tentang penggunaan LLM sebagai Penilai.
- Baca makalah: A Survey on LLM-as-a-Judge.
Jika Anda tertarik untuk lebih meningkatkan kualitas perintah, baca selengkapnya tentang pengembangan yang sadar konteks. Hal ini paling baik dilakukan oleh engineer machine learning.
Uji pemahaman Anda
Apa tujuan utama pengembangan berbasis evaluasi?
Mengapa menggunakan model yang lebih besar untuk mengevaluasi sistem sisi klien?
Apa potensi kekurangan menggunakan LLM sebagai hakim untuk evaluasi?
Komponen mana yang merupakan bagian dari pipeline evaluasi otomatis yang direkomendasikan?
Saat memilih juri untuk sistem evaluasi Anda, apa batasan utama penggunaan masukan manusia?