AI Destek Ajanları İçin En İyi Hafıza Yönetimi: Chat Geçmişten Akılcı Belleğe Geçiş

AI destek sistemleri geliştirirken karşılaşılan en yaygın hatalardan biri, sohbet geçmişini doğrudan sistem istemine dahil etmektir. Birçok geliştirici, ajanlara uzun vadeli bellek sağlamak amacıyla müşteri etkileşimlerinin tamamını kaydetmeyi tercih eder. Ancak bu yaklaşım, üretim ortamında ciddi sorunlara yol açabilir: yüksek token maliyetleri, gecikme sürelerinde artış ve yanıt kalitesinde düşüş. Biz de bir AI destek sistemini PERN yığını üzerinde inşa ederken bu hatalardan ders aldık ve bellek yönetimini baştan tasarladık. İşte hikayemiz ve kazandığımız kritik dersler.

Üretimde Karşılaşılan Gerçek Sorunlar: Naif Chat Geçmiş Yaklaşımının Sınırları

İlk versiyonumuzda, müşteri destek sistemimiz PostgreSQL veri tabanındaki sohbet geçmişini doğrudan Llama 3.3 modeline aktarıyordu. Sistem, son 20 mesajı JSON formatında modele aktarıyor ve ajan, bu verileri analiz ederek yanıt üretiyordu. Bu yöntem demo ortamlarında düzgün çalışsa da, üretimde üç temel sorunla karşılaştık:

• İşe yaramayan veriler: Müşteri sohbetleri, yanıtı etkilemeyen gereksiz bilgilerle doludur. Örneğin, "Klavye yapışık, düzeltiyorum" gibi ifadeler veya "Bob’a sorayım" gibi boş laflar, modelin dikkatini dağıtıyordu. Oysa ajanımızın hatırlaması gereken, müşterinin React frontend kullandığı, Node.js 18 çalıştırdığı ve API hız sınırı sorunları yaşadığıydı.

• Bağlam kirliliği ve ajan kayması: Çoklu oturumlar arasındaki geçişlerde, ajan farklı konuları birbirine karıştırıyordu. Örneğin, bir müşteri geçen ay SSO giriş sorunu yaşadıysa ve bu ay fatura sorunuyla yeni bir bilet açtıysa, sistem istemi bu SSO detaylarını fatura sorusuna yanıt verirken kullanabiliyordu.

• Kurumsal zeka eksikliği: Tek bir müşteriye özel bir sorun çözüldüğünde, bu çözüm diğer müşterilere aktarılamıyordu. Veri tabanı merkezli bir yaklaşımda, çözümler müşteri kimliğine göre izole edildiğinden, global öğrenme gerçekleşmiyordu. Ayrıca, kişisel bilgilerin (IP adresleri, hesap bakiyeleri) kaza sonucu paylaşılması riski vardı.

Yeni Bellek Mimarisi: Hindsight ile Akılcı Bellek Yönetimi

Bu sorunları çözmek için, sohbet geçmişini işlemek yerine yapısal bellek bankaları kullanmaya karar verdik. Hindsight adlı bir bellek motorundan yararlanarak, iki ayrı katman oluşturduk:

• Kişisel Bellek Bankası (`User {userId}`): Her müşteri için özel olarak saklanan ve doğrudan kimliklendirilebilir verileri içerir. Örneğin, müşterinin kullandığı teknoloji yığını, ekip büyüklüğü veya kurumsal yapı gibi bilgiler bu bankada depolanır.

• Global Çözüm Bankası (`global_resolutions`): Tüm platformdaki çözülmüş biletlerden oluşan, anonimleştirilmiş teknik sorun-çözüm çiftlerini barındırır. Bu banka, başka müşterilerin benzer sorunlarını hızla çözmelerine olanak tanır.

