Infrastruktur RAG: Membangun Sistem Retrieval-Augmented Generation untuk Produksi

Diperbarui 8 Desember 2025

Pembaruan Desember 2025: Adopsi RAG meningkat pesat sebagai use case LLM enterprise #1. Arsitektur GraphRAG dan agentic RAG semakin diminati untuk penalaran kompleks. Pasar vector database terkonsolidasi di sekitar Pinecone, Weaviate, Milvus, dan Qdrant. Voyage-3-large mengungguli embedding OpenAI dan Cohere sebesar 9-20%. Semantic chunking meningkatkan recall hingga 9% dibandingkan pendekatan fixed-size. Tantangan produksi bergeser dari prototipe ke skala—embedding drift, multi-tenancy, dan persyaratan latensi di bawah 50ms mendorong investasi infrastruktur.

Harvey AI melayani 97% firma hukum Am Law 100 menggunakan retrieval-augmented generation untuk mendasarkan riset hukum pada kasus hukum aktual daripada kutipan yang dihalusinasi.¹ Anthropic, OpenAI, dan Google semuanya merekomendasikan RAG sebagai teknik utama untuk menghubungkan large language model ke data enterprise proprietary. Namun kesenjangan antara prototipe RAG yang berfungsi dan infrastruktur tingkat produksi membutuhkan berbulan-bulan upaya engineering. Organisasi menemukan bahwa vector database, pipeline embedding, strategi chunking, dan optimasi retrieval masing-masing menghadirkan tantangan infrastruktur berbeda yang bertambah kompleks pada skala besar. Membangun sistem RAG yang menangani jutaan dokumen, melayani ribuan pengguna bersamaan, dan mempertahankan latensi di bawah satu detik memerlukan keputusan arsitektur yang jarang diantisipasi tim selama fase proof-of-concept.

Arsitektur inti yang dibutuhkan setiap sistem RAG produksi

Sistem RAG menggabungkan dua kapabilitas fundamental: mengambil konteks relevan dari knowledge base dan menghasilkan respons yang didasarkan pada konteks tersebut. Arsitektur terbagi menjadi lima komponen berbeda, masing-masing dengan persyaratan infrastruktur spesifik.

Pipeline ingestion dokumen menangani alur dari dokumen mentah ke embedding yang dapat dicari. Sistem produksi memproses PDF, HTML, dokumen Word, pesan Slack, dan record database melalui parser khusus format. Pipeline ingestion harus melacak versi dokumen, menangani pembaruan inkremental, dan memelihara metadata untuk filtering. Deployment enterprise tipikal memproses 100.000 hingga 10 juta dokumen selama backfill awal, dengan muatan inkremental harian 1.000 hingga 50.000 dokumen baru.²

Sistem chunking membagi dokumen menjadi segmen yang ramah untuk retrieval. Fixed-size chunking bekerja untuk konten homogen seperti artikel berita, sementara semantic chunking mempertahankan batas makna untuk dokumen kompleks.³ Sebagian besar sistem produksi menggunakan recursive chunking dengan 400-512 token dan overlap 10-20%, mencapai recall 85-90% dalam tes benchmark.⁴ Pemilihan strategi chunking menjadi semi-permanen—mengubah pendekatan nanti memerlukan re-embedding seluruh korpus.

Infrastruktur embedding mengkonversi chunk teks menjadi representasi vektor padat. Organisasi memilih antara API terkelola (OpenAI, Cohere, Voyage AI) dan model self-hosted. Pembuatan embedding menciptakan struktur biaya paling bervariasi dalam sistem RAG, dengan harga berkisar dari $0,02 hingga $0,18 per juta token tergantung pada pemilihan model.⁵ Batch processing memparalelkan pembuatan embedding di seluruh node GPU untuk muatan awal, sementara pipeline streaming menangani pembaruan inkremental.

Vector database menyimpan dan mengambil embedding menggunakan algoritma approximate nearest neighbor. Empat opsi dominan—Pinecone, Weaviate, Milvus, dan Qdrant—melayani profil operasional berbeda. Pinecone menawarkan layanan terkelola zero-ops, Weaviate menyediakan hybrid search dengan kapabilitas knowledge graph, Milvus menangani deployment skala miliaran, dan Qdrant unggul dalam metadata filtering kompleks.⁶ Persyaratan penyimpanan berskala dengan dimensi embedding dan jumlah dokumen; korpus 10 juta dokumen dengan embedding 1024-dimensi memerlukan sekitar 40GB penyimpanan vektor.

