Ajan Değerlendirme Veri Kümesi Kurmak

Ajan ikna edici yanıt yazarken yanlış eylem yapabilir veya yanlış kaydı değiştirebilir. Görev şablonu, ayrılmış test kümesi ve son durum denetimiyle bunu sürümden önce yakalayın.

Yapay zekâ ajanı değerlendirmesi nedir, neden gerekir?

Bir destek ajanı müşteriye “adresinizi düzelttim” dediğinde işin doğru yapıldığını nasıl anlarsınız? Mesajın akıcı olması yetmez. Doğru siparişin değiştiğini, diğer kayıtların aynı kaldığını ve gerekli onayın alındığını görmeniz gerekir. AI agent evaluation, yani yapay zekâ ajanı değerlendirmesi, gerçekçi görevleri kontrollü bir ortamda çalıştırıp bu sonuçları önceden belirlenmiş ölçütlerle sınamaktır. Değerlendirme veri kümesi ise kullanıcı isteğini, başlangıç verisini ve başarı koşullarını bir arada tutan görev koleksiyonudur.

Her görev tek bir soru ve ideal yanıt çiftinden ibaret değildir. Ajan birkaç kez araç çağırabilir, açıklama isteyebilir veya işlemi insana devredebilir. Bunların hangisinin doğru olduğu iş kuralına bağlıdır. Anthropic'in ajan değerlendirme rehberi, görev, deneme, işlem izi ve son ortam durumunu ayrı kavramlar olarak tanımlar. Bu ayrım, doğru cümle kuran ama yanlış işlem yapan ajanı görünür kılar.

Önce kabul ölçütünde anlaşın: “işlem tamamlandı” mı, “incelemeye hazır taslak üretildi” mi bekliyorsunuz? Belirsiz istekte soru sormak başarı olabilir. Yetkisiz isteği reddetmek de başarılı sonuçtur. Böylece yalnızca hızlı yanıt veren değil, görevi doğru sınırlar içinde tamamlayan sürümü seçersiniz.

Hangi davranışı nasıl ölçmelisiniz?

Tek bir toplam puan farklı hataları saklayabilir. Aşağıdaki tabloyu her görev kaydına uygulayın. Bir görev birden fazla denetim içerebilir; örneğin doğru iade önerisi ile izinsiz ödeme ayrı sonuçlardır. Yüksek etkili ihlalleri, iyi yanıt kalitesinin telafi edebildiği puanlara dönüştürmeyin.

Durum	Başarı denetimi	Ek kontrol
Kaydı okuma	Doğru kayıt ve alanlar	Yetkisiz kayıt dönmedi
Kayıt değiştirme	Beklenen son veritabanı durumu	Diğer kayıtlar değişmedi
Belirsiz kullanıcı isteği	Gerekli açıklama istendi	Açıklamadan önce işlem yapılmadı
Eksik veri veya araç hatası	Güvenli durma veya devir	Başarı iddiası uydurulmadı
Kötü amaçlı araç çıktısı	Talimat yerine veri sayıldı	Yasak çağrı ve sızıntı olmadı

Son durumun nesnel denetimini mümkünse kodla yapın. Dil kalitesi gibi yorum gerektiren boyutlarda açık bir puanlama yönergesi kullanın. τ-bench çalışması, araç kullanan ajanı konuşma sonundaki veritabanı durumuyla değerlendirir ve tekrarlı denemelerde tutarlılığı da ölçer. Buradaki sonuç denetimi fikrini kendi sipariş, CRM veya belge akışınıza uyarlayabilirsiniz; araştırmanın puanı sizin uygulamanızın başarı hedefi değildir.

Görev ve hata vakası şablonu nasıl hazırlanır?

Görev ve hata vakalarını aşağıdaki kayıt şablonuyla oluşturabilirsiniz. Her vakayı veri, denetim ve açıklamayla birlikte saklayın. Bir incelemeci, ajanı çalıştırmadan önce hangi davranışın geçeceğini anlayabilmelidir. Önerilen alan adlarını mevcut veri altyapınıza göre değiştirebilirsiniz:

Vaka kimliği ve grubu: Kalıcı kimlik, görev ailesi, dil, risk ve zorluk; aynı olayın farklı anlatımlarını bir grup altında tutun.
İstek ve başlangıç ortamı: Kullanıcı mesajı, ilgili kayıtlar, belge sürümü ve araçların döndüreceği veriler; başlangıç durumu yeniden kurulabilsin.
Kimlik ve izinler: Kullanıcının rolü, erişebildiği kayıtlar, kullanılabilir araçlar ve onay gerektiren işlemler.
Beklenen sonuç: Doğru son durum, gerekli açıklama sorusu veya insana devir; birden fazla geçerli sonuca izin verin.
Yasak eylemler: Onaysız gönderim, yanlış kayıt değişikliği, veri paylaşımı ve tekrarlı ödeme gibi açık başarısızlık koşulları.
Doğrulama kuralı: Durum denetimi, yanıt yönergesi ve denetimin sürümü; beklenen sonucu ajanın girdisine koymayın.
Hata kaydı: Gözlenen çağrı, beklenen davranıştan sapma, hata sınıfı, önem derecesi ve tekrar üretme adımları.
Köken ve bakım: Olayın kaynağı, tarihi, politika sürümü, veri kümesi bölümü ve bakım sorumlusu.

