Di episode #47 kita membongkar Transformer dari dalam: attention multi-head dan positional encoding. Kali ini saya mundur satu langkah lebih awal, ke bagian yang paling sering disepelekan tapi menentukan segalanya — tokenisasi dan context window. Ini yang saya catat setelah iseng menghitung token teks Indonesia dibanding teks Inggris, dan hasilnya cukup bikin saya mikir dua kali sebelum “menyisipkan seluruh basis data” ke prompt.
Token itu apa, dan kenapa model tidak membaca karakter
LLM tidak membaca huruf, tidak juga membaca kata. Model membaca token — potongan teks yang sudah dipotong oleh tokenizer sebelum training. Kenapa tidak huruf saja? Kalau per unit-nya karakter, urutan “makan” jadi 5 langkah prediksi dan konteks yang harus diingat jadi panjang sekali. Kalau per kata, kosakata meledak (ratusan ribu bentuk kata, belum termasuk nama orang dan istilah teknis). Token adalah kompromi di tengah: unit seukuran setengah sampai satu setengah kata.
Cara paling umum membangun kamus token adalah Byte-Pair Encoding (BPE). Idenya sederhana sekali, mirip kompresi: mulai dari level karakter, hitung pasangan byte mana yang paling sering berdampingan di korpus, gabungkan pasangan itu jadi satu simbol baru, ulangi ribuan kali sampai kamus terisi puluhan ribu simbol. Analogi untuk programmer: ini seperti merumuskan shortcut dari pola yang paling sering muncul di log — “error 404” lebih efisien disimpan sebagai satu entri daripada dipotong per karakter.
Ilustrasi BPE pada korpus sederhana: korpus : "low lower newest wider new" iterasi 1: pasangan "e"+"r" paling sering -> jadi simbol "er" iterasi 2: pasangan "n"+"ew" sering -> jadi simbol "new" iterasi 3: dst. sampai ukuran kamus tercapai kamus akhir: [l, o, w, low, er, new, est, wider, ...]
Kenapa AI “salah hitung”
Pernah minta LLM menghitung huruf dalam suatu kata, dan jawabannya salah? Sekarang saya tahu penyebabnya. Model tidak melihat huruf “l” di kata “level” — ia melihat token yang mewakili potongan kata itu. Hitungan karakter bagi model bukan hitungan, melainkan tebakan statistik dari representasi token-nya. Sama seperti programmer yang ditanya “berapa karakter string ini” padahal ia cuma tahu panjang array token-nya.
Implikasi praktis yang paling penting bagi saya: jumlah token untuk isi yang setara bisa jauh berbeda antar bahasa. Teks Inggris umumnya ±1,3 token per kata. Teks Indonesia — dengan melekatnya imbuhan meN-, peN-, ber-, ter- — sering lebih boros karena bentuk kata yang jarang muncul di korpus training dipotong jadi lebih banyak subword. Belum lagi emoji, spasi ganda, dan format JSON yang tag-nya ikut makan token. Ketika menghitung biaya produksi di episode #43, detail inilah yang membuat estimasi meleset kalau cuma pakai rumus kasar “1.000 kata = 750 token”.
Context window: dari ribuan ke jutaan token
Context window adalah jumlah token maksimum yang bisa dibaca model dalam satu kali permintaan — mencakup prompt Anda dan jawaban model. Perkembangannya dalam tiga tahun terakhir sungguh cepat (data per pertengahan 2026):
| Model | Context window | Catatan |
|---|---|---|
| GPT-4.1 (OpenAI) | ±1 juta token (1.047.576) | workhorse long-context OpenAI |
| Claude Sonnet 4.6 (Anthropic) | 200 ribu token | disiplin, fokus kualitas per token |
| Gemini 3.x (Google) | 1 juta token | Pro, Flash, sampai Flash-Lite window sama |
| Model legacy / ringan | 8k–128k token | masih umum di banyak provider |
Angka 1 juta token itu kira-kira 750.000 kata — satu buku setebal 1.500 halaman, atau ±30.000 baris kode, masuk dalam satu prompt. Tapi saya belajar untuk tidak terpana angka pemasaran begitu saja. Ada tiga tradeoff yang jarang dibahas di halaman landing:
- Biaya naik seiring panjang konteks. Token input dibayar per token. Menempel 500 ribu token di setiap permintaan = tagihan membengkak walau jawabannya cuma dua kalimat.
- Latensi dan KV cache. Semakin panjang konteks, semakin besar memori KV cache yang harus dipegang server, dan semakin lama waktu sampai token pertama muncul. Ini bagian dari biaya tersembunyi yang pernah saya bahas di #43.
- “Lost in the middle”. Penelitian menunjukkan model paling andal menangkap informasi di awal dan akhir konteks; informasi di tengah dokumen sangat panjang bisa terlewat. Context 1 juta token tidak berarti model “membaca” semua isi dengan seragam.
Praktik yang saya ambil
Pertama, hitung token sungguhan sebelum memasang anggaran — bukan sekadar menghitung kata. Kedua, jangan jadikan context window besar sebagai alasan untuk menempel seluruh basis data ke prompt; cara yang lebih sehat tetap penyaringan (RAG, dibahas menyusul di #54) plus kompresi konteks. Ketiga, saat menguji “apakah model salah hitung”, selalu cek dulu tokenizer-nya: bisa jadi yang salah bukan modelnya, tapi asumsi kita soal bagaimana teks itu dipotong.
Inti catatan ini: token adalah mata uang dunia AI — dan seperti mata uang, kita perlu tahu nilai tukarnya per bahasa sebelum berbelanja.
Sumber
- Byte pair encoding — Wikipedia — asal-usul algoritma BPE dan pemakaiannya di tokenizer GPT/LLaMA.
- OpenAI — Tokenizer & text usage docs — tokenizer o200k dan token counter resmi.
- Google DeepMind — Gemini long context (2025) — context window 1–2 juta token dan latensi terkait.
- DataCamp — Gemini 2.5 Pro: context window & benchmark (diakses Okt 2026) — perbandingan context GPT-4.1, Claude, DeepSeek R1, Grok.
- Liu et al., “Lost in the Middle” (arXiv:2307.03172) — bukti penurunan akurasi pada posisi tengah konteks panjang.
- Sennrich et al., “Neural Machine Translation of Rare Words with Subword Units” (arXiv:1508.07909) — penerapan BPE modern pada model bahasa.
Komentar Terbaru