RAG Nedir? Kurumsal Bilgi Tabanlarıyla Nasıl Kullanılır?

Kurumda çalışan herkes şu anı bilir: cevabı olan bir soru sorulur, cevap şirketin bir yerinde durur ve kimse üç gün içinde bulamaz. Tedarikçi sözleşmesindeki cezai şart maddesi, geçen yılki denetimde verilen taahhüt, üretim hattındaki arıza kodunun karşılığı. Bilgi kaybolmuş değildir; yüzlerce sayfalık PDF'lerin, iki ayrı intranet klasörünün ve arşivlenmiş e-posta zincirlerinin içine dağılmıştır. Genel amaçlı bir sohbet modeli aynı soruya saniyeler içinde cevap verir, ama verdiği cevabın sizin belgelerinizle ilgisi yoktur.

Kısa cevap: RAG (Retrieval Augmented Generation), bir yapay zeka modelinin cevabı ezberinden değil, soru sorulduğu anda kurumun kendi belgelerinden getirilen metin parçalarına bakarak yazmasıdır. Kurumsal karşılığı üç maddedir: cevap güncel belgeye dayanır, her cevabın altında kaynak referansı bulunur, bilgi değiştiğinde model yeniden eğitilmez — belge güncellenip yeniden indekslenir. Projelerin tıkandığı yer model değil, belge tarafıdır.

RAG nedir ve sıradan bir yapay zeka sohbetinden farkı nedir?

RAG, İngilizce "Retrieval Augmented Generation" ifadesinin kısaltmasıdır; Türkçeye "getirmeyle güçlendirilmiş üretim" diye çevrilebilir. Bir büyük dil modelinin (LLM, çok miktarda metinle eğitilmiş, metni kelime parçası — token — düzeyinde tahmin ederek üreten model) cevabı ezberinden değil, soru sorulduğu anda kurumun kendi belgelerinden getirilen metin parçalarına bakarak yazmasıdır.

Fark şuradadır. Modelin tek başına cevap vermesi kapalı kitap sınavına benzer: öğrenci hatırladığını yazar, hatırlamadığını emin bir dille uydurur. Buna halüsinasyon denir ve kurumsal kullanımda asıl risk budur, çünkü uydurulan cevap yanlış görünmez, doğru görünür. RAG ise açık kitap sınavıdır. Model önce ilgili sayfayı bulur, sonra o sayfaya bakarak cevap yazar ve hangi sayfaya baktığını söyler.

Bu üç sonucu doğurur:

• Cevap kurumun güncel belgesine dayanır, modelin eğitim verisine değil.
• Her cevabın altında kaynak referansı olur; cevap kontrol edilebilir hale gelir.
• Belge değiştiğinde cevap da değişir. Modeli yeniden eğitmek gerekmez; değişen belgenin yeniden parçalanıp indekslenmesi yeterlidir.

Buradaki yaygın yanılgıya not: RAG halüsinasyonu ortadan kaldırmaz, azaltır. Yanlış parça getirildiğinde model o yanlış parçaya sadık kalarak yine emin bir dille yanlış cevap üretir. Bu yüzden bir RAG sisteminin kalitesi, modelin kalitesinden çok getirmenin kalitesidir.

Kurumsal bir RAG sistemi hangi adımlarla çalışır?

