Apa Itu Context Window pada LLM? Penjelasan Lengkap

Apa Sebenarnya Context Window Itu

Context window adalah jumlah maksimum teks—yang diukur dalam satuan token, bukan kata atau karakter—yang dapat diproses dan dipertimbangkan oleh large language model secara sekaligus saat menghasilkan respons. Segala hal yang dapat diakses model saat memproduksi output berikutnya harus termuat dalam satu jendela ini, seperti prompt kita saat ini, instruksi apa pun yang diberikan sebelumnya dalam percakapan, dokumen yang kita unggah atau tempel (paste), serta respons-respons model sebelumnya dalam percakapan yang sama.

Cara paling tepat untuk memahami context window adalah dengan menganggapnya sebagai keseluruhan kesadaran kerja model pada momen tertentu, yaitu segala sesuatu yang benar-benar dapat "dilihat" dan diperhitungkan oleh model saat menyusun respons. Apa pun yang berada di luar jendela ini praktis tidak ada dari sudut pandang model selama proses pembuatan respons tersebut berlangsung. Informasi itu tidak tersimpan di tempat lain yang bisa diperiksa kembali oleh model jika diperlukan. Informasi itu juga tidak dipanggil kembali dari memori jangka panjang yang terpisah. Jika informasi tersebut tidak berada di dalam context window saat itu juga, model tidak memiliki cara untuk mengetahui bahwa informasi itu pernah ada, kecuali jika aplikasi pendukungnya secara khusus membangun mekanisme eksternal untuk memasukkan kembali informasi tersebut—sebuah perbedaan yang ternyata sangat krusial.

Hal ini benar-benar berbeda dari cara kerja memori manusia, dan perbedaan ini patut direnungkan sejenak karena dapat menjelaskan banyak hal yang terasa tidak intuitif saat berinteraksi dengan LLM. Manusia yang sedang melakukan percakapan panjang tidak perlu melihat setiap kata dari percakapan itu secara langsung di hadapan mereka untuk mengingat apa yang dibahas satu jam yang lalu—memori manusia bersifat asosiatif, persisten, dan terpisah dari perhatian aktif. Model bahasa sama sekali tidak memiliki penyimpanan memori terpisah seperti itu. Dalam pengertian teknis yang sesungguhnya, keseluruhan "ingatan" model mengenai suatu percakapan hanyalah teks apa pun yang saat itu sedang dimuat ke dalam context window-nya.

Token: Satuan Ukuran Sebenarnya untuk Context Window

Token adalah satuan dasar teks yang diproses oleh model bahasa; satuan ini tidak selalu berpadanan persis dengan kata, karakter, ataupun satuan linguistik intuitif lainnya. Model bahasa menggunakan proses yang disebut tokenisasi untuk memecah teks menjadi satuan-satuan ini sebelum memprosesnya. Proses ini memanfaatkan algoritma (umumnya varian yang disebut byte-pair encoding atau metode serupa) yang telah dilatih untuk menemukan cara efisien dalam merepresentasikan teks sebagai urutan simbol-simbol diskret. Dalam praktiknya, kata umum seperti "the" atau "and" biasanya merupakan satu token tunggal. Kata yang lebih panjang atau jarang digunakan mungkin dipecah menjadi dua atau tiga token—misalnya, kata "tokenization" sendiri bisa saja terbagi menjadi bagian seperti "token" dan "ization". Tanda baca, spasi, dan bahkan bagian dari kata bisa menjadi token tersendiri, bergantung pada tokenizer spesifik yang digunakan oleh model tersebut.

Sebagai pedoman kasar yang umum dikutip untuk teks berbahasa Inggris, satu token setara dengan sekitar empat karakter atau kira-kira tiga perempat kata; artinya, 100 token secara kasar setara dengan 75 kata, dan dokumen sepanjang 1.000 kata secara kasar setara dengan 1.300 token. Rasio ini berubah secara signifikan untuk bahasa lain, kode pemrograman, serta teks dengan format tidak lazim atau teks yang padat dengan kata-kata langka maupun jargon teknis; semua jenis teks ini cenderung memiliki efisiensi tokenisasi yang lebih rendah dibandingkan prosa bahasa Inggris biasa yang umum digunakan. Inilah alasan mengapa ukuran context window yang dinyatakan—misalnya 128.000 token—tidak serta-merta setara dengan jumlah halaman atau kata yang tetap dan universal; jumlah konten nyata yang dapat ditampung sangat bergantung pada karakteristik konten itu sendiri.

