थोडक्यात उत्तर: 100 टन red फळ crush करणारी वायनरी कदाचित 72,000 litres press करेल आणि 63,500 bottle करेल. मधले 8,500 litres बहुतेक ज्ञात losses असतात: lees, racking, evaporation, filtration, bottling. महत्त्वाचा भाग म्हणजे यांचा हिशेब लावल्यानंतर जे उरते ते, म्हणजे unexplained residual. movement ledger वर medallion pipeline म्हणून loss map बांधा, भारी model ऐवजी robust statistics ने असामान्य टप्पे flag करा, आणि query results वरून LLM ला variance note चा मसुदा लिहू द्या. शब्द model लिहिते. बेरजा SQL करते.

LOSS MAP: 100 टन RED, CRUSH ते BOTTLE (उदाहरणादाखल) अक्ष 60,000 L पासून सुरू 72,000 −2,900 −1,100 −2,000 −400 −700 −500 −900 63,500 pressed gross lees racking barrelevaporation topping& samples filtration bottling अस्पष्ट bottled 7,600 L ज्ञात LOSS · 900 L ज्याचे कोणीही स्पष्टीकरण देऊ शकत नाही · गुलाबी BAR चा पाठलाग करा
हे उदाहरणादाखल आकडे आहेत, benchmarks नाहीत. तुमच्या स्वतःच्या ledger मधील तुमचे स्वतःचे टप्पे, एवढेच आकडे महत्त्वाचे.

प्रत्येक vintage च्या शेवटी कोणीतरी तोच प्रश्न विचारतो: आपण इतके press केले, तितके bottle केले, बाकीचे कुठे गेले? प्रामाणिक उत्तर सहसा खांदे उडवत दिले जाते: “lees, evaporation आणि बऱ्याच छोट्या गोष्टी”. त्या खांदे उडवण्यामागे दोन अगदी वेगळ्या प्रकारचे loss लपलेले असतात. बहुतेक भाग wine बनवण्याचा सामान्य खर्च असतो. एक छोटा तुकडा अशी wine असते जिचा वायनरी हिशेब देऊ शकत नाही, आणि पैसा, excise चे प्रश्न आणि प्रक्रियेतील समस्या नेमक्या त्याच तुकड्यात राहतात.

मागील पोस्ट ने movement ledger बांधला. ही पोस्ट त्याचे loss map करते, anomaly detection चा हलका थर जोडते, आणि मासिक लेखन आखूड दोरीवर LLM च्या हाती देते.

ज्ञात loss विरुद्ध अस्पष्ट loss

काही loss म्हणजे वायनरीने नोंदवलेल्या कारणासह स्वतःहून सोडलेली wine:

  • fermentation आणि पहिल्या racking नंतरचे gross lees, बहुतेकदा volume च्या काही टक्के.
  • wine गाळावरून हलवली जाते तेव्हा प्रत्येक वेळी होणारे racking losses.
  • barrel evaporation, जे cellar मधील आर्द्रता आणि तापमानावर मोठ्या प्रमाणात अवलंबून असते, आणि वर्षाला काही टक्के असते.
  • topping आणि samples, छोटे पण सततचे.
  • filtration आणि bottling, म्हणजे hoses, filters आणि filler bowl मधील dead volume.

बाकी सर्व म्हणजे residual: inputs, वजा outputs, वजा प्रत्येक नोंदवलेला loss. वरील उदाहरणादाखल vintage मध्ये 7,600 litres loss ला कारण आहे आणि 900 litres ला नाही. नऊशे litres तयार red म्हणजे हजारपेक्षा जास्त bottles. त्यासाठी एक दुपार खर्च करणे योग्य आहे.

residual कधीच शून्य नसतो. meters जुळत नाहीत, dips मध्ये त्रुटी असते, तापमान volumes इकडेतिकडे हलवते. ध्येय शून्य नाही. ध्येय असा residual आहे जो इतका छोटा आणि स्थिर असेल की तो उसळी घेतो तेव्हा तुमच्या लक्षात येईल.

pipeline: bronze, silver, gold

loss map ही analytics समस्या होण्याआधी data engineering समस्या आहे. medallion pattern तिला चांगला बसतो.

Bronze म्हणजे movement ledger स्वतः, जसा आहे तसा: प्रत्येक receive, transfer, rack, top, filter, bottle, observe आणि adjust event, volumes 20 degrees C वर दुरुस्त केलेले.

