—·
Compaction adalah langkah tersembunyi saat aplikasi LLM merapatkan konteks terdahulu agar muat di context window. Pahami di mana prosesnya berlangsung dan cara memverifikasi yang dipertahankan.
Sesi LLM yang lazim tidak sekadar “penuh lalu berhenti.” Pada banyak produk nyata, sistem diam-diam berganti strategi: ketika percakapan membesar hingga terlalu besar, sistem secara otomatis memampatkan pesan-pesan lama menjadi representasi ringkas agar model tetap bisa melanjutkan. Proses ini kini semakin sering diekspos kepada pengembang dan power user, dengan istilah seperti “compaction” dalam toolchain long-context, atau perilaku “auto-compact” pada sebagian alur kerja chat/agent.
Anthropic, misalnya, mendokumentasikan compaction sebagai mekanisme peringkasan otomatis yang aktif saat percakapan mendekati ambang token yang dikonfigurasi. (Source)
Karena itu, “LLM basics” tidak bisa berhenti pada token dan context windows. Pemula biasanya belajar kebiasaan aman: memverifikasi sebelum percaya. Namun kendala kedua sering terlewat: ketika compaction terjadi, model mungkin tidak lagi menatap bukti orisinal yang disediakan. Yang dilihat justru ringkasan dari bukti itu.
Ringkasan dapat bersifat tak lengkap (detail dibuang), terdistorsi (bahasa diubah bingkainya), atau bahkan keliru secara halus (ringkasan yang memperkenalkan atau menyalahnyatakan fakta). Compaction mengurangi kesalahan karena context overflow, tetapi memindahkan risiko dari “teks yang hilang” menjadi “halusinasi berbasis ringkasan”—ketika model dengan yakin melanjutkan dari klaim yang tertulis dalam ringkasan.
Lalu, gambaran mentalnya menjadi lebih tepat: token dan context windows membatasi apa yang bisa diakses model. Compaction menentukan bagian mana dari token-token terdahulu yang akan bertahan. Dalam praktik, compaction adalah langkah pra-pemrosesan dalam alur tokens-ke-prompt, dan paling menentukan saat LLM dipakai untuk riset atau penulisan yang saksama, ketika detail awal seharusnya tetap bisa diperiksa. (Source)
Model long-context modern telah mendorong ukuran jendela jauh melewati era awal 8K/16K. Google’s Gemini 1.5 Pro disebut mendukung hingga 1 juta token dalam produksi. (Source) Anthropic juga menerbitkan ekspansi context-window, termasuk loncatan 100K token untuk Claude yang mereka jelaskan sebagai “sekitar 75.000 kata.” (Source) Bahkan, dokumentasi API Anthropic saat ini membahas ketersediaan context window 1M token, dengan anggaran (budget) spesifik tergantung saluran (channel). (Source)
Namun bahkan dengan jendela jutaan token, compaction tetap bernilai karena prompt tidak hanya memuat teks. Keluaran tool, instruksi sistem, riwayat percakapan, dan kadang overhead tersembunyi atau internal juga mengonsumsi token. Dokumentasi API OpenAI untuk GPT-4o menyebut context window 128.000, yang menegaskan bahwa sebagian besar penerapan tetap berjalan di dalam anggaran ketat, meskipun angka-angkanya terdengar besar. (Source)
Ketika budget terbatas, compaction menjadi sistem kendali default. Panduan ini akan memperlakukan compaction sebagai konsep utama, bukan rincian kebetulan.
Bayangkan pipeline seperti ini:
Dokumentasi compaction Anthropic menjelaskan persis hal tersebut: “memperpanjang panjang konteks efektif untuk percakapan dan tugas yang berlangsung lama” dengan cara merangkum konteks lama secara otomatis saat mendekati batas window, menghasilkan “compaction block” yang kemudian dipakai model untuk melanjutkan. (Source)
Di sinilah pelajaran keselamatan bagi pemula hingga perantara seharusnya benar-benar mendarat. Bukan cuma soal model bisa “lupa” saat context window tercapai; inti masalahnya, langkah transformasi antara mengubah apa yang dihitung sebagai konteks.
Perubahan analitis yang kunci adalah: compaction mengubah status bukti (evidence state), bukan sekadar volume bukti. Saat terjadi truncation, model berhenti melihat teks terdahulu sepenuhnya. Dengan compaction, model tetap berlanjut—menggunakan token yang diproduksi baru untuk menggantikan token-token terdahulu. Penggantian itu bisa setia, tetapi juga bisa menyimpang dalam pola yang sistematis:
Dengan kata lain, compaction tidak hanya “menghemat ruang.” Ia menciptakan ketergantungan tahap kedua: keluaran yang datang belakangan dikondisikan oleh penilaian kompresi awal model, bukan hanya oleh input orisinal. Inilah yang membuat failure mode disebut “halusinasi berbasis ringkasan,” bukan sekadar kegagalan truncation biasa.
Jadi, apa yang patut diharapkan saat compaction aktif? Secara praktis, konteks yang bisa diakses model menjadi campuran: sebagian token masih berpijak langsung pada percakapan orisinal, sementara token lain adalah pengganti yang dihasilkan model—kebenarannya tidak bisa disimpulkan dari tingkat keyakinan (confidence) semata. Semakin tugas bergantung pada detail yang mudah diparafrase (tanggal, angka, atribusi, klausul pengecualian), semakin penting memperlakukan compaction sebagai transformasi yang bisa diaudit—bukan rincian implementasi latar belakang.
Token adalah unit akuntansi. Compaction adalah respons operasional. Ini bukan basis data yang bertahan tentang apa yang ditulis. Compaction lebih dekat pada kebijakan penulisan ulang tentang apa yang akan dilihat model di masa mendatang.
Perbedaan ini penting ketika menjalankan verifikasi berulang (verification loop). Verifikasi berulang seharusnya dibangun di sekitar pertanyaan: “Apakah model memverifikasi isi ringkasan, atau memverifikasi materi aslinya?” Banyak pengguna menganggap keduanya sama. Dalam skenario compaction, keduanya bisa berbeda.
Selain itu, compaction bisa berinteraksi dengan fitur lain yang terasa seperti “memory,” dalam cara yang membingungkan. OpenAI, misalnya, menjelaskan ChatGPT “Memory” sebagai mekanisme terpisah dari konteks percakapan mentah, lengkap dengan kontrol untuk mengelola dan menghapus memori yang tersimpan. (Source) Sebaliknya, compaction umumnya adalah kompresi level-sesi atas konteks percakapan sebelumnya untuk menjaga prompt tetap dalam batas. Pemula tidak seharusnya memperlakukan sistem-sistem ini sebagai hal yang setara.
Mudah menggambarkan compaction sebagai peningkatan murni: lebih sedikit momen “tidak bisa lanjut,” sesi kerja panjang yang lebih mulus, dan lebih sedikit kebutuhan re-prompt berulang. Keuntungan ini nyata. Merangkum konteks lama lebih awal juga dapat membantu performa: model tetap fokus pada “bentuk” tugas, tanpa dipaksa membaca ulang semuanya.
Namun ada biaya editorialnya. Ringkasan bersifat kehilangan informasi (lossy). Meski akurat dalam semangat, ringkasan bisa mengubah tingkat spesifiknya. Paragraf yang terhapus bisa menghilangkan bukti yang diperlukan untuk klaim yang ketat. Parafrase bisa mengubah siapa berkata apa. Ringkasan juga bisa—secara tak sengaja—berubah menjadi mesin pembuat pernyataan baru ketika model peringkasan mengisi celah. Dalam alur kerja long-context, “ringkas lalu jawab” dapat memperkuat efek ini karena tahap jawaban memperlakukan ringkasan sebagai kebenaran konteks.
Riset tentang pola halusinasi dalam peringkasan sangat relevan. Dalam studi peringkasan multi-dokumen, penulis melaporkan bahwa rata-rata “hingga 75% dari konten” dalam ringkasan yang dihasilkan LLM adalah halusinasi, dengan halusinasi lebih mungkin muncul di bagian akhir ringkasan. (Source) Walaupun paper ini menargetkan peringkasan multi-dokumen, bukan ringkasan compaction secara spesifik, ia memperlihatkan risiko umum: ringkasan bisa memuat konten yang tidak berpijak pada input—terutama ketika ringkasan makin panjang atau makin banyak unsur inferensinya.
Untuk memperjelas, ringkasan compaction tidak identik dengan “buat ringkasan pemasaran dari tiga artikel.” Tetapi keduanya sama-sama melakukan transformasi konten menjadi representasi padat yang akan dipakai ulang pada langkah berikutnya. Ketika ringkasan mengandung kesalahan, langkah pemakaian ulang dapat mengubahnya menjadi keluaran yang terdengar meyakinkan.
Sekalipun kualitas compaction tinggi, halusinasi tidak semata-mata persoalan context window. OpenAI berargumen bahwa halusinasi muncul sebagian karena prosedur pelatihan dan evaluasi standar memberi penghargaan pada tebakan (guessing) alih-alih pengakuan ketidakpastian. (Source) Artinya: jika sistem perlu tetap melanjutkan dan memiliki grounding yang tidak lengkap, sistem tetap dapat menghasilkan konten yang lancar dan “terasa benar.” Dalam skenario compaction, grounding yang tidak lengkap itu bisa bersumber dari detail yang hilang di representasi yang dipadatkan.
Sikap praktisnya bukan “compaction itu buruk.” Melainkan: “compaction menggeser apa yang harus diverifikasi.” Verifikasi dilakukan pada ringkasan, karena ringkasan menjadi input bagi penalaran berikutnya.
Berikut verification loop sederhana yang dirancang untuk pengguna pemula hingga perantara agar dapat mengurangi halusinasi berbasis ringkasan tanpa mengubah alur kerja menjadi birokrasi.
Minta ringkasan eksplisit tentang apa yang sedang dipakai model. Misalnya:
Ini tidak menjamin kejujuran sempurna, tetapi menciptakan artefak yang terstruktur untuk diaudit. Langkah ini juga memberi sesuatu untuk dibandingkan dengan materi sumber.
Kemudian jalankan putaran kedua:
Ini menyerupai arah riset yang mapan untuk mengurangi halusinasi melalui prompting bergaya verifikasi. Salah satu contoh adalah “Chain-of-Verification (CoVe),” yang menyusun respons, merencanakan pertanyaan verifikasi, menjawabnya secara independen, lalu menghasilkan respons final yang sudah terverifikasi. (Source) Sekalipun implementasi dilakukan manual, inti idenya tetap: stop memperlakukan draf pertama sebagai kebenaran yang tak bisa diganggu.
Putaran ketiga menangkap kerusakan compaction yang paling umum: hilangnya constraint.
Pertanyaan ini meminta model menyorot kerapuhan. Jawaban yang baik sering kali mengungkap apa yang tidak ada dalam ringkasan.
Meski berhati-hati, compaction dapat aktif sebelum benar-benar “menabrak batas.” Dokumentasi compaction Anthropic menunjukkan ia aktif saat mendekati ambang token yang dikonfigurasi, bukan hanya ketika batas keras tercapai. (Source) Itu berarti alur kerja harus memperlakukan compaction sebagai kejadian berulang, bukan peristiwa luar biasa.
Bangun verification loop agar bisa berjalan setiap kali mengubah fase tugas (misalnya setelah beralih dari merangkum menjadi menyusun argumen, atau setelah meminta bagian baru dalam draf).
Perilaku produk berbeda-beda, tetapi mekanisme mirip compaction sering muncul dalam toolchain yang dirancang untuk tugas panjang. Berikut contoh yang terdokumentasi—baik ketika compaction adalah bagian eksplisit dari desain sistem, atau ketika alur kerja berjangka panjang memerlukan ringkasan agar bisa terus berjalan.
Anthropic mendokumentasikan compaction sebagai fitur yang otomatis merangkum konteks lama saat mendekati ambang token, lalu menggantinya dengan compaction block supaya percakapan dapat berlanjut. (Source)
Outcome: sesi yang berlangsung lebih lama dengan lebih sedikit konteks overflow.
Timeline: dokumentasi compaction Anthropic memuat pola header compaction yang diperbarui, yang menunjukkan fitur produk tersebut diluncurkan dalam alur kerja Claude API. (Source)
Pelajaran praktis: ketika ketergantungan pada detail di awal thread tinggi, klaim perlu diverifikasi terhadap materi sumber, karena model tidak lagi dijamin “melihat” materi-materi tersebut secara verbatim.
Pengumuman “100K Context Windows” dari Anthropic menyoroti pergeseran dari 9K ke 100K token, setara sekitar 75.000 kata, dan menyatakan context windows tersebut tersedia dalam API mereka. (Source)
Outcome: lebih banyak konten dapat dimasukkan dalam satu sesi, sehingga pemicu compaction bisa tertunda dan penggantian konteks lama dengan blok ringkas bisa lebih jarang.
Timeline: pertama kali diumumkan dalam posting 100K context window Anthropic (dipublikasikan saat ekspansi itu digulirkan). (Source)
Pelajaran praktis: sekalipun jendela cukup besar untuk menunda compaction, alur kerja berdurasi panjang sering kali tetap menghasilkan ringkasan sekunder (catatan riset, outline antara, rekap “apa yang diputuskan”). Risiko yang dikelola tidak hilang—ia bergeser dari “compaction implisit saja” ke “compaction implisit plus kompresi yang dibuat pengguna atau aplikasi.”
Google mendeskripsikan Gemini 1.5 Pro sebagai model yang mendukung hingga 1 juta token dalam produksi. (Source)
Outcome: pengguna bisa menyertakan teks jauh lebih banyak per sesi, berpotensi menunda pemicu compaction dan mengurangi frekuensi sistem mengganti konteks awal dengan blok yang dipadatkan.
Timeline: diumumkan dalam posting Google edisi Februari 2024. (Source)
Pelajaran praktis: transformasi mirip compaction tetap mungkin terjadi ketika aplikasi secara internal menghasilkan artefak “briefing” yang dipadatkan, meski window model dasar sangat besar. Dengan kata lain, verifikasi bukan hanya untuk ambang keras; ia juga diperlukan pada tahap apa pun yang menghasilkan representasi terkompresi—yang kemudian diperlakukan langkah berikutnya sebagai ground truth.
Sebuah benchmark peringkasan multi-dokumen menemukan bahwa halusinasi dapat mendominasi konten ringkasan. Laporan menyebut “hingga 75%” konten terhalusinasikan secara rata-rata di antara model yang dievaluasi. (Source)
Outcome: masuk akal bahwa representasi yang dipadatkan dapat membawa ketidakakuratan yang terbawa.
Timeline: riset dipublikasikan sebagai preprint; entri arXiv menunjukkan periode studi. (Source)
Pelajaran praktis: jangan menganggap ringkasan yang dipadatkan secara inheren lebih aman daripada transkrip panjang. Perlakukan ia sebagai artefak yang butuh verifikasi.
Untuk riset dan penyusunan draf, diperlukan dua sifat dari asisten LLM: (1) grounding yang stabil, dan (2) ketidakpastian yang dinyatakan secara eksplisit ketika grounding tidak tersedia. Compaction memengaruhi keduanya.
Sebelum meminta argumen atau sintesis, minta ekstraksi terstruktur dari sumber:
Pendekatan ini mendorong model membangun claim ledger. Baru setelah ledger tersebut ada, penulisan diminta. Cara ini mengurangi peluang compaction menghapus bukti yang dibutuhkan untuk paragraf berikutnya.
Jika asisten cenderung melakukan compaction, dapat diminta agar merangkum ulang secara sengaja lalu diaudit:
Ini mengubah compaction dari operasi tersembunyi menjadi langkah yang eksplisit dan bisa ditinjau, sehingga verification loop memiliki objek nyata untuk diperiksa. Dokumentasi Anthropic memposisikan compaction sebagai automatic summarization block; meminta “compaction summary” yang terkontrol adalah cara untuk mengembalikan agensi atas transformasi tersebut. (Source)
Karya OpenAI tentang halusinasi menekankan bahwa insentif dan evaluasi penting, dan model bisa didorong untuk menebak secara percaya diri. (Source) Terjemahan praktisnya dalam alur kerja: minta pemeriksaan yang memaksa model mengaitkan klaim pada bukti, serta memberi label untuk item yang belum terverifikasi.
Arah riset relevan lainnya: chain-of-verification mengurangi halusinasi di berbagai tugas dalam eksperimen. (Source) “Verification loop” yang dijalankan manusia pada dasarnya adalah analog operasional dari gagasan tersebut.
Compaction makin menjadi default praktis dalam aplikasi LLM yang berjalan lama, karena context budgets itu nyata, dan karena peringkasan otomatis atas pesan sebelumnya adalah cara termurah agar sesi tetap hidup. Anthropic mendokumentasikan compaction secara eksplisit sebagai langkah peringkasan otomatis yang dipicu saat mendekati ambang. (Source) Saat model long-context diskalakan, compaction mungkin lebih jarang aktif, tetapi tidak akan hilang—karena alur kerja penulisan dan analisis tetap diuntungkan oleh kondensasi.
Menjelang Q4 2026, tim seharusnya merencanakan pola pengalaman pengguna (UX) untuk verification loop—misalnya panel “compacted summary” yang terlihat atau jejak audit (audit trail) atas konteks yang dipertahankan—menjadi makin standar dalam tooling profesional, terutama ketika kepatuhan (compliance) atau peninjauan editorial menjadi pertimbangan. Alasan teknisnya sederhana: compaction menghadirkan langkah transformasi yang dapat ditampilkan dan diuji, sementara metode verifikasi bergaya riset sudah memiliki dukungan literatur untuk mengurangi halusinasi. (Source) Compaction sendiri didokumentasikan, sehingga dapat dioperasionalkan dalam desain produk. (Source)
(Catatan realitas: ini proyeksi perencanaan, bukan jaminan. Varian keluarga model dan perancang aplikasi akan berbeda apakah compaction diekspos secara eksplisit. Sebagian mungkin lebih memilih “shadow summaries” yang tidak pernah menampilkan panel audit—sehingga kebijakan tim perlu mengasumsikan visibilitas sempurna tidak selalu tersedia.)
Terapkan kebijakan penerapan dengan satu aturan tunggal: tidak ada klaim yang membawa bukti boleh diambil dari compaction summary tanpa langkah verifikasi yang terikat pada sumber asli.
Secara konkret, tim yang menggunakan compaction pada LLM perlu menjalankan workflow dua tahap untuk riset dan penulisan:
Kebijakan ini langsung menargetkan risiko “halusinasi berbasis ringkasan” yang diperkenalkan oleh compaction. Kebijakan ini juga selaras dengan pemahaman luas bahwa halusinasi bertahan ketika sistem diberi insentif untuk menebak secara percaya diri tanpa evaluasi yang sadar ketidakpastian. (Source)
Intinya: compaction bukan jalan pintas kepercayaan. Ia sekadar lapisan kenyamanan. Tugas pengguna memastikan lapisan kenyamanan tersebut tidak pernah berubah menjadi penulis final bagi fakta-fakta.