Bağlam Penceresi Nasıl Yönetilir: Bütçe, Özetleme ve Seçim Stratejileri

Bağlam penceresi bir bütçedir

Bir büyük dil modeli, tek bir istekte işleyebileceği metin miktarıyla sınırlıdır. Bu sınıra bağlam penceresi denir ve token cinsinden ölçülür. Pencere yalnızca sizin yazdığınız girdiyi değil, modelin üreteceği yanıtı da kapsar. Girdi pencereyi doldurursa yanıta yer kalmaz ya da istek reddedilir.

Bu yüzden bağlam yönetimi bir bütçe yönetimidir. Her isteğin penceresi şu kalemlerden oluşur: sistem talimatı, araç ve işlev tanımları, konuşma geçmişi, aranıp getirilen belge parçaları, kullanıcının son mesajı ve yanıt için ayrılan pay. Bu kalemlerden biri büyüdüğünde diğerleri küçülmek zorundadır. Yönetim, hangi bilginin pencerede kalacağına bilinçli karar vermektir.

Önce ölçün

Bağlamı yönetmenin ilk adımı, bütçenin nereye gittiğini görmektir. Modelin kendi tokenizer'ı ile (sağlayıcının sunduğu sayım aracı ya da kütüphane) her kalemin token sayısını ölçün ve istek bazında kaydedin. Karakter ya da kelime sayısı tahmini yanıltıcıdır; Türkçe gibi eklemeli dillerde aynı metin başka dillere göre daha fazla token tutabilir.

Ölçüm panosunda şunlara bakın: ortalama ve en kötü durumda istek boyutu, hangi kalemin payının büyük olduğu, pencereyi aşan isteklerin sıklığı, yanıtın kesilme oranı. Sorun sıklıkla beklenmedik bir kalemdedir: uzun bir araç çıktısı, hiç temizlenmeyen konuşma geçmişi ya da gereğinden fazla getirilen belge parçası.

Sınırlara göre uyarı eşiği koyun: pencerenin belirli bir kısmı dolduğunda sistem özetleme ya da kırpma kararını otomatik almalıdır.

Temel stratejiler

Pencere dolmaya başladığında kullanılan stratejiler birbirini tamamlar.

• Kırpma. En eski mesajları ya da en düşük öncelikli parçaları atmak. Basit ve ucuzdur ama bilgi kaybeder; talimatları ve kritik bilgileri her zaman korumak gerekir.
• Özetleme. Eski konuşmayı kısa bir özetle değiştirmek. Özet bir kez üretilir, sonraki isteklerde geçmişin yerine kullanılır. Özetin hangi bilgileri saklayacağı (karar, tercih, açık görev) istemde tarif edilmelidir.
• Seçme. Her istekte yalnızca gereken bilgiyi getirmek. Belgeler parçalanır, ilgili parçalar arama ile bulunur ve isteğe eklenir (retrieval). Bütün belgeyi pencereye koymak yerine soruyla ilgili kısmı koyarsınız.
• Dışarı alma. Uzun süreli bilgiyi pencerede tutmak yerine harici bir hafızaya (veritabanı, notlar) yazıp gerektiğinde geri okumak.

Pratikte bu stratejiler birlikte kullanılır: sistem talimatı sabit kalır, yakın geçmiş olduğu gibi tutulur, eski geçmiş özetlenir, bilgi tabanından gelen parçalar soruya göre seçilir.

Örnek akış: bağlamı kurmak

Aşağıdaki sözde kod, sabit bir bütçeyle bağlam kurmanın mantığını gösterir.

def baglam_kur(sistem, ozet, gecmis, kullanici_mesaji, butce, yanit_payi): kullanilabilir = butce - yanit_payi kullanilabilir -= token_say(sistem) + token_say(kullanici_mesaji)

