Chatbot Bilgi Tabanı Nasıl Hazırlanır? Kaynak, Test ve Güncelleme Rehberi

İşletmeniz için chatbot hazırlamak istiyorsunuz; fakat hizmet bilgileri web sitesinde, fiyat notları dosyalarda ve istisnalar çalışanların hafızasında duruyor. Böyle bir ortamda yalnızca model seçmek yeterli olmaz. Bu rehber, chatbotun kullanacağı bilgi tabanını nasıl düzenleyeceğinizi ve yanıtları yayın öncesinde nasıl kontrol edeceğinizi açıklar.

Bilgi tabanı hangi sorulara cevap verecek?

Bir servis işletmesinin chatbotunu düşünün. Müşteri çalışma saatini, hizmet verilen bölgeleri, randevu yöntemini ve belirli işlem kapsamını soruyor. Önce bu sorulardan hangilerinin bilgiyle cevaplanacağını, hangilerinin çalışan kararı gerektirdiğini ayırın.

Bilgi tabanı, işletmenizdeki her belgenin bir araya atıldığı klasör değildir. Chatbotun yetkili biçimde kullanabileceği, güncel ve amacı belli kaynaklardan oluşmalıdır. İç notlar ile müşteriye açıklanabilecek bilgiler aynı kapsamda olmayabilir.

İlk çalışma için dar bir alan seçebilirsiniz: örneğin randevu ve hizmet kapsamı. Sipariş değiştirme, ödeme kararı veya müşteriye özel işlem gibi yetenekleri ayrıca ele alın. Bilgi yanıtlayan sistem ile iş yapan sistemin gereksinimleri farklıdır.

Hangi belgeleri toplamalısınız?

Web sayfaları, kullanım belgeleri, onaylı hizmet açıklamaları ve mevcut destek yanıtları başlangıç kaynağı olabilir. Her belge için güncellik ve sorumluluk bilgisi ekleyin. Hangi kaynağın daha yetkili olduğu anlaşılmadan çelişkili metinleri sisteme vermeyin.

Belgelerin sahibi belli değilse güncelleme sorumluluğu boşta kalabilir. Kaynağın değiştirilmesi chatbot yanıtını etkiliyorsa bu ilişki de görünür olmalıdır. Günlük operasyon bilgilerini yılda bir güncellenen belgede bırakmak uygun olmayabilir.

Kaynakları nasıl sadeleştirirsiniz?

Aynı soruyu farklı belgelerde farklı biçimde cevaplayan içerikleri bulun. Hangisinin geçerli olduğunu iş sorumlusuna doğrulatın. Çelişkiyi modelin kendisinin çözmesini beklemek yerine kaynağı düzeltin.

Uzun pazarlama metinleri yerine kapsamı açık bilgi yazın. “Her türlü destek” gibi geniş ifade, müşteri açısından ne sunulduğunu açıklamaz. Hangi hizmetin verildiği, neyin kapsam dışında olduğu ve gerektiğinde kime sorulacağı belirtilsin.

• Tekrarlı metin: Aynı kuralın gereksiz kopyalarını azaltın.
• Eski sürüm: Geçerli olmayan bilgiyi kullanımdan ayırın.
• Belirsiz ifade: Geniş vaatleri somut kapsamla değiştirin.
• İç not: Müşteriye açıklanmaması gereken bilgiyi farklı erişimde tutun.
• İstisna: Genel kuralın uygulanmadığı durumları açıkça yazın.

Metni daha kısa yaparken gerekli koşulları silmeyin. Özellikle hizmet bölgesi, geçerlilik ve ürün sürümü gibi ayrıntılar yanıtın doğruluğunu etkileyebilir. Chatbotun akıcı konuşması, eksik kaynak bilgisini telafi etmez.

Bilgiyi soru ve yanıt biçiminde mi yazmalısınız?

Sık sorulan sorular iyi bir başlangıçtır, fakat bütün bilgiyi tek satırlık yanıta sıkıştırmak gerekmez. Hizmetin tanımı, uygulanma koşulları ve örnekleri aynı konu içinde anlaşılır biçimde bulunmalıdır. Belgenin başlığı hangi ihtiyacı karşıladığını söylesin.

