Context window sebagai UX

Namanya Dian. Dia seorang account manager level menengah di perusahaan B2B SaaS, dan sedang mencoba versi beta dari internal assistant yang kami bangun untuk membantu para rep menarik konteks deal sebelum panggilan. Dia sudah memakainya sekitar lima belas menit. Aku mengamati dari belakang bahunya — secara resmi untuk “riset kualitas,” tapi sebenarnya karena produk terasa lambat dan aku ingin tahu kenapa.

Dia mengetik: “Bisa ingatkan aku kita bicara apa tentang akun Telkomsel? Kayaknya aku sudah kasih kamu konteksnya tadi.”

Assistant membalas dengan sesuatu yang terdengar meyakinkan, tapi sama sekali salah. Dia mengarang ringkasan deal yang tidak pernah ada.

Dian mengerutkan dahi menatap layar. Dia menggulir ke atas. Di sana — empat pesan yang lalu, dia sudah menempelkan seluruh riwayat akun dari CRM. Sebuah dinding teks. Model sudah membacanya, mengonfirmasinya, bahkan menarik satu detail spesifik ke dalam salah satu balasan. Lalu, beberapa giliran kemudian, seolah semua itu tidak pernah terjadi. Konteks itu diam-diam terdorong keluar dari jendela seiring pesan-pesan baru masuk. Assistant tidak memberitahu Dian. Tidak ada indikator, tidak ada peringatan, tidak ada fallback yang elegan. Dia hanya diam-diam lupa dan terus berjalan.

Dian menutup laptopnya. “Ini tidak konsisten,” katanya. “Aku tidak bisa tahu kapan dia ingat dan kapan tidak.”

Aku mencatat itu. Tapi aku masih memikirkannya sebagai masalah perilaku model, bukan masalah produk. Aku belum melihat apa yang sebenarnya sedang terjadi.

Celah tempat aku berdiri

Apa yang dialami Dian adalah context truncation. Dalam istilah rekayasa, ini hal biasa: model memiliki context window yang tetap, percakapan melampaui batasnya, token-token lama dibuang agar tetap dalam limit. Perilaku standar. Kami sudah menyetel ukuran window untuk menyeimbangkan biaya dan latensi. Kami tahu soal ini. Kami sudah mencatatnya. Tidak ada yang memberitahu Dian.

Inilah celah tempat aku berdiri tanpa bisa melihatnya: bagiku, context window adalah parameter backend. Sebuah angka di file konfigurasi. Aku memikirkannya dalam hal token dan biaya API dan bagaimana ia berinteraksi dengan retrieval. Bagi Dian, itu adalah apakah assistant mengingatnya. Apakah dia bisa mempercayainya. Apakah sesuatu yang sudah dia habiskan lima belas menit untuk mengajarinya masih mendengarkan.

Keduanya adalah fakta yang sama. Kejadian yang sama, dua bingkai yang berbeda. Dan aku membangun produk itu sepenuhnya dari bingkaiku.

Tim produk telah mendesain antarmuka chat — kotak input, gelembung pesan, stempel waktu, spinner “berpikir”. Kami sudah memikirkan onboarding, tentang kondisi error untuk kegagalan jaringan, tentang empty state. Kami tidak sekalipun memikirkan seperti apa tampilannya — bagi pengguna — ketika memori model diam-diam direset. Kami memperlakukan context window sebagai infrastruktur. Dian memperlakukannya sebagai antarmuka.

Dia benar.

Tiga hal yang merupakan UX, bukan backend

Affordance. Affordance adalah sinyal yang memberitahu pengguna apa yang bisa mereka lakukan. Tombol memberi sinyal untuk diklik. Kolom teks memberi sinyal untuk diisi. Sebuah percakapan memberi sinyal untuk berbicara. Tapi context window menciptakan masalah affordance yang tidak terlihat: pengguna mengasumsikan assistant bisa “melihat” semua yang telah mereka katakan. Ketika tidak bisa, mereka tidak tahu. Tidak ada affordance untuk batasnya.

