- Meskipun batas token input (context window) pada LLM terbaru telah meluas hingga jutaan token, skor tinggi pada benchmark pencarian sederhana (Needle in a Haystack, NIAH) tetap tidak menutupi fakta bahwa penurunan kinerja pada input panjang di dunia nyata memang jelas terjadi
- Para peneliti melakukan beragam eksperimen pada 18 model dan berulang kali mengonfirmasi adanya penurunan kinerja serta pola yang tidak konsisten, bahkan ketika hanya panjang input yang dikendalikan
- Fenomena bahwa laju penurunan kinerja semakin cepat atau berubah secara tak terduga tampak menonjol ketika kemiripan pertanyaan-jawaban menurun, kalimat pengganggu (distractor) ditambahkan, atau struktur teks berubah
- Mempertahankan konteks yang terstruktur (alur paragraf yang logis) justru dapat berdampak negatif pada kinerja, menunjukkan bahwa susunan dan cara penyajian input sangat memengaruhi performa LLM
- Bahkan pada tugas yang sangat mudah seperti sekadar menyalin teks berulang, terlihat keterbatasan bahwa model tidak mampu menghasilkan keluaran yang konsisten ketika panjang input meningkat, sehingga menegaskan pentingnya perancangan konteks (context engineering) dalam penerapan nyata
Latar belakang dan tujuan penelitian
- Belakangan ini, context window pada LLM meningkat hingga 1 juta~10 juta token, sehingga muncul persepsi bahwa performa akan “tetap terjamin” bahkan untuk input yang panjang
- Contohnya Gemini 1.5 Pro, GPT-4.1, dan Llama 4
- Benchmark representatif Needle in a Haystack(NIAH) pada dasarnya hanya menguji pencarian kalimat sederhana, sehingga tidak mampu mencerminkan dengan baik penurunan kinerja pada tugas kompleks seperti peringkasan dokumen panjang dan tanya jawab
- Penelitian ini memverifikasi perubahan kinerja secara sistematis dengan cara hanya mengatur panjang input sementara tingkat kesulitan tugas dibuat tetap
Eksperimen utama dan hasil
- Total 4 rancangan eksperimen dilakukan pada 18 LLM terbaru (Anthropic Claude, OpenAI GPT-4.1/4o/3.5, Gemini, Qwen, dll.):
- Perubahan kemiripan semantik pertanyaan-jawaban (Needle-Question)
- Penambahan kalimat pengganggu (distractor)
- Perubahan topik/struktur teks (haystack)
- Penyalinan kata berulang (panjang output dan input diperluas bersamaan)
- Di semua eksperimen, semakin panjang input, semakin tajam penurunan kinerja, terutama ketika kemiripan semantik rendah atau jumlah distractor lebih banyak
- Semakin rendah kemiripan pertanyaan-jawaban, semakin tajam pula kenaikan rasio jawaban salah pada input panjang
- Bahkan dengan hanya satu distractor tambahan, akurasi langsung menurun, dan ketika ditambah 4 atau lebih, kebingungan dan halusinasi (hallucination) meningkat tajam tergantung modelnya
- Contoh: seri Claude cenderung menghindar dengan mengatakan “jawaban tidak dapat ditemukan” alih-alih menjawab salah, sedangkan seri GPT lebih sering menghasilkan jawaban salah dengan penuh keyakinan
- Juga diamati fenomena unik bahwa performa bisa berbalik tergantung struktur teks (alur logis/susunan acak)
- Pada teks asli (Original) yang mempertahankan alur logis, performa model justru lebih buruk
- Pada teks yang kalimatnya diacak (Shuffled), performa pencarian justru lebih tinggi
- Dalam eksperimen penyalinan kata berulang, ketika token input dan output sama-sama bertambah, pola yang tak terduga seperti meningkatnya rasio kesalahan, penolakan tugas, dan pembuatan kata acak juga ikut naik
- Contoh: setelah 2.500~5.000 kata, pada model tertentu hasil tidak normal seperti penolakan menyalin atau pembuatan teks acak meningkat tajam
LongMemEval: evaluasi percakapan jangka panjang yang lebih realistis
- Pada benchmark LongMemEval yang mencakup rekaman percakapan nyata, dibandingkan input terfokus (hanya bagian yang relevan dengan jawaban) dan input penuh (termasuk konteks yang tidak relevan dengan jawaban)
- Pada semua model, input terfokus menunjukkan akurasi yang jauh lebih tinggi, sedangkan pada input penuh, proses mencari konten yang relevan itu sendiri menjadi tugas tambahan yang secara signifikan menurunkan performa
- Model seri Claude terutama menunjukkan kecenderungan yang jelas untuk menghindar dengan menjawab “tidak ada jawaban” dalam situasi ambigu
Analisis tambahan dan implikasi
- Penelitian ini menganalisis secara rinci perbedaan pola kerja internal antar model melalui berbagai grafik, seperti tingkat kebingungan per distractor, akurasi posisi jawaban, dan posisi munculnya kata acak
- Dalam eksperimen penyalinan kata berulang, ada karakteristik yang bergantung pada posisi, misalnya akurasi lebih tinggi saat kata jawaban berada di bagian awal
- Karena perancangan konteks (susunan informasi, pengelolaan alur logis, dll.) sangat besar pengaruhnya terhadap performa model, penelitian ini menunjukkan bahwa sekadar memperluas konteks tidak cukup untuk mengharapkan performa yang konsisten saat diterapkan pada layanan nyata
Kesimpulan
- Kemampuan LLM memproses input panjang tidak dapat dijamin hanya dari skor benchmark, dan peningkatan panjang input di dunia nyata saja sudah dapat memunculkan penurunan performa yang tidak konsisten
- Sekadar memasukkan informasi yang relevan tidaklah cukup; susunan informasi, struktur, distractor, dan kemiripan semuanya berdampak menentukan pada performa
- Saat memanfaatkan LLM, pengelolaan dan perancangan konteks panjang (context engineering) menjadi hal yang wajib
2 komentar
Sudah lama juga sejak 2.5 keluar, kenapa masih pakai 1.5
Komentar Hacker News
Saya juga mengalami hal yang mirip. Terutama saat memakai Gemini Pro dengan referensi teks yang panjang, saya mendapatkan jawaban yang jauh lebih baik jika setiap dokumen diringkas dulu lalu ditanyai, dan bila perlu baru seluruh dokumen detailnya dimasukkan dengan gaya RAG atau loop agen sederhana, daripada memasukkan banyak dokumen sekaligus ke context window. Mirip juga saat memakai Claude Code bersama Opus atau Sonnet, saya mengalami langsung bahwa makin sering terjadi compaction, makin buruk hasilnya. Saya tidak yakin apakah ini karena kualitas ringkasannya menurun, atau karena proporsi data yang kurang relevan di dalam context window menjadi lebih tinggi, tetapi saat saya mengosongkan konteks lalu memintanya membaca ulang hanya file yang relevan, hasilnya jauh lebih baik (meskipun sudah disebutkan dalam ringkasan sebelumnya)
Gemini mulai runtuh dalam konsistensi dan kemampuan penalaran bahkan sebelum mencapai batas konteks chat. Meski begitu, menurut laporan ini, ia tetap model terbaik dalam banyak hal. Kesimpulannya, context engineering masih penting, dan pendekatan RAG juga masih valid
Bukankah "compaction" pada akhirnya hanya memendekkan transkrip menjadi ringkasan? Kalau begitu, wajar saja performanya memburuk karena memang ada informasi yang hilang. Tapi ini bukan karena context rot. Sinyal context rot yang sebenarnya muncul saat mendekati ambang auto-compact. Apakah saya memahaminya dengan benar?
Agen coding yang optimal sepertinya akan mengotomatiskan proses seperti ini. Ia akan mengumpulkan kode yang diperlukan, respons MCP, peta repo, dan sebagainya, sesekali merangkumnya, lalu menggabungkan semuanya menjadi pesan chat baru agar hanya bagian yang benar-benar perlu yang tersisa. Saya sudah memakai gaya seperti ini dengan alat bernama aider, dan dalam situasi yang memerlukan banyak konteks, hasilnya jauh lebih baik daripada workflow agentic atau otomatis. Hanya saja, butuh banyak kerja manual
Sudah coba NotebookLM? Aplikasi ini memecah dan merangkum dokumen di latar belakang, lalu memungkinkan kita mengajukan pertanyaan ke seluruh dokumen dalam bentuk chat melalui RAG
Saya mengalami bahwa di Cursor, makin lama percakapan berlangsung tentang fitur baru atau perubahan kode, kualitas hasilnya makin menurun. Hasil terbaik saya dapatkan saat saya lebih dulu membuat instruksi dan rencana yang jelas dan spesifik, lalu langsung menyeret file-file yang akan diubah ke prompt konteks
Menjalankan alur "Explore → plan → code → test → commit" jauh lebih membantu. Jika perlu, konteks bisa dikosongkan di setiap tahap untuk meningkatkan efektivitas
Saat informasi yang cukup untuk tugas tertentu sudah terkumpul, saya menyimpan konteksnya. Jika kualitas mulai turun, saya merangkum ulang pekerjaan sejauh ini lalu menambahkannya ke checkpoint sebelumnya
Fenomena ini sudah dikenal, tetapi hampir tidak ada dokumentasi yang benar-benar rapi, jadi saya sangat senang melihat tulisan ini. Saya rasa dampak nyatanya bahkan lebih besar daripada yang mudah diukur lewat benchmark. Aplikasi berbasis LLM yang benar-benar berguna berada tepat di batas kemampuan model. Artinya, nilainya muncul saat harus mengikuti konteks yang menuntut beberapa "lompatan" logis dalam pertanyaan atau tugas nyata. Menurut saya, makin banyak "lompatan" logis yang diperlukan, masalah context rot akan memburuk secara eksplosif, karena setiap lompatan menambah hal yang harus diperhatikan
Sangat perlu ada cara mudah untuk memangkas konteks. Kalau saya bisa mengelola sendiri seluruh percakapan dengan model, rasanya saya bisa mendapatkan performa jauh lebih tinggi dari sesi coding sekitar 200 ribu token. Tetapi kenyataannya, bahkan saat memakai instance yang bagus, setelah sekitar 20 ribu token model mulai aneh terus, dan sesi pun benar-benar membusuk. Saya ingin bisa langsung memotong bagian itu saja
LLM lokal memungkinkan kita mengedit konteks sesuka hati, sehingga jika respons LLM itu sendiri diubah, nanti model bisa salah mengira bahwa itulah yang tadinya ia katakan. Karena itu, ini menguntungkan untuk mengarahkannya ke hasil yang kita inginkan. Sebaliknya, model LLM-as-a-service tidak menyediakan fungsi seperti ini, karena akan mempermudah bypass sensor
Saya pernah bereksperimen dengan meminta, "Hei Claude, saya akan mereset konteks sekarang, jadi tolong buatkan satu prompt agar kita bisa terus bekerja setelah ini," lalu saya meninjau dan menyempurnakan prompt yang disarankan Claude sebelum memasukkannya kembali
Akan jadi fitur terbaik kalau kita bisa dengan mudah rollback ke checkpoint sebelumnya
Di kebanyakan agen CLI, ini bisa dilakukan dengan perintah
/compressSaat memakai Claude code, lama-lama ia tidak bisa membedakan antara kesalahannya sendiri dan instruksi saya. Begitu mulai bingung, solusinya adalah membuka sesi baru. Semakin panjang sesi, semakin sering ia berputar dalam loop yang sama atau bersikeras bahwa tes sudah rusak lalu mengabaikannya (padahal sebenarnya rusak di sesi ini). Mungkin ini salah saya karena memberi prompt yang buruk, tapi rasanya Claude belakangan diam-diam kehilangan sekitar 30 poin IQ
Saya merasakan hal yang sama. Bahkan di paket Max pun ada saat-saat ketika performanya jelas bagus dan jelas buruk
Berpikir "mungkin prompt dan konteks saya yang salah" terasa seperti bentuk gaslighting yang sudah kita internalisasi bersama
Ini adalah salah satu jenis masalah information retrieval, tetapi saya rasa penurunan performa karena perubahan panjang konteks bisa bekerja berbeda dari jawaban retrieval sederhana. Misalnya, pada pertanyaan seperti “bagaimana cara mengubah tombol ini menjadi merah?” atau masalah seperti “kalimat-kalimat di atas termasuk kategori apa?”, perilakunya bisa berbeda. Dulu ada makalah yang menurut saya mengesankan, Many-Shot In-Context Learning. Penelitian itu menunjukkan bahwa performa bisa meningkat besar saat konteks diisi dengan banyak contoh. Jadi pada akhirnya, kita memang harus mengujinya langsung untuk tiap masalah agar tahu bagaimana LLM berubah tergantung isi dan panjang konteks. Kita tidak boleh selalu berasumsi bahwa konteks yang lebih panjang pasti menurunkan performa
Artikel ini sangat keren dan penuh wawasan. Hanya saja, dari sudut pandang literasi media, perlu diingat bahwa Chroma adalah perusahaan vector DB
Baru-baru ini saya menulis beberapa novel panjang dengan Gemini 2.5 Flash, dan context rot memang terasa jelas, tetapi muncul jauh lebih belakangan daripada yang disajikan artikel ini. Dalam kasus saya, baru setelah sekitar 50 ribu hingga 100 ribu token ia mulai mengabaikan konteks awal (misalnya bahasa output, dan sebagainya). Mungkin pada tugas kompleks seperti penulisan kreatif, efeknya lebih sulit diukur atau kurang jelas. Bagaimanapun, selama sesekali konteks yang hilang dimasukkan lagi, kualitasnya tetap cukup layak dipakai
Saya juga mengalami hal serupa. Saat mengembangkan fitur pencarian transkrip video dalam sebuah proyek, panjang teksnya sangat besar. Saya kira model seperti GPT 4.1 tidak akan butuh RAG karena context window-nya besar, tetapi terutama pada model yang lebih kecil, fenomena aneh sering muncul. Alih-alih menjawab pertanyaan dengan benar, model kadang hanya memberikan ringkasan seluruh konten
Laporannya menarik. Saya penasaran apakah ada ukuran konteks yang direkomendasikan untuk tiap model. Saya ingin tahu apakah ada cara untuk menentukan sampai batas mana yang masuk akal untuk use case saya