Jangan Percaya pada Jendela Konteks yang Besar

• Jendela konteks LLM dapat dibagi menjadi zona pintar tempat model bekerja tajam, dan zona tumpul tempat perhatian menurun sehingga mulai melupakan instruksi sebelumnya
• Titik pemisahnya berada di sekitar 100k token, dan besarnya jendela konteks yang diiklankan tidak serta-merta berarti cakupan kerja nyata yang bisa digunakan
• Agen coding dapat dengan cepat menghabiskan token dan mencapai 100k token hanya dengan membaca file, debugging panjang, dan menjalankan pengujian besar
• Laporan RULER dan context rot dari Chroma menunjukkan bahwa konteks efektif hanyalah sebagian dari angka yang diiklankan, dan performa menurun secara bertahap saat jendela diisi semakin penuh
• Dibanding merangkum sesi panjang secara otomatis, meninggalkan informasi di luar sesi lewat spesifikasi dan artefak kecil yang ditulis langsung membuat pekerjaan tetap berada di zona pintar

---

Batas nyata jendela konteks

• Jendela konteks LLM dapat dibagi menjadi zona pintar tempat model tajam, dan zona tumpul tempat perhatian menurun
  • Di zona tumpul, model mulai melupakan hal-hal yang disampaikan beberapa menit sebelumnya
  • Titik pemisahnya berada di sekitar 100k token
  • Besarnya jendela konteks yang diiklankan tidak menghilangkan titik pemisah ini
• Agen coding menghabiskan token dengan cepat dalam pola penggunaan modern
  • Hanya dengan beberapa kali membaca file, sesi debugging yang panjang, dan pengujian berskala luas, 100k token bisa segera tercapai
  • Vendor mengiklankan jendela konteks 200k, 1M, 2M, tetapi angka-angka itu tidak berarti himpunan kerja yang benar-benar dapat digunakan
• Jendela konteks besar pada dasarnya lebih dekat ke angka pemasaran
  • Arsitektur di baliknya memang berfungsi, tetapi menutupi masalah yang pada praktiknya tidak benar-benar diselesaikan oleh mekanisme perhatian dasar
  • Angka yang ditampilkan produk bertambah besar di setiap rilis, tetapi bagian yang benar-benar dapat dipakai tidak mengikuti dengan laju yang sama
• RULER dan laporan context rot dari Chroma menunjukkan bahwa konteks efektif hanyalah sebagian dari angka yang diiklankan
  • Semakin penuh jendela konteks diisi, performa menurun secara bertahap

Cara kerja untuk menjaga sesi tetap pendek

• Agen terbaru mulai memiliki fitur kompresi otomatis untuk menangani sesi panjang
  • Claude Code menjalankan auto-compact, yaitu merangkum riwayat dan memulai ulang saat sesi menjadi panjang
  • Pendekatan ini membantu, tetapi baru bekerja setelah waktu sudah terbuang di zona tumpul
  • Ringkasannya sendiri juga dibuat oleh model yang performanya sudah menurun
• Cara serah terima yang lebih baik adalah membuka sesi baru dan memberikan spesifikasi yang ditulis langsung
  • Spesifikasi yang ditulis sendiri menjadi bahan serah terima dengan sinyal yang lebih kuat dibanding ringkasan otomatis
  • Karena manusialah yang bisa langsung menentukan apa yang penting ke depan
  • Pendekatan ini sejalan dengan metode breadcrumb, yaitu meninggalkan artefak yang rapi agar sesi berikutnya atau orang berikutnya bisa melanjutkan dengan mudah
• obra/superpowers dan mattpocock/skills menyusun workflow agen di sekitar artefak kecil yang memiliki nama
  • PRD, rencana, skill, dan serah terima sub-agen termasuk dalam artefak semacam ini
  • Setiap artefak memindahkan informasi ke luar sesi live agar bisa dibaca oleh sesi berikutnya
  • Pendekatan ini membantu sesi kerja tetap berada di zona pintar
