RAG 2026: Kenapa RAG Naif Gagal dan Arsitektur yang Benar

RAG naif, yaitu chunk dokumen lalu embed lalu ambil top-k, punya angka kegagalan yang bisa diukur. Eksperimen Anthropic yang terbit 19 September 2024 menunjukkan retrieval top-20 masih gagal 5,7% pada chunking biasa. Contextual Retrieval menurunkan angka itu 49% (5,7% jadi 2,9%), dan 67% (jadi 1,9%) kalau ditambah reranking. Jadi masalah utamanya bukan model bahasa, tapi cara chunk dan cara ambil. Artikel ini bedah arsitektur yang benar, biayanya, dan kapan cukup pakai Postgres.

TL;DR

• Retrieval failure rate itu metrik yang bisa diukur, bukan perasaan “kayaknya jawabannya kurang nyambung”.
• Contextual Retrieval turunkan gagal retrieval 49%, plus reranking jadi 67% (sumber: Anthropic, 19 Sep 2024).
• Posisi informasi di tengah konteks panjang bikin model lebih sering salah, ini temuan “Lost in the Middle” (TACL 2023).
• pgvector v0.8.7 sudah cukup untuk mayoritas proyek, dengan HNSW dan halfvec sampai 4.000 dimensi.
• Embedding 1 juta chunk 500 token di text-embedding-v4 kira-kira USD 35 sekali jalan, hitungan dari harga list USD 0,07 per 1 juta token.

Kenapa RAG naif gagal di produksi?

Karena chunk yang dipotong tanpa konteks sering tidak bisa menjawab pertanyaan yang sebenarnya. Satu potongan 500 token bisa berisi “biaya administrasi di atas berlaku mulai Januari”, tanpa menyebut produk, cabang, atau tahun apa pun. Embedding-nya jadi vektor yang mirip ribuan kalimat lain, dan yang terambil bukan bukti yang tepat.

Paper “Seven Failure Points When Engineering a Retrieval Augmented Generation System” (arXiv 2401.05856, 11 Januari 2024) mendokumentasikan tujuh titik gagal dari tiga studi kasus di domain riset, pendidikan, dan biomedis. Dua kesimpulan mereka penting:

• Validasi RAG baru benar-benar bisa dilakukan saat sistem berjalan, bukan di meja desain.
• Ketahanan RAG itu berevolusi lewat iterasi, bukan dirancang sekali jadi.

Penyebab paling umum di lapangan biasanya cuma tiga: chunk terlalu kecil, chunk terlalu besar, dan tidak ada pengaman saat retrieval kosong. Tiga-tiganya bisa dideteksi tanpa mengganti model.

Apa itu Contextual Retrieval dan berapa hasilnya?

Contextual Retrieval adalah teknik menambahkan konteks dokumen ke setiap chunk sebelum di-embed, lalu menggabungkan pencarian vektor dengan BM25, dan opsional menambah reranker. Hasil terukurnya ada di pengumuman resmi Anthropic.

Angka lengkapnya:

• Contextual Embeddings saja: gagal retrieval top-20 turun 35%, dari 5,7% ke 3,7%.
• Contextual Embeddings plus Contextual BM25: turun 49%, dari 5,7% ke 2,9%.
• Ditambah reranking: turun 67%, dari 5,7% ke 1,9%.

Cara kerjanya sederhana. Sebelum chunk di-embed, model kecil diminta menulis satu sampai dua kalimat konteks: dokumen ini tentang apa, bagian ini membahas apa, dan posisinya di mana. Kalimat itu ditempel di depan chunk. Biayanya naik karena ada panggilan LLM tambahan per chunk, tapi bisa ditekan drastis dengan prompt caching pada dokumen yang sama, karena prefix-nya identik untuk semua chunk dari satu berkas.

Efek sampingnya: chunk jadi lebih mahal saat indexing, tapi murah saat query. Untuk dokumen yang jarang berubah, ini trade-off yang biasanya menang.

