Tutorial Pruning RAG Context untuk Optimasi LLM di Produksi

Retrieval-Augmented Generation (RAG) masih menjadi fondasi andal untuk menjawab pertanyaan teknis kompleks di atas knowledge base besar. Namun di produksi, retrieved chunks seringkali membanjiri context window dengan informasi yang sebenarnya tidak dibutuhkan generator untuk menjawab pertanyaan user. Menurut laporan dari kapa.ai, retrieved chunks bisa menyumbang dua pertiga dari total biaya satu query LLM. Artinya, setiap chunk yang berhasil dibuang sebelum masuk ke generator langsung mengurangi cost secara signifikan.

Solusi yang diimplementasikan kapa.ai adalah menambahkan satu langkah pruner berbasis small LLM di antara retriever dan generator. Pruner ini membaca pertanyaan user dan seluruh chunk yang berhasil di-retrieve secara bersamaan, lalu membuang chunk yang tidak esensial. Hasilnya: 68% context dibuang, 96% recall tetap terjaga, dan total cost per query turun sepertiga. Teknik ini tidak menggantikan reranker, melainkan bekerja sebagai filter kedua yang lebih cerdas dan lebih murah.

Mengapa Reranker Biasa Tidak Cukup

Kebanyakan pipeline RAG sudah punya reranker yang menyaring chunk berdasarkan relevance score. Masalahnya, reranker bekerja secara pointwise: setiap chunk dinilai terhadap query secara individual, tanpa melihat chunk lain dalam satu set retrieval. Akibatnya, chunk yang sebenarnya penting karena melengkapi chunk lain bisa terbuang hanya karena tidak secara eksplisit menyebut keyword query.

Selain itu, reranker score bersifat relatif per query, tidak terkalibrasi secara absolut. Tidak ada threshold universal seperti "buang semua yang di bawah 0.7" karena skala score bisa berbeda-beda tergantung query. Solusi yang benar harus menilai chunk secara listwise: melihat seluruh set chunk sebagai satu kesatuan dan mengevaluasi kontribusi relatif masing-masing.

Konsep Pruning dengan Small LLM

Pruner bekerja sebagai satu LLM call tambahan yang ditempatkan setelah reranker dan sebelum generator. LLM ini menerima input berupa pertanyaan user dan seluruh chunk hasil retrieval, lalu memberikan grade pada tiap chunk menggunakan skala lima level:

• ESSENTIAL (5): Jawaban tidak bisa dihasilkan tanpa chunk ini, baik karena chunk tersebut langsung menjawab maupun berisi definisi atau prerequisite yang dibutuhkan chunk lain.

• CONTRIBUTING (4): Tidak menjawab sendiri, tapi memberikan informasi yang diperlukan jawaban lengkap ketika dikombinasikan dengan chunk lain.

• RELEVANT (3): Berisi informasi berkaitan yang berguna untuk konteks tambahan, meski tidak strictly diperlukan jawaban.

• TANGENTIAL (2): Berhubungan lemah dengan topik, hanya menyebutkan konsep yang sama tanpa detail yang membantu jawaban.

• IRRELEVANT (1): Tidak berkontribusi sama sekali terhadap jawaban.

Setelah grading, pruner hanya mem-forward chunk dengan grade tertentu ke generator, biasanya yang ESSENTIAL dan CONTRIBUTING saja. Chunk RELEVANT ke bawah dibuang. Threshold bisa dikonfigurasi tergantung seberapa agresif Anda ingin menghemat cost dan seberapa besar risiko kehilangan informasi yang bisa diterima.

Langkah Implementasi Pruner di Pipeline RAG

Langkah 1: Persiapkan Prompt Grading

Buat prompt yang eksplisit meminta LLM menilai setiap chunk relatif terhadap query dan chunk lainnya. Prompt harus menekankan bahwa penilaian bersifat listwise, bukan independent per chunk. Berikut struktur prompt yang bisa dipakai:

Anda adalah pruner untuk pipeline RAG. Tugas Anda: baca pertanyaan user dan seluruh chunk dokumen di bawah, lalu grade tiap chunk dengan skala 1-5 berdasarkan seberapa esensial chunk tersebut untuk menjawab pertanyaan. Perhatikan bahwa chunk bisa saling melengkapi. Chunk A yang tidak menyebut keyword query bisa jadi ESSENTIAL jika chunk B yang menyebut keyword bergantung pada definisi di chunk A.

Langkah 2: Pilih Small LLM yang Cost-Efektif

Pruner harus menggunakan model yang jauh lebih murah daripada generator. Model seperti GPT-4o-mini, Claude 3 Haiku, atau bahkan open source model seperti Llama 3.1 8B via local inference bisa jadi pilihan. Yang penting: pruner harus cukup kuat untuk memahami relasi antar chunk, tapi tidak perlu sekuat generator utama karena outputnya hanya grade, bukan jawaban natural language.

Sebagai referensi, kapa.ai menggunakan model yang harganya sekitar 1% dari biaya generator utama per token. Karena pruner memproses chunk yang jauh lebih pendek daripada jawaban generator, total cost pruner biasanya hanya sebagian kecil dari penghematan yang dihasilkan.

Langkah 3: Integrasikan ke Pipeline Existing

Tambahkan pruner node setelah reranker di pipeline Anda. Implementasi paling sederhana adalah membuat fungsi Python yang menerima list chunk dan query, memanggil small LLM API dengan prompt grading, lalu memfilter chunk berdasarkan threshold grade:

async def prune_chunks(query: str, chunks: list[str], threshold: int = 4):
    prompt = build_pruner_prompt(query, chunks)
    response = await small_llm.chat.completions.create(
        model="gpt-4o-mini",
        messages=[{"role": "user", "content": prompt}],
        temperature=0
    )
    grades = parse_grades(response.choices[0].message.content)
    return [c for c, g in zip(chunks, grades) if g >= threshold]

Langkah 4: Evaluasi dengan Recall Metrics

Sebelum deploy ke produksi, ukur dampak pruning terhadap recall. Caranya: jalankan eval set yang sudah punya ground truth jawaban, bandingkan hasil jawaban generator dengan dan tanpa pruner. Jika recall turun drastis, naikkan threshold atau perbaiki prompt grading. Jika recall tetap tinggi tapi cost tidak turun, turunkan threshold sedikit.

Metric yang paling penting adalah compression-recall curve: seberapa banyak context yang berhasil dikompresi untuk setiap titik recall yang dipertahankan. Kurva ideal menunjukkan kompresi tinggi dengan penurunan recall yang minimal.

Langkah 5: Optimasi dengan Structured Output

Gunakan fitur structured output atau JSON mode dari LLM provider agar parsing grade lebih robust. Alih-alih meminta LLM menulis penjelasan panjang, minta output JSON array berisi object dengan field chunk_id dan grade. Ini mengurangi token output pruner sendiri, yang artinya lebih murah lagi:

{
  "evaluations": [
    {"chunk_id": 0, "grade": 5, "reason": "contains direct answer"},
    {"chunk_id": 1, "grade": 4, "reason": "prerequisite for chunk 0"},
    {"chunk_id": 2, "grade": 1, "reason": "unrelated topic"}
  ]
}

Kesimpulan

Pruning RAG context dengan small LLM adalah teknik praktis yang bisa langsung mengurangi cost produksi tanpa mengorbankan kualitas jawaban. Kunci keberhasilannya ada pada pendekatan listwise grading yang melihat chunk sebagai set, bukan sebagai entitas individual. Dengan implementasi yang tepat, pipeline RAG Anda bisa lebih hemat dan tetap akurat di hadapan user.