Otomasyon eşiğini nereye koyduk

"Ajan bunu yapabilir mi" sorusuyla başladık. Yanlış soruymuş.

Ajan çoğu şeyi yapabiliyor. Ayda 21 ile 27 bin arasında olayın geçtiği bir sistemde cevaplanması gereken başkaydı: yaptığında yanılırsa ne oluyor. Bunun cevabı olay tipine göre öyle değişiyor ki, tek bir eşik yazmak mümkün olmadı.

Güven skoruyla başladık, iyi gitmedi

İlk kurulum herkesin yaptığını yaptı. Modelin ürettiği confidence değerine bir sınır koyduk, üstü otomatik gitsin dedik.

Sorun şu ki o skor kalibre değil. Model 0.9 dediğinde on kez dokuzunda haklı çıkmıyor. Kendi ürettiği bir sayı, dış dünyayla bağı yok. Eşiği ona bağlayınca ölçülmemiş bir tahmine bağlamış oluyorsunuz.

Skoru attık mı? Hayır. Sadece tek karar kriteri olmaktan çıkardık. Yerine geçen şey daha sıkıcı ama daha sağlam: eylem geri alınabiliyor mu.

Üç kova

Olayları zorluklarına göre değil, yanlış yapıldığında ne kaybedildiğine göre ayırdık.

Birinci kovada geri alınabilir ve dar kapsamlı işler var. Log toplama, disk kullanımı raporlama, servis durumu sorgulama. Yanlış çalışırsa maliyeti tekrar çalıştırmak. Bunlarda eşik yok - ajan karar veriyor, kimse onaylamıyor.

İkinci kova geri alınabilir ama kapsamı geniş olanlar. Tek cihazda servis yeniden başlatma burada. Yanlış cihazda yaparsanız etkisi var, ama düzeltilebiliyor. Eşik burada devrede ve ajanın seçtiği hedef envanterle çapraz kontrol ediliyor.

Üçüncü kovada geri alınamaz ya da çok geniş olanlar. Konfigürasyon değişikliği, birden fazla cihaza dokunan işlem, kullanıcı verisiyle ilgili her şey. Bu kovada eşik yok çünkü otomasyon yok. Ajan öneriyi hazırlıyor, uygulamayı insan onaylıyor.

Bu ayrımı yaptıktan sonra "ajan ne kadar iyi" sorusu ilginç olmaktan çıktı. Daha iyi bir model üçüncü kovayı otomatikleştirmiyor, çünkü sınırı çizen yetenek değil sonuç.

Kapsam, güvenden daha iyi bir sinyal

Zamanla şunu fark ettik: bir eylemin kaç cihaza dokunduğu, modelin ne kadar emin olduğundan daha güvenilir bir gösterge.

Tek cihazda yanlış yeniden başlatma bir kullanıcıyı etkiliyor. Aynı yanlış bir cihaz grubuna uygulandığında yüzlerce kişiyi. Modelin güven skoru ikisinde de aynı olabiliyor; sonuç aynı değil.

Eşiğin yanına ikinci bir kural koyduk: kapsam büyüdükçe onay zorunlu hale geliyor. Ajan aynı eylemi bir cihazda kendi başına yapıyor, beşte yapıyor, ellide yapmıyor.

Sınıf değil, bağlam

Başlangıçta eşikleri olay sınıfına bağlamıştık - "disk uyarıları şu eşikte, servis uyarıları bu eşikte". Bir süre sonra bunun fazla kaba olduğu ortaya çıktı.

Aynı sınıftaki iki olay çok farklı olabiliyor. Bir test sunucusundaki disk uyarısıyla veritabanı sunucusundaki disk uyarısı aynı sınıfta ama aynı şey değil. Eşiği sınıfa değil, sınıf ve hedefin birleşimine bağlamak gerekti.

Bu, eşik tablosunu büyüttü ve yönetimini zorlaştırdı. Karşılığında yanlış otomatik işlem sayısı düştü. İyi bir takas mıydı, hâlâ tartışıyoruz - tablo artık tek bir kişinin aklında tutabileceği boyutta değil.

Yüzde 37 bir hedef değildi

Sistem şu an olayların yaklaşık yüzde 37'sini insan müdahalesi olmadan kapatıyor. Bu sayıyı kimse hedef olarak koymadı; kovaların dağılımından çıktı.

Oranı yükseltmenin iki yolu var ve biri tuzak. Tuzak olan eşiği gevşetmek: aynı olaylar otomatik gitmeye başlıyor, oran yükseliyor, hata sayısı da yükseliyor. Diğeri birinci kovayı büyütmek, yani daha fazla olay tipini geri alınabilir hale getirmek.

Somut hali şöyle: "servisi yeniden başlat" tek adımda geri alınamaz bir iş. Ama önce durum kaydı alıp sonra yeniden başlatan bir akış geri alınabilir hale geliyor. Eşiğe dokunmadan kova değiştirmiş oluyorsunuz. Sıkıcı bir iş, en çok kazandıran da bu oldu.

Ajan durduğunda ne oluyor

Uzun süre atladığımız bir konu vardı: ajan çalışmadığında sistemin ne yapacağı.

Model servisine erişilemediğinde ya da doğrulama sürekli başarısız olduğunda olaylar birikmeye başlıyor. İlk sürümde bu sessizce oluyordu - kuyruk büyüyordu, kimsenin haberi yoktu.

Şimdi otomasyonun devre dışı kaldığı durum açık bir alarm üretiyor ve olaylar doğrudan insan kuyruğuna düşüyor. Ajan sistemlerinin en az konuşulan tarafı bu: çalışmadığında ne olacağı, çalıştığında ne yapacağından daha az düşünülmüş oluyor.

Eşik bir kez koyulup unutulmuyor

Altındaki her şey değişiyor - model sürümü, envanter, olay dağılımı - dolayısıyla eşik de sabit kalamıyor.

Olay tipi başına üç sayı tutuyoruz ve eşik tartışmaları bu üçü üzerinden yürüyor: otomatik kapatılan olaylarda geri dönüş oranı, insana düşen olaylarda onay oranı, ve doğrulama başarısızlık oranı.

İkincisi beklemediğimiz kadar faydalı çıktı. Bir olay tipinde insanlar ajanın önerisini sürekli olduğu gibi onaylıyorsa, o tip birinci kovaya aday demektir. Tersi de geçerli: onay oranı düşükse sorun eşikte değil, o adımın kendisinde.

---

Otomasyon eşiği bir model kalitesi sorusu gibi duruyor ama değil. Model iyileştikçe eşik kendiliğinden yükselmiyor.

Bizde işleyen sıra şu oldu: önce eylemi geri alınabilir hale getir, sonra kapsamını daralt, güven skoruna en son bak.