Bir Yapay Zekâ Ajanına Sistemlerinize Erişim Nasıl Verilir?

Erişim yalnızca veri değil, eylem meselesidir

Bir yapay zekâ sistemine şirket sistemlerine erişim vermeye dair tartışmaların çoğu aslında okumayla ilgilidir: hangi belgeleri görebilir, özgün dosyaların izinlerine uyar mı, veri nereye gider. Bu soru önemlidir ve iyi işlenmiştir. Bu rehber ise ajanlarla birlikte gelen ve çok daha az planlanan diğer yarıyı ele alır: bu şeyin ne yapmasına izin verilir. Yalnızca okuyabilen bir model yanlış bir yanıt üretir. Eyleyebilen bir model yanlış bir fatura, müşteriye giden yanlış bir e-posta ya da silinmiş bir kayıt üretir; üstelik makine hızında ve odada kimse yokken.

Aşağıdaki iş bilerek heyecansızdır. Hiçbiri hangi modeli ya da çerçeveyi kullandığınıza bağlı değildir ve hepsini ilk entegrasyondan önce yapmak üçüncüsünden sonra yapmaktan kolaydır.

Sistemleri değil eylemleri ayıklayarak başlayın

Açmayı düşündüğünüz her eylemi yazın ve biri yanlışlıkla tetiklenirse ne olacağına göre sınıflandırın. Bazıları geri alınabilir: yazılan bir taslak, eski değeri saklanan bir alan güncellemesi, denetlediğiniz bir yere konan bir dosya. Bazıları telafi edilebilir — geri alınamaz ama ikinci bir eylemle dengelenebilir, tahsilattan sonraki iade gibi — ve düzeltme birinin gözüne görünür. Geri kalanı geri alınamazdır: müşterinin okuduğu bir mesaj, yedeksiz bir silme, şirketten çıkan bir ödeme, dakikalar içinde kopyalanacağı bir yerde yayımlanan her şey.

Bu ayıklama, herhangi bir politika belgesinden daha çok iş görür. Geri alınabilir eylemler, bir ajanın ekmeğini kazandığı yerdir ve önlerine onay kuyruğu koymak herkesin dikkatini çarçur eder. Geri alınamaz eylemler, insan kararının yeridir. Bir ajanın insan kararı olmadan yapabildiği geri alınamaz eylemlerin sayısı, tasarımın taşıdığı riskin tek satırlık adil bir özetidir ve çoğu ekibin hiç hesaplamadığı bir sayıdır.

Ortadaki kategoriye kuşkuyla yaklaşın, çünkü geri alınabilirlik sızdırır. Bir güncelleme yalnızca eski değer saklandıysa geri alınabilir. Bir silme yalnızca yedek penceresi kapanana kadar geri alınabilir. Bir kayıt değişikliği, bir web kancası onu her biri kendi kopyasına sahip üç sisteme taşıyana dek geri alınabilir görünür. Dürüst sınav, bir geri alma düğmesinin belgelenmiş olması değil, birinin gerçekten bir şeyi geri yüklemiş olmasıdır.

Ajana kendi kimliğini verin

Kolay yol, ajanı onu başlatan kişinin oturumu altında ya da başka bir iş için var olan uzun ömürlü bir anahtarla çalıştırmaktır. İkisi de hemen işe yarar ve ikisi de sonradan soru sorma imkânınızı yok eder.

Üç şey bozulur. Denetim günlüğü bir kişiyi kaydeder; kimsenin yapmadığı eylemler o kişinin adı altında görünür ve onun gerçek işinden ayırt edilemez. İzinler o kişinindir; ajan, görevin ihtiyaç duyduğu dilimi değil o kişinin erişebildiği her şeyi devralır ve başlatan ne kadar kıdemliyse durum o kadar kötüdür. Yetki iptali de ya hep ya hiç olur: ajanı durdurmak bir çalışanı devre dışı bırakmak demektir.

