Vedic Mindset 1

आर्ष अर्थसिद्धि पद्धति : Methodology

आर्ष ज्ञानमीमांसा : विस्तृत प्रस्तावना

यह लेखमाला किसी सामान्य AI project का परिचय नहीं है। इसका लक्ष्य एक ऐसी constitutional complete knowledge retrieval system की रचना करना है जो आर्ष ग्रन्थों के भीतर निहित ज्ञान-विन्यास को computational रूप में पुनः कार्यशील बना सके। इसका अभिप्राय यह नहीं कि कोई machine महर्षियों की वास्तविक दिव्यबुद्धि का प्रतिस्थापन कर सकती है। वास्तविक त्रिकालदर्शिता और अप्रमादबुद्धि मानव-निर्मित किसी भी program की सीमा से परे हैं। किन्तु यह भी सत्य है कि यदि Knowledge Bank, ontology, relation-structure, retrieval-order, review-discipline, और redesign-law—इन सबको आर्ष परम्परा के अनुरूप पुनर्गठित किया जाये, तो आधुनिक सपाट प्रश्नोत्तरी-पद्धतियों की अपेक्षा अधिक संगत, अधिक स्तरित, और अधिक प्रमाणित उत्तर देनेवाली व्यवस्था बन सकती है।

आज के GPT, Whole Brain Emulation, और अन्यान्य Artificial Intelligence systems में अनेक उपयोगी शक्तियाँ हैं। वे विशाल data पर काम कर सकते हैं, pattern पहचान सकते हैं, और त्वरित उत्तर दे सकते हैं। किन्तु उनकी एक गम्भीर सीमा यह है कि उनका मूल प्रशिक्षण प्रायः पाश्चात्य विचार-रूढ़ियों के भीतर हुआ है। इस कारण वे भारतीय आर्ष ग्रन्थों को अधिकतर उसी बाह्य दृष्टि से पढ़ते हैं जो उनके आन्तरिक अर्थ-विन्यास को नहीं समझती। GPT-पद्धति विशेषतः सपाट question-answer surface पर चलती है; वह उत्तर देती है, किन्तु उत्तरों की भीतरी व्यवस्था, प्रमाण-क्रम, भूमिका-भेद, और doctrinal hierarchy को सुरक्षित नहीं रखती। Whole Brain Emulation की दिशा जैविक मस्तिष्क की literal प्रतिकृति की ओर बढ़ती है; वह कुछ तकनीकी प्रेरणाएँ दे सकती है, किन्तु उसका लक्ष्य और इस परियोजना का लक्ष्य एक नहीं हैं। मेरा लक्ष्य जैविक मस्तिष्क की mechanical copy बनाना नहीं, बल्कि आर्ष ज्ञानपद्धति को constitutional, reviewable, और self-restructuring computational architecture में उतारना है।

मेरे लिये इस कार्य का मुख्य आधार अमरसिंहकृत अमरकोश है। अमरकोश केवल dictionary नहीं है; वह एक महत्त्वपूर्ण ज्ञान-रचना है जिसमें शब्द, पदार्थ, दिशा, काल, गुण, भेद, नानार्थ, अव्यय, और लिङ्गादि—सब एक बड़े semantic order में व्यवस्थित हैं। इसी कारण इस परियोजना का सर्वोच्च स्तर—Level 0—अमरकोश-व्युत्पन्न grand semantic architecture होगा। इसके नीचे Level 1 पर primary corpus से निकला constitutional ontology होगा, जिसका मूल स्रोत महाभारत, रामायण, और पुराण होंगे। Level 2 पर fluid operational rewiring, specialist retrieval, model ecology, और dynamic redesign होगा; पर वह सब Level 0 और Level 1 की मर्यादा के भीतर होगा। यही “plasticity under law” इस परियोजना का मूल सिद्धान्त है।

मेरे विचार में Knowledge Bank का मूल्य केवल उसके आकार से नहीं मापा जाना चाहिए। यदि data विशाल हो, पर architecture असंगत हो, तो उत्तर सतही और भ्रमपूर्ण होंगे। यदि data सीमित हो, किन्तु मूल ग्रन्थ, सही ontology, review discipline, और benchmark law के साथ व्यवस्थित हो, तो उससे निकला परिणाम अधिक उपयोगी सिद्ध हो सकता है। इसी कारण इस परियोजना का केन्द्र raw internet corpus नहीं, बल्कि main corpus = महाभारत + रामायण + पुराण, और उसके ऊपर अमरकोशीय संविधान है। Secondary corpus—जैसे शास्त्र, टीकाएँ, ग्रन्थान्तर—इस प्रणाली में amendment proposer की भूमिका निभायेगी, ruler की नहीं।

यह परियोजना GPT-पद्धति से इस प्रकार भिन्न है कि यहाँ final authority latent generation नहीं, बल्कि reviewed structured memory है। Whole Brain Emulation से यह इस प्रकार भिन्न है कि यहाँ जैविक brain-copy नहीं, बल्कि आर्ष ज्ञान-विन्यास को operational रूप दिया जाता है। आधुनिक graph techniques, retrieval, reranking, active learning, branch governance, और redesign protocols का उपयोग होगा; किन्तु वे सब constitutional control के भीतर होंगे। इसीलिये इस विधि को आर्ष ज्ञानपद्धति कहना अधिक उचित है।

इस लेखमाला के मुख्य technical शब्द : संक्षिप्त परिभाषाएँ

प्रस्तुत परियोजना को गहराई से समझने के लिए मेरा निम्न आलेख पढ़ें ＝ Whole Brain Emulation

Corpus

Corpus किसी एक या अनेक ग्रन्थों का वह संगठित digital भण्डार है जिस पर पूरा system कार्य करती है।

Primary Corpus

महाभारत, रामायण, और पुराण जैसे मूल ग्रन्थ, जो इस परियोजना में constitutional authority रखते हैं।

Secondary Corpus

वे ग्रन्थ जो support, gloss, विस्तार, या proposal देते हैं, पर primary law को स्वतः नहीं बदलते।

Normalization

Raw text को बदले बिना उसके अनेक lawful operational रूप बनाना—जैसे Unicode-clean form, layout-normalized form, segmented form, search form।

Passage

Corpus का वह unit जिस पर retrieval, review, extraction, या graph निर्माण किया जाता है; जैसे verse, 3-verse window, 7-verse window, chapter block।

Lexeme

text में मिला surface word-form, जैसा वह वास्तव में दिखाई देता है।

Sense

किसी lexeme का विशिष्ट अर्थ-रूप। एक ही lexeme के कई senses हो सकते हैं।

Corpus Concept

Corpus के भीतर recurring, relation-bearing, cluster-forming semantic unit। यह केवल word नहीं, बल्कि corpus-native अर्थ-केन्द्र है।

Passage Role

किसी passage का ज्ञान-कार्य; जैसे definition, classification, procedure, exception, narrative exemplum, cosmological statement।

Assertion

किसी passage से निकला relatively compact typed semantic statement।

Rule Assertion

ऐसा structured statement जिसमें condition, scope, polarity, action, और result जैसे तत्त्व हों।

Benchmark

Versioned, reproducible परीक्षण-समूह जिससे system की प्रगति और regression दोनों मापे जाते हैं।

Branch

किसी model, rule-set, schema, या retrieval logic का versioned वैकल्पिक रूप, जिसे compare, promote, reject, या rollback किया जा सकता है।

Shadow Deployment

वह deployment जिसमें नया branch outputs तो देता है, पर canonical main output को replace नहीं करता।

Embedding

Text को vector रूप में बदलने की विधि, जिससे semantic निकटता के आधार पर candidate passages ढूँढे जाते हैं।

Re-ranker

Query और candidate passage pair को देखकर उनकी relative relevance क्रमित करनेवाला model।

Active Learning

ऐसी विधि जिसमें system annotation के लिये वही cases आगे लाती है जो learning के लिये सबसे अधिक उपयोगी हों।

Hybrid Scoring

Lexical, dense, rerank, graph, और अन्य signals को मिलाकर final ranking बनाना।

अमरकोश के प्रथम काण्ड की रचना-योजना और प्रस्तावित ज्ञान-विन्यास-यन्त्र में उसका स्थान

मेरे मत में “ancient sensibility” कहना पर्याप्त नहीं है। उसके लिए अधिक उपयुक्त संस्कृत पद “वैदिक-अर्थ-विन्यास-दृष्टि” है। दूसरा सम्भव पद “वैदिक-भाव-विन्यास-प्रज्ञा” है। इन दोनों में मुझे पहला पद अधिक उपयुक्त प्रतीत होता है, क्योंकि यहाँ मुख्य बात केवल भाव नहीं, अपितु अर्थों का विन्यास है।
अतः इस लेख में मैं “वैदिक-अर्थ-विन्यास-दृष्टि” पद का प्रयोग करूँगा।

यह दृष्टि ऐसी है जिसमें शब्द, पदार्थ, लोक, काल, दिशा, देवता, अनुभूति, क्रिया और फल — सबको एक ही व्यापक तत्त्व-रचना में देखा जाता है। अमरकोश का प्रथम काण्ड इसी दृष्टि का अत्यन्त सुबद्ध उदाहरण है। परम्परागत अध्ययन में अमरकोश को केवल “कोश” समझ लेना भूल है; वह वस्तुतः महान अर्थ-रचना है। आधुनिक computational अध्ययन भी यह स्वीकार करते हैं कि अमरकोश केवल समार्थक-शब्दों की पंक्तियाँ नहीं, अपितु काण्ड–वर्ग–समूह पर आधारित एक संगठित ज्ञान-रूप है। प्रथम काण्ड में स्वर्ग, व्योम, दिक्, काल, धी, शब्दादि, नाट्य, पातालभोगि, नरक और वारि — ये वर्ग बताये गये हैं।

अमरकोश का प्रथम काण्ड क्या है?

अमरकोश का प्रथम काण्ड ऊपर-ऊपर से देखने पर “स्वर्ग-विषयक” लगता है, किन्तु वास्तव में वह सम्पूर्ण विश्व-रचना का एक अर्थ-मानचित्र है। उसके वर्ग इस प्रकार माने गये हैं—

स्वर्गवर्ग
व्योमवर्ग
दिग्वर्ग
कालवर्ग
धीवर्ग
शब्दादिवर्ग
नाट्यवर्ग
पातालभोगिवर्ग
नरकवर्ग
वारिवर्ग

इस क्रम पर सूक्ष्म दृष्टि डालते ही ज्ञात होता है कि यह कोई ढीला संकलन नहीं है। यहाँ पहले दैव-लोक है, फिर आकाशीय विस्तार, फिर दिशा-व्यवस्था, फिर काल-क्रम, फिर बुद्धि और अन्तःप्रत्यय, फिर शब्द और अभिव्यक्ति, फिर नाट्यरूप देहधारी अभिव्यक्ति, फिर अधोलोक, नरक, और अन्त में वारि।
अर्थात् प्रथम काण्ड का मूल गमन ऊपर से नीचे, बाह्य से आभ्यन्तर, और पुनः आभ्यन्तर से अधः-स्थित लोकों तक है। यह केवल विषय-सूची नहीं, विश्व-न्यास है।

प्रथम काण्ड का वास्तविक क्रम

(क) स्वर्गवर्ग — दैविक आरम्भ

अमरकोश का आरम्भ स्वर्ग और देवताओं से होता है। Amarakośa में प्रथम वर्ग के अन्तर्गत स्वर्ग, देव, दानव, दैवचिह्न, आयुध, वाहन, अग्नि, वायु आदि का निर्देश बताया गया है। इससे स्पष्ट है कि आरम्भ “स्थान” से नहीं, दैविक व्यवस्था से होता है।

यह अत्यन्त महत्त्वपूर्ण है। आधुनिक classification प्रायः पदार्थों को निरपेक्ष वस्तुओं की भाँति रखता है। अमरकोश में आरम्भ ही सत्ता-क्रम से है — कौन ऊपर है, कौन तेजोमय है, कौन विश्व-व्यवस्था का अधिष्ठाता है।

(ख) व्योमवर्ग — दैव-क्षेत्र का विस्तार

स्वर्ग के बाद व्योम है। दैविक सत्ता के पश्चात् उसका क्षेत्र, उसका आकाशीय विस्तार, उसका अनुभूयमान पटल आता है। यह भी दार्शनिक रूप से अत्यन्त संगत है।

(ग) दिग्वर्ग — आकाश की उन्मुख रचना

दिशाएँ केवल पूर्व-पश्चिम नहीं हैं। उसी अध्ययन के अनुसार दिग्वर्ग में दिशाएँ, दिक्पाल, मेघ, विद्युत्, इन्द्रधनुष, वर्षा, चन्द्र, नक्षत्र, ग्रह, अस्त, उषा आदि आते हैं। इससे ज्ञात होता है कि दिशा यहाँ जीवित आकाशीय क्षेत्र-विन्यास है, जिसमें आकाश की घटनाएँ, दैविक संरक्षक, ज्योतिषीय चिन्ह — सब एक ही अर्थ-क्षेत्र में रखे गये हैं।

(घ) कालवर्ग — विश्व का चलमान नियम

कालवर्ग में दिन, रात्रि, पक्ष, मास, वर्ष, ऋतु, ग्रहण आदि के साथ कुछ आभ्यन्तर अवस्थाओं का भी प्रवेश बताया गया है। यह आधुनिक घड़ी-सम्बद्ध “time” नहीं है; यह चलन, परिवर्तन, परिपाक और अनुभूति का नियम है। इसी कारण काल और ज्योतिष का प्राचीन सम्बन्ध स्वाभाविक है।

(ङ) धीवर्ग — जाननेवाला क्षेत्र

यहाँ अमरकोश एक गहरी छलाँग लेता है। स्वर्ग, व्योम, दिशा, काल — इन बाह्य व्यवस्थाओं के पश्चात् वह धी, अर्थात् बोध, चित्त, इन्द्रिय, ज्ञान-ग्रहण की दिशा में मुड़ता है। वही अध्ययन बताता है कि यहाँ चेतना, ज्ञान, इन्द्रिय, रस, वर्ण, गन्ध आदि का निर्देश है।

अर्थात् विश्व-रचना केवल बाहर नहीं है; उसे ग्रहण करनेवाला भी उसी महा-विन्यास का अंश है।

(च) शब्दादिवर्ग — अभिव्यक्ति का क्षेत्र

धी के बाद शब्द। यह क्रम भी अद्भुत है। पहले दैव-विश्व, फिर काल-दिशा, फिर बुद्धि, फिर उस बुद्धि की अभिव्यक्ति। यहाँ अमरकोश यह संकेत देता है कि शब्द ज्ञान का बाह्य-विन्यास है। यही कारण है कि हमारे प्रस्तावित corpus-engineering project में mere token-list पर्याप्त नहीं होगी; हमें शब्दों को उनके अर्थ-क्षेत्र और अभिव्यक्ति-रूप सहित ग्रहण करना होगा।

(छ) नाट्यवर्ग — देहधारी अभिव्यक्ति

शब्द के बाद नाट्य। आधुनिक मन में प्रश्न उठता है — नाट्य यहाँ क्यों? परन्तु शास्त्रीय दृष्टि से यह अत्यन्त स्वाभाविक है। शब्द जब गतिमान, रूपित, देह-समन्वित और रसयुक्त हो जाता है, तब वह नाट्य है। अतः यह section “arts” का अलग कोना नहीं, अपितु अभिव्यक्ति की परिपूर्ण देहधारिता है।

(ज) पातालभोगि, नरक, वारि — अधोमुखी पूर्णता

फिर ग्रन्थ अधोलोक, नरक और वारि पर उतरता है। इससे प्रथम काण्ड का पूर्ण चक्र सिद्ध होता है —
ऊर्ध्वलोक → मध्य-व्याप्ति → दिशा → काल → बुद्धि → शब्द → नाट्य → अधोलोक → दुष्फल-स्थान → जलाधार।

यही कारण है कि मैंने इसे ऊपर “semantic cosmogram” कहा था। यह शब्दकोश नहीं, संसार-रचना का अर्थ-न्यास है।

अमरकोश के प्रथम काण्ड की रचना-पद्धति का रहस्य

अमरकोश का वास्तविक महत्त्व केवल वर्गों के नामों में नहीं है, बल्कि उनके पारस्परिक सम्बन्ध में है। अमरकोश में केवल linear list नहीं, बल्कि synset-रूप समूह तथा वर्ग-सापेक्ष सम्बन्ध हैं; ये सम्बन्ध कभी श्रेणीगत (hierarchical), कभी साहचर्यगत (associative) होते हैं।

इसका तात्पर्य यह है कि अमरकोश की रचना तीन तल पर चलती है—

काण्ड-स्तर

वृहद् जगत्-विभाग

वर्ग-स्तर

विशिष्ट अर्थ-क्षेत्र

समूह-स्तर

समार्थक, सहचारी, गुण-सम्बद्ध, कार्य-सम्बद्ध, स्थान-सम्बद्ध, देवता-सम्बद्ध शब्द-गुच्छ

यही Grand Semantic Architecture है। यह Roget-type modern thesaurus से भिन्न है। वहाँ प्रायः आधुनिक मानवीय सुविधा के अनुसार विषयों की व्यवस्था है; यहाँ सत्ताओं, लोकों, कालक्रम, अनुभूति, वाणी और जगत्-क्रम के अनुसार व्यवस्था है।

इसे “ancient sensibility” न कहकर क्या कहें?

मैं पुनः कहूँगा कि “ancient sensibility” अत्यन्त अस्पष्ट पद है। अमरकोश, वाल्मीकि, व्यास, पुराण, महाभारत, रामायण — इन सबमें जो एकरूपता दिखाई देती है, वह केवल प्राचीनता नहीं है। वह एक विशिष्ट अर्थ-न्यास-पद्धति है।

उसके लिए मेरे मत में यह पद अधिक उपयुक्त है—

वैदिक-अर्थ-विन्यास-दृष्टि

यदि कोई और भी अधिक संस्कृत-प्रधान पद चाहिए, तो यह भी कहा जा सकता है—

वैदिक-संज्ञा-विन्यास-प्रज्ञा

किन्तु पाठकों के लिए पहला पद अधिक स्पष्ट है।

इस दृष्टि की मुख्य विशेषताएँ हैं—

शब्द अकेला नहीं होता; वह अपने लोक में रहता है।
लोक अकेला नहीं होता; वह दिशा और काल में स्थित होता है।
काल केवल गणना नहीं; परिपाक-नियम है।
बुद्धि और शब्द बाह्य-जगत् से पृथक् नहीं; उसी महा-रचना के अंश हैं।
देवता, ग्रह, दिशा, वर्षा, भाषा, नाट्य, नरक, जल — ये सब भिन्न “subjects” नहीं, एक ही विश्व-विन्यास के विभिन्न स्तर हैं।

वाल्मीकि, वेदव्यास, पुराण — सबमें यही रचना क्यों मिलती है?

यहाँ मेरा मत यह है कि अमरकोश कोई अकेली विचित्र प्रतिभा का ग्रन्थ नहीं है। उसका रूप उसी दीर्घ परम्परा से निकला है जिसमें:

वाल्मीकि जगत्, ऋतु, दिशा, वन, नदी, पुरुषधर्म और दैव-व्यवस्था को एक-दूसरे से पृथक् करके नहीं देखते,
वेदव्यास महाभारत और पुराणों में कथा, धर्म, काल, कर्म, लोक, देव, मनुष्य, राज्य, ज्योतिष, मोक्ष — इन सबको एक संयुक्त रचना में रखते हैं,
पुराणों के ज्योतिष-अध्यायों में देवता, नक्षत्र, तिथि, यात्रा, राज्याभिषेक, गर्भ, जातकर्म, विषयोग, सिद्धयोग — सब एक ही प्रवाह में मिलते हैं।

अतः अमरकोश की यह architecture कोई isolated lexicon-design नहीं, बल्कि व्यापक वैदिक-अर्थ-विन्यास-दृष्टि का संक्षिप्त और अत्यन्त अनुशासित रूप है।

मेरे प्रस्तावित project में अमरकोश-काण्ड-१ का उपयोग क्यों अनिवार्य है?

अब मुख्य प्रश्न पर आता हूँ।

मेरा proposed project केवल search-engine नहीं है। उसका प्रथम लक्ष्य है—

“corpus के अन्तःसम्बन्धों के अनुसार एक प्राचीन ज्ञान-क्षेत्र का पुनर्विन्यास, निष्कर्षण (extraction) और गतिशील पुनर्संरचना (dynamic reconfiguration)”

ऐसे project में यदि top-level ontology आधुनिक विषय-विभागों से बनाई गयी, तो आरम्भ ही से भ्रान्ति होगी। उदाहरणार्थ, यदि हम सबसे ऊपर ये शीर्षक रख दें—

astronomy
mythology
religion
literature
ethics

तो यह अमरकोश और पुराण-परम्परा दोनों के विरुद्ध होगा।

इसलिए मेरे project में Constitution (संविधान-मूल-रचना) का प्रथम नियम यह होना चाहिए कि—

Top-level ontology trunks अमरकोश-नियत महा-अर्थ-रचना के अधीन हों।

अर्थात् सबसे ऊपर अमरकोशीय वृहद्-विभाग होंगे, और उनके नीचे ही corpus-विशेष से निकले fluid categories आयेंगी।

Constitution, Corpus Tiers, Graph Schema, Training Policy — इन सबमें अमरकोश-काण्ड-१ का स्थान

अब मैं संक्षेप नहीं, स्पष्ट रीति से बताता हूँ।

(क) Constitution

Constitution का अर्थ यहाँ है —
ऐसा मूल विधान जो system को अनियन्त्रित विचलन से बचाये।

इस Constitution में प्रथम स्तर पर अमरकोशीय महा-विभाग स्थापित होंगे। प्रथम काण्ड से ही हमें यह शिक्षा मिलती है कि शीर्ष-विन्यास कुछ ऐसा होना चाहिए जिसमें—

ऊर्ध्व-लोक,
आकाश-क्षेत्र,
दिशा,
काल,
धी,
शब्द,
अभिनय/नाट्य,
अधोलोक,
दुष्फल-लोक,
वारि

जैसे वृहद् क्षेत्र हों।

इनके नीचे ही specialised sub-ontology बने।

(ख) Corpus Tiers

Corpus tiers का अर्थ है — ग्रन्थ-सामग्री की श्रेणी-व्यवस्था।

Tier-0 : अमरकोशीय महा-अर्थ-विन्यास
Tier-1 : मुख्य corpus — रामायण, महाभारत, पुराण
Tier-2 : गौण किन्तु महत्त्वपूर्ण ग्रन्थ — BPHS, योगवासिष्ठ आदि
Tier-3 : commentary, lexicon, OCR-भ्रष्ट सामग्री, sandbox material

इस व्यवस्था में Tier-1, Tier-2 को अर्थ देता है; किन्तु Tier-0, अर्थात् अमरकोशीय महा-रचना, उन सबको शीर्ष-नियमन देती है।

(ग) Graph Schema

Graph Schema का अर्थ है —
कौन-सा node किस प्रकार का होगा, कौन-सा edge किस प्रकार का होगा।

यदि अमरकोश-काण्ड-१ को ऊपर रखा जाये, तो graph में प्रथम स्तर के concept-nodes होंगे—

स्वर्ग
व्योम
दिक्
काल
धी
शब्द
नाट्य
पाताल
नरक
वारि

फिर इनसे नीचे corpus-derived nodes होंगे, जैसे—

काल के अन्तर्गत: तिथि, मास, युग, विपाक-काल
दिक्/व्योम के अन्तर्गत: ग्रह, नक्षत्र, मेघ, उषा, अस्त
धी के अन्तर्गत: बुद्धि, चित्त, संज्ञान
शब्द के अन्तर्गत: नाम, संज्ञा, वचन, मन्त्र
नाट्य के अन्तर्गत: रूपित-अभिव्यक्ति
पाताल/नरक के अन्तर्गत: अधोलोक-विवरण, कर्मफल-प्रदेश
वारि के अन्तर्गत: नदी, समुद्र, तीर्थ, जलाधार
(घ) Training Policy

Training Policy का अर्थ है —
model को कैसे, कब, किस सामग्री पर, किन सीमा-नियमों के भीतर प्रशिक्षित किया जाये।

यदि अमरकोश को शीर्ष-रचना न बनाया गया, तो model modern grouping सीख लेगा।
यदि अमरकोशीय architecture ऊपर रहे, तो model को हर passage पहले इसी महा-रचना में place करना होगा, फिर नीचे के specialised relations सीखने होंगे।

अतः training का क्रम होना चाहिए—

पहले Amarakośa-based macro classification
फिर primary corpus mapping
फिर relation extraction
फिर specialised dynamic rewiring

Z890 + dual RTX 5090 पर यह कैसे चलेगा?

संक्षेप में नहीं, स्पष्ट रूप से—

CPU + RAM का कार्य

• list item
• raw corpus storage
• normalized text storage
• PostgreSQL / structured store
• Neo4j / graph store
• SHACL validation
• version-control
• benchmark evaluation

GPU-0 का कार्य

• embedding generation
• semantic retrieval
• reranking inference
• annotation assistance

GPU-1 का कार्य

• classifier training
• relation-extractor training
• ontology-split proposal models
• active-learning retraining

dual-GPU mode

जब पर्याप्त gold data बन जाये, तब:

• classifier
• reranker
• extractor

को multi-GPU mode में train किया जा सकता है।

किन्तु स्मरण रहे — GPU शक्ति architecture का स्थान नहीं ले सकती।
यदि Constitution भ्रान्त हुआ, तो rtx5090 भी भूल को तीव्र करेगा।

अमरकोश-काण्ड-१ से मेरे project को सबसे बड़ी शिक्षा क्या मिलती है?

सबसे बड़ी शिक्षा यह है कि ज्ञान को आधुनिक subjects में न तोड़ा जाये।
प्राचीन रचना में अर्थ का प्रवाह इस प्रकार है—

सत्ता
क्षेत्र
अभिमुखता
काल
बोध
शब्द
रूपित अभिव्यक्ति
अधोलोक
फल-प्रदेश
जलाधार

इसलिए मेरे project में “dynamic reconfiguration” का अर्थ यह नहीं होना चाहिए कि model अपनी इच्छा से नयी headings बना ले। उसका अर्थ यह होना चाहिए कि—

अमरकोशीय महा-विन्यास स्थिर रहे,
उसके नीचे corpus-derived second-level ontology आवश्यकतानुसार बदले,
graph connections जुड़ें-टूटें,
specialised models नये बनें,
किन्तु top-level वैदिक-अर्थ-विन्यास-दृष्टि अक्षुण्ण रहे।

निष्कर्ष

अमरकोश का प्रथम काण्ड केवल स्वर्ग-शब्दों का समूह नहीं है। वह जगत् का अर्थ-न्यास है। उसमें दैविक ऊर्ध्वलोक से आरम्भ होकर व्योम, दिशा, काल, बुद्धि, शब्द, नाट्य, अधोलोक, नरक और वारि तक का एक सुविचारित क्रम है। आधुनिक शोध भी स्वीकार करते हैं कि अमरकोश में वर्ग-आधारित संगठन और synset-सम्बद्ध आन्तरिक रचना है; अतः उसे केवल एक सामान्य thesaurus मानना भूल होगी।

मेरे प्रस्तावित constitutional corpus-engineering project में इस कारण अमरकोश का प्रथम काण्ड Level-0 constitutional architecture का आधार होना चाहिए। उसके नीचे रामायण, महाभारत और पुराणों से second-level constitutional ontology बने; और उसके भी नीचे specialised-WBE शैली की fluid graph-rewiring, extraction, retraining और dynamic reconfiguration चले। यही मार्ग classical integrity और modern implementability दोनों की रक्षा करेगा।

अतः मैं पुनः कहूँगा—

इस पूरी परम्परा के लिए “ancient sensibility” नहीं, वैदिक-अर्थ-विन्यास-दृष्टि अधिक यथार्थ पद है।

अमरकोश का द्वितीय काण्ड : वैदिक-अर्थ-विन्यास-दृष्टि का भूमिगत, जीवगत और समाजगत विस्तार