Silver प्रत्येक movement चे टप्पा आणि loss category मध्ये वर्गीकरण करते. 58 litres lees tank मध्ये पाठवणारा rack event “loss: gross lees, stage: post-ferment, lot 24-SH-03” बनतो. नंतर filter करून परत मिळवलेले lees recovery event म्हणून परत येतात, म्हणजे ते दोनदा loss म्हणून मोजले जात नाहीत. बहुतेक domain logic इथे राहते, आणि cellar master ने इथले नियम तपासावेत, कारण event type पासून loss category पर्यंतचे mapping म्हणजे प्रक्रियेबद्दलच्या मतांचा संच आहे.

Gold म्हणजे प्रत्येक lot, प्रत्येक टप्पा, प्रत्येक vintage साठी एक row: आत आलेले volume, बाहेर गेलेले volume, category नुसार ज्ञात loss, आणि residual. तोच waterfall, dashboard आणि, आपण पाहणार आहोत तसे, 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;

ही एक query आहे. खरे कष्ट silver मध्ये आहेत, categories बरोबर करण्यात.

anomaly flags: हेतुपुरस्सर कंटाळवाणी statistics

gold table तयार झाले की पुढची स्वाभाविक मागणी असते “समस्या शोधायला AI वापरा”. deep model कडे धाव घेण्याचा मोह टाळा. वायनरीकडे वर्षाला कदाचित काही शे lots आणि स्वच्छ इतिहासाच्या मोजक्या vintages असतात. काहीही गुंतागुंतीचे train करायला एवढा डेटा पुरेसा नाही, आणि cellar master ला flag हाताने तपासता आला पाहिजे.

robust z-score हे काम करतो:

  1. प्रत्येक टप्पा आणि vessel प्रकारासाठी (उदाहरणार्थ, 5,000 litre stainless मधून racking) सर्व lots मधील median loss rate घ्या.
  2. rates किती पसरलेले आहेत ते median absolute deviation ने मोजा, जे एखाद्या टोकाच्या मूल्याने ओढले न जाता त्याकडे दुर्लक्ष करते.
  3. ज्या lot चा loss rate median पासून साधारण तीन scaled deviations पेक्षा जास्त दूर आहे तो flag करा.

यामुळे racking मध्ये 4% गमावणारी ती एक tank flag होते जेव्हा तिच्या भावंडांनी 1.5% गमावले, आणि प्रत्येक tank ला लागू असलेल्या vintage-व्यापी बदलाकडे दुर्लक्ष होते. हे आकर्षक नाही. ते स्वतःचे स्पष्टीकरण एका वाक्यात देते, आणि ते जास्त महत्त्वाचे आहे.

barrel evaporation ला स्वतंत्र वागणूक हवी. ते barrel कुठे ठेवले आहे यावर अवलंबून असते, म्हणून तुम्ही नोंदवत असाल तर cellar zone आणि position नुसार गट करा. rackhouse microclimate पोस्ट हेच भौतिकशास्त्र whisky च्या बाजूने मांडते.

LLM variance note चा मसुदा लिहिते

दर महिन्याला कोणीतरी operations review साठी एक-दोन परिच्छेद लिहितो: या महिन्याचा loss, तुलना कशी आहे, काय घडले. त्याला एक तास लागतो आणि ते कंटाळवाणे असते. language model साठी हे चांगले काम आहे, जोपर्यंत तुम्ही अशी रचना करता की त्याला आकडे चुकवताच येणार नाहीत.

चालणारा pattern:

  1. प्रत्येक गणित SQL करते. gold table, महिन्या-दर-महिना बदल, flag झालेले lots, volume नुसार सर्वोच्च adjustment कारणे. model काहीही पाहण्याआधीच हे सगळे काढलेले असते.
  2. model ला निकाल structured input म्हणून मिळतात. आकड्यांचा छोटा JSON block, flag झालेल्या lots ची यादी, आणि operators नी adjustment events वर टाइप केलेली मुक्त मजकुरातील कारणे.
  3. model ठरलेल्या आकड्यांभोवती गद्य लिहिते. त्याला फक्त दिलेले आकडेच वापरायला आणि प्रत्येक दाव्यासाठी source row चे नाव द्यायला सांगा. त्याहूनही चांगले, त्याला placeholders सह note परत करायला लावा जे code JSON मधून भरतो, म्हणजे एकही आकडा model कधीच टाइप करत नाही.
  4. ते operators ची कारणे गटांत बांधते. “topping not logged”, “topped B-row, forgot”, “topping, missed” असे म्हणणाऱ्या वीस adjustment notes एक ओळ बनतात: “residual चा बहुतेक भाग B row मधील न नोंदवलेल्या barrel topping कडे जातो”. इथे model खरोखर आपली किंमत वसूल करते. ते गोंधळलेला मानवी मजकूर चांगला वाचते.
  5. एखादी व्यक्ती संपादन करून सही करते. note winemaker च्या नावाने जाते, model च्या नाही.

