Chatbot Hangi Verileri Kullanmalı? 7 Kritik Kaynak

Bir müşteri chatbotuna yanlış fiyat listesini verirseniz, model ne kadar güçlü olursa olsun hatalı yanıt üretir. Daha kritik senaryoda, yetkisiz bir çalışanın İK kayıtlarına erişebilmesi yalnızca kötü bir kullanıcı deneyimi değil, doğrudan operasyonel ve hukuki risktir. Bu nedenle chatbot hangi verileri kullanmalı sorusu, bir yapay zeka modeli seçme meselesinden önce veri mimarisi ve iş tasarımı meselesidir.

Kurumsal chatbotlar çoğu zaman tüm şirket dokümanları tek bir alana yüklenerek başlatılır. Bu yaklaşım ilk demoda etkileyici sonuç verebilir; ancak üretim ortamında güncel olmayan bilgi, çelişkili prosedürler ve belirsiz erişim sınırları hızla güven kaybına dönüşür.

7 Kritik Veri Kaynağı

İlk soru "Elimizde hangi veriler var?" değil, "Chatbot hangi iş sonucunu üretmeli?" olmalıdır. Her kullanım senaryosu farklı veri kaynakları, farklı güncellik gereksinimleri ve farklı risk seviyeleri taşır. Bu mimaride kullanılabilecek temel veri katmanları şunlardır:

• 1. Onaylanmış bilgi bankası: SSS içerikleri, ürün açıklamaları, hizmet kapsamları, prosedürler ve destek makaleleri.
• 2. Operasyonel sistem verileri: CRM, ERP, sipariş, stok, rezervasyon veya proje yönetim sistemlerinden gelen canlı kayıtlar.
• 3. Teknik dokümantasyon: API belgeleri, kurulum kılavuzları, sürüm notları, hata kodları ve mimari karar kayıtları.
• 4. Politika ve uyum içerikleri: İzinli erişimle sunulması gereken şirket politikaları, sözleşme koşulları ve süreç kuralları.
• 5. Konuşma verileri: Anonimleştirilmiş destek talepleri, çözüm notları ve sık tekrar eden kullanıcı niyetleri.

Bu kaynakların tümü her chatbotta bulunmak zorunda değildir. Örneğin yalnızca web sitesindeki ziyaretçileri nitelendiren bir satış botu için ürün sayfaları ve fiyatlandırma kuralları yeterli olabilir. Buna karşılık müşteri portalında çalışan bir AI agent, kullanıcının siparişleri, sözleşme durumu ve destek geçmişi gibi kimlik doğrulama gerektiren canlı verilere ihtiyaç duyabilir.

6. Statik Bilgi ile Canlı Veriyi Ayırın

Kurumlarda en sık görülen hata, sabit dokümanlar ile anlık değişen sistem kayıtlarını aynı bilgi havuzunda yönetmektir. Bir PDF içindeki fiyat listesi, bir ürün yönetim ekranındaki stok adedi veya CRM'deki müşteri durumu ile aynı güven seviyesinde ele alınamaz. Fiyat, stok, randevu, ödeme durumu ya da teslimat takibi gibi bilgiler mümkün olduğunda doğrudan kaynak sistemden API aracılığıyla sorgulanmalıdır.

Bu ayrım iki fayda sağlar. Birincisi, chatbotun eski dokümana dayanarak yanlış işlem yapma riski düşer. İkincisi, hangi yanıtın hangi sistemden geldiği izlenebilir hale gelir. Kullanıcıya "siparişiniz hazırlanıyor" deniyorsa, bu ifadenin hangi sipariş kaydına ve hangi zaman damgasına dayandığını sistem loglarında görebilmelisiniz.

7. Kişisel Veriler İçin Amaç Sınırı

