Eval Olmadan AI Ajanı Canlıya Alınır mı? Golden Set Nedir

Eval olmadan AI ajanı canlıya alınır mı?

Teknik olarak alınır. Ama ajanın gerçek vakaların kaçında doğru çalıştığı bilinmez ve bir güncellemenin yarattığı bozulma çoğu zaman müşteri şikâyetiyle fark edilir.

Şöyle bir senaryo düşünün. Bir kliniğin WhatsApp asistanı üç haftadır randevu sorularını cevaplıyor ve kimse şikâyet etmiyor. Kampanya dönemi geliyor, biri asistanın talimatına "yeni kampanyayı da anlat" satırını ekliyor. Kampanya soruları iyi cevaplanıyor. Aynı günden itibaren asistan, kampanyayla ilgisi olmayan fiyat sorularında da indirimli rakamı söylemeye başlıyor. Resepsiyon bunu bir hafta sonra, hastanın gösterdiği ekran görüntüsünden öğreniyor.

Bu senaryoda kimse ihmal yapmadı. Değişiklik mantıklıydı ve test edilen soru doğru cevaplandı. Eksik olan tek şey, değişiklikten sonra eski soruların da yeniden sorulmasıydı. Eval tam olarak bu işi yapıyor.

Sorunun yaygınlığını LangChain'in State of Agent Engineering anketi gösteriyor. 1.300'den fazla kişinin katıldığı çalışmada katılımcıların %57'si ajanlarını production'da kullanıyor, %32'si de kaliteyi en büyük engel olarak görüyor. Ajanını izleyen, yani gözlemlenebilirlik (observability) kuran ekiplerin oranı yaklaşık %89. Eval yapanların oranı %52'de kalıyor. İzleme size ajanın ne yaptığını gösteriyor. Yaptığı şeyin doğru olup olmadığını ise eval söylüyor.

AI ajanında eval tam olarak ne demek?

Ajanın, önceden seçilmiş gerçek vakalarla ve yazılı ölçütlerle düzenli olarak sınanması. Her değişiklikten sonra aynı sınav tekrarlanıyor, yeni puan bir önceki puanla karşılaştırılıyor.

Yazılım ekipleri bu fikre otomatik testlerden aşina. Fark şurada: ajan aynı soruya her seferinde aynı cümleyle cevap vermiyor. Klasik test "çıktı tam olarak bu mu?" diye soruyor. Eval ise "çıktı işin gerektirdiğini yapıyor mu?" diye soruyor. Doğru fiyatı söyledi mi, olmayan bir indirim uydurdu mu, randevu için gerçekten boş bir saat önerdi mi?

Çalışan bir eval düzeninde üç parça bulunuyor: vakaların listesi (golden set), her vakayı puanlayan kontroller ve puanların biriktiği bir sonuç tablosu. Bunlar kurulduktan sonra prompt'u, modeli ya da bağlanan sistemi değiştiren herkes aynı soruyu cevaplayabiliyor. Bu değişiklik ajanı iyileştirdi mi, yoksa bir yerini bozdu mu?

Golden set nedir, içinde neler bulunur?

Golden set, gerçek işten seçilmiş girdilerle her girdi için beklenen doğru davranışın yazıldığı listedir. Ajanın sınav kâğıdı ve cevap anahtarı gibi çalışır, her değişiklikte aynen yeniden kullanılır.

Adındaki "golden", setin doğruluğu üzerinde anlaşılmış bir referans olmasından geliyor. Her satır bir müşteri mesajı ile o mesaja verilecek doğru tepkinin tarifinden oluşuyor. Tarif çoğu zaman birebir cevap metni olmuyor. Ajan aynı doğru cevabı farklı kelimelerle de verebilir. Bu yüzden beklenen davranış, tek tek kontrol edilebilen maddeler halinde yazılıyor.

Etiketler küçük bir ayrıntı gibi duruyor, sonuç tablosunu okunur kılan ise onlar. Ortalama puan %90 çıktığında kalan %10'un fiyat sorularında mı yoksa basit selamlaşmalarda mı toplandığını etiketler gösteriyor. İlki yayını durdurur. İkincisi bekleyebilir.

Golden set kaç örnekle kurulmalı?

Başlangıç için gerçek hatalardan seçilmiş 20-50 vaka yeterli. Ajan olgunlaştıkça set 100'ün üzerine, müşteriye doğrudan cevap veren kritik işlerde birkaç yüz vakaya çıkar.

Ekiplerin eval'i ertelemesinin en sık gerekçesi, yüzlerce örnek gerektiği düşüncesi. Anthropic'in mühendislik blogundaki ajan eval'leri yazısı bu kaygıya doğrudan cevap veriyor. Yazıya göre gerçek hatalardan seçilmiş 20-50 basit görev iyi bir başlangıç. Gerekçesi de basit: geliştirmenin erken aşamasında her değişikliğin etkisi belirgin olduğu için küçük bir örneklem farkı görmeye yetiyor.

Projelerimizde izlediğimiz merdiven şöyle:

Sayıdan önemli olan, vakaların gerçek dağılımı temsil etmesi. Elli vakanın kırk beşi selamlaşmaysa set size pek bir şey söylemez.

