क्या आप local RAG बनाना चाहते हैं?

 (blog.yakkomajuri.com)
37 पॉइंट द्वारा GN⁺ 2025-11-30 | 7 टिप्पणियां | WhatsApp पर शेयर करें
  • Skald को इस लक्ष्य के साथ विकसित किया गया है कि यह डेटा को किसी third party को भेजे बिना पूरी तरह self-hostable RAG system उपलब्ध कराए
  • RAG के घटकों को vector database, embedding model, LLM, reranker, document parser में बाँटा गया है, और हर घटक के लिए open source alternatives प्रस्तुत किए गए हैं
  • Skald का डिफ़ॉल्ट local stack Postgres+pgvector, Sentence Transformers, Docling, और custom LLM से बना है
  • benchmark नतीजों में cloud-based models (Voyage+Claude) को औसतन 9.45 अंक मिले, जबकि fully local GPT-OSS 20B को 7.10~8.63 अंक दिए गए
  • यह तरीका दिखाता है कि data privacy बनाए रखते हुए भी high-performance RAG बनाया जा सकता है

RAG के घटक और open source alternatives

  • बुनियादी RAG में vector database, embedding model, LLM शामिल होते हैं, और अतिरिक्त रूप से reranker और document parser भी जोड़े जा सकते हैं
    • हर घटक को SaaS की जगह local alternative से बदला जा सकता है
  • उदाहरण तालिका में सुझाए गए विकल्प
    • 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 एक पूर्ण open source stack की दिशा में काम करता है, जिसमें हर घटक local तौर पर चलता है

Skald का local stack configuration

  • Vector DB: Postgres + pgvector का उपयोग
    • मौजूदा infrastructure में आसानी से integrate होता है और कई लाख documents तक संभाल सकता है
  • Vector Embeddings: डिफ़ॉल्ट रूप से Sentence Transformers (all-MiniLM-L6-v2)
    • केवल अंग्रेज़ी के लिए, speed और retrieval performance के बीच संतुलन
    • bge-m3 model (multilingual support) का भी परीक्षण किया गया
  • LLM: कोई built-in डिफ़ॉल्ट नहीं, इसे user स्वयं चलाता है
    • परीक्षण में GPT-OSS 20B को EC2 पर चलाया गया
  • Reranker: डिफ़ॉल्ट रूप से Sentence Transformers Cross-Encoder, और multilingual models जैसे bge-reranker-v2-m3 भी इस्तेमाल किए जा सकते हैं
  • Document Parsing: Docling का उपयोग, जिसे docling-serve के साथ चलाया गया

प्रदर्शन और deployment परिणाम

  • पूरे stack सहित Skald production instance deploy करने में 8 मिनट लगे
    • इसमें Postgres, embedding·reranking services, और Docling शामिल थे
    • LLM अलग से चलाया गया (llama.cpp का उपयोग)
  • test dataset में PostHog website content (लगभग 2000 documents) और स्वयं तैयार किया गया question-answer set शामिल था
  • experiment settings
    • Vector search topK=100, Reranking topK=50, Query rewriting=Off
    • evaluation का केंद्र accuracy था

benchmark परिणामों की तुलना

  • Voyage + Claude (cloud configuration)
    • औसत स्कोर 9.45, सभी उत्तर सही
  • Voyage + GPT-OSS 20B (partially local)
    • औसत स्कोर 9.18, अधिकांश उत्तर सही, लेकिन कुछ जानकारी छूटी
  • fully local + GPT-OSS 20B
    • बेसिक English model (all-MiniLM-L6-v2 + ms-marco-MiniLM-L6-v2) : औसत 7.10
      • अंग्रेज़ी queries में सही, लेकिन multilingual, अस्पष्ट queries, और multi-document aggregation में कमज़ोरी
    • multilingual model (bge-m3 + mmarco-mMiniLMv2-L12-H384-v1) : औसत 8.63
      • Portuguese queries को सफलतापूर्वक संभाला, लेकिन multi-document aggregation में कुछ कमी रही
  • मुख्य सीमा है कई documents में बिखरी जानकारी को जोड़कर संभालना
    • cloud models अपनी उच्च performance से इसे बेहतर संभालते हैं, लेकिन local environment में अतिरिक्त techniques की ज़रूरत होती है

आगे की योजना

  • Skald की योजना local RAG performance को बेहतर बनाने और open source model benchmarks सार्वजनिक करने की है
  • लक्ष्य है air-gapped environments में AI tools चलाने वाली कंपनियों के लिए समाधान उपलब्ध कराना
  • इच्छुक लोग GitHub(skaldlabs/skald) या Slack community के ज़रिए सहयोग कर सकते हैं

संबंधित पढ़ाई

7 टिप्पणियां

 
iolothebard 2025-11-30

यह बात कि RAG के लिए vector DB ज़रूरी है, आखिर शुरू कहाँ से हुई…
 
aer0700 2025-11-30

वेक्टर DB वगैरह कुछ भी हो, असल में तो बस search implement करना ही काफी होगा...
 
dkmin 2025-11-30

Gemini :
हाँ, RAG (Retrieval-Augmented Generation) में vector database (Vector Database) के उपयोग की अवधारणात्मक नींव 2020 में संबंधित पेपर पहली बार प्रकाशित होने के साथ ही रखी गई थी।
RAG मूल रूप से retrieval और generation को जोड़ने का तरीका है, और इस retrieval चरण में vector embedding तथा उन्हें कुशलतापूर्वक स्टोर और सर्च करने वाला vector database अनिवार्य भूमिका निभाता है।
💡 RAG और vector DB की शुरुआत
RAG में vector DB की आवश्यकता का विचार निम्नलिखित प्रमुख पेपरों और अवधारणाओं से शुरू हुआ।

  1. RAG का जन्म: Lewis et al. (2020) पेपर
  • पेपर का शीर्षक: "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks" (ज्ञान-गहन प्राकृतिक भाषा प्रसंस्करण कार्यों के लिए retrieval-augmented generation)
  • मुख्य बिंदु: इस पेपर में पहली बार RAG शब्द और framework प्रस्तुत किया गया था।
  • Retriever की भूमिका: पेपर में प्रस्तावित RAG मॉडल Retriever और Generator से मिलकर बना है। Retriever, Wikipedia जैसे बड़े dataset से query से संबंधित document (latent documents) खोजता है।
  • vector index का उपयोग: इस शुरुआती RAG मॉडल ने documents को खोजने के लिए dataset में vector index (Vector Index) का उपयोग किया, ताकि pretrained retriever documents ला सके।
  • निष्कर्ष: चूँकि RAG का मुख्य चरण 'retrieval' query और document के vector representation पर आधारित similarity की गणना करके किया जाता है, इसलिए कुशल खोज के लिए vector store (Vector Store) या vector index की अवधारणा स्वाभाविक रूप से अनिवार्य रूप में शामिल थी।
  1. vector embedding और similarity search
    vector database के RAG का अनिवार्य तत्व बनने के मूल कारण इस प्रकार हैं।
  • embedding (Embedding): RAG सिस्टम में external knowledge (documents, text) और user query (प्रश्न) दोनों को vector नामक गणितीय representation में बदला जाता है। यह vector, text के अर्थ को high-dimensional space में dense संख्यात्मक array के रूप में दर्शाता है।
  • similarity search (Similarity Search): vector space में query vector के सबसे नज़दीकी distance पर मौजूद document vector को खोजना, अर्थ के स्तर पर सबसे अधिक समान (relevant) document को खोजना होता है।
  • vector DB की भूमिका: vector database ऐसे बहुत सारे document vectors को स्टोर करता है और दिए गए query vector के लिए सबसे समान vector को तेज़ी और कुशलता से खोजने के लिए विशेष रूप से डिज़ाइन किया गया database है। इसलिए RAG की retrieval performance को अधिकतम करने में यह अनिवार्य है।
    सारांश: vector DB की ज़रूरत क्यों है
    यदि LLM को ऐसे नवीनतम या domain-specific ज्ञान तक पहुँच देनी है, जो उसने training में नहीं सीखा, तो केवल keyword matching (पारंपरिक खोज) से काम नहीं चलेगा; जानकारी को semantic similarity के आधार पर खोजना होगा। vector DB इसी semantic similarity-आधारित खोज को कुशलतापूर्वक करने के लिए RAG framework में स्वाभाविक रूप से एकीकृत की गई मुख्य तकनीक है.
 
aer0700 2025-12-03

असल में RAG के लिए ज़रूरी चीज़ search functionality है, और dense vector में embedding करके उसे vectorDB में push करना और cosine similarity search करना, search engine को implement करने के कई तरीकों में से बस एक तरीका भर है... ऐसा नहीं है कि vectorDB का इस्तेमाल न करने की कोई खास वजह है, लेकिन अगर पूछें कि क्या यह सचमुच अनिवार्य है, तो लंबे समय से अच्छी तरह इस्तेमाल होते आए search engine algorithms भी बहुत हैं, इसलिए थोड़ा सवाल तो उठता ही है।
 
ztaka 2025-12-02

क्योंकि यह सस्ता है और ज़्यादातर production LLM भी यही इस्तेमाल करते हैं।
असल में अगर web server के मामले में भी यही तर्क लगाएँ, तो infra फीचर जोड़कर डिस्क पर ही सब कुछ किया जा सकता है, इसलिए dbms की भी ज़रूरत नहीं पड़ेगी lol
 
gcback 2025-12-01

यह सही है कि user query के embedding value (vector) को key की तरह इस्तेमाल करने वाली एक तरह की similarity/semantic search के लिए DB की ज़रूरत होती है, और क्योंकि key vector के रूप में होता है, इसलिए vector DB भी सही है।
 
GN⁺ 2025-11-30
Hacker News राय

  • ऐसे सिस्टम बनाते समय मेरी सलाह है कि vector database या embeddings पर ज़रूरत से ज़्यादा अटकें नहीं
    full-text search या grep/rg जैसे टूल कहीं ज़्यादा तेज़ और सस्ते होते हैं, और index को maintain करने की भी ज़रूरत नहीं पड़ती
    अगर किसी अच्छे LLM को search tool दे दिया जाए, तो वह “dog OR canine” जैसी query खुद बना सकता है और उसे बार-बार बेहतर भी कर सकता है
    ऊपर से, इस तरह chunking problem को हल करने की ज़रूरत भी नहीं रहती

    • मैंने browser में embedding-based (“semantic”) और BM25 search के बीच का अंतर दिखाने के लिए एक छोटा app बनाया है
      इसे Search Sensei पर देखा जा सकता है
      पहली बार load होने पर यह लगभग 50MB model weights और onnx runtime डाउनलोड करता है, लेकिन उसके बाद काफ़ी smooth चलता है
      उदाहरण के लिए, BM25 यह नहीं समझ पाता कि “j lo” और “jlo” का मतलब Jennifer Lopez है, लेकिन embedding-based search ऐसे typo या alias को काफ़ी अच्छी तरह संभाल लेता है
      यह 2016~2024 के 1000 news articles पर search चलाता है
    • Anthropic की contextual retrieval research के अनुसार, embedding + BM25 का combination सबसे अच्छे नतीजे देता है
      लेकिन अफ़सोस है कि BM25 अकेले का performance सार्वजनिक नहीं किया गया
      मेरे छोटे tests में ऐसे cases थे जहाँ query के exact शब्द page में मौजूद थे, फिर भी embedding उन्हें miss कर गया — आख़िर में Ctrl+F जीत गया
    • मेरे अनुभव में semantic vs lexical search को precision और recall के trade-off की तरह समझना सही है
      lexical search की precision ज़्यादा होती है लेकिन recall कम, और semantic search इसके उलट तरफ़ होता है
    • Google Maps में “billiards” search किया तो synonym problem के कारण swimming pool और goats से जुड़े results आने लगे
      लगा कि “NOT” operator की ज़्यादा ज़रूरत है। RAG के बारे में भी और सीखना चाहता हूँ
    • जिज्ञासा है कि इस तरह search करते समय क्या कोई standard prompt इस्तेमाल किया जाता है
      कुछ agent-style tools को मैंने ऐसी queries अपने-आप बनाते देखा है, लेकिन समझ नहीं आया कि यह prompt से कराया गया है या default behavior है

  • performance कम होने की एक वजह semantic chunking की कमी भी हो सकती है
    अगर पूरे document को embed कर दिया जाए, तो कई concepts मिल जाते हैं और accuracy गिरती है
    Spacy जैसे टूल से उसे meaning units में बाँटना चाहिए, और हर chunk किस context में है यह जोड़कर फिर embedding बनानी चाहिए
    Anthropic की contextual retrieval approach RAG systems में बहुत असरदार रही है
    context generation के लिए GPT OSS 20B model इस्तेमाल किया जा सकता है

    • मैं मूल लेखक नहीं हूँ, लेकिन हम पहले से ही semantic chunking कर रहे हैं
      लगता है भ्रम इसलिए हुआ क्योंकि test ऐसे सवालों पर था जिनमें कई documents का context जोड़ना पड़ता है

  • समझ नहीं आता कि semantic search को lexical search से बेहतर मानकर क्यों चला जाता है
    2023 में Tantivy(BM25) से तुलना की थी और नतीजों में फ़र्क़ बहुत मामूली था
    थोड़ा recall बढ़ भी जाए, तब भी पता नहीं इतना complex setup बनाना उसके लायक है या नहीं

    • यह testing method पर निर्भर करता है
      developer tests में recall 90% था, लेकिन real user tests में यह लगभग 30% तक गिर गया
      users को documents की exact terminology पता नहीं होती, इसलिए सिर्फ lexical search काफ़ी नहीं था
      agent जोड़ सकते हैं, लेकिन latency बढ़ जाती है और user satisfaction घटती है
    • यह app की प्रकृति पर भी निर्भर करता है
      Wanderfugl में semantic search ऐसे हिस्से भी ढूँढ लेता है जिनका BM25 score कम होता है
      आख़िरकार hybrid ranking ही जवाब हो सकता है
    • “दो scientists के बीच बातचीत” जैसी query संभाल पाने की क्षमता इसका फ़ायदा है
      आख़िर में यह use case dependent है

  • मैं ऐसा open source tool ढूँढ रहा हूँ जो email, Slack, GDrive, code, wiki आदि सभी data को local offline mode में query कर सके
    खुद से build या customize करने से बचना चाहता हूँ, और अच्छे defaults व model recommendations मिल जाएँ तो बढ़िया होगा

    • इसी वजह से मैंने Nextcloud MCP server बनाया
      GitHub लिंक
      यह basic CRUD support करता है, और vector search enable करने पर documents या notes को embed करता है
      embedding provider के रूप में Ollama और OpenAI को support करता है
      MCP server semantic + BM25(qdrant fusion) search दोनों देता है, और MCP sampling के ज़रिए responses बनाता है
      server खुद जवाब generate नहीं करता, इसलिए किसी भी LLM/MCP client के साथ जोड़ा जा सकता है
      यह MCP sampling/RAG pattern बहुत ताकतवर है, और संभव है कि दूसरे data sources के लिए इसका एक generalized open source version भी आए

  • हम जो टूल इस्तेमाल करते हैं वह haiku.rag है
    यह developer-friendly Python code, pydantic-ai आधारित structure, benchmarks, और advanced citation features देता है
    यह deep research agent को support करता है, और लंबे समय तक maintain होने वाला सचमुच का open source project है

  • default embedding model के रूप में हम Sentence Transformers (all-MiniLM-L6-v2) इस्तेमाल कर रहे हैं, लेकिन अब समझ आया कि यह सिर्फ English के लिए है, इसलिए German RAG बनाते समय समस्या हो सकती है
    non-English models का performance कैसा है, यह जानना चाहता हूँ

    • इसके लिए MTEB leaderboard देखा जा सकता है
      “Retrieval” section में RTEB Multilingual या RTEB German entries देख लें
      अगर CPU-based self-hosting कर रहे हैं, तो 100M parameters से कम वाले models पर filter लगाना बेहतर रहेगा
    • कई models non-English भाषाओं में performance drop दिखाते हैं
      लेकिन German के लिए training data अपेक्षाकृत ज़्यादा है, और multilingual models भी काफ़ी उपलब्ध हैं
      ख़ासकर commercial API-based models में ज़्यादातर multilingual support होता है
    • हम भी पहले multilingual embedding models इस्तेमाल कर चुके हैं
      संबंधित paper के लिए Springer लिंक देख सकते हैं

  • GPT-4 के दौर में (8K context) मैंने एक script बनाई थी जो पूरी किताब को chunks में बाँटकर GPT-4 में डालती थी और relevant passages search करती थी
    तब एक search पर लगभग 1 डॉलर खर्च आता था, लेकिन अब यह बहुत सस्ता हो गया है
    Anthropic की contextual retrieval पोस्ट में भी कहा गया है कि अगर document पूरा context में आ सकता है, तो RAG की जगह उसे सीधे डालना बेहतर है
    हालाँकि context लंबा होने पर quality गिरती है, और cost व speed भी समस्या बनते हैं
    अब पूरी किताब context में डालना भी लगभग 1 cent में संभव है

  • RAG में सबसे मुश्किल हिस्सा document parsing है
    सिर्फ text हो तो ठीक है, लेकिन tables, multi-page tables, charts, table of contents, footnotes जैसी चीज़ें आते ही accuracy तेज़ी से गिर जाती है
    इसे बेहतर करने के लिए RAPTOR pattern जैसी approach है, जहाँ LLM content को summarize करता है, questions बनाता है, और फिर उसे vector DB में store करता है
    लेकिन हर case में काम करने वाली general-purpose RAG pipeline अब भी एक कठिन चुनौती है

    • vector embeddings में नए व्यक्ति के तौर पर मुझे पता नहीं था कि tables इतनी जटिल समस्या पैदा करती हैं
      यह भी जानना चाहता हूँ कि vector DB लंबे text groups को बेहतर संभालता है या tabular format को

  • full-text search को RAG में लागू करने का यह नया नज़रिया दिलचस्प लगा
    agent-style tool loop और fuzzy search को संभालने के तरीके पर मिली insight प्रभावशाली थी

  • जिज्ञासा है कि क्या ऐसे systems के लिए evaluation datasets standardized हैं
    अच्छा होगा अगर documents और questions का ऐसा benchmark हो, जिसमें किसी खास document या chunk को सबसे relevant result के रूप में आना चाहिए

    • उसके लिए haiku-rag benchmark और evaluation set देख सकते हैं