GraphRAG mı Vektör RAG mı? Üretim İçin Hibrit Router Karar Rehberi (2026)

TL;DR — GraphRAG ile klasik vektör tabanlı RAG arasındaki seçim, 2026'da kurumsal ekiplerin en geç fark ettiği mimari kararlardan biri. Çok adımlı (multi-hop) sorularda GraphRAG kurumsal kıyaslamalarda %86 doğruluğa ulaşırken vektör RAG %32'de kalıyor; ama basit anlamsal aramada ikisi neredeyse eşit performans veriyor ve grafik katmanı sadece maliyet ekliyor. Doğru cevap çoğu şirket için ne saf vektör ne saf grafik: vektör + BM25 + re-ranker temelli, gerektiğinde seçici grafik zenginleştirmesi yapan bir hibrit yönlendirici (router). Bu yazıda iki mimarinin nerede parladığını, Türkçe ve KVKK bağlamında neye dikkat etmek gerektiğini ve üretimde işe yarayan bir karar çerçevesini sahadan anlatıyorum.

Danışmanlıklarımda tekrarlayan bir sahne var: ekip bir RAG sistemi kurar, birkaç ay güzel çalışır, sonra "modelimiz aptallaştı" şikâyeti gelir. Model aptallaşmaz; sorular zorlaşır. Kullanıcılar önce "X belgesinde ne yazıyor?" diye sorar — vektör araması bunu rahat çözer. Sonra "X projesindeki gecikmenin Y tedarikçisindeki soruna ve Z sözleşmesindeki cezaya etkisi ne?" diye sorarlar. İşte burada vektör araması çöker, çünkü bu bir benzerlik değil, bir ilişki sorusudur.

Vektör RAG anlamsal benzerliğe bakar: metinleri gömer, sorguya en yakın parçaları getirir. Ama "A, C üzerinden B'ye bağlı" gibi yapısal bir zinciri, A ve C tamamen farklı kelimelerle anlatılıyorsa bulamaz. GraphRAG ise benzerliğe değil, yapısal bağlantılara bakar: bir bilgi grafiği üzerinde düğümden düğüme yürür. İşte bu yüzden çok adımlı sorularda arayı bu kadar açıyor.

Geç fark edilmesinin sebebi basit: proje başlarken sorular kolaydır. Sistem üretime girip kullanıcılar gerçek, karmaşık sorular sormaya başladığında iş işten geçmiş olur ve mimariyi baştan kurmak gerekir. Bu yüzden bu kararı bugünden, henüz tasarım masasındayken vermek çok daha ucuz.

Vektör RAG nasıl çalışır? Belgeleri parçalara (chunk) böler, her parçayı bir embedding modeliyle vektöre çevirir, bir vektör veritabanına yazar. Sorgu geldiğinde onu da vektöre çevirir ve en yakın parçaları benzerlik skoruna göre getirir. Getirilen parçalar prompt'a iliştirilir, LLM cevabı üretir. Basit, hızlı, olgun. Ekosistemi zengin: Qdrant, Weaviate, pgvector, Milvus.

GraphRAG nasıl çalışır? Belgelerden varlıkları (entity) ve ilişkileri çıkarır, bir bilgi grafiği (knowledge graph) inşa eder. Sorgu geldiğinde grafik üzerinde ilgili düğümleri bulur ve bağlantılı düğümlere yürüyerek (traversal) bir alt-grafik toplar. Bu alt-grafik, aralarındaki ilişkilerle birlikte LLM'e verilir. Microsoft GraphRAG, Neo4j'nin LLM entegrasyonları, FalkorDB ve Amazon Neptune Analytics bu alanı üretime hazır hale getirdi.

"

Kritik gözlem: Grafik geçişi anlamsal benzerliği umursamaz; yapısal bağlantıları takip eder. Eğer A varlığı, C varlığı üzerinden B'ye bağlıysa, A ve C hakkındaki metinler tamamen farklı kelimeler kullansa bile GraphRAG o zinciri getirebilir. Vektör RAG bunu yapamaz.