Golden set'teki vakalar nereden seçilmeli?

Gerçek trafikten: geçmiş mesajlar, maskelenmiş müşteri talepleri ve daha önce yaşanmış hatalar. Ekibin masa başında hayal ettiği örnekler en zor vakaları neredeyse her zaman kaçırıyor.

Masa başında yazılan örnek temiz oluyor. Gerçek müşteri ise yazım hatası yapıyor, iki soruyu tek mesajda soruyor, sesli mesaj gönderip ardından "dinleyemiyorsanız yazayım" diyor. Ajanın zorlandığı yer bu uzun kuyruk. Son birkaç ayın kayıtlarından ayıklanmadan seçilen vakalar kuyruğu sete taşıyor. Kişisel veri içeren kayıtlar sete girmeden önce maskeleniyor ve set işletmenin kendi ortamından çıkmıyor.

Ajan henüz canlıya çıkmadıysa elde hata kaydı da yok. Bu boşluğu doldurmanın yolu premortem. Ekip bir saatliğine oturup tek bir soruya cevap arıyor: "Üç ay sonra bu ajan bize müşteri kaybettirdi. Neden?" Böyle bir oturumdan 20-40 başarısızlık senaryosu çıkarmak mümkün. İlk onu zaten herkesin aklındaki şeyler oluyor. Değer sonrakilerde: ajan belirsiz bir soruda tahmin mi yürütüyor, takvim sistemine ulaşamazsa hastaya ne söylüyor, iki kişi aynı saati isterse ne yapıyor?

Canlıya çıktıktan sonra kaynak değişiyor. Yakalanan her gerçek hata sete yeni bir vaka olarak giriyor, böylece aynı hatanın ikinci kez yayına çıkması zorlaşıyor. Golden set bu yüzden ajanla birlikte büyüyor.

Golden set'in cevap anahtarını kim yazmalı?

İşi en iyi bilen kişi: resepsiyon sorumlusu, muhasebe şefi ya da destek ekibinin lideri. Yazılım ekibi formatı kurar, neyin doğru cevap sayılacağına iş tarafı karar verir.

Bu soru teknik yazılarda nadiren soruluyor. Oysa eval'in kalitesini en çok etkileyen karar bu. Ajanı kuran mühendis, cumartesi günü hangi tedavilerin yapılmadığını ya da hangi soruların mutlaka hekime aktarılması gerektiğini bilmiyor. Bunu bilmeyen birinin yazdığı cevap anahtarı ajanı yanlış davranışlar için ödüllendiriyor ve puan yükseldikçe herkes yanlış yönde rahatlıyor.

Pratikte iş birkaç saatlik bir oturumla çözülüyor. Mühendis vakaları tabloya diziyor, işi bilen kişi her satırın yanına "burada ne olmalı" notunu düşüyor. Anlaşmazlık çıkan satırlar en değerlileri, çünkü çoğu zaman hiçbir yerde yazılı olmayan bir iş kuralını ortaya çıkarıyorlar. Pilotların neden production'a geçmediğini anlattığımız yazıda iş tarafında isimli bir sahibin önemine değinmiştik. Cevap anahtarını yazan kişi çoğu zaman o sahibin kendisi oluyor.

Ajanın cevabı nasıl puanlanır?

Ucuzdan pahalıya katmanlarla. Önce kodla kesin kontrol edilebilen kurallar, sonra basit kontroller, en son başka bir modelin yazılı ölçütle yaptığı değerlendirme geliyor. Yargıç model düzenli olarak insanla karşılaştırılıyor.

Mümkün olan her şeyi ilk katmanda çözmek iyi bir kural. Fiyatın doğruluğunu bir modele sormak hem pahalı hem gereksiz, çünkü bir satır kodla kesin cevap alınabiliyor. Yargıç model ancak kuralla ölçülemeyen boyutlarda devreye giriyor.

Yargıç modelin de denetlenmesi gerekiyor. Bizim kuralımız şu: insanların puanladığı 20-30 örnekte yargıç model insanlarla %85-90 oranında aynı sonuca varmıyorsa puanlarına güvenmiyoruz ve ölçütleri yeniden yazıyoruz. Yargıç olarak değerlendirilen ajandan farklı bir model seçmek de modelin kendi üslubunu kayırma riskini azaltıyor.

Ajan bir kez doğru cevap verdiyse her seferinde verir mi?

Vermeyebilir. Aynı vaka birkaç kez çalıştırılmalı. Denemelerin %75'inde başarılı olan bir ajanın aynı görevi üç denemenin üçünde de başarma ihtimali yaklaşık %42.

Dil modelleri aynı soruya her seferinde aynı cevabı vermiyor. Bir vakayı tek kez çalıştırıp geçti saymak, ajanın o vakada hep başarılı olacağı yanılgısını doğuruyor. Bunu ölçmek için kullanılan ölçünün adı pass^k: aynı görevin k denemenin hepsinde başarılması. Sierra ekibinin 2024'te yayımladığı τ-bench çalışması bu ölçüyü müşteri hizmetleri senaryolarında denedi. Dönemin en gelişmiş modelleriyle (GPT-4o gibi) kurulan ajanlar görevlerin yarısından azında başarılı oldu. Perakende senaryosunda aynı görevi sekiz denemenin sekizinde de başarma oranı %25'in altında kaldı.

