GraphRAG mı, Vektör RAG mı? 2026'da Üretim İçin Doğru Retrieval Mimarisini Seçmek

TL;DR — Vektör RAG ölmedi, hâlâ vakaların büyük çoğunluğunda en doğru başlangıç noktası. Ama "neden", "nasıl bağlantılı", "kim kiminle ilişkili" tarzı çok adımlı sorularda klasik vektör arama duvara toslar; işte GraphRAG tam burada devreye giriyor. 2026'da sahada gördüğüm gerçek şu: kazanan mimari çoğu zaman ikisinden biri değil, hibrit bir kurgu. Bu yazıda vektör RAG ile GraphRAG'i üretim gözüyle karşılaştırıyor, contextual retrieval ve reranking gibi "ucuz ama çok kazandıran" katmanları konuşuyor, maliyet/karmaşıklık dengesini açıyor ve sonunda kendi projenizde hangisini seçeceğinizi netleştiren bir karar çerçevesi bırakıyorum. KVKK ve on-prem tarafını da atlamıyorum.

Son iki yılda Türkiye'de onlarca kurumda RAG projelerine girdim; bankadan sigortaya, üretimden kamuya. Ve neredeyse her "yapay zekâmız saçmalıyor" şikâyetinin altından aynı şey çıktı: model değil, retrieval bozuk. İnsanlar genelde modeli suçluyor, daha büyük bir LLM'e geçmeyi konuşuyor, prompt'u on kez yeniden yazıyor. Oysa sorunun kaynağı, modele yanlış ya da eksik bağlam veriliyor olması. Çöp girince çöp çıkıyor.

Bu yüzden "GraphRAG mı, vektör RAG mı?" sorusunu bir teknoloji modası tartışması olarak değil, çok somut bir mühendislik kararı olarak ele almak istiyorum. Çünkü doğru retrieval mimarisini seçmek, projenizin başarısıyla aylarca süren bir hayal kırıklığı arasındaki farkı belirliyor. Ve bu kararı verirken kimse size "her şeye GraphRAG kur" ya da "vektör yeter, gerisi hava" dememeli. Gerçek, her zamanki gibi, ortada bir yerde.

Klasik vektör RAG'i kabaca şöyle düşünün: belgelerinizi anlamlı parçalara (chunk) bölüyorsunuz, her parçayı bir embedding modeliyle sayısal bir vektöre çeviriyorsunuz, bunları bir vektör veritabanına (Qdrant, Weaviate, pgvector, Milvus gibi) yazıyorsunuz. Kullanıcı soru sorduğunda, sorunun da vektörünü çıkarıp en yakın komşuları buluyor ve o parçaları modele bağlam olarak veriyorsunuz. Anlamsal benzerlik üzerinden çalışan, sezgisel ve olgunlaşmış bir yöntem.

Neden hâlâ varsayılan? Çünkü basit, ucuz ve şaşırtıcı derecede iyi. Tek bir belgede cevabı net yazan sorular -ki kurumsal soruların belki yüzde yetmişi böyledir- için fazlasıyla yeterli. "İzin yönetmeliğine göre yıllık izin kaç gün?", "Şu ürünün garanti süresi nedir?", "Fatura itiraz süreci nasıl işliyor?" gibi sorularda vektör RAG harika çalışır. Altyapısı hazır, ekosistemi olgun, operasyonu öğrenmesi kolay. Bir projeye başlarken benim ilk önerim neredeyse her zaman temiz bir vektör RAG kurmaktır; çünkü yüzde seksenlik değeri yüzde yirmilik çabayla verir.

"

Sahadan bir kural: Eğer henüz düzgün bir vektör RAG'iniz çalışmıyorsa, GraphRAG'i konuşmak için çok erken. Önce temeli sağlamlaştırın.

Mesele şu ki, vektör arama "benzerlik" bulur ama "ilişki" kuramaz. İşte tam burada işler kritikleşiyor. Birkaç tipik kırılma noktası:

