RAG | Bilgi Erişimi, Graph RAG ve Büyük Veri

RAG'ı bilgi erişimi, hibrit arama, yeniden sıralama, büyük veri, özel veriyle sohbet, Graph RAG, zamansal ilişki analizi, güvenlik, değerlendirme ve yerel üretim mimarisi üzerinden uygulamaya dönük ele alan kapsamlı ders notu.

Bilgi Erişimi Destekli Üretim (Retrieval-Augmented Generation, RAG), büyük dil modelinin yanıt üretirken yalnız kendi parametrelerinde bulunan örüntülere dayanması yerine, çalışma zamanında dış bilgi kaynaklarından ilgili kanıtı bulup bağlama eklemesine dayanan bir sistem mimarisidir. RAG'ın asıl değeri bir sohbet ekranı üretmek değildir. Eski bir web sitesini, belge arşivini, veri tabanını, konuşma dökümlerini, olay kayıtlarını veya ilişki grafiğini yeniden eğitilmiş tek bir modele dönüştürmeden yapay zekâ ile kullanılabilir hâle getirmesidir.

Bu ders Yapay Zeka: Felsefe, Kuram ve Uygulama, Doğal Dil İşleme ve Büyük Dil Modelleri derslerinin doğal devamıdır.

Yapay Zeka
   |
   v
Doğal Dil İşleme
   |
   v
Büyük Dil Modelleri
   |
   v
Bilgi Erişimi Destekli Üretim

Yapay zekâ dersi daha geniş problem alanını, NLP dili ve metni, LLM dersi üretici modeli ele alır. Bu ders ise model ile dış bilgi sistemleri arasındaki mühendislik katmanına odaklanır.

RAG için en önemli düşünce şudur:

iyi yanıt
   =
uygun model
 + doğru kanıt
 + doğru yetki
 + doğru bağlam
 + doğrulanmış çıktı

Model güçlü olsa bile yanlış belge getirilirse yanıt yanlış temele oturur. Retrieval doğru olsa bile bağlam gereksiz parçalarla doldurulursa model önemli kanıtı kaçırabilir. Doğru bilgi getirilse bile kullanıcı o bilgiyi görmeye yetkili değilse sistem güvenlik açısından başarısızdır.

Ünite 1: Parametrik Bilgi ve Dış Bilgi

Bir büyük dil modeli geniş veri üzerinde eğitildiğinde örüntülerin bir bölümü model ağırlıklarına dağılmış biçimde yerleşir. Buna parametrik bilgi denebilir. Bu bilgi doğrudan satır, belge veya kaynak gösteren bir veri tabanı değildir.

RAG çalışma zamanında ayrı bir bilgi kaynağı kullanır.

                 +-------------------+
                 | Model ağırlıkları |
                 | parametrik bilgi  |
                 +---------+---------+
                           |
Sorgu -------------------->| LLM
                           ^
                           |
                 +---------+---------+
                 | getirilen kanıt   |
                 | dış bilgi         |
                 +-------------------+

Bu ayrım özellikle güncellik ve kaynak kökeni açısından önemlidir. Bir belgenin bugün değişmesi, model ağırlıklarının otomatik değiştiği anlamına gelmez. RAG'ta ise belge yeniden indekslenerek güncel bilgi çalışma zamanında modele sunulabilir.

RAG'ın tarihsel önemi, parametrik ve parametrik olmayan belleği üretim sürecinde birleştirmesidir. Bununla birlikte günümüzde RAG terimi çok daha geniş bir sistem ailesini ifade eder: sözcüksel arama, yoğun vektör arama, yeniden sıralama, SQL, grafik sorguları, zaman filtreleri ve araç çağrıları aynı retrieval katmanında birlikte kullanılabilir.

Ünite 2: RAG Ne Değildir?

RAG ile benzer görünen yöntemler farklı sorunları çözer.

İnce ayar

İnce ayar model davranışını veya temsilini ağırlıkları değiştirerek uyarlamaya yöneliktir. Bilginin sık değiştiği bir alanda her yeni belge için modeli yeniden eğitmek genellikle doğru mimari değildir.

veri değişti
   |
   +--> ince ayar:
   |      eğitim
   |      yeni ağırlık
   |      değerlendirme
   |      yeniden dağıtım
   |
   +--> RAG:
          belgeyi işle
          indeksi güncelle
          yeni sorguda kullan

Uzun bağlam

Modelin çok uzun bağlam kabul etmesi retrieval ihtiyacını tamamen ortadan kaldırmaz. Büyük arşivin tamamını her sorguda modele vermek:

gereksiz token maliyeti,
yüksek gecikme,
yetki yönetimi zorluğu,
önemli bilginin bağlam içinde kaybolması,
güncellik ve kaynak kökeni sorunları

oluşturabilir.

Uzun bağlam ile RAG birbirinin rakibi değil, tamamlayıcısıdır. Retrieval önce ilgili alanı daraltabilir; uzun bağlam ise seçilen belgelerin daha geniş bölümünü birlikte değerlendirmeyi sağlayabilir.

Araç kullanımı

RAG bilgi getirir. Araç kullanımı dış dünyada işlem yapabilir.

RAG:
"Bu kayıtlar ne söylüyor?"

Araç:
"Bu sorguyu çalıştır."
"Bu dosyayı aç."
"Bu raporu üret."

Bir sistem ikisini birlikte kullanabilir.

Ünite 3: Akıllı Olmayan Bir Siteyi Akıllı Hâle Getirmek

Klasik bir web sitesi yıllarca içerik üretmiş olabilir. Makaleler, ders notları, projeler, wiki girdileri ve dokümanlar kullanıcıya sayfa ve menü üzerinden sunulur. Bu yapı yapay zekâ kullanmıyor diye değersiz değildir; aksine düzenli içerik yapısı RAG için güçlü bir bilgi kaynağıdır.

İlk aşama mevcut siteyi değiştirmek değil, içeriği ayrı bir bilgi hattına bağlamaktır.

Mevcut Site
   |
   +--> HTML / Markdown
   +--> veri tabanı içerikleri
   +--> wiki
   +--> belgeler
   |
   v
İçerik Çıkarma
   |
   v
Temizleme + Metadata
   |
   v
Parçalama
   |
   +--> sözcüksel indeks
   |
   +--> vektör indeks
   |
   v
RAG API
   |
   v
Mevcut siteye sohbet / anlamsal arama yüzeyi

Bu yaklaşım eski sitenin veri modelini bozmaz. Yapay zekâ katmanı mevcut sistemin üzerine eklenen ayrı bir okuma ve anlamlandırma katmanıdır.

Aramadan yanıta geçiş

Klasik arama:

kullanıcı -> "gerçek zamanlı sistem"
          -> eşleşen sayfalar

RAG:

kullanıcı
  |
  v
"Gerçek zamanlı sistemlerde gecikme ve throughput
arasında hangi ödünleşimler anlatılmış?"
  |
  v
ilgili sayfa + bölüm + paragraf retrieval
  |
  v
kaynaklı sentez

İkinci sistem yine aramaya dayanır; fark, bulunan kanıtların üretici model tarafından soruya göre birleştirilmesidir.

Site için önerilen ilk sürüm

İlk sürümde ajan, Graph RAG veya karmaşık çok adımlı zincir gerekmez.

Sorgu
  |
  v
BM25 + Dense Search
  |
  v
Reciprocal Rank Fusion
  |
  v
Cross-Encoder Reranker
  |
  v
Top 5-10 kanıt
  |
  v
LLM
  |
  v
Kaynaklı yanıt

Basit ve ölçülebilir bir sistem, çok sayıda üretici modülü üst üste eklemekten daha sağlıklı başlangıçtır.