• Jendela konteks harus diperlakukan seperti anggaran
  • Anggap bagian yang benar-benar membantu hanyalah beberapa chunk awal di depan
  • Informasi yang dipindahkan dari sesi live ke written artifact mengurangi jumlah hal yang harus diperebutkan oleh perhatian model

[GN⁺]

Komentar Hacker News

• Mempelajari dasar-dasar AI itu cukup menyenangkan, tetapi saya tidak setuju dengan arah yang sedang ditempuh sekarang
  Sulit diungkapkan dengan kata-kata betapa meresahkannya komentar-komentar di thread seperti ini. Pengalaman baik-baik seperti “XYZ berhasil seperti ini buat saya” terasa seperti saran di thread Facebook tentang perawatan hewan peliharaan atau memasak
  Grup Facebook 3D printing bahkan lebih parah, dan kalau Anda termasuk orang yang mencetak tetapi juga ingin memahami apa yang sebenarnya terjadi, mungkin Anda mengerti maksudnya
  Di dunia LLM, khususnya dunia cloud LLM, ketelitian bersama itu terasa benar-benar runtuh, dan pada akhirnya menyusut menjadi sekadar meniru secara mistis. Tidak ada seorang pun yang lebih benar atau lebih salah daripada yang lain
  Rasanya seperti suasana “sudah coba dibersihkan konteksnya dengan sabun cuci piring Dawn lalu dikeringkan, lalu dioles satu lapis glue stick?”
  Saya tidak ingin terdengar terlalu kasar kepada orang-orang yang memang berniat membantu. Hanya saja ini terasa sangat berbeda dari thread bertopik lain. Biasanya, usulan seseorang akan diperdebatkan atau disempurnakan oleh orang lain, dan kadang ada yang menjelaskan hal seperti cara memilih riwayat bash lalu hidup Anda berubah, tetapi thread seperti ini akhirnya mengalir ke arah “bukankah aneh kalau mengancam ternyata berhasil?”

  • Sifat workflow LLM yang arbitrer dan non-deterministik memang sangat mengganggu. Sebagai orang lama di dunia embedded/sistem, saya selalu memprioritaskan determinisme dan reproduksibilitas
    Tetapi agent itu hebat, dan menjadi “perancang alur berpikir” juga menyenangkan. Saya tidak akan kembali ke cara lama. Bahkan kalau perkembangan AI berhenti hari ini, rasanya karier saya tetap tidak akan sama seperti sebelumnya
  • Di industri teknologi, hal seperti ini sebenarnya sudah selalu ada jauh sebelum LLM muncul
    Saya terlalu sering mengalami rapat yang keputusannya diambil bukan berdasarkan tolok ukur objektif dan terukur, melainkan karena “perusahaan yang sedikit lebih terkenal melakukannya seperti itu”. Bahkan bukti bahwa perusahaan tersebut sebenarnya tidak menerapkan pendekatan itu secara umum pun ternyata sangat tidak berpengaruh
  • Saran IT memang dari dulu sampai taraf tertentu selalu seperti ini. Semakin kompleks sistem dan hasilnya, semakin sulit mendefinisikan dengan jelas apa itu “lebih baik” dan “lebih buruk”
    Jika ditambah fakta bahwa LLM sangat non-deterministik, maka saran tentang LLM pada dasarnya menjadi seperti saran berkebun
    Bahkan “benchmark” pun kebanyakan lebih mirip upaya untuk mengkristalkan intuisi seseorang dengan tingkat keberhasilan tertentu
  • Sangat relate dengan frustrasinya dan pada umumnya setuju. Setiap kali saya mencoba memformalkan workflow berbasis LLM, saya kembali kecewa karena tampaknya tidak ada yang benar-benar tahu mengapa sesuatu berhasil dan yang lain tidak
    Jadi pada akhirnya saya kembali ke /plan dan menyuruhnya “tuliskan ini di dokumen Markdown untuk nanti, sebelum mengulang implementasinya”, sambil berharap sekitar bulan depan akan muncul sesuatu yang lebih ketat dan punya dasar yang lebih masuk akal
    Saya sama sekali tidak memakai glue stick karena memang tidak perlu. Tetapi Dawn tampaknya cukup efektif untuk membuat build plate Bambu kembali melekat dengan baik. Saya tidak sengaja mencarinya; itu memang sudah ada untuk cuci piring. IPA tidak berhasil, jadi saya coba Dawn, dan beberapa kali itu membuat hasil print kembali menempel dengan baik. Sampai sekarang belum mencapai N=30
  • Mungkin “ketelitian bersama” di kepala kita sendiri adalah ilusi, dan LLM beserta masalah konteks-nya hanya menyingkap hal itu
    Selama puluhan tahun hidup di industri teknologi, saya tidak banyak melihat ketelitian. Alat terus bertambah, paradigma lahir lalu mati lalu muncul lagi, dan untuk setiap penggaris yang dipakai mengukur sesuatu selalu ada penggaris saingan dengan satuan yang berbeda. Begitu melewati fisika daya dan sinyal serta biaya dominan wafer silikon, dibandingkan segelintir disiplin yang jauh lebih tua, kita hampir semua hanyalah tukang oprek dengan tingkat keterampilan yang berbeda-beda
    Batas konteks sebenarnya relatif mudah ditangani. Tetapkan spesifikasi dan batasi ruang lingkupnya. Agar LLM menghasilkan keluaran yang baik, dibutuhkan spesifikasi yang jelas dan arahan yang kuat
    Tetapi ini pun mungkin hanya naluri kerja tambal-sulam saat ini. Bisa jadi 90 hari dari sekarang beban ini pun lenyap, dan satu prompt sederhana saja sudah cukup untuk menghasilkan sistem operasi kelas dunia, bahasa pemrograman, serta fondasi formal matematis untuk keduanya