Çok adımlı (multi-hop) sorular. "X tedarikçisinin bağlı olduğu holdingin geçen yıl ceza aldığı projeler hangileri?" gibi bir soru, cevabı tek bir chunk'ta bulunmayan, birden çok belgeyi zincirleyerek birleştirmeyi gerektiren bir sorudur. Vektör arama her bir parçaya tek tek bakar; aradaki köprüyü kuramaz. Sonuç: model elindeki yarım malzemeyle uydurmaya başlar.

Bütünsel / küresel sorular. "Bu 400 sayfalık denetim raporunun ana temaları neler?" dediğinizde, cevap herhangi bir tek parçada yoktur; tüm külliyatın özetlenmesini gerektirir. Vektör arama "en yakın 10 parça"yı getirir ama bunlar bütünü temsil etmeyebilir.

Varlık merkezli sorgular. Aynı kişi, ürün ya da sözleşme onlarca belgede farklı isimlerle geçiyorsa, vektör benzerliği bu dağınık izleri tek bir kimlik altında toplayamaz. "Ahmet Yılmaz" bir yerde "A. Yılmaz", başka yerde sadece "müdür bey" olarak geçiyorsa, ilişki kopar.

Çelişki ve zaman boyutu. İki belge birbiriyle çelişiyorsa ya da bir politika güncellenmişse, vektör arama hangisinin güncel olduğunu bilmez; ikisini de aynı anda getirip modeli yanıltabilir.

Bu listeyi gördüğünüzde fark ediyorsunuz: sorun "daha iyi embedding" değil, "yapı eksikliği". Bilginin arasındaki bağlantılar bir yerde temsil edilmiyor.

GraphRAG'in temel fikri şu: belgelerden sadece metin parçaları değil, varlıkları (kişiler, kurumlar, ürünler, kavramlar) ve bunlar arasındaki ilişkileri de çıkarıp bir bilgi grafiğinde (knowledge graph) saklamak. Yani "Ahmet Yılmaz → yöneticisidir → X Projesi → bağlıdır → Y Holding" gibi düğüm ve kenarlardan oluşan bir ağ kuruyorsunuz. Sorgu geldiğinde, sadece benzer metni değil, ilgili düğümden başlayıp grafikte gezerek bağlantılı bilgiyi de topluyorsunuz.

Microsoft'un GraphRAG yaklaşımının popülerleştirdiği bir incelik daha var: grafiği topluluklara (community) ayırıp her topluluk için önceden özetler üretmek. Böylece "global" sorularda -bütünsel temalar, genel eğilimler- model, tek tek parçalar yerine bu hazır topluluk özetlerini kullanabiliyor. Bu, vektör RAG'in en zorlandığı bütünsel soru tipini doğrudan hedef alıyor.

GraphRAG'in gerçek gücü üç yerde ortaya çıkıyor: çok adımlı akıl yürütme, varlıkların tutarlı şekilde birleştirilmesi (entity resolution) ve cevabın hangi ilişki zincirinden geldiğinin izlenebilir olması. Bu son nokta -açıklanabilirlik- özellikle düzenlemeye tabi sektörlerde küçümsenmemeli. Bir denetçiye "model neden bu cevabı verdi" diye sorulduğunda, grafik üzerinden gidilen yolu göstermek, bir vektör benzerlik skorundan çok daha ikna edici.

Burada birçok ekibin tökezlediği yere geliyorum. GraphRAG kulağa harika geliyor, demolar etkileyici, ama üretime taşıdığınızda faturayı görüyorsunuz. Açık konuşalım:

İndeksleme maliyeti. Grafiği kurmak için her belgeden varlık ve ilişki çıkarmanız gerekiyor; bu da genelde bir LLM ile yapılıyor. Yani binlerce belgeyi LLM'den geçiriyorsunuz; bu hem token maliyeti hem zaman demek. Vektör RAG'de embedding üretmek görece çok ucuzken, graph extraction kat kat pahalı olabiliyor.

Bakım ve güncelleme. Belgeler değiştiğinde grafiği tutarlı tutmak, çakışan varlıkları çözmek, yanlış çıkarılmış ilişkileri temizlemek sürekli emek ister. Vektör veritabanında bir chunk'ı güncellemek tek bir işlemken, grafikte bir değişiklik domino etkisi yapabilir.