1. Kaynak seçimi. Hangi arşivin cevap üretmeye yetkili olduğu belirlenir: prosedürler, sözleşmeler, teknik dokümanlar, ürün kataloğu, çağrı merkezi kayıtları. Yetkili kaynak listesi yoksa sistem, kurumdaki her çelişkiyi cevaba taşır.
2. Parçalama. Belgeler anlamlı parçalara (chunk) bölünür. Sınırlar sabit karakter sayısına göre değil, belgenin yapısına — madde, başlık, tablo satırı — göre çizilir; parçalar arasında bir miktar örtüşme bırakılır. Bir maddeyi ortasından bölen kötü bir parçalama, sistemin en sık görülen ve en geç fark edilen hatasıdır.
3. Vektörleştirme ve indeksleme. Her parça gömme vektörüne (embedding) çevrilir. Vektör, metnin anlamını sayı dizisine dönüştüren gösterimdir; anlamca yakın iki metin sayısal olarak da yakın durur. Bu vektörler bir vektör veritabanında saklanır. Belgeler ve sorular aynı gömme modeliyle vektörleştirilmelidir; gömme modeli değiştirilirse tüm arşivin yeniden vektörleştirilmesi gerekir.
4. Getirme. Soru geldiğinde en ilgili parçalar bulunur. Pratikte en iyi sonuç hibrit aramadan çıkar: anlam bazlı arama ile klasik anahtar kelime aramasının birlikte çalışması. Ürün kodu, madde numarası, mevzuat referansı gibi ifadeler anlam aramasıyla değil, birebir eşleşmeyle bulunur. Yetki filtresi de bu adımda uygulanır.
5. Yeniden sıralama. Gelen adaylar ikinci bir modelle soruyla ilgi derecesine göre sıralanır (reranking). Modele on parça yerine en doğru üç parçayı vermek, doğruluğu en ucuz yoldan artıran adımdır.
6. Üretim ve kaynak gösterimi. Model cevabı yazar, altına kullandığı belgeyi ve bölümü koyar. Modele verilen talimat nettir: yalnızca getirilen parçalara dayan, parçalarda cevap yoksa cevap uydurma, bilgi bulunamadığını söyle.
7. Kayıt ve izlenebilirlik. Soru, getirilen parçalar, verilen cevap, model sürümü ve zaman damgası loglanır. Bir cevabın neden öyle çıktığı sonradan sorulduğunda tek geçerli delil bu kayıttır. ISO 42001 gibi bir yapay zeka yönetim sistemi kapsamında çalışılıyorsa bu adım tercih değil, gerekliliktir.
8. Ölçüm. Getirme doğruluğu ile cevap doğruluğu ayrı ayrı ölçülür: doğru parça ilk sonuçlar arasında geldi mi, geldiyse cevap o parçaya sadık mı? Ayrım önemlidir, çünkü RAG sistemleri çoğunlukla üretimde değil getirmede başarısız olur.

RAG kurumsal olarak hangi işlerde kullanılır?

Aynı mimari, sektörden bağımsız olarak birkaç tipik işi çözer:

• İç bilgi asistanı. Prosedür, İK yönetmeliği, kalite dokümanı ve iş talimatlarına doğal dille soru sorulur; cevap madde referansıyla gelir.
• Sözleşme ve mevzuat taraması. Yüzlerce sözleşmede aynı maddenin nasıl yazıldığı, hangi dosyada istisna verildiği dakikalar içinde çıkarılır.
• Müşteri hizmetleri desteği. Temsilciye cevap önerilir, kaynak gösterilir; karar temsilcide kalır.
• Teknik servis ve saha. Cihaz kılavuzları ve arıza kayıtları tek arayüzde birleşir.
• Agent altyapısı. Bir AI agent (verilen hedefe göre adım planlayıp araç çağırabilen yapay zeka bileşeni) doğru bilgiye erişmeden güvenilir iş yapamaz. RAG, agent'ın hafızası değil, kaynağıdır. AI agent geliştirme en yoğun çalıştığımız alan ve kurumsal projelerde ilk kurulan katman genellikle bu oluyor.

RAG mı, modeli yeniden eğitmek (fine-tuning) mi?

İnce ayar (fine-tuning), hazır bir modeli kendi verinizle bir miktar daha eğitip davranışını değiştirmektir. İkisi rakip değil, farklı işler için kullanılır: RAG bilgiyi taşır, ince ayar biçimi ve davranışı taşır.

Kurumsal bilgi tabanı projelerinin büyük çoğunluğu RAG ile başlar. İnce ayar, RAG doğru kurulduktan sonra hâlâ kalan bir sorun varsa gündeme gelir. Sıralamayı ters çevirmek, çözülmemiş bir getirme problemini pahalı bir eğitim süreciyle örtmek anlamına gelir.

Kurumsal bilgi tabanınız RAG'a hazır mı?

Projeler modelde değil, bu başlıkta tıkanır. İlk teknik toplantıda cevaplanması gereken sorular şunlardır:

