Retrieval-augmented generation (RAG) biasanya dimulai dari gagasan sederhana: cari chunk teks yang mirip dengan pertanyaan, masukkan chunk paling relevan ke context model, lalu minta model menjawab berdasarkan evidence tersebut. Pendekatan ini bekerja baik ketika jawaban terdapat dalam satu passage atau beberapa passage yang masing-masing mudah diambil.

Sebagian pertanyaan lebih sulit karena evidence yang berguna terhubung oleh relasi, bukan sekadar kemiripan kata. Developer mungkin perlu menjawab, “Service mana yang bergantung pada library yang dikelola tim pemilik Payments API?” Tidak ada satu chunk yang harus memuat semua kata itu. Jawabannya dapat memerlukan penelusuran beberapa hubungan antara service, library, tim, dan API.

Graph RAG merupakan pola retrieval untuk kondisi seperti ini. Object relevan direpresentasikan sebagai node dan relasi sebagai edge, lalu graph traversal mengumpulkan evidence yang saling terhubung sebelum generation. Graph menambahkan struktur eksplisit yang tidak tersedia pada retrieval berbasis similarity saja.

Mulai dari pertanyaan yang memerlukan sebuah path

Bayangkan knowledge base engineering internal berisi fakta berikut:

Checkout Service depends on Pricing SDK.
Pricing SDK is maintained by Commerce Platform.
Commerce Platform owns Payments API.

Pertanyaannya:

Which service depends on the library maintained by the team that owns Payments API?

Jawabannya adalah Checkout Service, tetapi pencapaiannya memerlukan tiga relasi:

Payments API <-owns- Commerce Platform -maintains-> Pricing SDK <-depends on- Checkout Service

Vector retriever masih dapat berhasil jika chunk yang tepat mendapat ranking tinggi. Namun, semantic similarity tidak secara eksplisit merepresentasikan kebutuhan untuk mengikuti owns, lalu maintains, kemudian depends on. Graph membuat struktur tersebut tersedia bagi algoritma retrieval.

Model mental dasarnya:

vector RAG: question -> similar passages -> answer

graph RAG:  question -> relevant nodes -> connected evidence -> answer

Graph retrieval tidak menggantikan language model. Ia mengubah cara sistem memilih evidence yang akan dibaca model.

Representasikan fakta sebagai node dan edge

Graph memiliki node untuk object dan edge untuk relasi antar-object. Untuk contoh di atas, node dapat berupa:

service: Checkout Service
library: Pricing SDK
team:    Commerce Platform
api:     Payments API

Edge berarahnya dapat berupa:

Checkout Service --depends_on--> Pricing SDK
Commerce Platform --maintains--> Pricing SDK
Commerce Platform --owns-------> Payments API

Arah penting ketika relasinya directional. Commerce Platform owns Payments API tidak berarti Payments API owns Commerce Platform.

Graph produksi biasanya menyimpan lebih dari nama. Node dapat membawa identifier, alias, referensi sumber, timestamp, atau deskripsi singkat. Edge dapat membawa tipe relasi dan provenance yang menunjukkan sumber pendukungnya.

Provenance sangat penting untuk RAG. Graph adalah retrieval index, bukan otomatis evidence final. Jika sebuah edge menyatakan satu service bergantung pada service lain, sistem idealnya mempertahankan dokumen, record konfigurasi, atau sumber lain tempat relasi itu diekstrak. Generator kemudian menerima teks sumber, bukan assertion graph tanpa dukungan.

Pisahkan konstruksi graph dari graph retrieval

Graph RAG sebaiknya diperlakukan sebagai dua masalah. Graph construction mengubah data sumber menjadi node dan edge. Graph retrieval menentukan bagian graph yang relevan untuk pertanyaan tertentu.

Kedua tahap gagal dengan cara berbeda. Traversal sempurna tidak dapat memulihkan relasi yang tidak pernah diindeks. Sebaliknya, graph yang kaya tidak berguna jika retrieval berekspansi melalui begitu banyak edge sehingga context akhir menjadi bising.

Bangun dari data terstruktur jika memungkinkan

Jika relasi sudah tersedia dalam database, service catalog, package manifest, access-control record, atau sistem terstruktur lain, utamakan sumber tersebut daripada mengekstrak setiap edge dengan language model.

Contohnya, dependency manifest dapat memberikan relasi langsung:

Checkout Service --depends_on--> Pricing SDK

Semantik edge itu lebih jelas daripada meminta model menyimpulkan dependency dari paragraf informal.

Ekstraksi dengan language model tetap berguna ketika relasi hanya ada di teks tidak terstruktur. Dalam kondisi itu, definisikan schema kecil terlebih dahulu:

node types: service, library, team, api
edge types: depends_on, maintains, owns