Karmaşıklık ve ekip becerisi. Graph veritabanı (Neo4j gibi), şema tasarımı, sorgu dili, entity resolution mantığı... Bunlar ekibinize yeni bir öğrenme yükü getirir. Türkiye'de graph ile rahat çalışabilen mühendis havuzu vektör tarafına göre hâlâ dar; bunu işe alım ve sürdürülebilirlik açısından göz ardı etmeyin.

Çıkarım kalitesine bağımlılık. Grafik, onu kuran LLM'in çıkardığı varlıklar kadar iyidir. Kötü çıkarım, baştan yanlış bir harita çizer ve siz o yanlış harita üzerinde gezinirsiniz. Bu, "çöp girer çöp çıkar" sorununun daha sinsi bir versiyonudur.

Net rakam vermekten kaçınıyorum çünkü her senaryo farklı, ama niteliksel olarak şunu rahatlıkla söyleyebilirim: GraphRAG'in toplam sahip olma maliyeti, vektör RAG'in belirgin biçimde üzerindedir. Bu maliyete değip değmeyeceği, tamamen sorularınızın doğasına bağlı.

Sahada en çok işe yarayan kurgu çoğu zaman saf graph ya da saf vektör değil, ikisinin birleşimi. Mantık şu: vektörle geniş bir aday havuzu çekersiniz (recall yüksek), sonra grafikle bu adayların ilişkisel bağlamını zenginleştirir ya da multi-hop gereken kısmı grafiğe sorarsınız. Çoğu modern üretim sistemi pratikte böyle melez çalışıyor.

Hibrit yaklaşımın güzel yanı, kademeli benimsenebilmesi. Önce sağlam bir vektör RAG kurarsınız. Sonra hangi soru tiplerinin başarısız olduğunu ölçer, yalnızca o tipler için grafik katmanı eklersiniz. Yani tüm korpusu grafiğe taşımak yerine, en çok değer üreten alt kümeyi grafikleştirirsiniz. Bu, hem maliyeti kontrol eder hem de karmaşıklığı sindirilebilir tutar.

"

Tavsiyem: "ya hep ya hiç" tuzağına düşmeyin. RAG mimarisi bir anahtar değil, bir kadrandır. Vektörden hibride, oradan graph-ağırlıklıya doğru kademeli ilerleyin.

GraphRAG'e atlamadan önce, vektör RAG'inizden çok daha fazlasını sıkıp çıkaran iki teknik var ki bunları görmezden gelmek günah. Çünkü düşük maliyetle, hızlıca, ciddi kalite artışı veriyorlar.

Contextual retrieval. Klasik chunking'in en büyük derdi, parçaların bağlamından kopması. "Bu oran yüzde 12 arttı" diyen bir chunk, hangi yıl, hangi ürün, hangi bölge belli değilse işe yaramaz. Contextual retrieval'da, her chunk'ı indekslemeden önce, ait olduğu belgenin bağlamını özetleyen kısa bir açıklama ekliyorsunuz. Yani parçayı kendi başına anlamlı hâle getiriyorsunuz. Bu basit müdahale, retrieval isabetini çoğu zaman dramatik biçimde yükseltir ve graph'a göre kurması çok daha kolaydır.

Reranking. Vektör arama size 50 aday getirsin; ama bunların hepsi eşit kalitede değil. Bir reranker modeli (cross-encoder mantığıyla çalışan), soru ile her adayı birlikte değerlendirip gerçek alaka düzeyine göre yeniden sıralar. İlk aşamada geniş tutup (recall), reranking ile daraltmak (precision), retrieval kalitesini yükseltmenin en yüksek getirili adımlarından biridir. Çoğu ekip bunu atlıyor ve sonra "model halüsinasyon yapıyor" diye dert yanıyor.

