Chatbot bir etkileşim biçimidir

Chatbot, kullanıcıyla yazılı veya sesli konuşan bir sistemdir. Önceden belirlenmiş cevaplarla çalışabilir ya da yapay zekâ kullanarak yanıt üretebilir. Bazı chatbot’lar bir sisteme bağlanıp işlem de yapabilir. Bu nedenle “chatbot yalnızca konuşur” şeklinde kesin bir ayrım doğru olmaz.

İşletmeniz sık sorulan soruları yanıtlamak, kullanıcıyı doğru belgeye yönlendirmek veya ilk talep bilgilerini toplamak istiyorsa sohbet tabanlı bir yardımcı başlangıç için yeterli olabilir. Başarı ölçüsü; verdiği cevabın doğruluğu, kaynakların güncelliği ve gerektiğinde kullanıcıyı bir çalışana aktarabilmesidir.

İş akışı ile ajan arasındaki farkı anlayın

Anthropic, önceden tanımlanmış adımlarla ilerleyen iş akışları ile modelin süreç ve araç kullanımını dinamik olarak yönlendirdiği ajanlar arasında ayrım yapar. Bu ayrım, ürün adından daha açıklayıcıdır. Anthropic: Building effective agents

Örneğin bir servis talebi her zaman “bilgileri al, kategori belirle, kayıt aç” sırasını izliyorsa kontrollü bir iş akışı kurulabilir. Talebin çözümü için farklı kaynakların incelenmesi ve sonraki adımın duruma göre seçilmesi gerekiyorsa ajan yaklaşımı değerlendirilebilir. Bu, her karmaşık işi mutlaka ajana vermek gerektiği anlamına gelmez.

Seçimi üç soruyla daraltın

Bir sistemin daha fazla yetenek sunması, işletmeniz için otomatik olarak daha uygun olduğu anlamına gelmez. Gereksiz araç kullanımı yanıt süresini, maliyeti ve kontrol ihtiyacını artırabilir.

İşlem yetkisini kademeli verin

Bir yardımcıya sipariş bilgisini okuma yetkisi vermek ile siparişi iptal etme yetkisi vermek aynı şey değildir. Ödeme, fiyat değişikliği veya müşteri kaydı silme gibi işlemler için ayrı sınırlar koyun. İlk denemeyi yalnızca okuma erişimi ve işlem önerisi üretmeyle başlatabilirsiniz.

Uygulamanın kim adına işlem yaptığı, hangi kaydı değiştirdiği ve işlemin nasıl geri alınacağı izlenebilir olmalıdır. Belirsiz bir istekte kullanıcıdan ek bilgi alınması ve kritik adımlarda insan onayı bulunması, tasarımın parçası olmalıdır.

Aynı müşteri talebi üç farklı biçimde çözülebilir

Bir müşterinin “Siparişim ne zaman gelecek?” sorusunu ele alalım. Basit bir bilgi yardımcısı, teslimat politikasını gösterip sipariş takibi için ilgili bağlantıyı sunabilir. Müşteri genel bir açıklama arıyorsa bu yaklaşım yeterli olabilir. Ancak belirli siparişin durumunu söylemek için doğrulanmış kayıt bilgisi gerekir; genel politika ile gerçek sipariş durumu birbirine karıştırılmamalıdır.

Kuralları belirli bir iş akışı ise önce müşteriyi doğrulayabilir, sipariş numarasını alabilir, kargo kaydını sorgulayabilir ve sonucu tanımlı bir biçimde iletebilir. Adımların sırası önceden bellidir. Sipariş bulunamadığında veya müşteri bilgisi uyuşmadığında hangi yoldan ilerleyeceği de tasarımda belirlenebilir. Bu yapı, çoğu standart sorgu için anlaşılır bir kontrol düzeni sunabilir.

Ajan yaklaşımında ise sistem, hedefe ulaşmak için hangi kayıtları hangi sırayla inceleyeceğini belirli sınırlar içinde seçebilir. Örneğin bir destek vakasında ilgili siparişi, önceki görüşmeleri ve taşıma bilgisini bir arada değerlendirmesi istenebilir. Böyle bir esneklik ancak gerçekten ihtiyaç varsa anlamlıdır; daha fazla erişim ve karar alanı, değerlendirme kapsamını da genişletir.

Cevap üretmek ile kayıt değiştirmek arasında sınır kurun

Bir sistemin kullanıcıya “İade talebi oluşturabilirim” demesi, o işlemi yapmaya yetkili olduğunu göstermez. İşlemin hangi hesap adına yürütüleceği, müşterinin hangi kayda erişebileceği ve onayın nerede alınacağı belirlenmelidir. Kullanıcının konuşma içinde verdiği talep, kurum içindeki yetki kurallarının yerine geçmemelidir.

Öneri olarak işlemleri üç gruba ayırabilirsiniz: Bilgi okuma, değişiklik taslağı hazırlama ve değişikliği uygulama. İlk pilotta sistem yalnızca kayıt okuyabilir ve çalışana öneri sunabilir. Daha sonraki aşamada uygun işlemler, açık onay sonrasında uygulanabilir. İşin etkisine göre insan kontrolü devam edebilir; bütün adımların otomatikleşmesi şart değildir.

