AI-powered gelir sistemi ne zaman gerçekten değer üretir?

Yapay zeka destekli bir gelir sistemi, modelin bir işi yapabilmesinden daha fazlasını gerektirir. O işin neden yapılacağını, hangi bilgiye dayanacağını, hatasının nasıl anlaşılacağını ve çıktının kim tarafından kullanılacağını tanımlamak gerekir. Hornpiper olarak önerdiğimiz başlangıç, bütün satış sürecini tek bir agent’a devretmek değil, sınırları açık bir görevi mevcut işleyiş içinde sınamaktır. Bu yazı bir kurulum ve değerlendirme yaklaşımıdır; müşteri sonucu veya gelir artışı iddiası değildir.

“Satışı yapay zekayla güçlendirelim” bir proje amacı olabilir, fakat test edilebilir görev tanımı değildir. “İzinli kaynaklardan bir hedef hesap hakkında kaynak bağlantılı araştırma notu hazırlamak” daha dar bir başlangıçtır. Bu tanımda girdi, çıktı ve kullanıcı bellidir. Başlangıçta şu soruları birlikte yanıtlarız: Kim bu işi yapıyor? Çıktı hangi kararda kullanılıyor? Hangi bilgi mutlaka bulunmalı? Hangi bilgi yoksa görev tamamlanmış sayılmamalı? Yanlış bir sonuç yalnız yeniden çalışma mı doğuruyor, yoksa müşteriye veya başka bir sisteme yansıyor mu?

Görevin sahibi satış yöneticisi olabilir; teknik sorumlu ise farklı bir kişi olabilir. İkisinin sorumluluğunu aynı başlık altında eritmeyiz. İş sahibi çıktının kullanılabilirliğini ve ticari önceliğini değerlendirir. Teknik sorumlu veri erişimini, çalışma kaydını ve sistem davranışını izler. Kurulumdan önce, anlaşmazlık halinde son kararı kimin vereceğini ve hangi koşulda akışın duracağını kayda geçiririz. Böylece belirsiz bir “insan denetimi” ifadesi yerine uygulanabilir bir sorumluluk düzeni oluşur.

Mevcut işin ne kadar zaman aldığını, hangi hataları ürettiğini ve sonucun nasıl kontrol edildiğini bilmeden iyileşme iddiasını değerlendirmek zordur. Önce aynı görev için bir referans yöntem belirleriz. Bu yöntem mevcut insan iş akışı, basit bir kural veya daha dar bir otomasyon olabilir. Seçim görevden göreve değişir. Karşılaştırmayı yalnız modelin yanıt üretme süresi üzerinden yapmayız; veriyi hazırlama, çıktıyı kontrol etme, düzeltme ve sisteme aktarma adımlarını da çalışma kaydına dahil ederiz.

Bir örnekte iyi görünen çıktı, bütün iş yükünde aynı davranışın gözleneceğini göstermez. Değerlendirme için yalnız kolay kayıtları seçmeyiz. Eksik kaynak, benzer şirket isimleri, çelişkili bilgiler ve güncelliğini yitirmiş kayıtlar gibi durumları ayrı test örnekleri olarak tutarız. Model veya istem üzerinde değişiklik yaptığımızda, bu örnekler üzerindeki farkı da inceleriz. Bu bir evrensel örneklem büyüklüğü önerisi değildir. Test kapsamı işin çeşitliliği, hata etkisi ve eldeki veriyle birlikte belirlenir.

Hesap araştırması örneğinde şirket adı, alan adı, kaynak adresi ve bilginin kontrol edildiği tarih ayrı alanlardır. Modelin akıcı bir paragraf yazması, bu alanların doğru eşleştirildiği anlamına gelmez. Kaynağı olmayan bilgiyi doğrulanmış bulgu gibi göstermeyen bir çıktı sözleşmesi kurarız. Gerekli veri bulunamazsa sistemin eksikliği bildirmesi, bir yanıt uydurarak görevi tamamlamasından farklı bir davranıştır. Eksik kayıtları başarılı işlem sayısının içinde görünmez hale getirmeyiz; neden tamamlanamadığını ayrı izleriz.

Aynı yaklaşım CRM verisi için de geçerlidir. Bir satış aşamasının anlamı ekipler arasında değişiyorsa, o alanı kullanan özetin nasıl yorumlanacağını önce netleştiririz. Eski bir teklif kaydının yeni fırsata bağlanması veya aynı müşterinin iki kimlikle görünmesi gibi sorunlar, yalnız istem metni değiştirilerek çözülmüş kabul edilmez. Gerekli durumda veri modeli, eşleştirme kuralları ve güncelleme sorumluluğu ele alınır. Sisteme daha fazla veri vermek yerine, karar için gerekli ve kullanılmasına izin verilen veriyi belirleriz.

Bir takip e-postası taslağı hazırlamak, e-postayı müşteriye göndermekle aynı yetki değildir. Bir alanın yanlış olabileceğini işaretlemek, CRM kaydını değiştirmekle aynı yetki değildir. Her görev için okunabilecek kaynakları, kullanılabilecek araçları, yazılabilecek alanları ve onay gerektiren işlemleri ayrı tanımlarız. Geri alınması zor veya etkisi yüksek işlemlerde insan onayını bir adım olarak tasarlarız. Onayı veren kişi yalnız bir düğme değil, karar vermesine yetecek kaynak ve bağlam görmelidir.

