Yapay zekâ tarafında yıllardır aynı şeyi yapıyoruz: modele daha çok veri ver, daha iyi cevap versin. Kulağa mantıklı geliyor. Ama asıl sıkıntı başka bir yerde duruyor — sistemler çoğu zaman bir soruyu gayet güzel yanıtlıyor, sonra ertesi dakika aynı şey tekrar geldiğinde sanki hayatında hiç görmemiş gibi davranıyor. İşte tam burada hafıza meselesi devreye girmesi gerekiyor… ya da çoğu ürünün bir türlü yapamadığı şey, lafı doğrudan söylersem.
Geçen ay İstanbul’da küçük bir SaaS ekibiyle oturmuştuk. Eh, görüşme diyeyim ama aslında daha çok şikayet seansıydı. Destek botları gayet düzgün çalışıyordu; kontrol listesi veriyor, log istemeyi biliyor, hatta nazik konuşuyordu. Ama aynı hata üçüncü kez geldiğinde sistem yine aynı cevabı dönüyordu, hiç sıkılmadan, hiç farketmeden. “Bu bot destekçi değil, hafıza balığı” dedim içimden o an. Çünkü tekrar eden sorunlar sadece mesaj değil — sinyal de taşır, bence oldukça önemli bir sinyal.
Benim bu yazıda asıl dikkatimi çeken şey buydu zaten. Mesele modelin ne kadar akıllı olduğu değil, zaman içinde olan biteni hatırlayıp hatırlamaması. Tek kareye bakınca resim güzel görünüyor ama film başlayınca iş tamamen değişiyor.
Neden stateless destek botları tökezliyor?
Lafı gevelemeden söyleyeyim. Çoğu destek otomasyonu olayları tek seferlik kabul ediyor — kullanıcı geliyor, sistem prompt’u alıyor, eşleşme yapıyor ve cevap üretiyor. Bu yapı küçük sorunlarda fena değil, hatta ilk temas için baya işe yarıyor.
Gel gelelim, aynı kullanıcı beş dakika sonra aynı hatayı yeniden açtığında sistem bunu yeni vaka sanıyor. Halbuki ikinci başvuru bence hayati ipucu (şaşırtıcı ama gerçek). Üçüncüsü ise neredeyse kırmızı alarm sayılmalı. İnsan desteğinde bunu hemen anlarsınız; deneyimli operatör ses tonundan bile hisseder bazen. Peki, yapay zekâ tarafında bu his tamamen kayboluyor — ve kaybolduğunda ne olduğunu çoğu ekip fark etmiyor bile.
2023’te Ankara’daki bir e-ticaret projesinde tam bunu yaşamıştık. Sipariş entegrasyonu bozulunca çağrı merkezi önce standart adımları önerdi, sonra kullanıcılar tekrar dönmeye başladı. Loglarda tekil hata gibi görünen şey aslında bölgesel bir kesintiymiş (yanlış duymadınız). Eğer sistem o tekrarları sayabilseydi ekip saatler önce uyarı alacaktı. Saatler, abartmıyorum.
Kısa bir not düşeyim buraya.
Tekrarlayan sorun neden ayrı ele alınmalı?
Eh, Çünkü tekrar eden hata artık yalnızca “hata” değildir — trend olur, desen olur, hatta kök neden aramasının giriş kapısı haline gelir — dürüst olayım, biraz hayal kırıklığı —. Bir defa düşen bağlantı kablo meselesi olabilir, ama üç defa düşüyorsa router tarafını kurcalarsın… ya da en azından kurcalamalısın, değil mi?
Vallahi, Klasik destek akışı kullanıcıya sürekli aynı checklist’i verirken aslında onu yıpratıyor. Bu noktada AI’ın görevi sadece doğru cevabı vermek değil; doğru seviyede, doğru zamanda tepki vermek olmalı. Hani ne farkı var diyorsunuz, değil mi? İnce ama çok önemli bir fark.
Bellekli ajan fikri neyi değiştiriyor?
Burada ortaya çıkan yaklaşım basit ama — şaşırdım açıkçası — etkili (inanın bana). Agent, konuşmayı sadece metin olarak saklamıyor; olayların tekrar sıklığını sayıyor, sınıflandırıyor ve durumun kötüleşip kötüleşmediğini izliyor. Bir çeşit hafıza katmanı ekleniyor ama düz tarihçe gibi değil, nasıl desem… not tutan bir nöbetçi gibi düşünün, her vardiyada bıraktığı yerden devam eden biri.
Editör masasında bu haberi ilk okuduğumda hemen kendi test ortamımda denemek istedim, İzmir’deki ev ofisinde. Bir demo akışında aynı hata üç kez tetiklendiğinde botun tonunu değiştirmesi baya hoşuma gitti açıkçası: önce yardım önerdi, sonra teşhisi derinleştirdi, en son doğrudan eskalasyon önerdi. Kağıt üstünde süper görünen birçok fikir pratikte sönüp gidiyor — bu sefer öyle olmadığını söyleyebilirim.
Bakın, burayı atlarsanız yazının kalanı anlamsız kalır.
Ama eksik var mı? Var tabii. Böyle sistemlerde yanlış pozitif riski her zaman masada duruyor; kullanıcı gerçekten sadece kararsızsa ve yanlışlıkla aynı mesajı iki kez gönderdiyse ne olacak? İşte burada eşik değerleri ve bağlam ağırlıkları kritik hale geliyor — bunları es geçerseniz sistem güvenilmez bir alarm makinesine dönüşüyor. Bu konuyla ilgili Sesle Konuşan Ajanlar Neden Hâlâ Oyuncak Gibi Kalıyor? yazımıza da göz atmanızı tavsiye ederim. Bu konuyla ilgili Claude Desktop’a Mila Bağlama: 30 Saniyede MCP Kurulumu yazımıza da göz atmanızı tavsiye ederim.
Tekrar eden hata = sıradan mesaj değil, operasyonel sinyal.
Mimariyi nasıl düşünmek lazım?
Kendi deneyimimden konuşuyorum, Böyle bir ajanı “LLM’e birkaç geçmiş mesaj atarım, olur biter” diye kurmaya kalkarsanız büyük ihtimalle duvara toslarsınız. Ham sohbet geçmişi hem gürültü üretir hem de modelin dikkatini dağıtır — ikisi bir arada oldukça kötü sonuç verir. Bunun yerine yapılandırılmış bellek çok daha mantıklı geliyor bana.
Şunu fark ettim: Mesela problem türü ayrı tutulur, tekrar sayısı ayrı tutulur, son görülme zamanı ayrı tutulur ve gerektiğinde eskalasyon puanı hesaplanır. Küçük startup için bu katman oldukça hafif kalabilir; tek dosyalık JSON state bile iş görür. Enterprise tarafta ise Redis, event stream veya özel durum deposu devreye girer. Şart değil ama ölçeklendikçe kaçınılmaz oluyor. Bu konuyla ilgili Alibaba Qwen’i Nasıl Büyüttü, Parayı Nereden Arıyor? yazımıza da göz atmanızı tavsiye ederim.
Peki neden?
| Yaklaşım | Artısı | Eksiği | Kime uygun? |
|---|---|---|---|
| Sadece chat geçmişi | Kurma işi kolay | Gürültülü ve unutkan | Deneme ortamları |
| Yapılandırılmış oturum belleği | Tekerleme gibi tekrarı yakalar | Tasarımı biraz emek ister | KOBİ / ürün ekipleri |
| Olay tabanlı + skorlanan bellek | Daha sağlam teşhis verir | Maliyet ve bakım artar | Kurumsal sistemler |
Nerede işler zorlaşıyor?
Zor kısım genelde modelde değil, orkestrasyonda çıkıyor. Kimin neyi ne kadar süre hatırlayacağına karar vermek gerekiyor; aksi halde sistem gereksiz yere geçmişe saplanıp kalıyor, her küçük şeyi kafaya takıyor.
Bazı durumlarda kısa süreli bellek yeterli olurken bazı senaryolarda uzun vadeli eğilim takibi gerekiyor. Mesela ödeme servislerinde beş dakikalık tekrar önemli ama güvenlik ihlallerinde günler süren örüntüler anlamlıdır. Yani tek beden herkese uymaz burada.
Peki SupportMind tarzı bir ajan nasıl çalışır?
Kod tarafını basitleştirerek anlatayım: giriş mesajı gelir, sınıflandırılır, ilgili issue etiketi bulunur ve oturum belleğindeki sayaç güncellenir. Sayaç belli eşiği aşarsa cevap tonu değişiyor — standart checklist yerine kök neden odaklı soru seti dönüyor ya da doğrudan insan desteğine yönlendiriyor. Basit ama işte bu basitlik güçlü kılan şey.
{
"issue_type": "database_connection_refused",
"occurrences": 3,
"last_seen": "2026-04-10T14:22:00Z",
"escalation_level": "high",
"next_action": "ask_for_logs"
}Böyle bakınca sihir yokmuş gibi duruyor. Ki zaten güzelliği de burada yatıyor — büyük iddialar yerine düzgün çalışan küçük parçalar. Ben bunu seviyorum açıkçası. Abartısız mühendislik.
Ha, bu arada önemli bir nokta var: amaç modeli “daha zeki” yapmak değil, belki sadece “daha dikkatli” yapmak olabilir mi? Bence evet. Birçok üründe eksik olan şey muhakeme kapasitesi değil; bağlam disiplinidir. PDF Dünyasında Bir Nefes: Ücretsiz ve Limitsiz Araçlar yazımızda bu konuya da değinmiştik.
Kural tabanlı mı olsun, öğrenen yapı mı?
Kural tabanlı yaklaşım hızlıdır ama serttir. Öğrenen yapı esnektir ama bazen saçmalar bir düşüneyim… — bunu açıkça söylemek lazım. En iyi sonuç genelde ikisinin ortasında geliyor diye düşünüyorum: önce güvenli eşikler koyarsınız, sonra gerçek kullanım verisi geldikçe sistemi yavaşça yumuşatırsınız.
- Aynı hata iki kez gelirse uyarıyı güçlendir. — bunu es geçmeyin
- Aynı hata üç kez gelirse teşhis sorularını değiştir.
- Aynı hata kısa sürede devam ederse insan operatöre aktar.
- Kullanıcı geçmişte çözüldü dediğinde sayaçları sıfırla veya azalt.
Nerede işe yarar, nerede patlar?
Küçük bir startup’ta bu yaklaşım özellikle destek yükünü azaltmak için fena değil. İki kişiyle müşteri desteği yürütüyorsanız her tekrarı yakalamak altın değerinde olur — abartmıyorum, gerçekten öyle. Bir support paneline gömülü hafif bellek katmanı bile ekibe ciddi nefes aldırabilir. Butterfly CSS: 2026’da Dikkat Çeken Hafif Bir Seçenek yazımızda bu konuya da değinmiştik.
Kurumsal tarafta ise oyun değişiyor. SLA baskısı var, güvenlik politikası var, entegrasyon karmaşası var (şaşırtıcı ama gerçek). Bu yüzden bellek mekanizmasının audit trail üretmesi gerekiyor; yani neden eskalasyon verdiğini sonradan gösterebilmelisiniz, yoksa iç denetimde ciddi sorun çıkar.
Bir arkadaşım geçen yıl Berlin’de böyle bir sistemi fintech tarafında denediğini anlatmıştı, adı Deniz. İlk hafta herkes heyecanlandı ama üçüncü haftada yanlış alarm oranları artınca tablo biraz bozuldu. Meğer eşikler fazla agresifmiş. Yani fikir güzel olsa da ince ayar şart — bu kısmı atlarsanız sisteme güven eriyor.
E tabi gizlilik konusu da var burada. Kullanıcı mesajlarını körlemesine saklamak iyi fikir değil; masking yapılmalı, TTL uygulanmalı. Mümkünse kişisel veri minimumda tutulmalı. Bunlar göz ardı edildiğinde teknik sorun değil, hukuki sorun haline geliyor.
Bende bıraktığı his ne oldu?
İnanın, Açık konuşayım. Bu konuyu araştırırken en çok şuna takıldım: AI’a yeni özellik eklemekten ziyade ona unutmayı bırakmayı öğretmek bazen çok daha büyük kazanım sağlıyor. Çünkü problem çözme kabiliyeti kadar problem devamlılığını fark etme yeteneği de önemliymiş — meğer bunu o kadar ciddiye almamışız.
Araya gireyim: Benzer bir şeyi geçen hafta Kadıköy’de kahve içerken yaşadım bizzat. Telefonum Wi-Fi’ye bağlanmıyordu ve cihaz bana peş peşe aynı “ağı unutup yeniden bağlanın” tavsiyesini verdi. Üçüncü denemede artık tavsiye komikti (kendi tecrübem). İşte insanlarla makineler arasındaki kırılma noktası tam orası — tekrar eden başarısızlığı fark edememek (buna dikkat edin)
Bu yüzden memory-driven agent fikri bana parlak geldi ama kusursuz gelmedi (inanın bana). Hatta beklediğim kadar pürüzsüz değildi diyeyim. Fakat dürüst olmak gerekirse zaten iyi fikirlerin çoğu ilk sürümde biraz hırpalıdır. Peki bunu neden söylüyorum? Önemli olan yönüdür — ve bu fikrin yönü doğru geliyor bana (inanın bana)
Sıkça Sorulan Sorular
Bellekli yapay zekâ ajanı nedir?
Kendi deneyimimden konuşuyorum, Bellekli ajan, kullanıcıyla olan etkileşimleri sadece tekil mesajlar olarak değil süreç olarak da takip eder.
Aynı sorunun kaç kez geldiğini bilir ve buna göre cevabını değiştirir.
Neden stateless destek botları sorun çıkarıyor?
Cevap çünkü her isteği sıfırdan değerlendiriyorlar.
Tekrar eden şikâyetleri görmezden gelince kullanıcıya aynı şeyi tekrar tekrar söylerler ve deneyim hızla bozulur.
Bu yaklaşım küçük şirketler için uygun mu?Evet, hatta çoğu zaman en faydalı olduğu yer orasıdır.
Basit bir oturum belleği bile destek yükünü azaltabilir ve eskalasyonu hızlandırabilir.
Sadece LLM geçmişi tutmak yeter mi?
Pek sayılmaz.
Ham geçmiş çok gürültü üretir; yapılandırılmış sayaçlar ve olay kayıtları daha temiz sinyal verir.Kaynaklar ve İleri Okuma
Orijinal yazının Dev.to sayfası
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