Bu ayrım özellikle yanlış kaydı değiştirme riskinin bulunduğu süreçlerde yararlıdır. Örneğin iki benzer şirket adı arasında seçim yapılamıyorsa sistem işlem yapmadan ek bilgi istemelidir. Başarılı kullanım, her talebi bitirmek kadar belirsizliği doğru noktada durdurabilmeyi de içerir.

Kullanılacak bilgi kaynağının sorumluluğunu belirleyin

Chatbot da ajan da güncelliğini kaybetmiş belgelerle çalışıyorsa yanlış bilgi sunabilir. Ürün kataloğu, teslimat politikası ve hizmet kapsamı gibi kaynakların kim tarafından güncellendiğini belirleyin. Bir belge değiştiğinde sisteme ne zaman yansıyacağını ve eski sürümün nasıl ele alınacağını sağlayıcıya sorun.

Örnek bir destek yardımcısında cevabın dayandığı belge çalışan tarafından görülebilir olabilir. Böylece kullanıcıya gönderilecek bilgi daha kolay kontrol edilir. Her cevapta uzun bir kaynak listesi göstermek gerekmeyebilir; ancak özellikle iç kullanımda, bilginin nereden geldiğini incelemek değerlendirmeyi kolaylaştırır.

Belgeye cevap eklenmesi ile iş kuralı değiştirilmesini de ayırın. İade süresini anlatan metin güncellenebilir, fakat sistemin iade uygunluğunu belirleyen kuralı ayrıca değişiklik gerektirebilir. İçerik, entegrasyon ve yetki düzeni farklı sorumluluklar olarak yönetilmelidir.

Sağlayıcı görüşmesinde hangi sorular sorulmalı?

“Yapay zekâ ajanımız var” sunumundan sonra somut bir örnek isteyin. Sistemin hangi durumda bir sonraki adımı kendi seçtiğini, hangi durumda önceden belirlenmiş yoldan ilerlediğini sorun. Bağlı sistem çalışmadığında ne yaptığını ve işlem sonucu kesinleşmeden kullanıcıya başarı mesajı verip vermediğini inceleyin.

Ücretlendirmeyi de kendi göreviniz üzerinden açıklatın. Bir konuşma çok sayıda sorgu, araç kullanımı veya insan devri içerebilir. Görünen mesaj sayısı ile arka plandaki işlem hacmi aynı olmayabilir. Tipik, uzun ve başarısız görevlerin maliyetini ayrı senaryolarda görmek daha gerçekçi bir karşılaştırma sağlar.

Son olarak işletmenin sistemden ayrılma veya sağlayıcı değiştirme koşullarını öğrenin. Bilgi kaynakları, konuşma kayıtları, yapılandırmalar ve entegrasyon belgelerinin nasıl teslim edileceğini konuşun. İyi bir demo, bakım ve devamlılık sorularını ortadan kaldırmaz.

Başarıyı konuşma sayısına göre değerlendirmeyin

Çok sayıda mesajlaşma olması, çok sayıda işin çözüldüğü anlamına gelmez. Kullanıcı aynı soruyu tekrar ediyor veya sürekli bir çalışana bağlanmak istiyorsa konuşma sayısı büyürken deneyim kötüleşebilir. Bu nedenle doğru tamamlanan görev, yanlış işlem, tekrar başvuru ve insan desteği ihtiyacını birlikte izleyin.

Bir bilgi yardımcısında cevap doğruluğu ve uygun yönlendirme öncelikli olabilir. İşlem yapan bir sistemde ise doğru kayda müdahale, işlem izinin bulunması ve hatadan toparlanma da ölçülmelidir. Kullanım amacı değiştikçe değerlendirme ölçütlerinin değişmesi normaldir.

Küçük bir test grubu için başarı ve hata örneklerini düzenli gözden geçirin. Kullanıcı açısından rahat görünen bir konuşmanın arkasında çalışanların fazladan düzeltme yapıp yapmadığını araştırın. Böylece çözümün sunduğu faydayı yalnızca arayüz üzerinden değil, bütün iş akışı içinde görebilirsiniz.

Demoyu kendi örneklerinizle sınayın

Sağlayıcıya yalnızca kolay sorular sormayın. Eksik sipariş numarası, çelişen belgeler, yetkisiz işlem isteği ve çalışmayan entegrasyon gibi durumları da deneyin. Sistemin bilmediğini söyleyebilmesi, yanlış bir kesinlikle işlem yapmasından daha değerlidir.

Kararınızı cevap başına maliyet, doğru tamamlanan görev, insan müdahalesi ve hata sonrası toparlanma üzerinden verin. İhtiyacınız basit bir yanıt sistemi ise oradan başlamak; iş gerçekten gerektirdiğinde daha kapsamlı otomasyona geçmek, yatırımı daha ölçülebilir hale getirir.