Loss Map: एक medallion पाइपलाइन, anomaly फ़्लैग और एक LLM जो variance नोट का ड्राफ़्ट बनाता है

संक्षिप्त उत्तर: 100 टन लाल फल crush करने वाली वाइनरी शायद 72,000 लीटर प्रेस करे और 63,500 बोतल में भरे। बीच के 8,500 लीटर ज़्यादातर जाने-पहचाने नुकसान हैं: lees, racking, वाष्पीकरण, filtration, bottling। मायने उस हिस्से के हैं जो इन सबका हिसाब लगाने के बाद बचता है, यानी अनसमझा residual। movement ledger के ऊपर loss map को medallion पाइपलाइन के रूप में बनाइए, असामान्य चरणों को किसी फ़ैंसी मॉडल की बजाय robust statistics से फ़्लैग कीजिए, और क्वेरी के नतीजों से एक LLM को variance नोट का ड्राफ़्ट बनाने दीजिए। शब्द मॉडल लिखता है। जोड़ SQL करता है।

उदाहरण के आँकड़े, benchmark नहीं। आपके अपने ledger से आपके अपने चरण ही गिनती की संख्याएँ हैं।

हर विंटेज के अंत में कोई न कोई वही सवाल पूछता है: हमने इतना प्रेस किया, उतना बोतल में भरा, बाकी कहाँ गया? ईमानदार जवाब आमतौर पर कंधे उचकाकर दिया जाता है: “lees, वाष्पीकरण और ढेर सारी छोटी चीज़ें”। वह कंधे उचकाना दो बहुत अलग तरह के नुकसान छिपा लेता है। ज़्यादातर हिस्सा वाइन बनाने की सामान्य कीमत है। एक छोटा टुकड़ा ऐसी वाइन है जिसका वाइनरी हिसाब नहीं दे सकती, और पैसा, excise के सवाल और प्रक्रिया की समस्याएँ उसी टुकड़े में रहती हैं।

पिछली पोस्ट ने movement ledger बनाया। यह पोस्ट उसे loss map में बदलती है, anomaly detection की एक हल्की परत जोड़ती है, और मासिक लेखन को एक छोटी रस्सी से बँधे LLM को सौंपती है।

ज्ञात नुकसान बनाम अनसमझा नुकसान

कुछ नुकसान ऐसी वाइन है जिसे वाइनरी ने दर्ज कारण के साथ खुद छोड़ना चुना:

• किण्वन और पहली racking के बाद gross lees, अक्सर वॉल्यूम का कुछ प्रतिशत।
• हर बार तलछट से वाइन हटाने पर racking का नुकसान।
• बैरल वाष्पीकरण, जो सेलर की नमी और तापमान पर बहुत निर्भर करता है, और साल में कुछ प्रतिशत तक जाता है।
• topping और सैंपल, छोटे पर लगातार।
• filtration और bottling, होज़, फ़िल्टर और filler bowl में फँसा dead volume।

बाकी सब residual है: इनपुट, घटा आउटपुट, घटा हर दर्ज नुकसान। ऊपर के उदाहरण विंटेज में 7,600 लीटर नुकसान का कारण है और 900 लीटर का नहीं। नौ सौ लीटर तैयार रेड वाइन एक हज़ार से ज़्यादा बोतलें हैं। इस पर एक दोपहर लगाना बनता है।

residual कभी शून्य नहीं होता। मीटर मेल नहीं खाते, dip में त्रुटि होती है, तापमान वॉल्यूम को इधर-उधर करता है। लक्ष्य शून्य नहीं है। लक्ष्य है residual इतना छोटा और स्थिर हो कि जब वह उछले, तो आपको दिख जाए।

पाइपलाइन: bronze, silver, gold

loss map एनालिटिक्स की समस्या बनने से पहले डेटा इंजीनियरिंग की समस्या है। medallion पैटर्न इस पर अच्छी तरह बैठता है।

Bronze खुद movement ledger है, बिना छुए: हर receive, transfer, rack, top, filter, bottle, observe और adjust event, वॉल्यूम 20 डिग्री C पर सुधारे हुए।

Silver हर movement को एक चरण और एक loss श्रेणी में बाँटता है। एक rack event जो 58 लीटर lees टैंक में भेजता है, वह बनता है “loss: gross lees, stage: post-ferment, lot 24-SH-03”। जो lees बाद में filter होकर वापस मिल जाते हैं, वे recovery event के रूप में लौटते हैं, ताकि उन्हें दो बार नुकसान न गिना जाए। ज़्यादातर डोमेन लॉजिक यहीं रहता है, और यहीं सेलर मास्टर को नियमों की समीक्षा करनी चाहिए, क्योंकि event प्रकार से loss श्रेणी तक की mapping प्रक्रिया के बारे में राय का एक सेट है।

