RAG-संचालित दस्तावेज़ सहायक का निर्माण (चंकिंग, एम्बेडिंग्स, और खोज)

आपको क्या मिलेगा

मैंने एक RAG-संचालित दस्तावेज़ सहायक बनाया है और इसे एक बॉयलरप्लेट में पैकेज किया है जिसे आप तुरंत उपयोग कर सकते हैं।

• एक तैयार-से-उपयोग एप्लिकेशन के साथ आता है (Next.js + OpenAI API)
• एक कार्यशील RAG पाइपलाइन शामिल है (चंकिंग, एम्बेडिंग्स, कोसाइन समानता)
• React में निर्मित एक पूर्ण चैटबॉट UI प्रदान करता है
• सभी UI घटक Tailwind CSS के साथ पूरी तरह से संपादन योग्य हैं
• हर उपयोगकर्ता क्वेरी को लॉग करता है ताकि गायब दस्तावेज़, उपयोगकर्ता की समस्याओं, और उत्पाद के अवसरों की पहचान की जा सके

👉 लाइव डेमो 👉 कोड बॉयलरप्लेट

परिचय

यदि आप कभी दस्तावेज़ में खो गए हैं, एक उत्तर के लिए अंतहीन स्क्रॉलिंग करते हुए, तो आप जानते हैं कि यह कितना दर्दनाक हो सकता है। दस्तावेज़ उपयोगी होते हैं, लेकिन वे स्थिर होते हैं और उनमें खोज करना अक्सर जटिल लगता है।

यहीं पर RAG (रिट्रीवल-ऑगमेंटेड जनरेशन) आता है। उपयोगकर्ताओं को टेक्स्ट के माध्यम से खुदाई करने के लिए मजबूर करने के बजाय, हम रिट्रीवल (दस्तावेज़ के सही हिस्सों को खोजने) को जनरेशन (एक LLM को इसे स्वाभाविक रूप से समझाने देना) के साथ जोड़ सकते हैं।

इस पोस्ट में, मैं आपको बताऊंगा कि मैंने कैसे एक RAG-संचालित दस्तावेज़ चैटबोट बनाया और यह न केवल उपयोगकर्ताओं को तेज़ी से उत्तर खोजने में मदद करता है, बल्कि उत्पाद टीमों को उपयोगकर्ता की समस्याओं को समझने का एक नया तरीका भी देता है।

दस्तावेज़ के लिए RAG क्यों उपयोग करें?

RAG एक लोकप्रिय दृष्टिकोण बन गया है और इसके पीछे एक कारण है: यह बड़े भाषा मॉडल को वास्तव में उपयोगी बनाने के सबसे व्यावहारिक तरीकों में से एक है।

दस्तावेज़ के लिए, इसके लाभ स्पष्ट हैं:

• त्वरित उत्तर: उपयोगकर्ता प्राकृतिक भाषा में पूछते हैं, और प्रासंगिक उत्तर प्राप्त करते हैं।
• बेहतर संदर्भ: मॉडल केवल सबसे प्रासंगिक दस्तावेज़ अनुभागों को देखता है, जिससे भ्रम की संभावना कम होती है।
• खोज जो मानव जैसी लगती है: यह अधिकतर Algolia + FAQ + चैटबोट का संयोजन है।
• प्रतिक्रिया चक्र: क्वेरी संग्रहित करके, आप पता लगाते हैं कि उपयोगकर्ता वास्तव में किन समस्याओं का सामना कर रहे हैं।

वह आखिरी बिंदु बहुत महत्वपूर्ण है। एक RAG सिस्टम केवल सवालों के जवाब नहीं देता, यह आपको बताता है कि लोग क्या पूछ रहे हैं। इसका मतलब है:

• आप अपनी दस्तावेज़ में गायब जानकारी का पता लगाते हैं।
• आप फीचर अनुरोधों को उभरते हुए देखते हैं।
• आप ऐसे पैटर्न पहचानते हैं जो उत्पाद रणनीति को भी मार्गदर्शन कर सकते हैं।

