RAG Nedir? Kurumsal Bilgi Erişimi İçin Kapsamlı Türkçe Rehber

RAG nedir? RAG (Retrieval-Augmented Generation, Türkçesiyle bilgi getirimiyle üretim), bir dil modelinin yanıt üretmeden önce dış bir bilgi kaynağından soruyla ilgili belgeleri getirip bağlamına eklediği bir yapay zeka mimarisidir. Böylece model yalnızca eğitim verisine değil, kurumun güncel ve özel bilgisine de dayanarak, kaynak göstererek cevap verir.

Bir dil modelinin iki büyük zayıflığı vardır: bilgisi eğitim tarihinde donmuştur ve sizin kurumunuza özel belgeleri hiç görmemiştir. RAG tam olarak bu iki sorunu çözer — modele "cevabı uydurma, önce şu belgelere bak" der. Bu rehberde rag nedir, neden gerekli, nasıl çalışır, embedding ve vektör veritabanı ile ilişkisi nedir, chunking ve reranking neden kalitenin kalbindedir, RAG ile fine-tuning arasındaki fark nedir, kurumsal bilgi erişimi ve KVKK bağlamında nasıl kurulur, halüsinasyon azaltma nasıl sağlanır, kalite nasıl ölçülür ve hybrid search ile GraphRAG gibi ileri teknikler nedir sorularını bir danışman titizliğiyle ele alıyoruz.

Tanım

RAG (Retrieval-Augmented Generation)

Bir dil modelinin yanıt üretmeden önce dış bir bilgi kaynağından (kurumsal belgeler, veritabanı, bilgi tabanı) ilgili parçaları getirip bağlamına eklediği yapay zeka mimarisi. Getirme aşaması embedding ve vektör veritabanı ile anlamsal arama yapar; üretme aşaması getirilen parçalara dayanarak yanıt yazar. RAG, modelin eğitim verisiyle sınırlı kalmasını engeller; güncel ve kuruma özel bilgiye kaynak göstererek erişim sağlar ve halüsinasyonu azaltır.

Ayrıca: Retrieval-Augmented Generation, bilgi getirimiyle üretim, getirmeyle zenginleştirilmiş üretim, RAG

Rag nedir sorusunun en kısa cevabı şudur: bir dil modelini, kendi eğitim belleği yerine (veya ona ek olarak) dışarıdan getirilen belgelere dayandırarak yanıt ürettiren mimari. "Retrieval" (getirme) kelimesi, sistemin önce bir arama yaptığını; "Augmented" (zenginleştirilmiş) kelimesi, modelin bağlamının bu aramayla beslendiğini; "Generation" (üretme) kelimesi ise modelin nihai yanıtı bu bağlama dayanarak yazdığını anlatır. Üç kelime, üç adımı özetler.

Bir benzetme yardımcı olur. Klasik bir dil modeli, kapalı kitap sınavına giren bir öğrenci gibidir: yalnızca hafızasında ne varsa onunla cevap verir, hatırlamadığını uydurur. RAG ise açık kitap sınavına giren bir öğrenci gibidir: soruyu okur, ilgili sayfayı açar, oradan okuyarak ve kaynak göstererek cevap yazar. Modelin akıl yürütme yeteneği aynıdır; değişen, ona doğru sayfayı vermenizdir. İşte RAG mimarisi tam olarak bu "doğru sayfayı bulup önüne koyma" işini otomatikleştirir.

Bu ayrım kritik bir mimari sonuç doğurur: modelin akıl yürütme yeteneği ile kurumun bilgisi birbirinden ayrılır. Model "nasıl cevap vereceğini" bilir; RAG ona "hangi bilgiyle cevap vereceğini" verir. Bu ayrışma sayesinde aynı modeli farklı bilgi tabanlarıyla çalıştırabilir, bilgiyi modelden bağımsız güncelleyebilir ve modeli yeniden eğitmeden yeni belgeler ekleyebilirsiniz. Dil modellerinin temelini anlamak için LLM nedir ve modelin metni nasıl parçalara ayırdığını görmek için token nedir rehberleri iyi bir başlangıçtır.

Rag nedir sorusuna verilecek en ikna edici cevap, "hangi sorunu çözdüğü"nü göstermektir. Bir dil modeli etkileyici biçimde akıcıdır, ama üç temel sınırı vardır ve RAG bu üçüne birden yanıt verir.

Birincisi bilgi kesim tarihidir. Model yalnızca eğitildiği tarihe kadarki bilgiyi taşır; dün yayımlanan bir yönetmeliği, bu sabah güncellenen bir fiyat listesini veya geçen hafta değişen bir prosedürü bilemez. Kurumsal bilgi ise sürekli değişir. RAG, bilgiyi modelin dışında, güncellenebilir bir kaynakta tutarak bu donmuşluğu aşar: belge değişince yanıt da değişir, modeli yeniden eğitmeye gerek kalmaz.

İkincisi kuruma özel bilgi eksikliğidir. Genel bir model, sizin iç sözleşmelerinizi, ürün dokümantasyonunuzu, İK politikalarınızı veya destek geçmişinizi hiç görmemiştir. Bu bilgiyi ona eğitim yoluyla vermek pahalı ve yavaştır; RAG ise bu belgeleri bir bilgi tabanına koyup anında erişilebilir kılar. Böylece genel bir model, sizin kurumunuzun uzmanı gibi konuşmaya başlar.

Üçüncüsü ve en tehlikelisi halüsinasyondur. Bir model bilmediği bir şeyi sorulduğunda, "bilmiyorum" demek yerine inandırıcı ama yanlış bir cevap uydurabilir. Kurumsal bir uygulamada yanlış ama kendinden emin bir yanıt, yanıt yokluğundan daha risklidir; çünkü kullanıcı ona güvenip yanlış karar verir. Halüsinasyonun ne olduğunu yapay zeka halüsinasyonu nedir yazısında ele alıyoruz. RAG, modeli cevap üretmeden önce gerçek belgelere dayandırarak bu riski yönetir; günümüzde halüsinasyon azaltmanın en pratik ve en yaygın yolu RAG mimarisidir.

Rag nedir kadar önemli bir soru da RAG'in perde arkasında tam olarak nasıl çalıştığıdır. RAG iki büyük evreye ayrılır: çevrimdışı hazırlık (indeksleme) ve çevrimiçi sorgu (getirme + üretme). İlk evre bir kez ve periyodik olarak yapılır; ikinci evre her kullanıcı sorusunda tekrar eder.

Çevrimdışı hazırlık evresinde belgeleriniz sisteme alınır: PDF, Word, web sayfası, veritabanı kaydı, e-posta gibi kaynaklardan metin çıkarılır, temizlenir, anlamlı parçalara bölünür (chunking), her parça bir embedding modeliyle vektöre çevrilir ve bu vektörler meta veriyle birlikte bir vektör veritabanına yazılır. Bu evre iyi yapıldığında, geri kalan her şey kolaylaşır; kötü yapıldığında ise en güçlü model bile kurtaramaz.

Çevrimiçi sorgu evresi ise şöyle işler:

Nasıl Yapılır

Bir RAG sorgusunun yaşam döngüsü

Kullanıcının sorusundan kaynak gösteren yanıta kadar RAG boru hattının izlediği temel adımlar.

1. 1

   Soruyu anla ve vektöre çevir

   Kullanıcının sorusu temizlenir, gerekirse yeniden yazılır ve bir embedding modeliyle anlamsal bir vektöre dönüştürülür.

2. 2

   İlgili parçaları getir

   Vektör veritabanında soruya anlamca en yakın belge parçaları bulunur; bu aday kümesi genellikle geniş tutulur.

3. 3

   Yeniden sırala (rerank)

   Aday parçalar bir reranker ile gerçek alaka düzeyine göre yeniden sıralanır; en iyi birkaçı seçilir.

4. 4

   Bağlamı kur ve promptu oluştur

   Seçilen parçalar, talimatlar ve soruyla birlikte modele verilecek son prompt haline getirilir.

5. 5

   Kaynak göstererek yanıt üret

   Model, yalnızca verilen parçalara dayanarak yanıtı yazar ve hangi belgeye dayandığını belirtir.

Bu akışın her adımı bir kalite kaldıracıdır. Soru yeniden yazma (query rewriting), belirsiz soruları netleştirir; geniş aday getirme, doğru belgenin kaçırılmamasını sağlar; reranking, gürültüyü eler; iyi bir prompt, modeli yalnızca bağlama dayanmaya zorlar; kaynak gösterme ise doğrulanabilirlik verir. Modelin ne kadar bağlam alabileceğini belirleyen sınır için context window nedir ve promptu iyi kurmanın yöntemleri için prompt engineering nedir yazıları yol gösterir.

Bir noktanın altını çizmek gerekir: bu adımların çoğu modelle ilgili değildir. RAG kalitesi genellikle en pahalı modeli seçmekten değil, getirme katmanını doğru kurmaktan gelir. Bu yüzden RAG projelerinde emeğin büyük kısmı üretme değil, getirme tarafına yatırılır.

RAG'in getirme aşaması, anahtar kelime aramasından daha derin bir şeye dayanır: anlamsal arama (semantik arama). Bunun temeli embedding'dir. Embedding, bir metni — bir kelimeyi, cümleyi veya paragrafı — anlamını temsil eden bir sayı dizisine (vektör) çeviren yöntemdir. Anlamca benzer metinler bu çok boyutlu vektör uzayında birbirine yakın konumlanır; alakasız metinler uzaklaşır. Böylece "anlam", ölçülebilir bir mesafeye dönüşür.

