Yeni model kıyaslamaları yapmayı bırakın ve ajanınızın bir aboneliği iptal etmeye çalışmasını izlemeye başlayın. Bu iki aktivite arasındaki fark, üretim sistemlerinin çöktüğü yerdir. Tek turlu bir test, bir yanıtın kulağa hoş gelip gelmediğini söyleyebilir. Ancak ajanın yanlış müşteriye iade yapıp yapmadığını, bir takvim API'sine karşı on dört kez döngüye girip girmediğini veya dolandırıcılık kontrolünü tamamen atlamaya karar verip vermediğini söyleyemez. Metin, bir ajanın ürettiği en az tehlikeli şeydir. Gerçek riskler, dokunduğu araçlarda, değiştirdiği verilerde ve yardım istemesi gerekirken devam ettiği anlarda gizlidir.

Metin Kıyaslamaları Üretim Ortamında Neden Başarısız Olur

Standart kıyaslamalardaki yüksek puanlar, yanıltıcı bir konfor biçimi haline geldi. Zarif bir metin yazan bir ajan, operasyonel bir tehlike olmaya devam edebilir. Sisteminiz randevu aldığında, veritabanı kayıtlarını düzenlediğinde veya destek talepleri oluşturduğunda, üretilen metin iş akışının yalnızca görünen yüzüdür. Altta ajan; hangi uç noktaya (endpoint) hitap edileceği, hangi veri paketinin (payload) gönderileceği ve ne zaman durulacağı konusunda somut kararlar verir. Kaynakları çift rezervasyon yaparak, yanlış satırı değiştirerek veya hassas bir durumu bir günlük (log) dosyasına sızdırarak size para kaybettirirken, bir okuduğunu anlama liderlik tablosunda zirveye oynayabilir. Sadece çıktının cilasına değil, işin mekaniğini doğrulamaya ihtiyacınız var. Eğer bir ajan çevrimdışı bir QA testinde iyi puan alıp hala döngüye girerek veya bir aracı yanlış kullanarak iş akışınızı bozuyorsa, değerlendirmeniz yanlış sinyallere bakıyor demektir.

Beş Bağımlılığın Haritalandırılması

Van Data Team ekibi, her değerlendirmeye beş belirli kontrol noktasını haritalandırarak başlar. Bu, soruyu tamamen değiştirir. Bir modelin diğerinden daha akıllı olup olmadığını sormayı bırakırsınız. Ajanın gerçek kısıtlamalarınız altında bir üretim görevini gerçekten bitirip bitiremeyeceğini sormaya başlarsınız.

İş sonuçları. "Tamamlandı" ifadesinin dolar ve müşteri etkisi açısından ne anlama geldiğini tanımlayın. Bir görev, ajan bir özet sunduğu için tamamlanmış sayılmaz. Görev; envanter kaydı doğru olduğunda, randevu onaylandığında ve müşteri geçerli bir takip numarası aldığında tamamlanmış olur.

Değiştirilebilir durum (Mutable state). Ajanın tam olarak neleri değiştirmesine izin verildiğini bilin. Hangi tablolar, hangi durumlar, hangi hesap bayrakları? Eğer ajan iade yapabiliyor, işleri yeniden planlayabiliyor veya fatura adreslerini güncelleyebiliyorsa, dokunduğu her alanı envanter haline getirmeniz gerekir.

Araç izinleri. Hangi API uç noktalarının ve işlevlerinin kapsam dahilinde olduğu konusunda açık olun. Arama aracı, yazma aracı ve bildirim aracına erişimi olan bir ajan, sınırlar belirsizse bunları birbirine karıştıracaktır. Her izni belirli bir operasyonel ihtiyaca eşleyin.

Hata kurtarma. Takvim API'sinin zaman aşımına uğraması, 500 hatası döndürmesi veya hatalı JSON döndürmesi durumunda ne olacağına karar verin. Ajan paniklememeli, başarılı bir mesaj uydurmamalı (hallucinate) veya sonsuza kadar yeniden denememelidir. Net bir geri dönüş (fallback) yoluna ihtiyacı vardır.

İnsan inceleme kapıları. Ajan ilerlemeden önce bir insanın onay vermesi gereken anları belirleyin. Bu, otomasyondaki bir zayıflık göstergesi değildir. Yüksek etkili değişiklikler için bir emniyet supabı ve değerlendirme kriterleriniz (rubrics) için bir doğruluk kaynağıdır.

Gerçek Bir Değerlendirme Planı Nasıl Görünür

Bağımlılıklar haritalandırıldıktan sonra, üretim ortamının karmaşıklığına uygun bir değerlendirme planına ihtiyacınız vardır. Sunum slaytlarındaki metrikler burada size yardımcı olmayacaktır.

Gerçek üretim hatalarından test setleri oluşturun, sentetik soru bankalarından değil. Eğer ajanınız geçen Salı iki benzer SKU'yu karıştırdığı için başarısız olduysa, bu karışıklığın aynısı kalıcı bir test vakası olmalıdır. Değerlendirme paketiniz, her yeni olay size yeni bir şey öğrettiğinde büyümelidir.

Başarılı tamamlanmayı operasyonel terimlerle tanımlayan değerlendirme kriterleri (rubrics) yazın. "Yardımcı" veya "doğru" gibi belirsiz kriterler işe yaramaz. Faydalı bir kriter; bir iade görevinin ancak orijinal ödeme kimliğine (payment ID) atıfta bulunulduğunda, tutar taleple eşleştiğinde, bir onay e-postası sıraya alındığında ve işlem kimliği (transaction ID) günlüğe kaydedildiğinde başarılı olduğunu belirtir.