Posisi informasi juga menentukan jawaban

Paper “Lost in the Middle: How Language Models Use Long Contexts” (arXiv 2307.03172, terbit di TACL 2023) menemukan performa model paling bagus saat informasi relevan ada di awal atau akhir konteks, dan turun signifikan saat informasi itu ada di tengah konteks panjang.

Implikasi praktisnya buat RAG:

• Jangan asal menumpuk 20 chunk ke prompt dengan urutan acak.
• Taruh chunk paling relevan di awal dan akhir, bukan di tengah.
• Lebih baik 5 chunk yang tepat daripada 20 chunk yang setengah relevan.

Ini juga alasan kenapa reranking penting. Reranker memindahkan chunk yang benar-benar menjawab ke posisi atas, dan itu bukan kosmetik.

Berapa biaya embedding 1 juta chunk?

Untuk 1 juta chunk dengan rata-rata 500 token, totalnya 500 juta token. Dengan harga text-embedding-v4 di region Singapura sebesar USD 0,07 per 1 juta token input, biaya sekali indexing sekitar USD 35. Harga dan batas dimensi ini diambil dari dokumentasi resmi Model Studio yang terakhir diperbarui 11 Oktober 2026.

Detail modelnya:

• Dimensi vektor bisa diatur dari 64 sampai 2.048.
• Harga input teks USD 0,07 per 1 juta token di Singapura, USD 0,072 di Beijing.
• Ada jalur batch file dengan harga lebih murah, USD 0,036 per 1 juta token di Beijing.
• Klaim peningkatan sampai 40% dibanding versi sebelumnya pada MTEB multilingual, Chinese-English, dan code retrieval.

Kalau butuh kualitas lebih tinggi dan mau self-host, Qwen3-Embedding-8B mencetak skor 70,58 di MTEB multilingual per 5 Juni 2025, berlisensi Apache-2.0, dan mendukung dimensi 32 sampai 4.096. Bobotnya 7,57 miliar parameter, jadi butuh GPU yang serius. Model 0,6B dan 4B di keluarga yang sama lebih masuk akal untuk VPS kecil.

Kalau mau jalur API tanpa mengurus GPU, Qwen di Model Studio menyediakan embedding dan LLM dalam satu tagihan, jadi tidak perlu dua vendor untuk indexing dan generation.

Kapan cukup pakai pgvector, kapan perlu vector DB khusus?

Untuk mayoritas proyek sampai puluhan juta vektor, Postgres dengan pgvector sudah cukup. Repo pgvector per 20 Oktober 2026 punya 23.414 bintang, 1.357 fork, dan tag terbaru v0.8.7. Fitur yang relevan:

• Index HNSW untuk kecepatan query, IVFFlat untuk build lebih murah.
• Tipe halfvec sampai 4.000 dimensi, jadi hemat memori.
• Dukungan quantisasi biner lewat operator bit.
• Semua jalan di database yang sama dengan data transaksional, tidak perlu sinkronisasi dua sistem.

Vector DB khusus masuk hitungan kalau salah satu kondisi ini benar:

• Kebutuhan filter metadata sangat kompleks dan volume query sangat tinggi.
• Tim butuh scaling horizontal otomatis tanpa mengurus Postgres.
• Data vektor mencapai ratusan juta sampai miliaran, dan biaya RAM Postgres sudah tidak masuk.

Kalau belum ada bukti salah satu kondisi di atas, menambah vector DB justru menambah satu sistem yang harus dijaga. Mulai dari Postgres dulu, ukur, baru pindah kalau angkanya memaksa.

Tiga lapisan yang bikin RAG tahan produksi

Arsitektur yang saya sarankan untuk 2026 bukan satu trik, tapi tiga lapisan yang masing-masing punya fungsi.

