50 लाख से अधिक दस्तावेज़ प्रोसेस करते हुए मिला Production RAG का अनुभव

• 8 महीनों तक RAG (Retrieval-Augmented Generation) प्रोजेक्ट चलाते हुए यह स्पष्ट हुआ कि कौन-से तरीके वास्तव में असरदार थे और कौन-से समय की बर्बादी साबित हुए
• शुरुआत में Langchain और Llamaindex का उपयोग करके प्रोटोटाइप जल्दी तैयार किया गया, लेकिन वास्तविक यूज़र फीडबैक में परफॉर्मेंस की सीमाएँ सामने आईं
• दस्तावेज़ खोज परफॉर्मेंस को बेहतर बनाने वाले सबसे बड़े कारक query generation, reranking, chunking strategy, metadata का उपयोग, query routing पाए गए
• प्रैक्टिकल काम में vector database, embedding, reranking, LLM आदि को लचीले ढंग से चुनते हुए एक custom pipeline बनाई गई
• सभी अनुभव और सीख को open source project(agentset-ai/agentset) में समेटकर सार्वजनिक किया गया

---

8 महीनों के Production RAG निर्माण अनुभव का सार

• कुल 90 लाख पेज (Usul AI), 40 लाख पेज (एक गुमनाम legal AI कंपनी) जैसे बड़े datasets पर RAG सिस्टम बनाकर और ऑपरेट करके हासिल अनुभव साझा किया गया
• शुरुआत में YouTube tutorials को फॉलो करते हुए Langchain से Llamaindex पर जाते-जाते कुछ ही दिनों में प्रोटोटाइप तैयार हो गया, लेकिन वास्तविक deployment में ऐसी कम परफॉर्मेंस दिखी जिसे केवल यूज़र ही महसूस कर सकते थे
• कई महीनों तक सिस्टम के अलग-अलग components को आंशिक रूप से सुधारते हुए अंततः बेहतरतम परफॉर्मेंस तक पहुँचा गया

परफॉर्मेंस सुधार में वास्तव में योगदान देने वाले तत्व (ROI क्रम में)

1. Query Generation

   • यूज़र की आख़िरी query में पूरा context नहीं समा पाता, इसलिए LLM से बातचीत की समीक्षा कराकर कई semantic queries और keyword queries तैयार की गईं
   • इन queries को parallel में प्रोसेस करके reranker को दिया गया, जिससे search coverage बढ़ी और hybrid search के bias की भरपाई हुई

2. Reranking

   • लगभग 5 लाइनों के code से लागू होने वाला reranking परफॉर्मेंस पर जितना असर डालता है, वह कल्पना से कहीं अधिक है
   • बड़ी संख्या में chunks (जैसे 50) इनपुट करने पर उनमें से ऊपर के कुछ chunks (जैसे 15) को फिर से क्रमबद्ध और चयनित करने की प्रक्रिया का ROI सबसे अधिक रहा
   • केवल reranking से भी कमजोर डिज़ाइन वाली pipeline की कई कमियाँ काफी हद तक संतुलित की जा सकती हैं

3. Chunking Strategy

   • पूरे development process का सबसे अधिक समय लेने वाला हिस्सा
   • डेटा की संरचना और पैटर्न को सही तरह समझना, logical units में chunking करना, और यह सुनिश्चित करने के लिए मैन्युअल जाँच करना कि अक्षर या वाक्य बीच में न कटें आवश्यक है
   • हर chunk का स्वतंत्र अर्थ बना रहना चाहिए

4. LLM इनपुट में metadata का उपयोग

   • केवल chunk text ही LLM को देने के बजाय, metadata (title, author आदि) जोड़ने से context और answer quality में बड़ा सुधार हुआ

5. Query Routing

   • जिन प्रकार के सवालों का जवाब RAG से देना संभव नहीं था (जैसे article summary, author information request आदि), उनके लिए एक lightweight router जोड़ा गया, जो ऐसी queries को API+LLM processing path की ओर भेजता है

प्रैक्टिकल स्टैक (Our stack)