Bu vektörler bir vektör veritabanında saklanır. Kullanıcı soru sorduğunda, sorunun vektörü hesaplanır ve vektör veritabanı, ona anlamca en yakın belge parçalarını milisaniyeler içinde bulur. İşte bu yüzden "iade politikası" araması, belgede "para iadesi koşulları" yazsa bile doğru parçayı getirebilir — çünkü arama kelimelerin harflerine değil, anlamına dayanır. Embedding'in nasıl çalıştığını embedding nedir, vektör veritabanının rolünü vektör veritabanı nedir ve anlamsal aramanın mantığını semantik arama nedir yazılarında derinlemesine ele alıyoruz.

Embedding kalitesi doğrudan getirme kalitesini belirler. Yanlış veya zayıf bir embedding modeli seçmek, anlamı iyi yakalayamaz ve alakasız parçalar döndürür; Türkçe içerik için Türkçeyi iyi temsil eden bir modelin seçilmesi özellikle önemlidir, çünkü çok dilli bazı modeller Türkçe nüansları zayıf yakalar. Ayrıca embedding modelini değiştirdiğinizde tüm belgeleri yeniden vektörlemeniz gerekir; bu yüzden model seçimi baştan dikkatle yapılmalıdır.

Anahtar kelime araması ile anlamsal (embedding tabanlı) arama karşılaştırması

Boyut	Anahtar kelime araması	Anlamsal arama (embedding)
Eşleşme temeli	Kelimenin harf/kök eşleşmesi	Anlam yakınlığı (vektör mesafesi)
Eş anlamlı yakalama	Zayıf (iade≠para iadesi)	Güçlü (anlamca eşler)
Tam kod/isim eşleşmesi	Güçlü	Zayıf olabilir
Türkçe nüans	Kök bulmaya bağlı	Modelin dil kalitesine bağlı
En iyi kullanım	Kesin terim arama	Kavramsal, doğal dil soru

Bu karşılaştırmadaki son satır, ileride ele alacağımız hybrid search'ün neden değerli olduğunu da açıklar: iki yöntem birbirinin zayıf noktasını kapatır. Doğru embedding modeli ve iyi yapılandırılmış bir vektör veritabanı, RAG kalitesinin temelini oluşturur; ama tek başına yeterli değildir — arada bir de chunking meselesi vardır.

Chunking (parçalama), belgeleri embedding'lenip saklanacak parçalara bölme işidir ve RAG kalitesini sessizce belirleyen en kritik adımlardan biridir. Sezgiye aykırı biçimde, RAG başarısızlıklarının büyük kısmı modelden değil, kötü chunking'den kaynaklanır. Nedeni basittir: getirme, parça düzeyinde çalışır; parça yanlış kesilirse, doğru bilgi ya bulunamaz ya da alakasız gürültüyle birlikte gelir.

Chunking'te temel gerilim boyuttur. Çok büyük parçalar (örneğin bütün bir bölüm) fazla ve alakasız bağlam taşır; modelin dikkatini dağıtır ve maliyeti artırır. Çok küçük parçalar (örneğin tek cümle) ise anlamı koparır; "bu koşul yalnızca kurumsal müşteriler için geçerlidir" cümlesi, hangi koşuldan bahsedildiği başka bir parçada kaldıysa işe yaramaz. Doğru boyut, belgenin türüne ve sorulara göre ayarlanır; tek bir evrensel sayı yoktur.

Olgun bir chunking stratejisi birkaç ilkeye dayanır. Birincisi yapıya saygıdır: belgeyi rastgele karakter sayısıyla değil, doğal sınırlarından (başlık, paragraf, madde, bölüm) bölmek. İkincisi örtüşmedir (overlap): ardışık parçaların bir miktar ortak metin paylaşması, sınırda kalan bağlamın kaybolmasını önler. Üçüncüsü meta veri zenginleştirmesidir: her parçaya belge başlığı, bölüm adı, tarih ve kaynak gibi bilgileri eklemek, hem getirmeyi hem de kaynak göstermeyi güçlendirir. Bu konunun ayrıntısını chunking nedir yazısında ele alıyoruz.

Yaygın chunking yaklaşımları ve ne zaman uygun oldukları

Yaklaşım	Nasıl böler	Güçlü olduğu yer	Dikkat
Sabit boyut	Belirli karakter/token sayısı	Basit, hızlı kurulum	Anlamı ortadan kesebilir
Örtüşmeli sabit boyut	Sabit boyut + overlap	Sınır bağlamını korur	Biraz tekrar ve maliyet
Yapısal (başlık/paragraf)	Belgenin doğal sınırları	Anlam bütünlüğü yüksek	Düzensiz belgede zor
Anlamsal (semantic)	Konu değişimine göre	En tutarlı parçalar	Hesaplama maliyeti yüksek

Pratik öneri, sabit boyutlu ve örtüşmeli bir temelle başlamak, sonra belgelerin yapısına göre yapısal veya anlamsal chunking'e geçmektir. Chunking, bir kez kurulup unutulan değil, RAG kalitesi ölçüldükçe iyileştirilen yaşayan bir parametredir.

Getirme aşaması genellikle iki adımlı çalışır: önce hızlı ve geniş bir aday getirme, sonra dikkatli bir yeniden sıralama. İlk adım, vektör veritabanından soruya anlamca yakın onlarca aday parçayı hız için kabaca çeker. Ama "anlamca yakın" her zaman "gerçekten ilgili" demek değildir; adaylar arasında konuya teğet geçen, eski veya çelişkili parçalar da bulunabilir. İşte reranking bu noktada devreye girer.

Reranking (yeniden sıralama), aday parçaların her birini soruyla birlikte daha güçlü bir modelden geçirip gerçek alaka düzeyine göre puanlayan ve sıralayan ikinci bir değerlendirme adımıdır. İlk getirme "geniş ağ atar", reranking "en iyi balıkları seçer". Sonuç, modele verilen bağlamın çok daha temiz olması ve gürültünün büyük ölçüde elenmesidir. Bu adımın önemini ve türlerini reranker nedir yazısında ayrıntılandırıyoruz.

Reranking neden bu kadar fark yaratır? Çünkü dil modelleri, bağlamdaki alakasız bilgiden olumsuz etkilenir: bir parça ne kadar ilgisizse, modeli o kadar yanıltma potansiyeli taşır. Ayrıca modeller genellikle bağlamın başındaki ve sonundaki bilgiye ortasındakinden daha çok dikkat eder; bu yüzden en ilgili parçayı öne almak yalnızca gürültüyü elemekle kalmaz, modelin dikkatini de doğru yere yönlendirir. Çok sayıda benzer belgenin olduğu kurumsal bilgi tabanlarında reranking neredeyse zorunludur.

Üretim kalitesinde bir RAG sistemi, birbirine bağlı birkaç katmandan oluşur ve zincirdeki en zayıf halka tüm sistemin kalitesini belirler. Bu bileşenleri bir arada görmek, "rag nedir" sorusunu somut bir mühendislik resmine dönüştürür.

RAG mimarisinin temel bileşenleri, görevleri ve kötü kurgulanırsa etkisi

Bileşen	Görevi	Kötü kurgulanırsa
Veri alımı (ingestion)	Kaynaklardan metni çıkarır ve temizler	Bozuk/eksik metin tüm hattı zehirler
Chunking	Belgeleri anlamlı parçalara böler	Bağlam kopar, yanlış parça gelir
Embedding	Metni anlamsal vektöre çevirir	Alakasız sonuçlar döner
Vektör veritabanı	Vektörleri saklar ve hızlı arar	Gecikme ve ölçek sorunu
Reranking	En ilgili parçaları öne alır	Model gürültüyle beslenir
Üretme (generation)	Parçalara dayanarak yanıt yazar	Kaynak gösteremez, halüsinasyon artar
Değerlendirme (evaluation)	Kaliteyi sürekli ölçer	Bozulmalar fark edilmeden büyür

Bu tabloya iki bileşen daha eklenir ve çoğu zaman ihmal edildikleri için ayrıca vurgulanmayı hak ederler. Birincisi orkestrasyon katmanıdır: adımları birbirine bağlayan, soru yeniden yazma, geri dönüş (fallback) ve gerektiğinde araç çağırma gibi mantığı yöneten koddur. İkincisi güvenlik ve yönetişim katmanıdır: erişim kontrolü, prompt injection savunması ve çıktı denetimi. Güvenlik açıkları için prompt injection nedir ve koruyucu katmanlar için guardrail nedir yazıları önemlidir.

Dikkat çeken nokta şudur: bu bileşenlerin çoğu modelin kendisiyle ilgili değildir. RAG bir sistem mühendisliği problemidir; başarı, tek bir bileşeni değil, tüm boru hattını dengeli ve ölçülebilir kurmaktan gelir. Bu yüzden bir RAG projesini "model seçme" olarak değil, "bilgi boru hattı tasarlama" olarak düşünmek gerekir.

Kurumlar sık sık "modeli kendi verimizle eğitelim mi, yoksa RAG mi kuralım?" diye sorar. İkisi farklı problemleri çözer ve doğru cevap çoğu zaman "önce RAG, gerekiyorsa fine-tuning"dir. RAG bilgi ekler: modele dışarıdan güncel ve kuruma özel belgeler verir. Fine-tuning ise davranış değiştirir: modelin tonunu, formatını veya bir alandaki üslubunu kalıcı olarak ayarlar. Fine-tuning'in ne olduğunu fine-tuning nedir yazısında ele alıyoruz.

