RAG जितना आप सोचते हैं, उससे कहीं सरल है

मूल लेख ↗ Hacker News चर्चा ↗

Retrieval-augmented generation (RAG) को उसकी hype से कम नया बताया गया है, और कई लोग कहते हैं कि यह मूलतः पारंपरिक information retrieval के साथ एक LLM है तथा टीमें vector databases और embeddings के साथ इसे अक्सर ज़रूरत से ज़्यादा जटिल बना देती हैं। टिप्पणीकार बार-बार ज़ोर देते हैं कि full-text search और BM25 कई वास्तविक उपयोग मामलों, खासकर technical और code search, के लिए शक्तिशाली, सस्ते, और नियंत्रित करने में आसान रहते हैं, और embeddings अक्सर जरूरत से ज़्यादा आँकी जाती हैं, ट्यून करना कठिन होता है, तथा संचालनगत रूप से महँगी होती हैं। RAG पर AI-generated how‑to सामग्री को लेकर भी संदेह है, साथ ही स्पष्ट design patterns, बेहतर evaluations, और “simple से शुरू करो, complexity केवल आवश्यकता होने पर जोड़ो” दृष्टिकोण की माँग है.

RAG वास्तव में क्या है

  • कई टिप्पणियाँ कहती हैं कि RAG मूलतः “क्लासिक सूचना पुनर्प्राप्ति + LLMs” है, कुछ बिल्कुल नया नहीं।
  • कई लोग बताते हैं कि “RAG ≠ vector search”: कोई भी retrieval (grep, SQL, FTS, web search) जिसके नतीजे LLM में दिए जाएँ, वही RAG है।
  • थ्रेड में कुछ लोग फिर भी अप्रत्यक्ष रूप से RAG को “embeddings + vector DB” मानते हैं, जो चल रही उलझन दिखाता है।

Embeddings बनाम Full‑Text / Keyword Search

  • एक मजबूत थीम: full‑text search (FTS/BM25/Lucene/Elasticsearch/Postgres FTS) कम आँका जाता है और आम तौर पर पहले आज़माया जाना चाहिए।
  • FTS के पक्ष में तर्क: सरल, निर्धार्य, परिपक्व tooling, डिबग करना आसान, अच्छी स्केलिंग, और अक्सर तकनीकी या code-like queries के लिए बेहतर।
  • embeddings के पक्ष में तर्क: अस्पष्ट या वर्णनात्मक queries, synonyms, multi-language search, और जब उपयोगकर्ताओं को exact terms पता न हों, तब उपयोगी।
  • कुछ लोग embeddings के साथ वास्तविक-विश्व निराशा बताते हैं: अपेक्षा से कम semantic similarity, संचालनगत overhead अधिक, reranking pipelines जटिल।
  • अन्य लोग simple embedding-based semantic search या hybrid BM25+vector approaches से अच्छे नतीजे बताते हैं।

Chunking, Scale, और Document Structure

  • chunk size को बार-बार महत्वपूर्ण बताया गया है; खराब chunking retrieval को, model चाहे जो भी हो, बिगाड़ सकती है।
  • लंबे दस्तावेज़ (books, reports, PDFs) समस्याएँ लाते हैं: token limits, chunks के बीच संदर्भ (“it” का पीछे लौटकर किसी चीज़ को refer करना), और बहुत सारे overlapping segments embed करने पर index size का बढ़ना।
  • इस पर बहस है कि क्या मध्यम-आकार के chunks (512–1024 tokens) आम तौर पर topic context पकड़ने के लिए पर्याप्त होते हैं; कुछ कहते हैं हाँ, कुछ कहते हैं कि relational information फिर भी खो जाती है।

Use Cases: Code, Enterprise Docs, Multilingual

  • code के लिए: कई tools और teams बताते हैं कि simple grep या FTS के साथ smart agents अक्सर RAG से बेहतर प्रदर्शन करते हैं; कुछ ने तो retrieval पूरी तरह हटा दिया, और users को पता भी नहीं चला।
  • बहुत बड़े codebases और abstract “concept” lookups के लिए retrieval फिर भी मदद कर सकती है।
  • enterprise/finance docs में, जहाँ jargon और acronyms बहुत हैं, BM25 संघर्ष कर सकता है; embeddings या cross-language setups बेहतर काम कर सकते हैं।
  • embeddings को cross-lingual search के लिए language-agnostic “common space” के रूप में देखा गया है, लेकिन debugging अधिक कठिन है।

System Design, Agents, और Orchestration

  • कई लोगों के अनुसार असली “dragons” embeddings में नहीं, बल्कि retrieval design में हैं: freshness, access control, versioning, overlapping docs, evals, और ranking।
  • classic search के ऊपर agentic query rewriting लोकप्रिय है: LLM को queries बनाने और iteratively सुधारने दें, फिर नीचे स्थिर lexical/FTS infrastructure का उपयोग करें।
  • कुछ लोग RAG को orchestration problem मानते हैं: use case और quality requirements के अनुसार exact search, vector, SQL, tagging, rules जैसे modules मिलाना।

Costs, Tooling, और Practical Tips

  • एक पक्ष कहता है “सब कुछ एक बार embed करो, changes track करो, और vectors को BigQuery जैसी चीज़ में store करो,” बशर्ते corpus size सीमित हो।
  • दूसरे vendor lock‑in से सावधान करते हैं और portable tech, simple Postgres/BM25/pgvector, या LLM-generated SQL के साथ SQLite FTS5 चुनने की सलाह देते हैं।
  • यह निराशा भी है कि कई RAG how‑tos methods को evals से नहीं जोड़ते; लोग benchmarks और यह मार्गदर्शन चाहते हैं कि कौन-सी retrieval recipe वास्तव में outcomes सुधारती है।

Skepticism, Hype, और Writing Style

  • कुछ commenters का तर्क है कि लेख LLM-generated “AI slop” जैसा पढ़ता है: बढ़ा-चढ़ा कर लिखे headings, कमजोर “why” के साथ सतही “what” lists, और hybrid recipes जो machine-stitched लगती हैं।
  • फिर भी कुछ लोग style के बावजूद सामग्री को व्यावहारिक रूप से उपयोगी मानते हैं।
  • व्यापक प्रतिक्रिया भी दिखती है: AI-generated prose से थकान, यह दावा कि RAG का अति-उपयोग हुआ है, “magic beans,” या “so 2024,” और यह पुकार कि सबसे सरल काम करने वाली search से शुरू करें और स्पष्ट आवश्यकता होने पर ही जटिलता जोड़ें।