Polarisasi Arsitektur untuk RAG yang Ditingkatkan Grafik: Langkah Lebih Jauh dari Pencarian Vektor di Produksi

Retrieval-augmented generation (RAG) telah menjadi standar untuk menghubungkan large language models (LLMs) dengan data pribadi. Arsitektur standar yang meliputi pengelompokan dokumen, mengintegrasikannya ke dalam basis data vektor, dan mengambil hasil teratas melalui cosine similarity terbukti efektif untuk pencarian semantik yang tidak terstruktur.

Namun, di domain enterprise yang ditandai oleh data yang sangat terhubung seperti rantai pasok, kepatuhan finansial, dan deteksi penipuan, RAG yang hanya berbasis vektor sering kalah. Metode ini menangkap kesamaan tapi melewatkan struktur. Ketika dihadapkan pada pertanyaan multi-langkah, misalnya “Bagaimana keterlambatan pada Komponen X memengaruhi pengiriman Q3 kita untuk Klien Y?”, sistem vektor tidak “tahu” bahwa Komponen X adalah bagian dari pengiriman Klien Y.

Artikel ini akan mengulas pola RAG yang ditingkatkan dengan graf. Beradasarkan pengalaman dalam membangun sistem log dengan throughput tinggi di Meta dan infrastruktur data pribadi di Cognee, kita akan menjelajahi arsitektur referensi yang menggabungkan fleksibilitas semantik pencarian vektor dengan determinisme struktural dari database graf.

Permasalahan: Ketika pencarian vektor kehilangan konteks

Database vektor unggul dalam menangkap makna namun mengabaikan topologi. Ketika sebuah dokumen dipecah dan terintegrasi, hubungan eksplisit seperti hierarki, ketergantungan, dan kepemilikan bisa jadi terhapus atau hilang sepenuhnya.

Bayangkan skenario risiko rantai pasok. Ini adalah contoh hipotetis yang merepresentasikan masalah struktural yang sering muncul dalam arsitektur data enterprise:

• Data terstruktur: Sebuah database SQL yang mendefinisikan bahwa Pemasok A menyediakan Komponen X ke Pabrik Y.

• Data tidak terstruktur: Sebuah laporan berita yang menyatakan, “Banjir di Thailand telah menghentikan produksi di fasilitas Pemasok A.”

Pencarian vektor standar untuk “risiko produksi” akan mengambil laporan berita tersebut. Namun, kemungkinan besar tidak memiliki konteks untuk menghubungkan laporan itu dengan output Pabrik Y. LLM menerima berita tersebut, tetapi tidak bisa menjawab pertanyaan bisnis penting: “Pabrik mana yang terkena dampak?”

Dalam praktiknya, ini terlihat sebagai halusinasi. LLM mencoba menjembatani kesenjangan antara laporan berita dan pabrik, namun tanpa hubungan eksplisit, sehingga ia hanya bisa menebak atau memberi respon “saya tidak tahu” meskipun data ada di dalam sistem.

Pola: Pengambilan hibrida

Untuk memecahkan masalah ini, kita berpindah dari arsitektur “Flat RAG” ke “Graph RAG”. Ini melibatkan tumpukan tiga lapisan:

1. Ingesti (Pelajaran dari “Meta”): Di Meta, saat bekerja dengan infrastruktur logging untuk Shops, kami belajar bahwa struktur harus ditegakkan saat ingest. Anda tidak dapat menjamin analitik yang baik jika mencoba membangun kembali struktur dari log yang tidak teratur. Dalam RAG, kita harus mengekstrak entitas (simpul) dan hubungan (tepi) selama ingest. Kita bisa menggunakan LLM atau model pengenalan entitas bernama (NER) untuk mengekstrak entitas dari potongan teks dan menghubungkannya dengan catatan yang ada dalam graf.

2. Penyimpanan: Kita menggunakan database graf (seperti Neo4j) untuk menyimpan graf struktural. Embedding vektor disimpan sebagai properti pada simpul tertentu (misalnya, simpul RiskEvent).

