İşte Neden Chat Geçmişi Yerine Hindsight Hafızası Kullanmaya Başladık

LlM destek ajanlarıyla çalışırken karşılaşılan en kritik anlardan biri, token maliyetlerinin aniden tırmanmaya başladığı ve ajan yanıtlarının tutarlılığını yitirdiği andır. Bu durum özellikle müşteri destek sistemlerinde ortaya çıkar ve genellikle tüm sohbet geçmişinin sistem komutuna eklenmesiyle tetiklenir. Peki, bu yöntemin neden uzun vadede sürdürülemez olduğunu ve nasıl daha verimli bir hafıza yönetimi stratejisine geçildiğini inceleyelim.

Üretimdeki Destek Ajanının Karşılaştığı Temel Sorunlar

İlk etapta geleneksel bir yaklaşım benimseyerek PostgreSQL tabanlı sohbet geçmişini doğrudan Llama 3.3 modeline aktaran bir sistem kurduk. Bu yöntem demo ortamlarında iyi çalışsa da gerçek dünya senaryolarında ciddi performans sorunları ortaya çıktı:

• İşe yaramayan gürültü: Müşterilerin teknik sorunlarını anlatırken ekledikleri gereksiz detaylar, LLM'in dikkatini dağıtarak token maliyetlerini artırdı. Örneğin, bir API hız sınırlama sorunu anlatılırken klavyenin yapışık olduğu gibi bireysel detaylar yer alabiliyordu.

• Bağlam penceresinin kirlenmesi: Farklı sorunlara ait geçmiş sohbetlerin karıştırılması, ajanların yanıtlarının tutarlılığını bozdu. Örneğin, bir müşterinin geçmişteki SSO giriş sorunu ile yeni bir fatura sorusunu karıştırabiliyordu.

• Çapraz müşteri öğrenme eksikliği: Bir müşterinin yaşadığı nadir bir sorunun çözümü, diğer müşterilere aktarılmıyordu. Veritabanı merkezli bu yaklaşım, müşteri verilerinin izolasyonunu zorlaştırıyordu.

Hindsight Hafızasının Yapısı: İki Katmanlı Sistem

Yapılandırılmış bir hafıza mimarisi kurmak için Hindsight Cloud’un sunduğu iki katmanlı hafıza yaklaşımına geçtik:

1. Bireysel Müşteri Hafızası

• Anahtar: Kullanıcı ID’si ile ilişkilendirilir.
• İçerik: Müşteriye özel teknik detaylar (örneğin, kullanılan teknoloji yığını, Node.js sürümü, ekip büyüklüğü).
• Örnek: "Müşteri Neon Postgres kullanıyor ve Node 18 üzerinde çalışıyor."

2. Küresel Çözümler Hafızası

• Anahtar: Anonimleştirilmiş teknik sorun-çözüm çiftleri.
• İçerik: Tüm platform genelinde çözümlenmiş sorunların teknik detayları (örneğin, API hata mesajları, Express.js ayarları).
• Örnek: "Sorun: Express payload parsing limitleri nedeniyle webhook doğrulama hatası. Çözüm: express.json({ limit: '10mb' }) yapılandırması."

Kod Düzeyinde Geçiş Süreci

Hindsight SDK’sından faydalanarak mevcut sistemimizi nasıl dönüştürdüğümüzü inceleyelim. Öncelikle, müşteriden yeni bir mesaj geldiğinde sistemin nasıl tepki verdiğini ve hafıza katmanlarına nasıl eriştiğini gösteren akış şu şekilde işliyor:

// Express.js arka uçta gelen yeni mesaj işleme fonksiyonu
exports.handleNewMessage = async (userId, message) => {
  // 1. Müşteri özelindeki hafızayı çek
  const userMemory = await hindsight.getMemory(`User ${userId}`);
  
  // 2. Küresel çözümler hafızasına eriş
  const globalMemory = await hindsight.getMemory('global_resolutions');
  
  // 3. İlgili geçmiş verileri sistem komutuna ekle
  const context = compileContext(userMemory, globalMemory, message);
  
  // 4. Llama 3.3 modeline gönder ve yanıtı al
  const response = await groqClient.query(
    'llama-3.3-70b-versatile',
    context,
    message
  );
  
  return response;
};