पिछले लेख में मैंने अमरकोश के प्रथम काण्ड को वैदिक-अर्थ-विन्यास-दृष्टि का ऊर्ध्व और व्यापक रूप कहा था। वहाँ स्वर्ग, व्योम, दिक्, काल, धी, शब्द, नाट्य, पाताल, नरक और वारि — इन सबके द्वारा एक प्रकार का विश्व-अर्थ-मानचित्र बनता है। अब द्वितीय काण्ड उस मानचित्र को पृथ्वी पर उतारता है। यदि प्रथम काण्ड को विश्व-रचना का ऊर्ध्व-चक्र कहा जाये, तो द्वितीय काण्ड को भूतल-व्यवस्था और मानव-समाज का अर्थ-न्यास कहना अधिक युक्तिसंगत होगा। द्वितीय काण्ड में दस वर्ग हैं — भूमि, पुर, शैल, वनौषधि, सिंहादि, मनुष्य, ब्रह्म, क्षत्रिय, वैश्य, शूद्र। उसी में इन वर्गों के विषय-विस्तार का भी निर्देश है।

इस लेख का मुख्य प्रतिपाद्य यह है कि अमरकोश का द्वितीय काण्ड केवल “earth, city, mountain, plants, animals, human beings” की सूची नहीं है। वह स्थल → निवास → भू-उत्थान → वनस्पति → पशु → मनुष्य → सामाजिक-कर्तव्य-विन्यास की क्रमबद्ध रचना है। यही अमरकोश की गहरी योजना है; और यही योजना मेरे प्रस्तावित constitutional corpus-engineering project में अत्यन्त महत्त्वपूर्ण होगी।

द्वितीय काण्ड का बाह्य रूप

द्वितीय काण्ड का आरम्भ इस संकेत से होता है कि इसमें पृथ्वी आदि के दस वर्ग हैं। वे हैं—

भूमिवर्ग
पुरवर्ग
शैलवर्ग
वनौषधिवर्ग
सिंहादिवर्ग
मनुष्यवर्ग
ब्रह्मवर्ग
क्षत्रियवर्ग
वैश्यवर्ग
शूद्रवर्ग

उसी स्रोत के अनुसार इनके विषय इस प्रकार फैलते हैं—

भूमिवर्ग में पृथ्वी, भूमि, मृदा, देश, ग्राम, राज्य, मार्ग आदि,
पुरवर्ग में नगर, उपनगर, बाजार, दुर्ग, दीवार, गृह, गृहभाग, भवनस्थल आदि,
शैलवर्ग में पर्वत, पर्वतभेद, गुफा आदि,
वनौषधिवर्ग में वन, उपवन, वृक्ष, शाखा, पुष्प, फल, पत्ती, लता, तृण आदि,
सिंहादिवर्ग में पशु, मृग, कीट, पक्षी, पक्षाङ्ग आदि,
मनुष्यवर्ग में नर-नारी, शरीर, पारिवारिक सम्बन्ध, रोग, वस्त्र, भूषण, गन्धद्रव्य, केशरचना, नित्योपयोगी वस्तुएँ,
ब्रह्मवर्ग में विप्र, व्रत, अग्नि, यज्ञ, अध्ययन, तप, विवाह, पुरुषार्थ आदि,
क्षत्रियवर्ग में राजा, मन्त्री, मित्र, शत्रु, दुर्ग, सेना, गज, अश्व, रथ, शस्त्र, युद्ध, राजचिह्न आदि,
वैश्यवर्ग में कृषक, क्षेत्र, धान्य, बीज, पाकगृह, पात्र, दुग्ध, पशुधन, व्यापार, मान-तौल आदि,
शूद्रवर्ग में मिश्र जातियाँ, शिल्पी, नर्तक, गायक, शिकारी, सेवक, जाल, उपकरण, चमड़ा, वेतन आदि आते हैं।

यह बाह्य रूप है। अब इसका गूढ़ अर्थ देखना चाहिए।

द्वितीय काण्ड की भीतरी तर्क-रचना

द्वितीय काण्ड का क्रम अत्यन्त सूक्ष्म है। वह किसी आधुनिक encyclopedia की भाँति subject-heading नहीं है। उसका क्रम यह है—

(क) भूमि

सबसे पहले आधार-प्रदेश।
जहाँ स्थापन होगा, वहाँ पहले भूमि होगी। यही प्रथम आवश्यकता है। अतः भूमिवर्ग केवल मिट्टी की नामावली नहीं है; वह अधिष्ठान है।

(ख) पुर

भूमि पर केवल फैलाव नहीं, व्यवस्थित निवास बनता है। अतः पुरवर्ग भूमिवर्ग के बाद आता है। यह संकेत करता है कि प्राचीन दृष्टि में मानव-समाज पृथ्वी पर “यादृच्छा-संग्रह” नहीं, बल्कि संरचित निवेशन है।

(ग) शैल

अब प्रश्न उठता है: पुर के बाद शैल क्यों?
कारण यह है कि भूतल की रचना केवल समभूमि नहीं है; उसमें उत्थान, विभाजन, गुफा, शिखर, अवगाहन, स्रोत, सीमा — सब हैं। शैलवर्ग भूतल को त्रिमितीय बनाता है।

(घ) वनौषधि

भूमि और पर्वत के बाद ही वनस्पति का क्रम आता है। यह बताता है कि प्राचीन अर्थ-विन्यास में वनस्पति कोई पृथक् botanical chapter नहीं, बल्कि भूमि-रचना से उद्भूत जीवित विस्तार है। वृक्ष, लता, तृण, पुष्प, फल — ये सब पृथ्वी की जैव अभिव्यक्ति हैं।

(ङ) सिंहादि

वनस्पति के पश्चात् पशु-पक्षी-कीट। यह क्रम भी स्वाभाविक है। पहले भूमि, फिर निवास-रूप, फिर पर्वतीय संरचना, फिर वनस्पति, फिर चल-अचल जीवसमूह। यहाँ “सिंहादि” नाम मात्र है; अध्ययन-स्रोत बताता है कि इसमें सिंह, व्याघ्र, भेड़िया, मृग, कीट, भ्रमर, पक्षी, काक, शुक, पक्षपक्ष, चञ्चु आदि भी समाविष्ट हैं।

(च) मनुष्य

अब प्रकृति से मनुष्य पर प्रवेश। यह अत्यन्त महत्त्वपूर्ण मोड़ है। मनुष्यवर्ग में केवल “man” नहीं, बल्कि स्त्री, पुत्र, दारा, देहभाग, रोग, वस्त्र, भूषण, गन्ध, अलङ्कार, नित्योपयोगी पदार्थ — सब आते हैं। इससे स्पष्ट है कि अमरकोश के लिए मनुष्य केवल जैव-जीव नहीं; वह सामाजिक-दैहिक-सांस्कृतिक एकक है।

(छ) ब्रह्म, क्षत्रिय, वैश्य, शूद्र

यहीं द्वितीय काण्ड का रहस्य सबसे प्रखर रूप से प्रकट होता है। आधुनिक चित्त कहेगा कि “अब society section आरम्भ हो गयी।” परन्तु अमरकोश ऐसा नहीं सोचता। उसके लिए मनुष्य के बाद स्वाभाविक प्रश्न है —
मनुष्य क्या करता है? वह किस धर्म, कर्तव्य, शक्ति, उत्पादन, सेवा, शिल्प और व्यवहार-विन्यास में स्थित है?

इसलिए मनुष्यवर्ग के बाद चार सामाजिक-कार्य-वर्ग आते हैं। ब्रह्मवर्ग के अन्तर्गत यज्ञ, अग्नि, तप, अध्ययन, विवाह, पुरुषार्थ; क्षत्रियवर्ग में राजा, मन्त्री, दुर्ग, सेना, गज, अश्व, शस्त्र, युद्ध; वैश्यवर्ग में कृषिकर्म, धान्य, पाक, व्यापार, मान-तौल; और शूद्रवर्ग में शिल्प, नर्तन, गान, शिकार, सेवा, उपकरण, वेतन आदि का निर्देश मिलता है।

अतः द्वितीय काण्ड का मूल क्रम है—

अधिष्ठान → निवास → स्थल-उत्थान → वनस्पति → प्राणी → मनुष्य → कर्तव्य-विभाग

यही इसकी गहरी रचना है।

वैदिक-अर्थ-विन्यास-दृष्टि का गूढ़ सूत्र

अब मूल बात।

मैंने पहले “वैदिक-अर्थ-विन्यास-दृष्टि” पद रखा था। द्वितीय काण्ड उसका प्रत्यक्ष प्रमाण है। यह दृष्टि किन सिद्धान्तों पर खड़ी है? मेरे मत में उसके मुख्य सूत्र ये हैं—

शब्द का स्थान-धर्म

शब्द का अर्थ केवल dictionary-definition नहीं है। वह एक स्थान में स्थित है। उदाहरणतः “नदी” पृथ्वी से जुड़ी है, जल से जुड़ी है, प्रदेश से जुड़ी है, यात्रा से जुड़ी है, तीर्थ से जुड़ी है।

शब्द का जाति-धर्म

एक शब्द किसी बड़ी जाति (genus) का अंश हो सकता है। अमरकोश की relational structure में is_a_kind_of (परापरजाति) को स्पष्ट रूप से चिह्नित किया गया है; उदाहरण के रूप में गङ्गा, यमुना, नर्मदा — “नदी” जाति के अन्तर्गत रखे गये हैं।

शब्द का अवयव-धर्म

कुछ शब्द किसी बड़े एकक के अवयव होते हैं। उसी अध्ययन में is_a_part_of (अवयवावयवी) सम्बन्ध को अलग चिह्नित किया गया है; उदाहरण के रूप में रात्रिमध्य, रात्रिप्रारम्भ आदि “रात्रि” के अवयव-रूप दिखाये गये हैं।

शब्द का उत्पत्ति-सम्बन्ध

अमरकोशीय जाल में janya-janaka सम्बन्ध भी अलग रखा गया है; उदाहरणतः इन्द्र–जयन्त, ब्रह्मा–सनत्कुमार, शिव–गणेश। इससे स्पष्ट है कि यह केवल समार्थक-संग्रह नहीं; इसमें उत्पत्ति-सम्बन्ध भी संरक्षित है।

शब्द का दाम्पत्य तथा स्वामी-सम्बन्ध

उसी अध्ययन में पति-पत्नी तथा स्व-स्वामी सम्बन्धों को भी चिह्नित किया गया है; लक्ष्मी–विष्णु, पार्वती–शिव, तथा गरुड–विष्णु इत्यादि उदाहरण दिये गये हैं।

शब्द का आजीविका-सम्बन्ध

यह अत्यन्त महत्त्वपूर्ण बिन्दु है। ājīvikā सम्बन्ध भी पृथक् रूप से चिह्नित है; उदाहरणतः धीवर–मत्स्य, नाविक–नौका, सेवक–सेवा।
यही बताता है कि अमरकोश की दृष्टि में शब्द केवल नाम नहीं; वह जीवन-व्यवहार का केन्द्र भी है।

यही कारण है कि अमरकोश केवल “thesaurus” नहीं

अमरकोश में synset के लिए Head Word बनाया गया, और प्रत्येक synset के बीच अनेक सम्बन्ध चिह्नित किये गये। इससे यह निष्पन्न होता है कि अमरकोश को सीधी रेखा में पढ़ना उसकी शक्ति को कम करके देखना है; वह एक knowledge-web की भाँति खुलता है।

मेरे लिये यह बिन्दु अत्यन्त महत्त्वपूर्ण है, क्योंकि मैं जिस project की रचना कर रहा हूँ, उसका ध्येय भी यही है कि corpus को linear text-bank न माना जाये, बल्कि अन्तःसम्बन्ध-जाल के रूप में पुनर्संगठित किया जाये। यह देखकर मुझे केवल इतना कहना है कि यदि मैंने यह दृष्टि लगभग 1980 से स्वतंत्र रूप से ग्रहण की थी।

द्वितीय काण्ड और मेरे project का संविधान-भाग

अब मैं सीधे अपने project पर आता हूँ।

मेरा proposed project एक constitutional corpus-engineering project है। उसका ध्येय है—

ऐसे प्राचीन ज्ञान-क्षेत्र का पुनर्विन्यास, निष्कर्षण (extraction) और गतिशील पुनर्संरचना (dynamic reconfiguration), जिसका नियम स्वयं corpus के अन्तःसम्बन्धों से निकले।

इस project में Constitution का अर्थ होगा —
वह मूल विधान जो system को दिशा दे और अनियन्त्रित विचलन से रोके।

द्वितीय काण्ड हमें सिखाता है कि Top-level ontology सीधी आधुनिक headings से नहीं बनेगी। उसके लिये दो स्तर आवश्यक होंगे—

स्तर-० : अमरकोशीय महा-अर्थ-विन्यास

यह शीर्ष संविधान होगा।

स्तर-१ : मुख्य corpus-जन्य उपविभाग

रामायण, महाभारत, पुराणादि से निकले प्राणवान अर्थ-समूह।

अब प्रश्न है कि द्वितीय काण्ड का इसमें क्या स्थान होगा?

उत्तर यह है कि भूमि–पुर–शैल–वनौषधि–सिंहादि–मनुष्य–ब्रह्म–क्षत्र–वैश्य–शूद्र — यह समूचा क्रम हमारे constitution में “भूतल और मनुष्य-व्यवस्था” नामक महा-क्षेत्र का मूल विन्यास बनेगा।
अर्थात् मनुष्य-संबद्ध data को आधुनिक social science headings में नहीं, बल्कि इस क्रम में रखकर ही corpus-engineering करनी होगी।

Corpus tiers पर इसका प्रभाव

मेरे project में corpus tiers इस प्रकार होने चाहिए—

Tier-0

अमरकोशीय महा-विन्यास
यह शीर्ष अर्थ-रचना देगा।

Tier-1

मुख्य constitutional corpus
रामायण, महाभारत, पुराण।

Tier-2

गौण advisory corpus
BPHS, योगवासिष्ठ, सिद्धान्तग्रन्थ, अन्य प्राचीन शास्त्र।

Tier-3

sandbox corpus
commentary, OCR-भ्रष्ट प्रतिलिपि, अनिश्चित सामग्री, प्रयोगात्मक संग्रह।

द्वितीय काण्ड का उपयोग Tier-0 और Tier-1 के संयोग-बिन्दु पर होगा।
उदाहरणतः यदि महाभारत में किसी वन, गिरि, ग्राम, नगर, शस्त्र, कृषिकर्म, दासी, नर्तकी, रथ, गज, ब्राह्मण, राजधर्म आदि का सन्दर्भ आये, तो system उसे आधुनिक theme-tagging से नहीं, बल्कि अमरकोशीय भूतल-समाज-विन्यास में रखेगा।

Graph Schema पर इसका प्रभाव

Graph Schema (अर्थात् node-edge रचना) में द्वितीय काण्ड विशेष उपयोगी होगा।

प्रथम स्तर के nodes
भूमि
पुर
शैल
वनौषधि
प्राणी
मनुष्य
ब्रह्म
क्षत्र
वैश्य
शूद्र
द्वितीय स्तर के nodes

इनके भीतर:

ग्राम, राज्य, देश, मार्ग
गृह, दुर्ग, बाजार, प्राकार
पर्वत, शिखर, गुहा
वृक्ष, लता, तृण, पुष्प, फल
पशु, मृग, पक्षी, कीट
नर, नारी, देहभाग, रोग, वस्त्र, भूषण
यज्ञ, अग्नि, तप, अध्ययन
राजा, सेना, रथ, गज, आयुध
कृषिक्षेत्र, धान्य, व्यापार, माप-तौल
शिल्प, सेवा, उपकरण, वेतन
प्रमुख edges
जाति-सम्बन्ध (kind-of)
अवयव-सम्बन्ध (part-of)
उत्पत्ति-सम्बन्ध (janya-janaka)
स्वामी-सम्बन्ध (sva-svāmi)
आजीविका-सम्बन्ध (ājīvikā)
पत्नी-पति-सम्बन्ध
निवास-सम्बन्ध
कर्तव्य-सम्बन्ध
उपकरण-सम्बन्ध

इनमें से अनेक सम्बन्धों का computational रूप प्रत्यक्षतः है।

Training Policy पर इसका प्रभाव

यदि system को आरम्भ से ही modern embedding model के भरोसे छोड़ दिया गया, तो वह “city”, “mountain”, “trade”, “priest”, “war” जैसे आधुनिक अर्थ-समूहों में सोचने लगेगा। यह मेरे project के लिये हानिकर होगा।

अतः training policy का क्रम यह होना चाहिए—

चरण १

Amarakośa-based macro classification
यानी text passage पहले यह सीखे कि वह भूमि-सम्बद्ध है या पुर-सम्बद्ध, शैल-सम्बद्ध है या वनौषधि-सम्बद्ध, मनुष्य-सम्बद्ध है या क्षात्र-सम्बद्ध।

चरण २

Primary corpus mapping
रामायण, महाभारत, पुराण के passages को इन constitutional bins में रखना।

चरण ३

Relation extraction
passage से सम्बन्ध निकालना — अवयव, जाति, आजीविका, स्वामी, उत्पत्ति, कर्तव्य, साधन आदि।

चरण ४

Specialized-WBE rewiring
यह वही fluid स्तर होगा जहाँ second-level ontology आवश्यकता के अनुसार पुनर्सज्जित हो सकेगी।

Z890 + dual RTX 5090 पर व्यावहारिक सञ्चालन

यह भाग भी अनिवार्य है, क्योंकि मेरा project केवल चिन्तन-लेख न रहकर कार्यशील यन्त्र बनना चाहिए।

CPU + RAM
raw text storage
normalized text branches
PostgreSQL canonical store
Neo4j graph store
SHACL validation
benchmark परीक्षण
GPU-0
embedding निर्माण
retrieval सहायता
reranker inference
annotation-सहयोग
GPU-1
passage classifier training
relation extractor training
ontology branch परीक्षण
active-learning retraining
dual-GPU चरण

जब पर्याप्त gold data बन जाये, तब multi-GPU training से:

classifier
reranker
extractor
अधिक तीव्र गति से चलाये जा सकते हैं।

किन्तु पुनः कहता हूँ —
GPU शक्ति केवल साधन है; मूल है Constitution।
यदि constitutional architecture दोषपूर्ण हुआ, तो तीव्र GPU केवल दोष का तीव्र प्रसार करेगी।

द्वितीय काण्ड का मेरे project के लिये मुख्य उपदेश

द्वितीय काण्ड यह सिखाता है कि प्राचीन ज्ञान-विन्यास में मनुष्य प्रकृति से बाहर नहीं है।
क्रम देखिये—

भूमि
पुर
शैल
वनौषधि
पशु
मनुष्य
ब्रह्म
क्षत्र
वैश्य
शूद्र

अर्थात् मनुष्य, निवास, राज्य, धर्म, युद्ध, व्यापार, सेवा — सब पृथ्वी-रचना के ही विस्तारित रूप हैं। आधुनिक विभाजन “nature” और “society” को तीव्र रूप से अलग करता है; अमरकोश ऐसा नहीं करता। यही वैदिक-अर्थ-विन्यास-दृष्टि का महत्त्वपूर्ण तत्व है।

मेरे proposed architecture में यह इस प्रकार रूपान्तरित होगा—

top-level पृथक्करण modern subjects से नहीं,
बल्कि भूमि-से-समाज तक के परम्परागत रेखाचित्र से होगा।

कार्य का एक और उपयोगी बोध

केवल वर्ग-सूची नहीं ; वह यह भी दिखाता है कि अमरकोश को structured lexicon बनाया जा सकता है, जिसमें:

word reference,
gender,
varga-name,
head-word,
relations,
ontological nodes
अलग-अलग रखे जा सकते हैं। वह यहाँ तक दिखाता है कि कुछ ontological nodes ऊपर “Dravyam” और अन्ततः “Padārthaḥ” तक जाते हैं। उदाहरणस्वरूप ākāśaḥ, dik, ātmā को dravyam के अधीन और dravyam को padārthaḥ के अधीन रखा गया है।

यह मेरे project के लिये अत्यन्त उपयोगी है, क्योंकि इससे स्पष्ट है कि अमरकोशीय architecture को केवल व्याख्या-लेख में नहीं, बल्कि actual database और graph रूप में बदला जा सकता है।

निष्कर्ष

अमरकोश का द्वितीय काण्ड पृथ्वी से समाज तक की क्रमिक महा-रचना है। वह भूमि से आरम्भ करता है, नगर-विन्यास तक जाता है, पर्वत और वनस्पति से प्राणी-जगत् तक बढ़ता है, फिर मनुष्य तक पहुँचता है, और अन्ततः मनुष्य के सामाजिक-कर्तव्य-विभागों — ब्रह्म, क्षत्र, वैश्य, शूद्र — में विभक्त होकर समाप्त होता है। यह क्रम आकस्मिक नहीं, बल्कि वैदिक-अर्थ-विन्यास-दृष्टि का स्थूल-भौतिक और सामाजिक रूप है। इसके वर्ग-विन्यास, synset-रूप, Head Word, तथा भाग, जाति, उत्पत्ति, स्वामी, आजीविका, पति-पत्नी आदि सम्बन्धों को computational रूप में चिह्नित करके यह सिद्ध किया है कि अमरकोश को एक ज्ञान-जाल (knowledge-web) के रूप में पढ़ना अधिक यथार्थ है।

अतः मेरे constitutional corpus-engineering project में द्वितीय काण्ड का स्थान अत्यन्त केन्द्रीय होगा। प्रथम काण्ड जहाँ विश्व-व्याप्त ऊर्ध्व रचना देता है, वहीं द्वितीय काण्ड भूतल, जीवन और समाज की आन्तरिक रचना देता है। इन्हीं दोनों के संयुक्त आधार पर आगे Ramayana, Mahābhārata और Purāṇas का mapping किया जाना चाहिए।

अगले लेख में मैं अमरकोश के तृतीय काण्ड पर इसी प्रकार लिखूँगा, क्योंकि वहाँ से ज्ञात होगा कि विशेषण, मिश्र-वर्ग, नानार्थ, अव्यय और लिङ्ग-संग्रह द्वारा अमरकोश अपनी समग्र अर्थ-रचना को किस प्रकार पूर्ण करता है।

अमरकोश का तृतीय काण्ड : शब्द-नियमन, अर्थ-भेद और proposed project का वास्तविक अर्थ-नियमन-स्तर

भूमिका

अमरकोश के प्रथम और द्वितीय काण्ड मुख्यतः जगत्, लोक, भूमि, जीव, मनुष्य और समाज का अर्थ-विन्यास सामने रखते हैं। वे बताते हैं कि पदार्थ-जगत् किस प्रकार अनेक स्तरों में व्यवस्थित है, कौन-से क्षेत्र किस व्यापक वर्ग के अन्तर्गत आते हैं, और नाम-समूहों के द्वारा विश्व का बौद्धिक मानचित्र कैसे बनता है। परन्तु तृतीय काण्ड का कार्य भिन्न, अधिक सूक्ष्म, और वस्तुतः अधिक नियामक है। यहाँ अमरकोश केवल यह नहीं बताता कि “कौन-सा पदार्थ क्या है”; यहाँ वह यह भी बताता है कि शब्द किस प्रकार दूसरे शब्दों से जुड़ेंगे, किस प्रकार किसी एक रूप के अनेक अर्थ होंगे, किन पदों को पदार्थ-संज्ञा मानना होगा और किन्हें सम्बन्ध-सूचक, काल-सूचक, दिशा-सूचक, वियोग-सूचक या विकल्प-सूचक मानना होगा, तथा लिङ्गादि के नियम अर्थ-निर्णय को कैसे प्रभावित करेंगे।

इसीलिए तृतीय काण्ड को केवल “अन्तिम भाग” मानना भूल है। यह परिशिष्ट नहीं है। यह समूचे नामलिङ्गानुशासन का वह भाग है जहाँ शब्द-जगत् के आन्तरिक नियम स्पष्ट होते हैं। यदि प्रथम और द्वितीय काण्ड विश्व का अर्थ-मानचित्र देते हैं, तो तृतीय काण्ड उन मार्गों का विधान करता है जिनसे हम उस अर्थ-मानचित्र में ठीक-ठीक प्रवेश करते हैं। दूसरे शब्दों में कहें, तो यह किसी software-control का स्तर नहीं, बल्कि corpus-semantic regulation का स्तर है। यह बताता है कि शब्दों को किस प्रकार पढ़ा, जोड़ा, पृथक् किया, सन्दर्भानुसार समझा और नियंत्रित किया जाये।

मेरे proposed project के लिये यही तृतीय काण्ड अत्यन्त केन्द्रीय है। क्योंकि मेरा लक्ष्य किसी एक शास्त्र-शाखा के लिये search system बनाना नहीं, बल्कि ancient classics पर आधारित एक complete knowledge retrieval system बनाना है। ऐसा system तभी सम्भव है जब उसमें केवल entity-नामों का संग्रह न हो, बल्कि शब्दार्थ-भेद, नानार्थ-नियमन, mixed zones की पहचान, operator-पदों की भूमिका और grammar-संबद्ध अर्थ-सीमा—इन सबका स्पष्ट विधान हो। यही विधान तृतीय काण्ड देता है।

पूर्वपक्ष

तृतीय काण्ड का बाह्य रूप

तृतीय काण्ड स्वयं को सामान्यकाण्ड कहता है। उसके आरम्भ में पाँच वर्ग बताये गये हैं—

विशेष्यनिघ्नवर्ग
संकीर्णवर्ग
नानार्थवर्ग
अव्ययवर्ग
लिङ्गादिसंग्रहवर्ग

और साथ ही यह भी संकेत किया गया है कि विशेष्य के भेदक शब्द गुण, द्रव्य और क्रिया-संबद्ध रूपों में समझे जायेंगे। इससे स्पष्ट हो जाता है कि यह काण्ड सामान्य पदार्थ-सूची नहीं है। यह शब्द-व्यवहार, अर्थ-भेद, और प्रयोग-नियम का काण्ड है।

प्रथम काण्ड में ऊर्ध्व, दैव, दिक्, काल और विश्व-संबद्ध विन्यास है। द्वितीय काण्ड में भूतल, जन, जीव और समाज का विन्यास है। परन्तु तृतीय काण्ड में प्रश्न यह है कि उन सबको समझने के लिये आवश्यक पद-संबन्धों का विधान कैसे होगा। यही उसका बाह्य रूप है, और यही उसकी भीतरी शक्ति।

विशेष्यनिघ्नवर्ग का गूढ़ प्रयोजन

“विशेष्यनिघ्न” को केवल “विशेषण-संग्रह” कह देने से बात अधूरी रह जाती है। यहाँ बात इससे अधिक सूक्ष्म है। यह वर्ग उन पदों का विन्यास करता है जो किसी विशेष्य का भेद प्रकट करते हैं—गुण के रूप में, द्रव्यगत विशेषता के रूप में, क्रियागत प्रवृत्ति के रूप में, स्वभावगत प्रवृत्ति के रूप में, अथवा किसी विशिष्ट स्थिति के रूप में। अतः यह वर्ग वस्तुओं की सूची नहीं, बल्कि विशेष्याधीन भेदक-पदों की व्यवस्था है।

इसका गहरा अर्थ यह है कि अमरकोश का ज्ञान-जगत् केवल objects से नहीं बनता। वह qualifiers, dispositions, capacities, states, tendencies, moral tags, functional tags, और actional differentiators से भी बनता है। जैसे— पुण्यवान्, निपुण, स्वाधीन, कर्मठ, दयालु, भीरु, क्रोधी, निद्रालु, जागरूक इत्यादि। ये पृथक् जगत् के नाम नहीं हैं; ये विशेष्य के आश्रय से अर्थवान् होते हैं। इसीलिये यह वर्ग केवल “adjective list” नहीं, बल्कि attribute-architecture है।

मेरे project के लिये इसका सीधा परिणाम यह है कि corpus को केवल “पदार्थ-संज्ञाओं” में विभाजित करना पर्याप्त नहीं होगा। कोई भी ज्ञान retrieval system तभी परिपक्व होगा जब वह यह भेद कर सके कि कौन-सा पद किसी वस्तु का नाम है, कौन-सा उसके गुण का, कौन-सा उसकी दशा का, कौन-सा उसकी शक्ति का, और कौन-सा उसकी प्रवृत्ति का। अतः Entity और Qualifier का भेद केवल computational सुविधा नहीं, बल्कि Amarakośa-सम्मत अनिवार्यता है। परन्तु इसे भी केवल software schema की भाँति नहीं समझना चाहिए। यह मूलतः शब्दार्थ-संबन्ध-विधान है।