Pratik kural nettir: sorun "model doğru bilgiyi bilmiyor" ise RAG; sorun "model doğru bilgiyi biliyor ama yanlış biçimde/tonla söylüyor" ise fine-tuning. Çoğu kurumsal senaryoda önce RAG denenir, çünkü daha hızlı kurulur, daha ucuzdur ve bilgiyi güncel tutmak kolaydır — bir belge değişince yalnızca o parçayı yeniden vektörlersiniz, modeli yeniden eğitmezsiniz.

RAG ile fine-tuning ne zaman tercih edilir

Kriter	RAG	Fine-tuning
Çözdüğü problem	Bilgi eksikliği	Davranış/biçim ihtiyacı
Bilgi güncelleme	Anında (belge değiştir)	Yeniden eğitim gerekir
Kaynak gösterme	Doğal olarak yapar	Zordur
Kurulum maliyeti	Görece düşük	Görece yüksek
En iyi kullanım	Sık değişen kurumsal bilgi	Tutarlı üslup, dar alan uzmanlığı

İkisi rakip değil, tamamlayıcıdır. Gelişmiş kurumlar sıklıkla hibrit kurar: fine-tuning ile modele kurumun üslubunu ve belirli çıktı formatını öğretir, RAG ile de güncel bilgiyi besler. Böylece model hem "sizin gibi" konuşur hem de "güncel ve doğru" bilgiyle cevap verir. Açık kaynak bir modeli kendi altyapınızda çalıştırıp hem fine-tuning hem RAG uygulama seçeneğini açık kaynak LLM nedir yazısında değerlendiriyoruz.

RAG'in en yüksek getirili kurumsal uygulaması, kurumsal bilgi erişimidir: çalışanların ve müşterilerin, kurumun dağınık belgelerine doğal dilde soru sorarak kaynak gösterilmiş cevaplar alması. Bir destek uzmanı binlerce sayfalık dokümantasyonu okumak yerine soruyu sorar; RAG ilgili paragrafı bulup yanıtı ona dayandırır ve kaynağı gösterir. Bu, kurumsal bilgi erişiminin verimlilikte yarattığı en somut sıçramadır.

Bu genel yetenek çok sayıda senaryoya dönüşür. Aşağıdaki örnekler, kurumsal bilgi erişiminin farklı biçimlerini gösterir:

• İç bilgi asistanı: Çalışanlar İK politikaları, BT prosedürleri, satış materyalleri veya teknik dokümantasyon hakkında soru sorar; RAG kurum içi kaynaklardan kaynak göstererek yanıtlar. Yeni çalışan uyumunu (onboarding) hızlandırır.
• Müşteri destek asistanı: Destek ekibi veya doğrudan müşteri, ürün dokümantasyonu ve geçmiş çözümler üzerinden anında yanıt alır. İlk çözüm oranını artırır, çözüm süresini kısaltır.
• Sözleşme ve mevzuat analizi: Hukuk ve uyum ekipleri, büyük belge yığınları içinde belirli maddeleri veya yükümlülükleri arar; RAG ilgili pasajları getirip özetler.
• Satış ve teklif desteği: Satış ekipleri ürün bilgisi, fiyatlandırma kuralları ve rakip karşılaştırmalarına doğal dilde erişir.
• Araştırma ve içgörü: Ekipler iç raporlar, pazar analizleri ve geçmiş projeler arasında bağlantı kurar.

Bu senaryoların ortak paydası, "cevap kurumun bir yerinde var ama bulmak zor" durumudur. RAG, bilgi ile onu arayan kişi arasındaki mesafeyi kısaltır. Bu yeteneği bir sohbet arayüzüyle sunmak için üretken yapay zeka nedir ve doğal dil işlemenin temeli için doğal dil işleme nedir yazıları bağlam sağlar. Daha ileri senaryolarda RAG, bir AI agent nedir ve agentic AI nedir yazılarında ele aldığımız ajan mimarileriyle birleşerek yalnızca yanıtlamakla kalmaz, çok adımlı görevleri de yürütür.

RAG'in kurumsal bilgi erişimindeki gücü, Türkiye bağlamında KVKK (Kişisel Verilerin Korunması Kanunu) ile birlikte tasarlanmalıdır. Çünkü RAG, tanımı gereği kurumsal belgeleri bir sisteme alır, vektörler; ve bu belgeler kişisel veri içeriyorsa, tüm KVKK yükümlülükleri devreye girer. Aşağıdaki çerçeve tanımsal ve bilgilendirme amaçlıdır; hukuki tavsiye değildir ve kurumunuzun hukuk/uyum birimiyle birlikte uygulanmalıdır.

En kritik ilke erişim kontrolüdür. Bir RAG sisteminin en tehlikeli hatası, tüm belgeleri tek bir havuza koyup herkese açmaktır; bu, erişim yetkisi olmayan bir çalışanın, bir arama yaparak görmemesi gereken maaş bilgisine veya gizli sözleşmeye ulaşması demektir. Doğru kurulumda getirme katmanı, kullanıcının yetkisine göre filtrelenir: model, kullanıcının görmeye yetkili olmadığı bir belgeyi asla bağlam olarak almaz. Yani izin kontrolü, üretme adımında değil, getirme adımında yapılır.

Kişisel veri içeren belgeler için ek önlemler gerekir. Kişisel verinin ne olduğunu kişisel veri nedir yazısında ele alıyoruz. Uygulamada anonimleştirme veya maskeleme (belgedeki kimlik bilgilerinin gizlenmesi), amaçla sınırlılık (verinin yalnızca tanımlı amaç için kullanılması), saklama süresi ve silme politikaları ile denetim kaydı (kim, ne zaman, hangi belgeye erişti) planlanır. Anonimleştirmenin yöntemlerini veri anonimleştirme nedir yazısında bulabilirsiniz. KVKK'nın genel çerçevesi için KVKK nedir ve KVKK ile uyumlu bir mimari kurmak için KVKK uyumlu yapay zeka nedir rehberleri temel oluşturur.

Avrupa'ya ürün veya hizmet sunan Türk kurumları için ek bir katman EU AI Act'tir. Avrupa Yapay Zeka Yasası, yapay zeka sistemlerini risk seviyelerine göre sınıflandırır ve şeffaflık, insan gözetimi ve dokümantasyon gibi yükümlülükler getirir; RAG tabanlı bir kurumsal asistan da bu kapsama girebilir. Yasanın çerçevesini EU AI Act nedir yazısında ele alıyoruz. Uluslararası referans olarak ISO/IEC 42001 (yapay zeka yönetim sistemi standardı) ve NIST AI RMF (yapay zeka risk yönetimi çerçevesi), RAG sistemlerinin yönetişimi için de yol gösterici olabilir.

Rag nedir tartışmasının kalbinde halüsinasyon azaltma vardır; çünkü RAG'in en çok konuşulan faydası tam olarak budur. Ama RAG'in halüsinasyonu nasıl azalttığını — ve tamamen ortadan kaldırmadığını — doğru anlamak gerekir. RAG, modeli hafızasından cevap uydurmak yerine önündeki belgeye dayanmaya zorlar; "bilgiyi bul, sonra o bilgiye göre yaz" prensibi, uydurmanın önünü keser.

Ancak RAG halüsinasyonu sıfırlamaz; yalnızca kaynağını değiştirir ve azaltır. RAG'de halüsinasyon üç noktada hâlâ ortaya çıkabilir. Birincisi, yanlış belge getirilirse model doğru belgeye dayanamaz ve yanlış ama "kaynaklı" görünen bir cevap üretir. İkincisi, belgeler çelişkiliyse model hangisine güveneceğini bilemez. Üçüncüsü, doğru belge gelse bile model onu yanlış yorumlayabilir veya belgede olmayan bir şeyi "aradaki boşluğu doldurarak" ekleyebilir.

Bu yüzden gerçek halüsinasyon azaltma, yalnızca "RAG kurmak" değil, birkaç ek disiplin gerektirir. Modeli açıkça "yalnızca verilen bağlama dayan, bağlamda yoksa bilmediğini söyle" diye yönlendirmek (abstain davranışı); her iddiayı bir kaynağa bağlamayı zorunlu kılmak (kaynak gösterme); ve yanıtın gerçekten getirilen belgeye dayanıp dayanmadığını ölçmek (dayanaklılık / groundedness). Halüsinasyonun doğasını yapay zeka halüsinasyonu nedir yazısında ayrıntılı ele alıyoruz.

Rag nedir sorusundan hemen sonra gelen soru "RAG'im ne kadar iyi çalışıyor" olmalıdır; çünkü ölçülmeyen bir RAG sistemi yönetilemez. RAG değerlendirmesi (evaluation), tahmin yerine kanıta dayalı iyileştirmenin tek yoludur ve iki ayrı katmanda yapılır: getirme ve üretme.

Getirme katmanının değerlendirmesi, "doğru parça getirildi mi" sorusuna cevap verir. Burada isabet (soruya gerçekten cevap veren parça geldi mi), kapsama (gerekli tüm parçalar geldi mi) ve sıralama kalitesi (en ilgili parça en üstte mi) ölçülür. Bu ölçümler için genellikle etiketli bir soru-cevap kümesi hazırlanır: her soru için hangi belgenin "doğru" olduğu önceden işaretlenir, sonra sistemin o belgeyi getirip getirmediği ve kaçıncı sırada getirdiği hesaplanır.