Orkestrasi retrieval dan generation mengikat komponen bersama, biasanya menggunakan framework seperti LangChain, LlamaIndex, atau implementasi kustom. Orkestrasi menangani pemrosesan query, retrieval, reranking, konstruksi prompt, dan pembuatan respons. Sistem produksi mengimplementasikan caching layer, strategi fallback, dan instrumentasi observability di setiap tahap.

Pemilihan vector database menentukan kompleksitas operasional

Pasar vector database terkonsolidasi di sekitar empat pemain utama pada Desember 2025, masing-masing melayani profil operasional dan use case yang berbeda.

Pinecone mendominasi segmen layanan terkelola, menangani infrastruktur sepenuhnya di balik API mereka. Tim men-deploy sistem produksi dalam hitungan jam daripada minggu, dengan automatic scaling, replikasi multi-region, dan kepatuhan SOC 2 sudah termasuk. Pinecone mendukung hingga 40KB metadata per vektor, memungkinkan filtering kaya tanpa sistem eksternal. Tradeoff-nya melibatkan biaya per-query lebih tinggi dan kontrol berkurang atas optimasi infrastruktur. Organisasi dengan workload yang dapat diprediksi sering menganggap Pinecone hemat biaya; yang memiliki traffic sangat bervariasi atau persyaratan skala ekstrem biasanya bermigrasi ke alternatif.⁷

Weaviate menjembatani fleksibilitas open-source dengan kenyamanan terkelola melalui Weaviate Cloud. Sistem menggabungkan vector search dengan kapabilitas knowledge graph, memungkinkan query hybrid yang memfilter data terstruktur sambil meranking berdasarkan kesamaan semantik. Arsitektur modular Weaviate mendukung beberapa model embedding secara bersamaan, berguna untuk organisasi yang bereksperimen dengan pendekatan berbeda. Deployment Docker dan Kubernetes memerlukan keahlian operasional moderat, membuat Weaviate populer di kalangan tim dengan kemampuan infrastruktur tertentu.⁸

Milvus (dan pasangan terkelolanya Zilliz Cloud) menargetkan deployment skala miliaran dengan performa sebagai tujuan desain utama. Milvus memimpin benchmark dalam latensi mentah, mencapai waktu query di bawah 10ms pada indeks vektor miliaran melalui akselerasi GPU dan algoritma indexing canggih.⁹ Arsitektur memisahkan compute dan storage, memungkinkan scaling independen untuk setiap layer. Mengoperasikan Milvus memerlukan keahlian data engineering yang signifikan—tim tanpa personel infrastruktur khusus sering kesulitan dengan manajemen cluster dan tuning performa.

Qdrant mendapatkan adopsi cepat untuk persyaratan filtering kompleks. Dibangun dengan Rust, Qdrant mengeksekusi payload filtering langsung dalam algoritma pencarian daripada sebagai post-processing, memberikan performa superior untuk query terfilter.¹⁰ Footprint resource yang ringkas membuat Qdrant populer untuk deployment yang sensitif biaya, sementara desain API yang jernih mempercepat velocity pengembangan. Deployment self-hosted berjalan lancar pada infrastruktur moderat, meskipun fitur enterprise memerlukan lisensi komersial.

Kriteria pemilihan harus memprioritaskan kapabilitas operasional terlebih dahulu. Tim yang membutuhkan zero-ops memilih Pinecone atau Weaviate Cloud. Organisasi dengan kapasitas SRE yang nyaman dengan workload Kubernetes stateful mendapatkan penghematan biaya dan kontrol dari Milvus, Qdrant, atau Weaviate self-hosted. Persyaratan compliance terkadang mengeliminasi opsi—Pinecone dan Weaviate Cloud menawarkan kepatuhan SOC 2 dan HIPAA, sementara mandat on-premise memerlukan solusi self-hosted.

Pemilihan model embedding mempengaruhi biaya dan kualitas retrieval

Model embedding mengkonversi teks menjadi representasi vektor, dan pemilihan model secara langsung mempengaruhi akurasi retrieval. Lanskap Desember 2025 menawarkan tiga opsi komersial terkemuka plus beberapa alternatif open-source yang kuat.

Voyage AI memimpin benchmark MTEB, dengan voyage-3-large mengungguli OpenAI text-embedding-3-large sebesar 9,74% dan Cohere embed-v3-english sebesar 20,71% di seluruh domain yang dievaluasi.¹¹ Voyage AI mendukung context window 32K-token (dibandingkan 8K untuk OpenAI dan 512 untuk model Cohere lama), memungkinkan pemrosesan dokumen lebih panjang tanpa chunking. Embedding 1024-dimensi berharga $0,06 per juta token—2,2x lebih murah dari OpenAI dan 1,6x lebih murah dari Cohere—sambil memerlukan 3x lebih sedikit penyimpanan vektor dibandingkan embedding 3072-dimensi OpenAI.

