संक्षिप्त उत्तर: अगर आप वाइनरी डेटा के ऊपर बिना नियंत्रित मेट्रिक लेयर के GenAI असिस्टेंट लगा देते हैं, तो “Shiraz लॉट पर potential alcohol कितना है?” का जवाब वह आपके तीन छिपे रूपांतरण फ़ैक्टर में से उसी से देगा जो उसे पहले मिल जाए। 24 Brix पर ये फ़ैक्टर अल्कोहल में 1.7 पॉइंट का अंतर देते हैं, जो लेबल की छूट से भी ज़्यादा है। समस्या मॉडल नहीं है। समस्या अपरिभाषित मेट्रिक है। potential alcohol को एक बार परिभाषित करें, उसके पैरामीटर खुले में रखें, पाइपलाइन ऐसी बनाएँ कि हर रीडिंग के साथ उसका उपकरण दर्ज हो, असिस्टेंट को कच्ची टेबल की जगह semantic layer की ओर मोड़ें, और उसे उन बीस सवालों से परखें जो सेलर सच में पूछता है।
एक वाइनमेकर नए डेटा असिस्टेंट में टाइप करता है: “Shiraz लॉट पर potential alcohol कितना है?” दो सेकंड में जवाब आ जाता है, एक साफ़-सुथरी टेबल के साथ। असिस्टेंट इस अर्थ में सही है कि वह संख्या कहीं मौजूद है। पर वह गलत भी है, क्योंकि लैब की वर्कबुक कुछ और कहती, और लेबल आर्टवर्क की फ़ाइल कुछ और।
उस इमारत में किसी ने गलती नहीं की। बरसों पहले किसी ने एक सेल में रूपांतरण फ़ैक्टर टाइप किया, वह सेल अगले विंटेज की वर्कबुक में कॉपी हो गया, और अब एक ही मेट्रिक के तीन संस्करण तीन फ़ाइलों में रहते हैं। इंसान जानता है कि किस फ़ाइल पर भरोसा करना है। text-to-SQL एजेंट नहीं जानता। यह The Cellar Ledger की पहली पोस्ट है, एक सीरीज़ जो वाइनरी की संख्याओं के नीचे बैठे डेटा इंजीनियरिंग और GenAI काम के बारे में है, और यह उसी संख्या से शुरू होती है जिसे सब इस्तेमाल करते हैं और किसी ने परिभाषित नहीं किया।
GenAI एक पुरानी समस्या को और ज़ोर से क्यों सुनाता है
2026 में बाज़ार का हर chat-with-your-data प्रोडक्ट लगभग एक ही तरह काम करता है। आप अंग्रेज़ी में सवाल पूछते हैं। असिस्टेंट आपके डेटा का कोई विवरण पढ़ता है, एक क्वेरी लिखता है, उसे चलाता है और नतीजे का सार देता है। Power BI Copilot, Databricks AI/BI Genie और Snowflake Cortex Analyst तीनों यही पैटर्न अपनाते हैं, और अगर आप उन्हें semantic model या कुछ चुने हुए निर्देश दें, तो तीनों पहले उन्हीं को पढ़ते हैं।
अगर आप नहीं देते, तो वे टेबल पढ़ते हैं। और pot_alc नाम का कॉलम मॉडल को यह नहीं बताता कि उसे किस फ़ैक्टर से बनाया गया।
फिर दो चीज़ें एक साथ बिगड़ती हैं:
- जवाब अस्थिर होता है। सवाल को थोड़ा अलग ढंग से पूछिए, और एजेंट किसी और टेबल को जोड़ सकता है, कोई और कॉलम चुन सकता है और उसी आत्मविश्वास भरे लहजे में अलग संख्या दे सकता है।
- जवाब आधिकारिक दिखता है। गलत संख्या वाली स्प्रेडशीट स्प्रेडशीट ही दिखती है। गलत संख्या वाला चैटबॉट पूरा सिस्टम दिखता है। लोग स्प्रेडशीट जाँचते हैं। चैटबॉट को ज़्यादातर नहीं जाँचते।
पुरानी समस्या यह थी कि तीन लोग तीन वाइन से काम कर रहे थे। नई समस्या यह है कि असिस्टेंट हर व्यक्ति को उन तीन में से वही वाइन भेजता है जिस तक प्रॉम्प्ट संयोग से पहुँच गया।
नीचे की मेट्रिक: रूपांतरण असल में क्या है
potential alcohol को एक बार परिभाषित करने के लिए यह जानना ज़रूरी है कि अंगूठे के नियम क्या छिपा रहे हैं। Brix गुणा 0.55, 0.59 या 0.62 एक चार-चरण की गणना का शॉर्टकट है, और हर चरण एक ऐसा पैरामीटर है जिसका कोई मालिक होना चाहिए।
1. Brix से घनत्व। डिग्री Brix का मतलब है प्रति 100 ग्राम घोल में सुक्रोज़ के ग्राम, वज़न के अनुपात में। सुक्रोज़ घोल का एक मानक polynomial 24 Brix पर लगभग 1.101 का specific gravity देता है।
2. प्रति लीटर घुले ठोस। Brix गुणा SG गुणा 10। हमारे must के लिए, लगभग 264 g/L।
3. जो चीनी नहीं है उसे घटाइए। अंगूर का must ग्लूकोज़ और फ़्रक्टोज़ के साथ अम्ल, खनिज और फ़िनोलिक्स भी है। पके फल में गैर-चीनी ठोस आमतौर पर 20 से 30 g/L के आसपास होते हैं। 25 लीजिए तो लगभग 239 g/L किण्वन योग्य चीनी बचती है।
4. चीनी से अल्कोहल। सिद्धांत में एक ग्लूकोज़ अणु से दो एथेनॉल और दो CO2 बनते हैं, इसलिए लगभग 15.4 g/L चीनी से 1% alcohol by volume बनता है। असली यीस्ट कोशिकाएँ बनाता है, ग्लिसरॉल बनाता है और कुछ एथेनॉल गैस के साथ खो देता है, इसलिए व्यावहारिक आँकड़े ऊँचे रहते हैं। EU प्रति 1% vol के लिए 16.83 g/L इस्तेमाल करता है। 239 को 16.83 से भाग दें तो 14.2% आता है।
फ़ंक्शन के रूप में लिखें तो पूरी बात छोटी है:
def potential_alcohol(brix, non_sugar_gl=25.0, yield_gl_per_pct=16.83):
sg = 1 + brix / (258.6 - (brix / 258.2) * 227.1)
sugar_gl = brix * sg * 10 - non_sugar_gl
return sugar_gl / yield_gl_per_pct
मुद्दा कोड नहीं है। मुद्दा यह है कि non_sugar_gl और yield_gl_per_pct अब नामित हैं, दिखते हैं और उनका मालिक है। शॉर्टकट फ़ैक्टर दोनों को छिपाते हैं, इसीलिए वे आपस में मेल नहीं खाते।
यह इसलिए मायने रखता है कि छूट एक-एक पॉइंट में मापी जाती है। US में 14% या उससे कम की वाइन सच से 1.5 पॉइंट के भीतर लेबल की जा सकती है, और 14% से ऊपर 1 पॉइंट के भीतर, और लेबल 14% की रेखा पार नहीं कर सकता क्योंकि वहाँ excise दर बदलती है। इमारत भर में 1.7 पॉइंट का फैलाव उस छूट से बड़ा है जिसके भीतर उसे रहना है।
डेटा इंजीनियरिंग का हल: उपकरण की जानकारी रखने वाली लेयर
मेट्रिक परिभाषित करना आधा काम है। बाकी आधा यह पक्का करना है कि इनपुट का वही मतलब हो जो मेट्रिक मानकर चलती है। यहीं बहुत-सा वाइनरी डेटा किसी AI के पास पहुँचने से पहले ही टूट जाता है।
वाइनयार्ड में refractometer ठीक है। किण्वन शुरू होते ही अल्कोहल refractive index बढ़ा देता है, इसलिए refractometer बची हुई चीनी को ज़्यादा बताता है, और वाइन जितनी सूखी होती जाती है यह गड़बड़ी उतनी बढ़ती है। hydrometer घनत्व मापता है, और एथेनॉल पानी से हल्का है, इसलिए एक सूखी रेड वाइन लगभग माइनस 1 से माइनस 2 Brix पढ़ती है। दोनों रीडिंग वही सही बताती हैं जो उपकरण मापता है। दोनों उसी पल गलत हो जाती हैं जब पाइपलाइन उन्हें brix नाम के एक ही कॉलम में रख देती है।
एक सीधा medallion ढाँचा बिना किसी बड़े जतन के यह संभाल लेता है:
- Bronze हर रीडिंग को ठीक वैसी ही रखता है जैसी ली गई: मान, इकाई, उपकरण, किसने, कब, कौन सा टैंक। कुछ भी रूपांतरित नहीं होता और कुछ भी फेंका नहीं जाता।
- Silver वह संदर्भ जोड़ता है जो पाइपलाइन खुद निकाल सकती है: टैंक की अपनी घटनाओं से किण्वन चरण (inoculation से पहले, सक्रिय, सूखा), और inoculation के बाद ली गई हर refractometer रीडिंग पर एक फ़्लैग। किण्वन के बीच की hydrometer रीडिंग का नाम बदलकर वही रखा जाता है जो वह है, घनत्व, और उसे नेगेटिव होने दिया जाता है।
- Gold और semantic layer नियंत्रित मेट्रिक्स रखते हैं।
potential_alcoholसिर्फ़ inoculation से पहले की चीनी रीडिंग पढ़ता है। जैसे ही किसी तैयार लॉट का लैब से मापा गया अल्कोहल आ जाता है, एक अलगalcohol_measuredउसकी जगह ले लेता है और उस लॉट के लिए अनुमान रिटायर हो जाता है।
bronze टेबल पर एक data contract लगाइए जो बिना उपकरण वाली रीडिंग को अस्वीकार कर दे। यह validation की एक लाइन है, और यही लाइन अगले विंटेज की उलझन को बोर्ड रिपोर्ट में पहुँचने की बजाय दरवाज़े पर ही रोक देती है।
असिस्टेंट को सही लेयर की ओर मोड़ना
मेट्रिक परिभाषित हो जाने के बाद GenAI वाला हिस्सा काफ़ी कम रोमांचक रह जाता है, और आप यही चाहते हैं। तीन सेटिंग ज़्यादातर काम कर देती हैं:
- असिस्टेंट को semantic model तक सीमित रखें। उसे कच्ची टेबल बिल्कुल न दें। अगर वह
potential_alcoholको सिर्फ़ एक measure के रूप में देख सकता है, तो वह चौथा संस्करण गढ़ नहीं सकता। - निर्देश सेलर मैनुअल की तरह लिखें। इनमें से ज़्यादातर टूल सादे टेक्स्ट में निर्देश लेते हैं। उनका इस्तेमाल उन डोमेन तथ्यों के लिए करें जिनका मॉडल अंदाज़ा नहीं लगा सकता: “inoculation के बाद Brix घनत्व है, चीनी नहीं”, “तैयार लॉट का अल्कोहल
alcohol_measuredसे आता है”, “वॉल्यूम 20 डिग्री C पर लीटर में हैं”। - उससे विधि का हवाला दिलवाएँ। हर जवाब के नीचे मेट्रिक का नाम और उसके पैरामीटर माँगें। जो वाइनमेकर “potential alcohol, EU yield 16.83 g/L, non-sugar 25 g/L” देखता है, वह संख्या की बजाय धारणा पर बहस कर सकता है।
बीस सवालों का eval सेट
आखिरी कदम वही है जिसे टीमें छोड़ देती हैं। किसी के असिस्टेंट पर भरोसा करने से पहले, बीस के आसपास ऐसे सवाल लिख लें जो सेलर सच में पूछता है, और जिनके जवाब किसी ने हाथ से जाँचे हों। “लॉट 24-SH-03 पर potential alcohol।” “कौन से टैंक अभी भी 5 Brix से ऊपर हैं?” “पिछले साल की Viognier का मापा गया अल्कोहल।” जब भी मॉडल, प्रॉम्प्ट या semantic model बदले, यह सेट चलाएँ और संख्याओं के exact match पर स्कोर करें।
यह एक छोटी फ़ाइल है। और “क्या हम चैटबॉट पर भरोसा कर सकते हैं?” का यही एक ईमानदार जवाब है। आप उस पर भरोसा नहीं करते। आप उसे परखते हैं, ठीक वैसे जैसे लैब किसी नए उपकरण को इस्तेमाल में लाने से पहले एक reference के सामने परखती है।
और एक बोनस भी है। हर तैयार लॉट आपको एक जोड़ी देता है: शुरुआती चीनी और मापा गया अल्कोहल। किस्म के हिसाब से कुछ विंटेज की ऐसी जोड़ियाँ आपको अपने फल, अपने यीस्ट और अपने सेलर के लिए अपना yield आँकड़ा फ़िट करने देती हैं। यह इमारत का पहला सचमुच काम का मॉडल है, और यह सिर्फ़ इसलिए मौजूद है क्योंकि पाइपलाइन ने दोनों संख्याएँ सँभालकर रखीं।
यह कहाँ टूटता है
गैर-चीनी का अनुमान अब भी अंदाज़ा है। यह किस्म, पकाव, सड़न और प्रेस फ़्रैक्शन के साथ बदलता है। लिखा हुआ default छिपे हुए से बेहतर है, पर हर साल कुछ must पर इसे मापें और इसे अस्थायी मानें।
semantic layer खराब सैंपलिंग ठीक नहीं करती। एक पंक्ति के धूप वाले सिरे का रस पूरे ब्लॉक का हाल नहीं बताता। कोई मेट्रिक परिभाषा बाल्टी को नहीं सुधारती।
निर्देश खिसकते हैं। असिस्टेंट को दिया गया सादा-टेक्स्ट मार्गदर्शन configuration है। उसका version रखें, बदलावों की समीक्षा करें, और बदलने पर eval सेट दोबारा चलाएँ, वरना वह चुपचाप चौथी स्प्रेडशीट बन जाता है।
नियम बाज़ार के हिसाब से बदलते हैं। ऊपर के US छूट आँकड़े वे हैं जिन्हें मैं सबसे अच्छी तरह जानता हूँ। उन पर लेबलिंग जाँच बनाने से पहले जिस बाज़ार में आप बेचते हैं उसके नियम देख लें।
निचोड़
चैटबॉट ने तीन जवाब दिए क्योंकि वाइनरी के पास तीन जवाब थे। GenAI ने यह समस्या पैदा नहीं की। उसने बस इसे छिपाना बंद कर दिया। मेट्रिक को एक बार उसके पैरामीटर खुले में रखकर परिभाषित करें, हर रीडिंग को उसके उपकरण के साथ रखें, असिस्टेंट को सिर्फ़ नियंत्रित लेयर देखने दें, और उसे जाँचे हुए सवालों के एक छोटे सेट पर कसें। तब दो सेकंड का जवाब सचमुच काम का होता है।
वाइनरी डैशबोर्ड सेलर का भरोसा क्यों खो देते हैं, इस बड़े तर्क के लिए देखें वाइनरी में Power BI डैशबोर्ड क्यों दम तोड़ देते हैं। एक साफ़ किण्वन कर्व से मॉडल क्या कर सकता है, यह वाइन किण्वन नियंत्रण के लिए AI में है। इस सीरीज़ में आगे: सेलर का event-sourcing, वह डेटा मॉडल जिससे वॉल्यूम का हिसाब मिलता है। पूरी सूची Cellar Ledger सीरीज़ पेज पर है।
अक्सर पूछे जाने वाले सवाल
chat-with-your-data असिस्टेंट एक ही सवाल के अलग-अलग जवाब क्यों देता है? आमतौर पर इसलिए कि मेट्रिक कहीं भी ऐसी जगह परिभाषित नहीं है जहाँ असिस्टेंट उसे देख सके। text-to-SQL एजेंट उन कॉलम पर क्वेरी लिखता है जो उसे ठीक लगते हैं। अगर potential alcohol तीन वर्कबुक में तीन अलग फ़ैक्टर से निकाला जाता है, तो एजेंट एक चुन लेता है, और थोड़ा अलग प्रॉम्प्ट दूसरा चुन लेता है। हल यह है कि मेट्रिक को एक नियंत्रित semantic layer में एक बार परिभाषित करें और असिस्टेंट को उसी की ओर मोड़ें, कच्ची टेबल की ओर नहीं।
वाइनरी को अपनी semantic layer में सबसे पहले क्या रखना चाहिए? वे संख्याएँ जिन पर लोग बहस करते हैं: potential alcohol, residual sugar, हाथ में मौजूद वॉल्यूम, नुकसान, और प्रति टन उपज। हर एक की एक परिभाषा हो, स्पष्ट लिखे पैरामीटर हों, जैसे चीनी से अल्कोहल का yield आँकड़ा, और एक नामित मालिक हो। GenAI असिस्टेंट से सबसे ज़्यादा यही सवाल पूछे जाएँगे, इसलिए गलत जवाब का सबसे बड़ा नुकसान भी यहीं होता है।
वाइनमेकर के इस्तेमाल से पहले GenAI डेटा असिस्टेंट को कैसे परखें? सेलर जो असली सवाल पूछता है, ऐसे बीस के आसपास सवाल लिखें, जिनके जवाब किसी व्यक्ति ने हाथ से जाँचे हों, और हर बार मॉडल, प्रॉम्प्ट या semantic model बदलने पर इन्हें चलाएँ। संख्याओं पर exact match से स्कोर करें। यह एक छोटा evaluation सेट है, और यह ज़्यादातर गड़बड़ियों को वाइनमेकर से पहले पकड़ लेता है।