• Tek doğru kaynak var mı? Aynı prosedürün üç farklı sürümü dolaşıyorsa, sistem üçünden birini seçer ve yanlış olanı seçtiğinde bunu kimse fark etmez.
• Belgelerin tarihi ve sürümü belli mi? Yürürlükten kalkmış bir talimatın cevaba karışmaması için tarih, belgenin içinde bir metin değil, filtrelenebilir bir alan olmalıdır.
• Yetki modeli kurulacak mı? Kullanıcının açıp okuyamayacağı bir belge, cevabın içine özet olarak da girmemelidir. Yetki kontrolü sisteme sonradan eklenen bir özellik değil, ilk günden kurulan bir tasarım kararıdır.
• Belgeler makine tarafından okunabiliyor mu? Taranmış PDF, imzalı form ve el yazısı içeren evrak teknik olarak metin değil, görüntüdür. Bunların OCR ile metne dönüştürülmesi, tablo ve form yapısının bozulmadan çıkarılması gerekir; kurumsal projelerde en çok küçümsenen kalem budur.
• Terimler standart mı? Aynı kavramın üç farklı adı varsa — kısaltma, eski ad, saha jargonu — bunların bir eşanlam sözlüğüne bağlanması gerekir. Aksi halde kullanıcı doğru soruyu sorar, sistem belgeyi bulamaz.
• Başarı nasıl ölçülecek? Sahadan toplanmış, cevabı bilinen gerçek sorulardan oluşan bir test seti olmadan sistemin iyileşip iyileşmediği söylenemez. Bu set, ilk kod yazılmadan önce hazırlanır.

RAG projelerinde en sık yapılan hatalar nelerdir?

• Pilotu birkaç düzine belgeyle kurup on binlerce belgede aynı sonucu beklemek. Getirme kalitesi arşiv büyüdükçe düşer; ölçek testi baştan planlanır.
• Yalnızca anlam bazlı arama kullanmak. Ürün kodu, madde numarası ve seri numarası bu aramayla kaçar.
• Yetkiyi arayüz katmanında çözmeye çalışmak. Filtre, parçaların arandığı katmanda değilse gizli içerik cevabın içinde sızar.
• Kaynak göstermeden cevap vermek. Kaynağı olmayan cevap, kurumsal kullanımda doğrulanamaz ve bu nedenle kullanılamaz.
• Değerlendirme seti yazmadan üretime almak. Ölçülmeyen bir sistemde her değişiklik iyileştirme sanılır.

Kurumsal RAG nerede çalışmalı: kendi sunucunuzda mı, bulutta mı?

Kurumsal bilgi tabanı söz konusu olduğunda ilk soru model değil, verinin nerede işleneceğidir. Belgeler kurum dışına çıkmayacaksa sistem, lokal açık kaynak dil modelleriyle kurumun kendi sunucularında çalıştırılır; belgeler, vektör veritabanı ve model aynı ağda kalır. Konteyner tabanlı (Docker) dağıtım bu kurulumu taşınabilir ve tekrar edilebilir hale getirir.

Hibrit yaklaşım da mümkündür: hassas içerik lokal modelde işlenir, hassas olmayan görevler ticari API'lere verilir. Önemli olan, bu ayrımın mimarinin ilk gününde yapılmasıdır — hangi belgenin hangi modele gidebileceği sonradan eklenen bir kural değil, sistemin taşıyıcı kararıdır.

Sıkça sorulan sorular

RAG ile ince ayar (fine-tuning) arasındaki fark nedir?

RAG bilgiyi taşır, ince ayar biçimi ve davranışı taşır. RAG'da cevap, soru sorulduğu anda kurumun belgelerinden getirilen metin parçalarına dayanır ve kaynak gösterilebilir; bilgi değiştiğinde belge güncellenir, model aynı kalır. İnce ayarda model kendi verinizle bir miktar daha eğitilir; kurum dili, cevap formatı ve sabit çıktı şeması için uygundur ama kaynak gösteremez ve her bilgi güncellemesi yeniden eğitim gerektirir.

RAG halüsinasyonu tamamen ortadan kaldırır mı?