• Mereka menghindari masalah ukuran konteks dengan satu batasan sederhana pada loop agen. Pada utas percakapan tingkat teratas pengguna, semua pemanggilan tool diblokir. Pekerjaan yang memerlukan pemanggilan tool hanya terjadi di dalam pemanggilan rekursif agen, lalu hanya hasilnya yang dikembalikan ke pemanggil
  Bahkan pada codebase dengan lebih dari 1 juta LOC, mereka bisa mempertahankan percakapan tingkat tinggi yang sama sepanjang hari tanpa menyentuh batas token yang berarti. Tidak perlu trik kompresi atau peringkasan juga. Bahkan jika pemanggilan rekursif membakar 50 juta token, utas percakapan root bisa tetap tidak menyentuh 100 ribu token
  Memang perlu ada pengerjaan ulang untuk “bootstrap” setiap kali agen turun lagi ke Narnia, tetapi itu jauh lebih efisien daripada terus membawa konteks datar besar yang berusaha memuat segalanya
  Rekursi sangat efektif untuk mengendalikan penggunaan token, tetapi tetap ada batasnya. Mereka belum pernah mendapat manfaat dari kedalaman rekursi lebih dari 1. Agen memang terlihat mencoba beberapa kali, tetapi performa nyatanya tidak muncul. Rekursi simbolik eksternal tampaknya bukan sesuatu yang dilatih pada model frontier. Model sangat bagus meniru rekursi di dalam konteks, tetapi jika tujuannya mengurangi penggunaan token, itu justru arah yang tidak diinginkan

  • Jika memakai Claude Code, Anda cukup menyuruhnya melakukan semua pekerjaan di dalam workflow. Ada tool untuk itu, fitur yang muncul bersama Opus 4.8, dan tampaknya lebih baik untuk pekerjaan panjang juga
    Pada titik ini, percakapan utama hanya berperan mengoordinasikan tugas
  • Secara intuitif ini masuk akal. Saya penasaran harness apa yang dipakai sampai batasan seperti itu bisa diatur, dan bagaimana cara mengaturnya
  • Claude Code tampaknya melakukan ini secara otomatis dalam beberapa kasus. Sepertinya ada heuristik semacam “ini akan memakan banyak konteks” lalu memutuskan untuk meneruskannya ke sub-agen
    Saya sering melihatnya pada alur pemecahan masalah atau analisis data, ketika pengumpulan dan agregasi data dilempar ke sub-agen lalu hanya hasil ringkasannya yang diambil
    Mirip juga, agen utama kadang menyimpan konteks di dokumen desain atau file Markdown sambil berjalan dan terus memperbaruinya. Dengan begitu, kapan pun bisa dihapus, dimulai ulang, atau diserahterimakan
  • Saya memakai pendekatan lain, dan masih mencoba memahami seberapa baik cara itu bekerja. Alih-alih masuk ke rekursi, saat konteks terlalu besar atau buntu, agen melewati tahap ringkasan/laporan/refleksi lalu memulai ulang thread, menulis temuan inti ke memori persisten, dan menulis ulang prompt
    Bisa dibilang ini mendekati rekursi dengan tail call optimization
    Dalam beberapa hal ini adalah generalisasi dari pendekatan berbasis spesifikasi, karena selain spesifikasi formal ada buffer warisan yang tetap tersimpan di memori
  • Menarik karena mengurangi konteks dan penggunaan token menguntungkan pengguna, tetapi bertentangan dengan kepentingan finansial penyedia AI
    Bahkan tanpa jadi ahli pun, “trik sederhana” ini terdengar seperti bisa memperbaiki masalah konteks dan memungkinkan kontrol penggunaan token yang jauh lebih ketat. Terima kasih sudah membagikan tip seperti ini lewat komentar HN. Cara orang-orang yang saya kenal memakai agen AI mungkin akan berubah ke depan. Sulit untuk terus mengikuti perkembangannya