तो, RAG केवल एक सहायता उपकरण नहीं है। यह एक उत्पाद खोज इंजन भी है।

RAG पाइपलाइन कैसे काम करती है

उच्च स्तर पर, यहाँ वह विधि है जिसका मैंने उपयोग किया:

1. दस्तावेज़ को टुकड़ों में बांटना बड़े Markdown फ़ाइलों को टुकड़ों में विभाजित किया जाता है। टुकड़ों में बांटने से केवल प्रासंगिक दस्तावेज़ भागों को संदर्भ के रूप में प्रदान करना संभव होता है।
2. एम्बेडिंग्स बनाना प्रत्येक टुकड़े को OpenAI के एम्बेडिंग API (text-embedding-3-large) या एक वेक्टर डेटाबेस (Chroma, Qdrant, Pinecone) का उपयोग करके वेक्टर में बदला जाता है।
3. इंडेक्सिंग और संग्रहण एम्बेडिंग्स को एक सरल JSON फ़ाइल में संग्रहित किया जाता है (मेरे डेमो के लिए), लेकिन उत्पादन में, आप संभवतः एक वेक्टर DB का उपयोग करेंगे।
4. रिकवरी (RAG में R) एक उपयोगकर्ता क्वेरी को एम्बेड किया जाता है, कोसाइन समानता की गणना की जाती है, और शीर्ष मेल खाने वाले टुकड़े पुनः प्राप्त किए जाते हैं।
5. ऑगमेंटेशन + जनरेशन (RAG में AG) उन टुकड़ों को ChatGPT के प्रॉम्प्ट में डाला जाता है, ताकि मॉडल वास्तविक दस्तावेज़ संदर्भ के साथ उत्तर दे सके।
6. प्रतिक्रिया के लिए क्वेरी लॉगिंग हर उपयोगकर्ता क्वेरी को संग्रहित किया जाता है। यह दर्द बिंदुओं, गायब दस्तावेज़ों, या नए अवसरों को समझने के लिए सोना है।

1. 1

   दस्तावेज़ पढ़ना

   पहला चरण सरल था: मुझे docs/ फ़ोल्डर में सभी .md फ़ाइलों को स्कैन करने का एक तरीका चाहिए था। Node.js और glob का उपयोग करके, मैंने प्रत्येक Markdown फ़ाइल की सामग्री को मेमोरी में लाया।

   यह पाइपलाइन को लचीला बनाए रखता है: Markdown के बजाय, आप दस्तावेज़ों को डेटाबेस, CMS, या यहां तक कि API से भी प्राप्त कर सकते हैं।

2. 2

   दस्तावेज़ों को टुकड़ों में विभाजित करना

   टुकड़ों में क्यों बांटना? क्योंकि भाषा मॉडल के पास संदर्भ सीमाएं होती हैं। उन्हें पूरे दस्तावेज़ की किताब खिलाना काम नहीं करेगा।

   इसलिए विचार यह है कि टेक्स्ट को प्रबंधनीय टुकड़ों (जैसे प्रत्येक 500 टोकन) में विभाजित किया जाए, जिसमें ओवरलैप (जैसे 100 टोकन) हो। ओवरलैप निरंतरता सुनिश्चित करता है ताकि आप टुकड़ों की सीमाओं पर अर्थ न खोएं।

   उदाहरण:

   • टुकड़ा 1 → “…पुरानी लाइब्रेरी जिसे कई लोग भूल चुके थे। इसकी ऊंची शेल्फ़ किताबों से भरी हुई थीं…”
   • टुकड़ा 2 → “…शेल्फ़ हर कल्पनीय शैली की किताबों से भरे हुए थे, प्रत्येक अपनी कहानियां फुसफुसा रहा था…”

   ओवरलैप सुनिश्चित करता है कि दोनों टुकड़ों में साझा संदर्भ हो, जिससे पुनः प्राप्ति सुसंगत बनी रहे।

   यह समझौता (टुकड़े का आकार बनाम ओवरलैप) RAG की दक्षता के लिए महत्वपूर्ण है:

   • बहुत छोटा → आपको शोर मिलेगा।
   • बहुत बड़ा → आप संदर्भ आकार को बढ़ा देते हैं।
