Tim Anda memiliki perintah yang tersebar di seluruh basis kode. Beberapa ada di file konfigurasi. Beberapa adalah string yang dikodekan dengan keras. Beberapa dokumen penting ada di Google Dokumen yang dikelola oleh satu orang. Tidak ada yang ingat mengapa perintah sistem untuk fitur ringkasan mengatakan "respon sebagai pustakawan Inggris yang membantu" — tetapi menghapus frasa tersebut akan membuat hasilnya menjadi lebih buruk, sehingga tetap ada.
Ini adalah cara sebagian besar tim mengelola perintah, dan ini kira-kira setara dengan menulis kode tanpa kontrol versi pada tahun 2005. Ini berfungsi sampai tidak berfungsi lagi, dan ketika berhenti berfungsi, Anda tidak tahu apa yang berubah atau bagaimana cara memperbaikinya.
Retrospektif rekayasa cepat membawa disiplin yang sama ke dalam interaksi LLM yang dibawa oleh retrospektif rekayasa ke dalam pengembangan perangkat lunak: tinjauan sistematis, pembelajaran bersama, dan peningkatan bertahap. Berikut cara melakukannya.
Masalah dengan Perintah Ad-Hoc
Sebagian besar tim mengembangkan perintah melalui siklus yang terlihat seperti ini: seseorang menulis perintah, mengujinya dengan beberapa contoh, mengirimkannya, dan melanjutkan. Ketika kualitas keluaran menurun atau mode kegagalan baru muncul, seseorang mengubah perintah berdasarkan kasus kegagalan tertentu, mungkin merusak tiga kasus lainnya dalam proses, dan siklus berulang.
Masalah dengan pendekatan ini bertambah:
Tidak ada riwayat. Saat Anda mengubah perintah, versi lama akan hilang. Jika versi baru lebih buruk, Anda tidak dapat mengembalikannya dengan mudah. Jika ada yang bertanya "mengapa promptnya mengatakan ini?", tidak ada yang tahu.
Tidak ada pembelajaran bersama. Orang yang mengetahui bahwa menambahkan "berpikir selangkah demi selangkah" pada perintah penalaran akan meningkatkan akurasi dengan selisih yang signifikan tidak sependapat dengan wawasan tersebut. Orang yang menulis perintah berikutnya mempelajari pelajaran yang sama dari awal.
Tidak ada pengujian sistematis. Perintah diuji berdasarkan contoh apa pun yang terlintas dalam pikiran, yang biasanya merupakan kasus mudah. Kasus-kasus edge, input yang berlawanan, dan pergeseran distribusi tidak diuji hingga gagal dalam produksi.
Tidak ada pengukuran. "Output terlihat lebih baik" adalah metode evaluasi yang paling umum. Lebih baik bagaimana? Dibandingkan dengan apa? Diukur oleh siapa? Tanpa evaluasi yang konsisten, Anda tidak dapat mengetahui apakah perubahan benar-benar merupakan perbaikan.
Retrospektif cepat reguler mengatasi keempat masalah ini.
Apa yang Harus Ditinjau dalam Retrospektif Segera
Kumpulkan Bukti Anda
Sebelum retrospektif, kumpulkan:
Kegagalan produksi. Setiap contoh ketika fitur yang didukung LLM menghasilkan keluaran buruk yang diketahui pengguna. Tangkap masukan, perintah, dan keluaran. Jika Anda memiliki masukan dari pengguna (tidak disukai, keluhan, koreksi), sertakan masukan tersebut.
Perubahan yang cepat sejak masa lalu. Apa saja yang berubah, apa maksud dibalik perubahan tersebut, dan apa yang terjadi setelahnya? Jika Anda mengontrol versi permintaan Anda (seharusnya demikian), ini adalah tinjauan yang berbeda. Jika tidak, ini adalah item tindakan pertama dari retro Anda.
Tren metrik kualitas. Jika Anda menjalankan evaluasi otomatis (selengkapnya di bawah), bawalah tren tersebut. Apakah keadaan membaik? Menjadi lebih buruk? Datar?
Data biaya dan latensi. Perintah secara langsung memengaruhi keduanya. Perintah sistem yang panjang dan jelas yang meningkatkan kualitas dengan margin kecil namun melipatgandakan penggunaan token Anda adalah sebuah tradeoff yang patut didiskusikan secara eksplisit.
Percakapan
Retrospektif cepat yang baik mencakup tiga pertanyaan:
1. Di manakah perintah kami gagal, dan mengapa?
Klasifikasikan kegagalan Anda. Kategori umum:
- Instruksi berikut: Model tidak melakukan apa yang diminta. Biasanya berarti instruksinya ambigu atau bertentangan dengan bagian lain dari perintah.
- Pelanggaran format: Model mengembalikan JSON saat Anda menginginkan teks biasa, atau sebaliknya. Biasanya dapat diperbaiki dengan spesifikasi dan contoh format yang lebih jelas.
- Halusinasi: Model menghasilkan informasi yang tidak didukung oleh konteks yang diberikan. Ini mungkin masalah yang cepat (instruksi grounding yang lemah) atau keterbatasan model.
- Penyimpangan nada/gaya: Outputnya terdengar berbeda dari yang diharapkan. Sering terjadi jika perintahnya panjang dan instruksi gayanya terkubur.
- Kegagalan kasus tepi: Perintah berfungsi untuk masukan biasa namun rusak pada masukan yang tidak biasa. Di sinilah yang paling dirugikan oleh kurangnya pengujian sistematis.
Untuk setiap kategori kegagalan, tanyakan: apakah ini masalah prompt, masalah model, atau masalah masukan? Perbaikannya berbeda-beda untuk masing-masing.
2. Apa yang telah kita pelajari tentang mendorong model ini?
Setiap model mempunyai kekhasan. GPT-4 merespons perintah yang sama secara berbeda dibandingkan Claude, dan keduanya mengubah perilaku seiring dengan pembaruan. Tim Anda mengumpulkan pengetahuan tentang kebiasaan ini melalui pekerjaan sehari-hari — retrospektif adalah tempat pengetahuan tersebut dibagikan dan didokumentasikan.
Hal-hal berguna untuk diabadikan:
- Teknik yang dapat meningkatkan hasil secara andal (dan untuk jenis tugas apa)
- Pendekatan yang tampaknya berhasil, namun ternyata tidak
- Perilaku model berubah setelah pembaruan penyedia
- Mendorong pola yang sesuai untuk kasus penggunaan spesifik Anda
Hal ini menciptakan basis pengetahuan tim yang mencegah semua orang menemukan kembali pelajaran yang sama.
3. Apa yang harus kami ubah atau uji selanjutnya?
Berdasarkan kegagalan dan pembelajaran, identifikasi eksperimen tertentu. Eksperimen yang baik adalah:
- Sempit cakupannya (ubah satu per satu)
- Terukur (definisikan arti "lebih baik" sebelum Anda mengujinya)
- Dibatasi waktu (dijalankan untuk jangka waktu atau jumlah evaluasi tertentu)
Contoh: "Kami akan menguji apakah menambahkan dua contoh format keluaran yang diinginkan ke perintah layanan pelanggan akan mengurangi pelanggaran format dari 12% menjadi di bawah 5%, yang diukur pada 200 kueri produksi."
Membangun Praktik Manajemen yang Cepat
Retrospektif lebih efektif bila Anda memiliki manajemen dasar yang cepat. Anda tidak memerlukan alat canggih untuk memulai — cukup beberapa latihan.
Kontrol Versi Perintah Anda
Perlakukan perintah seperti kode. Simpan di repositori Anda, tinjau perubahan dalam PR, dan tandai versi. Ini memberi Anda riwayat, kemampuan rollback, dan pengawasan ulasan. Jika perubahan yang cepat menurunkan kualitas, Anda dapat melihat secara pasti apa yang berubah dan mengembalikannya.
Untuk tim dengan banyak perintah, pertimbangkan struktur direktori khusus:
perintah/
ringkasan/
sistem.txt
beberapa-shot-examples.json
layanan pelanggan/
sistem.txt
eskalasi-aturan.txt
klasifikasi/
sistem.txt
label-definisi.json
Membangun Kumpulan Evaluasi
Untuk setiap perintah utama, pertahankan serangkaian kasus pengujian: pasangan input-output di mana Anda mengetahui seperti apa output yang bagus. Jumlahnya tidak perlu terlalu besar — 20-50 kasus per perintah yang mencakup penggunaan umum, kasus ekstrem, dan mode kegagalan yang diketahui.
Jalankan set evaluasi Anda setiap kali Anda mengubah perintah. Ini menangkap regresi sebelum mencapai produksi. Proses build-up pada awalnya memerlukan waktu, namun menghemat waktu jauh lebih banyak dibandingkan proses debug kegagalan produksi.
Dokumentasikan Keputusan Anda
Saat Anda segera melakukan perubahan, tulis catatan singkat: apa masalahnya, apa yang Anda ubah, dan mengapa Anda mengharapkan perubahan tersebut membantu. Hal ini tampak seperti overhead hingga tiga bulan kemudian ketika Anda melihat perintah dan bertanya-tanya mengapa perintah tersebut menyertakan instruksi yang tampaknya acak namun ternyata sangat penting.
Format Retrospektif Cepat yang Berfungsi
Tidak semua retro harus sama. Berikut dua format yang berfungsi dengan baik pada irama berbeda:
Tinjauan Singkat (30 menit, dua mingguan)
Untuk tim yang melakukan iterasi dengan cepat. Tinjau kegagalan produksi sejak sesi terakhir, diskusikan setiap perubahan cepat yang dilakukan, bagikan masing-masing satu wawasan, dan pilih eksperimen dengan prioritas tertinggi untuk dua minggu ke depan. Jaga agar tetap ketat dan berorientasi pada tindakan.
The Deep Dive (90 menit, bulanan)
Saat Anda perlu melangkah mundur dan melihat gambaran yang lebih besar. Tinjau metrik dan tren kualitas di semua permintaan. Pilih perintah dengan kinerja terburuk dan lakukan analisis menyeluruh: telusuri kegagalan, diskusikan akar permasalahan, lakukan brainstorming pendekatan, dan rancang eksperimen yang tepat. Tinjau juga perpustakaan dan dokumentasi prompt Anda untuk melihat apakah ada yang basi — apakah ada prompt yang sudah ketinggalan zaman atau tidak digunakan?
Tinjauan Insiden (ad-hoc)
Jika kegagalan mendadak menyebabkan insiden nyata yang dihadapi pengguna, lakukan peninjauan terfokus dalam beberapa hari. Apa yang terjadi, mengapa perintah tersebut gagal, mengapa pengujian kami tidak menangkapnya, dan apa yang kami tambahkan ke kumpulan evaluasi kami untuk mencegah kelompok kegagalan ini?
Kesalahan Umum
Permintaan rekayasa berlebihan. Perintah yang lebih panjang tidak selalu lebih baik. Setiap instruksi yang Anda tambahkan dapat berinteraksi dengan setiap instruksi lainnya dengan cara yang tidak terduga. Jika perintah Anda lebih dari 500 kata, pertimbangkan apakah Anda mencoba melakukan terlalu banyak hal dalam satu perintah dan harus membaginya menjadi beberapa rangkaian.
Mengoptimalkan metrik yang salah. Perintah yang mendapat skor bagus pada metrik otomatis namun menghasilkan keluaran yang menurut pengguna tidak membantu bukanlah perintah yang baik. Sertakan evaluasi manusia dalam proses Anda, bukan hanya penilaian otomatis.
Mengabaikan biaya. Peningkatan cepat yang menggandakan penggunaan token Anda mungkin tidak sebanding dengan peningkatan kualitas. Lacak biaya per kueri serta kualitas dan lakukan pengorbanan secara eksplisit.
Memperbaiki gejala, bukan penyebabnya. Jika Anda terus melakukan patch pada perintah yang sama untuk mode kegagalan yang baru, perintah tersebut mungkin memerlukan desain ulang dan bukan solusi lain. Data retrospektif Anda akan menunjukkan pola ini — perintah yang muncul dalam daftar kegagalan di beberapa retro memerlukan perhatian yang lebih mendasar.
Tidak menguji dengan masukan yang berlawanan. Pengguna Anda akan melakukan hal-hal yang tidak Anda harapkan. Retrospektif Anda harus secara berkala mencakup tinjauan tentang apa yang terjadi ketika perintah menerima masukan yang tidak biasa, tidak bersahabat, atau di luar cakupan. Jangan menunggu insiden produksi untuk mengetahui bahwa perintah Anda tidak memiliki batasan.
Memulai
Anda tidak perlu memikirkan segalanya untuk memulai. Berikut langkah minimal pertama:
- Pilih fitur terpenting yang didukung LLM.
- Kumpulkan 10 kegagalan terkini (keluaran buruk, keluhan pengguna, apa pun yang kurang optimal).
- Luangkan 30 menit bersama tim Anda untuk mengklasifikasikan alasan masing-masing tim gagal.
- Identifikasi pola kegagalan yang paling umum dan rancang satu eksperimen untuk mengatasinya.
- Jalankan eksperimen dan tinjau hasilnya dalam dua minggu.
Itu adalah retrospektif cepat pertama Anda. Lakukan lagi, dan lagi, dan Anda akan membentuk otot. Tim dengan kualitas keluaran AI terbaik bukanlah tim yang memiliki perintah paling cerdas — mereka adalah tim yang secara sistematis belajar dari kegagalan mereka dan tidak pernah melakukan kesalahan yang sama dua kali.
Coba NextRetro gratis — Klasifikasikan kegagalan yang terjadi ke dalam beberapa kategori, pilih prioritas, dan lacak eksperimen peningkatan di seluruh sprint.
Terakhir Diperbarui: Februari 2026
Waktu Membaca: 7 menit