Kurumsal kıyaslamalar net bir tablo çiziyor. Çok adımlı görevlerde GraphRAG %86, vektör RAG %32 doğruluk veriyor. Ama basit anlamsal aramada — "X konusunu tartışan belgeleri bul" — ikisi karşılaştırılabilir performans veriyor ve grafik, faydasız bir ek yük getiriyor.

Buradan çıkan ders "GraphRAG daha iyi" değil. Ders şu: soru tipiniz mimarinizi belirler. Sorularınızın çoğu tek adımlı, belge-içi ise vektör RAG hem daha ucuz hem yeterli. Sorularınız ilişkisel, çok kaynağı birleştiren, "şunun şuna etkisi ne" tipindeyse grafik katmanı yatırımı geri döner.

Kriter	Vektör RAG	GraphRAG
Basit anlamsal arama	Mükemmel	İyi (gereksiz yük)
Çok adımlı ilişki sorusu	Zayıf (%32)	Güçlü (%86)
Kurulum maliyeti	Düşük	Yüksek (entity/ilişki çıkarımı)
Bakım	Kolay	Zor (grafik güncelleme)
Olgunluk	Çok olgun	Olgunlaşıyor (<%15 kurumsal üretimde)
Açıklanabilirlik	Orta (kaynak parça)	Yüksek (ilişki zinciri görünür)

Dikkat çekici bir veri: 2025 itibarıyla kurumsal şirketlerin %15'inden azı grafik tabanlı getirmeyi üretimde kullanıyor. Bu, GraphRAG'in hâlâ erken benimseme aşamasında olduğunu gösteriyor — ama aynı zamanda doğru kullanan için bir farklılaşma fırsatı.

Ne saf vektör ne saf grafik, çoğu kurumsal senaryonun doğru cevabı değil. Doğru cevap akıllı bir hibrit yönlendirici. Şöyle çalışır:

1. Sorgu gelir, bir sınıflandırıcı (küçük bir LLM ya da kural tabanlı) sorunun tipini belirler.
2. Basit anlamsal sorularda vektör + BM25 + re-ranker hattına gider.
3. Bilinen çok adımlı desenlerde (ilişki, zincir, etki analizi) seçici grafik zenginleştirmesi devreye girer.
4. Sonuçlar birleştirilir ve LLM'e verilir.

Bu yaklaşımın güzelliği kademeli olması. Önce sağlam bir vektör tabanı kurarsınız (vektör + anahtar kelime BM25 + re-ranker — bu üçlü zaten çoğu üretim sistemi için doğru başlangıç). Sistemi düzgün enstrümante edersiniz. Hangi soru sınıfının başarısız olduğunu ölçersiniz. Ve grafik altyapısını sadece ölçümün yapısal sebeplerle başarısızlık gösterdiği yere eklersiniz.

Yani grafik, "havalı olduğu için" değil, "ölçüm gerektirdiği için" eklenir. Sahada gördüğüm en pahalı hata, daha ölçüm bile yokken tüm belge tabanını bir bilgi grafiğine çevirmeye çalışan ekipler. Aylar harcanır, maliyet katlanır ve çoğu sorgu zaten vektörle çözülebilirdi.

GraphRAG'in kalbi entity ve ilişki çıkarımı. Bu, İngilizce için görece olgun ama Türkçe için ekstra dikkat gerektiriyor. Türkçenin eklemeli (agglutinative) yapısı, varlık isimlerinin çekim ekleriyle değişmesi (Ahmet'in, Ahmet'e, Ahmet'ten) ve büyük harf kurallarının farklılığı, entity çözümlemeyi (entity resolution) zorlaştırıyor. "İş Bankası" ile "İş Bankası'nın" aynı düğüm olmalı; naif bir çıkarımcı bunları ayrı düğümler yapar ve grafik parçalanır.

Pratik çözüm: entity çıkarımını Türkçe destekli güçlü bir LLM ile yapmak ve bir normalizasyon (canonicalization) katmanı eklemek. Çıkarılan her varlığı standart bir forma indirgemek. Bu ekstra adım, Türkçe GraphRAG'in vektör RAG'e göre kurulum maliyetini daha da artırır — ki bu da hibrit yaklaşımı Türkiye'de daha da mantıklı kılıyor: grafiği sadece gerçekten gerektiren, yüksek değerli sorgu sınıflarına ayırın.

