RAG Nedir? Şirket Verisiyle Çalışan Yapay Zekâ

RAG (Retrieval-Augmented Generation, erişimle güçlendirilmiş üretim), bir dil modelinin soruyu yanıtlamadan önce şirketinizin belgelerinde ilgili bölümleri bulup okuduğu ve yanıtını bu kaynaklara dayandırdığı yöntemdir. Modeli yeniden eğitmeniz gerekmez; belgeleriniz güncellendikçe yanıtlar da güncellenir ve her yanıt dayandığı kaynağı gösterebilir.

Bu yazı teknik ekipler için değil, bu konuda karar verecek yöneticiler için. Yöntemin nasıl çalıştığını, kaliteyi neyin belirlediğini, yetkilerin nasıl korunduğunu, başarının nasıl ölçüldüğünü ve ne zaman başka bir yaklaşımın daha doğru olduğunu sade bir dille anlatıyoruz. Konuyu şirketinizin genel yapay zekâ planı içinde ele almak isterseniz yapay zekâ danışmanlığı sayfamıza göz atabilirsiniz.

Dil modelleri şirketinizi neden tanımaz?

Büyük dil modelleri (LLM), internetten ve lisanslı kaynaklardan derlenen geniş metinlerle belirli bir tarihe kadar eğitilir. Sözleşmelerinizi, iç prosedürlerinizi, ürün kataloğunuzu ya da geçen hafta değişen bir kuralı bilmezler. Bilmedikleri bir soruyla karşılaştıklarında ise kimi zaman "bilmiyorum" demek yerine akla yatkın ama yanlış bir yanıt üretirler. Buna halüsinasyon denir.

Bir modele şirket bilgisini vermenin üç temel yolu vardır:

  • Belgeyi doğrudan isteme eklemek: Birkaç sayfalık içerik için işe yarar, ancak yüzlerce belgede hem modelin sınırlarına takılır hem de her soruda maliyeti artırır.
  • İnce ayar (fine-tuning): Modeli kendi örneklerinizle ek olarak eğitmektir. Davranışı ve üslubu değiştirir, ama sık değişen bilgiyi taşımak için uygun değildir.
  • RAG: Bilgiyi modelin içine değil, yanına koymaktır. Model her soruda yalnızca ilgili bölümleri okur.

Şu tür kullanımların çoğunda doğru başlangıç noktası RAG yöntemidir:

  • Çalışanların prosedür, politika ve teknik belgelerde soru sorduğu şirket içi bilgi asistanları.
  • Müşteri destek ekipleri için kaynak gösteren yanıt taslakları.
  • Sözleşme, ihale ve teklif dosyalarında arama.
  • Ürün ve hizmet dokümantasyonu üzerinden çalışan müşteri asistanları.

RAG adım adım nasıl çalışır?

Bir RAG sistemi iki aşamadan oluşur: belgelerin hazırlanması ve soruların yanıtlanması.

  1. Toplama: PDF'ler, iç wiki sayfaları, destek kayıtları, e-postalar ya da veritabanı kayıtları gibi kaynaklar belirlenir ve düzenli olarak sisteme alınır.
  2. Parçalama (chunking): Uzun belgeler, her biri tek bir konuyu anlatan daha küçük bölümlere ayrılır.
  3. Embedding: Her parça, anlamını temsil eden bir sayı dizisine, yani bir vektöre dönüştürülür. Anlamca birbirine yakın metinlerin vektörleri de birbirine yakın olur.
  4. Saklama: Vektörler; belgenin adı, tarihi ve erişim yetkisi gibi bilgilerle birlikte bir vektör veritabanına kaydedilir.
  5. Arama: Kullanıcı soru sorduğunda soru da vektöre çevrilir ve ona en yakın parçalar bulunur. Buna vektör araması ya da anlamsal arama denir.
  6. Yanıt: Bulunan parçalar soruyla birlikte dil modeline verilir. Model yanıtı bu parçalara dayanarak yazar ve hangi belgelerden yararlandığını gösterir.

Bu yapının önemli bir avantajı vardır: Bir belge güncellendiğinde yalnızca o belgenin parçaları yeniden işlenir. Modele dokunmadan bilgi tazelenir. Çalışma maliyetini ise büyük ölçüde belge hacmi, soru sayısı ve her soruda modele gönderilen metin miktarı belirler.