संकीर्णवर्ग : अवशिष्ट क्षेत्र नहीं, मिश्र-अर्थ क्षेत्र

विशेष्यनिघ्नवर्ग के बाद अमरकोश संकीर्णवर्ग रखता है। आरम्भ में ही यह संकेत मिलता है कि यहाँ लिङ्ग आदि का निर्णय कभी प्रकृति से, कभी प्रत्यय से, कभी अर्थ से, और कभी मिश्र लक्षणों से करना होगा। इससे सिद्ध है कि संकीर्णवर्ग कोई “बाकी बचा हुआ संग्रह” नहीं है। यह वह क्षेत्र है जहाँ ऐसे पद या अर्थ-समूह आते हैं जिन्हें एकरेखीय वर्गीकरण से बाँधना कठिन है।

आधुनिक वर्गीकरण-प्रणालियाँ प्रायः प्रत्येक पद को एक folder में रखना चाहती हैं। Amarakośa का तृतीय काण्ड स्वीकार करता है कि कुछ पद और कुछ अर्थ-संबन्ध ऐसे हैं जिनमें अनेक सूत्र एक साथ काम करते हैं। इसीलिये संकीर्णवर्ग का वास्तविक अर्थ है—mixed semantic zone।

मेरे project के लिये इसका महत्व अत्यन्त अधिक है। Complete knowledge retrieval system में अनेक passages ऐसे होंगे जो एक साथ धर्म, काल, क्रिया, समाज, चरित्र, और metaphysical framework से जुड़े होंगे। यदि system उन्हें बलपूर्वक एक ही खाँचे में ठूँस देगा, तो ancient thought-process नष्ट हो जायेगा। अतः ऐसे passages, concepts और relations को mixed zone के रूप में चिह्नित करने की व्यवस्था अनिवार्य होगी। यही संकीर्णवर्ग का उपदेश है।

नानार्थवर्ग : शब्द-रूप और अर्थ-भेद का संविधान

नानार्थवर्ग Amarakośa की बौद्धिक परिपक्वता का बड़ा प्रमाण है। यहाँ यह स्वीकार किया गया है कि एक ही शब्द-रूप अनेक अर्थ धारण कर सकता है, और अर्थ का निर्णय केवल surface form देखकर नहीं किया जा सकता। यही वह बिन्दु है जहाँ modern thesaurus की सीमाएँ स्पष्ट हो जाती हैं। आधुनिक प्रणाली प्रायः शब्द-रूप को मुख्य इकाई बनाती है; Amarakośa कहता है कि रूप एक हो सकता है, पर अर्थ अनेक होंगे।

अतः retrieval engine के लिये यह नियम असत्य होगा कि “एक शब्द = एक अर्थ = एक node।” सही रचना यह होगी:

Lexeme
Sense
Context selector
Disambiguation rule

नानार्थवर्ग का यही वास्तविक संदेश है। यदि किसी पद का एक अर्थ लोक-संबन्धी हो, दूसरा metaphysical हो, तीसरा व्यवहारगत हो, चौथा technical हो, तो system को context देखकर सही sense चुनना होगा। यही complete knowledge retrieval का मूलभूत नियम है। अन्यथा system केवल token-match करेगा और भ्रम फैलायेगा।

इसलिए नानार्थवर्ग को software feature की तरह नहीं, बल्कि अर्थ-निर्णय-संविधान की तरह समझना चाहिए। यह बताता है कि corpus को पढ़ते समय शब्दरूप और अर्थरूप का पृथक्करण आवश्यक है।

अव्ययवर्ग : पदार्थ-नाम नहीं, सम्बन्ध-सूचक पद

अव्ययवर्ग में Amarakośa ऐसे पदों को रखता है जो सामान्यतः रूप-परिवर्तन से परे रहते हैं और जिनका काम है—काल, दिशा, वियोग, संयोग, विकल्प, निकटता, दूरता, पुनरावृत्ति, वेग, कारणता, अथवा क्रम का संकेत करना। जैसे— चिर, मुहुः, झटिति, पृथक्, विना, सह, वृथा, तदा, अधुना, ह्यः, श्वः, प्राग् इत्यादि।

यह अत्यन्त गहरा बिन्दु है। अव्यय पदार्थ नहीं हैं। वे सम्बन्ध-विधान के उपकरण हैं। वे स्वयं प्रायः किसी वस्तु का नाम नहीं देते; वे वस्तुओं, स्थितियों, कालों और क्रियाओं के बीच सम्बन्ध-संकेत करते हैं। इसलिए उन्हें सामान्य noun-node की तरह व्यवहार करना मूल भूल होगी।

मेरे project में अव्ययवर्ग का अर्थ होगा कि system को relation-operators, temporal-operators, directional-operators, scope-markers और context-markers की पृथक् पहचान करनी होगी। Complete knowledge retrieval system तभी सफल होगा जब वह यह समझ सके कि “सह”, “विना”, “प्राग्”, “अधुना”, “तदा”, “श्वः” जैसे पद अर्थ-संबन्ध का मार्ग बनाते हैं। यही corpus-semantic regulation है। यह केवल “operator detection” नामक तकनीकी अभ्यास नहीं, बल्कि पाठ के भीतर अर्थ-गति का बोध है।

लिङ्गादिसंग्रहवर्ग : grammar-aware control नहीं, grammar-aware अर्थ-नियमन

तृतीय काण्ड का अन्तिम वर्ग लिङ्गादिसंग्रहवर्ग है। यहाँ अमरकोश केवल शब्दों के लिङ्ग नहीं बताता; वह लिङ्ग, प्रत्यय, समास, व्युत्पत्ति, सामान्य नियम, विशेष बाधा, और शिष्ट-प्रयोग तक की ओर संकेत करता है। यह एक प्रकार की fallback rule-table अवश्य है, किन्तु इसका प्रयोजन केवल grammar चलाना नहीं है। इसका प्रयोजन यह सुनिश्चित करना है कि शब्द का अर्थ-निर्णय grammar से विच्छिन्न न हो।

इसीलिए यहाँ “control-layer” शब्द का उपयोग यदि करना भी हो, तो वह corpus-semantic sense में होना चाहिए, न कि software-control sense में। लिङ्गादिसंग्रहवर्ग बताता है कि grammar और semantics दो पृथक् द्वीप नहीं हैं। यदि किसी पद का लिङ्ग, समास, प्रत्यय, या व्युत्पत्ति उसके अर्थ-निश्चय को प्रभावित करती है, तो retrieval system को वह सब जानना होगा। अन्यथा वह गलत concept बना देगा, गलत cluster देगा, और गलत relation स्थापित करेगा।

मेरे project में इसका रूप होगा:

grammatical rule table
gender-sensitive interpretation
derivation-aware tagging
compound governance
override rules
usage-based exception handling

परन्तु यहाँ भी यह याद रखना होगा कि इन सबका लक्ष्य grammar को अलग engine में चलाना नहीं, बल्कि corpus के अर्थ-नियमन में grammar का उचित स्थान देना है।

उत्तरपक्ष

अब एक सम्भावित आपत्ति सामने आती है।

आपत्ति १

तृतीय काण्ड तो grammar appendix है; इसे project के grand architecture में इतना ऊँचा स्थान क्यों दिया जाये?

उत्तर

यह दृष्टि अधूरी है। यदि प्रथम और द्वितीय काण्ड पदार्थ-जगत् का विन्यास दें, और तृतीय काण्ड यह न बताए कि शब्द-रूप, अर्थ-भेद, नानार्थ, अव्यय, और लिङ्ग-नियमों के द्वारा उस विन्यास तक पहुँचने का मार्ग क्या है, तो समूची रचना अधूरी रह जायेगी। तृतीय काण्ड उसी प्रकार है जैसे किसी बड़े नगर में केवल भवन-सूची न हो, बल्कि मार्ग-सूचक, नाम-संशय-निवारण, प्रवेश-निषेध, दाहिने-बाएँ मोड़, और स्थान-परिचय का विधान भी हो। अतः यह appendix नहीं, प्रवेश-विधान है।

आपत्ति २

यदि यह grammar-heavy है, तो इसे semantic graph से अलग रखना चाहिए।

उत्तर

यह भी अर्धदृष्टि है। क्योंकि grammar को यदि semantics से पृथक् कर दिया गया, तो नानार्थ का निर्णय टूट जायेगा, operator-पदों की शक्ति नष्ट हो जायेगी, mixed zones की पहचान दुर्बल हो जायेगी, और लिङ्ग-आधारित अर्थ-भेद छूट जायेंगे। तृतीय काण्ड का मुख्य उपदेश ही यह है कि शब्दार्थ-जगत् में grammar, semantics, और usage परस्पर संबद्ध हैं। इसलिए इसे graph के बाहर रखकर काम नहीं चलेगा; हाँ, इसे graph के ऊपर शासन करनेवाले corpus-semantic नियम-तन्त्र के रूप में समझना चाहिए।

सन्धि

अब सम्यक् संश्लेषण यह है:

काण्ड १ = विश्व का व्यापक अर्थ-विन्यास
काण्ड २ = भूतल, जीव, मनुष्य और समाज का स्थूल अर्थ-विन्यास
काण्ड ३ = उन सबके ऊपर चलनेवाला शब्द-नियमन, अर्थ-भेद, operator-विन्यास, polysemy-विनियमन, और grammar-संबद्ध अर्थ-नियमन

अतः यदि पहले दो काण्ड semantic world-map हैं, तो तीसरा काण्ड semantic access-law है। यह software-control नहीं, बल्कि corpus-semantic governance है। यह बताता है कि किसी पद को किस रूप में ग्रहण किया जाये, किसी बहुअर्थक शब्द का sense कैसे चुना जाये, किसी अव्यय का सम्बन्ध-विधान कैसे समझा जाये, और mixed semantic zone को कैसे चिह्नित किया जाये।

यही कारण है कि मेरे project में तृतीय काण्ड को “control-layer” कहने के स्थान पर “अर्थ-नियमन-स्तर” कहना अधिक उचित है। यह शब्द-व्यवस्था का ऐसा नियमन है जो retrieval, clustering, relation building, और query interpretation—सभी को प्रभावित करता है।

सन्धान — मेरे project में वास्तविक कार्य-रूप

Constitution में तृतीय काण्ड का स्थान

Constitution में यह नियम होना चाहिए कि किसी भी concept, relation, passage-role, या cluster की स्वीकृति केवल topical similarity से न हो। यह भी देखा जाये कि:

वह विशेष्य है या विशेषक
वह mixed zone का अंश है या नहीं
वह single-sense है या polysemous
वह entity-word है या operator-word
उस पर लिङ्ग, समास, प्रत्यय या व्युत्पत्ति-संबद्ध सीमाएँ लागू हैं या नहीं

अर्थात् Constitution में Kanda-3 आधारित word-governance table अनिवार्य होगी। यह table software के लिये नहीं, corpus के लिये होगी।

Corpus tiers में उपयोग

Tier-0 : Amarakośa constitutional layer
Tier-1 : Rāmāyaṇa, Mahābhārata, Purāṇa
Tier-2 : BPHS, Yoga Vāsiṣṭha, अन्य शास्त्र
Tier-3 : commentary, OCR, sandbox

इन tiers पर Kanda-3 इस प्रकार काम करेगा:

qualifier detection
mixed passage detection
polysemy detection
operator recognition
grammar-aware tagging
sense selection
relation constraint

Graph schema पर प्रभाव

Graph schema में केवल Entity node पर्याप्त नहीं होगी। कम से कम ये types चाहिए—

Lexeme
Sense
Qualifier
Operator
GrammarRule
Passage
Concept
ConceptCluster

और edges—

has_sense
qualifies
modifies
context_selects
acts_as_operator
gender_rule_applies
compound_rule_applies
belongs_to_mixed_zone
restricted_by_usage

यह schema तृतीय काण्ड को software appendix के रूप में नहीं, corpus-semantic law के रूप में प्रतिबिम्बित करेगा।

Training policy

Training का क्रम यह होना चाहिए—

चरण १
surface-form normalization

चरण २
morphological tagging

चरण ३
entity vs qualifier vs operator vs polysemous lexeme classification

चरण ४
sense disambiguation

चरण ५
passage-role detection

चरण ६
relation extraction

चरण ७
graph rewiring under constitutional limits

यदि यह क्रम उलट दिया गया और पहले dense embedding या giant model पर भरोसा किया गया, तो system विशेषतः नानार्थ, अव्यय और लिङ्ग-विनियम में भारी भ्रम करेगा।

Z890 + dual RTX 5090 पर सञ्चालन

CPU + RAM : canonical store, graph store, rule tables, validation
GPU-0 : embedding, reranking, annotation assistance
GPU-1 : classifier, disambiguation model, relation extractor training
dual-GPU phase : जब पर्याप्त gold data बन जाये, तब multi-GPU training

पर यहाँ भी मूल बात hardware नहीं है। यदि तृतीय काण्ड की corpus-semantic मर्यादा system में न उतरी, तो high-end GPU केवल अधिक वेग से भ्रम उत्पन्न करेंगे।

निष्कर्ष

अमरकोश का तृतीय काण्ड सबसे अधिक सावधानी से पढ़े जाने योग्य है, क्योंकि यही वह स्थान है जहाँ कोष पदार्थ-सूची से उठकर शब्दार्थ-नियमन-तन्त्र बन जाता है। विशेष्याधीन भेदक-पद, mixed zones, नानार्थ, अव्यय, और लिङ्गादिसंग्रह—ये पाँचों मिलकर सिद्ध करते हैं कि Amarakośa केवल semantic map नहीं, बल्कि semantic regulation भी है।

मेरे project के लिये इसका मुख्य उपदेश यह है:

यदि complete knowledge retrieval system बनाना है, तो केवल world-model पर्याप्त नहीं। उसके साथ word-model, sense-model, relation-model, operator-model, और grammar-aware corpus-semantic regulation भी चाहिए। तृतीय काण्ड का यही मर्म है।

इसीलिए मैं कहूँगा कि काण्ड १ और २ बिना काण्ड ३ के स्थूल शरीर मात्र हैं; और काण्ड ३ बिना १ और २ के निर्जीव नियम-संग्रह होता। इन तीनों के संयोग से ही Amarakośa अपनी पूर्ण Ārṣa अर्थ-विन्यास-दृष्टि को सिद्ध करता है।

अगला उचित लेख यह होगा कि अब इन तीनों काण्डों को एक साथ रखकर project के लिये वास्तविक CONSTITUTION कैसे बनाया जाये —
अर्थात्:

immutable top layer,
fluid second layer,
graph law,
training law,
redesign law,
promotion law,
rollback law.

वैदिक-अर्थ-विन्यास-दृष्टि

(सबसे ऊर्ध्व स्तर Amarakośa-derived grand semantic architecture के अधीन रखा गया है;
उसके नीचे Primary-corpus constitutional ontology और
उसके नीचे Fluid specialist ontology and
dynamic WBE-style rewiring रखा गया है।)

भूमिका — पृष्ठभूमि तथा अग्रभूमि

सम्पूर्ण संवाद का सम्यक् परीक्षण करने पर अब यह प्रश्न निर्णीत हो चुका है कि यह कार्य chatbot project नहीं है। यह “Sanskrit पर model train करके उससे प्रश्न पूछना” नहीं है। यह एक constitutional corpus-engineering project है, जिसका प्रथम लक्ष्य है — किसी प्राचीन ज्ञान-क्षेत्र को उसके अपने अन्तःसम्बन्धों के अनुसार पुनर्विन्यस्त करना, उससे तत्त्वों का निष्कर्षण करना, तथा उसे गतिशील रीति से पुनर्संरचित करना। यह निष्कर्ष केवल शोभा के लिए नहीं है; आगे की प्रत्येक engineering decision इसी पर आश्रित होगी।

मुख्य corpus भी किसी आकस्मिक ग्रन्थ-संग्रह का नाम नहीं है। वह एक primary constitutional corpus है, जिसमें Mahābhārata + Rāmāyaṇa + Purāṇas होंगे। इनके नीचे secondary advisory corpus होगा, जिसमें BPHS, Yoga Vāsiṣṭha तथा अन्य सहायक ग्रन्थ आयेंगे। यह secondary corpus महत्त्वपूर्ण है, किन्तु इसे primary corpus से निष्पन्न architecture को परिवर्तित करने की स्वतन्त्र अनुमति नहीं दी जा सकती। वही मूल विधि-सूत्र है।

Z890 + dual RTX 5090 machine इस योजना के सभी गम्भीर computational अंशों के लिए पर्याप्त है। प्रत्येक RTX 5090 में 32 GB GDDR7 memory है; अतः parallel कार्य के लिए दो पृथक् 32 GB devices हैं, कोई काल्पनिक एकीकृत 64 GB device नहीं। फिर भी embedding generation, reranker training, passage classification, relation extraction तथा आगे चलकर graph-neural प्रयोगों के लिए यह पर्याप्त से अधिक है।

अब वास्तविक प्रश्न यह है:

किस प्रकार एक ऐसा self-restructuring, constitutionally constrained, corpus-native intelligence system निर्मित किया जाये, जो primary corpus से वैदिक-अर्थ-विन्यास-दृष्टि ग्रहण करे, secondary corpus का उपयोग नियमन के अधीन करे, और modern topical flattening में गिरे बिना अपने retrieval तथा internal organization का पुनर्विन्यास कर सके?

यही इस कार्य का यथार्थ प्रश्न है।

संशोधित वास्तु-नियम — Revised Architectural Rule

अब इस समग्र योजना का सर्वोच्च विन्यास इस प्रकार होना चाहिए:

Level 0

Amarakośa-derived grand semantic architecture

Level 1

Primary-corpus constitutional ontology induced from:

Mahābhārata
Rāmāyaṇa
Purāṇas
Level 2

Fluid specialist ontology and dynamic WBE-style rewiring

यह संशोधन अत्यन्त आवश्यक है, क्योंकि यदि Level 0 पर ही आधुनिक topical ontology रख दी गयी, तो सम्पूर्ण architecture आरम्भ से ही विकृत हो जायेगी। Amarakośa यहाँ केवल dictionary नहीं, बल्कि महान अर्थ-विन्यास-आधार है। उसके अधीन primary corpus अपना constitutional रूप ग्रहण करेगा, और उसके अधीन ही fluid specialist rewiring चलेगी।

पूर्वपक्ष — मुख्य प्रतिपादन

यथार्थ वस्तु “constitutional corpus brain” है, साधारण search index नहीं

केवल flat text index पर्याप्त नहीं है। केवल vector database पर्याप्त नहीं है। केवल fine-tuned LLM भी पर्याप्त नहीं है। यथार्थ वस्तु एक multi-layer knowledge architecture है, जिसमें corpus को केवल text के रूप में नहीं, बल्कि निम्नरूपेण ग्रहण किया जाये:

text units
concept units
doctrinal relations
discourse forms
narrative carriers
cosmological coordinates
temporal-causal structures
model branches that learn from failure and correction

इसी कारण graph-based methods का स्थान है। किन्तु यहाँ एक गम्भीर सीमा भी है। Sanskrit śāstric तथा Purāṇic सामग्री में graph को generic LLM extraction से सुरक्षित रीति से उत्पन्न नहीं किया जा सकता, क्योंकि ऐसा extractor प्रायः relations को modernize, flatten अथवा over-literalize कर देता है। अतः GraphRAG-जैसी प्रविधियाँ उपयोगी अवश्य हैं, किन्तु constitution के बाद, उससे पहले नहीं।

system में एक constitutional core और एक plastic operational layer अनिवार्य है

सम्पूर्ण योजना का एक निर्णायक बिन्दु यह है कि कुछ तत्त्व स्थिर रहेंगे और कुछ परिवर्तनीय रहेंगे। इसी कारण implementation को दो विभागों में विभक्त करना होगा।

A. Constitutional layer

यह वह स्तर है जिसे system स्वतन्त्रतया पुनर्लिखित नहीं कर सकेगा। इसमें होगा:

Level 0 Amarakośa-derived macro-architecture
legal relation types
admissible discourse forms
promotion rules
normalization laws
forbidden redesign moves
benchmark suites
rollback rules
B. Plastic operational layer

यह वह स्तर है जो self-restructuring होगा। इसमें system निम्न कार्य कर सकेगा:

reweight edges
propose new sub-concepts
improve segmentation
train specialist models
add branches
merge duplicate concepts
split overbroad concepts
revise retrieval routing

यह विभाजन “model सदा स्वयं को retrain करता रहे” जैसी अपरिपक्व कल्पना से कहीं अधिक यथार्थ है। इसी से constitution सुरक्षित रहेगा और growth भी सम्भव होगी।

ontology-induction का शासन primary corpus करेगा, किन्तु वह भी Level 0 के अधीन रहेगा

पहले draft में top-level ontology trunks के रूप में kāla, karma, phala, yajña आदि की बात थी। अब यह स्पष्ट रूप से संशोधित होना चाहिए। वे अब Level 0 नहीं होंगे; वे Level 1 या उसके नीचे के constitutional trunks होंगे। Level 0 पर Amarakośa-derived grand semantic architecture होगा। उसके नीचे primary corpus यह निश्चय करेगा कि कौन-से concepts:

explicitly present हैं,
structurally implied हैं,
केवल specialist refinement हैं,
अथवा main constitution से बाह्य हैं।

अतः संशोधित सिद्धान्त यह होगा:

Level 0 gives grand semantic order.
Level 1 gives living constitutional ontology from Mahābhārata, Rāmāyaṇa, Purāṇas.
Level 2 gives flexible expert rewiring.

secondary corpus “amendment proposer” होगा, “ruler” नहीं

यह hierarchy इस प्रकार है:

Primary corpus: constitution-maker
Secondary corpus: amendment proposer
Sandbox corpus: hypothesis generator

अर्थात् BPHS, Yoga Vāsiṣṭha, siddhānta-texts तथा अन्य technical works distinctions को और सूक्ष्म कर सकते हैं, specialist subgraphs प्रस्तावित कर सकते हैं, किन्तु वे main architecture पर शासन नहीं करेंगे। वे तभी स्वीकृत होंगे जब primary corpus उनको आत्मसात् कर सके और constitutional coherence अक्षुण्ण रहे।

ज्ञान-एकक केवल श्लोक नहीं है

Garuḍa Purāṇa का उदाहरण यह बात निर्णायक रूप से सिद्ध करता है कि एक chapter के भीतर ही अनेक प्रकार के rules एकत्र हो सकते हैं:

mapping rules
classification rules
suitability rules
prohibition rules
action-condition-result rules
yoga/doṣa combinations
ritual timing rules
naming rules

अतः knowledge unit को एक साथ अनेक स्तरों पर रखना होगा:

raw verse
verse window
typed rule object
entity mapping
doctrinal motif
graph insertion

इसलिए यथार्थ pipeline यह नहीं होगी कि “verse text को index करो”; यथार्थ pipeline होगी — verse text से typed assertions निकालो।

उत्तरपक्ष — मुख्य आपत्तियाँ और उनका निरसन

आपत्ति १ — corpus को स्वतः सब सीखने दो

यह ऊपर से मनोहर प्रतीत हो सकता है, किन्तु व्यवहार में यह भ्रान्त है। यदि raw corpus statistics को “ancient sensibility” का एकमात्र निर्णायक बना दिया गया, तो system सीखेगा:

OCR distortions
repetition artifacts
redaction frequency bias
genre imbalance
scribal survival accidents
modern file-order noise

अतः corpus source अवश्य है, किन्तु sole judge नहीं। उसका अर्थ constitutional constraints के अधीन ही ग्रहण करना होगा।

आपत्ति २ — सम्पूर्ण corpus पर एक बड़ा model fine-tune कर दो

यह भी त्रुटिपूर्ण है। इससे एक blurred latent space बनेगा, controlled architecture नहीं। model पहले verbal fluency ग्रहण करेगा, structural fidelity बहुत बाद में, यदि कभी करे भी। इस कार्य की प्रधान समस्याएँ generation नहीं हैं, बल्कि:

segmentation
mapping
extraction
graph formation
ontology growth
constitutional coherence
high-recall retrieval

अतः large generative model यदि बाद में किसी सहायक रूप में आये, तो आये; वह foundation नहीं बन सकता।

आपत्ति ३ — आरम्भ से सब कुछ graph में बदल दो

यह भी शीघ्रता होगी। यदि extraction ही दुर्बल हुआ, तो graph में garbage triples भर जायेंगे, और वही structural garbage बनकर authority का रूप धारण कर लेंगे। इसलिए graph construction का आरम्भ निम्न आधारों से होना चाहिए:

constitutional schema
manual gold chapters
typed extractors
high-precision rule templates
human correction
आपत्ति ४ — केवल graph पर्याप्त है, vector retrieval की आवश्यकता नहीं

यह भी अपूर्ण है। अनेक महत्त्वपूर्ण passages अप्रत्यक्ष होते हैं, दूर-दूर वितरित होते हैं, अथवा समान अर्थ रखते हुए भी surface-form नहीं साझा करते। ऐसे में graph अकेला आरम्भिक चरणों में brittle सिद्ध होगा। हमें संयुक्त रूप से चाहिए:

lexical retrieval
vector retrieval
graph traversal
reranking
आपत्ति ५ — dynamic redesign को uncontrolled self-modification बना दो

यही सबसे बड़ा संकट है। uncontrolled self-training से drift उत्पन्न होगा। model नये clusters, नये relations, नये norms गढ़ने लगेगा और फिर उन्हें scriptural authority के समीप रख देगा। यह सर्वथा वर्जनीय है। इसलिए “dynamic reordering” केवल इन रूपों में मान्य होगी:

versioned branching
benchmark-tested redesign
constitutionally validated promotion
आपत्ति ६ — dual RTX 5090 हैं, अतः एक giant universal model बनाना चाहिए

यह hardware का अनुचित उपयोग होगा। दो 5090s एक monolithic model की माँग नहीं करते; वे एक model ecology की अनुमति देते हैं:

one branch for embeddings
one for reranking
one for passage classification
one for relation extraction
optionally one for graph neural experiments

यही इस machine का यथार्थ उपयोग होगा।

सन्धि — सम्यक् संश्लेषण

सम्पूर्ण विचार का यथार्थ संश्लेषण यह है:

एक constitutionally governed, self-restructuring Puranic knowledge architecture निर्मित की जाये।

उसकी रचना इस प्रकार होगी:

Level 0

Amarakośa-derived grand semantic architecture

Primary Constitutional Corpus

Mahābhārata + Rāmāyaṇa + Purāṇas

Secondary Advisory Corpus

BPHS, Yoga Vāsiṣṭha, siddhānta texts, other irregular ancient texts

Immutable Raw Archive + Versioned Normalization Branches
Canonical Relational Store

Passages, entities, annotations, embeddings, provenance

Operational Property Graph

For graph traversal, community structure, typed relationships

Constitutional RDF / SHACL Mirror

For validation, legal-shape checking, and later rule-based inferencing

Lexical + Vector + Graph Hybrid Retrieval
Specialist Model Ecology

Instead of one monolithic model

Controlled Continual Learning Loop

Detect failure → open branch → train → validate → benchmark → promote or reject

यही “specific-WBE” (Whole Brain Emulation) विचार का यथार्थ computational समरूप है। यह literal neural tissue emulation नहीं है; यह fluid connectivity, dynamic rewiring, branch growth और constitutionally guided plasticity है।

SHACL यहाँ विशेष उपयोगी है, क्योंकि constitutional gatekeeping के लिए declared graph-conditions आवश्यक हैं। इस कारण RDF/SHACL mirror को केवल सजावटी भाग न समझा जाये; यह constitutional legality का परीक्षण-केन्द्र होगा।

सन्धान — Z890 + dual RTX 5090 पर व्यावहारिक कार्य-विधि

अब सिद्धान्त से कार्य-विधान की ओर बढ़ते हैं।

Machine architecture

1.1 Host/guest layout

इस machine का उत्तम उपयोग इस प्रकार होगा:

Windows host — सामान्य desktop workflow तथा GPU driver stability हेतु
WSL2 Ubuntu — मुख्य development तथा training environment हेतु
Graph/database services — Docker inside WSL2 अथवा native Linux services in WSL

यह विन्यास इसलिए श्रेयस्कर है कि मेरा व्यापक कार्य-वातावरण पहले से Windows-आधारित है, किन्तु Python, graph, database और training tooling मैं Windows में अनाकोण्डा के अलावा WSL2 - Linux में अधिक पुनरुत्पाद्य तथा अनुशासित तरीके से कर पाता हूँ ।