• Vector database: Azure → Pinecone → Turbopuffer (कम लागत, और डिफ़ॉल्ट रूप से keyword search सपोर्ट)
• Document extraction: custom तरीका अपनाया गया
• Chunking tool: डिफ़ॉल्ट रूप से Unstructured.io, enterprise pipeline के लिए custom (Chonkie के बारे में भी अच्छी राय)
• Embedding model: text-embedding-large-3 उपयोग किया गया (अन्य models का परीक्षण नहीं)
• Reranker: None → Cohere 3.5 → Zerank (ज़्यादा लोकप्रिय नहीं, लेकिन व्यवहार में उत्कृष्ट)
• LLM: GPT 4.1 → GPT 5 → GPT 4.1 (मुख्यतः Azure credits का उपयोग)

Open source और निष्कर्ष

• सभी सीख और वास्तविक अनुभवों का निष्कर्ष open source projectagentset-ai/agentset के रूप में सामने आया
• MIT license के तहत सार्वजनिक, इसलिए स्वतंत्र रूप से उपयोग और संपर्क संभव

[GN⁺]

Hacker News राय

• synthetic query generation के बारे में की गई बात सच में बहुत महत्वपूर्ण लगती है। असल उपयोगकर्ता अक्सर queries बहुत गलत या अस्पष्ट तरीके से डालते हैं, इसलिए शुरुआत में LLM synthetic queries बनाता था। लेकिन हर बार बनने वाली synthetic query के हिसाब से परिणामों में काफ़ी उतार-चढ़ाव आता था, इसलिए एक ही LLM call में query के तीन अलग-अलग versions विविध रूप में बनवाकर, उन्हें parallel search के बाद reciprocal rank fusion से जोड़कर मज़बूत result list तैयार की जाती है। Search के लिए hybrid dense + sparse bm25 का उपयोग होता है। सिर्फ dense approach technical terms में कमज़ोर पड़ती है। इसमें reranker भी जोड़ दिया जाए तो search से जुड़ी ज़्यादातर समस्याएँ हल हो जाती हैं
  • dense model की technical terminology में कमज़ोरी को पूरा करने के लिए hybrid approach (bm25 + dense search) का इस्तेमाल दिलचस्प लगा। SPLADE जैसे semantic और lexical search का अच्छा संतुलन रखने वाले v3 models प्रदर्शन में अच्छे दिखते हैं, लेकिन क्या इन्हें किसी और सरल solution से बदला जा सकता है, यह जिज्ञासा हमेशा रहती है
  • इस बात पर ज़ोर दिया गया कि ऐसी बारीक query generation/optimization आखिरकार Amazon, Microsoft, OpenAI जैसे RAG solution providers को ही संभालनी चाहिए
  • ये तरीके फिलहाल best practices ज़रूर हैं, लेकिन performance को एक स्तर और ऊपर ले जाने वाली अतिरिक्त strategies, जैसे embedding model का selective branching या कई re-ranker combinations, इनमें अभी भी कुछ कमी-सी महसूस होती है
  • आख़िरी tip के रूप में सुझाव दिया गया कि LLM ने उपयोगकर्ता की search intent को कैसे समझा, यह परिणामों के साथ उपयोगकर्ता को भी दिखाना चाहिए, ताकि उपयोगकर्ता ख़ुद जाँच सके कि LLM की समझ सही है या नहीं
