Ajan değerlendirme hattı kurmak
Ajan değerlendirmesi, gerçek kullanımdan toplanan görev seti üzerinde görev tamamlama oranı ve hata sınıflandırmasıyla ölçülür.
ÖNKOŞULLAR
- Çalışan bir ajan akışı ve araç şemaları
- Üretimden veya gerçek kullanıcı taleplerinden erişilebilir örnekler
- Ajanın yan etkilerini geri alabileceğiniz bir test ortamı
GEREKEN ARAÇLAR
- İz kaydı altyapısı (araç çağrıları dâhil)
- Test ortamı için sahte API ve dosya sistemi
- Sonuç doğrulama kodu yazacağınız bir test çatısı
- 01
Gerçek kullanımdan görev topla
Sentetik örnek değil, üretimde karşılaşılan gerçek istekler.
Uydurulmuş görevler gerçek dağılımı temsil etmez ve size yanlış bir güven verir. Üretim kayıtlarından veya gerçek taleplerden seçim yapın; kolay, orta ve zor vakaları dengeli dağıtın. Zor vakaların çoğu sınırda kalanlar olacak: politikanın tam eşiğinde, belgenin iki maddesi arasında, kullanıcının yarım bıraktığı cümlede.
- Gerçek olsun: üretim kaydından alınmış, anonimleştirilmiş.
- Doğrulanabilir olsun: son durum makine tarafından kontrol edilebilsin.
- Geri alınabilir olsun: değerlendirme koşusu kalıcı yan etki bırakmasın.
- Ayırt edici olsun: iki modelin farklı sonuç üretme ihtimali olsun.
- Başarısızlıkları içersin: üretimde hata veren gerçek vakalar sete girsin.
- 02
Başarı tanımını yaz
Doğru sonucun ne olduğu yazılı olmadan puanlama yapılamaz.
Ajan değerlendirmesinde başarı, çıktı metni değil ortamın son durumudur. Bu yüzden her görev için beklenen son durum yapılandırılmış biçimde yazılmalı ve makine tarafından kontrol edilebilmeli.
yaml kimlik: destek-iade-014 hedef: "İade talebini politikaya göre değerlendir ve uygun kuyruğa yönlendir." beklenen_son_durum: karar: "politika-disi" kuyruk: "istisna-degerlendirme" musteriye_bildirim: true degistirilen_kayit_sayisi: 1 kabul: yan_etki_yok: true maksimum_arac_cagrisi: 4 kaynak_gosterme: "iade politikası md. 4" - 03
Kısmi başarıyı puanla
İkili başarı/başarısızlık, iyileştirmeyi görünmez kılar.
İkili puanlama (tamamlandı / tamamlanmadı) karar için gerekli ama iyileştirme için yetersiz. Kısmi başarıyı ayrı raporlamak, hangi adımda kaybettiğinizi gösteriyor: doğru kuyruğa gitti ama bildirim göndermedi ile hiç başlamadı arasında büyük fark var.
Sonuç Tanım Ne anlama gelir Tam Beklenen son durum sağlandı, yan etki yok Hedef Kabul edilebilir Son durum sağlandı, fazladan araç çağrısı var Verimlilik sorunu Kısmi Bazı alanlar doğru, bazıları eksik Adım kaybı; izden teşhis edilir Yan etkili Hedef sağlandı ama fazladan değişiklik oldu Üretimde başarısız sayılır Başarısız Son durum sağlanmadı Kurtarma mekanizmasına bakılır Beş kategori, tek bir oranın gizlediği bilgiyi geri getirir. - 04
Hataları sınıflandır
Araç şeması, planlama, bellek, doğrulama — kök neden kategorileri.
Hata sınıflandırması, iyileştirme bütçesini nereye harcayacağınızı belirler. Sahada gözlenen hataların büyük kısmı model kalitesinden değil üç yerden geliyor: belirsiz araç şeması, uzun oturumda kısıt kaybı ve hata sonrası yeniden planlama eksikliği.
- Araç seçimi: yanlış araç çağrıldı → açıklamalara seçim ölçütü yazın.
- Parametre: şemaya uymayan değer → enum ve desen kısıtı ekleyin.
- Planlama: gereksiz veya eksik adım → hedefi daraltın.
- Kısıt kaybı: erken adımdaki kural unutuldu → araç katmanında zorlayın.
- Kurtarma yok: aynı hata tekrarlandı → hata mesajına düzeltme yönü ekleyin.
- Yan etki: hedef dışı değişiklik → yetkiyi daraltın.
- 05
Regresyona bağla
Her istem ve model değişikliğinde aynı seti çalıştır.
- 06
Yedi metriği raporla
Tek skora indirmeden yedi ekseni ayrı ayrı sunun.
Hattın çıktısı tek bir skor olmamalı. Tamamlama oranı, adım verimliliği, kurtarma oranı, yan etki sayısı, kalibrasyon, kararlılık ve tamamlanmış görev başına maliyet ayrı ayrı raporlanır; ağırlıklandırma iş bağlamına ait bir karardır.
- 07
Karar kümesini kilitle
Setin üçte birini yalnızca sürüm kararlarında açılmak üzere ayırın.
Setin yaklaşık üçte biri geliştirme sırasında hiç açılmayacak biçimde ayrılmalı. Bu, klasik makine öğrenmesindeki eğitim/test ayrımının aynısı ve aynı nedenle işe yarıyor: ekip, gördüğü vakalara farkında olmadan aşırı uyum sağlıyor.
Karar kümesi yalnızca sürüm kararlarında açılır ve sonucu sürüm notuna yazılır. Sık açılan bir karar kümesi, bir geliştirme kümesine dönüşür ve koruma işlevini kaybeder.
SIK DÜŞÜLEN TUZAKLAR
Beklenen çıktıyı modele yazdırmak
Modelin yazdığı beklenen çıktı, modelin kendi eğilimlerini sete kodlar ve ölçümü körleştirir. Taslak olarak kullanılabilir, karar insana ait olmalı.
Ortamı sıfırlamamak
Önceki koşunun bıraktığı durum sonraki sonucu bozar. Her görev temiz bir ortamda başlamalı.
Araç çağrısı sayısını sınırlamamak
Ajan hedefe ulaşır ama maliyet öngörülemez olur. Kabul kriterine üst sınır koyun.
Model yargıcına tek başına güvenmek
Yargıç modelin kendi eğilimleri sonuca karışır. En az bir insan kalibrasyon turu gerekir.
KONTROL LİSTESİ
- 30 gerçek görev toplandı ve zorluk dağılımı dengeli
- Her görev için beklenen son durum iki kişi tarafından bağımsız yazıldı
- Doğrulama kodu yazıldı ve otomatik koşuyor
- Kısmi başarı beş kategoride sınıflandırılıyor
- Hata sınıflandırması izlerden otomatik çıkarılabiliyor
- Yedi metrik ayrı ayrı raporlanıyor
- Karar kümesi ayrıldı ve kilitli
- Her üretim arızası sonrası sete vaka ekleniyor
Maddelerin tamamı işaretlenmeden kurulum üretime alınmamalı.
Sık sorulan sorular
Kaç görev yeterli?
Az sayıda ama gerçek görev, çok sayıda sentetik görevden daha bilgilendirici. Hata kategorilerini temsil etmesi önemli.
Kaç görevlik set yeterli?
Karar vermeye başlamak için 20-30 görev çoğu ekipte yeterli. Belirleyici olan sayı değil, görevlerin gerçek olması ve son durumunun doğrulanabilmesi.
Gerçek sistemlere karşı test edilebilir mi?
Yan etkileri geri alınabilir bir kopya ortamda evet. Üretim sistemlerinde değerlendirme koşusu yapmak, ölçümün kendisini bir risk kaynağına dönüştürür.
Kaynaklar
- 01Sinaptik Research — uygulama notları — Sinaptik Lab · Teknik rapor
BUILD
Bu rehberi kurumunuzda uygulayalım mı?
Aynı mimariyi kendi verinizle kurmak için discovery oturumundan üretime kadar birlikte ilerliyoruz.