1.2 GPU role separation

दोनों 5090s को पृथक् workers की भाँति ग्रहण कीजिये।

Default role assignment

GPU0: embedding generation, reranker inference, annotation assistance, interactive experiments
GPU1: branch training, classifier fine-tuning, relation extractor training

Heavy training mode

दोनों GPUs through DDP / multi-GPU PyTorch

Rule

database services को GPU से न जोड़ें
Neo4j, PostgreSQL, SHACL validation, graph analytics — CPU + RAM पर रहें
1.3 RAM and storage usage

मेरे Z890-aiTop डेक्सटॉप का २५६ GB RAM इन कार्यों के लिए महत्त्वपूर्ण होगी:

graph snapshot caching
full annotation table loading
graph-export community detection
multiple normalization branches in memory
batch embedding pipelines

Fast NVMe पर यह सब रहे:

raw corpus lake
normalized parquet/jsonl
Neo4j store
PostgreSQL data directory
model checkpoints
graph snapshots

Software stack

2.1 Canonical store: PostgreSQL + pgvector

PostgreSQL को canonical source of structured truth बनाया जाये। उसमें यह सब रहे:

passages
annotations
entities
rules
provenance
branches
evaluations
embeddings

pgvector को passage embeddings के लिए उपयोग करें। इस योजना में vector database पृथक् रूप से आरम्भ करना उचित नहीं, क्योंकि यह project vector-first नहीं, बल्कि relationally and constitutionally first है।

2.2 Operational graph: Neo4j

Neo4j को operational graph layer के रूप में उपयोग करें। उसका कार्य होगा:

local graph traversal
neighborhood inspection
doctrinal-path queries
community-level exploration
visual graph debugging
2.3 Constitutional validation layer: RDFLib + pySHACL

चयनित graph content को RDF triples में mirror कीजिये, और SHACL द्वारा validate कीजिये।

Why dual representation?

operational property graph queries are easier in Neo4j
constitutional legality checks are easier in SHACL

अतः:

property graph for operations
RDF/SHACL for validation
2.4 Graph learning / experimental reasoning: PyTorch Geometric

जब graph पर्याप्त परिपक्व हो जाये, तब graph snapshots को PyTorch Geometric में export करें। मेरे graph में heterogeneous node-types होंगे; अतः PyG का उपयोग आगे के चरणों में युक्तिसंगत होगा।

2.5 Retrieval and orchestration

आरम्भ में heavy orchestration framework पर आश्रित न हों। प्रथम संस्करण plain Python में बनाइये। GraphRAG या LlamaIndex-जैसी प्रविधियों को implementation reference के रूप में देखें, governing method के रूप में नहीं।

Directory and project structure

नीचे का structure यथावत् English में ही रखा जाना चाहिए:

corpus_brain/
constitution/
ontology/
relations/
discourse_forms/
shacl_shapes/
promotion_rules/
benchmark_queries/
data/
raw/
primary/
secondary/
sandbox/
normalized/
n0_raw_preserved/
n1_unicode/
n2_punctuation/
n3_segmented/
n4_canonicalized/
curated/
passages/
rules/
entities/
annotations/
db/
postgres/
neo4j/
rdf_exports/
models/
embeddings/
rerankers/
classifiers/
relation_extractors/
graph_models/
branches/
normalization/
ontology/
retrieval/
models/
eval/
gold_queries/
gold_passages/
gold_rules/
reports/
apps/
ingestion/
annotation_ui/
retrieval_api/
graph_export/
training/

यह केवल रूप-सौन्दर्य का विषय नहीं है। इससे raw, normalized, curated, graph, models, branches, evaluation — इन सबका पृथक्करण स्थिर रहेगा। इन्हें कभी मिश्रित न कीजिये।

Constitutional design — coding से पहले क्या लिखना अनिवार्य है

Large-scale training से पहले पाँच human-authored constitutional files लिखना आवश्यक होगा।

4.1 Revised top-level constitutional order

यहाँ पहले दिये गये direct top-level ontology trunks को संशोधित करना होगा। अब व्यवस्था इस प्रकार हो:

Level 0: Amarakośa macro-architecture

यहाँ Amarakośa-based grand semantic trunks आयेंगे।

Level 1: Primary-corpus constitutional trunks

यहाँ जैसे:

KALA
KARMA
PHALA_VIPAKA
YAJNA
COSMOGRAPHY
GRAHA_GATI
NAKSHATRA
RITUAL_TIMING
NARRATIVE_EXEMPLUM
RULE
EXCEPTION
MAPPING
CLASSIFICATION
PROHIBITION
SUITABILITY

अर्थात् ऊपर Amarakośa, उसके नीचे corpus-derived trunks। यही मेरे संशोधन का मूल है।

4.2 Legal edge vocabulary

उदाहरणार्थ:

defines
classifies
maps_to_deity
is_suitable_for
is_unsuitable_for
forms_yoga_with
forms_dosha_with
ripens_as
manifests_when
remains_dormant_under
is_nonbinding_when
narratively_encodes
presupposes
belongs_to_cluster

कोई model बिना review के canonical edge types न गढ़े।

4.3 Discourse-form taxonomy

At minimum:

DEFINITION
CLASSIFICATION
ENUMERATION
PRESCRIPTION
PROHIBITION
PHALASHRUTI
NARRATIVE_EXEMPLUM
DIALOGUE
MAPPING
CAUSAL_RULE
EXCEPTION
COSMOGRAPHIC_DESCRIPTION

4.4 Promotion rules

किसी नये model/ontology/normalization की promotion तभी हो जब:

benchmark performance सुधरे
SHACL legality न टूटे
constitutional recall सुरक्षित रहे या बढ़े
proposed new concepts interpretable हों
older gold tasks पर material regression न हो
4.5 Rollback rules

प्रत्येक promoted change reversible होना चाहिए।

Corpus ingestion and normalization

यह कार्य branches में होगा, overwrite करके नहीं।

5.1 Normalization branches
N0 — raw preserved

The exact source text, untouched.

N1 — unicode normalization

Unicode composition को normalize करें, hidden control characters हटायें, danda variants standardize करें, spaces normalize करें।

N2 — punctuation and line discipline

Line breaks, headings, chapter markers, Devanagari digits आदि को अनुशासित करें।

N3 — segmentation

Segment into:

verse
pāda if useful
3-verse windows
7-verse windows
chapter units
N4 — canonical views

Create derived fields:

stripped text
search-normalized text
transliteration if needed
entity-highlighted view
char n-gram view

किसी भी branch को नष्ट न करें। प्रत्येक downstream artifact को यह ज्ञात होना चाहिए कि वह किस normalization branch से उत्पन्न हुआ है।

5.2 Multiple segmentation levels क्यों आवश्यक हैं

Single verse प्रायः अत्यल्प होता है। Full chapter प्रायः अत्यधिक विशाल होता है। अतः कम से कम यह सब रखें:

verse
3-verse window
7-verse window
chapter

तब classifier यह सीख सकेगा कि किस task के लिए कौन-सी granularity अधिक उपयुक्त है।

प्रथम gold sample set

आरम्भ में सब कुछ label न करें। पहले एक deliberately chosen constitutional starter set बनाइये। उसमें यह सम्मिलित हों:

one Garuḍa Purāṇa Jyotiṣa chapter
one cosmography-heavy Purāṇic chapter
one karma-phala-vipāka narrative section
one yajña-phala / non-binding action section
one Mahābhārata doctrinal dialogue section
one Rāmāyaṇa section carrying cosmological or dharmic temporal structure

लक्ष्य सम्पूर्ण coverage नहीं, बल्कि system को यह सिखाना है कि legal structures कैसे दिखते हैं।

6.1 Annotation method for gold samples

प्रत्येक passage को अनेक स्तरों पर annotate करें।

Passage-level labels

KALA_VIDHANA
KARMA_LATENCY
CONDITIONAL_MANIFESTATION
YAJNA_NONBINDING
COSMOGRAPHY
GRAHA_GATI
RITUAL_TIMING
NARRATIVE_EXEMPLUM
NON_RELEVANT

Discourse-form labels

DEFINITION
CLASSIFICATION
PRESCRIPTION
PROHIBITION
ENUMERATION
DIALOGUE
CAUSAL_RULE

Typed assertions
उदाहरणतः Garuḍa chapter से:

कृत्तिका -> has_deity -> अग्नि
अश्विनी-group -> is_suitable_for -> प्रस्थान
विशाखात्रय + आदित्यवार -> forms_dosha -> उत्पात/रोग/मृत्यु
मूले + अर्क -> forms_amrita? if text warrants and annotation agrees

प्रत्येक gold sample का द्विवार manual review हो:

once by extractor/annotator
once by constitutional reviewer

Data model in PostgreSQL

इन tables का उपयोग किया जा सकता है।

7.1 passages

Fields:

passage_id
corpus_tier
text_source
work
book_or_kanda
chapter
verse_start
verse_end
normalization_branch
text_raw
text_norm
text_search
window_size
speaker
listener
setting
provenance_confidence

7.2 entities

entity_id
canonical_name
entity_type
variants_json
notes

7.3 assertions

assertion_id
passage_id
subject_id
relation_type
object_id
value_literal
confidence
created_by
branch_id

7.4 labels

passage_id
label
annotator
confidence
review_status

7.5 embeddings

passage_id
model_name
embedding vector
branch_id

7.6 benchmarks

benchmark_id
query
expected_passages
expected_assertions
expected_clusters
priority

यही relational base मेरी canonical memory होगी।

Operational graph schema in Neo4j

Use node labels like:

Passage
Work
Entity
Concept
DiscourseForm
Rule
Action
Yoga
Dosha
Deity
TimeUnit
NarrativeEvent

Use edges like:

MENTIONS
HAS_FORM
ASSERTS
MAPS_TO
SUITABLE_FOR
UNSUITABLE_FOR
FORMS_YOGA_WITH
FORMS_DOSHA_WITH
RIPENS_AS
MANIFESTS_WHEN
PRESUPPOSES
BELONGS_TO_CLUSTER

यह graph operational है, ultimate नहीं। इसकी legality अन्य स्तर पर जाँची जायेगी।

Constitutional validation with SHACL

SHACL यहाँ constitutional gate के रूप में काम करेगा। उदाहरणार्थ shapes इस प्रकार लिखे जा सकते हैं:

A Passage may have multiple HAS_FORM edges, but only from the legal discourse-form list.
A MAPS_TO edge of type maps_to_deity must connect Nakshatra -> Deity.
A forms_yoga_with relation must involve legal entity types.
A constitutional trunk cannot be demoted or deleted by automated redesign.
A passage cannot be promoted to canonical extraction exemplar without at least one review mark.

अर्थात् SHACL validation केवल syntax-जाँच नहीं, बल्कि constitutional legality की रक्षा का उपकरण होगा।

Retrieval architecture — day one से क्या कार्यशील होना चाहिए

10.1 Lexical layer

Use multiple textual views:

exact Devanagari
normalized Devanagari
transliterated view if needed
character n-grams
curated keyword dictionaries
regex/pattern rule hits

Whitespace tokenization पर मात्र अवलम्बित न हों। Sanskrit compounds तथा orthographic irregularities ऐसी सरलता को दण्ड देंगी।

10.2 Dense embedding layer

एक multilingual embedding model को baseline के रूप में रखें, final truth के रूप में नहीं।

10.3 Reranking layer

Initial retrieval के बाद multilingual reranker का उपयोग करें।

10.4 Graph traversal layer

Graph परिपक्व होने के पश्चात् query को lexical/dense results पर रोकें नहीं; उसे विस्तार दें:

entity neighbors
doctrinal neighbors
rule clusters
discourse-form siblings
community membership
10.5 Query fusion

Final score = weighted fusion of:

lexical score
dense score
reranker score
graph proximity score
constitutional trust score

अन्तिम पद अत्यन्त महत्त्वपूर्ण है। Primary corpus + reviewed extraction से प्राप्त result को secondary या sandbox material पर उचित वरीयता मिलनी चाहिए।

प्रथम model ecology

यहीं dual GPUs का यथार्थ उपयोग होगा। एक universal model न बनायें; एक model ecology बनायें।

11.1 Model A — Embedding retriever

Purpose:

semantic candidate generation

No constitutional authority. It only proposes.

11.2 Model B — Passage classifier

Purpose:

classify passages into labels such as
KALA_VIDHANA
COSMOGRAPHY
GRAHA_GATI
KARMA_LATENCY
YAJNA_NONBINDING
RITUAL_TIMING

यह प्रथम गम्भीर trainable model होगा।

11.3 Model C — Relation extractor

Purpose:

convert verse windows into typed assertions:
mapping
suitability
prohibition
yoga/doṣa
causation
ripening
non-binding action

यह आरम्भ में hybrid हो:

rules first
learned extraction later

11.4 Model D — Reranker

Purpose:

decide which retrieved passages are genuinely relevant

11.5 Model E — Graph specialist

Later only:

node classification
link prediction
community refinement

Active learning — annotation-सागर में डूबने से कैसे बचें

Half-million ślokas को हाथ से label नहीं करना चाहिए। इसका उत्तर active learning है।

12.1 Practical active-learning loop

Train a first weak classifier on gold samples.
Run it on a large unlabeled pool.
Select:
high-uncertainty passages
diverse passages far from already-labeled ones
passages from under-covered works
passages that cause constitutional conflicts
Annotate those.
Retrain.
Repeat.

12.2 यह यहाँ विशेष रूप से उपयुक्त क्यों है

क्योंकि इस परियोजना का क्षेत्र:

nuanced
low-resource
constitution-sensitive
relation-rich

है। अतः प्रत्येक labeled passage विचारपूर्वक चुना जाना चाहिए।

Dynamic redesign protocol

यही सम्पूर्ण योजना का हृदय है। Dynamic redesign को explicit बनाना होगा।

13.1 Redesign levels
Level 0 — Retrieval routing
Level 1 — Label refinement
Level 2 — Normalization redesign
Level 3 — Ontology redesign
Level 4 — Model redesign
Level 5 — Graph schema redesign

जैसे-जैसे स्तर ऊर्ध्व होगा, promotion test उतना ही कठोर होगा।

13.2 Branching policy

प्रत्येक redesign branch में होगा:

norm_branch_07
classifier_branch_jyotisha_v3
ontology_branch_kala_split
graph_branch_rule_nodes_v2

No silent mutation.

13.3 Promotion gate

किसी branch की promotion तभी हो जब:

benchmark recall सुधरे
noise threshold से अधिक न हो
SHACL legality बनी रहे
constitutional queries पर regression न हो
reviewer उस परिवर्तन का अर्थ समझ सके

अन्यथा वह sandbox branch ही रहे।

“वैदिक-अर्थ-विन्यास-दृष्टि” main corpus से कैसे सीखी जाये

इसे सूक्ष्म रूप से परिभाषित करना आवश्यक है। system को केवल keywords नहीं, बल्कि structural invariants सीखने होंगे।

14.1 क्या सीखना है

recurring discourse forms
concept families that cohere across works
stable oppositions such as visible/invisible, manifest/unmanifest, binding/non-binding
typical narrative-doctrine transfer patterns
centrality of time-order
centrality of classification
centrality of mappings between cosmic entities and human action

14.2 Practical induction methods

A. Co-occurrence graphs

Build co-occurrence networks from reviewed primary-corpus passages.

B. Frequent typed subgraph mining

Once typed assertions accumulate, mine recurrent patterns:

Nakshatra → Deity
Tithi + Vara → Doṣa
Action → SuitableUnder → NakshatraSet
Karma → Dormancy → ManifestsWhen → Condition

C. Community detection

Use graph communities to detect doctrinal neighborhoods, but only on reviewed or high-confidence edges.

D. Concept split proposals

If one node becomes too heterogeneous, propose a split. उदाहरणार्थ KALA may need sub-concepts:

cyclical time
admissibility time
ritual timing
calendrical units

किन्तु promotion reviewed ही रहेगी।

गरुड़ पुराण का ज्योतिष अध्याय : प्रथम serious template क्यों होना चाहिए

क्योंकि उसमें compressed form में लगभग पूरा engineering challenge निहित है। वह extractor को बाध्य करता है कि वह संभाले:

mapping
classification
orientation
suitability
prohibition
yoga/doṣa
naming
ritual timing
result language

अतः उस chapter से यह सब बनाया जाना चाहिए:

a gold JSONL file
a gold CSV of assertions
a gold graph export
a gold SHACL validation test
a gold retrieval benchmark

यह सब broader-scale model training से पहले होना चाहिए।

Recommended training sequence on your machine

Phase A — No neural training yet

Build:

canonical store
normalization branches
gold annotation workflow
lexical retrieval
first graph insertion
Phase B — Baseline semantic retrieval

Embed the primary corpus using a multilingual embedding model.

Phase C — Passage classifier training

Train a medium-sized classifier on your labels.
Use one GPU first.
Use both only when data is large enough.

Phase D — Multilingual reranker fine-tuning

Train/fine-tune a reranker on:

query-passage pairs
positive vs hard negative passages
Phase E — Relation extractor

Train a specialist model that converts verses/windows into typed assertions.
Still keep rules in the loop.
Do not trust pure neural extraction alone.

Phase F — Graph neural experiments

Only after enough graph density and label quality exist.
Use PyG heterogeneous graphs for:

node classification
edge scoring
missing-link proposals

Concrete GPU scheduling on dual 5090

17.1 Ingestion days

GPU0: dense embedding generation
GPU1: reranker inference over candidate pools or classifier training

17.2 Annotation-assistance days

GPU0: local model helping annotators with candidate labels and entity highlighting
GPU1: background training of next classifier branch

17.3 Heavy retraining days

both GPUs: DDP training for classifier/reranker
CPU/RAM: databases and graph services remain active

17.4 Query-serving mode

For interactive usage:

graph + Postgres stay on CPU/RAM
one GPU can host the reranker / embedding model
the other stays free for experiments

यही व्यवस्था system को training के समय भी usable बनाये रखेगी।

Benchmark design

आरम्भ से fixed benchmark suites आवश्यक हैं।

18.1 Retrieval benchmarks

Examples:

find all passages defining graha classes
find travel-suitability nakṣatra rules
find passages where karmic fruit remains dormant
find passages on yajña giving non-binding fruit
find Meru as geometric frame, not just name mention

18.2 Extraction benchmarks

From gold chapters:

deity mappings
action-suitability rules
doṣa/yoga rules
causal-temporal rules
narrative-encoded doctrine

18.3 Constitutional benchmarks

ऐसी queries जिनमें primary corpus का वर्चस्व अपेक्षित हो, जब तक कोई विशेष कारण अन्यथा सिद्ध न करे।

18.4 Regression benchmarks

प्रत्येक promoted redesign को older tests पर चलाना ही होगा। यदि नया model एक subdomain सुधारकर दूसरे को नष्ट कर दे, तो वह promoted न हो।

Runtime query flow

मान लीजिये query हो:

Find all passages where karmic fruit remains dormant until total karmic condition permits manifestation, especially where connected with kāla, yajña, or cosmic cycle.

तब runtime system को यह करना चाहिए:

parse the query into constitutional concepts
activate ontology trunks
retrieve lexical candidates
retrieve dense candidates
expand through graph neighborhoods
rerank with specialist model
group results by discourse form:
definition
causal rule
narrative exemplum
ritual exception
prefer primary corpus
display passages + extracted assertions + graph path

यह mere search नहीं, doctrinal traversal है।

क्या automate करना है और क्या नहीं

Automate
normalization proposals
candidate extraction
uncertainty-driven annotation queues
embedding generation
graph insertion
benchmark reporting
branch comparison
SHACL legality checks
Do not fully automate
Level 0 constitutional roots
final promotion of new trunk concepts
replacement of gold labels
silent reinterpretation of primary corpus
canonical status of secondary-corpus proposals

यही intelligence और drift के बीच की सीमा है।

Theoretical objective function

पूरे system को अनुशासित रखने के लिए objective function स्पष्ट होना चाहिए। system को यह maximize करना चाहिए:

constitutional recall
structural extractability
interpretability
retrieval fidelity
graph coherence

और यह minimize करना चाहिए:

drift from primary-corpus constitution
unreviewed ontology growth
hallucinated relations
over-dependence on secondary texts
regression on benchmark suites

यदि objective function स्पष्ट न होगा, तो system सुविधा-प्रेरित engineering की ओर ढल जायेगा।

निष्कर्ष — सिद्ध निष्पत्ति

सम्पूर्ण संवाद का द्वन्द्वात्मक परीक्षण एक अत्यन्त स्पष्ट निष्कर्ष देता है।

इस परियोजना का कार्य यह नहीं है:

a chatbot
a simple search engine
a thesaurus
a literal WBE system

इस परियोजना का कार्य यह है:

a constitutionally governed, self-restructuring, primary-corpus-led knowledge architecture

जिसका Level 0 Amarakośa-derived grand semantic architecture होगा, Level 1 primary-corpus constitutional ontology होगी, और Level 2 fluid specialist rewiring होगी।

इसका implementation इस क्रम में चलना चाहिए:

write the constitution
preserve raw corpus and create versioned normalizations
annotate a constitutional gold set
build PostgreSQL + pgvector as canonical store
build Neo4j as operational graph
validate legality with RDF/SHACL via pySHACL
deploy hybrid retrieval
train classifier and reranker before any giant generative experiment
use active learning to expand annotation efficiently
allow redesign only through versioned, benchmarked branches

यही सही theoretical methodology और practical engineering plan है।

उत्कर्ष — इस विधि का फल

यदि यह योजना सम्यक् रूप से कार्यान्वित हुई, तो इस परियोजना का system केवल “search better” नहीं करेगा। वह corpus-native order को पुनः उद्घाटित करना आरम्भ करेगा — न किसी कृत्रिम ऋषि-अभिनय से, न modern taxonomy की पुनरुक्ति से, बल्कि ऐसे machine-निर्माण से जिसमें:

primary corpus defines law
secondary corpus offers amendments
dynamic plasticity exists, but under constitution
retrieval becomes traversal of an internally ordered civilization-scale memory field

यही गम्भीर अनुसन्धानीय कार्यक्रम है। यह केवल scholastic chatter नहीं है।

Proposed project के लिये Normalization की वास्तविक विधि

वैदिक-अर्थ-विन्यास-दृष्टि की रक्षा करते हुए corpus को कार्ययोग्य बनाना

भूमिका

अब हम उस बिन्दु पर पहुँचे हैं जहाँ अधिकांश लोग भूल करते हैं। वे सोचते हैं कि text मिल गया, अब उसे “clean” कर दो, फिर embedding बना दो, फिर search चल पड़ेगा। यही पहली बड़ी भूल है।

मेरे proposed project में Normalization केवल सफाई नहीं है। वह संविधान-सम्मत पाठ-रक्षा है। उसका ध्येय यह नहीं कि text को modern computer की सुविधा के लिये रौंद दिया जाये; उसका ध्येय यह है कि:

मूल पाठ अक्षुण्ण रहे,
machine के लिये कार्ययोग्य रूप बने,
अनेक स्तरों पर अलग-अलग उपयोग हेतु भिन्न textual views बनें,
और किसी भी स्तर पर मूल पाठ का अपहरण न हो।

अतः मैं आरम्भ में ही एक कठोर नियम रखता हूँ:

Raw text is sacred. Normalized text is operational. Canonical text is derived.

अर्थात्:

Raw text = मूल साक्ष्य
Normalized text = machine-कार्य हेतु अनुशासित रूप
Canonical text = search, extraction, graph, training के लिये निर्मित रूप

यदि यह भेद नहीं रखा गया, तो पूरा project आगे चलकर अविश्वसनीय हो जायेगा।

पूर्वपक्ष

Normalization का यथार्थ अर्थ

Normalization का अर्थ केवल यह नहीं कि extra space हटा दिये, broken lines जोड़ दिये, और punctuation समान कर दी। वह तो अल्प भाग है। उसका यथार्थ अर्थ है:

एक ही textual material के अनेक lawful forms बनाना, जिनमें प्रत्येक form का प्रयोजन स्पष्ट हो, provenance स्पष्ट हो, और rollback सम्भव हो।

इसलिए मेरा पहला सिद्धान्त यह है कि एक text के कम से कम ये स्तर बनेंगे:

N0 — Raw preserved

जैसा source में आया, वैसा ही।

N1 — Unicode normalized

जहाँ केवल Unicode-अनुशासन हुआ।

N2 — Layout normalized

जहाँ line-break, heading, punctuation, spacing आदि अनुशासित हुए।

N3 — Structural segmentation

जहाँ chapter, verse, colophon, speaker markers, section markers आदि पहचाने गये।

N4 — Search canonicalization

जहाँ search और retrieval हेतु कुछ अतिरिक्त derived forms बने।

N5 — Scholarly enriched layer

जहाँ concepts, variants, relation-hints, grammatical hints, discourse-role hints आदि जुड़े।

इनमें से कोई भी स्तर दूसरे को नष्ट नहीं करेगा। प्रत्येक स्तर पृथक् रखा जायेगा।

“Clean text” की आधुनिक भूल

अनेक लोग OCR text पाते ही यह करते हैं:

सभी punctuation हटा देते हैं
दण्ड । और ॥ को तुच्छ मान लेते हैं
line breaks मिटा देते हैं
headings को body text में मिला देते हैं
colophon हटा देते हैं
अव्यय-पदों को stop-word मान लेते हैं
variant spellings को जबरदस्ती एक बना देते हैं
sandhi और compound को अपने अनुमान से तोड़ देते हैं

यह सब मेरे project में घातक होगा।

उदाहरण १

यदि text में है:

इति श्रीमहाभारते शान्तिपर्वणि…

और colophon को delete कर दिया, तो एक महत्त्वपूर्ण structural boundary marker नष्ट हो गया।

उदाहरण २

यदि text में है:

अथ नामलिङ्गानुशासनम्

और heading को body text में मिला दिया, तो एक constitutional marker नष्ट हो गया।

उदाहरण ३

यदि text में है:

श्वः, ह्यः, अधुना, सह, विना

और इन्हें generic stop-word मानकर हटा दिया, तो relation-layer ही नष्ट हो गया। तृतीय काण्ड की शिक्षा व्यर्थ हो गयी।

अतः Normalization का पहला नियम है:

Never destroy signal in the name of cleaning.

मेरे project में Normalization के मुख्य लक्ष्य

Normalization के चार प्रधान लक्ष्य होंगे:

(क) पाठ-रक्षा

मूल साक्ष्य सुरक्षित रहे।

(ख) यन्त्र-कार्य-सुलभता

Machine को stable input मिले।

(ग) बहु-दृष्टि निर्माण

एक ही पाठ के भिन्न उपयोगों के लिये भिन्न views बनें।

(घ) वैदिक-अर्थ-विन्यास-दृष्टि की रक्षा

Text को modern flat data में न बदला जाये।

किस प्रकार की अशुद्धियाँ और भेद मिलेंगे

जब Mahābhārata, Rāmāyaṇa, Purāṇas, Amarakośa, typed text, copied web text, PDF extraction, OCR text, commentary material, manual transcription—सबको एक corpus में लायेंगे, तब निम्न प्रकार के दोष और भेद मिलेंगे:

४.१ Unicode-सम्बन्धी दोष

hidden control characters
zero-width joiner / non-joiner
mixed normalization forms
copied web text with invisible characters

४.२ लिपि-सम्बन्धी भेद

Devanagari
IAST
Harvard-Kyoto
SLP1
WX
Roman + Devanagari mixed text
half-correct transliteration

४.३ Layout-सम्बन्धी दोष

arbitrary line breaks
broken verses across lines
multiple verses in one line
chapter heading merged into verse
colophon merged into body
footnote merged into body

४.४ OCR-दोष

द / ध, ब / व, श / ष confusion
anusvāra / chandrabindu confusion
danda missing or duplicated
ligatures broken
numeral read as letter
wrong word splitting

४.५ पाठभेद

same verse with slight spelling variation
alternate chapter numbering
commentary mixed into source text
recension differences

४.६ grammatical and semantic ambiguity

compounds split differently
visarga present in one source, absent in another
same surface word, multiple sense
vocative mistaken as nominative
proper noun mistaken as common noun

अतः Normalization साधारण mechanical step नहीं, बल्कि एक बहु-स्तरीय शास्त्र है।

उत्तरपक्ष

अब कुछ सामान्य भ्रान्त धारणाओं का निवारण करता हूँ।

