AI ajanı değerlendirmesi: Tek deneme yerine son durumu ölçün

Üretimdeki bir AI ajanını değerlendirmek için her göreve ölçülebilir bir başarı koşulu yazın, görevi temiz bir başlangıç durumundan birden fazla kez çalıştırın ve her denemenin sonunda hedef sistemin gerçek durumunu kontrol edin. Son mesajı, araç çağrılarını ve gerçekleşen işlemi ayrı kaydedin. OpenAI’ın değerlendirme kılavuzu, aynı girdinin farklı çıktılar üretebildiğini ve geleneksel tek sonuçlu testlerin bu değişkenlik karşısında yetersiz kalabildiğini belirtiyor.

Bir ajanın “işlem tamamlandı” demesi başarı koşulu değildir. Anthropic’in ajan değerlendirme açıklaması, varsayımsal bir uçuş rezervasyonunda son mesaj ile SQL veritabanında gerçekten bulunan rezervasyonu ayrı sonuçlar olarak ele alıyor. İşlem yapan bir ajan için temel ayrım budur: beyanı iletişim açısından, sistemdeki değişikliği görev başarısı açısından ölçün.

Her görevi başarı koşullarıyla kaydedin

Test kaydı yalnızca kullanıcı isteğinden oluşmamalı. Başlangıç durumunu, ajanın kullanabileceği araçları ve yetkileri, kabul edilebilir son durumu ve korunması gereken kayıtları birlikte tanımlayın. “Talebi çöz” ifadesi değerlendirici için fazla açıktır; hangi kaydın değişebileceği ve hangi kaydın değişmemesi gerektiği önceden yazılırsa sonuç denetlenebilir hâle gelir.

Tamamen varsayımsal bir destek görevinde müşteri uygun bir siparişi iptal etmek istiyor olsun. Görev kaydı ilgili siparişin başlangıç durumunu, iptal koşulunu ve beklenen son durumu içerir: doğru sipariş iptal edilmiş, diğer siparişler korunmuş ve müşteriye verilen bilgi gerçekleşen işlemle tutarlı olmalıdır. İptale uygun olmayan bir talep de ayrı görev olarak eklenebilir. Böylece sistem, işlem yapması gereken durumla işlemden kaçınması gereken durumu ayırt edip etmediği açısından ölçülür.

Görevleri ürünün gerçek kullanımına benzeyen isteklerden, destek kayıtlarından ve saptanmış hatalardan derleyin. Her göreve sürüm verin; istek, ortam veya başarı koşulu değiştiğinde eski puanla yeni puanı aynı testin sonucu gibi karşılaştırmayın. Gerçek kullanıcı verileri test ortamına aktarılacaksa erişim ve gizlilik koşullarını hazırlık aşamasında uygulayın.

Son durumu ajandan bağımsız denetleyin

İşlem görevlerinde ana değerlendirici, ajanın yazdığı açıklamayı okumak yerine hedef sistemin bıraktığı sonucu sorgulamalıdır. Bu sonuç göreve göre veritabanı kaydı, dosya içeriği veya yetkili bir API’den alınan güncel durum olabilir. Kontrolün ajanın kendi mesajına dayanması, “yaptım” beyanını gerçek işlemle karıştırır.

Varsayımsal sipariş iptalinde değerlendirici doğru siparişin durumunu okur; ardından ilgisiz siparişlerde değişiklik olup olmadığını denetler. Doğru kayıt değişmiş olsa bile başka bir müşterinin kaydı da değiştiyse görev geçmez. Tersine, işlem gerçekleşmiş fakat ajan kullanıcıya başarısız olduğunu söylemişse görev sonucu ile iletişim sonucu farklı puanlar alır. Bu ayrım, tek bir başarı etiketinin saklayacağı sorunları görünür kılar.

Son durum koşulunu ajana göre sonradan uyarlamayın. Beklenen sonucu görev yazılırken tanımlayın ve bilinen bir doğru çözümün bu denetimden geçtiğini kontrol edin. Araştırma gibi dış sistemde değişiklik bırakmayan görevlerde ise başarı koşulu farklıdır: verilen bilgilerin dayanağı, kapsamı ve kullanıcı isteğine uygunluğu değerlendirilir.

