# Bilgi Erişimi Destekli Üretim (RAG) > 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. - Author: Muhammet Ali Köker - Language: tr - Canonical: https://alikoker.com.tr/rag - Translation: https://alikoker.com.tr/en/rag - Published: 2024-09-01T12:00:00+03:00 - Modified: 2026-09-19T20:37:40+03:00 - Type: article 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](/yapay-zeka-felsefe-kuram-uygulama), [Doğal Dil İşleme](/dogal-dil-isleme) ve [Büyük Dil Modelleri](/buyuk-dil-modelleri) derslerinin doğal devamıdır. ```text 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: ```text 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. ```text +-------------------+ | 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. ```text 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. ```text 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. ```text 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: ```text kullanıcı -> "gerçek zamanlı sistem" -> eşleşen sayfalar ``` RAG: ```text 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. ```text 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. ```text 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. ```text 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. ```text 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: ```text 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. ```text 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. ```text "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ı: ```text 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 ```text +--> 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. ```text 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: ```text 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. ```text "Son 7 gündeki kayıt sayısı kaç?" ``` deterministik bir toplulaştırma sorusudur. ```text "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. ```text 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ı: ```text 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. ```text 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. ```text 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. ```text 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. ```text 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. ```text 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. ```text 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: 1. yanlış aday sayısını düşürür, 2. yetkisiz içeriğin modele hiç ulaşmamasını sağlar. Metadata ile semantik embedding aynı işi yapmaz. ```text 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. ```text 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ış ```text 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. ```text 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: ```text 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 ```text 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. ```text 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: ```text KISI ---- CALISIR ----> KURUM KURUM --- BULUNUR ----> SEHIR ``` Olay grafiği: ```text 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ı ```text 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: ```text 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 ```text 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ı: ```text İ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 ```text 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](/hts-analizi) notundaki temel sınır burada da korunmalıdır: trafik kaydı yorum değildir. RAG sistemi: ```text 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. ```text kim? ne zaman? ne kadar sık? hangi yönde? hangi dönem değişti? ``` soruları birlikte gelir. Sorgu önce zamansal niyeti çözmelidir. ```text "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. ```text 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: ```text 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: ```text A --[42 iletişim olayı]--> B ``` gözlenmiş olaylardan türetilebilir. ```text 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. ```text 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: ```text ö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: ```text 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. ```text 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. ```text 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. ```text 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: ```text 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. ```text 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: ```text "önceki talimatları yok say" ``` gibi bir metin bulunması, belgenin sistem talimatı olduğu anlamına gelmez. Retriever'dan gelen içerik: ```text 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ış: ```text tüm veri -> retrieval -> LLM context -> sonra yetki kontrolü ``` Doğru: ```text 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. ```text 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: ```text 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ı: ```text 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: ```text 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. ```text 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 ```text Sorgu -> Hybrid Search -> Kaynak listesi ``` LLM yoktur. Retrieval kalitesi ölçülür. ### Aşama 2: Kaynaklı özet ```text 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: ```text 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: 1. deterministik soru deterministik motorla çözülür, 2. semantik soru retrieval ile çözülür, 3. 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 ```text 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: ```text rag_document document_id = content.id language title section_path chunk_text modified_at content_hash source_url ``` ### Güncelleme ```text 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. ```text 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: ```text 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: ```text 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. ```text 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. ```text 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. ```text 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. ```text 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. ```text 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: ```text 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: ```text 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. ```text 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. ```text 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. ```text 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. ```text 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: ```text 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ı ```text Entity A -------- Entity B aggregate edge ``` kenarının özellikleri: ```text 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. ```text G(t1,t2) ``` belirli zaman aralığındaki ilişkileri temsil eder. Aynı iki varlık: ```text 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. ```text 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: ```text 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: ```text 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. ```text 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: ```text 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ış: ```text kanıt yok -> "Bu veri kümesinde destekleyen kaynak bulamadım." ``` Başarısız davranış: ```text kanıt yok -> parametrik bilgiden ikna edici cevap ``` ### Authorization testi Aynı soru iki farklı kullanıcı kapsamıyla çalıştırılır. ```text 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: ```text transcript note article structured description ``` İlk hat: ```text 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ı: ```text 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: ```text 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. ```text 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: ```text search(query, scope, filters) -> Evidence[] answer(query, evidence) -> Answer graph(query, scope, timeRange) -> GraphEvidence[] aggregate(metric, filters) -> StructuredEvidence ``` `Evidence` örneği: ```text 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. ```text 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: ```text embedding compute index memory disk reranker compute LLM GPU memory queueing reindex duration ``` kaynak maliyetidir. ### İndeks büyüklüğü Kabaca: ```text 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: ```text 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](/dogal-dil-isleme), 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](/buyuk-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. ```text 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](/ayrik-matematik-kumeler-mantik-bagintilar-graflar) dersindeki grafik kuramı ile bilgi gösterimi boyutunu ekler. [Veri Tabanı Yönetim Sistemleri](/veri-tabani-yonetim-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](/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: ```text 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. ## Bu Çalışmaya Atıf Köker, M. A. (2024). Bilgi Erişimi Destekli Üretim (RAG). alikoker.com.tr. https://alikoker.com.tr/rag - BibTeX: https://alikoker.com.tr/rag.bib - RIS: https://alikoker.com.tr/rag.ris - CSL-JSON: https://alikoker.com.tr/rag.csl.json