3. 3

   एम्बेडिंग्स जनरेट करना

   एक बार जब दस्तावेज़ों को टुकड़ों में बांट दिया जाता है, तो हम एम्बेडिंग्स बनाते हैं, उच्च-आयामी वेक्टर जो प्रत्येक टुकड़े का प्रतिनिधित्व करते हैं।

   मैंने OpenAI के text-embedding-3-large मॉडल का उपयोग किया, लेकिन आप कोई भी आधुनिक एम्बेडिंग मॉडल उपयोग कर सकते हैं।

   उदाहरण एम्बेडिंग:

   js

   सामग्री कॉपी करें

   कोड कॉपी करें

   कोड को क्लिपबोर्ड पर कॉपी करें

   [
     -0.0002630692, -0.029749284, 0.010225477, -0.009224428, -0.0065269712,
     -0.002665544, 0.003214777, 0.04235309, -0.033162255, -0.00080789323,
     //...+1533 elements
   ];
   

   प्रत्येक वेक्टर टेक्स्ट की एक गणितीय फिंगरप्रिंट है, जो समानता खोज को सक्षम बनाता है।

4. 4

   एम्बेडिंग्स का इंडेक्सिंग और संग्रहण

   बार-बार एम्बेडिंग्स को पुनः उत्पन्न करने से बचने के लिए, मैंने उन्हें embeddings.json में संग्रहित किया।

   उत्पादन में, आप संभवतः निम्नलिखित जैसे वेक्टर डेटाबेस चाहते होंगे:

   • Chroma
   • Qdrant
   • Pinecone
   • FAISS, Weaviate, Milvus, आदि।

   वेक्टर डेटाबेस इंडेक्सिंग, स्केलेबिलिटी, और तेज़ खोज को संभालते हैं। लेकिन मेरे प्रोटोटाइप के लिए, एक स्थानीय JSON ठीक काम करता था।

5. 5

   कोसाइन सिमिलैरिटी के साथ पुनःप्राप्ति

   जब कोई उपयोगकर्ता प्रश्न पूछता है:

   1. क्वेरी के लिए एक एम्बेडिंग जनरेट करें।
   2. इसे सभी दस्तावेज़ एम्बेडिंग्स के साथ कोसाइन सिमिलैरिटी का उपयोग करके तुलना करें।
   3. केवल शीर्ष N सबसे समान टुकड़ों को रखें।

   कोसाइन सिमिलैरिटी दो वेक्टरों के बीच कोण को मापती है। एक पूर्ण मेल का स्कोर 1.0 होता है।

   इस तरह, सिस्टम क्वेरी के सबसे निकट दस्तावेज़ अंश खोजता है।

6. 6

   संवर्धन + जनरेशन

   अब जादू आता है। हम शीर्ष टुकड़ों को लेते हैं और उन्हें ChatGPT के सिस्टम प्रॉम्प्ट में इंजेक्ट करते हैं।

   इसका मतलब है कि मॉडल ऐसे जवाब देता है जैसे वे चंक्स बातचीत का हिस्सा हों।

   परिणाम: सटीक, दस्तावेज़-आधारित उत्तर।