1. Indexing berkonteks. Setiap chunk diberi ringkasan konteks, lalu di-embed. Simpan juga versi teks aslinya untuk BM25.
2. Hybrid retrieval plus reranking. Gabungkan hasil vektor dan BM25, lalu rerank. Ini yang menurunkan failure rate dari 5,7% ke 1,9% di eksperimen Anthropic.
3. Guard saat retrieval kosong. Kalau skor tertinggi di bawah ambang, jawab “tidak ditemukan di dokumen” alih-alih mengarang. Ini yang paling sering dilewatkan, padahal paling murah.

Lapisan keempat yang opsional: evaluasi berkala dengan set pertanyaan berlabel. Tanpa set ini, semua perbaikan cuma tebakan.

Yang harus diukur sebelum ganti arsitektur

Ukur retrieval failure rate dulu, jangan langsung ganti model. Ambil 50 sampai 100 pertanyaan nyata, tentukan chunk mana yang seharusnya terambil, lalu hitung berapa persen yang gagal masuk top-20. Angka itu yang jadi baseline.

Setelah baseline ada, uji perubahan satu per satu: chunk size, contextual prefix, BM25, reranker. Paper Seven Failure Points menegaskan bahwa ketahanan RAG berevolusi lewat operasi, jadi evaluasi harus jalan terus, bukan sekali sebelum rilis.

Rekomendasi Tools & Layanan

• Embedding API: text-embedding-v4 di Model Studio, dimensi fleksibel 64 sampai 2.048, harga USD 0,07 per 1 juta token input di Singapura.
• Vector store: PostgreSQL plus pgvector v0.8.7 untuk mayoritas kasus. Self-host di ECS Alibaba Cloud kalau mau kontrol penuh atas data dan biaya bulanan.
• Reranker: Qwen3-Reranker dari keluarga yang sama, atau API rerank kalau tidak mau mengurus GPU.
• Evaluasi: set pertanyaan berlabel minimal 50 buah, dijalankan ulang setiap kali pipeline berubah.

FAQ

Apakah RAG selalu lebih baik daripada fine-tuning?

Tidak. RAG cocok untuk pengetahuan yang sering berubah dan butuh sitasi. Fine-tuning cocok untuk gaya, format, atau perilaku yang konsisten. Banyak sistem produksi memakai keduanya.

Berapa chunk size yang ideal?

Tidak ada angka ajaib. Yang bisa diukur adalah retrieval failure rate pada set pertanyaan sendiri. Mulai dari 300 sampai 800 token, lalu geser berdasarkan hasil evaluasi, bukan berdasarkan artikel blog.

Apakah BM25 masih relevan di 2026?

Masih. Eksperimen Anthropic menunjukkan penggabungan embedding dengan BM25 menurunkan failure rate dari 3,7% ke 2,9%. Pencarian keyword menangkap nama produk, kode, dan angka yang sering lolos dari pencarian vektor.

Berapa biaya menjalankan RAG untuk 1 juta chunk?

Sekitar USD 35 untuk embedding sekali jalan dengan text-embedding-v4 di Singapura, ditambah biaya LLM untuk membuat konteks per chunk dan biaya penyimpanan vektor. Biaya query jauh lebih kecil karena hanya memproses beberapa chunk per pertanyaan.

Apakah pgvector cukup untuk produksi?

Cukup untuk mayoritas beban sampai puluhan juta vektor, dengan HNSW dan halfvec. Pindah ke vector DB khusus kalau volume, kompleksitas filter, atau kebutuhan scaling sudah terbukti melampaui kapasitas Postgres.

Kesimpulan

RAG naif gagal bukan karena modelnya bodoh, tapi karena chunk kehilangan konteks dan retrieval tidak pernah diukur. Perbaikannya berurutan: beri konteks pada chunk, gabungkan vektor dengan BM25, tambah reranker, lalu pasang guard saat hasil kosong. Tiga langkah pertama sudah terbukti menurunkan failure rate dari 5,7% ke 1,9%. Sisanya soal disiplin mengukur, bukan soal ganti framework.