GraphRAG Rehberi: Bilgi Grafikleri Vector RAG'ı Ne Zaman Yener (Ve Ne Zaman Yenemez)

GraphRAG Rehberi: Bilgi Grafikleri Vector RAG'ı Ne Zaman Yener (Ve Ne Zaman Yenemez)

GraphRAG ölmedi, ama artık varsayılan seçenek de değil. microsoft/graphrag 18 Temmuz 2026'da v3.1.1 sürümünü yayınladı ve 35.088 GitHub yıldızına ulaştı; üstelik 2026 tarihli üç benchmark makalesi artık açık açık, sade vector erişimine sık sık yenildiğini raporluyor. Bu yüzden bu GraphRAG rehberi geriye kalan tek soruyu yanıtlıyor: bir bilgi grafiği, indeksleme faturasına değer mi?

GraphRAG Kullanmalı mısınız? Kısa Yanıt

GraphRAG'i sorularınız varlıklar arasında geçiş yapıyorsa ya da tüm külliyatı kapsıyorsa kullanın; "en büyük müşterimiz hangi tedarikçilere aynı zamanda satış yapıyor?" sorusu gibi. Tek atlamalı bilgi aramaları, sık değişen dokümanlar ve dar gecikme bütçeleri için sade ya da hibrit RAG'da kalın. Graf, çok atlamalı sorularda kendini amorti eder; geri kalan her yerde para kaybettirir.

GraphRAG ölmedi ve varsayılan da değil. Sorularınız çok atlamalı ya da külliyat genelinde olduğunda indeksleme faturasını hak eder; olmadığındaysa para kaybettirir.

Kısa versiyon:

• GraphRAG çok atlamalı ve külliyat geneli sorularda kazanır; sade RAG tek atlamalı aramalarda kazanır.
• 2026 benchmark'ları karışık: graflar toplulaştırmaya yardımcı oluyor ama ince taneli özetlemeye zarar verebiliyor.
• Maliyet sorgu anında değil, indeksleme anında, LLM çıkarım çağrılarında ortaya çıkar.
• Herhangi bir şey inşa etmeden önce kendi külliyatınızda Basic Search'ü kontrol grubu olarak çalıştırın.

Halihazırda çalışan bir vector RAG pipeline'ınız varsa, tek karar üzerine eklenen grafın kendini amorti edip etmediğidir. Aşağıdaki tablo tüm argümanı altı satırda özetler ve "sade RAG'da kalın" dediği yerler, satıcıların itiraf ettiğinden daha sık verilen dürüst yanıttır. Hibrit BM25 artı vector erişimi bu durumların çoğunu hiç graf olmadan karşılar.

GraphRAG Aslında Nedir: Parçalardan Topluluklara

GraphRAG, birbirinden kopuk parçalar yerine bir bilgi grafiği üzerinde yapılan erişim destekli üretmedir (retrieval-augmented generation). İndeksleme anında bir LLM dokümanlarınızdan varlıkları ve ilişkileri çıkarır, Leiden algoritması bu varlıkları topluluklara kümeleştirir ve her topluluk bir özet alır. Sorgu anında ise graf ve bu özetler, parçalar üzerinde bir top_k penceresinin yapısal olarak yanıtlayamayacağı soruları yanıtlar.

Pipeline, uçtan uca:

Documents
  |
  v
Chunks --> LLM entity + relationship extraction
  |
  v
Knowledge graph (entities = nodes, relations = edges)
  |
  v
Leiden community detection --> community summaries
  |
  v
Vector index over entity + community descriptions

İşi iki aşama yapar. İndeksleme aşaması pahalı olanıdır: her parça, varlıkların ve ilişkilerin çıkarılması için bir LLM çağrısına mal olur ve topluluk özetleri bunun üstüne ek çağrılar gerektirir. Sorgu aşaması, getirinin göründüğü yerdir. Graf ilişkileri açıkça sakladığı için, "en büyük müşterimiz hangi tedarikçilere satış yapıyor?" gibi bir soru, doğru iki parçanın aynı top_k penceresine düşmesi umuduna değil bir graf gezinmesine dönüşür.

