Mengapa strategi chunking begitu penting dalam pipeline RAG?

Chunking adalah keputusan paling berdampak dalam pipeline RAG karena menentukan apakah konteks yang tepat bisa diambil sama sekali. Chunking ukuran tetap mudah diimplementasikan tetapi buta secara semantik — ia bisa memotong tabel, blok kode, atau langkah-langkah di tengah jalan. Beralih dari chunking ukuran tetap ke chunking semantik (memisahkan di batas paragraf atau judul) menghasilkan peningkatan 25% dalam relevansi jawaban.

Apa itu HyDE dan mengapa ia meningkatkan kualitas retrieval?

HyDE (Hypothetical Document Embedder) bekerja dengan pertama-tama menggunakan LLM murah untuk menghasilkan jawaban hipotetis atas pertanyaan pengguna, lalu meng-embed jawaban tersebut sebagai kueri pencarian vektor. Karena jawaban hipotetis secara semantik lebih dekat ke dokumen relevan daripada pertanyaan itu sendiri, HyDE secara konsisten mengungguli embedding pertanyaan langsung dan bisa menghasilkan peningkatan 20–30% dalam recall retrieval.

Berapa banyak chunk yang sebaiknya dikirim ke LLM untuk generation?

Mengirim lebih banyak chunk tidak selalu meningkatkan kualitas jawaban. Riset (makalah 'Lost in the Middle') menunjukkan LLM secara konsisten mengabaikan informasi yang berada di tengah konteks panjang. Mempertahankan konteks yang diambil hingga 3–5 chunk berkualitas tinggi yang telah di-rerank, bukan 10 atau lebih yang mediocre, menghasilkan jawaban yang lebih baik.

Apa itu reranker dan kapan biayanya sepadan?

Reranker adalah model cross-encoder yang menilai pasangan (query, document_chunk) secara langsung untuk relevansi — lebih akurat dari kesamaan vektor tetapi terlalu lambat untuk memindai seluruh indeks. Pola yang direkomendasikan adalah menjalankan pencarian vektor cepat di seluruh indeks, mengambil 20 kandidat teratas, lalu melakukan rerank dan memilih 5 teratas untuk generation. Cohere Rerank dikenakan biaya $2 per 1.000 kueri, sehingga praktis untuk sebagian besar beban kerja produksi.

Bagaimana sistem RAG seharusnya dipantau di produksi?

Sistem RAG menurun secara diam-diam, sehingga pemantauan khusus sangat penting. Sinyal utama yang perlu dilacak adalah latensi retrieval, skor kualitas konteks, groundedness jawaban, dan kesegaran dokumen. Dokumen yang kedaluwarsa harus diindeks ulang secara otomatis via pekerjaan mingguan, dan versi model embedding harus dilacak agar embedding diregenerasi setelah pembaruan model apa pun.

Pelajaran Pipeline RAG di Produksi: Yang Jarang Dibahas

Pelajaran Produksi Pipeline RAG: Yang Tidak Diceritakan Siapa Pun

Pelajaran keras dari membangun sistem RAG produksi — strategi indeksasi, kegagalan chunking, kualitas retrieval, dan metrik yang benar-benar penting.

Matthews Wong

Software Engineer

Juni 202512 menit baca

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.

Chunking: Fondasi yang Bergantung pada Segalanya

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.

Semantic Chunking vs Fixed-Size Chunking

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.

Metadata Dokumen sebagai Pengganda Retrieval

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 Citations

Peningkatan 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.

Pilihan Database Vektor: pgvector vs Pinecone vs Qdrant

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.

Mengevaluasi Kualitas Retrieval

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-5

Reranking: Jembatan Antara Retrieval dan Generation

Retrieval 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.

Menangani Kueri Multi-Langkah dan Multi-Hop

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.

Pemantauan Produksi untuk Sistem RAG

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.