Gold प्रति लॉट, प्रति चरण, प्रति विंटेज एक पंक्ति है: अंदर आया वॉल्यूम, बाहर गया वॉल्यूम, श्रेणी के अनुसार ज्ञात नुकसान, और residual। यही waterfall, डैशबोर्ड और, जैसा हम देखेंगे, language model को भरता है।

SELECT lot_id, stage,
       SUM(volume_in_l)  AS vol_in,
       SUM(volume_out_l) AS vol_out,
       SUM(known_loss_l) AS known_loss,
       SUM(volume_in_l) - SUM(volume_out_l) - SUM(known_loss_l) AS residual_l
FROM   silver_lot_stage_movements
GROUP  BY lot_id, stage;

यह एक क्वेरी है। मेहनत silver में है, श्रेणियाँ सही करने में।

anomaly फ़्लैग: जानबूझकर उबाऊ statistics

gold टेबल बनते ही अगली स्वाभाविक माँग होती है “AI से समस्याएँ ढूँढो”। किसी deep मॉडल की ओर हाथ बढ़ाने की इच्छा रोकिए। एक वाइनरी में साल में शायद कुछ सौ लॉट होते हैं और कुछ ही विंटेज का साफ़ इतिहास। किसी पेचीदा चीज़ को train करने के लिए यह काफ़ी डेटा नहीं है, और सेलर मास्टर को फ़्लैग हाथ से जाँच पाना चाहिए।

एक robust z-score काम कर देता है:

1. हर चरण और बर्तन के प्रकार के लिए (मान लीजिए, 5,000 लीटर stainless से racking), सभी लॉट की loss rate का median लीजिए।
2. median absolute deviation से मापिए कि दरें कितनी फैली हैं, जो किसी इक्का-दुक्का चरम मान से खिंचने की बजाय उसे नज़रअंदाज़ करता है।
3. जिस लॉट की loss rate median से लगभग तीन स्केल्ड deviation से ज़्यादा दूर हो, उसे फ़्लैग कीजिए।

इससे वह एक टैंक फ़्लैग हो जाता है जिसने racking में 4% खोया जबकि उसके साथियों ने 1.5%, और वह विंटेज-व्यापी बदलाव नज़रअंदाज़ हो जाता है जो हर टैंक में था। यह चमकदार नहीं है। यह खुद को एक वाक्य में समझा देता है, और यह ज़्यादा मायने रखता है।

बैरल वाष्पीकरण का अलग इलाज होना चाहिए। यह इस पर निर्भर करता है कि बैरल कहाँ रखा है, इसलिए अगर आप दर्ज करते हैं तो सेलर ज़ोन और स्थिति के हिसाब से समूह बनाइए। rackhouse microclimate पोस्ट यही भौतिकी व्हिस्की की ओर से समझाती है।

LLM variance नोट का ड्राफ़्ट बनाता है

हर महीने कोई ऑपरेशंस रिव्यू के लिए एक-दो पैराग्राफ़ लिखता है: इस महीने का नुकसान, तुलना में कैसा है, क्या हुआ। इसमें एक घंटा लगता है और यह उबाऊ है। यह language model के लिए अच्छा काम है, बशर्ते आप इसे ऐसे सेट करें कि वह संख्याएँ गलत कर ही न सके।

जो पैटर्न काम करता है:

1. हर गणना SQL करता है। gold टेबल, महीने-दर-महीने बदलाव, फ़्लैग हुए लॉट, वॉल्यूम के हिसाब से सबसे बड़े adjustment कारण। मॉडल के कुछ भी देखने से पहले सब गणना हो चुका होता है।
2. मॉडल को नतीजे structured input के रूप में मिलते हैं। आँकड़ों का एक छोटा JSON ब्लॉक, फ़्लैग हुए लॉट की सूची, और वे free-text कारण जो ऑपरेटरों ने अपने adjustment events पर टाइप किए।
3. मॉडल तय आँकड़ों के इर्द-गिर्द गद्य लिखता है। उससे कहिए कि सिर्फ़ दिए गए नंबर इस्तेमाल करे और हर दावे के लिए स्रोत पंक्ति बताए। इससे भी बेहतर, उससे placeholders के साथ नोट लौटवाइए जिन्हें कोड JSON से भरे, ताकि कोई भी संख्या कभी मॉडल टाइप न करे।
4. वह ऑपरेटरों के कारणों को समूहों में बाँटता है। बीस adjustment नोट जो कहते हैं “topping दर्ज नहीं हुई”, “B-row top किया, भूल गया”, “topping, छूट गई”, वे एक लाइन बन जाते हैं: “residual का ज़्यादातर हिस्सा B row में दर्ज न की गई बैरल topping से आता है”। यहीं मॉडल सचमुच अपनी कीमत वसूलता है। वह गड़बड़ इंसानी टेक्स्ट अच्छी तरह पढ़ता है।
5. कोई व्यक्ति संपादित करता है और हस्ताक्षर करता है। नोट वाइनमेकर के नाम से जाता है, मॉडल के नहीं।