आपत्ति १

“सबसे पहले एक final clean text बना लो, फिर उसी पर सब काम करो।”

यह भूल है।
एक final clean text नहीं होगा।
एक text family होगी।

आपत्ति २

“Raw text को क्यों बचाना? Corrected text ही पर्याप्त है।”

यह भी भूल है।
क्योंकि correction स्वयं एक व्याख्या है।
यदि raw खो गया, तो भविष्य में correction की परीक्षा असम्भव हो जायेगी।

आपत्ति ३

“Normalization जितनी aggressive होगी, retrieval उतना अच्छा होगा।”

यह आधा-सत्य है।
कुछ search tasks के लिये aggressive normalization उपयोगी हो सकती है।
किन्तु यदि वही एकमात्र text बना, तो philological, grammatical, doctrinal, operator-sensitive, variant-sensitive कार्य नष्ट हो जायेंगे।

आपत्ति ४

“OCR error correction को पूर्ण स्वचालित कर दो।”

नहीं।
OCR correction के तीन स्तर होंगे:

safe automatic correction
probable correction
uncertain correction requiring review

तीनों को मिलाना नहीं है।

सन्धि

अब सम्यक् रूप यह है:

Normalization = बहु-स्तरीय, reversible, provenance-aware textual discipline

उसकी रचना में पाँच मूल नियम होंगे:

नियम १

Preserve first, derive later.

नियम २

One source text may yield many lawful operational forms.

नियम ३

Every transformation must be recorded.

नियम ४

No destructive normalization.

नियम ५

Different tasks need different text views.

इसी आधार पर अब वास्तविक कार्य-विधि लिखता हूँ।

सन्धान — actual practical method

अब मैं सीधी कार्य-विधि देता हूँ। यही project की वास्तविक कार्य-आरम्भ-रेखा होगी।

चरण १ — Corpus acquisition discipline

सबसे पहले कोई भी text database में डालने से पहले उसका source manifest बनाइये।

प्रत्येक source के लिये यह information रखिये:

source_id
title
work_name
corpus_tier
source_type
script
provenance
download_date
checksum
notes

source_type के प्रकार:

scan
OCR
typed text
web text
epub
pdf extraction
manual transcription
उदाहरण

यदि Amarakośa Sanskrit Documents से मिला, तो वह एक source है।
यदि वही text archive scan से OCR करके मिला, तो वह दूसरा source है।
यदि Mahābhārata किसी website से copied text के रूप में मिला, तो वह तीसरा source है।

यह चरण कभी मत छोड़िये।

चरण २ — Raw preservation

हर source file को immutable रूप में रखिये।
कोई editing नहीं।

यदि PDF है, PDF रखिये।
यदि OCR text है, वैसा ही रखिये।
यदि copied HTML है, वही raw रूप सुरक्षित रखिये।

Directory उदाहरण
data/raw/tier0_amarakosha/source_001.txt
data/raw/primary/mahabharata/source_042.txt
data/raw/primary/ramayana/source_017.html
data/raw/primary/purana/source_088.txt

Manifest table में यह सब जुड़ा होना चाहिए।

चरण ३ — Unicode normalization

अब पहला derived text बनाइये: Unicode-normalized text।

यहाँ केवल safe operations होंगे।

Safe operations
Unicode normalization form एक मानक पर लाना
zero-width characters हटाना
strange web-copy artifacts हटाना
repeated non-printing characters हटाना
invisible separators हटाना
क्या नहीं करना
spelling correction नहीं
punctuation interpretation नहीं
chapter splitting नहीं
OCR guessing नहीं
उदाहरण

Raw:
अमर\u200cकोशः

N1:
अमरकोशः

Raw:
अन्त में hidden non-breaking space

N1:
same visible text, only invisible दोष हटे

यहाँ केवल invisible दोष हटे हैं; text का अर्थ नहीं बदला।

चरण ४ — Script discipline

Project में अनेक scripts आयेंगी। अतः script-handling policy पहले ही बनाइये।

मूल नियम
canonical display text = Devanagari
transliteration views = derived
no Roman or WX text should replace Devanagari primary view

क्यों?

क्योंकि मुख्य corpus Devanagari-oriented होगा, और doctrinal reading भी उसी में अधिक स्वाभाविक है।

किन derived views की आवश्यकता होगी?
IAST view
ASCII transliteration view
phonetic normalized view
search view
उदाहरण

धर्मक्षेत्रे

से derived:

IAST: dharmakṣetre
ASCII: dharmakshetre
phonetic search: dharmakshetre

किन्तु canonical text फिर भी Devanagari ही रहे।

चरण ५ — Layout normalization

अब line-break, spacing, heading, punctuation आदि का अनुशासन कीजिये।
यहाँ बड़ी सावधानी चाहिए।

५.१ Heading की पहचान

जैसे:

अथ नामलिङ्गानुशासनम्
नारद उवाच
भीष्म उवाच
इति … अध्यायः

इनको body text में नहीं मिलाना।
इन्हें structural markers के रूप में tag कीजिये।

उदाहरण

Raw:

अथ नामलिङ्गानुशासनम्
स्वर्गो द्यौर्दिव…

N2:

heading = अथ नामलिङ्गानुशासनम्
body starts from next line
५.२ Danda discipline
।
॥
missing danda
doubled danda
Western punctuation mixed with danda

इनको normalize करना होगा, पर rule-based।

उदाहरण

Raw:
स्वर्गो द्यौर्दिव त्रिदिवम्..

N2:
स्वर्गो द्यौर्दिव त्रिदिवम्॥

यदि correction highly probable है, तो करें, पर annotation रखें कि यह inferred danda है।

५.३ Space discipline
multiple spaces → one space
spaces before danda हटें
spaces after danda standardized हों
words के भीतर broken spaces review से जुड़ें
उदाहरण

धर्म क्षेत्रे → safe join
पर
धर्म क्षे त्रे → uncertain; review queue में जाये

चरण ६ — Structural segmentation

अब text को अर्थपूर्ण units में विभक्त करना होगा।

६.१ Minimum units
document
chapter
verse
verse window
colophon
heading
speaker segment
६.२ Verse segmentation rules

Devanagari texts में verse boundary प्रायः । और ॥ से मिलती है, किन्तु सदा नहीं।

इसलिए rules यह होंगे:

Rule A
यदि ॥ हो, strong verse-end marker

Rule B
यदि single danda repeated pattern में हो, verse half marker

Rule C
यदि colophon line हो, chapter boundary

Rule D
यदि उवाच style marker हो, discourse segment break

Rule E
यदि heading हो, section boundary

६.३ Multi-granularity storage

प्रत्येक text के लिये store करें:

verse
3-verse window
7-verse window
chapter block

क्यों?

क्योंकि:

definition कभी एक verse में होगी,
classification 3-verse window में खुलेगी,
narrative-causal structure 7-verse window में दिखेगी,
thematic unity chapter-level पर दिखेगी।

चरण ७ — Canonical search forms

अब derived search views बनते हैं।
यहीं लोग प्रायः अति कर देते हैं।

मैं चार search views की अनुशंसा करता हूँ।

७.१ Exact view

Devanagari exact normalized text

उपयोग:

exact phrase search
witness comparison
quotation recovery
७.२ Soft normalized view

कुछ controlled normalization के साथ

उदाहरण:

extra visarga differences tolerated
danda standardized
spacing stabilized

उपयोग:

practical keyword search
७.३ Phonetic view

Approximate phonetic equivalence हेतु

उपयोग:

OCR-affected search
variant spelling recovery
७.४ Morph-aware view

जहाँ lexical form के साथ probable stem या lemma hint जुड़ा हो

उपयोग:

semantic grouping
concept normalization
relation extraction सहायता

चरण ८ — क्या normalize करना है, क्या नहीं

अब सबसे महत्त्वपूर्ण practical table देता हूँ।

८.१ Safe to normalize
invisible characters
repeated spaces
punctuation glyph variants
obvious line-break artifacts
standard danda usage
heading separation
chapter numbering markers
script encoding issues
८.२ Normalize with review
probable OCR correction
word joining/splitting
inferred danda
visarga restoration
anusvāra restoration
numeral correction
transliteration correction
८.३ Never auto-normalize destructively
sandhi resolution
compound splitting
semantic disambiguation
polysemous word replacement
deity-name correction based on guess
chapter reordering
colophon deletion
variant suppression
उदाहरण

यदि किसी source में अथर्ववेदः और किसी में अथर्ववेद है, तो raw स्तर पर दोनों अलग रहें। Search canonicalization में उन्हें linked variant group में रखा जा सकता है; मूल को मत मिटाइये।

चरण ९ — OCR correction policy

यह actual work का मुख्य भाग होगा।

OCR correction को तीन classes में बाँटिये।

Class A — safe automatic

जहाँ correction लगभग निश्चित है

उदाहरण

| की जगह ।
double spaces
invisible Unicode junk
obvious repeated punctuation
Class B — probable

जहाँ correction प्रबल सम्भाव्य है, किन्तु certainty पूर्ण नहीं

उदाहरण

.. → ॥
dropped visarga restoration
likely danda insertion

ऐसी corrections machine कर सकती है, किन्तु review_needed = true होना चाहिए।

Class C — uncertain

human review अनिवार्य

उदाहरण

भाग्याश्च — OCR defect है या वैकल्पिक पाठ?
इल्वलाः — corruption है या परम्परागत पाठ?
नानार्थ बनाम नानार्थः — context-dependent?

Class C को कभी silent-correct मत कीजिये।

चरण १० — Variant management

एक ही verse के अनेक readings मिलेंगे। इनके लिये variant architecture चाहिए।

मुख्य नीति
one operational reading may be chosen for retrieval convenience
but alternate readings remain attached
Representation
variant_group_id
reading_a
reading_b
source_links
confidence
preferred_for_operational_use
notes
उदाहरण

यदि एक source में colophon पूरा है और दूसरे में truncated है, तो:

दोनों readings रखें
one operational preference चुनें
graph और retrieval में दोनों का link रखें

चरण ११ — Speaker, discourse, colophon tagging

Project में यह अत्यन्त महत्त्वपूर्ण है।

Tag these explicitly:

speaker
listener
heading
colophon
chapter_end
section_start
definition
classification
enumeration
injunction
prohibition
exception
narrative_support
उदाहरण

भीष्म उवाच।

discourse_marker = speaker_change
speaker = भीष्म

इति श्रीरामायणे…

colophon = true
chapter_end = true

यह tagging बाद में retrieval, graph construction, and constitutional scoring में अत्यन्त उपयोगी होगी।

चरण १२ — Concept / Entity normalization

अब text से concepts और entities निकालनी होंगी, किन्तु यह direct modern NER खेल नहीं है। Sanskrit corpus में यह अत्यन्त सावधानी माँगता है।

आरम्भिक classes
deity / divine class
place
time unit
person role
work
chapter marker
doctrinal concept
action
quality
relation-operator
उदाहरण
अग्नि → कभी deity, कभी element, कभी ritual-fire
लोक → कई अर्थ
मूल → root भी हो सकता है, proper term भी
हरि → context-dependent

अतः normalization के साथ sense disambiguation जुड़ा होगा।

चरण १३ — Grammar-aware normalization

अब तृतीय काण्ड की शिक्षा लागू होगी।

१३.१ Qualifier vs entity
श्रेष्ठ entity नहीं; qualifier
अशुभ result-tag हो सकता है
निपुण quality है, पदार्थ नहीं
१३.२ Operator words
सह
विना
प्राग्
अधुना
युगपत्
पृथक्

इनको stop-word नहीं मानना।
ये relation या context operators हैं।

१३.३ Polysemy awareness

एक ही surface word को एक node मत बनाइये।
Use:

surface form
sense candidates
context-based selection

Normalization stage में केवल इतना करें कि word-form stable हो।
अर्थ-निश्चय बाद की stage में होगा।

चरण १४ — Database ingestion workflow

अब actual pipeline इस प्रकार चलेगी:

Step A
Source file register करो

Step B
Raw preserve करो

Step C
N1 Unicode normalize करो

Step D
N2 layout normalize करो

Step E
N3 segmentation करो

Step F
N4 search views बनाओ

Step G
Concept / entity hints attach करो

Step H
PostgreSQL tables में insert करो

Step I
Graph export बनाओ

Step J
Review queue बनाओ

इस pipeline को एक ही script से नहीं, बल्कि modular pipeline से चलाइये।

चरण १५ — Review queues

सारा काम human review के बिना नहीं चलेगा। इसलिए review queues बनाइये।

Queue types
OCR uncertain
boundary uncertain
concept uncertain
variant conflict
discourse-form uncertain
chapter metadata uncertain
उदाहरण

यदि doubt है कि कोई पंक्ति heading है या body text, तो boundary_uncertain queue में जाये।
यदि कोई शब्द कई senses ले सकता है, तो concept_uncertain queue में जाये।

चरण १६ — Practical examples

अब कुछ छोटे वास्तविक examples देता हूँ।

Example A — Safe normalization

Raw:

नारद उवाच।
धर्मो रक्षति रक्षितः।

N1:
same, only invisible junk removed

N2:

speaker = नारद
discourse_marker = उवाच
verse text separate
Example B — Heading and body separation

Raw:

अथ नामलिङ्गानुशासनम्

N2:

heading = अथ नामलिङ्गानुशासनम्
section_type = chapter_heading
Example C — Classification extraction preparation

Raw:

स्वर्गो द्यौर्दिवं त्रिदिवं…

Normalization alone should do:

verse boundary identify
text stable

Extraction stage later will do:

concept family = heaven / celestial region
discourse role = definition / synonym cluster

Normalization stage must not prematurely guess the full graph assertion.

Example D — Polysemy-sensitive preservation

Raw:
लोक

Do not auto-normalize to:

world
region
people
visible sphere

Keep surface form intact.
Context-based layer will later decide sense.

चरण १७ — File formats

मैं practical उपयोग के लिये यह structure recommend करता हूँ।

Raw files
.txt
.html
.pdf
.json
Intermediate normalized exports
.jsonl
.parquet
Why JSONL?

क्योंकि प्रत्येक passage एक self-contained record बन सकता है।

Example JSONL record
{
"passage_id": "amarakosha_001_001",
"work": "Amarakosha",
"chapter": 1,
"verse_start": 1,
"verse_end": 1,
"normalization_branch": "n3_segmented_v1",
"text_raw": "स्वर्गो द्यौर्दिवं त्रिदिवं…",
"text_norm": "स्वर्गो द्यौर्दिवं त्रिदिवं…",
"speaker": null,
"heading": "अथ नामलिङ्गानुशासनम्",
"review_status": "unchecked"
}

चरण १८ — Z890 + dual RTX 5090 पर actual execution plan

अब machine-level practical work।

CPU + RAM tasks
raw file management
PostgreSQL
Neo4j
SHACL validation
JSONL/Parquet transforms
review dashboards
deterministic normalization
GPU0 tasks
embedding generation
reranker inference
annotation assistance
semantic candidate search
GPU1 tasks
classifier training
OCR-error suggestion model
relation extractor training
disambiguation model training
Why not use GPU for everything?

क्योंकि normalization का बड़ा भाग:

deterministic
rule-based
text-processing-heavy
database-oriented

है, और CPU + RAM पर ही अधिक स्वाभाविक है।

GPU वहाँ लगाइये जहाँ:

pattern learning
ranking
disambiguation
extraction
branch training

आवश्यक हो।

चरण १९ — Common mistakes to avoid

भूल १

Raw overwrite कर देना

भूल २

One final clean text बना देना

भूल ३

OCR correction बिना provenance के करना

भूल ४

All punctuation delete कर देना

भूल ५

Avyaya को stop-word मान लेना

भूल ६

Polysemous words को एक ही entity बना देना

भूल ७

Chapter headings और colophons हटाना

भूल ८

Search view को canonical witness बना देना

भूल ९

Secondary corpus के cleaner text को primary corpus के raw text पर बलपूर्वक लाद देना

भूल १०

Normalization और interpretation को मिला देना

निष्कर्ष

मेरे proposed project में Normalization किसी text-cleaning utility का नाम नहीं है। वह एक विधिसम्मत, बहु-स्तरीय, reversible, provenance-aware textual discipline है, जिसका कार्य है:

मूल पाठ की रक्षा
machine के लिये अनेक operational forms का निर्माण
doctrinal, grammatical, structural और graph-based कार्यों हेतु अलग-अलग views की व्यवस्था
तथा किसी भी चरण पर मूल signal का विनाश रोकना

यदि यह चरण ठीक से हुआ, तो आगे:

extraction विश्वसनीय होगा
graph schema स्वस्थ बनेगा
training data स्वच्छ होगा
disambiguation सम्भव होगी
और constitutional architecture टिकाऊ बनेगी

यदि यह चरण बिगड़ा, तो आगे के सारे advanced models, dual RTX 5090, graph reasoning, reranking—सब केवल अधिक तीव्र भ्रम उत्पन्न करेंगे।

उत्कर्ष

अब तक की रचना में क्रम यह हुआ:

Amarakośa Kanda 1 = ऊर्ध्व-विश्व और महा-अर्थ-विन्यास
Kanda 2 = भूतल, जीव, मनुष्य और समाज-विन्यास
Kanda 3 = शब्द-नियमन, operator-structure, grammar-aware अर्थ-नियमन
अब Normalization = उन सबको machine-कार्य में उतारने का प्रथम वास्तविक द्वार

Concept extraction, Passage-role detection, Relation extraction, और प्रथम जीवित Graph निर्माण की वास्तविक कार्य-विधि

भूमिका

अब तक यह स्थिर किया जा चुका है कि:

Level 0 पर Amarakośa-derived grand semantic architecture रहेगा,
Level 1 पर primary-corpus constitutional ontology रहेगी,
Level 2 पर fluid rewiring चलेगी, किन्तु constitutional restraint के अधीन,
और Normalization एक बहु-स्तरीय, reversible, provenance-aware textual discipline होगी।

अब अगला यथार्थ चरण यह नहीं है कि text से केवल कुछ नाम पकड़ लिये जायें।
अगला यथार्थ चरण है:

text से कौन-से concept निकाले जायें,
किसी passage की भूमिका क्या है,
passage किस प्रकार का ज्ञान-कार्य कर रहा है,
किन concepts के बीच कौन-सा relation बनता है,
कौन-से passages मिलकर एक cluster बनाते हैं,
और इन सबके आधार पर पहला जीवित knowledge-graph कैसे निर्मित हो।

यहीं से project keyword-search से उठकर complete knowledge retrieval system बनना आरम्भ करेगा।

यदि हम केवल entity पकड़कर रुक गये, तो system आधुनिक shallow NER tool बनकर रह जायेगा।
यदि हम आरम्भ में ही पूरा automatic deep semantic parsing करना चाहेंगे, तो system शीघ्र ही भ्रमपूर्ण relations और मिथ्या clusters से भर जायेगा।
अतः यहाँ भी वही मार्ग उचित है जो वैदिक-अर्थ-विन्यास-दृष्टि के अनुकूल है—न अत्यल्प, न अत्यधिक; बल्कि क्रमबद्ध, विधिसम्मत, review-सम्मत extraction।

पूर्वपक्ष

Extraction का वास्तविक अर्थ

इस project में extraction का अर्थ केवल “नाम पकड़ लेना” नहीं है।
वास्तविक extraction के पाँच स्तर होंगे:

(क) Concept extraction

text में कौन-से मुख्य अर्थ-केन्द्र हैं—जैसे लोक, काल, धर्म, कर्म, फल, राजा, ऋषि, वन, अग्नि, दिक्, नदी, तप, यज्ञ, नीति, शौर्य, दया, मृत्यु, बन्ध, मोक्ष, इत्यादि।

(ख) Passage-role detection

किसी passage का कार्य क्या है?
क्या वह:

definition दे रहा है,
classification कर रहा है,
procedure बता रहा है,
prohibition दे रहा है,
exception बता रहा है,
narrative exemplum दे रहा है,
lexical gloss दे रहा है,
metaphysical statement दे रहा है,
cosmological frame दे रहा है?
(ग) Relation extraction

कौन-से concepts किस प्रकार से जुड़े हैं?
जैसे:

defines
classifies
causes
governs
exemplifies
presupposes
limits
contrasts_with
exception_to
belongs_to
manifests_as
(घ) Cluster formation

ऐसे passages और concepts कौन-से हैं जो एक semantic family बनाते हैं?
उदाहरणतः:

cosmic ordering cluster
temporal doctrine cluster
karmaphala-vipāka cluster
polity cluster
forest-and-exile cluster
lexical-synonym cluster
prohibition cluster
(ङ) Query interpretation support

जब कोई दीर्घ प्रश्न आये, तो system यह समझ सके कि user को:

definition चाहिए,
procedure चाहिए,
indirect support चाहिए,
narrative evidence चाहिए,
alternative view चाहिए,
या conceptual family चाहिए।

अतः extraction का अन्तिम ध्येय isolated words नहीं, बल्कि conceptual evidence field है।

इस project में मूल इकाई क्या है?

यहीं सबसे बड़ी correction आवश्यक है।

पहले जो drift हुआ था, उसमें entity बहुत अधिक केन्द्रीय बन रही थी।
अब स्पष्ट करना होगा कि इस project की मूल इकाई surface word नहीं, और न ही isolated entity है।
मूल इकाइयाँ इस प्रकार होंगी:

२.१ Lexeme

शब्द-रूप, जैसा text में आता है।

२.२ Sense

उस शब्द-रूप का विशिष्ट अर्थ।

२.३ Concept

वह अर्थ-केन्द्र जो corpus में पुनरावृत्त, संगठित, और relations में प्रविष्ट होता है।

२.४ Passage-role

किसी passage का ज्ञान-कार्य।

२.५ Relation

दो concepts, या concept और passage, या cluster और concept के बीच type-सहित संबंध।

२.६ Cluster

semantic परिवार, जिसमें अनेक passages, अनेक concepts, और कभी-कभी अनेक works सम्मिलित हों।

इसलिए यदि text में लोक आया, तो system को यह समझना होगा कि:

यह केवल एक lexeme नहीं,
इसका एक या अधिक sense हो सकता है,
यह किसी wider concept cluster का भाग हो सकता है,
और passage की भूमिका के अनुसार इसका अर्थ बदल सकता है।

यही Amarakośa-सम्मत पद्धति है।

Concept क्या है?

Concept को वस्तु-संज्ञा तक सीमित करना भूल होगी।
Complete knowledge retrieval system में concept के कई प्रकार होंगे।

३.१ Cosmic concepts

लोक
दिशा
काल
अयन
ऋतु
युग
कल्प
सूर्य
चन्द्र
नक्षत्र
आकाश
मेरु
पृथिवी

३.२ Divine and metaphysical concepts

देव
पितृ
नाग
यक्ष
ब्रह्म
ईश्वर
माया
प्रकृति
पुरुष
तप
श्रद्धा

३.३ Doctrinal concepts

धर्म
कर्म
फल
विपाक
बन्ध
मोक्ष
दान
यज्ञ
सत्य
अहिंसा
कालविधान

३.४ Human-social concepts

राजा
मन्त्री
ब्राह्मण
शिष्य
गुरु
पुत्र
स्त्री
ग्राम
नगर
सेना
जनपद

३.५ Narrative-exemplary concepts

वनवास
प्रतिज्ञा
युद्ध
शरण
व्रत
भ्रातृभाव
द्यूत
परीक्षा
त्याग

३.६ Lexical-semantic concepts

पर्याय
नानार्थ
अव्यय
लिङ्ग
विशेषण
क्रिया-प्रवृत्ति
mixed semantic zone

स्पष्ट है कि concept का दायरा आधुनिक noun-detection से कहीं अधिक बड़ा है।

Passage-role क्या है?

Passage-role इस architecture का अत्यन्त केन्द्रीय अंग होगा।
क्योंकि एक ही concept भिन्न passages में भिन्न ज्ञान-कार्य कर सकता है।

मुख्य passage-roles
४.१ Definition

किसी concept का स्पष्ट अर्थ-निश्चय

४.२ Classification

किसी concept family के भेद

४.३ Enumeration

सूचीबद्ध प्रस्तुति

४.४ Procedure

किसी कर्म, विधि, क्रम, अनुष्ठान, या नीति की रचना

४.५ Injunction

करना चाहिए

४.६ Prohibition

न करना चाहिए

४.७ Exception

सामान्य नियम का अपवाद

४.८ Result statement

फल, प्रभाव, या outcome

४.९ Narrative exemplum

कथा के द्वारा doctrinal अर्थ की प्रतिष्ठा

४.१० Lexical gloss

किसी शब्द, नाम, या पर्याय का स्पष्टीकरण

४.११ Metaphysical statement

तत्त्व, सत्, ब्रह्म, जीव, माया आदि पर कथन

४.१२ Cosmological statement

लोक, दिशा, काल, विश्व-रचना, cosmic order सम्बन्धी कथन

यह passage-role detection retrieval quality का प्रधान आधार होगा।
क्योंकि user को प्रायः “जो शब्द आया है” वह नहीं चाहिए; उसे “किस प्रकार का उत्तर” चाहिए।

Relation क्या है?

अब relation को भी केवल subject-object triple तक सीमित नहीं रखना चाहिए।

मुख्य relation families इस प्रकार हो सकती हैं:

defines
classifies
belongs_to
governs
causes
results_in
supports
contrasts_with
presupposes
manifests_as
is_exception_to
is_exemplified_by
is_glossed_by
is_temporally_related_to
is_spatially_related_to

अर्थात relation extraction का लक्ष्य केवल छोटे triples नहीं, बल्कि typed semantic relations हैं।

Cluster क्यों चाहिए?

यदि system केवल passages और assertions का ढेर बनाकर छोड़ दे, तो complete knowledge retrieval सम्भव नहीं होगा।

Cluster की आवश्यकता इन कारणों से है:

parallel passages को साथ देखने के लिये
thematic family recovery के लिये
indirect relevance निकालने के लिये
mixed semantic zones को अलग चिह्नित करने के लिये
Amarakośa-constitutional trunks के अधीन semantic families बनाने के लिये
उदाहरण

यदि query कर्मफल-विपाक पर है, तो system को केवल कर्म शब्द वाले passages नहीं देने चाहिए, बल्कि वह cluster बनाना चाहिए जिसमें:

कर्म
फल
विपाक
काल
बन्ध
मोक्ष
यज्ञ-अबन्धकर्म
narrative exempla

सब किसी न किसी घनिष्ठ semantic सम्बन्ध में आयें।

उत्तरपक्ष

अब कुछ मुख्य भ्रान्तियों का निरसन।

भ्रान्ति १

“पहले general NER model चलाइये, फिर उससे graph बना लीजिये।”

यह परियोजना के लिये पर्याप्त नहीं।
क्योंकि:

कई मूल शब्द entity नहीं, concept हैं,
अनेक महत्त्वपूर्ण पद qualifier या operator होंगे,
अनेक passages की मुख्य शक्ति role में होगी, noun में नहीं,
और complete knowledge retrieval को केवल named entities नहीं चाहिए।
भ्रान्ति २

“Passage-role बाद में देखेंगे; पहले words पकड़ें।”

यह भी भूल है।
क्योंकि कई passages की वास्तविक सार्थकता उसी के role में है।

उदाहरणतः:

कोई passage definition दे रहा हो
कोई मात्र narrative support दे रहा हो
कोई exception दे रहा हो

यदि role नहीं पहचाना गया, तो retrieval गलत प्रकार के evidence देगा।

भ्रान्ति ३

“Graph सीधे subject-relation-object triples से पर्याप्त बन जायेगा।”

कई स्थानों पर नहीं।
क्योंकि:

अनेक relations cluster-mediated होंगे,
कई passages multi-concept family बनाएँगे,
mixed zones simple triples से नहीं पकड़े जायेंगे,
passage-role स्वयं graph का भाग होगा।

अतः graph को passage-role, cluster, relation-family, और concept-sense distinction सब सँभालना होगा।

सन्धि

अब समुचित synthesis यह है:

extraction के मुख्य चरण होंगे:
lexical detection
concept candidate formation
passage-role detection
relation extraction
cluster suggestion
review
graph insertion

और यह कार्य तीन शक्तियों के संयुक्त प्रयोग से होगा:

deterministic rules
machine-learned proposals
human review

इसी मध्य मार्ग से system न shallow रहेगा, न भ्रमपूर्ण।

सन्धान — actual practical implementation

अब मैं पूर्ण कार्य-विधि देता हूँ।

