İki ayrı veri yaşam döngüsü

Bir kullanıcı tatil planını konuşurken aktarmasız uçuş istediğini söylemiş olsun. Otel ve gezi seçenekleri üzerine uzayan sohbetin sonunda bu tercih hâlâ işe yarar; son konuşulan restoranın ayrıntıları ise her soruya taşınmak zorunda değildir. Google’ın AlloyDB ve Valkey ile kurduğu bellek örneğinin çekici yanı burada: yakın konuşmayı saklamakla kalıcı bir kuralı korumayı ayrı işler olarak ele alıyor. Geliştiriciye bütün geçmişi büyüyen bir istem içinde tutmak yerine iki ayrı veri yaşam döngüsü veriyor.[1]

Valkey yakın konuşmanın kayan penceresini tutuyor. AlloyDB, kullanıcı tercihlerini, kuralları ve geçmiş olayları kalıcı olarak saklıyor. Okuma sırasında uygulama kısa süreli konuşmayı alıyor, sorguyu veri tabanındaki üretken yapay zekâ işleviyle düzenliyor ve ilgili kalıcı bilgileri karma aramayla buluyor. Vektör benzerliği ile tam metin eşleşmesi birlikte kullanılıyor; kullanıcı, proje ve kapsam koşulları aramayı daraltıyor. Burada değerli olan, belleğin yalnızca daha büyük bir metin kutusu olmaktan çıkıp sorgulanabilir uygulama verisine dönüşmesi.[1]

Bu ayrımın pratik bir kurulma nedeni var. Yakın konuşma her turda değişiyor; kalıcı tercihler aynı sıklıkta silinip yeniden yazılmak zorunda değil. Google, hızlı ve geçici yazmaları önbelleğe ayırmanın ilişkisel veri tabanındaki yazma yükünü ve tablo şişmesini azaltmasını amaçlıyor. Benim için tasarımın mühendislik fırsatı, bu iki işin birbirinden bağımsız ayarlanabilmesi. Yine de kazancı yalnızca iki depo kullanmaya bağlamam: daha kısa bir konuşma penceresi veya daha sıkı bilgi seçimi, tek depolu bir uygulamada da yükü azaltabilir.[1]

Tercih değiştiğinde belleği sınamak

Yazma yolunda ise dikkat edilmesi gereken bir sınır var. Yeni konuşma önce Valkey’e ekleniyor; arka plandaki işçi önemli varlıkları çıkarıp AlloyDB’ye yazıyor. Metin değiştiğinde vektör gösteriminin aynı veri tabanı işlemi içinde güncellenmesi, kalıcı katmandaki iki gösterimi birlikte tutuyor. Fakat bu güvence, kullanıcının son söylediği kuralın çıkarım işçisine ulaşmış veya sonraki sorguda bulunmuş olmasıyla aynı şey değil. Bu tasarım için öncelikli deneme, bir tercihin değişmesinden hemen sonra gelen yeni sorudur: uygulamanın eski bilgiyi mi, yeni bilgiyi mi getirdiği burada görünür hâle gelir.[1]

Ben bu örneği bir bellek sağlayıcısını değiştirme deneyiyle değerlendiririm. Aynı konuşmalar, aynı model ve aynı bilgi seçimi korunurken yalnızca depolama düzeni değişir; ardından eski bir kuralı düzeltme, proje değiştirme ve önceki bir olayı yeniden sorma adımları eklenir. Böylece başarıyı modelin daha iyi yanıt vermesiyle karıştırmadan, kalıcı bilginin ne zaman bulunabildiğine bakmak mümkün olur. Yanıtın içinde tercih görünmüyorsa kayıt oluşumu ile arama sonucunu ayrı incelemek gerekir. Eksik çıkarım ve yanlış arama kapsamı, depolama seçimine alternatif açıklamalardır.[1]

AlloyDB’nin işlevleri ve Agent Development Kit bağlantısı, bu deneyi somut bir uygulamaya çevirmek için elde tutulabilir parçalar sunuyor. Benim tercih ettiğim başlangıç, tek bir konuşma akışında kalıcı kurallar ile geçici ayrıntıları ayırmak ve bellek sağlayıcısının girişini, saklanan veriyi, sorgu sonucunu karşılaştırmak. Başarı ölçüsü yalnızca kısa istem değil: kullanıcının düzelttiği tercihin doğru kapsamda yeniden bulunması. Bu küçük başlangıç, geliştiricinin bellek düzenini modelden ayrı değiştirme imkânını koruyor; bütün uygulamayı tek seferde yeniden kurmayı gerektirmiyor.[1]