Bağlam Penceresine Sığdırma Rehberi

Barındırılan her büyük dil modelinin, tek bir çağrıda kaç token okuyabileceğine dair sabit bir üst sınırı vardır: bağlam penceresi. Basit bir limit gibi görünür — altında kalın, sorun yok — ama onunla ilgili iki şey, bir API’nin üzerine bir şeyler inşa eden hemen herkesi tökezletir: sayıya gerçekte neyin dahil olduğu ve onu aştığınızda ne olduğu. Belirli bir promptun her büyük modelin penceresine tam olarak nasıl oturduğunu bağlam penceresi görselleştiricisiyle kontrol edebilirsiniz.

Pencereye neler dahildir

Modelin yazmaya başlamadan önce okuduğu her şey sayılır: sistem promptu, çok turlu bir konuşmadaki her önceki tur, modele geçirilen araç ve fonksiyon çağrısı şemaları, bir RAG hattındaki alınan belgeler ve en son kullanıcı mesajı. Bunların hiçbiri isteğe bağlı veya bedava değildir — bir sohbet uygulamasında her çağrıda tekrar gönderilen uzun bir sistem promptu, yaygın ve gözden kaçması kolay bir taşma kaynağıdır, çünkü arayüzde görünmez ama her tek istekte tam olarak yeniden gönderilir.

Çıkış ayrı olarak faturalandırılır ve sınırlandırılır; genellikle bağlam penceresinin kendisinden çok daha küçük kendi üst sınırına sahiptir. Çok büyük bir bağlam penceresi reklam eden bir model, yine de yanıt başına yalnızca mütevazı sayıda token üretebilir — iki rakam farklı soruları yanıtlar ve karıştırılmamalıdır.

Taşmada gerçekte ne olur

Hata modu sağlayıcılar arasında tek tip değildir; bu, üretimde yanlış anlaşılmasının kolay olmasının bir nedenidir:

• Sert red. Belgelenen token limitini aşan doğrudan API çağrılarının çoğu, isteğin token sayısını modelin limitine karşı belirten açık bir hata döndürür. Bu en güvenli hata modudur çünkü gürültülü ve anındadır.
• Sessiz kesme. Bazı istemci sarmalayıcıları ve sohbet arayüzleri, bir sonraki çağrının sığması için konuşma geçmişinden en eski mesajları düşürür; hiçbir şeyin kaldırıldığını göstermeden. Model daha sonra düşürülen bağlamı hiç görmemiş gibi yanıt verir — bu, modelin aslında sessizce kesilmiş talimatları veya gerçekleri “unutması” gibi görünebilir.

Bu iki hata modundan hiçbirini üretimde keşfetmek istemezsiniz. Promptu göndermeden önce pencereye karşı boyutlandırmak — veya kontrolü hattınıza yerleştirmek — daha güvenilir bir alışkanlıktır ve bağlam penceresi görselleştiricisinin yapıştırılan bir prompt için tam olarak yaptığı şey budur: model başına doluluk yüzdesini gösterir ve kullanım yaklaşık %80’i geçtiğinde kırmızıya döner.

Sığmak, iyi okunmakla aynı şey değildir

Pencereye rahatça sığan bir prompt, daha kısa bir promptdan daha kötü yanıtlar üretebilir. Bağımsız uzun bağlam araştırmaları “ortada kaybolma” etkisini belgelemiştir: modeller, tüm prompt token limitinin oldukça altında olsa bile, uzun bir promptun başına veya sonuna yakın yerleştirilen bilgiyi ortasına gömülü bilgiden daha güvenilir biçimde hatırlar. Bu tek bir satıcının modelinde bir hata değildir — mimariler arasında ortaya çıkar ve dikkatin çok uzun dizilerde nasıl bozulduğunun bir özelliğidir.

Pratik çıkarım: “sığıyor mu” ile “model gerçekten iyi kullanacak mı” sorularını ayrı iki soru olarak ele alın. Alım-ağırlıklı iş yükleri için, promptun kenarlarına yerleştirilmiş daha küçük, iyi seçilmiş bir yığın parça, teknik olarak sığan ama önemli pasajı ortada gömen maksimum bir dökümden genellikle daha iyi performans gösterir.

Tam bir tokenizer olmadan token tahmini

Hızlı boyutlandırma için, İngilizce düzyazıda token başına yaklaşık 4 karakter, yoğun kodda ise 3,5 karaktere yakın bir değer plan yapmak için yeterince yakındır — bu sezgisel kural token sayacının ve görselleştiricinin ikisinin de kullandığı yöntemdir. Yayına almadan önce — veya bir maliyet tahminini onaylamadan önce — güvenebileceğiniz bir rakam için aynı metni satıcının kendi tokenizer’ından geçirin, çünkü farklı satıcılar farklı tokenizasyon şemaları kullanır ve tam sayı aynı metin için bile aralarında farklılık gösterir. Token sayısını öğrendikten sonra, LLM maliyet hesaplayıcı bunu çağrı başına bir fiyata dönüştürür.