Özetler önemlidir, çünkü Global Search'ün gerçekte okuduğu şey onlardır: külliyat geneli sorular, ham parçalardan değil önceden yazılmış topluluk metinlerinden yanıtlanır. Ve her kenar bir LLM yargısıdır; gerçek bir graf veritabanında Cypher ile sorgulayabileceğiniz bir üçlü (triple) olarak saklanır. Bu tasarım, aynı zamanda maliyete neden indekslemenin hakim olduğunun da açıklamasıdır; aşağıdaki sayılar bunu somutlaştırıyor.

Yerini hak eden çerçeve şu: sade RAG pasajları getirir, GraphRAG yapıyı getirir. Embedding modeli seçiminiz vector katmanı için hâlâ önemlidir ve vector veritabanınız açıklamaları saklamaya devam eder; ama yükü taşıyan yeni parça graftır. Resmî Index Overview dokümanları her aşamayı tüm ayrıntısıyla anlatır.

Dört GraphRAG Sorgu Yöntemi Nelerdir?

GraphRAG sorgu motoru dört yöntemle gelir: Local Search, Global Search, DRIFT Search ve Basic Search. Local Search belirli varlıklardan dışa doğru akıl yürütür, Global Search topluluk özetlerini tüm külliyat genelinde toplulaştırır, DRIFT Search ikisini özyinelemeli olarak harmanlar ve Basic Search sade bir vector taban çizgisidir. Beşinci bir özellik olan Question Generation (soru üretme), motorun yanında değil üstünde konumlanır.

30 Temmuz 2026'da microsoft.github.io/graphrag/query/overview/ adresindeki canlı dokümanları kontrol ettik ve sayı dört. Sıralama rehberlerinin çoğu iki ya da üç sayar. Aynı kontrol, hem Index hem Query özet sayfalarında "lazy" kelimesini sıfır kez buldu; bu, aşağıdaki maliyet bölümü için önemli.

Dikkatinizi hak eden satır sonuncusu. Basic Search, yerleşik sade vector taban çizgisidir ve var olma nedeni, grafı kendi külliyatınızda sade erişime karşı A/B testine sokup grafın faturasını hak edip etmediğini öğrenmenizdir. Bu önemsiz bir ayrıntı değil; bu rehberin tüm karar prosedürünün tek özelliğe sığmış halidir. Önce Basic Search'ü çalıştırın. Local, Global ya da DRIFT search size gerçekte sorulan sorularda onu geçemiyorsa, graf bir yükseltme değil bir maliyettir.

2026 Benchmark'ları Aslında Ne Gösterdi?

2026 tarihli üç benchmark makalesi, GraphRAG'ın çok atlamalı ve çok olgulu toplulaştırma görevlerinde işe yaradığını, ama başka yerlerde sık sık sade RAG'ın gerisinde kaldığını buluyor. Bunlardan biri, grafların nerede kaybettiğini bulmak için özel olarak bir benchmark inşa ediyor. Üçü de kazancın külliyat büyüklüğüne değil soru türüne bağlı olduğunda hemfikir. Kanıtlar GraphRAG'ın duruma bağlı olduğunu söylüyor, varsayılan olmadığını.

Dördüncü bir çalışma, GraphRAG-Bench (depo), dokuz GraphRAG yöntemini 16 disiplin ve 20 ders kitabı genelinde değerlendiriyor ve aynı sonuca daha geniş bir açıdan ulaşıyor.

Üç makale de tek bir noktada buluşuyor: graf, maliyetini çok atlamalı toplulaştırmada çıkarıyor ve ince taneli hatırlamada kaybediyor.

Bizim okumamız: zararı hype döngüsü verdi ve bu makaleler düzeltmedir. Hiçbiri grafların işe yaramaz olduğunu söylemiyor. Tutarlı biçimde söyledikleri şu: GraphRAG'ı külliyat geneli temalarda iyi yapan toplulaştırma adımı, ince taneli ayrıntıyı bulanıklaştıran adımın ta kendisi. WildGraphBench en net örnek: graflar orta sayıda kaynaktan çok olgulu toplulaştırmaya yardım etti ve aynı değerlendirmede özetleme kesinliğine zarar verdi. Bu bir çelişki değil; aynı mekanizmanın iki kez ortaya çıkması.

Pratik sonucu şu: buna yalnızca literatürden karar veremezsiniz. Makaleler size hangi soru türlerini test edeceğinizi söyler, külliyatınızın onlardan biri olup olmadığını değil. Yukarıdaki yöntemler bölümündeki Basic Search kontrolü tam olarak bunun içindir.

