← Resources
TUTORIAL · 2026-02-12
LangChain के बिना Production RAG Pipeline बनाएं (2026)
आप provider SDKs, pgvector, और एक reranker को directly compose करके कुछ सौ lines of code में एक production-grade RAG pipeline ship कर सकते हैं। LangChain के abstractions तब तक skip करें जब तक आपके पास एक concrete need न हो जो वो actually solve करता हो।
2026 में teams LangChain को unbundle क्यों कर रही हैं
2026 तक, production से LangChain हटाना एक पहचानने योग्य engineering pattern बन गया है, उन teams से public postmortems के साथ जो कभी इसका evangelize करती थीं। Complaint set consistent है: layered abstractions जो वो छिपाते हैं जो actually model को भेजा जाता है, minor versions के बीच frequent breaking changes, और debugging sessions जो wrapper classes के माध्यम से spelunking expeditions में बदल जाती हैं।
Underlying shift यह है कि provider SDKs अच्छे हो गए। OpenAI, Anthropic, और Google SDKs अब first-class streaming, structured outputs, tool calls, और batching ship करते हैं। Voyage, Cohere, और Jina embeddings और reranking के लिए clean REST endpoints expose करते हैं। pgvector के साथ Postgres एक dedicated vector database के बिना लगभग 10M vectors तक ANN search handle करता है।
अधिकांश RAG workloads के लिए, जो framework आप 2023 में चाहते थे वो अब चार function calls और एक SQL query है। 2026 में reasonable default है raw SDKs से शुरू करना, जब real pain महसूस हो तो एक thin pipeline abstraction add करना, और heavyweight frameworks को opt-in treat करना।
हर RAG pipeline को जिन पांच stages की ज़रूरत होती है
हर production RAG system, framework से regardless, उन्हीं पांच stages में decompose होता है। उन्हें explicitly name करने से code test और replace करना piecewise आसान हो जाता है।
- Ingest: source documents load करें, encoding normalize करें, boilerplate strip करें।
- Chunk: stable IDs और source metadata के साथ retrieval units में split करें।
- Embed and index: chunks को vector store में encode करें, hybrid search के लिए lexical index के साथ।
- Retrieve and rerank: एक wide candidate set pull करें, फिर cross-encoder reranker के साथ narrow करें।
- Generate and cite: retrieved context के साथ prompt assemble करें और source attribution के साथ answers return करें।
हर stage को typed inputs और outputs के साथ एक pure function रखें। Retrieval stage को नहीं पता होना चाहिए कि कौन सा LLM generate करेगा; generation stage को नहीं पता होना चाहिए कि कौन सा embedding model use हुआ। यही separation frameworks promise करते हैं और शायद ही deliver करते हैं, क्योंकि वे opaque chain objects के माध्यम से stages को couple करते हैं। इसे खुद लिखने में एक afternoon लगता है और upgrade risk की एक category हटा देता है।
Chunking strategies: semantic, recursive, और agentic
Chunking वो जगह है जहां अधिकांश RAG quality जीती या हारी जाती है। 2026 में तीन patterns dominate करते हैं।
Separators के hierarchy (paragraphs, sentences, फिर characters) पर recursive character splitting baseline है। यह fast, deterministic, और prose के लिए काफी अच्छा है। Semantic chunking candidate splits को embed करता है और adjacent chunks merge करता है जिनके embeddings close हैं, higher ingest cost पर topically coherent units produce करता है। Agentic chunking एक small LLM से contracts या transcripts जैसे structured documents के लिए split points propose करने को कहता है, जहां headings और turn boundaries character count से ज़्यादा मायने रखते हैं।
def recursive_chunk(text, max_chars=1200, overlap=150):
seps = ["\n\n", "\n", ". ", " "]
def split(s, depth=0):
if len(s) <= max_chars or depth == len(seps):
return [s]
parts, sep = [], seps[depth]
for p in s.split(sep):
parts.extend(split(p, depth + 1))
return parts
raw = split(text)
return [raw[i] + raw[i+1][:overlap] for i in range(len(raw)-1)] + [raw[-1]]
Recursive से शुरू करें, measure करें, फिर केवल उन document classes पर semantic पर graduate करें जहां evaluation दिखाए कि यह pay करता है।
Embeddings और rerankers: Voyage, BGE, और Cohere
2026 में retrievers का picture एक साल पहले की तुलना में स्पष्ट है। Voyage AI, अब MongoDB का हिस्सा, एक strong general-purpose dense model के रूप में voyage-3-large ship करता है और 2026 के शुरू में voyage-4 family release किया, RTEB leaderboard के top के लिए aimed एक mixture-of-experts variant के साथ। Cohere का embed-v4 दूसरा production frontrunner है। Open-weight self-hosting के लिए, BAAI का bge-m3 default बना हुआ है: एक single model 100-plus भाषाओं में dense, sparse, और multi-vector retrieval support करता है, 8192-token context के साथ।
Reranking के लिए, Cohere rerank-v3.5 workhorse है: एक multilingual model, 4096-token chunks, और typical payloads पर लगभग 80-150 ms p50 latency। Voyage rerank-2 competitive है और यदि आप पहले से Voyage embeddings use करते हैं तो cleanly integrate करता है।
Practical rule: एक dense embedder, एक reranker pick करें, और pair को interface के पीछे freeze करें। बाद में swap करना एक reindex costs करता है, rewrite नहीं।
Retrieval, generation, और citations wire करना
pgvector के साथ आपको straightforward SQL में hybrid search और citations मिलते हैं। Chunks को उनके document ID, embedding, और lexical recall के लिए एक tsvector के साथ store करें। एक wide candidate set retrieve करें, rerank करें, फिर LLM में explicit source IDs के साथ top N pass करें जिन्हें model cite करने के लिए instruct किया गया है।
import psycopg, voyageai, cohere
vo, co = voyageai.Client(), cohere.Client()
def retrieve(query, k=40, top_n=8):
qvec = vo.embed([query], model="voyage-3-large").embeddings[0]
with psycopg.connect(DSN) as conn:
rows = conn.execute(
"SELECT id, doc_id, text FROM chunks ORDER BY embedding <=> %s LIMIT %s",
(qvec, k)).fetchall()
docs = [r[2] for r in rows]
ranked = co.rerank(model="rerank-v3.5", query=query, documents=docs, top_n=top_n)
return [rows[r.index] for r in ranked.results]
```
pgvector के लिए, m=16 और ef_construction=64 के साथ HNSW index default करें, एक tenant या recency prefilter add करें ताकि ANN scan narrow शुरू हो, और हमेशा `ORDER BY embedding <=> $1` को `LIMIT` के साथ pair करें। Retrieved chunks को LLM में उनके IDs के साथ pass करें और model को citation markers emit करने के लिए instruct करें; उन markers को postprocess step में source URLs पर resolve करें।
Evaluation: hit rate, MRR, और faithfulness
Evaluation harness के बिना एक RAG pipeline एक guess है। कुछ भी tune करने से पहले harness बनाएं। Minimal kit है 100 से 500 examples का एक labeled query set जो उन question types को cover करता है जो आप actually expect करते हैं, plus तीन metrics।
K पर hit rate answer करता है कि क्या correct chunk candidate set में पहुंचा, जो retrieval quality को isolate करता है। Mean reciprocal rank capture करता है कि right chunk कितना ऊंचा rank किया, जो reranker को improve करने के लिए pay किया जाता है। Faithfulness, एक LLM judge द्वारा scored जो हर generated claim को cited chunks के against compare करने के लिए prompted है, capture करता है कि क्या model ने अपने context से आगे hallucinate किया।
हर change पर harness run करें: एक नया chunk size, एक different embedder, एक prompt edit। तीनों metrics को एक ही dashboard में time over plot करें। जब एक change MRR को improve करे लेकिन faithfulness को tank करे, तो reranker distractors surface कर रहा है और generation prompt को guardrails चाहिए, ज़्यादा retrieval tuning नहीं।
Managed orchestrator पर कब graduate करें
Hand-rolled pipelines तब तक maintainable रहती हैं जब तक एक team उन्हें own करती है और stage count small है। Managed orchestrator तब pay off करता है जब non-engineers को retrieval tune करना हो, जब आप different document classes के लिए parallel में कई pipelines run कर रहे हों, या जब आप redeploy के बिना versioned configs और A/B routing चाहते हों।
उस point पर, choice LlamaIndex या Haystack जैसे heavyweight frameworks और config-driven platforms के बीच है जो retrieval stages को declarative units के रूप में expose करते हैं। osFoundry का no-code orchestration editor osStudio दूसरा approach लेता है: ऊपर वाले पांच stages first-class config objects हैं managed Voyage embeddings और reranking के साथ एक single proxy के पीछे, ताकि आप LLM side पर BYOK रखें और retrieval side पर framework lock-in से बचें।
Useful question framework बनाम no-framework नहीं है। यह है कि क्या आपकी pipeline configuration code, config, या UI deserve करती है, और वो answer team बढ़ने पर बदलता है।
Frequently asked questions
- क्या मुझे RAG के लिए actually एक vector database चाहिए?
- शायद नहीं जब तक आप कई million vectors cross न करें। pgvector के साथ Postgres लगभग 10 million vectors तक comfortably HNSW index के साथ handle करता है, tsvector के माध्यम से hybrid search, और tenancy तथा recency के लिए standard SQL filters। आप उस database से backups, replication, और access control inherit करते हैं जो आप already operate करते हैं। Qdrant, Milvus, या Weaviate जैसे dedicated vector databases तब अपने operational cost के worth बनते हैं जब आपको sharded billion-scale indexes, बहुत high QPS पर specialized filtering, या multi-vector retrieval जैसी features चाहिए जो pgvector अभी match नहीं करता। pgvector से शुरू करें और तभी migrate करें जब एक measured bottleneck force करे।
- क्या reranker really latency के worth है?
- अधिकांश retrieval-heavy workloads के लिए, हां। Cohere rerank-v3.5 या Voyage rerank-2 जैसा एक cross-encoder reranker typically 40 से 100 chunks के candidate set पर p50 पर 80 से 200 milliseconds add करता है, और यह consistently dense retrieval alone से mean reciprocal rank को 10 से 30 percent lift करता है। Latency जो भी LLM call follow करती है उसके पीछे hidden है, जो usually user-visible budget को dominate करती है। Reranker केवल latency-critical autocomplete-style flows के लिए skip करें जो end to end 200 milliseconds के नीचे हैं, या जब आपका candidate set already इतना छोटा है कि dense ranking reliable है।
- मैं storage bloat किए बिना chunk overlap कैसे handle करूं?
- 10 से 15 percent chunk size के small overlaps use करें, duplicated text के बजाय source document में character offsets के रूप में stored। Retrieval time पर आप optionally context expansion के लिए neighboring chunk fetch कर सकते हैं। यह index lean रखता है और embedding के दौरान एक ही tokens के लिए दो बार pay करने से बचाता है। यदि आपको generation के लिए richer context चाहिए, तो parent-document pattern अच्छा काम करता है: retrieval precision के लिए small chunks index करें, फिर LLM को pass करने से पहले hits को उनकी parent section पर resolve करें। Parent lookup एक single indexed query है और negligible latency add करता है।
- RAG quality evaluate करने का सबसे simple तरीका क्या है?
- 100 से 200 representative queries का एक labeled set बनाएं उन chunk IDs के साथ जो retrieve होने चाहिए। केवल retrieval stage से K पर hit rate और mean reciprocal rank compute करें, जो retriever quality को generation noise से isolate करता है। Faithfulness के लिए, एक LLM judge use करें जो हर generated claim को cited chunks के against compare करने और grounded versus unsupported score करने के लिए prompted है। हर meaningful change पर तीनों numbers run करें और regressions को blockers treat करें। यह three-metric setup practice में अधिकांश RAG regressions catch करता है और एक number को optimize करते हुए चुपके से दूसरे को hurt करने के trap से बचाता है।
Sources