Panduan GraphRAG: Kapan Knowledge Graph Mengalahkan Vector RAG (dan Kapan Tidak)

Panduan GraphRAG: Kapan Knowledge Graph Mengalahkan Vector RAG (dan Kapan Tidak)

GraphRAG belum mati, tapi juga bukan pilihan default. microsoft/graphrag merilis v3.1.1 pada 2026-07-18 dengan 35.088 star GitHub, dan tiga paper benchmark 2026 kini melaporkan secara terbuka bahwa ia sering kalah dari retrieval vektor biasa. Jadi panduan GraphRAG ini menjawab satu-satunya pertanyaan yang tersisa: apakah knowledge graph sepadan dengan biaya indexing-nya?

Haruskah Kamu Memakai GraphRAG? Jawaban Singkatnya

Pakai GraphRAG ketika pertanyaanmu melintasi banyak entitas atau mencakup seluruh korpus, seperti "supplier mana saja yang juga menjadi tempat jual pelanggan terbesar kita?". Untuk pencarian fakta satu hop, dokumen yang cepat berubah, dan budget latensi yang ketat, tetaplah pada RAG vanilla atau hybrid. Graph baru balik modal pada pertanyaan multi-hop, dan di luar itu ia cuma menghabiskan uang.

GraphRAG belum mati dan bukan pula pilihan default. Ia menutup biaya indexing-nya saat pertanyaanmu bersifat multi-hop atau lintas korpus, dan justru rugi saat tidak.

Versi singkatnya:

• GraphRAG menang di pertanyaan multi-hop dan lintas korpus; RAG vanilla menang di pencarian satu hop.
• Benchmark 2026 hasilnya campur aduk: graph membantu agregasi, tapi bisa merusak ringkasan yang detail.
• Biayanya muncul saat indexing, dalam panggilan LLM untuk ekstraksi, bukan saat query.
• Jalankan Basic Search sebagai kontrol di korpusmu sendiri sebelum membangun apa pun.

Kalau kamu sudah punya pipeline vector RAG yang jalan, satu-satunya keputusan adalah apakah graph di atasnya balik modal. Tabel di bawah adalah seluruh argumennya dalam enam baris, dan di bagian yang menyuruhmu tetap di vanilla, itulah jawaban jujurnya, lebih sering daripada yang diakui para vendor. Retrieval hybrid BM25 plus vektor menutupi sebagian besar kasus ini tanpa graph sama sekali.

Apa Sebenarnya GraphRAG: Dari Chunk ke Komunitas

GraphRAG adalah retrieval-augmented generation di atas knowledge graph, bukan di atas chunk yang terpisah-pisah. Saat indexing, sebuah LLM mengekstrak entitas dan relasi dari dokumenmu, algoritma Leiden mengelompokkan entitas itu menjadi komunitas, dan setiap komunitas mendapat ringkasan. Saat query, graph plus ringkasan itu menjawab pertanyaan yang secara struktural tidak bisa dijawab jendela top_k di atas chunk.

Pipeline-nya, dari ujung ke ujung:

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

Dua fase yang melakukan pekerjaan. Fase indexing adalah yang mahal: setiap chunk butuh satu panggilan LLM untuk menarik entitas dan relasi, dan ringkasan komunitas menambah panggilan lagi di atasnya. Fase query adalah tempat hasilnya terlihat. Karena graph menyimpan relasi secara eksplisit, pertanyaan seperti "supplier mana yang juga menjadi tempat jual pelanggan terbesar kita?" menjadi sebuah traversal, bukan harapan bahwa dua chunk yang tepat mendarat di jendela top_k yang sama.

Ringkasan itu penting karena itulah yang sebenarnya dibaca Global Search: pertanyaan lintas korpus dijawab dari prosa komunitas yang sudah ditulis sebelumnya, bukan dari chunk mentah. Dan setiap edge adalah penilaian LLM, disimpan sebagai triple yang bisa kamu query dengan Cypher di graph database sungguhan. Desain itu juga alasan indexing mendominasi biaya, dan angka-angka di bawah membuatnya konkret.

Kerangka yang layak dipakai: RAG vanilla mengambil potongan teks, dan GraphRAG mengambil struktur. Pilihan model embedding-mu tetap penting untuk lapisan vektor, dan vector database-mu tetap menyimpan deskripsinya, tapi graph adalah bagian baru yang menanggung beban. Dokumentasi Index Overview resmi menjelaskan setiap tahap secara lengkap.

Apa Saja Empat Metode Query GraphRAG?

