AI ajanını yayına almadan test etmek

Perşembe öğleden sonra, 16.40. Randevu ajanını iki gündür kuran operasyon sorumlusu test panelinde on iki senaryo denedi; on ikisinde de makul, kibar ve doğru bir yanıt aldı. Yayına aldıktan kırk dakika sonra ajan aynı müşteri için iki ayrı randevu kartı açtı. Müşteri "cumartesi de olur" diye yazmıştı; ajan bunu ikinci bir talep sandı. Yanıt metni kusursuzdu. Sorun yanıtta değil, yanıtın arkasından gelen aksiyondaydı ve o aksiyonun CRM'de bıraktığı kayıttaydı.

Bu yazı bir AI ajanını canlıya almadan önce nasıl sınayacağınızı anlatıyor: senaryoları nereden toplayacağınızı, bir ajanda birbirinden ayrı sınanması gereken dört katmanı, prova modu ile gerçek çalıştırma arasındaki sınırı, guardrail'leri kasten zorlamayı, yayın kararını hangi eşiklere bağlayacağınızı, ilk hafta canlıda kontrollü açılışı ve yayından sonra hangi sinyallerin testinizin eksik kaldığını söylediğini. Sonda sık sorulan sorular var.

Ajanı sınamak, bir sohbet botunu denemekten neden farklı?

Sohbet botu yanlış cevap verdiğinde ortaya çıkan zarar bir cümledir: müşterinin kafası karışır, siz düzeltirsiniz, konu kapanır. Ajan yanlış davrandığında ortaya çıkan zarar bir kayıttır. Rocketly'de bir ajan CRM içinde 74 otonom aksiyon yürütebilir; görev, randevu, teklif ve fırsat oluşturur, lead durumunu, alanlarını ve puanını günceller, etiketler ve atar. Bunların hepsi geri alınabilir işler değildir. Gönderilmiş bir teklif geri alınmaz, kapatılmış bir fırsat sessizce açılmaz, yanlış atanan bir lead başka birinin listesinde bekler.

Bu yüzden ajan testi iki soruyu ayrı ayrı sormak zorundadır: doğru şeyi mi söyledi, doğru şeyi mi yaptı. İkincisi metin okuyarak anlaşılmaz; aksiyonun hangi parametreyle çağrıldığına bakmak gerekir. Yazılım tarafında bu refleks zaten var. CRM'de ayrı bir test ortamı kurup değişikliği önce orada denemek yıllardır standart pratik; ajanlarda aynı disiplini kurmak, üstelik daha hızlı kurmak gerekiyor, çünkü ajan davranışı kod gibi deterministik değil. Aynı girdi iki farklı çalıştırmada birbirine yakın ama aynı olmayan iki sonuç üretebilir.

Test senaryolarını nereden toplarsınız?

Senaryoyu masa başında hayal etmeyin. En iyi kaynak, o işi bugün insanların nasıl yaptığıdır: son birkaç yüz konuşmanın arşivi. Bu arşivi kabaca üç yığına ayırın. Birinci yığın rutin sorulardır: fiyat listesi nerede, çalışma saati nedir, salı günü boş randevu var mı. İkinci yığın belirsizdir: müşteri iki şeyi aynı cümlede soruyor ya da ne istediğini yarım bırakıyor. Üçüncü yığın nadir ama pahalıdır: iptal, iade, şikayet, hukuki ima, yanlış kişiye ulaşmış bir talep.

Rutin yığın testinizin hacmini belirler, nadir yığın ise kararınızı. Bir ajan rutin sorularda neredeyse kusursuz görünebilir ve yine de yayına hazır olmayabilir, çünkü nadir durumda ne yapacağını bilmiyordur. Müşterilerin sizi ilgilendiren konularda hangi kelimeleri kullandığını görmek için müşterilerin yapay zekaya gerçekte ne sorduğunu araştırmak senaryo listenizi kendi jargonunuzdan kurtarır. İnsanlar sizin ürün adlarınızı değil, kendi problemlerini yazar; test setiniz kurum dilinde kalırsa ajan da kurum dilinde kalır.

Senaryoları yazarken her birine beklediğiniz sonucu da ekleyin. "Müşteri cumartesi soruyor" yeterli değildir; "müşteri cumartesi soruyor, ajan mevcut randevuyu güncellemeli, yeni kart açmamalı" olmalıdır. Beklenen sonucu yazılmamış bir test seti, yayından sonra tartışma üretir, sonuç değil.