तुम्ही जे करू नये ते म्हणजे model ला raw ledger देऊन या महिन्यात काय चुकले असे विचारणे. ते मनातल्या मनात columns ची बेरीज करेल, आणि आत्मविश्वासाने काही शे litres ने चुकेल.

हे कुठे मोडते

residual प्रत्येक मापन त्रुटी शोषून घेतो. हळूहळू भरकटणारा flow meter अस्पष्ट loss म्हणून दिसतो. चुकीच्या तापमानाला वाचलेली dip stick सुद्धा. residual ला हरवलेली wine समजण्याआधी instruments तपासा.

silver नियम म्हणजे मते आहेत. lees wine loss मानायची की परत मिळवता येणारे उपउत्पादन, यामुळे map बदलतो. नियम लिहून ठेवा आणि cellar master कडून मंजूर करून घ्या, नाहीतर दोन माणसे तोच waterfall दोन प्रकारे वाचतील.

loss targets वर्तन बदलतात. लोकांचे मूल्यमापन गुलाबी bar वर झाले, तर गुलाबी bar इतर काहीतरी म्हणून नोंदवला जाऊन लहान होईल. map प्रक्रियेतील समस्या शोधण्यासाठी वापरा, cellar crew ला गुण देण्यासाठी नाही.

LLM शब्दांतून अजूनही दिशाभूल करू शकते. आकडे ठरलेले असले तरी model सामान्य महिन्याला समस्या म्हणून मांडू शकते किंवा खऱ्या समस्येकडे दुर्लक्ष करू शकते. म्हणूनच flags statistics मधून येतात आणि model फक्त त्यांचे वर्णन करते.

निष्कर्ष

प्रत्येक वायनरी wine गमावते. प्रश्न असा आहे की त्यातील किती loss कारणासह येतो. movement ledger वरचा pipeline ज्ञात loss आणि residual वेगळे करतो. robust statistics बदललेल्या टप्प्याकडे आणि lot कडे बोट दाखवतात. language model आकडे आणि cellar च्या स्वतःच्या notes वरून असा परिच्छेद तयार करते ज्यावर कोणीतरी आनंदाने सही करेल. या तीनपैकी एकही टप्पा विलक्षण नाही, आणि एकत्रितपणे ते vintage अखेरच्या खांदे उडवण्याला तपासायच्या tanks च्या छोट्या यादीत बदलतात.

मालिकेतील पुढील भाग: graph म्हणून lot genealogy, जिथे तोच ledger “कोणत्या bottles मध्ये block 7 आहे?” याचे उत्तर देतो. Tableau मधील cellar आणि barrel view साठी पाहा barrel-ageing dashboard. संपूर्ण यादी Cellar Ledger मालिकेच्या पानावर आहे.

वारंवार विचारले जाणारे प्रश्न

crush आणि bottle दरम्यान वायनरी किती wine गमावते? हे style, press पद्धत, barrel मधील वेळ आणि cellar मधील आर्द्रता यानुसार खूप बदलते, म्हणून कोणताही एक आकडा सावधपणे घ्या. अधिक उपयुक्त आकडा तुमचा स्वतःचा आहे: नोंदवलेल्या movements वरून काढलेला प्रत्येक lot चा प्रत्येक टप्प्यावरील loss, आणि त्यानंतर उरणारा unexplained residual. पाठलाग करण्यासारखा भाग तो residual आहे.

वायनरीच्या loss डेटासाठी कोणते anomaly detection चालते? इथे साध्या, robust statistics सहसा गुंतागुंतीच्या models पेक्षा सरस ठरतात. प्रत्येक lot चा एखाद्या टप्प्यावरील loss rate त्याच टप्प्याच्या आणि त्याच vessel प्रकाराच्या median शी, median absolute deviation ने scale करून तुलना करा, आणि outliers flag करा. deep model साठी पुरेसा डेटा क्वचितच असतो, आणि robust z-score cellar master हाताने सहज तपासू शकतो.

LLM मासिक loss variance report लिहू शकते का? ते मसुदा लिहू शकते, पण एकच अट: ते कधीच गणित करत नाही. आकडे SQL मध्ये काढा, निकाल आणि नोंदवलेली adjustment कारणे model ला द्या, आणि त्या ठरलेल्या आकड्यांभोवती त्याला टिप्पणी लिहू द्या. एखादी व्यक्ती आढावा घेऊन सही करते. table आणि वीस reason codes वाचनीय परिच्छेदांत बदलण्यात model चांगले आहे, आणि गणितात वाईट.