Apa Saja yang Sebenarnya Masuk ke Dalam Context Window

System prompt—yaitu instruksi yang ditetapkan oleh developer aplikasi (bukan pengguna akhir) untuk menentukan peran, nada, dan batasan perilaku model—menempati ruang dalam jendela tersebut pada setiap permintaan, meskipun pengguna tidak pernah melihatnya secara langsung. Riwayat percakapan—yaitu setiap pesan sebelumnya dalam obrolan yang sedang berlangsung, baik dari pengguna maupun dari model itu sendiri—juga harus disertakan dalam setiap permintaan berikutnya, karena model sebenarnya tidak memiliki ingatan mandiri mengenai percakapan dari satu pesan ke pesan lainnya; seluruh riwayat harus dikirim ulang secara utuh setiap saat. Dokumen yang diunggah, teks yang di-paste, atau konten yang diambil dan dimasukkan aplikasi ke dalam percakapan juga memakan ruang. Selain itu, definisi dan hasil tool—dalam sistem agen apa pun yang memberikan model akses ke alat atau fungsi eksternal—juga menempati porsi nyata dari jendela yang tersedia, karena model perlu melihat alat apa saja yang tersedia serta hasil yang diberikan alat tersebut saat dipanggil.

Sifat akumulatif inilah alasan mengapa percakapan yang awalnya terasa cepat dan responsif bisa perlahan melambat, menjadi lebih mahal untuk dijalankan, atau mulai kehilangan detail-detail awal seiring berjalannya waktu: riwayat percakapan terus bertambah pada setiap giliran interaksi, dan pada akhirnya akumulasi riwayat tersebut—ditambah dengan system prompt dan konten lain yang disisipkan—mendekati kapasitas total context window model.

Mengapa Context Window Memiliki Batasan?

Pertanyaan yang wajar muncul pada tahap ini adalah mengapa context window memiliki batasan sama sekali—mengapa model bahasa tidak bisa dibuat untuk memproses teks dalam jumlah tak terbatas sekaligus? Jawabannya terletak pada arsitektur khusus yang menjadi landasan hampir semua large language model modern, yaitu transformer, dan secara spesifik mekanisme intinya, yaitu self-attention.

Arsitektur transformer, yang diperkenalkan dalam makalah penting tahun 2017 berjudul "Attention Is All You Need," memproses teks dengan cara membuat setiap token dalam input memberikan perhatian pada—atau dengan kata lain, menghitung hubungan dengan—setiap token lainnya dalam input yang sama. Inilah yang memberikan kemampuan luar biasa bagi transformer untuk memahami ketergantungan jarak jauh dan konteks, yaitu kata ganti di bagian akhir sebuah teks panjang dapat dikaitkan secara langsung dan matematis dengan kata benda spesifik yang dirujuknya di bagian awal, terlepas dari seberapa banyak teks yang memisahkan keduanya. Namun, mekanisme yang sama ini membawa konsekuensi komputasi langsung yang tak terelakkan, yang skalanya bergantung pada jumlah teks yang diproses sekaligus; konsekuensi inilah yang menjadi alasan mendasar mengapa context window memiliki batasan.

Masalah Quadratic Attention

Hubungan matematis spesifik yang menjadi inti dari keterbatasan ini adalah bahwa mekanisme self-attention standar berskala secara kuadratik terhadap panjang urutan input. Jika kita melipatgandakan jumlah token dalam context window, biaya komputasi dan memori yang diperlukan untuk memproses seluruh hubungan berpasangan antar-token tersebut tidak sekadar menjadi dua kali lipat—melainkan meningkat kira-kira empat kali lipat. Hal ini terjadi karena setiap token (yang jumlahnya kini dua kali lebih banyak) harus dibandingkan dengan setiap token lainnya (yang jumlahnya juga dua kali lebih banyak).

