5 Arsitektur RAG : Dari Hybrid RAG hingga Multimodal RAG
Retrieval-Augmented Generation (RAG) sering digambarkan dengan arsitektur yang sangat sederhana:
Pertanyaan
↓
Embedding
↓
Vector Database
↓
Dokumen Relevan
↓
LLM
↓
Jawaban
Arsitektur tersebut memang cukup untuk memahami konsep dasar RAG. Namun ketika RAG digunakan pada sistem nyata, terutama untuk kebutuhan enterprise, persoalannya menjadi jauh lebih kompleks.
Bagaimana jika pengguna mencari kode error tertentu?
Bagaimana jika jawaban tersebar di beberapa dokumen yang saling berhubungan?
Bagaimana jika informasi harus diambil dari database, API, dan knowledge base sekaligus?
Bagaimana jika hasil retrieval ternyata salah?
Atau bagaimana jika sumber pengetahuan bukan hanya teks, tetapi juga gambar, diagram, dan tabel?
Untuk menjawab kebutuhan tersebut, arsitektur RAG berkembang menjadi beberapa pendekatan. Lima di antaranya yang penting untuk dipahami adalah Hybrid RAG, GraphRAG, Agentic RAG, Corrective RAG (CRAG), dan Multimodal RAG.
1. Hybrid RAG
Hybrid RAG menggabungkan lebih dari satu metode retrieval. Implementasi yang paling umum adalah menggabungkan semantic/vector search dengan keyword search seperti BM25.
┌── Semantic / Vector Search
│
Query ──────────────┤
│
└── Keyword Search / BM25
│
▼
Result Fusion
│
▼
Top-K Context
│
▼
LLM
│
▼
Answer
Mengapa keduanya perlu digabungkan?
Vector search sangat baik dalam memahami makna.
Misalnya pengguna bertanya:
Saya lupa password dan tidak dapat masuk aplikasi.
Sementara knowledge base mempunyai dokumen:
Prosedur reset credential pengguna.
Walaupun kata yang digunakan berbeda, semantic search dapat mengenali bahwa keduanya membicarakan persoalan yang serupa.
Tetapi vector search tidak selalu ideal untuk informasi seperti:
ERR-403
INC-2026-00821
PMK 96 Tahun 2023
INV/2026/00231
Untuk identifier, kode, nomor dokumen, atau istilah teknis tertentu, keyword search sering kali lebih presisi.
Hybrid RAG mencoba mendapatkan keuntungan dari keduanya.
Hasil dari vector search dan BM25 dapat digabungkan menggunakan teknik seperti Reciprocal Rank Fusion (RRF) sebelum dokumen terbaik diberikan kepada LLM.
Cocok digunakan untuk
Hybrid RAG sangat cocok untuk knowledge base yang berisi kombinasi:
- dokumentasi teknis,
- tiket helpdesk,
- SOP,
- regulasi,
- kode error,
- nama produk,
- nomor dokumen,
- dan teks natural language.
Untuk banyak implementasi enterprise, Hybrid RAG merupakan peningkatan yang cukup logis dari RAG berbasis vector search sederhana.
2. GraphRAG
Tidak semua pertanyaan dapat dijawab hanya dengan mencari potongan teks yang paling mirip.
Dalam banyak kasus, hubungan antar-informasi justru menjadi bagian penting dari jawaban.
Misalnya sebuah organisasi mempunyai informasi:
Customer A
│
├── menggunakan → Product X
│
└── memiliki → Ticket 1021
│
├── terkait → Module Payment
│
└── diselesaikan oleh → Team B
Informasi tersebut sebenarnya membentuk sebuah graph.
Dalam GraphRAG, informasi dapat direpresentasikan sebagai:
Node
↓
Entity
Edge
↓
Relationship
Contohnya:
Person ── works_at ──> Company
Company ── uses ──> Application
Application ── has_issue ──> Incident
Incident ── related_to ──> Technology
Arsitektur sederhananya:
Query
↓
Entity Extraction
↓
Knowledge Graph
↓
Subgraph Retrieval
↓
Relevant Relationships
↓
LLM
↓
Answer
GraphRAG menjadi menarik ketika sebuah pertanyaan membutuhkan informasi yang tersebar di berbagai sumber tetapi memiliki hubungan tertentu.
Misalnya:
Aplikasi apa yang paling banyak mengalami masalah setelah perubahan pada layanan autentikasi?
Jawabannya mungkin tidak berada dalam satu dokumen.
Sistem perlu menghubungkan:
Application
↓
Incident
↓
Service
↓
Deployment
↓
Change
Graph membantu sistem memahami hubungan tersebut.
Cocok digunakan untuk
GraphRAG menarik untuk:
- knowledge management,
- dependency analysis,
- fraud investigation,
- cybersecurity,
- customer relationship,
- supply chain,
- regulatory analysis,
- dan enterprise knowledge graph.
3. Agentic RAG
Pada RAG tradisional, jalur retrieval biasanya sudah ditentukan.
Query
↓
Vector Search
↓
LLM
Tetapi bagaimana jika sistem mempunyai banyak sumber informasi?
Misalnya:
Vector Database
SQL Database
REST API
Knowledge Graph
Search Engine
Document Repository
Pertanyaan yang berbeda mungkin membutuhkan sumber yang berbeda.
Di sinilah konsep Agentic RAG menjadi menarik.
Agentic RAG menggunakan AI agent untuk menentukan bagaimana sebuah pertanyaan harus diselesaikan.
Query
│
▼
Planner / Agent
│
┌──────────────┼──────────────┐
▼ ▼ ▼
Vector Search SQL Database External API
│ │ │
└──────────────┼──────────────┘
▼
Reasoning
│
▼
Final Answer
Misalnya pengguna bertanya:
Berapa jumlah tiket bulan ini dan apa tiga masalah yang paling sering dilaporkan?
Agent dapat memecah pertanyaan menjadi dua pekerjaan.
Task 1
"Berapa jumlah tiket bulan ini?"
→ SQL / API
Task 2
"Apa masalah yang paling sering dilaporkan?"
→ Retrieval / Classification / Aggregation
Hasil keduanya kemudian digabungkan untuk menghasilkan jawaban.
Agent bahkan dapat melakukan beberapa langkah.
Query
↓
Plan
↓
Retrieve
↓
Evaluate
↓
Need More Information?
│
├── YES → Retrieve Again
│
└── NO
↓
Answer
Dengan demikian retrieval tidak lagi sekadar satu langkah, tetapi menjadi bagian dari proses reasoning dan planning.
Cocok digunakan untuk
Agentic RAG cocok ketika sistem memiliki:
- banyak sumber data,
- berbagai API,
- database transaksional,
- knowledge base,
- tools internal,
- serta pertanyaan yang membutuhkan beberapa langkah penyelesaian.
4. Corrective RAG (CRAG)
Salah satu kelemahan mendasar RAG adalah adanya asumsi bahwa hasil retrieval pasti benar.
Padahal kenyataannya tidak selalu demikian.
Bayangkan pengguna bertanya:
Bagaimana menangani ERR-403 pada aplikasi?
Retriever mengambil lima dokumen.
Tetapi ternyata sebagian besar membahas:
ERR-401
Authentication Failure
Session Timeout
Jika seluruh dokumen tersebut langsung diberikan kepada LLM, model tetap dapat menghasilkan jawaban.
Masalahnya, jawabannya mungkin terlihat meyakinkan tetapi didasarkan pada context yang salah.
Corrective RAG mencoba mengatasi masalah tersebut dengan menambahkan proses evaluasi setelah retrieval.
Query
↓
Retriever
↓
Retrieved Documents
↓
Evaluator / Grader
↓
Apakah Context Relevan?
│
├── YES
│ ↓
│ LLM
│ ↓
│ Answer
│
└── NO
↓
Rewrite Query
↓
Retrieve Again
Evaluator dapat mengklasifikasikan hasil retrieval menjadi:
CORRECT
AMBIGUOUS
INCORRECT
Jika hasilnya correct, context dapat langsung diberikan kepada LLM.
Jika ambiguous, sistem dapat memperbaiki query kemudian melakukan retrieval ulang.
Jika incorrect, sistem dapat mencari sumber alternatif.
Contohnya:
Vector Database
↓
Tidak Relevan
↓
Query Rewrite
↓
Keyword Search
↓
Alternative Source
Konsep ini membuat pipeline RAG memiliki mekanisme quality control terhadap retrieval.
Cocok digunakan untuk
Corrective RAG sangat relevan ketika kesalahan retrieval memiliki konsekuensi besar, misalnya:
- regulasi,
- compliance,
- dokumentasi operasional,
- SOP,
- knowledge base enterprise,
- technical troubleshooting,
- dan sistem pendukung keputusan.
5. Multimodal RAG
Sebagian besar implementasi awal RAG berfokus pada teks.
Padahal knowledge base organisasi tidak selalu berbentuk teks.
Informasi dapat berada dalam:
PDF
Image
Chart
Diagram
Table
Screenshot
Document
Misalnya sebuah manual mesin memiliki:
Deskripsi kerusakan
+
Foto komponen
+
Diagram wiring
+
Tabel spesifikasi
Jika sistem hanya mengekstrak teks, sebagian informasi penting dapat hilang.
Multimodal RAG mencoba melakukan retrieval terhadap berbagai jenis informasi tersebut.
Text ──────────┐
│
Images ────────┼──> Multimodal Representation
│
Tables ────────┤
│
Charts ────────┘
↓
Retrieval
↓
Multimodal Model
↓
Answer
Contohnya pengguna mengunggah foto panel mesin dan bertanya:
Komponen mana yang kemungkinan bermasalah berdasarkan diagram maintenance?
Sistem mungkin perlu:
- memahami gambar yang dikirim pengguna,
- mencari diagram yang relevan,
- membaca dokumentasi maintenance,
- memahami tabel spesifikasi,
- kemudian menggabungkan semuanya menjadi jawaban.
Ini jauh melampaui RAG berbasis teks biasa.
Cocok digunakan untuk
Multimodal RAG menarik untuk:
- manufacturing,
- maintenance,
- engineering,
- healthcare documentation,
- financial reports,
- construction,
- agriculture,
- technical manuals,
- dan document intelligence.
Perbedaan 5 Arsitektur RAG
Kelima pendekatan tersebut sebenarnya menyelesaikan masalah yang berbeda.
| Arsitektur | Fokus Utama | Masalah yang Diselesaikan |
|---|---|---|
| Hybrid RAG | Metode pencarian | Vector search saja tidak cukup |
| GraphRAG | Hubungan informasi | Jawaban tersebar pada relasi antar-entitas |
| Agentic RAG | Planning & tools | Pertanyaan membutuhkan beberapa sumber/proses |
| Corrective RAG | Validasi retrieval | Dokumen hasil retrieval belum tentu benar |
| Multimodal RAG | Berbagai tipe data | Knowledge tidak hanya berupa teks |
Karena itu, kelimanya sebaiknya tidak dipandang sebagai pilihan yang selalu saling menggantikan.
Bisakah Kelimanya Digabungkan?
Bisa.
Bahkan arsitektur enterprise RAG di masa depan kemungkinan semakin banyak menggabungkan konsep-konsep tersebut.
Sebagai contoh:
USER
│
▼
Agentic Layer
Planning & Routing
│
┌──────────────────┼──────────────────┐
│ │ │
▼ ▼ ▼
Hybrid RAG GraphRAG SQL / API
│ │ │
BM25 + Vector Knowledge Structured
│ Graph Data
│ │ │
└──────────────────┼──────────────────┘
│
▼
Corrective Layer
Evaluate Retrieval
│
┌──────┴──────┐
│ │
Relevant Not Relevant
│ │
│ Retrieve Again
│ │
└──────┬──────┘
▼
Reranker
│
▼
Context Builder
│
▼
Multimodal LLM
│
▼
ANSWER
Pada arsitektur seperti ini:
Agentic RAG menentukan strategi pencarian.
Hybrid RAG mencari dokumen menggunakan keyword dan semantic search.
GraphRAG mencari hubungan antar-entitas.
Corrective RAG mengevaluasi apakah informasi yang ditemukan memang relevan.
Multimodal RAG memungkinkan sistem memahami context yang tidak terbatas pada teks.
Jangan Memilih Arsitektur Karena Sedang Tren
Hal yang perlu diperhatikan adalah tidak semua implementasi membutuhkan seluruh pendekatan tersebut.
Jika knowledge base hanya terdiri dari beberapa ribu dokumen teks, arsitektur:
Embedding
↓
Vector Search
↓
Reranker
↓
LLM
mungkin sudah cukup.
Jika banyak identifier dan istilah teknis, pertimbangkan:
Hybrid RAG
Jika hubungan antar-entitas sangat penting:
GraphRAG
Jika sistem harus memilih berbagai tools dan sumber data:
Agentic RAG
Jika kualitas retrieval harus diperiksa sebelum digunakan:
Corrective RAG
Jika sumber informasi mencakup gambar, tabel, dan diagram:
Multimodal RAG
Arsitektur seharusnya mengikuti karakteristik data dan masalah bisnis, bukan sebaliknya.
Evolusi RAG: Dari Search Menjadi Knowledge Architecture
Perkembangan RAG menunjukkan perubahan yang cukup menarik.
Generasi awal dapat digambarkan sebagai:
Query
↓
Vector Search
↓
LLM
Kemudian berkembang menjadi:
Query
↓
Hybrid Retrieval
↓
Reranking
↓
LLM
Dan pada implementasi yang lebih kompleks:
Query
↓
Query Understanding
↓
Planning / Routing
↓
┌────────────────┼────────────────┐
│ │ │
Semantic Keyword Graph
Retrieval Retrieval Retrieval
│ │ │
├────────────────┼────────────────┤
│ │ │
SQL / API Multimodal External
Retrieval Retrieval Sources
│ │ │
└────────────────┼────────────────┘
↓
Evaluation
↓
Reranking
↓
Context Selection
↓
LLM
↓
Answer
Pada tahap ini, RAG bukan lagi sekadar menghubungkan vector database dengan LLM.
RAG berkembang menjadi sebuah arsitektur untuk menentukan:
Informasi apa yang dibutuhkan, di mana informasi tersebut berada, bagaimana menemukannya, apakah informasi tersebut benar-benar relevan, dan bagaimana memberikannya kepada model dalam context yang tepat.
Kesimpulan
Hybrid RAG, GraphRAG, Agentic RAG, Corrective RAG, dan Multimodal RAG menunjukkan bahwa tidak ada satu pendekatan retrieval yang ideal untuk seluruh permasalahan.
Hybrid RAG meningkatkan kualitas pencarian dengan menggabungkan semantic dan keyword retrieval.
GraphRAG memberikan kemampuan untuk memahami hubungan antar-informasi.
Agentic RAG memungkinkan sistem merencanakan sendiri bagaimana dan dari mana informasi harus diperoleh.
Corrective RAG menambahkan mekanisme evaluasi agar context yang salah tidak langsung dipercaya.
Sedangkan Multimodal RAG memperluas knowledge retrieval dari sekadar teks menjadi gambar, tabel, diagram, dan bentuk informasi lainnya.
Hal terpenting dalam membangun RAG bukanlah menggunakan arsitektur yang paling kompleks.
Yang lebih penting adalah memahami karakteristik data, jenis pertanyaan pengguna, serta tingkat akurasi yang dibutuhkan sistem.
Karena pada akhirnya, LLM hanya dapat memberikan jawaban yang baik jika sistem berhasil memberikan context yang tepat, relevan, dan dapat dipercaya.
Published by Nirantara
Nirantara is an Indonesian Enterprise AI company specializing in Enterprise AI, RAG, Intelligent Search, and AI Automation. Article written by jsturana.