Ingin membangun RAG lokal?

• Skald dikembangkan dengan tujuan menjadi sistem RAG yang sepenuhnya dapat di-host sendiri, tanpa mengirim data ke pihak ketiga
• Komponen RAG dibagi menjadi database vektor, model embedding, LLM, reranker, parser dokumen, dan untuk tiap elemen disajikan alternatif open source
• Stack lokal dasar Skald terdiri dari Postgres+pgvector, Sentence Transformers, Docling, dan LLM kustom
• Dalam hasil benchmark, model berbasis cloud (Voyage+Claude) mendapat rata-rata 9,45 poin, sedangkan GPT-OSS 20B yang sepenuhnya lokal dinilai 7,10~8,63 poin
• Pendekatan ini menunjukkan bahwa RAG berperforma tinggi tetap bisa dibangun sambil menjaga privasi data

---

Komponen RAG dan alternatif open source

• RAG dasar terdiri dari database vektor, model embedding, LLM, dan secara tambahan dapat mencakup reranker serta parser dokumen
  • Tiap komponen dapat diganti dengan alternatif lokal alih-alih SaaS
• Contoh alternatif yang ditunjukkan dalam tabel
  • Vector DB: Pinecone, Weaviate Cloud → Qdrant, Weaviate, Postgres+pgvector
  • Embeddings: OpenAI, Cohere → Sentence Transformers, BGE, E5
  • LLM: GPT, Claude → Llama, Mistral, GPT-OSS
  • Reranker: Cohere → BGE Reranker, Sentence Transformers Cross-Encoder
  • Document Parsing: Reducto → Docling
• Skald mengarah pada stack open source yang sepenuhnya lengkap, dengan setiap komponen dijalankan secara lokal

Susunan stack lokal Skald

• Vector DB: menggunakan Postgres + pgvector
  • Mudah diintegrasikan ke infrastruktur yang sudah ada, serta mampu menangani hingga ratusan ribu dokumen
• Vector Embeddings: default-nya adalah Sentence Transformers (all-MiniLM-L6-v2)
  • Khusus bahasa Inggris, dengan keseimbangan antara kecepatan dan performa pencarian
  • Model bge-m3 (mendukung multibahasa) juga diuji
• LLM: tidak disediakan secara bawaan, pengguna menjalankannya sendiri
  • Dalam pengujian, GPT-OSS 20B dijalankan di EC2
• Reranker: default-nya adalah Sentence Transformers Cross-Encoder, dan model multibahasa seperti bge-reranker-v2-m3 juga dapat digunakan
• Document Parsing: menggunakan Docling, dijalankan lewat docling-serve

Hasil performa dan deployment

• Deployment instance produksi Skald beserta seluruh stack memerlukan 8 menit
  • Termasuk Postgres, layanan embedding dan reranking, serta Docling
  • LLM dijalankan secara terpisah (menggunakan llama.cpp)
• Dataset uji terdiri dari konten situs web PostHog (sekitar 2.000 dokumen) dan set tanya-jawab buatan sendiri
• Pengaturan eksperimen
  • Vector search topK=100, Reranking topK=50, Query rewriting=Off
  • Kriteria evaluasi berfokus pada akurasi

Perbandingan hasil benchmark

• Voyage + Claude (konfigurasi cloud)
  • Skor rata-rata 9,45, semua jawaban akurat
• Voyage + GPT-OSS 20B (sebagian lokal)
  • Skor rata-rata 9,18, sebagian besar akurat tetapi ada beberapa informasi yang terlewat
• Sepenuhnya lokal + GPT-OSS 20B
  • Model dasar bahasa Inggris (all-MiniLM-L6-v2 + ms-marco-MiniLM-L6-v2) : rata-rata 7,10
    • Akurat untuk kueri berbahasa Inggris, tetapi lemah pada kueri multibahasa, kueri ambigu, dan agregasi multi-dokumen
  • Model multibahasa (bge-m3 + mmarco-mMiniLMv2-L12-H384-v1) : rata-rata 8,63
    • Berhasil menangani kueri berbahasa Portugis, tetapi masih ada sebagian informasi yang terlewat saat agregasi multi-dokumen
• Batasan utamanya adalah pemrosesan terpadu atas informasi yang tersebar di banyak dokumen
  • Model cloud menutup kekurangan ini dengan performa tinggi, tetapi di lingkungan lokal diperlukan teknik tambahan

Rencana ke depan

• Skald berencana meningkatkan performa RAG lokal dan membuka benchmark model open source
• Menargetkan penyediaan solusi bagi perusahaan yang harus mengoperasikan alat AI di lingkungan air-gapped
• Yang ingin berpartisipasi dapat berkolaborasi melalui GitHub(skaldlabs/skald) atau komunitas Slack

[GN⁺]

Komentar Hacker News

• Saat membangun sistem seperti ini, saya ingin menyarankan agar tidak terlalu terpaku pada database vektor atau embedding
  Pencarian full-text atau alat seperti grep/rg jauh lebih cepat dan murah, serta tidak perlu memelihara indeks
  Jika Anda memberi LLM yang bagus alat pencarian, ia bisa membuat kueri seperti “dog OR canine” sendiri dan memperbaikinya secara iteratif
  Selain itu, dengan cara ini Anda juga tidak perlu menyelesaikan masalah chunking

  • Saya membuat aplikasi kecil di browser yang menunjukkan perbedaan antara pencarian berbasis embedding (“semantic”) dan pencarian BM25
    Bisa dicek di Search Sensei
    Saat pertama dimuat, aplikasi ini mengunduh sekitar 50MB bobot model dan onnx runtime, tetapi setelah itu berjalan lancar
    Misalnya, BM25 tidak memahami bahwa “j lo” dan “jlo” berarti Jennifer Lopez, tetapi pencarian berbasis embedding menangani typo dan alias seperti ini dengan baik
    Pencarian dijalankan terhadap 1000 artikel berita dari 2016~2024
  • Menurut riset contextual retrieval dari Anthropic, kombinasi embedding + BM25 memberikan hasil terbaik
    Namun sayangnya performa BM25 saja tidak dipublikasikan
    Dalam pengujian kecil saya, ada kasus ketika embedding melewatkan halaman yang sebenarnya memuat kata kueri apa adanya — pada akhirnya Ctrl+F yang menang
  • Menurut pengalaman saya, pencarian semantic vs lexical paling tepat dipahami sebagai trade-off antara precision dan recall
    Pencarian lexical punya precision tinggi tetapi recall rendah, sedangkan pencarian semantic berada di sisi sebaliknya
  • Saat saya mencari “billiards” di Google Maps, saya mengalami masalah sinonim karena yang muncul justru hasil terkait kolam renang dan kambing
    Rasanya operator “NOT” lebih dibutuhkan. Saya juga ingin belajar lebih banyak tentang RAG
  • Saya penasaran apakah ada prompt standar yang digunakan saat melakukan pencarian dengan cara seperti ini
    Saya pernah melihat beberapa alat berbasis agen membuat kueri seperti ini secara otomatis, tetapi saya tidak tahu apakah itu didorong oleh prompt atau perilaku bawaan

• Salah satu alasan performanya buruk mungkin karena kurangnya semantic chunking
  Jika seluruh dokumen di-embedding sekaligus, berbagai konsep akan bercampur dan akurasinya menurun
  Dokumen perlu dipecah berdasarkan satuan makna dengan alat seperti Spacy, lalu ditambahkan konteks tentang posisi tiap chunk dalam dokumen sebelum di-embedding
  Pendekatan contextual retrieval dari Anthropic sangat efektif dalam sistem RAG
  Pembuatan konteksnya bisa dilakukan dengan model GPT OSS 20B

  • Saya bukan penulisnya, tetapi kami sebenarnya sudah melakukan semantic chunking
    Sepertinya ada kesalahpahaman karena pengujian dilakukan dengan pertanyaan yang membutuhkan agregasi konteks dari beberapa dokumen

• Saya mempertanyakan kenapa orang menganggap pencarian semantic lebih unggul daripada pencarian lexical
  Saat dibandingkan dengan Tantivy (BM25) pada 2023, perbedaan hasilnya sangat kecil
  Bahkan jika memang ada sedikit peningkatan recall, saya tidak yakin itu sepadan dengan kompleksitas arsitekturnya

  • Ini tergantung cara pengujiannya
    Dalam pengujian oleh developer, recall mencapai 90%, tetapi dalam pengujian pengguna nyata turun ke sekitar 30%
    Karena pengguna tidak tahu istilah tepat yang ada di dokumen, pencarian lexical saja tidak cukup
    Agen bisa ditambahkan di atasnya, tetapi latency meningkat sehingga kepuasan pengguna menurun
  • Ini juga tergantung sifat aplikasinya
    Di Wanderfugl, pencarian semantic berhasil menemukan bagian yang skornya rendah di BM25
    Pada akhirnya, hybrid ranking mungkin jawabannya
  • Kelebihannya adalah bisa menangani kueri seperti “percakapan antara dua ilmuwan”
    Pada akhirnya ini bergantung pada use case

• Saya sedang mencari alat open source untuk mengkueri semua data secara lokal dan offline, termasuk email, Slack, GDrive, kode, wiki, dan lainnya
  Saya ingin menghindari membangun sendiri atau melakukan kustomisasi, dan akan bagus jika ada default yang baik serta rekomendasi model

  • Karena itu saya membuat server Nextcloud MCP
    Tautan GitHub
    Pada dasarnya mendukung CRUD, dan jika pencarian vektor diaktifkan maka dokumen atau catatan akan di-embedding
    Mendukung Ollama dan OpenAI sebagai penyedia embedding
    Server MCP ini menyediakan pencarian semantic + BM25 (qdrant fusion), dan menghasilkan respons melalui MCP sampling
    Server itu sendiri tidak menghasilkan jawaban, sehingga bisa diintegrasikan dengan LLM/MCP client apa pun
    Pola MCP sampling/RAG ini sangat kuat, dan kemungkinan besar akan muncul versi open source yang digeneralisasi untuk sumber data lain

• Alat yang kami gunakan adalah haiku.rag
  Alat ini menyediakan kode Python yang ramah developer, arsitektur berbasis pydantic-ai, benchmark, dan fitur sitasi tingkat lanjut
  Mendukung agen riset mendalam, dan merupakan proyek open source sejati yang dipelihara untuk jangka panjang

• Saat ini saya menggunakan Sentence Transformers (all-MiniLM-L6-v2) sebagai model embedding default, tetapi saya sadar model ini khusus bahasa Inggris sehingga bisa menjadi masalah saat membuat RAG berbahasa Jerman
  Saya penasaran seperti apa performa model non-Inggris

  • Lihat saja leaderboard MTEB
    Cek entri RTEB Multilingual atau RTEB German di bagian “Retrieval”
    Jika self-hosting berbasis CPU, sebaiknya filter ke model dengan parameter di bawah 100M
  • Banyak model menunjukkan penurunan performa pada bahasa non-Inggris
    Namun bahasa Jerman memiliki data pelatihan yang relatif banyak, dan model multibahasa juga cukup tersedia
    Terutama model berbasis API komersial, kebanyakan sudah mendukung banyak bahasa
  • Kami juga dulu pernah menggunakan model embedding multibahasa
    Untuk paper terkait, lihat tautan Springer

• Pada era GPT-4 (konteks 8K), saya pernah membuat skrip yang membagi seluruh buku menjadi chunk lalu memasukkannya ke GPT-4 untuk mencari kutipan yang relevan
  Saat itu satu kali pencarian memakan biaya sekitar 1 dolar, tetapi sekarang jauh lebih murah
  Dalam tulisan contextual retrieval dari Anthropic juga disebutkan bahwa jika seluruh dokumen muat dalam konteks, lebih baik langsung dimasukkan saja daripada memakai RAG
  Hanya saja, ketika konteks semakin panjang kualitas menurun, dan biaya serta kecepatan juga menjadi masalah
  Sekarang bahkan seluruh buku bisa dimasukkan ke konteks dengan biaya sekitar 1 sen

• Bagian tersulit dalam RAG adalah parsing dokumen
  Jika hanya berurusan dengan teks tidak masalah, tetapi jika ada tabel, tabel multi-halaman, grafik, daftar isi, catatan kaki, dan sebagainya, akurasinya turun drastis
  Untuk memperbaikinya, ada pendekatan seperti pola RAPTOR, di mana LLM merangkum dan mengajukan pertanyaan atas isi lalu menyimpannya ke vector DB
  Namun pipeline RAG serbaguna yang bekerja untuk semua kasus masih merupakan tantangan yang sulit

  • Sebagai pemula dalam embedding vektor, saya tidak tahu bahwa tabel bisa menimbulkan masalah serumit itu
    Saya juga penasaran apakah vector DB lebih baik menangani kelompok teks panjang atau format tabel

• Saya merasa sudut pandang baru tentang menerapkan pencarian full-text ke RAG ini menarik
  Wawasannya tentang loop alat berbasis agen dan cara menangani fuzzy search sangat berkesan

• Saya penasaran apakah dataset evaluasi untuk sistem seperti ini sudah distandardisasi
  Akan bagus jika ada benchmark berupa set dokumen dan pertanyaan, di mana dokumen atau chunk tertentu harus muncul sebagai hasil yang paling relevan

  • Untuk tujuan seperti itu, Anda bisa melihat benchmark dan set evaluasi haiku-rag

[iolothebard]

Dari mana asal gagasan aneh bahwa RAG memerlukan vector DB…

[aer0700]

Sebenarnya yang dibutuhkan untuk RAG adalah fungsi pencarian, dan melakukan embedding dengan dense vector lalu mendorongnya ke vectorDB serta menjalankan pencarian kemiripan cosine hanyalah salah satu dari banyak cara untuk mengimplementasikan mesin pencari... Bukan berarti tidak ada alasan untuk menggunakan vectorDB, tetapi kalau ditanya apakah itu benar-benar wajib, ada banyak algoritma mesin pencari yang sudah lama dipakai dengan baik, jadi saya memang agak memiringkan kepala memikirkannya.

[ztaka]

Karena murah dan sebagian besar LLM produksi memakainya.
Sebenarnya kalau logikanya begitu, web server juga kalau ditambah fungsi infrastruktur semuanya bisa dari disk, jadi DBMS juga tidak perlu, wkwk

[gcback]

Memang benar, untuk pencarian kemiripan/semantik semacam ini yang menggunakan nilai embedding (vektor) dari kueri pengguna sebagai key, dibutuhkan database. Karena key-nya berbentuk vektor, maka vector DB juga memang tepat.

[aer0700]

Entah itu vector DB atau apa pun, pada dasarnya yang perlu dilakukan cuma mengimplementasikan pencarian...

[dkmin]

Gemini:
Ya, penggunaan basis data vektor (Vector Database) dalam RAG (Retrieval-Augmented Generation) mulai memiliki landasan konseptual sejak makalah terkait pertama kali dipublikasikan pada 2020.
Pada dasarnya, RAG menggabungkan retrieval dan generation, dan pada tahap retrieval ini, embedding vektor serta basis data vektor yang menyimpan dan menelusurinya secara efisien memegang peran penting.
💡 Titik awal RAG dan vector DB
Gagasan bahwa RAG memerlukan vector DB berangkat dari makalah dan konsep utama berikut.

1. Kelahiran RAG: makalah Lewis et al. (2020)

• Judul makalah: "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks" (generasi berbasis retrieval untuk tugas NLP yang intensif pengetahuan)
• Inti: makalah ini pertama kali memperkenalkan istilah dan kerangka kerja RAG.
• Peran Retriever: model RAG yang diusulkan dalam makalah ini terdiri dari Retriever dan Generator. Retriever mencari dokumen (latent documents) yang relevan dengan kueri dari dataset besar seperti Wikipedia.
• Penggunaan indeks vektor: model RAG awal ini menggunakan indeks vektor (Vector Index) pada dataset untuk mengambil dokumen, sehingga pretrained retriever dapat mengambil dokumen tersebut.
• Kesimpulan: karena tahap inti RAG, yaitu 'retrieval', dilakukan dengan menghitung kesamaan berdasarkan representasi vektor dari kueri dan dokumen, maka konsep penyimpanan vektor (Vector Store) atau indeks vektor untuk pencarian yang efisien secara implisit menjadi elemen yang wajib ada.

2. Embedding vektor dan pencarian kemiripan
   Alasan mendasar mengapa basis data vektor menjadi komponen esensial dalam RAG adalah sebagai berikut.

• Embedding: dalam sistem RAG, pengetahuan eksternal (dokumen, teks) dan kueri pengguna (pertanyaan) sama-sama diubah menjadi representasi matematis berupa vektor (Vector). Vektor ini merepresentasikan makna teks sebagai susunan angka padat dalam ruang berdimensi tinggi.
• Pencarian kemiripan (Similarity Search): menemukan vektor dokumen yang jaraknya paling dekat dengan vektor kueri di ruang vektor berarti menemukan dokumen yang paling serupa secara semantik (relevan).
• Peran vector DB: basis data vektor adalah basis data yang dikhususkan untuk menyimpan banyak vektor dokumen seperti ini, lalu menelusuri vektor yang paling mirip dengan cepat dan efisien untuk vektor kueri tertentu. Karena itu, komponen ini sangat penting untuk memaksimalkan performa retrieval pada RAG.
  Ringkasan: mengapa vector DB dibutuhkan
  Agar LLM dapat mengakses pengetahuan terbaru atau pengetahuan spesifik domain yang tidak dipelajarinya saat training, informasi harus dicari berdasarkan kemiripan semantik, bukan sekadar pencocokan kata kunci (pencarian tradisional). Vector DB adalah teknologi inti yang secara alami terintegrasi ke dalam framework RAG untuk menjalankan pencarian berbasis kemiripan semantik ini secara efisien.