GraphRAG Ne Kadar Maliyetli? (Ve Herkesin Yanlış Tekrarladığı LazyGraphRAG Uyarısı)

GraphRAG'ın maliyeti bir indeksleme zamanı faturasıdır, sorgu zamanı faturası değil; insanları şaşırtması tam da bu yüzdendir. Her parçadan varlıkları ve ilişkileri çıkaran LLM çağrıları ve üstüne gelen topluluk özetleme geçişi, onu pahalı yapan şeydir. Ödemeyi, tek bir sorgu çalışmadan önce peşin yaparsınız. Sorgu zamanı daha ucuzdur ama bedava değildir: Global Search topluluk özetlerine topluluk başına bir LLM çağrısıyla yayılır; yukarıdaki yöntemler tablosunun onu yüksek işaretlemesinin nedeni budur.

Kamuya açık tek somut sayılar Microsoft Research'ten geliyor. 25 Kasım 2024'te ekip, LazyGraphRAG'ın indeksleme maliyetinin vector RAG ile aynı ve tam GraphRAG maliyetinin %0,1'i olduğunu ve GraphRAG global search sorgu maliyetinin %4'üyle, hem yerel hem küresel sorgu türlerinde test edilen rakip yöntemleri geride bıraktığını bildirdi (Microsoft Research). Bunlar Microsoft'un kendi blogundan Microsoft'un rakamlarıdır ve biz de öyle aktarıyoruz; fiyatlandırılmış kendi indeksimizi çalıştırmadık.

Yazıların çoğunun kaçırdığı düzeltme şu. LazyGraphRAG bir pip install seçeneği değildir. Microsoft'un 6 Haziran 2025 tarihli kendi editör notuna göre, açık kaynak pakete değil Microsoft Discovery ve Azure Local'a gönderildi. 30 Temmuz 2026'da resmî Index Overview ve Query Overview sayfalarını kontrol ettik: "lazy" kelimesi ikisinde de sıfır kez geçiyor. Yani bir rehber LazyGraphRAG'ı bu öğleden sonra ayağa kaldırabileceğiniz bir varyant olarak listeliyorsa, açık kaynak dünyasında artık doğru olmayan bir iddiayı tekrarlıyordur.

Bugün yapabilecekleriniz: çıkarım modelini yerel çalıştırmak. İndeksleme adımını Ollama üzerinden yerel bir modele yönlendirmek, en pahalı aşamadan token başına API ücretlerini kaldırır ve onu kendi barındırdığınız bir vector deposuyla eşleştirmek faturanın geri kalanını sıfıra yakın tutar.

Hangi GraphRAG Kütüphanesi Gerçekten Bakım Alıyor?

En çok atıf alan altı GraphRAG kütüphanesinden ikisi altı ve dokuz aydır push almadı. Bu rakamları 30 Temmuz 2026'da GitHub API'sinden çektik ve aşağıdaki sayım, eski derlemelerin atladığı kontroldür; birine bağlanmadan önce yeniden çalıştırma komutuyla birlikte. LightRAG ve microsoft/graphrag aktif olanlar; nano-graphrag ve fast-graphrag terk edilmiş yazılıma doğru sürükleniyor.

for r in HKUDS/LightRAG microsoft/graphrag getzep/graphiti neo4j/neo4j-graphrag-python gusye1234/nano-graphrag circlemind-ai/fast-graphrag; do gh api "repos/$r" --jq '.full_name,.stargazers_count,.pushed_at,.open_issues_count'; done

Bizim okumamız: yıldız bir gösteriş metriğidir; asıl sayı push tarihidir. LightRAG ve microsoft/graphrag ikisi de aktif bakım alıyor, Graphiti zamansal graf açısıyla hemen arkalarında. nano-graphrag ve fast-graphrag, eski yazıların hâlâ yalnızca itibar üzerinden önerdiği iki kütüphane ve ikisi de yarım yıldır sürüm yayınlamadı.

Nasıl seçilir: dört resmî sorgu yöntemiyle referans uygulamayı istiyorsanız microsoft/graphrag, en aktif projeyi ve daha hafif bir ayak izini istiyorsanız LightRAG ve zaten o satıcının veritabanını çalıştırıyorsanız neo4j-graphrag-python gibi satıcı bakımlı bir kütüphane seçin. Son push'u projenizden yarım yıl öncesine dayanan her şeyden kaçının.