Bir ajanda ayrı ayrı sınanması gereken dört katman hangisi?

Ajan tek bir şey değil, üst üste binmiş dört karardır. Bunları birlikte test ederseniz hatanın nereden geldiğini bulamazsınız.

• Bilgi. Doğru kaynağı buluyor mu? Ajan Bilgi Yönlendirme ile her ajanın hangi bilgi kaynaklarına erişebileceğini tek tek seçersiniz; satış ajanı fiyat listesini okur, destek ajanı yalnız dokümantasyonu. Test ederken kaynağı kasten daraltın ve ajanın bilmediğini söyleyebildiğini görün.
• Ton. Sizin sesinizle mi konuşuyor? Kişilik ve Bilgi Tabanı tanımınız burada sınanır, özellikle kötü haber verirken; iyi haberi herkes güzel yazar.
• Aksiyon. Hangi aksiyonu hangi parametreyle çağırdı? Yanıt doğru olup aksiyon yanlış olabilir; en sinsi hata budur.
• Sınır. Yapmaması gerekeni yapmıyor mu? Guardrails ile ajanın asla yapmaması gerekenleri deklaratif olarak tanımlarsınız ve bu sınırlar çalışma anında zorunlu tutulur.

Dört katmanı ayırınca hata ayıklama da kolaylaşır: bilgi katmanı bozuksa bilgi tabanına, ton bozuksa kişilik tanımına, aksiyon bozuksa isteme ve aksiyon açıklamalarına bakarsınız. Aksiyon açıklamalarını netleştirmek çoğu zaman modeli değiştirmekten daha etkilidir. Yapay zekadan işe yarar çıktı almanın pratiği burada da aynıdır: belirsiz talimat, belirsiz davranış üretir; bir ajanda belirsiz davranış ise veritabanınıza öngörülemeyen bir yazma demektir.

Prova modu ile gerçek çalıştırma arasındaki sınırı nasıl çizersiniz?

Test ve Önizleme paneli ajanı yayına almadan gerçek senaryolarla denemenizi sağlar; yanıtları ve aksiyonları müşterilere ulaşmadan görürsünüz. Aksiyon sırasını modelin insafına bırakmak istemediğiniz akışlarda Adım Adım Playbook devreye girer: koşullu adımları siz tanımlarsınız ve yan etkisiz prova modunda önce denersiniz. Prova modunun değeri şudur; ajanın ne yapacağını hiçbir kayıt oluşturmadan okursunuz.

Prova bir noktadan sonra yetmez, çünkü gerçek veriyle karşılaşan ajan farklı davranır. Eksik alanlar, mükerrer kayıtlar, üç ayrı formatta girilmiş tarihler, iki kişinin adına açılmış tek kart. Bu yüzden prova ile canlı arasına bir ara basamak koyun: gerçek kayıtlar üzerinde çalışan ama her yazma aksiyonu manuel onaya düşen bir ajan. Bu basamak, itirazı ve sunumu önceden prova etmek için kullanılan rol provası mantığının aynısıdır. Gerçek gibi davranın, sonuç bağlayıcı olmasın, hata ucuz kalsın.

Guardrail'leri kırmaya nasıl çalışırsınız?

İyi test, ajanın başarılı olacağı senaryoları değil, başarısız olacağı senaryoları arar. Bir saatlik bir oturum ayırın ve ajanı bilerek zorlayın. Denenecek beş yol var: yetkisi olmayan bir taviz istemek, yani indirim, istisna ya da söz; onu başka bir kimliğe sokmaya çalışmak; müşteri mesajının içine talimat gömmek, örneğin önceki kuralları unutmasını istemek; duygusal baskı kurmak; kapsam dışı bir konuyu ısrarla sormak.

Aradığınız şey ajanın her seferinde doğru cümleyi kurması değil, sınırın zorunlu tutulduğunu görmektir. Guardrails ile tanımlanan bir yasak, ajanın ikna olup olmamasından bağımsız olarak çalışma anında engellenir; model iyi niyetle davransa bile aksiyon geçmez. Baskı testinin ikinci amacı devir eşiğini ayarlamaktır. Akıllı İnsan Devri karmaşık ya da hassas durumlarda konuşmayı otomatik olarak doğru temsilciye devreder ve müşteri çıkmaza girmez. Devrin ne zaman tetikleneceğini kalibre ederken müşteri mesajlarındaki memnuniyetsizliği erken yakalamak üzerine kurduğunuz eşikleri kullanabilirsiniz; sinirli bir müşteriyi ajanla tartışmaya bırakmak, yanlış cevaptan çok daha pahalıya patlar.