Kendi kimlik bilgisi, kendi izin kümesi ve kendi yaşam döngüsü olan ayrı bir asıl kimlik, ilk gün çok az maliyetlidir ve sonradan eklemek neredeyse imkânsızdır: ödünç kimlikli sürüm birkaç ay çalıştıktan sonra geçmişte hangi eylemlerin otomatik olduğunu kimse söyleyemez. Ajan gerçekten bir kişi adına hareket ediyorsa iki olguyu birbirine indirgemeden kaydedin: hangi ajan hareket etti ve kimin yetkisiyle.

Yalnızca teknik değil iş diliyle de sınırlayın

Teknik sınırlama — mümkünse salt okunur, entegrasyon başına tek kimlik bilgisi, platformun sunduğu en dar izin — gereklidir ama yeterli değildir. Pahalı hataları önleyen sınırlar genellikle API'nin değil işin dilinde ifade edilir: eylem ve çalıştırma başına bir değer tavanı, hangi müşteri kayıtlarının kapsamda olduğu, hangi ortamlar, hangi bölgeler, çalıştırmanın durup sorması gerekmeden önce bir şeyden kaç tane oluşturulabileceği.

Bu sınırları bir istemde tarif edildikleri yere değil, kodla uygulandıkları yere yazın. Sistem istemindeki bir yönerge bir ricadır; araç uygulamasındaki bir kontrol bir kuraldır. Aradaki fark yalnızca hiçbir şeyin hiç düşmanca olmadığı durumda önemsizleşir ve ajan girdileri, ekibinizden kimsenin yazmadığı belgeleri, web sayfalarını ve araç sonuçlarını içerir.

Gerçek bir şeye bağlamadan önce prova yapın

Ajanı önce bir kurguya karşı çalıştırın: verinin bir kopyası, kaydedilmiş ya da yapay araç yanıtları, hiçbir yere gitmeyen giden çağrılar. Aradığınız şey mutlu yolu tamamlayıp tamamlayamadığı değil; bir şey eksik, belirsiz ya da bozuk olduğunda hangi yolu izlediğidir — ve bu ancak fikstürler bilerek arıza içerdiğinde görünür. Hep başarılı olan ve derli toplu veri döndüren araçlar, güvenilir görünen ama hiç zaman aşımı, boş sonuç ya da izin reddi görmemiş bir ajan üretir.

Kaydettiğiniz çalıştırmaları saklayın. Sabit yanıtlara karşı yeniden oynatıldığında, bir ajanın sahip olabileceği tek gerileme paketine dönüşürler: bir istemi, bir modeli ya da bir araç açıklamasını değiştirin, önceden çalışan hangi yolların saptığını görün. Onlar olmadan her değişiklik birkaç deneme ve bir izlenimle değerlendirilir; bu da aynı girdide farklı davranan bir sistem karşısında ayakta kalmaz.

Günlük, gerçekte soracağınız soruyu yanıtlasın

Soru geldiğinde şu biçimin bir sürümü olacaktır: bu şey geçen salı o müşterinin hesabına ne yaptı ve neden. Yanıtlamak için argümanları ve sonuçlarıyla araç çağrılarının dizisi, bunları yapan kimlik, çalıştırmayı başlatan istek ve bir dalın diğerine neden tercih edildiğini görecek kadar gerekçe gerekir. Yalnızca nihai çıktıları tutan bir günlük bunu yanıtlayamaz; o sırada oturumu açık olan kişiyi kaydeden bir günlük de yanıtlayamaz.

İki işletme parçası bunu tamamlar. Ajanı dağıtım yapmadan anında durdurma yolu; çünkü teşhis, hasardan uzun sürer. Ve ajanın kimlik bilgisi için adı konmuş bir insan sahip, bir son kullanma tarihi ve herkesle aynı erişim gözden geçirmesinde bir yer — yoksa makine kimlikleri sessizce birikir ve kendilerini yaratan projelerden uzun yaşar; bir şirket de böylece sistemleri üzerinde hâlâ neyin eyleme yetkili olduğunu söyleyemez hâle gelir.