Query engine GraphRAG hadir dengan empat metode: Local Search, Global Search, DRIFT Search, dan Basic Search. Local Search menalar keluar dari entitas tertentu, Global Search mengagregasi ringkasan komunitas di seluruh korpus, DRIFT Search memadukan keduanya secara rekursif, dan Basic Search adalah baseline vektor biasa. Fitur kelima, Question Generation, duduk di atas engine, bukan di sampingnya.

Kami mengecek dokumentasi live di microsoft.github.io/graphrag/query/overview/ pada 2026-07-30, dan jumlahnya empat. Kebanyakan panduan yang ranking cuma menyebut dua atau tiga. Pengecekan yang sama menemukan kata "lazy" nol kali di kedua halaman overview Index dan Query, dan ini penting untuk bagian biaya di bawah.

Baris yang layak kamu perhatikan adalah yang terakhir. Basic Search adalah baseline vektor vanilla bawaan, dan ia ada supaya kamu bisa meng-A/B graph melawan retrieval biasa di korpusmu sendiri dan mengetahui apakah graph benar-benar balik modal. Itu bukan trivia; itu seluruh prosedur keputusan panduan ini dalam satu fitur. Jalankan Basic Search dulu. Kalau Local, Global, atau DRIFT search tidak mengalahkannya pada pertanyaan yang benar-benar kamu terima, graph adalah biaya, bukan upgrade.

Apa yang Sebenarnya Ditemukan Benchmark 2026?

Tiga paper benchmark 2026 menemukan bahwa GraphRAG membantu pada tugas agregasi multi-hop dan multi-fakta, tapi sering kalah dari RAG vanilla di tempat lain. Salah satunya membangun benchmark khusus untuk mencari di mana graph kalah. Ketiganya sepakat bahwa kemenangan bergantung pada tipe pertanyaan, bukan ukuran korpus. Bukti mengatakan GraphRAG itu situasional, bukan default.

Upaya keempat, GraphRAG-Bench (repositori), mengevaluasi sembilan metode GraphRAG lintas 16 disiplin dan 20 buku teks, dan mencapai kesimpulan yang sama dari sudut yang lebih luas.

Ketiga paper konvergen di satu titik: graph menutup biayanya pada agregasi multi-hop dan rugi pada recall yang detail.

Bacaan kami: siklus hype yang membuat kerusakan, dan paper-paper ini adalah koreksinya. Tidak satu pun bilang graph tidak berguna. Yang mereka katakan secara konsisten: langkah agregasi yang membuat GraphRAG jago di tema lintas korpus adalah langkah yang sama yang mengaburkan detail halus. WildGraphBench contoh paling jelas: graph membantu agregasi multi-fakta dari sumber berjumlah sedang, dan merusak presisi ringkasan di evaluasi yang sama. Itu bukan kontradiksi; itu satu mekanisme yang muncul dua kali.

Konsekuensi praktisnya: kamu tidak bisa memutuskannya dari literatur saja. Paper memberi tahu tipe pertanyaan mana yang harus diuji, bukan apakah korpusmu termasuk salah satunya. Untuk itulah kontrol Basic Search dari bagian metode di atas ada.

Berapa Biaya GraphRAG? (Dan Catatan LazyGraphRAG yang Sering Diulang Secara Salah)

Biaya GraphRAG adalah tagihan waktu indexing, bukan waktu query, dan justru karena itu orang kaget. Panggilan LLM yang mengekstrak entitas dan relasi dari setiap chunk, plus tahap ringkasan komunitas, itulah yang membuatnya mahal. Kamu bayar di depan, sebelum satu pun query berjalan. Waktu query lebih murah tapi tidak gratis: Global Search menyebar ke ringkasan komunitas dengan satu panggilan LLM per komunitas, itulah kenapa tabel metode di atas menandainya tinggi.

Satu-satunya angka publik yang keras datang dari Microsoft Research. Pada 2024-11-25 tim melaporkan bahwa biaya indexing LazyGraphRAG identik dengan vector RAG dan 0,1% dari biaya GraphRAG penuh, dan bahwa dengan 4% biaya query global search GraphRAG ia mengungguli metode pesaing yang diuji, pada kedua tipe query lokal dan global (Microsoft Research). Itu angka Microsoft, dari blog Microsoft, dan kami melaporkannya apa adanya; kami belum pernah menjalankan indexing berbayar sendiri.

