RAG nedir? Şirket dokümanlarınızla çalışan yapay zeka asistanı
RAG chatbot nedir, ince ayar ve basit aramaya göre ne zaman daha doğru seçimdir ve cevaplarını ekibe açmadan önce kaynak doğruluğunu nasıl test edersiniz.
Bir RAG chatbot, genel bir dil modelinin eğitimde ezberlediklerinden değil, sizin kendi dokümanlarınızdan cevap verir. Sorunun ilgili olduğu pasajları dosyalarınızda bulur, bu pasajları modele verir ve modelden yalnızca bu pasajlara dayanarak, her iddianın kaynağını göstererek cevap yazmasını ister. Doküman cevabı içermiyorsa iyi kurulmuş bir sistem bunu açıkça söyler.
Bu yazıda RAG’in nasıl çalıştığını, ince ayar (fine-tuning) ve düz aramaya göre ne zaman doğru seçim olduğunu, neyin ters gidebildiğini ve projeye başlamadan önce neleri hazırlamanız gerektiğini anlatıyoruz. Yazı, karar vermesi gereken şirket sahipleri ve operasyon yöneticileri için hazırlandı. Geliştiriciler için değil.
RAG ne demek, sade bir dille?
RAG, “retrieval augmented generation” ifadesinin kısaltmasıdır. Türkçesiyle “geri getirme destekli üretim” diyebiliriz. Terim, Patrick Lewis ve ekibinin 2020’de yayımladığı Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks makalesiyle yaygınlaştı. Fikir basit: bir model cevap vermeden önce dışarıdaki metinlere bakabiliyorsa, yalnızca eğitimde öğrendiklerine bağımlı kalmaz.
Bir şirket RAG sistemi iki aşamada çalışır. Önce dokümanlar hazırlanır. Her dosya birkaç paragraflık parçalara (chunk) bölünür ve her parça anlamını temsil eden bir sayısal vektöre çevrilir. Vektörler ve özgün metin bir arama dizinine yazılır. Sonra bir soru geldiğinde soru da vektöre çevrilir, dizin anlamca en yakın parçaları getirir ve dil modeli soruyla birlikte bu parçaları alır.
Asıl işi geri getirme adımı yapar. Doğru pasaj getirilmezse model ne kadar güçlü olursa olsun doğru cevap veremez. Bu yüzden bir entegrasyon projesinde zamanın büyük kısmı doküman hazırlığına ve geri getirme testlerine gider, prompt’un kelimelerine değil.
Ne zaman RAG doğru araçtır?
Üç yaklaşım sık karıştırılır. Düz arama, dokümanları ya da bağlantıları listeler ve okumayı kullanıcıya bırakır. İnce ayar, modeli örneklerle eğitip davranışını değiştirir. RAG ise modeli olduğu gibi bırakır ve ilgili metni soru anında ekler. Aşağıdaki tablo farkları gösteriyor.
| Doküman üzerinde arama kutusu | İnce ayar (fine-tuning) | RAG chatbot | |
|---|---|---|---|
| Kullanıcı ne alır | Açılacak dosyaların listesi | Belirli bir üslup ya da görevi öğrenmiş model | Kaynak pasajlarla birlikte doğrudan cevap |
| Doküman değişince | Dizin güncellenir, etkisi hemen görülür | Yeni bir eğitim turu gerekir | Değişen dosyalar yeniden indekslenir |
| Kaynak gösterimi | Dosyanın kendisi | Genellikle yok | Pasaj ve doküman referansı |
| İyi olduğu durum | Bilinen bir dosyayı bulmak | Ton, çıktı biçimi, sınıflandırma | Tanımlı bir doküman kümesinden soru yanıtlamak |
| Ana risk | Kullanıcı cevabı bulamadan vazgeçer | Kaynaksız, emin görünen cevaplar ve eski bilgi | Kaçırılan pasajlar ve kaynakların ötesine geçen cevaplar |
Basit bir ölçüt: soru “bu konu hangi dosyada” ise arama yeterlidir. Soru “bu durumda politikamız ne diyor” ise RAG uygundur. İnce ayar, modelin nasıl yanıt vereceğini öğretmek için kullanılır; her ay değişen bilgileri saklamak için uygun değildir. Birçok ekip sonunda RAG’i düz aramayla yan yana kullanır, çünkü çalışanlar bazen orijinal dosyanın kendisini ister.
Şirketinizde nerede işe yarar?
Üç kullanım en sık karşımıza çıkar.
İç politika asistanı. Çalışanlar izin kurallarını, harcama limitlerini ya da bir iade sürecinin adımlarını sorar. Kaynaklar İK el kitabı, finans politikası ve prosedür dokümanlarıdır. Asistan bir iki cümleyle cevap verir ve kullandığı bölümün bağlantısını gösterir, böylece çalışan konu önemliyse tam metni okuyabilir.
Ürün dokümantasyonu üzerinden destek ajanı. Destek ekibi ya da müşteri bir özelliğin nasıl çalıştığını, bir hata kodunun ne anlama geldiğini ya da bir pakete hangi seçeneğin dahil olduğunu sorar. Kaynak ürün dokümantasyonu, sürüm notları ve bilinen sorunlar listesidir. Ana kazanç tutarlılıktır: cevap en iyi hatırlayan kişiden değil, güncel dokümandan gelir.
Sözleşme ve fiyat listeleri için satış asistanı. Bir satış temsilcisi, belli bir sözleşme tipinde standart ödeme koşullarını ya da hangi indirimin onay gerektirdiğini sorar. Asistan onaylı fiyat listesini ve sözleşme şablonlarını okur. Bu senaryo yalnızca erişim kuralları doğru kurulduğunda işe yarar. Yeni başlayan bir temsilcinin kâr marjlarını ya da eski bir fiyat listesini görmemesi gerekir.
Üç durumda da asistan, karar veren insanlar için bir okuma aracıdır. Kararın yerini almaz.
Nerede hata yapar?
RAG hatalarının çoğu dil modelinden değil, onun etrafındaki veriden kaynaklanır.
Eski dokümanlar. Dizinde geçen yılın fiyat listesi ya da martta yerine yenisi konmuş bir politika duruyor olabilir. Güncellemeyi kimsenin sahiplenmediği yerde asistan eski cevabı, geçerli görünen bir kaynakla birlikte, tam bir güvenle verir. Çözüm; her doküman grubu için adı belli bir sorumlu, düzenli bir yeniden indeksleme ya da dosya değiştiğinde çalışan bir güncelleme ve her kaynakta görünen bir “son güncelleme” tarihi.
Zayıf parçalama. Dokümanlar sabit uzunlukta kesilirse bir tablo ikiye bölünür, bir tanım bir parçada kalır, istisnası bir sonrakinde çıkar, bir başlık da anlattığı paragraftan ayrılır. Geri getirilen pasaj neredeyse doğrudur ama cevabı değiştiren koşulu kaçırır. Parçalama dokümanın yapısını izlemelidir. Bölümler, tablolar ve listeler mümkünse bütün kalmalıdır.
Yetkiler. Kimin sorduğuna bakmayan bir arama, kullanıcının görmemesi gereken pasajları getirir. Kural prompt’a değil, geri getirme katmanına yazılmalıdır. Aday pasajlar, modele ulaşmadan önce kullanıcının erişim hakkına göre süzülmelidir. Modelin okuduğu kısıtlı bir pasajı sonradan tekrar edebileceğini unutmayın.
Uydurma cevaplar. Doğru pasajlar olsa bile model, metinde olmayan bir ayrıntıyı ekleyebilir ya da cümleyi desteklemeyen bir kaynak gösterebilir. Önlemler şunlardır: pasajlar soruyu yanıtlamıyorsa “dokümanlarda bulunamadı” demesini isteyen talimatlar, her iddianın bir kaynak taşıması zorunluluğu ve gösterilen metnin gerçekten iddiayı içerdiğinin kontrolü. Bazı model API’leri, kullandıkları pasajlarla ilişkili atıf referansları döndürebiliyor. Anthropic’in atıf (citations) dokümantasyonu bu özelliklerden birini anlatır. İlke hangi sağlayıcıyı seçerseniz seçin geçerlidir.
Yayına almadan önce nasıl test edersiniz?
Test, asistanı kimse kullanmadan önce başlar. Destek talepleri, e-postalar, sohbet kayıtları ve satış ekibinin notlarından gerçek sorular toplayın. Zor olanları da ekleyin: yazım hatası içerenleri, iki politikayı birden ilgilendirenleri ve dokümanların hiç cevaplayamayacağı soruları. Her soru için doğru cevabı ve cevabı içeren doküman bölümünü yazın. Bu küme sizin değerlendirme setinizdir ve projenin en değerli çıktısıdır. Model ya da tedarikçi değişse bile işe yaramaya devam eder.
İki şeyi ayrı ayrı puanlayın. Cevap doğruluğu, cevabın doğru olup olmadığına bakar. Atıf doğruluğu, gösterilen pasajın cevabı gerçekten destekleyip desteklemediğine bakar. Chatbot doğru cevabı yanlış bir kaynakla verebilir. Kaynağı kontrol eden bir denetçi ya da müşteri için bu da bir hatadır.
Yanlış bir cevapta hatanın nerede olduğunu bulun. Doğru pasaj getirilmediyse sorun arama ya da parçalamadadır. Pasaj geldi ama model yine de yanlış cevap verdiyse sorun talimatlarda ya da modeldedir. Pasaj eskiyse sorun doküman yönetimindedir. Her hata türünün çözümü farklıdır ve bunları karıştırmak haftalar kaybettirir.
Her değişiklikten sonra, yeni bir doküman, yeni bir parçalama kuralı ya da yeni bir model sürümü için tüm değerlendirme setini yeniden çalıştırın. Sonuçları basit bir tabloda tutun. Böylece ekip sistemin gerçekten iyileşip iyileşmediğini, yalnızca değişip değişmediğini görebilir.
Barındırma ve veri tercihleri
İki yol yaygındır. Birincisinde sistem barındırılan bir model API’sini çağırır. Model güçlüdür ve sunucu yönetmeniz gerekmez. Ancak geri getirilen pasajlar, içinde müşteri ya da personel verisi olabilecek metinler, sağlayıcıya gönderilir. Dizine kişisel veri girmeden önce sözleşme koşulları, veri saklama ayarları ve sağlayıcının işleme yeri incelenmelidir.
İkincisinde açık ağırlıklı (open-weight) bir model, kendi kontrolünüzdeki altyapıda çalışır. Bu altyapı kendi veri merkeziniz ya da seçtiğiniz bir bulut bölgesi olabilir. Açık ağırlıklı modeller zor akıl yürütmede genellikle daha zayıftır. Ama tanımlı bir doküman kümesinden cevap vermek için çoğu zaman yeterlidir ve veri ortamınızdan çıkmaz. Bedeli operasyoneldir: birinin sunucuyu işletmesi, modeli güncellemesi ve sonuçları izlemesi gerekir.
Türkiye’de bu kararın hukuki bir boyutu da var. Veri sorumlusu olarak şirketiniz, 6698 sayılı Kişisel Verilerin Korunması Kanunu’na (KVKK) tabidir. Kanunun yurt dışına aktarımı düzenleyen 9. maddesi 2024’te değiştirildi, ardından yurt dışına aktarımın usul ve esaslarına ilişkin yönetmelik yürürlüğe girdi. Güncel metinleri ve rehberleri Kişisel Verileri Koruma Kurumu yayımlar. Kişisel veri içeren dokümanlar için barındırılan bir API seçmeden önce, bu verinin durumunu bir hukuk danışmanına değerlendirtmenizi öneririz. Bu yazı hukuki tavsiye değildir.
Dil kalitesi ayrı bir konudur. Geri getirme, kullandığınız gömme (embedding) modelinin Türkçeyi ne kadar iyi anladığına bağlıdır. Türkçede ekler, birleşik sözcükler ve kısaltmalar yoğundur. İngilizce öncelikli bir kurulum, bir Türk okuyucunun hemen fark edeceği pasajları kaçırabilir. Geri getirmeyi kendi arşivinizden Türkçe sorular ve Türkçe dokümanlarla test edin. Tedarikçinin dil iddialarına tek başına güvenmeyin.
Başlamadan önce ne hazırlamalısınız?
Projeye başlamak için tam bir veri altyapısı gerekmez. Ama dört şey gerekir.
- Doküman envanteri. Asistanın kullanabileceği her kaynağı listeleyin: dosya türü, sorumlusu, son güncelleme tarihi, dili ve nerede saklandığı. Sahibi olmayan dokümanlar genellikle yukarıda anlatılan eski cevapların kaynağı olur.
- Erişim kuralları. Hangi dokümanı kimin okuyabileceğini yazılı hale getirin. Bu kuralların bir kısmı dosya sunucunuzda ya da CRM’inizde zaten vardır. Bir kısmı ilk kez yazıya dökülecektir.
- Örnek sorular. Asistanı kullanacak kişilerden gerçek sorular toplayın. Bugün neyi aradıklarını ve bilmedikleri bir konuda bir meslektaşlarına ne sorduklarını sorun. Bu sorular değerlendirme setinin ilk sürümü olur.
- Tek bir sorumlu. Hangi dokümanın yetkili olduğuna karar veren, cevap kurallarındaki değişiklikleri onaylayan ve hata kaydını her ay gözden geçiren kişi.
Dokümanlarınızın ve sistemlerinizin bu yapıya nasıl oturacağını görmek isterseniz, yapay zeka entegrasyonu hizmetimiz doküman hattını, geri getirmeyi, erişim kontrolünü ve personelinizin zaten kullandığı araçlara bağlantıyı kapsar. İlk görüşme için bizimle iletişime geçebilirsiniz.