Klasik Vektör RAG Öldü mü? Karmaşık Kurumsal Verilerde GraphRAG, LazyGraphRAG ve Agentic RAG Mimarilerinin Hesaplaşması

"Hello World" RAG'ın Sonu: Düz Vektör Araması Kurumsal Veride Neden Çöküyor?

2023 ve 2024 yıllarında kurumsal yapay zeka projelerinin standart şablonu son derece basitti: PDF dokümanlarını, şirket içi wiki sayfalarını ve sözleşmeleri 500 tokenlık metin parçalarına (chunks) böl, bir gömme (embedding) modeliyle vektöre dönüştür, vektör veritabanına kaydet ve kullanıcı soru sorduğunda Kosinüs Benzerliği (Cosine Similarity) en yüksek Top-K (genellikle 5 veya 10) parçayı çekip LLM istemine (prompt) yapıştır.

Ancak 2026 üretim ortamı telemetrileri, literatürde "Naive RAG" (Klasik Vektör RAG) olarak adlandırılan bu mimarinin karmaşık kurumsal senaryolarda üç temel yapısal kör noktaya saplandığını kanıtlıyor:

1. Çok-Sıçramalı Muhakeme Körlüğü (Multi-Hop Blindness): "Tedarikçisi X ülkesinde bulunan ve son 2 yılda SLA ihlali yaşayan alt yüklenicilerin etkilediği finansal projeler hangileridir?" gibi bir sorunun cevabı tek bir paragrafta yazmaz. Tedarikçi bilgisi A dokümanında, SLA ihlali B tablosunda, proje etkisi ise C sözleşmesindedir. Vektör araması anlamsal olarak sadece sorunun kelimelerine benzeyen parçaları getirdiği için zincirleme ilişkileri (A → B → C) birleştiremez.
2. Bütüncül Korpus Körlüğü (Global Sensemaking Failure): "Son üç çeyrekteki 40.000 müşteri destek kaydında öne çıkan ana arıza temaları nasıl değişti?" sorusuna Top-10 metin parçasıyla yanıt vermek matematiksel olarak imkansızdır.
3. Bağlam Kırılması (Chunk Fragmentation): Sabit boyutlu parçalama, tabloların başlıklarını satırlarından koparır; hukuki maddelerdeki istisna bentlerini ana hükümden ayırarak tehlikeli halüsinasyonlara yol açar.

Peki klasik RAG gerçekten öldü mü? Hayır; basit bilgi getirme (nokta atışı SSS ve doküman araması) için hala en ucuz temel katman olmayı sürdürüyor. Ancak kurumsal zeka katmanında bayrağı iki devrimsel yaklaşım devraldı: Yapısal Bilgi Grafiği Odaklı GraphRAG / LazyGraphRAG ve Dinamik Kontrol Akışı Odaklı Agentic RAG.

1. GraphRAG ve LazyGraphRAG Mimarisi: Metin Yığınlarından Hiyerarşik Bilgi Galaksilerine

Microsoft Research tarafından öncülük edilen GraphRAG, yapılandırılmamış metinlerin içindeki örtük (implicit) ilişkileri açık bir Bilgi Grafiğine (Knowledge Graph) dönüştürür. Klasik vektör indekslemesinden farklı olarak GraphRAG şu boru hattını işletir:

1. Varlık ve İlişki Çıkarımı (Entity & Edge Extraction): LLM, her metin parçasını tarayarak kişileri, kurumları, mikroservisleri, sözleşme maddelerini (Düğümler / Nodes) ve aralarındaki bağıntıları (Kenarlar / Edges) çıkarır.
2. Leiden Topluluk Algoritması ile Hiyerarşik Kümeleme: Oluşan devasa grafik, Leiden algoritması ile birbirine sıkı sıkıya bağlı alt topluluklara (Communities: Seviye 0, Seviye 1, Seviye 2) ayrılır.
3. Önceden Hesaplanmış Topluluk Özetleri (Community Summaries): Her küme için LLM tarafından kapsamlı bir yönetici özeti üretilir. Bütüncül bir soru geldiğinde sistem tüm dokümanları taramak yerine topluluk özetleri üzerinde Map-Reduce çalıştırarak korpusun tamamını kapsayan kusursuz bir yanıt sentezler.

GraphRAG'ın Maliyet Duvarı ve LazyGraphRAG Devrimi