Bu yaklaşımın en önemli avantajı, sistem komutunun boyutunu önemli ölçüde küçültmesi oldu. Önceki yöntemde 20 mesajın JSON olarak aktarılması gerekirken, artık sadece ilgili teknik detaylar ve çözüm önerileri aktarılıyor. Bu da token maliyetlerini %60’a varan oranlarda azalttı.

Verimlilik Kazanımları ve Ölçülebilir Sonuçlar

Yapılandırılmış hafıza mimarisiyle birlikte sistem performansında dikkat çekici iyileşmeler gözlemledik:

• Token maliyetlerinde %60’a varan düşüş: Sistem komutunun boyutunun küçülmesiyle birlikte API çağrı maliyetleri önemli ölçüde azaldı.

• Yanıt kalitesinde artış: LLM’in gereksiz detaylarla dağılması engellendi ve yanıtların tutarlılığı arttı.

• Çapraz müşteri öğrenme: Bir müşterinin yaşadığı nadir bir sorunun çözümü, platformdaki tüm müşterilere anında aktarılmaya başladı.

• Gizlilik ve güvenlik: Müşteri verilerinin izolasyonu sayesinde veri sızıntıları ve PII (kişisel tanımlayıcı bilgiler) riski ortadan kalktı.

Kritik Dersler: Hafıza ve Durum Yönetimi

Bu proje sırasında edindiğimiz en önemli derslerden biri, veritabanındaki durum verilerinin doğrudan LLM’e aktarılmasının ne kadar verimsiz olduğu oldu. İşte karşılaştığımız temel hatalardan bazıları ve çözüm önerileri:

• Durum ≠ Bağlam: Veritabanındaki sohbet geçmişi, sadece uygulama durumunu temsil eder. Bu verilerin doğrudan LLM’e aktarılması, ajanların performansını olumsuz etkiler. Bunun yerine, durumu semantik hafızaya dönüştürmek gerekiyor.

• İzolasyon zorunludur: Tek bir vektör veritabanında tüm müşteri verilerini depolamak, veri sızıntılarına ve müşteri profillerinin karışmasına yol açar. Bu nedenle, özel müşteri hafızaları ile küresel çözümler hafızası mutlaka ayrılmalıdır.

• Anonimleştirme kritik önem taşır: Küresel hafızaya eklenen verilerde müşteri adları, IP adresleri veya özel hesap bilgileri gibi PII unsurlarının bulunmamasına dikkat edilmelidir.

Geleceğe Yönelik Stratejiler

Gelecekte, bu hafıza mimarisini daha da geliştirmek için birkaç önemli adım planlıyoruz. Öncelikle, müşteri özelindeki hafızanın otomatik olarak güncellenmesini ve dinamik olarak genişletilmesini sağlayacak bir sistem kurmayı hedefliyoruz. Ayrıca, küresel hafızadaki teknik detayların sürekli olarak güncellenmesini ve yeni çözüm önerilerinin hızla eklenmesini otomatikleştirecek araçlar geliştirmeyi planlıyoruz.

Bunun yanı sıra, farklı LLM modelleriyle entegrasyonu test ederek en uygun modeli ve ayarları belirlemeyi amaçlıyoruz. Son olarak, müşteri destek ajanlarının yanıt kalitesini sürekli olarak ölçmek ve iyileştirmek için yeni metriklere odaklanacağız.

İyi tasarlanmış bir hafıza mimarisi, sadece token maliyetlerini düşürmekle kalmıyor, aynı zamanda müşteri destek sistemlerinin verimliliğini ve yanıt kalitesini de önemli ölçüde artırıyor. İşte bu nedenle, artık chat geçmişi yerine Hindsight gibi yapılandırılmış hafıza sistemlerine yöneliyoruz.