Vektör tarafında da Türkçe önemli. Türkçe metinlerde iyi çalışan çok dilli embedding modelleri (örneğin BGE-M3 gibi güçlü çok dilli modeller) seçmek, re-ranker'ın Türkçe cümle yapısını anlaması ve chunking'in Türkçe cümle sınırlarını doğru kesmesi, sistemin temel kalitesini belirliyor.

Bilgi grafiği, kişisel veriler açısından özel bir risk taşır ve bunu çok az ekip düşünür. Vektör tabanında bir kişinin verisi dağınık parçalarda durur. Grafikte ise aynı kişi bir düğüm olur ve tüm ilişkileri — kiminle, hangi işlemde, hangi bağlamda — o düğümün etrafında toplanır. Bu, KVKK açısından bir profilleme yoğunlaşması yaratır.

Somut bir örnek: müşteri hizmetleri belgelerinden kurulan bir grafik, farkında olmadan bir müşterinin tüm şikâyetlerini, sağlık referanslarını, finansal durumunu tek bir düğümde birleştirebilir. Bu, veri minimizasyonu ilkesiyle çelişebilir ve bir "özel nitelikli veri" yoğunlaşması doğurabilir.

"

Grafik kurarken sadece "hangi ilişkileri çıkarabilirim" diye değil, "hangi ilişkileri çıkarmamalıyım" diye de sormak gerekir. KVKK'da amaç sınırlaması, grafik tasarımında bir mühendislik kısıtına dönüşür.

Pratik önlemler: kişisel veri içeren düğümlerde erişim kontrolü, hassas ilişki tiplerini grafikten hariç tutma, ve grafik üzerinde sorgulanan verinin de loglanıp denetlenmesi. Grafik güçlü bir araç ama gücüyle orantılı bir sorumluluk getiriyor.

Masaya oturduğunuzda şu sıralamayı öneriyorum:

1. Soru envanteri çıkarın. Kullanıcılarınızın gerçekte sorduğu (ya da soracağı) soruları toplayın ve sınıflandırın: tek-adımlı belge-içi mi, çok-adımlı ilişkisel mi? Bu dağılım, kararınızın temeli.

2. Vektör tabanıyla başlayın. Vektör + BM25 + re-ranker. Bu üçlü, çoğu sistemin %70-80'ini zaten çözer. Hızlı kurulur, ucuzdur, olgundur.

3. Enstrümante edin. Hangi sorguların başarısız olduğunu ölçün. Başarısızlıkların yapısal (ilişki gerektiren) mi yoksa başka sebeplerden mi (kötü chunking, zayıf embedding) olduğunu ayırın.

4. Yapısal başarısızlık varsa grafik ekleyin. Ve sadece o soru sınıfına. Tüm tabanı grafiğe çevirmeyin; grafik zenginleştirmesini seçici uygulayın.

5. Hibrit yönlendiriciyi kurun. Sorguyu tipine göre doğru hatta yönlendiren bir sınıflandırıcı. Bu, iki dünyanın en iyisini birleştirir.

Bu çerçevenin özü şu: kararı ideolojik değil, ampirik yapın. "GraphRAG geleceğin teknolojisi" ya da "vektör yeterli" gibi genellemeler değil, sizin ölçümünüz karar versin.

Hata 1 — Ölçmeden grafiğe atlamak. En yaygın ve en pahalı hata. Grafik altyapısı, ölçüm bir ihtiyaç gösterdiğinde eklenir.

Hata 2 — Re-ranker'ı atlamak. Vektör tarafında re-ranker eklemeden "vektör yetmiyor, grafiğe geçelim" demek. Çoğu zaman iyi bir re-ranker, grafiğe gitmeden sorunu çözer.

Hata 3 — Grafiği canlı tutmamak. Grafik statik değil. Belgeler değiştikçe grafik güncellenmeli. Bu bakım yükü sıklıkla hafife alınır ve grafik zamanla bayatlar.