Graphiti tek bir kapsam notunu hak ediyor: zamansal graf tasarımı, zaman farkında veri üzerinde erişim için inşa edildi ve ajan belleğiyle örtüşüyor; bunu Graphiti ve zamansal graf belleği rehberimizde ayrı ele alıyoruz. Daha geniş alan için RAG araç ekosisteminin geneline bakın.

200. Günden Sonra Ne Bozulur: Graf Sapması ve Yeniden Çıkarım

Graf sapması, lansmandan sonra ödediğiniz vergidir ve uygulayıcıların bir numaralı itirazı olmasının bir nedeni var. Her eğitim grafiği, grafı bir kez inşa ettiğiniz bir şey gibi gösterir. Gerçek ekipler 200. günde takılır.

Üç şey çürür. Birincisi, doküman güncellemelerinde yeniden indeksleme. 40 doküman değiştiğinde onları yalnızca yeniden gömemezsiniz; değişen parçalarda LLM çıkarımını yeniden çalıştırmanız, yeni varlıkları eski grafla uzlaştırmanız ve etkilenen toplulukları ve özetlerini yeniden hesaplamanız gerekir. Bir Medium rehberi artımlı güncellemeyi kolay diye anar. r/Rag'deki uygulayıcılar katılmıyor. Yaklaşık 600 doküman üzerinde BM25 artı BGE-M3 çalıştıran 25 Nisan 2026 tarihli bir başlığın sahibi açık konuşuyor: "LLM tabanlı varlık/ilişki çıkarımı gürültülü ve doküman güncellemelerinde yeniden indekslemek acı verici görünüyor."

İkincisi, varlık çözümleme çürümesi. "Acme Corp", "Acme" ve "ACME Corporation" aylar arayla farklı dokümanlarda gelir ve tek bir düğüm olması gerekirken üç düğüme bölünür. Hiçbir şey onları otomatik birleştirmez.

Üçüncüsü, çıkarım anında doğru olan ve sessizce doğru olmaktan çıkan ilişkiler. Bir reports_to kenarı bayatladığında kimse uyarı almaz.

def on_documents_changed(changed_docs):
    stale = find_affected_nodes(changed_docs)
    re_extract(changed_docs)
    reconcile_entities(stale)
    recompute_communities(affected_only=True)
    re_summarize(affected_communities)

Kod tabanı en kötü durumdur ve en ilginci de odur. Otomatik tamamlama artık "graphrag for codebase", "graphrag claude code" ve "graphrag mcp server" öneriyor ve bir kod tabanı saatlik değişen bir graftır: her commit çağrı kenarlarını yeniden yazar, sembolleri taşır ve fonksiyonları siler. Bu, hiçbir gecelik yeniden indekslemenin tam izleyemeyeceği bir takvimde graf sapmasıdır. Ciddi kod grafı araçlarının kenarlar için tree-sitter ve LSP gibi belirleyici ayrıştırıcılara yaslanıp LLM'i çevresindeki metne ayırmasının nedeni de budur: docstring'ler, commit mesajları, inceleme başlıkları. Bir depoyu grafa döküyorsanız, yavaş değişen katmanı LLM ile, hızlı değişeni ayrıştırıcıyla grafa dökün.

Geliştiriciler GraphRAG Hakkında Gerçekte Ne Diyor?

Çalışan geliştiriciler bölünmüş durumda ve Google bunu biliyor görünüyor: bir Reddit başlığı "graphrag vs rag" aramasında ikinci sırada; bu, arama motorunun size bu konunun satıcı metni değil meslektaş görüşü istediğini söylemesidir.

Şüphecilik gerçek. r/Rag'in 2024 tarihli başlığında "Would you always recommend (knowledge) graph RAG over normal RAG?" (10 puan, %86 olumlu) u/EncartaIt şöyle yazdı: "Bulduğum eğitimlerin hepsi aşırı basitleştirilmiş ve bilgi grafiği deseni için güçlü bir gerekçe sunmıyor." u/Prestigious_Run_4049 daha sertti: "Bence graph rag sadece hype. İnsanlar hakkında konuşmayı seviyor ve kulağa havalı geliyor ama kimse gerçek kullanım durumlarında kullanmıyor." Herkes katılmıyor. Prodüksiyon deneyimiyle tartışan u/pytheryx, graf erişiminin top_k'nın döndürdüğünden daha fazla parçadan bağlam gerektiren liste tipi sorularda kazandığını not etti; onun teknik doküman külliyatı tam bir yanıt için yaklaşık 50 parça gerektiriyor.

