Pengalaman Production RAG dari pemrosesan lebih dari 5 juta dokumen

• Selama 8 bulan menjalankan proyek RAG (Retrieval-Augmented Generation), penulis dapat membedakan metode yang benar-benar efektif dan yang hanya membuang waktu
• Pada tahap awal, prototipe cepat diselesaikan menggunakan Langchain dan Llamaindex, tetapi dari umpan balik pengguna nyata terlihat adanya keterbatasan performa
• Faktor terbesar yang meningkatkan performa pencarian dokumen adalah pembuatan kueri, reranking, strategi chunking, pemanfaatan metadata, dan query routing
• Dalam praktiknya, penulis membangun pipeline kustom dengan memilih secara fleksibel vector database, embedding, reranking, LLM, dan komponen lainnya
• Seluruh pengalaman dan know-how tersebut dirangkum dan dibuka melalui proyek open source (agentset-ai/agentset)

---

Gambaran umum pengalaman membangun Production RAG selama 8 bulan

• Penulis membagikan pengalaman membangun dan mengoperasikan sistem RAG pada dataset berskala besar seperti total 9 juta halaman (Usul AI) dan 4 juta halaman (sebuah perusahaan AI hukum anonim)
• Di awal, penulis mengikuti tutorial YouTube, berpindah dari Langchain ke Llamaindex, dan menyelesaikan prototipe hanya dalam beberapa hari, tetapi saat benar-benar dideploy muncul masalah performa rendah yang hanya bisa disadari oleh pengguna nyata
• Selama beberapa bulan, penulis memperbaiki komponen sistem secara bertahap hingga mencapai performa optimal

Faktor-faktor yang benar-benar berkontribusi pada peningkatan performa (berdasarkan urutan ROI)

1. Pembuatan Kueri (Query Generation)

   • Karena kueri terakhir pengguna tidak dapat memuat seluruh konteks, penulis menggunakan LLM untuk meninjau isi percakapan dan menghasilkan beberapa kueri semantik serta kueri berbasis kata kunci
   • Kueri-kueri ini diproses secara paralel lalu dikirim ke reranker untuk mendapatkan efek memperluas cakupan pencarian dan mengompensasi bias hybrid search

2. Reranking

   • Dampak reranking terhadap performa, yang bisa diimplementasikan hanya dengan sekitar 5 baris kode, jauh lebih besar dari yang dibayangkan
   • Dalam skenario input chunk besar (misalnya 50), proses menyusun ulang dan menyeleksi sebagian chunk teratas (misalnya 15) memberikan ROI paling tinggi
   • Dengan reranking saja, kekurangan dari pipeline yang desainnya kurang matang pun dapat tertutupi dalam kadar yang cukup besar

3. Strategi Chunking (Chunking Strategy)

   • Bagian ini menyita porsi waktu terbesar selama proses pengembangan
   • Diperlukan pemahaman yang akurat terhadap struktur dan pola data, lalu melakukan chunking berdasarkan unit logis serta meninjau langsung agar huruf atau kalimat tidak terpotong di tengah
   • Setiap chunk harus tetap mempertahankan makna yang mandiri

4. Pemanfaatan metadata pada input LLM

   • Alih-alih hanya mengirim teks chunk ke LLM, penulis menambahkan metadata (title, author, dan sebagainya) untuk sangat meningkatkan konteks dan kualitas jawaban

5. Query Routing

   • Untuk tipe pertanyaan yang tidak bisa dijawab dengan RAG (misalnya ringkasan artikel atau permintaan informasi penulis), penulis memperkenalkan router ringan yang mengalihkan kueri tersebut ke jalur pemrosesan API+LLM

Stack praktik lapangan (Our stack)

• Vector database: Azure → Pinecone → Turbopuffer (lebih murah dan secara default mendukung pencarian kata kunci)
• Ekstraksi dokumen: menggunakan pendekatan kustom
• Alat chunking: pada dasarnya Unstructured.io, sedangkan pipeline enterprise menggunakan solusi kustom (Chonkie juga disebut memiliki reputasi baik)
• Model embedding: menggunakan text-embedding-large-3 (model lain belum diuji)
• Reranker: None → Cohere 3.5 → Zerank (tidak terlalu populer, tetapi sangat baik dalam praktik)
• LLM: GPT 4.1 → GPT 5 → GPT 4.1 (terutama menggunakan kredit Azure)

Open source dan kesimpulan

• Semua hasil pembelajaran dan pengalaman praktik dirangkum dalam proyek open source agentset-ai/agentset
• Dirilis dengan lisensi MIT, sehingga dapat digunakan secara bebas dan terbuka untuk pertanyaan lebih lanjut (kontak disediakan)

[GN⁺]

Komentar Hacker News

• Terasa bahwa bagian yang membahas pembuatan kueri sintetis benar-benar penting; dalam praktiknya, pengguna sering memasukkan kueri dengan sangat tidak akurat, jadi awalnya LLM membuat kueri sintetis. Namun, hasilnya terlalu bervariasi tergantung kueri sintetis yang dibuat setiap kali, sehingga mereka membuat tiga versi kueri sekaligus dalam satu panggilan LLM, lalu menelusurinya secara paralel dan menggabungkan daftar hasil yang kuat dengan reciprocal rank fusion. Untuk pencarian mereka memakai hybrid dense + sparse BM25; dense saja lemah untuk istilah teknis. Setelah ditambah reranker, sebagian besar masalah pencarian pun terselesaikan.
  • Menarik melihat penggunaan pendekatan hybrid (BM25 + dense search) untuk menutupi kelemahan model dense terhadap istilah teknis. Model v3 seperti SPLADE yang menyeimbangkan pencarian semantik dan leksikal tampak punya performa bagus, tetapi saya selalu penasaran apakah ini bisa digantikan dengan solusi yang lebih sederhana.
  • Ditekankan bahwa detail seperti pembuatan/optimasi kueri pada akhirnya adalah bagian yang harus ditangani oleh penyedia solusi RAG seperti Amazon, Microsoft, dan OpenAI.
  • Memang benar metode-metode ini adalah best practice saat ini, tetapi tetap terasa ada sesuatu yang kurang terkait strategi tambahan yang bisa mendorong performa satu tingkat lebih tinggi, seperti percabangan selektif model embedding atau kombinasi beragam re-ranker.
  • Sebagai tip terakhir, diusulkan agar sistem juga menyampaikan kepada pengguna bagaimana LLM menafsirkan niat pencarian mereka bersama hasilnya, sehingga pengguna bisa langsung memeriksa apakah pemahaman LLM sudah tepat.
• Ada kebingungan soal opsi self-hosted. Dari dokumen terkait terlihat bahwa dibutuhkan setidaknya 6 akun layanan pihak ketiga, dan ini dianggap sangat berbeda dari makna self-hosted yang sebenarnya.
  • Dijelaskan bahwa kode itu sendiri memang bisa di-self-host secara langsung. Rasanya istilah “self-hosted” memang tidak punya standar resmi yang jelas. Misalnya, walaupun sebuah layanan self-hosted punya fitur backup off-site, itu tetap self-hosted sekaligus hanya berarti layanannya dirancang dengan baik.
  • Pemasaran self-hosted seperti ini mungkin terasa wajar. Mengingat model bisnis asli vendornya adalah menjual versi hosted, mereka juga tidak wajib menyediakan produk self-hosted yang sepenuhnya mandiri.
  • Dibagikan pengalaman bekerja di lingkungan jaringan terbatas; selama 20 tahun terakhir bekerja di intranet internal yang sepenuhnya terisolasi, sehingga mungkin banyak gelombang teknologi terbaru yang terlewat. Bahkan YouTube pun hampir tidak ditonton kecuali untuk perbaikan mobil, dan ada kecenderungan agak pasif terhadap tren teknologi yang wajib terhubung online.
  • Secara pribadi, versi open source ini dipakai dengan sangat memuaskan. Jika tidak ingin bergantung pada hosting, pendapat praktisnya adalah tinggal menulis semuanya sendiri dalam Rust.
• Reranker berbasis LLM besar (seperti Qwen3-reranker) direkomendasikan untuk dicoba karena akhirnya memberikan performa yang dulu diharapkan dari cross-encoder, meski kebutuhan komputasinya besar. Selain itu, metadata/informasi tabel adalah dasar yang sangat jelas bagi manusia, tetapi sering tidak diulang dalam chunk teks, jadi jika itu disuntikkan ke input LLM, hasilnya terlihat jauh lebih “cerdas”. Perlu hati-hati untuk kueri kompleks yang tidak mudah ditangani RAG sederhana, misalnya merangkum 20 dokumen terbaru. Karena itu, kami memfokuskan UI pada pencarian dan mengurangi UX chat, lalu memastikan pengguna juga melihat informasi yang benar-benar dilihat model.
  • Sangat setuju dengan pendapat bahwa dari sisi pengguna, sangat sulit membuat mereka memahami dengan benar bagaimana struktur pemrosesan konteks LLM bekerja. Kasus publik yang keluar dari UX chat pun jarang, dan ada keraguan apakah alasan perusahaan-perusahaan besar mencobanya lalu berhenti benar-benar karena “tidak ada hasil”. Dalam aplikasi konsumen berskala besar, biaya konteks/penalaran memang merupakan biaya utama yang harus dikendalikan, sehingga UI yang eksplisit soal konteks tampaknya kurang diminati. Sebaliknya, pada sistem RAG internal perusahaan, beban biaya lebih kecil sehingga fokusnya jauh lebih besar pada kualitas hasil dan penghematan waktu karyawan.
  • Optimasi teknis memang penting, tetapi saya ingin tahu lebih banyak contoh penggunaan nyata tentang seberapa besar efisiensi kerja pelanggan benar-benar meningkat. Kalau tidak, ini terasa hanya seperti tren teknologi lain lagi.
• Membagikan tulisan ringkasan yang dibuat satu setengah tahun lalu tentang pemrosesan RAG untuk jutaan halaman, khususnya materi teknis: https://jakobs.dev/learnings-ingesting-millions-pages-rag-azure/
  • Saya juga pernah membangun sistem RAG untuk pencarian teknis tahun lalu, dan menurut saya banyak bagiannya masih hampir sama bahkan jika dilihat sekarang.
• Dari sudut pandang orang yang ingin membangun atau mengadopsi sistem RAG seperti ini, muncul pertanyaan apakah akan praktis jika dokumen diunggah via API ke folder Google Workspace lalu dicari memakai Google AI search API, misalnya dipisahkan per pengguna ke folder yang berbeda. Atau mungkin hal serupa juga bisa diwujudkan di Azure.
• Ingin tahu cara melakukan versioning embedding. Jika data diperbarui, versi tertentu ingin diekspos, atau perlu difilter berdasarkan tanggal, bagaimana sebaiknya ini ditangani? Bahkan ada pemikiran untuk menambahkan versi konteks di depan setiap chunk.
  • Cukup simpan teks asli dan metadata (termasuk informasi versi) bersama-sama di vector store. Misalnya di turbopuffer, attribute filtering nyaman digunakan; dibagikan tautan dokumen.
  • Rasanya pertanyaan ini sendiri sudah merupakan pertanyaan yang sangat berguna dan penting.
• Terasa aneh bahwa urutan penggunaan versi LLM adalah GPT 4.1 → GPT 5 → kembali ke GPT 4.1, dan ada ketidaksesuaian dengan versi komponen lain di stack, misalnya text-embedding-large-3.
  • Jawaban OP: Begitu GPT-5 dirilis, kami langsung mencobanya, tetapi saat menerima banyak konteks (hingga 100 ribu token), performanya lebih buruk dibanding GPT-4.1 sehingga kami kembali ke 4.1. Secara spesifik: a) kemampuan mengikuti instruksi lebih lemah sehingga system prompt sering tidak diikuti dengan baik, b) jawabannya menjadi terlalu bertele-tele dan sangat merusak UX, c) batas context window 125 ribu token membuat input yang sangat besar berujung error. Masalah-masalah ini sangat menonjol dalam “RAG” saat banyak chunk dikirimkan, meski untuk tugas yang lebih umum GPT-5 bisa saja lebih baik.
• Bukan pendukung AWS, tetapi ditegaskan bahwa S3 Vectors saat ini adalah state-of-the-art di bidang ini. Jika dipadukan dengan Bedrock Knowledge Base, Discovery/Rebalance juga jadi sederhana, sehingga ini bisa menjadi solusi paling simpel di pasar. Begitu rilis resminya keluar, kemungkinan besar akan mengungguli sebagian besar pesaing.
  • Dengan bercanda, seseorang mengoreksi bahwa kata yang tepat bukan “schlep” melainkan “shill”.
  • Muncul pertanyaan kenapa S3 Vectors dianggap SOTA; bukankah pada akhirnya itu hanya vector store?
• RAG berbasis embedding sebenarnya belum tentu metode terbaik. Untuk tugas tunggal atau demo memang bagus, tetapi di situasi nyata sering menemui keterbatasan.
  • Ada juga pengalaman yang tidak sepenuhnya setuju. Produk Honeycomb yang saya kerjakan, Query Assistant blog, juga sejak 2023 berbasis kueri data, dan justru karena fitur ini dirancang untuk tujuan yang sederhana, rasanya itu menunjukkan arah ideal bagi produk berbasis LLM. Pendekatan ini bagus bila dikombinasikan dengan pemrosesan non-LLM.
  • rag terus ditafsirkan ulang dengan cara berbeda dan punya banyak kegunaan. Kami mengintegrasikan rag sebagai salah satu alat dalam agentic search, sekaligus mencampurnya dengan pencarian sumber real-time dan pendekatan chunk yang sudah ada. Dengan context window besar yang akan segera hadir, nantinya mungkin saja seluruh dokumen dimasukkan dalam satu permintaan.
  • Ditanyakan alternatif apa yang direkomendasikan; apakah yang dimaksud adalah metode pembuatan kueri?
  • Dalam kasus ChatGPT juga, RAG efektif untuk memperoleh informasi terbaru. Kegunaan praktis seperti inilah yang menegaskan mengapa semua vendor utama sekarang menawarkannya.
  • Ditanyakan dengan jelas apa sebenarnya pembandingnya.
• Disebutkan bahwa banyak waktu dan tenaga dihabiskan untuk strategi pemilihan chunk; saya ingin mendengar lebih detail strategi konkret apa yang digunakan.