@ideefixeAjana araç vermek: yetki sınırı, geri alınabilirlik ve onay adımı nasıl tasarlanır
Bir ajan kurduğunuzda asıl soru modelin ne kadar akıllı olduğu değil, neye dokunabildiği. Ajanımız sekiz aydır çalışıyor ve bu sürede yaptığımız en iyi işler model tarafında değil yetki tasarımı tarafında oldu. Kullandığımız çerçeveyi paylaşayım.
Her aracı üç eksende sınıflandırıyoruz: etkisi, geri alınabilirliği ve kapsamı.
Etkisi okuma mı yazma mı? Okuma araçları serbest. Yazma araçları onay gerektirebiliyor. Bu basit ayrım bile ilk gün çok şeyi düzene soktu.
Geri alınabilirlik en önemli eksen. Bir işlem yanlış yapıldıysa geri alınabiliyor mu? Bir kaydı güncellemek geri alınabilir, çünkü eski değeri saklıyoruz. Bir mail göndermek geri alınamaz. Bir ödeme başlatmak geri alınamaz. Kuralımız şu: geri alınamayan her işlem insan onayı gerektirir, istisnasız.
Kapsam, işlemin kaç kaydı etkilediği. Tek kayıt güncellemek ayrı, toplu güncelleme ayrı. Biz toplu işlemlerde bir üst sınır koyduk: ajan tek seferde en fazla 50 kayda dokunabiliyor, fazlası için insan onayı. Bu sınır bir kez işimize yaradı; ajan yanlış bir filtre kurup 4.000 kaydı güncellemeye kalktı ve sınıra takıldı.
Onay adımının tasarımı ayrı bir konu. Kötü tasarlanmış onay, onay değil tıklama alışkanlığı üretiyor. Onay ekranında üç şey gösteriyoruz: ne yapılacak, neden yapılacak, ne değişecek. Değişiklik önizlemesi en kritik kısım; kullanıcı eski ve yeni değeri yan yana görüyor. Bir de "bu onayı bir daha sorma" seçeneği koymadık, bilinçli olarak.
İzlenebilirlik: ajanın attığı her adım kayıt altında. Hangi aracı, hangi parametrelerle çağırdı, ne döndü. Bir sorun çıktığında bu kaydı okumadan hiçbir şey anlaşılmıyor. Kayıt formatını insanın okuyabileceği şekilde tutun; biz başta ham JSON tutuyorduk, kimse bakmıyordu, okunabilir bir akış görünümü yapınca ekip kendiliğinden incelemeye başladı.
Bir de şu var: ajanın kendi hatasını fark etmesini beklemeyin. Modeller yaptıkları işi başarılı sayma eğiliminde. Dışarıdan doğrulama koyun. Bizim ajanımız bir kaydı güncelledikten sonra, güncellemenin gerçekten olduğunu ayrı bir okuma çağrısıyla doğruluyor ve sonuç beklenenden farklıysa duruyor.
Son olarak kimlik meselesi. Ajan kimin adına çalışıyor? Bizde ajanın kendi hesabı var ve bu hesabın yetkileri, onu tetikleyen kullanıcının yetkileriyle kesişiyor. Yani ajan, kullanıcının yapamayacağı bir şeyi yapamıyor. Bu kuralı baştan koymak, sonradan koymaktan çok daha kolay.
Ajan çalıştıranlar, siz hangi işlemleri onaya bağladınız, toplu işlem sınırınız var mı?
Her aracı üç eksende sınıflandırıyoruz: etkisi, geri alınabilirliği ve kapsamı.
Etkisi okuma mı yazma mı? Okuma araçları serbest. Yazma araçları onay gerektirebiliyor. Bu basit ayrım bile ilk gün çok şeyi düzene soktu.
Geri alınabilirlik en önemli eksen. Bir işlem yanlış yapıldıysa geri alınabiliyor mu? Bir kaydı güncellemek geri alınabilir, çünkü eski değeri saklıyoruz. Bir mail göndermek geri alınamaz. Bir ödeme başlatmak geri alınamaz. Kuralımız şu: geri alınamayan her işlem insan onayı gerektirir, istisnasız.
Kapsam, işlemin kaç kaydı etkilediği. Tek kayıt güncellemek ayrı, toplu güncelleme ayrı. Biz toplu işlemlerde bir üst sınır koyduk: ajan tek seferde en fazla 50 kayda dokunabiliyor, fazlası için insan onayı. Bu sınır bir kez işimize yaradı; ajan yanlış bir filtre kurup 4.000 kaydı güncellemeye kalktı ve sınıra takıldı.
Onay adımının tasarımı ayrı bir konu. Kötü tasarlanmış onay, onay değil tıklama alışkanlığı üretiyor. Onay ekranında üç şey gösteriyoruz: ne yapılacak, neden yapılacak, ne değişecek. Değişiklik önizlemesi en kritik kısım; kullanıcı eski ve yeni değeri yan yana görüyor. Bir de "bu onayı bir daha sorma" seçeneği koymadık, bilinçli olarak.
İzlenebilirlik: ajanın attığı her adım kayıt altında. Hangi aracı, hangi parametrelerle çağırdı, ne döndü. Bir sorun çıktığında bu kaydı okumadan hiçbir şey anlaşılmıyor. Kayıt formatını insanın okuyabileceği şekilde tutun; biz başta ham JSON tutuyorduk, kimse bakmıyordu, okunabilir bir akış görünümü yapınca ekip kendiliğinden incelemeye başladı.
Bir de şu var: ajanın kendi hatasını fark etmesini beklemeyin. Modeller yaptıkları işi başarılı sayma eğiliminde. Dışarıdan doğrulama koyun. Bizim ajanımız bir kaydı güncelledikten sonra, güncellemenin gerçekten olduğunu ayrı bir okuma çağrısıyla doğruluyor ve sonuç beklenenden farklıysa duruyor.
Son olarak kimlik meselesi. Ajan kimin adına çalışıyor? Bizde ajanın kendi hesabı var ve bu hesabın yetkileri, onu tetikleyen kullanıcının yetkileriyle kesişiyor. Yani ajan, kullanıcının yapamayacağı bir şeyi yapamıyor. Bu kuralı baştan koymak, sonradan koymaktan çok daha kolay.
Ajan çalıştıranlar, siz hangi işlemleri onaya bağladınız, toplu işlem sınırınız var mı?
3 3 yorum