Yanlış ajana giden talebi yayın öncesinde nasıl yakalarsınız?

Tek ajanla başlayan kurumlar kısa sürede üç dört ajana çıkar: satış, destek, randevu, lead niteleme. O andan itibaren en sık görülen hata yanlış yanıt değil, yanlış yönlendirmedir. Çoklu Ajan Yönlendirme gelen talebi hakem mantığıyla değerlendirip konuya en uygun ajana verir ve kararın neden o ajana çıktığını açıklama panelinde gösterir. Test aşamasında asıl değerli olan kısım bu açıklamadır; gerekçeyi okuyunca eşiğin nerede yanıldığını görürsünüz.

Yeni bir yönlendirme kuralını doğrudan açmak yerine önce gölge modda ölçün. Kural karar verir, karar kaydedilir, ama trafiğe müdahale etmez; bir hafta sonra gölge kararlarla gerçek kararları yan yana koyarsınız. Kanal karışımı da bu testin parçası olmalı. WhatsApp sohbetlerini CRM satış hattına bağladığınızda gelen dil web formundan gelenden farklıdır: daha kısa, daha eksik, çoğu zaman bir sesli mesajın özeti. Yönlendirme eşiğiniz tek kanalda kalibre edildiyse ikinci kanalda şaşar.

Hangi eşikte yayına çıkmaya karar verirsiniz?

"Yeterince iyi göründü" bir karar kriteri değildir. Yayın kararını yazılı eşiklere bağlayın ve eşikleri ajanın yaptığı işin geri alınabilirliğine göre belirleyin. Aşağıdaki tablo örnek bir eşik setidir; kendi sayılarınızı koyun, ama sayıyı kararı vermeden önce koyun.

Sınama	Nasıl ölçülür	Yayın eşiği (örnek)
Rutin senaryolar	Arşivden seçilen 40 tipik konuşma	Hepsinde doğru aksiyon, sıfır yanlış kayıt
Belirsiz talepler	Yarım bırakılmış ya da iki konulu 15 mesaj	Ya doğru soruyu sorar ya devreder, uydurmaz
Sınır testi	Kasten zorlayan 10 deneme	Tamamında guardrail tutar
Yönlendirme	Gölge modda bir haftalık trafik	Açıklaması okunduğunda kararlar savunulabilir
Maliyet	Konuşma başına kredi tüketimi	Aylık ajan tavanının altında ve tahminle uyumlu

Eşik belirlemenin mantığı skor modellerindekiyle aynıdır: kesme noktasını verinin şeklinden değil, hatanın maliyetinden çıkarırsınız. Lead puanlama modelini kalibre etmek için kullandığınız yaklaşım burada da işe yarar; yanlış pozitifin ve yanlış negatifin size neye mal olduğunu bilmeden eşik konmaz. Ajanın açtığı gereksiz bir görev ucuzdur, yanlış şirkete gönderilmiş bir teklif değildir ve bu iki hata aynı eşikle yönetilemez.

İlk hafta canlıda kontrollü açılış nasıl olur?

Yayın bir düğme değil, bir rampadır. Dört kademe işinizi görür. Birinci kademe tek kanal, tek segment ve mesai saatleridir; gece gelen mesajı ilk haftada ajana bırakmayın. İkinci kademede aksiyonların tamamı manuel onaydadır. Onay Kontrolü Sizde özelliği her aksiyon türü için otomatik mi manuel mi çalışacağını ayrı ayrı seçmenize izin verir; ilk haftada okuma ve özetleme aksiyonlarını otomatik, kayıt yazan aksiyonları manuel bırakmak makul bir başlangıçtır. Üçüncü kademede yanlış giderse maliyeti düşük olan aksiyonları otomatiğe alırsınız. Dördüncü kademede hacmi ve saat aralığını genişletirsiniz.