Üretme katmanının değerlendirmesi ise "yanıt iyi mi" sorusuna cevap verir. Burada dört boyut öne çıkar: dayanaklılık (yanıt gerçekten getirilen belgeye mi dayanıyor, yoksa uyduruyor mu), doğruluk (yanıt olgusal olarak doğru mu), eksiksizlik (soruyu tam mı yanıtlıyor) ve kaynak gösterme (iddiaları belgeye bağlıyor mu). Bu boyutları ölçmek için otomatik metrikler, insan değerlendirmesi ve bir modelin başka bir modelin çıktısını puanladığı LLM-as-a-judge yaklaşımı birlikte kullanılır. Model değerlendirmesinin genel yöntemlerini LLM değerlendirme nedir yazısında ele alıyoruz.

RAG değerlendirmesinin iki katmanı ve örnek ölçütler

Katman	Ne sorar	Örnek ölçüt
Getirme	Doğru parça geldi mi?	İsabet, kapsama, sıralama kalitesi
Üretme - dayanaklılık	Yanıt belgeye mi dayanıyor?	Groundedness / kaynak tutarlılığı
Üretme - doğruluk	Yanıt olgusal doğru mu?	Doğruluk / hata oranı
Üretme - eksiksizlik	Soruyu tam yanıtlıyor mu?	Kapsam / eksiksizlik skoru
Deneyim	Kullanıcı işine yaradı mı?	Memnuniyet, çözüm oranı, gecikme

Değerlendirmeyi bir kez değil, sürekli yapmak gerekir. Belgeler değişir, kullanıcı soruları evrilir, model güncellenir; bu yüzden bir "değerlendirme kümesi" oluşturup her değişiklikte tekrar çalıştırmak (regresyon testi gibi), kalitenin sessizce bozulmasını önler. Üretim ortamında sistemin davranışını izlemek için gözlemlenebilirlik ve operasyon disiplini gerekir; bunları LLMOps nedir yazısında ele alıyoruz.

Klasik RAG çoğu senaryoda yeterlidir; ama bazı durumlarda yetersiz kalır ve ileri teknikler devreye girer. En yaygın iki tanesi hybrid search ve GraphRAG'dir; ikisi de klasik yaklaşımın belirli zayıflıklarını kapatır.

Hybrid search (hibrit arama), anlamsal aramayı klasik anahtar kelime aramasıyla (genellikle BM25 algoritması) birleştirir. Neden gerekli? Çünkü anlamsal arama kavramları iyi yakalar ama tam eşleşme gereken durumlarda — bir ürün kodu, bir yasal madde numarası, bir kişi adı, nadir bir teknik terim — zayıf kalabilir. Anahtar kelime araması ise tam eşleşmede güçlüdür ama eş anlamlıları kaçırır. İkisini birleştirmek, "hem anlamı hem tam eşleşmeyi" yakalar ve sonuçları birleştirir. Kurumsal bilgi tabanlarında, özellikle teknik ve terim yoğun içerikte, hybrid search çoğu zaman tek başına anlamsal aramadan üstündür.

GraphRAG ise farklı bir soruna yanıt verir: ilişkisel ve çok adımlı sorular. Klasik RAG, birbirinden bağımsız parçalar getirir; ama "X tedarikçisi ile Y projesi arasındaki bağlantı nedir" gibi bir soru, birden fazla belgedeki bilgiyi ilişkilendirmeyi gerektirir. GraphRAG, belgelerdeki varlıkları (kişi, kurum, ürün, kavram) ve aralarındaki ilişkileri bir bilgi grafiğine (knowledge graph) çıkarır; sonra getirmeyi bu graf üzerinden yaparak ilişkisel soruları yanıtlar. Bilgi grafiğinin ne olduğunu bilgi grafiği nedir ve GraphRAG'in ayrıntısını GraphRAG nedir yazısında ele alıyoruz.

Klasik RAG, hybrid search ve GraphRAG ne zaman kullanılır

Teknik	En güçlü olduğu soru tipi	Dikkat
Klasik RAG	Tek belgeden yanıtlanan kavramsal sorular	İlişkisel/tam eşleşmede zayıf
Hybrid search	Terim/kod + kavram karışık sorular	İki skorun birleştirilmesi ayarı gerektirir
GraphRAG	Çok belgeli, ilişkisel, çok adımlı sorular	Graf kurma maliyeti yüksek

Bu ileri teknikler değerlidir ama bir uyarıyla: karmaşıklık maliyeti vardır. Doğru yaklaşım, klasik RAG ile başlamak, kaliteyi ölçmek ve ancak belirli soru tipleri sistematik olarak başarısız olduğunda ilgili ileri tekniğe geçmektir. Karmaşıklığı baştan eklemek, çoğu zaman çözdüğünden fazla sorun yaratır.

Rag nedir sorusunu tam olarak kavramanın en iyi yolu, tek bir sorunun sistem içindeki yolculuğunu adım adım izlemektir. Varsayalım ki bir çalışan, kurum içi RAG asistanına şunu soruyor: "Yıllık izin hakkım bir sonraki yıla devrediyor mu?" Bu basit görünen soru, perde arkasında bir dizi işlemi tetikler ve her adım nihai yanıtın kalitesini belirler.

Önce soru işlenir. Sistem, soruyu olduğu gibi almaz; gerekiyorsa netleştirir ve bir embedding modeliyle anlamsal bir vektöre çevirir. Bu vektör, sorunun "anlamını" temsil eder — kelimeleri değil, kastedilen kavramı. Ardından bu vektör, vektör veritabanında bir aramayı tetikler: sistem, kurumun İK belgelerinden çıkarılmış binlerce parça arasından, bu soruya anlamca en yakın olanları bulur. Belgede "yıllık izin" yerine "senelik ücretli izin" veya "izin devri" yazsa bile, anlamsal arama doğru parçayı yakalayabilir; işte embedding ve vektör veritabanının gücü buradadır.

Getirilen aday parçalar — diyelim ki on parça — sonra bir reranker'dan geçer. Reranker, bu on parçayı soruyla gerçek alaka düzeyine göre yeniden sıralar; izin devriyle doğrudan ilgili olan iki parçayı en öne alır, teğet geçen sekizini geriye atar. Böylece modele verilecek bağlam gürültüden arınır. Şimdi sistem, seçilen iki parçayı, bir talimatla ("yalnızca bu belgelere dayan, kaynak göster, belgede yoksa bilmediğini söyle") ve orijinal soruyla birleştirerek son promptu oluşturur.

Son adımda model yanıtı yazar: "İK Yönetmeliği'ne göre kullanılmayan yıllık izin, bir sonraki yıla devredilir; ancak devredilen izin en geç takip eden yılın sonuna kadar kullanılmalıdır." Ve kritik biçimde, hangi belgeye dayandığını gösterir. Kullanıcı bu kaynağı tıklayıp doğrulayabilir. İşte bu uçtan uca yolculuk — soruyu anla, ilgili parçayı bul, temizle, dayandır, kaynak göster — RAG'in özüdür ve "rag nedir" sorusunun en somut cevabıdır. Dikkat edin: bu yolculukta modelin "zekâsı" tek başına belirleyici değildir; asıl belirleyici, ona doğru parçanın verilip verilmediğidir.

RAG mimarisinin en çok konuşulan bileşenleri embedding, reranking ve üretme modelidir; ama sessizce en belirleyici olan, sisteme giren verinin kalitesidir. "Çöp girerse çöp çıkar" ilkesi RAG için özellikle geçerlidir: en gelişmiş boru hattı bile, hatalı, eski veya çelişkili belgelerden doğru yanıt üretemez. Bu yüzden başarılı RAG projeleri, model seçmeden çok önce, veri hazırlığına yatırım yapar.

Veri kalitesinin ilk boyutu doğruluk ve güncelliktir. Bir bilgi tabanına eski bir prosedürün güncel sürümüyle birlikte konması, RAG'in çelişkili iki kaynaktan birini rastgele seçmesine ve yanlış yanıt vermesine yol açar. Bu yüzden hangi belgenin "yürürlükte" olduğunu işaretlemek, süresi geçmiş belgeleri ayıklamak ve düzenli güncelleme yapmak kritiktir. İkinci boyut çıkarım kalitesidir: PDF, tarama, tablo ve görsel içeren belgelerden metni doğru çıkarmak zordur; kötü çıkarım, bozuk metin üretir ve tüm hattı zehirler. Özellikle tablolar ve çok sütunlu düzenler, dikkatli işlenmezse anlamı bozar.

Üçüncü boyut meta veri ve yapıdır. Her belgeye kaynak, tarih, bölüm, sahiplik ve erişim düzeyi gibi meta verileri eklemek, hem getirmeyi hem erişim kontrolünü hem de kaynak göstermeyi güçlendirir. Meta verisi olmayan bir parça, "kim, ne zaman, hangi yetkiyle" sorularına cevap veremez. Dördüncü boyut tekilleştirme ve gürültü temizliğidir: aynı bilginin onlarca kopyası, alakasız şablon metinler (imza blokları, yasal uyarılar) ve boş sayfalar, getirmeyi kirletir ve maliyeti artırır.