• self-hosted option को लेकर उलझन महसूस हुई। संबंधित documents में कहा गया है कि कम-से-कम 6 third-party service accounts चाहिए, और यह self-hosted के असली मतलब से काफ़ी अलग लगता है
  • समझाया गया कि उस code को ख़ुद self-host किया जा सकता है। “self-hosted” शब्द के लिए कोई साफ़ आधिकारिक मानक नहीं है। उदाहरण के लिए, अगर किसी self-hosted service में offsite backup feature भी हो, तो वह self-hosted होने के साथ-साथ बस एक अच्छी तरह डिज़ाइन की गई service भी है
  • इस तरह की self-hosted marketing स्वाभाविक भी हो सकती है, लेकिन चूँकि कंपनी का मूल business model hosted version बेचना है, इसलिए पूरी तरह standalone self-hosted product देना उनके लिए अनिवार्य नहीं है
  • सीमित network environment में काम करने का अनुभव साझा किया गया। पिछले 20 सालों से पूरी तरह बंद internal network environment में काम करने के कारण संभव है कि नई technology waves काफ़ी छूट गई हों। YouTube भी कार मरम्मत के अलावा शायद ही देखते हैं, और online connectivity पर निर्भर technology trends को लेकर कुछ हद तक अनिच्छुक हैं
  • वे open source version का बहुत संतोषजनक उपयोग कर रहे हैं। अगर hosted dependency नहीं चाहिए, तो सब कुछ सीधे Rust में ख़ुद लिख लेने की व्यावहारिक राय दी गई
• बड़े LLM-आधारित rerankers (Qwen3-reranker आदि) अब वह performance दिखा रहे हैं जो पहले से cross-encoder में चाही जाती थी, इसलिए इन्हें ज़रूर आज़माने की सिफ़ारिश की गई। हालाँकि इनकी compute cost काफ़ी ज़्यादा है। साथ ही metadata/table information इंसानों के लिए बहुत बुनियादी और स्पष्ट जानकारी होती है, लेकिन text chunks में यह बार-बार दोहराई नहीं जाती। इसलिए इसे LLM input में inject कर दिया जाए तो सिस्टम काफ़ी ज़्यादा “smart” लगता है। सिर्फ simple RAG से अच्छी तरह न संभलने वाली complex queries, जैसे हाल की 20 documents का summary, पर सावधानी चाहिए। इसलिए हमने UI को search पर केंद्रित रखा, chat UX को कम किया, और मॉडल वास्तव में जो जानकारी देखता है वही उपयोगकर्ता को भी दिखाया
  • उपयोगकर्ता के नज़रिए से LLM की context processing संरचना को सही ढंग से समझाना बहुत कठिन है—इस राय से पूरी तरह सहमति जताई गई। chat UX से हटकर public examples कम ही दिखते हैं, और बड़े संगठनों ने कोशिश करके इसे छोड़ा तो क्या सच में “परिणाम नहीं मिले” इसलिए छोड़ा, इस पर भी संदेह है। वास्तव में बड़े consumer apps में context/reasoning cost एक प्रमुख खर्च होती है, इसलिए शायद context-explicit UI को नज़रअंदाज़ किया गया। दूसरी ओर, internal RAG systems में cost pressure कम होता है, इसलिए वहाँ output quality और कर्मचारियों के समय की बचत पर कहीं ज़्यादा ध्यान दिया जाता है—ऐसा अनुभव से महसूस हुआ
  • technical optimization महत्वपूर्ण है, लेकिन वास्तविक ग्राहकों की work efficiency कितनी बेहतर हुई, इसके और वास्तविक use cases जानने की इच्छा है। नहीं तो यह बस एक और तकनीकी trend बनकर रह जाएगा
• लाखों pages, ख़ासकर technical materials, पर RAG processing के बारे में डेढ़ साल पहले लिखा गया एक summary post साझा किया गया https://jakobs.dev/learnings-ingesting-millions-pages-rag-azure/
  • technical search के लिए RAG system पिछले साल भी बनाया था, और अब देखकर लगता है कि कई हिस्से लगभग वैसे ही हैं
• इस तरह के RAG system को बनाना या अपनाना चाहने वाले के नज़रिए से जिज्ञासा है कि क्या documents को Google Workspace folder में API के ज़रिए upload करके, Google AI search API से document search करना एक व्यावहारिक architecture हो सकता है—जैसे हर उपयोगकर्ता के लिए अलग folder रखना। या Azure में भी कुछ ऐसा ही बनाया जा सकता है या नहीं, इस पर विचार है
• embedding version management कैसे किया जाए, इस पर सवाल है। data updates, किसी specific version को expose करना, या date के हिसाब से filtering करनी हो तो कैसे करें—यह पूछा गया, और chunk के आगे context version जोड़ने का विचार भी रखा गया
  • vector store में original text और metadata, जिसमें version information भी शामिल हो, साथ में store कर देना चाहिए। उदाहरण के लिए, turbopuffer में attribute filtering सुविधाजनक है—यह बताते हुए दस्तावेज़ लिंक साझा किया गया
  • यह सवाल अपने-आप में काफ़ी उपयोगी और महत्वपूर्ण लगा