जो आपको नहीं करना चाहिए, वह है मॉडल को कच्चा ledger देकर पूछना कि इस महीने क्या गलत हुआ। वह दिमाग में कॉलम जोड़ेगा, और पूरे आत्मविश्वास से कुछ सौ लीटर गलत होगा।

यह कहाँ टूटता है

residual हर माप की त्रुटि सोख लेता है। खिसकता flow meter अनसमझे नुकसान के रूप में दिखता है। गलत तापमान पर पढ़ी गई dip stick भी। residual को गायब वाइन मानने से पहले उपकरण जाँचिए।

silver के नियम राय हैं। lees वाइन को नुकसान गिनें या वापस मिलने वाला उप-उत्पाद, इससे map बदल जाता है। नियम लिखिए और सेलर मास्टर से मंज़ूर करवाइए, वरना दो लोग एक ही waterfall को दो तरह पढ़ेंगे।

नुकसान के लक्ष्य व्यवहार बदलते हैं। अगर लोगों को गुलाबी बार पर आँका जाएगा, तो गुलाबी बार किसी और चीज़ के रूप में दर्ज होकर छोटा हो जाएगा। map का इस्तेमाल प्रक्रिया की समस्याएँ ढूँढने के लिए कीजिए, सेलर टीम को नंबर देने के लिए नहीं।

LLM अब भी शब्दों से भटका सकता है। तय संख्याओं के साथ भी, मॉडल एक सामान्य महीने को समस्या की तरह पेश कर सकता है या असली समस्या को टाल सकता है। इसीलिए फ़्लैग statistics से आते हैं और मॉडल सिर्फ़ उनका वर्णन करता है।

निचोड़

हर वाइनरी वाइन खोती है। सवाल यह है कि उस नुकसान का कितना हिस्सा कारण के साथ आता है। movement ledger पर बनी पाइपलाइन ज्ञात नुकसान को residual से अलग करती है। robust statistics उस चरण और लॉट की ओर इशारा करते हैं जो बदला। language model आँकड़ों और सेलर के अपने नोट्स को ऐसे पैराग्राफ़ में बदलता है जिस पर कोई खुशी से हस्ताक्षर करे। इन तीन में से कोई भी कदम अनोखा नहीं है, और साथ मिलकर ये विंटेज के अंत के कंधे उचकाने को देखने लायक टैंकों की एक छोटी सूची में बदल देते हैं।

सीरीज़ में आगे: ग्राफ़ के रूप में लॉट genealogy, जहाँ वही ledger बताता है कि “किन बोतलों में ब्लॉक 7 है?”। Tableau में सेलर और बैरल का नज़रिया देखने के लिए बैरल-ageing डैशबोर्ड देखें। पूरी सूची Cellar Ledger सीरीज़ पेज पर है।

अक्सर पूछे जाने वाले सवाल

crush और बोतल के बीच एक वाइनरी कितनी वाइन खोती है? यह स्टाइल, प्रेस के तरीके, बैरल में समय और सेलर की नमी के साथ काफ़ी बदलता है, इसलिए किसी एक संख्या को सावधानी से लें। ज़्यादा काम का आँकड़ा आपका अपना है: दर्ज movements से निकाला गया प्रति लॉट प्रति चरण नुकसान, और उसके बाद बचा अनसमझा residual। पीछा करने लायक हिस्सा वही residual है।

वाइनरी के नुकसान वाले डेटा पर कौन सा anomaly detection काम करता है? यहाँ सरल, robust statistics आमतौर पर जटिल मॉडलों से बेहतर रहते हैं। किसी चरण पर हर लॉट की loss rate की तुलना उसी चरण और उसी तरह के बर्तन के median से करें, median absolute deviation से स्केल करें, और outliers को फ़्लैग करें। deep मॉडल के लिए डेटा शायद ही कभी काफ़ी होता है, और robust z-score को सेलर मास्टर हाथ से आसानी से जाँच सकता है।

क्या एक LLM मासिक loss variance रिपोर्ट लिख सकता है? ड्राफ़्ट बना सकता है, बशर्ते वह कभी गणना न करे। संख्याएँ SQL में निकालें, नतीजे और दर्ज adjustment कारण मॉडल को दें, और उससे उन तय आँकड़ों के इर्द-गिर्द टिप्पणी लिखवाएँ। कोई व्यक्ति समीक्षा करे और हस्ताक्षर करे। मॉडल एक टेबल और बीस कारण कोड को पढ़ने लायक पैराग्राफ़ में बदलने में अच्छा है, और गणित में कमज़ोर।