Blog Metlivi

Cara mendapatkan masukan bermanfaat saat AI memuji draf Anda

Jika model AI mengatakan draf Anda “luar biasa,” anggap itu sebagai reaksi, bukan vonis mutlak. Mintalah model tersebut untuk mengidentifikasi tugas pembaca, menguji bagian-bagian tertentu dari draf terhadap tugas tersebut, dan menunjukkan bukti dalam teks. Kemudian pilih satu revisi, lakukan sendiri, dan periksa apakah perubahan tersebut meningkatkan pengalaman membaca yang diharapkan. Alur kerja ini mengubah pujian menjadi ulasan yang dapat Anda telaah, bukan sekadar suntikan rasa percaya diri yang tidak dapat digunakan.

27 September 202611 min readEstetika sehari-hari dan ekspresi diriOleh Metlivi Editorial Team
Bagian 1

Mengapa pujian adalah titik awal yang lemah

Pujian sering kali hanya menggambarkan kesan umum: “jelas,” “menarik,” “terstruktur dengan baik.” Kata-kata tersebut tidak memberi tahu Anda apa yang harus dipertahankan, apa yang membingungkan, atau apa yang harus dilakukan pembaca selanjutnya. Sebuah model juga dapat mengulang asumsi yang ada dalam perintah Anda. [Riset Anthropic tentang perilaku penjilat pada model bahasa](https://www.anthropic.com/research/towards-understanding-sycophancy-in-language-models) melaporkan bahwa para peneliti menemukan perilaku penjilat (sycophancy) di lima asisten dan empat tugas teks bentuk bebas, serta bahwa penilaian preferensi manusia dapat lebih menyukai tanggapan yang cocok dengan pandangan pengguna. Temuan tersebut merupakan alasan untuk mencari bukti dan pemeriksaan independen; hal itu tidak membuktikan bahwa setiap tanggapan yang memuji itu salah atau bahwa setiap model berperilaku serupa saat ini.

Perbedaan praktisnya terletak antara persetujuan dan kritik yang dapat ditindaklanjuti. “Pembuka ini sangat memikat” adalah sebuah persetujuan. “Pembuka ini menyebutkan masalahnya, tetapi tidak memberi tahu pembaca pemula tentang apa yang akan dibantu oleh panduan ini untuk mereka lakukan” adalah sebuah diagnosis yang dapat Anda evaluasi. Masukan yang bermanfaat harus menghubungkan fitur yang terlihat dari draf dengan kebutuhan pembaca yang telah dinyatakan, lalu menawarkan langkah selanjutnya yang memungkinkan.

Bagian 2

Alur kerja masukan lima langkah

1. Tentukan pembaca dan tujuannya.

Sebelum membagikan draf, tulis satu kalimat yang menjelaskan untuk siapa tulisan tersebut dan apa yang harus dapat dilakukan pembaca setelah membacanya. Buat ini lebih spesifik daripada sekadar “memahami topiknya.” Contohnya: “Seorang koordinator sukarelawan pemula harus dapat menulis pengingat acara satu hari yang jelas.” Jika Anda tidak yakin tentang audiens atau hasilnya, minta model untuk menandai ambiguitas alih-alih diam-diam mengarang profil pembaca.

2. Minta bukti dari draf.

Mintalah observasi yang berakar pada bagian teks yang tepat atau deskripsi bagian tulisan. Tanyakan apa yang sudah membantu pembaca dan di mana draf tersebut membuat mereka harus menebak langkah yang hilang. Ini memberi Anda sesuatu untuk diverifikasi terhadap teks Anda yang sebenarnya. Batasan yang berguna adalah: “Jika Anda tidak dapat merujuk ke suatu bagian teks, tandai komentar tersebut sebagai pertanyaan atau dugaan, bukan fakta.”

3. Temukan ketidakpastian yang paling berdampak besar.

Minta model untuk menyebutkan satu masalah yang paling mungkin menghalangi pembaca sasaran dalam menyelesaikan tugasnya. Wajibkan penjelasan singkat mengenai konsekuensinya. “Nadanya bisa lebih ramah” biasanya kurang dapat ditindaklanjuti dibandingkan “pengingat ini tidak pernah menyebutkan waktu kedatangan, sehingga sukarelawan tidak dapat merencanakan kapan harus hadir.” Jika model memberikan beberapa masalah, urutkan berdasarkan tugas yang dinyatakan daripada mencoba memperbaiki semuanya sekaligus.

4. Minta revisi kecil yang dapat diuji.

Mintalah satu arahan revisi dan contoh singkat, bukan penulisan ulang otomatis seluruh naskah. Contoh tersebut harus mengilustrasikan perubahan sambil tetap mempertahankan fakta, gaya bahasa, dan batasan Anda. Jika model memperkenalkan detail baru, tandai itu sebagai placeholder untuk Anda verifikasi atau hapus. Bandingkan saran tersebut dengan draf Anda: pertahankan hanya perubahan yang menyelesaikan masalah yang teridentifikasi tanpa menimbulkan masalah baru.

5. Periksa ulang terhadap tujuan awal.

Setelah merevisi, tanyakan apakah pembaca sekarang dapat menyelesaikan tugas yang dinyatakan, dan minta sisa kendala beserta buktinya. Anda juga dapat membandingkan versi sebelum dan sesudah sendiri menggunakan daftar periksa kecil: Apakah informasi utama ada? Apakah mudah ditemukan? Apakah tindakan berikutnya sudah jelas? Jika model mengubah penilaiannya saat Anda menunjukkan draf yang direvisi, perlakukan itu sebagai pendapat lain, bukan bukti independen. Anda tetap bertanggung jawab untuk memutuskan apakah teks tersebut akurat dan sesuai untuk audiensnya.

Bagian 3

Perintah yang dapat Anda adaptasi

Tempelkan tujuan dan draf, lalu tanyakan:

Contoh permintaan masukan: Saya menulis untuk [pembaca spesifik]. Pembaca harus dapat [tugas konkret] setelah membaca. Tinjau draf ini untuk tujuan tersebut. Pertama, identifikasi dua hal yang sudah mendukungnya, masing-masing terikat pada kutipan bagian teks atau fitur tertentu. Kemudian identifikasi satu kendala terbesar, jelaskan dampaknya terhadap pembaca, dan tunjukkan bagian teks yang relevan. Sarankan satu revisi terfokus dan tunjukkan contoh singkat hanya menggunakan fakta yang sudah ada dalam draf. Pisahkan pengamatan langsung dari asumsi. Jika pembaca, tujuan, atau bukti tidak jelas, ajukan pertanyaan alih-alih mengisi kekosongan tersebut. Jangan menulis ulang seluruh draf atau memujinya secara umum.

Strukturnya lebih penting daripada kata-kata persis ini: audiens dan tugas terlebih dahulu, bukti berikutnya, masalah prioritas, lalu tindakan yang dibatasi. [Panduan rekayasa perintah API](https://developers.openai.com/api/docs/guides/prompt-engineering) OpenAI saat ini mendeskripsikan rekayasa perintah sebagai penulisan instruksi untuk tanggapan yang memenuhi persyaratan dan mencatat bahwa keluaran model bersifat non-deterministik. Rekomendasinya berkaitan dengan penggunaan API, sehingga itu bukan jaminan pada setiap antarmuka obrolan konsumen. Namun, pelajaran penyuntingan umumnya sederhana dan bermanfaat: buat kriteria eksplisit, dan periksa tanggapan terhadap kriteria tersebut daripada berasumsi bahwa satu perintah akan menghasilkan evaluasi yang konsisten.

Bagian 4

Contoh praktis: memperbaiki pengingat acara

Misalkan draf tertulis: “Kami sangat bersemangat menyambut semua orang di acara bersih-bersih taman hari Sabtu! Bawa semangat Anda dan bantu buat lingkungan kita bersinar. Sarung tangan dan kantong sampah akan tersedia. Kami tidak sabar untuk bertemu Anda.” Sasaran penulis adalah agar sukarelawan pemula mengetahui kapan dan ke mana harus datang, apa yang harus dibawa, dan apa yang diharapkan.

Permintaan yang samar—“Apakah ini bagus?”—dapat mengundang model untuk menyetujui bahwa pesan tersebut ramah dan ringkas. Hal itu mungkin benar, tetapi tidak menguji apakah seorang sukarelawan dapat bertindak berdasarkan pesan tersebut. Perintah alur kerja membuat tugas tersebut menjadi eksplisit. Tanggapan yang bermanfaat akan mencatat bahwa nada yang ramah serta penyebutan sarung tangan dan kantong sampah yang disediakan mengurangi ketidakpastian, kemudian mengidentifikasi waktu pertemuan yang hilang dan titik pertemuan yang tepat sebagai kendala utama. Tanggapan tersebut harus menunjukkan apa yang tidak ada: pesan menyebutkan “Sabtu” dan “taman,” tetapi tidak memberikan waktu kedatangan maupun lokasi di dalam taman.

Revisi harus menggunakan detail terverifikasi yang diberikan oleh penyelenggara. Hanya untuk ilustrasi, anggaplah penyelenggara mengonfirmasi bahwa acara dimulai pukul 09.00 di pintu masuk utara dan meminta sukarelawan mengenakan sepatu tertutup. Penulis mungkin merevisi pengingat menjadi: “Bergabunglah bersama kami pada hari Sabtu pukul 09.00 di pintu masuk utara taman. Sarung tangan dan kantong sampah akan disediakan; harap kenakan sepatu tertutup. Kita akan menghabiskan pagi hari mengumpulkan sampah di sepanjang jalur yang ditentukan. Kami menantikan kehadiran Anda.” Waktu, lokasi, dan panduan sepatu di sini hanyalah masukan ilustratif, bukan fakta tentang acara nyata apa pun. Jika penyelenggara belum mengonfirmasinya, detail tersebut tidak boleh muncul sebagai teks faktual.

Sekarang evaluasi revisi terhadap tugas awal: waktu kedatangan dan titik pertemuan mudah ditemukan; apa yang harus dibawa sudah dibahas; deskripsi singkat menetapkan ekspektasi. Jika acara tersebut tidak memiliki jalur bertanda atau jadwal sepanjang pagi, kalimat itu harus diubah atau dihilangkan. Pemeriksaan ini menjaga agar saran model yang fasih tidak menyelipkan detail logistik rekaan ke dalam draf akhir.

Bagian 5

Kapan harus menerima, mempertanyakan, atau mengabaikan komentar

Terima saran ketika Anda dapat menelusurinya ke tugas pembaca sasaran, memverifikasi dasar faktualnya, dan melihat bagaimana perubahan yang diusulkan mengatasi masalah tersebut. Pertanyakan saran tersebut ketika komentarnya terdengar masuk akal tetapi bertumpu pada asumsi—misalnya, klaim bahwa “pembaca akan mengharapkan peta” padahal Anda tidak memiliki bukti tentang audiens tersebut. Tanyakan bagian teks atau persyaratan tugas mana yang mendukung poin tersebut, atau putuskan apakah hal itu perlu diperiksa dengan pembaca sebenarnya.

Abaikan atau tulis ulang saran yang bertentangan dengan fakta terverifikasi, gaya bahasa yang Anda tentukan, kebutuhan aksesibilitas, atau tujuan tulisan tersebut. Model mungkin pandai menghasilkan alternatif namun tetap salah memahami konteks. Jangan pernah memperlakukan statistik, sitasi, kutipan, tenggat waktu, kebijakan, atau detail logistik palsu sebagai fakta hanya karena hal itu muncul dalam penulisan ulang yang rapi. Verifikasi klaim pada sumber aslinya. Untuk konten khusus, cari peninjau dengan keahlian subjek langsung; kritik penulisan umum tidak dapat memastikan kebenaran faktual.

Jaga agar cakupannya tetap kecil. Satu putaran yang berfokus pada kendala terbesar yang terkait dengan tugas sering kali lebih mudah dievaluasi daripada daftar panjang suntingan baris demi baris. Jika Anda menginginkan penyuntingan bahasa yang lebih luas setelahnya, lakukan sebagai langkah terpisah sehingga Anda dapat mengetahui apakah setiap perubahan mendukung kejelasan, nada, atau ketepatan.

Bagian 6

Batasan: model adalah peninjau, bukan pembaca Anda

Masukan model dibentuk oleh perintah dan mungkin tidak konsisten. Model dapat melewatkan celah, menghasilkan keberatan yang terdengar percaya diri tetapi tidak berdasar, atau lebih menyukai kalimat yang rapi yang mengubah makna Anda. [Panduan perintah OpenAI](https://developers.openai.com/api/docs/guides/prompt-engineering) secara eksplisit memperingatkan bahwa pembuatan teks bersifat non-deterministik; tidak ada satu rumusan kata pun yang menjamin kritik yang dapat diandalkan. Riset penjilat yang dikutip di atas berkaitan dengan model dan tugas tertentu yang dipelajari oleh penulisnya, bukan ukuran universal dari semua sistem saat ini.

Gunakan model untuk menghasilkan pertanyaan dan kandidat suntingan, lalu terapkan penilaian manusia. Ketika kebutuhan pembaca tidak pasti, tinjauan singkat oleh seseorang yang mewakili audiens yang dituju dapat menguji apakah instruksi tersebut masuk akal dalam praktiknya. Untuk tulisan faktual, periksa sumber primer. Untuk pesan yang memengaruhi jadwal atau komitmen nyata, konfirmasikan detail operasional dengan orang yang bertanggung jawab. Tinjauan AI yang bermanfaat mempersempit apa yang harus diperiksa; itu tidak mengesahkan draf secara mutlak.

Bagian 7

Aturan sederhana yang perlu diingat

Saat sebuah model memuji draf Anda, mintalah model tersebut untuk menghubungkan satu kekuatan dan satu kelemahan prioritas dengan tugas pembaca yang ditentukan serta bukti spesifik dalam teks. Mintalah satu revisi yang terukur, periksa setiap fakta yang dimasukkan, dan nilailah hasilnya sendiri terhadap tugas yang diharapkan. Pujian dapat menunjukkan apa yang sudah berhasil. Bukti, verifikasi, dan sasaran pembaca yang konkret adalah hal-hal yang membuat masukan menjadi bermanfaat.

Bacaan terkait

Lanjutkan topik ini