Ünite 4: Bilgi Alım Hattı

RAG kalitesi sorgu anında başlamaz. Asıl hazırlık veri alım hattında yapılır.

Kaynak
  |
  v
Çıkarma
  |
  v
Normalizasyon
  |
  v
Metadata
  |
  v
Parçalama
  |
  v
Embedding / sözcüksel indeks
  |
  v
Sürümleme
  |
  v
Yayınlanmış indeks

Kaynak türleri

RAG yalnız PDF için değildir. Kaynaklar:

HTML,
Markdown,
düz metin,
PDF,
DOCX,
veri tabanı kayıtları,
konuşma dökümleri,
e-posta benzeri ileti metinleri,
kod ve teknik belge,
olay açıklamaları,
grafik düğüm ve kenar açıklamaları

olabilir.

Her kaynağın aynı biçimde parçalanması gerekmez.

Kanonik belge

Aynı içeriğin PDF, HTML ve veri tabanı biçimi bulunabilir. Hepsini ayrı gerçekmiş gibi indekslemek yinelenen retrieval sonuçları üretir. Bu nedenle bir kanonik belge kimliği tutulmalıdır.

canonical_document_id
source_type
source_uri
language
version
created_at
modified_at
access_scope
content_hash

İndeks girdisi kaynak belgenin yerine geçmemelidir. Kaynağa geri dönüş yolu korunmalıdır.

Ünite 5: Parçalama Stratejisi

RAG sisteminin en kritik kararlarından biri chunking, yani belgenin arama birimlerine ayrılmasıdır.

Sabit karakter uzunluğu kolaydır; fakat anlamsal sınırları bozabilir.

Yanlış sınır:
"... veri tabanı transaction sınırı burada..."
                       | CUT
"... başlar ve commit davranışı ..."

Böyle bir kesim retrieval sonucunun anlamını zayıflatır.

Yapısal parçalama

Markdown ve ders notlarında:

Ders
 |
 +--> Ünite
       |
       +--> Başlık
             |
             +--> Alt başlık
                   |
                   +--> Paragraf

yapısı zaten doğal hiyerarşidir.

Arama küçük parçalarda yapılabilir. LLM'ye ise gerektiğinde üst bağlam gönderilebilir.

arama granülerliği
        !=
bağlam granülerliği

Bu parent-child retrieval yaklaşımı uzun teknik belgelerde güçlüdür.

İçerik türüne göre parçalama

Bir SQL sorgusu, Java metodu, tablo açıklaması ve doğal dil paragrafı aynı splitter ile işlenmemelidir.

Örneğin kod parçasında fonksiyon veya sınıf sınırı; konuşma dökümünde konuşmacı dönüşü veya zaman segmenti; olay akışında zaman penceresi; ders notunda başlık yapısı daha anlamlı sınır olabilir.

Overlap

Chunk overlap komşu parçalar arasında bağlam kaybını azaltabilir. Fakat çok yüksek overlap:

indeks boyutunu büyütür,
aynı kanıtın tekrar tekrar gelmesine yol açar,
reranker havuzunu kirletir,
LLM bağlamını yinelenen metinle doldurur.

Overlap ölçülerek seçilmelidir.

Ünite 6: Embedding ve Vektör Arama

Embedding modeli metni yüksek boyutlu yoğun bir vektöre dönüştürür. Semantik olarak yakın metinlerin vektörlerinin yakın olması hedeflenir.

"veri tabanı bağlantı havuzu"
          |
          v
      embedding
          |
          v
[0.12, -0.31, ..., 0.07]

Sorgu da aynı uzaya taşınır ve yakın komşular aranır.

Benzerlik doğruluk değildir

Cosine similarity veya inner product, iki metnin anlamsal yakınlığını tahmin eder. Bu değer:

doğruluk,
nedensellik,
aynı kişi,
aynı olay,
güvenilirlik

anlamına gelmez.

Bu ayrım özellikle kişi ve ilişki analizinde zorunludur.

ANN

Milyonlarca vektörde bütün vektörlerle tam karşılaştırma pahalı olabilir. Approximate Nearest Neighbor indeksleri arama maliyetini düşürür. HNSW ve FAISS ailesindeki indeksler bu amaçla kullanılabilir.

ANN yaklaşık sonuç döndürür; bu nedenle performans kararı:

latency
  vs
recall
  vs
memory

ödünleşimidir.

Ünite 7: Sözcüksel, Yoğun ve Hibrit Retrieval

Sadece dense retrieval kullanmak özellikle kurumsal ve Türkçe veride yeterli değildir.

Sözcüksel arama

BM25 gibi yöntemler şu durumlarda güçlüdür:

özel ad,
telefon/kimlik benzeri tam değer,
teknik kod,
kısaltma,
nadir terim,
bire bir ifade.

Yoğun arama

Dense retrieval şu durumlarda avantajlıdır:

eş anlam,
farklı ifade biçimleri,
paraphrase,
kavramsal benzerlik.

Hibrit arama

                  +--> BM25 ---------+
Sorgu ------------|                  |
                  +--> Dense --------+--> Fusion --> Adaylar
                                     |
Metadata filtre ---------------------+

Birleştirme için skorları doğrudan toplamak zor olabilir; iki sistemin skor dağılımları farklıdır. Reciprocal Rank Fusion gibi sıra tabanlı yöntemler sağlam bir başlangıç sağlayabilir.

Türkçe için neden hibrit?

Türkçenin eklemeli yapısı dense model için anlamsal genelleme gerektirirken; özel ad, kod ve ekli sözcük varyantları lexical katmanı değerli kılar.

2026 tarihli RAGTurk çalışması Türkçe RAG hattında sorgu dönüşümü, reranking ve yanıt iyileştirme aşamalarını karşılaştırmış; karmaşık üretici bileşenlerin üst üste eklenmesinin her zaman yarar sağlamadığını, güçlü yeniden sıralama ile daha yalın yapıların maliyet/başarım açısından etkili olabildiğini göstermiştir. Bu sonuç tek veri kümesinden bütün sistemlere genellenmemeli; ancak Türkçe RAG'da karmaşıklığın ölçülmeden artırılmaması gerektiğini destekler.

Ünite 8: Yeniden Sıralama

İlk retrieval aşamasının amacı mümkün olduğunca ilgili adayları kaçırmamaktır. Sonraki reranker ise daha küçük aday kümesini daha pahalı ama daha hassas biçimde sıralar.

10 milyon parça
    |
    v
BM25 + ANN
    |
  top 100
    |
    v
Cross-Encoder
    |
  top 10
    |
    v
LLM

Bu mimaride pahalı model bütün veri üzerinde çalışmaz.

Bi-encoder ve cross-encoder

Bi-encoder belge vektörlerini önceden hesaplayabilir. Sorgu sırasında hızlıdır.

Cross-encoder ise sorgu ile belgeyi birlikte değerlendirir ve daha ayrıntılı etkileşim kurabilir; fakat her aday için ayrı çıkarım gerektiğinden daha pahalıdır.

Bu nedenle:

bi-encoder = candidate generation
cross-encoder = precision refinement

deseni üretimde yaygındır.

Ünite 9: Sorgu Anlama ve Yönlendirme

Her doğal dil sorusu vektör araması değildir.

"Son 7 gündeki kayıt sayısı kaç?"

deterministik bir toplulaştırma sorusudur.

"Son dönemde değişen iletişim örüntülerini açıkla."

ise SQL, zaman serisi, grafik ve metinsel retrieval birleşimi gerektirebilir.

Bu nedenle query router kullanılabilir.

                 Kullanıcı
                    |
                    v
               Query Router
                    |
      +-------------+-------------+
      |             |             |
  SQL / Filter   Text RAG      Graph Query
      |             |             |
      +-------------+-------------+
                    |
                 Evidence
                    |
                    v
                   LLM