Hata 4 — Türkçe entity normalizasyonunu atlamak. Çekim ekleri yüzünden parçalanan bir grafik, hiç grafik olmamasından beter olabilir çünkü yanlış ilişkiler üretir.

Türkiye'de bir üretim şirketiyle çalışırken tam bu ikilemi yaşadık. Teknik dokümantasyon üzerinde bir asistan kuruyorduk. İlk sürüm saf vektördü ve "şu parçanın spesifikasyonu ne?" sorularını mükemmel çözüyordu. Sonra saha ekibi "şu arıza, hangi alt-bileşenlerden hangi bakım geçmişine bağlı?" diye sormaya başladı — klasik çok adımlı ilişki sorusu.

Tüm dokümantasyonu grafiğe çevirmek yerine, sadece bileşen-arıza-bakım ilişkilerini bir grafiğe çıkardık ve bir yönlendirici kurduk. Spesifikasyon soruları vektöre, arıza-zincir soruları grafiğe gitti. Sonuç: çok adımlı soru doğruluğu belirgin biçimde arttı, maliyet ise tüm tabanı grafiğe çevirmeye kıyasla küçük bir kesirde kaldı. Ders yine aynı: seçici grafik, topyekûn grafikten hem ucuz hem etkili.

RAG sisteminiz varsa, bu hafta içinde bir soru envanteri çıkarın ve sorularınızın ne kadarının ilişkisel olduğunu ölçün. Eğer çoğu tek adımlıysa, enerjinizi vektör tabanını iyileştirmeye — daha iyi chunking, daha iyi embedding, mutlaka bir re-ranker — verin. İlişkisel soruların payı yüksekse, tüm tabanı değil, sadece o soru sınıfını hedefleyen bir grafik pilotu başlatın.

GraphRAG heyecan verici bir teknoloji ve doğru yerde kullanıldığında gerçekten dönüştürücü. Ama sahada öğrendiğim en sağlam ilke şu: mimariyi hype değil, ölçüm belirlemeli. Sağlam bir vektör tabanı kurun, düzgün enstrümante edin, başarısızlık sınıfını tespit edin ve grafiği yalnızca ölçümün gösterdiği yere ekleyin. Bu disiplin, hem bütçenizi hem de kullanıcı memnuniyetinizi korur. Kararı geç değil, tasarım masasındayken verin — çünkü bu kararı geç almanın bedeli, sistemi baştan kurmaktır.

RAG tartışmalarında grafik mi vektör mü sorusu öne çıkar ama sahada sistemlerin başarısını en çok belirleyen şey aslında chunking — yani belgelerin nasıl parçalandığı. Kötü chunking, en pahalı embedding modelini bile işe yaramaz hale getirir. Bir cümlenin ortasından kesilen, bağlamı kopmuş bir parça, ne kadar iyi gömülürse gömülsün yanlış getirilir.

İyi chunking için birkaç ilke: parçaları anlamsal sınırlarda (paragraf, başlık, madde) kesin, sabit token sayısında körlemesine değil. Parçalar arasında bir miktar örtüşme (overlap) bırakın ki sınırda kalan bilgi kaybolmasın. Ve her parçaya, ait olduğu belgenin başlığını, bölümünü ve tarihini metadata olarak ekleyin. Bu metadata hem filtreleme hem re-ranking için altın değerinde.

2026'da yaygınlaşan bir teknik de contextual retrieval (bağlamsal getirme): her parçaya, o parçanın belge içindeki bağlamını özetleyen kısa bir cümle eklemek. Örneğin bir mali tablo parçasının başına "Bu, ABC şirketinin 2025 Q3 gelir tablosudur" cümlesini eklemek, o parçanın izole edildiğinde bile anlamlı kalmasını sağlar. Bu küçük ek, getirme doğruluğunu belirgin biçimde artırır ve çoğu zaman grafiğe gitmeden yapısal olmayan başarısızlıkları çözer.

Vektör aramasının bir zaafı var: getirdiği ilk sonuçlar her zaman en alakalı sonuçlar olmayabilir. Embedding benzerliği kaba bir sinyaldir. İşte burada re-ranker devreye girer: vektör aramasının getirdiği ilk 20-50 parçayı alır ve sorguyla gerçek alakasına göre yeniden sıralar. Bu ikinci geçiş, çapraz-kodlayıcı (cross-encoder) mimarisi sayesinde çok daha hassas.

