Token dan Context Window: Cara AI Membaca Teks

Model bahasa AI tidak membaca huruf atau kata. Model membaca token: potongan kecil teks, sering kali satu kata utuh, kadang hanya bagian dari kata. Model juga hanya bisa menerima token dalam jumlah terbatas sekaligus, dan batas itu disebut context window (jendela konteks). Dua ide ini menjelaskan kenapa harga alat AI ditentukan seperti itu, kenapa chat yang panjang mulai melupakan instruksi awal, dan kenapa model bisa kesulitan menghitung huruf dalam kata yang baru saja dieja dengan benar olehnya.

Apa itu token di AI?

Sebelum model melihat prompt-mu, sebuah program bernama tokenizer memecah teksnya menjadi potongan-potongan dari kosakata yang sudah tetap, lalu mengubah setiap potongan menjadi angka. Model bekerja sepenuhnya dengan angka-angka itu, dan menulis balasannya dengan cara yang sama, satu token demi satu token, yang lalu diubah kembali menjadi teks oleh aplikasinya.

Kosakata itu dipelajari dari teks dalam jumlah besar, jadi kata-kata yang umum cenderung menjadi satu token dan kata-kata yang lebih jarang dipecah menjadi beberapa potongan yang sudah dikenal. Spasi sering menempel di awal kata yang mengikutinya. Sebuah kalimat bahasa Inggris mungkin dipecah kira-kira seperti ini:

Token ization isn 't magic .

Pemecahan itu hanya ilustrasi. Setiap keluarga model punya tokenizer sendiri, dan kalimat yang sama bisa menghasilkan jumlah potongan yang berbeda di masing-masing. Banyak penyedia menerbitkan alat tokenizer atau API penghitung token supaya kamu bisa mengecek jumlah yang sebenarnya.

Gambar, audio, dan file juga diubah menjadi token kalau model menerimanya, dan itulah kenapa screenshot yang dilampirkan memakai sebagian anggaran yang sama dengan teksmu.

Berapa token untuk satu kata?

Untuk teks bahasa Inggris, patokan kasar yang banyak dipakai adalah sekitar empat karakter per token, atau kira-kira tiga perempat kata. Dengan perkiraan itu, 1.000 token setara sekitar 750 kata bahasa Inggris, dan artikel 3.000 kata setara sekitar 4.000 token.

Perbandingannya berubah tergantung isinya:

• Bahasa lain sering kali butuh lebih banyak token untuk makna yang sama. Tokenizer dilatih dengan data yang didominasi bahasa Inggris, jadi kata-kata bahasa Inggris mendapat token yang ringkas, sementara teks dalam bahasa Jepang, Korea, Arab, Hindi, dan banyak bahasa lain dipecah menjadi lebih banyak potongan. Selisihnya bergantung pada tokenizer dan sudah menyempit di tokenizer yang lebih baru, tapi belum hilang.
• Kode memakai token untuk indentasi, kurung, operator, dan identifier yang panjang, jadi sebuah file sering kali memakan lebih banyak token daripada yang terlihat dari jumlah katanya.
• Angka, URL, dan string yang tidak biasa seperti ID dan hash cenderung dipecah menjadi banyak token kecil.

Kenapa token penting

Biaya. API mengenakan biaya per token, dengan harga terpisah untuk token yang kamu kirim dan token yang ditulis model. Dalam sebuah chat, seluruh percakapan dikirim ulang bersama setiap pesan baru, jadi percakapan yang panjang lebih mahal per pesan daripada yang pendek.

Batas. Model punya context window untuk semua yang dibaca dan ditulisnya dalam satu permintaan, dan sering kali juga batas terpisah untuk panjang satu balasan. Di API, kamu bisa mengatur batas itu sendiri, dan di API Anthropic kamu wajib mengaturnya: max_tokens adalah parameter yang harus diisi.

