Yapay zekâ ajanları geliştiren ekiplerin, sistemin olması gerektiği gibi çalışıp çalışmadığını anlamak için yalnızca nihai yanıtı kontrol etmekten fazlasına ihtiyacı vardır. Getirme, üretim ve araç çağırmayı birleştiren uygulamalarda yanlış sonuç, sorun görünüşte yalnızca nihai metinde ortaya çıksa bile yanlış veritabanının seçilmesinden veya uygun olmayan belgelerin getirilmesinden kaynaklanabilir. InfoQ üzerinden yaptığı bir sunum sırasında Elastic’in baş veri bilimcisi Susan Chang, şirketin siber güvenlikte ve kurumsal sohbet robotlarında kullandığı ajanları değerlendirmek için ortak bir çerçeveyi nasıl geliştirdiğini açıkladı.
Yalıtılmış değerlendirmelerden ortak araçlara
Elastic ekipleri, her ajan için ayrı veri kümeleri, değerlendiriciler ve izleme süreçleri oluşturarak başladı. Saldırı tespit ajanı örneğinde testler, analistler ve güvenlik araştırmacıları tarafından hazırlanan saldırı ve normal davranış senaryolarını; kesinlik ve geri çağırma, olgusal doğruluk, benzerlik ve MITRE taktiklerinin sınıflandırılması gibi metriklerle içeriyordu. Kurum verilerine dayanan sohbet robotları ise belgelerden soru ve getirme işlemlerini test ediyor; yanıtın uygunluğu ve eksiksizliği, ürün tanımlayıcılarının doğruluğu ve ES|QL sorgularının oluşturulmasına odaklanıyordu.
Bu kullanım alanlarının farklı olması, işlerin büyük ölçüde tekrarlanmasına yol açtı. Bu nedenle Elastic, farklı veri kümesi türlerini birleşik bir şema kapsamında içe aktarabilen, yürütme izlerine dayalı değerlendirmeler çalıştırabilen ve RAG uygulamaları için ortak değerlendiricilerin yanı sıra her ürüne özel bileşenler sunabilen ortak bir çerçeve oluşturdu. Süreç yerel olarak çalıştırılabilir, veriler yüklenebilir, ajan çalıştırılabilir, sonuçlar toplanabilir ve puanlar geliştiricilere gösterilebilir.
Başarısızlığın nedenini anlamak için izleme şart
Deneyim, ajan izlemesinin nihai çıktısıyla sınırlı olmaması gerektiğini doğruluyor. Ajanın çağırdığı araçlar, vektörel ve anahtar kelime tabanlı aramalar, getirilen veriler, belirteç tüketimi, yanıt süresi ve kararların sıralaması kaydedilmelidir. Bu ayrıntı düzeyi, belirli bir araç çağrısının değerlendirilmesini veya sorun nihai yanıtta ortaya çıkmadan önce ajanın yanlış bir kaynak kullandığının tespit edilmesini sağlar.
Ayrıca kullanıcıların bildirdiği, örneğin olumsuz değerlendirme gibi başarısız durumlar, test kümesine yeni örnekler olarak dönüştürülebilir. Böylece üretim geri bildirimleri, geliştirme döngüsünden ayrı manuel notlar olarak kalmak yerine sonraki sürümlerde regresyon testlerinin bir parçası hâline gelir.
LLM-as-a-judge neden yeterli değil?
Elastic, stil, tutarlılık ve yanıtın bağlama uygunluğu gibi açık uçlu veya belirsiz görevlerde diğer modellerin çıktılarını değerlendirmek için dil modellerini kullandı. Bu yaklaşım, uzun bir metni değerlendirmek için kesin bir kural yazmanın zor olduğu durumlarda değerlendirmeyi ölçeklendirmeyi sağlar. Ancak bir çalıştırmadan diğerine farklı sonuçlar verebilir ve mevcut olmayan bir ürün tanımlayıcısı veya geçersiz bir sorgu oluşturulması gibi belirli hataları tespit edemeyebilir.
Bu nedenle Elastic, LLM-as-a-judge yaklaşımını kurallara ve programlamaya dayalı deterministik değerlendirmelerle birleştirdi. Bu değerlendirmeler JSON veya YAML yapısını, biçimin doğruluğunu, gerekli varlıkların bulunmasını ve kodun veya sorgunun çalıştırılabilirliğini; ayrıca kesinlik, geri çağırma ve olgusal doğruluk gibi metrikleri inceler. Bu birleşim, yanıtın açık olduğu durumlarda değerlendirme maliyetini ve süresini azaltır; anlamsal hükmü ise kurallara indirgenmesi zor görevlere bırakır.
Neler genellenemez?
Elastic, uzmanlaşmış test verilerinin oluşturulmasını tamamen otomatikleştirilebilir bir süreç olarak görmedi. Siber güvenlikte ekip, neyin gerçek bir saldırı oluşturduğunu ve son kullanıcı için hangi davranışın kabul edilebilir olduğunu belirlemek üzere analistlere ve araştırmacılara ihtiyaç duyar. Ayrıca regresyonun tanımı ajanlar arasında değişir; örneğin belirli bir güncellemeden sonra güvenlik ajanı, normal veriler girildiğinde bile saldırı olduğunu ilan etmeye daha yatkın hâle gelebilir.
Değerlendiricilerin kalibrasyonu da her ekibin sorumluluğunda kalır. Dil tabanlı değerlendirici aynı durum için farklı puanlar verirse veya hedeflenen insan değerlendirmesiyle uyuşmazsa, ortak çerçeve yazılım altyapısının kalitesi ne olursa olsun yanıltıcı sayılar üretir. Chang ayrıca üretim ve değerlendirme için aynı model ailesinin üyeleri kullanıldığında değerlendirici yanlılığı riskine de dikkat çekti; bu durumda değerlendirici, söz konusu modellerin performansını olduğundan yüksek tahmin edebilir.
Ekipler açısından pratikte ne değişiyor?
Elastic’in deneyimi, ideal bir küme beklemek yerine 20 ila 50 arasında değişebilen küçük bir test örnekleri kümesiyle başlamayı öneriyor. İlk aşamalarda, özellikle kullanım alanları ve metrikler hâlâ keşfedilirken, öğrenmeyi hızlandırmak için dağınık çalışmalar kabul edilebilir. Ancak birden fazla ajan üretime alındığında, performans sorularını yanıtlamak ve kullanıcı sorunlarını teşhis etmek için temel izleme ve değerlendirme zorunlu hâle gelir.
Elastic ayrıca bazı değerlendirme araçlarını Python’dan TypeScript’e taşıdı; bunun amacı TypeScript ile yazılmış üretim koduyla uyum sağlamak ve Playwright ile Scout adlı, özel olarak geliştirilmiş dahili bir aracı kullanmaktı. Bu adım, tüm veri bilimi değerlendirmelerinin taşınmasının gerekli olduğu anlamına gelmez; ekibin test ettiği şeyle sistemin gerçekte yürüttüğü şey arasındaki farkı azaltmaya yönelik belirli bir ihtiyacı yansıtır. Pratik sonuç şudur: Ortak çerçeve şemayı, çalıştırmayı ve genel metrikleri standartlaştırabilir; ancak alan uzmanlığının veya neyin başarı, neyin başarısızlık sayılması gerektiğine ilişkin hükmün yerini alamaz.