7. 7

   उपयोगकर्ता प्रश्नों का लॉगिंग

   यह छुपी हुई सुपरपावर है।

   पूछे गए हर प्रश्न को संग्रहीत किया जाता है। समय के साथ, आप एक डेटासेट बनाते हैं जिसमें शामिल हैं:

   • सबसे अधिक पूछे जाने वाले प्रश्न (FAQs के लिए बेहतरीन)
   • अनुत्तरित प्रश्न (दस्तावेज़ गायब हैं या अस्पष्ट हैं)
   • प्रश्न के रूप में छिपे फीचर अनुरोध (“क्या यह X के साथ एकीकृत होता है?”)
   • उभरते हुए उपयोग के मामले जिनकी आपने योजना नहीं बनाई थी

   यह आपके RAG सहायक को एक लगातार उपयोगकर्ता अनुसंधान उपकरण में बदल देता है।

8. 8

   इसकी लागत क्या है?

   RAG के लिए एक सामान्य आपत्ति लागत है। व्यवहार में, यह आश्चर्यजनक रूप से सस्ता है:

   • लगभग 200 दस्तावेज़ों के लिए एम्बेडिंग जनरेट करने में लगभग 5 मिनट लगते हैं और इसकी लागत 1–2 यूरो होती है।
   • दस्तावेज़ खोजने की सुविधा 100% मुफ्त है।
   • क्वेरीज़ के लिए, हम "थिंकिंग" मोड के बिना gpt-4o-latest का उपयोग करते हैं। Intlayer पर, हम प्रति माह लगभग 300 चैट क्वेरीज़ देखते हैं, और OpenAI API बिल शायद ही कभी $10 से अधिक होता है।

   इसके ऊपर, आप होस्टिंग लागत भी शामिल कर सकते हैं।

9. 9

   कार्यान्वयन विवरण

   स्टैक:

   • मोनोरेपो: pnpm वर्कस्पेस
   • डॉक पैकेज: Node.js / TypeScript / OpenAI API
   • फ्रंटेंड: Next.js / React / Tailwind CSS
   • बैकेंड: Node.js API रूट / OpenAI API

   @smart-doc/docs पैकेज एक TypeScript पैकेज है जो दस्तावेज़ प्रसंस्करण को संभालता है। जब कोई मार्कडाउन फ़ाइल जोड़ी या संशोधित की जाती है, तो पैकेज में एक build स्क्रिप्ट शामिल होती है जो प्रत्येक भाषा में दस्तावेज़ सूची को पुनर्निर्मित करता है, एम्बेडिंग्स उत्पन्न करता है, और उन्हें embeddings.json फ़ाइल में संग्रहीत करता है।

   फ्रंटेंड के लिए, हम एक Next.js एप्लिकेशन का उपयोग करते हैं जो प्रदान करता है:

   • मार्कडाउन को HTML में रेंडर करना
   • प्रासंगिक दस्तावेज़ खोजने के लिए एक खोज बार
   • दस्तावेज़ों के बारे में प्रश्न पूछने के लिए एक चैटबॉट इंटरफ़ेस

   दस्तावेज़ खोज करने के लिए, Next.js एप्लिकेशन में एक API रूट शामिल है जो @smart-doc/docs पैकेज में एक फ़ंक्शन को कॉल करता है ताकि क्वेरी से मेल खाने वाले डॉक चंक्स प्राप्त किए जा सकें। इन चंक्स का उपयोग करके, हम उपयोगकर्ता की खोज से संबंधित दस्तावेज़ पृष्ठों की एक सूची वापस कर सकते हैं।

   चैटबॉट कार्यक्षमता के लिए, हम समान खोज प्रक्रिया का पालन करते हैं लेकिन अतिरिक्त रूप से प्राप्त डॉक चंक्स को ChatGPT को भेजे गए प्रॉम्प्ट में इंजेक्ट करते हैं।

   यहाँ ChatGPT को भेजे गए प्रॉम्प्ट का एक उदाहरण है:

   सिस्टम प्रॉम्प्ट :

   txt

   सामग्री कॉपी करें

   कोड कॉपी करें

   कोड को क्लिपबोर्ड पर कॉपी करें

   आप एक सहायक सहायक हैं जो Intlayer दस्तावेज़ के बारे में प्रश्नों का उत्तर दे सकता है।
   
   संबंधित चंक्स :
   
   -----
   docName: "getting-started"
   docChunk: "1/3"
   docUrl: "https://example.com/docs/hi/getting-started"
   ---
   
   # कैसे शुरू करें
   
   ...
   
   -----
   docName: "another-doc"
   docChunk: "1/5"
   docUrl: "https://example.com/docs/hi/another-doc"
   ---
   
   # एक और दस्तावेज़
   
   ...
   

   उपयोगकर्ता क्वेरी :

   txt

   सामग्री कॉपी करें

   कोड कॉपी करें

   कोड को क्लिपबोर्ड पर कॉपी करें

   कैसे शुरू करें?
   

   हम API रूट से प्रतिक्रिया को स्ट्रीम करने के लिए SSE का उपयोग करते हैं।

   जैसा कि उल्लेख किया गया है, हम "थिंकिंग" मोड के बिना gpt-4-turbo का उपयोग करते हैं। प्रतिक्रियाएँ प्रासंगिक होती हैं, और विलंबता कम होती है। हमने gpt-5 के साथ प्रयोग किया, लेकिन विलंबता बहुत अधिक थी (कभी-कभी उत्तर के लिए 15 सेकंड तक)। लेकिन हम भविष्य में इसे फिर से देखेंगे।

   👉 यहाँ डेमो आज़माएँ 👉 GitHub पर कोड टेम्पलेट देखें