2026 başlığı daha ölçülü. u/Popular_Sand2773: "Çoğu graph rag kurulumu ölçekte hile yapıyor. Tohum düğümleri bulmak için standart bir vector ya da meta veri araması çalıştırıyorsunuz, sonra etrafta dolaşıyorsunuz." Yaklaşık 300 milyon artefaktlık bir sistem çalıştıran u/ggone20: "Ölçekte, gerçek soruları yanıtlamak için onlarsız kelimenin tam anlamıyla yaşayamazsınız."

Bizim okumamız her iki başlıktaki en keskin argümanla örtüşüyor: kırılma noktası, külliyatınızın büyüklüğü değil sorularınızın karmaşıklığıdır. Yukarıdaki benchmark'ların bulduğu da budur ve bu yüzden aracı çok atlamalı işe kapsamlayan uygulayıcıların yanındayız, onu ölü ilan edenlerin değil.

Techsy Bu Konuya Nasıl Yaklaşıyor

Müşteri projelerinde kullandığımız sıralama şu ve bilerek sıkıcı.

Önce, hibrit erişimin tavanını kanıtlayın. Duyduğumuz "grafa ihtiyacımız var" isteklerinin çoğu aslında kılık değiştirmiş bir parçalama ya da yeniden sıralama sorunudur. İyi bir yeniden sıralayıcıya sahip bir BM25 artı vector pipeline'ı, ekiplerin beklediğinden fazlasını yanıtlar.

İkincisi, herhangi bir şey inşa etmeden önce Basic Search'ü kendi külliyatınızda kontrol grubu olarak çalıştırın. Dördüncü sorgu yöntemi tam olarak bunun için var: grafı, kendi verinizde, kendi sorularınızla A/B testine sokabileceğiniz sade bir vector taban çizgisi.

Üçüncüsü, grafı yalnızca ölçülmüş bir soru sınıfı o kontrolde başarısız olduğunda inşa edin. Çok atlamalı ya da külliyat geneli sorgular ıskalıyorsa, elinizde gerçek bir gerekçe var. Iskalamıyorsa, kendinizi bir indeksleme faturasından ve bir sapma sorunundan kurtardınız demektir.

Erişim yığınınıza ikinci bir göz mü gerekiyor? Ücretsiz danışmanlık alın.

Sık Sorulan Sorular

GraphRAG nasıl çalışır?

GraphRAG dokümanlarınızı bir bilgi grafiğine indeksler. Bir LLM her parçadan varlıkları ve ilişkileri çıkarır, Leiden algoritması bu varlıkları topluluklara kümeleştirir ve her topluluk bir özet alır. Sorgu anında motor grafı ve bu özetleri arar; böylece farklı parçalarda duran olguları birbirine bağlayabilir.

GraphRAG, RAG'den nasıl farklıdır?

Standart RAG en benzer top-k parçayı getirir ve modele besler. GraphRAG yapıyı getirir: varlıkları, aralarındaki ilişkileri ve önceden yazılmış topluluk özetlerini. Çok atlamalı ve külliyat geneli soruları yanıtlamasını sağlayan bu ek yapıdır ve indekslemeyi daha yavaş ve pahalı yapan da odur.

GraphRAG'i ne zaman kullanmalıyım?

Sorularınız varlıklar arasında geçiş yapıyorsa ya da tüm külliyatı kapsıyorsa kullanın; tedarikçi örtüşmesi soruları ya da binlerce doküman üzerinde tekrarlayan tema analizi gibi. Tek atlamalı bilgi aramaları, hızlı değişen külliyatlar ve dar gecikme ya da maliyet bütçeleri için atlayın. Sade bir hibrit pipeline bir soru sınıfını zaten yanıtlıyorsa, graf değer katmadan maliyet ekler.

GraphRAG öldü mü?

