Yapay Zeka Asistanım Oturum Ortasında Neden Hantallaştı? MCP Suçlamasından Önce Bağlam Penceresi Analizi

Yapay zeka asistanlarının uzun kodlama oturumlarında yavaş yavaş verimsizleştiğini, kuralları unuttuğunu fark etmişsinizdir. İlk refleksim, sisteme bağlı olan MCP (Model Context Protocol) sunucularını suçlamak oldu. Ancak ezbere hareket etmek yerine asistanın bağlam penceresi (context window) dökümünü inceledim ve şaşırtıcı bir tabloyla karşılaştım: En büyük payı konuşma geçmişi alırken, MCP araç tanımları neredeyse en küçük kısımdı.

Yazılım/Öğrenme Yorumu: Yazılımda da performans sorunlarında ilk şüphelenilen popüler veya yeni kütüphaneler olur; ancak gerçek darboğazı bulmanın tek bilimsel yolu profiling (kod analizi) yapmaktır.

1. Tahmin Etmek Yerine Dökümü İnceledim

Bağlam penceresinin kategorilere göre dökümünü aldığımda, konuşma geçmişinin tüm alanın yaklaşık beşte birini kapladığını gördüm. Sabit başlangıç maliyetleri (sistem yönergeleri, araç şablonları) kararlı bir yük oluşturuyordu. Ancak asıl suçladığım MCP sunucularının kapladığı alan ihmal edilecek kadar küçüktü.

Pratik Çıkarım: Sorun anında en görünür olana odaklanmak bizi yanıltır. Sorunu çözmeye çalışmadan önce veri toplayın.

2. MCP Varsayımı Neden Yarı Yarıya Doğruydu?

MCP'nin bağlam penceresini tükettiği uyarısı tamamen haksız değil. Bazı istemciler tüm araç şemalarını baştan yükler ve bu da ciddi yer kaplar. Ancak benim kullandığım istemcide araç tanımları sadece ihtiyaç duyulduğunda yükleniyordu (lazy loading). Yani genellemeler yerine sistemin çalışma detaylarına bakılmalıdır.

Pratik Çıkarım: Kullandığımız kütüphanelerin ve araçların arka planda nasıl çalıştığını (örneğin lazy loading vs eager loading) bilmek, doğru mimari kararlar vermemizi sağlar.

3. Bağlam Penceresini Gerçekte Ne Dolduruyordu?

Sessizce büyüyen ve alanı tüketen şey konuşma geçmişinin kendisiydi. Yaptığımız her deneme, hata çıktısı ve diyalog üst üste birikmişti. Bu birikim, yapay zekanın o anki problemi çözmesi için gereken akıl yürütme alanını daraltmıştı.

Pratik Çıkarım: Tıpkı kod yazarken kullanılmayan nesneleri bellekten temizlememek (memory leak) gibi, asistanla çalışırken de gereksiz verinin birikmesine izin vermemeliyiz.

4. Şimdi Ne Yapıyorum?

Çözüm adımlarım oldukça pratik ve uygulanabilir hale geldi:

Tek bir keşif oturumunu veya sohbeti sonsuza kadar sürdürmüyorum.
Belirli bir görev bittiğinde temiz bir oturum (yeni sohbet) başlatıyorum.
Süreklilik gerekiyorsa, asistana mevcut durumun bir özetini hazırlatıp sadece bu özeti yeni oturuma taşıyorum.
Pratik Çıkarım: Bağlam penceresi bir arşiv deposu değil, çalışma masasıdır. Masayı temiz tutmak, daha büyük bir masa satın almaktan çok daha verimlidir.

5. Asıl Ders MCP Hakkında Değil

İlk tahminimle hareket edip sunucuları kapatsaydım, sorunu çözemediğim gibi suçu yanlış araca atacaktım. Geliştiriciler olarak sıklıkla karşılaştığımız bu durum, bizi yanlış optimizasyonlara sürükler.

Pratik Çıkarım: Hata ayıklarken (debugging) en karmaşık veya en yeni bileşeni suçlama tuzağından kaçının, her zaman ölçün.

6. Kendime Bir Sonraki Sefer İçin Not

Asistan hantallaştığında tahminde bulunmayı bırak ve dökümü oku. Bugünün sorunu konuşma geçmişiyken, yarınki sorun bellek dosyaları olabilir.

Pratik Çıkarım: Yazılım geliştirme ve öğrenme süreçlerinde kalıplaşmış çözümlere güvenmeyin, her vaka kendi koşullarında analiz edilmelidir.

[Orijinal kaynağa buradan ulaşabilirsiniz.](https://dev.to/rapls/my-ai-agent-got-dumber-mid-session-i-measured-the-context-window-before-blaming-mcp-4c3l)