Haruskah Memori AI Companion Bisa Diedit? Alur Koreksi Praktis untuk Detail Proyek
Ya. Memori AI companion seharusnya memungkinkan pengguna memeriksa, mengoreksi, mengonfirmasi, dan menghapus detail biasa yang diingat—lalu menampilkan bagaimana perubahan tersebut memengaruhi balasan di kemudian hari. Tugas desain yang berguna adalah mengoreksi memori proyek yang keliru, seperti asisten yang mengingat bahwa sebuah seri foto direncanakan untuk galeri padahal pengguna hanya mengatakan bahwa mereka mungkin akan mengajukannya. Tujuannya adalah alur koreksi yang terlihat dan berhambatan rendah (low-friction), bukan janji bahwa setiap detail yang diingat akan selalu sempurna.
Mengapa memori proyek biasa memerlukan kontrol koreksi
Memori dapat membuat percakapan yang sedang berlangsung menjadi lebih berguna dengan meneruskan preferensi atau konteks proyek, sehingga pengguna tidak perlu mengulanginya. Dokumentasi produk saat ini menggambarkan memori sebagai sumber personalisasi, sembari juga mengakui bahwa memori mungkin tidak menyimpan setiap detail atau bisa saja keliru menangkap detail. Panduan memori OpenAI menjelaskan bahwa informasi yang diingat dapat berasal dari berbagai sumber dan kontrol yang tersedia bervariasi. Panduan memori Gemini dari Google juga menyatakan bahwa memori dapat menginformasikan saran proyek dan mengarahkan pengguna untuk mengoreksi Gemini di dalam obrolan.
Kesalahan kecil dapat menjadi gangguan yang berulang ketika suatu sistem memperlakukan kemungkinan di masa lalu sebagai rencana yang sudah pasti. Bayangkan seseorang sedang mendiskusikan proyek pertukangan kayu di akhir pekan: mereka sempat mempertimbangkan kayu cedar, lalu memilih kayu birch. Jika pendamping tersebut kemudian menyarankan finishing kayu cedar seolah-olah pilihan itu sudah final, masalahnya bukanlah karena sistem mengingat percakapan tersebut. Masalahnya adalah pengguna membutuhkan cara untuk memeriksa klaim yang diingat, merevisinya, dan melihat apakah revisi tersebut digunakan.
Ini adalah rekomendasi desain, bukan klaim bahwa setiap produk percakapan telah menyediakan kontrol yang sama. Panduan interaksi manusia-AI dari Microsoft menyebutkan koreksi yang efisien, penjelasan tentang perilaku sistem, dan penyampaian konsekuensi dari tindakan pengguna sebagai pertimbangan desain yang terpisah. Jika diterapkan pada memori, prinsip-prinsip tersebut menyarankan bahwa koreksi harus dibuat sederhana dan efek praktisnya mudah diverifikasi. Panduan interaksi manusia-AI dari Microsoft Research
Apa yang seharusnya dapat diperiksa oleh pengguna
Tampilan memori yang berguna harus menyajikan masing-masing klaim dalam bahasa sehari-hari: “Untuk pengatur meja, Anda memilih kayu birch,” atau “Anda sedang mempertimbangkan seri foto tentang plang nama di lingkungan sekitar.” Tampilan tersebut harus menghindari pengubahan bahasa yang masih tentatif menjadi sebuah kepastian. Jika percakapan yang mendasarinya dapat ditampilkan, tautan sumber atau pratinjau konteks singkat dapat membantu pengguna mengetahui apakah ringkasan tersebut akurat. Tampilan memori juga harus memperjelas bahwa itu mungkin merupakan ringkasan selektif dan bukan catatan lengkap; dokumentasi OpenAI secara gamblang menggambarkan ringkasan memorinya sebagai ringkasan tingkat tinggi dan menyatakan bahwa itu mungkin tidak menampilkan setiap detail atau sumber.
Untuk setiap item, tunjukkan statusnya dengan cara yang dapat dipahami pengguna: disimpan dan tersedia untuk personalisasi di masa mendatang, menunggu konfirmasi, dikoreksi, atau dihapus dari penggunaan aktif. Label-label ini merupakan pola antarmuka yang diusulkan. Prinsip yang mendasarinya didukung oleh panduan Microsoft untuk menjelaskan alasan sistem bertindak dan mengomunikasikan bagaimana tindakan pengguna akan memengaruhi perilaku di masa mendatang. Hal tersebut tidak mengharuskan pengungkapan mekanisme model internal. Itu hanya membutuhkan informasi yang cukup bagi seseorang untuk menjawab: “Apa yang Anda ingat, dan apa yang akan berubah jika saya mengeditnya?”
Alur koreksi dalam lima langkah
Alur koreksi yang praktis dapat dimulai dari tempat kesalahan tersebut muncul. Jika asisten mengatakan, “Karena pengajuan galeri dijadwalkan bulan depan…,” pengguna seharusnya dapat membuka memori yang berkontribusi atau memilih tindakan koreksi di samping respons tersebut. Penjelasan memori harus mengidentifikasi klaim yang relevan tanpa mengindikasikan bahwa asisten memiliki akses sempurna ke setiap alasan di balik keluarannya. Kontrol memori OpenAI saat ini dapat memunculkan sumber yang berkontribusi pada personalisasi, sembari mencatat bahwa sumber mungkin tidak menampilkan setiap faktor. Panduan OpenAI untuk sumber memori dan koreksi
Pengguna kemudian memilih tindakan terkecil yang berguna: mengedit klaim, menghapusnya, atau menandainya sebagai tidak pasti. Pengeditan mungkin mengubah “Mengajukan seri ke galeri” menjadi “Mempertimbangkan apakah akan mengajukan seri tersebut.” Penghapusan tepat dilakukan jika detail tersebut sama sekali tidak diinginkan lagi. Ketidakpastian dapat mempertahankan konteks yang berguna tanpa mengubah pemikiran yang masih tentatif menjadi komitmen yang pasti. Opsi ketidakpastian tersebut merupakan saran desain; ini tidak boleh disajikan sebagai fitur dari produk bernama tertentu kecuali telah diverifikasi di sana.
Sebelum menyimpan, tampilkan kata-kata revisi yang tepat dan mintalah konfirmasi ketika pengeditan tersebut mengubah makna atau dapat mengubah saran di masa mendatang secara substansial. Perbaikan salah ketik kecil mungkin tidak memerlukan langkah konfirmasi terpisah; tetapi mengganti rencana pasti dengan kemungkinan terbuka mungkin membutuhkannya. Perbedaan ini merupakan inferensi dari panduan koreksi dan disambiguasi: Microsoft merekomendasikan untuk mempermudah koreksi dan melibatkan pengguna saat sistem merasa ragu tentang tujuan mereka. Konfirmasi harus melindungi maksud pengguna, bukan menambah hambatan pada setiap pengeditan rutin.
Setelah konfirmasi, tampilkan hasil yang lugas seperti: “Diperbarui. Saya akan memperlakukan pengajuan galeri sebagai hal yang belum diputuskan dalam percakapan proyek di masa mendatang.” Jika pengguna menghapus item tersebut, sampaikan bahwa item tersebut telah dihapus dari memori aktif, dan perjelas cakupan sebenarnya dari produk tersebut. Jangan mengatakan bahwa semua jejak telah hilang kecuali hal itu benar-benar terbukti. Sistem yang ada menggambarkan mengapa presisi itu penting: OpenAI menjelaskan bahwa memori yang disimpan dan obrolan aslinya dapat disimpan secara terpisah, sementara panduan Gemini mengatakan bahwa mengoreksi detail yang diingat dapat dilakukan di obrolan dan menghapus obrolan yang relevan mungkin membutuhkan waktu singkat untuk memengaruhi personalisasi. Perilaku spesifik produk tersebut tidak boleh digeneralisasikan menjadi janji penghapusan universal. Panduan memori OpenAI dan panduan memori Gemini
Terakhir, biarkan pengguna menguji perubahan tersebut dalam tindak lanjut yang alami. Mereka mungkin meminta ide finishing untuk pengatur meja tersebut. Jika asisten menggunakan kayu birch, pengguna memiliki sinyal nyata bahwa koreksi tersebut memengaruhi penggunaan kembali informasi tersebut. Jika asisten kembali mengulang kayu cedar, berikan rute kembali ke item memori atau cara untuk menandai ketidaksesuaian tersebut. Pilihan desain yang penting adalah membuat penggunaan kembali informasi dapat diamati, sembari menghindari jaminan bahwa satu respons yang berhasil berarti sistem tidak akan pernah membuat kesalahan yang sama lagi.
Kapan harus mengedit, menghapus, atau mengonfirmasi
Gunakan edit ketika ide yang diingat masih berguna tetapi kata-kata atau detailnya salah: “Lebar rak 80 cm,” dikoreksi menjadi “Lebar rak 90 cm.” Gunakan hapus jika item tersebut tidak boleh lagi memandu balasan di masa mendatang—misalnya, preferensi proyek yang ditinggalkan. Gunakan konfirmasi ketika memori yang diusulkan bermakna ambigu atau suatu perubahan dapat mengubah komentar eksploratif menjadi sebuah keputusan. Antarmuka yang jelas harus membedakan tindakan-tindakan ini alih-alih memperlakukan “jangan katakan itu” sama dengan “hapus memori.” Dokumentasi OpenAI membuat pembedaan serupa: meminta sistem untuk tidak menyebutkan sesuatu akan mengubah perilaku personalisasi tetapi tidak dengan sendirinya menghapus sumber yang mendasarinya.
Antarmuka juga dapat menawarkan opsi “tidak yakin” atau “tanyakan pada saya lain kali” untuk detail yang nilainya bergantung pada momen tertentu. Sebagai contoh, seseorang mungkin biasanya lebih menyukai takarir (caption) pendek tetapi menginginkan deskripsi yang lebih panjang untuk halaman portofolio tertentu. Ini adalah cara yang diusulkan untuk menjaga fleksibilitas, bukan klaim fitur yang terverifikasi. Pertanyaan panduannya adalah apakah memori tersebut menyatakan preferensi yang stabil, pilihan sementara, atau kemungkinan yang harus tetap terbuka.
Desain untuk interaksi yang tenang dan mudah digunakan
Letakkan kontrol koreksi dekat dengan memori atau respons yang dipengaruhinya. Gunakan kata-kata yang sudah familier seperti “Edit,” “Hapus,” dan “Konfirmasi,” serta hindari mengharuskan orang menyusun perintah khusus (prompt) hanya untuk memperbaiki kesalahan faktual yang rutin. Panduan Microsoft secara eksplisit menuntut koreksi yang efisien dan umpan balik yang terperinci. Panduan desain AI generatif Apple saat ini juga menyarankan untuk mempermudah penyempurnaan atau pembatalan serta memberi sinyal ketika penyesuaian pengguna telah berlaku. Human Interface Guidelines dari Apple untuk AI generatif
Untuk pengeditan yang berdampak besar, sediakan tampilan sebelum-dan-sesudah yang ringkas. Jangan menggabungkan versi yang bertentangan secara diam-diam atau mengganti koreksi pengguna dengan preferensi hasil inferensi sistem. Jika pengguna mengatakan, “Saya memilih kayu birch untuk pengatur meja ini, tetapi saya masih menyukai kayu cedar untuk proyek luar ruangan,” pertahankan cakupan kedua klaim tersebut alih-alih menyeragamkannya menjadi preferensi kayu secara umum. Ini adalah inferensi desain: Microsoft merekomendasikan untuk membatasi cakupan layanan saat merasa ragu, dan panduannya tentang pembaruan yang berhati-hati mendukung pencegahan perubahan yang mengganggu seiring berjalannya waktu.
Riwayat perubahan yang ringan dapat membantu orang memulihkan diri dari kesalahan edit yang tidak disengaja, terutama untuk fakta proyek yang mungkin ingin mereka pulihkan. Namun riwayat harus dapat dipahami dan berada di bawah kendali pengguna. Jika antarmuka menawarkan opsi batalkan (undo), sebutkan apa yang dipulihkan dan apakah klaim yang dipulihkan tersebut menjadi aktif kembali. Panduan Apple secara khusus merujuk pada fitur urungkan (undo) dan umpan balik yang jelas sebagai pola yang berguna untuk menyempurnakan hasil generatif; menerapkan pola tersebut pada pengeditan memori merupakan perluasan yang wajar, bukan pernyataan bahwa pedoman tersebut mewajibkan fitur riwayat memori tertentu.
Cara mengetahui apakah alur tersebut berfungsi
Evaluasi alur tersebut dengan skenario proyek biasa dan tugas-tugas yang dapat diamati. Dapatkah seseorang menemukan detail yang keliru setelah detail itu muncul dalam balasan? Dapatkah mereka mengubah “sudah memutuskan” menjadi “mempertimbangkan,” mengonfirmasi kata-kata yang diperbarui, dan mengetahui apa yang akan digunakan sistem selanjutnya? Dapatkah mereka menghapus pilihan yang sudah usang tanpa membingungkan tindakan tersebut dengan meminta asisten untuk tidak menyebutkannya sekali saja? Ini adalah pertanyaan uji untuk desain yang diusulkan, bukan hasil pengujian yang dilaporkan.
Tinjauan yang berguna dapat melacak apakah orang menyelesaikan tugas-tugas ini, apakah mereka memahami perbedaan antara mengedit dan menghapus, dan apakah detail yang dikoreksi tercermin dalam respons relevan berikutnya. Tinjauan tersebut juga harus memeriksa jalur kegagalan: detail tidak dapat ditemukan, dua memori saling bertentangan, koreksi belum tercermin, atau pengguna membatalkan sebelum menyimpan. Dalam kasus tersebut, antarmuka harus mengakui status tersebut dan menawarkan langkah selanjutnya yang jelas alih-alih mengatakan “sudah diperbaiki” ketika antarmuka tidak dapat memverifikasi perubahan tersebut. Hal ini sejalan dengan panduan untuk membuat koreksi menjadi efisien dan mengomunikasikan konsekuensi tindakan; tolok ukur itu sendiri merupakan rekomendasi.
Buat memori dapat dikoreksi, lalu buat koreksinya terlihat
Memori AI companion harus dapat diedit karena detail proyek biasa dapat berubah, dan ringkasan yang diingat bisa jadi tidak lengkap atau keliru. Alur koreksi yang kuat memungkinkan seseorang memeriksa klaim tertentu, mengedit atau menghapusnya, mengonfirmasi makna jika diperlukan, dan melihat bagaimana perubahan tersebut diharapkan memengaruhi personalisasi di masa mendatang. Pengalaman tersebut menumbuhkan rasa percaya melalui umpan balik yang terlihat dan akurat tentang setiap tindakan—bukan dengan mengisyaratkan bahwa memori itu sempurna atau bahwa satu koreksi menjamin setiap respons setelahnya akan selalu benar.