Saya Menghabiskan $500 untuk Infrastruktur RAG Sebelum Memperbaiki 7 Kesalahan Ini

Saya membangun pipeline RAG untuk pencarian dokumen pribadi. Biayanya mencapai $500 untuk komputasi dan berminggu-minggu proses debugging. Hasilnya buruk. Pengguna mendapatkan jawaban yang salah dan kueri terasa lambat.

Saya mengaudit pipeline tersebut. Saya menemukan 7 kesalahan. Memperbaikinya mengubah segalanya.

  1. Perbaikan Token Chunking Saya membagi dokumen berdasarkan 512 token. Hal ini merusak konteks. Penjelasan API bisa terpotong di tengah kalimat. LLM menerima fragmen-fragmen dan memberikan jawaban yang tidak masuk akal. Solusinya: Gunakan semantic chunking.
  • Bagi berdasarkan batasan alami seperti paragraf atau header.
  • Gunakan parent-document retrieval.
  • Buat child chunks kecil untuk pencarian.
  • Kembalikan dokumen parent secara utuh ke LLM.
  • Tambahkan overlap sebesar 10-20% antar chunk.
  1. Bobot Hybrid Search yang Buruk Saya menggunakan pembagian 50/50 untuk pencarian vector dan keyword. Ini gagal untuk dokumen teknis. Pengguna teknis membutuhkan kecocokan keyword yang tepat. Solusinya: Gunakan bobot dinamis.
  • Kueri faktual: 35% vector, 65% keyword.
  • Kueri semantik: 75% vector, 25% keyword.
  • Kueri umum: 60% vector, 40% keyword.
  1. Over-tuning Parameter HNSW Saya mengatur ef_construction ke nilai maksimum. Ini membuat server saya crash. Hal ini menghabiskan semua RAM yang tersedia. Solusinya: Gunakan parameter yang sesuai.
  • Atur M antara 8 dan 32.
  • Atur ef_construction ke 200.
  • Atur ef_search ke 50. Penggunaan memori turun 70%.

  1. Model Embedding yang Terlalu Umum Saya menggunakan model yang dilatih pada Wikipedia. Dokumen saya adalah runbook teknik. Model tersebut tidak memahami domain saya. Solusinya: Gunakan model yang telah di-fine-tune untuk konten teknis atau kode.

  2. Tidak Ada Query Rewriting Pengguna mengajukan pertanyaan secara natural. Dokumen teknis menggunakan istilah formal. Keduanya tidak cocok. Solusinya: Tambahkan langkah LLM ringan untuk menulis ulang kueri.

  • Pengguna bertanya: "mengapa build saya lambat"
  • Sistem menulis ulang menjadi: "optimasi performa pipeline CI"
  • Ini meningkatkan recall sebesar 40%.

  1. Hasil yang Redundan Mengambil 10 chunk teratas sering kali memberikan paragraf yang sama sebanyak tiga kali. LLM mengulang-ulang jawabannya. Solusinya: Gunakan Maximal Marginal Relevance (MMR) untuk memastikan diversitas dalam hasil.

  2. Menguji Hal yang Salah Saya menguji seluruh pipeline sekaligus. Saya tidak tahu apakah masalahnya ada pada retrieval atau pada LLM. Solusinya: Pisahkan evaluasi retrieval.

  • Pantau hit rate.
  • Pantau Mean Reciprocal Rank (MRR).
  • Buat set pengujian berisi 100 pasangan kueri-dokumen.

Hasil setelah perbaikan:

  • Relevansi jawaban: 45% ke 85%
  • Latensi: 3.2s ke 1.8s
  • Biaya bulanan: $180 ke $95

Perbaiki chunking terlebih dahulu. Kemudian weights. Lalu kualitas embedding.

Sumber: https://dev.to/kollittle/i-spent-500-on-rag-infrastructure-before-realizing-these-7-mistakes-were-killing-my-results-iph