चरण १ — Concept lexicon banks बनाइये

हाँ, lexicon अभी भी आवश्यक हैं; किन्तु अब वे केवल entity lexicon नहीं होंगे।

१.१ Core concept lexicon

इसमें भिन्न constitutional trunks के concepts रखिये:

cosmic concepts
temporal concepts
human-social concepts
doctrinal concepts
lexical-semantic concepts
ritual concepts
narrative motifs
१.२ Variant lexicon

एक concept के अनेक forms:

देवनागरी variants
transliteration variants
sandhi variants
recension variants
१.३ Passage-role cue bank

जैसे:

उच्यते, स्मृतः, प्रोक्तः → definition/mapping cue
न कारयेत्, वर्जयेत् → prohibition cue
यदा … तदा → conditional/temporal cue
इति श्री…अध्यायः → colophon cue
१.४ Relation cue bank
इत्युच्यते
भेदाः
फलम्
कारणम्
हेतु
अतः
विना
सह
अपि
तु
एषु
तदा

अब lexicon banks का प्रयोजन बदल गया है।
वे केवल names पकड़ने के लिये नहीं, बल्कि concept-role-relation field तैयार करने के लिये हैं।

चरण २ — Passage pre-tagging

हर verse, verse-window, chapter-block पर pre-tagging चलाइये।

Output fields:

concept_hits
qualifier_hits
operator_hits
possible_passage_roles
possible_relations
uncertainty_score
उदाहरण

यदि किसी passage में:

अनेक पर्याय हैं
repeated definitional cues हैं

तो:

possible role = definition / lexical gloss

यदि:

विना, सह, यदा, तदा
temporal or causal structure

तो:

possible role = procedure / condition / exception

यह अभी final नहीं, केवल preparation है।

चरण ३ — Passage-role detection

अब passage-role detection को केन्द्रीय बनाइये।

इसका model या rule-system निम्न आधारों पर चले:

cue words
structure
list-pattern
clause pattern
negation pattern
colophon pattern
dialogue pattern
narrative density
repeated synonymy density
Output

प्रत्येक passage पर एक या अधिक role tags:

DEFINITION
CLASSIFICATION
ENUMERATION
PROCEDURE
INJUNCTION
PROHIBITION
EXCEPTION
RESULT_STATEMENT
NARRATIVE_EXEMPLUM
LEXICAL_GLOSS
METAPHYSICAL_STATEMENT
COSMOLOGICAL_STATEMENT
COLOPHON

यह step extraction का हृदय है।

चरण ४ — Concept candidate formation

अब lexical hits को सीधे graph node मत बनाइये।
पहले candidate concepts बनाइये।

प्रत्येक candidate में:
surface form
probable concept family
probable constitutional trunk
possible senses
confidence
review_required
उदाहरण

लोक

candidate sense 1 = world-region
candidate sense 2 = people
candidate sense 3 = cosmological plane
उदाहरण

अग्नि

candidate sense 1 = deity
candidate sense 2 = ritual fire
candidate sense 3 = elemental fire

यहाँ system को surface form और concept को पृथक् रखना ही होगा।

चरण ५ — Relation extraction

अब relation extraction कीजिये।
किन्तु relation extraction का अर्थ केवल binary edge नहीं।

५.१ direct relations

जहाँ passage sufficiently clear हो

उदाहरण:

X defines Y
X belongs_to Y
५.२ role-conditioned relations

जहाँ relation passage-role पर निर्भर हो

उदाहरण:

यदि role = classification, तो list-items -> belongs_to class
यदि role = definition, तो concept -> defined_by passage
५.३ narrative support relation

यदि role = narrative_exemplum, तो:

concept is exemplified by passage/event
५.४ exception relation

यदि cue indicates exception:

concept/rule -> has_exception -> passage/concept

इसलिए relation extractor को role-aware बनाइये।

चरण ६ — Cluster suggestion

अब concepts और passages से preliminary clusters बनाइये।

cluster seed sources
shared concept family
shared passage-role
repeated relation pattern
lexical overlap
dense embedding similarity
constitutional trunk proximity
cluster examples
cosmic ordering cluster
temporal doctrine cluster
forest / exile cluster
kingship / polity cluster
karmaphala cluster
lexical synonym cluster
prohibition cluster
exception cluster

किन्तु clusters को पहले suggested रखिये, final नहीं।

चरण ७ — Review architecture

अब review objects बदल चुके हैं।
अब review केवल mentions के लिये नहीं, बल्कि इन सबके लिये होगा:

concept assignment
sense selection
passage-role assignment
relation extraction
cluster membership
constitutional trunk assignment
review levels
Level A — quick review

high-confidence concept or role

Level B — detailed review

ambiguous sense or relation

Level C — constitutional review

new cluster, new relation family, trunk conflict, mixed-zone issue

review screen को यह दिखाना चाहिए:
raw text
normalized text
verse window
surrounding context
concept candidates
role candidates
relation candidates
cluster suggestions
reviewer edit controls

चरण ८ — प्रथम जीवित Graph निर्माण

अब graph schema को भी corrected center पर बनाइये।

८.१ Node types
Passage
Lexeme
Sense
Concept
PassageRole
Relation
ConceptCluster
Work
Chapter
८.२ Basic edges
MENTIONS_LEXEME
HAS_SENSE_CANDIDATE
EXPRESSES_CONCEPT
HAS_ROLE
SUPPORTS_RELATION
BELONGS_TO_CLUSTER
BELONGS_TO_WORK
BELONGS_TO_CHAPTER
PARALLEL_TO
EXCEPTION_TO
EXEMPLIFIES
८.३ Why conservative first graph?

क्योंकि आरम्भ में यदि direct semantic closures बहुत अधिक कर दिये गये, तो graph भ्रमपूर्ण हो जायेगा।
पहले provenance-rich graph बनाइये।

उदाहरण:

Passage → HAS_ROLE → DEFINITION
Passage → EXPRESSES_CONCEPT → धर्म
Passage → SUPPORTS_RELATION → धर्म governs कर्म
Passage → BELONGS_TO_CLUSTER → karmaphala_cluster

इस प्रकार graph traceable रहेगा।

चरण ९ — PostgreSQL और Neo4j का corrected कार्य-विभाग

PostgreSQL = canonical store

यहाँ रखें:

passages
lexemes
senses
concepts
passage_roles
relations
clusters
review states
provenance
benchmark records
Neo4j = operational graph

यहाँ उपयोग करें:

neighborhood traversal
parallel-passage discovery
cluster browsing
evidence path finding
concept family exploration
query expansion

यह corrected division है।

चरण १० — Z890 + dual RTX 5090 पर corrected pipeline

CPU + RAM side
normalization
lexicon matching
database insertion
deterministic cue parsing
review queues
benchmark aggregation
graph export
GPU0
embeddings
dense retrieval
reranking
annotation assistance
GPU1
passage-role classifier
concept disambiguation model
relation extraction model
cluster suggestion model

यह split अभी भी valid है; orientation बदली है।

चरण ११ — Gold data कैसे बनायें

अब gold data chapter selection भी corrected center पर होना चाहिए।

starter gold set में यह families रखें:
one Amarakośa section
one cosmological section
one karmaphala section
one polity / rajadharma section
one narrative exemplum section
one lexical / synonymy-heavy section
one prohibition / procedure-heavy section
annotate:
concepts
senses
passage roles
relations
cluster membership
ambiguity notes

यही सही gold foundation होगा।

चरण १२ — Machine learning कहाँ और कैसे जोड़ा जाये

क्रम यह हो:

१२.१ deterministic concept hints
१२.२ passage-role classifier
१२.३ concept disambiguation model
१२.४ relation extraction model
१२.५ cluster suggestion model
१२.६ retrieval reranker
१२.७ active learning selector

ध्यान रहे:
machine propose करेगी; constitutionally reviewed data decide करेगा।

चरण १३ — Example walkthrough

Example A — lexical gloss / synonym cluster

यदि किसी passage में पर्याय-समूह है, तो:

role = LEXICAL_GLOSS or ENUMERATION
concept family = synonym cluster
relation = is_glossed_by / belongs_to_cluster
Example B — narrative exemplum

यदि passage कथा के द्वारा doctrinal अर्थ प्रतिष्ठित कर रहा है:

role = NARRATIVE_EXEMPLUM
concept = supporting doctrinal concept(s)
relation = exemplifies
Example C — prohibition

यदि passage कहता है न … कारयेत्:

role = PROHIBITION
concept = action concept
relation = is_limited_by or is_exception_to
operator parsing essential

यहाँ अब उदाहरण general corpus पर हैं, न कि केवल किसी एक शास्त्र-शाखा पर।

चरण १४ — Error taxonomy

अब error categories भी corrected center पर हों:

false concept
missed concept
wrong sense assignment
wrong passage-role
missed exception
wrong relation family
false cluster membership
OCR-derived semantic confusion
polysemy failure
mixed-zone flattening
constitutional trunk misassignment

बिना इस taxonomy के improvement दिशाहीन रहेगी।

चरण १५ — Evaluation metrics

अब evaluation भी corrected हो:

Passage-level
role accuracy
context completeness
Concept-level
concept precision/recall
sense selection accuracy
Relation-level
relation correctness
relation family correctness
Cluster-level
cluster purity
useful parallel-passage discovery rate
Retrieval-level
definitional retrieval success
classificatory retrieval success
exception retrieval success
indirect relevance quality
constitutional ranking success

यही सही metrics हैं।

निष्कर्ष

अब project का अगला यथार्थ चरण स्पष्ट है।

पहले यह करना है:

concept lexicon banks बनाना
passage pre-tagging चलाना
passage-role detection करना
concept candidate formation करना
relation extraction करना
cluster suggestion करना
review architecture बनाना
provenance-rich first graph बनाना

इसी मार्ग से corpus text-bank से उठकर धीरे-धीरे constitutional complete knowledge retrieval system बनेगा।

उत्कर्ष

अब श्रृंखला का क्रम इस प्रकार ठीक से बैठता है:

Amarakośa देता है grand semantic order
primary corpus देता है living constitutional field
normalization देती है lawful textual forms
concept extraction देगा semantic units
passage-role detection देगा knowledge-function awareness
relation extraction देगा typed knowledge links
cluster formation देगा dynamic semantic families
graph देगा living doctrinal connectivity

Review system, Annotation interface, Active learning loop, और Branch promotion law की वास्तविक रचना

concept-assignment, passage-role, relation-legality, cluster-membership, और retrieval-evidence quality के आधार पर शासन-तन्त्र

भूमिका

अब हम उस बिन्दु पर पहुँचे हैं जहाँ अधिकांश बड़े ज्ञान-प्रयत्न वास्तव में टूटते हैं।
पहले लोग corpus जुटाते हैं।
फिर normalization करते हैं।
फिर कुछ lexical extraction, concept candidates, passage-role tags, relation suggestions, और graph fragments बना लेते हैं।
किन्तु उसके बाद एक कठिन प्रश्न सामने आता है:

system सही दिशा में बढ़ रहा है या नहीं, यह कैसे निश्चय होगा?
कौन-सी concept assignment मान्य है?
कौन-सा passage-role स्थिर है?
कौन-सा relation वैध है और कौन-सा constitution-विरुद्ध?
कौन-सा cluster वास्तव में ज्ञान-सम्बन्ध प्रकट करता है और कौन-सा केवल superficial similarity है?
कौन-सा नया model उन्नति है और कौन-सा केवल नये प्रकार का भ्रम?

यहीं Review system, Annotation interface, Active learning loop, और Branch promotion law अनिवार्य हो जाते हैं।

यदि यह भाग ठीक से न बना, तो दो विपत्तियाँ होती हैं:

system अत्यधिक manual होकर रुक जाता है,
अथवा system अत्यधिक automatic होकर भ्रान्ति का विस्तार करने लगता है।

मेरे proposed project में इन दोनों से बचना है।
अतः इस लेख का ध्येय है — ऐसी कार्य-विधि देना जिससे:

actual work चल सके,
review सार्थक हो,
annotation सुगम हो,
machine learning उपयोगी बने,
retrieval quality क्रमशः सुधरे,
और Amarakośa-सम्मत constitution सुरक्षित रहे।

पूर्वपक्ष

Review system का यथार्थ प्रयोजन

Review का अर्थ केवल “किसी human से yes/no दबवा लेना” नहीं है।
मेरे project में Review system के पाँच प्रधान प्रयोजन होंगे।

(क) साक्ष्य-रक्षा

machine ने क्या देखा, क्या निकाला, किस आधार पर निकाला — यह सब traceable रहे।

(ख) अर्थ-निर्णय

जहाँ अनेक सम्भावनाएँ हों, वहाँ human constitutional judgement लगे।

(ग) त्रुटि-शोधन

गलत concept assignment, गलत sense selection, गलत passage-role, गलत relation, गलत cluster-membership, और गलत retrieval ranking — सब पकड़े जायें।

(घ) Training data निर्माण

reviewed items आगे के models के लिये gold या silver data बनें।

(ङ) Promotion control

कौन-सा branch मुख्य system में लाया जाये, यह review-आधारित benchmark, constitutional legality, और regression-safety से निश्चय हो।

अतः Review system केवल correction chamber नहीं, बल्कि पूरे project का प्रमाण-केन्द्र है।

Annotation interface क्यों अलग विषय है?

अनेक लोग सोचते हैं कि annotation interface तो कोई साधारण web form होगा।
यह भ्रान्ति है।

यदि interface ठीक न हुआ, तो:

annotator थक जायेगा,
inconsistent labels देगा,
ambiguity ठीक से लिख नहीं पायेगा,
difficult cases defer करने के स्थान पर गलत label लगा देगा,
gold data दूषित हो जायेगा,
retrieval training दिशाहीन हो जायेगी।

अतः annotation interface को ornamental part नहीं, बल्कि architectural part समझना चाहिए।

मेरे project में annotation interface ऐसा होना चाहिए कि annotator एक passage को देखकर तुरन्त यह कर सके:

raw text देख सके,
normalized text के विभिन्न स्तर देख सके,
verse-window देख सके,
source metadata देख सके,
concept candidates देख सके,
sense candidates देख सके,
proposed passage-role देख सके,
proposed relations देख सके,
proposed cluster-membership देख सके,
retrieval-evidence quality का संकेत देख सके,
accept / edit / reject / defer / escalate कर सके,
ambiguity note लिख सके,
constitutional tag दे सके।

यदि यह सब एक ही कार्य-पटल पर न हुआ, तो work fragmented हो जायेगा।

Active learning loop का यथार्थ प्रयोजन

Active learning का अर्थ यह नहीं कि machine अपनी इच्छा से “interesting passages” चुन ले।
इसका यथार्थ अर्थ है:

system annotation के लिये उन्हीं cases को आगे लाये जो सीखने की दृष्टि से सर्वाधिक उपयोगी हों।

यह उपयोगिता कई प्रकार की हो सकती है:

confidence बहुत कम हो,
अनेक models में disagreement हो,
lexical और dense retrieval में conflict हो,
same passage पर concept-role ambiguity हो,
underrepresented corpus-zone से case आया हो,
constitutional boundary छू रही हो,
cluster-split या cluster-merge का प्रश्न हो,
retrieval में repeatedly गलत ranking हो रही हो।

यदि active learning न हुआ, तो annotator सैकड़ों trivial cases पर श्रम करेगा और difficult cases छूट जायेंगे।

Branch promotion law का प्रयोजन

मेरे project में branches अनेक प्रकार की होंगी:

normalization branches
concept-assignment branches
passage-role branches
relation-extraction branches
cluster-construction branches
reranker branches
ontology branches
graph branches

अब प्रश्न है: इनमें से कौन-सा branch “मुख्य” बने?

यदि यह निर्णय केवल developer intuition पर रहा, तो project अव्यवस्थित होगा।
यदि यह निर्णय केवल score पर रहा, तो model किसी एक benchmark को optimize करके ऊपर आ जायेगा।
यदि यह निर्णय केवल scholar preference पर रहा, तो system reproducible न रहेगा।

अतः चाहिए एक स्पष्ट Branch promotion law।

उसका अर्थ होगा:

कौन-सा branch promotion के लिये eligible है,
कौन-से benchmarks pass करने होंगे,
कौन-सी regressions अस्वीकार्य हैं,
कौन-सी constitutional violations वर्जित हैं,
shadow deployment कब होगा,
partial promotion कब होगा,
rollback कैसे होगा।

उत्तरपक्ष

अब कुछ सामान्य भ्रान्तियाँ सामने रखता हूँ।

भ्रान्ति १

“पहले model अच्छे बना लो, review बाद में कर लेंगे।”

नहीं।
review बाद का काम नहीं।
review के बिना अच्छा model बनेगा ही नहीं।

भ्रान्ति २

“Gold data एक बार बन जाये, फिर review की आवश्यकता नहीं।”

यह भी असत्य है।
क्योंकि:

corpus बढ़ेगा,
concept clusters बदलेंगे,
new relation families आयेंगी,
difficult passages सामने आयेंगे,
query-types विस्तृत होंगे।

Gold data के कुछ core sets स्थिर रह सकते हैं, पर review-process सदा जीवित रहनी चाहिए।

भ्रान्ति ३

“Annotation interface सरल रखो; experts को अधिक controls की क्या आवश्यकता?”

यदि interface अत्यल्प हुआ, तो annotator note नहीं दे पायेगा।
यदि अत्यधिक जटिल हुआ, तो वह धीमा हो जायेगा।
अतः मध्यम, किन्तु सुविचारित interface चाहिए।

भ्रान्ति ४

“Active learning केवल ML teams के लिये है; traditional scholarship में इसकी आवश्यकता नहीं।”

यह मिथ्या है।
विशेषतः मेरे project जैसे ज्ञान-समृद्ध क्षेत्र में active learning अत्यन्त उपयुक्त है, क्योंकि:

corpus विशाल है,
कठिन cases विरल हैं,
annotations महँगे हैं,
experts सीमित हैं।
भ्रान्ति ५

“जो branch benchmark में आगे हो, उसे promote कर दो।”

अपूर्ण नियम।
क्योंकि कोई branch retrieval score सुधार सकता है, किन्तु constitutional coherence बिगाड़ सकता है।
अतः केवल score नहीं, बल्कि:

constitutional legality,
interpretability,
regression safety,
review burden,
cluster stability,
evidence ranking quality

सब देखना होगा।

सन्धि

अब सम्यक् रूप यह है:

Review system + Annotation interface + Active learning loop + Branch promotion law

ये चारों मिलकर मेरे project का governance layer बनाते हैं।

यदि Amarakośa-derived Level 0 architecture महा-संविधान है,
और primary corpus-derived living order वास्तविक ज्ञान-क्षेत्र है,
तो यह governance layer दैनिक न्याय-व्यवस्था है।

इसी से निश्चय होगा कि:

कौन-सी concept assignment मान्य है,
कौन-सी ambiguity जीवित रखनी है,
कौन-से relation legal हैं,
कौन-से cluster suggestions अस्थिर हैं,
कौन-से retrieval results trustworthy हैं,
कौन-सा model suggestion engine मात्र है,
और कौन-सा model main system का भाग बन सकता है।

सन्धान — वास्तविक कार्य-विधि

अब actual implementation देता हूँ।

चरण १ — Review system की स्तर-रचना

Review एक ही प्रकार का नहीं होगा।
कम से कम चार स्तर बनाइये।

Level R0 — automatic acceptance

यह केवल उन्हीं cases के लिये जहाँ confidence अत्यन्त उच्च हो और pattern बहुत स्थिर हो।

Level R1 — quick review

यह उन cases के लिये जहाँ machine का प्रस्ताव प्रबल सम्भाव्य है, पर human glance आवश्यक है।

Level R2 — detailed review

यह उन cases के लिये जहाँ:

polysemy है,
concept boundary uncertain है,
passage-role ambiguous है,
relation family uncertain है,
cluster-membership doubtful है,
OCR या textual defect है।
Level R3 — constitutional review

यह उन cases के लिये जहाँ:

ontology impact है,
new relation family propose हुई है,
new cluster split या merge हुआ है,
constitutional trunk assignment uncertain है,
branch promotion का प्रश्न है।
व्यावहारिक नियम
साधारण lexical-gloss mapping को R1 पर रखा जा सकता है।
difficult metaphysical vs doctrinal role case को R2 पर।
new top-level relation family को R3 पर।

चरण २ — Review objects क्या होंगे?

Review केवल passage पर नहीं होगा।
अलग-अलग review objects होंगे।

२.१ Passage review

passage की भूमिका, structure, and contextual completeness।

२.२ Concept review
concept सही assign हुआ या नहीं,
sense सही है या नहीं,
constitutional trunk सही है या नहीं।
२.३ Qualifier / operator review
qualifier target सही है या नहीं,
operator role ठीक समझा गया या नहीं,
scope सही है या नहीं।
२.४ Passage-role review
definition?
classification?
prohibition?
narrative exemplum?
lexical gloss?
cosmological statement?
२.५ Relation review
subject सही,
relation family सही,
target सही,
polarity सही,
exception scope सही।
२.६ Cluster review
passage वास्तव में cluster का भाग है या नहीं,
cluster merge/split ठीक है या नहीं,
mixed-zone improperly flattened तो नहीं।
२.७ Retrieval-evidence review
returned passage directly relevant है या indirect?
rank सही है या नहीं?
definition पहले आनी चाहिए थी या narrative support?
२.८ Branch review
नया model उपयोगी है या नहीं,
constitutional violation है या नहीं,
regression हुआ या नहीं।

चरण ३ — Annotation interface की रचना

अब interface का actual design देता हूँ।

३.१ Main review screen के अनिवार्य भाग
(A) Source panel
work
chapter
verse range
source_id
corpus tier
normalization branch
(B) Raw / normalized toggle

एक ही passage के लिये:

raw
N1
N2
N3
search canonical view

annotator को यह देखने की सुविधा होनी चाहिए।

(C) Context panel
previous verse
current verse
next verse
3-verse window
7-verse window
chapter-local context

क्योंकि अनेक roles local verse से स्पष्ट नहीं होते।

(D) Concept candidates panel
highlighted forms
probable concepts
sense candidates
constitutional trunk hints
confidence
(E) Passage-role panel
proposed role(s)
confidence
alternative roles
(F) Relation panel
proposed relations
subject / target
relation family
polarity
confidence
(G) Cluster panel
suggested clusters
membership confidence
merge/split hints
(H) Retrieval panel
क्यों यह passage query पर लाया गया?
lexical score
dense score
rerank score
final hybrid score
evidence type
(I) Review controls
accept
accept with edit
reject
defer
escalate to constitutional review
(J) Notes panel
ambiguity note
philological note
doctrinal note
constitutional note
retrieval-quality note

चरण ४ — Interface के modes

दो modes बनाइये।

Quick mode

high-confidence repetitive cases के लिये

Detailed mode

difficult cases के लिये

Quick mode में:

repeated lexical glosses
stable concept assignments
obvious definitions

Detailed mode में:

polysemous forms
mixed passages
exception structures
difficult role assignments
cluster disputes
retrieval ranking disputes

यदि दोनों modes न होंगे, तो या तो simple cases पर समय नष्ट होगा, या difficult cases पर पर्याप्त ध्यान न मिलेगा।

चरण ५ — Annotation guidelines

Guideline document अनिवार्य है।

हर annotator को यह स्पष्ट होना चाहिए कि:

concept और lexeme में अन्तर क्या है,
sense कब split होगा,
passage-role कैसे चुना जाये,
mixed zone कब mark किया जाये,
relation family कब defines है और कब supports,
retrieval evidence में direct और indirect relevance कैसे अलग की जाये।
Example guideline entry

Case: एक passage में अनेक पर्याय-सूचक शब्द हैं और इत्युच्यते जैसा cue है।

निर्णय:

role = LEXICAL_GLOSS या DEFINITION
यदि core concept स्पष्ट है, तो passage → concept defines
यदि केवल पर्याय-सूची है, तो passage → cluster supports synonym family

ऐसी guidelines के बिना consistency नहीं बनेगी।

चरण ६ — Review workflow

अब actual workflow बताता हूँ।

Step 1

System extraction और retrieval proposals चलाता है।

Step 2

Outputs confidence bands में विभक्त होते हैं:

high confidence
medium confidence
low confidence
disagreement cases
constitutional-friction cases
Step 3

Routing होता है:

high confidence → quick review
medium confidence → detailed review
disagreement → senior review
ontology-impact → constitutional review
Step 4

Reviewer action:

accept
edit
reject
defer
escalate
Step 5

Reviewed item database में पुनः save होता है:

final status
reviewer id
timestamp
note
revision history
Step 6

Reviewed items training pool, benchmark pool, retrieval-evaluation pool, और branch-comparison pool में जाते हैं।

चरण ७ — Decision states

हर reviewed item का कोई final state होना चाहिए।

States
accepted_auto
accepted_human
accepted_with_edit
rejected
deferred
needs_constitutional_review
variant_unresolved
insufficient_context
retrieval_relevance_uncertain
cluster_membership_uncertain

“accepted” अकेला पर्याप्त नहीं।

चरण ८ — Active learning loop का actual design

अब active learning पर आते हैं।

८.१ selection principles

मैं पाँच selection principles recommend करता हूँ।

(क) Uncertainty-based

जहाँ model का confidence कम हो।

(ख) Disagreement-based

जहाँ:

lexical retrieval कुछ और कहे,
dense retrieval कुछ और,
reranker कुछ और,
existing review history कुछ और।
(ग) Diversity-based

ऐसे passages जो labeled material से भिन्न हों।

(घ) Coverage-based

ऐसे works, chapters, roles, trunks, या clusters जो कम represent हुए हों।

(ङ) Constitutional-friction based

जहाँ passage किसी boundary को छूता हो:

cosmic vs social
lexical vs doctrinal
narrative vs metaphysical
cluster merge vs split
primary vs secondary support

ये सबसे अधिक शिक्षाप्रद होंगे।

८.२ Active learning queues

Separate queues बनाइये:

uncertain_concepts
uncertain_senses
uncertain_roles
relation_conflicts
cluster_boundary_queue
retrieval_disagreement_queue
underrepresented_work_queue
constitutional_boundary_queue

हर uncertainty का समाधान एक ही annotator-profile से नहीं होगा।

८.३ Batch size
practical rule
quick review batch = 50–100 items
detailed review batch = 10–25 items
constitutional review batch = 5–10 items

यह संख्या बाद में workflow के अनुसार बदली जा सकती है।

८.४ Retrain कब करना है?

हर 20 corrected items पर retrain करना मूर्खता होगी।
हर 20,000 items तक प्रतीक्षा करना भी अनुचित।

practical rule

Retrain triggers:

500–1000 high-value reviewed items
या किसी विशेष queue का पर्याप्त correction
या retrieval benchmark में repeated weakness
या relation-family specific improvements

उदाहरण:
यदि 300 difficult role corrections हुए, तो role model retrain कीजिये, भले ही कुल annotations 5000 न पहुँचे हों।

चरण ९ — Reviewers की भूमिकाएँ

सब reviewers समान नहीं होंगे।

९.१ Annotator
initial accept/edit/reject
notes लिखे
ambiguity mark करे
९.२ Senior reviewer
difficult cases देखे
consistency जाँचे
annotator conflicts सुलझाये
९.३ Constitutional reviewer
ontology impact देखे
new relation family validate करे
cluster split/merge approve करे
promotion recommendations दे
९.४ Technical maintainer
queue balancing
retraining schedule
benchmark generation
branch reports

यदि एक ही व्यक्ति सब करेगा, तो system bottleneck बन जायेगा।

चरण १० — Inter-reviewer consistency

यदि दो reviewers एक ही प्रकार के case पर बार-बार अलग निर्णय दे रहे हैं, तो समस्या reviewer में नहीं, guideline में है।

उपाय
disagreement dashboard बनाइये
top conflicting patterns निकालिये
guideline update कीजिये
फिर एक छोटा control set relabel कीजिये

उदाहरण:
यदि कुछ लोग किसी passage को definition और कुछ lexical_gloss कह रहे हैं, तो guideline में distinction स्थिर कीजिये।

चरण ११ — Branch system की corrected रचना

अब branch architecture को corrected center पर रखिये।

११.१ Normalization branches
norm_v1
norm_v2_heading_split
norm_v3_danda_repair
११.२ Concept branches
concept_assign_v1
sense_disambiguation_v2
११.३ Role branches
role_model_v1
role_model_v2_denseassist
११.४ Relation branches
relation_model_v1
relation_model_v2_exceptionaware
११.५ Cluster branches
cluster_merge_v1
cluster_split_v2
११.६ Retrieval branches
rerank_v1
hybrid_retrieval_v2