Penskalaan kuadratik ini benar-benar merupakan kendala teknis utama yang membentuk sejarah pengembangan context window. Context window sebesar 4.000 token membutuhkan sejumlah komputasi tertentu untuk memproses setiap hubungan berpasangan di dalamnya. Context window sebesar 8.000 token—yang panjangnya hanya dua kali lipat—membutuhkan komputasi sekitar empat kali lebih besar untuk langkah atensi yang sama, bukan sekadar dua kali lipat. Jika hubungan tersebut diterapkan pada context window berukuran 100.000 token atau lebih, kebutuhan komputasi dan memorinya menjadi sangat masif. Inilah alasan mengapa pembuatan model dengan context window yang sangat besar merupakan pencapaian teknis yang signifikan dan sulit diraih, bukan sekadar keputusan perusahaan untuk mengizinkan input yang lebih banyak.

Selama beberapa tahun terakhir, banyak penelitian yang secara khusus difokuskan untuk mengatasi masalah penskalaan kuadratik ini. Berbagai teknik—seperti sparse attention (di mana setiap token hanya memperhatikan sebagian kecil token lain yang dipilih secara cermat, bukan memperhatikan setiap token lainnya), sliding window attention, dan beragam metode aproksimasi atensi yang lebih efisien—telah dikembangkan. Tujuannya adalah agar context window dapat diperbesar tanpa menyebabkan biaya komputasi dasarnya ikut meningkat secara drastis mengikuti laju kuadratik yang berat tersebut. Teknik-teknik ini berperan penting dalam ekspansi dramatis ukuran context window dalam kurun waktu yang relatif singkat.

Apa yang Terjadi Saat Kita Melampaui Batas Context Window

Pada sebagian besar sistem produksi dan implementasi API, melampaui batas context window tidak membuat model tetap membaca dan memproses semua yang kita kirim—meskipun dengan ketelitian atau akurasi yang lebih rendah. Sebaliknya, biasanya salah satu dari dua hal berikut yang terjadi. Banyak API akan langsung memberikan pesan kesalahan eksplisit, menolak permintaan tersebut dan memberi tahu aplikasi pemanggil bahwa input melebihi panjang konteks maksimum model; hal ini mengharuskan aplikasi itu sendiri untuk menangani situasi tersebut—biasanya dengan memangkas atau meringkas konten agar muat sebelum mencoba lagi. Sistem lain, khususnya antarmuka obrolan yang ditujukan bagi pengguna umum, menanganinya dengan cara yang lebih halus namun kurang transparan, yaitu dengan memotong percakapan secara otomatis. Sistem ini secara diam-diam menghapus pesan-pesan paling lama dari awal riwayat percakapan demi memberi ruang bagi konten baru; inilah mekanisme di balik pengalaman umum di mana obrolan yang panjang tiba-tiba tampak "lupa" akan sesuatu yang dibahas jauh sebelumnya dalam percakapan yang sama.

Perlu diperjelas bahwa pemotongan ini—saat terjadi—bukanlah tindakan model yang memilih untuk melupakan sesuatu berdasarkan penilaian internal mengenai apa yang dianggap kurang penting. Ini adalah operasi mekanis yang pada dasarnya dilakukan tanpa mempertimbangkan isi pesan (bersifat "buta" terhadap konten) oleh aplikasi pendukungnya; keputusan diambil semata-mata berdasarkan posisi pesan (biasanya menghapus bagian paling lama dari percakapan) dan bukan berdasarkan penilaian mengenai konten mana yang sebenarnya penting untuk dipertahankan.

Masalah "Lost in the Middle"

Sebuah keterbatasan tersendiri yang benar-benar penting—berbeda dari sekadar melampaui batas maksimum panjang konteks—adalah fenomena terdokumentasi dengan baik yang sering disebut peneliti sebagai "lost in the middle" (hilang di tengah). Bahkan ketika total teks yang kita berikan masih berada dalam batas context window model, kemampuan model untuk benar-benar memanfaatkan informasi yang terletak di bagian tengah konteks tersebut cenderung jauh lebih buruk dibandingkan kemampuannya dalam memanfaatkan informasi yang terletak di bagian awal atau akhir.