Araç çağrıları ve yeniden denemeler için izleme (trace) özellikleri tanımlayın. Ajanın ne planladığına, gerçekte neyi çağırdığına, kaç kez yeniden denediğine ve yeniden deneme stratejisinin uygun olup olmadığına dair gözlemlenebilirliğe ihtiyacınız var. Araç düzeyinde ayrıntıya sahip olmayan bir izleme (trace), sadece güzel bir hikâyeden ibarettir.

Bir insana ne zaman uyarı gönderileceğine dair politikalar belirleyin. Ajan kendi sınırlarını bilmelidir. Eğer bir talep bir dolar eşiğini aşıyorsa, bir VIP hesabına atıfta bulunuyorsa veya daha önce hiç görmediği bir durumla karşılaşıyorsa, tahmin yürütmek yerine durumu üst birime iletmelidir (escalate).

Kötü model güncellemelerini engellemek için sürüm kapıları (release gates) kurun. Yeni bir model, yalnızca belirli çıktılarınızı iyileştiriyorsa bir güncellemedir. Eğer araç argümanlarını (tool arguments) daha sık uyduruyor (hallucinate), gecikmeyi (latency) artırıyor veya yeni güvenlik riskleri oluşturuyorsa, yayına alınmaz. Bu kapı, temel model sağlayıcısı yeni bir sürüm yayınladığında bile üretim ortamını (production) kararlı tutar.

Çalışma Zamanı Değerlendirmesi (Runtime Grading): Ajanın Çalışmasını İzlemek

Anthropic, endüstriyi çevrimdışı testlerin ötesine geçip çalışma zamanı değerlendirmesine (runtime grading) yönelmeye teşvik ediyor. Bir konuşma dökümünü olay gerçekleştikten sonra yargılamak yerine, çalışma zamanı değerlendirmesi sistemin ajanın çalışmasını görev henüz devam ederken değerlendirmesine olanak tanır. Bu, hataların gerçek sorunlara dönüşmeden önce yakalanması için bir fırsat yaratır.

Bir değerlendirici (grader) eklemek token ve gecikme maliyeti getirir. Her küçük adımı değerlendirmeye gücünüz yetmeyebilir. Her değerlendiricinin konumu bir tasarım kararıdır. Onları hataların maliyetli olduğu yerlere yerleştirin. En değerli kontrol noktaları; bir durum değişikliğini (state change) veri tabanına kaydetmeden hemen önce, bir ödemeyi gerçekleştirmeden hemen önce ve bir müşteriye mesaj göndermeden hemen öncedir. Bunlar, kötü bir kararın geri döndürülemez bir eyleme dönüştüğü anlardır.

Belirli bir kör noktaya dikkat edin. Eğer aynı model hem işi gerçekleştiriyor hem de işi değerlendiriyorsa, aynı hataları gözden kaçırabilir. Hataya neden olan muhakeme süreci, inceleme sırasında bu hatayı kolayca rasyonalize edebilir. Yüksek etkili görevler için insan incelemesini sürecin içinde (human-in-the-loop) tutun. Özellikle para veya müşteri güveni söz konusu olduğunda, insanların değerlendiricinin kendi yargısını doğrulamasına izin verin.

Buradaki amaç operasyonel kontroldür. Olay (incident) verilerinizi, görev rubriklerinizi ve çalışma zamanı izlerinizi (runtime traces) tek bir geri bildirim döngüsünde birleştirin. Tüm yolu değerlendirin: plan, araç kullanımı, kurtarma davranışı ve nihai sonuç. Yayından önce bilinen, yeniden üretilebilir hataları yakalamak için çevrimdışı testleri kullanın. Öngörmediğiniz yeni hataları bulmak için çalışma zamanı izlerini kullanın. Rubriklerinizin nerede yetersiz kaldığını ve sıkılaştırılması gerektiğini keşfetmek için insan incelemesini kullanın.

Kendinize şunu sorun: İş akışınızda bir çalışma zamanı değerlendiricisini nereye koyardınız? Bir araç çağrısından (tool call) önce mi, sonra mı, yoksa sadece riskli bir değişiklikten önce mi? Çoğu ekip çok geniş bir kapsamla başlayıp her şeyi değerlendirmeye çalışır ve ardından maliyet altında ezilerek durma noktasına gelir. Dar bir kapsamla başlayın. Yanlış giderse en çok zarar verecek olan tek bir eylemi seçin. İlk olarak değerlendiriciyi oraya yerleştirin.

Tek Bir Maliyetli Hata İle Başlayın

Operasyonel değerlendirme bir araştırma egzersizi değildir. Ajan canlıya alındıktan sonra daha rahat uyumanın bir yoludur. İlk günden mükemmel bir çerçeveye ihtiyacınız yok. Tek bir, iyi tanımlanmış iş akışına, sade iş terimleriyle yazılmış bir rubriğe ve bir hatanın maliyetli hale geldiği tam o ana yerleştirilmiş bir değerlendiriciye ihtiyacınız var. Bunu doğru yaparsanız, gerçekten güvenebileceğiniz bir temel oluşturmuş olursunuz.

Ajan değerlendirmesi ve çalışma zamanı değerlendirmesi konularında uzmanlardan oluşan bir toplulukla daha derinlemesine bilgi edinmek isterseniz, GyaanSetu öğrenme topluluğunu https://t.me/GyaanSetuAi adresinde bulabilirsiniz.