- Di Hacker News, seorang pengguna menanyakan bagaimana orang-orang mengimplementasikan Retrieval-Augmented Generation (RAG) di lingkungan lokal
- Muncul kecenderungan kuat bahwa untuk RAG lokal, bahkan tanpa vector DB, pencarian teks seperti SQLite FTS5, BM25, atau grep sudah cukup memadai
- Untuk pencarian kode, banyak pengalaman yang menyebut embedding lambat dan penuh noise, dan cukup banyak yang berpendapat bahwa pendekatan berbasis kata kunci seperti BM25+trigram lebih baik
- Bahkan saat pencarian vektor memang dibutuhkan, ada banyak contoh yang menyelesaikannya dengan konfigurasi ringan seperti Postgres+pgvector, menyimpan vector BLOB di SQLite, atau memuat FAISS ke memori
- Kualitas pencarian bisa ditingkatkan lewat kombinasi seperti hybrid search yang menggabungkan BM25+vektor, RRF (Reciprocal Rank Fusion), reranking, dan ekspansi multi-query
- Terlihat kecenderungan untuk tidak mengunci pada “RAG=vector DB”, melainkan memilih pencarian sederhana → hybrid → berbasis agen sesuai jenis dokumen, skala, dan beban operasional
Kesimpulan umum pada tahap pencarian
- Alih-alih berasumsi vector DB atau graph wajib dipakai, banyak yang memilih pendekatan mulai sesederhana mungkin sesuai infrastruktur yang ada, tipe file, dan kebutuhan performa
- Ada juga penyebutan bahwa pendekatan agen yang langsung mengakses filesystem atau API lebih mudah dikonfigurasi dan dipelihara, meski bisa sedikit lebih lambat
- Pemahaman bahwa “yang diserahkan RAG ke LLM hanyalah potongan teks pendek hasil pencarian” menjadi pemicu untuk memusatkan perbaikan performa pada kualitas pencarian
- Dalam soal “definisi RAG”, ada yang berpendapat bahwa tanpa vector DB pun selama ada retrieval+generation maka itu tetap RAG, sementara ada juga yang menilai istilah itu biasanya dipakai dengan asumsi vector DB
Model embedding dan pencarian vektor
- Model embedding mdbr-leaf-ir yang dikembangkan di MongoDB berjalan hanya dengan CPU, dan mencatat peringkat 1 di beberapa leaderboard untuk kelas ukuran model tersebut
- Pada server standar 2vCPU, mampu memproses sekitar 22 dokumen per detik dan 120 query per detik
- Mencatat skor 53.55 pada benchmark BEIR (all-MiniLM-L12-v2 mencatat 42.69)
- Embedding kata statis seperti model2vec/minish punya kecepatan inferensi lebih tinggi, tetapi akurasi pencariannya lebih rendah
- Karena hanya melakukan tokenisasi + lookup table + rata-rata, ia lebih cepat dibanding pendekatan berbasis transformer
- Ada juga penggunaan Meta-Llama-3-8B untuk membuat vektor per chunk teks lalu menyimpannya ke kolom SQLite BLOB, dengan FAISS untuk pencarian
- Untuk 5 juta chunk, penggunaan memori sekitar 40GB
faiss-gpu di A6000 sangat cepat, sedangkan faiss-cpu di M1 Ultra lebih lambat tetapi tetap cukup untuk tingkat query beberapa kali per hari
Rekomendasi untuk pencarian kode
- Untuk kode, disarankan menghindari penggunaan vector database dan memakai kombinasi BM25+trigram
- Embedding lambat dan kurang cocok untuk kode
- Tanpa reranker, noise besar dan beban reindex file juga tinggi
- Kecepatan respons pencarian tinggi dan kualitas hasil juga baik
- Di PostgreSQL, pencarian BM25 bisa diimplementasikan dengan plpgsql_bm25
- Mendukung hybrid search bersama pgvector + Reciprocal Rank Fusion
- Hasil yang baik juga bisa diperoleh dengan menerapkan embedding pada path file + signature lalu menggabungkannya dengan BM25
- Pendekatan agentic yang menjalankan gpt-oss 20B bersama ripgrep dalam loop
while juga dinilai efektif
Solusi berbasis database
- SQLite FTS5: cocok untuk dokumen berbasis file Markdown, dan memungkinkan implementasi RAG tanpa vector DB
- Tiap file diberi field deskripsi singkat lalu dokumen dijelajahi lewat pencarian kata kunci
- Dimungkinkan juga desain yang menyimpan vektor fp16 sebagai BLOB di SQLite, lalu membuat subset dengan filter dan menghitung similarity di memori
- Ada juga opsi seperti sqlite-vec, sqlite-vector, vec0, dan bm25 milik SQLite
- “SQLite bekerja sangat bagus, bahkan mengejutkan”
- PostgreSQL + pgvector: memanfaatkan pengetahuan Postgres yang sudah ada, dan memudahkan serah terima ke tim operasional
- Ada juga library llmemory yang mendukung BM25 hybrid, ekspansi multi-query, dan reranking
- LanceDB: bisa digunakan dengan nyaman sebagai embedded vector DB
- Digunakan bersama embedding nomic-embed-text dari Ollama
- DuckDB: menyediakan ekstensi pencarian similarity vektor, cocok untuk proyek kecil di bawah 3GB
- Meilisearch, Typesense, Manticore: operasionalnya lebih sederhana dibanding Elasticsearch/OpenSearch
Hybrid dan pencarian agentic
- nori(usenori.ai): menggabungkan pencarian semantik dan pencarian kata dengan SQLite + vec0 + fts5
- Turbopuffer: mendukung hybrid search vektor + BM25
- Hanya dengan kombinasi pencarian agentic dan pencarian teks pun sudah bisa memperoleh hasil yang sangat baik
- Menambahkan pencarian vektor dan graph RAG bisa memberi sedikit peningkatan pada kecepatan dan kualitas
- Claude Code/Codex secara internal menggunakan ripgrep
- Menerapkan embedding pada path file juga efektif, dan bisa ditingkatkan lagi bila digabung dengan BM25
Contoh pemanfaatan BM25
- shebe: alat CLI/MCP untuk indexing dan pencarian codebase berbasis BM25
- Sangat berguna khususnya dalam workflow refactoring (contoh: saat upgrade Istio, menuliskan lokasi yang perlu diubah)
- Dalam 85% kasus, mencocokkan tag saja sudah cukup tanpa vector DB
- Para operator menambahkan tag pada input dan dokumen untuk mencapai pencocokan 100%
- Ada pendapat bahwa kebanyakan vector DB adalah “palu yang dipakai untuk menyelesaikan masalah sulit menemukan sesuatu”
Alat dan library khusus
- qmd: alat CLI untuk pencarian file Markdown, hasil query fuzzy lebih baik daripada fzf
- ck: alat semantic grep berbasis Rust
- Kiln: menambahkan file dengan drag and drop, serta bisa membandingkan berbagai pengaturan
- Mendukung perbandingan metode ekstraksi, model embedding, dan cara pencarian (BM25, hybrid, vector)
- Memiliki fitur evaluasi akurasi pencarian dan pembuatan dataset evaluasi otomatis
- libragen: library konten RAG berversi untuk pembuatan server CLI/MCP
- Dapat mengubah repositori GitHub menjadi DB RAG
- piragi: library Python RAG sederhana, mendukung beragam sumber seperti lokal/S3/API
- ragtune: alat CLI untuk debugging dan benchmarking pencarian RAG lokal
Pemrosesan dokumen dan OCR
- discovery: melakukan OCR dokumen dengan Qwen-3-VL-8B dan menyimpan vektor ke ChromaDB
- Mengimplementasikan hybrid RAG BM25 + embedding
- docling: alat ekstraksi dokumen yang dipakai di berbagai proyek RAG
- Saat konversi PDF, penanganan tabel, multi-kolom, dan tabel lintas halaman masih sulit
- Model Mistral OCR memberikan hasil terbaik (model tertutup)
Memori dan manajemen konteks
- Yang dikirim RAG ke LLM hanyalah string pendek hasil pencarian
- Pada model kecil, batasnya sekitar TOP_K=5; lebih dari itu bisa menyebabkan konteks terlupakan
- Performa dapat ditingkatkan dengan meringkas file dan folder lebih dulu
- Ada juga pendekatan yang memasukkan seluruh isi ke konteks dengan Sonnet + context window 1M
- Ada contoh membangun sistem memori untuk Claude Code dengan pencarian semantik pada file sesi
Pemanfaatan enterprise dan skala besar
- Saat menangani 300 ribu interaksi pelanggan per hari, latensi dan presisi menjadi penting
- Digunakan pendekatan hybrid embedding + full-text search + IVF-HNSW
- Tantangannya adalah mengelola penyebaran informasi di sekitar 600 sistem terdistribusi
- Sedang bereksperimen dengan pendekatan KAG (Knowledge Augmented Generation) untuk pemetaan aturan bisnis
- Implementasi RAG sepenuhnya lokal untuk lebih dari 500 ribu artikel berita dengan Postgres vector DB juga dilaporkan berhasil
Alat dan pendekatan lainnya
- AnythingLLM: menyediakan bundle vector DB untuk dokumen
- LibreChat: juga menyertakan bundle vector DB untuk dokumen
- ChromaDB: digunakan pada ekstensi Obsidian untuk pencarian semantik/hybrid
- SurrealDB: digunakan bersama vectorisasi lokal
- OData query interface: efektif bila diberikan ke LLM sebagai tool, dapat menganalisis Excel 40 ribu baris
- Nextcloud MCP Server: memakai Qdrant sebagai vector DB dan menyediakan pencarian semantik untuk dokumen pribadi
- LSP (Language Server Protocol): sudah ditambahkan ke Claude Code tetapi saat ini masih ada bug
- TreeSitter mungkin lebih berguna (lookup berdasarkan nama simbol, menelusuri definisi/lokasi penggunaan)
3 komentar
Saya ragu apakah bahasa Korea didukung dengan baik.
Melihat performa sistem RAG internal kami yang seadanya, membaca postingan seperti ini memang sedikit mengubah sudut pandang saya.
Opini Hacker News
Tim kami mengoperasikan basis data Q&A
Pertanyaan dan jawaban diindeks dengan indeks trigram dan embedding, lalu disimpan di Postgres
Saat pencarian, kami menggunakan
pgvectordan pencarian trigram bersama-sama, lalu menggabungkan hasilnya dengan skor relevansiPada tahap retrieval, kami mengembangkan model embedding teks yang sangat efisien dan ramah CPU
Model MongoDB/mdbr-leaf-ir menempati peringkat 1 di leaderboard di antara model seukuran
Model ini kompatibel dengan Snowflake/snowflake-arctic-embed-m-v1.5
Melalui demo search-sensei, kita bisa membandingkan pencarian semantik vs BM25 vs hybrid
Misalnya, model embedding memahami bahwa “j lo” berarti “Jennifer Lopez”
Kami juga telah membuka resep pelatihan, dan model ini bisa dilatih dengan mudah bahkan pada perangkat keras kelas menengah
Saya membuat vektor dengan Meta-Llama-3-8B sejak April 2024
Saya memakai Python dan Transformers di RTX-A6000; cepat, tetapi berisik dan panas
Setelah itu saya pindah ke M1 Ultra dan menggunakan library MLX dari Apple, dengan kecepatan yang mirip tetapi jauh lebih senyap
Model Llama berdimensi 4k, jadi ukurannya 8KB per chunk dalam fp16, dan saya menyimpannya dengan
numpy.save()ke kolom BLOB di SQLiteSaat pencarian, semua vektor dimuat dari SQLite, dibuat menjadi
numpy.array, lalu dicari dengan FAISSfaiss-gpu di RTX6000 sangat cepat, dan faiss-cpu di M1 Ultra juga cukup cepat untuk kebutuhan saya (beberapa kueri per hari)
Untuk 5 juta chunk, penggunaan memorinya sekitar 40GB, dan kedua perangkat dapat menanganinya dengan nyaman
Sebagian besar dokumen kompleks adalah file Markdown
Saya merekomendasikan alat CLI sederhana bernama tobi/qmd
Dulu saya memakai alur kerja berbasis fzf, tetapi alat ini memberikan pencarian fuzzy yang lebih baik
Saya tidak menggunakannya untuk pencarian kode
Untuk pencarian kode, saya menyarankan jangan memakai basis data vektor
Embedding lambat dan tidak cocok untuk kode
Kombinasi BM25 + trigram memberikan hasil yang lebih baik dan respons yang lebih cepat
Anda bisa melihat proyek plpgsql_bm25
Di dalamnya ada contoh penggabungan BM25 dan pgvector dengan Reciprocal Rank Fusion serta notebook Jupyter
Jika memakai model yang bukan untuk kode, pencarian vektor menimbulkan banyak noise
Sekarang pendekatan memutar
gpt-oss 20Bbersama ripgrep jauh lebih cepat dan akuratJika digabungkan (fusion) dengan BM25, hasilnya lebih baik lagi
Saya membuat local-LLM-with-RAG untuk eksperimen RAG lokal
Saya membuat embedding dengan “nomic-embed-text” dari Ollama dan memakai LanceDB sebagai vector DB
Baru-baru ini saya memperbaruinya menjadi “agentic RAG”, tetapi untuk proyek kecil itu mungkin berlebihan
Saya menyimpan vektor fp16 sebagai BLOB di SQLite, lalu setelah filtering saya memuatnya ke memori dan menghitung kemiripan dengan perkalian matriks-vektor (matvec)
Jika numpy atau torch memanfaatkan multithreading/BLAS/GPU, ini sangat cepat
Jika nanti ada bottleneck, saya berencana bermigrasi ke sqlite-vector
Ini efisien karena data banyak berkurang oleh filter seperti tanggal atau lokasi
Backend disembunyikan di balik antarmuka yang bisa diganti
Karena 95% dokumen saya adalah file Markdown kecil, saya memakai SQLite FTS5 sebagai indeks pencarian teks biasa
Indeksnya sudah ada, jadi saya langsung menghubungkannya ke agent mastra
Setiap file memiliki field deskripsi singkat; setelah pencarian kata kunci, jika deskripsinya cocok maka dokumen penuh dimuat
Menyiapkannya memakan waktu sekitar satu jam, dan hasilnya bekerja sangat baik
Pencarian berbasis embedding memang lebih umum, tetapi esensinya sama
Kami sudah terbiasa dengan Postgres, jadi kami mulai dengan PGVector
Belakangan kami menyadari ada konten yang 100% cocok dengan field semi-terstruktur dalam prompt
Itu karena operator mulai menambahkan tag baik pada input maupun pada dokumen (sekitar 50 dokumen)
Jadi kami lebih dulu mencari field tersebut dan memasukkan file terkait ke prompt, lalu baru melakukan pencarian embedding
Hasilnya, dalam 85% kasus vectordb tidak diperlukan
Saya membuat llmemory dan memakainya baik secara lokal maupun di aplikasi perusahaan
Ini berbasis PostgreSQL + pgvector, serta mencakup BM25 hybrid, ekspansi multi-kueri, dan reranking
Ini baru pertama kali saya publikasikan, jadi mungkin masih ada sedikit bug
Saya cukup puas dengan performanya