Bir yapay zeka ajanınız olduğunu düşünün. Günde iki kez dev.to makaleleri yazan, her seferinde önce bir hafıza dosyasını okuyarak daha önce işlediği konuları tekrarlamamaya çalışan bir ajan. Bu dosya başlangıçta sadece 2 KB iken, birkaç ay içinde 29.446 byte'a, yani yaklaşık 7.360 tokene ulaştı. Her çalıştırmada bu kadar token okumak, başlangıçtaki 500 tokene kıyasla ciddi bir maliyet artışı demek. Üstelik bu artış yavaş ve sessiz gerçekleşti; ne hata ne uyarı ne de herhangi bir metrik kırmızı bölgeye girdi. Sadece dosya, her girişle biraz daha pahalı hale geldi. İşte bu, 'ajan maliyet kayması' (agent cost drift) olarak adlandırılan bir hata sınıfının klasik bir örneği.
Bu, tipik 'bağlam pahalıdır' makalelerinden farklı. Genelde büyük bir dosyayı modele doğrudan beslemekten kaçınmak için kum havuzu (sandbox) kullanmak gibi tek seferlik çözümler işe yarar. Ancak burada ajan, tüm dosyayı baştan sona okumak zorunda; çünkü amacı, bugünkü konuları geçmişteki tüm girdilerle karşılaştırarak tekrarı önlemek. Dosyayı kırpmak veya sadece son N girişi okumak, işin doğasını bozar. Çözüm 'daha az oku' değil, 'okunanı daha ucuz hale getir' olmalıdır.
Dosyanın büyüme hızı da endişe verici. Ortalama 1.400 byte olan 21 girişin son dördü 1.900 byte'a yaklaşıyor. Bunun nedeni, her yeni girişin sadece seçilen konuyu değil, aynı zamanda önceki 20 konuyu neden reddettiğini de açıklamak zorunda olması. Reddetme gerekçeleri, giriş sayısı arttıkça karesel olarak büyüyor. Yani byte sayısı doğrusal değil, ikinci dereceden artıyor. Bu, maliyetin sadece artmakla kalmayıp, artış hızının da giderek yükseldiği anlamına geliyor.
Uzmanların Görüşleri
Bu sorunu çözmek için hemen hafıza sistemini yeniden yazmak yerine, önce ölçüm yapmayı tercih ettim. Basit bir Python betiği yazarak dosyadaki giriş sayısını, toplam token sayısını ve son beş girişin token maliyetini hesapladım. Bu betik, eğilimi hissetmek yerine görmemi sağladı. Asıl çözüm ise bir arşiv bölmesi oluşturmak: güncel girişler için issues.md, eski girişler için ise sadece tarih, konu ve etiket içeren tek satırlık bir indeks ve tam metin için issues-archive.md dosyası kullanmak. Ajan, tekrarları önlemek için tam metin aramaya ihtiyaç duyar, ancak iki ay önceki bir girişin reddetme gerekçelerini okumak zorunda değildir.
Buradaki asıl ders, hatanın tek bir commit'te olmamasıdır. Kimse 'hafıza dosyasını pahalı yap' diye bir kod yazmadı. Her giriş, o an için doğru, gerekli ve haklı bir eklemeydi. Bu nedenle gözden kaçması kolaydır: incelemede işaretleyeceğiniz bir fark, kırmızıya dönen bir test veya 'buna sebep olan' tek bir PR yoktur. Hata, tek başına herhangi bir değişiklikte değil, aksi halde iyi olan değişikliklerin sıralı birikimindedir.
Eğer her çağrıda kendi birikmiş durumunu okuyan bir ajan çalıştırıyorsanız - bir hafıza dosyası, başvurduğu bir değişiklik günlüğü veya çapraz referans yaptığı bir karar günlüğü - ölçmeye değer şey, 'bu dosya var mı ve doğru ayrıştırılıyor mu' değil, 'bugün bunu okumanın maliyeti neydi ve bir ay önce neydi?'dir. Bir hafıza dosyasını okumak, bozulma sinyali vermez. Bunu ancak dosyayı bilerek, her istekte çalışan başka bir şeyi profilleme gibi ölçerseniz görürsünüz.
Sonuç olarak, yapay zeka ajanlarının hafıza yönetimi, görünmeyen maliyetlerin biriktiği bir alan. 'Ajan maliyet kayması', fark edilmesi zor ancak uzun vadede ciddi kaynak tüketimine yol açan bir tuzak. Düzenli ölçüm, arşivleme ve sadece gerekli bilgiyi okuma stratejileri ile bu tuzağın önüne geçilebilir. Unutmayın, ajanınızın sessizce büyüyen hafıza dosyası, faturanızı da sessizce büyütüyor olabilir.
Kaynak: dev.to