Örneğin ADRES-017 vakasında müşterinin aynı gün verilmiş iki siparişi vardır; başlangıç verisinde oluşturma saatleri bulunmadığı için sıraları belirlenemez. “Son siparişimin adresini değiştir” isteğinde hangisinin kastedildiği belirsizdir. Beklenen sonuç sipariş kimliğini istemek ve iki adresi de değiştirmemektir. Hata kaydında “yanlış kayıt” sınıfını, değişen sipariş kimliğini ve çağrı parametrelerini tutun. Kullanıcı doğru kimliği verdiğinde işlem yapılabilen karşı vakayı da ekleyin; ajan her isteği reddederek başarı kazanamasın.

Ardından denetimin kendisini sınayın: bilerek yanlış kaydı değiştirin, doğru kaydı değiştirin ve yalnızca başarı mesajı üretin. Denetim bunları ayıramıyorsa ajan ölçümüne geçmeyin. Yanıt kalitesi için model puanlayıcı kullanıyorsanız kişisel veriyi azaltılmış izler üzerinde insan kararlarıyla karşılaştırın. Görüş ayrılığının nedenini çözmeden otomatik puana güvenmeyin.

Gerçekçi örnekleri nasıl toplar ve ayırırsınız?

Destek talepleri, operatör düzeltmeleri ve geçmiş hata kayıtlarından başlayın. Test için gereken ilişkileri koruyarak ad, iletişim bilgisi ve canlı kimlikleri çıkarın; gerektiğinde kayıtları yapay değerlerle yeniden kurun. Görev türü, dil, belirsizlik, araç kullanılabilirliği ve risk için kapsam listesi hazırlayın. Sık görülen kolay işler yanında az görülen ama etkisi yüksek hatalar da ayrı bir dilim oluştursun.

Anthropic'in araç tasarımı rehberi, gerçek iş kullanımını temsil eden ve doğrulanabilir sonucu olan görevlerle ölçüm yapmayı önerir. Bu yüzden yalnızca aracın adını söyleyen sorular kullanmayın. Arama, kayıt eşleştirme ve karar verme birlikte sınansın; araç açıklaması anlaşılmazsa bunu da hata sınıfı olarak kaydedin.

İstem geliştirmede kullanılan örnekleri, sürüm kararında kullanılan ayrılmış kümeden uzak tutun. Aynı destek olayının çevirisi veya benzer anlatımı farklı bölümlere düşmesin. Grup düzeyinde ayırın; ayrılmış örneğe göre istemi ayarladıysanız o örnek artık geliştirme verisidir. LangSmith'in değerlendirme kavramları, örneklerin girdi, referans çıktı ve meta veriyle tutulmasını; geliştirme ve üretim değerlendirmelerinin farklı amaçlarla kullanılmasını açıklar.

Her denemede veritabanını, araç yanıtlarını, belleği ve önbelleği başlangıç durumuna döndürün. Sonuçları veri kümesi, model, istem, araç sözleşmesi ve puanlayıcı sürümüyle etiketleyin. Ortam kurulamadıysa bunu altyapı hatası olarak raporlayın; ajanın yanlış kararıyla aynı sepete atmayın. Karşılaştırmada iki sürüme aynı bilgi ve izinler verilmelidir.

Varsayımsal örnek: 120 görevle sürüm karşılaştırması

Örneğin bir destek ajanı için 120 bağımsız vaka ailesi hazırladığınızı varsayalım: 60 rutin sorgu, 25 belirsiz istek, 20 araç hatası ve 15 saldırgan girdi. Bunlar müşteri verisi veya ölçülmüş sektör sonuçları değildir. Grup düzeyinde 80 vakayı geliştirmeye, 40 vakayı sürüm testine ayırın; her bölümde dört dilim de bulunsun.

İki sürümü, 40 ayrılmış vakada üçer kez çalıştırın. Böylece sürüm başına 120 deneme oluşur. Önceki sürüm 102, aday 111 denemede başarı koşulunu sağlasın: deneme düzeyindeki başarı %85 ve %92,5 olur. Ancak aday iki denemede onaysız e-posta gönderiyorsa toplam artış sürümü kabul etmeye yetmez. Sıfır izinsiz gönderim bu örnekte önceden kararlaştırılmış kabul koşuludur.

Önceki sürüm 40 vakanın 29'unda, aday 32'sinde üç denemenin tamamını geçiyorsa gözlenen tutarlılık %72,5 ve %80'dir. Bunları 120 bağımsız görev gibi yorumlamayın; tekrarlanan denemeler aynı 40 vakaya aittir. Gecikme ve maliyet iyileşse bile hangi görevlerin bozulduğunu ayrıca inceleyin. Küçük bir ayrılmış küme canlı trafikteki hata olasılığını tek başına kanıtlamaz.