Kecepatan. Balasan dihasilkan satu token demi satu token, jadi balasan yang lebih panjang butuh waktu yang sebanding lebih lama untuk selesai.

Tugas mengeja. Karena model melihat kata seperti magic sebagai satu atau dua satuan, bukan lima huruf, tugas yang bergantung pada karakter satu per satu, seperti menghitung huruf, membalik kata, atau mencari kata dengan panjang tertentu, lebih sulit baginya daripada kelihatannya. Model yang lebih baru menangani banyak tugas seperti ini dengan lebih baik, tapi kalau karakternya penting, cek jawabannya atau minta model menuliskan katanya huruf demi huruf lebih dulu.

Apa itu context window?

Context window adalah jumlah token maksimum yang bisa diperhitungkan model dalam satu permintaan. Anggap saja sebagai memori kerja model: semua yang bisa dipakai model untuk menulis balasannya harus muat di dalamnya sekaligus, termasuk:

• prompt sistem, baik instruksi dari aplikasinya maupun instruksimu
• percakapan sejauh ini, setiap pesan pengguna dan setiap balasan
• file yang dilampirkan, dokumen yang ditempel, dan hasil pencarian atau tool
• balasan yang sedang ditulis

Apa pun di luar jendela itu tidak ada bagi model. Tidak ada memori latar yang bisa dibuka model untuk mencari sesuatu. Ukuran context window sangat bervariasi antar model dan terus bertambah, jadi cek dokumentasi penyedia untuk model yang kamu pakai alih-alih mengandalkan angka dari sebuah artikel.

Model juga tidak menyimpan apa pun di antara permintaan. Yang terlihat seperti ingatan dalam chat sebenarnya adalah aplikasi yang mengirim ulang seluruh percakapan setiap kali. Fitur memori di aplikasi chat bekerja dengan cara yang sama: aplikasinya menyimpan catatan tentang dirimu, atau mencari di chat-chat sebelumnya, lalu menyisipkan temuannya ke konteks chat baru.

Apa yang terjadi saat chat jadi panjang

Kalau percakapan melampaui context window, harus ada yang dikorbankan. Tergantung aplikasinya, pesan-pesan terlama dibuang, bagian-bagian lama diganti dengan ringkasan, atau kamu diberi tahu bahwa chat sudah mencapai batasnya dan sebaiknya memulai chat baru. Dalam setiap kasus, detail dari awal, termasuk instruksi yang kamu berikan di pesan pertama, bisa berhenti memengaruhi jawaban.

Jendela yang penuh bukan satu-satunya masalah. Makin banyak materi di depan model, makin banyak yang bisa terlewat, dan dalam chat yang panjang, keputusan-keputusan awal bersaing dengan semua yang dikatakan sesudahnya. Gejalanya antara lain jawaban yang mengabaikan batasan yang kamu tetapkan sebelumnya, kode yang kembali ke versi yang sudah kamu perbaiki, atau model yang mengulang ide yang sudah kamu tolak.

Bekerja di dalam batas context window

Mulai chat baru untuk setiap tugas. Chat baru dengan pesan pertama yang jelas biasanya lebih baik daripada chat panjang yang sudah melantur ke beberapa topik.

Bawa ringkasan ke chat berikutnya. Kalau sebuah chat sudah mengumpulkan keputusan-keputusan yang berguna, minta ringkasan yang ditulis untuk ditempel ke chat baru, lalu lanjutkan di sana. Isi bagian kosong di bawah supaya sesuai dengan pekerjaanmu.

Lanjutkan di chat baru

EditCopy

Fill inartefakkata

Chat ini sudah makin panjang. Tulis ringkasan yang bisa aku tempel ke chat baru untuk melanjutkan pekerjaannya. Sertakan: tujuannya, keputusan yang sudah kita ambil beserta alasannya, versi terbaru dari skema database, dan pertanyaan yang masih terbuka. Ringkasannya harus kurang dari 200 kata, tidak termasuk skema database itu sendiri.