• यह अजीब लगा कि LLM versions का उपयोग क्रम GPT 4.1 → GPT 5 → फिर वापस GPT 4.1 क्यों रहा, और stack के दूसरे components के versions, जैसे text-embedding-large-3, के साथ यह mismatch भी असामान्य लगा
  • OP का जवाब: GPT-5 रिलीज़ होते ही इस्तेमाल किया था, लेकिन बहुत बड़े context, अधिकतम 100k tokens, के input में यह GPT-4.1 से कमज़ोर निकला, इसलिए फिर 4.1 पर लौटना पड़ा। विशेष रूप से a) instruction following कमज़ोर थी और system prompt को ठीक से follow नहीं करता था, b) जवाब बहुत verbose हो जाते थे जिससे UX काफ़ी बिगड़ता था, c) 125k token context window limit के कारण बहुत बड़े inputs error दे देते थे। ये समस्याएँ “RAG” में बहुत सारे chunks देने पर विशेष रूप से उभरती थीं, जबकि सामान्य tasks में GPT-5 बेहतर भी हो सकता है
• मैं AWS का समर्थक नहीं हूँ, लेकिन S3 Vectors इस क्षेत्र में अभी state-of-the-art है—इस पर ज़ोर दिया गया। अगर इसके साथ Bedrock Knowledge Base भी जोड़ दिया जाए, तो Discovery/Rebalance भी आसान हो जाएगा, और यह बाज़ार का सबसे सरल solution बन सकता है। औपचारिक release के बाद यह ज़्यादातर competitors को पीछे छोड़ देगा—ऐसा माना गया
  • मज़ाक में सुधार किया गया कि सही शब्द “schlep” नहीं बल्कि “shill” है
  • सवाल उठाया गया कि S3 Vectors को SOTA क्यों कहा जा रहा है—आख़िर वह भी एक vector store ही तो है, है न?
• embedding-आधारित RAG वास्तव में हमेशा सबसे अच्छा तरीका नहीं है। single-task या demo के लिए यह अच्छा है, लेकिन वास्तविक परिस्थितियों में इसकी सीमाएँ अक्सर सामने आती हैं
  • अनुभव से यह भी लगा कि बात हमेशा ऐसी नहीं होती। मैंने जिस Honeycomb product Query Assistant ब्लॉग पर काम किया, वह भी 2023 से data query पर आधारित था, और क्योंकि यह feature बहुत सरल उद्देश्य के लिए डिज़ाइन किया गया था, इसलिए यह LLM-based products की आदर्श दिशा जैसा लगा। non-LLM processing के साथ इसका संयोजन अच्छा रहता है
  • rag को लगातार नए तरीक़े से परिभाषित किया जा रहा है और इसके उपयोग भी कई हैं। हमने rag को agentic search के लिए एक tool की तरह integrate किया, साथ ही real-time source search और पारंपरिक chunk-based approach को भी मिलाया। आने वाली बड़ी context windows की वजह से भविष्य में एक ही request में पूरा document डालना भी संभव हो सकता है
  • पूछा गया कि वे किस alternative की सिफ़ारिश कर रहे हैं—क्या वे query generation approach की बात कर रहे हैं?
  • ChatGPT भी RAG के आधार पर ताज़ा जानकारी पाने में प्रभावी है। इसी व्यावहारिक उपयोगिता की वजह से आज सभी बड़े providers इसे दे रहे हैं—यह बात रेखांकित की गई
  • स्पष्ट रूप से पूछा गया कि तुलना किस चीज़ से की जा रही है
• कहा गया कि chunk selection strategy पर बहुत समय और मेहनत लगी, इसलिए इस्तेमाल की गई ठोस strategies के बारे में और विस्तार से सुनना चाहेंगे