Yeni sistemde, müşteri yeni bir mesaj gönderdiğinde backend, PostgreSQL’deki ham sohbet geçmişini değil, semantik olarak anlamlı olanı çıkarır. Ardından, Hindsight API’sini kullanarak ilgili müşteri ve global bankalardan verileri çeker. Bu veriler, modele aktarılmadan önce temiz bir talimat bloğuna dönüştürülür.

// Örnek bellek sorgusu
const userMemory = await hindsight.fetch(`User ${userId}`);
const globalMemory = await hindsight.fetch('global_resolutions');

Kurumsal AI için Kritik Tasarım İlkeleri

Üç aylık bir geliştirme sürecinden sonra, bellek mimarisini yeniden tasarlamanın önemini net bir şekilde gördük. Bu süreçte üç temel ilkeyi öğrendik:

1. Durumu Bağlamla Karıştırmayın

Veri tabanınızdaki messages tablosu, uygulamanın durumunu temsil eder. Bu durum, doğrudan AI ajanının bağlamı olarak kullanılamaz. Ham durum verilerini modelin sistem istemine aktarmak, sadece token maliyetlerini artırmakla kalmaz, aynı zamanda gecikme sürelerini de dramatik şekilde yükseltir. Bunun yerine, semantik bellek motorları kullanarak durumu anlamlı bağlama dönüştürün. Örneğin:

• Ham mesaj: Merhaba, hesabıma giriş yapamıyorum. Lütfen yardım edin.
• Anlamlı bağlam: Kullanıcı Node.js 20 kullanıyor ve Express.js uygulamasında JWT doğrulama hatası yaşıyor.

2. İzolasyon Zorunludur

Tüm destek biletlerini tek bir vektör indeksinde toplamak, AI ajanının müşteri verilerini karıştırmasına ve kişisel bilgilerin sızdırılmasına yol açar. Müşteri özelinde bellek bankaları ile global çözüm bankalarını tamamen izole edin. Bu, hem veri gizliliğini sağlar hem de ajanların yanıtlarında tutarlılığı artırır. Örneğin:

• Yanlış: Tüm biletleri aynı vektör veritabanında saklamak.
• Doğru: Müşteri kimliğine göre ayrılmış özel bellekler ve anonim global çözümler oluşturmak.

3. Anonimleştirme ve Veri Kontrolü

AI destek sistemlerinde kişisel olarak tanımlanabilir bilgiler (PII) riski yüksektir. Global bellek bankalarında depolanan çözümlerin, müşteri verilerinden arındırılmış olduğundan emin olun. Örneğin:

• Sakıncalı: Müşteri hesap numarası 1234567890 olan kullanıcı, webhook hata bildiriminde bulundu.
• Güvenli: Webhook doğrulama hatası nedeniyle Express.js payload sınırı 10MB’a ayarlanmalıdır.

Başarı Ölçütleri ve Gelecek Planları

Yeni bellek mimarisiyle birlikte sistemimizin performansı önemli ölçüde iyileşti:

• Token kullanımı %70 azaldı: Artık gereksiz sohbet geçmişi yerine, anlamlı bağlam aktarılıyor.
• Yanıt süresi %40 kısaldı: Sistem istemi boyutu küçüldü ve modelin bağlam işleme süreci hızlandı.
• Bilgi paylaşımı arttı: Global bellek sayesinde, benzer sorunlara sahip müşteriler hemen çözüme ulaşabiliyor.

Gelecekte, bu mimarinin daha da optimize edilmesi için çalışıyoruz. Özellikle, bellek bankalarının dinamik olarak güncellenmesi ve ajanların öğrenme sürecinin otomatikleştirilmesi üzerinde duruyoruz. AI destek sistemlerinde uzun vadeli bellek yönetiminin ne kadar kritik olduğunu gördükten sonra, artık hiçbir sistemi ham sohbet geçmişiyle çalıştırmayı düşünmüyoruz. Doğru bellek mimarisi, hem maliyetleri düşürüyor hem de müşteri deneyimini iyileştiriyor.