10. 10

    आगे बढ़ना

    यह परियोजना एक न्यूनतम कार्यान्वयन है। लेकिन आप इसे कई तरीकों से बढ़ा सकते हैं:

    • MCP सर्वर → डॉक्यूमेंटेशन को किसी भी AI असिस्टेंट से कनेक्ट करने के लिए डॉक रिसर्च फ़ंक्शन को MCP सर्वर में बदलना

    • वेक्टर DBs → लाखों डॉक चंक्स तक स्केल करना
    • LangChain / LlamaIndex → RAG पाइपलाइनों के लिए रेडी-मेड फ्रेमवर्क
    • एनालिटिक्स डैशबोर्ड → उपयोगकर्ता क्वेरी और समस्याओं को विज़ुअलाइज़ करना
    • मल्टी-सोर्स रिट्रीवल → केवल डॉक नहीं, बल्कि डेटाबेस एंट्री, ब्लॉग पोस्ट, टिकट आदि भी खींचना
    • बेहतर प्रॉम्प्टिंग → रीरैंकिंग, फ़िल्टरिंग, और हाइब्रिड सर्च (कीवर्ड + सेमांटिक)
11. 11

    सीमाएँ जिनका सामना करना पड़ा

    • चंकिन्ग और ओवरलैप अनुभवजन्य हैं। सही संतुलन (चंक साइज, ओवरलैप प्रतिशत, प्राप्त किए गए चंक्स की संख्या) के लिए पुनरावृत्ति और परीक्षण आवश्यक है।
    • जब डॉक बदलते हैं तो एम्बेडिंग्स स्वचालित रूप से पुनः उत्पन्न नहीं होती हैं। हमारा सिस्टम केवल तभी फाइल के लिए एम्बेडिंग्स रीसेट करता है जब चंक्स की संख्या संग्रहीत संख्या से भिन्न होती है।
    • इस प्रोटोटाइप में, एम्बेडिंग्स JSON में संग्रहीत की जाती हैं। यह डेमो के लिए काम करता है लेकिन Git को प्रदूषित करता है। उत्पादन में, एक डेटाबेस या समर्पित वेक्टर स्टोर बेहतर होता है।
