Bir AI ajanına nasıl bütçe verilir diye arattığınızda birbirinden tamamen farklı iki cevap alırsınız ve ikisinin de adı aynıdır. Biri token hakkında. Diğeri banka bakiyeniz hakkında. İkisini karıştırmak, ekiplerin ucuz hataya karşı korunup pahalı hataya açık kalmasının yoludur.
Aynı kelimeleri giyen iki soru
İnternete bir AI ajanının bütçenizi tüketmesini nasıl engelleyeceğinizi sorun, kendinden emin bir cevap alırsınız. Birkaç tanesini okuyunca aynı soruyu cevaplamadıklarını fark edersiniz.
Bir grup çıkarım maliyetinden bahsediyor: çalışma başına token sınırı, model yönlendirme, döngüye giren bir görevi durduran otomatik duraklatma. Buradaki hata modu, model sağlayıcınızdan gelen faturadır.
Diğer grup ödemelerden bahsediyor: ajanın bir cüzdanı veya kartı var ve üçüncü bir tarafa gerçek değer aktarabiliyor. Buradaki hata modu, paranın hesabınızdan çıkması ve geri gelmemesidir.
İkisine de "ajan bütçesi" ve "harcama kontrolü" deniyor. Aynı problem değiller, aynı şekilde bozulmuyorlar ve birinin kontrolleri diğeri için neredeyse hiçbir şey yapmıyor.
Fark neden teorik değil
Token aşımı sınırlı, gözlemlenebilir ve önemli anlamda telafi edilebilir. Fatura ay sonunda gelir, sağlayıcınız size bir gösterge paneli sunar ve en kötü ihtimalle planlamadığınız bir sayıyla karşılaşırsınız. Can sıkıcı ama atlatılır.
Ödeme aşımı bunların hiçbiri değildir. Bir şey durdurana kadar sınırsızdır, çoğu zaman mutabakat anına kadar görünmezdir ve bir stablecoin transferi bir kez gerçekleştikten sonra ne ters ibraz, ne itiraz süresi, ne de arayacağınız bir destek hattı vardır. Para karşı taraftadır.
Dolayısıyla token maliyeti yazılarını okuyup çalışma başına bir sınır koyan ve ajan harcamasını çözdüğünü düşünen bir ekip, kendini telafi edilebilir hataya karşı korumuş, telafi edilemez olanı ardına kadar açık bırakmıştır.
Gerçek bir ödeme limitinin dayanması gereken şey
Token sınırı kendi orkestrasyon kodunuzda yaşar ve bu sorun değildir, çünkü koruduğu şey kendi kodunuzun döngüye girmesidir. Ödeme limitinin işi daha zordur: aktif olarak kendisini aşmaya çalışan bir ajana karşı dayanması gerekir.
Bu varsayımsal değil. Bir dil modeli ikna makinesidir. Limiti isteme koyarsanız bir öneri yazmış olursunuz. Ajanın çağırdığı bir sarmalayıcıya koyarsanız, araya bir adım eklenmiş bir öneri yazmış olursunuz, çünkü onu çağırıp çağırmamaya ajan karar verir.
Herhangi bir ödeme kontrolünün testi basittir: ajan düşmanca davransaydı bu yine dayanır mıydı? Çoğu korkuluk bu soruda anında düşer.
Bir limitin sızdırdığı dört yol
Birincisi bariz olanı, olması gerekenden fazlasını isteyen ajan. Her kontrol bunu yakalar ve bu en az ilginç durumdur.
İkincisi, kimsenin ölçmediği yol. Ekip satın almaları engeller ama düzenli ödemeleri unutur, ya da transferleri engeller ama koruyucu bir pozisyonu iptal etmenin de para kaybetmenin bir yolu olduğunu gözden kaçırır. Ana fiili kapsayıp yanındakileri atlayan korkuluklar istisna değil, normal hatadır.
Üçüncüsü tekrar denemedir. Hayır denen bir ajan her zaman durmaz; cümleyi değiştirip yeniden dener. Retler sayılmıyorsa, doksan kez hayır bir kez evet diyen bir limit evet demiştir.
Dördüncüsü başarı gibi görünendir: ajan işlem başına her sınırın altında kalır ve kırk işlem yapar. Zaman penceresi olmayan bir kontrol bütçe değildir, işlem büyüklüğü sınırıdır.
Sayının gerçekte nerede durması gerekir
İşe yarayan düşünme biçimi şudur: limitin bozulması için neyin doğru olması gerektiğini sorun, sonra o şeyi zorlaştırın.
İstemdeki bir limit, ajan ikna edilirse bozulur. Sunucunuzdaki bir limit, sunucunuz yanılırsa, ele geçirilirse ya da tam o anda ayakta değilse bozulur. Zincir üstündeki bir sözleşmedeki limit, sözleşme yanlışsa bozulur ki bu çok daha küçük ve çok daha denetlenebilir bir yüzeydir.
Bunların hiçbiri tek başına yeterli değil, bu yüzden cevap seçim değil katmanlardır. Sunucu ön kontrolü hızlı yoldur ve sıradan durumu halleder. Zincir üstü kasa, yukarıdaki hiçbir katmanın neye inandığından bağımsız olarak limit aşan transferi geri çevirir. Saklama sağlayıcısındaki cüzdan taraması, ikisinin de görmediğini yakalar.
Bir ajan bunlardan birini konuşarak aşabilir. Bir sözleşmeyi kendi require satırını görmezden gelmeye ikna etmek diye bir şey yoktur.
Çoğu sistemin çöpe attığı sinyal
Neredeyse her korkuluk tasarımının iki sonucu vardır: izin ver ve engelle. Gerçek harcama kararlarının üç tane vardır.
Eksik olan, ödemenin izinli olduğu ama bir insanın gerçekleşmeden önce görmesi gerekecek kadar büyük ya da olağandışı olduğu durumdur. Bunu "izin ver" içine katarsanız, en çok haberdar olmak istediğiniz ödemeleri sessizce onaylayan bir sistem kurmuş olursunuz. "Engelle" içine katarsanız, meşru işi sürekli durdurduğu için insanlar bir hafta içinde her şeyi kapatır.
Bunu WARN olarak açıkça adlandırmak farkı yaratan şeydir. Karar vermek yerine yukarı taşır ve döngüdeki insana, izlemesi için bir gösterge paneli vermek yerine belirli bir anda belirli bir soru sorulur.
İkisini de koyun, ama hangisinin hangisi olduğunu bilin
Bunların hiçbiri token bütçelerine karşı bir argüman değil. Çalışma başına çıkarım maliyetinizi sınırlayın, yapabildiğiniz yerde daha ucuz modellere yönlendirin ve döngüye giren görevi duraklatın. Bu iş gerçek ve hakkında yazılanlar iyi.
Sadece bunu ödeme yetkisiyle aynı başlık altına koymayın ve birinde yeşil yanan bir panelin diğerinde güvenlik anlamına geldiğini düşünmeyin. Belirli bir kontrolün hangi bütçeyi koruduğunu sorun ve cevap "ucuz olanı" olduğunda dürüst olun.
Büyük bir çıkarım faturası çıkaran ajan size paraya mal olmuştur. Yanlış karşı tarafa ödeme yapan ajan, paranızı başkasına vermiştir. Bunlardan sadece biri bir destek talebidir.