Şunu net söyleyeyim: GraphRAG'e harcayacağınız bütçenin bir kısmını önce contextual retrieval ve reranking'e ayırın. Çoğu projede bu iki katman, ilişkisel olmayan sorularda graph kurmadan da ihtiyacınızın büyük kısmını karşılar.

Boyut	Vektör RAG	GraphRAG	Hibrit
Tek belgede cevaplanan sorular	Çok iyi	Aşırıya kaçar	İyi
Çok adımlı (multi-hop) akıl yürütme	Zayıf	Çok iyi	Çok iyi
Bütünsel / global özet soruları	Zayıf	İyi	İyi
Varlık çözümleme (entity resolution)	Zayıf	Çok iyi	İyi
Kurulum kolaylığı	Çok kolay	Zor	Orta
İndeksleme maliyeti	Düşük	Yüksek	Orta
Bakım yükü	Düşük	Yüksek	Orta
Açıklanabilirlik	Orta	Yüksek	Yüksek
Ekip öğrenme eğrisi	Düşük	Yüksek	Orta

Bu tabloyu bir reçete değil, bir pusula olarak okuyun. Asıl iş, kendi soru dağılımınızı tanımakta.

Mimari seçimini "hangisi havalı" üzerinden yapamazsınız; ölçmek zorundasınız. Ben sahada şu disiplini öneriyorum:

Önce gerçek kullanıcı sorularından oluşan bir değerlendirme seti çıkarın. Hayalî değil, sahadan. Bu setteki her soruyu tipine göre etiketleyin: tek-belge mi, multi-hop mu, global özet mi? Sonra retrieval'ı iki ayrı düzeyde ölçün. Birincisi, doğru belge/parça getirildi mi (retrieval kalitesi: recall, precision, MRR gibi). İkincisi, üretilen cevap doğru, dayanaklı ve halüsinasyonsuz mu (cevap kalitesi: faithfulness, answer relevance, context precision). RAGAS gibi araçlar bu ikinci katman için işinizi kolaylaştırır.

İşin püf noktası: her soru tipini ayrı ayrı raporlayın. Toplam ortalama sizi yanıltır. Bakarsınız genel skor iyi ama multi-hop sorularda sistem yerlerde sürünüyor. İşte o ayrıştırılmış tablo size GraphRAG'in nerede gerçekten gerekli olduğunu gösterir. Eğer multi-hop ve global sorular soru hacminizin küçük bir kısmıysa, graph kurmak yerine o vakaları farklı ele almak daha akıllıca olabilir.

"

Ölçmeden mimari kararı vermek, pusulasız denize açılmaktır. Bir hafta harcayıp düzgün bir eval seti kurmak, aylarca yanlış mimaride debelenmekten ucuzdur.

Bu kararı Türkiye'de verirken teknik boyut kadar düzenleyici boyut da masada. KVKK kapsamında, özellikle bankacılık, sigorta, sağlık ve kamuda, kişisel ve hassas verinin yurt dışına çıkması ya da kontrolsüz bir bulut LLM'ine gitmesi ciddi bir risk. Bu, retrieval mimarisi seçimini doğrudan etkiliyor.

İlginç bir nokta şu: GraphRAG, indeksleme aşamasında belgeleri bir LLM'den geçirdiği için, eğer bunu bir dış bulut API'siyle yaparsanız, tüm kurumsal külliyatınızı o sağlayıcıya akıtmış olursunuz. Vektör RAG'de embedding üretimi de benzer bir mahremiyet sorusu doğurur ama hacim ve içerik derinliği genelde daha sınırlıdır. Dolayısıyla hassas veri söz konusuysa, ister vektör ister graph, indeksleme ve çıkarımı on-prem ya da egemen (sovereign) bir kurulumda, yerel açık ağırlıklı modellerle yapmayı ciddi ciddi değerlendirmelisiniz.

