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 pasti, 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 dikodekan secara permanen 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 bersifat terbuka atau tidak dikenal.
Mendefinisikan masalah
Anda dapat menyusun masalah Anda seperti kontrak API, termasuk jenis input, format output, dan batasan tambahan. Contoh:
- Jenis input: Draf postingan blog
- Format output: Array JSON dengan 3 judul postingan
- Batasan: kurang dari 128 karakter, menggunakan gaya bahasa yang bersahabat
Kemudian, kumpulkan contoh input. Untuk memastikan keragaman data, Anda menyertakan contoh ideal dan input yang nyata dan tidak teratur. Pikirkan variasi dan kasus tepi, seperti postingan dengan emoji, struktur bertingkat, dan banyak cuplikan kode.
Melakukan inisialisasi dasar pengukuran
Tulis perintah pertama Anda. Mulailah dengan zero-shot dan sertakan petunjuk yang jelas, format output, dan placeholder variabel untuk konten input.
Anda akan meningkatkan kompleksitas sistem dan menggunakan komponen atau teknik perintah tambahan untuk mengoptimalkan sistem AI. Untuk memastikan kita menggunakan waktu secara efisien dan mengoptimalkan komponen yang tepat, Anda perlu menyiapkan sistem evaluasi.
Membuat sistem evaluasi
Dalam TDD, Anda mulai menulis pengujian setelah mengetahui persyaratan. Dengan AI generatif, tidak ada output pasti yang dapat diuji, sehingga 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, yang berarti ada jawaban yang benar dan diketahui. Misalnya, Anda dapat memeriksa apakah model menampilkan JSON yang valid atau menghasilkan jumlah item yang benar.
Namun, dengan AI, Anda akan menghabiskan sebagian besar waktu untuk mengidentifikasi dan menyempurnakan pengukuran kualitatif yang subjektif. Hal ini mencakup kualitas, kegunaan, gaya bahasa, dan kreativitas output. Anda dapat memulai dengan sasaran kesuksesan yang lebih luas, untuk mengetahui bagaimana output harus memenuhi ekspektasi Anda. Pada akhirnya, Anda akan menghadapi masalah spesifik dan rumit yang membantu Anda menentukan sasaran dengan lebih baik.
Misalnya, generator judul Anda terlalu sering menggunakan frasa atau pola tertentu, sehingga menghasilkan hasil yang berulang dan tidak alami. Dalam hal ini, Anda harus 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 produsen 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 tidak akurat dan tidak memiliki nuansa yang diperlukan untuk pengoptimalan yang presisi.
- LLM-as-judge 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 sederhana, 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, pemberi anotasi yang diperoleh dari banyak orang 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 merancang 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: Batasi deployment dengan pemeriksaan otomatis, seperti pengujian deterministik, skor LLM sebagai hakim, atau pembatasan, dan blokir penggabungan jika 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: Melacak 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?