• Sejak Anthropic menyediakan jendela konteks 1 juta token pada paket langganan, saya belum mengalami hal seperti ini di Opus. Dalam pemakaian biasa pun saya sering melewati 500 ribu token, dan kadang mendekati 800 ribu token tanpa melihat masalah ini
  Saya memang melihatnya sedikit saat mendekati batas nyata, di atas 900 ribu token, tetapi tidak separah yang dilihat penulis
  Lagi pula, untuk satu tugas tunggal atau sekumpulan tugas yang cukup terkait untuk mempertahankan konteks yang sama, jarang sekali jendela konteks terisi sejauh itu; biasanya di kisaran 200 ribu sampai 600 ribu
  Ini bukan berarti tak ada siapa pun yang mengalaminya, tetapi terasa aneh bahwa bagi sebagian orang ini cukup sering terjadi sampai diberi nama tersendiri

  • Saya sering melihat klaim seperti ini, tetapi rasanya tidak masuk akal karena saya sudah berkali-kali melihat model Opus membuat kesalahan recall dasar bahkan di bawah 100 ribu token
    Menurut saya pribadi, rentang cerdas Opus ada di di bawah 60 ribu token. Opus 4.7 dan 4.8 malah lebih buruk karena tokenizer yang lebih terperinci
  • Opus 4.6 terasa seperti sedang teler setelah lewat 200 ribu, saya melewatkan 4.7, 4.8 masih oke sampai sekitar 350 ribu, dan Fable dalam pengujian terbatas tetap luar biasa bahkan melewati 400 ribu
    Kualitasnya tampak bergerak naik
  • Tidak semua orang memakai model dan harness yang sama, dan juga tidak memakai model dengan cara yang sama
    Setiap model dan versi model menggunakan arsitektur attention yang berbeda, dan itu memengaruhi performa pada konteks panjang. Jumlah dan jenis pelatihan konteks panjang juga jelas berbeda
    Setiap agen juga berbeda dalam cara menyusun konteks dan menerapkan kompresi konteks
    Kalau bukan model yang sama, agen/harness yang sama, dan tugas yang sangat mirip, tidak ada alasan untuk menganggap pengalaman soal perilaku model terkait ukuran konteks akan sama
  • Saya sering melewati 300 ribu dan juga pernah bekerja di 800 ribu, tetapi ini jelas masalah yang bisa diamati
    Bergantung pada masalahnya, jendela konteks besar memang bisa bekerja, tetapi menurut saya lebih efektif jika condong ke konteks yang lebih kecil, di bawah 300 ribu
  • Setuju. Keluarga Claude terus membaik dalam hal ini di setiap rilis
    Opus 4.5 mulai gagal melakukan pemanggilan tool saat mendekati batas 200 ribu, Opus 4.6 bisa sampai sekitar 300 ribu sebelum mulai bingung, Opus 4.7 bisa diperpanjang sampai sekitar 400 ribu tetapi setelah itu masuk ke zona bodoh. Di Opus 4.8 saya punya sesi yang nyaman melewati 500 ribu
    Waktu saya memakai Fable memang terbatas, tetapi ada juga beberapa sesi yang berjalan mulus sampai 800–900 ribu