Schema terbatas membuat retrieval lebih mudah dianalisis dan memberi validation code sesuatu yang konkret untuk diperiksa. Graph tanpa batas dengan nama relasi arbitrer seperti works_with, related_to, supports, dan connected_to sulit di-query secara konsisten.

Pisahkan identitas stabil dari display name

Nama bukan identifier yang andal. Payments, Payments API, dan payment-api dapat merujuk object yang sama, sementara dua tim dapat memiliki nama pendek identik.

Graph praktis sebaiknya memetakan alias ke identifier node yang stabil:

id: api_1842
name: Payments API
aliases: [payment-api, Payments]

Tanpa entity resolution, satu object nyata dapat terpecah menjadi beberapa node dan traversal kehilangan path yang seharusnya ada.

Retrieval dua tahap: cari seed, lalu ekspansi

Graph retriever sederhana dapat memisahkan retrieval menjadi seed selection dan graph expansion. Untuk pertanyaan tentang Payments API, seed selection terlebih dahulu mengidentifikasi entitas tersebut dan memetakannya ke node graph.

question
   |
   v
seed: Payments API

Retriever kemudian berekspansi melalui relasi yang diizinkan:

Payments API
   ^ owns
Commerce Platform
   | maintains
   v
Pricing SDK
   ^ depends_on
Checkout Service

Ini adalah path tiga hop. Satu hop adalah satu traversal edge.

Pilihan implementasi penting bukan sekadar “search the graph”, melainkan edge mana yang boleh diikuti, arahnya, dan berapa banyak hop. Constraint tersebut menentukan jenis penalaran yang diizinkan pada tahap retrieval.

Traversal sederhana dapat berbentuk:

frontier = {seed nodes}
visited = {seed nodes}

repeat up to max_hops:
    next_frontier = {}
    for node in frontier:
        for edge in allowed_edges(node):
            neighbor = follow(edge)
            if neighbor not in visited:
                visited.add(neighbor)
                next_frontier.add(neighbor)
    frontier = next_frontier

Graph store nyata memiliki query language dan traversal API masing-masing. Retrieval produksi biasanya memberi ranking atau filter pada kandidat, bukan mengembalikan semua node yang dikunjungi.

Batasi ekspansi sebelum graph memenuhi context window

Traversal tanpa batas jarang berguna untuk RAG. Jika node populer memiliki ribuan neighbor, dua hop saja dapat menghasilkan material jauh lebih banyak daripada yang seharusnya diterima model.

Misalnya:

Platform Team -> maintains -> 180 libraries

Pertanyaan yang mencapai Platform Team tidak otomatis memerlukan evidence tentang seluruh 180 library. Ekspansi buta menambah latency, menghabiskan context token, dan dapat menenggelamkan path yang berguna.

Kontrol yang umum meliputi:

  • membatasi jumlah hop maksimum;
  • hanya mengizinkan tipe relasi yang relevan;
  • membatasi arah edge ketika semantik memerlukannya;
  • memfilter node berdasarkan tipe, recency, tenant, atau access policy;
  • memberi ranking pada path atau node sebelum mengambil source text;
  • membatasi jumlah neighbor dari node berderajat tinggi.

Tujuannya bukan mengambil connected subgraph terbesar, melainkan set evidence terkecil yang dapat dipertanggungjawabkan untuk mendukung relasi yang diminta.

Gabungkan text retrieval dan graph retrieval

Graph RAG tidak mengharuskan embeddings ditinggalkan. Embedding berguna untuk mencocokkan paraphrase atau konsep, sedangkan graph berguna untuk mempertahankan relasi eksplisit. Pipeline hybrid dapat memakai keduanya:

question
   |
   +-> vector search ------> relevant text chunks ------+
   |                                                 |
   +-> entity matching -> graph paths -> source text --+-> rerank -> context

Jika pengguna menyebut “the checkout component” sementara node bernama Checkout Service, semantic retrieval atau alias matching dapat menemukan seed, lalu traversal mengikuti dependency dari seed tersebut.

Context akhir biasanya sebaiknya berisi passage sumber yang dapat dibaca manusia atau fakta terstruktur dengan provenance, bukan dump internal graph. Model membutuhkan evidence yang dapat diinterpretasikan dan aplikasi membutuhkan informasi sumber untuk mengaudit jawaban.

Bedakan retrieval dari reasoning

Graph path dapat membuat rantai evidence eksplisit, tetapi menemukan path tidak sama dengan membuktikan kesimpulan akhir.

Service A --calls--> Service B
Service B --calls--> Service C

Valid untuk menyatakan graph memiliki call path dua hop dari A ke C. Belum tentu valid menyatakan A langsung memanggil C. Arti multi-hop path bergantung pada relasinya.

Sebagian relasi bersifat transitif pada domain tertentu, sebagian tidak. is_ancestor_of dapat mendukung transitive reasoning. reports_to, uses, calls, dan is_near umumnya tidak boleh dianggap otomatis transitif tanpa aturan domain khusus.