Örneğin “Randevuyu değiştirebilir miyim?” sorusunda sadece “evet” yazmayın. Değişikliğin nasıl istendiği, hangi durumlarda çalışan incelemesi gerektiği ve müşterinin hangi bilgiyi vermesi gerektiği açıklansın. Gerçek işletme kuralınızı bilmeden süre veya istisna uydurmayın.

Benzer soruların farklı ifadelerini test listesine ekleyin. Müşteri “yarın gelemem”, “saatimi değiştir” veya “randevumu ertele” diyebilir. Kaynakların bu ihtiyacı kapsaması, modelin her ifadeyi doğru anlayacağını garanti etmez; gerçek denemeler gerekir.

Yanıtın hangi kaynağa dayandığı görülmeli mi?

Özellikle ayrıntılı hizmet veya ürün sorularında ilgili kaynak bağlantısını göstermek yararlı olabilir. Kullanıcı bilgiyi inceleyebilir, destek ekibi de yanlış yanıtı araştırabilir. Ancak bağlantının gerçekten verilen yanıtı desteklediğini test edin.

Sistem benzer görünen fakat farklı ürüne ait belgeyi bulabilir. Ürün adı, sürüm veya şube gibi kapsam bilgilerini kaynakla birlikte değerlendirin. Bir belgenin bulunması, yanıtın o belgeyle tam uyumlu olduğunu tek başına göstermez.

Chatbot bilmediğinde ne yapmalı?

Kaynak bulunmayan soruda tahmin ederek kesin yanıt verilmesini istemeyin. Sistem sınırını açıklayıp gerekli bilgiyi sorabilir veya çalışan desteğine geçiş önerebilir. Bu davranışı ürünün normal bir parçası olarak tasarlayın.

Müşteriye özel fiyat, istisna talebi veya kaynaklarda çelişki olduğunda çalışan incelemesi gerekebilir. Aktarımda müşterinin sorusu ve ilgili kaynaklar destek ekibine anlaşılır biçimde ulaşsın. Müşteriden aynı bilgiyi tekrar tekrar istemek deneyimi zorlaştırır.

Aktarımın gerçekten bir görev oluşturduğunu doğrulayın. Sadece “ekibimiz dönecek” yazıp hiçbir kayıt açmayan bir akış yanlış beklenti yaratır. Sorumlu ekip ve müşterinin sonraki adımı belli olsun.

Kaynak güvenliği ve erişim nasıl ele alınmalı?

Bir kullanıcının erişemediği bilgiyi chatbot üzerinden öğrenmemesi gerekir. Müşteri, çalışan ve yönetici kaynakları farklıysa bu ayrım veri getirme aşamasında da korunmalıdır. Tek bir ortak klasörle başlamak erişim kapsamını gereksiz büyütebilir.

Belgelerdeki metinler, sisteme yeni yetki veren talimat olarak kabul edilmemelidir. OWASP'ın RAG güvenliği rehberi, getirilen içeriğin güvenilmeyen veri olarak ele alınmasını vurgular; erişim 28 Ekim 2026. Teknik ekipten bu sınırı ve testlerini açıklamasını isteyin.

Bu konu, müşteriyi korkutacak ek uyarılar üretmek için değil, işletmenin bilgi erişimini doğru kurmak için önemlidir. Hangi kaynakların dış hizmetlere gönderildiğini ve destek sırasında kimlerin görebildiğini açıkça belirleyin.

Yayın öncesi hangi sorularla deneme yapılmalı?

Gerçek destek sorularından bir kontrol seti hazırlayın. Kolay soruların yanında eksik bilgi, yanlış ürün adı, eski koşul ve kapsam dışı talep örnekleri bulunsun. Beklenen yanıtın dayandığı doğru kaynağı iş sorumlusu doğrulasın.

1. Bilinen soru: Yanıt doğru ve anlaşılır mı?
2. Eksik soru: Gerekli ayrıntı soruluyor mu?
3. Yanlış varsayım: Müşterinin hatalı bilgisini sorgusuz kabul ediyor mu?
4. Kaynak dışı soru: Sınırını açıklayıp uygun aktarım yapıyor mu?
5. Erişim denemesi: Yetkisiz bilgi veya işlem sunuluyor mu?