Pratik bir gerçek şudur: RAG projelerinde harcanan emeğin büyük kısmı, göz alıcı model çalışmasına değil, sıkıcı ama belirleyici veri hazırlığına gider. Veriyi doğru hazırlayan bir ekip, ortalama bileşenlerle bile güvenilir bir sistem kurar; veriyi ihmal eden bir ekip, en pahalı bileşenlerle bile başarısız olur. Kurumsal bilgi erişiminin kalitesi, doğrudan bu veri disiplinine bağlıdır; bu yüzden RAG'i bir "model projesi" değil, bir "bilgi yönetimi projesi" olarak görmek daha doğrudur.

Gerçek kullanıcılar tek bir soru sorup gitmez; bir sohbet yürütür. "Yıllık iznim devrediyor mu?" sorusunu "Peki ya doğum izni?" takip eder. Bu ikinci soru tek başına anlamsızdır — "peki ya" neyin devkinden bahsediyor? İşte çok turlu (multi-turn) diyaloglarda RAG, tek seferlik getirmeden daha inceliklidir ve ek bir katman gerektirir: konuşma geçmişini dikkate alan soru yeniden yazma.

Bu katmanın görevi, kullanıcının bağlama gömülü sorusunu, kendi başına anlaşılır bir arama sorgusuna dönüştürmektir. "Peki ya doğum izni?" sorusu, konuşma geçmişiyle birleştirilerek "Doğum izni bir sonraki yıla devrediyor mu?" biçimine yeniden yazılır; ancak bu yeniden yazılmış, bağımsız soru embedding'lenip getirmeye gönderilir. Bu adım olmadan, RAG ikinci soruda alakasız parçalar getirir ve sohbet kopar. Soru yeniden yazma, çok turlu RAG'in en kritik ama en sık atlanan bileşenidir.

Çok turlu RAG'de ikinci bir zorluk bağlam yönetimidir. Konuşma uzadıkça, geçmişin tamamını modele taşımak hem maliyeti artırır hem de dikkati dağıtır. Bu yüzden akıllı sistemler, konuşma geçmişini özetler, yalnızca ilgili kısımları tutar ve her turda taze bir getirme yapar. Ayrıca kullanıcı konuyu değiştirdiğinde bunu fark edip yeni bir getirme başlatmak gerekir; aksi halde sistem, önceki konunun parçalarına takılıp kalır.

Bu sohbet yeteneği, RAG'i statik bir soru-cevap kutusundan, gerçek bir asistana dönüştürür. Kullanıcı doğal biçimde konuşur, takip soruları sorar, önceki yanıtlara atıfta bulunur; iyi tasarlanmış bir çok turlu RAG bunların hepsini akıcı biçimde yönetir. Bu deneyimi bir sohbet arayüzüyle sunmanın temeli için üretken yapay zeka nedir ve daha ileri, çok adımlı senaryolar için agentic AI nedir yazıları yol gösterir. Çok turlu tasarım, kurumsal bilgi erişimini gerçek dünyada kullanılabilir kılan ayrıntıdır.

RAG'in bir mimari desen olarak yaygınlaşması tesadüf değildir; birkaç teknolojik gelişmenin aynı anda olgunlaşmasıyla mümkün oldu. Embedding modellerinin anlamı çok daha iyi yakalar hale gelmesi, vektör veritabanlarının milyarlarca vektörü milisaniyelerde arayabilecek ölçeğe ulaşması ve dil modellerinin verilen bağlamı sadık biçimde kullanma yeteneğinin artması — bu üçü bir araya geldiğinde RAG, laboratuvar fikrinden üretim mimarisine dönüştü. Bugün "rag nedir" sorusu, birkaç yıl öncesine göre çok daha somut bir mühendislik pratiğine karşılık geliyor.

Sık sorulan bir soru şudur: dil modellerinin bağlam penceresi (context window) sürekli büyürken — artık yüz binlerce token'lık bağlamlar mümkünken — RAG hâlâ gerekli mi? Neden tüm belgeleri doğrudan modele vermeyelim? Bu, "uzun bağlam mı, RAG mi" tartışmasıdır ve cevap çoğu kurumsal senaryoda "ikisi birlikte, ama RAG olmadan olmaz"dır. Bağlam penceresinin ne olduğunu context window nedir yazısında ele alıyoruz.

Uzun bağlam güçlüdür ama RAG'in yerini tutmaz; çünkü üç temel sınırı vardır. Birincisi maliyet ve gecikme: her soruda yüz binlerce token'ı modele göndermek, hem pahalıdır hem yavaştır; oysa RAG yalnızca ilgili birkaç parçayı gönderir. İkincisi ölçek: bir kurumun bilgi tabanı milyonlarca sayfa olabilir; bu, en büyük bağlam penceresine bile sığmaz. Üçüncüsü dikkat seyrelmesi: bağlam büyüdükçe modelin içindeki ilgili bilgiyi bulma ve ona odaklanma yeteneği zayıflar — devasa bir bağlamda kritik cümle "kaybolabilir". RAG, modele yalnızca en ilgili parçayı vererek bu üç sorunu birden çözer.

Uzun bağlam (long context) ile RAG yaklaşımının karşılaştırması

Boyut	Her şeyi bağlama koymak	RAG (seçici getirme)
Maliyet	Her soruda yüksek token maliyeti	Yalnızca ilgili parça, düşük maliyet
Ölçek	Bağlam penceresiyle sınırlı	Milyonlarca belgeye ölçeklenir
Güncelleme	Bilgi her seferinde elle verilir	Belge değişince indeks güncellenir
Kaynak gösterme	Zor	Doğal olarak yapar
Dikkat kalitesi	Büyük bağlamda seyrelir	Odaklı, temiz bağlam

Doğru bakış, ikisini rakip değil tamamlayıcı görmektir: uzun bağlam, RAG'in getirdiği parçalara "nefes alacak yer" verir; RAG ise uzun bağlamı gerçekten ilgili bilgiyle doldurur. Kısacası uzun bağlam RAG'i gereksiz kılmaz; RAG'i daha güçlü kılar. Modeller ne kadar gelişirse gelişsin, "doğru bilgiyi bulup önüne koyma" ihtiyacı — yani RAG'in özü — ortadan kalkmaz.

Klasik RAG tek adımlıdır: bir soru gelir, bir getirme yapılır, bir yanıt üretilir. Ama gerçek kurumsal sorular çoğu zaman tek getirmeyle çözülmez; birden fazla arama, ara akıl yürütme ve bazen dış araç kullanımı gerektirir. İşte agentic RAG (ajan tabanlı RAG) tam olarak bunu yapar: getirmeyi tek seferlik bir adım olmaktan çıkarıp, bir yapay zeka ajanının yönettiği çok adımlı bir sürece dönüştürür. Ajan mimarilerinin temelini AI agent nedir ve agentic AI nedir yazılarında ele alıyoruz.

Agentic RAG'de model, bir soruyu aldığında pasif kalmaz; kararlar verir. "Bu soruyu yanıtlamak için hangi bilgiye ihtiyacım var? Önce şunu arayayım, sonucu görüp gerekirse ikinci bir arama yapayım. Bu belge yetersiz, farklı bir kaynağa bakayım. Şimdi elimdeki parçaları birleştirip yanıtı yazayım." Bu döngü — planla, ara, değerlendir, gerekirse tekrar ara — ajanın yanıtı kademeli olarak inşa etmesini sağlar. Böylece "X ürününün 2024 fiyatı ile 2025 fiyatı arasındaki fark nedir" gibi birden fazla getirme gerektiren sorular yanıtlanabilir.

Bu güç bir maliyetle gelir. Agentic RAG, klasik RAG'e göre daha çok token tüketir (çok adımlı akıl yürütme), daha yavaştır (birden fazla getirme turu) ve daha karmaşıktır (hata ayıklaması zor). Ayrıca ajan yanlış bir yola saparsa, hata zincirleme büyüyebilir. Bu yüzden agentic RAG, her senaryo için değil, tek getirmenin yetmediği karmaşık, çok adımlı sorular için uygundur. Pratik kural: klasik RAG ile başla, yalnızca sorular sistematik olarak çok adımlı akıl yürütme gerektirdiğinde agentic yaklaşıma geç.

Bir RAG sistemi laboratuvarda çalışması ile üretimde ölçekli, hızlı ve makul maliyetle çalışması iki farklı şeydir. Üretim kalitesinde RAG, üç boyut arasında bilinçli bir denge gerektirir: yanıt kalitesi, gecikme (kullanıcının beklediği süre) ve maliyet. Bu üçü birbiriyle çekişir; birini iyileştirmek çoğu zaman diğerini zorlar ve doğru tasarım, kurumun önceliğine göre bu dengeyi ayarlamaktır.

Gecikme tarafında en büyük kaldıraçlar getirme ve üretme adımlarıdır. Çok geniş aday getirme ve ağır bir reranking, kaliteyi artırır ama yanıtı yavaşlatır; çok büyük bir üretme modeli daha iyi yazar ama daha yavaştır. Pratik teknikler arasında önbellekleme (sık sorulan soruların yanıtlarını saklamak), akışlı yanıt (streaming ile kullanıcıya cevabı yazılırken göstermek) ve aday sayısını akıllıca sınırlamak yer alır. Kullanıcı deneyiminde algılanan hız, ham hızdan daha önemlidir; bir yanıtın akarak gelmesi, bekleme hissini büyük ölçüde azaltır.

