Kurgusal Bir Sohbet Botu Uzun Bir Konuşmadan Sonra Kurulumunu Neden Unutur? Beş Adımlı Kontrol Kılavuzu
Kurgusal bir karakter sohbet botu birçok turdan sonra kurulumunu takip etmeyi bırakırsa, bu değişiklik tek başına nedenini ortaya koymaz. Unutulan bir ayrıntı; kullanılabilir konuşma bağlamının dışına çıkmış, bir bilgi getirme (retrieval) sisteminden geri dönememiş, bir özette kaybolmuş veya değiştirilmiş, başka bir talimatla çakışmış ya da hiçbir zaman kalıcı bellek olarak kaydedilmemiş olabilir. Olasılıkları daraltmak için zararsız kurgusal ayrıntılarla aşağıdaki beş kontrolü uygulayın. Bunlar kalıpları belirleyebilir; ancak sohbet botunun günlüklerine veya tasarımına erişim olmadan belirli bir uygulamanın nasıl çalıştığını kesin olarak kanıtlayamazlar.
İlk olarak, belirtiyi olası nedeninden ayırın
Sabit kalması gereken ve kontrol edilmesi kolay tek bir ayrıntı seçin. Örneğin: “Kurgusal bir deniz feneri bekçisi olan Mira, pirinç pusulasını yeşil masa çekmecesindedir.” Kontroller boyunca aynı bilgiyi kullanın ve “Çekmece ne renk?” gibi net ve dar kapsamlı bir soru sorun. Kişisel bilgilerden veya testin dışı için önem taşıyan ayrıntılardan kaçının.
İstemi (prompt), verilen yanıtı, yaklaşık konuşma uzunluğunu ve yeni bir sohbet başlatıp başlatmadığınızı tam olarak kaydedin. Başka birine ait bir sohbet botunu test ediyorsanız, yalnızca erişim izniniz olan bir kurulum ve test konuşmasını kullanın. Tek bir yanıtı kesin bir sonuç olarak değerlendirmeyin: üretim değişkenlik gösterebilir ve tek bir hata, bilginin mevcut olup gözden mi kaçırıldığını yoksa modele sağlanan veriler arasında hiç mi yer almadığını göstermez.
Bilimsel araştırmalar, uzun sohbetlerdeki aksaklıkları yorumlarken dikkatli olunması gerektiğini desteklemektedir. Liu ve meslektaşları, bilgi getirme görevlerindeki performansın ilgili ayrıntının uzun bir girdi içindeki konumuna göre değişebildiğini ve genellikle girdinin ortasında yer aldığında zayıfladığını tespit etmiştir. Yaptıkları deneyler kurgusal rol yapmayı veya belirli bir uygulamayı değil, soru yanıtlama ve anahtar-değer getirme işlemlerini incelemektedir. Luz de Araujo ve meslektaşları tarafından yapılan 2026 tarihli bir çalışma ise doğrudan genişletilmiş diyaloglardaki persona sadakatini incelemiş ve değerlendirdikleri modeller genelinde diyalog uzunluğu arttıkça bozulma olduğunu bildirmiştir. Her iki makale de belirli bir sohbet botundaki eksikliğin kesin nedenini belirlememektedir. ([Liu vd., “Lost in the Middle,” 2024](https://aclanthology.org/2024.tacl-1.9/); [De Araujo vd., “Persistent Personas?”, 2026](https://aclanthology.org/2026.eacl-long.246/))
1. Bağlam penceresi sınırını kontrol edin
Mevcut sohbette pusula ve çekmece hakkında soru sorun. Ardından yepyeni bir sohbet başlatın, başlangıçta karakter kurulumunu tekrar sağlayın ve aynı soruyu sorun. Yanıt yeni sohbette doğru çalışıyor ancak eski sohbetin ilerleyen aşamalarında başarısız oluyorsa, uzun bağlam sınırından kaynaklanması muhtemeldir. Sağlanan ayrıntı artık aynı biçimde erişilebilir olmayabilir veya konuşma uzadıkça model bunu kullanmakta zorlanıyor olabilir.
Bu durum, bağlam penceresinin kesin sınırını tam olarak belirlemez. Yeni sohbet diğer koşulları da değiştirir: bilgiyi başlangıca yakın bir yere yerleştirir ve onunla yarışabilecek sonraki talimatları ortadan kaldırır. Bağlam penceresi, bir sistemin tek seferde işleyebileceği konuşma ve diğer girdilerin toplam miktarıdır; sohbetler arasında kaydedilen bellekle mutlaka aynı şey olmak zorunda değildir. Hizmet sağlayıcı sınırlarını açıkça belgelemediği sürece, tek bir hatadan yola çıkarak bir belirteç (token) sayısı çıkarmayın.
2. Bilgi getirme (retrieval) hatasını kontrol edin
Hizmet belgelenmiş bir arama, hatırlama veya konuşma geçmişi özelliği sunuyorsa, kurulum metnini birebir bulup bulamadığını test edin. Desteklenen bir özellikse, sohbet botundan ilgili önceki konuşmadan bu bilgiyi getirmesini de isteyebilirsiniz. Sonucu yeni sohbet taban çizgisiyle karşılaştırın.
Kurulum, erişilebilir bir geçmişte veya bellek kaydında hala mevcut olduğu halde sohbet botu bunu kullanmıyorsa, bilgi getirme veya seçim hatası olası nedenlerden biridir. Bunun yerine bir bağlam konumu etkisi, zayıf bir yanıt veya beklenenden farklı davranan bir özellik de olabilir. O yanıt için modele hangi bilgilerin sağlandığını görmeden bunları kesin olarak birbirinden ayıramazsınız. Yalnızca arayüzde tüm konuşma dökümü görüntüleniyor diye bir sohbet botunun geçmişteki her mesajı aradığını varsaymayın.
3. Eski veya kayıplı bir özeti kontrol edin
Bazı sistemler önceki sıraları daha kısa bir özet halinde yoğunlaştırabilir. Uygulama bu özeti görünür kılıyorsa, özetin hala çekmecenin yeşil ve pusulanın pirinç olduğunu belirtip belirtmediğini inceleyin. Bunun yerine yalnızca Mira'nın “yakınında bir pusula tuttuğunu” söylüyorsa, atlanan renk hakkında dar kapsamlı bir soru sorun ve yanıtı, kurulumunu açıkça sağladığınız sürümle karşılaştırın.
Hatalı veya eksik bir özet, yapılan sıkıştırmanın aktarılan bilgileri değiştirdiği olasılığını destekler. Ancak sizin görebildiğiniz bir özet, sistem tarafından kullanılan özetle aynı olmayabilir ve görünmeyen bir özetin varlığı varsayılamaz. Bu kontrolü, yalnızca ürün ilgili kaydı veya belgeleri gerçekten görünür kıldığında bir kanıt olarak kabul edin.
4. Persona-talimat çakışmasını kontrol edin
Ana gerçeği sabit tutun, ardından bunun nasıl yanıtlanacağını etkileyebilecek sonraki talimatları inceleyin. Kurgusal bir sahne, “Mira bugün kararsızdır ve çekmecenin mavi olduğunu tahmin eder” diyebilir. Bu talimat, çekmecenin yeşil olduğunu söyleyen kurulumla çakışır. Önce tarafsız ve olgusal bir soru, ardından sahne çerçevesinde kurgulanmış bir soru sorun. Sohbet botu farklı yanıtlar veriyorsa, ifade biçimi veya talimat önceliği yanıtı etkiliyor olabilir.
Daha temiz bir test için, kurgusal kurulumun geri kalanını değiştirmeden çakışan bir talimatı kaldırın veya düzenleyin. Eğer bot kuruluma yeniden uymaya başlarsa, talimat çakışması basitçe unutmaktan daha güçlü bir açıklamadır. Bir sohbet botu bir talimatı yanlış anlayabilir veya doğaçlama da yapabilir; düzenlemeden sonra meydana gelen bir değişiklik sistemin dahili öncelik kurallarını ortaya koymaz. Genişletilmiş persona diyalogları üzerine yapılan araştırmalar, persona sadakatinin ve talimat takibinin uzun etkileşimler boyunca değerlendirilebileceğini göstermektedir; ancak belirli bir hizmetin hangi kurala öncelik verdiğini söyleyemez. ([“Persistent Personas?”](https://aclanthology.org/2026.eacl-long.246/))
5. Kalıcı belleğin bunu gerçekten kaydetmek üzere tasarlanıp tasarlanmadığını kontrol edin
Mevcut sohbetteki bir ayrıntı, kaydedilmiş bir karakter profili ve sohbetler arası bellek birbirinden farklı kavramlardır. Ürünün kalıcı karakter bilgisi sunup sunmadığını, kaydetmenin etkinleştirilmesinin veya onaylanmasının gerekip gerekmediğini ve seçilen öğenin konuşmalar arasında taşınmasının amaçlanıp amaçlanmadığını görmek için ürünün kendi ayarlarına veya belgelerine bakın. Yalnızca hizmet ilgili özelliğin orada geçerli olması gerektiğini söylüyorsa test etmek için yeni bir sohbet kullanın.
Ürünün bu tür bir karakter ayrıntısını kaydetmek için belgelenmiş bir yöntemi yoksa, başka bir sohbette bunu hatırlayamaması, kaydedilmiş bir belleğin silindiğinin kanıtı değildir. Böyle bir özelliği varsa, sonuçlara varmadan önce görünür durumdaki kayıtlı girdiyi ve kapsamını kontrol edin. Kaydedilmiş bir not, önceki her mesajın aktif konuşmada kalmasını gerektirmeden “yeşil çekmeceyi” koruyabilir; ancak ürüne özgü bir kanıt olmadan herhangi bir uygulamanın bu şekilde çalıştığını iddia etmeyin.
Yalnızca son cevabı değil, örüntüyü okuyun
Her bir yorumu örüntünün kendisinden daha dar kapsamda tutarak gözlemleri birer ipucu olarak kullanın:
Gözlem: Kurulumun sağlandığı yeni sohbet çalışıyor; eski sohbetin ilerleyen kısımları başarısız oluyor Olası yorum: Uzun bağlam veya konum duyarlılığı Neyi kanıtlamaz: Kesin bir bağlam penceresi kesintisini
Gözlem: Belgelenmiş bir geçmiş veya bellek gerçeğe sahip, ancak yanıt bunu kaçırıyor Olası yorum: Bilgi getirme veya kullanım hatası Neyi kanıtlamaz: Hataya yalnızca bilgi getirmenin neden olduğunu
Gözlem: Açıkta olan bir özet ayrıntıyı atlıyor veya değiştiriyor Olası yorum: Özet kaybı veya değişikliği Neyi kanıtlamaz: Modelin gerçek girdisinin o özeti kullandığını
Gözlem: Çakışan bir sahne talimatını kaldırmak uyumu geri getiriyor Olası yorum: Talimat çakışması veya yorumlama Neyi kanıtlamaz: Uygulamanın dahili talimat hiyerarşisini
Gözlem: Bir ayrıntı yeni bir sohbette yok ve sohbetler arası kaydetme belgelenmemiş Olası yorum: Gösterilmiş kalıcı bir bellek yolu yok Neyi kanıtlamaz: Mevcut belleğin silindiğini
Örtüşen örüntüler nasıl yorumlanmalıdır?
Birden fazla örüntü ortaya çıkarsa, nedenler birbiriyle örtüşebilir. Örneğin, bir özet çekmece rengini atlarken sonraki bir talimat da mavi bir çekmece tanımlayabilir. Her testi küçük tutun, aynı anda yalnızca bir koşulu değiştirin ve karşılaştırmanın yararlı kalması için tam ifadeleri koruyun.
Bu kontrolü ses tonu ve düzeltme davranışından ayrı tutun
Bir karakterin ses tonunun farklı çıkması, belirli bir kurulum gerçeğini unutmaktan ayrı bir belirtidir. Ses tutarlılığı üslup, diksiyon veya tavırla ilgilidir; yukarıdaki kontroller ise somut bir kurgusal ayrıntının mevcut olup olmadığı ve buna uyulup uyulmadığı ile ilgilidir. Bir model veya hizmet güncellemesi üslubu değiştirebilir; ancak hizmet bir değişikliği belgelemediği veya karşılaştırılabilir model bilgisi sağlamadığı sürece, sesteki bir kayma bir güncelleme yapıldığını kanıtlamaz.
Benzer şekilde, bir yanıtta kabul edilen bir düzeltme otomatik olarak kalıcı bir düzeltme anlamına gelmez. Bunu önce aynı sohbette test edin; yeni bir sohbette ise yalnızca ürün düzeltmelerin aktarılması gerektiğini iddia ediyorsa test edin. Karakter “çekmece yeşildir” ifadesine bir kez uyup daha sonra eski haline dönüyorsa, bu durum düzeltmenin kalıcılığını açıklar; tek başına nedenin bağlam mı, bilgi getirme mi, özet mi, talimat çakışması mı yoksa bellek tasarımı mı olduğunu göstermez.
Bir tasarımcı için bu beş durum pratik bir değerlendirme sunar: zararsız bir kurgusal olguyu sabit tutun, konuşma uzunluğunu ve olgunun konumunu çeşitlendirin, uygun olduğunda getirilen notları ve özetleri görünür yapın veya günlüğe kaydedin, kontrollü bir çakışan talimat ekleyin ve olgunun oturumlar arasında kalıcı olmasının beklenip beklenmediğini belirtin. Her testin hangi doğruluk kaynağına dayandığını kaydedin. Bu, bir hatanın yeniden üretilmesini kolaylaştırır ve bir içerik sorununun ürünün hiçbir zaman vaat etmediği bir beklentiden ayırt edilmesine yardımcı olur.
Özenli bir sonuç, kanıtı ve onun sınırlarını açıkça belirtmelidir: “Yeni sohbet karşılaştırması uzun konuşma kaynaklı bir etki olduğunu gösteriyor; ancak ayrıntının kesildiğini mi, getirilmediğini mi yoksa geçersiz mi kılındığını söyleyemem.” Bu yaklaşım, her aksaklığı bir bellek hatası olarak etiketlemekten daha yararlıdır ve uygulamanın arka planı bilinmediğinde daha doğrudur.