Model veya kaynak değiştiğinde aynı soruları yeniden deneyin. Yalnızca yeni eklenen sorunun doğru yanıtlandığını görmek yeterli olmayabilir. Önceden çalışan önemli soruların hâlâ beklenen sonucu verdiğini kontrol edin.

Hazırlık süresi ve bütçeyi nasıl planlarsınız?

Belge toplama, düzeltme, sistem kurulumu ve test işlerini ayrı gösterin. Örnek plan olarak ilk hafta kaynak envanteri, ikinci hafta düzenleme ve sonraki hafta soru denemeleri ayrılabilir. Bu bir süre garantisi değildir; kaynakların dağınıklığı ve kapsam planı etkiler.

Varsayımsal 10-18 kişi-gün iş ve 6.000 TL kişi-gün bedeliyle 60.000-108.000 TL kurulum hesabı oluşur. Bu piyasa fiyatı veya Navdion teklifi değildir. KDV, model kullanımı, depolama ve kapsam dışı bağlantılar dahil değildir.

Genel ürün kapsamını chatbot başlangıç rehberiyle birlikte değerlendirebilirsiniz. Günlük destek akışındaki rolünü ise müşteri hizmetlerinde chatbot yazısındaki kullanım alanlarıyla karşılaştırın; sonuçları kendi denemenizle doğrulayın.

İki kaynak farklı hizmet bölgesi söylüyorsa ne olur?

Web sayfasında bir bölgeye hizmet verildiği, eski destek belgesinde ise verilmediği yazsın. Chatbotun bu çelişkiyi tahmin ederek çözmesini beklemek yerine işletme sorumlusu geçerli kuralı belirlemelidir. Kaynakların hangisinin güncelleneceği ve hangisinin kullanımdan ayrılacağı kayda geçsin.

Ardından aynı ihtiyacı farklı ifadelerle test edin. Müşteri semt adı, ilçe veya yakın bir konum üzerinden sorabilir. Sistem kapsamı anlayamadığında kesin yanıt vermek yerine açıklayıcı soru sormalı veya çalışan desteğine geçebilmelidir.

Kaynak düzeltildikten sonra yalnızca yeni belgeyi yüklemekle yetinmeyin. Eski içeriğin hâlâ kullanılıp kullanılmadığını ve daha önce doğru çalışan soruların etkilenip etkilenmediğini kontrol edin. Bilgi güncellemesi, ürün davranışını değiştiren bir yayın işi olarak ele alınmalıdır.

Bilgi tabanının güncel kalmasını nasıl sağlarsınız?

Her kaynak için sorumlu kişi ve gözden geçirme nedeni belirleyin. Çalışma saatleri değiştiğinde güncelleme gerekirken, uzun süre geçerli teknik açıklamanın kontrol düzeni farklı olabilir. Tek bir takvimi bütün belgelere aynı şekilde uygulamak gereksiz iş oluşturabilir.

Destek ekibinin yanlış veya eksik yanıtı kolayca bildirmesini sağlayın. Bildirimde soru, verilen yanıt ve ilgili kaynak bulunursa inceleme daha anlaşılır olur. Gereksiz müşteri bilgilerini rapora taşımadan sorunu açıklamak hedeflenmelidir.

Yapılan düzeltmenin sonucunu bildiren kişiye dönün. Böylece ekip, gözlemlerinin bilgi tabanını gerçekten geliştirdiğini görebilir. Sürekli güncellenmeyen bir kaynak düzeni, ilk kurulumda iyi görünse bile zamanla işletmenin gerçek koşullarından uzaklaşabilir.

Sonuç: Önce kaynakları düzeltin

Dar bir soru alanı seçin, kaynakları sahipleriyle doğrulayın ve belirsiz yanıtta çalışana geçişi planlayın. Yayın öncesinde gerçek sorularla deneyip güncelleme sorumluluğunu belirleyin. Navdion ile chatbot bilgi tabanı ihtiyacınızı incelemek için ücretsiz proje analizi talep edebilirsiniz.