• Versi terbaru Opus masih oke di atas 100 ribu, tetapi biasanya saya berusaha menjaganya di bawah 200 ribu
  Karena itu saya menganggap apa yang disebut sistem memori biasanya adalah kesalahan yang justru membuat model lebih bodoh. Model tidak punya memori, yang ada hanya konteks, dan makin banyak fakta tak relevan didorong ke konteks, makin sedikit konteks yang tersisa untuk masalah yang sedang dikerjakan. Semakin sedikit gangguan, semakin baik hasilnya
  Cara membuat agen “mengingat” sesuatu adalah dengan menyuruhnya mendokumentasikan pekerjaannya, seperti ketika developer manusia membuat proyek yang ramah bagi developer lain. Dokumentasi pengembangan yang baik dengan halaman indeks dan rencana yang baik dengan checklist, disimpan sebagai file Markdown ringkas dan di-commit ke repositori, adalah memori ideal bagi model, sekaligus dokumentasi ideal untuk memahami sebenarnya apa yang sudah dikerjakan model. Ini juga membantu saat manusia atau model lain melakukan code review, dan tidak ada sisi buruknya

  • Setidaknya dalam kasus saya, Opus terus menuliskan sesuatu ke memori, tetapi secara konsisten lupa memeriksa memori itu sebelum mengulangi kesalahan yang sama
    Jadi “ingat untuk cek memori!” kembali disimpan ke memori. Jelas ini bukan sistem yang bekerja dengan baik
  • Sistem “memori” adalah cara agar para developer merasa mereka sedang berkontribusi pada AI

• Hampir semua komentar di sini mengandalkan pengalaman pribadi. Sebaliknya, postingan aslinya merujuk pada dua studi yang membandingkan kinerja tes terstandar pada beberapa model
  Saya tidak bisa mengatakan seberapa bagus tes-tes itu, tetapi pasti tidak lebih buruk daripada bukti anekdotal untuk sesuatu yang samar dan subjektif seperti performa LLM

  • Untuk menambah bukti anekdotal, di semua pengujian yang saya lakukan, lini Llama sangat buruk dalam mengikuti instruksi. Saya tidak terlalu tahu soal model lain di RULER
    Di hasil Chroma saya melihat Sonnet 4, dan dalam pengalaman saya juga Sonnet 4 itu buruk. Prompt yang sama yang bekerja sempurna di Sonnet 4.5 gagal total di Sonnet 4
    Saya ingin melihat pengujian baru yang mencakup model mutakhir terbaik sekaligus model open-weight. Model terbaik tampaknya selalu lebih baik dalam mengikuti instruksi dan tidak terlalu keluar dari topik, dan akan bagus kalau ada data yang mendukung itu
  • Studi-studi itu memakai data 2024 dan 2025. Itu tidak berlaku untuk model Claude saat ini

