“Kendi verilerimizle nasıl chatbot geliştiririz?” sorusuna genellikle kısa bir tarif verilir: Belgeleri toplayın, parçalara ayırın ve aranabilir bir dizine kaydedin. Biri soru sorduğunda soruyla en ilgili bölümleri dil modeline verin, yanıtı model yazsın. Retrieval-augmented generation, kısaca RAG denen bu yöntemde model, yanıt üretirken arama sonucunda bulunan kaynaklardan yararlanır. Az sayıda, düzgün hazırlanmış belgeyle birkaç günde çalışan bir demo yapılabilir. Şirket içinde kullanılacak bir sistem kurmak içinse önce hangi bilgilerin hazırlanacağını ve chatbot’un hangi kurallara göre çalışacağını belirlemek gerekiyor.
Demo, özenle seçilmiş birkaç belgeyle çalışır ve geliştiricilerin aklına gelen soruları yanıtlar. Şirketteki bilgiler ise dosyalara, ortak sürücülere, web sitelerine ve iş sistemlerine dağılır. Eski belgeler güncel olanlarla yan yana durur. Bazı bilgiler herkese açık değildir, üstelik kaynaklar birbiriyle çelişebilir. Her gün bu bilgilerle çalışan insanlar, hangisini nerede kullanacaklarına çoğu zaman düşünmeden karar verir. Chatbot içinse bu kararların açık kurallara dönüşmesi gerekir.
Birçok şirket chatbot’unda modeli sisteme bağlamak, kullanacağı bilgileri hazırlamaktan daha kolaydır. Asıl emek, bilgiyi chatbot’un kullanabileceği hale getirmeye gider. Ekibin hangi soruda hangi kaynağı kullanacağını belirlemesi ve güncel bilgilerin bulunduğu sistemlere bağlantı kurması gerekir. Kimin neyi görebileceği, chatbot’un hangi durumlarda görüşmeyi bir çalışana aktaracağı da bu işin parçasıdır. Ardından sistem, insanların gerçekten sorduğu sorularla denenir. Bunları baştan bilmek, hem hazırlıkları planlamayı hem de projenin neden demodan daha uzun sürdüğünü anlamayı kolaylaştırır.
Şirket belgeleri, konuyu zaten bilen insanlar için yazılır
Şirket belgelerinin çoğu, okuyanın birçok şeyi zaten bildiğini varsayar. Deneyimli bir çalışan, 2024 fiyat listesinin ocak ayında değiştiğini ve satış temsilcisinin e-postasıyla şirket politikası çeliştiğinde politikanın esas alınacağını bilir. Ortak klasördeki prosedür taslağının hiç onaylanmadığını, şirket içi fiyat tablosundaki rakamların müşteriye verilmemesi gerektiğini de bilir. Bu ayrıntılar belgelerin içinde yazmıyor olabilir.
Chatbot’a verilen metinlerde sürüm, sorumlu kişi ve erişim bilgileri yoksa sistemin bu metinler arasında sağlıklı bir seçim yapması zorlaşır. Arama sırasında soruyla en ilgili görünen parçalar bulunur. Eski bir fiyat listesindeki bölüm de soruyla güncel listedeki kadar örtüşebilir. Model böylece güncelliğini yitirmiş bir metne dayanarak kesin bir dille yanıt verebilir. Çalışanların bildiği ayrımlar modele aktarılmamıştır. Yanıtta kaynak da yoksa müşteri bilginin nereden geldiğini kontrol edemez. Chatbot geliştirme işinin büyük bir kısmı, çalışanların bildiği bu ayrımları sistemin uygulayabileceği kurallara dönüştürmektir.
Kaynaklar çeliştiğinde hangisinin esas alınacağı belli olmalı
İki kaynak çeliştiğinde insan çoğu zaman farkında bile olmadan birini esas alıp işine devam eder. Chatbot bunu güvenilir biçimde yapamaz. Eski ve yeni fiyat listesi birlikte verildiğinde herhangi birini seçebilir ya da ikisini karıştırıp hiçbirine uymayan bir yanıt oluşturabilir. Şirketin hangi kaynağı esas alacağı önceden belli olmalı, sistem de buna göre çalışmalıdır.
Kurallar çoğunlukla karmaşık değildir, ama birinin bunları açıkça yazması gerekir. Belgenin güncel sürümü eskilerinin yerini alır. Onaylı şirket politikası sunuma, pazarlama ekibinin hazırladığı sık sorulan sorular sayfasına veya ortak wiki’deki bir nota göre önceliklidir. Bir müşteriyle özel anlaşma yapılmışsa yalnızca o müşteri için genel fiyat listesi yerine anlaşmadaki fiyatlar geçerlidir. Şirket sistemindeki kayıtla geçen çeyrekte o sistemden alınmış bir PDF çelişiyorsa sistemdeki kayıt esas alınır. Taslaklar, arşivler ve geçerliliğini yitirmiş dosyalar chatbot’un kaynaklarına alınmaz ya da yanıtlara dayanak olamayacakları açıkça işaretlenir.
Sistemin bu kuralları uygulayabilmesi için belgenin onay durumunu, güncel sürümünü, kimler için ve ne zamana kadar geçerli olduğunu bilmesi gerekir. Belgeler bu bilgileri her zaman sistemin kullanabileceği biçimde içermez. Proje sırasında eksikleri tamamlamak gerekir ki sistem, model yanıtı yazmadan önce doğru kaynakları seçebilsin.
Hangi belge esas alınmalı?
Bir şirket chatbot'una gelen soru: “500 adedin üzerindeki siparişlerde ne kadar indirim alıyoruz?” Bu kurgusal örnek 1 Nisan 2026 tarihinde geçiyor. Anlaşma o tarihte geçerli. Aramada dört belge bulundu. Kuralları açıp kapatarak örnek yanıtları karşılaştırın.
Soruyu soran
Kaynak seçimi kuralları
Bilgi sızıntısı
Chatbot
30 Haziran 2026 tarihine kadar 500 adedin üzerindeki siparişlerde %15 indirim uygulanır.
Kaynak: Kestrel Supply anlaşması
Başka bir müşteriye özel fiyat, ilgisiz bir kişiye gösteriliyor. Üstelik şirket bu fiyatı ziyaretçiye sunmuyor.
Aramada bulunan belgeler
A. 2025 fiyat listesi%8
Onaylı fiyat listesi · Ocak 2025
“500 adedin üzerindeki siparişlerde %8 indirim.”
Bulundu, ancak kullanılmadı
B. 2026 fiyat listesi%10
Onaylı fiyat listesi · Ocak 2026
“500 adedin üzerindeki siparişlerde %10 indirim.”
Bulundu, ancak kullanılmadı
C. Satış ekibinin wiki sayfası%12 civarı
Onaylanmamış şirket içi not · Mart 2024 güncellemesi
“Toplu siparişlerde genellikle %12 civarı indirim uygulanır.”
Bulundu, ancak kullanılmadı
D. Kestrel Supply anlaşması%15
İmzalı müşteri anlaşması · 30 Haziran 2026 tarihine kadar geçerli
“500 adedin üzerindeki siparişlerde %15 indirim.”
Yanıtta kullanıldı
Chatbot'un bu kuralları uygulayabilmesi için birinin onları yazması gerekir. Her belgenin onay durumu, sürümü ve kimlere açık olduğu da kayıtlarda yer almalıdır.
Bazı çelişkiler zamanla ortaya çıkar. Fiyat değiştiğinde, politika güncellendiğinde ya da ürün satıştan kalktığında, sistem devreye alınırken doğru olan bir belge artık yanlış bilgi verir. Bu değişiklik kolayca gözden kaçabilir. Eski bir belgeden üretilen yanlış yanıt, doğru yanıt kadar emin bir dille yazılabilir.
Bunu önlemek için chatbot’un kullandığı her kaynağı güncel tutacak birinin sorumluluk alması gerekir. Yeni fiyat listesi çıktığında veya şirket politikası değiştiğinde ilgili kaynak da güncellenmelidir. Yılda bir kontrol etmek bu değişikliklere yetişmez. Tarihin önemli olduğu yanıtlarda kaynak tarihi gösterilebilir, böylece okuyucu bilginin güncelliğini değerlendirebilir. Diğer kaynaklar ne kadar iyi yönetilirse yönetilsin, ihmal edilmiş bir belgeden üretilen yanıtlar da o belgeyle birlikte eskir.
Birçok sorunun yanıtı belgelerde bulunmaz
“Siparişim nerede?” “Kaç gün iznim kaldı?” “Bu parça İzmir deposunda var mı?” “Sözleşmem ne zaman yenileniyor?” Bu soruları yanıtlamak için ilgili hesaba ait güncel bilgiler gerekir. Genel amaçlı bir belge arşivi çoğunlukla yeterli olmaz. Yanıtlar sipariş yönetimi, insan kaynakları, stok veritabanı veya CRM gibi sistemlerde bulunur. Bu bilgilerin bazıları saat başı değişirken bazıları soruyu soran kişiye göre farklılaşır.
Yalnızca belgelerle çalışan bir chatbot bu sorularda zorlanır. Müşteriye yanıtı nerede arayabileceğini söylemekle yetinebilir. Ya da teslimat sürelerini genel olarak anlatan bir belgeyi bulup sorunun yanıtıymış gibi sunabilir.
Doğru yanıt verebilmek için chatbot’un bilgiyi tutan sistemlere bağlanması gerekir. Müşteri siparişini sorduğunda sistem müşterinin kimliğini doğrular, sipariş sisteminin arayüzünden o müşterinin siparişlerini sorgular ve güncel kayda dayanarak yanıt verir. Bu, belgeleri dizine eklemekten farklı bir iştir. Her sistem için ayrı bir bağlantı kurmak ve chatbot’un okuyabileceği bilgileri belirlemek gerekir. Bağlantı yavaşladığında, sistem yanıt vermediğinde ya da beklenmedik bir sonuç döndürdüğünde ne yapılacağı da düşünülmelidir. Bu tür projelerde emeğin büyük bölümü modelden çok bağlantılara gider. Yapay zeka projelerinde asıl iş entegrasyon yazısında da bu durumu ele alıyoruz.
Projeye başlamadan önce gerçekte sorulan sorular bir listede toplanabilir. Her sorunun yanına yanıtın nerede bulunduğu yazılır. Bazı yanıtlar belgededir, bazıları bir sistemde, bazılarıysa yalnızca birinin aklındadır. Her grupta kaç soru olduğu, ne geliştirileceğine karar vermeyi kolaylaştırır. Belgelerle çalışan bir chatbot ilk gruptaki soruları yanıtlayabilir. İkinci grup hangi sistemlere bağlantı gerektiğini, üçüncü grup ise hangi bilgilerin yazıya dökülmesi veya hangi soruların bir çalışana aktarılması gerektiğini gösterir.
Chatbot soruyu kimin sorduğunu bilmeli
Aynı sorunun farklı kişiler için farklı doğru yanıtları olabilir. Fiyat soran müşteriyle bayi farklı rakamlar görmelidir. Türkiye’deki ve Almanya’daki çalışanların izin hakları farklı kurallara tabidir. Bir yönetici ekibinin maaş aralıklarını görebilirken ekipteki bir çalışanın diğer çalışanlara ait bu bilgilere erişmemesi gerekir.
İyi yönetilen bir şirkette bu erişim sınırları zaten kullanılan sistemlerin içinde tanımlıdır. Ortak klasörlerin erişim izinleri vardır, insan kaynakları sistemi her çalışana yalnızca kendi kaydını gösterir, müşteri hesapları ayrı tutulur. Belgeler chatbot’un arama dizinine kopyalanırken bağlantının bu izinleri koruduğu ve uyguladığı doğrulanmalıdır. Erişim izinleri uygulanmıyorsa dizindeki bütün bilgiler yanıtlara girebilir. Doğru soruyu sormak, kişinin görmemesi gereken bir bilgiye ulaşmasına yetebilir. OWASP güvenlik projesi bunu kaynak aramaya dayalı uygulamaların başlıca risklerinden biri olarak tanımlıyor: Saklanan içerikteki zayıf erişim kontrolleri, modelin kişisel verileri, şirkete özel bilgileri veya başka bir kullanıcı grubuna ait içeriği bulup paylaşmasına yol açabilir. OWASP
Bu nedenle model herhangi bir bilgi görmeden önce soruyu soran kişinin kimliği belirlenmeli, arama yalnızca o kişinin görmeye yetkili olduğu belge ve kayıtlarla sınırlandırılmalıdır. Modele bir bilgiyi gizli tutmasını söyleyen prompt, güvenilir bir erişim kontrolü değildir. Erişim yetkileri, kısıtlı bilgiler modele ulaşmadan önce hem belge aramalarında hem de bağlı sistemlerden bilgi alınırken kontrol edilmelidir.
Bunun için chatbot’un kullandığı her belge ve kaydın kimlere açık olduğu sisteme aktarılmalıdır. İnsanlar işe girdiğinde, ayrıldığında veya görev değiştirdiğinde bu bilgi de şirketin mevcut izinleriyle birlikte güncellenmelidir. Herkese açık sayfalardan yanıt veren bir web sitesi chatbot’unda şirket içi içeriği dışarıda tutmak yeterli olduğundan iş daha sınırlıdır. Birden çok departmana hizmet veren bir iç asistan veya müşterilerin kendi hesaplarını sorgulayan bir chatbot içinse erişim kontrolü projedeki iş yükünün büyük bir bölümünü oluşturur.
İyi bir chatbot ne zaman duracağını bilir
İyi tasarlanmış bir chatbot bazı soruları yanıtlamaz. Şirketin belirlediği kurallar gereği bir çalışanın ele alması gereken durumlar vardır: Hukuki uyuşmazlığa dönüşebilecek bir şikayet, iade politikasının dışına çıkan bir talep, sağlık veya güvenlikle ilgili bir soru, açıkça öfkeli ya da üzgün birinden gelen mesaj. Bazı sorular içinse elde yeterli bilgi yoktur. Böyle bir soruya emin bir dille tahminde bulunarak yanıt vermek, yanıt vermemekten daha kötüdür. Hangi soruların bu gruplara girdiğini belirlemek, chatbot tasarımının bir parçasıdır.
Kaynaklarda yeterli bilgi varsa chatbot soruyu yanıtlayabilir, ayrıntılar eksikse açıklama isteyebilir, güvenilir bir yanıt veremiyorsa görüşmeyi bir çalışana aktarabilir. Bilgi veren yanıtlarda dayanak alınan kaynak, gerektiğinde de kaynağın tarihi gösterilmelidir. “Bu konuda emin değilim. Sizi faturalama ekibimize yönlendireyim” demek, hem müşteri hem şirket için kendinden emin ama yanlış bir yanıttan daha iyidir.
Şirket bazı kararları baştan verebilir. Chatbot’un hangi konuları hiç yanıtlamayacağı, ne zaman görüşmeyi mutlaka bir çalışana aktaracağı ve neleri taahhüt edebileceği önceden yazılabilir. Bazı kararlar ise ancak soruyla ilgili kaynaklar bulunduktan sonra verilir. Sistem bu kaynakların yeterli olup olmadığını, birbirleriyle çelişip çelişmediğini ve kullanıcının bunları görmeye yetkili olup olmadığını kontrol eder. Projede hem bu kontrollerin hem de önceden yazılan kuralların nasıl işleyeceğini tasarlayıp test etmek gerekir.
Görüşmenin aktarılması da ayrıca tasarlanmalıdır. Sorununu chatbot’a anlatmış bir müşteri aynı şeyi yeniden anlatmak zorunda kalmamalıdır. Görüşmeyi devralan kişiye konuşmanın geçmişi, chatbot’un bulduğu kaynaklar ve neden yanıt veremediği iletilmelidir. Mesai saatlerinde görüşmeyi devralacak biri bulunmalıdır. Hemen yanıt verilemiyorsa müşteriye ne zaman dönüş yapılacağı açıkça söylenmelidir. Aksi halde müşteri chatbot’tan kimsenin okumadığı bir gelen kutusuna gönderilmiş olur.
Gerçek sorularla test edin, kullanıma açtıktan sonra da sürdürün
Geliştiricilerin düşündüğü sorularda iyi çalışan bir chatbot, insanların gerçekten sorduğu sorularda başarısız olabilir. İnsanlar aynı soruyu farklı biçimlerde sorar. Bazen iki konuyu birleştirir, şirket içi kısaltmalar veya ürünlere taktıkları adları kullanırlar. Yazım hataları yapar, hiçbir belgede ele alınmamış durumları sorarlar. Chatbot’un hazır olup olmadığını anlamak için onu kullanacak kişilerden gelen sorularla denemek gerekir. Bunlara kısıtlı bilgileri elde etmeye veya chatbot’a kurallarını ihlal ettirmeye yönelik kasıtlı denemeler de eklenmelidir. Sıradan sorular bu hataları hiç ortaya çıkarmayabilir.
İlk iş soruları toplamaktır. Destek e-postaları, destek kayıtları, sohbet geçmişleri ve satış ile insan kaynakları ekiplerinin her hafta yanıtladığı sorular iyi kaynaklardır. Dar kapsamlı bir pilot için yüz ila iki yüz soruyla başlanabilir. Ancak bu sayıya ulaşmak, sistemin kullanıma hazır olduğu anlamına gelmez. Zor sorular da dahil edilmelidir: Güncel bir sistem kaydı gerektiren, yanıtlanmaması gereken, iki belgenin çeliştiği veya yanıtını yalnızca belirli kişilerin görmeye yetkili olduğu sorular. İşi bilen biri, her sorunun doğru yanıtını, kaynağını ve kimlere verilebileceğini yazmalıdır.
Sık gelen ve önemli sorular, chatbot’un neleri yanıtlaması gerektiğini gösterir. Bu soruların hiçbirine katkısı olmayan bilgilere sistemde yer vermek gerekmeyebilir. Aynı liste, sonraki değişikliklerin çalışan bir özelliği bozup bozmadığını kontrol etmek için de kullanılır. Devreye alma öncesi değerlendirme için günlük iyileştirme çalışmalarında kullanılmayan ayrı bir soru kümesi de tutulmalıdır. Böylece sistem, geliştiricilerin iyileştirmeler sırasında kullanmadığı sorularla da sınanır. Devreye almadan önce her sürüm bu sorularla kontrol edilir: Yanıt doğru mu, doğru kaynağa mı dayanıyor, kısıtlı bilgiler gizli kaldı mı, chatbot gerektiğinde durdu mu? Ortalama puan her şeyi göstermez. Soruların %95’ini iyi yanıtlayan bir chatbot yine de bir müşterinin fiyatını başka bir müşteriye açıklayabilir. Yalnızca ortalamaya bakıldığında bu hata gözden kaçar. Kağıt üzerinde kusursuz, pratikte sorunlu yazısı, değerlendirmenin neden şirketin kendi koşullarına göre yapılması gerektiğini daha geniş biçimde ele alıyor.
Kaynak göstermek bu işi kolaylaştırır. Her yanıt dayandığı belgeleri veya kayıtları listeliyorsa inceleyen kişi hatanın nereden geldiğini araştırabilir: İçerik mi eskimiş, arama doğru parçayı mı bulamamış, yoksa model bulduğu parçayı mı yanlış yorumlamış? Arama kayıtları bu durumları ayırt etmeye yardımcı olur. Yalnızca kaynak gösterilmiş olması, kaynağın yanıtı desteklediğini kanıtlamaz. Kaynaklar, kullanıcıların da yanıtı kontrol etmesini sağlar. Yanıta dayanarak bir karar verilecekse bu kontrol daha da önemlidir.
Testler sistem devreye alınınca bitmez. Belgeler değişir, yeni ürünler çıkar, kimsenin beklemediği sorular gelir. Görüşmenin bir çalışana aktarıldığı durumlar, kullanıcıların yararsız bulduğu yanıtlar ve chatbot’un yanıtlayamadığı sorular düzenli olarak incelenmelidir. Bu incelemeyi üstlenen kişi, önemli örnekleri test kümesine eklemelidir. Böylece test kümesi, chatbot’un yanıtlaması beklenen sorularla birlikte gelişir. Bir belge güncellendiğinde veya model değiştiğinde bu soruları yeniden denemek, sonucu kontrol etmenin en hızlı yolu olur.
Chatbot projesinde hangi işler daha çok emek gerektirecek?
Kapsamı belirlemeye yardımcı olacak dört soru.
1 / 4
Yanıtların çoğu nerede bulunuyor?
Sonraki soru
Önce sorular ve kurallar
Kendi verileriyle chatbot geliştirmek isteyen bir şirket genellikle belgeleri toplamaya başlar. Oysa bir hesap tablosuyla başlamak daha yararlıdır. Yüz gerçek soru toplayıp her birinin yanına yanıtın nerede bulunduğunu yazmak iyi bir başlangıçtır. Birden fazla kaynak varsa hangisi esas alınacak? Yanıtı kimler görebilecek ve chatbot bu soruyu yanıtlamalı mı? Tablo bu kararları da içermelidir.
Bu tabloyu doldurmak kolay değildir. Kimsenin güncellemediği fiyat listesini, üç farklı sürümü bulunan politikayı, yalnızca bir kişinin bildiği yanıtı ve bağlantı kurmak için kullanılabilecek bir arayüzü bulunmayan sistemi ortaya çıkarır. Bu çalışma yapılmazsa eksiklikler daha sonra, chatbot’un bir müşteriye kesin bir dille verdiği yanlış yanıtta ortaya çıkar.
Tablo, ekibin işe somut gereksinimlerle başlamasını sağlar. Yanıtları yazan model seçilebilir, sonradan değiştirilebilir. Hangi kaynakların esas alınacağına ve bir yanıtın hangi koşullarda kabul edileceğine karar vermek ise şirketin sorumluluğundadır. Şirket, bütün sistemin bu kurallara uyduğunu da test etmelidir.