Standart GraphRAG'ın en büyük yumuşak karnı İndeksleme Maliyetidir (Upfront Indexing Token Burn). 10 GB'lık bir kurumsal veri setinde her paragraf için LLM çağrısı yaparak grafik çıkarmak, klasik vektör indekslemeden 20 ila 40 kat daha pahalıdır ve veri sık değiştiğinde grafiği güncel tutmak ciddi bir darboğaz yaratır.

Bu sorunu çözmek üzere geliştirilen LazyGraphRAG ve LightRAG mimarileri, pahalı LLM özetlemesini indeksleme anından sorgu anına (Query-Time) kaydırır:

• İndeksleme sırasında hiçbir LLM çağrısı yapılmaz; hafif doğal dil işleme (NLP isim öbekleri / noun-phrase extraction) ve birlikte geçme (co-occurrence) istatistikleriyle kavram grafiği klasik vektör RAG ile aynı maliyette (standart GraphRAG'ın %0,1 maliyetine — 1000 kat daha ucuza) inşa edilir.
• LLM yalnızca kullanıcı soru sorduğunda, belirlenen bir "İlgililik Test Bütçesi" (Relevance Test Budget) dahilinde alt grafikleri gezerek yanıt üretir.

2. Agentic RAG Mimarisi: Veri Yapısını Değil, Orkestrasyon Akışını Akıllandırmak

Agentic RAG, verinin nasıl saklandığından ziyade bilginin nasıl arandığına ve doğrulandığına odaklanan özerk bir kontrol döngüsüdür (Control-Flow Architecture). Tek seferlik "Ara ve Üret" (Retrieve-then-Generate) boru hattı yerine; Planlama, Araç Çağırma (Tool-Calling), Öz-Değerlendirme (Self-Reflection) ve Yeniden Yazma adımlarından oluşan çok turlu bir durum makinesi (State Machine) çalıştırır:

• Yönlendirici Ajan (Query Router): Gelen soruyu analiz eder; sorunun cevabı PostgreSQL/SQL veritabanında mı, Elasticsearch tam metin dizininde mi, vektör veritabanında mı yoksa canlı bir REST API'de mi karar verir.
• Corrective RAG (CRAG) ve Self-RAG Döngüsü: Getirilen doküman parçaları bir değerlendirici (Evaluator) model tarafından puanlanır. Eğer getirilen parçalar soruyu yanıtlamak için yetersizse (relevance < 0.75), ajan halüsinasyon üretmek yerine sorguyu yeniden yazar (Query Rewriting) ve farklı parametrelerle ikinci bir arama başlatır.

TypeScript / LangGraph Benzeri Hibrit Agentic + GraphRAG Orkestrasyon Kodu

Aşağıdaki mimari örnek, bir kurumsal sorguyu önce sınıflandırıp ardından hem vektör/grafik aramasını hem de öz-doğrulama (Self-Correction) döngüsünü yürüten üretim kalitesinde bir Agentic RAG akışını göstermektedir:

interface RetrievalChunk {
  sourceId: string;
  content: string;
  relevanceScore: number;
  graphPath?: string[]; // Örn: ["Vendor_A", "SUPPLIES_TO", "Service_Billing", "IMPACTS", "SLA_2026"]
}

export class EnterpriseHybridRagEngine {
  private maxIterations = 3;
  private minConfidenceThreshold = 0.80;

  async executeQuery(userQuery: string): Promise<{ answer: string; citations: string[]; hops: number }> {
    let currentQuery = userQuery;
    let collectedContext: RetrievalChunk[] = [];
    let iteration = 0;

    // 1. Niyet Sınıflandırma: Nokta atışı arama mı, çok-sıçramalı ilişki mi, bütüncül özet mi?
    const queryType = await this.classifyQueryIntent(userQuery); // "POINT" | "MULTI_HOP_GRAPH" | "GLOBAL_SUMMARY"

    while (iteration < this.maxIterations) {
      iteration++;

      // 2. Hibrit Getirme: Sorgu tipine göre Vektör + LazyGraph alt grafik gezintisi
      const newChunks = queryType === "POINT"
        ? await this.vectorHybridSearch(currentQuery)
        : await this.lazyGraphSubgraphTraversal(currentQuery, { budget: 250 });

      // 3. CRAG Değerlendirici: Getirilen parçalar gerçekten kanıt içeriyor mu?
      const gradedChunks = await this.gradeRetrievedEvidence(userQuery, newChunks);
      collectedContext.push(...gradedChunks.filter((c) => c.relevanceScore >= this.minConfidenceThreshold));

      const sufficiency = await this.checkEvidenceSufficiency(userQuery, collectedContext);
      if (sufficiency.isComplete) {
        break;
      }

      // 4. Eksik halka varsa sorguyu eksik varlıklar için yeniden yaz (Multi-Hop Query Expansion)
      currentQuery = sufficiency.rewrittenFollowUpQuery;
    }

    return await this.synthesizeGroundedAnswer(userQuery, collectedContext, iteration);
  }

  private async classifyQueryIntent(q: string): Promise<"POINT" | "MULTI_HOP_GRAPH" | "GLOBAL_SUMMARY"> {
    // Hızlı sınıflandırıcı model ile sorgu rotası belirlenir
    return q.includes("tüm") || q.includes("eğilimler") ? "GLOBAL_SUMMARY" : "MULTI_HOP_GRAPH";
  }

  private async vectorHybridSearch(q: string): Promise<RetrievalChunk[]> { return []; }
  private async lazyGraphSubgraphTraversal(q: string, opts: { budget: number }): Promise<RetrievalChunk[]> { return []; }
  private async gradeRetrievedEvidence(q: string, chunks: RetrievalChunk[]): Promise<RetrievalChunk[]> { return chunks; }
  private async checkEvidenceSufficiency(q: string, ctx: RetrievalChunk[]): Promise<{ isComplete: boolean; rewrittenFollowUpQuery: string }> {
    return { isComplete: true, rewrittenFollowUpQuery: "" };
  }
  private async synthesizeGroundedAnswer(q: string, ctx: RetrievalChunk[], hops: number) {
    return { answer: "Sentezlenen kanıtlı kurumsal yanıt", citations: ctx.map((c) => c.sourceId), hops };
  }
}

3. Üçlü Açmaz (Trilemma) Kıyaslama Matrisi: Maliyet, Gecikme ve Doğruluk

Kurumsal mimaride doğru RAG desenini seçmek bir moda tercihi değil; İndeksleme Maliyeti, Sorgu Başına Gecikme (Latency) ve Çok-Sıçramalı Doğruluk arasındaki mühendislik ödünleşimini yönetmektir:

4. Kurumsal Mimari Karar Rehberi: Hangi Senaryoda Hangisi Seçilmeli?

1. Ne Zaman Klasik Hibrit RAG (BM25 + Dense Vector + Reranker) Yeterlidir?
   • Sorguların %90'ı tek bir belge veya paragraf içinde yanıtlanabiliyorsa (ör. çalışan İK el kitabı, teknik API parametre araması) ve yanıt süresinin 1 saniyenin altında olması şartsa.
2. Ne Zaman GraphRAG / LazyGraphRAG Seçilmelidir?
   • Hukuki sözleşme ağları, tedarik zinciri bağımlılıkları, siber güvenlik tehdit istihbaratı veya tıbbi araştırmalar gibi varlıklar arası görünmeyen bağlantıların hayati olduğu alanlarda. Sık güncellenen veri setlerinde yüksek indeksleme faturasından kaçınmak için doğrudan LazyGraphRAG tercih edilmelidir.
3. Ne Zaman Agentic RAG Seçilmelidir?
   • Sorunun yanıtı yalnızca dokümanlarda değil; aynı anda PostgreSQL tablolarında, Jira biletlerinde ve canlı ERP API'lerinde dağılmışsa. Sistemin kendi kendine SQL sorgusu yazması, gelen veriyi doğrulaması ve eksik kalan kısmı dokümanlardan tamamlaması gerekiyorsa.

Sonuç: Nihai Nokta "Graph-Destekli Agentic RAG" Yakınsamasıdır

2026'da en olgun kurumsal yapay zeka platformları Agentic RAG ile GraphRAG'ı birbirinin rakibi olarak değil, tamamlayıcı iki katman olarak konumlandırıyor: Verinin bellekteki yapısal temsili Vektör + LazyGraphRAG ile modellenirken, bu belleğin üzerinde hangi derinlikte gezileceğine ve hangi canlı kurumsal API'lerin çağrılacağına hafif sıklet bir Agentic Yönlendirici (Router) karar veriyor. Böylece basit sorular 400 milisaniyede ucuza yanıtlanırken, yalnızca karmaşık çok-sıçramalı sorular geldiğinde otonom grafik ve ajan motoru devreye giriyor.