Router'ın kendisi LLM olabilir; fakat yüksek riskli sistemlerde kararın şema, whitelist ve izinli araçlarla sınırlandırılması gerekir.

Ünite 10: Büyük Veri RAG'a Nasıl Bağlanır?

Büyük veri sisteminde her satırı doğal dil cümlesine çevirip embedding üretmek çoğu zaman yanlış tasarımdır.

Örneğin milyarlarca olay kaydı:

event_id
actor_a
actor_b
timestamp
duration
channel
location_observation

şeklinde yapılandırılmışsa sayım, filtre, join ve zaman aralığı sorguları veri tabanı/analitik motor tarafından yapılmalıdır.

RAG katmanı bunun üzerine açıklama ve metinsel kanıt getirebilir.

                  Büyük Veri
                      |
       +--------------+--------------+
       |              |              |
   Yapısal veri    Metin/ASR       İlişkiler
       |              |              |
 SQL/analitik      Hybrid IR        Graph
       |              |              |
       +--------------+--------------+
                      |
                Evidence Builder
                      |
                      v
                     LLM

Embedding'e ne gitmeli?

Embedding için uygun adaylar:

belge paragrafları,
konuşma dökümü segmentleri,
olay özetleri,
açıklamalar,
notlar,
başlıklar,
varlık açıklamaları.

Embedding'e doğrudan göndermek için zayıf adaylar:

yalnız sayısal sayaçlar,
normalize edilmiş kimlikler,
kesin zaman aralığı sorguları,
zaten SQL ile deterministik bulunabilen basit satırlar.

Türetilmiş metin

Yapısal olayların insan tarafından okunabilir açıklaması oluşturulabilir; ancak bu metin kaynak kayıt değildir.

kaynak olay
   |
   v
deterministik özet
   |
   v
embedding

Retrieval sonucu tekrar kaynak event_id değerine bağlanmalıdır.

Ünite 11: Artımlı İndeksleme ve Değişiklik Yakalama

Büyük veri için her gece bütün indeksi baştan üretmek ölçeklenmez.

değişiklik
   |
   v
CDC / zaman damgası / kuyruk
   |
   v
değişen belgeyi yeniden çıkar
   |
   v
eski chunkları geçersiz kıl
   |
   v
yeni chunk + embedding
   |
   v
indeks sürümü

İdempotent ingest

Aynı olay iki kez gelirse iki ayrı belge oluşturmamalıdır.

document_key
source_version
content_hash

gibi alanlarla tekrar işleme denetlenebilir.

Silme

RAG veri yaşam döngüsünde silme zor bir konudur. Kaynak belge silinmişse yalnız veri tabanından değil:

vektör indeksinden,
sözcüksel indeksten,
cache'den,
özet katmanından,
graph düğüm/kenarlarından

da kaldırılması gerekebilir.

Ünite 12: Sıcak, Ilık ve Soğuk Veri

Her veri aynı sıklıkta sorgulanmaz.

HOT
son dönem
yüksek sorgu sıklığı
RAM / hızlı ANN

WARM
orta dönem
disk tabanlı indeks

COLD
uzun arşiv
daha yavaş ama ucuz saklama

Sorgu niyeti doğru veri katmanını seçebilir.

"Son hafta" sorusu yalnız sıcak indekse giderken "beş yıllık eğilim" soğuk arşivi de açabilir.

Bu ayrım özellikle yüz milyonlarca veya milyarlarca olayda bellek ve gecikme kontrolü sağlar.

Ünite 13: Metadata Retrieval'ın Birinci Sınıf Parçasıdır

Metadata yalnız sonuç ekranında gösterilecek süs değildir. Arama uzayını daha embedding çalışmadan küçültebilir.

language = tr
date >= 2026-09-01
content_type = transcript
access_scope IN user_scopes
source_type = communication

ardından dense retrieval yapılabilir.

Bu yaklaşım iki yarar sağlar:

yanlış aday sayısını düşürür,
yetkisiz içeriğin modele hiç ulaşmamasını sağlar.

Metadata ile semantik embedding aynı işi yapmaz.

metadata = kesin filtre
embedding = yaklaşık semantik yakınlık

Ünite 14: Kendi Verimizle Sohbet Sistemi

Kendi verisinden yanıt üreten sohbet sistemi, konuşma geçmişi ile bilgi tabanını ayırmalıdır.

Konuşma Belleği
  = bu oturumda ne konuşuldu?

Bilgi Belleği
  = kurumun / sitenin / arşivin gerçek verisi

Bütün geçmişi sürekli bilgi tabanına yazmak hem gizlilik hem retrieval kalitesi açısından sorun yaratabilir.

Önerilen akış

Kullanıcı
   |
   v
Oturum Bağlamı
   |
   v
Sorgu Yeniden Yazımı
   |
   v
ACL
   |
   v
Retriever Router
   |
   +--> SQL
   +--> BM25
   +--> Dense
   +--> Graph
   |
   v
Reranker
   |
   v
Context Builder
   |
   v
Yerel LLM
   |
   v
Kaynaklı Yanıt

Modelin cevabı yanında kaynak kimlikleri tutulmalıdır.

Yanıt yoksa

Güvenilir sistem, kanıt yokken cevap üretmeye zorlanmamalıdır.

retrieval sonucu yetersiz
        |
        v
"Yeterli kaynak bulunamadı."

Bu davranış, akıcı ama temelsiz bir cevaptan daha değerlidir.

Ünite 15: Kaynak Kökeni ve Kanıt Zinciri

RAG'ın güçlü taraflarından biri kaynak gösterebilmesidir; fakat kaynak eklemek otomatik doğruluk sağlamaz.

Her chunk şu bilgilerle kaynağa dönmelidir:

chunk_id
document_id
source_id
section
offset / page / event_id
version
hash
access_scope

Yanıtta kullanılan iddia ile kaynak arasında gerçek destek olup olmadığı ayrıca değerlendirilmelidir.

Kanıt paketi

Soru
 |
 v
Retrieval Adayları
 |
 v
Reranked Evidence
 |
 +--> kaynak 1
 +--> kaynak 2
 +--> kaynak 3
 |
 v
LLM Yanıtı
 |
 v
İddia-Kaynak Doğrulama

Özellikle adli veya denetlenebilir alanlarda özetin kanıtın yerine geçmesine izin verilmemelidir.

Ünite 16: Graf Tabanlı RAG

Klasik RAG çoğunlukla belge parçaları üzerinden çalışır. İlişki ağırlıklı sorularda bilgi farklı kayıtlara dağılmış olabilir.

A -> B
B -> D
D -> C

Soru A ile C arasındaki bağlantıyı soruyorsa hiçbir tek belge bütün yolu içermeyebilir.

Graph RAG bilgiye düğüm, kenar ve topluluk yapısı üzerinden erişir.

Bilgi grafiği ve olay grafiği

İki yaklaşım ayrılmalıdır.

Bilgi grafiği:

KISI ---- CALISIR ----> KURUM
KURUM --- BULUNUR ----> SEHIR

Olay grafiği:

VARLIK_A
   |
   v
[OLAY_123]
   ^
   |
VARLIK_B

Yüksek etkili iletişim analizinde olay grafiği daha güvenli bir temel olabilir. Çünkü "arkadaş", "örgüt üyesi", "iş ortağı" gibi semantik ilişki etiketleri doğrudan gözlenmiş gerçek olmayabilir.

Kanıt ile yorumun ayrılması

Gözlenen:
A ve B arasında 14 iletişim olayı.