Bir banka, sigorta, sağlık veya çalışan self-servis uygulaması kullanıcıya özel bilgi vermeden gerçek değer üretemeyebilir. Ancak kişisel veri erişimi, chatbotun mümkün olan her kayda erişmesi anlamına gelmez. Temel ilke amaçla sınırlılık olmalıdır: kullanıcı siparişinin durumunu soruyorsa, sistem yalnızca o sipariş için gerekli kayıtları ve yalnızca doğrulanmış kullanıcının yetkisi dahilinde getirmelidir.

Rol bazlı erişim kontrolü, oturum doğrulaması, veri maskeleme ve KVKK/GDPR uyumu gibi mimari kararları Müşteri Destek Chatbotu Kurulumunda 7 Adım yazımızda detaylandırdık.

En Değerli Veri, En Fazla Veri Değildir

Bir chatbot projesinde bilgi kapsamını genişletmek caziptir. Fakat binlerce dağınık dosya, daha akıllı bir asistan anlamına gelmez. Model; taslaklar, eski sürümler, kişisel notlar ve birbirini çürüten belgeler arasında doğru cevabı seçmek zorunda kalır. Sonuç, ikna edici görünen fakat denetlenemeyen yanıtlardır.

Veri seçiminde üç ölçüt daha değerlidir: doğruluk, güncellik ve sahiplik. Doğruluk, içeriğin iş açısından onaylanmış olmasını ifade eder. Güncellik, özellikle fiyat, düzenleme ve süreç adımlarında belirleyicidir. Sahiplik ise her veri alanından hangi ekibin sorumlu olduğunu netleştirir. Bu nedenle içerikleri yayın öncesinde "resmi kaynak", "yardımcı kaynak", "arşiv" ve "chatbota kapalı" gibi etiketlerle sınıflandırmak gerekir.

Doküman Parçalama: Küçük Ama Kritik Bir Detay

RAG mimarisinde dokümanlar parçalanır ve anlam temelli vektörlere dönüştürülür; kullanıcının sorusuyla en ilgili bölümler modele bağlam olarak verilir. Çok büyük parçalar yanıt için gereksiz bağlam taşır; çok küçük parçalar ise anlamı koparır. Teknik kılavuzlarda başlık hiyerarşisi ve kod örnekleri korunmalı, prosedürlerde adımlar bölünmeden saklanmalıdır. Her parçaya kaynak adı, sürüm, departman, geçerlilik tarihi ve erişim seviyesi gibi metadata eklemek, arama kalitesini ve denetimi güçlendirir.

Ne Zaman Chatbot Veri Kullanmamalı?

Her soru otomatik yanıtlanmamalıdır. Hukuki yorum, yüksek tutarlı finansal onay, hassas sağlık yönlendirmesi, çalışan performans kararı veya müşteriye bağlayıcı özel teklif sunumu gibi alanlarda chatbotun rolü bilgi toplamak ve yetkili kişiye aktarmak olabilir. Aynı şekilde, kaynağı belirsiz internet içeriklerini kurumsal bilgi tabanına doğrudan almak doğru değildir. Chatbotun hızlı yanıt vermesi değerlidir; fakat işletmenin sözünü temsil eden bir sistemde doğrulanabilirlik hızdan önce gelir.

TechConnect yaklaşımında chatbot veri mimarisi, iş süreçleri ve güvenlik katmanları birlikte ele alınır. Kurulum sürecinin adımlarını ve test/ölçüm çerçevesini Müşteri Destek Chatbotu Kurulumunda 7 Adım yazımızda, satış odaklı kullanım senaryolarını ise Sadece Destek Değil: Akıllı Chatbotlar Satışlarınızı Nasıl Artırır yazımızda ele aldık.

Başlangıç için en iyi adım, son altı ayda ekibinize en çok tekrar eden on soruyu seçmektir. Her soru için güvenilir veri kaynağını, veri sahibini ve güncelleme sıklığını yazın. Ortaya çıkan tablo, chatbot projenizin gerçek kapsamını ve ilk somut ROI alanını tahmin ettiğinizden daha net gösterecektir.

Kendi veri mimarinizi birlikte netleştirmek isterseniz, projenizi bize anlatın.