Model değiştiğinde kurallar değişmemeli

Ekipler, ajanlarının arkasındaki modeli yığındaki neredeyse her şeyden daha sık değiştirir. Yeni bir sürüm daha iyi taslak yazar, eskisi emekliye ayrılır, rutin işler için daha ucuz bir seçenek yeterli olur, bir bölge farklı bir sağlayıcı gerektirir. Her geçiş genellikle bir mühendislik yükseltmesi olarak görülür. Güvenlik kurallarınız modelin davranışının içinde yaşıyorsa, bu aynı zamanda kimsenin incelemediği bir politika değişikliğidir.

Yönetişim genellikle nerede saklanır

Tipik bir ajan kurulumuna bakın ve kuralların gerçekte nerede durduğunu sorun. Çoğu zaman modelle birlikte yer değiştiren yerlere dağılmışlardır:

• Sistem istemi. "E-posta göndermeden önce her zaman sor" bir denetim değil, modele yöneltilmiş bir ricadır. Başka bir model bunu farklı tartabilir ya da uzun bir bağlam onu görüş alanından itene kadar uygulayabilir.
• Modelin ne zaman soracağına dair kendi yargısı. Bazı modeller temkinlidir ve sık sık danışır; bazıları ilerlemeyi seçer. Duraklama bu mizaca bağlıysa, mizaç her değiştiğinde denetiminiz de değişir.
• Değerlendirme sırasında görülen davranış. Pilot, o model o istemlerle tesadüfen kaynak gösterdiği için başarılı olmuştu. Atıfın zorunlu olduğunu kimse yazmadığından, bir sonraki model kaynak göstermeyi bıraktığında bunu fark eden bir şey yoktur.
• Sağlayıcı tarafındaki korumalar. Bir sağlayıcının hizmetiyle gelen filtreler ve retler, bir başkasının hizmetiyle gelmez.

Bunların hiçbiri bir katman olarak yanlış değildir. Yalnızca kaybetmeyi göze alamayacağınız kuralları saklayacağınız yer değildir.

Model önerir, çalışma alanı karar verir

Kalıcı desen, kuralları modelin okuduğu metinde değil, eylemlerin gerçekleştiği sınırda uygulamaktır. Model planlar, taslak hazırlar ve araç çağrıları önerir. Modelin dışındaki bir katman, yani bu çağrıları yürüten koşum katmanı ya da çalışma alanı, herhangi bir şey çalışmadan önce her çağrıyı politikaya göre denetler. Ajan koşum katmanı (harness) nedir yazısı bu katmanı genel hatlarıyla anlatıyor.

Bu düzende "e-posta göndermeden önce sor", istemdeki bir cümle olmaktan çıkar ve gönderme eyleminin bir özelliğine dönüşür: hangi modelden gelirse gelsin her gönderme girişimi bir duraklama ve bir insana yöneltilmiş bir onay isteği doğurur. Duraklamanın olup olmayacağı konusunda modelin söz hakkı yoktur. Model yalnızca duraklama geldiğinde taslağın ne kadar iyi olduğunu etkiler.

Değişmesine izin verilenler

Model geçişi işin kalitesinde ve biçiminde görünmeli, başka hiçbir yerde değil:

• Taslakların, özetlerin ve analizlerin ne kadar iyi okunduğu.
• Ajanın bir hedefi adımlara nasıl böldüğü ve kaç adım attığı.
• Görevin izin verdiği araçlar içinde önce hangisine uzandığı.
• İş başına hız ve maliyet.
• Onay kapısındaki bir eyleme ne sıklıkla vardığı; daha iyi bir plan bunlardan daha azına ihtiyaç duyabilir.

Değişmemesi gerekenler

Bunlar ekibe aittir ve bir model geçişi her birini tam olarak olduğu yerde bırakmalıdır:

• Duran eylemlerin listesi. Dışarıya göndermek, silmek, dışa aktarmak, zamanlamak, canlı bir oturumda işlem yapmak, talimatları yeniden yazmak ve işi başka bir ajana devretmek. Her birini yedi eylem sınıfı yazısında açıkladık.
• Kimin onaylayabileceği. Roller ve erişim alanları, taslağı hangi modelin yazdığına bağlı değildir. Ayrıntılar için ajan işini kim onaylayabilir yazısına bakın.
• Bir kararın neye bağlı olduğu. Bir onay tek bir girişimi kapsar ve eylem çalışırken yeniden kontrol edilir.
• Kanıt şartları. Bir bulgu destekleyici bir pasaj gerektirir; kaynağı olmayan bir değer doldurulmaz, bilinmiyor olarak kalır.
• Denetim izi. İstekler, kararlar, araç çalıştırmaları ve sonuçlar aynı kesintisiz kayda düşmeye devam eder; böylece geçişin öncesi ve sonrası karşılaştırılabilir. Alanların listesi bir ajan denetim izi neyi kaydetmeli yazısında.
• Sınırlar. Harcama tavanları, süre ve araç çağrısı sınırları, durdurma denetimi ve şirket sınırı.
• Neyin tamamlanmış sayılacağı. Kabul ölçütleri bir modelin alışkanlıklarına göre değil, sonuca göre yazılır. Nasıl yapılacağını önce kabul ölçütlerini yazın yazısı gösteriyor.

GoCux çizgiyi nereye koyuyor

GoCux, kuralların şirketin çalışma alanına ait olduğu fikri üzerine kurulu. Kuralları ekipten biri belirler ve her an araya girebilir. Yedi sonuç doğuran eylem sınıfı, eylemin ne olduğu nedeniyle karar için durur; reddedilen çağrı kelimesi kelimesine aktarılır, böylece onaylayan kişi hangi model sormuş olursa olsun gerçekte neyin istendiğini görür. Kararlar ve sonuçlar, gerçekleştikleri anda tek ve kesintisiz bir denetim izinde makbuz olarak kayda geçer. Harcama görünür kredilerle ve günlük bir tavanın altında yürür; tek bir durdurma denetimi kurulumun tamamında yeni işi ve dış etkileri durdurur.

Model yönlendirmesi, bu kurallardan ayrı olarak, hizmetin içindeki tek bir ağ geçidi sınırının arkasında durur. Parçaların nasıl bir araya geldiğini yönetişim sayfasında görebilirsiniz.

Bir sonraki model geçişi için kontrol listesi

• Yazılı kabul ölçütleri olan, temsil gücü yüksek sabit bir iş emri seti tutun ve geçişten önce de sonra da çalıştırın.
• Bir test projesinde her sınıfı bilerek tetikleyin ve onay kapısındaki her eylemin hâlâ durduğunu doğrulayın.
• Metni değil kanıtı karşılaştırın: her bulgu hâlâ destekleyici bir pasaj taşıyor mu, bilinmeyenler bilinmiyor olarak kalıyor mu?
• Retlerin ve "kullanılamıyor" durumlarının üstü örtülmeden, hâlâ dürüstçe bildirildiğini kontrol edin.
• Geçiş öncesi ve sonrası denetim izini karşılaştırın; bir geçiş boşluk eklememeli ve alan düşürmemelidir.
• Sistem istemini, aslında birer kural olan ifadeler için gözden geçirin ve bunları uygulanan politikaya taşıyın.
• Geçişin kendisini, kimin onayladığı ve neden yapıldığıyla birlikte bir değişiklik olarak kaydedin.

Yanıtı değil işi değerlendirmek, değerlendirme sayfasının konusu; bir model değişikliği de aynı disiplini hak eder.