Hesaplanan:
Son 30 günde frekans önceki döneme göre arttı.

Yorum:
İlişkinin niteliği bu veriden tek başına belirlenemez.

RAG sistemi bu üç katmanı karıştırmamalıdır.

Ünite 17: Local, Global ve DRIFT Benzeri Graf Arama

Graf tabanlı retrieval tek yöntem değildir.

Yerel arama

Belirli bir varlık için:

Varlık X
  |
  +--> komşular
  +--> ilişkiler
  +--> ilgili metin parçaları
  +--> ilgili topluluk özeti

sorgulanabilir.

Küresel arama

"Bu veri kümesindeki baskın temalar nelerdir?" gibi sorular klasik top-k vektör retrieval için zordur. Sorguda hangi belirli parçaların seçileceğine dair açık ipucu yoktur.

Graf toplulukları ve önceden üretilmiş topluluk özetleri bütün veri kümesi düzeyinde sorgulamayı mümkün kılabilir.

DRIFT benzeri arama

genel topluluk bilgisi
        |
        v
başlangıç hipotezi
        |
        v
yerel alt sorular
        |
        v
komşu / belge retrieval
        |
        v
yeni alt sorular

Bu yöntem geniş bağlam ile yerel kanıtı birleştirir.

Ancak böyle çok adımlı arama pahalıdır. Her sorguda varsayılan olarak kullanılmamalıdır.

Ünite 18: İletişim ve İnsan İlişkileri İçin Genelleştirilmiş RAG

Yüksek hacimli iletişim olayları, konuşma dökümleri, notlar ve ilişki ağlarının aynı sistemde bulunduğu anonim bir senaryo düşünelim.

Veri katmanları:

İletişim Olayları
Konuşma Dökümleri
Not / Belge
Cihaz Gözlemleri
Konum Gözlemleri
Varlıklar

Tek bir vektör veritabanı bütün bu verinin doğal modeli değildir.

Önerilen mimari

                      Sorgu
                        |
                        v
                    Router
        +---------------+---------------+
        |               |               |
   Deterministik      Metinsel          Graf
      Sorgu             RAG             Arama
        |               |               |
   SQL / zaman      BM25 + Dense     Altgraf
   / filtre             |               |
        +---------------+---------------+
                        |
                     Fusion
                        |
                    Reranker
                        |
                 Evidence Builder
                        |
                  Yerel LLM
                        |
                 Kaynaklı Sonuç

Bu mimaride dil modeli veri tabanının yerine geçmez.

Soru sınıfları

"Belirli zaman aralığında kaç olay var?" -> SQL.

"Bu konuşmalarda hangi teknik konu tekrar ediyor?" -> metinsel RAG.

"İki varlık hangi ara düğümler üzerinden bağlanıyor?" -> graph query.

"Son dönemde ilişki yapısında hangi değişimler var ve metinsel bağlam ne?" -> zaman analizi + graph + RAG.

HTS/CDR benzeri olay verisi

HTS Analizi notundaki temel sınır burada da korunmalıdır: trafik kaydı yorum değildir.

RAG sistemi:

olay kaydı
 -> kanıt

toplulaştırma
 -> hesaplanan özellik

LLM açıklaması
 -> yorumlayıcı sunum

katmanlarını ayrı tutmalıdır.

Bir baz/hücre gözlemi doğrudan kesin fiziksel konum olarak, iletişim sıklığı da doğrudan ilişkinin niteliği olarak sunulmamalıdır.

Ünite 19: Zaman Duyarlı RAG

Olay verisinde zaman sıradan metadata değildir.

kim?
ne zaman?
ne kadar sık?
hangi yönde?
hangi dönem değişti?

soruları birlikte gelir.

Sorgu önce zamansal niyeti çözmelidir.

"son temas"
"ilk temas"
"en yoğun dönem"
"geçen aya göre artış"
"belirli tarih aralığı"

aynı filtre değildir.

Zaman ağırlıklı retrieval

Bazı kullanımda yeni kanıt daha önemli olabilir. Fakat "ilk kayıt" arandığında tam tersi geçerlidir. Bu nedenle tek bir evrensel recency boost doğru değildir.

ranking =
semantic_relevance
+ lexical_relevance
+ task_specific_time_score

Zaman puanı sorgu niyetinden türetilmelidir.

Ünite 20: Graph RAG'da İnsan İlişkilerinin Sınırı

İnsan ilişkisi grafiğinde sistemin bildiği ile çıkarsadığı ayrılmalıdır.

Kenar türleri:

OBSERVED
hesaplamadan önce kaynak olay var

DERIVED
çok sayıda olaydan ölçü türetildi

INFERRED
model veya kural hipotez üretti

UI ve RAG bağlamı bu sınıfları taşımalıdır.

Örneğin:

A --[42 iletişim olayı]--> B

gözlenmiş olaylardan türetilebilir.

A --[yakın arkadaş]--> B

ise çoğu veri kümesinde doğrudan kanıtlanamaz.

Bu ayrım hem bilimsel hem adli yöntem açısından zorunludur.

Ünite 21: Hiyerarşik Retrieval

Çok büyük arşivlerde bütün ham veriyi aynı indeks seviyesinde aramak zorlaşır.

Kurum Arşivi
   |
   +--> Yıl
         |
         +--> Ay
               |
               +--> Topluluk / konu
                     |
                     +--> Olay grubu
                           |
                           +--> ham belge / transkript

Üst seviyede özetler aday alanı seçmek için kullanılabilir.

Ancak:

özet = yönlendirme
ham kaynak = kanıt

ilkesi korunmalıdır.

Özetler zaman içinde yeniden üretilebilir; kaynak olayın kendisi değildir.

Ünite 22: Query Decomposition

Karmaşık soru tek retrieval isteğine indirgenmemelidir.

Örnek:

Son üç ayda iletişim yoğunluğu artan ve aynı zamanda konuşma içeriğinde yeni bir teknik konu görülen ilişki çiftlerini açıkla.

Bu soru:

1. zaman aralığını çöz
2. iletişim yoğunluğu değişimini hesapla
3. aday çiftleri seç
4. ilgili transkriptleri getir
5. yeni konu kanıtını ara
6. kaynakları birleştir
7. sonucu açıkla

adımlarına ayrılabilir.

Her alt soru farklı retriever kullanabilir.

Bu, agentic RAG'ın kontrollü biçimidir.

Ünite 23: Ajan Destekli RAG

Ajanlı sistem retrieval yöntemini dinamik seçebilir, sorguyu yeniden yazabilir veya yeterli kanıt yoksa başka arama yapabilir.

Soru
 |
 v
Plan
 |
 v
Retrieve
 |
 v
Kanıt yeterli mi?
 |            |
 hayır        evet
 |            |
 v            v
yeniden      yanıt
sorgula

Risk, açık uçlu döngüdür.

Üretimde:

azami adım,
azami token,
süre sınırı,
izinli araç listesi,
sorgu maliyet bütçesi

olmalıdır.

Ajan karar verirken yetki kapsamını genişletememelidir.

Ünite 24: Kapalı Ağ ve Yerel RAG

Hassas veri dış servise gönderilemiyorsa RAG tümüyle yerel çalışabilir.

Yerel Kaynaklar
   |
   v
Yerel Embedding
   |
   v
Yerel İndeks
   |
   v
Yerel Reranker
   |
   v
Yerel LLM

Çevrimdışı embedding, veri gizliliği ve sürüm kontrolü için değerlidir. Ekli uygulama kaynağı da internet bağlantısına veya bulut API'sine ihtiyaç duymayan yerel embedding kullanımını ayrı bir yöntem olarak ele almaktadır.

Yerel dağıtımda dikkat