NIST AI Risk Management Framework, yapay zeka sistemlerinin tasarım, geliştirme, kullanım ve değerlendirmesinde güvenilirlik ve risk yönetimini ele alan gönüllü bir çerçevedir. Buradaki görev ve onay tasarımı, Hornpiper’ın bu genel yaklaşımı ticari iş akışına uyarlayan uygulama önerisidir. NIST’in belirli bir satış sonucu vaat ettiği anlamına gelmez.

Araştırma notu için kalite ölçütü, metnin ikna edici görünmesi olmamalıdır. Kaynakların açılabilmesi, bulgunun kaynağa uygun olması, doğru şirketle eşleşmesi ve bilinmeyenlerin açıkça işaretlenmesi ayrı değerlendirme başlıklarıdır. Bir görev birden fazla koşula bağlıysa tek bir ortalama puan, kritik hatayı örtebilir. Bu nedenle hangi koşulların geçişi durduracağını önceden belirleriz. Örneğin yanlış şirket kaydına bağlanan, fakat dili çok iyi olan notu kabul edilmiş bir çıktı olarak değerlendirmeyiz.

İnsan kontrolü için harcanan zamanı da aynı kayıt içinde tutarız. Çıktı hızlı üretilse bile kontrol eden kişinin kaynakları baştan araştırması gerekiyorsa kazanım farklılaşır. Hataları tek bir “başarısız” etiketiyle birleştirmek yerine, kaynak eksikliği, eşleştirme hatası, yorum hatası ve araç hatası gibi düzeltilebilir gruplara ayırırız. Bunlar örnek sınıflardır, her projeye zorunlu bir taksonomi değildir. Amaç hatanın nerede oluştuğunu ve çözümün modelde mi, veride mi, süreçte mi aranacağını görebilmektir.

İlk değerlendirmede sistemin önerisini gerçek bir dış işlem yaptırmadan incelemek mümkün olabilir. Öneri üretimi ile uygulamayı ayıran bu düzen, özellikle çıktının henüz yeterince tanınmadığı akışlarda faydalı bir çalışma seçeneğidir. Pilotun ne kadar süreceğini ve hangi kayıtları içereceğini işin riskine göre belirleriz. Sürenin dolması tek başına yaygınlaştırma kararı değildir. Önceden yazılmış kalite, hata ve işletim koşullarının karşılanıp karşılanmadığını birlikte değerlendiririz.

Kapsam genişletildiğinde hangi görevlerin eklendiğini, hangi veri kaynaklarının açıldığını ve hangi yetkilerin değiştiğini ayrıca kaydederiz. Test edilmiş bir özetleme görevine yeni bir gönderim aracı eklemek, yalnız teknik bir ayar değişikliği değildir; akışın etkisini de değiştirir. Model veya veri kaynağı değiştiğinde değerlendirmeyi yeniden ele alırız. Geri dönüş yolu, önceki davranışın kaydı ve sorumlu kişi belli değilse genişletme kararını tamamlanmış saymayız. Pilotun işe yaramaması da korunması gereken bir öğrenme kaydıdır.

Bir araştırma görevinin daha kısa sürmesi, tek başına daha fazla satış yapıldığını kanıtlamaz. Kazanılan zamanın nerede kullanıldığı, satış ekibinin kapasitesi ve sonraki süreçlerin işleyişi ayrı sorulardır. Bu nedenle görev düzeyindeki değerlendirme ile ticari sonuç değerlendirmesini ayrı tutarız. İlki kalite, toplam süre, yeniden çalışma ve maliyet gibi alanları inceler. İkincisi ise o değişimin daha geniş iş sonucuna nasıl bağlandığını sorgular. Aynı dönemde kampanya, fiyat veya ekip değiştiyse bunları değerlendirme dışında bırakmayız.

Maliyet hesabına yalnız model kullanımını koymayız. Veri erişimi, kurulum, kontrol, bakım ve hata çözümü için gereken işi de düşünürüz. Burada her şirket için geçerli bir geri dönüş oranı veya eşik önermiyoruz. Karar; görevin sıklığı, alternatif yöntemin maliyeti, hata etkisi ve ekibin sistemi işletme kapasitesiyle birlikte verilmelidir. Daha küçük bir otomasyon aynı ihtiyacı karşılıyorsa daha karmaşık bir agent tasarımını seçmek zorunda değiliz. Teknoloji seçimi, işin gerektirdiği kapsamı izler.

Bu dosya model seçimini gereksiz kılmaz; model seçimine anlamlı bir bağlam verir. Hornpiper’ın yaklaşımında asıl teslimat, çalışan bir demo kadar açık görev tanımı, kontrol düzeni ve işletim sorumluluğudur. Sistem değer üretiyorsa bunu tanımlanmış iş ve gözlenmiş sonuç üzerinden konuşabilmeliyiz. Henüz bilmiyorsak, belirsizliği bir ürün sıfatıyla kapatmak yerine neyi sınayacağımızı açıkça söylemeliyiz.