Mengapa Chatbot Karakter Fiksi Melupakan Pengaturannya Setelah Percakapan Panjang? Panduan Lima Langkah Pemeriksaan

Pertama, pisahkan gejala dari kemungkinan penyebabnya

Pilihlah satu detail yang semestinya tetap konsisten dan mudah diperiksa. Sebagai contoh: “Mira, seorang penjaga mercusuar fiksi, menyimpan sebuah kompas kuningan di laci meja berwarna hijau.” Gunakan fakta yang persis sama tersebut di sepanjang pengujian, dan ajukan pertanyaan spesifik seperti “Apa warna laci tersebut?” Hindari informasi pribadi atau detail penting di luar pengujian.

Catat prompt yang tepat, jawaban yang diberikan, perkiraan panjang percakapan, serta apakah Anda memulai obrolan baru. Jika Anda menguji chatbot milik orang lain, gunakan hanya pengaturan dan percakapan uji yang memang diizinkan untuk Anda akses. Jangan mengambil kesimpulan hanya dari satu jawaban: proses generasi teks dapat bervariasi, dan satu kegagalan saja tidak menunjukkan apakah fakta tersebut sebenarnya ada tetapi terlewatkan, atau memang tidak disertakan dalam informasi yang diberikan kepada model.

Penelitian yang ada menyarankan agar kita berhati-hati dalam menafsirkan kegagalan pada obrolan panjang. Liu dan rekan-rekan menemukan bahwa performa pada tugas-tugas temu balik informasi dapat bervariasi bergantung pada letak posisi detail relevan dalam input yang panjang, yang sering kali melemah ketika detail berada di bagian tengah. Eksperimen mereka berfokus pada penjawab pertanyaan dan pengambilan nilai kunci (key-value retrieval), bukan roleplay fiksi atau aplikasi tertentu. Sebuah studi tahun 2026 oleh Luz de Araujo dan rekan-rekan secara langsung meneliti kesetiaan persona dalam dialog yang diperpanjang dan melaporkan terjadinya penurunan performa seiring bertambahnya panjang dialog pada model-model yang dievaluasi. Tak satu pun dari makalah tersebut yang secara definitif mengidentifikasi penyebab kelalaian chatbot tertentu. ([Liu et al., “Lost in the Middle,” 2024](https://aclanthology.org/2024.tacl-1.9/); [De Araujo et al., “Persistent Personas?”, 2026](https://aclanthology.org/2026.eacl-long.246/))

1. Periksa batas jendela konteks (context window)

Dalam obrolan yang sedang berlangsung, tanyakan tentang kompas dan laci tersebut. Kemudian buka obrolan baru, berikan pengaturan karakter lagi di awal, lalu ajukan pertanyaan yang sama. Jika jawabannya benar pada obrolan baru tetapi salah di bagian akhir obrolan lama, keterbatasan konteks panjang masuk akal untuk dicurigai. Detail yang diberikan mungkin tidak lagi tersedia dalam format yang sama, atau model menjadi kurang mampu menggunakannya seiring bertambah panjangnya percakapan.

Pola ini tidak serta-merta menetapkan batasan pasti dari jendela konteks. Obrolan baru juga mengubah kondisi lain: langkah ini menempatkan fakta dekat dengan bagian awal dan menghapus instruksi-instruksi berikutnya yang mungkin saling bersaing. Jendela konteks adalah jumlah percakapan dan input lain yang dapat diproses sistem dalam satu waktu; hal ini tidak selalu sama dengan memori yang tersimpan lintas obrolan. Kecuali layanannya secara eksplisit mendokumentasikan batasannya, jangan menyimpulkan jumlah token hanya dari satu kali kegagalan.

2. Periksa kegagalan temu balik (retrieval)

Jika layanan tersebut menyediakan fitur pencarian, pemanggilan ulang (recall), atau riwayat percakapan yang terdokumentasi, ujilah apakah fitur itu dapat menemukan teks pengaturan awal yang tepat. Anda juga dapat meminta chatbot untuk mengambil fakta dari interaksi sebelumnya yang relevan, jika fitur tersebut memang didukung. Bandingkan hasilnya dengan tolok ukur obrolan baru.

Jika pengaturan masih ada dalam riwayat yang dapat diakses atau catatan memori tetapi chatbot tidak menggunakannya, kegagalan temu balik atau proses seleksi adalah salah satu kemungkinannya. Hal tersebut juga bisa berupa efek posisi konteks, jawaban yang lemah, atau perilaku fitur yang berbeda dari perkiraan. Tanpa melihat informasi apa saja yang diberikan ke model saat menyusun respons tersebut, Anda tidak dapat membedakannya secara pasti. Jangan berasumsi bahwa chatbot menelusuri setiap pesan sebelumnya hanya karena antarmuka menampilkan seluruh transkrip percakapan.

3. Periksa ringkasan yang usang atau kehilangan informasi (lossy)

Beberapa sistem mungkin memadatkan giliran-giliran interaksi sebelumnya menjadi ringkasan yang lebih singkat. Jika aplikasi memperlihatkan ringkasan tersebut, periksa apakah di dalamnya masih tertulis bahwa lacinya berwarna hijau dan kompasnya terbuat dari kuningan. Jika yang tertulis hanya bahwa Mira “menyimpan kompas di dekatnya”, ajukan pertanyaan spesifik tentang warna yang dihilangkan tersebut dan bandingkan jawabannya dengan versi yang pengaturannya Anda berikan secara eksplisit.

Ringkasan yang salah atau tidak lengkap memperkuat kemungkinan bahwa proses kompresi telah mengubah informasi yang dibawa ke respons berikutnya. Namun, ringkasan yang terlihat oleh Anda mungkin bukan ringkasan yang sebenarnya digunakan oleh sistem, dan ringkasan yang tidak terlihat tidak dapat diasumsikan keberadaannya. Jadikan pemeriksaan ini sebagai bukti hanya jika produk tersebut benar-benar menampilkan catatan atau dokumentasi yang relevan.

4. Periksa konflik instruksi persona

Pertahankan fakta tersebut tetap sama, lalu amati instruksi-instruksi berikutnya yang mungkin memengaruhi bagaimana pertanyaan itu dijawab. Sebuah adegan fiksi mungkin menyebutkan, “Mira hari ini sedang ragu-ragu dan menebak bahwa lacinya berwarna biru.” Instruksi tersebut bertentangan dengan pengaturan awal yang menyatakan lacinya berwarna hijau. Ajukan pertanyaan faktual yang netral, lalu ajukan pertanyaan yang dibingkai di dalam adegan tersebut. Jika chatbot menjawab secara berbeda, susunan kata atau prioritas instruksi mungkin memengaruhi respons yang dihasilkan.

Untuk pengujian yang lebih bersih, hapus atau ubah satu instruksi yang saling bertentangan sembari mempertahankan sisa pengaturan fiksi lainnya tanpa perubahan. Jika kepatuhan terhadap fakta awal kembali, konflik instruksi merupakan penjelasan yang lebih kuat daripada sekadar lupa. Chatbot juga bisa salah menafsirkan instruksi atau berimprovisasi; perubahan respons setelah pengeditan tidak lantas membeberkan aturan prioritas internal sistem. Penelitian mengenai dialog persona yang diperpanjang menunjukkan bahwa kesetiaan persona dan kepatuhan terhadap instruksi keduanya dapat dievaluasi dalam interaksi yang panjang, tetapi hal itu tidak dapat memberi tahu Anda aturan mana yang diprioritaskan oleh layanan tertentu. ([“Persistent Personas?”](https://aclanthology.org/2026.eacl-long.246/))

5. Periksa apakah memori persisten memang dirancang untuk menyimpannya

Detail dalam obrolan yang sedang berjalan, profil karakter yang tersimpan, dan memori lintas obrolan adalah hal yang berbeda. Periksa pengaturan atau dokumentasi produk itu sendiri untuk melihat apakah produk tersebut menawarkan fitur informasi karakter yang persisten, apakah penyimpanan harus diaktifkan atau dikonfirmasi terlebih dahulu, dan apakah item yang dipilih memang dimaksudkan untuk dibawa ke percakapan lain. Gunakan obrolan baru untuk menguji hal ini hanya jika layanan menyatakan bahwa fitur tersebut memang berlaku di sana.

Jika produk tidak memiliki cara terdokumentasi untuk menyimpan jenis detail karakter seperti ini, kegagalan mengingatnya di obrolan lain bukanlah bukti bahwa memori yang tersimpan telah terhapus. Jika produk memiliki fitur semacam itu, periksa entri tersimpan yang terlihat beserta cakupannya sebelum menarik kesimpulan. Catatan yang tersimpan mungkin memelihara fakta “laci hijau” tanpa mewajibkan setiap pesan sebelumnya tetap ada dalam percakapan aktif, tetapi jangan mengklaim bahwa aplikasi tertentu bekerja seperti ini tanpa bukti spesifik dari produk terkait.

Pahami polanya, jangan hanya melihat jawaban terakhir

Gunakan observasi sebagai petunjuk, dengan tetap menjaga agar setiap interpretasi tidak melampaui pola yang teramati:

Observasi: Obrolan baru dengan pengaturan yang disertakan berhasil; obrolan lama di tahap akhir gagal Kemungkinan pembacaan: Sensitivitas konteks panjang atau posisi Hal ini tidak membuktikan: Batas pasti jendela konteks

Observasi: Riwayat atau memori yang terdokumentasi memuat fakta tersebut, tetapi jawabannya luput Kemungkinan pembacaan: Kegagalan temu balik atau kegagalan penggunaan informasi Hal ini tidak membuktikan: Bahwa temu balik semata yang menyebabkan kegagalan tersebut

Observasi: Ringkasan yang ditampilkan menghilangkan atau mengubah detail Kemungkinan pembacaan: Kehilangan informasi atau perubahan akibat ringkasan Hal ini tidak membuktikan: Bahwa input aktual model memang menggunakan ringkasan tersebut

Observasi: Menghapus instruksi adegan yang bertentangan memulihkan kepatuhan karakter Kemungkinan pembacaan: Konflik instruksi atau interpretasi Hal ini tidak membuktikan: Hierarki instruksi internal aplikasi

Observasi: Suatu detail tidak ada dalam obrolan baru dan tidak ada dokumentasi penyimpanan lintas obrolan Kemungkinan pembacaan: Tidak ada jalur memori persisten yang terbukti Hal ini tidak membuktikan: Bahwa memori yang ada sebelumnya telah dihapus

Cara menafsirkan pola yang saling tumpang tindih

Jika beberapa pola muncul secara bersamaan, penyebabnya mungkin saling berkaitan. Misalnya, sebuah ringkasan bisa saja menghilangkan warna laci sementara instruksi berikutnya juga memperkenalkan laci berwarna biru. Buatlah setiap pengujian tetap berskala kecil, ubah satu kondisi saja dalam satu waktu, dan pertahankan kata-kata yang sama persis agar perbandingannya tetap bermakna.

Bedakan pemeriksaan ini dari gaya bicara dan perilaku koreksi

Perubahan gaya bicara karakter merupakan gejala yang berbeda dari melupakan fakta pengaturan awal yang spesifik. Konsistensi gaya bicara berkaitan dengan gaya, diksi, atau tata cara penyampaian; pemeriksaan di atas berkaitan dengan apakah detail fiksi yang konkret tersedia dan diikuti. Pembaruan model atau layanan dapat mengubah gaya bahasa, tetapi kecuali layanan tersebut mendokumentasikan perubahan atau menyediakan informasi model yang sebanding, pergeseran gaya bicara tidak membuktikan bahwa pembaruan telah terjadi.

Demikian pula, koreksi yang diterima dalam satu balasan tidak secara otomatis menjadi koreksi yang persisten. Ujilah terlebih dahulu di obrolan yang sama, lalu di obrolan baru hanya jika produk mengklaim bahwa koreksi memang seharusnya terbawa. Jika karakter mematuhi fakta “lacinya berwarna hijau” sekali tetapi kemudian kembali salah, hal tersebut menggambarkan persistensi koreksi; hal itu sendiri belum mengidentifikasi apakah penyebabnya adalah konteks, temu balik, ringkasan, konflik instruksi, atau rancangan memori.

Bagi seorang perancang, kelima kasus yang sama menyarankan kerangka evaluasi yang praktis: pertahankan fakta fiksi yang tidak berbahaya secara konstan, variasikan panjang percakapan serta posisi fakta tersebut, tampilkan atau catat hasil temu balik dan ringkasan jika relevan, masukkan instruksi pertentangan yang terkontrol, dan tentukan apakah fakta tersebut diharapkan bertahan lintas sesi. Catat rujukan kebenaran (source of truth) mana yang menjadi dasar setiap pengujian. Hal ini membuat kegagalan lebih mudah direproduksi dan membantu membedakan antara masalah konten dengan ekspektasi yang memang tidak pernah dijanjikan oleh produk.

Kesimpulan yang cermat harus menyebutkan bukti beserta batasannya: “Perbandingan dengan obrolan baru mengindikasikan adanya efek percakapan panjang, tetapi saya tidak dapat memastikan apakah detail tersebut terpotong, tidak terambil, atau ditimpa.” Hal ini jauh lebih berguna daripada sekadar melabeli setiap kekeliruan sebagai kegagalan memori—dan jauh lebih akurat ketika implementasi internal aplikasi tersebut tidak diketahui publik.

Lanjutkan topik ini