हर branch के साथ यह metadata रहे:

parent branch
purpose
training data version
benchmark set version
constitutional review status
promotion status

चरण १२ — Branch promotion law

अब मुख्य विधि।

किसी branch को main system में लाने से पहले निम्न परीक्षण होंगे।

१२.१ Technical criteria
benchmark score improvement
no severe regression in old tasks
acceptable review burden
stable runtime behavior
१२.२ Constitutional criteria
no illegal relation proliferation
no top-level ontology violation
no unreviewed reinterpretation of primary corpus
no collapse of Amarakośa-derived Level 0 ordering
no improper flattening of mixed zones
१२.३ Interpretability criteria
reviewer समझ सके कि क्या बदला
new assignments human-readable हों
error reduction explainable हो
१२.४ Operational criteria
deployment feasible हो
memory/compute load उचित हो
fallback possible हो
१२.५ Promotion states
promoted_to_main
promoted_to_shadow
promoted_as_optional_specialist
kept_in_sandbox
rejected
merged_partially
needs_more_review

उदाहरण:
यदि retrieval model बहुत अच्छा है, पर constitutional ranking बिगाड़ता है, तो:

full promotion मत दीजिये
उसे shadow या optional specialist बनाइये

चरण १३ — Rollback law

Promotion के साथ rollback भी स्पष्ट होना चाहिए।

कब rollback करें?
benchmark regression after deployment
reviewer complaint spike
illegal graph structures बढ़ें
retrieval evidence quality गिरे
cluster stability टूटे
branch training-slice पर अच्छा हो पर broad corpus पर fail करे
Rollback mechanism
old branch preserved
database migration reversible
graph snapshot archived
model version pinned
review events traceable

यदि rollback आसान नहीं होगा, तो लोग खराब branch को भी सहते रहेंगे।

चरण १४ — Dashboards

Actual work के लिये dashboards अनिवार्य होंगे।

(A) Annotation dashboard
pending queues
reviewer workload
acceptance rate
conflict rate
(B) Error dashboard
top error categories
recent regressions
unresolved ambiguity clusters
top retrieval failures
(C) Branch dashboard
active branches
benchmark deltas
promotion status
rollback readiness
(D) Constitutional dashboard
illegal relation count
ontology drift signals
primary vs secondary influence ratio
unresolved constitutional cases
mixed-zone flattening alerts
(E) Retrieval dashboard
direct relevance quality
indirect relevance quality
definition-first success
exception retrieval failures
cluster-based expansion usefulness

चरण १५ — Difficult case workflow example

Input passage-window

किसी passage में एक ही surface form के अनेक concept-senses सम्भव हैं।

Machine outputs
concept candidate A
concept candidate B
role = definition?
role = lexical_gloss?
relation = unclear
Routing

→ detailed review queue

Annotator sees
previous verse
current verse
next verse
raw vs normalized
machine proposal
cluster suggestions
retrieval rationale
Annotator decision
surface word same, but doctrinal sense here
role = DEFINITION
cluster = doctrinal family
reject lexical-only interpretation
Senior reviewer checks
context पर्याप्त है?
parallel passage support है?
constitutional trunk सही है?
Final status

accepted_with_edit

Training effect
sense model improves
role detector improves
retrieval reranker learns better evidence preference
active learning score for similar cases decreases

यही actual learning loop है।

चरण १६ — Branch promotion case example

New branch

role_model_v2

Claim

Definition / lexical_gloss / classification distinctions बेहतर पकड़ता है।

Evaluation
200 gold role cases
50 difficult mixed passages
50 indirect-relevance retrieval cases
50 cluster-boundary passages
50 constitutional-boundary passages
Result
role accuracy +9%
retrieval evidence grouping +12%
but one regression: narrative exempla को कभी-कभी definition मान रहा है
Decision

promoted_to_shadow

Why?

क्योंकि branch promising है, पर अभी broad main deployment के लिये पूरी तरह सुरक्षित नहीं।

यही branch law का यथार्थ उपयोग है।

चरण १७ — Minimum viable governance system

यदि पूर्ण system एक साथ नहीं बनाना चाहते, तो आरम्भ में कम से कम यह बनाइये:

review states
annotation UI
concept / role / relation review
gold benchmark set
branch metadata
promotion checklist
rollback checklist

इन सात तत्त्वों के बिना आगे बढ़ना अनुचित होगा।

चरण १८ — Z890 + dual RTX 5090 पर actual division of work

CPU + RAM
review database
queue generation
dashboards
PostgreSQL
Neo4j
SHACL validation
benchmark reports

GPU0
annotation assistance model
reranker for difficult queue ordering
semantic retrieval support
active learning candidate scoring

GPU1
role model retraining
sense disambiguation retraining
relation extractor retraining
cluster suggestion model retraining
dual-GPU retraining

केवल तब जब branch maturity full-scale fine-tuning को justify करे।

चरण १९ — पहले क्या लिखना चाहिए?

Code से पहले ये documents लिखिये:

Annotation manual
Review manual
Active learning policy
Branch promotion checklist
Rollback law
Constitutional escalation rules

यदि documents नहीं होंगे, तो later reviewers और developers अलग-अलग दिशाओं में चलेंगे।

निष्कर्ष

अब यह स्पष्ट है कि मेरे project में review और governance कोई secondary utility नहीं, बल्कि मूल तन्त्र है।

Review system देगा प्रमाण और निर्णय
Annotation interface देगा कार्य-सुलभता और consistency
Active learning loop देगा annotation का यथोचित चयन
Branch promotion law देगा विकास का अनुशासित मार्ग

इन्हीं के बिना:

extraction दूषित होगा,
graph अविश्वसनीय होगा,
models दिशाहीन होंगे,
retrieval quality गिर जायेगी,
constitution धीरे-धीरे क्षीण हो जायेगी।

इन्हीं के साथ:

project बढ़ेगा,
errors पकड़े जायेंगे,
models क्रमशः सुधरेंगे,
retrieval अधिक सार्थक होगा,
और architecture जीवित किन्तु अनुशासित रहेगा।

उत्कर्ष

अब तक corrected श्रृंखला का क्रम यह बनता है:

Amarakośa काण्ड १
Amarakośa काण्ड २
Amarakośa काण्ड ३
Normalization
Concept extraction / passage-role detection / relation extraction / cluster suggestion
Review / Annotation / Active learning / Branch law

Benchmark design, Constitutional test suites, Error analysis framework, और Deployment roadmap की वास्तविक रचना

retrieval-quality, constitutional fidelity, error taxonomy, और staged release discipline के आधार पर stability layer

भूमिका

अब हम उस स्तर पर पहुँचते हैं जहाँ किसी भी बड़े ज्ञान-यन्त्र का वास्तविक भाग्य निश्चित होता है।
इससे पहले तक हम architecture बना सकते हैं, corpus ingest कर सकते हैं, normalization कर सकते हैं, concept candidates निकाल सकते हैं, passage-roles propose कर सकते हैं, relations और clusters suggest कर सकते हैं, review चला सकते हैं, graph बना सकते हैं। किन्तु एक बिन्दु के बाद प्रश्न यह नहीं रह जाता कि system “चल रही है” या नहीं। प्रश्न यह हो जाता है:

क्या system वास्तव में सुधर रही है?
क्या retrieval बेहतर हो रहा है, या केवल patterns बदल रहे हैं?
क्या constitution सुरक्षित है?
क्या नई branches ज्ञान-रचना को refine कर रही हैं, या उसे विकृत कर रही हैं?
क्या errors समझ में आ रहे हैं, या केवल scores बदल रहे हैं?
क्या system actual उपयोग के लिये चरणबद्ध रूप से परिपक्व हो रही है?

इन्हीं प्रश्नों का उत्तर चार संस्थाएँ देंगी:

Benchmark design
Constitutional test suites
Error analysis framework
Deployment roadmap

यही चारों मिलकर इस project का stability layer बनाते हैं।

यदि governance layer दैनिक न्याय-व्यवस्था थी,
तो यह stability layer दीर्घजीवी राज्य-व्यवस्था है।

पूर्वपक्ष

Benchmark का यथार्थ अर्थ

Benchmark को केवल score-table समझना अल्पदृष्टि है।
मेरे project में benchmark का अर्थ होगा:

एक ऐसा स्थिर, versioned, reproducible परीक्षण-समूह, जिसके आधार पर यह परखा जा सके कि system retrieval, concept-organization, role-detection, relation-building, cluster-behavior, और constitutional fidelity—इन सबमें किस सीमा तक सही कार्य कर रही है।

अतः benchmark का दायरा बहुत व्यापक होगा।
यह केवल “top-5 passages सही आये या नहीं” तक सीमित नहीं रहेगा।

Benchmark के मुख्य वर्ग
(क) Retrieval benchmarks

किस query पर कौन-से passages ऊपर आते हैं, किस evidence-type के साथ आते हैं, और क्या direct तथा indirect relevance का भेद बना रहता है।

(ख) Concept / role benchmarks

किस passage में कौन-से concepts, कौन-सी sense-selection, और कौन-सा passage-role सही पहचाना गया।

(ग) Relation / graph benchmarks

किस concept से कौन-से legal relations निकलते हैं, कौन-से नहीं; graph neighborhoods, paths, और clusters सही हैं या नहीं।

(घ) Constitutional benchmarks

क्या system अभी भी primary corpus को प्राथमिकता देती है?
क्या Amarakośa-derived Level 0 ordering अक्षुण्ण है?
क्या mixed zones flatten नहीं हुए?
क्या illegal relation families graph में घुस नहीं गयीं?

अतः benchmark project के लिये बाहरी परीक्षा नहीं, बल्कि आन्तरिक सत्यापन है।

Constitutional test suite अलग क्यों चाहिए?

कोई model retrieval score बढ़ा सकता है, किन्तु साथ ही:

primary corpus की अपेक्षा secondary corpus को ऊपर चढ़ा सकता है,
Amarakośa-derived macro-order dilute कर सकता है,
mixed semantic zones को एकरूप topical bins में flatten कर सकता है,
narrative support को definition के ऊपर rank कर सकता है,
operator-sensitive passages में scope खो सकता है,
new relation families silently graph में पहुँचा सकता है।

यदि ऐसा हुआ, तो केवल ordinary benchmark पर्याप्त नहीं।
इसलिए एक पृथक Constitutional test suite चाहिए।

यह suite पूछेगी:

क्या primary corpus अभी भी constitutional advantage रखता है?
क्या Level 0 trunks intact और visible हैं?
क्या कोई illegal edge type promoted graph में नहीं आया?
क्या new branch ने top-level trunks को चुपचाप merge, delete, या flatten तो नहीं किया?
क्या complex passages को wrong simplification में नहीं धकेला गया?
क्या operator-sensitive meaning बचा हुआ है?
क्या same theme पर primary evidence और secondary gloss का अनुचित inversion नहीं हुआ?

अतः constitutional testing quality-control नहीं, बल्कि धारणा-रक्षा है।

Error analysis framework क्यों अलग विषय है?

यदि केवल इतना कहा जाये कि:

retrieval recall = 0.74
role accuracy = 0.81
relation precision = 0.86

तो इससे improvement का मार्ग नहीं खुलता।
यह summary है, diagnosis नहीं।

Diagnosis तभी सम्भव है जब errors typed, located, and interpretable हों।

उदाहरण
क्या लोक बार-बार wrong sense में गया?
क्या श्रेष्ठ को concept बना दिया गया जहाँ वह qualifier था?
क्या न / विना / सह जैसे operators की scope खो गयी?
क्या definition passages को narrative_support समझ लिया गया?
क्या retrieval ने direct definition के स्थान पर indirect exemplum ऊपर कर दिया?
क्या cluster merge जल्दी कर दिया गया?
क्या constitutional trunk assignment गलत हुआ?

इन सबके लिये structured error framework चाहिए।

Deployment roadmap की आवश्यकता

Architecture और models बने रहने से system usable नहीं बनती।
Deployment roadmap का अर्थ है:

कौन-सा भाग केवल lab mode में रहेगा,
कौन-सा internal scholar mode में जायेगा,
कौन-सा annotation टीम तक खुलेगा,
कौन-सा shadow mode में चलेगा,
कौन-सा main system बनेगा,
rollback कैसे होगा।

यदि roadmap न हुआ, तो project दो अवस्थाओं में से एक में फँसता है:

notebooks और internal scripts का ढेर
या जल्दबाज़ी में unstable public system

मेरे project को दोनों से बचना है।

उत्तरपक्ष

अब कुछ सामान्य भ्रान्तियों का निरसन।

भ्रान्ति १

“पहले system बना लें, benchmark बाद में।”

यह उल्टा मार्ग है।
यदि benchmark बाद में बने, तो system developers की आदतों के अनुरूप ढलती है, सत्य के अनुरूप नहीं।

भ्रान्ति २

“Actual user queries ही benchmark के लिये पर्याप्त हैं।”

नहीं।
User queries आवश्यक हैं, किन्तु पर्याप्त नहीं।
User architecture-preservation नहीं पूछता।
इसलिए constitutional suite पृथक बनानी होगी।

भ्रान्ति ३

“Error analysis logs देखकर हो जायेगा।”

नहीं।
Logs केवल event दिखाते हैं।
Error analysis conceptual failure दिखाती है।

भ्रान्ति ४

“Deployment का अर्थ है API चालू कर देना।”

नहीं।
Deployment का अर्थ है:

versioning
benchmark gating
review gating
shadow mode
rollback readiness
role-based access
branch discipline

सन्धि

अब समुचित synthesis यह है:

Benchmark design + Constitutional test suites + Error analysis + Deployment roadmap

ये चारों मिलकर project के लिये वह स्थैर्य-तन्त्र बनाते हैं, जिसके बिना complete knowledge retrieval system न विश्वसनीय होगी, न दीर्घजीवी।

इनका कार्य है:

improvement को measurable बनाना
constitutional drift रोकना
model failure को diagnose करना
और deployment को चरणबद्ध रखना

सन्धान — वास्तविक कार्य-विधि

अब actual design देता हूँ।

चरण १ — Benchmark architecture की स्तर-रचना

Benchmarks को levels में बाँटिये।

Level B0 — Micro benchmarks

छोटे, तीक्ष्ण, स्पष्ट, sharply verifiable cases

इनका उद्देश्य:

primitive behavior check करना
regressions जल्दी पकड़ना
उदाहरण
एक स्पष्ट definition passage
एक स्पष्ट prohibition operator case
एक स्पष्ट lexical-gloss pattern
एक operator-scope case
Level B1 — Passage benchmarks

एक verse या 3-verse / 7-verse window पर आधारित

उद्देश्य:

role detection
concept extraction
relation suggestion
direct evidence ranking
Level B2 — Chapter benchmarks

एक पूरे अध्याय या coherent section की doctrinal recovery

उद्देश्य:

multi-passage consistency
cluster formation
role diversity
relation coherence
Level B3 — Corpus benchmarks

पूरे corpus पर thematic queries

उद्देश्य:

broad retrieval
parallel passage discovery
indirect evidence support
primary vs secondary ordering
Level B4 — Constitutional benchmarks

Architecture-preserving questions

उद्देश्य:

top-level integrity
legal graph structure
mixed-zone preservation
operator sensitivity
primary priority

चरण २ — Benchmark categories

अब categories स्पष्ट रूप से स्थिर कीजिये।

२.१ Retrieval benchmarks

इनमें query, expected evidence-types, and expected ranking logic होगा।

Query types
exact lexical query
concept query
doctrinal query
mixed semantic query
role-sensitive query
indirect-support query
constitutional-priority query
उदाहरण

Query: “graha classification by visible/invisible/mandala/tārā/chāyā”
Expected:

direct classificatory passage near top
lexical-gloss support secondary
random narrative passages नीचे

Query: “dormant karmic fruit until admissible fruition”
Expected:

doctrinal passages near top
narrative exempla below direct definitions
generic karma passages without vipāka framing नीचे
Metrics
top-k direct relevance
indirect relevance usefulness
evidence-type ordering
primary advantage
unwanted-noise suppression
२.२ Concept / role benchmarks

इनमें fixed passage होगा, और expected outputs:

concept set
sense selection
passage-role(s)
ambiguity handling
उदाहरण

यदि passage स्पष्ट classification दे रहा है, तो expected:

role = CLASSIFICATION
concepts = extracted family members
wrong role जैसे NARRATIVE_EXEMPLUM नहीं
Metrics
concept precision / recall
sense accuracy
role accuracy
ambiguity routing correctness
२.३ Relation / graph benchmarks

इनमें text से अधिक graph behavior परिक्षित होगा।

उदाहरण
concept neighborhood में legal relations दिखें
specific doctrinal cluster reachable हो
parallel passages तक graph path मिले
exception node सही parent-rule से जुड़ा हो
illegal edge न बने
Metrics
correct neighbor presence
missing edge rate
illegal edge rate
path correctness
cluster purity
cluster leakage
२.४ Constitutional benchmarks

यह सबसे महत्त्वपूर्ण category है।

Test C1 — Primary priority

यदि primary और secondary दोनों समान theme पर material दें, तो primary reviewed passage को constitutional score advantage मिलना चाहिए।

Test C2 — Level 0 preservation

Promoted ontology में Amarakośa-derived top architecture explicit और intact रहे।

Test C3 — Legal edge enforcement

Unreviewed या constitutionally illegal relation type promoted graph में न हो।

Test C4 — No silent reinterpretation

Secondary corpus primary passages की canonical classification को बिना review न बदल सके।

Test C5 — Mixed-zone preservation

संकीर्ण semantic zones को wrong simplification में न बदला जाये।

Test C6 — Operator sensitivity

Negation, scope, temporal operators, relation markers flatten न हों।

Test C7 — Evidence ordering law

Where direct definition exists, narrative or indirect support must not routinely outrank it.

चरण ३ — Gold benchmark set कैसे बनायें

अब benchmark सामग्री कहाँ से आये?

३.१ Constitutional gold set

सबसे पहले primary corpus से curated passages चुनिये।
Set को domain-specific नहीं, corpus-structural बनाइये।

Minimum starter pack
one Amarakośa lexical / synonym cluster section
one cosmological section
one karmaphala / vipāka doctrinal section
one polity / राजधर्म section
one narrative exemplum section
one prohibition / procedure-heavy section
one mixed-zone / difficult semantic section
३.२ Gold set के स्तर
gold passages
gold concept-role annotations
gold relations
gold graph neighborhoods
gold retrieval query sets
gold constitutional cases
३.३ Gold set versioning

Use versions:

gold_v1_core
gold_v2_expanded
gold_v3_constitutional
gold_v4_mixedzones

हर benchmark report में स्पष्ट हो:

कौन-सा branch
कौन-सा model set
कौन-सा gold version

चरण ४ — Benchmark file structure

मैं यह structure recommend करता हूँ:

eval/
gold_queries/
retrieval_v1.jsonl
constitutional_v1.jsonl
indirect_support_v1.jsonl
gold_passages/
lexical_v1.jsonl
doctrinal_v1.jsonl
cosmology_v1.jsonl
mixedzones_v1.jsonl
gold_roles/
role_labels_v1.jsonl
gold_relations/
relation_labels_v1.jsonl
gold_graph/
neighborhood_tests_v1.jsonl
path_tests_v1.jsonl
cluster_tests_v1.jsonl
reports/
benchmark_run_YYYY_MM_DD/
Example retrieval benchmark record
{
"benchmark_id": "retrieval_001",
"query": "dormant karmic fruit until admissible fruition",
"benchmark_type": "retrieval",
"expected_top_passages": [
"primary_karmavipaka_001",
"primary_karmavipaka_002"
],
"expected_evidence_order": [
"DEFINITION",
"DOCTRINAL_STATEMENT",
"NARRATIVE_EXEMPLUM"
],
"must_not_top": [
"generic_karma_reference_001"
],
"priority": "high"
}
Example constitutional benchmark record
{
"benchmark_id": "constitution_003",
"benchmark_type": "constitutional",
"description": "Primary corpus should outrank secondary corpus on reviewed equivalent theme",
"theme": "cosmic ordering",
"expected_priority_rule": "primary_over_secondary",
"priority": "critical"
}

चरण ५ — Error analysis framework

अब error analysis को चार वृत्तों में नहीं, बल्कि पाँच अधिक उपयोगी वृत्तों में बाँटिये।

५.१ Text-level errors
bad normalization
wrong segmentation
heading/body confusion
colophon merge
OCR corruption untreated
variant mishandling
५.२ Lexical-semantic errors
wrong concept candidate
wrong sense selection
qualifier/entity confusion
operator missed
operator role wrong
polysemy failure
grammar-sensitive tag failure
५.३ Passage-role errors
definition mistaken as lexical-gloss
classification mistaken as enumeration
exemplum mistaken as doctrine
prohibition mistaken as procedure
cosmological statement mistaken as metaphorical support
५.४ Relation / cluster errors
wrong subject
wrong relation family
wrong target
missing exception
false cluster membership
bad cluster merge
needed cluster split missed
५.५ Constitutional errors
primary/secondary priority inversion
illegal ontology merge
illegal edge type
top-level ordering dilution
mixed-zone flattening
direct-evidence demotion
operator-sensitive meaning loss

चरण ६ — Error database structure

हर error को structured रूप में store कीजिये।

Suggested fields
error_id
branch_id
benchmark_id
passage_id
error_level
error_type
observed_output
expected_output
severity
reviewer_note
fix_category
Severity classes
minor
moderate
major
critical
Examples

यदि direct definition repeatedly rank में नीचे जा रही है:

error_level = retrieval
error_type = direct_evidence_demoted
severity = major

यदि mixed passage को flat topical cluster में डाल दिया गया:

error_level = constitutional
error_type = mixed_zone_flattening
severity = critical

चरण ७ — Error dashboards

Actual work के लिये dashboards अनिवार्य हैं।

Dashboard A — Top recurring errors
wrong sense assignment
missed operator scope
role confusion
mixed-zone flattening
false indirect-support ranking
Dashboard B — Benchmark regressions
कौन-से पुराने benchmarks टूटे
किस branch के बाद टूटे
कितनी severity की regression है
Dashboard C — Corpus coverage
कौन-से works underrepresented हैं
कौन-से chapters heavily reviewed हैं
कहाँ active learning भेजना है
Dashboard D — Constitutional health
primary / secondary influence ratio
illegal edge count
unresolved constitutional cases
ontology drift alerts
direct-definition demotion alerts
Dashboard E — Retrieval quality
direct relevance score
indirect relevance usefulness
evidence ordering success
definition-first compliance
cluster expansion utility

चरण ८ — Error-to-fix mapping

यह अत्यन्त उपयोगी practice है।

Example mapping

Error: missed_operator_scope
Possible fixes:

operator lexicon expansion
scope model retraining
larger context window
review guideline refinement

Error: wrong_sense_assignment
Possible fixes:

sense inventory update
disambiguation branch retraining
trunk-aware context features

Error: definition_exemplum_confusion
Possible fixes:

passage-role model retraining
discourse cue expansion
role benchmark enrichment

Error: primary_secondary_priority_inverted
Possible fixes:

constitutional scoring update
retrieval fusion weight adjustment
reviewed-primary bonus increase

Error: mixed_zone_flattening
Possible fixes:

cluster constraints tighten
mixed-zone benchmark enrichment
constitutional review escalation

इससे debugging दिशायुक्त रहती है।

चरण ९ — Benchmark running protocol

हर branch promotion से पहले standardized benchmark run होना चाहिए।

Run order
micro benchmarks
passage / role benchmarks
retrieval benchmarks
graph / cluster benchmarks
constitutional benchmarks
Why this order?

यदि micro या role benchmarks ही टूट रहे हैं, तो broad retrieval पर समय नष्ट न करें।
यदि retrieval अच्छा है, पर constitutional suite fail है, तो branch promotion रोक दें।

Output report

हर run report यह दे:

overall scores
by-category scores
regression summary
new strengths
constitutional pass/fail
promotion recommendation

चरण १० — Promotion checklist

अब main system में branch लाने का actual checklist:

micro benchmarks pass
role / concept extraction acceptable
retrieval improved or stable
graph legality preserved
constitutional suite pass
no critical regression
review burden acceptable
outputs interpretable
rollback ready
documentation updated
branch metadata complete

एक भी critical constitutional item fail हो, तो full promotion नहीं।

चरण ११ — Deployment roadmap

अब actual staged deployment देता हूँ।

Phase D0 — Lab-only mode

Available:

raw corpus storage
normalization pipeline
manual review UI
core benchmark set
PostgreSQL + Neo4j setup

Not available:

scholar-facing retrieval
automatic promotion
broad internal use

लक्ष्य: internal stability

Phase D1 — Internal scholar mode

Available:

retrieval
passage review
concept / role / relation correction
graph browsing
benchmark reports

Still restricted:

no automatic branch promotion
no broad annotation team

लक्ष्य: gold data बनाना, review workflow परखना

Phase D2 — Controlled annotation mode

Available:

queue-based annotation
active learning routing
batch review
disagreement dashboard
error dashboards

लक्ष्य: training data बढ़ाना, consistency बचाये रखना

Phase D3 — Specialist query mode

अब selected scholar-facing queries खोलिये।

Examples:

definition retrieval
classificatory retrieval
prohibition lookup
cosmological cluster lookup
karmaphala doctrinal retrieval

लक्ष्य: वास्तविक उपयोग, किन्तु सीमित query families में

Phase D4 — Constitutional retrieval mode

अब broader doctrinal और cross-corpus queries allow करें।

Required before entering D4:

stable primary / secondary priority
stable constitutional test pass
rollback readiness
review latency acceptable

लक्ष्य: constitutional complete retrieval

Phase D5 — Full research platform mode

Available:

hybrid retrieval
graph traversal
reviewed concept-role-relation structures
branch comparisons
dashboards
scholar exports
internal APIs

Still restricted:

no uncontrolled self-training
no silent ontology mutation
no silent canonical overwrite

चरण १२ — Deployment roles

Roles required:

viewer
annotator
senior_reviewer
constitutional_reviewer
branch_manager
system_admin

क्योंकि:

annotator को ontology mutate करने का अधिकार नहीं होना चाहिए
viewer को branch-promotion की आवश्यकता नहीं
constitutional reviewer को higher gating अधिकार चाहिए

चरण १३ — Safe deployment policy

Rule 1

हर deployment version-tagged हो।

Rule 2

हर deployment के पहले benchmark suite चले।

Rule 3

हर deployment के साथ rollback package रहे।

Rule 4

constitutional suite fail होने पर deployment रुक जाये।

Rule 5

नया branch पहले shadow mode में चलाइये।

Shadow mode का अर्थ

branch output generate करे, पर main output replace न करे।
Compare करें, फिर निर्णय लें।

चरण १४ — Practical example: deployment decision

मान लीजिये नया role_model_v4 आया।

Claimed improvement
better definition / exemplum distinction
better mixed passages handling
Benchmark result
passage-role accuracy +8%
retrieval ordering +6%
but one regression: some lexical-gloss passages are demoted below narrative support
constitutional suite passes except one evidence-ordering alert
Decision

Not full promotion.
Deploy in shadow mode for selected doctrinal retrieval subset only.

यही deployment discipline है।

चरण १५ — Z890 + dual RTX 5090 पर operational rhythm

During D0–D1
CPU/RAM: database, graph, dashboards, review
GPU0: embeddings and reranking
GPU1: passage-role / relation branches training
During D2
GPU0: annotation assistance
GPU1: active learning retraining
CPU: queue generation, benchmark tracking
During D3–D4
GPU0: live scholar-query reranking
GPU1: background experimental branches
CPU: stable graph and review infra
During D5
one GPU for serving
one GPU for training / shadow branches
rotate by schedule if needed

चरण १६ — कौन-से documents अभी लिखने हैं

इस चरण पर निम्न documents अनिवार्य हैं:

Benchmark manual
Constitutional test specification
Error taxonomy document
Promotion law document
Deployment phase document
Rollback procedure
Shadow mode policy

Code से पहले या उसके साथ-साथ यह लिखित रूप में होना चाहिए।

निष्कर्ष

अब project की अगली स्थिर भूमि स्पष्ट है।