Maliyet tarafında ana kalemler embedding hesaplaması (özellikle büyük belge kütlelerinde ilk indeksleme), vektör veritabanı barındırma ve üretme modelinin token maliyetidir. Maliyeti kontrol etmenin yolları arasında daha küçük ve verimli bir üretme modeliyle başlamak, bağlamı gereğinden fazla doldurmamak (her fazladan parça token maliyetidir), iyi prompt tasarımıyla token israfını azaltmak ve sık tekrarlanan sorguları önbelleğe almak vardır. Prompt tasarımının maliyete etkisi için prompt engineering nedir yazısı yol gösterir. Üretim ortamında bu metrikleri sürekli izlemek için operasyon disiplini gerekir; bunu LLMOps nedir yazısında ele alıyoruz.

Doğru yaklaşım, bu dengeyi bir kez kurup unutmak değil, ölçüp yönetmektir. Her sorgunun gecikmesini, token maliyetini ve kalite skorunu izleyen bir gösterge tablosu, "kaliteyi ne kadar artırırsam maliyet/gecikme ne olur" sorusuna somut cevap verir. Böylece kurum, kör bir optimizasyon yerine, önceliğine göre bilinçli bir denge seçer: bir müşteri destek asistanında hız kritikken, bir hukuki analiz aracında kalite her şeyin önündedir.

RAG'in genel prensipleri dilden bağımsızdır; ama Türkçe içerikle çalışırken bazı özel zorluklar öne çıkar ve bunları görmezden gelmek kaliteyi sessizce düşürür. Türkçe, eklemeli (sondan eklemeli) yapısı, zengin çekim sistemi ve kelime köklerinin çok sayıda türev üretmesi nedeniyle, hem embedding hem de arama açısından İngilizceden farklı davranır.

Birinci zorluk embedding kalitesidir. Çok dilli embedding modellerinin bir kısmı Türkçeyi zayıf temsil eder; anlamı yeterince iyi yakalayamaz ve alakasız parçalar döndürür. Bu yüzden Türkçe ağırlıklı bir bilgi tabanında, embedding modelini yalnızca genel popülerliğine göre değil, Türkçe performansına göre seçmek kritiktir. Aynı içerik için iki farklı embedding modelini bir değerlendirme kümesiyle karşılaştırmak, doğru seçimi kanıta dayandırır. Embedding'in temelini embedding nedir yazısında ele alıyoruz.

İkinci zorluk arama ve eşleşmedir. Türkçenin çekim zenginliği, aynı kavramın onlarca farklı yüzeysel biçimde geçmesine yol açar; "sözleşme", "sözleşmenin", "sözleşmeye", "sözleşmelerde" gibi. Anlamsal arama bunu büyük ölçüde tolere eder, ama tam eşleşme gereken terimlerde (kod, isim, madde numarası) hybrid search'ün klasik anahtar kelime bileşeni, Türkçe kök bulma (stemming) ile desteklenmelidir. Üçüncü zorluk chunking'te ortaya çıkar: Türkçe cümlelerin uzunluğu ve yapısı, parça sınırlarını dikkatli seçmeyi gerektirir. Dördüncüsü, üretme adımında modelin akıcı ve doğru Türkçe üretmesidir; bazı modeller İngilizcede güçlüyken Türkçede tonlama ve dilbilgisi hataları yapabilir.

Bu zorluklar aşılamaz değildir; yalnızca farkında olmayı ve Türkçeye özel bir değerlendirme yapmayı gerektirir. Türkçe bir RAG sistemi kurarken en sağlam yol, tüm kararları (embedding modeli, chunking, üretme modeli) Türkçe bir test kümesiyle doğrulamaktır. Doğal dil işlemenin Türkçedeki inceliklerini doğal dil işleme nedir yazısında bulabilirsiniz. Türkiye'nin yüksek yapay zeka benimsemesi düşünüldüğünde, Türkçeyi iyi yapan bir kurumsal bilgi erişimi çözümü, önemli bir rekabet avantajıdır.

RAG bir sistem mühendisliği problemi olduğu için, başarılı bir RAG projesi tek bir kişinin değil, birkaç farklı yetkinliğin bir araya gelmesini gerektirir. Kimin neyi sahiplendiğini baştan tanımlamak, projenin en sık atlanan ama en belirleyici adımlarından biridir; çünkü RAG'in kalitesi, katmanların her birinin doğru sahiplenilmesine bağlıdır.

Tipik bir RAG projesinde şu roller öne çıkar. Alan uzmanı (domain expert): Hangi belgelerin doğru, güncel ve güvenilir olduğunu bilir; değerlendirme kümesindeki "doğru cevabı" tanımlar. Onun katkısı olmadan sistem, yanlış veya eski bilgiyi güvenle sunabilir. Veri/ML mühendisi: Veri alımı, chunking, embedding ve vektör veritabanı katmanlarını kurar ve optimize eder. Yazılım mühendisi: Orkestrasyonu, arayüzü ve mevcut sistemlerle entegrasyonu geliştirir. Uyum/hukuk sorumlusu: Erişim kontrolü, KVKK yükümlülükleri ve kişisel veri koruma kararlarını verir. Ürün sahibi: Kullanım senaryosunu daraltır, başarı ölçütlerini tanımlar ve önceliklendirir.

Bu rollerin ötesinde, çoğu projede eksik kalan kritik bir sorumluluk vardır: değerlendirme sahipliği. RAG kalitesi zamanla bozulabildiği için, birinin sürekli olarak değerlendirme kümesini güncellemekten, kaliteyi ölçmekten ve sapmaları yakalamaktan sorumlu olması gerekir. Bu sorumluluk kimseye verilmezse, sistem sessizce kötüleşir ve kimse fark etmez. Ekiplerin bu yetkinlikleri kazanması için gereken eğitim çerçevesini kurumsal yapay zeka eğitimi nedir yazısında ele alıyoruz.

Küçük bir kurumda bu roller tek bir kişide birleşebilir; büyük bir kurumda ise ayrı ekipler olabilir. Önemli olan rol sayısı değil, her sorumluluğun bilinçli olarak birine verilmiş olmasıdır. "Herkesin işi, kimsenin işi değildir" tuzağı, RAG projelerinde özellikle değerlendirme ve veri güncelliği alanlarında sık görülür. Kurumsal bir RAG programını doğru rollerle kurmak için yapay zeka danışmanlığı ile başlayabilir, tüm kavramları öğrenme merkezinde derinleştirebilirsiniz.

Rag nedir sorusunu teoride anlamak kolaydır; zor olan, üretimde çalışan sağlam bir sistem kurmaktır. Deneyimli bir gözle bakıldığında, başarısız RAG projeleri benzer hatalarla bozulur. En yaygınları şunlardır:

• Getirme yerine modele odaklanmak: En sık hata, tüm dikkati "hangi model" sorusuna verip getirme katmanını (chunking, embedding, reranking) ihmal etmektir. Oysa RAG kalitesinin büyük kısmı getirmeden gelir.
• Kötü chunking: Belgeleri anlamı koparacak biçimde bölmek, doğru bilginin ya bulunamamasına ya da gürültüyle gelmesine yol açar. Chunking, RAG'in sessiz katilidir.
• Zayıf veya uyumsuz embedding: Türkçe içeriğe uygun olmayan bir embedding modeli, anlamsal aramayı bozar ve alakasız parçalar döndürür.
• Reranking'i atlamak: İlk getirmenin sonuçlarını olduğu gibi modele vermek, gürültüyü bağlama taşır ve yanıt kalitesini düşürür.
• Kaynak göstermemek: Yanıtın hangi belgeye dayandığını göstermemek, doğrulamayı imkânsız kılar, güveni düşürür ve halüsinasyonu görünmez yapar.
• Erişim kontrolünü ihmal etmek: Tüm belgeleri herkese açmak, KVKK ihlali ve gizli veri sızıntısı riski yaratır.
• Değerlendirme yapmamak: Kaliteyi ölçmeden "iyi çalışıyor" varsaymak, sistemin zamanla sessizce bozulmasına yol açar.
• Bağlamı aşırı doldurmak: "Ne kadar çok belge, o kadar iyi" yanılgısıyla modele çok fazla parça vermek, dikkatini dağıtır ve maliyeti artırır.

Bu hatalardan kaçınmanın en pratik yolu, küçük bir kapsamda başlayıp ölçerek büyümektir. Tüm kurumu tek seferde dönüştürmeye çalışmak yerine, dar bir kullanım senaryosuyla (örneğin tek bir departmanın dokümantasyonu) başlamak, riski düşürür ve öğrenmeyi hızlandırır.

"Hangi RAG aracını kullanmalıyım" sorusu, aslında yanlış soruyla başlar; çünkü RAG tek bir araç değil, bir dizi bileşenin birleşimidir. Doğru soru, her katman için doğru bileşeni seçmek ve bunları kurumunuzun ölçek, gecikme, maliyet ve uyum gereksinimlerine göre bir araya getirmektir. Araç adları hızla değiştiği için, burada ürün değil kategori düzeyinde düşünmek daha kalıcıdır.