• Saya cukup berhasil dengan memaksa AI bertindak seperti manajer produk dan menuntut agar ia menulis PRD singkat untuk setiap fitur yang akan dibuat
  Dengan begitu, seiring waktu saya bisa merujuk kembali pada apa yang sudah dibuat, dan untuk tiap fitur percakapannya jadi tidak terlalu melantur. Saya membuat percakapan terpisah untuk tiap fitur
  Bagi saya ini kompromi yang pas: mencegah penyimpangan, tetapi tetap memungkinkan merujuk keputusan masa lalu saat diperlukan. Yang saya tidak suka dari pendekatan Pocock adalah lebih sedikit menulis PRD dan lebih dulu menyelaraskan lewat diskusi mendalam, karena itu membuang terlalu banyak bagian terbaik pada bolak-balik awal

  • Saya penasaran apakah itu dilakukan secara ad hoc, atau memakai pendekatan yang lebih terstruktur seperti openspec
    Saya juga cenderung merencanakan lebih dulu, tetapi itu tertinggal sebagai daftar tugas di dalam sesi sehingga sulit dirujuk nanti

• Mengutak-atik apa yang terjadi di dalam agen mungkin tidak akan lama lagi menjadi bagian dari pengembangan perangkat lunak
  Secara pribadi, saya sudah melihat LLM dan agen sebagai kotak hitam. Saya memberi permintaan fitur yang sama ke beberapa LLM dan membandingkan hasilnya. Saya tidak menulis “sesi” secara manual. Saya hanya melihat hasilnya. Kalau tidak suka, saya git reset --hard, ubah prompt, lalu mulai lagi permintaan fiturnya
  Saya menyimpan log untuk terus mendapatkan gambaran agen mana yang paling bagus, dan menghitung skor ELO untuk agen yang paling memenuhi kebutuhan saya. Bagi saya yang penting adalah skornya, bukan terlalu peduli bagaimana agen itu mencapainya

  • Kalau memikirkan biaya inferensi yang sebenarnya, ini benar-benar cara yang luar biasa boros dan bukan sesuatu yang layak dibanggakan
  • Saya penasaran proyek atau jenis pekerjaan kode seperti apa yang Anda serahkan
    Dugaan saya, ini mungkin cocok untuk jenis pekerjaan frontend yang tidak butuh banyak verifikasi keamanan atau validasi lain
    Tapi untuk industri yang diatur ketat atau pekerjaan yang harus sangat hati-hati, sepertinya tidak cocok
  • Model mana yang saat ini paling unggul?

• Betul, manajemen konteks adalah kuncinya
  Saya membuat framework sendiri dan menghabiskan banyak waktu untuk men-debug masalah ini; dibanding ukuran konteks absolut, yang lebih jadi masalah adalah kemungkinan ada sampah atau arahan keliru di dalam jendela yang menutupi hal-hal yang menurut pengguna penting
  Ini muncul sebagai kecenderungan LLM terus mencoba lagi hal-hal yang gagal pada pendekatan sebelumnya. Kalau sesuatu sering muncul di dalam jendela konteks, itu jadi berbobot, bahkan kalau salah
  Ada juga banyak trik, seperti tidak memberi LLM terlalu banyak alat, melainkan memberinya alat untuk mencari alat yang akan dipakai
  Tetapi solusi yang lebih besar ada pada prosesnya. Gunakan hal seperti superpowers untuk memaksa LLM mengikuti langkah demi langkah, dan kendalikan konteks yang dibawa ke depan

• Saya membuat ekstensi pribadi yang sangat kecil untuk Pi dan menambahkan perintah /last. Itu menghapus seluruh sesi dan hanya menyisakan pesan output terakhir dari agen
  Dengan ini “kompresi” manual jadi mungkin. Pada dasarnya saya menyuruh agen, “ringkas rencana yang sudah dibahas beserta referensi file yang perlu diedit,” lalu memanggil /last, dan setelah itu menyuruhnya mengimplementasikan
  [1] https://pi.dev/

• Saya tidak suka kalau semua ini digeneralisasi sebagai “model-model”. Tiap model punya arsitektur atensi yang berbeda, jadi perilaku pada konteks panjang juga bisa sangat berbeda
  Memang benar konteks panjang itu bermasalah dan di sebagian besar model kualitasnya menurun, tetapi saya tidak akan langsung menggeneralisasi perilaku model lama ke model baru