विषय-सूची
- 1. पुनरावलोकन: naive RAG की सीमाएं
- 2. आधुनिक RAG pipeline एक नजर में
- 3. ① Chunking (सबसे महत्वपूर्ण)
- 4. ② embedding model चुनना
- 5. ③ vector DB चुनना (तुलना)
- 6. ④ Hybrid search (BM25 + vector)
- 7. ⑤ Reranking (retrieve-then-rerank)
- 8. Frameworks (LlamaIndex/LangChain)
- 9. RAG बनाम long context
- 10. production में लाते समय सावधानियां
- सारांश
- FAQ
आप समझते हैं कि RAG क्या है। लेकिन जब आप वास्तव में एक बनाते हैं, तो कई लोग एक दीवार से टकराते हैं: "यह कुछ हद तक काम करता है, पर मुख्य जवाब गलत आता है।" इसका कारण लगभग हमेशा एक ही होता है — यह अब भी "naive RAG" है: दस्तावेज़ को लापरवाही से काट देना और एक साधारण vector search करना।
2026 में व्यावहारिक RAG उस अवस्था से स्पष्ट रूप से आगे बढ़ चुका है। कुंजी एक बहु-चरणीय pipeline है: "smart chunking → सही embedding → hybrid search (keyword + vector) → reranking।" लेख 030 के implementation फॉलो-अप के रूप में, इसमें हर चरण का ठोस तरीका, vector DB चुनना (Chroma/pgvector/Qdrant/Pinecone/Weaviate/Milvus), frameworks, और यहां तक कि "क्या 1M-token युग में हमें अब भी RAG की जरूरत है?" — एक अधिक उन्नत implementation की आवश्यक बातें शामिल हैं।
आधुनिक RAG के 5 चरण
— naive RAG से लेकर production में चलने वाले RAG तक
सटीकता में दो सबसे बड़े लाभ: hybrid search (BM25 + vector) और reranking।
केवल इन दोनों को जोड़ने से naive RAG की "जवाब गलत है" समस्या काफी हद तक ठीक हो जाती है।
* tool नाम, तरीके, और benchmark आंकड़े आधिकारिक स्रोतों और कई tech आउटलेट्स पर आधारित हैं (2026 तक)। यह क्षेत्र तेजी से विकसित होता है और सर्वोत्तम विकल्प बदलते रहते हैं। benchmark आंकड़े स्रोत-रिपोर्टेड हैं और डेटा व परिस्थितियों के अनुसार भिन्न होते हैं। चुनने से पहले अपने डेटा पर मूल्यांकन करें (नीचे)।
1. पुनरावलोकन: naive RAG की सीमाएं
न्यूनतम RAG है "दस्तावेज़ विभाजित करें → embeddings से vectorize करें → vector DB में स्टोर करें → प्रश्न को vectorize करें और निकटतम chunks लाएं → जवाब देने के लिए LLM को पास करें।" यही RAG की मूल बातें हैं। पर इस "naive RAG" की कुछ विशिष्ट कमजोरियां हैं।
- लापरवाह chunks: वाक्य के बीच में कट जाना, जिससे अर्थ टूट जाता है।
- केवल vector search: product नामों या model नंबरों जैसे सटीक पदों पर कमजोर (यह उन चीजों को पकड़ता/छोड़ता है जो अर्थ में करीब हैं पर शब्दों में अलग हैं)।
- top N को जस का तस पास करना: वास्तव में सबसे प्रासंगिक आइटम दब जाते हैं।
2026 में व्यावहारिक RAG इन तीनों को "smart विभाजन," "hybrid search," और "reranking" से कुचल देता है। चलिए क्रम से चलते हैं।
2. आधुनिक RAG pipeline एक नजर में
एक production RAG डेटा फ्लो में दो ट्रैक होते हैं: तैयारी (indexing) और query समय (search & generate)।
दो चरण
तैयारी (offline): दस्तावेज़ को समझदारी से chunk करें → embeddings से vectorize करें → vector DB में स्टोर करें (साथ ही एक keyword index बनाएं)।
query समय (online): hybrid search (BM25 + vector) से top 50-100 लाएं → reranking से कुछ तक संकुचित करें → जवाब उत्पन्न करने के लिए LLM को पास करें।
naive RAG से अंतर यह है कि "④ hybrid search" और "⑤ reranking" मौजूद हैं या नहीं। ये दो चरण search सटीकता को व्यावहारिक स्तर तक बढ़ाते हैं।
3. ① Chunking (सबसे महत्वपूर्ण)
यह कहना उचित है कि chunking RAG गुणवत्ता का आधा हिस्सा तय करता है। यहां मुख्य रणनीतियां हैं।
| रणनीति | यह क्या करती है | किसके लिए अच्छी |
|---|---|---|
| recursive 512 tokens | एक व्यावहारिक डिफ़ॉल्ट। Feb 2026 के एक benchmark में 7 रणनीतियों में #1 रिपोर्ट किया गया | जब संदेह हो, तो यही |
| semantic | वहां विभाजित करें जहां अर्थ बदलता है, ताकि हर chunk विषय की दृष्टि से सुसंगत हो | घने technical दस्तावेज़ |
| structural | headings, code blocks, HTML sections का सम्मान करें | documentation और code |
| parent-child (hierarchical) | छोटे chunks पर सटीक search करें; जवाब के समय आसपास का parent chunk लौटाएं | सटीकता और संदर्भ का संतुलन |
यदि सीमाओं पर संदर्भ का नुकसान समस्या है, तो Contextual Retrieval (हर chunk से पूरे-दस्तावेज़ का संदर्भ जोड़ना) या Late Chunking मदद करता है। Anthropic रिपोर्ट करता है कि Contextual Retrieval + reranking ने top-20 retrieval विफलताओं को 67% तक घटा दिया (एक रिपोर्टेड आंकड़ा)। यथार्थवादी क्रम: "recursive 512" से शुरू करें, और यदि सटीकता कम पड़े तो semantic / parent-child / Contextual Retrieval जोड़ें।
4. ② embedding model चुनना
embedding model chunks को vectors में बदलता है — search सटीकता की नींव।
- सुरक्षित डिफ़ॉल्ट: OpenAI text-embedding-3-large। retrieval गुणवत्ता और integration की आसानी का अच्छा संतुलन।
- अन्य विकल्प: Cohere, Voyage, Gemini embeddings, और विभिन्न OSS models।
- महत्वपूर्ण: कई OSS embeddings hybrid search + reranking के साथ मिलाने पर production के लिए पर्याप्त होते हैं। केवल embedding पर अटके न रहें।
मुख्य बात है "embedding को पूरे search pipeline का एक हिस्सा" मानना। एक महंगे embedding को बदलने के बजाय, hybrid search और reranking जोड़ना अक्सर अधिक लागत-प्रभावी होता है।
5. ③ vector DB चुनना (तुलना)
vector DB vectors को स्टोर और search करता है। यहां 2026 के अग्रणी अपने चरित्र के अनुसार हैं।
| DB | चरित्र / ताकत | किसके लिए |
|---|---|---|
| Chroma | AI-native, local-first, सरल Python API | व्यक्ति/PoCs जो RAG को सबसे तेजी से prototype करते हैं |
| pgvector | एक Postgres extension। कोई दूसरा DB नहीं, transactional संगति | वे टीमें जो पहले से Postgres पर हैं |
| Qdrant | कम latency (p50 ~4ms; रिपोर्टेड बनाम Milvus ~6ms / Pinecone ~8ms) | गति-केंद्रित, production |
| Pinecone | पूरी तरह managed। कोई infra नहीं, केवल एक API key से शुरू करें | जो ops संभाला हुआ चाहते हैं, cloud-first |
| Weaviate | Hybrid-search चैंपियन (एक query में BM25 + vector + metadata) | भारी hybrid-search उपयोगकर्ता |
| Milvus | enterprise-grade, अरबों vectors संभालता है | बहुत बड़ा पैमाना |
चयन के मापदंड: "पैमाना, managed बनाम self-hosted, मौजूदा stack, बजट।" जब संदेह हो — prototyping के लिए Chroma, यदि Postgres है तो pgvector, संतुलित production के लिए Qdrant/Pinecone, hybrid-भारी के लिए Weaviate। अधिकांश RAG workloads के लिए, Pinecone / Weaviate / Qdrant मजबूत विकल्प माने जाते हैं।
6. ④ Hybrid search (BM25 + vector)
जो naive RAG की सबसे बड़ी कमजोरी — सटीक पदों पर कमजोर होना — को ठीक करता है, वह है hybrid search। यह BM25 (keyword/lexical search) को dense vector search के साथ मिलाता है।
lexical + semantic को मिलाएं
दोनों को Reciprocal Rank Fusion (RRF) से मिलाना रिपोर्ट किया गया है कि
यह किसी भी एक तरीके से लगातार बेहतर परिणाम देता है (उच्च NDCG)।
व्यवहार में, ऐसा DB उपयोग करना सबसे आसान है जो एक ही query में hybrid परिणाम लौटाता है, जैसे Weaviate। पेचीदा score tuning को RRF (rank-आधारित fusion) पर छोड़ दें और यह नहीं टूटेगा। परिणाम: ऐसा search जो सटीक पदों और paraphrases दोनों पर मजबूत है।
7. ⑤ Reranking (retrieve-then-rerank)
2026 का मानक है "दो चरण: पहले व्यापक रूप से retrieve करें → फिर संकुचित करें (rerank)।"
- Stage 1 (retrieve): bi-encoder (embeddings) से top 50-100 को जल्दी लाएं।
- Stage 2 (rerank): cross-encoder से, (प्रश्न, chunk) को संयुक्त रूप से score करें और वास्तव में सबसे प्रासंगिक कुछ तक संकुचित करें।
लोकप्रिय rerankers हैं Cohere Rerank 3.5, Voyage rerank-2.5, BGE reranker-v2, Jina Reranker v2। Reranking लगभग 50-200ms की latency और लागत जोड़ता है, पर क्योंकि LLM को पास किए जाने वाले chunks चुनिंदा कुछ बन जाते हैं, यह अक्सर LLM token खपत घटाता है और कुल लागत कम करता है। सटीकता और लागत दोनों पर, reranking ऐसा चरण बनता जा रहा है जिसे "न जोड़ने का कोई कारण नहीं।"
8. Frameworks (LlamaIndex/LangChain)
framework का उपयोग करना सब कुछ खुद लिखने से तेज है। यहां 2026 का कार्य-विभाजन है।
- LlamaIndex: retrieval-केंद्रित। दस्तावेज़ indexing, search गुणवत्ता, और तेज RAG iteration में मजबूत।
- LangChain / LangGraph: orchestration (नियंत्रण) पक्ष। जटिल workflows और agent समन्वय।
- संयुक्त pattern: व्यवहार में, कई लोग retrieval layer के रूप में LlamaIndex और control layer के रूप में LangGraph का उपयोग करते हैं।
ध्यान दें कि हाल ही में, MCP के जरिए tool मानकीकरण और Agent SDKs के उदय के साथ, एक रुझान है कि agents भारी LLM frameworks के बिना तुरंत pipelines बनाते हैं। फिर भी, यदि आप search गुणवत्ता को निखार रहे हैं, तो LlamaIndex परिवार मजबूत बना रहता है। सामान्य रूप से agent बनाने के लिए, देखें AI agent कैसे बनाएं।
9. RAG बनाम long context
"1M-token context window के साथ, क्या मैं बस सब कुछ अंदर भर दूं और RAG छोड़ दूं?" — एक आम सवाल। जवाब है "नहीं, RAG प्रतिस्थापित नहीं होता।"
"सब कुछ भर दो" का जाल
- token-अकुशल: हर बार एक विशाल, अनावश्यक संदर्भ भेजना महंगा है।
- lost in the middle: लंबे पाठ के बीच की जानकारी अनदेखी होती है।
- distraction: जितनी अधिक असंबद्ध जानकारी, उतनी कम जवाब गुणवत्ता।
दिशानिर्देश: छोटे corpora और तेज iteration के लिए long context का उपयोग करें, स्थिर दोहराए जाने वाले संदर्भ के लिए जल्दी prompt caching जोड़ें, और जैसे ही "ताजगी, पैमाना, उत्पत्ति" आवश्यकताएं बनें, RAG जोड़ें। "बस context window में भर दो" नया "बस एक vector DB जोड़ दो" है — कोई रामबाण नहीं। इसे context window की समझ के साथ जोड़ें।
10. production में लाते समय सावधानियां
- पहले एक eval बनाएं: "कुछ हद तक बेहतर हो गया" को सुधारा नहीं जा सकता। प्रतिनिधि प्रश्नों × अपेक्षित स्रोतों के एक सेट से retrieval सटीकता को मापें और हर बदलाव के अनुसार तुलना करें।
- Monitoring: retrieval hit rate, rerank के बाद की प्रासंगिकता, और जवाब grounding को निरंतर देखें।
- लागत डिजाइन: बिलिंग embeddings, reranking, और LLM से आती है। reranking के जरिए LLM tokens कम करना मानक लागत-बचत है। देखें token-बचत।
- ताजगी और उत्पत्ति: डेटा अपडेट (re-indexing) को दर्शाने और जवाबों से हमेशा स्रोत (कौन सा दस्तावेज़) जोड़ने के लिए डिजाइन करें — hallucination से लड़ने की कुंजी।
- गोपनीय डेटा: आंतरिक दस्तावेज़ों को vectorize करके बाहर रखते समय सावधान रहें। देखें कॉर्पोरेट AI उपयोग दिशानिर्देश।
सारांश
व्यावहारिक RAG naive "काटो और vector-search करो" से विकसित होकर एक बहु-चरणीय pipeline बन गया है: "smart chunking → embedding → vector DB → hybrid search → reranking।" सटीकता में दो सबसे बड़े लाभ हैं hybrid search (BM25 + vector को RRF से मिलाना) और reranking (retrieve-then-rerank) — केवल इन दोनों को जोड़ने से "जवाब गलत है" काफी हद तक ठीक हो जाता है।
vector DBs के लिए: prototyping के लिए Chroma, यदि Postgres है तो pgvector, production के लिए Qdrant/Pinecone, hybrid-भारी के लिए Weaviate। frameworks के लिए: retrieval के लिए LlamaIndex, नियंत्रण के लिए LangChain/LangGraph। और 1M tokens पर भी, RAG प्रतिस्थापित नहीं होता — यदि आपको ताजगी, पैमाना, और उत्पत्ति चाहिए, तो वह RAG है। एक आखिरी आवश्यक बात: "पहले eval सेट बनाएं।" जिसे आप माप नहीं सकते उसे सुधार नहीं सकते। इसे ध्यान में रखें और आपका RAG "कुछ हद तक काम करता है" से "production में काम करता है" तक भरोसेमंद रूप से विकसित होगा।
संबंधित पठन: RAG क्या है (मूल बातें), context window क्या है, AI agent कैसे बनाएं, Claude Agent SDK, और MCP क्या है।
FAQ
Q. मेरी RAG सटीकता कम है। मुझे पहले क्या ठीक करना चाहिए?
A. दो चीजें — "hybrid search" और "reranking" — जोड़ना सबसे प्रभावी है। केवल साधारण vector search model नंबरों और proper nouns जैसे सटीक पदों पर कमजोर होता है, और सबसे प्रासंगिक chunks दब जाते हैं। BM25 (RRF के जरिए) + एक cross-encoder rerank से मिलाना search गुणवत्ता को व्यावहारिक स्तर तक बढ़ाता है। यदि फिर भी पर्याप्त न हो, तो अपने chunking पर फिर से विचार करें।
Q. मुझे कौन सा vector DB चुनना चाहिए?
A. prototyping के लिए Chroma, यदि आपके पास पहले से Postgres है तो pgvector आसान शुरुआत हैं। संतुलित production के लिए, Qdrant (कम latency) या Pinecone (पूरी तरह managed); भारी hybrid search के लिए, Weaviate; बहुत बड़े पैमाने के लिए, Milvus। पैमाने, ops प्राथमिकता, मौजूदा stack, और बजट के अनुसार चुनें।
Q. कौन सा chunk size अच्छा है?
A. recursive विभाजन के साथ लगभग 512 tokens एक व्यावहारिक डिफ़ॉल्ट है (2026 benchmarks में शीर्ष के पास रिपोर्ट किया गया)। technical दस्तावेज़ों के लिए, semantic (अर्थ से विभाजित); documentation/code के लिए, structural (headings/code का सम्मान); सटीकता और संदर्भ के लिए, parent-child। 512 से शुरू करें और मूल्यांकन करते हुए tune करें।
Q. 1M-token window के साथ, क्या RAG अनावश्यक नहीं है?
A. यह अनावश्यक नहीं होता। सब कुछ context में भरने से token-अकुशलता, "lost in the middle," और distraction के जरिए गुणवत्ता गिरती है। छोटे corpora और prototypes के लिए long context का उपयोग करें, और ताजगी, पैमाना, और उत्पत्ति आवश्यकताएं बनने पर RAG — यही यथार्थवादी विभाजन है।
Q. LangChain या LlamaIndex — मुझे किसका उपयोग करना चाहिए?
A. यदि आप search गुणवत्ता निखार रहे हैं तो LlamaIndex; जटिल नियंत्रण और agent समन्वय के लिए LangChain/LangGraph। व्यवहार में, कई लोग इन्हें मिलाते हैं — "retrieval layer के रूप में LlamaIndex, control layer के रूप में LangGraph।" हाल ही में Agent SDKs के साथ हल्के से जोड़ने का भी रुझान है, इसलिए अपनी आवश्यकताओं के अनुसार चुनें।