model lisansı,
model dosyasının hash'i,
embedding sürümü,
tokenizer sürümü,
indeks uyumluluğu,
CPU/GPU kapasitesi,
güncelleme paketi,
geri dönüş

birlikte yönetilmelidir.

Embedding modeli değiştiğinde eski indeks genellikle yeniden oluşturulmalıdır; iki farklı embedding uzayındaki vektörleri tek indeks içinde doğrudan karşılaştırmak doğru değildir.

Ünite 25: Performans ve Kapasite Mühendisliği

RAG gecikmesi yalnız LLM süresi değildir.

T_total =
query_parse
+ auth
+ filter
+ sparse_search
+ vector_search
+ rerank
+ context_build
+ LLM_prefill
+ LLM_decode

Toplam p95/p99 ölçülmelidir.

Retrieval bütçesi

Top-k artırmak recall'u yükseltebilir; fakat:

reranker maliyetini,
bağlam token sayısını,
prefill süresini,
dikkat yükünü

artırır.

Daha fazla belge her zaman daha iyi yanıt değildir.

Asenkron ingest

Büyük arşiv indekslenirken:

reader -> parse queue -> chunk workers -> embedding batches -> index writer

şeklinde boru hattı kurulabilir.

Backpressure olmadan üreticiler tüketicilerden hızlı çalışırsa bellek büyür.

Arama için partition

Veri doğal olarak:

tarih,
dil,
kaynak,
yetki alanı,
veri türü

ile bölünebiliyorsa bütün indeks yerine ilgili partition aranabilir.

Ünite 26: Önbellek

RAG'ta birden fazla cache katmanı vardır.

query normalization cache
embedding cache
retrieval cache
reranker cache
final response cache

En güvenlisi genellikle deterministik aşamalardır.

Final response cache kullanılırken:

kullanıcı yetkisi,
indeks sürümü,
model sürümü,
prompt sürümü

cache anahtarına dâhil edilmelidir.

Aksi durumda eski veya başka yetki bağlamına ait cevap sızabilir.

Ünite 27: Güvenlik

RAG sistemi dış metni modele taşıdığı için yeni saldırı yüzeyi oluşturur.

Prompt injection

Belge içinde:

"önceki talimatları yok say"

gibi bir metin bulunması, belgenin sistem talimatı olduğu anlamına gelmez.

Retriever'dan gelen içerik:

UNTRUSTED DATA

olarak işaretlenmeli; sistem talimatından ayrı sınırda tutulmalıdır.

Vektör ve embedding riskleri

Riskler:

yetkisiz retrieval,
tenantlar arası bilgi sızıntısı,
embedding inversion,
zehirlenmiş doküman,
eski ve yeni bilginin çelişmesi,
hassas metadata.

Embedding hassas veriyi sihirli biçimde anonim yapmaz.

ACL retrieval'dan önce uygulanır

Yanlış:

tüm veri
 -> retrieval
 -> LLM context
 -> sonra yetki kontrolü

Doğru:

kullanıcı kimliği
   |
   v
izinli veri kapsamı
   |
   v
retrieval
   |
   v
LLM

Yetkisiz veri bağlam penceresine hiç girmemelidir.

Poisoning

Bilgi tabanına eklenen kötü niyetli belge retrieval'da üst sıralara çıkacak biçimde hazırlanabilir.

Bu nedenle ingest aşamasında:

kaynak güveni,
dijital imza/hash,
editoryal onay,
belge sınıfı,
oluşturma/değiştirme kaydı

tutulmalıdır.

Ünite 28: RAG Değerlendirmesi

RAG tek model değildir. En az üç ayrı katman ölçülmelidir.

Retrieval

Recall@K
Precision@K
MRR
nDCG
hit rate
source diversity

Generation

yanıt ilgisi,
doğruluk,
faithfulness,
kaynak desteği,
desteklenmeyen iddia oranı,
alıntı doğruluğu.

Sistem

p50/p95/p99,
throughput,
index freshness,
zero-result rate,
ACL ihlali,
cache hit oranı,
kaynak başına maliyet.

RAG quality
   |
   +--> retrieval quality
   +--> generation quality
   +--> system quality

Tek bir "RAG score" hatanın nerede olduğunu gizleyebilir.

Altın veri kümesi

Gerçek sorulardan küçük ama güvenilir bir test seti hazırlanmalıdır.

Her soru için:

expected_sources
acceptable_answer
forbidden_claims
required_filters

gibi alanlar tutulabilir.

Ünite 29: Halüsinasyonu Azaltmak, Yok Etmemek

RAG yanlış bilgi üretimini azaltabilir; sıfırlamaz.

Hata kaynakları:

yanlış retrieval
doğru retrieval + yanlış yorum
yetersiz retrieval
çelişkili kaynak
modelin parametrik önbilgisi
prompt injection
eski indeks

Bu nedenle "RAG varsa model halüsinasyon yapmaz" ifadesi yanlıştır.

Güvenilir sistem:

kanıt yoksa -> cevap yok
kanıt çelişkiliyse -> çelişkiyi göster
kanıt kısıtlıysa -> kapsamı belirt

davranışını desteklemelidir.

Ünite 30: Sürümleme ve Yeniden Üretilebilirlik

Bir RAG sürümü yalnız LLM model adı değildir.

RAG_RELEASE =
    parser_version
  + chunker_version
  + embedding_version
  + lexical_index_version
  + vector_index_version
  + graph_version
  + reranker_version
  + prompt_version
  + llm_version
  + acl_policy_version

Bir kalite değişikliği olduğunda hangi bileşenin değiştiği bilinebilmelidir.

İndeks yeniden üretimi deterministik değilse karşılaştırmalı değerlendirme zorlaşır.

Ünite 31: Üretime Geçiş Planı

RAG sistemi bir anda bütün sisteme eklenmemelidir.

Aşama 1: Salt arama

Sorgu -> Hybrid Search -> Kaynak listesi

LLM yoktur. Retrieval kalitesi ölçülür.

Aşama 2: Kaynaklı özet

Sorgu -> Retrieval -> Reranker -> LLM -> kaynaklı özet

Araç çağrısı yoktur.

Aşama 3: Sınırlı sohbet

Konuşma geçmişi ve takip soruları eklenir.

Aşama 4: Yapısal araçlar

Read-only SQL ve graph query gibi araçlar kontrollü biçimde eklenir.

Aşama 5: Ajan

Yalnız gerekliyse dinamik planlama eklenir.

Bu ilerleme, retrieval hatalarını ajan karmaşıklığı altında gizlememeyi sağlar.

Ünite 32: Genel Amaçlı Üretim Mimarisi

Anonimleştirilmiş yüksek hacimli, kapalı ağ, çok kaynaklı bir sistem için önerdiğim temel mimari şöyledir:

                         Kullanıcı
                            |
                     Kimlik / Oturum
                            |
                         Yetki
                            |
                       Query Router
                            |
        +-------------------+--------------------+
        |                   |                    |
   SQL / Analitik       Hybrid Text          Graph
        |             BM25 + Dense            Query
        |                   |                    |
        |               Fusion               Subgraph
        |                   |                    |
        +-------------------+--------------------+
                            |
                         Reranker
                            |
                    Evidence Builder
                            |
                     Kaynak / Kapsam
                            |
                        Yerel LLM
                            |
                    Output Validator
                            |
                       Kaynaklı Yanıt

Bu yapı üç temel ilkeye dayanır:

deterministik soru deterministik motorla çözülür,
semantik soru retrieval ile çözülür,
ilişki sorusu grafik yapıyla çözülür.

LLM son katmanda açıklama, birleştirme ve doğal dil arayüzü sağlar.

Ünite 33: Uygulama Örneği — Eski İçerik Sisteminden RAG'a