3. Pengambilan: Kita melakukan query hibrida.

Implementasi referensi

Kita akan membangun implementasi sederhana dari analis risiko rantai pasok ini menggunakan Python, Neo4j, dan OpenAI.

1. Memodelkan graf

Kita membutuhkan skema yang menghubungkan “peristiwa risiko” yang tidak terstruktur dengan entitas “rantai pasok” yang terstruktur.

2. Ingesti: Mengaitkan struktur dan semantik

Dalam langkah ini, kita berasumsi bahwa graf struktural (pemasok -> pabrik) sudah ada. Kita menginjeksi “peristiwa risiko” yang tidak terstruktur dan menghubungkannya dengan graf.

3. Query pengambilan hibrida

Inilah yang membedakan. Alih-alih hanya mengembalikan potongan terbaik, kami menggunakan Cypher untuk melakukan pencarian vektor untuk menemukan peristiwa, dan kemudian menjelajah untuk menemukan dampak hilir.

Hasilnya: Alih-alih mendapatkan potongan teks yang generik, LLM menerima muatan yang terstruktur:

[{‘masalah’: ‘Banjir parah…’, ‘pemasok_terpengaruh’: ‘TechChip Inc’, ‘risiko_ke_pabrik’: ‘Pabrik Perakitan Alpha’}]

Ini memungkinkan LLM untuk menghasilkan jawaban yang tepat: “Banjir di TechChip Inc membuat Pabrik Perakitan Alpha berisiko.”

Pelajaran produksi: Latensi dan konsistensi

Mengalihkan arsitektur ini dari notebook ke produksi memerlukan penanganan trade-off.

1. Pajak latensi

Penjelajahan graf lebih mahal dibandingkan pencarian vektor sederhana. Dalam pekerjaan saya mengenai eksperimen gambar produk di Meta, kami menghadapi anggaran latensi yang ketat di mana setiap milidetik mempengaruhi pengalaman pengguna. Meskipun domainnya berbeda, pelajaran arsitektural ini berlaku langsung untuk Graph RAG: Anda tidak bisa menghitung semuanya secara langsung.

Mitigasi: Kami menggunakan caching semantik. Jika pengguna mengajukan pertanyaan yang mirip (cosine similarity > 0.85) dengan query sebelumnya, kami menyajikan hasil graf yang di-cache. Ini mengurangi “pajak graf” untuk query umum.

2. Masalah “tepi usang”

Dalam database vektor, data bersifat independen. Dalam graf, data saling bergantung. Jika Pemasok A berhenti memasok Pabrik Y, tetapi tepi tetap ada di graf, sistem RAG akan yakin akan hubungan yang sudah tidak ada.

Mitigasi: Hubungan graf harus memiliki Time-To-Live (TTL) atau disinkronisasi melalui pipeline Change Data Capture (CDC) dari sumber kebenaran (sistem ERP).

Kerangka keputusan infrastruktur

Apakah Anda harus mengadopsi Graph RAG? Berikut kerangka kerja yang kami gunakan di Cognee:

1. Gunakan RAG berbasis vektor jika:

   • Korpus bersifat datar (misalnya, Wiki atau dump Slack yang kacau).

   • Pertanyaan bersifat luas (“Bagaimana cara mereset VPN saya?”).

   • Latensi dianggap penting.

2. Gunakan RAG yang ditingkatkan graf jika:

   • Domainnya diatur (keuangan, kesehatan).

   • “Explainability” diperlukan (Anda perlu menunjukkan jalur penjelajahan).

   • Jawaban tergantung pada hubungan multi-langkah (“Subsidiary mana yang terpengaruh?”).

Kesimpulan

Graph-enhanced RAG bukan pengganti pencarian vektor, tetapi evolusi yang diperlukan untuk domain yang kompleks. Dengan memperlakukan infrastruktur Anda sebagai graf pengetahuan, Anda memberikan kepada LLM hal yang tidak bisa ia halusinasikan: Kebenaran struktural dari bisnis Anda.