Bir RAG yığını (stack) tipik olarak şu katmanlardan seçim yapmayı gerektirir: veri alımı ve belge işleme; embedding modeli; vektör veritabanı; getirme ve reranking; üretme modeli (LLM); orkestrasyon çatısı; ve değerlendirme/izleme araçları. Her katmanda hazır bir bulut hizmeti mi kullanacağınız yoksa kendi altyapınızda mı barındıracağınız kararı, hem maliyeti hem de KVKK/veri egemenliği açısından uyumu doğrudan etkiler. Modelleri araçlara ve verilere bağlayan protokolleri anlamak için MCP nedir ve function calling nedir yazıları yol gösterir.

Seçimde birkaç ilke işe yarar. Birincisi, başlangıçta basitlik: ilk pilotu en az bileşenle, hazır hizmetlerle kurup değeri kanıtlamak; karmaşıklığı ancak ihtiyaç doğrulandığında eklemek. İkincisi, değiştirilebilirlik: bileşenleri gevşek bağlı tutmak, böylece embedding modelini veya vektör veritabanını gerektiğinde değiştirebilmek. Üçüncüsü, ölçüm önceliği: hangi aracı seçerseniz seçin, değerlendirme altyapısını baştan kurmak. Ekiplerin bu kararları doğru vermesi için gereken yetkinliği kurumsal yapay zeka eğitimi nedir yazısında ele alıyoruz.

Rag nedir sorusu çevresinde en sık karışan üç kavram vardır: klasik chatbot, arama motoru ve RAG. Üçü de "soruya cevap veren" sistemler gibi görünür, ama çalışma biçimleri kökten farklıdır ve bu farkı anlamak, RAG'in neden özel olduğunu netleştirir.

Klasik bir chatbot, çoğunlukla önceden yazılmış kurallara veya sabit yanıt ağaçlarına dayanır: "şu sorulursa şu cevabı ver." Esnek değildir, doğal dili tam anlamaz ve bilgi tabanı büyüdükçe bakımı zorlaşır. Chatbot'ların evrimini chatbot nedir yazısında ele alıyoruz. RAG ise sabit kurallara değil, anlamsal aramaya ve dil modeline dayanır; kuralları elle yazmazsınız, belgeleri koyarsınız ve sistem doğal dildeki her soruya, o belgelere dayanarak yanıt üretir. RAG, bir chatbot'un yapabileceğinden çok daha geniş ve esnek bir soru kümesini karşılar.

Klasik bir arama motoruyla fark ise "ne döndürdüğü"ndedir. Bir arama motoru, sorunuza karşılık bir belge listesi (bağlantılar) döndürür; okuyup cevabı kendiniz bulursunuz. RAG ise bir adım öteye geçer: ilgili belgeleri bulur, okur ve size doğrudan bir cevap yazar — kaynağı da göstererek. Yani arama motoru "nerede bakacağını", RAG "cevabın ne olduğunu" söyler. Ayrıca klasik arama anahtar kelimeye, RAG ise anlama dayanır; bu yüzden RAG, kelimesi kelimesine eşleşme olmasa bile doğru bilgiyi bulabilir.

Bu ayrımlar RAG'in konumunu netleştirir: RAG, chatbot'un doğallığını, arama motorunun bilgi genişliğini ve bir uzmanın "sana doğrudan cevap verme" yeteneğini tek bir mimaride birleştirir. İşte bu birleşim, kurumsal bilgi erişimini bu kadar güçlü kılan şeydir. Ancak bu güç, doğru kurulmayı gerektirir; yanlış kurulmuş bir RAG, ne bir chatbot kadar öngörülebilir ne de bir arama motoru kadar şeffaf olur.

RAG'in ne olduğunu anlamak bir şeydir; ilk RAG projesine sağlam bir başlangıç yapmak başka bir şeydir. En sık hata, "tüm kurumun bilgisini tek bir asistanda toplayalım" gibi devasa bir hedefle başlamaktır; bu tür projeler kapsam genişliği altında ezilir ve değer üretmeden tükenir. Doğru yaklaşım tam tersidir: dar, ölçülebilir ve değerli tek bir senaryoyla başlamak.

İyi bir pilot senaryosu üç özelliği taşır. Birincisi darlık: tek bir departman, tek bir belge kümesi, tek bir soru tipi. Örneğin yalnızca İK politikaları üzerinde soru-cevap. İkincisi ölçülebilirlik: başarının rakamla tanımlanabilmesi — kaç soru doğru yanıtlandı, çözüm süresi ne kadar kısaldı. Üçüncüsü değer: pilotun, başarılı olursa gerçek bir acıyı dindirmesi; yoksa kimse ilgilenmez. Bu üç özelliği taşıyan bir pilot, hem riski düşük tutar hem de kuruma somut bir kanıt sunar.

Pilotu kurarken sıra önemlidir. Önce küçük ama temsili bir belge kümesi ve bir değerlendirme seti (gerçek kullanıcı sorularından oluşan etiketli bir liste) hazırlanır. Sonra en basit RAG hattı kurulur: temel chunking, iyi bir embedding, bir vektör veritabanı ve bir üretme modeli. Bu ilk hattın kalitesi ölçülür; en zayıf katman (genellikle chunking veya getirme) bulunur ve iyileştirilir. Ancak kalite kanıtlandıktan sonra kapsam genişletilir. Bu "ölç, iyileştir, sonra büyüt" döngüsü, RAG projelerini kâğıt üzerinde iyi görünen ama üretimde çöken projelerden ayırır.

Son olarak, pilotu baştan üretim gerçekliğiyle tasarlamak gerekir: erişim kontrolü, KVKK yükümlülükleri ve değerlendirme, "sonra ekleriz" denilecek şeyler değil, ilk günden düşünülecek unsurlardır. Küçük ama sağlam bir pilot, büyük ama belirsiz bir vaatten her zaman daha ikna edicidir ve bir sonraki projenin yolunu açar. Kurumunuza özel bir RAG pilot yol haritası tasarlamak için yapay zeka danışmanlığı ile başlayabilir, ekiplerinizin gerekli yetkinliği kazanması için kurumsal eğitim seçeneklerini inceleyebilirsiniz.

Aşağıdaki kontrol listesi, bir RAG projesini fikirden üretime sağlıklı yürütmek için pratik bir rehberdir. Rag nedir sorusunu bir sisteme dönüştürürken bu adımları sırayla işaretleyebiliyorsanız, sağlam bir temel kurmuşsunuz demektir.

Nasıl Yapılır

RAG uygulama kontrol listesi

Bir RAG sistemini dar bir pilottan güvenilir üretime taşımak için adım adım kontrol listesi.

1. 1

   Dar bir kullanım senaryosu seç

   Tüm kurum yerine tek, ölçülebilir bir senaryoyla (örneğin bir departmanın dokümantasyonu) başla.

2. 2

   Veriyi hazırla ve temizle

   Kaynak belgeleri topla, metni çıkar, tekrarları ve gürültüyü temizle, meta veriyi belirle.

3. 3

   Chunking stratejisini kur

   Belge yapısına uygun, örtüşmeli bir parçalama tasarla ve meta veriyle zenginleştir.

4. 4

   Embedding ve vektör veritabanını seç

   Türkçeyi iyi temsil eden bir embedding modeli ve ölçeğe uygun bir vektör veritabanı belirle.

5. 5

   Getirme ve reranking ekle

   Geniş aday getirme + reranking kur; gerektiğinde hybrid search değerlendir.

6. 6

   Erişim kontrolü ve uyumu tasarla

   Getirme katmanını kullanıcı yetkisine göre filtrele; KVKK yükümlülüklerini baştan ekle.

7. 7

   Değerlendirme kümesi oluştur

   Etiketli soru-cevaplarla getirme ve dayanaklılık ölçen bir değerlendirme çerçevesi kur.

8. 8

   Ölç, iyileştir, ölçekle

   Kaliteyi düzenli ölç, en zayıf katmanı iyileştir, ancak kanıtlandıkça kapsamı genişlet.

Bu listeyi bir pilot üzerinde uygulamak, büyük bir dönüşüm vaadinden çok daha değerlidir; çünkü küçük ama ölçülebilir bir başarı, büyük ama belirsiz bir plandan her zaman daha ikna edicidir. Kurumsal bir RAG sistemini uçtan uca tasarlamak ve doğru pilotu seçmek için yapay zeka danışmanlığı ile başlayabilir, ekiplerinizin yetkinliği için kurumsal eğitim seçeneklerini inceleyebilirsiniz.

Teknik olarak sağlam bir RAG kurmak yeterli değildir; o RAG'in kuruma gerçek bir değer üretip üretmediğini de gösterebilmek gerekir. Aksi halde proje, "havalı ama gereksiz" damgasını yer ve bütçe masasında düşer. RAG'in iş değeri, çoğunlukla üç kanaldan gelir ve her biri ayrı ölçülmelidir.

Birinci kanal zaman tasarrufudur: çalışanların bilgi ararken harcadığı süre, RAG ile dakikalardan saniyelere iner. Bir destek uzmanının bir cevabı bulmak için harcadığı ortalama süre, RAG öncesi ve sonrası ölçülerek somut bir tasarruf hesaplanabilir. İkinci kanal kalite ve tutarlılıktır: RAG, herkesin aynı doğru ve güncel bilgiye erişmesini sağlar; bu, yanlış bilgiden kaynaklanan hataları ve yeniden-işi azaltır. Üçüncü kanal ölçeklenebilirliktir: bir insan uzmanın kapasitesi sınırlıyken, RAG asistanı aynı anda binlerce soruyu yanıtlar; bu, ekibi büyütmeden hizmet kapasitesini artırır.