Bir site yıllardır teknik içerik yayımlıyor olsun.

Kaynak modeli

CONTENT
id
language
slug
title
summary
body
published_at
modified_at

RAG indeksi için kaynak şema değiştirilmek zorunda değildir.

Ayrı indeks belgesi:

rag_document
document_id = content.id
language
title
section_path
chunk_text
modified_at
content_hash
source_url

Güncelleme

modified_at değişti
   |
   v
yalnız o içerik yeniden parçalanır
   |
   v
eski chunklar silinir
   |
   v
yeni embedding + BM25 index

Bu sayede yüzlerce veya binlerce eski içerik bir defada "akıllı" hâle gelir; asıl site çalışma biçimini korur.

Ünite 34: Uygulama Örneği — Yapısal Olay + Metin + Graf

İkinci örnek, çok büyük olay tablosuyla konuşma dökümlerinin birlikte bulunduğu bir sistemdir.

EVENT
  |
  +--> zaman
  +--> iki uç / taraf
  +--> süre
  +--> kanal
  +--> kaynak kimliği

TRANSCRIPT
  |
  +--> event_id
  +--> segment
  +--> text

GRAPH
  |
  +--> node
  +--> edge/event reference

Sorgu:

Son 60 günde yoğunluğu artan ilişkilerde hangi konuşma konuları öne çıkıyor?

İşlem:

SQL
 -> yoğunluk değişimini hesapla
 -> aday çiftler

Graph
 -> adayların altgrafını getir

Hybrid RAG
 -> ilgili transcript parçalarını bul

Reranker
 -> kanıtı sırala

LLM
 -> yalnız getirilen kanıtı özetle

Bu mimari ham olayların tamamını embedding'e çevirmekten daha denetlenebilir ve daha verimlidir.

Ünite 35: Türkçe RAG Tasarım İlkeleri

Türkçe için ayrı değerlendirme gereklidir.

Normalizasyon

I/İ/ı/i, Unicode, özel ad ekleri ve ASCII Türkçe farklı retrieval davranışı oluşturabilir.

Lexical index için alternatif normalize alanlar tutulabilir:

original
lower_tr
ascii_aux
stem/morph_aux

Kanonik içerik değiştirilmez.

Morfoloji

Sorgu ile belgede aynı kökün farklı ekli biçimleri bulunabilir. BM25 tarafında morfolojik normalizasyon veya uygun analyzer yararlı olabilir. Dense retrieval bunu kısmen semantik olarak aşabilir; fakat her model Türkçe morfolojiyi eşit iyi temsil etmez.

Çok dilli veri

Türkçe sorgu İngilizce teknik dokümanı bulmak zorundaysa çok dilli embedding gerekir.

TR query
   |
multilingual embedding
   |
EN technical document

Ancak dil filtresi gerektiğinde metadata ile sınırlandırılmalıdır.

Ünite 36: Ne Zaman Graph RAG Kullanılmamalı?

Graph RAG etkileyici olduğu için her veri kümesine uygulanmamalıdır.

Kullanmayın veya erteleyin:

sorular çoğunlukla tek belge içindeyse,
varlık/ilişki çıkarmanın doğruluğu düşükse,
indeksleme maliyeti kabul edilemiyorsa,
veri çok sık değişiyor ve graph yeniden üretimi pahalıysa,
kullanıcıların çoğu yalnız tam metin arıyorsa.

Önce baseline RAG ölçülmelidir.

baseline
  -> hybrid search
  -> reranker
  -> citations

yetmiyorsa
  -> hierarchical / graph retrieval

Bu yaklaşım gereksiz mimari karmaşıklığı önler.

Ünite 37: RAG ile İnce Ayarın Birlikte Kullanımı

RAG ve fine-tuning birlikte olabilir.

Fine-tuning:

çıktı biçimi,
alan üslubu,
görev davranışı,
sınıflandırma yeteneği

için kullanılabilir.

RAG:

güncel bilgi,
erişim kontrollü belge,
kaynak gösterme,
değişken bilgi

için kullanılabilir.

Fine-tuned model
      +
RAG evidence
      =
alan davranışı + güncel bilgi

Ancak gizli veriyi modele ezberletmek ile erişim kontrollü retrieval arasında güvenlik farkı vardır.

Ünite 38: Bilgi ve Eylem Sınırı

RAG yanıt vermek için kanıt getirir. Eylem yapmak ayrı yetki gerektirir.

Soru
 |
 v
RAG
 |
 v
Öneri
 |
 v
Politika / İnsan / Deterministik Kural
 |
 v
Eylem

Özellikle yüksek etkili sistemlerde LLM'nin doğal dil cevabı doğrudan işlem komutu olmamalıdır.

Ünite 39: Veri Türüne Göre Retriever Tasarımı

Tek retriever bütün veri türlerinde en iyi sonucu vermez. Üretim RAG sisteminde veri kaynağının semantiği retrieval yöntemini belirlemelidir.

Teknik doküman

Teknik dokümanda başlık, bölüm yolu, sürüm ve ürün adı önemlidir.

query
 |
 +--> exact term / BM25
 |
 +--> dense semantic search
 |
 +--> section metadata filter
 |
 v
reranker

Bir API adı, hata kodu veya sınıf adı dense embedding içinde anlamsal olarak zayıf temsil edilebilir; sözcüksel indeks bu değerleri korur.

Konuşma dökümü

Konuşma dökümlerinde doğal parça yalnız sabit token sayısı değildir.

Metadata:

record_id
speaker_role
start_time
end_time
language
segment_order

olabilir.

Aynı konuşmanın birbirinden çok uzak segmentlerini top-k sonucu olarak getirip tek bağlamda birleştirmek yanlış anlam oluşturabilir. Retrieval sonrasında komşu segment genişletmesi yapılabilir:

hit segment
   |
   +--> previous segment
   +--> current segment
   +--> next segment

Bu, semantik aramanın bulduğu dar bölgeyi konuşma bağlamıyla genişletir.

Olay kaydı

Olay kaydı için önce metadata/SQL filtresi uygulanmalıdır. Serbest açıklama veya transkript varsa dense retrieval ikinci aşama olabilir.

Kaynak kod

Kod aramasında sembol adı, dosya yolu, dil ve çağrı ilişkileri önemlidir. Embedding tek başına yeterli değildir.

symbol search
 + lexical search
 + code embedding
 + call graph

aynı sistemde kullanılabilir.

Graf

Graf retrieval için komşuluk, yol, topluluk ve zaman penceresi kullanılır. Metin embedding'i graf sorgusunun alternatifi değil, düğüm/kenar açıklamalarını bulmaya yardımcı bir katmandır.

Ünite 40: Context Builder Bir Toplama İşlemi Değildir

Top-k sonuçları ham biçimde birleştirmek iyi context engineering değildir.

Context Builder şu soruları çözmelidir:

aynı kaynağın tekrar eden parçaları var mı,
çelişen kaynaklar var mı,
kanıtın zamanı nedir,
kaynak yetki kapsamı nedir,
birbirine komşu chunklar birleştirilmeli mi,
hangi kanıt daha yüksek güven taşıyor,
toplam token bütçesi nedir?

Duplicate collapse

Aynı paragrafın farklı sürümleri veya overlap nedeniyle benzer chunklar gelebilir.

candidate set
  |
  v
near-duplicate collapse
  |
  v
source diversity
  |
  v
token budget packing

Kaynak çeşitliliği

Top 10 sonucun tamamı aynı belgeden geliyorsa model tek kaynağa aşırı bağımlı kalabilir. Soruya göre belge başına kota uygulanabilir.