Temuan ini—yang didokumentasikan dalam berbagai studi penelitian independen mengenai kinerja model pada tugas-tugas pengambilan informasi spesifik dari konteks yang panjang—memiliki implikasi praktis nyata terhadap cara penyusunan konten saat menggunakan model berkonteks panjang. Ketersediaan context window yang secara teknis besar tidak menjamin bahwa model akan memanfaatkan segala sesuatu yang kita masukkan secara efektif dan merata; kepadatan informasi serta posisinya di dalam jendela tersebut sangat memengaruhi seberapa andal model dalam mengambil dan menalar fakta-fakta spesifik yang terkubur di tengah banyaknya teks pendukung. Inilah alasan mengapa panduan praktis penggunaan prompt berkonteks panjang sering menyarankan agar informasi paling krusial—seperti instruksi utama, pertanyaan spesifik, dan fakta terpenting—ditempatkan di bagian awal atau akhir prompt, alih-alih berasumsi bahwa model akan memberikan perhatian dan tingkat keandalan yang sama pada setiap posisi di dalam jendela konteksnya.

Perkembangan Ukuran Context Window dari Waktu ke Waktu

Model bahasa awal yang banyak digunakan, termasuk versi awal GPT-3, beroperasi dengan context window di kisaran 2.000 hingga 4.000 token—jumlah yang cukup untuk percakapan yang cukup panjang atau dokumen singkat, namun sangat membatasi untuk tugas yang melibatkan materi sumber yang lebih panjang. Seiring kemajuan bidang ini, ukuran context window meningkat menjadi 8.000, lalu 32.000 token, sehingga memungkinkan penggunaan yang jauh lebih canggih, seperti menganalisis dokumen panjang secara utuh atau mempertahankan percakapan yang jauh lebih panjang tanpa kehilangan konteks awal. Model-model mutakhir terkini telah melangkah jauh lebih jauh lagi; context window-nya kini umum mencapai ratusan ribu token, bahkan beberapa model khusus menawarkan context window hingga jutaan token—skala yang secara prinsip mampu menampung satu novel panjang, codebase yang besar, atau transkrip audio berdurasi berjam-jam dalam satu context window.

Pertumbuhan pesat ini mencerminkan kemajuan nyata di berbagai aspek secara bersamaan, yaitu mekanisme atensi yang lebih efisien untuk mengurangi beban praktis dari masalah penskalaan kuadratik yang telah disebutkan sebelumnya; perangkat keras dan infrastruktur khusus yang dioptimalkan untuk kebutuhan memori dalam memproses urutan data yang sangat panjang; serta inovasi arsitektur yang memungkinkan model mempertahankan kinerja yang cukup baik pada tugas-tugas konteks panjang, terlepas dari kecenderungan "hilang di tengah" yang telah dijelaskan tadi. Namun, kita perlu menyikapi kemajuan ini secara proporsional: angka context window yang lebih besar tidak secara otomatis berarti model memanfaatkan setiap token di dalam jendela tersebut secara efektif dan merata. Oleh karena itu, untuk mengevaluasi kinerja model dalam menangani konteks panjang secara akurat, kita tidak bisa hanya berpatokan pada angka panjang konteks yang dipublikasikan.

Context Window vs. Memori: Perbedaan yang Krusial

Context window bukanlah memori dalam artian penyimpanan yang bersifat permanen atau berkelanjutan. Ini adalah ruang pemrosesan sementara untuk setiap permintaan yang hanya ada selama proses pembuatan satu respons, dan isinya terbatas pada teks yang secara eksplisit disertakan dalam permintaan spesifik tersebut. Ketika percakapan berakhir—baik saat kita menutup jendela obrolan, memulai percakapan baru, atau sesi aplikasi berakhir karena habisnya batas waktu—apa pun yang ada di dalam context window tersebut akan benar-benar hilang dari sudut pandang model, tanpa meninggalkan jejak apa pun di dalam model itu sendiri. Model tersebut tidak mempelajari apa pun dari percakapan itu, tidak memperbarui parameter internalnya berdasarkan percakapan tersebut, dan tidak memiliki cara untuk memanggil kembali informasi apa pun di percakapan terpisah di masa mendatang, kecuali jika aplikasi pendukungnya secara khusus dan sengaja menyimpan serta memasukkan kembali informasi tersebut nantinya.