Yanıt kalitesini ne belirler?

RAG projelerinde sorunlar çoğu zaman modelden değil, aramadan kaynaklanır. Model doğru parçayı göremezse, ne kadar güçlü olursa olsun doğru yanıtı veremez. Kaliteyi belirleyen başlıca kararlar şunlardır:

  • Parça boyutu: Çok küçük parçalar bağlamı kaybeder, çok büyük parçalar ilgisiz metni de beraberinde taşır. Doğru boyut belge türüne göre değişir ve denemeyle bulunur.
  • Yapıyı korumak: Başlıkları, bölüm adlarını ve tarihleri parçayla birlikte saklamak hem aramayı hem de kaynak göstermeyi kolaylaştırır.
  • Hibrit arama: Ürün kodu, sözleşme numarası ya da özel isim gibi ifadelerde anlamsal arama tek başına zayıf kalabilir. Anahtar kelime aramasıyla birleştirmek bu açığı kapatır.
  • Yeniden sıralama (reranking): Bulunan aday parçalar, ikinci bir modelle soruya uygunluklarına göre yeniden sıralanır.
  • Belge kalitesi: Taranmış PDF'ler metin tanıma (OCR) ile metne çevrilmeli, tablolar ayrıca ele alınmalı, eski ve çelişen sürümler ayıklanmalıdır.
  • Güncellik: Bir belge değiştiğinde ya da silindiğinde dizinin de gecikmeden güncellenmesi gerekir; aksi hâlde asistan yürürlükten kalkmış bir kuralı yanıt olarak sunar.

Son madde çoğu zaman hafife alınır. Aynı prosedürün üç farklı sürümü yan yana dururken en iyi sistem bile hangisinin geçerli olduğunu tahmin etmek zorunda kalır.

Yetkiler ve veri güvenliği nasıl korunur?

Şirket verisiyle çalışan bir asistanın ilk kuralı şudur: Kullanıcı, açmaya yetkisi olmayan bir belgeyi asistan aracılığıyla da görememelidir. Bunun için yetki kontrolü arama sırasında uygulanır. Her parça kaynak belgenin erişim bilgisini taşır ve arama yalnızca kullanıcının görmeye yetkili olduğu parçalar arasında yapılır. Kaynak sistemde bir yetki değiştiğinde, örneğin bir çalışan başka bir departmana geçtiğinde, bu değişiklik asistana da hemen yansımalıdır.

Modele "bu bilgiyi paylaşma" demek bir güvenlik önlemi değildir. Modelin önüne konmaması gereken bilgi, hiç konmamalıdır. Bunun yanında şu konular en baştan netleşmelidir:

  • Kişisel veri: Belgelerde kişisel veri varsa hangi amaçla işlendiği, maskelenip maskelenmeyeceği ve KVKK kapsamındaki yükümlülükler.
  • Verinin işlendiği yer: Bulut tabanlı bir model sağlayıcısı mı, belirli bir bölgedeki sunucular mı, yoksa kendi altyapınızda çalışan bir model mi?
  • Kayıt ve saklama: Sorular ve yanıtlar ne kadar süreyle ve kimlerin erişimiyle saklanacak?
  • İstem enjeksiyonu (prompt injection): Belgelerin içine gizlenmiş talimatlarla modelin yönlendirilmeye çalışılmasıdır. Dış kaynaklı belgeler bu açıdan ayrıca denetlenmelidir.

Kişisel veriyle çalışmadan önce yapılması gereken kontrolleri KVKK ve yapay zekâ yazımızda maddeler hâlinde topladık.

Bir RAG sisteminin doğru çalıştığını nasıl ölçersiniz?