Buna karşılık gerçekten tek bir teknik standardın sorulduğu durumda çeşitlilik uğruna ilgisiz kaynak eklemek de yanlıştır.

Çelişki

İki kaynak farklı değer veriyorsa sistem birini sessizce seçmemelidir.

Source A -> değer X
Source B -> değer Y
        |
        v
"Kaynaklar çelişiyor."

Belge sürümü ve tarih bilgisi çelişkinin çözümüne yardımcı olabilir.

Citation mapping

Yanıt bittikten sonra rastgele kaynak eklemek yerine iddia üretimi sırasında kanıt kimlikleri taşınmalıdır.

Evidence E17
Evidence E42
    |
    v
Answer Claim C3
    |
    +--> supports: E17
    +--> supports: E42

Bu model, kaynak doğrulamasını sonradan yapılabilir hâle getirir.

Ünite 41: İletişim Olayları İçin Genel Graf Veri Modeli

İnsan ilişkilerini inceleyen bir sistemde grafı doğrudan sosyal etiketlerle kurmak yerine olayları birinci sınıf veri olarak tutmak daha denetlenebilirdir.

Örnek kavramsal model:

Entity
  |
  +--> participates_in --> CommunicationEvent
                              |
                              +--> timestamp
                              +--> duration
                              +--> direction
                              +--> channel
                              +--> source_record_id
                              +--> transcript_id

Aynı olayın iki veya daha fazla katılımcısı olabilir. Pairwise edge yalnız sorgu veya görselleştirme için türetilebilir.

İlişki kenarı

Entity A -------- Entity B
       aggregate edge

kenarının özellikleri:

event_count
total_duration
first_seen
last_seen
directional_counts
channel_distribution
source_event_ids

olabilir.

Ancak kenar, ham kanıt değildir. source_event_ids geri izlenebilirliği korur.

Zamansal pencere

Graf tek ve sonsuz zamanlı bir yapı olarak okunmamalıdır.

G(t1,t2)

belirli zaman aralığındaki ilişkileri temsil eder.

Aynı iki varlık:

Ocak: 2 olay
Şubat: 3 olay
Mart: 47 olay

gibi farklı davranış gösterebilir.

Graph RAG soruya göre uygun zaman penceresini seçmelidir.

Yön

A -> B ve B -> A olayları gerektiğinde ayrı korunmalıdır. Görselleştirme bunları tek undirected edge altında özetleyebilir; fakat retrieval katmanı yön bilgisini kaybetmemelidir.

Ünite 42: Graf Toplulukları ve Küresel Anlamlandırma

Büyük ilişki grafında her düğümü LLM bağlamına göndermek mümkün değildir. Topluluk tespiti, grafı daha küçük ve yapısal olarak yoğun alt gruplara ayırabilir.

Full Graph
   |
   +--> Community A
   |      +--> nodes
   |      +--> edges
   |      +--> evidence
   |
   +--> Community B
   |
   +--> Community C

Topluluk algoritmasının sonucu "gerçek dünyadaki örgüt" veya "sosyal grup" değildir. Yalnız kullanılan graf, kenar tanımı, ağırlık ve zaman penceresine göre matematiksel bir kümedir.

Bu ayrım açık biçimde yazılmalıdır:

graph community
   !=
real-world organization

Topluluk özeti

Topluluk özeti şu bilgilerden üretilebilir:

baskın düğümler,
yüksek ağırlıklı kenarlar,
zaman dağılımı,
ilişkili belge/transkript temaları,
kanıt kapsamı.

Ancak özet yalnız retrieval hızlandırıcıdır. Kullanıcı ayrıntı istediğinde sistem ham olaya ve metne geri dönmelidir.

Global soru

"Veri kümesinde hangi ilişki örüntüleri belirginleşiyor?" gibi soru:

community reports
   |
   v
map: community-level partial answers
   |
   v
reduce: corpus-level synthesis

deseniyle ele alınabilir.

Bu işlem maliyetli olduğundan batch olarak önceden hazırlanmış topluluk raporları kullanılabilir.

Ünite 43: RAG İçin Karar Ağacı

Her problemde RAG kullanmak doğru değildir.

Soru kesin bir filtre / aggregate mı?
  |
  +--> Evet -> SQL / analitik motor
  |
  +--> Hayır
        |
        v
Metinsel kanıt gerekli mi?
  |
  +--> Evet -> Hybrid Retrieval
  |
  +--> Hayır
        |
        v
İlişki / multi-hop problem mi?
  |
  +--> Evet -> Graph Retrieval
  |
  +--> Hayır
        |
        v
Modelin davranışı mı yetersiz?
  |
  +--> Evet -> prompt / SFT / fine-tuning
  |
  +--> Hayır -> problemi yeniden tanımla

RAG'ın mimari disiplini, her şeyi embedding'e çevirmemekten başlar.

Ünite 44: Değerlendirme Veri Kümesi Nasıl Hazırlanır?

Üretim RAG sistemi için benchmark internetten alınmış genel sorulardan oluşmamalıdır. Gerçek iş yükünü temsil eden kapalı bir test seti hazırlanmalıdır.

Soru sınıfları ayrı tutulabilir:

exact lookup
semantic lookup
multi-document synthesis
temporal
graph local
graph multi-hop
global corpus
no-answer
authorization
adversarial

Her sınıfta yeterli örnek bulunmalıdır.

No-answer testi

Bilgi tabanında olmayan soru özellikle önemlidir.

Başarılı davranış:

kanıt yok
 -> "Bu veri kümesinde destekleyen kaynak bulamadım."

Başarısız davranış:

kanıt yok
 -> parametrik bilgiden ikna edici cevap

Authorization testi

Aynı soru iki farklı kullanıcı kapsamıyla çalıştırılır.

User A -> sources {1,2,3}
User B -> sources {2}

User B'nin yanıtı 1 veya 3 numaralı kaynaktan bilgi sızdırmamalıdır.

Regression

Üretimde görülen her ciddi retrieval veya grounding hatası regresyon testine dönüşmelidir.

Ünite 45: Anonimleştirilmiş Kritik Sistem İçin Aşamalı Uygulama Önerisi

Kapalı ağda çalışan, büyük olay verisi, konuşma dökümü ve ilişki analizi bulunan bir sistem için doğrudan Graph RAG ile başlamazdım.

Faz 1: Metinsel kanıt retrieval

Kaynaklar:

transcript
note
article
structured description

İlk hat:

Turkish-aware lexical index
        +
multilingual / Turkish-capable dense embedding
        |
        v
RRF
        |
        v
cross-encoder reranker

LLM olmadan retrieval benchmark yapılır.

Faz 2: Kaynaklı soru-cevap

Yerel LLM eklenir.

Model talimatı:

yalnız verilen kanıta dayan
kanıt yoksa belirt
kaynak id'lerini koru
kişiler hakkında kanıtsız ilişki etiketi üretme

Çıktı serbest metin yanında yapısal kanıt listesi taşır.

Faz 3: SQL ve graf router

Sorgu sınıflandırılır:

count / range / exact -> SQL
semantic -> RAG
relationship -> graph
mixed -> orchestrated

Read-only araçlar kullanılır.

Faz 4: Zamansal altgraf

Graph indeksine zaman penceresi ve event provenance eklenir.

node -> edge -> event ids -> transcript ids

Graph sonucu her zaman kaynak olaylara geri dönebilir.

Faz 5: Topluluk ve Graph RAG

Yalnız gerçek sorguların önemli bölümü:

multi-hop,
global theme,
community-level

sorularına dönüşüyorsa eklenir.

Neden bu sıra?

Çünkü en pahalı mimari problemi ilk çözüm olarak seçmek:

