एलएलएम कोड लिखने का एक अधिक स्थिर तरीका पहले डीएसएल लिखना है

कुछ समय पहले, मैंने वही स्थिति बार-बार देखी: आवश्यकताओं को सीधे मॉडल पर फेंकना, पीढ़ी की गति बहुत तेज़ है, और पुन: कार्य भी तेज़ है; पहले आवश्यकताओं को डीएसएल की एक परत में रखें, और फिर मॉडल को सिमेंटिक मॉडल की इस परत के आसपास कार्यान्वयन लिखने दें, और आउटपुट स्पष्ट रूप से स्थिर है। परिवर्तन बहुत सीधा है. कुंजी यह नहीं है कि क्या मॉडल लिखा जा सकता है, बल्कि यह है कि क्या वैकल्पिक स्थान पहले बंद कर दिया गया है।

प्राकृतिक भाषा दिशा-निर्देश बताने के लिए उपयुक्त है, लेकिन बहुत अधिक अंतर्निहित निर्णय लेने के लिए उपयुक्त नहीं है। लागू होने पर एक साधारण सी लगने वाली आवश्यकता को कई छोटे निर्णयों में विभाजित किया जाएगा: राज्य का नाम कैसे दिया जाए, क्या विफलता को पूरा माना जाता है, कितनी बार पुनः प्रयास किया जाए, समय विंडो किसके समय क्षेत्र पर आधारित है, और लॉग किस परत पर लिखा गया है। जब तक ये निर्णय पीढ़ी प्रक्रिया में छिपे रहेंगे, मॉडल एक ही समय में विवरण भरेगा और सीमाएं बदल देगा। अंतिम लिखी गई बात को चलाया जा सकता है, लेकिन उसकी समीक्षा करना कठिन है।

प्राकृतिक भाषा केवल समस्याओं के बारे में बात करने के लिए उपयुक्त है

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

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

डीएसएल अंतर्निहित निर्णय को स्पष्ट इनपुट में बदल देता है

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

scenario: payment_timeout
steps:
  - send: order.created
  - wait: 3s
  - if: payment_missing
    then: cancel_order
    audit: required

इस प्रकार की परिभाषा का सबसे बड़ा मूल्य यह नहीं है कि यह लिखे जाने पर अच्छी लगती है, बल्कि यह है कि इसका संस्करण नियंत्रित किया जा सकता है, भिन्न किया जा सकता है और समीक्षा की जा सकती है। कोड निर्माण, दस्तावेज़ीकरण, परीक्षण और आरेख सभी एक ही सिमेंटिक मॉडल से विकसित हो सकते हैं। यहां मॉडल एक आविष्कारक की तुलना में एक एक्चुएटर की तरह अधिक है। यह स्थापित सीमाओं को लागू करने के लिए जिम्मेदार है और मौके पर ही उन्हें फिर से लिखने के लिए जिम्मेदार नहीं है।

एक बार यह सीमा स्थापित हो गई तो बहुत सी चीजें जो लंबे समय से शोर मचा रही होंगी, शांत हो जाएंगी। परीक्षण में क्या शामिल होना चाहिए, क्या विफलता की उम्मीद है, और रोलबैक शर्तों पर अंतिम निर्णय किसका है? इन्हें अब प्राकृतिक भाषा में मौके पर ही नहीं समझाया जाता, बल्कि एक निष्पादन योग्य संरचना में लिखा जाता है। मनुष्य जो देखता है वह शब्दार्थ है, मशीनें जिसे क्रियान्वित करती हैं वह शब्दार्थ है, और समस्या निवारण के समय हम जिस पर लौटते हैं वह वही शब्दार्थ है।

एलएलएम डीएसएल के विकास में भाग लेने के लिए उपयुक्त है

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

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

मैं एलएलएम को डीएसएल के पीछे रखना पसंद करूंगा। पहले सीमाओं को स्पष्ट करें, और फिर उन्हें बाद में सीमाओं को भरने में मदद करने दें, ताकि सिस्टम बार-बार सुधार से आसानी से विचलित न हो।

अर्थपरक परत भी बोझिल हो जाएगी

अधिक डीएसएल हमेशा बेहतर नहीं होता. जब क्षेत्र अभी भी तेजी से बदल रहा है, तो समय से पहले जमना गलत धारणाओं को जन्म देगा; यदि सिमेंटिक परत को बहुत अधिक सार्वभौमिक रूप से डिज़ाइन किया गया है, तो यह एक और भारी ढांचा बन जाएगा। वास्तव में लागत प्रभावी परिदृश्य आमतौर पर तब होता है जब एक ही प्रकार की कार्रवाइयां बार-बार होती हैं, समीक्षा लागत अधिक होती है, और व्यवहार का पता लगाया जाना चाहिए। इस बिंदु पर, डीएसएल अब एक अतिरिक्त बोझ नहीं है, बल्कि एक स्थिर प्रवेश द्वार में बिखरे हुए निर्णयों का संग्रह है।

इसलिए, अधिक व्यावहारिक निर्णय यह नहीं है कि “क्या एलएलएम को डीएसएल से सुसज्जित किया जा सकता है?” लेकिन “क्या पहले इस मामले के शब्दार्थ को ठीक करना आवश्यक है?” एक बार जब उत्तर हां हो, तो संकेत शब्द पर पूरी जिम्मेदारी नहीं रहनी चाहिए। प्रॉम्प्ट इरादे को समझाने के लिए जिम्मेदार है, डीएसएल बाधाओं को दूर करने के लिए जिम्मेदार है, और मॉडल बाधाओं को निष्पादन योग्य परिणामों में बदलने के लिए जिम्मेदार है। इस तरह से जो लिखा गया है वह सुधारों की एक श्रृंखला के बजाय एक इंजीनियरिंग प्रणाली की तरह है।