Simurg Okulu #2 — Token ve context window, model bir seferde ne kadar metni aklında tutabiliyor?
Talep Vadisi'nin ikinci durağı: model metni token'lara bölerek okuyor ve bir yanıt üretirken yalnızca context window'una sığan kadarını görebiliyor. Pencere dolunca eski kısımlar ya kesiliyor ya da özetleniyor; uzun metnin ortasındaki bilgi de her zaman eşit dikkat görmüyor.
Yol günlüğü
Talep Vadisi'nde ikinci akşam. İlk bölümde modelin kelimeleri değil token'ları gördüğünü öğrenmiştim ve heybeme bir soru koymuştum: Türkçe gibi eklerle uzayan bir dilde bu parçalama nasıl oluyor? Bugün o soruyla birlikte ikinci bir kavrama, modelin "hafızasının" sınırına baktım.
Nedir?
Token, modelin metni okurken kullandığı en küçük birim. Bir tokenizer metni bu parçalara ayırıyor; sık geçen kelimeler tek parça kalırken nadir kelimeler ve uzun ekli yapılar birkaç parçaya bölünüyor.
Context window ise modelin tek bir yanıt üretirken aynı anda bakabildiği metnin tamamı: sistem talimatı, sizin yazdıklarınız, sohbetin önceki mesajları, eklediğiniz dosyalar ve modelin o an yazdığı cevap. Bu sınır token cinsinden ölçülüyor. Model bu pencerenin dışındaki hiçbir şeyi "hatırlamıyor"; her yanıt, pencerede o an ne varsa ona bakılarak üretiliyor.
Nasıl çalışıyor?
Sohbet uzadıkça her yeni mesaj pencereye ekleniyor. Pencere dolduğunda uygulamanın bir şey yapması gerekiyor: ya en eski mesajları dışarıda bırakıyor, ya önceki konuşmayı kısa bir özete dönüştürüyor ya da daha fazla girdi kabul etmiyor. Hangisinin yapıldığı modele değil, kullandığınız ürüne bağlı. "Model az önce söylediğimi unuttu" hissinin bir kısmı buradan geliyor.
Pencerenin büyük olması her şeyin eşit görüldüğü anlamına da gelmiyor. Liu ve arkadaşlarının 2023'te yayımladığı Lost in the Middle çalışması, uzun girdilerde aranan bilgi metnin başında ya da sonundayken modellerin daha iyi sonuç verdiğini, bilgi ortaya düştüğünde başarının belirgin şekilde azaldığını gösterdi. Yani uzun bir belgeyi yapıştırıp "şunu bul" demek, belgenin neresinde olduğuna göre farklı sonuç verebiliyor.
Türkçe sorusuna gelince: Tokenizer'lar ağırlıklı olarak eğitim verisindeki sık kalıplara göre kuruluyor. Eğitim verisinde daha az temsil edilen dillerde ve ekli yapılarda aynı anlam genellikle daha fazla token'a bölünüyor. Bu da aynı pencereye daha az Türkçe metin sığması ve token başına ücretlendirilen API'lerde aynı iş için daha fazla token harcanması demek. Kalite üzerindeki etkisini ise kesin bir rakamla söyleyemem; bunu ölçen kaynaklı bir çalışma bulduğumda ayrıca yazacağım.
Ne yapılabilir?
- Uzun sohbetlerde konu değiştiyse yeni sohbet açmak, eski ve alakasız mesajların pencereyi doldurmasını önler.
- Önemli talimatı mesajın başında ya da sonunda, kısa ve açık yazmak; uzun bir belgenin ortasına gömmemek.
- Bir belgenin tamamı yerine ilgili bölümünü vermek hem daha az token harcar hem de ortada kaybolma riskini azaltır.
- Merak edenler, OpenAI'ın herkese açık Tokenizer sayfasında bir Türkçe ve bir İngilizce cümlenin kaç parçaya bölündüğünü kendi gözleriyle karşılaştırabilir. Farklı modellerin tokenizer'ları farklıdır; sonuç yalnızca o araç için geçerli.
Tüyü yaktım
Bir modele "gidemeyeceklermiş" kelimesinin kaç token olduğunu sordum. Bir sayı verdi ama ardından kendi token'larını doğrudan göremediğini, bunun bir tahmin olduğunu ve kesin sonuç için tokenizer aracı kullanmam gerektiğini ekledi. Dürüst bir cevaptı ve bana ilk bölümdeki dersi hatırlattı: Model kendisi hakkında da tahmin yürütüyor, ölçmüyor. Sayıyı bilmek istiyorsam ölçen aracı kullanmalıyım.
Kafama takılan
Pencere dolunca eski mesajları özetleyen bir uygulama, o özette neyi atacağına nasıl karar veriyor? Ve benim önemli bulduğum bir ayrıntı özetten düşerse bunu nasıl fark ederim?
Son söz
Bir sonraki bölümde model aileleri durağına geçiyorum: Aynı şirketin büyük, orta ve küçük modelleri arasındaki fark ne, hangi işte hangisini seçmek mantıklı?