Ini koreksi yang dilewatkan kebanyakan tulisan. LazyGraphRAG bukan opsi pip install. Menurut catatan editor Microsoft sendiri tertanggal 2025-06-06, ia dirilis ke Microsoft Discovery dan Azure Local, bukan ke paket open-source. Kami mengecek halaman Index Overview dan Query Overview resmi pada 2026-07-30: kata "lazy" muncul nol kali di keduanya. Jadi kalau sebuah panduan mencantumkan LazyGraphRAG sebagai varian yang bisa kamu jalankan sore ini, ia sedang mengulang klaim yang sudah tidak benar di dunia open-source.

Yang bisa kamu lakukan hari ini: menjalankan model ekstraksi secara lokal. Mengarahkan langkah indexing ke model lokal lewat Ollama menghilangkan biaya API per-token dari fase termahal, dan memadukannya dengan vector store self-hosted menjaga sisa tagihan mendekati nol.

Library GraphRAG Mana yang Benar-Benar Dirawat?

Dua dari enam library GraphRAG paling banyak dikutip tidak mendapat push selama enam dan sembilan bulan. Kami menarik angka ini dari GitHub API pada 2026-07-30, dan sensus di bawah adalah pengecekan yang dilewatkan roundup lama, lengkap dengan perintah untuk menjalankannya ulang sebelum kamu berkomitmen pada salah satu. LightRAG dan microsoft/graphrag adalah yang aktif; nano-graphrag dan fast-graphrag sedang meluncur ke abandonware.

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

Bacaan kami: star adalah metrik gengsi; tanggal push adalah angka yang penting. LightRAG dan microsoft/graphrag keduanya dirawat aktif, dengan Graphiti membuntuti di sudut temporal-graph. nano-graphrag dan fast-graphrag adalah dua yang masih direkomendasikan postingan lama bermodalkan reputasi saja, dan keduanya tidak merilis apa pun selama setengah tahun.

Cara memilih: pilih microsoft/graphrag kalau kamu mau implementasi referensi dengan empat metode query resmi, LightRAG kalau kamu mau proyek paling aktif dan jejak yang lebih ringan, dan library yang dirawat vendor seperti neo4j-graphrag-python kalau kamu sudah menjalankan database vendor itu. Hindari apa pun yang push terakhirnya lebih tua setengah tahun dari proyekmu.

Graphiti layak satu catatan berbatas: desain temporal-graph-nya dibangun untuk retrieval di atas data yang sadar waktu, dan ia tumpang tindih dengan memori agen, yang kami bahas terpisah di panduan Graphiti dan memori temporal graph. Untuk lanskap yang lebih luas, lihat lanskap tooling RAG yang lebih luas.

Apa yang Rusak Setelah Hari ke-200: Graph Drift dan Re-Ekstraksi

Graph drift adalah pajak yang kamu bayar setelah launch, dan ia adalah keberatan praktisi nomor satu, dengan alasan yang jelas. Setiap tutorial memperlakukan graph sebagai sesuatu yang kamu bangun sekali. Tim sungguhan macet di hari ke-200.

Tiga hal yang lapuk. Pertama, re-indexing saat dokumen diperbarui. Ketika 40 dokumen berubah, kamu tidak bisa sekadar meng-embed ulang; kamu harus menjalankan ulang ekstraksi LLM pada chunk yang berubah, merekonsiliasi entitas baru terhadap graph lama, dan menghitung ulang komunitas yang terdampak beserta ringkasannya. Satu panduan Medium menyebut pembaruan inkremental itu mudah. Praktisi di r/Rag tidak setuju. OP dari thread 2026-04-25 yang menjalankan BM25 plus BGE-M3 di atas sekitar 600 dokumen berkata terus terang: "Ekstraksi entitas/relasi berbasis LLM itu berisik, dan re-indexing saat dokumen diperbarui kelihatan menyakitkan."

Kedua, pelapukan entity-resolution. "Acme Corp", "Acme", dan "ACME Corporation" tiba di dokumen berbeda berjarak berbulan-bulan dan pecah menjadi tiga node yang seharusnya satu. Tidak ada yang menggabungkannya secara otomatis.

Ketiga, relasi yang benar saat ekstraksi dan diam-diam berhenti benar. Tidak ada yang mendapat alert ketika edge reports_to menjadi basi.

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)

Codebase adalah kasus terburuk, dan yang paling menarik. Autocomplete kini memunculkan "graphrag for codebase", "graphrag claude code", dan "graphrag mcp server", dan codebase adalah graph yang berubah tiap jam: setiap commit menulis ulang call edge, memindahkan simbol, dan menghapus fungsi. Itu graph drift dengan jadwal yang tidak bisa dikejar penuh oleh re-indexing nightly mana pun. Itu juga kenapa tool graph-code yang serius bersandar pada parser deterministik seperti tree-sitter dan LSP untuk edge-nya dan menyimpan LLM untuk prosa di sekitarnya: docstring, pesan commit, thread review. Kalau kamu meng-graph sebuah repo, graph lapisan yang lambat berubah dengan LLM dan yang cepat berubah dengan parser.

