RAG Nasıl Çalışır?

Büyük dil modelleri genel dil ve dünya bilgisine sahiptir; fakat kurumunuzun güncel prosedürlerini, özel sözleşmelerini veya dün yayımlanan raporunu kendiliğinden bilmez.

Retrieval-Augmented Generation (RAG), kullanıcı sorusuyla ilgili kurumsal içeriği önce bulup ardından bu içeriği modele bağlam olarak vererek kaynaklara dayanan yanıt üretme yaklaşımıdır.

Kısa akış:

Belgeler
  → ayrıştırma ve temizleme
  → anlamlı parçalara bölme
  → embedding üretme
  → vektör indeksine kaydetme

Kullanıcı sorusu
  → yetki filtresi
  → ilgili parçaları bulma
  → sıralama ve bağlam oluşturma
  → model yanıtı
  → kaynak gösterme

---

Neden bütün belgeyi modele vermiyoruz?

Küçük bir dosyada bütün metni göndermek mümkün olabilir. Kurumsal ölçekte ise binlerce belge, tekrarlanan sürümler ve farklı erişim yetkileri vardır.

Bütün içeriği her soruda modele göndermek:

• Gereksiz maliyet ve gecikme oluşturur.
• İlgisiz metin içinde doğru bilginin kaybolmasına neden olabilir.
• Erişim sınırlarını yönetmeyi zorlaştırır.
• Modelin bağlam penceresini gereksiz doldurur.
• Hangi kaynağın yanıta dayanak olduğunu belirsizleştirir.

Uzun bağlamlı modeller de her bilgiyi eşit başarıyla kullanmayabilir. Bu nedenle iyi retrieval, yalnızca bağlam penceresi küçük olduğu için değil, modele daha odaklı kanıt sunmak için gerekir.

---

İki ayrı hat: indeksleme ve sorgulama

RAG sistemi iki farklı zamanda çalışan iki hattan oluşur.

1. İndeksleme hattı

Belge yüklendiğinde bir kez veya belge değiştiğinde yeniden çalışır:

Belge kabulü
  → format ayrıştırma
  → metin temizleme
  → metadata ekleme
  → chunking
  → embedding
  → indeksleme

2. Sorgulama hattı

Her kullanıcı sorusunda çalışır:

Soru
  → kullanıcı ve erişim kapsamı
  → sorgu hazırlama
  → retrieval
  → filtreleme / yeniden sıralama
  → bağlam paketi
  → yanıt üretimi
  → kaynaklar

Bu ayrım hata ayıklarken önemlidir. Kötü bir yanıtın nedeni model olmayabilir; belge yanlış ayrıştırılmış, doğru chunk indekslenmemiş veya retrieval onu bulamamış olabilir.

---

İndeksleme hattı

1. Belge kabulü

Dosya yüklenirken en az şu bilgiler kaydedilmelidir:

• Belge kimliği ve adı
• Kaynak sistem veya klasör
• Belge sahibi
• Sürüm ve güncelleme zamanı
• Departman ve erişim kapsamı
• Belge türü, dili ve durumu
• Geçerlilik veya arşiv bilgisi

Metadata, arama kalitesi kadar güvenlik için de gereklidir. “En yakın metni bul” sorgusu, kullanıcının o metni görmeye yetkili olup olmadığını tek başına bilemez.

2. Ayrıştırma

PDF, Word, sunum veya tablo dosyası önce makinenin işleyebileceği metin ve yapıya dönüştürülür.

Kalite sorunları:

• Taranmış PDF'de OCR hataları
• İki sütunlu sayfalarda karışan okuma sırası
• Üstbilgi ve altbilginin her sayfada tekrarlanması
• Tabloların satır/sütun ilişkisini kaybetmesi
• Başlık hiyerarşisinin silinmesi
• Görsel içindeki bilginin çıkarılamaması

Retrieval, indekslenen içerikten daha iyi olamaz. Belge önizlemesi doğru görünse bile çıkarılan metni ayrıca kontrol edin.

3. Temizleme ve normalizasyon

Amaç içeriği değiştirmek değil, aramayı bozan gürültüyü azaltmaktır:

• Tekrarlanan sayfa başlıklarını kaldırma
• Gereksiz boşluk ve karakterleri düzeltme
• Başlık ve liste yapısını koruma
• Tablo bağlamını kaybetmeden metne dönüştürme
• Dil ve tarih formatlarını tutarlı hale getirme

Belgenin özgün kaynağı saklanmalı; normalize edilmiş metin kaynak belgenin yerine geçmemelidir.

---

Chunking: belgeyi anlamlı parçalara bölmek

Embedding ve retrieval genellikle bütün belge yerine daha küçük metin parçalarıyla çalışır. Bu parçalara chunk denir.

Çok büyük chunk

• Birden fazla konu aynı parçada karışır.
• Benzerlik skoru daha az ayırt edici olur.
• Modele gereksiz metin taşınır.

Çok küçük chunk

• Tanım, istisna veya koşul bağlamından kopar.
• Tablo başlığı ile satır ayrılabilir.
• Yanıt için gereken ilişki birden fazla parçaya dağılır.

Sabit uzunluk tek çözüm değildir

İyi chunking belge yapısını dikkate alır:

• Başlık ve alt başlık sınırları
• Paragraf ve liste bütünlüğü
• Tablo ve açıklamasının birlikteliği
• Sözleşme madde numaraları
• Prosedür adımları
• Soru-cevap çiftleri

Komşu parçalar arasında küçük bir örtüşme, sınırda kalan bilgiyi koruyabilir; fakat fazla örtüşme aynı içeriğin defalarca dönmesine yol açar.

Chunk ile birlikte tutulması gereken metadata

document_id
document_title
version
department_id
access_scope
section_title
page_number
language
effective_date
source_url

Bu alanlar filtreleme, kaynak gösterme ve belge yaşam döngüsü için kullanılır.

---

Embedding nedir?

Embedding modeli, metnin anlamını çok boyutlu sayısal bir vektörle temsil eder. Anlam bakımından yakın metinlerin vektörleri de genellikle birbirine yakın olur.

Örneğin:

• “İş sözleşmesi hangi durumda feshedilebilir?”
• “Çalışan sözleşmesinin sona erme şartları”

kelime olarak aynı değildir; fakat semantik olarak yakın olabilir.

Her chunk için embedding üretilir ve metadata ile birlikte vektör veritabanına kaydedilir. Kullanıcı sorusu da aynı uyumlu embedding modeliyle vektöre dönüştürülür.

Embedding seçiminde bakılacaklar

• Türkçe ve kullanılan diğer dillerde kalite
• Alan terimleri ve uzun metin performansı
• Çalışabileceği altyapı ve gecikme
• Vektör boyutu ve depolama maliyeti
• Lisans ve veri işleme koşulları
• Sorgu ve belge embedding uyumluluğu

---

Retrieval: doğru parçaları bulmak

Soru geldiğinde sistem yalnızca “en yakın vektörleri” seçmekle kalmamalıdır.

1. Yetki filtresi

Arama öncesinde veya aramayla birlikte:

• Organizasyon
• Departman
• Space
• Kullanıcı rolü
• Belge/klasör yetkisi
• Belge durumu ve geçerlilik

filtreleri uygulanır.

2. Semantik arama

Soru embedding'i ile izinli chunk vektörleri arasındaki yakınlık hesaplanır ve adaylar seçilir.

3. Anahtar kelime arama

Ürün kodu, sözleşme madde numarası, hata kodu veya özel isimlerde birebir terim eşleşmesi semantik aramadan daha etkili olabilir.

4. Hibrit arama

Semantik ve anahtar kelime sonuçlarını birleştirmek birçok kurumsal veri setinde daha dengeli sonuç verebilir. Bu bir seçenek olarak değerlendirilir; her kullanım senaryosunda otomatik olarak en iyi yöntem değildir.

5. Yeniden sıralama

İlk arama geniş bir aday listesi çıkarabilir. Reranker, soru ile her aday arasındaki ilgiyi daha ayrıntılı değerlendirerek en güçlü kanıtları üste taşır.

6. Çeşitlilik ve tekrar temizleme

Aynı paragrafın farklı sürüm veya örtüşen chunk'ları bağlamı doldurmamalıdır. Sistem:

• Tekrarlanan parçaları azaltabilir.
• Aynı belgeden aşırı sonuç gelmesini sınırlayabilir.
• Gerektiğinde farklı kaynaklardan kanıt seçebilir.

---

Bağlam paketi nasıl hazırlanır?

Seçilen chunk'lar doğrudan rastgele sırayla modele gönderilmemelidir.

Bağlam paketinde:

• En ilgili kanıtlar öne alınır.
• Kaynak adı, bölüm ve sayfa bilgisi korunur.
• Birbirini tamamlayan parçalar birlikte sunulur.
• Çelişen sürümler açıkça ayrılır.
• Token bütçesini aşan düşük değerli metin çıkarılır.

İyi bağlam “mümkün olan en fazla metin” değil, soruyu cevaplamak için gereken en küçük ve yeterli kanıt setidir.

---

Yanıt üretimi ve kaynak gösterme

Model, kullanıcı sorusu ve getirilen bağlam üzerinden yanıt üretir. Sistem talimatı genellikle şunları istemelidir:

• Yalnızca sağlanan kaynaklara dayan.
• Kaynakta olmayan bilgiyi gerçekmiş gibi tamamlama.
• Yeterli kanıt yoksa bunu açıkça söyle.
• Çelişen belgeleri ve sürümleri belirt.
• İddiaları ilgili kaynaklarla ilişkilendir.

Kaynak göstermek doğruluk garantisi değildir

Bir yanıtın yanında kaynak görünmesi şu riskleri tek başına çözmez:

• Kaynak soruyla ilgisiz olabilir.
• Model kaynağı yanlış yorumlayabilir.
• Atıf doğru belgeye ama yanlış bölüme gidebilir.
• Güncel olmayan sürüm kullanılmış olabilir.
• Kaynağın yalnızca bir bölümü iddiayı destekleyebilir.

Bu yüzden kullanıcı, atfın açıldığı yerde gerçekten ilgili kanıtı görebilmelidir.

---

RAG, fine-tuning ve uzun bağlam farkı

Bu yaklaşımlar rakip olmak zorunda değildir. Fine-tuned bir model RAG kullanabilir; RAG da uzun bağlam penceresinden yararlanabilir.

---

Erişim kontrolü ve veri yaşam döngüsü

RAG güvenliği yalnızca vektör veritabanını korumak değildir.

Yükleme sırasında

• Belge sahibini ve sınıfını kaydedin.
• Erişim metadata'sını chunk'lara taşıyın.
• Taslak ve geçersiz belgeleri ayırın.
• Kişisel veri ve saklama politikasını uygulayın.

Sorgu sırasında

• Kullanıcı kimliği ve space kapsamıyla filtreleyin.
• Yetkisiz sonuçları model bağlamına sokmayın.
• Harici modele giden veride Gateway politikasını uygulayın.

Güncelleme ve silme sırasında

• Yeni sürüm geldiğinde eski chunk'ları geçersiz kılın.
• Silinen belgeyi indeks ve cache'lerden kaldırın.
• Embedding modeli değişirse yeniden indeksleyin.
• Silme ve güncelleme olaylarını audit kaydına alın.

---

Kaliteyi nasıl ölçeriz?

RAG tek bir doğruluk puanıyla değerlendirilmemelidir. Retrieval ve generation ayrı ölçülmelidir.

Retrieval metrikleri

• Hit Rate / Recall@k: Doğru kanıt ilk k sonuç içinde mi?
• Precision@k: Dönen parçaların ne kadarı gerçekten ilgili?
• MRR: İlk doğru kanıt sıralamada ne kadar yukarıda?
• Metadata doğruluğu: Doğru sürüm ve erişim kapsamı seçildi mi?

Yanıt metrikleri

• Faithfulness: Yanıt iddiaları getirilen bağlam tarafından destekleniyor mu?
• Answer relevance: Yanıt kullanıcı sorusunu gerçekten karşılıyor mu?
• Citation accuracy: Atıf doğru iddiayı ve bölümü destekliyor mu?
• Completeness: Sorunun gerekli bütün parçaları cevaplandı mı?
• Abstention: Kanıt yokken sistem cevap vermemeyi biliyor mu?

İş metriği

Teknik metriklerin yanında:

• Belge bulma süresi
• Uzman inceleme süresi
• Yanlış yönlendirme oranı
• Kullanıcının kaynağı açma ve doğrulama davranışı
• İnsan düzeltmesi gereken yanıt oranı

izlenmelidir.

---

Altın test seti

Her önemli bilgi tabanı için küçük ama kaliteli bir değerlendirme seti hazırlayın:

Şu tür sorular mutlaka bulunmalıdır:

• Doğrudan cevabı olan sorular
• Birden fazla belge gerektiren sorular
• Benzer fakat yanlış belgeyi çekebilecek sorular
• Cevabı bilgi tabanında olmayan sorular
• Yetki dışındaki belgeden cevaplanabilecek sorular
• Güncel ve eski sürümün çeliştiği sorular

---

Sık karşılaşılan sorunlar

“Belge yüklü ama bulunmuyor”

Kontrol edin:

1. Ayrıştırılan metinde ilgili bölüm var mı?
2. Chunk sınırı bilgiyi bölmüş mü?
3. Metadata filtresi belgeyi dışlıyor mu?
4. Soru ve belge aynı embedding modeliyle işlenmiş mi?
5. top-k ve benzerlik eşiği fazla dar mı?

“İlgisiz kaynaklar geliyor”

• Chunk fazla büyük olabilir.
• Tekrarlanan üstbilgi embedding'i etkiliyor olabilir.
• Sorgu çok genel olabilir.
• Anahtar kelime veya metadata filtresi gerekebilir.
• Reranking kullanılabilir.

“Doğru kaynak geliyor ama cevap yanlış”

Bu durumda retrieval başarılı, generation başarısızdır:

• Model talimatını kontrol edin.
• Bağlam sırasını ve gürültüyü azaltın.
• Çelişen kaynakları ayırın.
• Yanıtın kaynakta olmayan çıkarım yapmasını sınırlayın.
• Daha uygun model veya çıktı şeması test edin.

“Eski belge cevapta kullanılıyor”

• Sürüm ve geçerlilik metadata'sı eksik olabilir.
• Eski chunk'lar indeks içinde aktif kalmış olabilir.
• Cache temizlenmemiş olabilir.
• “Yalnızca güncel” filtresi uygulanmıyor olabilir.

“Kullanıcı görmemesi gereken kaynağı buluyor”

Bu kritik bir güvenlik problemidir:

• Sorguyu durdurun ve bağlantıyı inceleyin.
• Erişim filtresinin retrieval öncesinde uygulandığını doğrulayın.
• Chunk metadata mirasını kontrol edin.
• Cache ve loglarda veri yayılımını araştırın.
• Olayı audit ve müdahale sürecine alın.

---

Yayına alma kontrol listesi

• Belge metni ve okuma sırası örnek dosyalarda doğrulandı.
• Belge türüne uygun chunking stratejisi seçildi.
• Chunk'larda kaynak, sürüm ve erişim metadata'sı var.
• Sorgu ve belgeler uyumlu embedding modeli kullanıyor.
• Yetki filtresi model bağlamından önce uygulanıyor.
• Eski ve taslak belgeler aramadan ayrılıyor.
• Kaynak bağlantısı doğru sayfa veya bölümü açıyor.
• Cevabı olmayan sorularda sistem bilgi uydurmuyor.
• Retrieval ve yanıt kalitesi ayrı ölçülüyor.
• Yetki dışı ve eski sürüm testleri yapıldı.
• Belge silme/güncelleme indeks ve cache'e yansıyor.
• Harici modele giden bağlam Gateway politikasından geçiyor.
• Kalite ve güvenlik için teknik/iş sahipleri belirlendi.

---

Sonraki adımlar

1. Bilgi tabanı oluşturun: Belge Yükleme ve Bilgi Tabanı
2. Bilgiyi doğru departman ve space kapsamına yerleştirin: Organizasyon → Departman → Space
3. RAG kullanan agent'ı yapılandırın: Model / Ajan Oluşturma
4. Harici modele gönderilen hassas bağlamı koruyun: LLM Secure Gateway

Araştırma kaynakları

• Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks
• RAGAS: Automated Evaluation of Retrieval Augmented Generation
• Lost in the Middle: How Language Models Use Long Contexts