RAG Nedir? Kendi Dokümanların Üzerine Soru-Cevap Yapay Zekası Nasıl Kurulur

Muhasebe departmanının bir sözleşme maddesini bulmak için üç yüz PDF'yi tek tek açtığı bir şirket düşünün. Ya da müşteri destek ekibinin aynı soruyu haftada onlarca kez yanıtladığı, her seferinde eski bir Word dokümanını arayarak cevap bulduğu bir SaaS şirketi. Bu şirketlerin çoğu artık aynı soruyu soruyor: 'ChatGPT gibi bir şey ama kendi dokümanlarımızın üzerinde çalışsa olmaz mı?' Cevap RAG (Retrieval-Augmented Generation) — ve bu yazıda RAG nedir, nasıl çalışır ve kendi dokümanların üzerine güvenilir bir soru-cevap sistemi kurmanın gerçekte ne gerektirdiğini anlatıyorum.

##RAG Nedir? Basitçe Açıklıyorum

RAG, bir dil modelinin (LLM) yanıt üretirken sadece eğitildiği genel bilgiye değil, sizin sağladığınız özel bir bilgi kümesine de başvurmasını sağlayan bir mimari. Süreç iki adımdan oluşuyor: önce ilgili sorguya en uygun doküman parçaları bir arama motorundan (genellikle bir vektör veritabanı) çekiliyor — buna 'retrieval' deniyor. Sonra bu parçalar, kullanıcının sorusuyla birlikte modele bağlam olarak veriliyor ve model yanıtı bu bağlama dayanarak üretiyor — buna 'generation' deniyor. Model hiçbir zaman sizin dokümanlarınız üzerinde yeniden eğitilmiyor; her sorguda ilgili parçalar anlık olarak modele 'okutuluyor'.

##RAG, Sade Bir ChatGPT Sorgusundan Neden Farklı?

Bir LLM'e doğrudan soru sorduğunuzda model yalnızca eğitim verisindeki genel bilgiye dayanıyor — şirketinizin iç sözleşmelerini, ürün dokümantasyonunuzu ya da geçen yılki destek biletlerinizi bilmiyor. Bu dokümanları promptun içine yapıştırmaya çalışabilirsiniz ama bağlam penceresi sınırlı ve maliyetli; binlerce sayfalık bir doküman kümesini her soruda modele göndermek pratik değil. RAG bu sorunu çözüyor: modele her şeyi göndermek yerine, sadece o soruyla alakalı birkaç parçayı gönderiyor. Bu hem maliyeti düşürüyor hem de yanıtın kaynağını gösterebilmenizi sağlıyor — 'bu cevap şu sözleşmenin 4. maddesinden geliyor' diyebiliyorsunuz. Halüsinasyon riski de azalıyor çünkü model uydurmak yerine gerçek bir metne dayanıyor; ancak sıfıra inmiyor, bu konuya aşağıda döneceğim.

Bir diğer fark da güncelleme hızında ortaya çıkıyor. Bir modeli yeniden eğitmek günler, hatta haftalar sürebilirken, RAG'de yeni bir doküman eklendiğinde tek yapılması gereken onu parçalayıp vektör veritabanına kaydetmek — birkaç dakika içinde o doküman soru-cevap sisteminin bir parçası haline geliyor. Fiyat listeleri, politika belgeleri ya da devam eden proje dosyaları gibi sürekli değişen içerikler için bu fark, pratikte 'kullanılabilir sistem' ile 'sürekli bakım gerektiren sistem' arasındaki ayrımı belirliyor.

##Gerçek Bir Senaryo: Bir Danışmanlık Şirketinde İç Bilgi Asistanı

Yirmi kişilik bir hukuk ve danışmanlık ofisi olan Vektör Danışmanlık'ı ele alalım (temsili bir örnek). Ofiste on yılı aşkın süredir biriken beş bin civarında sözleşme, iç yönerge ve eski proje raporu var. Yeni bir danışman bir soru sorduğunda — 'bu tip bir tedarik sözleşmesinde gizlilik maddesini nasıl yazmıştık?' — cevabı ya kıdemli bir ortağa sormak ya da eski dosyalarda saatlerce aramak zorunda kalıyordu. Kurulan sistemde önce mevcut dokümanlar (PDF, Word, e-posta arşivi) bir işlem hattından geçiriliyor: her doküman anlamlı parçalara (chunk) bölünüyor, her parça bir embedding modeliyle sayısal vektöre çevriliyor ve bir vektör veritabanına (örneğin pgvector ya da Pinecone) kaydediliyor. Danışman iç sohbet arayüzüne sorusunu yazdığında sistem önce soruyu da bir vektöre çeviriyor, veritabanında en yakın anlamsal eşleşmeleri buluyor, bulunan parçaları soruyla birlikte LLM'e gönderiyor ve LLM bu parçalara dayanarak bir yanıt üretiyor — yanıtın altında hangi dokümandan ve hangi sayfadan geldiği de gösteriliyor. Danışman artık saatlerce arşiv taramak yerine yanıtı otomatik alıyor, kaynağı görüyor ve gerekirse orijinal dokümana tek tıkla ulaşıyor.

##RAG Sistemi Nasıl Kurulur: Adım Adım

