AI
Pelajaran Produksi Pipeline RAG: Yang Tidak Diceritakan Siapa Pun
Agustus 202512 menit baca
AI
Retrieval-Augmented Generation terlihat sangat sederhana dalam tutorial: chunk dokumen, embed, simpan di database vektor, retrieve saat query, kirim ke LLM. Kenyataan: RAG produksi adalah masalah rekayasa keandalan dan kualitas yang membutuhkan berbulan-bulan untuk dikerjakan dengan benar. Saya telah membangun sistem RAG untuk konten fitness di AI Gymbro dan bereksperimen dengannya untuk dokumentasi ERP di Commsult.
Keputusan paling berdampak dalam pipeline RAG adalah cara Anda meng-chunk dokumen. Titik awal saya: chunk 512 token dengan overlap 128 token untuk konten teknis padat, chunk 256 token dengan overlap 64 token untuk konten gaya FAQ.
Chunking ukuran tetap membelah secara acak di mana-mana. Chunking semantik menghormati struktur dokumen: pisahkan di batas paragraf, batas judul, atau batas kalimat. Saya melihat peningkatan 25% dalam relevansi jawaban saat beralih dari chunking tetap ke semantik.
Setiap chunk yang Anda simpan harus membawa metadata kaya: judul dokumen, judul bagian, jenis dokumen, tanggal dibuat, dan tag domain-spesifik apa pun. Metadata ini memungkinkan retrieval hybrid: Anda dapat memfilter berdasarkan metadata sebelum atau setelah pencarian vektor.
Production RAG Pipeline Architecture
Documents
│
▼
┌──────────────────────────────────────────┐
│ Ingestion Pipeline │
│ 1. Semantic Chunking (respect headings) │
│ 2. Metadata Extraction (title, type, │
│ date, tags) │
│ 3. Embedding (text-embedding-3-small) │
│ 4. Store in pgvector / Qdrant │
└──────────────────────────────────────────┘
User Query
│
▼
┌──────────────────────────────────────────┐
│ Query Pipeline │
│ │
│ 1. HyDE: Generate hypothetical answer │
│ (cheap LLM call) │
│ 2. Embed hypothetical answer │
│ 3. Vector search top-20 │
│ 4. Metadata filter (optional) │
│ 5. Rerank top-5 (Cohere / bge) │
│ 6. Pass to LLM with retrieved context │
└──────────────────────────────────────────┘
│
▼
Generated Answer + Source CitationsPeningkatan RAG paling efektif yang saya temukan adalah menambahkan langkah 'hypothetical document embedder' (HyDE). Saat pengguna mengajukan pertanyaan, pertama gunakan LLM murah untuk menghasilkan jawaban hipotetis atas pertanyaan tersebut, kemudian embed jawaban hipotetis itu dan gunakan sebagai kueri pencarian. Peningkatan kualitas: 20-30% peningkatan dalam recall retrieval pada evaluasi saya.
Saya telah menggunakan tiga database vektor di produksi. pgvector adalah pilihan jelas jika Anda sudah menggunakan PostgreSQL. Pinecone sepenuhnya terkelola dan menangani miliaran vektor. Qdrant dapat di-self-host, memiliki performa filtering terbaik, dan mendukung pencarian hybrid sparse+dense secara native.
Kesalahan RAG terbesar adalah mengoptimalkan kualitas jawaban end-to-end tanpa memahami kualitas retrieval secara terpisah. Ukur presisi dan recall retrieval secara independen menggunakan set uji dari pasangan query-dokumen. Saya menjalankan 50 kueri evaluasi mingguan terhadap pipeline RAG saya dan melacak recall@5 secara terpisah dari kualitas jawaban.
-- pgvector: HNSW index for production performance
CREATE EXTENSION IF NOT EXISTS vector;
CREATE TABLE documents (
id BIGSERIAL PRIMARY KEY,
content TEXT NOT NULL,
embedding VECTOR(1536) NOT NULL,
metadata JSONB NOT NULL DEFAULT '{}'
);
-- HNSW index — tune m and ef_construction for your dataset
CREATE INDEX ON documents
USING hnsw (embedding vector_cosine_ops)
WITH (m = 32, ef_construction = 128);
-- Retrieval with metadata filter + vector search
SELECT id, content, metadata,
1 - (embedding <=> $1::vector) AS similarity
FROM documents
WHERE metadata->>'type' = 'exercise_technique' -- metadata filter
ORDER BY embedding <=> $1::vector -- vector search
LIMIT 20; -- retrieve 20, then rerank to top-5Retrieval kesamaan vektor cepat tetapi tidak presisi. Reranker adalah model cross-encoder yang mengambil pasangan (query, document_chunk) dan memberi skor relevansi langsung. Menjalankan reranker pada 20 hasil teratas pencarian vektor dan memilih 5 teratas untuk generation secara konsisten meningkatkan kualitas jawaban.
Mengambil lebih banyak chunk tampaknya selalu meningkatkan kualitas. Dalam praktiknya, memasukkan 10+ chunk ke dalam jendela konteks sering menurunkan kualitas jawaban karena LLM kesulitan mengidentifikasi informasi paling relevan. Pertahankan konteks yang diambil hingga 3-5 chunk berkualitas tinggi yang telah di-rerank, bukan 10+ yang mediocre.
RAG sederhana mengambil sekali dan menghasilkan. Tetapi kueri kompleks memerlukan retrieval multi-hop — pertama ambil profil pengguna, kemudian ambil latihan, kemudian ambil data kemajuan. Bangun pipeline RAG Anda untuk mendukung retrieval iteratif.
Sistem RAG menurun secara diam-diam. Pantau: latensi retrieval, skor kualitas konteks, groundedness jawaban, dan kesegaran dokumen. Indeks ulang dokumen yang kedaluwarsa secara otomatis via pekerjaan mingguan.