Hal ini sangat kontras dengan sistem yang dirancang khusus untuk menyediakan sesuatu yang lebih mendekati memori permanen yang sesungguhnya. Misalnya, fitur pada beberapa aplikasi obrolan yang mengingat preferensi pengguna di berbagai percakapan terpisah bukanlah bukti bahwa model bahasa dasarnya memiliki kemampuan memori bawaan. Fitur-fitur tersebut merupakan bukti adanya sistem terpisah yang dirancang secara sengaja untuk bekerja berdampingan dengan model, yaitu informasi diekstraksi dari percakapan, disimpan dalam basis data eksternal, lalu secara eksplisit diambil dan dimasukkan kembali ke dalam context window saat percakapan baru dimulai. Hal ini menciptakan kesan adanya memori melalui mekanisme yang sepenuhnya eksternal, bukan melalui kemampuan penyimpanan permanen yang sesungguhnya di dalam model itu sendiri. Memahami perbedaan ini dengan jelas dapat mencegah kesalahpahaman umum yang berdampak besar, yaitu model itu sendiri tidak mengingat apa pun di antara sesi-sesi yang terpisah, kecuali jika ada sistem pendukung yang secara khusus dan sengaja dibangun untuk menyimulasikan kesinambungan tersebut bagi model itu.

Cara Retrieval-Augmented Generation (RAG) Mengatasi Batasan Tersebut

Mengingat bahwa context window memiliki kapasitas terbatas, dan upaya sekadar memperbesarnya akan terbentur pada kendala komputasi nyata yang telah dijelaskan sebelumnya, bidang ini telah mengembangkan serangkaian teknik yang dirancang khusus agar model bahasa dapat bekerja secara efektif dengan informasi yang jauh lebih banyak daripada yang dapat dimuat secara langsung ke dalam context window-nya sekaligus. Teknik yang paling banyak diadopsi di antaranya adalah retrieval-augmented generation, yang secara umum disingkat sebagai RAG.

Alih-alih mencoba memasukkan seluruh basis pengetahuan—yang bisa mencakup ribuan atau jutaan dokumen—secara langsung ke dalam satu context window, sistem RAG mengelola basis pengetahuan tersebut secara terpisah; biasanya, data diubah menjadi representasi vektor numerik dan disimpan dalam database vektor khusus. Saat pengguna mengajukan pertanyaan, sistem terlebih dahulu mencari konten spesifik yang paling relevan dengan pertanyaan tersebut di dalam basis pengetahuan eksternal ini. Hanya potongan informasi yang relevan dan spesifik itulah—bukan keseluruhan basis pengetahuan—yang kemudian dimasukkan ke dalam context window model bersamaan dengan pertanyaan pengguna. Model kemudian menghasilkan respons berdasarkan kumpulan potongan informasi relevan yang telah dikurasi secara khusus dan berukuran relatif kecil ini, tanpa perlu memuat seluruh basis pengetahuan ke dalam context window-nya sekaligus.

Pendekatan ini secara efektif memisahkan total jumlah pengetahuan yang dapat diakses sistem dari ukuran tetap context window model individu; basis pengetahuan dasarnya bisa berukuran sangat besar, namun hanya sebagian kecil yang relevan yang benar-benar dimuat ke dalam konteks untuk setiap permintaan tertentu. RAG telah menjadi salah satu pola arsitektur terpenting dan paling banyak diterapkan dalam aplikasi LLM di lingkungan produksi, khususnya karena teknik ini mengatasi keterbatasan context window secara langsung dan praktis, alih-alih sekadar menunggu kapasitas context window itu sendiri terus bertambah tanpa batas.