Bu değeri savunulabilir kılmak için bir taban çizgisi şarttır: RAG öncesinde bir soruya cevap bulmak ne kadar sürüyordu, hata oranı neydi, kaç talep insana düşüyordu? Bu rakamlar ölçülmeden, RAG sonrası iyileşme iddiası havada kalır. RAG projelerinde en sık yapılan finansal hata, faydayı ölçmeden varsaymaktır. Yapay zeka projelerinde getirinin nasıl hesaplanacağını ayrıntılı olarak yapay zeka ROI nasıl hesaplanır yazısında ele alıyoruz; RAG için de aynı disiplin geçerlidir.

Bir uyarı gerekir: RAG'in getirisi, yalnızca teknolojiden değil, benimsemeden gelir. En iyi RAG sistemi bile çalışanlar onu kullanmazsa değer üretmez. Bu yüzden değer hesabına, aracın benimsenmesini sağlayacak eğitim ve değişim yönetimi de dahil edilmelidir. Doğru kurulmuş, ölçülen ve benimsenen bir RAG sistemi, kurumsal bilgi erişiminde somut ve sürdürülebilir bir getiri üretir; ama bu getiri, tahminle değil, ölçümle kanıtlanmalıdır.

Getiriyi zaman içinde korumak da ayrı bir disiplindir. Bir RAG sisteminin değeri, ilk kurulumda dondurulmuş bir sayı değildir; bilgi tabanı güncel tutuldukça, değerlendirme kümesi genişledikçe ve kullanıcı geri bildirimleri sisteme geri beslendikçe artar ya da ihmal edildikçe azalır. Bu yüzden RAG'i bir defalık bir proje gibi değil, sürekli bakım ve iyileştirme gerektiren yaşayan bir ürün gibi ele almak gerekir. Değeri kanıtlayan kurumlar, RAG'i kurup unutan değil; ölçen, dinleyen ve düzenli olarak iyileştiren kurumlardır. Bu süreklilik anlayışı, RAG yatırımını bir maliyet kaleminden, zamanla büyüyen bir kurumsal varlığa dönüştürür.

RAG nedir ve ne işe yarar?

RAG (Retrieval-Augmented Generation), bir dil modelinin yanıt üretmeden önce dış bir bilgi kaynağından ilgili belgeleri getirip bağlamına eklediği mimaridir. İşe yararı, modelin eğitim verisinde olmayan güncel ve kuruma özel bilgiyi kaynak göstererek kullanmasını sağlamak, böylece kurumsal bilgi erişimini mümkün kılmak ve halüsinasyonu azaltmaktır. Kısacası RAG, genel bir modeli sizin kurumunuzun bilgisiyle konuşan bir uzmana dönüştürür.

RAG ile fine-tuning arasındaki fark nedir?

RAG modele dışarıdan bilgi ekler; fine-tuning ise modelin davranışını, tonunu veya formatını kalıcı olarak değiştirir. Güncel veya sık değişen, kuruma özel bilgi gerekiyorsa RAG; tutarlı bir üslup, belirli bir çıktı biçimi veya dar bir alanda derin uzmanlık gerekiyorsa fine-tuning uygundur. İkisi birlikte de kullanılabilir: fine-tuning ile biçimi, RAG ile güncel bilgiyi verirsiniz.

RAG halüsinasyonu tamamen önler mi?

Hayır, ama belirgin biçimde azaltır. Model cevabı uydurmak yerine getirilen belgelere dayandığında halüsinasyon azaltma sağlanır. Yine de yanlış belge getirilirse, belge çelişkiliyse veya model belgeyi yanlış yorumlarsa hata olabilir. Bu yüzden kaynak gösterme, dayanaklılık ölçümü ve gerektiğinde bilgi bulunamadığında yanıt vermeme (abstain) davranışı önemlidir.

Embedding ve vektör veritabanı RAG'de ne işe yarar?

Embedding, bir metni anlamını temsil eden bir sayı dizisine (vektör) çevirir; anlamca benzer metinler bu uzayda birbirine yakın konumlanır. Vektör veritabanı bu vektörleri saklar ve bir soru geldiğinde ona anlamca en yakın parçaları hızla bulur. Bu ikili, anahtar kelime yerine anlama dayalı aramayı (semantik arama) mümkün kılar ve RAG'in getirme kalitesinin temelini oluşturur.

Chunking (parçalama) neden RAG kalitesini bu kadar etkiler?

Chunking, belgelerin hangi büyüklükte ve nereden bölüneceğini belirler. Çok büyük parçalar alakasız bağlamı içeri taşır ve modeli gürültüyle boğar; çok küçük parçalar ise anlamı koparır ve kritik bağlamı dışarıda bırakır. İyi bir chunking stratejisi belgenin doğal yapısına (başlık, paragraf, bölüm) saygı gösterir, örtüşme (overlap) kullanır ve meta veriyle zenginleştirir. RAG başarısızlıklarının büyük kısmı kötü chunking'e dayanır.

Reranking nedir ve gerçekten gerekli mi?

Reranking, getirme aşamasında bulunan aday parçaları, soruyla gerçek alaka düzeyine göre yeniden sıralayan ikinci bir değerlendirme adımıdır. İlk getirme hız için geniş ve kabaca yapılır; reranking ise en ilgili birkaç parçayı öne alarak modele temiz bir bağlam verir. Çoğu kurumsal RAG sisteminde reranking, yanıt kalitesini belirgin biçimde artırır; özellikle çok sayıda benzer belgenin olduğu bilgi tabanlarında neredeyse zorunludur.

RAG'i KVKK'ya uygun kurmak için nelere dikkat edilmeli?

Öncelikle hangi belgelerin RAG'e gireceği ve her kullanıcının hangi parçalara erişebileceği (erişim kontrolü) baştan tanımlanmalıdır. Kişisel veri içeren belgeler için anonimleştirme/maskeleme, amaçla sınırlılık, saklama süresi ve denetim kaydı planlanır. Getirme katmanı kullanıcının yetkisine göre filtrelenmeli; yani model, kullanıcının görmeye yetkili olmadığı bir belgeyi asla bağlam olarak almamalıdır. Bu, hukuki tavsiye değildir; kurumunuzun hukuk ve uyum birimiyle birlikte tasarlanmalıdır.

RAG kalitesi nasıl ölçülür?

RAG değerlendirmesi iki katmanda yapılır. Getirme katmanında isabet (ilgili parça getirildi mi), kapsama ve sıralama kalitesi ölçülür. Üretme katmanında dayanaklılık (yanıt gerçekten getirilen belgeye mi dayanıyor), doğruluk, eksiksizlik ve kaynak gösterme değerlendirilir. Pratikte etiketli bir soru-cevap kümesi, otomatik metrikler ve bir modelin başka bir modelin çıktısını puanladığı LLM-as-a-judge yaklaşımı birlikte kullanılır.

GraphRAG ve hybrid search klasik RAG'den ne farkla ayrılır?

Klasik RAG, belge parçalarını yalnızca anlamsal benzerlikle getirir. Hybrid search, anlamsal aramayı klasik anahtar kelime (BM25) aramasıyla birleştirerek hem anlamı hem tam eşleşmeyi yakalar; özellikle ürün kodu, terim ve isim gibi kesin eşleşme gereken sorgularda üstündür. GraphRAG ise belgeler arasındaki ilişkileri bir bilgi grafiği olarak modelleyip çok adımlı, ilişkisel soruları (X ile Y arasındaki bağlantı nedir) yanıtlamayı kolaylaştırır. İkisi de klasik RAG'in yetersiz kaldığı senaryolar için ileri tekniklerdir.

Özetle rag nedir sorusunun cevabı şudur: bir dil modelini yanıt üretmeden önce dış bir bilgi kaynağından getirilen ilgili belgelerle besleyen ve böylece yanıtı gerçek belgelere dayandıran yapay zeka mimarisidir. Getirme aşaması embedding ve vektör veritabanı ile anlamsal arama yapar; kalite büyük ölçüde chunking ve reranking ile belirlenir; üretme aşaması ise getirilen parçalara dayanarak kaynak gösteren bir yanıt yazar. RAG'in en yüksek kurumsal değeri, güncel ve kuruma özel bilgiye kaynak göstererek erişim (kurumsal bilgi erişimi) ve halüsinasyon azaltmadır.

En önemli mesaj şudur: RAG bir ürün değil, bir mimaridir; başarısı tek bir modelden değil, getirme katmanının kalitesinden gelir. İyi chunking, doğru embedding, etkili reranking, sağlam erişim kontrolü ve sürekli değerlendirme — bunlar bir araya geldiğinde, ortalama bir model bile güvenilir kurumsal yanıtlar üretir. Temel kavramlar için yapay zeka nedir, LLM nedir ve embedding nedir rehberlerine göz atabilir; kurumunuza özel bir RAG sistemi tasarımı ve yol haritası için yapay zeka danışmanlığı ile başlayabilir, ekiplerinizin yetkinliği için kurumsal eğitim seçeneklerini inceleyebilir ve tüm kavramları öğrenme merkezinde derinleştirebilirsiniz.

RAG'i kurumsal ortamda uçtan uca kurmayı uygulamalı öğrenmek isteyen ekipler için üretim sınıfı RAG eğitimi müfredatı; embedding modellerinden hibrit aramaya, re-ranking'den evaluation'a bu mimarinin bütün katmanlarını işler.