Kalau selama ini kita membayangkan AI seperti “mesin pencari paragraf pintar”, Graph RAG datang membawa level berikutnya: AI tidak hanya mencari teks yang mirip dengan pertanyaan, tetapi juga mencoba memahami siapa terhubung dengan siapa, dokumen mana berkaitan dengan peristiwa tertentu, dan jalur fakta apa yang membentuk sebuah kesimpulan.
Singkatnya, inilah inti besarnya: RAG biasa mencari potongan teks yang relevan, sedangkan Graph RAG menghubungkan fakta-fakta yang relevan.
Secara resmi, GraphRAG dijelaskan Microsoft sebagai pendekatan berbasis graph untuk mengekstrak data terstruktur dari teks tidak terstruktur menggunakan large language model, lalu memakai struktur tersebut untuk retrieval dan penyusunan jawaban [1]. Repositori resminya juga menggambarkan GraphRAG sebagai sistem RAG modular berbasis graph [1]. Jadi, fokus utamanya memang bukan hanya “menemukan teks”, melainkan “membangun struktur pengetahuan” dari kumpulan dokumen.
Di sinilah Graph RAG terasa menarik. Pada RAG biasa, sistem umumnya memecah dokumen menjadi chunk kecil, mengubah chunk menjadi embedding, lalu mencari chunk yang paling mirip secara semantik dengan pertanyaan pengguna. Pendekatan ini sangat berguna untuk pertanyaan langsung, misalnya syarat klaim, batas ukuran file, atau definisi sebuah istilah. Namun, ketika jawaban tersebar di banyak dokumen dan perlu dirangkai lewat beberapa langkah penalaran, pendekatan berbasis kemiripan teks saja bisa mulai kewalahan [2].
Bayangkan begini: pengguna tidak bertanya “apa isi dokumen ini?”, tetapi bertanya “apa hubungan orang ini dengan polis itu, klaim tersebut, dokumen pendukungnya, dan mengapa prosesnya terlambat?”. Jawaban seperti itu sering kali tidak berada dalam satu paragraf. Ia tersebar di banyak tempat. Nah, Graph RAG hadir untuk menyatukan potongan-potongan tersebut.
Dalam konteks ini, kata graph bukan berarti grafik batang atau grafik garis. Graph adalah struktur data yang menggambarkan objek dan hubungan antarobjek. Ada tiga komponen sederhana yang paling mudah dibayangkan:
- Node: objek atau entitas, misalnya nasabah, polis, klaim, rumah sakit, agen, atau dokumen.
- Edge: hubungan antara dua node, misalnya “memiliki”, “mengajukan”, “berasal dari”, atau “membutuhkan”.
- Property: atribut tambahan pada node atau hubungan, misalnya status klaim, tanggal pengajuan, jenis dokumen, atau kanal asal.
Konsep ini membuat AI tidak sekadar melihat kalimat secara terpisah, tetapi mulai memahami bahwa sebuah fakta dapat menjadi jembatan ke fakta lain. Jika satu dokumen menyebut pemegang polis, dokumen lain menyebut tertanggung, dan file ketiga menjelaskan alasan keterlambatan klaim, Graph RAG dapat mencoba merangkainya ke dalam jaringan hubungan yang lebih utuh.
Contoh sederhana buatan penulis: ada lima fakta terpisah di dokumen berbeda. Andi adalah pemegang Polis P001. Budi adalah tertanggung utama pada Polis P001. Siti membayar premi untuk polis itu. Klaim C009 diajukan atas nama Budi. Klaim C009 masih menunggu laporan medis. Jika ditanya “mengapa klaim Budi belum selesai?”, sistem berbasis graph dapat menelusuri jalur Budi - Klaim C009 - status pending - laporan medis belum diterima, lalu menyusun jawaban yang lebih runtut. Contoh ini adalah ilustrasi konseptual, bukan contoh resmi dari Microsoft.
Kenapa RAG biasa terkadang terasa belum cukup? Karena desain dasarnya memang sangat kuat untuk pencarian berbasis kemiripan semantik, tetapi tidak selalu ideal untuk pertanyaan global atau pertanyaan multi-hop. Paper Microsoft tentang GraphRAG menjelaskan bahwa RAG biasa cenderung kesulitan pada pertanyaan global terhadap keseluruhan corpus, misalnya “apa tema utama dalam dataset?” atau “apa pola besar yang muncul dari seluruh kumpulan dokumen?” [2]. Pertanyaan seperti itu lebih dekat ke tugas query-focused summarization daripada retrieval eksplisit biasa [2].
Artinya, masalahnya bukan karena RAG biasa “buruk”. Justru sebaliknya: ia hebat untuk banyak use case praktis. Hanya saja, ketika organisasi menyimpan informasi dalam ribuan file, email, laporan, transkrip, prosedur, tiket insiden, dan database transaksi, pertanyaan pengguna sering membutuhkan lebih dari sekadar chunk yang paling mirip. Mereka membutuhkan konteks, relasi, dan gambaran besar.
Di sinilah arsitektur GraphRAG menjadi penting. Dokumentasi dan penjelasan Microsoft Research menyebut dua tahap besar dalam pendekatan ini: indexing dan query [3]. Tahap indexing bertugas membangun struktur pengetahuan dari dokumen. Tahap query memakai struktur itu untuk menjawab pertanyaan lokal maupun global [3].
Pada tahap indexing, dokumen-dokumen mentah lebih dulu diproses menjadi unit teks yang lebih kecil. Dalam dokumentasi resmi GraphRAG, unit ini disebut TextUnit [4]. TextUnit adalah chunk teks yang dipakai untuk ekstraksi graph, sekaligus menjadi sumber referensi atau provenance agar sistem bisa menelusuri kembali dari jawaban ke teks asal [4]. Ini poin penting: Graph RAG bukan hanya ingin “cerdas”, tetapi juga berusaha menjaga jejak bukti.
Dokumentasi dataflow GraphRAG menyebut ukuran default TextUnit saat ini adalah 1200 token dan dapat dikonfigurasi [4]. Jadi, chunking tetap ada. Graph RAG tidak membuang praktik penting dari RAG modern; ia menambah lapisan struktur di atasnya.
Setelah TextUnit terbentuk, sistem mengekstrak artefak pengetahuan. Model pengetahuan GraphRAG secara resmi mencakup beberapa objek inti seperti Document, TextUnit, Entity, Relationship, Covariate, Community, dan Community Report [4].
- Document mewakili dokumen asal.
- TextUnit adalah pecahan teks hasil chunking.
- Entity mewakili entitas yang diekstrak dari TextUnit.
- Relationship mewakili hubungan antarentitas.
- Covariate dapat dipakai untuk klaim atau pernyataan faktual tambahan yang punya status atau batas waktu.
- Community adalah kelompok entitas yang saling terkait.
- Community Report adalah ringkasan isi komunitas tersebut [4].
Kalau dibayangkan secara ceria, Graph RAG itu seperti mengubah gudang arsip yang berantakan menjadi kota kecil yang tertata. Dokumen adalah bangunan besar. TextUnit adalah ruangan-ruangan di dalam bangunan. Entity adalah orang atau objek penting yang tinggal di sana. Relationship adalah jalan yang menghubungkan mereka. Community adalah lingkungan perumahan dengan tema tertentu. Dan Community Report adalah papan informasi yang menjelaskan apa yang sedang terjadi di wilayah itu.
Pipeline indexing default yang didokumentasikan GraphRAG mencakup langkah-langkah berikut: menyusun TextUnits dari dokumen, memproses dokumen dan menautkannya ke TextUnits, mengekstrak entity dan relationship, menjalankan community detection, membuat community reports, lalu membuat text embeddings [4]. Rangkaian ini menegaskan satu hal penting: Graph RAG bukan pengganti total vector search. Ia justru menggabungkan LLM + graph + embedding/vector retrieval [4].
Jadi, kalau ada anggapan bahwa Graph RAG berarti “sudah tidak perlu embedding lagi”, itu kurang tepat. Dokumentasi resmi menyebut embedding tetap dibuat untuk artefak yang memerlukan pencarian berbasis vector. Secara default, yang di-embed meliputi deskripsi entitas, TextUnit, dan teks community report, lalu embedding tersebut ditulis ke vector store yang dikonfigurasi [4]. Dengan kata lain, vector search masih berperan sebagai mesin pencari makna, sementara graph memberi struktur hubungan.
Sesudah entity dan relationship terbentuk, sistem masuk ke tahap yang membuat Graph RAG terasa “naik kelas”, yaitu community detection. Microsoft secara resmi menyebut adanya hierarchical community detection dalam GraphRAG [4]. Pada dataflow default, algoritme yang disebut adalah Hierarchical Leiden Algorithm, yang melakukan clustering komunitas secara rekursif sampai ambang ukuran komunitas tertentu tercapai [4].
Mengapa komunitas ini penting? Karena corpus besar sulit dipahami hanya sebagai daftar node dan edge. Dengan membentuk komunitas, sistem bisa melihat kelompok-kelompok pengetahuan yang rapat hubungannya. Ada komunitas yang kecil dan spesifik, ada yang lebih tinggi dan luas. Struktur hierarkis ini membantu AI memahami granularity: dari detail mikro ke gambaran makro [4].
Lalu, setiap komunitas diringkas menjadi Community Report [4]. Dokumentasi menjelaskan bahwa laporan ini berguna untuk pembacaan manusia dan juga untuk proses search di tahap berikutnya [4]. Report pada level komunitas tinggi dapat merangkum graph secara keseluruhan, sedangkan level yang lebih rendah merangkum cluster yang lebih lokal [4]. Di sinilah Graph RAG mendapatkan kemampuan untuk menjawab pertanyaan global secara lebih masuk akal.
Misalnya pengguna bertanya, “Apa masalah utama dalam proses klaim tahun ini?” Pertanyaan seperti ini tidak menunjuk satu entitas spesifik, melainkan meminta sintesis dari banyak sumber. Dengan adanya community report, sistem tidak harus membaca ulang semua dokumen mentah setiap kali. Ia dapat memanfaatkan ringkasan komunitas untuk membangun jawaban global dengan lebih efisien [4][5].
Pada sisi query, GraphRAG secara resmi memiliki beberapa pendekatan pencarian utama: Local Search, Global Search, dan DRIFT Search [5]. Tiga pendekatan ini bisa dibayangkan sebagai tiga gaya bertanya yang berbeda.
Local Search cocok ketika pertanyaan berfokus pada entitas tertentu. Dokumentasi query menjelaskan bahwa Local Search menggabungkan data terstruktur dari knowledge graph dengan text chunks dari dokumen mentah [5]. Query dipakai untuk mengidentifikasi entitas yang relevan secara semantik, lalu sistem mengambil entitas yang terhubung, relationships, covariates, community reports, dan text chunks terkait untuk diseleksi ke dalam satu context window [5].
Dengan kata lain, kalau pertanyaannya seperti “siapa tertanggung pada Polis P001?” atau “dokumen apa yang belum tersedia untuk Klaim C009?”, sistem dapat memulai dari node yang paling relevan, lalu menelusuri tetangga-tetangganya. Ini membuat jawaban menjadi lebih terstruktur daripada sekadar menyajikan chunk yang mirip.
Global Search dipakai saat pengguna meminta gambaran besar seluruh dataset. Dokumentasi query menyebut bahwa Global Search bekerja dengan menelusuri community reports menggunakan pola map-reduce [5]. Banyak report dibaca, masing-masing menghasilkan jawaban parsial, lalu jawaban-jawaban itu digabungkan menjadi kesimpulan akhir [5]. Microsoft juga menandai metode ini sebagai resource-intensive, jadi lebih mahal secara komputasi, tetapi berguna untuk pertanyaan tingkat corpus [5].
Ini sangat menarik karena memperlihatkan filosofi Graph RAG: bukan hanya “temukan teks yang paling mirip”, melainkan “kumpulkan perspektif dari banyak komunitas pengetahuan, lalu rangkai kesimpulan yang lebih luas”. Untuk pertanyaan global, pendekatan ini memang lebih dekat pada sensemaking daripada retrieval tradisional [2][5].
DRIFT Search adalah jembatan yang seru antara lokal dan global. DRIFT merupakan singkatan dari Dynamic Reasoning and Inference with Flexible Traversal [3]. Microsoft Research menjelaskan bahwa DRIFT menggabungkan karakteristik global dan local search agar kualitas jawaban detail tetap baik dengan keseimbangan biaya komputasi yang lebih masuk akal [3]. Dokumentasi query juga menjelaskan bahwa DRIFT memperluas local search dengan memasukkan informasi komunitas, sehingga titik awal pencarian lebih luas dan fakta yang dipakai dalam jawaban menjadi lebih beragam [3][5].
Secara praktis, DRIFT cocok untuk pertanyaan yang berawal dari tema besar lalu butuh bukti rinci. Misalnya, “Mengapa keterlambatan klaim sering terjadi pada produk tertentu?” Sistem bisa mulai dari gambaran umum komunitas, lalu turun ke hubungan lokal yang relevan. Hasilnya, jawaban dapat lebih bernuansa: ada konteks besar, ada detail faktual, dan ada jalur penalaran yang lebih jelas.
Sampai di sini, perbedaan mental model antara RAG biasa dan Graph RAG mulai terlihat terang. RAG biasa terutama bertanya: potongan teks mana yang paling mirip dengan pertanyaan? Sedangkan Graph RAG bertanya: entitas apa yang dibicarakan, bagaimana hubungan antarentitas itu, komunitas mana yang relevan, dan bukti sumber apa yang mendukung kesimpulan?
Karena itu, Graph RAG sangat cocok untuk situasi berikut:
- Data berasal dari banyak dokumen yang saling terkait.
- Pertanyaan membutuhkan beberapa langkah penelusuran.
- Hubungan antarentitas lebih penting daripada kemiripan teks saja.
- Pengguna sering meminta gambaran besar lintas dokumen.
- Organisasi perlu mengaudit dari jawaban kembali ke sumber [4].
Dalam dunia nyata, contoh domain seperti asuransi, perbankan, layanan kesehatan, operasi perusahaan, investigasi insiden, atau manajemen dokumen sangat mudah merasakan manfaat pendekatan ini. Namun, perlu dibedakan dengan jelas: contoh node, edge, dan jalur di domain-domain tersebut umumnya adalah ilustrasi implementasi, bukan daftar fitur domain resmi dari Microsoft GraphRAG. Yang resmi adalah pola arsitekturnya, jenis artefaknya, dan strategi query-nya [1][4][5].
Ambil ilustrasi buatan penulis pada Document Management System asuransi. Node bisa berupa dokumen, versi dokumen, taxonomy, policy, submission, claim, insured party, source system, user, dan role. Hubungan bisa berupa dokumen mereferensikan klaim, dokumen berasal dari sistem tertentu, atau role memiliki akses ke scope dokumen. Dengan model seperti ini, pertanyaan kompleks seperti “dokumen identitas apa yang dipakai pada klaim tertentu, berasal dari sistem mana, dan boleh diakses oleh role apa?” menjadi lebih mudah dirumuskan sebagai penelusuran hubungan. Ilustrasi ini konseptual, tetapi menggambarkan mengapa graph memberi nilai tambah.
Ilustrasi serupa juga cocok pada underwriting. Submission dapat dihubungkan ke insured, product, medical requirement, risk factor, underwriter, reasuransi, dan decision. Pertanyaan seperti “mengapa submission dirujuk ke reasuransi?” atau “dokumen apa yang paling sering menunda keputusan underwriting?” sering kali membutuhkan penggabungan banyak fakta dari beragam sumber. Di titik itulah Graph RAG terasa lebih alami dibanding retrieval murni berbasis chunk.
Tentu saja, semua kelebihan ini tidak datang gratis. Repositori resmi Microsoft secara eksplisit memperingatkan bahwa proses indexing GraphRAG bisa mahal dan menyarankan pengguna memulai dari dataset kecil [1]. Ini masuk akal, karena dibanding vector RAG sederhana, Graph RAG menambah banyak pekerjaan: ekstraksi entitas, ekstraksi relasi, pembentukan komunitas, pembuatan ringkasan komunitas, dan embedding untuk artefak tambahan [4].
Selain biaya, kompleksitas implementasinya juga meningkat. Pada vector RAG biasa, alur utamanya sering cukup lurus: chunking, embedding, simpan ke vector database, lalu retrieval. Pada Graph RAG, organisasi perlu memikirkan kualitas ekstraksi, konsistensi entitas, relasi yang ambigu, struktur graph, dan pembaruan indeks dari waktu ke waktu. Kalau datanya sering berubah, graph dan community report juga bisa perlu disegarkan.
Di area ini, ada satu kehati-hatian penting. Banyak penjelasan praktis tentang Graph RAG membahas entity resolution atau penyatuan entitas yang merujuk pada objek yang sama. Secara konseptual, hal ini sangat relevan dalam implementasi nyata. Namun, jika dibahas dalam artikel, paling aman menyajikannya sebagai pertimbangan desain atau praktik implementasi, kecuali ada sumber resmi tambahan yang mendetail. Jadi, ide seperti menyamakan “Hanwha Life”, “Hanwha Life Indonesia”, atau singkatan tertentu boleh dipakai sebagai ilustrasi, tetapi sebaiknya tidak diposisikan sebagai klaim khusus dari dokumentasi resmi yang dirujuk di sini.
Begitu pula dengan risiko noise. Jika terlalu banyak kata atau konsep dijadikan node, graph bisa membengkak dan justru menyulitkan retrieval. Maka, implementasi yang sehat biasanya menyesuaikan jenis entitas dan relasi dengan kebutuhan bisnis. Ini adalah analisis desain yang logis, tetapi tetap perlu dibedakan dari fakta dokumentasi resmi.
Lalu, apakah Graph RAG harus memakai Neo4j? Jawabannya: tidak harus. Fakta yang paling aman dari dokumentasi adalah bahwa output pipeline indexing GraphRAG secara default disimpan sebagai tabel Parquet, sedangkan embedding ditulis ke vector store yang dikonfigurasi [1][4]. Jadi, Graph RAG lebih tepat dipahami sebagai pola arsitektur, bukan nama produk database tertentu. Organisasi bisa menyimpan struktur graph dengan berbagai pendekatan, selama retrieval dan orkestrasi query-nya mendukung kebutuhan sistem.
Kalau diringkas secara praktis, arsitektur Graph RAG di perusahaan bisa dibayangkan seperti ini: dokumen masuk dari PDF, Word, email, database, atau transkrip; lalu diparse; dipecah menjadi TextUnit; diekstrak entitas dan relasinya; dibentuk graph; dikelompokkan menjadi komunitas; diringkas menjadi community report; kemudian digabungkan dengan embedding di vector store; setelah itu retrieval orchestrator menentukan kapan memakai local, global, atau DRIFT; barulah LLM menyusun jawaban akhir. Bentuk pastinya dapat berbeda-beda, tetapi kerangka besarnya sangat sejalan dengan pipeline resmi GraphRAG [3][4][5].
Pada implementasi yang matang, jawaban ideal tidak hanya berisi kesimpulan, tetapi juga fakta pendukung, sumber dokumen, entitas yang terlibat, dan jejak hubungan yang dipakai. Kekuatan provenance ini sangat penting, terutama ketika AI dipakai di domain yang sensitif atau diaudit. Kehadiran TextUnit sebagai source reference dalam dataflow resmi mendukung pendekatan semacam itu [4].
Bagaimana dengan bukti performanya? Paper GraphRAG dari Microsoft menyatakan bahwa untuk kelas pertanyaan global sensemaking pada dataset sekitar 1 juta token, GraphRAG menunjukkan peningkatan substansial dibanding baseline RAG naif pada aspek comprehensiveness dan diversity jawaban [2]. Ini formulasi yang aman dan kuat. Namun, jika tidak mengutip paper penuh secara rinci, sebaiknya jangan menambahkan angka persentase peningkatan tertentu.
Meski terdengar hebat, Graph RAG tidak selalu diperlukan. Untuk FAQ sederhana, pencarian aturan dalam satu paragraf, atau pertanyaan yang jawabannya hampir selalu muncul di satu chunk, vector RAG biasa biasanya lebih murah dan lebih simpel. Memakai graph untuk semua masalah ibarat naik forklift hanya untuk memindahkan satu kotak kecil: bisa, tetapi belum tentu efisien.
Jadi, kapan Graph RAG sebaiknya dipilih? Saat organisasi menghadapi data lintas dokumen yang sangat saling terkait, pengguna sering mengajukan pertanyaan multi-hop, dan kebutuhan utamanya adalah memahami hubungan, pola, atau gambaran besar. Kapan sebaiknya ditunda dulu? Saat jumlah dokumen masih sedikit, pertanyaan masih sederhana, atau biaya indexing harus dijaga sangat rendah.
Kalau ingin merumuskan esensinya dalam satu kalimat yang ringan: vector RAG membantu AI menemukan informasi yang mirip, sedangkan Graph RAG membantu AI memahami bagaimana informasi itu saling berhubungan.
Dan justru di situlah pesona utamanya. AI tidak lagi hanya “mengutip paragraf”, tetapi mulai membangun peta pengetahuan. Ia berusaha tahu siapa, apa, kapan, terkait dengan apa, berada dalam kelompok masalah yang mana, dan bukti teks mana yang mendukungnya. Untuk pertanyaan-pertanyaan yang kompleks, itu adalah lompatan yang sangat berarti.
Sebagai penutup, ada tiga hal yang paling penting untuk diingat. Pertama, GraphRAG adalah pendekatan resmi berbasis graph yang mengekstrak struktur pengetahuan dari teks tak terstruktur [1][4]. Kedua, ia sangat berguna untuk pertanyaan global dan pertanyaan yang perlu menghubungkan banyak fakta lintas dokumen [2][5]. Ketiga, ia tetap memakai embedding, sehingga bukan “graph versus vector”, melainkan “graph plus vector plus LLM” [4].
Dengan begitu, kita bisa melihat Graph RAG bukan sebagai pengganti semua bentuk RAG, melainkan sebagai evolusi untuk kasus-kasus yang lebih rumit. Saat hubungan antar-informasi lebih penting daripada paragraf individual, Graph RAG memberi AI cara yang lebih cerdas, lebih terstruktur, dan lebih dekat dengan cara manusia memahami jaringan pengetahuan.
Sumber: [1] Microsoft GraphRAG Overview dan repository resmi. [2] Paper “From Local to Global: A Graph RAG Approach to Query-Focused Summarization”. [3] Microsoft Research, “Introducing DRIFT Search”. [4] GraphRAG Default Dataflow. [5] GraphRAG Query Overview.