Neden bu kadar önemli? Çünkü LLM'e verdiğiniz ilk 5 parça sonucu belirler. Re-ranker, "doğru cevap 12. sırada gizli" durumunu "doğru cevap 2. sırada" durumuna çevirir. Sahada gördüğüm birçok "vektör yetmiyor" şikâyeti, aslında bir re-ranker eksikliğiydi. Grafiğe geçmeden önce mutlaka bir re-ranker deneyin — hem çok daha ucuz hem çoğu zaman yeterli.

Bir üretim hattının olgun hali şöyle görünür: sorgu → hybrid arama (vektör + BM25) → ilk 50 aday → re-ranker → ilk 5 → LLM. Bu hat, grafiksiz haliyle bile birçok kurumsal senaryoyu çözer. Grafik, ancak bu hattın yapısal sebeplerle başarısız olduğu yerde devreye girmeli.

Şunu net söyleyeyim: bazı alanlar grafik için doğuştan uygun. Bir soru envanteri çıkardığınızda aşağıdaki desenler baskınsa, grafik yatırımı erken bile mantıklı olabilir:

İlaç ve yaşam bilimleri. Molekül-hedef-hastalık-yayın ilişkileri doğal olarak grafik. "Bu bileşiğin şu hedefe etkisini gösteren, şu yan etkiyi raporlamış çalışmalar hangileri?" tam bir çok adımlı grafik sorusu.

Finans ve uyum. Şirket-iştirak-yönetici-işlem ilişkileri. Kara para aklama tespiti, gerçek fayda sahibi (UBO) analizi, birbirine bağlı taraf işlemleri — hepsi ilişkisel.

Üretim ve bakım. Bileşen-arıza-bakım-tedarikçi zincirleri. Yukarıdaki vakada anlattığım tam da bu.

Hukuk. Dava-emsal-madde-taraf ilişkileri. Bir emsalin başka hangi kararları etkilediği, bir maddenin hangi davalarda nasıl yorumlandığı — grafik burada parlar.

Bu alanlarda bile tavsiyem aynı: tüm tabanı değil, ilişkisel soru sınıfını grafiğe çıkarın ve bir yönlendiriciyle vektör tabanına bağlayın. Saf grafik neredeyse hiçbir zaman doğru cevap değil; hibrit neredeyse her zaman.

Mimari kararı sadece doğrulukla değil, maliyet ve gecikmeyle de vermek gerekir. GraphRAG'in gizli maliyetleri var: entity/ilişki çıkarımı için LLM çağrıları (kurulum ve güncelleme sırasında), grafik veritabanı işletme maliyeti ve sorgu zamanında ek geçiş süresi. Vektör RAG genelde daha düşük gecikmeli ve daha öngörülebilir maliyetli.

Bir hibrit sistemde yönlendirici, maliyeti de yönetir: sorguların çoğu ucuz vektör hattına gider, sadece gerçekten gereken azınlık pahalı grafik hattına. Bu, hem kaliteyi hem bütçeyi optimize eder. Ölçüm olmadan tüm sorguları grafiğe göndermek, hem yavaş hem pahalı bir sistem yaratır — ve çoğu sorgu için hiçbir fayda getirmez.

Bir de değerlendirme (eval) maliyeti var. GraphRAG'i doğru kurmak, çıkarılan ilişkilerin doğruluğunu değerlendirmeyi gerektirir. Yanlış çıkarılmış bir ilişki, grafiğe yanlış bir "gerçek" olarak yerleşir ve tüm çok adımlı cevapları zehirler. Bu yüzden grafik kuran ekibin, ilişki çıkarım kalitesini sürekli ölçen bir eval hattı olmalı.

Hangi mimariyi seçerseniz seçin, bir değerlendirme (eval) hattı olmadan kör uçuyorsunuz demektir. "Model aptallaştı" şikâyetini objektif olarak yanıtlamanın tek yolu, gerçek sorulardan oluşan bir test setine karşı düzenli ölçüm yapmak.