Hayır. RAG halüsinasyon riskini azaltır, sıfırlamaz. Yanlış parça getirildiğinde model o yanlış parçaya dayanarak emin bir dille yanlış cevap üretir. Riski gerçekten düşüren şey, getirme kalitesinin ayrıca ölçülmesi, her cevabın kaynak referansıyla verilmesi ve modele kaynakta bilgi yoksa cevap üretmeme talimatının verilmesidir.

Kurumsal RAG için kaç belge gerekir?

Belirleyici olan belge sayısı değil, belge disiplinidir. Aynı prosedürün üç farklı sürümü dolaşan bir arşivde on bin belge de sorunu çözmez; tek doğru kaynağı belli olan, tarihi ve sürümü alan olarak tutulan birkaç yüz belge çalışır bir sistem çıkarır. Doğru başlangıç, dar ama temiz bir kaynak kümesi seçip kapsamı ölçerek genişletmektir.

RAG kurulunca kurumun belgeleri dışarı çıkar mı?

Çıkmak zorunda değildir. Lokal açık kaynak dil modelleriyle kurulan on-premise bir RAG sisteminde belgeler, vektör veritabanı ve model kurumun kendi sunucularında kalır. Hibrit kurulumda hassas içerik lokal modelde işlenir, hassas olmayan görevler ticari API'lere verilir. Bu karar mimarinin ilk gününde alınır; sonradan değiştirilmesi maliyetlidir.

Taranmış PDF ve el yazısı içeren belgeler RAG sistemine girebilir mi?

Metin katmanı çıkarıldıktan sonra girebilir. Taranmış PDF, imzalı form ve el yazısı içeren evrak teknik olarak görüntüdür; OCR ile metne dönüştürülmeden ne parçalanabilir ne vektörleştirilebilir. Bu dönüşüm, kurumsal RAG projelerinin en çok küçümsenen kalemidir; tablo ve form yapısı dönüşümde bozulursa cevaplar da bozulur.

Yetkisiz bir kullanıcı gizli bir belgenin içeriğini RAG cevabında görebilir mi?

Yetki kontrolü getirme katmanında kurulmamışsa görebilir. Kullanıcının açıp okuyamayacağı bir belge, cevabın içine özet veya alıntı olarak da girmemelidir. Doğru tasarımda erişim filtresi arayüzde değil, parçaların arandığı katmanda uygulanır; kullanıcının yetkisi olmayan parça hiç getirilmez. Bu sonradan eklenen bir özellik değil, ilk günden alınan bir tasarım kararıdır.

Bir RAG projesinin süresini ne belirler?

Süreyi model seçimi değil, belge tarafı belirler. Kaynakların tekilleştirilmesi, tarih ve sürüm alanlarının çıkarılması, taranmış evrakın metne dönüştürülmesi ve yetki matrisinin netleştirilmesi zamanın büyük bölümünü alır. Belgeleri düzenli bir kurumda pilot hızlı kurulur; arşivi dağınık bir kurumda proje, modelden önce veri hazırlığında geçer.

Kendi belgeleriniz üzerinde çalışan bir sistem kurmak

Kurumsal RAG, bir model tercihinden çok bir belge ve yetki tasarımıdır. Hangi arşivin cevap üretmeye yetkili olduğuna, verinin nerede işleneceğine ve başarının nasıl ölçüleceğine ilk toplantıda karar verilirse geri kalanı mühendislik işidir.

Bu başlıkları kendi kurumunuz için konuşmak isterseniz: 0540 509 19 05 · gokhan@aiyapayzeka.io (her gün 09.00–19.00). En yoğun çalıştığımız alan AI agent geliştirme; RAG bu sistemlerin bilgi katmanı olarak kuruluyor.

Yazar: Dr. Gökhan Tahıl — Kurucu, AI Yapay Zeka Mühendislik A.Ş. Yapay zeka alanında doktora sahibi. Şirket ISO 42001 (yapay zeka yönetim sistemi) belgelidir ve aynı standartta danışmanlık vermektedir. Son güncelleme: Ağustos 2026.

Ücretsiz danışmanlık için bize ulaşın

← Tüm yazılar