Hayır, ama varsayılan da değil. 2026 benchmark'ları, gündelik görevlerde sık sık sade RAG'ın gerisinde kaldığını gösteriyor ve hype'ı bitiren de bu; ama çok atlamalı ve toplulaştırma sorularında hâlâ kazanıyor. Dürüst çerçeve duruma bağlı olandır: GraphRAG doğru soru türlerinde maliyetini karşılar, geri kalanında para kaybettirir.

GraphRAG sorgu yöntemleri nelerdir?

Resmî sorgu motoru dört yöntemle gelir: varlık merkezli sorular için Local Search, külliyat geneli toplulaştırma için Global Search, ikisinin özyinelemeli harmanı için DRIFT Search ve sade vector erişimi için Basic Search. Beşinci bir özellik olan Question Generation üstte konumlanır. En önemlisi Basic Search'tür: grafı A/B testine soktuğunuz kontrol grubudur.

GraphRAG indeksleme ne kadara mal olur?

Maliyet indeksleme anında ortaya çıkar; her parçadan varlık ve ilişki çıkaran LLM çağrılarında ve topluluk özetlemesinde. Microsoft Research, LazyGraphRAG indekslemesini tam GraphRAG maliyetinin %0,1'i ve vector RAG ile aynı olarak bildirdi; ama bu varyant açık kaynak kütüphaneye değil Microsoft ürünlerine gönderildi. Fiyatlandırılmış kendi indeksimizi çalıştırmadık.

GraphRAG'i Ollama ile yerel olarak çalıştırabilir miyim?

Evet. microsoft/graphrag kütüphanesi, indekslemeyi ve sorgulamayı Ollama'nın sunduğu yerel bir modele yönlendirmenize izin verir; bu da çıkarım adımından token başına API ücretlerini kaldırır. Maliyet karşılığında hız ve kaliteden ödün verirsiniz: yerel modeller varlık çıkarımında daha zayıftır, bu yüzden daha gürültülü graflar ve mütevazı donanımda daha uzun indeks süreleri bekleyin.

LightRAG mi Microsoft GraphRAG mi daha iyi?

Farklı şeyler için optimize edilirler. LightRAG (38.353 yıldız, 30 Temmuz 2026 push) en aktifi ve çalıştırması daha hafif; microsoft/graphrag (35.088 yıldız, v3.1.1) dört resmî sorgu yöntemiyle referans uygulama. Verimli bir prodüksiyon grafı için LightRAG'ı, şartnameye sadık davranış ve Basic Search kontrolü için Microsoft'unkini seçin.

GraphRAG'i kim, ne zaman geliştirdi?

GraphRAG'i Microsoft Research geliştirdi. Ekip makaleyi 2024'te yayınladı ve MIT lisansı altında açık kaynak microsoft/graphrag deposunu sürdürüyor; dokümanlar microsoft.github.io/graphrag adresinde. Referans kütüphane 18 Temmuz 2026'da v3.1.1'e ulaştı ve çevresinde LightRAG ve Graphiti dahil aktif bir üçüncü taraf uygulamaları ekosistemi büyüdü.

Karar: Graf Maliyetini Ne Zaman Karşılar

Kanıtlar tek bir yönü gösteriyor, işte pozisyonumuz.

• GraphRAG ölmedi. Duruma bağlıdır ve 2026 benchmark'ları bunu açıkça söylüyor.
• İndeksleme faturasını çok atlamalı varlık sorularında ve külliyat geneli toplulaştırmada hak eder. Tek atlamalı aramalarda para kaybettirir.
• Maliyet bir indeksleme zamanı faturasıdır ve herkesin alıntıladığı ucuz varyant LazyGraphRAG açık kaynak kütüphaneye hiç ulaşmadı.
• Graf lansmandan sonra çürür: varlık çözümleme sapar ve ilişkiler bayatlar; bu yüzden yeniden indekslemeye bütçe ayırın.
• Herhangi bir şey inşa etmeden önce Basic Search'ü kendi külliyatınızda kontrol grubu olarak çalıştırın.

Tek cümle: bir bilgi grafiği maliyetini karşılar, ama yalnızca sorularınız çok atlamalı ya da külliyat geneli olduğunda; öncesinde değil. Erişim yığınınıza ikinci bir görüş isterseniz, ücretsiz danışmanlık alın.