12. 12

    यह दस्तावेज़ों से परे क्यों महत्वपूर्ण है

    दिलचस्प हिस्सा केवल चैटबॉट नहीं है। यह फीडबैक लूप है।

    RAG के साथ, आप केवल उत्तर नहीं देते:

    • आप सीखते हैं कि उपयोगकर्ताओं को क्या भ्रमित करता है।
    • आप पता लगाते हैं कि वे कौन-से फीचर्स की उम्मीद करते हैं।
    • आप वास्तविक प्रश्नों के आधार पर अपनी उत्पाद रणनीति को अनुकूलित करते हैं।

    उदाहरण:

    कल्पना करें कि आप एक नया फीचर लॉन्च करते हैं और तुरंत देखते हैं:

    • 50% प्रश्न एक ही अस्पष्ट सेटअप चरण के बारे में हैं
    • उपयोगकर्ता बार-बार एक ऐसे इंटीग्रेशन के लिए पूछते हैं जिसे आप अभी तक सपोर्ट नहीं करते
    • लोग ऐसे शब्द खोजते हैं जो एक नए उपयोग मामले को प्रकट करते हैं

    यह है आपके उपयोगकर्ताओं से सीधे उत्पाद बुद्धिमत्ता।

13. 13

    निष्कर्ष

    RAG LLMs को व्यावहारिक बनाने के सबसे सरल और सबसे शक्तिशाली तरीकों में से एक है। रिकवरी + जनरेशन को मिलाकर, आप स्थिर दस्तावेज़ों को एक स्मार्ट असिस्टेंट में बदल सकते हैं और साथ ही, उत्पाद अंतर्दृष्टि की एक निरंतर धारा प्राप्त कर सकते हैं।

    मेरे लिए, इस परियोजना ने दिखाया कि RAG केवल एक तकनीकी चाल नहीं है। यह दस्तावेज़ीकरण को बदलने का एक तरीका है:

    • एक इंटरैक्टिव समर्थन प्रणाली
    • एक प्रतिक्रिया चैनल
    • एक उत्पाद रणनीति उपकरण

    👉 यहाँ डेमो आज़माएँ 👉 GitHub पर कोड टेम्पलेट देखें

    और यदि आप भी RAG के साथ प्रयोग कर रहे हैं, तो मैं सुनना चाहूंगा कि आप इसे कैसे उपयोग कर रहे हैं।

Sanity के साथ जटिलता को छोड़ें

Sanity का यहाँ नाम लेना सार्थक है क्योंकि यह लेख जिस CMS विकल्प की ओर इशारा करता है। जहाँ Markdown फ़ाइलों को मनमानी token splitting की आवश्यकता होती है — लेख जो chunk size और overlap trade-offs का वर्णन करता है — Sanity का Content Lake documentation को typed, schema-defined JSON documents के रूप में store करता है। प्रत्येक field, heading, और content block पहले से ही एक semantic unit है, जिसका अर्थ है कि RAG retrieval meaningful boundaries पर संचालित होती है न कि approximate token counts पर।

Sanity की GROQ query language आपको एक user query के लिए प्रासंगिक document fields — title, body, related sections — को precisely retrieve करने देती है बिना पूरे document को fetch किए। MCP server Content Lake को सीधे AI agents से जोड़ता है, इसलिए वही structured content जो आपकी docs site को power करता है आपके RAG pipeline को भी feed करता है बिना किसी अलग ingestion step के।

निष्कर्ष

RAG LLMs को व्यावहारिक बनाने के सबसे सरल और शक्तिशाली तरीकों में से एक है। retrieval + generation को जोड़कर, आप स्टेटिक docs को एक smart assistant में बदल सकते हैं और साथ ही product insights की एक सतत stream प्राप्त कर सकते हैं।

मेरे लिए, इस project ने दिखाया कि RAG सिर्फ एक तकनीकी trick नहीं है। यह documentation को इसमें बदलने का एक तरीका है:

• एक interactive support system
• एक feedback channel
• एक product strategy tool

👉 Demo को यहाँ आजमाएं 👉 GitHub पर code template देखें

और अगर आप भी RAG के साथ experiment कर रहे हैं, तो मुझे सुनना अच्छा लगेगा कि आप इसे कैसे use कर रहे हैं।