• ▸Doküman kaynaklarını belirleyin: PDF'ler, Word dosyaları, wiki sayfaları, destek biletleri — hangi veri kümesinin soru-cevap için değerli olduğuna karar verin.
• ▸Dokümanları anlamlı parçalara (chunk) bölün. Parça boyutu çok küçükse bağlam kaybolur, çok büyükse ilgisiz bilgi karışır; genelde 300-800 kelime aralığında başlanır.
• ▸Her parçayı bir embedding modeliyle vektöre çevirin ve bir vektör veritabanına (pgvector, Pinecone, Weaviate gibi) kaydedin.
• ▸Bir retrieval katmanı kurun: kullanıcı sorusu geldiğinde en alakalı parçaları getiren arama mantığı.
• ▸LLM'e gönderilecek prompt şablonunu tasarlayın: sistem talimatı + getirilen parçalar + kullanıcı sorusu.
• ▸Yanıtla birlikte kaynak gösterimini (hangi doküman, hangi bölüm) ekleyin — bu hem güven hem de doğrulama için kritik.
• ▸Yeni doküman eklendiğinde ya da güncellendiğinde vektör veritabanının otomatik güncellenmesini sağlayan bir senkronizasyon mekanizması kurun.

##Maliyet ve Sınırlamalar: RAG Her Şeyi Çözmüyor

RAG güçlü ama sihirli değil. Chunking stratejisi yanlış kurulursa model ilgisiz parçaları bağlam olarak alır ve yanıt kalitesi düşer — bu genelde ilk kurulumda en çok zaman harcanan optimizasyon adımı. Yapılandırılmış veriler (örneğin kesin sayısal raporlar, güncel stok miktarları) için RAG doğru araç değil; bu tür sorular için doğrudan bir veritabanı sorgusu ya da SQL tabanlı bir araç çok daha güvenilir. Ayrıca RAG halüsinasyonu tamamen ortadan kaldırmıyor — model bulduğu parçaları yanlış yorumlayabilir ya da parçalar arasında var olmayan bir bağlantı kurabilir. Bu yüzden özellikle hukuki ya da finansal kullanım senaryolarında yanıtın yanına kaynağı göstermek ve kritik kararlarda insan onayını sürecin dışında bırakmamak gerekiyor.

Bir diğer pratik sınırlama, doküman kalitesinin doğrudan yanıt kalitesine yansıması. Eski, çelişkili ya da güncelliğini yitirmiş dokümanlar sisteme dahil edilirse model bunları da geçerli bir kaynak gibi kullanır — bu yüzden kurulumdan önce hangi dokümanların hâlâ doğru ve güncel olduğunu gözden geçirmek, teknik kurulumun kendisi kadar önemli bir adım. Küçük ölçekli bir pilotta bu genelde birkaç saatlik bir doküman ayıklama çalışmasıyla çözülüyor; büyük ve dağınık arşivlerde ise ayrı bir 'veri temizliği' aşaması gerekebiliyor.

##Sık Sorulan Sorular

>RAG ile fine-tuning arasındaki fark nedir?

Fine-tuning, modelin kendisini sizin verinizle yeniden eğitmek anlamına geliyor — pahalı, zaman alıcı ve veri güncellendiğinde tekrar yapılması gerekiyor. RAG'de model hiç değişmiyor; her sorguda ilgili bilgi anlık olarak bağlam olarak veriliyor. Dokümanlarınız sık güncelleniyorsa (fiyat listesi, politika belgeleri, güncel projeler) RAG neredeyse her zaman daha pratik ve daha ucuz bir yaklaşım.

>Hangi vektör veritabanını seçmeliyim?

Zaten bir PostgreSQL veritabanı kullanıyorsanız pgvector eklentisi genelde en düşük sürtünmeli başlangıç noktası — ayrı bir servis yönetmenize gerek kalmıyor. Daha büyük ölçekte, milyonlarca dokümanla çalışan ürünler için Pinecone ya da Weaviate gibi yönetilen servisler daha uygun olabilir. Küçük ve orta ölçekli bir şirket için genellikle pgvector yeterli ve başlamak için doğru seçim.

>RAG sistemi kurmanın maliyeti ve süresi ne kadar?

Tek bir doküman kümesi ve basit bir sohbet arayüzü içeren bir pilot 2-3 haftada hazır olabilir. Kaynak gösterimi, kullanıcı yetkilendirmesi (kimin hangi dokümana erişebileceği) ve çoklu doküman tipi desteği içeren üretim kalitesinde bir sistem genelde 6-10 hafta sürüyor. Aylık işletme maliyeti kullanım hacmine göre değişiyor ama küçük-orta ölçekli bir şirket için genelde vektör veritabanı ve LLM API çağrıları toplamda aylık birkaç yüz ila birkaç bin dolar arasında kalıyor.

>RAG yanlış ya da uydurma cevap verme riskini tamamen ortadan kaldırıyor mu?

Hayır, azaltıyor ama sıfırlamıyor. Model bulduğu doğru parçaları bile bazen yanlış yorumlayabilir. Bu riski azaltmanın en etkili yolu her yanıtın yanında kaynağı (doküman adı, sayfa/bölüm) göstermek ve kullanıcının orijinal metne tek tıkla ulaşabilmesini sağlamak — böylece yanıt körü körüne değil, doğrulanabilir şekilde kullanılıyor.

Şirketinizin kendi dokümanları üzerine bir soru-cevap sistemi kurmayı düşünüyorsanız, en iyi başlangıç noktası hangi doküman kümesinin en çok zaman kaybettirdiğini ve kimin bu sisteme erişmesi gerektiğini netleştirmek. Birkaç soruyla kapsamı çıkarabiliriz — iletişim sayfasından ulaşabilirsiniz.