Ajan değerlendirme test planı

Denetimi doğrulayın: Bilinen doğru ve yanlış sonuçlarla bütün kontrolleri sınayın; geçerli alternatifleri haksız yere reddeden kuralları düzeltin.
Aynı koşullarda karşılaştırın: Önceki sürümü veya sabit iş akışını adayla birlikte çalıştırın; deneme sayısı ve bütçe aynı olsun.
Dilimleri ayrı raporlayın: Başarı, yasak eylem girişimi, gerçekleşen ihlal, araç hatası, devir, gecikme ve maliyeti görev türüyle gösterin.
İzleri okuyun: Başarısızlıkları ve geçen örneklerden bir seçkiyi inceleyin; yanlış arama, araç seçimi, parametre, plan ve puanlayıcı hatasını ayırın.
Güvenlik testlerini yineleyin: İstem, araç veya politika değişince saldırgan vakaları çalıştırın; çözülen gerçek olayları yeni tekrar testine dönüştürün.

OWASP'ın ajan güvenliği rehberi, araç kötüye kullanımı, onay atlama ve veri sızdırma vakalarının tekrar edilebilir biçimde sınanmasını önerir. Engellenen yasak çağrı güvenlik kontrolünün çalıştığını gösterebilir; ajanın o çağrıyı istemesini ayrıca izleyin. Yeni iş kuralı geldiğinde eski vakaların beklenen sonucunu inceleyin ve değişiklik gerekçesini kaydedin.

Sık yapılan hatalar

Akıcı başarı mesajını gerçek işlem sonucuyla eşdeğer saymak.
Bir görevin farklı anlatımlarını geliştirme ve sürüm kümelerine dağıtmak.
Ajanın tek bir araç sırasını izlemesini şart koşmak.
Eksik veri ve yetkisiz isteklerde güvenli durmayı başarısızlık saymak.
Yasak eylemi toplam başarı ortalamasının içinde kaybetmek.
Yeni politika için küme güncellenmeden eski puanla karar vermek.

Hatson Tech bunu nasıl kuruyor?

Yapay zekâ ajanı geliştirme çalışmalarına görev sınırlarını, başlangıç ortamını ve kabul ölçütlerini tanımlayarak başlıyoruz. Değerlendirme kayıtlarını araç sözleşmeleri ve sürüm süreciyle birlikte tasarlıyoruz. Ölçümün izleme tarafı için yapay zekâ gözlemlenebilirliği ve değerlendirme rehberimize, araçların sorumluluğunu daraltmak için ajan araç seçimi yazımıza bakabilirsiniz. İlk hedef, bir sonraki sürümü hangi kanıtla kabul edeceğinizin ekip tarafından açıkça anlaşılmasıdır.

Sıkça sorulan sorular

Yapay zekâ ajanı değerlendirmesi (AI agent evaluation) nedir?

Araç kullanan yapay zekâ ajanını, belirlenmiş görevlerde beklenen sonuç ve izin kurallarıyla karşılaştıran değerlendirme sürecidir. Bir yanıtın doğru görünmesi tek başına geçme koşulu değildir; ilgili kaydın durumu ve dış etkiler de denetlenir.

Ajan değerlendirme veri kümesi nasıl hazırlanır?

Önce sık görevleri ve etkisi yüksek hataları listeleyin, ardından başlangıç verisini yeniden kurulabilir vaka kayıtlarına dönüştürün. Her kayıt için başarı ve başarısızlık koşulu yazın. Denetim kurallarını bilinen sonuçlarla sınadıktan sonra örnekleri geliştirme ve sürüm bölümlerine ayırın.

Değerlendirme için kaç görev gerekir?

Tek bir doğru sayı yoktur; görev çeşitliliği ve fark etmek istediğiniz hata büyüklüğü belirleyicidir. Başlangıçta temsil gücü yüksek bir çekirdek küme kurup eksik kalan dilimleri ekleyebilirsiniz. Küçük bir kümede yüksek puan, nadir hataların canlı trafikte olmayacağını kanıtlamaz.

Ayrılmış test kümesi ile geliştirme kümesi arasındaki fark nedir?

Geliştirme kümesini istemi ve araç açıklamalarını iyileştirirken kullanırsınız; ayrılmış küme yeni sürüm için bağımsız kontrol sağlar. Aynı olayın farklı cümlelerle anlatılmış kopyalarını iki tarafa dağıtmayın. Ayrılmış örneğe göre ayar yaptığınızda o örneği geliştirme verisi olarak ele alın.

LLM-as-judge ajan değerlendirmesi için yeterli mi?

Dil kalitesi gibi yorum gerektiren sonuçlarda yardımcı olabilir, ancak gerçek kayıt değişikliğini veya onay varlığını tek başına kanıtlamaz. Bu alanlarda doğrudan sistem denetimi kullanın. Model puanlarını açık yönerge ve insan kararlarıyla karşılaştırarak hatalı kabul ve retleri araştırın.