Apa yang Sebenarnya Dikatakan Developer Tentang GraphRAG?

Developer yang aktif terbelah, dan Google sepertinya tahu itu: sebuah thread Reddit ranking di posisi dua untuk "graphrag vs rag", dan itu mesin pencari memberi tahumu bahwa topik ini menginginkan opini sesama, bukan kopi vendor.

Skeptisismenya nyata. Di thread r/Rag 2024 "Would you always recommend (knowledge) graph RAG over normal RAG?" (10 poin, 86% upvote), u/EncartaIt menulis: "Semua tutorial yang saya temukan terlalu menyederhanakan dan tidak benar-benar membuat kasus yang kuat untuk pola knowledge graph." u/Prestigious_Run_4049 lebih blak-blakan: "Saya rasa graph rag cuma hype. Orang suka membicarakannya dan kedengarannya keren tapi tidak ada yang benar-benar memakainya di use case nyata." Tidak semua setuju. u/pytheryx, berargumen dari produksi, mencatat bahwa retrieval graph menang di pertanyaan tipe daftar yang butuh konteks dari lebih banyak chunk daripada yang dikembalikan top_k; korpus whitepaper-nya butuh sekitar 50 chunk untuk jawaban lengkap.

Thread 2026 lebih terukur. u/Popular_Sand2773: "Kebanyakan setup graph rag cuma curang di skala. Kamu menjalankan pencarian vektor atau metadata standar untuk menemukan node awal lalu berjalan-jalan." u/ggone20, menjalankan sistem sekitar 300 juta artefak: "Di skala kamu benar-benar tidak bisa hidup tanpanya untuk menjawab pertanyaan nyata."

Bacaan kami cocok dengan argumen tertajam di kedua thread: titik beloknya adalah kompleksitas pertanyaanmu, bukan ukuran korpusmu. Itu juga yang ditemukan benchmark di atas, itulah kenapa kami berpihak pada praktisi yang membatasi tool ini untuk pekerjaan multi-hop, bukan yang menyebutnya mati.

Bagaimana Techsy Mendekati Ini

Ini urutan yang kami pakai di build klien, dan memang sengaja membosankan.

Pertama, buktikan langit-langit retrieval hybrid. Kebanyakan permintaan "kami butuh graph" yang kami dengar sebenarnya adalah masalah chunking atau reranking yang menyamar. Pipeline BM25-plus-vektor dengan reranker yang layak menjawab lebih banyak daripada yang diharapkan tim.

Kedua, jalankan Basic Search sebagai kontrol di korpusmu sendiri sebelum membangun apa pun. Itulah persisnya fungsi metode query keempat: baseline vektor biasa yang bisa kamu A/B melawan graph, di datamu, dengan pertanyaanmu.

Ketiga, bangun graph hanya ketika kelas pertanyaan yang terukur gagal di kontrol itu. Kalau query multi-hop atau lintas korpus meleset, kamu punya kasus nyata. Kalau tidak, kamu baru saja menghemat tagihan indexing dan masalah drift.

Mau pendapat kedua tentang stack retrieval-mu? Dapatkan konsultasi gratis.

Tentang Penulis

Mert Batur adalah Co-Founder Techsy.io, tempat timnya membangun AI agent, sistem otomasi, dan pipeline voice/SDR untuk klien B2B. Ia menulis tentang stack tooling LLM yang benar-benar dipakai tim Techsy di produksi. Di build klien, ia yang mengambil keputusan arsitektur retrieval: kapan hybrid search sudah cukup, dan kapan sebuah korpus benar-benar butuh graph. Terhubung dengannya di LinkedIn.

Pertanyaan yang Sering Diajukan

Bagaimana cara kerja GraphRAG?

GraphRAG mengindeks dokumenmu menjadi knowledge graph. Sebuah LLM mengekstrak entitas dan relasi dari setiap chunk, algoritma Leiden mengelompokkan entitas itu menjadi komunitas, dan setiap komunitas mendapat ringkasan. Saat query, engine mencari di graph dan ringkasan itu, sehingga ia bisa menghubungkan fakta yang duduk di chunk berbeda.

Apa bedanya GraphRAG dengan RAG?