OpenAI text-embedding-3-large menawarkan opsi paling teruji untuk deployment produksi. Model mendukung dimensi output yang dapat dikonfigurasi dari 256 hingga 3072, memungkinkan tradeoff biaya-penyimpanan. Dengan harga $0,13 per juta token, OpenAI berada di tengah spektrum harga sambil menyediakan uptime yang andal dan dokumentasi ekstensif. Organisasi yang sudah menggunakan API inference OpenAI sering menstandarisasi embedding mereka untuk kesederhanaan operasional.

Cohere embed-v4 mencapai skor MTEB tertinggi (65,2) per November 2025, dioptimalkan khusus untuk search dan retrieval daripada embedding tujuan umum.¹² Embedding Cohere berpasangan secara alami dengan reranker Cohere untuk pipeline retrieval dua tahap. Model ini unggul dalam aplikasi multibahasa, mendukung lebih dari 100 bahasa dengan cross-lingual retrieval yang kuat.

Alternatif open-source termasuk model BGE, E5, dan GTE memungkinkan embedding self-hosted dalam skala besar. Organisasi yang memproses miliaran dokumen sering men-deploy model ini pada infrastruktur GPU internal untuk menghilangkan biaya per-token. Self-hosting memerlukan pengelolaan pembaruan model, perencanaan kapasitas, dan optimasi inference—tradeoff yang masuk akal hanya pada skala signifikan.

Keputusan model embedding berdampak ke seluruh sistem. Mengubah model nanti memerlukan re-embedding korpus dokumen lengkap, proses yang memakan waktu, compute, dan berpotensi mengganggu layanan. Sistem produksi harus mengevaluasi model terhadap benchmark domain-spesifik daripada mengandalkan skor MTEB generik. Model yang unggul dalam pengetahuan umum mungkin berkinerja buruk pada teks hukum, medis, atau keuangan.

Strategi chunking menentukan presisi retrieval

Chunking dokumen menciptakan unit atomik yang dicari sistem retrieval. Pemilihan strategi chunking termasuk di antara keputusan infrastruktur paling berdampak, dengan potensi variasi recall 9% antara pendekatan terbaik dan terburuk.¹³

Fixed-size chunking membagi dokumen pada jumlah token yang telah ditentukan tanpa memperhatikan struktur konten. Pendekatan ini bekerja baik untuk korpora homogen—artikel berita, deskripsi produk, atau dokumen terstandarisasi. Implementasi memerlukan kompleksitas minimal, menjadikan fixed-size chunking titik awal alami untuk prototipe. Sebagian besar sistem produksi menggunakan chunk 400-512 token dengan overlap 50-100 token, menyeimbangkan granularitas retrieval dengan preservasi konteks.

Semantic chunking membagi dokumen pada batas yang bermakna—jeda paragraf, header bagian, atau pergeseran tematik—mempertahankan ide-ide koheren dalam setiap chunk. Implementasi menggunakan embedding kalimat untuk mendeteksi batas semantik, memisahkan ketika kesamaan antara kalimat yang berdekatan turun di bawah threshold. Semantic chunking meningkatkan recall hingga 9% untuk konten naratif seperti dokumentasi, FAQ, dan data percakapan.¹⁴ Pendekatan ini memerlukan lebih banyak compute selama ingestion dan tuning threshold kesamaan yang cermat.

Recursive chunking menerapkan aturan splitting hierarkis, pertama mencoba split besar (jeda bagian), kemudian secara progresif lebih kecil (jeda paragraf, jeda kalimat) sampai chunk mencapai ukuran target. RecursiveCharacterTextSplitter LangChain mengimplementasikan pola ini, mencapai performa kuat di berbagai jenis dokumen tanpa tuning per-korpus. Recursive chunking menyeimbangkan kesederhanaan implementasi dengan kualitas retrieval, menjadikannya rekomendasi default untuk sistem baru.

Page-level chunking muncul dari benchmark NVIDIA yang menunjukkan akurasi 0,648 dengan variansi terendah di berbagai jenis dokumen.¹⁵ Untuk dokumen terstruktur seperti laporan dan makalah, memperlakukan setiap halaman sebagai chunk mempertahankan hubungan spasial dan referensi silang. Pendekatan page-level bekerja buruk untuk dokumen tanpa batas halaman yang jelas (HTML, log chat, kode) tetapi unggul untuk korpora yang didominasi PDF.

Hierarchical chunking membangun indeks multi-level dengan granularitas bertingkat—level bagian, subbagian, paragraf, dan kalimat. Retrieval pertama mengidentifikasi bagian yang relevan, kemudian menggali ke dalam p

[Konten dipotong untuk penerjemahan]