Simon Willison sudah berulang kali menulis tentang kesenjangan antara cara developer memikirkan produk LLM dan cara pengguna benar-benar mengalaminya. Salah satu pengamatannya yang konsisten adalah bahwa kegagalan diam-diam — terutama dalam konteks dan memori — mengikis kepercayaan lebih cepat daripada mode kegagalan lainnya. Pengguna tidak melihat crash. Mereka hanya melihat model yang tampaknya tahu hal-hal di satu waktu dan tidak di waktu lain, lalu menyimpulkan produknya tidak dapat diandalkan. Yang merupakan kesimpulan yang wajar. Memang tidak dapat diandalkan, dalam hal-hal yang penting bagi mereka.

Solusi untuk affordance adalah visibilitas. Jika pesan-pesan sebelumnya tidak lagi ada dalam konteks aktif, katakan saja. Ini tidak perlu teknis. “Beberapa pesan sebelumnya mungkin tidak lagi terlihat oleh assistant” adalah kalimat lengkap yang bisa ditindaklanjuti pengguna. Tampilkan indikator samar di chat ketika window mendekati batasnya. Beri tahu pengguna apa yang bisa dilihat model sekarang, bukan hanya apa yang sudah mereka kirim.

Feedback. 10 heuristik usability Nielsen — ditulis pada 1994 dan masih sebagian besar benar — mencakup “visibilitas status sistem” dan “bantu pengguna mengenali, mendiagnosis, dan memulihkan diri dari kesalahan.” Itu bukan hal yang spesifik untuk AI. Tapi menjadi mendesak dalam produk AI karena mekanisme feedback yang biasa kita andalkan dihilangkan. Tidak ada 404. Tidak ada spinner yang berputar selamanya. Hanya ada paragraf yang meyakinkan yang mungkin atau mungkin tidak didasarkan pada apa pun yang sebenarnya dikatakan pengguna.

Ketika model tidak tahu, dia harus mengatakannya dalam bahasa yang menghadap pengguna. “Aku tidak punya akses ke konteks akun yang kamu bagikan sebelumnya — bisa kamu tempel lagi?” adalah pesan antarmuka yang nyata. Itu membantu, jujur, dan bisa ditindaklanjuti. “Tentu senang membantu dengan akun Telkomsel” — ketika model sudah melupakan akun Telkomsel — bukan satu pun dari itu.

Loop feedback bukan hanya tentang error. Ini tentang membangun hubungan kerja antara pengguna dan sistem. Ethan Mollick telah mendokumentasikan betapa banyak variasi dalam cara orang benar-benar menggunakan LLM — sebagian besar pengguna masih membangun mental model mereka tentang apa yang bisa dan tidak bisa dilakukan sistem ini. Tugas produk adalah membantu mereka membangun yang akurat.

Mental model. Inilah yang paling lama aku sadari. Pengguna membangun intuisi tentang apa yang diingat model berdasarkan apa yang dikonfirmasinya. Jika assistant menggemakan kembali sesuatu yang diberitahukan pengguna — “Betul, kamu menyebut kontrak Telkomsel akan diperbarui di Q3” — pengguna belajar: dia mendengarku. Jika assistant tidak pernah mengonfirmasi, tidak pernah merefleksikan, tidak pernah mengakui apa yang telah diberitahukan, mental model pengguna tetap tidak akurat. Mereka akan terlalu percaya atau kurang percaya. Keduanya adalah kegagalan produk.

Mendesain untuk pembentukan mental model berarti bersikap disengaja soal konfirmasi. Ketika pengguna memberi assistant konteks, minta ia mengakui konteks itu secara eksplisit. Ketika assistant mengambil sesuatu yang dikatakan pengguna tiga pesan yang lalu, sebutkan itu: “Berdasarkan riwayat akun yang kamu bagikan sebelumnya…” Ini bukan pengisi. Ini model yang mengajari pengguna cara bekerja dengannya. Kamu membangun mental model itu dengan sengaja, bukan membiarkan pengguna membangun yang salah secara tidak sengaja.

Titik buta sang engineer