secilen_parcalar = ara(kullanici_mesaji, en_fazla=kullanilabilir // dilim_payi) kullanilabilir -= token_say(secilen_parcalar)

yakin = deque() for mesaj in reversed(gecmis): if token_say(mesaj) > kullanilabilir: break yakin.appendleft(mesaj) kullanilabilir -= token_say(mesaj)

return [sistem, ozet, secilen_parcalar, *yakin, kullanici_mesaji]

Önce sabit kalemler ve yanıt payı düşülür, sonra kalan alan arama sonuçlarına ve yakın mesajlara paylaştırılır. Yakın mesajlar sondan başa doğru eklenir; sığmayan eski mesajlar atılır ve özetle temsil edilir. Gerçek uygulamada özetin güncellenmesi, parçaların yeniden sıralanması ve araç çıktılarının ayrıca kırpılması gibi adımlar da eklenir.

Uzun belgelerle çalışmak

Uzun bir sözleşme, rapor ya da kod tabanı tek istekte sığmayabilir. Yaygın desenler şunlardır.

Parçalayıp birleştirme: belge bölümlere ayrılır, her bölüm ayrı işlenir (özet, çıkarım, soru cevaplama) ve sonuçlar birleştirilir. Hiyerarşik özet: bölüm özetleri bir üst özette toplanır, böylece belgenin genel resmi ve ayrıntı katmanları ayrı tutulur. Soruya göre getirme: kullanıcı bir soru sorduğunda yalnızca ilgili parçalar bulunup isteğe eklenir; hangi parçanın hangi bölümden geldiği atıf için saklanır.

Bütün belge pencereye sığıyor olsa bile yüklemek her zaman en iyi seçenek değildir. Daha uzun girdi daha fazla maliyet ve gecikme demektir, ayrıca uzun bağlamlarda modelin her bilgiyi eşit güvenilirlikte kullanmayabileceği gözlemlenmiştir. Bilgiyi ilgili olana göre seçmek ve önemli talimatı bağlamın başına ya da sonuna yakın yerleştirmek makul bir önlemdir; bunun etkisini kendi veriniz ve modelinizle ölçün.

Sistem talimatı ve araç tanımları

Her istekte tekrar eden sabit içerik, bütçeyi sürekli tüketir. Sistem talimatını kısa ve net tutun; aynı kuralı birkaç yerde tekrar etmeyin. Araç ya da işlev tanımları da bağlama girer; çok sayıda araç tanımlamak, her istekte büyük bir sabit yük bindirir. Bir göreve gerçekten gereken araçları seçip yalnızca onları gönderin.

Araç çıktılarını doğrudan geri vermeyin. Bir arama aracının ham sonucu çok uzun olabilir; kısaltılmış, alan seçilmiş bir biçim bağlamı korur. Sağlayıcılar tekrar eden sabit öneklerin maliyetini ve gecikmesini azaltan önbellekleme seçenekleri sunabilir; kullandığınız sağlayıcının güncel dokümantasyonundan kontrol edin.

Sık yapılan hatalar

Bağlam sorunları sessiz biçimde kaliteyi düşürdüğü için gözden kaçar.

• Geçmişi hiç budamamak ve pencerenin dolmasını beklemek. Hata gelene kadar süreç işler görünür, sonra beklenmedik anda çöker.
• Yanıt payını ayırmamak; modelin yanıtı ortada kesilir.
• Özet üretirken kritik kararları ve kullanıcı tercihlerini atlamak.
• Arama sonuçlarının hepsini körlemesine eklemek. İlgisiz parçalar modeli yanıltabilir.
• Talimatları kırpılan kısımda bırakmak. Kritik kurallar her zaman korunan alanda olmalıdır.
• Ölçmemek: sorunu "model kötü" diye yorumlayıp bağlam kurulumunu hiç incelememek.

Bağlam sorunlarını ayıklamak için sorunlu yanıtın gerçekte modele gönderilen tam girdisini kaydedin ve okuyun; cevap sıklıkla oradadır.

Mindset programlarında nerede çalışılır?

LLM Uygulamalarında Bağlam Penceresi Yönetimi eğitimi Bağlam Bütçesi ve Ölçüm, Sıkıştırma ve Seçim Stratejileri ile Uzun Belge Desenleri ve Uygulama modüllerinden oluşur. LLM tabanlı uygulama geliştiren mühendisler ve ürün ekipleri için uygundur.

OpenAI API ile Kurumsal Uygulama Geliştirme eğitiminin Maliyet Yönetimi ve Optimizasyon modülü ise isteğin boyutunun maliyete yansımasını ele alarak bağlam bütçesi konusunu tamamlar. Belge sorgulama ya da müşteri destek asistanı geliştiren kurumsal ekipler programları birlikte değerlendirebilir.