Karena itu tipe relasi penting. Jika semua edge direduksi menjadi related_to, traversal dapat menemukan koneksi tetapi kehilangan semantik untuk menginterpretasikannya secara aman.

Evaluasi retrieval sebelum generated answer

Kualitas end-to-end penting, tetapi dapat menyembunyikan lokasi kegagalan. Evaluasi retrieval secara terpisah agar masalah indexing dapat dibedakan dari masalah generation.

Buat evaluation set kecil berisi pertanyaan, evidence yang diharapkan, dan jawaban yang diharapkan. Untuk pertanyaan multi-hop, catat path atau source record yang diperlukan.

Ukur perilaku seperti:

Did retrieval include every required evidence item?
How many irrelevant evidence items were also retrieved?
How many graph hops were needed?
How much context did the retrieved evidence consume?

Bandingkan graph retrieval dengan baseline yang lebih sederhana menggunakan generator yang sama. Jika vector retrieval saja sudah mengambil evidence yang diperlukan secara andal, graph dapat menambah kompleksitas operasional tanpa memperbaiki tugas utama.

Uji juga kasus rusak dan ambigu: hapus satu edge wajib, tambahkan dua entitas bernama mirip, tambahkan high-degree hub, atau ajukan pertanyaan yang jawabannya tidak ada dalam graph. Pipeline yang baik harus gagal secara terprediksi, bukan mengarang path atau menyajikan evidence tidak lengkap sebagai lengkap.

Perhatikan failure mode pada setiap tahap

Incorrect extraction. Jika model mengekstrak Team A owns API B dari teks yang hanya menyatakan Team A menggunakan API B, traversal dapat menyebarkan relasi palsu dengan percaya diri. Validasi tipe relasi berdampak tinggi dan simpan provenance.

Stale edges. Ownership dan dependency berubah. Simpan timestamp bila domain memerlukannya dan tentukan bagaimana update menginvalidasi relasi lama.

Entity collisions. Dua object bernama mirip dapat tergabung secara salah. Identifier stabil dan type constraint mengurangi risiko ini.

Missing edges. Tidak adanya graph path tidak membuktikan relasi tidak ada. Sumber mungkin belum diindeks atau ekstraksi melewatkannya.

Traversal explosion. Hub dapat menghasilkan kandidat sangat besar. Batasi ekspansi dan lakukan ranking sebelum mengambil source text dalam jumlah besar.

Access-control leakage. Graph dapat menghubungkan informasi publik dan restricted. Authorization harus diterapkan selama traversal dan evidence fetching, bukan hanya menyembunyikan teks restricted setelah path membocorkan nama node atau relasi sensitif.

Generator overreach. Bahkan dengan evidence benar, language model dapat menyatakan kesimpulan yang tidak didukung path. Evaluasi perilaku ini secara langsung pada aplikasi penting.

Tentukan kapan graph layak ditambahkan

Graph RAG cocok ketika pertanyaan berulang kali bergantung pada relasi yang bermakna dan dapat digunakan ulang: service dependency, organizational ownership, kompatibilitas produk, citation dokumen, interaksi biologis, atau domain lain tempat path memiliki semantik berguna.

Graph kurang menarik jika jawaban biasanya berada dalam passage tunggal, relasi berubah terlalu cepat untuk dipelihara, atau corpus tidak memiliki identitas entitas yang andal. Dalam kondisi tersebut, chunking, metadata filter, semantic retrieval, dan reranking dapat menyelesaikan masalah dengan komponen lebih sedikit.

Tidak perlu membangun universal enterprise knowledge graph. Graph kecil yang spesifik untuk tugas dengan empat tipe node dan tiga relasi terdefinisi baik dapat lebih berguna daripada graph besar dengan edge yang maknanya kabur.

Perbandingan yang tepat bukan “graph RAG versus basic RAG” secara abstrak. Bandingkan desain retrieval paling sederhana yang memenuhi pola pertanyaan, target kualitas, latency budget, dan kapasitas pemeliharaan aplikasi.

Penutup

Graph RAG pada dasarnya adalah relationship-aware retrieval. Retriever memulai dari entitas relevan dan mengikuti relasi eksplisit bertipe untuk mengumpulkan evidence yang tersebar di beberapa record.

Graph bernilai ketika relasi tersebut sesuai dengan reasoning path yang dibutuhkan pertanyaan. Bangun dari sumber terstruktur yang andal jika tersedia, pertahankan identitas entitas dan provenance, batasi traversal, dan ukur apakah evidence wajib benar-benar terambil. Jika retrieval biasa sudah memadai, pertahankan sistem yang lebih sederhana. Jika pertanyaan penting bergantung pada koneksi multi-hop, graph yang dibatasi dengan baik dapat membuat koneksi tersebut eksplisit dan dapat diambil.

Kecerdasan Buatan RAG LLM Knowledge Graph