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

 (news.ycombinator.com)
37 पॉइंट द्वारा GN⁺ 2026-01-16 | अभी कोई टिप्पणी नहीं है. | 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 की खोज)

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

अभी कोई टिप्पणी नहीं है.

अभी कोई टिप्पणी नहीं है.