"Denedik, iyi görünüyor" bir ölçüm değildir. Sistem canlıya çıkmadan önce bir değerlendirme seti hazırlanmalıdır:

  1. Gerçek soruları toplayın. Çalışanların ya da müşterilerin bugün e-postayla, telefonla ya da destek kaydıyla sorduğu soruları derleyin.
  2. Doğru yanıtı ve kaynağı yazın. Her soru için konuyu bilen bir kişi beklenen yanıtı ve dayandığı belgeyi belirlesin.
  3. Aramayı ayrı ölçün. Sistem doğru parçayı ilk sonuçlar arasında buldu mu?
  4. Yanıtı ayrı ölçün. Yanıt kaynaklara sadık mı, eksiksiz mi, kaynakta olmayan bir bilgi eklenmiş mi?
  5. "Bilmiyorum" davranışını test edin. Belgelerde yanıtı olmayan sorularda sistem uydurmak yerine bunu açıkça söylemelidir.

Canlıda ise yanıtların altına basit bir geri bildirim düğmesi koyun ve yanıtlanamayan soruları kaydedin. Model, parçalama ya da arama ayarı her değiştiğinde aynı değerlendirme setini yeniden çalıştırın.

Ne zaman RAG yerine ince ayar daha doğrudur?

RAG ve ince ayar birbirinin rakibi değil, farklı sorunların çözümüdür. Kısaca:

  • Bilgi sık değişiyorsa, kaynak göstermek gerekiyorsa ve yetkiler kullanıcıya göre farklıysa RAG doğru seçimdir.
  • Model belirli bir biçimde, üslupta ya da sınıflandırma mantığında tutarlı davranmalıysa ince ayar daha uygundur. Gelen talepleri sabit kategorilere ayırmak ya da raporları her seferinde aynı yapıda yazmak buna örnektir.
  • Dar ve tekrar eden bir görevde ince ayar yapılmış küçük bir model, büyük bir modelden daha hızlı ve daha ekonomik olabilir.
  • İkisi birlikte de kullanılabilir: İnce ayar davranışı, RAG ise bilgiyi sağlar.

Bazen ikisine de gerek yoktur. Soru "geçen ay hangi bölgeden kaç sipariş geldi?" gibi yapılandırılmış veriye dayanıyorsa doğru araç bir rapor ya da veritabanı sorgusudur. RAG ayrıca yapay zekâ ajanlarının bilgi katmanı olarak da kullanılır; bu konuyu otonom yapay zekâ ajanları yazımızda ele aldık.

Bir yapay zekâ asistanı, ancak dayandığı belgeler kadar güvenilirdir.

Sık sorulan sorular

RAG için verilerimizi bir yapay zekâ sağlayıcısına göndermemiz gerekir mi?

Mimariye bağlıdır. Bulut tabanlı bir model kullanıldığında yalnızca soruyla ilgili parçalar modele gönderilir; veri işleme koşulları ve sunucu bölgesi sözleşmeyle netleştirilmelidir. Hassas veride, kendi sunucularınızda çalışan açık kaynaklı bir model de seçenekler arasındadır.

RAG halüsinasyonu tamamen önler mi?

Hayır, ama önemli ölçüde azaltabilir. Yanıtların kaynak göstermesini zorunlu kılmak, yanıt bulunamadığında "bilmiyorum" denmesini sağlamak ve düzenli değerlendirme yapmak riski yönetilebilir seviyede tutar.

Hangi belgeler RAG için uygundur?

Metin ağırlıklı, güncel ve sahibi belli belgeler en iyi sonucu verir: prosedürler, politikalar, ürün dokümanları, sözleşmeler ve destek kayıtları. Eski, çelişkili ya da kopya belgeler kaliteyi düşürür; bu yüzden işe bir ayıklamayla başlamak gerekir.

Ayrı bir vektör veritabanı şart mı?

Her zaman değil. Bazı ilişkisel veritabanları ve arama motorları vektör aramayı destekler. Belge sayısı sınırlıysa mevcut altyapınızla başlamak, yeni bir ürün eklemekten daha basit olabilir.

Nereden başlamalı?

Çok soru alan tek bir alan seçin: insan kaynakları politikaları, teknik destek ya da satış dokümanları gibi. O alanda son dönemde sorulan gerçek soruları toplayın, yanıtların hangi belgelerde durduğunu işaretleyin ve bu belgelerin güncel olup olmadığını kontrol edin. Bu liste hem pilotun kapsamını hem de değerlendirme setinizi belirler.

Şirket verinizle çalışan bir yapay zekâ asistanını birlikte planlamak isterseniz bizimle iletişime geçin.

← Tüm yazılar

WhatsApp'tan Yazın