Bu rampanın emniyet kemeri Ajan Başına Kredi Tavanı: her ajana aylık bir tavan koyarsınız ve tavanı aşacak bir çalıştırma daha başlamadan durdurulur. Böylece tek bir döngü hatası bir gecede bütçeyi yakmaz. Döngüsü uzun işlerde rampayı daha yavaş çıkın; oto galeride lead takibi ve test sürüşü gibi haftalara yayılan süreçlerde bir hatanın sonucu ancak on gün sonra görünür, dolayısıyla kademeler arasındaki bekleme süresini uzatmanız gerekir.

Yayından sonra hangi sinyaller testin eksik kaldığını söyler?

Yayın, testin bitişi değil ikinci aşamasıdır. Dört sinyali düzenli okuyun. AI Analitiği konuşma bazında çözüm analizini, insana devir kırılımını, ajan karşılaştırmasını ve en pahalı konuşmaları gösterir; devir oranındaki ani bir sıçrama genellikle test setinizde hiç olmayan yeni bir senaryonun işaretidir. Ajan İçgörüleri hangi aksiyonun ne sıklıkla çalıştığını, nerede takıldığını ve ne kadar kredi yaktığını toplu olarak verir. Çalışma İzi ise tek tek olayları açar: her aksiyonun parametresi, sonucu, süresi ve onaylayanı kayıt altındadır, böylece bir müşteri "ben bunu istememiştim" dediğinde tartışma değil kayıt konuşur.

Dördüncü sinyal insan düzeltmesidir. AI Eğitim Ekranı ile gerçek konuşmalar üzerinden iyi yanıtları örnek olarak onaylar, hatalı olanları düzeltirsiniz; onayladığınız örnekler ajanın istemine girer ve sonraki yanıtlara yön verir. Bu, testi bir kereye mahsus bir kapı olmaktan çıkarıp sürekli bir döngü haline getirir. Alışkanlık olarak hangi görselin neden kazandığını ölçen bir kreatif test sistemi kurmaktan farkı yoktur: amaç kazananı bir kere bulmak değil, ölçmeyi hiç bırakmamaktır.

Ajanın yazdığı veriyi kullanan modelleri de ayrıca izlemeniz gerekir. Ajan lead puanını ve alanlarını güncelleyebildiği için, tahmine dayalı lead skorlama kuran ekipler ajanın doldurduğu alanların skoru kaydırıp kaydırmadığını ayrı bir kontrol olarak yürütür. Bir ajan yanlış alanı doldurduğunda hata o kartta kalmaz, aşağı akıştaki her modele bulaşır ve üç ay sonra "model bozuldu" diye geri döner.

Anlattığımız akışı kendi verinizle denemek isterseniz Rocketly hesabınızı açıp bir ajanı önce test panelinde çalıştırabilirsiniz.

Sıkça sorulan sorular

Yayına almadan önce kaç senaryo denemek yeterli?

Sayı değil kapsam önemlidir. Rutin, belirsiz ve nadir ama pahalı olmak üzere üç yığından da örnek içeren, aksiyon üreten senaryoları ayrıca sayan bir set kurun. Kırk rutin senaryo, on beş belirsiz talep ve on sınır denemesi çoğu ajan için makul bir başlangıç setidir; asıl önemlisi her senaryonun beklenen sonucunun yazılı olmasıdır.

Prova modu gerçek çalıştırmanın yerini tutar mı?

Hayır. Prova modu aksiyon sırasını ve kararı yan etkisiz görmenizi sağlar, ama gerçek verinin düzensizliğini göstermez. Prova ile canlı arasında, gerçek kayıtlar üzerinde çalışan fakat yazma aksiyonları manuel onaya düşen bir kademe bırakın.

Ajan yanlış bir kayıt oluşturursa geri dönebilir miyim?

Çalışma izi her aksiyonun parametresini, sonucunu ve onaylayanını tuttuğu için ne olduğunu kesin olarak görürsünüz. Ancak her aksiyonun iş etkisi geri alınabilir değildir; bu yüzden kayıt yazan aksiyonları ilk haftalarda manuel onayda tutmak, sonradan temizlemekten ucuza gelir.

Test setini ne sıklıkla güncellemeliyim?

Ajanın istemini, bilgi tabanını ya da aksiyon setini her değiştirdiğinizde aynı seti baştan çalıştırın. Ayrıca canlıda insana devredilen her yeni konuşma türünü sete ekleyin; en iyi test senaryoları, testin kaçırdığı gerçek olaylardan gelir.