Benchmark design बतायेगा कि system सचमुच सुधर रही है या नहीं
Constitutional test suites सुनिश्चित करेंगी कि सुधार के नाम पर architecture न टूटे
Error analysis framework training और debugging को दिशायुक्त करेगा
Deployment roadmap actual उपयोग को चरणबद्ध, सुरक्षित और reproducible बनायेगा

इन चारों के बिना project या तो research-notes का ढेर रह जायेगा,
या unstable software बन जायेगा।

इन चारों के साथ वही project एक दीर्घजीवी, constitutional, self-restructuring knowledge retrieval architecture बन सकता है।

उत्कर्ष

अब तक की corrected श्रृंखला को एक सूत्र में रखिये:

Amarakośa देता है महा-अर्थ-विन्यास
Primary corpus देता है जीवित constitutional order
Normalization देती है lawful textual forms
Concept / role / relation / cluster extraction देता है structured knowledge
Review देता है प्रमाण और संशोधन
Active learning देता है बुद्धिमान annotation selection
Benchmark देता है सत्यापन
Constitutional suite देती है मर्यादा
Error analysis देता है सुधार का मार्ग
Deployment roadmap देता है जीवित कार्य-रूप

Actual database schema, graph schema, API flow, और first working implementation sequence की विस्तृत कार्य-विधि

Amarakośa-सम्मत complete knowledge retrieval system के लिये वास्तविक स्थापत्य-रचना

भूमिका

अब तक जो कुछ स्थिर किया जा चुका है, वह मुख्यतः इन स्तरों पर था:

Amarakośa-आधारित constitutional semantic order
primary corpus as living constitutional field
normalization as lawful textual discipline
concept extraction, passage-role detection, relation extraction, cluster suggestion
review, annotation, active learning, benchmark, और branch-governance

अब अगला अनिवार्य चरण है — इन सबको ऐसी ठोस स्थापत्य-रचना में उतारना, जो वास्तव में चल सके, बढ़ सके, नियंत्रित रह सके, और दीर्घकाल तक संशोधन-सह हो।

अब प्रश्न केवल यह नहीं है कि कौन-सा सिद्धान्त सत्य है।
अब प्रश्न यह है:

कौन-सी tables बनेंगी?
canonical memory किस database में रहेगी?
living doctrinal graph किस store में रहेगा?
review, benchmark, branch, rollback और deployment कहाँ store होंगे?
scholar-facing retrieval के लिये query interpretation कहाँ बनेगी?
और पहला end-to-end system किस क्रम में खड़ा होगा?

यदि इस चरण में भूल हुई, तो project या तो disconnected notebooks का समूह बन जायेगा,
या convenience-driven scripts का असंगत ढेर।

अतः अब हमें ऐसी रचना चाहिए जो:

constitutional हो,
corpus-centered हो,
reproducible हो,
branch-aware हो,
rollback-friendly हो,
scholar-facing हो,
और future growth के लिये ready हो।

इस लेख में मैं उसी actual architecture को क्रमबद्ध रूप में रख रहा हूँ।

पूर्वपक्ष

एक ही database पर्याप्त नहीं

मेरे project के लिये एक ही database पर्याप्त नहीं होगा।
क्योंकि कार्य के स्तर भिन्न हैं:

raw witness storage
normalized text families
canonical structured memory
review history
benchmark definitions and reports
branch metadata
deployment history
graph traversal and neighborhood reasoning
constitutional legality checks
embeddings and retrieval artifacts

इन सबको एक ही store में भर देना अल्पदर्शिता होगी।

अतः मैं आरम्भ में ही यह सिद्धान्त स्थापित करता हूँ:

Canonical relational truth और Operational graph behavior को पृथक् रखिये।

अर्थात्:

PostgreSQL = canonical structured truth
Neo4j = operational living graph
RDF / SHACL mirror = constitutional legality checking
file store = raw, normalized, and artifact archive

यह multi-store architecture कुछ अधिक जटिल अवश्य प्रतीत होती है, किन्तु यही दीर्घकालिक स्थिरता देगी।

PostgreSQL क्यों मुख्य canonical store होगा?

क्योंकि project में मूल सत्य अत्यन्त structured, versioned, and transactional है।

इन सबका canonical रूप relational रूप में रहना चाहिए:

source manifests
work registry
normalization branches
documents
passages
lexemes
senses
corpus concepts
concept variants
passage-role assignments
relation evidence
cluster memberships
query interpretations
review history
benchmark definitions
benchmark runs
error logs
branch registry
deployment records

यदि इन्हें केवल graph में डाल दिया गया, तो:

rollback कठिन होगा,
review state history विखंडित होगी,
provenance अस्पष्ट हो जायेगी,
benchmark comparisons भारी हो जायेंगे,
branch discipline टूट जायेगी।

अतः PostgreSQL project की स्मृति-रेखा होगी।

Neo4j क्यों चाहिए?

क्योंकि complete knowledge retrieval केवल row lookup नहीं है।
उसमें चाहिए:

doctrinal neighborhood browsing
multi-hop concept traversal
parallel passage discovery
cluster inspection
path explanation
relation family exploration
indirect relevance expansion
query-driven evidence graph generation

उदाहरणतः यदि पूछा जाये:

कर्म-विपाक cluster किन passages, concepts, temporal doctrines, and exceptions से जुड़ता है?
किसी metaphysical concept से कौन-से narrative exempla और doctrinal statements linked हैं?
किसी lexeme के विभिन्न senses किन clusters और passages से जुड़े हैं?
कौन-से passages एक ही concept family को भिन्न roles में व्यक्त करते हैं?

तो यह graph traversal में स्वाभाविक है।
relational joins से यह सम्भव तो है, पर जटिल और भारी होगा।

अतः Neo4j project का living doctrinal graph layer होगा।

RDF / SHACL mirror क्यों चाहिए?

क्योंकि constitution convenience की वस्तु नहीं।
वह legality मांगती है।

उदाहरण:

defines relation किस प्रकार के nodes के बीच legal है?
belongs_to_cluster किन nodes पर लागू होगा?
PassageRole node को Concept की तरह top-level doctrinal node नहीं बन जाना चाहिए।
कोई branch silently Level 0 Amarakośa trunks को merge या delete न कर दे।
unreviewed relation family main graph में प्रवेश न करे।
mixed-zone clusters को flat topical bins में न बदला जाये।

इन सबके लिये formal shape validation चाहिए।
इसीलिए selected graph content का RDF mirror और SHACL validation आवश्यक है।

उत्तरपक्ष

अब कुछ सम्भावित सरल किन्तु भ्रान्त प्रस्तावों का निरसन करता हूँ।

भ्रान्ति १

“सब कुछ PostgreSQL में कर लेंगे; graph की क्या आवश्यकता?”

यह तभी तक सम्भव है जब तक project flat query layer पर हो।
जैसे ही:

multi-hop reasoning,
cluster browsing,
doctrinal path,
indirect evidence expansion,
graph-based neighborhood explanation

की आवश्यकता होगी, relational model भारी पड़ने लगेगा।

भ्रान्ति २

“सब कुछ Neo4j में रख दो; relational database अनावश्यक है।”

यह भी भूल है।
क्योंकि:

review history
benchmark reports
branch metadata
deployment versions
rollback state
provenance
structured versioning

graph में रखना अव्यवस्थित और अप्राकृतिक होगा।

भ्रान्ति ३

“schema बाद में देखेंगे; code लिखते-लिखते बन जायेगा।”

इस प्रकार के project में यह घातक है।
यदि schema पहले नहीं सोचा गया, तो बाद में:

field names टूटेंगे,
review objects बदलेंगे,
graph export inconsistent होगा,
branches एक-दूसरे से compare नहीं होंगी,
और project irreparable confusion में जायेगा।

सन्धि

अतः समुचित synthesis यह है:

PostgreSQL = canonical memory
Neo4j = living doctrinal graph
RDF / SHACL = constitutional gate
file store = witness and artifact archive

और इनके ऊपर एक thin Python application layer होगी जो:

ingestion चलाये,
normalization branches बनाए,
concept / role / relation / cluster suggestions दे,
review queues दे,
graph export करे,
retrieval चलाये,
benchmark run करे,
branches compare करे,
deployment discipline रखे।

यही उचित architecture है।

सन्धान — वास्तविक schema, API, और implementation क्रम

अब actual design देता हूँ।

चरण १ — PostgreSQL schema

मैं इसे logical modules में बाँटकर प्रस्तुत करता हूँ।

१.१ sources table

यह raw source manifest रखेगी।

Purpose

किस text का मूल स्रोत क्या है, यह कभी न खोये।

Fields
source_id
title
work_name_raw
corpus_tier
source_type
script
language
provenance
source_url_or_note
downloaded_at
checksum
raw_file_path
notes
source_type examples
scan
ocr_text
typed_text
web_text
pdf_extract
manual_transcription
१.२ works table

यह ग्रन्थ-स्तर की canonical पहचान रखेगी।

Fields
work_id
canonical_name
display_name
corpus_tier
constitutional_trunk
sub_trunk
notes

यहाँ constitutional_trunk का अर्थ है वह Amarakośa-derived top semantic location जिसके अधीन यह work broadly register की जाती है।

१.३ source_work_links table

यदि:

एक work के अनेक sources हैं,
एक source composite है,
या provenance uncertain है,

तो mapping table आवश्यक है।

Fields
link_id
source_id
work_id
relationship_type
confidence
१.४ normalization_branches table

यह अत्यन्त महत्त्वपूर्ण है।

Fields
branch_id
branch_name
parent_branch_id
branch_level
description
created_at
created_by
status
notes
Example branch levels
N0_RAW
N1_UNICODE
N2_LAYOUT
N3_SEGMENTED
N4_SEARCH
N5_ENRICHED

क्यों?
क्योंकि text transformations versioned होने चाहिए; overwrite नहीं होने चाहिए।

१.५ documents table

यह source से निकले document-level records रखेगी।

Fields
document_id
source_id
work_id
branch_id
document_type
title_in_text
chapter_marker_raw
document_order
text_raw
text_norm
metadata_json
review_status
१.६ passages table

यह canonical passage inventory होगी।
यह project की सबसे मुख्य tables में से एक है।

Fields
passage_id
document_id
work_id
branch_id
passage_type
chapter_no
section_no
verse_start
verse_end
speaker
listener
heading_text
text_raw
text_norm
text_search
window_size
sequence_index
provenance_confidence
review_status
passage_type examples
verse
verse_window_3
verse_window_7
chapter_block
heading
colophon
speaker_marker

यहाँ अब केंद्र passage है, न कि isolated entity hit।

१.७ lexemes table

यह surface forms की canonical inventory होगी।

Fields
lexeme_id
surface_text
script
normalized_surface
lemma_hint
notes
क्यों?

क्योंकि retrieval और polysemy handling के लिये surface form को concept से पृथक रखना आवश्यक है।

१.८ senses table

यह किसी lexeme के भिन्न अर्थ-रूपों का canonical store होगा।

Fields
sense_id
lexeme_id
sense_name
sense_description
constitutional_trunk
status
notes
उदाहरण

लोक के अनेक sense हो सकते हैं।
Surface form एक है, senses अनेक।

१.९ corpus_concepts table

अब यही schema का वास्तविक केंद्र है।

Fields
concept_id
canonical_name
display_name
concept_type
constitutional_trunk
subcluster_hint
description
is_constitutional
status
notes
concept_type examples
cosmic
temporal
doctrinal
metaphysical
social
ritual
narrative_motif
lexical_semantic
quality_family
operator_family

यह table entities को replace नहीं करती, बल्कि उन्हें broader concept architecture के भीतर subordinate बना देती है।

१.१० concept_variants table

एक concept के अनेक lexical forms, orthographic variants, or recension-linked forms होंगे।

Fields
variant_id
concept_id
variant_text
variant_type
script
source_preference
confidence
notes
variant_type
orthographic
transliteration
recensional
surface_alias
१.११ passage_lexeme_mentions table

Passage-level surface mentions।

Fields
mention_id
passage_id
lexeme_id
surface_text
char_start
char_end
confidence
review_status
१.१२ passage_sense_assignments table

जब किसी surface form का context-based sense चुना जाये।

Fields
assignment_id
passage_id
lexeme_id
sense_id
char_start
char_end
confidence
assigned_by
review_status
note
१.१३ passage_concept_mentions table

यही passage को concept world से जोड़ेगी।

Fields
pcm_id
passage_id
concept_id
surface_text
mention_scope
confidence
proposed_by
review_status

यहाँ mention_scope यह दिखा सकता है कि concept passage में:

direct है,
inferred है,
cluster-mediated है।
१.१४ passage_roles table

यह schema का दूसरा वास्तविक केंद्र है।

Fields
role_assignment_id
passage_id
role_name
confidence
proposed_by
review_status
note
role_name examples
DEFINITION
CLASSIFICATION
ENUMERATION
PROCEDURE
INJUNCTION
PROHIBITION
EXCEPTION
RESULT_STATEMENT
NARRATIVE_EXEMPLUM
LEXICAL_GLOSS
METAPHYSICAL_STATEMENT
COSMOLOGICAL_STATEMENT
COLOPHON

अब retrieval और graph का एक बड़ा भाग इसी table पर निर्भर करेगा।

१.१५ concept_relations table

यह अब central structured truth table है।

Fields
relation_id
relation_family
subject_concept_id
object_concept_id
polarity
relation_scope_json
confidence
status
notes
relation_family examples
defines
classifies
belongs_to
governs
causes
results_in
supports
contrasts_with
presupposes
manifests_as
is_exception_to
is_exemplified_by
is_glossed_by
is_temporally_related_to
is_spatially_related_to
१.१६ relation_evidence table

कोई भी relation बिना passage evidence के canonical नहीं होना चाहिए।

Fields
evidence_id
relation_id
passage_id
evidence_type
weight
confidence
review_status
note
evidence_type examples
direct
indirect_support
narrative_support
exception_support
lexical_support

यह table complete knowledge retrieval के लिये अत्यन्त महत्त्वपूर्ण है।

१.१७ concept_clusters table

अब cluster schema में प्रथम श्रेणी की इकाई है।

Fields
cluster_id
cluster_name
cluster_type
constitutional_trunk
description
status
notes
cluster_type examples
thematic
doctrinal
lexical_family
narrative_family
mixed_zone
cosmological
temporal
१.१८ cluster_memberships table
Fields
membership_id
cluster_id
member_type
member_id
membership_role
confidence
review_status
note
member_type
concept
passage
sense

इसीसे cluster dynamic और reviewable रहेगी।

१.१९ query_interpretations table

अब यह table scholar-facing retrieval के लिये अनिवार्य है।

Fields
query_id
raw_query
normalized_query
interpreted_concepts_json
requested_evidence_types_json
constitutional_trunk_hint
direct_indirect_balance
ambiguity_status
created_at

यह table complete knowledge retrieval को keyword search से ऊपर उठाती है।

१.२० retrieval_runs table

हर important retrieval reproducible होनी चाहिए।

Fields
retrieval_run_id
query_id
branch_id
retrieval_mode
parameters_json
created_at
१.२१ retrieval_evidence_groups table

अब output केवल flat ranked list नहीं होना चाहिए।

Fields
group_id
retrieval_run_id
group_name
group_rank
description
group_name examples
direct_definitions
classificatory_passages
procedural_passages
exceptions
narrative_support
parallel_passages
indirect_structural_support

यही table scholar-facing retrieval को useful बनायेगी।

१.२२ retrieval_group_items table
Fields
item_id
group_id
passage_id
rank_in_group
lexical_score
dense_score
rerank_score
hybrid_score
evidence_type
review_status
१.२३ reviews table

अब review objects broaden हो चुके हैं।

Fields
review_id
review_object_type
review_object_id
review_level
reviewer_id
decision
note
created_at
review_object_type examples
passage
lexeme_mention
sense_assignment
concept_mention
passage_role
relation
cluster_membership
retrieval_item
branch
१.२४ benchmarks table
Fields
benchmark_id
benchmark_type
name
description
priority
benchmark_payload_json
version_tag
is_active
benchmark_type
retrieval
role_detection
concept_assignment
relation
graph
constitutional
१.२५ benchmark_runs table
Fields
run_id
branch_id
benchmark_version
started_at
completed_at
summary_json
pass_fail
notes
१.२६ errors table
Fields
error_id
run_id
benchmark_id
passage_id
error_level
error_type
severity
observed_output_json
expected_output_json
reviewer_note
fix_category
error_level
text
concept
role
relation
cluster
retrieval
constitutional
१.२७ branches table
Fields
branch_id
branch_name
branch_type
parent_branch_id
description
status
created_at
created_by
branch_type
normalization
concept_model
role_model
relation_model
cluster_model
retrieval
ontology
status
sandbox
shadow
candidate
promoted
rejected
१.२८ deployments table
Fields
deployment_id
deployment_phase
branch_id
deployed_at
deployed_by
rollback_branch_id
notes
deployment_phase
D0
D1
D2
D3
D4
D5
१.२९ Optional later tables

यह trunk में अभी आवश्यक नहीं, पर बाद में आयेंगी:

embedding artifacts
active learning queue
disagreement queue
model registry
training dataset registry

इनका स्थान मुख्य concept architecture के बाद है।

चरण २ — Neo4j graph schema

अब graph schema corrected center पर रखते हैं।

२.१ मुख्य node labels
Passage
Lexeme
Sense
Concept
PassageRole
Relation
ConceptCluster
Work
Chapter
Query
EvidenceGroup
२.२ मुख्य relationships
Structural
(:Work)-[:HAS_CHAPTER]->(:Chapter)
(:Chapter)-[:HAS_PASSAGE]->(:Passage)
Lexical-semantic
(:Passage)-[:MENTIONS_LEXEME]->(:Lexeme)
(:Lexeme)-[:HAS_SENSE]->(:Sense)
(:Passage)-[:USES_SENSE]->(:Sense)
(:Passage)-[:EXPRESSES_CONCEPT]->(:Concept)
Role
(:Passage)-[:HAS_ROLE]->(:PassageRole)
Relation provenance
(:Passage)-[:SUPPORTS_RELATION]->(:Relation)
(:Relation)-[:SUBJECT]->(:Concept)
(:Relation)-[:OBJECT]->(:Concept)
Clusters
(:Concept)-[:BELONGS_TO_CLUSTER]->(:ConceptCluster)
(:Passage)-[:BELONGS_TO_CLUSTER]->(:ConceptCluster)
(:Sense)-[:BELONGS_TO_CLUSTER]->(:ConceptCluster)
Query / retrieval
(:Query)-[:RETURNS_GROUP]->(:EvidenceGroup)
(:EvidenceGroup)-[:CONTAINS_PASSAGE]->(:Passage)
२.३ Graph design principle

आरम्भ में direct doctrinal edges कम रखिये।
पहले provenance-safe structure रखिये।

मत कीजिये:

(:Concept)-[:CAUSES]->(:Concept) बिना evidence nodes के everywhere

कीजिये:

Passage -> supports Relation -> Concept / Concept

इससे later review, rollback, legality checking सब सम्भव रहेगा।

२.४ Optional direct edges

Later, only for high-confidence and reviewed relations:

(:Concept)-[:DEFINES]->(:Concept)
(:Concept)-[:CLASSIFIES]->(:Concept)
(:Concept)-[:IS_EXCEPTION_TO]->(:Concept)

किन्तु first graph में evidence-mediated graph बेहतर है।

चरण ३ — RDF / SHACL constitutional mirror

अब selected reviewed graph content का RDF mirror बनेगा।

Mirror में क्या जाये?
reviewed concepts
reviewed passage roles
reviewed relations
reviewed cluster memberships
top-level constitutional trunks
SHACL shapes validate करें:
legal relation families
legal node-type pairings
top-level trunk preservation
no illegal edge type
no mixed-zone flattening shortcuts
reviewed-only promotion

यह layer convenience नहीं, constitutional gate है।

चरण ४ — API flow

अब application layer का corrected flow स्थिर कीजिये।

४.१ Ingestion APIs
POST /sources/register

new source manifest

POST /sources/upload-raw

raw file path / artifact register

POST /normalize/run

given source / branch पर normalization pipeline

POST /segment/run

N2 से N3 passage segmentation

४.२ Concept / role / relation APIs
POST /extract/lexemes

surface lexical hits

POST /extract/senses

sense candidate generation

POST /extract/concepts

concept candidate generation

POST /extract/roles

passage-role detection

POST /extract/relations

relation proposal generation

POST /extract/clusters

cluster suggestion generation

अब यही corrected central extraction flow है।

४.३ Review APIs
GET /review/queue

queue by object type

GET /review/context/{passage_id}

full passage context

POST /review/decision

accept / edit / reject / defer / escalate

POST /review/batch-decision

quick batch review

४.४ Retrieval APIs
POST /search/passages

simple lexical passage search

POST /search/retrieve

grouped scholar-facing retrieval

POST /search/hybrid

lexical + dense + rerank + constitutional weighting

४.५ Graph APIs
POST /graph/export

PostgreSQL reviewed truth → Neo4j

GET /graph/concept/{concept_id}

concept neighborhood

GET /graph/passage/{passage_id}

passage-centered graph

GET /graph/cluster/{cluster_id}

cluster neighborhood

GET /graph/path

doctrinal path between concepts

४.६ Benchmark APIs
POST /benchmarks/run

specific branch पर benchmark suite

GET /benchmarks/report/{run_id}

report

GET /benchmarks/regressions/{branch_id}

regression view

४.७ Branch / deployment APIs
POST /branches/create

new branch

POST /branches/compare

candidate vs baseline compare

POST /branches/promote

promotion workflow

POST /deployments/create

shadow or main deploy

POST /deployments/rollback

rollback

चरण ५ — API request sequence का actual उदाहरण

अब एक पूरा corrected end-to-end flow दिखाता हूँ।

Example workflow

एक primary corpus chapter ingest करना

POST /sources/register
POST /sources/upload-raw
POST /normalize/run
POST /segment/run
POST /extract/lexemes
POST /extract/senses
POST /extract/concepts
POST /extract/roles
POST /extract/relations
POST /extract/clusters
GET /review/queue?type=concept_mention
POST /review/decision
GET /review/queue?type=passage_role
POST /review/decision
GET /review/queue?type=relation
POST /review/decision
POST /graph/export
POST /search/retrieve
POST /benchmarks/run
POST /branches/compare

यह अब corrected first living loop है।

चरण ६ — First working implementation sequence

अब actual build order देता हूँ।

Phase I — Foundation build
Step 1

PostgreSQL schema बनाइये:

sources
works
normalization_branches
documents
passages
Step 2

raw source register + upload flow

Step 3

N0 → N1 → N2 normalization pipeline

Step 4

segmentation engine

लक्ष्य

reliable passages table

Phase II — Conceptual extraction core
Step 5

lexeme inventory and lexeme extraction

Step 6

sense candidate generation

Step 7

corpus_concepts inventory

Step 8

concept candidate extraction

Step 9

passage-role detection

Step 10

relation proposal generation

Step 11

cluster suggestion generation

लक्ष्य

text से first conceptual field निकलने लगे

Phase III — Review core
Step 12

review queues

Step 13

annotation interface

Step 14

review write-back APIs

लक्ष्य

human-in-the-loop conceptual stabilization

Phase IV — Retrieval core
Step 15

simple passage search

Step 16

grouped scholar-facing retrieval

definitions
classifications
procedures
exceptions
narrative support
indirect structural support
Step 17

retrieval evidence grouping storage

लक्ष्य

system actual scholar queries पर usable बने

Phase V — Graph layer
Step 18

Neo4j schema

Step 19

reviewed conceptual truth से graph export

Step 20

basic graph browsing APIs

लक्ष्य

first living doctrinal graph

Phase VI — Benchmark and branch layer
Step 21

gold benchmark sets

Step 22

benchmark runner

Step 23

constitutional suite

Step 24

branch registry and promotion system

लक्ष्य

development अनुशासित हो

Phase VII — ML integration
Step 25

embeddings

Step 26

reranker

Step 27

role model

Step 28

sense disambiguation model

Step 29

relation / cluster suggestion models

लक्ष्य

human review burden घटे, quality बढ़े

Phase VIII — Constitutional gate
Step 30

RDF export

Step 31

SHACL validation

Step 32

deployment gating

लक्ष्य

system बुद्धिमान ही नहीं, मर्यादित भी हो

चरण ७ — Z890 + dual RTX 5090 पर corrected विभाजन

CPU + RAM side
PostgreSQL
Neo4j
normalization
segmentation
review queues
annotation interface
benchmark runner
SHACL validation
dashboards

GPU0
embeddings
reranker inference
scholar retrieval support

GPU1
role classifier
sense disambiguation
relation model
cluster suggestion model
Why this order?

क्योंकि पहले canonical structure चाहिए, फिर learned proposals।

चरण ८ — Minimal viable product

MVP-1
one work ingested
one normalization branch
verse + 3-verse segmentation
lexeme extraction
concept extraction
passage-role suggestions
review UI
PostgreSQL persistence
MVP-2
one chapter fully reviewed
relation evidence stored
graph export
first grouped retrieval output
first benchmark set
MVP-3
one reranker
one role model
active learning queue
branch registry
constitutional priority scoring

यही corrected realistic क्रम है।

चरण ९ — Schema mistakes to avoid

भूल १

entity को top-level trunk बना देना और concept को बाद में जोड़ना

भूल २

surface word, sense, और concept — तीनों को एक ही node मान लेना

भूल ३

passage-role table न बनाना

भूल ४

relation और relation-evidence को अलग न रखना

भूल ५

cluster को केवल derived visualization मानना, canonical review object न बनाना

भूल ६

query interpretation को store न करना

भूल ७

retrieval output को flat list तक सीमित रखना

भूल ८

review history overwrite करना

भूल ९

constitutional trunk field न रखना

भूल १०

graph export को canonical source मान लेना

चरण १० — Example end-to-end record family

अब एक corrected conceptual example देता हूँ।

Suppose किसी passage में:

एक doctrinal term है
उसका definitional use है
और वह broader cluster से जुड़ता है

तो PostgreSQL side पर records होंगे:

passage
lexeme mentions
sense assignments
concept mentions
passage_role = DEFINITION
one or more concept_relations
supporting relation_evidence
cluster_membership
reviews

Neo4j side पर nodes होंगे:

Passage
Lexeme
Sense
Concept
PassageRole
Relation
ConceptCluster

और यही family later retrieval, benchmark, and graph traversal में प्रयुक्त होगी।

चरण ११ — Software design principle

मैं यहाँ एक निर्णायक सिद्धान्त स्थापित करता हूँ:

थोड़े modules, स्पष्ट boundaries, strong versioning

मत कीजिये:

huge monolithic app
scattered scripts
hidden state notebooks
ad hoc manual DB edits

कीजिये:

modular services
explicit branch ids
explicit review ids
explicit benchmark versions
explicit deployment versions
provenance-safe graph export

इसी से system टिकेगी।

निष्कर्ष

अब project का actual engineering skeleton corrected रूप में स्पष्ट हो गया है।

PostgreSQL रखेगा canonical structured truth
Neo4j रखेगा living doctrinal graph
RDF / SHACL रखेगा constitutional legality gate
API layer ingestion से लेकर review, retrieval, graph export, benchmark, branch management तक प्रवाह बनायेगी
Implementation sequence foundation → conceptual extraction → review → retrieval → graph → benchmark → ML → constitutional gate के क्रम से चलेगी

यही क्रम corpus-centered, constitutional, reproducible, और दीर्घजीवी है।

उत्कर्ष

यदि पूरी रचना को एक सूत्र में कहा जाये, तो वह यह होगा:

Amarakośa देता है महा-अर्थ-विन्यास
primary corpus देता है जीवित विधान
PostgreSQL देता है स्मृति
Neo4j देता है संचार
passage-roles देते हैं ज्ञान-कार्य का बोध
concept-relations देती हैं संबद्धता
clusters देते हैं गतिशील semantic परिवार
review देता है प्रमाण
benchmark देती है परीक्षा
branch law देता है विकास
SHACL देती है मर्यादा

अगले पृष्ठ की ओर

इस पहले पृष्ठ में पद्धति, संवैधानिक आधार, अमरकोशीय ज्ञान-विन्यास, और implementation की पूर्वतैयारी का निरूपण दिया गया। अगले पृष्ठ में सम्पूर्ण पायथन कोड सहित actual software architecture, database schema, extraction pipeline, review discipline, benchmark governance, retrieval, training, redesign, और runtime operation का क्रमबद्ध निरूपण है।