Anthropic'in yukarıda andığımız yazısındaki hesap durumu sadeleştiriyor. Denemelerin %75'inde başarılı bir ajan, üç denemenin üçünü de (0,75)³ ile yaklaşık %42 ihtimalle geçiyor. Yazıda bu ölçünün özellikle müşteriyle konuşan ajanlarda önemli olduğu vurgulanıyor, çünkü müşteri ajandan her seferinde doğru davranmasını bekliyor.

Her vakayı üç kez çalıştırmak maliyeti üçe katlıyor. Bu yüzden tekrar yalnız kritik etiketli vakalara uygulanıyor. Fiyat, randevu onayı ve iptal gibi, hatasının bedeli yüksek 10-20 vaka çoğu ajan için yeterli.

Eval, canlıya alma kararını nasıl verir?

Eşikler önceden yazılır. Ortalama puan ve kritik vakalardaki tekrar başarısı eşiğin üzerindeyse değişiklik yayına çıkar, altındaysa bekletilir. Kararı toplantıdaki izlenim yerine sonuç tablosu veriyor.

Eval'in asıl gücü yayın kapısına bağlandığında ortaya çıkıyor. Prompt'ta tek kelime değişse bile tüm set yeniden çalışıyor. Puan bir önceki sürümün altına düşerse değişiklik canlıya çıkmıyor. Yazılımda bu düzenin adı regresyon kapısı. Baştaki klinik senaryosunda kampanya satırı eklendiğinde fiyat vakaları kırmızıya dönecek ve değişiklik hasta görmeden bekletilecekti.

Çalışırken kullandığımız eşikler şöyle: tüm sette ortalama puan en az 0,85, kritik vakalarda üç denemenin üçünü de geçme oranı en az %90. Bu rakamlar herkes için geçerli değil. Talep sınıflandıran bir ajanda daha esnek, müşteriye fiyat ya da tarih bildiren bir ajanda daha sıkı tutulabilir. Önemli olan, eşiğin yayından önce ve yazılı olarak belirlenmesi.

Sonuç tablosu üç karardan birine varıyor:

• Yayına hazır. Tüm ölçütler eşiğin üstünde, kritik vakalarda hata yok, bilinen sınırlar yazılı.
• Pilotu uzat. Puanlar yükseliyor ama eşiğe ulaşmadı. Hangi etikette eksik kaldığı belli, iyileştirme listesi somut.
• Geri dön. Kritik bir hata var ya da puan önceki sürümün altına düştü. Değişiklik canlıya çıkmıyor, önce kök neden bulunuyor.

Bu düzenin bir yan faydası da var. Model sağlayıcısı yeni bir sürüm çıkardığında geçişin güvenli olup olmadığını tahmin etmek gerekmiyor. Aynı set yeni modelle çalıştırılıyor ve cevap sonuç tablosunda görünüyor.

Eval kurmaya ne zaman başlanmalı?

Ajanın ilk satırı yazılmadan önce. Başarı ölçütü ve ilk 20-50 vaka kod başlamadan hazırsa, her geliştirme adımı bir sayıyla değerlendiriliyor ve tartışmalar kısalıyor.

Eval'i sona bırakan projelerde sık görülen bir sorun var. Ajan haftalarca geliştiriliyor, ölçüm kurulduğunda ise kimse ilk sürümün ne kadar iyi olduğunu bilmiyor ve karşılaştırılacak bir başlangıç noktası kalmıyor. Ölçüt baştan yazıldığında ajan kurulmadan önce mevcut süreç de ölçülebiliyor: resepsiyonun bugün kaç mesajı kaç dakikada cevapladığı, ne sıklıkla eksik bilgi verdiği. Ajanın değeri bu başlangıç noktasına göre hesaplanıyor. Hesabın yöntemini yapay zeka ROI yazısında adım adım gösterdik.

Araç seçimi ikinci planda kalabilir. İlk set için bir tablo ve basit bir betik yetiyor. DeepEval, promptfoo, Braintrust ya da LangSmith gibi araçlar hacim büyüdüğünde işi kolaylaştırıyor, ama hiçbiri cevap anahtarını sizin yerinize yazmıyor.

İlk ajanın hangi işe kurulacağı henüz belli değilse ilk otomasyon adayını seçme yazısı iyi bir başlangıç noktası. Mesajlaşma ve randevu tarafında somut bir örnek arıyorsanız klinik WhatsApp randevu otomasyonu yazısına göz atabilirsiniz.

Sık sorulan sorular

Eval'li bir ajanda her değişikliğin ölçülebilir bir sonucu oluyor: puan yükseldi ya da düştü. Prompt'a satır eklemek, modeli yükseltmek ya da ajanı yeni bir sisteme bağlamak böylece tahmin işi olmaktan çıkıyor. Diğer yazılara blog sayfasından, çalışma biçimimize hizmetler sayfasından ulaşabilirsiniz.