değerlendirmeyi zorlaştırır,
hata kaynağını gizler,
indeksleme maliyetini artırır,
üretim gecikmesini öngörülemez kılar.

Önce güçlü baseline, sonra ölçülen boşluk.

Ünite 46: Basit Bir Uygulama Sözleşmesi

Framework bağımsız bir RAG servisi şu kavramsal arayüze sahip olabilir:

search(query, scope, filters)
 -> Evidence[]

answer(query, evidence)
 -> Answer

graph(query, scope, timeRange)
 -> GraphEvidence[]

aggregate(metric, filters)
 -> StructuredEvidence

Evidence örneği:

evidence_id
source_id
source_type
text
score
timestamp
access_scope
provenance

LLM hiçbir zaman doğrudan veri tabanı nesnesi döndürmek zorunda değildir; uygulama katmanı kanıtı kontrollü DTO benzeri yapıya dönüştürür.

Bu ayrım framework değişimini kolaylaştırır.

application
   |
RAG contracts
   |
+-- lexical engine
+-- vector engine
+-- graph engine
+-- LLM runtime

LangChain, LlamaIndex veya başka bir orkestrasyon kütüphanesi kullanılabilir; fakat alan sözleşmesinin kendisi kütüphaneye bağlanmamalıdır.

Ünite 47: Maliyet Modeli ve Ölçekleme

RAG maliyeti yalnız token maliyeti değildir.

Yerel sistemde de:

embedding compute
index memory
disk
reranker compute
LLM GPU memory
queueing
reindex duration

kaynak maliyetidir.

İndeks büyüklüğü

Kabaca:

vector_count
x dimensions
x bytes_per_dimension

ham vektör belleğinin temelini verir. ANN grafı, metadata ve indeks yapısı ek yük oluşturur.

Büyük veri için:

daha küçük embedding boyutu,
quantization,
partitioning,
cold storage,
selective embedding

değerlendirilebilir.

Kalite ölçülmeden boyut düşürülmemelidir.

Reranker kapasitesi

Cross-encoder top-100 aday üzerinde pahalıysa:

top 100 -> lightweight reranker -> top 30
top 30  -> stronger reranker -> top 8

gibi kademeli yapı kurulabilir.

Her aşama ek latency getirir; faydası benchmark ile kanıtlanmalıdır.

Yapay Zeka, NLP ve Büyük Dil Modelleri ile İlişkisi

RAG, yapay zekânın bütünü değildir. Yapay zekâ problem çözme, öğrenme, arama, bilgi gösterimi, planlama ve karar verme gibi çok geniş bir alanı kapsar.

Doğal Dil İşleme, metnin nasıl temsil edildiğini, tokenlaştırıldığını, arandığını ve anlamlandırıldığını açıklar. RAG'ın lexical retrieval, embedding, query expansion ve metin parçalama bileşenleri doğrudan NLP ve bilgi erişimi temeline dayanır.

Büyük Dil Modelleri, retrieval sonucunu yorumlayan ve doğal dil yanıtına dönüştüren üretici modeli açıklar. RAG, LLM'nin ağırlıklarını değiştirmek zorunda değildir; çalışma zamanı bağlamını değiştirir.

NLP
  -> metin ve sorgu temsili

LLM
  -> dil üretimi ve bağlam kullanımı

RAG
  -> doğru dış bilginin doğru anda modele bağlanması

Graf tabanlı RAG ise buna Ayrık Matematik: Kümeler, Mantık, Bağıntılar ve Graflar dersindeki grafik kuramı ile bilgi gösterimi boyutunu ekler.

Veri Tabanı Yönetim Sistemleri ile ilişki de önemlidir. RAG veri tabanının alternatifi değildir. Yapısal veri, bütünlük, transaction, indeks ve deterministik sorgu yine veri tabanı sisteminin sorumluluğudur. RAG, yapılandırılmış ve yapılandırılmamış bilgiyi doğal dil arayüzünde birleştiren üst katmandır.

İletişim ve ilişki verisinde HTS Analizi notundaki kaynak–yorum ayrımı korunmalıdır. Graf kenarı, toplulaştırma ve LLM yorumu aynı epistemik seviyede değildir.

Sonuç

Bilgi Erişimi Destekli Üretim, büyük dil modeline daha fazla metin vermek değildir. Doğru veri kaynağını, doğru retrieval yöntemini, doğru yetki sınırını ve doğru kanıt zincirini tasarlama problemidir.

Olgun bir RAG sistemi:

Belge Arama
   +
Veri Tabanı
   +
Graf Analizi
   +
NLP
   +
LLM
   +
Yetkilendirme
   +
Değerlendirme

bileşimidir.

En iyi RAG mimarisi en fazla ajanı, en büyük modeli veya en karmaşık grafı kullanan mimari değildir. Ölçülebilir retrieval kalitesi, düşük ve öngörülebilir gecikme, kaynak kökeni, erişim denetimi ve kanıta geri izlenebilirlik sağlayan mimaridir.

Kaynakça

Patrick Lewis et al. “Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks.” NeurIPS, 2020. https://arxiv.org/abs/2005.11401

Vladimir Karpukhin et al. “Dense Passage Retrieval for Open-Domain Question Answering.” EMNLP, 2020. https://arxiv.org/abs/2004.04906

Nils Reimers; Iryna Gurevych. “Sentence-BERT: Sentence Embeddings using Siamese BERT-Networks.” EMNLP-IJCNLP, 2019. https://arxiv.org/abs/1908.10084

Jeff Johnson; Matthijs Douze; Hervé Jégou. “Billion-scale Similarity Search with GPUs.” 2017. https://arxiv.org/abs/1702.08734

Yu. A. Malkov; D. A. Yashunin. “Efficient and Robust Approximate Nearest Neighbor Search Using Hierarchical Navigable Small World Graphs.” IEEE TPAMI, 2020; preprint 2016. https://arxiv.org/abs/1603.09320

Omar Khattab; Matei Zaharia. “ColBERT: Efficient and Effective Passage Search via Contextualized Late Interaction over BERT.” SIGIR, 2020. https://arxiv.org/abs/2004.12832

Darren Edge et al. “From Local to Global: A Graph RAG Approach to Query-Focused Summarization.” 2024. https://arxiv.org/abs/2404.16130

Zirui Guo et al. “LightRAG: Simple and Fast Retrieval-Augmented Generation.” 2024. https://arxiv.org/abs/2410.05779

Hao Yu et al. “Evaluation of Retrieval-Augmented Generation: A Survey.” 2024. https://arxiv.org/abs/2405.07437

Dongyu Ru et al. “RAGChecker: A Fine-grained Framework for Diagnosing Retrieval-Augmented Generation.” 2024. https://arxiv.org/abs/2408.08067

Süha Kağan Köse et al. “RAGTurk: Best Practices for Retrieval Augmented Generation in Turkish.” SIGTURK 2026, 2026. DOI: https://doi.org/10.18653/v1/2026.sigturk-1.15

Microsoft Research. GraphRAG Documentation: Basic, Local, Global and DRIFT Search. https://microsoft.github.io/graphrag/

OWASP GenAI Security Project. LLM01:2025 Prompt Injection. https://genai.owasp.org/llmrisk/llm01-prompt-injection/

OWASP GenAI Security Project. LLM08:2025 Vector and Embedding Weaknesses. https://genai.owasp.org/llmrisk/llm082025-vector-and-embedding-weaknesses/

Deepak Dhyani. RAG with Python Cookbook: Learn Principles of RAG with LLM and Agentic AI, with 120+ Recipes. BPB Publications, 2026. ISBN 978-93-65895-735.

Julie Smith. RAG Generative AI: A Practical Guide to Building Custom Retrieval-Augmented Pipelines and Enhancing AI Systems. 2024.