RAG standar mengambil top-k chunk paling mirip dan memberikannya ke model. GraphRAG mengambil struktur: entitas, relasi di antaranya, dan ringkasan komunitas yang sudah ditulis sebelumnya. Struktur tambahan itulah yang membuatnya bisa menjawab pertanyaan multi-hop dan lintas korpus, dan itu juga yang membuat indexing lebih lambat dan lebih mahal.

Kapan saya harus memakai GraphRAG?

Pakailah ketika pertanyaanmu melintasi entitas atau mencakup seluruh korpus, seperti pertanyaan tumpang-tindih supplier atau analisis tema berulang di ribuan dokumen. Lewatkan untuk pencarian fakta satu hop, korpus yang cepat berubah, dan budget latensi atau biaya yang ketat. Kalau pipeline hybrid biasa sudah menjawab sebuah kelas pertanyaan, graph menambah biaya tanpa menambah nilai.

Apakah GraphRAG sudah mati?

Belum, tapi juga bukan pilihan default. Benchmark 2026 menunjukkan ia sering kalah dari RAG vanilla di tugas sehari-hari, dan itu membunuh hype-nya, sambil tetap menang di pertanyaan multi-hop dan agregasi. Kerangka jujurnya adalah situasional: GraphRAG menutup biayanya untuk tipe pertanyaan yang tepat dan rugi untuk sisanya.

Apa saja metode query GraphRAG?

Query engine resmi hadir dengan empat: Local Search untuk pertanyaan berpusat entitas, Global Search untuk agregasi lintas korpus, DRIFT Search untuk paduan rekursif keduanya, dan Basic Search untuk retrieval vektor biasa. Fitur kelima, Question Generation, duduk di atasnya. Basic Search paling penting: ia adalah kontrol untuk meng-A/B graph.

Berapa biaya indexing GraphRAG?

Biayanya muncul saat indexing, dalam panggilan LLM yang mengekstrak entitas dan relasi dari setiap chunk plus ringkasan komunitas. Microsoft Research melaporkan indexing LazyGraphRAG di 0,1% biaya GraphRAG penuh dan identik dengan vector RAG, tapi varian itu dirilis ke produk Microsoft, bukan library open-source. Kami belum menjalankan indexing berbayar sendiri.

Bisakah saya menjalankan GraphRAG secara lokal dengan Ollama?

Bisa. Library microsoft/graphrag membolehkanmu mengarahkan indexing dan query ke model lokal yang disajikan Ollama, yang menghilangkan biaya API per-token dari langkah ekstraksi. Kamu menukar kecepatan dan kualitas dengan biaya: model lokal lebih lemah di ekstraksi entitas, jadi harap maklum dengan graph yang lebih berisik dan waktu indexing lebih lama di hardware sederhana.

LightRAG atau Microsoft GraphRAG yang lebih baik?

Keduanya mengoptimalkan hal berbeda. LightRAG (38.353 star, push 2026-07-30) paling aktif dan lebih ringan dijalankan; microsoft/graphrag (35.088 star, v3.1.1) adalah implementasi referensi dengan empat metode query resmi. Pilih LightRAG untuk graph produksi yang efisien, milik Microsoft untuk perilaku yang setia spesifikasi dan kontrol Basic Search.

Siapa yang membuat GraphRAG dan kapan?

Microsoft Research membuat GraphRAG. Timnya menerbitkan paper pada 2024 dan merawat repositori open-source microsoft/graphrag di bawah lisensi MIT, dengan dokumentasi di microsoft.github.io/graphrag. Library referensi mencapai v3.1.1 pada 2026-07-18, dan ekosistem aktif implementasi pihak ketiga, termasuk LightRAG dan Graphiti, tumbuh di sekitarnya.

Vonis: Kapan Graph Menutup Biayanya

Bukti menunjuk satu arah, jadi ini posisinya.

• GraphRAG belum mati. Ia situasional, dan benchmark 2026 mengatakannya dengan lantang.
• Ia menutup biaya indexing-nya di pertanyaan entitas multi-hop dan agregasi lintas korpus. Ia rugi di pencarian satu hop.
• Biayanya adalah tagihan waktu indexing, dan varian murah yang dikutip semua orang, LazyGraphRAG, tidak pernah sampai ke library open-source.
• Graph melapuk setelah launch: entity resolution bergeser dan relasi menjadi basi, jadi anggarkan untuk re-indexing.
• Jalankan Basic Search sebagai kontrol di korpusmu sendiri sebelum membangun apa pun.

Satu kalimat: knowledge graph menutup biayanya ketika pertanyaanmu multi-hop atau lintas korpus, dan tidak sebelum itu. Kalau kamu mau pendapat kedua tentang stack retrieval-mu, dapatkan konsultasi gratis.