Pratikte gördüğüm sağlıklı kurgu şu: hassas veri hiç ayrılmadan, kurum içi GPU'larda barındırılan açık bir model (örneğin güçlü bir açık ağırlıklı LLM) ile hem embedding/extraction hem de yanıt üretimi yapılır. Vektör veritabanı ve varsa graph veritabanı da aynı güvenli ağ içinde durur. Bu kurulum bulut kadar konforlu olmasa da, KVKK uyumu ve veri egemenliği açısından çoğu kurum için tek kabul edilebilir yol. Mimari seçiminizi yaparken "bu bileşeni on-prem koşabilir miyim" sorusunu baştan sorun; sonradan taşımak çok daha acı verici.

Bir konuyu özellikle açmak istiyorum, çünkü GraphRAG'i haklı çıkaran asıl senaryo bu. Multi-hop sorular, cevabın birden çok bilgi parçasının zincirlenmesinden çıktığı sorulardır. "Bu sözleşmedeki gizlilik maddesi, bağlı olduğumuz çerçeve anlaşmanın hangi hükmüyle çelişiyor?" Bu soruyu cevaplamak için önce sözleşmeyi, sonra çerçeve anlaşmayı, sonra ikisi arasındaki ilişkiyi kurmanız gerekir.

Vektör arama burada yapısal olarak yetersiz, çünkü her parçaya bağımsız bakar; "şu parçadan şu parçaya köprü kur" diyemez. Grafikte ise bu köprü zaten bir kenar olarak var. Düğümden düğüme atlayarak ilişki zincirini takip edersiniz. İşte bu yüzden hukuk, uyum (compliance), istihbarat analizi, dolandırıcılık tespiti, tedarik zinciri ilişkileri gibi alanlarda GraphRAG belirgin biçimde öne çıkar. Bu alanların ortak özelliği: cevap tek bir belgede değil, belgeler arasındaki ilişkide saklı.

Ama dikkat: multi-hop ihtiyacınız yoksa, bu gücü kurmak için ödediğiniz bedel boşa gider. Çoğu kurumsal soru aslında tek-hop'tur. Önce kendi soru dağılımınıza bakın.

Şimdi en çok beklenen kısma geldik. Size sahada uyguladığım pratik karar adımlarını bırakıyorum:

Adım 1 — Soru dağılımınızı çıkarın. Gerçek kullanıcı sorularından 100-200 tanesini toplayın ve etiketleyin: tek-belge, multi-hop, global özet, varlık merkezli. Bu dağılım her şeyi belirler. Multi-hop + global oranınız düşükse (diyelim yüzde 15'in altında), büyük olasılıkla graph'a ihtiyacınız yok.

Adım 2 — Temeli kurun ve sıkın. Önce temiz bir vektör RAG. Üstüne contextual retrieval ve reranking ekleyin. Çoğu projede iş burada büyük ölçüde biter. Bunu atlayıp graph'a koşmak, en sık gördüğüm aşırı mühendislik hatası.

Adım 3 — Ölçün ve boşluğu görün. Eval setinizi soru tipine göre ayrıştırarak çalıştırın. Hangi tipler hâlâ başarısız? Eğer başarısızlık özellikle multi-hop ve global sorularda yoğunlaşıyorsa, graph için gerçek bir gerekçeniz var demektir.

Adım 4 — Cerrahi davranın. Tüm korpusu grafiğe taşımayın. Yalnızca ilişkisel sorgu gerektiren alt kümeyi grafikleştirin ve hibrit kurgu kurun. Vektör geniş ağı atar, graph ilişkiyi tamamlar.

Adım 5 — Maliyet ve KVKK'yı baştan koyun. İndeksleme ve çıkarımın on-prem koşulabilirliğini, bakım yükünü ve ekip becerisini karar anında hesaba katın. "Sonra hallederiz" diye ertelenen her şey üretimde size pahalıya patlar.

Bu çerçevenin özü şu: GraphRAG bir varsayılan değil, kanıtlanmış bir ihtiyaca verilen cerrahi bir cevaptır. Önce vektör, sonra ölç, sonra gerekiyorsa graph.

GraphRAG vektör RAG'in yerini alacak mı? Hayır, almayacak. Vektör arama hâlâ retrieval'ın bel kemiği. GraphRAG, vektörün zayıf kaldığı ilişkisel ve bütünsel senaryolarda onu tamamlayan bir katman. Geleceğin üretim sistemleri büyük olasılıkla hibrit olacak; "ya o ya bu" değil.

Küçük bir korpusum var, GraphRAG mantıklı mı? Genelde hayır. Küçük ve görece bağımsız belgelerden oluşan korpuslarda graph'ın getireceği değer, kuruluş ve bakım maliyetini karşılamaz. Graph, belgeler arası zengin ilişkilerin olduğu, geniş ve birbirine bağlı korpuslarda parlar.

Contextual retrieval ve reranking olmadan GraphRAG'e geçmeli miyim? Hayır, önce bu iki ucuz kazancı uygulayın. Çoğu projede ilişkisel olmayan sorunların büyük kısmını çözerler ve graph ihtiyacınızı netleştirirler. Önce kolay ve yüksek getirili olanı yapın.

On-prem GraphRAG kurmak mümkün mü? Evet, tamamen mümkün. Açık ağırlıklı bir LLM ile extraction ve yanıt üretimi, kurum içi bir graph veritabanı (örn. Neo4j) ve yerel vektör deposuyla baştan sona on-prem bir kurulum yapılabilir. KVKK kapsamındaki hassas veri için çoğu zaman tek doğru yol budur, ama GPU ve operasyon maliyetini hesaba katın.

Hangi metrikleri takip etmeliyim? Retrieval düzeyinde recall, precision ve MRR; cevap düzeyinde faithfulness, answer relevance ve context precision. Hepsini soru tipine göre ayrıştırarak raporlayın. Toplam ortalama sizi yanıltır.

Bütün bu tartışmadan sonra size en saf hâliyle söyleyeceğim şey şu: mimari sizi kurtarmaz, disiplin kurtarır. En şık GraphRAG kurgusu bile, kötü chunking, ölçülmemiş kalite ve etiketlenmemiş soru dağılımı üzerine kurulduğunda çöker. Tersine, iyi düşünülmüş, ölçülen, kademeli büyütülen sade bir vektör RAG, çoğu kurumu fazlasıyla mutlu eder.

Pratik harekete geçme planınız şu olsun: Bu hafta gerçek kullanıcı sorularından bir eval seti toplayın ve tiplerine göre etiketleyin. Önümüzdeki iki hafta vektör RAG'inizi kurun ya da elinizdekine contextual retrieval ve reranking ekleyip yeniden ölçün. Sonucu soru tipine göre ayrıştırın. Eğer multi-hop ve global sorularda belirgin bir açık görüyorsanız ve bu sorular işiniz için kritikse, o zaman -ve yalnızca o zaman- hibrit bir graph katmanını cerrahi olarak ekleyin. Maliyet ve KVKK kararını da bu yolculuğun başında, sonuna bırakmadan verin.

Doğru retrieval mimarisi, modaya değil, sizin sorularınıza, verinize ve kısıtlarınıza göre seçilir. Bu yazıdaki çerçeveyi kendi rakamlarınızla doldurduğunuzda, cevabın aslında en başından beri verinizin içinde sizi beklediğini göreceksiniz.

GraphRAG ile vektör RAG arasında gidip gelirken çoğu ekibin gözden kaçırdığı bir gerçek var: retrieval kalitenizin tavanını çoğu zaman embedding modeliniz değil, chunking stratejiniz belirliyor. Belgeyi nasıl parçaladığınız, sonradan ne kadar akıllı arama yaparsanız yapın, ulaşabileceğiniz en iyi sonucu sınırlıyor. Bir cümleyi ortasından kesen, tabloyu satırlara bölen, başlık ile içeriği birbirinden koparan kötü bir chunking, en gelişmiş mimaride bile sizi çıkmaza sokar.

Sahada gördüğüm en sık hata, belgeyi kör bir biçimde sabit token sayısıyla bölmek. Oysa kurumsal belgeler yapısaldır: başlıkları, alt başlıkları, maddeleri, tabloları vardır. Bu yapıyı koruyan, semantik sınırlara saygı gösteren bir chunking, retrieval'ı dramatik biçimde iyileştirir. Tabloları metne çevirmek, başlık bağlamını her parçaya taşımak, çok uzun maddeleri anlamlı alt parçalara bölmek... Bunlar sıkıcı ama getirisi en yüksek işlerdir. GraphRAG'e geçmeden önce chunking'inizi gözden geçirmemek, çatısı sağlam ama temeli çürük bir bina dikmek gibidir.

Bir de şu var: chunking kararı, mimari seçiminizi de etkiler. İyi yapılandırılmış, başlık hiyerarşisi net belgelerde vektör RAG çok daha iyi çalışır; çünkü yapı zaten bir tür örtük grafik sağlar. Yapısı dağınık, ilişkileri metnin içine gömülü belgelerde ise grafik katmanının değeri artar. Yani belge yapınız, hangi mimariye meyletmeniz gerektiği konusunda size erken bir ipucu verir.

Mimari tartışmalarında çoğu zaman doğruluğa odaklanıp gecikmeyi (latency) unutuyoruz. Oysa üretimde kullanıcı, cevabın ne kadar doğru olduğu kadar ne kadar hızlı geldiğiyle de ilgilenir. Burada vektör RAG ile GraphRAG arasında önemli bir fark var. Vektör arama tek bir yakınlık sorgusudur; milisaniyeler sürer. GraphRAG ise grafikte gezinme, çoklu hop, bazen ara LLM çağrıları içerebilir; bu da sorgu başına gecikmeyi artırır.

Bunu üretim kararınızda hesaba katmalısınız. Bir müşteri hizmetleri sohbet botunda saniyeler süren bir gecikme kabul edilemezken, bir hukukçunun derinlemesine araştırma yaptığı bir araçta birkaç saniyelik ek bekleme tamamen makuldür. Yani "hangi mimari" sorusunun cevabı, kullanım senaryosunun hız toleransına da bağlı. Hibrit kurgularda sık uyguladığım bir desen şu: hızlı yol olarak önce vektör araması yapılır, eğer soru multi-hop olarak sınıflandırılırsa ancak o zaman daha yavaş graph yoluna düşülür. Böylece sıradan soruların hızını feda etmeden, karmaşık soruların derinliğini de sunabilirsiniz.

"

Hız bir lükstür sanılır ama değildir; benimsenmeyen bir sistem, ne kadar doğru olursa olsun değersizdir. Latency'yi de bir kalite metriği gibi ölçün.

Türkiye'de pek çok kurumda gördüğüm hazin tablo şu: etkileyici bir pilot kurulur, yönetim heyecanlanır, sonra proje üretime geçemeden sönümlenir. Sebep neredeyse hiçbir zaman modelin yetersizliği değil. Sebep, pilotun gerçek dünyanın dağınıklığını hesaba katmamış olması. Pilotta seçilmiş on temiz belgeyle harika çalışan sistem, on bin gerçek, tutarsız, eski, çelişkili belgeyle karşılaşınca dağılıyor.

Bu yüzden mimari seçimini yaparken ölçek ve veri kalitesini en baştan masaya koymak şart. GraphRAG özellikle bu noktada acımasızdır: kirli veriden kurulan bir grafik, kirli ilişkiler üretir ve bu hatalar tüm sisteme yayılır. Vektör RAG kirli veriye karşı görece daha bağışlayıcıdır, çünkü her parça bağımsızdır; bir parçadaki hata diğerlerine bulaşmaz. Dolayısıyla veri kaliteniz düşükse ve onu kısa vadede düzeltemeyecekseniz, bu da vektör tarafına meyletmek için bir gerekçedir. Graph'ın getirdiği güç, ancak temiz ve tutarlı veriyle gerçek değere dönüşür.

Pilottan üretime geçişin sırrı, baştan üretim koşullarını taklit etmektir: gerçek belgelerin tam çeşitliliği, gerçek kullanıcı sorularının dağınıklığı, gerçek güncelleme sıklığı. Bu koşullarda hangi mimari ayakta kalıyorsa, doğru mimari odur. Laboratuvarda kazanan değil, sahada ayakta kalan.