RAG ile Kurumsal Asistan Kurmak: Şirket Bilgini Konuşturan Mimari

Büyük dil modellerinin (LLM) gücünü ilk kez gördüğünde herkesin aklına aynı soru geliyor: "Bunu şirketimizin kendi verileriyle kullanabilir miyiz?" Cevap evet — ama doğru mimariyle. Burada devreye RAG (Retrieval-Augmented Generation / Geri Getirmeli Üretim) giriyor.

RAG Nedir, Neden Önemlidir?

Klasik bir LLM eğitim sırasında gördüğü verileri "hafızaya" alır. Şirketinizin iç dokümanlarını, ürün kılavuzlarını ya da geçen haftaki toplantı notlarını elbette bilmez. Fine-tuning (ince ayar) bu boşluğu kapatabilir, ancak hem pahalıdır hem de model her güncellendiğinde yeniden eğitim gerektirir.

RAG ise farklı çalışır:

1. Kullanıcı bir soru sorar. 2. Sistem, vektör veritabanında ilgili belge parçalarını arar ve getirir (retrieve). 3. Bu parçalar, soruyla birlikte LLM'e bağlam olarak verilir. 4. Model, yalnızca bu bağlamı kullanarak cevap üretir (generate).

Sonuç: Modelin "bilgisini" güncellemenize gerek kalmadan bilgi tabanınızı her an güncel tutabilirsiniz.

Kurumsal Asistan İçin Temel Bileşenler

Sıfırdan bir RAG sistemi kurarken şu parçalara ihtiyacınız var:

• Belge deposu: PDF, Word, Confluence sayfaları, Notion, dahili wiki — ne varsa.
• Chunk & Embed aşaması: Belgeler küçük parçalara bölünür (chunk), ardından bir embedding modeli (örn. text-embedding-3-small) ile vektöre dönüştürülür.
• Vektör veritabanı: Pgvector, Weaviate, Qdrant veya Pinecone gibi çözümler vektörleri depolar ve hızlı benzerlik araması yapar.
• LLM katmanı: GPT-4o, Claude 3, Mistral ya da açık kaynak alternatifleri.
• Orkestrasyon: LangChain, LlamaIndex veya sıfırdan yazılmış bir pipeline.

Adım Adım Kurulum Akışı

1. Veri Hazırlığı

Ham belgelerinizi temizleyin. Taranmış PDF'lerdeki OCR hatalarını, gereksiz header/footer bloklarını ayıklayın. Veri kalitesi, model kalitesinden çok daha belirleyicidir.

2. Parçalama Stratejisi

Chunk boyutu kritik. Çok küçük parçalar bağlamı kaybettirir; çok büyük parçalar ise LLM'in dikkatini dağıtır. 512–1024 token aralığı genellikle iyi bir başlangıç noktasıdır. Üst üste binen (overlapping) chunk'lar sınır kayıplarını azaltır.

3. Retrieval Kalitesini Artırmak

Saf vektör araması her zaman yeterli değildir. Hibrit arama (vektör + BM25 gibi anahtar kelime araması) ve ardından uygulanan re-ranking modelleri, ilgili belgeleri çok daha isabetli getirir.

4. Prompt Mühendisliği

LLM'e verdiğiniz sistem prompt'u asistanın kişiliğini ve sınırlarını belirler. "Yalnızca aşağıdaki bağlamdaki bilgilere dayanarak cevap ver, bilmiyorsan bunu açıkça söyle" gibi yönergeler hallüsinasyonu önemli ölçüde azaltır.

5. Değerlendirme (Eval)

RAG sistemleri için RAGAS gibi çerçeveler; faithfulness (sadakat), answer relevancy (cevap ilgisi) ve context recall (bağlam geri çağırma) gibi metrikleri otomatik ölçer. Eval olmadan iyileştirme körü körüne yapılır.

Dikkat Edilmesi Gereken Tuzaklar

• Erişim kontrolü: Tüm belgeler herkese açık olmamalı. Kullanıcının yetkisine göre hangi chunk'ların getirileceğini filtreleyin.
• Veri bayatlaması: Belge güncellendiğinde embedding'lerin de güncellenmesi gerekir. Bunu otomatikleştirin.
• Latency: Her sorgu bir embedding + bir vektör araması + bir LLM çağrısı demek. Önbellekleme ve async mimarisi hayat kurtarır.

Sonuç

RAG, kurumsal bilgiyi LLM ile buluşturmanın şu an için en pratik ve sürdürülebilir yolu. Fine-tuning'in aksine verilerinizi gerçek zamanlı güncel tutabilir, erişim kontrolünü koruyabilir ve neden o cevabın verildiğini izleyebilirsiniz. Doğru kurulduğunda, şirketinizin dağınık bilgisini sorgulayan bir asistan değil; gerçekten anlayan bir iş arkadaşına dönüşür.

Bir sonraki yazıda bu mimariyi production'a taşırken karşılaştığım gerçek sorunlardan bahsedeceğim.