संक्षिप्त उत्तर: RAG यह ढूँढने में बहुत अच्छा है कि ब्रूइंग साहित्य क्या कहता है, और वह जो कहता है उसे करने में काफ़ी खराब। उसे अपनी पाठ्यपुस्तकों, शोधपत्रों और लैब विधियों की ओर मोड़िए, chunks ऐसे बनाइए कि कोई formula कभी अपनी इकाइयों से अलग न हो, hybrid search इस्तेमाल कीजिए क्योंकि ब्रूइंग ऐसे संक्षिप्त रूपों से भरी है जिन्हें embeddings धुंधला कर देते हैं, और हर जवाब से उस अंश का हवाला दिलवाइए जहाँ से वह आया। फिर गणित को मॉडल से पूरी तरह हटा दीजिए। वह समझाने के लिए formula retrieve करता है। संख्या एक परखा हुआ टूल निकालता है।
किसी सामान्य चैटबॉट से पूछिए कि बीयर के original extract और real degree of fermentation से उसका अल्कोहल कैसे निकालें। आपको एक आत्मविश्वास भरा पैराग्राफ़ और एक formula मिलेगा। कभी वह सही formula होता है। कभी वह specific gravity पर चलने वाला homebrew शॉर्टकट होता है, जिसे Plato संख्याओं के कपड़े पहना दिए गए जिनके लिए वह कभी बना ही नहीं था। दोनों ही सूरतों में आखिरी संख्या मॉडल के दिमाग में निकाली गई है, और मुसीबत वहीं से शुरू होती है।
यह The Brewer’s Agent की पहली पोस्ट है, एक सीरीज़ जो ब्रूइंग के लिए ऐसे GenAI टूल बनाने के बारे में है जिन पर ब्रूअर सचमुच भरोसा कर सके। यह वहीं से शुरू होती है जहाँ वाइनरी में The Cellar Ledger रुकी थी: मॉडल उतना ही अच्छा है जितना उसके नीचे का डेटा और टूल्स।
RAG असल में क्या करता है
retrieval-augmented generation एक सरल विचार है। मॉडल के जवाब देने से पहले, एक search चरण आपके नियंत्रण वाले संग्रह से सबसे प्रासंगिक अंश निकालता है। फिर मॉडल याददाश्त की बजाय उन अंशों से जवाब देता है।
एक ब्रूअरी के लिए वह संग्रह हो सकता है:
- कुछ पाठ्यपुस्तकें और वे अध्याय जिन्हें लोग सचमुच इस्तेमाल करते हैं
- hop रसायन, mashing और किण्वन पर प्रकाशित शोधपत्र
- आपकी अपनी लैब विधियाँ और SOPs
- सप्लायर specifications और certificates of analysis
फ़ायदा यह नहीं है कि मॉडल ज़्यादा होशियार हो जाता है। फ़ायदा यह है कि जवाब आपके चुने हुए दस्तावेज़ से आता है, और जवाब बता सकता है कि किससे। ब्रूअर पन्ना खोलकर जाँच सकता है। वही आदत, स्रोत जाँचना, पूरा सुरक्षा तंत्र है।
Chunking: जहाँ ब्रूइंग दस्तावेज़ टूटते हैं
index होने से पहले दस्तावेज़ chunks में बाँटे जाते हैं, और तकनीकी क्षेत्रों में ज़्यादातर RAG विफलताएँ यहीं से शुरू होती हैं।
default तरीका हर हज़ार के आसपास अक्षरों पर टेक्स्ट बाँटता है। ब्रूइंग साहित्य ऐसे formulas से भरा है जिनके बाद एक लाइन चिह्न, इकाइयाँ और तापमान आधार समझाती है। गलत जगह बाँटिए, और एक chunk में formula होता है और अगले में “जहाँ OG, 20/20 डिग्री C पर डिग्री Plato में है”। मॉडल पहला retrieve करता है और दूसरे का अंदाज़ा लगाता है।
ज़्यादातर समस्या ठीक करने वाले नियम:
- formula को उसकी परिभाषाओं के साथ रखिए। अक्षरों की गिनती पर नहीं, section की सीमाओं पर बाँटिए, और एक समीकरण और उसके बाद वाले पैराग्राफ़ को एक इकाई मानिए।
- tables पूरी रखिए। header पंक्ति के बिना hop utilisation table सिर्फ़ संख्याओं की सूची है। पूरी table, headers, footnotes समेत, एक chunk के रूप में रखिए, चाहे वह लंबी हो।
- परिपाटियाँ metadata में रखिए। हर chunk के साथ इकाइयाँ, तापमान आधार और स्रोत का संस्करण रखिए। 20/20 डिग्री C पर Plato और 60/60 डिग्री F पर specific gravity एक-दूसरे की जगह नहीं ले सकते, और मॉडल को दिखना चाहिए कि उसके हाथ में कौन सा है।
- लंबी व्युत्पत्तियों के लिए parent retrieval। सटीक मिलान के लिए छोटे chunks index कीजिए, पर मॉडल को वह पूरा section दीजिए जिससे वे आए।
hybrid search, क्योंकि ब्रूइंग संक्षिप्त रूपों में बोलती है
vector search मिलते-जुलते अर्थ वाले अंश ढूँढता है। “मेरी lager में पके sweetcorn का स्वाद क्यों है” को DMS तक पहुँचाने के लिए यह बढ़िया है। उन शब्दों के लिए यह उतना अच्छा नहीं जहाँ एक अक्षर मायने रखता है।
RDF और ADF attenuation के दो अलग माप हैं, और एक ही बीयर पर वे दस पॉइंट से ज़्यादा अलग हो सकते हैं। embedding मॉडल को वे लगभग एक जैसे दिखते हैं: छोटे, बड़े अक्षरों वाले, किण्वन के बारे में। keyword search (BM25 या उस जैसा) उन्हें वैसे ही अलग शब्द मानता है जैसे वे हैं।
इसलिए दोनों चलाइए और नतीजे मिलाइए, फिर एक reranker को सबसे प्रासंगिक अंश सबसे आगे रखने दीजिए। ज़्यादातर vector databases और search सेवाएँ अब यह सीधे सपोर्ट करती हैं। किसी तकनीकी RAG सिस्टम में आप जो सुधार कर सकते हैं, उनमें यह अकेला सबसे सस्ता है।
ज्ञान के लिए retrieval, गणित के लिए टूल
यह वह नियम है जिस पर पूरी सीरीज़ टिकी है। मॉडल formula समझा सकता है। उसे हल नहीं कर सकता।
चित्र वाला सवाल लीजिए। 13.0 डिग्री Plato का wort 64.9% के real degree of fermentation तक किण्वित हुआ। ABV क्या है?
सही तरीके से करें तो यह Balling के उस संबंध से होकर जाता है जो खर्च हुए extract और बने अल्कोहल को जोड़ता है, लगभग 4.77% का real extract और वज़न के हिसाब से लगभग 4.27% अल्कोहल देता है, फिर बीयर के अपने घनत्व से वज़न को वॉल्यूम में बदलता है। जवाब 5.46% ABV है। हर चरण में चार दशमलव वाला एक constant और एक इकाई परिपाटी जुड़ी है।
दिमाग में यह करने को कहे गए language model अक्सर करीब पहुँच जाते हैं। करीब ही समस्या है। वह कभी-कभार एक चरण छोड़ देगा, गलत घनत्व इस्तेमाल करेगा या वज़न और वॉल्यूम की अदला-बदली कर देगा, और 4.3% को ठीक उसी आत्मविश्वास से पेश करेगा जैसे 5.46% को। गद्य में कुछ भी नहीं बताता कि आपको कौन सा जवाब मिला।
इलाज आर्किटेक्चर में है, बेहतर प्रॉम्प्ट में नहीं। retrieval चरण स्पष्टीकरण देता है: RDF क्या है, वज़न और वॉल्यूम अलग क्यों हैं, constants कहाँ से आते हैं। एक calculation टूल, साधारण परखा हुआ कोड, संख्या देता है। अगली पोस्ट वे टूल बनाती है। इस पोस्ट के लिए मुद्दा यह है कि RAG सिस्टम को गणित बाहर भेजना चाहिए, और जवाब में यह बताना चाहिए: “OG और RDF से ABV टूल द्वारा गणना की गई”।
हवाले ही असली फ़ीचर हैं
हर जवाब के साथ उसके स्रोत होने चाहिए: दस्तावेज़, section और आदर्श रूप से पन्ना। इसे system prompt में पक्की शर्त बनाइए और testing में जाँचिए। बिना हवाले वाले जवाब को फ़ेल जवाब माना जाना चाहिए, चाहे वह कितना भी अच्छा लगे।
दो छोटी चीज़ें हवालों को कहीं ज़्यादा उपयोगी बनाती हैं:
- सिर्फ़ शीर्षक नहीं, अंश दिखाइए। उद्धृत पैराग्राफ़ पर नज़र डालने वाला ब्रूअर गलत संस्करण या homebrew स्रोत को किसी भी स्वचालित जाँच से जल्दी पकड़ लेगा।
- जब कुछ न मिले तो बताइए। अगर retrieval कुछ भी प्रासंगिक नहीं लौटाता, तो सही जवाब है “मेरे पास इसका कोई स्रोत नहीं है”, सामान्य ज्ञान से धाराप्रवाह अंदाज़ा नहीं। इस व्यवहार को जानबूझकर परखिए, क्योंकि मॉडल मददगार होने के लिए train होते हैं और आप इजाज़त दें तो खाली जगह भर देंगे।
यह कहाँ टूटता है
आपके संग्रह की अपनी राय है। पाठ्यपुस्तकें hop utilisation पर असहमत हैं, homebrew स्रोत ऐसे शॉर्टकट इस्तेमाल करते हैं जो व्यावसायिक लैब नहीं करतीं, और पुराने संस्करणों में रद्द हो चुकी विधियाँ हैं। RAG वफ़ादारी से वही अंश retrieve करता है जो सबसे अच्छा मेल खाए। संग्रह को सँवारिए, स्रोत के प्रकार का tag लगाइए, और जहाँ आपकी अपनी लैब विधियाँ हों वहाँ उन्हें प्राथमिकता दीजिए।
स्कैन की गई PDFs गणित खो देती हैं। OCR subscripts, यूनानी अक्षरों और भिन्नों को शोर में बदल देता है। जो formula किताब में “E = P/100” पढ़ता है, वह “E - Pl100” बनकर निकल सकता है। index पर भरोसा करने से पहले अपने सबसे ज़्यादा इस्तेमाल होने वाले formulas का निकाला गया टेक्स्ट आँख से जाँचिए।
copyright अब भी लागू है। आंतरिक इस्तेमाल के लिए पाठ्यपुस्तक index करना एक बात है। मॉडल को कंपनी के बाहर के लोगों को लंबे अंश उद्धृत करने देना दूसरी। जानिए कि आप जो दस्तावेज़ index करते हैं उन पर कौन सा licence लागू है।
हवाले भी गढ़े जा सकते हैं। मॉडल ऐसा reference बना सकता है जो सही दिखे और कभी retrieve ही न हुआ हो। हवाला कोड में retrieval metadata से बनाइए, मॉडल के टेक्स्ट से नहीं।
निचोड़
RAG ब्रूइंग साहित्य के ढेर को ऐसी चीज़ में बदल देता है जिससे आप सवाल पूछ सकें, और जवाब वापस पन्ने की ओर इशारा करते हैं। यह सचमुच उपयोगी है। जो यह नहीं करता वह है मॉडल को गणित में अच्छा बनाना, और ब्रूइंग ज़्यादातर परिपाटियों से जुड़ा गणित ही है। chunks ऐसे बनाइए कि formulas अपनी इकाइयाँ न खोएँ, अर्थ के साथ keywords से भी खोजिए, हवालों पर ज़ोर दीजिए, और हर संख्या टूल को भेजिए। मॉडल किताब पढ़ता है। कैलकुलेटर जोड़-घटाव करता है।
ब्रूअरियों में AI अभी क्या कर रहा है, इसकी बड़ी तस्वीर के लिए देखें What AI in Beer Actually Looks Like in 2026। पूरी सूची The Brewer’s Agent सीरीज़ पेज पर है।
अक्सर पूछे जाने वाले सवाल
RAG क्या है और ब्रूइंग ज्ञान के लिए इसे क्यों इस्तेमाल करें? retrieval-augmented generation का मतलब है कि मॉडल जवाब देने से पहले आपके अपने दस्तावेज़ों से अंश खोजता है, और उन्हीं अंशों से जवाब देता है। ब्रूइंग में यह जवाबों को उन पाठ्यपुस्तकों, शोधपत्रों और लैब विधियों से बाँधे रखता है जिन पर आप भरोसा करते हैं, बजाय उसके जो मॉडल को इंटरनेट से आधा-अधूरा याद है, और हर जवाब को अपने स्रोत का हवाला देने देता है।
क्या RAG सिस्टम ABV या IBU सही निकाल सकता है? यह सही formula ढूँढ सकता है, पर उसे गणना नहीं करनी चाहिए। language models कई चरणों वाले गणित में भरोसेमंद नहीं हैं, और ब्रूइंग formulas में इकाई और तापमान की परिपाटियाँ होती हैं जिन्हें गड़बड़ाना आसान है। समझाने के लिए formula retrieve कीजिए और संख्याएँ एक परखे हुए calculation टूल को भेजिए।
retrieval के लिए ब्रूइंग दस्तावेज़ों के chunks कैसे बनाने चाहिए? formulas, उनके चरों की परिभाषाएँ और उनकी इकाइयाँ एक ही chunk में रखिए, और tables को उनके headers और footnotes के साथ पूरा रखिए। हर chunk के साथ तापमान आधार और इकाइयाँ जैसा metadata रखिए। तय संख्या के अक्षरों पर बाँटना अक्सर formula को उस लाइन से अलग कर देता है जो बताती है कि उसके चिह्नों का मतलब क्या है।