Kita memikirkan context window sebagai angka. 128k token. 200k. 1M. Kita membicarakannya dalam konteks kapabilitas — “kamu bisa memasukkan seluruh codebase ke dalam konteks” — atau dalam konteks biaya — “konteks panjang mahal untuk dijalankan.” Kedua bingkai itu memperlakukannya sebagai urusan internal.

Panduan Anthropic tentang prompting long-context models membahas tantangan struktural tentang apa yang harus diletakkan di mana dalam konteks besar, dan bagaimana model menghadiri informasi di posisi berbeda. Itu adalah pengetahuan rekayasa yang berguna. Tapi masih ditulis untuk engineer. Itu tidak membantumu menjawab pertanyaan yang secara implisit ditanyakan Dian: seperti apa rasanya dari sisi layar pengguna?

Dari sisi pengguna, context window adalah memori kerja model. Itu adalah ruang kerja mental dari assistant yang sedang mereka ajak bicara. Ketika penuh dan meluap, assistant mengalami amnesia — tapi tidak bertingkah seolah punya amnesia. Dia hanya menjawab seolah tidak ada yang terjadi. Ketidaksesuaian antara ekspektasi pengguna (“kamu mengingat semua yang aku katakan”) dan perilaku aktual sistem (“aku diam-diam membuang pesan-pesanmu yang lebih awal”) adalah celah antarmuka. Tempatnya ada di product roadmap, bukan hanya di engineering runbook.

Langkah-langkah yang saling menguatkan

Beberapa hal konkret yang aku lihat membuat perbedaan:

Buat truncation terlihat. Bukan dengan error. Dengan indikator senyap di thread percakapan — sesuatu seperti garis horizontal tipis dengan teks “Pesan-pesan sebelumnya mungkin tidak terlihat oleh assistant.” Drama rendah. Kejujuran tinggi.

Beri label ketidakpastian model dalam bahasa yang menghadap pengguna. Jika produkmu memiliki akses ke sinyal kepercayaan diri, tampilkan di tempat yang bisa dilihat pengguna. Jika tidak, desain prompt untuk menghasilkan hedges yang eksplisit: “Berdasarkan apa yang kamu bagikan dalam percakapan ini…” membatasi klaim model pada apa yang sebenarnya bisa diaksesnya.

Desain prompt seperti kamu mendesain formulir. Formulir yang didesain dengan baik memiliki label, seksi, instruksi yang jelas tentang apa yang masuk ke mana. System prompt yang didesain dengan baik melakukan pekerjaan yang sama. Ketika aku membangun ulang assistant setelah sesi Dian, aku merestrukturisasi system prompt menjadi seksi berlabel eksplisit — satu untuk konteks produk, satu untuk konteks pengguna, satu untuk instruksi tugas — dengan delimiter yang jelas. Perilaku model menjadi lebih konsisten. Kemampuan pengguna untuk memprediksi perilaku itu meningkat. Keduanya saling terhubung.

Ketika kamu memperpendek konteks untuk menghemat biaya, beritahu pengguna bahwa kamu melakukannya. Bukan dinding teks cetak kecil. Satu baris, ditampilkan di momen yang tepat. “Untuk menjaga respons tetap cepat, assistant ini merangkum bagian percakapan yang lebih lama.” Pengguna bisa menerima itu. Yang tidak bisa mereka terima adalah perubahan perilaku diam-diam yang membuat assistant tampak tidak dapat dipercaya.

---

Aku masih memikirkan Dian yang menutup laptopnya itu.

Dia tidak tahu apa itu context window. Seharusnya dia tidak perlu tahu. Yang dia tahu adalah bahwa assistant yang telah dia ajak bicara selama lima belas menit, di tengah jalan, berhenti mendengarkan. Tidak secara dramatis. Hanya diam-diam. Dengan meyakinkan, tidak membantu, tidak terlihat.

Dia menyebutnya “tidak konsisten.” Itu kata yang dermawan. Itu adalah kegagalan antarmuka — secara spesifik, antarmuka tidak punya cara untuk memberitahunya apa yang sedang terjadi. Context window bukan parameter backend. Itu adalah batas perhatian model, dan selalu, sudah dari awal, merupakan permukaan yang menghadap pengguna.

Bangun seperti itu.