Bağımsız denemelerle değişkenliği ölçün

Aynı görevin bir kez geçmesi, sonraki çalıştırmada da geçeceğini göstermez. Görevi aynı sürüm ve eşdeğer başlangıç verisiyle tekrar çalıştırın; başarılı denemelerin toplam denemelere oranını her görev için ayrı hesaplayın. Genel ortalamanın yanında bazen geçen bazen kalan görevleri de gösterin. Kullanıcının tek bir çalıştırmaya güvenmek zorunda olduğu üründe bu dalgalanma doğrudan önem taşır.

Her deneme temiz bir ortamdan başlamalıdır. Önceki denemeden kalan kayıt, dosya veya önbellek sonraki sonucu kolaylaştırabilir; paylaşılan bir altyapı arızası da birden fazla denemeyi birlikte bozabilir. Bunlar ajanın davranışıyla karıştırılmamalıdır. Deneme kaydında görev sürümünü, model ve istem sürümünü, araç izinlerini, başlangıç ortamını ve varsa altyapı hatasını tutun.

Raporun paydasını açık bırakmayın: hangi görevin kaç denemede çalıştığı ve başarının hangi son durum koşuluna göre verildiği görülebilmeli. Tekrar sayısı arttıkça yalnızca başarı oranına bakmak da yeterli değildir; kritik bir görevin aralıklı başarısızlığı, aynı ortalamaya sahip daha düşük etkili bir görevden farklı bir ürün kararı gerektirebilir.

Değerlendiriciyi sonuç, iz ve iletişim için ayırın

Kesin denetlenebilen koşulları kodla ölçün: doğru kaydın değişmesi, yasaklı bir değişikliğin olmaması veya beklenen dosyanın çalışması gibi. İşlem sırasında zorunlu bir yetki kontrolü varsa bunu işlem izinde ayrıca arayın. Bunun dışındaki her araç çağrısını değişmez bir sıraya bağlamak, aynı sonuca geçerli başka bir yoldan ulaşan ajanı haksız yere başarısız gösterebilir.

LangChain’in işlem izi açıklaması, yalnızca son çıktıya bakmanın araç seçimi ve ara adımlardaki hataları kaçırabildiğini anlatıyor. Her deneme için kullanıcı girdisini, araç çağrılarını ve yanıtlarını, son mesajı, ortam denetimini ve değerlendirici kararını ortak bir kimlikle saklayın. Böylece bir başarısızlıkta hatanın araç seçiminden mi, araç sonucunun yorumlanmasından mı, yoksa işlemin uygulanmamasından mı kaynaklandığı incelenebilir.

Üslup, açıklık veya belirsiz niyetin ele alınışı gibi yoruma açık nitelikler için ölçütleri somut bir rubriğe dönüştürüp model tabanlı değerlendirici kullanabilirsiniz. Değerlendiriciye hangi kanıta bakacağını, başarısızlığın ne olduğunu ve kanıt yetmiyorsa nasıl karar vereceğini söyleyin. Onun metin puanı, veritabanı veya dosya üzerinde yapılacak son durum kontrolünün yerine geçmez.

İnsan incelemesiyle puanlama hatalarını bulun

Başarılı, başarısız ve sınırda görünen denemelerden örnekler seçip konu uzmanlarına görev koşulunu, işlem izini ve son durumu birlikte inceletin. Uzman ile otomatik değerlendirici ayrıştığında yalnızca etiketi değiştirmek yetmez: görev tanımı belirsiz olabilir, değerlendirici geçerli bir çözümü reddetmiş olabilir veya ajan gerçekten yanlış işlem yapmış olabilir. Her durum farklı bir düzeltme gerektirir.

Doğrulanmış hata biçimlerini yeni regresyon görevlerine dönüştürün ve görev kümesini ürün değiştikçe güncelleyin. Yayın öncesi değerlendirmede genel başarı oranının yanında kritik görevlerin sonuçları, tekrarlar arasındaki değişkenlik ve insan incelemesinde saptanan puanlama uyuşmazlıkları birlikte görünmelidir. Bu kayıtlar, model veya istem değişikliğinin kullanıcı adına yapılan işi nasıl etkilediğini karşılaştırmak için somut bir temel sağlar.

Ayrıca okuyun: