Ask HN: लोकल में RAG को आप कैसे इम्प्लीमेंट कर रहे हैं?

 (news.ycombinator.com)
37 पॉइंट द्वारा GN⁺ 2026-01-16 | 3 टिप्पणियां | WhatsApp पर शेयर करें
  • Hacker News पर एक यूज़र ने पूछा कि लोकल environment में Retrieval-Augmented Generation(RAG) को लोग कैसे इम्प्लीमेंट कर रहे हैं
  • लोकल RAG में vector DB के बिना भी SQLite FTS5, BM25, grep जैसे text search से काम अच्छी तरह चल सकता है—ऐसी राय काफ़ी मज़बूती से सामने आई
  • code search के लिए embeddings धीमे और noisy हैं—ऐसे अनुभव कई लोगों ने साझा किए, और BM25+trigram जैसे keyword-based तरीकों को बेहतर बताने वाली राय भी काफ़ी दिखी
  • vector search की ज़रूरत होने पर भी Postgres+pgvector, SQLite में vector BLOB storage, FAISS in-memory loading जैसे हल्के सेटअप से समाधान करने के कई उदाहरण दिखे
  • BM25+vector को मिलाने वाली hybrid search और RRF(Reciprocal Rank Fusion), reranking, multi-query expansion जैसे संयोजनों से search quality बेहतर की जा सकती है
  • “RAG=vector DB” की तय धारणा के बजाय, document type, scale और operational burden के हिसाब से simple search → hybrid → agentic विकल्प चुनने की प्रवृत्ति दिखी

search चरण पर साझा निष्कर्ष

  • vector DB या graph को अनिवार्य मानने के बजाय, मौजूदा infrastructure, file type और performance जरूरतों के अनुसार सरल शुरुआत करने वाला दृष्टिकोण अधिक दिखा
  • agent द्वारा filesystem या API को सीधे query करने का तरीका setup और maintenance में आसान हो सकता है, लेकिन थोड़ा धीमा भी हो सकता है
  • “RAG, LLM को search result के छोटे text chunks ही देता है” — इस समझ ने performance improvement का फ़ोकस search quality पर शिफ्ट करने में मदद की
  • “RAG की परिभाषा” को लेकर, vector DB न होने पर भी retrieval+generation है तो RAG है—ऐसी प्रतिक्रिया भी थी, जबकि कुछ लोगों का कहना था कि आम तौर पर यह vector DB को मानकर ही कहा जाता है

embedding models और vector search

  • MongoDB द्वारा विकसित mdbr-leaf-ir embedding model सिर्फ CPU पर चलता है, और इस size class के models में कई leaderboards पर 1st place दर्ज कर चुका है
    • standard 2vCPU server पर लगभग 22 documents/sec और 120 queries/sec प्रोसेस कर सकता है
    • BEIR benchmark में 53.55 score दर्ज किया (all-MiniLM-L12-v2 का score 42.69)
  • model2vec/minish जैसे static word embeddings inference speed में तेज़ हैं, लेकिन search accuracy कम है
    • क्योंकि ये सिर्फ tokenization + lookup table + averaging करते हैं, इसलिए transformer-based models से तेज़ हैं
  • Meta-Llama-3-8B से text chunk per vector बनाकर उसे SQLite BLOB column में store करने और FAISS से search करने का तरीका भी इस्तेमाल हो रहा है
    • 5 million chunks के आधार पर लगभग 40GB memory उपयोग
    • A6000 पर faiss-gpu बहुत तेज़ है, और M1 Ultra का faiss-cpu धीमा होने पर भी दिन में कुछ बार query करने के लिए काफ़ी है

code search के लिए सिफ़ारिशें

  • code के लिए vector database से बचने और BM25+trigram संयोजन अपनाने की सिफ़ारिश
    • embeddings धीमे हैं और code के लिए उपयुक्त नहीं
    • reranker न हो तो noise बढ़ता है, और files को दोबारा reindex करने का बोझ भी रहता है
    • search response तेज़ मिलती है और result quality भी अच्छी रहती है
  • PostgreSQL में plpgsql_bm25 से BM25 search इम्प्लीमेंट किया जा सकता है
    • pgvector के साथ hybrid search + Reciprocal Rank Fusion का support
  • file path + signature पर embeddings लागू करके BM25 के साथ fusion करने पर अच्छे परिणाम मिल सकते हैं
  • gpt-oss 20B को ripgrep के साथ while loop में चलाने वाला agentic तरीका भी प्रभावी बताया गया

database-आधारित solutions

  • SQLite FTS5: Markdown file-आधारित documents के लिए उपयुक्त, और vector DB के बिना भी RAG इम्प्लीमेंट किया जा सकता है
    • हर file में छोटा description field रखकर keyword search से document ढूँढना
    • SQLite में fp16 vectors को BLOB के रूप में store करके, filter से subset बनाने के बाद memory में similarity compute करने वाला design भी संभव
    • sqlite-vec, sqlite-vector, vec0, SQLite का bm25 जैसे विकल्प भी
    • “SQLite आश्चर्यजनक रूप से अच्छा काम करता है”
  • PostgreSQL + pgvector: मौजूदा Postgres knowledge का लाभ लिया जा सकता है, और ops team को handover करना भी आसान
    • hybrid BM25, multi-query expansion, reranking को support करने वाली llmemory library भी उपलब्ध
  • LanceDB: embedded vector DB के रूप में सुविधाजनक
    • Ollama के nomic-embed-text embeddings के साथ उपयोग
  • DuckDB: vector similarity search extension देता है, 3GB से छोटे projects के लिए उपयुक्त
  • Meilisearch, Typesense, Manticore: Elasticsearch/OpenSearch की तुलना में संचालन सरल

hybrid और agentic search

  • nori(usenori.ai): SQLite + vec0 + fts5 से semantic और word search का संयोजन
  • Turbopuffer: vector + BM25 hybrid search support
  • सिर्फ agentic search और text search के संयोजन से भी काफ़ी अच्छे परिणाम मिल सकते हैं
    • vector search और graph RAG जोड़ने पर speed और quality में थोड़ी अतिरिक्त बढ़त मिल सकती है
  • Claude Code/Codex अंदरूनी तौर पर ripgrep का उपयोग करते हैं
  • file paths पर embeddings लगाना भी असरदार है, और BM25 के साथ fusion करने पर और सुधार होता है

BM25 के उपयोग के उदाहरण

  • shebe: BM25-आधारित codebase indexing और search के लिए CLI/MCP tool
    • refactoring workflow में विशेष रूप से उपयोगी (जैसे Istio upgrade के समय बदलाव वाली जगहों की सूची बनाना)
  • 85% मामलों में vector DB के बिना सिर्फ tag matching ही काफ़ी
    • operators ने input और documents दोनों में tags जोड़कर 100% matching हासिल की
  • कई लोगों की राय में ज़्यादातर vector DB ऐसे “हथौड़े” हैं जो न मिल पाने की समस्या को हल करने के लिए बनाए गए हैं

विशेष tools और libraries

  • qmd: Markdown files search के लिए CLI tool, fzf की तुलना में fuzzy query results बेहतर
  • ck: Rust-आधारित semantic grep tool
  • Kiln: drag-and-drop से files जोड़ना, और अलग-अलग settings की तुलना करना संभव
    • extraction methods, embedding models, search methods(BM25, hybrid, vector) की तुलना support
    • search accuracy evaluation और evaluation dataset auto-generation फीचर
  • libragen: version-controlled RAG content library बनाने के लिए CLI/MCP server
    • GitHub repository को RAG DB में बदला जा सकता है
  • piragi: सरल Python RAG library, local/S3/API सहित कई sources support
  • ragtune: local RAG search debugging और benchmarking के लिए CLI tool

document processing और OCR

  • discovery: Qwen-3-VL-8B से document OCR और ChromaDB में vectors store
    • BM25 + embeddings hybrid RAG इम्प्लीमेंटेशन
  • docling: document extraction tool, कई RAG projects में उपयोग
  • PDF conversion में tables, multi-column layout, और page-spanning tables को संभालना मुश्किल
    • Mistral OCR model सबसे अच्छे परिणाम देता है (proprietary model)

memory और context management

  • RAG, LLM को सिर्फ छोटी search-result strings ही भेजता है
    • छोटे models में TOP_K=5 के आसपास सीमा दिखती है, उससे ज़्यादा पर context forgetting होने लगता है
  • files और folders का पहले से summary बनाकर सुधार किया जा सकता है
  • Sonnet + 1M context window के साथ सब कुछ context में डालने वाला तरीका भी इस्तेमाल हो रहा है
  • session files पर semantic search के ज़रिए Claude Code के लिए memory system बनाने के उदाहरण भी मिले

enterprise और बड़े पैमाने के उपयोग

  • रोज़ 300,000 customer interactions प्रोसेस करने में latency और precision बहुत महत्वपूर्ण
    • embeddings + full-text search + IVF-HNSW hybrid approach का उपयोग
    • लगभग 600 distributed systems में information propagation संभालना एक चुनौती
  • KAG(Knowledge Augmented Generation) approach से business rules mapping पर प्रयोग जारी
  • 500,000 से अधिक news articles पर Postgres vector DB के साथ पूर्ण local RAG इम्प्लीमेंट करने में सफलता

अन्य tools और approaches

  • AnythingLLM: documents के लिए bundled vector DB उपलब्ध
  • LibreChat: documents के लिए bundled vector DB शामिल
  • ChromaDB: Obsidian extension के रूप में semantic/hybrid search इम्प्लीमेंटेशन
  • SurrealDB: local vectorization के साथ उपयोग
  • OData query interface: LLM को tool के रूप में देने पर प्रभावी, 40,000-row Excel analysis संभव
  • Nextcloud MCP Server: Qdrant को vector DB के रूप में उपयोग करके personal documents पर semantic search देता है
  • LSP(Language Server Protocol): Claude Code में जोड़ा गया है, लेकिन अभी bug मौजूद हैं
    • TreeSitter अधिक उपयोगी हो सकता है (symbol name से lookup, definition/usage location की खोज)

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

3 टिप्पणियां

 
ryj0902 2026-01-20

हमारी कंपनी के एक कमजोर RAG सिस्टम की परफ़ॉर्मेंस देखने के बाद, ऐसा पोस्ट देखकर मेरा नज़रिया भी थोड़ा-थोड़ा बदल रहा है
 
tensun 2026-01-16

मुझे शक है कि क्या हिंदी ठीक से काम कर रही है।
 
GN⁺ 2026-01-16
Hacker News की राय

  • हमारी टीम एक Q&A डेटाबेस चलाती है
    सवालों और जवाबों दोनों को trigram index और embeddings से index करके Postgres में स्टोर किया जाता है
    search के समय pgvector और trigram search को साथ में इस्तेमाल करते हैं, और relevance score के आधार पर नतीजों को combine करते हैं

  • retrieval चरण के लिए हमने CPU-friendly, high-efficiency text embedding model विकसित किया है
    MongoDB/mdbr-leaf-ir मॉडल, जो इसी आकार के मॉडलों में leaderboard पर नंबर 1 है
    यह Snowflake/snowflake-arctic-embed-m-v1.5 मॉडल के साथ compatible है
    search-sensei demo के जरिए semantic search vs BM25 vs hybrid की तुलना की जा सकती है
    उदाहरण के लिए, embedding model यह पहचान लेता है कि “j lo” का मतलब “Jennifer Lopez” है
    साथ ही हमने training recipe भी सार्वजनिक की है, और इसे साधारण स्तर के hardware पर भी आसानी से train किया जा सकता है

    • जानना चाहूँगा कि इस मॉडल की embedding speed और recall minish या model2vec जैसे static word embeddings की तुलना में कैसी है

  • मैं अप्रैल 2024 से Meta-Llama-3-8B से vector generate कर रहा हूँ
    मैंने RTX-A6000 पर Python और Transformers इस्तेमाल किए, जो तेज़ था लेकिन शोर और गर्मी बहुत थी
    बाद में M1 Ultra पर चला गया और Apple की MLX library इस्तेमाल की, जहाँ speed लगभग समान रही लेकिन सिस्टम काफ़ी शांत था
    Llama model 4k-dimensional है, इसलिए fp16 पर 8KB/chunk बनता है, और मैं इसे numpy.save() से SQLite के BLOB column में स्टोर करता हूँ
    search के समय SQLite से सभी vectors लोड करके numpy.array बनाता हूँ और फिर FAISS से search करता हूँ
    RTX6000 का faiss-gpu बहुत तेज़ है, और M1 Ultra का faiss-cpu भी मेरे उपयोग (दिन में कुछ queries) के लिए काफ़ी तेज़ है
    50 लाख chunks के हिसाब से memory usage लगभग 40GB है, जिसे दोनों मशीनें आराम से संभाल लेती हैं

  • मेरे ज़्यादातर complex documents Markdown files हैं
    मैं tobi/qmd नाम का एक simple CLI tool recommend करता हूँ
    पहले मैं fzf-based workflow इस्तेमाल करता था, लेकिन यह tool बेहतर fuzzy search देता है
    code search के लिए इसका उपयोग नहीं करता

    • परिचय देखकर लगा था कि यह golang में लिखा grep replacement tool होगा, और सोचा था कि इसमें Markdown heading weight जैसी सुविधाएँ होंगी

  • code search के लिए vector database मत इस्तेमाल करो
    embeddings धीमे होते हैं और code के लिए उपयुक्त नहीं हैं
    BM25 + trigram का संयोजन बेहतर नतीजे देता है, और response time भी तेज़ रहता है

    • Postgres में भी hybrid search संभव है
      plpgsql_bm25 project देख सकते हैं
      इसमें BM25 और pgvector को Reciprocal Rank Fusion से जोड़ने का example और Jupyter notebook भी शामिल है
    • मैं भी सहमत हूँ। मैंने पहले grep replacement tool के तौर पर hybrid search आज़माया था, लेकिन लगातार reindexing झंझट भरी थी
      अगर code के लिए बना मॉडल न इस्तेमाल करें, तो vector search बहुत noise पैदा करता है
      अभी gpt-oss 20B को ripgrep के साथ loop में चलाने का तरीका कहीं ज़्यादा तेज़ और सटीक है
    • क्या किसी को ऐसा simple service या Docker image पता है जो BM25 और vector search दोनों दे?
    • file path या signature पर लागू करने पर अच्छे नतीजे मिले
      BM25 के साथ fusion करने पर और सुधार हुआ
    • document search के लिए RAG के उपयोग पर आपकी क्या राय है?

  • local RAG experiments के लिए मैंने local-LLM-with-RAG बनाया है
    Ollama के “nomic-embed-text” से embeddings बनते हैं, और LanceDB को vector DB की तरह इस्तेमाल किया गया है
    हाल में इसे “agentic RAG” तक update किया है, लेकिन छोटे projects के लिए यह ज़रूरत से ज़्यादा हो सकता है

    • मैं भी कुछ ऐसा ही कर रहा हूँ। lance-context इस्तेमाल कर रहा हूँ, जो इसका कहीं ज़्यादा simple version है
    • “RAG” का मतलब समझाने के लिए धन्यवाद। यह thread पढ़ते हुए मैं उलझ गया था

  • fp16 vectors को SQLite में BLOB के रूप में स्टोर करता हूँ, filter करने के बाद memory में लोड करता हूँ और matrix-vector multiplication (matvec) से similarity calculate करता हूँ
    अगर numpy या torch multithreading/BLAS/GPU का उपयोग करें तो यह बहुत तेज़ होता है
    bottleneck आने पर sqlite-vector पर migrate करने का इरादा है
    date या location जैसे filters से data काफ़ी कम हो जाता है, इसलिए यह efficient है
    backend को replaceable interface के पीछे छिपाया गया है

  • मेरे 95% documents छोटे Markdown files हैं, इसलिए मैं SQLite FTS5 से plain text search index इस्तेमाल करता हूँ
    index पहले से था, इसलिए उसे सीधे mastra agent से जोड़ दिया
    हर file में एक short description field है, इसलिए keyword search के बाद अगर description match करे तो पूरा document लोड करता हूँ
    setup में लगभग एक घंटा लगा, और यह बहुत अच्छी तरह काम कर रहा है

    • असल में वही तो RAG(Retrieval-Augmented Generation) है
      embedding-based search ज़्यादा आम है, लेकिन मूल बात वही है

  • हम Postgres से परिचित थे, इसलिए PGVector से शुरुआत की
    बाद में पता चला कि कुछ content prompt के semi-structured fields से 100% match करता है
    क्योंकि operator ने input और document दोनों तरफ tags डालने शुरू कर दिए थे (लगभग 50 documents)
    इसलिए पहले fields search करके उस file को prompt में डालते हैं, और उसके बाद embedding search करते हैं
    नतीजतन 85% मामलों में vectordb की ज़रूरत नहीं पड़ती

    • ज़्यादातर vectordb ऐसे लगते हैं जैसे समाधान ढूँढता हुआ हथौड़ा

  • मैंने llmemory बनाया है और इसे local तथा company apps दोनों में इस्तेमाल कर रहा हूँ
    यह PostgreSQL + pgvector पर आधारित है, और इसमें hybrid BM25, multi-query expansion, reranking जैसी सुविधाएँ शामिल हैं
    इसे पहली बार सार्वजनिक कर रहा हूँ, इसलिए थोड़ा बहुत bug हो सकता है
    performance से मैं काफ़ी संतुष्ट हूँ