Pratik bir eval seti şunları içerir: gerçek kullanıcı sorularından örneklenmiş 100-200 soru, her sorunun beklenen cevabı ya da beklenen kaynak parçaları, ve bir puanlama mekanizması (getirme doğruluğu, cevap sadakati, alaka). Bu seti hem vektör hem hibrit hem grafik kurulumlarında koşturursanız, karar artık ideolojik değil, sayısal olur. "Grafiğe geçelim mi?" sorusunun cevabı, bu setteki çok adımlı soruların vektörle kaç puan, grafikle kaç puan aldığıdır.

"

Sahadan en net tavsiyem: eval hattını mimari kararından önce kurun. Çünkü eval olmadan hangi mimarinin daha iyi olduğunu bilemezsiniz; sadece tahmin edersiniz. Ve tahmin, üretim sistemlerinde pahalı bir para birimidir.

Yazıyı bir karar ağacına indirgeyeyim, çünkü çoğu ekibin ihtiyacı bu.

• Sorularınızın çoğu tek-adımlı, belge-içi mi? → Vektör + BM25 + re-ranker. Grafiğe gerek yok.
• Vektör tabanınız var ama bazı sorular başarısız mı? → Önce chunking ve re-ranker'ı iyileştirin. Başarısızlık hâlâ varsa, sebebini ölçün.
• Başarısızlıklar yapısal (ilişki gerektiren) mi? → O soru sınıfı için seçici grafik + hibrit yönlendirici.
• Başarısızlıklar yapısal değil mi (kötü getirme, halüsinasyon)? → Grafik çözmez. Chunking, embedding, re-ranker, prompt ve eval'a dönün.
• Alanınız doğal olarak ilişkisel mi (ilaç, finans, hukuk, bakım)? → Grafiği daha erken düşünebilirsiniz ama yine seçici ve hibrit.

Bu ağaç, "GraphRAG mı vektör mü" sorusunu bir inanç meselesi olmaktan çıkarıp bir mühendislik kararına çeviriyor. Ve mühendislik kararlarının en iyi hakemi ölçümdür.

RAG dünyasında yeni teknolojiler her ay çıkıyor ve her biri "her şeyi çözer" diye pazarlanıyor. Sahada 2026'da öğrendiğim en kalıcı ders şu: sağlam bir vektör tabanı, iyi chunking, mutlaka bir re-ranker ve bir eval hattı — bu dört şey çoğu sistemin başarısını belirler. Grafik, bu temelin üzerine, ölçümün gösterdiği yere, seçici olarak eklenir. Temeli atlayıp grafiğe koşan ekip, en pahalı yoldan en yavaş sonuca ulaşır. Temeli sağlam atan ekip ise grafiğe hiç ihtiyaç duymadan çoğu sorunu çözer, ihtiyaç duyduğunda da tam yerine, tam dozunda ekler.

Teoriyi bırakıp yönlendiricinin nasıl kurulduğuna bakalım, çünkü çoğu ekip burada takılıyor. Yönlendirici, gelen sorguyu doğru getirme hattına yönlendiren küçük bir karar katmanı. İki yaygın yaklaşım var.

Kural tabanlı yönlendirici. En basit hali. Sorguda belirli anahtar kelimeler ya da desenler varsa (örneğin "etkisi", "bağlantısı", "hangi X'e bağlı Y") grafiğe, yoksa vektöre gider. Kurulumu kolay, hata ayıklaması kolay, öngörülebilir. Küçük ekipler için ideal başlangıç. Zaafı: dil çeşitliliğini yakalamakta zorlanır, özellikle Türkçenin esnek cümle yapısında.

LLM tabanlı yönlendirici. Küçük ve hızlı bir modele sorguyu verip "bu tek-adımlı bir bilgi sorusu mu, yoksa çok-adımlı bir ilişki sorusu mu?" diye sorarsınız. Model bir etiket döner, siz o etikete göre yönlendirirsiniz. Daha esnek, dil çeşitliliğini daha iyi yakalar, ama her sorguya küçük bir gecikme ve maliyet ekler. Çoğu üretim sistemi için bu ek maliyet, yanlış hatta gitmenin maliyetinden çok daha düşük.