Try it

Example replyReplies vary between models and runs.

Tujuan: database untuk aplikasi perpustakaan kecil, disimpan di SQLite.

Keputusan:

• Peminjaman punya tabel sendiri, jadi seluruh riwayat peminjaman tersimpan.
• Sebuah buku dianggap tersedia kalau tidak punya peminjaman dengan returned_at yang kosong.

Skema saat ini:

CREATE TABLE books (id INTEGER PRIMARY KEY, title TEXT NOT NULL, author TEXT NOT NULL);
CREATE TABLE members (id INTEGER PRIMARY KEY, name TEXT NOT NULL, email TEXT UNIQUE);
CREATE TABLE loans (
  id INTEGER PRIMARY KEY,
  book_id INTEGER NOT NULL REFERENCES books(id),
  member_id INTEGER NOT NULL REFERENCES members(id),
  loaned_at TEXT NOT NULL,
  returned_at TEXT
);

Pertanyaan yang masih terbuka:

• Apakah kita perlu denda keterlambatan?
• Apakah perpustakaan perlu mencatat beberapa eksemplar dari buku yang sama?

Tempel hanya yang dibutuhkan tugasnya. Fungsi yang ada bug-nya dan kode yang memanggilnya, bukan seluruh repository. Bagian kontrak yang dipertanyakan, bukan keempat puluh halamannya. Materi yang lebih sedikit menyisakan lebih sedikit hal yang bisa terlewat.

Taruh pertanyaannya setelah materi yang panjang, dan ulangi hal yang penting. Kalau kamu menempel dokumen yang panjang, ajukan pertanyaanmu di akhir, setelah dokumennya, dan ulangi batasan-batasan utamanya di sana. Dengan begitu instruksinya berada dekat dengan titik di mana model mulai menulis.

Pecah dokumen yang terlalu panjang untuk satu pesan. Beberapa aplikasi membatasi berapa banyak yang bisa kamu tempel dalam satu pesan, meskipun context window model sebenarnya bisa menampung lebih banyak. Mengirim dokumen dalam beberapa bagian bisa menyiasati batas pesan, tapi tidak dengan context window: setiap bagian tetap dihitung di dalamnya. Beri tahu model di awal supaya tidak merespons sampai kamu selesai mengirim semuanya.

Kirim setiap bagianAjukan pertanyaan

EditCopy

Fill intotalpertanyaan

Aku akan mengirim dokumen panjang kepadamu dalam 3 bagian. Setelah setiap bagian, balas hanya dengan "Bagian N dari 3 diterima" dan tidak ada yang lain. Jangan meringkas atau menjawab apa pun sampai aku mengajukan pertanyaanku. Bagian 1 dari 3: """ [tempel bagian 1] """

Try it

Example replyReplies vary between models and runs.

Bagian 1 dari 3 diterima

Hitung token kalau itu penting. Kalau kamu membangun sesuatu dengan API, hitung dulu sebelum mengirim. Library open source tiktoken dari OpenAI memecah teks menjadi token dengan tokenizer milik OpenAI, dan API Anthropic punya endpoint untuk menghitung token. Hitungan dari tokenizer satu penyedia hanya perkiraan untuk tokenizer penyedia lain.

import tiktoken

enc = tiktoken.get_encoding("o200k_base")  # one of OpenAI's tokenizers
tokens = enc.encode("Tokenization isn't magic.")
print(len(tokens))
print([enc.decode([t]) for t in tokens])

Saat kamu membangun aplikasi di sekitar sebuah model, menentukan apa yang masuk ke jendela konteks dan dalam urutan apa menjadi masalah desain tersendiri. Context engineering membahas hal itu, dan prompt chaining menunjukkan cara memecah pekerjaan besar menjadi langkah-langkah yang masing-masing muat dengan nyaman. Untuk melihat bagaimana satu pesan masuk ke dalam seluruh input, lihat apa itu prompt.