Teknik Lain untuk Mengelola Konteks Panjang

Selain RAG, muncul beberapa teknik pelengkap lainnya yang secara khusus membantu mengatasi kendala praktis dari context window yang terbatas; masing-masing teknik menangani aspek yang sedikit berbeda dari masalah dasar yang sama.

Peringkasan percakapan (conversation summarization) mengatasi masalah spesifik di mana percakapan yang berlangsung lama perlahan menghabiskan seluruh kapasitas context window akibat akumulasi riwayat pesan. Alih-alih menyimpan teks lengkap dan persis sama (verbatim) dari setiap pesan sebelumnya tanpa batas waktu, sistem dapat secara berkala membuat ringkasan padat dari bagian awal percakapan. Ringkasan yang jauh lebih singkat ini menggantikan teks asli yang lengkap namun tetap mempertahankan informasi penting yang mungkin masih perlu diketahui oleh model, sehingga membebaskan lebih banyak ruang dalam context window untuk kelanjutan percakapan yang aktif.

Pendekatan sliding window mengelola konteks panjang dengan sengaja hanya menyimpan bagian terbaru dari percakapan atau dokumen secara rinci, serta membuang atau meringkas konten lama seiring masuknya konten baru. Secara konseptual, teknik ini mirip dengan cara mekanisme atensi sliding window (yang disebutkan sebelumnya) mengatasi masalah penskalaan komputasi dasar, namun diterapkan di sini pada tingkat desain percakapan dan aplikasi secara keseluruhan, bukan jauh di dalam arsitektur internal model itu sendiri.

Strategi hierarkis dan pemecahan menjadi bagian-bagian kecil (chunking)—yang sering digunakan khusus untuk menangani dokumen tunggal yang sangat panjang—melibatkan pemecahan dokumen besar menjadi segmen-segmen yang lebih kecil dan mudah dikelola. Setiap segmen diproses atau diringkas secara individual, kemudian hasilnya digabungkan menjadi representasi akhir yang lebih ringkas agar dapat lebih leluasa dimuat dalam satu context window. Pendekatan ini secara konseptual terkait dengan strategi chunking pada RAG, namun diterapkan untuk memproses satu dokumen spesifik secara menyeluruh, alih-alih melakukan pencarian di basis pengetahuan eksternal yang besar dan bersifat umum.

Sistem memori eksternal dan memori berbasis agen—bidang pengembangan yang semakin penting dan aktif saat ini—memberikan sistem AI penyimpanan informasi eksternal yang persisten (diimplementasikan melalui kerangka kerja manajemen memori khusus dalam arsitektur agen yang lebih canggih). Informasi ini dapat dikueri dan diambil secara selektif sesuai kebutuhan; fungsinya secara konseptual mirip dengan RAG, namun secara khusus berorientasi pada akumulasi pengalaman dan fakta-fakta spesifik yang dipelajari oleh agen itu sendiri, bukan pada basis pengetahuan statis umum yang sudah ada sebelumnya.

Jadi, pada dasarnya, context window merupakan keseluruhan cakupan kesadaran kerja sesaat sebuah model—yaitu semesta teks yang lengkap dan terbatas yang benar-benar dapat dipertimbangkan oleh model pada satu titik waktu tertentu saat menghasilkan respons, yang dibatasi oleh kendala komputasi nyata dari mekanisme attention yang mendasari arsitektur transformer. Memahaminya dengan jelas berarti memahami beberapa hal secara bersamaan, yaitu bahwa ukurannya diukur dalam satuan token dan bukan kata; bahwa segala sesuatu, mulai dari system prompt hingga riwayat percakapan, saling berebut ruang di dalamnya; bahwa ukurannya secara mendasar dibatasi oleh biaya penskalaan kuadratik dari mekanisme self-attention; bahwa melampaui batas tersebut akan memicu kegagalan nyata yang terkadang tak terduga; serta bahwa context window yang secara teknis berukuran besar sekalipun tidak menjamin pemanfaatan yang andal dan konsisten atas semua informasi yang ditempatkan di dalamnya.