Sahada iyi çalışan bir desen, ikisini birleştirmek: hızlı kural tabanlı bir ön eleme, belirsiz kalan sorgular için LLM tabanlı bir ikinci kademe. Böylece basit sorgular ucuz kuralla anında yönlenir, sadece belirsiz azınlık pahalı LLM kararına gider.

Yönlendiricinin bir de "geri düşme" (fallback) stratejisi olmalı. Grafik hattı boş sonuç dönerse ya da düşük güven skoru verirse, sistem otomatik olarak vektör hattını da denemeli ve sonuçları birleştirmeli. Tek hatta kilitlenmek, o hat başarısız olduğunda tüm cevabı riske atar. İyi bir hibrit sistem, hatlar arasında zarif geçiş yapar.

Sistemi enstrümante ederken hangi metriklere bakmalı? En kritik dördü şunlar. Getirme doğruluğu (retrieval accuracy): getirilen parçalar gerçekten cevabı içeriyor mu? Bu, tüm zincirin temeli — getirme yanlışsa LLM ne kadar iyi olursa olsun cevap yanlış olur. Cevap sadakati (faithfulness): LLM'in cevabı, getirilen kaynaklara dayanıyor mu, yoksa halüsinasyon mu ekliyor? Alaka (relevance): cevap gerçekten sorulan soruya mı cevap veriyor? Gecikme ve maliyet: kabul edilebilir sınırlarda mı?

Bu dört metriği soru sınıfına göre ayrı ayrı ölçmek, altın değerinde bir içgörü verir. Belki vektör hattınız tek-adımlı sorularda mükemmel ama çok-adımlıda %30'da. İşte tam olarak grafiği nereye ekleyeceğinizi bu ayrıştırma söyler. Toplam ortalama bir puan yanıltıcıdır; sınıf bazlı ölçüm gerçeği gösterir.

GraphRAG ile vektör RAG arasındaki seçim, aslında bir "ya o ya bu" sorusu değil, bir "ne kadar, nerede" sorusu. Doğru cevap neredeyse her zaman hibrit: sağlam bir vektör tabanı üzerine, ölçümün gösterdiği yere seçici grafik. Bu kararı ideolojiyle değil, kendi sisteminizin verileriyle verin.

Somut bir eylem planıyla bitireyim. Bu hafta bir soru envanteri çıkarın ve sorularınızı tek-adımlı/çok-adımlı diye etiketleyin. Bir eval seti kurun — 100-200 gerçek soru yeter. Vektör + BM25 + re-ranker hattını kurun ve eval'da ölçün. Çok-adımlı sorularda başarısızlık görüyorsanız, o sınıf için küçük bir grafik pilotu başlatın ve yine eval'da karşılaştırın. Rakamlar size yolu gösterecek. Bu disiplini kuran ekip, RAG dünyasının her ay değişen hype'ından etkilenmeden, kendi kullanıcısının gerçek ihtiyacına göre sağlam bir sistem kurar. Ve sonunda önemli olan tek şey budur: kullanıcının sorusuna doğru, kaynaklı, hızlı cevap.

Ekiplerin en sık düştüğü tuzak, en yeni ve en karmaşık mimariyi seçmenin daha "profesyonel" görüneceği yanılgısı. Oysa üretimde en sağlam sistemler genellikle en sade olanlardır. İyi kurulmuş bir vektör + BM25 + re-ranker hattı, kötü kurulmuş bir bilgi grafiğinden her zaman daha iyidir. Karmaşıklık, ancak ölçülebilir bir fayda getiriyorsa değerlidir; getirmiyorsa sadece bakım yükü ve hata yüzeyidir. Sahada gördüğüm en zarif sistemler, gösterişten uzak, ölçüme dayalı ve ihtiyaç oldukça büyüyen sistemler oldu. Siz de mimarinizi bir vitrin gibi değil, bir alet çantası gibi düşünün: her araç bir işe yarar, ama hepsini aynı anda kullanmak zorunda değilsiniz. Doğru araç, doğru soru için, doğru zamanda. Pusulanız her zaman ölçüm olsun, moda değil.