Kurumsal bir chatbot yanlış cevap verdiğinde bunun maliyeti, cevabın yanlış olmasından değil, doğru görünmesinden gelir. Kullanıcı bir prosedürü uygular, bir müşteriye yanlış bilgi iletir ya da bir hakkı olmadığını düşünerek başvurudan vazgeçer. Hepsi de cevap "emin" göründüğü için olur.
Bu yüzden kurumsal asistan projelerinde başarıyı belirleyen üç şey var: doğru kaynağı bulabilmek, cevabı o kaynağa bağlamak ve emin olunamadığında cevap üretmemek.
Getirme katmanı tavanı belirler
Bilgi tabanına bağlı asistanlar, sorunun cevabını içeren metin parçalarını bulup modele veren bir mimariyle çalışır. Yaklaşımın literatürdeki temel referansı Lewis ve arkadaşlarının 2020 tarihli çalışmasıdır (Retrieval-Augmented Generation, arXiv 2005.11401).
Buradaki basit ama sık gözden kaçan gerçek şu: doğru pasaj getirilen sonuçlar arasında yoksa, model ne kadar iyi olursa olsun doğru cevap üretemez. Ya "bilmiyorum" der ya da elindeki alakasız metinden makul görünen bir şey uydurur.
"Model iyi ama cevaplar kötü" şikayetiyle gelen kurulumların büyük kısmında sorun modelde değil. Ölçtüğümüzde genellikle şunu görüyoruz: doğru pasaj ilk on sonucun içinde bile değil.
Bu yüzden değerlendirmeye modelden değil getirmeden başlamak gerekir. Ölçülecek metrik basit: gerçek sorulardan oluşan bir sette, doğru pasajın ilk k sonuç içinde bulunma oranı. Bu oran düşükken model değiştirmek zaman kaybıdır.
Bölümleme kararı sanıldığından önemli
Dokümanları sabit uzunlukta parçalara bölmek en kolay yöntem ve en çok soruna yol açan yöntem. Sabit bölme; prosedür adımlarını ortadan keser, tablonun başlığını verisinden ayırır, bir maddenin istisnasını maddenin kendisinden koparır.
Pratikte işe yarayan yaklaşım, dokümanın kendi yapısına saygı göstermek. Başlık hiyerarşisini koruyup her parçaya üst başlıkları da eklemek, arama isabetini gözle görülür biçimde artırıyor. "3.2 İstisnalar" başlıklı bir parça tek başına anlamsızken, "İzin Yönetmeliği > Yıllık İzin > İstisnalar" bağlamıyla birlikte hem daha iyi bulunuyor hem de daha doğru yorumlanıyor.
Bilgi tabanı çelişiyorsa model tutarlı olamaz
Bu, teknik ekiplerin en geç fark ettiği sorun. Aynı sorunun cevabı iki farklı dokümanda farklı yazıyorsa, asistan bazen birini bazen diğerini kullanır. Dışarıdan bakıldığında bu "model tutarsız" gibi görünür; gerçekte kurumsal içerik tutarsızdır.
Bir asistan kurmak, çoğu kurumda ilk kez tüm dokümanların aynı anda okunması anlamına gelir. Ortaya çıkan çelişkiler projenin hatası değil, projenin ilk faydasıdır.
Bunu yönetmenin yolu modelde değil içerik tarafında. Her doküman için bir sahip, bir geçerlilik tarihi ve bir sürüm bilgisi tanımlanmalı; süresi geçmiş içerik indeksten çıkarılmalı. Bu disiplin kurulmadan yapılan model iyileştirmeleri kalıcı sonuç vermiyor.
Cevap vermemek de bir yetenektir
Kurumsal asistanın "bilmiyorum" diyebilmesi, çoğu zaman doğru cevap vermesinden daha değerlidir. Çünkü kullanıcı, sistemin sınırını bir kez öğrendiğinde ona güvenmeye başlar.
Bunu kurmak için iki mekanizma gerekir. Birincisi, getirme skorları belirli bir eşiğin altındaysa cevap üretmemek. İkincisi, üretilen cevabın getirilen pasajlarla desteklenip desteklenmediğini kontrol etmek ve desteklenmiyorsa cevabı yayınlamamak.
Burada bir takas var ve dürüst olmak gerekiyor: eşiği yükselttikçe yanlış cevap azalır, cevaplanamayan soru artar. Bu takas her kurum için aynı yerde optimal değildir. Bir bankanın iç mevzuat asistanında yanlış cevabın maliyeti çok yüksektir, kapsama oranı feda edilebilir. Bir e-ticaret sitesinin kargo sorularında ise tersi geçerli olabilir.
Bu yüzden eşik bir teknik parametre değil, iş kararıdır ve kim tarafından belirlendiği yazılı olmalıdır.
Kaynak göstermek çift yönlü çalışır
Cevabın altında hangi dokümanın hangi bölümüne dayanıldığının gösterilmesi iki fayda sağlar.
Kullanıcı tarafında doğrulama imkanı verir. Kritik bir bilgide kullanıcı kaynağa tıklayıp kendisi bakabilir. Bu, güveni "sisteme inanmak" olmaktan çıkarıp "kontrol edebilmek" haline getirir.
Operasyon tarafında ise düzeltmeyi mümkün kılar. Yanlış bir cevap raporlandığında kaynağı görüyorsanız problemi bulmak dakikalar sürer: ya doküman yanlıştır, ya güncel değildir, ya da yanlış doküman getirilmiştir. Kaynak gösterilmeyen sistemlerde aynı inceleme günlere yayılır ve genellikle "prompt'u değiştirelim" ile sonuçlanır.
Kaynak gösterirken dikkat edilecek nokta, yetki kontrolünün burada da geçerli olması. Kullanıcının erişemeyeceği bir dokümanın adı bile bilgi taşıyabilir. Bu konuyu kapalı ağ mimarisi yazımızda ayrıntılı ele aldık.
Helpdesk tarafında "bot çözdü" oranı yanıltıcıdır
Destek otomasyonunda en çok raporlanan metrik, botun çözdüğü talep oranı. Bu metriğin ölçtüğü şey çoğunlukla sanıldığından farklı.
Bir kullanıcı cevabı alıp konuşmayı kapatırsa "çözüldü" sayılır. Ancak kullanıcı cevabı beğenmeyip pes ettiyse, ya da soruyu sorup cevabı anlamayıp vazgeçtiyse de aynı şekilde "çözüldü" sayılır. İki durum raporda ayırt edilmez.
Daha güvenilir metrik, tekrar temas oranıdır: aynı kullanıcının 24 ila 48 saat içinde aynı konuda tekrar başvurma oranı. Bot çözüm oranı yükselirken tekrar temas oranı da yükseliyorsa, sistem talepleri çözmüyor, erteliyordur.
Bunun yanında izlenmesi gereken birkaç metrik daha var:
- Devretme sonrası temsilcinin ek bilgi isteme oranı (devir kalitesini gösterir)
- Cevabın kaynağa dayanma oranı
- Eşik nedeniyle cevaplanmayan soruların konularına göre dağılımı
- Kullanıcının aynı soruyu farklı ifadelerle tekrar sorma sayısı
Üçüncü madde içerik ekibi için doğrudan bir iş listesi üretir. Cevaplanamayan sorular, bilgi tabanındaki boşlukların en net haritasıdır.
Devretme, konuşmanın kopması değil devamıdır
Asistan çözemediğinde temsilciye aktarılan şey yalnızca sohbet geçmişi olmamalı. Temsilcinin ihtiyaç duyduğu paket şudur: kullanıcının kim olduğu, ne sormak istediği, asistanın hangi kaynaklara baktığı, hangi adımların denendiği ve neyin işe yaramadığı.
Bu paket hazırlanmadığında müşteri her şeyi baştan anlatır ve otomasyondan elde edilen kazanç devir anında kaybolur. Ölçmesi de kolay: temsilcinin devirden sonra ilk mesajında ek bilgi isteme oranını izleyin. Bu oran yüksekse devir tasarımı çalışmıyor demektir.
Değerlendirmeyi tek seferlik yapmayın
Kurulum sırasında yapılan kalite testi, üç ay sonraki sistemi temsil etmez. Dokümanlar değişir, sorular değişir, model sürümü güncellenir.
İşleyen kurumlarda şu yapı kurulu: gerçek taleplerden seçilmiş 150-200 soruluk sabit bir set, her sürüm değişikliğinde çalıştırılıyor ve sonuçlar üç eksende raporlanıyor. Cevap doğru mu, cevap kaynağa dayanıyor mu, sistem cevap vermemesi gereken durumda cevap vermiş mi.
Bu setin bir kısmının cevabı bilinçli olarak bilgi tabanında bulunmamalı. Sistemin "bilmiyorum" demesi gereken sorular olmadan, cevaptan kaçınma davranışını ölçemezsiniz.
Kullanıcıya asistan olduğunu söylemek
AB'de faaliyet gösteren kurumlar için bu artık bir yükümlülük. Yapay Zeka Tüzüğü'nün 50. maddesi, insanlarla doğrudan etkileşen sistemlerin kişiye yapay zeka ile muhatap olduğunu bildirmesini zorunlu kılıyor ve madde 2 Ağustos 2026'da uygulanmaya başladı (artificialintelligenceact.eu).
Türkiye'de böyle bir zorunluluk bulunmuyor. Yine de deneyimimiz, bunu gizlemenin bir faydası olmadığı yönünde. Kullanıcılar zaten birkaç mesaj içinde anlıyor ve gizlenmiş olması güveni azaltıyor. Açıkça söylenen kurulumlarda ise beklenti baştan doğru ayarlanıyor.
Devreye alma öncesi kontrol listesi
- Getirme kalitesi gerçek sorular üzerinden ölçüldü mü
- Bölümleme doküman yapısına saygı gösteriyor mu, başlık bağlamı taşınıyor mu
- Her dokümanın sahibi, sürümü ve geçerlilik tarihi var mı
- Cevaptan kaçınma eşiği kim tarafından, hangi gerekçeyle belirlendi
- Cevaplar kaynağa bağlanıyor mu, kaynak gösterimi yetki kontrolünden geçiyor mu
- Devir paketi temsilcinin ihtiyacını karşılıyor mu
- Değerlendirme seti hazır mı ve her sürümde çalıştırılıyor mu
- Tekrar temas oranı raporlanıyor mu
Bilgi tabanına bağlı asistan mimarisini ve destek akışlarını Chatbot Platformu ile Helpdesk Çözümleri sayfalarında inceleyebilirsiniz.
Kaynaklar
- Lewis, P. ve ark. (2020). Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. NeurIPS. arxiv.org
- EU AI Act, Article 50: Transparency Obligations. artificialintelligenceact.eu
- ISO/IEC 42001:2023, AI management system. iso.org